Am Donnerstag, den 08.02.2018, 16:56 +0800 schrieb Shawn Guo: > 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@pengutronix.d > > e> 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. So it seems with that we are at a point where the majority vote of users/maintainers are in favor of keeping the binding that has served us well on MX5/6. Which is right where we started with v1 of the MX8 patches. How do we proceed? I would like to send out a respin of those series next week. Can we all agree to roll back the pinctrl binding to the MX5/6 one? Or are there still major reservations against it? I would like to avoid introducing any unnecessary churn. Regards, Lucas -- 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
