Amitkumar Karwar <amitkarwar@xxxxxxxxx> writes:
> From: Prameela Rani Garnepudi <prameela.j04cs@xxxxxxxxx>
>
> Currently, RX packets are handled in interrupt context in SDIO
> interface. To improve the efficiency of processing RX packets,
> RX thread and RX skb queues are introduced.
> When the packet is read from device, driver prepares skb, add to
> RX queue and trigger RX thread event. RX thread processes the
> packets from RX queue.
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@xxxxxxxxx>
> Signed-off-by: Amitkumar Karwar <amit.karwar@xxxxxxxxxxxxxxxxxx>
[...]
> +void rsi_sdio_rx_thread(struct rsi_common *common)
> +{
> + struct rsi_hw *adapter = common->priv;
> + struct rsi_91x_sdiodev *sdev = adapter->rsi_dev;
> + struct sk_buff *skb;
> + int status;
> +
> + do {
> + rsi_wait_event(&sdev->rx_thread.event, EVENT_WAIT_FOREVER);
> + rsi_reset_event(&sdev->rx_thread.event);
I started to wonder what these rsi_wait_event() and rsi_reset_event()
are and indeed, at least to me, they look suspicious (creating own
kthread and use of atomics etc). Why reinvent the wheel and not use
standard kernel frameworks, like workqueue? Most of the time trying to
be too clever ends up just being buggy.
No need for any immeadiate action but something to keep in mind and
hopefully clean up later.
--
Kalle Valo
