linux-kernel - RE: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <DU0PR04MB9417335A3A41BE4E373B915188472@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date: Mon, 5 Feb 2024 09:11:33 +0000
From: Peng Fan <peng.fan@....com>
To: Linus Walleij <linus.walleij@...aro.org>
CC: Cristian Marussi <cristian.marussi@....com>, Sudeep Holla
	<sudeep.holla@....com>, "Peng Fan (OSS)" <peng.fan@....nxp.com>,
	"souvik.chakravarty@....com" <Souvik.Chakravarty@....com>, Rob Herring
	<robh+dt@...nel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
	Oleksii Moisieiev <oleksii_moisieiev@...m.com>, Shawn Guo
	<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix
 Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
	dl-linux-imx <linux-imx@....com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>, AKASHI Takahiro <takahiro.akashi@...aro.org>,
	Rob Herring <robh@...nel.org>, Nitin Garg <nitin.garg_3@....com>
Subject: RE: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol
 protocol basic support

> Subject: Re: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol
> protocol basic support
>
> On Sun, Feb 4, 2024 at 10:29 AM Peng Fan <peng.fan@....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?

Yes. Code size should be as small as possible.

And using SCMI generic pinconf, there will be multiple
SCMI calls(not MMIO access), such as setting mux(ops->set_mux)
needs an SCMI call, pad settings(ops->pin_config_set) needs an SCMI call.
And maybe ops->get_function_name  needs an extra SCMI call.

With current i.MX design, only one SCMI call is used, which
use less time.

>
> 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 actually.
> Look at i.MX 53 for example:
> https://lore.ke/
> rnel.org%2Flinux-kernel%2F1322999384-7886-2-git-send-email-
> b29396%40freescale.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C
> db0604b1366346a0da1108dc25b3607d%7C686ea1d3bc2b4c6fa92cd99c5c3
> 01635%7C0%7C0%7C638426699551848076%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C0%7C%7C%7C&sdata=j%2FA%2BagoL2EXUzDSkg1wtSENPkuxb0YL1
> nTTB7xCIBTE%3D&reserved=0
>
> 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.

With current:
        pinctrl_uart1: uart1grp {
                fsl,pins = <
                        IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX      0x31e
                        IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX      0x31e
                >;
        };

It is very easy for people to know the meaning from reading reference manual.

If using generic pinconf, the dt node will be like
Uartgrp {
        pins = "uart1txd", "uart1rxd";
        functions = "uart1";
        bias-xx
        drive-strength =
};

The firmware needs add more code to export functions, pack the conf settings,
each pins needs a function name per current i.MX HW logic.

And as I said above, more SCMI calls needed for configure a pin.

So it is not a good fit for i.MX platform using SCP processor to use generic
pinconf for SCMI as I think.

Thanks,
Peng.

>
> Yours,
> Linus Walleij