Re: [PATCH 0/5] improve i2c probing

[Mark Underwood <basicmark@yahoo.com>]

Interestingly (we for me at least ;-) I have been
working on an SPI subsystem that was/is a copy of the
I2C subsystem with changes as SPI doesn’t have a
protocol like I2C. I am at the stage of tidying up the
structures in the head files and looking at where they
are used in the core layer.
To me, what I have, like I2C, doesn’t tie in very well
with the new driver model (although I’m not overly
familiar with it, I think I finally understand
platform devices :-). The current I2C core layer seems
to be only registering a bus type and devices so you
can see them in sysfs as none of the functions seem to
do anything.
I wonder how much work the new kernel subsystems can
do for us to cut down the size of i2c-core (and thus
also spi-core).
I guess there is no escaping the fact that I’m going
to gave to do some more homework and study the code.
Any thoughts or insights would be very welcome.

Mark

--- David Brownell <david-b@pacbell.net> wrote:

> Hmm, some of this resembles my prototype from last
> month:
> 
>   
>
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013012.html
> 
> Both ended up with new driver probe() methods
> attaching to *devices* not
> to busses, and used the probe signature the i2c core
> already handles.
> That helps eliminate one of the surprises hitting
> anyone starting to use
> the I2C driver stack.  But not the more fundamental
> one...
> 
> What would you think about actually making I2C
> probing work more like
> standard driver model probing, instead?  That is,
> have the probe method
> signature look like this:
> 
>     int probe(struct i2c_client *dev, void
> *driver_data)
> 
> In normal driver model usage, infrastructure creates
> the devices, and the
> device drivers just bind to them.  But I2C doesn't
> support that even for
> the submodel where it's very appropriate:  devices
> that have been probed,
> or which (as with platform_bus) were explicitly
> declared to exist.
> 
> I2C drivers would either continue the old school way
> ... or could start
> acting more like they do in other mainstream Linux
> driver frameworks.
> 
> - Dave
> 
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com