1. 07 4月, 2020 9 次提交
  2. 04 4月, 2020 5 次提交
    • C
      net: dsa: mt7530: fix null pointer dereferencing in port5 setup · 0452800f
      Chuanhong Guo 提交于
      The 2nd gmac of mediatek soc ethernet may not be connected to a PHY
      and a phy-handle isn't always available.
      Unfortunately, mt7530 dsa driver assumes that the 2nd gmac is always
      connected to switch port 5 and setup mt7530 according to phy address
      of 2nd gmac node, causing null pointer dereferencing when phy-handle
      isn't defined in dts.
      This commit fix this setup code by checking return value of
      of_parse_phandle before using it.
      
      Fixes: 38f790a8 ("net: dsa: mt7530: Add support for port 5")
      Signed-off-by: NChuanhong Guo <gch981213@gmail.com>
      Reviewed-by: NVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: NRené van Dorst <opensource@vdorst.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0452800f
    • G
      mptcp: add some missing pr_fmt defines · c85adced
      Geliang Tang 提交于
      Some of the mptcp logs didn't print out the format string:
      
      [  185.651493] DSS
      [  185.651494] data_fin=0 dsn64=0 use_map=0 ack64=1 use_ack=1
      [  185.651494] data_ack=13792750332298763796
      [  185.651495] MPTCP: msk=00000000c4b81cfc ssk=000000009743af53 data_avail=0 skb=0000000063dc595d
      [  185.651495] MPTCP: msk=00000000c4b81cfc ssk=000000009743af53 status=0
      [  185.651495] MPTCP: msk ack_seq=9bbc894565aa2f9a subflow ack_seq=9bbc894565aa2f9a
      [  185.651496] MPTCP: msk=00000000c4b81cfc ssk=000000009743af53 data_avail=1 skb=0000000012e809e1
      
      So this patch added these missing pr_fmt defines. Then we can get the same
      format string "MPTCP" in all mptcp logs like this:
      
      [  142.795829] MPTCP: DSS
      [  142.795829] MPTCP: data_fin=0 dsn64=0 use_map=0 ack64=1 use_ack=1
      [  142.795829] MPTCP: data_ack=8089704603109242421
      [  142.795830] MPTCP: msk=00000000133a24e0 ssk=000000002e508c64 data_avail=0 skb=00000000d5f230df
      [  142.795830] MPTCP: msk=00000000133a24e0 ssk=000000002e508c64 status=0
      [  142.795831] MPTCP: msk ack_seq=66790290f1199d9b subflow ack_seq=66790290f1199d9b
      [  142.795831] MPTCP: msk=00000000133a24e0 ssk=000000002e508c64 data_avail=1 skb=00000000de5aca2e
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Reviewed-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c85adced
    • O
      net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers · 6110dff7
      Oleksij Rempel 提交于
      After the power-down bit is cleared, the chip internally triggers a
      global reset. According to the KSZ9031 documentation, we have to wait at
      least 1ms for the reset to finish.
      
      If the chip is accessed during reset, read will return 0xffff, while
      write will be ignored. Depending on the system performance and MDIO bus
      speed, we may or may not run in to this issue.
      
      This bug was discovered on an iMX6QP system with KSZ9031 PHY and
      attached PHY interrupt line. If IRQ was used, the link status update was
      lost. In polling mode, the link status update was always correct.
      
      The investigation showed, that during a read-modify-write access, the
      read returned 0xffff (while the chip was still in reset) and
      corresponding write hit the chip _after_ reset and triggered (due to the
      0xffff) another reset in an undocumented bit (register 0x1f, bit 1),
      resulting in the next write being lost due to the new reset cycle.
      
      This patch fixes the issue by adding a 1...2 ms sleep after the
      genphy_resume().
      
      Fixes: 836384d2 ("net: phy: micrel: Add specific suspend")
      Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6110dff7
    • C
      net_sched: fix a missing refcnt in tcindex_init() · a8eab6d3
      Cong Wang 提交于
      The initial refcnt of struct tcindex_data should be 1,
      it is clear that I forgot to set it to 1 in tcindex_init().
      This leads to a dec-after-zero warning.
      
      Reported-by: syzbot+8325e509a1bf83ec741d@syzkaller.appspotmail.com
      Fixes: 304e0242 ("net_sched: add a temporary refcnt for struct tcindex_data")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: Paul E. McKenney <paulmck@kernel.org>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8eab6d3
    • J
      net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting · 3e1221ac
      Jisheng Zhang 提交于
      Commit 9463c445 ("net: stmmac: dwmac1000: Clear unused address
      entries") cleared the unused mac address entries, but introduced an
      out-of bounds mac address register programming bug -- After setting
      the secondary unicast mac addresses, the "reg" value has reached
      netdev_uc_count() + 1, thus we should only clear address entries
      if (addr < perfect_addr_number)
      
      Fixes: 9463c445 ("net: stmmac: dwmac1000: Clear unused address entries")
      Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e1221ac
  3. 03 4月, 2020 5 次提交
  4. 02 4月, 2020 21 次提交