Re: New MMC maintainer needed

From: Pierre Ossman
Date: Mon Aug 03 2009 - 06:34:44 EST


On Fri, 31 Jul 2009 11:54:07 +0100
Matt Fleming <matt@xxxxxxxxxxxxxxxxx> 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.

Attachment: signature.asc
Description: PGP signature