Changes in 8021q.h

85aabd1f - net: dsa: prepare 'dsa_tag_8021q_bridge_join' for standalone use

Sat, 13 Jul 2024 21:16:16 +0000

net: dsa: prepare 'dsa_tag_8021q_bridge_join' for standalone useThe 'dsa_tag_8021q_bridge_join' could be used as a generic implementationof the 'ds->ops->port_bridge_join()' function. However, it is necessaryto synchronize their arguments.This patch also moves the 'tx_fwd_offload' flag configuration line into'dsa_tag_8021q_bridge_join' body. Currently, every (sja1105) driver setsit, and the future vsc73xx implementation will also need it forsimplification.Suggested-by: Vladimir Oltean Signed-off-by: Pawel Dembicki Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20240713211620.1125910-11-paweldembicki@gmail.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/include/linux/dsa/8021q.h

ce20fdd6 - net: dsa: Define max num of bridges in tag8021q implementation

Sat, 13 Jul 2024 21:16:15 +0000

net: dsa: Define max num of bridges in tag8021q implementationMax number of bridges in tag8021q implementation is strictly limitedby VBID size: 3 bits. But zero is reserved and only 7 values can be used.This patch adds define which describe maximum possible value.Suggested-by: Vladimir Oltean Signed-off-by: Pawel Dembicki Reviewed-by: Florian Fainelli Reviewed-by: Linus Walleij Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20240713211620.1125910-10-paweldembicki@gmail.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/include/linux/dsa/8021q.h

19d05ea7 - net: dsa: move tag_8021q headers to their proper place

Mon, 21 Nov 2022 13:55:54 +0000

net: dsa: move tag_8021q headers to their proper placetag_8021q definitions are all over the place. Some are exported tolinux/dsa/8021q.h (visible by DSA core, taggers, switch drivers andeveryone else), and some are in dsa_priv.h.Move the structures that don't need external visibility into tag_8021q.c,and the ones which don't need the world or switch drivers to see theminto tag_8021q.h.We also have the tag_8021q.h inclusion from switch.c, which is basicallythe entire reason why tag_8021q.c was built into DSA in commit8b6e638b4be2 ("net: dsa: build tag_8021q.c as part of DSA core").I still don't know how to better deal with that, so leave it alone.Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski List of files: /linux-6.15/include/linux/dsa/8021q.h

b6362bdf - net: dsa: tag_8021q: rename dsa_8021q_bridge_tx_fwd_offload_vid

Fri, 25 Feb 2022 09:22:21 +0000

net: dsa: tag_8021q: rename dsa_8021q_bridge_tx_fwd_offload_vidThe dsa_8021q_bridge_tx_fwd_offload_vid is no longer used just forbridge TX forwarding offload, it is the private VLAN reserved forVLAN-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 Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

04b67e18 - net: dsa: tag_8021q: merge RX and TX VLANs

Fri, 25 Feb 2022 09:22:20 +0000

net: dsa: tag_8021q: merge RX and TX VLANsIn the old Shared VLAN Learning mode of operation that tag_8021qpreviously used for forwarding, we needed to have distinct concepts foran RX and a TX VLAN.An RX VLAN could be installed on all ports that were members of a givenbridge, so that autonomous forwarding could still work, while a TX VLANwas dedicated for precise packet steering, so it just contained the CPUport and one egress port.Now that tag_8021q uses Independent VLAN Learning and imprecise RX/TXall over, those lines have been blurred and we no longer have the needto do precise TX towards a port that is in a bridge. As for standaloneports, 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 itreserves, and halving it. Previously, our DIR bits were encoding theVLAN direction (RX/TX) and were set to either 1 or 2. This meant thattag_8021q reserved 2K VLANs, or 50% of the available range.Change the DIR bits to a hardcoded value of 3 now, which makes tag_8021qreserve only 1K VLANs, and a different range now (the last 1K). This isdone so that we leave the old format in place in case we need to returnto it.In terms of code, the vid_is_dsa_8021q_rxvlan and vid_is_dsa_8021q_txvlanfunctions go away. Any vid_is_dsa_8021q is both a TX and an RX VLAN, andthey are no longer distinct. For example, felix which did differentthings for different VLAN types, now needs to handle the RX and the TXlogic for the same VLAN.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

d7f9787a - net: dsa: tag_8021q: add support for imprecise RX based on the VBID

Fri, 25 Feb 2022 09:22:17 +0000

