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. -- Kalle Valo
