Hi Tom,
On 23 June 2016 at 16:55, Tom Rini trini@konsulko.com wrote:
On Thu, Jun 23, 2016 at 02:36:55PM -0600, Simon Glass wrote:
Hi Tom,
On 23 June 2016 at 14:04, Tom Rini trini@konsulko.com wrote:
On Sun, Jun 12, 2016 at 11:33:36PM -0600, Simon Glass wrote:
Revise the content based on the v2 additions. This is kept as a separate patch to avoid confusing those who have already reviewed the v1 series.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Tom Rini trini@konsulko.com
[snip]
+Converting of-platdata to a useful form +---------------------------------------
+Of course it would be possible use the of-platdata directly in your driver +whenever configuration information is required. However this meands that the
"means"
[snip]
+The of-platdata struct contents is copied from the C structure data to the
"is copied" -> "are copied"
And thanks again for doing all of this!
Obviously I still have a test to write, but other than that, what do you think of this feature?
Well, I like it. But I'm also not great at spotting problems before we run into them sometimes.
We need to find someone with a crystal ball...
I put quite a bit of info in the caveats. The benefit is clear but it is also a bit wonky - e.g. the structure / member naming. I'm really a little bit nervous about it all. Do you think we can make sure it is used sparingly?
Given the number of places (it feels like) that run in to, or nearly run in to size limits today in SPL with tiny-printf enabled, no, I can't say that I think this will be used sparingly. So is there anything we can do about the structure / member naming to make it less wonky? Or just wait and see how things work out in the end when people start using it more?
The only option I think is to allow people to provide a config file to map the compatible strings and property names to better names. To me that did not seem worth it, since it is a pain to add this file. It would need as much maintenance as changes to the device-tree binding.
My main concern is that people will use it to make SPL small when they can actually afford the ~4-6KB size increase. But I agree we need to be as efficient as possible and this helps bridge the gap with device tree.
I'll do another spin in a week or two and we'll see how it looks. Let me know if you have any comments.
Regards, Simon