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 for Android: free password hash cracker in your pocket

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

Message-ID: <YSZk5tyAxZoosXS3@pendragon.ideasonboard.com>
Date:   Wed, 25 Aug 2021 18:42:30 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Daniel Scally <djrscally@...il.com>,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [RFC PATCH v2 1/3] regulator: core: Add regulator_lookup_list

On Wed, Aug 25, 2021 at 04:27:35PM +0100, Mark Brown wrote:
> On Wed, Aug 25, 2021 at 04:48:15PM +0200, Hans de Goede wrote:
> 
> > Daniel, I believe that what Mark wants here is something similar to what
> > we already do for the 5v boost converter regulator in the TI bq24190 charger
> > chip used on some Cherry Trail devices.
> 
> Yeah, that or something like a generalized version of it which lets a
> separate quirk file like they seem to have register the data to insert -
> I'd be happy enough with the simple thing too given that it's not
> visible to anything, or with DMI quirks in the regulator driver too for
> that matter if it's just one or two platforms but there do seem to be
> rather a lot of these platforms which need quirks.

Let's also remember that we have to handle not just regulators, but also
GPIOs and clocks. And I'm pretty sure there will be more. We could have
a mechanism specific to the tps68470 driver to pass platform data from
the board file to the driver, and replicate that mechanism in different
drivers (for other regulators, clocks and GPIOs), but I really would
like to avoid splitting the DMI-conditioned platform data in those
drivers directly. I'd like to store all the init data for a given
platform in a single "board" file.

-- 
Regards,

Laurent Pinchart