linux-kernel - Re: [RFC PATCH V2 04/12] dt-bindings: misc: tegra-i2c: config settings

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: <CAL_Jsq+hzbHKeKM9UnJ=VK8_rKs5HJpZRGH2YYWAvjtf9SbPRw@mail.gmail.com>
Date: Wed, 3 Jul 2024 14:21:04 -0600
From: Rob Herring <robh@...nel.org>
To: Thierry Reding <thierry.reding@...il.com>
Cc: 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, jonathanh@...dia.com, 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 V2 04/12] dt-bindings: misc: tegra-i2c: config settings

On Tue, Jul 2, 2024 at 4:29 AM Thierry Reding <thierry.reding@...il.com> wrote:
>
> On Mon, Jul 01, 2024 at 11:42:27AM GMT, Rob Herring wrote:
> > On Mon, Jul 01, 2024 at 08:42:22PM +0530, Krishna Yarlagadda wrote:
> > > I2C interface timing registers are configured using config setting
> > > framework. List available field properties for Tegra I2C controllers.
> >
> > How is I2C bus timing parameters specific to NVIDIA? Just because you
> > have more controls? No. That's no reason to invent a whole new way to
> > specify parameters. Extend what's already there and make it work for
> > anyone.
>
> This may be applicable to a subset of this, and yes, maybe we can find
> generalizations for some of these parameters.
>
> However, we're also looking for feedback specifically on these config
> nodes that go beyond individual timing parameters. For example in the
> case of I2C, how should parameters for different operating modes be
> described?

Like what? It all looks like timing to me.

> Would you agree with something along the lines provided in this series?

When there are multiple users/vendors of it, maybe.

In general, it goes against the DT design of properties for foo go in
foo's node. This looks more like how ACPI does things where it's add
another table for this new thing we need.

Rob