linux-kernel - Re: [PATCH v4 1/5] devicetree: bindings: document Broadcom CPU enable method

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:	Wed, 28 May 2014 14:34:28 +0100
From:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:	Alex Elder <elder@...aro.org>
Cc:	"mporter@...aro.org" <mporter@...aro.org>,
	"bcm@...thebug.org" <bcm@...thebug.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
	"bcm-kernel-feedback-list@...adcom.com" 
	<bcm-kernel-feedback-list@...adcom.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"jason@...edaemon.net" <jason@...edaemon.net>,
	Mark Rutland <Mark.Rutland@....com>,
	Pawel Moll <Pawel.Moll@....com>,
	"rdunlap@...radead.org" <rdunlap@...radead.org>,
	"rjui@...adcom.com" <rjui@...adcom.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"rvaswani@...eaurora.org" <rvaswani@...eaurora.org>
Subject: Re: [PATCH v4 1/5] devicetree: bindings: document Broadcom CPU
 enable method

On Wed, May 28, 2014 at 01:22:06PM +0100, Alex Elder wrote:
> On 05/28/2014 05:36 AM, Lorenzo Pieralisi wrote:
> > On Wed, May 28, 2014 at 04:30:47AM +0100, Alex Elder wrote:
> >> On 05/27/2014 06:49 AM, Lorenzo Pieralisi wrote:
> >>> On Tue, May 20, 2014 at 06:43:46PM +0100, Alex Elder wrote:
> >>>> Broadcom mobile SoCs use a ROM-implemented holding pen for
> >>>> controlled boot of secondary cores.  A special register is
> >>>> used to communicate to the ROM that a secondary core should
> >>>> start executing kernel code.  This enable method is currently
> >>>> used for members of the bcm281xx and bcm21664 SoC families.
> >>>>
> >>>> The use of an enable method also allows the SMP operation vector to
> >>>> be assigned as a result of device tree content for these SoCs.
> >>>>
> >>>> Signed-off-by: Alex Elder <elder@...aro.org>
> >>>
> >>> This is getting out of control, it is absolutely ghastly. I wonder how
> >>> I can manage to keep cpus.txt updated if anyone with a boot method
> >>> du jour adds into cpus.txt, and honestly in this specific case it is even
> >>> hard to understand why.
> >>
> >> OK, in this message I'll focus on the particulars of this
> >> proposed binding.
> >>
> >>> Can't it be done with bindings for the relative register address space
> >>> (regmap ?) and platform code just calls the registers driver to set-up the
> >>> jump address ? It is platform specific code anyway there is no way you
> >>> can make this generic.
> >>
> >> I want to clarify what you're after here.
> >>
> >> My aim is to add SMP support for a class of Broadcom SMP
> >> machines.  To do so, I'm told I need to use the technique
> >> of assigning the SMP operations vector as a result of
> >> identifying an enable method in the DT.
> >>
> >> For 32-bit ARM, there are no generic "enable-method" values.
> >> (I did attempt to create one for "spin-table" but that was
> >> rejected by Russell King.)  For the machines I'm trying to
> >> enable, secondary CPUS start out spinning in a ROM-based
> >> holding pen, and there is no need for a kernel-based one.
> >>
> >> However, like a spin-table/holding pen enable method, a
> >> memory location is required for coordination between the
> >> boot CPU running kernel code and secondary CPUs running ROM
> >> code.  My proposal specifies it using a special numeric
> >> property value named "secondary-boot-reg" in the "cpus"
> >> node in the DT.
> >>
> >> And as I understand it, the issue you have relates to how
> >> this memory location is specified.
> > 
> > The issue I have relates to cluttering cpus.txt with all
> > sorts of platform specific SMP boot hacks.
> 
> OK, as I mentioned in my other message, I totally
> agree with you here.  It's a total (and building)
> mess.  I discussed this with Mark Rutland at ELC
> last month and suggested splitting that stuff out
> of "cpus.txt", which I have now proposed with a
> patch.
>     https://lkml.org/lkml/2014/5/8/545

I think this makes sense, I will review that patchset, and with this
approach agreed I am ok with adding a platform specific boot method,
since it is split up "nicely", do not bother adding a specific driver
to poke a register (it will be fun to see the number of files we have
to add to /cpu-enable-method though, big fun).

I still think that it is high time we started pushing back on these
platform hacks and move towards a common interface like PSCI to boot
(and suspend) ARM processors, there is no reason whatsoever why this
can't be done on the platforms you are trying to get merged unless I am
missing something.

Lorenzo

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