Skip to content

Commit

Permalink
Merge tag 'net-6.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/…
Browse files Browse the repository at this point in the history
…git/netdev/net

Pull networking fixes from Paolo Abeni:
 "Including fixes from bluetooth.

  Current release - new code bugs:

   - netfilter: complete validation of user input

   - mlx5: disallow SRIOV switchdev mode when in multi-PF netdev

  Previous releases - regressions:

   - core: fix u64_stats_init() for lockdep when used repeatedly in one
     file

   - ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr

   - bluetooth: fix memory leak in hci_req_sync_complete()

   - batman-adv: avoid infinite loop trying to resize local TT

   - drv: geneve: fix header validation in geneve[6]_xmit_skb

   - drv: bnxt_en: fix possible memory leak in
     bnxt_rdma_aux_device_init()

   - drv: mlx5: offset comp irq index in name by one

   - drv: ena: avoid double-free clearing stale tx_info->xdpf value

   - drv: pds_core: fix pdsc_check_pci_health deadlock

  Previous releases - always broken:

   - xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING

   - bluetooth: fix setsockopt not validating user input

   - af_unix: clear stale u->oob_skb.

   - nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies

   - drv: virtio_net: fix guest hangup on invalid RSS update

   - drv: mlx5e: Fix mlx5e_priv_init() cleanup flow

   - dsa: mt7530: trap link-local frames regardless of ST Port State"

* tag 'net-6.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (59 commits)
  net: ena: Set tx_info->xdpf value to NULL
  net: ena: Fix incorrect descriptor free behavior
  net: ena: Wrong missing IO completions check order
  net: ena: Fix potential sign extension issue
  af_unix: Fix garbage collector racing against connect()
  net: dsa: mt7530: trap link-local frames regardless of ST Port State
  Revert "s390/ism: fix receive message buffer allocation"
  net: sparx5: fix wrong config being used when reconfiguring PCS
  net/mlx5: fix possible stack overflows
  net/mlx5: Disallow SRIOV switchdev mode when in multi-PF netdev
  net/mlx5e: RSS, Block XOR hash with over 128 channels
  net/mlx5e: Do not produce metadata freelist entries in Tx port ts WQE xmit
  net/mlx5e: HTB, Fix inconsistencies with QoS SQs number
  net/mlx5e: Fix mlx5e_priv_init() cleanup flow
  net/mlx5e: RSS, Block changing channels number when RXFH is configured
  net/mlx5: Correctly compare pkt reformat ids
  net/mlx5: Properly link new fs rules into the tree
  net/mlx5: offset comp irq index in name by one
  net/mlx5: Register devlink first under devlink lock
  net/mlx5: E-switch, store eswitch pointer before registering devlink_param
  ...
  • Loading branch information
torvalds committed Apr 11, 2024
2 parents ab4319f + 4e1ad31 commit 2ae9a89
Show file tree
Hide file tree
Showing 69 changed files with 743 additions and 356 deletions.
11 changes: 3 additions & 8 deletions MAINTAINERS
Original file line number Diff line number Diff line change
Expand Up @@ -2191,7 +2191,6 @@ N: mxs

ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE
M: Shawn Guo <shawnguo@kernel.org>
M: Li Yang <leoyang.li@nxp.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
Expand Down Expand Up @@ -8524,7 +8523,6 @@ S: Maintained
F: drivers/video/fbdev/fsl-diu-fb.*

FREESCALE DMA DRIVER
M: Li Yang <leoyang.li@nxp.com>
M: Zhang Wei <zw@zh-kernel.org>
L: linuxppc-dev@lists.ozlabs.org
S: Maintained
Expand Down Expand Up @@ -8689,10 +8687,9 @@ F: drivers/soc/fsl/qe/tsa.h
F: include/dt-bindings/soc/cpm1-fsl,tsa.h

FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
M: Li Yang <leoyang.li@nxp.com>
L: netdev@vger.kernel.org
L: linuxppc-dev@lists.ozlabs.org
S: Maintained
S: Orphan
F: drivers/net/ethernet/freescale/ucc_geth*

FREESCALE QUICC ENGINE UCC HDLC DRIVER
Expand All @@ -8709,10 +8706,9 @@ S: Maintained
F: drivers/tty/serial/ucc_uart.c

FREESCALE SOC DRIVERS
M: Li Yang <leoyang.li@nxp.com>
L: linuxppc-dev@lists.ozlabs.org
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
S: Orphan
F: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
F: Documentation/devicetree/bindings/soc/fsl/
F: drivers/soc/fsl/
Expand Down Expand Up @@ -8746,10 +8742,9 @@ F: Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
F: sound/soc/fsl/fsl_qmc_audio.c

FREESCALE USB PERIPHERAL DRIVERS
M: Li Yang <leoyang.li@nxp.com>
L: linux-usb@vger.kernel.org
L: linuxppc-dev@lists.ozlabs.org
S: Maintained
S: Orphan
F: drivers/usb/gadget/udc/fsl*

FREESCALE USB PHY DRIVER
Expand Down
10 changes: 5 additions & 5 deletions drivers/isdn/mISDN/socket.c
Original file line number Diff line number Diff line change
Expand Up @@ -401,23 +401,23 @@ data_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
}

static int data_sock_setsockopt(struct socket *sock, int level, int optname,
sockptr_t optval, unsigned int len)
sockptr_t optval, unsigned int optlen)
{
struct sock *sk = sock->sk;
int err = 0, opt = 0;

if (*debug & DEBUG_SOCKET)
printk(KERN_DEBUG "%s(%p, %d, %x, optval, %d)\n", __func__, sock,
level, optname, len);
level, optname, optlen);

lock_sock(sk);

switch (optname) {
case MISDN_TIME_STAMP:
if (copy_from_sockptr(&opt, optval, sizeof(int))) {
err = -EFAULT;
err = copy_safe_from_sockptr(&opt, sizeof(opt),
optval, optlen);
if (err)
break;
}

if (opt)
_pms(sk)->cmask |= MISDN_TIME_STAMP;
Expand Down
246 changes: 207 additions & 39 deletions drivers/net/dsa/mt7530.c
Original file line number Diff line number Diff line change
Expand Up @@ -950,56 +950,217 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
mutex_unlock(&priv->reg_mutex);
}

