The issue fixed for bonding in commit c2edacf8 ("bonding / ipv6: no
addrconf for slaves separately from master") also exists in team driver.
However, we can't just disable ipv6 addrconf for team ports, as 'teamd'
will need it when nsns_ping watch is used in the user space.

Instead of preventing ipv6 addrconf, this patch only prevents RS packets
for team ports, as it did in commit b52e1cce ("ipv6: Don't send rs
packets to the interface of ARPHRD_TUNNEL").

Note that we do not prevent DAD packets, to avoid the changes getting
intricate / hacky. Also, usually sysctl dad_transmits is set to 1 and
only 1 DAD packet will be sent, and by now no libteam user complains
about DAD packets on team ports, unlike RS packets.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Florian Westphal says:

====================
netfilter updates for net-next

This pull request contains changes for the *net-next* tree.

1. Change IPv6 stack to keep conntrack references until ipsec policy
   checks are done, like ipv4, from Madhu Koriginja.
   This update was missed when IPv6 NAT support was added 10 years ago.

2. get rid of old 'compat' structure layout in nf_nat_redirect
   core and move the conversion to the only user that needs the
   old layout for abi reasons. From Jeremy Sowden.

3. Compact some common code paths in nft_redir, also from Jeremy.

4. Time to remove the 'default y' knob so iptables 32bit compat interface
   isn't compiled in by default anymore, from myself.

5. Move ip(6)tables builtin icmp matches to the udptcp one.
   This has the advantage that icmp/icmpv6 match doesn't load the
   iptables/ip6tables modules anymore when iptables-nft is used.
   Also from myself.

* 'main' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
  netfilter: keep conntrack reference until IPsecv6 policy checks are done
  xtables: move icmp/icmpv6 logic to xt_tcpudp
  netfilter: xtables: disable 32bit compat interface by default
  netfilter: nft_masq: deduplicate eval call-backs
  netfilter: nft_redir: use `struct nf_nat_range2` throughout and deduplicate eval call-backs
====================

Link: https://lore.kernel.org/r/20230322210802.6743-1-fw@strlen.deSigned-off-by: Jakub Kicinski <kuba@kernel.org>

One of the most commonly asked questions is "I answered all questions
and don't need to make any code changes, why was the patch not applied".
Document our time honored tradition of asking people to repost with
improved commit messages, to record the answers to reviewer questions.

Take this opportunity to also recommend a change log format.

Link: https://lore.kernel.org/r/20230322231202.265835-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

The load_cpu_fw function has no error return code
and always returns zero. Checking the value returned by
this function does not make sense.
Now checking the value of the return value is misleading when reading
the code. Path with error handling was deleted in 57579f76
("bnx2: Use request_firmware()").
As a result, bnx2_init_cpus() will also return only zero
Therefore, it will be safe to change the type of functions
to void and remove checking to improving readability.

Found by Security Code and Linux Verification
Center (linuxtesting.org) with SVACE
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com>
Link: https://lore.kernel.org/r/20230322162843.3452-1-korotkov.maxim.s@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

In the IPA device sysfs directory, the "version" file can be read to
find out what IPA version is implemented.  The content of this file
is supplied by ipa_version_string(), which needs to be updated to
properly handle IPA v5.0.
Signed-off-by: Alex Elder <elder@linaro.org>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230322144742.2203947-1-elder@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Playing with dpll netlink, I came across following issue:
$ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml --do pin-set --json '{"id": 0, "pin-idx": 1, "pin-state": 1}'
Traceback (most recent call last):
  File "tools/net/ynl/cli.py", line 52, in <module>
    main()
  File "tools/net/ynl/cli.py", line 40, in main
    reply = ynl.do(args.do, attrs)
  File "tools/net/ynl/lib/ynl.py", line 520, in do
    return self._op(method, vals)
  File "tools/net/ynl/lib/ynl.py", line 476, in _op
    msg += self._add_attr(op.attr_set.name, name, value)
  File "tools/net/ynl/lib/ynl.py", line 344, in _add_attr
    raise Exception(f'Unknown type at {space} {name} {value} {attr["type"]}')
Exception: Unknown type at dpll pin-state 1 u8

I'm not that familiar with ynl code, but from a quick peek, I suspect
that couple other types are missing for both encoding and decoding.
Ignoring those here as I'm scratching my local itch only.

Fix the issue by adding u8 attr packing.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20230322154242.1739136-1-jiri@resnulli.usSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Add basic documentation about NAPI. We can stop linking to the ancient
doc on the LF wiki.

Link: https://lore.kernel.org/all/20230315223044.471002-1-kuba@kernel.org/Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> # for ctucanfd-driver.rst
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20230322053848.198452-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

4 places in the act api code are using 'TCA_' definitions where they
should be using 'TCA_ACT_', which is confusing for the reader, although
functionally they are equivalent.

Cc: Hangbin Liu <haliu@redhat.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Acked-by: Hangbin Liu <haliu@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2023-03-21 (igb, igbvf, igc)

This series contains updates to igb, igbvf, and igc drivers.

Andrii changes igb driver to utilize diff_by_scaled_ppm() implementation
over an open-coded version.

Dawid adds pci_error_handlers for reset_prepare and reset_done for
igbvf.

Sasha removes unnecessary code in igc.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

Petr Machata says:

====================
net: Allow changing IPv4 address protocol

IPv4 and IPv6 addresses can be assigned a protocol value that indicates the
provenance of the IP address. The attribute is modeled after ip route
protocols, and essentially allows the administrator or userspace stack to
tag addresses in some way that makes sense to the actor in question.

When IP address protocol field was added in commit 47f0bd50 ("net: Add
new protocol attribute to IP addresses"), the semantics included the
ability to change the protocol for IPv6 addresses, but not for IPv4
addresses. It seems this was not deliberate, but rather by accident.

One particular use case is tagging the addresses differently depending on
whether the routing stack should advertise them or not. Without support for
protocol replacement, this can not be done.

In this patchset, extend IPv4 to allow changing the protocol defined at an
address (in patch #1). Then in patches #2 and #3 add selftest coverage for
ip address protocols.

Currently the kernel simply ignores the new value. Thus allowing the
replacement changes the observable behavior. However, since IPv6 already
behaves like this anyway, and since the feature as such is relatively new,
it seems like the change is safe to make.

An example session with the feature in action:

	bash-5.2# ip address add dev d 192.0.2.1/28 proto 0xab
	bash-5.2# ip address show dev d
	4: d: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
	    link/ether 06:29:74:fd:1f:eb brd ff:ff:ff:ff:ff:ff
	    inet 192.0.2.1/28 scope global proto 0xab d
	       valid_lft forever preferred_lft forever

	bash-5.2# ip address replace dev d 192.0.2.1/28 proto 0x11
	bash-5.2# ip address show dev d
	4: d: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
	    link/ether 06:29:74:fd:1f:eb brd ff:ff:ff:ff:ff:ff
	    inet 192.0.2.1/28 scope global proto 0x11 d
	       valid_lft forever preferred_lft forever
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

Add coverage of "ip address {add,replace} ... proto" support.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Extract the list of all tests into a variable, ALL_TESTS. Then assume the
environment variable TESTS holds the list of tests to actually run, falling
back to ALL_TESTS if TESTS is empty. This is the same interface that
forwarding selftests use to make the set of tests to run configurable.
In addition to this, allow setting the value explicitly through a command
line option "-t" along the lines of what fib_nexthops.sh does.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When IP address protocol field was added in commit 47f0bd50 ("net: Add
new protocol attribute to IP addresses"), the semantics included the
ability to change the protocol for IPv6 addresses, but not for IPv4
addresses. It seems this was not deliberate, but rather by accident.

A userspace that wants to change the protocol of an address might drop and
recreate the address, but that disrupts routing and is just impractical.

So in this patch, when an IPv4 address is replaced (through RTM_NEWADDR
request with NLM_F_REPLACE flag), update the proto at the address to the
one given in the request, or zero if none is given. This matches the
behavior of IPv6. Previously, any new value given was simply ignored.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Alex Elder says:

====================
net: ipa: fully support IPA v5.0

At long last, add the IPA and GSI register definitions, and the
configuration data required to support IPA v5.0.  This enables IPA
support for the Qualcomm SDX65 SoC.

The first version of this series had build errors due to a
non-existent source file being required.  This version addresses
that by changing how required files are specified in the Makefile.

Note that the second patch has some warnings about lines starting
with spaces; those spaces align text with the open parenthesis on
the previous line.
====================

Link: https://lore.kernel.org/r/20230321182644.2143990-1-elder@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Add the configuration data required for IPA v5.0, which is used in
the SDX65 SoC.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Add the definitions of GSI register offsets and fields for IPA v5.0.
These are used for the SDX65 SoC.  Increase the maximum channel and
event ring counts supported by the driver, so those implemented by
the SDX65 are supported.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Add the definitions of IPA register offsets and fields for IPA v5.0.
These are used for the SDX65 SoC.

In the Makefile, split IPA_VERSIONS to use IPA_REG_VERSIONS and
IPA_DATA_VERSIONS instead, to allow IPA register definitions for a
new version to be added separate from the IPA data.

Rename GSI_IPA_VERSIONS to be GSI_REG_VERSIONS for consistency.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Russell King says:

====================
Quirk for OEM SFP-2.5G-T copper module

Frank Wunderlich reports that this copper module requires a quirk in
order to function - in that the module needs to use 2500base-X.
Moreover, negotiation must be disabled.

An example of this device would be:

  https://www.optcore.net/product/sfp-2g-t-gen
====================

Link: https://lore.kernel.org/r/ZBniMlTDZJQ242DP@shell.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Add a quirk for a copper SFP that identifies itself as "OEM"
"SFP-2.5G-T". This module's PHY is inaccessible, and can only run
at 2500base-X with the host without negotiation. Add a quirk to
enable the 2500base-X interface mode with 2500base-T support, and
disable autonegotiation.
Reported-by: Frank Wunderlich <frank-w@public-files.de>
Tested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Allow SFP quirks to override the Autoneg, Pause and Asym_Pause bits in
the support mask.

Some modules have an inaccessible PHY on which is only accessible via
2500base-X without Autonegotiation. We therefore want to be able to
clear the Autoneg bit. Rearrange sfp_parse_support() to allow a SFP
modes quirk to override this bit.
Tested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Eric Dumazet says:

====================
net: remove some skb_mac_header assumptions

Historically, we tried o maintain skb_mac_header available in most of
networking paths.

When reaching ndo_start_xmit() handlers, skb_mac_header() should always
be skb->data.

With recent additions of skb_mac_header_was_set() and
DEBUG_NET_WARN_ON_ONCE() in skb_mac_header(), we can attempt
to remove our reliance on skb_mac_header in TX paths.

When this effort completes we will remove skb_reset_mac_header()
from __dev_queue_xmit() and replace it by
skb_unset_mac_header() on DEBUG_NET builds.
====================

Link: https://lore.kernel.org/r/20230321164519.1286357-1-edumazet@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

tcf_mirred_act() and tcf_mpls_act() can use skb_network_offset()
instead of relying on skb_mac_header().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

We want to remove our use of skb_mac_header() in tx paths,
eg remove skb_reset_mac_header() from __dev_queue_xmit().

Idea is that ndo_start_xmit() can get the mac header
simply looking at skb->data.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

We want to remove our use of skb_mac_header() in tx paths,
eg remove skb_reset_mac_header() from __dev_queue_xmit().

Idea is that ndo_start_xmit() can get the mac header
simply looking at skb->data.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Russell King says:

====================
Remove phylink_state's an_enabled member

Now that all the fixes and correctness patches have been merged, it is
time to switch the two users that make use of .an_enabled to check the
Autoneg bit in the advertising mask, and finally remove the
.an_enabled member.

The first two patches remove the last uses of .an_enabled, which are
in DPAA2 and XPCS. The final patch removes the member.
====================

Link: https://lore.kernel.org/r/ZBnT6yW9UY1sAsiy@shell.armlinux.org.ukSigned-off-by: Jakub Kicinski <kuba@kernel.org>

The Autoneg bit in the advertising bitmap and state->an_enabled are
always identical. state->an_enabled is now no longer used by any
drivers, so lets kill this duplication.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The Autoneg bit in the advertising bitmap and state->an_enabled are
always identical. Thus, we will be removing state->an_enabled.

Use the Autoneg bit in the advertising bitmap to indicate whether
autonegotiation should be used, rather than using the an_enabled
member which will be going away.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The Autoneg bit in the advertising bitmap and state->an_enabled are
always identical. Thus, we will be removing state->an_enabled.

Use the Autoneg bit in the advertising bitmap to indicate whether
autonegotiation should be used, rather than using the an_enabled
member which will be going away. This means we use the same condition
as phylink_mii_c22_pcs_config().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

When requesting a TX queue at a given index, warn on out-of-bounds
referencing if the index is greater than the allocated number of
queues.

Specifically, since this function is used heavily in the networking
stack use DEBUG_NET_WARN_ON_ONCE to avoid executing a new branch on
every packet.
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Link: https://lore.kernel.org/r/20230321150725.127229-2-nnac123@linux.ibm.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

When setting the XPS value of a TX queue, warn the user once if the
index of the queue is greater than the number of allocated TX queues.

Previously, this scenario went uncaught. In the best case, it resulted
in unnecessary allocations. In the worst case, it resulted in
out-of-bounds memory references through calls to `netdev_get_tx_queue(
dev, index)`. Therefore, it is important to inform the user but not
worth returning an error and risk downing the netdevice.
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com>
Link: https://lore.kernel.org/r/20230321150725.127229-1-nnac123@linux.ibm.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Siddharth Vadapalli says:

====================
Add CPSWxG SGMII support for J7200 and J721E

This series adds support to configure the CPSW Ethernet Switch in SGMII
mode, using the am65-cpsw-nuss driver. SGMII mode is supported by the
CPSWxG instances on TI's J7200 and J721E SoCs. Thus, SGMII mode is added
in the list of extra_modes for the appropriate compatibles corresponding
to the aforementioned SoCs.

Additionally, the method of setting the supported interface via struct
"phylink_config" is simplified by converting the IF/ELSE statements to
SWITCH statements.
====================

Link: https://lore.kernel.org/r/20230321111958.2800005-1-s-vadapalli@ti.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

TI's J721E SoC supports SGMII mode with the CPSW9G instance of the CPSW
Ethernet Switch. Thus, enable it by adding SGMII mode to the extra_modes
member of the "j721e_cpswxg_pdata" SoC data.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

TI's J7200 SoC supports SGMII mode with the CPSW5G instance of the CPSW
Ethernet Switch. Thus, enable it by adding SGMII mode to the extra_modes
member of the "j7200_cpswxg_pdata" SoC data.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Add support for configuring the CPSW Ethernet Switch in SGMII mode.

Depending on the SoC, allow selecting SGMII mode as a supported interface,
based on the compatible used.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Convert the existing IF/ELSE statement based approach of setting the
supported_interfaces member of struct "phylink_config", to SWITCH
statements. This will help scale to newer PHY-MODES as well as newer
compatibles.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

clang with W=1 reports
drivers/net/ethernet/cavium/liquidio/request_manager.c:43:19: error:
  unused function 'IQ_INSTR_MODE_64B' [-Werror,-Wunused-function]
static inline int IQ_INSTR_MODE_64B(struct octeon_device *oct, int iq_no)
                  ^
This function and its macro wrapper are not used, so remove them.
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230321184811.1827306-1-trix@redhat.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Leon Romanovsky says:

====================
Extend packet offload to fully support libreswan

The following patches are an outcome of Raed's work to add packet
offload support to libreswan [1].

The series includes:
 * Priority support to IPsec policies
 * Statistics per-SA (visible through "ip -s xfrm state ..." command)
 * Support to IKE policy holes
 * Fine tuning to acquire logic.

[1] https://github.com/libreswan/libreswan/pull/986
Link: https://lore.kernel.org/all/cover.1678714336.git.leon@kernel.org

* tag 'ipsec-libreswan-mlx5' of https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
  net/mlx5e: Update IPsec per SA packets/bytes count
  net/mlx5e: Use one rule to count all IPsec Tx offloaded traffic
  net/mlx5e: Support IPsec acquire default SA
  net/mlx5e: Allow policies with reqid 0, to support IKE policy holes
  xfrm: copy_to_user_state fetch offloaded SA packets/bytes statistics
  xfrm: add new device offload acquire flag
  net/mlx5e: Use chains for IPsec policy priority offload
  net/mlx5: fs_core: Allow ignore_flow_level on TX dest
  net/mlx5: fs_chains: Refactor to detach chains from tc usage
====================

Link: https://lore.kernel.org/r/20230320094722.1009304-1-leon@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Cleanup bindings dropping unneeded quotes. Once all these are fixed,
checking for this can be enabled in yamllint.

Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for bindings/net/can
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # for bindings/net/toshiba,visconti-dwmac.yaml
Reviewed-by: Heiko Stuebner <heiko@sntech.de> #rockchip
Link: https://lore.kernel.org/r/20230320233758.2918972-1-robh@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Álvaro Fernández Rojas says:

====================
net: dsa: b53: configure 6318 and 63268 RGMII ports

BCM6318 and BCM63268 need special configuration for their RGMII ports, so we
need to be able to identify them as a special BCM63xx switch.
In the meantime, let's add some missing BCM63xx SoCs to B53 MMAP device table.

This should be applied after "net: dsa: b53: add support for BCM63xx RGMIIs":
https://patchwork.kernel.org/project/netdevbpf/patch/20230319220805.124024-1-noltari@gmail.com/

Álvaro Fernández Rojas (4):
  dt-bindings: net: dsa: b53: add more 63xx SoCs
  net: dsa: b53: mmap: add more 63xx SoCs
  net: dsa: b53: mmap: allow passing a chip ID
  net: dsa: b53: add BCM63268 RGMII configuration

 .../devicetree/bindings/net/dsa/brcm,b53.yaml |  3 ++
 drivers/net/dsa/b53/b53_common.c              | 19 +++++++++++-
 drivers/net/dsa/b53/b53_mmap.c                | 29 +++++++++++++++----
 drivers/net/dsa/b53/b53_priv.h                |  9 +++++-
 drivers/net/dsa/b53/b53_regs.h                |  1 +
 5 files changed, 53 insertions(+), 8 deletions(-)
====================

Link: https://lore.kernel.org/r/20230321173359.251778-1-noltari@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

BCM63268 requires special RGMII configuration to work.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>