On Wednesday, March 11, 2015 10:04:42 PM Luck, Tony wrote: > >> Unfortunately there's a long standing comment in pci_device_remove(): > >> > >> /* > >> * We would love to complain here if pci_dev->is_enabled is set, that > >> * the driver should have called pci_disable_device(), but the > >> * unfortunate fact is there are too many odd BIOS and bridge setups > >> * that don't like drivers doing that all of the time. > >> * Oh well, we can dream of sane hardware when we sleep, no matter how > >> * horrible the crap we have to deal with is when we are awake... > >> */ > >> > >> So, unless we can somehow ignore that comment, I suspect forcing the > >> device to be disabled on driver remove, whether done from pci-core or > >> from x86/pci, is going to cause all sorts of breakage. Are the > >> expectations set by b4b55cda5874 really valid? It seems like something > >> needs to be done to allow the IRQ to be automatically re-established on > >> x86 regardless of the driver doing the right thing when releasing the > >> device. We're still looking at a regression for v4.0 as a result of > >> b4b55cda5874. > > > > In which case we probably should revert commit b4b55cda5874 for the time being. > > > > At least I'd be very nervous about any ad-hoc fixes at this stage of the cycle. > > The comment goes back to the dawn of "git" time ... not sure how much further > back. > > Is this actually still an issue on modern systems? Maybe we need a black list > or white list to separate the good from bad systems? The answer to that is "We don't know" and in my not so humble opinion it is too risky to try to find out at the end of the cycle. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
