Hi 2011/8/12 Bjorn Helgaas <bhelgaas@xxxxxxxxxx>: > We usually funnel PNP stuff through the linux-acpi@xxxxxxxxxxxxxxx > mailing list, so I added a cc: to it. > Thanks for your reminding! > request_region() is not a drop-in replacement for __check_region() > because __check_region() releases the resource before it returns > success. I agree that it would be good to get rid of > __check_region(), but I think it's a little more work than just this. > > I suppose you could just do the release_resource() in > pnp_check_port(), after request_region() was successful. But the > problem with __check_region() is that it's racy, and moving the > release_resource() into pnp_check_port() doesn't remove the race. It > just moves the problem from __check_region() (which is easy to grep > for) into PNP (where it's not so obvious). > I don't think the racy is still exist. In old days, the racy is exist in this situation: check_region() ...do something <-- here another process may do check and request same region request_region() <-- if some process request the same resource, it will fail here But nowadays, request_region has replaced the check_region, it will check and request in the same function, so no racy still exist. Am I right? > Part of the problem is that the PNP core doesn't actually request any > of the resources used by PNP devices. The PCI core *does* reserve > resources, independent of any drivers, and it would certainly be > reasonable to expect the PNP core to do the same, but it doesn't. > This is mostly because there are a bunch of hardcoded legacy resources > that conflict with PNP devices, and we haven't figured out a good way > to resolve the conflicts. > > Bjorn > -- Wang Shaoyan -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
