summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-10-27ibmvnic: Update reset infrastructure to support tunable parametersJohn Allen2-28/+209
Update ibmvnic reset infrastructure to include a new reset option that will allow changing of tunable parameters. There currently is no way to request different capabilities from the vnic server on the fly so this patch achieves this by resetting the driver and attempting to log in with the requested changes. If the reset operation fails, the old values of the tunable parameters are stored in the "fallback" struct and we attempt to login with the fallback values. Signed-off-by: John Allen <jallen@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27Merge branch 'qualcomm-rmnet-Add-64-bit-stats-and-GRO'David S. Miller6-32/+114
Subash Abhinov Kasiviswanathan says: ==================== net: qualcomm: rmnet: Add 64 bit stats and GRO This series adds support for 64 bit per cpu stats and GRO Patches 1-2 are cleanups of return code and a redundant condition Patch 3 adds support for 64 bit per cpu stats Patch 4 adds support for GRO using GRO cells v1->v2: Since gro_cells_init() could potentially fail, move it from device setup to ndo_init() as mentioned by Eric. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: qualcomm: rmnet: Add support for GROSubash Abhinov Kasiviswanathan4-1/+14
Add gro_cells so that rmnet devices can call gro_cells_receive instead of netif_receive_skb. Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: qualcomm: rmnet: Add support for 64 bit statsSubash Abhinov Kasiviswanathan2-5/+85
Implement 64 bit per cpu stats. Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: qualcomm: rmnet: Always assign rmnet dev in deaggregation pathSubash Abhinov Kasiviswanathan1-2/+1
The rmnet device needs to assigned for all packets in the deaggregation path based on the mux id, so the check is not needed. Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: qualcomm: rmnet: Fix the return value of rmnet_rx_handler()Subash Abhinov Kasiviswanathan3-24/+14
Since packet is always consumed by rmnet_rx_handler(), we always return RX_HANDLER_CONSUMED. There is no need to pass on this value through multiple functions. Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27Merge branch '40GbE' of ↵David S. Miller5-21/+22
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2017-10-26 This series contains fixes to e1000, igb, ixgbe and i40e. Vincenzo Maffione fixes a potential race condition which would result in the interface being up but transmits are disabled in the hardware. Colin Ian King fixes a possible NULL pointer dereference in e1000, which was found by Coverity. Jean-Philippe Brucker fixes a possible kernel panic when a driver cannot map a transmit buffer, which is caused by an erroneous test. Alex provides a fix for ixgbe, which is a partial revert of the commit ffed21bcee7a ("ixgbe: Don't bother clearing buffer memory for descriptor rings") because the previous commit messed up the exception handling path by adding the count back in when we did not need to. Also fixed a typo, where the transmit ITR setting was being used to determine if we were using adaptive receive interrupt moderation or not. Lastly, fixed a memory leak by including programming descriptors in the cleaned count. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27MAINAINTERS: Add Doug as GENET maintainerFlorian Fainelli1-0/+1
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27Merge branch 'bnxt_en-next'David S. Miller9-228/+1558
Michael Chan says: ==================== bnxt_en: Updates for net-next. This series includes firmware interface update, some optimizations, some new PCI IDs, new MTU checks, ethtool reset method, interrupt coalescing code cleanup, and TC flower offload for vxlan encap/decap from Sathya Perla. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: alloc tc_info{} struct only when tc flower is enabledSathya Perla5-22/+34
TC flower is not enabled on VFs and when there's no FW support. Alloc the tc_info{} struct at init time only when TC flower is being enabled. Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: query cfa flow stats periodically to compute 'lastused' attributeSathya Perla4-85/+218
This patch implements periodic querying of cfa flow stats in batches to compute the 'lastused' attribute of TC flow stats. Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: add hwrm FW cmds for cfa_encap_record and decap_filterSathya Perla1-4/+125
Add routines for issuing the hwrm_cfa_encap_record_alloc/free and hwrm_cfa_decap_filter_alloc/free FW cmds needed for supporting vxlan encap/decap offload. Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: add support for Flower based vxlan encap/decap offloadSathya Perla4-12/+631
This patch adds IPv4 vxlan encap/decap action support to TC-flower offload. For vxlan encap, the driver maintains a tunnel encap hash-table. When a new flow with a tunnel encap action arrives, this table is looked up; if an encap entry exists, it uses the already programmed encap_record_handle as the tunnel_handle in the hwrm_cfa_flow_alloc cmd. Else, a new encap node is added and the L2 header fields are queried via a route lookup. hwrm_cfa_encap_record_alloc cmd is used to create a new encap record and the encap_record_handle is used as the tunnel_handle while adding the flow. For vxlan decap, the driver maintains a tunnel decap hash-table. When a new flow with a tunnel decap action arrives, this table is looked up; if a decap entry exists, it uses the already programmed decap_filter_handle as the tunnel_handle in the hwrm_cfa_flow_alloc cmd. Else, a new decap node is added and a decap_filter_handle is alloc'd via the hwrm_cfa_decap_filter_alloc cmd. This handle is used as the tunnel_handle while adding the flow. The code to issue the HWRM FW cmds is introduced in a follow-up patch. Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Refactor and simplify coalescing code.Michael Chan1-46/+35
The mapping of the ethtool coalescing parameters to hardware parameters is now done in bnxt_hwrm_set_coal_params(). The same function can handle both RX and TX settings. The code is now more clear. Some adjustments have been made to get better hardware settings. The coal_frames setting is now accurately set in hardware. The max_timer is set to coal_ticks value. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Reorganize the coalescing parameters.Michael Chan3-52/+79
The current IRQ coalescing logic is a little messy. The ethtool parameters are mapped to hardware parameters in a way that is difficult to understand. The first step is to better organize the parameters by adding the new structure bnxt_coal. The structure is used by both the RX and TX sets of coalescing parameters. Adjust the default coal_ticks to 14 us and 28 us for RX and TX. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Add ethtool reset methodVasundhara Volam2-1/+38
This is a firmware internal reset after driver is unloaded. Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Check maximum supported MTU from firmware.Michael Chan2-6/+12
Some NICs have a firmware enforced maximum MTU setting by management firmware. Set up netdev->max_mtu accordingly. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Optimize .ndo_set_mac_address() for VFs.Michael Chan1-3/+3
No need to call bnxt_approve_mac() which will send a message to the PF if the MAC address hasn't changed. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Get firmware package version one time.Michael Chan2-16/+18
The current code retrieves the firmware package version from firmware everytime ethtool -i is run. There is no reason to do that as the firmware will not change while the driver is loaded. Get the version once at init time. Also, display the full 4-part firmware version string and remove the less useful interface spec version. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Check for zero length value in bnxt_get_nvram_item().Michael Chan1-0/+3
Return -EINVAL if the length is zero and not proceed to do essentially nothing. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: adding PCI ID for SMARTNIC VF supportRob Miller1-1/+5
Signed-off-by: Rob Miller <rmiller@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Add PCIe device ID for bcm58804Ray Jui2-0/+5
Add new PCIe device ID and chip number for bcm58804 Signed-off-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27bnxt_en: Update firmware interface to 1.8.3.1Michael Chan1-24/+396
Vxlan encap/decap filters are added to this firmware spec. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27Merge branch 'dsa-define-port-types'David S. Miller11-46/+62
Vivien Didelot says: ==================== net: dsa: define port types The DSA code currently has 3 bitmaps in the dsa_switch structure: cpu_port_mask, dsa_port_mask and enabled_port_mask. They are used to store the type of each switch port. This dates back from when DSA didn't have a dsa_port structure to hold port-specific data. The dsa_switch structure is mainly used to communicate with DSA drivers and must not contain such static data parsed from DTS or pdata, which belongs the DSA core structures, such as dsa_switch_tree and dsa_port. Also the enabled_port_mask is misleading, often misinterpreted as the complement of disabled ports (thus including DSA and CPU ports), while in fact it only masks the user ports. A port can be of 3 types when it is not unused: "cpu" (interfacing with a master device), "dsa" (interconnecting with another "dsa" port from another switch chip), or "user" (user-facing port.) This patchset first fixes the usage of DSA port type helpers, then defines the DSA_PORT_TYPE_UNUSED, DSA_PORT_TYPE_CPU, DSA_PORT_TYPE_DSA, and DSA_PORT_TYPE_USER port types, and finally removes the misleading port bitmaps. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: remove port masksVivien Didelot3-17/+0
Now that DSA core provides port types, there is no need to keep this information at the switch level. This is a static information that is part of a DSA core dsa_port structure. Remove them. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: use new port type in helpersVivien Didelot1-11/+16
Now that DSA exposes an enumerated type for the ports, we can use them directly instead of checking bitmaps, which is more consistent. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: define port typesVivien Didelot3-0/+16
Introduce an enumerated type for ports, which will be way more explicit to identify a port type instead of digging into switch port masks. A port can be of type CPU, DSA, user, or unused by default. This is a static parsed information that cannot be changed at runtime. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: introduce dsa_user_ports helperVivien Didelot6-8/+11
Introduce a dsa_user_ports() helper to return the ds->enabled_port_mask mask which is more explicit. This will also minimize diffs when touching this internal mask. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: use dsa_is_user_port everywhereVivien Didelot6-13/+12
Most of the DSA code still check ds->enabled_port_mask directly to inspect a given port type instead of using the provided dsa_is_user_port helper. Change this. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: rename dsa_is_normal_port helperVivien Didelot2-2/+2
This patch renames dsa_is_normal_port to dsa_is_user_port because "user" is the correct term in the DSA terminology, not "normal". Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: fix dsa_is_normal_port helperVivien Didelot1-1/+1
In order to know if a port is of type user, dsa_is_normal_port checks that the given port is not of type DSA nor CPU. This is not enough because a port can be unused. Without the previous fix, this caused the unused mv88e6xxx ports to be configured in normal mode. The ds->enabled_port_mask reports the user ports, so check this instead. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: mv88e6xxx: skip unused portsVivien Didelot1-0/+3
The unused ports are currently configured in normal mode. This does not prevent the switch from being functional, but it is unnecessary. Skip unused ports. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: add dsa_is_unused_port helperVivien Didelot2-1/+8
As the comment above the chunk states, the b53 driver attempts to disable the unused ports. But using ds->enabled_port_mask is misleading, because this mask reports in fact the user ports. To avoid confusion and fix this, this patch introduces an explicit dsa_is_unused_port helper which ensures the corresponding bit is not masked in any of the switch port masks. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: faraday: ftmac100: Use BUG_ON instead of if condition followed by BUG.Gustavo A. R. Silva1-2/+3
Notice that in this particular case unlikely() is already being called inside BUG_ON macro. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: bcmgenet: Use BUG_ON instead of if condition followed by BUGGustavo A. R. Silva1-2/+1
Use BUG_ON instead of if condition followed by BUG. Something to notice in this particular case is that unlikely() is already being called inside BUG_ON macro. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27Merge branch 'cxgb4-collect-more-hardware-dumps-via-ethtool'David S. Miller11-1/+1168
Rahul Lakkireddy says: ==================== cxgb4: collect more hardware dumps via ethtool This series of patches collect more firmware and hardware dumps via ethool --get-dump facility. Patch 1 collects hardware logic analyzer dumps. Patch 2 collects CIM queue configuration dump. Patch 3 collects RSS dumps. Patch 4 collects TID info dump. Patch 5 collects MPS-TCAM dump. Patch 6 collects PBT tables dump. Patch 7 collects hardware scheduler and pace table dumps. Patch 8 collects miscellaneous hardware information, including path mtu, PM stats, TP clock info, congestion control, and VPD data dumps. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect hardware misc dumpsRahul Lakkireddy5-0/+211
Collect path mtu, PM stats, TP clock info, congestion control, and VPD data dumps. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect hardware scheduler dumpsRahul Lakkireddy9-0/+119
Collect hardware TX traffic scheduler and pace tables. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect PBT tables dumpRahul Lakkireddy5-0/+91
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect MPS-TCAM dumpRahul Lakkireddy6-0/+230
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect TID info dumpRahul Lakkireddy8-1/+143
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect RSS dumpsRahul Lakkireddy5-0/+68
Collect RSS table and RSS VF configuration dumps. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect CIM queue configuration dumpRahul Lakkireddy5-0/+56
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27cxgb4: collect hardware LA dumpsRahul Lakkireddy6-0/+250
Collect CIM, CIM_MA, ULP_RX, TP, CIM_PIF, and ULP_TX logic analyzer dumps. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27ip6_gre: update dst pmtu if dev mtu has been updated by toobig in __gre6_xmitXin Long1-2/+7
When receiving a Toobig icmpv6 packet, ip6gre_err would just set tunnel dev's mtu, that's not enough. For skb_dst(skb)'s pmtu may still be using the old value, it has no chance to be updated with tunnel dev's mtu. Jianlin found this issue by reducing route's mtu while running netperf, the performance went to 0. ip6ip6 and ip4ip6 tunnel can work well with this, as they lookup the upper dst and update_pmtu it's pmtu or icmpv6_send a Toobig to upper socket after setting tunnel dev's mtu. We couldn't do that for ip6_gre, as gre's inner packet could be any protocol, it's difficult to handle them (like lookup upper dst) in a good way. So this patch is to fix it by updating skb_dst(skb)'s pmtu when dev->mtu < skb_dst(skb)'s pmtu in tx path. It's safe to do this update there, as usually dev->mtu <= skb_dst(skb)'s pmtu and no performance regression can be caused by this. Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_errXin Long1-4/+7
The similar fix in patch 'ipip: only increase err_count for some certain type icmp in ipip_err' is needed for ip6gre_err. In Jianlin's case, udp netperf broke even when receiving a TooBig icmpv6 packet. Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27ipip: only increase err_count for some certain type icmp in ipip_errXin Long1-17/+42
t->err_count is used to count the link failure on tunnel and an err will be reported to user socket in tx path if t->err_count is not 0. udp socket could even return EHOSTUNREACH to users. Since commit fd58156e456d ("IPIP: Use ip-tunneling code.") removed the 'switch check' for icmp type in ipip_err(), err_count would be increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link failure would be reported out due to this. In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet, udp netperf failed with the err: send_data: data send error: No route to host (errno 113) We expect this error reported from tunnel to socket when receiving some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED or ICMP_PARAMETERPROB ones. This patch is to bring 'switch check' for icmp type back to ipip_err so that it only reports link failure for the right type icmp, just as in ipgre_err() and ipip6_err(). Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.") Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: stmmac: First Queue must always be in DCB modeJose Abreu1-0/+7
According to DWMAC databook the first queue operating mode must always be in DCB. As MTL_QUEUE_DCB = 1, we need to always set the first queue operating mode to DCB otherwise driver will think that queue is in AVB mode (because MTL_QUEUE_AVB = 0). Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27Merge branch 'dsa-lan9303-Learn-addresses-on-CPU-port-when-bridged'David S. Miller4-34/+60
Egil Hjelmeland says: ==================== net: dsa: lan9303: Learn addresses on CPU port when bridged When CPU transmit directly to port using tag, the LAN9303 does not learn MAC addresses received on the CPU port into the ALR table. ALR learning is performed only when transmitting using ALR lookup. Solution: If the two external ports are bridged and the packet is not STP BPDU, then use ALR lookup to allow ALR learning on CPU port. Otherwise transmit directly to port with STP state override. The first patch moves struct lan9303 to include/linux/dsa/lan9303.h in order to prepare for the second patch. Changes v1 -> v2: - new file: include/linux/dsa/lan9303.h instead of include/linux/lan9303.h - include linux/if_ether.h in include/linux/dsa/lan9303.h - renamed lan9303_tx_use_arl to lan9303_xmit_use_arl for consistency. - removed inline keyword to lan9303_xmit_use_arl ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-27net: dsa: lan9303: Learn addresses on CPU port when bridgedEgil Hjelmeland1-1/+22
When CPU transmit directly to port using tag, the LAN9303 does not learn MAC addresses received on the CPU port into the ALR. ALR learning is performed only when transmitting using ALR lookup. Solution: If the two external ports are bridged and the packet is not STP BPDU, then use ALR lookup to allow ALR learning on CPU port. Otherwise transmit directly to port with STP state override. Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>