- 19 9月, 2018 1 次提交
-
-
由 Ricardo Ribalda Delgado 提交于
The current code only frees N-1 gpios if an error occurs during gpiod_set_transitory, gpiod_direction_output or gpiod_direction_input. Leading to gpios that cannot be used by userspace nor other drivers. Cc: Timur Tabi <timur@codeaurora.org> Cc: stable@vger.kernel.org Fixes: ab3dbcf7 ("gpioib: do not free unrequested descriptors) Reported-by: NJan Lorenzen <jl@newtec.dk> Reported-by: NJim Paris <jim@jtan.com> Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 31 8月, 2018 1 次提交
-
-
由 Vincent Whitchurch 提交于
gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list before of_gpiochip_add() is called, but it's only the latter which sets the ->of_xlate function pointer. gpiochip_find() can be called by someone else between these two actions, and it can find the chip and call of_gpiochip_match_node_and_xlate() which leads to the following crash due to a NULL ->of_xlate(). Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000 Modules linked in: leds_gpio(+) gpio_generic(+) CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43 Hardware name: ARM-Versatile Express PC is at (null) LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38 Process insmod (pid: 830, stack limit = 0x(ptrval)) (of_gpiochip_match_node_and_xlate) from (gpiochip_find+0x48/0x84) (gpiochip_find) from (of_get_named_gpiod_flags+0xa8/0x238) (of_get_named_gpiod_flags) from (gpiod_get_from_of_node+0x2c/0xc8) (gpiod_get_from_of_node) from (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144) (devm_fwnode_get_index_gpiod_from_child) from (gpio_led_probe+0x208/0x3c4 [leds_gpio]) (gpio_led_probe [leds_gpio]) from (platform_drv_probe+0x48/0x9c) (platform_drv_probe) from (really_probe+0x1d0/0x3d4) (really_probe) from (driver_probe_device+0x78/0x1c0) (driver_probe_device) from (__driver_attach+0x120/0x13c) (__driver_attach) from (bus_for_each_dev+0x68/0xb4) (bus_for_each_dev) from (bus_add_driver+0x1a8/0x268) (bus_add_driver) from (driver_register+0x78/0x10c) (driver_register) from (do_one_initcall+0x54/0x1fc) (do_one_initcall) from (do_init_module+0x64/0x1f4) (do_init_module) from (load_module+0x2198/0x26ac) (load_module) from (sys_finit_module+0xe0/0x110) (sys_finit_module) from (ret_fast_syscall+0x0/0x54) One way to fix this would be to rework the hairy registration sequence in gpiochip_add_data_with_key(), but since I'd probably introduce a couple of new bugs if I attempted that, simply add a check for a non-NULL of_xlate function pointer in of_gpiochip_match_node_and_xlate(). This works since the driver looking for the gpio will simply fail to find the gpio and defer its probe and be reprobed when the driver which is registering the gpiochip has fully completed its probe. Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 29 8月, 2018 4 次提交
-
-
由 Alexey Khoroshilov 提交于
If dwapb_gpio_add_port() fails in dwapb_gpio_probe(), gpio->clk is left undisabled. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Hans de Goede 提交于
GpioInt ACPI event handlers may see there IRQ triggered immediately after requesting the IRQ (esp. level triggered ones). This means that they may run before any other (builtin) drivers have had a chance to register their OpRegion handlers, leading to errors like this: [ 1.133274] ACPI Error: No handler for Region [PMOP] ((____ptrval____)) [UserDefinedRegion] (20180531/evregion-132) [ 1.133286] ACPI Error: Region UserDefinedRegion (ID=141) has no handler (20180531/exfldio-265) [ 1.133297] ACPI Error: Method parse/execution failed \_SB.GPO2._L01, AE_NOT_EXIST (20180531/psparse-516) We already defer the manual initial trigger of edge triggered interrupts by running it from a late_initcall handler, this commit replaces this with deferring the entire acpi_gpiochip_request_interrupts() call till then, fixing the problem of some OpRegions not being registered yet. Note that this removes the need to have a list of edge triggered handlers which need to run, since the entire acpi_gpiochip_request_interrupts() call is now delayed, acpi_gpiochip_request_interrupt() can call these directly now. Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
The commit ca876c74 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") added a initial value check for pin which is about to be locked as IRQ. Unfortunately, not all GPIO drivers can do that atomically. Thus, switch to cansleep version of the call. Otherwise we have a warning: ... WARNING: CPU: 2 PID: 1408 at drivers/gpio/gpiolib.c:2883 gpiod_get_value+0x46/0x50 ... RIP: 0010:gpiod_get_value+0x46/0x50 ... The change tested on Intel Broxton with Whiskey Cove PMIC GPIO controller. Fixes: ca876c74 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Michael Hennerich 提交于
This fixes: [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug in adp5588_gpio_write() [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug in adp5588_gpio_direction_input() Reported-by: NJia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 11 8月, 2018 9 次提交
-
-
由 Leonid Bloch 提交于
This was tested on actual hardware and found to work fine, but currently the official specifications of this chip could not be obtained to confirm the numbers. Signed-off-by: NLeonid Bloch <lbloch@janustech.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Ivan Podovalov 提交于
The DIO connector on the WAFER-945GSE is interfaced to GPIO ports on the ITE IT8718F Super I/O chipset. From the datasheet of ITE IT8718F, the GPIO interface is identical to IT8728, so just add it to the same case as the other chip. Signed-off-by: NIvan Podovalov <ipodovalov@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Biju Das 提交于
Add a check for unused gpios to avoid chip->request() call to client driver for unused gpios. Signed-off-by: NBiju Das <biju.das@bp.renesas.com> Reviewed-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This is a GPIO driver so include only <linux/gpio/driver.h>. Drop the use of GPIOF_* flags: these are for consumers, not drivers. Just return 0/1. Cc: Stefan Agner <stefan@agner.ch> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: NDmitry Osipenko <digetx@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
The bgpio_init() takes one of two arguments to specify a register to set the direction of the GPIO line: either dirout that indicates that a 1 in the bit in that register sets the corresponding line to output, or dirin which indicates that a 1 in the bit in that register sets the corresponding line to input. Conversely setting the bit to 0 on these will turn the line into input and output respectively. One of these can be defined but not both. This means that a platform that sets a bit to 1 for output only defines dirout and a platform that sets a bit to 0 for output only defines dirin. In short this defines the polarity of the direction register. Both can also be left as NULL meaning the GPIO chip is either input only or output only. Tomer Maimon discovered that for get/set chips (those where the get and set registers are defined but no separate clear register, and specifying BGPIOF_READ_OUTPUT_REG_SET so that we say we want to read the output value from the SET register) we are unconditionally reading the value from the SET register when the direction bit is 1 and from the DAT register when the direction bit is 0, not taking the direction bit polarity into account. It would be expected that when the direction bit is inverted (dirin is defined but not dirout) we read the current value from the DAT register when the bit is 1 and from the SET register when the bit is 0. Currently only some versions of ATH79, brcmstb, some versions of CLP711x, GE, IOP and Loongson use the dirin mode (a 1 in the register means input). They are unaffected because BGPIOF_READ_OUTPUT_REG_SET is not set on any of them. (They do not read back the SET register to figure out the output value.) So this is no regression with current drivers. However the behaviour is wrong and does not work with Tomer's new driver where he needs to use the BGIOF_READ_OUTPUT_REG_SET. This fixes the above issue by: - Instead of defining separate functions for the inverted case, set up a flag in the gpio_chip that indicates that the direction is inverted. - Remove the special inverted functions for setting input/output and getting the direction, rely on the flag instead. - Respect this flag in bgpio_get_set() and bgpio_get_set_multiple() Reported-by: NTomer Maimon <tmaimon77@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This is a GPIO driver so use only <linux/gpio/driver.h>. Acked-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This is a GPIO driver so include only <linux/gpio/driver.h>. Cc: Richard Röjfors <richard.rojfors@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This driver includes the legacy <linux/gpio.h> and <linux/of_gpio.h> but all it needs is really <linux/gpio/driver.h>. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Biju Das 提交于
Some platforms are not setting of_node in the driver. On these platforms defining gpio-reserved-ranges on device tree leads to kernel crash. It is due to some parts of the gpio core relying on the driver to set up of_node,while other parts do themselves.This inconsistent behaviour leads to a crash. gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node as NULL. of_gpiochip_add() fills "of_node" and calls of_gpiochip_init_valid_mask(). The fix is to move the assignment to chip->of_node from of_gpiochip_add() to gpiochip_add_data_with_key(). Signed-off-by: NBiju Das <biju.das@bp.renesas.com> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 07 8月, 2018 9 次提交
-
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, bail out if it fails with corresponding returned code. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, bail out if it fails with corresponding returned code. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, do not shadow them by -ENOSPC and let caller to decide. No functional change intended. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, do not shadow them by -EINVAL and let caller to decide. No functional change intended. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, do not shadow them by -EINVAL and let caller to decide. No functional change intended. Cc: Hoan Tran <hotran@apm.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, do not shadow them by -EINVAL and let caller to decide. No functional change intended. Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
gpiochip_lock_as_irq() may return a few error codes, do not shadow them by -EINVAL and let caller to decide. No functional change intended. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Levin Du 提交于
In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute control, can also be used for general purpose. It is manipulated by the GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI pins can also be set in the same way. Currently this GRF GPIO controller only supports the mute pin. If needed in the future, the HDMI pins support can also be added. Signed-off-by: NLevin Du <djw@t-chip.com.cn> Reviewed-by: NRob Herring <robh@kernel.org> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Janusz Krzysztofik 提交于
This should make applications utilizing whole banks work faster. Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 04 8月, 2018 1 次提交
-
-
由 Dmitry Osipenko 提交于
There is a bug in regards to deferred probing within the drivers core that causes GPIO-driver to suspend after its users. The bug appears if GPIO-driver probe is getting deferred, which happens after introducing dependency on PINCTRL-driver for the GPIO-driver by defining "gpio-ranges" property in device-tree. The bug in the drivers core is old (more than 4 years now) and is well known, unfortunately there is no easy fix for it. The good news is that we can workaround the deferred probe issue by changing GPIO / PINCTRL drivers registration order and hence by moving PINCTRL driver registration to the arch_init level and GPIO to the subsys_init. Signed-off-by: NDmitry Osipenko <digetx@gmail.com> Acked-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 03 8月, 2018 1 次提交
-
-
由 Wei Yongjun 提交于
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpio/gpio-pxa.c: In function "pxa_gpio_probe": drivers/gpio/gpio-pxa.c:629:35: warning: variable "gpio_offset" set but not used [-Wunused-but-set-variable] int irq0 = 0, irq1 = 0, irq_mux, gpio_offset = 0; ^ Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 01 8月, 2018 1 次提交
-
-
由 Benjamin Tissoires 提交于
On some systems using edge triggered ACPI Event Interrupts, the initial state at boot is not setup by the firmware, instead relying on the edge irq event handler running at least once to setup the initial state. 2 known examples of this are: 1) The Surface 3 has its _LID state controlled by an ACPI operation region triggered by a GPIO event: OperationRegion (GPOR, GeneralPurposeIo, Zero, One) Field (GPOR, ByteAcc, NoLock, Preserve) { Connection ( GpioIo (Shared, PullNone, 0x0000, 0x0000, IoRestrictionNone, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x004C } ), HELD, 1 } Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE { If ((HELD == One)) { ^^LID.LIDB = One } Else { ^^LID.LIDB = Zero Notify (LID, 0x80) // Status Change } Notify (^^PCI0.SPI1.NTRG, One) // Device Check } Currently, the state of LIDB is wrong until the user actually closes or open the cover. We need to trigger the GPIO event once to update the internal ACPI state. Coincidentally, this also enables the Surface 2 integrated HID sensor hub which also requires an ACPI gpio operation region to start initialization. 2) Various Bay Trail based tablets come with an external USB mux and TI T1210B USB phy to enable USB gadget mode. The mux is controlled by a GPIO which is controlled by an edge triggered ACPI Event Interrupt which monitors the micro-USB ID pin. When the tablet is connected to a PC (or no cable is plugged in), the ID pin is high and the tablet should be in gadget mode. But the GPIO controlling the mux is initialized by the firmware so that the USB data lines are muxed to the host controller. This means that if the user wants to use gadget mode, the user needs to first plug in a host-cable to force the ID pin low and then unplug it and connect the tablet to a PC, to get the ACPI event handler to run and switch the mux to device mode, This commit fixes both by running the event-handler once on boot. Note that the running of the event-handler is done from a late_initcall, this is done because the handler AML code may rely on OperationRegions registered by other builtin drivers. This avoids errors like these: [ 0.133026] ACPI Error: No handler for Region [XSCG] ((____ptrval____)) [GenericSerialBus] (20180531/evregion-132) [ 0.133036] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180531/exfldio-265) [ 0.133046] ACPI Error: Method parse/execution failed \_SB.GPO2._E12, AE_NOT_EXIST (20180531/psparse-516) Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> [hdegoede: Document BYT USB mux reliance on initial trigger] [hdegoede: Run event handler from a late_initcall, rather then immediately] Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 30 7月, 2018 10 次提交
-
-
由 Vincent Prince 提交于
From the datasheet, the GPIO interface is identical to IT8728 (same description), so just add it to the same case as the other chip. Signed-off-by: NVincent Prince <vincent.prince.fr@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Stefan Agner 提交于
Since commit e45d1c80 ("gpio: put GPIO IRQs into their own lock class") and commit a0a8bcf4 ("gpiolib: irqchip: use different lockdep class for each gpio irqchip") GPIO lib takes care of lockdep classes. In fact, gpiochip_irq_map() overwrites the class anyway, so the lockdep class set by the driver is useless. Remove it. Signed-off-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 zhong jiang 提交于
Fix the following sparse error: drivers/gpio/gpio-ath79.c:54:16: error: return expression in void function Signed-off-by: Nzhong jiang <zhongjiang@huawei.com> Acked-by: NAlban Bedel <albeu@free.fr> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Fabio Estevam 提交于
There is no need for splitting the writel() call in two lines. Make it fit into a single line instead. Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Daniel Mack 提交于
The pxa3xx driver uses the pinctrl-single driver since a while which does not implement a .gpio_set_direction() callback. The pinmux core will simply return 0 in this case, and the pxa3xx gpio driver hence believes the pinctrl driver did its job and returns as well. This effectively makes pxa_gpio_direction_{input,output} no-ops. To fix this, do not call into the pinctrl subsystem for the PXA3xx platform for now. We can revert this once the pinctrl-single driver learned to support setting pin directions. Signed-off-by: NDaniel Mack <daniel@zonque.org> Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Anton Vasilyev 提交于
If ioh_gpio_probe() fails on devm_irq_alloc_descs() then chip may point to any element of chip_save array, so reverse iteration from pointer chip may become chip_save[-1] and gpiochip_remove() will operate with wrong memory. The patch fix the error path of ioh_gpio_probe() to correctly bypass chip_save array. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAnton Vasilyev <vasilyev@ispras.ru> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Marcel Ziswiler 提交于
Actually report the error code from devm_regulator_get() which may as well just be a probe deferral. This is e.g. what one gets upon booting a Colibri T20: gpiochip_add_data_with_key: GPIOs 0..223 (tegra-gpio) failed to register Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Dmitry Osipenko 提交于
Commit 36b31279 ("gpiolib: Respect error code of ->get_direction()") broke tegra_gpio_irq_set_type() because requesting of GPIO direction must be done after enabling GPIO function for a pin. This patch fixes drivers probe failure like this: gpio gpiochip0: (tegra-gpio): gpiochip_lock_as_irq: cannot get GPIO direction tegra-gpio 6000d000.gpio: unable to lock Tegra GPIO 144 as IRQ Fixes: 36b31279 ("gpiolib: Respect error code of ->get_direction()") Signed-off-by: NDmitry Osipenko <digetx@gmail.com> Acked-by: NJon Hunter <jonathanh@nvidia.com> Tested-by: NJon Hunter <jonathanh@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Anson Huang 提交于
GPIO registers could lose context on i.MX7D, when enter LPSR mode, the whole SoC will be powered off except LPSR domain, GPIO banks will lose context in this case, need to restore the context after resume from LPSR mode. This patch adds new compatible string for i.MX7D which supports GPIO power off feature in suspend, and adds the GPIO save/restore operations in noirq suspend/resume phase, since GPIO is fundamental module which could be used by other peripherals' resume phase. Signed-off-by: NAnson Huang <Anson.Huang@nxp.com> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Morten Hein Tiljeset 提交于
Signed-off-by: NMorten Hein Tiljeset <morten.tiljeset@prevas.dk> Reviewed-by: NSean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 24 7月, 2018 2 次提交
-
-
由 Masahiro Yamada 提交于
If a GPIO chip is a part of a hierarchy IRQ domain, there is no way to specify the trigger type when gpio(d)_to_irq() allocates an interrupt on-the-fly. Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes an error in the .alloc() hook of the parent domain. (drivers/irq/irq-uniphier-aidet.c) Even if we change irq-uniphier-aidet.c to accept the NONE type, GIC complains about it since commit 83a86fbb ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE"). Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq is allocated. irq_set_irq_type() will override it when the irq is really requested. Fixes: dbe776c2 ("gpio: uniphier: add UniPhier GPIO controller driver") Reported-by: NKatsuhiro Suzuki <suzuki.katsuhiro@socionext.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NKatsuhiro Suzuki <suzuki.katsuhiro@socionext.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
This fixes up the handling of fixed regulator polarity inversion flags: while I remembered to fix it for the undocumented "reg-fixed-voltage" I forgot about the official "regulator-fixed" binding, there are two ways to do a fixed regulator. The error was noticed and fixed. Fixes: a603a2b8 ("gpio: of: Add special quirk to parse regulator flags") Cc: Mark Brown <broonie@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Reported-by: NThierry Reding <thierry.reding@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 23 7月, 2018 1 次提交
-
-
由 Sakari Ailus 提交于
Convert all users of struct acpi_reference_args to more generic fwnode_reference_args. This will 1) avoid an ACPI specific references to device nodes with integer arguments as well as 2) allow making references to nodes other than device nodes in ACPI. As a by-product, convert the fwnode interger arguments to u64. The arguments were 64-bit integers on ACPI but the fwnode arguments were just 32-bit. Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-