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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230824105137.xqkwi4xvmjoidexh@bogus>
Date:   Thu, 24 Aug 2023 11:51:37 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     "Peng Fan (OSS)" <peng.fan@....nxp.com>,
        oleksii_moisieiev@...m.com, Sudeep Holla <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

Hi Linus,

Thanks a lot for the quick response.

On Thu, Aug 24, 2023 at 10:43:20AM +0200, Linus Walleij wrote:
> 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.
>

Good to know.

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

Correct.

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

Agreed.

I don't have much knowledge on generic pinmux conf and suggested Peng
to post the RFC to start the discussion instead of getting blocked by me
during some internal/private discussions as the main intention for him
was upstreaming the changes. I am against the idea of mixing platform
specific changes the way it is done here but since I didn't have much
knowledge on pinmux conf to suggest/provide any useful feedback I suggested
to trigger this discussion.

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

+1

-- 
Regards,
Sudeep