linux-kernel - Re: New MMC maintainer needed

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]

Message-id: <alpine.LFD.2.00.0908131249340.10633@xanadu.home>
Date:	Thu, 13 Aug 2009 13:03:56 -0400 (EDT)
From:	Nicolas Pitre <nico@....org>
To:	Adrian Hunter <adrian.hunter@...ia.com>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	Pierre Ossman <pierre@...man.eu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
	"nicolas.ferre@....atmel.com" <nicolas.ferre@....atmel.com>,
	"hskinnemoen@...el.com" <hskinnemoen@...el.com>,
	"tony@...mide.com" <tony@...mide.com>,
	"david-b@...bell.net" <david-b@...bell.net>,
	"manuel.lauss@...il.com" <manuel.lauss@...il.com>,
	"mirq-linux@...e.qmqm.pl" <mirq-linux@...e.qmqm.pl>,
	"ppisa@...ron.com" <ppisa@...ron.com>,
	"Lavinen Jarkko (Nokia-D/Helsinki)" <jarkko.lavinen@...ia.com>,
	"ben@...ff.org" <ben@...ff.org>,
	"saschasommer@...enet.de" <saschasommer@...enet.de>,
	"avorontsov@...mvista.com" <avorontsov@...mvista.com>,
	"oakad@...oo.com" <oakad@...oo.com>,
	"ian@...menth.co.uk" <ian@...menth.co.uk>,
	"HaraldWelte@...tech.com" <HaraldWelte@...tech.com>,
	"JosephChan@....com.tw" <JosephChan@....com.tw>
Subject: Re: New MMC maintainer needed

On Thu, 13 Aug 2009, Adrian Hunter wrote:

> Results in microseconds:
> 
> 	before		after
> eMMC	194145		193641
> uSD	4143		2129
> 
> However, that excludes powering up.  For example the pbias setting
> on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.
> 
> So the difference is negligible.

I therefore tend to agree with Pierre and Andrew.  This doesn't make 
enough of a difference to increase the complexity and maintenance cost 
of the code for such a trivial improvement.

> Although, the notion of unnecessarily sending SDIO commands
> to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
> Especially when trying to debug very-hard-to-reproduce errors.

Simply commenting out the SD/SDIO or MMC probe call in the code is 
very simple when you're debugging.  Then if you actually come to the 
conclusion that some real bugs are due to this cross probe and can prove 
it then we might reconsider.

Currently, generic host drivers are sometimes used in the context of a 
uSD slot, sometimes in the context of a SD/SDIO/MMC slot, sometimes with 
a hardwired SDIO based chip soldered on the board, and they don't need 
any special flags to distinguish between those use cases.  This greatly 
helps maintainability, and that should prevail over slight latency 
improvements to non timing critical events such as card insertion.

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