* [PATCH 1/4] dt-bindings: arm: sunxi: add Radxa Cubie A7S
From: Enzo Adriano via B4 Relay @ 2026-06-13 9:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc, Enzo Adriano
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-0-7787c94681db@gmail.com>
From: Enzo Adriano <enzo.adriano.code@gmail.com>
Document the Radxa Cubie A7S board compatible for the Allwinner A733 SoC.
Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index e6443c266fa1..9f603681c78e 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -850,6 +850,11 @@ properties:
- const: radxa,cubie-a5e
- const: allwinner,sun55i-a527
+ - description: Radxa Cubie A7S
+ items:
+ - const: radxa,cubie-a7s
+ - const: allwinner,sun60i-a733
+
- description: Remix Mini PC
items:
- const: jide,remix-mini-pc
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260613-st-mmc-v4-0-b3c385617c16@gmail.com>
Convert STMicroelectronics sdhci-st MMC/SD controller binding to
DT schema.
The 'icn' clock and 'top-mmc-delay' register region are optional in
the text binding and remain so in the YAML schema. minItems: 1 is
set on clock-names and reg-names to match the flexibility of their
paired clocks and reg properties, preserving compatibility with
existing in-tree DTS nodes that provide only a single clock or
register entry.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 92 +++++++++++++++++
2 files changed, 92 insertions(+), 110 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
deleted file mode 100644
index ccf82b4ee838..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* STMicroelectronics sdhci-st MMC/SD controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties
-used by the sdhci-st driver.
-
-Required properties:
-- compatible: Must be "st,sdhci" and it can be compatible to "st,sdhci-stih407"
- to set the internal glue logic used for configuring the MMC
- subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
- family).
-
-- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- interrupts: One mmc interrupt should be described here.
-- interrupt-names: Should be "mmcirq".
-
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-- reg: This must provide the host controller base address and it can also
- contain the FlashSS Top register for TX/RX delay used by the driver
- to configure DLL inside the flashSS, if so reg-names must also be
- specified.
-
-Optional properties:
-- reg-names: Should be "mmc" and "top-mmc-delay". "top-mmc-delay" is optional
- for eMMC on stih407 family silicon to configure DLL inside FlashSS.
-
-- non-removable: Non-removable slot. Also used for configuring mmcss in STiH407 SoC
- family.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- bus-width: Number of data lines.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- max-frequency: Can be 200MHz, 100MHz or 50MHz (default) and used for
- configuring the CCONFIG3 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- resets: Phandle and reset specifier pair to softreset line of HC IP.
- See: Documentation/devicetree/bindings/reset/reset.txt
-
-- vqmmc-supply: Phandle to the regulator dt node, mentioned as the vcc/vdd
- supply in eMMC/SD specs.
-
-- sd-uhs-sdr50: To enable the SDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-sdr104: To enable the SDR104 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-ddr50: To enable the DDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-Example:
-
-/* Example stih416e eMMC configuration */
-
-mmc0: sdhci@fe81e000 {
- compatible = "st,sdhci";
- reg = <0xfe81e000 0x1000>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_a1_ls 1>;
- bus-width = <8>
-
-/* Example SD stih407 family configuration */
-
-mmc1: sdhci@9080000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09080000 0x7ff>;
- reg-names = "mmc";
- interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sd1>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_1>;
- resets = <&softreset STIH407_MMC1_SOFTRESET>;
- bus-width = <4>;
-};
-
-/* Example eMMC stih407 family configuration */
-
-mmc0: sdhci@9060000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
- reg-names = "mmc", "top-mmc-delay";
- interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
- vqmmc-supply = <&vmmc_reg>;
- max-frequency = <200000000>;
- bus-width = <8>;
- non-removable;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
- sd-uhs-ddr50;
-};
diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
new file mode 100644
index 000000000000..0bf4fc3ca699
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/st,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SDHCI-ST MMC/SD Controller
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+description:
+ The STMicroelectronics SDHCI-ST MMC/SD host controller is compliant with
+ the SD Host Controller Interface (SDHCI) specification and is used to
+ interface with MMC, SD and SDIO cards. The ST SDHCI controller extends the
+ standard SDHCI capabilities with platform-specific configurations such as
+ additional register regions, clock inputs, and delay control mechanisms
+ required for signal timing adjustments to support high-speed modes across
+ different ST SoCs.
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,sdhci
+ - items:
+ - const: st,sdhci-stih407
+ - const: st,sdhci
+
+ reg:
+ minItems: 1
+ items:
+ - description: MMC controller base registers
+ - description: FlashSS Top registers for TX/RX DLL delay configuration
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: top-mmc-delay
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Clock for the MMC controller
+ - description: Interconnect (ICN) clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: icn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: mmcirq
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ mmc@9060000 {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
+ reg-names = "mmc", "top-mmc-delay";
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0>;
+ clock-names = "mmc", "icn";
+ clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+ <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+ bus-width = <8>;
+ };
+...
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v5 3/3] net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
From: Lorenzo Bianconi @ 2026-06-13 9:39 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal,
Alexander Lobakin
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-3-c11de08486d1@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 11446 bytes --]
Commenting on sashiko's report:
https://sashiko.dev/#/patchset/20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1%40kernel.org
[...]
> static void airoha_dev_set_qdma(struct airoha_gdm_dev *dev)
> {
> struct net_device *netdev = netdev_from_priv(dev);
> + struct airoha_qdma *cur_qdma, *qdma;
> struct airoha_eth *eth = dev->eth;
> int ppe_id;
>
> /* QDMA0 is used for lan ports while QDMA1 is used for WAN ports */
> - dev->qdma = ð->qdma[!airoha_is_lan_gdm_dev(dev)];
> - netdev->irq = dev->qdma->irq_banks[0].irq;
> + qdma = ð->qdma[!airoha_is_lan_gdm_dev(dev)];
> + cur_qdma = airoha_qdma_deref(dev);
> + if (netif_running(netdev))
> + airoha_qdma_start(qdma);
> +
> + rcu_assign_pointer(dev->qdma, qdma);
> + netdev->irq = qdma->irq_banks[0].irq;
>
> ppe_id = !airoha_is_lan_gdm_dev(dev) && airoha_ppe_is_enabled(eth, 1);
> airoha_ppe_set_cpu_port(dev, ppe_id, airoha_get_fe_port(dev));
> +
> + if (!cur_qdma)
> + return;
> +
> + synchronize_rcu();
> + netif_tx_wake_all_queues(netdev);
> +
> + if (netif_running(netdev))
> + airoha_qdma_stop(cur_qdma);
> }
- When we switch the QDMA of a running device, airoha_qdma_stop() might
free pending SKBs via dev_kfree_skb_any() in airoha_qdma_cleanup_tx_queue().
Are these SKBs freed without calling netdev_tx_completed_queue() to
update Byte Queue Limits (BQL)?
Since the device is running, could the BQL counters leak and cause the
TX queue to permanently hang once the limit is reached?
- As pointed out in path 1/3, this is a pre-existing issue since we have the
same problem running airoha_dev_stop() for a QDMA single-user device
(airoha_qdma_cleanup_tx_queue() can run before the pending TX NAPI).
I will fix the problem with a dedicated patch.
>
> static int airoha_dev_init(struct net_device *netdev)
> @@ -2180,9 +2244,9 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_qdma *qdma = dev->qdma;
> u32 nr_frags, tag, msg0, msg1, len;
> struct airoha_queue_entry *e;
> + struct airoha_qdma *qdma;
> struct netdev_queue *txq;
- This is a pre-existing issue, but does the TX path modify the TCP header
directly without ensuring it is in the linear region?
- This issue (not introduced by this patch) has been already reported in the
past and we already agreed that it can't occur.
> struct airoha_queue *q;
> LIST_HEAD(tx_list);
> @@ -2191,6 +2255,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> u16 index;
> u8 fport;
>
[...]
> @@ -2793,11 +2869,12 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
> u32 channel = TC_H_MIN(opt->classid) % AIROHA_NUM_QOS_CHANNELS;
> int err, num_tx_queues = netdev->real_num_tx_queues;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> - struct airoha_qdma *qdma = dev->qdma;
> + struct airoha_qdma *qdma;
>
> /* Here we need to check the requested QDMA channel is not already
> * in use by another net_device running on the same QDMA block.
> */
> + qdma = airoha_qdma_deref(dev);
- This is a pre-existing issue, but does modifying real_num_tx_queues
as a dense counter cause problems when QoS leaf queues are allocated
with sparse IDs?
- I have already a fix for this issue I need to post.
> if (test_and_set_bit(channel, qdma->qos_channel_map)) {
> NL_SET_ERR_MSG_MOD(opt->extack,
> "qdma qos channel already in use");
> @@ -2831,7 +2908,7 @@ static int airoha_qdma_set_rx_meter(struct airoha_gdm_dev *dev,
> u32 rate, u32 bucket_size,
[...]
> +
> +static int airoha_enable_qos_for_gdm34(struct net_device *netdev,
> + struct netlink_ext_ack *extack)
> +{
> + struct airoha_gdm_dev *wan_dev, *dev = netdev_priv(netdev);
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + int err = -EBUSY;
> +
> + if (port->id != AIROHA_GDM3_IDX &&
> + port->id != AIROHA_GDM4_IDX) {
> + /* HW QoS is always supported by GDM1 and GDM2 */
> + return 0;
> + }
> +
> + if (!airoha_is_lan_gdm_dev(dev)) /* Already enabled */
> + return 0;
> +
> + mutex_lock(&flow_offload_mutex);
> +
> + wan_dev = airoha_get_wan_gdm_dev(eth);
> + if (wan_dev) {
> + if ((wan_dev->flags & AIROHA_PRIV_F_QOS) ||
> + wan_dev->port->id == AIROHA_GDM2_IDX) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "QoS configured for WAN device");
> + goto error_unlock;
> + }
> + airoha_disable_qos_for_gdm34(netdev_from_priv(wan_dev));
> + }
> +
> + dev->flags |= AIROHA_PRIV_F_WAN;
> + airoha_dev_set_qdma(dev);
> + err = airoha_enable_gdm2_loopback(dev);
> + if (err)
> + goto error_disable_wan;
> +
> + err = airoha_set_macaddr(dev, netdev->dev_addr);
> + if (err)
> + goto error_disable_loopback;
> +
> + if (netif_running(netdev)) {
> + u32 pse_port;
> +
> + pse_port = airoha_ppe_is_enabled(eth, 1) ? FE_PSE_PORT_PPE2
> + : FE_PSE_PORT_PPE1;
> + airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(port->id),
> + pse_port);
> + }
> +
> + mutex_unlock(&flow_offload_mutex);
> +
> + return 0;
> +
> +error_disable_loopback:
> + airoha_disable_gdm2_loopback(dev);
> +error_disable_wan:
> + dev->flags &= ~AIROHA_PRIV_F_WAN;
> + airoha_dev_set_qdma(dev);
> +error_unlock:
> + mutex_unlock(&flow_offload_mutex);
> +
> + return err;
> +}
- If airoha_set_macaddr() fails and we jump to error_disable_loopback,
the original wan_dev was preemptively demoted to LAN mode, but the error
path doesn't restore it.
Since the requesting device is also rolled back to LAN, does this leave
the system entirely without a WAN device? Would this permanently break
routing on the original WAN interface until manually reconfigured?
- If airoha_enable_qos_for_gdm34() fails, the system will continue routing
packets and, even if we re-promote the original interface to WAN, the user
will need to re-apply the same configuration to offload the intended
Qdisc on the new interface.
Moreover, please note this corner case occurs just if the original
interface has no Qdisc already configured on it. In the common case, the
user has previously removed the configured Qdisc on the original interface
and so, the roll-back process will still be partial.
In the end, airoha_set_macaddr() can fail just if the device is not
well-configured.
For the reasons above, I guess it does not worth to reset the original
interface to WAN if airoha_set_macaddr() fails.
Regards,
Lorenzo
> +
> static int airoha_tc_htb_destroy(struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> @@ -3038,6 +3205,8 @@ static int airoha_tc_htb_destroy(struct net_device *netdev)
> for_each_set_bit(q, dev->qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS)
> airoha_tc_remove_htb_queue(netdev, q);
>
> + dev->flags &= ~AIROHA_PRIV_F_QOS;
> +
> return 0;
> }
>
> @@ -3057,24 +3226,33 @@ static int airoha_tc_get_htb_get_leaf_queue(struct net_device *netdev,
> return 0;
> }
>
> -static int airoha_tc_setup_qdisc_htb(struct net_device *dev,
> +static int airoha_tc_setup_qdisc_htb(struct net_device *netdev,
> struct tc_htb_qopt_offload *opt)
> {
> switch (opt->command) {
> - case TC_HTB_CREATE:
> + case TC_HTB_CREATE: {
> + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + int err;
> +
> + err = airoha_enable_qos_for_gdm34(netdev, opt->extack);
> + if (err)
> + return err;
> +
> + dev->flags |= AIROHA_PRIV_F_QOS;
> break;
> + }
> case TC_HTB_DESTROY:
> - return airoha_tc_htb_destroy(dev);
> + return airoha_tc_htb_destroy(netdev);
> case TC_HTB_NODE_MODIFY:
> - return airoha_tc_htb_modify_queue(dev, opt);
> + return airoha_tc_htb_modify_queue(netdev, opt);
> case TC_HTB_LEAF_ALLOC_QUEUE:
> - return airoha_tc_htb_alloc_leaf_queue(dev, opt);
> + return airoha_tc_htb_alloc_leaf_queue(netdev, opt);
> case TC_HTB_LEAF_DEL:
> case TC_HTB_LEAF_DEL_LAST:
> case TC_HTB_LEAF_DEL_LAST_FORCE:
> - return airoha_tc_htb_delete_leaf_queue(dev, opt);
> + return airoha_tc_htb_delete_leaf_queue(netdev, opt);
> case TC_HTB_LEAF_QUERY_QUEUE:
> - return airoha_tc_get_htb_get_leaf_queue(dev, opt);
> + return airoha_tc_get_htb_get_leaf_queue(netdev, opt);
> default:
> return -EOPNOTSUPP;
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 24fd8dcf7fca..d1390ffcea7c 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -540,11 +540,12 @@ struct airoha_qdma {
>
> enum airoha_priv_flags {
> AIROHA_PRIV_F_WAN = BIT(0),
> + AIROHA_PRIV_F_QOS = BIT(1),
> };
>
> struct airoha_gdm_dev {
> + struct airoha_qdma __rcu *qdma;
> struct airoha_gdm_port *port;
> - struct airoha_qdma *qdma;
> struct airoha_eth *eth;
>
> DECLARE_BITMAP(qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS);
> @@ -676,6 +677,16 @@ int airoha_get_fe_port(struct airoha_gdm_dev *dev);
> bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> struct airoha_gdm_dev *dev);
>
> +extern struct mutex flow_offload_mutex;
> +
> +static inline struct airoha_qdma *
> +airoha_qdma_deref(struct airoha_gdm_dev *dev)
> +{
> + return rcu_dereference_protected(dev->qdma,
> + lockdep_rtnl_is_held() ||
> + lockdep_is_held(&flow_offload_mutex));
> +}
> +
> void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport);
> bool airoha_ppe_is_enabled(struct airoha_eth *eth, int index);
> void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 91bcc55a6ac6..1d1b1a57d795 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -15,7 +15,10 @@
> #include "airoha_regs.h"
> #include "airoha_eth.h"
>
> -static DEFINE_MUTEX(flow_offload_mutex);
> +/* Serialize airoha_gdm_dev flags, QDMA pointer and PPE CPU port
> + * configuration.
> + */
> +DEFINE_MUTEX(flow_offload_mutex);
> static DEFINE_SPINLOCK(ppe_lock);
>
> static const struct rhashtable_params airoha_flow_table_params = {
> @@ -86,8 +89,8 @@ static u32 airoha_ppe_get_timestamp(struct airoha_ppe *ppe)
>
> void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport)
> {
> - struct airoha_qdma *qdma = dev->qdma;
> - struct airoha_eth *eth = qdma->eth;
> + struct airoha_qdma *qdma = airoha_qdma_deref(dev);
> + struct airoha_eth *eth = dev->eth;
> u8 qdma_id = qdma - ð->qdma[0];
> u32 fe_cpu_port;
>
> diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
> index 436f3c8779c1..4e17dfbcf2b8 100644
> --- a/drivers/net/ethernet/airoha/airoha_regs.h
> +++ b/drivers/net/ethernet/airoha/airoha_regs.h
> @@ -376,6 +376,7 @@
>
> #define REG_SRC_PORT_FC_MAP6 0x2298
> #define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
> +#define FC_MAP6_DEF_VALUE 0x1b1a1918
>
> #define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
>
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v4 1/2] arm: dts: st: align node patterns with established convention
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260613-st-mmc-v4-0-b3c385617c16@gmail.com>
Update ST MMC DTS node patterns to match established convention.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/st/stih407-family.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/st/stih407-family.dtsi b/arch/arm/boot/dts/st/stih407-family.dtsi
index 3e6a0542e3ae..08acba209c56 100644
--- a/arch/arm/boot/dts/st/stih407-family.dtsi
+++ b/arch/arm/boot/dts/st/stih407-family.dtsi
@@ -596,7 +596,7 @@ spi@9542000 {
status = "disabled";
};
- mmc0: sdhci@9060000 {
+ mmc0: mmc@9060000 {
compatible = "st,sdhci-stih407", "st,sdhci";
status = "disabled";
reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
@@ -611,7 +611,7 @@ mmc0: sdhci@9060000 {
bus-width = <8>;
};
- mmc1: sdhci@9080000 {
+ mmc1: mmc@9080000 {
compatible = "st,sdhci-stih407", "st,sdhci";
status = "disabled";
reg = <0x09080000 0x7ff>;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/2] dt-bindings: mmc: st,sdhci: convert STMicroelectronics SDHCI-ST MMC/SD Controller controller binding to YAML
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
This patch series converts the legacy text-based Device Tree binding for
STMicroelectronics SDHCI-ST MMC/SD controller to DT schema (YAML) format.
Note:
The patch "dt-bindings: mmc: st,sdhci: convert to DT schema"
depends on the patch "arm: dts: st: align node patterns with established
convention". If the DT schema patch is applied before the DTS
cleanup patch, `dtbs_check` will fail due to the presence of the removed
properties in the existing DTS.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v4:
- st,sdhci: Add minItems: 1 to clock-names and reg-names to allow single-entry
configurations, fixing dtbs_check failures on nodes that omit the
optional 'icn' clock or 'top-mmc-delay' register region.
- st,sdhci: Modify the commit message to explain the changes.
- Link to v3: https://patch.msgid.link/20260508-st-mmc-v3-0-81c329ed28e8@gmail.com
Changes in v3:
- st,sdhci: Edit description of reg property. Modify reg-names. Add
"minItems" for clocks and clock-names properties.
- Modify the commit message to match with the updated changes.
- Link to v2: https://patch.msgid.link/20260503-st-mmc-v2-0-11ae3216d2ce@gmail.com
Changes in v2:
- Fix node name in DTS for the MMC to match with the estableshed convention.
- st,sdhci: drop unnecessary properties, modify "reg", "reg-names" and
"clock-names" properties, include an allOf with $ref to mmc-controller.
- Link to v1: https://patch.msgid.link/20260409-st-mmc-v1-1-4c54321c3535@gmail.com
---
Charan Pedumuru (2):
arm: dts: st: align node patterns with established convention
dt-bindings: mmc: st,sdhci: Convert to DT schema
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 92 +++++++++++++++++
arch/arm/boot/dts/st/stih407-family.dtsi | 4 +-
3 files changed, 94 insertions(+), 112 deletions(-)
---
base-commit: cf2cd8efd046c561191b8541d32a8bfe845bf06b
change-id: 20260327-st-mmc-c906ad95ff83
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <b428d57ba5464f1226daf099877f4c25fa4fc191.camel@gmail.com>
Dne sobota, 13. junij 2026 ob 10:34:42 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Hi Jernej,
>
> On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> > Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > > only reserves this memory internally, but doesn't carve out the region
> > > in the fdt passed to Linux.
> > >
> > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> >
> > NAK. It is job of boot procedure to properly inject TF-A reserved node.
> > Any issue should be fixed there.
>
>
> like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
> ("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> ? ;-)
I was against that too.
It's time to be fixed in bootloader.
Best regards,
Jernej
>
> > Best regards,
> > Jernej Skrabec
> >
> > > ---
> > > Changelog:
> > > v4:
> > > - new patch
> > >
> > > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > index 7cb06b19b5a5..d8391663fd1d 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > > #clock-cells = <0>;
> > > };
> > >
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /*
> > > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > > + * This is added by BL31 itself, but some bootloaders fail
> > > + * to propagate this into the DTB handed to kernels.
> > > + */
> > > + secmon@40000000 {
> > > + reg = <0x0 0x40000000 0x0 0x40000>;
> > > + no-map;
> > > + };
> > > + };
> > > +
> > > timer {
> > > compatible = "arm,armv8-timer";
> > > interrupts = <GIC_PPI 13
>
>
^ permalink raw reply
* Re: [PATCH 4/7] drivers: staging: media: sunxi: cedrus: add H616 variant
From: Jernej Škrabec @ 2026-06-13 9:33 UTC (permalink / raw)
To: wens
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, linux-media, linux-staging,
devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <CAGb2v64wDvLMFn9DYs-kH1S2PpHJat-imxR5eJSQAUYjOp=Xdg@mail.gmail.com>
Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > > The Allwinner H616 SoC has a video engine hardware block like the one
> > > found on previous generations such as the H6. In addition to the
> > > currently supported features of the H6, it is also supposed to include
> >
> > Remove "supposed".
>
> I can't actually verify that, so "supposed" is accurate from my point of
> view.
Isn't info from manual good enough?
In the interest of unblocking this, I would be fine with "supposed" too,
but manual and all my experiments show VP9 is supported.
Best regards,
Jernej
>
> ChenYu
>
> > > a VP9 decoder. However software support for this is currently missing
> > > and still needs to be reverse engineered from the vendor BSP.
> > >
> > > Add the compatible for the H616 variant, using the H6 variant data.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> >
> > With that:
> > Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> >
> > Best regards,
> > Jernej
> >
> >
>
^ permalink raw reply
* Re: [PATCH net-next v5 1/3] net: airoha: use int instead of atomic_t for qdma users counter
From: Lorenzo Bianconi @ 2026-06-13 9:06 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-1-c11de08486d1@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3901 bytes --]
> QDMA users counter is always accessed holding RTNL lock so we do not
> require atomic_t for it.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 504247c8bae9..9eb9b6a139b3 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1812,7 +1812,7 @@ static int airoha_dev_open(struct net_device *netdev)
> airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
> - atomic_inc(&qdma->users);
> + qdma->users++;
>
> if (!airoha_is_lan_gdm_dev(dev) &&
> airoha_ppe_is_enabled(qdma->eth, 1))
> @@ -1866,7 +1866,7 @@ static int airoha_dev_stop(struct net_device *netdev)
> REG_GDM_FWD_CFG(port->id),
> FE_PSE_PORT_DROP);
>
> - if (atomic_dec_and_test(&qdma->users)) {
> + if (!--qdma->users) {
> airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
commenting on sashiko's report:
https://sashiko.dev/#/patchset/20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1%40kernel.org
- This is a pre-existing issue, but by not cleaning the TX queues when
qdma->users > 0, does this leave the stopped device's packets in flight?
When airoha_dev_stop() is called, it resets the device's BQL counters via
netdev_tx_reset_subqueue(). By skipping the cleanup when other devices are
still sharing this QDMA ring, any pending skbs originating from the stopped
device are left to linger in the hardware TX ring.
Because the hardware continues to process the shared ring on behalf of the
remaining interfaces, the active NAPI poll will process their completions in
airoha_qdma_tx_napi_poll():
if (skb) {
struct netdev_queue *txq;
txq = skb_get_tx_queue(skb->dev, skb);
netdev_tx_completed_queue(txq, 1, skb->len);
dev_kfree_skb_any(skb);
}
Can this cause an unsigned underflow in dql->num_queued since the BQL
state was already reset to 0 by ndo_stop?
- This issue is valid, but as pointed out by sashiko, this problem has not
been introduced by this patch. In particular, I think we should remove
netdev_tx_reset_subqueue() in airoha_dev_stop() and run
netdev_tx_completed_queue() in airoha_qdma_cleanup_tx_queue(). We need to
pay attention to not loop over already unregistered net_devices in
airoha_qdma_cleanup_tx_queue() run from airoha_remove().
I will post a dedicated patch for this issue.
- Also, if the device was being unregistered, unregister_netdev() frees the
netdev memory without waiting for TX skbs (which do not hold a reference to
dev). Could this lead to a use-after-free when dereferencing skb->dev here?
Should the driver selectively purge skbs belonging to the stopping netdev
from the shared TX ring before ndo_stop returns?
- I do not think this is a problem in the current codebase since the
net_devices are unregistered just during module unload running
airoha_remove() where we run airoha_qdma_stop_napi() to stop TX/RX NAPIs.
Regards,
Lorenzo
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 8f42973f9cf5..24fd8dcf7fca 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -526,7 +526,7 @@ struct airoha_qdma {
> struct airoha_eth *eth;
> void __iomem *regs;
>
> - atomic_t users;
> + int users;
>
> struct airoha_irq_bank irq_banks[AIROHA_MAX_NUM_IRQ_BANKS];
>
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v8 next 04/10 Resend v2] arm_mpam: Refactor rmid to reqPARTID/PMG mapping
From: Zeng Heng @ 2026-06-13 8:59 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, Kefeng Wang, sunnanyong
In-Reply-To: <924fbfbc-995f-e291-8849-efcb8e01ef98@huawei.com>
Hi James,
>> @@ -478,6 +518,7 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
>> enum resctrl_conf_type cdp_type, u32 closid, u32 rmid, u64 *val)
>> {
>> struct mon_cfg cfg;
>> + u32 reqpartid = rmid2reqpartid(rmid);
>>
>> if (!mpam_is_enabled())
>> return -EINVAL;
>> @@ -493,8 +534,8 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
>> cfg = (struct mon_cfg) {
>> .mon = mon_idx,
>> .match_pmg = true,
>> - .partid = closid,
>> - .pmg = rmid,
>> + .partid = (cdp_type == CDP_CODE) ? reqpartid + 1 : reqpartid,
>> + .pmg = rmid2pmg(rmid),
>
> Not using the CLOSID here breaks multiple control groups.
>
After carefully reviewing your comments and Martin's patch series,
I tried to understand why there's insistence that CLOSID information
is necessary to support multiple control groups, but that's actually
not the case.
Before proceeding, allow me to introduce CPARTID (control partition ID,
no longer borrowing the intPARTID concept). All partids_per_closid
PARTIDs associated with it share the same control scheme under this
CPARTID.
Each PARTID within the partids_per_closid associated with a CPARTID is
called MPARTID (monitor partition ID, no longer borrowing the reqPARTID
concept). It refers to the PARTID used to represent different monitoring
groups under the same control scheme.
I've summarized the ID conversion diagrams from you and Martin as
follows:
+-------------------------+-----+------------------+
| CLOSID |{CDP}| RMID |
+-------------------------+-----+------------+-----+
| MPARTID | PMG |
+-------------------------------+------------+ |
| MPARTID_hi (base_partid) : MPARTID_lo | |
+-------------------------------+------------+-----+
Where (closid|cdp) = base_partid,
rmid = mpartid_lo * pmg_num + pmg,
and mpartid = base_partid * partids_per_closid + mpartid_lo,
with mpartid_lo in the range [0, partids_per_closid).
In this scheme, CLOSID and RMID are coupled together to form MPARTID,
which represents the monitor group PARTID.
In current patchset design, decoupling CLOSID and RMID, letting them
represent CPARTID and (MPARTID,PMG) pair respectively, rather than
having RMID depend on CLOSID to derive MPARTID. This decoupling is
essential for future dynamic allocation, because the relationship
between MPARTID and CPARTID must rely on table lookup rather than linear
mapping. If don't decouple in the static allocation design, we would
need another refactor when considering dynamic allocation extensibility.
+-------------------------------------------+-----+
| CLOSID |{CDP}|
+-------------------------------------------+-----+
| CPARTID (base_partid) |
+-------------------------------------------------+
+-----------------------------------+-----+-------+
| RMID_hi |{CDP}|RMID_lo|
+-----------------------------------+-----+-------+
| MPARTID | PMG |
+--------------+--------------------------+ |
| MPARTID_hi : MPARTID_lo (base_partid) | |
+--------------+--------------------------+-------+
Where (closid|cdp) = base_partid,
rmid_lo = pmg,
and (rmid_hi|cdp) = mpartid = mpartid_hi * (partid_num /
partids_per_closid) + base_partid,
with mpartid_hi in the range [0, partids_per_closid).
The reason of using base_partid as MPARTID_lo is to keep base_partid
contiguous and CLOSIDs are allocated contiguously. This does mean
MPARTIDs under the same CPARTID won't be contiguous, but that's
inherently difficult to guarantee with dynamic allocation anyway.
The control path uses CLOSID alone (CPARTID), and the monitor path uses
RMID alone (the (MPARTID, PMG) pair). This definition also aligns
closely with the native resctrl concepts: CLOSID (Class of Service ID,
corresponding to CPARTID) and RMID (Resource Monitor ID, corresponding
to the (MPARTID, PMG) pair).
In the end, the number of control groups is determined by the number of
CPARTIDs. Both of these ID translation schemes support multiple control
groups.
Could you please help outline the pros and cons of each approach?
This will determine which direction I take for subsequent iterations.
Thanks in advance.
Best Regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH RESEND v2 1/1] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Lothar Rubusch @ 2026-06-13 8:52 UTC (permalink / raw)
To: Herbert Xu
Cc: thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, krzk+dt, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <aipAf_uZnX_gwZnl@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 6:59 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Jun 09, 2026 at 09:47:23AM +0000, Lothar Rubusch wrote:
> >
> > diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> > index 4c9af737b33a..20cd915ea8a3 100644
> > --- a/drivers/crypto/atmel-sha204a.c
> > +++ b/drivers/crypto/atmel-sha204a.c
> > @@ -31,10 +31,15 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
> > struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
> > struct hwrng *rng = areq;
> >
> > - if (status)
> > + if (status) {
> > dev_warn_ratelimited(&i2c_priv->client->dev,
> > "i2c transaction failed (%d)\n",
> > status);
> > + kfree(work_data);
> > + rng->priv = 0;
>
> Why is this necessary? It appears that rng_read_nonblocking already
> zeroes rng->priv.
>
IMHO this is not the same. The patch targets the error path. If the
`status` in `atmel_sha204a_rng_done()` is failed, then failed `work_data` is
still assigned and `rng->priv` is not zeroed at the moment. Only a
subsequent call to `rng_read_nonblocking()` will set `rng->priv = 0;`
The call order is something like this:
1. atmel_sha204a_init // module setup
2. atmel_sha204a_rng_read_nonblocking // call 1
3. atmel_sha204a_rng_done // if fail, still copies
work_data <-- patch clears here
...
4. atmel_sha204a_rng_read_nonblocking // call 2, clears rng->priv = 0
Originally this was a sashiko finding, when I move the RNG part into the
common driver. Reason: Actually all Atmel ECC and Atmel SHA204a devices
support the same RNG mech. Thus part of my refactoring is moving it to the
common core driver atmel_i2c. I was advised by the maintainer to use also
sashiko's feedback. So, I went on identifying sashiko issues and have a
look into it, if I can provide a fix for it. This is one of them.
Sashiko asked:
"If the I2C transaction fails here, we still assign the work_data to
rng->priv. Since kmalloc_obj() uses GFP_ATOMIC and does not zero memory,
does this risk leaking uninitialized slab memory or stale data from
previous reads when the next non-blocking read copies from
work_data->cmd.data?"
ref: https://sashiko.dev/#/patchset/20260512224349.64621-1-l.rubusch%40gmail.com
[search for `atmel_i2c_rng_done` on that link]
I'm not sure about the risk or the (real) severity sashiko mentiones
here. But it seems to
be correct, when atmel_sha204a_rng_done() fails in the status, it
continues assigning the
failed result in the work_data:
static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
void *areq, int status)
{
struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
struct hwrng *rng = areq;
if (status)
dev_warn_ratelimited(&i2c_priv->client->dev,
"i2c transaction failed (%d)\n",
status);
rng->priv = (unsigned long)work_data;
atomic_dec(&i2c_priv->tfm_count);
}
Hence, my proposed patch will stop it passing work_data, if status is
failed. It will not
assign rng->priv anymore then containing old data, but clear it. It
will free the `work_data`
to provoke a new allocation happening in `atmel_sha204a_rng_read_nonblocking()`.
The patch is sashiko and maintainer reviewed and solves sashikos complaints.
ref: https://sashiko.dev/#/patchset/20260609094723.47237-1-l.rubusch%40gmail.com
Setting `rng->priv = 0;` is rather safety here.
Thank you for asking. Accept, drop or modification needed - please,
leave me a note,
I'd highly appreciate.
Best,
L
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix always-true condition in PPE1 queue reservation loop
From: Lorenzo Bianconi @ 2026-06-13 8:36 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca3de.ad59c0a6.147df9.2ac1@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
> In airoha_fe_pse_ports_init(), the inner condition for PPE1 queue
> reservation is identical to the for-loop bound, making it always true
> and the else branch dead code:
>
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_PPE1]; q++) {
> if (q < pse_port_num_queues[FE_PSE_PORT_PPE1]) /* always true */
> set RSV_PAGES;
> else
> set 0; /* unreachable */
> }
>
> The intended behavior is to reserve pages only for the first half of
> the queues, matching the PPE2 implementation on line 334 which
> correctly uses the /2 divisor. Fix the PPE1 condition accordingly.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11..999f517 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -311,7 +311,7 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
> PSE_QUEUE_RSV_PAGES);
> /* PPE1 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_PPE1]; q++) {
> - if (q < pse_port_num_queues[FE_PSE_PORT_PPE1])
> + if (q < pse_port_num_queues[FE_PSE_PORT_PPE1] / 2)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_PPE1, q,
> PSE_QUEUE_RSV_PAGES);
> else
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Alexander Sverdlin @ 2026-06-13 8:34 UTC (permalink / raw)
To: Jernej Škrabec, linux-arm-kernel, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <_6NEZ78hR8a_3V2bhBAGoQ@gmail.com>
Hi Jernej,
On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > only reserves this memory internally, but doesn't carve out the region
> > in the fdt passed to Linux.
> >
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
>
> NAK. It is job of boot procedure to properly inject TF-A reserved node.
> Any issue should be fixed there.
like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
? ;-)
> Best regards,
> Jernej Skrabec
>
> > ---
> > Changelog:
> > v4:
> > - new patch
> >
> > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > index 7cb06b19b5a5..d8391663fd1d 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > #clock-cells = <0>;
> > };
> >
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /*
> > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > + * This is added by BL31 itself, but some bootloaders fail
> > + * to propagate this into the DTB handed to kernels.
> > + */
> > + secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x40000>;
> > + no-map;
> > + };
> > + };
> > +
> > timer {
> > compatible = "arm,armv8-timer";
> > interrupts = <GIC_PPI 13
--
Alexander Sverdlin.
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix typos in comments and Kconfig
From: Lorenzo Bianconi @ 2026-06-13 8:30 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca74a.c5b1db4e.21a698.01e7@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
> Fix several typos found during code review:
> - Kconfig: "Aiorha" -> "Airoha" in NET_AIROHA_FLOW_STATS help text
> - Comment: "CMD1" -> "CDM1" (Central DMA, not Command)
> - Comments: "GMD1/2/3/4" -> "GDM1/2/3/4" (Gigabit DMA, not GMD)
>
> These are pure comment and documentation fixes with no functional impact.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/Kconfig | 2 +-
> drivers/net/ethernet/airoha/airoha_eth.c | 10 +++++-----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/Kconfig b/drivers/net/ethernet/airoha/Kconfig
> index ad3ce50..1f6640a 100644
> --- a/drivers/net/ethernet/airoha/Kconfig
> +++ b/drivers/net/ethernet/airoha/Kconfig
> @@ -29,6 +29,6 @@ config NET_AIROHA_FLOW_STATS
> bool "Airoha flow stats"
> depends on NET_AIROHA && NET_AIROHA_NPU
> help
> - Enable Aiorha flowtable statistic counters.
> + Enable Airoha flowtable statistic counters.
>
> endif #NET_VENDOR_AIROHA
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11..9d9d34a 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -294,18 +294,18 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
> FIELD_PREP(PSE_ALLRSV_MASK, all_rsv));
> }
>
> - /* CMD1 */
> + /* CDM1 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_CDM1]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_CDM1, q,
> PSE_QUEUE_RSV_PAGES);
> - /* GMD1 */
> + /* GDM1 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_GDM1]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM1, q,
> PSE_QUEUE_RSV_PAGES);
> - /* GMD2 */
> + /* GDM2 */
> for (q = 6; q < pse_port_num_queues[FE_PSE_PORT_GDM2]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM2, q, 0);
> - /* GMD3 */
> + /* GDM3 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_GDM3]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM3, q,
> PSE_QUEUE_RSV_PAGES);
> @@ -340,7 +340,7 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
> q, 0);
> }
> }
> - /* GMD4 */
> + /* GDM4 */
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_GDM4]; q++)
> airoha_fe_set_pse_oq_rsv(eth, FE_PSE_PORT_GDM4, q,
> PSE_QUEUE_RSV_PAGES);
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix non-standard return value in airoha_ppe_get_wdma_info()
From: Lorenzo Bianconi @ 2026-06-13 8:27 UTC (permalink / raw)
To: Wayen.Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca3d9.ad59c0a6.147df9.2a62@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
> airoha_ppe_get_wdma_info() returns -1 when the last path in the
> forwarding path stack is not of type DEV_PATH_MTK_WDMA. This is not
> a standard kernel error code. Replace it with -EINVAL since the
> input path type is invalid from the caller's perspective.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_ppe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 5c9dff6..7260177 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -264,7 +264,7 @@ static int airoha_ppe_get_wdma_info(struct net_device *dev, const u8 *addr,
>
> path = &stack.path[stack.num_paths - 1];
> if (path->type != DEV_PATH_MTK_WDMA)
> - return -1;
> + return -EINVAL;
>
> info->idx = path->mtk_wdma.wdma_idx;
> info->bss = path->mtk_wdma.bss;
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 8:22 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-7-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Add reserved-memory node carving out Trusted Firmware-A region spanning
> fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> itself passes the address range in the fdt to U-Boot, U-Boot currently
> only reserves this memory internally, but doesn't carve out the region
> in the fdt passed to Linux.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
NAK. It is job of boot procedure to properly inject TF-A reserved node.
Any issue should be fixed there.
Best regards,
Jernej Skrabec
> ---
> Changelog:
> v4:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index 7cb06b19b5a5..d8391663fd1d 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> #clock-cells = <0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /*
> + * 256 KiB reserved for Trusted Firmware-A (BL31).
> + * This is added by BL31 itself, but some bootloaders fail
> + * to propagate this into the DTB handed to kernels.
> + */
> + secmon@40000000 {
> + reg = <0x0 0x40000000 0x0 0x40000>;
> + no-map;
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <GIC_PPI 13
>
^ permalink raw reply
* Re: [PATCH v4 5/7] arm64: dts: allwinner: a100: Add LRADC node
From: Jernej Škrabec @ 2026-06-13 8:20 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-6-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:19 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> A100/A133 SoCs feature a Low Rate ADC (LRADC) for Key application.
>
> Specs:
> - Power supply voltage: 1.8 V
> - Reference voltage: 1.35 V
> - Interrupt support
> - Support Hold Key and General Key
> - Support normal, continue and single work mode
> - 6-bits resolution, sample rate up to 2 kHz
> - Voltage input range between 0 and 1.35 V
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> ---
> Changelog:
> v4:
> - added allwinner,sun50i-a100-lradc compatible
> v3:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index b3fb1e0ee796..7cb06b19b5a5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -466,6 +466,15 @@ ths: thermal-sensor@5070400 {
> #thermal-sensor-cells = <1>;
> };
>
> + lradc: lradc@5070800 {
> + compatible = "allwinner,sun50i-a100-lradc", "allwinner,sun50i-r329-lradc";
Break this into two lines, like usb_otg below. With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej Skrabec
> + reg = <0x05070800 0x400>;
> + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_LRADC>;
> + resets = <&ccu RST_BUS_LRADC>;
> + status = "disabled";
> + };
> +
> usb_otg: usb@5100000 {
> compatible = "allwinner,sun50i-a100-musb",
> "allwinner,sun8i-a33-musb";
>
^ permalink raw reply
* Re: [RFC PATCH v4 7/9] arm64: dts: rockchip: rk356x: Add the NPU and its IOMMU
From: Jonas Karlman @ 2026-06-13 8:18 UTC (permalink / raw)
To: MidG971
Cc: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson,
dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik
In-Reply-To: <20260613070116.438906-8-midgy971@gmail.com>
Hi Midgy,
On 6/13/2026 9:01 AM, MidG971 wrote:
> From: Midgy BALON <midgy971@gmail.com>
>
> The RK3568 has an NVDLA-derived NPU at fde40000 with its own IOMMU at
> fde4b000. Add both nodes (disabled by default) and the NPU power-domain
> child under the PMU power-controller, and point rockchip,pmu at the PMU
> syscon that controls the NPU NoC bus-idle.
>
> Besides the SCMI compute clock, assign the CRU CLK_NPU so the NPU AXI
> bus clock comes up at 200 MHz rather than the 12 MHz boot default.
>
> The power-domain deliberately carries no pm_qos: qos_npu sits behind the
> NPU NoC, which is gated until the NPU is brought up, so a genpd power-off
> QoS save would fault reading it.
>
> Signed-off-by: Midgy BALON <midgy971@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> index 64bdd8b7754b5..313db59c1aed8 100644
> --- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> @@ -512,6 +512,13 @@ power-domain@RK3568_PD_GPU {
> #power-domain-cells = <0>;
> };
>
> + pd_npu: power-domain@RK3568_PD_NPU {
> + reg = <RK3568_PD_NPU>;
> + clocks = <&cru ACLK_NPU_PRE>,
> + <&cru HCLK_NPU_PRE>;
> + #power-domain-cells = <0>;
> + };
> +
> /* These power domains are grouped by VD_LOGIC */
> power-domain@RK3568_PD_VI {
> reg = <RK3568_PD_VI>;
> @@ -572,6 +579,37 @@ power-domain@RK3568_PD_RKVENC {
> };
> };
>
> + rknn_core_0: npu@fde40000 {
> + compatible = "rockchip,rk3568-rknn-core";
> + reg = <0x0 0xfde40000 0x0 0x1000>,
> + <0x0 0xfde41000 0x0 0x1000>,
> + <0x0 0xfde43000 0x0 0x1000>;
> + reg-names = "pc", "cna", "core";
> + interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_NPU>, <&cru HCLK_NPU>,
> + <&scmi_clk SCMI_CLK_NPU>, <&cru PCLK_NPU_PRE>;
> + clock-names = "aclk", "hclk", "npu", "pclk";
> + assigned-clocks = <&scmi_clk SCMI_CLK_NPU>, <&cru CLK_NPU>;
> + assigned-clock-rates = <200000000>, <600000000>;
This looks strange, the SCMI clk can be seen as a virtual clock that
changes between normal CRU NPU clk and a PVTPLL NPU clk (depending on
rate). 200 MHz, a typical opp-suspend value (switch to CRU clk instead
of PVTPLL), will set the CLK_NPU rate to 200 MHz, then setting CLK_NPU
to 600 MHz (the lowest rate that activates PVTPLL mode) outside of SCMI
control looks strange.
Suggest you only set SCMI NPU clk rate to 200 or 400 MHz and drop any
special handling, e.g. noc_init, to closer match RK3588 and defer any
use of PVTPLL clk to a future series that also adds OPP support.
> + resets = <&cru SRST_A_NPU>, <&cru SRST_H_NPU>;
> + reset-names = "srst_a", "srst_h";
> + power-domains = <&power RK3568_PD_NPU>;
> + rockchip,pmu = <&pmu>;
This looks wrong, the rockchip,pmu prop is typically used to reference
PMU GRF, see i.e. pinctrl node, not the power-management that is seem to
be correctly abstracted using power-domains above, please drop this prop.
Regards,
Jonas
> + iommus = <&rknn_mmu_0>;
> + status = "disabled";
> + };
> +
> + rknn_mmu_0: iommu@fde4b000 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xfde4b000 0x0 0x40>;
> + interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "aclk", "iface";
> + clocks = <&cru ACLK_NPU>, <&cru HCLK_NPU>;
> + power-domains = <&power RK3568_PD_NPU>;
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> gpu: gpu@fde60000 {
> compatible = "rockchip,rk3568-mali", "arm,mali-bifrost";
> reg = <0x0 0xfde60000 0x0 0x4000>;
^ permalink raw reply
* Re: [PATCH v4 1/7] arm64: defconfig: Enable Allwinner LRADC input driver
From: Jernej Škrabec @ 2026-06-13 8:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-2-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:15 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Enable Allwinner LRADC input driver as module to support buttons on Baijie
> HelperBoard A133.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej Skrabec
^ permalink raw reply
* Re: [PATCH] net: correcting section tags for .init and .exit data/functions
From: kernel test robot @ 2026-06-13 8:05 UTC (permalink / raw)
To: xur, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Neal Cardwell, Kuniyuki Iwashima, Willem de Bruijn,
David Ahern, Ido Schimmel, Andreas Färber,
Manivannan Sadhasivam, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Maciej Żenczykowski,
Yue Haibing, Jeff Layton, Kees Cook, Fernando Fernandez Mancera,
Gustavo A. R. Silva, Sabrina Dubroca, Masahiro Yamada,
Nicolas Schier, linux-kernel, linux-arm-kernel, linux-actions
Cc: llvm, oe-kbuild-all, netdev
In-Reply-To: <20260612162257.896792-1-xur@google.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 2b414a95b8f7307d42173ba9e580d6d3e2bcbfce]
url: https://github.com/intel-lab-lkp/linux/commits/xur-google-com/net-correcting-section-tags-for-init-and-exit-data-functions/20260613-002737
base: 2b414a95b8f7307d42173ba9e580d6d3e2bcbfce
patch link: https://lore.kernel.org/r/20260612162257.896792-1-xur%40google.com
patch subject: [PATCH] net: correcting section tags for .init and .exit data/functions
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260613/202606131033.U9FHCI7B-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260613/202606131033.U9FHCI7B-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606131033.U9FHCI7B-lkp@intel.com/
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> WARNING: modpost: vmlinux: section mismatch in reference: tcpv6_init+0x68 (section: .text) -> mptcpv6_init (section: .init.text)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 02/11] iio: adc: change from %ld to %pe for PTR_ERR() printing
From: Jernej Škrabec @ 2026-06-13 8:06 UTC (permalink / raw)
To: linux-iio, Vojtěch Krátký
Cc: Vojtěch Krátký, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Chen-Yu Tsai, Samuel Holland,
Sakari Ailus, Linus Walleij, Wolfram Sang, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260604120201.116925-3-vo.kratky@seznam.cz>
Dne četrtek, 4. junij 2026 ob 13:59:22 Srednjeevropski poletni čas je Vojtěch Krátký napisal(a):
> Replace numeric PTR_ERR() logging with the %pe format specifier
> so that error values are printed in a more readable form.
>
> This change was identified using a Coccinelle semantic patch.
>
> No functional change intended.
>
> Signed-off-by: Vojtěch Krátký <vo.kratky@seznam.cz>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH] drm/sun4i: fix refcount leak in sun4i_backend_init_sat()
From: Jernej Škrabec @ 2026-06-13 7:50 UTC (permalink / raw)
To: wens, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
samuel, Wentao Liang
Cc: dri-devel, linux-arm-kernel, linux-sunxi, linux-kernel,
Wentao Liang, stable
In-Reply-To: <20260607030950.83636-1-vulab@iscas.ac.cn>
Dne nedelja, 7. junij 2026 ob 05:09:50 Srednjeevropski poletni čas je Wentao Liang napisal(a):
> When sun4i_backend_init_sat() calls reset_control_deassert() it
> increments the deassert_count of the reset controller, and must
> pair that with a reset_control_assert() call to decrement it.
> In the error path where clk_prepare_enable() fails, the function
> returns immediately without calling reset_control_assert(), leaking
> the reference count. Other error paths, like the devm_clk_get()
> failure, correctly jump to the err_assert_reset label which performs
> the missing assert.
>
> Fix the leak by using the existing err_assert_reset label in the
> clk_prepare_enable error path instead of returning directly.
>
> Cc: stable@vger.kernel.org
> Fixes: 440d2c7b127a ("drm/sun4i: backend: Handle the SAT")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH net-next v8 3/6] net: stmmac: eic7700: make RGMII delay properties optional
From: Andrew Lunn @ 2026-06-13 7:48 UTC (permalink / raw)
To: Maxime Chevallier
Cc: lizhi2, devicetree, andrew+netdev, davem, edumazet, kuba, robh,
krzk+dt, conor+dt, netdev, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, pjw, palmer, aou, alex, linux-riscv,
linux-stm32, linux-arm-kernel, linux-kernel, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, lee
In-Reply-To: <eaa645fc-be06-4a15-8c2f-6e82129c4715@bootlin.com>
On Wed, Jun 10, 2026 at 10:26:50AM +0200, Maxime Chevallier wrote:
> Hi,
>
> On 6/10/26 03:29, lizhi2@eswincomputing.com wrote:
> > From: Zhi Li <lizhi2@eswincomputing.com>
> >
> > Make rx-internal-delay-ps and tx-internal-delay-ps optional in the
> > EIC7700 DWMAC driver.
> >
> > The driver previously required both properties to be present and would
> > fail probe when they were missing. This restricts valid hardware
> > configurations where RGMII timing is instead provided by the PHY or
> > board design.
> >
> > Update the driver to treat missing delay properties as zero delay,
> > allowing systems without explicit MAC-side delay tuning to operate
> > correctly.
> >
> > This aligns the driver behavior with the updated device tree binding
> > and provides a safe default configuration when MAC-side delay
> > programming is not required.
> >
> > Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > index 4ac979d874d6..ec99b597aeaf 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > @@ -165,9 +165,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> > dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> > dwc_priv->eth_clk_dly_param |=
> > FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> > - } else {
> > - return dev_err_probe(&pdev->dev, -EINVAL,
> > - "missing required property rx-internal-delay-ps\n");
> > }
> >
> > /* Read tx-internal-delay-ps and update tx_clk delay */
> > @@ -187,9 +184,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> > dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> > dwc_priv->eth_clk_dly_param |=
> > FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> > - } else {
> > - return dev_err_probe(&pdev->dev, -EINVAL,
> > - "missing required property tx-internal-delay-ps\n");
> > }
>
> I think then you need to handle RGMII, RGMII_ID, RGMII_RXID and RGMII_TXID,
> by using default delays for these (usually around 2ns), as here all delays
> will be set to 0, regardless of the RGMII mode in use.
No. By default, the MAC adds 0ns delay, and passes the phy-mode to the
PHY. It will then add the 2ns delay. It is possible to use the
tx-internal-delay-ps and rx-internal-delay-ps in the MAC to add small
tuning delays, but not the full 2ns.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
Andrew
^ permalink raw reply
* Re: [PATCH] dmaengine: sun6i-dma: Fix use-after-free in error handling paths
From: Jernej Škrabec @ 2026-06-13 7:46 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, samuel, mripard, arnd, Hongling Zeng
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng
In-Reply-To: <20260611063631.96566-1-zenghongling@kylinos.cn>
Dne četrtek, 11. junij 2026 ob 08:36:31 Srednjeevropski poletni čas je Hongling Zeng napisal(a):
> In error handling paths, the for loop frees v_lli in the loop body,
> then accesses v_lli->v_lli_next and v_lli->p_lli_next in the
> increment expression, which is use-after-free.
>
> Fix by saving both the next virtual and physical pointers before
> freeing the current node.
>
> Fixes: 555859308723 ("dmaengine: Add driver for Allwinner sun6i DMA")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---
> drivers/dma/sun6i-dma.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a9a254dbf8cb..eb9c4ae87ac8 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -788,9 +788,15 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> + p_lli = txd->p_lli;
> + v_lli = txd->v_lli;
> + while (v_lli) {
> + struct sun6i_dma_lli *next_v_lli = v_lli->v_lli_next;
> + dma_addr_t next_p_lli = v_lli->p_lli_next;
> dma_pool_free(sdev->pool, v_lli, p_lli);
> + v_lli = next_v_lli;
> + p_lli = next_p_lli;
> + }
> kfree(txd);
> return NULL;
> }
> @@ -869,9 +875,15 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> + p_lli = txd->p_lli;
> + v_lli = txd->v_lli;
> + while (v_lli) {
> + struct sun6i_dma_lli *next_v_lli = v_lli->v_lli_next;
> + dma_addr_t next_p_lli = v_lli->p_lli_next;
> dma_pool_free(sdev->pool, v_lli, p_lli);
> + v_lli = next_v_lli;
> + p_lli = next_p_lli;
> + }
> kfree(txd);
> return NULL;
> }
>
This is certainly a valid fix, but it's replicating what sun6i_dma_free_desc()
is already doing. It would be better to split code to accept struct sun6i_desc
*txd parameter and call that instead from all places.
Best regards,
Jernej
^ permalink raw reply
* Re: [RFC PATCH v4 8/9] arm64: dts: rockchip: rk3568-rock-3b: Enable the NPU
From: Jonas Karlman @ 2026-06-13 7:40 UTC (permalink / raw)
To: MidG971
Cc: tomeu@tomeuvizoso.net, ogabbay@kernel.org, heiko@sntech.de,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
ulf.hansson@linaro.org, dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
xxm@rock-chips.com, chaoyi.chen@rock-chips.com,
finley.xiao@rock-chips.com, diederik@cknow-tech.com
In-Reply-To: <20260613070116.438906-9-midgy971@gmail.com>
Hi Midgy,
On 6/13/2026 9:01 AM, MidG971 wrote:
> From: Midgy BALON <midgy971@gmail.com>
>
> Enable the NPU and its IOMMU on ROCK 3B and wire vdd_npu as the NPU
> power domain's domain-supply, so genpd brings the rail up and down with
> the domain (the domain is marked need_regulator). The PVTPLL compute
> clock is brought up later by the driver.
>
> The rail is no longer kept always-on, so pin it to 1000 mV (the NPU's
> 1 GHz operating voltage; the driver runs a fixed compute rate with no
> devfreq voltage scaling) and mark it boot-on, so it is up before the
> power domain de-idles the NPU NoC at power-on.
>
> Signed-off-by: Midgy BALON <midgy971@gmail.com>
> ---
> .../arm64/boot/dts/rockchip/rk3568-rock-3b.dts | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> index 69001e453732e..d3f9776c2bdc3 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> @@ -330,9 +330,10 @@ regulator-state-mem {
>
> vdd_npu: DCDC_REG4 {
> regulator-name = "vdd_npu";
> + regulator-boot-on;
There is no need for the NPU in the bootloader, do not use DT as a
workaround for software issues.
This series mention the PVTPLL NPU clk and seem to contains some
workarounds related to how the PVTPLL clock is handled in TF-A.
The PVTPLL block typically require the pclk and power domain enabled to
function, and this series seem to add workarounds to try and ensure this,
e.g. with noc_init to activate PVTPLL usage.
I would suggest that you do not involve the PVTPLL clock in this initial
NPU support for RK3568, set CLK_NPU to 400 MHz and use it instead of the
SCMI clock, or keep SCMI clk rate less than or equal to 400 MHz to
disable PVTPLL_NEED mode in TF-A.
In a future series you can extend Linux with a proper PVTPLL clk driver
and OPP support for the rocket driver to correctly ensure pclk and pd is
enabled when a PVTPLL clock is managed.
> regulator-initial-mode = <0x2>;
> - regulator-min-microvolt = <500000>;
> - regulator-max-microvolt = <1350000>;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
Please describe the HW, do not add workarounds for software issues or
shortcomings.
Regards,
Jonas
> regulator-ramp-delay = <6001>;
>
> regulator-state-mem {
> @@ -787,3 +788,16 @@ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
> remote-endpoint = <&hdmi_in_vp0>;
> };
> };
> +
> +&pd_npu {
> + domain-supply = <&vdd_npu>;
> +};
> +
> +&rknn_core_0 {
> + npu-supply = <&vdd_npu>;
> + status = "okay";
> +};
> +
> +&rknn_mmu_0 {
> + status = "okay";
> +};
^ permalink raw reply
* Re: [PATCH v3 0/2] dt-bindings: mmc: st,sdhci: convert STMicroelectronics SDHCI-ST MMC/SD Controller controller binding to YAML
From: Charan Pedumuru @ 2026-06-13 7:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard, linux-mmc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <CAPx+jO9woUB9VGUx+ebWD9oOhqCwzXL9=41MEesnWS15Nyr66g@mail.gmail.com>
On 29-05-2026 17:40, Ulf Hansson wrote:
> On Fri, May 8, 2026 at 7:23 PM Charan Pedumuru
> <charan.pedumuru@gmail.com> wrote:
>>
>> This patch series converts the legacy text-based Device Tree binding for
>> STMicroelectronics SDHCI-ST MMC/SD controller to DT schema (YAML) format.
>>
>> Note:
>> The patch "dt-bindings: mmc: st,sdhci: convert to DT schema"
>> depends on the patch "arm: dts: st: align node patterns with established
>> convention". If the DT schema patch is applied before the DTS
>> cleanup patch, `dtbs_check` will fail due to the presence of the removed
>> properties in the existing DTS.
>>
>> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
>
> The series looks good to me, but awaiting and ack from some of the dt
> maintainers before applying.
Yeah, but until now they is no response from anyone.
>
> As the change in patch2 for arch/arm/boot/dts/st/stih407-family.dtsi
> doesn't seem to cause any conflict from soc maintainer trees point of
> view, I can pick this up too when applying.
Sure.
>
> Kind regards
> Uffe
>
>
>> ---
>> Changes in v3:
>> - st,sdhci: Edit description of reg property. Modify reg-names. Add
>> "minItems" for clocks and clock-names properties.
>> - Modify the commit message to match with the updated changes.
>> - Link to v2: https://patch.msgid.link/20260503-st-mmc-v2-0-11ae3216d2ce@gmail.com
>>
>> Changes in v2:
>> - Fix node name in DTS for the MMC to match with the estableshed convention.
>> - st,sdhci: drop unnecessary properties, modify "reg", "reg-names" and
>> "clock-names" properties, include an allOf with $ref to mmc-controller.
>> - Link to v1: https://patch.msgid.link/20260409-st-mmc-v1-1-4c54321c3535@gmail.com
>>
>> ---
>> Charan Pedumuru (2):
>> arm: dts: st: align node patterns with established convention
>> dt-bindings: mmc: st,sdhci: convert to DT schema
>>
>> Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
>> .../devicetree/bindings/mmc/st,sdhci.yaml | 91 +++++++++++++++++
>> arch/arm/boot/dts/st/stih407-family.dtsi | 4 +-
>> 3 files changed, 93 insertions(+), 112 deletions(-)
>> ---
>> base-commit: cf2cd8efd046c561191b8541d32a8bfe845bf06b
>> change-id: 20260327-st-mmc-c906ad95ff83
>>
>> Best regards,
>> --
>> Charan Pedumuru <charan.pedumuru@gmail.com>
--
Best Regards,
Charan.
^ 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