Linux-PCI Archive on lore.kernel.org
 help / color / Atom feed
From: Philip Langdale <philipl@overt.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Trevor Jacobs <trevor_jacobs@aol.com>,
	"Michael ." <keltoiboy@gmail.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kris Cleveland <tridentperfusion@yahoo.com>,
	Jeff <bluerocksaddles@willitsonline.com>,
	Morgan Klym <moklym@gmail.com>, Pierre Ossman <pierre@ossman.eu>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
Date: Tue, 25 Feb 2020 21:20:54 -0800
Message-ID: <20200225212054.09865e0b@fido6> (raw)
In-Reply-To: <20200226045104.GA2191053@rani.riverdale.lan>

On Tue, 25 Feb 2020 23:51:05 -0500
Arvind Sankar <nivedita@alum.mit.edu> 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

  reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFjuqNh1=B7Ft6v7nzo3BW70EbAvK=Eko_4yqrJ4Z4N3w_Y+Xw@mail.gmail.com>
     [not found] ` <CAFjuqNjLJw8J0nU2oo8rDfDUBavHLC7D0=AAwM62tp6=kHHk-A@mail.gmail.com>
     [not found]   ` <20191015064801.GA104469@owl.dominikbrodowski.net>
     [not found]     ` <CAFjuqNgxAuf+JTkWqhimDspzPd0+s5yGJro=Zi164uoxu4CmOA@mail.gmail.com>
     [not found]       ` <CANfzparZ17SMzE1qzzF=Rixu=aYpf1RiKqR4KXXS0S+u7Q3TwQ@mail.gmail.com>
2019-10-20  9:08         ` Dominik Brodowski
2019-10-21 16:09           ` Bjorn Helgaas
2019-10-21 18:17             ` Michael .
2019-10-21 18:47               ` Dominik Brodowski
2019-10-21 18:59                 ` Michael .
     [not found]                   ` <CAFjuqNg8_G-B5Owz1NBxa-nw620hXwcn9WkE4sfETVR81MWatA@mail.gmail.com>
     [not found]                     ` <CAFjuqNiToDC9BSJVdahdkPz8Ejb-rM3VRkyoBNUTJr8go=7zrg@mail.gmail.com>
     [not found]                       ` <20191025075536.GA14531@owl.dominikbrodowski.net>
2019-10-25 18:34                         ` Michael .
2019-10-29  8:58                           ` Michael .
2019-10-29 17:02                             ` Bjorn Helgaas
2020-02-22 16:56                               ` Bjorn Helgaas
2020-02-22 18:14                                 ` Michael .
2020-02-25 15:03                                 ` Ulf Hansson
2020-02-25 19:15                                   ` Bjorn Helgaas
2020-02-25 23:46                                   ` bluerocksaddles
2020-02-26  1:13                                   ` Arvind Sankar
2020-02-26  1:50                                     ` Michael .
2020-02-26  3:12                                       ` Trevor Jacobs
2020-02-26  4:51                                         ` Arvind Sankar
2020-02-26  5:20                                           ` Philip Langdale [this message]
2020-02-26  6:10                                             ` Michael .
2020-02-26 19:46                                               ` bluerocksaddles
2020-07-28  1:50                                                 ` Michael .
2020-08-02  5:58                                                   ` Michael .

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200225212054.09865e0b@fido6 \
    --to=philipl@overt.org \
    --cc=bluerocksaddles@willitsonline.com \
    --cc=helgaas@kernel.org \
    --cc=keltoiboy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=maximlevitsky@gmail.com \
    --cc=moklym@gmail.com \
    --cc=nivedita@alum.mit.edu \
    --cc=pierre@ossman.eu \
    --cc=trevor_jacobs@aol.com \
    --cc=tridentperfusion@yahoo.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PCI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \
		linux-pci@vger.kernel.org
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git