Once cdev_device_add() failed, we should use put_device() to decrement
reference count for cleanup. Or it could cause memory leak. Although
operations in err_free_ida are similar to the operations in callback
function fsi_slave_release(), put_device() is a correct handling
operation as comments require when cdev_device_add() fails.
As comment of device_add() says, 'if device_add() succeeds, you should
call device_del() when you want to get rid of it. If device_add() has
not succeeded, use only put_device() to drop the reference count'.
Found by code review.
Cc: stable(a)vger.kernel.org
Fixes: 371975b0b075 ("fsi/core: Fix error paths on CFAM init")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
drivers/fsi/fsi-core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 50e8736039fe..c494fc0bd747 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -1084,7 +1084,8 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id)
rc = cdev_device_add(&slave->cdev, &slave->dev);
if (rc) {
dev_err(&slave->dev, "Error %d creating slave device\n", rc);
- goto err_free_ida;
+ put_device(&slave->dev);
+ return rc;
}
/* Now that we have the cdev registered with the core, any fatal
@@ -1110,8 +1111,6 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id)
return 0;
-err_free_ida:
- fsi_free_minor(slave->dev.devt);
err_free:
of_node_put(slave->dev.of_node);
kfree(slave);
--
2.25.1
There is a nasty regression wrt mt7921e in the last LTS series (6.12).
If your computer crashes or fails to get out of hibernation, then at the
next boot the mt7921e wifi does not work, with dmesg reporting that it
is unable to change power state from d3cold to d0.
The issue is nasty, because rebooting won't help.
The only solution that I have found to the issue is booting a 6.6
kernel. With that the wife gets alive again. If, at this point, you boot
into 6.12, everything seems to be fine again, until a boot fails and
from that moment on you are without wifi.
Working around the issue is not very discoverable. On my machine not
even a hardware reset (40s of power off button pressed) helped alone,
without going through the 6.6 kernel boot.
I think the regression was introduced with 6.12 and I remember having no
issues with previous kernels, but cannot be 100% sure.
Similarly, I do not know if the bug is with the wifi card driver itself
or with something related to PM or PCIe.
The machine on which I am experiencing the issue is an Asus ROG 14
laptop (2022 edition), with AMD CPU and GPU.
Thanks for the attention,
Sergio
Dear stable
To whom it may Concern.
We PRIVATE COMPANY SGG ENERGY TECHNOLOGY LTD, With BIN Code:
211140900115 and Office address located at Astana, Esil District,
Syganak Street, Building 54a, N.P. 142A. With authorized legalized
mandate certificate from trusted and reliable supplier refinery of
petroleum commodities. Attached kindly find our official offer for
your review and if any of our give procedure is acceptable to any
ready buyer’s management, do kindly proceed to issue an official ICPO
to commence transaction.
And further your management is in need of assistance and further
clarification do not hesitate to contact our management.
Thank You.
---
PRIVATE COMPANY SGG ENERGY TECHNOLOGY LTD.
Address: Astana, Esil District, Syganak Street, Building 54a, N.P.
142A
BIN: 211140900115
Email:kazpetro@sggenergytech.com
Tel/WhatsApp: +7 775 540 3537
Director: Dou Shengjun