Hi Ana, On 2026-11-01T07:01:22+11:00, Ana Bobillo <[email protected]> wrote: > mmc: Always use a 512-byte block length > > mmc_startup() sets the block size of the card's block device from the > READ_BL_LEN field of its CSD and only caps it at 512 bytes from above. A > card reporting a READ_BL_LEN below 9, which the SD specification > reserves, gives the block device a block size below 512 bytes. A block > that small cannot hold an MBR or a GPT header, and the partition and > filesystem code assumes at least 512 bytes, as the patch adding > blk_valid_blksz() describes. Nor does the code bound an MMC card's
Two nits, neither worth a resend unless something else comes up. Once applied, 'the patch adding blk_valid_blksz()' won't point anywhere useful. Please can you give the subject of that commit, or drop the reference, since the sentence makes the point without it. > code already did in DDR mode and as Linux does for its transfers; the Please use 'does' here: before this commit the code still behaves this way in DDR mode. > WRITE_BL_LEN from below, though mmc_bwrite() then writes blocks of that > length where the block layer passes 512-byte ones. > > The check in blk_post_probe() does not catch this. It is left out of > SPL, TPL and VPL, which commonly boot from MMC. In U-Boot proper, > mmc_startup() runs again whenever the card is initialised again, by > 'mmc rescan' or 'mmc dev', or after the card-detect poll has seen it > removed, and sets the block size of a block device that is already > probed. > > Use 512-byte blocks whatever READ_BL_LEN and WRITE_BL_LEN say, as the > [...] > > arch/sandbox/include/asm/test.h | 10 ++++++++++ > drivers/mmc/mmc.c | 34 +++++++++++----------------------- > drivers/mmc/sandbox_mmc.c | 11 ++++++++++- > test/dm/mmc.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 71 insertions(+), 24 deletions(-) Reviewed-by: Simon Glass <[email protected]> Regards, Simon
