Messages in this thread | | | Subject | Re: [PATCH 05/12] regulator: Introduce tps68470-regulator driver | From | Hans de Goede <> | Date | Fri, 15 Oct 2021 21:48:24 +0200 |
| |
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: >> On 10/15/21 8:58 PM, Mark Brown wrote: > >>> 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. > >> 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, ®ulators[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
| |