[RFC,v1,0/2] scsi: ufs: introduce vendor isr

Message

Kiwoong Kim Aug. 6, 2021, 6:34 a.m. UTC

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 (2):
  scsi: ufs: introduce vendor isr
  scsi: ufs: ufs-exynos: implement exynos isr

 drivers/scsi/ufs/ufs-exynos.c | 78 +++++++++++++++++++++++++++++------
 drivers/scsi/ufs/ufshcd.c     | 10 +++++
 drivers/scsi/ufs/ufshcd.h     |  8 ++++
 3 files changed, 84 insertions(+), 12 deletions(-)

Comments

Bart Van Assche Aug. 6, 2021, 4:14 p.m. UTC | #1

On 8/5/21 11:34 PM, 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.

How about extending the UFS spec instead of adding a non-standard 
mechanism in a driver that is otherwise based on a standard?

Thanks,

Bart.

Avri Altman Aug. 8, 2021, 5:56 a.m. UTC | #2

> 
> On 8/5/21 11:34 PM, 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.
> 
> How about extending the UFS spec instead of adding a non-standard
> mechanism in a driver that is otherwise based on a standard?
The variant ops IMO (which he rightfully used), should allow that extra freedom.

Thanks,
Avri

> 
> Thanks,
> 
> Bart.

Kiwoong Kim Aug. 9, 2021, 7:46 a.m. UTC | #3

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

Bart Van Assche Aug. 9, 2021, 4:08 p.m. UTC | #4

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.

Kiwoong Kim Aug. 13, 2021, 5:31 a.m. UTC | #5

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