On 10/10/2012 04:51 PM, Laurent Pinchart wrote: > On Wednesday 10 October 2012 10:50:20 Stephen Warren wrote: >> On 10/10/2012 07:18 AM, Laurent Pinchart wrote: >>> On Monday 08 October 2012 17:15:53 Guennadi Liakhovetski wrote: >> ... >> >>>> But how do you get the subdev pointer? With the notifier I get it from >>>> i2c_get_clientdata(client) and what do you do without it? How do you get >>>> to the client? >>>> >>>>> And can't it get that from DT as well? >>>> >>>> No, I don't think there is a way to get a device pointer from a DT node. >> >> I don't believe there's a generic API for this (although perhaps there >> could be), but it can be implemented quite easily. >> >> For example, on Tegra, the SMMU needs to flip a bit in the AHB register >> space in order to enable itself. The SMMU DT node contains a phandle >> that points at the AHB DT node. The SMMU driver parses the phandle and >> passes the DT node pointer to the AHB driver. The AHB driver looks up >> the struct device that was instantiated for that node. See >> drivers/amba/tegra-ahb.c:tegra_ahb_enable_smmu(). There are a few other >> cases of similar code in the kernel, although I can't remember the others! > > That's a very naive approach, but what about storing the struct device in > struct device_node when the device is instantiated ? It's so simple that > there's probably a good reason why that hasn't been implemented though. It sounds like that would work. The advantage of calling a function in the driver for the node, rather than just grabbing something from the node directly in code unrelated to the driver for the node, is that it any knowledge of what kind of device/driver is handling that node is embedded into a function in the driver for the node, not the driver using the node, which makes everything a bit more type-safe. Now, perhaps the implementation of that function could just pull a field out of struct of_node rather than calling driver_find_device(), but it'd then have to validate that the struct device that was found was truly managed by the expected driver, for safety. I assume that's pretty simple, but haven't checked. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
