- 26 May, 2017 13 commits
-
-
Roopa Prabhu authored
This flag when specified will return matched fib result in response to a RTM_GETROUTE query. Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David Ahern authored
Prefix is needed for returning matching route spec on get route request. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David Ahern authored
Convert inet_rtm_getroute to use ip_route_input_rcu and ip_route_output_key_hash_rcu passing the fib_result arg to both. The rcu lock is held through the creation of the response, so the rtable/dst does not need to be attached to the skb and is passed to rt_fill_info directly. In converting from ip_route_output_key to ip_route_output_key_hash_rcu the xfrm_lookup_route in ip_route_output_flow is dropped since flowi4_proto is not set for a route get request. Signed-off-by:
-
David Ahern authored
rt_fill_info has 1 caller with the event set to RTM_NEWROUTE. Given that remove the arg and use RTM_NEWROUTE directly in rt_fill_info. Signed-off-by:
-
David Ahern authored
A later patch wants access to the fib result on an input route lookup with the rcu lock held. Refactor ip_route_input_noref pushing the logic between rcu_read_lock ... rcu_read_unlock into a new helper that takes the fib_result as an input arg. Signed-off-by:
-
David Ahern authored
A later patch wants access to the fib result on an output route lookup with the rcu lock held. Refactor __ip_route_output_key_hash, pushing the logic between rcu_read_lock ... rcu_read_unlock into a new helper with the fib_result as an input arg. To keep the name length under control remove the leading underscores from the name and add _rcu to the name of the new helper indicating it is called with the rcu read lock held. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: devlink port implementation This series adds basic devlink support. The operations we can perform are port show and port split/unsplit. v2: Register devlink first, and then register all the ports. Port {,un}split searches the port list, which is protected by a mutex. If port split is requested before ports are registered we will simply not find the port and return -EINVAL. ==================== Signed-off-by: -
Jakub Kicinski authored
Add support for configuring port split with devlink. Add devlink callbacks to validate requested config and call NSP helpers. Getting the right nfp_port structure can be done with simple iteration. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
For port splitting we will need to know the total number of lanes in a port. Calculate that based on eth_table information. Signed-off-by:
-
Jakub Kicinski authored
Extend nfp_port to contain devlink_port structures. Register the ports to allow users inspecting device ports. Signed-off-by:
-
Jakub Kicinski authored
We will soon have to invoke more clean up for vNICs. Move the cleanup callbacks into a helper. Signed-off-by:
-
Simon Horman authored
Add initial devlink support. This patch simply switches allocation of per-adapter structure to devlink's priv and register devlink with empty ops table. See following patches for implementation of particular ops. We should now clear the app pointer on exit, this is how devlink callbacks will know app is not initialized. Signed-off-by:
-
Jakub Kicinski authored
Move mutex init to main file close to structure allocation. This will allow mutex to be taken before net code runs (e.g. from devlink callbacks). While at it remember to destroy the mutex. Signed-off-by:
-
- 25 May, 2017 27 commits
-
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Support firmware flash Add support for device firmware flash on mlxsw spectrum. The firmware files are expected to be in the Mellanox Firmware Archive version 2 (MFA2) format. The firmware flash is triggered on driver initialization time if the device firmware version does not meet the minimum firmware version supported by the driver. Currently, to activate the newly flashed firmware, the user needs to reboot his system. The first patch introduces the mlxfw module, which implements common logic needed for the firmware flash process on Mellanox products, such as the MFA2 format parsing and the firmware flash state machine logic. As the module implements common logic which will be needed by various different Mellanox drivers, it defines a set of callbacks needed to interact with the specific device. Patches 1-5 implement the needed mlxfw callbacks in the mlxsw spectrum driver. Patches 6 and 7 add boot-time firmware upgrade on the mlxsw spectrum driver. Patch 8 adds a fix needed for new firmware versions. ==================== Signed-off-by: -
Ido Schimmel authored
In new firmware versions, when configuring a {Port, VID} as a router interface, the driver is responsible for enabling the STP filter and disabling learning. Otherwise, packets are discarded. This change doesn't break existing firmware versions, but is required for newer firmware versions. Signed-off-by:Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Yotam Gigi authored
Make the spectrum module check the current device firmware version, and if it is below the supported version, use the libfirmware API to request a firmware file with the supported firmware version and flash it to the device using the mlxfw module. The firmware file names are expected to be of Mellanox Firmware Archive version 2 (MFA2) format and their name are expected to be in the following pattern: "mlxsw_spectrum-<major>.<minor>.<sub-minor>.mfa2". Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Signed-off-by:
-
Yotam Gigi authored
This struct was previously an anonymous struct defined inside the mlxsw_bus_info struct. Extract it to a struct named mlxsw_fw_rev, as it will be needed later by the spectrum driver. Signed-off-by:
-
Yotam Gigi authored
The mlxfw module defines several needed callbacks in order to flash the device's firmware. As the mlxfw module is shared between several different drivers, those callbacks are the glue functionality that is responsible for hardware interaction. Add those callbacks using the MCQI, MCC, MCDA registers. Signed-off-by:
-
Yotam Gigi authored
The MCDA register allows reading and writing a firmware component. Signed-off-by:
-
Yotam Gigi authored
The MCC register allows controlling and querying the firmware flash state machine (FSM). Signed-off-by:
-
Yotam Gigi authored
The MCQI register queries information about firmware components. It will be needed by the mlxfw module to query various options about the components, such as their max size, alignment and max write size. Signed-off-by:
-
Yotam Gigi authored
The mlxfw module is in charge of common logic needed to flash Mellanox devices firmware, which consists of: - Parse the Mellanox Firmware Archive version 2 (MFA2) format, which is the format used to store the Mellanox firmware. The MFA2 format file can hold firmware for many different silicon variants, differentiated by a unique ID called PSID. In addition, the MFA2 file data section is compressed using xz compression to save both file-system space and memory at extraction time. - Implement the firmware flash state machine logic, which is a common logic for Mellanox products needed to flash the firmware to the device. As the module is shared between different Mellanox products, it defines a set of callbacks to be implemented by the specific driver for hardware interaction. Signed-off-by:
-
David S. Miller authored
Suresh Reddy says: ==================== be2net: patch-set Hi Dave, Please consider applying these two patches to net-next ==================== Signed-off-by: -
Suresh Reddy authored
Signed-off-by:
Suresh Reddy <suresh.reddy@broadcom.com> Signed-off-by:
-
Suresh Reddy authored
On certain platforms BE3 chips may indicate spurious UEs (unrecoverable error). Because of the UE detection logic was disabled in the driver for BE3 chips. Because of this, even in cases of a real UE, a failover will not occur. This patch re-enables UE detection on BE3 and if a UE is detected, reads the POST register. If the POST register, reports either a FAT_LOG_STATE or a ARMFW_UE, then it means that a valid UE occurred in the chip. Signed-off-by:
-
David Howells authored
Support network namespacing in AF_RXRPC with the following changes: (1) All the local endpoint, peer and call lists, locks, counters, etc. are moved into the per-namespace record. (2) All the connection tracking is moved into the per-namespace record with the exception of the client connection ID tree, which is kept global so that connection IDs are kept unique per-machine. (3) Each namespace gets its own epoch. This allows each network namespace to pretend to be a separate client machine. (4) The /proc/net/rxrpc_xxx files are now called /proc/net/rxrpc/xxx and the contents reflect the namespace. fs/afs/ should be okay with this patch as it explicitly requires the current net namespace to be init_net to permit a mount to proceed at the moment. It will, however, need updating so that cells, IP addresses and DNS records are per-namespace also. Signed-off-by:David Howells <dhowells@redhat.com> Signed-off-by:
-
Rosen, Rami authored
This patch removes unused parameter from prb_curr_blk_in_use() method in net/packet/af_packet.c. Signed-off-by:
Rami Rosen <rami.rosen@intel.com> Signed-off-by:
-
David S. Miller authored
Corentin Labbe says: ==================== net-next: stmmac: rework the speed selection The current stmmac_adjust_link() part which handle speed have some if (has_platform) code and my dwmac-sun8i will add more of them. So we need to handle better speed selection. Moreover the struct link member speed and port are hard to guess their purpose. And their unique usage are to be combined for writing speed. My first try was to create an adjust_link() in stmmac_ops but it duplicate some code The current solution is to have direct value for 10/100/1000 and a mask for them. The first 4 patchs fix some minor problem found in stmmac_adjust_link() and reported by Florian Fainelli in my previous serie. The last patch is the real work. This series is tested on cubieboard2 (dwmac1000) and opipc (dwmac-sun8i). Changes since v3: - Added the patch #4 "Convert old_link to bool" as suggested by Joe Perches - Changed the speedmask Changes since v2: - Use true/false for new_state in patch #1 ==================== Signed-off-by: -
LABBE Corentin authored
The current stmmac_adjust_link() part which handle speed have some if (has_platform) code and my dwmac-sun8i will add more of them. So we need to handle better speed selection. Moreover the struct link member speed and port are hard to guess their purpose. And their unique usage are to be combined for writing speed. So this patch replace speed/port by simpler speed10/speed100/speed1000/speed_mask variables. In dwmac4_core_init and dwmac1000_core_init, port/speed value was used directly without using the struct link. This patch convert also their usage to speedxxx. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
LABBE Corentin authored
This patch convert old_link from int to bool since it store only 1 or 0 Signed-off-by:
-
LABBE Corentin authored
Signed-off-by:
-
LABBE Corentin authored
Signed-off-by:
-
LABBE Corentin authored
This patch convert new_state from int to bool since it store only 1 or 0 Signed-off-by:
-
Matthias Kaehlcke authored
The functions jme_restart_tx_engine(), jme_pause_rx() and jme_resume_rx() are not used. Removing them fixes the following warnings when building with clang: drivers/net/ethernet/jme.c:694:1: error: unused function 'jme_restart_tx_engine' [-Werror,-Wunused-function] drivers/net/ethernet/jme.c:2393:20: error: unused function 'jme_pause_rx' [-Werror,-Wunused-function] drivers/net/ethernet/jme.c:2406:20: error: unused function 'jme_resume_rx' [-Werror,-Wunused-function] Signed-off-by:Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2017-05-23 Here's the first Bluetooth & 802.15.4 pull request targeting the 4.13 kernel release. - Bluetooth 5.0 improvements (Data Length Extensions and alternate PHY) - Support for new Intel Bluetooth adapter [[8087:0aaa] - Various fixes to ieee802154 code - Various fixes to HCI UART code ==================== Signed-off-by:
-
Uwe Kleine-König authored
Commit af6b6967 ("net: phy: export genphy_config_init()") introduced this EXPORT_SYMBOL and put it after gen10g_soft_reset() instead of directly after genphy_config_init. Probably this happend when the patch was applied because http://patchwork.ozlabs.org/patch/339622/ looks ok. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Eric Dumazet authored
Paul Fiterau Brostean reported : <quote> Linux TCP stack we analyze exhibits behavior that seems odd to me. The scenario is as follows (all packets have empty payloads, no window scaling, rcv/snd window size should not be a factor): TEST HARNESS (CLIENT) LINUX SERVER 1. - LISTEN (server listen, then accepts) 2. - --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED 3. - <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 4. - --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED 5. - <-- <SEQ=301><ACK=101><CTL=FIN,ACK> <-- FIN WAIT-1 (server opts to close the data connection calling "close" on the connection socket) 6. - --> <SEQ=101><ACK=99999><CTL=FIN,ACK> --> CLOSING (client sends FIN,ACK with not yet sent acknowledgement number) 7. - <-- <SEQ=302><ACK=102><CTL=ACK> <-- CLOSING (ACK is 102 instead of 101, why?) ... (silence from CLIENT) 8. - <-- <SEQ=301><ACK=102><CTL=FIN,ACK> <-- CLOSING (retransmission, again ACK is 102) Now, note that packet 6 while having the expected sequence number, acknowledges something that wasn't sent by the server. So I would expect the packet to maybe prompt an ACK response from the server, and then be ignored. Yet it is not ignored and actually leads to an increase of the acknowledgement number in the server's retransmission of the FIN,ACK packet. The explanation I found is that the FIN in packet 6 was processed, despite the acknowledgement number being unacceptable. Further experiments indeed show that the server processes this FIN, transitioning to CLOSING, then on receiving an ACK for the FIN it had send in packet 5, the server (or better said connection) transitions from CLOSING to TIME_WAIT (as signaled by netstat). </quote> Indeed, tcp_rcv_state_process() calls tcp_ack() but does not exploit the @acceptable status but for TCP_SYN_RECV state. What we want here is to send a challenge ACK, if not in TCP_SYN_RECV state. TCP_FIN_WAIT1 state is not the only state we should fix. Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process() can choose to send a challenge ACK and discard the packet instead of wrongly change socket state. With help from Neal Cardwell. Signed-off-by:Eric Dumazet <edumazet@google.com> Reported-by:
Paul Fiterau Brostean <p.fiterau-brostean@science.ru.nl> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
WANG Cong authored
tcf_chain_get() always creates a new filter chain if not found in existing ones. This is totally unnecessary when we get or delete filters, new chain should be only created for new filters (or new actions). Fixes: 5bc17018 ("net: sched: introduce multichain support for filters") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Jiri Pirko authored
With the introduction of chain goto action, the reclassification would cause the re-iteration of the actual chain. It makes more sense to restart the whole thing and re-iterate starting from the original tp - start of chain 0. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-update-2017-05-23 First patch from Leon, came to remove the redundant usage of mlx5_vzalloc, and directly use kvzalloc across all mlx5 drivers. 2nd patch from Noa, adds new device IDs into the supported devices list. 3rd and 4th patches from Ilan are adding the basic infrastructure and support for Mellanox's mlx5 FPGA. Last two patches from Tariq came to modify the outdated driver version reported in ethtool and in mlx5_ib to more reflect the current driver state and remove the redundant date string reported in the version. ==================== Signed-off-by:
-
