<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Good question. I have a nvSRAM that I access using the AT25 driver, and I<br>
> don't know how access it without its /sys/bus/ name. If there is another<br>
> way, it is worse to consider it.<br>
<br>
</div>For this I'd expect the application to be able to enumerate all the SPI<br>
devices and offer the user a selection of those with the appropriate<br>
driver bound (though I can see that simple scripts might not have<br>
bothered).<br>
</blockquote></div><br>???<br>I wrote a piece of code that uses this nvSRAM as a persistent storage.<br>This runs in a softcore embedded in an FPGA, in an equipment.<br>The PC version of this application uses a simple file to emulate this behavior.<br>
The simulated version, using an x86 port embedded in a VirtualBox uses a piece of virtual disk with /dev/sdb.<br><br>To sumarize, I have a same code that works for the 3 architecture, the single difference being in the device name:<br>
/sys/proc/spi/drivers/at25/spi0.0/eeprom for Nios2<br>dataBase.dat on Linux<br>/dev/sdb on the Virtual Machine<br><br>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.<br>
Sorry to insist, but this incapacity to set the bus number is a *real* regression (for me).<br><br clear="all">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...<br>
<br>