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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