/* On page 205, section "8.6.3 Frame filtering" of the active standard, IEEE Std
* 802.1Q™-2022, it is stated that frames with 01:80:C2:00:00:00-0F as MAC DA
* must only be propagated to C-VLAN and MAC Bridge components. That means
* VLAN-aware and VLAN-unaware bridges. On the switch designs with CPU ports,
* these frames are supposed to be processed by the CPU (software). So we make
* the switch only forward them to the CPU port. And if received from a CPU
* port, forward to a single port. The software is responsible of making the
* switch conform to the latter by setting a single port as destination port on
* the special tag.
/* In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer (DLL)
* of the Open Systems Interconnection basic reference model (OSI/RM) are
* described; the medium access control (MAC) and logical link control (LLC)
* sublayers. The MAC sublayer is the one facing the physical layer.
*
* This switch intellectual property cannot conform to this part of the standard
* fully. Whilst the REV_UN frame tag covers the remaining :04-0D and :0F MAC
* DAs, it also includes :22-FF which the scope of propagation is not supposed
* to be restricted for these MAC DAs.
* In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A
* Bridge component comprises a MAC Relay Entity for interconnecting the Ports
* of the Bridge, at least two Ports, and higher layer entities with at least a
* Spanning Tree Protocol Entity included.
*
* Each Bridge Port also functions as an end station and shall provide the MAC
* Service to an LLC Entity. Each instance of the MAC Service is provided to a
* distinct LLC Entity that supports protocol identification, multiplexing, and
* demultiplexing, for protocol data unit (PDU) transmission and reception by
* one or more higher layer entities.
*
* It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC
* Entity associated with each Bridge Port is modeled as being directly
* connected to the attached Local Area Network (LAN).
*
* On the switch with CPU port architecture, CPU port functions as Management
* Port, and the Management Port functionality is provided by software which
* functions as an end station. Software is connected to an IEEE 802 LAN that is
* wholly contained within the system that incorporates the Bridge. Software
* provides access to the LLC Entity associated with each Bridge Port by the
* value of the source port field on the special tag on the frame received by
* software.
*
* We call frames that carry control information to determine the active
* topology and current extent of each Virtual Local Area Network (VLAN), i.e.,
* spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN Registration
* Protocol Data Units (MVRPDUs), and frames from other link constrained
* protocols, such as Extensible Authentication Protocol over LAN (EAPOL) and
* Link Layer Discovery Protocol (LLDP), link-local frames. They are not
* forwarded by a Bridge. Permanently configured entries in the filtering
* database (FDB) ensure that such frames are discarded by the Forwarding
* Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in detail:
*
* Each of the reserved MAC addresses specified in Table 8-1
* (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be
* permanently configured in the FDB in C-VLAN components and ERs.
*
* Each of the reserved MAC addresses specified in Table 8-2
* (01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently
* configured in the FDB in S-VLAN components.
*
* Each of the reserved MAC addresses specified in Table 8-3
* (01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB in
* TPMR components.
*
* The FDB entries for reserved MAC addresses shall specify filtering for all
* Bridge Ports and all VIDs. Management shall not provide the capability to
* modify or remove entries for reserved MAC addresses.
*
* The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of
* propagation of PDUs within a Bridged Network, as follows:
*
* The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that no
* conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN)
* component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward.
* PDUs transmitted using this destination address, or any other addresses
* that appear in Table 8-1, Table 8-2, and Table 8-3
* (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can
* therefore travel no further than those stations that can be reached via a
* single individual LAN from the originating station.
*
* The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an
* address that no conformant S-VLAN component, C-VLAN component, or MAC
* Bridge can forward; however, this address is relayed by a TPMR component.
* PDUs using this destination address, or any of the other addresses that
* appear in both Table 8-1 and Table 8-2 but not in Table 8-3
* (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed by
* any TPMRs but will propagate no further than the nearest S-VLAN component,
* C-VLAN component, or MAC Bridge.
*
* The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an address
* that no conformant C-VLAN component, MAC Bridge can forward; however, it is
* relayed by TPMR components and S-VLAN components. PDUs using this
* destination address, or any of the other addresses that appear in Table 8-1
* but not in either Table 8-2 or Table 8-3 (01-80-C2-00-00-[00,0B,0C,0D,0F]),
* will be relayed by TPMR components and S-VLAN components but will propagate
* no further than the nearest C-VLAN component or MAC Bridge.
*
* Because the LLC Entity associated with each Bridge Port is provided via CPU
* port, we must not filter these frames but forward them to CPU port.
*
* In a Bridge, the transmission Port is majorly decided by ingress and egress
* rules, FDB, and spanning tree Port State functions of the Forwarding Process.
* For link-local frames, only CPU port should be designated as destination port
* in the FDB, and the other functions of the Forwarding Process must not
* interfere with the decision of the transmission Port. We call this process
* trapping frames to CPU port.
*
* Therefore, on the switch with CPU port architecture, link-local frames must
* be trapped to CPU port, and certain link-local frames received by a Port of a
* Bridge comprising a TPMR component or an S-VLAN component must be excluded
* from it.
*
* A Bridge of the switch with CPU port architecture cannot comprise a Two-Port
* MAC Relay (TPMR) component as a TPMR component supports only a subset of the
* functionality of a MAC Bridge. A Bridge comprising two Ports (Management Port
* doesn't count) of this architecture will either function as a standard MAC
* Bridge or a standard VLAN Bridge.
*
* Therefore, a Bridge of this architecture can only comprise S-VLAN components,
* C-VLAN components, or MAC Bridge components. Since there's no TPMR component,
* we don't need to relay PDUs using the destination addresses specified on the
* Nearest non-TPMR section, and the proportion of the Nearest Customer Bridge
* section where they must be relayed by TPMR components.
*
* One option to trap link-local frames to CPU port is to add static FDB entries
* with CPU port designated as destination port. However, because that
* Independent VLAN Learning (IVL) is being used on every VID, each entry only
* applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC
* Bridge component or a C-VLAN component, there would have to be 16 times 4096
* entries. This switch intellectual property can only hold a maximum of 2048
* entries. Using this option, there also isn't a mechanism to prevent
* link-local frames from being discarded when the spanning tree Port State of
* the reception Port is discarding.
*
* The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4
* registers. Whilst this applies to every VID, it doesn't contain all of the
* reserved MAC addresses without affecting the remaining Standard Group MAC
* Addresses. The REV_UN frame tag utilised using the RGAC4 register covers the
* remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination
* addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF
* destination addresses which may be relayed by MAC Bridges or VLAN Bridges.
* The latter option provides better but not complete conformance.
*
* This switch intellectual property also does not provide a mechanism to trap
* link-local frames with specific destination addresses to CPU port by Bridge,
* to conform to the filtering rules for the distinct Bridge components.
*
* Therefore, regardless of the type of the Bridge component, link-local frames
* with these destination addresses will be trapped to CPU port:
*
* 01-80-C2-00-00-[00,01,02,03,0E]
*
* In a Bridge comprising a MAC Bridge component or a C-VLAN component:
*
* Link-local frames with these destination addresses won't be trapped to CPU
* port which won't conform to IEEE Std 802.1Q-2022:
*
* 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F]
*
* In a Bridge comprising an S-VLAN component:
*
* Link-local frames with these destination addresses will be trapped to CPU
* port which won't conform to IEEE Std 802.1Q-2022:
*
* 01-80-C2-00-00-00
*
* Link-local frames with these destination addresses won't be trapped to CPU
* port which won't conform to IEEE Std 802.1Q-2022:
*
* 01-80-C2-00-00-[04,05,06,07,08,09,0A]
*
* To trap link-local frames to CPU port as conformant as this switch
* intellectual property can allow, link-local frames are made to be regarded as
* Bridge Protocol Data Units (BPDUs). This is because this switch intellectual
* property only lets the frames regarded as BPDUs bypass the spanning tree Port
* State function of the Forwarding Process.
*
* The only remaining interference is the ingress rules. When the reception Port
* has no PVID assigned on software, VLAN-untagged frames won't be allowed in.
* There doesn't seem to be a mechanism on the switch intellectual property to
* have link-local frames bypass this function of the Forwarding Process.
*/
static void
mt753x_trap_frames(struct mt7530_priv *priv)
{
/* Trap 802.1X PAE frames and BPDUs to the CPU port(s) and egress them
* VLAN-untagged.
*/
mt7530_rmw(priv, MT753X_BPC, MT753X_PAE_EG_TAG_MASK |
MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK |
MT753X_BPDU_PORT_FW_MASK,
MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) |
MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_BPDU_CPU_ONLY);
mt7530_rmw(priv, MT753X_BPC,
MT753X_PAE_BPDU_FR | MT753X_PAE_EG_TAG_MASK |
MT753X_PAE_PORT_FW_MASK | MT753X_BPDU_EG_TAG_MASK |
MT753X_BPDU_PORT_FW_MASK,
MT753X_PAE_BPDU_FR |
MT753X_PAE_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_PAE_PORT_FW(MT753X_BPDU_CPU_ONLY) |
MT753X_BPDU_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_BPDU_CPU_ONLY);

