1. 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
  2. 28 Sep, 2016 18 commits
  3. 27 Sep, 2016 12 commits
  4. 26 Sep, 2016 4 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
    • Arnd Bergmann's avatar
      nfp: bpf: improve handling for disabled BPF syscall · b47c62c5
      Arnd Bergmann authored
      I stumbled over a new warning during randconfig testing,
      with CONFIG_BPF_SYSCALL disabled:
      
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c: In function 'nfp_net_bpf_offload':
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: '*((void *)&res+4)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/ethernet/netronome/nfp/nfp_net_offload.c:263:3: error: 'res.n_instr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      As far as I can tell, this is a false positive caused by the compiler
      getting confused about a function that is partially inlined, but it's
      easy to avoid while improving the code:
      
      The nfp_bpf_jit() stub helper for that configuration is unusual as it
      is defined in a header file but not marked 'static inline'. By moving
      the compile-time check into the caller using the IS_ENABLED() macro,
      we can remove that stub and simplify the nfp_net_bpf_offload_prepare()
      function enough to unconfuse the compiler.
      
      Fixes: 7533fdc0 ("nfp: bpf: add hardware bpf offload")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b47c62c5