On 10/03/2017 05:03 PM, Stephen Boyd wrote:
I've run into this now on our mobile SoCs after I pull in commit
8e51533780ba ("pinctrl: qcom: add get_direction function").
Before that commit we never read each pin of the device. On our
mobile SoCs we have devicetree and it feels like having that
describe which pins are available and not available is
half-duplicating information we would already have via consumers
indicating which pins they care about. I don't see any value
beyond system wide debug in figuring out the default pin
configuration of a pin that doesn't have a consumer in Linux.
At the time I wrote that patch, the ACPI tables exposed all of the
GPIOs, even the ones it didn't care about. The new ACPI tables list
only specific GPIOs, and so we no longer need to blindly read the
direction of all GPIOs.
Could we remove the pin direction finding part here in
gpiochip_add_pin_range() and lazily resolve the pin direction
when a pin is requested?
That makes a lot more sense.
We would need a similar check in the msm
specific debugfs code where we skip pins that aren't requested.
I have that in patch #1.
This is basically a revert of commit 72d320006177 ("gpio: set up
initial state from .get_direction()").
I would be in favor of either reverting that patch, or moving the code
into gpiochip_add_pin_range().
ACPI can still describe only the pin ranges that they care about
exposing, but from the devicetree side it's been working well
enough to not touch pins that aren't used by anything in Linux.
I do hate having to hack up the driver to support crappy ACPI
definitions, but I'm stuck between a rock and a hard place.
--
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
