Hi Prarit,
On Mon, May 25, 2015 at 07:36:58PM -0400, Prarit Bhargava wrote:
> During system init, acpi_pci_root_add() is called which uses ACPI information to
> reserve memory and IO regions for PCI devices under the root bridge.
>
> If I hot remove a device, by echo'ing 1 into its remove file, and then
> rescanning the parent bus (in this case the same bridge discovered by
> acpi_pci_root_add()) by echo'ing 1 into the rescan file, the code path calls
>
> unsigned int pci_rescan_bus(struct pci_bus *bus)
> {
> unsigned int max;
>
> max = pci_scan_child_bus(bus);
> pci_assign_unassigned_bus_resources(bus);
> pci_bus_add_devices(bus);
>
> return max;
> }
>
> which AFAICT does not take into account ACPI Memory and IO regions for devices
> under the bridge. Is there an obvious reason to do this? Or is there some
> other init required before I issue the rescan on the bus?
>
> Or ... is this a bug?
>
> FWIW, I am removing a PCI Serial port card by echo'ing 1 into its remove file
> and then reinserting it by doing a rescan on the parent bus. The card does not
> come up with the same memory & IO as it initially had. I would have expected
> that it did come up with the same resources as the memory & IO are free... but
> maybe that expectation is incorrect.
It might be quicker if you posted the complete dmesg log, along with
pointers to the specific things that look wrong.
In this scenario, I assume the serial port device remains powered all the
time, even while it is logically removed from the system, so when we
re-enumerate and find the device, I would think its BARs would still
contain whatever they had before, and since they are still valid, we should
still use them.
So I think my expectation is the same as yours, and I don't know why it
doesn't work that way. I assume the device actually *works* with the new
resources, so it's not really broken in that sense, but it does bother me
if we're changing something when we don't need to change it.
Bjorn
--
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
