The dwc3->gadget_driver is not initialized during the dwc3 probe
process. This leads to a warning when the runtime power management (PM)
attempts to suspend the gadget using dwc3_gadget_suspend().
This patch adds a check to prevent the warning.
Cc: stable(a)vger.kernel.org
Fixes: 61a348857e86 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend")
Signed-off-by: Ray Chi <raychi(a)google.com>
---
drivers/usb/dwc3/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 28f49400f3e8..de987cffe1ec 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -4708,6 +4708,9 @@ int dwc3_gadget_suspend(struct dwc3 *dwc)
unsigned long flags;
int ret;
+ if (!dwc->gadget_driver)
+ return 0;
+
ret = dwc3_gadget_soft_disconnect(dwc);
if (ret)
goto err;
--
2.44.0.rc0.258.g7320e95886-goog
psci_init_system_suspend() invokes suspend_set_ops() very early during
bootup even before kernel command line for mem_sleep_default is setup.
This leads to kernel command line mem_sleep_default=s2idle not working
as mem_sleep_current gets changed to deep via suspend_set_ops() and never
changes back to s2idle.
Move psci_init_system_suspend() to late_initcall() to make sure kernel
command line mem_sleep_default=s2idle sets up s2idle as default suspend
mode.
Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support")
CC: stable(a)vger.kernel.org # 5.15+
Signed-off-by: Maulik Shah <quic_mkshah(a)quicinc.com>
---
drivers/firmware/psci/psci.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index d9629ff87861..655a2db70a67 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -523,18 +523,26 @@ static void __init psci_init_system_reset2(void)
psci_system_reset2_supported = true;
}
-static void __init psci_init_system_suspend(void)
+static int __init psci_init_system_suspend(void)
{
int ret;
+ u32 ver;
if (!IS_ENABLED(CONFIG_SUSPEND))
- return;
+ return 0;
+
+ ver = psci_0_2_get_version();
+ if (PSCI_VERSION_MAJOR(ver) < 1)
+ return 0;
ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND));
if (ret != PSCI_RET_NOT_SUPPORTED)
suspend_set_ops(&psci_suspend_ops);
+
+ return ret;
}
+late_initcall(psci_init_system_suspend)
static void __init psci_init_cpu_suspend(void)
{
@@ -651,7 +659,6 @@ static int __init psci_probe(void)
if (PSCI_VERSION_MAJOR(ver) >= 1) {
psci_init_smccc();
psci_init_cpu_suspend();
- psci_init_system_suspend();
psci_init_system_reset2();
kvm_init_hyp_services();
}
---
base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118
change-id: 20240219-suspend_ops_late_init-27fb0b15baee
Best regards,
--
Maulik Shah <quic_mkshah(a)quicinc.com>
I'm new here, first time reporting a regression, apologies in advance if
I'm doing something wrong of if this was already reported (I found some
CIFS issues but not exactly this one).
I'm using x86-64 Arch Linux and LTS kernel (6.1.71 as I write this) and
I noticed a regression that I could reproduce in other boxes with other
architectures as well (aarch64 with 6.1.70).
# mount.cifs //server/share /mnt
# mount
//server/share on /mnt type cifs (rw,relatime,vers=3.1.1...)
# cd /mnt
# df .
df: .: Resource temporarily unavailable
# ls -al
ls: .: Resource temporarily unavailable
ls: file1: Resource temporarily unavailable
ls: file2: Resource temporarily unavailable
[...then ls shows the listing...]
If I use strace with df, the problem is:
statfs(".", 0x.....) = -1 EAGAIN (Resource temporarily unavailable)
And with ls:
listxattr(".", 0x..., 152): -1 EAGAIN (Resource temporarily unavailable)
listxattr("file1", ..., 152): -1 EAGAIN (same as above)
...
Initially I thought the problem was with the Samba server and/or the
client mount flags, but I've spent a day trying a *lot* of different
combinations and nothing worked. This happens with any share that I try,
and I've tried mounting shares from multiple Linux boxes running
different Samba and kernel versions.
Then I tried changing kernel versions at my client box. I booted latest
6.6.9 and the problem simply disappeared. My Debian server with 6.5.11
also doesn't have it. I then started a VM and tried a "bisection" of
6.1.x versions, leading to kernel 6.1.70 when this started to happen.
6.1.69 and older look fine.
I hope that this is enough information to reproduce this issue. I will
be glad to provide more info if necessary.
// Leonardo.