* Re: [RFC PATCH 9/9] arm64: dts: rockchip: rk3576-rock-4d: enable NPU
From: sashiko-bot @ 2026-07-17 9:32 UTC (permalink / raw)
To: Jiaxing Hu; +Cc: devicetree, robh, conor+dt, dri-devel
In-Reply-To: <20260717085220.3212274-10-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unconditional call to `devm_pm_domain_attach_list()` breaks probe on single power-domain platforms (e.g., RK3588).
- [Medium] Devicetree binding schema violation: `power-domains` has multiple items.
--
--- Patch [9]: [RFC PATCH 9/9] arm64: dts: rockchip: rk3576-rock-4d: enable NPU ---
commit b202e27a2b4bfe1725b5bf2c08f62041f816c518
Author: Jiaxing Hu <gahing@gahingwoo.com>
arm64: dts: rockchip: rk3576-rock-4d: enable NPU
This commit enables rknn_core_0 and rknn_mmu_0 on the Radxa ROCK 4D. It
supplies the NPU rail and configures the power domains.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> index 272af1012ab03..09d2fc98bb4c1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
[ ... ]
> +&rknn_core_0 {
> + npu-supply = <&vdd_npu_s0>;
> + /*
> + * Power BOTH NPU domains (NPU0 + NPU1) like the vendor's single NPU node,
> + * even though rocket computes only on core 0: the CBUF->CMAC read path is
> + * only fully powered with NPU1 up. rocket attaches the multi-PD list.
> + */
> + power-domains = <&power RK3576_PD_NPU0>, <&power RK3576_PD_NPU1>;
[Severity: High]
Does the driver's handling of the multi-PD list break probe on single-PD
platforms like RK3588?
The comment here notes that rocket attaches the multi-PD list. When a device
has exactly one power-domains entry, the driver core automatically populates
dev->pm_domain before rocket_core_init() runs.
If the driver unconditionally calls devm_pm_domain_attach_list():
drivers/accel/rocket/rocket_core.c:rocket_core_init() {
...
err = devm_pm_domain_attach_list(dev, NULL, &pd_list);
if (err < 0)
return dev_err_probe(dev, err,
"failed to attach NPU power domains\n");
...
}
In this scenario, devm_pm_domain_attach_list() returns -EEXIST because
dev->pm_domain is already set. Since -EEXIST is less than 0, won't this abort
the probe via dev_err_probe(), fatally failing initialization for platforms
with only one power domain?
[Severity: Medium]
Will this multiple power domain configuration cause dtbs_check validation
errors?
The schema currently restricts the power-domains property to a single item:
Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml:
power-domains:
maxItems: 1
Since this adds both RK3576_PD_NPU0 and RK3576_PD_NPU1, could the schema
be updated to support maxItems: 2 before adding this configuration to avoid
build-time tooling errors?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=9
^ permalink raw reply
* Re: [PATCH v4 07/11] Bluetooth: hci_qca: Embed bt_power in struct qca_serdev
From: Bartosz Golaszewski @ 2026-07-17 9:31 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-7-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:24 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> 'bt_power' is allocated dynamically only for a subset of SOC types, using a
> switch on the SOC type that mirrors the one that follows it. This is about
> to become pointless as the power sequencer path (used by M.2 modules) is
> independent of the SOC type and needs 'bt_power' populated for any type.
>
> Embed 'struct qca_power' directly in 'struct qca_serdev' instead of
> allocating it separately. This drops the extra allocation and its dedicated
> SOC-type switch, and removes the need for NULL checks on the pointer.
>
> No functional change intended.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v8 2/8] iio: dac: ad5686: missing NULL check on match data
From: Rodrigo Alencar @ 2026-07-17 9:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva,
sashiko-bot
In-Reply-To: <alnknz55FbyyqqlL@ashevche-desk.local>
On 17/07/26 11:15, Andy Shevchenko wrote:
> On Fri, Jul 17, 2026 at 07:51:35AM +0100, Rodrigo Alencar wrote:
> > On 16/07/26 21:42, Andy Shevchenko wrote:
> > > On Thu, Jul 16, 2026 at 01:14:18PM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > struct iio_dev *indio_dev;
> > > > int ret, i;
> > >
> > > Move an assignment here as well.
> > >
> > > chip_info = ...
> >
> > assignment? this is an input param validation
>
> Can we make sure we always get a correct one to begin with?
> With that an assignment and check can be coupled together.
> Also consider use -ENODATA as it's most likely comes from
> driver_data.
I suppose you are suggesting to move the check to the bus code with:
info = i2c_get_match_data(i2c);
if (!info)
return -ENODATA;
rather than here in the core/common code.
> > > > + if (!chip_info)
> > > > + return -ENODEV;
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v4 06/11] Bluetooth: hci_qca: Set 'bt_en_available' based on pwrseq power controllability
From: Bartosz Golaszewski @ 2026-07-17 9:30 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-6-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:23 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> A Bluetooth device only needs the non-persistent setup if the host can
> gate its power, so that it is actually reset on the next power-on. When the
> power is controlled by a power sequencer, whether the host can gate it
> depends on the hardware wiring, e.g. the presence of the BT_EN or
> W_DISABLE2# line.
>
> Query the generic pwrseq_is_controllable() helper whenever the BT power
> comes from a sequencer, regardless of which provider it is (M2, WCN, ...).
> If the power is not controllable, clear 'bt_en_available' so that
> HCI_QUIRK_NON_PERSISTENT_SETUP is not set.
>
> This is based on Manivannan's original patch that keyed the decision off
> the W_DISABLE2# device tree property, it now uses the generic pwrseq helper
> and handles the always-on case.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/bluetooth/hci_qca.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 17f436484e1e74d1dd690ada22134315abb767c4..41e8c302abc2a820022d1783f1fad76b358ae67c 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -2548,7 +2548,18 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> return PTR_ERR(qcadev->susclk);
> }
> }
> -
> +
> + if (qcadev->bt_power->pwrseq) {
> + bt_en_available = pwrseq_is_controllable(qcadev->bt_power->pwrseq);
> + if (!bt_en_available) {
> + /* The host cannot gate the BT power individually.
> + * Treat it as always-on and drop the pwrseq handle.
> + */
> + pwrseq_power_on(qcadev->bt_power->pwrseq);
> + qcadev->bt_power->pwrseq = NULL;
Maybe a little comment saying this will be released by devres? It looks like
a leak otherwise.
Bart
> + }
> + }
> +
> err = hci_uart_register_device(&qcadev->serdev_hu, &qca_proto);
> if (err) {
> BT_ERR("serdev registration failed");
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [RFC PATCH 8/9] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes
From: sashiko-bot @ 2026-07-17 9:30 UTC (permalink / raw)
To: Jiaxing Hu; +Cc: conor+dt, dri-devel, devicetree, robh
In-Reply-To: <20260717085220.3212274-9-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing `aclk_cbuf` and `hclk_cbuf` clocks in `rknn_core_1` node.
- [High] Single power-domain definition for NPU cores causes probe failure (`-EEXIST`) and violates hardware constraints.
- [High] The physical register address for `rknn_mmu_1` is incorrectly mapped to `0x2770a000` instead of `0x27712000`.
--
--- Patch [8]: [RFC PATCH 8/9] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes ---
commit 5396e10743f01d595779ccc7127139fe5f89e996
Author: Jiaxing Hu <gahing@gahingwoo.com>
arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes
Add the RK3576 NPU: rknn_core_0/1 and rknn_mmu_0/1, with register
addresses, GIC_SPI 247/248 interrupts, clocks, resets and power-domains.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> index e12a2a0cfb891..5033f762840ae 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
[ ... ]
> @@ -1804,6 +1812,72 @@ qos_npu_m1ro: qos@27f22100 {
> reg = <0x0 0x27f22100 0x0 0x20>;
> };
>
> + rknn_core_0: npu@27700000 {
> + compatible = "rockchip,rk3576-rknn-core";
> + reg = <0x0 0x27700000 0x0 0x1000>,
> + <0x0 0x27701000 0x0 0x1000>,
> + <0x0 0x27703000 0x0 0x1000>,
> + <0x0 0x27704000 0x0 0x1000>,
> + <0x0 0x27705000 0x0 0x1000>;
> + reg-names = "pc", "cna", "core", "dpu", "dpu_rdma";
> + interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_RKNN0>, <&cru HCLK_RKNN_ROOT>,
> + <&cru CLK_RKNN_DSU0>, <&cru PCLK_NPUTOP_ROOT>,
> + <&cru ACLK_RKNN_CBUF>, <&cru HCLK_RKNN_CBUF>;
> + clock-names = "aclk", "hclk", "npu", "pclk",
> + "aclk_cbuf", "hclk_cbuf";
> + resets = <&cru SRST_A_RKNN0>;
> + reset-names = "srst_a";
> + power-domains = <&power RK3576_PD_NPU0>;
[Severity: High]
Does listing a single power domain here cause probe to fail?
The rocket_core_init driver expects both RK3576_PD_NPU0 and RK3576_PD_NPU1 on
rknn_core_0 to satisfy a hardware constraint where the CBUF->CMAC read path
requires both.
Because the DT only lists one power domain per core, the kernel platform bus
auto-attaches it and sets dev->pm_domain. When the driver then calls
devm_pm_domain_attach_list(), it will return -EEXIST, which the driver treats
as a fatal error and aborts probe. Missing RK3576_PD_NPU1 on rknn_core_0 also
breaks runtime PM, leading to AXI lockups.
> + iommus = <&rknn_mmu_0>;
> + status = "disabled";
> + };
> +
[ ... ]
> + rknn_core_1: npu@27710000 {
> + compatible = "rockchip,rk3576-rknn-core";
> + reg = <0x0 0x27710000 0x0 0x1000>,
> + <0x0 0x27711000 0x0 0x1000>,
> + <0x0 0x27713000 0x0 0x1000>,
> + <0x0 0x27714000 0x0 0x1000>,
> + <0x0 0x27715000 0x0 0x1000>;
> + reg-names = "pc", "cna", "core", "dpu", "dpu_rdma";
> + interrupts = <GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_RKNN1>, <&cru HCLK_RKNN_ROOT>,
> + <&cru CLK_RKNN_DSU0>, <&cru PCLK_NPUTOP_ROOT>;
> + clock-names = "aclk", "hclk", "npu", "pclk";
[Severity: High]
Will the driver fail to probe here due to missing CBUF clocks?
The rocket_core_init function explicitly requests 6 clocks (aclk, hclk, npu,
pclk, aclk_cbuf, hclk_cbuf) using devm_clk_bulk_get(). Since rknn_core_1 only
defines 4 clocks, the API will fail with -ENOENT, making the second NPU core
unusable.
> + resets = <&cru SRST_A_RKNN1>;
> + reset-names = "srst_a";
> + power-domains = <&power RK3576_PD_NPU1>;
> + iommus = <&rknn_mmu_1>;
> + status = "disabled";
> + };
> +
> + rknn_mmu_1: iommu@2770a000 {
> + compatible = "rockchip,rk3576-iommu", "rockchip,rk3568-iommu";
> + reg = <0x0 0x2770a000 0x0 0x100>,
> + <0x0 0x2770a100 0x0 0x100>;
[Severity: High]
Is this physical register address mapped correctly?
It looks like the base address is misplaced by 0x8000 relative to where it
belongs inside the rknn_core_1 memory footprint. The rknn_core_1 registers
span 0x27710000-0x27715000, with a 1-page gap at 0x27712000 for the IOMMU
(which is structurally symmetric to rknn_core_0 having its IOMMU at
0x27702000).
When the IOMMU driver attempts to access 0x2770a000 instead of 0x27712000, it
will likely cause a Synchronous External Abort or fail to translate memory
for the NPU.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=8
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: qcom: glymur-gcc: Add missing CX power domain
From: Taniya Das @ 2026-07-17 9:30 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Abel Vesa, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maulik Shah,
Dmitry Baryshkov, Jyothi Kumar Seerapu, Konrad Dybcio,
Brian Masney, Krzysztof Kozlowski, Sibi Sankar, Pankaj Patil,
Akhil P Oommen, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Jishnu Prakash, Raviteja Laggyshetty, Kamal Wadhwa,
Qiang Yu, Manaf Meethalavalappu Pallikunhi, Abel Vesa
In-Reply-To: <almBxBhYxTR9n5FZ@baldur>
On 7/17/2026 6:45 AM, Bjorn Andersson wrote:
> On Thu, Jul 16, 2026 at 04:42:11PM +0530, Taniya Das wrote:
>>
>>
>> On 7/16/2026 12:52 PM, Abel Vesa wrote:
>>> On 26-07-16 10:13:48, Taniya Das wrote:
>>>>
>>>>
>>>> On 7/15/2026 6:59 PM, Abel Vesa wrote:
>>>>> The GDSCs provided by the Glymur GCC are supplied by the RPMh CX power
>>>>> domain. Model that parent domain in the GCC binding so the provider can
>>>>> describe the dependency in devicetree.
>>>>>
>>>>> Add a single CX power-domain entry to the binding and make it required,
>>>>> matching the hardware description needed by the GCC node.
>>>>>
>>>>> Fixes: ee2d967030fe ("dt-bindings: clock: qcom: document the Glymur Global Clock Controller")
>>>>> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/clock/qcom,glymur-gcc.yaml | 8 ++++++++
>>>>> 1 file changed, 8 insertions(+)
>>>>
>>>>
>>>> Abel, I feel we should add the 'required-opps' as well which will ensure
>>>> the clock controllers minimum voltage requirement.
>>>
>>> But it was agreed in v1 that we should not add the required-opps. So we
>>> dropped it in v2.
>>>
>>
>> Okay, sorry, may be I missed that comment.
>>
>>
>>> Can you give more details to why you think it is needed ?
>>
>> My reasoning is that if a clock controller requires a rail, it is
>> preferable to explicitly specify the required operating level rather
>> than rely on system/client vote. This makes the dependency
>> self-contained and easier to reason about. Clients that require a higher
>> operating level than the clock controller's minimum requirement remain
>> free to vote for a higher level as needed.
>>
>
> You're expressing this in generic terms, can you please provide the
> concrete example of what this would look for in the Glymur GCC case?
>
Yes, Bjorn, this is indeed a general requirement for a clock controller.
In Glymur I do see that CX could drop to retention corner in case there
is no vote from any subsystem and so it is better to vote from clock
controller a level above retention using the required-opps.
> What is the required-opps for the Glymur GCC?
LOW_SVS(rpmhpd_opp_low_svs) corner should be good for GCC controller.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v4 03/11] power: sequencing: Add pwrseq_is_controllable() API
From: Bartosz Golaszewski @ 2026-07-17 9:29 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-3-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:20 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> On some boards a power sequencing target has no host-controllable enable
> for its function, for instance when the enable line is not wired up to a
> GPIO and is hardwired to an always-on level. The pcie-m2 "uart" target is
> one such example: when the M.2 connector does not route the W_DISABLE2#
> signal to a host GPIO, its enable/disable are no-ops and the consumer
> cannot gate the Bluetooth function at all or exclusively.
>
> Add a generic pwrseq_is_controllable() helper. It reports whether the
> target's final unit provides a host-controllable dedicated power actuator.
> The target can implement a new optional is_controllable() callback,
> reporting whether that actuator is effective on this target (for example
> depending on GPIO presence). If the target does not provide the callback,
> it is assumed to be controllable.
>
> Note this only describes the target's own enable actuator. It does not
> imply that a power-off reaches an electrical OFF state, since a target may
> have multiple consumers. It also does not mean that power is uncontrolled
> for the target's dependencies: those may still be gated on their own. And
> it does not restrict consumers from calling pwrseq_power_off() either,
> which remains valid to drop this consumer's vote on the (possibly shared)
> resources and dependencies of the target.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Thanks, this looks good to me now. This series is a bit all over the place,
what is the merge strategy?
Bart
^ permalink raw reply
* Re: [PATCH v4 09/11] dt-bindings: connector: pcie-m2-e: Add vendor LGA connector compatible
From: Bartosz Golaszewski @ 2026-07-17 9:27 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Krzysztof Kozlowski,
Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-9-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:26 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> Some modules (e.g. the Qualcomm QCA2066/QCNFA765) expose the same M.2
> Key E interface signals but are physically soldered as an LGA package
> rather than plugged into a real M.2 Key E connector socket. Such designs
> are not actual M.2 Key E connectors, so describe them with a dedicated
> vendor-specific compatible while keeping "pcie-m2-e-connector" as a
> fallback for the shared signal semantics.
>
> Add "qcom,pcie-m2-1418-lga-connector" for the M.2 LGA 1418 found on
> Arduino Ventuno Q (Monaco Monza).
>
> Add "qcom,pcie-m2-1620-lga-connector" for the M.2 LGA 1620 found on
> The Lenovo Thinkpad T14s.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: Add Maxio MAE0621A PHY
From: Liu Changjie @ 2026-07-17 9:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Luo Jie, Wolfram Sang,
devicetree, linux-kernel
In-Reply-To: <20260717-immortal-moth-of-will-6ab571@quoll>
Hi Krzysztof,
> How did you address previous feedback?
>
> If you ignore feedback, shall we ignore the patch?
You are right. I should have documented the disposition of Andrew's
comment in this patch's changelog below the --- separator, rather than
only in the cover letter. Sorry about that.
Andrew suggested allowing a value of 0 to disable CLKOUT and noted that
this could also be added later. I intentionally did not add 0 in v2. The
only setting I have tested on this PHY is 125 MHz, and public documentation
for page 0xa43, register 0x19 is not available, so I cannot yet verify the
register programming and reset requirements for disabling CLKOUT.
Andrew's comment:
https://lore.kernel.org/r/1a02ef89-2608-44c4-847f-239d9b86c7ab@lunn.ch
The deferral is recorded in the cover letter's Changes in v2 section:
https://lore.kernel.org/r/MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com
I did not intend to ignore the feedback; I deferred that optional extension
until it can be documented and tested properly. I will state this explicitly
in the per-patch changelog in any future revision.
Best regards,
Liu Changjie
^ permalink raw reply
* Re: [PATCH v4 0/3] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-07-17 9:25 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260717-qcom-spmi-haptics-v4-0-b0fe0ed30849@oss.qualcomm.com>
On 17/07/2026 09:28, Fenglin Wu wrote:
> Dependencies:
> - [patch 2/3] depends on [patch 1/3] and they should be applied together
>
Why are you cc-ing internal kernel@oss.qualcomm.com?
I already asked you TWICE. Both times you ignored that, so that's it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: arm: fsl: Add i.MX93 Wireless FRDM board
From: Krzysztof Kozlowski @ 2026-07-17 9:24 UTC (permalink / raw)
To: Joseph Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260717-imx93w_frdm-v1-2-0cca6c0ba2f5@nxp.com>
On Fri, Jul 17, 2026 at 02:11:53PM +0900, Joseph Guo wrote:
> Add DT compatible string for NXP i.MX93 Wireless FRDM board.
>
> i.MX93 Wireless SiP is created by integrating i.MX93 and IW610 WLCSP
> (Wi-Fi + BLE + 802.15.4). And i.MX93 Wireless FRDM board with the i.MX93
> Wireless SiP basically reuse the i.MX93 11x11 FRDM board, with some minor
> functional and pin connection differences.
>
> Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: media: i2c: Add Samsung S5KJN5 image sensor
From: Krzysztof Kozlowski @ 2026-07-17 9:23 UTC (permalink / raw)
To: Wenmeng Liu
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, linux-media, devicetree, linux-kernel
In-Reply-To: <20260717-sk5jn5-v1-1-da610d7fd494@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 12:08:36PM +0800, Wenmeng Liu wrote:
> +SAMSUNG S5KJN5 CAMERA DRIVER
> +M: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> +L: linux-media@vger.kernel.org
> +S: Supported
> +T: git git://linuxtv.org/media_tree.git
Drop, unless you have commit rights there.
> +F: Documentation/devicetree/bindings/media/i2c/samsung,s5kjn5.yaml
> +
With this fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 5/9] iommu/rockchip: skip orphaned-fault banks in CMD_ENABLE_STALL dispatch
From: sashiko-bot @ 2026-07-17 9:23 UTC (permalink / raw)
To: Jiaxing Hu; +Cc: conor+dt, devicetree, robh, dri-devel
In-Reply-To: <20260717085220.3212274-6-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [Medium] Missing reset_control_put() causes a resource leak on PM domain removal.
- [Medium] rk_iommu_disable_stall() unconditionally times out if all MMU banks are in the orphaned-fault state.
- [Low] Relaxing the global 'required' list breaks validation for RK3588 NPU.
Pre-existing issues:
- [High] On multi-bank IOMMUs (num_mmu > 1), rk_iommu_disable_stall and rk_iommu_disable_paging return success prematurely when disabling, potentially leaving banks active.
- [High] The `rk_iommu_probe` function contains a critical flaw in how it populates and handles errors in the `iommu->bases` array, leading to a guaranteed kernel panic on malformed device trees and a sparse array bug resulting in `ERR_PTR` dereferences.
--
--- Patch [5]: [RFC PATCH 5/9] iommu/rockchip: skip orphaned-fault banks in CMD_ENABLE_STALL dispatch ---
commit e1850eec170c4af87cf79a1f7f05257d02a8ccf8
Author: Jiaxing Hu <gahing@gahingwoo.com>
iommu/rockchip: skip orphaned-fault banks in CMD_ENABLE_STALL dispatch
Sending CMD_ENABLE_STALL to a bank that carries an orphaned firmware
fault (PAGE_FAULT_ACTIVE & !STALL_ACTIVE & IDLE) causes the command to
be silently dropped by that bank. The dropped command also interferes
with the other banks' stall transition, delaying them past the poll
timeout even though they would otherwise stall within a few
microseconds.
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index ad462cee6bd89..7dbcc978ede79 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -436,7 +436,21 @@ static int rk_iommu_enable_stall(struct rk_iommu *iommu)
> if (!rk_iommu_is_paging_enabled(iommu))
> return 0;
>
> - rk_iommu_command(iommu, RK_MMU_CMD_ENABLE_STALL);
> + /*
> + * Do not send CMD_ENABLE_STALL to orphaned-fault banks
> + * (PAGE_FAULT_ACTIVE & !STALL_ACTIVE & IDLE): the command is ignored
> + * by such a bank but its presence on the shared bus delays the other
> + * banks from reaching STALL_ACTIVE within the poll timeout.
> + */
> + for (i = 0; i < iommu->num_mmu; i++) {
> + u32 status = rk_iommu_read(iommu->bases[i], RK_MMU_STATUS);
> +
> + if ((status & RK_MMU_STATUS_PAGE_FAULT_ACTIVE) &&
> + !(status & RK_MMU_STATUS_STALL_ACTIVE) &&
> + (status & RK_MMU_STATUS_IDLE))
> + continue;
> + writel(RK_MMU_CMD_ENABLE_STALL, iommu->bases[i] + RK_MMU_COMMAND);
> + }
>
> ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
> val, RK_MMU_POLL_PERIOD_US,
[Severity: Medium]
Does rk_iommu_disable_stall() unconditionally timeout if all MMU banks are in
the orphaned-fault state?
Looking at rk_iommu_is_stall_active(), if all banks are orphaned, the loop
skips evaluating them:
drivers/iommu/rockchip-iommu.c:rk_iommu_is_stall_active() {
...
for (i = 0; i < iommu->num_mmu; i++) {
...
if ((status & RK_MMU_STATUS_PAGE_FAULT_ACTIVE) &&
!(status & RK_MMU_STATUS_STALL_ACTIVE) &&
(status & RK_MMU_STATUS_IDLE))
continue;
active &= !!(status & RK_MMU_STATUS_STALL_ACTIVE);
}
return active;
}
Since 'active' starts as true, it remains true and does not reflect their
bypassed state, meaning a fully-skipped IOMMU reports as stalled.
Then in rk_iommu_disable_stall():
drivers/iommu/rockchip-iommu.c:rk_iommu_disable_stall() {
...
ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
!val, RK_MMU_POLL_PERIOD_US,
RK_MMU_POLL_TIMEOUT_US);
...
}
The polling loop waits for !rk_iommu_is_stall_active(), which will
unconditionally exhaust its timeout if all banks are orphaned and continually
report as stalled.
[Severity: High]
This is a pre-existing issue, but do rk_iommu_disable_stall() and
rk_iommu_disable_paging() return success prematurely when disabling on
multi-bank IOMMUs?
Because of the bitwise AND reduction in rk_iommu_is_stall_active():
drivers/iommu/rockchip-iommu.c:rk_iommu_is_stall_active() {
...
for (i = 0; i < iommu->num_mmu; i++) {
...
active &= !!(status & RK_MMU_STATUS_STALL_ACTIVE);
}
return active;
}
The function returns false (indicating no stall) if ANY single bank has
finished its stall transition, ignoring banks that are still active.
Then in rk_iommu_disable_stall():
drivers/iommu/rockchip-iommu.c:rk_iommu_disable_stall() {
...
ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
!val, RK_MMU_POLL_PERIOD_US,
...
}
The poll condition !val incorrectly succeeds as soon as any single bank
unstalls, potentially leaving other hardware banks active.
[Severity: High]
This is a pre-existing issue, but is there a risk of a kernel panic in
rk_iommu_probe() due to how the iommu->bases array is handled?
If the device tree has 0 resources, or if devm_ioremap_resource() fails for an
early resource but succeeds for a later one in a multi-MMU configuration, the
array is populated sparsely:
drivers/iommu/rockchip-iommu.c:rk_iommu_probe() {
...
for (i = 0; i < num_res; i++) {
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
if (!res)
continue;
iommu->bases[i] = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(iommu->bases[i]))
continue;
iommu->num_mmu++;
}
if (iommu->num_mmu == 0)
return PTR_ERR(iommu->bases[0]);
...
}
If zero resources are provided, devm_kcalloc() returns ZERO_SIZE_PTR, which is
then invalidly dereferenced at index 0. Also, if an early resource fails
mapping, the array is populated sparsely using loop index 'i' instead of
'num_mmu', but runtime logic expects contiguous valid pointers, leading to a
dereference of ERR_PTR during register reads.
[Severity: Medium]
Does rockchip_pm_remove_one_domain() miss freeing reset controls on
PM domain removal?
When the PM domain is removed (e.g., during driver unbind) or if probing
fails for a later power domain:
drivers/pmdomain/rockchip/pm-domains.c:rockchip_pm_remove_one_domain() {
...
clk_bulk_unprepare(pd->num_clks, pd->clks);
clk_bulk_put(pd->num_clks, pd->clks);
...
}
This teardown function misses the reset_control_put() call to free the
reset controls retrieved during addition, causing a resource leak.
[Severity: Low]
Does relaxing the global 'required' list break validation for RK3588 NPU?
Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml:
...
- reset-names
- npu-supply
additionalProperties: false
...
The 'sram-supply' property was removed from the global 'required' list here.
Will DT schema validation fail to flag missing 'sram-supply' for RK3588
devices?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=5
^ permalink raw reply
* Re: [PATCH v6 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-07-17 9:25 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger, Sean Young, Julian Braha
In-Reply-To: <alibzwe9Mjf3GxJo@monoceros>
Hi Uwe,
On 11:18 Thu 16 Jul , Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Jul 03, 2026 at 07:05:25PM +0200, Andrea della Porta wrote:
> > +static int rp1_pwm_round_waveform_tohw(struct pwm_chip *chip,
> > + struct pwm_device *pwm,
> > + const struct pwm_waveform *wf,
> > + void *_wfhw)
> > +{
> > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > + u64 period_ticks, duty_ticks, offset_ticks;
> > + struct rp1_pwm_waveform *wfhw = _wfhw;
> > + u64 clk_rate = rp1->clk_rate;
> > + int ret = 0;
> > +
> > + if (!wf->period_length_ns) {
> > + wfhw->enabled = false;
> > + wfhw->inverted_polarity = (pwm_get_polarity(pwm) == PWM_POLARITY_INVERSED);
>
> pwm_get_polarity(pwm) looks wrong here for several reasons. 1st the
> polarity is defined in *wf and should not depend on the current state,
> 2nd for a disabled hardware the polarity doesn't matter anyhow, and 3rd
> you should not call pwm API functions from the lowlevel driver (which
> might interfere with subsystem locking).
Ok, but in this case what the output of the disabled channel should be?
If it was inverted before the disable, would it make sense to let the output
be high? Or are we allowed to hard code a polarity value on disable?
>
> Also please initialize the whole structure, best done using:
>
> *wfhw = (typeof(*wfhw)){
> .enabled = false,
> }
Ack. In this case inverted_polarity would be falsei though, see above.
>
> > + return 0;
> > + }
> > +
> > + period_ticks = mul_u64_u64_div_u64(wf->period_length_ns, clk_rate, NSEC_PER_SEC);
> > +
> > + /*
> > + * The period is limited to U32_MAX, and it will be decremented by one later
> > + * to allow 100% duty cycle.
> > + */
> > + if (period_ticks > U32_MAX) {
> > + period_ticks = U32_MAX;
> > + } else if (period_ticks < 2) {
> > + period_ticks = 2;
> > + ret = 1;
> > + }
> > +
> > + duty_ticks = mul_u64_u64_div_u64(wf->duty_length_ns, clk_rate, NSEC_PER_SEC);
> > + duty_ticks = min(duty_ticks, period_ticks);
> > + offset_ticks = mul_u64_u64_div_u64(wf->duty_offset_ns, clk_rate, NSEC_PER_SEC);
> > + if (offset_ticks >= period_ticks) {
> > + u64 remainder;
> > +
> > + div64_u64_rem(offset_ticks, period_ticks, &remainder);
> > + offset_ticks = remainder;
>
> offset_ticks = period_ticks - 1;
Ack.
>
> > + }
> > + if (duty_ticks && offset_ticks &&
> > + duty_ticks + offset_ticks >= period_ticks) {
> > + wfhw->duty_ticks = period_ticks - duty_ticks;
> > + wfhw->inverted_polarity = true;
> > + } else {
> > + wfhw->duty_ticks = duty_ticks;
> > + wfhw->inverted_polarity = false;
> > + }
> > + /* Account for the extra tick at the end of the period */
> > + wfhw->period_ticks = period_ticks - 1;
> > +
> > + wfhw->enabled = true;
> > +
> > + return ret;
> > +}
> > +
> > +static int rp1_pwm_round_waveform_fromhw(struct pwm_chip *chip,
> > + struct pwm_device *pwm,
> > + const void *_wfhw,
> > + struct pwm_waveform *wf)
> > +{
> > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > + const struct rp1_pwm_waveform *wfhw = _wfhw;
> > + u64 clk_rate = rp1->clk_rate;
> > + u64 ticks;
> > +
> > + *wf = (struct pwm_waveform){ };
> > +
> > + if (!wfhw->enabled)
> > + return 0;
> > +
> > + wf->period_length_ns = DIV_ROUND_UP_ULL(((u64)wfhw->period_ticks + 1) * NSEC_PER_SEC,
> > + clk_rate);
> > +
> > + if (!wfhw->inverted_polarity) {
> > + wf->duty_length_ns = DIV_ROUND_UP_ULL((u64)wfhw->duty_ticks * NSEC_PER_SEC,
> > + (u32)clk_rate);
> > + } else {
> > + if (wfhw->duty_ticks > (u64)wfhw->period_ticks + 1) {
> > + /* 100% duty cycle case */
> > + ticks = 0;
> > + } else {
> > + ticks = (u64)wfhw->period_ticks + 1 - wfhw->duty_ticks;
> > + }
> > + wf->duty_length_ns = DIV_ROUND_UP_ULL(ticks * NSEC_PER_SEC, clk_rate);
> > + wf->duty_offset_ns = wf->period_length_ns - wf->duty_length_ns;
>
> The duty_offset_ns calculation is wrong.
>
> Consider clk_rate = 3000000, period_ticks = 8, inverted_polarity = true and
> duty_ticks = 4.
>
> Then you have:
>
> .period_length_ns = 2666.6666666666666 ns ~> 2667
> .duty_length_ns = 1333.3333333333333 ns -> 1334
> .duty_offset_ns = 1333.3333333333333 ns -> 1334
>
> but .period_length_ns - .duty_length_ns is 1333.
>
> To get this right, you have to calculate
>
> wf->duty_offset_ns = DIV_ROUND_UP_ULL((u64)(wfhw->period_ticks + 1 - ticks) * NSEC_PER_SEC, clk_rate);
So it will end up as 'duty_length_ns + duty_offset_ns > period_length_ns', which is
timing violation. Is it allowed (or even required) in the PWM subsystem?
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int rp1_pwm_write_waveform(struct pwm_chip *chip,
> > + struct pwm_device *pwm,
> > + const void *_wfhw)
> > +{
> > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > + const struct rp1_pwm_waveform *wfhw = _wfhw;
> > + u32 value, ctrl;
> > +
> > + /* set polarity */
> > + regmap_read(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm), &value);
> > + if (!wfhw->inverted_polarity)
> > + value &= ~RP1_PWM_CHAN_CTRL_POLARITY;
> > + else
> > + value |= RP1_PWM_CHAN_CTRL_POLARITY;
> > + regmap_write(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm), value);
> > +
> > + /* early exit if disabled */
> > + regmap_read(rp1->regmap, RP1_PWM_GLB_CTRL, &ctrl);
> > + if (!wfhw->enabled) {
> > + ctrl &= ~RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(pwm->hwpwm);
> > + goto exit_disable;
>
> Please don't use goto unless for error handling.
Ack.
>
> > + }
> > +
> > + /* set period and duty cycle */
> > + regmap_write(rp1->regmap,
> > + RP1_PWM_RANGE(pwm->hwpwm), wfhw->period_ticks);
> > + regmap_write(rp1->regmap,
> > + RP1_PWM_DUTY(pwm->hwpwm), wfhw->duty_ticks);
> > +
> > + /* enable the channel */
> > + ctrl |= RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(pwm->hwpwm);
> > +exit_disable:
> > + regmap_write(rp1->regmap, RP1_PWM_GLB_CTRL, ctrl);
> > +
> > + rp1_pwm_apply_config(chip, pwm);
> > +
> > + return 0;
> > +}
> > +
> > +static int rp1_pwm_read_waveform(struct pwm_chip *chip,
> > + struct pwm_device *pwm,
> > + void *_wfhw)
> > +{
> > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > + struct rp1_pwm_waveform *wfhw = _wfhw;
> > + u32 value;
> > +
> > + regmap_read(rp1->regmap, RP1_PWM_GLB_CTRL, &value);
> > + wfhw->enabled = !!(value & RP1_PWM_GLB_CTRL_CHANNEL_ENABLE(pwm->hwpwm));
> > +
> > + regmap_read(rp1->regmap, RP1_PWM_CHAN_CTRL(pwm->hwpwm), &value);
> > + wfhw->inverted_polarity = !!(value & RP1_PWM_CHAN_CTRL_POLARITY);
> > +
> > + if (wfhw->enabled) {
> > + regmap_read(rp1->regmap, RP1_PWM_RANGE(pwm->hwpwm), &wfhw->period_ticks);
> > + regmap_read(rp1->regmap, RP1_PWM_DUTY(pwm->hwpwm), &wfhw->duty_ticks);
> > + } else {
> > + wfhw->period_ticks = 0;
> > + wfhw->duty_ticks = 0;
> > + }
>
> Ideally use *wfhw = (typeof(*wfhw)){ ... } here, too, to make it obvious
> that the complete struct is initialized.
Ack.
>
> > +
> > + return 0;
> > +}
> > [...]
> > +static struct platform_driver rp1_pwm_driver = {
> > + .probe = rp1_pwm_probe,
> > + .remove = rp1_pwm_remove,
> > + .driver = {
> > + .name = "rp1-pwm",
> > + .of_match_table = rp1_pwm_of_match,
> > + .pm = pm_ptr(&rp1_pwm_pm_ops),
> > + .suppress_bind_attrs = true,
>
> If the driver cannot be removed, .remove() is just dead code. Drop it
> and note in a comment that this is needed because a syscon cannot be
> removed.
Ack.
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [RFC PATCH 7/9] accel/rocket: add RK3576 NPU (RKNN) support
From: sashiko-bot @ 2026-07-17 9:21 UTC (permalink / raw)
To: Jiaxing Hu; +Cc: conor+dt, robh, dri-devel, devicetree
In-Reply-To: <20260717085220.3212274-8-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
New issues:
- [High] Unconditional clock and reset requests break driver initialization on RK3588.
- [High] Unhandled completion interrupts cause an interrupt storm on RK3588.
- [High] Using cancel_work() in rocket_reset() causes a race condition and hardware state corruption.
- [High] TOCTOU race in rocket_job_timedout() allows MMIO reads on a suspended device.
- [Medium] DPU and DPU_RDMA pre-arming logic is missing despite claims in the commit message.
Pre-existing issues:
- [High] Shared IRQ handler unconditionally accesses MMIO without verifying the device is active.
--
--- Patch [7]: [RFC PATCH 7/9] accel/rocket: add RK3576 NPU (RKNN) support ---
commit 44e533d6c3c461a28b2f0fb3ee35a8a9e75c974a
Author: Jiaxing Hu <gahing@gahingwoo.com>
accel/rocket: add RK3576 NPU (RKNN) support
Add RK3576 support to the rocket DRM accelerator driver (used with the
Mesa Teflon TFLite delegate).
[ ... ]
> - map the DPU (0x4000) and DPU_RDMA (0x5000) blocks and pre-arm them
[Severity: Medium]
The commit message mentions mapping and pre-arming the DPU and DPU_RDMA
blocks, and the accessor macros like rocket_dpu_writel are defined in
rocket_core.h. However, looking at rocket_job_hw_submit() in
rocket_job.c, there are no writes to these registers. Was the pre-arming
logic omitted by accident? Without it, might the compute path stall after
loading one slice on RK3576?
> diff --git a/drivers/accel/rocket/rocket_core.c b/drivers/accel/rocket/rocket_core.c
> --- a/drivers/accel/rocket/rocket_core.c
> +++ b/drivers/accel/rocket/rocket_core.c
> @@ -22,12 +23,23 @@ int rocket_core_init(struct rocket_core *core)
> int err = 0;
>
> core->resets[0].id = "srst_a";
> - core->resets[1].id = "srst_h";
> err = devm_reset_control_bulk_get_exclusive(&pdev->dev, ARRAY_SIZE(core->resets),
> core->resets);
[Severity: High]
Will this break initialization on RK3588? The srst_h reset line has been
removed from the array, meaning the RK3588 hardware might not be fully
reset during probe.
> if (err)
> return dev_err_probe(dev, err, "failed to get resets for core %d\n", core->index);
>
> + core->clks[0].id = "aclk";
> + core->clks[1].id = "hclk";
> + core->clks[2].id = "npu";
> + core->clks[3].id = "pclk";
> + /*
> + * RK3576: the CBUF (convolution buffer) has its own clock domain. The CNA
> + * fills the CBUF and CORE reads from it; without these the compute path
> + * stalls after loading one slice (RDMA, which bypasses the CBUF, still
> + * runs). The vendor keeps all NPU clocks on whenever powered.
> + */
> + core->clks[4].id = "aclk_cbuf";
> + core->clks[5].id = "hclk_cbuf";
> err = devm_clk_bulk_get(dev, ARRAY_SIZE(core->clks), core->clks);
[Severity: High]
Does this unconditional request for RK3576-specific clocks cause the probe
to fail on RK3588? If aclk_cbuf and hclk_cbuf do not exist in the RK3588
device tree, devm_clk_bulk_get() will return -ENOENT and break support for
the older platform.
[ ... ]
> diff --git a/drivers/accel/rocket/rocket_job.c b/drivers/accel/rocket/rocket_job.c
> --- a/drivers/accel/rocket/rocket_job.c
> +++ b/drivers/accel/rocket/rocket_job.c
[ ... ]
> @@ -137,8 +148,21 @@ static void rocket_job_hw_submit(struct rocket_core *core, struct rocket_job *jo
> rocket_pc_writel(core, REGISTER_AMOUNTS,
> PC_REGISTER_AMOUNTS_PC_DATA_AMOUNT((task->regcmd_count + 1) / 2 - 1));
>
> - rocket_pc_writel(core, INTERRUPT_MASK, PC_INTERRUPT_MASK_DPU_0 | PC_INTERRUPT_MASK_DPU_1);
> - rocket_pc_writel(core, INTERRUPT_CLEAR, PC_INTERRUPT_CLEAR_DPU_0 | PC_INTERRUPT_CLEAR_DPU_1);
> + /* Enable DMA-error interrupts; PC_DONE (bits 28-29) is polled, see above. */
> + rocket_pc_writel(core, INTERRUPT_MASK,
> + PC_INTERRUPT_MASK_DPU_0 | PC_INTERRUPT_MASK_DPU_1 |
> + PC_INTERRUPT_MASK_CORE_0 | PC_INTERRUPT_MASK_CORE_1 |
> + PC_INTERRUPT_MASK_PPU_0 | PC_INTERRUPT_MASK_PPU_1 |
> + PC_INTERRUPT_MASK_CNA_CSC_0 | PC_INTERRUPT_MASK_CNA_CSC_1 |
> + PC_INTERRUPT_MASK_DMA_READ_ERROR |
> + PC_INTERRUPT_MASK_DMA_WRITE_ERROR);
[Severity: High]
Could this lead to an interrupt storm on RK3588? In rocket_job_hw_submit(),
completion interrupts like DPU_0 and CORE_0 are unmasked in hardware.
However, rocket_job_irq_handler() now masks INTERRUPT_RAW_STATUS to only
check DMA errors and returns IRQ_NONE. This means the completion bits are
never cleared and the interrupt is never acknowledged.
[ ... ]
> @@ -326,56 +352,99 @@ static struct dma_fence *rocket_job_run(struct drm_sched_job *sched_job)
[ ... ]
> static void
> rocket_reset(struct rocket_core *core, struct drm_sched_job *bad)
> {
> + struct rocket_job *job;
> +
> if (!atomic_read(&core->reset.pending))
> return;
>
> + atomic_set(&core->poll_active, 0);
> + hrtimer_cancel(&core->poll_timer);
> + cancel_work(&core->poll_work);
[Severity: High]
Is it safe to use the non-blocking cancel_work() here instead of
cancel_work_sync()?
If a job timeout occurs while poll_work is actively executing on another
CPU, it will continue running alongside the reset sequence.
Since rocket_job_handle_irq() writes to OPERATION_ENABLE outside of the
job_lock, this unguarded write could abruptly halt a newly submitted job
after the reset completes.
[ ... ]
> @@ -385,7 +454,14 @@ static enum drm_gpu_sched_stat rocket_job_timedout(struct drm_sched_job *sched_j
> struct rocket_device *rdev = job->rdev;
> struct rocket_core *core = sched_to_core(rdev, sched_job->sched);
>
> - dev_err(core->dev, "NPU job timed out");
> + if (pm_runtime_active(core->dev))
> + dev_err(core->dev,
> + "NPU job timed out: RAW_STATUS=0x%08x MASK=0x%08x OP_EN=0x%08x\n",
> + rocket_pc_readl(core, INTERRUPT_RAW_STATUS),
> + rocket_pc_readl(core, INTERRUPT_MASK),
> + rocket_pc_readl(core, OPERATION_ENABLE));
> + else
> + dev_err(core->dev, "NPU job timed out (device not active)\n");
[Severity: High]
Is there a race condition here that could allow MMIO reads on a suspended
device?
The lockless pm_runtime_active() check does not take a reference to
prevent suspension. If the device autosuspends in the narrow window between
the check and the rocket_pc_readl() calls, this might trigger a bus fault.
Would using pm_runtime_get_if_active() be safer?
[ ... ]
> @@ -420,14 +496,16 @@ static irqreturn_t rocket_job_irq_handler(int irq, void *data)
> {
> struct rocket_core *core = data;
> u32 raw_status = rocket_pc_readl(core, INTERRUPT_RAW_STATUS);
[Severity: High]
This is a pre-existing issue, but since the IRQ handler is registered
with IRQF_SHARED, could reading INTERRUPT_RAW_STATUS unconditionally cause
a kernel panic if the device is runtime suspended?
If another device on the same IRQ line fires, reading unpowered MMIO
registers will trigger a synchronous external abort. Should this check
pm_runtime_get_if_active() first?
> + /* Only bits 0-13 (DMA errors) can raise this IRQ; PC_DONE is polled. */
> + u32 active = raw_status & 0x3fff;
> +
> + if (!active)
> + return IRQ_NONE;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=7
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: can: xilinx_can: Document phys property
From: Krzysztof Kozlowski @ 2026-07-17 9:20 UTC (permalink / raw)
To: Harini T
Cc: mkl, mailhol, robh, krzk+dt, conor+dt, michal.simek,
appana.durga.kedareswara.rao, linux-can, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260717021415.2234865-3-harini.t@amd.com>
On Fri, Jul 17, 2026 at 07:44:15AM +0530, Harini T wrote:
> The Xilinx CAN and CANFD controllers can be connected to an external
> CAN transceiver on the board. That connection is described with the
> standard "phys" property on the controller node, pointing to a CAN
> transceiver PHY node which models the transceiver and its control
> lines (for example the standby/enable signals).
>
> Describe the optional "phys" property (a single transceiver PHY) so
> the on-board CAN transceiver can be described in the device tree.
>
> Signed-off-by: Harini T <harini.t@amd.com>
> ---
> Documentation/devicetree/bindings/net/can/xilinx,can.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: Replace maintainer for Xilinx CAN driver
From: Krzysztof Kozlowski @ 2026-07-17 9:19 UTC (permalink / raw)
To: Harini T
Cc: mkl, mailhol, robh, krzk+dt, conor+dt, michal.simek,
appana.durga.kedareswara.rao, linux-can, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260717021415.2234865-2-harini.t@amd.com>
On Fri, Jul 17, 2026 at 07:44:14AM +0530, Harini T wrote:
> Replace Appana Durga Kedareswara rao with Harini T as the maintainer
> of the Xilinx CAN driver. Kedar is no longer maintaining it.
>
> Signed-off-by: Harini T <harini.t@amd.com>
> ---
> Documentation/devicetree/bindings/net/can/xilinx,can.yaml | 2 +-
> MAINTAINERS | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 11/11] arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm
From: Komal Bajaj @ 2026-07-17 9:19 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dmaengine, devicetree, linux-kernel, linux-pm,
Anurag Pateriya
In-Reply-To: <1153ebbd-659f-4ba9-9317-66ece33423e9@oss.qualcomm.com>
On 7/17/2026 12:03 AM, Konrad Dybcio wrote:
> On 7/15/26 3:41 PM, Komal Bajaj wrote:
>>
>>
>> On 7/15/2026 3:57 PM, Konrad Dybcio wrote:
>>> On 7/7/26 6:36 PM, Komal Bajaj wrote:
>>>> On 7/2/2026 4:25 PM, Konrad Dybcio wrote:
>>>>> On 7/2/26 11:50 AM, Komal Bajaj wrote:
>>>>>> Add gpio-reserved-ranges property to the tlmm node for all three
>>>>>> Shikra EVK variants (CQM, CQS, IQS) to mark GPIOs used by the
>>>>>> SoC internally and not available for general use.
>>>>> These are generally added to prevent non-secure access upon TLMM
>>>>> probe, i.e. the board won't boot if some of them are not protected.
>>>>>
>>>>> I assume the proposed set contains both ones that are _absolutely
>>>>> forbidden_ for Linux to touch, but also ones that are dedicated to
>>>>> some specific purpose that Linux _shouldn't_ touch.
>>>> Yes, some GPIOs are reserved for secure-world use and are therefore not accessible from the non-secure world.
>>>> I will update the commit message accordingly.
>>> I'm not sure how to read your response. In other words - is this
>>> patch boot-critical?
>> Yes, with Access Policy enabled, it becomes boot-critical.
> Well then, I'm no less than surprised since we have DTs for 3 boards
> in -next right now that I'm learning can't possibly boot..
>
> I understand you might have disabled that at some point during the
> development, but it's clearly not the configuration that's supported
> by any means. Please make sure to take that into account next time.
Development initially started with firmware builds that did not have
Access Policy enabled.
Recently, firmware has since been updated to enable Access Policy, which
makes these GPIOs boot-critical and requires this change.
If its needed, I can add Fixes tag.
>
> For this issue, since the pins seem common, perhaps moving them to
> the SoM DTSI makes more sense. And this most definitely needs 'fixes'
> tags.
Makes sense. I'll move it to the SoM DTSI in the next revision.
Thanks
Komal
>
> Konrad
^ permalink raw reply
* Re: [PATCH v3 4/4] regulator: axp20x: add support for the AXP318W
From: sashiko-bot @ 2026-07-17 9:18 UTC (permalink / raw)
To: Jerome Brunet; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260717-axp318-regulator-v3-4-779dc1b97dd4@baylibre.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unhandled AXP318_ID variant in `axp20x_set_dcdc_workmode` triggers a kernel splat if `x-powers,dcdc-workmode` is in the Device Tree.
--
--- Patch [4]: [PATCH v3 4/4] regulator: axp20x: add support for the AXP318W ---
commit 8de3219334d650160512cfdeb429dbaddb9ab5cb
Author: Andre Przywara <andre.przywara@arm.com>
regulator: axp20x: add support for the AXP318W
The X-Powers AXP318W is a typical PMIC from X-Powers, featuring nine
DC/DC converters and 28 LDOs, on the regulator side. Describe the chip's
voltage settings and switch registers, how the voltages are encoded, and
connect this to the MFD device via its regulator ID.
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index da891415efc0b..6f887250d6402 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
[ ... ]
> @@ -1585,6 +1858,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> regulators = axp313a_regulators;
> nregulators = AXP313A_REG_ID_MAX;
> break;
> + case AXP318_ID:
> + regulators = axp318_regulators;
> + nregulators = AXP318_REG_ID_MAX;
> + break;
> case AXP717_ID:
> regulators = axp717_regulators;
> nregulators = AXP717_REG_ID_MAX;
[Severity: Medium]
Could this trigger a kernel splat if the device tree contains the
"x-powers,dcdc-workmode" property for an AXP318 regulator?
During initialization in axp20x_regulator_probe(), the property is read
and passed to axp20x_set_dcdc_workmode():
ret = of_property_read_u32(rdev->dev.of_node,
"x-powers,dcdc-workmode",
&workmode);
if (!ret) {
if (axp20x_set_dcdc_workmode(rdev, i, workmode))
...
However, axp20x_set_dcdc_workmode() does not seem to handle AXP318_ID
in its switch statement, which will cause it to fall through to the
default case:
default:
/* should not happen */
WARN_ON(1);
return -EINVAL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-axp318-regulator-v3-0-779dc1b97dd4@baylibre.com?part=4
^ permalink raw reply
* Re: [PATCH 5/7] dt-bindings: reset: Add bindings for MediaTek MT6589 reset controller
From: Krzysztof Kozlowski @ 2026-07-17 9:18 UTC (permalink / raw)
To: Akari Tsuyukusa
Cc: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, open list:WATCHDOG DEVICE DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Roman Vivchar
In-Reply-To: <20260716161923.266315-6-akkun11.open@gmail.com>
On Fri, Jul 17, 2026 at 01:19:21AM +0900, Akari Tsuyukusa wrote:
> Add MT6589 reset controller bindings.
>
> Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
> ---
> include/dt-bindings/reset/mt6589-resets.h | 25 +++++++++++++++++++++++
Filename must match compatible.
Why is this separate from the patch adding the binding? Where is this
explained?
> 1 file changed, 25 insertions(+)
> create mode 100644 include/dt-bindings/reset/mt6589-resets.h
>
> diff --git a/include/dt-bindings/reset/mt6589-resets.h b/include/dt-bindings/reset/mt6589-resets.h
> new file mode 100644
> index 000000000000..18ef729022a9
> --- /dev/null
> +++ b/include/dt-bindings/reset/mt6589-resets.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) 2026 Akari Tsuyukusa <akkun11.open@gmail.com>
> + */
> +
> +#ifndef _DT_BINDINGS_RESET_MT6589_RESETS_H
> +#define _DT_BINDINGS_RESET_MT6589_RESETS_H
> +
> +/* TOPRGU */
> +#define MT6589_TOPRGU_INFRA_RST 0
> +#define MT6589_TOPRGU_DISP_RST 1
> +#define MT6589_TOPRGU_MFG_RST 2
> +#define MT6589_TOPRGU_VENC_RST 3
> +#define MT6589_TOPRGU_VDEC_RST 4
> +#define MT6589_TOPRGU_IMG_RST 5
> +#define MT6589_TOPRGU_DDRPHY_RST 6
> +#define MT6589_TOPRGU_MD_RST 7
> +#define MT6589_TOPRGU_INFRA_AO_RST 8
> +#define MT6589_TOPRGU_MD_LITE_RST 9
> +#define MT6589_TOPRGU_APMIXED_RST 10
> +#define MT6589_TOPRGU_PWRAP_SPICTL_RST 11
> +
> +#define MT6589_TOPRGU_RST_NUM 12
Not a binding, drop.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] watchdog: mtk_wdt: add explicit compatibles for SoCs using mt6589 fallback
From: Krzysztof Kozlowski @ 2026-07-17 9:17 UTC (permalink / raw)
To: Akari Tsuyukusa
Cc: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, open list:WATCHDOG DEVICE DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Roman Vivchar
In-Reply-To: <20260716161923.266315-2-akkun11.open@gmail.com>
On Fri, Jul 17, 2026 at 01:19:17AM +0900, Akari Tsuyukusa wrote:
> Several SoCs currently rely on matching "mediatek,mt6589-wdt" via the
> fallback compatible. Add dedicated of_device_id entries for each of
> them so that the driver can match directly on the SoC-specific string.
This makes no sense, NAK.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support
From: Konrad Dybcio @ 2026-07-17 9:17 UTC (permalink / raw)
To: mohit.dsor, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-kernel, linux-arm-msm, devicetree, venkata.valluru,
Jessica Zhang, Mohit Dsor
In-Reply-To: <20260717-shikra-work-v2-1-86ae8552259e@oss.qualcomm.com>
On 7/16/26 9:30 PM, mohit.dsor@oss.qualcomm.com wrote:
> From: Mohit Dsor <mdsor@oss.qualcomm.com>
>
> Enable the Shikra MDSS display subsystem on the Qualcomm Shikra IQS
> EVK board and add the Lontium LT9611UXD DSI-to-HDMI bridge node.
>
> The LT9611UXD is connected via I2C (bus 4, address 0x41), powered by
> a GPIO-controlled 3.3V regulator (PM8150 GPIO4) and an always-on 1.8V
> rail. Reset is on GPIO76 and interrupt on GPIO85.
>
> The bridge receives DSI output from MDSS and drives an HDMI-A
> connector, with the link wired as: DPU -> DSI0 -> LT9611UXD -> HDMI.
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
Does the other EVK not have this same hardware?
[...]
> +&pm8150_l11 {
> + /* DSI VDDA - must be at NOM voltage for PHY PLL lock */
This comment is superfluous
Konrad
^ permalink raw reply
* Re: [PATCH 08/10] dt-bindings: pwm: apple,s5l-fpwm: Add t8132 compatible
From: Yureka Lilian @ 2026-07-17 9:16 UTC (permalink / raw)
To: Uwe Kleine-König, Yureka Lilian
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Janne Grunau, Neal Gompa, Thomas Gleixner,
Wim Van Sebroeck, Guenter Roeck, Hector Martin, Linus Walleij,
Mark Kettenis, Andi Shyti, Sasha Finkelstein, devicetree,
linux-kernel, asahi, linux-arm-kernel, linux-watchdog, linux-gpio,
linux-i2c, linux-pwm
In-Reply-To: <alj0EbuIzZUa48di@monoceros>
On 7/16/26 17:11, Uwe Kleine-König wrote:
> Hello,
>
> On Sun, Jul 05, 2026 at 03:17:27PM +0200, Yureka Lilian wrote:
>> The PWM controller on the Apple silicon t8132 (M4) SoC is compatible
>> with the existing driver. Add "apple,t8132-fpwm" as SoC specific
>> compatible under "apple,s5l-fpwm" used by the driver.
>>
>> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
>> ---
>> Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
>> index 25ef04b60ca1..c85a2b85a66a 100644
>> --- a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
>> +++ b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
>> @@ -19,6 +19,7 @@ properties:
>> - apple,t8103-fpwm
>> - apple,t8112-fpwm
>> - apple,t8122-fpwm
>> + - apple,t8132-fpwm
>> - apple,t6000-fpwm
>> - apple,t6020-fpwm
>> - const: apple,s5l-fpwm
> There is no merge plan specified in the cover letter, but I assume this
> should go via arm-soc?
Yes, this will go through the appropriate -soc trees since there is no
driver change.
Sorry for not mentioning it in the original cover letter, I wasn't aware
of the procedures at the time.
> In that case:
>
> Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
>
> Best regards
> Uwe
Thanks,
— Yureka
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: watchdog: mediatek,mtk-wdt: remove mt6589 fallback items
From: Krzysztof Kozlowski @ 2026-07-17 9:16 UTC (permalink / raw)
To: Akari Tsuyukusa
Cc: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, open list:WATCHDOG DEVICE DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Roman Vivchar
In-Reply-To: <20260716161923.266315-5-akkun11.open@gmail.com>
On Fri, Jul 17, 2026 at 01:19:20AM +0900, Akari Tsuyukusa wrote:
> All DTS have been converted to standalone compatibles.
> Remove the items block that allowed the "mediatek,mt6589-wdt" fallback,
> keeping only the flat enum.
1. This is not a separate commit.
2. This lacks explanation WHY you are doing.
NAK.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: watchdog: mediatek,mtk-wdt: add compatibles for all SoCs
From: Krzysztof Kozlowski @ 2026-07-17 9:16 UTC (permalink / raw)
To: Akari Tsuyukusa
Cc: Wim Van Sebroeck, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Philipp Zabel, open list:WATCHDOG DEVICE DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Roman Vivchar
In-Reply-To: <20260716161923.266315-3-akkun11.open@gmail.com>
On Fri, Jul 17, 2026 at 01:19:18AM +0900, Akari Tsuyukusa wrote:
> The driver recognizes each SoC-specific compatible, update the binding
> to list them in the top-level enum alongside the existing ones. Keep
> the fallback items definition so that old DTS continue to validate.
>
> Affected SoCs: mt2701, mt6572, mt6582, mt6797, mt7622, mt7623,
> mt7629, mt8173, mt8189, mt8365, mt8516.
I do not understand what and why you are doing. Just because driver
recognizes some compatible is not a reason to move compatibles around.
This completely lacks explanation (in terms of DTS, see writing
bindings).
Best regards,
Krzysztof
^ 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