About reading UECxx in ufshcd_dump_regs

About reading UECxx in ufshcd_dump_regs

[Kiwoong Kim]

Dear all

I want to discuss about reading UECxx of UFS SFRs in ufshcd_dump_regs.

There are five SFRs - UECPA, UECDL, UECN, UECT and UECDME which are all ROC type that means they are cleared when reading them.
Originally, these SFRs are to let UFS driver know UIC error type which a UIC errors occurs.
Thus, when UFS driver reads them after clearing IS.UE, they are cleared.

I think the read values would be zero in many cases because of the flow I mentioned
And there might be some cases when ufshcd_dump_regs reads them before the ISR reads them.
e.g. when a command is timed out and ufshcd_dump_regs is called in ufshcd_abort.

So I want to ask this: how about removing reading UECxx in ufshcd_dump_regs?
I think reading them is meaningless and might be even a little bit risky.

Thanks.
Kiwoong Kim

RE: About reading UECxx in ufshcd_dump_regs

[Avri Altman]

> Dear all
> 
> I want to discuss about reading UECxx of UFS SFRs in ufshcd_dump_regs.
> 
> There are five SFRs - UECPA, UECDL, UECN, UECT and UECDME which are all
> ROC type that means they are cleared when reading them.
> Originally, these SFRs are to let UFS driver know UIC error type which a UIC
> errors occurs.
> Thus, when UFS driver reads them after clearing IS.UE, they are cleared.
> 
> I think the read values would be zero in many cases because of the flow I
> mentioned And there might be some cases when ufshcd_dump_regs reads them
> before the ISR reads them.
> e.g. when a command is timed out and ufshcd_dump_regs is called in
> ufshcd_abort.
> 
> So I want to ask this: how about removing reading UECxx in ufshcd_dump_regs?
> I think reading them is meaningless and might be even a little bit risky.
Maybe send an RFC patch to make the discussion concrete.

Thanks,
Avri

> 
> Thanks.
> Kiwoong Kim
>