All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: How does Linux handle PCI-E Surprise unplug?
Date: Mon, 08 Mar 2010 08:24:27 +0000	[thread overview]
Message-ID: <4B94B43B.7060202@jp.fujitsu.com> (raw)
In-Reply-To: <8506939B503B404A84BBB12293FC45F606B883BA@emailbng3.jnpr.net>

Rajat Jain wrote:
> Hello Greg / All,
> 
> Replying on this thread as I have a small query left regarding this...
> 
>> -----Original Message-----
>> From: Greg KH [mailto:greg@kroah.com]
>> Sent: Thursday, February 18, 2010 8:23 PM
>> To: Rajat Jain
>> Cc: linux-hotplug@vger.kernel.org; linux-pci@vger.kernel.org
>> Subject: Re: How does Linux handle PCI-E Surprise unplug?
>>
>> On Thu, Feb 18, 2010 at 11:35:33AM +0530, Rajat Jain wrote:
>>> Hi,
>>>
>>> I'm keen to understand how the Linux kernel handles surprise removal
> of
>>> a device, from a PCI-e slot that supports "Hot-plug Surprise"
> removal
>>> (in slot capabilities).
>>>
>>> Consider that the device in the slot is working normally, with its
>>> driver attached to the device, and is doing all sorts of read /
> write
>>> operations on the device registers that have been mapped into the
> PCI
>>> memory space. Now when that device is suddenly plugged out (and thus
> its
>>> registers suddenly disappear from the PCI memory space), the device
>>> driver is still unaware as it is doing the register reads / writes
> on
>>> the device. At this point, IMHO any attempt to access the device
>>> registers will result in an exception (BUS error?) as the device is
>>> gone. Correct?
>> The driver will suddenly start reading all 0xff and will then need to
>> abort whatever it was doing.  Usually all drivers handle this just
> fine
>> today, as this is what they needed to do when they were pccard
> devices.
>> Nothing new here at all.
>>
> 
> Does that mean accessing PCI memory mapped registers for a non-existent
> device has effects that are localized ONLY to the driver of that device?
> In other words, kernel does not notice or does not even become AWARE
> that a driver is trying to access non-existent memory mapped registers? 
> 
> So trying to access a HW that does not exist is totally legal in that
> sense? Is HW NOT supposed to generate an error in this case - as far as
> I had read, any access to non existent physical addresses should result
> in a bus error ... no?

This will cause Unsupported Request Error. But how it is handled
depends on platform, I think.

Thanks,
Kenji Kaneshige




  parent reply	other threads:[~2010-03-08  8:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18  6:17 How does Linux handle PCI-E Surprise unplug? Rajat Jain
2010-02-18 14:52 ` Greg KH
2010-02-19  4:13 ` Rajat Jain
2010-02-19  4:27 ` Greg KH
2010-02-19  6:41 ` Hidetoshi Seto
2010-03-08  7:23 ` Rajat Jain
2010-03-08  8:24 ` Kenji Kaneshige [this message]
2010-03-08 22:49 ` Grant Grundler

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=4B94B43B.7060202@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-hotplug@vger.kernel.org \
    /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.