Hello Rob,
On Fri, 10 May 2024 08:22:53 -0500
Rob Herring <robh@xxxxxxxxxx> wrote:
> On Fri, May 10, 2024 at 5:37 AM Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx> wrote:
> >
> > Hello Rob,
> >
> > On Fri, 10 May 2024 03:41:35 -0500
> > "Rob Herring (Arm)" <robh@xxxxxxxxxx> wrote:
> >
> > > On Fri, 10 May 2024 09:10:37 +0200, Luca Ceresoli wrote:
> > > > Add bindings for the GE SUNH add-on connector. This is a physical,
> > > > hot-pluggable connector that allows to attach and detach at runtime an
> > > > add-on adding peripherals on non-discoverable busses.
> > > >
> > > > Signed-off-by: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>
> > > >
> > > > ---
> > > >
> > > > NOTE: the second and third examples fail 'make dt_binding_check' because
> > > > they are example of DT overlay code -- I'm not aware of a way to
> > > > validate overlay examples as of now
> >
> > As mentioned here...
> >
> > > >
> > > > This patch is new in v2.
> > > > ---
> > > > .../connector/ge,sunh-addon-connector.yaml | 197 +++++++++++++++++++++
> > > > MAINTAINERS | 5 +
> > > > 2 files changed, 202 insertions(+)
> > > >
> > >
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > Error: Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.example.dts:49.9-14 syntax error
> > > FATAL ERROR: Unable to parse input tree
> >
> > ...this is expected.
> >
> > Any hints on how this can be managed in bindings examples would be very
> > useful.
>
> Overlays in examples are not supported. Add actual .dtso files if you
> want examples of overlays (maybe you did, shrug).
>
> Overlays are somewhat orthogonal to bindings. Bindings define the ABI.
> It only makes sense to validate applied overlays. Now maybe overlays
> contain complete nodes and we could validate those, but that's a
> problem for actual overlay files and not something we need to
> complicate examples with.
Many thanks for the insights.
The reason I added overlays in the bindings examples is that this
specific device calls for overlays by its very nature. And in fact the
implementation is based on overlays.
However I understand the reasons for not having overlays in examples. I
think I can just remove the two examples and mention the nvmem-cells
and nvmem-cell-names nodes as regular properties, and explain in their
descriptions that these are supposed to be loaded via overlays. Quick
draft:
properties:
nvmem-cell-names:
items:
- const: speed-bin
nvmem-cells:
maxItems: 1
description:
NVMEM cell containing the add-on model ID for the add-on that is
inserted. Multiple add-on models can be connected, and in order
to find out the exact model connected all of them have an EEPROM
at the same I2C bus and address with an ID at the same offset. By
its nature, this and the nvmem-cell-names nodes are supposed to be
added by an overlay once ad add-on is detected. So they must not
be present in the initial device tree, and they must be added by
an overlay before the add-on can be used.
Looks reasonable?
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
