* [PATCH v3 0/2] Cadence: Torrent: Enable PCIe + XAUI multilink configuration
From: Siddharth Vadapalli @ 2026-01-12 5:46 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, sjakhade, rogerq,
thomas.richard
Cc: andrew, linux-phy, linux-kernel, devicetree, linux-arm-kernel,
srk, s-vadapalli
Hello,
This patch series adds the dt-binding for PHY_TYPE_XAUI and adds the
driver support for enabling PCIe + XAUI multilink configuration.
Patch series is based on linux-next tagged next-20260109.
v2 of this patch series is at:
https://lore.kernel.org/r/20260104114422.2868321-1-s-vadapalli@ti.com/
Changes since v2:
- Collected Acked-by tag from Rob Herring (Arm) <robh@kernel.org>
https://lore.kernel.org/r/176772419699.2512006.6478554353373580831.robh@kernel.org/
- The commit message in the second patch has been updated to explain the
changes made to the LINKx_MASK/SHIFT and REFCLKx_MASK/SHIFT macros to
address feedback from Andrew Lunn <andrew@lunn.ch> at:
https://lore.kernel.org/r/7fd42221-d602-4ce4-9f7f-6754ed91e7aa@lunn.ch/
Regards,
Siddharth.
Swapnil Jakhade (2):
dt-bindings: phy: Add PHY_TYPE_XAUI definition
phy: cadence-torrent: Add PCIe + XAUI multilink configuration for
100MHz refclk
drivers/phy/cadence/phy-cadence-torrent.c | 143 ++++++++++++++++++++--
include/dt-bindings/phy/phy.h | 1 +
2 files changed, 137 insertions(+), 7 deletions(-)
--
2.51.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: phy: Add PHY_TYPE_XAUI definition
From: Siddharth Vadapalli @ 2026-01-12 5:46 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, sjakhade, rogerq,
thomas.richard
Cc: andrew, linux-phy, linux-kernel, devicetree, linux-arm-kernel,
srk, s-vadapalli
In-Reply-To: <20260112054636.108027-1-s-vadapalli@ti.com>
From: Swapnil Jakhade <sjakhade@cadence.com>
XAUI (eXtended Attachment Unit Interface) is a high-speed serial interface
standard for 10 Gigabit Ethernet (10GbE). It uses four lanes with each
lane operating at 3.125 Gbps (totaling 10 Gbps), to extend the XGMII
interface across circuit boards, commonly used in backplanes for
networking switches and high-performance computing. XAUI is defined as a
standardized instantiation of XGMII Extender in the IEEE 802.3
specification.
Add definition for XAUI PHY type.
Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
[s-vadapalli: added detailed description of XAUI in the commit message]
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
v2 of this patch is at:
https://lore.kernel.org/r/20260104114422.2868321-2-s-vadapalli@ti.com/
Changes since v2:
- Collected Acked-by tag from Rob Herring (Arm) <robh@kernel.org>
https://lore.kernel.org/r/176772419699.2512006.6478554353373580831.robh@kernel.org/
Regards,
Siddharth.
include/dt-bindings/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 6b901b342348..d77b372d302f 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -23,5 +23,6 @@
#define PHY_TYPE_DPHY 10
#define PHY_TYPE_CPHY 11
#define PHY_TYPE_USXGMII 12
+#define PHY_TYPE_XAUI 13
#endif /* _DT_BINDINGS_PHY */
--
2.51.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 2/2] phy: cadence-torrent: Add PCIe + XAUI multilink configuration for 100MHz refclk
From: Siddharth Vadapalli @ 2026-01-12 5:46 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, sjakhade, rogerq,
thomas.richard
Cc: andrew, linux-phy, linux-kernel, devicetree, linux-arm-kernel,
srk, s-vadapalli
In-Reply-To: <20260112054636.108027-1-s-vadapalli@ti.com>
From: Swapnil Jakhade <sjakhade@cadence.com>
Add register sequences for PCIe + XAUI multilink configuration for
100MHz reference clock.
The register sequences are fetched from a table by indexing entries based
on unique 'keys' generated by the Bitwise OR defined below:
REFCLK0_RATE | REFCLK1_RATE | LINK0_TYPE | LINK1_TYPE | SSC_TYPE
As of now, LINK_TYPE is a 3-bit value corresponding to the PHY type.
With the introduction of TYPE_XAUI, we need a 4-bit value to represent
the LINK_TYPE as TYPE_XAUI has the numerical value 8. Hence, extend the
LINKx_MASK macros to 4-bit masks. While at it, extend REFCLKx_MASK macros
as well to 4-bit masks to support reference clock frequencies that will be
added in the future.
Adjust the 'LINKx_SHIFT' and the 'REFCLKx_SHIFT' macros to account for
the aforementioned changes made to the masks.
Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
[s-vadapalli: elaborated on changes made to macros in the commit message]
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
v2 of this patch is at:
https://lore.kernel.org/r/20260104114422.2868321-3-s-vadapalli@ti.com/
Changes since v2:
- The commit message has been updated to explain the changes made to the
LINKx_MASK/SHIFT and REFCLKx_MASK/SHIFT macros to address feedback from
Andrew Lunn <andrew@lunn.ch> at:
https://lore.kernel.org/r/7fd42221-d602-4ce4-9f7f-6754ed91e7aa@lunn.ch/
Regards,
Siddharth.
drivers/phy/cadence/phy-cadence-torrent.c | 143 ++++++++++++++++++++--
1 file changed, 136 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cadence/phy-cadence-torrent.c
index 877f22177c69..d446a0f97688 100644
--- a/drivers/phy/cadence/phy-cadence-torrent.c
+++ b/drivers/phy/cadence/phy-cadence-torrent.c
@@ -300,6 +300,7 @@ enum cdns_torrent_phy_type {
TYPE_USB,
TYPE_USXGMII,
TYPE_PCIE_ML,
+ TYPE_XAUI,
};
enum cdns_torrent_ref_clk {
@@ -320,14 +321,14 @@ enum cdns_torrent_ssc_mode {
/* Unique key id for vals table entry
* REFCLK0_RATE | REFCLK1_RATE | LINK0_TYPE | LINK1_TYPE | SSC_TYPE
*/
-#define REFCLK0_SHIFT 12
-#define REFCLK0_MASK GENMASK(14, 12)
-#define REFCLK1_SHIFT 9
-#define REFCLK1_MASK GENMASK(11, 9)
-#define LINK0_SHIFT 6
-#define LINK0_MASK GENMASK(8, 6)
+#define REFCLK0_SHIFT 15
+#define REFCLK0_MASK GENMASK(18, 15)
+#define REFCLK1_SHIFT 11
+#define REFCLK1_MASK GENMASK(14, 11)
+#define LINK0_SHIFT 7
+#define LINK0_MASK GENMASK(10, 7)
#define LINK1_SHIFT 3
-#define LINK1_MASK GENMASK(5, 3)
+#define LINK1_MASK GENMASK(6, 3)
#define SSC_SHIFT 0
#define SSC_MASK GENMASK(2, 0)
@@ -709,6 +710,8 @@ static const char *cdns_torrent_get_phy_type(enum cdns_torrent_phy_type phy_type
return "USB";
case TYPE_USXGMII:
return "USXGMII";
+ case TYPE_XAUI:
+ return "XAUI";
default:
return "None";
}
@@ -3021,6 +3024,9 @@ static int cdns_torrent_phy_probe(struct platform_device *pdev)
case PHY_TYPE_USXGMII:
cdns_phy->phys[node].phy_type = TYPE_USXGMII;
break;
+ case PHY_TYPE_XAUI:
+ cdns_phy->phys[node].phy_type = TYPE_XAUI;
+ break;
default:
dev_err(dev, "Unsupported protocol\n");
ret = -EINVAL;
@@ -3405,6 +3411,95 @@ static DEFINE_NOIRQ_DEV_PM_OPS(cdns_torrent_phy_pm_ops,
cdns_torrent_phy_suspend_noirq,
cdns_torrent_phy_resume_noirq);
+/* PCIe and XAUI link configuration */
+static const struct cdns_reg_pairs pcie_xaui_link_cmn_regs[] = {
+ {0x0003, PHY_PLL_CFG},
+ {0x0600, CMN_PDIAG_PLL1_CLK_SEL_M0}
+};
+
+static const struct cdns_reg_pairs xaui_pcie_xcvr_diag_ln_regs[] = {
+ {0x0011, XCVR_DIAG_HSCLK_SEL},
+ {0x0089, XCVR_DIAG_PLLDRC_CTRL}
+};
+
+static const struct cdns_torrent_vals pcie_xaui_link_cmn_vals = {
+ .reg_pairs = pcie_xaui_link_cmn_regs,
+ .num_regs = ARRAY_SIZE(pcie_xaui_link_cmn_regs),
+};
+
+static const struct cdns_torrent_vals xaui_pcie_xcvr_diag_ln_vals = {
+ .reg_pairs = xaui_pcie_xcvr_diag_ln_regs,
+ .num_regs = ARRAY_SIZE(xaui_pcie_xcvr_diag_ln_regs),
+};
+
+/* XAUI 100 MHz Ref clk, no SSC */
+static const struct cdns_reg_pairs xaui_100_no_ssc_cmn_regs[] = {
+ {0x0004, CMN_PLL1_DSM_DIAG_M0},
+ {0x0B17, CMN_PDIAG_PLL1_CP_PADJ_M0},
+ {0x0E01, CMN_PDIAG_PLL1_CP_IADJ_M0},
+ {0x0D05, CMN_PDIAG_PLL1_FILT_PADJ_M0},
+ {0x003E, CMN_PLL1_INTDIV_M0},
+ {0x8000, CMN_PLL1_FRACDIVL_M0},
+ {0x0002, CMN_PLL1_FRACDIVH_M0},
+ {0x002A, CMN_PLL1_HIGH_THR_M0},
+ {0x3102, CMN_PDIAG_PLL1_CTRL_M0},
+ {0x007F, CMN_TXPUCAL_TUNE},
+ {0x007F, CMN_TXPDCAL_TUNE}
+};
+
+static const struct cdns_reg_pairs xaui_100_no_ssc_tx_ln_regs[] = {
+ {0x00F3, TX_PSC_A0},
+ {0x04A2, TX_PSC_A2},
+ {0x04A2, TX_PSC_A3 },
+ {0x0000, TX_TXCC_CPOST_MULT_00}
+};
+
+static const struct cdns_reg_pairs ti_xaui_100_no_ssc_tx_ln_regs[] = {
+ {0x00F3, TX_PSC_A0},
+ {0x04A2, TX_PSC_A2},
+ {0x04A2, TX_PSC_A3 },
+ {0x0000, TX_TXCC_CPOST_MULT_00},
+ {0x4000, XCVR_DIAG_RXCLK_CTRL}
+};
+
+static const struct cdns_reg_pairs xaui_100_no_ssc_rx_ln_regs[] = {
+ {0x091D, RX_PSC_A0},
+ {0x0900, RX_PSC_A2},
+ {0x0100, RX_PSC_A3},
+ {0x03C7, RX_REE_GCSM1_EQENM_PH1},
+ {0x01C7, RX_REE_GCSM1_EQENM_PH2},
+ {0x0000, RX_DIAG_DFE_CTRL},
+ {0x0019, RX_REE_TAP1_CLIP},
+ {0x0019, RX_REE_TAP2TON_CLIP},
+ {0x0098, RX_DIAG_NQST_CTRL},
+ {0x0C01, RX_DIAG_DFE_AMP_TUNE_2},
+ {0x0000, RX_DIAG_DFE_AMP_TUNE_3},
+ {0x0000, RX_DIAG_PI_CAP},
+ {0x0031, RX_DIAG_PI_RATE},
+ {0x0001, RX_DIAG_ACYA},
+ {0x018C, RX_CDRLF_CNFG},
+};
+
+static const struct cdns_torrent_vals xaui_100_no_ssc_cmn_vals = {
+ .reg_pairs = xaui_100_no_ssc_cmn_regs,
+ .num_regs = ARRAY_SIZE(xaui_100_no_ssc_cmn_regs),
+};
+
+static const struct cdns_torrent_vals xaui_100_no_ssc_tx_ln_vals = {
+ .reg_pairs = xaui_100_no_ssc_tx_ln_regs,
+ .num_regs = ARRAY_SIZE(xaui_100_no_ssc_tx_ln_regs),
+};
+
+static const struct cdns_torrent_vals ti_xaui_100_no_ssc_tx_ln_vals = {
+ .reg_pairs = ti_xaui_100_no_ssc_tx_ln_regs,
+ .num_regs = ARRAY_SIZE(ti_xaui_100_no_ssc_tx_ln_regs),
+};
+
+static const struct cdns_torrent_vals xaui_100_no_ssc_rx_ln_vals = {
+ .reg_pairs = xaui_100_no_ssc_rx_ln_regs,
+ .num_regs = ARRAY_SIZE(xaui_100_no_ssc_rx_ln_regs),
+};
+
/* USB and DP link configuration */
static const struct cdns_reg_pairs usb_dp_link_cmn_regs[] = {
{0x0002, PHY_PLL_CFG},
@@ -4876,6 +4971,7 @@ static const struct cdns_torrent_vals_entry link_cmn_vals_entries[] = {
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_USB), &pcie_usb_link_cmn_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_DP), &pcie_dp_link_cmn_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_USXGMII), &pcie_usxgmii_link_cmn_vals},
+ {CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_XAUI), &pcie_xaui_link_cmn_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE_ML, TYPE_USB), &ml_pcie_usb_link_cmn_vals},
@@ -4902,6 +4998,8 @@ static const struct cdns_torrent_vals_entry link_cmn_vals_entries[] = {
{CDNS_TORRENT_KEY_ANYCLK(TYPE_USXGMII, TYPE_PCIE), &pcie_usxgmii_link_cmn_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_USXGMII, TYPE_SGMII), &usxgmii_sgmii_link_cmn_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_USXGMII, TYPE_QSGMII), &usxgmii_sgmii_link_cmn_vals},
+
+ {CDNS_TORRENT_KEY_ANYCLK(TYPE_XAUI, TYPE_PCIE), &pcie_xaui_link_cmn_vals},
};
static const struct cdns_torrent_vals_entry xcvr_diag_vals_entries[] = {
@@ -4916,6 +5014,7 @@ static const struct cdns_torrent_vals_entry xcvr_diag_vals_entries[] = {
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_USB), &pcie_usb_xcvr_diag_ln_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_DP), &pcie_dp_xcvr_diag_ln_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_USXGMII), &pcie_usxgmii_xcvr_diag_ln_vals},
+ {CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE, TYPE_XAUI), NULL},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_PCIE_ML, TYPE_USB), &ml_pcie_usb_xcvr_diag_ln_vals},
@@ -4942,6 +5041,8 @@ static const struct cdns_torrent_vals_entry xcvr_diag_vals_entries[] = {
{CDNS_TORRENT_KEY_ANYCLK(TYPE_USXGMII, TYPE_PCIE), &usxgmii_pcie_xcvr_diag_ln_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_USXGMII, TYPE_SGMII), &usxgmii_sgmii_xcvr_diag_ln_vals},
{CDNS_TORRENT_KEY_ANYCLK(TYPE_USXGMII, TYPE_QSGMII), &usxgmii_sgmii_xcvr_diag_ln_vals},
+
+ {CDNS_TORRENT_KEY_ANYCLK(TYPE_XAUI, TYPE_PCIE), &xaui_pcie_xcvr_diag_ln_vals},
};
static const struct cdns_torrent_vals_entry pcs_cmn_vals_entries[] = {
@@ -4983,6 +5084,8 @@ static const struct cdns_torrent_vals_entry cmn_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), NULL},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), NULL},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), &ml_pcie_100_no_ssc_cmn_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), &ml_pcie_100_no_ssc_cmn_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), &ml_pcie_100_int_ssc_cmn_vals},
@@ -5033,6 +5136,8 @@ static const struct cdns_torrent_vals_entry cmn_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_cmn_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &xaui_100_no_ssc_cmn_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &sl_usxgmii_156_25_no_ssc_cmn_vals},
/* Dual refclk */
@@ -5077,6 +5182,8 @@ static const struct cdns_torrent_vals_entry cdns_tx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), NULL},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), NULL},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), NULL},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), NULL},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), NULL},
@@ -5127,6 +5234,8 @@ static const struct cdns_torrent_vals_entry cdns_tx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_tx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &xaui_100_no_ssc_tx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &usxgmii_156_25_no_ssc_tx_ln_vals},
/* Dual refclk */
@@ -5171,6 +5280,8 @@ static const struct cdns_torrent_vals_entry cdns_rx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), &pcie_100_no_ssc_rx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), &ml_pcie_100_no_ssc_rx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), &ml_pcie_100_no_ssc_rx_ln_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), &ml_pcie_100_no_ssc_rx_ln_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), &ml_pcie_100_no_ssc_rx_ln_vals},
@@ -5221,6 +5332,8 @@ static const struct cdns_torrent_vals_entry cdns_rx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_rx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &xaui_100_no_ssc_rx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &usxgmii_156_25_no_ssc_rx_ln_vals},
/* Dual refclk */
@@ -5301,6 +5414,8 @@ static const struct cdns_torrent_vals_entry ti_tx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), NULL},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), NULL},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), NULL},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), NULL},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), NULL},
@@ -5351,6 +5466,8 @@ static const struct cdns_torrent_vals_entry ti_tx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_tx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &ti_xaui_100_no_ssc_tx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &usxgmii_156_25_no_ssc_tx_ln_vals},
/* Dual refclk */
@@ -5429,6 +5546,8 @@ static const struct cdns_torrent_vals_entry ti_j7200_cmn_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), NULL},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), NULL},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), &ml_pcie_100_no_ssc_cmn_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), &ml_pcie_100_no_ssc_cmn_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), &ml_pcie_100_int_ssc_cmn_vals},
@@ -5479,6 +5598,8 @@ static const struct cdns_torrent_vals_entry ti_j7200_cmn_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_cmn_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &xaui_100_no_ssc_cmn_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &sl_usxgmii_156_25_no_ssc_cmn_vals},
/* Dual refclk */
@@ -5523,6 +5644,8 @@ static const struct cdns_torrent_vals_entry ti_j7200_tx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), NULL},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), NULL},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), NULL},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), NULL},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), NULL},
@@ -5573,6 +5696,8 @@ static const struct cdns_torrent_vals_entry ti_j7200_tx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_tx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &ti_xaui_100_no_ssc_tx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &usxgmii_156_25_no_ssc_tx_ln_vals},
/* Dual refclk */
@@ -5617,6 +5742,8 @@ static const struct cdns_torrent_vals_entry ti_j7200_rx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_DP, NO_SSC), &pcie_100_no_ssc_rx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE, TYPE_XAUI, NO_SSC), &pcie_100_no_ssc_rx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, NO_SSC), &pcie_100_no_ssc_rx_ln_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, EXTERNAL_SSC), &pcie_100_no_ssc_rx_ln_vals},
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_PCIE_ML, TYPE_USB, INTERNAL_SSC), &pcie_100_no_ssc_rx_ln_vals},
@@ -5667,6 +5794,8 @@ static const struct cdns_torrent_vals_entry ti_j7200_rx_ln_vals_entries[] = {
{CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_USB, TYPE_DP, NO_SSC), &usb_100_no_ssc_rx_ln_vals},
+ {CDNS_TORRENT_KEY(CLK_100_MHZ, CLK_100_MHZ, TYPE_XAUI, TYPE_PCIE, NO_SSC), &xaui_100_no_ssc_rx_ln_vals},
+
{CDNS_TORRENT_KEY(CLK_156_25_MHZ, CLK_156_25_MHZ, TYPE_USXGMII, TYPE_NONE, NO_SSC), &usxgmii_156_25_no_ssc_rx_ln_vals},
/* Dual refclk */
--
2.51.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 3/4] MAINTAINERS: Add Axiado AX3000 eMMC PHY driver
From: Prasad Bolisetty @ 2026-01-12 6:02 UTC (permalink / raw)
To: Tzu-Hao Wei, SriNavmani A, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc
In-Reply-To: <20260109-axiado-ax3000-add-emmc-phy-driver-support-v1-3-dd43459dbfea@axiado.com>
On 1/9/2026 1:43 AM, Tzu-Hao Wei wrote:
> Add SriNavmani, Prasad and me as maintainers for Axiado AX3000 eMMC PHY
> driver
>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
> ---
> MAINTAINERS | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a0dd762f5648b7e4e6fc62560662e43720422e01..6d1af11eb289ffb7c0d8634ac7d8f903aed1799c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4250,6 +4250,16 @@ W: https://ez.analog.com/linux-software-drivers
> F: Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
> F: drivers/hwmon/axi-fan-control.c
>
> +AXIADO EMMC PHY DRIVER
> +M: SriNavmani A <srinavmani@axiado.com>
> +M: Tzu-Hao Wei <twei@axiado.com>
> +M: Prasad Bolisetty <pbolisetty@axiado.com>
Acked-by: Prasad Bolisetty <pbolisetty@axiado.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: arasan,sdhci: Add Axiado AX3000 SoC
From: Tzu-Hao Wei @ 2026-01-12 6:10 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: SriNavmani A, Vinod Koul, Adrian Hunter, openbmc, Neil Armstrong,
devicetree, Ulf Hansson, Krzysztof Kozlowski, Prasad Bolisetty,
Conor Dooley, linux-arm-kernel, linux-phy, linux-kernel,
Michal Simek, linux-mmc
In-Reply-To: <176795814783.2967277.2609413382098901076.robh@kernel.org>
On 1/9/2026 7:29 PM, Rob Herring (Arm) wrote:
>>
>> Signed-off-by: SriNavmani A <srinavmani@axiado.com>
>> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
>> ---
>> Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
Thanks for catching it. I will fix it in the next version.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Luca Weiss @ 2026-01-12 7:56 UTC (permalink / raw)
To: Martin K. Petersen, Luca Weiss
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
phone-devel, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, linux-scsi, linux-phy
In-Reply-To: <yq1a4yj5ysp.fsf@ca-mkp.ca.oracle.com>
Hi Martin,
On Mon Jan 12, 2026 at 3:52 AM CET, Martin K. Petersen wrote:
>
> Hi Luca!
>
>> Add the nodes for the UFS PHY and UFS host controller, along with the
>> ICE used for UFS.
>
> arch/arm64/boot/dts/qcom/milos.dtsi isn't present in v6.19-rc1 so I am
> unable to apply this.
This patch is based on linux-next where milos.dtsi exists, but any arm64
qcom dts is for Bjorn to pick up, so please ignore this patch.
Regards
Luca
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-of-arasan: add support on Axiado AX3000 SoC
From: Adrian Hunter @ 2026-01-12 8:23 UTC (permalink / raw)
To: Tzu-Hao Wei, SriNavmani A, Prasad Bolisetty, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Michal Simek
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-mmc,
openbmc
In-Reply-To: <20260109-axiado-ax3000-add-emmc-host-driver-support-v2-2-934f1a61f7c0@axiado.com>
On 09/01/2026 11:46, Tzu-Hao Wei wrote:
> From: SriNavmani A <srinavmani@axiado.com>
>
> Axiado AX3000 SoC eMMC controller is based on Arasan eMMC 5.1 host
> controller IP.
>
> Signed-off-by: SriNavmani A <srinavmani@axiado.com>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
Apart from dt-bindings issues:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index ab7f0ffe7b4f007a58eb0a26868b08b0b02b40f3..5da915edd7416ab5c725a784867098c5e19236b6 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -1512,6 +1512,16 @@ static struct sdhci_arasan_of_data intel_keembay_sdio_data = {
> .clk_ops = &arasan_clk_ops,
> };
>
> +static const struct sdhci_pltfm_data sdhci_arasan_axiado_pdata = {
> + .ops = &sdhci_arasan_ops,
> + .quirks = SDHCI_QUIRK_BROKEN_CQE,
> +};
> +
> +static struct sdhci_arasan_of_data sdhci_arasan_axiado_data = {
> + .pdata = &sdhci_arasan_axiado_pdata,
> + .clk_ops = &arasan_clk_ops,
> +};
> +
> static const struct of_device_id sdhci_arasan_of_match[] = {
> /* SoC-specific compatible strings w/ soc_ctl_map */
> {
> @@ -1538,6 +1548,10 @@ static const struct of_device_id sdhci_arasan_of_match[] = {
> .compatible = "intel,keembay-sdhci-5.1-sdio",
> .data = &intel_keembay_sdio_data,
> },
> + {
> + .compatible = "axiado,ax3000-sdhci-5.1-emmc",
> + .data = &sdhci_arasan_axiado_data,
> + },
> /* Generic compatible below here */
> {
> .compatible = "arasan,sdhci-8.9a",
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Neil Armstrong @ 2026-01-12 8:26 UTC (permalink / raw)
To: Luca Weiss, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Alim Akhtar,
Avri Altman, Bart Van Assche, Vinod Koul, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy
In-Reply-To: <2486dc4b-71f3-4cd9-8139-b397407d7e4d@linaro.org>
On 1/7/26 14:53, Neil Armstrong wrote:
> Hi,
>
> On 1/7/26 09:05, Luca Weiss wrote:
>> Add the nodes for the UFS PHY and UFS host controller, along with the
>> ICE used for UFS.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> arch/arm64/boot/dts/qcom/milos.dtsi | 127 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 124 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
>> index e1a51d43943f..0f69deabb60c 100644
>> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
>> @@ -797,9 +797,9 @@ gcc: clock-controller@100000 {
>> <&sleep_clk>,
>> <0>, /* pcie_0_pipe_clk */
>> <0>, /* pcie_1_pipe_clk */
>> - <0>, /* ufs_phy_rx_symbol_0_clk */
>> - <0>, /* ufs_phy_rx_symbol_1_clk */
>> - <0>, /* ufs_phy_tx_symbol_0_clk */
>> + <&ufs_mem_phy 0>,
>> + <&ufs_mem_phy 1>,
>> + <&ufs_mem_phy 2>,
>> <0>; /* usb3_phy_wrapper_gcc_usb30_pipe_clk */
>> #clock-cells = <1>;
>> @@ -1151,6 +1151,127 @@ aggre2_noc: interconnect@1700000 {
>> qcom,bcm-voters = <&apps_bcm_voter>;
>> };
>> + ufs_mem_phy: phy@1d80000 {
>> + compatible = "qcom,milos-qmp-ufs-phy";
>> + reg = <0x0 0x01d80000 0x0 0x2000>;
>> +
>> + clocks = <&rpmhcc RPMH_CXO_CLK>,
>> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
>> + <&tcsr TCSR_UFS_CLKREF_EN>;
>> + clock-names = "ref",
>> + "ref_aux",
>> + "qref";
>> +
>> + resets = <&ufs_mem_hc 0>;
>> + reset-names = "ufsphy";
>> +
>> + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
>> +
>> + #clock-cells = <1>;
>> + #phy-cells = <0>;
>> +
>> + status = "disabled";
>> + };
>> +
>> + ufs_mem_hc: ufshc@1d84000 {
>> + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
>> + reg = <0x0 0x01d84000 0x0 0x3000>;
>> +
>> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
>> +
>> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
>> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
>> + <&gcc GCC_UFS_PHY_AHB_CLK>,
>> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
>> + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
>> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
>> + clock-names = "core_clk",
>> + "bus_aggr_clk",
>> + "iface_clk",
>> + "core_clk_unipro",
>> + "ref_clk",
>> + "tx_lane0_sync_clk",
>> + "rx_lane0_sync_clk",
>> + "rx_lane1_sync_clk";
>> +
>> + resets = <&gcc GCC_UFS_PHY_BCR>;
>> + reset-names = "rst";
>> +
>> + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>> + &cnoc_cfg SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
>> + interconnect-names = "ufs-ddr",
>> + "cpu-ufs";
>> +
>> + power-domains = <&gcc UFS_PHY_GDSC>;
>> + required-opps = <&rpmhpd_opp_nom>;
>> +
>> + operating-points-v2 = <&ufs_opp_table>;
>> +
>> + iommus = <&apps_smmu 0x60 0>;
>
> dma-coherent ?
>
> and no MCQ support ?
So, people just ignore my comment ?
Milos is based on SM8550, so it should have dma-coherent, for the MCQ
I hope they used the fixed added to the SM8650 UFS controller for MCQ.
Neil
>
> <snip>
>
> Thanks,
> Neil
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 0/2] Add Axiado AX3000 eMMC Host Controller Support
From: Krzysztof Kozlowski @ 2026-01-12 8:30 UTC (permalink / raw)
To: Tzu-Hao Wei, SriNavmani A, Prasad Bolisetty, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Adrian Hunter, Michal Simek
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-mmc,
openbmc
In-Reply-To: <20260109-axiado-ax3000-add-emmc-host-driver-support-v2-0-934f1a61f7c0@axiado.com>
On 09/01/2026 10:46, Tzu-Hao Wei wrote:
> Axiado AX3000 SoC eMMC controller is based on Arasan eMMC controller.
>
> This series includes:
> 1. Add bindings for AX3000 SoC eMMC controller
> 2. Add arasan sdhci support for eMMC in Axiado AX3000
>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
> ---
> Changes in v2:
> - Keep host controller changes in this patchset
> - Use pdata instead of mix compatible string
> - Fix coding style
> - Link to v1: https://lore.kernel.org/r/20251222-axiado-ax3000-add-emmc-host-driver-support-v1-0-5457d0ebcdb4@axiado.com
>
> ---
> SriNavmani A (2):
> dt-bindings: mmc: arasan,sdhci: Add Axiado AX3000 SoC
> mmc: sdhci-of-arasan: add support on Axiado AX3000 SoC
>
> Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 3 +++
> drivers/mmc/host/sdhci-of-arasan.c | 14 ++++++++++++++
> 2 files changed, 17 insertions(+)
> ---
> base-commit: f10c325a345fef0a688a2bcdfab1540d1c924148
> change-id: 20251222-axiado-ax3000-add-emmc-host-driver-support-2cc84a8f889a
> prerequisite-change-id: 20260108-axiado-ax3000-add-emmc-phy-driver-support-d61aead8f622:v1
> prerequisite-patch-id: 03617f4dadb7ed33653d1e0b3c03e732ed4948c5
> prerequisite-patch-id: 454a64fb94f3c1b6cf6fb7fbfce97f706933b7e3
> prerequisite-patch-id: 7961935b88d6c3056b55b4058c1ba878aa00490c
> prerequisite-patch-id: f87b65e3c93f8f1edf2305784ea3f81a04c4ad58
Huh, why and how?
It's impossible to apply this.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/4] Add eMMC PHY support for Axiado AX3000 SoC
From: Krzysztof Kozlowski @ 2026-01-12 8:32 UTC (permalink / raw)
To: Tzu-Hao Wei, SriNavmani A, Prasad Bolisetty, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc
In-Reply-To: <20260109-axiado-ax3000-add-emmc-phy-driver-support-v1-0-dd43459dbfea@axiado.com>
On 09/01/2026 10:43, Tzu-Hao Wei wrote:
> Axiado AX3000 SoC contains Arasan PHY which provides the interface to the
> HS200 eMMC controller.
>
> This series includes:
> 1. Add bindings for Axiado AX3000 eMMC PHY
> 2. Add Axiado AX3000 eMMC phy driver
> 3. Update MAINTAINERS for the new driver
> 4. Update Axiado AX3000 device tree
>
> Changes: (The previous version was mixed with Host driver, so I separate
> the PHY driver as a new thread)
> - Fix property order in required section to match properties section
> - Fixed example to use lowercase hex and proper node naming
> - Removed wrapper functions, use readl/writel directly
> - Replaced manual polling loops with read_poll_timeout macro
> - Used devm_platform_ioremap_resource instead of separate calls
> - Removed unnecessary of_match_node check
> - Used dev_err_probe for error reporting
> - Added proper Kconfig dependencies (ARCH_AXIADO || COMPILE_TEST)
> - Fixed various coding style issues
> - Link to previous patches: https://lore.kernel.org/all/20251222-axiado-ax3000-add-emmc-host-driver-support-v1-0-5457d0ebcdb4@axiado.com/
>
So v2. Always version your patches correctly.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/8] Add Axiado AX3000 eMMC Host Controller Support
From: Krzysztof Kozlowski @ 2026-01-12 8:33 UTC (permalink / raw)
To: Tzu-Hao Wei
Cc: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
Ulf Hansson, Adrian Hunter, Michal Simek, linux-phy, devicetree,
linux-arm-kernel, linux-kernel, linux-mmc
In-Reply-To: <108cf065-e2ac-4ab7-9c39-6e52cb5439fa@axiado.com>
On 09/01/2026 10:48, Tzu-Hao Wei wrote:
> On 12/23/2025 10:33 PM, Krzysztof Kozlowski wrote:
>>
>> You completely disorganized the patch.. dts is mixed all over driver
>> code, you combined two or three completely independent subsystems into
>> one.
>>
>> Read submitting patches in DT dir to understand how DTS must be sent.
>>
>>
>> Best regards,
>> Krzysztof
>>
> Hi Krzysztof,
>
> Appreciate your review comments. We reorganized the patch series per your review comments, separating the DTS changes and applying the driver code changes to the respective subsystems as following
Please wrap your emails correctly.
> https://lore.kernel.org/all/20260109-axiado-ax3000-add-emmc-phy-driver-support-v1-0-dd43459dbfea@axiado.com/
You sent this as v1, which I noticed only now. If I knew you ignored my
feedback, I would not care to review again... Lesson for me.
> https://lore.kernel.org/all/20260109-axiado-ax3000-add-emmc-host-driver-support-v2-0-934f1a61f7c0@axiado.com/
>
> We will also sync up internally and tighten our review process to ensure this kind of mistake does not happen again in future submissions.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: phy: axiado,ax3000-emmc-phy: add Axiado eMMC PHY
From: Krzysztof Kozlowski @ 2026-01-12 8:34 UTC (permalink / raw)
To: Tzu-Hao Wei
Cc: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-phy,
devicetree, linux-arm-kernel, linux-kernel, openbmc
In-Reply-To: <20260111-camouflaged-shiny-wrasse-796dbd@quoll>
On 11/01/2026 11:37, Krzysztof Kozlowski wrote:
> On Fri, Jan 09, 2026 at 05:43:29PM +0800, Tzu-Hao Wei wrote:
>> From: SriNavmani A <srinavmani@axiado.com>
>>
>> Axiado AX3000 SoC contains Arasan PHY which provides the interface to the
>> HS200 eMMC host controller.
>>
>> Signed-off-by: SriNavmani A <srinavmani@axiado.com>
>> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
>> ---
>
> You did not bother to test your code...
And this is not even v1, but v2 and you completely ignored that part.
So did you implement any previous feedback?
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Luca Weiss @ 2026-01-12 8:45 UTC (permalink / raw)
To: Neil Armstrong, Luca Weiss, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Alim Akhtar, Avri Altman, Bart Van Assche, Vinod Koul,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy
In-Reply-To: <543d9e55-c858-40f9-8785-c9f636850120@linaro.org>
Hi Neil,
On Mon Jan 12, 2026 at 9:26 AM CET, Neil Armstrong wrote:
> On 1/7/26 14:53, Neil Armstrong wrote:
>> Hi,
>>
>> On 1/7/26 09:05, Luca Weiss wrote:
>>> Add the nodes for the UFS PHY and UFS host controller, along with the
>>> ICE used for UFS.
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/milos.dtsi | 127 +++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 124 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
>>> index e1a51d43943f..0f69deabb60c 100644
>>> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
>>> @@ -797,9 +797,9 @@ gcc: clock-controller@100000 {
>>> <&sleep_clk>,
>>> <0>, /* pcie_0_pipe_clk */
>>> <0>, /* pcie_1_pipe_clk */
>>> - <0>, /* ufs_phy_rx_symbol_0_clk */
>>> - <0>, /* ufs_phy_rx_symbol_1_clk */
>>> - <0>, /* ufs_phy_tx_symbol_0_clk */
>>> + <&ufs_mem_phy 0>,
>>> + <&ufs_mem_phy 1>,
>>> + <&ufs_mem_phy 2>,
>>> <0>; /* usb3_phy_wrapper_gcc_usb30_pipe_clk */
>>> #clock-cells = <1>;
>>> @@ -1151,6 +1151,127 @@ aggre2_noc: interconnect@1700000 {
>>> qcom,bcm-voters = <&apps_bcm_voter>;
>>> };
>>> + ufs_mem_phy: phy@1d80000 {
>>> + compatible = "qcom,milos-qmp-ufs-phy";
>>> + reg = <0x0 0x01d80000 0x0 0x2000>;
>>> +
>>> + clocks = <&rpmhcc RPMH_CXO_CLK>,
>>> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
>>> + <&tcsr TCSR_UFS_CLKREF_EN>;
>>> + clock-names = "ref",
>>> + "ref_aux",
>>> + "qref";
>>> +
>>> + resets = <&ufs_mem_hc 0>;
>>> + reset-names = "ufsphy";
>>> +
>>> + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
>>> +
>>> + #clock-cells = <1>;
>>> + #phy-cells = <0>;
>>> +
>>> + status = "disabled";
>>> + };
>>> +
>>> + ufs_mem_hc: ufshc@1d84000 {
>>> + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
>>> + reg = <0x0 0x01d84000 0x0 0x3000>;
>>> +
>>> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
>>> +
>>> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
>>> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
>>> + <&gcc GCC_UFS_PHY_AHB_CLK>,
>>> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
>>> + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
>>> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
>>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
>>> + clock-names = "core_clk",
>>> + "bus_aggr_clk",
>>> + "iface_clk",
>>> + "core_clk_unipro",
>>> + "ref_clk",
>>> + "tx_lane0_sync_clk",
>>> + "rx_lane0_sync_clk",
>>> + "rx_lane1_sync_clk";
>>> +
>>> + resets = <&gcc GCC_UFS_PHY_BCR>;
>>> + reset-names = "rst";
>>> +
>>> + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>>> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>>> + &cnoc_cfg SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
>>> + interconnect-names = "ufs-ddr",
>>> + "cpu-ufs";
>>> +
>>> + power-domains = <&gcc UFS_PHY_GDSC>;
>>> + required-opps = <&rpmhpd_opp_nom>;
>>> +
>>> + operating-points-v2 = <&ufs_opp_table>;
>>> +
>>> + iommus = <&apps_smmu 0x60 0>;
>>
>> dma-coherent ?
Given that downstream volcano.dtsi has dma-coherent in the ufshc@1d84000
node, looks like this is missing in my patch.
>>
>> and no MCQ support ?
Not sure, I could only find one reference to MCQ on createpoint for
milos, but given there's no mcq_sqd/mcq_vs reg defined downstream, and I
couldn't find anything for the same register values in the .FLAT file, I
don't think Milos has MCQ? Feel free to prove me wrong though.
>
> So, people just ignore my comment ?
>
> Milos is based on SM8550, so it should have dma-coherent, for the MCQ
> I hope they used the fixed added to the SM8650 UFS controller for MCQ.
Not sure what this should mean regarding MCQ...
Regards
Luca
>
> Neil
>
>>
>> <snip>
>>
>> Thanks,
>> Neil
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: arasan,sdhci: Add Axiado AX3000 SoC
From: Krzysztof Kozlowski @ 2026-01-12 8:46 UTC (permalink / raw)
To: Tzu-Hao Wei, SriNavmani A, Prasad Bolisetty, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Adrian Hunter, Michal Simek
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-mmc,
openbmc
In-Reply-To: <20260109-axiado-ax3000-add-emmc-host-driver-support-v2-1-934f1a61f7c0@axiado.com>
On 09/01/2026 10:46, Tzu-Hao Wei wrote:
> From: SriNavmani A <srinavmani@axiado.com>
>
> Add compatible strings for Axiado AX3000 SoC eMMC controller which
> is based on Arasan eMMC controller.
>
> Signed-off-by: SriNavmani A <srinavmani@axiado.com>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Your patchset is impossible to apply. Do not add fake dependencies.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: qcom: edp: Fix NULL pointer dereference for phy v6 (x1e80100)
From: Konrad Dybcio @ 2026-01-12 9:25 UTC (permalink / raw)
To: Val Packett, Vinod Koul, Neil Armstrong, Abel Vesa,
Dmitry Baryshkov
Cc: Abel Vesa, linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20260111083317.604754-1-val@packett.cool>
On 1/11/26 9:25 AM, Val Packett wrote:
> For Glymur SoC support, the com_clk_fwd_cfg callback was added, and a
> stub implementation was added for the v4 of the hardware. However it
> was omitted for the v6, causing a NULL pointer dereference oops on
> Hamoa/Purwa (X1E/X1P) SoC devices. Fix by adding the appropriate stub.
>
> Fixes: add66a6673bc ("phy: qcom: edp: Add Glymur platform support")
> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Val Packett <val@packett.cool>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 0/2] Add Axiado AX3000 eMMC Host Controller Support
From: Tzu-Hao Wei @ 2026-01-12 10:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, SriNavmani A, Prasad Bolisetty, Vinod Koul,
Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Adrian Hunter, Michal Simek
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-mmc,
openbmc
In-Reply-To: <55a2c060-014f-4077-85a1-15f6f799d263@kernel.org>
On 1/12/2026 4:30 PM, Krzysztof Kozlowski wrote:
>> ---
>> base-commit: f10c325a345fef0a688a2bcdfab1540d1c924148
>> change-id: 20251222-axiado-ax3000-add-emmc-host-driver-support-2cc84a8f889a
>> prerequisite-change-id: 20260108-axiado-ax3000-add-emmc-phy-driver-support-d61aead8f622:v1
>> prerequisite-patch-id: 03617f4dadb7ed33653d1e0b3c03e732ed4948c5
>> prerequisite-patch-id: 454a64fb94f3c1b6cf6fb7fbfce97f706933b7e3
>> prerequisite-patch-id: 7961935b88d6c3056b55b4058c1ba878aa00490c
>> prerequisite-patch-id: f87b65e3c93f8f1edf2305784ea3f81a04c4ad58
>
> Huh, why and how?
>
> It's impossible to apply this.
>
> Best regards,
> Krzysztof
Thanks. Those prerequisite lines were included from b4 after adding the deps:
change-id: 20260108-axiado-ax3000-add-emmc-phy-driver-support-d61aead8f622:v1
base-commit: v6.19-rc4
I'll remove them.
Best regards,
TH
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: phy: axiado,ax3000-emmc-phy: add Axiado eMMC PHY
From: Tzu-Hao Wei @ 2026-01-12 10:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-phy,
devicetree, linux-arm-kernel, linux-kernel, openbmc
In-Reply-To: <041acb02-13de-4efe-a7d0-630390fb2940@kernel.org>
On 1/12/2026 4:34 PM, Krzysztof Kozlowski wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
>> You did not bother to test your code...
>
> And this is not even v1, but v2 and you completely ignored that part.
>
> So did you implement any previous feedback?
>
> Best regards,
> Krzysztof
Sorry for the confusion.
All of your previous feedback was implemented. I missed one YAML change
when preparing the resend, which made it look like the feedback was
ignored.
My original intent was:
- resend the eMMC host series as v2 with the PHY driver removed, and
- submit the eMMC PHY as a separate v1 thread.
However, due to the mistake above, this was not communicated clearly and
the versioning caused confusion.
I understand this is frustrating. I will resend with correct versioning,
explicitly list the addressed feedback, and include clear testing details
to avoid any ambiguity.
Thanks for your patience.
Best regards,
TH
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Konrad Dybcio @ 2026-01-12 10:29 UTC (permalink / raw)
To: Luca Weiss, Neil Armstrong, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Alim Akhtar, Avri Altman, Bart Van Assche, Vinod Koul,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy
In-Reply-To: <DFMH8W40TCJ0.XCTHNRJFJE4T@fairphone.com>
On 1/12/26 9:45 AM, Luca Weiss wrote:
> Hi Neil,
>
> On Mon Jan 12, 2026 at 9:26 AM CET, Neil Armstrong wrote:
>> On 1/7/26 14:53, Neil Armstrong wrote:
>>> Hi,
>>>
>>> On 1/7/26 09:05, Luca Weiss wrote:
>>>> Add the nodes for the UFS PHY and UFS host controller, along with the
>>>> ICE used for UFS.
>>>>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/milos.dtsi | 127 +++++++++++++++++++++++++++++++++++-
>>>> 1 file changed, 124 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
>>>> index e1a51d43943f..0f69deabb60c 100644
>>>> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
>>>> @@ -797,9 +797,9 @@ gcc: clock-controller@100000 {
>>>> <&sleep_clk>,
>>>> <0>, /* pcie_0_pipe_clk */
>>>> <0>, /* pcie_1_pipe_clk */
>>>> - <0>, /* ufs_phy_rx_symbol_0_clk */
>>>> - <0>, /* ufs_phy_rx_symbol_1_clk */
>>>> - <0>, /* ufs_phy_tx_symbol_0_clk */
>>>> + <&ufs_mem_phy 0>,
>>>> + <&ufs_mem_phy 1>,
>>>> + <&ufs_mem_phy 2>,
>>>> <0>; /* usb3_phy_wrapper_gcc_usb30_pipe_clk */
>>>> #clock-cells = <1>;
>>>> @@ -1151,6 +1151,127 @@ aggre2_noc: interconnect@1700000 {
>>>> qcom,bcm-voters = <&apps_bcm_voter>;
>>>> };
>>>> + ufs_mem_phy: phy@1d80000 {
>>>> + compatible = "qcom,milos-qmp-ufs-phy";
>>>> + reg = <0x0 0x01d80000 0x0 0x2000>;
>>>> +
>>>> + clocks = <&rpmhcc RPMH_CXO_CLK>,
>>>> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
>>>> + <&tcsr TCSR_UFS_CLKREF_EN>;
>>>> + clock-names = "ref",
>>>> + "ref_aux",
>>>> + "qref";
>>>> +
>>>> + resets = <&ufs_mem_hc 0>;
>>>> + reset-names = "ufsphy";
>>>> +
>>>> + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
>>>> +
>>>> + #clock-cells = <1>;
>>>> + #phy-cells = <0>;
>>>> +
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> + ufs_mem_hc: ufshc@1d84000 {
>>>> + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
>>>> + reg = <0x0 0x01d84000 0x0 0x3000>;
>>>> +
>>>> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
>>>> +
>>>> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
>>>> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
>>>> + <&gcc GCC_UFS_PHY_AHB_CLK>,
>>>> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
>>>> + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
>>>> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>>>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
>>>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
>>>> + clock-names = "core_clk",
>>>> + "bus_aggr_clk",
>>>> + "iface_clk",
>>>> + "core_clk_unipro",
>>>> + "ref_clk",
>>>> + "tx_lane0_sync_clk",
>>>> + "rx_lane0_sync_clk",
>>>> + "rx_lane1_sync_clk";
>>>> +
>>>> + resets = <&gcc GCC_UFS_PHY_BCR>;
>>>> + reset-names = "rst";
>>>> +
>>>> + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>>>> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>>>> + &cnoc_cfg SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
>>>> + interconnect-names = "ufs-ddr",
>>>> + "cpu-ufs";
>>>> +
>>>> + power-domains = <&gcc UFS_PHY_GDSC>;
>>>> + required-opps = <&rpmhpd_opp_nom>;
>>>> +
>>>> + operating-points-v2 = <&ufs_opp_table>;
>>>> +
>>>> + iommus = <&apps_smmu 0x60 0>;
>>>
>>> dma-coherent ?
>
>
> Given that downstream volcano.dtsi has dma-coherent in the ufshc@1d84000
> node, looks like this is missing in my patch.
Seems that way
>>>
>>> and no MCQ support ?
>
> Not sure, I could only find one reference to MCQ on createpoint for
> milos, but given there's no mcq_sqd/mcq_vs reg defined downstream, and I
> couldn't find anything for the same register values in the .FLAT file, I
> don't think Milos has MCQ? Feel free to prove me wrong though.
>
>>
>> So, people just ignore my comment ?
>>
>> Milos is based on SM8550, so it should have dma-coherent, for the MCQ
>> I hope they used the fixed added to the SM8650 UFS controller for MCQ.
>
> Not sure what this should mean regarding MCQ...
This platform doesn't support MCQ
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH V4 3/4] arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
From: Konrad Dybcio @ 2026-01-12 10:36 UTC (permalink / raw)
To: Martin K. Petersen, Pradeep P V K
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, andersson,
konradybcio, taniya.das, dmitry.baryshkov, manivannan.sadhasivam,
linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat, Abel Vesa, Manivannan Sadhasivam
In-Reply-To: <yq14ior5yey.fsf@ca-mkp.ca.oracle.com>
On 1/12/26 3:59 AM, Martin K. Petersen wrote:
>
> Hi Pradeep!
>
>> Add UFS host controller and PHY nodes for x1e80100 SoC.
>
> This does not apply to 6.20/scsi-queue. Please rebase, thanks!
We're taking the dts patches through the qcom tree, that's always been
our intention and the default expectation for cross-subsystem merges for
years (we'll take these ones too)
Do contributors for other subarchs only send you the relevant bits (or
do you grab their dt changes too)? Do you have a specific preference
for any of these settings?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-12 10:35 UTC (permalink / raw)
To: Andrew Lunn
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <0b61c962-9aa1-4275-a40a-220f6d7f1210@lunn.ch>
On Thu, Jan 08, 2026 at 03:47:17PM +0100, Andrew Lunn wrote:
> On Thu, Jan 08, 2026 at 04:22:24PM +0800, Xu Yang wrote:
> > On Wed, Dec 24, 2025 at 02:51:11PM +0100, Andrew Lunn wrote:
> > > On Wed, Dec 24, 2025 at 07:17:16PM +0800, Xu Yang wrote:
> > > > The CR port is a simple 16-bit data/address parallel port that is
> > > > provided for on-chip access to the control registers inside the
> > > > USB 3.0 femtoPHY. While access to these registers is not required
> > > > for normal PHY operation, this interface enables you to access
> > > > some of the PHY’s diagnostic features during normal operation or
> > > > to override some basic PHY control signals.
> > > >
> > > > 3 debugfs files are created to read and write control registers,
> > > > all use hexadecimal format:
> > > > ctrl_reg_base: the register offset to write, or the start offset
> > > > to read.
> > > > ctrl_reg_count: how many continuous registers to be read.
> > > > ctrl_reg_value: read to show the continuous registers value from
> > > > the offset in ctrl_reg_base, to ctrl_reg_base
> > > > + ctrl_reg_count - 1, one line for one register.
> > > > when write, override the register at ctrl_reg_base,
> > > > one time can only change one 16bits register.
> > >
> > > Are the registers openly documented somewhere? Could you include a
> > > link in the commit message.
> >
> > We integrate a SNPS PHY in Soc. So the registers are documented
> > in SNPS doc. Anyway, I can add a link for reference.
>
> Humm, so the registers are defined by a Synopsys databook?
>
> Shouldn't this patch be split into two? The access mechanism to the
> registers is specific to the imx8mq. But the registers themselves
> should be part of the generic SNPS PHY driver which should be shared
> by all devices using this licensed IP?
This patch mainly contain the access mechanism on i.MX Soc, so:
- imx8mq_phy_ctrl_reg_addr()
- imx8mq_phy_ctrl_reg_read()
- imx8mq_phy_ctrl_reg_write()
and debugfs function to show them:
- ctrl_reg_value_show()
- ctrl_reg_value_write()
Do you mean split above into 2 patches? Put the first part into
phy-fsl-imx8mq-usb.c and the second part into a SNPS generic driver?
If so, do you know which generic driver should I use? If no such
driver, can I put them in phy-fsl-imx8mq-usb.c at the beginning?
Thanks,
Xu Yang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-12 10:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <6j2yhzqt6x3k55vrqjrol2k2qrhqmobvwjedkujyet4loyajxa@vy55aajfuvxk>
On Mon, Jan 12, 2026 at 06:35:39PM +0800, Xu Yang wrote:
> On Thu, Jan 08, 2026 at 03:47:17PM +0100, Andrew Lunn wrote:
> > On Thu, Jan 08, 2026 at 04:22:24PM +0800, Xu Yang wrote:
> > > On Wed, Dec 24, 2025 at 02:51:11PM +0100, Andrew Lunn wrote:
> > > > On Wed, Dec 24, 2025 at 07:17:16PM +0800, Xu Yang wrote:
> > > > > The CR port is a simple 16-bit data/address parallel port that is
> > > > > provided for on-chip access to the control registers inside the
> > > > > USB 3.0 femtoPHY. While access to these registers is not required
> > > > > for normal PHY operation, this interface enables you to access
> > > > > some of the PHY’s diagnostic features during normal operation or
> > > > > to override some basic PHY control signals.
> > > > >
> > > > > 3 debugfs files are created to read and write control registers,
> > > > > all use hexadecimal format:
> > > > > ctrl_reg_base: the register offset to write, or the start offset
> > > > > to read.
> > > > > ctrl_reg_count: how many continuous registers to be read.
> > > > > ctrl_reg_value: read to show the continuous registers value from
> > > > > the offset in ctrl_reg_base, to ctrl_reg_base
> > > > > + ctrl_reg_count - 1, one line for one register.
> > > > > when write, override the register at ctrl_reg_base,
> > > > > one time can only change one 16bits register.
> > > >
> > > > Are the registers openly documented somewhere? Could you include a
> > > > link in the commit message.
> > >
> > > We integrate a SNPS PHY in Soc. So the registers are documented
> > > in SNPS doc. Anyway, I can add a link for reference.
> >
> > Humm, so the registers are defined by a Synopsys databook?
> >
> > Shouldn't this patch be split into two? The access mechanism to the
> > registers is specific to the imx8mq. But the registers themselves
> > should be part of the generic SNPS PHY driver which should be shared
> > by all devices using this licensed IP?
>
> This patch mainly contain the access mechanism on i.MX Soc, so:
> - imx8mq_phy_ctrl_reg_addr()
> - imx8mq_phy_ctrl_reg_read()
> - imx8mq_phy_ctrl_reg_write()
>
> and debugfs function to show them:
> - ctrl_reg_value_show()
> - ctrl_reg_value_write()
>
> Do you mean split above into 2 patches? Put the first part into
> phy-fsl-imx8mq-usb.c and the second part into a SNPS generic driver?
>
> If so, do you know which generic driver should I use? If no such
> driver, can I put them in phy-fsl-imx8mq-usb.c at the beginning?
Just found the access mechanism part is also described in SNPS databoot.
So the whole thing should be the part of the generic SNPS PHY.
Thanks,
Xu Yang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/5] PCI: dwc: Add support for retaining link during host init
From: Konrad Dybcio @ 2026-01-12 11:29 UTC (permalink / raw)
To: Bjorn Helgaas, Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <20260109155350.GA546142@bhelgaas>
On 1/9/26 4:53 PM, Bjorn Helgaas wrote:
> On Fri, Jan 09, 2026 at 12:51:07PM +0530, Krishna Chaitanya Chundru wrote:
>> Some platforms keep the PCIe link up across bootloader and kernel
>> handoff. In such cases, reinitializing the root complex is unnecessary
>> if the DWC glue drivers wants to retain the PCIe link.
>>
>> Introduce a link_retain flag in struct dw_pcie_rp to indicate that
>> the link should be preserved. When this flag is set by DWC glue drivers,
>> skip dw_pcie_setup_rc() and only initialize MSI, avoiding redundant
>> configuration steps.
>
> It sounds like this adds an assumption that the bootloader
> initialization is the same as what dw_pcie_setup_rc() would do. This
> assumption also applies to future changes in dw_pcie_setup_rc().
>
> It looks like you mention an issue like this in [PATCH 4/5]; DBI & ATU
> base being different than "HLOS" (whatever that is). This sounds like
FYI, "HLOS" is a Qualcomm term for "High-Level OS".. which is a very
pedantic way to say "OS"
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 2/2] phy: cadence-torrent: Add PCIe + XAUI multilink configuration for 100MHz refclk
From: Andrew Lunn @ 2026-01-12 13:05 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, sjakhade, rogerq,
thomas.richard, linux-phy, linux-kernel, devicetree,
linux-arm-kernel, srk
In-Reply-To: <20260112054636.108027-3-s-vadapalli@ti.com>
On Mon, Jan 12, 2026 at 11:16:31AM +0530, Siddharth Vadapalli wrote:
> From: Swapnil Jakhade <sjakhade@cadence.com>
>
> Add register sequences for PCIe + XAUI multilink configuration for
> 100MHz reference clock.
>
> The register sequences are fetched from a table by indexing entries based
> on unique 'keys' generated by the Bitwise OR defined below:
> REFCLK0_RATE | REFCLK1_RATE | LINK0_TYPE | LINK1_TYPE | SSC_TYPE
>
> As of now, LINK_TYPE is a 3-bit value corresponding to the PHY type.
> With the introduction of TYPE_XAUI, we need a 4-bit value to represent
> the LINK_TYPE as TYPE_XAUI has the numerical value 8. Hence, extend the
> LINKx_MASK macros to 4-bit masks. While at it, extend REFCLKx_MASK macros
> as well to 4-bit masks to support reference clock frequencies that will be
> added in the future.
>
> Adjust the 'LINKx_SHIFT' and the 'REFCLKx_SHIFT' macros to account for
> the aforementioned changes made to the masks.
>
> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
> [s-vadapalli: elaborated on changes made to macros in the commit message]
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Neil Armstrong @ 2026-01-12 13:08 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Alim Akhtar, Avri Altman, Bart Van Assche, Vinod Koul,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy
In-Reply-To: <ccbaff51-d7fa-4b22-8d4e-02bea5d8a529@oss.qualcomm.com>
On 1/12/26 11:29, Konrad Dybcio wrote:
> On 1/12/26 9:45 AM, Luca Weiss wrote:
>> Hi Neil,
>>
>> On Mon Jan 12, 2026 at 9:26 AM CET, Neil Armstrong wrote:
>>> On 1/7/26 14:53, Neil Armstrong wrote:
>>>> Hi,
>>>>
>>>> On 1/7/26 09:05, Luca Weiss wrote:
>>>>> Add the nodes for the UFS PHY and UFS host controller, along with the
>>>>> ICE used for UFS.
>>>>>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/milos.dtsi | 127 +++++++++++++++++++++++++++++++++++-
>>>>> 1 file changed, 124 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
>>>>> index e1a51d43943f..0f69deabb60c 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
>>>>> @@ -797,9 +797,9 @@ gcc: clock-controller@100000 {
>>>>> <&sleep_clk>,
>>>>> <0>, /* pcie_0_pipe_clk */
>>>>> <0>, /* pcie_1_pipe_clk */
>>>>> - <0>, /* ufs_phy_rx_symbol_0_clk */
>>>>> - <0>, /* ufs_phy_rx_symbol_1_clk */
>>>>> - <0>, /* ufs_phy_tx_symbol_0_clk */
>>>>> + <&ufs_mem_phy 0>,
>>>>> + <&ufs_mem_phy 1>,
>>>>> + <&ufs_mem_phy 2>,
>>>>> <0>; /* usb3_phy_wrapper_gcc_usb30_pipe_clk */
>>>>> #clock-cells = <1>;
>>>>> @@ -1151,6 +1151,127 @@ aggre2_noc: interconnect@1700000 {
>>>>> qcom,bcm-voters = <&apps_bcm_voter>;
>>>>> };
>>>>> + ufs_mem_phy: phy@1d80000 {
>>>>> + compatible = "qcom,milos-qmp-ufs-phy";
>>>>> + reg = <0x0 0x01d80000 0x0 0x2000>;
>>>>> +
>>>>> + clocks = <&rpmhcc RPMH_CXO_CLK>,
>>>>> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
>>>>> + <&tcsr TCSR_UFS_CLKREF_EN>;
>>>>> + clock-names = "ref",
>>>>> + "ref_aux",
>>>>> + "qref";
>>>>> +
>>>>> + resets = <&ufs_mem_hc 0>;
>>>>> + reset-names = "ufsphy";
>>>>> +
>>>>> + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
>>>>> +
>>>>> + #clock-cells = <1>;
>>>>> + #phy-cells = <0>;
>>>>> +
>>>>> + status = "disabled";
>>>>> + };
>>>>> +
>>>>> + ufs_mem_hc: ufshc@1d84000 {
>>>>> + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
>>>>> + reg = <0x0 0x01d84000 0x0 0x3000>;
>>>>> +
>>>>> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
>>>>> +
>>>>> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
>>>>> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
>>>>> + <&gcc GCC_UFS_PHY_AHB_CLK>,
>>>>> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
>>>>> + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
>>>>> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>>>>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
>>>>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
>>>>> + clock-names = "core_clk",
>>>>> + "bus_aggr_clk",
>>>>> + "iface_clk",
>>>>> + "core_clk_unipro",
>>>>> + "ref_clk",
>>>>> + "tx_lane0_sync_clk",
>>>>> + "rx_lane0_sync_clk",
>>>>> + "rx_lane1_sync_clk";
>>>>> +
>>>>> + resets = <&gcc GCC_UFS_PHY_BCR>;
>>>>> + reset-names = "rst";
>>>>> +
>>>>> + interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
>>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>>>>> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>>>>> + &cnoc_cfg SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
>>>>> + interconnect-names = "ufs-ddr",
>>>>> + "cpu-ufs";
>>>>> +
>>>>> + power-domains = <&gcc UFS_PHY_GDSC>;
>>>>> + required-opps = <&rpmhpd_opp_nom>;
>>>>> +
>>>>> + operating-points-v2 = <&ufs_opp_table>;
>>>>> +
>>>>> + iommus = <&apps_smmu 0x60 0>;
>>>>
>>>> dma-coherent ?
>>
>>
>> Given that downstream volcano.dtsi has dma-coherent in the ufshc@1d84000
>> node, looks like this is missing in my patch.
>
> Seems that way
>
>>>>
>>>> and no MCQ support ?
>>
>> Not sure, I could only find one reference to MCQ on createpoint for
>> milos, but given there's no mcq_sqd/mcq_vs reg defined downstream, and I
>> couldn't find anything for the same register values in the .FLAT file, I
>> don't think Milos has MCQ? Feel free to prove me wrong though.
>>
>>>
>>> So, people just ignore my comment ?
>>>
>>> Milos is based on SM8550, so it should have dma-coherent, for the MCQ
>>> I hope they used the fixed added to the SM8650 UFS controller for MCQ.
>>
>> Not sure what this should mean regarding MCQ...
>
> This platform doesn't support MCQ
Ack, it must be same situation as Kailua then,
Thanks
Neil
>
> Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 0/6] Enable UFS support on Milos
From: Luca Weiss @ 2026-01-12 13:53 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Luca Weiss, Krzysztof Kozlowski, Abel Vesa, Konrad Dybcio,
Dmitry Baryshkov
Add inline-crypto-engine and UFS bindings & driver parts, then add them
to milos dtsi and enable the UFS storage on Fairphone (Gen. 6).
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Add missing dma-coherent in milos.dtsi (Neil)
- Pick up tags
- Link to v1: https://lore.kernel.org/r/20260107-milos-ufs-v1-0-6982ab20d0ac@fairphone.com
---
Luca Weiss (6):
dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE
scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Milos QMP UFS PHY
phy: qcom-qmp-ufs: Add Milos support
arm64: dts: qcom: milos: Add UFS nodes
arm64: dts: qcom: milos-fairphone-fp6: Enable UFS
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
.../bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 +
.../devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml | 2 +
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 18 +++
arch/arm64/boot/dts/qcom/milos.dtsi | 129 ++++++++++++++++++++-
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 96 +++++++++++++++
6 files changed, 245 insertions(+), 3 deletions(-)
---
base-commit: ef1c7b875741bef0ff37ae8ab8a9aaf407dc141c
change-id: 20260106-milos-ufs-7bfbd774ca7c
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox