* Re: [PATCH v4 1/2] dt-bindings: embedded-controller: Add synology,microp device
From: Markus Probst @ 2026-03-27 13:34 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Conor Dooley,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Greg Kroah-Hartman, devicetree, linux-kernel,
rust-for-linux
In-Reply-To: <CAL_JsqJUVh1YnhmYYj4ara5BheaLOL1oayjtWNuPH53q1d4xXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]
On Thu, 2026-03-26 at 14:36 -0500, Rob Herring wrote:
> On Thu, Mar 26, 2026 at 8:02 AM Markus Probst <markus.probst@posteo.de> wrote:
> >
> > On Wed, 2026-03-25 at 17:07 -0500, Rob Herring wrote:
> > > On Sat, Mar 21, 2026 at 01:02:22PM +0000, Markus Probst wrote:
> > > > On Sat, 2026-03-21 at 13:32 +0100, Krzysztof Kozlowski wrote:
> > > > > On 21/03/2026 13:17, Markus Probst wrote:
> > > > > > On Sat, 2026-03-21 at 11:21 +0100, Krzysztof Kozlowski wrote:
> > > > > > > On Fri, Mar 20, 2026 at 11:09:53PM +0100, Markus Probst wrote:
> > > > > > > > +
> > > > > > > > +examples:
> > > > > > > > + - |
> > > > > > > > + #include <dt-bindings/leds/common.h>
> > > > > > > > +
> > > > > > > > + embedded-controller {
> > > > > > > > + compatible = "synology,microp";
> > > > > > > > +
> > > > > > > > + power-led {
> > > > > > > > + color = <LED_COLOR_ID_BLUE>;
> > > > > > > > + function = LED_FUNCTION_POWER;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + status-led {
> > > > > > > > + color = <LED_COLOR_ID_MULTI>;
> > > > > > > > + function = LED_FUNCTION_STATUS;
> > > > > > > > + };
> > > > > > >
> > > > > > > Where are other leds? Binding mentions 4.
> > > > > > >
> > > > > > Status and Power leds exist on every Synology NAS model I am aware of.
> > > > > > But there are models which have additionally a usb or alert led. The
> > > > > > device nodes for those leds should only be present, if they exist
> > > > > > physically on the device.
> > > > >
> > > > > Then help me to understand - are these different models?
> > > > Yes, even with different CPU architectures.
> > > > How much the "microp" device differs is not clear, but the
> > > > communication protocol is the same.
> > > > >
> > > > > EC is not a generic purpose component and is tightly coupled with the
> > > > > actual board it is being present on. Unless exactly same board is used
> > > > > in different models (unlikely) then the compatible defines the LEDs and
> > > > > they are not needed in DT.
> > > > So for instance "synology,ds923p-microp", "synology,ds723p-microp" etc.
> > > > ?
> > > >
> > > > I can do that, but that would be many.
> > >
> > > How many is many?
> > Estimated 300.
>
> Okay, that's a lot and probably safe to say there are not 300
> variations of the EC.
>
> > As a side note: I only have 1 model I can test the driver with.
> > >
> > > > Having it generic seems more flexible.
> > >
> > > Is there firmware for these ECs? If so is it the same or different
> > > firmware for each device? If the former or the functionality is really
> > > trivial, then I'd be more comfortable with 1 or a few compatibles.
> > The firmware is not public and the exact differences between them isn't
> > documented. The communication protocol is the same though.
> >
> > >
> > > Generic means you'll need to add quirk properties when there is some
> > > difference the OS needs to handle which we'll reject. So stuck with one
> > > compatible and no way to distinguish different ECs is anything but
> > > flexible.
> > Describing the physical leds that are present on the NAS device are not
> > quirk properties, at least in my definition.
>
> That's not what I mean. I mean things like this other device needs
> some different timing for power-on/reset or delays between accesses or
> some LED control is inverted or some protocol difference... Could be
> about anything. The key thing is you have specific enough information
> (compatible) to start with that you can handle any issue that comes up
> *without* changing the DT.
>
> As you said, you only have 1 device. Make the binding specific to that
> 1 device. If the next one that comes along can reuse the binding as
> it, then great. Nothing to do. If it can't, then it gets its own new
> compatible. Strictly speaking we would add a new compatible for each
> device, but it's a judgement call that there aren't going to be
> differences to handle. In this case, there likely aren't 300 versions
> of h/w, the functionality is simple enough, and the functionality is
> entirely optional (just a guess). But that's all really your argument
> to make.
I think I will go with different compatible, but instead of 1 I will
compile a small list of devices, which:
- are most similar to my testing device
- have unique functionality (like having additionally a "cpu fan" or
similar). This way I can implement every functionality in the driver,
which makes it easier to add devices in the future.
- I know are owned by people who like to experiment with their device
(including my device)
Thanks
- Markus Probst
>
> Rob
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: qcom: Add missing power-domains property
From: Krzysztof Kozlowski @ 2026-03-27 13:37 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luca Weiss,
Taniya Das, Konrad Dybcio, Dmitry Baryshkov
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260327-dt-fix-milos-eliza-gcc-power-domains-v1-1-f14a22c73fe9@oss.qualcomm.com>
On 27/03/2026 13:13, Abel Vesa wrote:
> In order for the GCC votes on the GDSCs it provides to be propagated
> to CX, CX needs to be declared as power domain of the GCC.
I assume this is true for Milos, not only Eliza.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 02/15] firmware: qcom: Add a generic PAS service
From: Krzysztof Kozlowski @ 2026-03-27 13:39 UTC (permalink / raw)
To: Sumit Garg, Mukesh Ojha
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <acE3MR4SVCPUzcgR@sumit-xelite>
On 23/03/2026 13:50, Sumit Garg wrote:
>>> +
>>> +#include <linux/device/devres.h>
>>> +#include <linux/firmware/qcom/qcom_pas.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +
>>> +#include "qcom_pas.h"
>>> +
>>> +struct qcom_pas_ops *ops_ptr;
>>
>> Should this be static ?
>
> It was static earlier in v1. I dropped it based on earlier v1 discussion
> with Krzysztof. Let me conclude that discussion on the other thread
> again.
The discussion was whether this should be singleton in the first place,
not making it a global singleton.
Of course it cannot be anything else than static - nothing should poke here.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: soc: qcom: qcom,pmic-glink: Document Eliza compatible
From: Abel Vesa @ 2026-03-27 13:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
Document the compatible for the PMIC GLINK interface found on the
Qualcomm Eliza SoC.
It is fully compatible with the one found on SM8550, so use that as
fallback.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
index ff01d2f3ee5b..411932f6b282 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -39,6 +39,7 @@ properties:
- const: qcom,pmic-glink
- items:
- enum:
+ - qcom,eliza-pmic-glink
- qcom,milos-pmic-glink
- qcom,sm8650-pmic-glink
- qcom,sm8750-pmic-glink
---
base-commit: e77a5a5cfe43b4c25bd44a3818e487033287517f
change-id: 20260327-eliza-bindings-pmic-glink-c2f769b4cbbd
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: clock: qcom: Add missing power-domains property
From: Abel Vesa @ 2026-03-27 13:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Luca Weiss, Taniya Das,
Konrad Dybcio, Dmitry Baryshkov, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <fb5a1d45-822a-4894-bf89-026164491935@kernel.org>
On 26-03-27 14:37:17, Krzysztof Kozlowski wrote:
> On 27/03/2026 13:13, Abel Vesa wrote:
> > In order for the GCC votes on the GDSCs it provides to be propagated
> > to CX, CX needs to be declared as power domain of the GCC.
>
> I assume this is true for Milos, not only Eliza.
My understanding of it is that this is true for all platforms.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks for reviewing!
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: mediatek,mt8173-rt5650-rt5514: convert to DT schema
From: Khushal Chitturi @ 2026-03-27 13:46 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
koro.chen, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Khushal Chitturi
Convert the Mediatek MT8173 with RT5650 and RT5514 sound card
bindings to DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v1 -> v2:
- Used two separate entries for two phandles.
- corrected positioning of additionalProperties.
- Fixed commit message to match subsystem.
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../sound/mediatek,mt8173-rt5650-rt5514.yaml | 41 +++++++++++++++++++
.../bindings/sound/mt8173-rt5650-rt5514.txt | 15 -------
2 files changed, 41 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
new file mode 100644
index 000000000000..ed698c9ff42b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8173-rt5650-rt5514.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8173 with RT5650 and RT5514 audio codecs
+
+maintainers:
+ - Koro Chen <koro.chen@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8173-rt5650-rt5514
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Phandles of rt5650 and rt5514 codecs
+ items:
+ - description: phandle of rt5650 codec
+ - description: phandle of rt5514 codec
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT8173 ASoC platform.
+
+required:
+ - compatible
+ - mediatek,audio-codec
+ - mediatek,platform
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8173-rt5650-rt5514";
+ mediatek,audio-codec = <&rt5650>, <&rt5514>;
+ mediatek,platform = <&afe>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
deleted file mode 100644
index e8b3c80c6fff..000000000000
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-MT8173 with RT5650 RT5514 CODECS
-
-Required properties:
-- compatible : "mediatek,mt8173-rt5650-rt5514"
-- mediatek,audio-codec: the phandles of rt5650 and rt5514 codecs
-- mediatek,platform: the phandle of MT8173 ASoC platform
-
-Example:
-
- sound {
- compatible = "mediatek,mt8173-rt5650-rt5514";
- mediatek,audio-codec = <&rt5650 &rt5514>;
- mediatek,platform = <&afe>;
- };
-
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-03-27 13:55 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-6-cf7d346b8372@oss.qualcomm.com>
On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
> PSCI supports different types of resets like COLD reset, ARCH WARM
> reset, vendor-specific resets. Currently there is no common driver that
> handles all supported psci resets at one place. Additionally, there is
> no common mechanism to issue the supported psci resets from userspace.
>
> Add a PSCI reboot mode driver and define two types of PSCI resets in the
> driver as reboot-modes: predefined resets controlled by Linux
> reboot_mode and customizable resets defined by SoC vendors in their
> device tree under the psci:reboot-mode node.
>
> Register the driver with the reboot-mode framework to interface these
> resets to userspace. When userspace initiates a supported command, pass
> the reset arguments to the PSCI driver to enable command-based reset.
>
> This change allows userspace to issue supported PSCI reset commands
> using the standard reboot system calls while enabling SoC vendors to
> define their specific resets for PSCI.
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
> 3 files changed, 130 insertions(+)
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
> then the bootloader can read it and take different
> action according to the mode.
>
> +config PSCI_REBOOT_MODE
> + bool "PSCI reboot mode driver"
> + depends on OF && ARM_PSCI_FW
> + select REBOOT_MODE
> + help
> + Say y here will enable PSCI reboot mode driver. This gets
> + the PSCI reboot mode arguments and passes them to psci
> + driver. psci driver uses these arguments for issuing
> + device reset into different boot states.
> +
> config POWER_MLXBF
> tristate "Mellanox BlueField power handling driver"
> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
> +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
> diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
> --- /dev/null
> +++ b/drivers/power/reset/psci-reboot-mode.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/device/faux.h>
> +#include <linux/device.h>
Nit: swap the two.
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/reboot-mode.h>
> +#include <linux/types.h>
> +
> +/*
> + * Predefined reboot-modes are defined as per the values
> + * of enum reboot_mode defined in the kernel: reboot.c.
> + */
> +static struct mode_info psci_resets[] = {
> + { .mode = "warm", .magic = REBOOT_WARM},
> + { .mode = "soft", .magic = REBOOT_SOFT},
> + { .mode = "cold", .magic = REBOOT_COLD},
> +};
> +
> +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
> +{
> + INIT_LIST_HEAD(&reboot->predefined_modes);
> + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
> + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
> + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
This looks weird to me, why can't we just initialize the array with the values
directly ?
> + INIT_LIST_HEAD(&psci_resets[i].list);
> + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
> + }
> +}
> +
> +/*
> + * arg1 is reset_type(Low 32 bit of magic).
> + * arg2 is cookie(High 32 bit of magic).
> + * If reset_type is 0, cookie will be used to decide the reset command.
> + */
> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
> +{
> + u32 reset_type = REBOOT_MODE_ARG1(magic);
> + u32 cookie = REBOOT_MODE_ARG2(magic);
> +
> + if (reset_type == 0) {
> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
> + psci_set_reset_cmd(true, 0, 0);
> + else
> + psci_set_reset_cmd(false, 0, 0);
> + } else {
> + psci_set_reset_cmd(true, reset_type, cookie);
> + }
I don't think that psci_set_reset_cmd() has the right interface (and this
nested if is too complicated for my taste). All we need to pass is reset-type
and cookie (and if the reset is one of the predefined ones, reset-type is 0
and cookie is the REBOOT_* cookie).
Then the PSCI firmware driver will take the action according to what
resets are available.
How does it sound ?
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int psci_reboot_mode_register_device(struct faux_device *fdev)
> +{
> + struct reboot_mode_driver *reboot;
> + int ret;
> +
> + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
> + if (!reboot)
> + return -ENOMEM;
> +
> + psci_reboot_mode_set_predefined_modes(reboot);
> + reboot->write = psci_reboot_mode_write;
> + reboot->dev = &fdev->dev;
> +
> + ret = devm_reboot_mode_register(&fdev->dev, reboot);
> + if (ret) {
> + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init psci_reboot_mode_init(void)
> +{
> + struct device_node *psci_np;
> + struct faux_device *fdev;
> + struct device_node *np;
> + int ret;
> +
> + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> + if (!psci_np)
> + return -ENODEV;
> + /*
> + * Look for reboot-mode in the psci node. Even if the reboot-mode
> + * node is not defined in psci, continue to register with the
> + * reboot-mode driver and let the dev.ofnode be set as NULL.
> + */
> + np = of_find_node_by_name(psci_np, "reboot-mode");
> +
> + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
Same comment as Bartosz (have you picked up his work and working towards
a solution) ?
Thanks,
Lorenzo
> + if (!fdev) {
> + ret = -ENODEV;
> + goto error;
> + }
> +
> + device_set_node(&fdev->dev, of_fwnode_handle(np));
> + ret = psci_reboot_mode_register_device(fdev);
> + if (ret)
> + goto error;
> +
> + return 0;
> +
> +error:
> + of_node_put(np);
> + if (fdev) {
> + device_set_node(&fdev->dev, NULL);
> + faux_device_destroy(fdev);
> + }
> +
> + return ret;
> +}
> +device_initcall(psci_reboot_mode_init);
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 02/15] firmware: qcom: Add a generic PAS service
From: Krzysztof Kozlowski @ 2026-03-27 13:56 UTC (permalink / raw)
To: Konrad Dybcio, Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
linux-kernel, Sumit Garg
In-Reply-To: <2e55bdc3-54a1-4f18-b9ad-fe03f21fc4da@oss.qualcomm.com>
On 23/03/2026 15:26, Konrad Dybcio wrote:
>>>
>>> This pattern has been carried from the PAS API contract among kernel
>>> clients and the SCM PAS service earlier. The clients don't hold a
>>> reference to the PAS data like underlying platform or TEE device etc.
>>> Hence the need to have a global data pointer to hold reference to the
>>> ops data structure registered by drivers having different lifetime of
>>> devices. Also, the PAS APIs can be called from very different client
>>> driver contexts.
>>>
>>> Surely, avoiding global data is always better given a better alternative
>>> is there. Do you have any better alternative proposal here?
>>
>> Why it cannot be part of the context?
>>
>> Look at your API, e.g.:
>> qcom_pas_init_image(). It takes struct qcom_pas_context which should
>> contain the ops.
>
> This would make the client have to select the ops. The whole point is to
> avoid that, since the client has no clue (and is supposed not to have any).
Yeah, I see. The problem is that this patchset just keeps growing the
singletons so except existing 'struct qcom_scm *__scm' in qcom_scm.c,
this one brings at least three new: 'ops_ptr', 'qcom_pas_ops_scm' and
'qcom_pas_ops_tee'.
I don't think you need all four in total, but only one which will hold
whatever pointers are necessary.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: mediatek,mt8173-rt5650-rt5514: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-27 13:57 UTC (permalink / raw)
To: Khushal Chitturi, lgirdwood, broonie
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
koro.chen, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260327134649.31376-1-khushalchitturi@gmail.com>
On 27/03/2026 14:46, Khushal Chitturi wrote:
> Convert the Mediatek MT8173 with RT5650 and RT5514 sound card
> bindings to DT schema.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Bartosz Golaszewski @ 2026-03-27 13:59 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Shivendra Pratap, Arnd Bergmann, Bjorn Andersson,
Sebastian Reichel, Rob Herring, Souvik Chakravarty,
Krzysztof Kozlowski, Andy Yan, Matthias Brugger, Mark Rutland,
Conor Dooley, Konrad Dybcio, John Stultz, Moritz Fischer,
Sudeep Holla, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Kathiravan Thirumoorthy, linux-pm, linux-kernel, linux-arm-kernel,
linux-arm-msm, devicetree, Srinivas Kandagatla
In-Reply-To: <acaMPgRALnoUIHMC@lpieralisi>
On Fri, Mar 27, 2026 at 2:55 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> > +
> > +static int __init psci_reboot_mode_init(void)
> > +{
> > + struct device_node *psci_np;
> > + struct faux_device *fdev;
> > + struct device_node *np;
> > + int ret;
> > +
> > + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> > + if (!psci_np)
> > + return -ENODEV;
> > + /*
> > + * Look for reboot-mode in the psci node. Even if the reboot-mode
> > + * node is not defined in psci, continue to register with the
> > + * reboot-mode driver and let the dev.ofnode be set as NULL.
> > + */
> > + np = of_find_node_by_name(psci_np, "reboot-mode");
> > +
> > + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
>
> Same comment as Bartosz (have you picked up his work and working towards
> a solution) ?
>
Hi Lorenzo!
Yes, I suggested creating an MFD driver binding to the "arm,psci-1.0"
compatible node which will have two cells: one for the existing
cpuidle-domain functionality and a second for the new reboot-mode
driver. This way we'll simply add a platform device as Greg suggested.
Bart
^ permalink raw reply
* Warning from free_reserved_area() in next-20260325+
From: Bert Karwatzki @ 2026-03-27 14:01 UTC (permalink / raw)
To: Mike Rapoport
Cc: Bert Karwatzki, linux-kernel, Liam.Howlett, akpm, andreas, ardb,
bp, brauner, catalin.marinas, chleroy, dave.hansen, davem, david,
devicetree, dvyukov, elver, glider, hannes, hpa, ilias.apalodimas,
iommu, jack, jackmanb, kasan-dev, linux-arm-kernel, linux-efi,
linux-fsdevel, linux-mm, linux-trace-kernel, linuxppc-dev,
lorenzo.stoakes, m.szyprowski, maddy, mhiramat, mhocko, mingo,
mpe, npiggin, robh, robin.murphy, saravanak, sparclinux, surenb,
tglx, vbabka, viro, will, x86, ziy
In-Reply-To: <20260323074836.3653702-10-rppt@kernel.org>
Starting with linux next-20260325 I see the following warning early in the
boot process of a machine running debian stable (trixie) (except for the kernel):
[ 0.027118] [ T0] ------------[ cut here ]------------
[ 0.027118] [ T0] Cannot free reserved memory because of deferred initialization of the memory map
[ 0.027119] [ T0] WARNING: mm/memblock.c:904 at __free_reserved_area+0xa9/0xc0, CPU#0: swapper/0/0
[ 0.027122] [ T0] Modules linked in:
[ 0.027123] [ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.0.0-rc5-next-20260326-master #385 PREEMPT_RT
[ 0.027125] [ T0] Hardware name: ASUS System Product Name/ROG STRIX B850-F GAMING WIFI, BIOS 1627 02/05/2026
[ 0.027125] [ T0] RIP: 0010:__free_reserved_area+0xa9/0xc0
[ 0.027126] [ T0] Code: 48 89 df 48 89 ee e8 06 fe ff ff 48 89 c3 48 39 e8 72 a0 5b 4c 89 e8 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d 3d 97 c2 c6 00 <67> 48 0f b9 3a 45 31 ed eb df 66 66 2e 0f 1f 84 00 00 00 00 00 66
[ 0.027127] [ T0] RSP: 0000:ffffffff9b203e98 EFLAGS: 00010202
[ 0.027128] [ T0] RAX: 0000000e91c00001 RBX: ffffffff9b100c0f RCX: 0000000080000001
[ 0.027128] [ T0] RDX: 00000000000000cc RSI: 0000000e2d42d000 RDI: ffffffff9b32ef60
[ 0.027128] [ T0] RBP: ffff9eeafdd6fbc0 R08: 0000000000000000 R09: 0000000000000001
[ 0.027129] [ T0] R10: 0000000000001000 R11: 8000000000000163 R12: 000000000000006f
[ 0.027129] [ T0] R13: 0000000000000000 R14: 0000000000000045 R15: 000000005c8a1000
[ 0.027129] [ T0] FS: 0000000000000000(0000) GS:ffff9eeb21c05000(0000) knlGS:0000000000000000
[ 0.027130] [ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.027130] [ T0] CR2: ffff9ee8ad801000 CR3: 0000000e2ce1e000 CR4: 0000000000f50ef0
[ 0.027131] [ T0] PKRU: 55555554
[ 0.027131] [ T0] Call Trace:
[ 0.027132] [ T0] <TASK>
[ 0.027132] [ T0] free_reserved_area+0x89/0xd0
[ 0.027133] [ T0] alternative_instructions+0xee/0x110
[ 0.027136] [ T0] arch_cpu_finalize_init+0x10f/0x160
[ 0.027138] [ T0] start_kernel+0x686/0x710
[ 0.027140] [ T0] x86_64_start_reservations+0x24/0x30
[ 0.027141] [ T0] x86_64_start_kernel+0xd4/0xe0
[ 0.027142] [ T0] common_startup_64+0x13e/0x141
[ 0.027143] [ T0] </TASK>
[ 0.027144] [ T0] ---[ end trace 0000000000000000 ]---
The Hardware used is this:
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 26
model : 68
model name : AMD Ryzen 9 9950X 16-Core Processor
stepping : 0
microcode : 0xb404035
cpu MHz : 3607.683
cache size : 1024 KB
physical id : 0
siblings : 32
core id : 0
cpu cores : 16
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect movdiri movdir64b overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d amd_lbr_pmc_freeze
bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass srso spectre_v2_user vmscape
bogomips : 8599.98
TLB size : 192 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]
$ lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Root Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge GPP Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge GPP Bridge
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge GPP Bridge
00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Internal GPP Bridge to Bus [C:A]
00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Internal GPP Bridge to Bus [C:A]
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 71)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 7
01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev 25)
02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch (rev 25)
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 44 [RX 9060 XT] (rev c0)
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 48 HDMI/DP Audio Controller
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1]
05:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Upstream Port (rev 01)
06:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:0c.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:0d.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
08:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 06)
09:00.0 Network controller: MEDIATEK Corp. Device 7925
0b:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 800 Series Chipset USB 3.x XHCI Controller (rev 01)
0c:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller (rev 01)
0d:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge PCIe Dummy Function (rev c1)
0d:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 19h PSP/CCP
0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge USB 3.1 xHCI
0d:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge USB 3.1 xHCI
0e:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge USB 2.0 xHCI
Memory used is 64G:
$ LANG=C free
total used free shared buff/cache available
Mem: 65500068 3584080 56709424 70916 5912256 61915988
Swap: 78125052 0 78125052
Bert Karwatzki
^ permalink raw reply
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Thierry Reding @ 2026-03-27 14:06 UTC (permalink / raw)
To: Diogo Ivo
Cc: Thierry Reding, Mathias Nyman, Greg Kroah-Hartman,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <00aeda7a-e5e5-4779-b212-6e56c2c5ec31@tecnico.ulisboa.pt>
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
On Thu, Mar 26, 2026 at 02:17:33PM +0000, Diogo Ivo wrote:
> Hello,
>
> On 3/24/26 11:48, Thierry Reding wrote:
> > On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
> > > As the PHY subsystem already synchronizes concurrent accesses to a PHY
> > > instance with a core-internal mutex remove the driver specific mutex
> > > synchronization.
> > >
> > > Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> > > ---
> > > v1->v2:
> > > - New patch
> > > ---
> > > drivers/usb/host/xhci-tegra.c | 4 ----
> > > 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> > > index 8b492871d21d..927861ca14f2 100644
> > > --- a/drivers/usb/host/xhci-tegra.c
> > > +++ b/drivers/usb/host/xhci-tegra.c
> > > @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
> > > dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
> > > - mutex_lock(&tegra->lock);
> > > -
> > > if (tegra->host_mode)
> > > phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
> > > else
> > > phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
> > > - mutex_unlock(&tegra->lock);
> > > -
> >
> > It looks to me like the mutex here is trying to protect against
> > tegra->host_mode changing while we're setting a different mode. That
> > doesn't seem to be taken care of by the PHY internal mutex.
>
> After taking another look at it I think I understand your point for the
> mutex, but in that case wouldn't it also need to be held in the writer
> of host_mode, tegra_xhci_id_notify()?
Yes, I think it probably would need to. I don't know how likely it is,
but I think the purpose of this is to protect against the ID notifier
firing quickly in succession. Although, given that this runs on a work
queue and work queue instances are non-reentrant to my knowledge, I
don't think we need the mutex here after all.
> This patch has been picked up as-is into usb-next so it would be nice to
> figure this out before it gets merged in the next merge window.
Given the above, I think it's fine. Maybe the commit message doesn't
give a correct reason for why we don't need the mutex, but the resulting
code looks like it should be fine regardless.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v20 04/10] firmware: psci: Introduce command-based reset in psci_sys_reset
From: Lorenzo Pieralisi @ 2026-03-27 14:07 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-4-cf7d346b8372@oss.qualcomm.com>
On Wed, Mar 04, 2026 at 11:33:04PM +0530, Shivendra Pratap wrote:
> PSCI currently supports only COLD reset and ARCH WARM reset based on the
> Linux reboot_mode variable. The PSCI specification now includes
> SYSTEM_RESET2 for vendor-specific resets, but there's no mechanism to
> issue these through psci_sys_reset.
>
> Add a command-based reset mechanism that allows external drivers to set
> the psci reset command via a new psci_set_reset_cmd() function.
>
> The psci command-based reset is disabled by default and the
> psci_sys_reset follows its original flow until a psci_reset command is
> set. In kernel panic path, psci_reset command is ignored.
If it is function calls you should add parenthesis (eg psci_sys_reset ->
psci_sys_reset()).
You must explain why the kernel panic path requires separate handling
here AND in the code - think about looking at this years down the line
and figure out why kernel panics are special here.
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/firmware/psci/psci.c | 45 ++++++++++++++++++++++++++++++++++++++++++--
> include/linux/psci.h | 2 ++
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 38ca190d4a22d6e7e0f06420e8478a2b0ec2fe6f..ae6f7a0aead913d740070080d4b2a3da15b29485 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -51,6 +51,15 @@ static int resident_cpu = -1;
> struct psci_operations psci_ops;
> static enum arm_smccc_conduit psci_conduit = SMCCC_CONDUIT_NONE;
>
> +struct psci_sys_reset_params {
> + u32 system_reset;
> + u32 reset_type;
> + u32 cookie;
> + bool cmd;
> +};
> +
> +static struct psci_sys_reset_params psci_reset;
> +
> bool psci_tos_resident_on(int cpu)
> {
> return cpu == resident_cpu;
> @@ -80,6 +89,28 @@ static u32 psci_cpu_suspend_feature;
> static bool psci_system_reset2_supported;
> static bool psci_system_off2_hibernate_supported;
>
> +/**
> + * psci_set_reset_cmd - Sets the psci_reset_cmd for command-based
> + * reset which will be used in psci_sys_reset call.
> + *
> + * @cmd_sys_rst2: Set to true for SYSTEM_RESET2 based resets.
> + * @cmd_reset_type: Set the reset_type argument for psci_sys_reset.
> + * @cmd_cookie: Set the cookie argument for psci_sys_reset.
> + */
> +void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie)
> +{
I don't think cmd_sys_rst2 is needed, as a replied in a different thread.
> + if (cmd_sys_rst2 && psci_system_reset2_supported) {
> + psci_reset.system_reset = PSCI_FN_NATIVE(1_1, SYSTEM_RESET2);
> + psci_reset.reset_type = cmd_reset_type;
> + psci_reset.cookie = cmd_cookie;
> + } else {
> + psci_reset.system_reset = PSCI_0_2_FN_SYSTEM_RESET;
> + psci_reset.reset_type = 0;
> + psci_reset.cookie = 0;
> + }
> + psci_reset.cmd = true;
> +}
> +
> static inline bool psci_has_ext_power_state(void)
> {
> return psci_cpu_suspend_feature &
> @@ -309,14 +340,24 @@ static int get_set_conduit_method(const struct device_node *np)
> static int psci_sys_reset(struct notifier_block *nb, unsigned long action,
> void *data)
> {
> - if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> - psci_system_reset2_supported) {
> + if (((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> + psci_system_reset2_supported) && (panic_in_progress() || !psci_reset.cmd)) {
> /*
> * reset_type[31] = 0 (architectural)
> * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
> * cookie = 0 (ignored by the implementation)
> */
> invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
> + } else if (!panic_in_progress() && psci_reset.cmd) {
> + /*
> + * Commands are being set in psci_set_reset_cmd
> + * This issues, SYSTEM_RESET2 arch warm reset or
> + * SYSTEM_RESET2 vendor-specific reset or
> + * a SYSTEM_RESET cold reset in accordance with
> + * the reboot-mode command.
> + */
> + invoke_psci_fn(psci_reset.system_reset, psci_reset.reset_type,
> + psci_reset.cookie, 0);
> } else {
> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
This is very hard to parse. IMO, what you should do is:
- Split this into two different paths: reboot_mode vs psci_reset.cmd == true.
- Document very clearly why a panic needs separate handling.
Something like:
if (psci_reset.cmd)
handle_reset_cmd();
else
handle_reboot_mode();
I don't think we are far from converging but I want to be able to maintain
this code going forward.
Thanks,
Lorenzo
> }
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 4ca0060a3fc42ba1ca751c7862fb4ad8dda35a4c..d13ceca88eab8932894051e7c86e806c2ad8a73a 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -45,8 +45,10 @@ struct psci_0_1_function_ids get_psci_0_1_function_ids(void);
>
> #if defined(CONFIG_ARM_PSCI_FW)
> int __init psci_dt_init(void);
> +void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie);
> #else
> static inline int psci_dt_init(void) { return 0; }
> +static inline void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie) { }
> #endif
>
> #if defined(CONFIG_ARM_PSCI_FW) && defined(CONFIG_ACPI)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-03-27 14:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Shivendra Pratap, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Kathiravan Thirumoorthy, linux-pm, linux-kernel, linux-arm-kernel,
linux-arm-msm, devicetree, Srinivas Kandagatla, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <CAMRc=McUdboG0ziWmUf+h9mUiuGesaFk2v27z_Opbw-AF33C0g@mail.gmail.com>
On Fri, Mar 06, 2026 at 02:32:46PM +0100, Bartosz Golaszewski wrote:
> On Thu, Mar 5, 2026 at 6:07 PM Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> wrote:
> >
> > >
> > > You should pass the address of this function in faux_device_ops instead of
> > > calling it directly.
> >
> > In last patch, we were using a probe function. As faux_device_create,
> > calls the probe from its internal operations, "of_node" can only be
> > assigned from inside of faux device probe.
> >
> > As our primary requirement is to assign reboot-mode of_node to the faux
> > device, thought to make it this way. (As we did not want to assign it
> > inside the faux device probe).
> >
>
> TBH This sounds like a limitation of the faux device API. I'll Cc you
> on a patch proposing to extend it with the ability of using a firmware
> node to describe the device. If it works for you, you can integrate it
> into your series and use it.
What's the status on this matter ?
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Bartosz Golaszewski @ 2026-03-27 14:09 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Shivendra Pratap, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Kathiravan Thirumoorthy, linux-pm, linux-kernel, linux-arm-kernel,
linux-arm-msm, devicetree, Srinivas Kandagatla, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <acaPSW6VeYceoMnO@lpieralisi>
On Fri, Mar 27, 2026 at 3:08 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> On Fri, Mar 06, 2026 at 02:32:46PM +0100, Bartosz Golaszewski wrote:
> > On Thu, Mar 5, 2026 at 6:07 PM Shivendra Pratap
> > <shivendra.pratap@oss.qualcomm.com> wrote:
> > >
> > > >
> > > > You should pass the address of this function in faux_device_ops instead of
> > > > calling it directly.
> > >
> > > In last patch, we were using a probe function. As faux_device_create,
> > > calls the probe from its internal operations, "of_node" can only be
> > > assigned from inside of faux device probe.
> > >
> > > As our primary requirement is to assign reboot-mode of_node to the faux
> > > device, thought to make it this way. (As we did not want to assign it
> > > inside the faux device probe).
> > >
> >
> > TBH This sounds like a limitation of the faux device API. I'll Cc you
> > on a patch proposing to extend it with the ability of using a firmware
> > node to describe the device. If it works for you, you can integrate it
> > into your series and use it.
>
> What's the status on this matter ?
>
I looked around and didn't find any good reason for adding this after
all so I dropped it.
Bart
^ permalink raw reply
* [PATCH] dt-bindings: phy: qcom,snps-eusb2: Document the Eliza Synopsys eUSB2 PHY
From: Abel Vesa @ 2026-03-27 14:14 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Abel Vesa
The Synopsys eUSB2 PHY found on the Eliza SoC is fully compatible with the
one found the SM8550.
So document it by adding the compatible to the list that has the SM8550
one as fallback.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
index 854f70af0a6c..096f6b546632 100644
--- a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
@@ -17,6 +17,7 @@ properties:
oneOf:
- items:
- enum:
+ - qcom,eliza-snps-eusb2-phy
- qcom,milos-snps-eusb2-phy
- qcom,sar2130p-snps-eusb2-phy
- qcom,sdx75-snps-eusb2-phy
---
base-commit: e77a5a5cfe43b4c25bd44a3818e487033287517f
change-id: 20260327-eliza-bindings-phy-eusb2-bc4dd201444c
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-03-27 14:14 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Arnd Bergmann, Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla,
Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-6-cf7d346b8372@oss.qualcomm.com>
On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
> PSCI supports different types of resets like COLD reset, ARCH WARM
> reset, vendor-specific resets. Currently there is no common driver that
> handles all supported psci resets at one place. Additionally, there is
> no common mechanism to issue the supported psci resets from userspace.
>
> Add a PSCI reboot mode driver and define two types of PSCI resets in the
> driver as reboot-modes: predefined resets controlled by Linux
> reboot_mode and customizable resets defined by SoC vendors in their
> device tree under the psci:reboot-mode node.
>
> Register the driver with the reboot-mode framework to interface these
> resets to userspace. When userspace initiates a supported command, pass
> the reset arguments to the PSCI driver to enable command-based reset.
>
> This change allows userspace to issue supported PSCI reset commands
> using the standard reboot system calls while enabling SoC vendors to
> define their specific resets for PSCI.
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
Add an entry into MAINTAINERS.POWER STATE COORDINATION INTERFACE for this
specific file because I'd like to keep an eye on it, if you don't mind.
Creating a MAINTAINER entry just for this seems overkill to me, it
does not look like it is done for other reboot mode drivers.
Thanks,
Lorenzo
> 3 files changed, 130 insertions(+)
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
> then the bootloader can read it and take different
> action according to the mode.
>
> +config PSCI_REBOOT_MODE
> + bool "PSCI reboot mode driver"
> + depends on OF && ARM_PSCI_FW
> + select REBOOT_MODE
> + help
> + Say y here will enable PSCI reboot mode driver. This gets
> + the PSCI reboot mode arguments and passes them to psci
> + driver. psci driver uses these arguments for issuing
> + device reset into different boot states.
> +
> config POWER_MLXBF
> tristate "Mellanox BlueField power handling driver"
> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
> +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
> diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
> --- /dev/null
> +++ b/drivers/power/reset/psci-reboot-mode.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/device/faux.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/reboot-mode.h>
> +#include <linux/types.h>
> +
> +/*
> + * Predefined reboot-modes are defined as per the values
> + * of enum reboot_mode defined in the kernel: reboot.c.
> + */
> +static struct mode_info psci_resets[] = {
> + { .mode = "warm", .magic = REBOOT_WARM},
> + { .mode = "soft", .magic = REBOOT_SOFT},
> + { .mode = "cold", .magic = REBOOT_COLD},
> +};
> +
> +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
> +{
> + INIT_LIST_HEAD(&reboot->predefined_modes);
> + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
> + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
> + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
> + INIT_LIST_HEAD(&psci_resets[i].list);
> + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
> + }
> +}
> +
> +/*
> + * arg1 is reset_type(Low 32 bit of magic).
> + * arg2 is cookie(High 32 bit of magic).
> + * If reset_type is 0, cookie will be used to decide the reset command.
> + */
> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
> +{
> + u32 reset_type = REBOOT_MODE_ARG1(magic);
> + u32 cookie = REBOOT_MODE_ARG2(magic);
> +
> + if (reset_type == 0) {
> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
> + psci_set_reset_cmd(true, 0, 0);
> + else
> + psci_set_reset_cmd(false, 0, 0);
> + } else {
> + psci_set_reset_cmd(true, reset_type, cookie);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int psci_reboot_mode_register_device(struct faux_device *fdev)
> +{
> + struct reboot_mode_driver *reboot;
> + int ret;
> +
> + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
> + if (!reboot)
> + return -ENOMEM;
> +
> + psci_reboot_mode_set_predefined_modes(reboot);
> + reboot->write = psci_reboot_mode_write;
> + reboot->dev = &fdev->dev;
> +
> + ret = devm_reboot_mode_register(&fdev->dev, reboot);
> + if (ret) {
> + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init psci_reboot_mode_init(void)
> +{
> + struct device_node *psci_np;
> + struct faux_device *fdev;
> + struct device_node *np;
> + int ret;
> +
> + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> + if (!psci_np)
> + return -ENODEV;
> + /*
> + * Look for reboot-mode in the psci node. Even if the reboot-mode
> + * node is not defined in psci, continue to register with the
> + * reboot-mode driver and let the dev.ofnode be set as NULL.
> + */
> + np = of_find_node_by_name(psci_np, "reboot-mode");
> +
> + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
> + if (!fdev) {
> + ret = -ENODEV;
> + goto error;
> + }
> +
> + device_set_node(&fdev->dev, of_fwnode_handle(np));
> + ret = psci_reboot_mode_register_device(fdev);
> + if (ret)
> + goto error;
> +
> + return 0;
> +
> +error:
> + of_node_put(np);
> + if (fdev) {
> + device_set_node(&fdev->dev, NULL);
> + faux_device_destroy(fdev);
> + }
> +
> + return ret;
> +}
> +device_initcall(psci_reboot_mode_init);
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: i2c: apple,i2c: Add t8122 compatible
From: Andi Shyti @ 2026-03-27 14:15 UTC (permalink / raw)
To: Janne Grunau
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Guenter Roeck,
Linus Walleij, Mark Kettenis, Uwe Kleine-König,
Sasha Finkelstein, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-watchdog, linux-gpio, linux-i2c,
linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-6-5842e1e393a8@jannau.net>
Hi Janne,
On Fri, Mar 20, 2026 at 01:23:24PM +0100, Janne Grunau wrote:
> The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
> "apple,t8103-i2c" used by the deriver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Bjorn Helgaas @ 2026-03-27 14:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Manivannan Sadhasivam, Tobias Heider, Ziyue Zhang, konradybcio,
robh, krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski,
bhelgaas, johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa,
kw, linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <CAARv3RRqXxNePX=4RqnLu7OnfjQmStynsL9RCNY19EKQOTcnLQ@mail.gmail.com>
[->to: Bjorn A.]
On Tue, Mar 24, 2026 at 08:14:39PM +0100, Tobias Heider wrote:
> On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > > >
> > > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > > to the port nodes.
> > > > > > > > > >
> > > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > > > - x1-hp-omnibook-x14
> > > > > > > > > > - x1-microsoft-denali
> > > > > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > > > > - x1-asus-zenbook-a14
> > > > > > > > > > - x1-crd
> > > > > > > > > > - x1-dell-thena
> > > > > > > > > >
> > > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > > >
> > > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > > combinations, so it fails correctly so.
> > > > > > > >
> > > > > > >
> > > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > > v7.0-rc?
> > > > > > >
> > > > > >
> > > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > > >
> > > > >
> > > > > In line with Bjorn's request, we shouldn't have to guess.
> > > > >
> > > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > > applied?
> > > > > > >
> > > > > >
> > > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > > fix on top of v7.0-rc1.
> > > > > >
> > > > >
> > > > > So 960609b22be5 was broken when I merged it?
> > > > >
> > > >
> > > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > > platforms.
> > > >
> > > > > The commit message says that the commit was incomplete, in that it
> > > > > didn't fully convert from the old to the new style, so it sounds like
> > > > > the offending commit was incomplete - but I believe the offending commit
> > > > > was a workaround for the new solution not being in place and this commit
> > > > > mostly reverts the changes in the offending commit.
> > > > >
> > > >
> > > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > > new for greater good, but it apparently decided to do so only for a subset of
> > > > the platforms for some reason which don't know. But the problem arises due to
> > > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > > or dts converted and not both to the new binding, the driver will get confused
> > > > and fail. And this is what exactly happended for below machines:
> > > >
> > > > - x1-hp-omnibook-x14
> > > > - x1-microsoft-denali
> > > > - x1e80100-lenovo-yoga-slim7x
> > > > - x1e80100-medion-sprchrgd-14-s1
> > > > - x1p42100-lenovo-thinkbook-16
> > > > - x1-asus-zenbook-a14
> > > > - x1-crd
> > > > - x1-dell-thena
> > >
> > > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> > >
> > > I'll try to collect some test feedback for the fix.
> > > I'd certainly appreciate this being included as an rc fix since
> > > currently half of
> > > the x1 laptop devices are broken.
> > >
> >
> > Thanks for the report. We will try to get this patch into v7.0-rcS.
> >
> > It'd be appreciated if you can test this patch and give your tested-by tag.
> >
> > - Mani
>
> Thank you!
>
> Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
> I have tested the CRD and got user feedback that it works on at least an
> Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
> Potentially more but not everyone provides feedback when things don't break.
>
> Tested-by: Tobias Heider <tobias.heider@canonical.com>
I don't see this patch upstream yet. It's a fix for 960609b22be5
("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe
port nodes and add port Nodes for all PCIe ports"), which looks like
it was merged by Bjorn A., so I assume the fix will go the same route?
Just want to make sure it's not waiting on me :)
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C support
From: Rustam Adilov @ 2026-03-27 14:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260327-berserk-roaring-quetzal-24dd7e@quoll>
On 2026-03-27 08:28, Krzysztof Kozlowski wrote:
> On Fri, Mar 27, 2026 at 12:34:16AM +0500, Rustam Adilov wrote:
>> description: |
>> - Realtek USB 2.0 PHY support the digital home center (DHC) RTD series SoCs.
>> + Realtek USB 2.0 PHY support the digital home center (DHC) RTD and
>> + RTL9607C series SoCs.
>> The USB 2.0 PHY driver is designed to support the XHCI controller. The SoCs
>> support multiple XHCI controllers. One PHY device node maps to one XHCI
>> controller.
>> + This driver also supports the OCHI and EHCI controllers.
>
> Hardware is fixed, does not change. Don't reference your driver changes
> here.
Will remove this line.
>>
>> RTD1295/RTD1619 SoCs USB
>> The USB architecture includes three XHCI controllers.
>> @@ -57,6 +59,12 @@ description: |
>> XHCI controller#1 -- usb2phy -- phy#0
>> XHCI controller#2 -- usb2phy -- phy#0
>>
>> + RTL9607C SoCs USB
>> + The USB architecture includes OHCI and EHCI controllers.
>> + Both of them map to one USB2.0 PHY.
>> + OHCI controller#0 -- usb2phy -- phy#0
>> + EHCI controller#0 -- usb2phy -- phy#0
>> +
>> properties:
>> compatible:
>> enum:
>> @@ -69,6 +77,7 @@ properties:
>> - realtek,rtd1395-usb2phy-2port
>> - realtek,rtd1619-usb2phy
>> - realtek,rtd1619b-usb2phy
>> + - realtek,rtl9607-usb2phy
>>
>> reg:
>> items:
>> @@ -130,6 +139,9 @@ properties:
>> minimum: -8
>> maximum: 8
>>
>> + resets:
>> + maxItems: 1
>> +
>> required:
>> - compatible
>> - reg
>> @@ -157,6 +169,15 @@ allOf:
>> then:
>> properties:
>> realtek,driving-level-compensate: false
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - realtek,rtl9607-usb2phy
>> + then:
>> + required:
>> + - resets
>
> If it is unclear, they might not have it so,
>
> else: ... :false
Right, i suppose if RTD SoCs had them they would have been added here already so..
will make the resets false for other devices
> see example-schema.
>
> Best regards,
> Krzysztof
Thanks,
Rustam
^ permalink raw reply
* Re: [PATCH v2 0/2] soc/tegra: cbb: Add Tegra238 support
From: Thierry Reding @ 2026-03-27 14:27 UTC (permalink / raw)
To: Sumit Gupta
Cc: treding, jonathanh, robh, krzk+dt, conor+dt, devicetree,
linux-tegra, linux-kernel, bbasu
In-Reply-To: <20260325125726.2694144-1-sumitg@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Wed, Mar 25, 2026 at 06:27:24PM +0530, Sumit Gupta wrote:
> Add support for Control Backbone (CBB) 2.0 based fabrics in Tegra238 SoC.
>
> The series includes:
> - DT binding updates for Tegra238 CBB compatible strings
> - Driver support for Tegra238 AON, APE, BPMP, and CBB fabrics
>
> v1[1] -> v2:
> - Add DT maintainers for review. Forgot to add earlier.
>
> Sumit Gupta (2):
> dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
> soc/tegra: cbb: Add support for CBB fabrics in Tegra238
>
> .../arm/tegra/nvidia,tegra234-cbb.yaml | 4 +
> drivers/soc/tegra/cbb/tegra234-cbb.c | 134 ++++++++++++++++++
> 2 files changed, 138 insertions(+)
>
> [1] https://lore.kernel.org/lkml/20260303155927.1885297-1-sumitg@nvidia.com/
Applied after adjusting the commit message as suggested by Krzysztof.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/12] arm64: dts: imx8mp: Correct PAD settings for PMIC_nINT
From: Frank Li @ 2026-03-27 14:32 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Laurent Pinchart,
Shawn Guo, Daniel Scally, Marco Felsch, Gilles Talis,
Viorel Suman, Shengjiu Wang, Jagan Teki, Manoj Sai, Matteo Lisi,
Ray Chang, Richard Hu, Heiko Schocher, Martyn Welch, Josua Mayer,
Goran Rađenović, Börge Strümpfel,
Christoph Niedermaier, Marek Vasut, devicetree, imx,
linux-arm-kernel, linux-kernel, kernel, Peng Fan, Kieran Bingham
In-Reply-To: <20260326-imx8mp-dts-fix-v2-v2-0-62c4ce727448@nxp.com>
On Thu, Mar 26, 2026 at 03:28:04PM +0800, Peng Fan (OSS) wrote:
> As reported in [1], there is interrupt storm for i.MX8MP DEBIX Model A.
> Per schematic, there is no on board PULL-UP resistors for GPIO1_IO03,
> so need to set PAD PUE and PU together to make pull up work properly.
>
> DEBIX Model SOM also has same issue as reported in [2].
>
> I gave a check on current i.MX8MP based boards, most boards have wrong
> PAD settings with PMIC_nINT. It is low level triggered interrupt.
> many boards only set PU, but PUE not set, so pull up not work properly.
>
> Patch 1 and 2 are to fix issue that confirmed by Laurent and Kieran.
>
> I checked AB2 and NAVQ schematic, so these two boards are also having
> same issue.
>
> For other boards, I not able to find any public schematics. For per
> the DT settings(interrupt is configured LOW LEVEL trigger), so PMIC_nINT
> should be configured as PULL UP, per NXP reference design, there is no
> on-board resistors for PMIC_nINT, it counts on SoC internal PULL. So I think
> these boards are also having issues. But I use phase "there might be" in
> commit log.
>
> The last two patches, I think the PAD settings are wrong, but not sure
> they have interrupt storm issues, so just correct the settings.
>
> For imx8mp-skov-reva.dtsi, I am not sure whether it needs same fix, so
> not touch it.
>
> [1] https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/
> [2] https://lore.kernel.org/all/20260324194353.GB2352505@killaraus.ideasonboard.com/
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Changes in V2:
> - Fix more boards
> - Drop preceding zero
> - Link to v1: https://lore.kernel.org/all/20260324-imx8mp-dts-fix-v1-1-df0eb2f62543@nxp.com/
>
> ---
> Peng Fan (12):
> arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-ab2: Correct PAD settings for PMIC_nINT
This one squash to 7adad1a52c420 ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
because it is still in my tree.
> arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT
> arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINT
Other apply to 7.0 fixes branch. Thanks
Frank
>
> arch/arm64/boot/dts/freescale/imx8mp-ab2.dts | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-aristainetos3a-som-v1.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-debix-som-a-bmb-08.dts | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-debix-som-a.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-edm-g.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-icore-mx8mp.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-navqp.dts | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-nitrogen-som.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-sr-som.dtsi | 4 ++--
> arch/arm64/boot/dts/freescale/imx8mp-ultra-mach-sbc.dts | 4 ++--
> 13 files changed, 15 insertions(+), 15 deletions(-)
> ---
> base-commit: 66ba480978ce390e631e870b740a3406e3eb6b01
> change-id: 20260326-imx8mp-dts-fix-v2-89ede7320c6a
>
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v5 6/6] ARM: tegra: Add SOCTHERM support on Tegra114
From: Thierry Reding @ 2026-03-27 14:38 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, linux-pm,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <20250828055104.8073-7-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Thu, Aug 28, 2025 at 08:51:04AM +0300, Svyatoslav Ryhel wrote:
> Add SOCTHERM and thermal zones nodes into common Tegra 4 device tree.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> arch/arm/boot/dts/nvidia/tegra114.dtsi | 197 +++++++++++++++++++++++++
> 1 file changed, 197 insertions(+)
Applied, finally.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-27 14:38 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <7712fbdd-a225-49f0-aeb9-ebcbb9d5abac@oss.qualcomm.com>
On 27/03/2026 10:07, Konrad Dybcio wrote:
> On 3/26/26 2:04 AM, Bryan O'Donoghue wrote:
>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>> PHY devices.
>>
>> The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
>> capture those modes as:
>>
>> - PHY_QCOM_CSI2_MODE_DPHY
>> - PHY_QCOM_CSI2_MODE_CPHY
>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
> Does the_PHY_ DT node need to be aware about this upfront?
Yeah that's a fair question.
The standard model is to pass the mode via binding right now. You
_could_ configure it @ run time in principle.
And you could even conceive of a sensor hardware that might find value
in that - but IMO it's a 100% hypothetical use-case - you'd basically
need an FPGA that could output CPHY, DPHY or for some reason SPLIT_MODE
DPHY.
But that's a pretty off the wall use-case to hypothesize. Split-mode
OTOH is a board-level physical reality which => a DT description not a
runtime choice.
> If we have some sideband signal (e.g. the sensor driver specifically
> requesting C-PHY mode), we can simply throw all this complexity into
> phy_mode + phy_configure_opts, all at runtime
Like I say its conceivable but IMO not a real thing and unless your
sensor is an FPGA not possible to support in real hardware.
> Further, the combo/split mode may possibly be selected through
> aggregation of requests.
>
> The question remains whether the sensor should have a direct connection to
> the PHY itself (i.e. phys = <&csiphyN> or of_graph straight into the PHY)
> or whether it's going to be translated by the camss node (which would be
> the one holding a PHY reference) - there's probably surface for adding such
> negotiation logic in both places
To be frankly honest you can make an argument for it either way. However
my honestly held position is analysing other upstream implementations
connecting to the PHY means we can't make the PHY device a drivers/phy
device - it would have to be a V4L2 device and then for me the question
is why is that even required ?
The model we have right now, right or wrong is sensor endpoint to
controller. Similarly the <&phy MODE_GOES_HERE> is a pattern Rob Herring
suggested and IMO is a consistent pattern we should aim for upstream. We
see it in latest Rockchip, Cadence.
> Note this is a question and I'm not aware of all the possible combinations
>
> Konrad
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-03-27 14:46 UTC (permalink / raw)
To: Liu Ying, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <544112ab-8ca0-4622-b680-233457198e3e@nxp.com>
Hello Liu,
On Thu Mar 26, 2026 at 9:15 AM CET, Liu Ying wrote:
> Hi Luca,
>
> On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
>> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
>> can operate in two different modes, depending on the platform data as set
>> by the driver:
>>
>> A. hdmi->plat_data->output_port = 0:
>> the HDMI output (port@1) in device tree is not used [0]
>>
>> B. hdmi->plat_data->output_port = 1:
>> the HDMI output (port@1) is parsed to find the next bridge
>>
>> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
>> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
>> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>>
>> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
>> in that case it adds the connector programmatically at bridge attach time.
>>
>> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
>> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
>> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>>
>> However this change requires that port@1 is connected to a "next
>> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
>> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>>
>> Many dts files for imx8mp-based boards in the kernel have such a connector
>> described and linked to port@1, so a connector is added by the
>> display-connector driver along with a bridge wrapping it. Sadly some of
>
> Hmm, display-connector driver is a bridge driver so it cannot add a connector.
> I assume that you mean a connector will be added by the bridge connector
> driver.
Indeed, rewording as:
Many dts files for imx8mp-based boards in the kernel have such a
connector described and linked to port@1, so the pipeline will be fully
attached up to a display-connector and a drm_connector added by the
bridge-connector.
>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>> Choose this to enable support for the internal HDMI encoder found
>> on the i.MX8MP SoC.
>>
>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>> + bool "Support device tree blobs without an hdmi-connector node"
>> + default y
>
> depends on DRM_IMX_LCDIF ?
If the imx hdmi-tx is not enabled then HDMI won't work anyway, so users are
not affected and the overlay is not needed. Am I missing something?
>> + err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
>> + if (err)
>> + return err;
>> +
>> + hdmi_conn = of_find_node_by_name(NULL, "fixup-hdmi-connector");
>
> Do you really need to find the node, since the overlay was just applied?
That was to ensure the node is present and error out if it isn't. But
thinking again about it after your question I don't see how it could be
missing if the overlay was successfully applied.
Removing this check in v2, which makes this function a lot simpler!
>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> new file mode 100644
>> index 000000000000..ee718ca1b11b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> @@ -0,0 +1,38 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
>> + *
>> + * Copyright (C) 2026 GE HealthCare
>> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> + */
>> +
>> +/dts-v1/;
>> +/plugin/;
>> +
>> +&{/} {
>
> I see build warnings(W=1):
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
AFAIK the device tree checkes just can't work on overlays. The tools just
cannot know on which base tree the overlay can be applied, so they cannot
know the existing properties. That might change in the future, but for now
my understanding is that it is OK to have overlays which produce such
harmless warnings, at least for driver-specific overlays like the tilcdc
one [0] which is already in linux-next since a few weeks.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ff223d991477fa4677dcb0f1fb00065847e2212
> Here is a patch to suppress them:
>
> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> @@ -10,6 +10,9 @@
> /plugin/;
>
> &{/} {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> fixup-hdmi-connector {
> compatible = "hdmi-connector";
> label = "HDMI";
> @@ -23,10 +26,25 @@ fixup_hdmi_connector_in: endpoint {
> };
>
> soc@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x3e000000>;
> +
> bus@32c00000 {
> + reg = <0x32c00000 0x400000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> hdmi@32fd8000 {
> + reg = <0x32fd8000 0x7eff>;
> +
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> hdmi_tx_out: endpoint {
> remote-endpoint = <&fixup_hdmi_connector_in>;
> };
Thanks for taking time to look into how to get rid of the warnings.
However the sheer amount of lines added, by just duplicating lines already
in the base tree and no added value, reinforces my opinion that we should
keep the overlay as simple as it is.
Also, what if one of the property values that your diff is duplicating from
the base tree turns out being wrong in the base tree and gets fixed later
there? The wrong value would be re-added by the overlay unless someone goes
hunting all the duplicated lines around.
Based on this, do you think we really need to get rid of those warnings?
Side note: this discussion made me think about what would happen if
DRM_IMX8MP_DW_HDMI_BRIDGE is enabled on a non-imx8mp board (as for
distribution kernels as mentioned by Laurent). I think it makes sense to
add a check that /soc@0/compatible matches "fsl,imx8mp-soc" and not apply
the overlay otherwise. I'll look into that for v2.
>> + fixup-hdmi-connector {
>> + compatible = "hdmi-connector";
>> + label = "HDMI";
>> + type = "a";
>
> What if a board uses another type?
For boards affected by this patch, currently the connector is created by
dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
difference.
OTOH how can a common module know the specific connector?
Boards with a different connector should describe the connector in the
device tree, if they need to instantiate the exact type.
[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox