On Mon, Apr 27, 2015 at 12:04:12PM +0200, Hans de Goede wrote: > Have you seen my mail about the raspberry pi use-case? Using dt-overlays > simply is not an acceptable answer there. There are legitimate use-cases > for a "generic spi bus" concept with the bus only being accessible via > spidev. > Blocking this use-case because you do not believe it is a valid use-case > is not going to help, this will just lead to the custom distros these > boards are shipping doing some ugly hack, which is not what we want > IMHO. I don't think you've fully considered your use case here. As I said in my reply to your earlier e-mail I think what you're looking for here is something like better UI around overlays. Registering a SPI bus without knowing what's connected to it doesn't allow generic maker style usage of the board, it's just as likely to hinder a user as help them. For example, if someone wants to use the SPI pins for another function such as GPIO they'll have to handle that (and may have problems with pin conflicts causing electrical issues if they do load up the DT with spidev in it). If someone has a SPI device they want to bind an in kernel driver to they'll have to handle that, if they want to use a GPIO to provide an additional chip select they'll have to handle that too. Note that the discussion here isn't about userspace drivers, it's about how the hardware is described.
Attachment:
signature.asc
Description: Digital signature
