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. > devcoredump turned out to be not a good fit for storage drivers. And I can't figure out another way. And Qcom is telling me that these debug prints are necessary for them to debug the issues going forward. Your thoughts? - Mani -- மணிவண்ணன் சதாசிவம்
