On Tue, 25 Feb 2020 23:51:05 -0500 Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > On Tue, Feb 25, 2020 at 09:12:48PM -0600, Trevor Jacobs wrote: > > That's correct, I tested a bunch of the old distros including > > slackware, and 2.6.32 is where the problem began. > > > > Also, the Panasonic Toughbook CF-29s effected that we tested are > > the later marks, MK4 and MK5 for certain. The MK2 CF-29 worked just > > fine because it has different hardware supporting the PCMCIA slots. > > I have not tested a MK3 but suspect it would work ok as it also > > uses the older hardware. > > > > Thanks for your help guys! > > Trevor > > > > Right, the distros probably all enabled MMC_RICOH_MMC earlier than > upstream. Can you test a custom kernel based off your distro kernel > but just disabling that config option? That's probably the easiest fix > currently, even though not ideal. Perhaps there should be a command > line option to disable specific pci quirks to make this easier. > > An ideal fix is I feel hard, given this quirk is based on undocumented > config registers -- it worked on Dell machines (that's where the > original authors seem to have gotten their info from), perhaps they > had only one Cardbus slot, but the code ends up disabling your second > Cardbus slot instead of disabling the MMC controller. Keeping in mind that this was 12+ years ago, you can at least still read the original discussion in the archives. My original Dell laptop (XPS m1330) had no cardbus slots at all, and used the r5c832 controller. There was a subsequent change that I was not involved with which added support for the rl5c476, which is the problematic device in this thread. As a hypothesis, based on the observed behaviour, the quirk (keeping in mind that these are magic configuration register values that are not documented) probably disabled function 1, regardless of what it is, and the original example that motivated adding the rl5c476 quirk probably had one cardbus slot and the card reader functions were all moved up one, or something along those lines. Truly making this smart would then involve having the code enumerate the pci functions and identify the one that is the unwanted mmc controller, based on function ID or class or whatever, and then disabling that (assuming the magic can be reverse engineered: eg, the current magic ORs the disable flag with 0x02 - chances are, that's the index of the function: 0x01 would be the 0th function, 0x04 would be the 2nd function, etc). Someone with access to real hardware could easily experiment with changing that magic value and seeing if it changes which function is disabled. Good luck. --phil
