linux-kernel - Re: [PATCH] pciehp: Add pciehp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hfvyygxac.wl%tiwai@suse.de>
Date:	Wed, 10 Apr 2013 18:34:03 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Oliver Neukum <oneukum@...e.de>, Michal Marek <mmarek@...e.cz>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pciehp: Add pciehp_surprise module option

Hi Bjorn,

sorry for the late follow up as I was on vacation and has been busy
for other tasks.  Since this topic went to nirvana, I try to whip
again...

At Mon, 25 Mar 2013 10:58:40 -0600,
Bjorn Helgaas wrote:
> 
> On Wed, Mar 20, 2013 at 8:02 AM, Takashi Iwai <tiwai@...e.de> wrote:
> > We encountered a problem that on some HP machines the Realtek PCI-e
> > card reader device appears only when you inserted a card before the
> > cold boot.  While debugging, it turned out that the device is actually
> > handled via PCI-e hotplug in some level.  The device sends a presence
> > change notification, and pciehp receives it, but it's ignored because
> > of lack of the hotplug surprise (PCI_EXP_SLTCAP_HPS) capability bit.
> > Once when this check passes, everything starts working -- the device
> > appears upon plugging the card properly.
> >
> > There are a few other bug reports indicating the similar problems
> > (e.g. on recent Dell laptops), and I guess the culprit is same.
> 
> Can you point us at these bug reports, e.g., with URLs?  Hopefully
> they will contain complete dmesg logs and "lspci -vv" outputs so we
> can debug this a bit more.

The machine isn't in market yet, so we cannot expose all things, but I
attach the lspci snippet of the relevant parts, pci-e ports and the
card reader, at least.  If you need anything else, let me know.

As Oliver and Michal already replied, Windows (both 7/8) identifies
the device without modification.  This implies that Windows handles
the hotplug no matter whether the surprise bit is set or not, either
globally or device-specifically.  But, since this is pretty new
hardware, we highly doubt it's done in a white-list basis.

> I'm strongly opposed to adding a module option to work around this
> issue because the user experience is unacceptable.  We can't expect
> users to debug the problem and discover the option.
> 
> I'm also opposed to a DMI quirk system because I think it's very
> likely that this device works correctly under Windows, and I doubt
> very much that Windows has to include the equivalent of DMI quirks.
> So we should, at least in principle, be able to figure out how to make
> it work, too.

In order to get things a bit straight, let me list up the things we
found again:

- The Realtek card reader devices doesn't appear in lspci at the
  fresh boot in multiple kernel versions from 3.0 to 3.9.

- Once when the card is inserted, it issues the hotplug IRQ event.

- pciehp receives and handles the event but it doesn't add/remove the
  device actually because the corresponding controller has no surprise
  bit.

  When forcibly enabling the hotplug device addition by my patch, it
  starts working.  The device is added at card insert.  The removal
  doesn't trigger on our system, but the event itself seems
  generated.

- The surprise bit can't be changed as it's supposed to be read-only
  register bits.  Thus no PCI quirk seems possible, and it has to be
  fixed in pciehp.

- Another way to detect the PCI card reader device is to perform
     echo 1 > /sys/bus/pci/rescan
  with a memory card inserted.  It doesn't work without the card,
  and it is less sophisticated than pciehp, of course.

Right now, we applied a patch for pciehp to ignore the surprise bit
per basis of DMI string match.  This works, but doesn't scale; if the
same problem happens on a similar model, the driver must be compiled
again.  A module option would be really convenient for that, although
I understand your concern, too.

Of course, an alternative (and more radical) solution is to remove the
surprise bit check completely from pciehp, as Matthew suggested in the
thread.  What risk would it bring?

If you have any other solution in mind, please let me know.

thanks,

Takashi

---

Download attachment "lspci.out" of type "application/octet-stream" (15098 bytes)