* [PATCH v5 4/5] arm64: dts: exynos: gs101: Add thermal management unit
From: Tudor Ambarus @ 2026-05-25 12:50 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
Alim Akhtar
Cc: jyescas, linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Tudor Ambarus
In-Reply-To: <20260525-acpm-tmu-v5-0-85fde739752e@linaro.org>
Add the Thermal Management Unit (TMU) support for the Google GS101 SoC.
Describe the TMU using a consolidated SoC node that includes memory
resources for interrupt identification and a phandle to the ACPM IPC
interface for functional control.
Define thermal zones for the little, mid, and big CPU clusters, including
associated trip points and cooling-device maps to enable thermal
mitigation.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101-tmu.dtsi | 136 +++++++++++++++++++++++
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 18 +++
2 files changed, 154 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-tmu.dtsi b/arch/arm64/boot/dts/exynos/google/gs101-tmu.dtsi
new file mode 100644
index 000000000000..b27d1a539ec2
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/google/gs101-tmu.dtsi
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Google GS101 TMU configurations device tree source
+ *
+ * Copyright 2020 Samsung Electronics Co., Ltd.
+ * Copyright 2020 Google LLC.
+ * Copyright 2026 Linaro Ltd.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+ thermal-zones {
+ cpucl2-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&tmu_top 0>;
+
+ trips {
+ big_switch_on: big-switch-on {
+ temperature = <80000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ big_mitigate: big-mitigate {
+ temperature = <90000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ big_hot: big-hot {
+ temperature = <100000>;
+ hysteresis = <5000>;
+ type = "hot";
+ };
+
+ big_critical: big-critical {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&big_mitigate>;
+ cooling-device = <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ cpucl1-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&tmu_top 1>;
+
+ trips {
+ mid_switch_on: mid-switch-on {
+ temperature = <80000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ mid_mitigate: mid-mitigate {
+ temperature = <90000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ mid_hot: mid-hot {
+ temperature = <100000>;
+ hysteresis = <5000>;
+ type = "hot";
+ };
+
+ mid_critical: mid-critical {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&mid_mitigate>;
+ cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ cpucl0-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&tmu_top 2>;
+
+ trips {
+ little_switch_on: little-switch-on {
+ temperature = <80000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ little_mitigate: little-mitigate {
+ temperature = <90000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ little_hot: little-hot {
+ temperature = <100000>;
+ hysteresis = <5000>;
+ type = "hot";
+ };
+
+ little_critical: little-critical {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&little_mitigate>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 86933f22647b..b6866ef99fb3 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -74,6 +74,7 @@ cpu0: cpu@0 {
compatible = "arm,cortex-a55";
reg = <0x0000>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL0>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&ananke_cpu_sleep>;
capacity-dmips-mhz = <250>;
@@ -86,6 +87,7 @@ cpu1: cpu@100 {
compatible = "arm,cortex-a55";
reg = <0x0100>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL0>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&ananke_cpu_sleep>;
capacity-dmips-mhz = <250>;
@@ -98,6 +100,7 @@ cpu2: cpu@200 {
compatible = "arm,cortex-a55";
reg = <0x0200>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL0>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&ananke_cpu_sleep>;
capacity-dmips-mhz = <250>;
@@ -110,6 +113,7 @@ cpu3: cpu@300 {
compatible = "arm,cortex-a55";
reg = <0x0300>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL0>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&ananke_cpu_sleep>;
capacity-dmips-mhz = <250>;
@@ -122,6 +126,7 @@ cpu4: cpu@400 {
compatible = "arm,cortex-a76";
reg = <0x0400>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL1>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&enyo_cpu_sleep>;
capacity-dmips-mhz = <620>;
@@ -134,6 +139,7 @@ cpu5: cpu@500 {
compatible = "arm,cortex-a76";
reg = <0x0500>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL1>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&enyo_cpu_sleep>;
capacity-dmips-mhz = <620>;
@@ -146,6 +152,7 @@ cpu6: cpu@600 {
compatible = "arm,cortex-x1";
reg = <0x0600>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL2>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&hera_cpu_sleep>;
capacity-dmips-mhz = <1024>;
@@ -158,6 +165,7 @@ cpu7: cpu@700 {
compatible = "arm,cortex-x1";
reg = <0x0700>;
clocks = <&acpm_ipc GS101_CLK_ACPM_DVFS_CPUCL2>;
+ #cooling-cells = <2>;
enable-method = "psci";
cpu-idle-states = <&hera_cpu_sleep>;
capacity-dmips-mhz = <1024>;
@@ -639,6 +647,15 @@ watchdog_cl1: watchdog@10070000 {
status = "disabled";
};
+ tmu_top: thermal-sensor@100a0000 {
+ compatible = "google,gs101-tmu-top";
+ reg = <0x100a0000 0x800>;
+ clocks = <&cmu_misc CLK_GOUT_MISC_TMU_TOP_PCLK>;
+ interrupts = <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH 0>;
+ samsung,acpm-ipc = <&acpm_ipc>;
+ #thermal-sensor-cells = <1>;
+ };
+
trng: rng@10141400 {
compatible = "google,gs101-trng",
"samsung,exynos850-trng";
@@ -1862,3 +1879,4 @@ timer {
};
#include "gs101-pinctrl.dtsi"
+#include "gs101-tmu.dtsi"
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v5 3/5] MAINTAINERS: Add entry for Samsung Exynos ACPM thermal driver
From: Tudor Ambarus @ 2026-05-25 12:50 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
Alim Akhtar
Cc: jyescas, linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Tudor Ambarus,
Krzysztof Kozlowski
In-Reply-To: <20260525-acpm-tmu-v5-0-85fde739752e@linaro.org>
Add a MAINTAINERS entry for the Samsung Exynos ACPM thermal driver.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..7ea3b9d95ccd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23660,6 +23660,14 @@ F: drivers/clk/samsung/clk-acpm.c
F: drivers/firmware/samsung/exynos-acpm*
F: include/linux/firmware/samsung/exynos-acpm-protocol.h
+SAMSUNG EXYNOS ACPM THERMAL DRIVER
+M: Tudor Ambarus <tudor.ambarus@linaro.org>
+L: linux-kernel@vger.kernel.org
+L: linux-samsung-soc@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/thermal/google,gs101-tmu-top.yaml
+F: drivers/thermal/samsung/acpm-tmu.c
+
SAMSUNG EXYNOS MAILBOX DRIVER
M: Tudor Ambarus <tudor.ambarus@linaro.org>
L: linux-kernel@vger.kernel.org
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* Re: [PATCH 2/5] remoteproc: imx_rpoc: fix carveout name parsing
From: Laurentiu Mihalcea @ 2026-05-25 12:31 UTC (permalink / raw)
To: Peng Fan
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam, Pengutronix Kernel Team,
linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ahOwO7LBXCYFIngw@shlinux89>
On 5/24/2026 7:13 PM, Peng Fan wrote:
> On Fri, May 22, 2026 at 04:18:46AM -0700, Laurentiu Mihalcea wrote:
>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>
>> The imx remoteproc driver assumes that the names of the reserved memory
>> regions reflect their usage (e.g. "vdevbuffer", "vdev0vring0", etc.). This
>> conflicts with the devicetree specification's recommendation, which states
>> that the names of the devicetree nodes should be generic.
>>
>> Therefore, instead of relying on the node names, use the names passed via
>> the "memory-region-names" property if present. Otherwise, keep the old
>> behavior.
>>
>> The definition of imx_rproc_rmem_to_resource() is added to a common place
>> as imx_dsp_rproc.c can also use it given that it suffers from the same
>> aforementioned problem.
>>
>> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>> ---
>> drivers/remoteproc/imx_rproc.c | 7 +++++--
>> drivers/remoteproc/imx_rproc.h | 19 +++++++++++++++++++
>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
>> index 7f54322244ac..1ee1c658dcc1 100644
>> --- a/drivers/remoteproc/imx_rproc.c
>> +++ b/drivers/remoteproc/imx_rproc.c
>> @@ -672,7 +672,7 @@ static int imx_rproc_prepare(struct rproc *rproc)
>> int err;
>> struct resource res;
>>
>> - err = of_reserved_mem_region_to_resource(np, i++, &res);
>> + err = imx_rproc_rmem_to_resource(np, i++, &res);
>> if (err)
>> break;
>>
>> @@ -850,11 +850,14 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>> if (nph <= 0)
>> return 0;
>>
>> + if (!of_property_present(np, "memory-region-names"))
>> + dev_warn(dev, "using node names for carveouts should be avoided\n");
>
> Please check 'memory-regions && !memory-region-names', some demos may not
> need to use memory regions.
>
> Regards
> Peng
>
What for? You'll not reach this check unless "memory-regions" is specified?
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-25 12:28 UTC (permalink / raw)
To: Chancel Liu (OSS), Frank Li
Cc: Chancel Liu, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org
In-Reply-To: <AM9PR04MB835333895276201A81251210E30A2@AM9PR04MB8353.eurprd04.prod.outlook.com>
On 25/05/2026 08:26, Chancel Liu (OSS) wrote:
>>>>>>>>>>> +description:
>>>>>>>>>>> + The NXP I/O connector represents a physically present I/O
>>>>>>>>>>> +connector on the
>>>>>>>>>>> + base board. It acts as a nexus that exposes a constrained
>>>>>>>>>>> +set
>>>>>> of
>>>>>>>>>>> +I/O
>>>>>>>>>>> + resources, such as GPIOs, clocks, PWMs and interrupts,
>>>>>>>>>>> +through fixed
>>>>>>>>>>> + electrical wiring. All actual hardware providers reside on
>>>>>>>>>>> +the
>>>>>> base
>>>>>>>> board.
>>>>>>>>>>> + The connector node only defines index-based mappings to
>>>>>>>>>>> + those
>>>>>>>>>> providers.
>>>>>>>>>>> +
>>>>>>>>>>> +properties:
>>>>>>>>>>> + compatible:
>>>>>>>>>>> + const: fsl,io-connector
>>>>>>>>>>
>>>>>>>>>> Everything is IO. Everything is connector, so your compatible
>>>>>>>>>> does not match requirements from writing bindings.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, this compatible is too generic. I will rename the
>>>>>>>>> compatible to fsl,aud-io-connector.
>>>>>>>>
>>>>>>>> aud is not much better. Which boards have it? What's the pinout?
>>>>>> What's
>>>>>>>> standard? Is it described anywhere? If so, provide reference to
>>>>>> spec/docs.
>>>>>>>>
>>>>>>>
>>>>>>> This is not an industry standard electrical interface. This
>>>>>>> connector
>>>>>>
>>>>>> Then if you do not have standard, then you have board specific
>>>>>> layouts thus you need board-specific compatibles. You can use
>>>>>> fallbacks. Generic fallback could work, but both io-connector and
>>>>>> aud-io-connector are just too generic. Every connector is
>>>>>> "connector" and "io", thus absolutely anything can be
>>>>>> "io-connector". "aud" improves it only a bit, thus honestly I would
>> go with board specific fallback as well.
>>>>>>
>>>>>
>>>>> How about board specific + common fallback compatible like this:
>>>>> compatible:
>>>>> items:
>>>>> - enum:
>>>>> - fsl,imx95-19x19-evk-aud-io-connector
>>>>> - fsl,imx952-evk-aud-io-connector
>>>>> - const: fsl,imx-aud-io-connector Since the daughter board is
>>>>> named “IMX-AUD-IO” in publicly available
>>>>
>>>> I don't think it is named like that.
>>>>
>>>> git grep -i imx-aud-io
>>>>
>>>>> documentation, common compatible clearly indicates that this
>>>>> connector is intended for that.
>>>>>
>>>>> Also, I want to talk about the topic of generic connector. It's a
>>>>> common design that daughter board is connected to base board through
>>>>> a connector. This connector more often acts as a nexus that exposes
>>>>> a constrained subset of GPIO, clock, PWM and interrupt resources to
>>>>> the daughter board. Can we document this kind of connector as a
>>>>> generic binding?
>>>>
>>>> So this binding is the connector between carrier and some addon? Then
>>>> you don't get a compatible for that at all, because it is not
>>>> necessary, not useful and NEVER used. Do you see socket LGA "connector"
>> bindings? No.
>>>
>>> Not exactly. Any connector connects a carrier board with an add-on
>> board.
>>> The key point here is that this connector type is reused across
>>> different boards, even though it is not an industry-standard
>>> connector. Both the signal definitions and the mechanical layout are
>> defined.
>>>
>>> The same add-on boards can therefore be reused across different base
>>> boards that use this type of connector.
>>>
>>> There are also GPIO mappings involved. For example, pin 1 on the
>>> connector may represent reset-gpios, but it could be connected to
>>> GPIO0 on board A and GPIO1 on board B.
>>>
>>> Without a connector definition layer, this would create an N × M
>>> combination problem. The Nexus node discussion already covered this
>> topic:
>>> https://osseu2025.sched.com/event/25Vrw
>>>
>>> An LGA socket is a CPU socket, where the signals are completely
>>> transparent to software, so it is not a good comparison. A PCIe M.2
>>> Key-M/E connector would be a more appropriate comparison.
>>>
>>
>> So the terminology of daughter and carrier boards was confusing. If this
>> is a hat, mezzanine or other addon, it's fine.
>>
>
> The IMX-AUD-IO is an add-on board that attaches to the base board. To
> make it clearer, I will replace "daughter board" with "add-on board"
> throughout descriptions.
>
>> I still insist on board specific compatibles - fallback and specific.
>>
>
> The base board has a slot component that is mechanically compatible
> with a PCIe x8 connector. However, it carries no PCIe signals and the
> pins are repurposed to carry fixed board-level audio I/O related
> signals.
>
> I think we can name a compatible reflects a standard mechanical form
> factor.
> For the compatibles (specific + fallback) I propose:
> - enum:
> - fsl,imx95-19x19-evk-aud-io-pcie-x8-slot
> - fsl,imx952-evk-aud-io-pcie-x8-slot
> - const: fsl,aud-io-pcie-x8-slot
Does not solve my request, so I won't ack it. Maybe you will get ack
from other DT maintainer then.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 05/10] dt-bindings: arm: fsl: Add solidrun lx2160a twins board
From: Krzysztof Kozlowski @ 2026-05-25 12:27 UTC (permalink / raw)
To: Josua Mayer
Cc: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yazan Shhady, Jon Nettleton, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <e26e0b56-a91f-43ff-9268-1b885dafba89@solid-run.com>
On 14/05/2026 12:12, Josua Mayer wrote:
> Hi Krzysztof,
>
> Am 14.05.26 um 08:43 schrieb Krzysztof Kozlowski:
>> On Tue, May 12, 2026 at 04:39:00PM +0200, Josua Mayer wrote:
>>> The SolidRun LX2160A Twins board supports two configurations, one with
>>> with a sinle CEX-7 module, and one with two (dual).
>>>
>>> The dual configuration was not yet tested.
>> And how do see dual configuration? New compatible? For the same
>> hardware (the same because from SoC point of view it will be exactly
>> the same)?
>
> From SoC point of view the sides are different, and the hardware looks different
> when it is assembled for dual configuration. Most notably each cpu in dual
> version only sees 12 SFP connectors each, while the single sees 20.
>
> Further the port numbering might be different between left and right side cpu.
>
> Finally there are some complications in the current pcb version with resource
> distribution (i.e. fans, leds).
>
>>
>> You must post complete binding, otherwise this feels risky and when you
>> actually try running dual configuration you will see that existing
>> binding makes no sense.
>
> I thought about this and decided against it.
>
> The single version is simple to describe, the cpu always sits in the right side socket,
> sees 20 SFP connectors and has full control over every peripheral.
>
> The dual version will require different description even if only one cpu is installed.
>
> Currently dual is hardware only without any software, and changes may or may not
> be made to the PCB to simplify things. Therefore I avoided drafting any bindings.
OK, one compatible is also fine, but your earlier explanation this
should be part of the commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/6] firmware: samsung: acpm: TMU support and cleanups
From: Krzysztof Kozlowski @ 2026-05-25 12:25 UTC (permalink / raw)
To: Alexey Klimov, Michael Turquette, Stephen Boyd, Lee Jones,
Tudor Ambarus
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <DIR9DLGP2EN5.21HR8BY11G5SF@linaro.org>
On 25/05/2026 00:26, Alexey Klimov wrote:
> On Sun May 24, 2026 at 8:40 PM BST, Krzysztof Kozlowski wrote:
>>
>> On Fri, 15 May 2026 09:32:24 +0000, Tudor Ambarus wrote:
>>> This series introduces protocol support for the Exynos
>>> Thermal Management Unit (TMU) to the ACPM driver, alongside several
>>> cleanups.
>>>
>>> Dependencies
>>> ============
>>> Krzysztof, these patches together with the acpm fixes from your `fixes`
>>> branch will be needed by the thermal maintainers. I'm going to send the
>>> ACPM TMU (thermal) driver for review. In case they'll take it for the
>>> next release, we'll need an immutable tag with the acpm fixes, cleanup
>>> and thermal helpers. Thanks!
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [1/6] firmware: samsung: acpm: Consolidate transfer initialization helper
>> https://git.kernel.org/krzk/linux/c/43d3733b7ffd82b2bfeda69befa2a179335dfe6c
>> [2/6] firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
>> https://git.kernel.org/krzk/linux/c/7b20fd06f783c1e901d34305c68df16212cdf669
>> [3/6] firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
>> https://git.kernel.org/krzk/linux/c/ef1109e4b6120a52be1ea66d486d6744d0c5ac47
>> [4/6] firmware: samsung: acpm: Make acpm_ops const and access via pointer
>> https://git.kernel.org/krzk/linux/c/e694e19bf7db26ee324ff6bb450cc523592f5bee
>> [5/6] firmware: samsung: acpm: Add TMU protocol support
>> https://git.kernel.org/krzk/linux/c/f6af402de525d0848fc4a50f25ff01f56fc68d98
>
> That commit contained the questionable error conversion which works
> only for gs101 -- acpm_tmu_to_linux_err() hides some sensible errors into -EIO.
> There were on-going discussion on maillist.
>
> Now, it is needed to ignore that or generalise that or split it to have
> different SoCs if needed. Some re-work will be needed.
That patch was looking correct in its scope. It solved one particular
case (GS101) without stopping anyone to grow this to support other cases
(Exynos850 etc)., so it is in kernel spirit to take such things. Solving
these other cases is simply not necessary now. It's also not blocked, so
just build on top and improve that code to match both use cases, when
you have exynos850 consumer of this.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] Bluetooth: Add Broadcom channel priority commands
From: Sasha Finkelstein @ 2026-05-25 12:11 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-kernel, asahi, linux-arm-kernel, linux-bluetooth, netdev,
Sasha Finkelstein
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL
streams carrying audio to be set as "high priority" using a vendor
specific command to prevent 10-ish second-long dropouts whenever
something does a device scan. This patch sends the command when the
socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio.
From experimenting with the hardware - this command is not suitable for
per-skb priority switching, as prioritization is done on the handle
level, with this command reconfiguring certain radio timings, and
dropping to low priority in order to send a low packet on the same
handle as an audio stream is being played on causes the same kind of
dropout it is supposed to avoid. In addition, the hardware is rather
picky about when this command can be sent, as sending it during
connection open results in a timeout. The vendor stacks solve it by
having high-level visibility into what a connection is used for and
sending it from userspace when it is known that an audio stream is
about to start. As we can't have that visibility without introducing a
new ioctl, the socket priority is used as proxy.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
Changes in v3:
- use a struct for command data
- Link to v2: https://lore.kernel.org/r/20260407-brcm-prio-v2-1-3f745edf49af@gmail.com
Changes in v2:
- new ioctl got nack-ed, so let's use sk_priority as the trigger
- Link to v1: https://lore.kernel.org/r/20260407-brcm-prio-v1-1-f38b17376640@gmail.com
---
MAINTAINERS | 2 ++
drivers/bluetooth/hci_bcm4377.c | 2 ++
include/net/bluetooth/hci_core.h | 15 +++++++++++++++
net/bluetooth/Kconfig | 7 +++++++
net/bluetooth/Makefile | 1 +
net/bluetooth/brcm.c | 38 ++++++++++++++++++++++++++++++++++++++
net/bluetooth/brcm.h | 19 +++++++++++++++++++
net/bluetooth/hci_core.c | 4 ++++
8 files changed, 88 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 10e8253181d3..da4d12ec70d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2581,6 +2581,8 @@ F: include/dt-bindings/pinctrl/apple.h
F: include/linux/mfd/macsmc.h
F: include/linux/soc/apple/*
F: include/uapi/drm/asahi_drm.h
+F: net/bluetooth/brcm.c
+F: net/bluetooth/brcm.h
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..5f79920c0306 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2397,6 +2397,8 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (bcm4377->hw->broken_le_ext_adv_report_phy)
hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LE_EXT_ADV_REPORT_PHY);
+ hci_set_brcm_capable(hdev);
+
pci_set_drvdata(pdev, bcm4377);
hci_set_drvdata(hdev, bcm4377);
SET_HCIDEV_DEV(hdev, &pdev->dev);
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index aa600fbf9a53..53ebb2ae898f 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -642,6 +642,10 @@ struct hci_dev {
bool aosp_quality_report;
#endif
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ bool brcm_capable;
+#endif
+
int (*open)(struct hci_dev *hdev);
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
@@ -756,6 +760,10 @@ struct hci_conn {
unsigned int sent;
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ bool brcm_high_prio;
+#endif
+
struct sk_buff_head data_q;
struct list_head chan_list;
@@ -1791,6 +1799,13 @@ static inline void hci_set_aosp_capable(struct hci_dev *hdev)
#endif
}
+static inline void hci_set_brcm_capable(struct hci_dev *hdev)
+{
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ hdev->brcm_capable = true;
+#endif
+}
+
static inline void hci_devcd_setup(struct hci_dev *hdev)
{
#ifdef CONFIG_DEV_COREDUMP
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index ee6457d1a5ee..b611942c7b8f 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -107,6 +107,13 @@ config BT_AOSPEXT
This options enables support for the Android Open Source
Project defined HCI vendor extensions.
+config BT_BRCMEXT
+ bool "Enable Broadcom extensions"
+ depends on BT
+ help
+ This option enables support for the Broadcom defined HCI
+ vendor extensions.
+
config BT_DEBUGFS
bool "Export Bluetooth internals in debugfs"
depends on BT && DEBUG_FS
diff --git a/net/bluetooth/Makefile b/net/bluetooth/Makefile
index 41049b280887..d402645dfb7d 100644
--- a/net/bluetooth/Makefile
+++ b/net/bluetooth/Makefile
@@ -23,5 +23,6 @@ bluetooth-$(CONFIG_BT_LE) += iso.o
bluetooth-$(CONFIG_BT_LEDS) += leds.o
bluetooth-$(CONFIG_BT_MSFTEXT) += msft.o
bluetooth-$(CONFIG_BT_AOSPEXT) += aosp.o
+bluetooth-$(CONFIG_BT_BRCMEXT) += brcm.o
bluetooth-$(CONFIG_BT_DEBUGFS) += hci_debugfs.o
bluetooth-$(CONFIG_BT_SELFTEST) += selftest.o
diff --git a/net/bluetooth/brcm.c b/net/bluetooth/brcm.c
new file mode 100644
index 000000000000..299d83d465c3
--- /dev/null
+++ b/net/bluetooth/brcm.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "brcm.h"
+
+struct brcm_prio_cmd {
+ __le16 handle;
+ u8 enable;
+} __packed;
+
+int brcm_set_high_priority(struct hci_dev *hdev, struct hci_conn *conn,
+ bool enable)
+{
+ struct sk_buff *skb;
+ struct brcm_prio_cmd cmd;
+
+ if (!hdev->brcm_capable)
+ return 0;
+
+ if (conn->brcm_high_prio == enable)
+ return 0;
+
+ cmd.handle = cpu_to_le16(conn->handle);
+ cmd.enable = !!enable;
+
+ skb = hci_cmd_sync(hdev, 0xfc57, sizeof(cmd), &cmd, HCI_CMD_TIMEOUT);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ conn->brcm_high_prio = enable;
+ kfree_skb(skb);
+ return 0;
+}
diff --git a/net/bluetooth/brcm.h b/net/bluetooth/brcm.h
new file mode 100644
index 000000000000..2290fc6cf798
--- /dev/null
+++ b/net/bluetooth/brcm.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+
+int brcm_set_high_priority(struct hci_dev *hdev, struct hci_conn *conn,
+ bool enable);
+
+#else
+
+static inline int brcm_set_high_priority(struct hci_dev *hdev,
+ struct hci_conn *conn, bool enable)
+{
+ return 0;
+}
+
+#endif
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c46c1236ebfa..0e74bad496a2 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -46,6 +46,7 @@
#include "msft.h"
#include "aosp.h"
#include "hci_codec.h"
+#include "brcm.h"
static void hci_rx_work(struct work_struct *work);
static void hci_cmd_work(struct work_struct *work);
@@ -3696,6 +3697,9 @@ static void hci_sched_acl_pkt(struct hci_dev *hdev)
skb = skb_dequeue(&chan->data_q);
+ if (skb->priority == TC_PRIO_INTERACTIVE)
+ brcm_set_high_priority(hdev, chan->conn, true);
+
hci_conn_enter_active_mode(chan->conn,
bt_cb(skb)->force_active);
---
base-commit: 8bc67e4db64aa72732c474b44ea8622062c903f0
change-id: 20260407-brcm-prio-b630e6cc3834
Best regards,
--
Sasha Finkelstein <k@chaosmail.tech>
^ permalink raw reply related
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Krzysztof Kozlowski @ 2026-05-25 12:10 UTC (permalink / raw)
To: wens
Cc: Jernej Skrabec, samuel, mripard, maarten.lankhorst, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, mturquette, sboyd,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk
In-Reply-To: <ahNuuaVlDl0KvOSj@home.wens.tw>
On 24/05/2026 23:33, Chen-Yu Tsai wrote:
> Hi,
>
> (resent from new email)
>
> On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
>>> From: Jernej Skrabec <jernej.skrabec@gmail.com>
>>>
>>> As it turns out, current H616 DE33 binding was written based on
>>> incomplete understanding of DE33 design. Namely, planes are shared
>>> resource and not tied to specific mixer, which was the case for previous
>>> generations of Display Engine (DE3 and earlier).
>>>
>>> This means that current DE33 binding doesn't properly reflect HW and
>>> using it would mean that second mixer (used for second display output)
>>> can't be supported.
>>>
>>> Remove layer register space, which will be represented with additional
>>> node, and replace it with phandle, which will point to that new, shared
>>> node. That way, all mixers can share same layers.
>>>
>>> There is no user of this binding yet, so changes can be made safely,
>>> without breaking any backward compatibility.
>>
>> There is user. git grep gives me:
>> drivers/gpu/drm/sun4i/sun8i_mixer.c
>>
>> which means this is a released ABI. As I understood, the old code was
>
> We held off on merging the DT changes so that we could rework this.
> I can't find the actual request though. It was probably over IRC.
>
>> working fine but just did not support all use cases. Why this cannot be
>> kept backwards compatible?
>
> AFAIK the "planes" block is shared between two display mixers. As the
> commit message explains, this prevents using the second mixer, since
> only one of them can claim and map the register space. And on the H700
> (which is the same die as the H616 discussed here but with more exposed
> interfaces), there could actually be a use case for the second mixer.
It explains why you want to make the changes but not why you cannot keep
it backwards compatible.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-05-25 12:04 UTC (permalink / raw)
To: Andy Shevchenko, linusw@kernel.org, mwalle@kernel.org
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], brgl@kernel.org
In-Reply-To: <agMM9soiqpG-TRSb@ashevche-desk.local>
> On Tue, May 12, 2026 at 11:33:12AM +0800, Yu-Chun Lin wrote:
> > Expose an accessor function to retrieve the gpio_chip pointer from a
> > gpio_regmap instance.
> >
> > This is needed by drivers that use gpio_regmap but also manage their
> > own irq_chip, where gpiochip_enable_irq()/gpiochip_disable_irq() must
> > be called with the gpio_chip pointer.
> >
> > Add gpio_regmap_get_gpiochip() to allow drivers with complex custom
> > IRQ implementations.
>
> Hmm... Can't we rather add
> gpio_regmap_enable_irq()/gpio_regmap_disable_irq()
> that take regmap or GPIO regmap (whatever suits better for the purpose) and
> do the magic inside GPIO regmap library code?
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
Thanks for the review! I apologize for the misleading commit message.
The real reason I need the struct gpio_chip pointer is to properly set up a custom
IRQ domain. Our SoC GPIO controller is quite complex. It routes different trigger
types to multiple parent IRQs, which doesn't fit the generic regmap_irq framework.
Therefore, we have to create our own irq_domain and pass it to
gpio_regmap_config.irq_domain.
The core problem occurs inside our custom irq_domain_ops.map() callback:
static int rtd1625_gpio_irq_map(struct irq_domain *domain, unsigned int irq,
irq_hw_number_t hwirq)
{
struct rtd1625_gpio *data = domain->host_data;
struct gpio_chip *gc = data->gpio_chip;
/*
* The second argument MUST be struct gpio_chip *.
* If we pass our custom data structure here, the kernel will panic later
* in gpiochip_irq_reqres() when it calls irq_data_get_irq_chip_data()
* and strictly expects it to be a gpio_chip.
*/
irq_set_chip_data(irq, gc);
irq_set_lockdep_class(irq, &rtd1625_gpio_irq_lock_class,
&rtd1625_gpio_irq_request_class);
irq_set_chip_and_handler(irq, &rtd1625_iso_gpio_irq_chip, handle_bad_irq);
irq_set_noprobe(irq);
return 0;
}
Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
map() function.
Before I send a v4, I see 3 possible paths:
Option 1: Keep the accessor (Current v3 approach)
We keep gpio_regmap_get_gpiochip() but I will completely rewrite the commit message
to explain the custom irq_domain_ops.map and lockdep requirements.
Option 2: Let gpiolib create the irq_domain via gpio_regmap_config
Instead of creating the irq_domain in our driver, we add all necessary IRQ fields
(irq_chip, irq_handler, irq_parents, etc.) into struct gpio_regmap_config. Then
gpio-regmap.c populates the gpio_irq_chip structure before calling
gpiochip_add_data(). This prevents an early return and allows the core gpiolib
(gpiochip_add_irqchip()) to automatically create the irq_domain for us.
Drawback: This adds a lot of fields to gpio_regmap_config and might violate the
original design philosophy of gpio-regmap.c (commit ebe363197e52), which explicitly
states that it does not implement its own IRQ chip and delegates it to the parent
driver.
Option 3: Drop gpio-regmap entirely (Revert to v2 approach)
Currently, all drivers using gpio-regmap (mostly simple CPLDs and external I/O cards)
use regmap-irq to get their domain. Since our SoC has a complex IRQ routing scheme
with multiple parents, maybe gpio-regmap is simply not the right tool for this
hardware, and we should just implement a standard GPIO driver directly using gpiolib.
Which approach would you prefer upstream?
Best regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH] net: stmmac: Improve Tx timer arm logic further
From: Maxime Chevallier @ 2026-05-25 11:53 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260525061653.22548-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
Hi,
On 5/25/26 08:16, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Currently hrtimer_start is called even if hrtimer is
> active. This is unnecessary and expensive in some targets.
> This patch avoids calling hrtimer_start unnecessarily.
This description is a bit lacking on details wrt. the expensiveness
and perf impacts, but I've tested with and without this patch on a
cyclone V with dwmac-socfpga, and I cansee a diff when sending
small UDP packets with :
iperf3 -c <srv> -u -b 0 -l 64
Before this patch, around 45200 pps sent,
after this patch, around 52300 pps sent !
Nice improvement :)
So from my perspective,
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
>
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@intel.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3591755ea30b..35da51c26248 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3341,12 +3341,14 @@ static void stmmac_tx_timer_arm(struct stmmac_priv *priv, u32 queue)
> * Try to cancel any timer if napi is scheduled, timer will be armed
> * again in the next scheduled napi.
> */
> - if (unlikely(!napi_is_scheduled(napi)))
> - hrtimer_start(&tx_q->txtimer,
> - STMMAC_COAL_TIMER(tx_coal_timer),
> - HRTIMER_MODE_REL);
> - else
> + if (unlikely(!napi_is_scheduled(napi))) {
> + if (unlikely(!(hrtimer_active(&tx_q->txtimer))))
> + hrtimer_start(&tx_q->txtimer,
> + STMMAC_COAL_TIMER(tx_coal_timer),
> + HRTIMER_MODE_REL);
> + } else {
> hrtimer_try_to_cancel(&tx_q->txtimer);
> + }
> }
>
> /**
^ permalink raw reply
* Re: [PATCH v7 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Rob Herring (Arm) @ 2026-05-25 11:43 UTC (permalink / raw)
To: Damon Ding
Cc: krzk+dt, m.szyprowski, maarten.lankhorst, cristian.ciocaltea,
linux-arm-kernel, mripard, conor+dt, nicolas.frattaroli,
luca.ceresoli, Laurent.pinchart, neil.armstrong, simona, rfoss,
jonas, dianders, tzimmermann, hjc, andrzej.hajda, devicetree,
sebastian.reichel, dmitry.baryshkov, dri-devel, linux-kernel,
jernej.skrabec, andy.yan, airlied, heiko, linux-rockchip
In-Reply-To: <20260525082033.117569-2-damon.ding@rock-chips.com>
On Mon, 25 May 2026 16:20:24 +0800, Damon Ding wrote:
> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
> registers and enable the video datapath.
>
> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> phandle reference, which allowed the eDP to work without explicitly
> managing the hclk_vo1 clock. However, this is not safe or explicit.
>
> To make the clock dependency explicit, enforce per-SoC clock-names
> requirements:
> - RK3288: 2 clocks (dp, pclk)
> - RK3399: 3 clocks (dp, pclk, grf)
> - RK3588: 3 clocks (dp, pclk, hclk)
>
> Do not reuse the 'grf' clock name for RK3588 because it represents
> a different clock with distinct control logic:
> - The 'grf' clock is only for GRF register access and is toggled
> dynamically during register access.
> - The 'hclk' clock controls both GRF access and video datapath
> gating, and must remain enabled during probe.
>
> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Enforce the correct third clock name on a per-compatible basis.
> - Modify the commit msg simultaneously.
>
> Changes in v6:
> - Expand more detail commit msg about using hclk instead of grf clock.
>
> Changes in v7:
> - List all valid clock names at the top level, and constrain the clock
> count for each platform with minItems/maxItems in allOf.
> ---
> .../rockchip/rockchip,analogix-dp.yaml | 34 ++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml:30:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260525082033.117569-2-damon.ding@rock-chips.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH 2/2] i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)
From: Vincent Jardin @ 2026-05-25 11:24 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Wolfram Sang, Kaushal Butala,
Shawn Guo, Stefan Eichenberger
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Vincent Jardin,
stable
In-Reply-To: <20260525-for-upstream-i2c-lx2160-fix-v1-v1-0-f30ab53dd97c@free.fr>
SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the
interrupt-driven block-read state machine rejects it as -EPROTO. Worse,
it returns without a NACK+STOP: the next receive cycle has already
started, so the target keeps holding SDA and the bus stays stuck until a
power cycle of this i2c controller.
Accept count=0: NACK the in-flight dummy byte (TXAK) and set msg->len to
2 so i2c_imx_isr_read_continue() emits STOP via its normal last-byte
path. The dummy byte is discarded; block-read callers only consume
buf[0..count-1].
While here, return early on the I2C_SMBUS_BLOCK_MAX error path instead
of falling through and overwriting msg->len/msg->buf with the rejected
count byte.
The atomic path regressed earlier (v3.16) and is fixed separately; this
patch covers only the v6.13 state-machine rework.
Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")
Cc: <stable@vger.kernel.org> # v6.13+
Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
drivers/i2c/busses/i2c-imx.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 0cd4f5892591..8792cb5cb9a8 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1061,11 +1061,26 @@ static inline enum imx_i2c_state i2c_imx_isr_read_continue(struct imx_i2c_struct
static inline void i2c_imx_isr_read_block_data_len(struct imx_i2c_struct *i2c_imx)
{
u8 len = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+ unsigned int temp;
- if (len == 0 || len > I2C_SMBUS_BLOCK_MAX) {
+ if (len > I2C_SMBUS_BLOCK_MAX) {
i2c_imx->isr_result = -EPROTO;
i2c_imx->state = IMX_I2C_STATE_FAILED;
wake_up(&i2c_imx->queue);
+ return;
+ }
+
+ if (len == 0) {
+ /*
+ * SMBus 3.1 6.5.7 "Block Write/Read": byte count can be 0
+ */
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp |= I2CR_TXAK;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ i2c_imx->msg->buf[i2c_imx->msg_buf_idx++] = 0;
+ i2c_imx->msg->len = 2;
+ return;
}
i2c_imx->msg->len += len;
i2c_imx->msg->buf[i2c_imx->msg_buf_idx++] = len;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
From: Vincent Jardin @ 2026-05-25 11:24 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Wolfram Sang, Kaushal Butala,
Shawn Guo, Stefan Eichenberger
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Vincent Jardin,
stable
In-Reply-To: <20260525-for-upstream-i2c-lx2160-fix-v1-v1-0-f30ab53dd97c@free.fr>
SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic
(polling) path rejects it as -EPROTO. Worse, it returns without a
NACK+STOP: the next receive cycle has already started, so the target
keeps holding SDA and the bus stays stuck until a power cycle for
this i2c controller.
Accept count=0: NACK the in-flight dummy byte (TXAK) and extend msgs->len
so the existing last-byte handling emits STOP. The dummy byte is
discarded; block-read callers only consume buf[0..count-1].
The interrupt-driven path has the same flaw from a later commit and is
fixed separately, as it carries a different Fixes:
Fixes: 8e8782c71595 ("i2c: imx: add SMBus block read support")
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
drivers/i2c/busses/i2c-imx.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b..0cd4f5892591 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1436,8 +1436,19 @@ static int i2c_imx_atomic_read(struct imx_i2c_struct *i2c_imx,
*/
if ((!i) && block_data) {
len = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
- if ((len == 0) || (len > I2C_SMBUS_BLOCK_MAX))
+ if (len > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
+ if (len == 0) {
+ /*
+ * SMBus 3.1 6.5.7: support count byte of 0.
+ */
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp |= I2CR_TXAK;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+ msgs->buf[0] = 0;
+ msgs->len = 2;
+ continue;
+ }
dev_dbg(&i2c_imx->adapter.dev,
"<%s> read length: 0x%X\n",
__func__, len);
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] i2c: imx: fix SMBus block-read of 0 locking the bus
From: Vincent Jardin @ 2026-05-25 11:24 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Wolfram Sang, Kaushal Butala,
Shawn Guo, Stefan Eichenberger
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Vincent Jardin,
stable
i2c-imx rejects a SMBus Block Read byte count of 0 (valid per SMBus 3.1
6.5.7) and it returns without a NACK+STOP, leaving the target
holding SDA so the bus is stuck until a power cycle occur.
The same bug is occuring with two independently introduced spots, so the
fix is two patches with their respective Fixes: tags and backport ranges:
1/2 atomic/polling path Fixes: 8e8782c71595 v3.16+
2/2 IRQ-driven state machine Fixes: 5f5c2d4579ca v6.13+
Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
Vincent Jardin (2):
i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)
drivers/i2c/busses/i2c-imx.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
---
base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6
change-id: 20260525-for-upstream-i2c-lx2160-fix-v1-0cba0a0093e5
Best regards,
--
Vincent Jardin <vjardin@free.fr>
^ permalink raw reply
* Re: [PATCH] pinctrl: meson: amlogic-a4: fix gpio output glitch
From: Xianwei Zhao @ 2026-05-25 11:16 UTC (permalink / raw)
To: Linus Walleij
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <CAD++jLkmm4BbOMZCbJD4H4xfa8nHfExczbXCyF7SapHzQwRZFg@mail.gmail.com>
Hi Linus,
Thanks for your review.
On 2026/5/25 16:34, Linus Walleij wrote:
> On Mon, May 18, 2026 at 10:26 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> When the system transitions from bootloader to kernel, the GPIO is
>> expected to keep driving high.
>>
>> However, the Linux kernel first configures the pin direction and then
>> sets the output value. This may cause a brief low-level glitch on the
>> GPIO line, which can be problematic for regulator control.
>>
>> By configuring the output value before switching the pin direction to
>> output, the glitch can be avoided.
>>
>> This commit fixes the issue by swapping the configuration order.
>>
>> Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
> Is this a regression? I.e. does it cause problems on a supported
> system with mainline?
>
> Linus (the big penguin) is unhappy with too many non-critical fixes
> so I wanna check this before this goes into fixes.
>
The issue only occurs when the critical power supply uses GPIO control.
Otherwise, it is not significant.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 7/7] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Dmitry Baryshkov @ 2026-05-25 11:13 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Luca Weiss, Ajit Pandey, Imran Shaik,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260525-eliza_mm_cc_v2-v5-7-a1d125619a5a@oss.qualcomm.com>
On Mon, May 25, 2026 at 04:16:09PM +0530, Taniya Das wrote:
> Add the device nodes for the multimedia clock controllers (cambistmclkcc,
> camcc, videocc, gpucc) for Qualcomm Eliza SoC.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 61 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 06/10] dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
From: Rob Herring (Arm) @ 2026-05-25 11:13 UTC (permalink / raw)
To: Damon Ding
Cc: mripard, luca.ceresoli, tzimmermann, linux-arm-kernel,
linux-kernel, krzk+dt, dmitry.baryshkov, conor+dt,
cristian.ciocaltea, Laurent.pinchart, rfoss, sebastian.reichel,
linux-rockchip, dri-devel, andy.yan, andrzej.hajda,
jernej.skrabec, simona, devicetree, nicolas.frattaroli,
m.szyprowski, Conor Dooley, hjc, airlied, maarten.lankhorst,
jonas, dianders, heiko, neil.armstrong
In-Reply-To: <20260525082033.117569-7-damon.ding@rock-chips.com>
On Mon, 25 May 2026 16:20:29 +0800, Damon Ding wrote:
> RK3576 integrates an eDP TX controller compatible with the existing
> RK3588 hardware design, reuse the same binding configuration directly.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v2:
> - Split out a separate patch to add the "hclk" clock reference.
>
> Chanegs in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Add Acked-by tag.
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml:34:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260525082033.117569-7-damon.ding@rock-chips.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v7 02/10] dt-bindings: display: rockchip: analogix-dp: Add per-clock descriptions
From: Rob Herring (Arm) @ 2026-05-25 11:13 UTC (permalink / raw)
To: Damon Ding
Cc: airlied, tzimmermann, Conor Dooley, rfoss, cristian.ciocaltea,
luca.ceresoli, heiko, dianders, sebastian.reichel, simona,
dmitry.baryshkov, jonas, Laurent.pinchart, neil.armstrong,
maarten.lankhorst, m.szyprowski, linux-rockchip, andrzej.hajda,
mripard, devicetree, dri-devel, conor+dt, linux-arm-kernel,
nicolas.frattaroli, hjc, andy.yan, linux-kernel, jernej.skrabec,
krzk+dt
In-Reply-To: <20260525082033.117569-3-damon.ding@rock-chips.com>
On Mon, 25 May 2026 16:20:25 +0800, Damon Ding wrote:
> Supplement dedicated description for each clock in the clocks
> property, clarifying the function of each clock input for the
> Analogix DP controller binding.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Add Acked-by tag.
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml:33:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260525082033.117569-3-damon.ding@rock-chips.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v5 0/7] Add support for Video, Camera, Graphics clock controllers on Eliza
From: Dmitry Baryshkov @ 2026-05-25 11:13 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Luca Weiss, Ajit Pandey, Imran Shaik,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, Konrad Dybcio
In-Reply-To: <20260525-eliza_mm_cc_v2-v5-0-a1d125619a5a@oss.qualcomm.com>
On Mon, May 25, 2026 at 04:16:02PM +0530, Taniya Das wrote:
> Add driver for Eliza SoC camera, graphics and Video clock controllers.
> The camera clock controller supports the cambist clock controller and
> the regular camera clock controller.
>
> Eliza camcc and videocc are on CX and MX rails and doesn't have MMCX
> and MXC rails dependency. Since CX and MX rails are already ON when APPS
> is active, explicit power-domain voting is not required similar to Milos.
> Hence extended the Milos camcc & videocc documentation bindings for Eliza.
>
> The patches have been tested on Qualcomm Eliza MTP board.
>
> Changes in v5:
> - Taken care of comments from v3, v4.
Which comments? Please be more specific in changelogics.
> - Update milos-videocc and milos-camcc bindings to add '#power-domain-cells'
> as required property in bindings.
> - Remove duplicate clock 'gpu_cc_gpu_smmu_vote_clk' from driver and
> bindings.
> - Add '#power-domain-cells' for 'camcc' and 'cambistmclkcc' device node.
> - Link to v4: https://lore.kernel.org/r/20260513-eliza_mm_cc_v2-v4-0-e61b5434e8d9@oss.qualcomm.com
>
> Changes in v4:
> - Update the clock ordering for camcc and cambistmclkcc in milos.dtsi.
> - Link to v3: https://lore.kernel.org/r/20260513-eliza_mm_cc_v2-v3-0-b59c370dc281@oss.qualcomm.com
>
> Changes in v3:
> - Dropped new documentation bindings & extended Milos documentation bindings for Eliza videocc & camcc.
> - Dropped the defconfig patch and included the drivers as m from Kconfig itself.
> - Update the header inclusion in the milos.dtsi.
> - Link to v2: https://lore.kernel.org/r/20260409-eliza_mm_cc_v2-v2-0-bc0c6dd77bc5@oss.qualcomm.com
>
> Changes in v2:
> - rebased the patches on the latest linux-next.
> - Add new bindings for Video and Camcc.
> - Remove commented code in GPUCC (limiter code).
> - Add device nodes for the corresponding clock controllers.
> - Add RB-by tags for VideoCC and CamCC/Cambistmclk from v1.
> - Link to v1: https://lore.kernel.org/r/20260317-eliza_mm_clock_controllers_v1-v1-0-4696eeda8cfb@oss.qualcomm.com
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> Taniya Das (7):
> dt-bindings: clock: qcom: Add video clock controller on Qualcomm Eliza SoC
> dt-bindings: clock: qcom: document the Eliza GPU Clock Controller
> dt-bindings: clock: qcom: Add support for CAMCC for Eliza
> clk: qcom: videocc: Add video clock controller driver for Eliza
> clk: qcom: gpucc: Add GPU Clock Controller driver for Eliza
> clk: qcom: camcc: Add support for camera clock controller for Eliza
> arm64: dts: qcom: eliza: Add support for MM clock controllers
>
> .../bindings/clock/qcom,milos-camcc.yaml | 12 +-
> .../bindings/clock/qcom,milos-videocc.yaml | 10 +-
> .../bindings/clock/qcom,sm8450-gpucc.yaml | 3 +
> arch/arm64/boot/dts/qcom/eliza.dtsi | 61 +
> drivers/clk/qcom/Kconfig | 31 +
> drivers/clk/qcom/Makefile | 3 +
> drivers/clk/qcom/cambistmclkcc-eliza.c | 465 ++++
> drivers/clk/qcom/camcc-eliza.c | 2803 ++++++++++++++++++++
> drivers/clk/qcom/gpucc-eliza.c | 607 +++++
> drivers/clk/qcom/videocc-eliza.c | 404 +++
> .../dt-bindings/clock/qcom,eliza-cambistmclkcc.h | 32 +
> include/dt-bindings/clock/qcom,eliza-camcc.h | 151 ++
> include/dt-bindings/clock/qcom,eliza-gpucc.h | 51 +
> include/dt-bindings/clock/qcom,eliza-videocc.h | 37 +
> 14 files changed, 4666 insertions(+), 4 deletions(-)
> ---
> base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
> change-id: 20260409-eliza_mm_cc_v2-701c34ddb74e
>
> Best regards,
> --
> Taniya Das <taniya.das@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Frank Wunderlich (linux) @ 2026-05-25 10:07 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Alexander Couzens, Daniel Golle, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Wunderlich, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260409215509.si2dy63seo4iaspa@skbuf>
Am 2026-04-09 23:55, schrieb Vladimir Oltean:
> On Thu, Apr 09, 2026 at 03:33:42PM +0200, Frank Wunderlich wrote:
>> From: Frank Wunderlich <frank-w@public-files.de>
>>
>> Commit 8871389da151 introduces common pcs dts properties which writes
>> rx=normal,tx=normal polarity to register SGMSYS_QPHY_WRAP_CTRL of
>> switch.
>> This is initialized with tx-bit set and so change inverts polarity
>> compared to before.
>>
>> It looks like mt7531 has tx polarity inverted in hardware and set
>> tx-bit
>> by default to restore the normal polarity.
>>
>> Till this patch the register write was only called when
>> mediatek,pnswap
>> property was set which cannot be done for switch because the fw-node
>> param
>> was always NULL from switch driver in the mtk_pcs_lynxi_create call.
>>
>> Do not configure switch side like it's done before.
>>
>> Fixes: 8871389da151 ("net: pcs: pcs-mtk-lynxi: deprecate
>> "mediatek,pnswap"")
>> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
>> ---
>
> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Hi,
just a gentle ping as i still not see this in torvalds/master.
regards Frank
^ permalink raw reply
* Re: [PATCH v5 6/7] clk: qcom: camcc: Add support for camera clock controller for Eliza
From: Dmitry Baryshkov @ 2026-05-25 11:12 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Luca Weiss, Ajit Pandey, Imran Shaik,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, Konrad Dybcio
In-Reply-To: <20260525-eliza_mm_cc_v2-v5-6-a1d125619a5a@oss.qualcomm.com>
On Mon, May 25, 2026 at 04:16:08PM +0530, Taniya Das wrote:
> Add support for the Camera Clock Controller (CAMCC) on the Eliza
> platform.
>
> The CAMCC block on Eliza includes both the primary camera clock
> controller and the Camera BIST clock controller, which provides the
> functional MCLK required for camera operations.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 11 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/cambistmclkcc-eliza.c | 465 ++++++
> drivers/clk/qcom/camcc-eliza.c | 2803 ++++++++++++++++++++++++++++++++
The camcc and cambistmclkccc drivers looks pretty close to SM8750,
except for using a different PLLs. Would it make sense to have common
drivers instead?
> 4 files changed, 3280 insertions(+)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Kuldeep Singh @ 2026-05-25 11:10 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Eric Biggers, Krzysztof Kozlowski, Demi Marie Obenour, Herbert Xu,
David S. Miller, Thara Gopinath, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Russell King,
linux-kernel, linux-crypto, linux-arm-msm, Ard Biesheuvel,
devicetree, linux-arm-kernel
In-Reply-To: <rb35vwvusd733s2zbgsitof3cpoyyfope4cpeh47xldw27ufix@7fm6bgr4wtkz>
On 25-05-2026 13:41, Dmitry Baryshkov wrote:
> On Mon, May 25, 2026 at 11:59:33AM +0530, Kuldeep Singh wrote:
>>> This driver is more than an order of magnitude slower than the CPU for
>>> both encryption and hashing. See:
>>>
>>> https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
>>> https://lore.kernel.org/r/20250615031807.GA81869@sol/
>>>
>>> There are many examples of it having bugs as well, for example see the
>>> second link above.
>>>
>>> That's why it had to be disabled via the cra_priority system. This
>>> driver was actively making Linux worse.
>>>
>>> This isn't particularly unique to drivers/crypto/, of course. This one
>>> we just have data on, so it's a bit clearer.
>>>
>>> I've yet to see any real reason to keep this driver.
>>
>> https://lore.kernel.org/all/c1697372-54ec-4f57-85d9-ad375ff1a44d@oss.qualcomm.com/
>> Kindly check my latest reply to the thread. There are numerous usecases
>> like DRM(Digital rights management) coming up and qce driver is required
>> for secure content.
>>
>>> Crypto drivers need to be held to a higher standard than other device
>>> drivers, as well. The onus is on those who want to keep a particular
>>> crypto driver to prove that it's worth keeping.
>> Sure, I'll be working on stabilizing self_tests infra for qce.
>> Kindly allow sometime to go over failures in crypto selftest and will
>> submit fix if applicable.
>
> Why are not selftests a part of your default config? How are you testing
> the driver?
We are validating the driver probe and kcapi userspace tests while
validating qce algos. Locally we update all 3 algo priority and then run
kcapi_convinience.sh test suite to ensure it picks qce algos.
Please note, previously were not aware need to run selftests suite too.
Got to know about this once issue was reported.
>
>> So far, i am observing 2 ciphers failing(xts-aes-qce and ctr-aes-qce )
>> with CONFIG_CRYPTO_SELFTESTS enabled.
>
> Please make sure to run the tests on older platforms too, not just the
> latest & greatest.
Yes, will check on all the platforms.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v5 5/7] clk: qcom: gpucc: Add GPU Clock Controller driver for Eliza
From: Dmitry Baryshkov @ 2026-05-25 11:07 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Luca Weiss, Ajit Pandey, Imran Shaik,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, Konrad Dybcio
In-Reply-To: <20260525-eliza_mm_cc_v2-v5-5-a1d125619a5a@oss.qualcomm.com>
On Mon, May 25, 2026 at 04:16:07PM +0530, Taniya Das wrote:
> Add Graphics Clock Controller (GPUCC) support for Eliza platform.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 10 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gpucc-eliza.c | 607 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 618 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 4/7] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Dmitry Baryshkov @ 2026-05-25 11:07 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Luca Weiss, Ajit Pandey, Imran Shaik,
Jagadeesh Kona, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel, Konrad Dybcio
In-Reply-To: <20260525-eliza_mm_cc_v2-v5-4-a1d125619a5a@oss.qualcomm.com>
On Mon, May 25, 2026 at 04:16:06PM +0530, Taniya Das wrote:
> Add support for the video clock controller for video clients to be able
> to request for videocc clocks on Eliza platform.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 10 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/videocc-eliza.c | 404 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 415 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-25 9:42 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260525082033.117569-2-damon.ding@rock-chips.com>
On 5/25/2026 4:20 PM, Damon Ding wrote:
> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
> registers and enable the video datapath.
>
> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> phandle reference, which allowed the eDP to work without explicitly
> managing the hclk_vo1 clock. However, this is not safe or explicit.
>
> To make the clock dependency explicit, enforce per-SoC clock-names
> requirements:
> - RK3288: 2 clocks (dp, pclk)
> - RK3399: 3 clocks (dp, pclk, grf)
> - RK3588: 3 clocks (dp, pclk, hclk)
>
> Do not reuse the 'grf' clock name for RK3588 because it represents
> a different clock with distinct control logic:
> - The 'grf' clock is only for GRF register access and is toggled
> dynamically during register access.
> - The 'hclk' clock controls both GRF access and video datapath
> gating, and must remain enabled during probe.
>
> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Enforce the correct third clock name on a per-compatible basis.
> - Modify the commit msg simultaneously.
>
> Changes in v6:
> - Expand more detail commit msg about using hclk instead of grf clock.
>
> Changes in v7:
> - List all valid clock names at the top level, and constrain the clock
> count for each platform with minItems/maxItems in allOf.
> ---
> .../rockchip/rockchip,analogix-dp.yaml | 34 ++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index d99b23b88cc5..7fe7655c1f37 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -26,7 +26,9 @@ properties:
> items:
> - const: dp
> - const: pclk
> - - const: grf
> + - enum:
> + - grf
> + - hclk
./Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml:34:9:
[warning] wrong indentation: expected 10 but found 8 (indentation)
Will fix in v8.
Best regards,
Damon
>
> power-domains:
> maxItems: 1
> @@ -60,6 +62,32 @@ required:
> allOf:
> - $ref: /schemas/display/bridge/analogix,dp.yaml#
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3288-dp
> + then:
> + properties:
> + clocks:
> + maxItems: 2
> + clock-names:
> + maxItems: 2
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3399-edp
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + clock-names:
> + minItems: 3
> +
> - if:
> properties:
> compatible:
> @@ -68,6 +96,10 @@ allOf:
> - rockchip,rk3588-edp
> then:
> properties:
> + clocks:
> + minItems: 3
> + clock-names:
> + minItems: 3
> resets:
> minItems: 2
> reset-names:
^ 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