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 <andrew@xxxxxxx> napisał(a): > > > > On Mon, Jan 16, 2023 at 08:16:18PM +0200, Vladimir Oltean wrote: > > > On Mon, Jan 16, 2023 at 05:50:13PM +0000, Russell King (Oracle) wrote: > > > > On Mon, Jan 16, 2023 at 06:34:14PM +0100, Marcin Wojtas wrote: > > > > > 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
