On Thu, 16 Jul 2009 20:38:44 +1000 Dave Airlie <airlied@xxxxxxxxx> wrote: > On Thu, Jul 16, 2009 at 6:48 PM, Alan Cox<alan@xxxxxxxxxxxxxxxxxxx> > wrote: > >> >> + pci_read_config_word(pdev, PCI_COMMAND, &cmd); > >> >> + if (rsrc & (VGA_RSRC_LEGACY_IO | VGA_RSRC_NORMAL_IO)) > >> >> + cmd |= PCI_COMMAND_IO; > >> >> + if (rsrc & (VGA_RSRC_LEGACY_MEM | VGA_RSRC_NORMAL_MEM)) > >> >> + cmd |= PCI_COMMAND_MEMORY; > >> >> + pci_write_config_word(pdev, PCI_COMMAND, cmd); > >> > > >> > Locking question - what locks this lot against hotplug also > >> > touching bridge settings ? > >> > >> well here we just bang on device config space registers which > >> means we can probably > >> race against lots of other things that rmw the PCI_COMMAND not > >> just hotplug. > >> > >> Perhaps we need some sort per device PCI command space lock, > >> granted this still means we race against anyone directly hacking it > >> behind our backs. > > > > I suspect the right thing to do is to move that function into the > > drivers/pci code and lock it properly there. That would keep all the > > locking detail internal and private (and someone else's problem ;)) > > I'll have a look, Jesse any ideas? the hotplug bridge bashing looks > unfun. > > I noticed a fair few drivers seem to bash these things, and really > pci_enable_device > could possible race with hotplug. Oh hm, yeah moving that sort of thing into the PCI core probably makes sense. Hotplug interactions would be good to get right here, since it might be possible to implement switchable graphics machines that way... -- Jesse Barnes, Intel Open Source Technology Center -- 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
