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. Thanks -- 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
