<br><br><div class="gmail_quote">2012/2/1 Mark Brown <span dir="ltr"><<a href="mailto:broonie@sirena.org.uk">broonie@sirena.org.uk</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
Well, something that walks all block devices on Linux is very<br></div>
straightforward...  It sounds like you just want logic along the lines<br>
of "find a block device and offer the option of overriding by providing<br>
a specific path for use with a file", is that about right?<br></blockquote><div><br>Well, yes, excepted that the file *is* equivalent to a block device for my piece of code!<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
> Although I tend to agree you on the fact that SPI bus num is a SPI core<br>
> matter, but the fact is that, for now, it is the controller that must fill<br>
> the spi_master structure to call spi_master_get(), and that this structure<br>
> contains a field 'bus_num' that is always initialized to -1 since DTS...<br>
<br>
</div>This sounds like a simple matter of proramming to change.  Clearly<br>
providing a standard feature of the SPI subsystem will involve<br>
modification of the SPI core, for example to change the interpretation<br>
of -1 to go look at the device tree and override it.<br>
</blockquote></div><br>Yes, that seems simple said like that.<br>It was thus more simple for me, at that time, to modify a specific driver for a specific port (Nios2), than to modify a core used by every one. Question of time, and confidence in my own capacities :-).<br>
The other point being the change acceptation (and the time it takes) by the community...<br clear="all"><br>-- <br>Fred<br>