Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Thu, 26 Oct 2023 13:18:53 +0200
From:   Wolfram Sang <wsa@kernel.org>
To:     Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc:     Jan Bottorff <janb@os.amperecomputing.com>,
        Serge Semin <fancer.lancer@gmail.com>,
        Yann Sionneau <ysionneau@kalrayinc.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Yann Sionneau <yann@sionneau.net>,
        Will Deacon <will@kernel.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Jan Dabros <jsd@semihalf.com>,
        Andi Shyti <andi.shyti@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] i2c: designware: Fix corrupted memory seen in the ISR
Message-ID: <ZTpLHZZYtd1WgBu6@ninjato>
Mail-Followup-To: Wolfram Sang <wsa@kernel.org>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        Jan Bottorff <janb@os.amperecomputing.com>,
        Serge Semin <fancer.lancer@gmail.com>,
        Yann Sionneau <ysionneau@kalrayinc.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Yann Sionneau <yann@sionneau.net>, Will Deacon <will@kernel.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Jan Dabros <jsd@semihalf.com>, Andi Shyti <andi.shyti@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>, linux-i2c@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <ZQm1UyZ0g7KxRW3a@arm.com>
 <cde7e2fc-2e13-4b82-98b3-3d3a52c4c185@os.amperecomputing.com>
 <p7wl7fk4cdyhvw2mfsa6sfc7dhfls3foplmzwj6pzstargt2oh@33zuuznup2gq>
 <ZQq2cT+/QCenR5gx@shikoro>
 <ba6d4378-b646-4514-3a45-4b6c951fbb9c@kalrayinc.com>
 <9219ad29-b9a3-4f07-81b5-43b4b6d9d178@os.amperecomputing.com>
 <d65lwrkji3rvw6r4jdcumo4zu3hbu6zpv6xq73hw6hcshvhtkw@jvuohb3f3loo>
 <3a305e74-2235-47ab-8564-0c594f24dc0a@os.amperecomputing.com>
 <ZRSEntqne/1y1ozq@shikoro>
 <1d56ceef-6573-43b9-a050-124c341a0698@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="o4CF2TM7pvgzMj7x"
Content-Disposition: inline
In-Reply-To: <1d56ceef-6573-43b9-a050-124c341a0698@linux.intel.com>
Precedence: bulk


--o4CF2TM7pvgzMj7x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 29, 2023 at 11:48:10AM +0300, Jarkko Nikula wrote:
> On 9/27/23 22:38, Wolfram Sang wrote:
> >=20
> > > So my next question, is the change to dw_reg_write something that I s=
hould
> > > write and submit, or should someone else submit something more genera=
lized,
> > > like option 2 above? I don't own the i2c driver, I'm just trying to f=
ix one
> > > issue on one processor with minimal risk of breaking something. I don=
't have
> > > the broader view of what's optimal for the whole DesignWare i2c drive=
r. I
> > > also don't have any way to test changes on other models of processors.
> >=20
> > Well, I guess this is a question for the designware maintainers: do we
> > want this one conversion from *_relaxed to non-relaxed. Or are we
> > playing safe by using non-relaxed all the time. I would suggest the
> > latter because the drivers I look after hardly write registers in a hot
> > path (and not many of them at a time). But you guys know your driver
> > better...
> >=20
> Well I don't have any preference (read enough knowledge) either here and I
> hardly think performance becomes issue in any configuration.

So, someone wants to come up with a patch to move to non-relaxed io
accessors?


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

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

iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmU6Sx0ACgkQFA3kzBSg
KbaEwxAAhYGFsc2Ic1zZ5TXouwBdmMiFzU4cUxRwQCghgpdhWQi56LAU9jW8xzeb
ZaAPq3k+/CARf2WdvlQ/EGIKO4SDNQudnpUWU+smJbLeLiWkRcHJVzGLfzq2q5F+
Mq5v1GNhl10Z2MSX8H+WSByGpAeYDC8/baba/zaR3KjdA/7dE5DNKHETG58aNQ7e
Uy8yaWQbrIx9mW1hGeReTW1cWk+xpOKYrYNJcxi7NkPSZDufbINiJKdKvbsAytKz
L0JBl3mo+bIut8H5SWHGkEbY5LBDAgsOSCnHVzI89pMZgmfT7ep9+mPsLSw0KGwL
XofbaKzYa/qT8JfOn/6dVedntUEHmpmhM1ZpuweGDwH5XSWcTUlt5J3nN46NI5OS
TkiWfhyHTg1Xn+Tr6ENMZRzshvnewzKimjLBQacdHgItnJ36PTuPi+FhoTxZtJ+j
2XJEz4BsPLoNJdwp6ACowQdmjYXgYl5U2bjlBlc+O/TX72tZI2okadIKb9GjcZ5Q
grp7GTB/tPblPsO4y7GdwTTBlQsWO9eHUl+3kaILpSRCuDditRR3BrJnAFCbFkCf
wQvbLWyKa8ArnKizUwEL7zv4jsI5brYkxHGkbC/oOjQXiWsNumOjaHK985taHFk3
T+xcW0ckSVjTV5x4DiL+UyfB71uqHdzpb8QB1fL2lqHgZAWYOuw=
=Kdgb
-----END PGP SIGNATURE-----

--o4CF2TM7pvgzMj7x--