From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sat, 25 Jun 2016 21:00:53 -0600 Subject: [U-Boot] [PATCH v2 55/55] dm: Update the of-platdata README for the new features In-Reply-To: <20160623225527.GA19080@bill-the-cat> References: <1465796016-18375-1-git-send-email-sjg@chromium.org> <1465796016-18375-56-git-send-email-sjg@chromium.org> <20160623200419.GZ19080@bill-the-cat> <20160623225527.GA19080@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On 23 June 2016 at 16:55, Tom Rini 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 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 >> >> Suggested-by: Tom Rini >> > [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