* Re: [PATCH net-next 03/10] net: stmmac: move TSO VLAN tag insertion to core code
From: Russell King (Oracle) @ 2026-03-29 9:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <E1w6bKu-0000000ELtr-0U6v@rmk-PC.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:36:52PM +0000, Russell King (Oracle) wrote:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index e21ca1c70c6d..ed3e9515cf25 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -4419,19 +4419,6 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> u8 proto_hdr_len, hdr;
> dma_addr_t des;
>
> - /* Always insert VLAN tag to SKB payload for TSO frames.
> - *
> - * Never insert VLAN tag by HW, since segments split by
> - * TSO engine will be un-tagged by mistake.
> - */
> - if (skb_vlan_tag_present(skb)) {
> - skb = __vlan_hwaccel_push_inside(skb);
> - if (unlikely(!skb)) {
> - priv->xstats.tx_dropped++;
> - return NETDEV_TX_OK;
> - }
> - }
> -
> nfrags = skb_shinfo(skb)->nr_frags;
> queue = skb_get_queue_mapping(skb);
>
> @@ -4932,6 +4919,14 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
> features = vlan_features_check(skb, features);
>
> if (skb_is_gso(skb)) {
> + /* Always insert VLAN tag to SKB payload for TSO frames.
> + *
> + * Never insert VLAN tag by HW, since segments split by
> + * TSO engine will be un-tagged by mistake.
> + */
> + features &= ~(NETIF_F_HW_VLAN_STAG_TX |
> + NETIF_F_HW_VLAN_CTAG_TX);
> +
I'm wondering whether this is the correct place to do this. If as a
result of the following tests we fallback to software GSO, then we
will be submitting "normal" frames to the driver to transmit, which
means it can insert the VLAN tag in hardware.
So, I'm thinking this isn't the correct place for the test, but it
should be after the tests that disable NETIF_F_GSO_MASK and only be
masked out when the features mask still contains any of the
NETIF_F_GSO_MASK features. Anyone concur?
--
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
* [PATCH v2 RESEND] soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge
From: Luca Leonardo Scorcia @ 2026-03-29 9:12 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Matthias Brugger, Fabien Parent, linux-kernel, linux-arm-kernel
The original patch that was sent to the mailing lists included the values
for the route masks, but they got lost during merge: add back the full
register masks where missing.
Fixes: 060f7875bd23 ("soc: mediatek: mmsys: Add support for MT8167 SoC")
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/soc/mediatek/mt8167-mmsys.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/mediatek/mt8167-mmsys.h b/drivers/soc/mediatek/mt8167-mmsys.h
index c468926561b4..eef14083c47b 100644
--- a/drivers/soc/mediatek/mt8167-mmsys.h
+++ b/drivers/soc/mediatek/mt8167-mmsys.h
@@ -10,24 +10,29 @@
#define MT8167_DISP_REG_CONFIG_DISP_RDMA0_SOUT_SEL_IN 0x06c
#define MT8167_DITHER_MOUT_EN_RDMA0 0x1
+#define MT8167_DITHER_MOUT_EN_MASK 0x7
+
#define MT8167_RDMA0_SOUT_DSI0 0x2
+#define MT8167_RDMA0_SOUT_MASK 0x3
+
#define MT8167_DSI0_SEL_IN_RDMA0 0x1
+#define MT8167_DSI0_SEL_IN_MASK 0x3
static const struct mtk_mmsys_routes mt8167_mmsys_routing_table[] = {
MMSYS_ROUTE(OVL0, COLOR0,
MT8167_DISP_REG_CONFIG_DISP_OVL0_MOUT_EN, OVL0_MOUT_EN_COLOR0,
OVL0_MOUT_EN_COLOR0),
MMSYS_ROUTE(DITHER0, RDMA0,
- MT8167_DISP_REG_CONFIG_DISP_DITHER_MOUT_EN, MT8167_DITHER_MOUT_EN_RDMA0,
+ MT8167_DISP_REG_CONFIG_DISP_DITHER_MOUT_EN, MT8167_DITHER_MOUT_EN_MASK,
MT8167_DITHER_MOUT_EN_RDMA0),
MMSYS_ROUTE(OVL0, COLOR0,
MT8167_DISP_REG_CONFIG_DISP_COLOR0_SEL_IN, COLOR0_SEL_IN_OVL0,
COLOR0_SEL_IN_OVL0),
MMSYS_ROUTE(RDMA0, DSI0,
- MT8167_DISP_REG_CONFIG_DISP_DSI0_SEL_IN, MT8167_DSI0_SEL_IN_RDMA0,
+ MT8167_DISP_REG_CONFIG_DISP_DSI0_SEL_IN, MT8167_DSI0_SEL_IN_MASK,
MT8167_DSI0_SEL_IN_RDMA0),
MMSYS_ROUTE(RDMA0, DSI0,
- MT8167_DISP_REG_CONFIG_DISP_RDMA0_SOUT_SEL_IN, MT8167_RDMA0_SOUT_DSI0,
+ MT8167_DISP_REG_CONFIG_DISP_RDMA0_SOUT_SEL_IN, MT8167_RDMA0_SOUT_MASK,
MT8167_RDMA0_SOUT_DSI0),
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next 06/10] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
From: Russell King (Oracle) @ 2026-03-29 9:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <E1w6bL9-0000000ELu9-1quN@rmk-PC.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:37:07PM +0000, Russell King (Oracle) wrote:
> +static void stmmac_set_gso_types(struct stmmac_priv *priv, bool tso)
> +{
> + if (!tso) {
> + priv->gso_enabled_types = 0;
> + } else {
> + /* Manage oversized TCP frames for GMAC4 device */
> + priv->gso_enabled_types = SKB_GSO_TCPV4 | SKB_GSO_TCPV6;
> + if (priv->plat->core_type == DWMAC_CORE_GMAC4)
> + priv->gso_enabled_types |= SKB_GSO_UDP_L4;
I've been wondering whether keying all three of these off NETIF_F_TSO
is correct. Shouldn't SKB_GSP_UDP_L4 be dependent on NETIF_F_GSO_UDP_L4?
(The above code doesn't change the current driver behaviour, so this
would be a separate fix.)
> + }
> +}
> +
> /**
> * stmmac_tso_xmit - Tx entry point of the driver for oversized frames (TSO)
> * @skb : the socket buffer
> @@ -4671,7 +4683,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> u32 queue = skb_get_queue_mapping(skb);
> int nfrags = skb_shinfo(skb)->nr_frags;
> unsigned int first_entry, tx_packets;
> - int gso = skb_shinfo(skb)->gso_type;
> struct stmmac_txq_stats *txq_stats;
> struct dma_desc *desc, *first_desc;
> struct stmmac_tx_queue *tx_q;
> @@ -4683,14 +4694,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> if (priv->tx_path_in_lpi_mode && priv->eee_sw_timer_en)
> stmmac_stop_sw_lpi(priv);
>
> - /* Manage oversized TCP frames for GMAC4 device */
> - if (skb_is_gso(skb) && priv->tso) {
> - if (gso & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
> - return stmmac_tso_xmit(skb, dev);
> - if (priv->plat->core_type == DWMAC_CORE_GMAC4 &&
> - (gso & SKB_GSO_UDP_L4))
> - return stmmac_tso_xmit(skb, dev);
> - }
> + if (skb_is_gso(skb) &&
> + skb_shinfo(skb)->gso_type & priv->gso_enabled_types)
> + return stmmac_tso_xmit(skb, dev);
I'm also wondering whether we should check gso_type in our
.ndo_features_check() method rather than here - if we get a GSO skb at
this point for a type that we don't recognise, surely it is wrong to
pass it via the normal skb transmission flow.
Yet more worms in the stmmac can... :/
--
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] media: cedrus: skip invalid H.264 reference list entries
From: Jernej Škrabec @ 2026-03-29 9:21 UTC (permalink / raw)
To: mripard, Pengpeng Hou
Cc: paulk, mchehab, gregkh, wens, samuel, nicolas.dufresne,
linux-media, linux-staging, linux-arm-kernel, linux-sunxi,
linux-kernel, pengpeng
In-Reply-To: <20260324080856.56787-1-pengpeng@iscas.ac.cn>
Dne torek, 24. marec 2026 ob 09:08:56 Srednjeevropski poletni čas je Pengpeng Hou napisal(a):
> Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the
> stateless slice control and later uses their indices to look up
> decode->dpb[] in _cedrus_write_ref_list().
>
> Rejecting such controls in cedrus_try_ctrl() would break existing
> userspace, since stateless H.264 reference lists may legitimately carry
> out-of-range indices for missing references. Instead, guard the actual
> DPB lookup in Cedrus and skip entries whose indices do not fit the fixed
> V4L2_H264_NUM_DPB_ENTRIES array.
>
> This keeps the fix local to the driver use site and avoids out-of-bounds
> reads from malformed or unsupported reference list entries.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Krzysztof Kozlowski @ 2026-03-29 9:29 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-2-krishnagopi487@gmail.com>
On Sun, Mar 29, 2026 at 11:45:19AM +0530, Gopi Krishna Menon wrote:
> Convert the SPEAr Thermal Sensor bindings to DT schema.
>
> Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
> ---
> Changes since v1:
> - Changed unevaluatedProperties to additionalProperties
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Krzysztof Kozlowski @ 2026-03-29 9:31 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-3-krishnagopi487@gmail.com>
On Sun, Mar 29, 2026 at 11:45:20AM +0530, Gopi Krishna Menon wrote:
> st,thermal-flags is a required property in SPEAr Thermal Sensor node,
> which is incorrectly written as thermal_flags in spear13xx.dtsi.
>
> Rename thermal_flags to st,thermal-flags to fix the property name
Does this have an impact? If yes, then why no fixes? If no, then why
not? How this could ever worked? Maybe this is completely unnecessary.
We already talked about this and I don't get why this change is neeeded
and why we discuss the same problem.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Krzysztof Kozlowski @ 2026-03-29 9:34 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329-starfish-of-eternal-storm-f16de5@quoll>
On 29/03/2026 11:31, Krzysztof Kozlowski wrote:
> On Sun, Mar 29, 2026 at 11:45:20AM +0530, Gopi Krishna Menon wrote:
>> st,thermal-flags is a required property in SPEAr Thermal Sensor node,
>> which is incorrectly written as thermal_flags in spear13xx.dtsi.
>>
>> Rename thermal_flags to st,thermal-flags to fix the property name
>
> Does this have an impact? If yes, then why no fixes? If no, then why
> not? How this could ever worked? Maybe this is completely unnecessary.
>
> We already talked about this and I don't get why this change is neeeded
> and why we discuss the same problem.
and by "this change" I meant, "rename" part, instead of "removal".
Your task is analyze entire code, understand what was wrong and provide
proper solution.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next 01/10] net: stmmac: fix TSO support when some channels have TBS available
From: Russell King (Oracle) @ 2026-03-29 9:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <E1w6bKj-0000000ELtf-3md9@rmk-PC.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:36:41PM +0000, Russell King (Oracle) wrote:
> According to the STM32MP25xx manual, which is dwmac v5.3, TBS (time
> based scheduling) is not permitted for channels which have hardware
> TSO enabled. Intel's commit 5e6038b88a57 ("net: stmmac: fix TSO and
> TBS feature enabling during driver open") concurs with this, but it
> is incomplete.
>
> This commit avoids enabling TSO support on the channels which have
> TBS available, which, as far as the hardware is concerned, means we
> do not set the TSE bit in the DMA channel's transmit control register.
>
> However, the net device's features apply to all queues(channels), which
> means these channels may still be handed TSO skbs to transmit, and the
> driver will pass them to stmmac_tso_xmit(). This will generate the
> descriptors for TSO, even though the channel has the TSE bit clear.
>
> Fix this by checking whether the queue(channel) has TBS available,
> and if it does, fall back to software GSO support.
This is sufficient for the immediate issue of fixing the patch below,
but I think there's another issue that also needs fixing here.
TSO requires the hardware to support checksum offload, and there is
a comment in the driver:
/* DWMAC IPs can be synthesized to support tx coe only for a few tx
* queues. In that case, checksum offloading for those queues that don't
* support tx coe needs to fallback to software checksum calculation.
*
* Packets that won't trigger the COE e.g. most DSA-tagged packets will
* also have to be checksummed in software.
*/
So, it seems at the very least we need to add a check (in a subsequent
patch) for priv->plat->tx_queues_cfg[queue].coe_unsupported to
stmmac_channel_tso_permitted().
I'm also wondering about the stmmac_has_ip_ethertype() thing, which
checks whether the skb can be checksummed by the hardware, and how that
interacts with TSO, and whether that's yet another hole that needs
plugging.
--
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
* [BUG] net: ethernet: cortina: gemini: skb leak in gmac_rx() causes kernel lockup under sustained RX load
From: Andreas Haarmann-Thiemann @ 2026-03-29 10:11 UTC (permalink / raw)
To: linusw; +Cc: ulli.kroll, netdev, linux-arm-kernel
Hello,
I am writing to report an SKB memory leak in the Cortina Gemini Ethernet
driver (drivers/net/ethernet/cortina/gemini.c) that causes the device to
lock up under sustained receive load.
Hardware affected: Raidsonic IB-NAS4220-B (Storlink/Cortina Gemini SL3516,
ARM FA526), running OpenWrt 6.12.67.
--- Observed Behaviour ---
Under sustained RX load (e.g. large file transfers over the network), the
device freezes completely and requires a hard power cycle. No kernel panic
or oops is produced; the system simply stops responding.
--- Root Cause Analysis ---
In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when
gmac_get_queue_page() returns NULL for the second page of a multi-page
fragment, the driver logs an error and continues - but does not free the
in-progress skb that was already being assembled via napi_build_skb() /
napi_get_frags():
gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
if (!gpage) {
dev_err(geth->dev, "could not find mapping\n");
/* BUG: skb leaked here */
port->stats.rx_dropped++;
continue;
}
This path is distinct from the similar block in gmac_cleanup_rxq(), which
correctly only logs "could not find page" without an skb in flight.
Each occurrence of this error path leaks one skb. Under sustained traffic
the leak exhausts kernel memory, causing the observed lockup.
Note: this analysis is based on code review only. The fix below has not
yet been verified on hardware due to the driver being compiled into the
kernel (CONFIG_GEMINI_ETHERNET=y) on the affected device, which prevents
loading a patched module at runtime.
--- Proposed Fix ---
Free the in-progress skb via napi_free_frags() before continuing, matching
the pattern already used elsewhere in the driver:
diff --git a/drivers/net/ethernet/cortina/gemini.c
b/drivers/net/ethernet/cortina/gemini.c
--- a/drivers/net/ethernet/cortina/gemini.c
+++ b/drivers/net/ethernet/cortina/gemini.c
@@ -1491,6 +1491,10 @@ static int gmac_rx(struct napi_struct *napi, int
budget)
gpage = gmac_get_queue_page(geth, port, mapping +
PAGE_SIZE);
if (!gpage) {
dev_err(geth->dev, "could not find mapping\n");
+ if (skb) {
+ napi_free_frags(&port->napi);
+ skb = NULL;
+ }
port->stats.rx_dropped++;
continue;
}
--- Additional Notes ---
A similar "could not find page" error path exists in gmac_cleanup_rxq().
That path does not have an skb in flight at that point and does not require
the same fix.
I would be happy to submit this as a formal patch if the analysis looks
correct to you.
Thank you for your time.
Best regards,
Andreas Haarmann-Thiemann
eitschman@nebelreich.de
^ permalink raw reply
* [PATCH net-next v2] net: airoha: Delay offloading until all net_devices are fully registered
From: Lorenzo Bianconi @ 2026-03-29 10:32 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev
Netfilter flowtable can theoretically try to offload flower rules as soon
as a net_device is registered while all the other ones are not
registered or initialized, triggering a possible NULL pointer dereferencing
of qdma pointer in airoha_ppe_set_cpu_port routine. Moreover, if
register_netdev() fails for a particular net_device, there is a small
race if Netfilter tries to offload flowtable rules before all the
net_devices are properly unregistered in airoha_probe() error patch,
triggering a NULL pointer dereferencing in airoha_ppe_set_cpu_port
routine. In order to avoid any possible race, delay offloading until
all net_devices are registered in the networking subsystem.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v2:
- Do not grab flow_offload_mutex in airoha_register_gdm_devices() since
it can trigger a deadlock. Add DEV_STATE_REGISTERED flag instead to
mark when all net_devices are fully registered.
- Link to v1: https://lore.kernel.org/r/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 ++
drivers/net/ethernet/airoha/airoha_eth.h | 1 +
drivers/net/ethernet/airoha/airoha_ppe.c | 7 +++++++
3 files changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..743ef0db30980ce74059dfb63553030ef3bf735f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2957,6 +2957,8 @@ static int airoha_register_gdm_devices(struct airoha_eth *eth)
return err;
}
+ set_bit(DEV_STATE_REGISTERED, ð->state);
+
return 0;
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 7df4dbcd8861856c54c2a38bc89c69180ac2f6dc..af29fc74165b8fffb59f45b4725dbd963f1b876d 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -88,6 +88,7 @@ enum {
enum {
DEV_STATE_INITIALIZED,
+ DEV_STATE_REGISTERED,
};
enum {
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 58b14aea7c2f33ebce11c51d892eefff692378ca..c057bb2d105d92947bb8c421d89ee94fc0c10f2f 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1389,6 +1389,13 @@ int airoha_ppe_setup_tc_block_cb(struct airoha_ppe_dev *dev, void *type_data)
struct airoha_eth *eth = ppe->eth;
int err = 0;
+ /* Netfilter flowtable can try to offload flower rules while not all
+ * the net_devices are registered or initialized. Delay offloading
+ * until all net_devices are registered in the system.
+ */
+ if (!test_bit(DEV_STATE_REGISTERED, ð->state))
+ return -EBUSY;
+
mutex_lock(&flow_offload_mutex);
if (!eth->npu)
---
base-commit: ced629dc8e5c51ff2b5d847adeeb1035cd655d58
change-id: 20260321-airoha-regiser-race-fix-fe854f61d760
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
From: Dmitry Baryshkov @ 2026-03-29 11:08 UTC (permalink / raw)
To: Canfeng Zhuang
Cc: konradybcio, andersson, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-arm-kernel
In-Reply-To: <20260327083101.1343613-3-canfeng.zhuang@oss.qualcomm.com>
On Fri, Mar 27, 2026 at 04:31:01PM +0800, Canfeng Zhuang wrote:
> The monaco-evk mezzanine connector supports a robot expansion board that
> requires UART6, which is currently disabled. This prevents the expansion
> board from exchanging data and control commands.
>
> Enable UART6 and assign the serial2 alias to provide stable device
> enumeration for the expansion board.
>
> Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/monaco-evk.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> index 565418b86b2a..0b26861eac02 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
> @@ -21,6 +21,7 @@ aliases {
> ethernet0 = ðernet0;
> i2c1 = &i2c1;
> serial0 = &uart7;
> + serial2 = &uart6;
What happened to serial1?
> };
>
> chosen {
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] spi: stm32-ospi: Fix resource leak in remove() callback
From: Felix Gu @ 2026-03-29 11:14 UTC (permalink / raw)
To: Mark Brown, Maxime Coquelin, Alexandre Torgue, Patrice Chotard
Cc: linux-spi, linux-stm32, linux-arm-kernel, linux-kernel, Felix Gu
The remove() callback returned early if pm_runtime_resume_and_get()
failed, skipping the cleanup of spi controller and other resources.
Remove the early return so cleanup completes regardless of PM resume
result.
Fixes: 79b8a705e26c ("spi: stm32: Add OSPI driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/spi/spi-stm32-ospi.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/spi/spi-stm32-ospi.c b/drivers/spi/spi-stm32-ospi.c
index acf2d182e8b1..192a20de1ae6 100644
--- a/drivers/spi/spi-stm32-ospi.c
+++ b/drivers/spi/spi-stm32-ospi.c
@@ -984,11 +984,8 @@ static int stm32_ospi_probe(struct platform_device *pdev)
static void stm32_ospi_remove(struct platform_device *pdev)
{
struct stm32_ospi *ospi = platform_get_drvdata(pdev);
- int ret;
- ret = pm_runtime_resume_and_get(ospi->dev);
- if (ret < 0)
- return;
+ pm_runtime_resume_and_get(ospi->dev);
spi_unregister_controller(ospi->ctrl);
/* Disable ospi */
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260329-ospi-6aa5060f090e
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Michal Piekos @ 2026-03-29 11:43 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
Add support for timer by reusing existing sun4i timer driver.
H616 timer is compatible with earlier sunxi timer variants and provides
both clocksource and clockevent functionality. It runs from 24 MHz
oscillator. It can serve as broadcast clockevent for wake up from idle
states.
Tested on Orange Pi Zero 3:
- timer is registered as clocksource:
- switching clocksource at runtime works
- timer operates as a broadcast clockevent device
- no regression observed compared to arch_sys_counter
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Test results:
Clocksource switching:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
arch_sys_counter timer
echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
[ 5031.105997] clocksource: Switched to clocksource timer
Clockevent configuration:
cat /proc/timer_list
...
Tick Device: mode: 1
Broadcast device
Clock Event Device: sun4i_tick
max_delta_ns: 178956969070
min_delta_ns: 1000
mult: 51539608
shift: 31
mode: 1
next_event: 9223372036854775807 nsecs
set_next_event: sun4i_clkevt_next_event
shutdown: sun4i_clkevt_shutdown
periodic: sun4i_clkevt_set_periodic
oneshot: sun4i_clkevt_set_oneshot
resume: sun4i_clkevt_shutdown
event_handler: tick_handle_oneshot_broadcast
...
Cyclictest measurements:
Dominated by system scheduler latency and do not reflect clocksource
precision.
---
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index 8d1110c14bad..bf054869e78b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
};
};
+ timer0: timer@3009000 {
+ compatible = "allwinner,sun50i-h616-timer",
+ "allwinner,sun8i-a23-timer";
+ reg = <0x03009000 0xa0>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
watchdog: watchdog@30090a0 {
compatible = "allwinner,sun50i-h616-wdt",
"allwinner,sun6i-a31-wdt";
---
base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
change-id: 20260328-h616-timer-046e6ac3549e
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply related
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Andy Shevchenko @ 2026-03-29 11:49 UTC (permalink / raw)
To: Bartosz Golaszewski, Heikki Krogerus
Cc: Aaro Koskinen, Janusz Krzysztofik, Arnd Bergmann,
Bartosz Golaszewski, Tony Lindgren, Russell King, Dmitry Torokhov,
Hans de Goede, Linux-OMAP, linux-arm-kernel, linux-kernel,
Kevin Hilman
In-Reply-To: <CAMRc=McVPskF4pMQSz=hR8CkyZhoPmCU_yJFT66vgTCPJd3-Vw@mail.gmail.com>
+Cc: Heikki, the author of the code in question.
On Fri, Mar 27, 2026 at 06:23:29PM +0100, Bartosz Golaszewski wrote:
> On Fri, Mar 27, 2026 at 5:59 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> > > Hmm, I'm wondering if there's a race with consumers already requesting
> > > the GPIOs after the controller device is registered but before the
> > > software node is added. I'll send a version with software nodes being
> > > registered first, then passes as firmware nodes to the platform device
> > > API before the device is registered.
> >
> > It crashes early, I was able to get an UART log from OSK (another
> > 16xx board):
> >
> > [ 1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
> > [ 1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> > [ 1.019500] Stack: (0xc2809ed0 to 0xc280a000)
> > [ 1.024230] 9ec0: c072d000 c0529474 c06b3aa0 c050a3cc
> > [ 1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
> > [ 1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
> > [ 1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
> > [ 1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
> > [ 1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
> > [ 1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
> > [ 1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
> > [ 1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [ 1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> > [ 1.111206] Call trace:
> > [ 1.111328] software_node_to_swnode from device_add_software_node+0x20/0x80
> > [ 1.121704] device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
> > [ 1.128997] omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
> > [ 1.135620] do_one_initcall from kernel_init_freeable+0x1ec/0x240
> > [ 1.142517] kernel_init_freeable from kernel_init+0x10/0x108
> > [ 1.148864] kernel_init from ret_from_fork+0x14/0x28
> > [ 1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
> > [ 1.159820] 9fa0: 00000000 00000000 00000000 00000000
> > [ 1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [ 1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > [ 1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
> > [ 1.191040] ---[ end trace 0000000000000000 ]---
> > [ 1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [ 1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
> Thanks. This makes sense. Both omap16xx_gpio_init() and
> software_node_init() run as postcore_initcall() so if the order is not
> right, it will fail.
>
> Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> reason to run software_node_init() as a postcore initcall? It only
> allocates the kset, can we move it to core_initcall() by any chance?
Good question. I don't know why it's chosen like this.
Let ask Heikki, who is the author of the code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Jernej Škrabec @ 2026-03-29 11:53 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Michal Piekos
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
In-Reply-To: <20260329-h616-timer-v1-1-5966d0420a66@mmpsystems.pl>
Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> Add support for timer by reusing existing sun4i timer driver.
>
> H616 timer is compatible with earlier sunxi timer variants and provides
> both clocksource and clockevent functionality. It runs from 24 MHz
> oscillator. It can serve as broadcast clockevent for wake up from idle
> states.
>
> Tested on Orange Pi Zero 3:
> - timer is registered as clocksource:
> - switching clocksource at runtime works
> - timer operates as a broadcast clockevent device
> - no regression observed compared to arch_sys_counter
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> Test results:
>
> Clocksource switching:
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> arch_sys_counter timer
> echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> [ 5031.105997] clocksource: Switched to clocksource timer
>
> Clockevent configuration:
> cat /proc/timer_list
> ...
> Tick Device: mode: 1
> Broadcast device
> Clock Event Device: sun4i_tick
> max_delta_ns: 178956969070
> min_delta_ns: 1000
> mult: 51539608
> shift: 31
> mode: 1
> next_event: 9223372036854775807 nsecs
> set_next_event: sun4i_clkevt_next_event
> shutdown: sun4i_clkevt_shutdown
> periodic: sun4i_clkevt_set_periodic
> oneshot: sun4i_clkevt_set_oneshot
> resume: sun4i_clkevt_shutdown
> event_handler: tick_handle_oneshot_broadcast
> ...
>
> Cyclictest measurements:
> Dominated by system scheduler latency and do not reflect clocksource
> precision.
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> index 8d1110c14bad..bf054869e78b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> };
> };
>
> + timer0: timer@3009000 {
> + compatible = "allwinner,sun50i-h616-timer",
> + "allwinner,sun8i-a23-timer";
You have to add above combo to DT bindings.
Best regards,
Jernej
> + reg = <0x03009000 0xa0>;
> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h616-wdt",
> "allwinner,sun6i-a31-wdt";
>
> ---
> base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> change-id: 20260328-h616-timer-046e6ac3549e
>
> Best regards,
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: enable h616 timer support
From: Michal Piekos @ 2026-03-29 12:07 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <5977334.DvuYhMxLoT@jernej-laptop>
On Sun, Mar 29, 2026 at 01:53:45PM +0200, Jernej Škrabec wrote:
> Dne nedelja, 29. marec 2026 ob 13:43:04 Srednjeevropski poletni čas je Michal Piekos napisal(a):
> > Add support for timer by reusing existing sun4i timer driver.
> >
> > H616 timer is compatible with earlier sunxi timer variants and provides
> > both clocksource and clockevent functionality. It runs from 24 MHz
> > oscillator. It can serve as broadcast clockevent for wake up from idle
> > states.
> >
> > Tested on Orange Pi Zero 3:
> > - timer is registered as clocksource:
> > - switching clocksource at runtime works
> > - timer operates as a broadcast clockevent device
> > - no regression observed compared to arch_sys_counter
> >
> > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > ---
> > Test results:
> >
> > Clocksource switching:
> > cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> > arch_sys_counter timer
> > echo timer > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > [ 5031.105997] clocksource: Switched to clocksource timer
> >
> > Clockevent configuration:
> > cat /proc/timer_list
> > ...
> > Tick Device: mode: 1
> > Broadcast device
> > Clock Event Device: sun4i_tick
> > max_delta_ns: 178956969070
> > min_delta_ns: 1000
> > mult: 51539608
> > shift: 31
> > mode: 1
> > next_event: 9223372036854775807 nsecs
> > set_next_event: sun4i_clkevt_next_event
> > shutdown: sun4i_clkevt_shutdown
> > periodic: sun4i_clkevt_set_periodic
> > oneshot: sun4i_clkevt_set_oneshot
> > resume: sun4i_clkevt_shutdown
> > event_handler: tick_handle_oneshot_broadcast
> > ...
> >
> > Cyclictest measurements:
> > Dominated by system scheduler latency and do not reflect clocksource
> > precision.
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > index 8d1110c14bad..bf054869e78b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -228,6 +228,15 @@ cpu_speed_grade: cpu-speed-grade@0 {
> > };
> > };
> >
> > + timer0: timer@3009000 {
> > + compatible = "allwinner,sun50i-h616-timer",
> > + "allwinner,sun8i-a23-timer";
>
> You have to add above combo to DT bindings.
>
> Best regards,
> Jernej
Not sure I understand your comment correctly but binding for h616 is already
there:
Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml:21-27
- items:
- enum:
- allwinner,sun20i-d1-timer
- allwinner,sun50i-a64-timer
- allwinner,sun50i-h6-timer
- allwinner,sun50i-h616-timer
- const: allwinner,sun8i-a23-timer
BR
Michal
>
> > + reg = <0x03009000 0xa0>;
> > + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > watchdog: watchdog@30090a0 {
> > compatible = "allwinner,sun50i-h616-wdt",
> > "allwinner,sun6i-a31-wdt";
> >
> > ---
> > base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
> > change-id: 20260328-h616-timer-046e6ac3549e
> >
> > Best regards,
> >
>
>
>
>
^ permalink raw reply
* [PATCH v3 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
This patch series converts SPEAr Thermal Sensor bindings to DT schema
and removes the thermal_flags property from spear13xx.dtsi.
Changes since v2:
- Reword the commit message and subject to correct explanation in patch 2
- No changes in patch 1
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Gopi Krishna Menon (2):
dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
ARM: dts: st: spear: remove undocumented thermal_flags property
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
3 files changed, 36 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
--
2.52.0
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry, Krzysztof Kozlowski
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v2:
- No changes
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt
deleted file mode 100644
index 93e3b67c102d..000000000000
--- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* SPEAr Thermal
-
-Required properties:
-- compatible : "st,thermal-spear1340"
-- reg : Address range of the thermal registers
-- st,thermal-flags: flags used to enable thermal sensor
-
-Example:
-
- thermal@fc000000 {
- compatible = "st,thermal-spear1340";
- reg = <0xfc000000 0x1000>;
- st,thermal-flags = <0x7000>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
new file mode 100644
index 000000000000..e3462a974691
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr Thermal Sensor
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+properties:
+ compatible:
+ const: st,thermal-spear1340
+
+ reg:
+ maxItems: 1
+
+ st,thermal-flags:
+ description: flags used to enable thermal sensor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - st,thermal-flags
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Sebastián Alba @ 2026-03-29 12:35 UTC (permalink / raw)
To: Phil Elwell
Cc: Greg Kroah-Hartman, Florian Fainelli,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, linux-staging,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
linux-arm-kernel, Dave Stevenson, Raspberry Pi Kernel Maintenance
In-Reply-To: <CAMEGJJ0zgab3WN=rb2o+UgEq_coX5LnkyPj3UNrBSMQbTGU7Zw@mail.gmail.com>
Hi Phil,
Thanks for the pointer. I've opened PR #7294 against rpi-6.6.y:
https://github.com/raspberrypi/linux/pull/7294
Sebastián
El dom, 29 mar 2026 a las 2:51, Phil Elwell (<phil@raspberrypi.com>) escribió:
>
>
>
> On Sun, 29 Mar 2026, 08:05 Sebastián Alba, <sebasjosue84@gmail.com> wrote:
>>
>> Hi Greg, Thanks for the quick review.
>>
>> Regarding kmalloc_array(): the patch does replace kmalloc() with
>> kmalloc_array() - perhaps the question is about the remaining
>> ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
>> That multiplication is now safe because kmalloc_array() already
>> verified that op_count * sizeof(*block) does not overflow(if it did,
>> kmalloc_array would have returned NULL and we'd have exited). Happy to
>> add a comment clarifying this if you prefer.
>>
>> Regarding the Fixes tag: the commit dfdc7a773374 is from the
>> raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
>> appears to only exist in the Raspberry Pi kernel fork and has not been
>> merged into mainline staging.
>>
>> I apologize for sending this to the wrong tree. Should these patches
>> go directly to the Raspberry Pi kernel maintainers
>> (kernel-list@raspberrypi.com) instead?
>
>
> Open a Pull Request at our Linux repo:
>
> https://github com/raspberrypi/linux/
>
> Phil
>
>> El dom, 29 mar 2026 a las 0:33, Greg Kroah-Hartman
>> (<gregkh@linuxfoundation.org>) escribió:
>> >
>> > On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
>> > > From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>> > >
>> > > vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
>> > > compute the allocation size passed to kmalloc(). Since ioparam.op_count
>> > > is a __u32 supplied directly by userspace via ioctl, an attacker can
>> > > choose a value that causes the multiplication to overflow on 32-bit
>> > > platforms, resulting in a small allocation followed by a large
>> > > copy_from_user() and out-of-bounds heap reads in the subsequent loop.
>> > >
>> > > Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
>> > > Also add an early return for op_count == 0 to avoid a zero-size
>> > > allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
>> > > correctly indicate out of memory.
>> >
>> > Why not use kmalloc_array() instead?
>> >
>> > >
>> > > The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
>> > > reachable by any unprivileged local user.
>> > >
>> > > Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
>> >
>> > I do not see that git id anywhere, what tree is it in?
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>>
>>
>> --
>> Sebastián Alba
--
Sebastián Alba
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: st: spear: remove undocumented thermal_flags property
From: Gopi Krishna Menon @ 2026-03-29 12:34 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
spear13xx.dtsi defines a thermal_flags property in spear thermal sensor
node which is both unused in kernel and undocumented in spear thermal
sensor's binding.
There were no dtbs_check warnings associated with this property as the
underlying spear thermal binding was not converted to DTSchema.
Most likely st,thermal-flags is a misspelling of thermal_flags in
spear13xx.dtsi. Since both st/spear1310.dtsi and st/spear1340.dtsi
define st,thermal-flags property in spear thermal sensor node, we can
safely remove this property from spear13xx.dtsi.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v2:
- Reword the commit message and subject to correct explanation in patch 2
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 159e941708ca..0bb88f2d4ef5 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -332,7 +332,6 @@ wdt@ec800620 {
thermal@e07008c4 {
compatible = "st,thermal-spear1340";
reg = <0xe07008c4 0x4>;
- thermal_flags = <0x7000>;
};
};
};
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] media: cedrus: skip invalid H.264 reference list entries
From: Chen-Yu Tsai @ 2026-03-29 12:44 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mripard, Pengpeng Hou, paulk, mchehab, gregkh, samuel,
nicolas.dufresne, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <2823210.mvXUDI8C0e@jernej-laptop>
On Sun, Mar 29, 2026 at 5:21 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Dne torek, 24. marec 2026 ob 09:08:56 Srednjeevropski poletni čas je Pengpeng Hou napisal(a):
> > Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the
> > stateless slice control and later uses their indices to look up
> > decode->dpb[] in _cedrus_write_ref_list().
> >
> > Rejecting such controls in cedrus_try_ctrl() would break existing
> > userspace, since stateless H.264 reference lists may legitimately carry
> > out-of-range indices for missing references. Instead, guard the actual
> > DPB lookup in Cedrus and skip entries whose indices do not fit the fixed
> > V4L2_H264_NUM_DPB_ENTRIES array.
> >
> > This keeps the fix local to the driver use site and avoids out-of-bounds
> > reads from malformed or unsupported reference list entries.
> >
> > Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>
> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Chen-Yu Tsai <wens@kernel.org>
This fixes a KASAN slab-use-after-free warning when running fluster H.264
tests.
^ permalink raw reply
* [PATCH 0/3] arm64: dts: imx8m: Correct PAD settings for PMIC_nINT (2nd part)
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
There was a patchset for i.MX8MP [1], but after further check,
i.MX8MM/N were missed, there are three boards that might also has
interrupt storm issue. I not have the boards, per NXP board design
, PMIC_nINT requires CPU internal pull up, I think most vendors will
follow NXP design. So updates the i.MX8MM/N boards, but I not have
the boards for testing. If board owners would give a test, that would
be great.
[1] https://lore.kernel.org/all/20260326-imx8mp-dts-fix-v2-v2-0-62c4ce727448@nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 ++--
arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260329-imx8m-regulator-4e2e3f1b6ed5
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH 1/3] arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
While at here, also correct interrupt type as IRQ_TYPE_LEVEL_LOW.
Fixes: cbd3ef64eb9d1 ("arm64: dts: Add support for Emtop SoM & Baseboard")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
index 67d22d3768aa8ae7343cffeebcfdde89ed25cc2d..507d1824d99d99b1f795b14aea538444c9476f65 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emtop-som.dtsi
@@ -60,7 +60,7 @@ pmic@25 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
regulators {
buck1: BUCK1 {
@@ -194,7 +194,7 @@ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
pinctrl_pmic: emtop-pmic-grp {
fsl,pins = <
- MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
>;
};
--
2.37.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
Fixes: 3e56e354db6d3 ("arm64: dts: freescale: add initial device tree for TQMa8MQNL with i.MX8MN")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
index 31a3ca137e63640a2387d3497274f10a6b8c6766..48a687926aa1b88a3d8bef25ff97bebec3777b00 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl.dtsi
@@ -283,7 +283,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x84>;
+ fsl,pins = <MX8MN_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1c4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
--
2.37.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
From: Peng Fan (OSS) @ 2026-03-29 13:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Himanshu Bhavani, Alexander Stein
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux, Peng Fan
In-Reply-To: <20260329-imx8m-regulator-v1-0-802c0ec507cc@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
there might be interrupt storm for this board. Need to set PAD PUE and PU
together to make pull up work properly.
Fixes: dfcd1b6f7620e ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
index 29b298af0d739100d33ff43a8b955a37821b3ef7..1b5ba3c47164f28756bb99210a5961bfaa881220 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi
@@ -292,7 +292,7 @@ pinctrl_i2c1_gpio: i2c1gpiogrp {
};
pinctrl_pmic: pmicgrp {
- fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x94>;
+ fsl,pins = <MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x1d4>;
};
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
--
2.37.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox