Linux RTC
 help / color / mirror / Atom feed
* Re: [PATCH v1 05/10] dt-bindings: leds: leds-cpcap: convert to schema
From: David Lechner @ 2026-01-31 19:59 UTC (permalink / raw)
  To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
	Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
	Alexandre Belloni, Dixit Parmar, Tony Lindgren
  Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
	linux-rtc
In-Reply-To: <20260125134302.45958-6-clamor95@gmail.com>

On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert leds devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../devicetree/bindings/leds/leds-cpcap.txt   | 29 -------------
>  .../bindings/leds/motorola,cpcap-leds.yaml    | 42 +++++++++++++++++++
>  2 files changed, 42 insertions(+), 29 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
>  create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> deleted file mode 100644
> index ebf7cdc7f70c..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Motorola CPCAP PMIC LEDs
> -------------------------
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -Requires node properties:
> -- compatible: should be one of
> -   * "motorola,cpcap-led-mdl"		(Main Display Lighting)
> -   * "motorola,cpcap-led-kl"		(Keyboard Lighting)
> -   * "motorola,cpcap-led-adl"		(Aux Display Lighting)
> -   * "motorola,cpcap-led-red"		(Red Triode)
> -   * "motorola,cpcap-led-green"		(Green Triode)
> -   * "motorola,cpcap-led-blue"		(Blue Triode)
> -   * "motorola,cpcap-led-cf"		(Camera Flash)
> -   * "motorola,cpcap-led-bt"		(Bluetooth)
> -   * "motorola,cpcap-led-cp"		(Camera Privacy LED)
> -- label: see Documentation/devicetree/bindings/leds/common.txt
> -- vdd-supply: A phandle to the regulator powering the LED
> -
> -Example:
> -
> -&cpcap {
> -	cpcap_led_red: red-led {
> -		compatible = "motorola,cpcap-led-red";
> -		label = "cpcap:red";
> -		vdd-supply = <&sw5>;
> -	};
> -};
> diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> new file mode 100644
> index 000000000000..8dfc98a1ef99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC leds
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> +  This module is part of the Motorola CPCAP MFD device. For more details
> +  see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. Leds are

s/Leds/LEDs/

> +  represented as sub-nodes of the PMIC node on the device tree.
> +
> +allOf:
> +  - $ref: /schemas/leds/common.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - motorola,cpcap-led-adl # Display Lighting
> +      - motorola,cpcap-led-blue # Blue Triode
> +      - motorola,cpcap-led-bt # Bluetooth
> +      - motorola,cpcap-led-cf # Camera Flash
> +      - motorola,cpcap-led-cp # Camera Privacy LED
> +      - motorola,cpcap-led-green # Green Triode
> +      - motorola,cpcap-led-kl # Keyboard Lighting
> +      - motorola,cpcap-led-mdl # Main Display Lighting
> +      - motorola,cpcap-led-red # Red Triode
> +
> +  vdd-supply: true
> +
> +required:
> +  - compatible
> +  - label
> +  - vdd-supply
> +
> +unevaluatedProperties: false
> +

Should keep the example here.

> +...


^ permalink raw reply

* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: David Lechner @ 2026-01-31 19:55 UTC (permalink / raw)
  To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
	Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
	Alexandre Belloni, Dixit Parmar, Tony Lindgren
  Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
	linux-rtc
In-Reply-To: <d7938728-fded-4d5e-b23d-a8346e3fab46@baylibre.com>

On 1/31/26 1:46 PM, David Lechner wrote:
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
>> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
>> from TXT to YAML format. Main functionality preserved and added compatible
>> for CPCAP regulator set found in the Mot board.
>>

...

>> +properties:
>> +  compatible:
>> +    enum:
>> +      - motorola,cpcap-regulator
>> +      - motorola,mapphone-cpcap-regulator
>> +      - motorola,mot-cpcap-regulator

This is what caused me to get confused on the order of the later patches.

motorola,mot-cpcap-regulator is a new compatible, so would be better as
a separate patch.


^ permalink raw reply

* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: David Lechner @ 2026-01-31 19:50 UTC (permalink / raw)
  To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
	Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
	Alexandre Belloni, Dixit Parmar, Tony Lindgren
  Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
	linux-rtc
In-Reply-To: <92858c73-1e11-4283-8ab6-1188e8bae0df@baylibre.com>

On 1/31/26 1:48 PM, David Lechner wrote:
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
>> Add compatible for ADC used in Mot board. Separate compatible is required
>> since ADC in the Mot board uses a unique set of configurations.
>>
> Logically, it makes more sense to readers to put the DT binding patch
> before the driver change in the series.

OK, I didn't read carefully enough that there are multiple devices
in this series. So you already did what I suggested. :-)


^ permalink raw reply

* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: David Lechner @ 2026-01-31 19:48 UTC (permalink / raw)
  To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
	Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
	Alexandre Belloni, Dixit Parmar, Tony Lindgren
  Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
	linux-rtc
In-Reply-To: <20260125134302.45958-4-clamor95@gmail.com>

On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Add compatible for ADC used in Mot board. Separate compatible is required
> since ADC in the Mot board uses a unique set of configurations.
> 
Logically, it makes more sense to readers to put the DT binding patch
before the driver change in the series.

^ permalink raw reply

* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: David Lechner @ 2026-01-31 19:46 UTC (permalink / raw)
  To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
	Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
	Alexandre Belloni, Dixit Parmar, Tony Lindgren
  Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
	linux-rtc
In-Reply-To: <20260125134302.45958-2-clamor95@gmail.com>

On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> from TXT to YAML format. Main functionality preserved and added compatible
> for CPCAP regulator set found in the Mot board.
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../bindings/regulator/cpcap-regulator.txt    | 35 -------------
>  .../regulator/motorola,cpcap-regulator.yaml   | 51 +++++++++++++++++++
>  2 files changed, 51 insertions(+), 35 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
>  create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> 
> diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> deleted file mode 100644
> index 36f5e2f5cc0f..000000000000
> --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -Motorola CPCAP PMIC voltage regulators
> -------------------------------------
> -
> -Requires node properties:
> -- "compatible" value one of:
> -    "motorola,cpcap-regulator"
> -    "motorola,mapphone-cpcap-regulator"
> -    "motorola,xoom-cpcap-regulator"
> -
> -Required regulator properties:
> -- "regulator-name"
> -- "regulator-enable-ramp-delay"
> -- "regulator-min-microvolt"
> -- "regulator-max-microvolt"
> -
> -Optional regulator properties:
> -- "regulator-boot-on"
> -
> -See Documentation/devicetree/bindings/regulator/regulator.txt
> -for more details about the regulator properties.
> -
> -Example:
> -
> -cpcap_regulator: regulator {
> -	compatible = "motorola,cpcap-regulator";
> -
> -	cpcap_regulators: regulators {
> -		sw5: SW5 {

Old example is missing the required regulator-names property.

> -			regulator-min-microvolt = <5050000>;
> -			regulator-max-microvolt = <5050000>;
> -			regulator-enable-ramp-delay = <50000>;
> -			regulator-boot-on;
> -		};
> -	};
> -};
> diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> new file mode 100644
> index 000000000000..b73d32a86904
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC regulators
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> +  This module is part of the Motorola CPCAP MFD device. For more details
> +  see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> +  regulator controller is represented as a sub-node of the PMIC node
> +  on the device tree.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - motorola,cpcap-regulator
> +      - motorola,mapphone-cpcap-regulator
> +      - motorola,mot-cpcap-regulator
> +      - motorola,xoom-cpcap-regulator
> +
> +  regulators:
> +    type: object
> +
> +    patternProperties:
> +      "$[A-Z0-9]+^":

Why not put the valid names here? Or does the node name not actually matter?
(in which case lower case could be allowed too.)

         "^(SW1|SW2|...)$":

And $,^ are swapped.

> +        $ref: /schemas/regulator/regulator.yaml#
> +        type: object
> +        description:
> +          Valid regulator names are SW1, SW2, SW3, SW4, SW5, VCAM, VCSI,
> +          VDAC, VDIG, VFUSE, VHVIO, VSDIO, VPLL, VRF1, VRF2, VRFREF, VWLAN1,
> +          VWLAN2, VSIM, VSIMCARD, VVIB, VUSB, VAUDIO
> +

If these apply to the regulator-name property, it can be written instead as:

  properties:
    regulator-name:
      enum:
        - SW1
        - SW2
        ...


Not sure if it is strictly needed, but this would document the optional
property:

    regulator-boot-on: true

> +        required:
> +          - regulator-name
> +          - regulator-enable-ramp-delay
> +          - regulator-min-microvolt
> +          - regulator-max-microvolt
> +
> +        unevaluatedProperties: false
> +
> +required:
> +  - compatible
> +
> +additionalProperties: false
> +

Example should go here.

> +...


^ permalink raw reply

* Re: [PATCH 4/4] rtc: ds1307: Add support for reading RX8901CE battery VL status
From: Alexandre Belloni @ 2026-01-31  0:05 UTC (permalink / raw)
  To: Fredrik M Olsson
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
	linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20251219-ds1307-rx8901-add-v1-4-b13f346ebe93@axis.com>

On 19/12/2025 13:10:38+0100, Fredrik M Olsson wrote:
> Adds support for:
> - Reading the battery voltage low status using the RTC_VL_READ ioctl,
>   which also reports invalid time information if the VLF flag is set.
> 
> Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
> ---
>  drivers/rtc/rtc-ds1307.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 43 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index 99d95e520108..ca062ed0c867 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -133,8 +133,11 @@ enum ds_type {
>  #define RX8901_REG_INTF			0x0e
>  #define RX8901_REG_INTF_VLF		BIT(1)
>  #define RX8901_REG_PWSW_CFG		0x37
> +#define RX8901_REG_PWSW_CFG_VBATLDETEN	BIT(4)
>  #define RX8901_REG_PWSW_CFG_INIEN	BIT(6)
>  #define RX8901_REG_PWSW_CFG_CHGEN	BIT(7)
> +#define RX8901_REG_BUF_INTF		0x46
> +#define RX8901_REG_BUF_INTF_VBATLF	BIT(3)
>  
>  #define MCP794XX_REG_CONTROL		0x07
>  #	define MCP794XX_BIT_ALM0_EN	0x10
> @@ -458,6 +461,39 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_RTC_INTF_DEV
> +static int rx8901_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)
> +{
> +	struct ds1307 *ds1307 = dev_get_drvdata(dev);
> +	unsigned int regflag, tmp = 0;
> +	int ret = 0;
> +
> +	switch (cmd) {
> +	case RTC_VL_READ:
> +		ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, &regflag);
> +		if (ret)
> +			return ret;
> +
> +		if (regflag & RX8901_REG_INTF_VLF)
> +			tmp |= RTC_VL_DATA_INVALID;
> +
> +		ret = regmap_read(ds1307->regmap, RX8901_REG_BUF_INTF, &regflag);
> +		if (ret)
> +			return ret;
> +
> +		if (regflag & RX8901_REG_BUF_INTF_VBATLF)
> +			tmp |= RTC_VL_BACKUP_LOW;
> +
> +		return put_user(tmp, (unsigned int __user *)arg);
> +	default:
> +		return -ENOIOCTLCMD;
> +	}
> +	return ret;
> +}
> +#else
> +#define rx8901_ioctl NULL
> +#endif
> +
>  static int ds1337_read_alarm(struct device *dev, struct rtc_wkalrm *t)
>  {
>  	struct ds1307		*ds1307 = dev_get_drvdata(dev);
> @@ -599,10 +635,13 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
>  	return setup;
>  }
>  
> -static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms __always_unused, bool diode)
>  {
> -	/* make sure that the backup battery is enabled */
> -	u8 setup = RX8901_REG_PWSW_CFG_INIEN;
> +	/*
> +	 * make sure that the backup battery is enabled and that battery
> +	 * voltage detection is performed
> +	 */
> +	u8 setup = RX8901_REG_PWSW_CFG_INIEN | RX8901_REG_PWSW_CFG_VBATLDETEN;
>  
>  	if (diode)
>  		setup |= RX8901_REG_PWSW_CFG_CHGEN;
> @@ -1005,6 +1044,7 @@ static const struct rtc_class_ops rx8130_rtc_ops = {
>  static const struct rtc_class_ops rx8901_rtc_ops = {
>  	.read_time      = ds1307_get_time,
>  	.set_time       = ds1307_set_time,
> +	.ioctl          = rx8901_ioctl,
>  };
>  

This seems to be an unrelated changed that hasn't been squashed in the
proper patch.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH 3/4] rtc: ds1307: Add Driver for Epson RX8901CE
From: Alexandre Belloni @ 2026-01-31  0:03 UTC (permalink / raw)
  To: Fredrik M Olsson
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
	linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20251219-ds1307-rx8901-add-v1-3-b13f346ebe93@axis.com>

Hello,

On 19/12/2025 13:10:37+0100, Fredrik M Olsson wrote:
>  #define MCP794XX_REG_CONTROL		0x07
>  #	define MCP794XX_BIT_ALM0_EN	0x10
>  #	define MCP794XX_BIT_ALM1_EN	0x20
> @@ -226,6 +233,19 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
>  			dev_warn_once(dev, "oscillator failed, set time!\n");
>  			return -EINVAL;
>  		}
> +	} else if (ds1307->type == rx_8901) {
> +		unsigned int regflag;
> +
> +		ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, &regflag);
> +		if (ret) {
> +			dev_err(dev, "%s error %d\n", "read", ret);

The multiple dev_err you are adding should be dev_dbg as there is no
other actions for the user than to restart the operation when it fails
so there is not actual value apart when debugging.

> +			return ret;
> +		}
> +
> +		if (regflag & RX8901_REG_INTF_VLF) {
> +			dev_warn_once(dev, "oscillator failed, set time!\n");
> +			return -EINVAL;
> +		}
>  	}
>  
>  	/* read the RTC date and time registers all at once */
> @@ -307,7 +327,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
>  	tmp = regs[DS1307_REG_HOUR] & 0x3f;
>  	t->tm_hour = bcd2bin(tmp);
>  	/* rx8130 is bit position, not BCD */
> -	if (ds1307->type == rx_8130)
> +	if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
>  		t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f) - 1;
>  	else
>  		t->tm_wday = bcd2bin(regs[DS1307_REG_WDAY] & 0x07) - 1;
> @@ -358,7 +378,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>  	regs[DS1307_REG_MIN] = bin2bcd(t->tm_min);
>  	regs[DS1307_REG_HOUR] = bin2bcd(t->tm_hour);
>  	/* rx8130 is bit position, not BCD */
> -	if (ds1307->type == rx_8130)
> +	if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
>  		regs[DS1307_REG_WDAY] = 1 << t->tm_wday;
>  	else
>  		regs[DS1307_REG_WDAY] = bin2bcd(t->tm_wday + 1);
> @@ -422,6 +442,17 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>  			dev_err(dev, "%s error %d\n", "write", result);
>  			return result;
>  		}
> +	} else if (ds1307->type == rx_8901) {
> +		/*
> +		 * clear Voltage Loss Flag as data is available now (writing 1
> +		 * to the other bits in the INTF register has no effect)
> +		 */
> +		result = regmap_write(ds1307->regmap, RX8901_REG_INTF,
> +				      0xff ^ RX8901_REG_INTF_VLF);
> +		if (result) {
> +			dev_err(dev, "%s error %d\n", "write", result);
> +			return result;
> +		}
>  	}
>  
>  	return 0;
> @@ -568,6 +599,17 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
>  	return setup;
>  }
>  
> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
> +{
> +	/* make sure that the backup battery is enabled */
> +	u8 setup = RX8901_REG_PWSW_CFG_INIEN;

You can't do this as this will cause issues in the future for people
wanting to keep this bit disabled (the main reason being that you don't
want to draw power from the battery while your device sits on a shelf).
You have to handle the RTC_PARAM_BACKUP_SWITCH_MODE parameter and then
switch it from userspace.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v3 0/3] RTC: Add Loongson-2K0300 support
From: Alexandre Belloni @ 2026-01-30 23:16 UTC (permalink / raw)
  To: Binbin Zhou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	linux-rtc, Huacai Chen, Binbin Zhou
  Cc: Xiaochuang Mao, Huacai Chen, Xuerui Wang, loongarch, devicetree,
	linux-mips, Keguang Zhang
