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: <20210712170120.GG4435@sirena.org.uk>
Date:   Mon, 12 Jul 2021 18:01:20 +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 Mon, Jul 12, 2021 at 07:08:23PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 12, 2021 at 4:35 PM Mark Brown <broonie@...nel.org> wrote:

> > But why?  I'm not seeing the advantage over providing platform data
> > based on DMI quirks here, it seems like a bunch of work for no reason.

> What do you mean by additional work? It's exactly opposite since most
> of the drivers in the kernel are using the fwnode interface rather
> than platform data. Why should we _add_ the specific platform data
> handling code in the certain drivers instead of not touching them at
> all?

It's adding an entirely new representation of standard data with less
validation support than either DT or platform data which seems like a
needlessly roundabout and error prone way of moving the data about with
less tooling support.  As far as I can tell the only advantage is that
it lets you write the quirk in a different source file but I'm finding
it hard to get excited about that.  If we were fixing up an existing
ACPI binding or something this approach would make sense to me but it's
making something entirely new out of whole cloth here.

We already have generic platform data support for the regulator API so
driver modifications would just be the DMI matching which is going to
have to happen somewhere anyway, I don't see a huge win from putting
them in one file rather than another.  It should basically just boil
down to being another data table, I imagine you could write a helper for
it, or probably even come up with some generic thing that let you
register a platform data/DMI combo independently of the driver to get it
out of the driver code (looking more like the existing GPIO code which
is already being used in another bit of this quirking).

It feels like this should be making more use of existing stuff than it
is.  If you look at what the core part of the code does it's taking data
which was provided by one part of the kernel in one set of C structs and
parsing those into a struct init_data which is what the core actually
wants to consume.  This seems like an entirely redundant process, we
should be able to just write the machine configuration into some struct
init_datas and get that associated with the regulators without creating
an otherwise entirely unused intermediate representation of the data.

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