Hi, wt., 17 sty 2023 o 17:34 Vladimir Oltean <olteanv@xxxxxxxxx> napisał(a): > > On Tue, Jan 17, 2023 at 05:05:53PM +0100, Marcin Wojtas wrote: > > 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. An example could be found in v1 of this series, > > the last 4 patches in [1] show that it can be done in a simple / > > seamless way, especially given the ACPI (fwnode) PHY description in > > phylink is already settled and widely used. I am aware at the end of > > the day, after final review all this can be more complex. > > > > I expect that the actual DSA ACPI support acceptance will require a > > lot of discussions and decisions, on whether certain solutions are > > worth migrating from OF world or require spec modification. For now my > > goal was to migrate to a more generic HW description API, and so to > > allow possible follow-up ACPI-related modifications, and additions to > > be extracted and better tracked. > > I have a simple question. > > If you expect that the DSA ACPI bindings will require a lot of > discussions, then how do you know that what you convert to fwnode now > will be needed later, and why do you insist to mechanically convert > everything to fwnode without having that discussion first? > Ok, let me clarify. From the technical standpoint, I think it is fairly easy and to a very big extent, we should be able to reuse, what is already existing - I made it work with a really minimal set of changes, using a standard nodes' hierarchy and generic methods in the ACPI tables. As more difficult, I consider getting this solution accepted by the ACPI and the network subsystem maintainers, also given the OF quirks/legacy stuff, that apparently needs to be ruled out in such circumstances. However, I perceive a preparation step, with migrating to the more generic HW description API in the generic net/dsa, as a sort of improvement, but I get your point and I will wait with resubmitting these changes again. > You see the lack of a need to maintain separate code paths between OF > and ACPI as useful. Yet the DSA maintainers don't, and in some cases > this is specifically what they want to avoid. So a mechanical conversion > will end up making absolutely no progress. Fair enough. I'll keep it on hold until MDIOSerialBus gets accepted and repost a bigger, combined patchset with all changes like in the v1. Best regards, Marcin
