On 1/12/25 4:59 PM, Jassi Brar wrote: >>>>> Then I updated the mailbox core to allow clients to request channels by >>>>> passing some args containing channel identifiers to the controllers, >>>>> that the controllers xlate() using their own method. >>>>> >>>> This is unnecessary. >>>> If you don't pass the doorbell number from DT, each channel populated >>>> by the driver is just a s/w construct or a 'virtual' channel. Make use >>>> of 'void *data' in send_data() to specify the doorbell. >>>> >>> I think this introduces concurrency problems if the channel identifiers >>> passed by 'void *data' don't match the virtual channel used for sending >>> the messages. Do we want to allow this? >>> >>> Also, if we use 'void *data' to pass channel identifiers, the channel >>> checks will have to be made at send_data() time. Thus if passing wrong >>> channel type for example, the mailbox client will eventually get a >>> -ENOBUFS and a "Try increasing MBOX_TX_QUEUE_LEN" message, which I find >>> misleading. >> >> Shall I still use 'void *data' to pass channel identifiers through >> send_data()? I'd like to respin everything. >> > Yes, please do. > What shall I do in driver's of_xlate method, always return &mbox->chans[0], as bcm2835 does? All 14 doorbels will be serialized with mobox->chans[0].lock. I could use a list of channels in the controller and provide some get/put channel methods, but the virtual channel ID will not match the actual channel ID that's used for communication. I'll also need to introduce channel ops, to put the channel that was acquired via of_xlate from the list of available channels. Aren't we better off with the mbox_request_channel_by_args() that I introduced in v6? Or if you think there's better option I'll be happy to implement it. I need an agreement on the overall idea. Thanks, ta
