On 10/03, Timur Tabi wrote:

On 10/03/2017 05:03 PM, Stephen Boyd wrote:

quoted

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.

Do you avoid this problem on new ACPI tables because only pins
that are able to be read are exposed?

quoted

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().

If it's in gpiochip_add_pin_range() would we still read the
hardware when creating the pin ranges? I don't want to have to
describe pin ranges of "valid" pins that won't cause the system
to blow up if we touch them, because those pins are never used by
Linux so reading them is not useful.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project