- 16 Jan, 2018 1 commit
-
-
Russell Hu authored
On new Intel platforms like ApolloLake, legacy interrupt mechanism (INTx) is not supported, so WLAN modules are not working because interrupts are missing, therefore this patch is to add MSI support to ath9k. With module paremeter "use_msi=1", ath9k driver would try to use MSI instead of INTx. Signed-off-by:
Russell Hu <rhu@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
- 15 Jan, 2018 17 commits
-
-
David S. Miller authored
Merge tag 'linux-can-next-for-4.16-20180105' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2017-12-01,Re: pull-request: can-next this is a pull request of 7 patches for net-next/master. All patches are by me. Patch 6 is for the "can_raw" protocol and add error checking to the bind() function. All other patches clean up the coding style and remove unused parameters in various CAN drivers and infrastructure. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Sergei Shtylyov says: ==================== sh_eth: simplify TSU initialization Here's a set of 2 patches against DaveM's 'net-next.git' repo. With those, I'm somewhat simplifying the TSU init code in the driver probe() method... ==================== Signed-off-by: -
Sergei Shtylyov authored
The dual-port Ether configurations always have a shared TSU to e.g. pass the packets between those ports. With the TSU init. code gathered under the single *if*, we now can only get the port # from 'platform_device::id' only when we actually need it (and not recalculate it each time)... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Sergei Shtylyov authored
The sh_eth_cpu_data::chip_reset() method always resets using ARSTR and this register is always located at the start of the TSU register region. Therefore, we can only call this method if we know TSU is there and thus simplify the probing code a bit... Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2018-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.16 Here are patches which have been accumulating over the holidays and after the New Year. Business as usual and nothing special really standing out. But what's noteworthy here is that Larry Finger is stepping down as the rtlwifi maintainer. He has been maintaining rtlwifi since it was applied back in 2010 in commit 0c817338 ("rtl8192ce: Add new driver") and it has been no easy role trying to juggle between the vendor, demanding upstream community and users. So big thank you to Larry for all his efforts! ath10k * more preparation work for wcn3990 support * add memory dump to firmware coredump files wil6210 * support scheduled scan * support 40-bit DMA addresses qtnfmac * support MAC address based access control * support for radar detection and Channel Availibility Check (CAC) mwifiex * firmware coredump for usb devices rtlwifi * Larry Finger steps down as the maintainer and Ping-Ke Shih becomes the new maintainer * add debugfs interfaces to dump register and btcoex status, and also write registers and h2c ==================== Signed-off-by:
-
Linus Walleij authored
The Gemini ethernet has been around for years as an out-of-tree patch used with the NAS boxen and routers built on StorLink SL3512 and SL3516, later Storm Semiconductor, later Cortina Systems. These ASICs are still being deployed and brand new off-the-shelf systems using it can easily be acquired. The full name of the IP block is "Net Engine and Gigabit Ethernet MAC" commonly just called "GMAC". The hardware block contains a common TCP Offload Enginer (TOE) that can be used by both MACs. The current driver does not use it. Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com> Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
This adds the device tree bindings for the Gemini ethernet controller. It is pretty straight-forward, using standard bindings and modelling the two child ports as child devices under the parent ethernet controller device. Cc: devicetree@vger.kernel.org Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com> Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Ido Schimmel authored
Emil reported the following compiler errors: net/ipv6/route.c: In function `rt6_sync_up`: net/ipv6/route.c:3586: error: unknown field `nh_flags` specified in initializer net/ipv6/route.c:3586: warning: missing braces around initializer net/ipv6/route.c:3586: warning: (near initialization for `arg.<anonymous>`) net/ipv6/route.c: In function `rt6_sync_down_dev`: net/ipv6/route.c:3695: error: unknown field `event` specified in initializer net/ipv6/route.c:3695: warning: missing braces around initializer net/ipv6/route.c:3695: warning: (near initialization for `arg.<anonymous>`) Problem is with the named initializers for the anonymous union members. Fix this by adding curly braces around the initialization. Fixes: 4c981e28 ("ipv6: Prepare to handle multiple netdev events") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reported-by:
Emil S Tantilov <emils.tantilov@gmail.com> Tested-by:
-
Jon Maloy authored
In commit 232d07b7 ("tipc: improve groupcast scope handling") we inadvertently broke non-group multicast transmission when changing the parameter 'domain' to 'scope' in the function tipc_nametbl_lookup_dst_nodes(). We missed to make the corresponding change in the calling function, with the result that the lookup always fails. A closer anaysis reveals that this parameter is not needed at all. Non-group multicast is hard coded to use CLUSTER_SCOPE, and in the current implementation this will be delivered to all matching destinations except those which are published with NODE_SCOPE on other nodes. Since such publications never will be visible on the sending node anyway, it makes no sense to discriminate by scope at all. We now remove this parameter altogether. Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Kirill Tkhai authored
Since net could be obtained from RCU lists, and there is a race with net destruction, the patch converts net::count to refcount_t. This provides sanity checks for the cases of incrementing counter of already dead net, when maybe_get_net() has to used instead of get_net(). Drivers: allyesconfig and allmodconfig are OK. Suggested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Marcelo Ricardo Leitner authored
Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
I see two issues with parameter new_link: 1. It's not needed. See also phy_interrupt(), works w/o this parameter. phy_mac_interrupt sets the state to PHY_CHANGELINK and triggers the state machine which then calls phy_read_status. And phy_read_status updates the link state. 2. phy_mac_interrupt is used in interrupt context and getting the link state may sleep (at least when having to access the PHY registers via MDIO bus). So let's remove it. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
-
Jon Maloy authored
In commit d12d2e12 "tipc: send out join messages as soon as new member is discovered") we added a call to the function tipc_group_join() without considering the case that the preceding tipc_sk_publish() might have failed, and the group item already deleted. We fix this by returning from tipc_sk_join() directly after the failed tipc_sk_publish. Reported-by: syzbot+e3eeae78ea88b8d6d858@syzkaller.appspotmail.com Signed-off-by:
-
David S. Miller authored
Phil Reid says: ==================== net: dsa: lan9303: check error value from devm_gpiod_get_optional() Errors need to be prograted back from probe. Note: I have only compile tested the code as I don't have the hardware. Egil Hjelmeland <privat@egil-hjelmeland.no> has tested it but I haven't added at Test-by: wasn't in the standard form. Not sure if that's ok or not. Changes from v1: - rebased on net-next ==================== Signed-off-by: -
Phil Reid authored
devm_gpiod_get_optional() can return an error in addition to a NULL ptr. Check for error and propagate that to the probe function. Check return value in probe. This will now handle EPROBE_DEFER for the reset gpio. Signed-off-by:
Phil Reid <preid@electromag.com.au> Signed-off-by:
-
Phil Reid authored
lan9303_handle_reset never returns anything other than success. So there's not need for it to return an error code. Signed-off-by:
-
Andrew Lunn authored
__phy_modify would return the old value of the register before it was modified. Thus on success, it does not return 0, but a positive value. Thus functions using phy_modify, which is a wrapper around __phy_modify, can start returning > 0 on success, rather than 0. As a result, breakage has been noticed in various places, where 0 was assumed. Code inspection does not find any current location where the return of the old value is currently used. So have __phy_modify return 0 on success. When there is a real need for the old value, either a new accessor can be added, or an additional parameter passed. Fixes: fea23fb5 ("net: phy: convert read-modify-write to phy_modify()") Fixes: 2b74e5be ("net: phy: add phy_modify() accessor") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Niklas Cassel <niklas.cassel@axis.com> Signed-off-by:
-
- 14 Jan, 2018 12 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 10GbE Intel Wired LAN Driver Updates 2018-01-12 This series contains updates to ixgbe, fm10k and net core. Alex updates the driver to remove a duplicate MAC address check and verifies that we have not run out of resources to configure a MAC rule in our filter table. Also do not assume that dev->num_tc was populated and configured with the driver, since it can be configured via mqprio without any hardware coordination. Fixed the recording of stats for MACVLAN in ixgbe and fm10k instead of recording the receive queue on MACVLAN offloaded frames. When handling a MACVLAN offload, we should be stopping/starting traffic on our own queues instead of the upper devices transmit queues. Fixed possible race conditions with the MACVLAN cleanup with the interface cleanup on shutdown. With the recent fixes to ixgbe, we can cap the number of queues regardless of accel_priv being in use or not, since the actual number of queues are being reported via real_num_tx_queues. Tony fixes up the kernel documentation for ixgbe and ixgbevf to resolve warnings when W=1 is used. ==================== Signed-off-by: -
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Offload PRIO qdisc Nogah says: Add an offload support for PRIO qdisc for mlxsw driver. PRIO qdisc is being offloaded by using ndo_setup_tc. It has three commands, to set or tune the qdisc, to remove it and to get its stats. Like RED offloading, offloading this qdisc is not enforced on the driver and determining its offload state is done in the dump action, when the stats are being updated. In the driver, offloading of PRIO is supported as root qdisc only. It supports only priorities 0-7 (the range that is used by the current static mapping of DSCP to skb prio and by 1:1 PCP values mapping) and up to 8 bands. Patches 1-2 offload DSCP to priority mapping in the mlxsw_sp driver. Patch 3 adds offload support for PRIO qdisc. Patches 4-5 Add PRIO offload support in the mlxsw_sp driver. --- v1->v2: - Patch 1/5: - Rewrite patch msg - Patch 3/5: - Send all the qstats in the replace command (and not just backlog) - Patch 5/5: - Align with the changes from 3/5 - Move backlog to the generic qdisc stats struct - Delete extra newline ==================== Signed-off-by: -
Nogah Frankel authored
Support basic stats for PRIO qdisc, which includes tx packets and bytes count, drops count and backlog size. The rest of the stats are irrelevant for this qdisc offload. Since backlog is not only incremental but reflecting momentary value, in case of a qdisc that stops being offloaded but is not destroyed, backlog value needs to be updated about the un-offloading. For that reason an unoffload function is being added to the ops struct. Signed-off-by:
Nogah Frankel <nogahf@mellanox.com> Reviewed-by:
Yuval Mintz <yuvalm@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Nogah Frankel authored
Add support for offloading PRIO qdisc as root qdisc. The support is for up to 8 bands. Routed packets priority is determined by the DSCP field with the default translations. Bridged packets priority is determined by the PCP field, if exist, otherwise it is set to 0. Since both options have only priorities 0-7, higher priorities mapping are being ignored. Signed-off-by:
-
Nogah Frankel authored
Add the ability to offload PRIO qdisc by using ndo_setup_tc. There are three commands for PRIO offloading: * TC_PRIO_REPLACE: handles set and tune * TC_PRIO_DESTROY: handles qdisc destroy * TC_PRIO_STATS: updates the qdiscs counters (given as reference) Like RED qdisc, the indication of whether PRIO is being offloaded is being set and updated as part of the dump function. It is so because the driver could decide to offload or not based on the qdisc parent, which could change without notifying the qdisc. Signed-off-by:
-
Yuval Mintz authored
When routing ip packets, the kernel is setting the SKB's priority based on the tos field of the packet. Imitate this behavior in the mlxsw router, having the internal switch priority of a routed packet determined according to its DS field. Signed-off-by:
-
Yuval Mintz authored
Add rdpm definition - router DSCP to priority mapping register. This register will be utilized later to align the default mapping between packet DSCP and switch-priority to the kernel's mapping between packet priority and skb priority. This is the first non-bit indexed register where the entries are arranged in descending order, i.e., entry at offset 0 matches configuration for dscp[63]. As a result, the item's step is converted into a signed variable to support descending arrays [where step would be negative]. Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== mv88e6xxx: ATU and VTU interrupts Both the ATU and VTU of Mavell switches can generate interrupts when violations occur. Trap this interrupts and print what violation occurred. ==================== Signed-off-by: -
Andrew Lunn authored
When there is a problem with the VTU, an interrupt can be generated. Trap this interrupt and decode the registers to determine what the problem was, then log the error. Signed-off-by:
-
Andrew Lunn authored
When there is a problem with the ATU, an interrupt can be generated. Trap this interrupt and decode the registers to determine what the problem was, then log the error. Signed-off-by:
-
Ido Schimmel authored
Since commit eb789980 ("mlxsw: spectrum_router: Populate adjacency entries according to weights") the driver includes support for non-equal-cost multipath, but IPv4 nexthops were the only user. Now that the kernel supports weighted IPv6 nexthops, we can extend the driver to support it as well. This is done by assigning each nexthop its configured weight, so that it will be populated accordingly in the device's adjacency table. The `weight` parameter is also taken into account when comparing nexthop groups in order not to consolidate non-identical groups. Signed-off-by:
-
Arnd Bergmann authored
On targets that have different sizes for phys_addr_t and dma_addr_t, we get a type mismatch error: drivers/net/ethernet/socionext/netsec.c: In function 'netsec_alloc_dring': drivers/net/ethernet/socionext/netsec.c:970:9: error: passing argument 3 of 'dma_zalloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] The code is otherwise correct, as the address is never actually used as a physical address but only passed into a DMA register. For consistently, I'm changing the variable name as well, to clarify that this is a DMA address. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
- 12 Jan, 2018 10 commits
-
-
Tony Nguyen authored
Recent checks added for formatting kernel-doc comments are causing warnings if W= is run with a non-zero value. This patch fixes function comments to resolve warnings when W=1 is used. Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Tony Nguyen authored
Recent checks added for formatting kernel-doc comments are causing warnings if W= is run with a non-zero value. This patch fixes function comments to resolve warnings when W=1 is used. Signed-off-by:
-
Alexander Duyck authored
With the recent fix to ixgbe we can cap the number of queues always regardless of if accel_priv is being used or not since the actual number of queues are being reported via real_num_tx_queues. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
-
Alexander Duyck authored
This update makes it so that we report the actual number of Tx queues via real_num_tx_queues but are still restricted to RSS on only the first pool by setting num_tc equal to 1. Doing this locks us into only having the ability to setup XPS on the queues in that pool, and only those queues should be used for transmitting anything other than macvlan traffic. Signed-off-by:
-
Alexander Duyck authored
This change makes it so that instead of bringing rings up/down for various we just update the netdev pointer for the Rx ring and set or clear the MAC filter for the interface. By doing it this way we can avoid a number of races and issues in the code as things were getting messy with the macvlan clean-up racing with the interface clean-up to bring the rings down on shutdown. With this change we opt to leave the rings owned by the PF interface for both Tx and Rx and just direct the packets once they are received to the macvlan netdev. Signed-off-by:
-
Alexander Duyck authored
We should not be stopping/starting the upper devices Tx queues when handling a macvlan offload. Instead we should be stopping and starting traffic on our own queues. In order to prevent us from doing this I am updating the code so that we no longer change the queue configuration on the upper device, nor do we update the queue_index on our own device. Instead we can just use the queue index for our local device and not update the netdev in the case of the transmit rings. Signed-off-by:
-
Alexander Duyck authored
We shouldn't be recording the Rx queue on macvlan offloaded frames since the macvlan is normally brought up as a single queue device, and it will trigger warnings for RPS if we have recorded queue IDs larger than the "real_num_rx_queues" value recorded for the device. Instead we should be recording the macvlan statistics since we are bypassing the normal macvlan statistics that would have been generated by the receive path. Signed-off-by:
-
Alexander Duyck authored
The code throughout ixgbe was assuming that dev->num_tc was populated and configured with the driver, when in fact this can be configured via mqprio without any hardware coordination other than restricting us to the real number of Tx queues we advertise. Instead of handling things this way we need to keep a local copy of the number of TCs in use so that we don't accidentally pull in the TC configuration from mqprio when it is configured in software mode. Signed-off-by:
-
Alexander Duyck authored
We might as well configure the limit to default to 1 pool always for the interface. This accounts for the fact that the PF counts as 1 pool if SR-IOV is enabled, and in general we are always running in 1 pool mode when RSS or DCB is enabled as well, though we don't need to actually evaluate any of the VMDq features in those cases. Signed-off-by:
-
Alexander Duyck authored
The macvlan driver itself will validate the MAC address that is configured for a given interface. There is no need for us to verify it again. Instead we should be checking to verify that we actually allocate the filter and have not run out of resources to configure a MAC rule in our filter table. Signed-off-by:
-
