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: <20090803123429.390a636f@mjolnir.ossman.eu>
Date:	Mon, 3 Aug 2009 12:34:29 +0200
From:	Pierre Ossman <pierre@...man.eu>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	nico@....org, nicolas.ferre@....atmel.com, hskinnemoen@...el.com,
	tony@...mide.com, david-b@...bell.net, manuel.lauss@...il.com,
	mirq-linux@...e.qmqm.pl, ppisa@...ron.com,
	jarkko.lavinen@...ia.com, ben@...ff.org, saschasommer@...enet.de,
	avorontsov@...mvista.com, oakad@...oo.com, ian@...menth.co.uk,
	HaraldWelte@...tech.com, JosephChan@....com.tw,
	adrian.hunter@...ia.com
Subject: Re: New MMC maintainer needed

On Fri, 31 Jul 2009 11:54:07 +0100
Matt Fleming <matt@...sole-pimps.org> wrote:

> On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
> > 
> > [PATCH 0/32] mmc and omap_hsmmc patches
> > http://marc.info/?t=124722953900010&r=1&w=2
> > 
> > I haven't looked through these at all. The ones affecting the core
> > probably need some thorough reviews.
> > 
> > I did notice the patch to say which cards a controller supports though,
> > and I'm very sceptical about that one. The scanning process should work
> > anyway, and the performance impact should be negligible as it is only
> > on init. So that patch only adds complexity and confusion IMO.
> > 
> 
> How much complexity does it really add? Surely it's better to give the
> host controller driver writers the ability to not entertain supporting
> some cards if they cannot be used? If they want to avoid the scanning
> process for certain cards, why not let them?
> 

Let's look at the pros and cons of this:

Con:

 - The scanning code gets less clear as you increase the number of
   possible paths through it.

 - Different systems will have different init sequences, possibly
   provoking bugs in the cards.

 - Host driver writers now have more capability bits they have to
   consider. And these might be less than obvious since SD/MMC/SDIO are
   normally compatible so these bits seem useless.

 - With the current logic (which was better in the first version),
   "normal" drivers will have to explicitly state that they work as
   intended by setting all bits.

Pro:

 - A slightly reduced scanning time.


I simply don't see it as being worth it. Linux patches generally need
to provide the answer to "Why?", not just be able to avoid "Why not?".

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)