[i2c] [PATCH 0/4] i2c: Introduce i2c listeners

Jean Delvare khali at linux-fr.org
Wed Jun 4 23:12:19 CEST 2008


Hi Jon,

On Wed, 4 Jun 2008 14:55:06 -0400, Jon Smirl wrote:
> On 6/4/08, Jean Delvare <khali at linux-fr.org> wrote:
> >  This patch set demonstrates a new concept which I would like to add to
> >  the i2c subsystem. It is named "i2c listeners" and is based on the
> >  following structure:
> 
> How does this fit in with the existing driver bus structure in kernel?

It's outside of the bus structure. The device driver model defines how
drivers bind to the devices they support. It doesn't imply much on how
devices are instantiated. For bus types where the present devices are
enumerated (like PCI) the device instantiation is pretty
straightforward, but in the case of I2C/SMBus where you have to either
know in advance or actively probe and guess which devices are there,
you clearly need additional code and strategy to instantiate the
devices.

That's the very reason why the i2c subsystem didn't originally follow
the device driver model (until David converted it to add support for
the standard model in addition to our custom one.)

> This sounds a lot like hot plug and buses already implement hot plug
> events.  This isn't exactly hot plug but it may be close enough that
> the existing bus APIs will work. Note that both devices and entire
> buses can be hot plugged with existing code.

I don't think it is related to hotplug at all. The issue here is not
whether devices are hotplugged or not. It's also not about how the
drivers are notified about devices and how they bind to them. The issue
is the step before that: how do you find and instantiate the devices if
you have no preliminary knowledge on what devices are present.

Now, if I have really been duplicating a mechanism that exists in the
driver core, I'll be happy to simplify my code to take benefit of it.
But then please point me to the exact piece of code you're thinking
about.

-- 
Jean Delvare



More information about the i2c mailing list