> -----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@xxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; rob.herring@xxxxxxxxxxx; pawel.moll@xxxxxxx; > mark.rutland@xxxxxxx; ijc+devicetree@xxxxxxxxxxxxxx; galak@xxxxxxxxxxxxxx; > grant.likely@xxxxxxxxxxxx; 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: > > > > > -----Original Message----- > > > From: geert.uytterhoeven@xxxxxxxxx > > > [mailto:geert.uytterhoeven@xxxxxxxxx] > > > On Behalf Of Geert Uytterhoeven > > > Sent: Tuesday, March 18, 2014 4:56 PM > > > To: Hou Zhiqiang-B48286 > > > Cc: Mark Brown; linux-spi@xxxxxxxxxxxxxxx; > > > devicetree@xxxxxxxxxxxxxxx; rob.herring@xxxxxxxxxxx; > > > pawel.moll@xxxxxxx; mark.rutland@xxxxxxx; > > > ijc+devicetree@xxxxxxxxxxxxxx; galak@xxxxxxxxxxxxxx; > > > grant.likely@xxxxxxxxxxxx; 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@xxxxxxxxxxxxx > > > <B48286@xxxxxxxxxxxxx> wrote: > > > >> > > 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)? > > > >> > > Or if it's just picking the correct filesystem then UUIDs and > > > >> > > labels are the standard way to do things. > > > >> > > > >> > 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? > > > >> > > > >> 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. > > > > > > > > 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. > > 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... > ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
