summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* gpio: gpiolib: fix a doc warningMauro Carvalho Chehab2020-03-271-1/+1
| | | | | | | | | | | | | | | | Use a different markup for the ERR_PTR, as %FOO doesn't work if there are parenthesis. So, use, instead: ``ERR_PTR(-EINVAL)`` This fixes the following warning: ./drivers/gpio/gpiolib.c:139: WARNING: Inline literal start-string without end-string. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/51197e3568f073e22c280f0584bfa20b44436708.1584456635.git.mchehab+huawei@kernel.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: tegra186: Add Tegra194 pin ranges for GG.0 and GG.1Thierry Reding2020-03-271-0/+8
| | | | | | | | | | | | | | | | | | | | | The GG.0 and GG.1 GPIOs serve as CLKREQ and RST pins, respectively, for PCIe controller 5 on Tegra194. When this controller is configured in endpoint mode, these pins need to be used as GPIOs by the PCIe endpoint driver. Typically the mode programming of these pins (GPIO vs. SFIO) is performed by early boot firmware to ensure that the configuration is consistent. However, the GG.0 and GG.1 pins are part of a special power partition that is not enabled during early boot, and hence the early boot firmware cannot program these pins to be GPIOs (they are SFIO by default). Adding them as pin ranges for the pin controller allows the pin controller to be involved when these pins are requested as GPIOs and allows the proper programming to take place. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-4-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: tegra186: Add support for pin rangesThierry Reding2020-03-271-0/+56
| | | | | | | | | | Add support for Tegra SoC generations to specify a list of pin ranges that map GPIOs to ranges of pins in the pin controller. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-3-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: Support GPIO controllers without pin-rangesThierry Reding2020-03-271-1/+4
| | | | | | | | | | | | Wake gpiochip_generic_request() call into the pinctrl helpers only if a GPIO controller had any pin-ranges assigned to it. This allows a driver to unconditionally use this helper if it supports multiple devices of which only a subset have pin-ranges assigned to them. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-2-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: brcmstb: support gpio-line-names propertyDoug Berger2020-03-261-0/+44
| | | | | | | | | | | | | | | | The default handling of the gpio-line-names property by the gpiolib-of implementation does not work with the multiple gpiochip banks per device structure used by the gpio-brcmstb driver. This commit adds driver level support for the device tree property so that GPIO lines can be assigned friendly names. Signed-off-by: Doug Berger <opendmb@gmail.com> Link: https://lore.kernel.org/r/1583780521-45702-1-git-send-email-opendmb@gmail.com Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: gpio_name_to_desc: factor out !name checkMichał Mirosław2020-03-251-1/+4
| | | | | | | | Since name == NULL can't ever match, move the check out of IRQ-disabled region. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: mt7621: add BGPIOF_NO_SET_ON_INPUT flagChuanhong Guo2020-03-251-2/+2
| | | | | | | | | | | DSET/DCLR registers only works on output pins. Add corresponding BGPIOF_NO_SET_ON_INPUT flag to bgpio_init call to fix direction_out behavior. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Tested-by: René van Dorst <opensource@vdorst.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: mmio: introduce BGPIOF_NO_SET_ON_INPUTChuanhong Guo2020-03-251-4/+19
| | | | | | | | | | | | | | | Some gpio controllers ignores pin value writing when that pin is configured as input mode. As a result, bgpio_dir_out should set pin to output before configuring pin values or gpio pin values can't be set up properly. Introduce two variants of bgpio_dir_out: bgpio_dir_out_val_first and bgpio_dir_out_dir_first, and assign direction_output according to a new flag: BGPIOF_NO_SET_ON_INPUT. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Tested-by: René van Dorst <opensource@vdorst.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: mvebu: avoid error message for optional IRQChris Packham2020-03-251-1/+1
| | | | | | | | | | | | | | platform_get_irq() will generate an error message if the requested irq is not present mvebu-gpio f1010140.gpio: IRQ index 3 not found use platform_get_irq_optional() to avoid the error message being generated. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: mxs: add COMPILE_TEST support for GPIO_MXSAnson Huang2020-03-251-1/+1
| | | | | | | | | Add COMPILE_TEST support to GPIO_MXS driver for better compile testing coverage. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: mxc: Add COMPILE_TEST support for GPIO_MXCAnson Huang2020-03-251-1/+1
| | | | | | | | Add COMPILE_TEST support to GPIO_MXC driver for better compile testing coverage. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: pl061: Warn when IRQ line has not been configuredAlexander Sverdlin2020-03-251-4/+2
| | | | | | | | | | | | | Existing (irq < 0) condition is always false because adev->irq has unsigned type and contains 0 in case of failed irq_of_parse_and_map(). Up to now all the mapping errors were silently ignored. Seems that repairing this check would be backwards-incompatible and might break the probe() for the implementations without IRQ support. Therefore warn the user instead. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: Move devres calls to devres fileLinus Walleij2020-03-202-46/+46
| | | | | | | | | | These two devres functions devm_gpiochip_[add|remove]() were in the wrong file. They should be in gpiolib-devres.c not gpiolib.c. Link: https://lore.kernel.org/r/20200313081522.35143-1-linus.walleij@linaro.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* Merge branch 'ib-omap-block-idle' into develLinus Walleij2020-03-091-15/+14
|\
| * Revert "gpio: omap: Fix lost edge wake-up interrupts"Tony Lindgren2020-03-091-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a522f1d0c381c42f3ace13b8bbeeccabdd6d2e5c. With cpu_pm handling fixed for omaps, and with gpio-omap now returning notify error on pending interrupts, we can drop the old workaround for seeing if there may be pending edge interrupts. Depends-on: ARM: OMAP2+: Handle errors for cpu_pm Depends-on: gpio: omap: Block idle on pending gpio interrupts Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpio: omap: Block idle on pending gpio interruptsTony Lindgren2020-03-091-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the SoC cpuidle handling fixed for cpu_pm, we can now start to return NOTIFY_BAD if there there are pending gpio interrupts. This way the deeper SoC idle states can get blocked, and gpio latency is improved in some cases. Note that this will not help with the latency if the SoC has already entered a deeper idle state. Note that this patch depends on cpu_pm properly handling the errors returned by notifiers. For omap variants, this is fixed with patch "ARM: OMAP2+: Handle errors for cpu_pm". Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20200304225433.37336-3-tony@atomide.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: add driver for Mellanox BlueField 2 GPIO controllerAsmaa Mnebhi2020-03-093-0/+343
| | | | | | | | | | | | | | | | | | This patch adds support for the GPIO controller used by Mellanox BlueField 2 SOCs. Signed-off-by: Asmaa Mnebhi <Asmaa@mellanox.com> Link: https://lore.kernel.org/r/1680de9eb6d2b8855228dde9a2dd065f0dcbe1fb.1583182325.git.Asmaa@mellanox.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | Merge tag 'gpio-updates-for-v5.7-part2' of ↵Linus Walleij2020-03-032-10/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel gpio updates for v5.7 part 2 - replace z zero-length array with flexible-array member in gpio-uniphier - make naming of variables consistent in uapi line event code - fix the behavior of line watch/unwatch ioctl()
| * | gpiolib: fix bitmap operations related to line event watchingBartosz Golaszewski2020-03-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When operating on the bits of watched_lines bitmap, we're using desc_to_gpio() which returns the GPIO number from the global numberspace. This leads to all sorts of memory corruptions and invalid behavior. We should switch to using gpio_chip_hwgpio() instead. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Reported-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Kent Gibson <warthog618@gmail.com>
| * | gpiolib: fix unwatch ioctl()Kent Gibson2020-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix the field having a bit cleared by the unwatch ioctl(). Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpiolib: Rename 'event' to 'ge' to be consistent with other useAndy Shevchenko2020-03-021-6/+6
| | | | | | | | | | | | | | | | | | | | | Rename 'event' to 'ge' to be consistent with other use. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: uniphier: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* | | gpiolib: Fix inverted check in gpiochip_remove()Geert Uytterhoeven2020-03-031-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | The optimization to check for requested lines actually optimized for the uncomon error case, where one of the GPIO lines is still in use. Hence the error message must be printed when the loop is terminated early, not when it went through all available GPIO lines. Fixes: 869233f81337bfb3 ("gpiolib: Optimize gpiochip_remove() when check for requested line") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200302082448.11795-1-geert+renesas@glider.be Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpiolib: Optimize gpiochip_remove() when check for requested lineAndy Shevchenko2020-02-281-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here are the following optimizations have been done: - break the loop after first found requested line - due to above, drop redundant boolean variable - replace open coded variant of gpiochip_is_requested() - due to above, drop redundant pointer to struct gpio_desc - use 'unsigned int' instead of 'unsigned' for loop counter Note, pointer to struct gpio_chip followed by pointer to struct gpio_device is still valid, back link is not. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200225114725.839-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: of: Add DT overlay support for GPIO hogsGeert Uytterhoeven2020-02-214-3/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As GPIO hogs are configured at GPIO controller initialization time, adding/removing GPIO hogs in DT overlays does not work. Add support for GPIO hogs described in DT overlays by registering an OF reconfiguration notifier, to handle the addition and removal of GPIO hog subnodes to/from a GPIO controller device node. Note that when a GPIO hog device node is being removed, its "gpios" properties is no longer available, so we have to keep track of which node a hog belongs to, which is done by adding a pointer to the hog's device node to struct gpio_desc. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.be Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: of: Extract of_gpiochip_add_hog()Geert Uytterhoeven2020-02-211-16/+33
| | | | | | | | | | | | | | | | | | | | Extract the code to add all GPIO hogs of a gpio-hog node into its own function, so it can be reused. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200220130149.26283-2-geert+renesas@glider.be Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: Switch timestamps to ktime_get_ns()Linus Walleij2020-02-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing use of ktime_get_real_ns() in the timestamps from the GPIO events is dubious. We have had several discussions about this timestamp, and it is unclear whether userspace has ever taken into account that a timestamp from ktime_get_real_ns() can actually move backwards in time relative the previous timetamp, and userspace is more likely to expect a monotonic counter. Background: https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/ https://marc.info/?l=linux-gpio&m=151661955709074&w=2 The change is ABI incompatible, but incompatible in a way that is IMO more likely to fix future bugs rather than break current userspace. To the best of my knowledge all userspace expects a monotonic timestamp and users are just lucky that they very seldom move backwards in time. Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpiolib: use gpiochip_get_desc() where applicableBartosz Golaszewski2020-02-211-1/+3
| | | | | | | | | | | | | | | | | | Whenever retrieving a descriptor from a gpiochip: use the provided helper which checks for errors. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200219094702.6463-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: siox: use raw spinlock for irq related lockingUwe Kleine-König2020-02-211-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | All the irq related callbacks are called with the (raw) spinlock desc->lock being held. So the lock here must be raw as well. Also irqs were already disabled by the caller for the irq chip callbacks, so the non-irq variants of spin_lock must be used there. Fixes: be8c8facc707 ("gpio: new driver to work with a 8x12 siox") Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Link: https://lore.kernel.org/r/20200211135121.15752-1-uwe@kleine-koenig.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: mockup: coding-style fixBartosz Golaszewski2020-02-201-1/+1
| | | | | | | | | | | | | | | | | | The indentation is wrong in gpio_mockup_apply_pull(). This patch makes the code more readable. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200210155059.29609-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: rcar: Fix typo in commentAshish Chavan2020-02-201-2/+2
| | | | | | | | | | | | | | | | | | "Positive" is spelled incorrectly as "Postive" in comment fix this. Signed-off-by: Ashish Chavan <ashish.gschavan@gmail.com> Link: https://lore.kernel.org/r/20200209095600.16394-1-ashish.gschavan@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpiolib: add new ioctl() for monitoring changes in line infoBartosz Golaszewski2020-02-122-8/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there is no way for user-space to be informed about changes in status of GPIO lines e.g. when someone else requests the line or its config changes. We can only periodically re-read the line-info. This is fine for simple one-off user-space tools, but any daemon that provides a centralized access to GPIO chips would benefit hugely from an event driven line info synchronization. This patch adds a new ioctl() that allows user-space processes to reuse the file descriptor associated with the character device for watching any changes in line properties. Every such event contains the updated line information. Currently the events are generated on three types of status changes: when a line is requested, when it's released and when its config is changed. The first two are self-explanatory. For the third one: this will only happen when another user-space process calls the new SET_CONFIG ioctl() as any changes that can happen from within the kernel (i.e. set_transitory() or set_debounce()) are of no interest to user-space. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* | gpiolib: provide a dedicated function for setting lineinfoBartosz Golaszewski2020-02-121-43/+55
| | | | | | | | | | | | | | | | | | We'll soon be filling out the gpioline_info structure in multiple places. Add a separate function that given a gpio_desc sets all relevant fields. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
* | gpiolib: emit a debug message when adding events to a full kfifoBartosz Golaszewski2020-02-121-0/+2
| | | | | | | | | | | | | | | | Currently if the line-event kfifo is full, we just silently drop any new events. Add a ratelimited debug message so that we at least have some trace in the kernel log of event overflow. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* | gpiolib: rework the locking mechanism for lineevent kfifoBartosz Golaszewski2020-02-121-29/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The read_lock mutex is supposed to prevent collisions between reading and writing to the line event kfifo but it's actually only taken when the events are being read from it. Drop the mutex entirely and reuse the spinlock made available to us in the waitqueue struct. Take the lock whenever the fifo is modified or inspected. Drop the call to kfifo_to_user() and instead first extract the new element from kfifo when the lock is taken and only then pass it on to the user after the spinlock is released. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
* | gpio: wcd934x: Fix logic of wcd_gpio_getAxel Lin2020-02-101-2/+2
| | | | | | | | | | | | | | | | | | | | The check with register value and mask should be & rather than &&. While at it, also use "unsigned int" for value variable because regmap_read() takes unsigned int *val argument. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* | gpio: wcd934x: Don't change gpio direction in wcd_gpio_setAxel Lin2020-02-101-1/+4
| | | | | | | | | | | | | | | | The .set callback should just set output value. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* | gpio: pxa: Avoid a warning when gpio0 and gpio1 IRQS are not thereLubomir Rintel2020-02-101-2/+2
|/ | | | | | | | | | | | Not all platforms use those. Let's use platform_get_irq_byname_optional() instead platform_get_irq_byname() so that we avoid a useless warning: [ 1.359455] pxa-gpio d4019000.gpio: IRQ gpio0 not found [ 1.359583] pxa-gpio d4019000.gpio: IRQ gpio1 not found Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* Merge tag 'kbuild-v5.6-2' of ↵Linus Torvalds2020-02-104-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild updates from Masahiro Yamada: - fix randconfig to generate a sane .config - rename hostprogs-y / always to hostprogs / always-y, which are more natual syntax. - optimize scripts/kallsyms - fix yes2modconfig and mod2yesconfig - make multiple directory targets ('make foo/ bar/') work * tag 'kbuild-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: make multiple directory targets work kconfig: Invalidate all symbols after changing to y or m. kallsyms: fix type of kallsyms_token_table[] scripts/kallsyms: change table to store (strcut sym_entry *) scripts/kallsyms: rename local variables in read_symbol() kbuild: rename hostprogs-y/always to hostprogs/always-y kbuild: fix the document to use extra-y for vmlinux.lds kconfig: fix broken dependency in randconfig-generated .config
| * kbuild: rename hostprogs-y/always to hostprogs/always-yMasahiro Yamada2020-02-034-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In old days, the "host-progs" syntax was used for specifying host programs. It was renamed to the current "hostprogs-y" in 2004. It is typically useful in scripts/Makefile because it allows Kbuild to selectively compile host programs based on the kernel configuration. This commit renames like follows: always -> always-y hostprogs-y -> hostprogs So, scripts/Makefile will look like this: always-$(CONFIG_BUILD_BIN2C) += ... always-$(CONFIG_KALLSYMS) += ... ... hostprogs := $(always-y) $(always-m) I think this makes more sense because a host program is always a host program, irrespective of the kernel configuration. We want to specify which ones to compile by CONFIG options, so always-y will be handier. The "always", "hostprogs-y", "hostprogs-m" will be kept for backward compatibility for a while. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* | irqchip/gic-v4.1: Avoid 64bit division for the sake of 32bit ARMMarc Zyngier2020-02-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In order to allow the GICv4 code to link properly on 32bit ARM, make sure we don't use 64bit divisions when it isn't strictly necessary. Fixes: 4e6437f12d6e ("irqchip/gic-v4.1: Ensure L2 vPE table is allocated at RD level") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge tag 'irq-urgent-2020-02-09' of ↵Linus Torvalds2020-02-093-24/+109
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull interrupt fixes from Thomas Gleixner: "A set of fixes for the interrupt subsystem: - Provision only ACPI enabled redistributors on GICv3 - Use the proper command colums when building the INVALL command for the GICv3-ITS - Ensure the allocation of the L2 vPE table for GICv4.1 - Correct the GICv4.1 VPROBASER programming so it uses the proper size - A set of small GICv4.1 tidy up patches - Configuration cleanup for C-SKY interrupt chip - Clarify the function documentation for irq_set_wake() to document that the wakeup functionality is orthogonal to the irq disable/enable mechanism" * tag 'irq-urgent-2020-02-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Rename VPENDBASER/VPROPBASER accessors irqchip/gic-v3-its: Remove superfluous WARN_ON irqchip/gic-v4.1: Drop 'tmp' in inherit_vpe_l1_table_from_rd() irqchip/gic-v4.1: Ensure L2 vPE table is allocated at RD level irqchip/gic-v4.1: Set vpe_l1_base for all redistributors irqchip/gic-v4.1: Fix programming of GICR_VPROPBASER_4_1_SIZE genirq: Clarify that irq wake state is orthogonal to enable/disable irqchip/gic-v3-its: Reference to its_invall_cmd descriptor when building INVALL irqchip: Some Kconfig cleanup for C-SKY irqchip/gic-v3: Only provision redistributors that are enabled in ACPI
| * \ Merge tag 'irqchip-fixes-5.6-1' of ↵Thomas Gleixner2020-02-083-24/+109
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes for 5.6, take #1 from Marc Zyngier: - Guarantee allocation of L2 vPE table for GICv4.1 - Fix GICv4.1 VPROPBASER programming - Numerous GICv4.1 tidy ups - Fix disabled GICv3 redistributor provisioning with ACPI - KConfig cleanup for C-SKY
| | * | irqchip/gic-v3-its: Rename VPENDBASER/VPROPBASER accessorsZenghui Yu2020-02-081-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V{PEND,PROP}BASER registers are actually located in VLPI_base frame of the *redistributor*. Rename their accessors to reflect this fact. No functional changes. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200206075711.1275-7-yuzenghui@huawei.com
| | * | irqchip/gic-v3-its: Remove superfluous WARN_ONZenghui Yu2020-02-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "ITS virtual pending table not cleaning" is already complained inside its_clear_vpend_valid(), there's no need to trigger a WARN_ON again. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200206075711.1275-6-yuzenghui@huawei.com
| | * | irqchip/gic-v4.1: Drop 'tmp' in inherit_vpe_l1_table_from_rd()Zenghui Yu2020-02-081-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The variable 'tmp' in inherit_vpe_l1_table_from_rd() is actually not needed, drop it. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200206075711.1275-5-yuzenghui@huawei.com
| | * | irqchip/gic-v4.1: Ensure L2 vPE table is allocated at RD levelZenghui Yu2020-02-081-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In GICv4, we will ensure that level2 vPE table memory is allocated for the specified vpe_id on all v4 ITS, in its_alloc_vpe_table(). This still works well for the typical GICv4.1 implementation, where the new vPE table is shared between the ITSs and the RDs. To make it explicit, let us introduce allocate_vpe_l2_table() to make sure that the L2 tables are allocated on all v4.1 RDs. We're likely not need to allocate memory in it because the vPE table is shared and (L2 table is) already allocated at ITS level, except for the case where the ITS doesn't share anything (say SVPET == 0, practically unlikely but architecturally allowed). The implementation of allocate_vpe_l2_table() is mostly copied from its_alloc_table_entry(). Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200206075711.1275-4-yuzenghui@huawei.com
| | * | irqchip/gic-v4.1: Set vpe_l1_base for all redistributorsZenghui Yu2020-02-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we will not set vpe_l1_page for the current RD if we can inherit the vPE configuration table from another RD (or ITS), which results in an inconsistency between RDs within the same CommonLPIAff group. Let's rename it to vpe_l1_base to indicate the base address of the vPE configuration table of this RD, and set it properly for *all* v4.1 redistributors. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200206075711.1275-3-yuzenghui@huawei.com
| | * | irqchip/gic-v4.1: Fix programming of GICR_VPROPBASER_4_1_SIZEZenghui Yu2020-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Size field of GICv4.1 VPROPBASER register indicates number of pages minus one and together Page_Size and Size control the vPEID width. Let's respect this requirement of the architecture. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200206075711.1275-2-yuzenghui@huawei.com
| | * | irqchip/gic-v3-its: Reference to its_invall_cmd descriptor when building INVALLZenghui Yu2020-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It looks like an obvious mistake to use its_mapc_cmd descriptor when building the INVALL command block. It so far worked by luck because both its_mapc_cmd.col and its_invall_cmd.col sit at the same offset of the ITS command descriptor, but we should not rely on it. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191202071021.1251-1-yuzenghui@huawei.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-30 17:16:02 +0100