On Mon, May 09, 2016 at 12:05:56PM +0000, Opensource [Adam Thomson] wrote:
On May 06, 2016, 17:06, Mark Brown wrote:
No, not really - your DT is fairly unusual in how it's done and the lack of ACPI helpers is not a good sign on that side. The _DSD things are really only supposed to work for simple properties on devices.
It's unusual in that there's a child node ("da7219_aad") of the device node, to encapsulate AAD specific information. The properties inside though are data only and simple. Actually, as I read it this is exactly the kind of thing that the 'Hierarchical Data Extension UUID For _DSD' is for.
If it's something that's supposed to be done I'd expect the code to be cleaner and less driver specific.
The intention was to just match against DT or ACPI and nothing else, so that didn't feel generic enough to be pushed into the fwnode framework. However I will take another look.
That's currently the entire set of things that fwnode supports so...
I believe there's the FWNODE_PDATA type as well so 3 things, although I assume that this is to be used longer term instead of the old fashioned platform data mechanism, for built-in properties. Right now though I don't see much actual usage of this.
Well, if you do that you don't need to check if data has been provided at all.