Message ID | 20180323163453.96495-1-swboyd@chromium.org |
---|---|
Headers | show |
Series | Support qcom pinctrl protected pins | expand |
On 03/23/2018 11:34 AM, Stephen Boyd wrote: > Stephen Boyd (5): > dt-bindings: gpio: Add a gpio-reserved-ranges property > gpiolib: Extract mask allocation into subroutine > gpiolib: Change bitmap allocation to kmalloc_array > gpiolib: Support 'gpio-reserved-ranges' property > pinctrl: qcom: Don't allow protected pins to be requested ACPI parts: Tested-by: Timur Tabi <timur@codeaurora.org> I posted a pair of patches that should be applied on top of yours. The first one fixed pinctrl-msm when there is more than one TLMM device. The second adds support for my SOC.
On Fri, 2018-03-23 at 09:34 -0700, Stephen Boyd wrote: > This patchset proposes a solution to describing the > valid > > pins for a pin controller in a 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. > > > The proposal is to describe the valid pins and then not allow things > to > cause problems by using the invalid pins. Obviously, the firmware > may > mess this up, so this is mostly a nice to have feature or a safety > net > so that things don't blow up > easily. FWIW, Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Changes from v3: > * Split out allocation of mask into subroutine > * Moved that allocation to kmalloc_array() > * Updated qcom driver to simplifiy ACPI logic and fix mem leak > > Changes from v2: > * Renamed binding to 'gpio-reserved-ranges' > * Reworked gpiolib patch to not use irqdomains > * Update qcom driver patch to use new valid_mask field > > > Changes from > v1: > > * Pushed into gpiolib-of core under irq valid line > logic > > * Fixed up qcom driver patch to free stuff properly and remove custom > code > * Dropped export patch as it got picked > up > > * Renamed binding to 'reserved-gpio-ranges' > > > Stephen Boyd (5): > dt-bindings: gpio: Add a gpio-reserved-ranges property > gpiolib: Extract mask allocation into subroutine > gpiolib: Change bitmap allocation to kmalloc_array > gpiolib: Support 'gpio-reserved-ranges' property > pinctrl: qcom: Don't allow protected pins to be requested > > .../devicetree/bindings/gpio/gpio.txt | 7 +- > drivers/gpio/gpiolib-of.c | 24 +++++++ > drivers/gpio/gpiolib.c | 66 +++++++++++++++++- > - > drivers/pinctrl/qcom/pinctrl-msm.c | 65 +++++++++++++++++- > include/linux/gpio/driver.h | 16 +++++ > 5 files changed, 167 insertions(+), 11 deletions(-) >
On Fri, Mar 23, 2018 at 5:34 PM, Stephen Boyd <swboyd@chromium.org> wrote: > This patchset proposes a solution to describing the valid > pins for a pin controller in a 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. > > The proposal is to describe the valid pins and then not allow things to > cause problems by using the invalid pins. Obviously, the firmware may > mess this up, so this is mostly a nice to have feature or a safety net > so that things don't blow up easily. > > Changes from v3: > * Split out allocation of mask into subroutine > * Moved that allocation to kmalloc_array() > * Updated qcom driver to simplifiy ACPI logic and fix mem leak As both Timur and Andy are happy with this I applied these five patches for v4.17 and pushed to the test farm. Let's see what happens! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html