Message-ID: <20090803111052.GA17501@console-pimps.org>
Date:	Mon, 3 Aug 2009 12:10:52 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Pierre Ossman <pierre@...man.eu>
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 Mon, Aug 03, 2009 at 12:34:29PM +0200, Pierre Ossman wrote:
> 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.
> 

Yes, it does but the function is only small. It's not that much more
complexity. And there's a trade off here between the added complexity
and the shorter initialisation time for cards. Running initialisation
functions on cards that don't need it just seems pointless.

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

Good. I'd like to know about bugs in the cards so that we can fix/work
around any issues. This seems like a pretty weak argument against the
change to me.

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

Yes, but they also have the flexibility to more clearly describe their
host controllers. Besides, any new host controller driver will likely
just copy one of the older drivers (which I updated) anyway.

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

I thought that the way I wrote the patch was more natural (which was why
I rewrote Adrian's to begin with), but if you think the original was
clearer I've no issue with pushing that patch through instead.

> 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?".
> 

That's not at all what I said, I have provided the why (and so have you
by noting the Pro above). 


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

Powered by blists - more mailing lists