All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlo Szelinsky <github@szelinsky.de>
To: netdev-bot+sashiko@kernel.org
Cc: o.rempel@pengutronix.de, kory.maincent@bootlin.com,
	andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
	kuba@kernel.org, pabeni@redhat.com, broonie@kernel.org,
	lgirdwood@gmail.com, corey@leavitt.info, kyle.swenson@est.tech,
	horms@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, sashiko-reviews@lists.linux.dev
Subject: Re: [PATCH net-next 2/4] net: pse-pd: unwind allocations when controller registration fails
Date: Mon, 19 Oct 2026 21:56:09 +0200	[thread overview]
Message-ID: <20261019195609.307868-1-github@szelinsky.de> (raw)
In-Reply-To: <179239893785.3135.13786246432250454158@kernel.org>

On Mon, 19 Oct 2026 08:35:37 +0000, netdev-bot+sashiko@kernel.org wrote:
> [Severity: Medium]
> Do these goto free_kfifo paths leak the OF node references held in
> pcdev->pi[]?

Yes, and the commit message is wrong about that. The regulator core
takes its own reference on the PI node, so I will drop the references
on these paths and keep only the array. That goes into the next
version, in net.

> [Severity: Medium]
> This recheck covers pse_pi_update_pw_budget() itself. Doesn't
> pse_ethtool_set_pw_limit() still read pw_d and the PI state without
> pcdev->lock before it calls this function?

Yes. That is fixed in net by "net: pse-pd: check the PI state under
the lock when setting a power limit".

> [Severity: Low]
> Should this patch carry a Fixes: tag

Yes. The patch moves to net, where it gets Fixes tags.

> [Severity: High]
> This is a pre-existing issue, but it sits next to this teardown code.
> devm_pse_alloc_pw_d() still allocates the power domain against the
> controller that creates it

Older bug, fixed in net by "net: pse-pd: do not tie a shared power
domain to its creator's devres".

> [Severity: High]
> This is a pre-existing issue, but does the normal unregister path follow
> the rule in this comment?

No, an older bug. The PI regulator part is fixed by the second patch
of [1], which I will rework and fold into the net series. Ethtool
callers that still hold a handle are fixed by the PSE notifier series.

> [Severity: Medium]
> This is a pre-existing issue, but none of the error paths after a
> successful setup_pi_matrix() undo what the driver did in that callback.

Only pd692x0 leaves something behind there: its power budget. That is
fixed in net by "net: pse-pd: pd692x0: release the manager power
budget through devres". The other drivers only read the device tree
and write registers there, so nothing is left to undo.

[1] https://lore.kernel.org/netdev/20260813200653.980170-1-github@szelinsky.de/

Carlo

  reply	other threads:[~2026-10-19 19:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-18  8:18 [PATCH net-next 0/4] net: pse-pd: core fixes ahead of the controller notifier Carlo Szelinsky
2026-10-18  8:18 ` [PATCH net-next 1/4] net: pse-pd: unlink the controller before freeing its PI data Carlo Szelinsky
2026-10-19  8:35   ` netdev-bot+sashiko
2026-10-19 19:56     ` Carlo Szelinsky
2026-10-18  8:18 ` [PATCH net-next 2/4] net: pse-pd: unwind allocations when controller registration fails Carlo Szelinsky
2026-10-19  8:35   ` netdev-bot+sashiko
2026-10-19 19:56     ` Carlo Szelinsky [this message]
2026-10-18  8:18 ` [PATCH net-next 3/4] net: pse-pd: si3474: use dev_err_probe() for controller registration Carlo Szelinsky
2026-10-18  8:18 ` [PATCH net-next 4/4] net: pse-pd: check the PI vpwr supply before registering the controller Carlo Szelinsky
2026-10-19  8:35   ` netdev-bot+sashiko
2026-10-19 19:56     ` Carlo Szelinsky
2026-10-18  8:23 ` [PATCH net-next 0/4] net: pse-pd: core fixes ahead of the controller notifier netdev-bot+sinfo
2026-10-19 19:56   ` Carlo Szelinsky
2026-10-19 12:54 ` Kory Maincent
2026-10-19 19:55   ` Carlo Szelinsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261019195609.307868-1-github@szelinsky.de \
    --to=github@szelinsky.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=corey@leavitt.info \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=kyle.swenson@est.tech \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev-bot+sashiko@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.