Re: Problem loading environment from spi-nor flash partition since barebox 2017.01.0

[Trent Piepho <tpiepho@kymetacorp.com>]

On Wed, 2017-01-11 at 09:32 +0100, Sascha Hauer wrote:
> With (real) SPI this is a little different and works as expected: If the
> qspi node would be handled by the SPI layer then the SPI core would
> register the child nodes as devices on a SPI bus. The normal probe
> mechanism would then bind the device and the driver together.
> 
> With the cadence-quadspi driver a device is registered in
> cqspi_setup_flash(), but there is never a driver attached to it, thus
> the dev->driver test fails.
> 
> The proper way if probably to register the n25q00 device on a qspi bus
> and to provide a qspi-nor-flash driver which gets probed then.
> The not-so-proper, faster way could be to just create a dummy driver
> struct and attach it to the device allocated in cqspi_setup_flash().

The qspi device is more like an MTD device than a SPI master.  It just
supports memory devices, not arbitrary SPI slaves that have their own
drivers.

But that said, there is sort of a driver for the SPI NOR chips attached
to the qspi in spi-nor.c, but it is not a real 'struct driver_d' driver.
Maybe it could be?

qspi could create a "qspi" or "spi-flash" bus (I don't think it will fit
well as a generic SPI bus) with the flash devices on it, and then
spi-nor could bind to them like a normal driver.

Or spi-nor could have a driver_d that's not registered and make
nor->dev->driver point to it in spi_nor_scan().

Or spi_nor_scan() could just set nor->dev->driver =
nor->dev->parent->driver.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox