From: Jonathan Cameron <jic23@kernel.org>
To: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Len Brown" <lenb@kernel.org>,
"Linus Walleij" <linusw@kernel.org>,
"Bartosz Golaszewski" <brgl@kernel.org>,
"Sven Peter" <sven@kernel.org>, "Janne Grunau" <j@jannau.net>,
"Neal Gompa" <neal@gompa.dev>,
"Guenter Roeck" <linux@roeck-us.net>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>, "Lee Jones" <lee@kernel.org>,
"Pavel Machek" <pavel@kernel.org>,
"Griffin Kroah-Hartman" <griffin@kroah.com>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Sebastian Reichel" <sre@kernel.org>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Wim Van Sebroeck" <wim@linux-watchdog.org>,
"Jarkko Sakkinen" <jarkko@kernel.org>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Dmitry Kasatkin" <dmitry.kasatkin@gmail.com>,
"Eric Snowberg" <eric.snowberg@oracle.com>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-hwmon@vger.kernel.org, linux-iio@vger.kernel.org,
linux-leds@vger.kernel.org, mfd@lists.linux.dev,
platform-driver-x86@vger.kernel.org, linux-pm@vger.kernel.org,
linux-rtc@vger.kernel.org, linux-watchdog@vger.kernel.org,
linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH 05/14] iio/accel: add driver for apple SMS
Date: Sun, 1 Nov 2026 01:35:40 +0000 [thread overview]
Message-ID: <20261101013540.3af16ea0@jic23-hlaptop> (raw)
In-Reply-To: <20261029085504.3547-6-atharvatiwarilinuxdev@gmail.com>
On Thu, 29 Oct 2026 04:52:02 -0400
Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
> Add a driver for the Sudden Motion Sensor accelerometer,
> exposed through IIO. It reports the three axes and also
> drop, orientation and shock events.
>
> This replaces the motion sensor support in applesmc.
>
> Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
A few specific comments inline.
> diff --git a/drivers/iio/accel/macsmc-accel.c b/drivers/iio/accel/macsmc-accel.c
> new file mode 100644
> index 000000000..0abf81e7b
> --- /dev/null
> +++ b/drivers/iio/accel/macsmc-accel.c
> @@ -0,0 +1,248 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC sudden motion sensor (SMS) driver
> + *
> + * Copyright (C) 2026 Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
> + *
> + * Based on drivers/hwmon/applesmc.c:
> + * Copyright (C) 2007 Nicolas Boichat <nicolas@boichat.ch>
> + * Copyright (C) 2010 Henrik Rydberg <rydberg@euromail.se>
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/byteorder/generic.h>
> +#include <linux/iio/events.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mfd/macsmc.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm.h>
> +
> +struct macsmc_accel {
> + struct apple_smc *smc;
> + struct iio_dev *indio_dev;
> + struct notifier_block nb;
> +};
> +
> +enum {
> + SMS_DROP = 0,
Novel ABI, which means unused ABI given no tools will have
a clue. Look at other drivers and the comments below for how
to do this.
> + SMS_ORIENTATION,
> + SMS_SHOCK,
> +};
> +
> +static int macsmc_accel_read(struct macsmc_accel *drv, smc_key key, s16 *p)
> +{
> + int ret;
> +
> + ret = apple_smc_read_s16(drv->smc, key, p);
> + if (ret < 0)
> + return ret;
> +
> + *p = (s16)be16_to_cpu(*p);
> + return 0;
> +}
> +
> +static int macsmc_accel_dev_init(struct macsmc_accel *drv)
> +{
> + int ret, total;
> + u16 buf;
> +
> + for (total = 0; total < 100; total++) {
> + ret = apple_smc_read_u16(drv->smc, SMC_KEY(MOCN), &buf);
> + if (!ret && buf)
> + return 0;
> +
> + buf = 0xE0;
Some define in this file to give that magic value some meaning (if we
have any info) If not, add comment to say this was from the older
driver (and any info that had on where the magic value came from).
> + apple_smc_write_u16(drv->smc, SMC_KEY(MOCN), buf);
> + msleep(50);
> + }
> +
> + return -ENODEV;
> +}
> +
> +static int macsmc_accel_read_raw(struct iio_dev *indio_dev, struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct macsmc_accel *drv = iio_priv(indio_dev);
> + int ret;
> + s16 buf;
> +
> + if (mask != IIO_CHAN_INFO_RAW)
> + return -EINVAL;
> +
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + ret = macsmc_accel_read(drv, SMC_KEY(MO_X), &buf);
I'd just have the switch set a local variable for SMC_KEY(whatever)
and then unify the actual read after the switch statement.
> + if (ret < 0)
> + return ret;
> +
> + *val = buf;
> + return IIO_VAL_INT;
> + case IIO_MOD_Y:
> + ret = macsmc_accel_read(drv, SMC_KEY(MO_Y), &buf);
> + if (ret < 0)
> + return ret;
> +
> + *val = buf;
> + return IIO_VAL_INT;
> + case IIO_MOD_Z:
> + ret = macsmc_accel_read(drv, SMC_KEY(MO_Z), &buf);
> + if (ret < 0)
> + return ret;
> +
> + *val = buf;
> + return IIO_VAL_INT;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int macsmc_accel_event(struct notifier_block *nb, unsigned long event, void *data)
> +{
> + struct macsmc_accel *drv = container_of(nb, struct macsmc_accel, nb);
> + u64 code;
> +
> + /* check if event is for us */
> + if (event != 0x60 && event != 0x69 && event != 0x6F)
As in previous driver, these should be defines in some header.
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case 0x60:
> + code = IIO_UNMOD_EVENT_CODE(IIO_ACCEL, SMS_DROP,
These need to be more informative to be useful to userspace.
See below for discussion of the channels.
> + IIO_EV_TYPE_CHANGE,
> + IIO_EV_DIR_NONE);
> + break;
> + case 0x69:
> + code = IIO_UNMOD_EVENT_CODE(IIO_ACCEL, SMS_ORIENTATION,
> + IIO_EV_TYPE_CHANGE,
> + IIO_EV_DIR_NONE);
> + break;
> + case 0x6F:
> + code = IIO_UNMOD_EVENT_CODE(IIO_ACCEL, SMS_SHOCK,
> + IIO_EV_TYPE_CHANGE,
> + IIO_EV_DIR_NONE);
> + break;
> + }
> +
> + iio_push_event(drv->indio_dev, code, iio_get_time_ns(drv->indio_dev));
> + return NOTIFY_OK;
> +}
> +
> +static const struct iio_event_spec macsmc_accel_event_spec = {
> + .type = IIO_EV_TYPE_CHANGE,
> + .dir = IIO_EV_DIR_NONE,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> +};
> +
> +static const struct iio_chan_spec macsmc_accel_channels[] = {
> + {
> + .type = IIO_ACCEL,
> + .modified = 1,
> + .channel2 = IIO_MOD_X,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + },
> + {
> + .type = IIO_ACCEL,
> + .modified = 1,
> + .channel2 = IIO_MOD_Y,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + },
> + {
> + .type = IIO_ACCEL,
> + .modified = 1,
> + .channel2 = IIO_MOD_Z,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + },
> + {
> + .type = IIO_ACCEL,
> + .channel = SMS_DROP,
Drop sounds like a typically falling threshold on all axis
event? Lots of drivers support these via the slightly unusual
looking X&Y&Z modifier.
> + .event_spec = &macsmc_accel_event_spec,
> + .num_event_specs = 1,
> + },
> + {
> + .type = IIO_ACCEL,
> + .channel = SMS_ORIENTATION,
This one needs some more info. What is it about the acceleration
values that leads to this event? Do we have any info on that?
> + .event_spec = &macsmc_accel_event_spec,
> + .num_event_specs = 1,
> + },
> + {
> + .type = IIO_ACCEL,
> + .channel = SMS_SHOCK,
That's normally an over threshold on X|Y|Z. See how other
drivers do this.
> + .event_spec = &macsmc_accel_event_spec,
> + .num_event_specs = 1,
> + },
> +};
next prev parent reply other threads:[~2026-11-01 1:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 8:51 [RFC PATCH 00/14] Add macsmc support for Intel Macs, replacing applesmc Atharva Tiwari
2026-10-29 8:51 ` [RFC PATCH 01/14] treewide: Add backend for macsmc Atharva Tiwari
2026-10-29 9:20 ` sashiko-bot
2026-10-29 8:51 ` [RFC PATCH 02/14] platform/x86: add backend for macsmc in intel macs Atharva Tiwari
2026-10-29 9:23 ` sashiko-bot
2026-10-29 12:59 ` Ilpo Järvinen
2026-10-29 8:52 ` [RFC PATCH 03/14] watchdog: add driver for apple smc Atharva Tiwari
2026-10-29 9:17 ` sashiko-bot
2026-10-29 13:30 ` Andy Shevchenko
2026-10-29 8:52 ` [RFC PATCH 04/14] iio/light: add new driver for macsmc Atharva Tiwari
2026-10-29 9:17 ` sashiko-bot
2026-11-01 1:28 ` Jonathan Cameron
2026-10-29 8:52 ` [RFC PATCH 05/14] iio/accel: add driver for apple SMS Atharva Tiwari
2026-10-29 9:20 ` sashiko-bot
2026-11-01 1:35 ` Jonathan Cameron [this message]
2026-10-29 8:52 ` [RFC PATCH 06/14] leds: add support for macsmc kbl Atharva Tiwari
2026-10-29 9:16 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 07/14] rtc: add support for x86 macs in macsmc-rtc Atharva Tiwari
2026-10-29 9:15 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 08/14] treewide: Add a flag to detect the Apple T2 chip Atharva Tiwari
2026-10-29 9:11 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 09/14] treewide: disable other rtc's in t2 macs Atharva Tiwari
2026-10-29 9:16 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 10/14] power/supply: add support for x86 macs in macsmc-power Atharva Tiwari
2026-10-29 9:19 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 11/14] acpi: disable battery and adapter for x86 apple machines Atharva Tiwari
2026-10-29 9:13 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 12/14] hwmon/macsmc: add more types Atharva Tiwari
2026-10-29 9:18 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 13/14] hwmon: add support for x86 macs in macsmc-hwmon Atharva Tiwari
2026-10-29 9:20 ` sashiko-bot
2026-10-29 8:52 ` [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys Atharva Tiwari
2026-10-29 9:26 ` sashiko-bot
2026-11-01 1:38 ` Jonathan Cameron
2026-11-01 1:07 ` [RFC PATCH 00/14] Add macsmc support for Intel Macs, replacing applesmc Jonathan Cameron
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=20261101013540.3af16ea0@jic23-hlaptop \
--to=jic23@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=andy@kernel.org \
--cc=asahi@lists.linux.dev \
--cc=atharvatiwarilinuxdev@gmail.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=brgl@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=dlechner@baylibre.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=griffin@kroah.com \
--cc=hansg@kernel.org \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=j@jannau.net \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=lee@kernel.org \
--cc=lenb@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mfd@lists.linux.dev \
--cc=mingo@redhat.com \
--cc=neal@gompa.dev \
--cc=nuno.sa@analog.com \
--cc=paul@paul-moore.com \
--cc=pavel@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=sre@kernel.org \
--cc=sven@kernel.org \
--cc=tglx@kernel.org \
--cc=wim@linux-watchdog.org \
--cc=x86@kernel.org \
--cc=zohar@linux.ibm.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