Hi Arnd, On 20 June 2014 15:08, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Friday 20 June 2014 14:55:16 Ashwin Chaugule wrote: >> So, in order to get an mbox->dev for ACPI platforms, we'd need an >> entry in the DSDT table. That seems rather pointless, since the DSDT >> is reserved for devices and is supposed to be OS agnostic. Since the >> mailbox controller itself is not really a "device" with a resource >> descriptor, I dont see the point in adding a dummy DSDT entry for the >> sake of getting this `struct device`. Also, I'm told adding new >> entries to this table requires registering a unique 4 character >> identifier and approval from some committees. If there are other ways >> to get this structure I'd like to hear about it. >> >> The other alternative would be to piggy back on the ACPI CPU detection >> code, which looks for the ACPI0007 device node in the DSDT and use >> that as the mbox controller device. This node is already registered >> and is an established method to detect CPUs. But I'm not sure what >> happens when CPUs are hotplugged off, we surely dont want mailbox >> clients such as PCC to break. > > The main question here is whether you expect having to support multiple > mailbox devices in an ACPI system. If you think there is never more than > one, you wouldn't need a DSDT entry, but if you can end up in a situation > where another device needs to specify which mailbox it is using, then > you need that entry anyway. At this point, I dont see the need for multiple mailbox devices. But I'm not seeing why we'd need a DSDT entry only if there are more than one mailbox devices? I'd obviously prefer not having a DSDT entry for this, and the patch I posted is the only way I could see to keep DT and ACPI mbox supported at runtime without DSDT involved. Please let me know if there are better ways. Cheers, Ashwin -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
