> > 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?
Attachment:
signature.asc
Description: PGP signature
