1. 26 8月, 2015 8 次提交
  2. 25 8月, 2015 1 次提交
  3. 17 8月, 2015 3 次提交
    • G
      gpiolib: irqchip: use different lockdep class for each gpio irqchip · a0a8bcf4
      Grygorii Strashko 提交于
      Since IRQ chip helpers were introduced drivers lose ability to
      register separate lockdep classes for each registered GPIO IRQ
      chip and the gpiolib now is using shared lockdep class for
      all GPIO IRQ chips (gpiochip_irq_lock_class).
      As result, lockdep will produce warning when there are min two
      stacked GPIO chips and all of them are interrupt controllers.
      
      HW configuration which generates lockdep warning (TI dra7-evm):
      
      [SOC GPIO bankA.gpioX]
        <- irq - [pcf875x.gpioY]
                  <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
      The issue was reported in [1] and discussed [2].
      
      =============================================
      [ INFO: possible recursive locking detected ]
      4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
      ---------------------------------------------
      sh/63 is trying to acquire lock:
       (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
      
      but task is already holding lock:
       (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(class);
        lock(class);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      7 locks held by sh/63:
       #0:  (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164
       #1:  (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0
       #2:  (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0
       #3:  (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4
       #4:  (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398
       #5:  (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94
       #6:  (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94
      
      stack backtrace:
      CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
      Hardware name: Generic DRA74X (Flattened Device Tree)
      [<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14)
      [<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c)
      [<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20)
      [<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128)
      [<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c)
      [<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94)
      [<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc)
      [<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54)
      [<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc)
      [<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4)
      [<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124)
      [<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398)
      [<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4)
      [<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728)
      [<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4)
      [<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8)
      [<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0)
      [<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8)
      [<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164)
      [<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c)
      [<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
      
      Lets fix it by using separate lockdep class for each registered GPIO
      IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.
      
      The implementation of this patch inspired by solution done by Nicolas
      Boichat for regmap [3]
      
      [1] http://www.spinics.net/lists/linux-gpio/msg05844.html
      [2] http://www.spinics.net/lists/linux-gpio/msg06021.html
      [3] http://www.spinics.net/lists/arm-kernel/msg429834.html
      
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roger Quadros <rogerq@ti.com>
      Reported-by: NRoger Quadros <rogerq@ti.com>
      Tested-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      a0a8bcf4
    • A
      gpio/grgpio: fix deadlock in grgpio_irq_unmap() · 7fa25937
      Alexandre Courbot 提交于
      As reported by Alexey Khoroshilov:
      
          grgpio_irq_unmap() code looks quite suspicious regarding usage of
          priv->bgc.lock spinlock.
      
          It locks the spinlock in line 310:
      
      	spin_lock_irqsave(&priv->bgc.lock, flags);
      
          and then it can call grgpio_set_imask() in line 317:
      
      	grgpio_set_imask(priv, i, 0);
      
          But grgpio_set_imask() unconditionally locks the spinlock by itself.
      
      Fix this by moving the spinlock acquisition outside of
      grgpio_set_imask().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Reported-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
      Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
      Cc: Andreas Larsson <andreas@gaisler.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7fa25937
    • D
      Documentation: gpio: consumer: describe active low property · ac49fbd1
      Dirk Behme 提交于
      I've been searching for any documentation of 'the active-low property of a GPIO'
      already mentioned in this documenation. But couldn't find any. Add it.
      Sigend-off-by: NDirk Behme <dirk.behme@gmail.com>
      Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
      [Spelling, grammar fixes]
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ac49fbd1
  4. 13 8月, 2015 7 次提交
    • D
      gpio: mxc: fix section mismatch warning · 929550b9
      Dirk Behme 提交于
      Fix the section mismatch warning
      
      WARNING: vmlinux.o(.text+0x2b2788): Section mismatch in reference from the function mxc_gpio_probe() to the function .init.text:mxc_gpio_init_gc()
      The function mxc_gpio_probe() references
      the function __init mxc_gpio_init_gc().
      This is often because mxc_gpio_probe lacks a __init
      annotation or the annotation of mxc_gpio_init_gc is wrong.
      Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      929550b9
    • U
      gpio/mxc: mask gpio interrupts in suspend · 952cfbd3
      Ulises Brindis 提交于
      Currently in the FSL platform all GPIO interrupts in a bank are muxed
      into two GPIO lines to the GPC interrupt controller. In each GPIO bank
      GPIOs 0-15 are OR'ed into one GPC interrupt controller interrupt and 16-31
      are OR'ed into another. With the current code, if any of the 0-15 or
      16-31 interrupts are marked as wakeup capable, all interrupts belonging
      to that sub-bank (either 0-15 or 16-31) will wake up the device. This is
      because interrupts are only being masked at the interrupt controller
      and not at the GPIO controller.
      
      This patch allows masking of GPIO interrupts at the GPIO controller during
      suspend if they have not been labeled wakeup capable. This patch uses
      preexisting IRQCHIP_MASK_ON_SUSPEND flag while initializing the GPIO
      interrupts to get the desired behavior.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: NUlises Brindis <ubrindis56@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      952cfbd3
    • A
      gpio: omap: Fix missing raw locks conversion · 627c89b4
      Axel Lin 提交于
      Fix below build warning:
        CC      drivers/gpio/gpio-omap.o
      drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_type':
      drivers/gpio/gpio-omap.c:504:3: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type [enabled by default]
      include/linux/spinlock.h:360:29: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
      
      Fixes: commit 4dbada2b ("gpio: omap: use raw locks for locking")
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      627c89b4
    • L
      Merge tag 'v4.2-rc4' into devel · 5f6f02cd
      Linus Walleij 提交于
      Linux 4.2-rc4
      5f6f02cd
    • G
      gpio: brcmstb: support wakeup from S5 cold boot · 3afa129a
      Gregory Fong 提交于
      For wake from S5, we need to:
      - register a reboot handler
      - set wakeup capability before requesting IRQ so wakeup count is
        incremented
      - mask all GPIO IRQs and clear any pending interrupts during driver
        probe to since no driver will yet be registered to handle any IRQs
        carried over from boot at that time, and it's possible that the
        booted kernel does not request the same IRQ anyway.
      
      This means that /sys/.../power/wakeup_count is valid at boot time, and
      we can properly account for S5 wakeup stats. e.g.:
      
        ### After waking from S5 from a GPIO key
        # cat /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup
        enabled
        # cat /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup_count
        1
      Signed-off-by: NGregory Fong <gregory.0xf0@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3afa129a
    • G
      gpio: brcmstb: Add interrupt and wakeup source support · 19a7b694
      Gregory Fong 提交于
      Uses the gpiolib irqchip helpers.  For this to work, the irq setup
      function is called once per bank instead of once per device.  Note
      that all known uses of this block have a BCM7120 L2 interrupt
      controller as a parent.  Supports interrupts for all GPIOs.
      
      In the IRQ handler, we check for raised IRQs for invalid GPIOs and
      warn (ratelimited) if they're encountered.
      
      Also, several drivers (e.g. gpio-keys) allow for GPIOs to be
      configured as wakeup sources, and this GPIO controller supports that
      through a separate interrupt path.
      
      The de-facto standard DT property "wakeup-source" is checked, since
      that indicates whether the GPIO controller hardware can wake.  Uses
      the IRQCHIP_MASK_ON_SUSPEND irq_chip flag because UPG GIO doesn't have
      any of its own wakeup source configuration.
      
      Aside regarding gpiolib irqchip helpers: It wasn't obvious (to me)
      that you can have multiple chained irqchips and associated IRQ domains
      for a single parent IRQ, and as long as the xlate function is written
      correctly, a GPIO IRQ request end up checking the correct domain and
      will get associated with the correct IRQ.  What helps make this clear
      is to read
        drivers/gpio/gpiolib-of.c:
         - of_gpiochip_find_and_xlate()
         - of_get_named_gpiod_flags()
        drivers/gpio/gpiolib.c:
         - gpiochip_find()
      Signed-off-by: NGregory Fong <gregory.0xf0@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      19a7b694
    • L
      gpio/ABI: document what is already the case · 77a775b7
      Linus Walleij 提交于
      commit 926b663c
      "gpiolib: allow GPIOs to be named" added the ability to
      name GPIO lines by an array of names stored in the GPIO
      chip. This was in 2009 and has been an ABI since. Let's
      document it properly.
      
      Cc: Daniel Silverstone <dsilvers@digital-scurf.org>
      Cc: Markus Pargmann <mpa@pengutronix.de>
      Cc: Johan Hovold <johan@kernel.org>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      77a775b7
  5. 03 8月, 2015 2 次提交
  6. 28 7月, 2015 3 次提交
  7. 27 7月, 2015 13 次提交
  8. 26 7月, 2015 3 次提交
    • T
      x86/mm/pat: Revert 'Adjust default caching mode translation tables' · 1a4e8795
      Thomas Gleixner 提交于
      Toshi explains:
      
      "No, the default values need to be set to the fallback types,
       i.e. minimal supported mode.  For WC and WT, UC is the fallback type.
      
       When PAT is disabled, pat_init() does update the tables below to
       enable WT per the default BIOS setup.  However, when PAT is enabled,
       but CPU has PAT -errata, WT falls back to UC per the default values."
      
      Revert: ca1fec58 'x86/mm/pat: Adjust default caching mode translation tables'
      Requested-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Jan Beulich <jbeulich@suse.de>
      Link: http://lkml.kernel.org/r/1437577776.3214.252.camel@hp.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1a4e8795
    • M
      perf/x86/intel/cqm: Return cached counter value from IRQ context · 2c534c0d
      Matt Fleming 提交于
      Peter reported the following potential crash which I was able to
      reproduce with his test program,
      
      [  148.765788] ------------[ cut here ]------------
      [  148.765796] WARNING: CPU: 34 PID: 2840 at kernel/smp.c:417 smp_call_function_many+0xb6/0x260()
      [  148.765797] Modules linked in:
      [  148.765800] CPU: 34 PID: 2840 Comm: perf Not tainted 4.2.0-rc1+ #4
      [  148.765803]  ffffffff81cdc398 ffff88085f105950 ffffffff818bdfd5 0000000000000007
      [  148.765805]  0000000000000000 ffff88085f105990 ffffffff810e413a 0000000000000000
      [  148.765807]  ffffffff82301080 0000000000000022 ffffffff8107f640 ffffffff8107f640
      [  148.765809] Call Trace:
      [  148.765810]  <NMI>  [<ffffffff818bdfd5>] dump_stack+0x45/0x57
      [  148.765818]  [<ffffffff810e413a>] warn_slowpath_common+0x8a/0xc0
      [  148.765822]  [<ffffffff8107f640>] ? intel_cqm_stable+0x60/0x60
      [  148.765824]  [<ffffffff8107f640>] ? intel_cqm_stable+0x60/0x60
      [  148.765825]  [<ffffffff810e422a>] warn_slowpath_null+0x1a/0x20
      [  148.765827]  [<ffffffff811613f6>] smp_call_function_many+0xb6/0x260
      [  148.765829]  [<ffffffff8107f640>] ? intel_cqm_stable+0x60/0x60
      [  148.765831]  [<ffffffff81161748>] on_each_cpu_mask+0x28/0x60
      [  148.765832]  [<ffffffff8107f6ef>] intel_cqm_event_count+0x7f/0xe0
      [  148.765836]  [<ffffffff811cdd35>] perf_output_read+0x2a5/0x400
      [  148.765839]  [<ffffffff811d2e5a>] perf_output_sample+0x31a/0x590
      [  148.765840]  [<ffffffff811d333d>] ? perf_prepare_sample+0x26d/0x380
      [  148.765841]  [<ffffffff811d3497>] perf_event_output+0x47/0x60
      [  148.765843]  [<ffffffff811d36c5>] __perf_event_overflow+0x215/0x240
      [  148.765844]  [<ffffffff811d4124>] perf_event_overflow+0x14/0x20
      [  148.765847]  [<ffffffff8107e7f4>] intel_pmu_handle_irq+0x1d4/0x440
      [  148.765849]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765853]  [<ffffffff81219bad>] ? vunmap_page_range+0x19d/0x2f0
      [  148.765854]  [<ffffffff81219d11>] ? unmap_kernel_range_noflush+0x11/0x20
      [  148.765859]  [<ffffffff814ce6fe>] ? ghes_copy_tofrom_phys+0x11e/0x2a0
      [  148.765863]  [<ffffffff8109e5db>] ? native_apic_msr_write+0x2b/0x30
      [  148.765865]  [<ffffffff8109e44d>] ? x2apic_send_IPI_self+0x1d/0x20
      [  148.765869]  [<ffffffff81065135>] ? arch_irq_work_raise+0x35/0x40
      [  148.765872]  [<ffffffff811c8d86>] ? irq_work_queue+0x66/0x80
      [  148.765875]  [<ffffffff81075306>] perf_event_nmi_handler+0x26/0x40
      [  148.765877]  [<ffffffff81063ed9>] nmi_handle+0x79/0x100
      [  148.765879]  [<ffffffff81064422>] default_do_nmi+0x42/0x100
      [  148.765880]  [<ffffffff81064563>] do_nmi+0x83/0xb0
      [  148.765884]  [<ffffffff818c7c0f>] end_repeat_nmi+0x1e/0x2e
      [  148.765886]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765888]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765890]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765891]  <<EOE>>  [<ffffffff8110ab66>] finish_task_switch+0x156/0x210
      [  148.765898]  [<ffffffff818c1671>] __schedule+0x341/0x920
      [  148.765899]  [<ffffffff818c1c87>] schedule+0x37/0x80
      [  148.765903]  [<ffffffff810ae1af>] ? do_page_fault+0x2f/0x80
      [  148.765905]  [<ffffffff818c1f4a>] schedule_user+0x1a/0x50
      [  148.765907]  [<ffffffff818c666c>] retint_careful+0x14/0x32
      [  148.765908] ---[ end trace e33ff2be78e14901 ]---
      
      The CQM task events are not safe to be called from within interrupt
      context because they require performing an IPI to read the counter value
      on all sockets. And performing IPIs from within IRQ context is a
      "no-no".
      
      Make do with the last read counter value currently event in
      event->count when we're invoked in this context.
      Reported-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vikas Shivappa <vikas.shivappa@intel.com>
      Cc: Kanaka Juvva <kanaka.d.juvva@intel.com>
      Cc: Will Auld <will.auld@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1437490509-15373-1-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2c534c0d
    • L
      Merge tag 'usb-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 26ae19a3
      Linus Torvalds 提交于
      Pull USB fixes from Greg KH:
       "Here's a few USB and PHY fixes for 4.2-rc4.
      
        Nothing major, the shortlog has the full details.
      
        All of these have been in linux-next successfully"
      
      * tag 'usb-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (21 commits)
        USB: OHCI: fix bad #define in ohci-tmio.c
        cdc-acm: Destroy acm_minors IDR on module exit
        usb-storage: Add ignore-device quirk for gm12u320 based usb mini projectors
        usb-storage: ignore ZTE MF 823 card reader in mode 0x1225
        USB: OHCI: Fix race between ED unlink and URB submission
        usb: core: lpm: set lpm_capable for root hub device
        xhci: do not report PLC when link is in internal resume state
        xhci: prevent bus_suspend if SS port resuming in phase 1
        xhci: report U3 when link is in resume state
        xhci: Calculate old endpoints correctly on device reset
        usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function
        xhci: Workaround to get D3 working in Intel xHCI
        xhci: call BIOS workaround to enable runtime suspend on Intel Braswell
        usb: dwc3: Reset the transfer resource index on SET_INTERFACE
        usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU
        usb: gadget: mv_udc_core: fix phy_regs I/O memory leak
        usb: ulpi: ulpi_init should be executed in subsys_initcall
        phy: berlin-usb: fix divider for BG2
        phy: berlin-usb: fix divider for BG2CD
        phy/pxa: add HAS_IOMEM dependency
        ...
      26ae19a3