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

[Bart Van Assche <bvanassche@acm.org>]

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?

Thanks,

Bart.