linux-kernel - Re: [patch 3/4] sdio: extend sdio_readsb() and friends to handle any length of buffer

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:	Wed, 08 Aug 2007 11:19:33 +0100
From:	David Vrabel <david.vrabel@....com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [patch 3/4] sdio: extend sdio_readsb() and friends to handle
 any length of buffer

Pierre Ossman wrote:
> +static int sdio_io_rw_ext_helper(struct sdio_func *func, int write,
> +	unsigned addr, int incr_addr, u8 *buf, unsigned size)
> +{
> +	unsigned remainder = size;
> +	int ret;
> +	unsigned short blksz;
> +	struct mmc_host *host = func->card->host;
> +
> +	if (func->forced_blksz)
> +		blksz = func->forced_blksz;
> +	else {
> +		blksz = func->max_blksz;
> +		if (blksz > host->max_blk_size)
> +			blksz = host->max_blk_size;
> +		if (blksz > 512)
> +			blksz = 512;
> +	}
> +
> +	WARN_ON(blksz > 512);
> +
> +	ret = sdio_set_block_size(func, blksz);
> +	if (ret)
> +		return ret;

We need to know the block size in use /before/ the start of the transfer
as we would like drivers to be able to perform transfers with single
commands as this can result in significantly better performance[1].  The
drivers for our (CSR's) WiFi chips should do this.  This isn't some (as
you suggested in a previous post) 'rare' requirement.

Therefore, we should not change the block size here.

We can also support block sizes > 512 and have this function do the
correct thing (as you'll see when I post my final patches).

David

[1] Consider a chip with a block size of 64 that regularly does short
transfers of between 64 - 128 bytes.  Without padding, this would
require two commands per transfer instead of just one, cutting
performance by 50%!  This scenario could be a WiFi chip doing VoIP.
-- 
David Vrabel, Software Engineer, Drivers group  Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ

.
-
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/