linux-kernel - Re: [PATCH v2] soc: imx: Add generic i.MX8 SoC driver

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:   Tue, 26 Feb 2019 13:34:52 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Abel Vesa <abel.vesa@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Jacky Bai <ping.bai@....com>
CC:     dl-linux-imx <linux-imx@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stefan@...er.ch" <stefan@...er.ch>,
        "abelvesa@...ux.com" <abelvesa@...ux.com>,
        "spencercw@...il.com" <spencercw@...il.com>,
        Fabio Estevam <fabio.estevam@....com>,
        "robh@...nel.org" <robh@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Anson Huang <anson.huang@....com>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH v2] soc: imx: Add generic i.MX8 SoC driver

On Tue, 2019-02-26 at 10:53 +0000, Abel Vesa wrote:
> Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
> For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
> revision it will print 'unknown'.
> 
> +	np = of_find_compatible_node(NULL, NULL, "fsl,imx8mq-ocotp");
> +	if (!np)
> +		goto out;
> +
> +	ocotp_base = of_iomap(np, 0);
> +	WARN_ON(!ocotp_base);
> +
> +	magic = readl_relaxed(ocotp_base + IMX8MQ_SW_INFO_B1);
> +	if (magic == IMX8MQ_SW_MAGIC_B1)
> +		rev = REV_B1;

Turns out that imx8mq version determination is uniquely messy. I think
we should try to print the revision number even for older chips so that
we know how old they are, but this code can be enhanced in later
patches.

In the vendor tree we handle this with a SIP call to ATF, it's not
clear why we shouldn't just upstream that (in both ATF and Linux).

Also, there are some imx soc revision declarations in
include/soc/imx/revision.h. Those are implemented in arch/arm/mach-imx
for older chips, would it make sense for soc-imx8 to define
imx_get_soc_revision?

--
Regards,
Leonard