* Re: [PATCH] arm64: dts: qcom: monaco: Add default GIC address cells
From: Krzysztof Kozlowski @ 2026-04-08 9:02 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Ziyue Zhang, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <4de63324-2f66-48ca-be1d-e8f20e8727e0@oss.qualcomm.com>
On 08/04/2026 10:56, Konrad Dybcio wrote:
> On 4/7/26 10:15 PM, Krzysztof Kozlowski wrote:
>> Add missing address-cells 0 to GIC interrupt node to silence W=1
>> warning:
>>
>> monaco.dtsi:2326.4-2329.30: Warning (interrupt_map): /soc@0/pci@1c00000:interrupt-map:
>> Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
>>
>> Value '0' is correct because:
>> 1. GIC interrupt controller does not have children,
>> 2. interrupt-map property (in PCI node) consists of five components and
>> the fourth component 'parent unit address', which size is defined by
>> '#address-cells' of the node pointed to by the interrupt-parent
>> component, is not used (=0).
>>
>> Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0")
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
>>
>> Fix for v7.0-rcX.
>> ---
>
> An alternative change would be to describe the GIC_ITS
Yes, but that's pretty different goal and requires testing.
My goal is that code people sent is without warnings :/. I wish there
were some tools helping in that, like you run a command and it tells you
if there is a warning or not.
>
> but for this warning fix:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Konrad Dybcio @ 2026-04-08 9:03 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-3-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
I guess the receptacle on board is power-only?
> RX1/TX1 pair is statically connected to the USB-A port, while its RX0/TX0
> pair is connected to the RA620 DP-to-HDMI bridge.
>
> Add and enable the nodes for the features to work.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 152 +++++++++++++++++++++
> 1 file changed, 152 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index c961d3ec625f..8d649b3a1cfa 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -111,6 +111,71 @@ usb2_3_connector: endpoint {
> };
> };
>
> + usb3_con: connector {
This label is unused
> + compatible = "usb-a-connector";
No vbus-supply?
[...]
> +&mdss_dp {
> + sound-name-prefix = "Display Port0";
Hmmmmm.. other platforms call it "DisplayPort0" (without a space)..
But I suppose this name needs to match UCM..
We'd also normally push this property to the SoC DTSI
Konrad
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: soc: microchip: document irqmux on pic64gx
From: Krzysztof Kozlowski @ 2026-04-08 9:04 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-riscv, Conor Dooley, Daire McNamara, Rob Herring,
Krzysztof Kozlowski, devicetree, linux-kernel
In-Reply-To: <20260407-headache-reward-ae93bacdba0e@spud>
On Tue, Apr 07, 2026 at 04:29:31PM +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> Being practically identical to PolarFire SoC, pic64gx has a irqmux
> that's entirely compatible with that on mpfs.
>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> CC: Conor Dooley <conor.dooley@microchip.com>
> CC: Daire McNamara <daire.mcnamara@microchip.com>
> CC: Rob Herring <robh@kernel.org>
> CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
> CC: linux-riscv@lists.infradead.org
> CC: devicetree@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
> .../bindings/soc/microchip/microchip,mpfs-irqmux.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 05/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Use board-specific CDSP firmware
From: Konrad Dybcio @ 2026-04-08 9:04 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-5-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> The official boot firmware for Dragon Q6A has been switched to the
> Qualcomm WP (Windows) boot firmware. Use the matching board-specific
> CDSP firmware instead of the generic one so that the DSP firmware stack
> remains compatible with the new boot firmware.
>
> The corresponding custom DSP firmware has already been added to
> linux-firmware:
>
> https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/882
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
It's a little shaky given you say it must be changed to remain compatible..
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 07/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Correct GPIO_27 label
From: Konrad Dybcio @ 2026-04-08 9:04 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound,
Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-7-14aca49dde3d@radxa.com>
On 4/7/26 5:19 PM, Xilin Wu wrote:
> From: Stephen Chen <stephen@radxa.com>
>
> The label of GPIO_27 is wrong. Fix it.
>
> Fixes: ef254b12ec60 ("arm64: dts: qcom: qcs6490: Introduce Radxa Dragon Q6A")
> Signed-off-by: Stephen Chen <stephen@radxa.com>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 08/12] arm64: dts: qcom: kodiak: Mark secondary USB controller as wakeup source
From: Konrad Dybcio @ 2026-04-08 9:04 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound,
Stephen Chen
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-8-14aca49dde3d@radxa.com>
On 4/7/26 5:20 PM, Xilin Wu wrote:
> From: Stephen Chen <stephen@radxa.com>
>
> Mark the secondary USB controller (usb_2) as a wakeup source so that it
> can be used to wake the system from suspend.
>
> Signed-off-by: Stephen Chen <stephen@radxa.com>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] Update my email address
From: Krzysztof Kozlowski @ 2026-04-08 9:04 UTC (permalink / raw)
To: Sean Anderson
Cc: Andrew Morton, linux-kernel, Rob Herring, devicetree,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260407164722.211610-1-sean.anderson@linux.dev>
On Tue, Apr 07, 2026 at 12:47:21PM -0400, Sean Anderson wrote:
> Soon I will no longer be working at SECO. Update the mailmap to redirect
> to my linux.dev address which I still have access to.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
> .mailmap | 1 +
> Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml | 2 +-
> MAINTAINERS | 4 ++--
> 3 files changed, 4 insertions(+), 3 deletions(-)
You CC-ed Andrew, so maybe he will take the patch?
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 12/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: add LPASS CPU audio variant
From: Konrad Dybcio @ 2026-04-08 9:06 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <20260407-dragon-q6a-feat-fixes-v1-12-14aca49dde3d@radxa.com>
On 4/7/26 5:20 PM, Xilin Wu wrote:
> Add a qcs6490-radxa-dragon-q6a-lpass-cpu.dts variant for debugging and
> bring-up of the host-controlled LPASS audio path on the Radxa Dragon
> Q6A.
>
> This variant enables the LPASS blocks and codec macros needed by the
> lpass-cpu driver, wires WCD9380 playback/capture and DisplayPort audio
> to the LPASS CDC DMA and DP interfaces, and disables remoteproc_adsp so
> that the audio hardware is owned directly by Linux.
>
> This DTB is an optional configuration for systems booted with the kernel
> running at EL2, where direct CPU access to the LPASS hardware is
> available. It is useful for users who need low-latency and fully
> controllable audio.
I believe on Chrome platforms it was done this way because at some point
it was determined that they would specifically like not to use the DSP.
I think this is more of a hack than anything else.. but at the end of the
commit message you mention low latency - is the impact actually measurable?
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: fpga: add binding for Technologic Systems TS-73xx FPGA
From: Krzysztof Kozlowski @ 2026-04-08 9:08 UTC (permalink / raw)
To: Phil Pemberton
Cc: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tom Rix, Florian Fainelli, linux-fpga, devicetree,
linux-kernel
In-Reply-To: <20260407172730.1779804-2-philpem@philpem.me.uk>
On Tue, Apr 07, 2026 at 06:27:29PM +0100, Phil Pemberton wrote:
> Add device tree binding documentation for the Altera Cyclone II FPGA
> found on Technologic Systems TS-7300 series boards, programmed via a
> CPLD memory-mapped interface.
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Phil Pemberton <philpem@philpem.me.uk>
> ---
> .../fpga/technologic,ts73xx-fpga.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml
>
> diff --git a/Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml b/Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml
> new file mode 100644
> index 000000000000..1f7a651e8f10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/technologic,ts73xx-fpga.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/fpga/technologic,ts73xx-fpga.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Technologic Systems TS-73xx FPGA Manager
> +
> +maintainers:
> + - Florian Fainelli <f.fainelli@gmail.com>
> +
> +description:
> + FPGA manager for the Altera Cyclone II FPGA on Technologic Systems
> + TS-7300 series boards. The FPGA is programmed via a CPLD interface
> + at a memory-mapped register pair.
> +
> +properties:
> + compatible:
> + const: technologic,ts73xx-fpga
So xx is a wildcard? That's not allowed (see writing bindings or any
talks). You need specific compatible. And compatibility, so fallbacks,
if you have multiple distinctive devices.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
Drop entire node, not needed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] riscv: dts: sophgo: sg2044: use hex for CPU unit address
From: Chen Wang @ 2026-04-08 9:08 UTC (permalink / raw)
To: Inochi Amaoto, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Han Gao, Nutty Liu, Guodong Xu, Guo Ren, Xiaoguang Xing
Cc: devicetree, linux-riscv, sophgo, linux-kernel, Yixun Lan,
Longbin Li
In-Reply-To: <20260406232655.144043-2-inochiama@gmail.com>
On 4/7/2026 7:26 AM, Inochi Amaoto wrote:
> Previous the CPU unit address cpu of sg2044 use decimal, it is
> not following the general convention for unit addresses of the
> OF. Convent the unit address to hex to resolve this problem.
>
> The introduces a small ABI break for the CPU id, but it should
> affect nothing since there is no direct full-path reference to
> these CPU nodes.
>
> Fixes: 967a94a92aaa ("riscv: dts: add initial Sophgo SG2042 SoC device tree")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> Link: https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Thanks for your quick action.
Chen
[......]
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add the missing mpll3 clock and clock controller nodes
From: Neil Armstrong @ 2026-04-08 9:09 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Martin Blumenstingl, Stephen Boyd,
Michael Turquette, robh+dt, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jian Hu
Cc: devicetree, linux-clk, linux-amlogic, linux-kernel,
linux-arm-kernel, Ronald Claveau, Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-1-jian.hu@amlogic.com>
Hi,
On Thu, 26 Mar 2026 17:26:42 +0800, Jian Hu wrote:
> This series adds the missing mpll3 parent clock and completes the
> Amlogic T7 SoC clock controller DT support.
>
> - Fix redundant hyphen in for gp1 pll
> - Add the missing mpll3 parent clock definition to t7-peripherals-clkc.yaml
> - Add Amlogic T7 SoC clock controller nodes
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/3] arm64: dts: amlogic: t7: Add clock controller nodes
https://git.kernel.org/amlogic/c/5f727a999f80a72dae7326577e0d832799ddeaa3
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH 2/2] riscv: dts: sophgo: sg2042: use hex for CPU unit address
From: Chen Wang @ 2026-04-08 9:10 UTC (permalink / raw)
To: Inochi Amaoto, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Han Gao, Nutty Liu, Guodong Xu, Guo Ren, Xiaoguang Xing
Cc: devicetree, linux-riscv, sophgo, linux-kernel, Yixun Lan,
Longbin Li
In-Reply-To: <20260406232655.144043-3-inochiama@gmail.com>
On 4/7/2026 7:26 AM, Inochi Amaoto wrote:
> Previous the CPU unit address cpu of sg2042 use decimal, it is
> not following the general convention for unit addresses of the
> OF. Convent the unit address to hex to resolve this problem.
>
> The introduces a small ABI break for the CPU id, but it should
> affect nothing since there is no direct full-path reference to
> these CPU nodes.
>
> Fixes: ae5bac370ed4 ("riscv: dts: sophgo: Add initial device tree of Sophgo SRD3-10")
> Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> Link: https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Tested-by: Chen Wang <unicorn_wang@outlook.com> on Pioneerbox.
Thanks for your quick action.
Chen
[......]
^ permalink raw reply
* Re: (subset) [PATCH 0/2] Fix Amlogic T7 null reset ops and DT required property
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Philipp Zabel, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
Hi,
On Tue, 31 Mar 2026 16:24:03 +0200, Ronald Claveau wrote:
> 1. As reset is required for MMC DT, this patch series aims to add the currently missing required driver ops.
>
> Whithout this patch the following kernel null error appears:
>
> [ 0.459197] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.459978] Mem abort info:
> [ 0.460324] ESR = 0x0000000096000004
> [ 0.460791] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.461471] SET = 0, FnV = 0
> [ 0.461830] EA = 0, S1PTW = 0
> [ 0.462220] FSC = 0x04: level 0 translation fault
> [ 0.462722] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> [ 0.462826] Data abort info:
> [ 0.462829] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.462842] Mem abort info:
> [ 0.462849] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.462859] ESR = 0x0000000096000004
> [ 0.462865] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.462874] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 0.462882] [0000000000000000] user address but active_mm is swapper
> [ 0.462890] SET = 0, FnV = 0
> [ 0.462901] Internal error: Oops: 0000000096000004 [#1] SMP
> [ 0.462909] EA = 0, S1PTW = 0
> [ 0.462917] Modules linked in:
> [ 0.462925] FSC = 0x04: level 0 translation fault
> [ 0.462932]
> [ 0.462939] Data abort info:
> [ 0.462951] CPU: 4 UID: 0 PID: 90 Comm: kworker/u34:3 Not tainted 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.463920] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> [ 0.463927] Hardware name: Khadas VIM4 (DT)
> [ 0.463940] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 0.463951] Workqueue: async async_run_entry_fn
> [ 0.464277] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 0.464286]
> [ 0.464294] [0000000000000000] user address but active_mm is swapper
> [ 0.464304] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.465935] pc : reset_control_reset+0x48/0x1d0
> [ 0.466409] lr : reset_control_reset+0x38/0x1d0
> [ 0.479907] sp : ffff800083943b60
> [ 0.479911] x29: ffff800083943b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.479926] x26: ffff80008310a9c0 x25: 0000000000000000 x24: ffff000100372005
> [ 0.481212] x23: ffff0001003a4000 x22: ffff000100fee988 x21: 0000000000000000
> [ 0.482976] x20: ffff00023f00a788 x19: ffff000100fee980 x18: 0000000000000006
> [ 0.483865] x17: 64656c62616e655f x16: 7469647561206465 x15: ffff800083943530
> [ 0.484753] x14: 0000000000000000 x13: 000000000000022d x12: 0000000000002000
> [ 0.485642] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.486530] x8 : ffff00023efd8a40 x7 : fffffffffffffe70 x6 : ffff00023efd89e0
> [ 0.487418] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.488307] x2 : ffff000102002488 x1 : ffff8000822248c0 x0 : 0000000000000000
> [ 0.489196] Call trace:
> [ 0.489500] reset_control_reset+0x48/0x1d0 (P)
> [ 0.490062] __device_reset+0xc8/0xfc
> [ 0.490517] meson_mmc_probe+0xe8/0x3d4
> [ 0.490994] platform_probe+0x5c/0x98
> [ 0.491448] really_probe+0xbc/0x298
> [ 0.491892] __driver_probe_device+0x78/0x12c
> [ 0.492434] driver_probe_device+0xd4/0x164
> [ 0.492954] __device_attach_driver+0xb8/0x140
> [ 0.493507] bus_for_each_drv+0x84/0xe0
> [ 0.493983] __device_attach_async_helper+0xac/0xd0
> [ 0.494590] async_run_entry_fn+0x34/0xe0
> [ 0.495089] process_one_work+0x158/0x29c
> [ 0.495587] worker_thread+0x18c/0x308
> [ 0.496053] kthread+0x11c/0x128
> [ 0.496453] ret_from_fork+0x10/0x20
> [ 0.496904] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.497661] ---[ end trace 0000000000000000 ]---
> [ 0.498234] Internal error: Oops: 0000000096000004 [#2] SMP
> [ 0.498935] Modules linked in:
> [ 0.499319] CPU: 1 UID: 0 PID: 88 Comm: kworker/u34:1 Tainted: G D 7.0.0-rc4-next-20260319 #41 PREEMPT
> [ 0.500669] Tainted: [D]=DIE
> [ 0.501025] Hardware name: Khadas VIM4 (DT)
> [ 0.501547] Workqueue: async async_run_entry_fn
> [ 0.502109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.502975] pc : reset_control_reset+0x48/0x1d0
> [ 0.503538] lr : reset_control_reset+0x38/0x1d0
> [ 0.504102] sp : ffff800083903b60
> [ 0.504513] x29: ffff800083903b60 x28: 0000000000000000 x27: 0000000000000000
> [ 0.505402] x26: ffff000100059028 x25: 0000000000000000 x24: ffff000100372005
> [ 0.506290] x23: ffff000100ec9400 x22: ffff0001003f6e08 x21: 0000000000000000
> [ 0.507178] x20: ffff00023f00b440 x19: ffff0001003f6e00 x18: 00000000ffffffff
> [ 0.508067] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000839037e0
> [ 0.508955] x14: 0000000000000000 x13: 0000000000000290 x12: 0000000000002000
> [ 0.509843] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
> [ 0.510732] x8 : ffff00023efd8bc0 x7 : fffffffffffffe70 x6 : ffff00023efd8b60
> [ 0.511620] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
> [ 0.512508] x2 : ffff000102002488 x1 : ffff800082224a40 x0 : 0000000000000000
> [ 0.513397] Call trace:
> [ 0.513700] reset_control_reset+0x48/0x1d0 (P)
> [ 0.514263] __device_reset+0xc8/0xfc
> [ 0.514718] meson_mmc_probe+0xe8/0x3d4
> [ 0.515195] platform_probe+0x5c/0x98
> [ 0.515650] really_probe+0xbc/0x298
> [ 0.516094] __driver_probe_device+0x78/0x12c
> [ 0.516636] driver_probe_device+0xd4/0x164
> [ 0.517156] __device_attach_driver+0xb8/0x140
> [ 0.517709] bus_for_each_drv+0x84/0xe0
> [ 0.518185] __device_attach_async_helper+0xac/0xd0
> [ 0.518792] async_run_entry_fn+0x34/0xe0
> [ 0.519290] process_one_work+0x158/0x29c
> [ 0.519788] worker_thread+0x18c/0x308
> [ 0.520254] kthread+0x11c/0x128
> [ 0.520655] ret_from_fork+0x10/0x20
> [ 0.521103] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
> [ 0.521860] ---[ end trace 0000000000000000 ]---
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[2/2] arm64: dts: amlogic: t7: Fix missing required reset property
https://git.kernel.org/amlogic/c/98da3e91a6157d2833af356620665a9734d26133
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-04-08 9:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
https://git.kernel.org/amlogic/c/759613b88fbf051c8a977a5e5b046b28a18ed5c7
[5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
https://git.kernel.org/amlogic/c/596e3c1bfa7869cf15079e5c6e586575013b2fc3
[7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
https://git.kernel.org/amlogic/c/647228c014ddbd336a97e74bde81cbb2f7cbd927
[9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
https://git.kernel.org/amlogic/c/00cca65deacb29947ef32011827ff88fd59dab55
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-2-florian.fainelli@broadcom.com>
On Tue, Apr 07, 2026 at 04:56:10PM -0700, Florian Fainelli wrote:
> Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> index 9135788cf62e..afe7329a1df2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> @@ -38,6 +38,10 @@ properties:
> - enum:
> - marvell,pxa1908-padconf
> - const: pinconf-single
> + - items:
> + - enum:
> + - brcm,bcm7038-padconf
> + - const: pinctrl-single
If there is going to be a new version, entire block should be placed
before 'ti' to have some sort of sorting by compatible.
But no need to resend just for that.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] clk: microchip: mpfs-ccc: fix out-of-bounds write
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Aleš Pečnik
Cc: Conor Dooley, Daire McNamara, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, linux-riscv, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260408-mpfs-clk-oob-write-v1-1-8b3b387f2a6f@skylabs.si>
On Wed, Apr 08, 2026 at 07:07:34AM +0200, Aleš Pečnik wrote:
> Issue was allocated array size for clk_data.
> When clocks are being registered their index is taken from defines in
> dt-bindings. The last 2 clocks had their index outside of allocated range.
> Two defines (CLK_CCC_DLL0, CLK_CCC_DLL1) were not used and skipped over
> which was not taken into account when allocating the array.
>
> This patch is minimal change to resolve the issue.
>
> Issue was found using KASAN when debugging unrelated xdma driver issue.
> Consequently fixing this issue also resolved xdma driver issue.
>
> Related dmesg output:
> [ 0.290703] BUG: KASAN: slab-out-of-bounds in mpfs_ccc_register_outputs.constprop.0+0xd0/0x1fa
> [ 0.290984] Write of size 8 at addr ffffffe7be6e3ca8 by task swapper/0/1
> [ 0.291253] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.43-linux4microchip+fpga-2023.09 #1
> [ 0.291482] Hardware name: Skylabs HPC (DT)
> [ 0.291611] Call Trace:
> ...
> [ 0.292999] [<ffffffff808508c8>] mpfs_ccc_register_outputs.constprop.0+0xd0/0x1fa
> [ 0.293245] [<ffffffff80850b66>] mpfs_ccc_probe+0x174/0x30e
> [ 0.293437] [<ffffffff808d4af2>] platform_probe+0x74/0xba
> ...
>
> Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support")
> Signed-off-by: Aleš Pečnik <ales.pecnik@skylabs.si>
> ---
> drivers/clk/microchip/clk-mpfs-ccc.c | 3 +--
> include/dt-bindings/clock/microchip,mpfs-clock.h | 2 ++
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/microchip/clk-mpfs-ccc.c b/drivers/clk/microchip/clk-mpfs-ccc.c
> index 3a3ea2d142f8..71fbb6265ea4 100644
> --- a/drivers/clk/microchip/clk-mpfs-ccc.c
> +++ b/drivers/clk/microchip/clk-mpfs-ccc.c
> @@ -234,8 +234,7 @@ static int mpfs_ccc_probe(struct platform_device *pdev)
> unsigned int num_clks;
> int ret;
>
> - num_clks = ARRAY_SIZE(mpfs_ccc_pll_clks) + ARRAY_SIZE(mpfs_ccc_pll0out_clks) +
> - ARRAY_SIZE(mpfs_ccc_pll1out_clks);
> + num_clks = CLK_CCC_NUM;
>
> clk_data = devm_kzalloc(&pdev->dev, struct_size(clk_data, hw_data.hws, num_clks),
> GFP_KERNEL);
> diff --git a/include/dt-bindings/clock/microchip,mpfs-clock.h b/include/dt-bindings/clock/microchip,mpfs-clock.h
> index b52f19a2b480..8d53f2b81a54 100644
> --- a/include/dt-bindings/clock/microchip,mpfs-clock.h
> +++ b/include/dt-bindings/clock/microchip,mpfs-clock.h
> @@ -73,4 +73,6 @@
> #define CLK_CCC_DLL1_OUT0 14
> #define CLK_CCC_DLL1_OUT1 15
>
> +#define CLK_CCC_NUM 16
Not a binding, drop from bindings. Driver is the place for that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Neil Armstrong @ 2026-04-08 9:12 UTC (permalink / raw)
To: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree,
Jun Yan
Cc: robh, krzk+dt, conor+dt, khilman, jbrunet, martin.blumenstingl
In-Reply-To: <20260330145111.115318-1-jerrysteve1101@gmail.com>
Hi,
On Mon, 30 Mar 2026 22:51:11 +0800, Jun Yan wrote:
> Correct the interrupt number assigned to the Realtek PHY in the p230
>
> following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
> fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
> interrupt improvements [1].
>
> [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/1] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
https://git.kernel.org/amlogic/c/b18d1b23558114b3c64fec7b515ca80c76e58171
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Wangao Wang @ 2026-04-08 9:14 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Vikash Garodia,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: wangao.wang, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <9bfaf15e-99c8-a98e-d0df-9df86872bfe8@oss.qualcomm.com>
On 2026/4/1 20:37, Dikshita Agarwal wrote:
>> +
>> +static void iris_vpu3_purwa_power_off_hardware(struct iris_core *core)
>> +{
>> + iris_vpu3_power_off_hardware(core);
>
> this will eventually call iris_vpu_power_off_hw which would try to disable
> IRIS_HW_AHB_CLK which is not applicable to purwa I think, will that not
> create any issue?
>
All VPU3s will call this hook, but none of them have IRIS_HW_AHB_CLK.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Wangao Wang @ 2026-04-08 9:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: wangao.wang, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260402-lurking-tested-marmoset-f315b4@quoll>
On 2026/4/2 15:08, Krzysztof Kozlowski wrote:
>
> Why no IRIS_HW_AHB_CLK in power on sequence?
>
> So if you rewrite the code that you have list of clocks for hw power on
> (IRIS_HW_CLK + IRIS_HW_AHB_CLK for all variants, +IRIS_BSE_HW_CLK on
> this variant) you could have just one function for all of them and
> devices will be fully compatible.
>
> No?
>
The original patch was to add the IRIS_BSE_HW_CLK operation into the
common API, but Dmitry requested to separate Purwa's implementation out
independently.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Wangao Wang @ 2026-04-08 9:17 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Vikash Garodia,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: wangao.wang, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <437123c2-35af-227c-3fe1-7d45ea1243da@oss.qualcomm.com>
On 2026/4/1 20:40, Dikshita Agarwal wrote:
>> +const struct iris_platform_data x1p42100_data = {
>> + .get_instance = iris_hfi_gen2_get_instance,
>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>
> this needs a rebase on latest platform rework series.
>
> Thanks,
> Dikshita
>
Will fix in next version.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH RFC 2/4] arm64: dts: qcom: glymur: Add GPU smmu node
From: Konrad Dybcio @ 2026-04-08 9:18 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Sean Paul,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
Rajendra Nayak, Rajendra Nayak
In-Reply-To: <20260405-glymur-gpu-dt-v1-2-2135eb11c562@oss.qualcomm.com>
On 4/4/26 11:03 PM, Akhil P Oommen wrote:
> From: Rajendra Nayak <quic_rjendra@quicinc.com>
>
> Add the nodes to describe the GPU SMMU node.
>
> Signed-off-by: Rajendra Nayak <rajendra.nayak@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] reset: eswin: Add eic7700 HSP reset driver
From: Philipp Zabel @ 2026-04-08 9:19 UTC (permalink / raw)
To: dongxuyang, mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk,
devicetree, linux-kernel, huangyifeng
Cc: ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260403093628.780-1-dongxuyang@eswincomputing.com>
On Fr, 2026-04-03 at 17:36 +0800, dongxuyang@eswincomputing.com wrote:
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> Add auxiliary driver to support ESWIN EIC7700 high-speed peripherals
> system. The reset controller is created using the auxiliary device
> framework and set up in the clock driver.
>
> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> ---
> drivers/reset/Kconfig | 13 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-eic7700-hsp.c | 151 ++++++++++++++++++++++++++++++
> 3 files changed, 165 insertions(+)
> create mode 100644 drivers/reset/reset-eic7700-hsp.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 7ce151f6a7e4..50bb0cd069ba 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -83,6 +83,19 @@ config RESET_EIC7700
> The driver supports eic7700 series chips and provides functionality for
> asserting and deasserting resets on the chip.
>
> +config RESET_EIC7700_HSP
> + tristate "EIC7700 HSP Reset controller"
> + depends on ARCH_ESWIN || COMPILE_TEST
> + depends on COMMON_CLK_EIC7700_HSP
Why?
Please make this buildable under COMPILE_TEST without enabling the
clock driver.
[...]
> diff --git a/drivers/reset/reset-eic7700-hsp.c b/drivers/reset/reset-eic7700-hsp.c
> new file mode 100644
> index 000000000000..fe9822078bcc
> --- /dev/null
> +++ b/drivers/reset/reset-eic7700-hsp.c
> @@ -0,0 +1,151 @@
[...]
> +static int eic7700_hsp_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct eic7700_hsp_reset_data *data = to_eic7700_hsp_reset(rcdev);
> + int ret;
> +
> + if (eic7700_hsp_reset[id].active_low)
> + ret = regmap_clear_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
> + else
> + ret = regmap_set_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
This is essentially regmap_assign_bits() open-coded.
> +
> + return ret;
> +}
> +
> +static int eic7700_hsp_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct eic7700_hsp_reset_data *data = to_eic7700_hsp_reset(rcdev);
> + int ret;
> +
> + if (eic7700_hsp_reset[id].active_low)
> + ret = regmap_set_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
> + else
> + ret = regmap_clear_bits(data->regmap, eic7700_hsp_reset[id].reg,
> + eic7700_hsp_reset[id].bit);
Same as above.
> +
> + return ret;
> +}
> +
> +static int eic7700_hsp_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + int ret;
> +
> + ret = eic7700_hsp_reset_assert(rcdev, id);
> + if (ret)
> + return ret;
> +
> + usleep_range(10, 15);
> +
> + return eic7700_hsp_reset_deassert(rcdev, id);
> +}
Does any of the consumer drivers (SATA, USB) actually use
reset_control_reset()? If not, don't implement this.
> +
> +static const struct reset_control_ops eic7700_hsp_reset_ops = {
> + .reset = eic7700_hsp_reset_reset,
> + .assert = eic7700_hsp_reset_assert,
> + .deassert = eic7700_hsp_reset_deassert,
> +};
> +
> +static int eic7700_hsp_reset_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + struct eic7700_hsp_reset_data *data;
> + struct device *dev = &adev->dev;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->regmap = devm_regmap_init_mmio
> + (dev, (__force void __iomem *)adev->dev.platform_data,
Consider letting the parent clk driver create the regmap und using
dev_get_regmap().
> + &eic7700_hsp_regmap_config);
> + if (IS_ERR(data->regmap))
> + return dev_err_probe(dev, PTR_ERR(data->regmap),
> + "failed to get regmap!\n");
> +
> + data->rcdev.owner = THIS_MODULE;
> + data->rcdev.ops = &eic7700_hsp_reset_ops;
> + data->rcdev.of_node = dev->parent->of_node;
> + data->rcdev.of_reset_n_cells = 1;
No need to set of_reset_n_cells, this value is ignored if of_xlate
isn't also set.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Dikshita Agarwal @ 2026-04-08 9:20 UTC (permalink / raw)
To: Wangao Wang, Bryan O'Donoghue, Vikash Garodia, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <7e7f7778-9a26-45f3-89c1-0113969cc1d8@oss.qualcomm.com>
On 4/8/2026 2:47 PM, Wangao Wang wrote:
>
>
> On 2026/4/1 20:40, Dikshita Agarwal wrote:
>
>>> +const struct iris_platform_data x1p42100_data = {
>>> + .get_instance = iris_hfi_gen2_get_instance,
>>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>>
>> this needs a rebase on latest platform rework series.
>>
>> Thanks,
>> Dikshita
>>
>
> Will fix in next version.
The rework series was expected to land in 7.1, which may no longer be the
case. Please hold off on any rebasing until it is clear what the correct
base for this series should be.
Thanks,
Dikshita
>
^ permalink raw reply
* Re: [PATCH v4 3/5] media: iris: Add platform data for X1P42100
From: Wangao Wang @ 2026-04-08 9:22 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Vikash Garodia,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: wangao.wang, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <fe1379a5-57f2-e618-dbeb-32d1c3c7536a@oss.qualcomm.com>
On 2026/4/8 17:20, Dikshita Agarwal wrote:
>
>
> On 4/8/2026 2:47 PM, Wangao Wang wrote:
>>
>>
>> On 2026/4/1 20:40, Dikshita Agarwal wrote:
>>
>>>> +const struct iris_platform_data x1p42100_data = {
>>>> + .get_instance = iris_hfi_gen2_get_instance,
>>>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>>>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>>>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>>>
>>> this needs a rebase on latest platform rework series.
>>>
>>> Thanks,
>>> Dikshita
>>>
>>
>> Will fix in next version.
>
> The rework series was expected to land in 7.1, which may no longer be the
> case. Please hold off on any rebasing until it is clear what the correct
> base for this series should be.
>
> Thanks,
> Dikshita
>>
Got it.
--
Best Regards,
Wangao
^ permalink raw reply
* Re: [PATCH RFC 3/4] arm64: dts: qcom: Add GPU support for Glymur
From: Konrad Dybcio @ 2026-04-08 9:23 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Sean Paul,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno
In-Reply-To: <20260405-glymur-gpu-dt-v1-3-2135eb11c562@oss.qualcomm.com>
On 4/4/26 11:03 PM, Akhil P Oommen wrote:
> The Adreno X2 series GPU present in Glymur SoC belongs to the A8x
> family. It is a new HW IP with architectural improvements as well
> as different set of hw configs like GMEM, num SPs, Caches sizes etc.
>
> Add the GPU and GMU nodes to describe this hardware.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
[...]
> + gpu_zap_shader: zap-shader {
> + status = "disabled";
> + memory-region = <&gpu_microcode_mem>;
> + };
My understanding is that we may drop this
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ 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