Support qcom pinctrl protected pins

Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Introduce a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing.

Cc Grant Likely <[email protected]>

Cc <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---
 Documentation/devicetree/bindings/gpio/gpio.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Documentation/devicetree/bindings/gpio/gpio.txt +4 -3

index b5de08e3b1a2..c22b56680fc8 100644
@@ -151,9 +151,9 @@ in a lot of designs, some using all 32 bits, some using 18 and some using
 first 18 GPIOs, at local offset 0 .. 17, are in use.
 
 If these GPIOs do not happen to be the first N GPIOs at offset 0...N-1, an
-additional bitmask is needed to specify which GPIOs are actually in use,
-and which are dummies. The bindings for this case has not yet been
-specified, but should be specified if/when such hardware appears.
+additional set of tuples is needed to specify which GPIOs are unusable, with
+the reserved-gpio-ranges binding. This property indicates the start and size
+of the GPIOs that can't be used.
 
 Optionally, a GPIO controller may have a "gpio-line-names" property. This is
 an array of strings defining the names of the GPIO lines going out of the

@@ -178,6 +178,7 @@ gpio-controller at 00000000 {
 	gpio-controller;
 	#gpio-cells = <2>;
 	ngpios = <18>;
+	reserved-gpio-ranges = <0 4>, <12 2>;
 	gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R",
 		"LED G", "LED B", "Col A", "Col B", "Col C", "Col D",
 		"Row A", "Row B", "Row C", "Row D", "NMI button",

Signature · 2 lines

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

Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Introduce a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing.

Cc Grant Likely <[email protected]>

Cc <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

This looks fine except Andy's note to rename this ranges to gpio-reserved-ranges for namespacing.

Are you reposting this series as v3 with this fixed or does someone else need to pick it up?

Hi Stephen,

thanks for the patch and hope you have a good time at your new workplace!

Quoted 7 lines · Stephen Boyd

Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Introduce a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing.

Quoted 3 lines

Cc Grant Likely <[email protected]>

Cc <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

This looks fine except Andy's note to rename this ranges to gpio-reserved-ranges for namespacing.

Are you reposting this series as v3 with this fixed or does someone else need to pick it up?

Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Add support for a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing.

For now, we plumb this into the gpiochip irq APIs so that GPIO/pinctrl drivers can use the gpiochip_irqchip_irq_valid() to test validity of GPIOs.

For now, we plumb this into the gpiochip irq APIs so that GPIO/pinctrl drivers can use the gpiochip_irqchip_irq_valid() to test validity of GPIOs.

Hi Stephen,

nice work!

Quoted 3 lines · Stephen Boyd

For now, we plumb this into the gpiochip irq APIs so that GPIO/pinctrl drivers can use the gpiochip_irqchip_irq_valid() to test validity of GPIOs.

But is that the right thing to do, given that we just took the trouble to define a DT binding that is explicitly about any GPIO, not just IRQ capable ones?

I am worries that the *irq* infix etc on these functions will be a bit confusing.

Is it a lot of work to make it just generic and maybe bake it into the gpio_chip so as to refuse already in gpiod_request_commit() in gpiolib already?

This patchset proposes a solution to describing the valid pins for a pin controller in a semi-generic way so that qcom platforms can expose the pins that are really available.

Typically, this has been done by having drivers and firmware descriptions only use pins they know they have access to, and that still works now because we no longer read the pin direction at boot. But there are still some userspace drivers and debugfs facilities that don't know what pins are available and attempt to read everything they can. On qcom platforms, this may lead to a system hang, which isn't very nice behavior, even if root is the only user that can trigger it.

Quoted 5 lines · Stephen Boyd

This patchset proposes a solution to describing the valid pins for a pin controller in a semi-generic way so that qcom platforms can expose the pins that are really available.

Quoted 7 lines

Typically, this has been done by having drivers and firmware descriptions only use pins they know they have access to, and that still works now because we no longer read the pin direction at boot. But there are still some userspace drivers and debugfs facilities that don't know what pins are available and attempt to read everything they can. On qcom platforms, this may lead to a system hang, which isn't very nice behavior, even if root is the only user that can trigger it.

Any progress on this patch set? Stephen no longer works for Qualcomm, so I don't know what the next step is, and I really want this feature in 4.17 (we've missed so many merge windows already).

Quoted 14 lines · Timur Tabi

Quoted 12 lines · Stephen Boyd

This patchset proposes a solution to describing the valid pins for a pin controller in a semi-generic way so that qcom platforms can expose the pins that are really available.

Typically, this has been done by having drivers and firmware descriptions only use pins they know they have access to, and that still works now because we no longer read the pin direction at boot. But there are still some userspace drivers and debugfs facilities that don't know what pins are available and attempt to read everything they can. On qcom platforms, this may lead to a system hang, which isn't very nice behavior, even if root is the only user that can trigger it.

Quoted 3 lines

Any progress on this patch set? Stephen no longer works for Qualcomm, so I don't know what the next step is, and I really want this feature in 4.17 (we've missed so many merge windows already).

I depend on Bjorn as maintainer of the pin control driver to ACK the solution he likes.

I haven't found the time to review the reuse of the irq valid mask or the effort needed to replace this, other than that I think the series looks good.