On Wed, Nov 12, 2014 at 01:59:30PM +0000, Paolo Bonzini wrote: > > > On 12/11/2014 14:41, Mark Rutland wrote: > > Writing a binding for the partiuclar device might be trivial. How this > > would fit with the DT model is more complicated, and needs to be > > specified. As far as I can see, those documents are quite strongly tied > > to x86 ACPI (they talk in terms of OSPM, OST, GPE, APIC IDs). > > OSPM -> replace with kernel driver > OST -> used to generate events, doesn't need to be implemented in the > kernel driver. Or just define the meaning based on the ACPI > _OST spec. > GPE -> replace with GPIO > APIC ID -> replace with whatever id ARM CPUs have > > > I agree that we could do CPU and memory hotplug without ACPI, but we > > need to specify the full firmware interface for doing so, and how this > > interacts with the initial DTB if using DT. > > The initial DTB has to expose the IDs for hotpluggable CPUs and the > range for hotpluggable memory. In the ACPI case this goes in the SRAT. > But none of this is insurmountable.
My only point is that it needs to be defined, not that this definition is impossible. That does trickle into a few places -- we currently have no way of defining a CPU in DT which is possible but not present, for example (the status property historically means something different per ePAPR). > > We can't just pick-and-mix > > portions of ACPI and state that it's specified and standard. > > But that's what you already do if you want to build ACPI tables from DT. > You are already picking-and-mixing the variable portions of the ACPI > tables and make a DT bindings for them. I don't follow. I argued _against_ trying to build ACPI tables from DT because the two don't quite match up anyway. I argued _against_ trying to convert ACPI tables to DT in prior discussions for similar reasons. > All that's left is to de-x86ify the existing spec (which is really > easy), and to figure out a DT binding for it. It's really not unlike > any other MMIO device. In addition to fixing up the other specs which are affected by this (e.g. how we describe those additional CPUs). There's also some de-ACPIing to be done in addition to de-x86ification, and we need to be careful to ensure we have access to all the information we require in the absence of ACPI, and that we have a well defined behaviour on both sides of the interface for what would previously have been implicit in ACPI. I'm not saying that this is impossible. It's just a greater body of work than modifying one spec. Thanks, Mark.