mbox series

[0/3] scsi: ufs-qcom: Enable Dumping of Hibern8, MCQ, and Testbus Registers

Message ID 20241025055054.23170-1-quic_mapa@quicinc.com (mailing list archive)
Headers show
Series scsi: ufs-qcom: Enable Dumping of Hibern8, MCQ, and Testbus Registers | expand

Message

Manish Pandey Oct. 25, 2024, 5:50 a.m. UTC
Submitting a series of patches aimed at enhancing the debugging and monitoring capabilities
of the UFS-QCOM driver. These patches introduce new functionalities that will significantly
aid in diagnosing and resolving issues related to hardware and software operations.

Manish Pandey (3):
  scsi: ufs-qcom: Add support for dumping HW and SW hibern8 count
  scsi: ufs-qcom: Add support for dumping MCQ registers
  scsi: ufs-qcom: Add support for testbus registers

 drivers/ufs/host/ufs-qcom.c | 141 ++++++++++++++++++++++++++++++++++++
 drivers/ufs/host/ufs-qcom.h |  11 +++
 2 files changed, 152 insertions(+)

Comments

Manivannan Sadhasivam Nov. 12, 2024, 7:50 a.m. UTC | #1
On Fri, Oct 25, 2024 at 11:20:51AM +0530, Manish Pandey wrote:
> Submitting a series of patches aimed at enhancing the debugging and monitoring capabilities
> of the UFS-QCOM driver. These patches introduce new functionalities that will significantly
> aid in diagnosing and resolving issues related to hardware and software operations.
> 

TBH, the current state of dumping UFSHC registers itself is just annoying as it
pollutes the kernel ring buffer. I don't think any peripheral driver in the
kernel does this. Please dump only relevant registers, not everything that you
feel like dumping.

- Mani

> Manish Pandey (3):
>   scsi: ufs-qcom: Add support for dumping HW and SW hibern8 count
>   scsi: ufs-qcom: Add support for dumping MCQ registers
>   scsi: ufs-qcom: Add support for testbus registers
> 
>  drivers/ufs/host/ufs-qcom.c | 141 ++++++++++++++++++++++++++++++++++++
>  drivers/ufs/host/ufs-qcom.h |  11 +++
>  2 files changed, 152 insertions(+)
> 
> -- 
> 2.17.1
> 
>
Bart Van Assche Nov. 12, 2024, 6:10 p.m. UTC | #2
On 11/11/24 11:50 PM, Manivannan Sadhasivam wrote:
> On Fri, Oct 25, 2024 at 11:20:51AM +0530, Manish Pandey wrote:
>> Submitting a series of patches aimed at enhancing the debugging and monitoring capabilities
>> of the UFS-QCOM driver. These patches introduce new functionalities that will significantly
>> aid in diagnosing and resolving issues related to hardware and software operations.
>>
> 
> TBH, the current state of dumping UFSHC registers itself is just annoying as it
> pollutes the kernel ring buffer. I don't think any peripheral driver in the
> kernel does this. Please dump only relevant registers, not everything that you
> feel like dumping.

I wouldn't mind if the code for dumping  UFSHC registers would be removed.

Thanks,

Bart.
manivannan.sadhasivam@linaro.org Dec. 9, 2024, 4:03 a.m. UTC | #3
On Tue, Nov 12, 2024 at 10:10:02AM -0800, Bart Van Assche wrote:
> On 11/11/24 11:50 PM, Manivannan Sadhasivam wrote:
> > On Fri, Oct 25, 2024 at 11:20:51AM +0530, Manish Pandey wrote:
> > > Submitting a series of patches aimed at enhancing the debugging and monitoring capabilities
> > > of the UFS-QCOM driver. These patches introduce new functionalities that will significantly
> > > aid in diagnosing and resolving issues related to hardware and software operations.
> > > 
> > 
> > TBH, the current state of dumping UFSHC registers itself is just annoying as it
> > pollutes the kernel ring buffer. I don't think any peripheral driver in the
> > kernel does this. Please dump only relevant registers, not everything that you
> > feel like dumping.
> 
> I wouldn't mind if the code for dumping  UFSHC registers would be removed.
> 

Instead of removing, I'm planning to move the dump to dev_coredump framework.
But should we move all the error prints also? Like all ufshcd_print_*()
functions?

- Mani
Bart Van Assche Dec. 9, 2024, 6:35 p.m. UTC | #4
On 12/8/24 12:03 PM, Manivannan Sadhasivam wrote:
> On Tue, Nov 12, 2024 at 10:10:02AM -0800, Bart Van Assche wrote:
>> On 11/11/24 11:50 PM, Manivannan Sadhasivam wrote:
>>> On Fri, Oct 25, 2024 at 11:20:51AM +0530, Manish Pandey wrote:
>>>> Submitting a series of patches aimed at enhancing the debugging and monitoring capabilities
>>>> of the UFS-QCOM driver. These patches introduce new functionalities that will significantly
>>>> aid in diagnosing and resolving issues related to hardware and software operations.
>>>>
>>>
>>> TBH, the current state of dumping UFSHC registers itself is just annoying as it
>>> pollutes the kernel ring buffer. I don't think any peripheral driver in the
>>> kernel does this. Please dump only relevant registers, not everything that you
>>> feel like dumping.
>>
>> I wouldn't mind if the code for dumping  UFSHC registers would be removed.
> 
> Instead of removing, I'm planning to move the dump to dev_coredump framework.
> But should we move all the error prints also? Like all ufshcd_print_*()
> functions?

Hmm ... we may be better off to check which of these functions can be 
removed rather than moving all of them to another framework.

Thanks,

Bart.
manivannan.sadhasivam@linaro.org Dec. 10, 2024, 6:14 a.m. UTC | #5
On Mon, Dec 09, 2024 at 10:35:39AM -0800, Bart Van Assche wrote:
> On 12/8/24 12:03 PM, Manivannan Sadhasivam wrote:
> > On Tue, Nov 12, 2024 at 10:10:02AM -0800, Bart Van Assche wrote:
> > > On 11/11/24 11:50 PM, Manivannan Sadhasivam wrote:
> > > > On Fri, Oct 25, 2024 at 11:20:51AM +0530, Manish Pandey wrote:
> > > > > Submitting a series of patches aimed at enhancing the debugging and monitoring capabilities
> > > > > of the UFS-QCOM driver. These patches introduce new functionalities that will significantly
> > > > > aid in diagnosing and resolving issues related to hardware and software operations.
> > > > > 
> > > > 
> > > > TBH, the current state of dumping UFSHC registers itself is just annoying as it
> > > > pollutes the kernel ring buffer. I don't think any peripheral driver in the
> > > > kernel does this. Please dump only relevant registers, not everything that you
> > > > feel like dumping.
> > > 
> > > I wouldn't mind if the code for dumping  UFSHC registers would be removed.
> > 
> > Instead of removing, I'm planning to move the dump to dev_coredump framework.
> > But should we move all the error prints also? Like all ufshcd_print_*()
> > functions?
> 
> Hmm ... we may be better off to check which of these functions can be
> removed rather than moving all of them to another framework.
> 

They are mostly for debugging the errors. I don't see why we should completely
get rid of them. Moving to devcoredump allows debugging the errors in a
standardized way and also prevents spamming the kernel ring buffer.

- Mani