On Wed, Feb 07, 2018 at 09:41:22AM -0200, Fabio Estevam wrote: > [Adding Shawn on Cc] Thanks Fabio. > On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > My opinion is that all that is generic about padctrl is a device driver > > saying "Put my pins into a suitable mode". That is what padctrl is good > > for and we are there for years now. I have always been happy with the > > plain register values in the device tree. Before device tree we had > > exactly these values in the board files and I never heard anyone > > complaining about it. There were defines for the bits in the register > > which you could use when you were unhappy with plain register values. > > > > It's really trivial to look in the reference manual to make up the > > needed register values. It's also trivial to take a register value > > and look into the reference manual what this value does. Every > > translation layer, call it generic properties, just makes things more > > complicated. Often enough our input is register value tables > > from either our customers our from spreadsheets from FSL/NXP. Every > > translation layer in the way just means we have to translate the already > > existing register values into something hoping that this correctly > > translates back into the register values. > > > > It's not that some board designer comes up with "I need a drive strength > > of 150mA" and wants to put that value into the device tree. Instead they > > start with the reference manual, see which values they can (must) adjust > > and then adjust the values until they are happy. No one wants to ask > > questions like "How do I have to manipulate that device tree to change > > that particular bit?" > > > > As said, I am happy with plain register values in the device tree and > > I consider everything else overengineered. > > FSL/NXP Reference Manuals are freely available and of high quality so > > everybody can understand the register values. There's nothing magic to > > them. That might change slightly when the Manuals are not available, but > > even then I think that not the device tree ABI is the right place to > > add that missing documentation. > > I agree 100% with Sascha. I would vote for not going generic pinconf either, as the controversy here starts from something, that indicates the generic stuff doesn't work for i.MX. Shawn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
