On 24/07/17 18:20, Jassi Brar wrote: > On Mon, Jul 24, 2017 at 4:50 AM, André Przywara <andre.przywara@xxxxxxx> wrote: >> On 02/07/17 06:55, Jassi Brar wrote: >> >>>> + mbox_chan_received_data(link, (void *)res.a0); >>>> + >>> Or you can update the 'data' with value from 'a0' ? >> >> Mmh, I am a bit puzzled by this. Why would this be needed or useful? >> > I meant instead of calling mbox_chan_received_data(), simply update > the value at 'data' with res.a0 > > Technically the firmware does not "send" us a message. It only updates > the structure we share with it. So maybe we could reflect that by > updating the data pointer the client driver asked to send. > Also it is optional for clients to provide the rx_callback(). By > calling mbox_chan_received_data() you mandate clients provide that > callback. > > Nothing serious, just that looking closely, updating 'data' seems a > better option. > >> I see that the SCPI firmware driver (as the user of the mailbox API) is >> expecting the return value from a0 as returned above, translating the >> firmware error codes into Linux' ones. >> > I am afraid, SCPI driver is not the golden example for client drivers > to follow. It is supposed to work only with MHU, and then, it is > likely to break if some other protocol is running parallel to it. > Not sure why do you say it works only with ARM MHU ? AmLogic uses it with their mailbox driver. However they followed an interim version of the SCPI spec which is termed "legacy" in the driver. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
