All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Luo Liu" <Luo.Liu@cixtech.com>
Cc: devicetree@vger.kernel.org, linux-phy@lists.infradead.org,
	olteanv@gmail.com, vkoul@kernel.org, conor+dt@kernel.org,
	neil.armstrong@linaro.org, robh@kernel.org
Subject: Re: [PATCH 2/3] phy: cix: Add Sky1 DP PHY driver
Date: Mon, 12 Oct 2026 08:15:48 +0000	[thread overview]
Message-ID: <sashiko-outbox-167831@kernel.org> (raw)
In-Reply-To: <20261012080517.566920-3-Luo.Liu@cixtech.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: cix: premature hardware ready polling in CDB transactions
--

commit 9a56e63287f31e17b6e8c0dd1873f84b0c04b8d1
Author: Luo Liu <Luo.Liu@cixtech.com>

phy: cix: Add Sky1 DP PHY driver

Add a PHY driver for the CIX Sky1 dedicated DisplayPort PMA. Support
link rate, lane count, SSC and voltage swing via the generic PHY DP
ops.

> diff --git a/drivers/phy/cix/phy-cix-dp.c b/drivers/phy/cix/phy-cix-dp.c
> new file mode 100644
> index 0000000000000..b5adc9c295060
> --- /dev/null
> +++ b/drivers/phy/cix/phy-cix-dp.c
[ ... ]
> +static int cix_dp_phy_cdb_write(struct cix_dp *dp, u32 offset, u32 data)
> +{
> +	int ret;
> +
> +	ret = cix_dp_phy_cdb_ready(dp);
> +	if (ret)
> +		return ret;
> +
> +	writel(offset, dp->base + CIX_DP_CDB_ADDR);
> +	writel(data, dp->base + CIX_DP_CDB_WDATA);
> +	writel(CIX_DP_CDB_SEL_WRITE, dp->base + CIX_DP_CDB_SEL_WR);
> +	writel(1, dp->base + CIX_DP_CDB_ENABLE);
> +
> +	return cix_dp_phy_cdb_ready(dp);

[Severity: Medium]
Is there a risk of a race condition here if the hardware takes a few clock
cycles to pull the CIX_DP_CDB_READY bit low after CIX_DP_CDB_ENABLE is set?

Because cix_dp_phy_cdb_ready() uses readl_poll_timeout(), it immediately
performs a read. If the PHY IP drops the ready bit asynchronously (e.g.,
due to a clock domain crossing), the CPU might read the stale idle state
where the ready bit is still 1 and return success instantly.

This could cause the write operation to return before the hardware
transaction actually completes, potentially overlapping with the next
transaction and corrupting PHY configuration.

> +}
> +
> +static int cix_dp_phy_cdb_read(struct cix_dp *dp, u32 offset)
> +{
> +	int ret;
> +
> +	ret = cix_dp_phy_cdb_ready(dp);
> +	if (ret)
> +		return ret;
> +
> +	writel(offset, dp->base + CIX_DP_CDB_ADDR);
> +	writel(CIX_DP_CDB_SEL_READ, dp->base + CIX_DP_CDB_SEL_WR);
> +	writel(1, dp->base + CIX_DP_CDB_ENABLE);
> +
> +	ret = cix_dp_phy_cdb_ready(dp);
> +	if (ret)
> +		return ret;
> +
> +	return readl(dp->base + CIX_DP_CDB_RDATA) & GENMASK(15, 0);

[Severity: Medium]
Similarly, could this early ready check cause cix_dp_phy_cdb_read() to
read stale data?

If the hardware hasn't pulled the ready bit to 0 yet,
cix_dp_phy_cdb_ready() will return 0 immediately and we will read
CIX_DP_CDB_RDATA before the hardware has actually populated it.

> +}
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012080517.566920-1-Luo.Liu@cixtech.com?part=2

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Luo Liu" <Luo.Liu@cixtech.com>
Cc: devicetree@vger.kernel.org, linux-phy@lists.infradead.org,
	olteanv@gmail.com, vkoul@kernel.org, conor+dt@kernel.org,
	neil.armstrong@linaro.org, robh@kernel.org
