[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Aug 2021 05:56:11 +0000
From: Avri Altman <Avri.Altman@....com>
To: Bart Van Assche <bvanassche@....org>,
Kiwoong Kim <kwmad.kim@...sung.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"beanhuo@...ron.com" <beanhuo@...ron.com>,
"cang@...eaurora.org" <cang@...eaurora.org>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"sc.suh@...sung.com" <sc.suh@...sung.com>,
"hy50.seo@...sung.com" <hy50.seo@...sung.com>,
"sh425.lee@...sung.com" <sh425.lee@...sung.com>,
"bhoon95.kim@...sung.com" <bhoon95.kim@...sung.com>
Subject: RE: [RFC PATCH v1 0/2] scsi: ufs: introduce vendor isr
>
> On 8/5/21 11:34 PM, Kiwoong Kim wrote:
> > This patch is to activate some interrupt sources
> > that aren't defined in UFSHCI specifications. Those
> > purpose could be error handling, workaround or whatever.
>
> How about extending the UFS spec instead of adding a non-standard
> mechanism in a driver that is otherwise based on a standard?
The variant ops IMO (which he rightfully used), should allow that extra freedom.
Thanks,
Avri
>
> Thanks,
>
> Bart.
Powered by blists - more mailing lists