Re: [PATCH 5/5] tpm: fix log messages in tpm_init()

[Jarkko Sakkinen <jarkko@kernel.org>]

On Mon, Oct 05, 2026 at 09:05:25AM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 05, 2026 at 12:23:31PM +0800, Pei Xiao wrote:
> > 
> > 
> > 在 2026/10/5 11:46, Jarkko Sakkinen 写道:
> > > On Sat, Oct 03, 2026 at 04:27:55PM +0800, Pei Xiao wrote:
> > >> Make the error messages consistently prefixed with "tpm: ", and fix
> > >> the tpm_dev_common_init() failure message which was wrongly copied
> > >> from the previous step.
> > >>
> > >> Assisted-by: GLM-5.3
> > >> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
> > >> ---
> > >>  drivers/char/tpm/tpm-interface.c | 6 +++---
> > >>  1 file changed, 3 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
> > >> index 1ccdbde98b69..666a1c654c02 100644
> > >> --- a/drivers/char/tpm/tpm-interface.c
> > >> +++ b/drivers/char/tpm/tpm-interface.c
> > >> @@ -524,13 +524,13 @@ static int __init tpm_init(void)
> > >>  
> > >>  	rc = class_register(&tpm_class);
> > >>  	if (rc) {
> > >> -		pr_err("couldn't create tpm class\n");
> > >> +		pr_err("tpm: couldn't create tpm class\n");
> > >>  		return rc;
> > >>  	}
> > >>  
> > >>  	rc = class_register(&tpmrm_class);
> > >>  	if (rc) {
> > >> -		pr_err("couldn't create tpmrm class\n");
> > >> +		pr_err("tpm: couldn't create tpmrm class\n");
> > >>  		goto out_destroy_tpm_class;
> > >>  	}
> > >>  
> > >> @@ -542,7 +542,7 @@ static int __init tpm_init(void)
> > >>  
> > >>  	rc = tpm_dev_common_init();
> > >>  	if (rc) {
> > >> -		pr_err("tpm: failed to allocate char dev region\n");
> > >> +		pr_err("tpm: failed to allocate TPM workqueue\n");
> > >>  		goto out_unreg_chrdev;
> > >>  	}
> > >>  
> > >> -- 
> > >> 2.25.1
> > >>
> > > 
> > > I NAK this one. It is not fixing anything.
> > Hmm, this is a cleanup, not a fix—just a very minor change to an error
> > log/print. I noticed it was duplicated (with the alloc_chrdev_region
> > error print), which made it impossible to tell which function call had
> > failed (it might actually never be executed). So I just brought up this
> > cleanup along the way.
> 
> If there is patch that is coming along the way, it is patch that should
> not be sent because:
> 
> 1. It wastes also everyone else's time.
> 2. Lack of understanding of cause and effect because by definition
>    you have no idea what you are submitting. E
> 
> Pure clean ups per se are already something that is usually best to NAK
> but this patch is not a clean up.
> 
> I mean the path is doing arbitrary log message changes. That is not
> harmless change as you enforce your arbitrary preferences also for few
> billion other users. 

Well, maybe just machines but anyhow :-)

Br, Jarkko