* Re: [PATCH v3 6/8] arm64: dts: qcom: shikra-cqm-evk: Enable A704 GPU
From: Dmitry Baryshkov @ 2026-06-28 22:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-6-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:53:59PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Enable the A704 GPU and configure its zap-shader firmware on the
> Shikra CQM EVK board.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: dts: qcom: shikra-cqs-evk: Enable A704 GPU
From: Dmitry Baryshkov @ 2026-06-28 22:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-7-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:54:00PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Enable the A704 GPU and configure its zap-shader firmware on the
> Shikra CQS EVK board.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: am62p5-var-som-symphony: add touchscreen support
From: Stefano Radaelli @ 2026-06-28 20:56 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1782680023.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add support for the capacitive touchscreen on the Symphony carrier
board.
Describe the FT5x06 touchscreen controller, configure its interrupt,
and mark it as a wakeup source.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Fix commit message
.../dts/ti/k3-am62p5-var-som-symphony.dts | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts b/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
index 5ba4ed56755b..5c41647ff43f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-var-som-symphony.dts
@@ -293,6 +293,21 @@ &main_i2c1 {
clock-frequency = <400000>;
status = "okay";
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_captouch_pins>;
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ wakeup-source;
+ };
+
rtc@68 {
compatible = "dallas,ds1337";
reg = <0x68>;
@@ -307,6 +322,12 @@ &main_mcan0 {
};
&main_pmx0 {
+ pinctrl_captouch_pins: main-captouch-default-pins {
+ pinctrl-single,pins = <
+ AM62PX_IOPAD(0x01b8, PIN_INPUT, 7) /* (E20) SPI0_CS1.GPIO1_16 */
+ >;
+ };
+
pinctrl_extcon: main-extcon-pins {
pinctrl-single,pins = <
AM62PX_IOPAD(0x01a8, PIN_INPUT, 7) /* (F25) MCASP0_AFSX.GPIO1_12 */
--
2.47.3
^ permalink raw reply related
* [PATCH 0/4] ARM: dts: helios4: add regulator supplies and thermal cooling
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
This series adds missing vcc-supply properties to the EEPROM and GPIO
expander on the Helios4, adds SATA regulator supplies, and wires the
on-board LM75 temperature sensor into a thermal zone with active fan
cooling.
Rosen Penev (4):
ARM: dts: helios4: add vcc-supply to EEPROM
ARM: dts: helios4: add vcc-supply to GPIO expander
ARM: dts: helios4: add SATA regulator supplies
ARM: dts: helios4: wire LM75 into a thermal zone with fan cooling
.../boot/dts/marvell/armada-388-helios4.dts | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
--
2.54.0
^ permalink raw reply
* [PATCH 1/4] ARM: dts: helios4: add vcc-supply to EEPROM
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The at24 driver requests a 'vcc' supply for the EEPROM, producing
'supply vcc not found, using dummy regulator' at boot when the
property is missing.
The EEPROM sits on the Helios 4 and is powered by the
same always-on 3.3V rail used by other on-board I2C devices.
Add vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/marvell/armada-388-helios4.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index 390e98df49c9..05540b8012c2 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -201,6 +201,10 @@ temp_sensor: temp@4c {
reg = <0x4c>;
vcc-supply = <®_3p3v>;
};
+
+ eeprom@53 {
+ vcc-supply = <®_3p3v>;
+ };
};
i2c@11100 {
--
2.54.0
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: helios4: wire LM75 into a thermal zone with fan cooling
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The LM75 temperature sensor on i2c0 creates a hwmon interface but was
not referenced by any thermal zone, producing:
hwmon hwmon0: temp1_input not attached to any thermal zone
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
.../boot/dts/marvell/armada-388-helios4.dts | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index 626a7339a5d0..6e0452217265 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -8,6 +8,7 @@
*/
/dts-v1/;
+#include <dt-bindings/thermal/thermal.h>
#include "armada-388.dtsi"
#include "armada-38x-solidrun-microsom.dtsi"
@@ -68,6 +69,35 @@ reg_5p0v_usb: regulator-5v-usb {
vin-supply = <®_12v>;
};
+ thermal-zones {
+ board-thermal {
+ polling-delay-passive = <2000>;
+ polling-delay = <10000>;
+ thermal-sensors = <&temp_sensor>;
+
+ trips {
+ board_alert: board-alert {
+ temperature = <55000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+ board_crit: board-crit {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&board_alert>;
+ cooling-device = <&fan1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&fan2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
system-leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -129,6 +159,7 @@ fan1: j10-pwm {
pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
pinctrl-names = "default";
pinctrl-0 = <&helios_fan1_pins>;
+ #cooling-cells = <2>;
};
fan2: j17-pwm {
@@ -136,6 +167,7 @@ fan2: j17-pwm {
pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
pinctrl-names = "default";
pinctrl-0 = <&helios_fan2_pins>;
+ #cooling-cells = <2>;
};
usb2_phy: usb2-phy {
@@ -201,6 +233,7 @@ temp_sensor: temp@4c {
compatible = "ti,lm75";
reg = <0x4c>;
vcc-supply = <®_3p3v>;
+ #thermal-sensor-cells = <0>;
};
eeprom@53 {
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: helios4: add vcc-supply to GPIO expander
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The pca953x driver requests a 'vcc' supply, producing:
pca953x 0-0020: supply vcc not found, using dummy regulator
The PCA9655 (PCA9555-compatible) expander is powered by the same
always-on 3.3V rail as the other I2C devices on the bus. Add
vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/marvell/armada-388-helios4.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index 05540b8012c2..cf0432a0e71a 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -169,6 +169,7 @@ expander0: gpio-expander@20 {
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
+ vcc-supply = <®_3p3v>;
pinctrl-names = "default";
pinctrl-0 = <&pca0_pins>;
interrupt-parent = <&gpio0>;
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: helios4: add SATA regulator supplies
From: Rosen Penev @ 2026-06-28 23:00 UTC (permalink / raw)
To: devicetree
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dennis Gilmore,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list
In-Reply-To: <20260628230042.1204293-1-rosenp@gmail.com>
The ahci-mvebu driver and libahci_platform request three supplies
on SATA controller and port nodes:
- ahci-supply (controller power)
- phy-supply (PHY power)
- target-supply (disk power per port)
Without them the regulator core prints notices at boot, e.g.:
supply ahci not found, using dummy regulator
supply phy not found, using dummy regulator
supply target not found, using dummy regulator
The SATA controller and PHY inside the Armada 388 SoC are powered
by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD
rail. Wire the existing fixed regulators accordingly.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/marvell/armada-388-helios4.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/marvell/armada-388-helios4.dts b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
index cf0432a0e71a..626a7339a5d0 100644
--- a/arch/arm/boot/dts/marvell/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/marvell/armada-388-helios4.dts
@@ -222,13 +222,17 @@ sata@a8000 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
+ ahci-supply = <®_3p3v>;
+ phy-supply = <®_3p3v>;
sata0: sata-port@0 {
reg = <0>;
+ target-supply = <®_5p0v_hdd>;
};
sata1: sata-port@1 {
reg = <1>;
+ target-supply = <®_5p0v_hdd>;
};
};
@@ -236,13 +240,17 @@ sata@e0000 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
+ ahci-supply = <®_3p3v>;
+ phy-supply = <®_3p3v>;
sata2: sata-port@0 {
reg = <0>;
+ target-supply = <®_5p0v_hdd>;
};
sata3: sata-port@1 {
reg = <1>;
+ target-supply = <®_5p0v_hdd>;
};
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH rc v6 1/7] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump
From: Pranjal Shrivastava @ 2026-06-28 23:00 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <f3d1f938a9b4d540f67d9c1ff394bd62735a4f5c.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:18AM -0700, Nicolin Chen wrote:
Hi Nicolin,
> When transitioning to a kdump kernel, the primary kernel might have crashed
> while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
> driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
> and setting the Global Bypass Attribute (GBPA) to ABORT.
>
> In a kdump scenario, this aggressive reset is highly destructive:
> a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> PCIe AER or SErrors that may panic the kdump kernel
> b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
> the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
>
> To safely absorb in-flight DMAs, a kdump kernel will have to leave SMMUEN=1
> intact and avoid modifying STRTAB_BASE, allowing HW to continue translating
> in-flight DMAs reusing the crashed kernel's page tables until the endpoint
> device drivers probe and quiesce their respective hardware.
>
> However, the ARM SMMUv3 architecture specification states that updating the
> SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
>
> This leaves a kdump kernel no choice but to adopt the stream table from the
> crashed kernel.
>
> Introduce ARM_SMMU_OPT_KDUMP_ADOPT and adopt functions memremapping all the
> stream tables extracted from STRTAB_BASE and STRTAB_BASE_CFG.
>
> Note that the adoption of the crashed kernel's stream table follows certain
> strict rules, since the old stream table might be compromised. Thus, apply
> some basic validations against the values read from the registers. If tests
> fail, it means the stream table cannot be trusted, so toss it entirely. To
> avoid OOM due to a potentially corrupted stream table, the memremap for l2
> tables is done on the kdump kernel's demand.
>
> The new option will be set in a following change.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 254 +++++++++++++++++++-
> 2 files changed, 252 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index ef42df4753ec4..cd60b692c3901 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -861,6 +861,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_OPT_MSIPOLL (1 << 2)
> #define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
> #define ARM_SMMU_OPT_TEGRA241_CMDQV (1 << 4)
> +#define ARM_SMMU_OPT_KDUMP_ADOPT (1 << 5)
> u32 options;
>
> struct arm_smmu_cmdq cmdq;
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f03..aa6837a5daa88 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2040,16 +2040,70 @@ static void arm_smmu_init_initial_stes(struct arm_smmu_ste *strtab,
> }
> }
>
> +static int arm_smmu_kdump_adopt_l2_strtab(struct arm_smmu_device *smmu, u32 sid,
> + phys_addr_t base, u32 span,
> + struct arm_smmu_strtab_l2 **l2table)
> +{
> + struct arm_smmu_strtab_l2 *table;
> + size_t size;
> +
> + /*
> + * Only a coherent SMMU is supported at this moment. For a non-coherent
> + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> + return -EOPNOTSUPP;
We already checked this in arm_smmu_kdump_adopt_strtab_2lvl() can it
change since?
> +
> + /*
> + * Retest the span in case the L1 descriptor has been overwritten since
> + * the adopt. Reject this master's insert; panic or SMMU-disable would
> + * either lose the vmcore or cascade aborts. Do not try to fix it, as it
> + * would break all other SIDs in the same bus (PCI case). The corruption
> + * blast radius is already bounded to that bus range.
> + */
> + if (span != STRTAB_SPLIT + 1) {
> + dev_err(smmu->dev,
> + "kdump: L1[%u] span %u changed since adopt (was %u)\n",
> + arm_smmu_strtab_l1_idx(sid), span, STRTAB_SPLIT + 1);
> + return -EINVAL;
> + }
> +
> + size = (1UL << (span - 1)) * sizeof(struct arm_smmu_ste);
> +
> + table = devm_memremap(smmu->dev, base, size, MEMREMAP_WB);
Why do we use devm_memremap() here but memremap() in the rest of the
functions (even for the L1 ptr)?
> + if (IS_ERR(table)) {
> + dev_err(smmu->dev,
> + "kdump: failed to adopt l2 stream table for SID %u\n",
> + sid);
> + return PTR_ERR(table);
> + }
> +
> + *l2table = table;
> + return 0;
> +}
> +
> static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
> {
> dma_addr_t l2ptr_dma;
> struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> struct arm_smmu_strtab_l2 **l2table;
> + u32 l1_idx = arm_smmu_strtab_l1_idx(sid);
>
> - l2table = &cfg->l2.l2ptrs[arm_smmu_strtab_l1_idx(sid)];
> + l2table = &cfg->l2.l2ptrs[l1_idx];
> if (*l2table)
> return 0;
>
> + /* Deferred adoption of the crashed kernel's L2 table */
> + if (smmu->options & ARM_SMMU_OPT_KDUMP_ADOPT) {
> + u64 l2ptr = le64_to_cpu(cfg->l2.l1tab[l1_idx].l2ptr);
> + phys_addr_t base = l2ptr & STRTAB_L1_DESC_L2PTR_MASK;
> + u32 span = FIELD_GET(STRTAB_L1_DESC_SPAN, l2ptr);
> +
> + if (span && base)
> + return arm_smmu_kdump_adopt_l2_strtab(smmu, sid, base,
> + span, l2table);
> + }
> +
> *l2table = dmam_alloc_coherent(smmu->dev, sizeof(**l2table),
> &l2ptr_dma, GFP_KERNEL);
> if (!*l2table) {
> @@ -2061,8 +2115,7 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
>
> arm_smmu_init_initial_stes((*l2table)->stes,
> ARRAY_SIZE((*l2table)->stes));
> - arm_smmu_write_strtab_l1_desc(&cfg->l2.l1tab[arm_smmu_strtab_l1_idx(sid)],
> - l2ptr_dma);
> + arm_smmu_write_strtab_l1_desc(&cfg->l2.l1tab[l1_idx], l2ptr_dma);
> return 0;
> }
>
> @@ -4556,10 +4609,204 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> return 0;
> }
>
> +static int arm_smmu_kdump_adopt_strtab_2lvl(struct arm_smmu_device *smmu,
> + u32 cfg_reg, phys_addr_t base)
> +{
> + u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
> + u32 split = FIELD_GET(STRTAB_BASE_CFG_SPLIT, cfg_reg);
> + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> + u32 num_l1_ents;
> + size_t size;
> + int i;
> +
> + /*
> + * Only a coherent SMMU is supported at this moment. For a non-coherent
> + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> + return -EOPNOTSUPP;
> +
> + if (log2size < split || log2size > smmu->sid_bits) {
> + dev_err(smmu->dev, "kdump: log2size %u out of range [%u, %u]\n",
> + log2size, split, smmu->sid_bits);
> + return -EINVAL;
> + }
> + if (split != STRTAB_SPLIT) {
> + dev_err(smmu->dev,
> + "kdump: unsupported STRTAB_SPLIT %u (expected %u)\n",
> + split, STRTAB_SPLIT);
> + return -EINVAL;
> + }
> +
> + num_l1_ents = 1U << (log2size - split);
> + if (num_l1_ents > STRTAB_MAX_L1_ENTRIES) {
> + dev_err(smmu->dev, "kdump: l1 entries %u exceeds max %u\n",
> + num_l1_ents, STRTAB_MAX_L1_ENTRIES);
> + return -EINVAL;
> + }
> +
> + cfg->l2.num_l1_ents = num_l1_ents;
> +
> + size = num_l1_ents * sizeof(struct arm_smmu_strtab_l1);
> + cfg->l2.l1tab = memremap(base, size, MEMREMAP_WB);
> + if (!cfg->l2.l1tab)
> + return -ENOMEM;
Same here (as below, sorry reviewing it as the code flows), we should
populate cfg->l2.l1_dma here to be consistent.
> +
> + cfg->l2.l2ptrs =
> + kcalloc(num_l1_ents, sizeof(*cfg->l2.l2ptrs), GFP_KERNEL);
> + if (!cfg->l2.l2ptrs)
> + return -ENOMEM;
We shuold ummap cfg->l2.l1tab before returning -ENOMEM here
> +
> + for (i = 0; i < num_l1_ents; i++) {
> + u64 l2ptr = le64_to_cpu(cfg->l2.l1tab[i].l2ptr);
> + phys_addr_t l2_base = l2ptr & STRTAB_L1_DESC_L2PTR_MASK;
> + u32 span = FIELD_GET(STRTAB_L1_DESC_SPAN, l2ptr);
> +
> + if (!span || !l2_base)
> + continue;
> +
> + if (span != STRTAB_SPLIT + 1) {
> + dev_err(smmu->dev,
> + "kdump: L1[%u] unsupported span %u (vs %u)\n",
> + i, span, STRTAB_SPLIT + 1);
> + return -EINVAL;
We leak kcalloc'd mem (l2.l2ptrs) here, also we should unmap cfg->l2.l1tab
> + }
> +
> + /*
> + * If the crashed kernel's l1 descriptors are deeply corrupted,
> + * blindly memremapping every l2 table here could lead to OOM.
> + *
> + * Defer the l2 memremap to arm_smmu_init_l2_strtab(), so peak
> + * memory is bounded by the kdump kernel's actual demand.
> + */
> + }
> +
> + return 0;
> +}
> +
> +static int arm_smmu_kdump_adopt_strtab_linear(struct arm_smmu_device *smmu,
> + u32 cfg_reg, phys_addr_t base)
> +{
> + u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
> + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> + unsigned int max_log2size;
> + size_t size;
> +
> + /*
> + * Only a coherent SMMU is supported at this moment. For a non-coherent
> + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> + return -EOPNOTSUPP;
> +
> + /* Cap the size at what the kdump kernel itself would have allocated */
> + if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
> + max_log2size =
> + ilog2(STRTAB_MAX_L1_ENTRIES * STRTAB_NUM_L2_STES);
Looks like we'd never hit this if condition because we'd never support a
"linear" strtab if the HW supports ARM_SMMU_FEAT_2_LVL_STRTAB. Please
see arm_smmu_init_strtab:
static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
{
int ret;
if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
ret = arm_smmu_init_strtab_2lvl(smmu);
else
ret = arm_smmu_init_strtab_linear(smmu);
if (ret)
return ret;
ida_init(&smmu->vmid_map);
return 0;
}
> + else
> + max_log2size = smmu->sid_bits;
> +
> + /* cfg->linear.num_ents is unsigned int, so cap log2size at 31 */
> + max_log2size = min(max_log2size, 31U);
> + if (log2size > max_log2size) {
> + dev_err(smmu->dev, "kdump: unsupported log2size %u (> %u)\n",
> + log2size, max_log2size);
> + return -EINVAL;
> + }
> +
> + /*
> + * We might end up with a num_ents != sid_bits, which is fine. In the
> + * ARM_SMMU_OPT_KDUMP_ADOPT case, arm_smmu_write_strtab() is bypassed.
> + */
> + cfg->linear.num_ents = 1U << log2size;
> +
> + size = cfg->linear.num_ents * sizeof(struct arm_smmu_ste);
> + cfg->linear.table = memremap(base, size, MEMREMAP_WB);
> + if (!cfg->linear.table)
> + return -ENOMEM;
We seem to skips initializing cfg->linear.ste_dma (it is populated in
arm_smmu_init_strtab_linear)
While the comment notes that arm_smmu_write_strtab() is bypassed in the
kdump case, leaving cfg->linear.ste_dma uninitialized seems like a
ticking time bomb if any other part of the driver ever uses it.
> + return 0;
> +}
> +
> +static void arm_smmu_kdump_adopt_cleanup(void *data)
> +{
> + struct arm_smmu_device *smmu = data;
> + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
I'm worried about reading the HW register here, since this is a devres action, it
can run after arm_smmu_device_remove() or arm_smmu_device_shutdown()
(which would call rpm_put()). Please see __device_release_driver[1]:
pm_runtime_put_sync(dev); <--- HW turned off
device_remove(dev);
if (dev->bus && dev->bus->dma_cleanup)
dev->bus->dma_cleanup(dev);
device_unbind_cleanup(dev); <--- This is where devm_release runs
device_links_driver_cleanup(dev);
Thus, even if we call rpm_get() here it would make no sense as the
register contents would've been lost. Can we rely on some SW state
here? smmu->features & 2LVL or maybe add an fmt in cfg?
> + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> + u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
> +
> + if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> + kfree(cfg->l2.l2ptrs);
> + if (cfg->l2.l1tab)
> + memunmap(cfg->l2.l1tab);
> + } else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
> + if (cfg->linear.table)
> + memunmap(cfg->linear.table);
> + }
> +}
> +
> +static int arm_smmu_kdump_adopt_strtab(struct arm_smmu_device *smmu)
> +{
> + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
> + u64 base_reg = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> + u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
> + phys_addr_t base = base_reg & STRTAB_BASE_ADDR_MASK;
> + int ret;
> +
> + dev_info(smmu->dev, "kdump: adopting crashed kernel's stream table\n");
Nit: Should this be dev_info? If everything goes right, the user doesn't
need to know. dev_dbg seems more appropriate. It should only be a warn or
err if adoption fails (which is in place).
> +
> + if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> + /*
> + * Both kernels run on the same hardware, so it's impossible for
> + * kdump kernel to see the support for linear stream table only.
> + */
> + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)))
> + ret = -EINVAL;
> + else
> + ret = arm_smmu_kdump_adopt_strtab_2lvl(smmu, cfg_reg,
> + base);
> + } else if (fmt == STRTAB_BASE_CFG_FMT_LINEAR) {
> + /*
> + * In case that the old kernel for some reason used the linear
Nit: This sounds a little judgemental, what if the HW only supports
linear table? Let's drop the "for some reason" part.
> + * format, enforce the same format to match the adopted table.
> + */
> + ret = arm_smmu_kdump_adopt_strtab_linear(smmu, cfg_reg, base);
> + if (!ret)
> + smmu->features &= ~ARM_SMMU_FEAT_2_LVL_STRTAB;
IIRC, this should NOT be set if we selected the linear format.
Looking at arm_smmu_init_strtab(), if the HW supports 2-level tables,
the driver unconditionally selects it. What is the expected scenario
where the previous kernel would have allocated a linear table on 2-level
capable hardware? IMO, it is a bug if we see linear fmt with this
feature set. Am I missing something?
> + } else {
> + dev_err(smmu->dev, "kdump: invalid STRTAB format %u\n", fmt);
> + ret = -EINVAL;
> + }
> +
> + if (ret) {
> + arm_smmu_kdump_adopt_cleanup(smmu);
> + goto err;
> + }
> +
> + ret = devm_add_action_or_reset(smmu->dev, arm_smmu_kdump_adopt_cleanup,
> + smmu);
> + /* devm_add_action_or_reset ran the cleanup upon failure */
> + if (ret) {
> + dev_warn(smmu->dev, "kdump: failed to set up cleanup action\n");
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + dev_warn(smmu->dev, "kdump: falling back to full reset\n");
> + memset(&smmu->strtab_cfg, 0, sizeof(smmu->strtab_cfg));
> + smmu->options &= ~ARM_SMMU_OPT_KDUMP_ADOPT;
> + return ret;
> +}
> +
> static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
> {
> int ret;
>
> + if ((smmu->options & ARM_SMMU_OPT_KDUMP_ADOPT) &&
> + !arm_smmu_kdump_adopt_strtab(smmu))
> + goto out;
> +
> if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
> ret = arm_smmu_init_strtab_2lvl(smmu);
> else
> @@ -4567,6 +4814,7 @@ static int arm_smmu_init_strtab(struct arm_smmu_device *smmu)
> if (ret)
> return ret;
>
> +out:
> ida_init(&smmu->vmid_map);
>
> return 0;
> --
> 2.43.0
>
Thanks,
Praan
[1] https://elixir.bootlin.com/linux/v7.1.2/source/drivers/base/dd.c#L1350
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size
From: Rosen Penev @ 2026-06-28 23:10 UTC (permalink / raw)
To: devicetree
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Broadcom internal kernel review list, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list
Fixes:
[ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
[ 0.182159] Unexpected (big) NVRAM size: 1056112 B
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
index af411679a14a..37593e7582ba 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
@@ -26,7 +26,7 @@ memory@0 {
nvram@1c080000 {
compatible = "brcm,nvram";
- reg = <0x1c080000 0x180000>;
+ reg = <0x1c080000 0x100000>;
et2macaddr: et2macaddr {
#nvmem-cell-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
From: Rosen Penev @ 2026-06-28 23:11 UTC (permalink / raw)
To: devicetree
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Broadcom internal kernel review list, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list
These addresses overlap with DRAM on BCM5301X/BCM470X SoCs, causing the OF
address translation code to route PCIe MMIO accesses through the AXI bus
space instead of directly to memory, breaking PCIe. Remove the extra
ranges to restore the original single-entry mapping that only covers the
AXI peripheral register space.
Assisted-by: opencode:big-pickle
Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/broadcom/bcm-ns.dtsi | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
index bd52de0faa3e..27a97c8122de 100644
--- a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
@@ -95,10 +95,7 @@ L2: cache-controller@22000 {
axi@18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
- ranges = <0x00000000 0x18000000 0x00100000>,
- <0x08000000 0x08000000 0x08000000>,
- <0x20000000 0x20000000 0x08000000>,
- <0x28000000 0x28000000 0x08000000>;
+ ranges = <0x00000000 0x18000000 0x00100000>;
#address-cells = <1>;
#size-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH rc v6 2/7] iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
From: Pranjal Shrivastava @ 2026-06-28 23:06 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <89cbd3760a13f11cf63f6ead12f44974511f308a.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:19AM -0700, Nicolin Chen wrote:
> Though the kdump kernel adopts the crashed kernel's stream table, the iommu
> core will still try to attach each probed device to a default domain, which
> overwrites the adopted STE and breaks in-flight DMA from that device.
>
> Implement an is_attach_deferred() callback to prevent this. For each device
> that has STE.V=1 and STE.Cfg!=Abort in the adopted table, defer the default
> domain attachment, until the device driver explicitly requests it.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v3 8/8] arm64: dts: qcom: shikra-iqs-evk: Enable A704 GPU
From: Dmitry Baryshkov @ 2026-06-28 22:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-8-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:54:01PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Enable the A704 GPU and configure its zap-shader firmware on the
> Shikra IQS EVK board.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Chaoyi Chen @ 2026-06-29 1:29 UTC (permalink / raw)
To: Xu Yang, Heikki Krogerus
Cc: Chaoyi Chen, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang,
Andy Yan, Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel
In-Reply-To: <erx73m2ueuvbzjteadjli6aki5by4pr3hyertkkqqoqwhaa4v3@5cstmshcercx>
Hello Xu Yang,
On 6/26/2026 7:15 PM, Xu Yang wrote:
> On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> The HPD function of Type-C DP is implemented through
>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>
>> To describe the relationship between the DP controller and the Type-C
>> port device, we usually using drm_bridge to build a bridge chain.
>>
>> Now several USB-C controller drivers have already implemented the DP
>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>> HPD bridge on USB-C connector port device.
>>
>> But this requires the USB-C controller driver to manually register the
>> HPD bridge. If the driver does not implement this feature, the bridge
>> will not be create.
>>
>> So this patch implements a generic DP HPD bridge based on
>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>> Type-C port device containing the DP svid is registered, it will
>> create an HPD bridge for it without the need for the USB-C controller
>> driver to implement it.
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>> ---
>>
>> (no changes since v14)
>>
>> Changes in v13:
>> - Only register drm dp hpd bridge for typec port altmode device.
>>
>> (no changes since v12)
>>
>> Changes in v11:
>> - Switch to using typec bus notifiers.
>>
>> (no changes since v10)
>>
>> Changes in v9:
>> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
>> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
>> - Add more commit comment about problem background.
>>
>> Changes in v8:
>> - Merge generic DP HPD bridge into one module.
>> ---
>>
>> drivers/gpu/drm/bridge/Kconfig | 10 ++++
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
>> 3 files changed, 60 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index a250afd8d662..559487aa09a9 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
>> Simple bridge that terminates the bridge chain and provides HPD
>> support.
>>
>> +if DRM_AUX_HPD_BRIDGE
>> +config DRM_AUX_HPD_TYPEC_BRIDGE
>> + tristate
>> + depends on TYPEC || !TYPEC
>> + default TYPEC
>> + help
>> + Simple bridge that terminates the bridge chain and provides HPD
>> + support. It build bridge on each USB-C connector device node.
>> +endif
>> +
>
> Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
> manually.
>
> $ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
> ./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
> ./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>
That's a fair point. But based on the previous discussion, Heikki
point out that configurations in the TYPEC subsystem should not
select configurations from DRM.
--
Best,
Chaoyi
^ permalink raw reply
* Re: [PATCH v5 3/4] drm/bridge: analogix_dp: Add validation for samsung,lane-count property
From: Damon Ding @ 2026-06-29 1:53 UTC (permalink / raw)
To: Luca Ceresoli
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <178249136513.1374898.11400378046460567437.b4-review@b4>
Hi Luca,
On 6/27/2026 12:29 AM, Luca Ceresoli wrote:
> On Thu, 04 Jun 2026 16:52:19 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
>
> Hello Damon,
>
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 7a85774aaac1..e120ef3320c1 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1261,8 +1262,11 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
>> */
>> of_property_read_u32(dp_node, "samsung,link-rate",
>> &video_info->max_link_rate);
>> - of_property_read_u32(dp_node, "samsung,lane-count",
>> - &video_info->max_lane_count);
>> + ret = of_property_read_u32(dp_node, "samsung,lane-count",
>> + &video_info->max_lane_count);
>> + if (ret || !drm_dp_lane_count_is_valid(video_info->max_lane_count))
>> + return dev_err_probe(dp->dev, ret ? ret : -EINVAL,
>> + "failed to parse samsung,lane-count\n");
>
> I think this report by sashiko makes sense:
>
> > sashiko-bot@kernel.org <sashiko-bot@kernel.org>:
> >
> > [Severity: High]
> > Does this make the optional and deprecated samsung,lane-count property a
> > strict requirement?
> >
> > If samsung,lane-count is absent from the device tree, of_property_read_u32()
> > returns -EINVAL. This causes the condition to evaluate to true, aborting the
> > probe with an error.
> >
> > According to the device tree bindings
> > (Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml),
> > this property is marked as deprecated and explicitly optional because the
> > lane count can be read from the monitor. Does this patch break compatibility
> > with device trees that rightfully omit this deprecated property?
>
> (via: https://patch.msgid.link/20260604090935.7FC051F00898@smtp.kernel.org)
>
> Can you comment on this?
>
>
I was also confused about this handling at first. From commit
0d0abd894ead ("drm: bridge: analogix/dp: add max link rate and lane
count limit for RK3288"), its commit message does not explain why
samsung,lane-count was changed from a mandatory to optional property.
After digging into the code flow, I found that
analogix_dp_full_link_train() picks the smaller value between the
platform-supported lane count and the lane count retrieved from sink
DPCD for link training. If the samsung,lane-count property is
missing/invalid here, link training will end up using an unexpected lane
count configuration.
Additionally, I checked Samsung’s upstream device trees that utilize
this DP controller, and all of them carry the lane-count property. Based
on this observation, I believe restoring the strict mandatory
requirement for this property makes sense.
Should I create an independent fix patch to revert these two properties
to mandatory, instead of bundling the fix in this series?
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-29 2:08 UTC (permalink / raw)
To: Leo Yan, Suzuki K Poulose, Mike Leach, James Clark
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Yuanfang Zhang, linux-arm-msm, devicetree,
linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <20260626154949.GA1812158@e132581.arm.com>
Hi Leo/Suzuki,
On 6/26/2026 11:49 PM, Leo Yan wrote:
> On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
>
> [...]
>
>> I have another proposal: what if we allocate the ATID in trace_noc_id() when
>> the device does not already have a valid ATID?
>>
>> Possible scenarios:
>>
>> If the itnoc device is connected to a TPDM device (which has no ATID),
>> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
>> valid ATID can be allocated for the path.
>>
>> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
>> will never be invoked, and therefore no ATID will be allocated for the
>> device, saving resources.
>
> TBH, I'm not sure I can make a judgement here, as I don't have enough
> knowledge of the topology. And I'm not sure whether the listed
> connections cover all possible cases.
>
> I also found commit 5799dee92dc2:
>
> | This patch adds platform driver support for the CoreSight Interconnect
> | TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
> | from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
> | it does not have aggregation and ATID functionality.
>
> With your proposal, wouldn't ATID be allocated for the interconnect
> TNOC while being skipped for the Aggregator TNOC? That seems to
> contradict the commit log.
The ATID is allocated to the Aggregator TNOC during probe. The "WA" in
driver definitely break the original design.
Can I fix the issue by adding "arm,primecell-periphid" property. That's
would be the best temp solution as it avoids breaking the original
design of both the TraceNoC AMBA driver and interconnect TraceNoC
platform driver.
The TraceNoC device here must be treated as an AMBA device and I am
continuing to investigate the issue with our hardware team. We aim to
fix it from hardware perspetive for existing platforms if possible and
ensure it is fixed in future platforms.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* RE: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-06-29 2:32 UTC (permalink / raw)
To: Frank Li (OSS), Sherry Sun (OSS)
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, Amitkumar Karwar, Neeraj Sanjay Kale,
marcel@holtmann.org, luiz.dentz@gmail.com, Hongxing Zhu,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <aj7VpvRQxhCyPVPg@SMW015318>
> Subject: Re: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
>
> On Fri, Jun 26, 2026 at 10:31:19AM +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > suspend to preserve wakeup capability of the devices and also not to
> > power on the devices in the init path.
>
> Need empty line here.
Ok, will fix.
>
> > This allows controller power-off to be skipped when some devices(e.g.
> > M.2 cards key E without auxiliary power) required to support PCIe L2
> > link state and wake-up mechanisms.
> >
> > Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is
> > only called once during probe, similar to other regulator_get calls.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 43
> > ++++++++++++++++-----------
> > 1 file changed, 25 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 0fa716d1ed75..0685573fee71 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -1382,16 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > }
> > }
> >
> > - ret = pci_pwrctrl_create_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to create pwrctrl devices\n");
> > - goto err_reg_disable;
> > - }
> > -
>
> Please two patch do that. one patch move pci_pwrctrl_create_devices() to
> probe
>
> one patch check skip_power_off.
>
> > - ret = pci_pwrctrl_power_on_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > - goto err_pwrctrl_destroy;
> > + if (!pp->skip_pwrctrl_off) {
> > + ret = pci_pwrctrl_power_on_devices(dev);
> > + if (ret) {
> > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > + goto err_reg_disable;
> > + }
> > }
> >
> > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,10 +1456,8 @@
> static
> > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > err_clk_disable:
> > imx_pcie_clk_disable(imx_pcie);
> > err_pwrctrl_power_off:
> > - pci_pwrctrl_power_off_devices(dev);
> > -err_pwrctrl_destroy:
> > - if (ret != -EPROBE_DEFER)
> > - pci_pwrctrl_destroy_devices(dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(dev);
> > err_reg_disable:
> > if (imx_pcie->vpcie)
> > regulator_disable(imx_pcie->vpcie);
> > @@ -1482,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> *pp)
> > }
> > imx_pcie_clk_disable(imx_pcie);
> >
> > - pci_pwrctrl_power_off_devices(pci->dev);
> > + if (!pci->pp.skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(pci->dev);
> > if (imx_pcie->vpcie)
> > regulator_disable(imx_pcie->vpcie);
> > }
> > @@ -1954,11 +1949,15 @@ static int imx_pcie_probe(struct
> platform_device *pdev)
> > if (ret)
> > return ret;
> >
> > + ret = pci_pwrctrl_create_devices(dev);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "failed to create pwrctrl
> > +devices\n");
> > +
> > pci->use_parent_dt_ranges = true;
> > if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> > ret = imx_add_pcie_ep(imx_pcie, pdev);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > /*
> > * FIXME: Only single Device (EPF) is supported due to the
> @@
> > -1973,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device
> *pdev)
> > pci->pp.use_atu_msg = true;
> > ret = dw_pcie_host_init(&pci->pp);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > if (pci_msi_enabled()) {
> > u8 offset = dw_pcie_find_capability(pci,
> PCI_CAP_ID_MSI); @@
> > -1985,16 +1984,24 @@ static int imx_pcie_probe(struct platform_device
> *pdev)
> > }
> >
> > return 0;
> > +
> > +err_pwrctrl_destroy:
> > + if (ret != -EPROBE_DEFER)
> > + pci_pwrctrl_destroy_devices(dev);
> > + return ret;
>
> Mani said he will fix DEFER problem soon.
Yes, so for now I'll make a patch to move pci_pwrctrl_create_devices() into the
probe() and temporarily add the err_pwrctrl_destroy error label until Mani fixes it.
Let me know if any other suggestions, thanks!
Best Regards
Sherry
>
> Frank
>
> > }
> >
> > static void imx_pcie_shutdown(struct platform_device *pdev) {
> > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct dw_pcie_rp *pp = &pci->pp;
> >
> > /* bring down link, so bootloader gets clean state in case of reboot */
> > imx_pcie_assert_core_reset(imx_pcie);
> > imx_pcie_assert_perst(imx_pcie, true);
> > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > pci_pwrctrl_destroy_devices(&pdev->dev);
> > }
> >
> > --
> > 2.50.1
> >
> >
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-29 2:33 UTC (permalink / raw)
To: David Lechner, Akhila Kavi, Prasad Bolisetty, Jonathan Cameron,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <6770a7af-06cc-4240-9b20-c299e7080ab1@baylibre.com>
On 6/28/2026 1:07 AM, David Lechner wrote:
>> +#define AX_SARADC_CH(_index, _id) \
>> + { \
>> + .type = IIO_VOLTAGE, \
>> + .indexed = 1, \
>> + .channel = (_index), \
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>> + .datasheet_name = (_id), \
> This could probably be:
>
> .datasheet_name = "adc" #_index,
>
> and avoid the need for _id.
Thanks for the review, David.
Yes, that makes sense. I will update this and remove the extra _id
argument.
>> + }
>> +
>> +static const struct iio_chan_spec axiado_saradc_iio_channels[] = {
>> + AX_SARADC_CH(0, "adc0"), AX_SARADC_CH(1, "adc1"),
>> + AX_SARADC_CH(2, "adc2"), AX_SARADC_CH(3, "adc3"),
>> + AX_SARADC_CH(4, "adc4"), AX_SARADC_CH(5, "adc5"),
>> + AX_SARADC_CH(6, "adc6"), AX_SARADC_CH(7, "adc7"),
>> + AX_SARADC_CH(8, "adc8"), AX_SARADC_CH(9, "adc9"),
>> + AX_SARADC_CH(10, "adc10"), AX_SARADC_CH(11, "adc11"),
>> + AX_SARADC_CH(12, "adc12"), AX_SARADC_CH(13, "adc13"),
>> + AX_SARADC_CH(14, "adc14"), AX_SARADC_CH(15, "adc15"),
> Two columns looks a bit odd.
I will also reformat the channel table to one entry per line.
>> +};
>> +
>> +static void axiado_saradc_disable(void *data)
>> +{
>> + struct axiado_saradc *info = data;
>> +
>> + writel(AX_SARADC_GLOBAL_CTRL_PD, info->regs + AX_SARADC_GLOBAL_CTRL_REG);
> People usual make read and write wrappers or use regmap to avoid having
> to write `info->regs + AX_SARADC_GLOBAL_CTRL_REG` so many times.
My understanding is that simple read/write wrappers are not always
preferred unless they provide additional value. Would switching the
driver to regmap be acceptable here to avoid repeating the base address
calculation?
Regards,
Petar
^ permalink raw reply
* [PATCH v4 0/2] i2c: imx: Fix slave mode corner issues
From: Liem @ 2026-06-29 2:38 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa
In-Reply-To: <AM0PR04MB6802B863CD9B9AE1609C1785E8EB2@AM0PR04MB6802.eurprd04.prod.outlook.com>
This series fixes two issues in the i2c-imx target mode.
Patch 1 defers slave pointer assignment to after a successful resume
and protects it with the slave_lock to prevent races with the shared
IRQ handler.
Patch 2 cancels the hrtimer before clearing the slave pointer during
unregistration, preventing a potential use-after-free.
Changes in v4:
- Patch 1: reworked to avoid race with shared IRQ handler, as
suggested by Sashiko.
- Patch 2: unchanged.
Changes in v3:
- Split the original patch into two separate patches as suggested by
Frank Li.
- v2: https://lore.kernel.org/imx/
20260625160219.55116-1-liem16213@gmail.com/
Liem (2):
i2c: imx: Fix slave registration race and error handling
i2c: imx: Cancel hrtimer before clearing slave pointer
drivers/i2c/busses/i2c-imx.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v4 1/2] i2c: imx: Fix slave registration race and error handling
From: Liem @ 2026-06-29 2:38 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa
In-Reply-To: <20260629023829.152651-1-liem16213@gmail.com>
In i2c_imx_reg_slave(), the slave pointer was assigned before
pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed,
the error path returned without clearing i2c_imx->slave, leaving it
non-NULL and causing all subsequent registration attempts to fail
with -EBUSY.
Additionally, because this driver uses a shared IRQ, the interrupt
handler i2c_imx_isr() can execute concurrently and, after acquiring
slave_lock, dereference i2c_imx->slave. The previous fix attempt
added a lockless i2c_imx->slave = NULL on the error path, but that
could race with the ISR under the lock and still cause a NULL pointer
dereference.
Fix both issues by deferring the assignment of i2c_imx->slave and
i2c_imx->last_slave_event to after a successful resume, and by
performing the assignment inside the slave_lock critical section.
This guarantees that the slave pointer is never left stale on the
error path and is always valid when observed by the interrupt handler.
Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Cc: stable@vger.kernel.org
Signed-off-by: Liem <liem16213@gmail.com>
---
v3 -> v4:
- Instead of clearing the slave pointer on error, defer the
assignment until after pm_runtime_resume_and_get() succeeds,
and take slave_lock to avoid racing with the shared IRQ handler.
Suggested by Sashiko and Carlos Song
---
drivers/i2c/busses/i2c-imx.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 28313d0fad37..2398c406e913 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -930,9 +930,6 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
if (i2c_imx->slave)
return -EBUSY;
- i2c_imx->slave = client;
- i2c_imx->last_slave_event = I2C_SLAVE_STOP;
-
/* Resume */
ret = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
if (ret < 0) {
@@ -940,6 +937,11 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
return ret;
}
+ scoped_guard(spinlock_irqsave, &i2c_imx->slave_lock) {
+ i2c_imx->slave = client;
+ i2c_imx->last_slave_event = I2C_SLAVE_STOP;
+ }
+
i2c_imx_slave_init(i2c_imx);
return 0;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/2] i2c: imx: Cancel hrtimer before clearing slave pointer
From: Liem @ 2026-06-29 2:38 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa, Carlos Song
In-Reply-To: <20260629023829.152651-1-liem16213@gmail.com>
In i2c_imx_unreg_slave(), the slave pointer is set to NULL after
disabling interrupts. However, a pending interrupt might already
have started the hrtimer (i2c_imx_slave_timeout) before the pointer
was cleared. If the hrtimer fires after i2c_imx->slave is set to
NULL, the timer callback i2c_imx_slave_finish_op() will call
i2c_imx_slave_event() with a NULL slave pointer, which results in a
use-after-free / NULL pointer dereference.
Fix by canceling the hrtimer and waiting for it to complete after
disabling interrupts, before clearing the slave pointer.
Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Cc: stable@vger.kernel.org
Acked-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Liem <liem16213@gmail.com>
---
v3 -> v4: No changes, added Acked-by from Carlos Song.
---
drivers/i2c/busses/i2c-imx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 2398c406e913..b1c6581db774 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -960,6 +960,7 @@ static int i2c_imx_unreg_slave(struct i2c_client *client)
i2c_imx_reset_regs(i2c_imx);
+ hrtimer_cancel(&i2c_imx->slave_timer);
i2c_imx->slave = NULL;
/* Suspend */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Chris Lu (陸稚泓) @ 2026-06-29 3:01 UTC (permalink / raw)
To: luiz.dentz@gmail.com, i@rong.moe
Cc: Will-CY Lee (李政穎), marcel@holtmann.org,
AngeloGioacchino Del Regno, SS Wu (巫憲欣),
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
patchwork-bot+bluetooth@kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <4e96132bcfb267af05c06dc277b5ba6895e3ddde.camel@rong.moe>
Hi Rong,
Thanks for your understanding. We hope to find a better way to handle
this issue.
Hi Luiz,
Regarding this issue, MediaTek Bluetooth team has already initialed an
internal investigation for problematic combination and will seek
assistance from AMD SOC team to investigate the root cause of this
issue.
However, since this change has impact on MTK products, may I submit a
patch to remove it first?
If the investigation determines the issue lies within MTK BT
driver/firmware, we'll submit a separate solution to fix it.
On Sat, 2026-06-27 at 03:56 +0800, Rong Zhang wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Hi Chris, Luiz,
>
> On Fri, 2026-06-26 at 17:56 +0000, Chris Lu (陸稚泓) wrote:
> > Hi Rong and Luiz,
> >
> > On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> > > Hi,
> > >
> > >
> > > On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > > > <Chris.Lu@mediatek.com> 写道：
> > > > > Hi Luiz,
> > > > >
> > > > > Could we revert this change?
> > > >
> > > > Please don't. The fundamental goal of the patch is to make
> > > > MT7922/MT7925 *usable* on affected platforms.
> > > >
> > > > Moreover, almost all recent AMD platforms ship with
> > > > MT7922/MT7925,
> > > > reverting this patch affects quite a lot of users. Almost every
> > > > AMD
> > > > platform I've met suffers from the issue, and there are plenty
> > > > of
> > > > bug reports.
> > > >
> > > > Intel platforms never ship with MTK WLAN NICs, so I can't tell
> > > > if
> > > > the issue is reproducible on them.
> > >
> > We still have non-AMD platforms with MT7922/7925, where
> > "wakeup by Bluetooth" is an essential feature. In other word, this
> > change will have a serious impact to them.
>
> Oh, perhaps I missed something before. Your words were a bit unclear
> to
> me at first glance.
>
> You previous reply said "wake on Bluetooth". I interpreted it as USB
> remote wakeup upon Bluetooch device connection.
>
> "Wakeup by Bluetooth" is clearer. You meant using the Bluetooth
> interface as a wakeup source to wake up the system from sleep, right?
>
> Hmm, it makes more sense to me.
>
> My patch was inspired by commit f4292e2faf52 ("Bluetooth: btusb: Make
> the CSR clone chip force-suspend workaround more generic"). The
> mentioned commit is correct as the quirky chips can't perform remote
> wakeup at all.
>
> If MT7922/MT7925 can reliably wake up the system from sleep, my patch
> could be a burden. I won't insist anymore if you'd like to revert it.
>
> >
> > > We cannot really remove it anymore, since it has already been
> > > pulled.
> > > Therefore, I strongly prefer that the issue is fixed somehow or
> > > if
> > > there is no other way then a proper revert patch must be sent,
> > > since
> > > I
> > > don't have any hardware with this controller I cannot really test
> > > this
> > > myself.
> > >
> > Got it.
> > > > >
> > > > > Sorry, MediaTek wasn't aware someone submitted this change
> > > > > and it
> > > > > had
> > > > > already been merged.
> > > > >
> > > > > MTK believes this issue is strongly related to the platform's
> > > > > USB
> > > > > hub
> > > > > behavior,
> > > >
> > > > Still, I believe that there are some interoperability issues in
> > > > MT7922/MT7925's hardware or firmware, as reinitializing the
> > > > XHCI
> > > > root hub (by logically removing it from the PCI bus and probing
> > > > it
> > > > again) doesn't make it recover at all.
> > > >
> > > > > The product lines MTK directly support haven't reported such
> > > > > issue.
> > > >
> > > > ...or did you mean none of the existing AMD platforms are
> > > > supported
> > > > by MTK?
> > > >
> > I'll report it to corresponding department to see if they have such
> > issue. (I'm not from Bluetooth with AMD platform support team)
> >
> > > > >
> > > > > Disable wake capability would severely impact wake on
> > > > > Bluetooth
> > > > > on
> > > > > MTK's official product lines.
> > > >
> > > > Could you kindly explain "MTK's official product lines"?
> > > >
> > Some products are module makers selling our modules to downstream
> > customers directly.
> >
> > > > > Furthermore, this patch looks like a
> > > > > workaround. There should be a better way to handle this
> > > > > issue. We
> > > > > hope
> > > > > this change can be reverted.
> > > >
> > > > The issue is severe on affected platforms by making the
> > > > Bluetooth
> > > > interface completely gone. IMHO, we must figure out the "better
> > > > way" before reverting it, or else it's more like burying your
> > > > head
> > > > into sand by shouting "works fine on our platforms" (TM).
> > > >
> > > > That being said, I think we can narrow the range of the quirk
> > > > down
> > > > to AMD platforms only. Does it make sense to you? If so, I will
> > > > submit a patch for this.
> > >
> > As I mentioned above, we have many platforms using the kernel
> > driver,
> > not just AMD,
> >
> > If this change can be limited to specific platform , it would be
> > the
> > best way so far.
>
> I plan to submit another patch to properly fix it next week. In
> general,
> I will:
>
> - narrow the quirk down to AMD platforms only
> - disable USB remote wakeup for runtime autosuspend only
> - leave the wakeup source as is, so users can enable "wakeup by
> Bluetooth" even on AMD platforms if they really want it
>
> Hopefully it will minimize the impact of the workaround.
>
> Thanks,
> Rong
>
> >
> > > Ok, then you guys please coordinate. I don't want to start
> > > requiring
> > > Sign-Off-By (SOB) from driver authors because this instance shows
> > > that
> > > response time can be very long. Therefore, the best way forward
> > > in my
> > > opinion, is to have the issue fixed in a way that works for both
> > > of
> > > you.
> >
> > Of course, Mediatek BT team also agree that any issue need to be
> > resolved, However, original issue for this change requires further
> > verification of Hardware/firmware and even USB behavior. A device
> > that
> > can reproduce the issue stably is required in order to experiment
> > and
> > identify the root cause.
> >
> > As mentioned, I'll deliver internally to relate support team. If
> > they
> > have similar settings, MTK will attempt to reproduce it and provide
> > an
> > official solution.
> >
> > Thanks very much for your input and understanding.
> >
> > Best Regards,
> > Chris Lu
Thanks,
Chris Lu
^ permalink raw reply
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Songwei.Chai @ 2026-06-29 3:03 UTC (permalink / raw)
To: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt, gregkh
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, Songwei Chai
In-Reply-To: <48c6abce-c492-46a6-84ef-3074983e817c@oss.qualcomm.com>
Hi Greg & Alexander,
Apologies for interrupting again.
As the TGU hardware plays an important role in Qualcomm tracing design,
I would greatly appreciate it if you could kindly take some time to
review this at your earliest convenience.
Best regards,
Songwei
On 6/5/2026 11:14 AM, Songwei.Chai wrote:
> hi Greg & Alexander,
>
> I hope this message finds you well.
>
> We are currently working on a Qualcomm TGU (Trace Generation Unit)
> driver and would like to seek your guidance on how best to integrate
> it into the /hwtracing/ subsystem.
>
> TGU is a programmable hardware block that monitors signal conditions
> and triggers debug-related actions, effectively acting as a trace
> generation utility. Based on its functionality, placing it under
> |"drivers/hwtracing"| appears to be a reasonable choice.
>
> We initially explored integrating it into
> "|drivers/hwtracing/coresight"|.However, that approach did not receive
> support, primarily because the component is not tightly coupled with
> the CoreSight subsystem.
>
> *Chat History*:
> https://lore.kernel.org/all/CAJ9a7ViKxHThyZfFFDV_FkNRimk4uo1NrMtQ-kcaj1qO4ZcGnA@mail.gmail.com/
>
> As an alternative, we are proposing to introduce a dedicated
> |"drivers/hwtracing/qcom/"|directory, similar to the existing
> "|drivers/hwtracing/intel_th"|.
> A more detailed rationale can be found in the cover letter under the
> section /"Why we are proposing this:"/.
>
> *Current status of the patch:*
>
> * Reviewed-by: Jie Gan
> * Acked-by: Konrad Dybcio
>
> We would greatly appreciate it if you could take some time to review
> this patch and share your thoughts. Your feedback would be very
> helpful in moving this effort forward in the right direction.
>
> Thanks a lot for your time and consideration.
>
> Best regards,
> Songwei
>
> On 4/17/2026 3:33 PM, Songwei Chai wrote:
>> We propose creating a new qcom directory under drivers/hwtracing
>> to host this TGU driver, as well as additional Qualcomm-specific
>> hwtracing drivers that we plan to submit in the coming months.
>> This structure will help organize vendor-specific implementations
>> and facilitate future development and maintenance.
>>
>> Feedback from the community on this proposal is highly appreciated.
>>
>> - Why we are proposing this:
>>
>> TGU has the ability to monitor signal conditions and trigger
>> debug-related
>> actions, serving as a programmable hardware component that enhances
>> system
>> trace and debug capabilities. Placing it under drivers/hwtracing aligns
>> with its function as a trace generation utility.
>>
>> We previously attempted to push this driver to
>> drivers/hwtracing/coresight,
>> but did not receive support from the maintainers of the CoreSight
>> subsystem. The reason provided was: “This component is primarily a part
>> of the Qualcomm proprietary QPMDA subsystem, and is capable of operating
>> independently from the CoreSight hardware trace generation system.”
>>
>> Chat history :
>> https://lore.kernel.org/all/CAJ9a7ViKxHThyZfFFDV_FkNRimk4uo1NrMtQ-kcaj1qO4ZcGnA@mail.gmail.com/
>>
>> Given this, we have been considering whether it would be appropriate
>> to create a dedicated drivers/hwtracing/qcom directory for
>> Qualcomm-related hwtracing drivers. This would follow the precedent set
>> by Intel, which maintains its own directory at
>> drivers/hwtracing/intel_th.
>> We believe this structure would significantly facilitate
>> future submissions of related Qualcomm drivers.
>>
>> - Maintenance of drivers/hwtracing/qcom:
>>
>> Bjorn, who maintains linux-arm-msm, will be the maintainer of this
>> directory — we’ve discussed this with him and he’s aware that his task
>> list may grow accordingly. Additionally, Qualcomm engineers familiar
>> with
>> the debug hardware — such as [Tingwei Zhang, Jinlong Mao, Songwei Chai],
>> will be available to review incoming patches and support ongoing
>> development.
>>
>> - Detail for TGU:
>>
>> This component can be utilized to sense a plurality of signals and
>> create a trigger into the CTI or generate interrupts to processors
>> once the input signal meets the conditions. We can treat the TGU’s
>> workflow as a flowsheet, it has some “steps” regions for customization.
>> In each step region, we can set the signals that we want with priority
>> in priority_group, set the conditions in each step via condition_decode,
>> and set the resultant action by condition_select. Meanwhile,
>> some TGUs (not all) also provide timer/counter functionality.
>> Based on the characteristics described above, we consider the TGU as a
>> helper in the CoreSight subsystem. Its master device is the TPDM, which
>> can transmit signals from other subsystems, and we reuse the existing
>> ports mechanism to link the TPDM to the connected TGU.
>>
>> Here is a detailed example to explain how to use the TGU:
>>
>> In this example, the TGU is configured to use 2 conditions, 2 steps, and
>> the timer. The goal is to look for one of two patterns which are
>> generated
>> from TPDM, giving priority to one, and then generate a trigger once the
>> timer reaches a certain value. In other words, two conditions are used
>> for the first step to look for the two patterns, where the one with the
>> highest priority is used in the first condition. Then, in the second
>> step,
>> the timer is enabled and set to be compared to the given value at each
>> clock cycle. These steps are better shown below.
>> |-----------------|
>> | |
>> | TPDM |
>> | |
>> |-----------------|
>> |
>> |
>> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
>> ------
>> | | |
>> | | |--------------------| |
>> | |---- ---> | | Go to next
>> steps | |
>> | | | |--- ---> | Enable
>> timer | |
>> | | v | | | |
>> | | |-----------------| | |--------------------| |
>> | | | | Yes | | |
>> | | | inputs==0xB | ----->| | <-------- |
>> | | | | | | No | |
>> | No | |-----------------| | v | |
>> | | | | |-----------------| | |
>> | | | | | | | |
>> | | | | | timer>=3 |-- |
>> | | v | | | |
>> | | |-----------------| | |-----------------| |
>> | | | | Yes | | |
>> | |--- | inputs==0xA | ----->| | Yes |
>> | | | | |
>> | |-----------------| v |
>> | |-----------------| |
>> | | | |
>> | | Trigger | |
>> | | | |
>> | |-----------------| |
>> | TGU | |
>> |--- --- --- --- --- --- --- --- --- --- --- --- --- --- |---
>> --- -- |
>> |
>> v
>> |-----------------|
>> |The controllers |
>> |which will use |
>> |triggers further |
>> |-----------------|
>>
>> steps:
>> 1. Reset TGU /*it will disable tgu and reset dataset*/
>> - echo 1 > /sys/bus/amba/devices/<tgu-name>/reset_tgu
>>
>> 2. Set the pattern match for priority0 to 0xA = 0b1010 and for
>> priority 1 to 0xB = 0b1011.
>> - echo 0x11113232 >
>> /sys/bus/amba/devices/<tgu-name>/step0_priority0/reg0
>> - echo 0x11113233 >
>> /sys/bus/amba/devices/<tgu-name>/step0_priority1/reg0
>>
>> Note:
>> Bit distribution diagram for each priority register
>> |-------------------------------------------------------------------|
>> | Bits | Field Nam | Description |
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 29:28 | SEL_BIT7_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 25:24 | SEL_BIT6_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 21:20 | SEL_BIT5_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 17:16 | SEL_BIT4_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 13:12 | SEL_BIT3_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 9:8 | SEL_BIT2_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 5:4 | SEL_BIT1_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 1:0 | SEL_BIT0_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> These bits are used to identify the signals we want to sense, with
>> a maximum signal number of 140. For example, to sense the signal
>> 0xA (binary 1010), we set the value of bits 0 to 13 to 3232, which
>> represents 1010. The remaining bits are set to 1, as we want to use
>> AND gate to summarize all the signals we want to sense here. For
>> rising or falling edge detection of any input to the priority, set
>> the remaining bits to 0 to use an OR gate.
>>
>> 3. look for the pattern for priority_i i=0,1.
>> - echo 0x3 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_decode/reg0
>> - echo 0x30 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_decode/reg1
>>
>> |-------------------------------------------------------------------------------|
>> | Bits | Field Nam |
>> Description |
>> |-------------------------------------------------------------------------------|
>> | | |For each decoded
>> condition, this |
>> | 24 | NOT |inverts the output. If
>> the condition |
>> | | |decodes to true, and
>> the NOT field |
>> | | |is '1', then the output
>> is NOT true. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | 21 | BC0_COMP_ACTIVE |comparator will be
>> actively included in|
>> | | |the decoding of this
>> particular |
>> | | |condition. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | | |comparator will need to
>> be 1 to affect |
>> | 20 | BC0_COMP_HIGH |the decoding of this
>> condition. |
>> | | |Conversely, a '0' here
>> requires a '0' |
>> | | |from the
>> comparator |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | 17 | |comparator will be
>> actively included in|
>> | | TC0_COMP_ACTIVE |the decoding of this
>> particular |
>> | | |condition. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | | |comparator will need to
>> be 1 to affect |
>> | 16 | TC0_COMP_HIGH |the decoding of this
>> particular |
>> | | |condition.Conversely, a 0 here |
>> | | |requires a '0' from the
>> comparator |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |OR logic will be
>> actively |
>> | 4n+3 | Priority_n_OR_ACTIVE|included in the
>> decoding of |
>> | | (n=0,1,2,3) |this particular
>> condition. |
>> | | | |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |will need to be '1' to
>> affect the |
>> | 4n+2 | Priority_n_OR_HIGH |decoding of this
>> particular |
>> | | (n=0,1,2,3) |condition. Conversely,
>> a '0' here |
>> | | |requires a '0' from
>> Priority_n OR logic|
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |AND logic will be
>> actively |
>> | 4n+1 |Priority_n_AND_ACTIVE|included in the
>> decoding of this |
>> | | (n=0,1,2,3) |particular
>> condition. |
>> | | | |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |AND logic will need to
>> be '1' to |
>> | 4n | Priority_n_AND_HIGH |affect the decoding of
>> this |
>> | | (n=0,1,2,3) |particular condition.
>> Conversely, |
>> | | |a '0' here requires a
>> '0' from |
>> | | |Priority_n AND
>> logic. |
>> |-------------------------------------------------------------------------------|
>> Since we use `priority_0` and `priority_1` with an AND output in
>> step 2, we set `0x3`
>> and `0x30` here to activate them.
>>
>> 4. Set NEXT_STEP = 1 and TC0_ENABLE = 1 so that when the conditions
>> are met then the next step will be step 1 and the timer will
>> be enabled.
>> - echo 0x20008 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_select/reg0
>> - echo 0x20008 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_select/reg1
>>
>> |-----------------------------------------------------------------------------|
>> | Bits | Field Nam |
>> Description |
>> |-----------------------------------------------------------------------------|
>> | | |This field defines the
>> next step the |
>> | 18:17 | NEXT_STEP |TGU will 'goto' for the
>> associated |
>> | | |Condition and
>> Step. |
>> |-----------------------------------------------------------------------------|
>> | | |For each possible output
>> trigger |
>> | 13 | TRIGGER |available, set a '1' if
>> you want |
>> | | |the trigger to go active
>> for the |
>> | | |associated condition and
>> Step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause BC0 to
>> increment if the|
>> | 9 | BC0_INC |associated Condition is
>> decoded for |
>> | | |this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause BC0 to
>> decrement if the|
>> | 8 | BC0_DEC |associated Condition is
>> decoded for |
>> | | |this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will clear BC0 count
>> value to 0 if|
>> | 7 | BC0_CLEAR |the associated Condition
>> is decoded |
>> | | |for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause TC0 to
>> increment until |
>> | 3 | TC0_ENABLE |paused or cleared if the
>> associated |
>> | | |Condition is decoded for
>> this step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause TC0 to
>> pause until |
>> | 2 | TC0_PAUSE |enabled if the associated
>> Condition |
>> | | |is decoded for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will clear TC0 count
>> value to 0 |
>> | 1 | TC0_CLEAR |if the associated
>> Condition is |
>> | | |decoded for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will set the done
>> signal to the |
>> | 0 | DONE |TGU FSM if the associated
>> Condition |
>> | | |is decoded for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> Based on the distribution diagram, we set `0x20008` for
>> `priority0` and `priority1` to
>> achieve "jump to step 1 and enable TC0" once the signal is sensed.
>>
>> 5. activate the timer comparison for this step.
>> - echo 0x30000 >
>> /sys/bus/amba/devices/<tgu-name>/step1_condition_decode/reg0
>>
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | 17 | |comparator will be
>> actively included in|
>> | | TC0_COMP_ACTIVE |the decoding of this
>> particular |
>> | | |condition. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | | |comparator will need to
>> be 1 to affect |
>> | 16 | TC0_COMP_HIGH |the decoding of this
>> particular |
>> | | |condition.Conversely, a 0 here |
>> | | |requires a '0' from the
>> comparator |
>> |-------------------------------------------------------------------------------|
>> Accroding to the decode distribution diagram , we give 0x30000
>> here to set 16th&17th bit
>> to enable timer comparison.
>>
>> 6. Set the NEXT_STEP = 0 and TC0_PAUSE = 1 and TC0_CLEAR = 1
>> once the timer
>> has reached the given value.
>> - echo 0x6 >
>> /sys/bus/amba/devices/<tgu-name>/step1_condition_select/reg0
>>
>> 7. Enable Trigger 0 for TGU when the condition 0 is met in step1,
>> i.e. when the timer reaches 3.
>> - echo 0x2000 >
>> /sys/bus/amba/devices/<tgu-name>/step1_condition_select/default
>>
>> Note:
>> 1. 'default' register allows for establishing the resultant
>> action for
>> the default condition
>>
>> 2. Trigger:For each possible output trigger available from
>> the Design document, there are three triggers: interrupts, CTI,
>> and Cross-TGU mapping.All three triggers can occur, but
>> the choice of which trigger to use depends on the user's
>> needs.
>>
>> 8. Compare the timer to 3 in step 1.
>> - echo 0x3 > /sys/bus/amba/devices/<tgu-name>/step1_timer/reg0
>>
>> 9. enale tgu
>> - echo 1 > /sys/bus/amba/devices/<tgu-name>/enable_tgu
>> ---
>> Link to V13:
>> https://lore.kernel.org/all/20260402092838.341295-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V14:
>> - Fix some typos and formatting.
>> ---
>> Link to V12:
>> https://lore.kernel.org/all/20260317032639.2393221-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V13:
>> - add ":" after "KernelVersion"
>> - add an enablement check in the enable function to avoid increasing
>> the counter each time
>> ---
>> Link to V11:
>> https://lore.kernel.org/all/ee1ca8e6-8e5f-47d8-8a24-f904ee2fc6d0@oss.qualcomm.com/
>>
>> Changes in V12:
>> - Remove the in-ports property from the bindings, as this device is
>> decoupled from CoreSight.
>> - Update kernel version and date.
>> ---
>> Link to V10:
>> https://lore.kernel.org/all/20c5406d-3e9f-4fdb-84ba-4cbe629c79b5@oss.qualcomm.com/
>>
>> Changes in V11:
>> - Change the names of members in drvdata: max_xxx -> num_xxx, enable
>> -> enabled
>> - Use "FIELD_GET" to replace "BMVAL"
>> - Use devm_kcalloc to replace devm_kzalloc once create members of
>> value_table
>> - Keep a consistent \n above return
>> - Keep reverse-Christmas-tree style
>> - Add checks so that the enable and reset nodes only accept 0 or 1
>> ---
>> Link to V9:
>> https://lore.kernel.org/all/20251219065902.2296896-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V10:
>> - Modified code formatting based on Jie's feedback to improve
>> readability.
>> - Applied inverse Christmas tree order to the variables.
>> ---
>> Link to V8:
>> https://lore.kernel.org/all/20251203090055.2432719-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V9:
>> - Decoupled the tgu driver from coresight header file and registered
>> it as an amba device.
>> - Retained Rob's reviewed-by tag on patch1/7 since the file remains
>> unchanged.
>> - Updated the sysfs node path in the Documentation directory.
>> ---
>> Link to V7:
>> https://lore.kernel.org/all/20251104064043.88972-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V8:
>> - Add "select" section in bindings.
>> - Update publish date in "sysfs-bus-coresight-devices-tgu".
>> ---
>> Link to V6:
>> https://lore.kernel.org/all/20250709104114.22240-1-songchai@qti.qualcomm.com/
>>
>> Changes in V7:
>> - Move the TGU code location from 'drivers/hwtracing/coresight/' to
>> 'drivers/hwtracing/qcom/'.
>> - Rename the spinlock used in the code from 'spinlock' to 'lock'.
>> - Perform the 'calculate_array_location' separately, instead of doing
>> it within the function.
>> - Update the sender email address.
>> ---
>> Link to V5:
>> https://lore.kernel.org/all/20250529081949.26493-1-quic_songchai@quicinc.com/
>>
>> Changes in V6:
>> - Replace spinlock with guard(spinlock) in tgu_enable.
>> - Remove redundant blank line.
>> - Update publish date and contact member's name in
>> "sysfs-bus-coresight-devices-tgu".
>> ---
>> Link to V4:
>> https://patchwork.kernel.org/project/linux-arm-msm/cover/20250423101054.954066-1-quic_songchai@quicinc.com/
>>
>> Changes in V5:
>> - Update publish date and kernel_version in
>> "sysfs-bus-coresight-devices-tgu"
>> ---
>> Link to V3:
>> https://lore.kernel.org/all/20250227092640.2666894-1-quic_songchai@quicinc.com/
>>
>> Changes in V4:
>> - Add changlog in coverletter.
>> - Correct 'year' in Copyright in patch1.
>> - Correct port mechansim description in patch1.
>> - Remove 'tgu-steps','tgu-regs','tgu-conditions','tgu-timer-counters'
>> from dt-binding
>> and set them through reading DEVID register as per Mike's suggestion.
>> - Modify tgu_disable func to make it have single return point in
>> patch2 as per
>> Mike's suggestion.
>> - Use sysfs_emit in enable_tgu_show func in ptach2.
>> - Remove redundant judgement in enable_tgu_store in patch2.
>> - Correct typo in description in patch3.
>> - Set default ret as SYSFS_GROUP_INVISIBLE, and returnret at end in
>> pacth3 as
>> per Mike's suggestion.
>> - Remove tgu_dataset_ro definition in patch3
>> - Use #define constants with explanations of what they are rather than
>> arbitrary magic numbers in patch3 and patch4.
>> - Check -EINVAL before using 'calculate_array_location()' in array in
>> patch4.
>> - Add 'default' in 'tgu_dataset_show''s switch part in patch4.
>> - Document the value needed to initiate the reset in pacth7.
>> - Check "value" in 'reset_tgu_store' and bail out with an error code
>> if 0 in patch7.
>> - Remove dev_dbg in 'reset_tgu_store' in patch7.
>> ---
>> Link to V2:
>> https://lore.kernel.org/all/20241010073917.16023-1-quic_songchai@quicinc.com/
>>
>> Changes in V3:
>> - Correct typo and format in dt-binding in patch1
>> - Rebase to the latest kernel version
>> ---
>> Link to V1:
>> https://lore.kernel.org/all/20240830092311.14400-1-quic_songchai@quicinc.com/
>>
>> Changes in V2:
>> - Use real name instead of login name,
>> - Correct typo and format in dt-binding and code.
>> - Bring order in tgu_prob(declarations with and without
>> assignments) as per
>> Krzysztof's suggestion.
>> - Add module device table in patch2.
>> - Set const for tgu_common_grp and tgu_ids in patch2.
>> - Initialize 'data' in tgu_ids to fix the warning in pacth2.
>> ---
>> Songwei Chai (7):
>> dt-bindings: arm: Add support for Qualcomm TGU trace
>> qcom-tgu: Add TGU driver
>> qcom-tgu: Add signal priority support
>> qcom-tgu: Add TGU decode support
>> qcom-tgu: Add support to configure next action
>> qcom-tgu: Add timer/counter functionality for TGU
>> qcom-tgu: Add reset node to initialize
>>
>> .../ABI/testing/sysfs-bus-amba-devices-tgu | 51 ++
>> .../devicetree/bindings/arm/qcom,tgu.yaml | 71 ++
>> drivers/Makefile | 1 +
>> drivers/hwtracing/Kconfig | 2 +
>> drivers/hwtracing/qcom/Kconfig | 20 +
>> drivers/hwtracing/qcom/Makefile | 3 +
>> drivers/hwtracing/qcom/tgu.c | 704 ++++++++++++++++++
>> drivers/hwtracing/qcom/tgu.h | 275 +++++++
>> 8 files changed, 1127 insertions(+)
>> create mode 100644
>> Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,tgu.yaml
>> create mode 100644 drivers/hwtracing/qcom/Kconfig
>> create mode 100644 drivers/hwtracing/qcom/Makefile
>> create mode 100644 drivers/hwtracing/qcom/tgu.c
>> create mode 100644 drivers/hwtracing/qcom/tgu.h
>>
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Joey Lu @ 2026-06-29 3:47 UTC (permalink / raw)
To: Icenowy Zheng, Conor Dooley
Cc: Conor Dooley, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn>
On 6/26/2026 5:33 PM, Icenowy Zheng wrote:
> 在 2026-06-26五的 10:26 +0100，Conor Dooley写道：
>> On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote:
>>> 在 2026-06-26五的 08:19 +0100，Conor Dooley写道：
>>>> On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng wrote:
>>>>> 在 2026-06-25四的 17:33 +0100，Conor Dooley写道：
>>>>>> On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
>>>>>>> +allOf:
>>>>>>> + - if:
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + contains:
>>>>>>> + const: thead,th1520-dc8200
>>>>>>> + then:
>>>>>>> + properties:
>>>>>>> + clocks:
>>>>>>> + minItems: 5
>>>>>>> + maxItems: 5
>>>>>>> +
>>>>>>> + clock-names:
>>>>>>> + minItems: 5
>>>>>>> + maxItems: 5
>>>>>> All the maxItems here repeat the maximum constraint and do
>>>>>> nothing.
>>>>>>
>>>>>> Since you didn't change the minimum constraint at the top
>>>>>> level,
>>>>>> your
>>>>>> minItems also do nothing.
>>>>>>
>>>>>>> +
>>>>>>> + resets:
>>>>>>> + minItems: 3
>>>>>>> + maxItems: 3
>>>>>>> +
>>>>>>> + reset-names:
>>>>>>> + minItems: 3
>>>>>>> + maxItems: 3
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - resets
>>>>>>> + - reset-names
>>>>>> Both conditional sections have this, but the original binding
>>>>>> doesn't
>>>>>> require these for the thead device. This is a functional
>>>>>> change
>>>>>> therefore and shouldn't be in a patch calling itself
>>>>>> "generalise
>>>>>> for
>>>>>> single ended variants".
>>>>> Well yes they're required.
>>>>>
>>>>> Should I send a patch adding the `thead,th1520-dc8200` part of
>>>>> the
>>>>> schema?
>>>> If you mean the code above, no. Adding a conditional section when
>>>> there's only that compatible doesn't make sense.
>>>>
>>>> What you could do is just add it at the top level though, which
>>>> would
>>>> also benefit this patch since it'd not have to be conditionally
>>>> added
>>>> for the new nuvoton device.
>>>> Just note in your commit message about what the ABI impact of the
>>>> change
>>>> to required properties is (effectively nothing because it's
>>>> optional
>>>> in
>>>> the driver and the only user has the properties).
>>> Okay, I will craft such a patch and send it.
>>>
>>>>>>> +
>>>>>>> + resets:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + reset-names:
>>>>>>> + items:
>>>>>>> + - const: core
>>>>>> This is just maxItems: 1.
>>>>> Well the implicit rules of DT binding schemas are quite
>>>>> weird...
>>>> I don't think it is that strange, as the binding has
>>>> reset-names:
>>>> items:
>>>> - const: core
>>>> - const: axi
>>>> - const: ahb
>>> Ah does the list constraint the order of items? If it constrains
>>> the
>> It does, yes.
>> Alternatively, using an enum permits free ordering.
> Ah in this case this should be converted to an enum, I think.
>
> Should I send a patch for converting it?
>
> Thanks,
> Icenowy
Thank you all for the detailed review and discussion, it really helped
clarify the right approach.
Since I will supply all four clocks with the same phandle for core/axi/ahb,
and only one reset "core" for MA35D1, the ordering constraint in the
`items` list is not a problem, "core" is already the first entry. There
is no need to convert to an enum.
Regarding the clock situation for the MA35D1: I agree with supplying all
four clocks (core, axi, ahb, pix0) in the devicetree, even though the
MA35D1 clock controller gates core/axi/ahb with a single bit. The DT will
use the same clock phandle for core, axi, and ahb:
clocks = <&clk X>, <&clk X>, <&clk X>, <&pix_clk Y>;
clock-names = "core", "axi", "ahb", "pix0";
This correctly models the hardware topology. Since all three names resolve
to the same underlying clock node, the CCF's standard enable refcounting
handles the shared gate correctly without any custom implementation needed.
I will also revert the change in patch 4/7 that made axi and ahb clocks
optional, since they will now always be provided in the devicetree.
Regarding moving `resets` and `reset-names` to the top-level `required:`,
I will wait for Icenowy's patch to land before sending v6 to avoid
duplicating the work.
In v6 I will update patch 1/7 with:
- Update the subject to "dt-bindings: display: verisilicon,dc: add
support for nuvoton,ma35d1-dcu"
- Lower `clocks`/`clock-names` `minItems` to 4 at the top level
- Remove the `thead,th1520-dc8200` conditional block entirely
- Keep only the `nuvoton,ma35d1-dcu` conditional block, using only
`maxItems: 4` for clocks/clock-names and `maxItems: 1` for
resets/reset-names to tighten the top-level constraints
BR,
Joey
>>> order, it partly breaks the intention of having names; if it does
>>> not
>>> constrain the order, it needs to be clarified that the required 1
>>> reset
>>> is core instead of the other two.
>> Given the discussion we're having on the clocks, I wonder if this is
>> also an oversimplification and the IP has three resets inputs hooked
>> up
>> to one output of the reset controller (or 3 outputs controlled by one
>> bit..).
^ permalink raw reply
* Re: [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: Joey Lu @ 2026-06-29 3:48 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <cf9af38dfe52548649b9010f298341d4064aaa21.camel@iscas.ac.cn>
On 6/26/2026 4:03 PM, Icenowy Zheng wrote:
> 在 2026-06-25四的 17:44 +0800，Joey Lu写道：
>> The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller
>> whose
>> AXI and AHB bus clocks share a single gate enable bit with the
>> display
>> core clock, so the clock driver does not expose them separately. This
>> patch makes the axi and ahb clocks optional in the probe.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ```
> Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ```
>
> Thanks,
> Icenowy
Thank you for the review. I will revert this patch entirely. As discussed
in the binding review, axi and ahb clocks will now always be supplied in
the devicetree using the same phandle as the core clock gate, so making
them optional in the driver is no longer needed.
>> ---
>> drivers/gpu/drm/verisilicon/vs_dc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index 9729b693d360..fd1f5fe67a68 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> return PTR_ERR(dc->core_clk);
>> }
>>
>> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
>> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
>> if (IS_ERR(dc->axi_clk)) {
>> dev_err(dev, "can't get axi clock\n");
>> return PTR_ERR(dc->axi_clk);
>> }
>>
>> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
>> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
>> if (IS_ERR(dc->ahb_clk)) {
>> dev_err(dev, "can't get ahb clock\n");
>> return PTR_ERR(dc->ahb_clk);
^ 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