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

["B48286@xxxxxxxxxxxxx" <B48286@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: Mark Brown [mailto:broonie@xxxxxxxxxx]
> Sent: Saturday, March 15, 2014 3:19 AM
> To: Hou Zhiqiang-B48286
> Cc: 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 Fri, Mar 14, 2014 at 05:35:57PM +0800, Hou Zhiqiang wrote:
> > Get the spi_master's bus_num from DTS to make the spi_master's name
> > static. So "mtdparts=spi.bus_num.chip_select:..." in cmdline can be
> > used to asign mtd partions of spi flash.
> 
> If we are going to do this it shouldn't be device specific (it should be
> done in the framework since nothing is specific to the controller there)
> but I'm not convinced that we should be doing it - this is all very Linux
> specific.

This patch just assign a bus number to the controller. It is driver's 
responsibility to distribute a bus number to spi_master and the definition
of bus_num is used to distinguish controllers. So, it is specific for the
controller and doesn't affect the framework. 

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

Thanks,
Zhiqiang
--
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