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