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:   Wed, 16 Nov 2022 15:05:30 +0100
From:   Thierry Reding <thierry.reding@gmail.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Marijn Suijten <marijn.suijten@somainline.org>,
        Brian Masney <bmasney@redhat.com>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Linus Walleij <linus.walleij@linaro.org>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Konrad Dybcio <konrad.dybcio@linaro.org>
Subject: Re: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips
Message-ID: <Y3TuKhW9YjOTzcfg@orome>
References: <20221111113732.461881-1-thierry.reding@gmail.com>
 <Y3Kv7XoBytwwy9pC@x1>
 <20221115111800.t6i6fuszhuasvgka@SoMainline.org>
 <Y3S62i7OzocP5QrT@orome>
 <Y3S9oEw6qfLVgGhR@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="8YUqZNNhJPdRaHFQ"
Content-Disposition: inline
In-Reply-To: <Y3S9oEw6qfLVgGhR@smile.fi.intel.com>
User-Agent: Mutt/2.2.8 (2022-11-05)
Precedence: bulk


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

On Wed, Nov 16, 2022 at 12:38:24PM +0200, Andy Shevchenko wrote:
> On Wed, Nov 16, 2022 at 11:26:34AM +0100, Thierry Reding wrote:
> > On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote:
> > > On 2022-11-14 16:15:25, Brian Masney wrote:
> > > > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote:
> > > > > From: Thierry Reding <treding@nvidia.com>
> > > > >=20
> > > > > The OF node store in chip->fwnode is used to explicitly override =
the FW
> > > > > node for a GPIO chip. For chips that use the default FW node (i.e=
=2E that
> > > > > of their parent device), this will be NULL and cause the chip not=
 to be
> > > > > fully registered.
> > > > >=20
> > > > > Instead, use the GPIO device's FW node, which is set to either th=
e node
> > > > > of the parent device or the explicit override in chip->fwnode.
> > > > >=20
> > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of=
_gpiochip_remove() for fwnode")
> > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > >=20
> > > > Reviewed-by: Brian Masney <bmasney@redhat.com>
> > > > Tested-by: Brian Masney <bmasney@redhat.com>
> > > >=20
> > > > I separately sent a similar type of patch to fix the same issue tod=
ay:
> > > > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmas=
ney@redhat.com/T/#u
> > >=20
> > > For completeness, your linked patch fixes a synchronous external abort
> > > on multiple Qualcomm platforms pointed out in [1].  This patch however
> > > does not, are you sure they fix the exact same issue?
>=20
> Yes, they fix the same issue.
>=20
> > > [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmb=
xm3jb@SoMainline.org/
> >=20
> > Can you check if the below fixes the MSM issue that you're seeing
> > (applied on top of my earlier patch, though with Brian's reverted
> > temporarily)?
>=20
> I don't know why we would need this. Brian's patch (already applied into
> GPIO tree) is correct, no? (Moreover, it makes yours unneeded, but I'm fi=
ne
> with having it anyway.)

I've explained this in the reply to Brian's patch, but I don't think we
want to use gc->fwnode other than initially to override the fwnode that
the GPIO chip uses. It might even be worth turning it into a parameter
to gpiochip_add() to avoid the ambiguity we have right now where we
store the same fwnode in two different places and end up using either
depending on whoever wrote the patch and what mood they were in. There
really should only be one place to store this pointer to avoid this sort
of ambiguity.

Thierry

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

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

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmN07ioACgkQ3SOs138+
s6GcARAAwVSaB6cgAFmgZVVRCE4RrjHNgm0XrWw1TWomrfOvqBcIprj702QqcOfq
DMkgLdW9LPzt/nxItelQ9sn8tfrajma7x+kfTAcXMtTIkZgAKIcP7MLk++ymwL30
RzfsjbFUhCaqSb75m4fktdi6Jdj8G80R4VEmmiEk0nnWu9CeOquC+5MTf+BL3PNy
jCx6ndMyRjuLU7JRVFqkfXJt+LsjDh/+tMIaomfiYnoMRimKxQSmf318avHZXA9/
H8DvEyh+dlGwyexUHBD6GI4N4COFdLamOrjXXjqr/t0lSZ28GrCbhm9ZmhVXjR1j
NkNRElKf0VF41y0/oVoqgt+Aq2AirL2yh0jCQIS7Qou1snvqXDw8aW6AxGSSWpgL
+Oj8k9xqd/OEWchd0J7dQED0Iokv1q+RosY5bGLuAkeAzkKzk7cKqndiNGHl0A+p
IbLX7g8cvI6duFoMh8oSAOWT8ATrCTzzMbHt5GodGITKTWO41VlfUrI3znx/RDNQ
1j8jVLkpgQd1sS//Dj/wgHEWcFKqcvg5Z18dtTSy+EhlHG5UNFQMyHKohXQ+Tnp0
eCDJ18okOfytJbc0N+co2CI91bsAfBIYIMlQtoLfsVFlj4fiT64ZEJE82BVClbHa
IuI4TgbdV/1Y2YIo6RwcaK0Zud4SYVjhxt32aLTbX63OAMYXaLU=
=PJfZ
-----END PGP SIGNATURE-----

--8YUqZNNhJPdRaHFQ--