1. 23 10月, 2018 34 次提交
  2. 22 10月, 2018 6 次提交
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · a19c59cc
      David S. Miller 提交于
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2018-10-21
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      The main changes are:
      
      1) Implement two new kind of BPF maps, that is, queue and stack
         map along with new peek, push and pop operations, from Mauricio.
      
      2) Add support for MSG_PEEK flag when redirecting into an ingress
         psock sk_msg queue, and add a new helper bpf_msg_push_data() for
         insert data into the message, from John.
      
      3) Allow for BPF programs of type BPF_PROG_TYPE_CGROUP_SKB to use
         direct packet access for __skb_buff, from Song.
      
      4) Use more lightweight barriers for walking perf ring buffer for
         libbpf and perf tool as well. Also, various fixes and improvements
         from verifier side, from Daniel.
      
      5) Add per-symbol visibility for DSO in libbpf and hide by default
         global symbols such as netlink related functions, from Andrey.
      
      6) Two improvements to nfp's BPF offload to check vNIC capabilities
         in case prog is shared with multiple vNICs and to protect against
         mis-initializing atomic counters, from Jakub.
      
      7) Fix for bpftool to use 4 context mode for the nfp disassembler,
         also from Jakub.
      
      8) Fix a return value comparison in test_libbpf.sh and add several
         bpftool improvements in bash completion, documentation of bpf fs
         restrictions and batch mode summary print, from Quentin.
      
      9) Fix a file resource leak in BPF selftest's load_kallsyms()
         helper, from Peng.
      
      10) Fix an unused variable warning in map_lookup_and_delete_elem(),
          from Alexei.
      
      11) Fix bpf_skb_adjust_room() signature in BPF UAPI helper doc,
          from Nicolas.
      
      12) Add missing executables to .gitignore in BPF selftests, from Anders.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a19c59cc
    • D
      Merge branch 'net-simplify-getting-driver_data' · 92303c86
      David S. Miller 提交于
      Wolfram Sang says:
      
      ====================
      net: simplify getting .driver_data
      
      I got tired of fixing this in Renesas drivers manually, so I took the big
      hammer. Remove this cumbersome code pattern which got copy-pasted too much
      already:
      
      -	struct platform_device *pdev = to_platform_device(dev);
      -	struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
      +	struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
      
      A branch, tested by buildbot, can be found here:
      
      git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
      
      I have been asked if it couldn't be done for dev_set_drvdata as well. I checked
      it and did not find one occasion where it could be simplified like this. Not
      much of a surprise because driver_data is usually set in probe() functions
      which access struct platform_device in many other ways.
      
      I am open for other comments, suggestions, too, of course.
      
      Here is the cocci-script I created:
      
      @@
      struct device* d;
      identifier pdev;
      expression *ptr;
      @@
      (
      -	struct platform_device *pdev = to_platform_device(d);
      |
      -	struct platform_device *pdev;
      	...
      -	pdev = to_platform_device(d);
      )
      	<... when != pdev
      -	&pdev->dev
      +	d
      	...>
      
      	ptr =
      -	platform_get_drvdata(pdev)
      +	dev_get_drvdata(d)
      
      	<... when != pdev
      -	&pdev->dev
      +	d
      	...>
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92303c86
    • W
      net: phy: mdio-mux-bcm-iproc: simplify getting .driver_data · 2c67e33d
      Wolfram Sang 提交于
      We should get 'driver_data' from 'struct device' directly. Going via
      platform_device is an unneeded step back and forth.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c67e33d
    • W
      net: ethernet: wiznet: w5300: simplify getting .driver_data · 44f5ccdb
      Wolfram Sang 提交于
      We should get 'driver_data' from 'struct device' directly. Going via
      platform_device is an unneeded step back and forth.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44f5ccdb
    • W
      net: ethernet: ti: davinci_emac: simplify getting .driver_data · 762b9e9a
      Wolfram Sang 提交于
      We should get 'driver_data' from 'struct device' directly. Going via
      platform_device is an unneeded step back and forth.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      762b9e9a
    • W
      net: ethernet: ti: cpsw: simplify getting .driver_data · 4e13c252
      Wolfram Sang 提交于
      We should get 'driver_data' from 'struct device' directly. Going via
      platform_device is an unneeded step back and forth.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e13c252