* [PATCH v4 5/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable touchscreen
From: Cristian Cozzolino via B4 Relay @ 2026-03-27 14:30 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, Cristian Cozzolino,
Konrad Dybcio
In-Reply-To: <20260327-rimob-new-features-v4-0-06edff9c4509@protonmail.com>
From: Cristian Cozzolino <cristian_ci@protonmail.com>
This device uses a Goodix GT5688 touch controller, connected to i2c_3.
Add it to the device tree.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
.../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
index 8620143e04a0..a1280b0e7e90 100644
--- a/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
+++ b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
@@ -94,6 +94,31 @@ &hsusb_phy {
status = "okay";
};
+&i2c_3 {
+ status = "okay";
+
+ touchscreen@5d {
+ compatible = "goodix,gt5688";
+ reg = <0x5d>;
+
+ interrupts-extended = <&tlmm 65 IRQ_TYPE_LEVEL_LOW>;
+
+ pinctrl-0 = <&tsp_int_rst_default>;
+ pinctrl-names = "default";
+
+ irq-gpios = <&tlmm 65 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
+
+ VDDIO-supply = <&pm8953_l6>;
+ AVDD28-supply = <&pm8953_l10>;
+
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <1920>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ };
+};
+
&ibb {
qcom,discharge-resistor-kohms = <32>;
};
@@ -317,6 +342,13 @@ panel_default: panel-default-state {
drive-strength = <8>;
bias-disable;
};
+
+ tsp_int_rst_default: tsp-int-rst-default-state {
+ pins = "gpio64", "gpio65";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
};
&usb3 {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 6/6] arm64: dts: qcom: msm8953-flipkart-rimob: Enable Hall sensor
From: Cristian Cozzolino via B4 Relay @ 2026-03-27 14:30 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel, Cristian Cozzolino,
Konrad Dybcio
In-Reply-To: <20260327-rimob-new-features-v4-0-06edff9c4509@protonmail.com>
From: Cristian Cozzolino <cristian_ci@protonmail.com>
Enable the Hall effect sensor (flip cover) for Billion Capture+.
The GPIO is mapped to SW_LID events as in other qcom devices.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
index a1280b0e7e90..8e3874740cf9 100644
--- a/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
+++ b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
@@ -47,9 +47,18 @@ framebuffer@90001000 {
gpio-keys {
compatible = "gpio-keys";
- pinctrl-0 = <&gpio_key_default>;
+ pinctrl-0 = <&gpio_hall_sensor_default>, <&gpio_key_default>;
pinctrl-names = "default";
+ event-hall-sensor {
+ label = "Hall Effect Sensor";
+ gpios = <&tlmm 46 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ linux,can-disable;
+ wakeup-source;
+ };
+
key-volume-up {
label = "Volume Up";
gpios = <&tlmm 85 GPIO_ACTIVE_LOW>;
@@ -329,6 +338,13 @@ &sdhc_2 {
&tlmm {
gpio-reserved-ranges = <0 4>, <135 4>;
+ gpio_hall_sensor_default: gpio-hall-sensor-default-state {
+ pins = "gpio46";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
gpio_key_default: gpio-key-default-state {
pins = "gpio85";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* 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
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