Message-ID: <20090731122623.254fd0f1@mjolnir.ossman.eu>
Date:	Fri, 31 Jul 2009 12:26:23 +0200
From:	Pierre Ossman <pierre@...man.eu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	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

This things are currently lingering in my inbox:

[PATCH 1/1] MMC: SDIO card reset support for Intel Moorestown  platform
http://lkml.org/lkml/2009/6/16/269

SDIO cards have a global reset that in theory might be useful. I'm not
sure it is in practice though as it is a very blunt instrument and it
has created some problems in the past.

A PCI equivalent to this reset would be resetting an entire PCI card,
making it and every subfunction fall off the bus and come back again.
The complexity of handling this can be high since every subfunction
needs to be involved.

The patch above adds new callbacks to handle this, but I think it can
proabably be handled as a normal removal/insertion. This reset should
only be used as a last resort anyway.

Lastly, using this reset method might not even be useful. The libertas
guys tried using it to get back a wedged card, but they did not have
much success.

I recommend holding off on this functionality until someone can show
that the added functionality is worth the complexity.

[PATCH 1/2] MMC Agressive clocking framework
http://marc.info/?l=linux-arm-kernel&m=124394660502578&w=2
(and several subsequent versions)

I like this idea and it should be merged. What I didn't like about the
initial versions were that the MMC core was too involved with low level
decisions in drivers. IMO (and the PM guys from what I can tell) the
drivers should automatically do relevant PM stuff, only restricted by
what the MMC core has told the driver should be going on on the bus.

The missing piece here was that the core needed to tell the drivers
when they could turn off the clock on the bus. This can be difficult as
some cards need the clock to drive their internal logic for writes
(although this is in violation of the specs). This means the clock
needs to be left running some time after a request.

There are also a bunch of drivers that tries to do this themselves, and
often without the delay. These should be fixed to leave such decisions
to the core.

[PATCH] mmc: prevent dangling block device from accessing stale queues
http://marc.info/?l=linux-kernel&m=124413857119112

This one is more fun as it requires digging into the block layer. :/

The thread above describes the problem so I'm not going to reiterate it
here. The short summary of why I don't want the patch though is that I
believe it papers over the problem and doesn't solve it. I've been
meaning to look further into the issue, but if someone else has the
time then please go digging.

[PATCH 1/2] atmel-mci: Unified Atmel MCI drivers (AVR32 & AT91)
http://marc.info/?l=linux-arm-kernel&m=124577578729455

This is nice work and it's really up to Nicolas when he wants it merged.

[PATCH] DaVinci: MMC: V5: MMC/SD controller driver for DaVinci family.
(couldn't find an archive)

This driver has undergone some reviews and should be more or less done.
Please check the previous review comments to confirm that everything
has been fixed.

[PATCH] mmc_spi: fail gracefully if host or card do not support the switch command
http://marc.info/?l=linux-kernel&m=124473347118158

This is to work around buggy cards. I'm not convinced the problem is
fully understood yet though so I need to look more at this.

MMC driver for HTC Dream
http://marc.info/?t=124631240200002&r=1&w=2

This is a new driver that needs a review. It seems to make the
classical mistakes, so have a look at my earlier driver reviews to see
what to look for.

[PATCH] MMC Core: Drop initialization frequency floor to 50kHz
http://lkml.org/lkml/2009/7/1/529

The initial patch wasn't very good, but lowering the
speed to 350 kHz should be okay. A new patch is needed and probably
some testing in -next.

[PATCH] MMCI: use AMBA bus accessors
http://marc.info/?t=124689780400003&r=1&w=2
http://marc.info/?t=124689978900001&r=1&w=2
http://marc.info/?t=124689956700005&r=1&w=2
http://marc.info/?t=124689959900002&r=1&w=2

Should probably all be merged.

[PATCH] Add support for debugging MMC channel individually.
http://list.drzeus.cx/pipermail/sdhci-devel/2009-July/002713.html

I agree with Marcel. This kind of fine grained control belongs in
debugfs.

[PATCH] sdio: do not ignore MMC_VDD_165_195
http://marc.info/?t=124764000300001&r=1&w=2

There has already been some discussions around this, and quite
correctly the bit this patch wants to use is undefined.

Restoring back the system state from MMC after a successful hibernation
http://marc.info/?t=124818534700003&r=1&w=2

I don't agree with this approach. The point of the workqueue is so that
the kernel can do things in parallel, so this patch is a step back. The
problem is really with how the kernel doesn't properly cope with
asynchronous disk scanning during bootup. The root_delay parameter was
added for this for the "normal" case, but it seems more work is needed.

move mmci-omap-hs's probe function to .devinit.text
http://marc.info/?t=124734613000001&r=1&w=2

Second patch is probably okay, but the maintainers need to respond.

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


I think that's it, but don't be afraid to search the archives for
anything else that doesn't seem to have been getting any attention.

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)

Powered by blists - more mailing lists