From: email@example.com To: "Michael ." <firstname.lastname@example.org> Cc: Philip Langdale <email@example.com>, Arvind Sankar <firstname.lastname@example.org>, Trevor Jacobs <email@example.com>, Ulf Hansson <firstname.lastname@example.org>, Bjorn Helgaas <email@example.com>, Dominik Brodowski <firstname.lastname@example.org>, Linux PCI <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, Kris Cleveland <email@example.com>, Morgan Klym <firstname.lastname@example.org>, Pierre Ossman <email@example.com>, Maxim Levitsky <firstname.lastname@example.org>, email@example.com Subject: Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29] Date: Wed, 26 Feb 2020 11:46:36 -0800 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAFjuqNh8ja3maOFev4S9zOSi04yAvnyEo2GTTxjr1pbQvmAW=A@mail.gmail.com> Somewhere in these messages is a clue....in that SD reader was involved. MK 4 and 5 have SD whilst MK 1, 2 and three do not. On 2020-02-25 22:10, Michael . wrote: >> 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 <email@example.com> wrote: >> On Tue, 25 Feb 2020 23:51:05 -0500 >> Arvind Sankar <firstname.lastname@example.org> 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 >>
next prev parent 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-rM3VRkyoBNUTJr8goemail@example.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 2020-02-26 6:10 ` Michael . 2020-02-26 19:46 ` bluerocksaddles [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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 \ firstname.lastname@example.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