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_Puy8eEBc6tubEx@smile.fi.intel.com>
Date: Mon, 7 Apr 2025 18:27:07 +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 Mon, Apr 07, 2025 at 04:55:37PM +0200, Herve Codina wrote:
> The supplier device of an I2C adapter is the device that calls
> i2c_add_adapter() or variants and i2c_del_adapter().
> 
> Most of the time this supplier device is the parent of the adapter dev.
> 
> Exceptions exist with i2c muxes. Indeed, in case of i2c muxes, the
> parent of the adapter dev points to the adapter dev the mux is connected

dev --> device (in both cases)

> to instead of the supplier of this adapter.
> 
> Introduce i2c_get_adapter_supplier() and a new supplier field in the
> adapter structure in order to ease the adapter supplier retrieval.

...

> +/**
> + * i2c_get_adapter_supplier() - Get the supplier of an adapter
> + * @adapter: the adapter to get the supplier from
> + *
> + * return:

Return:

> + * Look up and return the &struct device corresponding to the device supplying
> + * this adapter.

@adapter

> + * The user must call put_device() once done with the supplier returned.
> + */
> +struct device *i2c_get_adapter_supplier(struct i2c_adapter *adapter)
> +{
> +	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.

> +}

-- 
With Best Regards,
Andy Shevchenko