1. 29 4月, 2014 22 次提交
  2. 19 4月, 2014 1 次提交
  3. 14 4月, 2014 3 次提交
    • M
      gpio / ACPI: Prevent potential wrap of GPIO value on OpRegion read · b5539fa2
      Mika Westerberg 提交于
      Dan Carpenter's static code checker reports:
      
       The patch 473ed7be: "gpio / ACPI: Add support for ACPI GPIO
       operation regions" from Mar 14, 2014, leads to the following static
       checker warning:
      
        drivers/gpio/gpiolib-acpi.c:454 acpi_gpio_adr_space_handler()
        warn: should 'gpiod_get_raw_value(desc) << i' be a 64 bit type?
      
      This is due the fact that *value is of type u64 and gpiod_get_raw_value()
      returns int. Since i can be larger than 31, it is possible that the value
      returned gets wrapped.
      
      Fix this by casting the return of gpiod_get_raw_value() to u64 first before
      shift.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      b5539fa2
    • M
      gpio / ACPI: Don't crash on NULL chip->dev · e9595f84
      Mika Westerberg 提交于
      Commit aa92b6f6 (gpio / ACPI: Allocate ACPI specific data directly in
      acpi_gpiochip_add()) moved ACPI handle checking to acpi_gpiochip_add() but
      forgot to check whether chip->dev is NULL before dereferencing it.
      
      Since chip->dev pointer is optional we can end up with crash like following:
      
       BUG: unable to handle kernel NULL pointer dereference at 00000138
       IP: [<c126c2b3>] acpi_gpiochip_add+0x13/0x190
       *pde = 00000000
       Oops: 0000 [#1] PREEMPT SMP
       Modules linked in: ssb(+) ...
       CPU: 0 PID: 512 Comm: modprobe Tainted: G        W     3.14.0-rc7-next-20140324-t1 #24
       Hardware name: Dell Inc. Latitude D830                   /0UY141, BIOS A02 06/07/2007
       task: f5799900 ti: f543e000 task.ti: f543e000
       EIP: 0060:[<c126c2b3>] EFLAGS: 00010282 CPU: 0
       EIP is at acpi_gpiochip_add+0x13/0x190
       EAX: 00000000 EBX: f57824c4 ECX: 00000000 EDX: 00000000
       ESI: f57824c4 EDI: 00000010 EBP: f543fc54 ESP: f543fc40
        DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
       CR0: 8005003b CR2: 00000138 CR3: 355f8000 CR4: 000007d0
       Stack:
        f543fc5c fd1f7790 f57824c4 000000be 00000010 f543fc84 c1269f4e f543fc74
        fd1f78bd 00008002 f57822b0 f5782090 fd1f8400 00000286 fd1f9994 00000000
        f5782000 f543fc8c fd1f7e39 f543fcc8 fd1f0bd8 000000c0 00000000 00000000
       Call Trace:
        [<fd1f7790>] ? ssb_pcie_mdio_write+0xa0/0xd0 [ssb]
        [<c1269f4e>] gpiochip_add+0xee/0x300
        [<fd1f78bd>] ? ssb_pcicore_serdes_workaround+0xfd/0x140 [ssb]
        [<fd1f7e39>] ssb_gpio_init+0x89/0xa0 [ssb]
        [<fd1f0bd8>] ssb_attach_queued_buses+0xc8/0x2d0 [ssb]
        [<fd1f0f65>] ssb_bus_register+0x185/0x1f0 [ssb]
        [<fd1f3120>] ? ssb_pci_xtal+0x220/0x220 [ssb]
        [<fd1f106c>] ssb_bus_pcibus_register+0x2c/0x80 [ssb]
        [<fd1f40dc>] ssb_pcihost_probe+0x9c/0x110 [ssb]
        [<c1276c8f>] pci_device_probe+0x6f/0xc0
        [<c11bdb55>] ? sysfs_create_link+0x25/0x40
        [<c131d8b9>] driver_probe_device+0x79/0x360
        [<c1276512>] ? pci_match_device+0xb2/0xc0
        [<c131dc51>] __driver_attach+0x71/0x80
        [<c131dbe0>] ? __device_attach+0x40/0x40
        [<c131bd87>] bus_for_each_dev+0x47/0x80
        [<c131d3ae>] driver_attach+0x1e/0x20
        [<c131dbe0>] ? __device_attach+0x40/0x40
        [<c131d007>] bus_add_driver+0x157/0x230
        [<c131e219>] driver_register+0x59/0xe0
        ...
      
      Fix this by checking chip->dev pointer against NULL first. Also we can now
      remove redundant check in acpi_gpiochip_request/free_interrupts().
      Reported-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NSabrina Dubroca <sd@queasysnail.net>
      Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
      Tested-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      e9595f84
    • L
      gpio: set data first, then chip and handler · 7633fb95
      Linus Walleij 提交于
      During irq mapping, in irq_set_chip_and_handler() the process
      of setting this up may incur calls to lock the irqchip, which
      in turn may need to dereference and use the chip data. So set
      the data first, then set the chip and handler.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7633fb95
  4. 01 4月, 2014 1 次提交
  5. 29 3月, 2014 3 次提交
  6. 27 3月, 2014 6 次提交
    • D
      pch_gpio: set value before enabling output direction · 2ddf6cd6
      Daniel Krueger 提交于
      This ensures that the output signal does not toggle if set to high.
      Signed-off-by: NDaniel Krueger <daniel.krueger@systec-electronic.com>
      Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      2ddf6cd6
    • A
      gpio: moxart: Actually set output state in moxart_gpio_direction_output() · fc860356
      Axel Lin 提交于
      moxart_gpio_direction_output() ignored the state passed into it. Fix it.
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      fc860356
    • A
      gpio: moxart: Avoid forward declaration · c9e8dbad
      Axel Lin 提交于
      Slightly adjust the code to avoid forward declaration as we need to call
      moxart_gpio_set() in moxart_gpio_direction_output() to properly set the
      output state.
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c9e8dbad
    • M
      gpio: mxs: Allow for recursive enable_irq_wake() call · a585f87c
      Marek Vasut 提交于
      The scenario here is that someone calls enable_irq_wake() from somewhere
      in the code. This will result in the lockdep producing a backtrace as can
      be seen below. In my case, this problem is triggered when using the wl1271
      (TI WlCore) driver found in drivers/net/wireless/ti/ .
      
      The problem cause is rather obvious from the backtrace, but let's outline
      the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(),
      which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq()
      calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to
      grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in
      irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not
      marked as recursive, lockdep will spew the stuff below.
      
      We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to
      fix the spew.
      
       =============================================
       [ INFO: possible recursive locking detected ]
       3.10.33-00012-gf06b763-dirty #61 Not tainted
       ---------------------------------------------
       kworker/0:1/18 is trying to acquire lock:
        (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
      
       but task is already holding lock:
        (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&irq_desc_lock_class);
         lock(&irq_desc_lock_class);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       3 locks held by kworker/0:1/18:
        #0:  (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4
        #1:  ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4
        #2:  (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
      
       stack backtrace:
       CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61
       Workqueue: events request_firmware_work_func
       [<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14)
       [<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64)
       [<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104)
       [<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58)
       [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88)
       [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4)
       [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24)
       [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44)
       [<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4)
       [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c)
       [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58)
       [<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4)
       [<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394)
       [<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0)
       [<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34)
       wlcore: loaded
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      a585f87c
    • A
      24016ab6
    • A
      gpio: twl4030: Remove redundant assignment · fd0f885b
      Alexander Shiyan 提交于
      Variable "status" is never used, so remove it and add warning if
      any error happen.
      Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      fd0f885b
  7. 26 3月, 2014 3 次提交
  8. 19 3月, 2014 1 次提交