On Mon, Mar 17, 2014 at 05:11:11AM +0000, B48286@xxxxxxxxxxxxx wrote: > > 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. You are adding a property to specify a bus number. There is no reason why such a property should be specific to a single controller, every controller in every system has a bus number assigned to it so if we have a way to specify one controller via the device tree we should have a way to specify it for all. > > 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.
Attachment:
signature.asc
Description: Digital signature
