lkml.org 
[lkml]   [2021]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
Date
On Tue, Dec 14 2021 at 17:36, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
>> On 10:41-20211214, Thomas Gleixner wrote:
> [ 13.478122] Call trace:
> [ 13.509042] msi_device_destroy_sysfs+0x18/0x88
> [ 13.509058] msi_domain_free_irqs+0x34/0x58
> [ 13.509064] pci_msi_teardown_msi_irqs+0x30/0x3c
> [ 13.509072] free_msi_irqs+0x78/0xd4
> [ 13.509077] pci_disable_msix+0x138/0x164
> [ 13.529930] pcim_release+0x70/0x238
> [ 13.529942] devres_release_all+0x9c/0xfc
> [ 13.529951] device_release_driver_internal+0x1a0/0x244
> [ 13.542725] device_release_driver+0x18/0x24
> [ 13.542741] iwl_req_fw_callback+0x1a28/0x1ddc [iwlwifi]
> [ 13.552308] request_firmware_work_func+0x50/0x9c
> [ 13.552320] process_one_work+0x194/0x25c
>
> That's not a driver problem, that's an ordering issue vs. the devres
> muck. Let me go back to the drawing board. Sigh...

Which is pretty obvious why:

pcim_enable_device()
devres_alloc(pcim_release...);
...
pci_irq_alloc()
msi_setup_device_data()
devres_alloc(msi_device_data_release, ...)

and once the device is released:

msi_device_data_release()
...
pcim_release()
pci_disable_msi[x]()

Groan....

\
 
 \ /
  Last update: 2021-12-14 18:04    [W:0.113 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site