Re: [PATCH 5/5] tpm: fix log messages in tpm_init()
From: Pei Xiao
Date: Mon Oct 05 2026 - 02:12:53 EST
在 2026/10/5 14:05, Jarkko Sakkinen 写道:
> 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.
OK, got it. Thanks.
>
> Br, Jarkko