[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <32cc37cd-2f66-0f74-5242-cfcf86f58844@acm.org>
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.
Powered by blists - more mailing lists