linux-kernel - Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug addon connector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 10 May 2024 16:39:51 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Rob Herring <robh@...nel.org>
Cc: Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Dragan Cvetic
 <dragan.cvetic@....com>, Maxime Ripard <mripard@...nel.org>, Andrzej Hajda
 <andrzej.hajda@...el.com>, Paul Kocialkowski
 <paul.kocialkowski@...tlin.com>, Robert Foss <rfoss@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Jernej Skrabec <jernej.skrabec@...il.com>,
 Hervé Codina <herve.codina@...tlin.com>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>, Derek Kiernan
 <derek.kiernan@....com>, Neil Armstrong <neil.armstrong@...aro.org>,
 Saravana Kannan <saravanak@...gle.com>, David Airlie <airlied@...il.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Paul Kocialkowski
 <contact@...lk.fr>, devicetree@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, Thomas Zimmermann <tzimmermann@...e.de>,
 linux-kernel@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>, Jonas
 Karlman <jonas@...boo.se>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 1/5] dt-bindings: connector: add GE SUNH hotplug
 addon connector

Hello Rob,

On Fri, 10 May 2024 08:22:53 -0500
Rob Herring <robh@...nel.org> wrote:

> On Fri, May 10, 2024 at 5:37 AM Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
> >
> > Hello Rob,
> >
> > On Fri, 10 May 2024 03:41:35 -0500
> > "Rob Herring (Arm)" <robh@...nel.org> 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@...tlin.com>
> > > >
> > > > ---
> > > >
> > > > 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