(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@xxxxxxxxxxxxxxx> > > > > > > > > [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@xxxxxxxxxxxxxxx/#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@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
