Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

On Wed, Feb 01, 2012 at 04:29:25PM +0100, Frederic LAMBERT wrote:

quoted

 > To sumarize, I have a same code that works for the 3 architecture, the

quoted

single difference being in the device name:
/sys/proc/spi/drivers/at25/spi0.0/eeprom for Nios2
dataBase.dat on Linux
/dev/sdb on the Virtual Machine

quoted

In this case surely the mechanisms used to identify regular disks (UUIDs
and so on) will also work (the .dat file will have to be an override,
but otherwise...)?  Names like sdb aren't stable either - they can
change with either software or hardware changes since they just come
from the order of discovery.

Sure there are mechanisms, but that means that the code must be either
specific to the arch, either have the code for all of them. Not simple !

Well, something that walks all block devices on Linux is very
straightforward...  It sounds like you just want logic along the lines
of "find a block device and offer the option of overriding by providing
a specific path for use with a file", is that about right?

The other issue with your patch is that setting a bus number is

quoted

obviously not a device specific thing, it's something that will apply to
any SPI controller on Linux, and so shouldn't be something driver
specific but should instead be a change to the SPI core.

Although I tend to agree you on the fact that SPI bus num is a SPI core
matter, but the fact is that, for now, it is the controller that must fill
the spi_master structure to call spi_master_get(), and that this structure
contains a field 'bus_num' that is always initialized to -1 since DTS...

This sounds like a simple matter of proramming to change.  Clearly
providing a standard feature of the SPI subsystem will involve
modification of the SPI core, for example to change the interpretation
of -1 to go look at the device tree and override it.