* Re: [PATCH v8 3/3] drm/v3d: Introduce Runtime Power Management
From: Florian Fainelli @ 2026-03-30 18:46 UTC (permalink / raw)
To: Maíra Canal, Stefan Wahren, Maxime Ripard, Melissa Wen,
Iago Toral Quiroga, Dave Stevenson
Cc: dri-devel, linux-rpi-kernel, linux-arm-kernel,
Broadcom internal kernel review list, kernel-dev
In-Reply-To: <20260328-v3d-power-management-v8-3-94336830df5f@igalia.com>
On 3/28/26 11:52, Maíra Canal wrote:
> Commit 90a64adb0876 ("drm/v3d: Get rid of pm code") removed the last
> bits of power management code that V3D had, which were actually never
> hooked. Therefore, currently, the GPU clock is enabled during probe
> and only disabled when removing the driver.
>
> Implement proper power management using the kernel's Runtime PM
> framework.
>
> Reviewed-by: Melissa Wen <mwen@igalia.com>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
> ---
[snip]
> +static void
> +v3d_suspend_sms(struct v3d_dev *v3d)
> +{
> + if (v3d->ver < V3D_GEN_71)
> + return;
> +
> + V3D_SMS_WRITE(V3D_SMS_TEE_CS, V3D_SMS_POWER_OFF);
> +
> + if (wait_for((V3D_GET_FIELD(V3D_SMS_READ(V3D_SMS_TEE_CS),
> + V3D_SMS_STATE) == V3D_SMS_POWER_OFF_STATE), 100)) {
> + drm_err(&v3d->drm, "Failed to power off SMS\n");
> + }
We would certainly want to propagate any errors from wait_for() here to
ensure that we built appropriately timeout and get a chance at debugging.
Same for v3d_resume_sms().
--
Florian
^ permalink raw reply
* Re: [PATCH v1 0/2] perf build: Remove libunwind support
From: Arnaldo Carvalho de Melo @ 2026-03-30 18:49 UTC (permalink / raw)
To: Ian Rogers
Cc: Namhyung Kim, 9erthalion6, adrian.hunter, alex,
alexander.shishkin, andrew.jones, aou, atrajeev, blakejones,
ctshao, dapeng1.mi, howardchu95, james.clark, john.g.garry, jolsa,
leo.yan, libunwind-devel, linux-arm-kernel, linux-kernel,
linux-perf-users, linux-riscv, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will, amadio, yuzhuo
In-Reply-To: <acbxyzN4XKczgpLg@x1>
On Fri, Mar 27, 2026 at 06:08:27PM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Mar 27, 2026 at 01:37:20PM -0700, Ian Rogers wrote:
> > On Fri, Mar 27, 2026 at 1:07 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > This is an area that is tricky and since we _already_ have two
> > > implementations, the good thing for regression testing would be the
> > > compare their results until libunwind becomes completely rotten and
> > > unusable?
> >
> > My series:
> > https://lore.kernel.org/lkml/20260305221927.3237145-1-irogers@google.com/
> > makes libdw and libunwind supported together:
> > https://lore.kernel.org/lkml/20260305221927.3237145-2-irogers@google.com/
> > """
> > This commit refactors the DWARF unwind post-processing to be
> > configurable at runtime via the .perfconfig file option
> > 'unwind.style', or using the argument '--unwind-style' in the commands
> > 'perf report', 'perf script' and 'perf inject', in a similar manner to
> > the addr2line or the disassembler style.
> > """
> > That series cleans up several other issues, which is why I think it is
> > worth landing while we wait for libdw to become stable.
>
> Cool, I'll try and review/test it this weekend.
>
> Thanks for pointint it out!
Pointing, looking at it now, one comment so far, remove that new blank
line, testing...
⬢ [acme@toolbx perf-tools-next]$ git am ./v2_20260305_irogers_perf_libunwind_multiple_remote_support.mbx
Applying: perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
.git/rebase-apply/patch:128: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Applying: perf build loongarch: Remove reference to missing file
Applying: tools build: Deduplicate test-libunwind for different architectures
Applying: perf build: Be more programmatic when setting up libunwind variables
Applying: perf unwind-libunwind: Make libunwind register reading cross platform
Applying: perf unwind-libunwind: Move flush/finish access out of local
Applying: perf unwind-libunwind: Remove libunwind-local
Applying: perf unwind-libunwind: Add RISC-V libunwind support
⬢ [acme@toolbx perf-tools-next]$
^ permalink raw reply
* Re: [PATCH net V2 2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
From: Sean Anderson @ 2026-03-30 18:49 UTC (permalink / raw)
To: Suraj Gupta, Radhey Shyam Pandey, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Daniel Borkmann, Ariane Keller, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-3-suraj.gupta2@amd.com>
On 3/27/26 03:32, Suraj Gupta wrote:
> When a TX packet spans multiple buffer descriptors (scatter-gather),
> axienet_free_tx_chain sums the per-BD actual length from descriptor
> status into a caller-provided accumulator. That sum is reset on each
> NAPI poll. If the BDs for a single packet complete across different
> polls, the earlier bytes are lost and never credited to BQL. This
> causes BQL to think bytes are permanently in-flight, eventually
> stalling the TX queue.
>
> The SKB pointer is stored only on the last BD of a packet. When that
> BD completes, use skb->len for the byte count instead of summing
> per-BD status lengths. This matches netdev_sent_queue(), which debits
> skb->len, and naturally survives across polls because no partial
> packet contributes to the accumulator.
>
> Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL")
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index b06e4c37ff61..263c4b67fd5a 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -770,8 +770,8 @@ static int axienet_device_reset(struct net_device *ndev)
> * @first_bd: Index of first descriptor to clean up
> * @nr_bds: Max number of descriptors to clean up
> * @force: Whether to clean descriptors even if not complete
> - * @sizep: Pointer to a u32 filled with the total sum of all bytes
> - * in all cleaned-up descriptors. Ignored if NULL.
> + * @sizep: Pointer to a u32 accumulating the total byte count of
> + * completed packets (using skb->len). Ignored if NULL.
> * @budget: NAPI budget (use 0 when not called from NAPI poll)
> *
> * Would either be called after a successful transmit operation, or after
> @@ -805,6 +805,8 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
> DMA_TO_DEVICE);
>
> if (cur_p->skb && (status & XAXIDMA_BD_STS_COMPLETE_MASK)) {
> + if (sizep)
> + *sizep += cur_p->skb->len;
> napi_consume_skb(cur_p->skb, budget);
> packets++;
> }
> @@ -818,9 +820,6 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
> wmb();
> cur_p->cntrl = 0;
> cur_p->status = 0;
> -
> - if (sizep)
> - *sizep += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
> }
>
> if (!force) {
Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
Although FWIW this may result in slightly-different statistics. Not sure
if we care since this will only affect packets that could not be sent
for whatever reason (collisions, loss of carrier, etc.)
^ permalink raw reply
* [PATCH v2 0/4] usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
This series introduces support for the Multi-Media Integrated (MMI) USB
3.2 Dual-Role Device (DRD) controller on Xilinx Versal2 platforms.
The controller supports SSP(10-Gbps), SuperSpeed, high-speed, full-speed
and low-speed operation modes.
USB2 and USB3 PHY support Physical connectivity via the Type-C
connectivity. DWC3 wrapper IP IO space is in SLCR so reg is made
optional.
The driver is required for the clock, reset and platform specific
initialization (coherency/TX_DEEMPH etc). In this initial version typec
reversibility is not implemented and it is assumed that USB3 PHY TCA mux
programming is done by MMI configuration data object (CDOs) and TI PD
controller is configured using external tiva programmer on VEK385
evaluation board.
Changes for v2:
- DT binding: fix MHz spacing (SI convention), reorder description
before $ref in xlnx,usb-syscon, restore zynqmp-dwc3 example and add
versal2-mmi-dwc3 example, fix node name for no-reg case, use 1/1
address/size configuration and lowercase hex in syscon offsets.
- Split config struct refactoring (device_get_match_data,dwc3_xlnx_config)
into a separate preparatory patch.
- Fix error message capitalization to lowercase per kernel convention.
- Rename property snps,lcsr_tx_deemph to snps,lcsr-tx-deemph (hyphens).
- Fix double space in comment and missing blank line in core.h.
- Use platform data instead of of_device_is_compatible() check for
deemphasis support.
Link: https://lore.kernel.org/all/20251119193036.2666877-1-radhey.shyam.pandey@amd.com/
Radhey Shyam Pandey (4):
dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2
platform
usb: dwc3: xilinx: Introduce dwc3_xlnx_config for per-platform data
usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
usb: dwc3: xilinx: Add support to program MMI USB TX deemphasis
.../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++-
drivers/usb/dwc3/core.c | 17 ++++
drivers/usb/dwc3/core.h | 8 ++
drivers/usb/dwc3/dwc3-xilinx.c | 89 +++++++++++++++----
4 files changed, 166 insertions(+), 18 deletions(-)
base-commit: 46b513250491a7bfc97d98791dbe6a10bcc8129d
--
2.43.0
^ permalink raw reply
* [PATCH v2 2/4] usb: dwc3: xilinx: Introduce dwc3_xlnx_config for per-platform data
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Replace the direct pltfm_init function pointer in struct dwc3_xlnx with
a const pointer to a new struct dwc3_xlnx_config. This groups
per-platform configuration in one place and allows future patches to add
platform-specific fields (e.g. tx_deemph) without growing dwc3_xlnx.
While at it, switch from of_match_node() to device_get_match_data() to
simplify the match data lookup.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- New patch, split from "Add Versal2 MMI USB 3.2 controller support".
- Use device_get_match_data() instead of of_match_node().
---
drivers/usb/dwc3/dwc3-xilinx.c | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f41b0da5e89d..bb59b56726e7 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/dma-mapping.h>
#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
@@ -41,12 +42,18 @@
#define XLNX_USB_FPD_POWER_PRSNT 0x80
#define FPD_POWER_PRSNT_OPTION BIT(0)
+struct dwc3_xlnx;
+
+struct dwc3_xlnx_config {
+ int (*pltfm_init)(struct dwc3_xlnx *data);
+};
+
struct dwc3_xlnx {
int num_clocks;
struct clk_bulk_data *clks;
struct device *dev;
void __iomem *regs;
- int (*pltfm_init)(struct dwc3_xlnx *data);
+ const struct dwc3_xlnx_config *dwc3_config;
struct phy *usb3_phy;
};
@@ -241,14 +248,22 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
return ret;
}
+static const struct dwc3_xlnx_config zynqmp_config = {
+ .pltfm_init = dwc3_xlnx_init_zynqmp,
+};
+
+static const struct dwc3_xlnx_config versal_config = {
+ .pltfm_init = dwc3_xlnx_init_versal,
+};
+
static const struct of_device_id dwc3_xlnx_of_match[] = {
{
.compatible = "xlnx,zynqmp-dwc3",
- .data = &dwc3_xlnx_init_zynqmp,
+ .data = &zynqmp_config,
},
{
.compatible = "xlnx,versal-dwc3",
- .data = &dwc3_xlnx_init_versal,
+ .data = &versal_config,
},
{ /* Sentinel */ }
};
@@ -284,7 +299,6 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
struct dwc3_xlnx *priv_data;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- const struct of_device_id *match;
void __iomem *regs;
int ret;
@@ -296,9 +310,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
if (IS_ERR(regs))
return dev_err_probe(dev, PTR_ERR(regs), "failed to map registers\n");
- match = of_match_node(dwc3_xlnx_of_match, pdev->dev.of_node);
-
- priv_data->pltfm_init = match->data;
+ priv_data->dwc3_config = device_get_match_data(dev);
priv_data->regs = regs;
priv_data->dev = dev;
@@ -314,7 +326,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = priv_data->pltfm_init(priv_data);
+ ret = priv_data->dwc3_config->pltfm_init(priv_data);
if (ret)
goto err_clk_put;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Versal Gen2 platform multimedia integrated (MMI) module has a USB3.2 Gen
2x1 Dual Role Device IP. Introduce a new compatibility string to support
it. The USB wrapper registers reside in the MMI UDH system-level control
registers (SLCR) block, so instead of a dedicated reg property, add
xlnx,usb-syscon phandle with four cells specifying register offsets for
USB2 PHY, USB3 PHY, USB DRD, and USB power configuration within the SLCR.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Add blank line after compatible as suggested by Krzysztof.
- Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
IP from Synopsys is part of the dedicated Multimedia Interface. The
Versal Gen2 platform also includes a separate USB 2.0 controller,
and the mmi suffix uniquely distinguishes between the two USB
controllers. MMI is an independent subsystem particularly targeted for
deployment in Multi-Media related applications. The MMI block include
following submodules: UDH: USB3.2 Gen 2x1 Dual Role Device, DisplayPort
Transmit Controller, Security Module (ESM) for DisplayPort and HDMI
Controllers, DP AUX-I2C PHY.
- For MMI USB define parent address space i.e UDH block.
- Fix inconsistent MHz spacing to use SI convention with spaces.
- Move description before $ref and items in xlnx,usb-syscon property.
- Restore original zynqmp-dwc3 example, add new versal2-mmi-dwc3 example.
- Use 'usb' node name (without unit address) for versal2 example since
it has no reg property.
- Use 1/1 address/size configuration in versal2 example, use lowercase
hex in syscon offsets.
---
.../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++++++-
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
index d6823ef5f9a7..5e31b961aff7 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
@@ -15,6 +15,8 @@ properties:
- enum:
- xlnx,zynqmp-dwc3
- xlnx,versal-dwc3
+ - xlnx,versal2-mmi-dwc3
+
reg:
maxItems: 1
@@ -37,8 +39,9 @@ properties:
A list of phandle and clock-specifier pairs for the clocks
listed in clock-names.
items:
- - description: Master/Core clock, has to be >= 125 MHz
- for SS operation and >= 60MHz for HS operation.
+ - description: Master/Core clock, has to be >= 156.25 MHz in SSP
+ mode, >= 125 MHz for SS operation and >= 60 MHz for HS
+ operation.
- description: Clock source to core during PHY power down.
clock-names:
@@ -79,6 +82,20 @@ properties:
description: GPIO used for the reset ulpi-phy
maxItems: 1
+ xlnx,usb-syscon:
+ description:
+ Phandle to the MMI UDH system-level control register (SLCR) syscon
+ node, with four cells specifying the register offsets for USB2 PHY,
+ USB3 PHY, USB DRD, and USB power configuration respectively.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to MMI UDH SLCR syscon node
+ - description: USB2 PHY register offset within SLCR
+ - description: USB3 PHY register offset within SLCR
+ - description: USB DRD register offset within SLCR
+ - description: USB power register offset within SLCR
+
# Required child node:
patternProperties:
@@ -87,7 +104,6 @@ patternProperties:
required:
- compatible
- - reg
- "#address-cells"
- "#size-cells"
- ranges
@@ -104,6 +120,7 @@ allOf:
contains:
enum:
- xlnx,versal-dwc3
+ - xlnx,versal2-mmi-dwc3
then:
properties:
resets:
@@ -117,6 +134,26 @@ allOf:
reset-names:
minItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-dwc3
+ - xlnx,versal-dwc3
+ then:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: xlnx,versal2-mmi-dwc3
+ then:
+ required:
+ - xlnx,usb-syscon
+
additionalProperties: false
examples:
@@ -156,3 +193,30 @@ examples:
};
};
};
+ - |
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+ #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
+ #include <dt-bindings/phy/phy.h>
+ usb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,versal2-mmi-dwc3";
+ clocks = <&zynqmp_clk 32>, <&zynqmp_clk 34>;
+ clock-names = "bus_clk", "ref_clk";
+ power-domains = <&zynqmp_firmware PD_USB_0>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>;
+ reset-names = "usb_crst";
+ phys = <&psgtr 2 PHY_TYPE_USB3 0 2>;
+ phy-names = "usb3-phy";
+ xlnx,usb-syscon = <&udh_slcr 0x005c 0x0070 0x00c4 0x00f8>;
+ ranges;
+
+ usb@fe200000 {
+ compatible = "snps,dwc3";
+ reg = <0xfe200000 0x40000>;
+ interrupt-names = "host", "otg";
+ interrupts = <0 65 4>, <0 69 4>;
+ dr_mode = "host";
+ dma-coherent;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/4] usb: dwc3: xilinx: Add support to program MMI USB TX deemphasis
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Introduces support for programming the 18-bit TX Deemphasis value that
drives the pipe_TxDeemph signal, as defined in the PIPE4 specification.
The configured value is recommended by Synopsys and is intended for
standard (non-compliance) operation. These Gen2 equalization settings
have been validated through both internal and external compliance
testing. By applying this setting, the stability of USB 3.2 enumeration
is improved and now SuperSpeedPlus devices are consistently recognized as
USB 3.2 Gen 2 by the MMI USB Host controller.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Don't use compatible check for deemphasis programming.
- Rename property "snps,lcsr_tx_deemph" to "snps,lcsr-tx-deemph"
(hyphens per kernel convention).
- Fix double space in LCSR_TX_DEEMPH register comment.
- Add blank line between register offset define and "Bit fields" section.
---
drivers/usb/dwc3/core.c | 17 +++++++++++++++++
drivers/usb/dwc3/core.h | 8 ++++++++
drivers/usb/dwc3/dwc3-xilinx.c | 15 ++++++++++++---
3 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 161a4d58b2ce..e678a53a90b3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -646,6 +646,15 @@ static void dwc3_config_soc_bus(struct dwc3 *dwc)
reg |= DWC3_GSBUSCFG0_REQINFO(dwc->gsbuscfg0_reqinfo);
dwc3_writel(dwc, DWC3_GSBUSCFG0, reg);
}
+
+ if (dwc->csr_tx_deemph_field_1 != DWC3_LCSR_TX_DEEMPH_UNSPECIFIED) {
+ u32 reg;
+
+ reg = dwc3_readl(dwc, DWC3_LCSR_TX_DEEMPH);
+ reg &= ~DWC3_LCSR_TX_DEEMPH_MASK(~0);
+ reg |= DWC3_LCSR_TX_DEEMPH_MASK(dwc->csr_tx_deemph_field_1);
+ dwc3_writel(dwc, DWC3_LCSR_TX_DEEMPH, reg);
+ }
}
static int dwc3_core_ulpi_init(struct dwc3 *dwc)
@@ -1671,11 +1680,13 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
static void dwc3_get_software_properties(struct dwc3 *dwc,
const struct dwc3_properties *properties)
{
+ u32 csr_tx_deemph_field_1;
struct device *tmpdev;
u16 gsbuscfg0_reqinfo;
int ret;
dwc->gsbuscfg0_reqinfo = DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED;
+ dwc->csr_tx_deemph_field_1 = DWC3_LCSR_TX_DEEMPH_UNSPECIFIED;
if (properties->gsbuscfg0_reqinfo !=
DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED) {
@@ -1693,6 +1704,12 @@ static void dwc3_get_software_properties(struct dwc3 *dwc,
&gsbuscfg0_reqinfo);
if (!ret)
dwc->gsbuscfg0_reqinfo = gsbuscfg0_reqinfo;
+
+ ret = device_property_read_u32(tmpdev,
+ "snps,lcsr-tx-deemph",
+ &csr_tx_deemph_field_1);
+ if (!ret)
+ dwc->csr_tx_deemph_field_1 = csr_tx_deemph_field_1;
}
}
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index a35b3db1f9f3..99874ad09730 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -181,6 +181,8 @@
#define DWC3_LLUCTL(n) (0xd024 + ((n) * 0x80))
+#define DWC3_LCSR_TX_DEEMPH 0xd060
+
/* Bit fields */
/* Global SoC Bus Configuration INCRx Register 0 */
@@ -198,6 +200,10 @@
#define DWC3_GSBUSCFG0_REQINFO(n) (((n) & 0xffff) << 16)
#define DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED 0xffffffff
+/* LCSR_TX_DEEMPH Register: setting TX deemphasis used in normal operation in gen2 */
+#define DWC3_LCSR_TX_DEEMPH_MASK(n) ((n) & 0x3ffff)
+#define DWC3_LCSR_TX_DEEMPH_UNSPECIFIED 0xffffffff
+
/* Global Debug LSP MUX Select */
#define DWC3_GDBGLSPMUX_ENDBC BIT(15) /* Host only */
#define DWC3_GDBGLSPMUX_HOSTSELECT(n) ((n) & 0x3fff)
@@ -1180,6 +1186,7 @@ struct dwc3_glue_ops {
* @wakeup_pending_funcs: Indicates whether any interface has requested for
* function wakeup in bitmap format where bit position
* represents interface_id.
+ * @csr_tx_deemph_field_1: stores TX deemphasis used in Gen2 operation.
*/
struct dwc3 {
struct work_struct drd_work;
@@ -1417,6 +1424,7 @@ struct dwc3 {
struct dentry *debug_root;
u32 gsbuscfg0_reqinfo;
u32 wakeup_pending_funcs;
+ u32 csr_tx_deemph_field_1;
};
#define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f2dee28bdc65..44008856ee73 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -41,11 +41,13 @@
#define PIPE_CLK_SELECT 0
#define XLNX_USB_FPD_POWER_PRSNT 0x80
#define FPD_POWER_PRSNT_OPTION BIT(0)
+#define XLNX_MMI_USB_TX_DEEMPH_DEF 0x8c45
struct dwc3_xlnx;
struct dwc3_xlnx_config {
int (*pltfm_init)(struct dwc3_xlnx *data);
+ u32 tx_deemph;
bool map_resource;
};
@@ -284,6 +286,7 @@ static const struct dwc3_xlnx_config versal_config = {
static const struct dwc3_xlnx_config versal2_config = {
.pltfm_init = dwc3_xlnx_init_versal2,
+ .tx_deemph = XLNX_MMI_USB_TX_DEEMPH_DEF,
};
static const struct of_device_id dwc3_xlnx_of_match[] = {
@@ -303,10 +306,12 @@ static const struct of_device_id dwc3_xlnx_of_match[] = {
};
MODULE_DEVICE_TABLE(of, dwc3_xlnx_of_match);
-static int dwc3_set_swnode(struct device *dev)
+static int dwc3_set_swnode(struct dwc3_xlnx *priv_data)
{
+ struct device *dev = priv_data->dev;
+ const struct dwc3_xlnx_config *config = priv_data->dwc3_config;
struct device_node *np = dev->of_node, *dwc3_np;
- struct property_entry props[2];
+ struct property_entry props[3];
int prop_idx = 0, ret = 0;
dwc3_np = of_get_compatible_child(np, "snps,dwc3");
@@ -320,6 +325,10 @@ static int dwc3_set_swnode(struct device *dev)
if (of_dma_is_coherent(dwc3_np))
props[prop_idx++] = PROPERTY_ENTRY_U16("snps,gsbuscfg0-reqinfo",
0xffff);
+ if (config->tx_deemph)
+ props[prop_idx++] = PROPERTY_ENTRY_U32("snps,lcsr-tx-deemph",
+ config->tx_deemph);
+
of_node_put(dwc3_np);
if (prop_idx)
@@ -368,7 +377,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
if (ret)
goto err_clk_put;
- ret = dwc3_set_swnode(dev);
+ ret = dwc3_set_swnode(priv_data);
if (ret)
goto err_clk_put;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
From: Radhey Shyam Pandey @ 2026-03-30 19:03 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <20260330190304.1841593-1-radhey.shyam.pandey@amd.com>
Multi-media integrated (MMI) USB3.2 DRD IP is usb3.1 gen2 controller
which support following speed SSP (10-Gbps), SuperSpeed(5-Gbps),
high-speed(480-Mbps), full-speed(12-Mbps), and low-speed(1.5-Mbps)
operation modes.
USB2 and USB3 PHY support Physical connectivity via the Type-C
connectivity. The MMI USB controller does not have a dedicated wrapper
register space, so ioremap is skipped via the map_resource config flag.
The driver handles clock and reset initialization. In this initial
version typec reversibility is not implemented and it is assumed that
USB3 PHY TCA mux programming is done by MMI configuration data object
(CDOs) and TI PD controller is configured using external tiva programmer
on VEK385 evaluation board.
Tested host mode with mass storage device.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
- Introduce xlnx,usb-syscon phandle to access UDH address space
which is wrapper subsystem IP for USB, DP and HDCP.
- Split config struct refactoring into separate patch (2/4).
- Remove unused regmap/syscon fields and parsing code; defer to
patch that first consumes them.
- Fix error message capitalization to lowercase ("reset", "deassert").
---
drivers/usb/dwc3/dwc3-xilinx.c | 50 ++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index bb59b56726e7..f2dee28bdc65 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -46,6 +46,7 @@ struct dwc3_xlnx;
struct dwc3_xlnx_config {
int (*pltfm_init)(struct dwc3_xlnx *data);
+ bool map_resource;
};
struct dwc3_xlnx {
@@ -93,6 +94,29 @@ static void dwc3_xlnx_set_coherency(struct dwc3_xlnx *priv_data, u32 coherency_o
}
}
+static int dwc3_xlnx_init_versal2(struct dwc3_xlnx *priv_data)
+{
+ struct device *dev = priv_data->dev;
+ struct reset_control *crst;
+ int ret;
+
+ crst = devm_reset_control_get_optional_exclusive(dev, NULL);
+ if (IS_ERR(crst))
+ return dev_err_probe(dev, PTR_ERR(crst),
+ "failed to get reset signal\n");
+
+ /* assert and deassert reset */
+ ret = reset_control_assert(crst);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to assert reset\n");
+
+ ret = reset_control_deassert(crst);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to deassert reset\n");
+
+ return 0;
+}
+
static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
{
struct device *dev = priv_data->dev;
@@ -250,10 +274,16 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
static const struct dwc3_xlnx_config zynqmp_config = {
.pltfm_init = dwc3_xlnx_init_zynqmp,
+ .map_resource = true,
};
static const struct dwc3_xlnx_config versal_config = {
.pltfm_init = dwc3_xlnx_init_versal,
+ .map_resource = true,
+};
+
+static const struct dwc3_xlnx_config versal2_config = {
+ .pltfm_init = dwc3_xlnx_init_versal2,
};
static const struct of_device_id dwc3_xlnx_of_match[] = {
@@ -265,6 +295,10 @@ static const struct of_device_id dwc3_xlnx_of_match[] = {
.compatible = "xlnx,versal-dwc3",
.data = &versal_config,
},
+ {
+ .compatible = "xlnx,versal2-mmi-dwc3",
+ .data = &versal2_config,
+ },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(of, dwc3_xlnx_of_match);
@@ -299,19 +333,23 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
struct dwc3_xlnx *priv_data;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- void __iomem *regs;
int ret;
priv_data = devm_kzalloc(dev, sizeof(*priv_data), GFP_KERNEL);
if (!priv_data)
return -ENOMEM;
- regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(regs))
- return dev_err_probe(dev, PTR_ERR(regs), "failed to map registers\n");
-
priv_data->dwc3_config = device_get_match_data(dev);
- priv_data->regs = regs;
+
+ if (priv_data->dwc3_config->map_resource) {
+ void __iomem *regs;
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return dev_err_probe(dev, PTR_ERR(regs),
+ "failed to map registers\n");
+ priv_data->regs = regs;
+ }
priv_data->dev = dev;
platform_set_drvdata(pdev, priv_data);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net V2 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Sean Anderson @ 2026-03-30 19:09 UTC (permalink / raw)
To: Suraj Gupta, Radhey Shyam Pandey, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Daniel Borkmann, Ariane Keller, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-2-suraj.gupta2@amd.com>
On 3/27/26 03:32, Suraj Gupta wrote:
> The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
> macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
> product guide (PG021) specifies the buffer length field as bits 25:0
> (26 bits). Update both masks to match the IP documentation.
>
> In practice this had no functional impact, since Ethernet frames are
> far smaller than 2^23 bytes and the extra bits were always zero, but
> the masks should still reflect the hardware specification.
>
> Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
> drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> index 5ff742103beb..fcd3aaef27fc 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> @@ -105,7 +105,7 @@
> #define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
> #define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
>
> -#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
> +#define XAXIDMA_BD_CTRL_LENGTH_MASK GENMASK(25, 0) /* Requested len */
> #define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
> #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
> #define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
> @@ -130,7 +130,7 @@
> #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
> #define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
>
> -#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
> +#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK GENMASK(25, 0) /* Actual len */
> #define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
> #define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
> #define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Andy Shevchenko @ 2026-03-30 20:24 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-2-b68592e977d0@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
> Software nodes are currently initialized in a function registered as
> a postcore_initcall(). However, some devices may want to register
> software nodes earlier than that (or also in a postcore_initcall() where
> they're at the merci of the link order). Move the initialization to
> driver_init() making swnode available much earlier as well as making
> their initialization time deterministic.
...
> -static void __exit software_node_exit(void)
> -{
> - ida_destroy(&swnode_root_ids);
> - kset_unregister(swnode_kset);
> }
> -__exitcall(software_node_exit);
Why? What's wrong with the __exitcall?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 07/12] kbuild: Only run objtool if there is at least one command
From: Nicolas Schier @ 2026-03-30 18:49 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Herbert Xu
In-Reply-To: <zdipyf26t2gos5dw2gjyzmeg2zm5a67xwr5ozubnhmhllrwgnm@ezdt54coe2bk>
On Wed, Mar 18, 2026 at 05:49:27PM -0700, Josh Poimboeuf wrote:
> On Wed, Mar 18, 2026 at 08:54:31PM +0100, Nicolas Schier wrote:
> > On Tue, Mar 17, 2026 at 03:51:07PM -0700, Josh Poimboeuf wrote:
> > > Split the objtool args into commands and options, such that if no
> > > commands have been enabled, objtool doesn't run.
> > >
> > > This is in preparation in enabling objtool and klp-build for arm64.
> > >
> > > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > > Tested-by: Nathan Chancellor <nathan@kernel.org>
> > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > > ---
> > > arch/x86/boot/startup/Makefile | 2 +-
> > > scripts/Makefile.build | 4 +--
> > > scripts/Makefile.lib | 46 ++++++++++++++++++----------------
> > > scripts/Makefile.vmlinux_o | 15 ++++-------
> > > 4 files changed, 33 insertions(+), 34 deletions(-)
> > >
> > [...]
> > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > > index 3652b85be545..8a1bdfdb2fdb 100644
> > > --- a/scripts/Makefile.build
> > > +++ b/scripts/Makefile.build
> > > @@ -277,7 +277,7 @@ endif # CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT
> > > is-standard-object = $(if $(filter-out y%, $(OBJECT_FILES_NON_STANDARD_$(target-stem).o)$(OBJECT_FILES_NON_STANDARD)n),$(is-kernel-object))
> > >
> > > ifdef CONFIG_OBJTOOL
> > > -$(obj)/%.o: private objtool-enabled = $(if $(is-standard-object),$(if $(delay-objtool),$(is-single-obj-m),y))
> > > +$(obj)/%.o: private objtool-enabled = $(if $(is-standard-object),$(if $(objtool-cmds-y),$(if $(delay-objtool),$(is-single-obj-m),y)))
> >
> > Please use $(and a,b,c) instead of multiple nested $(if $(a),$(if
> > $(b),$(c)); as the last variable (is-single-obj-m) is 'y' or empty, the final 'y' can be
> > left-out:
> >
> > $(obj)/%.o: private objtool-enabled = $(and $(is-standard-object),$(objtool-cmds-y),$(delay-objtool),$(is-single-obj-m))
>
> I believe that would break the !delay-objtool case. The logic needs to
> be something like:
>
> if (is-standard-object && objtool-cmds-y) {
> if (delay-objtool) {
> // for delay-objtool, only enable objtool for single-object modules
> $(is-single-obj-m)
> } else {
> // for !delay-objtool, always enable objtool
> y
> }
> }
>
> so maybe something like this?
>
> $(obj)/%.o: private objtool-enabled = $(and $(is-standard-object),$(objtool-cmds-y),$(if $(delay-objtool),$(is-single-obj-m),y))
sorry for the delay! Yes, I overlooked the !delay-objtool. That line
looks good to me, thanks!
--
Nicolas
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Jon Hunter @ 2026-03-30 20:15 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Manivannan Sadhasivam, mark.rutland, bjorn.andersson,
konrad.dybcio, mani, linux-arm-kernel, linux-kernel,
Konrad Dybcio, Konrad Dybcio, Sudeep Holla,
linux-tegra@vger.kernel.org
In-Reply-To: <acJPHGIW1fb7whsu@lpieralisi>
Hi Lorenzo,
On 24/03/2026 08:45, Lorenzo Pieralisi wrote:
...
>>> I wanted to ask what the status of this patch is?
>>>
>>> It turns out that since commit f3ac2ff14834 ("PCI/ASPM: Enable all
>>> ClockPM and ASPM states for devicetree platforms"), this fix is also
>>> need for Tegra platforms that have NVMe devices to ensure that they are
>>> suspended as needed. There is some more background in this thread [0].
>>
>>
>> Any feedback on this? I am not sure if this patch is purposely being
>> ignored, but if so, I would like to understand why.
>
> It fell through the cracks, apologies.
No worries. Do you plan to pick this up?
Thanks
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v4 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
combo WiFi 7 + BT 5.4 module. The BT subsystem uses hardware variant
0x6639 and connects via USB.
The MT7927 is shipping in motherboards and PCIe add-in cards from ASUS,
Gigabyte, Lenovo, MSI, and TP-Link since mid-2024. Without these patches,
users see "Unsupported hardware variant (00006639)" or the BT subsystem
hangs during firmware download.
The series consists of eight patches:
[1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
[2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
[3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
[4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
[5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
[6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
[7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
[8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
Three driver changes are needed for MT6639 (patch 1):
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id. Force dev_id to 0x6639 only when the USB VID/PID
matches a known MT6639 device, avoiding misdetection if a future
chip also reads zero. This follows the WiFi-side pattern.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The firmware binary contains 9 sections, but only
sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending WiFi/other sections causes an irreversible BT subsystem hang.
Patch 2 fixes the ISO interface setup for devices that expose only a
single alternate setting (alt 0) on the ISO endpoint. Without this fix,
btmtk_usb_claim_iso_intf() fails with EINVAL, causing ~20 second
initialization delays on 13d3:3588 devices.
WBS (Wideband Speech) was verified on MT7927 hardware. The controller
reports LMP_TRANSPARENT, LMP_ERR_DATA_REPORTING, and mSBC codec support.
A btmon capture confirms eSCO links establish with Transparent air mode
(mSBC) and 60-byte frames. BTUSB_WIDEBAND_SPEECH is correct for this
controller family.
Tested on:
- ASUS ROG Crosshair X870E Hero (USB 0489:e13a)
- ASUS ROG STRIX X870E-E (USB 13d3:3588)
- ASUS ROG STRIX B850-E GAMING WIFI (USB 0489:e13a)
- Gigabyte Z790 AORUS MASTER X (USB 0489:e10f)
- Lenovo Legion Pro 7 16ARX9 (USB 0489:e0fa)
Changes in v4:
- Pass dev_id as parameter to btmtk_setup_firmware_79xx instead of
using hci_get_priv, which is not available in btmtksdio
(suggested by Luiz Augusto von Dentz)
- Skip post-reset CHIPID validation for 0x6639 in
btmtk_usb_subsys_reset since the register always returns 0x0000
on affected boards
Link to v3: https://lore.kernel.org/linux-bluetooth/20260326-mt7927-bt-support-v3-0-fa7ebd424323@jetm.me/
Signed-off-by: Javier Tia <floss@jetm.me>
---
Javier Tia (8):
Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
Bluetooth: btmtk: fix ISO interface setup for single alt setting
Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
drivers/bluetooth/btmtk.c | 63 ++++++++++++++++++++++++++++++++++++++-----
drivers/bluetooth/btmtk.h | 7 +++--
drivers/bluetooth/btmtksdio.c | 2 +-
drivers/bluetooth/btusb.c | 12 +++++++++
4 files changed, 75 insertions(+), 9 deletions(-)
---
base-commit: 7f9446b23ac77f46d356b354ea8da49113e8000d
change-id: 20260305-mt7927-bt-support-6589a50c961f
Best regards,
--
Javier Tia <floss@jetm.me>
^ permalink raw reply
* [PATCH v4 1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses
hardware variant 0x6639 for its Bluetooth subsystem. Without this patch,
the chip fails with "Unsupported hardware variant (00006639)" or hangs
during firmware download.
Three changes are needed to support MT6639:
1. CHIPID workaround: On some boards the BT USB MMIO register reads
0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
Force dev_id to 0x6639 only when the USB VID/PID matches a known
MT6639 device, avoiding misdetection if a future chip also reads
zero. This follows the WiFi-side pattern that uses PCI device IDs
to scope the same workaround.
2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
"1_1" used by MT7925 and other variants. The firmware path is
mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927
directory to match the WiFi firmware convention. The filename will
likely change to use MT7927 once MediaTek submits a dedicated
Linux firmware binary.
3. Section filtering: The MT6639 firmware binary contains 9 sections, but
only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
Sending the remaining WiFi/other sections causes an irreversible BT
subsystem hang requiring a full power cycle. This matches the Windows
driver behavior observed via USB captures.
Also add 0x6639 to the reset register (CONNV3) and firmware setup switch
cases alongside the existing 0x7925 handling.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/bluetooth/btmtk.c | 60 +++++++++++++++++++++++++++++++++++++++----
drivers/bluetooth/btmtk.h | 7 +++--
drivers/bluetooth/btmtksdio.c | 2 +-
3 files changed, 61 insertions(+), 8 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 2507d587f28a..4af19b86c551 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -25,6 +25,22 @@
/* It is for mt79xx iso data transmission setting */
#define MTK_ISO_THRESHOLD 264
+/* Known MT6639 (MT7927) Bluetooth USB devices.
+ * Used to scope the zero-CHIPID workaround to real MT6639 hardware,
+ * since some boards return 0x0000 from the MMIO chip ID register.
+ */
+static const struct {
+ u16 vendor;
+ u16 product;
+} btmtk_mt6639_devs[] = {
+ { 0x0489, 0xe13a }, /* ASUS ROG Crosshair X870E Hero */
+ { 0x0489, 0xe0fa }, /* Lenovo Legion Pro 7 16ARX9 */
+ { 0x0489, 0xe10f }, /* Gigabyte Z790 AORUS MASTER X */
+ { 0x0489, 0xe110 }, /* MSI X870E Ace Max */
+ { 0x0489, 0xe116 }, /* TP-Link Archer TBE550E */
+ { 0x13d3, 0x3588 }, /* ASUS ROG STRIX X870E-E */
+};
+
struct btmtk_patch_header {
u8 datetime[16];
u8 platform[4];
@@ -112,7 +128,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
u32 fw_flavor)
{
- if (dev_id == 0x7925)
+ if (dev_id == 0x6639)
+ snprintf(buf, size,
+ "mediatek/mt7927/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
+ dev_id & 0xffff, (fw_ver & 0xff) + 1);
+ else if (dev_id == 0x7925)
snprintf(buf, size,
"mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
@@ -128,7 +148,8 @@ void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
- wmt_cmd_sync_func_t wmt_cmd_sync)
+ wmt_cmd_sync_func_t wmt_cmd_sync,
+ u32 dev_id)
{
struct btmtk_hci_wmt_params wmt_params;
struct btmtk_patch_header *hdr;
@@ -166,6 +187,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
section_offset = le32_to_cpu(sectionmap->secoffset);
dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
+ /* MT6639: only download sections where dlmode byte0 == 0x01,
+ * matching the Windows driver behavior which skips WiFi/other
+ * sections that would cause the chip to hang.
+ */
+ if (dev_id == 0x6639 && dl_size > 0 &&
+ (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
+ continue;
+
if (dl_size > 0) {
retry = 20;
while (retry > 0) {
@@ -852,7 +881,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
if (err < 0)
return err;
msleep(100);
- } else if (dev_id == 0x7925) {
+ } else if (dev_id == 0x7925 || dev_id == 0x6639) {
err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
if (err < 0)
return err;
@@ -938,7 +967,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
}
err = btmtk_usb_id_get(hdev, 0x70010200, &val);
- if (err < 0 || !val)
+ if (err < 0 || (!val && dev_id != 0x6639))
bt_dev_err(hdev, "Can't get device id, subsys reset fail.");
return err;
@@ -1322,6 +1351,24 @@ int btmtk_usb_setup(struct hci_dev *hdev)
fw_flavor = (fw_flavor & 0x00000080) >> 7;
}
+ if (!dev_id) {
+ u16 vid = le16_to_cpu(btmtk_data->udev->descriptor.idVendor);
+ u16 pid = le16_to_cpu(btmtk_data->udev->descriptor.idProduct);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(btmtk_mt6639_devs); i++) {
+ if (vid == btmtk_mt6639_devs[i].vendor &&
+ pid == btmtk_mt6639_devs[i].product) {
+ dev_id = 0x6639;
+ break;
+ }
+ }
+
+ if (dev_id)
+ bt_dev_info(hdev, "MT6639: CHIPID=0x0000 with VID=%04x PID=%04x, using 0x6639",
+ vid, pid);
+ }
+
btmtk_data->dev_id = dev_id;
err = btmtk_register_coredump(hdev, btmtk_data->drv_name, fw_version);
@@ -1339,11 +1386,13 @@ int btmtk_usb_setup(struct hci_dev *hdev)
case 0x7925:
case 0x7961:
case 0x7902:
+ case 0x6639:
btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
fw_version, fw_flavor);
err = btmtk_setup_firmware_79xx(hdev, fw_bin_name,
- btmtk_usb_hci_wmt_sync);
+ btmtk_usb_hci_wmt_sync,
+ dev_id);
if (err < 0) {
/* retry once if setup firmware error */
if (!test_and_set_bit(BTMTK_FIRMWARE_DL_RETRY, &btmtk_data->flags))
@@ -1516,3 +1565,4 @@ MODULE_FIRMWARE(FIRMWARE_MT7668);
MODULE_FIRMWARE(FIRMWARE_MT7922);
MODULE_FIRMWARE(FIRMWARE_MT7961);
MODULE_FIRMWARE(FIRMWARE_MT7925);
+MODULE_FIRMWARE(FIRMWARE_MT7927);
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index adaf385626ee..c564aedc0ce0 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -8,6 +8,7 @@
#define FIRMWARE_MT7902 "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
#define FIRMWARE_MT7961 "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
#define FIRMWARE_MT7925 "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
+#define FIRMWARE_MT7927 "mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin"
#define HCI_EV_WMT 0xe4
#define HCI_WMT_MAX_EVENT_SIZE 64
@@ -189,7 +190,8 @@ typedef int (*wmt_cmd_sync_func_t)(struct hci_dev *,
int btmtk_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr);
int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
- wmt_cmd_sync_func_t wmt_cmd_sync);
+ wmt_cmd_sync_func_t wmt_cmd_sync,
+ u32 dev_id);
int btmtk_setup_firmware(struct hci_dev *hdev, const char *fwname,
wmt_cmd_sync_func_t wmt_cmd_sync);
@@ -228,7 +230,8 @@ static inline int btmtk_set_bdaddr(struct hci_dev *hdev,
static inline int btmtk_setup_firmware_79xx(struct hci_dev *hdev,
const char *fwname,
- wmt_cmd_sync_func_t wmt_cmd_sync)
+ wmt_cmd_sync_func_t wmt_cmd_sync,
+ u32 dev_id)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index 042064464d34..5b0fab7b89b5 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -883,7 +883,7 @@ static int mt79xx_setup(struct hci_dev *hdev, const char *fwname)
u8 param = 0x1;
int err;
- err = btmtk_setup_firmware_79xx(hdev, fwname, mtk_hci_wmt_sync);
+ err = btmtk_setup_firmware_79xx(hdev, fwname, mtk_hci_wmt_sync, 0);
if (err < 0) {
bt_dev_err(hdev, "Failed to setup 79xx firmware (%d)", err);
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/8] Bluetooth: btmtk: fix ISO interface setup for single alt setting
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on
ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a
single alternate setting (alt 0) on the ISO interface. The driver
unconditionally requests alt setting 1, which fails with EINVAL on
these devices, causing a ~20 second initialization delay and no LE
audio support.
Check the number of available alternate settings before selecting one.
If only alt 0 exists, use it; otherwise request alt 1 as before.
Closes: https://github.com/jetm/mediatek-mt7927-dkms/pull/39
Signed-off-by: Javier Tia <floss@jetm.me>
Reported-by: Ryan Gilbert <xelnaga@gmail.com>
Tested-by: Ryan Gilbert <xelnaga@gmail.com>
---
drivers/bluetooth/btmtk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 4af19b86c551..f8cff895f14c 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1029,7 +1029,8 @@ static int __set_mtk_intr_interface(struct hci_dev *hdev)
if (!btmtk_data->isopkt_intf)
return -ENODEV;
- err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM, 1);
+ err = usb_set_interface(btmtk_data->udev, MTK_ISO_IFNUM,
+ (intf->num_altsetting > 1) ? 1 : 0);
if (err < 0) {
bt_dev_err(hdev, "setting interface failed (%d)", -err);
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/8] Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jose Tiburcio Ribeiro Netto
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e13a (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the ASUS ROG Crosshair X870E
Hero WiFi motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e13a Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a5e44887a5b5..58309af0f7a2 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -751,6 +751,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe139), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe13a), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/8] Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Llewellyn Curran
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e0fa (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the Lenovo Legion Pro 7
16ARX9 laptop.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e0fa Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Llewellyn Curran <melinko2003@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 58309af0f7a2..2c9ca3d6016b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -753,6 +753,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe13a), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe0fa), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 5/8] Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Chapuis Dario, Evgeny Kapusta
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e10f (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the Gigabyte Z790 AORUS
MASTER X motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e10f Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2c9ca3d6016b..d60798331bb3 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -755,6 +755,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe0fa), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe10f), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 6/8] Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Nitin Gurram
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e110 (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the MSI X870E Ace Max
motherboard.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e110 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Nitin Gurram <nitin.reddy88@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d60798331bb3..96882e9b831c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -757,6 +757,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe10f), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe110), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 7/8] Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Thibaut FRANCOIS
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 0489:e116 (Foxconn/Hon Hai) for the MediaTek MT7927
(Filogic 380) Bluetooth interface found on the TP-Link Archer TBE550E
PCIe adapter.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e116 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
...
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Thibaut FRANCOIS <tibo@humeurlibre.fr>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 96882e9b831c..55a000540439 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -759,6 +759,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe110), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* [PATCH v4 8/8] Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Jose Tiburcio Ribeiro Netto, Ivan Lubnin
In-Reply-To: <20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me>
Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek
MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX
X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards.
Note: boards with this USB ID report only one ISO alternate setting
(alt 0), causing a non-fatal "setting interface failed (22)" during
setup. Bluetooth still functions but initialization takes ~19 seconds
instead of ~2.6 seconds.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3588 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927
Signed-off-by: Javier Tia <floss@jetm.me>
Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io>
Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 55a000540439..45ef0d008bce 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -761,6 +761,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe116), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3588), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14e), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0489, 0xe14f), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/8] Bluetooth: Add MediaTek MT7927 (MT6639) support
From: Javier Tia @ 2026-03-30 20:39 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Gilbert, Jose Tiburcio Ribeiro Netto, Llewellyn Curran,
Chapuis Dario, Evgeny Kapusta, Nitin Gurram, Thibaut FRANCOIS,
Ivan Lubnin
Hi Luiz,
Thank you for the review.
On Thu, Mar 27, 2026 Luiz Augusto von Dentz wrote:
> https://sashiko.dev/#/patchset/20260326-mt7927-bt-support-v3-0-fa7ebd424323%40jetm.me
>
> First one is more concerning since it may mean it can lead to crashes
> with SDIO driver, the other comment may actually need to be addressed
> separately, perhaps WBS handling needs to be fixed on this family of
> controllers.
Both issues are addressed in v4.
For the SDIO concern: btmtk_setup_firmware_79xx now takes dev_id
as a parameter instead of reading it from hci_get_priv. The SDIO
caller passes its own dev_id, so there is no out-of-bounds read
from a mismatched private struct layout.
For the subsys reset: btmtk_usb_subsys_reset now skips the
post-reset CHIPID validation for 0x6639. On affected boards the
register always reads back 0x0000, so the validation would always
fail. This is scoped to 0x6639 only.
Regarding WBS, I verified it on MT7927 hardware (ASUS ROG
Crosshair X870E Hero). The controller reports LMP_TRANSPARENT
and LMP_ERR_DATA_REPORTING in its LMP features, and
HCI_Read_Local_Supported_Codecs returns CVSD, Transparent, and
mSBC. A btmon capture confirms eSCO links establish with
Transparent air mode (0x03) and 60-byte mSBC frames. WBS works
correctly on this controller family, no fix needed.
Link to v4: https://lore.kernel.org/linux-bluetooth/20260330-mt7927-bt-support-v4-0-cecc025e7062@jetm.me/
Best,
Javier
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Bjorn Andersson @ 2026-03-30 20:48 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: mark.rutland, lpieralisi, bjorn.andersson, konrad.dybcio, mani,
linux-arm-kernel, linux-kernel, Konrad Dybcio, Konrad Dybcio,
Sudeep Holla
In-Reply-To: <20251231162126.7728-1-manivannan.sadhasivam@oss.qualcomm.com>
On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
> From: Konrad Dybcio <konradybcio@kernel.org>
>
> PSCI specification defines the SYSTEM_SUSPEND feature which enables the
> firmware to implement the suspend to RAM (S2RAM) functionality by
> transitioning the system to a deeper low power state. When the system
> enters such state, the power to the peripheral devices might be removed.
What is the actual extent of "peripheral devices" in this definition?
> So
> the respective device drivers must prepare for the possible removal of the
> power by performing actions such as shutting down or resetting the device
> in their system suspend callbacks.
>
Our typical interpretation of this state is that IP-blocks might be
non-functional during this time, but typically some state is retained.
Will the acceptance of this patch result in that we in the Qualcomm case
should start accepting/writing patches that implement save/restore of
state that is generally retained throughout the drivers - in the name of
"power might be removed"?
> The Linux PM framework allows the platform drivers to convey this info to
> device drivers by calling the pm_set_suspend_via_firmware() and
> pm_set_resume_via_firmware() APIs.
>
> Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
> mentioned APIs in the psci_system_suspend_begin() and
> psci_system_suspend_enter() callbacks.
>
With the right interpretation of what this means for us, I think this
patch looks good - but as we've discussed, I'm a bit worried about how
to deal with the alternative interpretations.
Specifically, if we fully adopt "power might be removed", we should to
take actions which will prevent a typical Qualcomm system from waking up
from sleep again.
Regards,
Bjorn
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> [mani: reworded the description to be more elaborative]
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>
> This patch was part of an old series that didn't make it to mainline due to
> objections in the binding and exposing CPU_SUSPEND as S2RAM patches:
> https://lore.kernel.org/all/20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com/
>
> But this patch on its own is useful for platforms implementing the S2RAM
> feature in PSCI firmware. So I picked it up, tested on Qcom X1E T14s and
> resending it.
>
> drivers/firmware/psci/psci.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 38ca190d4a22..e73bae6cb23a 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -539,12 +539,22 @@ static int psci_system_suspend(unsigned long unused)
>
> static int psci_system_suspend_enter(suspend_state_t state)
> {
> + pm_set_resume_via_firmware();
> +
> return cpu_suspend(0, psci_system_suspend);
> }
>
> +static int psci_system_suspend_begin(suspend_state_t state)
> +{
> + pm_set_suspend_via_firmware();
> +
> + return 0;
> +}
> +
> static const struct platform_suspend_ops psci_suspend_ops = {
> .valid = suspend_valid_only_mem,
> .enter = psci_system_suspend_enter,
> + .begin = psci_system_suspend_begin,
> };
>
> static void __init psci_init_system_reset2(void)
> --
> 2.48.1
>
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-rc5, upstream-arm-next, f97a8538)
From: cki-project @ 2026-03-30 20:53 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge branch 'devel/linus-uaccess' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2418826285
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* [PATCHv2] clk: kirkwood: use kzalloc_flex
From: Rosen Penev @ 2026-03-30 20:55 UTC (permalink / raw)
To: linux-clk
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Simplify allocation by using a flexible array member and kzalloc_flex to
combine allocations.
Add __counted_by for extra runtime analysis. Move counting variable
assignment to right after allocation as required by __counted_by.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: remove unused goto.
drivers/clk/mvebu/kirkwood.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
index ed061d82fb65..f4f62b241193 100644
--- a/drivers/clk/mvebu/kirkwood.c
+++ b/drivers/clk/mvebu/kirkwood.c
@@ -253,8 +253,8 @@ struct clk_muxing_soc_desc {
struct clk_muxing_ctrl {
spinlock_t *lock;
- struct clk **muxes;
int num_muxes;
+ struct clk *muxes[] __counted_by(num_muxes);
};
static const char *powersave_parents[] = {
@@ -297,21 +297,18 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
if (WARN_ON(!base))
return;
- ctrl = kzalloc_obj(*ctrl);
- if (WARN_ON(!ctrl))
- goto ctrl_out;
-
- /* lock must already be initialized */
- ctrl->lock = &ctrl_gating_lock;
-
/* Count, allocate, and register clock muxes */
for (n = 0; desc[n].name;)
n++;
+ ctrl = kzalloc_flex(*ctrl, muxes, n);
+ if (WARN_ON(!ctrl))
+ goto ctrl_out;
+
ctrl->num_muxes = n;
- ctrl->muxes = kzalloc_objs(struct clk *, ctrl->num_muxes);
- if (WARN_ON(!ctrl->muxes))
- goto muxes_out;
+
+ /* lock must already be initialized */
+ ctrl->lock = &ctrl_gating_lock;
for (n = 0; n < ctrl->num_muxes; n++) {
ctrl->muxes[n] = clk_register_mux(NULL, desc[n].name,
@@ -324,8 +321,6 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
of_clk_add_provider(np, clk_muxing_get_src, ctrl);
return;
-muxes_out:
- kfree(ctrl);
ctrl_out:
iounmap(base);
}
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox