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] [day] [month] [year] [list]
Date:   Tue, 28 May 2019 13:37:15 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Lucas Stach <l.stach@...gutronix.de>,
        Guido Günther <agx@...xcpu.org>
CC:     Abel Vesa <abel.vesa@....com>, Jacky Bai <ping.bai@....com>,
        Anson Huang <anson.huang@....com>,
        Fabio Estevam <festevam@...il.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions

On 22.05.2019 16:40, Lucas Stach wrote:
> Am Mittwoch, den 22.05.2019, 13:30 +0000 schrieb Leonard Crestez:
>> On 22.05.2019 16:13, Guido Günther wrote:
>>> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
>>> On Wed, May 08, 2019 at 02:40:18PM +0200, Guido Günther wrote:

>>>> Thanks for your comments. Let's try s.th. different then: identify by
>>>> bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
>>>> out the DT part and add binding docs if this makes sense). I'm also
>>>> happy to drop the whole ATF logic until mailine ATF catched up:
>>>>
>>>> The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
>>>> nor does it have the code to identify different imx8mq SOC revisions so
>>>> mimic what NXPs ATF does here.
>>>
>>> Does this makes sense? If so I'll send this out as a series.
>>
>> Mainline ATF has recently caught up:
>>
>>>> As a fallback use ATF so we can identify new revisions once it gains
>>>> support or when using NXPs ATF.
>>>
>>> I'm also fine with dropping the ATF part if we don't want to depend on
>>> it in mainline.
>>
>> Linux arm64 depends on ATF to implement power management via PSCI:
>> hotplug cpuidle and suspend.
>>
>> It is not clear why Linux would avoid other services and insist on
>> reimplementing hardware workarounds.
> 
> I fully agree. We should not duplicate functionality between ATF and
> Linux kernel.

Excellent, will remember this when debating who should manipulate GPC.

Guido: Are you going to resend a variant of your V1?

You mentioned that you need this for erratas, how exactly are you going 
to fetch soc revision from a driver? For 32bit imx there is a global 
imx_get_soc_revision(), maybe the definition could be moved from 
arch/arm/mach-imx/cpu.c to drivers/soc/imx/revision.c so that it's 
available everywhere?

--
Regards,
Leonard

Powered by blists - more mailing lists