Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Christer Weinigel]

On 05/26/2016 08:47 PM, Mark Brown wrote:
> On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote:
> 
>> One of the main drivers behind devicetree was that Linus got fed 
>> up with the churn for all platform device changes in arch/arm.
>> I faintly recall him writing that he would be rather unhappy if 
>> that just got replaced with churn for devicetree dts files.
> 
> Since device trees are hardware descriptions they really shouldn't 
> be churning at all - if they are that's an indication that we're 
> failing at device tree.

I meant churn from the sheer number of platforms.  According to
gsmarena.com there were over 600 new Android devices released last
year.  Each and every one of them is a Linux platform.  I've
personally worked on *counts on fingers* 8 different custom Linux
platforms during the last year.  That's a lot of new device tree files
if all of them were to end up in the mainline kernel.

My point is that I don't think it would be doable to get every
devicetree file out there into the mainline kernel; it's not even
desirable.  devicetree files for custom platforms are a lot like
userspace applications, the devicetree implementation is an ABI, and
devicetrees for a lot of different platforms are built for that ABI.

Using "the dts file is not in mainline" or "there is no user of that
devicetree feature in mainline" as an argument for breaking existing
dts files is in my opinion not a good argument.  That will be a change
that is visible to userspace (because device names will change).

>> For platforms based on a FPGA such as the Xilinx Zync it's even 
>> more pointless to submit dts files to mainline.  When you have 
>> "hardware" that can be reconfigured the device tree files can't 
>> be set in stone. If I use Xilinx tools [1] to add one more UART
>> I have just added new hardware this needs to be reflected in the 
>> devicetree for the devices to be usable in Linux.  And something 
>> like aliases which provides a stable device name can be very 
>> useful here.
> 
> Right, but it doesn't follow that aliases are what we should be 
> doing here - both Rob and myself have mentioned providing a way to 
> label the actual SPI devices themselves, this seems like a more 
> robust way of doing things.

That would be good.  It would probably be clearer to have
"i2c-sensors" than "i2c3".  But it won't solve all of the issues that
were flagged as bad with aliases.  For example, someone mentioned that
even if aliases worked with devicetree fragments there could be
collisions in the numbering f aliases.  As long as user assigned names
are used there are going to be mistakes and collisions are going to
happen.  Some nut like me will come along and build lots of
temperature sensors and have multiple buses to talk to them, and then
you end up with half a dozen "i2c-sensors" busses :-)

http://zoo.weinigel.se/misc/temp-chain.jpg

These are actually dallas one-wire sensors, but you get the point.

The only way to guarantee uniqueness would be to use uuids or
something inherently unique like bus addresses (where collisions would
break other things anyway) , but then we're back to things not being
that user friendly again.

> Just numbering the buses provides a partial solution for some 
> systems with usability drawbacks (you need to know the number to 
> name mapping somehow), naming devices is both more direct and more 
> general.

Except that being able to assign static bus numbers devicetree is
something that works _now_ and at least for me it is good enough.
Being able to assign bus numbers makes life for me and the colleagues
I have to support a lot easier.  The whole reason I started looking at
assigning bus numbers to spi ports was a very frustrated colleague
complaining about the seemingly random bus number assignment. To be
able to put stickers on the pin headers on a board saying "spi1",
"spi2" and "spi3" and being able to refer to those numbers in in an
email makes things a lot easier.

It would probably be better if some future devicetree extension would
allow abitrary user-friendly naming of devices, but in the absence of
that I'd take numbers every time.  If I'd have to wait for a perfect
solution before doing something I'd never get anything done.  A dumb
and ok solution is often "better" than a complex one.

  /Christer