[PATCH 2/5] dt-bindings: mfd: atmel,at91-usart: convert to json-schema

Krzysztof Kozlowski krzysztof.kozlowski at linaro.org
Fri Aug 19 02:05:30 PDT 2022


On 19/08/2022 11:47, Krzysztof Kozlowski wrote:
> On 19/08/2022 11:38, Sergiu.Moga at microchip.com wrote:
>> On 18.08.2022 11:39, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 17/08/2022 10:55, Sergiu Moga wrote:
>>>> Convert at91 USART DT Binding for Atmel/Microchip SoCs to
>>>> json-schema format.
>>>>
>>>> Signed-off-by: Sergiu Moga <sergiu.moga at microchip.com>
>>>> ---
>>>>   .../bindings/mfd/atmel,at91-usart.yaml        | 190 ++++++++++++++++++
>>>>   .../devicetree/bindings/mfd/atmel-usart.txt   |  98 ---------
>>>>   2 files changed, 190 insertions(+), 98 deletions(-)
>>>>   create mode 100644 Documentation/devicetree/bindings/mfd/atmel,at91-usart.yaml
>>>>   delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-usart.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91-usart.yaml
>>>> new file mode 100644
>>>> index 000000000000..cf15d73fa1e8
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/atmel,at91-usart.yaml
>>> One more thing - I think this should be in serial directory, not mfd,
>>> even though it includes SPI. MFD is just a Linux naming/wrapper device.
>>>
>>> Best regards,
>>> Krzysztof
>>
>> I would rather keep it in this directory, since its corresponding driver 
>> is also in the mfd directory.
> 
> Sorry, but that's poor argument. Driver subsystems match Linux
> convention, not necessarily hardware type/naming. Bindings directories
> match hardware. MFD bindings are only for MFD wrapper drivers and this
> is a serial interface. Not a MFD. You even do not add MFD devices in the
> driver but add *always one* device depending on serial feature you want.
> This is not even MFD device but regular platform device with children.
> 
> You put it in SoC, though, because all other SoCs store it there...

The last one should be:

You could put it in SoC, though, because all other SoCs store it there...

Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list