Re: PCIe hotplug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nishank wrote:
On 04/20/2010 01:38 AM, Kenji Kaneshige wrote:
Nishank Trivedi wrote:
On 04/19/2010 05:41 PM, Kenji Kaneshige wrote:
Greg KH wrote:
On Mon, Apr 19, 2010 at 12:45:44PM -0700, Nishank wrote:
Hi,

I'm trying understand PCIe hot-plugging and surprise removal as
supported in kernel. I am using a board having Ibex Peak. Can
someone please help me understand -
1. Which is the relevant driver for pcie hp for this board? (looks
like pciehp but I see others as well - shpchp)

Depends on the hardware, what does yours have on it?

2. Is there a specific user-space utility for safe removal of PCIe?
Seems like it should be something like - quiesce, unbind, power-off.

You can do it with a simple one line bash script:
echo 0 > /sys/bus/pci/slot/SLOT_NUMBER/power
Yes, however, driver needs to handle 0xFF reads.


echo 0 > /sys/.../power unbinds the driver (this makes the device
quiescent) and turns the slot power off. So 0xFF reads (unsupported
request) doesn't happen.

If you're talking about the 0xFF reads that is caused by the driver's
device access after the surprise removal before driver unbinding, yes,
driver needs to handle 0xFF reads.
Yes, I was referring to latter.




Or you can use the very old pcihpview GUI tool if you really like those
types of things.

Or you can just press the button on the back of your machine that
controls the power to the slot.

3. Is there any existing driver which supports PCIe surprise
removal? Also, when pcie slot has been powered off (as in
handle_suprise_event() in pciehp), how is the driver notified about
it?

The pciehp driver handles pcie device removal, assuming that is what is
controlling the hardware. It is notified through the PCIe standard way
(go read the PCI spec for the boring details...)

The pciehp driver detects surprise removal through presence detect
changed event.
Actually Extended error handling driver shows something similar. In
fact, their documentation is also really good.
One more question I had was, on a hotplug event, what is prompting the
re-enumeration of bus? update_slot_info() seems to be setting status
specific to that slot only.

On surprise removal, pciehp doesn't re-enumerate the bus. It unbinds
the driver and frees the struct pci_dev and so on associated with the
removed device.
However, when device is added back, re-enumeration is needed but I didn't quite understand what is prompting it.

When device is added back, another presence changed event will be notified.
The pciehp driver will re-enumerates the bus on that event.



By the way, I don't think surprise removal is well tested unfortunately.
Looks like i'll be testing it out.


I cannot test surprise removal because I don't have any surprise removal
capable environment. But I will contribute on trouble shooting as far as
possible.

Thanks,
Kenji Kaneshige

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux