* Re: [PATCH v2 08/10] arm64: dts: renesas: r9a07g0{43,44,54}: remove TCIU8 interrupt from MTU3
From: Geert Uytterhoeven @ 2026-05-22 13:43 UTC (permalink / raw)
To: Cosmin Tanislav
Cc: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Michael Turquette,
Stephen Boyd, Lee Jones, Philipp Zabel, linux-iio,
linux-renesas-soc, linux-kernel, devicetree, linux-clk
In-Reply-To: <20260410163530.383818-9-cosmin-gabriel.tanislav.xa@renesas.com>
On Fri, 10 Apr 2026 at 18:37, Cosmin Tanislav
<cosmin-gabriel.tanislav.xa@renesas.com> wrote:
> The TCIU8 interrupt used to be documented in earlier revisions of the
> user manuals, but has since been removed. The corresponding entry is now
> marked as reserved in the interrupt mapping tables of all supported
> SoCs.
>
> * Page 486, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2UL
> Rev.1.40 User Manual
> * Page 363, Table 8.2 Interrupt Mapping (6/13) in the Renesas RZ/Five
> Rev.1.30 User Manual
> * Page 528, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2L
> and RZ/G2LC Rev.1.50 User Manual
> * Page 540, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/V2L
> Rev.1.50 User Manual
>
> Remove the TCIU8 interrupt. This does not cause any breakage as the
> driver does not make use of the interrupts.
>
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> ---
>
> V2:
> * reword to mention that TCIU8 used to exist
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 v12 5/6] iio: adc: ad4691: add oversampling support
From: Jonathan Cameron @ 2026-05-22 13:38 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414E63DA5C2C22A46E98215F70F2@LV9PR03MB8414.namprd03.prod.outlook.com>
On Fri, 22 May 2026 11:38:55 +0000
"Sabau, Radu bogdan" <Radu.Sabau@analog.com> wrote:
> > -----Original Message-----
> > From: Jonathan Cameron <jic23@kernel.org>
> > Sent: Friday, May 22, 2026 2:16 PM
>
> ...
>
> > > >
> > > > + iio_for_each_active_channel(indio_dev, bit) {
> > > > + ret = regmap_write(st->regmap,
> > > > AD4691_ACC_DEPTH_IN(bit), st->osr[bit]);
> > >
> > > Unfortunately enough, I think a v13 will come, too...
> > >
> > > Had a look again on what Sashiko had to say, and seeing the sampling
> > frequency
> > > shared_by_all comment again made me have a deeper look see how the
> > code could
> > > be commented so he wouldn't complain about this anymore, and...
> > >
> > > Perhaps he is a bit right after all. I found a section stating that in standard
> > > sequencer mode (which the driver uses right now), all the channels actually
> > use
> > > the ACC_DEPTH_IN0 for osr, and so changing ACC_DEPTH_INn for other
> > channels
> > > doesn't really do much. And so I tested this selecting both voltage0 and
> > voltage1
> > > for sampling with osr4 for voltage0 and osr1 for voltage1 and with a 100kHz
> > osc freq
> > > indeed DR fell after approximately 80us which points out both channels were
> > actually
> > > using OSR of 4. Perhaps the OSR should be shared by all and therefore the
> > > sampling frequency would also be shared by all, right?
> >
> > I kind of lost track on the modes. What are the chances we later move to or
> > add
> > support for a mode where the different OSRs do matter? If that's a possibility
> > we should avoid ABI change by allowing for it from the start.
> >
> > Then if we are in this mode, they'll have separate controls but change any,
> > changes
> > them all, if we are in a different mode that connection breaks.
> > If that's the case, just throw in a comment saying something to the effect this
> > may change.
> >
> > It's not wrong ABI to do this, it's just less intuitive for users which is why
> > we prefer the shared_by stuff where there isn't a disadvantage. That is at
> > most
> > a hint to what actually happens. A simple example is where different
> > channels have one OSR field but they aren't the same - i.e. channel 1 is twice
> > the OSR of channel 2. Hence we can't share the attribute but any change
> > effects
> > both.
> >
>
> Hi Jonathan,
>
> I don't think a mode where different OSR will matter will be added in the future. Better
> yet, this advanced sequencer functionality is not really mode dependent and is actually
> something that allows you to manually rearrange channels and samples in the
> sequence, and unless this functionality is active (it is not by default nor is it used by
> the driver, since we use the standard sequencer).
>
> Personally, I don't see any reason to have this advanced sequencer stuff implemented
> since DR is only falling at the end of the sequence no matter if it is standard config or not,
> the only "disadvantage" to say so is that the standard sequencer uses the same OSR field
> for all channels. But that advanced sequencer stuff would only complicate the buffer
> enable/disable functions even more, which I don't think it's worth the effort.
>
> So, with this in mind. Letting the driver use standard sequencer would ultimately mean
> that the osr would be the same for all the channels, and then effective rate the same for
> all channels, which I suggest having it like that from initial driver patch to the end, so no
> ABI change mid-patch series. This change will simplify the driver.
Ok. Thanks for the analysis. It may well be that those fancy sequencer things are
only really useful for very specific use cases we won't see in Linux.
So I'm fine with following the simple path!
Jonathan
>
> Radu
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: rz-smarc-du-adv7513: Simplify DU port configuration
From: Geert Uytterhoeven @ 2026-05-22 13:37 UTC (permalink / raw)
To: Prabhakar
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260420132211.1350656-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 20 Apr 2026 at 15:22, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The SoC dtsi already defines the du node with its ports hierarchy,
> including the du_out_rgb endpoint node under port@0. There is no need
> to redefine the entire ports/port@0 structure in the board-level dtsi.
>
> 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-devel for v7.2.
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 2/2] arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Add alias for on-SoC RTC
From: Geert Uytterhoeven @ 2026-05-22 13:35 UTC (permalink / raw)
To: Prabhakar
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260506155804.3984418-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, 6 May 2026 at 17:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The RZ/V2N SoC provides an internal RTC, which is enabled in the DT.
> The RZ/V2N EVK board also includes an external RTC in the RAA215300
> PMIC.
>
> Add an "rtc0" alias pointing to the on-SoC RTC node to ensure a stable
> device numbering.
>
> 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-devel for v7.2.
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 1/2] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add alias for on-SoC RTC
From: Geert Uytterhoeven @ 2026-05-22 13:35 UTC (permalink / raw)
To: Prabhakar
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260506155804.3984418-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, 6 May 2026 at 17:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The RZ/V2H SoC provides an internal RTC, which is enabled in the DT.
> The RZ/V2H EVK board also includes an external RTC in the RAA215300
> PMIC.
>
> Add an "rtc0" alias pointing to the on-SoC RTC node to ensure a stable
> device numbering.
>
> 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-devel for v7.2.
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 v3 8/8] iio: temperature: ltc2983: Add support for ADT7604
From: Jonathan Cameron @ 2026-05-22 13:34 UTC (permalink / raw)
To: Liviu Stan
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Antoniu Miclaus,
Francesco Lavra, linux-iio, linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-9-liviu.stan@analog.com>
On Thu, 21 May 2026 19:43:01 +0300
Liviu Stan <liviu.stan@analog.com> wrote:
> The ADT7604 shares the same die as the LTC2984. It repurposes the
> custom RTD sensor type (18) as a copper trace resistance sensor
> and the custom thermistor type (27) as a leak detector, and
> removes thermocouple, diode and direct ADC sensor types.
>
> Two new software sensor type values are introduced
> (LTC2983_SENSOR_COPPER_TRACE = 32, LTC2983_SENSOR_LEAK_DETECTOR = 33)
> that map to the hardware register values 18 and 27 respectively.
> Dedicated structs (ltc2983_copper_trace, ltc2983_leak_detector) and
> parser functions are added rather than extending the existing RTD and
> thermistor paths, as the hardware configuration bits are fully
> hardcoded and several RTD/thermistor properties would need to be
> explicitly forbidden or ignored.
>
> Custom RTD (type 18) becomes the copper trace sensor. Sensor
> configuration bits are hardcoded to 0b1001 per the datasheet.
> Two variants are supported via the adi,copper-trace-sub-ohm DT
> property: sub-ohm traces (< 1 ohm) have bits 17:0 cleared with no
> excitation current or custom table; standard traces (> 1 ohm) have
> a required resistance-to-temperature table.
>
> Custom thermistor (type 27) becomes the leak detector. Sensor
> configuration bits are hardcoded to 0b001. The custom table uses
> a resolution of 16 instead of 64, and is specified via the
> required adi,custom-leak-detector DT property.
>
> Both sensor types expose an IIO_RESISTANCE channel reading from
> the resistance result register bank (0x0060-0x00AF). Added a
> "base" parameter to the LTC2983_RESULT_ADDR macro and a "base_reg"
> parameter to the ltc2983_chan_read function so we can read from
> both result register banks. The resistance register encodes the
> measured resistance with 10 fractional bits, so dividing by 1024
> gives ohms. Since the sense resistor is specified in ohms, the
> output is in ohms for both sensor types and a single 1/1024
> scale applies to both. For > 1 ohm copper traces and for leak
> detectors, a secondary channel also appears: IIO_TEMP
> (millidegrees Celsius) for copper trace and IIO_COVERAGE (percent)
> for leak detector.
>
> The ltc2983_chip_info struct is extended with a u64 supported_sensors
> bitmask using BIT_ULL() to safely represent the new sensor type bits
> 32 and 33 on 32-bit builds. A LTC2983_SENSOR_NUM sentinel is added
> to the enum so that the bounds check uses >= LTC2983_SENSOR_NUM
> rather than hardcoding the last sensor type.
>
> Tested on EVAL-ADT7604-AZ connected to Raspberry Pi 5 via SPI.
>
> Signed-off-by: Liviu Stan <liviu.stan@analog.com>
The sashiko comment about the completion race looks real to me.
Can you take a look at that. Might be some odd reason why we can't
reinit_completion() before triggering the capture but that would
be very unusual.
Otherwise just two really small things I missed in earlier reviews.
If everything else was ready to go I'd have tweaked these whilst
applying but seems you'll be doing a v4 so over to you!
Jonathan
> drivers/iio/temperature/ltc2983.c | 413 ++++++++++++++++++++++++++++--
> 1 file changed, 394 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
> index 326f843f4271..e2ffeee026ee 100644
> --- a/drivers/iio/temperature/ltc2983.c
> +++ b/drivers/iio/temperature/ltc2983.c
> @@ -186,17 +188,44 @@ enum {
> LTC2983_SENSOR_SENSE_RESISTOR = 29,
> LTC2983_SENSOR_DIRECT_ADC = 30,
> LTC2983_SENSOR_ACTIVE_TEMP = 31,
> + /* Sensor types for some parts only; map to RTD_CUSTOM/THERMISTOR_CUSTOM in HW */
> + LTC2983_SENSOR_COPPER_TRACE = 32,
> + LTC2983_SENSOR_LEAK_DETECTOR = 33,
> + LTC2983_SENSOR_NUM,
That's a terminating entry so no trailing comma. It always has to be last.
> };
> static const struct spi_device_id ltc2983_id_table[] = {
> @@ -1707,6 +2080,7 @@ static const struct spi_device_id ltc2983_id_table[] = {
> { "ltc2984", (kernel_ulong_t)<c2984_chip_info_data },
> { "ltc2986", (kernel_ulong_t)<c2986_chip_info_data },
> { "ltm2985", (kernel_ulong_t)<m2985_chip_info_data },
> + { "adt7604", (kernel_ulong_t)&adt7604_chip_info_data },
As below.
> { }
> };
> MODULE_DEVICE_TABLE(spi, ltc2983_id_table);
> @@ -1716,6 +2090,7 @@ static const struct of_device_id ltc2983_of_match[] = {
> { .compatible = "adi,ltc2984", .data = <c2984_chip_info_data },
> { .compatible = "adi,ltc2986", .data = <c2986_chip_info_data },
> { .compatible = "adi,ltm2985", .data = <m2985_chip_info_data },
> + { .compatible = "adi,adt7604", .data = &adt7604_chip_info_data },
Oops I missed this before. Alphabetical order.
Jonathan
> { }
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: renesas: ulcb: Rename clk-multiplier to clock-controller
From: Geert Uytterhoeven @ 2026-05-22 13:34 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260504225704.115125-5-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 00:57, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Use standard clock-controller node name for the CS2000-CP.
> No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 4/5] arm64: dts: renesas: salvator-common: Rename clk-multiplier to clock-controller
From: Geert Uytterhoeven @ 2026-05-22 13:33 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260504225704.115125-4-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 00:57, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Use standard clock-controller node name for the CS2000-CP.
> No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 v3 2/2] ASoC: spacemit: add K3 SoC support with additional clocks
From: sashiko-bot @ 2026-05-22 13:33 UTC (permalink / raw)
To: Troy Mitchell; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260522-k3-i2s-v3-2-08e3eb811d93@linux.spacemit.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unprotected rate changes on shared clocks `c_sysclk` and `c_bclk` can corrupt active audio streams on other I2S controllers.
--
commit f3c6244a03afa7c9321de2747d7f0c3a9bc65bd2
Author: Troy Mitchell <troy.mitchell@linux.spacemit.com>
ASoC: spacemit: add K3 SoC support with additional clocks
This commit adds support for the SpacemiT K3 SoC I2S controller. It acquires
new clocks (sysclk_div, c_sysclk, and c_bclk) using
devm_clk_get_optional_enabled() and configures their rates dynamically based
on the sample rate during stream setup.
> diff --git a/sound/soc/spacemit/k1_i2s.c b/sound/soc/spacemit/k1_i2s.c
> index 5420ca2aefbd8..8871fc15b29cc 100644
> --- a/sound/soc/spacemit/k1_i2s.c
> +++ b/sound/soc/spacemit/k1_i2s.c
[ ... ]
> @@ -206,6 +209,14 @@ static int spacemit_i2s_hw_params(struct snd_pcm_substream *substream,
> params_rate(params) *
> data_bits;
>
> + ret = clk_set_rate(i2s->c_sysclk, bclk_rate * 2);
> + if (ret)
> + return ret;
> +
> + ret = clk_set_rate(i2s->c_bclk, bclk_rate);
> + if (ret)
> + return ret;
> +
[Severity: Medium]
The commit message notes that c_sysclk and c_bclk are shared across multiple
I2S controllers on the K3 SoC. If multiple controllers are concurrently
active and request different sample rates, will calling clk_set_rate() here
silently overwrite the shared clock rates?
Could this instantaneous frequency change disrupt the active audio stream on
the other controllers, causing pitch shifts or FIFO underflows?
Would it be safer to use clk_set_rate_exclusive() to lock the rate while the
stream is active and reject conflicting requests?
> ret = clk_set_rate(i2s->bclk, bclk_rate);
> if (ret)
> return ret;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-k3-i2s-v3-0-08e3eb811d93@linux.spacemit.com?part=2
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: renesas: hihope: Rename clk-multiplier to clock-controller
From: Geert Uytterhoeven @ 2026-05-22 13:33 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260504225704.115125-3-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 00:57, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Use standard clock-controller node name for the CS2000-CP.
> No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 2/5] arm64: dts: qcom: Introduce Shikra SoC base dtsi
From: Komal Bajaj @ 2026-05-22 13:33 UTC (permalink / raw)
To: sashiko-reviews
Cc: robh, devicetree, vkoul, linux-phy, olteanv, conor+dt,
neil.armstrong
In-Reply-To: <20260519114737.70CD0C2BCB3@smtp.kernel.org>
On 5/19/2026 5:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> - [Critical] Incorrect PPI numbers are specified for the ARM architected timers and GIC maintenance interrupts.
> - [High] The base memory node specifies an incorrect start address, obscuring 512MB of DDR system RAM and breaking reservations.
> - [Medium] The `sdhc_1` node incorrectly references a power domain specific to a different SoC.
> - [Medium] The logical `cpu-map` splits CPUs into two clusters, contradicting physical MPIDR topology and shared cache.
> - [Medium] The `usb_1` node is missing MPM-routed interrupts for USB 2.0 wake from deep sleep.
> --
>
> commit 32b9841bdefaa72fe3d5267070711875edaaafa0
> Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>
> arm64: dts: qcom: Introduce Shikra SoC base dtsi
>
> Add initial device tree support for the Qualcomm Shikra SoC, an
> IoT-focused platform built around a heterogeneous CPU cluster
> (Cortex-A55 + Cortex-A78C) with RPM-based power and clock management.
>
>> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
>> new file mode 100644
>> index 0000000000000..31d0126e5b3ee
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
>> @@ -0,0 +1,981 @@
> [ ... ]
>
>> + cpu-map {
>> + cluster0 {
>> + core0 {
>> + cpu = <&cpu0>;
>> + };
>> +
>> + core1 {
>> + cpu = <&cpu1>;
>> + };
>> +
>> + core2 {
>> + cpu = <&cpu2>;
>> + };
>> + };
>> +
>> + cluster1 {
>> + core0 {
>> + cpu = <&cpu3>;
>> + };
>> + };
>> + };
> Is this logical topology misaligned with the physical MPIDR topology?
>
> The CPU reg values (0x0, 0x100, 0x200, 0x300) have their Aff2 bits set to 0,
> meaning they physically reside in the same cluster. The A55 cores and A78C
> core also share the same L3 cache.
>
> Does splitting cpu0-cpu2 into cluster0 and cpu3 into cluster1 violate
> DynamIQ specifications and confuse the scheduler's task migration and
> domains?
>
> [ ... ]
The hardware MPIDR for cpu3 is 0x300 (Aff2=0), confirmed by PSCI boot
failure when reg was changed to 0x10000.
The cpu-map two-cluster split is intentional and correct for EAS
scheduler topology (separate performance domains for A55 silver and A78C
gold), even though all four cores share Aff2=0 in the same DSU.
>
>> + memory@a0000000 {
>> + device_type = "memory";
>> + /* We expect the bootloader to fill in the size */
>> + reg = <0x0 0xa0000000 0x0 0x0>;
>> + };
> Is this base address correct?
>
> The reserved-memory list allocates memory regions well below this address,
> such as hyp@80000000 and smem@86000000.
>
> Does starting the system RAM at 0xa0000000 cause the kernel to disregard the
> 0x80000000-0x9fffffff region, effectively losing 512MB of RAM and
> potentially causing the reservations to fail?
Will fix by updating base address to memory@80000000.
>
> [ ... ]
>
>> + sdhc_1: mmc@4744000 {
>> + compatible = "qcom,shikra-sdhci", "qcom,sdhci-msm-v5";
>> +
>> + reg = <0x0 0x04744000 0x0 0x1000>,
> [ ... ]
>
>> + interconnects = <&system_noc MASTER_SDCC_1 RPM_ALWAYS_TAG
>> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
>> + <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
>> + &config_noc SLAVE_SDCC_1 RPM_ACTIVE_TAG>;
>> + interconnect-names = "sdhc-ddr",
>> + "cpu-sdhc";
>> +
>> + power-domains = <&rpmpd QCM2290_VDDCX>;
> Is this a copy-paste error?
>
> The gcc node correctly uses the generic or Shikra-specific RPMPD_VDDCX.
>
> Could referencing a QCM2290-specific power domain macro here result in the
> hardware attempting to scale the wrong voltage domain or cause an
> out-of-bounds array access in the driver?
Yes, that's a copy-paste error. Will fix it in the next version.
[ ... ]
> [ ... ]
>
>> + intc: interrupt-controller@f200000 {
>> + compatible = "arm,gic-v3";
>> + reg = <0x0 0xf200000 0x0 0x10000>,
>> + <0x0 0xf240000 0x0 0x80000>;
>> +
>> + interrupts = <GIC_PPI 8 IRQ_TYPE_LEVEL_HIGH 0>;
> Is this the correct PPI for the GIC maintenance interrupt?
>
> The architecturally mandated GIC maintenance interrupt is PPI 9, rather than
> PPI 8.
Will fix by changing GIC_PPI 8 to GIC_PPI 9 in the next version.
Thanks
Komal
>
> [ ... ]
>
>> + timer {
>> + compatible = "arm,armv8-timer";
>> +
>> + interrupts = <GIC_PPI 1 IRQ_TYPE_LEVEL_LOW 0>,
>> + <GIC_PPI 2 IRQ_TYPE_LEVEL_LOW 0>,
>> + <GIC_PPI 3 IRQ_TYPE_LEVEL_LOW 0>,
>> + <GIC_PPI 0 IRQ_TYPE_LEVEL_LOW 0>;
>> + };
>> +};
> Are these PPI numbers correct for the ARM architected timers?
>
> The architecturally hardwired ARM core timer PPIs are 13 (Secure),
> 14 (Non-Secure), 11 (Virtual), and 10 (Hypervisor).
>
> Could specifying these incorrect numbers prevent the kernel from receiving
> timer ticks and cause the system to hang during boot?
>
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: renesas: ebisu: Rename clk-multiplier to clock-controller
From: Geert Uytterhoeven @ 2026-05-22 13:33 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260504225704.115125-2-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 00:57, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Use standard clock-controller node name for the CS2000-CP.
> No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 1/5] arm64: dts: renesas: draak: Rename clk-multiplier to clock-controller
From: Geert Uytterhoeven @ 2026-05-22 13:32 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260504225704.115125-1-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 00:57, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Use standard clock-controller node name for the CS2000-CP.
> No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 3/3] arm64: dts: renesas: r9a07g054: Add max-frequency to SDHI nodes
From: Geert Uytterhoeven @ 2026-05-22 13:31 UTC (permalink / raw)
To: Biju
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260520115144.60067-4-biju.das.jz@bp.renesas.com>
On Wed, 20 May 2026 at 13:51, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add the max-frequency property set to 133333333 Hz (133.33 MHz) to both
> SDHI0 and SDHI1 MMC controller nodes in the RZ/V2L (r9a07g054) device
> tree.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
increasing performance by ca. 33%.
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 2/3] arm64: dts: renesas: r9a07g044: Add max-frequency to SDHI nodes
From: Geert Uytterhoeven @ 2026-05-22 13:31 UTC (permalink / raw)
To: Biju
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260520115144.60067-3-biju.das.jz@bp.renesas.com>
On Wed, 20 May 2026 at 13:51, Biju <biju.das.au@gmail.com> wrote:
>
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add the max-frequency property set to 133333333 Hz (133.33 MHz) to both
> SDHI0 and SDHI1 MMC controller nodes in the RZ/{G2L,G2LC} (r9a07g044)
> device tree.
increasing performance by ca. 33%.
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 1/3] arm64: dts: renesas: r9a07g043: Add max-frequency to SDHI nodes
From: Geert Uytterhoeven @ 2026-05-22 13:30 UTC (permalink / raw)
To: Biju
Cc: Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260520115144.60067-2-biju.das.jz@bp.renesas.com>
On Wed, 20 May 2026 at 13:51, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Add the max-frequency property set to 133333333 Hz (133.33 MHz) to both
> SDHI0 and SDHI1 MMC controller nodes in the RZ/{G2UL,Five} (r9a07g043)
> device tree.
increasing performance by ca. 33%.
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 RFC] arm64: dts: qcom: qcm6490-fairphone-fp5: Add AW88261 amplifiers
From: Konrad Dybcio @ 2026-05-22 13:26 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Val Packett, Bharadwaj Raju,
Bhushan Shah
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260522-fp5-aw88261-v1-1-20e412eb4c4e@fairphone.com>
On 5/22/26 2:39 PM, Luca Weiss wrote:
> Add nodes for the two AW88261 amplifiers, for the top and bottom
> speakers of this phone. Hook them up to the sound card.
>
> Co-developed-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in>
> Signed-off-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> RFC because the AW88261 patches aren't merged yet
Are you sure?
for the patch:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 11/11] arm64: dts: renesas: gray-hawk: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:24 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-12-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:44, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
No regression on my Gray Hawk Single, so
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 10/11] arm64: dts: renesas: white-hawk: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:24 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-11-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:44, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
No regression on my White Hawk, so
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 v3 8/8] iio: temperature: ltc2983: Add support for ADT7604
From: Liviu Stan @ 2026-05-22 13:23 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521191828.F20931F000E9@smtp.kernel.org>
On Thu, 21 May 2026 19:18:28 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> New issues:
> - [High] Reading the IIO_RESISTANCE channel bypasses hardware fault detection, causing hardware errors (like broken sensor traces) to be silently reported as valid data.
>
> Pre-existing issues:
> - [High] reinit_completion() is called after initiating the hardware conversion, creating a race condition that can cause spurious read timeouts.
> --
>
> commit d382a4cbefd41723ab5ddd91fd399d716c8faaec
> Author: Liviu Stan <liviu.stan@analog.com>
> Subject: iio: temperature: ltc2983: Add support for ADT7604
>
> This commit adds support for the ADT7604 temperature sensor by repurposing
> custom RTD and thermistor types as copper trace resistance and leak detector
> sensors. It introduces two new software sensor types and exposes a new
> IIO_RESISTANCE channel reading from a separate result register bank. The
> ltc2983_chip_info struct is also extended to use a 64-bit supported_sensors
> bitmask for the new types.
>
> > diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
> > index 326f843f42713..e2ffeee026eef 100644
> > --- a/drivers/iio/temperature/ltc2983.c
> > +++ b/drivers/iio/temperature/ltc2983.c
>
> [ ... ]
>
> > @@ -1205,7 +1502,8 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
> > }
> >
> > static int ltc2983_chan_read(struct ltc2983_data *st,
> > - const struct ltc2983_sensor *sensor, int *val)
> > + const struct ltc2983_sensor *sensor,
> > + u32 base_reg, int *val)
> > {
> > struct device *dev = &st->spi->dev;
> > u32 start_conversion = 0;
>
> [Severity: High]
> This is a pre-existing issue, but can this function experience spurious
> read timeouts due to a race condition with the completion?
>
> Looking at the rest of this function:
>
> ret = regmap_write(st->regmap, LTC2983_STATUS_REG, start_conversion);
> if (ret)
> return ret;
>
> reinit_completion(&st->completion);
>
> If the hardware conversion finishes very quickly after regmap_write(),
> could the interrupt fire and call complete() before the CPU executes
> reinit_completion()? This would overwrite the completion event, causing the
> subsequent wait_for_completion_timeout() to spuriously time out.
>
> Would it be safer to call reinit_completion() before initiating the hardware
> action?
This is theoretically valid but in practice, the conversion requires at minimum
two 82ms cycles (167ms), so there is no realistic window for the interrupt to
race with reinit_completion(). What do you guys think?
>
> [ ... ]
>
> > @@ -1236,13 +1534,23 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
> > }
> >
> > /* read the converted data */
> > - ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan),
> > + ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan, base_reg),
> > &st->temp, sizeof(st->temp));
> > if (ret)
> > return ret;
> >
> > *val = __be32_to_cpu(st->temp);
> >
> > + if (base_reg = ADT7604_RES_RES_START_REG) {
> > + /*
> > + * Resistance result register gives a plain unsigned value,
> > + * D31 is always 0, no valid bit, no fault bits. Read bits[30:0]
> > + * directly — the temperature result format does not apply here.
> > + */
> > + *val &= GENMASK(30, 0);
> > + return 0;
>
> [Severity: High]
> Will returning early here bypass hardware fault detection for resistance
> channels?
>
> As the comment notes, the resistance result register does not contain fault
> bits. However, hardware fault indicators (like Hard Fault, Soft Fault, or
> Over Range) are stored in the primary Temperature Result register.
>
> By returning before reading the Temperature Result register and calling
> sensor->fault_handler(), does this code silently ignore sensor faults? This
> might be problematic for sub-ohm copper traces, which only expose the
> IIO_RESISTANCE channel, leaving users with no mechanism to detect a broken
> trace.
>
First, I don't understand why Sashiko wrote "base_reg =
ADT7604_RES_RES_START_REG", the patch has a "==" there. Second, the temperature
result register stores fault indicator bits for temperature reads, not resistance.
Thanks,
Liviu
^ permalink raw reply
* Re: [PATCH 09/11] arm64: dts: renesas: falcon: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:23 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-10-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:44, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 08/11] arm64: dts: renesas: draak: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:23 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-9-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 07/11] arm64: dts: renesas: ebisu: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-8-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
No regression on Ebisu-4D, so
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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/11] arm64: dts: renesas: v3hsk: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-7-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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 05/11] arm64: dts: renesas: condor-common: Specify ethernet PHY reset timings
From: Geert Uytterhoeven @ 2026-05-22 13:21 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260505034325.167797-6-marek.vasut+renesas@mailbox.org>
On Tue, 5 May 2026 at 05:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The KSZ9031RNX reference manual [1] DS00002096H page 60 FIGURE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING Note 2 states, that after the
> de-assertion of reset, wait a minimum of 100 us before starting
> programming on the MIIM (MDC/MDIO) interface. Set DT property
> reset-deassert-us to three times that, 300 us, to provide ample
> time between reset deassertion and MDIO access.
>
> The KSZ9031RNX reference manual [1] DS00002096H page 60 TABLE 7-7:
> POWER-UP/POWER-DOWN/RESET TIMING PARAMETERS row tSR Stable supply
> voltages to de-assertion of reset is at minimum 10 ms. Set DT
> property reset-assert-us to 10ms because the KSZ9031RNX RM does
> not explicitly spell out how long the reset has to be asserted,
> but this at least covers the worst case scenario.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ9031MNX-Data-Sheet-DS00002096.pdf
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Modulo the document references:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
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