Received-SPF: pass (google.com: domain of linux-kernel+bounces-169372-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240503162217.1999467-1-sean.anderson@linux.dev>
In-Reply-To: <20240503162217.1999467-1-sean.anderson@linux.dev>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Mon, 6 May 2024 08:43:49 +0200
Message-ID: <CACRpkdbOAoSDNFhXfz3djUZh1_MQ_T75CC+-LmojRXvyCbUusA@mail.gmail.com>
Subject: Re: [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins
To: Sean Anderson <sean.anderson@linux.dev>
Cc: Michal Simek <michal.simek@amd.com>, linux-gpio@vger.kernel.org, 
	Krishna Potthuri <sai.krishna.potthuri@amd.com>, linux-kernel@vger.kernel.org, 
	linux-arm-kernel@lists.infradead.org, Conor Dooley <conor+dt@kernel.org>, 
	Krzysztof Kozlowski <krzk+dt@kernel.org>, Rob Herring <robh@kernel.org>, devicetree@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 3, 2024 at 6:22=E2=80=AFPM Sean Anderson <sean.anderson@linux.d=
ev> wrote:

> This series adds support for muxing individual pins, instead of
> requiring groups to be muxed together. See [1] for additional
> discussion.
>
> [1] https://lore.kernel.org/linux-arm-kernel/5bb0dc7e-4c89-4f3d-abc6-41ae=
9ded5ae9@linux.dev/

The way I usually would recommend to solve this would be to
define new subgroups, so e.g. for a UARTS:

uart0_grp =3D pin_rx, pin_tx, pin_cts, pin_dts, pin_dcd;

And today this would be used like that:

mux0:
    function =3D "uart0";
    groups =3D "uart0_grp";

Then we realize that not everyone need all the modem
control signals provided. What to do. Well this:

uart0_rxtx_grp =3D pin_rx, pin_tx:
uart0_modem_grp =3D pin_cts, pin_dts, pin_dcd;

mux0:
    function =3D "uart0";
    groups =3D "uart0_rxtx_grp";

Now the CTS, DTS, DCD pins can be reused for something
else such as GPIO.

I *know* that this breaks ABI: the driver group definitions change
and the device tree needs to be changed too.

This only matters if the users have a habit of distributing the
kernel and DTB separately so a new kernel needs to support
and old DTB. This varies in how much control we have but I
think for Xilinx systems the kernel and DTB are always updated
in lockstep, so it really does not matter?

Yours,
Linus Walleij