[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250227144936.4wrvydm4i4oenszf@thinkpad>
Date: Thu, 27 Feb 2025 20:19:36 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Manivannan Sadhasivam <manisadhasivam.linux@...il.com>,
Manish Pandey <quic_mapa@...cinc.com>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-arm-msm@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, quic_nitirawa@...cinc.com
Subject: Re: [PATCH 0/3] scsi: ufs-qcom: Enable Dumping of Hibern8, MCQ, and
Testbus Registers
On Wed, Feb 26, 2025 at 10:40:51AM -0800, Bart Van Assche wrote:
> On 2/25/25 9:30 PM, Manivannan Sadhasivam wrote:
> > 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?
>
> Does this mean that printk() is the best alternative we have available?
>
For storage, yes unfortunately.
- Mani
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists