[PATCH] rtc: nct3018y: report chassis intrusion through hwmon

[PATCH] rtc: nct3018y: report chassis intrusion through hwmon

[Eric Liu]

Add an hwmon intrusion alarm for the chip's chassis intrusion latch.
Reading it says whether the chassis has been opened since the latch was
last cleared; writing 0 clears it and re-arms.

Signed-off-by: Eric Liu <liuer@nvidia.com>
---
Tested on an NVIDIA Vera Rubin NVL BMC (Aspeed AST2600, kernel 6.18.47)
with an NCT3018Y on i2c5 at 0x6f, opening and closing the chassis by hand.

  # cd /sys/class/hwmon/hwmon0
  # cat name
  nct3018y

lid open:

  # cat intrusion0_alarm
  1

a non-zero write is rejected:

  # echo 1 > intrusion0_alarm
  sh: echo: write error: Invalid argument
  # cat intrusion0_alarm
  1

lid closed -- the latch is held, closing the chassis does not clear it:

  # cat intrusion0_alarm
  1

cleared through the driver:

  # echo 0 > intrusion0_alarm
  # cat intrusion0_alarm
  0

lid opened again, re-armed:

  # cat intrusion0_alarm
  1

Note the latch can only be cleared while the chassis is closed: the flag is
set on "POR or INTRUDER# asserted", so with the lid open the hardware sets
it again immediately after the write.

Build-tested for arm with W=1 and no new warnings, for CONFIG_HWMON=y, =m
and =n.

 drivers/rtc/rtc-nct3018y.c | 94 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/drivers/rtc/rtc-nct3018y.c b/drivers/rtc/rtc-nct3018y.c
index 2f7ad57057a4..194ba077363a 100644
--- a/drivers/rtc/rtc-nct3018y.c
+++ b/drivers/rtc/rtc-nct3018y.c
@@ -4,6 +4,7 @@
 #include <linux/bcd.h>
 #include <linux/clk-provider.h>
 #include <linux/err.h>
+#include <linux/hwmon.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -23,6 +24,7 @@
 #define NCT3018Y_REG_CTRL	0x0A /* timer control */
 #define NCT3018Y_REG_ST		0x0B /* status */
 #define NCT3018Y_REG_CLKO	0x0C /* clock out */
+#define NCT3018Y_REG_INTR_CTRL	0x12 /* intrusion control */
 #define NCT3018Y_REG_PART	0x21 /* part info */
 
 #define NCT3018Y_BIT_AF		BIT(7)
@@ -34,6 +36,7 @@
 #define NCT3018Y_BIT_OFIE	BIT(2)
 #define NCT3018Y_BIT_CIE	BIT(1)
 #define NCT3018Y_BIT_TWO	BIT(0)
+#define NCT3018Y_BIT_INTRUSION	BIT(1) /* in NCT3018Y_REG_INTR_CTRL */
 
 #define NCT3018Y_REG_BAT_MASK		0x07
 #define NCT3018Y_REG_CLKO_F_MASK	0x03 /* frequenc mask */
@@ -491,6 +494,95 @@ static const struct rtc_class_ops nct3018y_rtc_ops = {
 	.ioctl		= nct3018y_ioctl,
 };
 
+#if IS_REACHABLE(CONFIG_HWMON)
+
+static umode_t nct3018y_hwmon_is_visible(const void *data,
+					 enum hwmon_sensor_types type,
+					 u32 attr, int channel)
+{
+	if (type == hwmon_intrusion && attr == hwmon_intrusion_alarm)
+		return 0644;
+
+	return 0;
+}
+
+static int nct3018y_hwmon_read(struct device *dev,
+			       enum hwmon_sensor_types type, u32 attr,
+			       int channel, long *val)
+{
+	struct nct3018y *nct3018y = dev_get_drvdata(dev);
+	int flags;
+
+	flags = i2c_smbus_read_byte_data(nct3018y->client,
+					 NCT3018Y_REG_INTR_CTRL);
+	if (flags < 0)
+		return flags;
+
+	*val = !!(flags & NCT3018Y_BIT_INTRUSION);
+
+	return 0;
+}
+
+static int nct3018y_hwmon_write(struct device *dev,
+				enum hwmon_sensor_types type, u32 attr,
+				int channel, long val)
+{
+	struct nct3018y *nct3018y = dev_get_drvdata(dev);
+	int flags;
+
+	/* The alarm latches until it is cleared, and only clearing is a
+	 * meaningful thing to ask for.
+	 */
+	if (val)
+		return -EINVAL;
+
+	flags = i2c_smbus_read_byte_data(nct3018y->client,
+					 NCT3018Y_REG_INTR_CTRL);
+	if (flags < 0)
+		return flags;
+
+	return i2c_smbus_write_byte_data(nct3018y->client,
+					 NCT3018Y_REG_INTR_CTRL,
+					 flags & ~NCT3018Y_BIT_INTRUSION);
+}
+
+static const struct hwmon_channel_info * const nct3018y_hwmon_info[] = {
+	HWMON_CHANNEL_INFO(intrusion, HWMON_INTRUSION_ALARM),
+	NULL
+};
+
+static const struct hwmon_ops nct3018y_hwmon_ops = {
+	.is_visible = nct3018y_hwmon_is_visible,
+	.read = nct3018y_hwmon_read,
+	.write = nct3018y_hwmon_write,
+};
+
+static const struct hwmon_chip_info nct3018y_hwmon_chip_info = {
+	.ops = &nct3018y_hwmon_ops,
+	.info = nct3018y_hwmon_info,
+};
+
+static void nct3018y_hwmon_register(struct nct3018y *nct3018y)
+{
+	struct device *dev;
+
+	dev = devm_hwmon_device_register_with_info(&nct3018y->client->dev,
+						   "nct3018y", nct3018y,
+						   &nct3018y_hwmon_chip_info,
+						   NULL);
+	if (IS_ERR(dev))
+		dev_warn(&nct3018y->client->dev,
+			 "unable to register hwmon device %ld\n", PTR_ERR(dev));
+}
+
+#else
+
+static void nct3018y_hwmon_register(struct nct3018y *nct3018y)
+{
+}
+
+#endif /* IS_REACHABLE(CONFIG_HWMON) */
+
 static int nct3018y_probe(struct i2c_client *client)
 {
 	struct nct3018y *nct3018y;
@@ -568,6 +660,8 @@ static int nct3018y_probe(struct i2c_client *client)
 	nct3018y_clkout_register_clk(nct3018y);
 #endif
 
+	nct3018y_hwmon_register(nct3018y);
+
 	return devm_rtc_register_device(nct3018y->rtc);
 }
 
-- 
2.34.1

Re: [PATCH] rtc: nct3018y: report chassis intrusion through hwmon

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rtc: nct3018y: hwmon device registration violates layering guidelines
--

commit 12bf4b0b27866f7565ebcc7b10db8faf4943fb10
Author: Eric Liu <liuer@nvidia.com>

rtc: nct3018y: report chassis intrusion through hwmon

This patch adds an hwmon intrusion alarm for the chip's chassis intrusion
latch. Reading it says whether the chassis has been opened since the latch was
last cleared; writing 0 clears it and re-arms.

> diff --git a/drivers/rtc/rtc-nct3018y.c b/drivers/rtc/rtc-nct3018y.c
> index 2f7ad57057a4b..194ba077363aa 100644
> --- a/drivers/rtc/rtc-nct3018y.c
> +++ b/drivers/rtc/rtc-nct3018y.c

[ ... ]

> @@ -491,6 +494,95 @@ static const struct rtc_class_ops nct3018y_rtc_ops = {
>  	.ioctl		= nct3018y_ioctl,
>  };
>  
> +#if IS_REACHABLE(CONFIG_HWMON)

[ ... ]

> +static void nct3018y_hwmon_register(struct nct3018y *nct3018y)
> +{
> +	struct device *dev;
> +
> +	dev = devm_hwmon_device_register_with_info(&nct3018y->client->dev,
> +						   "nct3018y", nct3018y,
> +						   &nct3018y_hwmon_chip_info,
> +						   NULL);
[Severity: Medium]
Does this violate the hardware monitoring subsystem architecture rules?

Registering a hardware monitoring device directly from within
nct3018y_hwmon_register() in drivers/rtc/rtc-nct3018y.c bypasses hwmon
maintainer review and pollutes the RTC driver with secondary hardware
monitoring code.

Could this hwmon functionality be decoupled via an auxiliary device driver
located in the hwmon subsystem directory instead?

> +	if (IS_ERR(dev))
> +		dev_warn(&nct3018y->client->dev,
> +			 "unable to register hwmon device %ld\n", PTR_ERR(dev));
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001054108.3346426-1-liuer@nvidia.com?part=1

Re: [PATCH] rtc: nct3018y: report chassis intrusion through hwmon

[Alexandre Belloni]

On 01/10/2026 05:48:21+0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] rtc: nct3018y: hwmon device registration violates layering guidelines
> --
> 
> commit 12bf4b0b27866f7565ebcc7b10db8faf4943fb10
> Author: Eric Liu <liuer@nvidia.com>
> 
> rtc: nct3018y: report chassis intrusion through hwmon
> 
> This patch adds an hwmon intrusion alarm for the chip's chassis intrusion
> latch. Reading it says whether the chassis has been opened since the latch was
> last cleared; writing 0 clears it and re-arms.
> 
> > diff --git a/drivers/rtc/rtc-nct3018y.c b/drivers/rtc/rtc-nct3018y.c
> > index 2f7ad57057a4b..194ba077363aa 100644
> > --- a/drivers/rtc/rtc-nct3018y.c
> > +++ b/drivers/rtc/rtc-nct3018y.c
> 
> [ ... ]
> 
> > @@ -491,6 +494,95 @@ static const struct rtc_class_ops nct3018y_rtc_ops = {
> >  	.ioctl		= nct3018y_ioctl,
> >  };
> >  
> > +#if IS_REACHABLE(CONFIG_HWMON)
> 
> [ ... ]
> 
> > +static void nct3018y_hwmon_register(struct nct3018y *nct3018y)
> > +{
> > +	struct device *dev;
> > +
> > +	dev = devm_hwmon_device_register_with_info(&nct3018y->client->dev,
> > +						   "nct3018y", nct3018y,
> > +						   &nct3018y_hwmon_chip_info,
> > +						   NULL);
> [Severity: Medium]
> Does this violate the hardware monitoring subsystem architecture rules?
> 
> Registering a hardware monitoring device directly from within
> nct3018y_hwmon_register() in drivers/rtc/rtc-nct3018y.c bypasses hwmon
> maintainer review and pollutes the RTC driver with secondary hardware
> monitoring code.
> 
> Could this hwmon functionality be decoupled via an auxiliary device driver
> located in the hwmon subsystem directory instead?

While this is not an issue to register the hwmon driver from rtc, this
still needs a review from the hwmon maintainers.

> 
> > +	if (IS_ERR(dev))
> > +		dev_warn(&nct3018y->client->dev,
> > +			 "unable to register hwmon device %ld\n", PTR_ERR(dev));
> > +}
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261001054108.3346426-1-liuer@nvidia.com?part=1

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

Re: [PATCH] rtc: nct3018y: report chassis intrusion through hwmon

[Guenter Roeck]

On Thu, Oct 01, 2026 at 09:29:48AM +0200, Alexandre Belloni wrote:
> On 01/10/2026 05:48:21+0000, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] rtc: nct3018y: hwmon device registration violates layering guidelines
> > --
> > 
> > commit 12bf4b0b27866f7565ebcc7b10db8faf4943fb10
> > Author: Eric Liu <liuer@nvidia.com>
> > 
> > rtc: nct3018y: report chassis intrusion through hwmon
> > 
> > This patch adds an hwmon intrusion alarm for the chip's chassis intrusion
> > latch. Reading it says whether the chassis has been opened since the latch was
> > last cleared; writing 0 clears it and re-arms.
> > 
> > > diff --git a/drivers/rtc/rtc-nct3018y.c b/drivers/rtc/rtc-nct3018y.c
> > > index 2f7ad57057a4b..194ba077363aa 100644
> > > --- a/drivers/rtc/rtc-nct3018y.c
> > > +++ b/drivers/rtc/rtc-nct3018y.c
> > 
> > [ ... ]
> > 
> > > @@ -491,6 +494,95 @@ static const struct rtc_class_ops nct3018y_rtc_ops = {
> > >  	.ioctl		= nct3018y_ioctl,
> > >  };
> > >  
> > > +#if IS_REACHABLE(CONFIG_HWMON)
> > 
> > [ ... ]
> > 
> > > +static void nct3018y_hwmon_register(struct nct3018y *nct3018y)
> > > +{
> > > +	struct device *dev;
> > > +
> > > +	dev = devm_hwmon_device_register_with_info(&nct3018y->client->dev,
> > > +						   "nct3018y", nct3018y,
> > > +						   &nct3018y_hwmon_chip_info,
> > > +						   NULL);
> > [Severity: Medium]
> > Does this violate the hardware monitoring subsystem architecture rules?
> > 
> > Registering a hardware monitoring device directly from within
> > nct3018y_hwmon_register() in drivers/rtc/rtc-nct3018y.c bypasses hwmon
> > maintainer review and pollutes the RTC driver with secondary hardware
> > monitoring code.
> > 
> > Could this hwmon functionality be decoupled via an auxiliary device driver
> > located in the hwmon subsystem directory instead?
> 
> While this is not an issue to register the hwmon driver from rtc, this
> still needs a review from the hwmon maintainers.

I don't usually do that, because I have been told several times from people
submitting hwmon drivers outside drivers/hwmon that I am clueless about
hardware monitoring. From my perspective, every hwmon driver outside
drivers/hwmon gets a free ride and is the responsibility of the subsystem
maintainer.

Guenter