On 20/03/14 17:12, Frank Bormann wrote:
Hi Laurent, First of all, thank you so much for your detailed explanation. This really helps out a lot. Your assumptions are correct, I am needed working on an ARM device and it uses device tree for driver configuration. Just to confirm that I understand you correctly, what you're saying is that the platform_data and the device tree configuration mechanisms have an exclusive-or relationship, at least when it comes down to an individual driver, is that correct? And, if there is no platform_data provided, it is perfectly permissible for the probe function of the driver to make call to of_* functions to read its configuration? Provided that the kernel has Open Firmware and Device Tree support enabled of course.
Yes, dev->of_node should be set appropriately for devices enumerated from the OF. This can then be used to read anything that the driver core has not already found.
Would it also acceptable for a driver's probe function to allocate memory for a platform_data instance and use the platform_data member in client->dev to store a pointer to it if no previous platform_data is available from the i2c_board_info configuration mechanism? Again provided of course that the memory is freed and the platform_data member in client->dev set back to null in the remove function of the driver.
I think client->dev should be avoided if at-all possible. Many drivers keep their own local copy of platform data or the pointer to it in their driver private information. I tend to prefer not to alloc platform_data for OF if possible as it avoids fragmenting the memory. devm_kzalloc() can also be used to avoid having to remember to free the memory again. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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
