| Message ID | cover.1631519695.git.kwmad.kim@samsung.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | scsi: ufs: introduce vendor isr | expand |
On 9/13/21 12:55 AM, 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. > > Kiwoong Kim (3): > scsi: ufs: introduce vendor isr > scsi: ufs: introduce force requeue > scsi: ufs: ufs-exynos: implement exynos isr > > drivers/scsi/ufs/ufs-exynos.c | 84 ++++++++++++++++++++++++++++++++++++------- > drivers/scsi/ufs/ufshcd.c | 22 ++++++++++-- > drivers/scsi/ufs/ufshcd.h | 2 ++ > 3 files changed, 93 insertions(+), 15 deletions(-) The UFS protocol is standardized. Your employer has a representative in the UFS standardization committee. Please work with that representative to standardize this feature instead of adding non-standard extensions to the UFS driver. Thanks, Bart.
Hi Bart, On Mon, Sep 13, 2021 at 9:42 PM Bart Van Assche <bvanassche@acm.org> wrote: > > On 9/13/21 12:55 AM, 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. > > > > Kiwoong Kim (3): > > scsi: ufs: introduce vendor isr > > scsi: ufs: introduce force requeue > > scsi: ufs: ufs-exynos: implement exynos isr > > > > drivers/scsi/ufs/ufs-exynos.c | 84 ++++++++++++++++++++++++++++++++++++------- > > drivers/scsi/ufs/ufshcd.c | 22 ++++++++++-- > > drivers/scsi/ufs/ufshcd.h | 2 ++ > > 3 files changed, 93 insertions(+), 15 deletions(-) > > The UFS protocol is standardized. Your employer has a representative in the > UFS standardization committee. Please work with that representative to > standardize this feature instead of adding non-standard extensions to the UFS > driver. > Thanks for your input. Completely agree with you, in fact your suggestions make sense to me. As a driver developer, surely we can take these concerns to the IP designers and see how far we can get in terms of standardization. That, however, is not something that can be accomplished overnight. My main concern is, what about millions of devices which are already in the market? UFS subsystem does support _vops_ to handle vendor specific hooks/modifications. I am not saying we should always follow this path, but surely until these deviations are either fixed or become part of UFS standard itself, IMO. Thanks! > Thanks, > > Bart. > >
On 9/13/21 10:26, Alim Akhtar wrote: > Thanks for your input. Completely agree with you, in fact your > suggestions make sense to me. As a driver developer, surely we can > take these concerns to the IP designers and see how far we can get in > terms of standardization. That, however, is not something that can be > accomplished overnight. My main concern is, what about millions of > devices which are already in the market? UFS subsystem does support > _vops_ to handle vendor specific hooks/modifications. I am not saying > we should always follow this path, but surely until these deviations > are either fixed or become part of UFS standard itself, IMO. Hi Alim, If there are already millions of devices in the market that support this feature then that's an argument to proceed with this patch series. Thanks, Bart.