Hi, (at home already), On Fri, 2010-11-19 at 07:57 -0600, Kanigeri, Hari wrote: > > think of it as FIFO. So the first completed message is the first in your > > list of requests. Ain't that easy ? :-) > > Actually it isn't that easy ;) because there is no guarantee that the > completed message is the first one in the list of requests. > Responses could be asynchronous and we cannot depend on serialized > handling of requests on BIOS...even in some cases you might not even > get a response for particular request in which case you have to handle > that in IPC module. you did not get what I said then. users will queue a request, which is simply a list_add_tail() to the mailbox's request list. Then you kick the transfers which will: request = list_first_entry(mbox->req_list); setup_correct_registers(); enable_irq(); kick_transfer(); return; then on IRQ handler, when the message is completed you do: request = list_first_entry(mbox->req_list); list_del(request->list); /* unlock */ request->complete(); /* lock again */ you will always one message at a time, so you know that when you get the IRQ, the first message on your list is what was just completed. > eg: Process A sends a message to M3 core to kick off some translation > in some codec, the thread handling this request running on BIOS would > kick off the translation and wait for the completion before sending > the response. In the mean time BIOS will be handling other requests > coming to it, and shouldn't be blocked until the completion of first > request. why you're involving BIOS here ? mailbox should not have to know what's on the other side. All it needs to know is how to get the message to the other side, no matter _what_ it is. So until BIOS sends the response, you would not start another transfer on mailbox neither you would any IRQ, right ? > > Still it doesn't the fact that currently you allow for that. There are > > malware writers everywhere. But hey, it would be cool to have mailbox > > appear on securityfocus.com :-p > > > > Agree about malware writers. Add PM interfaces as well to the list as > one can misuse them as well ;) for PM interfaces it's a bit more difficult and you cannot tamper with another device's PM (well, after all are converted to hwmod, that is) and on top of that, the biggest trouble you will run into, is your battery dying quickly. With mailbox you have actual useful data coming back and forth, no ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
