Re: [RFC][PATCH] SPI subsystem

[Vital <vitalhome@rbcmail.ru>]

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