linux-kernel - Re: [PATCH v3] [RFC] arm: use PSCI if available

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:	Thu, 28 Mar 2013 13:38:20 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"arnd@...db.de" <arnd@...db.de>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3] [RFC] arm: use PSCI if available

On 03/28/2013 10:39 AM, Nicolas Pitre wrote:
> On Thu, 28 Mar 2013, Rob Herring wrote:
> 
>> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
>>> On Thu, 28 Mar 2013, Stefano Stabellini wrote:
>>>
>>>> - the interface to bring up secondary cpus is different and based on
>>>> PSCI, in fact Xen is going to add a PSCI node to the device tree so that
>>>> Dom0 can use it.
>>>>
>>>> Oh wait, Dom0 is not going to use the PSCI interface even if the node is
>>>> present on device tree because it's going to prefer the platform smp_ops
>>>> instead.
>>>
>>> Waitaminute...  I must have missed this part.
>>>
>>> Who said platform specific methods must be used in preference to PSCI?
>>
>> I did. Specifically, I said the platform should be allowed to provide
>> its own smp_ops. A platform may need to do addtional things on top of
>> PSCI for example.
> 
> Then the platform should have its special hook that would override the 
> default PSCI methods.  But, by *default* the PSCI methods should be used 
> if the related DT information is present.

Agreed. The special hook to override is setting mach desc smp_ops, right?

>>> If DT does provide PSCI description, then PSCI should be used.  Doing 
>>> otherwise is senseless.  If PSCI is not to be used, then it should not 
>>> be present in DT.
>>
>> You can't assume the DT and kernel are in-sync. For example, I've added
>> PSCI in the firmware and DTB (part of the firmware), but the highbank
>> kernel may or may not use it depending if I convert it.
> 
> If the kernel does not understand PSCI bindings in the DT, it naturally 
> won't use PSCI, right?  Conversely, if the firmware and therefore 
> provided DT don't have PSCI, then the PSCI enabled kernel won't use PSCI 
> either. So what is the problem?

I'm distinguishing the kernel in general is enabled for PSCI and a
platform is enabled. The kernel may have PSCI smp_ops and the DTB may
have PSCI data, but that alone should not make a platform use the
default PSCI smp_ops. The platform has to make the decision and it
cannot be just based on the platform's dtb having PSCI data.

I have firmware (dtb is part of the firmware) with PSCI support and
older firmware without. Old/existing kernels are fine on both firmware
versions and don't use PSCI. New kernels with default PSCI ops should
continue to work with both versions. When/If I convert highbank to use
PSCI in the kernel, only then will new kernels require the new firmware
version. Or perhaps I need to support both in the kernel for a while
before ripping out non PSCI code. There is enough lag in distro kernels
that I don't think this is necessary.

Rob

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