- 13 2月, 2021 1 次提交
-
-
由 Vladimir Oltean 提交于
There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be expressed by the bridge through switchdev, and not all of them can be emulated by DSA mid-layer API at the same time. One possible configuration is when the bridge offloads the port flags using a mask that has a single bit set - therefore only one feature should change. However, DSA currently groups together unicast and multicast flooding in the .port_egress_floods method, which limits our options when we try to add support for turning off broadcast flooding: do we extend .port_egress_floods with a third parameter which b53 and mv88e6xxx will ignore? But that means that the DSA layer, which currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will see that .port_egress_floods is implemented, and will report that all 3 types of flooding are supported - not necessarily true. Another configuration is when the user specifies more than one flag at the same time, in the same netlink message. If we were to create one individual function per offloadable bridge port flag, we would limit the expressiveness of the switch driver of refusing certain combinations of flag values. For example, a switch may not have an explicit knob for flooding of unknown multicast, just for flooding in general. In that case, the only correct thing to do is to allow changes to BR_FLOOD and BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having a separate .port_set_unicast_flood and .port_set_multicast_flood would not allow the driver to possibly reject that. Also, DSA doesn't consider it necessary to inform the driver that a SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it just calls .port_egress_floods for the CPU port. When we'll add support for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real problem because the flood settings will need to be held statefully in the DSA middle layer, otherwise changing the mrouter port attribute will impact the flooding attribute. And that's _assuming_ that the underlying hardware doesn't have anything else to do when a multicast router attaches to a port than flood unknown traffic to it. If it does, there will need to be a dedicated .port_set_mrouter anyway. So we need to let the DSA drivers see the exact form that the bridge passes this switchdev attribute in, otherwise we are standing in the way. Therefore we also need to use this form of language when communicating to the driver that it needs to configure its initial (before bridge join) and final (after bridge leave) port flags. The b53 and mv88e6xxx drivers are converted to the passthrough API and their implementation of .port_egress_floods is split into two: a function that configures unicast flooding and another for multicast. The mv88e6xxx implementation is quite hairy, and it turns out that the implementations of unknown unicast flooding are actually the same for 6185 and for 6352: behind the confusing names actually lie two individual bits: NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2) NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3) so there was no reason to entangle them in the first place. Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of PORT_CTL0, which has the exact same bit index. I have left the implementations separate though, for the only reason that the names are different enough to confuse me, since I am not able to double-check with a user manual. The multicast flooding setting for 6185 is in a different register than for 6352 though. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 2月, 2021 1 次提交
-
-
由 DENG Qingfang 提交于
Having multiple destination ports for a unicast address does not make sense. Make port_db_load_purge override existent unicast portvec instead of adding a new port bit. Fixes: 88472939 ("net: dsa: mv88e6xxx: handle multiple ports in ATU") Signed-off-by: NDENG Qingfang <dqfext@gmail.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20210130134334.10243-1-dqfext@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 28 1月, 2021 1 次提交
-
-
由 Andrew Lunn 提交于
Early generations of the mv88e6xxx did not have the global 2 registers. In order to keep the driver slim, it was decided to make the code for these registers optional. Over time, more generations of switches have been added, always supporting global 2 and adding more and more registers. No effort has been made to keep these additional registers also optional to slim the driver down when used for older generations. Optional global 2 now just gives additional development and maintenance burden for no real gain. Make global 2 support always compiled in. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Tested-by: NVladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20210127003210.663173-1-andrew@lunn.chSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 27 1月, 2021 2 次提交
-
-
由 Rasmus Villemoes 提交于
Apart from the mask used to get the high bits of the fid, mv88e6185_g1_vtu_loadpurge() and mv88e6250_g1_vtu_loadpurge() are identical. Since the entry->fid passed in should never exceed the number of databases, we can simply use the former as-is as replacement for the latter. Suggested-by: NTobias Waldekranz <tobias@waldekranz.com> Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Rasmus Villemoes 提交于
mv88e6250_g1_vtu_getnext is almost identical to mv88e6185_g1_vtu_getnext, except for the 6250 only having 64 databases instead of 256. We can reduce code duplication by simply masking off the extra two garbage bits when assembling the fid from VTU op [3:0] and [11:8]. Reviewed-by: NTobias Waldekranz <tobias@waldekranz.com> Tested-by: NTobias Waldekranz <tobias@waldekranz.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 24 1月, 2021 1 次提交
-
-
由 Richard Cochran 提交于
The mv88e6xxx is a DSA driver, and it implements DSA style time stamping of PTP frames. It has no need of the expensive option to enable PHY time stamping. Remove the bogus dependency. Signed-off-by: NRichard Cochran <richardcochran@gmail.com> Acked-by: NBrandon Streiff <brandon.streiff@ni.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 19 1月, 2021 1 次提交
-
-
由 Rasmus Villemoes 提交于
mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069 (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NTobias Waldekranz <tobias@waldekranz.com> Tested-by: NTobias Waldekranz <tobias@waldekranz.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 16 1月, 2021 3 次提交
-
-
由 Vladimir Oltean 提交于
As explained in commit 54a0ed0d ("net: dsa: provide an option for drivers to always receive bridge VLANs"), DSA has historically been skipping VLAN switchdev operations when the bridge wasn't in vlan_filtering mode, but the reason why it was doing that has never been clear. So the configure_vlan_while_not_filtering option is there merely to preserve functionality for existing drivers. It isn't some behavior that drivers should opt into. Ideally, when all drivers leave this flag set, we can delete the dsa_port_skip_vlan_configuration() function. New drivers always seem to omit setting this flag, for some reason. So let's reverse the logic: the DSA core sets it by default to true before the .setup() callback, and legacy drivers can turn it off. This way, new drivers get the new behavior by default, unless they explicitly set the flag to false, which is more obvious during review. Remove the assignment from drivers which were setting it to true, and add the assignment to false for the drivers that didn't previously have it. This way, it should be easier to see how many we have left. The following drivers: lan9303, mv88e6060 were skipped from setting this flag to false, because they didn't have any VLAN offload ops in the first place. The Broadcom Starfighter 2 driver calls the common b53_switch_alloc and therefore also inherits the configure_vlan_while_not_filtering=true behavior. Also, print a message through netlink extack every time a VLAN has been skipped. This is mildly annoying on purpose, so that (a) it is at least clear that VLANs are being skipped - the legacy behavior in itself is confusing, and the extack should be much more difficult to miss, unlike kernel logs - and (b) people have one more incentive to convert to the new behavior. No behavior change except for the added prints is intended at this time. $ ip link add br0 type bridge vlan_filtering 0 $ ip link set sw0p2 master br0 [ 60.315148] br0: port 1(sw0p2) entered blocking state [ 60.320350] br0: port 1(sw0p2) entered disabled state [ 60.327839] device sw0p2 entered promiscuous mode [ 60.334905] br0: port 1(sw0p2) entered blocking state [ 60.340142] br0: port 1(sw0p2) entered forwarding state Warning: dsa_core: skipping configuration of VLAN. # This was the pvid $ bridge vlan add dev sw0p2 vid 100 Warning: dsa_core: skipping configuration of VLAN. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NKurt Kanzenbach <kurt@linutronix.de> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210115231919.43834-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Tobias Waldekranz 提交于
There are chips that do have Global 2 registers, and therefore trunk mapping/mask tables are not available. Refuse the offload as early as possible on those devices. Fixes: 57e661aa ("net: dsa: mv88e6xxx: Link aggregation support") Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Tobias Waldekranz 提交于
Support for Global 2 registers is build-time optional. In the case where it was not enabled the build would fail as no "dummy" implementation of these functions was available. Fixes: 57e661aa ("net: dsa: mv88e6xxx: Link aggregation support") Reported-by: Nkernel test robot <lkp@intel.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Tested-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 15 1月, 2021 1 次提交
-
-
由 Tobias Waldekranz 提交于
Support offloading of LAGs to hardware. LAGs may be attached to a bridge in which case VLANs, multicast groups, etc. are also offloaded as usual. Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 12 1月, 2021 5 次提交
-
-
由 Vladimir Oltean 提交于
It should be the driver's business to logically separate its VLAN offloading into a preparation and a commit phase, and some drivers don't need / can't do this. So remove the transactional shim from DSA and let drivers propagate errors directly from the .port_vlan_add callback. It would appear that the code has worse error handling now than it had before. DSA is the only in-kernel user of switchdev that offloads one switchdev object to more than one port: for every VLAN object offloaded to a user port, that VLAN is also offloaded to the CPU port. So the "prepare for user port -> check for errors -> prepare for CPU port -> check for errors -> commit for user port -> commit for CPU port" sequence appears to make more sense than the one we are using now: "offload to user port -> check for errors -> offload to CPU port -> check for errors", but it is really a compromise. In the new way, we can catch errors from the commit phase that we previously had to ignore. But we have our hands tied and cannot do any rollback now: if we add a VLAN on the CPU port and it fails, we can't do the rollback by simply deleting it from the user port, because the switchdev API is not so nice with us: it could have simply been there already, even with the same flags. So we don't even attempt to rollback anything on addition error, just leave whatever VLANs managed to get offloaded right where they are. This should not be a problem at all in practice. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NJiri Pirko <jiri@nvidia.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vladimir Oltean 提交于
For many drivers, the .port_mdb_prepare callback was not a good opportunity to avoid any error condition, and they would suppress errors found during the actual commit phase. Where a logical separation between the prepare and the commit phase existed, the function that used to implement the .port_mdb_prepare callback still exists, but now it is called directly from .port_mdb_add, which was modified to return an int code. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NJiri Pirko <jiri@nvidia.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Reviewed-by: Linus Wallei <linus.walleij@linaro.org> # RTL8366 Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vladimir Oltean 提交于
Since the introduction of the switchdev API, port attributes were transmitted to drivers for offloading using a two-step transactional model, with a prepare phase that was supposed to catch all errors, and a commit phase that was supposed to never fail. Some classes of failures can never be avoided, like hardware access, or memory allocation. In the latter case, merely attempting to move the memory allocation to the preparation phase makes it impossible to avoid memory leaks, since commit 91cf8ece ("switchdev: Remove unused transaction item queue") which has removed the unused mechanism of passing on the allocated memory between one phase and another. It is time we admit that separating the preparation from the commit phase is something that is best left for the driver to decide, and not something that should be baked into the API, especially since there are no switchdev callers that depend on this. This patch removes the struct switchdev_trans member from switchdev port attribute notifier structures, and converts drivers to not look at this member. In part, this patch contains a revert of my previous commit 2e554a7a ("net: dsa: propagate switchdev vlan_filtering prepare phase to drivers"). For the most part, the conversion was trivial except for: - Rocker's world implementation based on Broadcom OF-DPA had an odd implementation of ofdpa_port_attr_bridge_flags_set. The conversion was done mechanically, by pasting the implementation twice, then only keeping the code that would get executed during prepare phase on top, then only keeping the code that gets executed during the commit phase on bottom, then simplifying the resulting code until this was obtained. - DSA's offloading of STP state, bridge flags, VLAN filtering and multicast router could be converted right away. But the ageing time could not, so a shim was introduced and this was left for a further commit. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NJiri Pirko <jiri@nvidia.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Reviewed-by: Linus Walleij <linus.walleij@linaro.org> # RTL8366RB Reviewed-by: NIdo Schimmel <idosch@nvidia.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vladimir Oltean 提交于
mv88e6xxx apparently has a problem offloading VID 0, which the 8021q module tries to install as part of commit ad1afb00 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)"). That mv88e6xxx restriction seems to have been introduced by the "VTU GetNext VID-1 trick to retrieve a single entry" - see commit 2fb5ef09 ("net: dsa: mv88e6xxx: extract single VLAN retrieval"). There is one more problem. The mv88e6xxx CPU port and DSA links do not report properly in the prepare phase what are the VLANs that they can offload. They'll say they can offload everything: mv88e6xxx_port_vlan_prepare -> mv88e6xxx_port_check_hw_vlan: /* DSA and CPU ports have to be members of multiple vlans */ if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port)) return 0; Except that if you actually try to commit to it, they'll error out and print this message: [ 32.802438] mv88e6085 d0032004.mdio-mii:12: p9: failed to add VLAN 0t which comes from: mv88e6xxx_port_vlan_add -> mv88e6xxx_port_vlan_join: if (!vid) return -EOPNOTSUPP; What prevents this condition from triggering in real life? The fact that when a DSA_NOTIFIER_VLAN_ADD is emitted, it never targets a DSA link directly. Instead, the notifier will always target either a user port or a CPU port. DSA links just happen to get dragged in by: static bool dsa_switch_vlan_match(struct dsa_switch *ds, int port, struct dsa_notifier_vlan_info *info) { ... if (dsa_is_dsa_port(ds, port)) return true; ... } So for every DSA VLAN notifier, during the prepare phase, it will just so happen that there will be somebody to say "no, don't do that". This will become a problem when the switchdev prepare/commit transactional model goes away. Every port needs to think on its own. DSA links can no longer bluff and rely on the fact that the prepare phase will not go through to the end, because there will be no prepare phase any longer. Fix this issue before it becomes a problem, by having the "vid == 0" check earlier than the check whether we are a CPU port / DSA link or not. Also, the "vid == 0" check becomes unnecessary in the .port_vlan_add callback, so we can remove it. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vladimir Oltean 提交于
The call path of a switchdev VLAN addition to the bridge looks something like this today: nbp_vlan_init | __br_vlan_set_default_pvid | | | | | br_afspec | | | | | | | v | | | br_process_vlan_info | | | | | | | v | | | br_vlan_info | | | / \ / | | / \ / | | / \ / | | / \ / v v v v v nbp_vlan_add br_vlan_add ------+ | ^ ^ | | | / | | | | / / / | \ br_vlan_get_master/ / v \ ^ / / br_vlan_add_existing \ | / / | \ | / / / \ | / / / \ | / / / \ | / / / v | | v / __vlan_add / / | / / | / v | / __vlan_vid_add | / \ | / v v v br_switchdev_port_vlan_add The ranges UAPI was introduced to the bridge in commit bdced7ef ("bridge: support for multiple vlans and vlan ranges in setlink and dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec) have always been passed one by one, through struct bridge_vlan_info tmp_vinfo, to br_vlan_info. So the range never went too far in depth. Then Scott Feldman introduced the switchdev_port_bridge_setlink function in commit 47f8328b ("switchdev: add new switchdev bridge setlink"). That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made full use of the range. But switchdev_port_bridge_setlink was called like this: br_setlink -> br_afspec -> switchdev_port_bridge_setlink Basically, the switchdev and the bridge code were not tightly integrated. Then commit 41c498b9 ("bridge: restore br_setlink back to original") came, and switchdev drivers were required to implement .ndo_bridge_setlink = switchdev_port_bridge_setlink for a while. In the meantime, commits such as 0944d6b5 ("bridge: try switchdev op first in __vlan_vid_add/del") finally made switchdev penetrate the br_vlan_info() barrier and start to develop the call path we have today. But remember, br_vlan_info() still receives VLANs one by one. Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit 29ab586c ("net: switchdev: Remove bridge bypass support from switchdev") so that drivers would not implement .ndo_bridge_setlink any longer. The switchdev_port_bridge_setlink also got deleted. This refactoring removed the parallel bridge_setlink implementation from switchdev, and left the only switchdev VLAN objects to be the ones offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add (the latter coming from commit 9c86ce2c ("net: bridge: Notify about bridge VLANs")). That is to say, today the switchdev VLAN object ranges are not used in the kernel. Refactoring the above call path is a bit complicated, when the bridge VLAN call path is already a bit complicated. Let's go off and finish the job of commit 29ab586c by deleting the bogus iteration through the VLAN ranges from the drivers. Some aspects of this feature never made too much sense in the first place. For example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID flag supposed to mean, when a port can obviously have a single pvid? This particular configuration _is_ denied as of commit 6623c60d ("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API perspective, the driver still has to play pretend, and only offload the vlan->vid_end as pvid. And the addition of a switchdev VLAN object can modify the flags of another, completely unrelated, switchdev VLAN object! (a VLAN that is PVID will invalidate the PVID flag from whatever other VLAN had previously been offloaded with switchdev and had that flag. Yet switchdev never notifies about that change, drivers are supposed to guess). Nonetheless, having a VLAN range in the API makes error handling look scarier than it really is - unwinding on errors and all of that. When in reality, no one really calls this API with more than one VLAN. It is all unnecessary complexity. And despite appearing pretentious (two-phase transactional model and all), the switchdev API is really sloppy because the VLAN addition and removal operations are not paired with one another (you can add a VLAN 100 times and delete it just once). The bridge notifies through switchdev of a VLAN addition not only when the flags of an existing VLAN change, but also when nothing changes. There are switchdev drivers out there who don't like adding a VLAN that has already been added, and those checks don't really belong at driver level. But the fact that the API contains ranges is yet another factor that prevents this from being addressed in the future. Of the existing switchdev pieces of hardware, it appears that only Mellanox Spectrum supports offloading more than one VLAN at a time, through mlxsw_sp_port_vlan_set. I have kept that code internal to the driver, because there is some more bookkeeping that makes use of it, but I deleted it from the switchdev API. But since the switchdev support for ranges has already been de facto deleted by a Mellanox employee and nobody noticed for 4 years, I'm going to assume it's not a biggie. Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 15 12月, 2020 1 次提交
-
-
由 Rasmus Villemoes 提交于
The 6220 and 6250 switches do not have a learn2all bit in global1, ATU control register; bit 3 is reserverd. On the switches that do have that bit, it is used to control whether learning frames are sent out the ports that have the message_port bit set. So rather than adding yet another chip method, use the existence of the ->port_setup_message_port method as a proxy for determining whether the learn2all bit exists (and should be set). Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk> Link: https://lore.kernel.org/r/20201210110645.27765-1-rasmus.villemoes@prevas.dkSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 10 12月, 2020 1 次提交
-
-
由 Zheng Yongjun 提交于
Replace a comma between expression statements by a semicolon. Signed-off-by: NZheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 11月, 2020 4 次提交
-
-
由 Chris Packham 提交于
If the underlying read operation failed we would end up writing stale data to the supplied buffer. This would end up with the last successfully read value repeating. Fix this by only writing the data when we know the read was good. This will mean that failed values will return 0xffff. 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>
-
由 Chris Packham 提交于
The MV88E6097 presents the serdes interrupts for ports 8 and 9 via the Switch Global 2 registers. There is no additional layer of enablinh/disabling the serdes interrupts like other mv88e6xxx switches. Even though most of the serdes behaviour is the same as the MV88E6185 that chip does not provide interrupts for serdes events so unlike earlier commits the functions added here are specific to the MV88E6097. 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>
-
由 Chris Packham 提交于
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes ports and directly connected to other network interfaces or to SFPs without a PHY. 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>
-
由 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>
-
- 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>
-
- 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 1 次提交
-
-
由 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>
-
- 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>
-
- 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>
-
- 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>
-
- 19 9月, 2020 4 次提交
-
-
由 Andrew Lunn 提交于
Return the driver name and the asic.id with the switch name. Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Reviewed-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Lunn 提交于
Allow the global registers, and the ATU to be snapshot via devlink regions. It is later planned to add support for the port registers. v2: Remove left over debug prints Comment ATU format is generic for mv88e6xxx, not wider v3: Make use of ops structure passed to snapshot function Remove port regions v4: Make use of enum mv88e6xxx_region_id Fix global2/global1 read typ0 Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Lunn 提交于
Refactor the code in mv88e6xxx_atu_new() which builds a bitmaps of FIDs in use into a helper function. This will be reused by the devlink code when dumping the ATU. Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Lunn 提交于
There will soon be more devlink code. Move the existing code into a file of its own, before we start adding this new code. Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 9月, 2020 1 次提交
-
-
由 Andrew Lunn 提交于
When building on platforms without device tree, e.g. amd64, W=1 gives a warning about mv88e6xxx_mdio_external_match being unused. Replace of_match_node() with of_device_is_compatible() to prevent this warning. Suggested-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 8月, 2020 1 次提交
-
-
由 Gustavo A. R. Silva 提交于
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
-
- 20 8月, 2020 1 次提交
-
-
由 Kurt Kanzenbach 提交于
In order to reduce code duplication between ptp drivers, generic helper functions were introduced. Use them. Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de> Tested-by: NRichard Cochran <richardcochran@gmail.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 7月, 2020 3 次提交
-
-
由 Chris Packham 提交于
Some of the chips in the mv88e6xxx family don't support jumbo configuration per port. But they do have a chip-wide max frame size that can be used. Use this to approximate the behaviour of configuring a port based MTU. Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Chris Packham 提交于
The MV88E6190 and MV88E6190X both support per port jumbo configuration just like the other GE switches. Install the appropriate ops. Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Chris Packham 提交于
The MV88E6097 chip does not support configuring jumbo frames. Prior to commit 5f436666 only the 6352, 6351, 6165 and 6320 chips configured jumbo mode. The refactor accidentally added the function for the 6097. Remove the erroneous function pointer assignment. Fixes: 5f436666 ("net: dsa: mv88e6xxx: Refactor setting of jumbo frames") Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-