Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 22 Mar 2022 18:51:35 +0100
From:   Jonathan =?utf-8?Q?Neusch=C3=A4fer?= <j.neuschaefer@gmx.net>
To:     Avi Fishman <avifishman70@gmail.com>
Cc:     Jonathan =?utf-8?Q?Neusch=C3=A4fer?= <j.neuschaefer@gmx.net>,
        Tomer Maimon <tmaimon77@gmail.com>, KWLIU@nuvoton.com,
        Tali Perry <tali.perry1@gmail.com>,
        Linux I2C <linux-i2c@vger.kernel.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Benjamin Fair <benjaminfair@google.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
        OpenBMC Maillist <openbmc@lists.ozlabs.org>,
        JJLIU0@nuvoton.com, Lukas Bulwahn <lukas.bulwahn@gmail.com>,
        Tomer Maimon <tomer.maimon@nuvoton.com>,
        devicetree <devicetree@vger.kernel.org>, bence98@sch.bme.hu,
        Arnd Bergmann <arnd@arndb.de>, sven@svenpeter.dev,
        Rob Herring <robh+dt@kernel.org>,
        Avi Fishman <Avi.Fishman@nuvoton.com>,
        Tyrone Ting <warp5tw@gmail.com>, yangyicong@hisilicon.com,
        semen.protsenko@linaro.org, jie.deng@intel.com,
        Patrick Venture <venture@google.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Wolfram Sang <wsa@kernel.org>, kfting@nuvoton.com,
        Tali Perry <tali.perry@nuvoton.com>, olof@lixom.net
Subject: Re: [PATCH v3 08/11] i2c: npcm: Correct register access width
Message-ID: <YjoMpyEmuXHObF1p@latitude>
References: <20220303083141.8742-1-warp5tw@gmail.com>
 <20220303083141.8742-9-warp5tw@gmail.com>
 <YiCZlhJoXPLpQ6/D@smile.fi.intel.com>
 <CAHb3i=t+Ai3w5mMhmZxxMsD7Zv0xpM4ZicMCmdDMtVn_OMbWYA@mail.gmail.com>
 <YiDNdlEKqorDFkZB@smile.fi.intel.com>
 <YiJ5unrCb82ZMV4Z@latitude>
 <CAKKbWA4quvDbHWBdckAsKe65fDXXe8M-9CsjaP=4wsA=-NnULA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="xEONTgdtFn65elzz"
Content-Disposition: inline
In-Reply-To: <CAKKbWA4quvDbHWBdckAsKe65fDXXe8M-9CsjaP=4wsA=-NnULA@mail.gmail.com>
Precedence: bulk


--xEONTgdtFn65elzz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 22, 2022 at 07:18:34PM +0200, Avi Fishman wrote:
> On Fri, Mar 4, 2022 at 10:42 PM Jonathan Neusch=C3=A4fer
> <j.neuschaefer@gmx.net> wrote:
> >
> > Hello,
> >
> > On Thu, Mar 03, 2022 at 04:15:18PM +0200, Andy Shevchenko wrote:
> > > On Thu, Mar 03, 2022 at 02:54:27PM +0200, Tali Perry wrote:
> > > > > On Thu, Mar 03, 2022 at 04:31:38PM +0800, Tyrone Ting wrote:
> > > > > > From: Tyrone Ting <kfting@nuvoton.com>
> > > > > >
> > > > > > Use ioread8 instead of ioread32 to access the SMBnCTL3 register=
 since
> > > > > > the register is only 8-bit wide.
> > > > >
> > > > > > Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C contro=
ller driver")
> > > > >
> > > > > No, this is bad commit message, since you have bitwise masks and =
there is
> > > > > nothing to fix from functional point of view. So, why is this a f=
ix?
> > > > >
> > > >
> > > > The next gen of this device is a 64 bit cpu.
> > > > The module is and was 8 bit.
> > > >
> > > > The ioread32 that seemed to work smoothly on a 32 bit machine
> > > > was causing a panic on a 64 bit machine.
> > > > since the module is 8 bit we changed to ioread8.
> > > > This is working both for the 32 and 64 CPUs with no issue.
> > >
> > > Then the commit message is completely wrong here.
> >
> > I disagree: The commit message is perhaps incomplete, but not wrong.
> > The SMBnCTL3 register was specified as 8 bits wide in the datasheets of
> > multiple chip generations, as far as I can tell, but the driver wrongly
> > made a 32-bit access, which just happened not to blow up.
> >
> > So, indeed, "since the register is only 8-bit wide" seems to be a
> > correct claim.
> >
> > > And provide necessary (no need to have noisy commit messages)
> > > bits of the oops to show what's going on
> >
> > I guess it's blowing up now because SMBnCTL3 isn't 32-bit aligned
> > (being at offset 0x0e in the controller).
> >
>=20
> Hi Andy,
> After this clarification can you please acknowledge this specific patch?
> If you think there is a better way to describe this, can you propose one?

To be honest, I think it's probably best to include all the necessary
explanations in the next version of this patch, i.e.:

 - That the register was always defined as 8-bit in the datasheets,
   and so the 32-bit access was always incorrect, but simply didn't
   cause a visible error
 - How the 32-bit access caused an error now, perhaps with a trimmed
   Oops log as Andy suggested


Jonathan

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

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

iQIzBAABCgAdFiEEvHAHGBBjQPVy+qvDCDBEmo7zX9sFAmI6DIQACgkQCDBEmo7z
X9s7OQ//X2W94xxyy5YEI/+1O2hIBvmm36jDMTS3z+mAnxmeUKhEBZdn0v8d/euk
JSimNGFJCDze0zmLhJK6yve/1N0Jg0IersKHikjnx06ZU4mgxG5udJKCU2W6MPVj
Zp4IiXgBQ7pTDEMlgEPbT0wSjkmuiiimkjp6QWJZkyKapp3SttzUOiKX/3SeyUtZ
Y1/L3txILtSnYuzlvlL5knG+KJu2Um3/BKCOEzqop+FeQr/16wEvYUWS5Ggg94kK
M9uwBI9cgOhvqS+SOFoNHyPc2VIJ6zsshwz6lB8/NrRQMqrpqyjwZttderEguxNO
MP96a9M7VKpytM+eEbzIZFIxSa/A0zeNqXXXQNB/K+t7Awwdhf32qD4jPRIK0JCK
2pO+hBT5XfRXmRI6f3U7X7lpSpzlR+DMLkq7nEI76rgJfN5qI87ml+WmbzIDXPFf
b04x9eu6AbFeSuz0HW+F/MFwimMiTz+CKVpF7hgZEmJew7OiJT2a1bu6eTPr+4Fv
pOut/60haUWiMulL9QXqbk+0gWWa8k3Mzv6DwQ0wbO/GFHkzlRfBOkMyUUXmNnho
RdBd0cCISHsGLRsRkXEHgCRT67X1sadBrxcB03k91MKNNJoD4mnUr79JpFvIJidC
XL4AOd2HO/z+OFq2y4K14ea8dPl1NgziCcFpC46TAKBrywMDtgg=
=EGzi
-----END PGP SIGNATURE-----

--xEONTgdtFn65elzz--