linux-kernel - Re: [RFC PATCH 03/11] soc: tegra: config settings binding document

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] [day] [month] [year] [list]

Date: Fri, 24 May 2024 10:01:42 +0200
From: "Thierry Reding" <thierry.reding@...il.com>
To: "Krzysztof Kozlowski" <krzk@...nel.org>, "Krishna Yarlagadda"
 <kyarlagadda@...dia.com>, <linux-tegra@...r.kernel.org>,
 <devicetree@...r.kernel.org>, <linux-doc@...r.kernel.org>,
 <linux-i2c@...r.kernel.org>, <linux-mmc@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Cc: <jonathanh@...dia.com>, <robh@...nel.org>, <krzk+dt@...nel.org>,
 <conor+dt@...nel.org>, <corbet@....net>, <andi.shyti@...nel.org>,
 <wsa+renesas@...g-engineering.com>, <ulf.hansson@...aro.org>,
 <adrian.hunter@...el.com>, <digetx@...il.com>, <ldewangan@...dia.com>,
 <mkumard@...dia.com>
Subject: Re: [RFC PATCH 03/11] soc: tegra: config settings binding document

On Tue May 7, 2024 at 8:32 AM CEST, Krzysztof Kozlowski wrote:
> On 07/05/2024 00:51, Krishna Yarlagadda wrote:
> > Config framework parses device tree and provides a list of register
> > settings with mask per mode to be applied by the controller.
> > 
> > Add binding document for config settings framework. Config settings
> > are defined as a property per field and have different modes per device.
>
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> > 
> > Signed-off-by: Krishna Yarlagadda <kyarlagadda@...dia.com>
> > ---
> >  .../misc/nvidia,tegra-config-settings.yaml    | 50 +++++++++++++++++++
> >  MAINTAINERS                                   |  1 +
> >  2 files changed, 51 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra-config-settings.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra-config-settings.yaml b/Documentation/devicetree/bindings/misc/nvidia,tegra-config-settings.yaml
> > new file mode 100644
> > index 000000000000..e379cbd5b597
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra-config-settings.yaml
> > @@ -0,0 +1,50 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/misc/nvidia,tegra-config-settings.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Config properties for a device.
>
> No full stop, that's a title.
>
> > +
> > +description:
> > +  Config setting is the configuration based on chip/board/system
> > +  characterization on interface/controller settings. This is needed for
> > +  - making the controller internal configuration to better perform
> > +  - making the interface to work proper by setting drive strength, slew
> > +    rates etc
> > +  - making the low power leakage.
> > +  There are two types of recommended configuration settings
> > +  - Controller register specific for internal operation of controller.
> > +  - Pad control/Pinmux/pincontrol registers for interfacing.
> > +  These configurations can further be categorized as static and dynamic.
> > +  - Static config does not change until a controller is reset.
> > +  - Dynamic config changes based on mode or condition, controller is
> > +    operating in.
> > +
> > +maintainers:
> > +  - Thierry Reding <thierry.reding@...il.com>
> > +
> > +patternProperties:
> > +  "^[a-z0-9_]*$":
> > +    description:
> > +      Config name to be applied on controller.
> > +    type: object
>
> Nope, this means nothing. Sorry, describe hardware, do not create some
> fake nodes.

We're trying to solve a real problem here, though. In order for the
hardware to operate properly we need certain parameters to be programmed
into the hardware.

If this is not acceptable, do you have a suggestion on where else to put
this information?

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)