[U-Boot] A problem about 'sf probe' using DM_SPI

[Simon Glass]

Hi Qianyu,

On 25 March 2016 at 03:34, Qianyu Gong <qianyu.gong at nxp.com> wrote:
> Hi Simon,
>
>
>
> I think I’m not very clear with this code in common/cmd_sf.c:
>
> “
>
> # ifdef CONFIG_DM_SPI_FLASH
>
>        /* Remove the old device, otherwise probe will just be a nop */
>
>        ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new);
>
>        if (!ret) {
>
>               device_remove(new);
>
>              device_unbind(new);
>
>      }
>
> ”
>
> I may understand the remove but why need to unbind the device?

This is because otherwise 'sf probe' would be a nop if the device
already existed. The spi_flash_probe_bus_cs() call will simply return
the existing device. If something has changed on the bus, it would be
ignored.

>
> The unbind would cause a series of free operations on the device list,
> correct?

Yes

>
>
>
> Then if I probe a flash twice, at the second time the driver model will
> create
>
> a new flash named ‘spi_flash at xx:xx’ using default settings because it
> doesn’t
>
> find such a device in the device list and never probes it from the board’s
> fdt again.

Yes.

>
>
>
> => dm tree
>
> Class       Probed   Name
>
> ----------------------------------------
>
> root        [ + ]    root_driver
>
> simple_bus  [ + ]    `-- soc
>
> spi         [ + ]           |-- dspi at 2100000
>
> spi_flash   [   ]        |    |-- n25q128a
>
> spi_flash   [ + ]        |   |-- spi_flash at 1:1
>
> spi_flash   [ + ]        |   `-- spi_flash at 1:2
>
>
>
> Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn’t
> cause
>
> issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is
> used,
>
> I think it wouldn’t work properly from the second probe.
>
>
>
>
>
> Sorry if there is something wrong with my understandings.
>
> Just because I found my flash’s name was changed to spi-flash at xx:xx in dm
> tree
>
> after several probes, I began to read something about driver model.J

Yes I think removing the unbind would be OK, except that we need a way
to show the messages at the end of spi_flash_scan().

Probably these messages should move out of the uclass and into a
separate call. We could add a function like spi_flash_show(struct
udevice *dev) and call it from do_spi_flash_probe() and perhaps
saveenv().

Regards,
Simon