net: dsa: tag_8021q: add support for imprecise RX based on the VBIDThe sja1105 switch can't populate the PORT field of the tag_8021q headerwhen sending a frame to the CPU with a non-zero VBID.Similar to dsa_find_designated_bridge_port_by_vid() which performsimprecise RX for VLAN-aware bridges, let's introduce a helper intag_8021q for performing imprecise RX based on the VLAN that it hasallocated for a VLAN-unaware bridge.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

91495f21 - net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging

Fri, 25 Feb 2022 09:22:16 +0000

net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridgingFor VLAN-unaware bridging, tag_8021q uses something perhaps a bit tootied with the sja1105 switch: each port uses the same pvid which is alsoused for standalone operation (a unique one from which the source portand device ID can be retrieved when packets from that port are forwardedto the CPU). Since each port has a unique pvid when performingautonomous forwarding, the switch must be configured for Shared VLANLearning (SVL) such that the VLAN ID itself is ignored when performingFDB lookups. Without SVL, packets would always be flooded, since FDBlookup in the source port's VLAN would never find any entry.First of all, to make tag_8021q more palatable to switches which mightnot support Shared VLAN Learning, let's just use a common VLAN for allports that are under the same bridge.Secondly, using Shared VLAN Learning means that FDB isolation can neverbe enforced. But if all ports under the same VLAN-unaware bridge sharethe same VLAN ID, it can.The disadvantage is that the CPU port can no longer perform precisesource port identification for these packets. But at least we have amechanism which has proven to be adequate for that situation: impreciseRX (dsa_find_designated_bridge_port_by_vid), which is what we use fortermination on VLAN-aware bridges.The VLAN ID that VLAN-unaware bridges will use with tag_8021q is thesame one as we were previously using for imprecise TX (bridge TXforwarding offload). It is already allocated, it is just a matter ofusing it.Note that because now all ports under the same bridge share the sameVLAN, the complexity of performing a tag_8021q bridge join decreasesdramatically. We no longer have to install the RX VLAN of a newlyjoining port into the port membership of the existing bridge ports.The newly joining port just becomes a member of the VLAN correspondingto that bridge, and the other ports are already members of it from whenthey joined the bridge themselves. So forwarding works properly.This means that we can unhook dsa_tag_8021q_bridge_{join,leave} from thecross-chip notifier level dsa_switch_bridge_{join,leave}. We can putthese calls directly into the sja1105 driver.With this new mode of operation, a port controlled by tag_8021q can havetwo pvids whereas before it could only have one. The pvid for standaloneoperation 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 portjoins a bridge, and restoring it when it leaves it.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

d3eed0e5 - net: dsa: keep the bridge_dev and bridge_num as part of the same structure

Mon, 06 Dec 2021 16:57:56 +0000

net: dsa: keep the bridge_dev and bridge_num as part of the same structureThe main desire behind this is to provide coherent bridge information tothe fast path without locking.For example, right now we set dp->bridge_dev and dp->bridge_num fromseparate code paths, it is theoretically possible for a packettransmission to read these two port properties consecutively and find abridge number which does not correspond with the bridge device.Another desire is to start passing more complex bridge information todsa_switch_ops functions. For example, with FDB isolation, it isexpected that drivers will need to be passed the bridge which requestedan FDB/MDB entry to be offloaded, and along with that bridge_dev, theassociated bridge_num should be passed too, in case the driver mightwant to implement an isolation scheme based on that number.We already pass the {bridge_dev, bridge_num} pair to the TX forwardingoffload switch API, however we'd like to remove that and squash it intothe basic bridge join/leave API. So that means we need to pass thispair to the bridge join/leave API.During dsa_port_bridge_leave, first we unset dp->bridge_dev, then wecall the driver's .port_bridge_leave with what used to be ourdp->bridge_dev, but provided as an argument.When bridge_dev and bridge_num get folded into a single structure, weneed to preserve this behavior in dsa_port_bridge_leave: we need a copyof what used to be in dp->bridge.Switch drivers check bridge membership by comparing dp->bridge_dev withthe provided bridge_dev, but now, if we provide the struct dsa_bridge asa pointer, they cannot keep comparing dp->bridge to the providedpointer, since this only points to an on-stack copy. To make thisobvious and prevent driver writers from forgetting and doing stupidthings, in this new API, the struct dsa_bridge is provided as a fullstructure (not very large, contains an int and a pointer) instead of apointer. An explicit comparison function needs to be used to determinebridge membership: dsa_port_offloads_bridge().Signed-off-by: Vladimir Oltean Reviewed-by: Alvin Šipraga Signed-off-by: Jakub Kicinski List of files: /linux-6.15/include/linux/dsa/8021q.h

