From: Andrew Jeffery <andrew@codeconstruct.com.au>
To: Ryan Chen <ryan_chen@aspeedtech.com>,
Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Joel Stanley <joel@jms.id.au>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] phy: add AST2700 usb3.2 phy driver
Date: Thu, 09 Jul 2026 11:45:52 +0930 [thread overview]
Message-ID: <ddb133ca1a3be605ee776b2276c1907c9ad32491.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20260116-upstream_usb3phy-v2-2-0b0c9f3eb6f4@aspeedtech.com>
Hi Ryan,
On Fri, 2026-01-16 at 10:53 +0800, Ryan Chen wrote:
...
> diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
> new file mode 100644
> index 000000000000..872d2163fcf5
> --- /dev/null
> +++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2026 Aspeed Technology Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +
> +#define PHY3S00 0x00
> +#define PHY3S00_INIT_DONE BIT(15)
> +#define PHY3S00_SRAM_BYPASS BIT(7)
> +#define PHY3S00_SRAM_EXT_LOAD BIT(6)
>
...
> +
> +static int aspeed_usb3_phy_init(struct phy *phy)
> +{
> + struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(aspeed_phy->clk);
> + if (ret) {
> + dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(aspeed_phy->rst);
> + if (ret) {
> + clk_disable_unprepare(aspeed_phy->clk);
> + return ret;
Nit: Given we have to do this below if the reset_control_deassert()
succeeds, perhaps add a label below and use goto here?
> + }
> +
> + /* Wait for USB3 PHY internal SRAM initialization done */
> + ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
> + val & PHY3S00_INIT_DONE,
> + USEC_PER_MSEC, 10 * USEC_PER_MSEC);
> + if (ret) {
> + dev_err(aspeed_phy->dev, "SRAM init timeout\n");
> + goto err_assert_reset;
> + }
> +
> + val = readl(aspeed_phy->regs + PHY3S00);
> + val |= PHY3S00_SRAM_BYPASS;
> + writel(val, aspeed_phy->regs + PHY3S00);
According to the datasheet PHY3S00[15] (PHY3S00_INIT_DONE above)
indicates that the PHY internal SRAM initialisation is complete. The
datasheet reports the SRAM is used for configuration of calibration
among other things. PHY3S00[6] instructs the PHY that software has
completed loading the configuration data into SRAM, however
PHY3S00_SRAM_BYPASS (PHY3S00[7]) tells the PHY to load configuration
from "hard wired" values.
Is it necessary to wait for SRAM initialisation to complete if we're
bypassing it? Or are there other side-effects involved in the setting
of PHY3S00[15]?
> +
> + /* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
> + * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
> + */
> + writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
> + writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
> + writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
> + writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
> +
> + return 0;
> +
> +err_assert_reset:
> + reset_control_assert(aspeed_phy->rst);
> + clk_disable_unprepare(aspeed_phy->clk);
> + return ret;
> +}
>
...
>
> +static struct platform_driver aspeed_usb3_phy_driver = {
> + .probe = aspeed_usb3_phy_probe,
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .of_match_table = aspeed_usb3_phy_match_table,
> + },
> +};
> +module_platform_driver(aspeed_usb3_phy_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ASPEED USB3.0 PHY Driver");
MODULE_AUTHOR()?
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Jeffery <andrew@codeconstruct.com.au>
To: Ryan Chen <ryan_chen@aspeedtech.com>,
Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Joel Stanley <joel@jms.id.au>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] phy: add AST2700 usb3.2 phy driver
Date: Thu, 09 Jul 2026 11:45:52 +0930 [thread overview]
Message-ID: <ddb133ca1a3be605ee776b2276c1907c9ad32491.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20260116-upstream_usb3phy-v2-2-0b0c9f3eb6f4@aspeedtech.com>
Hi Ryan,
On Fri, 2026-01-16 at 10:53 +0800, Ryan Chen wrote:
...
> diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
> new file mode 100644
> index 000000000000..872d2163fcf5
> --- /dev/null
> +++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2026 Aspeed Technology Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +
> +#define PHY3S00 0x00
> +#define PHY3S00_INIT_DONE BIT(15)
> +#define PHY3S00_SRAM_BYPASS BIT(7)
> +#define PHY3S00_SRAM_EXT_LOAD BIT(6)
>
...
> +
> +static int aspeed_usb3_phy_init(struct phy *phy)
> +{
> + struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(aspeed_phy->clk);
> + if (ret) {
> + dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(aspeed_phy->rst);
> + if (ret) {
> + clk_disable_unprepare(aspeed_phy->clk);
> + return ret;
Nit: Given we have to do this below if the reset_control_deassert()
succeeds, perhaps add a label below and use goto here?
> + }
> +
> + /* Wait for USB3 PHY internal SRAM initialization done */
> + ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
> + val & PHY3S00_INIT_DONE,
> + USEC_PER_MSEC, 10 * USEC_PER_MSEC);
> + if (ret) {
> + dev_err(aspeed_phy->dev, "SRAM init timeout\n");
> + goto err_assert_reset;
> + }
> +
> + val = readl(aspeed_phy->regs + PHY3S00);
> + val |= PHY3S00_SRAM_BYPASS;
> + writel(val, aspeed_phy->regs + PHY3S00);
According to the datasheet PHY3S00[15] (PHY3S00_INIT_DONE above)
indicates that the PHY internal SRAM initialisation is complete. The
datasheet reports the SRAM is used for configuration of calibration
among other things. PHY3S00[6] instructs the PHY that software has
completed loading the configuration data into SRAM, however
PHY3S00_SRAM_BYPASS (PHY3S00[7]) tells the PHY to load configuration
from "hard wired" values.
Is it necessary to wait for SRAM initialisation to complete if we're
bypassing it? Or are there other side-effects involved in the setting
of PHY3S00[15]?
> +
> + /* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
> + * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
> + */
> + writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
> + writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
> + writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
> + writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
> +
> + return 0;
> +
> +err_assert_reset:
> + reset_control_assert(aspeed_phy->rst);
> + clk_disable_unprepare(aspeed_phy->clk);
> + return ret;
> +}
>
...
>
> +static struct platform_driver aspeed_usb3_phy_driver = {
> + .probe = aspeed_usb3_phy_probe,
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .of_match_table = aspeed_usb3_phy_match_table,
> + },
> +};
> +module_platform_driver(aspeed_usb3_phy_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ASPEED USB3.0 PHY Driver");
MODULE_AUTHOR()?
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-09 2:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 2:53 [PATCH v2 0/3] Add AST2700 USB3.2 PHY driver Ryan Chen
2026-01-16 2:53 ` Ryan Chen
2026-01-16 2:53 ` [PATCH v2 1/3] dt-bindings: phy: aspeed: Document AST2700 USB3.0 PHY Ryan Chen
2026-01-16 2:53 ` Ryan Chen
2026-01-16 2:53 ` [PATCH v2 2/3] phy: add AST2700 usb3.2 phy driver Ryan Chen
2026-01-16 2:53 ` Ryan Chen
2026-07-09 2:15 ` Andrew Jeffery [this message]
2026-07-09 2:15 ` Andrew Jeffery
2026-07-15 5:55 ` Ryan Chen
2026-07-15 5:55 ` Ryan Chen
2026-01-16 2:53 ` [PATCH v2 3/3] MAINTAINERS: Add ASPEED USB3 PHY driver Ryan Chen
2026-01-16 2:53 ` Ryan Chen
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=ddb133ca1a3be605ee776b2276c1907c9ad32491.camel@codeconstruct.com.au \
--to=andrew@codeconstruct.com.au \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=ryan_chen@aspeedtech.com \
--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.