Le 14/04/2016 10:57, Mark Brown a écrit : > On Thu, Apr 14, 2016 at 10:06:55AM +0200, Cyrille Pitchen wrote: > >> I understand but you propose to patch both the SPI layer and the m25p80 driver >> to introduce some support which is already provided by the "spi_flash_read" >> hook: struct spi_flash_read_message has already a "dummy_bytes" field. >> IMHO, it looks redundant. > > My understanding is that this is intended for dummy bits rather than > dummy bytes. > dummy_bits == (dummy_bytes * 8) and dummy_cycles == ((dummy_bytes * 8) / addr_nbits) witch addr_nbits in {1, 2, 4} the struct_flash_read_message has both dummy_bytes and addr_nbits members. The spi-nor framework seems to always provide a multiple of 8 for dummy *bits*. I guess because the m25p80 driver only supports such number of dummy bits but also because all SPI memories can be configured so their number of dummy cycles keeps the byte alignment for the data to follow. It still allows to use less than 8 dummy *cycles*, for instance the factory settings for Macronix Quad SPI memories are: - 4 dummy cycles for Fast Read 1-2-2 (hence 8 dummy bits) - 6 dummy cycles for Fast Read x-4-4 (hence 24 dummy bits) AFAIK, only Micron QSPI memories could be configured so the number of dummy cycles doesn't result in a multiple of 8 bits but theirs are not the recommanded timings provided by the datasheet. Micron factory settings are: - 10 dummy cycles for Fast Read x-4-4 (hence 40 dummy bits) - 8 dummy cycles for other Fast Reads. Best regards, Cyrille -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html