RE: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

-----Original Message-----
From: Wood Scott-B07421
Sent: Wednesday, March 19, 2014 6:09 AM
To: Hou Zhiqiang-B48286
Cc: 'Geert Uytterhoeven'; Mark Brown; linux-spi@vger.kernel.org;
devicetree@vger.kernel.org; rob.herring@calxeda.com; pawel.moll@arm.com;
mark.rutland@arm.com; ijc+devicetree@hellion.org.uk; galak@codeaurora.org;
grant.likely@secretlab.ca; Hu Mingkai-B21284
Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
from DTS

On Tue, 2014-03-18 at 04:34 -0500, Hou Zhiqiang-B48286 wrote:

quoted

quoted

-----Original Message-----
From: geert.uytterhoeven@gmail.com
[mailto:geert.uytterhoeven@gmail.com]
On Behalf Of Geert Uytterhoeven
Sent: Tuesday, March 18, 2014 4:56 PM
To: Hou Zhiqiang-B48286
Cc: Mark Brown; linux-spi@vger.kernel.org;
devicetree@vger.kernel.org; rob.herring@calxeda.com;
pawel.moll@arm.com; mark.rutland@arm.com;
ijc+devicetree@hellion.org.uk; galak@codeaurora.org;
grant.likely@secretlab.ca; Wood Scott-B07421; Hu Mingkai-B21284
Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus
number from DTS

On Tue, Mar 18, 2014 at 8:40 AM, B48286@freescale.com
[off-list ref] wrote:

quoted

quoted

quoted

quoted

The DT already has support for specifying flash layouts,
can't those be used (for example via chosen if they're not
fixed for the

board)?

quoted

quoted

quoted

quoted

Or if it's just picking the correct filesystem then UUIDs and
labels are the standard way to do things.

quoted

The DT specifying flash layouts is ok. There is another way to
make the flash layouts using command line, but it is not safe
because of the dynamic bus_num. It is not the reason that the
way of DT is supported flash layouts, to live the other way

unsafe, right?

quoted

quoted

quoted

quoted

This sounds to me like we need a better way of talking about
flash device names on the Linux command line rather than a way to
fix the bus number - for example, being able to refer to them
using a fixed property like the physical address.  Being able to
refer to devices via an alias assigned in the DT would also be
useful (and more readable), I think there may already be a
mechanism for doing that which would need to be plumbed in but I'm

not 100% sure.

quoted

quoted

quoted

The bus number is the variable designed to distinguish one spi
controller from others. Why spi controller's physical address must
be use instead of bus number?

Because the bus number is dynamic, while the physical address
doesn't change, so it can be used to uniqely identify the device
before booting the kernel.
Cfr. "spi1" vs. "e6e20000.spi".

The precondition of dynamic bus number is initial it with -1 in the
controller driver. But now I need a reasonable bus number, I don't want

a dynamic one.

quoted

Why does use the controller's physical address to take the role of bus
number to distinguish controllers.

Where are you going to get this "reasonable" non-dynamic number from?
How are you going to ensure there are no conflicts with other SPI
controllers (e.g. on a dynamic add-on card)?

"other than negative (== assign one dynamically), bus_num is fully
board-specific.  usually that simplifies to being SOC-specific.
example:  one SOC has three SPI controllers, numbered 0..2,
and one board's schematics might show it using SPI-2.  software
would normally use bus_num=2 for that controller."
The above paragraph is description of bus_num in spi.h. The "reasonable"
is from it.
Other controllers should also include this property, otherwise it will be
dynamic. So there is not conflict.

Physical addresses work well because they are tied to something real,
rather than an arbitrary enumeration.  Our NAND controllers use the
physical address for the MTD name.  Device tree NOR flash allows the
device tree to set the mtd name[1], and otherwise falls back on the
platform device name, which contains the physical address.

I know the physical work well, but there is a mechanism of bus number.
As the description say above, isn't it reasonable?
 

-Scott

[1] This violates the "device tree describes hardware rather than
configures Linux" rule...

��칻
�&�~�&���+-��ݶ��w��˛���m�b��l�(����ܨ}���Ơz�&j:+v����n�r��6;靫3��\
nnX��f�z��2�ޙ���&�)ߡ�a����
�G���h��j:+v���w�٥