Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934914Ab3DKNk5 (ORCPT ); Thu, 11 Apr 2013 09:40:57 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49530 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752023Ab3DKNky (ORCPT ); Thu, 11 Apr 2013 09:40:54 -0400 Date: Thu, 11 Apr 2013 15:40:53 +0200 Message-ID: From: Takashi Iwai To: Bjorn Helgaas Cc: Oliver Neukum , Michal Marek , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "alex.williamson@redhat.com" , Matthew Garrett Subject: Re: [PATCH] pciehp: Add pciehp_surprise module option In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5135 Lines: 114 At Wed, 10 Apr 2013 11:19:48 -0600, Bjorn Helgaas wrote: > > On Wed, Apr 10, 2013 at 10:34 AM, Takashi Iwai wrote: > > 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 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? > > I think we need to ignore the surprise bit as Matthew suggested. OK, this is certainly a cleaner way. > Alex raised an issue with this (secondary bus reset causes a device > remove followed by device add), so we'd have to work through that > somehow. I think doing the remove/add would actually be more correct > because we would be doing the whole device initialization after the > reset. We currently save/restore some device state around the reset, > but that's a piecemeal approach that is certain to miss internal > hidden state. But I don't know how to deal with the KVM implications > of remove/add. So is this specific to KVM? In anyway, if any test patch is available, let me (or Oliver, Michal) know. We'll happily try on the machine showing the bug. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/