Hi Geert, > > - /* DMAC can handle 0xffffffff blk count but only 1 segment */ > > - .max_blk_count = 0xffffffff, > > + /* DMAC can handle 32bit blk count but only 1 segment */ > > + .max_blk_count = UINT_MAX / TMIO_MAX_BLK_SIZE, > > I have mixed feelings about this change: > 1. You're lying about the actual maximum (yes, there's a comment that > mentions the real limit), We can't utilize the actual maximum without converting the MMC core to u64. Given that the above max_blk_count is still way beyond any practical value, I am OK with the above. > 2. This fixes the problem in this single (set of) drivers only, while about > every other driver (not the mmc core) calculates > "max_blk_size * max_blk_count", too. I glimpsed, too, and found various patterns. We could maybe add a warning to the MMC core, but other than that I fail to see a way to handle it in a generic way. I'll think about it some more. Or do you have an idea already? > 3. Some drivers use different limits (e.g. 2048, 4095, or 4096), so > eventually having a common upper limit is not easy. I don't understand this one. Which limit do you mean here? blk_size? > BTW, drivers/mmc/host/usdhi6rol0.c does it the other way around: > > mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size; I think we can't do this because of older SDHI instances. max_req_size is still 32 bit for them, but their blk_count register is only 16 bit. Thanks, Wolfram
Attachment:
signature.asc
Description: PGP signature
