- 26 11月, 2020 4 次提交
-
-
由 Chris Packham 提交于
When a port is configured with 'managed = "in-band-status"' switch chips like the 88E6390 need to propagate the SERDES link state to the MAC because the link state is not correctly detected. This causes problems on the 88E6185/88E6097 where the link partner won't see link state changes because we're forcing the link. To address this introduce a new device specific op port_sync_link() and push the logic from mv88e6xxx_mac_link_up() into that. Provide an implementation for the 88E6185 like devices which doesn't force the link. Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Christian Eggers 提交于
This should be done in the device driver instead of the device tree. Signed-off-by: NChristian Eggers <ceggers@arri.de> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Christian Eggers 提交于
This should be done in the device driver instead of the device tree. Signed-off-by: NChristian Eggers <ceggers@arri.de> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Christian Eggers 提交于
The dsa.yaml device tree binding allows "ethernet-ports" (preferred) and "ports". Signed-off-by: NChristian Eggers <ceggers@arri.de> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 24 11月, 2020 1 次提交
-
-
由 Kurt Kanzenbach 提交于
When DSA is not loaded when the driver is probed an error message is printed. But, that's not really an error, just a defer. Use dev_err_probe() instead. Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 19 11月, 2020 1 次提交
-
-
由 Andrew Lunn 提交于
When the switch is hardware reset, it reads the contents of the EEPROM. This can contain instructions for programming values into registers and to perform waits between such programming. Reading the EEPROM can take longer than the 100ms mv88e6xxx_hardware_reset() waits after deasserting the reset GPIO. So poll the EEPROM done bit to ensure it is complete. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NRuslan Sushko <rus@sushko.dev> Link: https://lore.kernel.org/r/20201116164301.977661-1-rus@sushko.devSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 17 11月, 2020 1 次提交
-
-
由 Martin Blumenstingl 提交于
A user reports (slightly shortened from the original message): libphy: lantiq,xrx200-mdio: probed mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing. gswip 1e108000.switch lan: no phy at 2 gswip 1e108000.switch lan: failed to connect to port 2: -19 lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy This is a single-port board using the internal Fast Ethernet PHY. The user reports that switching to PHY scanning instead of configuring the PHY within device-tree works around this issue. The documentation for the standalone variant of the PHY11G (which is probably very similar to what is used inside the xRX200 SoCs but having the firmware burnt onto that standalone chip in the factory) states that the PHY needs 300ms to be ready for MDIO communication after releasing the reset. Add a 300ms delay after initializing all GPHYs to ensure that the GPHY firmware had enough time to initialize and to appear on the MDIO bus. Unfortunately there is no (known) documentation on what the minimum time to wait after releasing the reset on an internal PHY so play safe and take the one for the external variant. Only wait after the last GPHY firmware is loaded to not slow down the initialization too much ( xRX200 has two GPHYs but newer SoCs have at least three GPHYs). Fixes: 14fceff4 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: NHauke Mehrtens <hauke@hauke-m.de> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20201115165757.552641-1-martin.blumenstingl@googlemail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 15 11月, 2020 1 次提交
-
-
由 Tobias Waldekranz 提交于
As soon as you add the second port to a VLAN, all other port membership configuration is overwritten with zeroes. The HW interprets this as all ports being "unmodified members" of the VLAN. In the simple case when all ports belong to the same VLAN, switching will still work. But using multiple VLANs or trying to set multiple ports as tagged members will not work. On the 6352, doing a VTU GetNext op, followed by an STU GetNext op will leave you with both the member- and state- data in the VTU/STU data registers. But on the 6097 (which uses the same implementation), the STU GetNext will override the information gathered from the VTU GetNext. Separate the two stages, parsing the result of the VTU GetNext before doing the STU GetNext. We opt to update the existing implementation for all applicable chips, as opposed to creating a separate callback for 6097, because although the previous implementation did work for (at least) 6352, the datasheet does not mention the masking behavior. Fixes: ef6fcea3 ("net: dsa: mv88e6xxx: get STU entry on VTU GetNext") Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com> Link: https://lore.kernel.org/r/20201112114335.27371-1-tobias@waldekranz.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 12 11月, 2020 1 次提交
-
-
由 Tobias Waldekranz 提交于
Most of the other chip info constants have helpers to get at them; add one for max_vid to keep things consistent. Suggested-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201110185720.18228-1-tobias@waldekranz.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 11 11月, 2020 2 次提交
-
-
由 zhangxiaoxu 提交于
When mv88e6xxx_fid_map return error, we lost free the table. Fix it. Fixes: bfb25542 ("net: dsa: mv88e6xxx: Add devlink regions") Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: Nzhangxiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201109144416.1540867-1-zhangxiaoxu5@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Colin Ian King 提交于
The left shift of u16 variable high is promoted to the type int and then sign extended to a 64 bit u64 value. If the top bit of high is set then the upper 32 bits of the result end up being set by the sign extension. Fix this by explicitly casting the value in high to a u64 before left shifting by 16 places. Also, remove the initialisation of variable value to 0 at the start of each loop iteration as the value is never read and hence the assignment it is redundant. Addresses-Coverity: ("Unintended sign extension") Fixes: e4b27ebc ("net: dsa: Add DSA driver for Hirschmann Hellcreek switches") Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NKurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20201109124008.2079873-1-colin.king@canonical.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 10 11月, 2020 1 次提交
-
-
由 Tobias Waldekranz 提交于
Export the raw VTU data and related registers in a devlink region so that it can be inspected from userspace and compared to the current bridge configuration. Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201109082927.8684-1-tobias@waldekranz.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 06 11月, 2020 4 次提交
-
-
由 Kurt Kanzenbach 提交于
The switch has two controllable I/Os which are usually connected to LEDs. This is useful to immediately visually see the PTP status. These provide two signals: * is_gm This LED can be activated if the current device is the grand master in that PTP domain. * sync_good This LED can be activated if the current device is in sync with the network time. Expose these via the LED framework to be controlled via user space e.g. linuxptp. Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Kamil Alkhouri 提交于
The switch has the ability to take hardware generated time stamps per port for PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed time synchronization precision for TSN devices/switches. So add support for it. There are two directions: * RX The switch has a single register per port to capture a timestamp. That mechanism is not used due to correlation problems. If the software processing is too slow and a PTPv2 event message is received before the previous one has been processed, false timestamps will be captured. Therefore, the switch can do "inline" timestamping which means it can insert the nanoseconds part of the timestamp directly into the PTPv2 event message. The reserved field (4 bytes) is leveraged for that. This might not be in accordance with (older) PTP standards, but is the only way to get reliable results. * TX In Tx direction there is no correlation problem, because the software and the driver has to ensure that only one event message is "on the fly". However, the switch provides also a mechanism to check whether a timestamp is lost. That can only happen when a timestamp is read and at this point another message is timestamped. So, that lost bit is checked just in case to indicate to the user that the driver or the software is somewhat buggy. Signed-off-by: NKamil Alkhouri <kamil.alkhouri@hs-offenburg.de> Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de> Acked-by: NRichard Cochran <richardcochran@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Kamil Alkhouri 提交于
The switch has internal PTP hardware clocks. Add support for it. There are three clocks: * Synchronized * Syntonized * Free running Currently the synchronized clock is exported to user space which is a good default for the beginning. The free running clock might be exported later e.g. for implementing 802.1AS-2011/2020 Time Aware Bridges (TAB). The switch also supports cross time stamping for that purpose. The implementation adds support setting/getting the time as well as offset and frequency adjustments. However, the clock only holds a partial timeofday timestamp. This is why we track the seconds completely in software (see overflow work and last_ts). Furthermore, add the PTP multicast addresses into the FDB to forward that packages only to the CPU port where they are processed by a PTP program. Signed-off-by: NKamil Alkhouri <kamil.alkhouri@hs-offenburg.de> Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de> Acked-by: NRichard Cochran <richardcochran@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Kurt Kanzenbach 提交于
Add a basic DSA driver for Hirschmann Hellcreek switches. Those switches are implementing features needed for Time Sensitive Networking (TSN) such as support for the Time Precision Protocol and various shapers like the Time Aware Shaper. This driver includes basic support for networking: * VLAN handling * FDB handling * Port statistics * STP * Phylink Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 05 11月, 2020 1 次提交
-
-
由 DENG Qingfang 提交于
MT7530/7531 has a global RX packet length register, which can be used to set MTU. Supported packet length values are 1522 (1518 if untagged), 1536, 1552, and multiple of 1024 (from 2048 to 15360). Signed-off-by: NDENG Qingfang <dqfext@gmail.com> Link: https://lore.kernel.org/r/20201103050618.11419-1-dqfext@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 03 11月, 2020 4 次提交
-
-
由 Tom Rix 提交于
A semicolon is not needed after a switch statement. Signed-off-by: NTom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201031153047.2147341-1-trix@redhat.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vladimir Oltean 提交于
After the good discussion with Florian from here: https://lore.kernel.org/netdev/20200911000337.htwr366ng3nc3a7d@skbuf/ I realized that the VLAN settings on the NPI port (the hardware "CPU port", in DSA parlance) don't actually make any difference, because that port is hardcoded in hardware to use what mv88e6xxx would call "unmodified" egress policy for VLANs. So earlier patch 183be6f9 ("net: dsa: felix: send VLANs on CPU port as egress-tagged") was incorrect in the sense that it didn't actually make the VLANs be sent on the NPI port as egress-tagged. It only made ocelot_port_set_native_vlan shut up. Now that we have moved the check from ocelot_port_set_native_vlan to ocelot_vlan_prepare, we can simply shunt ocelot_vlan_prepare from DSA, and avoid calling it. This is the correct way to deal with things, because the NPI port configuration is DSA-specific, so the ocelot switch library should not have the check for multiple native VLANs refined in any way, it is correct the way it is. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vladimir Oltean 提交于
Put the preparation phase of switchdev VLAN objects to some good use, and move the check we already had, for preventing the existence of more than one egress-untagged VLAN per port, to the preparation phase of the addition. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Jonathan McDowell 提交于
The qca8k only supports a switch-wide MTU setting, and the code to take the max of all ports was only looking at the port currently being set. Fix to examine all ports. Reported-by: NDENG Qingfang <dqfext@gmail.com> Fixes: f58d2598 ("net: dsa: qca8k: implement the port MTU callbacks") Signed-off-by: NJonathan McDowell <noodles@earth.li> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201030183315.GA6736@earth.liSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 31 10月, 2020 1 次提交
-
-
由 Russell King 提交于
DSA assumes that a bridge which has vlan filtering disabled is not vlan aware, and ignores all vlan configuration. However, the kernel software bridge code allows configuration in this state. This causes the kernel's idea of the bridge vlan state and the hardware state to disagree, so "bridge vlan show" indicates a correct configuration but the hardware lacks all configuration. Even worse, enabling vlan filtering on a DSA bridge immediately blocks all traffic which, given the output of "bridge vlan show", is very confusing. Allow the VLAN configuration to be updated on Marvell DSA bridges, otherwise we end up cutting all traffic when enabling vlan filtering. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Tested-by: NVladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/E1kYAU3-00071C-1G@rmk-PC.armlinux.org.ukSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 21 10月, 2020 1 次提交
-
-
由 Colin Ian King 提交于
Don't populate the const array rate_table on the stack but instead it static. Makes the object code smaller by 46 bytes. Before: text data bss dec hex filename 29812 3824 192 33828 8424 drivers/net/dsa/bcm_sf2.o After: text data bss dec hex filename 29670 3920 192 33782 83f6 drivers/net/dsa/bcm_sf2.o (gcc version 10.2.0) Signed-off-by: NColin Ian King <colin.king@canonical.com> Acked-by: NFlorian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20201020165029.56383-1-colin.king@canonical.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 20 10月, 2020 1 次提交
-
-
由 Maxim Kochetkov 提交于
The VSC9953 Seville switch has 2 megabits of buffer split into 4360 words of 60 bytes each. 2048 * 1024 is 2 megabytes instead of 2 megabits. 2 megabits is (2048 / 8) * 1024 = 256 * 1024. Signed-off-by: NMaxim Kochetkov <fido_max@inbox.ru> Reviewed-by: NVladimir Oltean <vladimir.oltean@nxp.com> Fixes: a63ed92d ("net: dsa: seville: fix buffer size of the queue system") Link: https://lore.kernel.org/r/20201019050625.21533-1-fido_max@inbox.ruSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 13 10月, 2020 1 次提交
-
-
由 Christian Eggers 提交于
Between queuing the delayed work and finishing the setup of the dsa ports, the process may sleep in request_module() (via phy_device_create()) and the queued work may be executed prior to the switch net devices being registered. In ksz_mib_read_work(), a NULL dereference will happen within netof_carrier_ok(dp->slave). Not queuing the delayed work in ksz_init_mib_timer() makes things even worse because the work will now be queued for immediate execution (instead of 2000 ms) in ksz_mac_link_down() via dsa_port_link_register_of(). Call tree: ksz9477_i2c_probe() \--ksz9477_switch_register() \--ksz_switch_register() +--dsa_register_switch() | \--dsa_switch_probe() | \--dsa_tree_setup() | \--dsa_tree_setup_switches() | +--dsa_switch_setup() | | +--ksz9477_setup() | | | \--ksz_init_mib_timer() | | | |--/* Start the timer 2 seconds later. */ | | | \--schedule_delayed_work(&dev->mib_read, msecs_to_jiffies(2000)); | | \--__mdiobus_register() | | \--mdiobus_scan() | | \--get_phy_device() | | +--get_phy_id() | | \--phy_device_create() | | |--/* sleeping, ksz_mib_read_work() can be called meanwhile */ | | \--request_module() | | | \--dsa_port_setup() | +--/* Called for non-CPU ports */ | +--dsa_slave_create() | | +--/* Too late, ksz_mib_read_work() may be called beforehand */ | | \--port->slave = ... | ... | +--Called for CPU port */ | \--dsa_port_link_register_of() | \--ksz_mac_link_down() | +--/* mib_read must be initialized here */ | +--/* work is already scheduled, so it will be executed after 2000 ms */ | \--schedule_delayed_work(&dev->mib_read, 0); \-- /* here port->slave is setup properly, scheduling the delayed work should be safe */ Solution: 1. Do not queue (only initialize) delayed work in ksz_init_mib_timer(). 2. Only queue delayed work in ksz_mac_link_down() if init is completed. 3. Queue work once in ksz_switch_register(), after dsa_register_switch() has completed. Fixes: 7c6ff470 ("net: dsa: microchip: add MIB counter reading support") Signed-off-by: NChristian Eggers <ceggers@arri.de> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 11 10月, 2020 1 次提交
-
-
由 Linus Walleij 提交于
The MTU setting for this DSA switch is global so we need to keep track of the MTU set for each port, then as soon as any MTU changes, roof the MTU to the biggest common denominator and poke that into the switch MTU setting. To achieve this we need a per-chip-variant state container for the RTL8366RB to use for the RTL8366RB-specific stuff. Other SMI switches does seem to have per-port MTU setting capabilities. Fixes: 5f4a8ef3 ("net: dsa: rtl8366rb: Support setting MTU") Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 10 10月, 2020 1 次提交
-
-
由 Christian Eggers 提交于
Add support for the KSZ9563 3-Port Gigabit Ethernet Switch to the ksz9477 driver. The KSZ9563 supports both SPI (already in) and I2C. The ksz9563 is already in the device tree binding documentation. Signed-off-by: NChristian Eggers <ceggers@arri.de> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 06 10月, 2020 1 次提交
-
-
由 Vladimir Oltean 提交于
There is an upper bound to the value that a watermark may hold. That upper bound is not immediately obvious during configuration, and it might be possible to have accidental truncation. Actually this has happened already, add a warning to prevent it from happening again. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 10月, 2020 2 次提交
-
-
由 Vladimir Oltean 提交于
A driver may refuse to enable VLAN filtering for any reason beyond what the DSA framework cares about, such as: - having tc-flower rules that rely on the switch being VLAN-aware - the particular switch does not support VLAN, even if the driver does (the DSA framework just checks for the presence of the .port_vlan_add and .port_vlan_del pointers) - simply not supporting this configuration to be toggled at runtime Currently, when a driver rejects a configuration it cannot support, it does this from the commit phase, which triggers various warnings in switchdev. So propagate the prepare phase to drivers, to give them the ability to refuse invalid configurations cleanly and avoid the warnings. Since we need to modify all function prototypes and check for the prepare phase from within the drivers, take that opportunity and move the existing driver restrictions within the prepare phase where that is possible and easy. Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Woojung Huh <woojung.huh@microchip.com> Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Landen Chao <Landen.Chao@mediatek.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Vivien Didelot <vivien.didelot@gmail.com> Cc: Jonathan McDowell <noodles@earth.li> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Lunn 提交于
Add a devlink region to return the per port registers. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 10月, 2020 1 次提交
-
-
由 Vladimir Oltean 提交于
This is a strictly cosmetic change that renames some macros in sja1105_dynamic_config.c. They were copy-pasted in haste and this has resulted in them having the driver prefix twice. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 03 10月, 2020 3 次提交
-
-
由 Xiaoliang Yang 提交于
VCAP IS1 is a VCAP module which can filter on the most common L2/L3/L4 Ethernet keys, and modify the results of the basic QoS classification and VLAN classification based on those flow keys. There are 3 VCAP IS1 lookups, mapped over chains 10000, 11000 and 12000. Currently the driver is hardcoded to use IS1_ACTION_TYPE_NORMAL half keys. Note that the VLAN_MANGLE has been omitted for now. In hardware, the VCAP_IS1_ACT_VID_REPLACE_ENA field replaces the classified VLAN (metadata associated with the frame) and not the VLAN from the header itself. There are currently some issues which need to be addressed when operating in standalone, or in bridge with vlan_filtering=0 modes, because in those cases the switch ports have VLAN awareness disabled, and changing the classified VLAN to anything other than the pvid causes the packets to be dropped. Another issue is that on egress, we expect port tagging to push the classified VLAN, but port tagging is disabled in the modes mentioned above, so although the classified VLAN is replaced, it is not visible in the packet transmitted by the switch. Signed-off-by: NXiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
Since the mscc_ocelot_switch_lib is common between a pure switchdev and a DSA driver, the procedure of retrieving a net_device for a certain port index differs, as those are registered by their individual front-ends. Up to now that has been dealt with by always passing the port index to the switch library, but now, we're going to need to work with net_device pointers from the tc-flower offload, for things like indev, or mirred. It is not desirable to refactor that, so let's make sure that the flower offload core has the ability to translate between a net_device and a port index properly. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Florian Fainelli 提交于
Indicate to the DSA receive path that we need to untage the bridge PVID, this allows us to remove the dsa_untag_bridge_pvid() calls from net/dsa/tag_brcm.c. Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 30 9月, 2020 6 次提交
-
-
由 Vladimir Oltean 提交于
Now that we are deriving these from the constants exposed by the hardware, we can delete the static info we're keeping in the driver. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
The numbers in struct vcap_props are not intuitive to derive, because they are not a straightforward copy-and-paste from the reference manual but instead rely on a fairly detailed level of understanding of the layout of an entry in the TCAM and in the action RAM. For this reason, bugs are very easy to introduce here. Ease the work of hardware porters and read from hardware the constants that were exported for this particular purpose. Note that this implies that struct vcap_props can no longer be const. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
As a preparation step for the offloading to ES0, let's create the infrastructure for talking with this hardware block. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
As a preparation step for the offloading to IS1, let's create the infrastructure for talking with this hardware block. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
In the Ocelot switches there are 3 TCAMs: VCAP ES0, IS1 and IS2, which have the same configuration interface, but different sets of keys and actions. The driver currently only supports VCAP IS2. In preparation of VCAP IS1 and ES0 support, the existing code must be generalized to work with any VCAP. In that direction, we should move the structures that depend upon VCAP instantiation, like vcap_is2_keys and vcap_is2_actions, out of struct ocelot and into struct vcap_props .keys and .actions, a structure that is replicated 3 times, once per VCAP. We'll pass that structure as an argument to each function that does the key and action packing - only the control logic needs to distinguish between ocelot->vcap[VCAP_IS2] or IS1 or ES0. Another change is to make use of the newly introduced ocelot_target_read and ocelot_target_write API, since the 3 VCAPs have the same registers but put at different addresses. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vladimir Oltean 提交于
Since the actions are packed together in the action RAM, an incorrect action width means that no action except the first one would behave correctly. The tc-flower offload has probably not been tested on this hardware since its introduction. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-