1. May 05, 2015
    • Kamlakant Patel's avatar
      net/smsc911x: fix irq resource allocation failure · 965b2aa7
      Kamlakant Patel authored
      When smsc911x uses GPIO as the interrupt controller, and if both are
      loaded as modules, we get following error:
      
      "smsc911x: Could not allocate irq resource"
      
      This issue is because of smsc911x using platform_get_resource to get
      device tree based irq resource.
      
      commit "9ec36caf
      
       (of/irq: do irq resolution in platform_get_irq)" and
      commit "7085a7 (drivers: platform: parse IRQ flags from resources)" add
      support in platform_get_irq to resolve irq and irq_flags respectively
      for both modern device tree and legacy static platform data platforms.
      
      Modify smsc911x driver to use platform_get_irq to pick up irq resource
      correctly and use irq_get_trigger_type to get the IRQ trigger flags.
      
      Signed-off-by: default avatarKamlakant Patel <kamlakant.patel@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      965b2aa7
    • Vlad Yasevich's avatar
      net: core: Correct an over-stringent device loop detection. · d66bf7dd
      Vlad Yasevich authored
      
      
      The code in __netdev_upper_dev_link() has an over-stringent
      loop detection logic that actually prevents valid configurations
      from working correctly.
      
      In particular, the logic returns an error if an upper device
      is already in the list of all upper devices for a given dev.
      This particular check seems to be a overzealous as it disallows
      perfectly valid configurations.  For example:
        # ip l a link eth0 name eth0.10 type vlan id 10
        # ip l a dev br0 typ bridge
        # ip l s eth0.10 master br0
        # ip l s eth0 master br0  <--- Will fail
      
      If you switch the last two commands (add eth0 first), then both
      will succeed.  If after that, you remove eth0 and try to re-add
      it, it will fail!
      
      It appears to be enough to simply check adj_list to keeps things
      safe.
      
      I've tried stacking multiple devices multiple times in all different
      combinations, and either rx_handler registration prevented the stacking
      of the device linking cought the error.
      
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarVeaceslav Falico <vfalico@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d66bf7dd
    • Tilman Schmidt's avatar
      isdn/gigaset: cede maintainership · 6b096fde
      Tilman Schmidt authored
      
      
      As German phone operators are discontinuing ISDN service, neither
      Hansjörg nor I will be able to maintain the Gigaset ISDN drivers
      any longer. Paul Bolle offered to step into the breach for odd
      fixes.
      
      Signed-off-by: default avatarTilman Schmidt <tilman@imap.cc>
      Acked-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b096fde
  2. May 04, 2015
  3. May 02, 2015
  4. May 01, 2015
  5. Apr 30, 2015
    • Mike Snitzer's avatar
      dm: fix free_rq_clone() NULL pointer when requeueing unmapped request · aa6df8dd
      Mike Snitzer authored
      Commit 02233342 ("dm: optimize dm_mq_queue_rq to _not_ use kthread if
      using pure blk-mq") mistakenly removed free_rq_clone()'s clone->q check
      before testing clone->q->mq_ops.  It was an oversight to discontinue
      that check for 1 of the 2 use-cases for free_rq_clone():
      1) free_rq_clone() called when an unmapped original request is requeued
      2) free_rq_clone() called in the request-based IO completion path
      
      The clone->q check made sense for case #1 but not for #2.  However, we
      cannot just reinstate the check as it'd mask a serious bug in the IO
      completion case #2 -- no in-flight request should have an uninitialized
      request_queue (basic block layer refcounting _should_ ensure this).
      
      The NULL pointer seen for case #1 is detailed here:
      https://www.redhat.com/archives/dm-devel/2015-April/msg00160.html
      
      
      
      Fix this free_rq_clone() NULL pointer by simply checking if the
      mapped_device's type is DM_TYPE_MQ_REQUEST_BASED (clone's queue is
      blk-mq) rather than checking clone->q->mq_ops.  This avoids the need to
      dereference clone->q, but a WARN_ON_ONCE is added to let us know if an
      uninitialized clone request is being completed.
      
      Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      aa6df8dd