/* Trap frames with :01 and :02 MAC DAs to the CPU port(s) and egress
* them VLAN-untagged.
*/
mt7530_rmw(priv, MT753X_RGAC1, MT753X_R02_EG_TAG_MASK |
MT753X_R02_PORT_FW_MASK | MT753X_R01_EG_TAG_MASK |
MT753X_R01_PORT_FW_MASK,
MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) |
MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_BPDU_CPU_ONLY);
mt7530_rmw(priv, MT753X_RGAC1,
MT753X_R02_BPDU_FR | MT753X_R02_EG_TAG_MASK |
MT753X_R02_PORT_FW_MASK | MT753X_R01_BPDU_FR |
MT753X_R01_EG_TAG_MASK | MT753X_R01_PORT_FW_MASK,
MT753X_R02_BPDU_FR |
MT753X_R02_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_R02_PORT_FW(MT753X_BPDU_CPU_ONLY) |
MT753X_R01_BPDU_FR |
MT753X_R01_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_BPDU_CPU_ONLY);

/* Trap frames with :03 and :0E MAC DAs to the CPU port(s) and egress
* them VLAN-untagged.
*/
mt7530_rmw(priv, MT753X_RGAC2, MT753X_R0E_EG_TAG_MASK |
MT753X_R0E_PORT_FW_MASK | MT753X_R03_EG_TAG_MASK |
MT753X_R03_PORT_FW_MASK,
MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) |
MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_BPDU_CPU_ONLY);
mt7530_rmw(priv, MT753X_RGAC2,
MT753X_R0E_BPDU_FR | MT753X_R0E_EG_TAG_MASK |
MT753X_R0E_PORT_FW_MASK | MT753X_R03_BPDU_FR |
MT753X_R03_EG_TAG_MASK | MT753X_R03_PORT_FW_MASK,
MT753X_R0E_BPDU_FR |
MT753X_R0E_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_R0E_PORT_FW(MT753X_BPDU_CPU_ONLY) |
MT753X_R03_BPDU_FR |
MT753X_R03_EG_TAG(MT7530_VLAN_EG_UNTAGGED) |
MT753X_BPDU_CPU_ONLY);
}

