Hi Frank, On Friday 21 March 2014 11:55:24 Frank Bormann wrote: > Hi Laurent, > > Thank you again for explaining. One last question if that's okay. > > If I have i2c_board_info being passed in to the probe function through the > platform_data pointer and I also have the same, similar or maybe even > conflicting configuration information in the DTB, is there any of the two > that is supposed to take precedence or should that be an error case? That shouldn't happen (except in very special cases using OF_DEV_AUXDATA, but you really should think twice before going that way). If the I2C device is instantiated in board code with i2c_board_info then there will be no DT node corresponding to the device (client->dev.of_node will be NULL). If the device is instead instantiated from DT there will be no platform data (client- >dev.platform_data will be NULL). > On 20/03/14 01:51 PM, Laurent Pinchart wrote: > > On Thursday 20 March 2014 13:16:35 Frank Bormann wrote: > >> Hi Ben, > >> > >>> 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 was thinking about that. But then again, I'd either have to copy the > >> client->dev.platform_data pointer over to the private data, if it is > >> non-null, or I would have to use some variation of > >> > >> pdata = client->dev.platform_data ? client->dev.platform_data : priv_pd; > >> > >> every time I want to access the configuration. Guess, that's not so bad > >> though. > > > > Most drivers store a pointer to the platform data or a copy of the > > platform data in a per-device driver private structure. They populate that > > pointer or copy from the platform data pointer (in the legacy case) or > > from the device tree content. Outside of the probe function the driver > > thus only accesses its private pointer or copy. -- Regards, Laurent Pinchart -- 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
