* Re: [PATCH net 1/2] net: airoha: Fix use-after-free in metadata dst teardown
From: Lorenzo Bianconi @ 2026-06-04 21:23 UTC (permalink / raw)
To: Jacob Keller
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno, Florian Westphal, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <21810a20-abe6-4490-969c-cfd62c4c082a@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]
> On 6/2/2026 2:21 AM, Lorenzo Bianconi wrote:
> > airoha_metadata_dst_free() runs metadata_dst_free() which frees the
> > metadata_dst with kfree() immediately, bypassing the RCU grace period.
> > In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
> > the skb to the metadata_dst. This function requires RCU read-side
> > protection and the dst must remain valid until all RCU readers complete.
> > Since metadata_dst_free() calls kfree() directly, an use-after-free can
> > occur if any skb still holds a noref pointer to the dst when the driver
> > tears it down.
> > Replace metadata_dst_free() with dst_release() which properly goes
> > through the refcount path: when the refcount drops to zero, it schedules
> > the actual free via call_rcu_hurry(), ensuring all RCU readers have
> > completed before the memory is freed.
> >
> > Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor")
> > Signed-off-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 cecd66251dba..eab6a98d62b9 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> > @@ -2936,7 +2936,7 @@ static void airoha_metadata_dst_free(struct airoha_gdm_port *port)
> > if (!port->dsa_meta[i])
> > continue;
> >
> > - metadata_dst_free(port->dsa_meta[i]);
> > + dst_release(&port->dsa_meta[i]->dst);
> > }
> > }
> >
> >
>
> the port->dsa_meta is allocated using metadata_dst_alloc().. how is it
> safe to use dst_release here? Seems like we should be calling dst_alloc
> instead of metadata_dst_alloc in order to use dst_release??
We need to allocate the metadata_dst using metadata_dst_alloc() since
md_dst->u.port_info.port_id is consumed in dsa_switch_rcv() to get the
switch conduit port.
I guess it is fine to free metadata_dst running dst_release() since dst_init()
sets DST_METADATA flag and so dst_destroy() runs metadata_dst_free() after the
RCU grace period.
>
> metadata_dst_alloc does call __metadata_dst_init which calls dst_init..
>
> I guess the start of the metadata_dst structure is also the same address
> as the internal dst_entry struct...
>
> But dst_destroy does a whole lot more than metadata_dst_release so I
> don't feel confident in this actually being a drop-in replacement... It
> calls netdev_put, it calls the dst->ops->destroy, it releases child
> refs.. Or for metadata dst entries is that all basically a no-op??
__metadata_dst_init() calls dst_init() with dev = NULL so netdev_put() is a
no-op. Same for dst->ops is dst_blackhole_ops and and dst_blackhole_ops has no
destroy callback.
>
> I feel like I'm missing something here.. The driver also calls
> metadata_dst_free in the remove path and that wasn't changed by this
> patch either.
can you please explain what you mean here? we do not run metadata_dst_free()
anymore.
Regards,
Lorenzo
>
> Generally it seems like we should be using the same API to allocate as
> to release the object... This is confusing. What am I missing?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] regulator: dt-bindings: mt6311: Convert to DT schema
From: Rob Herring (Arm) @ 2026-06-04 20:57 UTC (permalink / raw)
To: Ninad Naik
Cc: broonie, devicetree, linux-arm-kernel, conor+dt, krzk+dt,
matthias.bgg, angelogioacchino.delregno, me, linux-kernel-mentees,
skhan, linux-mediatek, lgirdwood, linux-kernel
In-Reply-To: <20260604162624.644241-1-ninadnaik07@gmail.com>
On Thu, 04 Jun 2026 21:56:24 +0530, Ninad Naik wrote:
> Convert mediatek,mt6311 to DT schema.
>
> Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
> ---
> Changes in v2:
> - Correct "MediaTek" in the title.
> - Drop "|" in the top-level description.
> - Remove unnecessary regulator node description.
> - Remove unused labels from example.
>
> .../regulator/mediatek,mt6311-regulator.yaml | 70 +++++++++++++++++++
> .../bindings/regulator/mt6311-regulator.txt | 35 ----------
> 2 files changed, 70 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> delete mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net 1/2] net: airoha: Fix use-after-free in metadata dst teardown
From: Jacob Keller @ 2026-06-04 17:38 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Florian Westphal, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org>
On 6/2/2026 2:21 AM, Lorenzo Bianconi wrote:
> airoha_metadata_dst_free() runs metadata_dst_free() which frees the
> metadata_dst with kfree() immediately, bypassing the RCU grace period.
> In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
> the skb to the metadata_dst. This function requires RCU read-side
> protection and the dst must remain valid until all RCU readers complete.
> Since metadata_dst_free() calls kfree() directly, an use-after-free can
> occur if any skb still holds a noref pointer to the dst when the driver
> tears it down.
> Replace metadata_dst_free() with dst_release() which properly goes
> through the refcount path: when the refcount drops to zero, it schedules
> the actual free via call_rcu_hurry(), ensuring all RCU readers have
> completed before the memory is freed.
>
> Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor")
> Signed-off-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 cecd66251dba..eab6a98d62b9 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2936,7 +2936,7 @@ static void airoha_metadata_dst_free(struct airoha_gdm_port *port)
> if (!port->dsa_meta[i])
> continue;
>
> - metadata_dst_free(port->dsa_meta[i]);
> + dst_release(&port->dsa_meta[i]->dst);
> }
> }
>
>
the port->dsa_meta is allocated using metadata_dst_alloc().. how is it
safe to use dst_release here? Seems like we should be calling dst_alloc
instead of metadata_dst_alloc in order to use dst_release??
metadata_dst_alloc does call __metadata_dst_init which calls dst_init..
I guess the start of the metadata_dst structure is also the same address
as the internal dst_entry struct...
But dst_destroy does a whole lot more than metadata_dst_release so I
don't feel confident in this actually being a drop-in replacement... It
calls netdev_put, it calls the dst->ops->destroy, it releases child
refs.. Or for metadata dst entries is that all basically a no-op??
I feel like I'm missing something here.. The driver also calls
metadata_dst_free in the remove path and that wasn't changed by this
patch either.
Generally it seems like we should be using the same API to allocate as
to release the object... This is confusing. What am I missing?
^ permalink raw reply
* [PATCH v2] regulator: dt-bindings: mt6311: Convert to DT schema
From: Ninad Naik @ 2026-06-04 16:26 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, me,
linux-kernel-mentees, skhan, Ninad Naik
Convert mediatek,mt6311 to DT schema.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Changes in v2:
- Correct "MediaTek" in the title.
- Drop "|" in the top-level description.
- Remove unnecessary regulator node description.
- Remove unused labels from example.
.../regulator/mediatek,mt6311-regulator.yaml | 70 +++++++++++++++++++
.../bindings/regulator/mt6311-regulator.txt | 35 ----------
2 files changed, 70 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
new file mode 100644
index 000000000000..f65ee2c90298
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6311-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6311 Regulator
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek MT6311 is an I2C power management IC that provides one step-down
+ converter and one low-dropout regulator. The regulators are named VDVFS and
+ VBIASN, respectively.
+
+properties:
+ compatible:
+ const: mediatek,mt6311-regulator
+
+ reg:
+ description: I2C slave address.
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: List of regulators provided by this controller.
+
+ patternProperties:
+ "^(VDVFS|VBIASN)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@6b {
+ compatible = "mediatek,mt6311-regulator";
+ reg = <0x6b>;
+
+ regulators {
+ VDVFS {
+ regulator-name = "VDVFS";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-ramp-delay = <10000>;
+ };
+
+ VBIASN {
+ regulator-name = "VBIASN";
+ regulator-min-microvolt = <200000>;
+ regulator-max-microvolt = <800000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
deleted file mode 100644
index 84d544d8c1b1..000000000000
--- a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Mediatek MT6311 Regulator
-
-Required properties:
-- compatible: "mediatek,mt6311-regulator"
-- reg: I2C slave address, usually 0x6b.
-- regulators: List of regulators provided by this controller. It is named
- to VDVFS and VBIASN.
- The definition for each of these nodes is defined using the standard binding
- for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
-
-The valid names for regulators are:
-BUCK:
- VDVFS
-LDO:
- VBIASN
-
-Example:
- mt6311: pmic@6b {
- compatible = "mediatek,mt6311-regulator";
- reg = <0x6b>;
-
- regulators {
- mt6311_vcpu_reg: VDVFS {
- regulator-name = "VDVFS";
- regulator-min-microvolt = < 600000>;
- regulator-max-microvolt = <1400000>;
- regulator-ramp-delay = <10000>;
- };
- mt6311_ldo_reg: VBIASN {
- regulator-name = "VBIASN";
- regulator-min-microvolt = <200000>;
- regulator-max-microvolt = <800000>;
- };
- };
- };
--
2.54.0
^ permalink raw reply related
* [PATCH v1] ufs: core: Remove unnecessary block I/O quiesce for clock scaling
From: peter.wang @ 2026-06-04 13:33 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: wsd_upstream, linux-mediatek, peter.wang, chun-hung.wu,
alice.chao, cc.chou, chaotian.jing, tun-yu.yu, eddie.huang,
naomi.chu, ed.tsai, bvanassche
From: Peter Wang <peter.wang@mediatek.com>
According to the MIPI UniPro Specification v2.0:
5.3.2.3 PA_DL_PAUSE.ind
This primitive informs the PA Service User, the DL Layer in
this case, that the PA Layer was requested to execute a
operation that requires the usage of the Link, e.g. Power
Mode change or PACP frame transmission.
5.3.2.4 PA_DL_PAUSE.rsp_L
This primitive informs the Service Provider that the PA
Service User, the DL Layer in this case, has reached
a state where the Link may be used by the PA Layer.
5.3.2.5 PA_DL_RESUME.ind
This primitive informs the PA Service User, the DL Layer
in this case, that the PA Layer has completed its operation
and the DL Layer may continue to use the Link.
The detailed flow can be found in Figure 52:
Power Mode Change Using PACP_PWR_req and PACP_PWR_cnf.
In short, when the PA layer do power mode change:
1. The DL layer receives PA_DL_PAUSE.ind.
2. The DL layer stops and responds to the PA layer with PA_DL_PAUSE.rsp_L.
3. Waits until the PA layer has completed its work.
4. The PA layer then informs the DL layer with PA_DL_RESUME.ind.
Hence, it is not necessary to stop I/O during a power mode change,
and this step can be removed.
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
---
drivers/ufs/core/ufshcd.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index c3f08957d179..b979f5105eb5 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1468,7 +1468,7 @@ static int ufshcd_scale_gear(struct ufs_hba *hba, u32 target_gear, bool scale_up
*
* Return: 0 upon success; -EBUSY upon timeout.
*/
-static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba, u64 timeout_us)
+static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba)
{
int ret = 0;
/*
@@ -1476,16 +1476,13 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba, u64 timeout_us)
* clock scaling is in progress
*/
mutex_lock(&hba->host->scan_mutex);
- blk_mq_quiesce_tagset(&hba->host->tag_set);
mutex_lock(&hba->wb_mutex);
down_write(&hba->clk_scaling_lock);
- if (!hba->clk_scaling.is_allowed ||
- ufshcd_wait_for_pending_cmds(hba, timeout_us)) {
+ if (!hba->clk_scaling.is_allowed) {
ret = -EBUSY;
up_write(&hba->clk_scaling_lock);
mutex_unlock(&hba->wb_mutex);
- blk_mq_unquiesce_tagset(&hba->host->tag_set);
mutex_unlock(&hba->host->scan_mutex);
goto out;
}
@@ -1501,7 +1498,6 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, int err)
{
up_write(&hba->clk_scaling_lock);
mutex_unlock(&hba->wb_mutex);
- blk_mq_unquiesce_tagset(&hba->host->tag_set);
mutex_unlock(&hba->host->scan_mutex);
/* Enable Write Booster if current gear requires it else disable it */
@@ -1529,7 +1525,7 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba, unsigned long freq,
new_gear = ufshcd_vops_freq_to_gear_speed(hba, freq);
- ret = ufshcd_clock_scaling_prepare(hba, 1 * USEC_PER_SEC);
+ ret = ufshcd_clock_scaling_prepare(hba);
if (ret)
return ret;
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()
From: Lorenzo Bianconi @ 2026-06-04 10:18 UTC (permalink / raw)
To: ZhaoJinming
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev, linux-kernel, stable
In-Reply-To: <20260604070352.2603077-1-zhaojinming@uniontech.com>
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
> of_reserved_mem_lookup() may return NULL if the reserved memory region
> referenced by the "memory-region" phandle is not found in the reserved
> memory table (e.g. due to a misconfigured DTS or a removed
> memory-region node). The current code dereferences the returned
> pointer without checking for NULL, leading to a kernel NULL pointer
> dereference at the following lines:
>
> dma_addr = rmem->base; // line 1156
> num_desc = div_u64(rmem->size, buf_size); // line 1160
>
> Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if
> the lookup fails, which is consistent with the existing error handling
> for of_parse_phandle() failure in the same code block.
>
> Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory")
> Cc: stable@vger.kernel.org
> Signed-off-by: ZhaoJinming<zhaojinming@uniontech.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index cecd66251dba..2444d3275a81 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1153,6 +1153,9 @@ static int airoha_qdma_init_hfwd_queues(struct airoha_qdma *qdma)
>
> rmem = of_reserved_mem_lookup(np);
> of_node_put(np);
> + if (!rmem)
> + return -ENODEV;
> +
> dma_addr = rmem->base;
> /* Compute the number of hw descriptors according to the
> * reserved memory size and the payload buffer size
> --
> 2.25.1
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v9 6/6] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
From: Lorenzo Bianconi @ 2026-06-04 9:20 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Madhur Agrawal
In-Reply-To: <20260603-airoha-eth-multi-serdes-v9-6-5d476bc2f426@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 7479 bytes --]
On Jun 03, Lorenzo Bianconi wrote:
> The EN7581 and AN7583 SoCs provide registers to configure hardware LAN/WAN
> MAC addresses. These registers are used during FE hw acceleration to
> determine whether received traffic is destined to this host (L3 traffic)
> or should be switched to another device (L2 traffic).
> The SoC hardware design assumes all interfaces configured as LAN (or WAN)
> share the MAC address MSBs, which are programmed into the
> REG_FE_{LAN,WAN}_MAC_H register. The LSBs of 'local' mac addresses can be
> expressed as a range via the REG_FE_MAC_LMIN and REG_FE_MAC_LMAX
> registers. In order to properly accelerate the traffic, FE module requires
> the user to configure the REG_FE_{LAN,WAN}_MAC_H register respecting this
> limitation. Please note a misconfiguration in REG_FE_{LAN,WAN}_MAC_H
> will still allow the user to log into the device for debugging.
> Previously, only a single interface was considered when programming these
> registers. Extend the logic to derive the correct minimum and maximum
> values for REG_FE_MAC_LMIN/REG_FE_MAC_LMAX when two or more interfaces are
> configured as LAN or WAN. Since this functionality was not available
> before this series, no regression is introduced.
Commenting on sashiko's report:
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260603-airoha-eth-multi-serdes-v9-0-5d476bc2f426%40kernel.org
- How does this validation interact with the init path?
In airoha_alloc_gdm_device(), interfaces lacking a DT MAC fall back to
eth_hw_addr_random(), and airoha_dev_init() calls airoha_set_macaddr()
but discards the int return, so a netdev whose initial MAC would fail
the new MSB check still proceeds to register and reaches NETREG_REGISTERED.
- This is done on purpose to not block the device probe and allow the user
to log into the system, and based on the syslog, fix the issue manually.
Regards,
Lorenzo
>
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 77 ++++++++++++++++++++++++++++----
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
> drivers/net/ethernet/airoha/airoha_ppe.c | 4 +-
> 3 files changed, 71 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 64ee526da241..8f2608293bb7 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -71,20 +71,76 @@ static void airoha_qdma_irq_disable(struct airoha_irq_bank *irq_bank,
> airoha_qdma_set_irqmask(irq_bank, index, mask, 0);
> }
>
> -static void airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
> +static int airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
> {
> + u8 ref_addr[ETH_ALEN] __aligned(2);
> struct airoha_eth *eth = dev->eth;
> - u32 val, reg;
> + u32 reg, val, lmin, lmax;
> + int i;
> +
> + eth_zero_addr(ref_addr);
> + lmin = (addr[3] << 16) | (addr[4] << 8) | addr[5];
> + lmax = lmin;
> +
> + for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> + struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
> +
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + struct airoha_gdm_dev *iter_dev;
> + struct net_device *netdev;
> +
> + iter_dev = port->devs[j];
> + if (!iter_dev || iter_dev == dev)
> + continue;
> +
> + if (airoha_is_lan_gdm_dev(iter_dev) !=
> + airoha_is_lan_gdm_dev(dev))
> + continue;
> +
> + netdev = netdev_from_priv(iter_dev);
> + if (netdev->reg_state != NETREG_REGISTERED)
> + continue;
> +
> + ether_addr_copy(ref_addr, netdev->dev_addr);
> + val = (netdev->dev_addr[3] << 16) |
> + (netdev->dev_addr[4] << 8) | netdev->dev_addr[5];
> + if (val < lmin)
> + lmin = val;
> + if (val > lmax)
> + lmax = val;
> + }
> + }
> +
> + if (!is_zero_ether_addr(ref_addr) && memcmp(ref_addr, addr, 3)) {
> + /* According to the HW design, hw mac address MSBs must be
> + * the same for each net_device with the same LAN/WAN
> + * configuration.
> + */
> + struct net_device *netdev = netdev_from_priv(dev);
> +
> + dev_warn(eth->dev,
> + "%s: wrong mac addr, MSBs must be %02x:%02x:%02x\n",
> + netdev->name, ref_addr[0], ref_addr[1],
> + ref_addr[2]);
> + dev_warn(eth->dev, "FE hw forwarding won't work properly\n");
> +
> + return -EINVAL;
> + }
>
> reg = airoha_is_lan_gdm_dev(dev) ? REG_FE_LAN_MAC_H : REG_FE_WAN_MAC_H;
> val = (addr[0] << 16) | (addr[1] << 8) | addr[2];
> airoha_fe_wr(eth, reg, val);
>
> - val = (addr[3] << 16) | (addr[4] << 8) | addr[5];
> - airoha_fe_wr(eth, REG_FE_MAC_LMIN(reg), val);
> - airoha_fe_wr(eth, REG_FE_MAC_LMAX(reg), val);
> + airoha_fe_wr(eth, REG_FE_MAC_LMIN(reg), lmin);
> + airoha_fe_wr(eth, REG_FE_MAC_LMAX(reg), lmax);
>
> - airoha_ppe_init_upd_mem(dev);
> + airoha_ppe_init_upd_mem(dev, addr);
> +
> + return 0;
> }
>
> static void airoha_set_gdm_port_fwd_cfg(struct airoha_eth *eth, u32 addr,
> @@ -1826,13 +1882,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> static int airoha_dev_set_macaddr(struct net_device *netdev, void *p)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + struct sockaddr *addr = p;
> int err;
>
> - err = eth_mac_addr(netdev, p);
> + err = eth_prepare_mac_addr_change(netdev, p);
> if (err)
> return err;
>
> - airoha_set_macaddr(dev, netdev->dev_addr);
> + err = airoha_set_macaddr(dev, addr->sa_data);
> + if (err)
> + return err;
> +
> + eth_commit_mac_addr_change(netdev, p);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 3e8262f583a7..8f42973f9cf5 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -683,7 +683,7 @@ void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> int airoha_ppe_setup_tc_block_cb(struct airoha_ppe_dev *dev, void *type_data);
> int airoha_ppe_init(struct airoha_eth *eth);
> void airoha_ppe_deinit(struct airoha_eth *eth);
> -void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev);
> +void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev, const u8 *addr);
> u32 airoha_ppe_get_total_num_entries(struct airoha_ppe *ppe);
> struct airoha_foe_entry *airoha_ppe_foe_get_entry(struct airoha_ppe *ppe,
> u32 hash);
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index f54622904733..91bcc55a6ac6 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -1487,12 +1487,10 @@ void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> airoha_ppe_foe_insert_entry(ppe, skb, hash, rx_wlan);
> }
>
> -void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev)
> +void airoha_ppe_init_upd_mem(struct airoha_gdm_dev *dev, const u8 *addr)
> {
> - struct net_device *netdev = netdev_from_priv(dev);
> struct airoha_gdm_port *port = dev->port;
> struct airoha_eth *eth = dev->eth;
> - const u8 *addr = netdev->dev_addr;
> u32 val;
>
> val = (addr[2] << 24) | (addr[3] << 16) | (addr[4] << 8) | addr[5];
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v9 3/6] net: airoha: Support multiple net_devices for a single FE GDM port
From: Lorenzo Bianconi @ 2026-06-04 8:41 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260603-airoha-eth-multi-serdes-v9-3-5d476bc2f426@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 22410 bytes --]
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
>
> ┌─────────────────────────────────┐
> │ │ ┌──────┐
> │ P1 GDM1 ├────►MT7530│
> │ │ └──────┘
> │ │ ETH0 (DSA conduit)
> │ │
> │ PSE/FE │
> │ │
> │ │
> │ │ ┌─────┐
> │ P0 CDM1 ├────►QDMA0│
> │ P4 P9 GDM4 │ └─────┘
> └──┬─────────────────────────┬────┘
> │ │
> ┌──▼──┐ ┌────▼────┐
> │ PPE │ │ ARB │
> └─────┘ └─┬─────┬─┘
> │ │
> ┌──▼──┐┌─▼───┐
> │ ETH ││ USB │
> └─────┘└─────┘
> ETH1 ETH2
>
> Introduce support for multiple net_devices connected to the same Frame
> Engine (FE) GDM port (GDM3 or GDM4) via an external hw arbiter.
> Please note GDM1 or GDM2 does not support the connection with the external
> arbiter.
> Add get_dev_from_sport callback since EN7581 and AN7583 have different
> logics for the net_device type connected to GDM3 or GDM4.
>
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 280 +++++++++++++++++++++++--------
> drivers/net/ethernet/airoha/airoha_eth.h | 8 +-
> drivers/net/ethernet/airoha/airoha_ppe.c | 26 ++-
> 3 files changed, 237 insertions(+), 77 deletions(-)
commenting on sashiko's report:
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260603-airoha-eth-multi-serdes-v9-0-5d476bc2f426%40kernel.org
- With multiple net_devices now allowed on the same GDM3/GDM4 port,
airoha_dev_init() runs the GDM3/GDM4 branch of the switch for every
device, which calls airoha_enable_gdm2_loopback() once per device.
Inside that function:
src_port = eth->soc->ops.get_sport(port, dev->nbq);
...
airoha_fe_rmw(eth, REG_FE_WAN_PORT,
WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
FIELD_PREP(WAN0_MASK, src_port));
the rmw clears WAN0/WAN1/WAN1_EN and writes only WAN0. When two devices
share a port (for example EN7581 GDM3 with nbq=4 and nbq=5, giving
HSGMII_LAN_7581_PCIE0_SRCPORT and HSGMII_LAN_7581_PCIE1_SRCPORT, or
ETH/USB on GDM4) wouldn't the second invocation overwrite the first
device's src_port in WAN0, leaving the first device's traffic
unrecognized as WAN even though the hardware register has WAN0/WAN1
slots specifically for two ports?
- We can run airoha_enable_gdm2_loopback() just for the single device
configured as WAN. As pointed out by the report, this is enforced by a
following patch in the series.
- Should d++ live below the of_device_is_available() check?
- This is done on purpose to highlight device-tree misconfigurations.
Regards,
Lorenzo
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 57a16de0a2ec..1d088d95d5fb 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -106,7 +106,7 @@ static int airoha_set_vip_for_gdm_port(struct airoha_gdm_dev *dev, bool enable)
> struct airoha_eth *eth = dev->eth;
> u32 vip_port;
>
> - vip_port = eth->soc->ops.get_vip_port(port, port->nbq);
> + vip_port = eth->soc->ops.get_vip_port(port, dev->nbq);
> if (enable) {
> airoha_fe_set(eth, REG_FE_VIP_PORT_EN, vip_port);
> airoha_fe_set(eth, REG_FE_IFC_PORT_EN, vip_port);
> @@ -566,24 +566,26 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
> return nframes;
> }
>
> -static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
> - struct airoha_qdma_desc *desc)
> +static struct airoha_gdm_dev *
> +airoha_qdma_get_gdm_dev(struct airoha_eth *eth, struct airoha_qdma_desc *desc)
> {
> - u32 port, sport, msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
> + struct airoha_gdm_port *port;
> + u16 p, d;
>
> - sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK, msg1);
> - switch (sport) {
> - case 0x10 ... 0x14:
> - port = 0;
> - break;
> - case 0x2 ... 0x4:
> - port = sport - 1;
> - break;
> - default:
> - return -EINVAL;
> - }
> + if (eth->soc->ops.get_dev_from_sport(desc, &p, &d))
> + return ERR_PTR(-ENODEV);
>
> - return port >= ARRAY_SIZE(eth->ports) ? -EINVAL : port;
> + if (p >= ARRAY_SIZE(eth->ports))
> + return ERR_PTR(-ENODEV);
> +
> + port = eth->ports[p];
> + if (!port)
> + return ERR_PTR(-ENODEV);
> +
> + if (d >= ARRAY_SIZE(port->devs))
> + return ERR_PTR(-ENODEV);
> +
> + return port->devs[d] ? port->devs[d] : ERR_PTR(-ENODEV);
> }
>
> static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> @@ -598,9 +600,9 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> struct airoha_queue_entry *e = &q->entry[q->tail];
> struct airoha_qdma_desc *desc = &q->desc[q->tail];
> u32 hash, reason, msg1, desc_ctrl;
> - struct airoha_gdm_port *port;
> + struct airoha_gdm_dev *dev;
> struct net_device *netdev;
> - int data_len, len, p;
> + int data_len, len;
> struct page *page;
>
> desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
> @@ -621,15 +623,11 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> if (!len || data_len < len)
> goto free_frag;
>
> - p = airoha_qdma_get_gdm_port(eth, desc);
> - if (p < 0 || !eth->ports[p])
> + dev = airoha_qdma_get_gdm_dev(eth, desc);
> + if (IS_ERR(dev))
> goto free_frag;
>
> - port = eth->ports[p];
> - if (!port->dev)
> - goto free_frag;
> -
> - netdev = netdev_from_priv(port->dev);
> + netdev = netdev_from_priv(dev);
> if (!q->skb) { /* first buffer */
> q->skb = napi_build_skb(e->buf - AIROHA_RX_HEADROOM,
> q->buf_size);
> @@ -659,6 +657,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> continue;
>
> if (netdev_uses_dsa(netdev)) {
> + struct airoha_gdm_port *port = dev->port;
> +
> /* PPE module requires untagged packets to work
> * properly and it provides DSA port index via the
> * DMA descriptor. Report DSA tag to the DSA stack
> @@ -852,26 +852,29 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> - struct airoha_gdm_dev *dev;
> - struct net_device *netdev;
> - int j;
> + int d;
>
> if (!port)
> continue;
>
> - dev = port->dev;
> - if (!dev)
> - continue;
> + for (d = 0; d < ARRAY_SIZE(port->devs); d++) {
> + struct airoha_gdm_dev *dev = port->devs[d];
> + struct net_device *netdev;
> + int j;
>
> - if (dev->qdma != qdma)
> - continue;
> + if (!dev)
> + continue;
>
> - netdev = netdev_from_priv(dev);
> - for (j = 0; j < netdev->num_tx_queues; j++) {
> - if (airoha_qdma_get_txq(qdma, j) != qid)
> + if (dev->qdma != qdma)
> continue;
>
> - netif_wake_subqueue(netdev, j);
> + netdev = netdev_from_priv(dev);
> + for (j = 0; j < netdev->num_tx_queues; j++) {
> + if (airoha_qdma_get_txq(qdma, j) != qid)
> + continue;
> +
> + netif_wake_subqueue(netdev, j);
> + }
> }
> }
> q->txq_stopped = false;
> @@ -1742,11 +1745,9 @@ static int airoha_dev_open(struct net_device *netdev)
> GLOBAL_CFG_RX_DMA_EN_MASK);
> atomic_inc(&qdma->users);
>
> - if (port->id == AIROHA_GDM2_IDX &&
> - airoha_ppe_is_enabled(qdma->eth, 1)) {
> - /* For PPE2 always use secondary cpu port. */
> + if (!airoha_is_lan_gdm_dev(dev) &&
> + airoha_ppe_is_enabled(qdma->eth, 1))
> pse_port = FE_PSE_PORT_PPE2;
> - }
> airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> pse_port);
>
> @@ -1834,7 +1835,7 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
> airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
>
> - src_port = eth->soc->ops.get_sport(port, port->nbq);
> + src_port = eth->soc->ops.get_sport(port, dev->nbq);
> if (src_port < 0)
> return src_port;
>
> @@ -1851,7 +1852,7 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
> airoha_ppe_set_cpu_port(dev, i, AIROHA_GDM2_IDX);
>
> if (port->id == AIROHA_GDM4_IDX && airoha_is_7581(eth)) {
> - u32 mask = FC_ID_OF_SRC_PORT_MASK(port->nbq);
> + u32 mask = FC_ID_OF_SRC_PORT_MASK(dev->nbq);
>
> airoha_fe_rmw(eth, REG_SRC_PORT_FC_MAP6, mask,
> __field_prep(mask, AIROHA_GDM2_IDX));
> @@ -1865,7 +1866,7 @@ static int airoha_dev_init(struct net_device *netdev)
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> struct airoha_eth *eth = dev->eth;
> - int i;
> + 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)];
> @@ -1888,8 +1889,8 @@ static int airoha_dev_init(struct net_device *netdev)
> break;
> }
>
> - for (i = 0; i < eth->soc->num_ppe; i++)
> - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
> + 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));
>
> return 0;
> }
> @@ -2055,7 +2056,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> }
>
> fport = airoha_get_fe_port(dev);
> - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
>
> q = &qdma->q_tx[qid];
> @@ -2985,12 +2987,15 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> + int j;
>
> if (!port)
> continue;
>
> - if (port->dev == dev)
> - return true;
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + if (port->devs[j] == dev)
> + return true;
> + }
> }
>
> return false;
> @@ -2998,10 +3003,11 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
>
> static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> struct airoha_gdm_port *port,
> - struct device_node *np)
> + int nbq, struct device_node *np)
> {
> - struct airoha_gdm_dev *dev;
> struct net_device *netdev;
> + struct airoha_gdm_dev *dev;
> + u8 index;
> int err;
>
> netdev = devm_alloc_etherdev_mqs(eth->dev, sizeof(*dev),
> @@ -3021,7 +3027,6 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> NETIF_F_HW_TC;
> netdev->features |= netdev->hw_features;
> netdev->vlan_features = netdev->hw_features;
> - netdev->dev.of_node = np;
> SET_NETDEV_DEV(netdev, eth->dev);
>
> /* reserve hw queues for HTB offloading */
> @@ -3039,10 +3044,24 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> netdev->dev_addr);
> }
>
> + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> + * and PCIE1 respectively.
> + */
> + index = nbq;
> + if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> + index -= 4;
> +
> + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> + return -EINVAL;
> + }
> +
> + netdev->dev.of_node = of_node_get(np);
> dev = netdev_priv(netdev);
> dev->port = port;
> - port->dev = dev;
> dev->eth = eth;
> + dev->nbq = nbq;
> + port->devs[index] = dev;
>
> return 0;
> }
> @@ -3052,7 +3071,8 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> {
> const __be32 *id_ptr = of_get_property(np, "reg", NULL);
> struct airoha_gdm_port *port;
> - int err, p;
> + struct device_node *node;
> + int err, nbq, p, d = 0;
> u32 id;
>
> if (!id_ptr) {
> @@ -3080,15 +3100,51 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> u64_stats_init(&port->stats.syncp);
> spin_lock_init(&port->stats.lock);
> port->id = id;
> - /* XXX: Read nbq from DTS */
> - port->nbq = id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> eth->ports[p] = port;
>
> err = airoha_metadata_dst_alloc(port);
> if (err)
> return err;
>
> - return airoha_alloc_gdm_device(eth, port, np);
> + /* Default nbq value to ensure backward compatibility */
> + nbq = id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> +
> + for_each_child_of_node(np, node) {
> + /* Multiple external serdes connected to the FE GDM port via an
> + * external arbiter.
> + */
> + const __be32 *nbq_ptr;
> +
> + if (!of_device_is_compatible(node, "airoha,eth-port"))
> + continue;
> +
> + d++;
> + if (!of_device_is_available(node))
> + continue;
> +
> + nbq_ptr = of_get_property(node, "reg", NULL);
> + if (!nbq_ptr) {
> + dev_err(eth->dev, "missing nbq id\n");
> + of_node_put(node);
> + return -EINVAL;
> + }
> +
> + /* Verify the provided nbq parameter is valid */
> + nbq = be32_to_cpup(nbq_ptr);
> + err = eth->soc->ops.get_sport(port, nbq);
> + if (err < 0) {
> + of_node_put(node);
> + return err;
> + }
> +
> + err = airoha_alloc_gdm_device(eth, port, nbq, node);
> + if (err) {
> + of_node_put(node);
> + return err;
> + }
> + }
> +
> + return !d ? airoha_alloc_gdm_device(eth, port, nbq, np) : 0;
> }
>
> static int airoha_register_gdm_devices(struct airoha_eth *eth)
> @@ -3097,14 +3153,22 @@ static int airoha_register_gdm_devices(struct airoha_eth *eth)
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> - int err;
> + int j;
>
> if (!port)
> continue;
>
> - err = register_netdev(netdev_from_priv(port->dev));
> - if (err)
> - return err;
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + struct airoha_gdm_dev *dev = port->devs[j];
> + int err;
> +
> + if (!dev)
> + continue;
> +
> + err = register_netdev(netdev_from_priv(dev));
> + if (err)
> + return err;
> + }
> }
>
> set_bit(DEV_STATE_REGISTERED, ð->state);
> @@ -3211,17 +3275,22 @@ static int airoha_probe(struct platform_device *pdev)
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> - struct airoha_gdm_dev *dev;
> + int j;
>
> if (!port)
> continue;
>
> - dev = port->dev;
> - if (dev) {
> - struct net_device *netdev = netdev_from_priv(dev);
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + struct airoha_gdm_dev *dev = port->devs[j];
> + struct net_device *netdev;
> +
> + if (!dev)
> + continue;
>
> + netdev = netdev_from_priv(dev);
> if (netdev->reg_state == NETREG_REGISTERED)
> unregister_netdev(netdev);
> + of_node_put(netdev->dev.of_node);
> }
> airoha_metadata_dst_free(port);
> }
> @@ -3243,14 +3312,22 @@ static void airoha_remove(struct platform_device *pdev)
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> - struct airoha_gdm_dev *dev;
> + int j;
>
> if (!port)
> continue;
>
> - dev = port->dev;
> - if (dev)
> - unregister_netdev(netdev_from_priv(dev));
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + struct airoha_gdm_dev *dev = port->devs[j];
> + struct net_device *netdev;
> +
> + if (!dev)
> + continue;
> +
> + netdev = netdev_from_priv(dev);
> + unregister_netdev(netdev);
> + of_node_put(netdev->dev.of_node);
> + }
> airoha_metadata_dst_free(port);
> }
> airoha_hw_cleanup(eth);
> @@ -3313,6 +3390,39 @@ static u32 airoha_en7581_get_vip_port(struct airoha_gdm_port *port, int nbq)
> return 0;
> }
>
> +static int airoha_en7581_get_dev_from_sport(struct airoha_qdma_desc *desc,
> + u16 *port, u16 *dev)
> +{
> + u32 sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK,
> + le32_to_cpu(READ_ONCE(desc->msg1)));
> +
> + *dev = 0;
> + switch (sport) {
> + case 0x10 ... 0x14:
> + *port = 0; /* GDM1 */
> + break;
> + case 0x2 ... 0x4:
> + *port = sport - 1;
> + break;
> + case HSGMII_LAN_7581_PCIE1_SRCPORT:
> + *dev = 1;
> + fallthrough;
> + case HSGMII_LAN_7581_PCIE0_SRCPORT:
> + *port = 2; /* GDM3 */
> + break;
> + case HSGMII_LAN_7581_USB_SRCPORT:
> + *dev = 1;
> + fallthrough;
> + case HSGMII_LAN_7581_ETH_SRCPORT:
> + *port = 3; /* GDM4 */
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static const char * const an7583_xsi_rsts_names[] = {
> "xsi-mac",
> "hsi0-mac",
> @@ -3362,6 +3472,36 @@ static u32 airoha_an7583_get_vip_port(struct airoha_gdm_port *port, int nbq)
> return 0;
> }
>
> +static int airoha_an7583_get_dev_from_sport(struct airoha_qdma_desc *desc,
> + u16 *port, u16 *dev)
> +{
> + u32 sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK,
> + le32_to_cpu(READ_ONCE(desc->msg1)));
> +
> + *dev = 0;
> + switch (sport) {
> + case 0x10 ... 0x14:
> + *port = 0; /* GDM1 */
> + break;
> + case 0x2 ... 0x4:
> + *port = sport - 1;
> + break;
> + case HSGMII_LAN_7583_ETH_SRCPORT:
> + *port = 2; /* GDM3 */
> + break;
> + case HSGMII_LAN_7583_USB_SRCPORT:
> + *dev = 1;
> + fallthrough;
> + case HSGMII_LAN_7583_PCIE_SRCPORT:
> + *port = 3; /* GDM4 */
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static const struct airoha_eth_soc_data en7581_soc_data = {
> .version = 0x7581,
> .xsi_rsts_names = en7581_xsi_rsts_names,
> @@ -3370,6 +3510,7 @@ static const struct airoha_eth_soc_data en7581_soc_data = {
> .ops = {
> .get_sport = airoha_en7581_get_sport,
> .get_vip_port = airoha_en7581_get_vip_port,
> + .get_dev_from_sport = airoha_en7581_get_dev_from_sport,
> },
> };
>
> @@ -3381,6 +3522,7 @@ static const struct airoha_eth_soc_data an7583_soc_data = {
> .ops = {
> .get_sport = airoha_an7583_get_sport,
> .get_vip_port = airoha_an7583_get_vip_port,
> + .get_dev_from_sport = airoha_an7583_get_dev_from_sport,
> },
> };
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 1f162fa1405e..92fd81bb9269 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -17,6 +17,7 @@
> #include <net/dsa.h>
>
> #define AIROHA_MAX_NUM_GDM_PORTS 4
> +#define AIROHA_MAX_NUM_GDM_DEVS 2
> #define AIROHA_MAX_NUM_QDMA 2
> #define AIROHA_MAX_NUM_IRQ_BANKS 4
> #define AIROHA_MAX_DSA_PORTS 7
> @@ -546,12 +547,13 @@ struct airoha_gdm_dev {
> /* qos stats counters */
> u64 cpu_tx_packets;
> u64 fwd_tx_packets;
> +
> + int nbq;
> };
>
> struct airoha_gdm_port {
> - struct airoha_gdm_dev *dev;
> + struct airoha_gdm_dev *devs[AIROHA_MAX_NUM_GDM_DEVS];
> int id;
> - int nbq;
>
> struct airoha_hw_stats stats;
>
> @@ -587,6 +589,8 @@ struct airoha_eth_soc_data {
> struct {
> int (*get_sport)(struct airoha_gdm_port *port, int nbq);
> u32 (*get_vip_port)(struct airoha_gdm_port *port, int nbq);
> + int (*get_dev_from_sport)(struct airoha_qdma_desc *desc,
> + u16 *port, u16 *dev);
> } ops;
> };
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index c9711bb7ef1c..96abf451fdac 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -167,9 +167,7 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_fe_clear(eth, REG_PPE_PPE_FLOW_CFG(i),
> PPE_FLOW_CFG_IP6_6RD_MASK);
>
> - for (p = 0; p < ARRAY_SIZE(eth->ports); p++) {
> - struct airoha_gdm_port *port = eth->ports[p];
> -
> + for (p = 0; p < ARRAY_SIZE(eth->ports); p++)
> airoha_fe_rmw(eth, REG_PPE_MTU(i, p),
> FP0_EGRESS_MTU_MASK |
> FP1_EGRESS_MTU_MASK,
> @@ -177,11 +175,27 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> AIROHA_MAX_MTU) |
> FIELD_PREP(FP1_EGRESS_MTU_MASK,
> AIROHA_MAX_MTU));
> - if (!port)
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> + struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
> +
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + struct airoha_gdm_dev *dev = port->devs[j];
> + int ppe_id;
> + u8 fport;
> +
> + if (!dev)
> continue;
>
> - airoha_ppe_set_cpu_port(port->dev, i,
> - airoha_get_fe_port(port->dev));
> + ppe_id = !airoha_is_lan_gdm_dev(dev) &&
> + airoha_ppe_is_enabled(eth, 1);
> + fport = airoha_get_fe_port(dev);
> + airoha_ppe_set_cpu_port(dev, ppe_id, fport);
> }
> }
> }
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* RE: [External Mail] Re: [PATCH 00/11] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Wu. JackBB (GSM) @ 2026-06-04 8:22 UTC (permalink / raw)
To: Sergey Ryazanov, Jakub Kicinski, Jack Wu via B4 Relay
Cc: Loic Poulain, Johannes Berg, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Wen-Zhi Huang, Shi-Wei Yeh,
Minano Tseng, Matthias Brugger, AngeloGioacchino Del Regno,
Simon Horman, Jonathan Corbet, Shuah Khan,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <e7df5082-ef48-43d0-ad07-10e1e64e1d26@gmail.com>
Hi
> let me join the discussion and put my 2c.
>
> On 6/2/26 13:58, Wu. JackBB (GSM) wrote:
> > Hi Jakub,
> >
> > > On Fri, 29 May 2026 18:31:39 +0800 Jack Wu via B4 Relay wrote:
> > > > 43 files changed, 14761 insertions(+)
> > >
> > > Please try to cut this down to ~5kLoC for the initial submission.
> > > Whatever the absolute minimum sensible chunk of code is.
> > >
> > > Each patch must build cleanly with W=1
> >
> > We've already reduced this significantly from the original 41k LoC
> > down to ~14.7k by stripping out non-essential features such as
> > exception handling, memory logging, devlink, statistics, debug
> > tracing, and others.
> >
> > We even removed some arguably necessary features (PM, mdlog,
> > throughput optimizations) that we plan to submit as follow-up
> > series.
>
> Great work. Highly appreciate!
>
> > Note that the line count may slightly increase in v2, as we plan
> > to add missing kdoc comments based on review feedback.
> >
> > For reference, the t7xx driver (two generations older, simpler HW)
> > had an initial submission of ~11.3k LoC [1]. The t9xx hardware is
> > more complex, so we believe being in a similar range is reasonable.
>
> Let me elaborate a bit here. The size problem is not due to a git or a
> mailbox limitation. It arise due to the human limitation. The T7xx
> submission review took something about 4 months and 8 iterations. And it
> was 'only' 11.3k lines. Let's do some extrapolation assuming that
> function is linear. 14.7k is 30% bigger, thus, estimated reviewing time
> should be 5 months and 2 weeks. And this looks optimistic.
>
> Recommendation, shared by Jakub, is practical. 5k lines might be
> reviewed in a reasonable time and merged with the full confidence of the
> quality.
>
> > We'd like to keep the driver functional and reviewable in its
> > current scope. Do you have any suggestions on how we could further
> > reduce the size while maintaining a working initial submission?
>
> Off the top of my head, I would suggest joining T7xx and T9xx code
> bases. It could be done through factoring out a core functionality of
> T7xx into a library, or through making the driver layered.
>
> I am not pretending being an expert in any of these drivers, but
> generally divide-n-conqueror together with code reuse work reliable. As
> an alternative, I could spend a couple of weeks reviewing the new
> submission and will come with more specific ideas on what can be thrown
> away or reused.
>
Thank you for the detailed explanation and the practical suggestions.
We discussed this with MediaTek. The T7XX and T9XX hardware architectures
have diverged significantly, so developing a shared driver would require
substantial effort and risk introducing regressions in the existing T7XX
driver, requiring extensive testing to ensure reliability.
MediaTek also confirmed that the current driver cannot be reduced further
without removing functionality. One option would be to remove the data
plane and power management patches, which would bring the submission down
to approximately 9,000 lines:
[0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
[1/7] net: wwan: t9xx: Add PCIe core
[2/7] net: wwan: t9xx: Add control plane transaction layer
[3/7] net: wwan: t9xx: Add control DMA interface
[4/7] net: wwan: t9xx: Add control port
[5/7] net: wwan: t9xx: Add FSM thread
[6/7] net: wwan: t9xx: Add AT & MBIM WWAN ports
[7/7] net: wwan: t9xx: Add maintainers and documentation
We have verified that the MBIM and AT ports work independently in this
configuration — the control plane is fully functional, just without the
network interface.
That said, we would prefer to continue the review with the current 14.7k
line submission if the community is open to it, as it represents a more
complete and testable driver. We are happy to go either way based on your
preference.
Thanks.
> > [1]
> > https://patchwork.kernel.org/project/netdevbpf/cover/20220506181310.2183829-1-ricardo.martinez@linux.intel.com/
> >
> > Thanks.
> >
> >
> > ================================================================================================================================================================
> > This message may contain information which is private, privileged or
> > confidential of Compal Electronics, Inc. If you are not the intended
> > recipient of this message, please notify the sender and destroy/delete the
> > message. Any review, retransmission, dissemination or other use of, or
> > taking of any action in reliance upon this information, by persons or
> > entities other than the intended recipient is prohibited.
> > ================================================================================================================================================================
>
> And this disclaimer does not facilitate the review. Am I 'intended'
> recipient or should I destroy the message ASAP?
Please ignore this message.
Our company's mail server automatically adds this announcement to all external emails.
We apologize for the inconvenience.
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* [PATCH net] net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()
From: ZhaoJinming @ 2026-06-04 7:03 UTC (permalink / raw)
To: lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni
Cc: horms, linux-arm-kernel, linux-mediatek, netdev, linux-kernel,
stable, ZhaoJinming
of_reserved_mem_lookup() may return NULL if the reserved memory region
referenced by the "memory-region" phandle is not found in the reserved
memory table (e.g. due to a misconfigured DTS or a removed
memory-region node). The current code dereferences the returned
pointer without checking for NULL, leading to a kernel NULL pointer
dereference at the following lines:
dma_addr = rmem->base; // line 1156
num_desc = div_u64(rmem->size, buf_size); // line 1160
Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if
the lookup fails, which is consistent with the existing error handling
for of_parse_phandle() failure in the same code block.
Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory")
Cc: stable@vger.kernel.org
Signed-off-by: ZhaoJinming<zhaojinming@uniontech.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index cecd66251dba..2444d3275a81 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1153,6 +1153,9 @@ static int airoha_qdma_init_hfwd_queues(struct airoha_qdma *qdma)
rmem = of_reserved_mem_lookup(np);
of_node_put(np);
+ if (!rmem)
+ return -ENODEV;
+
dma_addr = rmem->base;
/* Compute the number of hw descriptors according to the
* reserved memory size and the payload buffer size
--
2.25.1
^ permalink raw reply related
* RE: [PATCH 01/11] net: wwan: t9xx: Add PCIe core
From: Wu. JackBB (GSM) @ 2026-06-04 6:42 UTC (permalink / raw)
To: Jagielski, Jedrzej, Loic Poulain, Sergey Ryazanov, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <PH0PR11MB5902127C590230B9FE50F78AF0152@PH0PR11MB5902.namprd11.prod.outlook.com>
> Sent: Friday, May 29, 2026 12:32 PM
>
> > +
>
> please also take a look on sashiko notes, there is some number of them
Hi Jagielski,
Thank you for your review. We have fixed some issues and are still discussing others with MediaTek. All of them will be addressed in V2.
Regarding sashiko notes, how should I handle them if discussion is needed? I cannot find sashiko's email address, and its website does not have a reply option.
For example:
https://sashiko.dev/#/patchset/20260529-t9xx_driver_v1-v1-0-bdbfe2c01e57%40compal.com?part=2
Q1:
The commit message mentions implementing TX and RX services, but the patch primarily adds empty structures and boilerplate code. Is the patch missing the actual TX/RX implementation described here?
Reply:
We plan to update the commit message. Would the following be acceptable?
Add the control plane transaction layer framework for the t9xx
WWAN driver, including configuration options, device structure
definitions, and initialization/cleanup functions.
The actual TX/RX service implementations that use this framework
are introduced in subsequent patches.
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH net 0/2] Fix use-after-free in metadata dst teardown in airoha_eth and mtk_eth_soc drivers
From: patchwork-bot+netdevbpf @ 2026-06-04 2:30 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, nbd, matthias.bgg,
angelogioacchino.delregno, fw, linux-arm-kernel, linux-mediatek,
netdev
In-Reply-To: <20260602-airoha-mtk-metadata-uaf-fix-v1-0-3aaa99d83351@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 02 Jun 2026 11:21:03 +0200 you wrote:
> airoha_metadata_dst_free() and mtk_free_dev() call metadata_dst_free()
> which frees the metadata_dst with kfree() immediately, bypassing the RCU
> grace period.
> Replace metadata_dst_free() with dst_release() which properly goes
> through the refcount path and runs call_rcu_hurry() if refcount goes to
> zero.
>
> [...]
Here is the summary with links:
- [net,1/2] net: airoha: Fix use-after-free in metadata dst teardown
https://git.kernel.org/netdev/net/c/b38cae85d1c4
- [net,2/2] net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown
https://git.kernel.org/netdev/net/c/80df409e1a48
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v3 0/2] af_unix: Fix inq_len update issue
From: patchwork-bot+netdevbpf @ 2026-06-04 2:00 UTC (permalink / raw)
To: =?utf-8?b?Smlhbnl1IExpICjmnY7lgaXnkYApIDxqaWFueXUubGlAbWVkaWF0ZWsuY29tPg==?=
Cc: kuniyu, davem, edumazet, kuba, pabeni, horms, willemb, netdev,
linux-kernel, linux-mediatek, black-ch.chen, ivan.tseng
In-Reply-To: <20260601113640.231897-1-jianyu.li@mediatek.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 1 Jun 2026 19:36:38 +0800 you wrote:
> From: Jianyu Li <jianyu.li@mediatek.com>
>
> This series fix the problem that inq_len is inconsistent with
> actual remaining byte count when only part of a skb is consumed.
>
> Changes:
> v3:
> - Patch 2: Align macro definitions
> v2: https://lore.kernel.org/netdev/20260528110033.3327744-1-jianyu.li@mediatek.com/
> - Patch 1: Improve lock usage in unix_stream_read_generic()
> - Patch 2: Follow reverse xmas tree ordering in partial_read test case
> v1: https://lore.kernel.org/netdev/20260527065342.2463433-1-jianyu.li@mediatek.com/
>
> [...]
Here is the summary with links:
- [net,v3,1/2] af_unix: Fix inq_len update problem in partial read
https://git.kernel.org/netdev/net/c/c1f07a7f2d47
- [net,v3,2/2] af_unix: Add test for SCM_INQ on partial read
https://git.kernel.org/netdev/net/c/dd8975ad710e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] regulator: dt-bindings: mt6311: Convert to DT schema
From: Rob Herring @ 2026-06-04 1:47 UTC (permalink / raw)
To: Ninad Naik
Cc: lgirdwood, broonie, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, me, linux-kernel-mentees, skhan
In-Reply-To: <20260531165712.729635-1-ninadnaik07@gmail.com>
On Sun, May 31, 2026 at 10:27:12PM +0530, Ninad Naik wrote:
> Convert mediatek,mt6311 to DT schema.
>
> Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
> ---
> .../regulator/mediatek,mt6311-regulator.yaml | 72 +++++++++++++++++++
> .../bindings/regulator/mt6311-regulator.txt | 35 ---------
> 2 files changed, 72 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> delete mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> new file mode 100644
> index 000000000000..a51db46b0f41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6311-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT6311 Regulator
> +
> +maintainers:
> + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> +
> +description: |
Don't need '|' if no formatting.
> + The MediaTek MT6311 is an I2C power management IC that provides one step-down
> + converter and one low-dropout regulator. The regulators are named VDVFS and
> + VBIASN, respectively.
> +
> +properties:
> + compatible:
> + const: mediatek,mt6311-regulator
> +
> + reg:
> + description: I2C slave address.
> + maxItems: 1
> +
> + regulators:
> + type: object
> + description: List of regulators provided by this controller.
> +
> + patternProperties:
> + "^(VDVFS|VBIASN)$":
> + type: object
> + $ref: regulator.yaml#
> + description: |
> + Regulator nodes.
Drop. That's obvious with the $ref.
> + unevaluatedProperties: false
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - regulators
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mt6311: pmic@6b {
Drop unused label.
> + compatible = "mediatek,mt6311-regulator";
> + reg = <0x6b>;
> +
> + regulators {
> + mt6311_vcpu_reg: VDVFS {
Drop unused label.
> + regulator-name = "VDVFS";
> + regulator-min-microvolt = <600000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-ramp-delay = <10000>;
> + };
> +
> + mt6311_ldo_reg: VBIASN {
Drop unused label.
> + regulator-name = "VBIASN";
> + regulator-min-microvolt = <200000>;
> + regulator-max-microvolt = <800000>;
> + };
> + };
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> deleted file mode 100644
> index 84d544d8c1b1..000000000000
> --- a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -Mediatek MT6311 Regulator
> -
> -Required properties:
> -- compatible: "mediatek,mt6311-regulator"
> -- reg: I2C slave address, usually 0x6b.
> -- regulators: List of regulators provided by this controller. It is named
> - to VDVFS and VBIASN.
> - The definition for each of these nodes is defined using the standard binding
> - for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
> -
> -The valid names for regulators are:
> -BUCK:
> - VDVFS
> -LDO:
> - VBIASN
> -
> -Example:
> - mt6311: pmic@6b {
> - compatible = "mediatek,mt6311-regulator";
> - reg = <0x6b>;
> -
> - regulators {
> - mt6311_vcpu_reg: VDVFS {
> - regulator-name = "VDVFS";
> - regulator-min-microvolt = < 600000>;
> - regulator-max-microvolt = <1400000>;
> - regulator-ramp-delay = <10000>;
> - };
> - mt6311_ldo_reg: VBIASN {
> - regulator-name = "VBIASN";
> - regulator-min-microvolt = <200000>;
> - regulator-max-microvolt = <800000>;
> - };
> - };
> - };
> --
> 2.54.0
>
>
^ permalink raw reply
* Re: [bug report] wifi: mt76: mt7921: mt7925monitor-mode per-channel retune emits narrowband RF burst
From: Bradley Pizzimenti @ 2026-06-03 23:46 UTC (permalink / raw)
To: Sean Wang
Cc: John Henry, Javier Tia, linux-wireless, linux-kernel, nbd,
lorenzo, ryder.lee, shayne.chen, sean.wang,
moderated list:ARM/Mediatek SoC support, Deren Wu, Nick Morrow
In-Reply-To: <CAGp9LzrmUGQLK5giHVgOjJ5pzGNnfLaV02iWdodT7aDNBbNUqg@mail.gmail.com>
Hi there,
Are all of these fixes going into kernel 7.1+ or introduced earlier?
On Wed, May 27, 2026 at 4:08 PM Sean Wang <sean.wang@kernel.org> wrote:
>
> Hi John,
>
> On Wed, May 27, 2026 at 7:24 AM John Henry <jshenry1963@gmail.com> wrote:
> >
> > Just a kind reminder of this issue.
> >
> > Please advise if this is already taken up in a separate issue I am
> > unaware of, but it is not directly related to the "iw set txpower
> > fixed accepted but ignored" issue.
> >
> > On products available in the market, e.g. the Alfa AWUS036AXML
> > consumer product and the Netgear Nighthawk A9000, in Monitor Mode
> > there is RF generated when scanning through channels and we get to 5
> > or more channels in succession.
> > This does not seem to occur at all in managed mode.
> >
> > This means if we scan the 2.4GHz channel list, an RF Spectrum analyzer
> > will show a narrow pulse generated on each channel as we progress
> > through the channels.
> > This can 100% be reproduced using standard iw set channel commands as
> > shown below:
> > FACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
> > iw reg set US ; sleep 1
> > ip link set "$IFACE" down
> > iw dev "$IFACE" set type monitor
> > ip link set "$IFACE" up
> >
> > # This triggers narrowband bursts at channel center on each retune:
> > while true; do
> > for f in 2412 2417 2422 2427 2432; do
> > iw dev "$IFACE" set freq "$f" HT20
> > done
> > done
> >
>
> I have thought about this issue for a while. A possible workaround
> would be to reset WFSYS / firmware after five consecutive `set
> channel` operations in monitor mode, then restore the current monitor
> channel context. The WFSYS reset may take hundreds of milliseconds to
> complete, which is the cost we would need to pay.
>
> > No special software required to reproduce.
> > I have shown that this occurs on all MT7921 based products, along with
> > MT7925 based products.
> > It does not occur if the channel list is set to the same 4 over and
> > over, no RF generated.
> >
> > There are no calibration channel commands going from the driver to the
> > firmware, so I believe this is a firmware bug.
> >
> > Best Regards,
> > John Henry
> >
> > On Sun, May 17, 2026 at 9:01 AM John Henry <jshenry1963@gmail.com> wrote:
> > >
> > > Just a kind reminder of this issue, has anyone been able to reproduce
> > > this monitor mode issue?
> > > When scanning through channels, and the list of channels is > 4, there
> > > is a large transmit tick/burst coming from the MT7921u and the MT7925.
> > > This can easily be seen on an RF Spectrum Analyzer.
> > > Confirmed on an Alfa AWUS036AXML consumer product and the Netgear
> > > Nighthawk A9000.
> > > This can be reproduced with simple scripts.
> > >
> > > Reproduction with stock iw commands (no custom code):
> > >
> > > IFACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
> > > iw reg set US ; sleep 1
> > > ip link set "$IFACE" down
> > > iw dev "$IFACE" set type monitor
> > > ip link set "$IFACE" up
> > >
> > > # This triggers narrowband bursts at channel center on each retune:
> > > while true; do
> > > for f in 2412 2417 2422 2427 2432; do
> > > iw dev "$IFACE" set freq "$f" HT20
> > > done
> > > done
> > >
> > > # This does NOT (only 4 frequencies):
> > > while true; do
> > > for f in 2412 2422 2462 2484; do
> > > iw dev "$IFACE" set freq "$f" HT20
> > > done
> > > done
> > >
> > > Bursts are ~800 kHz wide at the base, -30 to -50 dBm OTA at close
> > > range, brief (estimated few hundred microseconds), at channel
> > > frequency. tx_stats counters remain zero throughout.
> > > On Mon, May 11, 2026 at 1:58 PM John Henry <jshenry1963@gmail.com> wrote:
> > > >
> > > > Bradley/Sean,
> > > >
> > > > Thank you all very much for the information.
> > > > I tested this on mt7921u based Alfa AWUS unit and also an mt7925 based
> > > > Netgear Nighthawk unit.
> > > > I can confirm that the RF tick issue is present on both models when in
> > > > Monitor Mode. I'm assuming it is in the base mt76?
> > > >
> > > > I attempted sudo iw dev wlxxx set txpower fixed nn where nn is the
> > > > minimum value, next few values up, and then a few near the max values,
> > > > and see no change in the signal strength of the RF Ticks when scanning
> > > > through 5 or more channels.
> > > >
> > > > Please keep this in mind when attempting to resolve the known txpower
> > > > 3dBm issue if possible, or please generate a new bug report for that
> > > > specifically so that I can track when it is patched, or in ??? version
> > > > so that I can test here locally.
> > > >
> > > > Incidentally, I'd appreciate it if anyone could please attempt to
> > > > repeat using the scripts I had shown in the previous posts and confirm
> > > > it is indeed seen by others.
> > > >
> > > > Thank you very much for your time and assistance
> > > >
> > > > John Henry
> > > >
> > > >
> > > >
> > > >
> > > > From: Bradley Pizzimenti <brad.pizzimenti@gmail.com>
> > > > To: linux-wireless@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org, nbd@nbd.name, lorenzo@kernel.org,
> > > > ryder.lee@mediatek.com, shayne.chen@mediatek.com,
> > > > sean.wang@mediatek.com
> > > > Subject: [bug report] wifi: mt76: mt7925: iw set txpower fixed
> > > > accepted but ignored
> > > > Date: Mon, 4 May 2026 15:04:35 -0700 [thread overview]
> > > > Message-ID: <CACjnFagN9zeSkwEv3-CSPJDUENPcEcOLjKyQoLQ91Yjn=rq5ww@mail.gmail.com>
> > > > (raw)
> > > >
> > > > Hi there maintainers,
> > > >
> > > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for any
> > > > N tested, but the reported txpower never changes from a stuck value of
> > > > 3.00 dBm. The kernel accepts and ignores the call silently in both
> > > > directions (above and below the displayed value), and well below the
> > > > regulatory ceiling.
> > > >
> > > > I'm aware there's prior art on the cosmetic 3.00 dBm display issue
> > > > (Razvan Grigore's v2 series, Feb 2025; Ming Yen Hsieh's txpower init
> > > > refactor, Sept 2025). What seems potentially distinct here is that the
> > > > user-issued `iw set txpower fixed N` itself is silently no-op'd,
> > > > separate from the reported-value question. Reporting as breadcrumbs
> > > > in case the second observation is a separate bug rather than the same
> > > > one.
> > > >
> > > > Hardware
> > > > --------
> > > > MEDIATEK MT7925 [Filogic 360], 802.11be 2x2, PCI 14c3:7925
> > > > ASIC revision 0x79250000
> > > > Driver in use: mt7925e (in-tree)
> > > >
> > > > Firmware (from dmesg at probe)
> > > > ------------------------------
> > > > mt7925e 0000:01:00.0: HW/SW Version: 0x8a108a10,
> > > > Build Time: 20260106153007a
> > > > mt7925e 0000:01:00.0: WM Firmware Version: ____000000,
> > > > Build Time: 20260106153120
> > > > Files: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
> > > > mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin
> > > >
> > > > Kernel
> > > > ------
> > > > 6.18.18-1-MANJARO (close to vanilla 6.18 stable; not yet tested on
> > > > wireless-next or nbd168/wireless HEAD -- happy to retest if needed,
> > > > but flagging the data point in case it helps as-is).
> > > >
> > > > Tools: iw version 6.17
> > > >
> > > > Regulatory
> > > > ----------
> > > > $ iw reg get
> > > > country US: DFS-FCC
> > > > ...
> > > > (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
> > > > ...
> > > >
> > > > Connection context: 5GHz channel 161 (5805 MHz), 80 MHz, VHT-MCS,
> > > > NSS 1. So we are on a band with a 30 dBm regulatory cap.
> > > >
> > > > Observed
> > > > --------
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > $ sudo iw dev wlp1s0 set txpower fixed 100 # 1 dBm
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > $ sudo iw dev wlp1s0 set txpower fixed 1500 # 15 dBm
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > $ sudo iw dev wlp1s0 set txpower auto
> > > > $ iw dev wlp1s0 info | grep txpower
> > > > txpower 3.00 dBm
> > > >
> > > > All four `set` invocations return exit code 0. The reported value
> > > > never moves.
> > > >
> > > > Expected
> > > > --------
> > > > Either:
> > > > - The reported txpower follows the requested value (or, where
> > > > capped, the actual applied value with extack indicating the
> > > > cap reason), or
> > > > - The set call returns an error rather than silently ignoring the
> > > > request.
> > > >
> > > > Caveats
> > > > -------
> > > > - Not yet tested on wireless-next or nbd168/wireless HEAD. If a
> > > > reproduction on a current dev tree would be useful, I can do that.
> > > > - I have not verified whether the actual radiated TX power changes
> > > > in response to `set txpower fixed`; I am reporting only the
> > > > user-visible behavior.
> > > >
> > > > Thanks,
> > > > Bradley
> > > >
> > > > On Wed, May 6, 2026 at 8:12 PM Sean Wang <sean.wang@kernel.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > The TX power reporting issue has already been investigated by Lucid
> > > > > from the Linux WiFi USB community, and there is a proposed solution.
> > > > > I think we can continue checking whether there are any remaining
> > > > > issues on top of that work. Please refer to the patches here:
> > > > > https://lists.infradead.org/pipermail/linux-mediatek/2026-April/105726.html
> > > > > Thanks everyone for reporting and raising these concerns.
> > > > >
> > > > > On Wed, May 6, 2026 at 3:09 PM Javier Tia <floss@jetm.me> wrote:
> > > > > >
> > > > > > On Sun May 4 22:04:48 2026 Bradley Pizzimenti wrote:
> > > > > > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for
> > > > > > > any N tested, but the reported txpower never changes from a stuck
> > > > > > > value of 3.00 dBm.
> > > > > >
> > > > > > Hi Bradley,
> > > > > >
> > > > > > The 3 dBm display bug is a known issue we have seen when using mt7927
> > > > > > and a tested fix has been working well so far. The root cause is that
> > > > > > mt7925_mcu_set_rate_txpower() programs the per-band SKU tables into
> > > > > > firmware but never assigns phy->txpower_cur. mt76_get_txpower() then
> > > > > > computes:
> > > > > >
> > > > > > DIV_ROUND_UP(0 + 6, 2) = 3
> > > > > >
> > > > > > regardless of the actual power level. The RF output is unaffected;
> > > > > > it is a display-only bug.
> > > > > >
> > > > > > The fix reads the effective TX power back from the rate power limits
> > > > > > after programming the SKU tables and writes it to phy->txpower_cur,
> > > > > > following the same pattern used by mt7996:
> > > > > >
> > > > > > https://github.com/jetm/mediatek-mt7927-dkms/blob/master/mt7927-wifi-14-fix-reported-txpower-always-showing-3-db.patch
> > > > > >
> > > > > > This is part of a series we are targeting for wireless-next; not
> > > > > > yet upstream.
> > > > > >
> > > > > > > What seems potentially distinct here is that the user-issued
> > > > > > > `iw set txpower fixed N` itself is silently no-op'd, separate
> > > > > > > from the reported-value question.
> > > > > >
> > > > > > Agreed those are two separate issues. Our patch addresses the
> > > > > > display-only side: after applying it, iw will report the value the
> > > > > > firmware is actually using based on the SKU tables, rather than
> > > > > > always 3 dBm. Whether `set txpower fixed N` propagates to firmware
> > > > > > to change actual output power is orthogonal and not addressed here.
> > > > > >
> > > > > > If you can test the patch on your MT7925 and confirm the displayed
> > > > > > value reflects the correct power after association, a Tested-by
> > > > > > would be appreciated.
> > > > > >
> > > > > > Best,
> > > > > > Javier
> > > > > >
> > > > >
^ permalink raw reply
* Re: (subset) [PATCH v1 0/6] power: Use named initializers for platform_device_id arrays
From: Sebastian Reichel @ 2026-06-03 20:46 UTC (permalink / raw)
To: Sebastian Reichel, Uwe Kleine-König (The Capable Hub)
Cc: Kuan-Wei Chiu, Benson Leung, Guenter Roeck, Thomas Weißschuh,
Krzysztof Kozlowski, Matthias Brugger, AngeloGioacchino Del Regno,
linux-pm, linux-kernel, chrome-platform, linux-arm-kernel,
linux-mediatek, Hans de Goede, Marek Szyprowski,
Sebastian Krzyszkowiak, Purism Kernel Team, Yixun Lan,
Andreas Kemnade, Matti Vaittinen, Sven Peter, Janne Grunau,
Neal Gompa, Amit Sunil Dhamne, Samuel Kayode, linux-riscv,
spacemit, asahi, imx, Chen-Yu Tsai
In-Reply-To: <cover.1780048925.git.u.kleine-koenig@baylibre.com>
On Fri, 29 May 2026 12:18:15 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -610,4 +610,7 @@ struct dmi_system_id {
> struct platform_device_id {
> char name[PLATFORM_NAME_SIZE];
> - kernel_ulong_t driver_data;
> + union {
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
>
> [...]
Applied, thanks!
[1/6] power: Drop unused assignment of platform_device_id driver data
commit: 75a0e1e0b86078687c3c6a05107a98c7e59a65a8
[2/6] power: supply: max14577: Drop driver data in of and platform device id arrays
commit: 37258ad1f3a52ea442c32b3c92ad7146e74050c7
[4/6] power: Use named initializers for platform_device_id arrays
commit: e28f7498dd819878b8acacb89c4c073a646feea0
[5/6] power: supply: mt6360_charger: Use of match table unconditionally
commit: eb7ed650e5960fc303130704d1e29d18a7d0e1df
[6/6] power: Unify code style for platform_device_id arrays
commit: e3f669bed32287ae72c05a4ddab4a6687b0e62ca
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
From: kernel test robot @ 2026-06-03 20:27 UTC (permalink / raw)
To: JB Tsai, nbd, lorenzo
Cc: llvm, oe-kbuild-all, linux-wireless, linux-mediatek, Deren.Wu,
Sean.Wang, Quan.Zhou, Ryder.Lee, Leon.Yen, litien.chang,
Charlie-cy.Wu, jb.tsai
In-Reply-To: <20260603075331.1234691-1-jb.tsai@mediatek.com>
Hi JB,
kernel test robot noticed the following build errors:
[auto build test ERROR on wireless-next/main]
[also build test ERROR on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/JB-Tsai/wifi-mt76-mt7925-add-regulatory-wiphy-self-manager-support/20260603-155908
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603075331.1234691-1-jb.tsai%40mediatek.com
patch subject: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260603/202606032205.iaSDVq2Z-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/20260603/202606032205.iaSDVq2Z-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/202606032205.iaSDVq2Z-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/net/wireless/mediatek/mt76/mt7925/regd.c:361:43: error: passing 'const struct ieee80211_regdomain *' to parameter of type 'struct ieee80211_regdomain *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
361 | return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
| ^~~~~~~~~~~~~~~
include/net/cfg80211.h:8082:38: note: passing argument to parameter 'rd' here
8082 | struct ieee80211_regdomain *rd);
| ^
1 error generated.
vim +361 drivers/net/wireless/mediatek/mt76/mt7925/regd.c
286
287 int mt7925_regd_update(struct mt792x_phy *phy, char *alpha2)
288 {
289 struct wiphy *wiphy = phy->mt76->hw->wiphy;
290 struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
291 struct mt792x_dev *dev = mt792x_hw_dev(hw);
292 struct mt7925_regd_rule *mt7925_rule;
293 struct mt76_dev *mdev = &dev->mt76;
294 struct ieee80211_regdomain *regd;
295 struct ieee80211_reg_rule *rule;
296 struct mt7925_regd_rule_ev *ev;
297 int i, num_of_rules = 0;
298 struct sk_buff *skb;
299 int ret = 0;
300
301 if (dev->hw_full_reset)
302 return 0;
303
304 if (!MT7925_REGD_SUPPORTED(phy))
305 return -EOPNOTSUPP;
306
307 mt792x_mutex_acquire(dev);
308 skb = mt7925_regd_query_regdb(phy, alpha2);
309 mt792x_mutex_release(dev);
310
311 if (!skb)
312 return -EINVAL;
313
314 ev = (struct mt7925_regd_rule_ev *)(skb->data + 4);
315 num_of_rules = le32_to_cpu(ev->n_reg_rules);
316
317 if (!num_of_rules ||
318 WARN_ON_ONCE(num_of_rules > NL80211_MAX_SUPP_REG_RULES)) {
319 ret = -EINVAL;
320 goto err;
321 }
322
323 regd = kzalloc(struct_size(regd, reg_rules, num_of_rules), GFP_KERNEL);
324 if (!regd) {
325 ret = -ENOMEM;
326 goto err;
327 }
328
329 for (i = 0; i < num_of_rules; i++) {
330 mt7925_rule = &ev->reg_rule[i];
331 rule = ®d->reg_rules[i];
332
333 rule->freq_range.start_freq_khz =
334 MHZ_TO_KHZ(mt7925_rule->start_freq);
335 rule->freq_range.end_freq_khz =
336 MHZ_TO_KHZ(mt7925_rule->end_freq);
337 rule->freq_range.max_bandwidth_khz =
338 MHZ_TO_KHZ(mt7925_rule->max_bw);
339 /* not used by fw */
340 rule->power_rule.max_antenna_gain = DBI_TO_MBI(6);
341 rule->power_rule.max_eirp = DBM_TO_MBM(22);
342 rule->flags = mt7925_rule->flags;
343 }
344
345 regd->n_reg_rules = num_of_rules;
346 regd->dfs_region = ev->dfs_region;
347
348 memcpy(regd->alpha2, alpha2, 2);
349 memcpy(mdev->alpha2, alpha2, 2);
350
351 dev->regd_change = true;
352 mt7925_mcu_regd_update(dev, alpha2, ENVIRON_ANY);
353
354 ret = regulatory_set_wiphy_regd(wiphy, regd);
355
356 kfree(regd);
357 err:
358 dev_kfree_skb(skb);
359
360 if (ret < 0)
> 361 return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
362
363 return ret;
364 }
365 EXPORT_SYMBOL_GPL(mt7925_regd_update);
366
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: patchwork-bot+bluetooth @ 2026-06-03 17:50 UTC (permalink / raw)
To: Rong Zhang
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260603-btmtk-remote-wakeup-v1-1-5c1006442f36@rong.moe>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
> These NICs are often reported to lose their Bluetooth interfaces, i.e,
> their USB interfaces suddenly become completely unresponsive, causing
> the USB core to reset them, only to find that they are no longer
> accessible. A power cycle is required to make the Bluetooth interfaces
> recover.
>
> After some investigations, I found that their USB autosuspend remote
> wakeup capabilities are so broken that they are precisely the culprit
> behind the issue:
>
> [...]
Here is the summary with links:
- Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Jonathan Cameron @ 2026-06-03 17:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Romain Gantois, MyungJoo Ham, Chanwoo Choi, Guenter Roeck,
Peter Rosin, David Lechner, Nuno Sá, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Mariel Tinaco, Kevin Tsai,
Linus Walleij, Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
Sebastian Reichel, Chen-Yu Tsai, Hans de Goede,
Support Opensource, Paul Cercueil, Iskren Chernev,
Krzysztof Kozlowski, Marek Szyprowski, Matheus Castello,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Sylwester Nawrocki, Olivier Moysan, Arnaud Pouliquen,
Maxime Coquelin, Alexandre Torgue, Thomas Petazzoni, linux-kernel,
linux-hwmon, linux-iio, linux-input, linux-phy, linux-pm,
linux-mips, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Sebastian Reichel, Andy Shevchenko
In-Reply-To: <acBr-W2ILu9tnMyd@google.com>
On Sun, 22 Mar 2026 15:24:21 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Tue, Dec 09, 2025 at 09:25:56AM +0100, Romain Gantois wrote:
> > Use namespaced exports for IIO consumer API functions.
> >
> > This will make it easier to manage the IIO export surface. Consumer drivers
> > will only be provided access to a specific set of functions, thereby
> > restricting usage of internal IIO functions by other parts of the kernel.
> >
> > This change cannot be split into several parts without breaking
> > bisectability, thus all of the affected drivers are modified at once.
> >
> > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for power-supply
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
>
> For input:
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Thanks.
>
For anyone wondering what happened to this... I forgot to apply this at the
beginning of the cycle and by the time I remembered we had too much queued up
so it would have been messy to do an immutable branch. Anyhow, I plan to
sort this at start of next cycle.
Jonathan
^ permalink raw reply
* Re: [PATCH v5 11/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196
From: Conor Dooley @ 2026-06-03 16:14 UTC (permalink / raw)
To: Kyrie Wu
Cc: Fan Wu, Andrew-CT Chen, Kees Cook, Yunfei Dong, Matthias Brugger,
Haoxiang Li, Rob Herring, Laurent Pinchart, Benjamin Gaignard,
Sebastian Fricke, Chen-Yu Tsai, linux-media, devicetree,
Conor Dooley, Sakari Ailus, Irui Wang, Mauro Carvalho Chehab,
linux-mediatek, Tzung-Bi Shih, Jacopo Mondi, Tiffany Lin,
Qianfeng Rong, linux-arm-kernel, AngeloGioacchino Del Regno,
Hans Verkuil, linux-kernel, Tomasz Figa, Philipp Zabel,
Ricardo Ribalda, Krzysztof Kozlowski, Nicolas Dufresne
In-Reply-To: <20260603084045.17488-12-kyrie.wu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
On Wed, Jun 03, 2026 at 04:40:41PM +0800, Kyrie Wu wrote:
> From: Yunfei Dong <yunfei.dong@mediatek.com>
>
> The MT8196 decoder differs from previous generations in several
> key aspects, most notably in its use of VCP instead of SCP.
> Additionally, the MT8196 enhances codec capabilities by supporting
> HEVC Main10 profile decoding. To accommodate these hardware changes,
> the binding constraints specify a total of 12 clock inputs,
> consisting of 9 decoder clocks and 3 VCP interface clocks,
> along with 2 power domains covering both the decoder and VCP
> subsystems.
I'm pretty pretty confused by this statement about constraints, since
there's none added?
The vcodec-dec node doesn't even seem to permit clocks at all?
>
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> .../bindings/media/mediatek,vcodec-subdev-decoder.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> index bf8082d87ac0..74e1d88d3056 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> @@ -76,6 +76,7 @@ properties:
> - mediatek,mt8186-vcodec-dec
> - mediatek,mt8188-vcodec-dec
> - mediatek,mt8195-vcodec-dec
> + - mediatek,mt8196-vcodec-dec
>
> reg:
> minItems: 1
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()
From: Dylan Eskew @ 2026-06-03 15:43 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, linux-wireless,
linux-arm-kernel, linux-mediatek
In-Reply-To: <ah_TG4bkzitM4AER@lore-desk>
Hi Lore,
>> Hi Lore,
> Hi Dylan,
>
>> We have been seeing the token memory leak in our custom kernel. After
>> pulling your patch in, we are still getting the leak (validated with
>> kmemleak). How did you figure out where this potential leak was? I want to
>> determine if we are leaking because of our changes or if there's more areas
>> for token leakage.
> Can you please try to run kmemleak on Felix's tree to check if there are any
> leftover leaks not fixed yet?
Ran kmemleak with Felix's tree. I brought up only a few stations, no
traffic run yet and kmemleak flagged a possible leak, same allocation
location we've seen flagged in our custom kernel.
kmemleak trace:
```
unreferenced object 0xffff88811e6ca380 (size 128):
comm "mt76-tx phy0", pid 1164, jiffies 4295044455
hex dump (first 32 bytes):
44 00 00 1a 0a a0 4c ae 0d 00 00 00 02 78 00 30 D.....L......x.0
00 00 00 00 01 00 00 00 14 00 27 12 00 00 00 08 ..........'.....
backtrace (crc fba2c5a3):
__kmalloc_noprof+0x38e/0x480
mt76_dma_tx_queue_skb+0x522/0x890 [mt76]
__mt76_tx_queue_skb+0x3e/0xa0 [mt76]
mt76_txq_schedule_pending_wcid+0x12b/0x200 [mt76]
mt76_txq_schedule_pending+0x122/0x1b0 [mt76]
mt76_tx_worker_run+0x1b/0xc0 [mt76]
__mt76_worker_fn+0x49/0x90 [mt76]
kthread+0xdc/0x110
ret_from_fork+0x190/0x280
ret_from_fork_asm+0x11/0x20
```
In dma.c, line 19 is the where the kmemleak trace points:
```
10 static struct mt76_txwi_cache *
11 mt76_alloc_txwi(struct mt76_dev *dev)
12 {
13 struct mt76_txwi_cache *t;
14 dma_addr_t addr;
15 u8 *txwi;
16 int size;
17
18 size = L1_CACHE_ALIGN(dev->drv->txwi_size + sizeof(*t));
19 txwi = kzalloc(size, GFP_ATOMIC);
20 if (!txwi)
21 return NULL;
22
23 addr = dma_map_single(dev->dma_dev, txwi, dev->drv->txwi_size,
24 DMA_TO_DEVICE);
25 if (unlikely(dma_mapping_error(dev->dma_dev, addr))) {
26 kfree(txwi);
27 return NULL;
28 }
29
30 t = (struct mt76_txwi_cache *)(txwi + dev->drv->txwi_size);
31 t->dma_addr = addr;
32
33 return t;
34 }
```
Let me know if you need any other information.
-- Dylan
>
> Regards,
> Lorenzo
>
>> -- Dylan
>>
>> On 5/31/26 2:10 AM, Lorenzo Bianconi wrote:
>>> If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine,
>>> mt7996 driver leaks an already allocated tx token. Fix the issue
>>> releasing the token in case of error.
>>>
>>> Fixes: 7ef0c7ad735b0 ("wifi: mt76: mt7996: Implement MLD address translation for EAPOL")
>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 8 ++++++--
>>> drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
>>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> index c98446057282..8c56344d211b 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> @@ -1067,11 +1067,11 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>>> link_conf = rcu_dereference(vif->link_conf[wcid->link_id]);
>>> if (!link_conf)
>>> - return -EINVAL;
>>> + goto error_relase_token;
>>> link_sta = rcu_dereference(sta->link[wcid->link_id]);
>>> if (!link_sta)
>>> - return -EINVAL;
>>> + goto error_relase_token;
>>> dma_sync_single_for_cpu(mdev->dma_dev, tx_info->buf[1].addr,
>>> tx_info->buf[1].len, DMA_TO_DEVICE);
>>> @@ -1176,6 +1176,10 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>>> tx_info->nbuf = MT_CT_DMA_BUF_NUM;
>>> return 0;
>>> +
>>> +error_relase_token:
>>> + mt76_token_release(mdev, id, NULL);
>>> + return -EINVAL;
>>> }
>>> u32 mt7996_wed_init_buf(void *ptr, dma_addr_t phys, int token_id)
>>> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
>>> index 22f9690634c9..f96d9c471853 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/tx.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
>>> @@ -933,7 +933,7 @@ mt76_token_release(struct mt76_dev *dev, int token, bool *wake)
>>> #endif
>>> }
>>> - if (dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
>>> + if (wake && dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
>>> dev->phy.q_tx[0]->blocked)
>>> *wake = true;
>>>
>>> ---
>>> base-commit: 4913f44167cf35a9536e9eec7352e15b2de0c573
>>> change-id: 20260531-mt7996_tx_prepare_skb-token-leack-82e240d8c66f
>>>
>>> Best regards,
^ permalink raw reply
* Re: [PATCH v2 RESEND 0/5] wifi: mediatek: drop redundant USB device references
From: Johan Hovold @ 2026-06-03 14:51 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Jakub Kicinski
Cc: Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, linux-mediatek,
linux-kernel
In-Reply-To: <20260430083335.215239-1-johan@kernel.org>
On Thu, Apr 30, 2026 at 10:33:30AM +0200, Johan Hovold wrote:
> [ This is a resend (with trimmed CC) of the five Mediatek patches which
> still haven't been picked up from [1]. ]
>
> Driver core holds a reference to the USB interface and its parent USB
> device while the interface is bound to a driver and there is no need to
> take additional references unless the structures are needed after
> disconnect.
>
> Drop redundant device references to reduce cargo culting, make it easier
> to spot drivers where an extra reference is needed, and reduce the risk
> of memory leaks when drivers fail to release them.
> [1] https://lore.kernel.org/all/20260306085144.12064-1-johan@kernel.org/
>
>
> Johan Hovold (5):
> wifi: mt76: drop redundant device reference
> wifi: mt76x0u: drop redundant device reference
> wifi: mt76x2u: drop redundant device reference
> wifi: mt76: mt792xu: drop redundant device reference
> wifi: mt7601u: drop redundant device reference
It's now been three months since these were first posted.
Can someone please pick them up?
Johan
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
From: kernel test robot @ 2026-06-03 14:41 UTC (permalink / raw)
To: JB Tsai, nbd, lorenzo
Cc: oe-kbuild-all, linux-wireless, linux-mediatek, Deren.Wu,
Sean.Wang, Quan.Zhou, Ryder.Lee, Leon.Yen, litien.chang,
Charlie-cy.Wu, jb.tsai
In-Reply-To: <20260603075331.1234691-1-jb.tsai@mediatek.com>
Hi JB,
kernel test robot noticed the following build warnings:
[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/JB-Tsai/wifi-mt76-mt7925-add-regulatory-wiphy-self-manager-support/20260603-155908
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603075331.1234691-1-jb.tsai%40mediatek.com
patch subject: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260603/202606031619.GjGn8yRe-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260603/202606031619.GjGn8yRe-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/202606031619.GjGn8yRe-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/wireless/mediatek/mt76/mt7925/regd.c: In function 'mt7925_regd_update':
>> drivers/net/wireless/mediatek/mt76/mt7925/regd.c:361:57: warning: passing argument 2 of 'regulatory_set_wiphy_regd' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
361 | return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
| ^~~~~~~~~~~~~~~
In file included from include/net/mac80211.h:22,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt76.h:18,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt76_connac.h:7,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt76_connac_mcu.h:7,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt792x.h:10,
from drivers/net/wireless/mediatek/mt76/mt7925/mt7925.h:7,
from drivers/net/wireless/mediatek/mt76/mt7925/regd.c:4:
include/net/cfg80211.h:8082:59: note: expected 'struct ieee80211_regdomain *' but argument is of type 'const struct ieee80211_regdomain *'
8082 | struct ieee80211_regdomain *rd);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
vim +361 drivers/net/wireless/mediatek/mt76/mt7925/regd.c
286
287 int mt7925_regd_update(struct mt792x_phy *phy, char *alpha2)
288 {
289 struct wiphy *wiphy = phy->mt76->hw->wiphy;
290 struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
291 struct mt792x_dev *dev = mt792x_hw_dev(hw);
292 struct mt7925_regd_rule *mt7925_rule;
293 struct mt76_dev *mdev = &dev->mt76;
294 struct ieee80211_regdomain *regd;
295 struct ieee80211_reg_rule *rule;
296 struct mt7925_regd_rule_ev *ev;
297 int i, num_of_rules = 0;
298 struct sk_buff *skb;
299 int ret = 0;
300
301 if (dev->hw_full_reset)
302 return 0;
303
304 if (!MT7925_REGD_SUPPORTED(phy))
305 return -EOPNOTSUPP;
306
307 mt792x_mutex_acquire(dev);
308 skb = mt7925_regd_query_regdb(phy, alpha2);
309 mt792x_mutex_release(dev);
310
311 if (!skb)
312 return -EINVAL;
313
314 ev = (struct mt7925_regd_rule_ev *)(skb->data + 4);
315 num_of_rules = le32_to_cpu(ev->n_reg_rules);
316
317 if (!num_of_rules ||
318 WARN_ON_ONCE(num_of_rules > NL80211_MAX_SUPP_REG_RULES)) {
319 ret = -EINVAL;
320 goto err;
321 }
322
323 regd = kzalloc(struct_size(regd, reg_rules, num_of_rules), GFP_KERNEL);
324 if (!regd) {
325 ret = -ENOMEM;
326 goto err;
327 }
328
329 for (i = 0; i < num_of_rules; i++) {
330 mt7925_rule = &ev->reg_rule[i];
331 rule = ®d->reg_rules[i];
332
333 rule->freq_range.start_freq_khz =
334 MHZ_TO_KHZ(mt7925_rule->start_freq);
335 rule->freq_range.end_freq_khz =
336 MHZ_TO_KHZ(mt7925_rule->end_freq);
337 rule->freq_range.max_bandwidth_khz =
338 MHZ_TO_KHZ(mt7925_rule->max_bw);
339 /* not used by fw */
340 rule->power_rule.max_antenna_gain = DBI_TO_MBI(6);
341 rule->power_rule.max_eirp = DBM_TO_MBM(22);
342 rule->flags = mt7925_rule->flags;
343 }
344
345 regd->n_reg_rules = num_of_rules;
346 regd->dfs_region = ev->dfs_region;
347
348 memcpy(regd->alpha2, alpha2, 2);
349 memcpy(mdev->alpha2, alpha2, 2);
350
351 dev->regd_change = true;
352 mt7925_mcu_regd_update(dev, alpha2, ENVIRON_ANY);
353
354 ret = regulatory_set_wiphy_regd(wiphy, regd);
355
356 kfree(regd);
357 err:
358 dev_kfree_skb(skb);
359
360 if (ret < 0)
> 361 return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
362
363 return ret;
364 }
365 EXPORT_SYMBOL_GPL(mt7925_regd_update);
366
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Report extack error to the user if airoha_tc_htb_modify_queue() fails
From: Alexander Lobakin @ 2026-06-03 14:05 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260603-airoha_tc_htb_modify_queue-err-message-v1-1-33ec3ab997d9@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Wed, 03 Jun 2026 12:30:01 +0200
> Report an extack error message in airoha_tc_htb_modify_queue routine if
> airoha_qdma_set_tx_rate_limit() fails.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 6574901ebd19..d0d13f01e50f 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2605,13 +2605,19 @@ static int airoha_tc_htb_modify_queue(struct net_device *dev,
> {
> u32 channel = TC_H_MIN(opt->classid) % AIROHA_NUM_QOS_CHANNELS;
> u32 rate = div_u64(opt->rate, 1000) << 3; /* kbps */
> + int err;
>
> if (opt->parent_classid != TC_HTB_CLASSID_ROOT) {
> NL_SET_ERR_MSG_MOD(opt->extack, "invalid parent classid");
> return -EINVAL;
> }
>
> - return airoha_qdma_set_tx_rate_limit(dev, channel, rate, opt->quantum);
> + err = airoha_qdma_set_tx_rate_limit(dev, channel, rate, opt->quantum);
> + if (err)
> + NL_SET_ERR_MSG_MOD(opt->extack,
> + "failed configuring htb offload");
> +
> + return err;
> }
>
> static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Jonathan Cameron @ 2026-06-03 13:41 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay
Cc: rva333, David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260602-mt6323-adc-v1-2-68ec737508ee@protonmail.com>
On Tue, 02 Jun 2026 15:46:55 +0300
Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
> provides support for reading various channels including battery and
> charger voltages, battery and chip temperature, current sensing and
> accessory detection.
>
> Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
>
> Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Trivial stuff inline + a question from the sashiko bot you may have
missed.
Jonathan
> diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
> new file mode 100644
> index 000000000000..da6c11a5079c
> --- /dev/null
> +++ b/drivers/iio/adc/mt6323-auxadc.c
> @@ -0,0 +1,299 @@
> +static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
> + unsigned long channel)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
See below. Sashiko asked if lack of turning this off again when done
with a read is wasting power or similar.
> + if (ret)
> + return ret;
> +
> + ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
> + if (ret)
> + return ret;
> +
> + return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
> +}
> +
> +static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
> + const struct iio_chan_spec *chan, int *out)
> +{
> + struct regmap *map = auxadc->regmap;
> + u32 reg = chan->address;
It's only used one. I'd probably put it inline and skip the local variable.
> + u32 val;
> + int ret;
> +
> + ret = regmap_read_poll_timeout(map, reg, val, (val & AUXADC_READY_MASK),
> + 1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
> + if (ret)
> + return ret;
> +
> + *out = FIELD_GET(AUXADC_DATA_MASK, val);
> +
> + return 0;
> +}
> +
> +static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
> + int ret, mult;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + if (chan->channel == MT6323_AUXADC_ISENSE ||
> + chan->channel == MT6323_AUXADC_BATSNS)
> + mult = 4;
> + else
> + mult = 1;
> +
> + /* 1800mV full range with 15-bit resolution. */
> + *val = mult * 1800;
> + *val2 = 15;
> +
> + return IIO_VAL_FRACTIONAL_LOG2;
> + case IIO_CHAN_INFO_RAW:
> + scoped_guard(mutex, &auxadc->lock) {
> + ret = mt6323_auxadc_prepare_channel(auxadc);
> + if (ret)
> + return ret;
> +
> + ret = mt6323_auxadc_request(auxadc, chan->channel);
Sashiko asks:
"Does this leak power by leaving AUXADC_CON11_VBUF_EN enabled after the
reading finishes?
It appears the voltage buffer is enabled in mt6323_auxadc_request() but never
disabled once the conversion completes and exits here. Also, the active
channel is never cleared."
https://sashiko.dev/#/patchset/20260602-mt6323-adc-v1-0-68ec737508ee%40protonmail.com
Seems like a reasonable point.
> + if (ret)
> + return ret;
> +
> + /* Hardware limitation: the AUXADC needs a delay to become ready. */
> + fsleep(300);
> +
> + ret = mt6323_auxadc_read(auxadc, chan, val);
> + if (ret)
> + return ret;
> + }
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +static int mt6323_auxadc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mt6323_auxadc *auxadc;
> + struct iio_dev *iio;
> + struct regmap *regmap;
When no other particular ordering preference in IIO is for reverse xmas
tree.
> + int ret;
> +
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
> +
> + iio = devm_iio_device_alloc(dev, sizeof(*auxadc));
> + if (!iio)
> + return -ENOMEM;
> +
> + auxadc = iio_priv(iio);
> + auxadc->regmap = regmap;
> +
> + ret = devm_mutex_init(dev, &auxadc->lock);
> + if (ret)
> + return ret;
> +
> + ret = mt6323_auxadc_init(auxadc);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to initialize auxadc\n");
> +
> + iio->name = "mt6323-auxadc";
> + iio->info = &mt6323_auxadc_iio_info;
> + iio->modes = INDIO_DIRECT_MODE;
> + iio->channels = mt6323_auxadc_channels;
> + iio->num_channels = ARRAY_SIZE(mt6323_auxadc_channels);
> +
> + return devm_iio_device_register(dev, iio);
> +}
^ 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