Re: [PATCH 08/16] i2c: core: Introduce i2c_get_adapter_supplier()

[Andy Shevchenko]

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@xxxxxxxxxxxxxxx> 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