On 2014/12/18 3:09, Bjorn Helgaas wrote: > On Wed, Dec 17, 2014 at 12:36 AM, Yijing Wang <wangyijing@xxxxxxxxxx> wrote: >> On 2014/12/17 14:21, ratheesh kannoth wrote: >>> On Wed, Dec 17, 2014 at 11:44 AM, Yijing Wang <wangyijing@xxxxxxxxxx> wrote: >>>> Unbind won't release PCI device bar resource, resources in /proc/iomem is the >>>> physical address resource(added by request_resource()), if you iounmap the bar resource, >>>> it won't change anything in /proc/iomem. >>> >>> who is calling request_resource() ...is it enic driver ? >> >> PCI core interface, E.g pci_bus_assign_resources() > > Hi Ratheesh, > > There are two things going on in /proc/iomem: > > 1) The core should put all the hardware that responds to physical > accesses in /proc/iomem. These entries should be there regardless of > whether we have a driver for the device. These are used when > assigning addresses to new devices, to make sure we don't assign the > same address to two different devices. These entries include RAM, > ACPI tables, APICs, PCI host bridges, PCI MMCONFIG regions, PCI > devices, etc. It *should* also include address space consumed by > other things like PNP and ACPI devices, but that is currently missing. > > 2) Individual drivers claim address space they use to control their > device, e.g., with pci_request_regions(), ioremap(), etc. This puts > an entry in /proc/iomem with the driver name on it. A device may > respond to several physical address regions, and a driver need not > claim all of them, and it may even claim only part of a region. Yes, exactly, I missed this. > > So when you unbind a driver, you should see the second type of entry > go away. When you actually remove a device (hot-remove or sysfs > remove), you should see the first type go away as well, which means > there's no longer anything that will respond to that physical address > space. > > Bjorn > > -- Thanks! Yijing -- 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
