Re: [RFC PATCH 2/2] mmc: renesas_sdhi: prevent overflow for max_req_size

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]