Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230116173420.1278704-1-mw@semihalf.com> <20230116173420.1278704-3-mw@semihalf.com>
 <Y8WOVVnFInEoXLVX@shell.armlinux.org.uk> <20230116181618.2iz54jywj7rqzygu@skbuf>
 <Y8XJ3WoP+YKCjTlF@lunn.ch> <CAPv3WKc8gfBb7BDf5kwyPCNRxmS_H8AgQKRitbsqvL7ihbP1DA@mail.gmail.com>
 <20230117163453.o7pv7cdvgeobne4b@skbuf>
In-Reply-To: <20230117163453.o7pv7cdvgeobne4b@skbuf>
From:   Marcin Wojtas <mw@semihalf.com>
Date:   Tue, 17 Jan 2023 19:01:20 +0100
Message-ID: <CAPv3WKewRYwgTvNWYMdxwZvJfgj3__H3GYiKu__DHQf0fJPLEw@mail.gmail.com>
Subject: Re: [net-next: PATCH v4 2/8] net: mdio: switch fixed-link PHYs API to fwnode_
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        "Russell King (Oracle)" <linux@armlinux.org.uk>,
        linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
        netdev@vger.kernel.org, rafael@kernel.org,
        andriy.shevchenko@linux.intel.com, sean.wang@mediatek.com,
        Landen.Chao@mediatek.com, linus.walleij@linaro.org,
        vivien.didelot@gmail.com, f.fainelli@gmail.com,
        davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
        pabeni@redhat.com, hkallweit1@gmail.com, jaz@semihalf.com,
        tn@semihalf.com, Samer.El-Haj-Mahmoud@arm.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

wt., 17 sty 2023 o 17:34 Vladimir Oltean <olteanv@gmail.com> napisa=C5=82(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