Hi, On Tue, Jul 05, 2016 at 11:58:41PM +0900, Wolfram Sang wrote: > Hi, > > > this is a request for feedback about a lockdep-warning-free I2C > > restart_handler. I would like to know whether someone had the problem already > > and how the best and mainline friendliest solution looks like. > > I have an embedded board with the PMIC chip DA9063 that is also used as a > > voltage regulator for DVFS. For a clean reboot/reset of the system I have to > > set the bit nSHUTDOWN in the PMIC via I2C. The restart_handler call chain > > is of type > > > > static ATOMIC_NOTIFIER_HEAD(restart_handler_list); > > > > So any code running as a restart_handler cannot (should not) wait, for other > > locks. When you use i2c_transfer/regmap you get lockdep warnings like [1]. > > Yes, this problem has come up occasionally. And it is not only about > sleeping. IRQs are disabled, too. > > My idea was to introduce master_xfer_irqless or similar to struct > i2c_algorithm. I even discussed this shortly with Mark Brown how to > interact with regmap; but this was too long ago, so I forgot what we > agreed on :( Great. I was looking for exactly this kind of feedback. The term 'master_xfer_irqless' does not bring up anything on the internet and I didn't find anything on the list linux-i2c. Can you point me to the discussion, so I can read it up and work on it? > > Any comments? > > I just skimmed very lightly over the patchset. Yet, seeing an I2C client > messing directly with 'struct adapter' breaks so many abstractions, it > hits my instant-NACK nerve ;) Yes, accessing the function directly is really ugly. I was thinking about augmenting the I2C interface and the regmap interface with 'sleep-free' and 'irq-less' functions or flags, but this requires changing a lot of code. So I was just taking this shortcut. For follow up patches I will rework this. Mit freundlichen Grüßen / Kind regards, Stefan Christ > Thanks, > > Wolfram > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
