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

[Cristian Ciocaltea]

Hi Krzysztof,

On 2/28/26 11:58 AM, Krzysztof Kozlowski wrote:
> 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.

I thought we've already reached consensus to allow extending the binding and
keep both lists, precisely to avoid breaking the ABI.  At least this was my
understanding according to your reply [1]:

  You can have also oneOf with older list "deprecated: true", if want to
  keep any users unaffected.

And this patch was meant to do exactly that.  Did I miss something?

>> This is barely acceptable, but I am just annoyed already explain it to
>> you multiple times.

There is no need to explain it again, we've got your point.  We've also brought our
arguments and I had the impression that we eventually agreed to keep the unit
address unchanged, based on your comments [2]:

  Yes, with drop of the oneOf this would be fine.
  I meant, the "one item option" in oneOf.

Is this not applicable anymore?

>> But now you claim, you can break ABI for cosmetic unimportant change,

No, breaking ABI wasn't our intention here.  If we put the issue with reg-names
being optional aside for a moment (as that one will be handled separately), is
there still a problem with the current revision?

>> but actually doing something meaningful is a no-go?

Making reg-names mandatory has been already clarified with Conor and agreed [3]
to be handled in a dedicated patch.  And that one will indeed break the ABI, but
it's unavoidable, unfortunately. 

>> At least use correct arguments if you want to discuss.

Sorry, I'm not sure what do you mean.  I really believed that we managed to
address all the open topics by now.

Thanks,
Cristian

[1] https://lore.kernel.org/all/1cdc36f2-6e51-492a-9063-7d0a784f5118@kernel.org/
[2] https://lore.kernel.org/all/12b30229-1c55-429d-8a3c-0d831c4d33ab@kernel.org/
[3] https://lore.kernel.org/all/20260227-urologist-gratitude-7984733f2d41@spud/