linux-kernel - Re: sdio: enhance IO_RW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Aug 2007 15:33:33 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	David Vrabel <david.vrabel@....com>
Cc:	linux-kernel@...r.kernel.org, david.vrabel@....com
Subject: Re: sdio: enhance IO_RW_EXTENDED support

On Tue, 07 Aug 2007 13:51:39 +0100
David Vrabel <david.vrabel@....com> wrote:

> 
> In conclusion, the optimum block size is based solely on the card and
> host capabilities and should be limited to at most 512.  Hence the
> block size can (and should) only be set once during card
> initialization.
> 

Well, I can hardly argue with that thorough analysis. :)

I still like the idea of having the control in the core as much as
possible though. It allows people to experiment and figure out new and
clever ways of solving this in a way that can benefit all drivers.

So could we do most of what you propose, where we set the block size to
maximum, yet <= 512. Drivers can tweak this further by calling
sdio_force_block_size() (as need e.g. by my marvell card), and keep the
convention of 0 meaning "back to core default"? That way we can modify
the meaning of "core default" if more clever ways are available.

> > +		if (size <= 512)
> > +			goto byte_remainder;
> 
> The maximum size for a byte mode transfer is the block size set in
> the card.
> 

Right, sorry. It was late when I was hacking on this.

> > +		/* avoid changing blksize needlessly */
> > +		if (func->cur_blksz && ((blksz % func->cur_blksz)
> > == 0))
> > +			blksz = func->cur_blksz;
> 
> If func->blksize == 1024 and we perform transfers in the 512 to 1024
> range, this would set the block size on every transfer.
> 

Quite right. I had no doubts that thing had room for improvement. But I
agree that we might as well select a fixed block size and stick with it
for the general case.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/