linux-kernel - Re: [PATCH] media: synopsys: hdmirx: support use with sleeping GPIOs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <18643681.geO5KgaWL5@phil>
Date: Fri, 09 Jan 2026 20:02:03 +0100
From: Heiko Stuebner <heiko@...ech.de>
To: Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Mark Brown <broonie@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
 Marek Szyprowski <m.szyprowski@...sung.com>, Aishwarya.TCV@....com,
 Robin.Murphy@....com, linux-media@...r.kernel.org, kernel@...labora.com,
 linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] media: synopsys: hdmirx: support use with sleeping GPIOs

Am Donnerstag, 8. Januar 2026, 21:08:47 Mitteleuropäische Normalzeit schrieb Mark Brown:
> The recent change in 20cf2aed89ac (gpio: rockchip: mark the GPIO
> controller as sleeping) to mark the rockchip GPIO driver as sleeping has
> started triggering the warning at drivers/gpio/gpiolib.c:3523 indicating
> that a sleepable GPIO was called via the non-sleeping APIs on the Rock 5B:
> 
> <4>[   14.699308] Call trace:
> <4>[   14.699545]  gpiod_get_value+0x90/0x98 (P)
> <4>[   14.699928]  tx_5v_power_present+0x44/0xd0 [synopsys_hdmirx]
> <4>[   14.700446]  hdmirx_delayed_work_hotplug+0x34/0x128 [synopsys_hdmirx]
> <4>[   14.701031]  process_one_work+0x14c/0x28c
> <4>[   14.701405]  worker_thread+0x184/0x300
> <4>[   14.701756]  kthread+0x11c/0x128
> <4>[   14.702065]  ret_from_fork+0x10/0x20
> 
> Currently the active use of the GPIO is all done from process context so
> can be simply converted to use gpiod_get_value_cansleep(). There is one use
> of the GPIO from hard interrupt context but this is only done so the status
> can be displayed in a debug print so can simply be deleted without any
> functional effect.
> 
> Signed-off-by: Mark Brown <broonie@...nel.org>

Reviewed-by: Heiko Stuebner <heiko@...ech.de>

> ---
>  drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> index c3007e09bc9f..1eaa25efee21 100644
> --- a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> +++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> @@ -230,7 +230,7 @@ static bool tx_5v_power_present(struct snps_hdmirx_dev *hdmirx_dev)
>  
>  	for (i = 0; i < 10; i++) {
>  		usleep_range(1000, 1100);
> -		val = gpiod_get_value(hdmirx_dev->detect_5v_gpio);
> +		val = gpiod_get_value_cansleep(hdmirx_dev->detect_5v_gpio);
>  		if (val > 0)
>  			cnt++;
>  		if (cnt >= detection_threshold)
> @@ -2204,10 +2204,6 @@ static void hdmirx_delayed_work_res_change(struct work_struct *work)
>  static irqreturn_t hdmirx_5v_det_irq_handler(int irq, void *dev_id)
>  {
>  	struct snps_hdmirx_dev *hdmirx_dev = dev_id;
> -	u32 val;
> -
> -	val = gpiod_get_value(hdmirx_dev->detect_5v_gpio);
> -	v4l2_dbg(3, debug, &hdmirx_dev->v4l2_dev, "%s: 5v:%d\n", __func__, val);
>  
>  	queue_delayed_work(system_unbound_wq,
>  			   &hdmirx_dev->delayed_work_hotplug,
> 
> ---
> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> change-id: 20260108-media-synopsys-hdmirx-fix-gpio-cansleep-d9c8b526cabe
> 
> Best regards,
> --  
> Mark Brown <broonie@...nel.org>
> 
>