New MMC maintainer needed

New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

I'm afraid the time has come for me to step down as maintainer for the
MMC/SD/SDIO subsystem and for someone else to take over the rudder. It
is no secret that I haven't been able to give the maintainer role the
resources it required, and as a result it has gone from being a fun
hobby to a burdensome chore. I was hoping it was a temporary slump, but
this has been the norm for over a year now, so it's time for me to
throw in the towel.

I don't have any clear nominees for a replacement, but if you feel that
you are in a position to take over the maintainer role then please
raise your hand.

I only have a few patches in my queue right now and I can push those
off to Linus before I quit. There are however a lot of unhandled
messages that need attention. I can provide a list once a successor has
been named.

I realise that you have put a lot of time and effort into the patches
you send me and I am truly sorry that I haven't been able to handle
them better. Hopefully me stepping down means that we get someone who
can actually take care of everything in a timely manner.

I haven't decided what to do with the sdhci maintainership yet. Right
now I only know I need a break and freeing myself from the MMC
maintainer role is the first step. Hopefully I can return as a
developer in the future.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

I'm afraid the time has come for me to step down as maintainer for the
MMC/SD/SDIO subsystem and for someone else to take over the rudder. It
is no secret that I haven't been able to give the maintainer role the
resources it required, and as a result it has gone from being a fun
hobby to a burdensome chore. I was hoping it was a temporary slump, but
this has been the norm for over a year now, so it's time for me to
throw in the towel.

I don't have any clear nominees for a replacement, but if you feel that
you are in a position to take over the maintainer role then please
raise your hand.

I only have a few patches in my queue right now and I can push those
off to Linus before I quit. There are however a lot of unhandled
messages that need attention. I can provide a list once a successor has
been named.

I realise that you have put a lot of time and effort into the patches
you send me and I am truly sorry that I haven't been able to handle
them better. Hopefully me stepping down means that we get someone who
can actually take care of everything in a timely manner.

I haven't decided what to do with the sdhci maintainership yet. Right
now I only know I need a break and freeing myself from the MMC
maintainer role is the first step. Hopefully I can return as a
developer in the future.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Ian Molton]

Pierre Ossman wrote:
> I'm afraid the time has come for me to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the rudder.

Thank you for your time and effort on this subsystem.

I havent done anything 'deep' in MMC for some time (since my initial SD 
mem card support), so I dont feel qualified to step up. Hopefully we'll 
find someone suitable.

Re: New MMC maintainer needed

[Andrew Morton]

On Tue, 14 Jul 2009 15:36:01 +0200
Pierre Ossman <pierre@ossman.eu> wrote:

> I'm afraid the time has come for me to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the rudder. It
> is no secret that I haven't been able to give the maintainer role the
> resources it required, and as a result it has gone from being a fun
> hobby to a burdensome chore. I was hoping it was a temporary slump, but
> this has been the norm for over a year now, so it's time for me to
> throw in the towel.
> 
> I don't have any clear nominees for a replacement, but if you feel that
> you are in a position to take over the maintainer role then please
> raise your hand.
> 
> I only have a few patches in my queue right now and I can push those
> off to Linus before I quit. There are however a lot of unhandled
> messages that need attention. I can provide a list once a successor has
> been named.
> 
> I realise that you have put a lot of time and effort into the patches
> you send me and I am truly sorry that I haven't been able to handle
> them better. Hopefully me stepping down means that we get someone who
> can actually take care of everything in a timely manner.
> 
> I haven't decided what to do with the sdhci maintainership yet. Right
> now I only know I need a break and freeing myself from the MMC
> maintainer role is the first step. Hopefully I can return as a
> developer in the future.
> 

Thanks, Pierre.

Until and unless someone else steps up I can act as maintainer of last
resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
gpio, i2o and about 1000 other identifiable subsystems.

Fortunately, MMC doesn't appear to have its own mailing list so I'll
actually get to see the patches.  I do monitor a couple of
subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a
month or two.


When it comes to subsystems about which I have little knowledge I tend
to work as follows:

- scan the patch to see if anything stands out to my inexperienced eye

- if possible, comment on it to make a bit of noise and to let the
  submitter and others know that a) someone has looked at it and b)
  there's a chance that it'll be merged.

- try to identify some people who might have an interest in the patch
  and/or who might have related experience which would help them review
  this one effectively.

So if someone finds themselves cc'ed on an MMC email from myself,
please do take a bit of time to pass an eye across it, and let us know
that you have done so - it really helps.

Re: New MMC maintainer needed

[Ian Molton]

Andrew Morton wrote:

> Until and unless someone else steps up I can act as maintainer of last
> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
> gpio, i2o and about 1000 other identifiable subsystems.

If no-one else is helping out, Im happy to also be CC'd on MMC patches. 
I've been out of the loop, as I mentioned, but I dont mind helping out.

I'm currently helping someone bring a PCI based TMIO type device online 
via email.

Pierre - do you have a bunch of MMC spec-type docs around? I've lost all 
but the few sparse datasheets for TMIO that I had, so some docs covering 
protocol / commands would be useful. Any references / downloads that you 
know of?

Re: New MMC maintainer needed

