Sparse GPIO maps with pinctrl-msm.c?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've run into a problem with our ACPI system where it turns out that
one a subset of GPIOs are actually available to Linux.  Attempting to
access anything that's not "approve" generates an XPU violation and
halts the system.

Our pin control driver, pinctrl-qdf2xxx.c, is a client on
pintrl-msm.c.  As such, it has to package the GPIO information in a
way that pinctrl-msm can use.  I just want to get confirmation that
there is no way to provide a list of specific GPIOs.

The actual list are these GPIOs: 116, 117, 118, 119, 120, 121, 122,
123, 124, 125, 126, 127, 128, 129, 130, 131, 80, 81, 82, 83, 84, 85,
86, 87, 88, 89, 90, 50, 36, 37, 38, 39.  These correspond to
qdss_tracedata[0 - 31].  I can create these as gpio0 - gpio31, but
that doesn't work because then no one will know (without using
debug_fs) that "gpio3" is actually GPIO 119.

I can instead create all 150 GPIOs, and then specify NULL data for the
118 unavailable GPIOs, but then if anyone tries to access any of those
(e.g. "echo 7 > /sys/class/gpio/gexport") will case a violation.

Is there a way, in pinctrl-msm, to specify a GPIO that doesn't
actually exist, and therefore should never be exported?

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, 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



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux