summaryrefslogtreecommitdiff
path: root/drivers/pinctrl
AgeCommit message (Collapse)AuthorFilesLines
2021-01-27pinctrl: qcom: Don't clear pending interrupts when enablingDouglas Anderson1-24/+50
commit cf9d052aa6005f1e8dfaf491d83bf37f368af69e upstream. In Linux, if a driver does disable_irq() and later does enable_irq() on its interrupt, I believe it's expecting these properties: * If an interrupt was pending when the driver disabled then it will still be pending after the driver re-enables. * If an edge-triggered interrupt comes in while an interrupt is disabled it should assert when the interrupt is re-enabled. If you think that the above sounds a lot like the disable_irq() and enable_irq() are supposed to be masking/unmasking the interrupt instead of disabling/enabling it then you've made an astute observation. Specifically when talking about interrupts, "mask" usually means to stop posting interrupts but keep tracking them and "disable" means to fully shut off interrupt detection. It's unfortunate that this is so confusing, but presumably this is all the way it is for historical reasons. Perhaps more confusing than the above is that, even though clients of IRQs themselves don't have a way to request mask/unmask vs. disable/enable calls, IRQ chips themselves can implement both. ...and yet more confusing is that if an IRQ chip implements disable/enable then they will be called when a client driver calls disable_irq() / enable_irq(). It does feel like some of the above could be cleared up. However, without any other core interrupt changes it should be clear that when an IRQ chip gets a request to "disable" an IRQ that it has to treat it like a mask of that IRQ. In any case, after that long interlude you can see that the "unmask and clear" can break things. Maulik tried to fix it so that we no longer did "unmask and clear" in commit 71266d9d3936 ("pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback"), but it only handled the PDC case and it had problems (it caused sc7180-trogdor devices to fail to suspend). Let's fix. >From my understanding the source of the phantom interrupt in the were these two things: 1. One that could have been introduced in msm_gpio_irq_set_type() (only for the non-PDC case). 2. Edges could have been detected when a GPIO was muxed away. Fixing case #1 is easy. We can just add a clear in msm_gpio_irq_set_type(). Fixing case #2 is harder. Let's use a concrete example. In sc7180-trogdor.dtsi we configure the uart3 to have two pinctrl states, sleep and default, and mux between the two during runtime PM and system suspend (see geni_se_resources_{on,off}() for more details). The difference between the sleep and default state is that the RX pin is muxed to a GPIO during sleep and muxed to the UART otherwise. As per Qualcomm, when we mux the pin over to the UART function the PDC (or the non-PDC interrupt detection logic) is still watching it / latching edges. These edges don't cause interrupts because the current code masks the interrupt unless we're entering suspend. However, as soon as we enter suspend we unmask the interrupt and it's counted as a wakeup. Let's deal with the problem like this: * When we mux away, we'll mask our interrupt. This isn't necessary in the above case since the client already masked us, but it's a good idea in general. * When we mux back will clear any interrupts and unmask. Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio") Fixes: 71266d9d3936 ("pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210114191601.v7.4.I7cf3019783720feb57b958c95c2b684940264cd1@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27pinctrl: qcom: Properly clear "intr_ack_high" interrupts when unmaskingDouglas Anderson1-4/+10
commit a95881d6aa2c000e3649f27a1a7329cf356e6bb3 upstream. In commit 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio") we tried to Ack interrupts during unmask. However, that patch forgot to check "intr_ack_high" so, presumably, it only worked for a certain subset of SoCs. Let's add a small accessor so we don't need to open-code the logic in both places. This was found by code inspection. I don't have any access to the hardware in question nor software that needs the Ack during unmask. Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210114191601.v7.3.I32d0f4e174d45363b49ab611a13c3da8f1e87d0f@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27pinctrl: qcom: No need to read-modify-write the interrupt statusDouglas Anderson1-15/+8
commit 4079d35fa4fca4ee0ffd66968312fc86a5e8c290 upstream. When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a read-modify-write on the interrupt status register. On some SoCs it makes sure that the status bit is 1 to "Ack" and on others it makes sure that the bit is 0 to "Ack". Presumably the first type of interrupt controller is a "write 1 to clear" type register and the second just let you directly set the interrupt status register. As far as I can tell from scanning structure definitions, the interrupt status bit is always in a register by itself. Thus with both types of interrupt controllers it is safe to "Ack" interrupts without doing a read-modify-write. We can do a simple write. It should be noted that if the interrupt status bit _was_ ever in a register with other things (like maybe status bits for other GPIOs): a) For "write 1 clear" type controllers then read-modify-write would be totally wrong because we'd accidentally end up clearing interrupts we weren't looking at. b) For "direct set" type controllers then read-modify-write would also be wrong because someone setting one of the other bits in the register might accidentally clear (or set) our interrupt. I say this simply to show that the current read-modify-write doesn't provide any sort of "future proofing" of the code. In fact (for "write 1 clear" controllers) the new code is slightly more "future proof" since it would allow more than one interrupt status bits to share a register. NOTE: this code fixes no bugs--it simply avoids an extra register read. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210114191601.v7.2.I3635de080604e1feda770591c5563bd6e63dd39d@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27pinctrl: qcom: Allow SoCs to specify a GPIO function that's not 0Douglas Anderson2-2/+3
commit a82e537807d5c85706cd4c16fd2de77a8495dc8d upstream. There's currently a comment in the code saying function 0 is GPIO. Instead of hardcoding it, let's add a member where an SoC can specify it. No known SoCs use a number other than 0, but this just makes the code clearer. NOTE: no SoC code needs to be updated since we can rely on zero-initialization. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210114191601.v7.1.I3ad184e3423d8e479bc3e86f5b393abb1704a1d1@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27pinctrl: mediatek: Fix fallback call pathHsin-Yi Wang1-0/+4
[ Upstream commit 81bd1579b43e0e285cba667399f1b063f1ce7672 ] Some SoCs, eg. mt8183, are using a pinconfig operation bias_set_combo. The fallback path in mtk_pinconf_adv_pull_set() should also try this operation. Fixes: cafe19db7751 ("pinctrl: mediatek: Backward compatible to previous Mediatek's bias-pull usage") Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Acked-by: Sean Wang <sean.wang@kernel.org> Link: https://lore.kernel.org/r/20201228090425.2130569-1-hsinyi@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-27pinctrl: aspeed: g6: Fix PWMG0 pinctrl settingBilly Tsai1-1/+1
[ Upstream commit 92ff62a7bcc17d47c0ce8dddfb7a6e1a2e55ebf4 ] The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from SCU414 to SCU4B4. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support") Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20201217024912.3198-1-billy_tsai@aspeedtech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-27pinctrl: ingenic: Fix JZ4760 supportPaul Cercueil1-13/+13
commit 9a85c09a3f507b925d75cb0c7c8f364467038052 upstream. - JZ4760 and JZ4760B have a similar register layout as the JZ4740, and don't use the new register layout, which was introduced with the JZ4770 SoC and not the JZ4760 or JZ4760B SoCs. - The JZ4740 code path only expected two function modes to be configurable for each pin, and wouldn't work with more than two. Fix it for the JZ4760, which has four configurable function modes. Fixes: 0257595a5cf4 ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and JZ4760B.") Cc: <stable@vger.kernel.org> # 5.3 Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20201211232810.261565-1-paul@crapouillou.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30pinctrl: sunxi: Always call chained_irq_{enter, exit} in ↵Yangtao Li1-2/+4
sunxi_pinctrl_irq_handler commit a1158e36f876f6269978a4176e3a1d48d27fe7a1 upstream. It is found on many allwinner soc that there is a low probability that the interrupt status cannot be read in sunxi_pinctrl_irq_handler. This will cause the interrupt status of a gpio bank to always be active on gic, preventing gic from responding to other spi interrupts correctly. So we should call the chained_irq_* each time enter sunxi_pinctrl_irq_handler(). Signed-off-by: Yangtao Li <frank@allwinnertech.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/85263ce8b058e80cea25c6ad6383eb256ce96cc8.1604988979.git.frank@allwinnertech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30pinctrl: falcon: add missing put_device() call in pinctrl_falcon_probe()Yu Kuai1-5/+9
[ Upstream commit 89cce2b3f247a434ee174ab6803698041df98014 ] if of_find_device_by_node() succeed, pinctrl_falcon_probe() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: e316cb2b16bb ("OF: pinctrl: MIPS: lantiq: adds support for FALCON SoC") Signed-off-by: Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20201119011219.2248232-1-yukuai3@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30pinctrl: sunxi: fix irq bank map for the Allwinner A100 pin controllerYangtao Li1-1/+1
[ Upstream commit 6de7ed693c631d4689acfe90c434147598d75543 ] A100's pin starts with PB, so it should start with 1. Fixes: 473436e7647d6 ("pinctrl: sunxi: add support for the Allwinner A100 pin controller") Signed-off-by: Yangtao Li <frank@allwinnertech.com> Link: https://lore.kernel.org/r/9db51667bf9065be55beafd56e5c319e3bbe8310.1604988979.git.frank@allwinnertech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30pinctrl: core: Add missing #ifdef CONFIG_GPIOLIBHe Zhe1-0/+2
[ Upstream commit b507cb92477ad85902783a183c5ce01d16296687 ] To fix the following build warnings when CONFIG_GPIOLIB=n. drivers/pinctrl/core.c:1607:20: warning: unused variable 'chip' [-Wunused-variable] 1608 | struct gpio_chip *chip; | ^~~~ drivers/pinctrl/core.c:1606:15: warning: unused variable 'gpio_num' [-Wunused-variable] 1607 | unsigned int gpio_num; | ^~~~~~~~ drivers/pinctrl/core.c:1605:29: warning: unused variable 'range' [-Wunused-variable] 1606 | struct pinctrl_gpio_range *range; | ^~~~~ Fixes: f1b206cf7c57 ("pinctrl: core: print gpio in pins debugfs file") Signed-off-by: He Zhe <zhe.he@windriver.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201028103921.22486-1-zhe.he@windriver.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-09pinctrl: intel: Actually disable Tx and Rx buffers on GPIO requestAndy Shevchenko1-2/+2
Mistakenly the buffers (input and output) become enabled together for a short period of time during GPIO request. This is problematic, because instead of initial motive to disable them in the commit af7e3eeb84e2 ("pinctrl: intel: Disable input and output buffer when switching to GPIO"), the driven value on the pin, which might be used as an IRQ line, brings firmwares of some touch pads to an awkward state that needs a full power off to recover. Fix this, as stated in the culprit commit, by disabling the buffers. Fixes: af7e3eeb84e2 ("pinctrl: intel: Disable input and output buffer when switching to GPIO") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210497 Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20201208182403.40435-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-12-08pinctrl: aspeed: Fix GPIO requests on pass-through banksAndrew Jeffery2-9/+72
Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Billy Tsai <billy_tsai@aspeedtech.com> Cc: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-12-04pinctrl: amd: remove debounce filter setting in IRQ type settingCoiby Xu1-7/+0
Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). Together with commit 06abe8291bc31839950f7d0362d9979edc88a666 ("pinctrl: amd: fix incorrect way to disable debounce filter") and Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], this will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [2][3] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-17Merge tag 'intel-pinctrl-v5.10-3' of ↵Linus Walleij3-222/+246
gitolite.kernel.org:pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.10-3 * Fix HOSTSW_OWN offset and unhide SPI group of pins on Jasper Lake * Fix debounce configuration on Baytrail when it's turned off * Fix default bias setting on Merrifield The following is an automated git shortlog grouped by driver: baytrail: - Avoid clearing debounce value when turning it off jasperlake: - Fix HOSTSW_OWN offset - Unhide SPI group of pins merrifield: - Set default bias in case no particular value given
2020-11-16pinctrl: baytrail: Avoid clearing debounce value when turning it offAndy Shevchenko1-1/+7
Baytrail pin control has a common register to set up debounce timeout. When a pin configuration requested debounce to be disabled, the rest of the pins may still want to have debounce enabled and thus rely on the common timeout value. Avoid clearing debounce value when turning it off for one pin while others may still use it. Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration") Depends-on: 04ff5a095d66 ("pinctrl: baytrail: Rectify debounce support") Depends-on: 827e1579e1d5 ("pinctrl: baytrail: Rectify debounce support (part 2)") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-16pinctrl: merrifield: Set default bias in case no particular value givenAndy Shevchenko1-0/+8
When GPIO library asks pin control to set the bias, it doesn't pass any value of it and argument is considered boolean (and this is true for ACPI GpioIo() / GpioInt() resources, by the way). Thus, individual drivers must behave well, when they got the resistance value of 1 Ohm, i.e. transforming it to sane default. In case of Intel Merrifield pin control hardware the 20 kOhm sounds plausible because it gives a good trade off between weakness and minimization of leakage current (will be only 50 uA with the above choice). Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support") Depends-on: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-16pinctrl: jasperlake: Fix HOSTSW_OWN offsetEvan Green1-1/+1
GPIOs that attempt to use interrupts get thwarted with a message like: "pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because the HOSTSW_OWN offset is incorrect, so every GPIO looks like it's owned by ACPI. Fixes: e278dcb7048b1 ("pinctrl: intel: Add Intel Jasper Lake pin controller support") Cc: stable@vger.kernel.org Signed-off-by: Evan Green <evgreen@chromium.org> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-11-16pinctrl: jasperlake: Unhide SPI group of pinsAndy Shevchenko1-220/+230
If the group of pins is hidden in the pin list it affects the register offset calculation despite fixed GPIO base. Hence, the offsets of all pins after the hidden group are broken. Instead we have to unhide the group and use a flag to exclude it from GPIO number space. Fixes: e278dcb7048b ("pinctrl: intel: Add Intel Jasper Lake pin controller support") Reported-by: Divagar Mohandass <divagar.mohandass@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10Merge tag 'intel-pinctrl-v5.10-2' of ↵Linus Walleij1-10/+30
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.10-2 * Respect bias setting when comes from ACPI The following is an automated git shortlog grouped by driver: intel: - Set default bias in case no particular value given - Fix 2 kOhm bias which is 833 Ohm
2020-11-10pinctrl: qcom: sm8250: Specify PDC mapBjorn Andersson1-0/+18
Specify the PDC mapping for SM8250, so that gpio interrupts are propertly mapped to the wakeup IRQs of the PDC. Fixes: 4e3ec9e407ad ("pinctrl: qcom: Add sm8250 pinctrl driver.") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20201028043642.1141723-1-bjorn.andersson@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-10pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callbackMaulik Shah1-13/+19
When GPIOs that are routed to PDC are used as output they can still latch the IRQ pending at GIC. As a result the spurious IRQ was handled when the client driver change the direction to input to starts using it as IRQ. Currently such erroneous latched IRQ are cleared with .irq_enable callback however if the driver continue to use GPIO as interrupt and invokes disable_irq() followed by enable_irq() then everytime during enable_irq() previously latched interrupt gets cleared. This can make edge IRQs not seen after enable_irq() if they had arrived after the driver has invoked disable_irq() and were pending at GIC. Move clearing erroneous IRQ to .irq_request_resources callback as this is the place where GPIO direction is changed as input and its locked as IRQ. While at this add a missing check to invoke msm_gpio_irq_clear_unmask() from .irq_enable callback only when GPIO is not routed to PDC. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/1604561884-10166-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-10pinctrl: amd: use higher precision for 512 RtcClkCoiby Xu1-1/+1
RTC is 32.768kHz thus 512 RtcClk equals 15625 usec. The documentation likely has dropped precision and that's why the driver mistakenly took the slightly deviated value. Cc: stable@vger.kernel.org Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/linux-gpio/2f4706a1-502f-75f0-9596-cc25b4933b6c@redhat.com/ Link: https://lore.kernel.org/r/20201105231912.69527-3-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-10pinctrl: amd: fix incorrect way to disable debounce filterCoiby Xu1-2/+2
The correct way to disable debounce filter is to clear bit 5 and 6 of the register. Cc: stable@vger.kerne.org Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/linux-gpio/df2c008b-e7b5-4fdd-42ea-4d1c62b52139@redhat.com/ Link: https://lore.kernel.org/r/20201105231912.69527-2-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-05pinctrl: aspeed: Fix GPI only function problem.Billy Tsai1-3/+4
Some gpio pin at aspeed soc is input only and the prefix name of these pin is "GPI" only. This patch fine-tune the condition of GPIO check from "GPIO" to "GPI" and it will fix the usage error of banks D and E in the AST2400/AST2500 and banks T and U in the AST2600. Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20201030055450.29613-1-billy_tsai@aspeedtech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-05pinctrl: mcp23s08: Print error message when regmap init failsAndy Shevchenko1-0/+2
It is useful for debugging to have the error message printed when regmap initialisation fails. Add it to the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20201009180856.4738-2-andriy.shevchenko@linux.intel.com Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-05pinctrl: mcp23s08: Use full chunk of memory for regmap configurationAndy Shevchenko1-1/+1
It appears that simplification of mcp23s08_spi_regmap_init() made a regression due to wrong size calculation for dev_kmemdup() call. It misses the fact that config variable is already a pointer, thus the sizeof() calculation is wrong and only 4 or 8 bytes were copied. Fix the parameters to devm_kmemdup() to copy a full chunk of memory. Fixes: 0874758ecb2b ("pinctrl: mcp23s08: Refactor mcp23s08_spi_regmap_init()") Reported-by: Martin Hundebøll <martin@geanix.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20201009180856.4738-1-andriy.shevchenko@linux.intel.com Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-04pinctrl: rockchip: create irq mapping in gpio_to_irqJianqun Xu1-16/+12
Remove totally irq mappings create in probe, the gpio irq mapping will be created when do gpio_to_irq -> rockchip_gpio_to_irq -> irq_create_mapping This patch can speed up system boot on, also abandon many unused irq mappings' create. Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Kever Yang<kever.yang@rock-chips.com> Link: https://lore.kernel.org/r/20201013063731.3618-4-jay.xu@rock-chips.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-04pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irqJianqun Xu1-0/+2
There need to enable pclk_gpio when do irq_create_mapping, since it will do access to gpio controller. Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Kever Yang<kever.yang@rock-chips.com> Link: https://lore.kernel.org/r/20201013063731.3618-3-jay.xu@rock-chips.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-28pinctrl: ingenic: Fix invalid SSI pinsPaul Cercueil1-36/+36
The values for the SSI pins on GPIO chips D and E were off by 0x20. Fixes: d3ef8c6b2286 ("pinctrl: Ingenic: Add SSI pins support for JZ4770 and JZ4780.") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reported-by: Artur Rojek <contact@artur-rojek.eu> Link: https://lore.kernel.org/r/20201010192509.9098-1-paul@crapouillou.net Reviewed-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-26pinctrl: intel: Set default bias in case no particular value givenAndy Shevchenko1-0/+8
When GPIO library asks pin control to set the bias, it doesn't pass any value of it and argument is considered boolean (and this is true for ACPI GpioIo() / GpioInt() resources, by the way). Thus, individual drivers must behave well, when they got the resistance value of 1 Ohm, i.e. transforming it to sane default. In case of Intel pin control hardware the 5 kOhm sounds plausible because on one hand it's a minimum of resistors present in all hardware generations and at the same time it's high enough to minimize leakage current (will be only 200 uA with the above choice). Fixes: e57725eabf87 ("pinctrl: intel: Add support for hardware debouncer") Reported-by: Jamie McClymont <jamie@kwiius.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-10-26pinctrl: intel: Fix 2 kOhm bias which is 833 OhmAndy Shevchenko1-10/+22
2 kOhm bias was never an option in Intel GPIO hardware, the available matrix is: 000 none 001 1 kOhm (if available) 010 5 kOhm 100 20 kOhm As easy to get the 3 resistors are gated separately and according to parallel circuits calculations we may get combinations of the above where the result is always strictly less than minimal resistance. Hence, additional values can be: 011 ~833.3 Ohm 101 ~952.4 Ohm 110 ~4 kOhm 111 ~800 Ohm That said, convert TERM definitions to be the bit masks to reflect the above. While at it, enable the same setting for pull down case. Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support") Cc: Jamie McClymont <jamie@kwiius.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-10-14Merge tag 'pinctrl-v5.10-1' of ↵Linus Torvalds102-501/+10422
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "Core changes: - NONE whatsoever, we don't even touch the core files this time around. New drivers: - New driver for the Toshiba Visconti SoC. - New subdriver for the Qualcomm MSM8226 SoC. - New subdriver for the Actions Semiconductor S500 SoC. - New subdriver for the Mediatek MT8192 SoC. - New subdriver for the Microchip SAMA7G5 SoC. Driver enhancements: - Intel Cherryview and Baytrail cleanups and refactorings. - Enhanced support for the Renesas R8A7790, more pins and groups. - Some optimizations for the MCP23S08 MCP23x17 variant. - Some cleanups around the Actions Semiconductor subdrivers. - A bunch of cleanups around the SH-PFC and Emma Mobile drivers. - The "SH-PFC" (literally SuperH pin function controller, I think) subdirectory is now renamed to the more neutral "renesas", as these are not very much centered around SuperH anymore. - Non-critical fixes for the Aspeed driver. - Non-critical fixes for the Ingenic (MIPS!) driver. - Fix a bunch of missing pins on the AMD pinctrl driver" * tag 'pinctrl-v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (78 commits) pinctrl: amd: Add missing pins to the pin group list dt-bindings: pinctrl: sunxi: Allow pinctrl with more interrupt banks pinctrl: visconti: PINCTRL_TMPV7700 should depend on ARCH_VISCONTI pinctrl: mediatek: Free eint data on failure pinctrl: single: fix debug output when #pinctrl-cells = 2 pinctrl: single: fix pinctrl_spec.args_count bounds check pinctrl: sunrisepoint: Modify COMMUNITY macros to be consistent pinctrl: cannonlake: Modify COMMUNITY macros to be consistent pinctrl: tigerlake: Fix register offsets for TGL-H variant pinctrl: Document pinctrl-single,pins when #pinctrl-cells = 2 pinctrl: mediatek: use devm_platform_ioremap_resource_byname() pinctrl: nuvoton: npcm7xx: Constify static ops structs pinctrl: mediatek: mt7622: add antsel pins/groups pinctrl: ocelot: simplify the return expression of ocelot_gpiochip_register() pinctrl: at91-pio4: add support for sama7g5 SoC dt-bindings: pinctrl: at91-pio4: add microchip,sama7g5 pinctrl: spear: simplify the return expression of tvc_connect() pinctrl: spear: simplify the return expression of spear310_pinctrl_probe pinctrl: sprd: use module_platform_driver to simplify the code pinctrl: Ingenic: Add I2S pins support for Ingenic SoCs. ...
2020-10-13Merge tag 'gpio-v5.10-1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This time very little driver changes but lots of core changes. We have some interesting cooperative work for ARM and Intel alike, making the GPIO subsystem more and more suitable for industrial systems and the like, in addition to the in-kernel users. We touch driver core (device properties) and lib/* by adding one simple string array free function, these are authored by Andy Shevchenko who is a well known and recognized core helpers maintainers so this should be fine. We also see some Android GKI-related modularization in the MXC drivers. Core changes: - The big core change is the updated (v2) userspace character device API. This corrects badly designed 64-bit alignment around the line events. We also add the debounce request feature. This echoes the often quotes passage from Frederick Brooks "The mythical man-month" to always throw one away, which we have seen before in things such as V4L2. So we put in a new one and deprecate and obsolete the old one. - All example tools in tools/gpio/* are migrated to the new API to set a good example. The libgpiod userspace library has been augmented to use this new API pretty much from day 1. - Some misc API hardening by using strn* function calls has been added as well. - Use the simpler IDA interface for GPIO chip instance enumeration. - Add device core function for counting string arrays in device properties. - Provide a generic library function kfree_strarray() that can be used throughout the kernel. Driver enhancements: - The DesignWare dwapb-gpio driver has been enhanced and now uses the IRQ handling in the gpiolib core. - The mockup and aggregator drivers have seen some substantial code clean-up and now use more of the core kernel inftrastructure. - Misc cleanups using dev_err_probe(). - The MXC drivers (Freescale/NXP) can now be built modularized, which makes modularized GKI Android kernels happy" * tag 'gpio-v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (73 commits) gpiolib: Update header block in gpiolib-cdev.h gpiolib: cdev: switch from kstrdup() to kstrndup() docs: gpio: add a new document to its index.rst gpio: pca953x: Add support for the NXP PCAL9554B/C tools: gpio: add debounce support to gpio-event-mon tools: gpio: add multi-line monitoring to gpio-event-mon tools: gpio: port gpio-event-mon to v2 uAPI tools: gpio: port gpio-hammer to v2 uAPI tools: gpio: rename nlines to num_lines tools: gpio: port gpio-watch to v2 uAPI tools: gpio: port lsgpio to v2 uAPI gpio: uapi: document uAPI v1 as deprecated gpiolib: cdev: support setting debounce gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL gpiolib: cdev: support edge detection for uAPI v2 gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL gpiolib: add build option for CDEV v1 ABI gpiolib: make cdev a build option ...
2020-10-12Merge tag 'irq-core-2020-10-12' of ↵Linus Torvalds1-5/+6
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq updates from Thomas Gleixner: "Updates for the interrupt subsystem: Core: - Allow trimming of interrupt hierarchy to support odd hardware setups where only a subset of the interrupts requires the full hierarchy. - Allow the retrigger mechanism to follow a hierarchy to simplify driver code. - Provide a mechanism to force enable wakeup interrrupts on suspend. - More infrastructure to handle IPIs in the core code Architectures: - Convert ARM/ARM64 IPI handling to utilize the interrupt core code. Drivers: - The usual pile of new interrupt chips (MStar, Actions Owl, TI PRUSS, Designware ICTL) - ARM(64) IPI related conversions - Wakeup support for Qualcom PDC - Prevent hierarchy corruption in the NVIDIA Tegra driver - The usual small fixes, improvements and cleanups all over the place" * tag 'irq-core-2020-10-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (59 commits) dt-bindings: interrupt-controller: Add MStar interrupt controller irqchip/irq-mst: Add MStar interrupt controller support soc/tegra: pmc: Don't create fake interrupt hierarchy levels soc/tegra: pmc: Allow optional irq parent callbacks gpio: tegra186: Allow optional irq parent callbacks genirq/irqdomain: Allow partial trimming of irq_data hierarchy irqchip/qcom-pdc: Reset PDC interrupts during init irqchip/qcom-pdc: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag pinctrl: qcom: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag genirq/PM: Introduce IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag pinctrl: qcom: Use return value from irq_set_wake() call pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags ARM: Handle no IPI being registered in show_ipi_list() MAINTAINERS: Add entries for Actions Semi Owl SIRQ controller irqchip: Add Actions Semi Owl SIRQ controller dt-bindings: interrupt-controller: Add Actions SIRQ controller binding dt-bindings: dw-apb-ictl: Update binding to describe use as primary interrupt controller irqchip/dw-apb-ictl: Add primary interrupt controller support irqchip/dw-apb-ictl: Refactor priot to introducing hierarchical irq domains genirq: Add stub for set_handle_irq() when !GENERIC_IRQ_MULTI_HANDLER ...
2020-10-07pinctrl: amd: Add missing pins to the pin group listShyam Sundar S K1-1/+68
Some of the pins were not exposed in the initial driver or kept as reserved. Exposing all of them now. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20201007111220.744348-1-Shyam-sundar.S-k@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-07pinctrl: visconti: PINCTRL_TMPV7700 should depend on ARCH_VISCONTIGeert Uytterhoeven1-2/+2
The Toshiba Visconti TMPV7700 series pin controller is only present on Visconti SoCs. Hence add a dependency on ARCH_VISCONTI, to prevent asking the user about this driver when configuring a kernel without Visconti platform support. Fixes: a68a7844264e4fb9 ("pinctrl: visconti: Add Toshiba Visconti SoCs pinctrl support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Link: https://lore.kernel.org/r/20201005125049.26926-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-07pinctrl: mediatek: Free eint data on failureEnric Balletbo i Serra1-6/+18
The pinctrl driver can work without the EINT resource, but, if it is expected to have this resource but the mtk_build_eint() function fails after allocating their data (because can't get the resource or can't map the irq), the data is not freed and you end with a NULL pointer dereference. Fix this by freeing the data if mtk_build_eint() fails, so pinctrl still works and doesn't hang. This is noticeable after commit f97dbf48ca43 ("irqchip/mtk-sysirq: Convert to a platform driver") on MT8183 because, due this commit, the pinctrl driver fails to map the irq and spots the following bug: [ 1.947597] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 1.956404] Mem abort info: [ 1.959203] ESR = 0x96000004 [ 1.962259] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.967565] SET = 0, FnV = 0 [ 1.970613] EA = 0, S1PTW = 0 [ 1.973747] Data abort info: [ 1.976619] ISV = 0, ISS = 0x00000004 [ 1.980447] CM = 0, WnR = 0 [ 1.983410] [0000000000000004] user address but active_mm is swapper [ 1.989759] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 1.995322] Modules linked in: [ 1.998371] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc1+ #44 [ 2.004715] Hardware name: MediaTek krane sku176 board (DT) [ 2.010280] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) [ 2.015850] pc : mtk_eint_set_debounce+0x48/0x1b8 [ 2.020546] lr : mtk_eint_set_debounce+0x34/0x1b8 [ 2.025239] sp : ffff80001008baa0 [ 2.028544] x29: ffff80001008baa0 x28: ffff0000ff7ff790 [ 2.033847] x27: ffff0000f9ec34b0 x26: ffff0000f9ec3480 [ 2.039150] x25: ffff0000fa576410 x24: ffff0000fa502800 [ 2.044453] x23: 0000000000001388 x22: ffff0000fa635f80 [ 2.049755] x21: 0000000000000008 x20: 0000000000000000 [ 2.055058] x19: 0000000000000071 x18: 0000000000000001 [ 2.060360] x17: 0000000000000000 x16: 0000000000000000 [ 2.065662] x15: ffff0000facc8470 x14: ffffffffffffffff [ 2.070965] x13: 0000000000000001 x12: 00000000000000c0 [ 2.076267] x11: 0000000000000040 x10: 0000000000000070 [ 2.081569] x9 : ffffaec0063d24d8 x8 : ffff0000fa800270 [ 2.086872] x7 : 0000000000000000 x6 : 0000000000000011 [ 2.092174] x5 : ffff0000fa800248 x4 : ffff0000fa800270 [ 2.097476] x3 : ffff8000100c5000 x2 : 0000000000000000 [ 2.102778] x1 : 0000000000000000 x0 : 0000000000000000 [ 2.108081] Call trace: [ 2.110520] mtk_eint_set_debounce+0x48/0x1b8 [ 2.114870] mtk_gpio_set_config+0x5c/0x78 [ 2.118958] gpiod_set_config+0x5c/0x78 [ 2.122786] gpiod_set_debounce+0x18/0x28 [ 2.126789] gpio_keys_probe+0x50c/0x910 [ 2.130705] platform_drv_probe+0x54/0xa8 [ 2.134705] really_probe+0xe4/0x3b0 [ 2.138271] driver_probe_device+0x58/0xb8 [ 2.142358] device_driver_attach+0x74/0x80 [ 2.146532] __driver_attach+0x58/0xe0 [ 2.150274] bus_for_each_dev+0x70/0xc0 [ 2.154100] driver_attach+0x24/0x30 [ 2.157666] bus_add_driver+0x14c/0x1f0 [ 2.161493] driver_register+0x64/0x120 [ 2.165319] __platform_driver_register+0x48/0x58 [ 2.170017] gpio_keys_init+0x1c/0x28 [ 2.173672] do_one_initcall+0x54/0x1b4 [ 2.177499] kernel_init_freeable+0x1d0/0x238 [ 2.181848] kernel_init+0x14/0x118 [ 2.185328] ret_from_fork+0x10/0x34 [ 2.188899] Code: a9438ac1 12001266 f94006c3 121e766a (b9400421) [ 2.194991] ---[ end trace 168cf7b3324b6570 ]--- [ 2.199611] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2.207260] SMP: stopping secondary CPUs [ 2.211294] Kernel Offset: 0x2ebff4800000 from 0xffff800010000000 [ 2.217377] PHYS_OFFSET: 0xffffb50500000000 [ 2.221551] CPU features: 0x0240002,2188200c [ 2.225811] Memory Limit: none [ 2.228860] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 89132dd8ffd2 ("pinctrl: mediatek: extend eint build to pinctrl-mtk-common-v2.c") Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Sean Wang <sean.wang@kernel.org> Link: https://lore.kernel.org/r/20201001142511.3560143-1-enric.balletbo@collabora.com [rebased on changed infrastructure] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-06pinctrl: qcom: Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flagMaulik Shah1-1/+2
Set IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag to enable/unmask the wakeirqs during suspend entry. Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1601267524-20199-5-git-send-email-mkshah@codeaurora.org
2020-10-06