Hi, On 12 November 2015 at 05:48, Tom Rini <tr...@konsulko.com> wrote: > On Thu, Nov 12, 2015 at 02:42:41PM +0530, Mugunthan V N wrote: >> On Friday 06 November 2015 05:37 PM, Simon Glass wrote: >> > Hi Mugunthan, >> > >> > On 4 November 2015 at 01:16, Mugunthan V N <mugunthan...@ti.com> wrote: >> >> Add compatible for spansion 32MiB spi flash s25fl256s1. >> >> >> >> Signed-off-by: Mugunthan V N <mugunthan...@ti.com> >> >> --- >> >> drivers/mtd/spi/sf_probe.c | 1 + >> >> 1 file changed, 1 insertion(+) >> >> >> >> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c >> >> index c000c53..9cfa9b6 100644 >> >> --- a/drivers/mtd/spi/sf_probe.c >> >> +++ b/drivers/mtd/spi/sf_probe.c >> >> @@ -502,6 +502,7 @@ static const struct dm_spi_flash_ops >> >> spi_flash_std_ops = { >> >> >> >> static const struct udevice_id spi_flash_std_ids[] = { >> >> { .compatible = "spi-flash" }, >> >> + { .compatible = "s25fl256s1" }, >> > >> > Instead, is it possible to add "spi-flash" to the list of compatible >> > strings in your device tree? >> > >> >> The compatible "spi-flash" is not defined/documented in kernel and >> compatible "s25fl256s1" is already documented and present in dt files. >> So it will be good to follow the same dt compatibles in U-Boot so that >> future merge/sync will be easier. > > Agreed.
I see this in kernel upstream at present: git grep s25fl256s1 arch/arm/boot/dts/dra7-evm.dts: compatible = "s25fl256s1"; arch/arm/boot/dts/dra72-evm.dts: compatible = "s25fl256s1"; arch/arm/boot/dts/qcom-ipq8064-ap148.dts: compatible = "s25fl256s1"; arch/powerpc/boot/dts/fsl/kmcoge4.dts: compatible = "spansion,s25fl256s1"; drivers/mtd/devices/m25p80.c: {"s25fl256s1"}, {"s25fl512s"}, {"s25sl12801"}, {"s25fl008k"}, drivers/mtd/devices/st_spi_fsm.c: { "s25fl256s1", 0x010219, 0x4d01, 64 * 1024, 512, drivers/mtd/spi-nor/spi-nor.c: { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, There seems to be some confusion as to whether to include "spansion" or not. I feel it should be included. The problem is that in U-Boot at present this compatible string does not affect any behaviour. We still scan the chip to figure out its type from its ID. Do you want to add a .data value for it, and skip the probing, or are you just trying to trigger the driver to bind? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot