linux-kernel - RE: [RFC PATCH v1 0/2] scsi: ufs: introduce vendor isr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <064a01d79004$77f087c0$67d19740$@samsung.com>
Date:   Fri, 13 Aug 2021 14:31:29 +0900
From:   "Kiwoong Kim" <kwmad.kim@...sung.com>
To:     "'Bart Van Assche'" <bvanassche@....org>,
        <linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <alim.akhtar@...sung.com>, <avri.altman@....com>,
        <jejb@...ux.ibm.com>, <martin.petersen@...cle.com>,
        <beanhuo@...ron.com>, <cang@...eaurora.org>,
        <adrian.hunter@...el.com>, <sc.suh@...sung.com>,
        <hy50.seo@...sung.com>, <sh425.lee@...sung.com>,
        <bhoon95.kim@...sung.com>
Subject: RE: [RFC PATCH v1 0/2] scsi: ufs: introduce vendor isr

> On 8/9/21 12:46 AM, Kiwoong Kim wrote:
> >> How about extending the UFS spec instead of adding a non-standard
> >> mechanism in a driver that is otherwise based on a standard?
> >
> > It seems to be a great approach but I wonder if extending for the
> > events that all the SoC vendors require in the spec is recommendable.
> > Because I think there is quite possible that many of those things are
> > originated for architectural reasons.
> 
> Has the interrupt mechanism supported by this patch series already been
> implemented or is it still possible to change the ASIC design? In the
The former case. It has been included since mass production of the first SoC
supporting UFS for the first time.

> latter case, I propose the following:
> * Drop the new interrupt.
> * Instead of raising an interrupt if the UFS controller detects an
> inconsistency, report this via a check condition code, e.g. LOGICAL UNIT
> NOT READY, HARD RESET REQUIRED (there may be a better choice).
> 
> The above approach has the advantage that it does not slow down the UFS
> interrupt handler.
> 
> Thanks,
> 
> Bart.
>