linux-kernel - Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

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, 16 Jul 2013 19:32:48 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Rob Herring <robherring2@...il.com>
cc:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	devicetree-discuss@...ts.ozlabs.org,
	Jon Medhurst <tixy@...aro.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Pawel Moll <pawel.moll@....com>,
	Achin Gupta <achin.gupta@....com>,
	Amit Kucheria <amit.kucheria@...aro.org>
Subject: Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power
 Controller (SPC) support

On Tue, 16 Jul 2013, Rob Herring wrote:

> On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
> > The TC2 versatile express core tile integrates a logic block that provides the
> > interface between the dual cluster test-chip and the M3 microcontroller that
> > carries out power management. The logic block, called Serial Power Controller
> > (SPC), contains several memory mapped registers to control among other things
> > low-power states, wake-up irqs and per-CPU jump addresses registers.
> > 
> > This patch provides a driver that enables run-time control of features
> > implemented by the SPC power management control logic.
> > 
> > The SPC control logic is required to be programmed very early in the boot
> > process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
> > wake-up IRQs for power management. Hence, waiting for core changes to be
> > made in the device core code to enable early registration of platform
> > devices, the driver puts in place an early init scheme that allows kernel
> > drivers to initialize the SPC driver directly from the components requiring
> > it, if their initialization routine is called before the driver init
> > function by the boot process.
> > 
> > Device tree bindings documentation for the SPC component is provided with
> > the patchset.
> 
> Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
> most/all of this code?

There is a PSCI equivalent for the above already, in the sense that 
there is a simple MCPM backend that bypass most of the MCPM race 
avoidance code paths and simply calls into PSCI instead.  But not all 
the world is going to be PSCI, and therefore we need to ensure good 
support for non-PSCI platforms as well.

This is why TC2 supports both, and this also ensure that the PSCI 
implementation, which won't be part of the kernel and therefore unlikely 
to get the same level of scrutiny, is properly implemented and doesn't 
introduce any regression when compared to the non PSCI case.

Remember that TC2 is multi-cluster which means that the PSCI 
implementation has to carry the same amount of complexity as the whole 
in-kernel MCPM layer and that doesn't make me overly confident it is 
going to always be right.

All this to say that we do need this code despite PSCI availability.


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