* [PATCH 2/2] arm64: dts: qcom: glymur: add TRNG node
From: Harshal Dev @ 2026-04-16 12:26 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Harshal Dev
In-Reply-To: <20260416-glymur_trng_enablement-v1-0-60abcfd45403@oss.qualcomm.com>
Glymur has a True Random Number Generator, add the node with the correct
compatible set.
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77..c9d46ec82ccc 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -3675,6 +3675,11 @@ pcie3b_phy: phy@f10000 {
status = "disabled";
};
+ rng: rng@10c3000 {
+ compatible = "qcom,glymur-trng", "qcom,trng";
+ reg = <0x0 0x10c3000 0x0 0x1000>;
+ };
+
tcsr_mutex: hwlock@1f40000 {
compatible = "qcom,tcsr-mutex";
reg = <0x0 0x01f40000 0x0 0x20000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: crypto: qcom,prng: Document Glymur TRNG
From: Harshal Dev @ 2026-04-16 12:26 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Harshal Dev
In-Reply-To: <20260416-glymur_trng_enablement-v1-0-60abcfd45403@oss.qualcomm.com>
Document glymur compatible for the True Random Number Generator.
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index 41402599e9ab..498d6914135e 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -17,6 +17,7 @@ properties:
- qcom,prng-ee # 8996 and later using EE
- items:
- enum:
+ - qcom,glymur-trng
- qcom,ipq5332-trng
- qcom,ipq5424-trng
- qcom,ipq9574-trng
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] Add TRNG support for Glymur SoC
From: Harshal Dev @ 2026-04-16 12:26 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Harshal Dev
Document and add the device-tree node to enable TRNG for Glymur SoC.
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
Harshal Dev (2):
dt-bindings: crypto: qcom,prng: Document Glymur TRNG
arm64: dts: qcom: glymur: add TRNG node
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 5 +++++
2 files changed, 6 insertions(+)
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260416-glymur_trng_enablement-31518b69fbca
Best regards,
--
Harshal Dev <harshal.dev@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4] dt-bindings: display: ti, am65x-dss: Fix AM62L DSS reg and clock constraints
From: Rob Herring (Arm) @ 2026-04-16 12:25 UTC (permalink / raw)
To: Swamil Jain
Cc: jyri.sarha, maarten.lankhorst, vigneshr, praneeth, krzk+dt,
tzimmermann, simona, devicetree, airlied, linux-kernel, mripard,
devarsht, tomi.valkeinen, conor+dt, dri-devel
In-Reply-To: <20260415110409.2577633-1-s-jain1@ti.com>
On Wed, 15 Apr 2026 16:34:09 +0530, Swamil Jain wrote:
> The AM62L DSS [1] support incorrectly used the same register and
> clock constraints as AM65x, but AM62L has a single video port
>
> Fix this by adding conditional constraints that properly define the
> register regions and clocks for AM62L DSS (single video port) versus
> other AM65x variants (dual video port).
>
> [1]: Section 12.7 (Display Subsystem and Peripherals)
> Link : https://www.ti.com/lit/pdf/sprujb4
>
> Fixes: cb8d4323302c ("dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS")
> Cc: stable@vger.kernel.org
> Signed-off-by: Swamil Jain <s-jain1@ti.com>
> ---
> Validated the changes with some examples:
> https://gist.github.com/swamiljain/79f30568c9ece89f5a20218f52647486
>
> Changelog:
> v3->v4:
> - Add reg-names constraint
> - Re-order constraints to make it consistent with the properties order
>
> Link to v3:
> https://lore.kernel.org/all/20260410105955.843868-1-s-jain1@ti.com/
>
> v2->v3:
> - Reduce redundancy and use constraints suggested by maintainers
> - Remove blank line between the tags
>
> Link to v2:
> https://lore.kernel.org/all/20260129150601.185882-1-s-jain1@ti.com/
>
> v1->v2:
> - Remove oneOf from top level constraints, it makes bindings redundant
> - Remove minItems from top level constraints
> - "dma-coherent" property shouldn't be changed in v1 itself
> - Add description for reg-names, clock and clock-names
> - Add constraints specific to AM62L and for other SoCs within allOf
> check
>
> Link to v1:
> https://lore.kernel.org/all/20251224133150.2266524-1-s-jain1@ti.com/
> ---
> .../bindings/display/ti/ti,am65x-dss.yaml | 70 ++++++++++++++-----
> 1 file changed, 52 insertions(+), 18 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v4 02/13] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-04-16 12:15 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260416-upbeat-archetypal-mantis-1ede48@quoll>
On 2026-04-16 10:23 +02:00, Krzysztof Kozlowski wrote:
> On Wed, Apr 15, 2026 at 11:00:16PM +0530, Kaustabh Chakraborty wrote:
>> On 2026-04-15 09:03 +02:00, Krzysztof Kozlowski wrote:
>> > On Tue, Apr 14, 2026 at 12:02:54PM +0530, Kaustabh Chakraborty wrote:
>> >> +description: |
>> >> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> >> + 8-bit brightness control for each channel, typically used as status
>> >> + indicators in mobile phones.
>> >> +
>> >> + This is a part of device tree bindings for S2M and S5M family of Power
>> >> + Management IC (PMIC).
>> >> +
>> >> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> >> + additional information and example.
>> >> +
>> >> +allOf:
>> >> + - $ref: common.yaml#
>> >
>> > Rob's comment is still valid:
>> > 1. How do you address one of three LEDs in non-RGB case?
>> > 2. Where is multi-color?
>>
>> Yes, multi-color should have been added here.
>>
>> >
>> > And based on this alone without other properties, I say this should be
>> > part of top-level schema. Separate node is fine, but no need for
>> > separate binding.
>>
>> BTW, for loading the sub-device driver via platform (as it won't be a
>> separate binding) the driver *must* be built-in. Although not related to
>> bindings, this seems counter-intuitive. I see the same problem with the
>
> I don't understand that comment. If it has nothing to do with the
> binding, what is the problem?
It was an unrelated user-space issue, so ignore.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: interrupt-controller: Add support for secure donated SGIs
From: Rob Herring @ 2026-04-16 12:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: Krzysztof Kozlowski, Conor Dooley, Marc Zyngier, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260412-b4-ffa_ns_sgi_gicv3-v1-1-af61243eb405@kernel.org>
On Sun, Apr 12, 2026 at 06:04:37PM +0100, Sudeep Holla wrote:
> In GICv3, SGI security is defined by interrupt grouping and configuration
> rather than by SGI number alone. Linux conventionally reserves SGIs 0-7
> for non-secure internal kernel IPIs, while higher SGIs is assumed to be
> owned/stolen by the Secure world unless explicitly made available.
>
> Document secure donated SGI interrupt specifiers for the GICv3 binding.
> It describes "arm,secure-donated-ns-sgi-ranges" for SGIs donated by the
> secure world to non-secure software. It excludes SGIs 0-7, which are
> already used by the kernel for internal IPI purposes.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
> .../bindings/interrupt-controller/arm,gic-v3.yaml | 27 +++++++++++++++++++++-
> include/dt-bindings/interrupt-controller/arm-gic.h | 1 +
> 2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> index bfd30aae682b..664727d071c9 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> @@ -45,17 +45,24 @@ description: |
>
> The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> interrupts, 2 for interrupts in the Extended SPI range, 3 for the
> - Extended PPI range. Other values are reserved for future use.
> + Extended PPI range, and 4 for SGI interrupts. Other values are
> + reserved for future use.
>
> The 2nd cell contains the interrupt number for the interrupt type.
> SPI interrupts are in the range [0-987]. PPI interrupts are in the
> range [0-15]. Extended SPI interrupts are in the range [0-1023].
> Extended PPI interrupts are in the range [0-127].
>
> + SGI interrupts are in the range [8-15] which overlaps with the SGIs
> + assigned to/reserved for the secure world but donated to the non
> + secure world to use. Refer "arm,secure-donated-ns-sgi-ranges" for
> + more details.
> +
> The 3rd cell is the flags, encoded as follows:
> bits[3:0] trigger type and level flags.
> 1 = edge triggered
> 4 = level triggered
> + SGIs are edge triggered and must be described as such.
>
> The 4th cell is a phandle to a node describing a set of CPUs this
> interrupt is affine to. The interrupt must be a PPI, and the node
> @@ -136,6 +143,24 @@ description: |
> - $ref: /schemas/types.yaml#/definitions/uint32
> - $ref: /schemas/types.yaml#/definitions/uint64
>
> + arm,secure-donated-ns-sgi-ranges:
> + description:
> + A list of pairs <sgi span>, where "sgi" is the first SGI INTID of a
> + range donated by the secure side to non-secure software, and "span" is
> + the size of that range. Multiple ranges can be provided.
> +
> + SGIs described by interrupt specifiers with type 4 (SGI) must fall
> + within one of these ranges. SGIs(0-7) reserved by non-secure world
> + for internal IPIs must not be listed here. "sgi" must be in the
> + range [8-15], "span" must be in the range [1-8], and the range must
> + not extend past SGI 15.
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + items:
As a matrix, you need:
items:
items:
- ...
- ...
However, given this is at most 8 entries, I would just do an array:
minItems: 1
maxItems: 8
uniqueItems: true
items:
minimum: 8
maximum: 15
Unless we need more flexibility in GICv5?
Is there an example we can stick this property into so it gets tested?
> + - minimum: 8
> + maximum: 15
> + - minimum: 1
> + maximum: 8
> +
> ppi-partitions:
> type: object
> additionalProperties: false
> diff --git a/include/dt-bindings/interrupt-controller/arm-gic.h b/include/dt-bindings/interrupt-controller/arm-gic.h
> index 887f53363e8a..52c2f3f090c5 100644
> --- a/include/dt-bindings/interrupt-controller/arm-gic.h
> +++ b/include/dt-bindings/interrupt-controller/arm-gic.h
> @@ -14,6 +14,7 @@
> #define GIC_PPI 1
> #define GIC_ESPI 2
> #define GIC_EPPI 3
> +#define GIC_SGI 4
>
> /*
> * Interrupt specifier cell 2.
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: Enable CAN RX via GPIO expander
From: Anup Kulkarni @ 2026-04-16 12:11 UTC (permalink / raw)
To: Dmitry Baryshkov, Konrad Dybcio
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-kernel, mukesh.savaliya, viken.dadhaniya
In-Reply-To: <lghedhcnuh2fm4mp64mkgsgtpkd32yneftjazgrye7bovxxaby@uscrda3wtyoj>
On 4/14/2026 11:39 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 06:20:14PM +0200, Konrad Dybcio wrote:
>> On 4/14/26 6:08 PM, Dmitry Baryshkov wrote:
>>> On Thu, Apr 02, 2026 at 04:22:53PM +0530, Anup Kulkarni wrote:
>>>> Few CAN controllers, part of RTSS sub-system on LeMans, route
>>>> their RX signal through a I2C GPIO expander at address 0x3b.
>>>> RTSS subsystem is an MCU like sub-system on LeMans with independent
>>>> booting capability through OSPI interface and supports peripherals like
>>>> RGMII, CAN-FD, UART, I2C, SPI etc.
>>>>
>>>> Describe this hardware wiring by configuring the expander GPIO 4 pin as
>>>> hog with output-high, asserting the selected line during boot.
>>> Missing platform name in the subject.
Will update the name in the next patch.
>>>
>>>> Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/lemans-evk.dts | 7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
>>>> index a1ef4eba2a20..b8371bdf9933 100644
>>>> --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
>>>> @@ -615,6 +615,13 @@ expander3: gpio@3b {
>>>> interrupts-extended = <&tlmm 39 IRQ_TYPE_LEVEL_LOW>;
>>>> pinctrl-0 = <&expander3_int>;
>>>> pinctrl-names = "default";
>>>> +
>>>> + rtss-can-sel-hog {
>>> Why is it being described as a hog rather than a pinctrl used by the
>>> CAN device?
The RTSS CAN device is active at boot-up so used hog property here.
>> My understanding is that the CAN bus is managed by SAIL ("RTSS")
> So, Linux can affect what is being required for the safety island?
Yes, CAN bus is managed by RTSS, but the transceivers are
outside of RTSS. The RX line of CAN device is connected to the transceiver through I2C
GPIO expander on board level. GPIO Expander pin enables mux to connect CAN RX to transceiver.
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Rob Herring (Arm) @ 2026-04-16 12:03 UTC (permalink / raw)
To: Kevin Hilman (TI)
Cc: devicetree, Ulf Hansson, linux-arm-kernel, linux-pm, linux-kernel,
arm-scmi, Geert Uytterhoeven
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-1-83396e4b5f8b@baylibre.com>
On Fri, 10 Apr 2026 16:44:36 -0700, Kevin Hilman (TI) wrote:
> Add binding documentation for the new power-domains-child-ids property,
> which works in conjunction with the existing power-domains property to
> establish parent-child relationships between a multi-domain power domain
> provider and external parent domains.
>
> Each element in the uint32 array identifies the child domain
> ID (index) within the provider that should be made a child domain of
> the corresponding phandle entry in power-domains. The two arrays must
> have the same number of elements.
>
> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
> ---
> Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: thermal: Fix false warning with 'phandle' in trips nodes
From: Rob Herring (Arm) @ 2026-04-16 12:03 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Daniel Lezcano, Zhang Rui, Krzysztof Kozlowski, Lukasz Luba,
Rafael J. Wysocki, linux-pm, Conor Dooley, linux-kernel,
devicetree
In-Reply-To: <20260410223601.1487473-2-robh@kernel.org>
On Fri, 10 Apr 2026 17:36:00 -0500, Rob Herring (Arm) wrote:
> A pattern property matching essentially anything doesn't work if there
> are implicit properties such as 'phandle' which can occur on any node.
> One such example popped up recently:
>
> arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: thermal-zones: gpuss0-thermal:trips:phandle: 531 is not of type 'object'
> from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
>
> Instead of a pattern property, use an "additionalProperties" schema
> instead which is the fallback in case of no matching property.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> Daniel, Please pick this up for v7.1 as the above warning is in next. Or
> if you prefer, I can take it.
>
> .../bindings/thermal/thermal-zones.yaml | 111 +++++++++---------
> 1 file changed, 54 insertions(+), 57 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* [PATCH v5 13/13] arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
eliza.
Fixes: af20af39fc09b ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 4a7a0ac40ce6..7e97361a5dc5 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -843,7 +843,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 12/13] arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for milos.
Fixes: 04bb37433330e ("arm64: dts: qcom: milos: Add UFS nodes")
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..a6e463f3885d 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1275,7 +1275,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 11/13] arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
sm8750.
Fixes: b1dac789c650a ("arm64: dts: qcom: sm8750: Add ICE nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 18fb52c14acd..099d7fb82ae6 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -2086,7 +2086,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 10/13] arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8650.
Fixes: 10e0246712951 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 1604bc8cff37..e2d98cf6adca 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -4081,7 +4081,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 09/13] arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8550.
Fixes: b8630c48b43fc ("arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 912525e9bca6..fe46a5d41fe0 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2465,7 +2465,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 08/13] arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8450.
Fixes: 86b0aef435851 ("arm64: dts: qcom: sm8450: Use standalone ICE node for UFS")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 03bf30b53f28..9528baedf8ae 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -5374,7 +5374,11 @@ ice: crypto@1d88000 {
compatible = "qcom,sm8450-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v3 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Rob Herring (Arm) @ 2026-04-16 12:00 UTC (permalink / raw)
To: Jens Emil Schulz Østergaard
Cc: Steen Hegelund, Krzysztof Kozlowski, devicetree, Jakub Kicinski,
linux-kernel, Vladimir Oltean, Woojung Huh, Conor Dooley,
Russell King, David S. Miller, netdev, UNGLinuxDriver,
Simon Horman, Daniel Machon, Paolo Abeni, Eric Dumazet,
Andrew Lunn
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-2-aadc8595306d@microchip.com>
On Fri, 10 Apr 2026 13:48:38 +0200, Jens Emil Schulz Østergaard wrote:
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
>
> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
> Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> ---
> Changes in v3:
> - remove additionalProperties: true
> - remove unnecessary | from description
> - change top level $ref to dsa.yaml#/$defs/ethernet-ports
> - use ethernet-ports and ethernet-port
> - move ethernet-ports under properties instead of patternProperties
> - move unevaluatedProperties: false after $ref
> - update example to use ethernet-ports and ethernet-port
>
> Changes in v2:
> - rename file to microchip,lan96455s-switch.yaml
> - remove led vendor property
> - add {rx,tx}-internal-delay-ps for rgmii delay
> - remove labels from example
> - remove container node from example
> ---
> .../net/dsa/microchip,lan96455s-switch.yaml | 111 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 112 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 07/13] arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
kodiak.
Fixes: dfd5ee7b34bb7 ("arm64: dts: qcom: sc7280: Add inline crypto engine")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..55fc256501c5 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -2579,7 +2579,11 @@ ice: crypto@1d88000 {
compatible = "qcom,sc7280-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0 0x01d88000 0 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 06/13] arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sc7180.
Fixes: 858536d9dc946 ("arm64: dts: qcom: sc7180: Add UFS nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index a4b17564469e..94a699cc2688 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1605,7 +1605,11 @@ ice: crypto@1d90000 {
compatible = "qcom,sc7180-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0 0x01d90000 0 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
ipa: ipa@1e40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 05/13] arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
monaco.
Fixes: cc9d29aad876d ("arm64: dts: qcom: qcs8300: enable the inline crypto engine")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 7b1d57460f1e..fa13210fc539 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -2737,7 +2737,11 @@ ice: crypto@1d88000 {
compatible = "qcom,qcs8300-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
crypto: crypto@1dfa000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 04/13] arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for lemans.
Fixes: 96272ba7103d4 ("arm64: dts: qcom: sa8775p: enable the inline crypto engine")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index fe6e76351823..d83cad26a20f 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -2758,7 +2758,11 @@ ice: crypto@1d88000 {
compatible = "qcom,sa8775p-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
cryptobam: dma-controller@1dc4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 03/13] arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
kaanapali.
Fixes: 2eeb5767d53f4 ("arm64: dts: qcom: Introduce Kaanapali SoC")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..14e362a4899b 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2538,7 +2538,11 @@ ice: crypto@1d88000 {
"qcom,inline-crypto-engine";
reg = <0x0 0x01d88000 0x0 0x18000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
};
tcsr_mutex: hwlock@1f40000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 02/13] soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev,
Manivannan Sadhasivam
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
Since Qualcomm inline-crypto engine (ICE) is now a dedicated driver
de-coupled from the QCOM UFS driver, it explicitly votes for its required
clocks during probe. For scenarios where the 'clk_ignore_unused' flag is
not passed on the kernel command line, to avoid potential unclocked ICE
hardware register access during probe the ICE driver should additionally
vote on the 'iface' clock.
Also update the suspend and resume callbacks to handle un-voting and voting
on the 'iface' clock.
Fixes: 2afbf43a4aec6 ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver")
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
drivers/soc/qcom/ice.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index b203bc685cad..bf4ab2d9e5c0 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -108,6 +108,7 @@ struct qcom_ice {
void __iomem *base;
struct clk *core_clk;
+ struct clk *iface_clk;
bool use_hwkm;
bool hwkm_init_complete;
u8 hwkm_version;
@@ -312,8 +313,13 @@ int qcom_ice_resume(struct qcom_ice *ice)
err = clk_prepare_enable(ice->core_clk);
if (err) {
- dev_err(dev, "failed to enable core clock (%d)\n",
- err);
+ dev_err(dev, "Failed to enable core clock: %d\n", err);
+ return err;
+ }
+
+ err = clk_prepare_enable(ice->iface_clk);
+ if (err) {
+ dev_err(dev, "Failed to enable iface clock: %d\n", err);
return err;
}
qcom_ice_hwkm_init(ice);
@@ -323,6 +329,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
int qcom_ice_suspend(struct qcom_ice *ice)
{
+ clk_disable_unprepare(ice->iface_clk);
clk_disable_unprepare(ice->core_clk);
ice->hwkm_init_complete = false;
@@ -579,11 +586,17 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
engine->core_clk = devm_clk_get_optional_enabled(dev, "ice_core_clk");
if (!engine->core_clk)
engine->core_clk = devm_clk_get_optional_enabled(dev, "ice");
+ if (!engine->core_clk)
+ engine->core_clk = devm_clk_get_optional_enabled(dev, "core");
if (!engine->core_clk)
engine->core_clk = devm_clk_get_enabled(dev, NULL);
if (IS_ERR(engine->core_clk))
return ERR_CAST(engine->core_clk);
+ engine->iface_clk = devm_clk_get_optional_enabled(dev, "iface");
+ if (IS_ERR(engine->iface_clk))
+ return ERR_CAST(engine->iface_clk);
+
if (!qcom_ice_check_supported(engine))
return ERR_PTR(-EOPNOTSUPP);
--
2.34.1
^ permalink raw reply related
* [PATCH v5 01/13] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev
In-Reply-To: <20260416-qcom_ice_power_and_clk_vote-v5-0-5ccf5d7e2846@oss.qualcomm.com>
The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
power-domain and iface clock. Without enabling the iface clock and the
associated power-domain the ICE hardware cannot function correctly and
leads to unclocked hardware accesses being observed during probe.
Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
power-domain and iface clock for new devices (Eliza and Milos) introduced
in the current release (7.1) with yet-to-stabilize ABI, while preserving
backward compatibility for older devices.
Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index 876bf90ed96e..ccb6b8dd8e11 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -30,6 +30,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: iface
+
+ power-domains:
maxItems: 1
operating-points-v2: true
@@ -44,6 +54,25 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,eliza-inline-crypto-engine
+ - qcom,milos-inline-crypto-engine
+
+ then:
+ required:
+ - power-domains
+ - clock-names
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
examples:
- |
#include <dt-bindings/clock/qcom,sm8550-gcc.h>
@@ -52,7 +81,11 @@ examples:
compatible = "qcom,sm8550-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x01d88000 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&gcc UFS_PHY_GDSC>;
operating-points-v2 = <&ice_opp_table>;
--
2.34.1
^ permalink raw reply related
* [PATCH v5 00/13] Add explicit clock vote and enable power-domain for QCOM-ICE
From: Harshal Dev @ 2026-04-16 11:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Kuldeep Singh, Krzysztof Kozlowski, Harshal Dev,
Manivannan Sadhasivam
When the kernel is booted without the 'clk_ignore_unused' and
'pd_ignore_unused' command‑line flags, votes for unused clocks and power
domains are dropped by the kernel post late_init and deferred probe
timeout. Depending on the relative timing between the ICE probe and the
kernel disabling the unused clocks and power domains occasional unclocked
register accesses or 'stuck' clocks are observed during QCOM‑ICE probe.
When the 'iface' clock is not voted on, unclocked register access would
be observed. On the other hand, if the associated power-domain for ICE
is not enabled, a 'stuck' clock is observed.
This patch series resolves both of these problems by adding explicit
power‑domain enablement and 'iface' clock‑vote handling to the QCOM‑ICE
driver.
The clock 'stuck' issue was first reported on Qualcomm RideSX4 (sa8775p)
platform: https://lore.kernel.org/all/ZZYTYsaNUuWQg3tR@x1/
Issue with unclocked ICE register access is easily reproducible on
on Qualcomm RB3Gen2 (kodiak) platform when 'clk_ignore_unused' is
not passed on the kernel command-line.
This patch series has been validated on: SM8650-MTP, RB3Gen2 and
Lemans-EVK.
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
Changes in v5:
- Rebased onto linux-next tag next-20260415
- Added patches 12 and 13 to this series to ensure newly added eliza and milos
DTS in v7.1 comply to the DT-binding introduced in this patch series.
- Fixed commit message of patch 1 to indicate eliza and milos DT support was
added in kernel v7.1.
- Collected Reviewed-by and Tested-by tags from Kuldeep, Konrad, Krzysztof and
Manivannan.
- Link to v4: https://lore.kernel.org/r/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com
Changes in v4:
- Squashed commits 1 and 2 from v3 to form a single consolidated patch with
an updated and more concise commit message that explains why the DT binding
needs to be fixed and why the fix is necessary for this release cycle.
- Re-order the ICE driver source code patches to be positioned before the DTS
patches.
- Collected Reviewed-by tags from Konrad for DTS patches which were missed in
v3.
- Link to v3: https://lore.kernel.org/r/20260317-qcom_ice_power_and_clk_vote-v3-0-53371dbabd6a@oss.qualcomm.com
Changes in v3:
- Dropped "_clk" suffix from clock names in DT binding and sources and ensure
ICE driver looks for these updated clock names.
- Updated commit message of DT binding change (Patch 1) to explicitly state
that the change is preserving backward compatibility.
- Introduced new DT binding commit to ensure eliza and milos require the iface
clock and power-domain.
- Check for IS_ERR() on devm_clk_get_optional_enabled(dev, "iface") return
value.
- Minor beautification of dev_err() prints as suggested by Konrad.
- Rebased onto latest linux-next tag next-20260316.
- Link to v2: https://lore.kernel.org/r/20260310-qcom_ice_power_and_clk_vote-v2-0-b9c2a5471d9e@oss.qualcomm.com
Changes in v2:
- Updated the DT bindings and ICE driver source to ensure no ABI breaks are
made in this patch series. A follow-up patch series will mark the clocks
and power-domain as required to preserve bisectability.
- Added list of allowed clock-names to the DT-binding.
- Added Fixes tag to mark the original regressions and ensure back-porting
for stable trees.
- Updated the commit messages to explicitly mention the problem of
potential unclocked register access and stuck clocks during probe.
- Dropped explicit calls to pm_runtime_* APIs from ICE probe, suspend and
resume.
- Link to v1: https://lore.kernel.org/r/20260123-qcom_ice_power_and_clk_vote-v1-0-e9059776f85c@qti.qualcomm.com
---
Harshal Dev (13):
dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE
arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node
arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node
arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node
arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node
arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node
arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node
arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
arch/arm64/boot/dts/qcom/eliza.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/kodiak.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/lemans.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/milos.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/monaco.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8450.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8650.dtsi | 6 +++-
arch/arm64/boot/dts/qcom/sm8750.dtsi | 6 +++-
drivers/soc/qcom/ice.c | 17 +++++++++--
13 files changed, 104 insertions(+), 14 deletions(-)
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260120-qcom_ice_power_and_clk_vote-769704f5036a
Best regards,
--
Harshal Dev <harshal.dev@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 01/13] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Rob Herring @ 2026-04-16 11:59 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Guenter Roeck,
Philipp Zabel, Eric Biggers, Sakari Ailus, Wolfram Sang,
Miquel Raynal, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-2-akhilrajeev@nvidia.com>
On Thu, Apr 09, 2026 at 04:27:31PM +0530, Akhil R wrote:
> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> Discovery and Configuration Specification [1] to specify which discovery
> method an I3C device supports during bus initialization. The property is
> a bitmap, where a bit value of 1 indicates support for that method, and 0
> indicates lack of support.
> Bit 0: SETDASA CCC (Direct)
> Bit 1: SETAASA CCC (Broadcast)
> Bit 2: Other CCC (vendor / standards extension)
> All other bits are reserved.
>
> It is specifically needed when an I3C device requires SETAASA for the
> address assignment. SETDASA will be supported by default if this property
> is absent, which means for now the property just serves as a flag to
> enable SETAASA, but keep the property as a bitmap to align with the
> specifications.
>
> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
> .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> index e25fa72fd785..1705d90d4d79 100644
> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> @@ -31,10 +31,12 @@ properties:
> described in the device tree, which in turn means we have to describe
> I3C devices.
>
> - Another use case for describing an I3C device in the device tree is when
> - this I3C device has a static I2C address and we want to assign it a
> - specific I3C dynamic address before the DAA takes place (so that other
> - devices on the bus can't take this dynamic address).
> + Other use-cases for describing an I3C device in the device tree are:
> + - When the I3C device has a static I2C address and we want to assign
> + it a specific I3C dynamic address before the DAA takes place (so
> + that other devices on the bus can't take this dynamic address).
> + - When the I3C device requires SETAASA for its discovery and uses a
> + pre-defined static address.
>
> "#size-cells":
> const: 0
> @@ -147,6 +149,26 @@ patternProperties:
> through SETDASA. If static address is not present, this address is assigned
> through SETNEWDA after assigning a temporary address via ENTDAA.
>
> + mipi-i3c-static-method:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0x1
> + maximum: 0xff
Looks like the max is 0x7 currently.
> + default: 1
> + description: |
> + Bitmap describing which methods of Dynamic Address Assignment from a
> + static address are supported by this I3C Target. A bit value of 1
> + indicates support for that method, and 0 indicates lack of support.
blank line here.
> + Bit 0: SETDASA CCC (Direct)
> + Bit 1: SETAASA CCC (Broadcast)
> + Bit 2: Other CCC (vendor / standards extension)
> + All other bits are reserved.
Indent these by 2 more.
> +
> + This property follows the MIPI I3C specification. The primary use
> + of this property is to indicate support for SETAASA, i.e Bit 1, but
> + will allow all values so that it is aligned with the specifications.
> + SETDASA will remain as the default method even if this property is
> + not present.
> +
> required:
> - reg
>
> --
> 2.50.1
>
^ 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