[Matt Fleming]

On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> Andrew Morton wrote:
>
>> Until and unless someone else steps up I can act as maintainer of last
>> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
>> gpio, i2o and about 1000 other identifiable subsystems.
>
> If no-one else is helping out, Im happy to also be CC'd on MMC patches.
>

Ditto.

Re: New MMC maintainer needed

[Andrew Morton]

On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:

> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> > Andrew Morton wrote:
> >
> >> Until and unless someone else steps up I can act as maintainer of last
> >> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
> >> gpio, i2o and about 1000 other identifiable subsystems.
> >
> > If no-one else is helping out, Im happy to also be CC'd on MMC patches.
> >
> 
> Ditto.

Thanks, guys.

I actually already have a little pile of MMC things queued:

http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch

I guess we own them now ;)

Re: New MMC maintainer needed

[Paul Mundt]

On Wed, Jul 22, 2009 at 11:22:59PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:
> 
> > On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> > > Andrew Morton wrote:
> > >
> > >> Until and unless someone else steps up I can act as maintainer of last
> > >> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
> > >> gpio, i2o and about 1000 other identifiable subsystems.
> > >
> > > If no-one else is helping out, Im happy to also be CC'd on MMC patches.
> > >
> > 
> > Ditto.
> 
> Thanks, guys.
> 
> I actually already have a little pile of MMC things queued:
> 
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
> 
> I guess we own them now ;)

While you're in MMC collection mode:

	http://lkml.org/lkml/2009/7/17/75

wants to be queued, too. Presumably Ian will get to it at some point,
though.

Re: New MMC maintainer needed

[Ohad Ben-Cohen]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Hi Andrew,

On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<akpm@linux-foundation.org> wrote:
> I actually already have a little pile of MMC things queued:

Please also consider queuing up the attached patch as well.

The patch is removing the current SDIO cards 1.8V limit, which is
needed for embedded
SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
have on the ZOOM2 boards for example).

Thank you,
Ohad.

[-- Attachment #2: 0001-sdio-do-not-ignore-MMC_VDD_165_195.patch --]
[-- Type: text/x-diff, Size: 1014 bytes --]

From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@bencohen.org>
Date: Wed, 15 Jul 2009 09:21:41 +0300
Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195

This is needed for 1.8V embedded SDIO devices and supporting host controllers
(e.g. TI 127x and ZOOM2 boards)

Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
---
 drivers/mmc/core/sdio.c |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..6f221dc 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
 		ocr &= ~0x7F;
 	}
 
