Re: [PATCH v2 1/2] net: ena: fix PHC cleanup on probe failure

From: Guangshuo Li

Date: Mon Sep 21 2026 - 22:13:18 EST


Hi Krzysztof,

Thank you for your feedback.

On Tue, 22 Sept 2026 at 06:02, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 21/09/2026 21:06, Arthur Kiyanovski wrote:
> > On Mon, 21 Sep 2026 23:42:01 +0800, Guangshuo Li <lgs201920130244@xxxxxxxxx> wrote:
> >> ena_probe() initializes the PHC as part of ena_device_init(), but the
> >> probe failure path does not destroy it before freeing the PHC private
> >> data.
> >>
> >> The normal removal path calls ena_phc_destroy() through
> >> ena_destroy_device() before ena_phc_free(). However, if probe fails
> >> after ena_device_init() succeeds, the error path reaches ena_phc_free()
> >
> > This part:
> >
> >> without unregistering the PTP clock or destroying the device PHC
> >> resources.
> >
> > is inaccurate, see my explanation bellow.
> >
>
> Don't waste your time. This is AI slop agent posting (one of 500 more of
> postings where agent does not care about replies).
>
> Best regards,
> Krzysztof

I would like to clarify that these patches were manually reviewed and
audited by us; they were not simply generated and submitted by an LLM.
However, I understand why the recent submission pattern may have given
that impression. We sent too many patches in a short period of time,
and we also failed to respond to some discussions in a timely manner,
which made the situation look worse.

Many of the recent patches, especially the v2 revisions, are
corrections and improvements based on previous review feedback rather
than completely new untested changes. That said, we recognize that the
way we submitted them increased the burden on maintainers and
reviewers.

We apologize for the pressure this caused to the community. We will be
more careful about organizing patches by subsystem, preparing proper
patchsets, and following the kernel contribution guidelines before
sending future work.

Thank you again for pointing this out.

Best regards,
Guangshuo