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

Nicolas Frattaroli nicolas.frattaroli at collabora.com
Wed Feb 25 05:05:55 PST 2026


On Tuesday, 24 February 2026 13:47:28 Central European Standard Time Peter Wang (王信友) wrote:
> On Mon, 2026-02-16 at 14:37 +0100, Nicolas Frattaroli wrote:
> >  drivers/ufs/host/ufs-mediatek.c | 99 ++++++++++++++++++-------------
> > ----------
> >  1 file changed, 43 insertions(+), 56 deletions(-)
> > 
> > diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-
> > mediatek.c
> > index ecf16e82a326..2b1f26b55782 100644
> > --- a/drivers/ufs/host/ufs-mediatek.c
> > +++ b/drivers/ufs/host/ufs-mediatek.c
> > [... snip ...]
> > @@ -810,11 +806,11 @@ static void ufs_mtk_mcq_set_irq_affinity(struct
> > ufs_hba *hba, unsigned int cpu)
> >  	_cpu = (cpu == 0) ? 3 : cpu;
> >  	ret = irq_set_affinity(irq, cpumask_of(_cpu));
> >  	if (ret) {
> > -		dev_err(hba->dev, "set irq %d affinity to CPU %d
> > failed\n",
> > +		dev_err(hba->dev, "setting irq %d affinity to CPU %d
> > failed\n",
> >  			irq, _cpu);
> >  		return;
> >  	}
> > -	dev_info(hba->dev, "set irq %d affinity to CPU: %d\n", irq,
> > _cpu);
> > +	dev_dbg(hba->dev, "set irq %d affinity to CPU %d\n", irq,
> > _cpu);
> > 
> 
> Is it more appropriate to use dev_info for state changes or for setting
> changes?

Is this information a user would want to see in their bootup log in
every case? My understanding right now is no.

> > [... snip ...]
> > @@ -1571,7 +1559,7 @@ static int ufs_mtk_device_reset(struct ufs_hba
> > *hba)
> >  	/* Some devices may need time to respond to rst_n */
> >  	usleep_range(10000, 15000);
> >  
> > -	dev_info(hba->dev, "device reset done\n");
> > +	dev_dbg(hba->dev, "device reset done\n");
> >  
> 
> Is it more appropriate to use dev_info for state changes or for setting
> changes?

Depends on your view of what's useful information for the user.

I can change both of these back to _info if I have to send out a next
revision, just to get this through though.

> 
> Thanks
> Peter
> 







More information about the linux-arm-kernel mailing list