On Thu, Feb 1, 2018 at 12:26 PM, Kalle Valo <kv...@codeaurora.org> wrote:
> Amitkumar Karwar <amitkar...@gmail.com> writes:
>
>> From: Prameela Rani Garnepudi <prameela.j0...@gmail.com>
>>
>> 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 <prameela.j0...@gmail.com>
>> Signed-off-by: Siva Rebbagondla <siva.rebbagon...@redpinesignals.com>
>> Signed-off-by: Amitkumar Karwar <amit.kar...@redpinesignals.com>
>
> [...]
>
>> @@ -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.
> Also calling it tx_bus_lock is IMHO misleading, tx_bus_sema would be
> nicer.
Sure. I will rename the variable
Regards,
Amitkumar
