From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpcmd13147.aruba.it (smtpcmd13147.aruba.it [62.149.156.147]) (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 98C403A1A22 for ; Tue, 22 Sep 2026 07:45:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.149.156.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790063127; cv=none; b=tYEanb/ahw7aNVXHrFHavCXhWHIHNpFZHCy1VUoueJXXsFzrjxm9UYuBaDqlUIJLGqpRkaXAHkveZJdTZopLIwcNvf5/QonJaGAls3lx3zQTpMXVcRBpotK83nVEUwYMGQpCKw8tvxgqaQ+iA753UTygq73o2biAely2DqUOguo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790063127; c=relaxed/simple; bh=rAwrZSEnbhAjepFBanz1IEDBQr5LomBIXFm+PqctUXc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pzDGpGZghkAcUwAiJQy5DPBw1eoMi0V5aLW3AYuJI8LQsDJ8PlojC799bvhXDmAE+aG2rD9MnVA9audOPpnPzgFqqHNmL9FekDVECECJBaWvKXMUarW1gQe3NHAhWw/5j5Jx6Tsg3xz7QkZWyS5W7SmzOJBv44u/3yulrDCAZqU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com; spf=pass smtp.mailfrom=enneenne.com; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b=IEVYcNoj; arc=none smtp.client-ip=62.149.156.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enneenne.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=enneenne.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b="IEVYcNoj" Received: from [172.18.100.99] ([109.238.20.116]) by Aruba SMTP with ESMTPSA id 8v7IxQF8Nbk7m8v7IxukAS; Tue, 22 Sep 2026 09:40:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1790062841; bh=rAwrZSEnbhAjepFBanz1IEDBQr5LomBIXFm+PqctUXc=; h=Date:MIME-Version:Subject:To:From:Content-Type; b=IEVYcNoj2wde8M6H80ef9P6bxjE4j+VEFCmwWpOnYYJWbhjSzPNhKWK8KoVIfmvD2 o6gR1D9tgsaHYne+mS11HDnt6Ptmi4vXk4pweIIuPfZBT4OfFEd3VqeEzMznUgaohj Q1EimCXEUCi/ssPEBIrxuk0y+CRJF9XI1v4hBDGiHqRCvQTlzq5vPDYGl1ssWgTuE0 qORGbOl2qZ13W6auCGDaCmjfuG7efw6REbEWbmH0QO6wMjYoWdto6VUyAHmaJtDnAm wqNTEGSl1HMqnaJQJelCOV3vZVJEcCFH+LisezXwN7DbFeSePEr0w3XeoUHQ5yM3pw HddXKphG2/HYw== Message-ID: <495ec89c-b035-4bc5-9c15-3ddbb108d312@enneenne.com> Date: Tue, 22 Sep 2026 09:40:40 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/3] pps: clients: gpio: release pins to an inactive state on remove and shutdown Content-Language: en-US To: Eliav Farber , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: Linus Walleij , Bartosz Golaszewski , Fabio Estevam , Andrew Morton , Takashi Sakamoto , devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260917075611.47881-1-farbere@amazon.com> <20260919171157.5502-4-farbere@amazon.com> From: Rodolfo Giometti In-Reply-To: <20260919171157.5502-4-farbere@amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfEX+JZyOpmHRZkZKWpq5GHpt+/+Wou9W4ZmO6rpg+1ED4ppI72vV3Co0jMia9LFjD9LfvprRN7xA/bJervz3uRgOxxxPpbAtousLhawyffm02JeSX7cr 0+jYsJfb3D6enp7usAcO3caOfZG2xuOaui7MT/gkA84J6Sy6jx9j9lmQ1ubRq63tP7FClDujwn+GtTzfE+QzWOmDNUq4gCGkEYX0Ny5yZOZVMMAzbeV7FsI9 FN1PZtO1Tf16zH1WkUSdiyPKdZA7wU0yf0z/nbrWbyznO3iuaR6+LgYg62TpaXAuSi73cGL4Hp6STH2G8k9hUBMnAWbSPaS3hbQlU2uM5Xfm61os+xiHXZ2X QDthuiWqxa/C1tsi5aRWg8zGKBz6fcXwBBjgTkp9gTmCh1S6sH7HhXzu+AqwzlApMcG9vCdnIhttwljJFM5bFKjvELRdTxoeNFoqGvJ/1W2+5sfD7z05doD7 c+N81iHbdIbECQYnLZBZKVaWHOy/5r4ESmzSTS3ZF9FoafrWqaUO0n6pErjlzseLF9jlKs5wHZ2qH4+EXjcKihLWl9ehoiDfGwr8uQ== On Sat, Sep 19, 2026 at 05:11:57PM +0000, Eliav Farber wrote: > +static void pps_gpio_shutdown(struct platform_device *pdev) > +{ > + struct pps_gpio_device_data *data = 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); > + timer_delete_sync(&data->echo_timer); > + gpiod_set_value(data->echo_pin, 0); > + pps_gpio_release_pins(&pdev->dev); > +} The ordering argument convinced me, and I checked it against remove(): free_irq() really is the first thing remove() does, so releasing the pins last is safe in both. Good. The timer_delete_sync() worries me a little, though. timer_setup() only runs when data->echo_pin is set, so on a board without echo-gpios this touches a timer_list that was never initialised. remove() has carried the same line for years, but remove() only happens on an unbind, which hardly anyone does; .shutdown runs on every reboot and every kexec, on every pps-gpio board there is. And as far as I can tell no in-tree DT using pps-gpio describes echo-gpios at all, so that is the ordinary case rather than the corner one. Would you mind guarding it with if (data->echo_pin)? The gpiod_set_value() beside it is already a no-op for a NULL descriptor, so that one is fine as it stands. Whether you want to give remove() the same guard while you are there is up to you -- it is pre-existing, so I would not insist on it in this series. > +/* > + * 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) The rest of the patch reads well to me, and the comments are the right length now. My answer on the probe-failure question is on the cover letter. Ciao, Rodolfo