1. 19 11月, 2015 3 次提交
  2. 18 11月, 2015 1 次提交
  3. 17 11月, 2015 11 次提交
  4. 16 11月, 2015 7 次提交
  5. 13 11月, 2015 2 次提交
  6. 11 11月, 2015 3 次提交
    • C
      sfc: don't call dma_supported · 8722b8fb
      Christoph Hellwig 提交于
      dma_set_mask already checks for a supported DMA mask before updating it,
      the call to dma_supported is redundant.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Shradha Shah <sshah@solarflare.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8722b8fb
    • C
      pcnet32: use pci_set_dma_mask insted of pci_dma_supported · 46a7fd8a
      Christoph Hellwig 提交于
      All drivers should be using dma_set_mask / pci_set_dma_mask to try to
      set the dma mask instead of just querying it.  Without that some iommu
      implementations may not work.
      
      pci_dma_supported is removed entirely, but dma_supported stays for
      dma_ops implementations for now.
      
      This patch (of 15):
      
      This ensures the dma mask that is supported by the driver is recorded
      in the device structure.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NDon Fry <pcnet32@frontier.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Alexandre Courbot <acourbot@nvidia.com>
      Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Hans Verkuil <hverkuil@xs4all.nl>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Pawel Osciak <pawel@osciak.com>
      Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
      Cc: Sergey Kozlov <serjk@netup.ru>
      Cc: Shradha Shah <sshah@solarflare.com>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Steven Toth <stoth@kernellabs.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      46a7fd8a
    • A
      qed: select ZLIB_INFLATE · 4bdb96cb
      Arnd Bergmann 提交于
      The newly added qlogic qed driver uses the zlib library, but
      misses the dependency:
      
      drivers/built-in.o: In function `qed_alloc_stream_mem':
      drivers/net/ethernet/qlogic/qed/qed_main.c:707: undefined reference to `zlib_inflate_workspacesize'
      drivers/built-in.o: In function `qed_unzip_data':
      drivers/net/ethernet/qlogic/qed/qed_main.c:675: undefined reference to `zlib_inflateInit2'
      
      This changes Kconfig to always select zlib when needed.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: fe56b9e6 ("qed: Add module with basic common support")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bdb96cb
  7. 10 11月, 2015 3 次提交
    • J
      net: mvneta: Fix memory use after free. · 8c94ddbc
      Justin Maggard 提交于
      After changing an interface's MTU, then bringing the interface down and
      back up again, I immediately saw tons of kernel messages like below.
      The reason for this bad behavior is mvneta_rxq_drop_pkts(), which calls
      dma_unmap_single() on already-freed memory.  So we need to switch the
      order of those two operations.
      
      [  152.388518] BUG: Bad page state in process ifconfig  pfn:1b518
      [  152.388526] page:dff3dbc0 count:0 mapcount:0 mapping:  (null) index:0x0
      [  152.395178] flags: 0x200(arch_1)
      [  152.398441] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
      [  152.398446] bad because of flags:
      [  152.398450] flags: 0x200(arch_1)
      [  152.401716] Modules linked in:
      [  152.401728] CPU: 0 PID: 1453 Comm: ifconfig Tainted: P    B      O    4.1.12.armada.1 #1
      [  152.401733] Hardware name: Marvell Armada 370/XP (Device Tree)
      [  152.401749] [<c0015b1c>] (unwind_backtrace) from [<c0011d8c>] (show_stack+0x10/0x14)
      [  152.401762] [<c0011d8c>] (show_stack) from [<c06aa68c>] (dump_stack+0x74/0x90)
      [  152.401772] [<c06aa68c>] (dump_stack) from [<c0096c08>] (bad_page+0xc4/0x124)
      [  152.401783] [<c0096c08>] (bad_page) from [<c0099378>] (get_page_from_freelist+0x4e4/0x644)
      [  152.401794] [<c0099378>] (get_page_from_freelist) from [<c0099620>] (__alloc_pages_nodemask+0x148/0x784)
      [  152.401805] [<c0099620>] (__alloc_pages_nodemask) from [<c00ac658>] (kmalloc_order+0x10/0x20)
      [  152.401818] [<c00ac658>] (kmalloc_order) from [<c04c6f44>] (mvneta_rx_refill+0xc4/0xe8)
      [  152.401830] [<c04c6f44>] (mvneta_rx_refill) from [<c04c96c0>] (mvneta_setup_rxqs+0x298/0x39c)
      [  152.401842] [<c04c96c0>] (mvneta_setup_rxqs) from [<c04c9904>] (mvneta_open+0x3c/0x150)
      [  152.401853] [<c04c9904>] (mvneta_open) from [<c0597764>] (__dev_open+0xac/0x124)
      [  152.401864] [<c0597764>] (__dev_open) from [<c05979e4>] (__dev_change_flags+0x8c/0x148)
      [  152.401875] [<c05979e4>] (__dev_change_flags) from [<c0597ac0>] (dev_change_flags+0x18/0x48)
      [  152.401886] [<c0597ac0>] (dev_change_flags) from [<c060d308>] (devinet_ioctl+0x620/0x6d0)
      [  152.401897] [<c060d308>] (devinet_ioctl) from [<c057d810>] (sock_ioctl+0x64/0x288)
      [  152.401908] [<c057d810>] (sock_ioctl) from [<c00dcb7c>] (do_vfs_ioctl+0x78/0x608)
      [  152.401918] [<c00dcb7c>] (do_vfs_ioctl) from [<c00dd170>] (SyS_ioctl+0x64/0x74)
      [  152.401930] [<c00dd170>] (SyS_ioctl) from [<c000f3a0>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: NJustin Maggard <jmaggard@netgear.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c94ddbc
    • A
      mvneta: add FIXED_PHY dependency · 4bed5395
      Arnd Bergmann 提交于
      The fixed_phy infrastructure is done in a way that is optional,
      by providing 'static inline' helper functions doing nothing in
      include/linux/phy_fixed.h for all its APIs. However, three out
      of the four users (DSA, BCMGENET, and SYSTEMPORT) always
      'select FIXED_PHY', presumably because they need that.
      MVNETA is the fourth one, and if that is built-in but FIXED_PHY
      is configured as a loadable module, we get a link error:
      
      drivers/built-in.o: In function `mvneta_fixed_link_update':
      fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state'
      
      Presumably this driver has the same dependency as the others,
      so this patch also uses 'select' to ensure that the fixed-phy
      support is built-in.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 898b2970 ("mvneta: implement SGMII-based in-band link state signaling")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bed5395
    • G
      net: hisilicon: NET_VENDOR_HISILICON should depend on HAS_DMA · 3870502a
      Geert Uytterhoeven 提交于
      If NO_DMA=y:
      
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
      
      As this affects all of HNS_ENET, HNS_DSAF, HNS, HIX5HD2_GMAC, and
      HIP04_ETH, add a dependency on HAS_DMA to the main NET_VENDOR_HISILICON
      symbol to fix this.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3870502a
  8. 09 11月, 2015 1 次提交
  9. 08 11月, 2015 2 次提交
    • M
      dwc_eth_qos: Delete an unnecessary check before the function call "of_node_put" · 3694bfbd
      Markus Elfring 提交于
      The of_node_put() function tests whether its argument is NULL
      and then returns immediately.
      Thus the test around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3694bfbd
    • J
      net/qlcnic: fix mac address restore in bond mode 5/6 · e824de8a
      Jarod Wilson 提交于
      The bonding driver saves a copy of slaves' original mac address and then
      assigns whatever mac as needed to the slave, depending on mode. In at
      least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
      mac address of another slave. On release from the bond, the original mac
      address is supposed to get restored via a dev_set_mac_address() call in
      the bonding driver's __bond_release_one() function, which calls the
      slave's ndo_set_mac_address function, which for qlcnic, is
      qlcnic_set_mac().
      
      Now, this function tries to be somewhat intelligent and exit early if
      you're trying to set the mac address to the same thing that is already
      set. The problem here is that adapter->mac_addr isn't in sync with
      netdev->dev_addr. The qlcnic driver still has the original mac stored in
      adapter->mac_addr, while the bonding driver has updated netdev->dev_addr,
      so qlcnic thinks we're trying to set the same address it already has.
      
      I think the way to go here, since the function updates both netdev and
      adapter's stored mac addresses, is to check if either of them doesn't
      match the newly requested mac. Simply checking netdev's value only could
      result in a similar mismatch and non-update, so look at both.
      
      CC: Dept-GELinuxNICDev@qlogic.com
      CC: netdev@vger.kernel.org
      CC: Manish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e824de8a
  10. 07 11月, 2015 2 次提交
    • M
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman 提交于
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      reserves.
      
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      
      This patch then converts a number of sites
      
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0164adc
    • S
      device property: ACPI: Make use of the new DMA Attribute APIs · 1831eff8
      Suthikulpanit, Suravee 提交于
      Now that we have the new DMA attribute APIs, we can replace the older
      acpi_check_dma() and device_dma_is_coherent().
      Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1831eff8
  11. 06 11月, 2015 5 次提交