In-Reply-To: <cover.1768616276.git.zhoubinbin@loongson.cn>

On Sat, 17 Jan 2026 10:26:47 +0800, Binbin Zhou wrote:
> This patch set introduces the Loongson-2K0300 RTC, which has a similar
> hardware design to the Loongson-1B, but without the alarm feature.
> 
> Thanks.
> Binbin
> 
> ==========
> V3:
> - Add Reviewed-by tag from Huacai, thanks.
> 
> [...]

Applied, thanks!

[1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
      https://git.kernel.org/abelloni/c/da9934a6583a
[2/3] dt-bindings: rtc: loongson: Document Loongson-2K0300 compatible
      https://git.kernel.org/abelloni/c/5d4899d4859f
[3/3] rtc: loongson: Add Loongson-2K0300 support
      https://git.kernel.org/abelloni/c/770a54accf80

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: (subset) [PATCH 3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
From: Alexandre Belloni @ 2026-01-30 23:15 UTC (permalink / raw)
  To: claudiu.beznea.uj, robh, krzk+dt, conor+dt, geert+renesas,
	magnus.damm, mturquette, sboyd, prabhakar.mahadev-lad.rj,
	Ovidiu Panait
  Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-4-ovidiu.panait.rb@renesas.com>

On Sun, 25 Jan 2026 19:27:03 +0000, Ovidiu Panait wrote:
> The Renesas RZ/V2N (r9a09g056) RTC is identical to the RZ/V2H
> (r9a09g057) variant. Add the compatible string for RZ/V2N and
> extend the existing RZ/V2H reset configuration to cover both
> variants.
> 
> 

Applied, thanks!

[3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
      https://git.kernel.org/abelloni/c/f3ac75cfacc6

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
From: Alexandre Belloni @ 2026-01-30 22:59 UTC (permalink / raw)
  To: Michal Simek, Tomas Melin
  Cc: linux-rtc, linux-arm-kernel, linux-kernel, Harini T
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-0-d4edb966b499@vaisala.com>

On Thu, 22 Jan 2026 13:53:44 +0000, Tomas Melin wrote:
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values
> are now updated to match with expected.
> 
> The RTC calibration value operates with full ticks,
> and fractional ticks which are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks
> and value matches the external oscillator in Hz. Through that,
> the maximum and minimum offset values can be calculated dynamically,
> as they depend on the input frequency used.
> 
> [...]

Applied, thanks!

[1/5] rtc: zynqmp: correct frequency value
      https://git.kernel.org/abelloni/c/2724fb4d429c
[2/5] rtc: zynqmp: check calibration max value
      https://git.kernel.org/abelloni/c/83b9e5eb0437
[3/5] rtc: zynqmp: rework read_offset
      https://git.kernel.org/abelloni/c/0f9989443fae
[4/5] rtc: zynqmp: rework set_offset
      https://git.kernel.org/abelloni/c/9f5af70268d6
[5/5] rtc: zynqmp: use dynamic max and min offset ranges
      https://git.kernel.org/abelloni/c/2254383176fc

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: (subset) [PATCH v1 06/10] dt-bindings: rtc: cpcap-rtc: convert to schema
From: Alexandre Belloni @ 2026-01-30 22:59 UTC (permalink / raw)
  To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
	Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown, Dixit Parmar,
	Tony Lindgren, Svyatoslav Ryhel
  Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
	linux-rtc
In-Reply-To: <20260125134302.45958-7-clamor95@gmail.com>

On Sun, 25 Jan 2026 15:42:58 +0200, Svyatoslav Ryhel wrote:
> Convert RTC devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
> 
> 

Applied, thanks!

[06/10] dt-bindings: rtc: cpcap-rtc: convert to schema
        https://git.kernel.org/abelloni/c/96a77ec577d4

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH 3/3] rtc: optee: simplify OP-TEE context match
From: Rouven Czerwinski @ 2026-01-30 15:03 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Jens Wiklander, Sumit Garg, Olivia Mackall, Herbert Xu,
	Clément Léger, op-tee, linux-kernel, linux-crypto,
	linux-rtc
In-Reply-To: <202601291605277bc279f4@mail.local>

Hi Alexandre,

On Thu, 2026-01-29 at 17:05 +0100, Alexandre Belloni wrote:
> On 26/01/2026 11:11:26+0100, Rouven Czerwinski via B4 Relay wrote:
> > From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> > 
> > Simplify the TEE implementor ID match by returning the boolean
> > expression directly instead of going through an if/else.
> > 
> > Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> > ---
> >  drivers/rtc/rtc-optee.c | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
> > index 184c6d142801..2f18be3de684 100644
> > --- a/drivers/rtc/rtc-optee.c
> > +++ b/drivers/rtc/rtc-optee.c
> > @@ -541,10 +541,7 @@ static int optee_rtc_read_info(struct device
> > *dev, struct rtc_device *rtc,
> >  
> >  static int optee_ctx_match(struct tee_ioctl_version_data *ver,
> > const void *data)
> >  {
> > -	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> > -		return 1;
> > -	else
> > -		return 0;
> > +	return (ver->impl_id == TEE_IMPL_ID_OPTEE);
> 
> I guess the correct way to do this would be:
> 
> return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);

Could you explain why? If I read the standard correctly, an equality
operation always produces either 1 or 0, so there should be no need for
!! here like there is for bit flag comparisons, i.e. !!(flag &
SOME_FLAG_SET) to normalize to 1 or 0. Wondering if I am missing
something.

> But is this change actually generating better code?
> 
> Before:
> 
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const
> void *data)
> {
>         if (ver->impl_id == TEE_IMPL_ID_OPTEE)
>        0:       e5900000        ldr     r0, [r0]
>                 return 1;
>         else
>                 return 0;
> }
>        4:       e2400001        sub     r0, r0, #1
>        8:       e16f0f10        clz     r0, r0
>        c:       e1a002a0        lsr     r0, r0, #5
>       10:       e12fff1e        bx      lr
> 
> After:
> 
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const
> void *data)
> {
>         return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);
>        0:       e5900000        ldr     r0, [r0]
> }
>        4:       e2400001        sub     r0, r0, #1
>        8:       e16f0f10        clz     r0, r0
>        c:       e1a002a0        lsr     r0, r0, #5
>       10:       e12fff1e        bx      lr
> 
> I'm in favor of keeping the current version.

