On Mon, Jun 25, 2018 at 05:50:11PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > Since I took over maintainership of the at24 driver I've been working > towards removing at24_platform_data in favor for device properties. > > DaVinci is the only platform that's still using it - all other users > have already been converted. > > One of the obstacles in case of DaVinci is removing the setup() callback > from the pdata struct, the only user of which are some davinci boards. Hi Bartosz Nice code. I've got a platform i want to add sometime soon using the at24. I noticed you doing the cleanup, so i avoided the setup() call. But using it would of helped... My platform is x86 based, so no device tree. I instantiate a number of AT24 devices from a platform driver, and then add nvmem cells so i can access data in these eeproms. This new code will make this simpler. > The only board that's still using this callback is now mityomapl138. > Unfortunately it stores more info in EEPROM than just the MAC address > and will require some more work. Unfortunately I don't have access > to this board so I can't test any actual solutions on a live hardware. Depending on what i find in the EEPROM, i need to instantiate other i2c devices. So i have the problem of knowing when the EEPROM has actually probed and i can use the nvmem API to retrieve the contents. What i have done so far, is registers a bus notifier on i2c_bus_type, and look for BUS_NOTIFY_BOUND_DRIVER. I can then check if the i2c client in the notifier is the at24 client. But when i then add more i2c clients from inside the notifier i get lockdep splats. They are false positives, but it does suggest it is not a good idea to do this. So it would be good to have some sort of recommended alternative to the setup() callback. Ideally it would be specific to a particular at24, and safe to call other i2c functions from. Do you have any ideas? Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
