linux-kernel - Re: [PATCH 08/16] i2c: core: Introduce i2c_get_adapter

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: <Z_UpB1cgU_99JHdF@smile.fi.intel.com>
Date: Tue, 8 Apr 2025 16:47:51 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Peter Rosin <peda@...ntia.se>,
	Derek Kiernan <derek.kiernan@....com>,
	Dragan Cvetic <dragan.cvetic@....com>,
	Arnd Bergmann <arnd@...db.de>, Rob Herring <robh@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Mark Brown <broonie@...nel.org>, Len Brown <lenb@...nel.org>,
	Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Wolfram Sang <wsa@...nel.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
	linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-spi@...r.kernel.org,
	linux-acpi@...r.kernel.org,
	Allan Nielsen <allan.nielsen@...rochip.com>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	Steen Hegelund <steen.hegelund@...rochip.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 08/16] i2c: core: Introduce i2c_get_adapter_supplier()

On Tue, Apr 08, 2025 at 03:08:36PM +0200, Herve Codina wrote:
> On Mon, 7 Apr 2025 18:27:07 +0300
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
> > On Mon, Apr 07, 2025 at 04:55:37PM +0200, Herve Codina wrote:

...

> > > +	return get_device(adapter->supplier ?: adapter->dev.parent);  
> > 
> > What will be the meaning when both are set? Why dev.parent is not the same
> > as supplier in this case?  Looking at the commit message example, it seems
> > like you want to provide a physdev or sysdev (as term supplier seems more
> > devlink:ish), like it's done elsewhere. And in the same way _always_ initialise
> > it. In such a case, the ambiguity will be gone.
> 
> When both are set (this is case for i2c muxes), the adapter->supplier the
> device that register the I2C adapter using i2c_add_adapter() or variant.
> In other word, the device that creates the I2C adapter.
> 
> The adapter->dev.parent is most of the time the device that register the
> I2C adapter except for i2c muxes. For I2C muxes, this adapter->dev.parent
> is the adapter the i2c mux is connected to.
> 
> Between physdev and sysdev, I really prefer physdev and, if renaming from
> supplier to physdev is still needed (and wanted), I will rename it. Let me
> know.

The terms supplier/consumer are widely used in terms of power and devlink.
I think here should not be used the term supplier.

> For initialization, I don't want to modify all the I2C controller drivers.
> What I can do is to initialize adapter->supplier using adapter->dev.parent
> during the i2c_register_adapter() call if it was not already initialize by
> the caller (i.e. the I2C controller driver).

This can be done in the I²C core, but I'm not insisting on this part.
We can start from your function only and then decide later on how to
proceed (depending on how many users of that field appear and what
they want to do with it).

> Does it make sense ?

-- 
With Best Regards,
Andy Shevchenko