Re: [PATCH] media: rtl28xxu: fix SDR platform device leak

[Krzysztof Kozlowski]

On 21/09/2026 17:17, krzk@xxxxxxxxxx wrote:
> 
> On Mon, 21 Sep 2026 16:15:42 +0800, Guangshuo Li wrote:
>> rtl2832u_tuner_attach() registers an rtl2832_sdr platform device, but
>> if registration succeeds without a bound driver, it breaks out without
>> unregistering the device.
>>
>> dev->platform_device_sdr is assigned only after a driver is bound, so
>> rtl28xxu_tuner_detach() cannot unregister the unbound device later.
>> This leaves the registered platform device and its associated resources
>> allocated.
>>
>> Split the registration failure and driver binding checks. Unregister
>> the successfully registered platform device when no driver is bound
>> before leaving the switch.
>>
>> The issue was identified by a static analysis tool I developed and
>> confirmed by manual review.
>>
>> Fixes: a2f7f220df5e ("[media] rtl28xxu: switch SDR module to platform driver")
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Guangshuo Li <lgs201920130244@xxxxxxxxx>
>> ---
>>  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 6 +++++-
>>  1 file changed, 5 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