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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
