linux-kernel - Re: [PATCH] dt-bindings: mmc: move compatible property to its specific binding

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: <3ecf58f4-38c0-4435-899a-400df62f5d51@linaro.org>
Date: Tue, 4 Feb 2025 09:14:11 +0100
From: neil.armstrong@...aro.org
To: Dharma.B@...rochip.com, robh@...nel.org, conor@...nel.org
Cc: ulf.hansson@...aro.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 khilman@...libre.com, jbrunet@...libre.com, linux-mmc@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
 martin.blumenstingl@...glemail.com
Subject: Re: [PATCH] dt-bindings: mmc: move compatible property to its
 specific binding

Hi,

On 04/02/2025 05:24, Dharma.B@...rochip.com wrote:
> Rob / Conor,
> 
> On 20/01/25 10:00 am, Dharma B wrote:
>> Hi Rob/Conor,
>>
>> On 09/01/25 2:26 am, Martin Blumenstingl wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Hi Dharma,
>>>
>>> On Wed, Jan 8, 2025 at 4:11 AM <Dharma.B@...rochip.com> wrote:
>>> [...]
>>>> "One issue is 'compatible' is required. Either that would have to be
>>>> dropped as required."
>>>>
>>>> Instead of just dropping it from "required:", I removed the property
>>>> itself and moved it to another binding.
>>>>
>>>> I will send a v2 by removing it from the required, will it be fine?
>>> For me this is fine.
>>>
>>> My understanding is that if we drop the compatible property completely
>>> then any compatible string will be allowed (for example: compatible =
>>> "random,name"). This is because mmc-slot.yaml inherits the properties
>>> from mmc-controller-common.yaml which itself has
>>> "additionalProperties: true".
>>> However, if we allow it but make it optional it means that there's
>>> only two valid states:
>>> - no compatible property (on the Atmel / Microchip SoCs)
>>> - a compatible property with the value "mmc-slot" (as used on Amlogic
>>> Meson and Cavium Thunder SoCs)
>>> - (anything else is considered invalid)
>>>
>>> Rob, Conor: can confirm this or correct me wherever I got something
>>> wrong.
>>> I hope that your feedback will help Dharma write a good patch
>>> description for v2.
>>
>> Shall I proceed with v2 by dropping the compatible from the required
>> property list?
> 
> I hope this email finds you well. Just following up on my previous
> message from 20/01/25, as it seems to have achieved an impressive
> feat—perfect stealth mode. Either my patch is so flawless that it left
> everyone speechless, or it has been silently sacrificed to the inbox
> gods. 😅
> 
> If there are any concerns, feedback, or a secret ritual I need to
> perform to get a response, please do let me know. Would love to hear
> your thoughts when time permits.
> 
> Looking forward to breaking the radio silence!

Just send a v2 as RFC, so we can comment on it.

Thanks,
Neil

>>
>>>
>>>
>>> Best regards,
>>> Martin
>>>
>>
>>
> 
>