linux-kernel - Re: [PATCH v2 1/6] dt-bindings: gpio: add max77759 binding

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]

Message-ID: <f3db83179b405ca056fd55abdd6c38adaedbaea0.camel@linaro.org>
Date: Thu, 27 Feb 2025 11:19:55 +0000
From: André Draszik <andre.draszik@...aro.org>
To: "Rob Herring (Arm)" <robh@...nel.org>
Cc: "Gustavo A. R. Silva" <gustavoars@...nel.org>,
 devicetree@...r.kernel.org,  Kees Cook <kees@...nel.org>,
 linux-gpio@...r.kernel.org, Srinivas Kandagatla	
 <srinivas.kandagatla@...aro.org>, Tudor Ambarus <tudor.ambarus@...aro.org>,
  Will McVicker <willmcvicker@...gle.com>, Conor Dooley
 <conor+dt@...nel.org>, kernel-team@...roid.com,  Bartosz Golaszewski	
 <brgl@...ev.pl>, linux-hardening@...r.kernel.org,
 linux-kernel@...r.kernel.org,  Lee Jones <lee@...nel.org>, Peter Griffin
 <peter.griffin@...aro.org>, Krzysztof Kozlowski	 <krzk+dt@...nel.org>,
 Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v2 1/6] dt-bindings: gpio: add max77759 binding

On Wed, 2025-02-26 at 14:30 -0600, Rob Herring (Arm) wrote:
> 
> On Wed, 26 Feb 2025 17:51:20 +0000, André Draszik wrote:
> > The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
> > includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
> > Port Controller (TCPC), NVMEM, and a GPIO expander.
> > 
> > This describes its GPIO module.
> > 
> > Signed-off-by: André Draszik <andre.draszik@...aro.org>
> > 
> > ---
> > v2:
> > * drop 'interrupts' property and sort properties alphabetically
> > ---
> >  .../bindings/gpio/maxim,max77759-gpio.yaml         | 44 ++++++++++++++++++++++
> >  MAINTAINERS                                        |  6 +++
> >  2 files changed, 50 insertions(+)
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> 
> 
> doc reference errors (make refcheckdocs):
> Warning: Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml references a file that doesn't exist:
> Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
> Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml: Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
> 
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250226-max77759-mfd-v2-1-a65ebe2bc0a9@linaro.org
> 
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:

'make dt_binding_check' doesn't invoke 'make refcheckdocs', unless
I'm doing something wrong - and therefore 'make dt_binding_check'
doesn't print any warning, contrary to what seems to be implied by
the paragraph above, If I run 'make refcheckdocs', I do get the
error, too, sure enough.

I've never come across refcheckdocs, and it wasn't on my radar.

The error is because the binding's 'description:' references the
mfd binding using the complete path and the mfd binding is added
in a later patch only in this version of the series:

  > ... For additional information, see
  > Documentation/devicetree/bindings/mfd/maxim,max77759.yaml.

the error goes away if a relative path is used instead:

  > ... For additional information, see
  > ../mfd/maxim,max77759.yaml.

I'd like to keep the reference to the mfd binding, and keep
refcheckdocs working as intended (i.e. keep using the full
path), so I'll split the gpio binding patch into two, the first
one without the path and a 2nd one to add the full mfd binding
path, to be applied after the mfd binding. Same for the similar
nvmem binding.

Unless there is a different preference?

Cheers,
Andre'