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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