On Wed, Nov 08, 2017 at 05:25:20PM -0600, Andrew F. Davis wrote: > On 11/08/2017 04:18 PM, Mark Brown wrote: > > There is code in the driver to use the GPIO, including in the probe > > where the GPIO is requested and set to high (which will bring it out of > > reset if the default state was low). At least the probe seems rather > > likely to have a concrete effect. > None of the 4 boards that defined this gpio have this pulled low in the > pin control, boards should have an external pull-up on the reset line. None of the boards in mainline... > At any-rate, I'm pushing this fix to allow the driver to use new kernel > frameworks that depend on the correct binding being used. This is not a > case of a badly designed binding or trying to add incompatible > functionality, it is a typo fix. If we have to keep this driver back > using old frameworks and needlessly bloat the code solely for the sake > of compatibility with a typo, then DT "stability" here is causing more > issues than it solves. </rant> This isn't a typographical error, that'd be a spelling mistake or something. > I guess the alternative would be to have of_find_gpio() also consider > prefixing, the 'gpio_suffixes' to 'con_id' and checking for those. That > is rather ugly and probably encourages the spread of this bad binding > property, but whatever the best fix is it cannot be to force bloat into > the driver. Another option is to add an interface for telling the DT code about renaming properties then the core code can do the fallback transparently to the upper layers (when asked for X if it's not there then try the legacy name Y).
Attachment:
signature.asc
Description: PGP signature
