Skip to content
  1. Aug 12, 2015
  2. Aug 05, 2015
    • Geert Uytterhoeven's avatar
      ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node · 94bdc48d
      Geert Uytterhoeven authored
      
      
      If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
      case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
      doesn't work:
      
          requesting hog GPIO led1-high (chip sh73a0_pfc, offset 20) failed
      
      The actual error code is -517 == -EPROBE_DEFER.
      
      The problem is that PFC+GPIO registration is handled in multiple steps:
        1. pinctrl_register(),
        2. gpiochip_add(),
        3. gpiochip_add_pin_range().
      
      Configuration of the hogs is handled in gpiochip_add():
      
          gpiochip_add
              of_gpiochip_add
                  of_gpiochip_scan_hogs
                      gpiod_hog
                          gpiochip_request_own_desc
                              __gpiod_request
                                  chip->request
                                      pinctrl_request_gpio
                                          pinctrl_get_device_gpio_range
      
      However, at this point the GPIO controller hasn't been added to
      pinctrldev_list yet, so the range can't be found, and the operation fails
      with -EPROBE_DEFER.
      
      To fix this, add a "gpio-ranges" property to the gpio device node, so
      the ranges are added by of_gpiochip_add_pin_range(), which is called by
      of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
      
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      94bdc48d
    • Geert Uytterhoeven's avatar
      ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node · 09d1c7b4
      Geert Uytterhoeven authored
      
      
      If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
      case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
      doesn't work:
      
          requesting hog GPIO lcd0 (chip r8a7740_pfc, offset 176) failed
      
      The actual error code is -517 == -EPROBE_DEFER.
      
      The problem is that PFC+GPIO registration is handled in multiple steps:
        1. pinctrl_register(),
        2. gpiochip_add(),
        3. gpiochip_add_pin_range().
      
      Configuration of the hogs is handled in gpiochip_add():
      
          gpiochip_add
              of_gpiochip_add
                  of_gpiochip_scan_hogs
                      gpiod_hog
                          gpiochip_request_own_desc
                              __gpiod_request
                                  chip->request
                                      pinctrl_request_gpio
                                          pinctrl_get_device_gpio_range
      
      However, at this point the GPIO controller hasn't been added to
      pinctrldev_list yet, so the range can't be found, and the operation fails
      with -EPROBE_DEFER.
      
      To fix this, add a "gpio-ranges" property to the gpio device node, so
      the range is added by of_gpiochip_add_pin_range(), which is called by
      of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
      
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      09d1c7b4
    • Geert Uytterhoeven's avatar
      ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node · 17ccec50
      Geert Uytterhoeven authored
      
      
      If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
      case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
      doesn't work:
      
          requesting hog GPIO led1-high (chip r8a73a4_pfc, offset 28) failed
      
      The actual error code is -517 == -EPROBE_DEFER.
      
      The problem is that PFC+GPIO registration is handled in multiple steps:
        1. pinctrl_register(),
        2. gpiochip_add(),
        3. gpiochip_add_pin_range().
      
      Configuration of the hogs is handled in gpiochip_add():
      
          gpiochip_add
              of_gpiochip_add
                  of_gpiochip_scan_hogs
                      gpiod_hog
                          gpiochip_request_own_desc
                              __gpiod_request
                                  chip->request
                                      pinctrl_request_gpio
                                          pinctrl_get_device_gpio_range
      
      However, at this point the GPIO controller hasn't been added to
      pinctrldev_list yet, so the range can't be found, and the operation fails
      with -EPROBE_DEFER.
      
      To fix this, add a "gpio-ranges" property to the gpio device node, so
      the ranges are added by of_gpiochip_add_pin_range(), which is called by
      of_gpiochip_add() before the call to of_gpiochip_scan_hogs().
      
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      17ccec50
  3. Aug 03, 2015
  4. Jul 30, 2015
  5. Jul 29, 2015
  6. Jul 28, 2015
  7. Jul 22, 2015
  8. Jul 15, 2015
  9. Jul 06, 2015
  10. Jul 05, 2015
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 1dc51b82
      Linus Torvalds authored
      Pull more vfs updates from Al Viro:
       "Assorted VFS fixes and related cleanups (IMO the most interesting in
        that part are f_path-related things and Eric's descriptor-related
        stuff).  UFS regression fixes (it got broken last cycle).  9P fixes.
        fs-cache series, DAX patches, Jan's file_remove_suid() work"
      
      [ I'd say this is much more than "fixes and related cleanups".  The
        file_table locking rule change by Eric Dumazet is a rather big and
        fundamental update even if the patch isn't huge.   - Linus ]
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (49 commits)
        9p: cope with bogus responses from server in p9_client_{read,write}
        p9_client_write(): avoid double p9_free_req()
        9p: forgetting to cancel request on interrupted zero-copy RPC
        dax: bdev_direct_access() may sleep
        block: Add support for DAX reads/writes to block devices
        dax: Use copy_from_iter_nocache
        dax: Add block size note to documentation
        fs/file.c: __fget() and dup2() atomicity rules
        fs/file.c: don't acquire files->file_lock in fd_install()
        fs:super:get_anon_bdev: fix race condition could cause dev exceed its upper limitation
        vfs: avoid creation of inode number 0 in get_next_ino
        namei: make set_root_rcu() return void
        make simple_positive() public
        ufs: use dir_pages instead of ufs_dir_pages()
        pagemap.h: move dir_pages() over there
        remove the pointless include of lglock.h
        fs: cleanup slight list_entry abuse
        xfs: Correctly lock inode when removing suid and file capabilities
        fs: Call security_ops->inode_killpriv on truncate
        fs: Provide function telling whether file_remove_privs() will do anything
        ...
      1dc51b82
    • Linus Torvalds's avatar
      bluetooth: fix list handling · 9b284cbd
      Linus Torvalds authored
      Commit 835a6a2f
      
       ("Bluetooth: Stop sabotaging list poisoning")
      thought that the code was sabotaging the list poisoning when NULL'ing
      out the list pointers and removed it.
      
      But what was going on was that the bluetooth code was using NULL
      pointers for the list as a way to mark it empty, and that commit just
      broke it (and replaced the test with NULL with a "list_empty()" test on
      a uninitialized list instead, breaking things even further).
      
      So fix it all up to use the regular and real list_empty() handling
      (which does not use NULL, but a pointer to itself), also making sure to
      initialize the list properly (the previous NULL case was initialized
      implicitly by the session being allocated with kzalloc())
      
      This is a combination of patches by Marcel Holtmann and Tedd Ho-Jeong
      An.
      
      [ I would normally expect to get this through the bt tree, but I'm going
        to release -rc1, so I'm just committing this directly   - Linus ]
      
      Reported-and-tested-by: default avatarJörg Otte <jrg.otte@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Original-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Original-by: default avatarMarcel Holtmann <marcel@holtmann.org&gt;:>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b284cbd