1. 02 Oct, 2020 5 commits
    • Willy Liu's avatar
      net: phy: realtek: Modify 2.5G PHY name to RTL8226 · 7a333af6
      Willy Liu authored
      Realtek single-chip Ethernet PHY solutions can be separated as below:
      10M/100Mbps: RTL8201X
      1Gbps: RTL8211X
      2.5Gbps: RTL8226/RTL8221X
      RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY.
      Since RTL8226 is single port only, realtek changes its name to RTL8221B from
      the second version.
      PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840.
      
      RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus
      controller and embedded memory.
      Signed-off-by: default avatarWilly Liu <willy.liu@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a333af6
    • Jing Xiangfeng's avatar
      caif_virtio: Remove redundant initialization of variable err · f1638a4c
      Jing Xiangfeng authored
      After commit a8c7687b ("caif_virtio: Check that vringh_config is not
      null"), the variable err is being initialized with '-EINVAL' that is
      meaningless. So remove it.
      Signed-off-by: default avatarJing Xiangfeng <jingxiangfeng@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1638a4c
    • Ye Bin's avatar
      net-sysfs: Fix inconsistent of format with argument type in net-sysfs.c · 000fe268
      Ye Bin authored
      Fix follow warnings:
      [net/core/net-sysfs.c:1161]: (warning) %u in format string (no. 1)
      	requires 'unsigned int' but the argument type is 'int'.
      [net/core/net-sysfs.c:1162]: (warning) %u in format string (no. 1)
      	requires 'unsigned int' but the argument type is 'int'.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      000fe268
    • Ye Bin's avatar
      pktgen: Fix inconsistent of format with argument type in pktgen.c · 32be425b
      Ye Bin authored
      Fix follow warnings:
      [net/core/pktgen.c:925]: (warning) %u in format string (no. 1)
      	requires 'unsigned int' but the argument type is 'signed int'.
      [net/core/pktgen.c:942]: (warning) %u in format string (no. 1)
      	requires 'unsigned int' but the argument type is 'signed int'.
      [net/core/pktgen.c:962]: (warning) %u in format string (no. 1)
      	requires 'unsigned int' but the argument type is 'signed int'.
      [net/core/pktgen.c:984]: (warning) %u in format string (no. 1)
      	requires 'unsigned int' but the argument type is 'signed int'.
      [net/core/pktgen.c:1149]: (warning) %d in format string (no. 1)
      	requires 'int' but the argument type is 'unsigned int'.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32be425b
    • Xie He's avatar
      drivers/net/wan/hdlc_fr: Correctly handle special skb->protocol values · 8306266c
      Xie He authored
      The fr_hard_header function is used to prepend the header to skbs before
      transmission. It is used in 3 situations:
      1) When a control packet is generated internally in this driver;
      2) When a user sends an skb on an Ethernet-emulating PVC device;
      3) When a user sends an skb on a normal PVC device.
      
      These 3 situations need to be handled differently by fr_hard_header.
      Different headers should be prepended to the skb in different situations.
      
      Currently fr_hard_header distinguishes these 3 situations using
      skb->protocol. For situation 1 and 2, a special skb->protocol value
      will be assigned before calling fr_hard_header, so that it can recognize
      these 2 situations. All skb->protocol values other than these special ones
      are treated by fr_hard_header as situation 3.
      
      However, it is possible that in situation 3, the user sends an skb with
      one of the special skb->protocol values. In this case, fr_hard_header
      would incorrectly treat it as situation 1 or 2.
      
      This patch tries to solve this issue by using skb->dev instead of
      skb->protocol to distinguish between these 3 situations. For situation
      1, skb->dev would be NULL; for situation 2, skb->dev->type would be
      ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI.
      
      This way fr_hard_header would be able to distinguish these 3 situations
      correctly regardless what skb->protocol value the user tries to use in
      situation 3.
      
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8306266c
  2. 01 Oct, 2020 35 commits