>> 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?
-Tony
N�����r��y����b�X��ǧv�^�){.n�+����{����zX����ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?�����&�)ߢf��^jǫy�m��@A�a���
0��h���i