-	if (ocr & MMC_VDD_165_195) {
-		printk(KERN_WARNING "%s: SDIO card claims to support the "
-		       "incompletely defined 'low voltage range'. This "
-		       "will be ignored.\n", mmc_hostname(host));
-		ocr &= ~MMC_VDD_165_195;
-	}
-
 	host->ocr = mmc_select_voltage(host, ocr);
 
 	/*
-- 
1.5.4.3

Re: New MMC maintainer needed

[Adrian Hunter]

Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:
> 
>> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
>>> Andrew Morton wrote:
>>>
>>>> Until and unless someone else steps up I can act as maintainer of last
>>>> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
>>>> gpio, i2o and about 1000 other identifiable subsystems.
>>> If no-one else is helping out, Im happy to also be CC'd on MMC patches.
>>>
>> Ditto.
> 
> Thanks, guys.
> 
> I actually already have a little pile of MMC things queued:
> 
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
> 
> I guess we own them now ;)
> 

There are also 32 patches starting here:

http://marc.info/?l=linux-kernel&m=124722949501844&w=2

Re: New MMC maintainer needed

[Adrian Hunter]

Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:
> 
>> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
>>> Andrew Morton wrote:
>>>
>>>> Until and unless someone else steps up I can act as maintainer of last
>>>> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
>>>> gpio, i2o and about 1000 other identifiable subsystems.
>>> If no-one else is helping out, Im happy to also be CC'd on MMC patches.
>>>
>> Ditto.
> 
> Thanks, guys.
> 
> I actually already have a little pile of MMC things queued:
> 
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
> 
> I guess we own them now ;)
> 

There are also 32 patches starting here:

http://marc.info/?l=linux-kernel&m=124722949501844&w=2

Re: New MMC maintainer needed

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Hi Andrew,

On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I actually already have a little pile of MMC things queued:
> 
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
> 
> I guess we own them now ;)

So how about, as an experiment, you put all those (at least those that are
"stable") into a git tree (or quilt series) based on Linus' tree and I
could replace the current linux-next mmc tree (which is empty) with that.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: New MMC maintainer needed

[Andrew Morton]

On Thu, 23 Jul 2009 17:25:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > I actually already have a little pile of MMC things queued:
> > 
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
> > 
> > I guess we own them now ;)
> 
> So how about, as an experiment, you put all those (at least those that are
> "stable") into a git tree (or quilt series) based on Linus' tree and I
> could replace the current linux-next mmc tree (which is empty) with that.
> 

I haven't worked out how to do that yet :( (Well, I have, but it's all
complex).

It gets easy if I remove linux-next.patch from -mm.  Maybe I'll do that.

Re: New MMC maintainer needed

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

Hi Andrew,

On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> It gets easy if I remove linux-next.patch from -mm.  Maybe I'll do that.

At that point we could add the "stable" part of -mm to linux-next :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: New MMC maintainer needed

[Roberto A. Foglietta]

2009/7/23, Matt Fleming <matt@console-pimps.org>:
> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
>  > Andrew Morton wrote:
>  >
>  >> Until and unless someone else steps up I can act as maintainer of last
>  >> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
>  >> gpio, i2o and about 1000 other identifiable subsystems.
>  >
>  > If no-one else is helping out, Im happy to also be CC'd on MMC patches.
>  >
>

I am new in maintaining a kernel driver into community but I would help.

-- 
Roberto A. Foglietta,
Linux Embedded Consultant
mobile: (+39) 349.33.30.697

Re: New MMC maintainer needed

[Matt Fleming]

On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> Hi Andrew,
> 
> On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<akpm@linux-foundation.org> wrote:
> > I actually already have a little pile of MMC things queued:
> 
> Please also consider queuing up the attached patch as well.
> 
> The patch is removing the current SDIO cards 1.8V limit, which is
> needed for embedded
> SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
> have on the ZOOM2 boards for example).
> 
> Thank you,
> Ohad.

> From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
> From: Ohad Ben-Cohen <ohad@bencohen.org>
> Date: Wed, 15 Jul 2009 09:21:41 +0300
> Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
> 
> This is needed for 1.8V embedded SDIO devices and supporting host controllers
> (e.g. TI 127x and ZOOM2 boards)
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> ---
>  drivers/mmc/core/sdio.c |    7 -------
>  1 files changed, 0 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index fb99ccf..6f221dc 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
>  		ocr &= ~0x7F;
>  	}
>  
> -	if (ocr & MMC_VDD_165_195) {
> -		printk(KERN_WARNING "%s: SDIO card claims to support the "
> -		       "incompletely defined 'low voltage range'. This "
> -		       "will be ignored.\n", mmc_hostname(host));
> -		ocr &= ~MMC_VDD_165_195;
> -	}
> -
>  	host->ocr = mmc_select_voltage(host, ocr);
>  
>  	/*
> -- 
> 1.5.4.3
> 

Looks OK to me, I'm unaware of a reason to not allow a card to use
MMC_VDD_165_195 if that's what it wants.

Acked-by: Matt Fleming <matt@console-pimps.org>

Re: New MMC maintainer needed

[Andi Kleen]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Andrew,
>
> On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> It gets easy if I remove linux-next.patch from -mm.  Maybe I'll do that.
>
> At that point we could add the "stable" part of -mm to linux-next :-)

I think that would be a great idea. It always bugged me that
if Andrew pulls something in it's not automatically tested in -next.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: New MMC maintainer needed

[Andrew Morton]

On Thu, 23 Jul 2009 14:52:09 +0100
Matt Fleming <matt@console-pimps.org> wrote:

> On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> > Hi Andrew,
> > 
> > On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<akpm@linux-foundation.org> wrote:
> > > I actually already have a little pile of MMC things queued:
> > 
> > Please also consider queuing up the attached patch as well.
> > 
> > The patch is removing the current SDIO cards 1.8V limit, which is
> > needed for embedded
> > SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
> > have on the ZOOM2 boards for example).
> > 
> > Thank you,
> > Ohad.
> 
> > From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
> > From: Ohad Ben-Cohen <ohad@bencohen.org>
> > Date: Wed, 15 Jul 2009 09:21:41 +0300
> > Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
> > 
> > This is needed for 1.8V embedded SDIO devices and supporting host controllers
> > (e.g. TI 127x and ZOOM2 boards)
> > 
> > Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> > ---
> >  drivers/mmc/core/sdio.c |    7 -------
> >  1 files changed, 0 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> > index fb99ccf..6f221dc 100644
> > --- a/drivers/mmc/core/sdio.c
> > +++ b/drivers/mmc/core/sdio.c
> > @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
> >  		ocr &= ~0x7F;
> >  	}
> >  
> > -	if (ocr & MMC_VDD_165_195) {
> > -		printk(KERN_WARNING "%s: SDIO card claims to support the "
> > -		       "incompletely defined 'low voltage range'. This "
> > -		       "will be ignored.\n", mmc_hostname(host));
> > -		ocr &= ~MMC_VDD_165_195;
> > -	}
> > -
> >  	host->ocr = mmc_select_voltage(host, ocr);
> >  
> >  	/*
> > -- 
> > 1.5.4.3
> > 
> 
> Looks OK to me, I'm unaware of a reason to not allow a card to use
> MMC_VDD_165_195 if that's what it wants.
> 

Yes, that code was there from day #1, via Pierre's original commit.  There
is no indication in either the code comments or the changelog why it was done
this way.

Other ways of finding out why this code is there include:

a) search the mailing list for review discussion.  I can't find it
   in my lkml archive.

b) ask Pierre :)

Re: New MMC maintainer needed

[Philip Langdale]

On Fri, 24 Jul 2009 15:29:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 23 Jul 2009 14:52:09 +0100
> Matt Fleming <matt@console-pimps.org> wrote:
> 
> > On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> > > Hi Andrew,
> > > 
> > > On Thu, Jul 23, 2009 at 9:22 AM, Andrew
> > > Morton<akpm@linux-foundation.org> wrote:
> > > > I actually already have a little pile of MMC things queued:
> > > 
> > > Please also consider queuing up the attached patch as well.
> > > 
> > > The patch is removing the current SDIO cards 1.8V limit, which is
> > > needed for embedded
> > > SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers
> > > like we have on the ZOOM2 boards for example).
> > > 
> > > Thank you,
> > > Ohad.
> > 
> > > From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00
> > > 2001 From: Ohad Ben-Cohen <ohad@bencohen.org>
> > > Date: Wed, 15 Jul 2009 09:21:41 +0300
> > > Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
> > > 
> > > This is needed for 1.8V embedded SDIO devices and supporting host
> > > controllers (e.g. TI 127x and ZOOM2 boards)
> > > 
> > > Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> > > ---
> > >  drivers/mmc/core/sdio.c |    7 -------
> > >  1 files changed, 0 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> > > index fb99ccf..6f221dc 100644
> > > --- a/drivers/mmc/core/sdio.c
> > > +++ b/drivers/mmc/core/sdio.c
> > > @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host,
> > > u32 ocr) ocr &= ~0x7F;
> > >  	}
> > >  
> > > -	if (ocr & MMC_VDD_165_195) {
> > > -		printk(KERN_WARNING "%s: SDIO card claims to
> > > support the "
> > > -		       "incompletely defined 'low voltage
> > > range'. This "
> > > -		       "will be ignored.\n", mmc_hostname(host));
> > > -		ocr &= ~MMC_VDD_165_195;
> > > -	}
> > > -
> > >  	host->ocr = mmc_select_voltage(host, ocr);
> > >  
> > >  	/*
> > > -- 
> > > 1.5.4.3
> > > 
> > 
> > Looks OK to me, I'm unaware of a reason to not allow a card to use
> > MMC_VDD_165_195 if that's what it wants.
> > 
> 
> Yes, that code was there from day #1, via Pierre's original commit.
> There is no indication in either the code comments or the changelog
> why it was done this way.
> 
> Other ways of finding out why this code is there include:
> 
> a) search the mailing list for review discussion.  I can't find it
>    in my lkml archive.
> 
> b) ask Pierre :)

Both the (Simplified) SD and SDIO specifications do not formally define
the 'low voltage' range in the way the MMC spec does. ie: You won't
find anything in the SD specs that even tell you what the range is -
it just says that it exists.

So we (I wrote the first incarnation of this check for normal SD cards)
decided to bail if a card requested the low voltage range. Now, if
there's actually hardware out there that is SD/SDIO and operates at
1.8V, we should probably do something more appropriate. :-)

It's obviously an easy change but I'd feel a lot more comfortable if
someone can point us to a document that states that the SD/SDIO low
voltage range is defined to match the MMC one. Maybe one of the NDA
docs actually states this.

Andrew - I'm also willing to be cc'ed on MMC changes and I'll respond
to the best of my (limited) abilities.

--phil

Re: New MMC maintainer needed

[David Vrabel]

Philip Langdale wrote:
> 
> Both the (Simplified) SD and SDIO specifications do not formally
> define the 'low voltage' range in the way the MMC spec does. ie: You
> won't find anything in the SD specs that even tell you what the range
> is - it just says that it exists.

Standard SD/SDIO cards only support 2.7-3.6V.

1.8V operation is added in SD physical spec 3.00 and is part of any of
the UHS-1 modes (SDR12-SDR104 and DDR50).  It has a different timings
and requires a different (3.00 compliant) host controller.

> So we (I wrote the first incarnation of this check for normal SD
> cards) decided to bail if a card requested the low voltage range.
> Now, if there's actually hardware out there that is SD/SDIO and
> operates at 1.8V, we should probably do something more appropriate.
> :-)

The SD/SDIO stack must ignore reserved bits unless a per-card quirk
gives an additional meaning to the reserved bit.

> It's obviously an easy change but I'd feel a lot more comfortable if 
> someone can point us to a document that states that the SD/SDIO low 
> voltage range is defined to match the MMC one. Maybe one of the NDA 
> docs actually states this.

The non-simplified documents don't say anything on this.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/


'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'

Re: New MMC maintainer needed

[Matt Fleming]

On Mon, Jul 27, 2009 at 01:09:47PM +0100, David Vrabel wrote:
> Philip Langdale wrote:
> > 
> > Both the (Simplified) SD and SDIO specifications do not formally
> > define the 'low voltage' range in the way the MMC spec does. ie: You
> > won't find anything in the SD specs that even tell you what the range
> > is - it just says that it exists.
> 
> Standard SD/SDIO cards only support 2.7-3.6V.
> 
> 1.8V operation is added in SD physical spec 3.00 and is part of any of
> the UHS-1 modes (SDR12-SDR104 and DDR50).  It has a different timings
> and requires a different (3.00 compliant) host controller.

Is the 3.00 spec publicly available?

Re: New MMC maintainer needed

[Philip Langdale]

On Mon, 27 Jul 2009 22:40:01 +0100
Matt Fleming <matt@console-pimps.org> wrote:

> On Mon, Jul 27, 2009 at 01:09:47PM +0100, David Vrabel wrote:
> > Philip Langdale wrote:
> > > 
> > > Both the (Simplified) SD and SDIO specifications do not formally
> > > define the 'low voltage' range in the way the MMC spec does. ie:
> > > You won't find anything in the SD specs that even tell you what
> > > the range is - it just says that it exists.
> > 
> > Standard SD/SDIO cards only support 2.7-3.6V.
> > 
> > 1.8V operation is added in SD physical spec 3.00 and is part of any
> > of the UHS-1 modes (SDR12-SDR104 and DDR50).  It has a different
> > timings and requires a different (3.00 compliant) host controller.
> 
> Is the 3.00 spec publicly available?
> 

Indeed! If the 1.8V operations have conformance requirements beyond
those of MMCplus/MMCmobile, then we can't just remove the current
test as proposed. I've been checking the sdcard.org site periodically
for new specs and haven't seen anything yet.

--phil

Re: New MMC maintainer needed

[David Vrabel]

Matt Fleming wrote:
> 
> Is the 3.00 spec publicly available?

There does not appear to be a simplified version of the 3.00 specification.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/


'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'

Re: New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

On Wed, 22 Jul 2009 15:17:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> 
> Thanks, Pierre.
> 
> Until and unless someone else steps up I can act as maintainer of last
> resort for MMC.  As I'm presently doing for fbdev, hwmon, rtc, spi,
> gpio, i2o and about 1000 other identifiable subsystems.
> 

I'm not falling of the face of the earth here, so people can still cc
me on MMC patches, although I probably cannot answer all of them. I
don't want to be the bottle neck that keeps MMC patches and discussions
moving at a glacial speed, which is the situation we're in today.

> Fortunately, MMC doesn't appear to have its own mailing list so I'll
> actually get to see the patches.  I do monitor a couple of
> subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a
> month or two.

MMC discussions tend to often be very system specific, which makes
lists such as the arm kernel list more appropriate. Also, I've always
tried to steer people to LKML as it allows others to keep a casual eye
on things.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Thu, 23 Jul 2009 01:08:08 +0100
Ian Molton <ian@mnementh.co.uk> wrote:

> Pierre - do you have a bunch of MMC spec-type docs around? I've lost all 
> but the few sparse datasheets for TMIO that I had, so some docs covering 
> protocol / commands would be useful. Any references / downloads that you 
> know of?

I use the public specs from sdcard.org for more or less everything. I
also have a MMC 4 spec, which was generously donated to me by Nokia.
Unfortunately I am not allowed to pass that on. I can look things up
for people if they have specific questions though.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

I'll try to compose a list of outstanding discussions and patches so
that people know what needs attention. I'll try to get that done in the
next few days.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Ian Molton]

Pierre Ossman wrote:

> MMC discussions tend to often be very system specific, which makes
> lists such as the arm kernel list more appropriate. Also, I've always
> tried to steer people to LKML as it allows others to keep a casual eye
> on things.

I think an MMC list wouldnt be a bad idea now that we have a sort of 
'distributed maintainership' thing going on... itd help get people up to 
speed...

Re: New MMC maintainer needed

[Andrew Morton]

On Tue, 28 Jul 2009 22:14:40 +0100
Ian Molton <ian@mnementh.co.uk> wrote:

> Pierre Ossman wrote:
> 
> > MMC discussions tend to often be very system specific, which makes
> > lists such as the arm kernel list more appropriate. Also, I've always
> > tried to steer people to LKML as it allows others to keep a casual eye
> > on things.
> 
> I think an MMC list wouldnt be a bad idea now that we have a sort of 
> 'distributed maintainership' thing going on... itd help get people up to 
> speed...

I expect that Dave Miller can set up linux-mmc@vger.kernel.org in a
jiffy.  A MAINTAINERS patch should be made if this is done.

What I am unsure about is whether and how web-based archives of the vger
lists come into being - is it automatic, or should people be asked?

Re: New MMC maintainer needed

[Sam Ravnborg]

On Tue, Jul 28, 2009 at 03:41:37PM -0700, Andrew Morton wrote:
> On Tue, 28 Jul 2009 22:14:40 +0100
> Ian Molton <ian@mnementh.co.uk> wrote:
> 
> > Pierre Ossman wrote:
> > 
> > > MMC discussions tend to often be very system specific, which makes
> > > lists such as the arm kernel list more appropriate. Also, I've always
> > > tried to steer people to LKML as it allows others to keep a casual eye
> > > on things.
> > 
> > I think an MMC list wouldnt be a bad idea now that we have a sort of 
> > 'distributed maintainership' thing going on... itd help get people up to 
> > speed...
> 
> I expect that Dave Miller can set up linux-mmc@vger.kernel.org in a
> jiffy.  A MAINTAINERS patch should be made if this is done.
> 
> What I am unsure about is whether and how web-based archives of the vger
> lists come into being - is it automatic, or should people be asked?

It was a manual process when I had linux-kbuild created.
I contacted marc and one other place I do not recall right now.

	Sam

Re: New MMC maintainer needed

[Ian Molton]

Andrew Morton wrote:

> I expect that Dave Miller can set up linux-mmc@vger.kernel.org in a
> jiffy.  A MAINTAINERS patch should be made if this is done.

I've sent him an email, will let you all know what happens.

Re: New MMC maintainer needed

[Segher Boessenkool]

> I use the public specs from sdcard.org for more or less everything. I
> also have a MMC 4 spec, which was generously donated to me by Nokia.
> Unfortunately I am not allowed to pass that on. I can look things up
> for people if they have specific questions though.

The MMC Association has merged with JEDEC, so now everyone can download
the specs, e.g. http://www.jedec.org/download/search/JESD84-A44.pdf .


Segher

Re: New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 5949 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Matt Fleming]

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?

Re: New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

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:

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Matt Fleming]

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@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:
> 
> 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). 

Re: New MMC maintainer needed

[Adrian Hunter]

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.

And the pro is objective.

> Pro:
> 
>  - A slightly reduced scanning time.

That's great!  Why do you disregard this so easily?

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

You have just supplied answers to both "Why?" and "Why not?".

In my opinion "Why?" outweighs "Why not?" because the pro is objective and
the cons and not.

Re: New MMC maintainer needed

[Adrian Hunter]

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.

And the pro is objective.

> Pro:
> 
>  - A slightly reduced scanning time.

That's great!  Why do you disregard this so easily?

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

You have just supplied answers to both "Why?" and "Why not?".

In my opinion "Why?" outweighs "Why not?" because the pro is objective and
the cons and not.

Re: New MMC maintainer needed

[Andrew Morton]

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!

Re: New MMC maintainer needed

[David Brownell]

On Friday 31 July 2009, Pierre Ossman wrote:
> 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.

Doesn't handing of resumes needs more attention overall?

Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
resume at all well the last time I checked ... mounted file systems
(not just root) made trouble.  Hardware that reliably reports card
insert/remove was rude in the same ways.

- Dave

Re: New MMC maintainer needed

[David VomLehn]

On Mon, Aug 03, 2009 at 06:51:23PM -0700, David Brownell wrote:
> On Friday 31 July 2009, Pierre Ossman wrote:
> > 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.
> 
> Doesn't handing of resumes needs more attention overall?
> 
> Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
> resume at all well the last time I checked ... mounted file systems
> (not just root) made trouble.  Hardware that reliably reports card
> insert/remove was rude in the same ways.
> 
> - Dave

I've been half- (or less) watching this discussion, but I'm sort of thinking
that one piece of this might be a patch I just reposted that provides for
synchronizing the discovery/initialization of devices during start up with
their use. One thing I expect it to do is to largely eliminate the need for
root_delay. It currently knows nothing about resuming, but perhaps it should.

Since the patch touches USB and SCSI, as well as some core kernel pieces, it
was posted to a bunch of places, but by tomorrow you should be able to find it
by searching for "initdev" in the kernel mailing list archives.

David VomLehn

Re: New MMC maintainer needed

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On Mon, 3 Aug 2009 18:51:23 -0700
David Brownell <david-b@pacbell.net> wrote:

> On Friday 31 July 2009, Pierre Ossman wrote:
> > 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.
> 

(confusion on my end, I wasn't thinking about root_delay but rootwait)

> Doesn't handing of resumes needs more attention overall?
> 

Very much so. I haven't given that area much love since a) I haven't
had the time, b) I don't have any systems with fancy enough suspend
handling to do anything interesting.

> Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
> resume at all well the last time I checked ... mounted file systems
> (not just root) made trouble.  Hardware that reliably reports card
> insert/remove was rude in the same ways.

The general lack of removal detection during suspend tends to make
everything more complicated than one would like. But I'm sure it's
manageable just as long as someone puts enough time into it. I'm still
very much opposed to just assuming that the user never removes the card
during suspend though.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: New MMC maintainer needed

[Matt Fleming]

On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
> Pierre Ossman wrote:
>> 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.
>
> And the pro is objective.
>
>> Pro:
>>
>>  - A slightly reduced scanning time.
>
> That's great!  Why do you disregard this so easily?
>

Ping. Adrian, do you have any initialisation times for this patch? I'm
afraid I don't have any eMMC hardware, so I'm not able to gather any
numbers.

Re: New MMC maintainer needed

[Matt Fleming]

On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
> Pierre Ossman wrote:
>> 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.
>
> And the pro is objective.
>
>> Pro:
>>
>>  - A slightly reduced scanning time.
>
> That's great!  Why do you disregard this so easily?
>

Ping. Adrian, do you have any initialisation times for this patch? I'm
afraid I don't have any eMMC hardware, so I'm not able to gather any
numbers.

Re: New MMC maintainer needed

[Andrew Morton]

davem has set up linux-mmc@vger.kernel.org for us.  It will be archived
at marc.info.  Thanks to both..

I was thinking that we wouldn't need a separate list but then I
realised I didn't have anywhere to send MMC bug reports.

	echo "subscribe linux-mmc" | mail majordomo@vger.kernel.org

Re: New MMC maintainer needed

[Adrian Hunter]

Matt Fleming wrote:
> On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
>> Pierre Ossman wrote:
>>> 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.
>> And the pro is objective.
>>
>>> Pro:
>>>
>>>  - A slightly reduced scanning time.
>> That's great!  Why do you disregard this so easily?
>>
> 
> Ping. Adrian, do you have any initialisation times for this patch? I'm
> afraid I don't have any eMMC hardware, so I'm not able to gather any
> numbers.
> 

Sorry for the slow reply.

Results in microseconds:

	before		after
eMMC	194145		193641
uSD	4143		2129

However, that excludes powering up.  For example the pbias setting
on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.

So the difference is negligible.

Although, the notion of unnecessarily sending SDIO commands
to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
Especially when trying to debug very-hard-to-reproduce errors.

Re: New MMC maintainer needed

[Adrian Hunter]

Matt Fleming wrote:
> On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote:
>> Pierre Ossman wrote:
>>> 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.
>> And the pro is objective.
>>
>>> Pro:
>>>
>>>  - A slightly reduced scanning time.
>> That's great!  Why do you disregard this so easily?
>>
> 
> Ping. Adrian, do you have any initialisation times for this patch? I'm
> afraid I don't have any eMMC hardware, so I'm not able to gather any
> numbers.
> 

Sorry for the slow reply.

Results in microseconds:

	before		after
eMMC	194145		193641
uSD	4143		2129

However, that excludes powering up.  For example the pbias setting
on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.

So the difference is negligible.

Although, the notion of unnecessarily sending SDIO commands
to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
Especially when trying to debug very-hard-to-reproduce errors.

Re: New MMC maintainer needed

[Matt Fleming]

On Wed, Aug 12, 2009 at 03:27:31PM -0700, Andrew Morton wrote:
> 
> davem has set up linux-mmc@vger.kernel.org for us.  It will be archived
> at marc.info.  Thanks to both..
> 
> I was thinking that we wouldn't need a separate list but then I
> realised I didn't have anywhere to send MMC bug reports.
> 
> 	echo "subscribe linux-mmc" | mail majordomo@vger.kernel.org
> 

Unless someone has beaten me to it,

>From a920e6c11635cab6261541a487db7b68b4892a74 Mon Sep 17 00:00:00 2001
From: Matt Fleming <matt@console-pimps.org>
Date: Thu, 13 Aug 2009 09:17:23 +0100
Subject: [PATCH] mmc: Add linux-mmc mailing list

A new linux-mmc mailing list has been set up at vger.kernel.org for all
things related to MMC/SD development.

Signed-off-by: Matt Fleming <matt@console-pimps.org>
---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..e16c7dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3420,6 +3420,7 @@ S:	Supported
 F:	drivers/mfd/
 
 MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
+L:	linux-mmc@vger.kernel.org
 S:	Orphan
 F:	drivers/mmc/
 F:	include/linux/mmc/
-- 
1.6.4.rc0

Re: New MMC maintainer needed

[Matt Fleming]

On Wed, Aug 12, 2009 at 03:27:31PM -0700, Andrew Morton wrote:
> 
> davem has set up linux-mmc@vger.kernel.org for us.  It will be archived
> at marc.info.  Thanks to both..
> 
> I was thinking that we wouldn't need a separate list but then I
> realised I didn't have anywhere to send MMC bug reports.
> 
> 	echo "subscribe linux-mmc" | mail majordomo@vger.kernel.org
> 

Unless someone has beaten me to it,

From a920e6c11635cab6261541a487db7b68b4892a74 Mon Sep 17 00:00:00 2001
From: Matt Fleming <matt@console-pimps.org>
Date: Thu, 13 Aug 2009 09:17:23 +0100
Subject: [PATCH] mmc: Add linux-mmc mailing list

A new linux-mmc mailing list has been set up at vger.kernel.org for all
things related to MMC/SD development.

Signed-off-by: Matt Fleming <matt@console-pimps.org>
---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..e16c7dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3420,6 +3420,7 @@ S:	Supported
 F:	drivers/mfd/
 
 MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
+L:	linux-mmc@vger.kernel.org
 S:	Orphan
 F:	drivers/mmc/
 F:	include/linux/mmc/
-- 
1.6.4.rc0

Re: New MMC maintainer needed

[Nicolas Pitre]

On Thu, 13 Aug 2009, Adrian Hunter wrote:

> Results in microseconds:
> 
> 	before		after
> eMMC	194145		193641
> uSD	4143		2129
> 
> However, that excludes powering up.  For example the pbias setting
> on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.
> 
> So the difference is negligible.

I therefore tend to agree with Pierre and Andrew.  This doesn't make 
enough of a difference to increase the complexity and maintenance cost 
of the code for such a trivial improvement.

> Although, the notion of unnecessarily sending SDIO commands
> to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
> Especially when trying to debug very-hard-to-reproduce errors.

Simply commenting out the SD/SDIO or MMC probe call in the code is 
very simple when you're debugging.  Then if you actually come to the 
conclusion that some real bugs are due to this cross probe and can prove 
it then we might reconsider.

Currently, generic host drivers are sometimes used in the context of a 
uSD slot, sometimes in the context of a SD/SDIO/MMC slot, sometimes with 
a hardwired SDIO based chip soldered on the board, and they don't need 
any special flags to distinguish between those use cases.  This greatly 
helps maintainability, and that should prevail over slight latency 
improvements to non timing critical events such as card insertion.


Nicolas

Re: New MMC maintainer needed

[Nicolas Pitre]

On Thu, 13 Aug 2009, Adrian Hunter wrote:

> Results in microseconds:
> 
> 	before		after
> eMMC	194145		193641
> uSD	4143		2129
> 
> However, that excludes powering up.  For example the pbias setting
> on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay.
> 
> So the difference is negligible.

I therefore tend to agree with Pierre and Andrew.  This doesn't make 
enough of a difference to increase the complexity and maintenance cost 
of the code for such a trivial improvement.

> Although, the notion of unnecessarily sending SDIO commands
> to an uSD, and SDIO and SD commands to an eMMC, seems wrong.
> Especially when trying to debug very-hard-to-reproduce errors.

Simply commenting out the SD/SDIO or MMC probe call in the code is 
very simple when you're debugging.  Then if you actually come to the 
conclusion that some real bugs are due to this cross probe and can prove 
it then we might reconsider.

Currently, generic host drivers are sometimes used in the context of a 
uSD slot, sometimes in the context of a SD/SDIO/MMC slot, sometimes with 
a hardwired SDIO based chip soldered on the board, and they don't need 
any special flags to distinguish between those use cases.  This greatly 
helps maintainability, and that should prevail over slight latency 
improvements to non timing critical events such as card insertion.


Nicolas

Re: New MMC maintainer needed

[Nicolas Ferre]

Pierre Ossman :
> This things are currently lingering in my inbox:

[..]

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

Ok guys, it should be fine if we can plan a merge for those bits: I have
additional patches that are waiting on top of this one...

Thanks a lot. Bye,
-- 
Nicolas Ferre

Re: New MMC maintainer needed

[ellis]

It'll also be archived at http://www.spinics.net/lists/linux-mmc/

Re: New MMC maintainer needed

[Maxim Levitsky]

On Fri, 2009-07-31 at 23:53 -0700, Alex Dubov wrote:
> > 
> > What to do now?
> > 
> 
> Lift up your spirit and get back to work?
> ;-)

Not a bad idea :-)

Best regards,
	Maxim Levitsky

Re: New MMC maintainer needed

[Alex Dubov]

> 
> What to do now?
> 

Lift up your spirit and get back to work?
;-)



      

Re: New MMC maintainer needed

[Maxim Levitsky]

On Wed, Jul 15, 2009 at 7:59 AM, Alex Dubov<oakad@yahoo.com> wrote:
>
>> I'm afraid the time has come for me
>> to step down as maintainer for the
>> MMC/SD/SDIO subsystem and for someone else to take over the
>> rudder. It
>> is no secret that I haven't been able to give the
>> maintainer role the
>> resources it required, and as a result it has gone from
>> being a fun
>> hobby to a burdensome chore. I was hoping it was a
>> temporary slump, but
>> this has been the norm for over a year now, so it's time
>> for me to
>> throw in the towel.
>
> What an unfortunate thing.
>
> Franky speaking, I couldn't manage any time to work on Linux
> in the last year myself. I had such a great plans for Memstick
> and such, yet none advanced.
>
> At this rate, the future of the flash cards on Linux will
> become highly uncertain.
> :-(
>

Me too.

I had plans to reverse engineer and then write drivers for my ricoh 5
in one controller
for SD and memstick mode (especialy XD)
Now I know that RE part isn't the hardest probably, but writing the
core support for XD subsystem (your was rejected I see)

I am also an owner of a jmicron controller, and thanks to you memstick
on it is supported.

What to do now?

Best regards,
         Maxim Levitsky

Re: New MMC maintainer needed

[Alex Dubov]

> I'm afraid the time has come for me
> to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the
> rudder. It
> is no secret that I haven't been able to give the
> maintainer role the
> resources it required, and as a result it has gone from
> being a fun
> hobby to a burdensome chore. I was hoping it was a
> temporary slump, but
> this has been the norm for over a year now, so it's time
> for me to
> throw in the towel.

What an unfortunate thing.

Franky speaking, I couldn't manage any time to work on Linux
in the last year myself. I had such a great plans for Memstick
and such, yet none advanced.

At this rate, the future of the flash cards on Linux will
become highly uncertain.
:-(



      

Re: New MMC maintainer needed

[Alex Dubov]

> I'm afraid the time has come for me
> to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the
> rudder. It
> is no secret that I haven't been able to give the
> maintainer role the
> resources it required, and as a result it has gone from
> being a fun
> hobby to a burdensome chore. I was hoping it was a
> temporary slump, but
> this has been the norm for over a year now, so it's time
> for me to
> throw in the towel.

What an unfortunate thing.

Franky speaking, I couldn't manage any time to work on Linux
in the last year myself. I had such a great plans for Memstick
and such, yet none advanced.

At this rate, the future of the flash cards on Linux will
become highly uncertain.
:-(