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

[Mark Brown <broonie-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>]

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

> >  > To sumarize, I have a same code that works for the 3 architecture, the
> > > 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

> > 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
> > 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.