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 <[email protected]> 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 [email protected]
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |