* 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/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 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 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
* [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 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
* 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 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: [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
* [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
* [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 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 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
* 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
* 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
* [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 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
* 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 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 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 v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-22 18:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Nuno Sá, Rodrigo Alencar, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622172911.48259a0c@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
On Mon, Jun 22, 2026 at 05:29:11PM +0100, Jonathan Cameron wrote:
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > > >
> > >
> > > If the device-addressing on the same chip-select is to be handled
> > > by the spi framework, wouldn't we lose device-specific features?
> > >
> > > I understand that this multi-device feature is there mostly to extend the
> > > channel count from 16 to 32, 48 or 64. I suppose the command:
> > >
> > > "MULTI DEVICE SW LDAC MODE"
> > >
> > > exists so that software can update channel values accross multiple devices.
> >
> > Right! You do have a point! I agree the main driver for a feature like
> > this is likely to extend the channel count and effectively "aggregate"
> > devices.
> >
> > But I would say that even with the spi solution the MULTI DEVICE stuff
> > should be doable (as we still need a sort of adi,pin-id property).
> >
> > But yes, I do feel that the whole feature is for aggregation so seeing
> > one device with 32 channels is the expectation here? Rather than seeing
> > two devices with 16 channels.
>
> Agreed - if we have messages that address both devices at once that needs
> to be a unified driver and given they are about triggering simultaneous
> update of all channels it needs to look like one big device.
> This ends up similar to how we handle daisy chain devices.
>
> The question of what to do on devices that don't have this feature
> is rather different. Good thing you read the datasheet :)
I'm not sure it really is, the intent for the microchip devices I think
is pretty similar. The mcp3911 datasheet cites three-phase power
metering using three devices as a typical use-case, for example.
Probably creating an amalgamated device is a good fit there too?
I assume an amalgamated device for this ADI product means per-channel ID
properties? If so, I think they should be made generic and the Microchip
products retrofitted to use them, with a fallback to the proprietary
property. Not going to ask for the support for multiple devices in those
drivers, since the current way doesn't work and there'd be no loss of
support. Someone from Microchip can do that. The proprietary property
to generic conversion should be straightforward and provides weight to
an argument for this being generic, since that'd be three devices that
can all share?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/2] Add support for StarFive JHB100 SPI
From: Mark Brown @ 2026-06-19 17:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Changhuang Liang
Cc: linux-spi, linux-kernel, devicetree
In-Reply-To: <20260619143443.22267-1-changhuang.liang@starfivetech.com>
On Fri, 19 Jun 2026 07:34:41 -0700, Changhuang Liang wrote:
> Add support for StarFive JHB100 SPI
>
> The StarFive JHB100 SPI is based on the Synopsys DesignWare SSI version 2.00.
>
> changes since v1:
> PATCH 1:
> - Add "starfive,jhb100-spi" and support falling back to
> "snps,dwc-ssi-2.00a" or "snps,dwc-ssi-1.01a".
> - using subject lines reflecting the style for the
> spi subsystem.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2
Thanks!
[1/2] spi: dt-bindings: snps,dw-apb-ssi: Add starfive,jhb100-spi
https://git.kernel.org/broonie/spi/c/07f251e0ed0b
[2/2] spi: dw: Add support for snps,dwc-ssi-2.00a
https://git.kernel.org/broonie/spi/c/914e708e3049
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-22 18:46 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
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>
---
Changes in v2:
- Fix coding style (blank line, interrupts-extended, property order,
drop output-high)
- Correct voltage constraints for ldo1 and ldo2
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 93 +++++++++++++++++++
1 file changed, 93 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..c514478cba4f 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -571,6 +571,82 @@ fuel-gauge@55 {
};
};
+&i2c15 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ pm8008: pmic@8 {
+ compatible = "qcom,pm8008";
+ reg = <0x8>;
+
+ 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-0 = <&pm8008_default>;
+ pinctrl-names = "default";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8008 0 0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ regulators {
+ vreg_l1p: ldo1 {
+ regulator-name = "vreg_l1p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l2p: ldo2 {
+ regulator-name = "vreg_l2p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l3p: ldo3 {
+ regulator-name = "vreg_l3p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l4p: ldo4 {
+ regulator-name = "vreg_l4p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l5p: ldo5 {
+ regulator-name = "vreg_l5p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l6p: ldo6 {
+ regulator-name = "vreg_l6p";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vreg_l7p: ldo7 {
+ regulator-name = "vreg_l7p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2900000>;
+ };
+ };
+ };
+};
+
&i2c11 {
clock-frequency = <400000>;
status = "okay";
@@ -801,6 +877,23 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ 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>;
+ };
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: sm8250-xiaomi-elish: add ov8856 front camera
From: Xin Xu @ 2026-06-22 18:52 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
powered by pm8008 LDOs and other supplies.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v2:
- Fix coding style (property order)
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 70 +++++++++++++++++++
1 file changed, 70 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 c514478cba4f..262cb9f29ebc 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/usb/pd.h>
@@ -531,6 +532,61 @@ vreg_l7f_1p8: ldo7 {
};
};
+&camss {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+
+ ports {
+ port@4 {
+ csiphy4_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&ov8856_front_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera_front: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ avdd-supply = <&vreg_l5p>;
+ dovdd-supply = <&vreg_l1c_1p8>;
+ dvdd-supply = <&vreg_l1p>;
+
+ clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ clock-names = "xvclk";
+ assigned-clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&mclk3_active &camera_front_active>;
+ pinctrl-names = "default";
+
+ orientation = <0>; /* Front facing */
+ rotation = <270>;
+
+ port {
+ ov8856_front_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64
+ <720000000 360000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
&cdsp {
firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
status = "okay";
@@ -877,6 +933,20 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ camera_front_active: camera-front-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ mclk3_active: mclk3-active-state {
+ pins = "gpio97";
+ function = "cam_mclk";
+ bias-disable;
+ drive-strength = <4>;
+ };
+
pm8008_default: pm8008-default-state {
int-pins {
pins = "gpio84";
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
Hi all,
After submitting a patch series adding support for TI ADS126X ADCs [1],
I was made aware by David [2] that at least two more chip families,
ads1220 [3] and ads1x2c14, share very similar features (though these
chips are not really compatible between them). After that, I found one
more chip with the same features which is already upstream, the
AD4170-4.
As David explained in [2], these chips are intended to be used with
RTDs, thermocouples or other resistive sensors so they share the
following per-channel features:
- Configurable reference selection
- Burn-out Current Sources (BOCS) for diagnostic purpuses
- Excitation current sources (usually called IDACs TI) for sensor
current biasing
Given that these three features are present in all four devices and
three of these drivers are still under review, my proposal is to have
these features be described in adc.yaml and have this series merged
before the three others [1] [2] [3].
This series is sent as RFC because I still don't have much experience
with dt-bindings and I don't know if this approach or the properties are
general enough to be described like this.
No dependencies between properties were provided because not all devices
may be able to configure each one of them.
[1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
[2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
[3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
v2:
- reference-source is now a string-array and now presents a couple of
quick examples
- excitation-* properties now do not enforce arbitrary limits
- Dropped burn-out-current-polarity because it was not general enough
- I kept burn-out-current-microamp because the discussion around it is
still ongoing
v1: https://patch.msgid.link/20260618-new-channel-props-v1-0-963c1b5cf40a@gmail.com
---
Kurt Borja (3):
dt-bindings: iio: adc: Add reference-source property
dt-bindings: iio: adc: Add excitation current sources properties
dt-bindings: iio: adc: Add burn-out current properties
Documentation/devicetree/bindings/iio/adc/adc.yaml | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260618-new-channel-props-4fbd52020da2
--
Thanks,
~ Kurt
^ 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