linux-kernel - Re: [RFC PATCH v2 1/6] dt-bindings: mfd: add entry for Marvell 88PM886 PMIC

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] [day] [month] [year] [list]

Date: Mon, 19 Feb 2024 08:29:42 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Karel Balej <karelb@...li.ms.mff.cuni.cz>, Rob Herring <robh@...nel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Lee Jones <lee@...nel.org>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 linux-input@...r.kernel.org, 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 v2 1/6] dt-bindings: mfd: add entry for Marvell
 88PM886 PMIC

On 18/02/2024 16:10, Karel Balej wrote:
> Rob Herring, 2024-02-15T08:20:52-06:00:
>>>  .../bindings/mfd/marvell,88pm88x.yaml         | 74 +++++++++++++++++++
>>
>> Filename should match the compatible.
>>
>> In general, drop the 'x' wildcard.
> 
> By "in general", do you mean for the drivers code also?

No, not driver. The rules for wildcard, that they are discouraged, are
DT binding rules.

> 
> As I have mentioned in the commit message for the driver, the other
> device is very similar and if the support for it was ever to be added
> (which I personally currently have no interest in), I believe it would
> make sense to extend this driver. Is it then still prefered to call it
> all just 88pm886 now?

Extend the driver, it's unrelated. Binding still should be named like
compatible, because that extension might never happen.

> 
>>> +properties:
>>> +  compatible:
>>> +    const: marvell,88pm886-a1
> 
> So the file should be called marvell,88pm886-a1.yaml, correct? Again, is
> it prefered to call it like this even if the other revision could
> eventually be added (again, I am not interested in that right now

If you already add two devices, flexible name would be fine. But you do
not add it now and you might never add, so keep the filename=compatible.
It is fine if it has also other compatibles later. We already accepted
many bindings like that.


Best regards,
Krzysztof