* Re: [PATCH v2 1/4] iio: dac: ad3530r: Refactor setup to table-driven register bank approach
From: Andy Shevchenko @ 2026-06-15 10:08 UTC (permalink / raw)
To: Kim Seer Paller
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio, linux-kernel, linux, devicetree
In-Reply-To: <20260615-iio-ad3532r-support-v2-1-84a0af8b83fa@analog.com>
On Mon, Jun 15, 2026 at 02:20:15PM +0800, Kim Seer Paller wrote:
> Replace direct register calls in ad3530r_setup() with per-chip register
> address arrays and bank helpers (ad3530r_set_reg_bank_bits,
> ad3530r_write_reg_banks). Convert sw_ldac_trig_reg from a static
> register address to a function pointer for per-bank LDAC trigger
> register selection. Switch spi_device_id to named initializers.
...
> +static int ad3530r_set_reg_bank_bits(const struct ad3530r_state *st,
> + const unsigned int *regs,
> + unsigned int num_regs,
> + unsigned int mask)
> +{
> + int ret;
> +
> + for (unsigned int i = 0; i < num_regs; i++) {
> + ret = regmap_update_bits(st->regmap, regs[i], mask, mask);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ad3530r_write_reg_banks(const struct ad3530r_state *st,
> + const unsigned int *regs,
> + unsigned int num_regs,
> + unsigned int val)
> +{
> + int ret;
> +
> + for (unsigned int i = 0; i < num_regs; i++) {
> + ret = regmap_write(st->regmap, regs[i], val);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
Can the above helpers use bulk operations or regmap_multi_reg_write()?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 3/3] ASoC: qcom: sc8280xp: ASoC: qcom: sc8280xp: enhance machine driver for board-specific config
From: Mohammad Rafi Shaik @ 2026-06-15 10:11 UTC (permalink / raw)
To: Mark Brown
Cc: Srinivas Kandagatla, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Krzysztof Kozlowski, linux-arm-msm, linux-sound, devicetree,
linux-kernel
In-Reply-To: <b09da7e1-ddc1-452b-9380-964f9ed3b733@sirena.org.uk>
On 6/8/2026 5:38 PM, Mark Brown wrote:
> On Mon, Jun 08, 2026 at 08:00:11AM +0530, Mohammad Rafi Shaik wrote:
>> The sc8280xp machine driver is currently written with a largely
>> SoC-centric view and assumes a uniform audio topology across all boards.
>
>> +static inline int sc8280xp_get_mclk_freq(struct snd_pcm_hw_params *params)
>> +{
>> + int rate = params_rate(params);
>> +
>> + switch (rate) {
>> + case SNDRV_PCM_RATE_11025:
>> + case SNDRV_PCM_RATE_44100:
>> + case SNDRV_PCM_RATE_88200:
>
> rate is in Hz but these are bitmasks.
>
Yes right, thanks for pointing out.
Comparing the sampling rate value from params_rate(params) against
bitmasks like SNDRV_PCM_RATE_44100 is an error. I will update the
switch-case to use literal frequency values (e.g., 44100, 88200) or
appropriate rate constants to ensure the sampling rate is correctly
identified.
>> + return I2S_MCLK_RATE(44100);
>> + default:
>> + break;
>> + }
>
> The function only works since it ignores invalid values.
>
Ack, will fix in next version.
>> +static int sc8280xp_snd_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params)
>> +{
>
>> +
>> + if (data->snd_soc_common_priv->codec_dai_fmt)
>> + snd_soc_dai_set_fmt(codec_dai,
>> + data->snd_soc_common_priv->codec_dai_fmt);
>
> Should we error check the functions we call here?
>
Agreed. I will add proper return value checks for snd_soc_dai_set_fmt
and snd_soc_dai_set_sysclk to ensure any configuration failures are
caught and reported during hw_params.
>> + if (data->snd_soc_common_priv->mi2s_mclk_enable)
>> + snd_soc_dai_set_sysclk(cpu_dai,
>> + LPAIF_MI2S_MCLK, mclk_freq,
>> + SND_SOC_CLOCK_IN);
>> +
>> + if (data->snd_soc_common_priv->mi2s_bclk_enable)
>> + snd_soc_dai_set_sysclk(cpu_dai,
>> + LPAIF_MI2S_BCLK, bclk_freq,
>> + SND_SOC_CLOCK_IN);
>
> Is SND_SOC_CLK_IN right here? The flag sounds like it's enabling the
> clock on the DAI but this is configuring the DAI to consume a clock.
Good catch. Since the CPU DAI is providing the MCLK/BCLK to the codec in
this configuration (Master mode), it should be configured as
SND_SOC_CLOCK_OUT. I will change these to SND_SOC_CLOCK_OUT to correctly
reflect that the DAI is the clock source.
>
>> + if (data->snd_soc_common_priv->codec_sysclk_set)
>> + snd_soc_dai_set_sysclk(cpu_dai,
>> + 0, mclk_freq,
>> + SND_SOC_CLOCK_IN);
>
> This is configuring the CPU not CODEC.
will fix typo error. The call should indeed target the codec_dai when
the codec_sysclk_set flag is enabled. I will fix the function call to
use the correct DAI pointer.
Thanks & Regards,
Rafi.
^ permalink raw reply
* RE: [PATCH 7/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Zhang Yi @ 2026-06-15 10:14 UTC (permalink / raw)
To: krzk
Cc: alsa-devel, broonie, conor+dt, devicetree, krzk+dt, robh, tiwai,
zhangyi
In-Reply-To: <241d0fab-26ea-4c06-9928-e256f2cc5d1c@kernel.org>
> >>> Yes, setting mclk-from-sclk does not affect the MCLK connection.
> >>
> >> I am asking about wiring of the device. If MCLK is used from SCLK, but
> >> SCLK is used as the internal clock, then how can you still have MCLK
> >> connected?
> >
> > If MCLK is derived from SCLK, whether the 'MCLK' pin on the device is
> > connected or not has no effect on operation.
>
> If MCLK is connected, why would you derive it from SCLK? That's the
> point - your clocks property already might be telling everything needed
> here.
This is because sometimes the codec does not work properly
when using the MCLK provided by the CPU.
> >>>>> +
> >>>>> + everest,hpfl:
> >>>>> + $ref: /schemas/types.yaml#/definitions/uint8
> >>>>> + description:
> >>>>> + the HPF value of ADCL.
> >>>>
> >>>> Is HPF value in dB? If so, use proper unit suffix and proper units.
> >>>
> >>> No, the values here correspond to the values in the registers.
> >>> The value is not in dB
> >>
> >> What are the meanings of the register values?
> >
> > The value of everest,hpfl is equal to the value of the corresponding register,
> > not the cutoff frequency of the HPF.
>
> You keep avoiding answers.
>
> I don't want you to encode standard units as register values.
I think I understand what you mean.
Do you want me to enter the physical values in DTS and then convert them to register values in the code?
^ permalink raw reply
* Re: (subset) [PATCH] dt-bindings: mfd: syscon: Revert renesas,r9a08g046-lvds-cmn
From: Lee Jones @ 2026-06-15 10:21 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Tommaso Merciai, Biju Das,
devicetree, linux-kernel, linux-renesas-soc, Krzysztof Kozlowski
In-Reply-To: <20260608115507.134969-2-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 08 Jun 2026 13:55:08 +0200, Krzysztof Kozlowski wrote:
> Revert commit 51284d8b1dbc ("dt-bindings: mfd: syscon: Document the
> LVDS_CMN syscon for the RZ/G3L") because it is completely not matching
> reality and clearly incorrect in respect of renesas,r9a08g046-lvds-cmn.
>
> It wasn't ever build-tested by author on their DTS, either.
>
> The documented renesas,r9a08g046-lvds-cmn compatible clearly disallows
> any children and simple-mfd fallback, however its only use in original
> patchset is with simple-mfd and children, so this could have never
> worked.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: mfd: syscon: Revert renesas,r9a08g046-lvds-cmn
commit: 4143734f197c0065bf5fce7da22f4d0eaf404753
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH V12 4/9] iio: imu: inv_icm42607: Add SPI For icm42607
From: Andy Shevchenko @ 2026-06-15 10:23 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260611202607.85376-5-macroalpha82@gmail.com>
On Thu, Jun 11, 2026 at 03:26:01PM -0500, Chris Morgan wrote:
> Add SPI driver support for InvenSense ICM-42607 devices.
...
> +#include <linux/bitfield.h>
> +#include <linux/dev_printk.h>
> +#include <linux/err.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/spi/spi.h>
...
> +static const struct spi_device_id inv_icm42607_spi_id_table[] = {
> + {
> + .name = "icm42607",
> + .driver_data = (kernel_ulong_t)&inv_icm42607_hw_data
> + }, {
> + .name = "icm42607p",
> + .driver_data = (kernel_ulong_t)&inv_icm42607p_hw_data
I believe I have commented on this already. But anyway, please leave
a trailing comma for .driver_data assignments as well. Same for I²C
driver.
> + },
> + { }
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: spi: snps,dw-apb-ssi: Add support for snps,dwc-ssi-2.00a
From: Conor Dooley @ 2026-06-15 10:23 UTC (permalink / raw)
To: Changhuang Liang
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mark Brown, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <ZQ4PR01MB1202FA8F122134F7153D26F7F2192@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
On Sat, Jun 13, 2026 at 03:38:46AM +0000, Changhuang Liang wrote:
> Hi, Conor
>
> Thanks for the review.
>
> > On Fri, Jun 12, 2026 at 05:58:55AM -0700, Changhuang Liang wrote:
> > > Add a new compatible string "snps,dwc-ssi-2.00a" for the Synopsys
> > > DesignWare SSI controller version 2.00a.
> >
> > Two things. Firstly, driver patch suggests a fallback to 1.01a is possible. Why
> > haven't you added one?
>
> Will support fallback.
>
> > Secondly, I am going to expect that when your starfive user for this appears in
> > my inbox that it has a device-specific compatible, so you may as well add that
> > now.
>
> Our standard SPI control is completely based on the Synopsys DesignWare SSI controller version 2.00a.
> However, for the controller that accesses the flash, a set of modifications has been made based on the
> Synopsys DesignWare SSI controller version 2.00a, and the driver part also requires specific adaptation.
>
> Therefore, on the JHB100 SoC, the initial device tree source I have planned looks like this:
>
> spi0: spi@17f20000 {
> compatible = "snps,dwc-ssi-2.00a";
> reg = <0x0 0x17f20000 0x0 0x10000>;
> };
>
> sfc0: spi@18000000 {
> compatible = "starfive,jhb100-spi";
> reg = <0x0 0x18000000 0x0 0x10000>;
> };
>
> Thus, I plan to add a new "starfive,jhb100-spi" compatible string for the controller that accesses the flash.
> For now, I intend to keep these as two separate series.
No, if you have two integrations of the designware IP with different
programming models on the jhb100 I expect to see two different
soc-specific compatibles used. I don't want to see bare synopsys
compatibles on the platforms I am looking after.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v3 2/3] dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
From: Tapio Reijonen @ 2026-06-15 10:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hugo Villeneuve
Cc: linux-kernel, linux-serial, devicetree, Tapio Reijonen
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-0-7e79f064bdd7@vaisala.com>
The MAX310x is a family of one- (max3107, max3108), two- (max3109) and
four-channel (max14830) UARTs. The binding pulls in
/schemas/serial/rs485.yaml at the chip level, describing a single set of
RS-485 properties - enough for the single-channel parts, but a
multi-channel chip can wire RS-485 differently on each channel.
Split the binding per compatible:
- single-channel parts (max3107, max3108): the chip node is itself the
serial port and carries the RS-485 properties, as before;
- multi-channel parts (max3109, max14830): the chip node is only a
container and is no longer a serial node; each channel is a "serial@N"
subnode that carries the standard serial.yaml/rs485.yaml properties
(and may host a serial slave device). max3109 has channels 0-1,
max14830 has 0-3.
This avoids a chip node that is simultaneously a serial node and the
parent of serial nodes. The driver still reads chip-level RS-485 for
single-channel and legacy device trees, so existing users are unaffected.
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
.../devicetree/bindings/serial/maxim,max310x.yaml | 92 +++++++++++++++++++++-
1 file changed, 90 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
index 889eeaca64a027b4d9e8ec87bcf63fcc8fd9d55b..e598dda4d13f514820ed8012f2fb2fc2aba3e669 100644
--- a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
+++ b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
@@ -9,6 +9,13 @@ title: Maxim MAX310X Advanced Universal Asynchronous Receiver-Transmitter (UART)
maintainers:
- Hugo Villeneuve <hvilleneuve@dimonoff.com>
+description:
+ The MAX310X is a family of SPI/I2C UARTs with one (max3107, max3108),
+ two (max3109) or four (max14830) channels. Single-channel parts are
+ described as a serial node with RS-485 properties on the chip node;
+ multi-channel parts use one "serial@N" child node per channel, each
+ carrying its own serial/RS-485 properties.
+
properties:
compatible:
enum:
@@ -49,8 +56,55 @@ required:
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
- - $ref: /schemas/serial/serial.yaml#
- - $ref: /schemas/serial/rs485.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max3107
+ - maxim,max3108
+ then:
+ allOf:
+ - $ref: /schemas/serial/serial.yaml#
+ - $ref: /schemas/serial/rs485.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max3109
+ - maxim,max14830
+ then:
+ properties:
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+ patternProperties:
+ "^serial@[0-3]$":
+ type: object
+ description: A single UART channel of the chip.
+ allOf:
+ - $ref: /schemas/serial/serial.yaml#
+ - $ref: /schemas/serial/rs485.yaml#
+ properties:
+ reg:
+ description: UART channel number on the chip.
+ maximum: 3
+ required:
+ - reg
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max3109
+ then:
+ patternProperties:
+ "^serial@[23]$": false
unevaluatedProperties: false
@@ -70,5 +124,39 @@ examples:
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
gpio-controller;
#gpio-cells = <2>;
+ rs485-rts-active-low;
+ linux,rs485-enabled-at-boot-time;
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ serial@0 {
+ compatible = "maxim,max14830";
+ reg = <0>;
+ spi-max-frequency = <26000000>;
+ clocks = <&xtal4m>;
+ clock-names = "xtal";
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ serial@0 {
+ reg = <0>;
+ rs485-rts-active-low;
+ linux,rs485-enabled-at-boot-time;
+ };
+
+ serial@2 {
+ reg = <2>;
+ rs485-rts-active-low;
+ };
};
};
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/3] serial: max310x: honour per-channel DT RS485 properties
From: Tapio Reijonen @ 2026-06-15 10:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hugo Villeneuve
Cc: linux-kernel, linux-serial, devicetree, Tapio Reijonen
The MAX310x DT binding pulls in /schemas/serial/rs485.yaml via its allOf
list, but the driver has never actually called uart_get_rs485_mode(), so
none of the advertised rs485-* properties take effect at runtime.
This series wires per-channel RS485 DT configuration end to end:
Patch 1 reorders the probe so the gpio_chip is registered before
uart_add_one_port(). A port can then reference one of the chip's own
GPIOs (e.g. rs485-term-gpios = <&max310x ...>) without -EPROBE_DEFER
from its own provider - prerequisite for patch 3.
Patch 2 splits the binding per compatible. Single-channel parts
(max3107, max3108) keep RS485 on the chip node, which is itself the
serial port. Multi-channel parts (max3109, max14830) describe each
channel as a "serial@N" subnode carrying the standard rs485.yaml
properties; the chip node is then only a container and is no longer
itself a serial node, which avoids a serial node that is also the parent
of serial nodes. Being serial nodes, the channels may also host serial
slave devices. (max3109 has channels 0-1, max14830 has 0-3.)
Patch 3 reads each channel's RS485 properties from its own subnode by
temporarily retargeting dev->fwnode while uart_get_rs485_mode() runs.
For single-channel variants, falls back to the chip's own fwnode when no
subnode is present, so existing top-level rs485 DTs keep working.
Note for maintainers: patch 3 mutates the parent SPI/I2C device's
fwnode around the uart_get_rs485_mode() call so the underlying
property/GPIO lookups resolve against the per-channel DT subnode. Probe
is serialised, so the swap is locally safe, but I'd appreciate feedback
on whether this idiom is acceptable. If a cleaner shape is preferred (a
serial_core helper that takes a fwnode directly, or one struct device
per port), I'll respin accordingly.
Tested on max14830 (SPI, 4 ports): each ttyMAXn port comes up with the
rs485 flags and delays configured in its serial@N subnode, and the
termination GPIO sourced from the MAX310x's own gpio_chip is resolved
without probe deferral.
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
Changes in v3:
- dt-bindings: split per compatible so the chip node is a serial node only
for the single-channel max3107/max3108; the multi-channel max3109/max14830
are containers with serial@N child nodes and the chip node is no longer
itself a serial node. This avoids a node that is simultaneously a serial
node and the parent of serial nodes. (Krzysztof)
- dt-bindings: move the device/DT-model explanation into a top-level
description.
- Rebase onto v7.1-rc7.
- Patches 1 and 3 (driver) are unchanged; patch 3 still uses the temporary
fwnode retarget (idiom flagged above).
- Link to v2: https://lore.kernel.org/r/20260601-b4-max310x-rs485-dt-v2-0-a105105f8e70@vaisala.com
Changes in v2:
- dt-bindings: rename the per-port subnode "port@N" -> "serial@N" so each
channel is a proper serial node (serial.yaml) that can also host a
serial slave device; "port" is reserved for the graph binding. (Krzysztof)
- dt-bindings: constrain channels per compatible - max3107/max3108 take no
subnodes (nor #address-cells/#size-cells), max3109 allows 0-1, max14830
allows 0-3; out-of-range channels now fail dt_binding_check. (Krzysztof)
- serial: max310x: match the "serial" child node name accordingly.
- No change to patch 1; patch 3 still reads rs485 via the temporary fwnode
retarget (idiom flagged above).
- Link to v1: https://lore.kernel.org/r/20260525-b4-max310x-rs485-dt-v1-0-e6c19b4d5592@vaisala.com
---
Tapio Reijonen (3):
serial: max310x: register GPIO controller before adding UART ports
dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
serial: max310x: honour rs485 properties from per-channel DT subnode
.../devicetree/bindings/serial/maxim,max310x.yaml | 92 +++++++++++++++++++++-
drivers/tty/serial/max310x.c | 91 ++++++++++++++++-----
2 files changed, 160 insertions(+), 23 deletions(-)
---
base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
change-id: 20260525-b4-max310x-rs485-dt-ebff12af9976
Best regards,
--
Tapio Reijonen <tapio.reijonen@vaisala.com>
^ permalink raw reply
* [PATCH v3 1/3] serial: max310x: register GPIO controller before adding UART ports
From: Tapio Reijonen @ 2026-06-15 10:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hugo Villeneuve
Cc: linux-kernel, linux-serial, devicetree, Tapio Reijonen
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-0-7e79f064bdd7@vaisala.com>
The MAX310x exposes four GPIOs per UART port via an in-driver
gpio_chip. devm_gpiochip_add_data() used to run after the per-port
uart_add_one_port() loop, so a device-tree consumer referencing one of
the chip's own GPIOs (for example rs485-term-gpios = <&max310x 0 ...>)
could not resolve it during port registration: the GPIO provider it
waits for is the very driver still trying to register, and the lookup
returns -EPROBE_DEFER on its own provider, deferring probe forever.
Split the per-port setup into two passes around the gpio_chip
registration:
1. Initialise per-port state - port struct fields, regmap binding,
IRQ disable, work queues. The gpio_chip callbacks dereference
s->p[i].regmap via to_max310x_port() and become callable as soon
as the chip is visible to gpiolib, so every entry must be
populated first.
2. devm_gpiochip_add_data() - register the gpio_chip.
3. Allocate a line, uart_add_one_port(), set_bit(), max310x_power().
Keeping line allocation, registration and set_bit() together
preserves the existing "bit set <=> port registered" rollback
invariant that out_uart relies on.
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
drivers/tty/serial/max310x.c | 54 +++++++++++++++++++++++++++-----------------
1 file changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index ac7d3f197c3a5ce3531d5607f48e21a807314021..5cb7d01e404663dc25b88bc7b4f8df61be2135ec 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1364,17 +1364,12 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk);
+ /*
+ * Set up each port's state before registering the gpiochip,
+ * since the gpiochip callbacks will read s->p[i].regmap as
+ * soon as gpiolib exposes the controller.
+ */
for (i = 0; i < devtype->nr; i++) {
- unsigned int line;
-
- line = find_first_zero_bit(max310x_lines, MAX310X_UART_NRMAX);
- if (line == MAX310X_UART_NRMAX) {
- ret = -ERANGE;
- goto out_uart;
- }
-
- /* Initialize port data */
- s->p[i].port.line = line;
s->p[i].port.dev = dev;
s->p[i].port.irq = irq;
s->p[i].port.type = PORT_MAX310X;
@@ -1404,20 +1399,16 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
INIT_WORK(&s->p[i].md_work, max310x_md_proc);
/* Initialize queue for changing RS485 mode */
INIT_WORK(&s->p[i].rs_work, max310x_rs_proc);
-
- /* Register port */
- ret = uart_add_one_port(&max310x_uart, &s->p[i].port);
- if (ret)
- goto out_uart;
-
- set_bit(line, max310x_lines);
-
- /* Go to suspend mode */
- max310x_power(&s->p[i].port, 0);
}
#ifdef CONFIG_GPIOLIB
- /* Setup GPIO controller */
+ /*
+ * Register the GPIO controller before adding the UART ports so
+ * that consumers referencing the chip's own GPIOs from device
+ * tree (for example rs485-term-gpios = <&max310x ...>) can
+ * resolve them at uart_add_one_port() time instead of receiving
+ * -EPROBE_DEFER from their own provider.
+ */
s->gpio.owner = THIS_MODULE;
s->gpio.parent = dev;
s->gpio.label = devtype->name;
@@ -1434,6 +1425,27 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
goto out_uart;
#endif
+ for (i = 0; i < devtype->nr; i++) {
+ unsigned int line;
+
+ line = find_first_zero_bit(max310x_lines, MAX310X_UART_NRMAX);
+ if (line == MAX310X_UART_NRMAX) {
+ ret = -ERANGE;
+ goto out_uart;
+ }
+ s->p[i].port.line = line;
+
+ /* Register port */
+ ret = uart_add_one_port(&max310x_uart, &s->p[i].port);
+ if (ret)
+ goto out_uart;
+
+ set_bit(line, max310x_lines);
+
+ /* Go to suspend mode */
+ max310x_power(&s->p[i].port, 0);
+ }
+
/* Setup interrupt */
ret = devm_request_threaded_irq(dev, irq, NULL, max310x_ist,
IRQF_ONESHOT | IRQF_SHARED, dev_name(dev), s);
--
2.47.3
^ permalink raw reply related
* [PATCH v3 3/3] serial: max310x: honour rs485 properties from per-channel DT subnode
From: Tapio Reijonen @ 2026-06-15 10:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hugo Villeneuve
Cc: linux-kernel, linux-serial, devicetree, Tapio Reijonen
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-0-7e79f064bdd7@vaisala.com>
The MAX310x DT binding pulls in /schemas/serial/rs485.yaml via its allOf
list, advertising the rs485-* properties defined there - none of which
were honoured at runtime, because the driver never called
uart_get_rs485_mode().
All channels share the parent SPI/I2C device, so uart_get_rs485_mode()
called directly on each port would read the same chip-level fwnode for
every call. Walk dev->of_node's children for the "serial@N" subnode
with matching reg, and temporarily retarget the parent device's fwnode
while uart_get_rs485_mode() runs, so each channel picks up its own
subnode's properties. Probe is serialised, so the swap is safe.
For single-channel variants (max3107, max3108), fall back to the chip's
own fwnode when no subnode is present, so existing DTs that declare
rs485 properties at the top level keep working.
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
drivers/tty/serial/max310x.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 5cb7d01e404663dc25b88bc7b4f8df61be2135ec..aee3b75fff000385a7543f099663c8a0e4a7d014 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1426,6 +1426,9 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
#endif
for (i = 0; i < devtype->nr; i++) {
+ struct fwnode_handle *saved_fwnode = dev_fwnode(dev);
+ struct device_node *port_np = NULL;
+ struct device_node *child;
unsigned int line;
line = find_first_zero_bit(max310x_lines, MAX310X_UART_NRMAX);
@@ -1435,6 +1438,40 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
}
s->p[i].port.line = line;
+ /* Locate the matching "serial@i" DT subnode, if any. */
+ for_each_available_child_of_node(dev->of_node, child) {
+ u32 reg;
+
+ if (!of_node_name_eq(child, "serial"))
+ continue;
+ if (of_property_read_u32(child, "reg", ®))
+ continue;
+ if (reg == i) {
+ port_np = child;
+ break;
+ }
+ }
+
+ /*
+ * Temporarily retarget dev's fwnode to the per-port subnode
+ * so uart_get_rs485_mode() picks up the per-port properties.
+ * For single-port variants, fall back to the chip's own
+ * fwnode so legacy DTs that declare rs485 properties at the
+ * top level keep working.
+ */
+ if (port_np) {
+ device_set_node(dev, of_fwnode_handle(port_np));
+ ret = uart_get_rs485_mode(&s->p[i].port);
+ device_set_node(dev, saved_fwnode);
+ of_node_put(port_np);
+ if (ret)
+ goto out_uart;
+ } else if (devtype->nr == 1) {
+ ret = uart_get_rs485_mode(&s->p[i].port);
+ if (ret)
+ goto out_uart;
+ }
+
/* Register port */
ret = uart_add_one_port(&max310x_uart, &s->p[i].port);
if (ret)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH V12 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: Andy Shevchenko @ 2026-06-15 10:28 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260611202607.85376-6-macroalpha82@gmail.com>
On Thu, Jun 11, 2026 at 03:26:02PM -0500, Chris Morgan wrote:
> Add power management support for the ICM42607 device driver.
...
> +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> + enum inv_icm42607_sensor_mode gyro,
> + enum inv_icm42607_sensor_mode accel,
> + bool temp, unsigned int *sleep_ms)
> +{
> + enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
> + enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
> + bool oldtemp = st->conf.temp_en;
> + unsigned int sleepval_ms;
> + unsigned int val;
> + int ret;
> +
> + if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
> + return 0;
This validation seems weak, see below why.
> + val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
> + val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
> + /*
> + * Note that temp being enabled here doesn't affect PM since
> + * per 10.25 of the datasheet the clock will be off by default
> + * if both the gyro and accel modes are off.
> + */
> + if (!temp)
> + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> + if (ret)
> + return ret;
> +
> + st->conf.gyro.mode = gyro;
> + st->conf.accel.mode = accel;
> + st->conf.temp_en = temp;
> + sleepval_ms = 0;
> + if (temp && !oldtemp)
> + sleepval_ms = max(sleepval_ms, INV_ICM42607_TEMP_STARTUP_TIME_MS);
> +
> + if (accel != oldaccel)
> + sleepval_ms = max(sleepval_ms, INV_ICM42607_ACCEL_STARTUP_TIME_MS);
> +
> + if (gyro != oldgyro)
> + sleepval_ms = max(sleepval_ms, INV_ICM42607_GYRO_STARTUP_TIME_MS);
Does it mean that it might be more than a single conditional to become true?
If so, the last code wins, which is most likely buggy approach. Can you put
a comment, and possible convert this to if-else-if, to clarify what's going
on here?
> + if (sleep_ms)
> + *sleep_ms = sleepval_ms;
> + else if (sleepval_ms)
> + fsleep(sleepval_ms * USEC_PER_MSEC);
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Julian Braha @ 2026-06-15 10:29 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <ai-dNlC1_nbQTy5Z@monoceros>
Hi Uwe,
On 6/15/26 07:37, Uwe Kleine-König wrote:
> IMHO selecting REGMAP_MMIO explicitly here is fine because at least to
> me it's not obvious that MFD_SYSCON enforces REGMAP_MMIO.
I think it's better to use comments to document non-obvious behavior,
rather than dead code.
E.g.:
'select MFD_SYSCON # selects REGMAP_MMIO'
But I guess this is not really worth bikeshedding over.
- Julian Braha
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: lemans-evk: Describe the PCIe M.2 Key E connector
From: Wei Deng @ 2026-06-15 10:32 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, manivannan.sadhasivam,
bartosz.golaszewski, quic_chezhou, cheng.jiang, shuai.zhang,
jinwang.li, xiuzhuo.shang, mengshi.wu
In-Reply-To: <20260608091702.3797437-2-wei.deng@oss.qualcomm.com>
The lemans EVK has the PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe 0 Root Port and
UART17 nodes through graph port/endpoint.
Also add 'compatible = "pciclass,0604"' to the pcieport0 node in
lemans.dtsi to allow the PCI subsystem to associate the DT node with
the PCI-to-PCI bridge device.
The M.2 Key E connector is powered by a 3.3V fixed regulator
(vreg_wcn_3p3) which is sourced from the board's 12V DC input rail
(vreg_dcin_12v). Both regulators are always-on and are required by the
pcie-m2-e-connector binding.
Also add the serial1 = &uart17 alias, which is required for the
Bluetooth serdev device to be enumerated on the UART17 interface.
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Changes in v2:
- Collected Reviewed-by tag and reorganized the patch
Link: https://lore.kernel.org/linux-arm-msm/20260608091702.3797437-2-wei.deng@oss.qualcomm.com/ [v1]
arch/arm64/boot/dts/qcom/lemans-evk.dts | 75 +++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/lemans.dtsi | 1 +
2 files changed, 76 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index 34dfc8d22b6a..b2967cb53760 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -21,6 +21,7 @@ aliases {
ethernet0 = ðernet0;
mmc1 = &sdhc;
serial0 = &uart10;
+ serial1 = &uart17;
serial2 = &uart0;
};
@@ -88,6 +89,38 @@ usb2_con_hs_ep: endpoint {
};
};
+ connector-3 {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <&vreg_wcn_3p3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcieport0_ep>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&uart17_ep>;
+ };
+ };
+ };
+ };
+
edp0-connector {
compatible = "dp-connector";
label = "EDP0";
@@ -178,6 +211,17 @@ vmmc_sdc: regulator-vmmc-sdc {
regulator-max-microvolt = <2950000>;
};
+ vreg_dcin_12v: regulator-dcin-12v {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_DCIN_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vreg_sdc: regulator-vreg-sdc {
compatible = "regulator-gpio";
@@ -191,6 +235,19 @@ vreg_sdc: regulator-vreg-sdc {
startup-delay-us = <100>;
};
+
+ vreg_wcn_3p3: regulator-wcn-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ vin-supply = <&vreg_dcin_12v>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&apps_rsc {
@@ -742,6 +799,14 @@ &pcie1_phy {
status = "okay";
};
+&pcieport0 {
+ port {
+ pcieport0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
+};
+
&pmm8654au_0_pon_resin {
linux,code = <KEY_VOLUMEDOWN>;
status = "okay";
@@ -970,6 +1035,16 @@ &uart10 {
status = "okay";
};
+&uart17 {
+ status = "okay";
+
+ port {
+ uart17_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
+ };
+};
+
&ufs_mem_hc {
reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
vcc-supply = <&vreg_l8a>;
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 353a6e6fd3ac..9afd6e8ebcdb 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -2779,6 +2779,7 @@ pcie0: pcie@1c00000 {
status = "disabled";
pcieport0: pcie@0 {
+ compatible = "pciclass,0604";
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v2 2/2] net: pse-pd: add Realtek/Broadcom PSE MCU driver
From: Simon Horman @ 2026-06-15 10:34 UTC (permalink / raw)
To: Oleksij Rempel
Cc: jelonek.jonas, kory.maincent, andrew+netdev, davem, edumazet,
kuba, pabeni, robh, krzk+dt, conor+dt, netdev, devicetree,
linux-kernel, daniel, bjorn
In-Reply-To: <ai_ITHd_xxt7an4q@pengutronix.de>
On Mon, Jun 15, 2026 at 11:39:24AM +0200, Oleksij Rempel wrote:
> Hi Jonas,
>
> On Mon, Jun 15, 2026 at 10:07:33AM +0100, Simon Horman wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > Full review at: https://sashiko.dev
>
> It probably sounds scary, but sashiko finds not all issues in one time.
> Bigger patches and more different included frameworks - increase findings
> probability a lot. With other words, it may more rounds than expected.
FWIIW, that matches my observations too.
...
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Daniel Lezcano @ 2026-06-15 10:34 UTC (permalink / raw)
To: Gaurav Kohli, Krzysztof Kozlowski
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <ec65893d-873a-4a62-b0e2-5008b2130545@oss.qualcomm.com>
On 6/13/26 13:05, Gaurav Kohli wrote:
>
>
> On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
>> On 12/06/2026 15:52, Gaurav Kohli wrote:
>>>
>>>
>>> On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
>>>> On 11/06/2026 13:12, Gaurav Kohli wrote:
>>>>>> Why? And where is this generic property defined? You cannot just
>>>>>> sprinkle generic properties in random bindings.
>>>>>>
>>>>>
>>>>> Ack, will add why part.
>>>>> These names are matched with the thermal mitigation device identifiers
>>>>> populated by remote firmware over QMI and define mitigation devices
>>>>> are
>>>>> exposed as cooling devices.
>>>>
>>>> No, -names correspond to values passed via DT, not some remote
>>>> firmware.
>>>> The remote firmware should give you interface which is explicit and
>>>> does
>>>> not need such properties.
>>>
>>> thanks Krzysztof for review, We need tmd-names because of following
>>> reasons:
>>>
>>> Following Daniel's series [1], the thermal framework supports
>>> mapping multiple cooling devices per remoteproc/device via indexed
>>> cooling-cells.
>>>
>>> 1) The thermal framework's cooling-maps reference
>>> cooling devices by index (for #cooling-cells = <3>). Without tmd-names,
>>> there's no way to know which index corresponds to which TMD, as firmware
>>> may return tmd-names in any order.
>>>
>>> below are the changes post new thermal mapping changes:
>>> DT: tmd-names = "cdsp_sw", "xyz";
>>> Firmware: ["cdsp_sw", "xyz1", "xyz2",]
>>> Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
>>
>> names property are not to instruct drivers to register or not to
>> register something.
>>
>> I don't understand the problem and explanation in the binding is
>> basically non-existing.
>>
>> Remember that all lists and indices ARE FIXED, so driver knows exactly
>> which index means what.
>>
>
> thanks for review, shall i use driver data, which is basically pas data
> structure like below:
>
> static const struct qcom_pas_data {
> .crash_reason_smem = 601,
> .firmware_name = "cdsp.mdt",
> .tmd_names = (const char *[]){"xyz", NULL},
> .num_tmds = 1,
>
> Is something like above acceptable? and this will also help to filter
> tmd names as well?
How the thermal framework will bind the thermal zone with the TMD ?
(node pointer, id) ?
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
From: sashiko-bot @ 2026-06-15 10:38 UTC (permalink / raw)
To: Tapio Reijonen; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-2-7e79f064bdd7@vaisala.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Schema backward compatibility break for legacy multi-channel device trees by removing $refs to serial/rs485 schemas at the chip level.
--
commit d832a7d0f42d71a0c331f81efe607eabea305da1
Author: Tapio Reijonen <tapio.reijonen@vaisala.com>
dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
This commit splits the binding for the MAX310x UART family, introducing
per-channel child nodes for multi-channel parts while keeping single-channel
parts as serial nodes. It removes the top-level serial and RS-485 references
and conditionally maps them based on the compatible string.
> diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
> index 889eeaca64a02..e598dda4d13f5 100644
> --- a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
> +++ b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
[ ... ]
> @@ -49,8 +56,55 @@ required:
>
> allOf:
> - $ref: /schemas/spi/spi-peripheral-props.yaml#
> - - $ref: /schemas/serial/serial.yaml#
> - - $ref: /schemas/serial/rs485.yaml#
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - maxim,max3107
> + - maxim,max3108
> + then:
> + allOf:
> + - $ref: /schemas/serial/serial.yaml#
> + - $ref: /schemas/serial/rs485.yaml#
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - maxim,max3109
> + - maxim,max14830
> + then:
> + properties:
[Severity: Medium]
The commit message notes that existing users are unaffected because the driver
still reads chip-level RS-485 for single-channel and legacy device trees.
However, does this change break schema validation for legacy multi-channel
device trees?
By removing the top-level references to serial.yaml and rs485.yaml for
multi-channel parts, and because the binding uses unevaluatedProperties: false
at the top level, any legacy multi-channel device trees that still declare
serial or RS-485 properties at the chip level will now trigger unevaluated
property validation errors during dtbs_check.
Could we retain the top-level references for multi-channel parts, perhaps with
a deprecation note, to preserve ABI backward compatibility for existing device
trees?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-b4-max310x-rs485-dt-v3-0-7e79f064bdd7@vaisala.com?part=2
^ permalink raw reply
* Re: [PATCH v3 3/3] serial: max310x: honour rs485 properties from per-channel DT subnode
From: sashiko-bot @ 2026-06-15 10:39 UTC (permalink / raw)
To: Tapio Reijonen; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-3-7e79f064bdd7@vaisala.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Medium] Temporary modification of registered device's `fwnode` creates a data race with sysfs/bus iterators.
Pre-existing issues:
- [Critical] Uninitialized port line values in `out_uart` cleanup path cause deregistration of other devices' serial ports.
- [High] Unprotected global bitmap `max310x_lines` allows concurrent probes to allocate the same UART line, leading to state corruption.
- [High] Missing registration ordering: UART port is exposed to userspace before its interrupt handler is registered.
--
commit 0bd4955b2ec9441be6e7a42bfe7ca700f31859d2
Author: Tapio Reijonen <tapio.reijonen@vaisala.com>
serial: max310x: honour rs485 properties from per-channel DT subnode
This commit updates the MAX310x driver to parse rs485 properties from
per-channel device tree subnodes by temporarily retargeting the parent
device's fwnode. It falls back to the top-level node for single-channel
variants.
> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c
[ ... ]
> @@ -1426,6 +1426,9 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
> #endif
>
> for (i = 0; i < devtype->nr; i++) {
> + struct fwnode_handle *saved_fwnode = dev_fwnode(dev);
> + struct device_node *port_np = NULL;
> + struct device_node *child;
> unsigned int line;
>
> line = find_first_zero_bit(max310x_lines, MAX310X_UART_NRMAX);
[Severity: High]
This is a pre-existing issue, but does this lockless read of the global
bitmap allow concurrent probes to allocate the same UART line?
Since find_first_zero_bit() is called here, but set_bit() is only called
much later after port registration and DT parsing, multiple asynchronous
probes could observe the same zero bit.
Could the second thread fail in uart_add_one_port() due to a collision, jump
to the cleanup path, and erroneously clear the bit that the first thread
successfully registered?
> if (line == MAX310X_UART_NRMAX) {
> ret = -ERANGE;
> goto out_uart;
> }
> s->p[i].port.line = line;
>
> + /* Locate the matching "serial@i" DT subnode, if any. */
> + for_each_available_child_of_node(dev->of_node, child) {
[ ... ]
> + /*
> + * Temporarily retarget dev's fwnode to the per-port subnode
> + * so uart_get_rs485_mode() picks up the per-port properties.
> + * For single-port variants, fall back to the chip's own
> + * fwnode so legacy DTs that declare rs485 properties at the
> + * top level keep working.
> + */
> + if (port_np) {
> + device_set_node(dev, of_fwnode_handle(port_np));
[Severity: Medium]
Does temporarily swapping the fwnode on a live device create a data race
with sysfs or bus iterators?
Since the parent SPI/I2C device is already registered with the driver core
and visible in sysfs at this stage, locklessly modifying dev->fwnode and
dev->of_node could expose a torn pointer state to concurrent udev events or
subsystem iterators.
> + ret = uart_get_rs485_mode(&s->p[i].port);
> + device_set_node(dev, saved_fwnode);
> + of_node_put(port_np);
> + if (ret)
> + goto out_uart;
> + } else if (devtype->nr == 1) {
> + ret = uart_get_rs485_mode(&s->p[i].port);
> + if (ret)
> + goto out_uart;
> + }
>
> /* Register port */
> ret = uart_add_one_port(&max310x_uart, &s->p[i].port);
[Severity: High]
This is a pre-existing issue, but could this ordering lead to unhandled
interrupts if the port is opened immediately?
Because uart_add_one_port() makes the port available to userspace, udev or a
getty could open it before the probe loop finishes. If the port is opened
and powers on, the hardware might assert the IRQ line before
devm_request_threaded_irq() is called later in max310x_probe(), potentially
causing the IRQ core to permanently disable the shared interrupt line.
> if (ret)
> goto out_uart;
[ ... ]
> out_uart:
> for (i = 0; i < devtype->nr; i++) {
> if (test_and_clear_bit(s->p[i].port.line, max310x_lines))
> uart_remove_one_port(&max310x_uart, &s->p[i].port);
> }
[Severity: Critical]
This is a pre-existing issue, but can this cleanup path unregister active
ports belonging to completely different devices?
During early probe failure, the allocated port structures are zeroed out,
meaning uninitialized elements have their port.line set to 0. Since this
loop unconditionally iterates over all devtype->nr elements, it will call
test_and_clear_bit() on line 0.
If another max310x instance has already probed and owns line 0, couldn't
this accidentally clear the other device's bit and forcefully unregister its
active port via uart_remove_one_port(), leading to a kernel panic or
use-after-free?
> out_clk:
> clk_disable_unprepare(s->clk);
>
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-b4-max310x-rs485-dt-v3-0-7e79f064bdd7@vaisala.com?part=3
^ permalink raw reply
* Re: [PATCH v11 4/6] arm64: dts: qcom: kodiak: Add OPP-table for ICE UFS and ICE eMMC nodes
From: Kuldeep Singh @ 2026-06-15 10:42 UTC (permalink / raw)
To: Abhinaba Rakshit
Cc: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
James E.J. Bottomley, Martin K. Petersen, Adrian Hunter,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neeraj Soni, Harshal Dev, linux-arm-msm, linux-kernel, linux-scsi,
linux-mmc, devicetree
In-Reply-To: <ai+x7Ovc9/pPTu9f@hu-arakshit-hyd.qualcomm.com>
>> To align with sdhc_ice(as label name), can we rename to ice_sdhc_opp_table?
>
> Do you mean sdhc_ice_opp_table?
Yes.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v3 1/3] serial: max310x: register GPIO controller before adding UART ports
From: sashiko-bot @ 2026-06-15 10:43 UTC (permalink / raw)
To: Tapio Reijonen; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-1-7e79f064bdd7@vaisala.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
Pre-existing issues:
- [High] The `out_uart` error path relies on zero-initialized `port.line` values, causing it to erroneously clear line 0 from the global bitmap.
- [High] Concurrent allocation of UART lines using the global `max310x_lines` bitmap lacks locking, leading to race conditions and probe failures.
- [High] The shared IRQ handler is registered after the UART ports are exposed to userspace, creating an unhandled interrupt window.
- [High] Missing `cancel_work_sync()` in the `out_uart` error path leaks synchronously queued work items, leading to a Use-After-Free.
- [High] The driver unconditionally powers off the device after registering the port, introducing a TOCTOU race with concurrent userspace access.
- [High] The driver accesses and modifies the `uart_port` state completely outside of `port->lock`, violating fundamental serial core locking rules.
--
commit e3ed4a711cf7a4f6df5863f1c7baec8925661b6f
Author: Tapio Reijonen <tapio.reijonen@vaisala.com>
serial: max310x: register GPIO controller before adding UART ports
The MAX310x exposes four GPIOs per UART port via an in-driver
gpio_chip. devm_gpiochip_add_data() used to run after the per-port
uart_add_one_port() loop, so a device-tree consumer referencing one of
the chip's own GPIOs (for example rs485-term-gpios = <&max310x 0 ...>)
could not resolve it during port registration: the GPIO provider it
waits for is the very driver still trying to register, and the lookup
returns -EPROBE_DEFER on its own provider, deferring probe forever.
Split the per-port setup into two passes around the gpio_chip
registration.
> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> index ac7d3f197c3a5..5cb7d01e40466 100644
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c
[ ... ]
> @@ -1434,6 +1425,27 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
> goto out_uart;
> #endif
>
> + for (i = 0; i < devtype->nr; i++) {
> + unsigned int line;
> +
> + line = find_first_zero_bit(max310x_lines, MAX310X_UART_NRMAX);
[Severity: High]
This is a pre-existing issue, but does the allocation of UART lines using
the global max310x_lines bitmap lack locking?
Multiple instances of the driver probing concurrently on different buses
could simultaneously find the same zero bit and assign the same line number.
Since set_bit is deferred until after uart_add_one_port completes, the
second instance to call uart_add_one_port would fail with -EINVAL. Could
this cause the probe to abort and jump to the out_uart cleanup path?
> + if (line == MAX310X_UART_NRMAX) {
> + ret = -ERANGE;
> + goto out_uart;
> + }
> + s->p[i].port.line = line;
> +
> + /* Register port */
> + ret = uart_add_one_port(&max310x_uart, &s->p[i].port);
> + if (ret)
> + goto out_uart;
> +
> + set_bit(line, max310x_lines);
> +
> + /* Go to suspend mode */
> + max310x_power(&s->p[i].port, 0);
[Severity: High]
This is a pre-existing issue, but is there a race condition with userspace
access when unconditionally powering off the device here?
The port is exposed to userspace via uart_add_one_port just before this.
If userspace opens the port in the exact window between these two calls,
max310x_startup will properly power the device on, but then this thread
will immediately execute the power-off sequence.
Could this leave an active port unpowered and completely unresponsive?
> + }
> +
> /* Setup interrupt */
> ret = devm_request_threaded_irq(dev, irq, NULL, max310x_ist,
> IRQF_ONESHOT | IRQF_SHARED, dev_name(dev), s);
[Severity: High]
This is a pre-existing issue, but does registering the shared IRQ handler
after exposing the UART ports to userspace create an unhandled interrupt
window?
Userspace can immediately open the port, invoking max310x_startup, which
synchronously enables chip-level hardware interrupts via MAX310X_IRQEN_REG.
If the hardware asserts the IRQ line before devm_request_threaded_irq is
called here, the kernel receives an unhandled interrupt.
Since the interrupt is requested with IRQF_SHARED, could this unhandled
interrupt trigger the spurious interrupt detector to permanently disable
the shared interrupt line, causing the device to hang?
[Severity: High]
This is another pre-existing issue, but can the out_uart cleanup path clear
the wrong bit in the max310x_lines bitmap?
If find_first_zero_bit or devm_gpiochip_add_data fails, the code jumps
to out_uart. Because the port structures are zero-initialized via
devm_kzalloc, the port.line field defaults to 0.
The cleanup loop iterates over all ports:
out_uart:
for (i = 0; i < devtype->nr; i++) {
if (test_and_clear_bit(s->p[i].port.line, max310x_lines))
...
If another max310x device successfully claimed line 0, would its bit be
wrongfully cleared, permanently corrupting the resource tracking for future
allocations?
[Severity: High]
This is also a pre-existing issue, but does the out_uart error path leak
synchronously queued work items?
During port registration, uart_add_one_port invokes max310x_rs485_config
if SER_RS485_ENABLED is set, which unconditionally schedules one->rs_work.
If a subsequent initialization step fails and the probe jumps to out_uart,
the driver structure is freed by devres. However, cancel_work_sync is not
called for rs_work.
When the workqueue scheduler later executes the pending work, will it
dereference freed memory?
[Severity: High]
Finally, this is a pre-existing issue, but does the driver modify the
uart_port state outside of the port->lock?
In max310x_handle_tx, the transmit FIFO is modified using
kfifo_out_linear_ptr and uart_xmit_advance is called. Similarly,
max310x_port_irq calls uart_handle_cts_change.
None of these execution paths acquire spin_lock(&port->lock). Could this
lead to data corruption and inconsistent state when racing with concurrent
TTY core operations, such as tty_write modifying the FIFO?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-b4-max310x-rs485-dt-v3-0-7e79f064bdd7@vaisala.com?part=1
^ permalink raw reply
* Re: [PATCH] mips: dts: ar9132: fix wdt node name
From: Thomas Bogendoerfer @ 2026-06-15 10:28 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-mips, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260608053202.12004-1-rosenp@gmail.com>
On Sun, Jun 07, 2026 at 10:32:02PM -0700, Rosen Penev wrote:
> Fixes the following warning:
>
> $nodename:0: 'wdt@18060008' does not match
> '^(timer|watchdog)(@.*|-([0-9]|[1-9][0-9]+))?$'
> from schema $id: http://devicetree.org/schemas/watchdog/qca,ar7130-wdt.yaml#
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> arch/mips/boot/dts/qca/ar9132.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/boot/dts/qca/ar9132.dtsi b/arch/mips/boot/dts/qca/ar9132.dtsi
> index 4d3c48a9f9fd..77225ed459cb 100644
> --- a/arch/mips/boot/dts/qca/ar9132.dtsi
> +++ b/arch/mips/boot/dts/qca/ar9132.dtsi
> @@ -98,7 +98,7 @@ pll: pll-controller@18050000 {
> clock-output-names = "cpu", "ddr", "ahb";
> };
>
> - wdt: wdt@18060008 {
> + wdt: watchdog@18060008 {
> compatible = "qca,ar7130-wdt";
> reg = <0x18060008 0x8>;
>
> --
> 2.54.0
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Konrad Dybcio @ 2026-06-15 10:44 UTC (permalink / raw)
To: Iskren Chernev, Konrad Dybcio, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Greg Kroah-Hartman, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <5b474af3-f651-4a64-a5b9-c18136e589eb@iskren.info>
On 6/14/26 2:29 PM, Iskren Chernev wrote:
>
>
> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> I don't know where the existing one came from, but it's apparently
>> wrong, according to both docs and a downstream DT [1]. Fix it up.
>
> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
>
> The phone was bough early after launch, so it could have been wrong/updated later.
Good to see you're still around!
Looks like vendor tuning. I see that even the initial commit for
6115 had the init sequence I posted. And the OnePlus sources have
what seems like a project-specific local copy of the DTSI:
https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148
To support that, we should add a new property to override the TUNEx
registers - like e.g. qcom,hstx-trim-value that's already consumed
Would you like to look into that, or should I take this?
Konrad
^ permalink raw reply
* [PATCH v3 0/5] Add PLL3 and LCDC_CLKD support for RZ/T2H and RZ/N2H
From: Prabhakar @ 2026-06-15 10:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi all,
This series adds support for the PLL3 and LCDC_CLKD clocks on Renesas
RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs. These clocks are essential
for the display pipeline, specifically feeding the LCD controller.
Key Changes:
- PLL Reference Flexibility in the RZ/V2H(P) CPG driver
- MSTP Dummy-Read Mechanism
- LCDC implementation in the RZ/T2H CPG driver.
v2->v3:
- Added export.h include in rzv2h-cpg-lib.c.
- In r9a09g077_cpg_lcdc_div_determine_rate() made use of
clk_hw_get_parent_by_index() to ensure we retrieve pll3 as the parent.
v1->v2:
https://lore.kernel.org/all/20260609105924.962573-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
- Dropped RZ_V2H_OSC_CLK_IN_MEGA macro in favor of direct use of the
input_fref field with a fallback.
- Updated the doc to specify the default value of input_freq when it is 0.
- Updated commit message for patch 1 and 2 to reflect the new approach.
- Dropped using table based approach in favor of direct conditional checks
on the clock index.
- Added Acked-by and Reviewed-by tags
- Added new patch#4
- Switched to use the new library
- Kconfig now selects CLK_RZV2H_CPG_LIB
- Renamed CPG_PLLEN to CPG_PLL_EN_EN
- Renamed LCDCDIV to LCDC_CLKD
- Changed ctr0/1 in r9a09g077_cpg_pll3_clk_recalc_rate() to use u32
v1: https://lore.kernel.org/all/20260511191910.1945705-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Prabhakar
Lad Prabhakar (5):
clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for
calculations
clk: renesas: cpg-mssr: Implement dedicated MSTP delay logic for
RZ/T2H LCDC and RTC
dt-bindings: clock: renesas,r9a09g077/87: Add LCDC_CLKD clock ID
clk: renesas: rzv2h-cpg: Extract PLL calculation math into a library
clk: renesas: r9a09g077: Add LCDC and PLL3 clock support for RZ/T2H
display pipeline
drivers/clk/renesas/Kconfig | 6 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r9a09g077-cpg.c | 373 +++++++++++++++++-
drivers/clk/renesas/renesas-cpg-mssr.c | 20 +-
drivers/clk/renesas/rzv2h-cpg-lib.c | 217 ++++++++++
drivers/clk/renesas/rzv2h-cpg.c | 186 +--------
.../clock/renesas,r9a09g077-cpg-mssr.h | 1 +
.../clock/renesas,r9a09g087-cpg-mssr.h | 1 +
include/linux/clk/renesas.h | 28 ++
9 files changed, 650 insertions(+), 183 deletions(-)
create mode 100644 drivers/clk/renesas/rzv2h-cpg-lib.c
--
2.54.0
^ permalink raw reply
* [PATCH v3 1/5] clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for calculations
From: Prabhakar @ 2026-06-15 10:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Introduce a per-SoC PLL reference input frequency parameter to avoid
relying on a hardcoded 24MHz constant during PLL configuration math.
Add an input_fref member to struct rzv2h_pll_limits. In the core
calculation helper rzv2h_get_pll_pars(), derive the base input clock
rate from limits->input_fref, utilizing the conditional ternary operator
to fall back to 24MHz if the struct field is left uninitialized (0), and
drop the obsolete macro RZ_V2H_OSC_CLK_IN_MEGA.
This abstraction permits the reuse of the common PLL divider logic on
newer SoC platforms like the RZ/T2H, which feature a 48 MHz PLL reference
clock input instead of the 24 MHz signal used by RZ/V2H(P), without
disrupting existing platforms.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v2->v3:
- No change
v1->v2:
- Dropped RZ_V2H_OSC_CLK_IN_MEGA macro in favor of direct use of the
input_fref field with a fallback.
- Updated the doc to specify the default value of input_freq when it is 0.
- Updated commit message
---
drivers/clk/renesas/rzv2h-cpg.c | 8 ++++----
include/linux/clk/renesas.h | 5 +++++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/renesas/rzv2h-cpg.c b/drivers/clk/renesas/rzv2h-cpg.c
index e271c04cee34..fff89f2bdc0b 100644
--- a/drivers/clk/renesas/rzv2h-cpg.c
+++ b/drivers/clk/renesas/rzv2h-cpg.c
@@ -218,7 +218,6 @@ struct rzv2h_plldsi_div_clk {
#define to_plldsi_div_clk(_hw) \
container_of(_hw, struct rzv2h_plldsi_div_clk, hw)
-#define RZ_V2H_OSC_CLK_IN_MEGA (24 * MEGA)
#define RZV2H_MAX_DIV_TABLES (16)
/**
@@ -242,6 +241,7 @@ struct rzv2h_plldsi_div_clk {
bool rzv2h_get_pll_pars(const struct rzv2h_pll_limits *limits,
struct rzv2h_pll_pars *pars, u64 freq_millihz)
{
+ unsigned long input_fref = limits->input_fref ?: (24 * MEGA);
u64 fout_min_millihz = mul_u32_u32(limits->fout.min, MILLI);
u64 fout_max_millihz = mul_u32_u32(limits->fout.max, MILLI);
struct rzv2h_pll_pars p, best;
@@ -254,7 +254,7 @@ bool rzv2h_get_pll_pars(const struct rzv2h_pll_limits *limits,
best.error_millihz = S64_MAX;
for (p.p = limits->p.min; p.p <= limits->p.max; p.p++) {
- u32 fref = RZ_V2H_OSC_CLK_IN_MEGA / p.p;
+ u32 fref = input_fref / p.p;
u16 divider;
for (divider = 1 << limits->s.min, p.s = limits->s.min;
@@ -335,9 +335,9 @@ bool rzv2h_get_pll_pars(const struct rzv2h_pll_limits *limits,
continue;
/* PLL_M component of (output * 65536 * PLL_P) */
- output = mul_u32_u32(p.m * 65536, RZ_V2H_OSC_CLK_IN_MEGA);
+ output = mul_u32_u32(p.m * 65536, input_fref);
/* PLL_K component of (output * 65536 * PLL_P) */
- output += p.k * RZ_V2H_OSC_CLK_IN_MEGA;
+ output += p.k * input_fref;
/* Make it in mHz */
output *= MILLI;
output = DIV_U64_ROUND_CLOSEST(output, 65536 * p.p * divider);
diff --git a/include/linux/clk/renesas.h b/include/linux/clk/renesas.h
index 0949400f44de..2aeff01150c3 100644
--- a/include/linux/clk/renesas.h
+++ b/include/linux/clk/renesas.h
@@ -53,6 +53,9 @@ static inline void rzg2l_cpg_dsi_div_set_divider(u8 divider, int target) { }
* various parameters used to configure a PLL. These limits ensure
* the PLL operates within valid and stable ranges.
*
+ * @input_fref: Reference input frequency to the PLL (in MHz). If set
+ * to 0, a default value of 24MHz is used.
+ *
* @fout: Output frequency range (in MHz)
* @fout.min: Minimum allowed output frequency
* @fout.max: Maximum allowed output frequency
@@ -78,6 +81,8 @@ static inline void rzg2l_cpg_dsi_div_set_divider(u8 divider, int target) { }
* @k.max: Maximum delta-sigma value
*/
struct rzv2h_pll_limits {
+ u32 input_fref;
+
struct {
u32 min;
u32 max;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/5] clk: renesas: cpg-mssr: Implement dedicated MSTP delay logic for RZ/T2H LCDC and RTC
From: Prabhakar @ 2026-06-15 10:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
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>
---
v2->v3:
- No change
v1->v2:
- Dropped using table based approach in favor of direct conditional checks on the clock index.
- Updated commit message to reflect the new approach.
---
drivers/clk/renesas/renesas-cpg-mssr.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c b/drivers/clk/renesas/renesas-cpg-mssr.c
index 5b84cbee030b..4ed056b18d31 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -253,6 +253,22 @@ static void cpg_rzt2h_mstp_write(struct cpg_mssr_priv *priv, u16 offset, u32 val
writel(value, base + RZT2H_MSTPCR_OFFSET(offset));
}
+static void cpg_rzt2h_mstp_delay(u32 idx, bool bit_valid)
+{
+ unsigned int mask = bit_valid ? GENMASK(31, 0) : GENMASK(31, 5);
+
+ if (idx == (MOD_CLK_PACK(1204) & mask)) {
+ /* LCDC needs 100 dummy reads, or 142us */
+ udelay(142);
+ } else if (idx == (MOD_CLK_PACK(605) & mask)) {
+ /* RTC needs 300 dummy reads, or 428us */
+ udelay(428);
+ } else {
+ /* default 7 dummy reads, or 10us */
+ udelay(10);
+ }
+}
+
static int cpg_mstp_clock_endisable(struct clk_hw *hw, bool enable)
{
struct mstp_clock *clock = to_mstp_clock(hw);
@@ -312,7 +328,7 @@ static int cpg_mstp_clock_endisable(struct clk_hw *hw, bool enable)
* register, we simply add a delay after the read operation.
*/
cpg_rzt2h_mstp_read(priv, priv->control_regs[reg]);
- udelay(10);
+ cpg_rzt2h_mstp_delay(clock->index, true);
return 0;
}
@@ -1142,7 +1158,7 @@ static int cpg_mssr_resume_noirq(struct device *dev)
cpg_rzt2h_mstp_write(priv, priv->control_regs[reg], newval);
/* See cpg_mstp_clock_endisable() on why this is necessary. */
cpg_rzt2h_mstp_read(priv, priv->control_regs[reg]);
- udelay(10);
+ cpg_rzt2h_mstp_delay(reg * 32, false);
continue;
} else
writel(newval, priv->pub.base0 + priv->control_regs[reg]);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/5] dt-bindings: clock: renesas,r9a09g077/87: Add LCDC_CLKD clock ID
From: Prabhakar @ 2026-06-15 10:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar, Conor Dooley
In-Reply-To: <20260615104845.4122868-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
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>
---
v2->v3:
- No change
v1->v2:
- Added Acked-by and Reviewed-by tags.
---
include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h | 1 +
include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h b/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h
index c4863e444458..f6cb8d649a46 100644
--- a/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h
+++ b/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h
@@ -34,5 +34,6 @@
#define R9A09G077_XSPI_CLK0 22
#define R9A09G077_XSPI_CLK1 23
#define R9A09G077_PCLKCAN 24
+#define R9A09G077_LCDC_CLKD 25
#endif /* __DT_BINDINGS_CLOCK_RENESAS_R9A09G077_CPG_H__ */
diff --git a/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h b/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h
index 0d53f1e65077..312e563b322e 100644
--- a/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h
+++ b/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h
@@ -34,5 +34,6 @@
#define R9A09G087_XSPI_CLK0 22
#define R9A09G087_XSPI_CLK1 23
#define R9A09G087_PCLKCAN 24
+#define R9A09G087_LCDC_CLKD 25
#endif /* __DT_BINDINGS_CLOCK_RENESAS_R9A09G087_CPG_H__ */
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox