* Re: [PATCH mt76] wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S
From: Lorenzo Bianconi @ 2026-04-08 9:34 UTC (permalink / raw)
To: Zenm Chen
Cc: nbd, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <20260407154430.9184-1-zenmchen@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
On Apr 07, Zenm Chen wrote:
> Add the ID 056e:400a to the table to support an additional MT7612U
> adapter: ELECOM WDC-867SU3S.
>
> Compile tested only.
>
> Cc: stable@vger.kernel.org # 5.10.x
I do not think this material for stable. Anyway:
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Zenm Chen <zenmchen@gmail.com>
> ---
> This ID was found from [1] and adding it to the device table should be
> enough to make it work. Hardware probes at [2] can prove its existence.
>
> [1] https://bushowhige.blogspot.com/2019/08/ubuntu-1804-mediatek-usb-wi-fi.html
> [2] https://linux-hardware.org/?id=usb:056e-400a
> ---
> drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
> index 01cb3b283..459c4044f 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
> @@ -16,6 +16,7 @@ static const struct usb_device_id mt76x2u_device_table[] = {
> { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USBAC1200 - Alfa AWUS036ACM */
> { USB_DEVICE(0x057c, 0x8503) }, /* Avm FRITZ!WLAN AC860 */
> { USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
> + { USB_DEVICE(0x056e, 0x400a) }, /* ELECOM WDC-867SU3S */
> { USB_DEVICE(0x0e8d, 0x7632) }, /* HC-M7662BU1 */
> { USB_DEVICE(0x0471, 0x2126) }, /* LiteOn WN4516R module, nonstandard USB connector */
> { USB_DEVICE(0x0471, 0x7600) }, /* LiteOn WN4519R module, nonstandard USB connector */
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH RFC net-next 06/10] net: stmmac: dche is only for GMAC4 cores
From: Russell King (Oracle) @ 2026-04-08 9:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
dma_cfg->dche is only read by dwmac4_dma_init(), which is only called
for the DWMAC_CORE_GMAC4 core type. Rather than having a bare IP
version check that can match any core type, make this conditional on
DWMAC_CORE_GMAC4 to make it clear that it's a GMAC4 feature.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 295d31d7b28b..e47321119c83 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7895,9 +7895,10 @@ static int __stmmac_dvr_probe(struct device *device,
if (ret)
goto error_hw_init;
- /* Only DWMAC core version 5.20 onwards supports HW descriptor prefetch.
+ /* Only DWMAC4 core version 5.20 onwards support HW descriptor prefetch.
*/
- if (priv->snpsver < DWMAC_CORE_5_20)
+ if (priv->plat->core_type != DWMAC_CORE_GMAC4 ||
+ priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
stmmac_check_ether_addr(priv);
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 05/10] net: stmmac: rename confusing synopsys_id
From: Russell King (Oracle) @ 2026-04-08 9:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
priv->synopsys_id is the Synopsys IP version, defined by snpsver in
the databook. This is made up of the major version in bits 7:4 and
the first digit of the minor version in bits 3:0. Change the type
for synopsys_id to be a u8 and rename to snpsver.
For reference, the values for snpsver:
GMAC100 cores do not have a readable snpsver number.
GMAC cores generally have a snpsver number less than 0x40.
GMAC4 cores may have a version number that overlaps GMAC cores
(see first entry for DWMAC_CORE_GMAC4).
XGMAC and XLGMAC cores each have an entirely separate IP version
number space from GMAC and GMAC4, which are distinguished by their
respective userver.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/hwif.c | 10 +++++-----
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 ++++++------
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 ++++----
8 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index eb14c197d6ae..789b384a2838 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -326,7 +326,7 @@ static int loongson_dwmac_setup(void *apriv, struct mac_device_info *mac)
* original value so the correct HW-interface would be selected.
*/
if (ld->multichan) {
- priv->synopsys_id = DWMAC_CORE_3_70;
+ priv->snpsver = DWMAC_CORE_3_70;
*dma = dwmac1000_dma_ops;
dma->init_chan = loongson_dwmac_dma_init_channel;
dma->dma_interrupt = loongson_dwmac_dma_interrupt;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 48c52eb96233..4bff7592c652 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1069,7 +1069,7 @@ static int sun8i_dwmac_setup(void *ppriv, struct mac_device_info *mac)
mac->unicast_filter_entries = 8;
/* Synopsys Id is not available */
- priv->synopsys_id = 0;
+ priv->snpsver = 0;
return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 03437f1cf3df..635d711a554e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -380,7 +380,7 @@ static int dwxgmac2_get_hw_feature(void __iomem *ioaddr,
dma_cap->vlhash = (hw_cap & XGMAC_HWFEAT_VLHASH) >> 4;
dma_cap->half_duplex = (hw_cap & XGMAC_HWFEAT_HDSEL) >> 3;
dma_cap->mbps_1000 = (hw_cap & XGMAC_HWFEAT_GMIISEL) >> 1;
- if (dma_cap->mbps_1000 && priv->synopsys_id >= DWXGMAC_CORE_2_20)
+ if (dma_cap->mbps_1000 && priv->snpsver >= DWXGMAC_CORE_2_20)
dma_cap->mbps_10_100 = 1;
/* MAC HW feature 1 */
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 7f95a2a5be4c..e5629afc391f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -72,7 +72,7 @@ static int stmmac_dwmac1_quirks(struct stmmac_priv *priv)
dev_info(priv->device, "Enhanced/Alternate descriptors\n");
/* GMAC older than 3.50 has no extended descriptors */
- if (priv->synopsys_id >= DWMAC_CORE_3_50) {
+ if (priv->snpsver >= DWMAC_CORE_3_50) {
dev_info(priv->device, "Enabled extended descriptors\n");
priv->extend_desc = true;
} else {
@@ -299,7 +299,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 userver)
if (core_type != entry->core_type)
continue;
- /* Use synopsys_id var because some setups can override this */
+ /* Use snpsver var because some setups can override this */
if (snpsver < entry->min_snpsver)
continue;
if (core_type == DWMAC_CORE_XGMAC &&
@@ -324,7 +324,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
stmmac_get_version(priv, &version);
/* Save ID for later use */
- priv->synopsys_id = version.snpsver;
+ priv->snpsver = version.snpsver;
/* Lets assume some safe values first */
if (core_type == DWMAC_CORE_GMAC4) {
@@ -355,8 +355,8 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
/* Fallback to generic HW */
- /* Use synopsys_id var because some setups can override this */
- entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.userver);
+ /* Use snpsver var because some setups can override this */
+ entry = stmmac_hwif_find(core_type, priv->snpsver, version.userver);
if (!entry) {
dev_err(priv->device,
"Failed to find HW IF (id=0x%x, gmac=%d/%d)\n",
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 8ba8f03e1ce0..9a5d9c404e4f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -304,7 +304,7 @@ struct stmmac_priv {
struct dma_features dma_cap;
struct stmmac_counters mmc;
int hw_cap_support;
- int synopsys_id;
+ u8 snpsver;
u32 msg_enable;
/* Our MAC Wake-on-Lan options */
int wolopts;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 92585d27ab88..343cf903c0bf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -553,7 +553,7 @@ static void stmmac_get_ethtool_stats(struct net_device *dev,
priv->xstats.phy_eee_wakeup_error_n = val;
}
- if (priv->synopsys_id >= DWMAC_CORE_3_50)
+ if (priv->snpsver >= DWMAC_CORE_3_50)
stmmac_mac_debug(priv, priv->ioaddr,
(void *)&priv->xstats,
rx_queues_count, tx_queues_count);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 01a983001ab4..295d31d7b28b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -755,7 +755,7 @@ static int stmmac_hwtstamp_set(struct net_device *dev,
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
- if (priv->synopsys_id < DWMAC_CORE_4_10)
+ if (priv->snpsver < DWMAC_CORE_4_10)
ts_event_en = PTP_TCR_TSEVNTENA;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -6624,7 +6624,7 @@ static int stmmac_dma_cap_show(struct seq_file *seq, void *v)
seq_printf(seq, "\tAV features: %s\n", (priv->dma_cap.av) ? "Y" : "N");
seq_printf(seq, "\tChecksum Offload in TX: %s\n",
(priv->dma_cap.tx_coe) ? "Y" : "N");
- if (priv->synopsys_id >= DWMAC_CORE_4_00 ||
+ if (priv->snpsver >= DWMAC_CORE_4_00 ||
priv->plat->core_type == DWMAC_CORE_XGMAC) {
seq_printf(seq, "\tIP Checksum Offload in RX: %s\n",
(priv->dma_cap.rx_coe) ? "Y" : "N");
@@ -7454,7 +7454,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
if (priv->plat->rx_coe) {
priv->hw->rx_csum = priv->plat->rx_coe;
dev_info(priv->device, "RX Checksum Offload Engine supported\n");
- if (priv->synopsys_id < DWMAC_CORE_4_00)
+ if (priv->snpsver < DWMAC_CORE_4_00)
dev_info(priv->device, "COE Type %d\n", priv->hw->rx_csum);
}
if (priv->plat->tx_coe)
@@ -7520,7 +7520,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
* has to be disable and this can be done by passing the
* riwt_off field from the platform.
*/
- if ((priv->synopsys_id >= DWMAC_CORE_3_50 ||
+ if ((priv->snpsver >= DWMAC_CORE_3_50 ||
priv->plat->core_type == DWMAC_CORE_XGMAC) &&
!priv->plat->riwt_off) {
priv->use_riwt = 1;
@@ -7897,7 +7897,7 @@ static int __stmmac_dvr_probe(struct device *device,
/* Only DWMAC core version 5.20 onwards supports HW descriptor prefetch.
*/
- if (priv->synopsys_id < DWMAC_CORE_5_20)
+ if (priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
stmmac_check_ether_addr(priv);
@@ -7997,7 +7997,7 @@ static int __stmmac_dvr_probe(struct device *device,
if (priv->plat->core_type == DWMAC_CORE_XGMAC)
ndev->max_mtu = XGMAC_JUMBO_LEN;
- else if (priv->plat->enh_desc || priv->synopsys_id >= DWMAC_CORE_4_00)
+ else if (priv->plat->enh_desc || priv->snpsver >= DWMAC_CORE_4_00)
ndev->max_mtu = JUMBO_LEN;
else
ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index afe98ff5bdcb..0107119f68d2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -74,7 +74,7 @@ static void stmmac_xgmac2_c22_format(struct stmmac_priv *priv, int phyaddr,
{
u32 tmp = 0;
- if (priv->synopsys_id < DWXGMAC_CORE_2_20) {
+ if (priv->snpsver < DWXGMAC_CORE_2_20) {
/* Until ver 2.20 XGMAC does not support C22 addr >= 4. Those
* bits above bit 3 of XGMAC_MDIO_C22P register are reserved.
*/
@@ -136,7 +136,7 @@ static int stmmac_xgmac2_mdio_read_c22(struct mii_bus *bus, int phyaddr,
u32 addr;
/* Until ver 2.20 XGMAC does not support C22 addr >= 4 */
- if (priv->synopsys_id < DWXGMAC_CORE_2_20 &&
+ if (priv->snpsver < DWXGMAC_CORE_2_20 &&
phyaddr > MII_XGMAC_MAX_C22ADDR)
return -ENODEV;
@@ -199,7 +199,7 @@ static int stmmac_xgmac2_mdio_write_c22(struct mii_bus *bus, int phyaddr,
u32 addr;
/* Until ver 2.20 XGMAC does not support C22 addr >= 4 */
- if (priv->synopsys_id < DWXGMAC_CORE_2_20 &&
+ if (priv->snpsver < DWXGMAC_CORE_2_20 &&
phyaddr > MII_XGMAC_MAX_C22ADDR)
return -ENODEV;
@@ -625,7 +625,7 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->read_c45 = &stmmac_xgmac2_mdio_read_c45;
new_bus->write_c45 = &stmmac_xgmac2_mdio_write_c45;
- if (priv->synopsys_id < DWXGMAC_CORE_2_20) {
+ if (priv->snpsver < DWXGMAC_CORE_2_20) {
/* Right now only C22 phys are supported */
max_addr = MII_XGMAC_MAX_C22ADDR;
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 04/10] net: stmmac: use ver->userver and ver->snpsver to print version
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
Rather than using FIELD_GET() twice, reorder the code to extract the
version fields into struct stmmac_version, and then print them.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index aacf78d4a2ee..7f95a2a5be4c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -42,12 +42,11 @@ static void stmmac_get_version(struct stmmac_priv *priv,
return;
}
- dev_info(priv->device, "User ID: 0x%x, Synopsys ID: 0x%x\n",
- FIELD_GET(DWMAC_USERVER, version),
- FIELD_GET(DWMAC_SNPSVER, version));
-
ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
ver->userver = FIELD_GET(DWMAC_USERVER, version);
+
+ dev_info(priv->device, "User ID: 0x%x, Synopsys ID: 0x%x\n",
+ ver->userver, ver->snpsver);
}
static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 03/10] net: stmmac: always fill in ver->userver
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
Always fill in ver->userver irrespective of the core type. This has no
functional impact but tidies up the code by removing an unnecessary
conditional.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 830ff816ab4f..aacf78d4a2ee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -47,8 +47,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
FIELD_GET(DWMAC_SNPSVER, version));
ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
- if (core_type == DWMAC_CORE_XGMAC)
- ver->userver = FIELD_GET(DWMAC_USERVER, version);
+ ver->userver = FIELD_GET(DWMAC_USERVER, version);
}
static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 02/10] net: stmmac: rename dev_id to userver
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
The Synopsys Databook and several implementation TRMs identify bits
15:8 of the version register in dwmac v3.xx and v4.xx as "userver".
We even print its value with "User ID". Rather than using "dev_id",
use "userver" instead.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 3774af66db48..830ff816ab4f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -15,7 +15,7 @@
struct stmmac_version {
u8 snpsver;
- u8 dev_id;
+ u8 userver;
};
static void stmmac_get_version(struct stmmac_priv *priv,
@@ -26,7 +26,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
u32 version;
ver->snpsver = 0;
- ver->dev_id = 0;
+ ver->userver = 0;
if (core_type == DWMAC_CORE_MAC100)
return;
@@ -48,7 +48,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
if (core_type == DWMAC_CORE_XGMAC)
- ver->dev_id = FIELD_GET(DWMAC_USERVER, version);
+ ver->userver = FIELD_GET(DWMAC_USERVER, version);
}
static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
@@ -111,7 +111,7 @@ int stmmac_reset(struct stmmac_priv *priv)
static const struct stmmac_hwif_entry {
enum dwmac_core_type core_type;
u32 min_snpsver;
- u32 dev_id;
+ u32 userver;
const struct stmmac_regs_off regs;
const void *desc;
const void *dma;
@@ -247,7 +247,7 @@ static const struct stmmac_hwif_entry {
}, {
.core_type = DWMAC_CORE_XGMAC,
.min_snpsver = DWXGMAC_CORE_2_10,
- .dev_id = DWXGMAC_ID,
+ .userver = DWXGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
.mmc_off = MMC_XGMAC_OFFSET,
@@ -269,7 +269,7 @@ static const struct stmmac_hwif_entry {
}, {
.core_type = DWMAC_CORE_XGMAC,
.min_snpsver = DWXLGMAC_CORE_2_00,
- .dev_id = DWXLGMAC_ID,
+ .userver = DWXLGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
.mmc_off = MMC_XGMAC_OFFSET,
@@ -291,7 +291,7 @@ static const struct stmmac_hwif_entry {
};
static const struct stmmac_hwif_entry *
-stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
+stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 userver)
{
const struct stmmac_hwif_entry *entry;
int i;
@@ -305,7 +305,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
if (snpsver < entry->min_snpsver)
continue;
if (core_type == DWMAC_CORE_XGMAC &&
- dev_id != entry->dev_id)
+ userver != entry->userver)
continue;
return entry;
@@ -358,7 +358,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
/* Fallback to generic HW */
/* Use synopsys_id var because some setups can override this */
- entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.dev_id);
+ entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.userver);
if (!entry) {
dev_err(priv->device,
"Failed to find HW IF (id=0x%x, gmac=%d/%d)\n",
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 01/10] net: stmmac: rename min_id to min_snpsver
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
min_id is the minimum Synopsys IP version that the hwif entry will
match. Name it min_snpsver so that it's clear which part of the
version ID it is related to.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 511b0fd5e834..3774af66db48 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -110,7 +110,7 @@ int stmmac_reset(struct stmmac_priv *priv)
static const struct stmmac_hwif_entry {
enum dwmac_core_type core_type;
- u32 min_id;
+ u32 min_snpsver;
u32 dev_id;
const struct stmmac_regs_off regs;
const void *desc;
@@ -129,7 +129,7 @@ static const struct stmmac_hwif_entry {
/* NOTE: New HW versions shall go to the end of this table */
{
.core_type = DWMAC_CORE_MAC100,
- .min_id = 0,
+ .min_snpsver = 0,
.regs = {
.ptp_off = PTP_GMAC3_X_OFFSET,
.mmc_off = MMC_GMAC3_X_OFFSET,
@@ -146,7 +146,7 @@ static const struct stmmac_hwif_entry {
.quirks = stmmac_dwmac1_quirks,
}, {
.core_type = DWMAC_CORE_GMAC,
- .min_id = 0,
+ .min_snpsver = 0,
.regs = {
.ptp_off = PTP_GMAC3_X_OFFSET,
.mmc_off = MMC_GMAC3_X_OFFSET,
@@ -163,7 +163,7 @@ static const struct stmmac_hwif_entry {
.quirks = stmmac_dwmac1_quirks,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = 0,
+ .min_snpsver = 0,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -183,7 +183,7 @@ static const struct stmmac_hwif_entry {
.quirks = stmmac_dwmac4_quirks,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = DWMAC_CORE_4_00,
+ .min_snpsver = DWMAC_CORE_4_00,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -204,7 +204,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = DWMAC_CORE_4_10,
+ .min_snpsver = DWMAC_CORE_4_10,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -225,7 +225,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = DWMAC_CORE_5_10,
+ .min_snpsver = DWMAC_CORE_5_10,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -246,7 +246,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_XGMAC,
- .min_id = DWXGMAC_CORE_2_10,
+ .min_snpsver = DWXGMAC_CORE_2_10,
.dev_id = DWXGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
@@ -268,7 +268,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_XGMAC,
- .min_id = DWXLGMAC_CORE_2_00,
+ .min_snpsver = DWXLGMAC_CORE_2_00,
.dev_id = DWXLGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
@@ -302,7 +302,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
if (core_type != entry->core_type)
continue;
/* Use synopsys_id var because some setups can override this */
- if (snpsver < entry->min_id)
+ if (snpsver < entry->min_snpsver)
continue;
if (core_type == DWMAC_CORE_XGMAC &&
dev_id != entry->dev_id)
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 00/10] net: stmmac: clean up / fix synopsys IP version checks
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-stm32,
linux-sunxi, netdev, Paolo Abeni, Samuel Holland,
Jitendra Vegiraju
Oh lookie, another relatively large stmmac patch series as a result of
reviewing Jitendra Vegiraju's patch series! Yay! :(
This series cleans up and in some cases fixes the Synopsys IP version
checks, which is a per-core numberspace.
For example, for dwmac1000 and dwmac4, we have versions such as v3.4 to
up v5.2, which are represented by two BCD digits. For XGMAC, we have
versions v2.1 and v2.2 represented by 0x21 and 0x22 respectively. For
XLGMAC, we have v2.0, which is 0x20.
Note that hwif.c supports GMAC4 core type with the IP version in the
range 0..0x40, which overlaps with the GMAC core type.
Thus, testing the Synopsys IP version for <= v4.0 will match dwmac1000,
potentially some dwmac4, and all xgmac and xlgmac cores. In some cases,
the latter two are provably incorrect.
The Synopsys IP version is named "synopsys_id" in the driver - as
stated, it is the Synopsys IP version, and the register field is called
snpsver. Use this name throughout the driver to avoid confusion. Also,
dev_id seems to actually be userver.
The first decision making change is for dche, which is only looked at
by the dwmac4 DMA code which requires core_type == DWMAC_CORE_GMAC4.
Thus, it makes no sense to merely look at the IP version. Since setting
this to true makes no sense for non-GMAC4 cores, force it to false for
non-DWMAC_CORE_GMAC4 cores.
The MAC .debug() method is only populated by the dwmac1000 and dwmac4
cores, yet the test checks only for the IP version >= v3.5. While this
works today, it may not work in the future given the different version
numberspaces. Make this conditional on DWMAC_CORE_GMAC or GMAC4 core
types to limit the version check. Ideally, it would be better to
move the version check inside the .dwbug() method implementation, but
that would require the method signature to change.
As getting to that point involved quite a bit of research, add comments
into stmmac_get_ethtool_stats() so others don't have to re-analyse the
code.
Clean up the resulting code in stmmac_get_ethtool_stats() given the
complexity, adding documentation for each test.
Address the rx_coe handling, which checks for IP version >= v4.0 or
the XGMAC core type. However, the members being printed are only
present in the GMAC4 and XGMAC core type in one path, and GMAC in
the other. There is an odd-ball which is sun8i, but we preserve its
current behaviour. Also, given the research, add documentation in
appropriate places. Note that priv->plat->rx_coe (and also
priv->hw->rx_csum) has different value spaces depending on the core
type - which is not nice.
Lastly, make the printing of the COE type, which as identified above,
depend on the GMAC core type.
This leaves four locations unaddressed:
1) PTP filter code:
case HWTSTAMP_FILTER_PTP_V2_EVENT:
/* PTP v2/802.AS1 any layer, any kind of event packet */
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
if (priv->snpsver < DWMAC_CORE_4_10)
ts_event_en = PTP_TCR_TSEVNTENA;
I don't yet have an answer for this one, but it does mean that
PTP_TCR_TSEVNTENA will be set for XGMAC cores for
HWTSTAMP_FILTER_PTP_V2_EVENT... if they have PTP support.
2) riwt watchdog:
/* Rx Watchdog is available in the COREs newer than the 3.40.
* In some case, for example on bugged HW this feature
* has to be disable and this can be done by passing the
* riwt_off field from the platform.
*/
if ((priv->snpsver >= DWMAC_CORE_3_50 ||
priv->plat->core_type == DWMAC_CORE_XGMAC) &&
!priv->plat->riwt_off) {
priv->use_riwt = 1;
This to me looks like the version check is only really applicable for
the DWMAC_CORE_GMAC core type. So, I'm thinking that:
if (priv->plat->core_type >= DWMAC_CORE_GMAC4 ||
(priv->plat->core_type == DWMAC_CORE_GMAC &&
priv->snpsver >= DWMAC_CORE_3_50)) {
if (!priv->plat->rwit_off) {
...
would be clearer (note the splitting of the if() conditions which seems
to me would be more readable than trying to munge it all into one
expression.)
3) max_mtu setup:
/* Set the maximum MTU.
* For XGMAC cores, 16KiB.
* For cores using enhanced descriptors or GMAC cores >= v4.00, 9kB.
* For everything else, PAGE_SIZE - NET_SKB_PAD - NET_IP_ALIGN -
* aligned skb_shared_info.
*/
if (priv->plat->core_type == DWMAC_CORE_XGMAC)
ndev->max_mtu = XGMAC_JUMBO_LEN;
else if (priv->plat->enh_desc || priv->snpsver >= DWMAC_CORE_4_00)
ndev->max_mtu = JUMBO_LEN;
else
ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
which I've previously identified is very buggy, and I'm not sure what
the real tests here should be. I'm quite certain that the max_mtu
values are basically completely wrong, especially in the last case.
This needs a lot of analysis and comparing with documentation to get
to the bottom of what the tests and resulting max_mtu values should
actually be.
.../net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/hwif.c | 54 +++++++++++-----------
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 51 +++++++++++---------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 24 ++++++----
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 ++--
include/linux/stmmac.h | 7 +++
9 files changed, 85 insertions(+), 67 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 00/10] arm64/entry:
From: Peter Zijlstra @ 2026-04-08 9:19 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mark Rutland, vladimir.murzin, Catalin Marinas, ruanjinjie,
linux-kernel, Andy Lutomirski, Will Deacon, linux-arm-kernel
In-Reply-To: <87cy0a4gx7.ffs@tglx>
On Tue, Apr 07, 2026 at 11:08:36PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 07 2026 at 14:16, Mark Rutland wrote:
> > I've split the series into a prefix of changes for generic irqentry,
> > followed by changes to the arm64 code. I'm hoping that we can queue the
> > generic irqentry patches onto a stable branch, or take those via arm64.
> > The patches are as follows:
> >
> > * Patches 1 and 2 are cleanup to the generic irqentry code. These have no
> > functional impact, and I think these can be taken regardless of the
> > rest of the series.
> >
> > * Patches 3 to 5 refactor the generic irqentry code as described above,
> > providing separate irqentry_{enter,exit}() functions and providing a
> > split form of irqentry_exit_to_kernel_mode() similar to what exists
> > for irqentry_exit_to_user_mode(). These patches alone should have no
> > functional impact.
>
> I looked through them and I can't find any problem with them. I queued
> them localy and added the missing kernel doc as I promised you on IRC.
>
> As I have quite a conflict pending in the tip tree with other changes
> related to the generic entry code, I suggest that I queue 1-5, tag them
> for arm64 consumption and merge them into the conflicting branch to
> avoid trouble with pull request ordering and headaches for the -next
> people.
FWIW, for those 1-5
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
^ permalink raw reply
* Re: [PATCH 1/2] coresight: etm4x: fix inconsistencies with sysfs configration
From: Yeoreum Yun @ 2026-04-08 9:17 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin
In-Reply-To: <20260407143028.GM356832@e132581.arm.com>
Hi Leo,
> On Tue, Mar 17, 2026 at 06:17:04PM +0000, Yeoreum Yun wrote:
> > The current ETM4x configuration via sysfs can lead to the following
> > inconsistencies:
> >
> > - If a configuration is modified via sysfs while a perf session is
> > active, the running configuration may differ between before
> > a sched-out and after a subsequent sched-in.
> >
> > - Once a perf session is enabled, some read-only register fields
> > (e.g., TRCSSCSR<n>) may not be reported correctly,
> > because drvdata->config is cleared while enabling with perf mode,
> > even though the information was previously read via etm4_init_arch_data().
> >
> > To resolve these inconsistencies, the configuration should be separated into:
> >
> > - active_config, which represents the currently applied configuration
> > - config, which stores the settings configured via sysfs.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > .../hwtracing/coresight/coresight-etm4x-cfg.c | 2 +-
> > .../coresight/coresight-etm4x-core.c | 45 +++++++++++--------
> > drivers/hwtracing/coresight/coresight-etm4x.h | 2 +
> > 3 files changed, 30 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > index c302072b293a..84213d40d1ae 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > @@ -47,7 +47,7 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> > struct cscfg_regval_csdev *reg_csdev, u32 offset)
> > {
> > int err = -EINVAL, idx;
> > - struct etmv4_config *drvcfg = &drvdata->config;
> > + struct etmv4_config *drvcfg = &drvdata->active_config;
>
> I'd suggest we leave out complex cfg things, we can refactor it
> later.
>
> In this series, let us first separate active_config and config, and
> keep using drvdata->config to save complex cfg ?
Yes. but I think we should include the separation of ss_status in
this patchset.
>
> > u32 off_mask;
> >
> > if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > index d565a73f0042..c552129c4a0c 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > @@ -88,9 +88,11 @@ static int etm4_probe_cpu(unsigned int cpu);
> > */
> > static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
> > {
> > + struct etmv4_config *config = &drvdata->active_config;
> > +
> > return (n < drvdata->nr_ss_cmp) &&
> > drvdata->nr_pe &&
> > - (drvdata->config.ss_status[n] & TRCSSCSRn_PC);
> > + (config->ss_status[n] & TRCSSCSRn_PC);
>
> As Suzuki suggested in another reply, we need to extract capabilities
> into a separate structure. I'd also extract status related registers
> into a new structure:
>
> struct etm4_cap {
> int nr_ss_cmp;
> bool pe_comparator; // TRCSSCSRn.PC
> bool dv_comparator; // TRCSSCSRn.DV
> bool da_comparator; // TRCSSCSRn.DA
> bool inst_comparator; // TRCSSCSRn.INST
>
> int ns_ex_level;
> int nr_pe;
> int nr_pe_cmp;
> int nr_resource;
> ...
> }
>
> struct etm4_status_reg {
> u32 ss_status[ETM_MAX_SS_CMP];
> u32 cntr_val[ETMv4_MAX_CNTR];
> }
Thanks. I'll take with this as reference.
>
> [...]
>
> > @@ -911,14 +915,17 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa
> >
> > /* enable any config activated by configfs */
> > cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset);
> > +
> > + raw_spin_lock(&drvdata->spinlock);
> > +
> > + drvdata->active_config = drvdata->config;
>
> This is not an issue introduced by this patch, but we might need to
> consider to copy active config until it has acquired SYSFS mode.
> Otherwise, it might update config here but will disturb a perf session
> has been running.
Good catch. I think we should access "active_config" after taking a
mode. That means cscfg_csdev_enable/disable_active_config() should
be called after/before taking mode like PERF session otherwise
active_config could be a race if perf and sysfs session are enabled parallely.
>
> > @@ -2246,7 +2254,8 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
> > if (!desc.name)
> > return -ENOMEM;
> >
> > - etm4_set_default(&drvdata->config);
> > + etm4_set_default(&drvdata->active_config);
>
> Should we set default values to drvdata->config ?
>
> My understanding is drvdata->active_config would be always set at the
> runtime, but "drvdata->config" should be initialized properly so it
> can be consumed by sysfs knobs.
Right. I've only thought about perf case not a sysfs knobs for this.
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 05/10] entry: Split preemption from irqentry_exit_to_kernel_mode()
From: Jinjie Ruan @ 2026-04-08 9:17 UTC (permalink / raw)
To: Mark Rutland, linux-arm-kernel, Andy Lutomirski, Peter Zijlstra,
Thomas Gleixner
Cc: vladimir.murzin, will, linux-kernel, catalin.marinas
In-Reply-To: <20260407131650.3813777-6-mark.rutland@arm.com>
On 2026/4/7 21:16, Mark Rutland wrote:
> Some architecture-specific work needs to be performed between the state
> management for exception entry/exit and the "real" work to handle the
> exception. For example, arm64 needs to manipulate a number of exception
> masking bits, with different exceptions requiring different masking.
>
> Generally this can all be hidden in the architecture code, but for arm64
> the current structure of irqentry_exit_to_kernel_mode() makes this
> particularly difficult to handle in a way that is correct, maintainable,
> and efficient.
>
> The gory details are described in the thread surrounding:
>
> https://lore.kernel.org/lkml/acPAzdtjK5w-rNqC@J2N7QTR9R3/
>
> The summary is:
>
> * Currently, irqentry_exit_to_kernel_mode() handles both involuntary
> preemption AND state management necessary for exception return.
>
> * When scheduling (including involuntary preemption), arm64 needs to
> have all arm64-specific exceptions unmasked, though regular interrupts
> must be masked.
>
> * Prior to the state management for exception return, arm64 needs to
> mask a number of arm64-specific exceptions, and perform some work with
> these exceptions masked (with RCU watching, etc).
>
> While in theory it is possible to handle this with a new arch_*() hook
> called somewhere under irqentry_exit_to_kernel_mode(), this is fragile
> and complicated, and doesn't match the flow used for exception return to
> user mode, which has a separate 'prepare' step (where preemption can
> occur) prior to the state management.
>
> To solve this, refactor irqentry_exit_to_kernel_mode() to match the
> style of {irqentry,syscall}_exit_to_user_mode(), moving preemption logic
> into a new irqentry_exit_to_kernel_mode_preempt() function, and moving
> state management in a new irqentry_exit_to_kernel_mode_after_preempt()
> function. The existing irqentry_exit_to_kernel_mode() is left as a
> caller of both of these, avoiding the need to modify existing callers.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Vladimir Murzin <vladimir.murzin@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> include/linux/irq-entry-common.h | 26 +++++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> Thomas/Peter/Andy, as mentioned on IRC, I haven't created kerneldoc
> comments for these new functions because the existing comments don't
> seem all that consistent (e.g. for user mode vs kernel mode), and I
> suspect we want to rewrite them all in one go for wider consistency.
>
> I'm happy to respin this, or to follow-up with that as per your
> preference.
>
> Mark.
>
> diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h
> index 2206150e526d8..24830baa539c6 100644
> --- a/include/linux/irq-entry-common.h
> +++ b/include/linux/irq-entry-common.h
> @@ -421,10 +421,18 @@ static __always_inline irqentry_state_t irqentry_enter_from_kernel_mode(struct p
> return ret;
> }
>
> -static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state)
> +static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, irqentry_state_t state)
> {
> - lockdep_assert_irqs_disabled();
> + if (regs_irqs_disabled(regs) || state.exit_rcu)
> + return;
> +
> + if (IS_ENABLED(CONFIG_PREEMPTION))
> + irqentry_exit_cond_resched();
> +}
>
> +static __always_inline void
> +irqentry_exit_to_kernel_mode_after_preempt(struct pt_regs *regs, irqentry_state_t state)
> +{
> if (!regs_irqs_disabled(regs)) {
> /*
> * If RCU was not watching on entry this needs to be done
> @@ -443,9 +451,6 @@ static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, i
> }
>
> instrumentation_begin();
> - if (IS_ENABLED(CONFIG_PREEMPTION))
> - irqentry_exit_cond_resched();
> -
> /* Covers both tracing and lockdep */
> trace_hardirqs_on();
> instrumentation_end();
> @@ -459,6 +464,17 @@ static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, i
> }
> }
>
> +static __always_inline void irqentry_exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state)
> +{
> + lockdep_assert_irqs_disabled();
> +
> + instrumentation_begin();
> + irqentry_exit_to_kernel_mode_preempt(regs, state);
> + instrumentation_end();
I think the below AI's feedback makes sense. Directly calling
irqentry_exit_to_kernel_mode_preempt() on arm64/other archs could lead
to missing instrumentation_begin()/end() markers.
https://sashiko.dev/#/patchset/20260407131650.3813777-1-mark.rutland%40arm.com
> +
> + irqentry_exit_to_kernel_mode_after_preempt(regs, state);
> +}
> +
> /**
> * irqentry_enter - Handle state tracking on ordinary interrupt entries
> * @regs: Pointer to pt_regs of interrupted context
^ permalink raw reply
* Re: [RFC PATCH 0/8] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Dev Jain @ 2026-04-08 9:14 UTC (permalink / raw)
To: Barry Song (Xiaomi), linux-mm, linux-arm-kernel, catalin.marinas,
will, akpm, urezki
Cc: linux-kernel, anshuman.khandual, ryan.roberts, ajd, rppt, david,
Xueyuan.chen21
In-Reply-To: <20260408025115.27368-1-baohua@kernel.org>
On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
> This patchset accelerates ioremap, vmalloc, and vmap when the memory
> is physically fully or partially contiguous. Two techniques are used:
>
> 1. Avoid page table zigzag when setting PTEs/PMDs for multiple memory
> segments
> 2. Use batched mappings wherever possible in both vmalloc and ARM64
> layers
>
> Patches 1–2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> CONT-PTE regions instead of just one.
>
> Patches 3–4 extend vmap_small_pages_range_noflush() to support page
> shifts other than PAGE_SHIFT. This allows mapping multiple memory
> segments for vmalloc() without zigzagging page tables.
>
> Patches 5–8 add huge vmap support for contiguous pages. This not only
> improves performance but also enables PMD or CONT-PTE mapping for the
> vmapped area, reducing TLB pressure.
>
> Many thanks to Xueyuan Chen for his substantial testing efforts
> on RK3588 boards.
>
> On the RK3588 8-core ARM64 SoC, with tasks pinned to CPU2 and
> the performance CPUfreq policy enabled, Xueyuan’s tests report:
>
> * ioremap(1 MB): 1.2× faster
> * vmalloc(1 MB) mapping time (excluding allocation) with
> VM_ALLOW_HUGE_VMAP: 1.5× faster
> * vmap(): 5.6× faster when memory includes some order-8 pages,
> with no regression observed for order-0 pages
>
> Barry Song (Xiaomi) (8):
> arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE
> setup
> arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple
> CONT_PTE
> mm/vmalloc: Extend vmap_small_pages_range_noflush() to support larger
> page_shift sizes
> mm/vmalloc: Eliminate page table zigzag for huge vmalloc mappings
> mm/vmalloc: map contiguous pages in batches for vmap() if possible
> mm/vmalloc: align vm_area so vmap() can batch mappings
> mm/vmalloc: Coalesce same page_shift mappings in vmap to avoid pgtable
> zigzag
> mm/vmalloc: Stop scanning for compound pages after encountering small
> pages in vmap
>
> arch/arm64/include/asm/vmalloc.h | 6 +-
> arch/arm64/mm/hugetlbpage.c | 10 ++
> mm/vmalloc.c | 178 +++++++++++++++++++++++++------
> 3 files changed, 161 insertions(+), 33 deletions(-)
>
On Linux VM on Apple M3, running mm-selftests:
./run_vmtests.sh -t "hugetlb"
TAP version 13
# -----------------------
# running ./hugepage-mmap
# -----------------------
# TAP version 13
# 1..1
# # Returned address is 0xffffe7c00000
[ 30.884630] kernel BUG at mm/page_table_check.c:86!
[ 30.884701] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 30.886803] Modules linked in:
[ 30.887217] CPU: 3 UID: 0 PID: 1869 Comm: hugepage-mmap Not tainted 7.0.0-rc5+ #86 PREEMPT
[ 30.888218] Hardware name: linux,dummy-virt (DT)
[ 30.889413] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 30.889901] pc : page_table_check_clear.part.0+0x128/0x1a0
[ 30.890337] lr : page_table_check_clear.part.0+0x7c/0x1a0
[ 30.890714] sp : ffff800084da3ad0
[ 30.890946] x29: ffff800084da3ad0 x28: 0000000000000001 x27: 0010000000000001
[ 30.891434] x26: 0040000000000040 x25: ffffa06bb8fb9000 x24: 00000000ffffffff
[ 30.891932] x23: 0000000000000001 x22: 0000000000000000 x21: ffffa06bb8997810
[ 30.892514] x20: 0000000000113e39 x19: 0000000000113e38 x18: 0000000000000000
[ 30.893007] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 30.893500] x14: ffffa06bb7013780 x13: 0000fffff7f90fff x12: 0000000000000000
[ 30.893990] x11: 1fffe0001a1282c1 x10: ffff0000d094160c x9 : ffffa06bb568a858
[ 30.894479] x8 : ffff5f95c8474000 x7 : 0000000000000000 x6 : ffff00017fffc500
[ 30.894973] x5 : ffff000191208fc0 x4 : 0000000000000000 x3 : 0000000000004000
[ 30.895449] x2 : 0000000000000000 x1 : 00000000ffffffff x0 : ffff0000c071f1b8
[ 30.895875] Call trace:
[ 30.896027] page_table_check_clear.part.0+0x128/0x1a0 (P)
[ 30.896369] page_table_check_clear+0xc8/0x138
[ 30.896776] __page_table_check_ptes_set+0xe4/0x1e8
[ 30.897073] __set_ptes_anysz+0x2e4/0x308
[ 30.897327] set_huge_pte_at+0xec/0x210
[ 30.897561] hugetlb_no_page+0x1ec/0x8e0
[ 30.897807] hugetlb_fault+0x188/0x740
[ 30.898036] handle_mm_fault+0x294/0x2c0
[ 30.898283] do_page_fault+0x120/0x748
[ 30.898539] do_translation_fault+0x68/0x90
[ 30.898796] do_mem_abort+0x4c/0xa8
[ 30.899011] el0_da+0x2c/0x90
[ 30.899205] el0t_64_sync_handler+0xd0/0xe8
[ 30.899461] el0t_64_sync+0x198/0x1a0
[ 30.899688] Code: 91001021 b8f80022 51000441 36fffd41 (d4210000)
[ 30.900053] ---[ end trace 0000000000000000 ]---
The bug is at
BUG_ON(atomic_dec_return(&ptc->file_map_count) < 0);
My tree is mm-unstable, commit 3fa44141e0bb.
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Neil Armstrong @ 2026-04-08 9:12 UTC (permalink / raw)
To: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree,
Jun Yan
Cc: robh, krzk+dt, conor+dt, khilman, jbrunet, martin.blumenstingl
In-Reply-To: <20260330145111.115318-1-jerrysteve1101@gmail.com>
Hi,
On Mon, 30 Mar 2026 22:51:11 +0800, Jun Yan wrote:
> Correct the interrupt number assigned to the Realtek PHY in the p230
>
> following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
> fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
> interrupt improvements [1].
>
> [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
https://git.kernel.org/amlogic/c/b18d1b23558114b3c64fec7b515ca80c76e58171
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-2-florian.fainelli@broadcom.com>
On Tue, Apr 07, 2026 at 04:56:10PM -0700, Florian Fainelli wrote:
> Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> index 9135788cf62e..afe7329a1df2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> @@ -38,6 +38,10 @@ properties:
> - enum:
> - marvell,pxa1908-padconf
> - const: pinconf-single
> + - items:
> + - enum:
> + - brcm,bcm7038-padconf
> + - const: pinctrl-single
If there is going to be a new version, entire block should be placed
before 'ti' to have some sort of sorting by compatible.
But no need to resend just for that.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
https://git.kernel.org/amlogic/c/759613b88fbf051c8a977a5e5b046b28a18ed5c7
[5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
https://git.kernel.org/amlogic/c/596e3c1bfa7869cf15079e5c6e586575013b2fc3
[7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
https://git.kernel.org/amlogic/c/647228c014ddbd336a97e74bde81cbb2f7cbd927
[9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
https://git.kernel.org/amlogic/c/00cca65deacb29947ef32011827ff88fd59dab55
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH 0/2] Fix Amlogic T7 null reset ops and DT required property
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
Hi,
On Tue, 31 Mar 2026 16:24:03 +0200, Ronald Claveau wrote:
> 1. As reset is required for MMC DT, this patch series aims to add the currently missing required driver ops.
>
> Whithout this patch the following kernel null error appears:
>
> [ 0.459197] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.459978] Mem abort info:
> [ 0.460324] ESR = 0x0000000096000004
> [ 0.460791] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.461471] SET = 0, FnV = 0
> [ 0.461830] EA = 0, S1PTW = 0
> [ 0.462220] FSC = 0x04: level 0 translation fault
> [ 0.462722] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.462826] Data abort info:
> [ 0.462829] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.462842] Mem abort info:
> [ 0.462849] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.462859] ESR = 0x0000000096000004
> [ 0.462865] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.462874] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.462882] [0000000000000000] user address but active_mm is swapper
> [ 0.462890] SET = 0, FnV = 0
> [ 0.462901] Internal error: Oops: 0000000096000004 [#1] SMP
> [ 0.462909] EA = 0, S1PTW = 0
> [ 0.462917] Modules linked in:
> [ 0.462925] FSC = 0x04: level 0 translation fault
> [ 0.462932]
> [ 0.462939] Data abort info:
> [ 0.462951] CPU: 4 UID: 0 PID: 90 Comm: kworker/u34:3 Not tainted 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.463920] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.463927] Hardware name: Khadas VIM4 (DT)
> [ 0.463940] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.463951] Workqueue: async async_run_entry_fn
> [ 0.464277] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.464286]
> [ 0.464294] [0000000000000000] user address but active_mm is swapper
> [ 0.464304] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.465935] pc : reset_control_reset+0x48/0x1d0
> [ 0.466409] lr : reset_control_reset+0x38/0x1d0
> [ 0.479907] sp : ffff800083943b60
> [ 0.479911] x29: ffff800083943b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.479926] x26: ffff80008310a9c0 x25: 0000000000000000 x24: ffff000100372005
> [ 0.481212] x23: ffff0001003a4000 x22: ffff000100fee988 x21: 0000000000000000
> [ 0.482976] x20: ffff00023f00a788 x19: ffff000100fee980 x18: 0000000000000006
> [ 0.483865] x17: 64656c62616e655f x16: 7469647561206465 x15: ffff800083943530
> [ 0.484753] x14: 0000000000000000 x13: 000000000000022d x12: 0000000000002000
> [ 0.485642] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.486530] x8 : ffff00023efd8a40 x7 : fffffffffffffe70 x6 : ffff00023efd89e0
> [ 0.487418] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.488307] x2 : ffff000102002488 x1 : ffff8000822248c0 x0 : 0000000000000000
> [ 0.489196] Call trace:
> [ 0.489500] reset_control_reset+0x48/0x1d0 (P)
> [ 0.490062] __device_reset+0xc8/0xfc
> [ 0.490517] meson_mmc_probe+0xe8/0x3d4
> [ 0.490994] platform_probe+0x5c/0x98
> [ 0.491448] really_probe+0xbc/0x298
> [ 0.491892] __driver_probe_device+0x78/0x12c
> [ 0.492434] driver_probe_device+0xd4/0x164
> [ 0.492954] __device_attach_driver+0xb8/0x140
> [ 0.493507] bus_for_each_drv+0x84/0xe0
> [ 0.493983] __device_attach_async_helper+0xac/0xd0
> [ 0.494590] async_run_entry_fn+0x34/0xe0
> [ 0.495089] process_one_work+0x158/0x29c
> [ 0.495587] worker_thread+0x18c/0x308
> [ 0.496053] kthread+0x11c/0x128
> [ 0.496453] ret_from_fork+0x10/0x20
> [ 0.496904] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.497661] ---[ end trace 0000000000000000 ]---
> [ 0.498234] Internal error: Oops: 0000000096000004 [#2] SMP
> [ 0.498935] Modules linked in:
> [ 0.499319] CPU: 1 UID: 0 PID: 88 Comm: kworker/u34:1 Tainted: G D 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.500669] Tainted: [D]=DIE
> [ 0.501025] Hardware name: Khadas VIM4 (DT)
> [ 0.501547] Workqueue: async async_run_entry_fn
> [ 0.502109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.502975] pc : reset_control_reset+0x48/0x1d0
> [ 0.503538] lr : reset_control_reset+0x38/0x1d0
> [ 0.504102] sp : ffff800083903b60
> [ 0.504513] x29: ffff800083903b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.505402] x26: ffff000100059028 x25: 0000000000000000 x24: ffff000100372005
> [ 0.506290] x23: ffff000100ec9400 x22: ffff0001003f6e08 x21: 0000000000000000
> [ 0.507178] x20: ffff00023f00b440 x19: ffff0001003f6e00 x18: 00000000ffffffff
> [ 0.508067] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000839037e0
> [ 0.508955] x14: 0000000000000000 x13: 0000000000000290 x12: 0000000000002000
> [ 0.509843] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.510732] x8 : ffff00023efd8bc0 x7 : fffffffffffffe70 x6 : ffff00023efd8b60
> [ 0.511620] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.512508] x2 : ffff000102002488 x1 : ffff800082224a40 x0 : 0000000000000000
> [ 0.513397] Call trace:
> [ 0.513700] reset_control_reset+0x48/0x1d0 (P)
> [ 0.514263] __device_reset+0xc8/0xfc
> [ 0.514718] meson_mmc_probe+0xe8/0x3d4
> [ 0.515195] platform_probe+0x5c/0x98
> [ 0.515650] really_probe+0xbc/0x298
> [ 0.516094] __driver_probe_device+0x78/0x12c
> [ 0.516636] driver_probe_device+0xd4/0x164
> [ 0.517156] __device_attach_driver+0xb8/0x140
> [ 0.517709] bus_for_each_drv+0x84/0xe0
> [ 0.518185] __device_attach_async_helper+0xac/0xd0
> [ 0.518792] async_run_entry_fn+0x34/0xe0
> [ 0.519290] process_one_work+0x158/0x29c
> [ 0.519788] worker_thread+0x18c/0x308
> [ 0.520254] kthread+0x11c/0x128
> [ 0.520655] ret_from_fork+0x10/0x20
> [ 0.521103] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.521860] ---[ end trace 0000000000000000 ]---
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[2/2] arm64: dts: amlogic: t7: Fix missing required reset property
https://git.kernel.org/amlogic/c/98da3e91a6157d2833af356620665a9734d26133
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Neil Armstrong @ 2026-04-08 9:09 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Hi,
On Thu, 26 Mar 2026 17:26:42 +0800, Jian Hu wrote:
> This series adds the missing mpll3 parent clock and completes the
> Amlogic T7 SoC clock controller DT support.
>
> - Fix redundant hyphen in for gp1 pll
> - Add the missing mpll3 parent clock definition to t7-peripherals-clkc.yaml
> - Add Amlogic T7 SoC clock controller nodes
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/3] arm64: dts: amlogic: t7: Add clock controller nodes
https://git.kernel.org/amlogic/c/5f727a999f80a72dae7326577e0d832799ddeaa3
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH 10/10] arm64: Check DAIF (and PMR) at task-switch time
From: Mark Rutland @ 2026-04-08 9:08 UTC (permalink / raw)
To: Jinjie Ruan
Cc: vladimir.murzin, peterz, Catalin Marinas, linux-kernel, tglx,
luto, Will Deacon, linux-arm-kernel
In-Reply-To: <26642def-7676-e081-98f3-9ab883048375@huawei.com>
On Wed, Apr 08, 2026 at 10:17:56AM +0800, Jinjie Ruan wrote:
> On 2026/4/7 21:16, Mark Rutland wrote:
> > +static inline void debug_switch_state(void)
> > +{
> > + if (system_uses_irq_prio_masking()) {
> > + unsigned long daif_expected = 0;
> > + unsigned long daif_actual = read_sysreg(daif);
> > + unsigned long pmr_expected = GIC_PRIO_IRQOFF;
> > + unsigned long pmr_actual = read_sysreg_s(SYS_ICC_PMR_EL1);
> > +
> > + WARN_ONCE(daif_actual != daif_expected ||
> > + pmr_actual != pmr_expected,
> > + "Unexpected DAIF + PMR: 0x%lx + 0x%lx (expected 0x%lx + 0x%lx)\n",
> > + daif_actual, pmr_actual,
> > + daif_expected, pmr_expected);
> > + } else {
> > + unsigned long daif_expected = DAIF_PROCCTX_NOIRQ;
> > + unsigned long daif_actual = read_sysreg(daif);
> > +
> > + WARN_ONCE(daif_actual != daif_expected,
> > + "Unexpected DAIF value: 0x%lx (expected 0x%lx)\n",
> > + daif_actual, daif_expected);
> > + }
>
> This logic seems consistent with arm64's local_irq_disable()
> implementation. Do we need to wrap these debug checks in a config option
> (e.g., CONFIG_ARM64_DEBUG_PRIORITY_MASKING) to avoid unnecessary overhead?
Possibly. I'd expected this was infrequent enough that there wouldn't be
a noticeable overhead, but admittedly I don't have numbers.
Given Thomas seems happy to queue the preparatory bits, (hopefully) we
can queue the rest of this as-is, and I reckon it's probably best to
drop this patch for now and follow up with a better version later.
There are some other bits of state I'd like to check here (e.g. PAN),
and I think this requires a bit more work.
Thanks for looking at this!
Mark.
>
>
> __schedule()
> -> local_irq_disable()
> -> arch_local_irq_disable()
>
> 52 static __always_inline void __daif_local_irq_disable(void)
> 53 {
> 54 barrier();
> 55 asm volatile("msr daifset, #3");
> 56 barrier();
> 57 }
> 58
> 59 static __always_inline void __pmr_local_irq_disable(void)
> 60 {
> 61 if (IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING)) {
> 62 u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
> 63 WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr !=
> GIC_PRIO_IRQOFF);
> 64 }
> 65
> 66 barrier();
> 67 write_sysreg_s(GIC_PRIO_IRQOFF, SYS_ICC_PMR_EL1);
> 68 barrier();
> 69 }
> 70
> 71 static inline void arch_local_irq_disable(void)
> 72 {
> 73 if (system_uses_irq_prio_masking()) {
> 74 __pmr_local_irq_disable();
> 75 } else {
> 76 __daif_local_irq_disable();
> 77 }
> 78 }
>
>
> > +}
> > +
> > /*
> > * Thread switching.
> > */
> > @@ -708,6 +731,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
> > {
> > struct task_struct *last;
> >
> > + debug_switch_state();
> > +
> > fpsimd_thread_switch(next);
> > tls_thread_switch(next);
> > hw_breakpoint_thread_switch(next);
^ permalink raw reply
* Re: [PATCH 1/2] coresight: etm4x: fix inconsistencies with sysfs configration
From: Yeoreum Yun @ 2026-04-08 9:07 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, mike.leach,
james.clark, alexander.shishkin, leo.yan
In-Reply-To: <f62c7138-bddc-4bf1-932d-bafa683f5ee0@arm.com>
Hi Suzuki,
[...]
>
> >
> > To resolve these inconsistencies, the configuration should be separated into:
> >
> > - active_config, which represents the currently applied configuration
>
> To be more precise, it is the "Applied configuration for the current
> session"
Thanks for suggestion. I'll change it.
>
> > - config, which stores the settings configured via sysfs.
>
> While we are at it, should we stop using the drvdata->config for the
> "capabilities" for the ETM (e.g., TRCSSCSRn in ss_status ?) Instead
> we could save it in "drvdata->ss_status". This keeps everything
> separated:
>
> 1. Boot time probed capabilities of ETM
> 2. Sysfs configuration for the next Run
> 3. Current active configuration for the ETM (sysfs or perf)
Agree. with the Leo's suggestion, I'll change it.
Thanks!
[...]
^ permalink raw reply
* Re: [PATCH 00/10] arm64/entry:
From: Catalin Marinas @ 2026-04-08 9:06 UTC (permalink / raw)
To: Mark Rutland
Cc: vladimir.murzin, Peter Zijlstra, ruanjinjie, linux-kernel,
Thomas Gleixner, Andy Lutomirski, Will Deacon, linux-arm-kernel
In-Reply-To: <adYZpA3-Tx6s1VOp@J2N7QTR9R3>
On Wed, Apr 08, 2026 at 10:02:28AM +0100, Mark Rutland wrote:
> On Tue, Apr 07, 2026 at 11:08:36PM +0200, Thomas Gleixner wrote:
> > On Tue, Apr 07 2026 at 14:16, Mark Rutland wrote:
> > > I've split the series into a prefix of changes for generic irqentry,
> > > followed by changes to the arm64 code. I'm hoping that we can queue the
> > > generic irqentry patches onto a stable branch, or take those via arm64.
> > > The patches are as follows:
> > >
> > > * Patches 1 and 2 are cleanup to the generic irqentry code. These have no
> > > functional impact, and I think these can be taken regardless of the
> > > rest of the series.
> > >
> > > * Patches 3 to 5 refactor the generic irqentry code as described above,
> > > providing separate irqentry_{enter,exit}() functions and providing a
> > > split form of irqentry_exit_to_kernel_mode() similar to what exists
> > > for irqentry_exit_to_user_mode(). These patches alone should have no
> > > functional impact.
> >
> > I looked through them and I can't find any problem with them. I queued
> > them localy and added the missing kernel doc as I promised you on IRC.
>
> Thanks! Much appreciated!
>
> > As I have quite a conflict pending in the tip tree with other changes
> > related to the generic entry code, I suggest that I queue 1-5, tag them
> > for arm64 consumption and merge them into the conflicting branch to
> > avoid trouble with pull request ordering and headaches for the -next
> > people.
> >
> > Does that work for you?
>
> That sounds good to me.
>
> Catalin, Will, does that work for you?
Yes, it does. Thanks!
--
Catalin
^ permalink raw reply
* Re: [PATCH 00/10] arm64/entry:
From: Mark Rutland @ 2026-04-08 9:02 UTC (permalink / raw)
To: Thomas Gleixner, Catalin Marinas, Will Deacon
Cc: vladimir.murzin, Peter Zijlstra, ruanjinjie, linux-kernel,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <87cy0a4gx7.ffs@tglx>
On Tue, Apr 07, 2026 at 11:08:36PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 07 2026 at 14:16, Mark Rutland wrote:
> > I've split the series into a prefix of changes for generic irqentry,
> > followed by changes to the arm64 code. I'm hoping that we can queue the
> > generic irqentry patches onto a stable branch, or take those via arm64.
> > The patches are as follows:
> >
> > * Patches 1 and 2 are cleanup to the generic irqentry code. These have no
> > functional impact, and I think these can be taken regardless of the
> > rest of the series.
> >
> > * Patches 3 to 5 refactor the generic irqentry code as described above,
> > providing separate irqentry_{enter,exit}() functions and providing a
> > split form of irqentry_exit_to_kernel_mode() similar to what exists
> > for irqentry_exit_to_user_mode(). These patches alone should have no
> > functional impact.
>
> I looked through them and I can't find any problem with them. I queued
> them localy and added the missing kernel doc as I promised you on IRC.
Thanks! Much appreciated!
> As I have quite a conflict pending in the tip tree with other changes
> related to the generic entry code, I suggest that I queue 1-5, tag them
> for arm64 consumption and merge them into the conflicting branch to
> avoid trouble with pull request ordering and headaches for the -next
> people.
>
> Does that work for you?
That sounds good to me.
Catalin, Will, does that work for you?
Mark.
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Krzysztof Kozlowski @ 2026-04-08 9:00 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <CAPBH0A-ER9-_KpknyOKTmS2sBk-xv0c016y9WsLOvZ8CjSiwCw@mail.gmail.com>
On 08/04/2026 10:52, Colin Huang wrote:
> Hi Krzysztof,
> Thanks for reply.
Do not top post.
> Could you let me know what kind test I need to run?
> Following is what I do before send.
> * I build this dts with linux 6.6.x
v6.6? That's like 2.5 years ago.
No, you must work on recent kernel.
> * run "b4 prep --check"
Google - how to validate DTS in Linux kernel
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Wei Fang @ 2026-04-08 8:59 UTC (permalink / raw)
To: Jakub Kicinski, Vladimir Oltean
Cc: Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011738.1795644-1-kuba@kernel.org>
> > +static int netc_init_switch_id(struct netc_switch *priv)
> > +{
> > + struct netc_switch_regs *regs = &priv->regs;
> > + struct dsa_switch *ds = priv->ds;
> > +
> > + /* The value of 0 is reserved for the VEPA switch and cannot
> > + * be used.
> > + */
> > + if (ds->index > SWCR_SWID || !ds->index) {
> > + dev_err(priv->dev, "Switch index %d out of range\n",
> > + ds->index);
> > + return -ERANGE;
> > + }
>
> Does this check cause the probe to fail unconditionally for standard
> single-switch topologies?
>
> The DSA core typically assigns ds->index = 0 by default for the first switch.
> Because !ds->index evaluates to true for index 0, this setup function will
> always fail unless the dsa,member property is explicitly overridden in the
> device tree.
As I mentioned in another mail, we added the 'dsa,member' property to the
netc switch DT-binding doc, specifying that the 'member' (switch index) value
cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> Could the driver translate the hardware ID internally, for example by writing
> ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> restriction onto the software DSA index?
The current approach is based on Vladimir's suggestion. I need to confirm with
Vladimir which approach is better.
Hi Vladimir,
What are your thoughts on this suggestion? Is this approach better?
>
> [ ... ]
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + /* If the node does not have phy-handle property, then
> > + * the port does not connect to a PHY, so the port is
> > + * not the EMDIO consumer.
> > + */
> > + phy_node = of_parse_phandle(child, "phy-handle", 0);
> > + if (!phy_node)
> > + continue;
> > +
> > + if (!netc_port_is_emdio_consumer(child)) {
> > + of_node_put(phy_node);
> > + continue;
> > + }
> > +
> > + phydev = of_phy_find_device(phy_node);
> > + of_node_put(phy_node);
> > + if (!phydev) {
> > + err = -EPROBE_DEFER;
> > + goto out;
> > + }
>
> Could this logic cause an infinite probe deferral loop for ports sharing an
> internal MDIO bus?
>
> The netc_port_is_emdio_consumer() function assumes any port node without
> an
> mdio child is an EMDIO consumer waiting for an external controller. However,
> if multiple sibling ports on the same switch share a single internal MDIO bus
> defined under one port, the other ports will lack an mdio child node.
>
> This would cause those ports to be mistakenly treated as external EMDIO
> consumers, calling of_phy_find_device(). Because the internal MDIO bus is not
> registered until later in netc_setup(), the PHY device cannot be found, and
> the driver returns -EPROBE_DEFER.
>
> Since netc_setup() is never reached, the MDIO bus is never registered,
> causing an infinite deferral loop. Could the driver more accurately identify
> whether the PHY belongs to its own switch before deferring?
This case will not be true, from the hardware perspective, the switch ports
do not support share a single internal MDIO bus defined under one port.
The internal MDIO bus of a port can only access its own external PHY. So
a switch port must either use EMDIO to access its PHY or its internal MDIO
bus to access its PHY.
>
> > +
> > + put_device(&phydev->mdio.dev);
> > + }
> > +
> > +out:
> > + of_node_put(ports);
> > +
> > + return err;
> > +}
> > +
> > +static int netc_switch_pci_init(struct pci_dev *pdev)
> > +{
> [ ... ]
> > + regs->base = pci_ioremap_bar(pdev, NETC_REGS_BAR);
> > + if (!regs->base) {
> > + err = -ENXIO;
> > + dev_err(dev, "pci_ioremap_bar() failed\n");
> > + goto release_mem_regions;
> > + }
> [ ... ]
> > +static void netc_switch_pci_destroy(struct pci_dev *pdev)
> > +{
> > + struct netc_switch *priv = pci_get_drvdata(pdev);
> > +
> > + iounmap(priv->regs.base);
> > + pci_release_mem_regions(pdev);
> > + pci_disable_device(pdev);
> > +}
>
> Does unmapping the memory here introduce a use-after-unmap issue when the
> MDIO bus is unregistered?
>
> The driver registers the MDIO bus using devm_of_mdiobus_register(), meaning
> devres cleans it up asynchronously after the remove function returns or when
> probe fails.
>
> However, in netc_switch_pci_destroy(), the driver explicitly unmaps the PCI
> I/O memory via iounmap(). Since netc_switch_pci_destroy() is called
> synchronously inside the remove function and probe error paths, the memory is
> unmapped before the MDIO bus is unregistered by devres.
>
> When devres eventually unregisters the MDIO bus, it detaches PHY devices,
> which often perform MDIO transactions during removal. Because the
> underlying
> memory priv->regs.base is already unmapped, these MDIO read/write callbacks
> could trigger a synchronous external abort or kernel panic.
>
> Would it be better to use pcim_iomap() to tie the memory mapping lifecycle to
> devres, ensuring it outlives the MDIO bus?
Great, I will pcim_iomap().
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: aspeed: anacapa: add EVT1 devicetree and point wrapper to it
From: Colin Huang @ 2026-04-08 8:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <20260408-glorious-vehement-robin-b6def3@quoll>
Hi Krzysztof,
Thanks for reply.
Could you let me know what kind test I need to run?
Following is what I do before send.
* I build this dts with linux 6.6.x
* run "b4 prep --check"
BR,
Colin Huang
Krzysztof Kozlowski <krzk@kernel.org> 於 2026年4月8日週三 下午3:52寫道：
>
> On Tue, Apr 07, 2026 at 09:54:33PM +0800, Colin Huang wrote:
> > This change introduces a development-phase devicetree for the
> > Facebook Anacapa BMC EVT1 hardware revision and updates the Anacapa
> > wrapper DTS to reference it.
> >
> > A dedicated EVT1 DTS is added for revision-specific hardware while
> > keeping a single, Anacapa entrypoint used by the build and deployment
> > flow. The top-level aspeed-bmc-facebook-anacapa.dts
> >
> > Signed-off-by: Colin Huang <u8813345@gmail.com>
> > ---
> > .../aspeed/aspeed-bmc-facebook-anacapa-evt1.dts | 1069 ++++++++++++++++++++
> > .../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 1064 +------------------
> > 2 files changed, 1070 insertions(+), 1063 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> > new file mode 100644
> > index 000000000000..a29b7fa1155b
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa-evt1.dts
> > @@ -0,0 +1,1069 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +/dts-v1/;
> > +#include "aspeed-g6.dtsi"
> > +#include <dt-bindings/gpio/aspeed-gpio.h>
> > +#include <dt-bindings/i2c/i2c.h>
> > +
> > +/ {
> > + model = "Facebook Anacapa BMC";
> > + compatible = "facebook,anacapa-bmc-evt1",
> > + "facebook,anacapa-bmc",
> > + "aspeed,ast2600";
>
> Test your DTS before you send, not after. Your binding clearly said
> something else.
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: James Clark @ 2026-04-08 8:47 UTC (permalink / raw)
To: Ian Rogers
Cc: John Garry, Will Deacon, Mike Leach, Leo Yan, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, Al Grant,
linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <CAP-5=fXNb50wXT3YH0i=-U8bXwizzH4bv8EL8mC9BMQE0Anp9Q@mail.gmail.com>
On 07/04/2026 7:26 pm, Ian Rogers wrote:
> On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
>>
>>
>>
>> On 02/04/2026 4:26 pm, Ian Rogers wrote:
>>> On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
>>>>
>>>> From the TRM [1], N1 has one IMPDEF event which isn't covered by the
>>>> common list. Add a framework so that more cores can be added in the
>>>> future and that the N1 IMPDEF event can be decoded. Also increase the
>>>> size of the buffer because we're adding more strings and if it gets
>>>> truncated it falls back to a hex dump only.
>>>>
>>>> [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
>>>> Suggested-by: Al Grant <al.grant@arm.com>
>>>> Signed-off-by: James Clark <james.clark@linaro.org>
>>>> ---
>>>> tools/perf/util/arm-spe-decoder/Build | 2 +
>>>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
>>>> .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
>>>> tools/perf/util/arm-spe.c | 13 ++++---
>>>> 4 files changed, 54 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
>>>> index ab500e0efe24..97a298d1e279 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/Build
>>>> +++ b/tools/perf/util/arm-spe-decoder/Build
>>>> @@ -1 +1,3 @@
>>>> perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
>>>> +
>>>> +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
>>>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> index c880b0dec3a1..42a7501d4dfe 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
>>>> @@ -15,6 +15,8 @@
>>>>
>>>> #include "arm-spe-pkt-decoder.h"
>>>>
>>>> +#include "../../arm64/include/asm/cputype.h"
>>>
>>> Sashiko spotted:
>>> https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
>>> """
>>> This isn't a bug, but does this include directive rely on accidental
>>> path normalization?
>>>
>>> The relative path ../../arm64/include/asm/cputype.h does not exist relative
>>> to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
>>> -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
>>>
>>> Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
>>> the include path?
>>> [ ... ]
>>> """
>>> I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
>>> instead just add the extra "../" into the include path.
>>>
>>
>> Do you mean change the #include to this?
>>
>> #include "../../../arm64/include/asm/cputype.h"
>>
>> I still need to add:
>>
>> CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
>>
>> To make the this include in cputype.h work:
>>
>> #include <asm/sysreg.h>
>>
>> Which probably only works because there isn't a sysreg.h on other
>> architectures. But I'm not sure what the significance of ../../ vs
>> ../../../ is if either compile? arm-spe.c already does it with ../../
>> which is what I copied.
>
> Hmm.. maybe the path should be
> "../../../arch/arm64/include/asm/cputype.h". The include preference is
> for a path relative to the source file and
> ../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
Up 3 dirs from arm-spe-pkt-decoder.c would be
"tools/arm64/include/asm/cputype.h" which doesn't exist either unless
I'm missing something?
If get the compiler to print the path it uses with 3 then it would use
the x86 uapi include path which doesn't seem any less weird to me:
...
In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.c:19:
linux/tools/arch/x86/include/uapi/../../../arm64/include/asm/cputype.h:254:10:
> to add an include path and then use a relative path to escape into a
> higher-level directory. arm-spe.c is a little different as it is one
> directory higher in the directory layout.
>
It is one folder higher, but arm-spe.c still relies on adding a special
include path to CFLAGS_arm-spe.o to make it work. It's not including a
real path relative to the source either.
Yeah it's a bit horrible but I don't think the asm/ thing combined with
copying headers from the kernel to tools expected to handle the case
where we would want to use asm/ stuff for a different arch than the
compile one. It might not be normal to use relative include paths to
escape to higher directories, but it's not a normal situation either. I
think it's a special case for a special scenario. I'm not sure of a
better way, but this is working for now.
> Thanks,
> Ian
>
>>>> +
>>>> static const char * const arm_spe_packet_name[] = {
>>>> [ARM_SPE_PAD] = "PAD",
>>>> [ARM_SPE_END] = "END",
>>>> @@ -307,6 +309,11 @@ static const struct ev_string common_ev_strings[] = {
>>>> { .event = 0, .desc = NULL },
>>>> };
>>>>
>>>> +static const struct ev_string n1_event_strings[] = {
>>>> + { .event = 12, .desc = "LATE-PREFETCH" },
>>>> + { .event = 0, .desc = NULL },
>>>> +};
>>>> +
>>>> static u64 print_event_list(int *err, char **buf, size_t *buf_len,
>>>> const struct ev_string *ev_strings, u64 payload)
>>>> {
>>>> @@ -318,14 +325,44 @@ static u64 print_event_list(int *err, char **buf, size_t *buf_len,
>>>> return payload;
>>>> }
>>>>
>>>> +struct event_print_handle {
>>>> + const struct midr_range *midr_ranges;
>>>> + const struct ev_string *ev_strings;
>>>> +};
>>>> +
>>>> +#define EV_PRINT(range, strings) \
>>>> + { \
>>>> + .midr_ranges = range, \
>>>> + .ev_strings = strings, \
>>>> + }
>>>> +
>>>> +static const struct midr_range n1_event_encoding_cpus[] = {
>>>> + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
>>>> + {},
>>>> +};
>>>> +
>>>> +static const struct event_print_handle event_print_handles[] = {
>>>> + EV_PRINT(n1_event_encoding_cpus, n1_event_strings),
>>>> +};
>>>> +
>>>> static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
>>>> - char *buf, size_t buf_len)
>>>> + char *buf, size_t buf_len, u64 midr)
>>>> {
>>>> u64 payload = packet->payload;
>>>> int err = 0;
>>>>
>>>> arm_spe_pkt_out_string(&err, &buf, &buf_len, "EV");
>>>> - print_event_list(&err, &buf, &buf_len, common_ev_strings, payload);
>>>> + payload = print_event_list(&err, &buf, &buf_len, common_ev_strings,
>>>> + payload);
>>>> +
>>>> + /* Try to decode IMPDEF bits for known CPUs */
>>>> + for (unsigned int i = 0; i < ARRAY_SIZE(event_print_handles); i++) {
>>>> + if (is_midr_in_range_list(midr,
>>>> + event_print_handles[i].midr_ranges))
>>>> + payload = print_event_list(&err, &buf, &buf_len,
>>>> + event_print_handles[i].ev_strings,
>>>> + payload);
>>>> + }
>>>>
>>>> return err;
>>>> }
>>>> @@ -506,7 +543,7 @@ static int arm_spe_pkt_desc_counter(const struct arm_spe_pkt *packet,
>>>> }
>>>>
>>>> int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
>>>> - size_t buf_len)
>>>> + size_t buf_len, u64 midr)
>>>> {
>>>> int idx = packet->index;
>>>> unsigned long long payload = packet->payload;
>>>> @@ -522,7 +559,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf,
>>>> arm_spe_pkt_out_string(&err, &buf, &blen, "%s", name);
>>>> break;
>>>> case ARM_SPE_EVENTS:
>>>> - err = arm_spe_pkt_desc_event(packet, buf, buf_len);
>>>> + err = arm_spe_pkt_desc_event(packet, buf, buf_len, midr);
>>>> break;
>>>> case ARM_SPE_OP_TYPE:
>>>> err = arm_spe_pkt_desc_op_type(packet, buf, buf_len);
>>>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> index adf4cde320aa..17b067fe3c87 100644
>>>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
>>>> @@ -11,7 +11,7 @@
>>>> #include <stddef.h>
>>>> #include <stdint.h>
>>>>
>>>> -#define ARM_SPE_PKT_DESC_MAX 256
>>>> +#define ARM_SPE_PKT_DESC_MAX 512
>>>>
>>>> #define ARM_SPE_NEED_MORE_BYTES -1
>>>> #define ARM_SPE_BAD_PACKET -2
>>>> @@ -186,5 +186,6 @@ const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
>>>> int arm_spe_get_packet(const unsigned char *buf, size_t len,
>>>> struct arm_spe_pkt *packet);
>>>>
>>>> -int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len);
>>>> +int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, size_t len,
>>>> + u64 midr);
>>>> #endif
>>>> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
>>>> index 7447b000f9cd..46f0309c092b 100644
>>>> --- a/tools/perf/util/arm-spe.c
>>>> +++ b/tools/perf/util/arm-spe.c
>>>> @@ -135,7 +135,7 @@ struct data_source_handle {
>>>> }
>>>>
>>>> static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> - unsigned char *buf, size_t len)
>>>> + unsigned char *buf, size_t len, u64 midr)
>>>> {
>>>> struct arm_spe_pkt packet;
>>>> size_t pos = 0;
>>>> @@ -161,7 +161,7 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> color_fprintf(stdout, color, " ");
>>>> if (ret > 0) {
>>>> ret = arm_spe_pkt_desc(&packet, desc,
>>>> - ARM_SPE_PKT_DESC_MAX);
>>>> + ARM_SPE_PKT_DESC_MAX, midr);
>>>> if (!ret)
>>>> color_fprintf(stdout, color, " %s\n", desc);
>>>> } else {
>>>> @@ -174,10 +174,10 @@ static void arm_spe_dump(struct arm_spe *spe __maybe_unused,
>>>> }
>>>>
>>>> static void arm_spe_dump_event(struct arm_spe *spe, unsigned char *buf,
>>>> - size_t len)
>>>> + size_t len, u64 midr)
>>>> {
>>>> printf(".\n");
>>>> - arm_spe_dump(spe, buf, len);
>>>> + arm_spe_dump(spe, buf, len, midr);
>>>> }
>>>>
>>>> static int arm_spe_get_trace(struct arm_spe_buffer *b, void *data)
>>>> @@ -1469,8 +1469,11 @@ static int arm_spe_process_auxtrace_event(struct perf_session *session,
>>>> /* Dump here now we have copied a piped trace out of the pipe */
>>>> if (dump_trace) {
>>>> if (auxtrace_buffer__get_data(buffer, fd)) {
>>>> + u64 midr = 0;
>>>> +
>>>> + arm_spe__get_midr(spe, buffer->cpu.cpu, &midr);
>>>
>>> Sashiko claims to have spotted an issue here:
>>> """
>>> Is it possible for arm_spe__get_midr() to cause a segmentation fault here?
>>>
>>> If the trace is from an older recording (metadata version 1) and the
>>> environment lacks a CPUID string (such as during cross-architecture
>>> analysis), perf_env__cpuid() returns NULL.
>>>
>>> It appears arm_spe__get_midr() then passes this NULL pointer to
>>> strtol(cpuid, NULL, 16), which leads to undefined behavior.
>>> """
>>>
>>> But this feels like, if this happens you're already having a bad time
>>> and these changes aren't necessarily making things worse.
>>>
>>> Thanks,
>>> Ian
>>>
>>
>> Yeah I think it might be possible so I can add an error instead of a
>> segfault. I'll check the rest of the Sashiko comments too.
>>
>>>> arm_spe_dump_event(spe, buffer->data,
>>>> - buffer->size);
>>>> + buffer->size, midr);
>>>> auxtrace_buffer__put_data(buffer);
>>>> }
>>>> }
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>
^ 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