Hi all, Le 29/08/2018 à 14:12, Cédric Le Goater a écrit : > [ ... ] > >> Ah, so the whole problem is, the ASpeed 2400 SPI NOR controller does >> memory-mapped read from the flash and that has some limitations when the >> flash is over 16 MiB in size -- it sends 3 byte standard opcodes with 4 >> byte address ? > > yes. > > [ ... ] > >> To simplify the situation, if the ASpeed 2400 SPI NOR controller tried >> reading the SPI flash past 16 MiB, it would also require that the flash >> is in EN4B mode, yes ? > > yes. > > [ ... ] > >>> I start thinking about maybe adding an option to "jedec,spi-nor" DTS >>> binding like "enable-4byte-mode", so that we could get rid of our >>> local patch and just specify that option in the devicetree. The >>> option would force EN4B on the chip if it supports that mode. What do >>> you think? How do I do it if you approve? Send patches separately in >>> here and in the devicetree mailing list or cross-post both patches to >>> both lists? >> >> That's an option. But what I think this is really about is a fact that >> we completely lack any way to negotiate limitations between the SPI NOR >> and the controller. > > what about the hwcaps in spi_nor_scan() ? > Maybe only a matter of taste but I agree with Cedric: a new hwcaps sounds better than a new DT property. There are already different "compatible" strings to make the difference between AST2400 and AST2500, so we can add the new hwcap only to AST2400 entries. Then no need to update any existing device trees, at least in this case. Best regards, Cyille > Thanks, > > C. > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/