On 2 September 2014 19:03, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Tue, Sep 02, 2014 at 04:15:05PM -0400, Ashwin Chaugule wrote: > >> > 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" ? > > As previously suggested just looking things up in the context of a > device created to represent the PCC controller seems fine; clients know > they're using PCC so can just call a PCC specific API which hides the > mechanics from them (for example, using a global variable to store the > device). IIUC, this means, either modifying the existing mbox_controller_register() to know when a PCC mbox is being added, or have another PCC specific API for registering as a mailbox? Then, in the PCC specific API that requests a PCC channel, depending on what we do in the registration path, this function can pick out the PCC mailbox pointer and try_module_get(mbox->dev..). Since this is PCC specific anyway, we don't need the client->dev argument at all. Did I understand you correctly? 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
