* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Mark Brown @ 2026-06-22 18:23 UTC (permalink / raw)
To: Otto Pflüger
Cc: Krzysztof Kozlowski, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Orson Zhai, Baolin Wang,
Chunyan Zhang, Lee Jones, linux-kernel, devicetree,
Krzysztof Kozlowski
In-Reply-To: <ajl8YparXoIXL0wm@abscue.de>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Mon, Jun 22, 2026 at 08:18:10PM +0200, Otto Pflüger wrote:
> Also, is it generally a rule now that the comatible is left out for MFD
> child nodes, or is there a reason why this is only done for regulators?
> Is this related to the (non-)existence of a reg property in the child?
It happens more for regulators because I tend to bring up that people
are encoding Linux internals rather than describing the hardware.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Otto Pflüger @ 2026-06-22 18:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260622-mindful-civet-of-refinement-02d3da@quoll>
On Mon, Jun 22, 2026 at 09:29:20AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Jun 20, 2026 at 10:54:00AM +0200, Otto Pflüger wrote:
> > Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> > PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
> >
> > Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> > 1 file changed, 44 insertions(+)
> >
>
> Sashiko has good point - where is any user of this binding (through
> reference)? Without $ref, this won't match thus is a noop for validation.
For some reason, the patch adding the binding references from v3 of
this series was merged by Lee Jones. This means that a user exists now:
Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml includes this
binding as one of the options.
Sashiko even sees that but the inconsistent omission of the compatible
property confuses it. The point about the lack of validation is correct,
but I was going to send a separate patch for that since it's more of an
MFD binding cleanup, whereas this series is mainly for the regulator
driver. Or should I add it here again?
Also, is it generally a rule now that the comatible is left out for MFD
child nodes, or is there a reason why this is only done for regulators?
Is this related to the (non-)existence of a reg property in the child?
Best regards,
Otto
^ permalink raw reply
* Re: [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Eric Biggers @ 2026-06-22 18:19 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Andy Gross, Harshal Dev, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, dmaengine, Kuldeep Singh
In-Reply-To: <CAMRc=MdJJRPBeNtAUr82b4zv7vLjrRQ76Q3bJHQYEigaE2Hqog@mail.gmail.com>
On Mon, Jun 22, 2026 at 04:25:12AM -0400, Bartosz Golaszewski wrote:
> On Fri, 19 Jun 2026 18:45:06 +0200, Eric Biggers <ebiggers@kernel.org> said:
> > On Fri, Jun 19, 2026 at 02:13:28PM +0530, Kuldeep Singh wrote:
> >> On 21-05-2026 18:47, Kuldeep Singh wrote:
> >> > This patchseries attempt to enable sdhc-ice, rng and qce on shikra
> >> > platform similar to other platforms.
> >> >
> >> > Previously, the 3 dt-bindigs/DT changes were sent as individual series
> >> > and with feedback received, clubbed them together as all belong to same
> >> > crypto subsystem.
> >> >
> >> > Here's link to old patchsets.
> >> > QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
> >>
> >> Hi Eric,
> >>
> >> As selftests issues for QCE are now fixed[1], so shikra series should be
> >> good to proceed? as your concerns[2] are now addressed.
> >> I am waiting for merge window to end and will send next rev post that.
> >>
> >> [1]
> >> https://lore.kernel.org/linux-arm-msm/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com/
> >> [2] https://lore.kernel.org/lkml/20260522024912.GC5937@quark/
> >
> > If you think that then it sounds like you need to read what I actually
> > said. The fixes are appreciated but don't change the big picture.
> >
> > - Eric
> >
>
> Eric,
>
> I mentioned it in another thread[1]. This series is not adding any new features
> to the QCE driver, it describes the hardware. The SoC *does have* this IP and
> no matter the state of the support in the kernel, there's nothing wrong in
> extending the existing bindings and adding new dts nodes.
>
> Thanks,
> Bartosz
It enables the driver on a new platform. So it very much has a real
effect. It's not just adding a hardware description without a user.
- Eric
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-22 18:07 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, devicetree, konradybcio, linux-arm-msm, linux-kernel,
xxsemail
In-Reply-To: <f18194c2-01eb-43c0-8e40-5575deac9e84@oss.qualcomm.com>
On Mon, 2026-06-22 at 13:40 +0200, Konrad Dybcio wrote:
> On 6/19/26 6:07 PM, Xin Xu wrote:
> > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > using GPIO84 as interrupt and GPIO76 as reset.
> >
> > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > ---
> > .../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 94
> > +++++++++++++++++++
> > 1 file changed, 94 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-
> > common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-
> > common.dtsi
> > index 51b57c697a75..2687a2a8dda4 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
> > @@ -599,6 +599,82 @@ fuel-gauge@55 {
> > };
> > };
> >
> > +&i2c15 {
> > + clock-frequency = <400000>;
> > + status = "okay";
>
> nit: please add an \n before status
>
> > +
> > + pm8008: pmic@8 {
> > + compatible = "qcom,pm8008";
> > + reg = <0x8>;
> > +
> > + interrupt-parent = <&tlmm>;
> > + interrupts = <84 IRQ_TYPE_EDGE_RISING>;
>
> interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_RISING>;
>
>
> > + reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;
> > +
> > + vdd-l1-l2-supply = <&vreg_s8c_1p35>;
> > + vdd-l3-l4-supply = <&vreg_bob>;
> > + vdd-l5-supply = <&vreg_bob>;
> > + vdd-l6-supply = <&vreg_bob>;
> > + vdd-l7-supply = <&vreg_bob>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pm8008_default>;
>
> property-n
> property-names
>
> in this order, please
>
> [...]
>
> > + regulators {
> > + vreg_l1p: ldo1 {
> > + regulator-name = "vreg_l1p";
> > + regulator-min-microvolt =
> > <1152000>;
> > + regulator-max-microvolt =
> > <1152000>;
>
> Make sure you verified all of the voltage ranges vs downstream,
> as incorrect values may lead to hw damage
>
> [...]
>
> > + pm8008_default: pm8008-default-state {
> > + int-pins {
> > + pins = "gpio84";
> > + function = "gpio";
> > + bias-disable;
> > + drive-strength = <2>;
> > + input-enable;
> > + };
> > +
> > + reset-pins {
> > + pins = "gpio76";
> > + function = "gpio";
> > + bias-pull-up;
> > + drive-strength = <2>;
> > + output-high;
>
> Drop output-high, the driver will take care of setting the output
> state
>
> Konrad
Thank you for your review!
I will fix the coding style issues (blank line before status,
interrupts-extended, property order, and dropping output-high)
in the next version.
I have verified all LDO voltages against the downstream device tree:
https://github.com/MiCode/kernel_devicetree/tree/elish-r-oss/
The definitions can be found around lines 209–244 in
qcom/elish-sm8250-camera-board.dtsi
The voltage constraints for ldo1 and ldo2 were incorrect in my
previous patch; this will be corrected in v2.
Best regards,
Xin Xu
^ permalink raw reply
* [PATCH v2] dt-bindings: clock: ti,clockdomain: Convert to DT schema
From: Bhargav Joshi @ 2026-06-22 17:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tero Kristo
Cc: linux-clk, devicetree, linux-kernel, goledhruva, m-chawdhry,
daniel.baluta, simona.toaca, j.bhargav.u
Convert TI clockdomain to yaml DT schema. Drop '#clock-cells' from the
required list as this binding doesn't define a new clock binding type,
it is used to group existing clock nodes under hardware hierarchy. Most
existing dts omit '#clock-cells'.
Update the reference to the old legacy text binding in the description
of bindings/clock/ti/ti,gate-clock.yaml to point to the new YAML file.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
Changes in v2:
- updating the stale reference to the legacy .txt file inside
bindings/clock/ti/ti,gate-clock.yaml to fix make refcheckdocs error
- Link to v1: https://lore.kernel.org/r/20260621-ti-clockdomain-v1-1-e99a56af98ea@gmail.com
---
.../devicetree/bindings/clock/ti/clockdomain.txt | 25 -------------
.../bindings/clock/ti/ti,clockdomain.yaml | 41 ++++++++++++++++++++++
.../bindings/clock/ti/ti,gate-clock.yaml | 2 +-
3 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
deleted file mode 100644
index edf0b5d42768..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Binding for Texas Instruments clockdomain.
-
-This binding uses the common clock binding[1] in consumer role.
-Every clock on TI SoC belongs to one clockdomain, but software
-only needs this information for specific clocks which require
-their parent clockdomain to be controlled when the clock is
-enabled/disabled. This binding doesn't define a new clock
-binding type, it is used to group existing clock nodes under
-hardware hierarchy.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "ti,clockdomain"
-- #clock-cells : from common clock binding; shall be set to 0.
-- clocks : link phandles of clocks within this domain
-
-Optional properties:
-- clock-output-names : from common clock binding.
-
-Examples:
- dss_clkdm: dss_clkdm {
- compatible = "ti,clockdomain";
- clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml b/Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml
new file mode 100644
index 000000000000..9494cbb1a942
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,clockdomain.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments clockdomain
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description:
+ This binding uses the common clock binding in consumer role. Every clock on TI
+ SoC belongs to one clockdomain, but software only needs this information for
+ specific clocks which require their parent clockdomain to be controlled when
+ the clock is enabled/disabled. This binding doesn't define a new clock binding
+ type, it is used to group existing clock nodes under hardware hierarchy.
+
+properties:
+ compatible:
+ const: ti,clockdomain
+
+ "#clock-cells":
+ const: 0
+
+ clocks: true
+
+ clock-output-names: true
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ dss_clkdm {
+ compatible = "ti,clockdomain";
+ clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
index eaa727ab0d7f..438e190d1067 100644
--- a/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
@@ -19,7 +19,7 @@ description: |
that is used.
[1] Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml
- [2] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+ [2] Documentation/devicetree/bindings/clock/ti/ti,clockdomain.yaml
properties:
compatible:
---
base-commit: acb7500801e98639f6d8c2d796ed9f64cba83d3a
change-id: 20260610-ti-clockdomain-a27dd0fa1ad5
Best regards,
--
Bhargav
^ permalink raw reply related
* Re: [PATCH v4 2/3] clk: qcom: camcc-glymur: Add camera clock controller driver
From: Taniya Das @ 2026-06-22 17:50 UTC (permalink / raw)
To: Bryan O'Donoghue, Konrad Dybcio, Jagadeesh Kona,
Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <1de2f9bf-b48c-4acb-882c-9e35a8582d0b@kernel.org>
On 6/12/2026 4:44 PM, Bryan O'Donoghue wrote:
> That's an argument against changing the values, not naming the values.
> Hexwork in upstream code is a public black box and should be avoided
> where possible.
>
> How about, take these fixed hex but someone on the clock-side in qcom
> agrees to update the script to write defined bitfields not hexwork in
> future deliveries. AFAIU its a script that mostly spits out these clock
> descriptors so, it should be possible to fix that script once @ source,
> without committing to fixing everything _currently_ in flight.
Thanks for the suggestion, Bryan. We should probably skip adding these
definitions because the approach just doesn't scale across our various
PLL architectures. The bitfields vary widely between different flavors
of alpha PLLs, and the SW driver doesn't interact with these fields
post-initialization anyway.
Even if we generate them through scripts, it provides no practical
benefit. The field names aren't meaningful to the end user, and the
software never decodes these bits at any stage beyond the core PLL bits
we already have defined.
I recommend leaving them as simple fixed hex values. This keeps the code
straightforward and perfectly aligns with the format our hardware team
uses to pass these values to us.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [RFC PATCH 3/3] dt-bindings: sifive: Add WorldGuard Checker
From: Conor Dooley @ 2026-06-22 17:50 UTC (permalink / raw)
To: Yu-Chien Peter Lin
Cc: devicetree, linux-riscv, linux-kernel, robh, krzk+dt, conor+dt,
pjw, palmer, aou, alex, samuel.holland, dlan, guodong, dfustini,
michal.simek, junhui.liu, darshan.prajapati, akpm, zhangchunyan,
luxu.kernel, pincheng.plct, nick.hu, jim.shu, zong.li,
greentime.hu, robin.randhawa, scott, dave.patel, raymond.mao
In-Reply-To: <20260619105834.1277302-4-peter.lin@sifive.com>
[-- Attachment #1: Type: text/plain, Size: 8912 bytes --]
On Fri, Jun 19, 2026 at 06:58:34PM +0800, Yu-Chien Peter Lin wrote:
> Add DT binding for SiFive wgChecker2, a hardware firewall enforcing
> WID-based access control in RISC-V Worlds. Provides checker slots to
> program per-WID permissions for downstream resources, with optional
> sub-range partitioning.
>
> Link: https://github.com/riscvarchive/security/blob/main/papers/worldguard%20proposal.pdf
> Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> Reviewed-by: Zong Li <zong.li@sifive.com>
> Reviewed-by: Jim Shu <jim.shu@sifive.com>
> ---
> .../devicetree/bindings/riscv/worlds.yaml | 9 +
> .../bindings/sifive/sifive,wgchecker2.yaml | 237 ++++++++++++++++++
> 2 files changed, 246 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
> index cc8b3747591e..c39a06c2dd8d 100644
> --- a/Documentation/devicetree/bindings/riscv/worlds.yaml
> +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
> @@ -34,6 +34,14 @@ properties:
> minimum: 2
> maximum: 64
>
> + sifive,trustedwid:
What's sifive specific about this? Wouldn't other vendors also have
trusted worlds?
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 31
> + description: |
> + The World ID (WID) designated as the trusted WID for this platform.
> + Transactions tagged with this WID are authorized to access and configure
> + WorldGuard blocks, including wgCheckers and wgMarkers.
> +
> additionalProperties: true
>
> examples:
> @@ -44,6 +52,7 @@ examples:
> #size-cells = <0>;
> timebase-frequency = <1000000>;
> riscv,nworlds = <4>;
> + sifive,trustedwid = <3>;
>
> cpu@0 {
> device_type = "cpu";
> diff --git a/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
> new file mode 100644
> index 000000000000..043c748385ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
> @@ -0,0 +1,237 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2026 SiFive, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sifive/sifive,wgchecker2.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SiFive WorldGuard Checker
> +
> +maintainers:
> + - Yu-Chien Peter Lin <peter.lin@sifive.com>
> +
> +description: |
> + The RISC-V Worlds ISA extension defines World IDs (WIDs) as architectural
> + identifiers that tag each system transaction with its originating context.
> + System integrators assign WIDs to execution contexts such as privilege modes,
> + trusted execution environments, or other isolation boundaries.
> +
> + The SiFive WorldGuard Checker is a hardware firewall positioned in the
> + system interconnect fabric. It inspects every transaction, evaluating the
> + WID against access control policies encoded in checker slots for each
> + protected resource. Transactions from unauthorized WIDs are blocked and
> + reported as bus errors, interrupts, or both.
> +
> + This enables spatial partitioning of memory regions and memory-mapped devices
> + across execution contexts. Different address ranges can enforce distinct
> + policies, allowing isolated workloads to coexist with hardware-enforced
> + protection.
> +
> + The wgChecker acts as an access-controller provider as defined in the
> + access-controllers framework. Protected devices are consumers that declare
> + their access policy via the access-controllers property. The hardware
> + supports up to 32 World IDs.
> +
> + The World ID authorized to configure WorldGuard blocks is specified by the
> + sifive,trustedwid property in the /cpus node.
> +
> +allOf:
> + - $ref: /schemas/access-controllers/access-controllers.yaml#
> +
> +properties:
> + compatible:
> + const: sifive,wgchecker2
Missing device specific compatibles.
> +
> + reg:
> + maxItems: 1
> + description:
> + Base address and size of the wgChecker memory-mapped I/O registers.
> +
> + interrupts:
> + maxItems: 1
> + description:
> + Interrupt line asserted when a WID access violation is detected and
> + interrupt reporting is enabled in the slot configuration (IR or IW
> + bits set).
> +
> + '#access-controller-cells':
> + const: 7
> + description: |
> + Specifier for one access-control rule, encoded as seven u32 cells:
> + <addr-hi addr-lo size-hi size-lo perm-hi perm-lo config>
> +
> + where:
> + - addr-hi, addr-lo: 64-bit base address of the protected region.
> + - size-hi, size-lo: 64-bit size of the protected region in bytes.
These two cells effectively just duplicate the reg property.
> + - perm-hi: Permission bitmap for WIDs 16..31. Two bits per WID:
> + bit 2*(WID-16) = Read permission
> + bit 2*(WID-16)+1 = Write permission
> + Set bits grant access. Use 0x0 for systems with
> + riscv,nworlds <= 16.
> + - perm-lo: Permission bitmap for WIDs 0..15. Two bits per WID:
> + bit 2*WID = Read permission
> + bit 2*WID+1 = Write permission
> + Set bits grant access.
And these two look like a layering violation to me. Why does the
consumer contain its own configuration information? If firmware provides
this to s-mode, it is either useless (because firmware has already done
the configuration) or it makes the access control pointless because
s-mode is expected to program its own access.
With that in mind, the first 4 cells can probably just be transmuted to
a single cell with platform-specific unique identifiers.
Surely the ecall involved with actually requesting access needs
something like that anyway?
The only value I can see in this is if some worlds that a bit of
software is running on can access a peripheral (or part thereof) and
others can't? Though platforms like that might benefit more from being
reworked to have homogeneous access! I've got no idea how a Linux driver
etc would handle the only some CPUs being permitted to access a register
region.
> + - config: Slot configuration bits:
> + Bit 0 (ER): Report read violations as bus errors
> + Bit 1 (EW): Report write violations as bus errors
> + Bit 2 (IR): Report read violations via interrupt
> + Bit 3 (IW): Report write violations via interrupt
> + Bit 4 (L): Lock bit - prevents further modification
> + Bits 5..31 are reserved and must be zero.
For the next revision of this, I really would like to see the access
controller driver.
> +
> + Multiple entries may be listed to apply different policies to
> + different address ranges, including sub-ranges within a single
> + physical resource.
> +
> +required:
> + - compatible
> + - reg
> + - '#access-controller-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + // Example 1: Single device protection
> + // WID 0 and WID 3 have RW access to UART; errors and IRQs reported.
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <1000000>;
> + riscv,nworlds = <4>;
> + sifive,trustedwid = <3>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + compatible = "riscv";
> + riscv,isa = "rv64imac";
> + };
> + };
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + uart: uart@1c1000 {
> + compatible = "ns16550a";
> + reg = <0x0 0x001c1000 0x0 0x1000>;
> + reg-names = "control";
> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
> + // WID 0,3 RW; report errors+IRQs
> + access-controllers = <&wgchecker0
> + 0x0 0x001c1000 0x0 0x00001000
> + 0x0 0x000000c3 0x0f>;
> + };
> +
> + wgchecker0: wgchecker@1c2000 {
I think this should be access-controller@
> + compatible = "sifive,wgchecker2";
> + reg = <0x0 0x001c2000 0x0 0x1000>;
> + #access-controller-cells = <7>;
> + interrupts = <80 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-parent = <&aplic_m>;
> + };
> + };
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI-FRAM
From: Wolfram Sang @ 2026-06-22 17:48 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Geert Uytterhoeven, Magnus Damm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260622174806.74450-5-wsa+renesas@sang-engineering.com>
Activate the FRAM and the SPI bus which it is attached to.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Change since v2:
* none
.../dts/renesas/r9a06g032-rzn1d400-eb.dts | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
index 97a339b30d76..ead379988fb1 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
+++ b/arch/arm/boot/dts/renesas/r9a06g032-rzn1d400-eb.dts
@@ -53,6 +53,10 @@ led@1 {
};
};
+&gpio2 {
+ status = "okay";
+};
+
&i2c2 {
/* Sensors are different across revisions. All are LM75B compatible */
sensor@49 {
@@ -152,6 +156,13 @@ pins_sdio1_clk: pins-sdio1-clk {
drive-strength = <12>;
};
+ pins_spi1: pins-spi1 {
+ pinmux = <RZN1_PINMUX(156, RZN1_FUNC_SPI0_M)>,
+ <RZN1_PINMUX(157, RZN1_FUNC_SPI0_M)>,
+ <RZN1_PINMUX(158, RZN1_FUNC_SPI0_M)>,
+ <RZN1_PINMUX(159, RZN1_FUNC_GPIO)>;
+ };
+
pins_uart2: pins-uart2 {
pinmux = <RZN1_PINMUX(105, RZN1_FUNC_UART2)>,
<RZN1_PINMUX(106, RZN1_FUNC_UART2)>,
@@ -168,6 +179,20 @@ &sdio1 {
status = "okay";
};
+&spi1 {
+ pinctrl-0 = <&pins_spi1>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ cs-gpios = <&gpio2a 31 GPIO_ACTIVE_LOW>;
+
+ fram: fram@0 {
+ compatible = "cypress,fm25", "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <12500000>;
+ };
+};
+
&switch {
pinctrl-0 = <&pins_eth1>, <&pins_eth2>, <&pins_eth3>, <&pins_eth4>,
<&pins_mdio1>;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: renesas: r9a06g032: Describe SPI controllers
From: Wolfram Sang @ 2026-06-22 17:48 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Herve Codina, Geert Uytterhoeven, Magnus Damm,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260622174806.74450-5-wsa+renesas@sang-engineering.com>
Add nodes for the 6 SPI controllers of the Renesas RZ/N1D SoC. The first
4 can only be controllers, the latter 2 can only be targets. DMA nodes
are not added yet because DMA needs some extra code in the drivers and
cannot be tested yet. Basic FIFO mode works reliably, though.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Herve Codina <herve.codina@bootlin.com>
---
Change since v2:
* tag added (Thanks, Herve!)
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 84 ++++++++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
index 442ea26b40f5..19c9bce0a26d 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
@@ -563,6 +563,90 @@ gic: interrupt-controller@44101000 {
<GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ /* Controller only */
+ spi1: spi@50005000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50005000 0x200>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI0>, <&sysctrl R9A06G032_HCLK_SPI0>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ num-cs = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ /* Controller only */
+ spi2: spi@50006000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50006000 0x200>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI1>, <&sysctrl R9A06G032_HCLK_SPI1>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ num-cs = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ /* Controller only */
+ spi3: spi@50007000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50007000 0x200>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI2>, <&sysctrl R9A06G032_HCLK_SPI2>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ num-cs = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ /* Controller only */
+ spi4: spi@50008000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50008000 0x200>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI3>, <&sysctrl R9A06G032_HCLK_SPI3>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ num-cs = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ /* Target only */
+ spi5: spi@50009000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x50009000 0x200>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI4>, <&sysctrl R9A06G032_HCLK_SPI4>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-slave;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ /* Target only */
+ spi6: spi@5000a000 {
+ compatible = "renesas,r9a06g032-spi", "renesas,rzn1-spi";
+ reg = <0x5000a000 0x200>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_CLK_SPI5>, <&sysctrl R9A06G032_HCLK_SPI5>;
+ clock-names = "ssi_clk", "pclk";
+ power-domains = <&sysctrl>;
+ spi-slave;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
/*
* The GPIO mapping to the corresponding pins is not obvious.
* See the hardware documentation for details.
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/3] spi: dt-bindings: snps,dw-apb-ssi: add 'power-domains' property
From: Wolfram Sang @ 2026-06-22 17:48 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Herve Codina, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-spi, devicetree
In-Reply-To: <20260622174806.74450-5-wsa+renesas@sang-engineering.com>
On the Renesas RZ/N1D SoC, this SPI controller belongs to a power
domain. Enable the property to describe it in DTs.
Reported-by: Herve Codina <herve.codina@bootlin.com>
Closes: https://lore.kernel.org/r/20260622132842.7e0d772c@bootlin.com
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Change since v2:
* new patch (Thanks, Herve!)
Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
index 8ebebcebca16..3896ee02d7b6 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -88,6 +88,9 @@ properties:
- const: ssi_clk
- const: pclk
+ power-domains:
+ maxItems: 1
+
resets:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/3] ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI and FRAM
From: Wolfram Sang @ 2026-06-22 17:48 UTC (permalink / raw)
To: linux-renesas-soc
Cc: Wolfram Sang, Conor Dooley, devicetree, Geert Uytterhoeven,
Krzysztof Kozlowski, linux-spi, Magnus Damm, Mark Brown,
Rob Herring
Here are the patches to enable the SPI-FRAM with FIFO (no DMA yet, needs
more work) on the RZ/N1D Extension board.
Changes since v2 in the individual patches.
A branch is here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/n1d/enablement
Wolfram Sang (3):
spi: dt-bindings: snps,dw-apb-ssi: add 'power-domains' property
ARM: dts: renesas: r9a06g032: Describe SPI controllers
ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI-FRAM
.../bindings/spi/snps,dw-apb-ssi.yaml | 3 +
.../dts/renesas/r9a06g032-rzn1d400-eb.dts | 25 ++++++
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 84 +++++++++++++++++++
3 files changed, 112 insertions(+)
--
2.47.3
^ permalink raw reply
* Re: [PATCH 05/23] powerpc/powermac: fix OF node refcount
From: Bartosz Golaszewski @ 2026-06-22 17:43 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: brgl, linux-kernel, netdev, linux-arm-msm, linux-sound,
driver-core, devicetree, linuxppc-dev, linux-i2c, iommu, linux-pm,
imx, linux-arm-kernel, intel-xe, dri-devel, linux-usb, linux-mips,
platform-driver-x86, Bartosz Golaszewski, stable, Lee Jones,
Mark Brown, Thierry Reding, Sebastian Hesselbarth, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Andi Shyti, Andy Shevchenko, Joerg Roedel, Will Deacon,
Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt
In-Reply-To: <20260521-pdev-fwnode-ref-v1-5-88c324a1b8d2@oss.qualcomm.com>
On Thu, 21 May 2026 10:36:28 +0200, Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> said:
> Platform devices created with platform_device_alloc() call
> platform_device_release() when the last reference to the device's
> kobject is dropped. This function calls of_node_put() unconditionally.
> This works fine for devices created with platform_device_register_full()
> but users of the split approach (platform_device_alloc() +
> platform_device_add()) must bump the reference of the of_node they
> assign manually. Add the missing call to of_node_get().
>
> Cc: stable@vger.kernel.org
> Fixes: 81e5d8646ff6 ("i2c/powermac: Register i2c devices from device-tree")
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> arch/powerpc/platforms/powermac/low_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
> index da72a30ab8657e6dc7e6f3437af612155783d8f9..973f58771d9636605ed5d3e91b45008543b584d3 100644
> --- a/arch/powerpc/platforms/powermac/low_i2c.c
> +++ b/arch/powerpc/platforms/powermac/low_i2c.c
> @@ -1471,7 +1471,7 @@ static int __init pmac_i2c_create_platform_devices(void)
> if (bus->platform_dev == NULL)
> return -ENOMEM;
> bus->platform_dev->dev.platform_data = bus;
> - bus->platform_dev->dev.of_node = bus->busnode;
> + bus->platform_dev->dev.of_node = of_node_get(bus->busnode);
> platform_device_add(bus->platform_dev);
> }
>
>
> --
> 2.47.3
>
>
Madhavan, can you please pick this up and send it upstream as a fix please?
Not having to carry it with the rest of the series will make things easier
for the next release.
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH 10/11] regulator: db8500: Add power domain regulators
From: Mark Brown @ 2026-06-22 17:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-10-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
On Thu, Jun 18, 2026 at 07:00:56AM +0200, Linus Walleij wrote:
> +static int db8500_regulator_get_voltage(struct regulator_dev *rdev)
> +{
> + struct db8500_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + if (!info->desc.fixed_uV)
> + return -EINVAL;
> +
> + return info->desc.fixed_uV;
> +}
The core supports single fixed voltages, set desc->fixed_uV.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties
From: Conor Dooley @ 2026-06-22 17:12 UTC (permalink / raw)
To: Yu-Chien Peter Lin
Cc: devicetree, linux-riscv, linux-kernel, robh, krzk+dt, conor+dt,
pjw, palmer, aou, alex, samuel.holland, dlan, guodong, dfustini,
michal.simek, junhui.liu, darshan.prajapati, akpm, zhangchunyan,
luxu.kernel, pincheng.plct, nick.hu, jim.shu, zong.li,
greentime.hu, robin.randhawa, scott, dave.patel, raymond.mao
In-Reply-To: <20260619105834.1277302-3-peter.lin@sifive.com>
[-- Attachment #1: Type: text/plain, Size: 5527 bytes --]
On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> Add per-hart DT properties for RISC-V Worlds architecture:
> riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> platform-defined values are primarily used by M-mode firmware
> to configure World ID CSRs and restrict WID usage across
> privilege levels.
>
> Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> ---
> .../devicetree/bindings/riscv/cpus.yaml | 21 +++++
> .../devicetree/bindings/riscv/worlds.yaml | 77 +++++++++++++++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index 5feeb2203050..4b5778b6d3e7 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -26,6 +26,7 @@ description: |
> allOf:
> - $ref: /schemas/cpu.yaml#
> - $ref: extensions.yaml
> + - $ref: worlds.yaml
> - if:
> not:
> properties:
> @@ -120,11 +121,31 @@ properties:
> thead systems where the vector register length is not identical on all harts, or
> the vlenb CSR is not available.
>
> + riscv,pmwid:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Platform-defined M-mode World ID (WID) assigned to this hart.
> + minimum: 0
> + maximum: 63
> +
> + riscv,pmwidlist:
> + $ref: /schemas/types.yaml#/definitions/uint64
> + description:
> + Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
I don't understand what the difference is between this property and the
one before it are.
Is this one meant to be used by m-mode software to then select one which
will appear in riscv,pmwid?
> +
> + riscv,pmlwidlist:
> + $ref: /schemas/types.yaml#/definitions/uint64
> + description:
> + Platform-defined bitmap of World IDs (WIDs) that S-mode and U-mode may use
> + on this hart.
> +
> # RISC-V has multiple properties for cache op block sizes as the sizes
> # differ between individual CBO extensions
> cache-op-block-size: false
> # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
> timebase-frequency: false
> + # RISC-V requires 'riscv,nworlds' in /cpus, so disallow it here
> + riscv,nworlds: false
Isn't this pointless? Nothing ever defines riscv,nworlds as a cpu level
property so there's no need to disallow it?
>
> interrupt-controller:
> type: object
> diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
> new file mode 100644
> index 000000000000..cc8b3747591e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/worlds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V Worlds Extension
> +
> +maintainers:
> + - Yu-Chien Peter Lin <peter.lin@sifive.com>
> +
> +description: |
> + The RISC-V Worlds ISA extension, as described in the RISC-V Privileged
> + Specification, adds World ID tagging for context isolation.
> +
> + This binding describes the system-wide Worlds configuration for the /cpus node
> + and is used alongside per-hart Worlds-related properties such as riscv,pmwid in
> + the RISC-V CPU binding and Worlds-related ISA extensions enumerated via
> + riscv,isa-extensions.
> +
> +select:
> + properties:
> + $nodename:
> + pattern: "^cpus$"
> +
> +properties:
> + riscv,nworlds:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + Number of World IDs (WIDs) supported by the platform. This is a system-wide
> + property that describes the total number of isolation contexts available.
> + Hardware components such as the WorldGuard Checker use this to determine
> + the valid range of WID values.
> + minimum: 2
> + maximum: 64
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + // Example: System with 4 World IDs
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <1000000>;
> + riscv,nworlds = <4>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + compatible = "sifive,bullet0", "riscv";
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> + riscv,pmwid = <0>;
> +
> + interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + reg = <1>;
> + compatible = "sifive,bullet0", "riscv";
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> + riscv,pmwid = <1>;
> +
> + interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + };
> --
> 2.43.7
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 02/16] spi: dt-bindings: add spi-phy-pattern-partition property
From: Miquel Raynal @ 2026-06-22 17:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Santhosh Kumar K, broonie, robh, krzk+dt, conor+dt, richard,
vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <20260622-jasmine-mandrill-of-emphasis-eebb4c@quoll>
Hello,
>> + spi-phy-pattern-partition:
>
> Is this specific to SPI-based MTD/NAND or rather broader - specific to
> MTD/NAND memories, regardless of interface? Feels like the second, thus
> maybe should be placed into the NAND bindings.
>
> If the first, then in below description:
>
> s/PHY/SPI PHY/ to be clear that this is about SPI, not the memory
> itself.
As far as I know, there is no raw NAND controller with such
capability. In the raw/parallel NAND world, timings are well defined by
the ONFI specification, it covers both the bus timings and the minimal
requirements for the chips. There is a method to query what "timing mode"
the NAND chip supports, and then we tune the controller registers to fit
the highest supported timings (capped by possible controller limits).
In the SPI world it is different. No specific timing has ever been
globally defined, so every manufacturer has its own capabilities which
are not discoverable dynamically. The routing also weights a lot. I
would say that we can safely keep this property SPI related, because it
is about the SPI bus being used with optimized timings, rather than some
kind of memory specific feature.
The reason why we need a property in those memories for the feature to
work, is because we need to make data transfers with a known pattern,
thus requiring to read the pattern from the internal array somehow.
Therefore, we shall indeed go for the s/PHY/SPI PHY/ naming indeed.
Thanks,
Miquèl
^ permalink raw reply
* [PATCH] arm64: dts: renesas: rzt2h-n2h-evk-common: Add memory nodes
From: Prabhakar @ 2026-06-22 17:07 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add memory nodes for the RZ/T2H and RZ/N2H EVK boards.
These boards populate 8GB of DDR memory, which is exposed through two
address ranges.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
index 1f575ea23db4..a0e1e4b1f23d 100644
--- a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
@@ -30,6 +30,17 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ memory@c8000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0xc8000000 0x0 0x38000000>;
+ };
+
+ memory@240000000 {
+ device_type = "memory";
+ reg = <0x2 0x40000000 0x1 0xc0000000>;
+ };
+
reg_1p8v: regulator-1p8v {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC v5 6/6] iio: osf: register IIO devices from capabilities
From: Jonathan Cameron @ 2026-06-22 17:07 UTC (permalink / raw)
To: Jinseob Kim
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-7-kimjinseob88@gmail.com>
On Tue, 16 Jun 2026 16:22:42 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Register IIO devices for supported Open Sensor Fusion capability entries
> and push received samples into IIO buffers when enabled.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
Sashiko had a few comments. The last one on the unitilialized heap
memory needs a new version of the fix from me.
Hopefully I'll get to that in the next few days,
https://sashiko.dev/#/patchset/20260529121005.1470-1-kimjinseob88%40gmail.com
The one about intermediate build issues (if correct) suggests you didn't
ensure this series builds after each patch. Please make sure to do that
to avoid breaking bisectability of the kernel.
Thanks,
Jonathan
> ---
> drivers/iio/opensensorfusion/Kconfig | 11 +-
> drivers/iio/opensensorfusion/Makefile | 3 +-
> drivers/iio/opensensorfusion/osf_core.c | 253 ++++++++++++++++++++--
> drivers/iio/opensensorfusion/osf_core.h | 52 +++++
> drivers/iio/opensensorfusion/osf_iio.c | 275 ++++++++++++++++++++++++
> drivers/iio/opensensorfusion/osf_iio.h | 22 ++
> 6 files changed, 586 insertions(+), 30 deletions(-)
> create mode 100644 drivers/iio/opensensorfusion/osf_iio.c
> create mode 100644 drivers/iio/opensensorfusion/osf_iio.h
>
> diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
> index d393eb3aa..8b9376d28 100644
> --- a/drivers/iio/opensensorfusion/Kconfig
> +++ b/drivers/iio/opensensorfusion/Kconfig
> @@ -5,11 +5,10 @@ config OPEN_SENSOR_FUSION
> depends on IIO
> depends on SERIAL_DEV_BUS
> select CRC32
> + select IIO_BUFFER
> + select IIO_KFIFO_BUF
> help
> - Build the Open Sensor Fusion UART receive path.
> + Build the Open Sensor Fusion UART IIO driver.
>
> - The driver receives OSF protocol frames over a serdev UART.
> - Frames are decoded and validated before being passed to the
> - driver core.
> - This patch only adds the transport path.
> - IIO device registration is added separately.
> + The driver receives OSF protocol frames over a serdev UART and
> + registers IIO devices for supported capability entries.
Avoid this churn. I wouldn't worry about it being a little forwards
looking when added in the earlier patch and directly go to the final
text.
> diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
> index 137fb7166..61ef55646 100644
> --- a/drivers/iio/opensensorfusion/osf_core.c
> +++ b/drivers/iio/opensensorfusion/osf_core.c
>
> -static int osf_core_validate_sensor_sample(const struct osf_frame *frame)
> +static int osf_core_register_capabilities(struct osf_device *osf,
> + const struct osf_capability_cache *cache)
> {
> + struct iio_dev *indio_dev;
> + unsigned int i;
> + int ret;
> +
> + if (osf->capability_cache.valid)
> + return 0;
> +
> + for (i = 0; i < cache->capability_count; i++) {
> + if (!osf_iio_sensor_supported(cache->entries[i].sensor_type,
> + cache->entries[i].channel_count))
> + continue;
> +
> + if (osf_core_capability_is_duplicate(cache, i))
> + return -EEXIST;
> + }
> +
> + for (i = 0; i < cache->capability_count; i++) {
> + if (!osf_iio_sensor_supported(cache->entries[i].sensor_type,
> + cache->entries[i].channel_count))
> + continue;
> +
> + ret = osf_iio_register_sensor(osf->dev, &cache->entries[i],
> + osf, &indio_dev);
> + if (ret)
> + goto err_unregister;
> +
> + osf->iio_devs[osf->iio_dev_count].sensor_type =
> + cache->entries[i].sensor_type;
> + osf->iio_devs[osf->iio_dev_count].sensor_index =
> + cache->entries[i].sensor_index;
> + osf->iio_devs[osf->iio_dev_count].indio_dev = indio_dev;
> + osf->iio_dev_count++;
Probably use a designated initializer for this one
ost->iio_dev[osf->iio_dev_count++] = (struct osf_iio_binding) {
.sensor_type = ...
};
Not a problem if the lines are over 80 chars given this should be generally easier
to read.
> +
> +static int osf_core_handle_sensor_sample(struct osf_device *osf,
> + const struct osf_frame *frame)
> +{
> + struct osf_latest_sample *latest;
> struct osf_sensor_sample sample;
> + struct iio_dev *indio_dev;
> + s32 values[OSF_MAX_SAMPLE_CHANNELS] = { };
> + unsigned int i;
> + int ret;
> +
> + ret = osf_protocol_decode_sensor_sample(frame, &sample);
> + if (ret)
> + return ret;
> +
> + if (sample.channel_count > OSF_MAX_SAMPLE_CHANNELS)
> + return -E2BIG;
> +
> + for (i = 0; i < sample.channel_count; i++) {
> + ret = osf_protocol_sensor_sample_value(&sample, i, &values[i]);
> + if (ret)
> + return ret;
> + }
>
> - return osf_protocol_decode_sensor_sample(frame, &sample);
> + mutex_lock(&osf->latest_lock);
This may well be better as a scoped_guard()
> + latest = osf_core_find_latest_sample(osf, sample.sensor_type,
> + sample.sensor_index);
> + if (!latest) {
> + mutex_unlock(&osf->latest_lock);
scoped_guard() would allow you to return here without worrying
about the manual unlock.
> + return -E2BIG;
> + }
> +
> + memcpy(latest->values, values, sizeof(values));
> + latest->sensor_type = sample.sensor_type;
> + latest->sensor_index = sample.sensor_index;
> + latest->channel_count = sample.channel_count;
> + latest->sample_format = sample.sample_format;
> + latest->scale_nano = sample.scale_nano;
> + latest->sequence = frame->sequence;
> + latest->timestamp_us = frame->timestamp_us;
> + latest->valid = true;
> + osf->last_sequence = frame->sequence;
> + mutex_unlock(&osf->latest_lock);
> +
> + indio_dev = osf_core_find_iio_dev(osf, sample.sensor_type,
> + sample.sensor_index);
> + if (!indio_dev)
> + return 0;
> +
> + return osf_iio_push_sample(indio_dev, values, sample.channel_count);
> }
>
> @@ -73,27 +260,47 @@ int osf_core_receive_frame(struct osf_device *osf, const u8 *buf, size_t len)
>
> switch (frame.message_type) {
> case OSF_MSG_SENSOR_SAMPLE:
> - ret = osf_core_validate_sensor_sample(&frame);
> - break;
> + return osf_core_handle_sensor_sample(osf, &frame);
> case OSF_MSG_DEVICE_STATUS:
> - ret = osf_core_validate_device_status(&frame);
> - break;
> + return osf_core_handle_device_status(osf, &frame);
> case OSF_MSG_CAPABILITY_REPORT:
> - ret = osf_core_validate_capability_report(&frame);
> - break;
> + return osf_core_handle_capability_report(osf, &frame);
> default:
> if (frame.message_type >= OSF_RESERVED_MSG_FIRST &&
> frame.message_type <= OSF_RESERVED_MSG_LAST)
> - ret = 0;
> - else if (frame.message_type >= OSF_VENDOR_PRIVATE_FIRST)
> - ret = 0;
> - else
> - ret = -EOPNOTSUPP;
> - break;
> + return 0;
> + if (frame.message_type >= OSF_VENDOR_PRIVATE_FIRST)
> + return 0;
> + return -EOPNOTSUPP;
> }
See if you can rework original code to reduce the churn here.
> +}
> +
> +int osf_core_read_latest_sample(struct osf_device *osf, u16 sensor_type,
> + u16 sensor_index, unsigned int channel,
> + s32 *value)
> +{
> + const struct osf_latest_sample *latest;
> + unsigned int i;
> + int ret = -ENODATA;
> +
> + if (!osf || !value)
> + return -EINVAL;
> +
> + mutex_lock(&osf->latest_lock);
Looks like a good place to use guard(mutex)(&osf->latest_lock);
Remember to include cleanup.h
> + for (i = 0; i < osf->latest_sample_count; i++) {
> + latest = &osf->latest_samples[i];
> + if (latest->sensor_type != sensor_type ||
> + latest->sensor_index != sensor_index)
> + continue;
> +
> + if (!latest->valid || channel >= latest->channel_count)
> + break;
>
> - if (!ret)
> - osf->last_sequence = frame.sequence;
> + *value = latest->values[channel];
> + ret = 0;
With guard, you can return directly here.
> + break;
> + }
> + mutex_unlock(&osf->latest_lock);
This gets handled automatically on leaving scope
Then if you get here you can just do
return -ENODATA;
>
> return ret;
> }
> diff --git a/drivers/iio/opensensorfusion/osf_iio.c b/drivers/iio/opensensorfusion/osf_iio.c
> new file mode 100644
> index 000000000..862a797f4
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_iio.c
> +
> +bool osf_iio_sensor_supported(u16 sensor_type, u16 channel_count)
> +{
> + return !!osf_iio_find_sensor_spec(sensor_type, channel_count);
The !! is getting used a lot less in modern kernel code. Linus Torvalds
once pointed out how hard it is to read. Maybe != 0 is clearer and
let the compiler do the optimization if it wants.
> +}
> +
> +const char *osf_iio_sensor_name(u16 sensor_type)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(osf_iio_sensor_specs); i++) {
> + if (osf_iio_sensor_specs[i].sensor_type == sensor_type)
> + return osf_iio_sensor_specs[i].name;
> + }
> +
> + return NULL;
> +}
> +}
> +
> +int osf_iio_push_sample(struct iio_dev *indio_dev, const s32 *values,
> + unsigned int channel_count)
As you are comparing it with the reported number of channels from spec->channel
count I would match type with that (u16 I think)
> +{
> + struct osf_iio_state *state = iio_priv(indio_dev);
> + s64 timestamp;
> +
> + if (channel_count != state->spec->channel_count)
> + return -EPROTO;
> +
> + /* This is only a fast path; IIO rechecks buffer state while pushing. */
> + if (!iio_buffer_enabled(indio_dev))
> + return 0;
> +
> + timestamp = iio_get_time_ns(indio_dev);
> +
> + return iio_push_to_buffers_with_ts_unaligned(indio_dev, values,
> + channel_count * sizeof(*values),
> + timestamp);
> +}
^ permalink raw reply
* Re: [PATCH 09/11] regulator: db8500-prcmu: Remove EPOD regulators
From: Mark Brown @ 2026-06-22 17:00 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-9-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 160 bytes --]
On Thu, Jun 18, 2026 at 07:00:55AM +0200, Linus Walleij wrote:
> Remove the obsolete DB8500 PRCMU regulator drivers.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner @ 2026-06-22 16:59 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622105546.69c6b4bb@jic23-huawei>
On 6/22/26 4:55 AM, Jonathan Cameron wrote:
> On Sun, 21 Jun 2026 16:14:57 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
>> On 6/21/26 1:41 PM, Jonathan Cameron wrote:
>>> On Mon, 15 Jun 2026 16:59:59 -0500
>>> "David Lechner (TI)" <dlechner@baylibre.com> wrote:
>>>
...
>>>> + description: The current output of the excitation channels in microamps.
>>>> + minimum: 1
>>>> + maximum: 1000
>>>> +
>>>> + current-chopping:
>>>> + $ref: /schemas/types.yaml#/definitions/flag
>>>> + description:
>>>> + If provided, the two excitation channels are to be used with current
>>>> + chopping enabled.
>>>
>>> Can I have a reference for that? My initial read suggests it's the input channels
>>
>> No. :-)
>>
>> I must have got two ideas mixed together in my head to come up with
>> this. Clearly this should be `input-channel-rotation` or something like
>> that (we discussed in another thread already). Also curious if you thing
>> any of these properties are common enough to promote to adc.yaml or if we
>> should just make them e.g. `ti,input-channel-rotation` (you might not have
>> had time to read the threads on that yet).
>
> It's turned up in a couple of drivers and the concept is fairly standard I think
> so I'm fine with promoting this to a top level property if the definition can
> be generic enough.
>
> For a non TI example, the LTC2893 has this as well for it's thermistor settings.
> It might be worth comparing the approach given here with what we have there.
> In that case there are specific node types for different types of things that
> are wired up with constraints on things like excitation currents.
> It kind of constrains things to the sane known use cases. However that is
> partly because that device does (I think) more type specific handling than
> we have here.
LTC2983 has current source rotation, so it has a adi,current-rotate property
which would be the same as the excitation-current-rotation property that
we have proposed here (named current-chopping in the patch, but better name
was suggested in later discussion).
So not quite the same as the input-rotation property that we would need for
this chip. Although ti,ads1262 that Kurt is working on will have both.
>
>>
>>> that are chopped. For GC_EN
>>> "When enabled, the device automatically swaps
>>> the analog inputs and takes the average of two consecutive conversions to
>>> cancel the internal offset voltage"
>>>
>>>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Conor Dooley @ 2026-06-22 16:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: sashiko-reviews, neil.armstrong, vkoul, dri-devel, robh, conor+dt,
linux-phy, olteanv, devicetree, wsa+renesas
In-Reply-To: <0a6f92ba-de8c-48ae-9025-a7570e53e453@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
On Mon, Jun 22, 2026 at 03:23:05PM +0200, Krzysztof Kozlowski wrote:
> On 22/06/2026 12:19, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Low] Unintended replacement of BNF notation `::=` with `:=`.
> > --
> >
> > commit a9fdd0b065eb5b6394a9c33ffba0fd5194e80115
> > Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >
> > dt-bindings: Drop incorrect usage of double '::'
> >
> > This commit cleans up device tree binding schemas by removing the redundant
> > double colons at the end of descriptions inside YAML literal style blocks.
> >
> > Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> >
> >> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> >> index 9e2d78a78e409..769243a2bf046 100644
> >> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> >> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> >> @@ -13,8 +13,8 @@ description: |
> >> Mux controller consumers should specify a list of mux controllers that they
> >> want to use with a property containing a 'mux-ctrl-list':
> >>
> >> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
> >> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
> >> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
> >> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
> >
> > [Severity: Low]
> > Does this unintentionally change the standard Backus-Naur Form (BNF) ::=
> > operator to :=? It looks like a global search-and-replace for :: might
>
>
> I wasn't sure about that... and indeed this should not be changed. I
> will send a v2.
Other than this one that I agree shouldn't be changed to a single :,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
(Although I find the syntax used here to be really confusing and a good
example in the text would be a lot clearer. OTOH, how to write consumers
is, I think, well understood, since they all work the same.)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Conor Dooley @ 2026-06-22 16:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-3-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
On Mon, Jun 22, 2026 at 12:16:07PM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v5 5/6] iio: osf: add UART transport
From: Jonathan Cameron @ 2026-06-22 16:49 UTC (permalink / raw)
To: Jinseob Kim
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-6-kimjinseob88@gmail.com>
On Tue, 16 Jun 2026 16:22:41 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Add the serdev UART transport and the initial OSF core receive path.
>
> Enable the required vcc regulator with devm_regulator_get_enable()
> before opening the UART, keeping power handling limited to the simple
> probe-time requirement for this RFC.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
A few things inline.
Thanks,
Jonathan
> diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
> new file mode 100644
> index 000000000..d393eb3aa
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config OPEN_SENSOR_FUSION
> + tristate "Open Sensor Fusion UART IIO driver"
> + depends on IIO
> + depends on SERIAL_DEV_BUS
> + select CRC32
> + help
> + Build the Open Sensor Fusion UART receive path.
> +
> + The driver receives OSF protocol frames over a serdev UART.
> + Frames are decoded and validated before being passed to the
> + driver core.
> + This patch only adds the transport path.
> + IIO device registration is added separately.
Don't talk about a patch in here. Talk about what is supported then
if you really want to add the other bits in later patches. Mostly
this help is generic enough we don't need to modify it more than
once in a series.
> diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
> new file mode 100644
> index 000000000..137fb7166
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_core.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +#include "osf_core.h"
> +#include "osf_protocol.h"
> +
> +#define OSF_RESERVED_MSG_FIRST 0x7f00
> +#define OSF_RESERVED_MSG_LAST 0x7fff
> +#define OSF_VENDOR_PRIVATE_FIRST 0x8000
> +
> +void osf_core_init(struct osf_device *osf, struct device *dev)
> +{
> + memset(osf, 0, sizeof(*osf));
*osf = (struct osf_device){
.dev = dev,
};
is guaranteed to also clear all other fields (new C spec as
well as the options the kernel has long been built with)
so is how I would always do cases of zero then set stuff like
this.
> + osf->dev = dev;
> +}
> diff --git a/drivers/iio/opensensorfusion/osf_serdev.c b/drivers/iio/opensensorfusion/osf_serdev.c
> new file mode 100644
> index 000000000..624cb01fe
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_serdev.c
> +
> +static void osf_serdev_remove(struct serdev_device *serdev)
> +{
> + struct osf_serdev *osf_uart = serdev_device_get_drvdata(serdev);
> +
> + serdev_device_close(serdev);
> + osf_stream_reset(&osf_uart->stream);
> + osf_core_unregister_iio(&osf_uart->osf);
My gut feeling is this should be first to tear down the device
interfaces as soon as possible. They will have been initialized
after the serdev was opened so should be unregistered before it is closed.
If there is a reason for this specific order add a comment.
> +}
> +
> +static struct serdev_device_driver osf_serdev_driver = {
> + .probe = osf_serdev_probe,
> + .remove = osf_serdev_remove,
> + .driver = {
> + .name = "open-sensor-fusion-uart",
> + .of_match_table = osf_serdev_of_match,
> + },
> +};
> +
No blank line here as the macro is extremely tightly coupled
with the structure and it is nice to have the visual cue.
> +module_serdev_device_driver(osf_serdev_driver);
> +
> +MODULE_DESCRIPTION("Open Sensor Fusion IIO driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* [PATCH v18 4/4] arm64: dts: renesas: rzg3l-smarc-som: Enable SDHI2
From: Biju @ 2026-06-22 16:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260622164819.184674-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Enable SDHI2 on the RZ/G3L SMARC EVK platform using the internal
voltage regulator for voltage switching. SDHI2 signals are muxed
with I2S0; the selection is controlled by the SW_SD2_EN macro in
the board DTS, which must match the position of switch SYS.4 on
the SoM. By default, I2S0 is enabled.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v17->v18:
* No change.
v1->v17:
* No change.
---
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 88 +++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
index 446c7780cb30..3d5e6b8489a9 100644
--- a/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
@@ -42,6 +42,7 @@ aliases {
ethernet1 = ð1;
i2c0 = &i2c0;
mmc0 = &sdhi0;
+ mmc2 = &sdhi2;
};
memory@48000000 {
@@ -296,6 +297,74 @@ sd0-data {
power-source = <1800>;
};
};
+
+ sdhi2_pins: sd2 {
+ sd2-cd {
+ pinmux = <RZG3L_PORT_PINMUX(K, 0, 1)>; /* SD2_CD */
+ };
+
+ sd2-clk {
+ pinmux = <RZG3L_PORT_PINMUX(H, 0, 1)>; /* SD2_CLK */
+ power-source = <3300>;
+ };
+
+ sd2-cmd {
+ pinmux = <RZG3L_PORT_PINMUX(H, 1, 1)>; /* SD2_CMD */
+ input-enable;
+ power-source = <3300>;
+ };
+
+ sd2-data {
+ pinmux = <RZG3L_PORT_PINMUX(H, 2, 1)>, /* SD2_DAT0 */
+ <RZG3L_PORT_PINMUX(H, 3, 1)>, /* SD2_DAT1 */
+ <RZG3L_PORT_PINMUX(H, 4, 1)>, /* SD2_DAT2 */
+ <RZG3L_PORT_PINMUX(H, 5, 1)>; /* SD2_DAT3 */
+ input-enable;
+ power-source = <3300>;
+ };
+
+ sd2-iovs {
+ pinmux = <RZG3L_PORT_PINMUX(K, 1, 1)>; /* SD2_IOVS */
+ };
+
+ sd2-pwen {
+ pinmux = <RZG3L_PORT_PINMUX(K, 2, 1)>; /* SD2_PWEN */
+ };
+ };
+
+ sdhi2_pins_uhs: sd2-uhs {
+ sd2-cd {
+ pinmux = <RZG3L_PORT_PINMUX(K, 0, 1)>; /* SD2_CD */
+ };
+
+ sd2-clk {
+ pinmux = <RZG3L_PORT_PINMUX(H, 0, 1)>; /* SD2_CLK */
+ power-source = <1800>;
+ };
+
+ sd2-cmd {
+ pinmux = <RZG3L_PORT_PINMUX(H, 1, 1)>; /* SD2_CMD */
+ input-enable;
+ power-source = <1800>;
+ };
+
+ sd2-data {
+ pinmux = <RZG3L_PORT_PINMUX(H, 2, 1)>, /* SD2_DAT0 */
+ <RZG3L_PORT_PINMUX(H, 3, 1)>, /* SD2_DAT1 */
+ <RZG3L_PORT_PINMUX(H, 4, 1)>, /* SD2_DAT2 */
+ <RZG3L_PORT_PINMUX(H, 5, 1)>; /* SD2_DAT3 */
+ input-enable;
+ power-source = <1800>;
+ };
+
+ sd2-iovs {
+ pinmux = <RZG3L_PORT_PINMUX(K, 1, 1)>; /* SD2_IOVS */
+ };
+
+ sd2-pwen {
+ pinmux = <RZG3L_PORT_PINMUX(K, 2, 1)>; /* SD2_PWEN */
+ };
+ };
};
#if (SW_SD0_DEV_SEL)
@@ -329,6 +398,25 @@ &sdhi0 {
};
#endif
+#if SW_SD2_EN
+&sdhi2 {
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <&sdhi2_vqmmc>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&sdhi2_vqmmc {
+ status = "okay";
+};
+#endif
+
&wdt0 {
timeout-sec = <60>;
status = "okay";
--
2.43.0
^ permalink raw reply related
* [PATCH v18 3/4] arm64: dts: renesas: rzg3l-smarc-som: Enable SD/eMMC on SDHI0
From: Biju @ 2026-06-22 16:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260622164819.184674-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add support for enabling SD card or eMMC on SDHI0 on the RZ/G3L SMARC
SoM. The selection between SD and eMMC is controlled by the
SW_SD0_DEV_SEL macro in the board DTS, which must match the position
of switch SYS.1 on the SoM. By default, eMMC is enabled.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v17->v18:
* No change.
v1->v17:
* No change.
---
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 1 +
.../boot/dts/renesas/rzg3l-smarc-som.dtsi | 111 ++++++++++++++++++
2 files changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
index 0b6b7e109200..96cc7ee46a6a 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
@@ -9,6 +9,7 @@
/* Switch selection settings */
#define RZ_BOOT_MODE3 1
+#define SW_SD0_DEV_SEL 0
#define SW_SD2_EN 0
#define SW_DPI_EN 0
#define SW_GPIO4 1
diff --git a/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
index 091a227233cb..446c7780cb30 100644
--- a/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3l-smarc-som.dtsi
@@ -9,6 +9,10 @@
* Please set the below switch position on the SoM and the corresponding macro
* on the board DTS:
*
+ * Switch position SYS.1, Macro SW_SD0_DEV_SEL:
+ * 0 - SD0 is connected to eMMC (default)
+ * 1 - SD0 is connected to uSD0 card
+ *
* Switch position SYS.2, Macro SW_I3C_EN:
* 0 - SMARC_I2C_GP is enabled
* 1 - I3C is enabled
@@ -37,6 +41,7 @@ aliases {
ethernet0 = ð0;
ethernet1 = ð1;
i2c0 = &i2c0;
+ mmc0 = &sdhi0;
};
memory@48000000 {
@@ -63,6 +68,19 @@ reg_3p3v: regulator-3p3v {
regulator-always-on;
};
+#if SW_SD0_DEV_SEL
+ vqmmc_sd0_pvdd: vqmmc-sd0-pvdd {
+ compatible = "regulator-gpio";
+ regulator-name = "SD0_PVDD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&pinctrl RZG3L_GPIO(L, 4) GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+ states = <3300000 0>, <1800000 1>;
+ regulator-ramp-delay = <1200>;
+ };
+#endif
+
x2_clk: x2-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -216,7 +234,100 @@ i2c0_pins: i2c0 {
pinmux = <RZG3L_PORT_PINMUX(L, 2, 4)>, /* RIIC0_SCL */
<RZG3L_PORT_PINMUX(L, 3, 4)>; /* RIIC0_SDA */
};
+
+ sd0-pwr-en-hog {
+ gpio-hog;
+ gpios = <RZG3L_GPIO(5, 1) GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "sd0_pwr_en";
+ };
+
+ sdhi0_emmc_pins: sd0-emmc {
+ sd0-ctrl {
+ pins = "SD0_CLK", "SD0_CMD";
+ power-source = <1800>;
+ };
+
+ sd0-data {
+ pins = "SD0_DAT0", "SD0_DAT1", "SD0_DAT2", "SD0_DAT3",
+ "SD0_DAT4", "SD0_DAT5", "SD0_DAT6", "SD0_DAT7";
+ power-source = <1800>;
+ };
+
+ sd0-rst {
+ pins = "SD0_RST#";
+ power-source = <1800>;
+ };
+
+ sd0-ds {
+ pins = "SD0_DS";
+ power-source = <1800>;
+ };
+ };
+
+ sdhi0_usd_pins: sd0-usd {
+ sd0-cd {
+ pinmux = <RZG2L_PORT_PINMUX(5, 0, 8)>; /* SD0_CD */
+ };
+
+ sd0-ctrl {
+ pins = "SD0_CLK", "SD0_CMD";
+ power-source = <3300>;
+ };
+
+ sd0-data {
+ pins = "SD0_DAT0", "SD0_DAT1", "SD0_DAT2", "SD0_DAT3";
+ power-source = <3300>;
+ };
+ };
+
+ sdhi0_usd_uhs_pins: sd0-usd-uhs {
+ sd0-cd {
+ pinmux = <RZG2L_PORT_PINMUX(5, 0, 8)>; /* SD0_CD */
+ };
+
+ sd0-ctrl {
+ pins = "SD0_CLK", "SD0_CMD";
+ power-source = <1800>;
+ };
+
+ sd0-data {
+ pins = "SD0_DAT0", "SD0_DAT1", "SD0_DAT2", "SD0_DAT3";
+ power-source = <1800>;
+ };
+ };
+};
+
+#if (SW_SD0_DEV_SEL)
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_usd_pins>;
+ pinctrl-1 = <&sdhi0_usd_uhs_pins>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <&vqmmc_sd0_pvdd>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+#else
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_emmc_pins>;
+ pinctrl-1 = <&sdhi0_emmc_pins>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ fixed-emmc-driver-type = <1>;
+ status = "okay";
};
+#endif
&wdt0 {
timeout-sec = <60>;
--
2.43.0
^ permalink raw reply related
* [PATCH v18 2/4] arm64: dts: renesas: r9a08g046: Add SDHI nodes for RZ/G3L SoC and SDHI1 pincontrol on SMARC EVK
From: Biju @ 2026-06-22 16:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260622164819.184674-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add device tree nodes for the three SDHI controllers (SDHI{0,1,2})
on the RZ/G3L SoC (r9a08g046) and enable SDHI1 on the RZ/G3L SMARC
EVK platform with pincontrol and GPIO-based voltage switching
regulator support.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v17->v18:
* No change.
* This patch depend on [1]
[1] https://lore.kernel.org/all/20260622155610.184271-2-biju.das.jz@bp.renesas.com/
v1->v17:
* No change.
---
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 73 ++++++++++++++-
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 88 +++++++++++++++++++
2 files changed, 160 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
index c63a857f0e5b..ff2de3f192b5 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
@@ -762,9 +762,80 @@ dmac: dma-controller@11820000 {
dma-channels = <16>;
};
+ sdhi0: mmc@11c00000 {
+ compatible = "renesas,sdhi-r9a08g046";
+ reg = <0x0 0x11c00000 0 0x10000>;
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_SDHI0_IMCLK>,
+ <&cpg CPG_MOD R9A08G046_SDHI0_CLK_HS>,
+ <&cpg CPG_MOD R9A08G046_SDHI0_IMCLK2>,
+ <&cpg CPG_MOD R9A08G046_SDHI0_IACLKS>,
+ <&cpg CPG_MOD R9A08G046_SDHI0_IACLKM>;
+ clock-names = "core", "clkh", "cd", "aclk", "aclkm";
+ max-frequency = <150000000>;
+ resets = <&cpg R9A08G046_SDHI0_IXRST>,
+ <&cpg R9A08G046_SDHI0_IXRSTAXIM>,
+ <&cpg R9A08G046_SDHI0_IXRSTAXIS>;
+ reset-names = "rst", "axim", "axis";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
sdhi1: mmc@11c10000 {
+ compatible = "renesas,sdhi-r9a08g046";
reg = <0x0 0x11c10000 0 0x10000>;
- /* placeholder */
+ interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_SDHI1_IMCLK>,
+ <&cpg CPG_MOD R9A08G046_SDHI1_CLK_HS>,
+ <&cpg CPG_MOD R9A08G046_SDHI1_IMCLK2>,
+ <&cpg CPG_MOD R9A08G046_SDHI1_IACLKS>,
+ <&cpg CPG_MOD R9A08G046_SDHI1_IACLKM>;
+ clock-names = "core", "clkh", "cd", "aclk", "aclkm";
+ max-frequency = <150000000>;
+ resets = <&cpg R9A08G046_SDHI1_IXRST>,
+ <&cpg R9A08G046_SDHI1_IXRSTAXIM>,
+ <&cpg R9A08G046_SDHI1_IXRSTAXIS>;
+ reset-names = "rst", "axim", "axis";
+ power-domains = <&cpg>;
+ status = "disabled";
+
+ sdhi1_vqmmc: vqmmc-regulator {
+ regulator-name = "SDHI1-VQMMC";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <1200>;
+ status = "disabled";
+ };
+ };
+
+ sdhi2: mmc@11c20000 {
+ compatible = "renesas,sdhi-r9a08g046";
+ reg = <0x0 0x11c20000 0 0x10000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_SDHI2_IMCLK>,
+ <&cpg CPG_MOD R9A08G046_SDHI2_CLK_HS>,
+ <&cpg CPG_MOD R9A08G046_SDHI2_IMCLK2>,
+ <&cpg CPG_MOD R9A08G046_SDHI2_IACLKS>,
+ <&cpg CPG_MOD R9A08G046_SDHI2_IACLKM>;
+ clock-names = "core", "clkh", "cd", "aclk", "aclkm";
+ max-frequency = <150000000>;
+ resets = <&cpg R9A08G046_SDHI2_IXRST>,
+ <&cpg R9A08G046_SDHI2_IXRSTAXIM>,
+ <&cpg R9A08G046_SDHI2_IXRSTAXIS>;
+ reset-names = "rst", "axim", "axis";
+ power-domains = <&cpg>;
+ status = "disabled";
+
+ sdhi2_vqmmc: vqmmc-regulator {
+ regulator-name = "SDHI2-VQMMC";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <1200>;
+ status = "disabled";
+ };
};
eth0: ethernet@11c30000 {
diff --git a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
index 5289efd1a430..0b6b7e109200 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
@@ -14,6 +14,7 @@
#define SW_GPIO4 1
#define SW_I3C_EN 0
#define SW_SER0_PMOD 1
+#define SW_SDIO_M2E 0
#define PMOD_GPIO4 0
#define PMOD_GPIO6 0
@@ -38,6 +39,7 @@ / {
aliases {
i2c2 = &i2c2;
i2c3 = &i2c3;
+ mmc1 = &sdhi1;
serial0 = &rsci2;
serial1 = &rsci3;
serial2 = &rsci1;
@@ -69,6 +71,19 @@ codec_dai: codec {
};
};
#endif
+
+#if RZ_BOOT_MODE3
+ vqmmc_sd1_pvdd: regulator-vqmmc-sd1-pvdd {
+ compatible = "regulator-gpio";
+ regulator-name = "SD1_PVDD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&pinctrl RZG3L_GPIO(J, 1) GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+ states = <3300000 0>, <1800000 1>;
+ regulator-ramp-delay = <1200>;
+ };
+#endif
};
&i2c2 {
@@ -175,6 +190,68 @@ scif0_pins: scif0 {
power-source = <1800>;
};
+#if RZ_BOOT_MODE3
+ sd1-pwr-en-hog {
+ gpio-hog;
+ gpios = <RZG3L_GPIO(J, 2) GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "sd1_pwr_en";
+ };
+#endif
+
+ sdhi1_pins: sd1 {
+ sd1-cd {
+ pinmux = <RZG3L_PORT_PINMUX(J, 0, 8)>; /* SD1_CD */
+ };
+
+ sd1-clk {
+ pinmux = <RZG3L_PORT_PINMUX(G, 0, 1)>; /* SD1_CLK */
+ power-source = <3300>;
+ };
+
+ sd1-cmd {
+ pinmux = <RZG3L_PORT_PINMUX(G, 1, 1)>; /* SD1_CMD */
+ input-enable;
+ power-source = <3300>;
+ bias-pull-up;
+ };
+
+ sd1-data {
+ pinmux = <RZG3L_PORT_PINMUX(G, 2, 1)>, /* SD1_DAT0 */
+ <RZG3L_PORT_PINMUX(G, 3, 1)>, /* SD1_DAT1 */
+ <RZG3L_PORT_PINMUX(G, 4, 1)>, /* SD1_DAT2 */
+ <RZG3L_PORT_PINMUX(G, 5, 1)>; /* SD1_DAT3 */
+ input-enable;
+ power-source = <3300>;
+ };
+ };
+
+ sdhi1_uhs_pins: sd1-uhs {
+ sd1-cd {
+ pinmux = <RZG3L_PORT_PINMUX(J, 0, 8)>; /* SD1_CD */
+ };
+
+ sd1-clk {
+ pinmux = <RZG3L_PORT_PINMUX(G, 0, 1)>; /* SD1_CLK */
+ power-source = <1800>;
+ };
+
+ sd1-cmd {
+ pinmux = <RZG3L_PORT_PINMUX(G, 1, 1)>; /* SD1_CMD */
+ input-enable;
+ power-source = <1800>;
+ };
+
+ sd1-data {
+ pinmux = <RZG3L_PORT_PINMUX(G, 2, 1)>, /* SD1_DAT0 */
+ <RZG3L_PORT_PINMUX(G, 3, 1)>, /* SD1_DAT1 */
+ <RZG3L_PORT_PINMUX(G, 4, 1)>, /* SD1_DAT2 */
+ <RZG3L_PORT_PINMUX(G, 5, 1)>; /* SD1_DAT3 */
+ input-enable;
+ power-source = <1800>;
+ };
+ };
+
ssi0_pins: ssi0 {
pinmux = <RZG3L_PORT_PINMUX(H, 0, 9)>, /* SSIF0_RXD */
<RZG3L_PORT_PINMUX(H, 1, 9)>, /* SSIF0_BCK */
@@ -230,6 +307,17 @@ &scif0 {
pinctrl-names = "default";
};
+#if RZ_BOOT_MODE3
+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-1 = <&sdhi1_uhs_pins>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <&vqmmc_sd1_pvdd>;
+};
+#endif
+
#if !SW_SD2_EN
&ssi0 {
clocks = <&cpg CPG_MOD R9A08G046_SSI0_PCLK2>,
--
2.43.0
^ permalink raw reply related
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