Hi,

wt., 17 sty 2023 o 17:34 Vladimir Oltean [off-list ref] napisał(a):

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

quoted

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