linux-kernel - Re: [RFC PATCH 0/2] Add software node support to regulator framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210713181837.GE4098@sirena.org.uk>
Date:   Tue, 13 Jul 2021 19:18:37 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Daniel Scally <djrscally@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        kieran.bingham@...asonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework

On Tue, Jul 13, 2021 at 06:55:59PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 13, 2021 at 6:25 PM Mark Brown <broonie@...nel.org> wrote:

> > The driver code is trivial boilerplate, assuming someone doesn't go and
> > implement a helper to register stuff separately like I suggested.  The
> > proposed swnode stuff would involve duplicating the DT parsing code.
> > This seems like a whole lot of effort for something that provides a
> > worse result than either of the existing things.

> I'm not sure I follow. Where did you see the duplication when I saw
> the other way around?

The current patch consists entirely of additions, it does not remove any
existing code at all, the diffstat is:

 5 files changed, 174 insertions(+)

> Converting code from OF to fwnode APIs in most cases is smooth and
> doesn't add any overhead to the codebase,

We explicitly do not want to attempt to parse regulator properties out
of ACPI platform descriptions because using the regulator binding on
ACPI platforms conflicts with the ACPI model for power management and
we really don't want to encourage platforms to attempt to mix and match
here, it's not going to lead to anything robust.  System integrators
that need this sort of OS visible low level power management really
should be working with the UEFI forum to get an ACPI specification for
it, or if they don't really need it fixing up their AML to DTRT.

If you were to say that we could bodge around that by somehow forcing
this binding to exist only for swnodes when running on ACPI systems then
we'd still have the problems with creating something with worse tooling
than what's there already.

Like I said in the other mail fwnode is a nice hack for systems that are
using ACPI but have hardware that's doing something totally outside the
ACPI model to allow them to reuse work that's been done for DT, it's not
a universal solution to the lack of appropriate support for describing
modern systems in ACPI.

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