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:   Mon, 11 Jul 2022 14:23:59 +0100
From:   Mark Brown <broonie@kernel.org>
To:     Alexandru Elisei <alexandru.elisei@arm.com>
Cc:     lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com,
        heiko@sntech.de, linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
        alsa-devel@alsa-project.org, judyhsiao@chromium.org
Subject: Re: [PATCH] ASoC: rockchip: i2s: Fix NULL pointer dereference when
 pinctrl is not found
Message-ID: <Yswkb6mvwUywOTLg@sirena.org.uk>
References: <20220711130522.401551-1-alexandru.elisei@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="8nxuGyPlmzXFliIn"
Content-Disposition: inline
In-Reply-To: <20220711130522.401551-1-alexandru.elisei@arm.com>
Precedence: bulk


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

On Mon, Jul 11, 2022 at 02:05:22PM +0100, Alexandru Elisei wrote:
> Commit a5450aba737d ("ASoC: rockchip: i2s: switch BCLK to GPIO") switched
> BCLK to GPIO functions when probing the i2s bus interface, but missed
> adding a check for when devm_pinctrl_get() returns an error.  This can le=
ad
> to the following NULL pointer dereference on a rockpro64-v2 if there are =
no
> "pinctrl" properties in the i2s device tree node:
>=20
> [    0.658381] rockchip-i2s ff880000.i2s: failed to find i2s default state
> [    0.658993] rockchip-i2s ff880000.i2s: failed to find i2s gpio state
> [    0.660072] rockchip-i2s ff890000.i2s: failed to find i2s default state
> [    0.660670] rockchip-i2s ff890000.i2s: failed to find i2s gpio state

Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative (it often is
for search engines if nothing else) then it's usually better to pull out
the relevant sections.

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

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmLMJG4ACgkQJNaLcl1U
h9B/nAf+Kvf5A4KB+uPO75jiVyCWYLkssKsw3HPjAgF8EBe+8IPSH4bMdRcdnkQH
/pZO3j8srxvMN1ABFQcuRSwjkxGjKYw6JGKo7W0BjV20qZ8PwLWPIOb9VVEROFiP
ky6OFpD3u5KGXVx95J8syIOrgskyM+CQ+eczZQCezEVti0W/WeysP2nm96HChhQB
9CogIqhh3ta5E7G7aq74o2o9reistKq1WNh94UfjDGGmj62d8RWdCVkLTrHjqY5n
sMAZHBBjIFybtao7r1NtcwUwTsvGcUWqX1u5xFhBx8i3T8aWbC5M9a1wdNGGzAtM
dGv7Ol9LRhreIVWgVe63OzthpynCSg==
=AqBY
-----END PGP SIGNATURE-----

--8nxuGyPlmzXFliIn--