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]

Date:   Fri, 25 Aug 2023 10:28:49 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Peng Fan <peng.fan@....com>
Cc:     "Peng Fan (OSS)" <peng.fan@....nxp.com>,
        "oleksii_moisieiev@...m.com" <oleksii_moisieiev@...m.com>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        Aisheng Dong <aisheng.dong@....com>,
        "festevam@...il.com" <festevam@...il.com>,
        Jacky Bai <ping.bai@....com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        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>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [RFC] scmi: pinctrl: support i.MX9

On Thu, Aug 24, 2023 at 2:47 PM Peng Fan <peng.fan@....com> wrote:
> Me:

>> it is merely making things more complex and also slower
> > bymaking the registers only accessible from this SCMI link.
>
> This is for safety reason, the pinctrl hardware must be handled
> by a system manager entity. So mmio direct access not allowed
> from Cortex-A side.

Yeah I understood as much. But I don't think that the firmware is
really filtering any of the access, it will just poke into any pinctrl
register as instructed anyway so what's the point. Just looks like
a layer of indirection. But I'm not your system manager, so it's not
my decision.

> The SCMI firmware is very straightforward, there is no group or
> function.
>
> It just accepts the format as this:
> MUX_TYPE, MUX VALUE, CONF_TYPE, CONF_VAL, DAISY_TYPE,
> DAISY ID, DAISY_CFG, DAISY_VALUE.
>
> Similar as linux MMIO format.
>
> Our i.MX95 platform will support two settings, one with SCMI
> firmware, one without SCMI. These two settings will share
> the same pinctrl header file.
>
> And to simplify the scmi firmware design(anyway I am not owner
> of the firmware), to make pinctrl header shared w/o scmi,
> we take the current in-upstream freescale imx binding format.

The SCMI people will have to state their position on this.
Like what they consider conformance and what extensions are
allowed. This is more a standardization question than an
implementation question so it's not really my turf.

I was under the impression that the ambition with SCMI firmware
was to abstract away and hide aspects of the hardware behind
a consistent API. This approach drives a truck through that
idea.

Yours,
Linus Walleij