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

[Frederic LAMBERT]

>
> > I wrote a piece of code that uses this nvSRAM as a persistent storage.
> > This runs in a softcore embedded in an FPGA, in an equipment.
> > The PC version of this application uses a simple file to emulate this
> > behavior.
> > The simulated version, using an x86 port embedded in a VirtualBox uses a
> > piece of virtual disk with /dev/sdb.
>
> So it's just a basic block device?
>

It is the purpose of AT25, yes.


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

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

-- 
Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120201/6ca03c27/attachment-0001.html>