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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a850d86-5974-4b2d-95be-e79dad33636f@acm.org>
Date: Mon, 9 Dec 2024 10:35:39 -0800
From: Bart Van Assche <bvanassche@....org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.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 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.