Subject: Re: [PATCH 2/3] phy: cix: Add Sky1 DP PHY driver
Date: Mon, 12 Oct 2026 08:15:48 +0000	[thread overview]
Message-ID: <sashiko-outbox-167831@kernel.org> (raw)
In-Reply-To: <20261012080517.566920-3-Luo.Liu@cixtech.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: cix: premature hardware ready polling in CDB transactions
--

commit 9a56e63287f31e17b6e8c0dd1873f84b0c04b8d1
Author: Luo Liu <Luo.Liu@cixtech.com>

phy: cix: Add Sky1 DP PHY driver

Add a PHY driver for the CIX Sky1 dedicated DisplayPort PMA. Support
link rate, lane count, SSC and voltage swing via the generic PHY DP
ops.

> diff --git a/drivers/phy/cix/phy-cix-dp.c b/drivers/phy/cix/phy-cix-dp.c
> new file mode 100644
> index 0000000000000..b5adc9c295060
> --- /dev/null
> +++ b/drivers/phy/cix/phy-cix-dp.c
[ ... ]
> +static int cix_dp_phy_cdb_write(struct cix_dp *dp, u32 offset, u32 data)
> +{
> +	int ret;
> +
> +	ret = cix_dp_phy_cdb_ready(dp);
> +	if (ret)
> +		return ret;
> +
> +	writel(offset, dp->base + CIX_DP_CDB_ADDR);
> +	writel(data, dp->base + CIX_DP_CDB_WDATA);
> +	writel(CIX_DP_CDB_SEL_WRITE, dp->base + CIX_DP_CDB_SEL_WR);
> +	writel(1, dp->base + CIX_DP_CDB_ENABLE);
> +
> +	return cix_dp_phy_cdb_ready(dp);

[Severity: Medium]
Is there a risk of a race condition here if the hardware takes a few clock
cycles to pull the CIX_DP_CDB_READY bit low after CIX_DP_CDB_ENABLE is set?

Because cix_dp_phy_cdb_ready() uses readl_poll_timeout(), it immediately
performs a read. If the PHY IP drops the ready bit asynchronously (e.g.,
due to a clock domain crossing), the CPU might read the stale idle state
where the ready bit is still 1 and return success instantly.

This could cause the write operation to return before the hardware
transaction actually completes, potentially overlapping with the next
transaction and corrupting PHY configuration.

> +}
> +
> +static int cix_dp_phy_cdb_read(struct cix_dp *dp, u32 offset)
> +{
> +	int ret;
> +
> +	ret = cix_dp_phy_cdb_ready(dp);
> +	if (ret)
> +		return ret;
> +
> +	writel(offset, dp->base + CIX_DP_CDB_ADDR);
> +	writel(CIX_DP_CDB_SEL_READ, dp->base + CIX_DP_CDB_SEL_WR);
> +	writel(1, dp->base + CIX_DP_CDB_ENABLE);
> +
> +	ret = cix_dp_phy_cdb_ready(dp);
> +	if (ret)
> +		return ret;
> +
> +	return readl(dp->base + CIX_DP_CDB_RDATA) & GENMASK(15, 0);

[Severity: Medium]
Similarly, could this early ready check cause cix_dp_phy_cdb_read() to
read stale data?

If the hardware hasn't pulled the ready bit to 0 yet,
cix_dp_phy_cdb_ready() will return 0 immediately and we will read
CIX_DP_CDB_RDATA before the hardware has actually populated it.

> +}
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012080517.566920-1-Luo.Liu@cixtech.com?part=2

  reply	other threads:[~2026-10-12  8:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12  8:05 [PATCH 0/3] phy: cix: Add Sky1 DisplayPort PHY support Luo Liu
2026-10-12  8:05 ` Luo Liu
2026-10-12  8:05 ` [PATCH 1/3] dt-bindings: phy: Add CIX Sky1 DP PHY Luo Liu
2026-10-12  8:05   ` Luo Liu
2026-10-12  8:05 ` [PATCH 2/3] phy: cix: Add Sky1 DP PHY driver Luo Liu
2026-10-12  8:05   ` Luo Liu
2026-10-12  8:15   ` sashiko-bot [this message]
2026-10-12  8:15     ` sashiko-bot
2026-10-12  8:05 ` [PATCH 3/3] arm64: dts: cix: Add Sky1 DP PHY node Luo Liu
2026-10-12  8:05   ` Luo Liu

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=sashiko-outbox-167831@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Luo.Liu@cixtech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /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.