- 13 May, 2020 33 commits
-
-
Michael Walle authored
The AR8031/AR8033 and the AR8035 support cable diagnostics. Adding driver support is straightforward, so lets add it. The PHY just do one pair at a time, so we have to start the test four times. The cable_test_get_status() can block and therefore we can just busy poll the test completion and continue with the next pair until we are done. The time delta counter seems to run at 125MHz which just gives us a resolution of about 82.4cm per tick. 100m cable, A/B/C/D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: Open Circuit Pair: Pair A, fault length: 107.94m Pair: Pair B, result: Open Circuit Pair: Pair B, fault length: 104.64m Pair: Pair C, result: Open Circuit Pair: Pair C, fault length: 105.47m Pair: Pair D, result: Open Circuit Pair: Pair D, fault length: 107.94m 1m cable, A/B connected, C shorted, D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: OK Pair: Pair B, result: OK Pair: Pair C, result: Short within Pair Pair: Pair C, fault length: 0.82m Pair: Pair D, result: Open Circuit Pair: Pair D, fault length: 0.82m Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Christoph Hellwig authored
While do_ipv6_getsockopt does not call the high-level recvmsg helper, the msghdr eventually ends up being passed to put_cmsg anyway, and thus needs msg_control_is_user set to the proper value. Fixes: 1f466e1f ("net: cleanly handle kernel vs user buffers for ->msg_control") Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
David S. Miller authored
Michael Walle says: ==================== net: phy: broadcom: cable tester support Add cable tester support for the Broadcom PHYs. Support for it was developed on a BCM54140 Quad PHY which RDB register access. If there is a link partner the results are not as good as with an open cable. I guess we could retry if the measurement until all pairs had at least one valid result. changes since v1: - added Reviewed-by: tags - removed "div by 2" for cross shorts, just mention it in the commit message. The results are inconclusive if the tests are repeated. So just report the length as is for now. - fixed typo in commit message ==================== Signed-off-by: -
Michael Walle authored
Use the generic cable tester functions from bcm-phy-lib to add cable tester support. 100m cable, A/B/C/D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: Open Circuit Pair: Pair B, result: Open Circuit Pair: Pair C, result: Open Circuit Pair: Pair D, result: Open Circuit Pair: Pair A, fault length: 106.60m Pair: Pair B, fault length: 103.32m Pair: Pair C, fault length: 104.96m Pair: Pair D, fault length: 106.60m 1m cable, A/B connected, pair C shorted, D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: OK Pair: Pair B, result: OK Pair: Pair C, result: Short within Pair Pair: Pair D, result: Open Circuit Pair: Pair C, fault length: 0.82m Pair: Pair D, fault length: 1.64m 1m cable, A/B connected, pair C shorted with D: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: OK Pair: Pair B, result: OK Pair: Pair C, result: Short to another pair Pair: Pair D, result: Short to another pair Pair: Pair C, fault length: 1.64m Pair: Pair D, fault length: 1.64m The granularity of the length measurement seems to be 82cm. Signed-off-by:
-
Michael Walle authored
Most modern broadcom PHYs support ECD (enhanced cable diagnostics). Add support for it in the bcm-phy-lib so they can easily be used in the PHY driver. There are two access methods for ECD: legacy by expansion registers and via the new RDB registers which are exclusive. Provide functions in two variants where the PHY driver can choose from. To keep things simple for now, we just switch the register access to expansion registers in the RDB variant for now. On the flipside, we have to keep a bus lock to prevent any other non-legacy access on the PHY. The results of the intra-pair tests are inconclusive (at least for the BCM54140). Most of the times half the length is reported but sometimes the length is correct. Signed-off-by:
-
Michael Walle authored
Add the convenience function to do a read-modify-write. This has the additional benefit of saving one write to the selection register. Signed-off-by:
-
Michael Walle authored
Add helper to read and write expansion registers without taking the mdio lock. Please note, that this changes the semantics of the read and write. Before there was no lock between selecting the expansion register and the actual read/write. This may lead to access failures if there are parallel accesses. Instead take the bus lock during the whole access cycle. Signed-off-by:
-
Oleksij Rempel authored
Add initial cable testing support. This PHY needs only 100usec for this test and it is recommended to run it before the link is up. For now, provide at least ethtool support, so it can be tested by more developers. This patch was tested with TJA1102 PHY with following results: - No cable, is detected as open - 1m cable, with no connected other end and detected as open - a 40m cable (out of spec, max lenght should be 15m) is detected as OK. Current patch do not provide polarity test support. This test would indicate not proper wire connection, where "+" wire of main phy is connected to the "-" wire of the link partner. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
-
Christoph Hellwig authored
The code had historically been ignoring these errors, and my recent refactoring changed that, which broke ssh in some setups. Fixes: 2618d530 ("net/scm: cleanup scm_detach_fds") Reported-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Tested-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
David S. Miller authored
Martin Blumenstingl says: ==================== dwmac-meson8b Ethernet RX delay configuration The Ethernet TX performance has been historically bad on Meson8b and Meson8m2 SoCs because high packet loss was seen. I found out that this was related (yet again) to the RGMII TX delay configuration. In the process of discussing the big picture (and not just a single patch) [0] with Andrew I discovered that the IP block behind the dwmac-meson8b driver actually seems to support the configuration of the RGMII RX delay (at least on the Meson8b SoC generation). Since I sent the first RFC I got additional documentation from Jianxin (many thanks!). Also I have discovered some more interesting details: - Meson8b Odroid-C1 requires an RX delay (by either the PHY or the MAC) Based on the vendor u-boot code (not upstream) I assume that it will be the same for all Meson8b and Meson8m2 boards - Khadas VIM2 seems to have the RX delay built into the PCB trace length. When I enable the RX delay on the PHY or MAC I can't get any data through. I expect that we will have the same situation on all GXBB, GXM, AXG, G12A, G12B and SM1 boards. Further clarification is needed here though (since I can't visually see these lengthened traces on the PCB). This will be done before sending patches for these boards. Dependencies for this series: There is a soft dependency for patch #2 on commit f2253143 "dt-bindings: net: dwmac: increase 'maxItems' for 'clocks', 'clock-names' properties" which is currently in Rob's -next tree. That commit is needed to make the dt-bindings schema validation pass for patch #2. That patch has been for ~4 weeks in Robs tree, so I assume that is not going to be dropped. Changes since RFC v2 at [2]: - dropped $ref: /schemas/types.yaml#definitions/uint32 from the "amlogic,rx-delay-ns" in patch #1 ("Don't need to define the type when in standard units." says Rob - thanks, I learned something new). Also use "default: 0" for for this property instead of explaining it in the description text. - added a note to the cover-letter about a hidden dependency for dt-binding schema validation in patch #2 - Added Andrew's Reviewed-by to patches 1-7. Thank you again for the quick and detailed reviews, I appreciate this! - error out if the (optional) timing-adjustment clock is missing but we're asked to enable the RGMII RX delay. The MAC won't work in this specific case and either the RX delay has to be provided by the PHY or the timing-adjustment clock has to be added. - dropped the dts patches (#9-11) which were only added to give an overview how this is going to be used. those will be sent separately - dropped the RFC prefix Changes since RFC v1 at [1]: - add support for the timing adjustment clock input (dt-bindings and in the driver) thanks to the input from the unnamed Ethernet engineer at Amlogic. This is the missing link between the fclk_div2 clock and the Ethernet controller on Meson8b (no traffic would flow if that clock was disabled) - add support fot the amlogic,rx-delay-ns property. The only supported values so far are 0ns and 2ns. The registers seem to allow more precise timing adjustments, but I could not make that work so far. - add more register documentation (for the new RX delay bits) and unified the placement of existing register documentation. Again, thanks to Jianxin and the unnamed Ethernet engineer at Amlogic - DO NOT MERGE: .dts patches to show the conversion of the Meson8b and Meson8m2 boards to "rgmii-id". I didn't have time for all arm64 patches yet, but these will switch to phy-mode = "rgmii-txid" with amlogic,rx-delay-ns = <0> (because the delay seems to be provided by the PCB trace length). [0] https://patchwork.kernel.org/patch/11309891/ [1] https://patchwork.kernel.org/cover/11310719/ [2] https://patchwork.kernel.org/cover/11518257/ ==================== Signed-off-by:
-
Martin Blumenstingl authored
Configure the PRG_ETH0_ADJ_* bits to enable or disable the RX delay based on the various RGMII PHY modes. For now the only supported RX delay settings are: - disabled, use for example for phy-mode "rgmii-id" - 0ns - this is treated identical to "disabled", used for example on boards where the PHY provides 2ns TX delay and the PCB trace length already adds 2ns RX delay - 2ns - for whenever the PHY cannot add the RX delay and the traces on the PCB don't add any RX delay Disabling the RX delay (in case u-boot enables it, which is the case for example on Meson8b Odroid-C1) simply means that PRG_ETH0_ADJ_ENABLE, PRG_ETH0_ADJ_SETUP, PRG_ETH0_ADJ_DELAY and PRG_ETH0_ADJ_SKEW should be disabled (just disabling PRG_ETH0_ADJ_ENABLE may be enough, since that disables the whole re-timing logic - but I find it makes more sense to clear the other bits as well since they depend on that setting). u-boot on Odroid-C1 uses the following steps to enable a 2ns RX delay: - enabling enabling the timing adjustment clock - enabling the timing adjustment logic by setting PRG_ETH0_ADJ_ENABLE - setting the PRG_ETH0_ADJ_SETUP bit The documentation for the PRG_ETH0_ADJ_DELAY and PRG_ETH0_ADJ_SKEW registers indicates that we can even set different RX delays. However, I could not find out how this works exactly, so for now we only support a 2ns RX delay using the exact same way that Odroid-C1's u-boot does. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Martin Blumenstingl authored
The timing adjustment clock will need similar logic as the RGMII clock: It has to be enabled in the driver conditionally and when the driver is unloaded it should be disabled again. Extract the existing code for the RGMII clock into a new function so it can be re-used. Reviewed-by:
-
Martin Blumenstingl authored
The PRG_ETHERNET registers have a built-in timing adjustment circuit which can provide the RX delay in RGMII mode. This is driven by an external (to this IP, but internal to the SoC) clock input. Fetch this clock as optional (even though it's there on all supported SoCs) since we just learned about it and existing .dtbs don't specify it. Reviewed-by:
-
Martin Blumenstingl authored
The PRG_ETH0_ADJ_* are used for applying the RGMII RX delay. The public datasheets only have very limited description for these registers, but Jianxin Pan provided more detailed documentation from an (unnamed) Amlogic engineer. Add the PRG_ETH0_ADJ_* bits along with the improved description. Suggested-by:
Jianxin Pan <jianxin.pan@amlogic.com> Reviewed-by:
-
Martin Blumenstingl authored
Move the documentation for the TX delay above the PRG_ETH0_TXDLY_MASK definition. Future commits will add more registers also with documentation above their register bit definitions. Move the existing comment so it will be consistent with the upcoming changes. Reviewed-by:
-
Martin Blumenstingl authored
Use FIELD_PREP() to shift a value to the correct offset based on a bitmask instead of open-coding the logic. No functional changes. Reviewed-by:
-
Martin Blumenstingl authored
The PRG_ETHERNET registers can add an RX delay in RGMII mode. This requires an internal re-timing circuit whose input clock is called "timing adjustment clock". Document this clock input so the clock can be enabled as needed. Reviewed-by:
-
Martin Blumenstingl authored
The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX delay. Add a property with the known supported values so it can be configured according to the board layout. Reviewed-by:
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2020-05-13 Here's a second attempt at a bluetooth-next pull request which supercedes the one dated 2020-05-09. This should have the issues discovered by Jakub fixed. - Add support for Intel Typhoon Peak device (8087:0032) - Add device tree bindings for Realtek RTL8723BS device - Add device tree bindings for Qualcomm QCA9377 device - Add support for experimental features configuration through mgmt - Add driver hook to prevent wake from suspend - Add support for waiting for L2CAP disconnection response - Multiple fixes & cleanups to the btbcm driver - Add support for LE scatternet topology for selected devices - A few other smaller fixes & cleanups Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
David S. Miller authored
Xiaoliang Yang says: ==================== net: dsa: felix: tc taprio and CBS offload support This patch series support tc taprio and CBS hardware offload according to IEEE 802.1Qbv and IEEE-802.1Qav on VSC9959. v1->v2 changes: - Move port_qos_map_init() function to be common felix codes. - Keep const for dsa_switch_ops structs, add felix_port_setup_tc function to call port_setup_tc of felix.info. - fix code style for cbs_set, rename variables. ==================== Signed-off-by: -
Xiaoliang Yang authored
VSC9959 hardware support the Credit Based Shaper(CBS) which part of the IEEE-802.1Qav. This patch support sch_cbs set for VSC9959. Signed-off-by:
Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Reviewed-by:
-
Xiaoliang Yang authored
Ocelot VSC9959 switch supports time-based egress shaping in hardware according to IEEE 802.1Qbv. This patch add support for TAS configuration on egress port of VSC9959 switch. Felix driver is an instance of Ocelot family, with a DSA front-end. The patch uses tc taprio hardware offload to setup TAS set function on felix driver. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
Xiaoliang Yang authored
Set the default QoS Classification based on PCP and DEI of vlan tag, after that, frames can be Classified to different Qos based on PCP tag. If there is no vlan tag or vlan ignored, use port default Qos. Signed-off-by:
-
Archie Pusaka authored
Whenever we disconnect a L2CAP connection, we would immediately report a disconnection event (EPOLLHUP) to the upper layer, without waiting for the response of the other device. This patch offers an option to wait until we receive a disconnection response before reporting disconnection event, by using the "how" parameter in l2cap_sock_shutdown(). Therefore, upper layer can opt to wait for disconnection response by shutdown(sock, SHUT_WR). This can be used to enforce proper disconnection order in HID, where the disconnection of the interrupt channel must be complete before attempting to disconnect the control channel. Signed-off-by:
Archie Pusaka <apusaka@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Sonny Sasaka authored
After sending Inquiry Cancel command to the controller, it is possible that Inquiry Complete event comes before Inquiry Cancel command complete event. In this case the Inquiry Cancel command will have status of Command Disallowed since there is no Inquiry session to be cancelled. This case should not be treated as error, otherwise we can reach an inconsistent state. Example of a btmon trace when this happened: < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0 > HCI Event: Inquiry Complete (0x01) plen 1 Status: Success (0x00) > HCI Event: Command Complete (0x0e) plen 4 Inquiry Cancel (0x01|0x0002) ncmd 1 Status: Command Disallowed (0x0c) Signed-off-by:Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by:
-
Rikard Falkeborn authored
serdev_device_ops is not modified and can be const. Also, remove the unneeded declaration of it. Output from the file command before and after: Before: text data bss dec hex filename 7192 2408 192 9792 2640 drivers/bluetooth/hci_serdev.o After: text data bss dec hex filename 7256 2344 192 9792 2640 drivers/bluetooth/hci_serdev.o Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Raghuram Hegde authored
Device from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0032 Rev= 0.00 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by:
Raghuram Hegde <raghuram.hegde@intel.com> Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
Amit K Bag <amit.k.bag@intel.com> Signed-off-by:
-
Abhishek Pandit-Subedi authored
Implement the prevent_wake hook by checking device_may_wakeup on the usb interface. This prevents the Bluetooth core from enabling scanning when the device isn't expected to wake from suspend. Signed-off-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by:
Alain Michaud <alainm@chromium.org> Signed-off-by:
-
Abhishek Pandit-Subedi authored
Let drivers have a hook to disable configuring scanning during suspend. Drivers should use the device_may_wakeup function call to determine whether hci should be configured for wakeup. For example, an implementation for btusb may look like the following: bool btusb_prevent_wake(struct hci_dev *hdev) { struct btusb_data *data = hci_get_drvdata(hdev); return !device_may_wakeup(&data->udev->dev); } Signed-off-by: -
Abhishek Pandit-Subedi authored
Renamed BT_SUSPEND_COMPLETE to BT_SUSPEND_CONFIGURE_WAKE since it sets up the event filter and whitelist for wake-up. Signed-off-by:
-
Abhishek Pandit-Subedi authored
When a device is suspended, it doesn't need to be as responsive to connection events. Increase the interval to 640ms (creating a duty cycle of roughly 1.75%) so that passive scanning uses much less power (vs previous duty cycle of 18.75%). The new window + interval combination has been tested to work with HID devices (which are currently the only devices capable of wake up). Signed-off-by:
-
Abhishek Pandit-Subedi authored
The types for window and interval should be uint16, not uint8. Signed-off-by:
-
Vladimir Oltean authored
A comparison between a value from the packet and an integer constant value needs to be done by converting the value from the packet from net->host, or the constant from host->net. Not the other way around. Even though it makes no practical difference, correct that. Fixes: 38b5beea ("net: dsa: sja1105: prepare tagger for handling DSA tags and VLAN simultaneously") Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
- 12 May, 2020 7 commits
-
-
William Tu authored
Add a check to make sure the IFLA_GRE_ERSPAN_VER is provided by users. Fixes: f989d546 ("erspan: Add type I version 0 support.") Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
William Tu <u9012063@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Traffic support for dsa_8021q in vlan_filtering=1 mode This series is an attempt to support as much as possible in terms of traffic I/O from the network stack with the only dsa_8021q user thus far, sja1105. The hardware doesn't support pushing a second VLAN tag to packets that are already tagged, so our only option is to combine the dsa_8021q with the user tag into a single tag and decode that on the CPU. The assumption is that there is a type of use cases for which 7 VLANs per port are more than sufficient, and that there's another type of use cases where the full 4096 entries are barely enough. Those use cases are very different from one another, so I prefer trying to give both the best experience by creating this best_effort_vlan_filtering knob to select the mode in which they want to operate in. v2 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200511135338.20263-1-olteanv@gmail.com/ v1 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200510164255.19322-1-olteanv@gmail.com/ Changes in v3: Patch 01/15: - Rename again to configure_vlan_while_not_filtering, and add a helper function for skipping VLAN configuration. Patch 03/15: - Remove sja1105_can_use_vlan_as_tags from driver code. Patch 06/15: - Adapt sja1105 driver to the second variable name change. Patch 08/15: - Provide an implementation of sja1105_can_use_vlan_as_tags as part of the tagger and not as part of the switch driver. So we have to look at the skb only, and not at the VLAN awareness state. Changes in v2: Patch 01/15: - Rename variable from vlan_bridge_vtu to configure_vlans_while_disabled. Patch 03/15: - Be much more thorough, and make sure that things like virtual links and FDB operations still work properly. Patch 05/15: - Free the vlan lists on teardown. - Simplify sja1105_classify_vlan: only look at priv->expect_dsa_8021q. - Keep vid 1 in the list of dsa_8021q VLANs, to make sure that untagged packets transmitted from the stack, like PTP, continue to work in VLAN-unaware mode. Patch 06/15: - Adapt to vlan_bridge_vtu variable name change. Patch 11/15: - In sja1105_best_effort_vlan_filtering_set, get the vlan_filtering value of each port instead of just one time for port 0. Normally this shouldn't matter, but it avoids issues when port 0 is disabled in device tree. Patch 14/14: - Only do anything in sja1105_build_subvlans and in sja1105_build_crosschip_subvlans when operating in SJA1105_VLAN_BEST_EFFORT state. This avoids installing VLAN retagging rules in unaware mode, which would cost us a penalty in terms of usable frame memory. ==================== Signed-off-by:
-
Vladimir Oltean authored
Signed-off-by:
-
Vladimir Oltean authored
Expand the delta commit procedure for VLANs with additional logic for treating bridge_vlans in the newly introduced operating mode, SJA1105_VLAN_BEST_EFFORT. For every bridge VLAN on every user port, a sub-VLAN index is calculated and retagging rules are installed towards a dsa_8021q rx_vid that encodes that sub-VLAN index. This way, the tagger can identify the original VLANs. Extra care is taken for VLANs to still work as intended in cross-chip scenarios. Retagging may have unintended consequences for these because a sub-VLAN encoding that works for the CPU does not make any sense for a front-panel port. Signed-off-by:
-
Vladimir Oltean authored
There are 2 different features that require some reserved frame memory space: VLAN retagging and virtual links. Create a central function that modifies the static config and ensures frame memory is never overcommitted. Signed-off-by:
-
Vladimir Oltean authored
The Retagging Table is an optional feature that allows the switch to match frames against a {ingress port, egress port, vid} rule and change their VLAN ID. The retagged frames are by default clones of the original ones (since the hardware-foreseen use case was to mirror traffic for debugging purposes and to tag it with a special VLAN for this purpose), but we can force the original frames to be dropped by removing the pre-retagging VLAN from the port membership list of the egress port. Signed-off-by: -
Vladimir Oltean authored
This devlink parameter enables the handling of DSA tags when enslaved to a bridge with vlan_filtering=1. There are very good reasons to want this, but there are also very good reasons for not enabling it by default. So a devlink param named best_effort_vlan_filtering, currently driver-specific and exported only by sja1105, is used to configure this. In practice, this is perhaps the way that most users are going to use the switch in. It assumes that no more than 7 VLANs are needed per port. Signed-off-by:
-
