Message-ID: <Yhe/qhFNNiGVHSW1@sirena.org.uk>
Date:   Thu, 24 Feb 2022 17:26:02 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Clément Léger <clement.leger@...tlin.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Wolfram Sang <wsa@...nel.org>, Peter Rosin <peda@...ntia.se>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, linux-i2c@...r.kernel.org,
        netdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Subject: Re: [RFC 00/10] add support for fwnode in i2c mux system and sfp

On Thu, Feb 24, 2022 at 05:42:05PM +0100, Clément Léger wrote:
> Hans de Goede <hdegoede@...hat.com> a écrit :

> > As Mark already mentioned the regulator subsystem has shown to
> > be a bit problematic here, but you don't seem to need that?

> 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 ? 

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.

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.

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists