Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Rob Herring <robh+dt@xxxxxxxxxx>
> Date: Thu, 1 Sep 2022 17:26:18 -0500
> 
> On Thu, Sep 1, 2022 at 10:56 AM Russell King (Oracle)
> <linux@xxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, Sep 01, 2022 at 06:45:52PM +0300, Krzysztof Kozlowski wrote:
> > > On 01/09/2022 18:24, Russell King (Oracle) wrote:
> > > > On Thu, Sep 01, 2022 at 06:15:46PM +0300, Krzysztof Kozlowski wrote:
> > > >> On 01/09/2022 18:12, Russell King (Oracle) wrote:
> > > >>>>> +  compatible:
> > > >>>>> +    items:
> > > >>>>> +      - enum:
> > > >>>>> +        - apple,t8103-smc
> > > >>>>
> > > >>>> You miss two spaces of indentation on this level.
> > > >>>
> > > >>> Should that be picked up by the dt checker?
> 
> I have a problem that Krzysztof is quicker. ;) Maybe I should stop
> screening the emails (for the times I break things mostly).
> 
> > > >>
> > > >> I think yamllint complains about it. It is not a hard-dependency, so
> > > >> maybe you don't have it installed.
> > > >>
> > > >>>
> > > >>>>> +        - apple,t8112-smc
> > > >>>>> +        - apple,t6000-smc
> > > >>>>
> > > >>>> Bring some order here - either alphabetical or by date of release (as in
> > > >>>> other Apple schemas). I think t6000 was before t8112, so it's none of
> > > >>>> that orders.
> > > >>>
> > > >>> Ok.
> > > >>>
> > > >>>>> +      - const: apple,smc
> > > >>>>> +
> > > >>>>> +  reg:
> > > >>>>> +    description: Two regions, one for the SMC area and one for the SRAM area.
> > > >>>>
> > > >>>> You need constraints for size/order, so in this context list with
> > > >>>> described items.
> > > >>>
> > > >>> How do I do that? I tried maxItems/minItems set to 2, but the dt checker
> > > >>> objected to it.
> > > >>
> > > >> One way:
> > > >> reg:
> > > >>   items:
> > > >>     - description: SMC area
> > > >>     - description: SRAM area
> > > >>
> > > >> but actually this is very similar what you wrote for reg-names - kind of
> > > >> obvious, so easier way:
> > > >>
> > > >> reg:
> > > >>   maxItems: 2
> > > >
> > > > Doesn't work. With maxItems: 2, the example fails, yet it correctly lists
> > > > two regs which are 64-bit address and 64-bit size - so in total 8 32-bit
> > > > ints.
> > > >
> > > > Documentation/devicetree/bindings/mfd/apple,smc.example.dtb: smc@23e400000: reg: [[2, 1044381696], [0, 16384], [2, 1071644672], [0, 1048576]] is too long
> > > >         From schema: /home/rmk/git/linux-rmk/Documentation/devicetree/bindings/mfd/apple,smc.yaml
> > > >
> > > > Hence, I originally had maxItems: 2, and ended up deleting it because of
> > > > the dt checker.
> > > >
> > > > With the two descriptions, it's the same failure.
> > >
> > > Yeah, they should create same result.
> > >
> > > >
> > > > I think the problem is that the checker has no knowledge in the example
> > > > of how big each address and size element of the reg property is. So,
> > > > it's interpreting it as four entries of 32-bit address,size pairs
> > > > instead of two entries of 64-bit address,size pairs. Yep, that's it,
> > > > if I increase the number of "- description" entries to four then it's
> > > > happy.
> > > >
> > > > So, what's the solution?
> > > >
> > >
> > > If you open generated DTS examples (in your
> > > kbuild-output/Documentation/devicetree/bindings/mfd/) you will see which
> > > address/size cells are expected. By default it is I think address/size
> > > cells=1, so you need a bus node setting it to 2.
> >
> > Thanks, that works. The patch with all those points addressed now looks
> > like:
> >
> > 8<===
> > From: "Russell King (Oracle)" <rmk+kernel@xxxxxxxxxxxxxxx>
> > Subject: [PATCH] dt-bindings: mfd: add binding for Apple Mac System Management
> >  Controller
> >
> > Add a DT binding for the Apple Mac System Management Controller.
> >
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@xxxxxxxxxxxxxxx>
> > ---
> >  .../devicetree/bindings/mfd/apple,smc.yaml    | 61 +++++++++++++++++++
> >  1 file changed, 61 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
> > new file mode 100644
> > index 000000000000..168f237c2962
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
> > @@ -0,0 +1,61 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Apple Mac System Management Controller
> > +
> > +maintainers:
> > +  - Hector Martin <marcan@xxxxxxxxx>
> > +
> > +description:
> > +  Apple Mac System Management Controller implements various functions
> > +  such as GPIO, RTC, power, reboot.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - apple,t6000-smc
> > +          - apple,t8103-smc
> > +          - apple,t8112-smc
> > +      - const: apple,smc
> > +
> > +  reg:
> > +    items:
> > +      - description: SMC area
> > +      - description: SRAM area
> 
> Based on the disjoint addresses, is this really one device? Perhaps
> the SRAM area should use mmio-sram binding? That already supports
> sub-dividing the sram for different uses. I'll comment more on the
> full example.

To me it does look as if the SRAM is part of the SMC coprocessor
block.  It is probably part of a larger SRAM on the side of the SMC
coprocessor.  There is a gap, but the addresses are close.  The only
thing in between is the SMC mailbox, which is represented by a
separate node.

The address of the SRAM can be discovered by sending SMC commands.  I
believe Hector added it in order to verify the address that the SMC
firmware provides.  My OpenBSD driver doesn't use it, so in that sense
changing the binding to use a separate node with a "mmio-sram"
compatible (and presumably an "apple,sram" property to reference that
node using a phandle) would work fine.  The extra level of indirection
obviously would mean more code in the Linux SMC driver though.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux