Received-SPF: pass (google.com: domain of linux-kernel+bounces-190662-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240503162217.1999467-1-sean.anderson@linux.dev>
 <CACRpkdbOAoSDNFhXfz3djUZh1_MQ_T75CC+-LmojRXvyCbUusA@mail.gmail.com> <06a4e5fd-3d26-4923-bcbf-0bdd66d756c4@linux.dev>
In-Reply-To: <06a4e5fd-3d26-4923-bcbf-0bdd66d756c4@linux.dev>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Mon, 27 May 2024 15:15:19 +0200
Message-ID: <CACRpkdbSsgxtKqF6ORXubufTaegjysHU7zH-tJfDfKNd=Kdoeg@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 Mon, May 6, 2024 at 4:45=E2=80=AFPM Sean Anderson <sean.anderson@linux.d=
ev> wrote:

> > 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.

Actually I didn't think that over, it is possible to add new groups
and retain the old ones.

I.e. retain uart0_grp, but additionally add and use
uart0_rxtx and uart0_modem_grp and use one or the
other approach.

> Well, the pin groups are actually defined in the PMU firmware.

Is that firmware written in such an helpful way that the groups
can be extracted from the firmware then, as with SCMI? Or is it
a matter of duplicating the info from the PMU in the software-defined
groups.

> And
> frankly, I don't see the point of pin "groups" when there are not actual
> pin groups at the hardware level. The pins can all be muxed
> individually, so there's no point in adding artificial groups on top.
> Just mux the pins like the hardware allows and everything is easy. Cuts
> down on the absurd number of strings too.

So are you going to switch all of Xilinx devicetrees over to using exclusiv=
ely
the new method (muxing individual pins)?

I'm fine with one (string identified groups) which I encourage, but I
let individual pin control pass as well on several occasions.

What I don't want to see is a Franken-solution that mixes the two
approaches, even less so on the same system. Someone is going to
have to maintain the resulting mess. And this looks like exactly that.

If you want to mux individual pins instead of groups and functions, by
all means, but please do not mix the two approaches in the same
driver, I'm just trying to save Xilinx from themselves here.

Yours,
Linus Walleij