Re: [RFC PATCH v2 07/16] gpio: Add support for unified device properties interface

[Arnd Bergmann]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/