mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Cc: "Michal Simek" <michal.simek@amd.com>,
	"Sai Krishna Potthuri" <sai.krishna.potthuri@amd.com>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, amitrkcian2002@gmail.com
Subject: Re: [PATCH 4/6] iio: adc: versal-sysmon: add over-temperature alarm events
Date: Sat, 7 Nov 2026 23:43:23 +0000	[thread overview]
Message-ID: <20261107234323.0aef5ae0@jic23-hlaptop> (raw)
In-Reply-To: <20261102122112.1723130-5-amit.kumar-mahapatra@amd.com>

On Mon, 2 Nov 2026 17:51:10 +0530
Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> wrote:

> The SysMon has two independent temperature comparators. The driver
> exposes only DEVICE_TEMP on interrupt bit 9; the over-temperature alarm
> on bit 8, with its own threshold pair at OT_TEMP_TH_LOWER and
> OT_TEMP_TH_UPPER, is not reported to userspace at all.
> 
> The two are structurally identical: an upper threshold, a lower
> threshold acting as the hysteresis floor, and a hysteresis mode bit in
> ALARM_CONFIG, bit 0 for OT and bit 1 for DEVICE_TEMP. Per AM006 the
> over-temperature shutdown response is a PMC function configured at
> design time, so the kernel's role here is threshold configuration and
> notification rather than acting on the alarm.
> 
> IIO identifies an event by channel, type and direction, and both
> comparators are rising thresholds on the same aggregate temperature, so
> they cannot share a channel. Add an event-only channel labelled "ot"
> carrying the OT thresholds.

So the reason we don't normally do multiple threshold levels is they
have minimal use for an IIO interface - as you've discovered they've
reported the same on the events interface.

If this wasn't an existing driver, the support of this is something that
would strongly push in favour of an hwmon driver where the concept of
warn and critical thresholds exists.  That's there precisely because
the critical is often wired to a pmic or similar.

However, that isn't normally a problem even in an IIO driver
because that threshold should be a design time concern with the
limits coming from firmware.   So why is this even settable by
userspace? Feels like an interface to create the bad type of smoke.

We have a few times discussed how we would perhaps add another
layer of indexing to events, but it is hard given the the compact
event codes and I'm not sure I'm seeing a usecase that justifies
that complexity here.

I also can't work out where your new channel turns up. What does
the userspace ABI look like for this and the existing event controls?

Thanks,

Jonathan


> 
> The channel is appended after the device tree derived channels because
> io-channels phandle arguments are raw array positions, and placing it
> earlier would silently repoint existing consumers. It is created only
> when the device has an interrupt, as without one it would carry no
> events.
> 
> Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
>
W
> @@ -880,6 +932,9 @@ static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev, int ir
>  
>  	num_static = ARRAY_SIZE(temp_channels);
>  	num_chan = size_add(num_temp, size_add(num_static, num_supply));
> +	/* The over-temperature channel exists only when events do */
> +	if (irq > 0)
> +		num_chan = size_add(num_chan, 1);
>  	sysmon_channels = devm_kcalloc(dev, num_chan, sizeof(*sysmon_channels), GFP_KERNEL);
>  	if (!sysmon_channels)
>  		return -ENOMEM;
> @@ -960,6 +1015,25 @@ static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev, int ir
>  		};
>  	}
>  
> +	/*
> +	 * Over-temperature alarm. The OT comparator watches the same
> +	 * aggregate temperature as channel 0 but against its own threshold
> +	 * pair, and IIO cannot express two rising thresholds on one channel.
> +	 * It has no reading of its own, so only event attributes and a label
> +	 * are exposed. Appended last, because io-channels phandle arguments
> +	 * are raw array positions and inserting it earlier would silently
> +	 * repoint every existing consumer.
> +	 */
> +	if (irq > 0)
> +		sysmon_channels[idx++] = (struct iio_chan_spec) {
> +			.type = IIO_TEMP,
> +			.indexed = 1,

indexed without an index? I'm not even sure what this
turns up as. There are already 4 indexed temperature channels
so why isn't this just landing on the index 0 one?

> +			.address = SYSMON_OT_TH_UP,
> +			.event_spec = sysmon_temp_events,
> +			.num_event_specs = ARRAY_SIZE(sysmon_temp_events),
> +			.datasheet_name = "ot",
> +		};
> +


  reply	other threads:[~2026-11-07 23:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 12:21 [PATCH 0/6] iio: adc: versal-sysmon: Add OT alarm, shutdown and thermal zone support Amit Kumar Mahapatra
2026-11-02 12:21 ` [PATCH 1/6] iio: adc: versal-sysmon: fix race in interrupt teardown Amit Kumar Mahapatra
2026-11-03  7:05   ` Prasanna Kumar T S M
2026-11-07 23:27   ` Jonathan Cameron
2026-11-02 12:21 ` [PATCH 2/6] iio: adc: versal-sysmon: validate temperature hysteresis Amit Kumar Mahapatra
2026-11-03 10:08   ` Andy Shevchenko
2026-11-06 11:35     ` Mahapatra, Amit Kumar
2026-11-02 12:21 ` [PATCH 3/6] iio: adc: versal-sysmon: disable interrupts on shutdown Amit Kumar Mahapatra
2026-11-03  7:07   ` Prasanna Kumar T S M
2026-11-03 10:10   ` Andy Shevchenko
2026-11-07 23:30     ` Jonathan Cameron
2026-11-07 23:32   ` Jonathan Cameron
2026-11-02 12:21 ` [PATCH 4/6] iio: adc: versal-sysmon: add over-temperature alarm events Amit Kumar Mahapatra
2026-11-07 23:43   ` Jonathan Cameron [this message]
2026-11-02 12:21 ` [PATCH 5/6] arm64: versal-net: Add SysMon and thermal zone Amit Kumar Mahapatra
2026-11-02 14:53   ` Michal Simek
2026-11-06 11:46     ` Mahapatra, Amit Kumar
2026-11-02 12:21 ` [PATCH 6/6] MAINTAINERS: update Versal SysMon maintainers Amit Kumar Mahapatra
2026-11-02 12:53   ` Michal Simek
2026-11-06 11:46   ` Sai Krishna Potthuri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261107234323.0aef5ae0@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=amit.kumar-mahapatra@amd.com \
    --cc=amitrkcian2002@gmail.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=sai.krishna.potthuri@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®