1. 15 7月, 2014 6 次提交
    • O
      hso: fix deadlock when receiving bursts of data · 8f9818af
      Olivier Sobrie 提交于
      When the module sends bursts of data, sometimes a deadlock happens in
      the hso driver when the tty buffer doesn't get the chance to be flushed
      quickly enough.
      
      Remove the endless while loop in function put_rxbuf_data() which is
      called by the urb completion handler.
      If there isn't enough room in the tty buffer, discards all the data
      received in the URB.
      
      Cc: David Miller <davem@davemloft.net>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jan Dumon <j.dumon@option.com>
      Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f9818af
    • O
      hso: remove unused workqueue · 5c763edf
      Olivier Sobrie 提交于
      The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
      in the code. So, remove it.
      Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c763edf
    • C
      net: ppp: don't call sk_chk_filter twice · 3916a319
      Christoph Schulz 提交于
      Commit 568f194e ("net: ppp: use
      sk_unattached_filter api") causes sk_chk_filter() to be called twice when
      setting a PPP pass or active filter. This applies to both the generic PPP
      subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP
      subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The first call is from
      within get_filter(). The second one is through the call chain
      
        ppp_ioctl() or isdn_ppp_ioctl()
        --> sk_unattached_filter_create()
            --> __sk_prepare_filter()
                --> sk_chk_filter()
      
      The first call from within get_filter() should be deleted as get_filter() is
      called just before calling sk_unattached_filter_create() later on, which
      eventually calls sk_chk_filter() anyway.
      
      For 3.15.x, this proposed change is a bugfix rather than a pure optimization as
      in that branch, sk_chk_filter() may replace filter codes by other codes which
      are not recognized when executing sk_chk_filter() a second time. So with
      3.15.x, if sk_chk_filter() is called twice, the second invocation may yield
      EINVAL (this depends on the filter codes found in the filter to be set, but
      because the replacement is done for frequently used codes, this is almost
      always the case). The net effect is that setting pass and/or active PPP filters
      does not work anymore, since sk_unattached_filter_create() always returns
      EINVAL due to the second call to sk_chk_filter(), regardless whether the filter
      was originally sane or not.
      Signed-off-by: NChristoph Schulz <develop@kristov.de>
      Acked-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3916a319
    • J
      mlx4: mark napi id for gro_skb · 32b333fe
      Jason Wang 提交于
      Napi id was not marked for gro_skb, this will lead rx busy loop won't
      work correctly since they stack never try to call low latency receive
      method because of a zero socket napi id. Fix this by marking napi id
      for gro_skb.
      
      The transaction rate of 1 byte netperf tcp_rr gets about 50% increased
      (from 20531.68 to 30610.88).
      
      Cc: Amir Vadai <amirv@mellanox.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32b333fe
    • N
      bonding: fix ad_select module param check · 548d28bd
      Nikolay Aleksandrov 提交于
      Obvious copy/paste error when I converted the ad_select to the new
      option API. "lacp_rate" there should be "ad_select" so we can get the
      proper value.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      
      Fixes: 9e5f5eeb ("bonding: convert ad_select to use the new option
      API")
      Reported-by: NKarim Scheik <karim.scheik@prisma-solutions.at>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      548d28bd
    • C
      net: pppoe: use correct channel MTU when using Multilink PPP · a8a3e41c
      Christoph Schulz 提交于
      The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
      ppp_generic module) tries to determine how big a fragment might be. According
      to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
      corresponding comment and code in ppp_mp_explode():
      
      		/*
      		 * hdrlen includes the 2-byte PPP protocol field, but the
      		 * MTU counts only the payload excluding the protocol field.
      		 * (RFC1661 Section 2)
      		 */
      		mtu = pch->chan->mtu - (hdrlen - 2);
      
      However, the pppoe module *does* include the PPP protocol field in the channel
      MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
      certain circumstances (one byte if PPP protocol compression is used, two
      otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
      module has to subtract two bytes from the channel MTU. This error only
      manifests itself when using Multilink PPP, as otherwise the channel MTU is not
      used anywhere.
      
      In the following, I will describe how to reproduce this bug. We configure two
      pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
      a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
      computed by adding the two link MTUs and subtracting the MP header twice, which
      is 4 bytes long.) The necessary pppd statements on both sides are "multilink
      mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
      rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
      side, we additionally need to start two pppoe-server instances to be able to
      establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
      of the PPP network interface to the MRRU (2976) on both sides of the connection
      in order to make use of the higher bandwidth. (If we didn't do that, IP
      fragmentation would kick in, which we want to avoid.)
      
      Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
      server over the PPP link. This results in the following network packet:
      
         2948 (echo payload)
       +    8 (ICMPv4 header)
       +   20 (IPv4 header)
      ---------------------
         2976 (PPP payload)
      
      These 2976 bytes do not exceed the MTU of the PPP network interface, so the
      IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
      prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
      than the negotiated MRRU. So this packet would have to be divided in three
      fragments. But this does not happen as each link MTU is assumed to be two bytes
      larger. So this packet is diveded into two fragments only, one of size 1489 and
      one of size 1488. Now we have for that bigger fragment:
      
         1489 (PPP payload)
       +    4 (MP header)
       +    2 (PPP protocol field for the MP payload (0x3d))
       +    6 (PPPoE header)
      --------------------------
         1501 (Ethernet payload)
      
      This packet exceeds the link MTU and is discarded.
      
      If one configures the link MTU on the client side to 1501, one can see the
      discarded Ethernet frames with tcpdump running on the client. A
      
      ping -s 2948 -c 1 192.168.15.254
      
      leads to the smaller fragment that is correctly received on the server side:
      
      (tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [end], length 1492
      
      and to the bigger fragment that is not received on the server side:
      
      (tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
      52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
        length 1515: PPPoE  [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
        Flags [begin], length 1493
      
      With the patch below, we correctly obtain three fragments:
      
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [begin], length 1492
      52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [none], length 1492
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 27: PPPoE  [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
        Flags [end], length 5
      
      And the ICMPv4 echo request is successfully received at the server side:
      
      IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
        length 2976)
          192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
            length 2956
      
      The bug was introduced in commit c9aa6895
      ("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
      to 3.10 upwards but the fix can be applied (with minor modifications) to
      kernels as old as 2.6.32.
      Signed-off-by: NChristoph Schulz <develop@kristov.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8a3e41c
  2. 14 7月, 2014 1 次提交
  3. 12 7月, 2014 3 次提交
  4. 11 7月, 2014 1 次提交
  5. 10 7月, 2014 5 次提交
  6. 09 7月, 2014 6 次提交
  7. 08 7月, 2014 5 次提交
    • O
      net/mlx4_en: Don't configure the HW vxlan parser when vxlan offloading isn't set · e326f2f1
      Or Gerlitz 提交于
      The add_vxlan_port ndo driver code was wrongly testing whether HW vxlan offloads
      are supported by the device instead of checking if they are currently enabled.
      
      This causes the driver to configure the HW parser to conduct matching for vxlan
      packets but since no steering rules were set, vxlan packets are dropped on RX.
      
      Fix that by doing the right test, as done in the del_vxlan_port ndo handler.
      
      Fixes: 1b136de1 ('net/mlx4: Implement vxlan ndo calls')
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e326f2f1
    • B
      net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2 · 8dcb4b15
      Bernd Wachter 提交于
      There's a new version of the Telewell 4G modem working with, but not
      recognized by this driver.
      Signed-off-by: NBernd Wachter <bernd.wachter@jolla.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8dcb4b15
    • D
      Revert "net: stmmac: add platform init/exit for Altera's ARM socfpga" · 26a9ebca
      David S. Miller 提交于
      This reverts commit 0acf1676.
      
      Breaks the build due to missing reference to phy_resume in
      the resulting dwmac-socfpga.o object.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26a9ebca
    • Z
      powerpc/ucc_geth: deal with a compile warning · 8844a006
      Zhao Qiang 提交于
      deal with a compile warning: comparison between
      'enum qe_fltr_largest_external_tbl_lookup_key_size'
      and 'enum qe_fltr_tbl_lookup_key_size'
      
      the code:
      	"if (ug_info->largestexternallookupkeysize ==
      	     QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES)"
      is warned because different enum, so modify it.
      
      	"enum qe_fltr_largest_external_tbl_lookup_key_size
      	             largestexternallookupkeysize;
      
      	enum qe_fltr_tbl_lookup_key_size {
      		 QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES
      			 = 0x3f,         /* LookupKey parsed by the Generate LookupKey
      					    CMD is truncated to 8 bytes */
      		 QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES
      			 = 0x5f,         /* LookupKey parsed by the Generate LookupKey
      					    CMD is truncated to 16 bytes */
      	 };
      
      	 /* QE FLTR extended filtering Largest External Table Lookup Key Size */
      	 enum qe_fltr_largest_external_tbl_lookup_key_size {
      		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_NONE
      			 = 0x0,/* not used */
      		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_8_BYTES
      			 = QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES,        /* 8 bytes */
      		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_16_BYTES
      			 = QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES,       /* 16 bytes */
      	 };"
      Signed-off-by: NZhao Qiang <B45475@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8844a006
    • A
      rt2800usb: Don't perform DMA from stack · 2c4db12e
      Andrea Merello 提交于
      Function rt2800usb_autorun_detect() passes the address of a variable
      allocated onto the stack to be used for DMA by the USB layer. This has
      been caught by my debugging-enabled kernel.
      
      This patch change things in order to allocate that variable via
      kmalloc, and it adjusts things to handle the kmalloc failure case,
      propagating the error.
      
      [ 7363.238852] ------------[ cut here ]------------
      [ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0()
      [ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4]
      [ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib]
      [ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G           O  3.16.0-rc3-wl+ #31
      [ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
      [ 7363.297511]  0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758
      [ 7363.305062]  ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0
      [ 7363.312622]  ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8
      [ 7363.320161] Call Trace:
      [ 7363.322661]  [<ffffffff8175dcad>] dump_stack+0x4d/0x6f
      [ 7363.327847]  [<ffffffff8106d372>] warn_slowpath_common+0x82/0xb0
      [ 7363.333893]  [<ffffffff8106d3e7>] warn_slowpath_fmt+0x47/0x50
      [ 7363.339686]  [<ffffffff813a93b4>] check_for_stack+0xa4/0xf0
      [ 7363.345298]  [<ffffffff813a995c>] debug_dma_map_page+0x10c/0x150
      [ 7363.351367]  [<ffffffff81521bd9>] usb_hcd_map_urb_for_dma+0x229/0x720
      [ 7363.357890]  [<ffffffff8152256d>] usb_hcd_submit_urb+0x2fd/0x930
      [ 7363.363929]  [<ffffffff810eac31>] ? irq_work_queue+0x71/0xd0
      [ 7363.369617]  [<ffffffff810ab5a7>] ? wake_up_klogd+0x37/0x50
      [ 7363.375219]  [<ffffffff810ab7a5>] ? console_unlock+0x1e5/0x420
      [ 7363.381081]  [<ffffffff810abc25>] ? vprintk_emit+0x245/0x530
      [ 7363.386773]  [<ffffffff81523d3c>] usb_submit_urb+0x30c/0x580
      [ 7363.392462]  [<ffffffff81524295>] usb_start_wait_urb+0x65/0xf0
      [ 7363.398325]  [<ffffffff815243ed>] usb_control_msg+0xcd/0x110
      [ 7363.404014]  [<ffffffffa005514d>] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb]
      [ 7363.411544]  [<ffffffffa0074292>] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb]
      [ 7363.418986]  [<ffffffffa0074aa1>] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb]
      [ 7363.426168]  [<ffffffffa0063ffd>] rt2800_probe_hw+0x11d/0xf90 [rt2800lib]
      [ 7363.432989]  [<ffffffffa0074b7d>] rt2800usb_probe_hw+0xd/0x50 [rt2800usb]
      [ 7363.439808]  [<ffffffffa00453d8>] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib]
      [ 7363.446992]  [<ffffffffa00bfa48>] ? ieee80211_led_names+0xb8/0x100 [mac80211]
      [ 7363.454156]  [<ffffffffa0056116>] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb]
      [ 7363.460971]  [<ffffffffa0074250>] rt2800usb_probe+0x10/0x20 [rt2800usb]
      [ 7363.467616]  [<ffffffff8152799e>] usb_probe_interface+0xce/0x1c0
      [ 7363.473651]  [<ffffffff81480c20>] really_probe+0x70/0x240
      [ 7363.479079]  [<ffffffff81480f01>] __driver_attach+0xa1/0xb0
      [ 7363.484682]  [<ffffffff81480e60>] ? __device_attach+0x70/0x70
      [ 7363.490461]  [<ffffffff8147eef3>] bus_for_each_dev+0x63/0xa0
      [ 7363.496146]  [<ffffffff814807c9>] driver_attach+0x19/0x20
      [ 7363.501570]  [<ffffffff81480468>] bus_add_driver+0x178/0x220
      [ 7363.507270]  [<ffffffff8148151b>] driver_register+0x5b/0xe0
      [ 7363.512874]  [<ffffffff815271b0>] usb_register_driver+0xa0/0x170
      [ 7363.518905]  [<ffffffffa007a000>] ? 0xffffffffa0079fff
      [ 7363.524074]  [<ffffffffa007a01e>] rt2800usb_driver_init+0x1e/0x20 [rt2800usb]
      [ 7363.531247]  [<ffffffff810002d4>] do_one_initcall+0x84/0x1b0
      [ 7363.536932]  [<ffffffff8113aa60>] ? kfree+0xd0/0x110
      [ 7363.541931]  [<ffffffff8112730a>] ? __vunmap+0xaa/0xf0
      [ 7363.547538]  [<ffffffff810ca07e>] load_module+0x1aee/0x2040
      [ 7363.553141]  [<ffffffff810c6f10>] ? store_uevent+0x50/0x50
      [ 7363.558676]  [<ffffffff810ca66e>] SyS_init_module+0x9e/0xc0
      [ 7363.564285]  [<ffffffff81764012>] system_call_fastpath+0x16/0x1b
      [ 7363.570338] ---[ end trace 01ef5f822bea9882 ]---
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2c4db12e
  8. 04 7月, 2014 2 次提交
  9. 03 7月, 2014 8 次提交
    • E
      iwlwifi: dvm: don't enable CTS to self · 43d826ca
      Emmanuel Grumbach 提交于
      We should always prefer to use full RTS protection. Using
      CTS to self gives a meaningless improvement, but this flow
      is much harder for the firmware which is likely to have
      issues with it.
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      43d826ca
    • V
      net: stmmac: Remove unneeded I/O read caught by cppcheck · c8df8ce3
      Vince Bridgers 提交于
      Cppcheck found a case where a local variable was being assigned a value,
      but not used. There seems to be no reason to read this register before
      assigning a new value, so addressing thie issue.
      
      cppcheck --force --enable=all --inline-suppr . shows ...
      
      Variable 'value' is reassigned a value before the old one has been used.
      Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8df8ce3
    • V
      net: stmmac: Correct duplicate if/then/else case found by cppcheck · 43d24e48
      Vince Bridgers 提交于
      Cppcheck found a duplicate if/then/else case where a receive descriptor
      was being processed. This patch corrects that issue.
      
      cppcheck --force --enable=all --inline-suppr .
      ...
      Checking enh_desc.c...
      [enh_desc.c:148] -> [enh_desc.c:144]: (style) Found duplicate if expressions.
      ...
      Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43d24e48
    • V
      net: stmmac: add platform init/exit for Altera's ARM socfpga · 0acf1676
      Vince Bridgers 提交于
      This patch adds platform init/exit functions and modifications to support
      suspend/resume for the Altera Cyclone 5 SOC Ethernet controller. The platform
      exit function puts the controller into reset using the socfpga reset
      controller driver. The platform init function sets up the Synopsys mac by
      first making sure the Ethernet controller is held in reset, programming the
      phy mode through external support logic, then deasserts reset through
      the socfpga reset manager driver.
      Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0acf1676
    • A
      net/mlx4_en: IRQ affinity hint is not cleared on port down · bb273617
      Amir Vadai 提交于
      Need to remove affinity hint at mlx4_en_deactivate_cq() and not at
      mlx4_en_destroy_cq() - since affinity_mask might be free'd while still
      being used by procfs.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb273617
    • A
      net/mlx4_en: Don't use irq_affinity_notifier to track changes in IRQ affinity map · 35f6f453
      Amir Vadai 提交于
      IRQ affinity notifier can only have a single notifier - cpu_rmap
      notifier. Can't use it to track changes in IRQ affinity map.
      Detect IRQ affinity changes by comparing CPU to current IRQ affinity map
      during NAPI poll thread.
      
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Ben Hutchings <ben@decadent.org.uk>
      Fixes: 2eacc23c ("net/mlx4_core: Enforce irq affinity changes immediatly")
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35f6f453
    • M
      defxx: Fix !DYNAMIC_BUFFERS compilation warnings · 1b037474
      Maciej W. Rozycki 提交于
      This fixes compilation warnings:
      
      drivers/net/fddi/defxx.c:294: warning: 'dfx_rcv_flush' declared inline after being called
      drivers/net/fddi/defxx.c:294: warning: previous declaration of 'dfx_rcv_flush' was here
      drivers/net/fddi/defxx.c:2854: warning: 'my_skb_align' defined but not used
      
      triggered when the driver is built with DYNAMIC_BUFFERS undefined.  Code
      tested to work just fine with these changes and a few DEFPA and DEFTA
      boards.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b037474
    • M
      defxx: Remove an incorrectly inverted preprocessor conditional · f46d53d0
      Maciej W. Rozycki 提交于
      The RX handler of the driver has two paths switched between, depending on
      the size of the frame received, as determined by SKBUFF_RX_COPYBREAK.
      
      When a small frame is received, a new skb allocated has data space large
      enough to hold the incoming frame only, and data is copied there from the
      original skb whose buffer is returned to the DMA RX ring; in that case
      `rx_in_place' is 0.  When a large frame is received, a new skb allocated
      has data space large enough to hold the largest frame possible, including
      the overhead for alignment, the receive status and padding, over 4.5kiB
      overall, and its buffer is placed on the DMA RX ring while the original
      buffer is passed up to the network stack avoiding the need to copy data;
      in that case `rx_in_place' is 1.
      
      However the latter scenario is only possible when dynamic buffers are
      used, as determined by DYNAMIC_BUFFERS, because otherwise the buffers used
      for the DMA RX ring are fixed at the time the interface is brought up.
      
      That leads to an observation that the preprocessor conditional around the
      `rx_in_place' check is inverted, the check only really matters when
      dynamic buffers are in use.  It has gone unnoticed for many years since
      support for using dynamic buffers on the DMA RX ring was introduced in
      2.1.40 -- because the only problem that results is in the case where
      `rx_in_place' is 1 frame data received is unnecessarily copied to the
      newly-allocated buffer, before the buffer placed on the the DMA receive RX
      and its contents ignored.  Therefore the only symptom is some performance
      loss.
      
      Rather than flipping the condition though I decided to discard the
      conditional altogether -- in the case of static buffers `rx_in_place' is
      always 0 so GCC will optimise the C conditional away instead.
      
      Tested on a few DEFPA and DEFTA boards successfully using both small and
      large frames, both with DYNAMIC_BUFFERS defined and with the macro
      undefined.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f46d53d0
  10. 02 7月, 2014 3 次提交