From nobody Thu Sep 24 16:07:15 2026 Received: from pdx-out-015.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-015.esa.us-west-2.outbound.mail-perimeter.amazon.com [50.112.246.219]) (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 784044F30C1; Tue, 22 Sep 2026 10:31:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=50.112.246.219 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073075; cv=none; b=X+eayQHC6zHaM7QlObu4CvF2ZriISDsYRej+UdLIREgeBO1UQ5DPxMph1/tCUfF0wW7iSrNbq1CgKyZiwPCkzzVobmcfXHEMQerzI5KXGf6PIg7wNd+kElvyAN0kUQYVViSPU9bQyUhpYHvhO82l0H5MAUjmiN//T1F1vpP0BbE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073075; c=relaxed/simple; bh=c4d1nOjeNhT9jLZ3ARh7PAPB0tnZeYKkRoijwwRAcLs=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oWTXqlFBq+HRgiO6xRbiPvvdwKUVhrOpPoLU3rwNYrh1hNNrCQjPVe3GZbNKJeVum8fLujmNs6g5+lblrw6y4LDnRCMaMqspc2PAcz9nmrUt0z+o85XWKt+//snaqxsUa3pnGvchRo0kJi11kfrqthMUAgISDdsyR3ax2P4Kx4k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; spf=pass smtp.mailfrom=amazon.com; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b=pB0IRPSx; arc=none smtp.client-ip=50.112.246.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b="pB0IRPSx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1790073071; x=1821609071; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FONXOdAXNzNqni0VAdej7KuuNZs3Z6zTLAiVVikiw4g=; b=pB0IRPSxUF4fcdQ+cBhCzS/jpFXum0gvOHZwtX2i8C+xcZj2wCaWSYQw GJh1+L9S1vnH6N8IOj1agqOUzvgn4TWSLDz1UtGo1GVGnygsKLCBiPt0D Gx6MlYRi2q/GmWseHbayjZxQxpX598D2h2eIEUzEB/ndtnzfKixkBeXwO msZ//DAayhtto4izQoYzAckYZIvARBTIJ6jpNoW71i+/shC4fX8qHICRy StQum3f+LW4BC1Oq0l69nvF5HtScbCEX9o6Kn62bLLeFOoAqubIvJL7+m BtP/r1f1JHvhPA9Ctx2Mvxef0Gk3rH/iN9huLn5yEbc2SWSHWvdtvatmM Q==; X-CSE-ConnectionGUID: NxTJnMLJTK2c8xqeaZsx3Q== X-CSE-MsgGUID: 2vI3SvBZTHudFbD7H3hicw== X-IronPort-AV: E=Sophos;i="6.27,116,1787011200"; d="scan'208";a="29109114" Received: from ip-10-5-6-203.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.6.203]) by internal-pdx-out-015.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2026 10:31:02 +0000 Received: from EX19MTAUWB001.ant.amazon.com [205.251.233.51:30287] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.60.208:2525] with esmtp (Farcaster) id df508233-3de7-495e-a6f4-504f7b83d2e2; Tue, 22 Sep 2026 10:31:02 +0000 (UTC) X-Farcaster-Flow-ID: df508233-3de7-495e-a6f4-504f7b83d2e2 Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWB001.ant.amazon.com (10.250.64.248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:01 +0000 Received: from dev-dsk-farbere-1a-46ecabed.eu-west-1.amazon.com (172.19.116.181) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:30:59 +0000 From: Eliav Farber To: Rodolfo Giometti , Rob Herring , Krzysztof Kozlowski , Conor Dooley CC: Linus Walleij , Bartosz Golaszewski , Fabio Estevam , Andrew Morton , Takashi Sakamoto , Eliav Farber , , , Subject: [PATCH v5 1/4] pps: clients: gpio: propagate probe error codes Date: Tue, 22 Sep 2026 10:30:48 +0000 Message-ID: <20260922103051.5257-2-farbere@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922103051.5257-1-farbere@amazon.com> References: <20260919171157.5502-1-farbere@amazon.com> <20260922103051.5257-1-farbere@amazon.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: EX19D036UWB002.ant.amazon.com (10.13.139.139) To EX19D001UWA001.ant.amazon.com (10.13.138.214) Content-Type: text/plain; charset="utf-8" On the two probe error paths that map and request the interrupt, probe overwrote the error from gpiod_to_irq() and request_threaded_irq() with a hardcoded -EINVAL, hiding meaningful codes such as -EBUSY, -ENOMEM or -EPROBE_DEFER from the caller. The request_threaded_irq() failure message also logged the IRQ number but not the errno. Switch both paths to dev_err_probe() so the actual error code is returned and logged symbolically, and so a repeated -EPROBE_DEFER during boot is logged at debug level rather than spamming the console. This also matches pps_gpio_setup() in the same file, which already uses dev_err_probe(). Fixes: 161520451dfa ("pps: new client driver using GPIO") Signed-off-by: Eliav Farber --- Changes in v5: - Use dev_err_probe() on both error paths instead of dev_err() + return, so a propagated -EPROBE_DEFER is logged at debug level (no console spam on repeated deferral) and the code is emitted symbolically. This also matches pps_gpio_setup() in the same file. Drop Bartosz Golaszewski's Reviewed-by as the patch changed materially Changes in v4: - Add Fixes: 161520451dfa ("pps: new client driver using GPIO") and Bartosz Golaszewski's Reviewed-by. The hardcoded -EINVAL on both error paths predates 4461d65176b4 (which only switched gpio_to_irq() to gpiod_to_irq() and left those returns as context), so the tag points at the original driver rather than the descriptor conversion Changes in v3: - New patch, split out of the pinctrl change: while converting the probe error paths to a goto, Takashi Sakamoto noted that the hardcoded -EINVAL discards the real gpiod_to_irq()/request_threaded_irq() error, so fix that separately first drivers/pps/clients/pps-gpio.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c index 73ec2c7335e5..ccc2fb470b7e 100644 --- a/drivers/pps/clients/pps-gpio.c +++ b/drivers/pps/clients/pps-gpio.c @@ -163,10 +163,8 @@ static int pps_gpio_probe(struct platform_device *pdev) =20 /* IRQ setup */ ret =3D gpiod_to_irq(data->gpio_pin); - if (ret < 0) { - dev_err(dev, "failed to map GPIO to IRQ: %d\n", ret); - return -EINVAL; - } + if (ret < 0) + return dev_err_probe(dev, ret, "failed to map GPIO to IRQ\n"); data->irq =3D ret; =20 /* initialize PPS specific parts of the bookkeeping data structure. */ @@ -197,8 +195,8 @@ static int pps_gpio_probe(struct platform_device *pdev) data->info.name, data); if (ret) { pps_unregister_source(data->pps); - dev_err(dev, "failed to acquire IRQ %d\n", data->irq); - return -EINVAL; + return dev_err_probe(dev, ret, "failed to acquire IRQ %d\n", + data->irq); } =20 dev_dbg(&data->pps->dev, "Registered IRQ %d as PPS source\n", --=20 2.47.3 From nobody Thu Sep 24 16:07:15 2026 Received: from pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com [35.162.73.231]) (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 864CF4DDB32; Tue, 22 Sep 2026 10:31:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=35.162.73.231 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073075; cv=none; b=qfiED9aQm3FmOL3t7NEG68WPV9F1+y4yqP4phkyggXcEHH5iDipe3sn/8k/u7An1qR5/j8R3O5iFYeMtQKXVhqbJxOesTolOZNKGI2A1QWSYKSP8EB9Y0HtMaOzOd3lrwVPsJTiaf6bFMkV41COA00OHphDoJ4jakL40WZ2e/ts= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073075; c=relaxed/simple; bh=rABX0WanbeFHc+GJ7Lvu3lndigrD+X4eaT7URR7WlHU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hJW3hYjHThEEPh+Pck7KCv7a4sYMe4Bmc7fATQdKfPvbWTAVYIgVOLDr/J/0IQBRzEa2X6ntgQTQn6MaLLwaMJD/v5dKX6/wDPihXaEBfIbN9wUpSPe2DWhkIjRoZO1/ih5+HFWDp1fjhlFg1HmJrZYUf55nbqwtlmNi3adV0EQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; spf=pass smtp.mailfrom=amazon.com; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b=Eb1wXVn8; arc=none smtp.client-ip=35.162.73.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b="Eb1wXVn8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1790073071; x=1821609071; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nyFsqbiJe894vApQkWC51dQ7yzSu7fFDyoRKdXI6MtQ=; b=Eb1wXVn8nPtPjNsmhA03ao7pOp9mPTOGsSBtRxApIHXvtAP0tZVkvBIS YPT35Ix43kgrVjma9jObKYb0yr6tgPULPmpe3x0ZAMMviVJXbMSy10jrs lyTKhrSbtVgsWX/8ok2ncKXpy79mu2HqIQ8wLL1Oyra9MdQ/fKjD6o0yR IvOZrpS8QyqzDYlp0/TfZW1XPtxZC5rfVl08tv0jUUaeT1FKvA0AAwdOC 86ndzx7NIQX4SdRmnx1n3Cklypf5HvEcWAN2DgbNWMqb6ZQFuQb82FzFZ RXRPzcRJJ+WzVR9Xpsrjj7p2HGt9FW++jPr62YsS3AL5VxPJo8FNi1cRG Q==; X-CSE-ConnectionGUID: CCvTHDrBQC+/wjcoKiV9Cw== X-CSE-MsgGUID: jiQZ0B9GTF2YShaW4tPzHg== X-IronPort-AV: E=Sophos;i="6.27,116,1787011200"; d="scan'208";a="29130432" Received: from ip-10-5-12-219.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.12.219]) by internal-pdx-out-012.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2026 10:31:04 +0000 Received: from EX19MTAUWC002.ant.amazon.com [205.251.233.111:11204] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.46.137:2525] with esmtp (Farcaster) id 5f7692ac-4d1a-408f-95ca-967d748d0ba9; Tue, 22 Sep 2026 10:31:04 +0000 (UTC) X-Farcaster-Flow-ID: 5f7692ac-4d1a-408f-95ca-967d748d0ba9 Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWC002.ant.amazon.com (10.250.64.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:03 +0000 Received: from dev-dsk-farbere-1a-46ecabed.eu-west-1.amazon.com (172.19.116.181) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:01 +0000 From: Eliav Farber To: Rodolfo Giometti , Rob Herring , Krzysztof Kozlowski , Conor Dooley CC: Linus Walleij , Bartosz Golaszewski , Fabio Estevam , Andrew Morton , Takashi Sakamoto , Eliav Farber , , , Subject: [PATCH v5 2/4] pps: clients: gpio: only tear down the echo timer when it exists Date: Tue, 22 Sep 2026 10:30:49 +0000 Message-ID: <20260922103051.5257-3-farbere@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922103051.5257-1-farbere@amazon.com> References: <20260919171157.5502-1-farbere@amazon.com> <20260922103051.5257-1-farbere@amazon.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: EX19D036UWB002.ant.amazon.com (10.13.139.139) To EX19D001UWA001.ant.amazon.com (10.13.138.214) Content-Type: text/plain; charset="utf-8" remove() calls timer_delete_sync() on data->echo_timer unconditionally, but the timer is only initialised by timer_setup() in probe() when the board describes an "echo" GPIO. On a board without echo-gpios the timer is never set up, so remove() operates on a timer_list that was never initialised. The guard used to be there: it was dropped by commit fde046a8c490 ("pps: clients: gpio: Remove redundant condition in ->remove()") on the grounds that "the timer along with GPIO API are NULL-aware". That is true for the GPIO API - gpiod_set_value() is a no-op for a NULL descriptor - but not for the timer: timer_delete_sync() on a timer that was never timer_setup() initialised trips the debug_assert_init() check and emits a debugobjects "not initialized" warning under CONFIG_DEBUG_OBJECTS_TIMERS. Restore the data->echo_pin guard around the echo teardown, mirroring the condition under which the timer is set up in probe(). gpiod_set_value() is kept under the same guard as it only makes sense together with the echo timer. Fixes: fde046a8c490 ("pps: clients: gpio: Remove redundant condition in ->r= emove()") Signed-off-by: Eliav Farber --- Changes in v5: - New patch. Split out because patch 4 mirrors remove()'s teardown in the new shutdown(); guarding the echo teardown here first keeps that latent issue out of both paths (Rodolfo Giometti) drivers/pps/clients/pps-gpio.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c index ccc2fb470b7e..aec534c246af 100644 --- a/drivers/pps/clients/pps-gpio.c +++ b/drivers/pps/clients/pps-gpio.c @@ -211,9 +211,11 @@ static void pps_gpio_remove(struct platform_device *pd= ev) =20 free_irq(data->irq, data); pps_unregister_source(data->pps); - timer_delete_sync(&data->echo_timer); - /* reset echo pin in any case */ - gpiod_set_value(data->echo_pin, 0); + /* reset the echo state, if the board has an echo GPIO */ + if (data->echo_pin) { + timer_delete_sync(&data->echo_timer); + gpiod_set_value(data->echo_pin, 0); + } dev_info(&pdev->dev, "removed IRQ %d as PPS source\n", data->irq); } =20 --=20 2.47.3 From nobody Thu Sep 24 16:07:15 2026 Received: from pdx-out-011.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-011.esa.us-west-2.outbound.mail-perimeter.amazon.com [52.35.192.45]) (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 360D7477991; Tue, 22 Sep 2026 10:31:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=52.35.192.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073076; cv=none; b=C5lOZLRHKAKnwyS1IjaB7Dv9QuVuLTbxsJJNywr2cKNVtGMeRXh/TRJ/d4uYCZCc7Z4YCb48J0yYs35Pf7vvjPtDZa5eJmDcStHiooNSMk72usX0RbygjvhraW1JI3bTMRGMbO6CjMN8YuQlDjPTz7dQgRsR2RExbyLOIZt3ZqQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073076; c=relaxed/simple; bh=pmcieg6oScmEYU6/MyQ9Mj7cF07ICbZ9Av6qPsPrE1E=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hNjk0Y2fTWPPAJDj3kNbMB1uT8Nzf0JKHSITAq/AD+l7R4J/jzvCyvminRoovwzFp+BK8DCjq2PpsSideLbqOutHEMnOQtSkNd/OK1fjuaLpn2aGC63kqJLlaxT7Ia/ArIZvgeoDpYicPQA+GJjsxp/ykkP92LaQL+bDE3+rE10= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; spf=pass smtp.mailfrom=amazon.com; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b=aW+tLNhB; arc=none smtp.client-ip=52.35.192.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b="aW+tLNhB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1790073073; x=1821609073; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=eohaOZGCuEICBV1DzPfZR6vfi8a+kP71azJvuPSBEO0=; b=aW+tLNhByMOxqn+O0PbIvwnyPRxBybnq1hzopvIcZ2+1Vm/XbSGC32GV OzbH6ftTdEYxyEfK3xowCvWwPIDLd8P2g0S3SqQqU4JGOwUyHV2ES4wOs uZ+YvXbo0Qi1WTyLdE5MG4002cZWOVwxoTxMbb3or97t2kZNw7hj/r9WC PxLw1h6Ix8baemvWhi04ZGWlcuMxcsjSVGXg1H5UYBFVSMCreg+NIB9Ty qYxf9Ox07uLC8RIDXh+rUqdLFJQY4G0zQoD0eflWExXL/AtsCBc5yo8UX TPLEVgXl2BJgVDj4shlz0+LhzwHP3rSKl/fSvAXwaemM9I8U7fSDUi8kE g==; X-CSE-ConnectionGUID: AZ02Gq1eRl2DDWsBmn8P9g== X-CSE-MsgGUID: c8U2zRlVQX6jjHEQSagDyg== X-IronPort-AV: E=Sophos;i="6.27,116,1787011200"; d="scan'208";a="29095334" Received: from ip-10-5-9-48.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.9.48]) by internal-pdx-out-011.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2026 10:31:06 +0000 Received: from EX19MTAUWA001.ant.amazon.com [205.251.233.182:25616] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.35.200:2525] with esmtp (Farcaster) id 0939f03d-e97f-4e42-9b76-a3b2cc99918c; Tue, 22 Sep 2026 10:31:06 +0000 (UTC) X-Farcaster-Flow-ID: 0939f03d-e97f-4e42-9b76-a3b2cc99918c Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWA001.ant.amazon.com (10.250.64.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:06 +0000 Received: from dev-dsk-farbere-1a-46ecabed.eu-west-1.amazon.com (172.19.116.181) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:03 +0000 From: Eliav Farber To: Rodolfo Giometti , Rob Herring , Krzysztof Kozlowski , Conor Dooley CC: Linus Walleij , Bartosz Golaszewski , Fabio Estevam , Andrew Morton , Takashi Sakamoto , Eliav Farber , , , Subject: [PATCH v5 3/4] dt-bindings: pps: pps-gpio: document optional pinctrl states Date: Tue, 22 Sep 2026 10:30:50 +0000 Message-ID: <20260922103051.5257-4-farbere@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922103051.5257-1-farbere@amazon.com> References: <20260919171157.5502-1-farbere@amazon.com> <20260922103051.5257-1-farbere@amazon.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: EX19D036UWB002.ant.amazon.com (10.13.139.139) To EX19D001UWA001.ant.amazon.com (10.13.138.214) Content-Type: text/plain; charset="utf-8" When the PPS input GPIO is routed through a pin controller, a board may need to mux those pins to a different function while pps-gpio is not driving PPS (for example after the driver is unbound or across a kexec). Document the optional "default" and "inactive" pinctrl-names and show both in the example. The "default" state selects the PPS/GPIO function and is applied by the driver core before probe; the optional "inactive" state, when present, describes the mux to restore when the driver is unbound or the system is shut down. "default" is pinctrl-0, matching the implicit ordering the pinctrl core already assigns it, and "inactive" is pinctrl-1; the driver looks each state up by name. Signed-off-by: Eliav Farber --- Changes in v4: - Rework per Rob Herring: do not express the ordering in prose; use an ordered "items" list ("default" then "inactive") with minItems: 1, since pinctrl-0 is already implicitly "default" and its position is fixed. This also fixes the "['default', 'inactive'] is too long" dt_binding_check error seen on v3. Reword the commit message accordingly Changes in v3: - Do not constrain pinctrl-names to a fixed ["default", "inactive"] tuple. The driver looks the states up by name, so "inactive" may appear in any position and other states may coexist; only require (via "contains") that a "default" state exists, and reword the description accordingly Changes in v2: - Rename the released state from "idle" to "inactive" .../devicetree/bindings/pps/pps-gpio.yaml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.yaml b/Document= ation/devicetree/bindings/pps/pps-gpio.yaml index 383a838744eb..61b5de6724ea 100644 --- a/Documentation/devicetree/bindings/pps/pps-gpio.yaml +++ b/Documentation/devicetree/bindings/pps/pps-gpio.yaml @@ -28,6 +28,17 @@ properties: description: Indicates a falling edge assert, when present. Rising edg= e if absent. type: boolean =20 + pinctrl-names: + description: + The "default" state selects the PPS/GPIO function and is applied by = the + driver core before probe. The optional "inactive" state, when presen= t, + is selected when the driver is unbound or the system is shut down, + handing the pins back to their alternate function. + minItems: 1 + items: + - const: default + - const: inactive + required: - compatible - gpios @@ -40,8 +51,9 @@ examples: =20 pps { compatible =3D "pps-gpio"; - pinctrl-names =3D "default"; + pinctrl-names =3D "default", "inactive"; pinctrl-0 =3D <&pinctrl_pps>; + pinctrl-1 =3D <&pinctrl_pps_inactive>; gpios =3D <&gpio1 26 GPIO_ACTIVE_HIGH>; assert-falling-edge; echo-gpios =3D <&gpio1 27 GPIO_ACTIVE_HIGH>; --=20 2.47.3 From nobody Thu Sep 24 16:07:15 2026 Received: from pdx-out-008.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-008.esa.us-west-2.outbound.mail-perimeter.amazon.com [52.42.203.116]) (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 27FF74F7970; Tue, 22 Sep 2026 10:31:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=52.42.203.116 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073080; cv=none; b=Iu3zPyjj33zaQ37jmING25PDHU2cU4Azd+j/v6u1g787tZxzGSD7Pe76sJsDl0P2wsX+3lHgO2Y4l2ZmKONROts7eQVzD2Ra4ICreCTC2wS2hA24UwztTOHNvSZBJpC7OVREOSIzYsToaMPQoa8DY/fVxlITRzvBEVrvYEsfz4I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790073080; c=relaxed/simple; bh=fzZrqq/3EIZzhNmmYznawxf13JvsJDAwsHKRhcXlRLM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WPalNVOGPWWto2RdQjfu7F2zZ4swTqlBdrmcYoz5Rvy+MNZkBQ3Tc/EPz4xjM1QIEE9yLLZV/lUMa2E67V6PAQnBS1MTm4C45CN+/iaJuZn6hmO3UyjvHVnMmBOpnuGxOAW0D+iGTeBYcLHpGKiPETNLYEJZibo4my2XdV6zKp4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com; spf=pass smtp.mailfrom=amazon.com; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b=DLhV+wvx; arc=none smtp.client-ip=52.42.203.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.com header.i=@amazon.com header.b="DLhV+wvx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1790073075; x=1821609075; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cIK6DEOkfPf2hQxSaOZnF2IvrXaG24SQpmzVgtKhpNM=; b=DLhV+wvxPSeJpa1ee8J5yRfRg5Ejn/Phz5EVqlyGvithF2W/KCNd2Tg4 jFMx8q5Mthdi9efLx1hGo6xMTiAtt0fEG/5VJXrEvLbp90q/KmTQRysng 5jF9NBRXkiFYvqa3a0BCY68A/uLNpqYWUyTChYRxyLHnNLLa626LX+yj6 C8kpbCSbCpTN62WBWsh3T2IVmOzqdbkmTg8aJyDRakwDtsyuEv0CXCBca kpWwug3XkIi/UQCQaUITdDWRZrBlXAuUTBG67LdKnDk/Oo2Q4jsDvYJXE HVAUwgPPOj+s6gJoU+2vqbLAFYJWVXVXcuN4IDRLDs73s3pdoO/Cd39eK g==; X-CSE-ConnectionGUID: 3NcB0qSiSrqJMjp4odgTRg== X-CSE-MsgGUID: CnKAZHUFQDqm1/CrpJhEzA== X-IronPort-AV: E=Sophos;i="6.27,116,1787011200"; d="scan'208";a="29360550" Received: from ip-10-5-12-219.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.12.219]) by internal-pdx-out-008.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2026 10:31:08 +0000 Received: from EX19MTAUWC001.ant.amazon.com [205.251.233.53:10527] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.5.10:2525] with esmtp (Farcaster) id 3086d706-52b0-438c-8a6d-69fb231f5751; Tue, 22 Sep 2026 10:31:08 +0000 (UTC) X-Farcaster-Flow-ID: 3086d706-52b0-438c-8a6d-69fb231f5751 Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWC001.ant.amazon.com (10.250.64.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:08 +0000 Received: from dev-dsk-farbere-1a-46ecabed.eu-west-1.amazon.com (172.19.116.181) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.49; Tue, 22 Sep 2026 10:31:06 +0000 From: Eliav Farber To: Rodolfo Giometti , Rob Herring , Krzysztof Kozlowski , Conor Dooley CC: Linus Walleij , Bartosz Golaszewski , Fabio Estevam , Andrew Morton , Takashi Sakamoto , Eliav Farber , , , Subject: [PATCH v5 4/4] pps: clients: gpio: release pins to an inactive state on remove and shutdown Date: Tue, 22 Sep 2026 10:30:51 +0000 Message-ID: <20260922103051.5257-5-farbere@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922103051.5257-1-farbere@amazon.com> References: <20260919171157.5502-1-farbere@amazon.com> <20260922103051.5257-1-farbere@amazon.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: EX19D036UWB002.ant.amazon.com (10.13.139.139) To EX19D001UWA001.ant.amazon.com (10.13.138.214) Content-Type: text/plain; charset="utf-8" Some boards route the PPS input GPIO through a pin controller and need to mux it to another function when pps-gpio is not driving PPS. The driver core applies the "default" pinctrl state before probe, so the pins are muxed for GPIO/PPS use while the driver is bound. Nothing, however, hands the pins back when the driver is unbound or the system is shut down, so they stay stuck in the GPIO function for whatever runs next, kexec included. Look up an optional "inactive" pinctrl state in probe via devm_pinctrl_get() and pinctrl_lookup_state(), and select it with pinctrl_select_state() in remove() and shutdown(). The state is looked up and selected by the driver itself rather than reusing the runtime-PM "idle"/"sleep" states, so its meaning is unambiguous and it does not depend on CONFIG_PM. Boards that do not describe an "inactive" state are unaffected. Since "inactive" is only meaningful as the mux to restore after the core-applied "default" state, reject an "inactive" state that is not paired with a "default" one rather than releasing pins that were never put into a defined PPS state. Look up the pinctrl states first in probe(), before pps_gpio_setup(), and route every subsequent failure through a common err_release_pins label. The driver core applies the "default" mux before probe(), so a probe that fails after this point would otherwise leave the pins stuck in "default"; releasing them to "inactive" on the error path is the symmetrical counterpart to what the core did on the driver's behalf. A failure in pps_gpio_get_pins() itself returns directly, as no state was taken yet; pps_gpio_release_pins() is a no-op when no "inactive" state was found. The mux must not change while something can still drive the pins. On shutdown() the requested IRQ and the echo timer would otherwise outlive the mux change -- device_shutdown() is not the end of the road, the kernel keeps running to load and start the kexec image -- so a timer callback or the PPS handler could poke a line that by then belongs to another function. Tear down in the same order as remove(): free_irq() first, then the echo timer (only when the board has an echo GPIO, as in remove()), and the mux change last. shutdown() does not unregister the PPS source, which is a remove-time concern. Signed-off-by: Eliav Farber --- Changes in v5: - Resolve the v4 probe-failure open question by taking option "A + keep the NULL guard": look the pinctrl states up first in probe(), before pps_gpio_setup(), and route the pps_gpio_setup() failure through err_release_pins too, so every path the driver can act on restores "inactive". pps_gpio_release_pins() keeps its NULL guard, so it is a no-op when no "inactive" state was found. Verified on the AL11 K2V6 JRD10 with a forced-defer test: the pins are released to "inactive" on each failed attempt, the core re-applies "default" before the next, and the mux settles at "default" on the eventual success, with no spurious PPS event (Rodolfo Giometti) - Clear data->pins_inactive when rejecting an "inactive" state that has no "default", so a board deliberately rejected here can never have its pins released to "inactive" - Guard the echo-timer teardown in the new shutdown() with data->echo_pin, matching remove() after the preceding patch (Rodolfo Giometti) - Convert the gpiod_to_irq()/request_threaded_irq() error paths to the log-only dev_err_probe() + goto err_release_pins form, following patch 1 Changes in v4: - No functional change (probe-failure raised as an open question, now resolved in v5 above) Changes in v3: - Treat -ENODEV from devm_pinctrl_get() as "no pinctrl", not a probe failure; keep propagating everything else, e.g. -EPROBE_DEFER - Restore the "inactive" mux on probe failure via a new err_release_pins label - Warn if pinctrl_select_state() fails to apply the "inactive" state rather than silently ignoring the error - Trim and de-duplicate the added comments Changes in v2: - Rename the released state from "idle" to "inactive" - Look the state up in the driver with devm_pinctrl_get() + pinctrl_lookup_state() + pinctrl_select_state() instead of pinctrl_pm_select_idle_state(), removing the CONFIG_PM dependency - Fix shutdown() to free_irq() and the echo teardown before the mux change, matching remove() - Require a "default" state whenever "inactive" is present and reject the mismatch drivers/pps/clients/pps-gpio.c | 117 +++++++++++++++++++++++++++++++-- 1 file changed, 111 insertions(+), 6 deletions(-) diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c index aec534c246af..203bf465ed8b 100644 --- a/drivers/pps/clients/pps-gpio.c +++ b/drivers/pps/clients/pps-gpio.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include @@ -30,6 +31,8 @@ struct pps_gpio_device_data { struct gpio_desc *gpio_pin; /* GPIO port descriptors */ struct gpio_desc *echo_pin; struct timer_list echo_timer; /* timer to reset echo active state */ + struct pinctrl *pinctrl; /* pin control handle */ + struct pinctrl_state *pins_inactive; /* pins released when unbound */ bool assert_falling_edge; unsigned int echo_active_ms; /* PPS echo active duration */ unsigned long echo_timeout; /* timer timeout value in jiffies */ @@ -96,6 +99,68 @@ static void pps_gpio_echo_timer_callback(struct timer_li= st *t) gpiod_set_value(info->echo_pin, 0); } =20 +/* + * Look up the optional "inactive" pinctrl state. It requires a "default" + * state (applied by the driver core before probe) and is rejected without + * one. Absent pinctrl, or an absent "inactive" state, is not an error. + */ +static int pps_gpio_get_pins(struct device *dev) +{ + struct pps_gpio_device_data *data =3D dev_get_drvdata(dev); + struct pinctrl_state *pins_default; + + data->pinctrl =3D devm_pinctrl_get(dev); + if (IS_ERR(data->pinctrl)) { + /* + * A DT device without "pinctrl-0" yields -ENODEV, which + * is not an error here; propagate anything else. + */ + if (PTR_ERR(data->pinctrl) =3D=3D -ENODEV) { + data->pinctrl =3D NULL; + return 0; + } + return dev_err_probe(dev, PTR_ERR(data->pinctrl), + "failed to get pinctrl\n"); + } + + /* The "inactive" state is optional. */ + data->pins_inactive =3D pinctrl_lookup_state(data->pinctrl, "inactive"); + if (IS_ERR(data->pins_inactive)) { + data->pins_inactive =3D NULL; + return 0; + } + + /* "inactive" requires a "default" state to return from. */ + pins_default =3D pinctrl_lookup_state(data->pinctrl, "default"); + if (IS_ERR(pins_default)) { + data->pins_inactive =3D NULL; + return dev_err_probe(dev, PTR_ERR(pins_default), + "\"inactive\" pinctrl state requires a \"default\" state\n"); + } + + return 0; +} + +/* + * Restore the "inactive" pinctrl state, handing the pins back to whatever + * function uses them while pps-gpio is not driving PPS. This undoes the + * "default" state the driver core applied before probe. A no-op for boards + * that describe no "inactive" state. + */ +static void pps_gpio_release_pins(struct device *dev) +{ + struct pps_gpio_device_data *data =3D dev_get_drvdata(dev); + int ret; + + if (!data->pins_inactive) + return; + + ret =3D pinctrl_select_state(data->pinctrl, data->pins_inactive); + if (ret) + dev_warn(dev, "failed to select inactive pinctrl state: %d\n", + ret); +} + static int pps_gpio_setup(struct device *dev) { struct pps_gpio_device_data *data =3D dev_get_drvdata(dev); @@ -156,15 +221,25 @@ static int pps_gpio_probe(struct platform_device *pde= v) =20 dev_set_drvdata(dev, data); =20 + /* + * pinctrl setup (optional states) first, so the "inactive" mux can be + * restored on any later probe-failure path via err_release_pins. + */ + ret =3D pps_gpio_get_pins(dev); + if (ret) + return ret; + /* GPIO setup */ ret =3D pps_gpio_setup(dev); if (ret) - return ret; + goto err_release_pins; =20 /* IRQ setup */ ret =3D gpiod_to_irq(data->gpio_pin); - if (ret < 0) - return dev_err_probe(dev, ret, "failed to map GPIO to IRQ\n"); + if (ret < 0) { + dev_err_probe(dev, ret, "failed to map GPIO to IRQ\n"); + goto err_release_pins; + } data->irq =3D ret; =20 /* initialize PPS specific parts of the bookkeeping data structure. */ @@ -185,7 +260,8 @@ static int pps_gpio_probe(struct platform_device *pdev) if (IS_ERR(data->pps)) { dev_err(dev, "failed to register IRQ %d as PPS source\n", data->irq); - return PTR_ERR(data->pps); + ret =3D PTR_ERR(data->pps); + goto err_release_pins; } =20 /* register IRQ interrupt handler */ @@ -195,14 +271,20 @@ static int pps_gpio_probe(struct platform_device *pde= v) data->info.name, data); if (ret) { pps_unregister_source(data->pps); - return dev_err_probe(dev, ret, "failed to acquire IRQ %d\n", - data->irq); + dev_err_probe(dev, ret, "failed to acquire IRQ %d\n", + data->irq); + goto err_release_pins; } =20 dev_dbg(&data->pps->dev, "Registered IRQ %d as PPS source\n", data->irq); =20 return 0; + +err_release_pins: + /* Restore the inactive mux on probe failure; safe to do last here. */ + pps_gpio_release_pins(dev); + return ret; } =20 static void pps_gpio_remove(struct platform_device *pdev) @@ -216,9 +298,31 @@ static void pps_gpio_remove(struct platform_device *pd= ev) timer_delete_sync(&data->echo_timer); gpiod_set_value(data->echo_pin, 0); } + /* release the pins last, once nothing can drive them */ + pps_gpio_release_pins(&pdev->dev); dev_info(&pdev->dev, "removed IRQ %d as PPS source\n", data->irq); } =20 +static void pps_gpio_shutdown(struct platform_device *pdev) +{ + struct pps_gpio_device_data *data =3D platform_get_drvdata(pdev); + + /* + * The kernel keeps running after device_shutdown() (e.g. to load and + * start a kexec image), so quiesce the hardware before touching the + * mux: free the IRQ and stop the echo timer first, then release the + * pins last, so no callback can drive a pin after it is handed back. + * The PPS source is left registered; that is a remove-time concern. + */ + free_irq(data->irq, data); + /* reset the echo state, if the board has an echo GPIO */ + if (data->echo_pin) { + timer_delete_sync(&data->echo_timer); + gpiod_set_value(data->echo_pin, 0); + } + pps_gpio_release_pins(&pdev->dev); +} + static const struct of_device_id pps_gpio_dt_ids[] =3D { { .compatible =3D "pps-gpio", }, { /* sentinel */ } @@ -228,6 +332,7 @@ MODULE_DEVICE_TABLE(of, pps_gpio_dt_ids); static struct platform_driver pps_gpio_driver =3D { .probe =3D pps_gpio_probe, .remove =3D pps_gpio_remove, + .shutdown =3D pps_gpio_shutdown, .driver =3D { .name =3D PPS_GPIO_NAME, .of_match_table =3D pps_gpio_dt_ids, --=20 2.47.3