Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Rob Herring <robh@kernel.org>]

On Tue, Sep 30, 2025 at 04:01:27PM +0100, Jon Hunter wrote:
> Hi Chintan,
> 
> On 29/09/2025 05:39, Chintan Vankar wrote:
> 
> ...
> 
> > Following your series, I would like to bring to your attention that
> > Texas Instruments SoCs also have a component which requires similar kind
> > of configuration, named Timesync Router(TSR). It enables the
> > multiplexing of M inputs to N outputs, where inputs can be selectively
> > driven based on N output configuration. A detailed explanation of the
> > TSR and our attempts we tried to implement TSR can be found in following
> > RFC series:
> > https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
> > https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/

I fail to see how that is related to this series. I'm not going to 
study these 2 implementations and imagine how it could be implemented 
using this series. If the amount of overlap is just 'reg-settings' node, 
then that's not really enough. More below.

> > To implement TSR, the relevant registers must be configured via the
> > device tree. We initially assumed that the device could be handled as a
> > mux-controller and could be extended in the same subsystem, but it was
> > ineffective. Having explored both the approaches, we now plan to
> > implement TSR within misc subsystem, which aligns with the dt-bindings
> > that you have proposed in this series.
> > 
> > The purpose to replying over this series is to inform you that we also
> > have a component requiring configuration as outlined in this series. Let
> > us know if you have any suggestions for this.
> 
> That's great! Thanks for the feedback.
> 
> Rob, Krzysztof, Conor, have you guys had chance to look at this series some
> more? We are open to re-working it as necessary to address any
> concerns/comments you have. However, this appears to be stalled at the
> moment and I am not sure what we should do next to push this forward.

I fail to see what is generic here? There's a generic node name, but 
that has nothing else common. The 2 examples share nothing because it 
is all bus specific. But then the bus specific stuff is NVIDIA specific. 
It's the bus specific part that should be generic (to the bus type) IMO. 

A concrete second user would go a long way to help. Anything "common" 
from one vendor ends up needing something different from the 2nd user. 
Somehow that 2nd user always shows up a month later... So the rule is 
generally I want to see 2 users. Yeah, it's hard to get others to pay 
attention, but that's not really my problem.

Rob