linux-kernel - Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC

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: <20150413105618.GD4076@leverpostej>
Date:	Mon, 13 Apr 2015 11:56:19 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Chanwoo Choi <cw00.choi@...sung.com>,
	"kgene@...nel.org" <kgene@...nel.org>,
	"arnd@...db.de" <arnd@...db.de>, "olof@...om.net" <olof@...om.net>
Cc:	Marc Zyngier <Marc.Zyngier@....com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"inki.dae@...sung.com" <inki.dae@...sung.com>,
	"chanho61.park@...sung.com" <chanho61.park@...sung.com>,
	"sw0312.kim@...sung.com" <sw0312.kim@...sung.com>,
	"jh80.chung@...sung.com" <jh80.chung@...sung.com>,
	"ideal.song@...sung.com" <ideal.song@...sung.com>,
	"a.kesavan@...sung.com" <a.kesavan@...sung.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit
 Exynos5433 SoC

Hi Chanwoo,

Could you please reply to the below?

Without an answer I'm going to have to ask for the patch to be unqueued
for the moment, and I'd prefer that we came to a solution instead.

Thanks,
Mark.

On Tue, Apr 07, 2015 at 11:25:27AM +0100, Mark Rutland wrote:
> > >>> I'm very worried about adding a DT that's known broken, especially when
> > >>> we have no idea as to if/when the FW will be fixed judging from prior
> > >>> replies.
> > >>
> > >> As I replied, I can not fix the FW because I don't have any code of FW.
> > > 
> > > Surely you are able to contact those who do?
> > > 
> > >> I don't have any solution to fix it on Linux kernel level.
> > >>
> > >> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
> > > 
> > > I disagree. I do not want to add a DT that is known to be broken;
> > > especially when we have no idea how to fix it. It creates long-term
> > > maintenance pain for everyone, and marginal gain for few. A comment does
> > > nothing to aid the end-user.
> > > 
> > > So NAK to the PSCI node and PSCI enable method in this dts until we
> > > either have a working firmware, or a reasonable mechanism to handle the
> > > deficiency.
> > 
> > There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
> 
> I understand that, but the issue with CPU0 is still a blocker from my
> PoV.
> 
> > To fix this issue, we must need the help of firmware developer.
> > But, We never get the any help.
> 
> Previously you said that you did not have access to the source code
> rather than not having help from the relevant firmware engineers. I take
> it you have informed them of the issue with CPU0?
> 
> > Also, as I mentioned on previous mail, all Exynos SoCs can not turn
> > off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
> 
> While that may be the case, PSCI is a more generic standard, and it is
> used on systems where CPU0 can be hot unplugged. So Exynos-specific
> details cannot dictate how the kernel PSCI driver should behave.
> 
> Is there a particular reason that CPU0 cannot be hotplugged?
> 
> In PSCI 0.2 and later it's possible to determine whether a trusted OS
> prohibits a core from being hotplugged, but this mechanism doesn't exist
> in earlier versions. I am not averse to adding a property to PSCI 0.1
> to mark a CPU as not being hotpluggable if there is a fundamental reason
> (i.e. not simply a bug) for this being the case.
> 
> Thanks,
> Mark.
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/