Re: [PATCH] scsi: ufs: core: Handle MCQ IAG events

[Bart Van Assche]

On 3/3/26 4:25 AM, Peter Wang (王信友) wrote:
> On Mon, 2026-03-02 at 23:31 +0530, vamshi gajjela wrote:
> > @@ -7141,7 +7149,10 @@ static irqreturn_t ufshcd_sl_intr(struct
> > ufs_hba *hba, u32 intr_status)
> >  retval |= ufshcd_transfer_req_compl(hba);
> >  
> >  if (intr_status & MCQ_CQ_EVENT_STATUS)
> > -retval |= ufshcd_handle_mcq_cq_events(hba);
> > +retval |= ufshcd_handle_mcq_cq_events(hba, false);
> > +
> > +if (intr_status & MCQ_IAG_EVENT_STATUS)
> > +retval |= ufshcd_handle_mcq_cq_events(hba, true);
>
> Hi Vamshi,
>
> This is strange to me.
> Why does receiving an IAG_EVENT call ufshcd_handle_mcq_cq_events?
> Shouldn't it be ufshcd_handle_mcq_iag_events instead?
Doesn't this follow from the UFSHCI standard? From the UFSHCI 5.0
standard: "MCQ Interrupt Aggregation Event Status (IAGES): This bit is
transparent and becomes ‘1’ when all of the following conditions are met
• Controller is operating in MCQ mode (Config.QT = 1)
• ESI is not enabled (Config.ESIE = 0)
• At least one interrupt aggregation group has triggered, which means it
has satisfied either counter or timer condition

When in MCQ mode, and ESI is not used, SW can use traditional interrupt 
approach. When this bit is set, interrupt routine needs to scan all
interrupt aggregation groups to determine which IAG has caused this
interrupt.

Thanks,

Bart.