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:   Thu, 3 Mar 2022 09:48:40 +0100
From:   =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     Hans de Goede <hdegoede@redhat.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Daniel Scally <djrscally@gmail.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Wolfram Sang <wsa@kernel.org>, Peter Rosin <peda@axentia.se>,
        Russell King <linux@armlinux.org.uk>,
        Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, linux-kernel@vger.kernel.org,
        linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org,
        netdev@vger.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>
Subject: Re: [RFC 00/10] add support for fwnode in i2c mux system and sfp
Message-ID: <20220303094840.3b75c4c9@fixe.home>
In-Reply-To: <Yhe/qhFNNiGVHSW1@sirena.org.uk>
References: <20220221162652.103834-1-clement.leger@bootlin.com>
        <20220224154040.2633a4e4@fixe.home>
        <2d3278ef-0126-7b93-319b-543b17bccdc2@redhat.com>
        <20220224174205.43814f3f@fixe.home>
        <Yhe/qhFNNiGVHSW1@sirena.org.uk>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Le Thu, 24 Feb 2022 17:26:02 +0000,
Mark Brown <broonie@kernel.org> a =C3=A9crit :

> On Thu, Feb 24, 2022 at 05:42:05PM +0100, Cl=C3=A9ment L=C3=A9ger wrote:
> > Hans de Goede <hdegoede@redhat.com> a =C3=A9crit : =20
>=20
> > > As Mark already mentioned the regulator subsystem has shown to
> > > be a bit problematic here, but you don't seem to need that? =20
>=20
> > Indeed, I don't need this subsystem. However, I'm still not clear why
> > this subsystem in particular is problematic. Just so that I can
> > recognize the other subsystems with the same pattern, could you explain
> > me why it is problematic ?  =20
>=20
> ACPI has a strong concept of how power supply (and general critical
> resources) for devices should be described by firmware which is very
> different to that which DT as it is used in Linux has, confusing that
> model would make it much harder for generic OSs to work with generic
> ACPI systems, and makes it much easier to create unfortunate interactions
> between bits of software expecting ACPI models and bits of software
> expecting DT models for dealing with a device.  Potentially we could
> even run into issues with new versions of Linux if there's timing or
> other changes.  If Linux starts parsing the core DT bindings for
> regulators on ACPI systems then that makes it more likely that system
> integrators who are primarily interested in Linux will produce firmwares
> that run into these issues, perhaps unintentionally through a "this just
> happens to work" process.

Ok that's way more clear.

>=20
> As a result of this we very much do not want to have the regulator code
> parsing DT bindings using the fwnode APIs since that makes it much
> easier for us to end up with a situation where we are interpreting _DSD
> versions of regulator bindings and ending up with people making systems
> that rely on that.  Instead the regulator API is intentional about which
> platform description interfaces it is using.  We could potentially have
> something that is specific to swnode and won't work with general fwnode
> but it's hard to see any advantages for this over the board file based
> mechanism we have already, swnode offers less error detection (typoing
> field names is harder to spot) and the data marshalling takes more code.

Instead of making it specific for swnode, could we make it instead non
working for acpi nodes ? Thus, the parsing would work only for swnode
and device_node, not allowing to use the fwnode support with acpi for
such subsystems (not talking about regulators here).

If switching to board file based mechanism, this means that all drivers
that are used by the PCIe card will have to be modified to support this
mechanism.

>=20
> fwnode is great for things like properties for leaf devices since those
> are basically a free for all on ACPI systems, it allows us to quickly
> and simply apply the work done defining bindings for DT to ACPI systems
> in a way that's compatible with how APCI wants to work.  It's also good
> for cross device bindings that are considered out of scope for ACPI,
> though a bit of caution is needed determining when that's the case.

Ok got it, thanks for the in-depth explanations.

--=20
Cl=C3=A9ment L=C3=A9ger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com