* [PATCH v1 phy-next 5/8] soc: fsl: guts: make fsl_soc_data available after fsl_guts_init()
From: Vladimir Oltean @ 2026-06-11 19:39 UTC (permalink / raw)
To: linux-phy
Cc: devicetree, linuxppc-dev, linux-arm-kernel, Ioana Ciornei,
Vinod Koul, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel
In-Reply-To: <20260611193940.44416-1-vladimir.oltean@nxp.com>
In a future change, struct fsl_soc_data will be extended with methods
for performing RCW override.
Since this will be performed from a calling context outside
fsl_guts_init(), we need to keep track of the soc_data that we determine
at fsl_guts_init() time, so we can reference it later.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/soc/fsl/guts.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 1494b545bbb4..9f2aff07a274 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -138,6 +138,7 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
static struct fsl_soc_guts {
struct ccsr_guts __iomem *dcfg_ccsr;
+ const struct fsl_soc_data *data;
bool little_endian;
u32 svr;
} soc;
@@ -234,7 +235,6 @@ static int __init fsl_guts_init(void)
struct soc_device_attribute *soc_dev_attr;
static struct soc_device *soc_dev;
const struct fsl_soc_die_attr *soc_die;
- const struct fsl_soc_data *soc_data;
const struct of_device_id *match;
struct device_node *np;
u64 soc_uid = 0;
@@ -243,7 +243,7 @@ static int __init fsl_guts_init(void)
np = of_find_matching_node_and_match(NULL, fsl_guts_of_match, &match);
if (!np)
return 0;
- soc_data = match->data;
+ soc.data = match->data;
soc.dcfg_ccsr = of_iomap(np, DCFG_CCSR);
if (!soc.dcfg_ccsr) {
@@ -283,9 +283,9 @@ static int __init fsl_guts_init(void)
if (!soc_dev_attr->revision)
goto err_nomem;
- if (soc_data)
- soc_uid = fsl_guts_get_soc_uid(soc_data->sfp_compat,
- soc_data->uid_offset);
+ if (soc.data)
+ soc_uid = fsl_guts_get_soc_uid(soc.data->sfp_compat,
+ soc.data->uid_offset);
if (soc_uid)
soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX",
soc_uid);
--
2.34.1
^ permalink raw reply related
* [PATCH v1 phy-next 6/8] dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region
From: Vladimir Oltean @ 2026-06-11 19:39 UTC (permalink / raw)
To: linux-phy
Cc: devicetree, linuxppc-dev, linux-arm-kernel, Ioana Ciornei,
Vinod Koul, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel, Conor Dooley, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260611193940.44416-1-vladimir.oltean@nxp.com>
In Layerscape (Arm) and QorIQ (PowerPC) devices, hardware peripherals
are accessed by the CPU through a portion of the SoC address space
called CCSR ("Configuration, Control, and Status Registers"). All
hardware IP blocks have their registers mapped here, and the Device
Configuration block makes no exception.
However, there exists a secondary range of the address space named DCSR
("Debug Control and Status Registers") which, like CCSR, also holds
registers of hardware IP blocks, except the DCSR contents is hidden in
all public reference manuals.
The intention of the CCSR/DCSR split, to the best of my knowledge, was
to place the functionality that is too low level for normal use, and
which is necessary only for debug, in a completely separate address
space which can be hidden.
A use case has appeared where networking SerDes lanes need to be
reconfigured at runtime for a different protocol (example: 10GBase-R to
SGMII), and the architecture of the SoCs does not normally permit that.
The Reset Configuration Word (RCW) is a data structure read by the SoC
preboot loader (PBL) which contains stuff like pinmuxing and SerDes
protocol mapping for each lane.
The RCW that the PBL has loaded is visible in the DCFG block's normal
status registers (from CCSR), as read only. Turns out, the RCW is also
mapped in the DCFG's shadow register map (in DCSR), in a write-only
form. Writing to the RCW registers from the DCFG's DCSR space to change
what the PBL has loaded is called "RCW override".
It has been validated that the RCW override procedure is necessary to
reconfigure the networking data path when a SerDes lane performs a major
protocol change. It changes some internal muxes which connect the PCS to
either the 10G MAC or to the 1G MAC.
Defining the DCSR area of the DCFG as a secondary 'reg' array element
allows operating systems to perform RCW overrides. Since it is
introduced late in the binding's lifetime, it is optional. It can be
identified by name, but also by index (first 'reg' is CCSR).
Note that while all SoCs should have a DCFG register block in DCSR, we
only need to expose it for the SoCs where the RCW override procedure is
known to be needed and has been validated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: Conor Dooley <conor@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
---
.../bindings/soc/fsl/fsl,layerscape-dcfg.yaml | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
index 3fb0534ea597..fc14fd0bf84b 100644
--- a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
@@ -36,7 +36,20 @@ properties:
- const: simple-mfd
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description:
+ Customer-visible DCFG register map from CCSR address space
+ (Configuration, Control and Status Registers)
+ - description:
+ Customer-hidden DCFG register map from DCSR address space
+ (Debug Control and Status Registers)
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: dcfg_ccsr
+ - const: dcfg_dcsr
little-endian: true
big-endian: true
--
2.34.1
^ permalink raw reply related
* [PATCH v1 phy-next 7/8] soc: fsl: guts: implement the RCW override procedure
From: Vladimir Oltean @ 2026-06-11 19:39 UTC (permalink / raw)
To: linux-phy
Cc: devicetree, linuxppc-dev, linux-arm-kernel, Ioana Ciornei,
Vinod Koul, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel, Conor Dooley, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260611193940.44416-1-vladimir.oltean@nxp.com>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Add support for the RCW override procedure which enables runtime
reconfiguration of the protocol running on a SerDes lane. The procedure
is done through the DCFG DCSR space which now can be defined as the
second memory region of the guts DT node.
Support is added on the following SoCs: LS1046A, LS1088A, LS2088A.
The procedure is exported to the "client" driver - the Lynx10G SerDes
PHY driver - through the following functions:
- fsl_guts_lane_init() used to notify the initial / boot time lane mode
running on a SerDes lane.
- fsl_guts_lane_validate() used to validate that changing the protocol
on a specific lane is supported.
- fsl_guts_lane_set_mode() which can be used to request the RCW
procedure be executed for a specific lane.
Since the RCW override procedure is different depending on the SoC, the
private fsl_soc_data structure is updated with two new per SoC callbacks
(.serdes_get_rcw_override() and .serdes_init_rcwcr()) which get used
from the generic fsl_guts_lane_set_mode() function. These two callbacks
hide all the SoC specific register offsets, masks and values so that the
_set_mode() procedure is straightforward.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: Conor Dooley <conor@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
---
drivers/soc/fsl/guts.c | 286 ++++++++++++++++++++++++++++++++++++++-
include/linux/fsl/guts.h | 20 ++-
2 files changed, 299 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 9f2aff07a274..23ec5750080c 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -15,6 +15,30 @@
#include <linux/fsl/guts.h>
#define DCFG_CCSR 0
+#define DCFG_DCSR 1
+
+#define MAX_NUM_LANES 8
+#define MAX_NUM_SERDES 2
+
+#define LS1088A_RCWSR29_SRDS_PRTCL_S1_LNn(lane) \
+ GENMASK(19 + 4 * (3 - lane), 16 + 4 * (3 - lane))
+#define LS1088A_RCWSR30_SRDS_PRTCL_S2_LNn(lane) \
+ GENMASK(3 + 4 * (3 - lane), 4 * (3 - lane))
+
+#define LS1046A_RCWSR5_SRDS_PRTCL_S1(lane) \
+ GENMASK(19 + 4 * (lane), 16 + 4 * (lane))
+#define SRDS_PRTCL_NONE 0
+#define SRDS_PRTCL_XFI 1
+#define SRDS_PRTCL_2500BASEX 2
+#define SRDS_PRTCL_100BASEX_SGMII 3
+#define SRDS_PRTCL_QSGMII 4
+#define SRDS_PRTCL_PCIE 5
+
+#define LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1 BIT(14)
+#define LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(lane) BIT(6 + (7 - (lane)))
+#define LS2088A_RCWSR30_SRDS_CLK_SEL_MSK GENMASK(13, 6)
+#define SRDS_CLK_SEL_XGMII 1
+#define SRDS_CLK_SEL_GMII 0
struct fsl_soc_die_attr {
char *die;
@@ -22,9 +46,19 @@ struct fsl_soc_die_attr {
u32 mask;
};
+struct fsl_soc_serdes_rcw_override {
+ int offset;
+ int mask;
+ int val;
+};
+
struct fsl_soc_data {
const char *sfp_compat;
u32 uid_offset;
+ int (*serdes_get_rcw_override)(int index, int lane,
+ enum lynx_lane_mode lane_mode,
+ struct fsl_soc_serdes_rcw_override *override);
+ void (*serdes_init_rcwcr)(int index);
};
enum qoriq_die {
@@ -138,9 +172,13 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
static struct fsl_soc_guts {
struct ccsr_guts __iomem *dcfg_ccsr;
+ struct ccsr_guts __iomem *dcfg_dcsr;
const struct fsl_soc_data *data;
bool little_endian;
u32 svr;
+ enum lynx_lane_mode lane_mode[MAX_NUM_SERDES][MAX_NUM_LANES];
+ bool rcwcr_init_done;
+ spinlock_t rcwcr_lock; /* serializes concurrent writes to the RCWCR */
} soc;
static unsigned int fsl_guts_read(const void __iomem *reg)
@@ -151,6 +189,28 @@ static unsigned int fsl_guts_read(const void __iomem *reg)
return ioread32be(reg);
}
+static void fsl_guts_write(void __iomem *reg, u32 val)
+{
+ if (soc.little_endian)
+ iowrite32(val, reg);
+ else
+ iowrite32be(val, reg);
+}
+
+/* Some fields of the Reset Configuration Word (RCW) can be overridden at
+ * runtime by writing to the RCWCRn registers contained within the DCSR space
+ * of the Device Configuration (DCFG) block. The layout of the RCWCRn registers
+ * is identical with the read-only RCWSRn from the CCSR space.
+ */
+static void fsl_guts_rmw(int offset, u32 val, u32 mask)
+{
+ u32 tmp = fsl_guts_read(&soc.dcfg_ccsr->rcwsr[offset]);
+
+ tmp &= ~mask;
+ tmp |= val;
+ fsl_guts_write(&soc.dcfg_dcsr->rcwcr[offset], tmp);
+}
+
static bool fsl_soc_die_match_one(u32 svr, const struct fsl_soc_die_attr *match)
{
return match->svr == (svr & match->mask);
@@ -167,6 +227,97 @@ static const struct fsl_soc_die_attr *fsl_soc_die_match(
return NULL;
}
+static int
+fsl_guts_serdes_get_rcw_override(int serdes_idx, int lane,
+ enum lynx_lane_mode lane_mode,
+ struct fsl_soc_serdes_rcw_override *override)
+{
+ if ((!fsl_soc_die_match_one(soc.svr, &fsl_soc_die[DIE_LS1088A]) &&
+ !fsl_soc_die_match_one(soc.svr, &fsl_soc_die[DIE_LS2088A]) &&
+ !fsl_soc_die_match_one(soc.svr, &fsl_soc_die[DIE_LS1046A])) ||
+ !soc.data || !soc.data->serdes_get_rcw_override) {
+ pr_debug("RCW override not implemented for SoC\n");
+ return -EINVAL;
+ }
+
+ if (!soc.dcfg_dcsr) {
+ pr_debug("Device tree does not define DCFG_DCSR region necessary for RCW override\n");
+ return -EINVAL;
+ }
+
+ return soc.data->serdes_get_rcw_override(serdes_idx, lane, lane_mode,
+ override);
+}
+
+/**
+ * fsl_guts_lane_init() - Notify guts module of SerDes lane configuration
+ * @serdes_idx: zero-based SerDes block index
+ * @lane: zero-based lane index within SerDes
+ * @lane_mode: initial / boot time SerDes protocol for lane
+ *
+ * On the LS208xA SoC, the RCW override procedure needs to be aware of all link
+ * modes which are configured on a SerDes block.
+ */
+void fsl_guts_lane_init(int serdes_idx, int lane, enum lynx_lane_mode lane_mode)
+{
+ soc.lane_mode[serdes_idx - 1][lane] = lane_mode;
+}
+EXPORT_SYMBOL_NS_GPL(fsl_guts_lane_init, "FSL_GUTS");
+
+/**
+ * fsl_guts_lane_validate() - Validate that SerDes protocol is implemented and
+ * supported on current SoC
+ * @serdes_idx: zero-based SerDes block index
+ * @lane: zero-based lane index within SerDes
+ * @lane_mode: requested SerDes protocol
+ *
+ * Should be called before actually requesting the RCW override procedure to be
+ * applied using %fsl_guts_lane_set_mode()
+ *
+ * Return: 0 if RCW override to protocol is possible, negative error otherwise
+ */
+int fsl_guts_lane_validate(int serdes_idx, int lane, enum lynx_lane_mode lane_mode)
+{
+ struct fsl_soc_serdes_rcw_override override;
+
+ return fsl_guts_serdes_get_rcw_override(serdes_idx, lane, lane_mode,
+ &override);
+}
+EXPORT_SYMBOL_NS_GPL(fsl_guts_lane_validate, "FSL_GUTS");
+
+/**
+ * fsl_guts_lane_set_mode() - apply RCW override procedure for SerDes lane
+ * @serdes_idx: zero-based SerDes block index
+ * @lane: zero-based lane index within SerDes
+ * @lane_mode: requested SerDes protocol
+ *
+ * Return: 0 on success, negative error otherwise
+ */
+int fsl_guts_lane_set_mode(int serdes_idx, int lane, enum lynx_lane_mode lane_mode)
+{
+ struct fsl_soc_serdes_rcw_override override;
+ int err;
+
+ err = fsl_guts_serdes_get_rcw_override(serdes_idx, lane, lane_mode,
+ &override);
+ if (err)
+ return err;
+
+ spin_lock(&soc.rcwcr_lock);
+
+ if (soc.data->serdes_init_rcwcr)
+ soc.data->serdes_init_rcwcr(serdes_idx);
+
+ fsl_guts_rmw(override.offset, override.val << __bf_shf(override.mask),
+ override.mask);
+ soc.lane_mode[serdes_idx - 1][lane] = lane_mode;
+
+ spin_unlock(&soc.rcwcr_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_NS_GPL(fsl_guts_lane_set_mode, "FSL_GUTS");
+
static u64 fsl_guts_get_soc_uid(const char *compat, unsigned int offset)
{
struct device_node *np;
@@ -193,6 +344,128 @@ static u64 fsl_guts_get_soc_uid(const char *compat, unsigned int offset)
return uid;
}
+static int ls1088a_serdes_get_rcw_override(int index, int lane,
+ enum lynx_lane_mode lane_mode,
+ struct fsl_soc_serdes_rcw_override *override)
+{
+ /* The RCW override procedure has to write to different registers
+ * depending on the SerDes block index.
+ */
+ switch (index) {
+ case 1:
+ override->offset = 28;
+ override->mask = LS1088A_RCWSR29_SRDS_PRTCL_S1_LNn(lane);
+ break;
+ case 2:
+ override->offset = 29;
+ override->mask = LS1088A_RCWSR30_SRDS_PRTCL_S2_LNn(lane);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (lynx_lane_mode_uses_xgmii_mac(lane_mode))
+ override->val = SRDS_PRTCL_XFI;
+ else if (lynx_lane_mode_uses_gmii_mac(lane_mode))
+ override->val = SRDS_PRTCL_100BASEX_SGMII;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static int ls1046a_serdes_get_rcw_override(int index, int lane,
+ enum lynx_lane_mode lane_mode,
+ struct fsl_soc_serdes_rcw_override *override)
+{
+ /* The RCW override procedure has to write to different registers
+ * depending on the SerDes block index.
+ */
+ switch (index) {
+ case 1:
+ override->offset = 4;
+ override->mask = LS1046A_RCWSR5_SRDS_PRTCL_S1(lane);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (lynx_lane_mode_uses_xgmii_mac(lane_mode))
+ override->val = SRDS_PRTCL_XFI;
+ else if (lynx_lane_mode_uses_gmii_mac(lane_mode))
+ override->val = SRDS_PRTCL_100BASEX_SGMII;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static int ls2088a_serdes_get_rcw_override(int index, int lane,
+ enum lynx_lane_mode lane_mode,
+ struct fsl_soc_serdes_rcw_override *override)
+{
+ switch (index) {
+ case 1:
+ override->offset = 29;
+ override->mask = LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(lane);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (lynx_lane_mode_uses_xgmii_mac(lane_mode))
+ override->val = SRDS_CLK_SEL_XGMII;
+ else if (lynx_lane_mode_uses_gmii_mac(lane_mode))
+ override->val = SRDS_CLK_SEL_GMII;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static void ls2088a_serdes_init_rcwcr(int serdes_idx)
+{
+ u32 reg;
+ int i;
+
+ if (serdes_idx != 1)
+ return;
+ if (soc.rcwcr_init_done)
+ return;
+
+ /* SRDS_CLK_EN_SEL_XGMII_S1: SerDes Clock Enable Select XGMII Serdes 1:
+ * Enables to select GMII/XGMII clock according to
+ * SRDS_CLK_SEL_XGMII_Ln_S1
+ */
+ reg = LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1;
+
+ /* We need to configure the initial state of all lanes for
+ * the SerDes block #1
+ */
+ for (i = 0; i < MAX_NUM_LANES; i++)
+ if (lynx_lane_mode_uses_xgmii_mac(soc.lane_mode[serdes_idx - 1][i]))
+ reg |= LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(i);
+
+ fsl_guts_rmw(29, reg,
+ LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1 |
+ LS2088A_RCWSR30_SRDS_CLK_SEL_MSK);
+
+ soc.rcwcr_init_done = true;
+}
+
+static const struct fsl_soc_data ls1088a_data = {
+ .serdes_get_rcw_override = ls1088a_serdes_get_rcw_override,
+};
+
+static const struct fsl_soc_data ls1046a_data = {
+ .serdes_get_rcw_override = ls1046a_serdes_get_rcw_override,
+};
+
+static const struct fsl_soc_data ls2088a_data = {
+ .serdes_get_rcw_override = ls2088a_serdes_get_rcw_override,
+ .serdes_init_rcwcr = ls2088a_serdes_init_rcwcr,
+};
+
static const struct fsl_soc_data ls1028a_data = {
.sfp_compat = "fsl,ls1028a-sfp",
.uid_offset = 0x21c,
@@ -221,10 +494,10 @@ static const struct of_device_id fsl_guts_of_match[] = {
{ .compatible = "fsl,mpc8572-guts", },
{ .compatible = "fsl,ls1021a-dcfg", },
{ .compatible = "fsl,ls1043a-dcfg", },
- { .compatible = "fsl,ls2080a-dcfg", },
- { .compatible = "fsl,ls1088a-dcfg", },
+ { .compatible = "fsl,ls2080a-dcfg", .data = &ls2088a_data},
+ { .compatible = "fsl,ls1088a-dcfg", .data = &ls1088a_data},
{ .compatible = "fsl,ls1012a-dcfg", },
- { .compatible = "fsl,ls1046a-dcfg", },
+ { .compatible = "fsl,ls1046a-dcfg", .data = &ls1046a_data},
{ .compatible = "fsl,lx2160a-dcfg", },
{ .compatible = "fsl,ls1028a-dcfg", .data = &ls1028a_data},
{}
@@ -250,6 +523,8 @@ static int __init fsl_guts_init(void)
of_node_put(np);
return -ENOMEM;
}
+ /* DCFG_DCSR is optional */
+ soc.dcfg_dcsr = of_iomap(np, DCFG_DCSR);
soc.little_endian = of_property_read_bool(np, "little-endian");
soc.svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
@@ -296,6 +571,8 @@ static int __init fsl_guts_init(void)
goto err;
}
+ spin_lock_init(&soc.rcwcr_lock);
+
pr_info("Machine: %s\n", soc_dev_attr->machine);
pr_info("SoC family: %s\n", soc_dev_attr->family);
pr_info("SoC ID: %s, Revision: %s\n",
@@ -305,7 +582,8 @@ static int __init fsl_guts_init(void)
err_nomem:
ret = -ENOMEM;
-
+ if (soc.dcfg_dcsr)
+ iounmap(soc.dcfg_dcsr);
iounmap(soc.dcfg_ccsr);
err:
kfree(soc_dev_attr->family);
diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
index fdb55ca47a4f..176842531241 100644
--- a/include/linux/fsl/guts.h
+++ b/include/linux/fsl/guts.h
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/io.h>
+#include <soc/fsl/phy-fsl-lynx.h>
/*
* Global Utility Registers.
@@ -91,9 +92,15 @@ struct ccsr_guts {
u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x100 - 0xc4];
- u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
- There are 16 registers */
- u8 res140[0x224 - 0x140];
+ /* 0x.0100 - read-only Reset Configuration Word Status registers in
+ * CCSR, or write-only Reset Configuration Word Control registers in
+ * DCSR. In both cases there are 32 registers.
+ */
+ union {
+ u32 rcwsr[32];
+ u32 rcwcr[32];
+ };
+ u8 res180[0x224 - 0x180];
u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
@@ -131,6 +138,13 @@ struct ccsr_guts {
u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+void fsl_guts_lane_init(int serdes_idx, int lane,
+ enum lynx_lane_mode lane_mode);
+int fsl_guts_lane_validate(int serdes_idx, int lane,
+ enum lynx_lane_mode lane_mode);
+int fsl_guts_lane_set_mode(int serdes_idx, int lane,
+ enum lynx_lane_mode lane_mode);
+
/* Alternate function signal multiplex control */
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
--
2.34.1
^ permalink raw reply related
* [PATCH v1 phy-next 8/8] phy: lynx-10g: use RCW override procedure for dynamic protocol change
From: Vladimir Oltean @ 2026-06-11 19:39 UTC (permalink / raw)
To: linux-phy
Cc: devicetree, linuxppc-dev, linux-arm-kernel, Ioana Ciornei,
Vinod Koul, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel
In-Reply-To: <20260611193940.44416-1-vladimir.oltean@nxp.com>
Up until this patch, the only protocol change supported was between
1000Base-X/SGMII and 2500Base-X. The others require an RCW override
procedure which was lacking.
Since now the guts driver provides the means of applying this procedure,
make use of it and remove any comment which mentioned the limitation.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/phy/freescale/Kconfig | 1 +
drivers/phy/freescale/phy-fsl-lynx-10g.c | 24 +++++++++++++++---------
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 5bf3864fbe64..d4e189fffbf8 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -58,6 +58,7 @@ config PHY_FSL_LYNX_10G
tristate "Freescale Layerscape Lynx 10G SerDes PHY support"
depends on OF
depends on ARCH_LAYERSCAPE || COMPILE_TEST
+ select FSL_GUTS
select GENERIC_PHY
select PHY_FSL_LYNX_CORE
help
diff --git a/drivers/phy/freescale/phy-fsl-lynx-10g.c b/drivers/phy/freescale/phy-fsl-lynx-10g.c
index 38def160ef1a..5ece7889aed7 100644
--- a/drivers/phy/freescale/phy-fsl-lynx-10g.c
+++ b/drivers/phy/freescale/phy-fsl-lynx-10g.c
@@ -8,6 +8,7 @@
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/workqueue.h>
+#include <linux/fsl/guts.h>
#include "phy-fsl-lynx-core.h"
@@ -446,6 +447,7 @@ static void lynx_10g_lane_read_configuration(struct lynx_lane *lane)
}
lynx_10g_backup_pccr_val(lane);
+ fsl_guts_lane_init(priv->info->index, lane->id, lane->mode);
}
static int ls1028a_get_pccr(enum lynx_lane_mode lane_mode, int lane,
@@ -1167,14 +1169,7 @@ static bool lynx_10g_lane_mode_needs_rcw_override(struct lynx_lane *lane,
/* Major protocol changes, which involve changing the PCS connection to
* the GMII MAC with the one to the XGMII MAC, require an RCW override
- * procedure to reconfigure an internal mux, as documented here:
- * https://lore.kernel.org/linux-phy/20230810102631.bvozjer3t67r67iy@skbuf/
- * This is SoC-specific, and not yet implemented in drivers/soc/fsl/guts.c.
- *
- * So the supported set of protocols depends on the initial lane mode.
- *
- * Minor protocol changes (SGMII <-> 1000Base-X <-> 2500Base-X or
- * 10GBase-R <-> USXGMII) are supported.
+ * procedure to reconfigure an internal mux.
*/
if ((lynx_lane_mode_uses_gmii_mac(curr) &&
lynx_lane_mode_uses_xgmii_mac(new)) ||
@@ -1189,6 +1184,7 @@ static int lynx_10g_validate(struct phy *phy, enum phy_mode mode, int submode,
union phy_configure_opts *opts)
{
struct lynx_lane *lane = phy_get_drvdata(phy);
+ struct lynx_priv *priv = lane->priv;
enum lynx_lane_mode lane_mode;
int err;
@@ -1197,7 +1193,8 @@ static int lynx_10g_validate(struct phy *phy, enum phy_mode mode, int submode,
return err;
if (lynx_10g_lane_mode_needs_rcw_override(lane, lane_mode))
- return -EINVAL;
+ return fsl_guts_lane_validate(priv->info->index, lane->id,
+ lane_mode);
return 0;
}
@@ -1205,6 +1202,7 @@ static int lynx_10g_validate(struct phy *phy, enum phy_mode mode, int submode,
static int lynx_10g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
{
struct lynx_lane *lane = phy_get_drvdata(phy);
+ struct lynx_priv *priv = lane->priv;
bool powered_up = lane->powered_up;
enum lynx_lane_mode lane_mode;
int err;
@@ -1225,6 +1223,13 @@ static int lynx_10g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
if (powered_up)
lynx_10g_lane_halt(phy);
+ if (lynx_10g_lane_mode_needs_rcw_override(lane, lane_mode)) {
+ err = fsl_guts_lane_set_mode(priv->info->index, lane->id,
+ lane_mode);
+ if (err)
+ goto out;
+ }
+
err = lynx_10g_lane_disable_pcvt(lane, lane->mode);
if (err)
goto out;
@@ -1314,6 +1319,7 @@ static struct platform_driver lynx_10g_driver = {
};
module_platform_driver(lynx_10g_driver);
+MODULE_IMPORT_NS("FSL_GUTS");
MODULE_IMPORT_NS("PHY_FSL_LYNX");
MODULE_AUTHOR("Ioana Ciornei <ioana.ciornei@nxp.com>");
MODULE_AUTHOR("Vladimir Oltean <vladimir.oltean@nxp.com>");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] iio: adc: add Axiado SARADC driver
From: Andy Shevchenko @ 2026-06-11 19:41 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260611-axiado-ax3000-ax3005-saradc-v2-2-913c9de7c64c@axiado.com>
On Thu, Jun 11, 2026 at 02:37:44AM -0700, Petar Stepanovic wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
>
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.
Tried to not overlap Jonathan's review.
...
> +struct axiado_saradc {
> + void __iomem *regs;
> + struct clk *clk;
> + unsigned long clk_rate;
> + int vref_uV;
> + struct mutex lock; /* Serializes ADC conversions. */
> +};
Is `pahole` satisfied with the chosen layout?
...
> +static int axiado_saradc_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + struct axiado_saradc *info = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = axiado_saradc_conversion(info, chan, val);
> + return ret ? ret : IIO_VAL_INT;
Better to use plain if.
if (ret)
return ret;
return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = info->vref_uV / 1000;
1000 --> (MICRO / MILLI) ?
(yes, with parentheses)
> + *val2 = AX_RESOLUTION_BITS;
> + return IIO_VAL_FRACTIONAL_LOG2;
> +
> + default:
> + return -EINVAL;
> + }
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: stm32: lxa: change stdout-path baud rate from 9600 to 115200
From: David Laight @ 2026-06-11 19:43 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde, Alexandre Torgue, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, kernel
In-Reply-To: <20260611-lxa-stdout-path-baudrate-v1-0-59b60a5069ff@pengutronix.de>
On Thu, 11 Jun 2026 20:12:32 +0200
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> The LXA boards are the only STM32 boards that set stdout-path = &uart*
> instead of explicitly specifying a baud rate.
>
> This would mean the default of 9600 is used, but it goes unnoticed when
> booting normally as barebox fixes up a console= line that includes a
> baud rate.
>
> When EFI booting GRUB however, GRUB will not pass along the console=
> line and thus the board ends up with a 9600 baud Linux console,
> confusing users.
Is it possible to determine the current baud rate (by reading the hardware
register) and default to that value.
Then if grub has initialised the uart the kernel will use the same
baud rate.
David
>
> This series fixes this. As the device trees were added at different
> times, they are fixed each in a separate commit with its own Fixes: tag.
>
> ---
> Ahmad Fatoum (3):
> ARM: dts: stm32: lxa-mc1: change stdout-path baud rate from 9600 to 115200
> ARM: dts: stm32: lxa-tac: change stdout-path baud rate from 9600 to 115200
> ARM: dts: stm32: fairytux2: change stdout-path baud rate from 9600 to 115200
>
> arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi | 2 +-
> arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts | 2 +-
> arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
> ---
> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> change-id: 20260611-lxa-stdout-path-baudrate-7cf454cdae07
>
> Best regards,
> --
> Ahmad Fatoum <a.fatoum@pengutronix.de>
>
>
^ permalink raw reply
* Re: [PATCH v7 6/6] coco: guest: arm64: Replace dummy CCA device with sysfs ABI
From: Dan Williams (nvidia) @ 2026-06-11 19:45 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-coco, linux-arm-kernel,
linux-kernel
Cc: Aneesh Kumar K.V (Arm), Catalin Marinas, Greg KH, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Steven Price, Suzuki K Poulose, Andre Przywara
In-Reply-To: <20260611130429.295516-7-aneesh.kumar@kernel.org>
Aneesh Kumar K.V (Arm) wrote:
> The SMCCC firmware driver now creates the arm-smccc platform device and
> instantiates the CCA RSI auxiliary devices once the RSI ABI is discovered.
> The arm64-specific arm-cca-dev platform device stub is therefore no longer
> needed.
>
> However, userspace has used the arm-cca-dev platform device to detect Arm
> CCA Realm guests [1]. Removing it without a replacement would break that
> detection and would also leave userspace depending on kernel device-model
> details.
>
> Add /sys/firmware/cca/realm_guest as a stable, architecture-provided ABI
> for detecting whether the kernel is running as an Arm CCA Realm guest. The
> file returns 1 in Realm world and 0 otherwise, similar to the existing s390
> /sys/firmware/uv/prot_virt_guest interface for protected virtualization
> guests.
>
> Remove the dummy arm-cca-dev registration now that userspace has a
> dedicated CCA Realm guest indicator, and document the new ABI in
> Documentation/ABI/testing/sysfs-firmware-cca.
I would have expected an attribute in /sys/class/tsm/tsmX to be the
common protected guest indicator. Then, if you need to distinguish the
architecture that registered that tsm it would be in the name of the
parent device for the tsm class device.
That also gives you the property that a uevent has signalled the arrival
of tsm guest services. Otherwise, userspace still needs some custom
device-model details to know when it can start issuing tsm requests.
Is auxilliary device arrival too late in the flow for what systemd
needs?
^ permalink raw reply
* [PATCH v6 1/3] PCI: rockchip-ep: do not attempt 5.0 GT/s retraining
From: Geraldo Nascimento @ 2026-06-11 20:03 UTC (permalink / raw)
To: Shawn Lin, Dragan Simic
Cc: linux-rockchip, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, linux-pci,
linux-arm-kernel, linux-kernel, Geraldo Nascimento
In-Reply-To: <cover.1781207474.git.geraldogabriel@gmail.com>
Drop the 5.0 GT/s Link Speed retraining code block from Rockchip PCIe
EP driver. The reason is that Shawn Lin from Rockchip has reiterated
that there may be danger of "catastrophic failure" in using their PCIe
with 5.0 GT/s speeds.
While Rockchip has done so informally without issuing a proper errata,
and the particulars are thus unknown, this may cause data loss or
worse.
This change is corroborated by RK3399 official datasheet [1], which
states maximum link speed for this platform is 2.5 GT/s.
[1] https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf
Link: https://lore.kernel.org/all/ffd05070-9879-4468-94e3-b88968b4c21b@rock-chips.com/
Cc: stable@vger.kernel.org
Reported-by: Dragan Simic <dsimic@manjaro.org>
Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
---
drivers/pci/controller/pcie-rockchip-ep.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c
index 799461335762e..9ebc227a1ef84 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -553,19 +553,6 @@ static void rockchip_pcie_ep_link_training(struct work_struct *work)
if (ret)
goto again;
- /*
- * Check the current speed: if gen2 speed was requested and we are not
- * at gen2 speed yet, retrain again for gen2.
- */
- val = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
- if (!PCIE_LINK_IS_GEN2(val) && rockchip->link_gen == 2) {
- /* Enable retrain for gen2 */
- rockchip_pcie_ep_retrain_link(rockchip);
- readl_poll_timeout(rockchip->apb_base + PCIE_CORE_CTRL,
- val, PCIE_LINK_IS_GEN2(val), 50,
- LINK_TRAIN_TIMEOUT);
- }
-
/* Check again that the link is up */
if (!rockchip_pcie_ep_link_up(rockchip))
goto again;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Andy Shevchenko @ 2026-06-11 18:54 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Sakari Ailus, Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <airY6IMz2KFz_z9j@kuha>
On Thu, Jun 11, 2026 at 06:48:56PM +0300, Heikki Krogerus wrote:
> On Thu, Jun 11, 2026 at 11:35:13AM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jun 11, 2026 at 10:37 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
> > > > On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> said:
> > > > > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
> > > > >> When a USB hub port is connected to a connector in a firmware node
> > > > >> graph, the port itself has a node in the graph.
> > > > >>
> > > > >> Associate the port's firmware node with the USB port's device,
> > > > >> usb_port::dev. This is used in later changes for the M.2 slot power
> > > > >> sequencing provider to match against the requesting port.
> > > > >
> > > > > Okay, would this affect ACPI-based systems? if so, how?
> > > > > Can you elaborate on that, please?
> > > >
> > > > Is it possible that there's an ACPI device node associated with the port like
> > > > on some DT systems? I don't think so and there should be no impact IMO but I
> > > > also don't know enough about ACPI.
>
> There are device nodes for the USB ports in ACPI, and I think they get
> always assigned in drivers/usb/core/usb-acpi.c.
>
> > > The API is agnostic. There is a possibility to have software nodes associated
> > > with the port. I think the best is to be sure that ACPI-aware people who are
> > > experts in USB will check this (Heikki?).
>
> I can't say what's the impact from this patch - I'm not an expert with
> this side of USB. Is there a danger that we end up overwriting the
> ACPI node for the port, or something else?
Exactly this one is my worrying, but I haven't checked the actual flow.
> > Even if there is a software node - it shouldn't really matter. It will
> > just be assigned to the port device.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v6 2/3] PCI: rockchip-host: do not attempt 5.0 GT/s retraining
From: Geraldo Nascimento @ 2026-06-11 20:03 UTC (permalink / raw)
To: Shawn Lin, Dragan Simic
Cc: linux-rockchip, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, linux-pci,
linux-arm-kernel, linux-kernel, Geraldo Nascimento
In-Reply-To: <cover.1781207474.git.geraldogabriel@gmail.com>
Drop the 5.0 GT/s Link Speed retraining from Rockchip PCIe Root
Complex Mode Operation, so called host driver.
The reason is that Shawn Lin from Rockchip has reiterated that there
may be danger of "catastrophic failure" in using their PCIe with
5.0GT/s speeds.
While Rockchip has done so informally without issuing a proper errata,
and the particulars are thus unknown, this may cause data loss or
worse.
This change is corroborated by RK3399 official datasheet [1], which
states maximum link speed for this platform is 2.5 GT/s.
[1] https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf
Link: https://lore.kernel.org/all/ffd05070-9879-4468-94e3-b88968b4c21b@rock-chips.com/
Cc: stable@vger.kernel.org
Reported-by: Dragan Simic <dsimic@manjaro.org>
Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
---
drivers/pci/controller/pcie-rockchip-host.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index ee1822ca01db3..1374a2c92b563 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -328,26 +328,6 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
goto err_power_off_phy;
}
- if (rockchip->link_gen == 2) {
- /*
- * Enable retrain for gen2. This should be configured only after
- * gen1 finished.
- */
- status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_CR + PCI_EXP_LNKCTL2);
- status &= ~PCI_EXP_LNKCTL2_TLS;
- status |= PCI_EXP_LNKCTL2_TLS_5_0GT;
- rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_CR + PCI_EXP_LNKCTL2);
- status = rockchip_pcie_read(rockchip, PCIE_RC_CONFIG_CR + PCI_EXP_LNKCTL);
- status |= PCI_EXP_LNKCTL_RL;
- rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_CR + PCI_EXP_LNKCTL);
-
- err = readl_poll_timeout(rockchip->apb_base + PCIE_CORE_CTRL,
- status, PCIE_LINK_IS_GEN2(status), 20,
- 500 * USEC_PER_MSEC);
- if (err)
- dev_dbg(dev, "PCIe link training gen2 timeout, fall back to gen1!\n");
- }
-
/* Check the final link width from negotiated lane counter from MGMT */
status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
status = 0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
--
2.54.0
^ permalink raw reply related
* [PATCH v6 3/3] PCI: rockchip: drive at 2.5 GT/s, error other speeds
From: Geraldo Nascimento @ 2026-06-11 20:04 UTC (permalink / raw)
To: Shawn Lin, Dragan Simic
Cc: linux-rockchip, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, linux-pci,
linux-arm-kernel, linux-kernel, Geraldo Nascimento
In-Reply-To: <cover.1781207474.git.geraldogabriel@gmail.com>
Configure the core to be driven at 2.5 GT/s Link Speed and ignore
any other speed with a warning. Also drop the 5.0 GT/s Link Speed
defines from Rockchip PCIe header.
The reason is that Shawn Lin from Rockchip has reiterated that there
may be danger of "catastrophic failure" in using their PCIe with
5.0 GT/s speeds.
While Rockchip has done so informally without issuing a proper errata,
and the particulars are thus unknown, this may cause data loss or
worse.
This change is corroborated by RK3399 official datasheet [1], which
states maximum link speed for this platform is 2.5 GT/s.
[1] https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Link: https://lore.kernel.org/all/ffd05070-9879-4468-94e3-b88968b4c21b@rock-chips.com/
Cc: stable@vger.kernel.org
Reported-by: Dragan Simic <dsimic@manjaro.org>
Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
---
drivers/pci/controller/pcie-rockchip.c | 16 +++++++++-------
drivers/pci/controller/pcie-rockchip.h | 3 ---
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c b/drivers/pci/controller/pcie-rockchip.c
index 0f88da3788054..5a2876d7c8547 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -66,8 +66,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
rockchip->link_gen = of_pci_get_max_link_speed(node);
- if (rockchip->link_gen < 0 || rockchip->link_gen > 2)
- rockchip->link_gen = 2;
+ if (rockchip->link_gen < 0 || rockchip->link_gen >= 2) {
+ rockchip->link_gen = 1;
+ dev_warn(dev, "invalid max-link-speed, limited to 2.5 GT/s\n");
+ }
for (i = 0; i < ROCKCHIP_NUM_PM_RSTS; i++)
rockchip->pm_rsts[i].id = rockchip_pci_pm_rsts[i];
@@ -147,12 +149,12 @@ int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
goto err_exit_phy;
}
+ /* 5.0 GT/s may cause catastrophic failure for this core */
if (rockchip->link_gen == 2)
- rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
- PCIE_CLIENT_CONFIG);
- else
- rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
- PCIE_CLIENT_CONFIG);
+ dev_warn(dev, "5.0 GT/s may cause data loss or worse\n");
+
+ rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1,
+ PCIE_CLIENT_CONFIG);
regs = PCIE_CLIENT_ARI_ENABLE |
PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes);
diff --git a/drivers/pci/controller/pcie-rockchip.h b/drivers/pci/controller/pcie-rockchip.h
index 3e82a69b9c006..b5da15601b585 100644
--- a/drivers/pci/controller/pcie-rockchip.h
+++ b/drivers/pci/controller/pcie-rockchip.h
@@ -42,7 +42,6 @@
#define PCIE_CLIENT_MODE_RC HWORD_SET_BIT(0x0040)
#define PCIE_CLIENT_MODE_EP HWORD_CLR_BIT(0x0040)
#define PCIE_CLIENT_GEN_SEL_1 HWORD_CLR_BIT(0x0080)
-#define PCIE_CLIENT_GEN_SEL_2 HWORD_SET_BIT(0x0080)
#define PCIE_CLIENT_LEGACY_INT_CTRL (PCIE_CLIENT_BASE + 0x0c)
#define PCIE_CLIENT_INT_IN_ASSERT HWORD_SET_BIT(0x0002)
#define PCIE_CLIENT_INT_IN_DEASSERT HWORD_CLR_BIT(0x0002)
@@ -197,8 +196,6 @@
(((x) & PCIE_CORE_PL_CONF_LS_MASK) == PCIE_CORE_PL_CONF_LS_READY)
#define PCIE_LINK_UP(x) \
(((x) & PCIE_CLIENT_LINK_STATUS_MASK) == PCIE_CLIENT_LINK_STATUS_UP)
-#define PCIE_LINK_IS_GEN2(x) \
- (((x) & PCIE_CORE_PL_CONF_SPEED_MASK) == PCIE_CORE_PL_CONF_SPEED_5G)
#define RC_REGION_0_ADDR_TRANS_H 0x00000000
#define RC_REGION_0_ADDR_TRANS_L 0x00000000
--
2.54.0
^ permalink raw reply related
* [PATCH] firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
From: Unnathi Chalicheemala @ 2026-06-11 20:19 UTC (permalink / raw)
To: Sudeep Holla, Jens Wiklander
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, kernel,
Trilok Soni, Satya Durga Srinivasu Prabhala,
Unnathi Chalicheemala
ffa_partition_info_get() passes uuid_str directly to uuid_parse()
without a NULL check. When a caller passes NULL (or an empty string),
uuid_parse() → __uuid_parse() → uuid_is_valid() dereferences the
pointer, causing a kernel panic:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000040
pc : uuid_parse+0x40/0xac
lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa]
Per the FF-A spec, the all-zeros UUID is the defined wildcard that
instructs the SPMC to return information for all partitions. Map NULL
and empty string to uuid_null rather than crashing in uuid_parse(),
preserving the intended "return all partitions" semantics for callers
that pass NULL.
Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions")
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
---
drivers/firmware/arm_ffa/driver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b9f17fda7243..dd500fb81b79 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1129,7 +1129,9 @@ static int ffa_partition_info_get(const char *uuid_str,
uuid_t uuid;
struct ffa_partition_info *pbuf;
- if (uuid_parse(uuid_str, &uuid)) {
+ if (!uuid_str || uuid_str[0] == '\0') {
+ uuid = uuid_null;
+ } else if (uuid_parse(uuid_str, &uuid)) {
pr_err("invalid uuid (%s)\n", uuid_str);
return -ENODEV;
}
---
base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
change-id: 20260604-ffa_partition_nullptr_fix-66f37bb2630b
Best regards,
--
Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH RESEND v6] MAINTAINERS: Add Axiado reviewer and Maintainers
From: Karthikeyan Mitran @ 2026-06-11 20:19 UTC (permalink / raw)
To: Arnd Bergmann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Prasad Bolisetty, Tzu-Hao Wei
Cc: devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Drew Fustini, Linus Walleij, Harshit Shah, Karthikeyan Mitran
From: Prasad Bolisetty <pbolisetty@axiado.com>
Adding 3 new maintainers Prasad,Tzu-Hao, and Karthikeyan
Removed previous maintainer as the previous maintainer moved from project
Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
Acked-by: Harshit Shah <hshah@axiado.com>
Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
Signed-off-by: Karthikeyan Mitran <kmitran@axiado.com>
---
----
This patch removes a Axiado SoC maintainer and adds 3 more.
A maintainer has moved on from the project, so we are adding three new maintainers (Prasad, Tzu-Hao, and Karthikeyan). also commit message amended to have the same.
Patch 1: Removed one and added 3 new maintainers
Changes since v5:
- Removed review mail-list R:Axiado Reviewers <linux-maintainer@axiado.com>
- Link to v5: https://lore.kernel.org/r/20260326-maintainers-addition-and-axiado-ax3000_dtsi-update-v5-1-648dfe9bff29@axiado.com
Changes in v4:
- Updated commit message to clarify maintainer removal and additions
- v4: https://lore.kernel.org/linux-devicetree/20260302-maintainers-addition-and-axiado-ax3000_dtsi-update-v4-0-84a5c9df6689@axiado.com/
Changes in v3:
- Updated commit message
- v3: https://lore.kernel.org/linux-devicetree/20260226-maintainers-addition-and-axiado-ax3000_dtsi-update-v3-0-a3b095989823@axiado.com/
---
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 55af015174a5..b1349bd178cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2605,7 +2605,9 @@ F: arch/arm/mach-aspeed/
N: aspeed
ARM/AXIADO ARCHITECTURE
-M: Harshit Shah <hshah@axiado.com>
+M: Prasad Bolisetty <pbolisetty@axiado.com>
+M: Tzu-Hao Wei <twei@axiado.com>
+M: Karthikeyan Mitran <kmitran@axiado.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/axiado.yaml
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260226-maintainers-addition-and-axiado-ax3000_dtsi-update-2f37e16b9053
Best regards,
--
Karthikeyan Mitran <kmitran@axiado.com>
^ permalink raw reply related
* Re: [PATCH 0/3] ARM: dts: stm32: lxa: change stdout-path baud rate from 9600 to 115200
From: Ahmad Fatoum @ 2026-06-11 20:33 UTC (permalink / raw)
To: David Laight
Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde, Alexandre Torgue, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, kernel
In-Reply-To: <20260611204341.147f1afb@pumpkin>
Hi David,
On 6/11/26 21:43, David Laight wrote:
> On Thu, 11 Jun 2026 20:12:32 +0200
> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
>> The LXA boards are the only STM32 boards that set stdout-path = &uart*
>> instead of explicitly specifying a baud rate.
>>
>> This would mean the default of 9600 is used, but it goes unnoticed when
>> booting normally as barebox fixes up a console= line that includes a
>> baud rate.
>>
>> When EFI booting GRUB however, GRUB will not pass along the console=
>> line and thus the board ends up with a 9600 baud Linux console,
>> confusing users.
>
> Is it possible to determine the current baud rate (by reading the hardware
> register) and default to that value.
> Then if grub has initialised the uart the kernel will use the same
> baud rate.
I think so, yes. In addition to the register divider configuration, one
would need the input clock rate as well, but that's not a problem.
Do you know if any drivers already do this?
Nevertheless, I would like the LXA device trees changed, even if only
to align them with all other existing STM32 device trees.
Cheers,
Ahmad
>
> David
>
>>
>> This series fixes this. As the device trees were added at different
>> times, they are fixed each in a separate commit with its own Fixes: tag.
>>
>> ---
>> Ahmad Fatoum (3):
>> ARM: dts: stm32: lxa-mc1: change stdout-path baud rate from 9600 to 115200
>> ARM: dts: stm32: lxa-tac: change stdout-path baud rate from 9600 to 115200
>> ARM: dts: stm32: fairytux2: change stdout-path baud rate from 9600 to 115200
>>
>> arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi | 2 +-
>> arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts | 2 +-
>> arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>> ---
>> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
>> change-id: 20260611-lxa-stdout-path-baudrate-7cf454cdae07
>>
>> Best regards,
>> --
>> Ahmad Fatoum <a.fatoum@pengutronix.de>
>>
>>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v5 1/4] PCI/DOE: Move common definitions to the header file
From: Frank Li @ 2026-06-11 20:36 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260610100256.1889111-2-a-garg7@ti.com>
On Wed, Jun 10, 2026 at 03:32:53PM +0530, Aksh Garg wrote:
> Move common macros and structures from drivers/pci/doe.c to
> drivers/pci/pci.h to allow reuse across root complex and
> endpoint DOE implementations.
>
> PCI_DOE_MAX_LENGTH macro can be used outside the PCI core as well,
> hence move the macro to include/linux/pci-doe.h.
>
> These changes prepare the groundwork for the DOE endpoint implementation
> that will reuse these common definitions.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Changes from v4 to v5:
> - None.
>
> Changes from v3 to v4:
> - None.
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - Moved the common macros that need not be visible outside the PCI core
> to drivers/pci/pci.h instead to include/linux/pci-doe.h as suggested
> by Lukas Wunner
> - Removed the redundant empty inlines guarded with CONFIG_PCI_DOE in
> include/linux/pci-doe.h.
>
> v4: https://lore.kernel.org/all/20260522052434.802034-2-a-garg7@ti.com/
> v3: https://lore.kernel.org/all/20260427051725.223704-2-a-garg7@ti.com/
> v2: https://lore.kernel.org/all/20260401073022.215805-2-a-garg7@ti.com/
> v1: https://lore.kernel.org/all/20260213123603.420941-3-a-garg7@ti.com/
>
> drivers/pci/doe.c | 11 -----------
> drivers/pci/pci.h | 9 +++++++++
> include/linux/pci-doe.h | 3 +++
> 3 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
> index 7b41da4ec11a..e8d9e95644b3 100644
> --- a/drivers/pci/doe.c
> +++ b/drivers/pci/doe.c
> @@ -28,12 +28,6 @@
> #define PCI_DOE_TIMEOUT HZ
> #define PCI_DOE_POLL_INTERVAL (PCI_DOE_TIMEOUT / 128)
>
> -#define PCI_DOE_FLAG_CANCEL 0
> -#define PCI_DOE_FLAG_DEAD 1
> -
> -/* Max data object length is 2^18 dwords */
> -#define PCI_DOE_MAX_LENGTH (1 << 18)
> -
> /**
> * struct pci_doe_mb - State for a single DOE mailbox
> *
> @@ -63,11 +57,6 @@ struct pci_doe_mb {
> #endif
> };
>
> -struct pci_doe_feature {
> - u16 vid;
> - u8 type;
> -};
> -
> /**
> * struct pci_doe_task - represents a single query/response
> *
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 4a14f88e543a..5844deee2b5f 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -683,6 +683,15 @@ struct pci_sriov {
> bool drivers_autoprobe; /* Auto probing of VFs by driver */
> };
>
> +/* DOE Mailbox state flags */
> +#define PCI_DOE_FLAG_CANCEL 0
> +#define PCI_DOE_FLAG_DEAD 1
> +
> +struct pci_doe_feature {
> + u16 vid;
> + u8 type;
> +};
> +
> #ifdef CONFIG_PCI_DOE
> void pci_doe_init(struct pci_dev *pdev);
> void pci_doe_destroy(struct pci_dev *pdev);
> diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
> index bd4346a7c4e7..abb9b7ae8029 100644
> --- a/include/linux/pci-doe.h
> +++ b/include/linux/pci-doe.h
> @@ -19,6 +19,9 @@ struct pci_doe_mb;
> #define PCI_DOE_FEATURE_CMA 1
> #define PCI_DOE_FEATURE_SSESSION 2
>
> +/* Max data object length is 2^18 dwords */
> +#define PCI_DOE_MAX_LENGTH (1 << 18)
> +
> struct pci_doe_mb *pci_find_doe_mailbox(struct pci_dev *pdev, u16 vendor,
> u8 type);
>
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v6 0/3] PCI: rockchip: 5.0 GT/s speed discouraged by Rockchip
From: Geraldo Nascimento @ 2026-06-11 20:02 UTC (permalink / raw)
To: Shawn Lin, Dragan Simic
Cc: linux-rockchip, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, linux-pci,
linux-arm-kernel, linux-kernel, Geraldo Nascimento
Dragan Simic already had warned me of potential issues with 5.0 GT/s
speed operation in Rockchip PCIe. However, in recent interactions
with Shawn Lin from Rockchip it came to my attention there's grave
danger in the unknown errata regarding 5.0 GT/s operational speed
of their PCIe core, including data loss.
Drop all code related to 5.0 GT/s operational speed from this driver.
Endpoint Mode driver was not tested.
---
Changes in v6:
- Squashed patches 3 & 4 together as suggested by Mani
- More formal warning message as suggested by Dragan
- Set the 2.5 GT/s bit regardless of if link-speed is set to 2
- Link to v5: https://lore.kernel.org/all/cover.1772239598.git.geraldogabriel@gmail.com/T/
Changes in v5:
- Changed commit order to not break builds and adjusted copy pasted
commit message. (thanks Charalampos!)
- Reintroduced behavior to force 2.5 GT/s in case there's something
non-default in the DT. (thanks Dragan!)
- Link to v4: https://lore.kernel.org/linux-rockchip/cover.1772169998.git.geraldogabriel@gmail.com/T/
Changes in v4:
- Incorporate suggestion by Bjorn and refined by Dragan to drop the
"catastrophic" code
- Link to v3: https://lore.kernel.org/linux-rockchip/cover.1772057799.git.geraldogabriel@gmail.com/T/
Changes in v3:
- Clarify warning message even though Rockchip won't disclose details
- Drop DT changes as they were applied as subset by Heiko
- Link to v2: https://lore.kernel.org/all/cover.1763415705.git.geraldogabriel@gmail.com/T/
Changes in v2:
- hard limit to 2.5 GT/s, not just warn
- add Reported-by: and Reviewed-by: Dragan Simic
- remove redundant declaration of max-link-speed from helios64 dts
- fix Link: of helios64 patch
- simplify RC mode comment
- Link to v1: https://lore.kernel.org/all/aRhR79u5BPtRRFw3@geday/T/
---
Geraldo Nascimento (3):
PCI: rockchip-ep: do not attempt 5.0 GT/s retraining
PCI: rockchip-host: do not attempt 5.0 GT/s retraining
PCI: rockchip: drive at 2.5 GT/s, error other speeds
drivers/pci/controller/pcie-rockchip-ep.c | 13 -------------
drivers/pci/controller/pcie-rockchip-host.c | 20 --------------------
drivers/pci/controller/pcie-rockchip.c | 16 +++++++++-------
drivers/pci/controller/pcie-rockchip.h | 3 ---
4 files changed, 9 insertions(+), 43 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH 0/4] Xilinx TRNG fix and simplification
From: Eric Biggers @ 2026-06-11 20:47 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, linux-kernel, Mounika Botcha, Harsh Jain,
Olivia Mackall, Michal Simek, linux-arm-kernel
In-Reply-To: <aip2l1pwMY4UDBdA@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 04:49:27PM +0800, Herbert Xu wrote:
> On Sun, May 31, 2026 at 12:17:34PM -0700, Eric Biggers wrote:
> > This series fixes and greatly simplifies the Xilinx TRNG driver by:
> >
> > - Removing the gratuitous crypto_rng interface, leaving just hwrng which
> > is the one that actually matters.
> >
> > - Replacing the really complicated AES based entropy extraction
> > algorithm with a much simpler one.
> >
> > Note that this mirrors similar changes in other drivers.
> >
> > Eric Biggers (4):
> > crypto: xilinx-trng - Remove crypto_rng interface
> > crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()
> > crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512
> > hwrng: xilinx - Move xilinx-rng into drivers/char/hw_random/
> >
> > MAINTAINERS | 2 +-
> > arch/arm64/configs/defconfig | 2 +-
> > crypto/Kconfig | 5 -
> > crypto/Makefile | 2 -
> > crypto/df_sp80090a.c | 222 ------------------
> > drivers/char/hw_random/Kconfig | 11 +
> > drivers/char/hw_random/Makefile | 1 +
> > .../xilinx => char/hw_random}/xilinx-trng.c | 134 ++---------
> > drivers/crypto/Kconfig | 13 -
> > drivers/crypto/xilinx/Makefile | 1 -
> > include/crypto/df_sp80090a.h | 53 -----
> > 11 files changed, 37 insertions(+), 409 deletions(-)
> > delete mode 100644 crypto/df_sp80090a.c
> > rename drivers/{crypto/xilinx => char/hw_random}/xilinx-trng.c (75%)
> > delete mode 100644 include/crypto/df_sp80090a.h
> >
> >
> > base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> > prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> > prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> > prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> > prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> > --
> > 2.54.0
>
> All applied. Thanks.
Can you re-add the following to "hwrng: xilinx - Move xilinx-rng into
drivers/char/hw_random/"? It seems you applied this before the qcom-rng
series, then dropped the drivers/char/hw_random/Makefile change rather
than resolve it.
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 3e655d6e116b..95b5adb49560 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -51,5 +51,6 @@ obj-$(CONFIG_HW_RANDOM_XIPHERA) += xiphera-trng.o
obj-$(CONFIG_HW_RANDOM_ARM_SMCCC_TRNG) += arm_smccc_trng.o
obj-$(CONFIG_HW_RANDOM_CN10K) += cn10k-rng.o
obj-$(CONFIG_HW_RANDOM_POLARFIRE_SOC) += mpfs-rng.o
obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
obj-$(CONFIG_HW_RANDOM_JH7110) += jh7110-trng.o
+obj-$(CONFIG_HW_RANDOM_XILINX) += xilinx-trng.o
^ permalink raw reply related
* Re: [PATCH v5 0/4] PCI: Add DOE support for endpoint
From: Frank Li @ 2026-06-11 20:47 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260610100256.1889111-1-a-garg7@ti.com>
On Wed, Jun 10, 2026 at 03:32:52PM +0530, Aksh Garg wrote:
> This patch series introduces the framework for supporting the Data
> Object Exchange (DOE) feature for PCIe endpoint devices. Please refer
> to the documentation added in patch 4 for details on the feature and
> implementation architecture.
>
> The implementation provides a common framework for all PCIe endpoint
> controllers, not specific to any particular SoC vendor.
>
General question, does DOE generate irq when received msg for HOST? I have
not related irq handle code.
Any program to test it? such as pci_endpoint_test, need at least one real
user to use it.
Frank
> The changes since v1 are documented in the respective patch descriptions.
>
> v4: https://lore.kernel.org/all/20260522052434.802034-1-a-garg7@ti.com/
> v3: https://lore.kernel.org/all/20260427051725.223704-1-a-garg7@ti.com/
> v2: https://lore.kernel.org/all/20260401073022.215805-1-a-garg7@ti.com/
> v1 (RFC): https://lore.kernel.org/all/20260213123603.420941-1-a-garg7@ti.com/
>
> Below is a code demonstration showing the integration of DOE-EP APIs with
> EPC drivers.
>
> Note: The provided code is just to show how an EPC driver is expected to
> utilize the pci_ep_doe_process_request() and pci_ep_doe_abort() APIs,
> and might not cover all the corner cases. The below implementation
> also expects the EPC hardware to have some memory buffer to store the
> data from(for) write_mailbox(read_mailbox) DOE capability registers.
>
> ============================================================================
>
> /* ========== DOE Completion Callback (invoked by DOE-EP core) ========== */
>
> static void doe_completion_cb(struct pci_epc *epc, u8 func_no, u16 cap_offset,
> int status, u16 vendor, u8 type,
> void *response_pl, size_t response_pl_sz)
> {
> struct epc_driver *drv = epc_get_drvdata(epc);
> u32 *response = (u32 *)response_pl;
> u32 header1, header2;
> int payload_dw, i;
>
> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
> /* Aborted: do not send response */
> goto free;
> }
>
> if (status < 0) {
> /* Error: set ERROR bit in DOE Status register */
> writel(1 << DOE_STATUS_ERROR,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
> goto free;
> }
>
> /* Success: write DOE headers first, then response to the read memory */
>
> /* Header 1: Vendor ID (bits 15:0) | Type (bits 23:16) */
> header1 = (type << 16) | vendor;
> writel(header1, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>
> /* Header 2: Length in DW (including 2 DW of headers + payload) */
> payload_dw = DIV_ROUND_UP(response_pl_sz, sizeof(u32));
> header2 = 2 + payload_dw; /* 2 header DWs + payload */
> writel(header2, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>
> /* Set READY bit to signal response ready */
> writel(1 << DOE_STATUS_READY,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>
> /* Write response payload DWORDs to Read memory */
> for (i = 0; i < payload_dw; i++)
> writel(response[i],
> drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>
> /* Wait for the memory to empty before clearing the READY bit */
> while (!RD_MEMORY_EMPTY()) {/* wait */}
>
> writel(0 << DOE_STATUS_READY,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>
> free:
> /* unset BUSY bit */
> writel(0 << DOE_STATUS_BUSY,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>
> kfree(response_pl);
> }
>
> /* ========== DOE Interrupt Handler (triggered on GO bit from root complex) ========== */
>
> static irqreturn_t doe_interrupt_handler(int irq, void *priv)
> {
> struct epc_driver *drv = priv;
> u16 cap_offset = extract_cap_offset_from_irq(irq);
> u8 func_no = extract_func_from_irq(irq);
> u32 header1, header2, length_dw, *request;
> u16 vendor;
> u8 type;
> int i, ret;
>
> /* Read first header DWORD: Vendor ID (bits 15:0) | Type (bits 23:16) */
> header1 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
> vendor = header1 & 0xFFFF;
> type = (header1 >> 16) & 0xFF;
>
> /* Read second header DWORD: Length in DW (includes 2 DW of headers) */
> header2 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
> length_dw = header2 & 0x3FFFF; /* Bits 17:0 */
>
> if (!length_dw)
> length_dw = PCI_DOE_MAX_LENGTH;
>
> length_dw -= 2; /* Subtract 2 DW of headers to get payload length */
> /* Allocate buffer for complete request (headers + payload) */
> request = kzalloc(length_dw * sizeof(u32), GFP_ATOMIC);
> if (!request) {
> writel(1 << DOE_STATUS_ERROR,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
> return IRQ_HANDLED;
> }
>
> /* Read remaining payload DWORDs from Write memory */
> for (i = 0; i < length_dw; i++) {
> while (WR_MEMORY_EMPTY()) { /* wait */ }
> request[i] = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
> }
>
> mutex_lock(&lock);
> /* Check the ABORT bit, if set then return */
> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
> kfree(request);
> mutex_unlock(&lock);
> return IRQ_HANDLED;
> }
>
> /* Set BUSY bit */
> writel(1 << DOE_STATUS_BUSY,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
> mutex_unlock(&lock);
>
> /* Hand off to DOE-EP core for asynchronous processing */
> ret = pci_ep_doe_process_request(drv->epc, func_no, cap_offset,
> vendor, type, (void *)request,
> length_dw * sizeof(u32),
> doe_completion_cb);
> if (ret) {
> writel(1 << DOE_STATUS_ERROR,
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
> kfree(request);
> }
>
> return IRQ_HANDLED;
> }
>
> /* ========== Abort Handler (triggered on ABORT bit from root complex) ========== */
>
> static irqreturn_t doe_abort_handler(int irq, void *priv)
> {
> struct epc_driver *drv = priv;
> u16 cap_offset = extract_cap_offset_from_irq(irq);
> u8 func_no = extract_func_from_irq(irq);
>
> mutex_lock(&lock);
>
> /* call abort API only if BUSY bit set (pci_ep_doe_process_request() called) */
> if (readl(drv->base + PF_DOE_STATUS_REG(func_no, cap_offset)) & DOE_STATUS_BUSY)
> pci_ep_doe_abort(drv->epc, func_no, cap_offset);
>
> mutex_unlock(&lock);
>
> /* Discard Write memory contents */
> writel(DOE_WR_MEMORY_CTRL_DISCARD,
> drv->base + PF_DOE_WR_MEMORY_CTRL_REG(func_no, cap_offset));
>
> /* Clear status bits */
> writel((0 << DOE_STATUS_ERROR) | (0 << DOE_STATUS_READY),
> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>
> return IRQ_HANDLED;
> }
>
> ====================================================================================
>
> Aksh Garg (4):
> PCI/DOE: Move common definitions to the header file
> PCI: endpoint: Add DOE mailbox support for endpoint functions
> PCI: endpoint: Add support for DOE initialization and setup in EPC
> core
> Documentation: PCI: Add documentation for DOE endpoint support
>
> Documentation/PCI/endpoint/index.rst | 1 +
> .../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++
> drivers/pci/doe.c | 11 -
> drivers/pci/endpoint/Kconfig | 14 +
> drivers/pci/endpoint/Makefile | 1 +
> drivers/pci/endpoint/pci-ep-doe.c | 594 ++++++++++++++++++
> drivers/pci/endpoint/pci-epc-core.c | 104 +++
> drivers/pci/pci.h | 48 ++
> include/linux/pci-doe.h | 8 +
> include/linux/pci-epc.h | 9 +
> 10 files changed, 1112 insertions(+), 11 deletions(-)
> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
> create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Andrew Lunn @ 2026-06-11 20:54 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260612-shikra_ethernet-v1-3-f0f4a1d19929@oss.qualcomm.com>
On Fri, Jun 12, 2026 at 12:06:59AM +0530, Mohd Ayaan Anwar wrote:
> When "rgmii-id" is selected the PHY supplies both TX and RX delays, so
> the MAC must not add its own. The driver currently falls through to the
> generic DLL initialisation path which programs it to add a delay.
>
> Power down the DLL and set DDR bypass mode for RGMII_ID, then program
> the IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. Also fix
> ethqos_set_clk_tx_rate() to not double the clock rate in bypass mode at
> 100M/10M, and remove RGMII_ID from the phase-shift suppression in
> ethqos_rgmii_macro_init() since RGMII_ID no longer reaches that path.
I'm curious how this works at the moment? Do no boards make use of
RGMII ID? Are all current boards broken?
Andrew
^ permalink raw reply
* Re: [GIT PULL] pmdomain fixes for v7.1-rc8
From: pr-tracker-bot @ 2026-06-11 20:58 UTC (permalink / raw)
To: Ulf Hansson; +Cc: Linus, linux-pm, linux-kernel, Ulf Hansson, linux-arm-kernel
In-Reply-To: <20260611110557.120619-1-ulf.hansson@oss.qualcomm.com>
The pull request you sent on Thu, 11 Jun 2026 13:05:57 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git tags/pmdomain-v7.1-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/79f2670da86722d075633d20fa57418994ee6940
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH RFC 7/9] arm64: dts: qcom: shikra-cqm-evk: Enable ethernet0
From: Andrew Lunn @ 2026-06-11 20:58 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260612-shikra_ethernet-v1-7-f0f4a1d19929@oss.qualcomm.com>
> + ethphy0: ethernet-phy@7 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <7>;
> + reset-gpios = <&tlmm 135 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <10000>;
> + reset-deassert-us = <50000>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
Are these two needed? It should default to 2ns, since that is what the
RGMII standard says the delay should be.
Andrew
^ permalink raw reply
* [PATCH] crypto: atmel-ecc - reject hardware ECDH without a public key
From: Thorsten Blum @ 2026-06-11 21:36 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Tudor Ambarus
Cc: linux-crypto, linux-arm-kernel, linux-kernel
The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the
private key stored in the device. However, the public key is cached only
after atmel_ecdh_set_secret() successfully generated that private key
for the current tfm.
atmel_ecdh_generate_public_key() already rejects requests when no public
key is cached. Add the same check to atmel_ecdh_compute_shared_secret()
to prevent the device from using a private key that was not generated
for the current tfm.
Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 93f219558c2f..542c8cc13a0f 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -173,6 +173,9 @@ static int atmel_ecdh_compute_shared_secret(struct kpp_request *req)
return crypto_kpp_compute_shared_secret(req);
}
+ if (!ctx->public_key)
+ return -EINVAL;
+
/* must have exactly two points to be on the curve */
if (req->src_len != ATMEL_ECC_PUBKEY_SIZE)
return -EINVAL;
^ permalink raw reply related
* Re: [PATCH RESEND v6] MAINTAINERS: Add Axiado reviewer and Maintainers
From: Arnd Bergmann @ 2026-06-11 21:48 UTC (permalink / raw)
To: Karthikeyan Mitran, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Prasad Bolisetty, Tzu-Hao Wei
Cc: devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Drew Fustini, Linus Walleij, Harshit Shah
In-Reply-To: <20260611-maintainers-addition-and-axiado-ax3000_dtsi-update-v6-1-00bdcddc0c29@axiado.com>
On Thu, Jun 11, 2026, at 22:19, Karthikeyan Mitran wrote:
> From: Prasad Bolisetty <pbolisetty@axiado.com>
>
> Adding 3 new maintainers Prasad,Tzu-Hao, and Karthikeyan
> Removed previous maintainer as the previous maintainer moved from project
>
> Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
> Acked-by: Harshit Shah <hshah@axiado.com>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
> Signed-off-by: Karthikeyan Mitran <kmitran@axiado.com>
> ---
I've picked up the patch now for 7.2.
For future content that you want to get merged after it
has been reviewed, please make sure to send the patches
or pull requests to soc@lists.linux.dev, and follow the
additional explanations from
Documentation/process/maintainer-soc.rst
Thanks,
Arnd
^ permalink raw reply
* [PATCH net-next v5 0/3] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: Lorenzo Bianconi @ 2026-06-11 21:55 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal,
Alexander Lobakin
Add the capability to configure GDM3/GDM4 as WAN/LAN on demand when QoS
offload is created or destroyed.
Make dev->qdma an RCU pointer so the TX path can safely dereference it
without holding RTNL.
Introduce airoha_qdma_start() and airoha_qdma_stop() helpers.
---
Changes in v5:
- Add patch 1/3: use int instead of atomic_t for qdma users counter
- Protect dev->flags with flow_offload_mutex mutex.
- Introduce AIROHA_PRIV_F_QOS in order to handle better WAN/LAN
switching.
- Link to v4: https://lore.kernel.org/r/20260610-airoha-ethtool-priv_flags-v4-0-60e89cf28fea@kernel.org
Changes in v4:
- Move back QDMA TX/RX DMA enable to airoha_dev_open()/airoha_dev_stop().
- Configure GDM3/4 as WAN if GDM2 is not available in ndo_init()
callback.
- Protect qdma pointer in airoha_gdm_dev struct using RCU.
- Rely on rtnl_dereference() to access qdma pointer in the control path.
- Add airoha_qdma_start() and airoha_qdma_stop() utility routines in
patch 1/2
- Link to v3: https://lore.kernel.org/r/20260608-airoha-ethtool-priv_flags-v3-1-3e8e3dc3f715@kernel.org
Changes in v3:
- Do not introduce ethtool private flags support to configure LAN/WAN
for GDM3/4 and rely on tc qdisc offload for it instead.
- Set GDM3/4 ports as LAN by default.
- Move QDMA TX/RX DMA enable from airoha_dev_open() to airoha_probe()
and the corresponding disable from airoha_dev_stop() to airoha_qdma_cleanup().
- Link to v2: https://lore.kernel.org/r/20260607-airoha-ethtool-priv_flags-v2-1-742c7aa1e182@kernel.org
Changes in v2:
- Rework airoha_dev_set_wan_flag routine
- Enable GDM_STRIP_CRC_MASK in airoha_disable_gdm2_loopback()
- Do not always reset REG_SRC_PORT_FC_MAP6 in
airoha_disable_gdm2_loopback() but use the same condition used in
airoha_enable_gdm2_loopback().
- Link to v1: https://lore.kernel.org/r/20260606-airoha-ethtool-priv_flags-v1-1-401b2c9fe9f1@kernel.org
---
Lorenzo Bianconi (3):
net: airoha: use int instead of atomic_t for qdma users counter
net: airoha: refactor QDMA start/stop into reusable helpers
net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
drivers/net/ethernet/airoha/airoha_eth.c | 287 +++++++++++++++++++++++++-----
drivers/net/ethernet/airoha/airoha_eth.h | 15 +-
drivers/net/ethernet/airoha/airoha_ppe.c | 9 +-
drivers/net/ethernet/airoha/airoha_regs.h | 1 +
4 files changed, 262 insertions(+), 50 deletions(-)
---
base-commit: dad4d4b92a9b9f0edb8c66deda049da1b62f6089
change-id: 20260606-airoha-ethtool-priv_flags-b6aa70caa780
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* [PATCH net-next v5 1/3] net: airoha: use int instead of atomic_t for qdma users counter
From: Lorenzo Bianconi @ 2026-06-11 21:55 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1@kernel.org>
QDMA users counter is always accessed holding RTNL lock so we do not
require atomic_t for it.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 504247c8bae9..9eb9b6a139b3 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1812,7 +1812,7 @@ static int airoha_dev_open(struct net_device *netdev)
airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
- atomic_inc(&qdma->users);
+ qdma->users++;
if (!airoha_is_lan_gdm_dev(dev) &&
airoha_ppe_is_enabled(qdma->eth, 1))
@@ -1866,7 +1866,7 @@ static int airoha_dev_stop(struct net_device *netdev)
REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
- if (atomic_dec_and_test(&qdma->users)) {
+ if (!--qdma->users) {
airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 8f42973f9cf5..24fd8dcf7fca 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -526,7 +526,7 @@ struct airoha_qdma {
struct airoha_eth *eth;
void __iomem *regs;
- atomic_t users;
+ int users;
struct airoha_irq_bank irq_banks[AIROHA_MAX_NUM_IRQ_BANKS];
--
2.54.0
^ permalink raw reply related
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