All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rustam Adilov" <adilov@disroot.org>
Cc: linux-phy@lists.infradead.org, vkoul@kernel.org,
	neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH v8 1/6] phy: realtek: usb2: introduce phy_reg_desc struct to the driver
Date: Mon, 12 Oct 2026 17:49:46 +0000	[thread overview]
Message-ID: <sashiko-outbox-168495@kernel.org> (raw)
In-Reply-To: <20261012173739.36377-2-adilov@disroot.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] phy: realtek: data race between debugfs and PHY ops corrupts hardware state
--

commit d16c7943f8b3fd4b0cfe55fc75ec12d09511eaf4
Author: Rustam Adilov <adilov@disroot.org>

phy: realtek: usb2: introduce phy_reg_desc struct to the driver

This commit introduces a phy_reg_desc struct to the realtek usb2 driver. It
stores per-SoC differences such as register offsets and busy bits. This
avoids duplication in driver data for RTL9607C and RTD SoCs.

> diff --git a/drivers/phy/realtek/phy-rtk-usb2.c b/drivers/phy/realtek/phy-rtk-usb2.c
> index 248550ef98cab..e8d0f0119ec0a 100644
> --- a/drivers/phy/realtek/phy-rtk-usb2.c
> +++ b/drivers/phy/realtek/phy-rtk-usb2.c

[ ... ]

> @@ -190,29 +199,31 @@ static int rtk_phy_write(struct phy_reg *phy_reg, char addr, char data)
>  	unsigned int val;
>  	void __iomem *reg_wrap_vstatus = phy_reg->reg_wrap_vstatus;
>  	void __iomem *reg_gusb2phyacc0 = phy_reg->reg_gusb2phyacc0;
> +	const struct phy_reg_desc *reg_desc = phy_reg->desc;
>  	int shift_bits = phy_reg->vstatus_index * 8;
>  	int ret = 0;
>  
>  	/* write data to VStatusOut2 (data output to phy) */
> -	writel((u32)data << shift_bits, reg_wrap_vstatus);
> +	writel((u32)data << shift_bits,
> +	       reg_wrap_vstatus + reg_desc->vstatus_offset);
>  
> -	ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
> +	ret = utmi_wait_register(reg_gusb2phyacc0, reg_desc->vstatus_busy, 0);
>  	if (ret)
>  		return ret;
>  
> -	/* VCtrl = low nibble of addr, set PHY_NEW_REG_REQ */
> -	val = PHY_NEW_REG_REQ | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
> +	/* VCtrl = low nibble of addr, set reg_desc->new_reg_req */
> +	val = reg_desc->new_reg_req | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
>  
>  	writel(val, reg_gusb2phyacc0);

[Severity: Medium]
Can this multi-step state write be interrupted and corrupted by concurrent
debugfs accesses?

A user with root privileges reading the debugfs file parameter via
rtk_usb2_parameter_show() in drivers/phy/realtek/phy-rtk-usb2.c repeatedly
calls rtk_phy_set_page() and rtk_phy_read() without acquiring any
driver-specific lock:

    /* Set page 0 */
    phy_data_page = phy_cfg->page0;
    rtk_phy_set_page(phy_reg, 0);

If the kernel concurrently executes a PHY state change (such as
rtk_phy_connect() or rtk_phy_init()), could their register accesses collide
and corrupt the PHY's internal register access state machine?

Additionally, since struct rtk_phy lacks a reference to struct phy, it
appears the debugfs callback cannot acquire phy->mutex. Is there another way
to synchronize these accesses?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012173739.36377-1-adilov@disroot.org?part=1

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

  reply	other threads:[~2026-10-12 17:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 17:37 [PATCH v8 0/6] phy: realtek: usb2: support for RTL9607C USB2 PHY Rustam Adilov
2026-10-12 17:37 ` [PATCH v8 1/6] phy: realtek: usb2: introduce phy_reg_desc struct to the driver Rustam Adilov
2026-10-12 17:49   ` sashiko-bot [this message]
2026-10-12 18:22     ` Rustam Adilov
2026-10-12 17:37 ` [PATCH v8 2/6] phy: realtek: usb2: introduce read and write functions to phy_reg_desc struct Rustam Adilov
2026-10-12 17:37 ` [PATCH v8 3/6] dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C support Rustam Adilov
2026-10-13  6:05   ` Krzysztof Kozlowski
2026-10-12 17:37 ` [PATCH v8 4/6] phy: realtek: usb2: introduce reset controller struct Rustam Adilov
2026-10-12 17:37 ` [PATCH v8 5/6] phy: realtek: usb2: add support for RTL9607C USB2 PHY Rustam Adilov
2026-10-12 18:17   ` sashiko-bot
2026-10-12 18:25     ` Rustam Adilov
2026-10-12 17:37 ` [PATCH v8 6/6] phy: realtek: Make configs available for MACH_REALTEK_RTL Rustam Adilov

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-168495@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=adilov@disroot.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --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.