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

[Jon Hunter <jonathanh@nvidia.com>]

Hi Krzysztof,

On 29/07/2025 15:05, Thierry Reding wrote:
> On Tue, Jul 29, 2025 at 11:28:43AM +0200, Krzysztof Kozlowski wrote:
>> On 29/07/2025 11:15, Jon Hunter wrote:
>>>
>>> On 25/07/2025 07:47, Krzysztof Kozlowski wrote:
>>>> On 25/07/2025 07:22, Rajesh Gumasta wrote:
>>>>> +description: |
>>>>> +  Register Settings provides a generic way to specify register configurations
>>>>> +  for any hardware controllers. Settings are specified under a "reg-settings"
>>>>> +  sub-node under the controller device tree node. It allows defining both
>>>>> +  default and operating mode specific register settings in the device tree.
>>>>> +
>>>>> +properties:
>>>>> +  reg-settings:
>>>>> +    type: object
>>>>> +    description: |
>>>>> +      Container node for register settings configurations. Each child node
>>>>> +      represents a specific configuration mode or operating condition.
>>>>> +
>>>>> +    additionalProperties:
>>>>> +      type: object
>>>>
>>>> I don't understand what does this binding bring. It is empty.
>>>
>>>
>>> Yes this is very much similar to the pinctrl.yaml that defines a
>>> top-level object that can then be used by different devices and those
>>
>> No, it is not similar. pinctrl.yaml defines common properties and common
>> schema for class of devices - pin controllers.
>>
>> There is nothing common here, nothing defined except that you have
>> unspecified children nodes.
> 
> This is supposed to be very generic and it needs to be by its nature.

To add, we want the ability to use the 'reg-settings' child node for any 
device, but because the settings for a given class of device will vary, 
for now we opted to create this empty top-level node. The alternative is 
to define this 'reg-settings' node for every device using it, which is 
fine, if that is preferred. Please let me know what your preference is here?

>>> devices can then define the properties they need. So the examples for
>>> I2C and MMC really demonstrate how this would be used in the subsequent
>>> patches. Obviously we are open to any ideas on how if there are better
>>> or preferred ways to do this.
>>
>> I don't see this part addressing comments from Rob - you need more users
>> of this. Adding fake (empty, no-op) common schema is not solving it.
> 
> Bjorn, Simon and Nishanth are Cc'ed on this series since they expressed
> interest in this kind of functionality, so I expect that we'll see other
> users of this eventually.
> 
> However, we do have to get the ball rolling and propose something that
> we think can work for a number of cases, so that's what this is.

We certainly have more drivers that will use this. However, we want to 
flesh out the device-tree schema for this with just a couple examples to 
keep the review simple and focused.

In the short-term I would like to understand if you agree that we can 
use device-tree to store such hardware register settings? If so, then we 
are happy to re-work the proposal in anyway that you would prefer so 
that we can agree on how such hardware register setting values can be 
stored in device-tree.

Thanks!
Jon

-- 
nvpublic