RE: [PATCH] scsi: ufs: core: Add a vop to handle vendor specific ops
From: Fang Hongjie(方洪杰)
Date: Fri Mar 20 2026 - 23:36:14 EST
> On 3/19/26 2:38 AM, Hongjie Fang wrote:
> > add a vop to allow some vendors to do some additional ops
> > for some interrupts if necessary.
>
> UFS patches should be sent to Martin K. Petersen and should be Cc-ed to
> the linux-scsi mailing list. Additionally, a patch description should
> not only explain what has been changed but also why a change is being
> mode. "to do some additional ops for some interrupts if necessary" is
> too vague.
Given that some UFS controllers have private or extended interrupt status
registers, the purpose of this patch is to facilitate the handling of
proprietary registers within the host driver during the interrupt handling.
>
> > @@ -7141,6 +7141,8 @@ static irqreturn_t ufshcd_sl_intr(struct ufs_hba
> *hba, u32 intr_status)
> > {
> > irqreturn_t retval = IRQ_NONE;
> >
> > + ufshcd_vops_vendor_intr(hba);
> Why to call this code from inside ufshcd_sl_intr() instead of from the
> ufshcd_sl_intr() caller?
It is called within `ufshcd_sl_intr()` to support running vendor ops in
the `ufshcd_threaded_intr()`.
>
> > @@ -380,6 +381,7 @@ struct ufs_hba_variant_ops {
> > int (*config_esi)(struct ufs_hba *hba);
> > void (*config_scsi_dev)(struct scsi_device *sdev);
> > u32 (*freq_to_gear_speed)(struct ufs_hba *hba, unsigned long
> freq);
> > + void (*vendor_intr)(struct ufs_hba *hba);
> > };
>
> Where is the implementation of .vendor_intr? I don't see any
> implementation of that new callback in this patch. Please always submit
> at least one implementation of a new vendor operation together with the
> patch that adds the new vendor operation.
The idea here is to first enable the ability to run vendor operations within
interrupt handlers, making it easier to add the vendor specific
implementations later.
>
> Thanks,
>
> Bart.
Best.