On 01/05/2024 17:59, Eddie James wrote:
>
> On 4/30/24 01:53, Krzysztof Kozlowski wrote:
>> On 29/04/2024 23:01, Eddie James wrote:
>>> Conver to json-schema for the OCC documentation. Also document the fact
>>> that the OCC "bridge" device will often have the hwmon node as a
>>> child.
>>>
>>> Signed-off-by: Eddie James <eajames@xxxxxxxxxxxxx>
>>> ---
>>> Changes since v3:
>>> - Move required below other properties
>>> - Drop "occ-" in child node
>>> - Drop hwmon unit address
>>> - Complete example
>>> - Change commit message to match similar commits
>>>
>>> .../devicetree/bindings/fsi/ibm,p9-occ.txt | 16 --------
>>> .../devicetree/bindings/fsi/ibm,p9-occ.yaml | 41 +++++++++++++++++++
>>> 2 files changed, 41 insertions(+), 16 deletions(-)
>>> delete mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> deleted file mode 100644
>>> index e73358075a90..000000000000
>>> --- a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>>> +++ /dev/null
>>> @@ -1,16 +0,0 @@
>>> -Device-tree bindings for FSI-attached POWER9/POWER10 On-Chip Controller (OCC)
>>> ------------------------------------------------------------------------------
>>> -
>>> -This is the binding for the P9 or P10 On-Chip Controller accessed over FSI from
>>> -a service processor. See fsi.txt for details on bindings for FSI slave and CFAM
>>> -nodes. The OCC is not an FSI slave device itself, rather it is accessed
>>> -through the SBE FIFO.
>>> -
>>> -Required properties:
>>> - - compatible = "ibm,p9-occ" or "ibm,p10-occ"
>>> -
>>> -Examples:
>>> -
>>> - occ {
>>> - compatible = "ibm,p9-occ";
>>> - };
>>> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml
>>> new file mode 100644
>>> index 000000000000..3ab2582cb8a0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml
>>> @@ -0,0 +1,41 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/fsi/ibm,p9-occ.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: IBM FSI-attached On-Chip Controller (OCC)
>>> +
>>> +maintainers:
>>> + - Eddie James <eajames@xxxxxxxxxxxxx>
>>> +
>>> +description:
>>> + The POWER processor On-Chip Controller (OCC) helps manage power and
>>> + thermals for the system, accessed through the FSI-attached SBEFIFO
>>> + from a service processor.
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - ibm,p9-occ
>>> + - ibm,p10-occ
>>> +
>>> +patternProperties:
>>> + "^hwmon":
>> And now it raises questions:
>> 1. Other devices on FSI bus have unit addresses, so why this does not?
>> 2. This suggest only one hwmon, so ^hwmon$, which is then not a
>> patternProperty but property.
>> 3. But the true problem why do you even need two empty nodes? These
>> should be combined into one node.
>
>
> 1. This is not truly on the FSI bus. It is on the SBEFIFO "bus"
>
> 2. True enough, I'll change it to property.
>
> 3. If this binding was being designed now, I'd agree with you, but the
> two nodes (occ and occ-hwmon) are already documented, I'm just changing
> to yaml here... Changing that would require a lot of changes and would
> break the two drivers.
No child was documented before and documenting things post-factum does
not allow to bypass regular review rules.
Best regards,
Krzysztof
