1. 30 Sep, 2016 1 commit
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: add global1 helpers · a935c052
      Vivien Didelot authored
      The Global (1) internal SMI device is an extended set of registers
      containing ATU, PPU, VTU, STU, etc.
      
      It is present on every switches, usually at SMI address 0x1B. But old
      models such as 88E6060 access it at address 0xF, thus using REG_GLOBAL
      is erroneous.
      
      Add a global1_addr info member used by mv88e6xxx_g1_{read,write} and
      mv88e6xxx_g1_wait helpers in a new global1.c file.
      
      This patch finally removes _mv88e6xxx_reg_{read,write}, in favor on the
      appropriate helpers. No functional changes here.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a935c052
  2. 29 Sep, 2016 6 commits
    • David S. Miller's avatar
      Merge branch 'qcom-emac-acpi' · 31fbe81f
      David S. Miller authored
      Timur Tabi says:
      
      ====================
      Add basic ACPI support to the Qualcomm Technologies EMAC driver
      
      This patch series adds support to the EMAC driver for extracting addresses,
      interrupts, and some _DSDs (properties) from ACPI.  The first two patches
      clean up the code, and the third patch adds ACPI-specific functionality.
      
      The first patch fixes a bug with handling the platform_device for the
      internal PHY.  This phy is treated as a separate device in both DT and
      ACPI, but since the platform is not released automatically when the
      driver unloads, managed functions like devm_ioremap_resource cannot be
      used.
      
      The second patch replaces of_get_mac_address with its platform-independent
      equivalent device_get_mac_address.
      
      The third patch parses the ACPI tables to obtain the platform_device for
      the primary EMAC node ("QCOM8070") and the internal phy node ("QCOM8071").
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31fbe81f
    • Timur Tabi's avatar
      net: qcom/emac: initial ACPI support · 5f3d3807
      Timur Tabi authored
      Add support for reading addresses, interrupts, and _DSD properties
      from ACPI tables, just like with device tree.  The HID for the
      EMAC device itself is QCOM8070.  The internal PHY is represented
      by a child node with a HID of QCOM8071.
      
      The EMAC also has some complex clock initialization requirements
      that are not represented by this patch.  This will be addressed
      in a future patch.
      Signed-off-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f3d3807
    • Timur Tabi's avatar
      net: qcom/emac: use device_get_mac_address · 0de709ac
      Timur Tabi authored
      Replace the DT-specific of_get_mac_address() function with
      device_get_mac_address, which works on both DT and ACPI platforms.  This
      change makes it easier to add ACPI support.
      Signed-off-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0de709ac
    • Timur Tabi's avatar
      net: qcom/emac: do not use devm on internal phy pdev · 54e19bc7
      Timur Tabi authored
      The platform_device returned by of_find_device_by_node() is not
      automatically released when the driver unprobes.  Therefore,
      managed calls like devm_ioremap_resource() should not be used.
      Instead, we manually allocate the resources and then free them
      on driver release.
      Signed-off-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54e19bc7
    • Josef Bacik's avatar
      bpf: allow access into map value arrays · 48461135
      Josef Bacik authored
      Suppose you have a map array value that is something like this
      
      struct foo {
      	unsigned iter;
      	int array[SOME_CONSTANT];
      };
      
      You can easily insert this into an array, but you cannot modify the contents of
      foo->array[] after the fact.  This is because we have no way to verify we won't
      go off the end of the array at verification time.  This patch provides a start
      for this work.  We accomplish this by keeping track of a minimum and maximum
      value a register could be while we're checking the code.  Then at the time we
      try to do an access into a MAP_VALUE we verify that the maximum offset into that
      region is a valid access into that memory region.  So in practice, code such as
      this
      
      unsigned index = 0;
      
      if (foo->iter >= SOME_CONSTANT)
      	foo->iter = index;
      else
      	index = foo->iter++;
      foo->array[index] = bar;
      
      would be allowed, as we can verify that index will always be between 0 and
      SOME_CONSTANT-1.  If you wish to use signed values you'll have to have an extra
      check to make sure the index isn't less than 0, or do something like index %=
      SOME_CONSTANT.
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48461135
    • Eric Dumazet's avatar
      net: do not export sk_stream_write_space · 7836667c
      Eric Dumazet authored
      Since commit 900f65d3 ("tcp: move duplicate code from
      tcp_v4_init_sock()/tcp_v6_init_sock()") we no longer need
      to export sk_stream_write_space()
      
      From: Eric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7836667c
  3. 28 Sep, 2016 18 commits
  4. 27 Sep, 2016 12 commits
  5. 26 Sep, 2016 3 commits
    • David S. Miller's avatar
      Merge branch 'bnx2x-fix-page-allocation-failure' · be92e538
      David S. Miller authored
      Jason Baron says:
      
      ====================
      bnx2x: page allocation failure
      
      While configuring ~500 multicast addrs, we ran into high order
      page allocation failures. They don't need to be high order, and
      thus I'm proposing to split them into at most PAGE_SIZE allocations.
      
      Below is a sample failure.
      
      [1201902.617882] bnx2x: [bnx2x_set_mc_list:12374(eth0)]Failed to create multicast MACs list: -12
      [1207325.695021] kworker/1:0: page allocation failure: order:2, mode:0xc020
      [1207325.702059] CPU: 1 PID: 15805 Comm: kworker/1:0 Tainted: G        W
      [1207325.712940] Hardware name: SYNNEX CORPORATION 1x8-X4i SSD 10GE/S5512LE, BIOS V8.810 05/16/2013
      [1207325.722284] Workqueue: events bnx2x_sp_rtnl_task [bnx2x]
      [1207325.728206]  0000000000000000 ffff88012d873a78 ffffffff8267f7c7 000000000000c020
      [1207325.736754]  0000000000000000 ffff88012d873b08 ffffffff8212f8e0 fffffffc00000003
      [1207325.745301]  ffff88041ffecd80 ffff880400000030 0000000000000002 0000c0206800da13
      [1207325.753846] Call Trace:
      [1207325.756789]  [<ffffffff8267f7c7>] dump_stack+0x4d/0x63
      [1207325.762426]  [<ffffffff8212f8e0>] warn_alloc_failed+0xe0/0x130
      [1207325.768756]  [<ffffffff8213c898>] ? wakeup_kswapd+0x48/0x140
      [1207325.774914]  [<ffffffff82132afc>] __alloc_pages_nodemask+0x2bc/0x970
      [1207325.781761]  [<ffffffff82173691>] alloc_pages_current+0x91/0x100
      [1207325.788260]  [<ffffffff8212fa1e>] alloc_kmem_pages+0xe/0x10
      [1207325.794329]  [<ffffffff8214c9c8>] kmalloc_order+0x18/0x50
      [1207325.800227]  [<ffffffff8214ca26>] kmalloc_order_trace+0x26/0xb0
      [1207325.806642]  [<ffffffff82451c68>] ? _xfer_secondary_pool+0xa8/0x1a0
      [1207325.813404]  [<ffffffff8217cfda>] __kmalloc+0x19a/0x1b0
      [1207325.819142]  [<ffffffffa02fe975>] bnx2x_set_rx_mode_inner+0x3d5/0x590 [bnx2x]
      [1207325.827000]  [<ffffffffa02ff52d>] bnx2x_sp_rtnl_task+0x28d/0x760 [bnx2x]
      [1207325.834197]  [<ffffffff820695d4>] process_one_work+0x134/0x3c0
      [1207325.840522]  [<ffffffff82069981>] worker_thread+0x121/0x460
      [1207325.846585]  [<ffffffff82069860>] ? process_one_work+0x3c0/0x3c0
      [1207325.853089]  [<ffffffff8206f039>] kthread+0xc9/0xe0
      [1207325.858459]  [<ffffffff82070000>] ? notify_die+0x10/0x40
      [1207325.864263]  [<ffffffff8206ef70>] ? kthread_create_on_node+0x180/0x180
      [1207325.871288]  [<ffffffff826852d2>] ret_from_fork+0x42/0x70
      [1207325.877183]  [<ffffffff8206ef70>] ? kthread_create_on_node+0x180/0x180
      
      v2:
       -make use of list_next_entry()
       -only use PAGE_SIZE allocations
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be92e538
    • Jason Baron's avatar
      bnx2x: allocate mac filtering pending list in PAGE_SIZE increments · 3129e159
      Jason Baron authored
      Currently, we can have high order page allocations that specify
      GFP_ATOMIC when configuring multicast MAC address filters.
      
      For example, we have seen order 2 page allocation failures with
      ~500 multicast addresses configured.
      
      Convert the allocation for the pending list to be done in PAGE_SIZE
      increments.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
      Cc: Ariel Elior <Ariel.Elior@qlogic.com>
      Acked-by: default avatarYuval Mintz <Yuval.Mintz@caviumnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3129e159
    • Jason Baron's avatar
      bnx2x: allocate mac filtering 'mcast_list' in PAGE_SIZE increments · e8c6ae9f
      Jason Baron authored
      Currently, we can have high order page allocations that specify
      GFP_ATOMIC when configuring multicast MAC address filters.
      
      For example, we have seen order 2 page allocation failures with
      ~500 multicast addresses configured.
      
      Convert the allocation for 'mcast_list' to be done in PAGE_SIZE
      increments.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
      Cc: Ariel Elior <Ariel.Elior@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8c6ae9f