linux-hotplug.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).