Thread (29 messages) 29 messages, 3 authors, 2021-10-16

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

From: Hans de Goede <hidden>
Date: 2021-10-15 19:48:44
Also in: linux-acpi, linux-media, lkml, platform-driver-x86

Hi,

On 10/15/21 9:40 PM, Mark Brown wrote:
On Fri, Oct 15, 2021 at 09:27:50PM +0200, Hans de Goede wrote:
quoted
On 10/15/21 8:58 PM, Mark Brown wrote:
quoted
quoted
I am very confused about why it's in the driver without a DMI quirk
and/or clear comments about why and saying that this is a terrible
example to copy.
quoted
The DMI quirks live in the ACPI glue code under drivers/platform/x86,
that code instantiates the MFD cell and sets the platform-data
as part of the cell.
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):

struct tps68470_regulator_platform_data {
        const struct regulator_init_data *reg_init_data[TPS68470_NUM_REGULATORS];
};

This struct gets filled by platform specific code under drivers/platform/x86
(in later patches in the series).

And the regulator code in this patch consumes this like this:

                if (pdata && pdata->reg_init_data[i])
                        config.init_data = pdata->reg_init_data[i];
                else
                        config.init_data = &tps68470_init[i];

                rdev = devm_regulator_register(&pdev->dev, &regulators[i], &config);

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?

Regards,

Hans
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help