[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 6/6] [RFC] arm: use PSCI if available



On Tue, 26 Mar 2013, Nicolas Pitre wrote:
> On Tue, 26 Mar 2013, Arnd Bergmann wrote:
> 
> > On Tuesday 26 March 2013, Will Deacon wrote:
> > > > They can even base the implementation of their smp_ops on the current
> > > > psci code, in order to facilitate that I could get rid of psci_ops
> > > > (which initialization is based on device tree) and export the psci_cpu_*
> > > > functions instead, so that they can be called directly by other smp_ops.
> > > 
> > > Again, I think this destroys the layering. The whole point is that the 
> > > PSCI
> > > functions are called from within something that understands precisely how 
> > > to
> > > talk to the firmware and what it is capable of.
> > 
> > Right, we probably the psci smp ops to be separate from the rest of the psci
> > code, but I also think that Stefano is right that we should let any platform
> > use the psci smp ops if possible, rather than having to implement their own.
> 
> Oh absolutely.  It is always best to use an existing standard.  But PSCI 
> probably won't be the only firmware interface standard.  It therefore 
> shouldn't be used as the Linux internal interface model.

I am not proposing to use PSCI as an interal Linux API.

I am proposing to use a set of PSCI based smp_ops (instead of the ones
that come with machine_desc, if any) if a PSCI node is available on
device tree.

smp_ops remains the internal Linux API.

I am also saying that we should let people reuse the PSCI functions in
their own machine-specific smp_ops, if they want to.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.