On Wednesday 03 September 2014 11:23:21 Ashwin Chaugule wrote: > 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? Yes, I think this would be reasonable. Arnd -- 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
