linux-kernel - Re: [RFC PATCH 4/5] regulator: add 88pm88x regulators 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: <89fab5fd-34ce-4196-b246-b5c3e4c7e201@linaro.org>
Date: Sun, 7 Jan 2024 11:34:07 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Karel Balej <karelb@...li.ms.mff.cuni.cz>, Mark Brown <broonie@...nel.org>
Cc: Karel Balej <balejk@...fyz.cz>, Lee Jones <lee@...nel.org>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Duje Mihanović <duje.mihanovic@...le.hr>,
 ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org
Subject: Re: [RFC PATCH 4/5] regulator: add 88pm88x regulators driver

On 07/01/2024 10:49, Karel Balej wrote:
> Mark,
> 
> On Fri Jan 5, 2024 at 4:18 PM CET, Mark Brown wrote:
>> On Thu, Dec 28, 2023 at 10:39:13AM +0100, Karel Balej wrote:
>>
>>> @@ -68,6 +68,21 @@ static struct mfd_cell pm886_devs[] = {
>>>  		.num_resources = ARRAY_SIZE(pm88x_onkey_resources),
>>>  		.resources = pm88x_onkey_resources,
>>>  	},
>>> +	{
>>> +		.name = "88pm88x-regulator",
>>> +		.id = PM88X_REGULATOR_ID_LDO2,
>>> +		.of_compatible = "marvell,88pm88x-regulator",
>>> +	},
>>
>> Why are we adding an of_compatible here?  It's redundant, the MFD split
>> is a feature of Linux internals not of the hardware, and the existing
>> 88pm8xx MFD doesn't use them.
> 
> in a feedback to my MFD series, Rob Herring pointed out that there is no
> need to have a devicetree node for a subdevice if it only contains
> "compatible" as the MFD driver can instantiate subdevices itself. I
> understood that this is what he was referring to, but now I suspect that
> it is sufficient for the mfd_cell.name to be set to the subdevice driver
> name for this - is that correct?

I think Rob was only referring to "no need to have a devicetree node".
But you added here a devicetree node, plus probably undocumented compatible.

Does it even pass the checkpatch?

Best regards,
Krzysztof