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

[Scott Wood <scottwood@xxxxxxxxxxxxx>]

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)?

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.

-Scott

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


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html