Received-SPF: pass (google.com: domain of linux-kernel+bounces-51850-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240121-pinctrl-scmi-v3-0-8d94ba79dca8@nxp.com>
 <f88d07ef-83b2-4d14-976a-6dbbd71e036f@oss.nxp.com> <CACRpkdYV=qYQ9qDUWYTLDAV1niay30gYH5S=zjfi31GpeY5o-A@mail.gmail.com>
 <DU0PR04MB9417A9074C5DC49AE689E65288432@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <Zbt-QkWhz5d9P-v6@pluto> <DU0PR04MB9417CA6CF089B264112C32A088402@DU0PR04MB9417.eurprd04.prod.outlook.com>
In-Reply-To: <DU0PR04MB9417CA6CF089B264112C32A088402@DU0PR04MB9417.eurprd04.prod.outlook.com>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Sun, 4 Feb 2024 19:58:59 +0100
Message-ID: <CACRpkdYCrbNB8wu4rO3Yx0qomxR3kTt0P7YH7kc2HPCbrgt=tg@mail.gmail.com>
Subject: Re: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol
 protocol basic support
To: Peng Fan <peng.fan@nxp.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, 
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>, 
	"souvik.chakravarty@arm.com" <Souvik.Chakravarty@arm.com>, Rob Herring <robh+dt@kernel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, 
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Shawn Guo <shawnguo@kernel.org>, 
	Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, 
	Fabio Estevam <festevam@gmail.com>, dl-linux-imx <linux-imx@nxp.com>, 
	"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, 
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>, AKASHI Takahiro <takahiro.akashi@linaro.org>, 
	Rob Herring <robh@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 4, 2024 at 10:29=E2=80=AFAM Peng Fan <peng.fan@nxp.com> wrote:

> Using generic pinconf means the firmware needs exporting groups/functions=
/pins
> and etc, the firmware design will be complicated and code size enlarged.

This is very much to the core of the problem isn't it?

So the argument is to save code effort and size in the firmware.

This reflects some of the reasoning behind the device tree bindings
that encode "magic numbers" in the DT nodes to mux and configure
pins. Often the argument is that it saves space and effort.

When the i.MX driver was first discussed it used the standard scheme actual=
ly.
Look at i.MX 53 for example:
https://lore.kernel.org/linux-kernel/1322999384-7886-2-git-send-email-b2939=
6@freescale.com/

Groups and functions! As strings!

Then the DT bindings were discussed back and forth between Dong
Aisheng (the original driver author), Sasha Hauer and Shawn Guo
before arriving at the fsl,pins scheme.

Back in the day I was pretty much clueless about device tree and
relied on others to review the bindings, which ended up like this:
Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt

This was in 2011/2012 so many things were not considered. It is
clear that this scheme with a number of integers that get poked into
registers is convenient for some DT authors, also pinctrl-single uses
this as well as I think Mediatek and maybe a few others.

Over the years I have come to regret it a bit, I think insisting on
groups and functions as strings is better for abstraction. And the point
of firmware is to abstract things so they work the same on all systems.

Yours,
Linus Walleij