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:   Sun, 30 Apr 2023 09:05:55 +0200
From:   Wolfram Sang <wsa@kernel.org>
To:     Alexander Stein <alexander.stein@ew.tq-group.com>
Cc:     Marc Kleine-Budde <mkl@pengutronix.de>,
        NXP Linux Team <linux-imx@nxp.com>,
        "A. Sverdlin" <alexander.sverdlin@siemens.com>,
        Dong Aisheng <aisheng.dong@nxp.com>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>, linux-i2c@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] i2c: lpi2c: cache peripheral clock rate
Message-ID: <ZE4TU0rCw9MSwrmB@sai>
Mail-Followup-To: Wolfram Sang <wsa@kernel.org>,
        Alexander Stein <alexander.stein@ew.tq-group.com>,
        Marc Kleine-Budde <mkl@pengutronix.de>,
        NXP Linux Team <linux-imx@nxp.com>,
        "A. Sverdlin" <alexander.sverdlin@siemens.com>,
        Dong Aisheng <aisheng.dong@nxp.com>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>, linux-i2c@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
References: <20230310130815.562418-1-alexander.sverdlin@siemens.com>
 <9272339.EvYhyI6sBW@steina-w>
 <20230421-kinfolk-glancing-e185fd9c47b4-mkl@pengutronix.de>
 <4797405.GXAFRqVoOG@steina-w>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="0V48hNfsy+qdyek6"
Content-Disposition: inline
In-Reply-To: <4797405.GXAFRqVoOG@steina-w>
Precedence: bulk


--0V48hNfsy+qdyek6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


> > IIRC this is a general problem^w limitation of the clock framework,
> > clock providers cannot use clocks themselves in certain callback, e.g.
> > set_rate.
>=20
> Well, that's essentially impossible when this clock provider is attached =
via=20
> i2c. i2c transfers potentially need to change or prepare clocks.

So, as I get it, this is not a specific lpi2c problem but affecting any
I2C controller driver which uses get_rate() to setup a transfer to a
remote I2C clock provider? And this lockdep warning is a false-positive?


--0V48hNfsy+qdyek6
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmROE1MACgkQFA3kzBSg
KbY9IhAAgLo8PSbFxem7+yW32eqHDssVomd/c07FPtFDLUi2XW1n/roLDv0Q1BWa
NXHyl6RkiW8k25kzh2Q9nMLKvF6NnZKn/yynAIZnAKPK2Yly0V6oPAjA5Wlbovr5
q18FajnSElq9MZBXgmQSUrI/YtuFpDTxSYUgv6yWKqYMt4Z4u05qbcncNe/CTPH9
7MsV+PXRozwQbA2AHZWSFRY6vVTFISFtflf8BSP6JI3WOynUquZCeEzbSDQ/1Q7d
Uw0dolCi3oQTS/7z82fZsHHfeZlyg0q+kaBC7NyHtGUhNF0LdrriJtLkzog5AS8H
3QBa8UvborMCh1ytGb6nU+m1SmnUzYTXkKhz+gScGYuV6puq5BJBC3zj8rFQsyqP
Iz7AoDPTsHtWffVsz1CsakqC0ioXxgD2T7SSMMXKugI7Gt99feVx1Ojgu+AT7fCE
Q+Yi+XiXggjvlnTwg6YP0HtC07JN8v4z+4/WeOANcTT3ZausYyxoUmj6YUE3eJXv
M4jVjGecVKfhdblXpplgG7W6zU3pEcJ6FMBWkwT3/vu7dUtAcZFbdIrMmC3HlrvP
PPaGllJEqlgbFCJUU4BDjF7TQ1yY204FRmNIm+nfSOqMcrTkNMF/jo9/j6FGrz4O
YSeQR7br6xCfGO+yxCEetsB1BWvQc6Ebw+xgX4N3uYSekN/HhyM=
=YJB/
-----END PGP SIGNATURE-----

--0V48hNfsy+qdyek6--