Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Tue, 8 Feb 2022 13:56:20 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Charles Keepax <ckeepax@opensource.cirrus.com>
Cc:     Marek Szyprowski <m.szyprowski@samsung.com>,
        Prasad Kumpatla <quic_pkumpatl@quicinc.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        linux-kernel@vger.kernel.org,
        Krzysztof Kozlowski <krzk@kernel.org>,
        'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH v2] regmap-irq: Use regmap_irq_update_bits instead of
 regmap_write
Message-ID: <YgJ2hG2vwUclA/zF@sirena.org.uk>
References: <20220119142953.1804-1-quic_pkumpatl@quicinc.com>
 <CGME20220208122955eucas1p2d4e32f51224242e9ebd0bce58b9c04ca@eucas1p2.samsung.com>
 <39f1b598-58ca-1e3d-3065-8dd692ee7c9f@samsung.com>
 <20220208133957.GC112838@ediswmail.ad.cirrus.com>
 <20220208135036.GD112838@ediswmail.ad.cirrus.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="SM0t/lOK8BmL30Jc"
Content-Disposition: inline
In-Reply-To: <20220208135036.GD112838@ediswmail.ad.cirrus.com>
Precedence: bulk


--SM0t/lOK8BmL30Jc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Feb 08, 2022 at 01:50:36PM +0000, Charles Keepax wrote:

> Apologies for the multiple emails, yeah looking at this I think
> need some more information on how the hardware that patch was
> addressing works. I don't quite understand what was wrong with
> the old code even in the inverted case, the old code wrote a 1 to
> every bit except the interrupt being cleared which gets a 0. This
> feels like how I would have thought a write 0 to clear IRQ would
> work, you don't want to clear any other bits so you write 1 to
> them.

> The update_bits is really problematic as even in the write 0 to
> clear case, if a new interrupt asserts between the regmap_read
> and regmap_write that make up the update_bits, you will clear that
> new interrupt without ever noticing it.

My understanding was that they'd mixed interrupt handling in as a
bitfield in another register.

--SM0t/lOK8BmL30Jc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmICdoMACgkQJNaLcl1U
h9Biowf/We1cO8n8VT5ycGn7rnfrxsvBwTyjNR+FOsglkDblgPUrR/dQM0M4OKhV
kig/tc66n0ZF9GVi9ccsU7gX7k3iDKPaV5LH4kZvzpfApFcg2Qn1EIKWR+CkODId
XmEHkD3aIFcrEaG2v65R4gSOv9twxYSJdaUl9s7ZDmq6nB/RbKewxQsbhbzA9F4n
OyzjhEhegiSyjsNP80Kxh9ZUajYwnyp4Hx4JgJxOuJB4kSICPcbkZOjvbynHd8p6
WG2gNTsB9/W3uBIg3jOdbSI8CDxyA9YYkE+N4392Px0BGRe6xvwaGxR2OJweyuu3
c0mNQqzJJ7T4tQUNIDx1Hf6r8OraRA==
=23Gb
-----END PGP SIGNATURE-----

--SM0t/lOK8BmL30Jc--