- 01 Dec, 2020 11 commits
-
-
Ahmed S. Darwish authored
qla82xx_idc_lock() spins on a certain hardware state until it's updated. At the end of each spin, if in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it yields the CPU. While in_interrupt() is ill-defined and does not provide what the name suggests, it is not needed here: qla82xx_idc_lock() is always called from process context. Below is an analysis of its callers, in order of appearance: - qla_nx.c: qla82xx_device_bootstrap(), only called by qla82xx_device_state_handler(), has multiple msleep()s. - qla_nx.c: qla82xx_need_qsnt_handler(), has one second msleep() - qla_nx.c: qla82xx_wait_for_state_change(), one second msleep() - qla_nx.c: qla82xx_need_reset_handler(), can sleep up to 10 seconds - qla_nx.c: qla82xx_device_state_handler(), has multiple msleep()s - qla_nx.c: qla82xx_abort_isp(), if it's a qla82xx controller, calls qla82xx_device_state_handler(), which sleeps. It's also bound to isp_operations ->abort_isp() hook, where all the callers are in process context. - qla_nx.c: qla82xx_beacon_on(), bound to isp_operations ->beacon_on() hook. That hook is only called once, in a mutex locked context, from qla2x00_beacon_store(). - qla_nx.c: qla82xx_beacon_off(), bound to isp_operations ->beacon_off() hook. Like ->beacon_on(), it's only called once, in a mutex locked context, from qla2x00_beacon_store(). - qla_nx.c: qla82xx_fw_dump(), calls qla2x00_wait_for_chip_reset(), which has msleep() in a loop. It is bound to isp_operations ->fw_dump() hook. That hook *is* called from atomic context at qla_isr.c by multiple interrupt handlers. Nonetheless, it's other controllers interrupt handlers, and not the qla82xx. - qla82xx_msix_default() and qla82xx_msix_rsp_q() call qla24xx_process_response_queue() which doesn't implement the firmware dumping. - qla_attr.c: qla2x00_sysfs_write_fw_dump(), and qla2x00_sysfs_write_reset(), process-context sysfs ->write() hooks. - qla_os.c: qla2x00_probe_one(). PCI ->probe(), process context. - qla_os.c: qla2x00_clear_drv_active(), called solely from qla2x00_remove_one(), which is PCI ->remove() hook, process context. - qla_os.c: qla2x00_do_dpc(), kthread function, process context. Remove the in_interrupt() check. Change qla82xx_idc_lock() specification to a purely process-context function. Mark it with "Context: task, might sleep". Change qla82xx_idc_lock() implementation to sleep 100ms, instead of a schedule(), for each spin. This is more deterministic, and it matches the other qla models idc_lock() functions. Link: https://lore.kernel.org/r/20201126132952.2287996-5-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by:Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by:
Daniel Wagner <dwagner@suse.de> Signed-off-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Ahmed S. Darwish authored
qla4_82xx_crb_win_lock() spins on a certain hardware state until it's updated. At the end of each spin, if in_interrupt() is true, it does 20 loops of cpu_relax(). Otherwise, it yields the CPU. The in_interrupt() macro is ill-defined as it does not provide what the name suggests, and it does not catch the intended use-case here. qla4_82xx_crb_win_lock() is always invoked with scsi_qla_host::hw_lock acquired, with disabled interrupts. If the caller is in process context, as in qla4_82xx_need_reset_handler(), then in_interrupt() will return false even though it is not allowed to call schedule(). Remove the in_interrupt() check. Change qla4_82xx_crb_win_lock() specification to a purely atomic function. Mark it as static, remove its forward declaration, and move it above its callers. To avoid hammering the PCI bus while spinning, use a 10 micro-second delay instead of cpu_relax(). Link: https://lore.kernel.org/r/20201126132952.2287996-4-bigeasy@linutronix.de Fixes: f4f5df23 ("[SCSI] qla4xxx: Added support for ISP82XX") Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by:
-
Ahmed S. Darwish authored
hisi_sas_task_exec() uses preemptible() to see if it's safe to block. This does not work for CONFIG_PREEMPT_COUNT=n kernels in which preemptible() always returns 0. The problem is masked when enabling some of the common Kconfig.debug options (like CONFIG_DEBUG_ATOMIC_SLEEP), as they implicitly enable the preemption counter. In general, driver leaf functions should not make logic decisions based on the context they're called from. The caller should be the entity responsible for explicitly indicating context. Since hisi_sas_task_exec() already has a gfp_t flags parameter, use it as the explicit context marker. Link: https://lore.kernel.org/r/20201126132952.2287996-3-bigeasy@linutronix.de Fixes: 214e702d ("scsi: hisi_sas: Adjust task reject period during host reset") Fixes: 550c0d89 ("scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec()") Cc: Xiaofei Tan <tanxiaofei@huawei.com> Cc: Xiang Chen <chenxiang66@hisilicon.com> Cc: John Garry <john.garry@huawei.com> Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Ahmed S. Darwish authored
hw_event_sas_phy_up() is used in hardirq/softirq context: pm8001_interrupt_handler_msix() || pm8001_interrupt_handler_intx() || pm8001_tasklet => PM8001_CHIP_DISP->isr() = pm80xx_chip_isr() => process_oq() [spin_lock_irqsave(&pm8001_ha->lock,)] => process_one_iomb() => mpi_hw_event() => hw_event_sas_phy_up() => msleep(200) Revert the msleep() back to an mdelay() to avoid sleeping in atomic context. Link: https://lore.kernel.org/r/20201126132952.2287996-2-bigeasy@linutronix.de Fixes: 4daf1ef3 ("scsi: pm80xx: Convert 'long' mdelay to msleep") Cc: Vikram Auradkar <auradkar@google.com> Cc: Jack Wang <jinpu.wang@cloud.ionos.com> Acked-by:Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
-
Bean Huo authored
In the case that auto_bkops_enable is false, which means auto bkops has been disabled, there is no need to call ufshcd_disable_auto_bkops(). Link: https://lore.kernel.org/r/20201125185300.3394-1-huobean@gmail.comReviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Luo Jiaxing authored
Relocate all the debugfs code for DFX to v3 hw since no other versions support it. Link: https://lore.kernel.org/r/1606207594-196362-4-git-send-email-john.garry@huawei.comSigned-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
-
Xiang Chen authored
Fix some rollbacks in function hisi_sas_v3_probe() and interrupt_init_v3_hw(). Link: https://lore.kernel.org/r/1606207594-196362-3-git-send-email-john.garry@huawei.com Fixes: 8d98416a ("scsi: hisi_sas: Switch v3 hw to MQ") Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
John Garry authored
Sometimes local functions are called indirectly from the hw driver, which only makes the code harder to follow. Remove these. Method .hw_init is only called from platform driver probe, which is not relevant, so don't set this either. Link: https://lore.kernel.org/r/1606207594-196362-2-git-send-email-john.garry@huawei.comSigned-off-by:
-
Colin Ian King authored
There are two words that need separating with a space in a pm8001_dbg() message. Fix it. Link: https://lore.kernel.org/r/20201124093828.307709-1-colin.king@canonical.comReviewed-by:
Ewan D. Milne <emilne@redhat.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Joe Perches authored
kernel robot reported a misindentation of a goto. Fix it. At the same time, use a temporary for a repeated entry in the same block to reduce visual noise. Link: https://lore.kernel.org/r/9542a8be9954c1dca744f93f53bb1af6dd1436e8.1606192458.git.joe@perches.comReported-by:
kernel test robot <lkp@intel.com> Acked-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Use the more common logging style. [mkp: fixed a few conflicts] Link: https://lore.kernel.org/r/69dc34ff63adfa60b3f203ed2d58143b5692af57.1606192458.git.joe@perches.comAcked-by:
-
- 26 Nov, 2020 29 commits
-
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-30-vaibhavgupta40@gmail.comSigned-off-by:
Vaibhav Gupta <vaibhavgupta40@gmail.com> Signed-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in pmcraid_resume(), and there is no corresponding pci_enable_wake(...., true) in pmcraid_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from pmcraid_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-29-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
There is no "device" parameter in mvumi_shutdown(). Instead there is "pdev" which is not described. Link: https://lore.kernel.org/r/20201102164730.324035-28-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-27-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in mvumi_resume(), and there is no corresponding pci_enable_wake(...., true) in mvumi_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from mvumi_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-26-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-25-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in twl_resume(), and there is no corresponding pci_enable_wake(...., true) in twl_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from twl_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-24-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-23-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in twa_resume(), and there is no corresponding pci_enable_wake(...., true) in twa_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from twa_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-22-vaibhavgupta40@gmail.comAcked-by:
Don Brace <don.brace@microchip.com> Signed-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-21-vaibhavgupta40@gmail.comAcked-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-20-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in pm8001_pci_resume(), and there is no corresponding pci_enable_wake(...., true) in pm8001_pci_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from pm8001_pci__resume(). Link: https://lore.kernel.org/r/20201102164730.324035-19-vaibhavgupta40@gmail.comAcked-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-18-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-17-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in scsih_resume(), and there is no corresponding pci_enable_wake(...., true) in scsih_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from scsih_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-16-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Both runtime_suspend_v3_hw() and runtime_resume_v3_hw() do nothing else but invoke suspend_v3_hw() and resume_v3_hw() respectively. This is the case of unnecessary function calls. To use those functions for runtime pm as well, simply use UNIVERSAL_DEV_PM_OPS. make -j$(nproc) W=1, with CONFIG_PM disabled, throws '-Wunused-function' warning for runtime_suspend_v3_hw() and runtime_resume_v3_hw(). After dropping those function definitions, the warning was thrown for suspend_v3_hw() and resume_v3_hw(). Hence, mark them as '__maybe_unused'. Link: https://lore.kernel.org/r/20201102164730.324035-15-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers using new-framework/generic-framework should not handle standard power management operations. These operations were performed by legacy framework through PCI helper functions like pci_save/restore_state(), pci_set_power_state(), etc. Drivers should not use them now. Link: https://lore.kernel.org/r/20201102164730.324035-14-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in hisi_sas_v3_resume(), and there is no corresponding pci_enable_wake(...., true) in hisi_sas_v3_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from hisi_sas_v3_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-13-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-12-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in esas2r_resume(), and there is no corresponding pci_enable_wake(...., true) in esas2r_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from esas2r_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-11-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-10-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in arcmsr_resume(), and there is no corresponding pci_enable_wake(...., true) in arcmsr_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from arcmsr_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-9-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-8-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-7-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-6-vaibhavgupta40@gmail.comAcked-by:
Balsundar P <balsundar.p@microchip.com> Signed-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in aac_resume(), and there is no corresponding pci_enable_wake(...., true) in aac_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this is a bug and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from aac_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-5-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Function parameter 'pdev 'is described as Generic Device Structure. It is a PCI device structure. Link: https://lore.kernel.org/r/20201102164730.324035-4-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. Link: https://lore.kernel.org/r/20201102164730.324035-3-vaibhavgupta40@gmail.comSigned-off-by:
-
Vaibhav Gupta authored
The driver calls pci_enable_wake(...., false) in megasas_resume(), and there is no corresponding pci_enable_wake(...., true) in megasas_suspend(). Either it should do enable-wake the device in .suspend() or should not invoke pci_enable_wake() at all. Concluding that this driver doesn't support enable-wake and PCI core calls pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from megasas_resume(). Link: https://lore.kernel.org/r/20201102164730.324035-2-vaibhavgupta40@gmail.comSigned-off-by:
-
