On 08/31/2017 04:39 AM, Thomas Petazzoni wrote:
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
