Re: [PATCH v6 1/4] dt-bindings: mfd: Add sony,cronos-smc

[Timothy Pearson <tpearson@raptorengineering.com>]

----- Original Message -----
> From: "Krzysztof Kozlowski" <krzk@kernel.org>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>
> Cc: "devicetree" <devicetree@vger.kernel.org>, "linux-kernel" <linux-kernel@vger.kernel.org>, "Rob Herring"
> <robh+dt@kernel.org>, "Conor Dooley" <conor+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
> "Lee Jones" <lee@kernel.org>, "Georgy Yakovlev" <Georgy.Yakovlev@sony.com>, "Shawn Anastasio"
> <sanastasio@raptorengineering.com>
> Sent: Wednesday, January 7, 2026 2:22:33 PM
> Subject: Re: [PATCH v6 1/4] dt-bindings: mfd: Add sony,cronos-smc

> On 07/01/2026 18:41, Timothy Pearson wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Krzysztof Kozlowski" <krzk@kernel.org>
>>> To: "Timothy Pearson" <tpearson@raptorengineering.com>
>>> Cc: "devicetree" <devicetree@vger.kernel.org>, "linux-kernel"
>>> <linux-kernel@vger.kernel.org>, "Rob Herring"
>>> <robh+dt@kernel.org>, "Conor Dooley" <conor+dt@kernel.org>, "Krzysztof
>>> Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
>>> "Lee Jones" <lee@kernel.org>, "Georgy Yakovlev" <Georgy.Yakovlev@sony.com>,
>>> "Shawn Anastasio"
>>> <sanastasio@raptorengineering.com>
>>> Sent: Wednesday, January 7, 2026 11:18:09 AM
>>> Subject: Re: [PATCH v6 1/4] dt-bindings: mfd: Add sony,cronos-smc
>> 
>>> On 07/01/2026 18:09, Timothy Pearson wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Krzysztof Kozlowski" <krzk@kernel.org>
>>>>> To: "Timothy Pearson" <tpearson@raptorengineering.com>
>>>>> Cc: "devicetree" <devicetree@vger.kernel.org>, "linux-kernel"
>>>>> <linux-kernel@vger.kernel.org>, "Rob Herring"
>>>>> <robh+dt@kernel.org>, "Conor Dooley" <conor+dt@kernel.org>, "Krzysztof
>>>>> Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
>>>>> "Lee Jones" <lee@kernel.org>, "Georgy Yakovlev" <Georgy.Yakovlev@sony.com>,
>>>>> "Shawn Anastasio"
>>>>> <sanastasio@raptorengineering.com>
>>>>> Sent: Wednesday, January 7, 2026 1:25:10 AM
>>>>> Subject: Re: [PATCH v6 1/4] dt-bindings: mfd: Add sony,cronos-smc
>>>>
>>>>> On Tue, Jan 06, 2026 at 06:21:33PM -0600, Timothy Pearson wrote:
>>>>>> From: Shawn Anastasio <sanastasio@raptorengineering.com>
>>>>>>
>>>>>> The Sony Cronos Platform Controller is a multi-purpose platform controller
>>>>>> that provides both a watchdog timer and an LED controller for the Sony
>>>>>> Interactive Entertainment Cronos x86 server platform. As both functions
>>>>>> are provided by the same CPLD, a multi-function device is exposed as the
>>>>>> parent of both functions.
>>>>>>
>>>>>> Add a DT binding for this device.
>>>>>>
>>>>>> Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
>>>>>> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
>>>>>> ---
>>>>>>  .../bindings/mfd/sony,cronos-smc.yaml         | 128 ++++++++++++++++++
>>>>>
>>>>> How this can be a v6 with no changelog at all and still not tested?
>>>>>
>>>>> What happened with this patchset? Where is it explained?
>>>>
>>>> Changes have only been to fix issues identified in review and any posted
>>>> autotest failures.
>>>
>>> And where is this explained? Please always provide detailed changelog in
>>> the cover letter or individual patch.
>>>
>>>>
>>>> Please note that the tooling to check the DT bindings does NOT appear work
>>>> properly, we've wasted a lot of time and effort attempting to get it running
>>>> only to find that it's spitting out internal Python errors even for other
>>>> drivers that are *already* in the kernel source tree.  This obviously creates a
>>>> situation where it's difficult to pre-check the patch set for compliance; if
>>>> you want to see this first hand, spin up a Debian Sid VM (which has a very
>>>> recent version of the DT tooling from late 2025) and try to check any of the
>>>> in-tree MFD drivers using the documented methods.
>>>
>>> I am using DT schema on multiple distros, including Debian but not Sid
>>> but Trixie
>>> (https://krzk.eu/#/builders/91/builds/116/steps/13/logs/stdio). Works
>>> without problem...
>> 
>> Good to know.  There is next to no documentation on the required software
>> versions to make this work, which complicates
>> 
>>> On regular Debian based distro this is just few commands - pix install
>>> and them make dt_binding_check - so I am surprised you spent a lot of
>>> time on setting this up.
>>>
>>> What is the problem exactly?
>> 
>> Good to know.  There is next to no documentation on the required software
>> versions to make this work, which complicates setup.  Bookworm's DT package was
>> too old when it was tried pre-Trixie release, and at the time Sid didn't work
>> either for some other reason.  The assumption was that the kernel needed a very
>> recent version of the DT tooling, so Sid was tried again this year.  Will try
>> Trixie before the next patch update.
> 
> So you mean from distro? We don't use it from the distro because it's
> heavily outdated. It makes no sense. That's why I wrote - pipx.
> 
> 
>> 
>> Here is example output against an in-tree driver, using an up to date Sid system
>> (word wrap not applied so as to make the errors easier to read):
>> 
>> dt_binding_check
>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml
>> 
>>   CHKDT   ./Documentation/devicetree/bindings
>> Traceback (most recent call last):
>>   File "/usr/bin/dt-doc-validate", line 8, in <module>
>>     sys.exit(main())
>>              ~~~~^^
>>   File "/usr/lib/python3/dist-packages/dtschema/doc_validate.py", line 66, in main
> 
> Feels liks distro package. Never saw this, but again I have never used
> distro and have absolutely never recommended even trying that. There
> were problems with matching jsonschema package, but regardless - if you
> use distro you will use very old schemas, so you will hit another
> problem. It's just pointless to rely on distro here - no benefits for
> you, but only stale/old package, especially that installing via pipx is
> easy.

In my opinion, the distro package should be fixed.  There are security considerations with PyPI [1], and those concerns then require (per our policies) the use of isolated systems due to downloading and running unsigned and (at least on our end) unaudited code from the general Internet.  The distro packages are signed and built from source on known trusted systems, in contrast with pip's general mode of operation, and I can't imagine it would be that difficult to make sure that Debian and Fedora (the two most common base distros) ship a reasonably new version of the valdation tools, especially in unstable / bleeding edge releases (Sid).

That said, for now, I guess I'll spin up a new VM and give pipx a shot.  Thanks for the pointer in the right direction!

[1] https://carles-garcia.net/python/python_pip/