On Fri, Feb 8, 2013 at 3:33 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> On Fri, Feb 8, 2013 at 1:14 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>> On Fri, Feb 8, 2013 at 12:28 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
>>> For physical hot plug should be ok, but for remove/rescan path will
>>> need us to disable that.
>>>
>>> otherwise rescan mmio resource for pci ioapic device will not be
>>> sized and allocated, aka skiped.
>>
>> When we scan other PCI devices, we can size memory BARs even if
>> PCI_COMMAND_MEMORY is already set. So there must be something
>> different about IOAPICs? Or maybe it's something different about
>> rescan vs. the initial scan?
>
> it is in drivers/pci/setup-bus.c::__dev_sort_resources()
> it will skip the reallocation for ioapic controller.
>
> ...
> /* Don't touch ioapic devices already enabled by firmware */
> if (class == PCI_CLASS_SYSTEM_PIC) {
> u16 command;
> pci_read_config_word(dev, PCI_COMMAND, &command);
> if (command & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY))
> return;
> }
>
>>
>>> For ioapic_probe:pci_enable_device will not enable the device
>>> correctly, and will bail out early.
>>
>> Exactly where and why do we bail out early? The only early bail out I
>> see is where __pci_enable_device_flags() returns if "dev->enable_cnt >
>> 1". Is that what you mean?
>
> pci_enable_device==>pci_enable_device_flags
> ==>do_pci_enable_device==>pcibios_enable_device==>pci_enable_resources
> ...
> if (!r->parent) {
> dev_err(&dev->dev, "device not available "
> "(can't reserve %pR)\n", r);
> return -EINVAL;
> }
> ...
>
> only reassign one will have get it's parent.
Hmmm, OK. So basically this patch is a hack to work around previous
hacks elsewhere.
We are like flies in a spider's web, bound tighter and tighter by
every loop of silk.
--
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
