Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux