[PATCH v4 1/3] media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}

[Cristian Ciocaltea]

On 2/27/26 8:10 PM, Conor Dooley wrote:
> On Fri, Feb 27, 2026 at 07:49:33PM +0200, Cristian Ciocaltea wrote:
>> 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.
 
[...]

> So yes, while what I propose is an ABI break, the driver currently
> expects reg-names to be mandatory for the rk3588-vdec. Additionally, new
> required properties are only really a meaningful ABI break if the driver
> is changed to required them, since that would render old devicetrees
> non-functional. The driver in question already requires them, so that's
> pretty moot! 

I think that's precisely the information I was looking for, i.e. breaking ABI
in this case is fully justified since we cannot really fix the driver.  I mean 
we would have time to do this, since the rk3588 related changes landed in
v7.0-rc1, but it's not feasible to accommodate to the current state of the
binding, as you clearly pointed out.

> Hopefully I've made my point about reg-names being mandatory this time
> around?

Totally, thanks for your time and sorry for the confusion around the topic!

My only question now is how should we proceed with this particular change - I'd
handle it in a dedicated patch, preceding this one.

Regards,
Cristian