On Tue, Jan 17, 2023 at 05:05:53PM +0100, Marcin Wojtas wrote:

Hi Andrew and Vladimir,

pon., 16 sty 2023 o 23:04 Andrew Lunn [off-list ref] napisał(a):

quoted

On Mon, Jan 16, 2023 at 08:16:18PM +0200, Vladimir Oltean wrote:

quoted

On Mon, Jan 16, 2023 at 05:50:13PM +0000, Russell King (Oracle) wrote:

quoted

On Mon, Jan 16, 2023 at 06:34:14PM +0100, Marcin Wojtas wrote:

quoted

fixed-link PHYs API is used by DSA and a number of drivers
and was depending on of_. Switch to fwnode_ so to make it
hardware description agnostic and allow to be used in ACPI
world as well.

Would it be better to let the fixed-link PHY die, and have everyone use
the more flexible fixed link implementation in phylink?

Would it be even better if DSA had some driver-level prerequisites to
impose for ACPI support - like phylink support rather than adjust_link -
and we would simply branch off to a dsa_shared_port_link_register_acpi()
function, leaving the current dsa_shared_port_link_register_of() alone,
with all its workarounds and hacks? I don't believe that carrying all
that logic over to a common fwnode based API is the proper way forward.

In the past couple of years, a number of subsystems have migrated to a
more generic HW description abstraction (e.g. a big chunk of network,
pinctrl, gpio). ACPI aside, with this patchset one can even try to
describe the switch topology with the swnode (I haven't tried that
though). I fully agree that there should be no 0-day baggage in the
DSA ACPI binding (FYI the more fwnode- version of the
dsa_shared_port_validate_of() cought one issue in the WIP ACPI
description in my setup). On the other hand, I find fwnode_/device_
APIs really helpful for most of the cases - ACPI/OF/swnode differences
can be hidden to a generic layer and the need of maintaining separate
code paths related to the hardware description on the driver/subsystem
level is minimized.

It looks like we are heading towards three different descriptions. OF,
ACPI and swnode. Each is likely to be different. OF has a lot of
history in it, deprecated things etc, which should not appear in the
others. So i see a big ugly block of code for the OF binding, and
hopefully clean and tidy code for ACPI binding and a clean and tidy
bit of code for swmode.,

It would be nice if the results of that parsing could be presented to
the drivers in a uniform way, so the driver itself does not need to
care where the information came from. But to me it is clear that this
uniform layer has no direct access to the databases, since the
database as are different.

	Andrew