On 08/31/2017 04:39 AM, Thomas Petazzoni wrote:

quoted

IMHO, the pinmux settings should always be specified in DT, and that's
what we should be using everywhere, not doing broken backdoor games like
"the gpio is being requested, it's obvious that we want this pin to be
a gpio" - that really doesn't follow.

Agreed.

How many drivers need to be "fixed" if this is the plan?  I don't think 
we can make a blanket change to all drivers whose ->request functions 
touch the muxes without testing on all those platforms.  And it's not 
just the muxes.  The whole point behind my patch was to avoid 
gpiochip_add_data() touching the hardware without claiming the GPIO first.

The overall goal of my patch was to allow "sparse" GPIO maps.  The 
problem with gpiochip_add_data() is that it touches all GPIOs even 
before I call gpiochip_add_pin_range().

Maybe the for-loop that it's in gpiochip_add_data() should be moved to 
gpiochip_add_pin_range(), so that we only query the direction of a pin 
after it's been added, not before?

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.