All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Esben Haabendal" <esben@geanix.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v4 5/6] iio: accel: mma8452: Allow open drain interrupt pin configuration
Date: Wed, 12 Aug 2026 15:46:01 +0000	[thread overview]
Message-ID: <20260812154601.CB4971F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812-mma8452-open-drain-v4-5-bfca15d02b59@geanix.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] The PM runtime resume handler fails to restore most device configuration registers after a power cycle, reverting to POR defaults.
- [High] The driver ignores the requested interrupt polarity from irq_get_trigger_type() and fails to configure the hardware's WAKE_INT_POL bit.
- [High] Sysfs read/write handlers modify device registers and poll STATUS without acquiring a PM runtime reference.
--

--- Patch [5]: [PATCH v4 5/6] iio: accel: mma8452: Allow open drain interrupt pin configuration ---
commit 7603b79afdeeb3c4d36936afa7e16bc8d738683c
Author: Esben Haabendal <esben@geanix.com>

    iio: accel: mma8452: Allow open drain interrupt pin configuration
    
    When designing systems sharing the interrupt for mma8452 chips, it is
    helpful to be able to configure the irq pin in open-drain mode (default is
    push-pull).
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
    Signed-off-by: Esben Haabendal <esben@geanix.com>

> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 106cdd904dbfd..7992f9e388180 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
[ ... ]
> @@ -647,6 +650,22 @@ static int mma8452_set_power_mode(struct mma8452_data *data, u8 mode)
>  	return mma8452_change_config(data, MMA8452_CTRL_REG2, reg);
>  }
>  
> +static int mma8452_set_interrupt_pin_mode(struct mma8452_data *data)
> +{
> +	int reg;
> +
> +	reg = i2c_smbus_read_byte_data(data->client, MMA8452_CTRL_REG3);
> +	if (reg < 0)
> +		return reg;
> +
> +	if (data->open_drain)
> +		reg |= MMA8452_CTRL_REG3_PP_OD;
> +	else
> +		reg &= ~MMA8452_CTRL_REG3_PP_OD;

[Severity: High]
This is a pre-existing issue, but could this function also configure the
interrupt polarity bit to match the requested irq polarity?

If a board's device tree specifies an active-high interrupt, the driver
requests the irq with that flag but leaves the chip generating active-low
signals.

Since this function modifies the open-drain setting in MMA8452_CTRL_REG3,
might it also ensure the polarity bit is set correctly so we don't end up
with missing interrupts or continuous interrupt storms?

> +
> +	return i2c_smbus_write_byte_data(data->client, MMA8452_CTRL_REG3, reg);
> +}
> +
[ ... ]
> @@ -1817,6 +1841,10 @@ static int mma8452_runtime_resume(struct device *dev)
>  		return ret;
>  	}
>  
> +	ret = mma8452_set_interrupt_pin_mode(data);
> +	if (ret)
> +		goto runtime_resume_failed;
> +
>  	ret = mma8452_active(data);

[Severity: High]
This is a pre-existing issue, but does mma8452_runtime_resume() fully restore
the device state after a power cycle?

When the device goes to runtime suspend after a period of inactivity,
mma8452_runtime_suspend() disables the vdd and vddio regulators, causing the
hardware to lose all its register state.

When it wakes up, only MMA8452_CTRL_REG1 and MMA8452_CTRL_REG3 are restored
here. Does this leave crucial configurations like MMA8452_DATA_CFG,
MMA8452_CTRL_REG4, and MMA8452_CTRL_REG5 uninitialized and revert to power-on
defaults?

Could this cause the device to operate with incorrect full-scale settings and
disabled interrupts?

>  	if (ret < 0)
>  		goto runtime_resume_failed;


[Severity: High]
This is a pre-existing issue, but do the sysfs read/write handlers modify
device registers and poll the status without acquiring a pm runtime reference?

For example, looking at mma8452_read() in drivers/iio/accel/mma8452.c:

mma8452_read() {
    ...
    int ret = mma8452_drdy(data);

    if (ret < 0)
        return ret;

    ret = mma8452_set_runtime_pm_state(data->client, true);
    ...
}

The driver polls the status register before waking up the device.
Since the device enters autosuspend and turns off its regulators, will any
subsequent sysfs read or write attempt to access an unpowered chip?

Could this result in bus errors and completely break the sysfs interface?

Also, __mma8452_write_raw() calls into mma8452_change_config() which reads
from the device without holding a pm runtime reference.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-mma8452-open-drain-v4-0-bfca15d02b59@geanix.com?part=5

  reply	other threads:[~2026-08-12 15:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 14:30 [PATCH v4 0/6] io: accel: mma8452: Allow open drain interrupt pin configuration Esben Haabendal
2026-08-12 14:30 ` [PATCH v4 1/6] dt-bindings: iio: accel: mma8452: Add drive-open-drain Esben Haabendal
2026-08-12 15:00   ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 2/6] iio: accel: mma8452: Optimize struct mm8452_data member orders Esben Haabendal
2026-08-12 15:12   ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 3/6] iio: accel: mma8452: Only apply trigger type when not set by firmware Esben Haabendal
2026-08-12 15:23   ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 4/6] iio: accel: mma8452: Support interrupt sharing Esben Haabendal
2026-08-12 15:34   ` sashiko-bot
2026-08-12 14:30 ` [PATCH v4 5/6] iio: accel: mma8452: Allow open drain interrupt pin configuration Esben Haabendal
2026-08-12 15:46   ` sashiko-bot [this message]
2026-08-12 14:30 ` [PATCH v4 6/6] iio: accel: mma8452: Reuse existing dev pointer in mma8452_probe() Esben Haabendal
2026-08-12 15:56   ` sashiko-bot

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=20260812154601.CB4971F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=esben@geanix.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.