* [PATCH v3 1/2] dt-bindings: clock: Add Amlogic A9 AO clock controller
From: Jian Hu via B4 Relay @ 2026-06-10 8:23 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl
Cc: linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel, Jian Hu, Conor Dooley
In-Reply-To: <20260610-a9_aoclk-v3-0-b7592d6c31e2@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Add the Always-On clock controller dt-bindings for the Amlogic A9
SoC family.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
.../bindings/clock/amlogic,a9-aoclkc.yaml | 76 ++++++++++++++++++++++
include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 ++++++++++++++++++++++
2 files changed, 152 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-aoclkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-aoclkc.yaml
new file mode 100644
index 000000000000..1fa9b3a32fbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,a9-aoclkc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2026 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,a9-aoclkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A9 Series Always-On Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Jian Hu <jian.hu@amlogic.com>
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+
+properties:
+ compatible:
+ const: amlogic,a9-aoclkc
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ minItems: 5
+ items:
+ - description: input oscillator
+ - description: input fclk div 3
+ - description: input fclk div 4
+ - description: input fclk div 5
+ - description: input sys clk
+ - description: external fixed 32k (optional)
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: xtal
+ - const: fdiv3
+ - const: fdiv4
+ - const: fdiv5
+ - const: sys
+ - const: ext_32k
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@0 {
+ compatible = "amlogic,a9-aoclkc";
+ reg = <0x0 0x0 0x0 0x58>;
+ #clock-cells = <1>;
+ clocks = <&xtal>,
+ <&scmi_clk 14>,
+ <&scmi_clk 16>,
+ <&scmi_clk 18>,
+ <&scmi_clk 21>;
+ clock-names = "xtal",
+ "fdiv3",
+ "fdiv4",
+ "fdiv5",
+ "sys";
+ };
+ };
diff --git a/include/dt-bindings/clock/amlogic,a9-aoclkc.h b/include/dt-bindings/clock/amlogic,a9-aoclkc.h
new file mode 100644
index 000000000000..a7d704d4b58e
--- /dev/null
+++ b/include/dt-bindings/clock/amlogic,a9-aoclkc.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2026 Amlogic, Inc. All rights reserved.
+ */
+
+#ifndef __AMLOGIC_A9_AO_CLKC_H
+#define __AMLOGIC_A9_AO_CLKC_H
+
+#define CLKID_AO_XTAL_IN 0
+#define CLKID_AO_XTAL 1
+#define CLKID_AO_SYS 2
+#define CLKID_AO_SYS_I3C 3
+#define CLKID_AO_SYS_RTC_REG 4
+#define CLKID_AO_SYS_CLKTREE 5
+#define CLKID_AO_SYS_RST_CTRL 6
+#define CLKID_AO_SYS_PAD 7
+#define CLKID_AO_SYS_RTC_DIG 8
+#define CLKID_AO_SYS_IRQ 9
+#define CLKID_AO_SYS_PWRCTRL 10
+#define CLKID_AO_SYS_PWM_A 11
+#define CLKID_AO_SYS_PWM_B 12
+#define CLKID_AO_SYS_PWM_C 13
+#define CLKID_AO_SYS_PWM_D 14
+#define CLKID_AO_SYS_PWM_E 15
+#define CLKID_AO_SYS_PWM_F 16
+#define CLKID_AO_SYS_PWM_G 17
+#define CLKID_AO_SYS_I2C_A 18
+#define CLKID_AO_SYS_I2C_B 19
+#define CLKID_AO_SYS_I2C_C 20
+#define CLKID_AO_SYS_I2C_D 21
+#define CLKID_AO_SYS_SED 22
+#define CLKID_AO_SYS_IR_CTRL 23
+#define CLKID_AO_SYS_UART_B 24
+#define CLKID_AO_SYS_UART_C 25
+#define CLKID_AO_SYS_UART_D 26
+#define CLKID_AO_SYS_UART_E 27
+#define CLKID_AO_SYS_SPISG_0 28
+#define CLKID_AO_SYS_RTC_SECURE 29
+#define CLKID_AO_SYS_CEC 30
+#define CLKID_AO_SYS_AOCPU 31
+#define CLKID_AO_SYS_SRAM 32
+#define CLKID_AO_SYS_SPISG_1 33
+#define CLKID_AO_SYS_SPISG_2 34
+#define CLKID_AO_PWM_A_SEL 35
+#define CLKID_AO_PWM_A_DIV 36
+#define CLKID_AO_PWM_A 37
+#define CLKID_AO_PWM_B_SEL 38
+#define CLKID_AO_PWM_B_DIV 39
+#define CLKID_AO_PWM_B 40
+#define CLKID_AO_PWM_C_SEL 41
+#define CLKID_AO_PWM_C_DIV 42
+#define CLKID_AO_PWM_C 43
+#define CLKID_AO_PWM_D_SEL 44
+#define CLKID_AO_PWM_D_DIV 45
+#define CLKID_AO_PWM_D 46
+#define CLKID_AO_PWM_E_SEL 47
+#define CLKID_AO_PWM_E_DIV 48
+#define CLKID_AO_PWM_E 49
+#define CLKID_AO_PWM_F_SEL 50
+#define CLKID_AO_PWM_F_DIV 51
+#define CLKID_AO_PWM_F 52
+#define CLKID_AO_PWM_G_SEL 53
+#define CLKID_AO_PWM_G_DIV 54
+#define CLKID_AO_PWM_G 55
+#define CLKID_AO_RTC_DUALDIV_IN 56
+#define CLKID_AO_RTC_DUALDIV_DIV 57
+#define CLKID_AO_RTC_DUALDIV_SEL 58
+#define CLKID_AO_RTC_DUALDIV 59
+#define CLKID_AO_RTC 60
+#define CLKID_AO_CEC_DUALDIV_IN 61
+#define CLKID_AO_CEC_DUALDIV_DIV 62
+#define CLKID_AO_CEC_DUALDIV_SEL 63
+#define CLKID_AO_CEC_DUALDIV 64
+#define CLKID_AO_CEC 65
+
+#endif /* __AMLOGIC_A9_AO_CLKC_H */
--
2.47.1
^ permalink raw reply related
* Re: [PATCH net-next v8 3/6] net: stmmac: eic7700: make RGMII delay properties optional
From: Maxime Chevallier @ 2026-06-10 8:26 UTC (permalink / raw)
To: lizhi2, devicetree, andrew+netdev, davem, edumazet, kuba, robh,
krzk+dt, conor+dt, netdev, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, pjw, palmer, aou, alex, linux-riscv,
linux-stm32, linux-arm-kernel, linux-kernel
Cc: ningyu, linmin, pinkesh.vaghela, pritesh.patel, weishangjuan,
horms, lee
In-Reply-To: <20260610012937.911-1-lizhi2@eswincomputing.com>
Hi,
On 6/10/26 03:29, lizhi2@eswincomputing.com wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> Make rx-internal-delay-ps and tx-internal-delay-ps optional in the
> EIC7700 DWMAC driver.
>
> The driver previously required both properties to be present and would
> fail probe when they were missing. This restricts valid hardware
> configurations where RGMII timing is instead provided by the PHY or
> board design.
>
> Update the driver to treat missing delay properties as zero delay,
> allowing systems without explicit MAC-side delay tuning to operate
> correctly.
>
> This aligns the driver behavior with the updated device tree binding
> and provides a safe default configuration when MAC-side delay
> programming is not required.
>
> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> index 4ac979d874d6..ec99b597aeaf 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> @@ -165,9 +165,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> dwc_priv->eth_clk_dly_param |=
> FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> - } else {
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "missing required property rx-internal-delay-ps\n");
> }
>
> /* Read tx-internal-delay-ps and update tx_clk delay */
> @@ -187,9 +184,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> dwc_priv->eth_clk_dly_param |=
> FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> - } else {
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "missing required property tx-internal-delay-ps\n");
> }
I think then you need to handle RGMII, RGMII_ID, RGMII_RXID and RGMII_TXID,
by using default delays for these (usually around 2ns), as here all delays
will be set to 0, regardless of the RGMII mode in use.
Maxime
>
> dwc_priv->eic7700_hsp_regmap =
^ permalink raw reply
* Re: [PATCH v1 13/26] s390: Introduce read/write ARM sysreg instructions
From: Steffen Eiden @ 2026-06-10 8:30 UTC (permalink / raw)
To: Janosch Frank
Cc: kvm, kvmarm, linux-arm-kernel, linux-kernel, linux-s390,
Alexander Gordeev, Andreas Grapentin, Arnd Bergmann,
Catalin Marinas, Christian Borntraeger, Claudio Imbrenda,
David Hildenbrand, Friedrich Welter, Gautam Gala, Hariharan Mari,
Heiko Carstens, Hendrik Brueckner, Ilya Leoshkevich, Joey Gouly,
Marc Zyngier, Nico Boehr, Nina Schoetterl-Glausch, Oliver Upton,
Paolo Bonzini, Suzuki K Poulose, Sven Schnelle, Ulrich Weigand,
Vasily Gorbik, Will Deacon, Zenghui Yu
In-Reply-To: <2d73aca5-1858-4a7a-a304-0971e4789dc1@linux.ibm.com>
On Tue, Jun 09, 2026 at 05:04:10PM +0200, Janosch Frank wrote:
> On 5/29/26 17:55, Steffen Eiden wrote:
> > Introduce Extract Arm System Register and Store Arm System Register to
> > enable s390 hosts to read and write system registers for arm64 guests.
> > The new instructions use the new RIE_H instruction format. Add assembler
> > macros to create instructions in RIE_H format manually. Add Support for
> > disassembling the new instructions.
> >
> > Co-developed-by: Andreas Grapentin <gra@linux.ibm.com>
> > Signed-off-by: Andreas Grapentin <gra@linux.ibm.com>
> > Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
> > ---
> > arch/s390/include/asm/sae-asm.h | 48 +++++++++++++++++++++++++++
> > arch/s390/include/asm/sae.h | 58 +++++++++++++++++++++++++++++++++
> > arch/s390/kernel/dis.c | 1 +
> > arch/s390/tools/opcodes.txt | 2 ++
> > 4 files changed, 109 insertions(+)
> > create mode 100644 arch/s390/include/asm/sae-asm.h
> >
...
> > diff --git a/arch/s390/include/asm/sae.h b/arch/s390/include/asm/sae.h
> > index fe010a1a7729..1d9a16b91b23 100644
> > --- a/arch/s390/include/asm/sae.h
> > +++ b/arch/s390/include/asm/sae.h
> > @@ -4,6 +4,7 @@
> > #include "linux/linkage.h"
> > #include <linux/types.h>
> > +#include <asm/sae-asm.h>
> > /* defined in arch/s390/kernel/entry.S */
> > asmlinkage int __sae64a(phys_addr_t sae_block_phys);
> > @@ -12,6 +13,12 @@ asmlinkage int __sae64a(phys_addr_t sae_block_phys);
> > #include <linux/io.h>
> > #include <asm/kvm_host_arm64_types.h>
> > +asm(".include \"asm/sae-asm.h\"\n");
> > +
> > +#define _SAE_ASR_REG_SHIFT 5
> > +#define SASR_FLAG_INITIALIZED 0x8
> > +#define EASR_FLAG_SA 0x8
>
> s/SA/SAVE_AREA/ or SAVEAREA
>
> I think both might fit.
yes, might be a good idea.
>
> > +
> > /**
> > * __sae64a() - Start Arm Execution
> > */
> > @@ -20,6 +27,57 @@ static inline void sae64a(struct kvm_sae_block *sae_block)
> > __sae64a(virt_to_phys(sae_block));
> > }
> > +/**
> > + * sasr() - Set Arm System Register
> > + * @arm_reg: ARM system register identifier; compile-time constant
> > + * @val: Value to set
> > + * @save_area: Pointer to SAE save area
> > + * @flags: Operation flags; compile-time constant
> > + *
> > + * Sets an ARM system register value.
> > + */
> > +static __always_inline void sasr(unsigned int arm_reg, u64 val,
> > + struct kvm_sae_save_area *save_area,
> > + u64 flags)
>
> m4 is 4 bits in length, any reason why we use a u64 here?
> Same for easr.
>
No real reason beside my preference of using u64 by default.
Do you want me to change it to u8?
Steffen
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
From: Krzysztof Kozlowski @ 2026-06-10 8:34 UTC (permalink / raw)
To: Liu Ying
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch
In-Reply-To: <aikYviBO1d560jdr@raspi>
On 10/06/2026 09:56, Liu Ying wrote:
> On Wed, Jun 10, 2026 at 09:46:39AM +0200, Krzysztof Kozlowski wrote:
>> On Mon, Jun 08, 2026 at 05:04:22PM +0800, Liu Ying wrote:
>>> i.MX93 SoC mediamix blk-ctrl contains one LDB_CTRL register and one LVDS
>>> register which control video output through a LVDS interface. Allow the
>>> LVDS Display Bridge(LDB) child node and add the child node to example.
>>>
>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>> ---
>>> .../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 ++++++++++++++++++++++
>>> 1 file changed, 39 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
>>> index d828c2e82965..124f5c206ee3 100644
>>> --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
>>> @@ -26,6 +26,12 @@ properties:
>>> reg:
>>> maxItems: 1
>>>
>>> + '#address-cells':
>>> + const: 1
>>> +
>>> + '#size-cells':
>>> + const: 1
>>> +
>>> '#power-domain-cells':
>>> const: 1
>>>
>>> @@ -92,6 +98,11 @@ properties:
>>> - compatible
>>> - ports
>>>
>>> + bridge@20:
>>
>> You have dpi-bridge, so this should not be different. You should not mix
>> addressable and non-addressable nodes and NXP decided recently in
>> 3feaa4342637eef673243dd38ccb32e8dc8efd5a that everything will be
>> non-addressable.
>>
>> Writing bindings ask explicitly to post bindings, so if you decide to do
>> half-baked solutions it's on you. Half baked solutions are not allowing
>> to bypass standard rules.
>
> Mixing addressable and non-addressable nodes is allowed according to recent
> discussion[1].
>
> [1] https://lore.kernel.org/all/n6akxiayi3g6gxcqhreb4iaohmeokoalnqup6h5r2fwdt4zijt@u2wyps55ayqm/
And it is explained in commit msg in... where exactly?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 01/16] device property: Add fwnode_graph_get_port_by_id()
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
In some cases the driver needs a reference to the port firmware node.
Once such case is the upcoming USB power sequencing integration. The
USB hub port is tied to the corresponding port firmware node if it
exists.
Provide a helper for this.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/base/property.c | 22 ++++++++++++++++++++++
include/linux/property.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 9387bb83eb54..a2afd854a604 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1346,6 +1346,28 @@ int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
}
EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
+/**
+ * fwnode_graph_get_port_by_id - get the port matching a given id
+ * @fwnode: parent fwnode_handle containing the graph
+ * @id: id of the port
+ *
+ * Return: A 'port' firmware node pointer with refcount incremented.
+ *
+ * The caller is responsible for calling fwnode_handle_put() on the returned
+ * fwnode pointer.
+ */
+struct fwnode_handle *fwnode_graph_get_port_by_id(struct fwnode_handle *fwnode, u32 id)
+{
+ struct fwnode_handle *ep;
+
+ ep = fwnode_graph_get_endpoint_by_id(fwnode, id, 0, FWNODE_GRAPH_ENDPOINT_NEXT);
+ if (!ep)
+ return NULL;
+
+ return fwnode_get_next_parent(ep);
+}
+EXPORT_SYMBOL_GPL(fwnode_graph_get_port_by_id);
+
const void *device_get_match_data(const struct device *dev)
{
return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data, dev);
diff --git a/include/linux/property.h b/include/linux/property.h
index e30ef23a9af3..11f3b54c7de0 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -499,6 +499,7 @@ int fwnode_get_phy_mode(const struct fwnode_handle *fwnode);
void __iomem *fwnode_iomap(struct fwnode_handle *fwnode, int index);
+struct fwnode_handle *fwnode_graph_get_port_by_id(struct fwnode_handle *fwnode, u32 id);
struct fwnode_handle *fwnode_graph_get_next_endpoint(
const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
struct fwnode_handle *
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 02/16] device property: Add fwnode_graph_get_next_port_endpoint()
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
Due to design constraints of the power sequencing API, the consumer
must first be sure that the other side is actually a provider, or it
will continually get -EPROBE_DEFER when requesting the power
sequencing descriptor.
In the upcoming USB power sequencing integration, the USB hub driver
first needs to check whether a graph connection exists, and whether
the other side of the connection is a supported connector type. The
USB port is tied to a "port" firmware node, and this new helper will
be used to get the endpoint under the known "port" firmware node.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/base/property.c | 33 +++++++++++++++++++++++++++++++++
include/linux/property.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index a2afd854a604..cf14f9b0a3e0 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1099,6 +1099,39 @@ int fwnode_irq_get_byname(const struct fwnode_handle *fwnode, const char *name)
}
EXPORT_SYMBOL(fwnode_irq_get_byname);
+/**
+ * fwnode_graph_get_next_port_endpoint - Get next endpoint firmware node in port
+ * @port: Pointer to the target port firmware node
+ * @prev: Previous endpoint node or %NULL to get the first
+ *
+ * The caller is responsible for calling fwnode_handle_put() on the returned
+ * fwnode pointer. Note that this function also puts a reference to @prev
+ * unconditionally.
+ *
+ * Return: an endpoint firmware node pointer or %NULL if no more endpoints
+ * are available.
+ */
+struct fwnode_handle *fwnode_graph_get_next_port_endpoint(const struct fwnode_handle *port,
+ struct fwnode_handle *prev)
+{
+ struct fwnode_handle *ep;
+
+ while (1) {
+ prev = fwnode_get_next_child_node(port, prev);
+ if (!prev)
+ break;
+
+ if (WARN(!fwnode_name_eq(prev, "endpoint"),
+ "non endpoint node is used (%pfw)", prev))
+ continue;
+
+ break;
+ }
+
+ return prev;
+}
+EXPORT_SYMBOL_GPL(fwnode_graph_get_next_port_endpoint);
+
/**
* fwnode_graph_get_next_endpoint - Get next endpoint firmware node
* @fwnode: Pointer to the parent firmware node
diff --git a/include/linux/property.h b/include/linux/property.h
index 11f3b54c7de0..2e744c6f251d 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -500,6 +500,8 @@ int fwnode_get_phy_mode(const struct fwnode_handle *fwnode);
void __iomem *fwnode_iomap(struct fwnode_handle *fwnode, int index);
struct fwnode_handle *fwnode_graph_get_port_by_id(struct fwnode_handle *fwnode, u32 id);
+struct fwnode_handle *fwnode_graph_get_next_port_endpoint(
+ const struct fwnode_handle *port, struct fwnode_handle *prev);
struct fwnode_handle *fwnode_graph_get_next_endpoint(
const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
struct fwnode_handle *
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 03/16] power: sequencing: Change CONFIG_POWER_SEQUENCING to bool
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
USB support, including the core and hub driver, is bool, no modules. To
be able to use the power sequencing API in the USB core, the former must
also be bool to avoid the latter being built as a module.
Change CONFIG_POWER_SEQUENCING to bool.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/power/sequencing/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index 1c5f5820f5b7..27448fba9dc5 100644
--- a/drivers/power/sequencing/Kconfig
+++ b/drivers/power/sequencing/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
menuconfig POWER_SEQUENCING
- tristate "Power Sequencing support"
+ bool "Power Sequencing support"
help
Say Y here to enable the Power Sequencing subsystem.
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 04/16] usb: hub: Return actual error from hub_configure() in hub_probe()
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The addition of power sequencing descriptor handling in the USB hub code
requires dealing with deferred probing from pwrseq_get(). The power
sequencing provider may not yet be available when the USB hub probes.
Return the actual error code from hub_configure() when it fails, so that
the driver core can notice the deferred probe request.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Moved "int ret" declaration in hub_configure() over here from the next
patch
---
drivers/usb/core/hub.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 13264e86bc6d..985551d013b2 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1874,6 +1874,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
struct usb_host_interface *desc;
struct usb_device *hdev;
struct usb_hub *hub;
+ int ret;
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -2005,14 +2006,15 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
usb_set_interface(hdev, 0, 0);
}
- if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) {
+ ret = hub_configure(hub, &desc->endpoint[0].desc);
+ if (ret >= 0) {
onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
return 0;
}
hub_disconnect(intf);
- return -ENODEV;
+ return ret;
}
static int
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
When a USB hub port is connected to a connector in a firmware node
graph, the port itself has a node in the graph.
Associate the port's firmware node with the USB port's device,
usb_port::dev. This is used in later changes for the M.2 slot power
sequencing provider to match against the requesting port.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/usb/core/port.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index b1364f0c384c..1846eb1206a4 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -780,6 +780,8 @@ int usb_hub_create_port_device(struct usb_hub *hub, int port1)
port_dev->dev.driver = &usb_port_driver;
dev_set_name(&port_dev->dev, "%s-port%d", dev_name(&hub->hdev->dev),
port1);
+ device_set_node(&port_dev->dev,
+ fwnode_graph_get_port_by_id(dev_fwnode(&hdev->dev), port1));
mutex_init(&port_dev->status_lock);
retval = device_register(&port_dev->dev);
if (retval) {
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 06/16] usb: hub: Pass |struct usb_port*| to usb_port_is_power_on()
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
usb_port_is_power_on() currently takes |struct usb_hub*|, but only needs
it to tell if the hub/port is SuperSpeed or not.
In a subsequent change, usb_port_is_power_on() needs access to a pwrseq
state tracking field in |struct usb_port|. Either structure can be used
to identify whether a port/hub is SuperSpeed or not, as the field in
|struct usb_port| is inherited from the hub:
port->is_superspeed = hub_is_superspeed(hub)
Replace usb_port_is_power_on()'s |struct usb_hub*| parameter with
|struct usb_port*| so a subsequent change can use it.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/usb/core/hub.c | 11 ++++++-----
drivers/usb/core/hub.h | 2 +-
drivers/usb/core/port.c | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 985551d013b2..362a10f7eddb 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3240,11 +3240,11 @@ static bool hub_port_stop_enumerate(struct usb_hub *hub, int port1, int retries)
}
/* Check if a port is power on */
-int usb_port_is_power_on(struct usb_hub *hub, unsigned int portstatus)
+int usb_port_is_power_on(struct usb_port *port, unsigned int portstatus)
{
int ret = 0;
- if (hub_is_superspeed(hub->hdev)) {
+ if (port->is_superspeed) {
if (portstatus & USB_SS_PORT_STAT_POWER)
ret = 1;
} else {
@@ -3306,7 +3306,7 @@ static int check_port_resume_type(struct usb_device *udev,
}
/* Is the device still present? */
else if (status || port_is_suspended(hub, portstatus) ||
- !usb_port_is_power_on(hub, portstatus)) {
+ !usb_port_is_power_on(port_dev, portstatus)) {
if (status >= 0)
status = -ENODEV;
} else if (!(portstatus & USB_PORT_STAT_CONNECTION)) {
@@ -3748,12 +3748,13 @@ static int wait_for_connected(struct usb_device *udev,
struct usb_hub *hub, int port1,
u16 *portchange, u16 *portstatus)
{
+ struct usb_port *port_dev = hub->ports[port1 - 1];
int status = 0, delay_ms = 0;
while (delay_ms < 2000) {
if (status || *portstatus & USB_PORT_STAT_CONNECTION)
break;
- if (!usb_port_is_power_on(hub, *portstatus)) {
+ if (!usb_port_is_power_on(port_dev, *portstatus)) {
status = -ENODEV;
break;
}
@@ -5449,7 +5450,7 @@ static void hub_port_connect(struct usb_hub *hub, int port1, u16 portstatus,
* but only if the port isn't owned by someone else.
*/
if (hub_is_port_power_switchable(hub)
- && !usb_port_is_power_on(hub, portstatus)
+ && !usb_port_is_power_on(port_dev, portstatus)
&& !port_dev->port_owner)
set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 9ebc5ef54a32..b65d9192379d 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -138,7 +138,7 @@ extern int usb_clear_port_feature(struct usb_device *hdev,
int port1, int feature);
extern int usb_hub_port_status(struct usb_hub *hub, int port1,
u16 *status, u16 *change);
-extern int usb_port_is_power_on(struct usb_hub *hub, unsigned int portstatus);
+extern int usb_port_is_power_on(struct usb_port *port, unsigned int portstatus);
static inline bool hub_is_port_power_switchable(struct usb_hub *hub)
{
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 1846eb1206a4..d9d3e2bb8f25 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -97,7 +97,7 @@ static ssize_t disable_show(struct device *dev,
}
usb_hub_port_status(hub, port1, &portstatus, &unused);
- disabled = !usb_port_is_power_on(hub, portstatus);
+ disabled = !usb_port_is_power_on(port_dev, portstatus);
out_hdev_lock:
usb_unlock_device(hdev);
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 07/16] usb: hub: Power on connected M.2 E-key connectors
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The new M.2 E-key connector can have a USB connection. For the USB device
on this connector to work, its power must be enabled and the W_DISABLE2#
signal deasserted. The connector driver handles this and provides a
toggle over the power sequencing API.
This feature currently only supports a directly connected (no mux in
between) M.2 E-key connector. Existing USB connector types are not
covered. The USB A connector was recently added to the onboard devices
driver. USB B connectors have historically been managed by the USB
gadget or dual-role device controller drivers. USB C connectors are
handled by TCPM drivers.
The power sequencing API does not know whether a power sequence provider
is not needed or not available yet, so we only request it for connectors
that we know need it, which at this time is just the E-key connector.
On the USB side, the port firmware node (if present) is tied to the
usb_port device. This device is used to acquire the power sequencing
descriptor. This allows the provider to tell the different ports on one
hub apart.
This feature is not implemented in the onboard USB devices driver. The
power sequencing API expects the consumer device to make the request,
but there is no device node to instantiate a platform device to tie
the driver to. The connector is not a child node of the USB host or
hub, and the graph connection is from a USB port to the connector.
And the connector itself already has a driver.
Power sequencing is not directly enabled in the connector driver as
that would completely decouple the timing of it from the USB subsystem.
It would not be possible for the USB subsystem to toggle the power
for a power cycle or to disable the port.
This change depends on another change to make the power sequencing
framework bool instead of tristate. The USB core and hub driver are
bool, so if the power sequencing framework is built as a module, the
kernel will fail to link.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Switch to fwnode instead of OF
- Tie port@ fwnode to usb_port device
- Move remote node compatible checking to separate helper
- Use usb_port device to request power sequencing descriptor
- Drop "index" parameter from pwrseq_get()
- Do not get pwrseq descriptor for SuperSpeed port; share one for one
physical port
- Add pwrseq state tracking
---
drivers/usb/core/hub.c | 38 ++++++++++++++++++++---
drivers/usb/core/hub.h | 4 +++
drivers/usb/core/port.c | 68 ++++++++++++++++++++++++++++++++++++++++-
3 files changed, 104 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 362a10f7eddb..9a9eb7e3e1fd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -32,6 +32,7 @@
#include <linux/mutex.h>
#include <linux/random.h>
#include <linux/pm_qos.h>
+#include <linux/pwrseq/consumer.h>
#include <linux/kobject.h>
#include <linux/bitfield.h>
@@ -886,20 +887,41 @@ static void hub_tt_work(struct work_struct *work)
int usb_hub_set_port_power(struct usb_device *hdev, struct usb_hub *hub,
int port1, bool set)
{
- int ret;
+ struct usb_port *pwrseq_port = hub->ports[port1 - 1];
+ int ret = 0;
+
+ /* non-SuperSpeed USB port holds pwrseq descriptor reference. */
+ if (hub->ports[port1 - 1]->is_superspeed && hub->ports[port1 - 1]->peer)
+ pwrseq_port = hub->ports[port1 - 1]->peer;
+
+ if (set && !pwrseq_port->pwrseq_on)
+ ret = pwrseq_power_on(pwrseq_port->pwrseq);
+ else if (!set && pwrseq_port->pwrseq_on)
+ ret = pwrseq_power_off(pwrseq_port->pwrseq);
+ if (ret)
+ return ret;
if (set)
ret = set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
else
ret = usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
- if (ret)
+ if (ret) {
+ if (set && !pwrseq_port->pwrseq_on)
+ pwrseq_power_off(pwrseq_port->pwrseq);
+ else if (!set && pwrseq_port->pwrseq_on)
+ pwrseq_power_on(pwrseq_port->pwrseq);
return ret;
+ }
- if (set)
+ if (set) {
set_bit(port1, hub->power_bits);
- else
+ pwrseq_port->pwrseq_on = 1;
+ } else {
clear_bit(port1, hub->power_bits);
+ pwrseq_port->pwrseq_on = 0;
+ }
+
return 0;
}
@@ -3252,7 +3274,13 @@ int usb_port_is_power_on(struct usb_port *port, unsigned int portstatus)
ret = 1;
}
- return ret;
+ if (port->is_superspeed && port->peer)
+ port = port->peer;
+
+ if (!port->pwrseq)
+ return ret;
+
+ return ret && port->pwrseq_on;
}
static void usb_lock_port(struct usb_port *port_dev)
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index b65d9192379d..a2ac91726c61 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -85,6 +85,7 @@ struct usb_hub {
* @port_owner: port's owner
* @peer: related usb2 and usb3 ports (share the same connector)
* @connector: USB Type-C connector
+ * @pwrseq: power sequencing descriptor for the port
* @req: default pm qos request for hubs without port power control
* @connect_type: port's connect type
* @state: device state of the usb device attached to the port
@@ -97,6 +98,7 @@ struct usb_hub {
* @usb3_lpm_u2_permit: whether USB3 U2 LPM is permitted.
* @early_stop: whether port initialization will be stopped earlier.
* @ignore_event: whether events of the port are ignored.
+ * @pwrseq_on: whether power sequencing is turned on.
*/
struct usb_port {
struct usb_device *child;
@@ -104,6 +106,7 @@ struct usb_port {
struct usb_dev_state *port_owner;
struct usb_port *peer;
struct typec_connector *connector;
+ struct pwrseq_desc *pwrseq;
struct dev_pm_qos_request *req;
enum usb_port_connect_type connect_type;
enum usb_device_state state;
@@ -118,6 +121,7 @@ struct usb_port {
unsigned int is_superspeed:1;
unsigned int usb3_lpm_u1_permit:1;
unsigned int usb3_lpm_u2_permit:1;
+ unsigned int pwrseq_on:1;
};
#define to_usb_port(_dev) \
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index d9d3e2bb8f25..a5e7fbf4aa6e 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -7,11 +7,14 @@
* Author: Lan Tianyu <tianyu.lan@intel.com>
*/
+#include <linux/cleanup.h>
#include <linux/kstrtox.h>
#include <linux/slab.h>
#include <linux/string_choices.h>
#include <linux/sysfs.h>
#include <linux/pm_qos.h>
+#include <linux/property.h>
+#include <linux/pwrseq/consumer.h>
#include <linux/component.h>
#include <linux/usb/of.h>
@@ -28,6 +31,9 @@ static bool usb_port_allow_power_off(struct usb_device *hdev,
if (hub_is_port_power_switchable(hub))
return true;
+ if (port_dev->pwrseq)
+ return true;
+
if (!IS_ENABLED(CONFIG_ACPI))
return false;
@@ -748,6 +754,43 @@ static const struct component_ops connector_ops = {
.unbind = connector_unbind,
};
+static bool port_pwrseq_is_supported(struct usb_port *port_dev)
+{
+ struct device *dev = &port_dev->dev;
+ struct fwnode_handle *port = dev->fwnode;
+ struct fwnode_handle *ep __free(fwnode_handle) =
+ fwnode_graph_get_next_port_endpoint(port, NULL);
+ if (!ep)
+ return false;
+
+ struct fwnode_handle *remote __free(fwnode_handle) =
+ fwnode_graph_get_remote_port_parent(ep);
+ if (!remote)
+ return false;
+
+ if (!fwnode_device_is_compatible(remote, "pcie-m2-e-connector")) {
+ dev_dbg(dev, "remote endpoint %pfw is not a supported connector", remote);
+ return false;
+ }
+
+ return true;
+}
+
+static struct pwrseq_desc *usb_hub_port_pwrseq_get(struct usb_port *port_dev)
+{
+ if (!IS_ENABLED(CONFIG_POWER_SEQUENCING))
+ return NULL;
+
+ /* A physical port should only have one pwrseq reference. */
+ if (port_dev->is_superspeed)
+ return NULL;
+
+ if (!port_pwrseq_is_supported(port_dev))
+ return NULL;
+
+ return pwrseq_get(&port_dev->dev, "usb");
+}
+
int usb_hub_create_port_device(struct usb_hub *hub, int port1)
{
struct usb_port *port_dev;
@@ -803,10 +846,25 @@ int usb_hub_create_port_device(struct usb_hub *hub, int port1)
goto err_put_kn;
}
+ port_dev->pwrseq = usb_hub_port_pwrseq_get(port_dev);
+ if (IS_ERR(port_dev->pwrseq)) {
+ retval = PTR_ERR(port_dev->pwrseq);
+ dev_err_probe(&port_dev->dev, retval,
+ "failed to get power sequencing descriptor\n");
+ goto err_put_kn;
+ }
+
+ retval = pwrseq_power_on(port_dev->pwrseq);
+ if (retval) {
+ dev_err_probe(&port_dev->dev, retval, "failed to enable power\n");
+ goto err_put_pwrseq;
+ }
+ port_dev->pwrseq_on = 1;
+
retval = component_add(&port_dev->dev, &connector_ops);
if (retval) {
dev_warn(&port_dev->dev, "failed to add component\n");
- goto err_put_kn;
+ goto err_pwrseq_off;
}
find_and_link_peer(hub, port1);
@@ -844,6 +902,11 @@ int usb_hub_create_port_device(struct usb_hub *hub, int port1)
}
return 0;
+err_pwrseq_off:
+ if (port_dev->pwrseq_on)
+ pwrseq_power_off(port_dev->pwrseq);
+err_put_pwrseq:
+ pwrseq_put(port_dev->pwrseq);
err_put_kn:
sysfs_put(port_dev->state_kn);
err_unregister:
@@ -860,6 +923,9 @@ void usb_hub_remove_port_device(struct usb_hub *hub, int port1)
peer = port_dev->peer;
if (peer)
unlink_peers(port_dev, peer);
+ if (port_dev->pwrseq_on)
+ pwrseq_power_off(port_dev->pwrseq);
+ pwrseq_put(port_dev->pwrseq);
component_del(&port_dev->dev, &connector_ops);
sysfs_put(port_dev->state_kn);
device_unregister(&port_dev->dev);
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 08/16] Revert "dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP"
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
This reverts commit 454a1e3cd36c113341d7b71e8e691c6e47ab4a8a.
mtk-xhci handles both USB 2.0 High Speed (HS) and USB 3.x SuperSpeed
(SS) host connections. And there are USB 2.0 only mtk-xhci blocks.
The SSUSB controller handles the device or gadget mode. Saying that
SSUSB handles the HS portion is wrong.
Fixes: 454a1e3cd36c ("dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP")
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 4 ----
1 file changed, 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index 231e6f35a986..75ecce3bdc7a 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -107,10 +107,6 @@ properties:
- description: USB3/SS(P) PHY
- description: USB2/HS PHY
- port:
- $ref: /schemas/graph.yaml#/properties/port
- description: Super Speed (SS) Output endpoint to a Type-C connector
-
vusb33-supply:
description: Regulator of USB AVDD3.3v
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 09/16] dt-bindings: usb: mediatek,mtk-xhci: Allow ports for USB connections
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
MediaTek's XHCI implementation supports both USB 2.0 High Speed (HS)
and USB 3.x Super Speed (SS). The block can also be synthesized with
either HS-only capability or HS+SS capability.
For example, on the MT8195, the first two instances support both HS and
SS, while the latter two instances support only HS.
Allow a ports sub-node for describing USB connections. Port 1 is Super
Speed if the controller is SS-capable, otherwise it is High Speed. Port
2 is High Speed if SS-capable. This port mapping scheme directly matches
what the hardware returns in its capability registers.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index 75ecce3bdc7a..d6c75bd20b78 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -184,6 +184,19 @@ properties:
"#size-cells":
const: 0
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) data bus if SS-capable;
+ otherwise High Speed (HS) data bus.
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: High Speed (HS) data bus if controller is SS-capable.
+
patternProperties:
"@[0-9a-f]{1}$":
type: object
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 10/16] power: sequencing: pcie-m2: support matching on remote "port" node
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
A USB hub can have multiple ports, and this driver needs to
differentiate which port is being matched to. The USB hub driver now
associates the "port" node with the usb_port device, so here we can
use the remote "port" node to check for a match. Then fall back to
the remote device node for the other connection types.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index e82821655fc4..49293376956b 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -176,8 +176,17 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
* parent matches the OF node of 'dev'.
*/
for_each_endpoint_of_node(ctx->of_node, endpoint) {
+ /* USB port devices are tied to the port nodes. */
+ struct device_node *remote_port __free(device_node) =
+ of_graph_get_remote_port(endpoint);
+
+ if (remote_port && remote_port == dev_of_node(dev))
+ return PWRSEQ_MATCH_OK;
+
+ /* Try the remote port parent for other types. */
struct device_node *remote __free(device_node) =
of_graph_get_remote_port_parent(endpoint);
+
if (remote && (remote == dev_of_node(dev)))
return PWRSEQ_MATCH_OK;
}
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 11/16] power: sequencing: pcie-m2: Add usb and sdio targets for E-key connector
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The M.2 E-key connector allows either PCIe or SDIO for WiFi and USB or
UART for BT. Currently the driver only supports PCIe and UART.
Add power sequencing targets for SDIO and USB. To avoid adding a
complicated dependency tree, rename the existing power sequencing units
"pcie" and "uart" to "wifi" and "bt". The existing target names are left
untouched. The new "sdio" and "usb" targets just point to the renamed
"wifi" and "bt" units.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 41 +++++++++++++++--------
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index 49293376956b..a21a3dbe8a5d 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -70,46 +70,46 @@ static const struct pwrseq_unit_data *pwrseq_pcie_m2_unit_deps[] = {
NULL
};
-static int pwrseq_pci_m2_e_uart_enable(struct pwrseq_device *pwrseq)
+static int pwrseq_pci_m2_e_bt_enable(struct pwrseq_device *pwrseq)
{
struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
return gpiod_set_value_cansleep(ctx->w_disable2_gpio, 0);
}
-static int pwrseq_pci_m2_e_uart_disable(struct pwrseq_device *pwrseq)
+static int pwrseq_pci_m2_e_bt_disable(struct pwrseq_device *pwrseq)
{
struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
return gpiod_set_value_cansleep(ctx->w_disable2_gpio, 1);
}
-static const struct pwrseq_unit_data pwrseq_pcie_m2_e_uart_unit_data = {
- .name = "uart-enable",
+static const struct pwrseq_unit_data pwrseq_pcie_m2_e_bt_unit_data = {
+ .name = "bt-enable",
.deps = pwrseq_pcie_m2_unit_deps,
- .enable = pwrseq_pci_m2_e_uart_enable,
- .disable = pwrseq_pci_m2_e_uart_disable,
+ .enable = pwrseq_pci_m2_e_bt_enable,
+ .disable = pwrseq_pci_m2_e_bt_disable,
};
-static int pwrseq_pci_m2_e_pcie_enable(struct pwrseq_device *pwrseq)
+static int pwrseq_pci_m2_e_wifi_enable(struct pwrseq_device *pwrseq)
{
struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
return gpiod_set_value_cansleep(ctx->w_disable1_gpio, 0);
}
-static int pwrseq_pci_m2_e_pcie_disable(struct pwrseq_device *pwrseq)
+static int pwrseq_pci_m2_e_wifi_disable(struct pwrseq_device *pwrseq)
{
struct pwrseq_pcie_m2_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
return gpiod_set_value_cansleep(ctx->w_disable1_gpio, 1);
}
-static const struct pwrseq_unit_data pwrseq_pcie_m2_e_pcie_unit_data = {
- .name = "pcie-enable",
+static const struct pwrseq_unit_data pwrseq_pcie_m2_e_wifi_unit_data = {
+ .name = "wifi-enable",
.deps = pwrseq_pcie_m2_unit_deps,
- .enable = pwrseq_pci_m2_e_pcie_enable,
- .disable = pwrseq_pci_m2_e_pcie_disable,
+ .enable = pwrseq_pci_m2_e_wifi_enable,
+ .disable = pwrseq_pci_m2_e_wifi_disable,
};
static const struct pwrseq_unit_data pwrseq_pcie_m2_m_pcie_unit_data = {
@@ -131,13 +131,24 @@ static int pwrseq_pcie_m2_e_pwup_delay(struct pwrseq_device *pwrseq)
static const struct pwrseq_target_data pwrseq_pcie_m2_e_uart_target_data = {
.name = "uart",
- .unit = &pwrseq_pcie_m2_e_uart_unit_data,
+ .unit = &pwrseq_pcie_m2_e_bt_unit_data,
.post_enable = pwrseq_pcie_m2_e_pwup_delay,
};
+static const struct pwrseq_target_data pwrseq_pcie_m2_e_usb_target_data = {
+ .name = "usb",
+ .unit = &pwrseq_pcie_m2_e_bt_unit_data,
+};
+
static const struct pwrseq_target_data pwrseq_pcie_m2_e_pcie_target_data = {
.name = "pcie",
- .unit = &pwrseq_pcie_m2_e_pcie_unit_data,
+ .unit = &pwrseq_pcie_m2_e_wifi_unit_data,
+ .post_enable = pwrseq_pcie_m2_e_pwup_delay,
+};
+
+static const struct pwrseq_target_data pwrseq_pcie_m2_e_sdio_target_data = {
+ .name = "sdio",
+ .unit = &pwrseq_pcie_m2_e_wifi_unit_data,
.post_enable = pwrseq_pcie_m2_e_pwup_delay,
};
@@ -148,7 +159,9 @@ static const struct pwrseq_target_data pwrseq_pcie_m2_m_pcie_target_data = {
static const struct pwrseq_target_data *pwrseq_pcie_m2_e_targets[] = {
&pwrseq_pcie_m2_e_pcie_target_data,
+ &pwrseq_pcie_m2_e_sdio_target_data,
&pwrseq_pcie_m2_e_uart_target_data,
+ &pwrseq_pcie_m2_e_usb_target_data,
NULL
};
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 12/16] arm64: dts: mediatek: mt8192-asurada: Add USB type-A connector
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The MT8192 Asurada design features a USB type-A connector for external
devices.
Add a proper representation for it with a node for the connector and
OF graph connection to the USB hub behind it.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../boot/dts/mediatek/mt8192-asurada.dtsi | 74 ++++++++++++++++++-
1 file changed, 71 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index b7387075cb87..fb4d92750770 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -292,6 +292,32 @@ sound: sound {
pinctrl-24 = <&aud_gpio_tdm_off_pins>;
pinctrl-25 = <&aud_gpio_tdm_on_pins>;
};
+
+ usb-a-connector {
+ compatible = "usb-a-connector";
+ vbus-supply = <&pp5000_a>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_a_u2_ep: endpoint {
+ remote-endpoint = <&usb2_hub_p3_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_a_u3_ep: endpoint {
+ remote-endpoint = <&usb3_hub_p3_ep>;
+ };
+ };
+ };
+ };
};
&afe {
@@ -1702,11 +1728,53 @@ &uart0 {
};
&xhci {
- status = "okay";
-
wakeup-source;
vusb33-supply = <&pp3300_g>;
- vbus-supply = <&pp5000_a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ usb3_hub: usb-hub@1 {
+ compatible = "usb5e3,620";
+ reg = <1>;
+ reset-gpios = <&pio 44 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&pp5000_a>;
+ peer-hub = <&usb2_hub>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ reg = <3>;
+
+ usb3_hub_p3_ep: endpoint {
+ remote-endpoint = <&usb_a_u3_ep>;
+ };
+ };
+ };
+ };
+
+ usb2_hub: usb-hub@2 {
+ compatible = "usb5e3,610";
+ reg = <2>;
+ reset-gpios = <&pio 44 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&pp5000_a>;
+ peer-hub = <&usb3_hub>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ reg = <3>;
+
+ usb2_hub_p3_ep: endpoint {
+ remote-endpoint = <&usb_a_u2_ep>;
+ };
+ };
+ };
+ };
};
#include <arm/cros-ec-keyboard.dtsi>
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 13/16] arm64: dts: mediatek: mt8192-asurada: Add M.2 E-key slot
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The MT8192 Asurada design features an M.2 E-key slot for WiFi/BT combo
cards. Only PCIe and USB are wired from the SoC to the slot, along with
some auxiliary signals.
Add the proper representation for it, replacing the PCIe wifi node and
vpcie3v3-supply property under the PCIe controller. Also clean up the
pcie controller node.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../boot/dts/mediatek/mt8192-asurada.dtsi | 65 +++++++++++++++++--
1 file changed, 58 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
index fb4d92750770..901240384a4a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
@@ -318,6 +318,41 @@ usb_a_u3_ep: endpoint {
};
};
};
+
+ wifi-bt-connector {
+ compatible = "pcie-m2-e-connector";
+ pinctrl-names = "default";
+ pinctrl-0 = <&m2_e_key_kill_pins>;
+ vpcie3v3-supply = <&pp3300_wlan>;
+ w-disable1-gpios = <&pio 61 GPIO_ACTIVE_LOW>;
+ w-disable2-gpios = <&pio 59 GPIO_ACTIVE_LOW>;
+ /* PCIe auxiliary signals wired to controller. */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* PCIe for WiFi */
+ port@0 {
+ reg = <0>;
+
+ wifi_ep: endpoint {
+ remote-endpoint = <&pcie_ep>;
+ };
+ };
+
+ /* USB for Bluetooth */
+ port@2 {
+ reg = <2>;
+
+ bt_ep: endpoint {
+ remote-endpoint = <&usb2_hub_p4_ep>;
+ };
+ };
+
+ /* SDIO, UART and I2S not implemented */
+ };
+ };
};
&afe {
@@ -671,19 +706,19 @@ &pcie {
pinctrl-0 = <&pcie_pins>;
memory-region = <&wifi_restricted_dma_region>;
- pcie0: pcie@0,0 {
+ pcie@0 {
+ compatible = "pciclass,0604";
+ reg = <0 0 0 0 0>;
device_type = "pci";
- reg = <0x0000 0 0 0 0>;
num-lanes = <1>;
- bus-range = <0x1 0x1>;
-
#address-cells = <3>;
#size-cells = <2>;
ranges;
- wifi: wifi@0,0 {
- reg = <0x10000 0 0 0 0x100000>,
- <0x10000 0 0x100000 0 0x100000>;
+ port {
+ pcie_ep: endpoint {
+ remote-endpoint = <&wifi_ep>;
+ };
};
};
};
@@ -1206,6 +1241,14 @@ pins-bus {
};
};
+ m2_e_key_kill_pins: m2-e-key-kill-pins {
+ pins-kill {
+ pinmux = <PINMUX_GPIO61__FUNC_GPIO61>,
+ <PINMUX_GPIO59__FUNC_GPIO59>;
+ output-high;
+ };
+ };
+
mmc0_default_pins: mmc0-default-pins {
pins-cmd-dat {
pinmux = <PINMUX_GPIO184__FUNC_MSDC0_DAT0>,
@@ -1773,6 +1816,14 @@ usb2_hub_p3_ep: endpoint {
remote-endpoint = <&usb_a_u2_ep>;
};
};
+
+ port@4 {
+ reg = <4>;
+
+ usb2_hub_p4_ep: endpoint {
+ remote-endpoint = <&bt_ep>;
+ };
+ };
};
};
};
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 14/16] arm64: dts: mediatek: mt8195-cherry: Add M.2 E-key slot
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The Mt8195 Cherry design features an M.2 E-key slot for WiFi/BT combo
cards. Only PCIe and USB are wired from the SoC to the slot, along with
some auxiliary signals.
Add the proper representation for it, replacing the PCIe wifi node and
vpcie3v3-supply property under the PCIe controller, and the vbus-supply
property under the xhci3 node.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../boot/dts/mediatek/mt8195-cherry.dtsi | 74 +++++++++++++++++--
1 file changed, 69 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index ef7afc436aef..c95a54de3567 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -266,6 +266,47 @@ tboard_thermistor2: thermal-sensor-t2 {
120000 51
125000 44>;
};
+
+ wifi-bt-connector {
+ compatible = "pcie-m2-e-connector";
+ pinctrl-names = "default";
+ pinctrl-0 = <&m2_e_key_kill_pins>;
+ vpcie3v3-supply = <&pp3300_wlan>;
+ w-disable1-gpios = <&pio 61 GPIO_ACTIVE_LOW>;
+ w-disable2-gpios = <&pio 59 GPIO_ACTIVE_LOW>;
+ /* PCIe auxiliary signals wired to controller. */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* PCIe for WiFi */
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wifi_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcie1_ep>;
+ };
+ };
+
+ /* USB for Bluetooth */
+ port@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bt_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usb3_ep>;
+ };
+ };
+
+ /* SDIO, UART and I2S not implemented */
+ };
+ };
};
&adsp {
@@ -791,14 +832,14 @@ pcie@0 {
reg = <0 0 0 0 0>;
device_type = "pci";
num-lanes = <1>;
- vpcie3v3-supply = <&pp3300_wlan>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
- wifi@0 {
- reg = <0 0 0 0 0>;
- wakeup-source;
+ port {
+ pcie1_ep: endpoint {
+ remote-endpoint = <&wifi_ep>;
+ };
};
};
};
@@ -1085,6 +1126,14 @@ pins-bus {
};
};
+ m2_e_key_kill_pins: m2-e-key-kill-pins {
+ pins-kill {
+ pinmux = <PINMUX_GPIO61__FUNC_GPIO61>,
+ <PINMUX_GPIO59__FUNC_GPIO59>;
+ output-high;
+ };
+ };
+
mmc0_pins_default: mmc0-default-pins {
pins-cmd-dat {
pinmux = <PINMUX_GPIO126__FUNC_MSDC0_DAT0>,
@@ -1637,9 +1686,24 @@ &xhci2 {
&xhci3 {
/* MT7921's USB Bluetooth has issues with USB2 LPM */
usb2-lpm-disable;
- vbus-supply = <&pp3300_wlan>;
vusb33-supply = <&mt6359_vusb_ldo_reg>;
status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb3_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&bt_ep>;
+ };
+ };
+ };
};
#include <arm/cros-ec-keyboard.dtsi>
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 15/16] arm64: dts: mediatek: mt8195-cherry: Add USB type-A connector
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The MT8195 Cherry design features a USB type-A connector for external
devices.
Add a proper representation for it with a node for the connector and
OF graph connection to the USB hub behind it.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../boot/dts/mediatek/mt8195-cherry.dtsi | 73 ++++++++++++++++++-
1 file changed, 70 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index c95a54de3567..8a21a8b996df 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -153,7 +153,6 @@ usb_vbus: regulator-5v0-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb-vbus";
enable-active-high;
- regulator-always-on;
vin-supply = <&pp5000_s5>;
};
@@ -267,6 +266,32 @@ tboard_thermistor2: thermal-sensor-t2 {
125000 44>;
};
+ usb-a-connector {
+ compatible = "usb-a-connector";
+ vbus-supply = <&usb_vbus>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_a_u2_ep: endpoint {
+ remote-endpoint = <&usb2_hub_p3_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_a_u3_ep: endpoint {
+ remote-endpoint = <&usb3_hub_p3_ep>;
+ };
+ };
+ };
+ };
+
wifi-bt-connector {
compatible = "pcie-m2-e-connector";
pinctrl-names = "default";
@@ -1672,13 +1697,55 @@ vdosys1_ep_ext: endpoint@1 {
&xhci0 {
rx-fifo-depth = <3072>;
- vbus-supply = <&usb_vbus>;
+ #address-cells = <1>;
+ #size-cells = <0>;
vusb33-supply = <&mt6359_vusb_ldo_reg>;
status = "okay";
+
+ usb3_hub: usb-hub@1 {
+ compatible = "usb5e3,620";
+ reg = <1>;
+ reset-gpios = <&pio 84 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&pp5000_s5>;
+ peer-hub = <&usb2_hub>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ reg = <3>;
+
+ usb3_hub_p3_ep: endpoint {
+ remote-endpoint = <&usb_a_u3_ep>;
+ };
+ };
+ };
+ };
+
+ usb2_hub: usb-hub@2 {
+ compatible = "usb5e3,610";
+ reg = <2>;
+ reset-gpios = <&pio 84 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&pp5000_s5>;
+ peer-hub = <&usb3_hub>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ reg = <3>;
+
+ usb2_hub_p3_ep: endpoint {
+ remote-endpoint = <&usb_a_u2_ep>;
+ };
+ };
+ };
+ };
};
&xhci2 {
- vbus-supply = <&usb_vbus>;
vusb33-supply = <&mt6359_vusb_ldo_reg>;
status = "okay";
};
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v2 16/16] arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-1-wenst@chromium.org>
The MT8188 Geralt design features a chip-on-board WiFi/BT solution. This
is a M.2 E-key WiFi/BT board layout directly inserted into the mainboard
design. The connections to the rest of the board are almost the same as
if it were a separate M.2 card. The only addition is the PMU_EN pin on
the chip; on M.2 cards this would be tied to the primary power source.
Model the chip-on-board WiFi/BT solution as a M.2 E-key slot with PCIe,
USB and auxiliary signals. The PMU_EN pin, which enables the internal
power controls and regulators, is modeled as a regulator fed by the
pp3300_wlan regulator. Since power sequencing is now correctly modeled
using the M.2 E-key slot, drop the "regulator-always-on" property one
pp3300_wlan regulator. Also drop the comment in xhci2 saying "MT7921's
power is controlled by PCIe".
Also drop the voltage range on the pp3300_wlan regulator. This
"regulator" is just a load switch and does not provide any regulation.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../boot/dts/mediatek/mt8188-geralt.dtsi | 93 ++++++++++++++++++-
1 file changed, 89 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
index f382f90c48f5..c4cc2cff1b5b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
@@ -86,13 +86,11 @@ pp3300_z1: regulator-pp3300-z1 {
pp3300_wlan: regulator-pp3300-wlan {
compatible = "regulator-fixed";
regulator-name = "pp3300_wlan";
- regulator-always-on;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
enable-active-high;
gpio = <&pio 12 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <&wlan_en>;
pinctrl-names = "default";
+ /* load switch */
vin-supply = <&pp3300_z1>;
};
@@ -159,6 +157,17 @@ ppvar_mipi_disp_avee: regulator-ppvar-mipi-disp-avee {
vin-supply = <&pp5000_z1>;
};
+ /* PMU_EN pin controls internal regulators and power sequence */
+ wlan_pmu: regulator-wlan-pmu {
+ compatible = "regulator-fixed";
+ regulator-name = "wlan-pmu";
+ enable-active-high;
+ gpio = <&pio 145 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&wlan_pmu_en>;
+ pinctrl-names = "default";
+ vin-supply = <&pp3300_wlan>;
+ };
+
reserved_memory: reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -193,6 +202,39 @@ adsp_dma_mem: memory@61000000 {
no-map;
};
};
+
+ wifi-bt-connector {
+ compatible = "pcie-m2-e-connector";
+ pinctrl-names = "default";
+ pinctrl-0 = <&m2_e_key_kill_pins>;
+ vpcie1v8-supply = <&mt6359_vcn18_ldo_reg>;
+ vpcie3v3-supply = <&wlan_pmu>;
+ w-disable1-gpios = <&pio 13 GPIO_ACTIVE_LOW>;
+ w-disable2-gpios = <&pio 14 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* PCIe for WiFi */
+ port@0 {
+ reg = <0>;
+
+ wifi_ep: endpoint {
+ remote-endpoint = <&pcie_ep>;
+ };
+ };
+
+ /* USB for Bluetooth */
+ port@2 {
+ reg = <2>;
+
+ bt_ep: endpoint {
+ remote-endpoint = <&usb2_ep>;
+ };
+ };
+ };
+ };
};
&adsp {
@@ -657,6 +699,22 @@ &pcie {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
status = "okay";
+
+ pcie@0 {
+ compatible = "pciclass,0604";
+ reg = <0 0 0 0 0>;
+ device_type = "pci";
+ num-lanes = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ port {
+ pcie_ep: endpoint {
+ remote-endpoint = <&wifi_ep>;
+ };
+ };
+ };
};
&pciephy {
@@ -1000,6 +1058,14 @@ pins-bus {
};
};
+ m2_e_key_kill_pins: m2-e-key-kill-pins {
+ pins-kill {
+ pinmux = <PINMUX_GPIO13__FUNC_B_GPIO13>,
+ <PINMUX_GPIO14__FUNC_B_GPIO14>;
+ output-high;
+ };
+ };
+
mipi_disp_avdd_en: mipi-disp-avdd-en-pins {
pins-en-ppvar-mipi-disp {
pinmux = <PINMUX_GPIO3__FUNC_B_GPIO3>;
@@ -1164,6 +1230,13 @@ pins-bus {
};
};
+ wlan_pmu_en: wlan-pmu-en-pins {
+ pins-wlan-pmu-en {
+ pinmux = <PINMUX_GPIO145__FUNC_B_GPIO145>;
+ output-low;
+ };
+ };
+
wlan_en: wlan-en-pins {
pins-en-pp3300-wlan {
pinmux = <PINMUX_GPIO12__FUNC_B_GPIO12>;
@@ -1343,10 +1416,22 @@ vdosys1_ep_ext: endpoint@1 {
};
&xhci2 {
- /* no power supply since MT7921's power is controlled by PCIe */
/* MT7921's USB BT has issues with USB2 LPM */
usb2-lpm-disable;
status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb2_ep: endpoint {
+ remote-endpoint = <&bt_ep>;
+ };
+ };
+ };
};
#include <arm/cros-ec-keyboard.dtsi>
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* Re: [PATCH 0/2] ARM: mstar: fix two device_node refcount leaks in mstarv7.c
From: Daniel Palmer @ 2026-06-10 8:45 UTC (permalink / raw)
To: Weigang He; +Cc: Romain Perier, Arnd Bergmann, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610053312.2267307-1-geoffreyhe2@gmail.com>
Hi Weigang,
On Wed, 10 Jun 2026 at 14:33, Weigang He <geoffreyhe2@gmail.com> wrote:
> Found by static analysis tool CodeQL. The series is build-tested only
> (arm, multi_v7_defconfig + CONFIG_ARCH_MSTARV7); I have no mstar
> hardware, so runtime testing would be appreciated.
I can build and boot test this but as far as I'm aware this is non-issue?
I have one device running this code stuck under a desk that has an
uptime over 3+ years now I think.
I guess maybe merge them just to stop another person from sending
another version of this?
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH v6 06/20] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-06-10 8:46 UTC (permalink / raw)
To: Petr Tesarik
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Jason Gunthorpe,
Mostafa Saleh, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <20260609144836.4ecea34e@mordecai>
Petr Tesarik <ptesarik@suse.com> writes:
> On Thu, 4 Jun 2026 14:09:45 +0530
> "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
>
...
>> /*
>> * If memory encryption is supported, phys_to_dma will set the memory encryption
>> * bit in the DMA address, and dma_to_phys will clear it.
>> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
>> index 29187cec90d8..4dcbf3931be1 100644
>> --- a/include/linux/swiotlb.h
>> +++ b/include/linux/swiotlb.h
>> @@ -81,6 +81,7 @@ struct io_tlb_pool {
>> struct list_head node;
>> struct rcu_head rcu;
>> bool transient;
>> + bool unencrypted;
>
> IIUC this is a copy of the unencrypted member in the corresponding
> struct io_tlb_mem. In other words, if pools are allocated dynamically,
> all pools must have the same encryption state, correct?
>
That is correct. The reason we have the unencrypted member in struct
io_tlb_pool is that we need it in swiotlb_dyn_free().
When freeing memory from an unencrypted pool, we need to convert the
memory back to private/encrypted
>
>> #endif
>> };
>>
>> @@ -111,6 +112,7 @@ struct io_tlb_mem {
>> struct dentry *debugfs;
>> bool force_bounce;
>> bool for_alloc;
>> + bool unencrypted;
>> #ifdef CONFIG_SWIOTLB_DYNAMIC
>> bool can_grow;
>> u64 phys_limit;
>> @@ -282,7 +284,8 @@ static inline void swiotlb_sync_single_for_cpu(struct device *dev,
>> extern void swiotlb_print_info(void);
....
>> @@ -604,30 +621,26 @@ static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes, u64 phys_limit)
>> * @dev: Device for which a memory pool is allocated.
>> * @bytes: Size of the buffer.
>> * @phys_limit: Maximum allowed physical address of the buffer.
>> + * @attrs: DMA attributes for the allocation.
>> * @gfp: GFP flags for the allocation.
>> *
>> * Return: Allocated pages, or %NULL on allocation failure.
>> */
>> static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
>> - u64 phys_limit, gfp_t gfp)
>> + u64 phys_limit, unsigned long attrs, gfp_t gfp)
>
> If my assumption above is correct, then I prefer to add a struct
> io_tlb_mem *mem parameter here and calculate the allocation attributes
> inside this function, so you don't have to repeat it in the callers.
>
Will switch to that. That is, we will use struct io_tlb_mem->unencrypted
to determine the pool attribute instead of using unsigned long attrs
>
>> {
>> struct page *page;
>> - unsigned long attrs = 0;
>>
>> /*
>> * Allocate from the atomic pools if memory is encrypted and
>> * the allocation is atomic, because decrypting may block.
>> */
>> - if (!gfpflags_allow_blocking(gfp) && dev && force_dma_unencrypted(dev)) {
>> + if (!gfpflags_allow_blocking(gfp) && (attrs & DMA_ATTR_CC_SHARED)) {
>
> You're removing the check that dev is non-NULL. This is fine, because
> the only call with dev == NULL is from swiotlb_dyn_alloc(), and that one
> uses GFP_KERNEL (i.e. allows blocking). However, if this is an intended
> optimization, I'd rather have it in a separate commit, with this
> explanation why it's OK to do it.
>
> The rest of the patch looks good to me.
>
I'll add that back.
-aneesh
^ permalink raw reply
* [PATCH v2 00/16] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Chen-Yu Tsai @ 2026-06-10 8:40 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, Chen-Yu Tsai, linux-acpi, driver-core, linux-pm,
linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam
Hi everyone,
This is v2 of my attempt at integrating the power sequencing API into
the USB core to support the USB connection on M.2 E-key slots. M.2
E-key was enabled in v7.1-rc1 with just PCIe and UART supported [1].
Major changes since v1:
- No longer adding the "index" parameter the power sequencing API
- Switched from OF graph to fwnode graph APIs
- Tie "port@" node to usb_port device, and use this device as consumer
to acquire power sequencing descriptor
- Power sequencing descriptor now only tied to USB 2.0 port to avoid
double reference
- Power sequencing state tracking added
- Link to v1
https://lore.kernel.org/all/20260515090149.3169406-1-wenst@chromium.org/
The series is based on next-20260608.
Patch 1 and 2 add new fwnode graph helpers. These are used by the patch
5 and 7, respectively.
Patch 3 changes the power sequencing framework's Kconfig symbol from
tristate to bool. This is needed as the USB core is bool. And since a
later patch introduces power sequencing API usage to the USB core, the
power sequencing framework cannot be built as a module anymore. This
patch needs to go in with "usb: hub: Power on connected M.2 E-key
connectors", or we will get allmodconfig build failures.
Patch 4 reworks the USB hub driver to return the actual error code from
hub_configure() in hub_probe(). This is needed in the next patch to
correctly return -EPROBE_DEFER returned by pwrseq_get() in patch 7.
Patch 5 makes the USB port device associated with a "port@" fwnode if
available. This depends on patch 1.
Patch 6 changes usb_port_is_power_on() so that |struct usb_port*| is
passed in instead of |struct usb_hub*|. This patch does not change any
functionality.
Patch 7 lets the USB hub driver look for power sequencers for each port.
Currently this only works for M.2 E-key connections, but it could be
extended to cover other cases. It should also make port reset via turning
off the port VBUS work, even when VBUS is not directly controlled by the
hub. This depends on patch 2 (for the new helper) and patch 3 (to avoid
allmodconfig link failures).
Patch 8 reverts an incorrectly modeled OF graph connection for the
MediaTek XHCI controller.
Patch 9 then adds a proper representation.
Patch 10 adds matching pwrseq consumer by "port@" node to the M.2 slot
driver. This is only used for the USB target, but there is no attempt
to differentiate the connection type. The driver simply tries matching
the "port@" node first, then falling back to the port parent or device's
node.
Patch 11 reworks the power sequencing targets for the E-key connector in
the pcie-m2 driver to add targets for USB and SDIO. The former is used
later on in this series.
Patches 12 through 16 enable the M.2 E-key slots (used for WiFi/BT) and
USB type-A connectors found on MediaTek-based Chromebooks. These are
provided in this series for reference. The USB type-A connector changes,
while not directly related, have overlapping context, and was easier to
include. They were also used to test some extra local changes I tried
to convert the USB A connector from an onboard USB device to a power
sequencing provider.
This series unfortunately spans multiple trees. The way I see it:
- Patch 1 and 2 go through the driver core, and an immutable tag is
provided to be merged together with the USB patches.
- Patch 3 gets an ack from Bartosz, and goes through the USB tree.
- Patch 4 through 9 (all the USB related ones) go through the USB
tree, along with the dependencies above.
- Patch 10 and 11 go through the power sequencing tree.
- Patch 12 through 16 (device tree only) go through the soc tree via
the mediatek tree.
Some of us discussed v1 at Embedded Recipes, and I believe Bartosz, Mani
and I agree on this approach. The debate is likely going to be on
whether this should be integrated into the USB core or not. I believe it
should, so that the power sequencing timing is tied to the USB port
being brought up. I do have a fallback option of just enabling the USB
power sequencing target inside the M.2 slot driver if a valid OF graph
connection is seen. But this is less desired for the reason given above.
Please have a look and share your thoughts.
Thanks
ChenYu
[1] https://lore.kernel.org/all/20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com/
Chen-Yu Tsai (16):
device property: Add fwnode_graph_get_port_by_id()
device property: Add fwnode_graph_get_next_port_endpoint()
power: sequencing: Change CONFIG_POWER_SEQUENCING to bool
usb: hub: Return actual error from hub_configure() in hub_probe()
usb: hub: Associate port@ fwnode with USB port device
usb: hub: Pass |struct usb_port*| to usb_port_is_power_on()
usb: hub: Power on connected M.2 E-key connectors
Revert "dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed
EP"
dt-bindings: usb: mediatek,mtk-xhci: Allow ports for USB connections
power: sequencing: pcie-m2: support matching on remote "port" node
power: sequencing: pcie-m2: Add usb and sdio targets for E-key
connector
arm64: dts: mediatek: mt8192-asurada: Add USB type-A connector
arm64: dts: mediatek: mt8192-asurada: Add M.2 E-key slot
arm64: dts: mediatek: mt8195-cherry: Add M.2 E-key slot
arm64: dts: mediatek: mt8195-cherry: Add USB type-A connector
arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot
.../bindings/usb/mediatek,mtk-xhci.yaml | 17 +-
.../boot/dts/mediatek/mt8188-geralt.dtsi | 93 ++++++++++-
.../boot/dts/mediatek/mt8192-asurada.dtsi | 139 +++++++++++++++--
.../boot/dts/mediatek/mt8195-cherry.dtsi | 147 +++++++++++++++++-
drivers/base/property.c | 55 +++++++
drivers/power/sequencing/Kconfig | 2 +-
drivers/power/sequencing/pwrseq-pcie-m2.c | 50 ++++--
drivers/usb/core/hub.c | 55 +++++--
drivers/usb/core/hub.h | 6 +-
drivers/usb/core/port.c | 72 ++++++++-
include/linux/property.h | 3 +
11 files changed, 583 insertions(+), 56 deletions(-)
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
From: Sergey Senozhatsky @ 2026-06-10 8:51 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen
Cc: Sean Wang, Tomasz Figa, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, stable, Sergey Senozhatsky
In-Reply-To: <20260609121329.1262170-1-senozhatsky@chromium.org>
On (26/06/09 21:10), Sergey Senozhatsky wrote:
> Every once in a while we see a hung btmtksdio_flush() task:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> It all boils down to incorrect time_is_before_jiffies() usage in
> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
> to be terminated if running for longer than 5*HZ. However the
> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
> means that:
> - before the 5-second timeout: the condition is `int_status || false`,
> so it loops as long as there are pending interrupts.
> - after the 5-second timeout: the condition becomes `int_status || true`,
> which is always true.
>
> When the loop becomes infinite btmtksdio_txrx_work() loop never
> terminates and never releases the SDIO host.
>
> Fix loop termination condition to actually enforce a 5*HZ timeout.
Please hold off this patch, this change alone might not be enough.
Let us look closer into it, we'll come back you.
^ permalink raw reply
* [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Pragnesh Papaniya @ 2026-06-10 8:51 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sibi Sankar, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Dmitry Osipenko, Thierry Reding, Jonathan Hunter,
Bjorn Andersson, Konrad Dybcio
Cc: Pragnesh Papaniya, Rajendra Nayak, Pankaj Patil, linux-arm-msm,
linux-kernel, arm-scmi, linux-arm-kernel, devicetree, linux-pm,
linux-tegra, Amir Vajid, Ramakrishna Gottimukkula
The QCOM SCMI vendor protocol provides a generic way of exposing a number of
Qualcomm SoC specific features (like memory bus scaling) through a mixture of
pre-determined algorithm strings and param_id pairs hosted on the SCMI
controller. On Qualcomm Glymur and Hamoa SoCs, the memlat governor and the
mechanism to control the various caches and RAM is hosted on the CPU Control
Processor (CPUCP) and the method to tweak and start the governor is exposed
through the QCOM SCMI Generic Extension Protocol.
This series introduces the devfreq SCMI client driver that uses the MEMLAT
algorithm string hosted on the QCOM SCMI Generic Extension Protocol to detect
memory latency workloads and control frequency/level of the various memory
buses (DDR/LLCC/DDR_QOS). DDR/LLCC/DDR_QOS are modelled as devfreq devices
using the remote devfreq governor. This provides basic insight into device
operation via trans_stat and lets userspace further tweak the parameters of
the remote governor.
trans_stat data for DDR/LLCC/DDR_QOS is now available with this series:
From : To
315000000 479000000 545000000 725000000 840000000 959000000 1090000000 1211000000 time(ms)
315000000: 0 3 6 6 6 7 0 30 143956
479000000: 2 0 7 1 1 1 0 3 356
545000000: 7 6 0 5 5 0 0 10 1200
725000000: 3 0 5 0 6 1 0 6 2172
840000000: 8 2 3 2 0 4 0 12 1188
959000000: 3 0 1 2 2 0 0 13 272
1090000000: 0 0 0 0 0 0 0 0 0
1211000000: 35 4 11 5 11 8 0 0 21684
Total transition : 253
QCOM SCMI Generic Vendor protocol background:
A lot of the vendor protocol numbers used internally were for
debug/internal development purposes that were either highly SoC-specific
or had to be disabled because some features were fused out during
production. This led to a large number of vendor protocol numbers being
quickly consumed and never released. Using a single generic vendor
protocol with functionality abstracted behind algorithm strings gives us
the flexibility of letting such functionality exist during initial
development/debugging while still being able to expose mature features
(like MEMLAT) once they have stabilised. The param_ids are expected to
act as ABI for algorithm strings like MEMLAT.
Thanks in advance for taking time to review the series.
Changes in v7:
- Minor bug fixes and documentation improvements based on review feedback.
- Significantly expand the QCOM Generic Vendor Protocol documentation
with a dedicated MEMLAT section covering all param_ids, payloads and
return values [Sudeep, Cristian].
- Move per-SoC event IDs and hardware type identifiers from the driver
into the platform configuration header.
- Poll devfreq at twice the CPUCP sampling rate so every firmware voting
cycle is reliably observed [Lukasz].
- Add a devicetree binding schema for the Qualcomm SCMI vendor
protocol@80 node.
- Link to v6: https://lore.kernel.org/r/20260507062237.78051-1-sibi.sankar@oss.qualcomm.com
Changes in v6:
- Combining vendor protocol and the client and moving it
back into RFC mode.
- Introduce target_freq attr flag and TRACK_REMOTE devfreq
governor flag.
- Add basic remote devfreq governor to give users data like
transtat [Dmitry]
- Drop the current design that relies on manual parsing of
device tree data and move those into SoC specific structs
- Add Glymur/Mahua/Hamoa/Purwa support in the same series.
- Link to v5: https://lore.kernel.org/lkml/20241115011515.1313447-1-quic_sibis@quicinc.com/
Changes in v5:
- Splitting the series into vendor protocol and memlat client.
- Also the move the memlat client implementation back to RFC
due to multiple opens.
- Use common xfer helper to avoid code duplication [Dmitry]
- Update enum documentation without duplicate enum info [Dmitry]
- Update the protol attributes doc with more information. [Cristian]
- Link to v4: https://lore.kernel.org/lkml/20241007061023.1978380-1-quic_sibis@quicinc.com/
Changes in v4:
- Restructure the bindings to mimic IMX [Christian]
- Add documentation for the qcom generic vendor protocol [Christian/Sudeep]
- Pick up Rb tag and fixup/re-order elements of the vendor ops [Christian]
- Follow naming convention and folder structure used by IMX
- Add missing enum in the vendor protocol and fix documentation [Konrad]
- Add missing enum in the scmi memlat driver and fix documentation [Konrad]
- Add checks for max memory and monitor [Shivnandan]
- Fix typo from START_TIMER -> STOP_TIMER [Shivnandan]
- Make populate_physical_mask func to void [Shivnandan]
- Remove unecessary zero set [Shivnandan]
- Use __free(device node) in init_cpufreq-memfreqmap [Christian/Konrad]
- Use sdev->dev.of_node directly [Christian]
- use return dev_err_probe in multiple places [Christian]
- Link to v3: https://lore.kernel.org/lkml/20240702191440.2161623-1-quic_sibis@quicinc.com/
Changes in v3:
- Drop container dvfs memlat container node. [Rob]
- Move scmi-memlat.yaml to protocol level given that a lot of vendors might end up
- using the same protocol number. [Rob]
- Replace qcom,cpulist with the standard "cpus" property. [Rob]
- Fix up compute-type/ipm-ceil required. [Rob]
- Make driver changes to the accommodate bindings changes. [Rob]
- Minor fixups in subjects/coverletter.
- Minor style fixes in dts.
- Link to v2: https://lore.kernel.org/lkml/20240612183031.219906-1-quic_sibis@quicinc.com/
Changes in v2:
- Add missing bindings for the protocol. [Konrad/Dmitry]
- Use alternate bindings. [Dmitry/Konrad]
- Rebase on top of Cristian's "SCMI multiple vendor protocol support" series. [Cristian]
- Add more documentation wherever possible. [Sudeep]
- Replace pr_err/info with it's dev equivalents.
- Mixed tabs and initialization cleanups in the memlat driver. [Konrad]
- Commit message update for the memlat driver. [Dmitry]
- Cleanups/Fixes suggested for the client driver. [Dmitry/Konrad/Cristian]
- Use opp-tables instead of memfreq-tbl. [Dmitry/Konrad]
- Detect physical cpu to deal with variants with reduced cpu count.
- Add support for DDR_QOS mem_type.
- Link to v1: https://lore.kernel.org/lkml/20240117173458.2312669-1-quic_sibis@quicinc.com/
Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
---
Pragnesh Papaniya (1):
dt-bindings: firmware: arm,scmi: Add Qualcomm Generic Extension Protocol
Sibi Sankar (8):
firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation
firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions
PM / devfreq: Add new target_freq attribute flag for governors
PM / devfreq: Add new track_remote flag for governors
PM / devfreq: Add a governor for tracking remote device frequencies
PM / devfreq: Introduce the QCOM SCMI Memlat devfreq driver
arm64: dts: qcom: glymur: Enable LLCC/DDR/DDR_QOS DVFS
arm64: dts: qcom: hamoa: Enable LLCC/DDR/DDR_QOS DVFS
Documentation/ABI/testing/sysfs-class-devfreq | 8 +
.../devicetree/bindings/firmware/arm,scmi.yaml | 1 +
.../bindings/firmware/qcom,generic-scmi.yaml | 27 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 41 ++
arch/arm64/boot/dts/qcom/hamoa.dtsi | 4 +
drivers/devfreq/Kconfig | 21 +
drivers/devfreq/Makefile | 2 +
drivers/devfreq/devfreq.c | 27 +
drivers/devfreq/governor_passive.c | 1 +
drivers/devfreq/governor_performance.c | 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_remote.c | 73 +++
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
drivers/devfreq/hisi_uncore_freq.c | 1 +
drivers/devfreq/scmi-qcom-memlat-cfg.h | 573 ++++++++++++++++++
drivers/devfreq/scmi-qcom-memlat-devfreq.c | 616 ++++++++++++++++++++
drivers/devfreq/tegra30-devfreq.c | 3 +-
drivers/firmware/arm_scmi/Kconfig | 1 +
drivers/firmware/arm_scmi/Makefile | 1 +
drivers/firmware/arm_scmi/vendors/qcom/Kconfig | 15 +
drivers/firmware/arm_scmi/vendors/qcom/Makefile | 2 +
.../arm_scmi/vendors/qcom/qcom-generic-ext.c | 153 +++++
.../arm_scmi/vendors/qcom/qcom_generic.rst | 647 +++++++++++++++++++++
include/linux/devfreq-governor.h | 8 +
include/linux/devfreq.h | 1 +
include/linux/scmi_qcom_protocol.h | 37 ++
27 files changed, 2266 insertions(+), 1 deletion(-)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260610-rfc_v7_scmi_memlat-3d3d0c0896d4
Best regards,
--
Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
^ 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