From: Krzysztof Kozlowski <krzk@kernel.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Lee Jones <lee@kernel.org>, Liviu Dudau <liviu.dudau@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Janusz Krzysztofik <jmkrzyszt@gmail.com>,
Tony Lindgren <tony@atomide.com>,
Russell King <linux@armlinux.org.uk>,
Alim Akhtar <alim.akhtar@samsung.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
patches@opensource.cirrus.com, linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH RFT 2/6] gpio: mmio: get chip label and GPIO base from device properties
Date: Wed, 25 Jun 2025 12:42:08 +0200 [thread overview]
Message-ID: <33c99324-a50b-4e0f-bcc7-012d3244d47a@kernel.org> (raw)
In-Reply-To: <CAMRc=MdEWmgj8hTY3fQrXnDDv6pmK9XPvT9gE=5oGEs8R7GOVA@mail.gmail.com>
On 25/06/2025 12:28, Bartosz Golaszewski wrote:
> On Wed, Jun 25, 2025 at 12:26 PM Krzysztof Kozlowski <krzk@kernel.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@linaro.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
next prev parent reply other threads:[~2025-06-25 10:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 13:19 [PATCH RFT 0/6] gpio: mmio: remove struct bgpio_pdata Bartosz Golaszewski
2025-06-24 13:19 ` [PATCH RFT 1/6] gpio: mmio: drop the big-endian platform device variant Bartosz Golaszewski
2025-06-24 19:41 ` Linus Walleij
2025-06-24 13:19 ` [PATCH RFT 2/6] gpio: mmio: get chip label and GPIO base from device properties Bartosz Golaszewski
2025-06-24 19:43 ` Linus Walleij
2025-06-25 7:35 ` Bartosz Golaszewski
2025-06-25 8:53 ` Krzysztof Kozlowski
2025-06-25 10:23 ` Bartosz Golaszewski
2025-06-25 10:26 ` Krzysztof Kozlowski
2025-06-25 10:28 ` Bartosz Golaszewski
2025-06-25 10:42 ` Krzysztof Kozlowski [this message]
2025-06-24 13:19 ` [PATCH RFT 3/6] mfd: vexpress-sysreg: set-up software nodes for gpio-mmio Bartosz Golaszewski
2025-06-24 19:45 ` Linus Walleij
2025-06-26 13:22 ` Lee Jones
2025-06-26 13:25 ` Bartosz Golaszewski
2025-06-27 12:55 ` Lee Jones
2025-06-26 22:20 ` Liviu Dudau
2025-06-24 13:19 ` [PATCH RFT 4/6] ARM: omap1: ams-delta: use generic device properties " Bartosz Golaszewski
2025-06-24 19:45 ` Linus Walleij
2025-06-24 13:19 ` [PATCH RFT 5/6] ARM: s3c: crag6410: " Bartosz Golaszewski
2025-06-24 16:33 ` Charles Keepax
2025-06-24 19:46 ` Linus Walleij
2025-06-26 19:51 ` Krzysztof Kozlowski
2025-06-24 13:19 ` [PATCH RFT 6/6] gpio: mmio: remove struct bgpio_pdata Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33c99324-a50b-4e0f-bcc7-012d3244d47a@kernel.org \
--to=krzk@kernel.org \
--cc=aaro.koskinen@iki.fi \
--cc=alim.akhtar@samsung.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=jmkrzyszt@gmail.com \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=liviu.dudau@arm.com \
--cc=lpieralisi@kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=sudeep.holla@arm.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).