* [PATCH v7 3/4] rtc: nvvrs: add NVIDIA VRS RTC device driver
From: Shubhi Garg @ 2025-10-07 13:57 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Catalin Marinas, Will Deacon, Alexandre Belloni, Jonathan Hunter
Cc: devicetree, linux-arm-kernel, linux-rtc, linux-tegra, Shubhi Garg
In-Reply-To: <20251007135738.487694-1-shgarg@nvidia.com>
Add support for NVIDIA VRS (Voltage Regulator Specification) RTC device
driver. NVIDIA VRS is a Power Management IC (PMIC) that implements a
power sequencing solution with I2C interface. The device includes RTC
which provides functionality to get/set system time, retain system
time across boot, wake system from suspend and shutdown state.
Supported platforms:
- NVIDIA Jetson AGX Orin Developer Kit
- NVIDIA IGX Orin Development Kit
- NVIDIA Jetson Orin NX Developer Kit
- NVIDIA Jetson Orin Nano Developer Kit
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
---
v7:
- rtc driver fixes to remove mutex lock
- moved register definitions in driver file
v6:
- compatible name fixes to "nvidia,vrs-10"
v5:
- removed unused register definitions from header
- added VRS to maintainers list
- removed MFD dependency from Kconfig
- improved driver filename and CONFIG name
- handle all VRS interrupts in RTC driver
- validate chip vendor info during RTC probe
- clear any pending IRQs during RTC probe
v4:
- no changes
v3:
- fixed return value in RTC read_time and read_alarm functions
- fixed sizeof(*variable) inside rtc driver devm_kzalloc
- switch to devm_device_init_wakeup() for automatic cleanup
v2:
- removed regmap struct since it is not required
- removed rtc_map definition to directly use register definition
- removed unnecessary dev_err logs
- fixed dev_err logs to dev_dbg
- used rtc_lock/unlock in irq handler
- changed RTC allocation and register APIs as per latest kernel
- removed nvvrs_rtc_remove function since it's not required
MAINTAINERS | 8 +
drivers/rtc/Kconfig | 9 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-nvidia-vrs10.c | 542 +++++++++++++++++++++++++++++++++
4 files changed, 560 insertions(+)
create mode 100644 drivers/rtc/rtc-nvidia-vrs10.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3773c74b31d6..0b1dddc241a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18418,6 +18418,14 @@ S: Maintained
F: drivers/video/fbdev/nvidia/
F: drivers/video/fbdev/riva/
+NVIDIA VRS RTC DRIVER
+M: Shubhi Garg <shgarg@nvidia.com>
+L: linux-tegra@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/rtc/nvidia,vrs-10.yaml
+F: drivers/rtc/rtc-nvidia-vrs10.c
+F: include/linux/rtc/rtc-nvidia-vrs10.h
+
NVIDIA WMI EC BACKLIGHT DRIVER
M: Daniel Dadap <ddadap@nvidia.com>
L: platform-driver-x86@vger.kernel.org
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2933c41c77c8..1714a100697b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -416,6 +416,15 @@ config RTC_DRV_SPACEMIT_P1
This driver can also be built as a module, which will be called
"spacemit-p1-rtc".
+config RTC_DRV_NVIDIA_VRS10
+ tristate "NVIDIA VRS10 RTC device"
+ help
+ If you say yes here you will get support for the battery backed RTC device
+ of NVIDIA VRS (Voltage Regulator Specification). The RTC is connected via
+ I2C interface and supports alarm functionality.
+ This driver can also be built as a module. If so, the module will be called
+ rtc-nvidia-vrs10.
+
config RTC_DRV_NCT3018Y
tristate "Nuvoton NCT3018Y"
depends on OF
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 8221bda6e6dc..d06380a040c9 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_RTC_DRV_GAMECUBE) += rtc-gamecube.o
obj-$(CONFIG_RTC_DRV_NCT3018Y) += rtc-nct3018y.o
obj-$(CONFIG_RTC_DRV_NCT6694) += rtc-nct6694.o
obj-$(CONFIG_RTC_DRV_NTXEC) += rtc-ntxec.o
+obj-$(CONFIG_RTC_DRV_NVIDIA_VRS10)+= rtc-nvidia-vrs10.o
obj-$(CONFIG_RTC_DRV_OMAP) += rtc-omap.o
obj-$(CONFIG_RTC_DRV_OPAL) += rtc-opal.o
obj-$(CONFIG_RTC_DRV_OPTEE) += rtc-optee.o
diff --git a/drivers/rtc/rtc-nvidia-vrs10.c b/drivers/rtc/rtc-nvidia-vrs10.c
new file mode 100644
index 000000000000..b15796698558
--- /dev/null
+++ b/drivers/rtc/rtc-nvidia-vrs10.c
@@ -0,0 +1,542 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * NVIDIA Voltage Regulator Specification RTC
+ *
+ * SPDX-FileCopyrightText: Copyright (c) 2025 NVIDIA CORPORATION & AFFILIATES.
+ * All rights reserved.
+ */
+
+#include <linux/bits.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/rtc.h>
+
+#define NVVRS_REG_VENDOR_ID 0x00
+#define NVVRS_REG_MODEL_REV 0x01
+
+/* Interrupts registers */
+#define NVVRS_REG_INT_SRC1 0x10
+#define NVVRS_REG_INT_SRC2 0x11
+#define NVVRS_REG_INT_VENDOR 0x12
+
+/* Control Registers */
+#define NVVRS_REG_CTL_1 0x28
+#define NVVRS_REG_CTL_2 0x29
+
+/* RTC Registers */
+#define NVVRS_REG_RTC_T3 0x70
+#define NVVRS_REG_RTC_T2 0x71
+#define NVVRS_REG_RTC_T1 0x72
+#define NVVRS_REG_RTC_T0 0x73
+#define NVVRS_REG_RTC_A3 0x74
+#define NVVRS_REG_RTC_A2 0x75
+#define NVVRS_REG_RTC_A1 0x76
+#define NVVRS_REG_RTC_A0 0x77
+
+/* Interrupt Mask */
+#define NVVRS_INT_SRC1_RSTIRQ_MASK BIT(0)
+#define NVVRS_INT_SRC1_OSC_MASK BIT(1)
+#define NVVRS_INT_SRC1_EN_MASK BIT(2)
+#define NVVRS_INT_SRC1_RTC_MASK BIT(3)
+#define NVVRS_INT_SRC1_PEC_MASK BIT(4)
+#define NVVRS_INT_SRC1_WDT_MASK BIT(5)
+#define NVVRS_INT_SRC1_EM_PD_MASK BIT(6)
+#define NVVRS_INT_SRC1_INTERNAL_MASK BIT(7)
+#define NVVRS_INT_SRC2_PBSP_MASK BIT(0)
+#define NVVRS_INT_SRC2_ECC_DED_MASK BIT(1)
+#define NVVRS_INT_SRC2_TSD_MASK BIT(2)
+#define NVVRS_INT_SRC2_LDO_MASK BIT(3)
+#define NVVRS_INT_SRC2_BIST_MASK BIT(4)
+#define NVVRS_INT_SRC2_RT_CRC_MASK BIT(5)
+#define NVVRS_INT_SRC2_VENDOR_MASK BIT(7)
+#define NVVRS_INT_VENDOR0_MASK BIT(0)
+#define NVVRS_INT_VENDOR1_MASK BIT(1)
+#define NVVRS_INT_VENDOR2_MASK BIT(2)
+#define NVVRS_INT_VENDOR3_MASK BIT(3)
+#define NVVRS_INT_VENDOR4_MASK BIT(4)
+#define NVVRS_INT_VENDOR5_MASK BIT(5)
+#define NVVRS_INT_VENDOR6_MASK BIT(6)
+#define NVVRS_INT_VENDOR7_MASK BIT(7)
+
+/* Controller Register Mask */
+#define NVVRS_REG_CTL_1_FORCE_SHDN (BIT(0) | BIT(1))
+#define NVVRS_REG_CTL_1_FORCE_ACT BIT(2)
+#define NVVRS_REG_CTL_1_FORCE_INT BIT(3)
+#define NVVRS_REG_CTL_2_EN_PEC BIT(0)
+#define NVVRS_REG_CTL_2_REQ_PEC BIT(1)
+#define NVVRS_REG_CTL_2_RTC_PU BIT(2)
+#define NVVRS_REG_CTL_2_RTC_WAKE BIT(3)
+#define NVVRS_REG_CTL_2_RST_DLY 0xF0
+
+#define ALARM_RESET_VAL 0xffffffff
+#define NVVRS_MIN_MODEL_REV 0x40
+
+enum nvvrs_irq_regs {
+ NVVRS_IRQ_REG_INT_SRC1 = 0,
+ NVVRS_IRQ_REG_INT_SRC2 = 1,
+ NVVRS_IRQ_REG_INT_VENDOR = 2,
+ NVVRS_IRQ_REG_COUNT = 3,
+};
+
+struct nvvrs_rtc_info {
+ struct device *dev;
+ struct i2c_client *client;
+ struct rtc_device *rtc;
+ unsigned int irq;
+};
+
+static int nvvrs_update_bits(struct nvvrs_rtc_info *info, u8 reg,
+ u8 mask, u8 value)
+{
+ int ret;
+ u8 val;
+
+ ret = i2c_smbus_read_byte_data(info->client, reg);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ val &= ~mask;
+ val |= (value & mask);
+
+ return i2c_smbus_write_byte_data(info->client, reg, val);
+}
+
+static int nvvrs_rtc_write_alarm(struct i2c_client *client, u8 *time)
+{
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, NVVRS_REG_RTC_A3, time[3]);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, NVVRS_REG_RTC_A2, time[2]);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, NVVRS_REG_RTC_A1, time[1]);
+ if (ret < 0)
+ return ret;
+
+ return i2c_smbus_write_byte_data(client, NVVRS_REG_RTC_A0, time[0]);
+}
+
+static int nvvrs_rtc_enable_alarm(struct nvvrs_rtc_info *info)
+{
+ int ret;
+
+ /* Set RTC_WAKE bit for autonomous wake from sleep */
+ ret = nvvrs_update_bits(info, NVVRS_REG_CTL_2, NVVRS_REG_CTL_2_RTC_WAKE,
+ NVVRS_REG_CTL_2_RTC_WAKE);
+ if (ret < 0)
+ return ret;
+
+ /* Set RTC_PU bit for autonomous wake from shutdown */
+ ret = nvvrs_update_bits(info, NVVRS_REG_CTL_2, NVVRS_REG_CTL_2_RTC_PU,
+ NVVRS_REG_CTL_2_RTC_PU);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int nvvrs_rtc_disable_alarm(struct nvvrs_rtc_info *info)
+{
+ struct i2c_client *client = info->client;
+ u8 val[4];
+ int ret;
+
+ /* Clear RTC_WAKE bit */
+ ret = nvvrs_update_bits(info, NVVRS_REG_CTL_2, NVVRS_REG_CTL_2_RTC_WAKE,
+ 0);
+ if (ret < 0)
+ return ret;
+
+ /* Clear RTC_PU bit */
+ ret = nvvrs_update_bits(info, NVVRS_REG_CTL_2, NVVRS_REG_CTL_2_RTC_PU,
+ 0);
+ if (ret < 0)
+ return ret;
+
+ /* Write ALARM_RESET_VAL in RTC Alarm register to disable alarm */
+ val[0] = 0xff;
+ val[1] = 0xff;
+ val[2] = 0xff;
+ val[3] = 0xff;
+
+ ret = nvvrs_rtc_write_alarm(client, val);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int nvvrs_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct nvvrs_rtc_info *info = dev_get_drvdata(dev);
+ time64_t secs = 0;
+ int ret;
+ u8 val;
+
+ /*
+ * Multi-byte transfers are not supported with PEC enabled
+ * Read MSB first to avoid coherency issues
+ */
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_T3);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ secs |= (time64_t)val << 24;
+
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_T2);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ secs |= (time64_t)val << 16;
+
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_T1);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ secs |= (time64_t)val << 8;
+
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_T0);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ secs |= val;
+
+ rtc_time64_to_tm(secs, tm);
+
+ return 0;
+}
+
+static int nvvrs_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct nvvrs_rtc_info *info = dev_get_drvdata(dev);
+ time64_t secs;
+ u8 time[4];
+ int ret;
+
+ secs = rtc_tm_to_time64(tm);
+ time[0] = secs & 0xff;
+ time[1] = (secs >> 8) & 0xff;
+ time[2] = (secs >> 16) & 0xff;
+ time[3] = (secs >> 24) & 0xff;
+
+ ret = i2c_smbus_write_byte_data(info->client, NVVRS_REG_RTC_T3, time[3]);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(info->client, NVVRS_REG_RTC_T2, time[2]);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(info->client, NVVRS_REG_RTC_T1, time[1]);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(info->client, NVVRS_REG_RTC_T0, time[0]);
+
+ return ret;
+}
+
+static int nvvrs_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct nvvrs_rtc_info *info = dev_get_drvdata(dev);
+ time64_t alarm_val = 0;
+ int ret;
+ u8 val;
+
+ /* Multi-byte transfers are not supported with PEC enabled */
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_A3);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ alarm_val |= (time64_t)val << 24;
+
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_A2);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ alarm_val |= (time64_t)val << 16;
+
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_A1);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ alarm_val |= (time64_t)val << 8;
+
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_RTC_A0);
+ if (ret < 0)
+ return ret;
+
+ val = (u8)ret;
+ alarm_val |= val;
+
+ if (alarm_val == ALARM_RESET_VAL)
+ alrm->enabled = 0;
+ else
+ alrm->enabled = 1;
+
+ rtc_time64_to_tm(alarm_val, &alrm->time);
+
+ return 0;
+}
+
+static int nvvrs_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+{
+ struct nvvrs_rtc_info *info = dev_get_drvdata(dev);
+ time64_t secs;
+ u8 time[4];
+ int ret;
+
+ if (!alrm->enabled) {
+ ret = nvvrs_rtc_disable_alarm(info);
+ if (ret < 0)
+ return ret;
+ }
+
+ ret = nvvrs_rtc_enable_alarm(info);
+ if (ret < 0)
+ return ret;
+
+ secs = rtc_tm_to_time64(&alrm->time);
+ time[0] = secs & 0xff;
+ time[1] = (secs >> 8) & 0xff;
+ time[2] = (secs >> 16) & 0xff;
+ time[3] = (secs >> 24) & 0xff;
+
+ ret = nvvrs_rtc_write_alarm(info->client, time);
+
+ return ret;
+}
+
+static int nvvrs_pseq_irq_clear(struct nvvrs_rtc_info *info)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < NVVRS_IRQ_REG_COUNT; i++) {
+ ret = i2c_smbus_read_byte_data(info->client,
+ NVVRS_REG_INT_SRC1 + i);
+ if (ret < 0) {
+ dev_err(info->dev, "Failed to read INT_SRC%d : %d\n",
+ i + 1, ret);
+ return ret;
+ }
+
+ ret = i2c_smbus_write_byte_data(info->client,
+ NVVRS_REG_INT_SRC1 + i,
+ (u8)ret);
+ if (ret < 0) {
+ dev_err(info->dev, "Failed to clear INT_SRC%d : %d\n",
+ i + 1, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static irqreturn_t nvvrs_rtc_irq_handler(int irq, void *data)
+{
+ struct nvvrs_rtc_info *info = data;
+ int ret;
+
+ /* Check for RTC alarm interrupt */
+ ret = i2c_smbus_read_byte_data(info->client, NVVRS_REG_INT_SRC1);
+ if (ret < 0)
+ return IRQ_NONE;
+
+ if (ret & NVVRS_INT_SRC1_RTC_MASK) {
+ rtc_lock(info->rtc);
+ rtc_update_irq(info->rtc, 1, RTC_IRQF | RTC_AF);
+ rtc_unlock(info->rtc);
+ }
+
+ /* Clear all interrupts */
+ if (nvvrs_pseq_irq_clear(info) < 0)
+ return IRQ_NONE;
+
+ return IRQ_HANDLED;
+}
+
+static int nvvrs_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ /*
+ * This hardware does not support enabling/disabling the alarm IRQ
+ * independently. The alarm is disabled by clearing the alarm time
+ * via set_alarm().
+ */
+ return 0;
+}
+
+static const struct rtc_class_ops nvvrs_rtc_ops = {
+ .read_time = nvvrs_rtc_read_time,
+ .set_time = nvvrs_rtc_set_time,
+ .read_alarm = nvvrs_rtc_read_alarm,
+ .set_alarm = nvvrs_rtc_set_alarm,
+ .alarm_irq_enable = nvvrs_rtc_alarm_irq_enable,
+};
+
+static int nvvrs_pseq_vendor_info(struct nvvrs_rtc_info *info)
+{
+ struct i2c_client *client = info->client;
+ u8 vendor_id, model_rev;
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(client, NVVRS_REG_VENDOR_ID);
+ if (ret < 0)
+ return dev_err_probe(&client->dev, ret,
+ "Failed to read Vendor ID\n");
+
+ vendor_id = (u8)ret;
+
+ ret = i2c_smbus_read_byte_data(client, NVVRS_REG_MODEL_REV);
+ if (ret < 0)
+ return dev_err_probe(&client->dev, ret,
+ "Failed to read Model Revision\n");
+
+ model_rev = (u8)ret;
+
+ if (model_rev < NVVRS_MIN_MODEL_REV) {
+ return dev_err_probe(&client->dev, -ENODEV,
+ "Chip revision 0x%02x is not supported!\n",
+ model_rev);
+ }
+
+ dev_dbg(&client->dev, "NVVRS Vendor ID: 0x%02x, Model Rev: 0x%02x\n",
+ vendor_id, model_rev);
+
+ return 0;
+}
+
+static int nvvrs_rtc_probe(struct i2c_client *client)
+{
+ struct nvvrs_rtc_info *info;
+ int ret;
+
+ info = devm_kzalloc(&client->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ if (client->irq <= 0)
+ return dev_err_probe(&client->dev, -EINVAL, "No IRQ specified\n");
+
+ info->irq = client->irq;
+ info->dev = &client->dev;
+ client->flags |= I2C_CLIENT_PEC;
+ i2c_set_clientdata(client, info);
+ info->client = client;
+
+ /* Check vendor info */
+ if (nvvrs_pseq_vendor_info(info) < 0)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Failed to get vendor info\n");
+
+ /* Clear any pending IRQs before requesting IRQ handler */
+ if (nvvrs_pseq_irq_clear(info) < 0)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Failed to clear interrupts\n");
+
+ /* Allocate RTC device */
+ info->rtc = devm_rtc_allocate_device(info->dev);
+ if (IS_ERR(info->rtc))
+ return PTR_ERR(info->rtc);
+
+ info->rtc->ops = &nvvrs_rtc_ops;
+ info->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
+ info->rtc->range_max = RTC_TIMESTAMP_END_2099;
+
+ /* Request RTC IRQ */
+ ret = devm_request_threaded_irq(info->dev, info->irq, NULL,
+ nvvrs_rtc_irq_handler, IRQF_ONESHOT,
+ "nvvrs-rtc", info);
+ if (ret < 0) {
+ dev_err_probe(info->dev, ret, "Failed to request RTC IRQ\n");
+ return ret;
+ }
+
+ /* RTC as a wakeup source */
+ devm_device_init_wakeup(info->dev);
+
+ return devm_rtc_register_device(info->rtc);
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int nvvrs_rtc_suspend(struct device *dev)
+{
+ struct nvvrs_rtc_info *info = dev_get_drvdata(dev);
+ int ret;
+
+ if (device_may_wakeup(dev)) {
+ /* Set RTC_WAKE bit for auto wake system from suspend state */
+ ret = nvvrs_update_bits(info, NVVRS_REG_CTL_2,
+ NVVRS_REG_CTL_2_RTC_WAKE,
+ NVVRS_REG_CTL_2_RTC_WAKE);
+ if (ret < 0) {
+ dev_err(info->dev, "Failed to set RTC_WAKE bit (%d)\n",
+ ret);
+ return ret;
+ }
+
+ return enable_irq_wake(info->irq);
+ }
+
+ return 0;
+}
+
+static int nvvrs_rtc_resume(struct device *dev)
+{
+ struct nvvrs_rtc_info *info = dev_get_drvdata(dev);
+ int ret;
+
+ if (device_may_wakeup(dev)) {
+ /* Clear FORCE_ACT bit */
+ ret = nvvrs_update_bits(info, NVVRS_REG_CTL_1,
+ NVVRS_REG_CTL_1_FORCE_ACT, 0);
+ if (ret < 0) {
+ dev_err(info->dev, "Failed to clear FORCE_ACT bit (%d)\n",
+ ret);
+ return ret;
+ }
+
+ return disable_irq_wake(info->irq);
+ }
+
+ return 0;
+}
+
+#endif
+static SIMPLE_DEV_PM_OPS(nvvrs_rtc_pm_ops, nvvrs_rtc_suspend, nvvrs_rtc_resume);
+
+static const struct of_device_id nvvrs_rtc_of_match[] = {
+ { .compatible = "nvidia,vrs-10" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, nvvrs_rtc_of_match);
+
+static struct i2c_driver nvvrs_rtc_driver = {
+ .driver = {
+ .name = "rtc-nvidia-vrs10",
+ .pm = &nvvrs_rtc_pm_ops,
+ .of_match_table = nvvrs_rtc_of_match,
+ },
+ .probe = nvvrs_rtc_probe,
+};
+
+module_i2c_driver(nvvrs_rtc_driver);
+
+MODULE_AUTHOR("Shubhi Garg <shgarg@nvidia.com>");
+MODULE_DESCRIPTION("NVIDIA Voltage Regulator Specification RTC driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v7 4/4] arm64: defconfig: enable NVIDIA VRS PSEQ RTC
From: Shubhi Garg @ 2025-10-07 13:57 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Catalin Marinas, Will Deacon, Alexandre Belloni, Jonathan Hunter
Cc: devicetree, linux-arm-kernel, linux-rtc, linux-tegra, Shubhi Garg
In-Reply-To: <20251007135738.487694-1-shgarg@nvidia.com>
Enable NVIDIA VRS (Voltage Regulator Specification) RTC device module.
It provides functionality to get/set system time, retain system time
across boot, wake system from suspend and shutdown state.
Supported platforms:
- NVIDIA Jetson AGX Orin Developer Kit
- NVIDIA IGX Orin Development Kit
- NVIDIA Jetson Orin NX Developer Kit
- NVIDIA Jetson Orin Nano Developer Kit
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
---
v7:
- no changes
v6:
- no changes
v5:
- removed VRS MFD CONFIG
- changed VRS RTC CONFIG name
v4:
- no changes
v3:
- no changes
v2:
- moved VRS RTC config to correct place
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e3a2d37bd104..a7fb6aa4062c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1283,6 +1283,7 @@ CONFIG_RTC_DRV_MT6397=m
CONFIG_RTC_DRV_XGENE=y
CONFIG_RTC_DRV_TI_K3=m
CONFIG_RTC_DRV_RENESAS_RTCA3=m
+CONFIG_RTC_DRV_NVIDIA_VRS10=m
CONFIG_DMADEVICES=y
CONFIG_DMA_BCM2835=y
CONFIG_DMA_SUN6I=m
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 02/13] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: Rob Herring (Arm) @ 2025-10-09 0:43 UTC (permalink / raw)
To: James Calligeros
Cc: linux-input, Dmitry Torokhov, linux-rtc, asahi, linux-kernel,
Jonathan Corbet, linux-doc, Alexandre Belloni, devicetree,
linux-hwmon, Alyssa Rosenzweig, Janne Grunau, Lee Jones,
Jean Delvare, linux-arm-kernel, Conor Dooley, Guenter Roeck,
Neal Gompa, Krzysztof Kozlowski, Sven Peter
In-Reply-To: <20251007-macsmc-subdevs-v3-2-d7d3bfd7ae02@gmail.com>
On Tue, 07 Oct 2025 21:16:43 +1000, James Calligeros wrote:
> Apple Silicon devices integrate a vast array of sensors, monitoring
> current, power, temperature, and voltage across almost every part of
> the system. The sensors themselves are all connected to the System
> Management Controller (SMC). The SMC firmware exposes the data
> reported by these sensors via its standard FourCC-based key-value
> API. The SMC is also responsible for monitoring and controlling any
> fans connected to the system, exposing them in the same way.
>
> For reasons known only to Apple, each device exposes its sensors with
> an almost totally unique set of keys. This is true even for devices
> which share an SoC. An M1 Mac mini, for example, will report its core
> temperatures on different keys to an M1 MacBook Pro. Worse still, the
> SMC does not provide a way to enumerate the available keys at runtime,
> nor do the keys follow any sort of reasonable or consistent naming
> rules that could be used to deduce their purpose. We must therefore
> know which keys are present on any given device, and which function
> they serve, ahead of time.
>
> Add a schema so that we can describe the available sensors for a given
> Apple Silicon device in the Devicetree.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> .../bindings/hwmon/apple,smc-hwmon.yaml | 86 +++++++++++++++++++++++++
> .../bindings/mfd/apple,smc.yaml | 36 +++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 123 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 06/13] hwmon: Add Apple Silicon SMC hwmon driver
From: Guenter Roeck @ 2025-10-09 1:58 UTC (permalink / raw)
To: James Calligeros, Sven Peter, Janne Grunau, Alyssa Rosenzweig,
Neal Gompa, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Jean Delvare, Dmitry Torokhov,
Jonathan Corbet
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251007-macsmc-subdevs-v3-6-d7d3bfd7ae02@gmail.com>
On 10/7/25 04:16, James Calligeros wrote:
> The System Management Controller on Apple Silicon devices is responsible
> for integrating and exposing the data reported by the vast array of
> hardware monitoring sensors present on these devices. It is also
> responsible for fan control, and allows users to manually set fan
> speeds if they so desire. Add a hwmon driver to expose current,
> power, temperature, and voltage monitoring sensors, as well as
> fan speed monitoring and control via the SMC on Apple Silicon devices.
>
> The SMC firmware has no consistency between devices, even when they
> share an SoC. The FourCC keys used to access sensors are almost
> random. An M1 Mac mini will have different FourCCs for its CPU core
> temperature sensors to an M1 MacBook Pro, for example. For this
> reason, the valid sensors for a given device are specified in a
> child of the SMC Devicetree node. The driver uses this information
> to determine which sensors to make available at runtime.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Co-developed-by: Janne Grunau <j@jannau.net>
> Signed-off-by: Janne Grunau <j@jannau.net>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* RE: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053 support
From: Lakshay Piplani @ 2025-10-09 8:13 UTC (permalink / raw)
To: Conor Dooley
Cc: 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, Pankit Garg,
Vikash Bansal, Priyanka Jain, Shashank Rebbapragada
In-Reply-To: <20250923-capitol-easter-d0154d967522@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, September 24, 2025 12:28 AM
> To: Lakshay Piplani <lakshay.piplani@nxp.com>
> Cc: 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; Pankit Garg
> <pankit.garg@nxp.com>; Vikash Bansal <vikash.bansal@nxp.com>; Priyanka
> Jain <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>
> Subject: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053 support
>
> On Tue, Sep 23, 2025 at 05:04:40PM +0530, Lakshay Piplani wrote:
> > Add device tree bindings for NXP PCF85053 RTC chip.
> >
> > Signed-off-by: Pankit Garg <pankit.garg@nxp.com>
> > Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> > ---
> > V3 -> V4: Add dedicated nxp,pcf85053.yaml.
> > Remove entry from trivial-rtc.yaml.
> > V2 -> V3: Moved MAINTAINERS file changes to the driver patch
> > V1 -> V2: Handled dt-bindings by trivial-rtc.yaml
> >
> > .../devicetree/bindings/rtc/nxp,pcf85053.yaml | 128
> > ++++++++++++++++++
> > 1 file changed, 128 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > b/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > new file mode 100644
> > index 000000000000..6b1c97358486
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > @@ -0,0 +1,128 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright
> > +2025 NXP %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/rtc/nxp,pcf85053.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP PCF85053 Real Time Clock
> > +
> > +maintainers:
> > + - Pankit Garg <pankit.garg@nxp.com>
> > + - Lakshay Piplani <lakshay.piplani@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - nxp,pcf85053
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + nxp,interface:
> > + $ref: /schemas/types.yaml#/definitions/string
> > + enum: [ primary, secondary ]
> > + description: |
> > + Identifies this host's logical role in a multi-host topology for the
> > + PCF85053 RTC. The device exposes a "TWO" ownership bit in the CTRL
> > + register that gates which host may write time/alarm registers.
> > + - "primary": Designated host that *may* claim write ownership (set
> > + CTRL.TWO=1) **if** write-access is explicitly requested.
> > + - "secondary": Peer host that writes only when CTRL.TWO=0 (default).
> > +
> > + nxp,write-access:
> > + type: boolean
> > + description: |
> > + Request the driver to claim write ownership at probe time by setting
> > + CTRL.TWO=1. This property is only valid when nxp,interface="primary".
> > + The driver will not modify any other CTRL bits (HF/DM/etc.) and will
> not
> > + clear any status/interrupt flags at probe.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - nxp,interface
> > +
> > +additionalProperties: false
> > +
> > +# Schema constraints matching driver:
> > +# 1) If nxp,write-access is present, nxp,interface must be "primary".
> > +# Rationale: only the primary may claim ownership; driver will set
> TWO=1.
> > +# 2) If nxp,interface is "secondary", nxp,write-access must not be present.
> > +# Rationale: secondary never claims ownership and cannot write
> CTRL/ST/alarm.
> > +#
> > +# Practical effect:
> > +# - Primary without 'nxp,write-access'; primary is read only; secondary
> may
> > +# write time registers.
> > +# - Primary with 'nxp,write-access'; primary owns writes, secondary is read
> only.
> > +allOf:
> > + - $ref: rtc.yaml#
> > + - oneOf:
> > + # Case 1: primary with write-access
> > + - required: [ "nxp,write-access" ]
> > + properties:
> > + nxp,interface:
> > + const: primary
> > +
> > + # Case 2: primary without write-access
> > + - properties:
> > + nxp,interface:
> > + const: primary
> > + not:
> > + required: [ "nxp,write-access" ]
>
> Aren't case 1 and case 2 here redundant? All you need to do is block interface
> == secondary when nxp,write-access is present, which your case
> 3 should be able to be modified to do via
>
> if:
> properties:
> nxp,interface:
> const: secondary
> then:
> properties:
> nxp,write-access: false
>
> I think your description for nxp,write-access gets the point across about when
> it can be used, and the additional commentary is not really helpful.
>
Thanks for reviewing the patch.
We kept both cases: primary with write-access and primary without write-access, because the hardware
supports three different ways it can be used, and we want to show that clearly in the bindings:
Primary with nxp,write-access: primary host can write to the device.
Primary without nxp,write-access - primary host is read-only, and the secondary host can write.
Secondary - default role, with write access; when no primary host is claiming it.
Even though both case 1 and 2 use nxp,interface = "primary", they behave differently.
Keeping both cases separate makes it easier to understand whether Primary host can write or not.
> > +
> > + # Case 3: secondary (must not have write-access)
> > + - properties:
> > + nxp,interface:
> > + const: secondary
> > + not:
> > + required: [ "nxp,write-access" ]
> > +
> > +examples:
> > + # Single host example.
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + rtc@6f {
> > + compatible = "nxp,pcf85053";
> > + reg = <0x6f>;
> > + nxp,interface = "primary";
> > + nxp,write-access;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > + };
> > + };
> > +
> > + # Dual-host example: one primary that claims writes; one secondary that
> never claims writes.
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + i2c0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + rtc@6f {
> > + compatible = "nxp,pcf85053";
> > + reg = <0x6f>;
> > + nxp,interface = "primary";
> > + nxp,write-access;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > + };
> > + };
> > +
> > + i2c1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + rtc@6f {
> > + compatible = "nxp,pcf85053";
> > + reg = <0x6f>;
> > + nxp,interface = "secondary";
>
> Maybe a silly question, but if you have a system that wants to have two pairs
> of RTCs, how would you determine which primary a secondary belongs to? I
> notice you have no link between these devices in dt so I am curious. Would it
> be better to eschew nxp,interface and have a phandle from the secondary to
> the primary?
>
> I don't know anything about your use case or features, so maybe knowing the
> relationship just is not relevant at all, or it can be determined at runtime.
>
> Cheers,
> Conor.
This device can connect to two independent hosts via separate I²C buses.
Each host sees the same hardware instance through its own I²C address. The nxp,interface
property simply declares the host's role, so the driver knows whether to attempt write
access or not.
Thanks
Lakshay
^ permalink raw reply
* Re: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053 support
From: Conor Dooley @ 2025-10-09 17:00 UTC (permalink / raw)
To: Lakshay Piplani
Cc: 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, Pankit Garg,
Vikash Bansal, Priyanka Jain, Shashank Rebbapragada
In-Reply-To: <AS4PR04MB93620F7CAD21F745B95FAF1CFBEEA@AS4PR04MB9362.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 8672 bytes --]
On Thu, Oct 09, 2025 at 08:13:49AM +0000, Lakshay Piplani wrote:
>
> > -----Original Message-----
> > From: Conor Dooley <conor@kernel.org>
> > Sent: Wednesday, September 24, 2025 12:28 AM
> > To: Lakshay Piplani <lakshay.piplani@nxp.com>
> > Cc: 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; Pankit Garg
> > <pankit.garg@nxp.com>; Vikash Bansal <vikash.bansal@nxp.com>; Priyanka
> > Jain <priyanka.jain@nxp.com>; Shashank Rebbapragada
> > <shashank.rebbapragada@nxp.com>
> > Subject: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053 support
> >
> > On Tue, Sep 23, 2025 at 05:04:40PM +0530, Lakshay Piplani wrote:
> > > Add device tree bindings for NXP PCF85053 RTC chip.
> > >
> > > Signed-off-by: Pankit Garg <pankit.garg@nxp.com>
> > > Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> > > ---
> > > V3 -> V4: Add dedicated nxp,pcf85053.yaml.
> > > Remove entry from trivial-rtc.yaml.
> > > V2 -> V3: Moved MAINTAINERS file changes to the driver patch
> > > V1 -> V2: Handled dt-bindings by trivial-rtc.yaml
> > >
> > > .../devicetree/bindings/rtc/nxp,pcf85053.yaml | 128
> > > ++++++++++++++++++
> > > 1 file changed, 128 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > b/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > new file mode 100644
> > > index 000000000000..6b1c97358486
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > @@ -0,0 +1,128 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright
> > > +2025 NXP %YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/rtc/nxp,pcf85053.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: NXP PCF85053 Real Time Clock
> > > +
> > > +maintainers:
> > > + - Pankit Garg <pankit.garg@nxp.com>
> > > + - Lakshay Piplani <lakshay.piplani@nxp.com>
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - nxp,pcf85053
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + nxp,interface:
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [ primary, secondary ]
> > > + description: |
> > > + Identifies this host's logical role in a multi-host topology for the
> > > + PCF85053 RTC. The device exposes a "TWO" ownership bit in the CTRL
> > > + register that gates which host may write time/alarm registers.
> > > + - "primary": Designated host that *may* claim write ownership (set
> > > + CTRL.TWO=1) **if** write-access is explicitly requested.
> > > + - "secondary": Peer host that writes only when CTRL.TWO=0 (default).
> > > +
> > > + nxp,write-access:
> > > + type: boolean
> > > + description: |
> > > + Request the driver to claim write ownership at probe time by setting
> > > + CTRL.TWO=1. This property is only valid when nxp,interface="primary".
> > > + The driver will not modify any other CTRL bits (HF/DM/etc.) and will
> > not
> > > + clear any status/interrupt flags at probe.
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - nxp,interface
> > > +
> > > +additionalProperties: false
> > > +
> > > +# Schema constraints matching driver:
> > > +# 1) If nxp,write-access is present, nxp,interface must be "primary".
> > > +# Rationale: only the primary may claim ownership; driver will set
> > TWO=1.
> > > +# 2) If nxp,interface is "secondary", nxp,write-access must not be present.
> > > +# Rationale: secondary never claims ownership and cannot write
> > CTRL/ST/alarm.
> > > +#
> > > +# Practical effect:
> > > +# - Primary without 'nxp,write-access'; primary is read only; secondary
> > may
> > > +# write time registers.
> > > +# - Primary with 'nxp,write-access'; primary owns writes, secondary is read
> > only.
> > > +allOf:
> > > + - $ref: rtc.yaml#
> > > + - oneOf:
> > > + # Case 1: primary with write-access
> > > + - required: [ "nxp,write-access" ]
> > > + properties:
> > > + nxp,interface:
> > > + const: primary
> > > +
> > > + # Case 2: primary without write-access
> > > + - properties:
> > > + nxp,interface:
> > > + const: primary
> > > + not:
> > > + required: [ "nxp,write-access" ]
> >
> > Aren't case 1 and case 2 here redundant? All you need to do is block interface
> > == secondary when nxp,write-access is present, which your case
> > 3 should be able to be modified to do via
> >
> > if:
> > properties:
> > nxp,interface:
> > const: secondary
> > then:
> > properties:
> > nxp,write-access: false
> >
> > I think your description for nxp,write-access gets the point across about when
> > it can be used, and the additional commentary is not really helpful.
> >
> Thanks for reviewing the patch.
>
> We kept both cases: primary with write-access and primary without write-access, because the hardware
> supports three different ways it can be used, and we want to show that clearly in the bindings:
>
> Primary with nxp,write-access: primary host can write to the device.
> Primary without nxp,write-access - primary host is read-only, and the secondary host can write.
> Secondary - default role, with write access; when no primary host is claiming it.
>
> Even though both case 1 and 2 use nxp,interface = "primary", they behave differently.
> Keeping both cases separate makes it easier to understand whether Primary host can write or not.
Just explain it properly in the property description, creating
if/then/else stuff with additional commentary like this makes it more,
rather than less, confusing.
>
> > > +
> > > + # Case 3: secondary (must not have write-access)
> > > + - properties:
> > > + nxp,interface:
> > > + const: secondary
> > > + not:
> > > + required: [ "nxp,write-access" ]
> > > +
> > > +examples:
> > > + # Single host example.
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + i2c {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + rtc@6f {
> > > + compatible = "nxp,pcf85053";
> > > + reg = <0x6f>;
> > > + nxp,interface = "primary";
> > > + nxp,write-access;
> > > + interrupt-parent = <&gpio2>;
> > > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > > + };
> > > + };
> > > +
> > > + # Dual-host example: one primary that claims writes; one secondary that
> > never claims writes.
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + i2c0 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + rtc@6f {
> > > + compatible = "nxp,pcf85053";
> > > + reg = <0x6f>;
> > > + nxp,interface = "primary";
> > > + nxp,write-access;
> > > + interrupt-parent = <&gpio2>;
> > > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > > + };
> > > + };
> > > +
> > > + i2c1 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + rtc@6f {
> > > + compatible = "nxp,pcf85053";
> > > + reg = <0x6f>;
> > > + nxp,interface = "secondary";
> >
> > Maybe a silly question, but if you have a system that wants to have two pairs
> > of RTCs, how would you determine which primary a secondary belongs to? I
> > notice you have no link between these devices in dt so I am curious. Would it
> > be better to eschew nxp,interface and have a phandle from the secondary to
> > the primary?
> >
> > I don't know anything about your use case or features, so maybe knowing the
> > relationship just is not relevant at all, or it can be determined at runtime.
>
> This device can connect to two independent hosts via separate I²C buses.
> Each host sees the same hardware instance through its own I²C address. The nxp,interface
> property simply declares the host's role, so the driver knows whether to attempt write
> access or not.
That doesn't really answer what I was looking for. Is knowing the
relationships either unimportant or determinable at runtime?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* RE: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053 support
From: Lakshay Piplani @ 2025-10-10 5:21 UTC (permalink / raw)
To: Conor Dooley
Cc: 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, Pankit Garg,
Vikash Bansal, Priyanka Jain, Shashank Rebbapragada
In-Reply-To: <20251009-shrank-caucus-5f42afa398fa@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Thursday, October 9, 2025 10:30 PM
> To: Lakshay Piplani <lakshay.piplani@nxp.com>
> Cc: 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; Pankit Garg
> <pankit.garg@nxp.com>; Vikash Bansal <vikash.bansal@nxp.com>; Priyanka
> Jain <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>
> Subject: Re: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053 support
>
> On Thu, Oct 09, 2025 at 08:13:49AM +0000, Lakshay Piplani wrote:
> >
> > > -----Original Message-----
> > > From: Conor Dooley <conor@kernel.org>
> > > Sent: Wednesday, September 24, 2025 12:28 AM
> > > To: Lakshay Piplani <lakshay.piplani@nxp.com>
> > > Cc: 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; Pankit Garg
> > > <pankit.garg@nxp.com>; Vikash Bansal <vikash.bansal@nxp.com>;
> > > Priyanka Jain <priyanka.jain@nxp.com>; Shashank Rebbapragada
> > > <shashank.rebbapragada@nxp.com>
> > > Subject: [EXT] Re: [PATCH v4 1/2] dt-bindings: rtc: Add pcf85053
> > > support
> > >
> > > On Tue, Sep 23, 2025 at 05:04:40PM +0530, Lakshay Piplani wrote:
> > > > Add device tree bindings for NXP PCF85053 RTC chip.
> > > >
> > > > Signed-off-by: Pankit Garg <pankit.garg@nxp.com>
> > > > Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> > > > ---
> > > > V3 -> V4: Add dedicated nxp,pcf85053.yaml.
> > > > Remove entry from trivial-rtc.yaml.
> > > > V2 -> V3: Moved MAINTAINERS file changes to the driver patch
> > > > V1 -> V2: Handled dt-bindings by trivial-rtc.yaml
> > > >
> > > > .../devicetree/bindings/rtc/nxp,pcf85053.yaml | 128
> > > > ++++++++++++++++++
> > > > 1 file changed, 128 insertions(+) create mode 100644
> > > > Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > > b/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > > new file mode 100644
> > > > index 000000000000..6b1c97358486
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85053.yaml
> > > > @@ -0,0 +1,128 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) #
> > > > +Copyright
> > > > +2025 NXP %YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/rtc/nxp,pcf85053.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: NXP PCF85053 Real Time Clock
> > > > +
> > > > +maintainers:
> > > > + - Pankit Garg <pankit.garg@nxp.com>
> > > > + - Lakshay Piplani <lakshay.piplani@nxp.com>
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - nxp,pcf85053
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + interrupts:
> > > > + maxItems: 1
> > > > +
> > > > + nxp,interface:
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [ primary, secondary ]
> > > > + description: |
> > > > + Identifies this host's logical role in a multi-host topology for the
> > > > + PCF85053 RTC. The device exposes a "TWO" ownership bit in the
> CTRL
> > > > + register that gates which host may write time/alarm registers.
> > > > + - "primary": Designated host that *may* claim write ownership
> (set
> > > > + CTRL.TWO=1) **if** write-access is explicitly requested.
> > > > + - "secondary": Peer host that writes only when CTRL.TWO=0
> (default).
> > > > +
> > > > + nxp,write-access:
> > > > + type: boolean
> > > > + description: |
> > > > + Request the driver to claim write ownership at probe time by setting
> > > > + CTRL.TWO=1. This property is only valid when
> nxp,interface="primary".
> > > > + The driver will not modify any other CTRL bits (HF/DM/etc.)
> > > > + and will
> > > not
> > > > + clear any status/interrupt flags at probe.
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - nxp,interface
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +# Schema constraints matching driver:
> > > > +# 1) If nxp,write-access is present, nxp,interface must be "primary".
> > > > +# Rationale: only the primary may claim ownership; driver will set
> > > TWO=1.
> > > > +# 2) If nxp,interface is "secondary", nxp,write-access must not be
> present.
> > > > +# Rationale: secondary never claims ownership and cannot write
> > > CTRL/ST/alarm.
> > > > +#
> > > > +# Practical effect:
> > > > +# - Primary without 'nxp,write-access'; primary is read only;
> > > > +secondary
> > > may
> > > > +# write time registers.
> > > > +# - Primary with 'nxp,write-access'; primary owns writes,
> > > > +secondary is read
> > > only.
> > > > +allOf:
> > > > + - $ref: rtc.yaml#
> > > > + - oneOf:
> > > > + # Case 1: primary with write-access
> > > > + - required: [ "nxp,write-access" ]
> > > > + properties:
> > > > + nxp,interface:
> > > > + const: primary
> > > > +
> > > > + # Case 2: primary without write-access
> > > > + - properties:
> > > > + nxp,interface:
> > > > + const: primary
> > > > + not:
> > > > + required: [ "nxp,write-access" ]
> > >
> > > Aren't case 1 and case 2 here redundant? All you need to do is block
> > > interface == secondary when nxp,write-access is present, which your
> > > case
> > > 3 should be able to be modified to do via
> > >
> > > if:
> > > properties:
> > > nxp,interface:
> > > const: secondary
> > > then:
> > > properties:
> > > nxp,write-access: false
> > >
> > > I think your description for nxp,write-access gets the point across
> > > about when it can be used, and the additional commentary is not really
> helpful.
> > >
> > Thanks for reviewing the patch.
> >
> > We kept both cases: primary with write-access and primary without
> > write-access, because the hardware supports three different ways it can be
> used, and we want to show that clearly in the bindings:
> >
> > Primary with nxp,write-access: primary host can write to the device.
> > Primary without nxp,write-access - primary host is read-only, and the
> secondary host can write.
> > Secondary - default role, with write access; when no primary host is
> claiming it.
> >
> > Even though both case 1 and 2 use nxp,interface = "primary", they behave
> differently.
> > Keeping both cases separate makes it easier to understand whether Primary
> host can write or not.
>
> Just explain it properly in the property description, creating if/then/else stuff
> with additional commentary like this makes it more, rather than less,
> confusing.
>
Understood - we'll simplify the schema by keeping only the if/then constraint and move the explanation
of the valid configurations into the property descriptions for nxp,interface and nxp,write-access rather than
in comments.
> >
> > > > +
> > > > + # Case 3: secondary (must not have write-access)
> > > > + - properties:
> > > > + nxp,interface:
> > > > + const: secondary
> > > > + not:
> > > > + required: [ "nxp,write-access" ]
> > > > +
> > > > +examples:
> > > > + # Single host example.
> > > > + - |
> > > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > > + i2c {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + rtc@6f {
> > > > + compatible = "nxp,pcf85053";
> > > > + reg = <0x6f>;
> > > > + nxp,interface = "primary";
> > > > + nxp,write-access;
> > > > + interrupt-parent = <&gpio2>;
> > > > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > > > + };
> > > > + };
> > > > +
> > > > + # Dual-host example: one primary that claims writes; one
> > > > + secondary that
> > > never claims writes.
> > > > + - |
> > > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > > + i2c0 {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + rtc@6f {
> > > > + compatible = "nxp,pcf85053";
> > > > + reg = <0x6f>;
> > > > + nxp,interface = "primary";
> > > > + nxp,write-access;
> > > > + interrupt-parent = <&gpio2>;
> > > > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > > > + };
> > > > + };
> > > > +
> > > > + i2c1 {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + rtc@6f {
> > > > + compatible = "nxp,pcf85053";
> > > > + reg = <0x6f>;
> > > > + nxp,interface = "secondary";
> > >
> > > Maybe a silly question, but if you have a system that wants to have
> > > two pairs of RTCs, how would you determine which primary a secondary
> > > belongs to? I notice you have no link between these devices in dt so
> > > I am curious. Would it be better to eschew nxp,interface and have a
> > > phandle from the secondary to the primary?
> > >
> > > I don't know anything about your use case or features, so maybe
> > > knowing the relationship just is not relevant at all, or it can be determined
> at runtime.
> >
> > This device can connect to two independent hosts via separate I²C buses.
> > Each host sees the same hardware instance through its own I²C address.
> > The nxp,interface property simply declares the host's role, so the
> > driver knows whether to attempt write access or not.
>
> That doesn't really answer what I was looking for. Is knowing the relationships
> either unimportant or determinable at runtime?
Primary and secondary are independent hosts connected to separate I²C buses,
so, no relationship needs to be described between them.
Thanks
Lakshay
^ permalink raw reply
* Re: [PATCH v1 5/7] clk: s2mps11: add the support for S2MPS16 PMIC clock
From: Krzysztof Kozlowski @ 2025-10-10 13:05 UTC (permalink / raw)
To: Ivaylo Ivanov, André Draszik, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Alexandre Belloni
Cc: linux-samsung-soc, devicetree, linux-clk, linux-rtc, linux-kernel
In-Reply-To: <20250914124227.2619925-6-ivo.ivanov.ivanov1@gmail.com>
On 14/09/2025 14:42, Ivaylo Ivanov wrote:
> Add the support for S2MPS16 PMIC clock, which is functionally the same
> as the currently supported ones, with the exception of a different
> register.
>
> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
> ---
> drivers/clk/clk-s2mps11.c | 8 ++++++++
This depends on mfd patch. Many maintainers would appreciate if you
mention it also in the patch changelog (---), not only cover letter.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 6/7] rtc: s5m: add support for S2MPS16 RTC
From: Krzysztof Kozlowski @ 2025-10-10 13:07 UTC (permalink / raw)
To: Ivaylo Ivanov, André Draszik, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Alexandre Belloni
Cc: linux-samsung-soc, devicetree, linux-clk, linux-rtc, linux-kernel
In-Reply-To: <20250914124227.2619925-7-ivo.ivanov.ivanov1@gmail.com>
On 14/09/2025 14:42, Ivaylo Ivanov wrote:
> Add support for Samsung's S2MPS16 PMIC RTC, which has pretty much
> identical functionality to the existing S2MPS15 support, with the
> difference being the ST2 register.
>
> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
> ---
> drivers/rtc/rtc-s5m.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
> index a7220b4d0..910248731 100644
> --- a/drivers/rtc/rtc-s5m.c
> +++ b/drivers/rtc/rtc-s5m.c
> @@ -18,6 +18,7 @@
> #include <linux/mfd/samsung/irq.h>
> #include <linux/mfd/samsung/rtc.h>
> #include <linux/mfd/samsung/s2mps14.h>
> +#include <linux/mfd/samsung/s2mps16.h>
>
> /*
> * Maximum number of retries for checking changes in UDR field
> @@ -254,6 +255,11 @@ static int s5m_check_pending_alarm_interrupt(struct s5m_rtc_info *info,
> ret = regmap_read(info->regmap, S5M_RTC_STATUS, &val);
> val &= S5M_ALARM0_STATUS;
> break;
> + case S2MPS16X:
> + ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS16_REG_ST2,
> + &val);
> + val &= S2MPS_ALARM0_STATUS;
> + break;
> case S2MPG10:
> case S2MPS15X:
> case S2MPS14X:
> @@ -303,6 +309,7 @@ static int s5m8767_rtc_set_alarm_reg(struct s5m_rtc_info *info)
> udr_mask |= S5M_RTC_TIME_EN_MASK;
> break;
> case S2MPG10:
> + case S2MPS16X:
> case S2MPS15X:
> case S2MPS14X:
> case S2MPS13X:
Interesting, so we have here reversed alphabetical order within
S2MPSXXX... that is probably my achievement. Me minus 10 years would not
pass my current review, for sure.
Thanks for the patches, nice work.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 7/7] regulator: s2mps11: add support for S2MPS16 regulators
From: Krzysztof Kozlowski @ 2025-10-10 13:08 UTC (permalink / raw)
To: Ivaylo Ivanov, André Draszik, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Alexandre Belloni
Cc: linux-samsung-soc, devicetree, linux-clk, linux-rtc, linux-kernel
In-Reply-To: <20250914124227.2619925-8-ivo.ivanov.ivanov1@gmail.com>
On 14/09/2025 14:42, Ivaylo Ivanov wrote:
> S2MPS16 is a PMIC, manufactured by Samsung, particularly used in
> exynos8890 based devices, featuring 38 LDOs, of which 11 are used for
> CP, and 11 BUCKs, of which 1 is used for CP. Add driver support for
> controlling all BUCKs and LDOs, except the ones used for CP, as they are
> not documented enough and the vendor kernel doesn't handle them anyways.
>
> Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 4/7] mfd: sec: add support for s2mps16 pmic
From: Krzysztof Kozlowski @ 2025-10-10 13:12 UTC (permalink / raw)
To: Ivaylo Ivanov, André Draszik, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Lee Jones, Liam Girdwood, Mark Brown,
Alexandre Belloni
Cc: linux-samsung-soc, devicetree, linux-clk, linux-rtc, linux-kernel
In-Reply-To: <20250914124227.2619925-5-ivo.ivanov.ivanov1@gmail.com>
On 14/09/2025 14:42, Ivaylo Ivanov wrote:
> enum s2mpu02_irq {
> S2MPU02_IRQ_PWRONF,
> S2MPU02_IRQ_PWRONR,
> diff --git a/include/linux/mfd/samsung/s2mps16.h b/include/linux/mfd/samsung/s2mps16.h
> new file mode 100644
> index 000000000..d4394b054
> --- /dev/null
> +++ b/include/linux/mfd/samsung/s2mps16.h
> @@ -0,0 +1,195 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
Does the license 2.0+ (so 3.0 and so one) come from the downstream you
copied it? Or from other upstream? If not, thus it is your invention,
please keep only 2.0.
Anyway:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 1/4] dt-bindings: rtc: Document NVIDIA VRS RTC
From: Rob Herring (Arm) @ 2025-10-10 14:32 UTC (permalink / raw)
To: Shubhi Garg
Cc: devicetree, linux-tegra, Catalin Marinas, Will Deacon,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, linux-rtc,
Jonathan Hunter, Lee Jones, Alexandre Belloni
In-Reply-To: <20251007135738.487694-2-shgarg@nvidia.com>
On Tue, 07 Oct 2025 13:57:35 +0000, Shubhi Garg wrote:
> Add device tree bindings for NVIDIA VRS (Voltage Regulator Specification)
> RTC device. NVIDIA VRS is a Power Management IC (PMIC) that implements a
> power sequencing solution with I2C interface. The device includes RTC
> which provides functionality to get/set system time, retain system
> time across boot, wake system from suspend and shutdown state.
>
> Supported platforms:
> - NVIDIA Jetson AGX Orin Developer Kit
> - NVIDIA IGX Orin Development Kit
> - NVIDIA Jetson Orin NX Developer Kit
> - NVIDIA Jetson Orin Nano Developer Kit
>
> Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
> ---
>
> v7:
> - dt binding file name fix to keep same as compatible
>
> v6:
> - compatible name fixes to "nvidia,vrs-10"
> - changed dtb node name to pmic@3c
>
> v5:
> - moved device tree bindings from mfd to rtc
> - changed dtb node name to rtc@3c
> - changed compatible string to "nvidia,vrs10-rtc"
>
> v4:
> - no changes
>
> v3:
> - fixed device tree node name to generic "pmic@3c"
> - fixed indentation
>
> v2:
> - fixed copyrights
> - updated description with RTC information
> - added status node in dtb node example
>
> .../bindings/rtc/nvidia,vrs-10.yaml | 59 +++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/nvidia,vrs-10.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 06/13] hwmon: Add Apple Silicon SMC hwmon driver
From: kernel test robot @ 2025-10-10 20:25 UTC (permalink / raw)
To: James Calligeros, Sven Peter, Janne Grunau, Alyssa Rosenzweig,
Neal Gompa, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Jean Delvare, Guenter Roeck,
Dmitry Torokhov, Jonathan Corbet
Cc: oe-kbuild-all, asahi, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251007-macsmc-subdevs-v3-6-d7d3bfd7ae02@gmail.com>
Hi James,
kernel test robot noticed the following build errors:
[auto build test ERROR on c746c3b5169831d7fb032a1051d8b45592ae8d78]
url: https://github.com/intel-lab-lkp/linux/commits/James-Calligeros/dt-bindings-rtc-Add-Apple-SMC-RTC/20251010-092141
base: c746c3b5169831d7fb032a1051d8b45592ae8d78
patch link: https://lore.kernel.org/r/20251007-macsmc-subdevs-v3-6-d7d3bfd7ae02%40gmail.com
patch subject: [PATCH v3 06/13] hwmon: Add Apple Silicon SMC hwmon driver
config: sparc-allmodconfig (https://download.01.org/0day-ci/archive/20251011/202510110421.ZnJdu1ds-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251011/202510110421.ZnJdu1ds-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/202510110421.ZnJdu1ds-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/hwmon/macsmc-hwmon.c: In function 'macsmc_hwmon_write_f32':
>> drivers/hwmon/macsmc-hwmon.c:246:24: error: implicit declaration of function 'FIELD_PREP' [-Wimplicit-function-declaration]
246 | fval = FIELD_PREP(FLT_SIGN_MASK, neg) |
| ^~~~~~~~~~
vim +/FIELD_PREP +246 drivers/hwmon/macsmc-hwmon.c
225
226 static int macsmc_hwmon_write_f32(struct apple_smc *smc, smc_key key, int value)
227 {
228 u64 val;
229 u32 fval = 0;
230 int exp = 0, neg;
231
232 val = abs(value);
233 neg = val != value;
234
235 if (val) {
236 int msb = __fls(val) - exp;
237
238 if (msb > 23) {
239 val >>= msb - FLT_MANT_BIAS;
240 exp -= msb - FLT_MANT_BIAS;
241 } else if (msb < 23) {
242 val <<= FLT_MANT_BIAS - msb;
243 exp += msb;
244 }
245
> 246 fval = FIELD_PREP(FLT_SIGN_MASK, neg) |
247 FIELD_PREP(FLT_EXP_MASK, exp + FLT_EXP_BIAS) |
248 FIELD_PREP(FLT_MANT_MASK, val);
249 }
250
251 return apple_smc_write_u32(smc, key, fval);
252 }
253
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] rtc: Kconfig: add MC34708 to mc13xxx help text
From: Alexander Kurz @ 2025-10-11 6:26 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel; +Cc: Alexander Kurz
MC34708 is one of the three mfd devices supported by DRV_MC13XXX.
Update Kconfig accordingly.
Signed-off-by: Alexander Kurz <akurz@blala.de>
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 4a8dc8d0a4b7..28f2450d2518 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1739,7 +1739,7 @@ config RTC_DRV_MC13XXX
tristate "Freescale MC13xxx RTC"
help
This enables support for the RTCs found on Freescale's PMICs
- MC13783 and MC13892.
+ MC13783, MC13892 and MC34708.
config RTC_DRV_MPC5121
tristate "Freescale MPC5121 built-in RTC"
--
2.39.5
^ permalink raw reply related
* [GIT PULL] RTC for 6.18
From: Alexandre Belloni @ 2025-10-11 16:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-rtc, linux-kernel
Hello Linus,
Here is the RTC subsystem pull request for 6.18. This cycle, we have a
new RTC driver, for the SpacemiT P1. The optee driver gets alarm
support. We also get a fix for a race condition that was fairly rare
unless while stress testing the alarms.
The following changes since commit 8f5ae30d69d7543eee0d70083daf4de8fe15d585:
Linux 6.17-rc1 (2025-08-10 19:41:16 +0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-6.18
for you to fetch changes up to 9db26d5855d0374d4652487bfb5aacf40821c469:
rtc: interface: Ensure alarm irq is enabled when UIE is enabled (2025-10-09 23:34:52 +0200)
----------------------------------------------------------------
RTC for 6.18
Subsystem:
- Fix race when setting alarm
- Ensure alarm irq is enabled when UIE is enabled
- remove unneeded 'fast_io' parameter in regmap_config
New driver:
- SpacemiT P1 RTC
Drivers:
- efi: Remove wakeup functionality
- optee: add alarms support
- s3c: Drop support for S3C2410
- zynqmp: Restore alarm functionality after kexec transition
----------------------------------------------------------------
Alex Elder (1):
rtc: spacemit: support the SpacemiT P1 RTC
Alexandre Belloni (2):
rtc: optee: make optee_rtc_pm_ops static
rtc: Kconfig: move symbols to proper section
Ard Biesheuvel (1):
rtc: efi: Remove wakeup functionality
Bruno Thomsen (1):
rtc: pcf2127: fix watchdog interrupt mask on pcf2131
Clément Le Goffic (3):
rtc: optee: fix memory leak on driver removal
rtc: optee: remove unnecessary memory operations
rtc: optee: add alarm related rtc ops to optee rtc driver
Dan Carpenter (2):
rtc: optee: fix error code in probe()
rtc: optee: Fix error code in optee_rtc_read_alarm()
Esben Haabendal (5):
rtc: interface: Fix long-standing race when setting alarm
rtc: isl12022: Fix initial enable_irq/disable_irq balance
rtc: cpcap: Fix initial enable_irq/disable_irq balance
rtc: tps6586x: Fix initial enable_irq/disable_irq balance
rtc: interface: Ensure alarm irq is enabled when UIE is enabled
Frank Li (2):
dt-bindings: rtc: pcf85063: remove quartz-load-femtofarads restriction for nxp,pcf85063
dt-bindings: rtc: trivial-rtc: add dallas,m41t00
Harini T (1):
rtc: zynqmp: Restore alarm functionality after kexec transition
Josua Mayer (1):
rtc: pcf2127: clear minute/second interrupt
Krzysztof Kozlowski (3):
rtc: s3c: Drop unused defines
rtc: s3c: Drop support for S3C2410
dt-bindings: rtc: s3c: Drop S3C2410
Rob Herring (Arm) (4):
dt-bindings: rtc: Drop isil,isl12057.txt
dt-bindings: rtc: Fix Xicor X1205 vendor prefix
rtc: x1205: Fix Xicor X1205 vendor prefix
dt-bindings: rtc: Convert apm,xgene-rtc to DT schema
Tóth János (1):
rtc: sd2405al: Add I2C address.
Wolfram Sang (1):
rtc: remove unneeded 'fast_io' parameter in regmap_config
Xianwei Zhao (1):
rtc: amlogic-a4: Optimize global variables
.../devicetree/bindings/rtc/apm,xgene-rtc.yaml | 45 ++
.../devicetree/bindings/rtc/isil,isl12057.txt | 74 ----
.../devicetree/bindings/rtc/nxp,pcf85063.yaml | 10 -
Documentation/devicetree/bindings/rtc/s3c-rtc.yaml | 40 +-
.../devicetree/bindings/rtc/trivial-rtc.yaml | 6 +-
.../devicetree/bindings/rtc/xgene-rtc.txt | 28 --
drivers/rtc/Kconfig | 38 +-
drivers/rtc/Makefile | 1 +
drivers/rtc/interface.c | 27 ++
drivers/rtc/rtc-amlogic-a4.c | 14 +-
drivers/rtc/rtc-cpcap.c | 1 +
drivers/rtc/rtc-efi.c | 76 +---
drivers/rtc/rtc-isl12022.c | 1 +
drivers/rtc/rtc-meson.c | 1 -
drivers/rtc/rtc-optee.c | 465 +++++++++++++++++++--
drivers/rtc/rtc-pcf2127.c | 19 +-
drivers/rtc/rtc-s3c.c | 49 +--
drivers/rtc/rtc-s3c.h | 19 -
drivers/rtc/rtc-sd2405al.c | 4 +-
drivers/rtc/rtc-spacemit-p1.c | 167 ++++++++
drivers/rtc/rtc-tps6586x.c | 1 +
drivers/rtc/rtc-x1205.c | 2 +-
drivers/rtc/rtc-zynqmp.c | 19 +
23 files changed, 753 insertions(+), 354 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/apm,xgene-rtc.yaml
delete mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12057.txt
delete mode 100644 Documentation/devicetree/bindings/rtc/xgene-rtc.txt
create mode 100644 drivers/rtc/rtc-spacemit-p1.c
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 0/5] rtc: Fix problems with missing UIE irqs
From: Alexandre Belloni @ 2025-10-11 16:21 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linux-rtc, linux-kernel, linux-arm-kernel, stable
In-Reply-To: <20250516-rtc-uie-irq-fixes-v2-0-3de8e530a39e@geanix.com>
On Fri, 16 May 2025 09:23:34 +0200, Esben Haabendal wrote:
> This fixes a couple of different problems, that can cause RTC (alarm)
> irqs to be missing when generating UIE interrupts.
>
> The first commit fixes a long-standing problem, which has been
> documented in a comment since 2010. This fixes a race that could cause
> UIE irqs to stop being generated, which was easily reproduced by
> timing the use of RTC_UIE_ON ioctl with the seconds tick in the RTC.
>
> [...]
Applied, thanks!
[1/5] rtc: interface: Fix long-standing race when setting alarm
https://git.kernel.org/abelloni/c/795cda8338ea
[2/5] rtc: isl12022: Fix initial enable_irq/disable_irq balance
https://git.kernel.org/abelloni/c/9ffe06b6ccd7
[3/5] rtc: cpcap: Fix initial enable_irq/disable_irq balance
https://git.kernel.org/abelloni/c/e0762fd26ad6
[4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq balance
https://git.kernel.org/abelloni/c/1502fe0e97be
[5/5] rtc: interface: Ensure alarm irq is enabled when UIE is enabled
https://git.kernel.org/abelloni/c/9db26d5855d0
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [GIT PULL] RTC for 6.18
From: pr-tracker-bot @ 2025-10-11 19:08 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: Linus Torvalds, linux-rtc, linux-kernel
In-Reply-To: <20251011162009a4f6040d@mail.local>
The pull request you sent on Sat, 11 Oct 2025 18:20:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-6.18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/98906f9d850e4882004749eccb8920649dc98456
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: (subset) [PATCH v13 0/7] spacemit: introduce P1 PMIC support
From: Yixun Lan @ 2025-10-14 0:01 UTC (permalink / raw)
To: lee, lgirdwood, broonie, alexandre.belloni, robh, krzk+dt,
conor+dt, Alex Elder
Cc: Yixun Lan, mat.jonczyk, paul.walmsley, palmer, aou, alex,
linux.amoon, troymitchell988, guodong, linux-rtc, devicetree,
linux-riscv, spacemit, linux-kernel
In-Reply-To: <20250825172057.163883-1-elder@riscstar.com>
On Mon, 25 Aug 2025 12:20:49 -0500, Alex Elder wrote:
> The SpacemiT P1 is an I2C-controlled PMIC that implements 6 buck
> converters and 12 LDOs. It contains a load switch, ADC channels,
> GPIOs, a real-time clock, and a watchdog timer.
>
> This series introduces a multifunction driver for the P1 PMIC as
> well as drivers for its regulators and RTC.
>
> [...]
Applied, thanks!
[5/7] riscv: dts: spacemit: enable the i2c8 adapter
https://github.com/spacemit-com/linux/commit/3e8d7309e6260b1d066e733bf3e2e1b6a0d3f82b
[6/7] riscv: dts: spacemit: define fixed regulators
https://github.com/spacemit-com/linux/commit/1df07a40453fd652132051419140950d47941fe9
[7/7] riscv: dts: spacemit: define regulator constraints
https://github.com/spacemit-com/linux/commit/09a412d397484e76588707d85ccc37f71e491091
Best regards,
--
Yixun Lan
^ permalink raw reply
* [PATCH] rtc: rx8025: fix incorrect register reference
From: Yuta Hayama @ 2025-10-15 3:07 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel
Cc: Yuta Hayama, Takao Miyasaka, Naokado OGISO
This code is intended to operate on the CTRL1 register, but ctrl[1] is
actually CTRL2. Correctly, ctrl[0] is CTRL1.
Signed-off-by: Yuta Hayama <hayama@lineo.co.jp>
Fixes: 71af91565052 ("rtc: rx8025: fix 12/24 hour mode detection on RX-8035")
Cc: stable@vger.kernel.org
---
drivers/rtc/rtc-rx8025.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rx8025.c b/drivers/rtc/rtc-rx8025.c
index aabe62c283a1..7e9f7cb90c28 100644
--- a/drivers/rtc/rtc-rx8025.c
+++ b/drivers/rtc/rtc-rx8025.c
@@ -316,7 +316,7 @@ static int rx8025_init_client(struct i2c_client *client)
return hour_reg;
rx8025->is_24 = (hour_reg & RX8035_BIT_HOUR_1224);
} else {
- rx8025->is_24 = (ctrl[1] & RX8025_BIT_CTRL1_1224);
+ rx8025->is_24 = (ctrl[0] & RX8025_BIT_CTRL1_1224);
}
out:
return err;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 06/13] hwmon: Add Apple Silicon SMC hwmon driver
From: Janne Grunau @ 2025-10-16 21:51 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251007-macsmc-subdevs-v3-6-d7d3bfd7ae02@gmail.com>
On Tue, Oct 07, 2025 at 09:16:47PM +1000, James Calligeros wrote:
> The System Management Controller on Apple Silicon devices is responsible
> for integrating and exposing the data reported by the vast array of
> hardware monitoring sensors present on these devices. It is also
> responsible for fan control, and allows users to manually set fan
> speeds if they so desire. Add a hwmon driver to expose current,
> power, temperature, and voltage monitoring sensors, as well as
> fan speed monitoring and control via the SMC on Apple Silicon devices.
>
> The SMC firmware has no consistency between devices, even when they
> share an SoC. The FourCC keys used to access sensors are almost
> random. An M1 Mac mini will have different FourCCs for its CPU core
> temperature sensors to an M1 MacBook Pro, for example. For this
> reason, the valid sensors for a given device are specified in a
> child of the SMC Devicetree node. The driver uses this information
> to determine which sensors to make available at runtime.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Co-developed-by: Janne Grunau <j@jannau.net>
> Signed-off-by: Janne Grunau <j@jannau.net>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> Documentation/hwmon/macsmc-hwmon.rst | 71 +++
> MAINTAINERS | 2 +
> drivers/hwmon/Kconfig | 12 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/macsmc-hwmon.c | 850 +++++++++++++++++++++++++
> 5 files changed, 936 insertions(+)
...
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -148,6 +148,7 @@ obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
> obj-$(CONFIG_SENSORS_LTC4261) += ltc4261.o
> obj-$(CONFIG_SENSORS_LTC4282) += ltc4282.o
> obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
> +obj-$(CONFIG_SENSORS_MACSMC_HWMON) += macsmc-hwmon.o
> obj-$(CONFIG_SENSORS_MAX1111) += max1111.o
> obj-$(CONFIG_SENSORS_MAX127) += max127.o
> obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
> diff --git a/drivers/hwmon/macsmc-hwmon.c b/drivers/hwmon/macsmc-hwmon.c
> new file mode 100644
> index 000000000000..342fe3a5ff62
> --- /dev/null
> +++ b/drivers/hwmon/macsmc-hwmon.c
> @@ -0,0 +1,850 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC hwmon driver for Apple Silicon platforms
> + *
> + * The System Management Controller on Apple Silicon devices is responsible for
> + * measuring data from sensors across the SoC and machine. These include power,
> + * temperature, voltage and current sensors. Some "sensors" actually expose
> + * derived values. An example of this is the key PHPC, which is an estimate
> + * of the heat energy being dissipated by the SoC.
> + *
> + * While each SoC only has one SMC variant, each platform exposes a different
> + * set of sensors. For example, M1 MacBooks expose battery telemetry sensors
> + * which are not present on the M1 Mac mini. For this reason, the available
> + * sensors for a given platform are described in the device tree in a child
> + * node of the SMC device. We must walk this list of available sensors and
> + * populate the required hwmon data structures at runtime.
> + *
> + * Originally based on a concept by Jean-Francois Bortolotti <jeff@borto.fr>
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
missing linux/bitfield.h include as noted by kernel robot
> +#include <linux/hwmon.h>
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
...
> +static int macsmc_hwmon_probe(struct platform_device *pdev)
> +{
> + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent);
> + struct macsmc_hwmon *hwmon;
> + int ret;
> +
> + /*
> + * The MFD driver will try to probe us unconditionally. Some devices
> + * with the SMC do not have hwmon capabilities. Only probe if we have
> + * a hwmon node.
> + */
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon),
> + GFP_KERNEL);
> + if (!hwmon)
> + return -ENOMEM;
> +
> + hwmon->dev = &pdev->dev;
> + hwmon->smc = smc;
> +
> + ret = macsmc_hwmon_populate_sensors(hwmon, hwmon->dev->of_node);
> + if (ret) {
> + dev_err(hwmon->dev, "Could not parse sensors\n");
> + return ret;
> + }
> +
> + if (!hwmon->curr.count && !hwmon->fan.count &&
> + !hwmon->power.count && !hwmon->temp.count &&
> + !hwmon->volt.count) {
> + dev_err(hwmon->dev,
> + "No valid sensors found of any supported type\n");
> + return -ENODEV;
> + }
> +
> + ret = macsmc_hwmon_create_infos(hwmon);
> + if (ret)
> + return ret;
> +
> + hwmon->chip_info.ops = &macsmc_hwmon_ops;
> + hwmon->chip_info.info =
> + (const struct hwmon_channel_info *const *)&hwmon->channel_infos;
> +
> + hwmon->hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
> + "macsmc_hwmon", hwmon,
> + &hwmon->chip_info, NULL);
> + if (IS_ERR(hwmon->hwmon_dev))
> + return dev_err_probe(hwmon->dev, PTR_ERR(hwmon->hwmon_dev),
> + "Probing SMC hwmon device failed\n");
> +
> + dev_info(hwmon->dev, "Registered SMC hwmon device. Sensors:");
> + dev_info(hwmon->dev,
printing non-errors during probe is strongly discouraged. I also do not
see much value in this message outside of development so please change
to dev_dbg().
Janne
^ permalink raw reply
* Re: [PATCH v3 08/13] input: macsmc-input: New driver to handle the Apple Mac SMC buttons/lid
From: Janne Grunau @ 2025-10-16 21:58 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Hector Martin
In-Reply-To: <20251007-macsmc-subdevs-v3-8-d7d3bfd7ae02@gmail.com>
On Tue, Oct 07, 2025 at 09:16:49PM +1000, James Calligeros wrote:
> From: Hector Martin <marcan@marcan.st>
>
> This driver implements power button and lid switch support for Apple Mac
> devices using SMC controllers driven by the macsmc driver.
>
> In addition to basic input support, this also responds to the final
> shutdown warning (when the power button is held down long enough) by
> doing an emergency kernel poweroff. This allows the NVMe controller to
> be cleanly shut down, which prevents data loss for in-cache data.
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Co-developed-by: Sven Peter <sven@kernel.org>
> Signed-off-by: Sven Peter <sven@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/input/misc/Kconfig | 11 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/macsmc-input.c | 208 +++++++++++++++++++++++++
> 4 files changed, 221 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 79b9f40224a9..e8283f127f11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2451,6 +2451,7 @@ F: drivers/hwmon/macsmc-hwmon.c
> F: drivers/pmdomain/apple/
> F: drivers/i2c/busses/i2c-pasemi-core.c
> F: drivers/i2c/busses/i2c-pasemi-platform.c
> +F: drivers/input/misc/macsmc-input.c
> F: drivers/input/touchscreen/apple_z2.c
> F: drivers/iommu/apple-dart.c
> F: drivers/iommu/io-pgtable-dart.c
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 0e6b49fb54bc..5ab8a4729e0a 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -981,4 +981,15 @@ config INPUT_STPMIC1_ONKEY
> To compile this driver as a module, choose M here: the
> module will be called stpmic1_onkey.
>
> +config INPUT_MACSMC_INPUT
INPUT_MACSMC_INPUT looks redundant, is there a reason for not just using
INPUT_MACSMC?
> + tristate "Apple Mac SMC lid/buttons"
> + depends on MFD_MACSMC
> + help
> + Say Y here if you want to use the input events delivered via the
> + SMC controller on Apple Mac machines using the macsmc driver.
> + This includes lid open/close and the power button.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called macsmc-input.
> +
> endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index ae857c24f48e..480a0d08d4ae 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_INPUT_IQS7222) += iqs7222.o
> obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
> obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
> obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
> +obj-$(CONFIG_INPUT_MACSMC_INPUT) += macsmc-input.o
> obj-$(CONFIG_INPUT_MAX7360_ROTARY) += max7360-rotary.o
> obj-$(CONFIG_INPUT_MAX77650_ONKEY) += max77650-onkey.o
> obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
> diff --git a/drivers/input/misc/macsmc-input.c b/drivers/input/misc/macsmc-input.c
> new file mode 100644
> index 000000000000..ebbc7dfc31f5
> --- /dev/null
> +++ b/drivers/input/misc/macsmc-input.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC input event driver
> + * Copyright The Asahi Linux Contributors
> + *
> + * This driver exposes HID events from the SMC as an input device.
s/HID //
> + * This includes the lid open/close and power button notifications.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/reboot.h>
> +
> +/**
> + * struct macsmc_input
> + * @dev: Underlying struct device for the input sub-device
> + * @smc: Pointer to apple_smc struct of the mfd parent
> + * @input: Allocated input_dev; devres managed
> + * @nb: Notifier block used for incoming events from SMC (e.g. button pressed down)
> + * @wakeup_mode: Set to true when system is suspended and power button events should wake it
> + */
> +struct macsmc_input {
> + struct device *dev;
> + struct apple_smc *smc;
> + struct input_dev *input;
> + struct notifier_block nb;
> + bool wakeup_mode;
> +};
> +
> +#define SMC_EV_BTN 0x7201
> +#define SMC_EV_LID 0x7203
> +
> +#define BTN_POWER 0x01 /* power button on e.g. Mac Mini chasis pressed */
> +#define BTN_TOUCHID 0x06 /* combined TouchID / power button on MacBooks pressed */
> +#define BTN_POWER_HELD_SHORT 0xfe /* power button briefly held down */
> +#define BTN_POWER_HELD_LONG 0x00 /* power button held down; sent just before forced poweroff */
> +
> +static void macsmc_input_event_button(struct macsmc_input *smcin, unsigned long event)
> +{
> + u8 button = (event >> 8) & 0xff;
> + u8 state = !!(event & 0xff);
> +
> + switch (button) {
> + case BTN_POWER:
> + case BTN_TOUCHID:
> + if (smcin->wakeup_mode) {
> + if (state)
> + pm_wakeup_event(smcin->dev, 0);
> + } else {
> + input_report_key(smcin->input, KEY_POWER, state);
> + input_sync(smcin->input);
> + }
> + break;
> + case BTN_POWER_HELD_SHORT: /* power button held down; ignore */
> + break;
> + case BTN_POWER_HELD_LONG:
> + /*
> + * If we get here the power button has been held down for a while and
> + * we have about 4 seconds before forced power-off is triggered by SMC.
> + * Try to do an emergency shutdown to make sure the NVMe cache is
> + * flushed. macOS actually does this by panicing (!)...
> + */
> + if (state) {
> + dev_crit(smcin->dev, "Triggering forced shutdown!\n");
> + if (kernel_can_power_off())
> + kernel_power_off();
> + else /* Missing macsmc-reboot driver? */
> + kernel_restart("SMC power button triggered restart");
> + }
> + break;
> + default:
> + dev_warn(smcin->dev, "Unknown SMC button event: %04lx\n", event & 0xffff);
> + }
> +}
> +
> +static void macsmc_input_event_lid(struct macsmc_input *smcin, unsigned long event)
> +{
> + u8 lid_state = !!((event >> 8) & 0xff);
> +
> + if (smcin->wakeup_mode && !lid_state)
> + pm_wakeup_event(smcin->dev, 0);
> +
> + input_report_switch(smcin->input, SW_LID, lid_state);
> + input_sync(smcin->input);
> +}
> +
> +static int macsmc_input_event(struct notifier_block *nb, unsigned long event, void *data)
> +{
> + struct macsmc_input *smcin = container_of(nb, struct macsmc_input, nb);
> + u16 type = event >> 16;
> +
> + switch (type) {
> + case SMC_EV_BTN:
> + macsmc_input_event_button(smcin, event);
> + return NOTIFY_OK;
> + case SMC_EV_LID:
> + macsmc_input_event_lid(smcin, event);
> + return NOTIFY_OK;
> + default:
> + /* SMC event meant for another driver */
> + return NOTIFY_DONE;
> + }
> +}
> +
> +static int macsmc_input_probe(struct platform_device *pdev)
> +{
> + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent);
> + struct macsmc_input *smcin;
> + bool have_lid, have_power;
> + int error;
> +
> + /* Bail early if this SMC neither supports power button nor lid events */
> + have_lid = apple_smc_key_exists(smc, SMC_KEY(MSLD));
> + have_power = apple_smc_key_exists(smc, SMC_KEY(bHLD));
> + if (!have_lid && !have_power)
> + return -ENODEV;
> +
> + smcin = devm_kzalloc(&pdev->dev, sizeof(*smcin), GFP_KERNEL);
> + if (!smcin)
> + return -ENOMEM;
> +
> + smcin->dev = &pdev->dev;
> + smcin->smc = smc;
> + platform_set_drvdata(pdev, smcin);
> +
> + smcin->input = devm_input_allocate_device(&pdev->dev);
> + if (!smcin->input)
> + return -ENOMEM;
> +
> + smcin->input->phys = "macsmc-input (0)";
> + smcin->input->name = "Apple SMC power/lid events";
> +
> + if (have_lid)
> + input_set_capability(smcin->input, EV_SW, SW_LID);
> + if (have_power)
> + input_set_capability(smcin->input, EV_KEY, KEY_POWER);
> +
> + if (have_lid) {
> + u8 val;
> +
> + error = apple_smc_read_u8(smc, SMC_KEY(MSLD), &val);
> + if (error < 0)
> + dev_warn(&pdev->dev, "Failed to read initial lid state\n");
> + else
> + input_report_switch(smcin->input, SW_LID, val);
> + }
> +
> + if (have_power) {
> + u32 val;
> +
> + error = apple_smc_read_u32(smc, SMC_KEY(bHLD), &val);
> + if (error < 0)
> + dev_warn(&pdev->dev, "Failed to read initial power button state\n");
> + else
> + input_report_key(smcin->input, KEY_POWER, val & 1);
> + }
> +
> + error = input_register_device(smcin->input);
> + if (error) {
> + dev_err(&pdev->dev, "Failed to register input device: %d\n", error);
> + return error;
> + }
> +
> + input_sync(smcin->input);
> +
> + smcin->nb.notifier_call = macsmc_input_event;
> + blocking_notifier_chain_register(&smc->event_handlers, &smcin->nb);
> +
> + device_init_wakeup(&pdev->dev, 1);
> +
> + return 0;
> +}
> +
> +static int macsmc_input_pm_prepare(struct device *dev)
> +{
> + struct macsmc_input *smcin = dev_get_drvdata(dev);
> +
> + smcin->wakeup_mode = true;
> + return 0;
> +}
> +
> +static void macsmc_input_pm_complete(struct device *dev)
> +{
> + struct macsmc_input *smcin = dev_get_drvdata(dev);
> +
> + smcin->wakeup_mode = false;
> +}
> +
> +static const struct dev_pm_ops macsmc_input_pm_ops = {
> + .prepare = macsmc_input_pm_prepare,
> + .complete = macsmc_input_pm_complete,
> +};
> +
> +static struct platform_driver macsmc_input_driver = {
> + .driver = {
> + .name = "macsmc-input",
> + .pm = &macsmc_input_pm_ops,
> + },
> + .probe = macsmc_input_probe,
> +};
> +module_platform_driver(macsmc_input_driver);
> +
> +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>");
> +MODULE_LICENSE("Dual MIT/GPL");
> +MODULE_DESCRIPTION("Apple SMC input driver");
mssing 'MODULE_ALIAS("platform:macsmc-input");'. This is required when
using MFD_CELL_NAME(). My ask for it to be removed was based on my
mistaken idea to add a pointless node to the DT and use MFD_CELL_OF().
Janne
^ permalink raw reply
* Re: [PATCH v3 00/13] mfd: macsmc: add rtc, hwmon and hid subdevices
From: Janne Grunau @ 2025-10-16 22:15 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Mark Kettenis, Hector Martin
In-Reply-To: <20251007-macsmc-subdevs-v3-0-d7d3bfd7ae02@gmail.com>
On Tue, Oct 07, 2025 at 09:16:41PM +1000, James Calligeros wrote:
> Hi all,
>
> This series adds support for the remaining SMC subdevices. These are the
> RTC, hwmon, and HID devices. They are being submitted together as the RTC
> and hwmon drivers both require changes to the SMC DT schema.
>
> The RTC driver is responsible for getting and setting the system clock,
> and requires an NVMEM cell. This series replaces Sven's original RTC driver
> submission [1].
>
> The hwmon function is an interesting one. While each Apple Silicon device
> exposes pretty similar sets of sensors, these all seem to be paired to
> different SMC keys in the firmware interface. This is true even when the
> sensors are on the SoC. For example, an M1 MacBook Pro will use different
> keys to access the LITTLE core temperature sensors to an M1 Mac mini. This
> necessitates describing which keys correspond to which sensors for each
> device individually, and populating the hwmon structs at runtime. We do
> this with a node in the device tree. This series includes only the keys
> for sensors which we know to be common to all devices. The SMC is also
> responsible for monitoring and controlling fan speeds on systems with fans,
> which we expose via the hwmon driver.
The split of the hwmon dts changes looks weird to me. It's not a lot of
changes so squashing everything together into a single commit might be
ok. If you want to split the commits splitting them by SoC (t8103,
t8112, t600x, ...) and adding common sensor defines as needed might work
better.
> The SMC also handles the hardware power button and lid switch. Power
> button presses and lid opening/closing are emitted as HID events, so we
> add an input subdevice to handle them.
The cover letter doesn't mention a merge strategy for this series. I
don't think there are any dependencies between different parts. That
means the dt-bindings and driver additions can be merged through their
subsystem trees. The single line patches wiring the devices up to the
macsmc mfd driver should be merged together through mfd tree as they
(trivially) conflict. The dts changes will be merged through the apple
soc tree.
Janne
^ permalink raw reply
* Re: [PATCH] rtc: tegra: Add ACPI support
From: Andy Shevchenko @ 2025-10-15 8:04 UTC (permalink / raw)
To: Kartik Rajput
Cc: alexandre.belloni, thierry.reding, jonathanh, linux-rtc,
linux-tegra, linux-kernel
In-Reply-To: <20250919111232.605405-1-kkartik@nvidia.com>
On Fri, Sep 19, 2025 at 04:42:32PM +0530, Kartik Rajput wrote:
> Add ACPI support for Tegra RTC, which is available on Tegra241 and
> Tegra410. Both Tegra241 and Tegra410 use the same ACPI ID 'NVDA0280'.
> The RTC clock is configured by UEFI before the kernel boots.
...
> +#include <linux/acpi.h>
No use.
...
> +static const struct acpi_device_id tegra_rtc_acpi_match[] = {
> + { "NVDA0280", 0 },
Drop redundant ', 0' part.
> + { }
> +};
...
> + if (is_of_node(dev_fwnode(&pdev->dev))) {
Simple dev_of_node() will work here
> + info->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(info->clk))
> + return PTR_ERR(info->clk);
>
> + ret = clk_prepare_enable(info->clk);
> + if (ret < 0)
> + return ret;
> + }
...
> disable_clk:
> - clk_disable_unprepare(info->clk);
> + if (is_of_node(dev_fwnode(&pdev->dev)))
> + clk_disable_unprepare(info->clk);
Redundant change. CLK APIs are NULL aware.
...
> - clk_disable_unprepare(info->clk);
> + if (is_of_node(dev_fwnode(&pdev->dev)))
> + clk_disable_unprepare(info->clk);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 0/6] Add RTC support for the Renesas RZ/V2H SoC
From: Ovidiu Panait @ 2025-10-19 9:21 UTC (permalink / raw)
To: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, mturquette, sboyd, p.zabel
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
Hi,
This series adds RTC support for the Renesas RZ/V2H SoC.
The Renesas RZ/V2H RTC IP is based on the same RTCA3 IP as RZ/G3S
(r9a08g045), with the following differences:
- it lacks the time capture functionality
- the maximum supported periodic interrupt frequency is 128Hz instead
of 256Hz
- it requires two reset lines instead of one
Best regards,
Ovidiu
Ovidiu Panait (6):
clk: renesas: r9a09g057: Add clock and reset entries for RTC
dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
rtc: renesas-rtca3: Use OF data for configuration
rtc: renesas-rtca3: Add support for RZ/V2H SoC
arm64: dts: renesas: r9a09g057: Add RTC node
arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable RTC
.../bindings/rtc/renesas,rz-rtca3.yaml | 33 ++++++++++++++++---
arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 14 ++++++++
.../dts/renesas/r9a09g057h44-rzv2h-evk.dts | 4 +++
drivers/clk/renesas/r9a09g057-cpg.c | 4 +++
drivers/rtc/rtc-renesas-rtca3.c | 27 +++++++++++++--
5 files changed, 74 insertions(+), 8 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH 1/6] clk: renesas: r9a09g057: Add clock and reset entries for RTC
From: Ovidiu Panait @ 2025-10-19 9:21 UTC (permalink / raw)
To: claudiu.beznea.uj, alexandre.belloni, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, mturquette, sboyd, p.zabel
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20251019092106.5737-1-ovidiu.panait.rb@renesas.com>
Add module clock and reset entries for the RTC module on the Renesas RZ/V2H
(R9A09G057) SoC.
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
---
drivers/clk/renesas/r9a09g057-cpg.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/renesas/r9a09g057-cpg.c b/drivers/clk/renesas/r9a09g057-cpg.c
index c9c117c6782c..100cd56c323e 100644
--- a/drivers/clk/renesas/r9a09g057-cpg.c
+++ b/drivers/clk/renesas/r9a09g057-cpg.c
@@ -241,6 +241,8 @@ static const struct rzv2h_mod_clk r9a09g057_mod_clks[] __initconst = {
BUS_MSTOP(5, BIT(13))),
DEF_MOD("wdt_3_clk_loco", CLK_QEXTAL, 5, 2, 2, 18,
BUS_MSTOP(5, BIT(13))),
+ DEF_MOD("rtc_0_clk_rtc", CLK_PLLCM33_DIV16, 5, 3, 2, 19,
+ BUS_MSTOP(3, BIT(11) | BIT(12))),
DEF_MOD("rspi_0_pclk", CLK_PLLCLN_DIV8, 5, 4, 2, 20,
BUS_MSTOP(11, BIT(0))),
DEF_MOD("rspi_0_pclk_sfr", CLK_PLLCLN_DIV8, 5, 5, 2, 21,
@@ -411,6 +413,8 @@ static const struct rzv2h_reset r9a09g057_resets[] __initconst = {
DEF_RST(7, 6, 3, 7), /* WDT_1_RESET */
DEF_RST(7, 7, 3, 8), /* WDT_2_RESET */
DEF_RST(7, 8, 3, 9), /* WDT_3_RESET */
+ DEF_RST(7, 9, 3, 10), /* RTC_0_RST_RTC */
+ DEF_RST(7, 10, 3, 11), /* RTC_0_RST_RTC_V */
DEF_RST(7, 11, 3, 12), /* RSPI_0_PRESETN */
DEF_RST(7, 12, 3, 13), /* RSPI_0_TRESETN */
DEF_RST(7, 13, 3, 14), /* RSPI_1_PRESETN */
--
2.51.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