Re: [PATCH v6 3/4] dt-bindings: pps: pps-gpio: document optional pinctrl states

[Rob Herring]

On Wed, Sep 23, 2026 at 06:22:42PM +0000, Eliav Farber wrote:
> 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 <farbere@xxxxxxxxxx>
> ---
> Changes in v6:
> - No change. Rob Herring confirmed the two-entry ["default", "inactive"]
>   items list is fine as-is; the "sleep" state discussed on the list is not
>   something this binding needs
> 
> 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(-)

Reviewed-by: Rob Herring (Arm) <robh@xxxxxxxxxx>

In the future, don't thread new versions to old versions.