Ea 5.15.y #3
Open
Ea 5.15.y #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ridging
For VLAN-unaware bridging, tag_8021q uses something perhaps a bit too
tied with the sja1105 switch: each port uses the same pvid which is also
used for standalone operation (a unique one from which the source port
and device ID can be retrieved when packets from that port are forwarded
to the CPU). Since each port has a unique pvid when performing
autonomous forwarding, the switch must be configured for Shared VLAN
Learning (SVL) such that the VLAN ID itself is ignored when performing
FDB lookups. Without SVL, packets would always be flooded, since FDB
lookup in the source port's VLAN would never find any entry.
First of all, to make tag_8021q more palatable to switches which might
not support Shared VLAN Learning, let's just use a common VLAN for all
ports that are under the same bridge.
Secondly, using Shared VLAN Learning means that FDB isolation can never
be enforced. But if all ports under the same VLAN-unaware bridge share
the same VLAN ID, it can.
The disadvantage is that the CPU port can no longer perform precise
source port identification for these packets. But at least we have a
mechanism which has proven to be adequate for that situation: imprecise
RX (dsa_find_designated_bridge_port_by_vid), which is what we use for
termination on VLAN-aware bridges.
The VLAN ID that VLAN-unaware bridges will use with tag_8021q is the
same one as we were previously using for imprecise TX (bridge TX
forwarding offload). It is already allocated, it is just a matter of
using it.
Note that because now all ports under the same bridge share the same
VLAN, the complexity of performing a tag_8021q bridge join decreases
dramatically. We no longer have to install the RX VLAN of a newly
joining port into the port membership of the existing bridge ports.
The newly joining port just becomes a member of the VLAN corresponding
to that bridge, and the other ports are already members of it from when
they joined the bridge themselves. So forwarding works properly.
This means that we can unhook dsa_tag_8021q_bridge_{join,leave} from the
cross-chip notifier level dsa_switch_bridge_{join,leave}. We can put
these calls directly into the sja1105 driver.
With this new mode of operation, a port controlled by tag_8021q can have
two pvids whereas before it could only have one. The pvid for standalone
operation is different from the pvid used for VLAN-unaware bridging.
This is done, again, so that FDB isolation can be enforced.
Let tag_8021q manage this by deleting the standalone pvid when a port
joins a bridge, and restoring it when it leaves it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 91495f2)
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The sja1105 switch can't populate the PORT field of the tag_8021q header when sending a frame to the CPU with a non-zero VBID. Similar to dsa_find_designated_bridge_port_by_vid() which performs imprecise RX for VLAN-aware bridges, let's introduce a helper in tag_8021q for performing imprecise RX based on the VLAN that it has allocated for a VLAN-unaware bridge. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit d7f9787) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
…awareness After change "net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging", tag_8021q enforces two different pvids on a port, depending on whether it is standalone or in a VLAN-unaware bridge. Up until now, there was a single pvid, represented by dsa_tag_8021q_rx_vid(), and that was used as the VLAN for VLAN-unaware virtual link rules, regardless of whether the port was bridged or standalone. To keep VLAN-unaware virtual links working, we need to follow whether the port is in a bridge or not, and update the VLAN ID from those rules. In fact we can't fully do that. Depending on whether the switch is VLAN-aware or not, we can accept Virtual Link rules with just the MAC DA, or with a MAC DA and a VID. So we already deny changes to the VLAN awareness of the switch. But the VLAN awareness may also change as a result of joining or leaving a bridge. One might say we could just allow the following: a port may leave a VLAN-unaware bridge while it has VLAN-unaware VL (tc-flower) rules, and the driver will update those with the new tag_8021q pvid for standalone mode, but the driver won't accept joining a bridge at all while VL rules were installed in standalone mode. This is sort of a compromise made because leaving a bridge is an operation that cannot be vetoed. But this sort of setup change is not fully supported, either: as mentioned, VLAN filtering changes can also be triggered by leaving a bridge, therefore, the existing veto we have in place for turning VLAN filtering off with VLAN-aware VL rules active still isn't fully effective. I really don't know how to deal with this in a way that produces predictable behavior for user space. Since at the moment, keeping this feature fully functional on constellation changes (not changing the tag_8021q port pvid when joining a bridge) is blocking progress for the DSA FDB isolation, I'd rather document it as a (potentially temporary) limitation and go on without it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit d27656d) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
…ging The felix driver, which also has a tagging protocol implementation based on tag_8021q, does not care about adding the RX VLAN that is pvid on one port on the other ports that are in the same bridge with it. It simply doesn't need that, because in its implementation, the RX VLAN that is pvid of a port is only used to install a TCAM rule that pushes that VLAN ID towards the CPU port. Now that tag_8021q no longer performs Shared VLAN Learning based forwarding, the RX VLANs are actually segregated into two types: standalone VLANs and VLAN-unaware bridging VLANs. Since you actually have to call dsa_tag_8021q_bridge_join() to get a bridging VLAN from tag_8021q, and felix does not do that because it doesn't need it, it means that it only gets standalone port VLANs from tag_8021q. Which is perfect because this means it can drop its workarounds that avoid the VLANs it does not need. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 08f44db) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
In the old Shared VLAN Learning mode of operation that tag_8021q previously used for forwarding, we needed to have distinct concepts for an RX and a TX VLAN. An RX VLAN could be installed on all ports that were members of a given bridge, so that autonomous forwarding could still work, while a TX VLAN was dedicated for precise packet steering, so it just contained the CPU port and one egress port. Now that tag_8021q uses Independent VLAN Learning and imprecise RX/TX all over, those lines have been blurred and we no longer have the need to do precise TX towards a port that is in a bridge. As for standalone ports, it is fine to use the same VLAN ID for both RX and TX. This patch changes the tag_8021q format by shifting the VLAN range it reserves, and halving it. Previously, our DIR bits were encoding the VLAN direction (RX/TX) and were set to either 1 or 2. This meant that tag_8021q reserved 2K VLANs, or 50% of the available range. Change the DIR bits to a hardcoded value of 3 now, which makes tag_8021q reserve only 1K VLANs, and a different range now (the last 1K). This is done so that we leave the old format in place in case we need to return to it. In terms of code, the vid_is_dsa_8021q_rxvlan and vid_is_dsa_8021q_txvlan functions go away. Any vid_is_dsa_8021q is both a TX and an RX VLAN, and they are no longer distinct. For example, felix which did different things for different VLAN types, now needs to handle the RX and the TX logic for the same VLAN. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 04b67e1) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The dsa_8021q_bridge_tx_fwd_offload_vid is no longer used just for bridge TX forwarding offload, it is the private VLAN reserved for VLAN-unaware bridging in a way that is compatible with FDB isolation. So just rename it dsa_tag_8021q_bridge_vid. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit b6362bd) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
For DSA, to encourage drivers to perform FDB isolation simply means to
track which bridge does each FDB and MDB entry belong to. It then
becomes the driver responsibility to use something that makes the FDB
entry from one bridge not match the FDB lookup of ports from other
bridges.
The top-level functions where the bridge is determined are:
- dsa_port_fdb_{add,del}
- dsa_port_host_fdb_{add,del}
- dsa_port_mdb_{add,del}
- dsa_port_host_mdb_{add,del}
aka the pre-crosschip-notifier functions.
Changing the API to pass a reference to a bridge is not superfluous, and
looking at the passed bridge argument is not the same as having the
driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
method.
DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
and those do not have any dp->bridge information to retrieve, because
they are not in any bridge - they are merely the pipes that serve the
user ports that are in one or multiple bridges.
The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
in a larger "struct dsa_db" database. Although only databases associated
to bridges are notified for now, this API will be the starting point for
implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
entries on the CPU port which belong to the corresponding user port's
port database. These are supposed to match only when the port is
standalone.
It is better to introduce the API in its expected final form than to
introduce it for bridges first, then to have to change drivers which may
have made one or more assumptions.
Drivers can use the provided bridge.num, but they can also use a
different numbering scheme that is more convenient.
DSA must perform refcounting on the CPU and DSA ports by also taking
into account the bridge number. So if two bridges request the same local
address, DSA must notify the driver twice, once for each bridge.
In fact, if the driver supports FDB isolation, DSA must perform
refcounting per bridge, but if the driver doesn't, DSA must refcount
host addresses across all bridges, otherwise it would be telling the
driver to delete an FDB entry for a bridge and the driver would delete
it for all bridges. So introduce a bool fdb_isolation in drivers which
would make all bridge databases passed to the cross-chip notifier have
the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
say that all bridge databases are the same database - which is
essentially the legacy behavior.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c269336)
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This drops the code setting bit 9 on egress frames on the Realtek "type A" (RTL8366RB) frames. This bit was set on ingress frames for unknown reason, and was set on egress frames as the format of ingress and egress frames was believed to be the same. As that assumption turned out to be false, and since this bit seems to have zero effect on the behaviour of the switch let's drop this bit entirely. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210913143156.1264570-1-linus.walleij@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 339133f) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This hacky default VLAN setup was done in order to direct packets to the right ports and provide port isolation, both which we now support properly using custom tags and proper bridge port isolation. We can drop the custom VLAN code and leave all VLAN handling alone, as users expect things to be. We can also drop ds->configure_vlan_while_not_filtering = false; and let the core deal with any VLANs it wants. Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 7776e33) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
While we were defining one VLAN per port for isolating the ports the port_vlan_filtering() callback was implemented to enable a VLAN on the port + 1. This function makes no sense, not only is it incomplete as it only enables the VLAN, it doesn't do what the callback is supposed to do, which is to selectively enable and disable filtering on a certain port. Implement the correct callback: we have two registers dealing with filtering on the RTL9366RB, so we implement an ASIC-specific callback and implement filering using the register bit that makes the switch drop frames if the port is not in the VLAN member set. The DSA documentation Documentation/networking/switchdev.rst states: When the bridge has VLAN filtering enabled and a PVID is not configured on the ingress port, untagged and 802.1p tagged packets must be dropped. When the bridge has VLAN filtering enabled and a PVID exists on the ingress port, untagged and priority-tagged packets must be accepted and forwarded according to the bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering disabled, the presence/lack of a PVID should not influence the packet forwarding decision. To comply with this, we add two arrays of bool in the RTL8366RB state that keeps track of if filtering and PVID is enabled or not for each port. We then add code such that whenever filtering or PVID changes, we update the filter according to the specification. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: Alvin Šipraga <alsi@bang-olufsen.dk> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: DENG Qingfang <dqfext@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit a4eff91) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
We don't need a message for every VLAN association, dbg is fine. The message about adding the DSA or CPU port to a VLAN is directly misleading, this is perfectly fine. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit d310b14) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
We added a state variable to track whether a certain port was VLAN filtering or not, but we can just inquire the DSA core about this. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Cc: Alvin Šipraga <alsi@bang-olufsen.dk> Cc: Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 55b115c) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The RTL8366RB hardware supports disabling learning per-port so let's make use of this feature. Rename some unfortunately named registers in the process. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Cc: Alvin Šipraga <alsi@bang-olufsen.dk> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 56d8bb7) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This implements fast aging per-port using the special "security" register, which will flush any learned L2 LUT entries on a port. The vendor API just enabled setting and clearing this bit, so we set it to age out any entries on the port and then we clear it again. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 1fbd19e) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This adds support for setting the STP state to the RTL8366RB DSA switch. This rids the following message from the kernel on e.g. OpenWrt: DSA: failed to set STP state 3 (-95) Since the RTL8366RB has one STP state register per FID with two bit per port in each, we simply loop over all the FIDs and set the state on all of them. Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Alvin Šipraga <alsi@bang-olufsen.dk> Cc: Mauri Sandberg <sandberg@mailfence.com> Cc: DENG Qingfang <dqfext@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit e674cfd) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Add a new EtherType ETH_P_REALTEK to the if_ether.h uapi header. The EtherType 0x8899 is used in a number of different protocols from Realtek Semiconductor Corp [1], so no general assumptions should be made when trying to decode such packets. Observed protocols include: 0x1 - Realtek Remote Control protocol [2] 0x2 - Echo protocol [2] 0x3 - Loop detection protocol [2] 0x4 - RTL8365MB 4- and 8-byte switch CPU tag protocols [3] 0x9 - RTL8306 switch CPU tag protocol [4] 0xA - RTL8366RB switch CPU tag protocol [4] [1] https://lore.kernel.org/netdev/CACRpkdYQthFgjwVzHyK3DeYUOdcYyWmdjDPG=Rf9B3VrJ12Rzg@mail.gmail.com/ [2] https://www.wireshark.org/lists/ethereal-dev/200409/msg00090.html [3] https://lore.kernel.org/netdev/20210822193145.1312668-4-alvin@pqrs.dk/ [4] https://lore.kernel.org/netdev/20200708122537.1341307-2-linus.walleij@linaro.org/ Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 7bbbbfa) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Jakub pointed out that we have a new ethtool API for reporting device
statistics in a standardized way, via .get_eth_{phy,mac,ctrl}_stats.
Add a small amount of plumbing to allow DSA drivers to take advantage of
this when exposing statistics.
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 487d385)
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Move things around a little so that this tag driver is alphabetically ordered. The Kconfig file is sorted based on the tristate text. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 9cb8edd) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
rtl8365mb is a new realtek-smi subdriver for the RTL8365MB-VC 4+1 port 10/100/1000M Ethernet switch controller. Its compatible string is "realtek,rtl8365mb". Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 2e40587) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This commit implements a basic version of the 8 byte tag protocol used in the Realtek RTL8365MB-VC unmanaged switch, which carries with it a protocol version of 0x04. The implementation itself only handles the parsing of the EtherType value and Realtek protocol version, together with the source or destination port fields. The rest is left unimplemented for now. The tag format is described in a confidential document provided to my company by Realtek Semiconductor Corp. Permission has been granted by the vendor to publish this driver based on that material, together with an extract from the document describing the tag format and its fields. It is hoped that this will help future implementors who do not have access to the material but who wish to extend the functionality of drivers for chips which use this protocol. In addition, two possible values of the REASON field are specified, based on experiments on my end. Realtek does not specify what value this field can take. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 1521d5a) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This patch adds a realtek-smi subdriver for the RTL8365MB-VC 4+1 port 10/100/1000M switch controller. The driver has been developed based on a GPL-licensed OS-agnostic Realtek vendor driver known as rtl8367c found in the OpenWrt source tree. Despite the name, the RTL8365MB-VC has an entirely different register layout to the already-supported RTL8366RB ASIC. Notwithstanding this, the structure of the rtl8365mb subdriver is loosely based on the rtl8366rb subdriver. Like the 'rb, it establishes its own irqchip to handle cascaded PHY link status interrupts. The RTL8365MB-VC switch is capable of offloading a large number of features from the software, but this patch introduces only the most basic DSA driver functionality. The ports always function as standalone ports, with bridging handled in software. One more thing. Realtek's nomenclature for switches makes it hard to know exactly what other ASICs might be supported by this driver. The vendor driver goes by the name rtl8367c, but as far as I can tell, no chip actually exists under this name. As such, the subdriver is named rtl8365mb to emphasize the potentially limited support. But it is clear from the vendor sources that a number of other more advanced switches share a similar register layout, and further support should not be too hard to add given access to the relevant hardware. With this in mind, the subdriver has been written with as few assumptions about the particular chip as is reasonable. But the RTL8365MB-VC is the only hardware I have available, so some further work is surely needed. Co-developed-by: Michael Rasmussen <mir@bang-olufsen.dk> Signed-off-by: Michael Rasmussen <mir@bang-olufsen.dk> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 4af2950) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The RTL8365MB-VC ethernet switch controller has 4 internal PHYs for its user-facing ports. All that is needed is to let the PHY driver core pick up the IRQ made available by the switch driver. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 2ca2969) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Probe deferral is not an error, so don't log this as an error: [0.590156] realtek-smi ethernet-switch: unable to register switch ret = -517 Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit b014861) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
A contact at Realtek has clarified what exactly the units of RGMII RX delay are. The answer is that the unit of RX delay is "about 0.3 ns". Take this into account when parsing rx-internal-delay-ps by approximating the closest step value. Delays of more than 2.1 ns are rejected. This obviously contradicts the previous assumption in the driver that a step value of 4 was "about 2 ns", but Realtek also points out that it is easy to find more than one RX delay step value which makes RGMII work. Fixes: 4af2950 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Cc: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit ef13683) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
If a bridged port is not offloaded to the hardware - either because the
underlying driver does not implement the port_bridge_{join,leave} ops,
or because the operation failed - then its dp->bridge pointer will be
NULL when dsa_port_bridge_leave() is called. Avoid dereferncing NULL.
This fixes the following splat when removing a port from a bridge:
Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
CPU: 3 PID: 1119 Comm: brctl Tainted: G O 5.17.0-rc4-rt4 #1
Call trace:
dsa_port_bridge_leave+0x8c/0x1e4
dsa_slave_changeupper+0x40/0x170
dsa_slave_netdevice_event+0x494/0x4d4
notifier_call_chain+0x80/0xe0
raw_notifier_call_chain+0x1c/0x24
call_netdevice_notifiers_info+0x5c/0xac
__netdev_upper_dev_unlink+0xa4/0x200
netdev_upper_dev_unlink+0x38/0x60
del_nbp+0x1b0/0x300
br_del_if+0x38/0x114
add_del_if+0x60/0xa0
br_ioctl_stub+0x128/0x2dc
br_ioctl_call+0x68/0xb0
dev_ifsioc+0x390/0x554
dev_ioctl+0x128/0x400
sock_do_ioctl+0xb4/0xf4
sock_ioctl+0x12c/0x4e0
__arm64_sys_ioctl+0xa8/0xf0
invoke_syscall+0x4c/0x110
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x28/0x84
el0_svc+0x1c/0x50
el0t_64_sync_handler+0xa8/0xb0
el0t_64_sync+0x17c/0x180
Code: f9402f00 f0002261 f9401302 913cc021 (a9401404)
---[ end trace 0000000000000000 ]---
Fixes: d3eed0e ("net: dsa: keep the bridge_dev and bridge_num as part of the same structure")
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20220221203539.310690-1-alvin@pqrs.dk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 342b641)
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
This switch family can have up to 8 UTP ports {0..7}. However,
INDIRECT_ACCESS_ADDRESS_PHYNUM_MASK was using 2 bits instead of 3,
dropping the most significant bit during indirect register reads and
writes. Reading or writing ports 4, 5, 6, and 7 registers was actually
manipulating, respectively, ports 0, 1, 2, and 3 registers.
This is not sufficient but necessary to support any variant with more
than 4 UTP ports, like RTL8367S.
rtl8365mb_phy_{read,write} will now returns -EINVAL if phy is greater
than 7.
Fixes: 4af2950 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1e89ad8)
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Recent net-next fails to initialize ports with: realtek-smi switch: phy mode gmii is unsupported on port 0 realtek-smi switch lan5 (uninitialized): validation of gmii with support 0000000,00000000,000062ef and advertisement 0000000,00000000,000062ef failed: -22 realtek-smi switch lan5 (uninitialized): failed to connect to PHY: -EINVAL realtek-smi switch lan5 (uninitialized): error -22 setting up PHY for tree 1, switch 0, port 0 Current net branch(3dd7d40) is not affected. I also noticed the same issue before with older versions but using a MDIO interface driver, not realtek-smi. Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit a5dba0f) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Removed kdoc mark for incomplete struct description. Added a return description for rtl8366rb_drop_untagged. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 0f0c6da) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 319a70a) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
…odes There is a downstream patch which adds a new interface type - PHY_INTERFACE_MODE_2500SGMII (which is really the same one as PHY_INTERFACE_MODE_2500BASEX). We backported from upstream the following phylink patch which, of course, does not treat the PHY_INTERFACE_MODE_2500SGMII interface mode in a switch case statement. 34ae2c0 ("net: phylink: add generic validate implementation") Because of this, we get the following build warning. drivers/net/phy/phylink.c: In function ‘phylink_get_linkmodes’: drivers/net/phy/phylink.c:322:2: warning: enumeration value ‘PHY_INTERFACE_MODE_2500SGMII’ not handled in switch [-Wswitch] 322 | switch (interface) { | ^~~~~~ Fix it by treating the new interface mode in the switch-case statement. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Enable CONFIG_SFP for the Linux SFP infrastructure. Also, enable the Lynx 28G SerDes PHY driver which supports runtime reconfiguration of SerDes lanes. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
It seems that there are circumstances when access to QBMAN through the software portals will be delayed. Accessing some lower speeds interfaces while also QBMAN commands are issued from the kernel will lead to software timeouts happening in the dpaa2-eth driver. What we have observed is that management commands like re-arming the interrupts on a specific channel, waiting for a dequeue response to be available etc, will take a longer time to complete. All these commands have to wait for a valid bit to be set for the command to be interpreted as successfully completed. Increase the maximum number of times the Linux kernel drivers will busy poll for a successful result of one of these commands. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Merge latest from NXP Linux kernel repository (5.15.32).
This issue is related to commit f5d9aa7 where clk-out fixup was remoevd.
This issue is related to commit c7e73b5 where fixup for Micrel KSZ8081 was removed.
…efault. The eadisp functionality has been removed from u-boot. Instead the 7-inch HDMI display is considered default. For those boards that doesn't have HDMI interface an RGB to HDMI adapter is used.
This happened when enabling CONFIG_AT803X_PHY in commit d19b6eb.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.