* [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 4/8] soc: fsl: guts: make it easier to determine on which SoC we are running
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>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
The guts driver will need to easily determine on which SoC it's running
when it will need to perform RCW override at runtime. The guts driver
knows this already because fsl_guts_init() reads the QorIQ/Layerscape
architectural System Version Register (SVR), but it doesn't save this
for later lookups.
Add a new qoriq_die enum to be used as an index in the fsl_soc_die
array. A new fsl_soc_die_match_one() function is also added so that we
can directly determine if the SVR is a match with a specific die.
The SVR value read from the DCFG CCSR is also kept in the global soc
structure so that it can be accessed when needed.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/soc/fsl/guts.c | 47 ++++++++++++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index dc1a42cd9544..1494b545bbb4 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -27,6 +27,23 @@ struct fsl_soc_data {
u32 uid_offset;
};
+enum qoriq_die {
+ DIE_T4240,
+ DIE_T1040,
+ DIE_T2080,
+ DIE_T1024,
+ DIE_LS1043A,
+ DIE_LS2080A,
+ DIE_LS1088A,
+ DIE_LS1012A,
+ DIE_LS1046A,
+ DIE_LS2088A,
+ DIE_LS1021A,
+ DIE_LX2160A,
+ DIE_LS1028A,
+ DIE_MAX,
+};
+
/* SoC die attribute definition for QorIQ platform */
static const struct fsl_soc_die_attr fsl_soc_die[] = {
/*
@@ -34,21 +51,25 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
*/
/* Die: T4240, SoC: T4240/T4160/T4080 */
+ [DIE_T4240] =
{ .die = "T4240",
.svr = 0x82400000,
.mask = 0xfff00000,
},
/* Die: T1040, SoC: T1040/T1020/T1042/T1022 */
+ [DIE_T1040] =
{ .die = "T1040",
.svr = 0x85200000,
.mask = 0xfff00000,
},
/* Die: T2080, SoC: T2080/T2081 */
+ [DIE_T2080] =
{ .die = "T2080",
.svr = 0x85300000,
.mask = 0xfff00000,
},
/* Die: T1024, SoC: T1024/T1014/T1023/T1013 */
+ [DIE_T1024] =
{ .die = "T1024",
.svr = 0x85400000,
.mask = 0xfff00000,
@@ -59,46 +80,55 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
*/
/* Die: LS1043A, SoC: LS1043A/LS1023A */
+ [DIE_LS1043A] =
{ .die = "LS1043A",
.svr = 0x87920000,
.mask = 0xffff0000,
},
/* Die: LS2080A, SoC: LS2080A/LS2040A/LS2085A */
+ [DIE_LS2080A] =
{ .die = "LS2080A",
.svr = 0x87010000,
.mask = 0xff3f0000,
},
/* Die: LS1088A, SoC: LS1088A/LS1048A/LS1084A/LS1044A */
+ [DIE_LS1088A] =
{ .die = "LS1088A",
.svr = 0x87030000,
.mask = 0xff3f0000,
},
/* Die: LS1012A, SoC: LS1012A */
+ [DIE_LS1012A] =
{ .die = "LS1012A",
.svr = 0x87040000,
.mask = 0xffff0000,
},
/* Die: LS1046A, SoC: LS1046A/LS1026A */
+ [DIE_LS1046A] =
{ .die = "LS1046A",
.svr = 0x87070000,
.mask = 0xffff0000,
},
/* Die: LS2088A, SoC: LS2088A/LS2048A/LS2084A/LS2044A */
+ [DIE_LS2088A] =
{ .die = "LS2088A",
.svr = 0x87090000,
.mask = 0xff3f0000,
},
/* Die: LS1021A, SoC: LS1021A/LS1020A/LS1022A */
+ [DIE_LS1021A] =
{ .die = "LS1021A",
.svr = 0x87000000,
.mask = 0xfff70000,
},
/* Die: LX2160A, SoC: LX2160A/LX2120A/LX2080A */
+ [DIE_LX2160A] =
{ .die = "LX2160A",
.svr = 0x87360000,
.mask = 0xff3f0000,
},
/* Die: LS1028A, SoC: LS1028A */
+ [DIE_LS1028A] =
{ .die = "LS1028A",
.svr = 0x870b0000,
.mask = 0xff3f0000,
@@ -109,6 +139,7 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
static struct fsl_soc_guts {
struct ccsr_guts __iomem *dcfg_ccsr;
bool little_endian;
+ u32 svr;
} soc;
static unsigned int fsl_guts_read(const void __iomem *reg)
@@ -119,11 +150,16 @@ static unsigned int fsl_guts_read(const void __iomem *reg)
return ioread32be(reg);
}
+static bool fsl_soc_die_match_one(u32 svr, const struct fsl_soc_die_attr *match)
+{
+ return match->svr == (svr & match->mask);
+}
+
static const struct fsl_soc_die_attr *fsl_soc_die_match(
u32 svr, const struct fsl_soc_die_attr *matches)
{
while (matches->svr) {
- if (matches->svr == (svr & matches->mask))
+ if (fsl_soc_die_match_one(svr, matches))
return matches;
matches++;
}
@@ -202,7 +238,6 @@ static int __init fsl_guts_init(void)
const struct of_device_id *match;
struct device_node *np;
u64 soc_uid = 0;
- u32 svr;
int ret;
np = of_find_matching_node_and_match(NULL, fsl_guts_of_match, &match);
@@ -217,7 +252,7 @@ static int __init fsl_guts_init(void)
}
soc.little_endian = of_property_read_bool(np, "little-endian");
- svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
+ soc.svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
of_node_put(np);
/* Register soc device */
@@ -229,7 +264,7 @@ static int __init fsl_guts_init(void)
if (ret)
of_machine_read_compatible(&soc_dev_attr->machine, 0);
- soc_die = fsl_soc_die_match(svr, fsl_soc_die);
+ soc_die = fsl_soc_die_match(soc.svr, fsl_soc_die);
if (soc_die) {
soc_dev_attr->family = kasprintf(GFP_KERNEL, "QorIQ %s",
soc_die->die);
@@ -239,12 +274,12 @@ static int __init fsl_guts_init(void)
if (!soc_dev_attr->family)
goto err_nomem;
- soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "svr:0x%08x", svr);
+ soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "svr:0x%08x", soc.svr);
if (!soc_dev_attr->soc_id)
goto err_nomem;
soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%d.%d",
- (svr >> 4) & 0xf, svr & 0xf);
+ (soc.svr >> 4) & 0xf, soc.svr & 0xf);
if (!soc_dev_attr->revision)
goto err_nomem;
--
2.34.1
^ permalink raw reply related
* [PATCH v1 phy-next 2/8] soc: fsl: guts: add a global structure to hold state
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>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Add the fsl_soc_guts structure in order to pass information like base
addresses, endianness etc between the init time and the runtime
operations (RCW override) which will get added in future patches.
There is no point in mapping and unmapping the DCFG CCSR space every
time we need to make a read, just map it once and keep its reference in
this new global struture.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/soc/fsl/guts.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index f87ee47c1503..a0a52a5603a5 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -106,6 +106,11 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
{ },
};
+static struct fsl_soc_guts {
+ struct ccsr_guts __iomem *dcfg_ccsr;
+ bool little_endian;
+} soc;
+
static const struct fsl_soc_die_attr *fsl_soc_die_match(
u32 svr, const struct fsl_soc_die_attr *matches)
{
@@ -187,9 +192,7 @@ static int __init fsl_guts_init(void)
const struct fsl_soc_die_attr *soc_die;
const struct fsl_soc_data *soc_data;
const struct of_device_id *match;
- struct ccsr_guts __iomem *regs;
struct device_node *np;
- bool little_endian;
u64 soc_uid = 0;
u32 svr;
int ret;
@@ -199,18 +202,17 @@ static int __init fsl_guts_init(void)
return 0;
soc_data = match->data;
- regs = of_iomap(np, DCFG_CCSR);
- if (!regs) {
+ soc.dcfg_ccsr = of_iomap(np, DCFG_CCSR);
+ if (!soc.dcfg_ccsr) {
of_node_put(np);
return -ENOMEM;
}
- little_endian = of_property_read_bool(np, "little-endian");
- if (little_endian)
- svr = ioread32(®s->svr);
+ soc.little_endian = of_property_read_bool(np, "little-endian");
+ if (soc.little_endian)
+ svr = ioread32(&soc.dcfg_ccsr->svr);
else
- svr = ioread32be(®s->svr);
- iounmap(regs);
+ svr = ioread32be(&soc.dcfg_ccsr->svr);
of_node_put(np);
/* Register soc device */
@@ -263,6 +265,8 @@ static int __init fsl_guts_init(void)
err_nomem:
ret = -ENOMEM;
+
+ iounmap(soc.dcfg_ccsr);
err:
kfree(soc_dev_attr->family);
kfree(soc_dev_attr->soc_id);
--
2.34.1
^ permalink raw reply related
* [PATCH v1 phy-next 3/8] soc: fsl: guts: add a central fsl_guts_read() function
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>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Add a central fsl_guts_read() function which will take into account the
endianness that was already determined. No point is duplicating the
if-else statement each time we need to read a DCFG register.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/soc/fsl/guts.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index a0a52a5603a5..dc1a42cd9544 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -111,6 +111,14 @@ static struct fsl_soc_guts {
bool little_endian;
} soc;
+static unsigned int fsl_guts_read(const void __iomem *reg)
+{
+ if (soc.little_endian)
+ return ioread32(reg);
+
+ return ioread32be(reg);
+}
+
static const struct fsl_soc_die_attr *fsl_soc_die_match(
u32 svr, const struct fsl_soc_die_attr *matches)
{
@@ -209,10 +217,7 @@ static int __init fsl_guts_init(void)
}
soc.little_endian = of_property_read_bool(np, "little-endian");
- if (soc.little_endian)
- svr = ioread32(&soc.dcfg_ccsr->svr);
- else
- svr = ioread32be(&soc.dcfg_ccsr->svr);
+ svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
of_node_put(np);
/* Register soc device */
--
2.34.1
^ permalink raw reply related
* [PATCH v1 phy-next 0/8] RCW override for 10G Lynx dynamic protocol reconfiguration
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
Previous set "New Generic PHY driver for Lynx 10G SerDes":
https://lore.kernel.org/linux-phy/20260610151952.2141019-1-vladimir.oltean@nxp.com/
introduced the 10G Lynx SerDes driver with a reduced functionality set.
Namely, only minor protocol changes are supported (1GbE <-> 2.5GbE).
The major protocol changes need a procedure named RCW override,
explained in more detail in commits 6/8 and 7/8.
To keep the ball roling, this series adds kernel and device tree binding
support for RCW override. (being so close to the merge window, I don't
really expect this series to be merged, just want to get an initial
feedback so I can keep working on it)
Two components are involved:
- drivers/soc/fsl/guts.c (binding is fsl,layerscape-dcfg.yaml) - Device
Configuration Unit, this is API provider for the SerDes driver to
request RCW override depending on SoC
- drivers/phy/freescale/phy-fsl-lynx-10g.c - SerDes PHY driver, this is
API consumer
The guts driver probes on DCFG blocks from multiple Freescale SoC
generations:
- MPC85xx, BSC and QorIQ (PowerPC) are all covered by the
Documentation/devicetree/bindings/soc/fsl/guts.txt schema
- Layerscape (Arm) is covered by
Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
It is ultimately the same hardware block, just that (from what I can
tell) the Layerscape nodes are also compatible with syscon, and PowerPC
aren't.
RCW override has only been validated on select Layerscape SoCs, so
converting guts.txt to a PowerPC schema is out of scope for this
series - we don't even touch that (just in case it gets asked).
Using syscon to map the DCFG_DCSR register block in the Lynx SerDes
driver instead of creating this guts <-> lynx API was considered, but
because the RCW procedure is SoC-specific, it was ruled out for
polluting the SerDes driver. The guts driver is all about SoC awareness
anyway, and it offers some abstraction of all the gory details.
Cc: Conor Dooley <conor@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Ioana Ciornei (5):
soc: fsl: guts: use a macro to encode the DCFG CCSR space
soc: fsl: guts: add a global structure to hold state
soc: fsl: guts: add a central fsl_guts_read() function
soc: fsl: guts: make it easier to determine on which SoC we are
running
soc: fsl: guts: implement the RCW override procedure
Vladimir Oltean (3):
soc: fsl: guts: make fsl_soc_data available after fsl_guts_init()
dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region
phy: lynx-10g: use RCW override procedure for dynamic protocol change
.../bindings/soc/fsl/fsl,layerscape-dcfg.yaml | 15 +-
drivers/phy/freescale/Kconfig | 1 +
drivers/phy/freescale/phy-fsl-lynx-10g.c | 24 +-
drivers/soc/fsl/guts.c | 370 ++++++++++++++++--
include/linux/fsl/guts.h | 20 +-
5 files changed, 394 insertions(+), 36 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v1 phy-next 1/8] soc: fsl: guts: use a macro to encode the DCFG CCSR space
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>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Instead of using a hardcoded value when iomapping the DCFG CCSR space,
add a new macro for it. The code will be easier to follow this way,
especially when we add support for the DCFG DCSR space as well.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/soc/fsl/guts.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 9bee7baec2b9..f87ee47c1503 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -14,6 +14,8 @@
#include <linux/platform_device.h>
#include <linux/fsl/guts.h>
+#define DCFG_CCSR 0
+
struct fsl_soc_die_attr {
char *die;
u32 svr;
@@ -197,7 +199,7 @@ static int __init fsl_guts_init(void)
return 0;
soc_data = match->data;
- regs = of_iomap(np, 0);
+ regs = of_iomap(np, DCFG_CCSR);
if (!regs) {
of_node_put(np);
return -ENOMEM;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] iio: pressure: ms5637: Add variant specific temperature compensation
From: Andy Shevchenko @ 2026-06-11 19:32 UTC (permalink / raw)
To: Louis Adamian
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260611151026.4abf8804@louisarchdesktop>
On Thu, Jun 11, 2026 at 03:10:26PM -0400, Louis Adamian wrote:
> On Wed, 10 Jun 2026 21:37:58 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Jun 09, 2026 at 10:04:58PM -0400, Louis Adamian wrote:
...
> > > struct ms_tp_dev {
> > > struct i2c_client *client;
> >
> > > const struct ms_tp_hw_data *hw;
> > > u16 prom[MS_SENSORS_TP_PROM_WORDS_NB];
> > > u8 res_index;
> > > + const struct ms_tp_comp_consts *comp_consts;
> >
> > Please, check with `pahole` if this is the best layout.
>
> I will correct the packing on this per pahole's finding.
> > > struct ms_tp_data {
> > > const char *name;
> > > const struct ms_tp_hw_data *hw;
> > > + const struct ms_tp_comp_consts *comp_consts;
> > > };
> >
> > Can this be simply embedded into ms_tp_dev (and copied there if
> > required)?
>
> Copying in ms_tp_comp_consts provides no benefit over
> referencing the pointer; the values are per-descriptor, not
> per-instance and never modified. I'll keep the pointer (same as
> ms_tp_hw_data).
Okay, let me ask differently then: Can we use the same data type in ms_tp_dev
instead of adding basically the same fields as in ms_tp_data?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Andy Shevchenko @ 2026-06-11 19:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n0bpo6PAfdN+LGEgPYhEx8mqtu_SL=WnDxhWn-Cq4rQKA@mail.gmail.com>
On Thu, Jun 11, 2026 at 03:33:42PM +0300, Svyatoslav Ryhel wrote:
> ср, 10 черв. 2026 р. о 21:54 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > On Wed, Jun 10, 2026 at 05:45:28PM +0300, Svyatoslav Ryhel wrote:
> > > вт, 9 черв. 2026 р. о 22:23 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > > > On Sat, Jun 06, 2026 at 07:57:38AM +0300, Svyatoslav Ryhel wrote:
> > > > > Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> > > > > defined in the device tree.
...
> > > > > + int ret, i;
> > > >
> > > > No need to add 'i'.
> > >
> > > This is personal preference as well. There is no strict rule that
> > > iteration variable must be defined strictly in the for loop.
> >
> > This is a preference by Linus who is the leader of the project.
> > Also in IIO we have some set of maintainer preferences.
>
> Well, this is not meant for IIO,
Oh, my bad. I am overwhelmed with the IIO patches, automatically thought that
I am dealing with yet another IIO patch.
> though it seems that Lee is also in favor if this approach.
Good to know!
> > > > > + for (i = 0; i < led->num_leds; i++) {
> > > >
> > > > for (unsigned int i = 0; i < led->num_leds; i++) {
> > > >
> > > > > + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> > > > > + continue;
> > > > > +
> > > > > + output_cfg_shift = led->leds[i] * 2;
> > > > > + output_cfg_val |= led->id << output_cfg_shift;
> > > > > + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> > > > > + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver
From: Andy Shevchenko @ 2026-06-11 19:18 UTC (permalink / raw)
To: Wadim Mueller
Cc: Jonathan Cameron, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Maxwell Doose,
linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar
In-Reply-To: <20260611132700.671322-5-wafgo01@gmail.com>
On Thu, Jun 11, 2026 at 03:27:00PM +0200, Wadim Mueller wrote:
> Add a driver for the Sensirion SLF3S family of digital
> liquid-flow sensors on I2C. Currently supported variants are
> SLF3S-0600F, SLF3S-1300F and SLF3S-4000B; they share the same
> register map and differ only in flow-scale factor and calibrated
> measurement range. The variant (and therefore the scale) is
> auto-detected from the product-information register at probe time;
> a sensor reporting an unknown sub-type falls back to the variant
> named in the device tree, as promised by the fallback compatible.
>
> Each measurement frame returns a 16-bit signed flow value, a
> 16-bit signed temperature reading and a status word, each
> protected by a CRC-8 byte. The driver exposes the flow rate as
> IIO_VOLUMEFLOW and the temperature as IIO_TEMP via the standard
> IIO read_raw / read_scale interface.
>
> The volume-flow scale is reported in m^3/s. As the per-LSB scale
> is on the order of 1e-12 m^3/s, it is emitted as a 64-bit
> fixed-point value with femto (1e-15) resolution
> (IIO_VAL_DECIMAL64_FEMTO) so the small SI value keeps full
> precision. This relies on the IIO_VAL_DECIMAL64_FEMTO format type
> added earlier in this series, which extends the IIO_VAL_DECIMAL64
> core formatting introduced by Rodrigo Alencar's ADF41513 series.
>
> The active calibration medium can be switched at runtime between
> the factory-calibrated water and isopropyl-alcohol modes via the
> in_volumeflow_medium sysfs attribute; the sensor starts in water
> mode after probe.
>
> The sensor has no low-power state of its own, so system suspend
> stops the measurement and disables the vdd supply; resume powers
> the sensor back up, waits out the power-up time and restarts the
> measurement with the previously active medium, following the
> scd30/scd4x precedent.
>
> This driver also creates the drivers/iio/flow/ subdirectory and
> the corresponding Kconfig/Makefile glue.
...
> +#include <linux/array_size.h>
> +#include <linux/bitops.h>
> +#include <linux/cleanup.h>
> +#include <linux/crc8.h>
> +#include <linux/delay.h>
> +#include <linux/dev_printk.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
Should be err.h // PTR_ERR(), et cetera
> +#include <linux/i2c.h>
> +#include <linux/math64.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/pm.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +#include <linux/units.h>
...
> +/**
> + * struct slf3s_variant - per-variant calibration constants
> + * @sub_type: product-info sub-type byte returned by the sensor
> + * @name: name reported via @iio_dev.name
> + * @scale_num: flow scale numerator (l/s per LSB)
> + * @scale_den: flow scale denominator (l/s per LSB)
> + */
> +struct slf3s_variant {
> + u8 sub_type;
> + const char *name;
> + int scale_num;
> + int scale_den;
struct s32_fract scale;
> +};
...
> +static const struct slf3s_variant slf3s_variants[] = {
> + [0] = {
> + .sub_type = 0x03,
> + .name = "slf3s-0600f",
> + .scale_num = 1,
> + .scale_den = 600 * MICRO,
> + },
> + [1] = {
> + .sub_type = 0x02,
> + .name = "slf3s-1300f",
> + .scale_num = 1,
> + .scale_den = 30 * MICRO,
> + },
> + [2] = {
> + .sub_type = 0x05,
> + .name = "slf3s-4000b",
> + .scale_num = 1,
> + .scale_den = 1920 * MILLI,
> + },
Either split this to per HW structures, or introduce a enum for having these be
robust against any indices shuffling. The plain numbers are semantic-less, easy
to mess up with them.
> +};
...
> +/**
> + * struct slf3s_data - per-device state
> + * @client: I2C client this instance is bound to
> + * @vdd: supply regulator, disabled while suspended
> + * @variant: pointer into @slf3s_variants for the detected device
> + * @medium: currently active calibration medium
> + * @lock: serialises the multi-step command/response exchanges
> + * @crc_table: pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
> + */
> +struct slf3s_data {
> + struct i2c_client *client;
> + struct regulator *vdd;
> + const struct slf3s_variant *variant;
> + enum slf3s_medium medium;
> + struct mutex lock; /* serialises command/response exchanges */
> + u8 crc_table[CRC8_TABLE_SIZE];
Does `pahole` agree with the layout?
> +};
> +
> +static int slf3s_send_cmd(struct i2c_client *client, const u8 cmd[at_least 2])
Hmm... Do we really need to be overprotective here?
> +{
> + int ret = i2c_master_send(client, cmd, 2);
> +
> + if (ret == 2)
In long-term this is hard to maintain. The preferred way is to decouple the
assignment and the definition as the value is getting validated in the code.
> + return 0;
> +
> + return ret < 0 ? ret : -EIO;
The usual pattern is to check for errors first
if (ret < 0)
return ret;
if (ret != 2)
return -EIO;
return 0;
> +}
...
> +static int slf3s_read_sample(struct slf3s_data *sf, int *flow, int *temp)
> +{
> + /*
> + * A measurement frame is flow, temperature and a signaling-flags
> + * word, each followed by a CRC byte. Only flow and temperature are
> + * used, so the read is stopped after their two words (6 bytes).
> + */
> + u8 buf[6];
> + int ret;
> +
> + ret = i2c_master_recv(sf->client, buf, ARRAY_SIZE(buf));
sizeof() will do the job.
> + if (ret < 0)
> + return ret;
> + if (ret != ARRAY_SIZE(buf))
Ditto.
> + return -EIO;
> +
> + for (unsigned int i = 0; i < ARRAY_SIZE(buf); i += 3) {
Ditto.
> + if (!slf3s_crc_valid(sf, &buf[i]))
> + return -EIO;
> + }
> +
> + *flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
> + *temp = sign_extend32(get_unaligned_be16(&buf[3]), 15);
> +
> + return 0;
> +}
...
> +static int slf3s_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + struct slf3s_data *sf = iio_priv(indio_dev);
> + int flow, temp, ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + scoped_guard(mutex, &sf->lock)
> + ret = slf3s_read_sample(sf, &flow, &temp);
> + if (ret)
> + return ret;
> +
> + *val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
> +
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + if (chan->type == IIO_VOLUMEFLOW) {
> + /*
> + * scale_num/scale_den is the flow per LSB in l/s, but
> + * IIO reports volume flow in m^3/s (1 l = 1e-3 m^3).
> + * These values are tiny (~1.67e-12 m^3/s for the
> + * SLF3S-0600F), so emit a 64-bit fixed-point value with
> + * femto (1e-15) resolution to preserve precision.
> + * Converting l/s to m^3/s (/ MILLI) and scaling to femto
> + * (* FEMTO) leaves a net * (FEMTO / MILLI) factor.
> + */
> + const struct slf3s_variant *v = sf->variant;
> + s64 num = (s64)v->scale_num * FEMTO / MILLI;
Since the FEMTO and MILLI are of the same base, there might be better to use
them in parentheses. Can you check if that affects code generation? (I hope
compiler is smart enough to prove the above and basically simply multiply the
scale_num.)
> + s64 scale = DIV_S64_ROUND_CLOSEST(num, v->scale_den);
> +
> + iio_val_s64_decompose(scale, val, val2);
> +
> + return IIO_VAL_DECIMAL64_FEMTO;
> + }
> + /* Temperature LSB = 1/200 degC; IIO_TEMP wants milli-degC. */
> + *val = 1000 / 200;
MILLIDEGREE_PER_DEGREE ?
> +
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: pressure: ms5637: Add variant specific temperature compensation
From: Louis Adamian @ 2026-06-11 19:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
devicetree, linux-kernel
In-Reply-To: <aimvBvJp8CsNKlPU@ashevche-desk.local>
On Wed, 10 Jun 2026 21:37:58 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 09, 2026 at 10:04:58PM -0400, Louis Adamian wrote:
> > Add correct temperature compensation for ms5637-30BA,
> > MS5803-01BA,02BA, 05BA, 14BA, 30BA, MS5837-30BA. The temperature
> > compensation formula is shared across these sensors but with
> > different constants. Add ms_tp_comp_consts to capture these
> > per-device differences. Add pressure variant specific pressure
> > scale variable.
>
> Is there SPI driver? If so, why only i2c is affected?
As Jonathan noted, there is no SPI driver currently and the
modified function is only used by i2c.
> > + s64 tmp = (s64)temp - 2000;
>
> Why casting?
This is extraneous, I will remove it.
> Overall this all needs a good comment or even comments to explain all
> calculations with the references to the respective sections / tables
> / pages in the datasheet.
I'll add comments here explaining the shared equations. There are
also references to the individual datasheets in the constant structures
because they differ per device.
> > struct ms_tp_dev {
> > struct i2c_client *client;
>
> > const struct ms_tp_hw_data *hw;
> > u16 prom[MS_SENSORS_TP_PROM_WORDS_NB];
> > u8 res_index;
> > + const struct ms_tp_comp_consts *comp_consts;
>
> Please, check with `pahole` if this is the best layout.
I will correct the packing on this per pahole's finding.
> > struct ms_tp_data {
> > const char *name;
> > const struct ms_tp_hw_data *hw;
> > + const struct ms_tp_comp_consts *comp_consts;
> > };
>
> Can this be simply embedded into ms_tp_dev (and copied there if
> required)?
Copying in ms_tp_comp_consts provides no benefit over
referencing the pointer; the values are per-descriptor, not
per-instance and never modified. I'll keep the pointer (same as
ms_tp_hw_data).
> Have you considered to prepare the infrastructure in one patch and add
> the actual compensation data tables in another?
I can split this patch for V3 and I will fix the other formatting
issues.
Thanks,
Louis
^ permalink raw reply
* [PATCH] arm64: dts: qcom: glymur: fix PCIe SMMU interrupts
From: Bjorn Andersson @ 2026-06-11 19:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Qiang Yu, Raviteja Laggyshetty,
Jyothi Kumar Seerapu, Jishnu Prakash
Cc: Dmitry Baryshkov, Taniya Das, Sibi Sankar, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, Bjorn Andersson
The PCIe SMMUv3 wired interrupts are routed to GIC extended SPI INTIDs
4100, 4098 and 4096. Describe them as ESPIs with the ESPI-relative
interrupt numbers instead of regular SPIs 964, 962 and 960.
Assisted-by: Codex:GPT-5.5
Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..c7edfa8156f3 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -6874,9 +6874,9 @@ apps_smmu: iommu@15000000 {
pcie_smmu: iommu@15480000 {
compatible = "arm,smmu-v3";
reg = <0x0 0x15480000 0x0 0x20000>;
- interrupts = <GIC_SPI 964 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 962 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 960 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_ESPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_ESPI 0 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "eventq", "cmdq-sync", "gerror";
dma-coherent;
#iommu-cells = <1>;
---
base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
change-id: 20260611-glymur-pcie-smmu-espi-d8a495bd7965
Best regards,
--
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
^ permalink raw reply related
* Re: (subset) [PATCH v4 0/3] Nuvoton NPCM FIU DTS fixes and binding conversion
From: Mark Brown @ 2026-06-11 18:56 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt, Tomer Maimon
Cc: openbmc, linux-spi, devicetree, linux-kernel, avifishman70,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260609163919.3321228-1-tmaimon77@gmail.com>
On Tue, 09 Jun 2026 19:39:16 +0300, Tomer Maimon wrote:
> Nuvoton NPCM FIU DTS fixes and binding conversion
>
> This series fixes the in-tree NPCM7xx FIU controller nodes so their
> resources match what the DTS actually describes, and converts the legacy
> Nuvoton NPCM FIU binding to YAML DT schema.
>
> Patch 1 drops the bogus "memory" entry from reg-names on the NPCM7xx FIU
> nodes.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2
Thanks!
[3/3] spi: dt-bindings: nuvoton,npcm750-fiu: Convert to DT schema
https://git.kernel.org/broonie/misc/c/3da90b29241d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* 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
* Re: [PATCH 3/3] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Andy Shevchenko @ 2026-06-11 18:48 UTC (permalink / raw)
To: Nuno Sá
Cc: Paller, Kim Seer, Jonathan Cameron, David Lechner, Sa, Nuno,
Andy Shevchenko, Hennerich, Michael, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux, devicetree@vger.kernel.org
In-Reply-To: <aiqqIz8wiVjauCai@nsa>
On Thu, Jun 11, 2026 at 01:29:53PM +0100, Nuno Sá wrote:
> On Thu, Jun 11, 2026 at 07:04:37AM +0000, Paller, Kim Seer wrote:
...
> > > > static const struct regmap_config ad3530r_regmap_config = {
> > > > .reg_bits = 16,
> > > > .val_bits = 8,
> > > > - .max_register = AD3530R_MAX_REG_ADDR,
> > > > + .max_register = AD3532R_MAX_REG_ADDR,
> > >
> > > What happens if we read off the end (via debugfs) for the smaller parts?
> >
> > I tested reading registers at 0x1000 and above on AD3531R it just
> > returns 0xFF and no crash. Should I add a per-chip regmap_config to limit
> > the exposed register space?
>
> Personally, that would make sense to me.
And strictly speaking it's better in case of extending the driver with some
other features.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH RFC 9/9] arm64: dts: qcom: shikra-iqs-evk: Enable both ethernet ports
From: Mohd Ayaan Anwar @ 2026-06-11 18:37 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Enable both Gigabit Ethernet controllers. Each port has a dedicated
PHY with a gpio-hog to assert the power-enable GPIO at boot,
pin-control for the RGMII and MDIO bus, and MTL queue configuration.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 235 ++++++++++++++++++++++++++++
1 file changed, 235 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
index fd691d53a0fa8179111b921bf3bacc08884b84fb..d69b63dbc8e44f1bcec064564236ea23673bfa1f 100644
--- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
@@ -7,6 +7,7 @@
#include "shikra-iqs-som.dtsi"
#include "shikra-evk.dtsi"
+#include <dt-bindings/net/ti-dp83867.h>
/ {
model = "Qualcomm Technologies, Inc. Shikra IQS EVK";
@@ -68,6 +69,178 @@ vreg_pmu_ch1: ldo4 {
};
};
+ðernet0 {
+ status = "okay";
+ phy-handle = <ðphy0>;
+ phy-mode = "rgmii-id";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet0_defaults>;
+
+ snps,mtl-rx-config = <&emac0_mtl_rx_setup>;
+ snps,mtl-tx-config = <&emac0_mtl_tx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ 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>;
+ };
+ };
+
+ emac0_mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ emac0_mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
+ðernet1 {
+ status = "okay";
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet1_defaults>;
+
+ snps,mtl-rx-config = <&emac1_mtl_rx_setup>;
+ snps,mtl-tx-config = <&emac1_mtl_tx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@7 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <7>;
+ reset-gpios = <&tlmm 151 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>;
+ };
+ };
+
+ emac1_mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ emac1_mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
&remoteproc_cdsp {
firmware-name = "qcom/shikra/cdsp.mbn";
@@ -103,6 +276,68 @@ &sdhc_1 {
status = "okay";
};
+&tlmm {
+ ethernet0_defaults: ethernet0-defaults-state {
+ rgmii-rx-pins {
+ pins = "gpio121", "gpio122", "gpio123",
+ "gpio124", "gpio125", "gpio126";
+ function = "rgmii";
+ bias-disable;
+ drive-strength = <16>;
+ };
+ rgmii-tx-pins {
+ pins = "gpio127", "gpio128", "gpio129",
+ "gpio130", "gpio131", "gpio132";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ rgmii-mdio-pins {
+ pins = "gpio133", "gpio134";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ };
+
+ ethernet1_defaults: ethernet1-defaults-state {
+ rgmii-rx-pins {
+ pins = "gpio137", "gpio138", "gpio139",
+ "gpio140", "gpio141", "gpio142";
+ function = "rgmii";
+ bias-disable;
+ drive-strength = <16>;
+ };
+ rgmii-tx-pins {
+ pins = "gpio143", "gpio144", "gpio145",
+ "gpio146", "gpio147", "gpio148";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ rgmii-mdio-pins {
+ pins = "gpio149", "gpio150";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ };
+
+ emac0_phy_en_hog: emac0-phy-en-hog {
+ gpio-hog;
+ gpios = <66 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "emac0-phy-en";
+ };
+
+ emac1_phy_en_hog: emac1-phy-en-hog {
+ gpio-hog;
+ gpios = <53 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "emac1-phy-en";
+ };
+};
+
&uart8 {
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Mohd Ayaan Anwar @ 2026-06-11 18:37 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Enable the first Gigabit Ethernet controller. The board layout is
identical to the CQM EVK.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 119 ++++++++++++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
index 26ff8007a819e46bbc9ffa3dddc6fee6530a4a7a..1f2e4f6dd7cca436f62ba9f09cd328e5a2079095 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
@@ -7,6 +7,7 @@
#include "shikra-cqm-som.dtsi"
#include "shikra-evk.dtsi"
+#include <dt-bindings/net/ti-dp83867.h>
/ {
model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
@@ -60,6 +61,92 @@ vreg_pmu_ch1: ldo4 {
};
};
+ðernet0 {
+ status = "okay";
+ phy-handle = <ðphy0>;
+ phy-mode = "rgmii-id";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet0_defaults>;
+
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ 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>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
&remoteproc_cdsp {
firmware-name = "qcom/shikra/cdsp.mbn";
@@ -95,6 +182,38 @@ &sdhc_1 {
status = "okay";
};
+&tlmm {
+ ethernet0_defaults: ethernet0-defaults-state {
+ rgmii-rx-pins {
+ pins = "gpio121", "gpio122", "gpio123",
+ "gpio124", "gpio125", "gpio126";
+ function = "rgmii";
+ bias-disable;
+ drive-strength = <16>;
+ };
+ rgmii-tx-pins {
+ pins = "gpio127", "gpio128", "gpio129",
+ "gpio130", "gpio131", "gpio132";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ rgmii-mdio-pins {
+ pins = "gpio133", "gpio134";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ };
+
+ emac0_phy_en_hog: emac0-phy-en-hog {
+ gpio-hog;
+ gpios = <149 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "emac0-phy-en";
+ };
+};
+
&uart8 {
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 7/9] arm64: dts: qcom: shikra-cqm-evk: Enable ethernet0
From: Mohd Ayaan Anwar @ 2026-06-11 18:37 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Enable the first Gigabit Ethernet controller. Add pin-control for the
RGMII and MDIO bus, a gpio-hog to assert the PHY power-enable GPIO at
boot, and the board-level ethernet0 overlay with PHY and MTL queue
configuration.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 119 ++++++++++++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
index 683b5245923bbc1fb5df28ab7899d47a0cf8dbe7..6a6bcd2e712a1d4db5ceea4733751397779963c9 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
@@ -7,6 +7,7 @@
#include "shikra-cqm-som.dtsi"
#include "shikra-evk.dtsi"
+#include <dt-bindings/net/ti-dp83867.h>
/ {
model = "Qualcomm Technologies, Inc. Shikra CQM EVK";
@@ -60,6 +61,92 @@ vreg_pmu_ch1: ldo4 {
};
};
+ðernet0 {
+ status = "okay";
+ phy-handle = <ðphy0>;
+ phy-mode = "rgmii-id";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet0_defaults>;
+
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ 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>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
&remoteproc_cdsp {
firmware-name = "qcom/shikra/cdsp.mbn";
@@ -95,6 +182,38 @@ &sdhc_1 {
status = "okay";
};
+&tlmm {
+ ethernet0_defaults: ethernet0-defaults-state {
+ rgmii-rx-pins {
+ pins = "gpio121", "gpio122", "gpio123",
+ "gpio124", "gpio125", "gpio126";
+ function = "rgmii";
+ bias-disable;
+ drive-strength = <16>;
+ };
+ rgmii-tx-pins {
+ pins = "gpio127", "gpio128", "gpio129",
+ "gpio130", "gpio131", "gpio132";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ rgmii-mdio-pins {
+ pins = "gpio133", "gpio134";
+ function = "rgmii";
+ bias-pull-up;
+ drive-strength = <16>;
+ };
+ };
+
+ emac0_phy_en_hog: emac0-phy-en-hog {
+ gpio-hog;
+ gpios = <149 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "emac0-phy-en";
+ };
+};
+
&uart8 {
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 6/9] arm64: dts: qcom: shikra: Add ethernet nodes
From: Mohd Ayaan Anwar @ 2026-06-11 18:37 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Add the two Gigabit Ethernet controllers present on Shikra (ethernet0
at 0x5d00000, ethernet1 at 0x5d20000). Both nodes are left disabled;
board files supply the PHY, pin-control, and queue configuration.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 78 ++++++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index e67fe047a683aa566b444a847b57b4b47a25aa8a..cac1573e3eec9e52b62f4b4cd7c564c70d0d8f78 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -1990,6 +1990,84 @@ gpucc: clock-controller@5990000 {
#power-domain-cells = <1>;
};
+ ethernet0: ethernet@5d00000 {
+ compatible = "qcom,shikra-ethqos";
+ reg = <0x0 0x05d00000 0x0 0x10000>,
+ <0x0 0x05d16000 0x0 0x100>;
+ reg-names = "stmmaceth", "rgmii";
+
+ interrupts = <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ clocks = <&gcc GCC_EMAC0_AXI_CLK>,
+ <&gcc GCC_EMAC0_AHB_CLK>,
+ <&gcc GCC_EMAC0_PTP_CLK>,
+ <&gcc GCC_EMAC0_RGMII_CLK>,
+ <&gcc GCC_EMAC0_AXI_CLK>,
+ <&gcc GCC_EMAC0_AXI_SYS_NOC_CLK>,
+ <&gcc GCC_PCIE_TILE_AXI_SYS_NOC_CLK>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii",
+ "axi", "axi-noc", "pcie-tile-axi-noc";
+
+ power-domains = <&gcc GCC_EMAC0_GDSC>;
+ resets = <&gcc GCC_EMAC0_BCR>;
+ iommus = <&apps_smmu 0x0380 0x0007>;
+
+ interconnects = <&mem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ALWAYS
+ &config_noc SLAVE_EMAC0_CFG QCOM_ICC_TAG_ALWAYS>,
+ <&system_noc MASTER_EMAC_0 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-mac", "mac-mem";
+
+ snps,tso;
+ snps,pbl = <32>;
+ rx-fifo-depth = <8192>;
+ tx-fifo-depth = <8192>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ ethernet1: ethernet@5d20000 {
+ compatible = "qcom,shikra-ethqos";
+ reg = <0x0 0x05d20000 0x0 0x10000>,
+ <0x0 0x05d36000 0x0 0x100>;
+ reg-names = "stmmaceth", "rgmii";
+
+ interrupts = <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ clocks = <&gcc GCC_EMAC1_AXI_CLK>,
+ <&gcc GCC_EMAC1_AHB_CLK>,
+ <&gcc GCC_EMAC1_PTP_CLK>,
+ <&gcc GCC_EMAC1_RGMII_CLK>,
+ <&gcc GCC_EMAC1_AXI_CLK>,
+ <&gcc GCC_EMAC1_AXI_SYS_NOC_CLK>,
+ <&gcc GCC_PCIE_TILE_AXI_SYS_NOC_CLK>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii",
+ "axi", "axi-noc", "pcie-tile-axi-noc";
+
+ power-domains = <&gcc GCC_EMAC1_GDSC>;
+ resets = <&gcc GCC_EMAC1_BCR>;
+ iommus = <&apps_smmu 0x03a0 0x0007>;
+
+ interconnects = <&mem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ALWAYS
+ &config_noc SLAVE_EMAC1_CFG QCOM_ICC_TAG_ALWAYS>,
+ <&system_noc MASTER_EMAC_1 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-mac", "mac-mem";
+
+ snps,tso;
+ snps,pbl = <32>;
+ rx-fifo-depth = <8192>;
+ tx-fifo-depth = <8192>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
dispcc: clock-controller@5f00000 {
compatible = "qcom,shikra-dispcc", "qcom,qcm2290-dispcc";
reg = <0x0 0x05f00000 0x0 0x20000>;
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 5/9] net: stmmac: qcom-ethqos: add Shikra EMAC support
From: Mohd Ayaan Anwar @ 2026-06-11 18:37 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Shikra integrates two Qualcomm ETHQOS controllers based on the Synopsys
GMAC IP, similar to previous platforms. Register qcom,shikra-ethqos
backed by a new shikra_data descriptor that enables the three NOC clocks
required for DMA memory access and the 36-bit DMA address width.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index f4d4b419a76277cc6c56f03bb10d883cd4dff424..59fa8779e4e4628ae585dd5625168fca824662b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -326,6 +326,36 @@ static const struct ethqos_emac_driver_data emac_v4_0_0_data = {
},
};
+static const struct ethqos_noc_clk_cfg shikra_noc_clks[] = {
+ { "axi", 120000000 },
+ { "axi-noc", 120000000 },
+ { "pcie-tile-axi-noc", 120000000 },
+};
+
+static const struct ethqos_emac_driver_data shikra_data = {
+ .dma_addr_width = 36,
+ .has_emac_ge_3 = true,
+ .noc_clk_cfg = shikra_noc_clks,
+ .num_noc_clks = ARRAY_SIZE(shikra_noc_clks),
+ .rgmii_config_loopback_en = false,
+ .dwmac4_addrs = {
+ .dma_chan = 0x00008100,
+ .dma_chan_offset = 0x1000,
+ .mtl_chan = 0x00008000,
+ .mtl_chan_offset = 0x1000,
+ .mtl_ets_ctrl = 0x00008010,
+ .mtl_ets_ctrl_offset = 0x1000,
+ .mtl_txq_weight = 0x00008018,
+ .mtl_txq_weight_offset = 0x1000,
+ .mtl_send_slp_cred = 0x0000801c,
+ .mtl_send_slp_cred_offset = 0x1000,
+ .mtl_high_cred = 0x00008020,
+ .mtl_high_cred_offset = 0x1000,
+ .mtl_low_cred = 0x00008024,
+ .mtl_low_cred_offset = 0x1000,
+ },
+};
+
static int ethqos_dll_configure(struct qcom_ethqos *ethqos)
{
struct device *dev = ðqos->pdev->dev;
@@ -915,6 +945,7 @@ static const struct of_device_id qcom_ethqos_match[] = {
{ .compatible = "qcom,qcs404-ethqos", .data = &emac_v2_3_0_data},
{ .compatible = "qcom,sa8775p-ethqos", .data = &emac_v4_0_0_data},
{ .compatible = "qcom,sc8280xp-ethqos", .data = &emac_v3_0_0_data},
+ { .compatible = "qcom,shikra-ethqos", .data = &shikra_data},
{ .compatible = "qcom,sm8150-ethqos", .data = &emac_v2_1_0_data},
{ }
};
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 4/9] net: stmmac: qcom-ethqos: add per-platform NOC clock voting
From: Mohd Ayaan Anwar @ 2026-06-11 18:37 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Some SoCs gate the EMAC's path to the System NOC behind dedicated clocks
that must be enabled before the DMA can reach memory. Add
ethqos_noc_clk_cfg and the corresponding fields in the driver-data and
runtime structs so each compatible can declare its own set with per-clock
rates. The clocks are acquired during probe and enabled/disabled
alongside the existing link clock in ethqos_clks_config().
No functional change for existing compatibles. This will help us when
we add support for Shikra.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index bec08f1eb8cb41484ba3c91c77393e163e7fd071..f4d4b419a76277cc6c56f03bb10d883cd4dff424 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -84,11 +84,18 @@
#define SGMII_10M_RX_CLK_DVDR 0x31
+#define ETHQOS_MAX_NOC_CLKS 3
+
struct ethqos_emac_por {
unsigned int offset;
unsigned int value;
};
+struct ethqos_noc_clk_cfg {
+ const char *id;
+ unsigned long rate;
+};
+
struct ethqos_emac_driver_data {
const struct ethqos_emac_por *rgmii_por;
unsigned int num_rgmii_por;
@@ -98,6 +105,8 @@ struct ethqos_emac_driver_data {
const char *link_clk_name;
struct dwmac4_addrs dwmac4_addrs;
bool needs_sgmii_loopback;
+ const struct ethqos_noc_clk_cfg *noc_clk_cfg;
+ unsigned int num_noc_clks;
};
struct qcom_ethqos {
@@ -112,6 +121,9 @@ struct qcom_ethqos {
bool rgmii_config_loopback_en;
bool has_emac_ge_3;
bool needs_sgmii_loopback;
+
+ struct clk_bulk_data noc_clks[ETHQOS_MAX_NOC_CLKS];
+ int num_noc_clks;
};
static u32 rgmii_readl(struct qcom_ethqos *ethqos, unsigned int offset)
@@ -696,6 +708,17 @@ static int ethqos_clks_config(void *priv, bool enabled)
return ret;
}
+ if (ethqos->num_noc_clks) {
+ ret = clk_bulk_prepare_enable(ethqos->num_noc_clks,
+ ethqos->noc_clks);
+ if (ret) {
+ dev_err(ðqos->pdev->dev,
+ "NOC clocks enable failed: %d\n", ret);
+ clk_disable_unprepare(ethqos->link_clk);
+ return ret;
+ }
+ }
+
/* Enable functional clock to prevent DMA reset to timeout due
* to lacking PHY clock after the hardware block has been power
* cycled. The actual configuration will be adjusted once
@@ -704,6 +727,9 @@ static int ethqos_clks_config(void *priv, bool enabled)
qcom_ethqos_set_sgmii_loopback(ethqos, true);
ethqos_set_func_clk_en(ethqos);
} else {
+ if (ethqos->num_noc_clks)
+ clk_bulk_disable_unprepare(ethqos->num_noc_clks,
+ ethqos->noc_clks);
clk_disable_unprepare(ethqos->link_clk);
}
@@ -732,6 +758,37 @@ static void ethqos_ptp_clk_freq_config(struct stmmac_priv *priv)
netdev_dbg(priv->dev, "PTP rate %lu\n", plat_dat->clk_ptp_rate);
}
+/*
+ * Some SoCs gate interconnect access to the System NOC behind dedicated
+ * clocks. Acquire them, set their required rates, and store the result in
+ * ethqos so ethqos_clks_config() can enable/disable them at runtime.
+ */
+static int qcom_ethqos_init_noc_clks(struct qcom_ethqos *ethqos,
+ const struct ethqos_emac_driver_data *data)
+{
+ struct device *dev = ðqos->pdev->dev;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < data->num_noc_clks; i++)
+ ethqos->noc_clks[i].id = data->noc_clk_cfg[i].id;
+ ethqos->num_noc_clks = data->num_noc_clks;
+
+ ret = devm_clk_bulk_get(dev, ethqos->num_noc_clks, ethqos->noc_clks);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get NOC clocks\n");
+
+ for (i = 0; i < data->num_noc_clks; i++) {
+ ret = clk_set_rate(ethqos->noc_clks[i].clk,
+ data->noc_clk_cfg[i].rate);
+ if (ret)
+ dev_warn(dev, "Failed to set %s rate: %d\n",
+ data->noc_clk_cfg[i].id, ret);
+ }
+
+ return 0;
+}
+
static int qcom_ethqos_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -791,6 +848,12 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
ethqos->has_emac_ge_3 = data->has_emac_ge_3;
ethqos->needs_sgmii_loopback = data->needs_sgmii_loopback;
+ if (data->num_noc_clks) {
+ ret = qcom_ethqos_init_noc_clks(ethqos, data);
+ if (ret)
+ return ret;
+ }
+
ethqos->link_clk = devm_clk_get(dev, data->link_clk_name ?: "rgmii");
if (IS_ERR(ethqos->link_clk))
return dev_err_probe(dev, PTR_ERR(ethqos->link_clk),
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Mohd Ayaan Anwar @ 2026-06-11 18:36 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
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.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 65 +++++++++++++++++++++-
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 44270c25d874f72e7f971757fec659d36468c315..bec08f1eb8cb41484ba3c91c77393e163e7fd071 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -67,6 +67,9 @@
/* SDC4_STATUS bits */
#define SDC4_STATUS_DLL_LOCK BIT(7)
+/* SDCC_USR_CTL bits */
+#define SDCC_USR_CTL_DDR_BYPASS BIT(30)
+
/* RGMII_IO_MACRO_CONFIG2 fields */
#define RGMII_CONFIG2_RSVD_CONFIG15 GENMASK(31, 17)
#define RGMII_CONFIG2_RGMII_CLK_SEL_CFG BIT(16)
@@ -183,7 +186,15 @@ static int ethqos_set_clk_tx_rate(void *bsp_priv, struct clk *clk_tx_i,
if (rate < 0)
return rate;
- return clk_set_rate(ethqos->link_clk, rate * 2);
+ /* Clock Rate Requirements:
+ * MAC added delay: 250/50/5 Mhz for 1G/100M/10M
+ * No MAC delay (DLL bypass): 250/25/2.5 Mhz for 1G/100M/10M
+ */
+ if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII ||
+ speed == SPEED_1000)
+ rate *= 2;
+
+ return clk_set_rate(ethqos->link_clk, rate);
}
static void
@@ -405,8 +416,7 @@ static void ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
RGMII_IO_MACRO_CONFIG2);
/* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
- if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
- ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
+ if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
phase_shift = 0;
else
phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
@@ -475,6 +485,40 @@ static void ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
RGMII_IO_MACRO_CONFIG);
}
+static void ethqos_rgmii_id_macro_init(struct qcom_ethqos *ethqos, int speed)
+{
+ rgmii_clrmask(ethqos, RGMII_CONFIG2_TX_TO_RX_LOOPBACK_EN,
+ RGMII_IO_MACRO_CONFIG2);
+
+ if (speed == SPEED_1000)
+ rgmii_setmask(ethqos, RGMII_CONFIG_DDR_MODE, RGMII_IO_MACRO_CONFIG);
+ else
+ rgmii_clrmask(ethqos, RGMII_CONFIG_DDR_MODE, RGMII_IO_MACRO_CONFIG);
+ rgmii_setmask(ethqos, RGMII_CONFIG_BYPASS_TX_ID_EN, RGMII_IO_MACRO_CONFIG);
+ rgmii_clrmask(ethqos, RGMII_CONFIG_POS_NEG_DATA_SEL, RGMII_IO_MACRO_CONFIG);
+ rgmii_clrmask(ethqos, RGMII_CONFIG_PROG_SWAP, RGMII_IO_MACRO_CONFIG);
+
+ if (ethqos->has_emac_ge_3)
+ rgmii_clrmask(ethqos, RGMII_CONFIG2_DATA_DIVIDE_CLK_SEL,
+ RGMII_IO_MACRO_CONFIG2);
+ else
+ rgmii_setmask(ethqos, RGMII_CONFIG2_DATA_DIVIDE_CLK_SEL,
+ RGMII_IO_MACRO_CONFIG2);
+
+ rgmii_clrmask(ethqos, RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN,
+ RGMII_IO_MACRO_CONFIG2);
+
+ if (speed == SPEED_1000)
+ rgmii_clrmask(ethqos, RGMII_CONFIG2_RSVD_CONFIG15, RGMII_IO_MACRO_CONFIG2);
+ else
+ rgmii_setmask(ethqos, RGMII_CONFIG2_RSVD_CONFIG15, RGMII_IO_MACRO_CONFIG2);
+
+ if (!ethqos->rgmii_config_loopback_en)
+ rgmii_clrmask(ethqos, RGMII_CONFIG_LOOPBACK_EN, RGMII_IO_MACRO_CONFIG);
+
+ rgmii_setmask(ethqos, RGMII_CONFIG2_RX_PROG_SWAP, RGMII_IO_MACRO_CONFIG2);
+}
+
static void ethqos_fix_mac_speed_rgmii(void *bsp_priv,
phy_interface_t interface, int speed,
unsigned int mode)
@@ -493,6 +537,21 @@ static void ethqos_fix_mac_speed_rgmii(void *bsp_priv,
ethqos_set_func_clk_en(ethqos);
+ /* For rgmii-id mode, the PHY should add the required delays.
+ * Therefore, power down the DLL and program it in bypass mode.
+ * Program the IO_MACRO as per the settings recommended by the
+ * programming guide for bypass mode. This will ensure that the
+ * MAC core doesn't add any additional delays.
+ */
+ if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID) {
+ rgmii_setmask(ethqos, SDCC_DLL_CONFIG_PDN, SDCC_HC_REG_DLL_CONFIG);
+ rgmii_setmask(ethqos, SDCC_USR_CTL_DDR_BYPASS, SDCC_USR_CTL);
+
+ ethqos_rgmii_id_macro_init(ethqos, speed);
+
+ return;
+ }
+
/* Initialize the DLL first */
/* Set DLL_RST */
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 2/9] net: stmmac: qcom-ethqos: convert ethqos_rgmii_macro_init() to void
From: Mohd Ayaan Anwar @ 2026-06-11 18:36 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
The return value is never checked by its sole caller and the speed
validation duplicates a check higher up the call stack. Convert to
void and remove the dead code.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index ac7d6d3e205a1ab5b391def879d6f1033a0961b6..44270c25d874f72e7f971757fec659d36468c315 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -371,9 +371,8 @@ static int ethqos_dll_configure(struct qcom_ethqos *ethqos)
return 0;
}
-static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
+static void ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
{
- struct device *dev = ðqos->pdev->dev;
unsigned int prg_rclk_dly, loopback;
unsigned int phase_shift;
@@ -384,11 +383,6 @@ static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
/* Select RGMII, write 0 to interface select */
rgmii_clrmask(ethqos, RGMII_CONFIG_INTF_SEL, RGMII_IO_MACRO_CONFIG);
- if (speed != SPEED_1000 && speed != SPEED_100 && speed != SPEED_10) {
- dev_err(dev, "Invalid speed %d\n", speed);
- return -EINVAL;
- }
-
rgmii_setmask(ethqos, RGMII_CONFIG_DDR_MODE, RGMII_IO_MACRO_CONFIG);
if (speed == SPEED_1000) {
@@ -479,8 +473,6 @@ static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
rgmii_updatel(ethqos, RGMII_CONFIG_LOOPBACK_EN, loopback,
RGMII_IO_MACRO_CONFIG);
-
- return 0;
}
static void ethqos_fix_mac_speed_rgmii(void *bsp_priv,
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 1/9] dt-bindings: net: qcom,ethqos: add qcom,shikra-ethqos compatible
From: Mohd Ayaan Anwar @ 2026-06-11 18:36 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
In-Reply-To: <20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com>
Shikra's EMAC requires three additional clocks beyond the standard four
(axi, axi-noc, pcie-tile-axi-noc) for NOC interconnect voting. Add the
compatible string and extend clock-names with a oneOf variant for this
seven-clock configuration.
The AXI clock appears twice (as "stmmaceth" and "axi") because the
stmmac core and the driver's NOC bulk-clock array each consume one
reference; CCF refcounting makes this safe.
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
.../devicetree/bindings/net/qcom,ethqos.yaml | 31 ++++++++++++++++------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
index 423959cb928d945aa3e758a3c803d12bd61ec42b..4528946856c8c6e33bc6ad4159ed111f35ec37d9 100644
--- a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
@@ -32,6 +32,7 @@ properties:
- qcom,qcs404-ethqos
- qcom,sa8775p-ethqos
- qcom,sc8280xp-ethqos
+ - qcom,shikra-ethqos
- qcom,sm8150-ethqos
reg:
@@ -57,16 +58,30 @@ properties:
- const: sfty
clocks:
- maxItems: 4
+ minItems: 4
+ maxItems: 7
clock-names:
- items:
- - const: stmmaceth
- - const: pclk
- - const: ptp_ref
- - enum:
- - rgmii
- - phyaux
+ oneOf:
+ - items:
+ - const: stmmaceth
+ - const: pclk
+ - const: ptp_ref
+ - enum:
+ - rgmii
+ - phyaux
+ - description: |
+ Extended clock list for platforms with AXI NOC clocks that require
+ explicit driver management (e.g. Shikra). GCC_EMAC0_AXI_CLK appears
+ as both "stmmaceth" and "axi"; CCF refcounting makes this safe.
+ items:
+ - const: stmmaceth
+ - const: pclk
+ - const: ptp_ref
+ - const: rgmii
+ - const: axi
+ - const: axi-noc
+ - const: pcie-tile-axi-noc
iommus:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH RFC 0/9] net: stmmac: qcom-ethqos: add Shikra EMAC support
From: Mohd Ayaan Anwar @ 2026-06-11 18:36 UTC (permalink / raw)
To: 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
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Mohd Ayaan Anwar
(Sending this out as an RFC because we have a couple of fixes for RGMII
handling in dwmac-qcom-ethqos, as well as a new framework to manage
clocks required by the System NOC. If this gets into a decent shape,
then this series will be split between patches for DT and net-next.)
Hi,
This series adds Gigabit Ethernet support for the Qualcomm Shikra SoC,
which integrates two EMAC controllers based on the Synopsys GMAC IP,
similar to previous Qualcomm platforms.
Before introducing the new compatible, two generic fixes are applied to
the driver that benefit all platforms:
- ethqos_rgmii_macro_init() is converted to void; the return value was
never checked and the speed validation was redundant.
- RGMII_ID mode ("rgmii-id") was incorrectly falling through to the
standard DLL bring-up path, which may add MAC-internal delays. The
fix powers down the DLL, sets DDR bypass mode, and programs the
IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. The clock
rate doubling in ethqos_set_clk_tx_rate() is also corrected for
bypass mode.
Shikra-specific additions:
- On Shikra, access to the System NOC from the EMAC is gated by three
dedicated clocks. The axi and axi-noc clocks are sourced from a
dedicated RCG (emac0_axi_clk_srcg) per EMAC instance. The
pcie-tile-axi-noc clock (gcc_pcie_tile_axi_sys_noc_clk) gates an
arbiter internal to the NOC shared by both EMAC instances and must
be enabled for any EMAC-to-DDR traffic to complete. Generic
infrastructure is introduced (ethqos_noc_clk_cfg) so future
platforms can declare their own sets.
- The qcom,shikra-ethqos compatible is registered.
- DTS for the SoC and three EVK boards (CQM, CQS, IQS) is included.
The CQM and CQS boards expose one EMAC; the IQS board exposes both.
Dependencies:
This series is based on linux-next and depends on the core Shikra SoC
framework (DT, clock, regulator) being merged.
Tested on the Shikra CQM-EVK, CQS-EVK, and IQS-EVK with rgmii-id mode
at 1G/100M/10M speeds.
---
Mohd Ayaan Anwar (9):
dt-bindings: net: qcom,ethqos: add qcom,shikra-ethqos compatible
net: stmmac: qcom-ethqos: convert ethqos_rgmii_macro_init() to void
net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
net: stmmac: qcom-ethqos: add per-platform NOC clock voting
net: stmmac: qcom-ethqos: add Shikra EMAC support
arm64: dts: qcom: shikra: Add ethernet nodes
arm64: dts: qcom: shikra-cqm-evk: Enable ethernet0
arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
arm64: dts: qcom: shikra-iqs-evk: Enable both ethernet ports
.../devicetree/bindings/net/qcom,ethqos.yaml | 31 ++-
arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 119 +++++++++++
arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 119 +++++++++++
arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 235 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/shikra.dtsi | 78 +++++++
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 167 ++++++++++++++-
6 files changed, 730 insertions(+), 19 deletions(-)
---
base-commit: 999ed3289ceea2b2808f396b4bd2f9a43dcba033
change-id: 20260611-shikra_ethernet-11a1b318d5b6
Best regards,
--
Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 1/5] dt-bindings: arm: qcom: Document Shikra and its EVK boards
From: Rob Herring @ 2026-06-11 18:18 UTC (permalink / raw)
To: Komal Bajaj
Cc: Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Neil Armstrong, Wesley Cheng, Ulf Hansson,
linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara
In-Reply-To: <20260611-shikra-dt-v5-1-103ed26a8529@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 03:40:08PM +0530, Komal Bajaj wrote:
> Shikra is a Qualcomm IoT SoC available in a System-on-Module (SoM)
> form factor. The SoM integrates the Shikra SoC, PMICs, and essential
> passives, and is designed to be mounted on carrier boards.
>
> Three eSoM variant are introduced:
> - CQM: retail variant with integrated modem (PM4125 and PM8005 PMIC)
> - CQS: retail variant without modem (PM4125 and PM8005 PMIC)
> - IQS: industrial-grade variant without modem (PM8150 PMIC)
>
> Each SoM variant pairs with a common EVK carrier board provides debug
> UART, USB, and other peripheral interfaces.
>
> Add compatible strings for the CQ2390M, CQ2390S, IQ2390S SoM variant and
> its corresponding EVK boards.
>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Missing Krzysztof's reviewed-by.
^ 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