2018-06-25 19:40 GMT+02:00 Andrew Lunn <andrew@xxxxxxx>: > 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 With my patch 1/14 you'll get -EPROBE_DEFER from nvmem_cell_get() if the nvmem provider is not yet registered. Will that help in your case? Bart -- 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
