All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Mike DeKoker <mdekoker@signatec.com>
Cc: "'Rafael J. Wysocki'" <rjw@sisk.pl>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	"'Bjorn Helgaas'" <bjorn.helgaas@hp.com>
Subject: Re: pciehp - Problems with ExpressCard hotplug
Date: Tue, 09 Nov 2010 17:17:34 +0900	[thread overview]
Message-ID: <4CD9039E.6000103@jp.fujitsu.com> (raw)
In-Reply-To: <003a01cb7d1d$3adbad70$b0930850$@com>

(2010/11/06 4:11), Mike DeKoker wrote:
>> (2010/11/04 14:06), Rafael J. Wysocki wrote:
>>> [CCing linux-pci and Bjorn]
>>>
>>> On Thursday, November 04, 2010, Mike DeKoker wrote:
>>>> Hello everyone, I hope this is the correct forum.
>>>>
>>>> I'm having a problem with hotplug working for a PCIe-based ExpressCard
>>>> device that I'm developing a driver module for. If not hot-plugged,
>>>> everything works great. Further, running the exact same laptop/device
>>>> hardware but different OS (XP or Win7-64) hot-plugging works okay so I
> don't
>>>> think this is a simple hardware/BIOS error.
>>>>
>>>> I've tried several stock kernel versions from 2.6.18 (the version my
>>>> customer intends to use) up to 2.6.34.7 (version for all verbiage below)
> and
>>>> have had fairly consistent behavior.
>>>>
>>>> The driver module (sig_ec14) is using the pci_register_driver interface
> and
>>>> in the subsequent probe callback function (after a hot-plug) an error
> occurs
>>>> when calling pci_enable_device. Here's the relevant dmesg data:
>>>>
>>>> Insert device:
> SNIP
>>>>
>>>> It looks like the requested memory spaces are not allocated properly.
> I'm a
>>>> little uncertain about the entity that's actually responsible for
> allocating
>>>> the resources. Is this a failure of the BIOS or does system software
> play a
>>>> role in PNP resource allocation for hot-plug? I'm a little out of my
> element
>>>> here.
>>>>
>>>> I've also run with pciehp_debug=1 in the event that the extra info makes
>>>> sense to someone:
>>>>
> SNIP
>>>>
>>>> That 'Surprise Removal' immediately following the 'Card present on
> Slot(5)'
>>>> message looks like a potential culprit.
>>
>> I believe this is just an message problem.
>>
>> It looks like resource allocation code doesn't work for your
>> end device...
>>
>> Could you send the following information
>>
>>   - whole dmesg output after hot-plugging the device (with pciehp_debug=1)
>>   - lspci -vvvxxx output after boot with and without your device (no
>>     hotplug operation required)
>
> ------- lspci -vvvxxx (Pre device insertion):
>

(snip.)

> 08:00.0 Non-VGA unclassified device: Device 1b94:ec14
> 	Subsystem: Device 1b94:ec14
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium>TAbort-
> <TAbort-<MAbort->SERR-<PERR- INTx-
> 	Interrupt: pin A routed to IRQ 255
> 	Kernel modules: sig_ec14
> 00: 94 1b 14 ec 00 00 20 02 00 00 00 00 00 40 00 00


I guess the following code in setup-bus.c skips your device
whose class code is undefined.

static void __dev_sort_resources(struct pci_dev *dev,
                                  struct resource_list *head)
{
         u16 class = dev->class >> 8;

         /* Don't touch classless devices or host bridges or ioapics.  */
         if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
                 return;

Can you try with the above two lines commented out?

Regards,
Kenji Kaneshige


      reply	other threads:[~2010-11-09  8:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-04  2:10 pciehp - Problems with ExpressCard hotplug Mike DeKoker
2010-11-04  5:06 ` Rafael J. Wysocki
2010-11-05  5:57   ` Kenji Kaneshige
2010-11-05 19:11     ` Mike DeKoker
2010-11-09  8:17       ` Kenji Kaneshige [this message]

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=4CD9039E.6000103@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mdekoker@signatec.com \
    --cc=rjw@sisk.pl \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.