1. 19 Nov, 2016 4 commits
  2. 18 Nov, 2016 19 commits
  3. 17 Nov, 2016 14 commits
  4. 16 Nov, 2016 3 commits
    • Arnd Bergmann's avatar
      staging: vc04_services: clarify firmware dependency · 6fde3789
      Arnd Bergmann authored
      The raspberrypi-firmware driver may be built as a loadable module,
      which causes a link-time failure if the vc04_services driver is
      built-in during compile-testing:
      
      drivers/staging/vc04_services/vchiq.o: In function `vchiq_probe':
      vchiq_connected.c:(.text.vchiq_probe+0x2c): undefined reference to `rpi_firmware_get'
      drivers/staging/vc04_services/vchiq.o: In function `vchiq_platform_init':
      vchiq_connected.c:(.text.vchiq_platform_init+0x1f0): undefined reference to `rpi_firmware_property'
      
      This extends the dependency list to ensure the firmware is either
      reachable, or completely disabled in case of compile-testing.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fde3789
    • Arnd Bergmann's avatar
      staging: vc04_services: remove duplicate mutex_lock_interruptible · b826d73b
      Arnd Bergmann authored
      The driver tries to redefine mutex_lock_interruptible as an open-coded
      mutex_lock_killable, but that definition clashes with the normal
      mutex_lock_interruptible definition when CONFIG_DEBUG_LOCK_ALLOC
      is set:
      
      staging/vc04_services/interface/vchiq_arm/vchiq_killable.h:67:0: error: "mutex_lock_interruptible" redefined [-Werror]
       #define mutex_lock_interruptible mutex_lock_interruptible_killable
      include/linux/mutex.h:161:0: note: this is the location of the previous definition
      
      This simply removes the private implementation and uses the
      normal mutex_lock_killable directly.
      
      We could do the same for the down_interruptible_killable here, but
      it's better to just remove the semaphores entirely from the driver,
      which also takes care of that.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b826d73b
    • Arnd Bergmann's avatar
      staging: wilc1000: simplify vif[i]->ndev accesses · 735bb39c
      Arnd Bergmann authored
      With gcc-7, I got a new warning for this driver:
      
      wilc1000/linux_wlan.c: In function 'wilc_netdev_cleanup':
      wilc1000/linux_wlan.c:1224:15: error: 'vif[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      wilc1000/linux_wlan.c:1224:15: error: 'vif[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      A closer look at the function reveals that it's more complex than
      it needs to be, given that based on how the device is created
      we always get
      
      	netdev_priv(vif->ndev) == vif
      
      Based on this assumption, I found a few other places in the same file
      that can be simplified. That code appears to be a relic from times
      when the assumption above was not valid.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      735bb39c