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 E3CF2401A25; Fri, 4 Sep 2026 05:59:23 +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=1788501565; cv=none; b=P7wjP7FLHMZ4ChUbVW4V0lNgfAeZ3IbSKxz6xSmZ/RRM7ztvzn7+GAxmQrRVGnENTCjKuPdEUKbBFbFgn+ddon+FxQ2xiwjDNBAKVB05lm967ViQH6gWf7lW2u8YWk1LX/k4coAiHoOBN6hZc9Tr5SrR3YLJwliUVq2sMGzPNCY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788501565; c=relaxed/simple; bh=mDCJtOuFWhBPNDii+GLL1vu8/M4Yzvl/No5KBU+kpDA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UnzA+rXhX3aH5warH4CuNW+aFxOBTmRW9krdomW0W8tfu1JIaCJux2gb57J9rjGhOZzfmUHrzb6cXXCeixTGnvoFrKYQMDKznzLZKIdsqqKSQzksU6fipZF7WXfA4FrGXZ/GnnCPwPubCmVrHUMJvV3sl0BC+Pll+ZjCgSrRb3Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=jX2WUnL+; 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="jX2WUnL+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53CB01F00A3D; Fri, 4 Sep 2026 05:59:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788501563; bh=Lm9DMO1uLsPSSyv2N4Vgc3UMmbo5zb4Y3xmR5umq0ec=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jX2WUnL+y6naLu2/XMrBEbrOzHjZ9yzFnlhWEJdneGzmHDNNW6JsfwyTKJIAtLXG8 MBmlZbvCZKehEF/fqSxrrnGKMfKI0ilKzLV+JksSvgPuh7pFuQO7arBKCqmhwKQhUK lMpvwK24yG9cQTWvAhlAyGS9Xv0QzT865kD06O0E= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ahmad Fatoum , Oleksij Rempel , =?UTF-8?q?Alvin=20=C5=A0ipraga?= , Linus Walleij , Luiz Angelo Daros de Luca , Jakub Kicinski Subject: [PATCH 6.18 455/552] net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO Date: Fri, 4 Sep 2026 07:00:12 +0200 Message-ID: <20260904045801.017869821@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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ahmad Fatoum commit fb58b6a696b30bcbfbe0cfc0a91b19c816a955fc upstream. rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns: WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events_unbound deferred_probe_work_func pc : gpiod_set_value+0x44/0x80 lr : rtl83xx_probe+0x1d8/0x3a0 Call trace: gpiod_set_value+0x44/0x80 (P) rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0 __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Cc: # 6.9.x Signed-off-by: Ahmad Fatoum Co-developed-by: Oleksij Rempel Signed-off-by: Oleksij Rempel Reviewed-by: Alvin Šipraga Reviewed-by: Linus Walleij Reviewed-by: Luiz Angelo Daros de Luca Link: https://patch.msgid.link/20260814110102.2362246-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- drivers/net/dsa/realtek/rtl83xx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/dsa/realtek/rtl83xx.c +++ b/drivers/net/dsa/realtek/rtl83xx.c @@ -309,7 +309,7 @@ void rtl83xx_reset_assert(struct realtek "Failed to assert the switch reset control: %pe\n", ERR_PTR(ret)); - gpiod_set_value(priv->reset, true); + gpiod_set_value_cansleep(priv->reset, true); } void rtl83xx_reset_deassert(struct realtek_priv *priv) @@ -322,7 +322,7 @@ void rtl83xx_reset_deassert(struct realt "Failed to deassert the switch reset control: %pe\n", ERR_PTR(ret)); - gpiod_set_value(priv->reset, false); + gpiod_set_value_cansleep(priv->reset, false); } MODULE_AUTHOR("Luiz Angelo Daros de Luca ");