From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
To: Conor Dooley <conor@kernel.org>,
Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Detlev Casanova <detlev.casanova@collabora.com>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@kernel.org>,
kernel@collabora.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Conor Dooley <conor.dooley@microchip.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH v4 1/3] media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}
Date: Fri, 27 Feb 2026 19:49:33 +0200 [thread overview]
Message-ID: <86f4e4ee-cf49-4ebe-8cc6-0a9763ade36a@collabora.com> (raw)
In-Reply-To: <20260227-atonable-glamorous-920cfd832bc1@spud>
On 2/27/26 7:18 PM, Conor Dooley wrote:
> On Thu, Feb 26, 2026 at 04:56:30PM -0500, Nicolas Dufresne wrote:
>> Le jeudi 26 février 2026 à 20:59 +0000, Conor Dooley a écrit :
>>> On Thu, Feb 26, 2026 at 02:45:11PM -0500, Nicolas Dufresne wrote:
>>>> Le jeudi 26 février 2026 à 18:43 +0000, Conor Dooley a écrit :
>
>>>>> Deprecating the order also makes little sense to me, given that some of
>>>>> these devices only have one reg entry, which as far as I can tell from
>>>>> looking at the driver *is* the "function" region, so it can never be
>>>>> entirely deprecated.
>>>>
>>>> What I'd like to see, is a binding expression that behave like a set, not a
>>>> list, and leave the ordering open. As people keep repeating, there is nothing in
>>>> a binding that assist to define the right ordering (its not address or base
>>>> addres aware). That basically means, we can't as reviewer see that ordering is
>>>> going to imposing using a base address in the unit name (which is a convenience,
>>>> not a rule I suppose) that differ from the vendor documented base address.
>>>>
>>>> By explicitly removing the ordering in the binding, we create a strict rule that
>>>> driver should retrieve this by name, and never assume the ordering, which I
>>>> personally like.
>>>>
>>>> thoughts ?
>>>
>>> Yeah, you can do this, but to avoid potential breaks you have to do it
>>> from the start, not after the fact. Probably there's bindings that get
>>> acked every day that do do this. Even the retcon is okay to do when
>>> reg-names is mandated by the binding and the users use reg-names in my
>>> opinion.
>>
>> I think from the above analyses, since the usage only starts in rc1, we have
>> room for improving it knowing we aren't creating problem for anyone. Note that I
>> have no idea what the syntax is to "do this", and I doubt either Detlev or
>> Cristian have a clue.
>
> I think this is the only bit that really still needs a reply, this can
> be solved by adding reg-names as "required" to the existing conditional
> portion of the binding. There's probably hundreds of examples if one
> does a search for "then:\n.*required:" to use a basis for the change
> here. Probably should be an independent change, since it is needed even
> without the re-order given the bug I brought up.
As mentioned in my previous reply, the actual problem is that the binding has
been already released, and I'm not sure we can change this without breaking the
ABI.
Regards,
Cristian
next prev parent reply other threads:[~2026-02-27 17:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 10:46 [PATCH v4 0/3] arm64: dts: rockchip: Fix vdec register blocks order on RK3576/RK3588 Cristian Ciocaltea
2026-02-26 10:46 ` [PATCH v4 1/3] media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88} Cristian Ciocaltea
2026-02-26 18:43 ` Conor Dooley
2026-02-26 19:45 ` Nicolas Dufresne
2026-02-26 20:59 ` Conor Dooley
2026-02-26 21:56 ` Nicolas Dufresne
2026-02-26 22:15 ` Conor Dooley
2026-02-26 22:41 ` Nicolas Dufresne
2026-02-27 7:38 ` Krzysztof Kozlowski
2026-02-27 9:09 ` Conor Dooley
2026-02-27 17:18 ` Conor Dooley
2026-02-27 17:49 ` Cristian Ciocaltea [this message]
2026-02-27 18:10 ` Conor Dooley
2026-02-27 19:35 ` Cristian Ciocaltea
2026-02-27 19:39 ` Conor Dooley
2026-02-27 7:39 ` Krzysztof Kozlowski
2026-02-27 7:46 ` Krzysztof Kozlowski
2026-02-27 11:37 ` Cristian Ciocaltea
2026-02-27 13:03 ` Krzysztof Kozlowski
2026-02-28 1:11 ` Nicolas Dufresne
2026-02-27 17:13 ` Conor Dooley
2026-02-27 17:42 ` Cristian Ciocaltea
2026-02-28 9:54 ` Krzysztof Kozlowski
2026-02-28 9:58 ` Krzysztof Kozlowski
2026-03-03 0:26 ` Cristian Ciocaltea
2026-03-04 21:26 ` Cristian Ciocaltea
2026-02-26 10:46 ` [PATCH v4 2/3] arm64: dts: rockchip: Fix vdec register blocks order on RK3576 Cristian Ciocaltea
2026-02-26 10:46 ` [PATCH v4 3/3] arm64: dts: rockchip: Update vdec register blocks order on RK3588 Cristian Ciocaltea
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=86f4e4ee-cf49-4ebe-8cc6-0a9763ade36a@collabora.com \
--to=cristian.ciocaltea@collabora.com \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=heiko@sntech.de \
--cc=hverkuil@kernel.org \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=robh@kernel.org \
/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