On Wednesday 03 September 2014 11:23:21 Ashwin Chaugule wrote:
On 2 September 2014 19:03, Mark Brown broonie@kernel.org 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