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

[Cristian Ciocaltea]

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