1. 17 May, 2021 9 commits
    • Yang Shen's avatar
      net: broadcom: bnx2x: Fix wrong function name in comments · 76d85049
      Yang Shen authored
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:13595: warning: expecting prototype for bnx2x_get_num_none_def_sbs(). Prototype was for bnx2x_get_num_non_def_sbs() instead
       drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:4165: warning: expecting prototype for atomic_add_ifless(). Prototype was for __atomic_add_ifless() instead
       drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c:4193: warning: expecting prototype for atomic_dec_ifmoe(). Prototype was for __atomic_dec_ifmoe() instead
      
      Cc: Ariel Elior <aelior@marvell.com>
      Cc: Sudarsana Kalluru <skalluru@marvell.com>
      Cc: GR-everest-linux-l2@marvell.com
      Signed-off-by: default avatarYang Shen <shenyang39@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76d85049
    • Yang Shen's avatar
      net: atheros: atl1x: Fix wrong function name in comments · c706c75a
      Yang Shen authored
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/ethernet/atheros/atlx/atl1.c:1020: warning: expecting prototype for atl1_setup_mem_resources(). Prototype was for atl1_setup_ring_resources() instead
      
      Cc: Chris Snook <chris.snook@gmail.com>
      Signed-off-by: default avatarYang Shen <shenyang39@huawei.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c706c75a
    • Yang Shen's avatar
      net: atheros: atl1e: Fix wrong function name in comments · b43e1554
      Yang Shen authored
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/ethernet/atheros/atl1e/atl1e_main.c:367: warning: expecting prototype for atl1e_set_mac(). Prototype was for atl1e_set_mac_addr() instead
       drivers/net/ethernet/atheros/atl1e/atl1e_main.c:796: warning: expecting prototype for atl1e_setup_mem_resources(). Prototype was for atl1e_setup_ring_resources() instead
      
      Cc: Chris Snook <chris.snook@gmail.com>
      Signed-off-by: default avatarYang Shen <shenyang39@huawei.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b43e1554
    • Yang Shen's avatar
      net: atheros: atl1c: Fix wrong function name in comments · 8965c1c5
      Yang Shen authored
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/ethernet/atheros/atl1c/atl1c_main.c:442: warning: expecting prototype for atl1c_set_mac(). Prototype was for atl1c_set_mac_addr() instead
       drivers/net/ethernet/atheros/atl1c/atl1c_main.c:969: warning: expecting prototype for atl1c_setup_mem_resources(). Prototype was for atl1c_setup_ring_resources() instead
       drivers/net/ethernet/atheros/atl1c/atl1c_main.c:1375: warning: expecting prototype for atl1c_configure(). Prototype was for atl1c_configure_mac() instead
      
      Cc: Chris Snook <chris.snook@gmail.com>
      Signed-off-by: default avatarYang Shen <shenyang39@huawei.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8965c1c5
    • Yang Shen's avatar
      net: arc: Demote non-compliant kernel-doc headers · 1d7f7eca
      Yang Shen authored
      Fixes the following W=1 kernel build warning(s):
      
       drivers/net/ethernet/arc/emac_rockchip.c:18: warning: expecting prototype for emac(). Prototype was for DRV_NAME() instead
      Signed-off-by: default avatarYang Shen <shenyang39@huawei.com>
      Reviewed-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d7f7eca
    • Heiner Kallweit's avatar
      r8169: use KBUILD_MODNAME instead of own module name definition · 7cb7541a
      Heiner Kallweit authored
      Remove own module name definition and use KBUILD_MODNAME instead.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cb7541a
    • David S. Miller's avatar
      Merge branch 'ipv4-unicast' · 58fee5fc
      David S. Miller authored
      Seth David Schoen says:
      
      ====================
      Treat IPv4 lowest address as ordinary unicast address
      
      Treat the lowest address in a subnet (the address within the subnet
      which contains all 0 bits) as an ordinary unicast address instead
      of as a potential second broadcast address.  For example, in subnet
      192.168.17.24/29, which contains 8 addresses, make address 192.168.17.24
      usable as a normal unicast address (while continuing to support
      192.168.17.31 as a broadcast address).
      
      Since EVERY network number or subnet formerly had its host number 0
      reserved, this patchset adds 1 more usable host address to every network
      and subnet (i.e., 2^(32-n)-1 instead of 2^(32-n)-2 addresses available
      for assignment on each IPv4 /n subnet).  For small subnets, this is a
      significant gain; instead of 6 usable host addresses, a /29 would now
      contain 7, a 16% increase.
      
      The reserving of host number 0 for broadcast came about in RFC 1122 from
      1989 (page 31, "IP addresses are not permitted to have the value 0 or -1
      for any of the <Host-number>, <Network-number>, or <Subnet-number>
      fields (except in the special cases listed above)" and page 66, "There
      is a class of hosts [4.2BSD Unix and its derivatives, but not 4.3BSD]
      that use non-standard broadcast address forms, substituting 0 for -1.
      All hosts SHOULD recognize and accept any of these non-standard
      broadcast addresses as the destination address of an incoming
      datagram.").  This has been repeated in subsequent RFCs, always with
      backwards-compatibility rationales.  Network troubles (broadcast storms)
      ensued when some early hosts on a LAN treated the lowest address as
      unicast and others treated it as broadcast.  Multiple 1989 changes to IP
      successfully prevented these.  The key was adding the layering violation
      rule requiring hosts to ignore all IP datagrams with unicast destination
      addresses that were received in low-level (Ethernet) broadcasts.  That
      change is still in effect, and this patchset does not alter it.  All
      operating systems since 4.3BSD, including all the current BSD OSes, now
      use the standard IP broadcast address.  4.2BSD has been obsolete for
      more than 30 years, and all modern hosts ignore hardware broadcasts
      containing unicast IP addresses, so there is no modern likelihood of
      broadcast storms even when hosts disagree on the unicast vs. broadcast
      status of a given address.
      
      Tests with this patchset show that other Linux hosts on the local segment
      simply ignore a host numbered with the lowest address, both for incoming
      and outgoing packet purposes.  They don't interoperate with it, but they
      also don't cause broadcast storms or any other malfunction.  If patched,
      they have no trouble interoperating with a host at the lowest address.
      
      Unmodified "distant" hosts that are not on the same segment successfully
      interoperate, as long as the gateway on the local segment, and the local
      host itself using the lowest address, have this patch.  (Distant hosts
      have no way of knowing whether a given address is the lowest address
      in a faraway network segment, so they treat it no differently than any
      other unicast address.)  This means that each local site can change this
      behavior locally, resulting immediately in global interoperability with
      the newly usable lowest local address.
      
      Modern software and documentation continues to use the definition of the
      directed, or "net-directed", broadcast address as "a host ID of all one
      bits".  The Internet no longer gets any benefit from having two different
      broadcast addresses usable on every Ethernet segment.  I have not been
      able to find any documentation that suggests that users or software should
      ever intentionally use the all-zero form, or that justifies it other than
      as a historic Berkeleyism.  RFCs 1112, 1812, and 3021 state that hosts and
      routers need to maintain compatibility with the old form -- but they give
      no rationale other than the past existence of the 4.2BSD behavior.
      
      We're happy to provide more historical details or information about
      behavior of other systems in this regard by e-mail or as future patches
      to kernel documentation files.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58fee5fc
    • Seth David Schoen's avatar
      selftests: Lowest IPv4 address in a subnet is valid · 6101ca03
      Seth David Schoen authored
      Expect the lowest IPv4 address in a subnet to be assignable
      and addressable as a unicast (non-broadcast) address on a
      local network segment.
      Signed-off-by: default avatarSeth David Schoen <schoen@loyalty.org>
      Suggested-by: default avatarJohn Gilmore <gnu@toad.com>
      Acked-by: default avatarDave Taht <dave.taht@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6101ca03
    • Seth David Schoen's avatar
      ip: Treat IPv4 segment's lowest address as unicast · 94c821c7
      Seth David Schoen authored
      Treat only the highest, not the lowest, IPv4 address within a local
      subnet as a broadcast address.
      Signed-off-by: default avatarSeth David Schoen <schoen@loyalty.org>
      Suggested-by: default avatarJohn Gilmore <gnu@toad.com>
      Acked-by: default avatarDave Taht <dave.taht@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94c821c7
  2. 14 May, 2021 31 commits