Bug 11267

Wrong subsystem I'm afraid. Luckily Adrian fixed that for you. :)

There has been a lot of changes to the sdhci driver to facilitate more workarounds for buggy hardware, but you should at the very least get a message in dmesg that it failed to initialise the card.

Could you please enable CONFIG_MMC_DEBUG and see what you get in dmesg when you insert a card? That change will just recompile the mmc portion of the kernel, so it won't take long.

On Thu, 7 Aug 2008, Romano Giannetti wrote:
> I just posted a regression bug on bugzilla:
> 
>       http://bugzilla.kernel.org/show_bug.cgi?id=11267
> 
> the new kernel stopped to notice the fact that I introduce an SD card into
> the
> slot of the machine. It used to work perfectly in 2.6.26 (came back and
> tested, so it's not hardware).
> 
> In 2.6.26 I had on the dmesg:
> 
> [  131.145237] mmc0: new high speed SD card at address b368
> [  131.145295] PM: Adding info for mmc:mmc0:b368
> [  131.176370] mmcblk0: mmc0:b368 SD    2009600KiB (ro)
> [  131.176370] PM: Adding info for No Bus:mmcblk0
> [  131.176370]  mmcblk0: p1
> [  131.176434] PM: Adding info for No Bus:mmcblk0p1
> [  131.176434] PM: Adding info for No Bus:179:0
> 
> In 2.6.27-rc2 nothing happens. I have not a lot of time in my hands, so if
> it's possible at all I'd like to avoid a bisect (It's more than one hour per
> compile here...)

Please try yesterday's patch from the scsi-rc-fixes tree,
commit d211f052fa58a053639bc51501cb64421157d362
which fixed SD cards over USB storage for me:

[SCSI] sd: fix USB devices incorrectly reporting DIF support

Some USB devices set the protect bit in the INQUIRY data which
currently causes the DIF code in sd to assume (incorrectly) that they
support READ_CAPACITY(16).  Fix this (only for the time being) by
making sure we only believe the protect bit in the inquiry data if the
device claims conformance to SCSI-3 or above.

Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---

diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 291d56a..80b2e93 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -6,6 +6,7 @@
 #include <linux/spinlock.h>
 #include <linux/workqueue.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi.h>
 #include <asm/atomic.h>
 
 struct request_queue;
@@ -426,7 +427,7 @@ static inline int scsi_device_enclosure(struct scsi_device *sdev)
 
 static inline int scsi_device_protection(struct scsi_device *sdev)
 {
-	return sdev->inquiry[5] & (1<<0);
+	return sdev->scsi_level > SCSI_2 && sdev->inquiry[5] & (1<<0);
 }
 
 #define MODULE_ALIAS_SCSI_DEVICE(type) \

Handled-By : Hugh Dickins <hugh@veritas.com>
Patch : http://marc.info/?l=linux-kernel&m=121812325903507&w=4

The MMC stack does not use SCSI, so you're just side-tracking the poor fella' :)

Oops.

Not-Handled-By : Hugh Dickins <hugh@veritas.com>
Ignore-Patch : http://marc.info/?l=linux-kernel&m=121812325903507&w=4

Handled-By : Pierre Ossman <drzeus-bugzilla@drzeus.cx>

I am recompiling now with CONFIG_MMC_SDHCI_PCI enabled (I had it disabled before) and with MMC debug enabled. Will report back asap.

OK, that solved it. When doing a make oldconfig and blindly hitting return, the option CONFIG_MMC_SDHCI_PCI got its default value of N. Setting this to Y gave me back my SD card reader. 

Just a doubt: given that in 2.6.26 the functionality was on, shouldn't this option default to yes?

It was off by default in 2.6.26 as well. Those config options have no explicit default, which means they get "N". This is the norm for all device drivers.

Hmmm... CONFIG_MMC_SDHCI_PCI is not in my 2.6.26 config:

(0)rukbat:/usr/src/linux-2.6.26%  grep MMC_SDHCI .config
CONFIG_MMC_SDHCI=m

But it seems that that option has been split in two in 2.6.27:

(0)rukbat:/usr/src/linux-2.6.27%  grep MMC_SDHCI .config
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m

and probably the "PCI" capability was included into the global option before. 
What happened is that I did a "make oldconfig" and it failed to give me an equivalent configuration, that was what I meant. In a perfect world, the nw configuration option should get a default that covers the same range of devices it covered before.

But well, it's an easy thing to correct, and distro will take care of it, so not a big issue. Thanks,

Romano