- 16 Oct, 2018 38 commits
-
-
Michael Chan authored
New firmware spec. allows interrupt coalescing parameters, such as maximums, timer units, supported features to be queried. Update the driver to make use of the new call to query these parameters and provide the legacy defaults if the call is not available. Replace the hard-coded values with these parameters. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Support the max_ext_req_len field from the HWRM_VER_GET_RESPONSE. If this field is valid and greater than the mailbox size, use the short command format to send firmware messages greater than the mailbox size. Newer devices use this method to send larger messages to the firmware. Signed-off-by:
-
Michael Chan authored
Latest firmware spec. has some additional rx extended port stats and new tx extended port stats added. We now need to check the size of the returned rx and tx extended stats and determine how many counters are valid. New counters added include CoS byte and packet counts for rx and tx. Signed-off-by:
-
Michael Chan authored
Among the new changes are trusted VF support, 200Gbps support, and new API to dump ring information on the new chips. Signed-off-by:
-
David S. Miller authored
Stefano Brivio says: ==================== selftests: pmtu: Add test choice and captures This series adds a couple of features useful for debugging: 1/2 allows selecting single tests and 2/2 adds optional traffic captures. Semantics for current invocation of test script are preserved. ==================== Signed-off-by: -
Stefano Brivio authored
If --trace is passed as an option and tcpdump is available, capture traffic for all relevant interfaces to per-test pcap files named <test>_<interface>.pcap. Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
-
Stefano Brivio authored
As number of tests is growing, it's quite convenient to allow single tests to be run. Display usage when the script is run with any invalid argument, keep existing semantics when no arguments are passed so that automated runs won't break. Instead of just looping on the list of requested tests, if any, check first that they exist, and go through them in a nested loop to keep the existing way to display test descriptions. Signed-off-by:
-
Heiner Kallweit authored
netif_device_detach() stops all tx queues already, so we don't need this call. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Simplify this function, no functional change intended. Signed-off-by:
-
Arnd Bergmann authored
The newly added driver causes a warning about a function that is not used anywhere: drivers/net/ethernet/marvell/octeontx2/af/cgx.c:320:12: error: 'cgx_fwi_link_change' defined but not used [-Werror=unused-function] Remove it for now, until a user gets added. If we want to use this function from another module, we also need a declaration in a header file, which is currently missing, so it would have to change anyway. Fixes: 1463f382 ("octeontx2-af: Add support for CGX link management") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ryan C Goodfellow authored
This commit makes it possible to use devlink to split the 100G CXP Netronome into two 40G interfaces. Currently when you ask for 2 interfaces, the math in src/nfp_devlink.c:nfp_devlink_port_split calculates that you want 5 lanes per port because for some reason eth_port.port_lanes=10 (shouldn't this be 12 for CXP?). What we really want when asking for 2 breakout interfaces is 4 lanes per port. This commit makes that happen by calculating based on 8 lanes if 10 are present. Signed-off-by:
Ryan C Goodfellow <rgoodfel@isi.edu> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Greg Weeks <greg.weeks@netronome.com> Signed-off-by:
-
David S. Miller authored
Ioana Ciornei says: ==================== dpaa2-eth: code cleanup There are no functional changes in this patch set, only some cleanup changes such as: unused parameters, uninitialized variables and unnecessary Kconfig dependencies. ==================== Signed-off-by: -
Ioana Radulescu authored
According to the hardware ArchDef, the PTV1 field in FD[CTRL] is ignored by WRIOP, so setting it for Tx FDs is pointless. Remove all references to it from the code. Signed-off-by:
Ioana Radulescu <ruxandra.radulescu@nxp.com> Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Ioana Ciornei authored
The ch parameter is never used in the dpaa2_eth_tx_conf function but since its prototype must match the type defined in the consume field of struct dpaa2_eth_fq, just mark it as __always_unused. Signed-off-by:
-
Ioana Ciornei authored
The priv parameter is never used in the build_linear_skb and drain_channel function. Remove it from the function definitions. Signed-off-by:
-
Ioana Ciornei authored
All 3 cases of possible uninitialized variables are false positives since they are used only as output parameters. Nonetheless, fix the warnings. Signed-off-by:
-
Ioana Ciornei authored
The dpaa2_eth_set_dist_key function is only used in a single file. Make it static. Signed-off-by:
-
Ioana Radulescu authored
Both ARCH_LAYERSCAPE and COMPILE_TEST dependencies are already implied through the FSL_MC_BUS dep, so there's no need to state it explicitly. Also, the fsl-mc bus depends on COMPILE_TEST only for some architectures (arm, arm64, ppc, x86), so it's not correct to claim build support unconditionally. Signed-off-by:
-
Ivan Khoronzhuk authored
In dual-emac mode the cpsw driver sends directed packets, that means that packets go to the directed port, but an ALE lookup is performed to determine untagged egress only. It means that on tx side no need to add port bit for ALE mcast entry mask, and basically ALE entry for port identification is needed only on rx side. So, add only host port in dual_emac mode as used directed transmission, and no need in one more port. For single port boards and switch mode all ports used, as usual, so no changes for them. Also it simplifies farther changes. In other words, mcast entries for dual-emac should behave exactly like unicast. It also can help avoid leaking packets between ports with same vlan on h/w level if ports could became members of same vid. So now, for instance, if mcast address 33:33:00:00:00:01 is added then entries in ALE table: vid = 1, addr = 33:33:00:00:00:01, port_mask = 0x1 vid = 2, addr = 33:33:00:00:00:01, port_mask = 0x1 Instead of: vid = 1, addr = 33:33:00:00:00:01, port_mask = 0x3 vid = 2, addr = 33:33:00:00:00:01, port_mask = 0x5 With the same considerations, set only host port for unregistered mcast for dual-emac mode in case of IFF_ALLMULTI is set, exactly like it's done in cpsw_ale_set_allmulti(). Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
David S. Miller authored
Ivan Khoronzhuk says: ==================== net: ethernet: ti: cpsw fix mcast packet lost The patchset omits redundant refresh of mcast address table and prevents mcast packet lost. Based on net-next/master tested on am572x evm ==================== Signed-off-by: -
Ivan Khoronzhuk authored
Whenever kernel or user decides to call rx mode update, it clears every multicast entry from forwarding table and in some time adds it again. This time can be enough to drop incoming multicast packets. That's why clear only staled multicast entries and update or add new one afterwards. Signed-off-by:
-
Ivan Khoronzhuk authored
It allows to use function under callbacks with same const qualifier of mac address for farther changes. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: improve and simplify state machine Improve / simplify handling of states PHY_RUNNING and PHY_RESUMING in phylib state machine. ==================== Signed-off-by: -
Heiner Kallweit authored
Simplify code for handling state PHY_RESUMING, no functional change intended. Signed-off-by:
-
Heiner Kallweit authored
Handling of state PHY_RUNNING seems to be more complex than it needs to be. If not polling, then we don't have to do anything, we'll receive an interrupt and go to state PHY_CHANGELINK once the link goes down. If polling and link is down, we don't have to go the extra mile over PHY_CHANGELINK and call phy_read_status() again but can set status PHY_NOLINK directly. Signed-off-by:
-
Roopa Prabhu authored
This makes use of NTF_USE in vxlan driver consistent with bridge driver. Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Acked-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Justin.Lee1@Dell.com authored
The new command (NCSI_CMD_SEND_CMD) is added to allow user space application to send NC-SI command to the network card. Also, add a new attribute (NCSI_ATTR_DATA) for transferring request and response. The work flow is as below. Request: User space application -> Netlink interface (msg) -> new Netlink handler - ncsi_send_cmd_nl() -> ncsi_xmit_cmd() Response: Response received - ncsi_rcv_rsp() -> internal response handler - ncsi_rsp_handler_xxx() -> ncsi_rsp_handler_netlink() -> ncsi_send_netlink_rsp () -> Netlink interface (msg) -> user space application Command timeout - ncsi_request_timeout() -> ncsi_send_netlink_timeout () -> Netlink interface (msg with zero data length) -> user space application Error: Error detected -> ncsi_send_netlink_err () -> Netlink interface (err msg) -> user space application Signed-off-by:
Justin Lee <justin.lee1@dell.com> Reviewed-by:
Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by:
-
Heiner Kallweit authored
When starting the state machine there may be work to be done immediately, e.g. if the initial state is PHY_UP then the state machine may trigger an autonegotiation. Having said that I see no need to wait a second until the state machine is run first time. Signed-off-by:
-
David S. Miller authored
Toshiaki Makita says: ==================== veth: XDP stats improvement ndo_xdp_xmit in veth did not update packet counters as described in [1]. Also, current implementation only updates counters on tx side so rx side events like XDP_DROP were not collected. This series implements the missing accounting as well as support for ethtool per-queue stats in veth. Patch 1: Update drop counter in ndo_xdp_xmit. Patch 2: Update packet and byte counters for all XDP path, and drop counter on XDP_DROP. Patch 3: Support per-queue ethtool stats for XDP counters. Note that counters are maintained on per-queue basis for XDP but not otherwise (per-cpu and atomic as before). This is because 1) tx path in veth is essentially lockless so we cannot update per-queue stats on tx, and 2) rx path is net core routine (process_backlog) which cannot update per-queue based stats when XDP is disabled. On the other hand there are real rxqs and napi handlers for veth XDP, so update per-queue stats on rx for XDP packets, and use them to calculate tx counters as well, contrary to the existing non-XDP counters. [1] https://patchwork.ozlabs.org/cover/953071/#1967449 ==================== Signed-off-by:Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by:
-
Toshiaki Makita authored
Expose per-queue stats for ethtool -S. As there are only rx queues, and rx queues are used only when XDP is used, per-queue counters are only rx XDP ones. Example: $ ethtool -S veth0 NIC statistics: peer_ifindex: 11 rx_queue_0_xdp_packets: 28601434 rx_queue_0_xdp_bytes: 1716086040 rx_queue_0_xdp_drops: 28601434 rx_queue_1_xdp_packets: 17873050 rx_queue_1_xdp_bytes: 1072383000 rx_queue_1_xdp_drops: 17873050 Signed-off-by: -
Toshiaki Makita authored
On XDP path veth has napi handler so we can collect statistics on per-queue basis for XDP. By this change now we can collect XDP_DROP drop count as well as packets and bytes coming through ndo_xdp_xmit. Packet counters shown by "ip -s link", sysfs stats or /proc/net/dev is now correct for XDP. Signed-off-by:
-
Toshiaki Makita authored
Use existing atomic drop counter. Since drop path is really an exceptional case here, I'm thinking atomic ops would not hurt the performance. XDP packets and bytes are not counted in ndo_xdp_xmit, but will be accounted on rx side by the following commit. Signed-off-by:
-
Hoang Le authored
INADDR_ANY is hard-coded when activating UDP bearer. So, we could not bind to a specific IP address even with replicast mode using - given remote ip address instead of using multicast ip address. In this commit, we fixed it by checking and switch to use appropriate local ip address. before: $netstat -plu Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address udp 0 0 **0.0.0.0:6118** 0.0.0.0:* after: $netstat -plu Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address udp 0 0 **10.0.0.2:6118** 0.0.0.0:* Acked-by:
Ying Xue <ying.xue@windriver.com> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5e-updates-2018-10-10 IPoIB netlink support and mlx5e pre-allocated netdevice initialization IP link was broken due to the changes in IPoIB for the rdma_netdev support after commit cd565b4b ("IB/IPoIB: Support acceleration options callbacks"). This patchset fixes IPoIB pkey creation and removal using rtnetlink by adding support in both IPoIB ULP layer and mlx5 layer: From Jason and Denis: 1) Introduces changes in the RDMA netdev code in order to allow allocation of the netdev to be done by the rtnl netdev code. 2) Reworks IPoIB initialization to use the two step rdma_netdev creation. From Feras and Saeed, mlx5e netdev layer refactoring to allow accepting pre-allocated netdevs: 3) Adds support to initialize/cleanup netdevs that are not created by mlx5 driver. 4) Change mlx5e netdevice layer to accept the pre-allocated netdevice queue number. 5) Initialize mlx5e generic structures in one place to be used for all netdevs types NIC/representors/IPoIB (both mlx5 allocated and pre-allocted). ==================== Signed-off-by:
-
David S. Miller authored
Maciej W. Rozycki says: ==================== FDDI: DEC FDDIcontroller 700 TURBOchannel adapter support This is an update to <http://patchwork.ozlabs.org/patch/342737/>. I believe I have addressed all the requests made in the previous review round. There is still one `checkpatch.pl' warning remaining: WARNING: quoted string split across lines + pr_info("%s: ROM rev. %.4s, firmware rev. %.4s, RMC rev. %.4s, " + "SMT ver. %u\n", fp->name, rom_rev, fw_rev, rmc_rev, smt_ver); total: 0 errors, 1 warnings, 2458 lines checked however I think the value of staying within 80 columns is higher than the value of having the string on a single line. This is because with all the formatting specifiers there it is not directly greppable based on the final output produced to the kernel log on one hand, e.g.: tc2: ROM rev. 1.0, firmware rev. 1.2, RMC rev. A, SMT ver. 1 while it can be easily tracked down by grepping for an obvious substring such as "RMC rev" on the other. The issue with MMIO barriers I discussed in the course of the original review turned out mostly irrelevant to this driver, because as I have learnt in a recent Alpha/Linux discussion starting here: <https://marc.info/?i=alpine.LRH.2.02.1808161556450.13597%20()%20file01%20!%20intranet%20!%20prod%20!%20int%20!%20rdu2%20!%20redhat%20!%20com> our MMIO API mandates the `readX' and `writeX' accessors to be strongly ordered with respect to each other, even if that is not implicitly enforced by hardware. Consequently I have removed all the explicit ordering barriers and instead submitted a fix for MIPS MMIO implementation, which currently does not guarantee strong ordering (the MIPS architecture does not define bus ordering rules except in terms of SYNC barriers), as recorded here: <https://patchwork.linux-mips.org/project/linux-mips/list/?series=1538>. Enforcing strong MMIO ordering can be costly however and is often unnecessary, e.g. when using PIO to access network frame data in onboard packet memory. I have therefore retained the information that would be lost by the removal of barriers, by defining accessor wrappers suffixed by `_o' and `_u', for accesses that have to be ordered and can be unordered respectively. If we ever have an API defined for weakly-ordered MMIO accesses, then these wrappers can be redefined accordingly. Right now they all expand to the respective `_relaxed' accessors, because, again, enforcing the ordering WRT DMA transfers can be costly and we don't need it here except in one place, where I chose to use explicit `dma_rmb' instead. Similarly I have replaced the completion barriers with a read back from the respective MMIO location (all adapter MMIO registers can be read with no side effects incurred), which will serve its purpose on the basis of MMIO being strongly ordered (although a read from TURBOchannel is going to be slower than `iob', making the delay incurred unnecessarily longer). And last but not least, I have split off the SMT Tx network tap support to a separate change, 2/2 in this series, so that it does not block the driver proper and can be discussed separately. I think it has value in that it makes the view of the outgoing network traffic complete, as if one actually physically tapped into the outgoing line of the ring, between the station being examined and its downstream neighbour. Without this part only traffic passed from applications through the whole protocol stack can be captured and this is only a part of the view. With the `dev_queue_xmit_nit' interface now exported it's only `ptype_all' that remains private, and to define a properly abstracted API I propose to provide am exported `dev_nit_active' predicate that tells whether any taps are active. This predicate is then used accordingly. NB if there is a long-term maintenance concern about the `dev_nit_active' predicate, then well, corresponding inline code currently present in `xmit_one' has to be maintained anyway, and if the resulting changes require `defza' to be updated accordingly, then I am going to handle it; after some 20 years with Linux it's not that I am going to disappear anywhere anytime. And once I am dead, which is inevitably going to happen sooner or later, then the driver can simply be ripped from the kernel. Though I suspect that at that point no DECstation Linux users may survive anymore, even though hardware, being as sturdy as it is, likely will. I have a patch for `tcpdump' to actually decode SMT frames, which I plan to upstream sometime. Here's a sample of SMT traffic captured through the `defza' driver in a small network of 4 stations and no concentrators, printed in the most verbose mode: 01:16:59.138381 4f 00:60:b0:58:41:e7 00:60:b0:58:41:e7 73: SMT NIF ann vid:1 tid:00000270 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01 01:17:00.332750 4f 08:00:2b:a3:a3:29 08:00:2b:a3:a3:29 73: SMT NIF ann vid:1 tid:0000013b sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01 01:17:00.354479 4f 00:60:b0:58:40:75 00:60:b0:58:40:75 73: SMT NIF ann vid:1 tid:0000029c sid:00-00-00-60-b0-58-40-75 len:40: UNA: 00 00 10 00 d4 74 b6 ae StationDescr: 00 01 02 00 StationState: 00 00 31 00 MACFrameStatusFunctions.3: 00 00 00 01 01:17:00.442175 4f 00:60:b0:58:41:e7 Broadcast 73: SMT NIF req vid:1 tid:00000271 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01 01:17:00.448657 41 08:00:2b:a3:a3:29 00:60:b0:58:41:e7 73: SMT NIF rsp vid:1 tid:00000271 sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01 01:17:01.015152 4f 08:00:2b:a3:a3:29 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01 01:17:01.111644 41 08:00:2b:2e:6d:75 08:00:2b:a3:a3:29 73: SMT NIF rsp vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01 01:17:04.814603 4f 08:00:2b:2e:6d:75 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01 01:17:04.814939 4f 08:00:2b:2e:6d:75 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01 01:17:04.820960 4f 08:00:2b:2e:6d:75 08:00:2b:2e:6d:75 73: SMT NIF ann vid:1 tid:0000013b sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01 Questions, comments? Otherwise, please apply. ==================== Signed-off-by:
-
Maciej W. Rozycki authored
DEC FDDIcontroller 700 (DEFZA) uses a Tx/Rx queue pair to communicate SMT frames with adapter's firmware. Any SMT frame received from the RMC via the Rx queue is queued back by the driver to the SMT Rx queue for the firmware to process. Similarly the firmware uses the SMT Tx queue to supply the driver with SMT frames which are queued back to the Tx queue for the RMC to send to the ring. When a network tap is attached to an FDDI interface handled by `defza' any incoming SMT frames captured are queued to our usual processing of network data received, which in turn delivers them to any listening taps. However the outgoing SMT frames produced by the firmware bypass our network protocol stack and are therefore not delivered to taps. This in turn means that taps are missing a part of network traffic sent by the adapter, which may make it more difficult to track down network problems or do general traffic analysis. Call `dev_queue_xmit_nit' then in the SMT Tx path, having checked that a network tap is attached, with a newly-created `dev_nit_active' helper wrapping the usual condition used in the transmit path. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
-
Maciej W. Rozycki authored
Add support for the DEC FDDIcontroller 700 (DEFZA), Digital Equipment Corporation's first-generation FDDI network interface adapter, made for TURBOchannel and based on a discrete version of what eventually became Motorola's widely used CAMEL chipset. The CAMEL chipset is present for example in the DEC FDDIcontroller TURBOchannel, EISA and PCI adapters (DEFTA/DEFEA/DEFPA) that we support with the `defxx' driver, however the host bus interface logic and the firmware API are different in the DEFZA and hence a separate driver is required. There isn't much to say about the driver except that it works, but there is one peculiarity to mention. The adapter implements two Tx/Rx queue pairs. Of these one pair is the usual network Tx/Rx queue pair, in this case used by the adapter to exchange frames with the ring, via the RMC (Ring Memory Controller) chip. The Tx queue is handled directly by the RMC chip and resides in onboard packet memory. The Rx queue is maintained via DMA in host memory by adapter's firmware copying received data stored by the RMC in onboard packet memory. The other pair is used to communicate SMT frames with adapter's firmware. Any SMT frame received from the RMC via the Rx queue must be queued back by the driver to the SMT Rx queue for the firmware to process. Similarly the firmware uses the SMT Tx queue to supply the driver with SMT frames that must be queued back to the Tx queue for the RMC to send to the ring. This solution was chosen because the designers ran out of PCB space and could not squeeze in more logic onto the board that would be required to handle this SMT frame traffic without the need to involve the driver, as with the later DEFTA/DEFEA/DEFPA adapters. Finally the driver does some Frame Control byte decoding, so to avoid magic numbers some macros are added to <linux/if_fddi.h>. Signed-off-by:
-
Serhey Popovych authored
Configuring generic network device parameters on tun will fail in presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute since tun_validate() always return failure. This can be visualized with following ip-link(8) command sequences: # ip link set dev tun0 group 100 # ip link set dev tun0 group 100 type tun RTNETLINK answers: Invalid argument with contrast to dummy and veth drivers: # ip link set dev dummy0 group 100 # ip link set dev dummy0 type dummy # ip link set dev veth0 group 100 # ip link set dev veth0 group 100 type veth Fix by returning zero in tun_validate() when @data is NULL that is always in case since rtnl_link_ops->maxtype is zero in tun driver. Fixes: f019a7a5 ("tun: Implement ip link del tunXXX") Signed-off-by:
Serhey Popovych <serhe.popovych@gmail.com> Signed-off-by:
-
- 14 Oct, 2018 2 commits
-
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2018-10-14' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.20 Third set of patches for 4.20. Most notable is finalising ath10k wcn3990 support, all components should be implemented now. Major changes: ath10k * support NET_DETECT WoWLAN feature * wcn3990 basic functionality now working after we got QMI support mt76 * mt76x0e improvements (should be usable now) * more mt76x0/mt76x2 unification work brcmsmac * fix a problem on AP mode with clients using power save mode iwlwifi * support for a new scan type: fast balance ==================== Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.20. Major changes: ath10k * support NET_DETECT WoWLAN feature * wcn3990 basic functionality now working after we got QMI support
-
