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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 9 Aug 2021 09:08:56 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Kiwoong Kim <kwmad.kim@...sung.com>, 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
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.