Hi Wolfram,
On Fri, Mar 15, 2019 at 9:29 AM Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote:
> > > - /* 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?
No idea, else I would have told you ;-)
> > 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?
Yes, blk_size.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
