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;
Date:   Tue, 17 Jan 2023 18:34:53 +0200
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Marcin Wojtas <mw@semihalf.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
Subject: Re: [net-next: PATCH v4 2/8] net: mdio: switch fixed-link PHYs API
 to fwnode_
Message-ID: <20230117163453.o7pv7cdvgeobne4b@skbuf>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPv3WKc8gfBb7BDf5kwyPCNRxmS_H8AgQKRitbsqvL7ihbP1DA@mail.gmail.com>
Precedence: bulk

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?

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.