linux-kernel - Re: [PATCH RFT 2/6] gpio: mmio: get chip label and GPIO base from device properties

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]

Message-ID: <33c99324-a50b-4e0f-bcc7-012d3244d47a@kernel.org>
Date: Wed, 25 Jun 2025 12:42:08 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
 Linus Walleij <linus.walleij@...aro.org>, Lee Jones <lee@...nel.org>,
 Liviu Dudau <liviu.dudau@....com>, Sudeep Holla <sudeep.holla@....com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Aaro Koskinen <aaro.koskinen@....fi>,
 Janusz Krzysztofik <jmkrzyszt@...il.com>, Tony Lindgren <tony@...mide.com>,
 Russell King <linux@...linux.org.uk>, Alim Akhtar <alim.akhtar@...sung.com>,
 linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
 patches@...nsource.cirrus.com, linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH RFT 2/6] gpio: mmio: get chip label and GPIO base from
 device properties

On 25/06/2025 12:28, Bartosz Golaszewski wrote:
> On Wed, Jun 25, 2025 at 12:26 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>>>>>> I wouldn't be stoked to see device trees abusing the "gpio-mmio,base"
>>>>>> property all of a sudden just because it now exists as a device
>>>>>> property though... I kind of wish we had a way to opt out of exposing
>>>>>> this to all the sub-property paths. But it seems tiresome, so:
>>>>>>
>>>>>> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>>>>>>
>>>>>> Yours,
>>>>>> Linus Walleij
>>>>>
>>>>> That's not a problem - this property is not in any DT bindings and as
>>>>> such is not an allowed property in DT sources. For out-of-tree DTs? We
>>>>> don't care about those.
>>>> That's not true, we do care about implied ABI. Try changing/breaking
>>>> this later, when users complain their out of tree DTS is affected, and
>>>> explaining this all to Greg.
>>>>
>>>
>>> Wait, seriously? I thought that the upstream bindings are the source
>>> of truth for device-tree sources...
>>
>>
>> They are, until they are not... ok, we don't really care that much about
>> out of tree DTS, but in-tree DTS still could use these and don't care
>> about bindings check, right?
>>
> 
> Could they though? I can imagine this happening by accident but in
> general: you'd expect new sources to follow the bindings and be

Yes, that is what I would expect.

> verifiable against them? Otherwise, what's the point of the schema?

Of course, but do you really think most SoC maintainers even run
dtbs_check on their existing or new code?

I think some maintainers pay attention, but RISC-V and my tree are the
only ones actually actively checking this for existing and new code.
Except me, no other maintainer even referenced maintainer-soc-clean-dts
profile.

I can easily imagine DTS with warnings and undocumented ABI gets merged
and then released in some kernel. And when you release such kernel in
v6.17 with DTS and drivers, isn't this already an implied ABI?

Best regards,
Krzysztof