Messages in this thread | | | Date | Mon, 25 Jun 2018 19:40:24 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH 00/14] ARM: davinci: step towards removing at24_platform_data |
| |
On Mon, Jun 25, 2018 at 05:50:11PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > 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
| |