Hi Arnd, On 2 September 2014 15:22, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> > Suppose we create a platform_device for the PCCT (mailbox controller) >> > and another one for the PCC client (mailbox client). How should the >> > PCC client(s) identify the mailbox controller without passing a name? >> > In DT, the "mboxes" field in the client DT entry is all strings with >> > mailbox controller names. > > No, it's not a string at all, it's a phandle, which is more like a > pointer. We intentionally never match by a global string at all, > because those might not be unique. Ok. With PCC, I dont see a way to do this sort of pointer matching. > >> > The "index" in mbox_request_channel() picks >> > up one set of strings. How should this work with PCC? Should we use >> > the PCC client platform_device->dev->platform_data to store mailbox >> > controller strings? > > I didn't think there was more than one PCC provider, why do you even > need a string? > > For the general case in ACPI, there should be a similar way of looking > up mailbox providers to what we have in DT, but if I understand you > correctly, the PCC specification does not allow that. Right. At least not in a way DT does. PCC clients know if something needs to be written/read via PCC mailbox and can identify a PCC subspace. (i.e. Mailbox channel). The PCC mailbox is uniquely identified/defined in the spec. #define ACPI_ADR_SPACE_PLATFORM_COMM (acpi_adr_space_type) 10 So we could use this ID instead of a string and use that to look up the PCC controller for a PCC client. > > Using platform_data would no be helpful, because there is no platform > code to fill that out on ACPI based systems. Right. So the question is how do we work around the "mbox->dev" and "client->dev" expectations in the Mailbox framework for PCC, given that these tables aren't backed by "struct devices" ? Thanks, 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
