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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4156 bytes --]

On Fri, Feb 27, 2026 at 09:35:01PM +0200, Cristian Ciocaltea wrote:
> 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!

No worries. I as kinda wondering if I had someone gone nuts and
misunderstaood what the driver was doing!

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

I would do it in a dedicated patch yeah, since it is independently
justifiable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]