I like the short version better, but I am also not very attached to
getting this in at all, I'll let the maintainers decide.

Thanks and best regards,
Rouven



^ permalink raw reply

* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Thomas Bogendoerfer @ 2026-01-30 14:37 UTC (permalink / raw)
  To: Brian Masney
  Cc: Claudiu Beznea, linux-mips, linux-kernel, Michael Turquette,
	Stephen Boyd, linux-clk, Thomas Gleixner, Adrian Hunter,
	Ulf Hansson, linux-mmc, Linus Walleij, linux-gpio,
	Alexandre Belloni, linux-rtc, Greg Kroah-Hartman, Jiri Slaby,
	linux-serial, Guenter Roeck, Wim Van Sebroeck, linux-watchdog
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>

On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> There are currently some pic32 MIPS drivers that are in tree, and are
> only configured to be compiled on the MIPS pic32 platform. There's a
> risk of breaking some of these drivers when migrating drivers away from
> legacy APIs. It happened to me with a pic32 clk driver.
> 
> Let's go ahead and move the pic32.h from the asm to the platform_data
> include directory in the tree. This will make it easier, and cleaner to
> enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> updating some includes, which I do at the beginning of this series.
> 
> This series was compile tested on a centos-stream-10 arm64 host in two
> different configurations:
> 
> - native arm64 build with COMPILE_TEST (via make allmodconfig)
> - MIPS cross compile on arm64 with:
>       ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
> 
> Note that there is a separate MIPS compile error in linux-next, and I
> reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
> 
> I included a patch at the end that shows enabling COMPILE_TEST for a
> pic32 clk driver.
> 
> Merge Strategy
> ==============
> - Patches 1-15 can go through the MIPS tree.
> - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
>   tree after the next merge window. There is a separate patch set that
>   fixes a compiler error I unintentionally introduced via the clk tree.
>   https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
> 
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> Changes in v2:
> - Fix native MIPS build by updating include files
> - Link to v1: https://lore.kernel.org/r/20260109-mips-pic32-header-move-v1-0-99859c55783d@redhat.com
> 
> ---
> Brian Masney (16):
>       MIPS: pic32: include linux/io.h header on several files
>       MIPS: pic32: include linux/types.h on pic32.h
>       MIPS: pic32: drop unused include linux/io.h from pic32.h
>       MIPS: copy pic32.h header file from asm/mach-pic32/ to include/platform-data/
>       MAINTAINERS: add include/linux/platform_data/pic32.h to MIPS entry
>       MIPS: update include to use pic32.h from platform_data
>       clk: microchip: core: update include to use pic32.h from platform_data
>       irqchip/irq-pic32-evic: update include to use pic32.h from platform_data
>       mmc: sdhci-pic32: update include to use pic32.h from platform_data
>       pinctrl: pic32: update include to use pic32.h from platform_data
>       rtc: pic32: update include to use pic32.h from platform_data
>       serial: pic32_uart: update include to use pic32.h from platform_data
>       watchdog: pic32-dmt: update include to use pic32.h from platform_data
>       watchdog: pic32-wdt: update include to use pic32.h from platform_data
>       MIPS: drop unused pic32.h header
>       clk: microchip: core: allow driver to be compiled with COMPILE_TEST
> 
>  MAINTAINERS                                             |  1 +
>  arch/mips/pic32/common/reset.c                          |  3 ++-
>  arch/mips/pic32/pic32mzda/config.c                      |  3 +--
>  arch/mips/pic32/pic32mzda/early_clk.c                   |  3 ++-
>  arch/mips/pic32/pic32mzda/early_console.c               |  3 ++-
>  drivers/clk/microchip/Kconfig                           |  2 +-
>  drivers/clk/microchip/clk-core.c                        |  6 +++++-
>  drivers/irqchip/irq-pic32-evic.c                        |  2 +-
>  drivers/mmc/host/sdhci-pic32.c                          |  2 +-
>  drivers/pinctrl/pinctrl-pic32.c                         |  3 +--
>  drivers/rtc/rtc-pic32.c                                 |  3 +--
>  drivers/tty/serial/pic32_uart.c                         |  3 +--
>  drivers/watchdog/pic32-dmt.c                            |  3 +--
>  drivers/watchdog/pic32-wdt.c                            |  3 +--
>  .../mach-pic32 => include/linux/platform_data}/pic32.h  | 17 ++++++++++-------
>  15 files changed, 31 insertions(+), 26 deletions(-)
> ---
> base-commit: f417b7ffcbef7d76b0d8860518f50dae0e7e5eda
> change-id: 20260109-mips-pic32-header-move-6ac9965aa70a

