On Tuesday 23 September 2014 22:47:36 Rafael J. Wysocki wrote: > Quite frankly, I'm not sure what you're asking for. > > It seems to mean "I kind of don't like the current implementation", but > then the last part is quite unclear to me. Are you suggesting to add more > "if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) etc" type of checks to > device drivers? That I'd like to avoid to be honest. No, that is not what I want. Device drivers should ideally call interfaces that just take a 'struct device' or 'struct platform_device' pointer, and those should be implemented in an appropriate way. > Instead of the current proposal we can introduce something like > > int device_get_child_property(struct device *dev, void *child_node, > const char *propname, void **valptr); > > (and analogously for device_read_property*) and use that in the drivers that > need to iterate over child nodes of a device. Quite along the lines of what > Dmitry is suggesting. > > Then, fn() in acpi_for_each_child_node() (and the of_ counterpart of it) > would become > > int (*fn)(struct device *dev, void *child_node, void *data) > > and so on. > > Would you prefer that? I must still be missing part of what you are trying to achieve above. We definitely need an interface to get properties from the device itself, like int device_get_property(struct device *dev, const char *propname, void **valptr); (whatever valptr ends up being, that would be a separate discussion). As soon as it comes to devices that have child nodes, I don't see a necessity to have a generic abstraction for them, as this is typically only done for some of the more obscure bindings, or for child nodes that are defined in a subsystem-wide binding rather than a device private binding. For the former case, I think they are indeed better left in drivers that actively know the difference between DT and ACPI, and that don't necessarily use the same binding for both. In the latter case, I'd leave the implementation up to subsystem code, which again would know what interface it is using. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
