wireguard-linux/drivers/rtc, branch update-toolchain

rtc: stm32: add new st,stm32mp25-rtc compatible and check RIF configuration

2024-07-10T15:15:33Z

Introduce new st,stm32mp25-rtc compatible. It is based on st,stm32mp1-rtc. Difference is that stm32mp25 soc implements a triple protection on RTC registers: - Secure bit based protection - Privileged context based protection - Compartment ID filtering based protection This driver will now check theses configurations before probing to avoid exceptions and fake reads on register. At this time, driver needs only to check two resources: INIT and ALARM_A. Other resources are not used. Resource isolation framework (RIF) is a comprehensive set of hardware blocks designed to enforce and manage isolation of STM32 hardware resources, like memory and peripherals. Link: https://www.st.com/resource/en/reference_manual/rm0457-stm32mp25xx-advanced-armbased-3264bit-mpus-stmicroelectronics.pdf#page=4081 Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20240708153434.416287-3-valentin.caron@foss.st.com Signed-off-by: Alexandre Belloni

rtc: Drop explicit initialization of struct i2c_device_id::driver_data to 0

2024-07-06T22:40:29Z

These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove a comma after the sentinel entry in rtc-hym8563. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20240515194336.58342-2-u.kleine-koenig@pengutronix.de Signed-off-by: Alexandre Belloni

rtc: interface: Add RTC offset to alarm after fix-up

2024-07-06T22:40:17Z

`rtc_add_offset()` is called by `__rtc_read_time()` and `__rtc_read_alarm()` to add the RTC's offset to the raw read-outs from the device drivers. However, in the latter case, a fix-up algorithm is run if the RTC device does not report a full `struct rtc_time` alarm value. In that case, the offset was forgot to be added. Fixes: fd6792bb022e ("rtc: fix alarm read and set offset") Signed-off-by: Csókás, Bence Link: https://lore.kernel.org/r/20240619140451.2800578-1-csokas.bence@prolan.hu Signed-off-by: Alexandre Belloni

rtc: ds1307: Clamp year to valid BCD (0-99) in `set_time()`

2024-07-06T22:39:27Z

`tm_year` may go up to 299 if the device supports the century bit. Therefore, subtracting may not give us a valid 2-digit number, but modulo does. Co-developed-by: Szentendrei, Tamás Signed-off-by: Szentendrei, Tamás Signed-off-by: Csókás, Bence Link: https://lore.kernel.org/r/20240611072411.671600-2-csokas.bence@prolan.hu Signed-off-by: Alexandre Belloni

rtc: ds1307: Detect oscillator fail on mcp794xx

2024-07-06T22:39:15Z

This patch enables the detection of the oscillator failure on mcp794xx chips. Co-developed-by: Szentendrei, Tamás Signed-off-by: Szentendrei, Tamás Signed-off-by: Csókás, Bence Link: https://lore.kernel.org/r/20240611072411.671600-1-csokas.bence@prolan.hu Signed-off-by: Alexandre Belloni

rtc: isl1208: Update correct procedure for clearing alarm

2024-06-27T22:34:21Z

As per the latest HW manual[1], there is an internal delay(~250 microsec) from setting ALME = 0 to disabling the alarm function, so the user must add a short delay of greater than 250µs between setting ALME = 0 and clearing ALM. Currently setting of ALME = 0 is done after clearing the ALM, so just reverse the operation and add a delay of 275 microsec. [1]https://www.renesas.com/us/en/document/dst/raa215300-datasheet?r=1506351 Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20240618152635.48956-3-biju.das.jz@bp.renesas.com Signed-off-by: Alexandre Belloni

rtc: isl1208: Add a delay for clearing alarm

2024-06-27T22:34:21Z

As per the latest HW manual[1], the INT# output is pulled low after the alarm is triggered. After the INT# output is pulled low, it is low for at least 250ms, even if the correct action is taken to clear it. It is impossible to clear ALM if it is still active. The host must wait for the RTC to progress past the alarm time plus the 250ms delay before clearing ALM. [1]https://www.renesas.com/us/en/document/dst/raa215300-datasheet?r=1506351 Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20240618152635.48956-2-biju.das.jz@bp.renesas.com Signed-off-by: Alexandre Belloni

rtc: add missing MODULE_DESCRIPTION() macro

2024-06-27T22:24:43Z

On x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rtc/lib_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rtc/rtc-goldfish.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rtc/rtc-omap.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rtc/rtc-rc5t583.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rtc/rtc-tps65910.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/rtc/rtc-twl.o Add the missing invocation of the MODULE_DESCRIPTION() macro to all files which have a MODULE_LICENSE(). This includes rtc-mpc5121.c, which does not produce a warning with the x86 allmodconfig since it is not built for x86, but it may cause this warning with Freescale PPC configurations. Signed-off-by: Jeff Johnson Link: https://lore.kernel.org/r/20240608-md-drivers-rtc-v1-1-5f44222adfae@quicinc.com Signed-off-by: Alexandre Belloni

rtc: abx80x: Fix return value of nvmem callback on read

2024-06-27T22:21:46Z

Read callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. abx80x_nvmem_xfer() on read calls i2c_smbus_read_i2c_block_data() which returns the number of bytes read on success as per its api description, this return value is handled as an error and returned to nvmem even on success. Fix to handle all possible values that would be returned by i2c_smbus_read_i2c_block_data(). Fixes: e90ff8ede777 ("rtc: abx80x: Add nvmem support") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty Reviewed-by: Dan Carpenter Reviewed-by: Sean Anderson Link: https://lore.kernel.org/r/20240613120750.1455209-1-joychakr@google.com Signed-off-by: Alexandre Belloni

rtc: cmos: Fix return value of nvmem callbacks

2024-06-27T22:21:06Z

Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. cmos_nvram_read()/cmos_nvram_write() currently return the number of bytes read or written, fix to return 0 on success and -EIO incase number of bytes requested was not read or written. Fixes: 8b5b7958fd1c ("rtc: cmos: use generic nvmem") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20240612083635.1253039-1-joychakr@google.com Signed-off-by: Alexandre Belloni