* Re: [PATCH 4/4] iio: adc: ti-ads112c14: add measurement channel support
From: Andy Shevchenko @ 2026-06-17 10:16 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <e1e6a5f3-4cf3-4454-ab73-a45ae7b77116@baylibre.com>
On Tue, Jun 16, 2026 at 10:55:34AM -0500, David Lechner wrote:
> On 6/16/26 3:36 AM, Andy Shevchenko wrote:
> > On Mon, Jun 15, 2026 at 05:00:02PM -0500, David Lechner (TI) wrote:
...
> >> + if (fwnode_property_present(child, "single-channel")) {
> >> + ret = fwnode_property_read_u32(child, "single-channel", &spec->channel);
> >> + if (ret)
> >> + return dev_err_probe(dev, ret,
> >> + "failed to read single-channel property\n");
> >> +
> >> + if (spec->channel >= 8)
> >> + return dev_err_probe(dev, -EINVAL,
> >> + "single-channel value must be between 0 and 7\n");
> >> + } else if (fwnode_property_present(child, "diff-channels")) {
> >> + ret = fwnode_property_read_u32_array(child, "diff-channels", pair, ARRAY_SIZE(pair));
> >> + if (ret)
> >> + return dev_err_probe(dev, ret,
> >> + "failed to read diff-channels property\n");
> >> +
> >> + if (pair[0] >= 8 || pair[1] >= 8)
> >> + return dev_err_probe(dev, -EINVAL,
> >> + "diff-channels values must be between 0 and 7\n");
> >> +
> >> + spec->channel = pair[0];
> >> + spec->channel2 = pair[1];
> >> + spec->differential = 1;
> >> + } else {
> >> + return dev_err_probe(dev, -EINVAL,
> >> + "channel node missing channel type property\n");
> >> + }
> >
> > Looking how it's going to spread (I mean the above pattern), perhaps it's a time to introduce bunch of
> >
> > fwnode_property_read_*_optional()
> >
> > and the respective device_property_read_*_optional()?
> >
> > Let's start from u32 case only, as it will be most used anyway.
>
> I don't think that would be really any different from device_property_read_*
> and checking for -EINVAL or ignoring the error completely. TBH, I really like
> it this way with fwnode_property_present().
Yeah, it's explicit, but with _optional() we may simply have
propname = "single-channel";
ret = fwnode_property_read_u32_optional(child, propname, &spec->channel, 0);
if (ret)
return dev_err_probe(dev, ret, "failed to read %s property\n", propname);
if (spec->channel >= 8)
return dev_err_probe(dev, -EINVAL, "%s value must be between 0 and 7\n", propname);
However I admit that in the above case you also want to distinguish the cases.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Fenglin Wu @ 2026-06-17 10:12 UTC (permalink / raw)
To: Konrad Dybcio, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <29806448-0588-4590-8540-a689ccf1e7b0@oss.qualcomm.com>
On 6/17/2026 5:30 PM, Konrad Dybcio wrote:
> On 6/17/26 4:31 AM, Fenglin Wu wrote:
>>>> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>>> +
>>>> + for (; i < len; i++) {
>>>> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>> So if i'm reading this right, the first loop will always write
>>> 4*(len//4) bytes and the second one will be entered at most once,
>>> to write len rem 4 bytes.. should this be an if instead?
>> I should put a comment for clarification. Here’s some background: FIFO data writing supports both 4-byte bulk writes using registers [HAP_PTN_FIFO_DIN_0_REG ... HAP_PTN_FIFO_DIN_3_REG], and 1-byte writes using the HAP_PTN_FIFO_DIN_1B_REG register. The 4-byte bulk write is more efficient, especially for waveform which has several Kb data, and it helps to reduce software latency when loading effects and reduce the delay in triggering vibration. It also helps prevent the FIFO from running dry during data refill in FIFO-empty interrupts. Typically, we use 4-byte writes for the initial 4-byte aligned data, and 1-byte writes for any trailing remainder.
>>
>> So it still needs a 'for' loop here since the remainder could be more than 1 byte.
> Right, I mentioned len rem 4 but failed to notice it's a
> single-byte write.. anyway, a comment here would be good
>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Configure the hardware FIFO memory boundary.
>>>> + * FIFO occupies addresses [0, fifo_len).
>>>> + */
>>>> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
>>>> +{
>>>> + u32 fifo_len, fifo_units;
>>>> +
>>>> + /* Config all memory space for FIFO usage for now */
>>> What's the not-"for now" endgame for this?
>> The hardware supports more modes than the two currently supported in the driver. One of these, called 'PAT_MEM' mode, also shares memory space with FIFO mode. However, 'PAT_MEM' requires memory to be pre-reserved and waveform data to be pre-loaded. The entire 8K bytes of memory can be divided into partitions, and it is configurable, with FIFO mode always using the first partition [0, fifo_len], where 'fifo_len' is set via the 'MMAP_FIFO_REG' register. 'PAT_MEM' mode plays waveform using data preloaded in a memory bank defined by the registers 'PATX_MEM_START_ADDR_REG' and 'PATTERN_SPMI_PATX_LEN_REG' (they are not defined in the driver). Since PAT_MEM is mainly intended for hardware-triggered vibrations, such as a signal from a dedicated GPIO triggering a short vibration with a preloaded waveform, and although it also supports software triggers, I haven't found a suitable way to support it well into the driver under input FF framework yet. So, I am currently allocating the
>> entire 8K FIFO memory for FIFO mode only. We can adjust this later if we find a better way to incorporate 'PAT_MEM' mode into the driver.
> Sounds like a plan.
>
> For the other mode, would that GPIO trigger need any OS intervention?
> Could you speak a bit more about how that works?
>
> Konrad
I'll try to clarify the 'PAT_MEM' mode further. 'PAT_MEM' is useful for
latency-sensitive vibrations because it preloads the waveform into a
fixed memory bank, then it doesn't need to load the data of the effect
in the HW before triggering the play. When playback is triggered, it
plays the waveform from the specified memory address and length. This
memory should be preserved, and the data is preloaded during boot.
Unlike FIFO mode, it doesn't allow data refilling. The trigger can come
from hardware via dedicated GPIOs—currently, three are supported, each
mapping to a memory bank set through specific registers. Software
configuration can be done in the bootloader or in the driver probe, but
the 'fifo_len' should be adjusted accordingly. After setup, software
doesn't need to manage it further, relying on the GPIO signal to
activate the playback (for example, a pressure sensor triggering
vibration to simulate a physical key press). The trigger can also come
from software using SPMI commands by setting the play mode, start
address, and data length. I previously tried using the 'FF_HAPTIC'
effect by mapping 'hid_usage' to a predefined effect in the devicetree,
but later I found it unsuitable since 'FF_HAPTIC' is mainly for USB HID
touch devices and not general vibration usage. If you have any
suggestions for supporting 'PAT_MEM' mode through the input FF
framework, please let me know.
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: Add header file for ADC5 Gen3 channel macros
From: Neil Armstrong @ 2026-06-17 10:12 UTC (permalink / raw)
To: Konrad Dybcio, Jishnu Prakash, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ayyagari Ushasreevalli,
Kamal Wadhwa
In-Reply-To: <bae5b5be-16a9-4581-9863-4ca4eca88754@oss.qualcomm.com>
On 6/15/26 18:48, Konrad Dybcio wrote:
> On 6/15/26 6:39 PM, Neil Armstrong wrote:
>> Hi,
>>
>> On 6/15/26 17:55, Konrad Dybcio wrote:
>>> On 4/30/26 10:58 AM, Jishnu Prakash wrote:
>>>> Add macro definitions for virtual channels (combination of ADC channel
>>>> number and PMIC SID number), to be used in devicetree by clients of ADC5
>>>> GEN3 device and in the "reg" property of ADC channels.
>>>>
>>>> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
>>>> ---
>>>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> And what happens with my patch [1] ?
>>
>> I had zero feedback so far
>>
>> [1] https://lore.kernel.org/all/20260504-topic-sm8x50-adc5-gen3-v2-1-5cc04d6ecda0@linaro.org/
>
> I think this approach (single generic header) is better. The existing
> ADC7 bindings which your series draws inspiration from come with a ton
> of boilerplate.
>
> There are some non-trivial mappings in there though, e.g.:
>
> +#define PM8550B_ADC5_GEN3_AMUX4_GPIO12_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_100K_PU)
>
> but these would presumably be deducible from downstream
I'll try to rebase on this patch, seems all the values are defined, I just need to match the old and new defines
Neil
>
> Konrad
^ permalink raw reply
* Re: [PATCH v9 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Konrad Dybcio @ 2026-06-17 10:11 UTC (permalink / raw)
To: Stanislav Zaikin, devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, dmitry.baryshkov
In-Reply-To: <3bc5c1f5-8994-48b7-a376-39afc7e429e4@gmail.com>
On 6/17/26 9:55 AM, Stanislav Zaikin wrote:
> On 6/16/26 12:01 PM, Konrad Dybcio wrote:
>> On 6/8/26 4:33 PM, Stanislav Zaikin wrote:
>>> Xiaomi 12 Lite 5G is a handset released in 2022
>>>
>>> This commit has the following features working:
>>> - Display (with simple fb)
>>> - Touchscreen
>>> - UFS
>>> - Power and volume buttons
>>> - Pinctrl
>>> - RPM Regulators
>>> - Remoteprocs - wifi, bluetooth
>>> - USB (Device Mode)
>>>
>>> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
>>> ---
>>
>> [...]
>>
>>> +&ipa {
>>> + firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
>>> +
>>> + status = "okay";
>>> +};
>>
>> From make dtbs_check:
>>
>> qcom/sm7325-xiaomi-taoyao.dtb: ipa@1e40000 (qcom,sc7280-ipa): 'memory-region' is a required property
>>
>> Please fix that (or disable IPA)
>>
>> Otherwise:
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Konrad
>
> Thank you for the review.
>
> This patch depends on [0]. With [0] patch applied, dtbs_check passes w/o warnings.
>
> [0] https://lore.kernel.org/all/20260517-ipa-loader-v1-6-3c3764c1b4a3@oss.qualcomm.com/
Ah, I see, thank you
Konrad
^ permalink raw reply
* [PATCH v3] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-17 10:10 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 SPI controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v2:
- Add cs-gpios to required property
Link to v2: https://lore.kernel.org/all/20260615115311.515404-1-challauday369@gmail.com/
Changes since v1:
- Rename schema file to microchip,pic32mzda-spi.yaml
- Update subject prefix to match SPI DT binding conventions
Link to v1:https://lore.kernel.org/all/20260614175005.435826-1-challauday369@gmail.com/
---
.../bindings/spi/microchip,pic32mzda-spi.yaml | 82 +++++++++++++++++++
.../bindings/spi/microchip,spi-pic32.txt | 34 --------
2 files changed, 82 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
new file mode 100644
index 000000000000..4669b521fa1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/microchip,pic32mzda-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA SPI Controller
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Fault interrupt
+ - description: Receive interrupt
+ - description: Transmit interrupt
+
+ interrupt-names:
+ items:
+ - const: fault
+ - const: rx
+ - const: tx
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mck0
+
+ cs-gpios:
+ maxItems: 1
+
+ dmas:
+ items:
+ - description: RX DMA channel
+ - description: TX DMA channel
+
+ dma-names:
+ items:
+ - const: spi-rx
+ - const: spi-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - cs-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi@1f821000 {
+ compatible = "microchip,pic32mzda-spi";
+ reg = <0x1f821000 0x200>;
+ interrupts = <109 IRQ_TYPE_LEVEL_HIGH>,
+ <110 IRQ_TYPE_LEVEL_HIGH>,
+ <111 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "fault", "rx", "tx";
+ clocks = <&PBCLK2>;
+ clock-names = "mck0";
+ cs-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
+ dmas = <&dma 134>, <&dma 135>;
+ dma-names = "spi-rx", "spi-tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt b/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
deleted file mode 100644
index 79de379f4dc0..000000000000
--- a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Microchip PIC32 SPI Master controller
-
-Required properties:
-- compatible: Should be "microchip,pic32mzda-spi".
-- reg: Address and length of register space for the device.
-- interrupts: Should contain all three spi interrupts in sequence
- of <fault-irq>, <receive-irq>, <transmit-irq>.
-- interrupt-names: Should be "fault", "rx", "tx" in order.
-- clocks: Phandle of the clock generating SPI clock on the bus.
-- clock-names: Should be "mck0".
-- cs-gpios: Specifies the gpio pins to be used for chipselects.
- See: Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
-- dmas: Two or more DMA channel specifiers following the convention outlined
- in Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: Names for the dma channels. There must be at least one channel
- named "spi-tx" for transmit and named "spi-rx" for receive.
-
-Example:
-
-spi1: spi@1f821000 {
- compatible = "microchip,pic32mzda-spi";
- reg = <0x1f821000 0x200>;
- interrupts = <109 IRQ_TYPE_LEVEL_HIGH>,
- <110 IRQ_TYPE_LEVEL_HIGH>,
- <111 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "fault", "rx", "tx";
- clocks = <&PBCLK2>;
- clock-names = "mck0";
- cs-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
- dmas = <&dma 134>, <&dma 135>;
- dma-names = "spi-rx", "spi-tx";
-};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/4] iio: adc: add ti-ads112c14 driver
From: Andy Shevchenko @ 2026-06-17 10:07 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <12831fd9-8a6f-442e-b1ca-f39248a5baf0@baylibre.com>
On Tue, Jun 16, 2026 at 10:38:05AM -0500, David Lechner wrote:
> On 6/16/26 2:32 AM, Andy Shevchenko wrote:
> > On Mon, Jun 15, 2026 at 05:00:00PM -0500, David Lechner (TI) wrote:
...
> >> + if (ret != -EREMOTEIO)
> >> + return ret;
> >
> > I would do it separately as
> >
> > if (ret == -EREMOTEIO)
> > /* ...big comment here... */
> > return 0;
What I meant here is
ret = 0;
Sorry for the confusion.
> We should not return early here. We just continue with the rest
> of the function as normal. So I think the way I had it was
> simplest. Otherwise we would need a goto or something like that.
>
>
> > if (ret) // which is regular pattern and doesn't need any comment.
> > return ret;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 5/5] clk: renesas: r9a09g077: Add LCDC and PLL3 clock support for RZ/T2H display pipeline
From: Geert Uytterhoeven @ 2026-06-17 10:06 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the clock definitions and PLL logic required to supply the LCDC
> (VSPD/FCPVD/DU) blocks on the RZ/T2H (R9A09G077) SoC. The RZ/T2H display
> subsystem depends on a dedicated PLL (PLL3) and a set of new derived
> clocks.
>
> Introduce a new PLL clock type and implement rate recalculation,
> programming and locking sequences for PLL3 using the RZ/T2H specific
> divider and VCO limits. Add the corresponding muxes and divider entries,
> expose the LCDC core clock, and register the LCDC module clock using the
> correct PCLK parent.
>
> This enables the RZ/T2H clock driver to generate the display pipeline
> clocking tree needed by the DU and VSP-based composition engines, allowing
> upcoming display support to be integrated without duplicating CPG logic.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v2->v3:
> - In r9a09g077_cpg_lcdc_div_determine_rate() made use of
> clk_hw_get_parent_by_index() to ensure we retrieve pll3 as the parent.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
From: Andy Shevchenko @ 2026-06-17 10:05 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij,
linux-iio, linux-kernel, llvm, devicetree
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-3-063edcf74e60@herrie.org>
On Tue, Jun 16, 2026 at 03:02:06PM +0200, Herman van Hazendonk wrote:
> The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
> highest-sensitivity full-scale supported by the chip -- as the
> starting range. For the LSM303DLH that is +/-1.3 G; for the
> LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
>
> That is the right default for "minimal noise floor at a desk", but
> it leaves no margin for boards that pick up appreciable DC bias from
> nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
> LSM303DLH magnetometer is mounted close enough to the surrounding
> power planes that X reads back as the chip's 0xF000 overflow
> sentinel (== -4096 raw, the value the chip publishes when the ADC
> saturates) on every sample at the chip-default range, while Y and Z
> fall well within the +/-1.3 G window.
>
> Parse the st,fullscale-milligauss device-tree property (documented
> separately in dt-bindings/iio/st,st-sensors.yaml) in the
> magnetometer common probe to select the initial fs_avl entry by its
> mg value. The DT binding pins the accepted value set per compatible
> via allOf/if-then enum clauses, so a malformed mg value fails
> dt_binding_check rather than reaching the driver. Sensors with a
> fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
> register to switch and the property is rejected outright for them
> in the binding; the parse block is additionally gated on fs.addr as
> defence in depth against stale DTBs.
>
> Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
> LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
> 4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
> they are 4000, 8000, 12000, 16000.
>
> Empirical scale sweep on the HP TouchPad confirmed that on this
> board any fs_avl >= 1 produces non-saturated X readings:
>
> scale (0.001 G/LSB) | X raw Y raw Z raw
> --------------------+-------------------------------
> 1.100 | -4096 44 46 (X saturated)
> 0.855 | -547 37 37 (clean)
> 0.670 | -433 94 103 (clean)
> 0.450 | -266 44 71 (clean)
> 0.400 | -235 34 65 (clean)
> 0.330 | -196 27 56 (clean)
> 0.230 | -145 15 40 (clean)
>
> 2500 mg is the natural choice for tenderloin: comfortably outside
> the saturation regime while keeping useful precision for compass
> applications.
Not sure if we need that big commit message, better to move to the point.
> + propname = "st,fullscale-milligauss";
> + if (mdata->sensor_settings->fs.addr &&
> + device_property_present(parent, propname)) {
> + struct st_sensor_fullscale *fs = &mdata->sensor_settings->fs;
> + u32 fs_mg;
> + int i;
Instead...
> + err = device_property_read_u32(parent, propname, &fs_mg);
> + if (err)
> + return err;
> + for (i = 0; i < ST_SENSORS_FULLSCALE_AVL_MAX; i++) {
for (unsigned int i = 0; i < ST_SENSORS_FULLSCALE_AVL_MAX; i++) {
> + if (!fs->fs_avl[i].num)
> + break;
> + if (fs->fs_avl[i].num == fs_mg) {
> + mdata->current_fullscale = &fs->fs_avl[i];
> + break;
> + }
> + }
> + if (mdata->current_fullscale->num != fs_mg)
> + dev_warn(parent, "%s=%u not supported, using %u\n",
> + propname, fs_mg,
> + mdata->current_fullscale->num);
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-06-17 9:54 UTC (permalink / raw)
To: Michael Walle, Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <DJB6XO07EC8Q.1X9P752MLFB4N@kernel.org>
Hi Michael,
> Hi,
>
> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] wrote:
>>>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to
>>>>>> fulfill these requirements in our
>>>>>> map() function.
>>>
>>> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>>> only called if the irq handling is set up via gc->irq.chip and not
>>> via
>>> gpiochip_irqchip_add_domain() like in gpio-regmap?
>>>
>>
>> The panic was caused by my driver including
>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>
> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>
> -michael
Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
Additional information: our GPIO controller receives 3 separate interrupt lines.
Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
this multi-line hardware design, we are forced to create our own IRQ domain and pass
it via 'config->irq_domain'.
Given this constraint (that we must use our own IRQ domain), are you suggesting
that we should implement our own 'irq_request_resources' and
'irq_release_resources' callbacks instead of relying on
'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
But if that is the case, we would much prefer to let the core gpiolib handle
these resource and state management tasks for us *as proposed in option 3), rather
than duplicating the effort in our driver.
Best Regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: kodiak: Elite-ify LPASS macros
From: Konrad Dybcio @ 2026-06-17 10:05 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, cros-qcom-dts-watchers
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260522-kodiak-elite-macros-v1-1-487661ac1270@fairphone.com>
On 5/22/26 4:46 PM, Luca Weiss wrote:
> Due to initial kodiak/sc7280 bringup being done for Chrome platforms,
> some Chrome-specific bits still remain in kodiak.dtsi, like the clocks
> and power-domains for the LPASS RX/TX/WSA/VA macros.
>
> Move them to sc7280-chrome-common.dtsi and put Elite (q6afecc)
> equivalents in its place. The qcs6490-audioreach.dtsi file can also drop
> deletion of power-domains properties then.
>
> This follows previous commits moving Chrome-specific configuration to
> the correct file, leaving kodiak.dtsi for Elite and
> qcs6490-audioreach.dtsi for AudioReach.
>
> No functional change intended. The clock-output-names property will now
> exist for both Chrome and AudioReach devices but this shouldn't have any
> relevant effect. And WSA macro clocks weren't added to Chrome because I
> don't believe this would've ever worked given it already referenced
> q6afecc and the nodes were originally added during AudioReach bringup.
I think it's better to keep them, if only to make sure that the result
of dtx_diff isn't outside the expectation of a commit that claims to
only reshuffle data for these platforms
It looks OK as-is for Elite and Audioreach platforms (for the record, I
checked rb3gen2 and FP5)
Konrad
^ permalink raw reply
* Re: [PATCH v3 4/5] clk: renesas: rzv2h-cpg: Extract PLL calculation math into a library
From: Geert Uytterhoeven @ 2026-06-17 10:04 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-5-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Move the common PLL and divider parameter calculation logic from the
> core rzv2h-cpg driver into a standalone library file.
>
> Introduce the CLK_RZV2H_CPG_LIB Kconfig configuration symbol and create
> rzv2h-cpg-lib.c to house rzv2h_cpg_get_pll_pars() and
> rzv2h_cpg_get_pll_divs_pars().
>
> Keep rzv2h_get_pll_pars() and rzv2h_get_pll_divs_pars() in the original
> driver as wrappers that call into the new library helper endpoints.
> These wrappers are maintained for this cycle because they are actively
> referenced by the DSI driver; they will be safely removed in a subsequent
> cycle once the DSI driver is updated to use the new APIs from the library,
> preventing cross-subsystem build breakages.
>
> This restructuring allows other Renesas SoC clock drivers, such as the
> upcoming RZ/T2H and RZ/N2H platforms that utilize similar LCDC clock
> divider mathematical logic, to share the iterative calculation helper
> infrastructure without duplication.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/include/linux/clk/renesas.h
> +++ b/include/linux/clk/renesas.h
> @@ -213,4 +213,27 @@ static inline bool rzv2h_get_pll_divs_pars(const struct rzv2h_pll_limits *limits
> }
> #endif
>
> +#ifdef CONFIG_CLK_RZV2H_CPG_LIB
> +bool rzv2h_cpg_get_pll_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_pars *pars, u64 freq_millihz);
> +
> +bool rzv2h_cpg_get_pll_divs_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_div_pars *pars,
> + const u8 *table, u8 table_size, u64 freq_millihz);
> +#else
> +static inline bool rzv2h_cpg_get_pll_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_pars *pars,
> + u64 freq_millihz)
> +{
> + return false;
> +}
> +
> +static inline bool rzv2h_cpg_get_pll_divs_pars(const struct rzv2h_pll_limits *limits,
> + struct rzv2h_pll_div_pars *pars,
> + const u8 *table, u8 table_size,
> + u64 freq_millihz)
> +{
> + return false;
> +}
> +#endif
> #endif
What about just dropping the old functions, and adding two simple
compatibility defines in the header file:
#define rzv2h_get_pll_pars rzv2h_cpg_get_pll_pars
#define rzv2h_get_pll_divs_pars rzv2h_cpg_get_pll_divs_pars
That way there is less code to change in the next phase.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 06/12] rtc: rzn1: Sort headers alphabetically
From: Wolfram Sang @ 2026-06-17 10:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Prabhakar, Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CAMuHMdXg16frnn88_P_jHRH+HPy00wWfoqNKdOv8teSWNpMEGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
> > --- a/drivers/rtc/rtc-rzn1.c
> > +++ b/drivers/rtc/rtc-rzn1.c
> > @@ -15,8 +15,8 @@
> > #include <linux/clk.h>
> > #include <linux/init.h>
> > #include <linux/iopoll.h>
> > -#include <linux/module.h>
> > #include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
>
> Sorting of special characters w.r.t. alphanumericals is always
> a bit fuzzy...
I rely on the 'sort' utility which gives the same output, so:
> > #include <linux/platform_device.h>
> > #include <linux/pm_runtime.h>
> > #include <linux/rtc.h>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: sashiko-bot @ 2026-06-17 10:04 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260617-mt6323-nvmem-v2-2-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unchecked traversal of device parent pointers causes a NULL pointer dereference.
- [High] Buffer overflow in the NVMEM read callback for unaligned read requests.
--
commit 6d793839a1a7e502029cf9f7b58d011fec9486e7
Author: Roman Vivchar <rva333@protonmail.com>
nvmem: add mt6323 PMIC EFUSE driver
This commit adds support for the EFUSE controller found in the Mediatek
MT6323 PMIC. The MT6323 EFUSE stores 24 bytes of hardware-related data,
such as thermal sensor calibration values.
> diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
> new file mode 100644
> index 0000000000000..7a0ce4c7f5658
> --- /dev/null
> +++ b/drivers/nvmem/mt6323-efuse.c
[ ... ]
> +static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct regmap *map = context;
> + u16 *buf = val;
> + u32 tmp;
> + int ret;
> +
> + /*
> + * A manual loop using regmap_read is required because PWRAP is not
> + * a continuous MMIO space, but rather a FSM that doesn't implement the
> + * necessary read callback for the regmap_read_raw and regmap_read_bulk
> + * functions.
> + */
> + for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
> + ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
> + if (ret)
> + return ret;
> +
> + *buf++ = tmp;
[Severity: High]
What happens if an internal client requests to read an odd number of bytes?
Since this loop unconditionally writes a 16-bit word on each iteration, an odd
bytes length would cause the loop to execute an extra time and write past the
end of the destination buffer. Because nvmem_device_read() does not enforce
word_size alignment on internal requests, this could corrupt adjacent memory
if the caller allocated a buffer matching the exact requested size.
Could the driver explicitly reject unaligned lengths or safely handle partial
word writes?
> + }
> +
> + return 0;
> +}
> +
> +static int mt6323_efuse_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_config config = {
> + .name = "mt6323-efuse",
> + .stride = 2,
> + .word_size = 2,
> + .size = MT6323_EFUSE_SIZE,
> + .reg_read = mt6323_efuse_read,
> + };
> + struct nvmem_device *nvmem;
> + struct regmap *regmap;
> +
> + /* efuse -> mfd -> pwrap */
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
Could this lead to a NULL pointer dereference if the device tree hierarchy
is malformed?
If the device is instantiated at the top level or independently of the
expected MFD and PMIC wrapper structure, dev->parent could map to the
platform bus, making dev->parent->parent NULL. Passing a NULL pointer to
dev_get_regmap() will cause a kernel panic when it attempts to lock the
devres lock.
Would it be safer to verify that dev->parent and dev->parent->parent are
non-NULL before passing the grandparent pointer?
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/3] iio: common: st_sensors: honour channel endianness in read_axis_data
From: Andy Shevchenko @ 2026-06-17 10:02 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij,
linux-iio, linux-kernel, llvm, devicetree, stable
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-1-063edcf74e60@herrie.org>
On Tue, Jun 16, 2026 at 03:02:04PM +0200, Herman van Hazendonk wrote:
> st_sensors_read_axis_data() unconditionally decoded multi-byte
> results with get_unaligned_le16() / get_unaligned_le24() regardless
> of the channel's declared scan_type.endianness.
>
> For every ST sensor that has used this helper since it was introduced
> this happened to be fine because the ST IMU/accel/gyro/pressure
> families publish their data registers as little-endian and the
> channel specs in those drivers declare IIO_LE accordingly.
>
> The LSM303DLH magnetometer however publishes its X/Y/Z output as a
> pair of big-endian bytes (the H register sits at the lower address,
> 0x03/0x05/0x07, and the L register immediately after), and its
> channel specs in st_magn_core.c correctly declare IIO_BE -- but
> read_axis_data() ignored that and decoded as little-endian, swapping
> the high and low bytes of every magnetometer sample. The LSM303DLHC
> and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and
> were therefore byte-swapped by the same bug; users of those parts
> will see different in_magn_*_raw values after this fix lands.
>
> The bug is most visible on a stationary chip: in earth's field the
> true X reading is small and the high byte sits at 0x00, so swapping
> the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0
> = 240). Y and Z still appear "to vary" because their magnitudes are
> larger and the noise in the low byte produces big swings in the
> swapped high byte:
>
> before (LSM303DLH flat, sysfs in_magn_*_raw):
> X=240 (stuck), Y= 12032..23296, Z=-16128..-9728
>
> after (direct i2c-dev big-endian decode, same chip same orientation):
> X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's
> ambient field at low gauss range)
>
> Fix read_axis_data() to dispatch on ch->scan_type.endianness and
> call get_unaligned_be16() / get_unaligned_be24() when the channel
> declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro,
> st_pressure, st_lsm6dsx and others) are unaffected because their
> channel specs already declare IIO_LE and the LE path is unchanged.
>
> While restructuring the branches, replace the previously implicit
> silent-success-with-uninitialised-*data fall-through for
> byte_for_channel outside 1..3 with an explicit return -EINVAL. No
> in-tree ST sensor publishes such a channel, but the new behaviour
> is strictly safer than handing userspace garbage.
Sounds like inevitable change in ABI, but worth doing it.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 4/4] ARM: dts: mediatek: mt6323: add EFUSE support
From: sashiko-bot @ 2026-06-17 10:02 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260617-mt6323-nvmem-v2-4-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unchecked dereference of dev->parent when getting regmap.
--
commit f140540f16666ffd0b4a44edcb3b4ac15d83d749
Author: Roman Vivchar <rva333@protonmail.com>
ARM: dts: mediatek: mt6323: add EFUSE support
This commit adds the devicetree node for the mt6323 efuse to the mt6323
PMIC definition. It introduces the mediatek,mt6323-efuse compatible string
to instantiate the driver.
> diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
> index c230c865116d0..807e000a7ff64 100644
> --- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
> +++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
> @@ -14,6 +14,10 @@ pmic: mt6323 {
> interrupt-controller;
> #interrupt-cells = <2>;
>
> + efuse {
> + compatible = "mediatek,mt6323-efuse";
[Severity: High]
Does binding to this compatible string introduce a regression under certain
devicetree configurations?
Looking at drivers/nvmem/mt6323-efuse.c:mt6323_efuse_probe(), the driver
blindly traverses the parent hierarchy:
/* efuse -> mfd -> pwrap */
regmap = dev_get_regmap(dev->parent->parent, NULL);
If the device is instantiated directly at the root of a Device Tree
or via a malformed overlay, it lacks a grandparent. In this case,
dev->parent is initialized to &platform_bus, and evaluating
dev->parent->parent results in a null pointer.
Passing a null pointer as the device to dev_get_regmap() triggers an
immediate kernel panic during probe(), because the underlying
devres_find() unconditionally dereferences the dev pointer.
Could the driver verify that the parent hierarchy exists before
attempting to traverse it and retrieve the regmap?
> + };
> +
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=4
^ permalink raw reply
* Re: [PATCH 05/12] rtc: rzn1: Add system suspend/resume support and wakeup capability
From: Wolfram Sang @ 2026-06-17 10:02 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
> Add system-wide power management support along with wakeup capability to
> the rtc-rzn1 driver.
Do you have an actual use case for the wakeup functionality? If it is so
limited, then we should maybe not support the weak abilities until
someone has a real use case? For which then, a proper solution has been
developed and tested?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: sashiko-bot @ 2026-06-17 10:00 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260617-mt6323-nvmem-v2-1-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing core NVMEM schema reference for an NVMEM provider node.
--
commit 3b91c0fc686c29119bcba167256b72fe3a4c7b96
Author: Roman Vivchar <rva333@protonmail.com>
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
This commit adds devicetree binding documentation for the MediaTek mt6323
EFUSE. The efuse component is responsible for storing calibration data
within the mt6323 PMIC.
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 05c121b0cb3d8..beaa67bf0df2c 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -145,6 +145,23 @@ properties:
> required:
> - compatible
>
> + efuse:
> + type: object
> + unevaluatedProperties: false
> + description:
> + The efuse is responsible for storing calibration data, such as thermal
> + sensor calibration.
> +
> + properties:
> + compatible:
> + const: mediatek,mt6323-efuse
> +
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
[Severity: Low]
Does this node need a reference to the core NVMEM schema?
Because the efuse node acts as an NVMEM provider and uses
unevaluatedProperties: false, it will currently reject standard NVMEM
properties like read-only and wp-gpios if they are specified in the
device tree.
Including a $ref to /schemas/nvmem/nvmem.yaml# would natively support
nvmem-layout and permit standard NVMEM provider features to pass validation.
> +
> + required:
> + - compatible
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 3/4] mfd: mt6397-core: add mt6323 EFUSE support
From: sashiko-bot @ 2026-06-17 9:59 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260617-mt6323-nvmem-v2-3-4f30e36aa0f4@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unchecked grandparent pointer dereference in mt6323_efuse_probe.
--
commit 9ff4fcd2490678b446194f62f1baf75c41828eff
Author: Roman Vivchar <rva333@protonmail.com>
Subject: mfd: mt6397-core: add mt6323 EFUSE support
This commit adds the mt6323 EFUSE to the mt6323 devices array in the MFD core.
This registration allows the corresponding efuse driver to probe using its
compatible string.
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 3e58d0764c7e0..362737a1c4a9a 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
>
> static const struct mfd_cell mt6323_devs[] = {
> {
> + .name = "mt6323-efuse",
> + .of_compatible = "mediatek,mt6323-efuse",
[Severity: High]
Does adding this compatible string expose an unchecked pointer dereference
in the efuse driver?
Looking at mt6323_efuse_probe() in drivers/nvmem/mt6323-efuse.c:
mt6323_efuse_probe() {
...
regmap = dev_get_regmap(dev->parent->parent, NULL);
...
}
If the driver is instantiated directly from a top-level device tree node via
this compatible string instead of as an MFD child, dev->parent will point to
the root platform bus. Because the platform bus has no parent,
dev->parent->parent evaluates to a NULL pointer.
Passing this NULL device pointer to dev_get_regmap() causes devres_find() to
unconditionally dereference it. Would it be safer to add a NULL check on
dev->parent and dev->parent->parent in the driver before doing this lookup
to prevent a kernel panic?
> }, {
> .name = "mt6323-rtc",
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=3
^ permalink raw reply
* Re: [PATCH v4 resend 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Krzysztof Kozlowski @ 2026-06-17 9:58 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617064100.1504617-2-joakim.zhang@cixtech.com>
On Wed, Jun 17, 2026 at 02:40:56PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> and control registers in a dedicated CRU block. Software reset lines are
> exposed on the syscon parent via #reset-cells, following the same model
> as the existing Sky1 FCH and S5 system control bindings.
>
> A clock-controller child node is required under the audss syscon. It has
> no reg property of its own and accesses the parent register block for mux,
> divider and gate fields.
>
> The AUDSS is also controlled by one power domain and reset part.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> .../soc/cix/cix,sky1-system-control.yaml | 48 +++++++++++++++++++
> .../reset/cix,sky1-audss-system-control.h | 25 ++++++++++
> 2 files changed, 73 insertions(+)
> create mode 100644 include/dt-bindings/reset/cix,sky1-audss-system-control.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 resend 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Krzysztof Kozlowski @ 2026-06-17 9:58 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617064100.1504617-4-joakim.zhang@cixtech.com>
On Wed, Jun 17, 2026 at 02:40:58PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The AUDSS CRU contains an internal clock tree of muxes, dividers and
> gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider is
> a child node of the cix,sky1-audss-system-control syscon and accesses
> registers through the parent MMIO region.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 04/12] rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS
From: Wolfram Sang @ 2026-06-17 9:57 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-5-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
> - depends on ARCH_RZN1 || COMPILE_TEST
> + depends on ARCH_RENESAS || COMPILE_TEST
Yes, this helps X5H also :)
> - If you say yes here you get support for the Renesas RZ/N1 RTC.
> + If you say yes here you get support for the RTC found on Renesas RZ/N1,
> + RZ/N2H, and RZ/T2H SoCs.
Such lists are easy to get stale IMHO. What about "initially found on
Renesas RZ/N1 SoCs."?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/5] clk: renesas: cpg-mssr: Implement dedicated MSTP delay logic for RZ/T2H LCDC and RTC
From: Geert Uytterhoeven @ 2026-06-17 9:50 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Introduce a dedicated clock delay mechanism, cpg_rzt2h_mstp_delay(), to
> satisfy the module-stop (MSTP) state release requirements specified in
> the RZ/T2H hardware manual.
>
> Per the hardware manual, while a standard 10 us delay (satisfying 7 dummy
> reads) is sufficient for most IP blocks, the LCDC requires 100 dummy reads
> (142 us) and the RTC requires 300 dummy reads (428 us) to stabilize after
> being released from a module-stop state.
>
> Implement a conditional bitmask filter helper that switches wait
> intervals based on the packaged module clock index. In
> cpg_mstp_clock_endisable(), the clock index and individual target bits are
> known, allowing an exact match. In the resume path cpg_mssr_resume_noirq(),
> where individual bits are not tracked, pass a fallback register index base
> (`reg * 32`) with bit verification masked out to match on the peripheral's
> register group block instead.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 03/12] rtc: rzn1: Fix malformed MODULE_AUTHOR string
From: Wolfram Sang @ 2026-06-17 9:55 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
On Mon, Jun 15, 2026 at 04:47:56PM +0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Fix a malformed MODULE_AUTHOR macro in the rtc-rzn1 driver where a missing
> closing angle bracket on the second author entry creates an invalid format.
> Correct it to the standard "Name <email>" format.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 02/12] rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
From: Wolfram Sang @ 2026-06-17 9:55 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar, stable
In-Reply-To: <20260615154805.1619693-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]
Hi,
Sashiko found issues with your patch. I curated the list and agree. I
think, in probe(), 'rate' should be initialized to 32768 and 'sync_time'
should be calculated unconditionally.
Thank you and happy hacking,
Wolfram
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] If the optional 'xtal' clock is not present, `rtc->sync_time` remains 0, causing `readl_poll_timeout` to use a 0 timeout (infinite wait) and `usleep_range` to use a 0 delay.
> --
>
> commit 5d75a1049c228d2049afaf29833f1b2f212837d4
> Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Subject: rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
>
> This commit checks for -EPROBE_DEFER from platform_get_irq_byname_optional()
> and handles the deferred probe request properly. It intercepts this specific
> error condition, assigns it to the return value, and jumps to the
> dis_runtime_pm label to avoid ignoring a valid probe deferral.
>
> Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms")
> Cc: stable@vger.kernel.org
>
> > diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> > index c4ed437354574..f81d691c8b9a2 100644
> > --- a/drivers/rtc/rtc-rzn1.c
> > +++ b/drivers/rtc/rtc-rzn1.c
> > @@ -465,6 +465,10 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> > }
> >
> > irq = platform_get_irq_byname_optional(pdev, "pps");
> > + if (irq == -EPROBE_DEFER) {
> > + ret = irq;
> > + goto dis_runtime_pm;
> > + }
> > if (irq >= 0)
> > ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
>
> [Severity: High]
> If the optional xtal clock is not present, does rtc->sync_time remain 0,
> causing readl_poll_timeout() to use a 0 timeout (infinite wait) and
> usleep_range() to use a 0 delay?
>
> devm_clk_get_optional() returns NULL if the clock is absent in the device
> tree, skipping the calculation:
>
> drivers/rtc/rtc-rzn1.c:rzn1_rtc_probe() {
> ...
> xtal = devm_clk_get_optional(dev, "xtal");
> if (IS_ERR(xtal)) {
> ...
> } else if (xtal) {
> rate = clk_get_rate(xtal);
> ...
> rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
> }
> ...
> ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
> !(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
> rtc->sync_time * 2);
> ...
> }
>
> In include/linux/iopoll.h, a timeout_us of 0 skips the timeout check
> entirely, which could lead to a tight infinite loop and a kernel hard lockup
> if the hardware fails to clear the CEST bit.
>
> Additionally, rtc->sync_time being 0 causes usleep_range(0, 100) in
> rzn1_rtc_set_time(), which may return almost immediately and violate the
> hardware's explicit 2-clock-cycle delay requirement (previously hardcoded to
> 61us).
>
> This regression was introduced by the commit 'rtc: rzn1: Dynamically
> calculate synchronization delay based on clock rate' later in this series.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: clock: renesas,r9a09g077/87: Add LCDC_CLKD clock ID
From: Geert Uytterhoeven @ 2026-06-17 9:51 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar, Conor Dooley
In-Reply-To: <20260615104845.4122868-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the LCDC clockd (LCDC_CLKD) definition for the Renesas RZ/T2H
> (R9A09G077) and RZ/N2H (R9A09G087) SoCs. LCDC_CLKD is used as the
> operating clock for LCDC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, will queue in a branch shared by renesas-clk and renesas-dts.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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