From: sashiko-bot@kernel.org
To: "Ali Rouhi" <arouhi@sitime.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH net-next v11 13/13] dpll: sit9531x: model the inter-PLL sync net as a pair of pins
Date: Fri, 02 Oct 2026 09:14:21 +0000 [thread overview]
Message-ID: <20261002091422.10AA51F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930233714.87679-14-arouhi@sitime.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dpll/sit9531x: partial INTSYNC enable state prevents retry from succeeding
--
commit 04b8069f0eb6eee7c1faf966517e2a726ccd2acc
Author: Oleg Zadorozhnyi <Oleg.Zadorozhnyi@devoxsoftware.com>
dpll: sit9531x: model the inter-PLL sync net as a pair of pins
The device has an internal net by which one PLL can drive the others: the
source PLL puts its output on it, and any other PLL can select it as a
reference instead of an external input. The two ends are nothing alike --
one is driven, the other is selected -- so they are two pins rather than
one: an output pin on the source and an input pin on each destination.
That keeps each pin honest about what its state means. The source pin
reports whether this PLL is the one driving the net, and setting it takes
the net over or gives it up; a destination pin reports whether its PLL has
selected the net, and behaves like any other selectable input. A single
pin would have had to answer both questions at once and could only have
been right about one of them.
> diff --git a/drivers/dpll/sit9531x/core.c b/drivers/dpll/sit9531x/core.c
> index 45baa703aa45b..6b607f3d5fc31 100644
> --- a/drivers/dpll/sit9531x/core.c
> +++ b/drivers/dpll/sit9531x/core.c
[ ... ]
> + } else if (n_en && n_dis &&
> + n_en + n_dis == ARRAY_SIZE(intsync_config) &&
> + partial < 0) {
> + /*
> + * Every register holds one of the two patterns and both
> + * occur: the residue of an enable or a disable that
> + * stopped part way, and nothing a profile writes.
> + */
> + partial = pll;
> + }
> + }
> +
> + /*
> + * A disable that stopped part way leaves a PLL holding a mix of the
> + * two patterns. Treat it as the owner, so that a repeated disconnect
> + * on that PLL runs the disable again and another PLL cannot be
> + * enabled on top of the leftover configuration.
> + */
> + if (src < 0 && partial >= 0) {
> + dev_warn(sitdev->dev,
> + "PLL%c holds a partial INTSYNC source configuration\n",
> + 'A' + partial);
> + src = partial;
> + }
> +
> + sitdev->intsync_src = src;
[Severity: Medium]
Could caching the partially-configured PLL as the active owner of the
INTSYNC net cause issues during a retry?
> +
> + return 0;
> +}
[ ... ]
> diff --git a/drivers/dpll/sit9531x/dpll.c b/drivers/dpll/sit9531x/dpll.c
> index 6bf4efd3c6334..52d5b1a6e36f7 100644
> --- a/drivers/dpll/sit9531x/dpll.c
> +++ b/drivers/dpll/sit9531x/dpll.c
[ ... ]
> +static int
> +sit9531x_dpll_intsync_src_state_on_dpll_set(const struct dpll_pin *pin,
> + void *pin_priv,
> + const struct dpll_device *dpll,
> + void *dpll_priv,
> + enum dpll_pin_state state,
> + struct netlink_ext_ack *extack)
> +{
> + struct sit9531x_dpll *sitdpll = dpll_priv;
> + struct sit9531x_dev *sitdev = sitdpll->dev;
> + int rc = 0, detect_rc = 0;
> + bool changed = false;
> + u8 hw_src;
> +
> + mutex_lock(&sitdev->multiop_lock);
> +
> + switch (state) {
> + case DPLL_PIN_STATE_CONNECTED:
> + if (sitdev->intsync_src == sitdpll->id)
> + break;
[Severity: Medium]
Does this short-circuit condition prevent repairing the partially-configured
hardware?
If a transient bus error during sit9531x_intsync_enable() triggers a rollback
via sit9531x_intsync_disable(), and the rollback also fails, the
INTSYNC_GLOBAL bit is restored and the hardware is left partially configured.
The subsequent call to sit9531x_intsync_src_detect() then caches this PLL as
the net owner (sitdev->intsync_src = partial) as noted above.
When userspace retries the failed connect request, it seems this check in
sit9531x_dpll_intsync_src_state_on_dpll_set() might erroneously assume the
PLL is already fully enabled based on the cached partial state, returning
success without actually repairing the hardware.
> + if (sitdev->intsync_src >= 0) {
> + NL_SET_ERR_MSG(extack,
> + "INTSYNC is already sourced by another PLL");
> + rc = -EBUSY;
> + break;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930233714.87679-1-arouhi@sitime.com?part=13
next prev parent reply other threads:[~2026-10-02 9:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 23:37 [PATCH net-next v11 00/13] dpll: add SiTime SiT9531x DPLL clock driver Ali Rouhi
2026-09-30 23:37 ` [PATCH net-next v11 01/13] dt-bindings: dpll: allow hex unit addresses on output pins Ali Rouhi
2026-10-02 8:32 ` Krzysztof Kozlowski
2026-09-30 23:37 ` [PATCH net-next v11 02/13] dt-bindings: vendor-prefixes: add SiTime Corporation Ali Rouhi
2026-09-30 23:37 ` [PATCH net-next v11 03/13] dt-bindings: dpll: add SiTime SiT95316 clock generator Ali Rouhi
2026-10-05 1:09 ` netdev-bot+sashiko
2026-10-06 3:22 ` Rob Herring (Arm)
2026-09-30 23:37 ` [PATCH net-next v11 05/13] dpll: sit9531x: read DPLL types and pin properties from system firmware Ali Rouhi
2026-10-05 1:09 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 04/13] dpll: add basic SiTime SiT9531x support Ali Rouhi
2026-10-05 1:09 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 06/13] dpll: sit9531x: register DPLL devices and pins Ali Rouhi
2026-10-05 1:09 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 07/13] dpll: sit9531x: implement input pin state on a DPLL Ali Rouhi
2026-10-05 1:10 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 08/13] dpll: sit9531x: add support to get and set priority on input pins Ali Rouhi
2026-10-05 1:10 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 09/13] dpll: sit9531x: add support to get and set frequency on pins Ali Rouhi
2026-10-05 1:10 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 10/13] dpll: sit9531x: implement output pin state on a DPLL Ali Rouhi
2026-10-05 1:10 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 12/13] dpll: sit9531x: add support to get phase offset on the connected input pin Ali Rouhi
2026-10-05 1:10 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 11/13] dpll: sit9531x: add support to adjust output phase Ali Rouhi
2026-10-05 1:10 ` netdev-bot+sashiko
2026-09-30 23:37 ` [PATCH net-next v11 13/13] dpll: sit9531x: model the inter-PLL sync net as a pair of pins Ali Rouhi
2026-10-02 9:14 ` sashiko-bot [this message]
2026-10-05 1:10 ` netdev-bot+sashiko
2026-10-07 2:10 ` [PATCH net-next v11 00/13] dpll: add SiTime SiT9531x DPLL clock driver patchwork-bot+netdevbpf
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=20261002091422.10AA51F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=arouhi@sitime.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox