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

From: Jarkko Sakkinen

Date: Mon Oct 05 2026 - 02:05:37 EST


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@xxxxxxxxxx>
> >> ---
> >> 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.

Br, Jarkko