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:5.015 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site