linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Adrian Hunter <adrian.hunter@nokia.com>
Cc: pierre@ossman.eu, matt@console-pimps.org,
	linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
	nico@cam.org, nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
	tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
	mirq-linux@rere.qmqm.pl, ppisa@pikron.com,
	jarkko.lavinen@nokia.com, ben@fluff.org, saschasommer@freenet.de,
	avorontsov@ru.mvista.com, oakad@yahoo.com, ian@mnementh.co.uk,
	HaraldWelte@viatech.com, JosephChan@via.com.tw
Subject: Re: New MMC maintainer needed
Date: Mon, 3 Aug 2009 14:41:50 -0700	[thread overview]
Message-ID: <20090803144150.82f63ffc.akpm@linux-foundation.org> (raw)
In-Reply-To: <4A76C658.6050002@nokia.com>

On Mon, 03 Aug 2009 14:13:28 +0300
Adrian Hunter <adrian.hunter@nokia.com> wrote:

> Pierre Ossman wrote:
> > On Fri, 31 Jul 2009 11:54:07 +0100
> > Matt Fleming <matt@console-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:
> 
> But the cons are all subjective.
> 
> > 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.

Subjective or not, they are real and valid.

> And the pro is objective.
> 
> > Pro:
> > 
> >  - A slightly reduced scanning time.
> 
> That's great!  Why do you disregard this so easily?

Coz nobody quantified it.  Let's go to the changelog:

: Some hosts can accept only certain types of cards.  For example, an eMMC
: is MMC only and a uSD slot may be SD only.  However the MMC card scanning
: logic checks for all card types one by one.
: 
: Add host capabilities to specify which card types can be used, and amend
: the card scanning logic to skip scanning for those types which cannot be
: used.

See, it provides no reason at all for adding this additional complexity.

Now we're told "it's faster".  OK.  How much faster?  Show us the
numbers so we can all understand why the change is justifiable!

  reply	other threads:[~2009-08-03 21:41 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-14 13:36 New MMC maintainer needed Pierre Ossman
2009-07-14 21:04 ` Ian Molton
2009-07-22 22:17 ` Andrew Morton
2009-07-23  0:08   ` Ian Molton
2009-07-23  5:54     ` Matt Fleming
2009-07-23  6:22       ` Andrew Morton
2009-07-23  6:42         ` Paul Mundt
2009-07-23  6:50         ` Ohad Ben-Cohen
2009-07-23 13:52           ` Matt Fleming
2009-07-24 22:29             ` Andrew Morton
2009-07-27  6:06               ` Philip Langdale
2009-07-27 12:09                 ` David Vrabel
2009-07-27 21:40                   ` Matt Fleming
2009-07-28  0:52                     ` Philip Langdale
2009-07-28 12:51                     ` David Vrabel
2009-07-23  7:01         ` Adrian Hunter
2009-07-23  7:25         ` Stephen Rothwell
2009-07-23  7:32           ` Andrew Morton
2009-07-23  7:38             ` Stephen Rothwell
2009-07-23 16:29               ` Andi Kleen
2009-07-23 10:57       ` Roberto A. Foglietta
2009-07-28 20:22     ` Pierre Ossman
2009-07-30  2:36       ` Segher Boessenkool
2009-07-28 20:20   ` Pierre Ossman
2009-07-28 21:14     ` Ian Molton
2009-07-28 22:41       ` Andrew Morton
2009-07-29  6:35         ` Sam Ravnborg
2009-07-29 10:35         ` Ian Molton
2009-07-28 20:23   ` Pierre Ossman
2009-07-31 10:26     ` Pierre Ossman
2009-07-31 10:54       ` Matt Fleming
2009-08-03 10:34         ` Pierre Ossman
2009-08-03 11:10           ` Matt Fleming
2009-08-03 11:13           ` Adrian Hunter
2009-08-03 21:41             ` Andrew Morton [this message]
2009-08-11 14:02             ` Matt Fleming
2009-08-12 22:27               ` Andrew Morton
2009-08-13  8:21                 ` Matt Fleming
2009-08-13  7:01               ` Adrian Hunter
2009-08-13 17:03                 ` Nicolas Pitre
2009-08-04  1:51       ` David Brownell
2009-08-05  1:42         ` David VomLehn
2009-08-06  8:54         ` Pierre Ossman
2009-08-18  9:33       ` Nicolas Ferre
  -- strict thread matches above, loose matches on Subject: below --
2009-07-15  4:59 Alex Dubov
2009-07-31 13:36 ` Maxim Levitsky
2009-08-01  6:53   ` Alex Dubov
2009-08-01  7:21     ` Maxim Levitsky
2009-08-12 22:52 ellis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090803144150.82f63ffc.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=HaraldWelte@viatech.com \
    --cc=JosephChan@via.com.tw \
    --cc=adrian.hunter@nokia.com \
    --cc=avorontsov@ru.mvista.com \
    --cc=ben@fluff.org \
    --cc=david-b@pacbell.net \
    --cc=hskinnemoen@atmel.com \
    --cc=ian@mnementh.co.uk \
    --cc=jarkko.lavinen@nokia.com \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manuel.lauss@gmail.com \
    --cc=matt@console-pimps.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=nico@cam.org \
    --cc=nicolas.ferre@rfo.atmel.com \
    --cc=oakad@yahoo.com \
    --cc=pierre@ossman.eu \
    --cc=ppisa@pikron.com \
    --cc=saschasommer@freenet.de \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).