PATCH: Config option to pad SDIO sizes

[Dan Williams]

On Fri, 2008-06-27 at 19:39 +0200, Pierre Ossman wrote:
> On Fri, 27 Jun 2008 11:37:53 -0400
> Dan Williams <dcbw at redhat.com> wrote:
> 
> > 
> > Pending a look from Pierre, but I think this would probably _also_ be
> > better as a module parameter rather than a CONFIG option.  Since the
> > addition is done anyway, there shouldn't be a real speed hit.  The
> > problem is that in the general world, we have no idea what hardware
> > you'll be running this on, and it's better to have one kernel that can
> > run on lots of hardware rather than having to flip config options and
> > recompile.  I don't think a module parameter would be an issue in
> > embedded-land either, right?
> > 
> > Pierre, is there a better way to fix the crappy SDIO host controller
> > thing, or is padding in libertas_sdio what we're stuck with?
> > 
> 
> I've been toying with the idea of a sdio_readsb_may_pad(). The problem
> is how to handle memory allocations in a sane manner. Most controllers
> can't do scatter-gather, and it would be wasteful to have bounce so
> many requests. Ideas are welcome.
> 
> I'm not completely against making the libertas driver more friendly to
> broken-beyond-repair controllers. But it's a slippery slope as there
> are so many other restrictions that people will start requesting that
> we respect. I'd like it all in one place at least.
> 
> Perhaps we could do something where there is more chatter back and
> forth between card driver and the host driver. The CD could send the HD
> a query for how much padding is needed before it does any allocations.
> It doesn't handle the alignment issues, but it would be a start.

Sounds like a good start to me; only the HD knows what it's padding
requirements are, and in the unlikely case where there are two different
HDs in the same system with libertas devices attached, there might be
two different padding requirements which each libertas instance would
need to keep track of.

Dan