On 02.05.2023 08:50:06, Alexander Stein wrote: > Hello Wolfgang, > > Am Sonntag, 30. April 2023, 09:05:55 CEST schrieb Wolfram Sang: > > * PGP Signed by an unknown key > > > > > > 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. > > > > > > Well, that's essentially impossible when this clock provider is attached > > > via 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? > > Yes, IMHO this could potentially occur on every I2C controller driver, if a > clock provider while holding the clk_prepare_lock, e.g. during registration, > issues an i2c transfer. > I'm not so sure if this is a false-positive, but more like trying to do a > nested lock. It's a general limitation of the clock framework. The clk_prepare_lock() is taken by clk_prepare() and by clk_get_rate(). So if you implement a clock provider driver that uses I2C, which might use clk_get_rate() it might deadlock. However there's a workaround for nested I2C calls: 533ddeb1e86f "(clk: allow reentrant calls into the clk framework, 2013-03-28)". This doesn't work for SPI, as it's using a worker thread. | https://elixir.bootlin.com/linux/v6.3/source/drivers/clk/clk.c#L128 regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Attachment:
signature.asc
Description: PGP signature
