>Someone with access to real hardware could >easily experiment with changing that magic value and seeing if it >changes which function is disabled. One of our members has offered to supply a machine to a dev that can use it to test any theory. It is nearly beyond the scope of the majority of us to do much more than just testing. We appreciate all the effort the devs put in and are willing to help in anyway we can but we aren't kernel devs. I, personally, use Debian. Others use Debian based distros such as MX and Mint. We have been able to test many different distros such as those listed in other comments but don't have the skills or expertise to do much more. It is our hope that this discussion and subsequent effort may enable others who prefer distros other than Debian based distros can use a CF-29 (and possibly earlier) Toughbook with the distro of their choice without having to rebuild a kernel so they can use hardware that worked back in 2010. To do this the fix needs to be at the kernel dev level not a local enthusiast level because while I can rebuild a Debian kernel I can't rebuild a Fedora or Arch or Slackware kernel. I did a search about this issue before I made initial contact late last year and the issue was discovered on more than Toughbooks and posted about on various sites not long after distros moved from 2.6.32. It seems back then people just got new machines that didn't have a 2nd slot so the search for an answer stopped. Us Toughbook users are a loyal group we use our machines because they are exactly what we need and they take alot of "punishment" taht other machines simply cannot handle. Our machines are used rather than recycled or worse still just left to sit in waste management facilities in a country that the western world dumps its rubbish in, we are Linux and Toughbook enthusiasts and hope to be able to keep our machines running for many years to come with all their native capabilities working as they were designed to but using a modern Linux instead of Windows XP or Windows 7. (that wasn't a pep talk, its just an explanation of why we are passionate about this). Let us know what you need us to do, we will let you know if we are capable of it and give you any feedback you ask for. Over the weekend I will try to rebuild a Debian kernel with the relevant option disabled, provide it to my peers for testing and report back here what the outcome is. Thank you all for all your time and effort, it is truly appreciated. Cheers. Michael. On 26/02/2020, Philip Langdale <philipl@xxxxxxxxx> wrote: > 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 >
