| Message ID | 20180126011400.2191-3-sboyd@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 2018-01-25 at 17:13 -0800, Stephen Boyd wrote: > 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. > +static void of_gpiochip_init_irq_valid_mask(struct gpio_chip *chip) > +{ > + int len, i; > + u32 start, count; > + struct device_node *np = chip->of_node; Perhaps reversed tree style? (In the following function as well) > + len = of_property_count_u32_elems(np, "reserved-gpio- > ranges"); > > + for (i = 0; i < len; i += 2) { > + of_property_read_u32_index(np, "reserved-gpio- > ranges", > + i, &start); > + of_property_read_u32_index(np, "reserved-gpio- > ranges", > + i + 1, &count); of_find_property() + of_prop_next_u32() ? > + if (size > 0 && size % 2 == 0) > + gpiochip->irq.need_valid_mask = true; ffs(size) >= 2 ?
Hi Stephen, nice work! On Fri, Jan 26, 2018 at 2:13 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > 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? Yours, Linus Walleij
Quoting Linus Walleij (2018-02-07 05:34:19) > Hi Stephen, > > nice work! > > On Fri, Jan 26, 2018 at 2:13 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > > > 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? I don't think that it will be too much work to tweak the code to treat these as gpios instead of irq lines. It may end up duplicating a bit of code that the irq line stuff is already doing, but I'll take a stab at it and see how bad it comes out.
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index 564bb7a31da4..194b3306ef74 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -498,6 +498,32 @@ void of_mm_gpiochip_remove(struct of_mm_gpio_chip *mm_gc) } EXPORT_SYMBOL(of_mm_gpiochip_remove); +#ifdef CONFIG_GPIOLIB_IRQCHIP +static void of_gpiochip_init_irq_valid_mask(struct gpio_chip *chip) +{ + int len, i; + u32 start, count; + struct device_node *np = chip->of_node; + + len = of_property_count_u32_elems(np, "reserved-gpio-ranges"); + if (len < 0 || len % 2 != 0) + return; + + for (i = 0; i < len; i += 2) { + of_property_read_u32_index(np, "reserved-gpio-ranges", + i, &start); + of_property_read_u32_index(np, "reserved-gpio-ranges", + i + 1, &count); + if (start >= chip->ngpio || start + count >= chip->ngpio) + continue; + + bitmap_clear(chip->irq.valid_mask, start, count); + } +}; +#else +static void of_gpiochip_init_irq_valid_mask(struct gpio_chip *chip) { } +#endif + #ifdef CONFIG_PINCTRL static int of_gpiochip_add_pin_range(struct gpio_chip *chip) { @@ -602,6 +628,8 @@ int of_gpiochip_add(struct gpio_chip *chip) if (chip->of_gpio_n_cells > MAX_PHANDLE_ARGS) return -EINVAL; + of_gpiochip_init_irq_valid_mask(chip); + status = of_gpiochip_add_pin_range(chip); if (status) return status; diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 930676ec9847..8483850463e6 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1483,6 +1483,15 @@ static struct gpio_chip *find_chip_by_name(const char *name) static int gpiochip_irqchip_init_valid_mask(struct gpio_chip *gpiochip) { +#ifdef CONFIG_OF_GPIO + int size; + struct device_node *np = gpiochip->of_node; + + size = of_property_count_u32_elems(np, "reserved-gpio-ranges"); + if (size > 0 && size % 2 == 0) + gpiochip->irq.need_valid_mask = true; +#endif + if (!gpiochip->irq.need_valid_mask) return 0;
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. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> --- Or this can move into a dedicated API and not be tied to the irq code. Something like of_gpiochip_init_valid_mask? drivers/gpio/gpiolib-of.c | 28 ++++++++++++++++++++++++++++ drivers/gpio/gpiolib.c | 9 +++++++++ 2 files changed, 37 insertions(+)