Re: [PATCH v7 16/23] scsi: ufs: mediatek: Clean up logging prints

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Thu, 2026-02-26 at 11:45 +0100, AngeloGioacchino Del Regno wrote:
> Sorry Peter, but I'd argue that the users don't care about how much
> and when
> their UFS device resets. Users just want to use a device, without
> caring
> about any implementation detail.
> The spirit is: "radio silence as long as everything works good".
> 
> Power users might want to check the kernel log in a problematic
> scenario to
> seek for a message that says that "something went horribly wrong",
> but other
> than developers, nobody cares about when UFS resets.
> 
>  From a developer standpoint, I do agree with you in that we do *not*
> want to
> see device resets occurring repeatedly, but we're talking about a
> user here.
> 
> See it like this... imagine if all of the device drivers in the Linux
> kernel
> would say "device reset done": how many devices are present in one
> SoC (of
> course, ignoring subdevices on a board)?
> 
> Of all those many devices, if all of them would print a message
> saying that
> their reset is done (and operation is ok), the kernel log would get
> quite a
> bit clogged, you'd need to have a bigger RAM carveout just for ..
> well, the
> kernel log itself, and then you'd have to grep the log, hoping to
> find the
> one single line that helps you finding an issue that you're having.
> 
> This is the reason why keeping any message that is not exactly a
> *single*
> indication of an error (so, an actual issue) as a dev_dbg() is a
> sensible
> thing to do (and of course, with dynamic debug in the kernel, you can
> always
> activate that on-the-fly without recompiling to verify functionality
> should
> you have any immediate doubt).
> 
> So while I agree about your reasons, I very strongly disagree about
> having
> this message as a dev_info(), nor anything else that is not dev_dbg()
> really.
> 
> Regards,
> Angelo

Hi AngeloGioacchino,

I am not sure if you know that when UFS encounters an error,
such as a UIC error or timeout, some errors can be so severe
that they cannot be recovered without a reset. In these cases,
we need to perform error handling or recovery by resetting 
the device.

I agree that "radio silence is preferable as long as everything
works well." However, users may sometimes wonder why their 
device (phone, tablet, laptop, etc.) shows good IO performance 
in tests, but the actual user experience is poor (laggy).
This log can provide users with an explanation for IO lag
during usage.

I also agree that many devices are present in a single SoC, but
I don't think there is much reset information throughout the system.
Each device should ensure that the likelihood of a reset (error) 
is minimized.

Thanks.
Peter