Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
From: Trevor Jacobs
Date: Tue Feb 25 2020 - 22:13:00 EST
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
On 2/25/20 7:50 PM, Michael . wrote:
Through our own testing it hasn't worked on any of the regular Linux
releases (both Deb and RPM varieties, and I think someone tested Arch
or Slackware as well) after 2.6.32 .
On 26/02/2020, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
On Tue, Feb 25, 2020 at 04:03:32PM +0100, Ulf Hansson wrote:
On Sat, 22 Feb 2020 at 17:56, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
On Tue, Oct 29, 2019 at 12:02:50PM -0500, Bjorn Helgaas wrote:
[+cc Ulf, Philip, Pierre, Maxim, linux-mmc; see [1] for beginning of
thread, [2] for problem report and the patch Michael tested]
On Tue, Oct 29, 2019 at 07:58:27PM +1100, Michael . wrote:
Bjorn and Dominik.
I am happy to let you know the patch did the trick, it compiled
well
on 5.4-rc4 and my friends in the CC list have tested the modified
kernel and confirmed that both slots are now working as they
should.
As a group of dedicated Toughbook users and Linux users please
accept
our thanks your efforts and assistance is greatly appreciated.
Now that we know this patch works what kernel do you think it will
be
released in? Will it make 5.4 or will it be put into 5.5
development
for further testing?
That patch was not intended to be a fix; it was just to test my guess
that the quirk might be related.
Removing the quirk solved the problem *you're* seeing, but the quirk
was added in the first place to solve some other problem, and if we
simply remove the quirk, we may reintroduce the original problem.
So we have to look at the history and figure out some way to solve
both problems. I cc'd some people who might have insight. Here are
some commits that look relevant:
5ae70296c85f ("mmc: Disabler for Ricoh MMC controller")
03cd8f7ebe0c ("ricoh_mmc: port from driver to pci quirk")
[1]
https://lore.kernel.org/r/CAFjuqNi+knSb9WVQOahCVFyxsiqoGgwoM7Z1aqDBebNzp_-jYw@xxxxxxxxxxxxxx/
[2] https://lore.kernel.org/r/20191021160952.GA229204@xxxxxxxxxx/
I guess this problem is still unfixed? I hate the fact that we broke
something that used to work.
Maybe we need some sort of DMI check in ricoh_mmc_fixup_rl5c476() so
we skip it for Toughbooks? Or maybe we limit the quirk to the
machines where it was originally needed?
Both options seems reasonable to me. Do you have time to put together a
patch?
Kind regards
Uffe
The quirk is controlled by MMC_RICOH_MMC configuration option. At least
as a short-term fix a bit better than patching the kernel, building one
with that config option disabled should have the same effect.
From the commit messages, the quirk was required to support MMC (as
opposed to SD) cards in the SD slot. I would assume this will be an
issue with the chip in any machine as the commit indicates that the
hardware in the chip detects MMC cards and doesn't expose them through
the SDHCI function.
It looks like the quirk was only enabled by default in 2015, at least
upstream [1], though in Debian it was enabled in May 2010 going by their
git repo, maybe in 2.6.32-16.
[1] commit ba2f73250e4a ("mmc: Enable Ricoh MMC quirk by default")