static void
Expand Down Expand Up @@ -2505,18 +2666,25 @@ mt7531_setup(struct dsa_switch *ds)
mt7530_rmw(priv, MT7531_GPIO_MODE0, MT7531_GPIO0_MASK,
MT7531_GPIO0_INTERRUPT);

/* Enable PHY core PLL, since phy_device has not yet been created
* provided for phy_[read,write]_mmd_indirect is called, we provide
* our own mt7531_ind_mmd_phy_[read,write] to complete this
* function.
/* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since
* phy_device has not yet been created provided for
* phy_[read,write]_mmd_indirect is called, we provide our own
* mt7531_ind_mmd_phy_[read,write] to complete this function.
*/
val = mt7531_ind_c45_phy_read(priv, MT753X_CTRL_PHY_ADDR,
MDIO_MMD_VEND2, CORE_PLL_GROUP4);
val |= MT7531_PHY_PLL_BYPASS_MODE;
val |= MT7531_RG_SYSPLL_DMY2 | MT7531_PHY_PLL_BYPASS_MODE;
val &= ~MT7531_PHY_PLL_OFF;
mt7531_ind_c45_phy_write(priv, MT753X_CTRL_PHY_ADDR, MDIO_MMD_VEND2,
CORE_PLL_GROUP4, val);

/* Disable EEE advertisement on the switch PHYs. */
for (i = MT753X_CTRL_PHY_ADDR;
i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) {
mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
0);
}

mt7531_setup_common(ds);

/* Setup VLAN ID 0 for VLAN-unaware bridges */
Expand Down
Loading

0 comments on commit 2ae9a89

Please sign in to comment.