Hi Karl, On Thu, 24 Jun 2010 12:19:07 +0200, Karl Hiramoto wrote: > My goal is to assign a MAC address stored in a I2C EEPROM to a ethernet > device on an ARM SOC so I can boot via NFS. Reading and writing this > address works with the at24 driver after its loaded. > > Currently the i2c __init call is after the ethernet devices __init, so this > makes using the I2C drivers not possible, as nothing is instantiated. > > So to me it looks like i have two options. > > 1. Reorder the init calls. I'd prefer not doing this for fear of breaking > something else. > > 2. The I2C bus on my board is just using GPIO pins. I could bit bang > these pins before the i2c drivers are loaded, in the arch initcalls. Are > there any functions in the kernel to do this easily? Like optimally some > libary function in the kernel to do something like: > > i2c_gpio_read(int sda_pin, int scl_pin, int i2c_address, int len, void *data) > > This library function may need to have to have a spinlock or mutex to avoid > conflicts on these pins.
I don't think anything like this exists, and I sincerely hope it will never exist. It would inevitably duplicate code that already exists, and add confusion all around, and bugs. > Is there a better solution? If parts of i2c need to be initialized earlier, then let's just do this. That being said, i2c core initialization happens at postcore_initcall() level since kernel 2.6.28, and many i2c bus drivers for embedded platforms use subsys_initcall(). i2c-gpio has just need changed to do exactly this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b8680784875b26a2876df5959673a496d56af673 Isn't it enough to solve your problem? -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
