Re: [PATCH] platform/x86/amd/hfi: fix platform device leak on init failure

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/09/2026 17:15, krzk@kernel.org wrote:
> 
> On Mon, 21 Sep 2026 16:26:09 +0800, Guangshuo Li wrote:
>> amd_hfi_init() registers the HFI platform device before registering
>> the platform driver. If platform_driver_register() fails, the function
>> returns the error without unregistering the already registered platform
>> device.
>>
>> Since the failed init path does not run amd_hfi_exit(), the platform
>> device remains registered and its reference is never dropped, preventing
>> the associated platform object from being released.
>>
>> Unregister the platform device when platform driver registration fails
>> to properly unwind the successful device registration.
>>
>> The issue was identified by a static analysis tool I developed and
>> confirmed by manual review.
>>
>> Fixes: 5d902ee5609a ("platform/x86: hfi: Introduce AMD Hardware Feedback Interface Driver")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
>> ---
>>  drivers/platform/x86/amd/hfi/hfi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
> 
> 
> You sent multiple independent patches, to multiple independent
> subsystems. The amount of these patches clearly suggest this was
> AI generated and most likely not tested.
> 
> More importantly, you sent all this work without properly organizing
> relevant patches into patchsets. This makes reviewing difficult
> and might cause multiple reviewers to address the same issue.
> Replying to the entire set is impossible and requires handling each
> patch independently, instead of applying or discarding the set.
> Maintainers also won't see the bigger picture of your work. Quite
> worrying.
> 
> This is on the verge of hostile patch: bomb us with so many
> contributions, we won't be able to handle them in efficient manner,
> like responding ONCE to ask you to slow down.  Considering all this
> is untested and LLM generated, I have even more doubts whether this
> should be considered for review.
> 
> Please read kernel documentation BEFORE posting more work. It will
> explain you how to identify subsystems, how to organize your work per
> subsystem, how to document usage of LLM and how what you should not
> do if this was posted in a good faith.


Apologies for spamming here, mistake on my side.

I guess the OpenClaw on the other side did not even notice...


Best regards,
Krzysztof