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

[Krzysztof Kozlowski]

On 28/02/2026 10:54, Krzysztof Kozlowski wrote:
> On 27/02/2026 18:42, Cristian Ciocaltea wrote:
>> On 2/27/26 7:13 PM, Conor Dooley wrote:
>>> On Fri, Feb 27, 2026 at 01:37:17PM +0200, Cristian Ciocaltea wrote:
>>>> Hi Krzysztof, Conor,
>>>>
>>>> On 2/27/26 9:46 AM, Krzysztof Kozlowski wrote:
>>>>> On Thu, Feb 26, 2026 at 12:46:53PM +0200, Cristian Ciocaltea wrote:
>>>>>> With the introduction of the RK3588 SoC, and RK3576 afterwards, two more
>>>>>> register blocks have been provided for the video decoder unit.
>>>>>>
>>>>>> However, the binding does not properly describe the new hardware layout,
>>>>>
>>>>> As you shown me last time with excerpt of address spaces from
>>>>> datasheet/manual, the binding correctly describes the hardware and above
>>>>> sentence is not true.
>>>>>
>>>>>> as it breaks the convention expecting the unit address to indicate the
>>>>>> start of the first register range, i.e. 'function' block is listed
>>>>>
>>>>> Imprecise wording. "start of the main or primary register range"
>>>>>
>>>>> (if you have 0x1000 with one reg and 0x20000000 with everything, the
>>>>> unit address will be 0x20000000).
>>>>>
>>>>>> before 'link' instead of the opposite.
>>>>>>
>>>>>> Since the binding changes have been already released and a fix would
>>>>>> bring up an ABI break, mark the current 'reg-names' ordering as
>>>>>> deprecated and introduce an alternative 'link,function,cache' listing
>>>>>> which follows the address-based ordering according to the TRM.
>>>>>>
>>>>>> Additionally, drop the 'reg' description items as the order is not fixed
>>>>>> anymore, while the information they offer is not very relevant anyway.
>>>>>
>>>>> This is fine for me.
>>>>
>>>> Thanks for the additional feedback!
>>>>
>>>> If I'm not mistaken (please correct me), the only remaining (hard)
>>>> blocker for the series would be to improve this commit message.
>>>
>>> No, you also need to fix the problem I pointed out about reg-names being
>>> optional on the devices you're relying on reg-names for. 
>>
>> My only concern is that by marking reg-names as required we would break the ABI,
> 
> You are ALREADY BREAKING the ABI. Really, for absolutely non-important
> cosmetic change in unit address, where I asked you repeatedly to fix the
> unit address, you change the ABI affecting kernel and DTS users.
> 
> This is barely acceptable, but I am just annoyed already explain it to
> you multiple times.
> 
> But now you claim, you can break ABI for cosmetic unimportant change,
> but actually doing something meaningful is a no-go?
> 
> At least use correct arguments if you want to discuss.

And I double checked now with Conor - your binding and drivers are
broken here and THIS you must fix. Not the unit address you are so
focused about.

Best regards,
Krzysztof