[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yg0tUlQ/Qs8AHa4O@sirena.org.uk>
Date: Wed, 16 Feb 2022 16:58:58 +0000
From: Mark Brown <broonie@...nel.org>
To: Prasad Kumpatla <quic_pkumpatl@...cinc.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
linux-kernel@...r.kernel.org,
Charles Keepax <ckeepax@...nsource.cirrus.com>,
"Srinivas Kandagatla . [
B. [ B. [
B" <srinivas.kandagatla@...aro.org>
Subject: Re: [PATCH] regmap-irq: Update interrupt clear register for proper
reset
On Wed, Feb 16, 2022 at 03:30:26PM +0530, Prasad Kumpatla wrote:
> With the existing logic where clear_ack is true, interrupt clear register
> reset is not handled properly. Due to this only the first interrupts get
> processed properly and further interrupts are blocked due to interrupt
> clear register is not reset. So writing 0x00 and 0xff(when ack_invert is
> true) should have no effect, other than clearing the ACKs just set.
This commit log still has the problem that it's not clearly describing
the problem and I've forgotten again - in what way is the interrupt
clear reset not handled properly? What should happen and what does
happen?
> if (d->chip->ack_invert && !ret)
> - ret = regmap_write(map, reg,
> - d->mask_buf[i]);
> + ret = regmap_write(map, reg, 0xff);
Why only 0xff and not UINT_MAX?
> else if (!ret)
> - ret = regmap_write(map, reg,
> - ~d->mask_buf[i]);
> + ret = regmap_write(map, reg, 0x00);
Please write 0 normally, no need for 00.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists