On 28 August 2014 06:15, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Aug 28, 2014 at 10:39:01AM +0200, Arnd Bergmann wrote: >> On Wednesday 27 August 2014 20:09:02 Mark Brown wrote: > >> > That certainly looks like what it's doing. Probably also make the name >> > that gets passed in const while you're at it. > >> The mailbox API intentionally does not have an interface for >> that: you are supposed to get a reference to an mbox controller >> from a phandle or similar, not by knowing the name of the controller. > > Right, and what he's trying to work around here is that ACPI has chosen > to provide a generic binding for some mailboxes which isn't associated > with anything we represent as a device and he doesn't want to provide > that device as a Linux virtual thing. Just the idea of a table as a device, when it doesn't do any power management, hotplug or anything like a device seemed strange. But I'm open to ideas if we find a good solution. Its highly possible that I'm not seeing it the way you are because the driver subsystem internals are fairly new to me. :) 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. 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? > >> Unfortunately, the three patches that Ashwin posted don't have a >> caller for this function, so I don't know what it's actually used for. >> Why do we need this function for pcc, and what are the names that >> can be passed here? > > AFAICT the names he's interested in will be defined by the ACPI specs. > It does seem like we should be providing a device for the controller and > then either using references in ACPI to look it up if they exist or a > lookup function for this particular namespace that goes and fetches the > device we created and looks up in its context. What is the comparison in this lookup function? A string or a struct device pointer? If it is the latter, how does the client get the reference to the controller struct device? One way would be to register the PCCT as a platform_device and the PCC client as its platform_driver. But I think that will restrict the number of PCC clients to who ever matches first. I suspect this is not what you're implying, so I'd appreciate some more help. 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
