Re: [net-next: PATCH v4 2/8] net: mdio: switch fixed-link PHYs API to fwnode_

[Marcin Wojtas]

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