1. 17 1月, 2015 14 次提交
  2. 15 1月, 2015 17 次提交
  3. 14 1月, 2015 9 次提交
    • R
      MPILIB: Fix obvious but harmless typo · 98dbbcba
      Rasmus Villemoes 提交于
      The macro MPN_COPY_INCR this occurs in isn't used anywhere.
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      98dbbcba
    • R
      MPILIB: Deobfuscate mpi_cmp · 7fe21291
      Rasmus Villemoes 提交于
      The condition preceding 'return 1;' makes my head hurt. At this point,
      we know that u and v have the same sign; if they are negative, they
      compare opposite to how their absolute values compare (which
      mpihelp_cmp found for us), otherwise cmp itself is the
      answer. Negating cmp is ok since mpihelp_cmp returns {-1,0,1};
      -INT_MIN==INT_MIN won't bite us.
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NDmitry Kasatkin <dmitry.kasatkin@gmail.com>
      7fe21291
    • J
      neighbour: fix base_reachable_time(_ms) not effective immediatly when changed · 4bf6980d
      Jean-Francois Remy 提交于
      When setting base_reachable_time or base_reachable_time_ms on a
      specific interface through sysctl or netlink, the reachable_time
      value is not updated.
      
      This means that neighbour entries will continue to be updated using the
      old value until it is recomputed in neigh_period_work (which
          recomputes the value every 300*HZ).
      On systems with HZ equal to 1000 for instance, it means 5mins before
      the change is effective.
      
      This patch changes this behavior by recomputing reachable_time after
      each set on base_reachable_time or base_reachable_time_ms.
      The new value will become effective the next time the neighbour's timer
      is triggered.
      
      Changes are made in two places: the netlink code for set and the sysctl
      handling code. For sysctl, I use a proc_handler. The ipv6 network
      code does provide its own handler but it already refreshes
      reachable_time correctly so it's not an issue.
      Any other user of neighbour which provide its own handlers must
      refresh reachable_time.
      Signed-off-by: NJean-Francois Remy <jeff@melix.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bf6980d
    • S
      net: fec: fix MDIO bus assignement for dual fec SoC's · 3d125f9c
      Stefan Agner 提交于
      On i.MX28, the MDIO bus is shared between the two FEC instances.
      The driver makes sure that the second FEC uses the MDIO bus of the
      first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
      However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
      has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
      is not an option since other logic, triggered by this quirk, is
      still needed.
      
      Furthermore, there are board designs which use the same MDIO bus
      for both PHY's even though the second bus would be available on the
      SoC side. Such layout are popular since it saves pins on SoC side.
      Due to the above quirk, those boards currently do work fine. The
      boards in the mainline tree with such a layout are:
      - Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
      - Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)
      
      This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
      makes sure that the MDIO bus of the first FEC is used in any case.
      
      However, the boards above do have a SoC with a MDIO bus for each FEC
      instance. But the PHY's are not connected in a 1:1 configuration. A
      proper device tree description is needed to allow the driver to
      figure out where to find its PHY. This patch fixes that shortcoming
      by adding a MDIO bus child node to the first FEC instance, along
      with the two PHY's on that bus, and making use of the phy-handle
      property to add a reference to the PHY's.
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d125f9c
    • L
      Merge branch 'leds-fixes-for-3.19' of... · 188c9019
      Linus Torvalds 提交于
      Merge branch 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
      
      Pull LED fix from Bryan Wu.
      
      * 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
        leds: netxbig: fix oops at probe time
      188c9019
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux · 0c133dd0
      Linus Torvalds 提交于
      Pull WRITE_ONCE argument order change from Christian Borntraeger:
       "As discussed on LKML[1] it was agreed that WRITE_ONCE(x, val) is
        better than ASSIGN_ONCE(val, x)
      
        Lets change that for 3.19 as 3.19 has no user yet, but the first users
        will hit linux-next soon"
      
      [1] http://marc.info/?l=linux-kernel&m=142081181707596
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux:
        kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)
      0c133dd0
    • D
      xen-netfront: use different locks for Rx and Tx stats · 900e1833
      David Vrabel 提交于
      In netfront the Rx and Tx path are independent and use different
      locks.  The Tx lock is held with hard irqs disabled, but Rx lock is
      held with only BH disabled.  Since both sides use the same stats lock,
      a deadlock may occur.
      
        [ INFO: possible irq lock inversion dependency detected ]
        3.16.2 #16 Not tainted
        ---------------------------------------------------------
        swapper/0/0 just changed the state of lock:
         (&(&queue->tx_lock)->rlock){-.....}, at: [<c03adec8>]
        xennet_tx_interrupt+0x14/0x34
        but this lock took another, HARDIRQ-unsafe lock in the past:
         (&stat->syncp.seq#2){+.-...}
        and interrupts could create inverse lock ordering between them.
        other info that might help us debug this:
         Possible interrupt unsafe locking scenario:
      
               CPU0                    CPU1
               ----                    ----
          lock(&stat->syncp.seq#2);
                                       local_irq_disable();
                                       lock(&(&queue->tx_lock)->rlock);
                                       lock(&stat->syncp.seq#2);
          <Interrupt>
            lock(&(&queue->tx_lock)->rlock);
      
      Using separate locks for the Rx and Tx stats fixes this deadlock.
      Reported-by: NDmitry Piotrovsky <piotrovskydmitry@gmail.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      900e1833
    • M
      drivers: net: cpsw: fix multicast flush in dual emac mode · 25906052
      Mugunthan V N 提交于
      Since ALE table is a common resource for both the interfaces in Dual EMAC
      mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
      all the multicast entries added by the first interface is flushed out and
      only second interface multicast addresses are added. Fixing this by
      flushing multicast addresses based on dual EMAC port vlans which will not
      affect the other emac port multicast addresses.
      
      Fixes: d9ba8f9e (driver: net: ethernet: cpsw: dual emac interface implementation)
      Cc: <stable@vger.kernel.org> # v3.9+
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25906052
    • S
      leds: netxbig: fix oops at probe time · 0c86ac2c
      Simon Guinot 提交于
      This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to
      this bug, a kernel oops can be observed at probe time on the LaCie 2Big
      and 5Big v2 boards:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      [...]
      [<c03f244c>] (netxbig_led_probe) from [<c02c8c6c>] (platform_drv_probe+0x4c/0x9c)
      [<c02c8c6c>] (platform_drv_probe) from [<c02c72d0>] (driver_probe_device+0x98/0x25c)
      [<c02c72d0>] (driver_probe_device) from [<c02c7520>] (__driver_attach+0x8c/0x90)
      [<c02c7520>] (__driver_attach) from [<c02c5c24>] (bus_for_each_dev+0x68/0x94)
      [<c02c5c24>] (bus_for_each_dev) from [<c02c6408>] (bus_add_driver+0x124/0x1dc)
      [<c02c6408>] (bus_add_driver) from [<c02c7ac0>] (driver_register+0x78/0xf8)
      [<c02c7ac0>] (driver_register) from [<c000888c>] (do_one_initcall+0x80/0x1cc)
      [<c000888c>] (do_one_initcall) from [<c0733618>] (kernel_init_freeable+0xe4/0x1b4)
      [<c0733618>] (kernel_init_freeable) from [<c058db9c>] (kernel_init+0xc/0xec)
      [<c058db9c>] (kernel_init) from [<c0009850>] (ret_from_fork+0x14/0x24)
      [...]
      
      This bug was introduced by commit 588a6a99
      ("leds: netxbig: fix attribute-creation race").
      Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
      Cc: <stable@vger.kernel.org> # 3.17+
      Acked-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NBryan Wu <cooloney@gmail.com>
      0c86ac2c