1. 16 8月, 2019 4 次提交
  2. 15 8月, 2019 1 次提交
  3. 14 8月, 2019 3 次提交
  4. 13 8月, 2019 1 次提交
    • A
      net: phy: at803x: stop switching phy delay config needlessly · bb0ce4c1
      André Draszik 提交于
      This driver does a funny dance disabling and re-enabling
      RX and/or TX delays. In any of the RGMII-ID modes, it first
      disables the delays, just to re-enable them again right
      away. This looks like a needless exercise.
      
      Just enable the respective delays when in any of the
      relevant 'id' modes, and disable them otherwise.
      
      Also, remove comments which don't add anything that can't be
      seen by looking at the code.
      Signed-off-by: NAndré Draszik <git@andred.net>
      CC: Andrew Lunn <andrew@lunn.ch>
      CC: Florian Fainelli <f.fainelli@gmail.com>
      CC: Heiner Kallweit <hkallweit1@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb0ce4c1
  5. 12 8月, 2019 4 次提交
    • N
      net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx · 125b7e09
      Nathan Chancellor 提交于
      clang warns:
      
      drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
      '&&' with constant operand [-Wconstant-logical-operand]
                              if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                        ^  ~~~~~~~~~~~~
      drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
      bitwise operation
                              if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                        ^~
                                                        &
      drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
      silence this warning
                              if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                       ~^~~~~~~~~~~~~~~
      1 warning generated.
      
      Explicitly check that NET_IP_ALIGN is not zero, which matches how this
      is checked in other parts of the tree. Because NET_IP_ALIGN is a build
      time constant, this check will be constant folded away during
      optimization.
      
      Fixes: 82a9928d ("tc35815: Enable StripCRC feature")
      Link: https://github.com/ClangBuiltLinux/linux/issues/608Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      125b7e09
    • P
      mlxsw: spectrum_ptp: Keep unmatched entries in a linked list · 8028ccda
      Petr Machata 提交于
      To identify timestamps for matching with their packets, Spectrum-1 uses a
      five-tuple of (port, direction, domain number, message type, sequence ID).
      If there are several clients from the same domain behind a single port
      sending Delay_Req's, the only thing differentiating these packets, as far
      as Spectrum-1 is concerned, is the sequence ID. Should sequence IDs between
      individual clients be similar, conflicts may arise. That is not a problem
      to hardware, which will simply deliver timestamps on a first comes, first
      served basis.
      
      However the driver uses a simple hash table to store the unmatched pieces.
      When a new conflicting piece arrives, it pushes out the previously stored
      one, which if it is a packet, is delivered without timestamp. Later on as
      the corresponding timestamps arrive, the first one is mismatched to the
      second packet, and the second one is never matched and eventually is GCd.
      
      To correct this issue, instead of using a simple rhashtable, use rhltable
      to keep the unmatched entries.
      
      Previously, a found unmatched entry would always be removed from the hash
      table. That is not the case anymore--an incompatible entry is left in the
      hash table. Therefore removal from the hash table cannot be used to confirm
      the validity of the looked-up pointer, instead the lookup would simply need
      to be redone. Therefore move it inside the critical section. This
      simplifies a lot of the code.
      
      Fixes: 87486427 ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8028ccda
    • J
      net: nps_enet: Fix function names in doc comments · d81f4141
      Jonathan Neuschäfer 提交于
      Adjust the function names in two doc comments to match the corresponding
      functions.
      Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d81f4141
    • D
      netdevsim: Restore per-network namespace accounting for fib entries · 59c84b9f
      David Ahern 提交于
      Prior to the commit in the fixes tag, the resource controller in netdevsim
      tracked fib entries and rules per network namespace. Restore that behavior.
      
      Fixes: 5fc49422 ("netdevsim: create devlink instance per netdevsim instance")
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59c84b9f
  6. 10 8月, 2019 2 次提交
  7. 09 8月, 2019 16 次提交
  8. 07 8月, 2019 9 次提交
    • V
      net: dsa: sja1105: Really fix panic on unregistering PTP clock · 6cb0abbd
      Vladimir Oltean 提交于
      The IS_ERR_OR_NULL(priv->clock) check inside
      sja1105_ptp_clock_unregister() is preventing cancel_delayed_work_sync
      from actually being run.
      
      Additionally, sja1105_ptp_clock_unregister() does not actually get run,
      when placed in sja1105_remove(). The DSA switch gets torn down, but the
      sja1105 module does not get unregistered. So sja1105_ptp_clock_unregister
      needs to be moved to sja1105_teardown, to be symmetrical with
      sja1105_ptp_clock_register which is called from the DSA sja1105_setup.
      
      It is strange to fix a "fixes" patch, but the probe failure can only be
      seen when the attached PHY does not respond to MDIO (issue which I can't
      pinpoint the reason to) and it goes away after I power-cycle the board.
      This time the patch was validated on a failing board, and the kernel
      panic from the fixed commit's message can no longer be seen.
      
      Fixes: 29dd908d ("net: dsa: sja1105: Cancel PTP delayed work on unregister")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cb0abbd
    • V
      net: dsa: sja1105: Use the LOCKEDS bit for SJA1105 E/T as well · 4b7da3d8
      Vladimir Oltean 提交于
      It looks like the FDB dump taken from first-generation switches also
      contains information on whether entries are static or not. So use that
      instead of searching through the driver's tables.
      
      Fixes: d7637782 ("net: dsa: sja1105: Implement is_static for FDB entries on E/T")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b7da3d8
    • V
      net: dsa: sja1105: Fix broken learning with vlan_filtering disabled · 6d7c7d94
      Vladimir Oltean 提交于
      When put under a bridge with vlan_filtering 0, the SJA1105 ports will
      flood all traffic as if learning was broken. This is because learning
      interferes with the rx_vid's configured by dsa_8021q as unique pvid's.
      
      So learning technically still *does* work, it's just that the learnt
      entries never get matched due to their unique VLAN ID.
      
      The setting that saves the day is Shared VLAN Learning, which on this
      switch family works exactly as desired: VLAN tagging still works
      (untagged traffic gets the correct pvid) and FDB entries are still
      populated with the correct contents including VID. Also, a frame cannot
      violate the forwarding domain restrictions enforced by its classified
      VLAN. It is just that the VID is ignored when looking up the FDB for
      taking a forwarding decision (selecting the egress port).
      
      This patch activates SVL, and the result is that frames with a learnt
      DMAC are no longer flooded in the scenario described above.
      
      Now exactly *because* SVL works as desired, we have to revisit some
      earlier patches:
      
      - It is no longer necessary to manipulate the VID of the 'bridge fdb
        {add,del}' command when vlan_filtering is off. This is because now,
        SVL is enabled for that case, so the actual VID does not matter*.
      
      - It is still desirable to hide dsa_8021q VID's in the FDB dump
        callback. But right now the dump callback should no longer hide
        duplicates (one per each front panel port's pvid, plus one for the
        VLAN that the CPU port is going to tag a TX frame with), because there
        shouldn't be any (the switch will match a single FDB entry no matter
        its VID anyway).
      
      * Not really... It's no longer necessary to transform a 'bridge fdb add'
        into 5 fdb add operations, but the user might still add a fdb entry with
        any vid, and all of them would appear as duplicates in 'bridge fdb
        show'. So force a 'bridge fdb add' to insert the VID of 0**, so that we
        can prune the duplicates at insertion time.
      
      ** The VID of 0 is better than 1 because it is always guaranteed to be
         in the ports' hardware filter. DSA also avoids putting the VID inside
         the netlink response message towards the bridge driver when we return
         this particular VID, which makes it suitable for FDB entries learnt
         with vlan_filtering off.
      
      Fixes: 227d07a0 ("net: dsa: sja1105: Add support for traffic through standalone ports")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NGeorg Waibel <georg.waibel@sensor-technik.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d7c7d94
    • N
      net: dsa: qca8k: Add of_node_put() in qca8k_setup_mdio_bus() · f26e0cca
      Nishka Dasgupta 提交于
      Each iteration of for_each_available_child_of_node() puts the previous
      node, but in the case of a return from the middle of the loop, there
      is no put, thus causing a memory leak. Hence add an of_node_put() before
      the return.
      Additionally, the local variable ports in the function
      qca8k_setup_mdio_bus() takes the return value of of_get_child_by_name(),
      which gets a node but does not put it. If the function returns without
      putting ports, it may cause a memory leak. Hence put ports before the
      mid-loop return statement, and also outside the loop after its last usage
      in this function.
      Issues found with Coccinelle.
      Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f26e0cca
    • J
      net: hisilicon: Fix dma_map_single failed on arm64 · 96a50c0d
      Jiangfeng Xiao 提交于
      On the arm64 platform, executing "ifconfig eth0 up" will fail,
      returning "ifconfig: SIOCSIFFLAGS: Input/output error."
      
      ndev->dev is not initialized, dma_map_single->get_dma_ops->
      dummy_dma_ops->__dummy_map_page will return DMA_ERROR_CODE
      directly, so when we use dma_map_single, the first parameter
      is to use the device of platform_device.
      Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96a50c0d
    • J
      net: hisilicon: fix hip04-xmit never return TX_BUSY · f2243b82
      Jiangfeng Xiao 提交于
      TX_DESC_NUM is 256, in tx_count, the maximum value of
      mod(TX_DESC_NUM - 1) is 254, the variable "count" in
      the hip04_mac_start_xmit function is never equal to
      (TX_DESC_NUM - 1), so hip04_mac_start_xmit never
      return NETDEV_TX_BUSY.
      
      tx_count is modified to mod(TX_DESC_NUM) so that
      the maximum value of tx_count can reach
      (TX_DESC_NUM - 1), then hip04_mac_start_xmit can reurn
      NETDEV_TX_BUSY.
      Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2243b82
    • J
      net: hisilicon: make hip04_tx_reclaim non-reentrant · 1a2c070a
      Jiangfeng Xiao 提交于
      If hip04_tx_reclaim is interrupted while it is running
      and then __napi_schedule continues to execute
      hip04_rx_poll->hip04_tx_reclaim, reentrancy occurs
      and oops is generated. So you need to mask the interrupt
      during the hip04_tx_reclaim run.
      
      The kernel oops exception stack is as follows:
      
      Unable to handle kernel NULL pointer dereference
      at virtual address 00000050
      pgd = c0003000
      [00000050] *pgd=80000000a04003, *pmd=00000000
      Internal error: Oops: 206 [#1] SMP ARM
      Modules linked in: hip04_eth mtdblock mtd_blkdevs mtd
      ohci_platform ehci_platform ohci_hcd ehci_hcd
      vfat fat sd_mod usb_storage scsi_mod usbcore usb_common
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.4.185 #1
      Hardware name: Hisilicon A15
      task: c0a250e0 task.stack: c0a00000
      PC is at hip04_tx_reclaim+0xe0/0x17c [hip04_eth]
      LR is at hip04_tx_reclaim+0x30/0x17c [hip04_eth]
      pc : [<bf30c3a4>]    lr : [<bf30c2f4>]    psr: 600e0313
      sp : c0a01d88  ip : 00000000  fp : c0601f9c
      r10: 00000000  r9 : c3482380  r8 : 00000001
      r7 : 00000000  r6 : 000000e1  r5 : c3482000  r4 : 0000000c
      r3 : f2209800  r2 : 00000000  r1 : 00000000  r0 : 00000000
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 32c5387d  Table: 03d28c80  DAC: 55555555
      Process swapper/0 (pid: 0, stack limit = 0xc0a00190)
      Stack: (0xc0a01d88 to 0xc0a02000)
      [<bf30c3a4>] (hip04_tx_reclaim [hip04_eth]) from [<bf30d2e0>]
                                                      (hip04_rx_poll+0x88/0x368 [hip04_eth])
      [<bf30d2e0>] (hip04_rx_poll [hip04_eth]) from [<c04c2d9c>] (net_rx_action+0x114/0x34c)
      [<c04c2d9c>] (net_rx_action) from [<c021eed8>] (__do_softirq+0x218/0x318)
      [<c021eed8>] (__do_softirq) from [<c021f284>] (irq_exit+0x88/0xac)
      [<c021f284>] (irq_exit) from [<c0240090>] (msa_irq_exit+0x11c/0x1d4)
      [<c0240090>] (msa_irq_exit) from [<c02677e0>] (__handle_domain_irq+0x110/0x148)
      [<c02677e0>] (__handle_domain_irq) from [<c0201588>] (gic_handle_irq+0xd4/0x118)
      [<c0201588>] (gic_handle_irq) from [<c0551700>] (__irq_svc+0x40/0x58)
      Exception stack(0xc0a01f30 to 0xc0a01f78)
      1f20:                                     c0ae8b40 00000000 00000000 00000000
      1f40: 00000002 ffffe000 c0601f9c 00000000 ffffffff c0a2257c c0a22440 c0831a38
      1f60: c0a01ec4 c0a01f80 c0203714 c0203718 600e0213 ffffffff
      [<c0551700>] (__irq_svc) from [<c0203718>] (arch_cpu_idle+0x20/0x3c)
      [<c0203718>] (arch_cpu_idle) from [<c025bfd8>] (cpu_startup_entry+0x244/0x29c)
      [<c025bfd8>] (cpu_startup_entry) from [<c054b0d8>] (rest_init+0xc8/0x10c)
      [<c054b0d8>] (rest_init) from [<c0800c58>] (start_kernel+0x468/0x514)
      Code: a40599e5 016086e2 018088e2 7660efe6 (503090e5)
      ---[ end trace 1db21d6d09c49d74 ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      CPU3: stopping
      CPU: 3 PID: 0 Comm: swapper/3 Tainted: G      D    O    4.4.185 #1
      Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a2c070a
    • J
      net: stmmac: tc: Do not return a fragment entry · 4a6a1385
      Jose Abreu 提交于
      Do not try to return a fragment entry from TC list. Otherwise we may not
      clean properly allocated entries.
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a6a1385
    • J
      net: stmmac: Fix issues when number of Queues >= 4 · e8df7e8c
      Jose Abreu 提交于
      When queues >= 4 we use different registers but we were not subtracting
      the offset of 4. Fix this.
      
      Found out by Coverity.
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8df7e8c