All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: How does Linux handle PCI-E Surprise unplug?
Date: Mon, 08 Mar 2010 22:49:36 +0000	[thread overview]
Message-ID: <20100308224936.GC14858@lackof.org> (raw)
In-Reply-To: <8506939B503B404A84BBB12293FC45F606B883BA@emailbng3.jnpr.net>

On Mon, Mar 08, 2010 at 12:41:33PM +0530, Rajat Jain wrote:
...
> 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?

What Kenji said.

> 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?

Yes and no. Depends on who you ask. Old intel platforms tolerated
this just fine. Many other !intel platforms did not.

> 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?

Correct. The access will result in a "Master Abort" (timeout when device
fails to respond.) This is when the platform dependent behaviour
comes into play. "Hard Fail" systems will end up in a system error
handler (HPMC, MCE, or equivalent) and "Soft Fail" systems (like
older Intel) will have the chipset return ~0 (and some ancient PCI
chipsets had BIOS return 0 instead).

hth,
grant

      parent reply	other threads:[~2010-03-08 22:49 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
2010-03-08 22:49 ` Grant Grundler [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=20100308224936.GC14858@lackof.org \
    --to=grundler@parisc-linux.org \
    --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.