linux-kernel - Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup

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]

Date:   Wed, 25 Aug 2021 15:26:37 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Daniel Scally <djrscally@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list

On Wed, Aug 25, 2021 at 2:30 PM Mark Brown <broonie@...nel.org> wrote:
> On Wed, Aug 25, 2021 at 02:10:05PM +0300, Andy Shevchenko wrote:
> > On Wed, Aug 25, 2021 at 1:34 PM Mark Brown <broonie@...nel.org> wrote:
>
> > > DMI quirks throughout the drivers like we currently do then we should
> > > have a way for boards to just store generic platform data for a device
> > > and then have that platform data joined up with the device later.  This
>
> > What you are describing sounds similar to what we have, i.e. fwnode graph.
> > That's how v4l2 describes complex connections between devices in the
> > camera world.
>
> > But IIRC you don't like this idea to be present with regulators (as
> > per v1 of this series).
>
> No, what was proposed for regulator was to duplicate all the the DT
> binding code in the regulator framework so it parses fwnodes then have
> an API for encoding fwnodes from C data structures at runtime.  The bit
> where the data gets joined up with the devices isn't the problem, it's
> the duplication and fragility introduced by encoding everything into
> an intermediate representation that has no purpose and passing that
> around which is the problem.

The whole exercise with swnode is to minimize the driver intrusion and
evolving a unified way for (some) of the device properties. V4L2 won't
like what you are suggesting exactly because they don't like the idea
of spreading the board code over the drivers. In some cases it might
even be not so straightforward and easy.

Laurent, do I understand correctly the v4l2 expectations?

> > So, what do you propose then?
>
> I propose what I suggested above, providing a way to attach platform
> data to firmware provided devices.  Don't bother with an intermediate
> encoding, just use platform data.  Or just put quirks in the drivers
> like all the other systems using ACPI for platforms where it's not a
> good fit.

-- 
With Best Regards,
Andy Shevchenko