Linux-mmc Archive on lore.kernel.org
 help / color / Atom feed
* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
       [not found] <CAFjuqNihuEb4_5Lny5X7vA258c0ogemVg8pQ5Y_ANgOsqhSXhg@mail.gmail.com>
@ 2019-10-29 17:02 ` Bjorn Helgaas
  2020-02-22 16:56   ` Bjorn Helgaas
  0 siblings, 1 reply; 15+ messages in thread
From: Bjorn Helgaas @ 2019-10-29 17:02 UTC (permalink / raw)
  To: Michael .
  Cc: Dominik Brodowski, linux-pci, linux-kernel, Trevor Jacobs,
	Kris Cleveland, Jeff, Morgan Klym, Ulf Hansson, Philip Langdale,
	Pierre Ossman, Maxim Levitsky, linux-mmc

[+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@mail.gmail.com/
[2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2019-10-29 17:02 ` PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29] Bjorn Helgaas
@ 2020-02-22 16:56   ` Bjorn Helgaas
  2020-02-22 18:14     ` Michael .
  2020-02-25 15:03     ` Ulf Hansson
  0 siblings, 2 replies; 15+ messages in thread
From: Bjorn Helgaas @ 2020-02-22 16:56 UTC (permalink / raw)
  To: Michael .
  Cc: Dominik Brodowski, linux-pci, linux-kernel, Trevor Jacobs,
	Kris Cleveland, Jeff, Morgan Klym, Ulf Hansson, Philip Langdale,
	Pierre Ossman, Maxim Levitsky, linux-mmc

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@mail.gmail.com/
> [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/

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?

Bjorn

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-22 16:56   ` Bjorn Helgaas
@ 2020-02-22 18:14     ` Michael .
  2020-02-25 15:03     ` Ulf Hansson
  1 sibling, 0 replies; 15+ messages in thread
From: Michael . @ 2020-02-22 18:14 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Dominik Brodowski, linux-pci, linux-kernel, Trevor Jacobs,
	Kris Cleveland, Jeff, Morgan Klym, Ulf Hansson, Philip Langdale,
	Pierre Ossman, Maxim Levitsky, linux-mmc

Hi Bjorn, yes this is still unfixed.
I'm sorry that I haven't been able to pursue this but the weather in
Australia has been horrendous since October last year. Your proposals
sound good but are way beyond my knowledge and skill level to
implement. I, and my friends, are happy to help in any way we can.
Cheers.
Michael.

P.S. I apologise for the double reply

On 23/02/2020, Bjorn Helgaas <helgaas@kernel.org> 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@mail.gmail.com/
>> [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
>
> 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?
>
> Bjorn
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  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
                         ` (2 more replies)
  1 sibling, 3 replies; 15+ messages in thread
From: Ulf Hansson @ 2020-02-25 15:03 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Michael .,
	Dominik Brodowski, Linux PCI, Linux Kernel Mailing List,
	Trevor Jacobs, Kris Cleveland, Jeff, Morgan Klym,
	Philip Langdale, Pierre Ossman, Maxim Levitsky, linux-mmc

On Sat, 22 Feb 2020 at 17:56, Bjorn Helgaas <helgaas@kernel.org> 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@mail.gmail.com/
> > [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
>
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  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
  2 siblings, 0 replies; 15+ messages in thread
From: Bjorn Helgaas @ 2020-02-25 19:15 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Michael .,
	Dominik Brodowski, Linux PCI, Linux Kernel Mailing List,
	Trevor Jacobs, Kris Cleveland, Jeff, Morgan Klym,
	Philip Langdale, Pierre Ossman, Maxim Levitsky, linux-mmc

On Tue, Feb 25, 2020 at 04:03:32PM +0100, Ulf Hansson wrote:
> On Sat, 22 Feb 2020 at 17:56, Bjorn Helgaas <helgaas@kernel.org> 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@mail.gmail.com/
> > > [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
> >
> > 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?

I don't really have time, and I'm not sure which way is best.  In
general I like to avoid quirks, so I would lean toward applying the
quirk only on the machines that we know need it.  But I'm not sure how
to identify those.

Bjorn

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  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
  2 siblings, 0 replies; 15+ messages in thread
From: bluerocksaddles @ 2020-02-25 23:46 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Bjorn Helgaas, Michael .,
	Dominik Brodowski, Linux PCI, Linux Kernel Mailing List,
	Trevor Jacobs, Kris Cleveland, Morgan Klym, Philip Langdale,
	Pierre Ossman, Maxim Levitsky, linux-mmc

Bjorn,

If you folks need a test unit or five, let me know. I can donate any 
Mark CF-29 to the project. (MK 2 or 3 will duplicate the "problem".) 
They are non-pae 386.

Jeff

On 2020-02-25 07:03, Ulf Hansson wrote:
> On Sat, 22 Feb 2020 at 17:56, Bjorn Helgaas <helgaas@kernel.org> 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@mail.gmail.com/
>> > [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
>> 
>> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  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 .
  2 siblings, 1 reply; 15+ messages in thread
From: Arvind Sankar @ 2020-02-26  1:13 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Bjorn Helgaas, Michael .,
	Dominik Brodowski, Linux PCI, Linux Kernel Mailing List,
	Trevor Jacobs, Kris Cleveland, Jeff, Morgan Klym,
	Philip Langdale, Pierre Ossman, Maxim Levitsky, linux-mmc

On Tue, Feb 25, 2020 at 04:03:32PM +0100, Ulf Hansson wrote:
> On Sat, 22 Feb 2020 at 17:56, Bjorn Helgaas <helgaas@kernel.org> 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@mail.gmail.com/
> > > [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
> >
> > 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")

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26  1:13       ` Arvind Sankar
@ 2020-02-26  1:50         ` Michael .
  2020-02-26  3:12           ` Trevor Jacobs
  0 siblings, 1 reply; 15+ messages in thread
From: Michael . @ 2020-02-26  1:50 UTC (permalink / raw)
  To: Arvind Sankar
  Cc: Ulf Hansson, Bjorn Helgaas, Dominik Brodowski, Linux PCI,
	Linux Kernel Mailing List, Trevor Jacobs, Kris Cleveland, Jeff,
	Morgan Klym, Philip Langdale, Pierre Ossman, Maxim Levitsky,
	linux-mmc

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@alum.mit.edu> 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@kernel.org> 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@mail.gmail.com/
>> > > [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
>> >
>> > 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")
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26  1:50         ` Michael .
@ 2020-02-26  3:12           ` Trevor Jacobs
  2020-02-26  4:51             ` Arvind Sankar
  0 siblings, 1 reply; 15+ messages in thread
From: Trevor Jacobs @ 2020-02-26  3:12 UTC (permalink / raw)
  To: Michael ., Arvind Sankar
  Cc: Ulf Hansson, Bjorn Helgaas, Dominik Brodowski, Linux PCI,
	Linux Kernel Mailing List, Kris Cleveland, Jeff, Morgan Klym,
	Philip Langdale, Pierre Ossman, Maxim Levitsky, linux-mmc

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@alum.mit.edu> 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@kernel.org> 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@mail.gmail.com/
>>>>> [2] https://lore.kernel.org/r/20191021160952.GA229204@google.com/
>>>> 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")
>>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26  3:12           ` Trevor Jacobs
@ 2020-02-26  4:51             ` Arvind Sankar
  2020-02-26  5:20               ` Philip Langdale
  0 siblings, 1 reply; 15+ messages in thread
From: Arvind Sankar @ 2020-02-26  4:51 UTC (permalink / raw)
  To: Trevor Jacobs
  Cc: Michael .,
	Arvind Sankar, Ulf Hansson, Bjorn Helgaas, Dominik Brodowski,
	Linux PCI, Linux Kernel Mailing List, Kris Cleveland, Jeff,
	Morgan Klym, Philip Langdale, Pierre Ossman, Maxim Levitsky,
	linux-mmc

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26  4:51             ` Arvind Sankar
@ 2020-02-26  5:20               ` Philip Langdale
  2020-02-26  6:10                 ` Michael .
  0 siblings, 1 reply; 15+ messages in thread
From: Philip Langdale @ 2020-02-26  5:20 UTC (permalink / raw)
  To: Arvind Sankar
  Cc: Trevor Jacobs, Michael .,
	Ulf Hansson, Bjorn Helgaas, Dominik Brodowski, Linux PCI,
	Linux Kernel Mailing List, Kris Cleveland, Jeff, Morgan Klym,
	Pierre Ossman, Maxim Levitsky, linux-mmc

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26  5:20               ` Philip Langdale
@ 2020-02-26  6:10                 ` Michael .
  2020-02-26 19:46                   ` bluerocksaddles
  0 siblings, 1 reply; 15+ messages in thread
From: Michael . @ 2020-02-26  6:10 UTC (permalink / raw)
  To: Philip Langdale
  Cc: Arvind Sankar, Trevor Jacobs, Ulf Hansson, Bjorn Helgaas,
	Dominik Brodowski, Linux PCI, Linux Kernel Mailing List,
	Kris Cleveland, Jeff, Morgan Klym, Pierre Ossman, Maxim Levitsky,
	linux-mmc

>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@overt.org> wrote:
> 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
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26  6:10                 ` Michael .
@ 2020-02-26 19:46                   ` bluerocksaddles
  2020-07-28  1:50                     ` Michael .
  0 siblings, 1 reply; 15+ messages in thread
From: bluerocksaddles @ 2020-02-26 19:46 UTC (permalink / raw)
  To: Michael .
  Cc: Philip Langdale, Arvind Sankar, Trevor Jacobs, Ulf Hansson,
	Bjorn Helgaas, Dominik Brodowski, Linux PCI,
	Linux Kernel Mailing List, Kris Cleveland, Morgan Klym,
	Pierre Ossman, Maxim Levitsky, linux-mmc

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 <philipl@overt.org> wrote:
>> 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
>> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-02-26 19:46                   ` bluerocksaddles
@ 2020-07-28  1:50                     ` Michael .
  2020-08-02  5:58                       ` Michael .
  0 siblings, 1 reply; 15+ messages in thread
From: Michael . @ 2020-07-28  1:50 UTC (permalink / raw)
  To: bluerocksaddles
  Cc: Philip Langdale, Arvind Sankar, Trevor Jacobs, Ulf Hansson,
	Bjorn Helgaas, Dominik Brodowski, Linux PCI,
	Linux Kernel Mailing List, Kris Cleveland, Morgan Klym,
	Pierre Ossman, Maxim Levitsky, linux-mmc

I have just compiled and uploaded a kernel to test for this issue,
members of the Toughbook community have been provided with the link,
though a forum discussion, to download the kernel and test it.
Hopefully we will get positive results and can confirm the
MMC_RICOH_MMC flag is the culprit.
Regards.
Stay safe.
Michael.

On 27/02/2020, bluerocksaddles@willitsonline.com
<bluerocksaddles@willitsonline.com> wrote:
> 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 <philipl@overt.org> wrote:
>>> 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
>>>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
  2020-07-28  1:50                     ` Michael .
@ 2020-08-02  5:58                       ` Michael .
  0 siblings, 0 replies; 15+ messages in thread
From: Michael . @ 2020-08-02  5:58 UTC (permalink / raw)
  To: bluerocksaddles
  Cc: Philip Langdale, Arvind Sankar, Trevor Jacobs, Ulf Hansson,
	Bjorn Helgaas, Dominik Brodowski, Linux PCI,
	Linux Kernel Mailing List, Kris Cleveland, Morgan Klym,
	Pierre Ossman, Maxim Levitsky, linux-mmc

Have just had confirmation that the mmc_ricoh_mmc change works and
both PCMCIA slots now work as intended on Panasonic Toughbook CF-29 Mk
4 and 5.

Thank you to all who have made suggestions for this, your dedication
to Linux is amazing and your help with this is appreciated.

Stay safe.
Michael.

On 28/07/2020, Michael . <keltoiboy@gmail.com> wrote:
> I have just compiled and uploaded a kernel to test for this issue,
> members of the Toughbook community have been provided with the link,
> though a forum discussion, to download the kernel and test it.
> Hopefully we will get positive results and can confirm the
> MMC_RICOH_MMC flag is the culprit.
> Regards.
> Stay safe.
> Michael.
>
> On 27/02/2020, bluerocksaddles@willitsonline.com
> <bluerocksaddles@willitsonline.com> wrote:
>> 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 <philipl@overt.org> wrote:
>>>> 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
>>>>
>>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, back to index

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAFjuqNihuEb4_5Lny5X7vA258c0ogemVg8pQ5Y_ANgOsqhSXhg@mail.gmail.com>
2019-10-29 17:02 ` PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29] 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
2020-07-28  1:50                     ` Michael .
2020-08-02  5:58                       ` Michael .

Linux-mmc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mmc/0 linux-mmc/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-mmc linux-mmc/ https://lore.kernel.org/linux-mmc \
		linux-mmc@vger.kernel.org
	public-inbox-index linux-mmc

Example config snippet for mirrors

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


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