Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CGME20210913081148epcas2p21c23ca6a745f40083ee7d6e7da4d7c00@epcas2p2.samsung.com>
 <cover.1631519695.git.kwmad.kim@samsung.com> <fbdd02bc-01ab-c5b3-9355-3ebe04601b04@acm.org>
In-Reply-To: <fbdd02bc-01ab-c5b3-9355-3ebe04601b04@acm.org>
From:   Alim Akhtar <alim.akhtar@gmail.com>
Date:   Mon, 13 Sep 2021 22:56:48 +0530
Message-ID: <CAGOxZ51X-ThsqV35PiTh-awRvAkQ=Fjf9m+KRd1HLZ+pDNi=Xg@mail.gmail.com>
Subject: Re: [PATCH v2 0/3] scsi: ufs: introduce vendor isr
To:     Bart Van Assche <bvanassche@acm.org>
Cc:     Kiwoong Kim <kwmad.kim@samsung.com>, linux-scsi@vger.kernel.org,
        open list <linux-kernel@vger.kernel.org>,
        Alim Akhtar <alim.akhtar@samsung.com>,
        Avri Altman <avri.altman@wdc.com>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        "Bean Huo (beanhuo)" <beanhuo@micron.com>,
        Can Guo <cang@codeaurora.org>,
        Adrian Hunter <adrian.hunter@intel.com>, sc.suh@samsung.com,
        hy50.seo@samsung.com, sh425.lee@samsung.com,
        bhoon95.kim@samsung.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.
>
>


-- 
Regards,
Alim