3f9bb030 - net: dsa: make dp->bridge_num one-based

Mon, 06 Dec 2021 16:57:47 +0000

net: dsa: make dp->bridge_num one-basedI have seen too many bugs already due to the fact that we must encode aninvalid dp->bridge_num as a negative value, because the natural tendencyis to check that invalid value using (!dp->bridge_num). Latest examplecan be seen in commit 1bec0f05062c ("net: dsa: fix bridge_num notgetting cleared after ports leaving the bridge").Convert the existing users to assume that dp->bridge_num == 0 is theencoding for invalid, and valid bridge numbers start from 1.Signed-off-by: Vladimir Oltean Reviewed-by: Alvin Šipraga Signed-off-by: Jakub Kicinski List of files: /linux-6.15/include/linux/dsa/8021q.h

992e5cc7 - net: dsa: tag_8021q: make dsa_8021q_{rx,tx}_vid take dp as argument

Wed, 20 Oct 2021 17:49:55 +0000

net: dsa: tag_8021q: make dsa_8021q_{rx,tx}_vid take dp as argumentPass a single argument to dsa_8021q_rx_vid and dsa_8021q_tx_vid thatcontains the necessary information from the two arguments that arecurrently provided: the switch and the port number.Also rename those functions so that they have a dsa_port_* prefix, sincethey operate on a struct dsa_port *.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

b6ad86e6 - net: dsa: sja1105: add bridge TX data plane offload based on tag_8021q

Mon, 26 Jul 2021 16:55:35 +0000

net: dsa: sja1105: add bridge TX data plane offload based on tag_8021qThe main desire for having this feature in sja1105 is to support networkstack termination for traffic coming from a VLAN-aware bridge.For sja1105, offloading the bridge data plane means sending packetsas-is, with the proper VLAN tag, to the chip. The chip will look up itsFDB and forward them to the correct destination port.But we support bridge data plane offload even for VLAN-unaware bridges,and the implementation there is different. In fact, VLAN-unawarebridging is governed by tag_8021q, so it makes sense to have the.bridge_fwd_offload_add() implementation fully within tag_8021q.The key difference is that we only support 1 VLAN-aware bridge, but wesupport multiple VLAN-unaware bridges. So we need to make sure that theforwarding domain is not crossed by packets injected from the stack.For this, we introduce the concept of a tag_8021q TX VLAN for bridgeforwarding offload. As opposed to the regular TX VLANs which containonly 2 ports (the user port and the CPU port), a bridge data plane TXVLAN is "multicast" (or "imprecise"): it contains all the ports that arepart of a certain bridge, and the hardware will select where the packetgoes within this "imprecise" forwarding domain.Each VLAN-unaware bridge has its own "imprecise" TX VLAN, so we make useof the unique "bridge_num" provided by DSA for the data plane offload.We use the same 3 bits from the tag_8021q VLAN ID format to encode thisbridge number.Note that these 3 bit positions have been used before for sub-VLANs inbest-effort VLAN filtering mode. The difference is that for best-effort,the sub-VLANs were only valid on RX (and it was documented that thesub-VLAN field needed to be transmitted as zero). Whereas for the bridgedata plane offload, these 3 bits are only valid on TX.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

c64b9c05 - net: dsa: tag_8021q: add proper cross-chip notifier support

Mon, 19 Jul 2021 17:14:52 +0000

net: dsa: tag_8021q: add proper cross-chip notifier supportThe big problem which mandates cross-chip notifiers for tag_8021q isthis: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ]When the user runs:ip link add br0 type bridgeip link set sw0p0 master br0ip link set sw2p0 master br0It doesn't work.This is because dsa_8021q_crosschip_bridge_join() assumes that "ds" and"other_ds" are at most 1 hop away from each other, so it is sufficientto add the RX VLAN of {ds, port} into {other_ds, other_port} and viceversa and presto, the cross-chip link works. When there is anotherswitch in the middle, such as in this case switch 1 with its DSA linkssw1p3 and sw1p4, somebody needs to tell it about these VLANs too.Which is exactly why the problem is quadratic: when a port joins abridge, for each port in the tree that's already in that same bridge wenotify a tag_8021q VLAN addition of that port's RX VLAN to the entiretree. It is a very complicated web of VLANs.It must be mentioned that currently we install tag_8021q VLANs on toomany ports (DSA links - to be precise, on all of them). For example,when sw2p0 joins br0, and assuming sw1p0 was part of br0 too, we add theRX VLAN of sw2p0 on the DSA links of switch 0 too, even though thereisn't any port of switch 0 that is a member of br0 (at least yet).In theory we could notify only the switches which sit in between theport joining the bridge and the port reacting to that bridge_join event.But in practice that is impossible, because of the way 'link' propertiesare described in the device tree. The DSA bindings require DT writers tolist out not only the real/physical DSA links, but in fact the entirerouting table, like for example switch 0 above will have: sw0p3: port@3 { link = <&sw1p4 &sw2p4>; };This was done because:/* TODO: ideally DSA ports would have a single dp->link_dp member, * and no dst->rtable nor this struct dsa_link would be needed, * but this would require some more complex tree walking, * so keep it stupid at the moment and list them all. */but it is a perfect example of a situation where too much information isactively detrimential, because we are now in the position where wecannot distinguish a real DSA link from one that is put there to avoidthe 'complex tree walking'. And because DT is ABI, there is not much wecan change.And because we do not know which DSA links are real and which onesaren't, we can't really know if DSA switch A is in the data path betweenswitches B and C, in the general case.So this is why tag_8021q RX VLANs are added on all DSA links, andprobably why it will never change.On the other hand, at least the number of additions/deletions is wellbalanced, and this means that once we implement reference counting atthe cross-chip notifier level a la fdb/mdb, there is absolutely zeroneed for a struct dsa_8021q_crosschip_link, it's all self-managing.In fact, with the tag_8021q notifiers emitted from the bridge joinnotifiers, it becomes so generic that sja1105 does not need to doanything anymore, we can just delete its implementation of the.crosschip_bridge_{join,leave} methods.Among other things we can simply delete is the home-grown implementationof sja1105_notify_crosschip_switches(). The reason why that is wrong isbecause it is not quadratic - it only covers remote switches to which wehave a cross-chip bridging link and that does not cover in-betweenswitches. This deletion is part of the same patch because sja1105 usedto poke deep inside the guts of the tag_8021q context in order to dothat. Because the cross-chip links went away, so needs the sja1105 code.Last but not least, dsa_8021q_setup_port() is simplified (and alsorenamed). Because our TAG_8021Q_VLAN_ADD notifier is designed to reacton the CPU port too, the four dsa_8021q_vid_apply() calls:- 1 for RX VLAN on user port- 1 for the user port's RX VLAN on the CPU port- 1 for TX VLAN on user port- 1 for the user port's TX VLAN on the CPU portnow get squashed into only 2 notifier calls viadsa_port_tag_8021q_vlan_add.And because the notifiers to add and to delete a tag_8021q VLAN aredistinct, now we finally break up the port setup and teardown intoseparate functions instead of relying on a "bool enabled" flag whichtells us what to do. Arguably it should have been this way from theget go.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

328621f6 - net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}register

Mon, 19 Jul 2021 17:14:50 +0000

net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}registerRight now, setting up tag_8021q is a 2-step operation for a driver,first the context structure needs to be created, then the VLANs need tobe installed on the ports. A similar thing is true for teardown.Merge the 2 steps into the register/unregister methods, to be astransparent as possible for the driver as to what tag_8021q does behindthe scenes. This also gets rid of the funny "bool setup == true meanssetup, == false means teardown" API that tag_8021q used to expose.Note that dsa_tag_8021q_register() must be called at least in the.setup() driver method and never earlier (like in the driver probefunction). This is because the DSA switch tree is not initialized atprobe time, and the cross-chip notifiers will not work.For symmetry with .setup(), the unregister method should be put in.teardown().Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

5da11eb4 - net: dsa: make tag_8021q operations part of the core

Mon, 19 Jul 2021 17:14:49 +0000

net: dsa: make tag_8021q operations part of the coreMake tag_8021q a more central element of DSA and move the 2 driverspecific operations outside of struct dsa_8021q_context (which issupposed to hold dynamic data and not really constant functionpointers).Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

d7b1fd52 - net: dsa: let the core manage the tag_8021q context

Mon, 19 Jul 2021 17:14:48 +0000

