On Tue, Feb 13, 2018 at 9:07 PM, Kalle Valo <[email protected]> wrote: > Amitkumar Karwar <[email protected]> writes: > >> On Thu, Feb 1, 2018 at 12:26 PM, Kalle Valo <[email protected]> wrote: >>> Amitkumar Karwar <[email protected]> writes: >>> >>>> From: Prameela Rani Garnepudi <[email protected]> >>>> >>>> With BT support, driver has to handle two streams of data >>>> (i.e. wlan and BT). Actual coex implementation is in firmware. >>>> Coex module just schedule the packets to firmware by taking them >>>> from the corresponding paths. >>>> >>>> Structures for module and protocol operations are introduced for >>>> this purpose. Protocol operations structure is global structure >>>> which can be shared among different modules. Initialization of >>>> coex and operating mode values is moved to rsi_91x_init(). >>>> >>>> Signed-off-by: Prameela Rani Garnepudi <[email protected]> >>>> Signed-off-by: Siva Rebbagondla <[email protected]> >>>> Signed-off-by: Amitkumar Karwar <[email protected]> >>> >>> [...] >>> >>>> @@ -270,6 +271,7 @@ struct rsi_common { >>>> u8 obm_ant_sel_val; >>>> int tx_power; >>>> u8 ant_in_use; >>>> + struct semaphore tx_bus_lock; >>> >>> Do you really need to use semaphore? I think nowadays the preference is >>> to use something other than semaphores. >> >> We used semaphore here, as USB/SDIO bus write operations could be >> blocking/waiting. I will check if spinlock suits here in follow up >> patch. It will need some testing. > > I was more thinking about using a mutex.
Right. mutex would be better option. I will submit updated version with this change Regards, Amitkumar Karwar
