[PATCH 1/4] dt-bindings: trivial-devices: add traverse,ten64-controller

[Mathew McBride]

(resend as my mail editor defaulted to HTML, oops)
Hello Rob,

On Mon, May 8, 2023, at 12:14 PM, Mathew McBride wrote:
> 
> 
> On Sat, May 6, 2023, at 6:47 AM, Rob Herring wrote:
> > On Tue, May 02, 2023 at 10:02:27AM +0200, Krzysztof Kozlowski wrote:
> > > On 01/05/2023 08:47, Mathew McBride wrote:
> > > > Add the Ten64 family board controller[1] to the trivial devices list.
> > > > 
> > > > Signed-off-by: Mathew McBride <matt at traverse.com.au>
> > > > 
> > > > [1] - https://ten64doc.traverse.com.au/hardware/microcontroller/
> > 
> > Nothing at that link...
> 
> Apologies, we had a DNS issue last week, but it should be OK now.
> 
> If you still can't view it, there is the source to the page here:
> https://gitlab.com/traversetech/ls1088firmware/ten64-user-manual/-/blob/master/docs/hardware/microcontroller.md
> 
> > 
> > > > ---
> > > >  Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> > > > index 246863a9bc7e..638e16fc9f71 100644
> > > > --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> > > > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> > > > @@ -397,6 +397,8 @@ properties:
> > > >            - ti,tps544b25
> > > >            - ti,tps544c20
> > > >            - ti,tps544c25
> > > > +            # Board controller for Ten64 family mainboards
> > > > +          - traverse,ten64-controller
> > > 
> > > This is not a ten64 device, but just component of the SoC, right?
> > > Regular NXP LPC804 Cortex-M0 which you just program with different firmware.
> > > 
> > > Basically this means you describe the firmware in Devicetree...
> > > 
> > > Rob,
> > > 
> > > What are the guidelines for generic co-processors (some Cortex-M)
> > > exposing just I2C line and nothing more? Do we want to describe the
> > > actual firmware running there?
> > 
> > It really depends if the firmware implements a fixed function or varies 
> > frequently. If there's resources exposed in DT dependent on the 
> > firmware, then the binding kind of has to be a binding for the firmware.
> > 
> 
> The firmware implements a fixed set of functions. It's not a general purpose microcontroller intended for arbitrary uses.
> 
> The I/O on the microcontroller is wired to various state and control pins on the CPU and power regulators so it's hardware function is fixed in that regard.
> 
> > DT is the view of hardware as presented to the OS whether the h/w is 
> > implemented in gates or firmware.
> > 
> > Rob
> > 
> > 
Sorry for resurrecting an old submission, but I'm keen to get this particular change upstream.

This is where things left off: https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230501064727.8921-2-matt@traverse.com.au/#3108891

In Documentation/devicetree/bindings/trivial-devices.yaml it says:
"This is a list of trivial I2C and SPI devices that have simple device tree
  bindings, consisting only of a compatible field, an address and possibly an
  interrupt line."

I read that and it sounded like trivial-devices.yaml matched my use case. There are no other properties to expose than "compatible" and "reg". It is simply (for U-Boot's use):
&i2c0 {
    uc: board-controller at 7e {
        compatible = "traverse,ten64-controller";
        reg = <0x7e>;
   };
};

_Maybe_ something like nvmem could bind onto it in the future, but there is no such code in existence today.

If you think a dedicated YAML file is required, I can create "traverse,ten64-controller.yaml" and submit that (most likely under misc/).

Regards,
Matt