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 03:53:00PM +0100, Frederic LAMBERT wrote:

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

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

> Why should I have to break that, which work nice, to use a bus enumeration
> which would be specific to the real hardware version, because I'm using a
> new tools, DTS, which is supposed to simplify my life.
> Sorry to insist, but this incapacity to set the bus number is a *real*
> regression (for me).

> I know I could use the name chosen by the kernel (it mus be something like
> /sys/.../spi253.0/...), but I have no control on it. If tomorrow someone
> changes something in the spi bus number definition, a kernel upgrade will
> have an impact on the user stuff...

We went through exactly the same routine whenever people noticed that
the names for disks weren't as stable as people had been assuming, for
example with the SATA transition from IDE to SCSI, with network devices,
and in a few other places too.  Coming up with fixed names for things
that don't depend on implementation details is really rather hard and
tends to break down eventually either due to software changes or due to
newer hardware.

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.