series 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 3/3] rtc: optee: simplify OP-TEE context match
From: Alexandre Belloni @ 2026-01-29 16:05 UTC (permalink / raw)
  To: rouven.czerwinski
  Cc: Jens Wiklander, Sumit Garg, Olivia Mackall, Herbert Xu,
	Clément Léger, op-tee, linux-kernel, linux-crypto,
	linux-rtc
In-Reply-To: <20260126-optee-simplify-context-match-v1-3-d4104e526cb6@linaro.org>

On 26/01/2026 11:11:26+0100, Rouven Czerwinski via B4 Relay wrote:
> From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> 
> Simplify the TEE implementor ID match by returning the boolean
> expression directly instead of going through an if/else.
> 
> Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> ---
>  drivers/rtc/rtc-optee.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
> index 184c6d142801..2f18be3de684 100644
> --- a/drivers/rtc/rtc-optee.c
> +++ b/drivers/rtc/rtc-optee.c
> @@ -541,10 +541,7 @@ static int optee_rtc_read_info(struct device *dev, struct rtc_device *rtc,
>  
>  static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
>  {
> -	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> -		return 1;
> -	else
> -		return 0;
> +	return (ver->impl_id == TEE_IMPL_ID_OPTEE);

I guess the correct way to do this would be:

return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);

But is this change actually generating better code?

Before:

static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
{
        if (ver->impl_id == TEE_IMPL_ID_OPTEE)
       0:       e5900000        ldr     r0, [r0]
                return 1;
        else
                return 0;
}
       4:       e2400001        sub     r0, r0, #1
       8:       e16f0f10        clz     r0, r0
       c:       e1a002a0        lsr     r0, r0, #5
      10:       e12fff1e        bx      lr

After:

static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
{
        return !!(ver->impl_id == TEE_IMPL_ID_OPTEE);
       0:       e5900000        ldr     r0, [r0]
}
       4:       e2400001        sub     r0, r0, #1
       8:       e16f0f10        clz     r0, r0
       c:       e1a002a0        lsr     r0, r0, #5
      10:       e12fff1e        bx      lr

I'm in favor of keeping the current version.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
From: Michal Simek @ 2026-01-29 10:11 UTC (permalink / raw)
  To: Tomas Melin, Alexandre Belloni
  Cc: linux-rtc, linux-arm-kernel, linux-kernel, Harini T
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-0-d4edb966b499@vaisala.com>



On 1/22/26 14:53, Tomas Melin wrote:
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values
> are now updated to match with expected.
> 
> The RTC calibration value operates with full ticks,
> and fractional ticks which are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks
> and value matches the external oscillator in Hz. Through that,
> the maximum and minimum offset values can be calculated dynamically,
> as they depend on the input frequency used.
> 
> For docs on the calibration register, see
> https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
> 
> Due to rounding errors (different number of fract ticks),
> offset readback will differ slightly depending on
> if the offset is negative or positive. This is however well below the granularity
> provided by the hardware.
> 
> For example
> $ echo 34335 > offset
> $ cat offset
> 34335
> $ echo -34335 > offset
> $ cat offset
> -34326
> 
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> Changes in v4:
> - Do not limit building to zynqmp arch as building on other platforms
>    might be needed. Implies dropping commit.
> - No need for RTC_PPB to be 64 bit value, use 32 bit instead
> - Link to v3: https://lore.kernel.org/r/20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com
> 
> Changes in v3:
> - Add commit for limiting building of driver to zynqmp arch.
> - Reorder variable declarations in set_offset
> - Link to v2: https://lore.kernel.org/r/20260108-zynqmp-rtc-updates-v2-0-864c161fa83d@vaisala.com
> 
> Changes in v2:
> - Add commit introducing check for calibration value overflow
> - Update comments
> - Align data types across set and read
> - Rename fract_tick as fract_data conforming to data sheet
> - Further improve on set offset calculation logic
> - Link to v1: https://lore.kernel.org/r/20251201-zynqmp-rtc-updates-v1-0-33875c1e385b@vaisala.com
> 
> ---
> Tomas Melin (5):
>        rtc: zynqmp: correct frequency value
>        rtc: zynqmp: check calibration max value
>        rtc: zynqmp: rework read_offset
>        rtc: zynqmp: rework set_offset
>        rtc: zynqmp: use dynamic max and min offset ranges
> 
>   drivers/rtc/rtc-zynqmp.c | 75 ++++++++++++++++++++++++++----------------------
>   1 file changed, 41 insertions(+), 34 deletions(-)
> ---
> base-commit: cd635e33b0113287c94021be53d2a7c61a1614e9
> change-id: 20251201-zynqmp-rtc-updates-d260364cc01b
> 
> Best regards,

Acked-by: Michal Simek <michal.simek@amd.com>

Thanks,
Michal

^ permalink raw reply

* RE: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
From: T, Harini @ 2026-01-29  9:36 UTC (permalink / raw)
  To: Tomas Melin, Alexandre Belloni, Simek, Michal
  Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-0-d4edb966b499@vaisala.com>

[Public]

The patch series looks fine to me.

Thanks,
Harini T

> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 22, 2026 7:24 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>; T, Harini
> <Harini.T@amd.com>
> Subject: [PATCH v4 0/5] rtc: zynqmp: fixes for read and set offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values are now
> updated to match with expected.
>
> The RTC calibration value operates with full ticks, and fractional ticks which
> are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks and value
> matches the external oscillator in Hz. Through that, the maximum and
> minimum offset values can be calculated dynamically, as they depend on the
> input frequency used.
>
> For docs on the calibration register, see https://docs.amd.com/r/en-
> US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
>
> Due to rounding errors (different number of fract ticks), offset readback will
> differ slightly depending on if the offset is negative or positive. This is
> however well below the granularity provided by the hardware.
>
> For example
> $ echo 34335 > offset
> $ cat offset
> 34335
> $ echo -34335 > offset
> $ cat offset
> -34326
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> Changes in v4:
> - Do not limit building to zynqmp arch as building on other platforms
>   might be needed. Implies dropping commit.
> - No need for RTC_PPB to be 64 bit value, use 32 bit instead
> - Link to v3: https://lore.kernel.org/r/20260119-zynqmp-rtc-updates-v3-0-
> acd902fdeab1@vaisala.com
>
> Changes in v3:
> - Add commit for limiting building of driver to zynqmp arch.
> - Reorder variable declarations in set_offset
> - Link to v2: https://lore.kernel.org/r/20260108-zynqmp-rtc-updates-v2-0-
> 864c161fa83d@vaisala.com
>
> Changes in v2:
> - Add commit introducing check for calibration value overflow
> - Update comments
> - Align data types across set and read
> - Rename fract_tick as fract_data conforming to data sheet
> - Further improve on set offset calculation logic
> - Link to v1: https://lore.kernel.org/r/20251201-zynqmp-rtc-updates-v1-0-
> 33875c1e385b@vaisala.com
>
> ---
> Tomas Melin (5):
>       rtc: zynqmp: correct frequency value
>       rtc: zynqmp: check calibration max value
>       rtc: zynqmp: rework read_offset
>       rtc: zynqmp: rework set_offset
>       rtc: zynqmp: use dynamic max and min offset ranges
>
>  drivers/rtc/rtc-zynqmp.c | 75 ++++++++++++++++++++++++++---------------------
> -
>  1 file changed, 41 insertions(+), 34 deletions(-)
> ---
> base-commit: cd635e33b0113287c94021be53d2a7c61a1614e9
> change-id: 20251201-zynqmp-rtc-updates-d260364cc01b
>
> Best regards,
> --
> Tomas Melin <tomas.melin@vaisala.com>


^ permalink raw reply

* RE: [PATCH v4 4/5] rtc: zynqmp: rework set_offset
From: T, Harini @ 2026-01-29  9:33 UTC (permalink / raw)
  To: Tomas Melin, Alexandre Belloni, Simek, Michal
  Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <20260122-zynqmp-rtc-updates-v4-4-d4edb966b499@vaisala.com>

[Public]

Reviewed-by: Harini T <harini.t@amd.com>

> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 22, 2026 7:24 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>; T, Harini
> <Harini.T@amd.com>
> Subject: [PATCH v4 4/5] rtc: zynqmp: rework set_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> set_offset was using remainder of do_div as tick_mult which resulted in
> wrong offset. Calibration value also assumed builtin calibration default.
> Update fract_offset to correctly calculate the value for negative offset and
> replace the for loop with division.
>
> Tested-by: Harini T <harini.t@amd.com>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
>  drivers/rtc/rtc-zynqmp.c | 33 +++++++++++++--------------------
>  1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> c82f4d490fc7ebb5876b820182f5e79a99e496a8..f0f5dc63e254799ed99927c25
> 9c767b30ee877a4 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
> long *offset)  static int xlnx_rtc_set_offset(struct device *dev, long offset)  {
>         struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> -       unsigned long long rtc_ppb = RTC_PPB;
> -       unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> -       unsigned char fract_tick = 0;
> +       int max_tick, tick_mult, fract_offset, fract_part;
> +       int freq = xrtcdev->freq;
>         unsigned int calibval;
> -       short int  max_tick;
> -       int fract_offset;
> +       int fract_data = 0;
>
> +       /* Tick to offset multiplier */
> +       tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
>         if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
>                 return -ERANGE;
>
> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
>         /* Number fractional ticks for given offset */
>         if (fract_offset) {
> -               if (fract_offset < 0) {
> -                       fract_offset = fract_offset + tick_mult;
> +               fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> +               fract_data = fract_offset / fract_part;
> +               /* Subtract one from max_tick while adding fract_offset */
> +               if (fract_offset < 0 && fract_data) {
>                         max_tick--;
> -               }
> -               if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
> -                       for (fract_tick = 1; fract_tick < 16; fract_tick++) {
> -                               if (fract_offset <=
> -                                   (fract_tick *
> -                                    (tick_mult / RTC_FR_MAX_TICKS)))
> -                                       break;
> -                       }
> +                       fract_data += RTC_FR_MAX_TICKS;
>                 }
>         }
>
>         /* Zynqmp RTC uses second and fractional tick
>          * counters for compensation
>          */
> -       calibval = max_tick + RTC_CALIB_DEF;
> -
> -       if (fract_tick)
> -               calibval |= RTC_FR_EN;
> +       calibval = max_tick + freq;
>
> -       calibval |= (fract_tick << RTC_FR_DATSHIFT);
> +       if (fract_data)
> +               calibval |= (RTC_FR_EN | (fract_data <<
> + RTC_FR_DATSHIFT));
>
>         writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>
>
> --
> 2.47.3


^ permalink raw reply

* RE: [PATCH v4 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL
From: Lakshay Piplani @ 2026-01-29  5:43 UTC (permalink / raw)
  To: alexandre.belloni@bootlin.com, linux-rtc@vger.kernel.org,
	linux-kernel@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org,
	wim@linux-watchdog.org, linux@roeck-us.net,
	linux-watchdog@vger.kernel.org
  Cc: Vikash Bansal, Priyanka Jain, Shashank Rebbapragada
In-Reply-To: <20251121121137.3043764-2-lakshay.piplani@nxp.com>



> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Friday, November 21, 2025 5:42 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org; wim@linux-watchdog.org;
> linux@roeck-us.net; linux-watchdog@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>
> Subject: [PATCH v4 2/5] rtc: pcf85363: support reporting battery switch-over
> via RTC_VL
> 
> Add battery switch-over reporting for PCF85263/PCF85363 using the standard
> RTC_VL_* ioctl interface. When the backup supply takes over, the BSF flag is
> exposed to userspace through RTC_VL_READ and can be cleared using
> RTC_VL_CLR.
> 
> This allows applications to detect loss of main power without relying on non-
> standard interfaces.
> 
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V3 -> V4:
> - No changes in v4.
> V2 -> V3:
> - Split into separate patches as suggested:
>   - Battery switch-over detection.
>   - Timestamp recording for TS pin and battery switch-over events.
>   - Offset calibration.
>   - Watchdog timer (to be reviewed by watchdog maintainers).
> - Dropped Alarm2 support
> - Switched to rtc_add_group() for sysfs attributes
> V1 -> V2:
> - Watchdog related changes due to removal of vendor specific properties
>   from device tree
>   * remove vendor DT knobs (enable/timeout/stepsize/repeat)
>   * use watchdog_init_timeout (with 10s default)
>   * derive clock_sel from final timeout
>   * default, repeat=true (repeat mode)
> - Fixed uninitalised warning on 'ret' (reported by kernel test robot)
> - Use dev_dbg instead of dev_info for debug related print messages
> - Minor cleanup and comments.
> 
>  drivers/rtc/rtc-pcf85363.c | 49 ++++++++++++++++++++++++++++++++++++--
>  1 file changed, 47 insertions(+), 2 deletions(-)
> 


Hi,

I'm sending a gentle reminder regarding the patches that I submitted in November. 
I haven't received any review comments yet, so I'd really appreciate it if you could have a look whenever you have some time.

Best Regards
Lakshay Piplani

^ permalink raw reply

* RE: [PATCH v7 2/2] rtc: Add NXP PCF85053 driver support
From: Lakshay Piplani @ 2026-01-29  5:34 UTC (permalink / raw)
  To: alexandre.belloni@bootlin.com, linux-rtc@vger.kernel.org,
	linux-kernel@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org
  Cc: Vikash Bansal, Priyanka Jain, Shashank Rebbapragada,
	Daniel Aguirre, Pankit Garg
In-Reply-To: <20251127120456.1849177-2-lakshay.piplani@nxp.com>



> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Thursday, November 27, 2025 5:35 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>; Daniel Aguirre <daniel.aguirre@nxp.com>;
> Pankit Garg <pankit.garg@nxp.com>
> Subject: [PATCH v7 2/2] rtc: Add NXP PCF85053 driver support
> 
> PCF85053 is i2c based RTC which supports timer and calendar functionality.
> 
> Features supported:
> 1. Read/Write time
> 2. Get/Set Alarm
> 3. Wakeup Source
> 4. Generate up to 32768Hz clock output
> 5. Primary/Secondary i2c bus
> 
> Signed-off-by: Daniel Aguirre <daniel.aguirre@nxp.com>
> Signed-off-by: Pankit Garg <pankit.garg@nxp.com>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V6 -> V7: - Addressed minor cleanups from review: use
> dev_get_drvdata()/dev_set_drvdata()
> 	    consistently, fix alarm IRQ dev_id handling, and switch to
> devm_device_init_wakeup().
> 	  - Simplified time/alarm programming by forcing 24h + binary mode
> in hardware,
> 	    dropping complex 12h/BCD handling in setters.
> 	  - Documented the 2000–2099 supported year range, explaining how
> the 00–99 year
> 	    register maps to leap-year behavior in the device.
> V5 -> V6: no changes
> V4 -> V5: no changes
> V3 -> V4: - Handle multi-host ownership explicitly using primary/secondary
> bus hadling.
>           - Probe no longer changes any CTRL bits unconditionally and do not
> clear ST/AF/OF
>             avoiding lost interrupts or silent mode changes.
>           - Read/Set time & alarm now respect HF(12/24h) and DM(BCD/BIN)
> converting
>             hour fields correctly for all combinations.
>           - Minor changes: drop noisy warnings, tidy error paths/comments.
> V2 -> V3: Add MAINTAINERS file changes to this patch
> V1 -> V2: no changes
> 
>  MAINTAINERS                |   7 +
>  drivers/rtc/Kconfig        |  10 +
>  drivers/rtc/Makefile       |   1 +
>  drivers/rtc/rtc-pcf85053.c | 717 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 735 insertions(+)
>  create mode 100644 drivers/rtc/rtc-pcf85053.c
> 

Hi Alexandre,

I'm sending a gentle reminder regarding the patches that I submitted in November. 
I haven't received any review comments yet, so I’d really appreciate it if you could have a look whenever you have some time.

Best Regards
Lakshay Piplani

^ permalink raw reply

* Re: (subset) [PATCH v2 12/20] rtc: amlogic-a4: Remove IRQF_ONESHOT
From: Alexandre Belloni @ 2026-01-28 11:28 UTC (permalink / raw)
  To: linux-kernel, Sebastian Andrzej Siewior
  Cc: Thomas Gleixner, Xianwei Zhao, Yiting Deng, linux-amlogic,
	linux-rtc
In-Reply-To: <20260128095540.863589-13-bigeasy@linutronix.de>

On Wed, 28 Jan 2026 10:55:32 +0100, Sebastian Andrzej Siewior wrote:
> Passing IRQF_ONESHOT ensures that the interrupt source is masked until
> the secondary (threaded) handler is done. If only a primary handler is
> used then the flag makes no sense because the interrupt can not fire
> (again) while its handler is running.
> The flag also disallows force-threading of the primary handler and the
> irq-core will warn about this.
> 
> [...]

Applied, thanks!

[12/20] rtc: amlogic-a4: Remove IRQF_ONESHOT
        https://git.kernel.org/abelloni/c/1932db202c93

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH] rtc: isl12022: Add missing check for device_property_read_u32_array
From: Markus Elfring @ 2026-01-28 10:16 UTC (permalink / raw)
  To: Chen Ni, linux-rtc, Alexandre Belloni; +Cc: LKML
In-Reply-To: <20260128043430.2260970-1-nichen@iscas.ac.cn>

> Add check for the return value of device_property_read_u32_array() and
> log a warning message if it fails in order to catch the error.

* Were any source code analysis tools involved here?

* Did anything hinder to add any tags (like “Fixes” and “Cc”) accordingly?


Regards,
Markus

^ permalink raw reply

* [PATCH v2 12/20] rtc: amlogic-a4: Remove IRQF_ONESHOT
From: Sebastian Andrzej Siewior @ 2026-01-28  9:55 UTC (permalink / raw)
  To: linux-kernel
  Cc: Thomas Gleixner, Sebastian Andrzej Siewior, Xianwei Zhao,
	Yiting Deng, Alexandre Belloni, linux-amlogic, linux-rtc
In-Reply-To: <20260128095540.863589-1-bigeasy@linutronix.de>

Passing IRQF_ONESHOT ensures that the interrupt source is masked until
the secondary (threaded) handler is done. If only a primary handler is
used then the flag makes no sense because the interrupt can not fire
(again) while its handler is running.
The flag also disallows force-threading of the primary handler and the
irq-core will warn about this.

Remove IRQF_ONESHOT from irqflags.

Fixes: c89ac9182ee29 ("rtc: support for the Amlogic on-chip RTC")
Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
Cc: Yiting Deng <yiting.deng@amlogic.com>
Cc: Xianwei Zhao <xianwei.zhao@amlogic.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-amlogic@lists.infradead.org
Cc: linux-rtc@vger.kernel.org
---
 drivers/rtc/rtc-amlogic-a4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-amlogic-a4.c b/drivers/rtc/rtc-amlogic-a4.c
index 123fb372fc9fe..50938c35af36a 100644
--- a/drivers/rtc/rtc-amlogic-a4.c
+++ b/drivers/rtc/rtc-amlogic-a4.c
@@ -369,7 +369,7 @@ static int aml_rtc_probe(struct platform_device *pdev)
 		return PTR_ERR(rtc->rtc_dev);
 
 	ret = devm_request_irq(dev, rtc->irq, aml_rtc_handler,
-			       IRQF_ONESHOT, "aml-rtc alarm", rtc);
+			       0, "aml-rtc alarm", rtc);
 	if (ret) {
 		dev_err_probe(dev, ret, "IRQ%d request failed, ret = %d\n",
 			      rtc->irq, ret);
-- 
2.51.0


^ permalink raw reply related

* [PATCH] rtc: isl12022: Add missing check for device_property_read_u32_array
From: Chen Ni @ 2026-01-28  4:34 UTC (permalink / raw)
  To: alexandre.belloni; +Cc: linux-rtc, linux-kernel, Chen Ni

Add check for the return value of device_property_read_u32_array() and
log a warning message if it fails in order to catch the error.

Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
 drivers/rtc/rtc-isl12022.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c
index 5fc52dc64213..6f66ec4a9948 100644
--- a/drivers/rtc/rtc-isl12022.c
+++ b/drivers/rtc/rtc-isl12022.c
@@ -517,8 +517,10 @@ static void isl12022_set_trip_levels(struct device *dev)
 	int ret, i, j, x[2];
 	u8 val, mask;
 
-	device_property_read_u32_array(dev, "isil,battery-trip-levels-microvolt",
-				       levels, 2);
+	ret = device_property_read_u32_array(dev, "isil,battery-trip-levels-microvolt",
+					     levels, 2);
+	if (ret)
+		dev_warn(dev, "failed to read battery-trip-levels-microvolt: %d\n", ret);
 
 	for (i = 0; i < 2; i++) {
 		for (j = 0; j < ARRAY_SIZE(trip_levels[i]) - 1; j++) {
-- 
2.25.1


^ permalink raw reply related

* Re: [PATCH 3/5] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
From: Conor Dooley @ 2026-01-26 20:30 UTC (permalink / raw)
  To: Ovidiu Panait
  Cc: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
	geert+renesas, magnus.damm, mturquette, sboyd,
	prabhakar.mahadev-lad.rj, linux-rtc, linux-renesas-soc,
	devicetree, linux-kernel, linux-clk
In-Reply-To: <20260125192706.27099-4-ovidiu.panait.rb@renesas.com>

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* Re: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
From: kernel test robot @ 2026-01-26 19:41 UTC (permalink / raw)
  To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
	Sebastian Reichel, André Draszik, Alexandre Belloni,
	Jonathan Corbet, Shuah Khan
  Cc: llvm, oe-kbuild-all, linux-leds, devicetree, linux-kernel,
	linux-pm, linux-samsung-soc, linux-rtc, linux-doc,
	Kaustabh Chakraborty
In-Reply-To: <20260126-s2mu005-pmic-v2-6-78f1a75f547a@disroot.org>

Hi Kaustabh,

kernel test robot noticed the following build errors:

[auto build test ERROR on ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea]

url:    https://github.com/intel-lab-lkp/linux/commits/Kaustabh-Chakraborty/dt-bindings-leds-document-Samsung-S2M-series-PMIC-flash-LED-device/20260126-031457
base:   ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
patch link:    https://lore.kernel.org/r/20260126-s2mu005-pmic-v2-6-78f1a75f547a%40disroot.org
patch subject: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260127/202601270307.Ds4yus7I-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260127/202601270307.Ds4yus7I-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601270307.Ds4yus7I-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/mfd/sec-irq.c:218:7: error: expression is not an integer constant expression
           case irqf_regs[0]:
                ^~~~~~~~~~~~
   drivers/mfd/sec-irq.c:218:7: note: initializer of 'irqf_regs' is not a constant expression
   drivers/mfd/sec-irq.c:204:21: note: declared here
           const unsigned int irqf_regs[] = {
                              ^
   drivers/mfd/sec-irq.c:220:7: error: expression is not an integer constant expression
           case mask_regs[0]:
                ^~~~~~~~~~~~
   drivers/mfd/sec-irq.c:220:7: note: initializer of 'mask_regs' is not a constant expression
   drivers/mfd/sec-irq.c:210:21: note: declared here
           const unsigned int mask_regs[] = {
                              ^
   2 errors generated.


vim +218 drivers/mfd/sec-irq.c

   200	
   201	static unsigned int s2mu005_irq_get_reg(struct regmap_irq_chip_data *data,
   202						unsigned int base, int index)
   203	{
   204		const unsigned int irqf_regs[] = {
   205			S2MU005_REG_CHGR_INT1,
   206			S2MU005_REG_FLED_INT1,
   207			S2MU005_REG_MUIC_INT1,
   208			S2MU005_REG_MUIC_INT2,
   209		};
   210		const unsigned int mask_regs[] = {
   211			S2MU005_REG_CHGR_INT1M,
   212			S2MU005_REG_FLED_INT1M,
   213			S2MU005_REG_MUIC_INT1M,
   214			S2MU005_REG_MUIC_INT2M,
   215		};
   216	
   217		switch (base) {
 > 218		case irqf_regs[0]:
   219			return irqf_regs[index];
   220		case mask_regs[0]:
   221			return mask_regs[index];
   222		}
   223	
   224		return base;
   225	}
   226	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox