Re: [RFC][PATCH] SPI subsystem

From: Vital
Date: Sat Sep 10 2005 - 16:20:50 EST


Mark Underwood wrote:

Same as for suspend.

And the basic idea anyway looks wrong and not
LDM'ish.
What if your driver

+static struct device_driver spi_adapter_driver = {
+ .name = "spi_adapter",
+ .bus = &spi_bus_type,
+ .probe = spi_adapter_probe,
+ .remove = spi_adapter_remove,
+};

presents also suspend/resume functions (what it
should have done anyway).

Won't it be in a clash with your suspend/resume
technique?



Probably as I said above I don't know enough about
this area yet. Maybe you could help me to do this
correctly?



I guess that it's basically wrong to use platform_device here. My POV is that a specific spi_device structure should be introduced here, just like pcidevice, for instance.

Also:

Can you please specify what is the difference
between 'bus' and 'chip' in your model?



My current terminology is:

spi adapter: A device that sits on an bus (platform,
PCI, USB etc) and is a SPI master and/or slave (I
haven't done any work on the slave part yet).

spi device: A SPI device (e.g. a SPI eeprom) which one
or more of are connected to a spi adapter.



It's not clear to me how the following situation is
handled. Suppose you have two SPI 'busses' with same devices (for
instance, 2 SD card adapters) attached to different busses.



I don't understand your question here. You would have
two instances of a SD card adapter. In sysfs it would
look like:

SD card 0
/sys/devices/platform/spi-0/0-0000

SD card 1
/sys/devices/platform/spi-1/1-0002

As far as the SD card driver is concernedit doesn't
need to know which one its driving or even how many of
them they are. The big advantage of using the LDM.


Not sure if I get you right.
If we suspend bus 0, how does the SD driver get aware of that?

Vitaly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/