On 7/29/22 16:19, Takashi Iwai wrote: Thanks for your time.
[CAUTION: External Email] On Fri, 29 Jul 2022 12:34:51 +0200, Venkata Prasad Potturu wrote:On 7/28/22 18:19, Mark Brown wrote: Thanks for your time. On Thu, Jul 28, 2022 at 06:10:50PM +0530, Venkata Prasad Potturu wrote: @@ -104,14 +105,13 @@ static irqreturn_t i2s_irq_handler(int irq, void *data) ext_intr_stat = readl(ACP_EXTERNAL_INTR_STAT(adata, rsrc->irqp_used)); - for (i = 0; i < ACP_MAX_STREAM; i++) { - stream = adata->stream[i]; + spin_lock_irqsave(&adata->acp_lock, flags); + list_for_each_entry(stream, &adata->stream_list, list) { If we're already in an interrupt handler here (presumably not a threaded one) why are we using irqsave? Yes, your statement make sense, I have followed below statement in kernel document. so used irqsave in interrupt context as well. We will change it to spin_lock() and send it in the next version. statement:- spin_lock_irqsave() will turn off interrupts if they are on, otherwise does nothing (if we are already in an interrupt handler), hence these functions are safe to call from any context.Also the open and close callbacks are certainly non-irq context, hence you can use spin_lock_irq() instead of irqsave(), too.
Okay. Thanks for your suggestion. We will use accordingly.
Takashi
