From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EDC8F3B19BC; Fri, 4 Sep 2026 05:55:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788501346; cv=none; b=tgzgoxUKRvKXc9A3mn68oJE71QuiJL8X7SDdldf7yuizTnb8tnFAW7dihbzAolVMkSO3MM7tQR9DUh4LljX5juNXCC9H0dA51FFiny6Gb2DPOaDWZG1vAG631ByD11pXUPOoaFDjJm9NLeotqQ0jQs5Cu5djFLuTYg20nwpEoeQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788501346; c=relaxed/simple; bh=DSaxOVmy1udjxSz7zd1Cgx8qXlWH7hLUWjdXrt69Sbo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n2piWBUyoF3vJZNqUVzvboKZ2fxHs4myIpg/+S8J/QatnHapb19GRawgs7zfSyf0Aegle/Hakso9l3+STd96LjCIpRtAMY4AzAevYV7XLUW4njv0F/t/Ych1iAWXmQP4kohzPO4txsUsmENVq1ip8WqOVvINfn0uVVxz+gHNN4I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=hHjZP87R; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="hHjZP87R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 535A41F00A3D; Fri, 4 Sep 2026 05:55:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788501344; bh=wMbQoBvYPizCMlz332mp4LN9dSlPUO9yvPz+ECCd960=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hHjZP87Rn/DvPBpfFPE5vk/hbrHCbFIsnY8099JPeBIxTK70UmlbsK2dL7MhJOgGM ayO0fzXkqsTDPenIl6JaNnEK6t0eO0ju7P5QnpGbdSghbObXtTLviUxJSvWwAWXXz3 XWGvV+ej5LloCPE0DOV7jf9s0jmPEqZvX+IJ+G54= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Fan Wu , Sebastian Reichel Subject: [PATCH 6.18 376/552] power: supply: rt9455: quiesce delayed work before teardown Date: Fri, 4 Sep 2026 06:58:53 +0200 Message-ID: <20260904045758.745879237@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904045747.813364717@linuxfoundation.org> References: <20260904045747.813364717@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Fan Wu commit 3e7a1ebc32fad5a558254a478efd401c17a24381 upstream. The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself. rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled: rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed. Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter. This issue was found by an in-house static analysis tool. Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260723225310.12663-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman --- drivers/power/supply/rt9455_charger.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) --- a/drivers/power/supply/rt9455_charger.c +++ b/drivers/power/supply/rt9455_charger.c @@ -1582,6 +1582,19 @@ static const struct regmap_config rt9455 .cache_type = REGCACHE_MAPLE, }; +static void rt9455_cancel_all_delayed_works(void *data) +{ + struct rt9455_info *info = data; + + /* + * Both pwr_rdy_work and batt_presence_work can queue + * max_charging_time_work, so cancel them first. + */ + cancel_delayed_work_sync(&info->pwr_rdy_work); + cancel_delayed_work_sync(&info->batt_presence_work); + cancel_delayed_work_sync(&info->max_charging_time_work); +} + static int rt9455_probe(struct i2c_client *client) { struct i2c_adapter *adapter = client->adapter; @@ -1672,6 +1685,10 @@ static int rt9455_probe(struct i2c_clien goto put_usb_notifier; } + ret = devm_add_action_or_reset(dev, rt9455_cancel_all_delayed_works, info); + if (ret) + goto put_usb_notifier; + ret = devm_request_threaded_irq(dev, client->irq, NULL, rt9455_irq_handler_thread, IRQF_TRIGGER_LOW | IRQF_ONESHOT, @@ -1712,10 +1729,6 @@ static void rt9455_remove(struct i2c_cli if (info->nb.notifier_call) usb_unregister_notifier(info->usb_phy, &info->nb); #endif - - cancel_delayed_work_sync(&info->pwr_rdy_work); - cancel_delayed_work_sync(&info->max_charging_time_work); - cancel_delayed_work_sync(&info->batt_presence_work); } static const struct i2c_device_id rt9455_i2c_id_table[] = {