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

[Pei Xiao <xiaopei01@kylinos.cn>]

在 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@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. 
OK, got it. Thanks.
> 
> Br, Jarkko