net: dsa: let the core manage the tag_8021q contextThe basic problem description is as follows:Be there 3 switches in a daisy chain topology: | sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ]The CPU will not be able to ping through the user ports of thebottom-most switch (like for example sw2p0), simply because tag_8021qwas not coded up for this scenario - it has always assumed DSA switchtrees with a single switch.To add support for the topology above, we must admit that the RX VLAN ofsw2p0 must be added on some ports of switches 0 and 1 as well. This isin fact a textbook example of thing that can use the cross-chip notifierframework that DSA has set up in switch.c.There is only one problem: core DSA (switch.c) is not able right now tomake the connection between a struct dsa_switch *ds and a structdsa_8021q_context *ctx. Right now, it is drivers who call intotag_8021q.c and always provide a struct dsa_8021q_context *ctx pointer,and tag_8021q.c calls them back with the .tag_8021q_vlan_{add,del}methods.But with cross-chip notifiers, it is possible for tag_8021q to calldrivers without drivers having ever asked for anything. A good exampleis right above: when sw2p0 wants to set itself up for tag_8021q,the .tag_8021q_vlan_add method needs to be called for switches 1 and 0,so that they transport sw2p0's VLANs towards the CPU without droppingthem.So instead of letting drivers manage the tag_8021q context, add atag_8021q_ctx pointer inside of struct dsa_switch, which will bepopulated when dsa_tag_8021q_register() returns success.The patch is fairly long-winded because we are partly reverting commit5899ee367ab3 ("net: dsa: tag_8021q: add a context structure") which madethe driver-facing tag_8021q API use "ctx" instead of "ds". Now that wecan access "ctx" directly from "ds", this is no longer needed.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

cedf4670 - net: dsa: tag_8021q: create dsa_tag_8021q_{register,unregister} helpers

Mon, 19 Jul 2021 17:14:46 +0000

net: dsa: tag_8021q: create dsa_tag_8021q_{register,unregister} helpersIn preparation of moving tag_8021q to core DSA, move all initializationand teardown related to tag_8021q which is currently done by drivers in2 functions called "register" and "unregister". These will gather morefunctionality in future patches, which will better justify the chosennaming scheme.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

8afbea18 - net: dsa: tag_8021q: remove struct packet_type declaration

Mon, 19 Jul 2021 17:14:45 +0000

net: dsa: tag_8021q: remove struct packet_type declarationThis is no longer necessary since tag_8021q doesn't register itself as afull-blown tagger anymore.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

0fac6aa0 - net: dsa: sja1105: delete the best_effort_vlan_filtering mode

Mon, 19 Jul 2021 17:14:42 +0000

net: dsa: sja1105: delete the best_effort_vlan_filtering modeSimply put, the best-effort VLAN filtering mode relied on VLAN retaggingfrom a bridge VLAN towards a tag_8021q sub-VLAN in order to be able todecode the source port in the tagger, but the VLAN retaggingimplementation inside the sja1105 chips is not the best and we wererelying on marginal operating conditions.The most notable limitation of the best-effort VLAN filtering mode isits incapacity to treat this case properly:ip link add br0 type bridge vlan_filtering 1ip link set swp2 master br0ip link set swp4 master br0bridge vlan del dev swp4 vid 1bridge vlan add dev swp4 vid 1 pvidWhen sending an untagged packet through swp2, the expectation is for itto be forwarded to swp4 as egress-tagged (so it will contain VLAN ID 1on egress). But the switch will send it as egress-untagged.There was an attempt to fix this here:https://patchwork.kernel.org/project/netdevbpf/patch/20210407201452.1703261-2-olteanv@gmail.com/but it failed miserably because it broke PTP RX timestamping, in a waythat cannot be corrected due to hardware issues related to VLANretagging.So with either PTP broken or pushing VLAN headers on egress for untaggedpackets being broken, the sad reality is that the best-effort VLANfiltering code is broken. Delete it.Note that this means there will be a temporary loss of functionality inthis driver until it is replaced with something better (network stackRX/TX capability for "mode 2" as described inDocumentation/networking/dsa/sja1105.rst, the "port under VLAN-awarebridge" case). We simply cannot keep this code until that driver reworkis done, it is super bloated and tangled with tag_8021q.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

233697b3 - net: dsa: tag_8021q: refactor RX VLAN parsing into a dedicated function

Fri, 11 Jun 2021 19:01:27 +0000

net: dsa: tag_8021q: refactor RX VLAN parsing into a dedicated functionThe added value of this function is that it can deal with both the casewhere the VLAN header is in the skb head, as well as in the offload field.This is something I was not able to do using other functions in thenetwork stack.Since both ocelot-8021q and sja1105 need to do the same stuff, let'smake it a common service provided by tag_8021q.This is done as refactoring for the new SJA1110 tagger, which partlyuses tag_8021q as well (just like SJA1105), and will be the third caller.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h

ab6a303c - net: dsa: tag_8021q: remove shim declarations

Fri, 11 Jun 2021 19:01:26 +0000

net: dsa: tag_8021q: remove shim declarationsAll users of tag_8021q select it in Kconfig, so shim functions are notneeded because it is not possible for it to be disabled and its callersenabled.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/include/linux/dsa/8021q.h