linux-kernel - Re: [PATCH 05/12] regulator: Introduce tps68470-regulator driver

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: <YWndpGgBtLEAEaNj@sirena.org.uk>
Date:   Fri, 15 Oct 2021 20:59:32 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Mark Gross <markgross@...nel.org>,
        Andy Shevchenko <andy@...radead.org>,
        Daniel Scally <djrscally@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, Len Brown <lenb@...nel.org>,
        linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Kate Hsuan <hpa@...hat.com>, linux-media@...r.kernel.org,
        linux-clk@...r.kernel.org
Subject: Re: [PATCH 05/12] regulator: Introduce tps68470-regulator driver

On Fri, Oct 15, 2021 at 09:48:24PM +0200, Hans de Goede wrote:
> On 10/15/21 9:40 PM, Mark Brown wrote:

> > I can't see how the quirking gets propagated through into the driver and
> > I'd really expect that in a situation like this the platform data would
> > be passed through as platform data from the code doing the quirks,

> That is exactly what is happening here. The platform_data in this
> case is just an array of regulator_init_data pointers (one per
> regulator in the PMIC):

No, it's not.  What normally happens is that whatever registers the
device will when registering the device supply platform data that the
device later picks up from the struct device during probe.  What you're
saying is that the idea here is that driver unconditionally declares
platform data and then other code scribbles over that before the driver
instantiates.  This is cleaner in that it keeps the platform
configuration together and safer since the device can't exist before
it's configuration is provided.

> So we have the code doing the quirks determining the regulator_init_data
> and passing this through platform_data, which AFAICT is exactly what
> you want?

No.  There should be no sign of the platform data getting allocated or
initialised in the driver consuming the platform data.  It should purely
be reading the data it gets passed by the platform initialisation code.

Please make the use of platform data look like normal platform data use
rather than going and inventing some new scheme.

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