On Mon, Jun 17, 2024 at 02:07:45PM -0700, Bart Van Assche wrote:
> The ufshcd_poll() implementation does not support queue_num ==
> UFSHCD_POLL_FROM_INTERRUPT_CONTEXT in MCQ mode. Hence complain
> if queue_num == UFSHCD_POLL_FROM_INTERRUPT_CONTEXT in MCQ mode.
>
> Signed-off-by: Bart Van Assche <bvanassche@xxxxxxx>
> ---
> drivers/ufs/core/ufshcd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 7761ccca2115..db374a788140 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -5562,6 +5562,7 @@ static int ufshcd_poll(struct Scsi_Host *shost, unsigned int queue_num)
> struct ufs_hw_queue *hwq;
>
> if (is_mcq_enabled(hba)) {
> + WARN_ON_ONCE(queue_num == UFSHCD_POLL_FROM_INTERRUPT_CONTEXT);
So what does the user has to do if this WARN_ON gets triggered? Can't we use
dev_err()/dev_warn() and return instead if the intention is to just report the
error or warning.
I know that UFS code has WARN_ON sprinkled all over, but those should be audited
at some point and also the new additions.
Also, this is a bug fix as it essentially fixes array out of the bounds issue.
So should have a fixes tag and CC stable list for backporting.
- Mani
> hwq = &hba->uhq[queue_num];
>
> return ufshcd_mcq_poll_cqe_lock(hba, hwq);
--
மணிவண்ணன் சதாசிவம்
