linux-kernel - Re: [RFC] scmi: pinctrl: support i.MX9

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: <CACRpkdYU7MRXRV3Uw1w300sdxv=9XT=P1vFFarHfpSM6BT20Hg@mail.gmail.com>
Date:   Thu, 24 Aug 2023 10:43:20 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc:     oleksii_moisieiev@...m.com, sudeep.holla@....com,
        aisheng.dong@....com, festevam@...il.com, ping.bai@....com,
        s.hauer@...gutronix.de, shawnguo@...nel.org, kernel@...gutronix.de,
        linux-imx@....com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        Peng Fan <peng.fan@....com>
Subject: Re: [RFC] scmi: pinctrl: support i.MX9

On Thu, Aug 24, 2023 at 9:01 AM Peng Fan (OSS) <peng.fan@....nxp.com> wrote:

> This patch is just to introduce i.MX support to see whether people have
> comments for the design.

Very interesting!

> The binding format:
> <mux_reg conf_reg input_reg mux_mode input_val>
> dts:
>         pinctrl_uart1: uart1grp {
>                 fsl,pins = <
>                         MX93_PAD_UART1_RXD__LPUART1_RX                  0x31e
>                         MX93_PAD_UART1_TXD__LPUART1_TX                  0x31e
>                 >;
>         };
>
> i.MX pinctrl not use generic pinconf, this has been agreeed by
> maintainers before.

Yes, it has historical reasons.

> So after moving to SCMI, we will still
> keep the same binding format, and i.MX SCMI firmware also use same
> format when configure registers. So we need to use i.MX specific
> dt_node_to_map function.

I thought the idea with SCMI was to abstract and hide the characteristics of
the underlying hardware. I.e. the firmware is to present groups and
functions and generic config options and then the driver will use these.

This patch, it seems, creates a hybrid between the old freescale driver
and the SCMI firmware communication link where the SCMI is just a
transport mechanism to something inside SCMI that poke the same
registers that userspace could poke, if it could only access these
registers.

I.e using SCMI on this platform isn't creating any abstraction of the
pin control hardware, it is merely making things more complex and
also slower bymaking the registers only accessible from this SCMI link.

But I could have misunderstood it, so please correct me!

Yours,
Linus Walleij