- 31 Jul, 2017 9 commits
-
-
Jamal Hadi Salim authored
Bug fix for an issue which has been around for about a decade. We got away with it because the enumeration was larger than needed. Fixes: 7ba699c6 ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API") Suggested-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jamal Hadi Salim authored
Generic bitflags attribute content sent to the kernel by user. With this netlink attr type the user can either set or unset a flag in the kernel. The value is a bitmap that defines the bit values being set The selector is a bitmask that defines which value bit is to be considered. A check is made to ensure the rules that a kernel subsystem always conforms to bitflags the kernel already knows about. i.e if the user tries to set a bit flag that is not understood then the _it will be rejected_. In the most basic form, the user specifies the attribute policy as: [ATTR_GOO] = { .type = NLA_BITFIELD32, .validation_data = &myvalidflags }, where myvalidflags is the bit mask of the flags the kernel understands. If the user _does not_ provide myvalidflags then the attribute will also be rejected. Examples: value = 0x0, and selector = 0x1 implies we are selecting bit 1 and we want to set its value to 0. value = 0x2, and selector = 0x2 implies we are selecting bit 2 and we want to set its value to 1. Suggested-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
The FEC Receive Control Register has a 14 bit field indicating the longest frame that may be received. It is being set to 1522. Frames longer than this are discarded, but counted as being in error. When using DSA, frames from the switch has an additional header, either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame of 1522 bytes received by the switch on a port becomes 1530 bytes when passed to the host via the FEC interface. Change the maximum receive size to 2048 - 64, where 64 is the maximum rx_alignment applied on the receive buffer for AVB capable FEC cores. Use this value also for the maximum receive buffer size. The driver is already allocating a receive SKB of 2048 bytes, so this change should not have any significant effects. Tested on imx51, imx6, vf610. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
If the PHY is missing but expected, e.g. because of a typ0 in the dt file, it is not possible to open the interface. ip link returns: RTNETLINK answers: No such device It is not very obvious what the problem is. Add a netdev_err() in this case to make it easier to debug the issue. [ 21.409385] fec 2188000.ethernet eth0: Unable to connect to phy RTNETLINK answers: No such device Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Egil Hjelmeland says: ==================== net: dsa: lan9303: Fix MDIO issues. This series fix the MDIO interface for the lan9303 DSA driver. Bugs found after testing on actual HW. This series is extracted from the first patch of my first large series. Significant changes from that version are: - use mdiobus_write_nested, mdiobus_read_nested. - EXPORT lan9303_indirect_phy_ops Unfortunately I do not have access to i2c based system for testing. Changes from first version: - Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Egil Hjelmeland authored
Indirect access (PMI) to phy register only work in I2C mode. In MDIO mode phy registers must be accessed directly. Introduced struct lan9303_phy_ops to handle the two modes. Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Egil Hjelmeland authored
Preparing for the following fix of MDIO phy access: Renamed functions that access PHY 1 and 2 indirectly through PMI registers. lan9303_port_phy_reg_wait_for_completion() to lan9303_indirect_phy_wait_for_completion() lan9303_port_phy_reg_read() to lan9303_indirect_phy_read() lan9303_port_phy_reg_write() to lan9303_indirect_phy_write() Also changed "val" parameter of lan9303_indirect_phy_write() to u16, for clarity. Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Egil Hjelmeland authored
lan9303_mdio_write()/_read() must multiply register number by 4 to get offset. Added some commments to the register definitions. Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Egil Hjelmeland authored
Handle that MDIO read with no response return 0xffff. Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 30 Jul, 2017 4 commits
-
-
David S. Miller authored
Roopa Prabhu says: ==================== ethtool: support for forward error correction mode setting on a link Forward Error Correction (FEC) modes i.e Base-R and Reed-Solomon modes are introduced in 25G/40G/100G standards for providing good BER at high speeds. Various networking devices which support 25G/40G/100G provides ability to manage supported FEC modes and the lack of FEC encoding control and reporting today is a source for interoperability issues for many vendors. FEC capability as well as specific FEC mode i.e. Base-R or RS modes can be requested or advertised through bits D44:47 of base link codeword. This patch set intends to provide option under ethtool to manage and report FEC encoding settings for networking devices as per IEEE 802.3 bj, bm and by specs. v2 : - minor patch format fixes and typos pointed out by Andrew - there was a pending discussion on the use of 'auto' vs 'automatic' for fec settings. I have left it as 'auto' because in most cases today auto is used in place of automatic to represent automatically generated values. We use it in other networking config too. I would prefer leaving it as auto. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Casey Leedom authored
Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Casey Leedom authored
Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vidya Sagar Ravipati authored
Forward Error Correction (FEC) modes i.e Base-R and Reed-Solomon modes are introduced in 25G/40G/100G standards for providing good BER at high speeds. Various networking devices which support 25G/40G/100G provides ability to manage supported FEC modes and the lack of FEC encoding control and reporting today is a source for interoperability issues for many vendors. FEC capability as well as specific FEC mode i.e. Base-R or RS modes can be requested or advertised through bits D44:47 of base link codeword. This patch set intends to provide option under ethtool to manage and report FEC encoding settings for networking devices as per IEEE 802.3 bj, bm and by specs. set-fec/show-fec option(s) are designed to provide control and report the FEC encoding on the link. SET FEC option: root@tor: ethtool --set-fec swp1 encoding [off | RS | BaseR | auto] Encoding: Types of encoding Off : Turning off any encoding RS : enforcing RS-FEC encoding on supported speeds BaseR : enforcing Base R encoding on supported speeds Auto : IEEE defaults for the speed/medium combination Here are a few examples of what we would expect if encoding=auto: - if autoneg is on, we are expecting FEC to be negotiated as on or off as long as protocol supports it - if the hardware is capable of detecting the FEC encoding on it's receiver it will reconfigure its encoder to match - in absence of the above, the configuration would be set to IEEE defaults. >From our understanding , this is essentially what most hardware/driver combinations are doing today in the absence of a way for users to control the behavior. SHOW FEC option: root@tor: ethtool --show-fec swp1 FEC parameters for swp1: Active FEC encodings: RS Configured FEC encodings: RS | BaseR ETHTOOL DEVNAME output modification: ethtool devname output: root@tor:~# ethtool swp1 Settings for swp1: root@hpe-7712-03:~# ethtool swp18 Settings for swp18: Supported ports: [ FIBRE ] Supported link modes: 40000baseCR4/Full 40000baseSR4/Full 40000baseLR4/Full 100000baseSR4/Full 100000baseCR4/Full 100000baseLR4_ER4/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: [RS | BaseR | None | Not reported] Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: [RS | BaseR | None | Not reported] <<<< One or more FEC modes Speed: 100000Mb/s Duplex: Full Port: FIBRE PHYAD: 106 Transceiver: internal Auto-negotiation: off Link detected: yes This patch includes following changes a) New ETHTOOL_SFECPARAM/SFECPARAM API, handled by the new get_fecparam/set_fecparam callbacks, provides support for configuration of forward error correction modes. b) Link mode bits for FEC modes i.e. None (No FEC mode), RS, BaseR/FC are defined so that users can configure these fec modes for supported and advertising fields as part of link autonegotiation. Signed-off-by: Vidya Sagar Ravipati <vidya.chowdary@gmail.com> Signed-off-by: Dustin Byford <dustin@cumulusnetworks.com> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 29 Jul, 2017 27 commits
-
-
David S. Miller authored
Stephen Hemminger says: ==================== netvsc: minor fixes and optimization This is a subset of earlier submission with a few more fixes found during testing. The are two small optimizations, one is to better manage the receive completion ring, and the other is removing one unneeded level of indirection. Will submit the improved VF support and buffer sizing in a later patch so they get more review. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
Latency improvement related to NAPI conversion. If all packets are processed from receive ring then need to signal host. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
If setting receive buffer fails, the error unwind would cause kernel panic because it was not correctly doing RCU and NAPI unwind. RCU'd pointer needs to be reset to NULL, and NAPI needs to be disabled not deleted. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
Optimize how receive completion ring are managed. * Allocate only as many slots as needed for all buffers from host * Allocate before setting up sub channel for better error detection * Don't need to keep copy of initial receive section message * Precompute the watermark for when receive flushing is needed * Replace division with conditional test * Replace atomic per-device variable with per-channel check. * Handle corner case where receive completion send fails if ring buffer to host is full. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
The internal API was passing struct hv_page_buffer ** when only simple struct hv_page_buffer * was necessary for passing an array. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
Using %p to print pointer to packet meta-data doesn't give any good info, and exposes kernel memory offsets. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
This includes a bunch of fixups for issues reported by lockdep. * ethtool routines can assume RTNL * send is done with RCU lock (and BH disable) * avoid refetching internal device struct (netvsc) instead pass it as a parameter. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
The error and normal case got swapped. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Felix Manlunas authored
Bump up driver version to match newer NIC firmware. Also update nic_rx_stats (a struct common to host driver and firmware) by adding a new field: fw_total_fwd_bytes. Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sathya Perla authored
bnxt_en depends on MAY_USE_DEVLINK; this is used to force bnxt_en to be =m when DEVLINK is =m. Now, bnxt_re selects bnxt_en. Unless bnxt_re also explicitly calls out dependency on MAY_USE_DEVLINK, Kconfig does not force bnxt_re to be =m when DEVLINK is =m, causing the following error: drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function `bnxt_dl_register': bnxt_vfr.c:(.text+0x1440): undefined reference to `devlink_alloc' bnxt_vfr.c:(.text+0x14c0): undefined reference to `devlink_register' bnxt_vfr.c:(.text+0x14e0): undefined reference to `devlink_free' drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function `bnxt_dl_unregister': bnxt_vfr.c:(.text+0x1534): undefined reference to `devlink_unregister' bnxt_vfr.c:(.text+0x153c): undefined reference to `devlink_free' Fix this by adding MAY_USE_DEVLINK dependency in bnxt_re. Fixes: 4ab0c6a8 ("bnxt_en: add support to enable VF-representors") Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
John Fastabend authored
Apparently through one of my revisions of the initial patches series I lost the devmap test. We can add more testing later but for now lets fix the simple one we have. Fixes: 546ac1ff "bpf: add devmap, a map for storing net device references" Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
SZ Lin says: ==================== net: moxa: Fix style issues This patch set fixs the WARNINGs found by the checkpatch.pl tool ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
SZ Lin authored
This patch fixes all checkpatch occurences of "CHECK: spaces preferred around that '{+,-}' (ctx:VxV)" in moxart_ether code. Signed-off-by: SZ Lin <sz.lin@moxa.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
SZ Lin authored
Signed-off-by: SZ Lin <sz.lin@moxa.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
SZ Lin authored
No space is necessary after a cast This warning is found using checkpatch.pl Signed-off-by: SZ Lin <sz.lin@moxa.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
SZ Lin authored
Fixed coding style for null comparisons in moxart_ether driver to be more consistent with the rest of the kernel coding style Signed-off-by: SZ Lin <sz.lin@moxa.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
SZ Lin authored
Use 'unsigned int' instead of 'unsigned' This warning is found using checkpatch.pl Signed-off-by: SZ Lin <sz.lin@moxa.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
SZ Lin authored
Remove unnecessary braces from single-line if statement This warning is found using checkpatch.pl Signed-off-by: SZ Lin <sz.lin@moxa.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ursula Braun says: ==================== net/smc: get rid of unsafe_global_rkey The smc code uses the unsafe_global_rkey, exposing all memory for remote reads and writes once a connection is established. Here is now a patch series to get rid of unsafe_global_rkey usage. Main idea is to switch to SG-logic and separate memory regions for RMBs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
Usage of send buffer "sndbuf" is synced (a) before filling sndbuf for cpu access (b) after filling sndbuf for device access Usage of receive buffer "RMB" is synced (a) before reading RMB content for cpu access (b) after reading RMB content for device access Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
Split function __smc_buf_create() for better readability. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
Creation and deletion of SMC receive and send buffers shares a high amount of common code . This patch introduces common functions to get rid of duplicate code. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
SMC send buffers are processed the same way as RMBs. Since RMBs have been converted to sg-logic, do the same for send buffers. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
Now separate memory regions are created and registered for separate RMBs. The unsafe_global_rkey of the protection domain is no longer used. Thus the exposing memory warning can be removed. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
A memory region created for a new RMB must be registered explicitly, before the peer can make use of it for remote DMA transfer. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
SMC currently uses the unsafe_global_rkey of the protection domain, which exposes all memory for remote reads and writes once a connection is established. This patch introduces separate memory regions with separate rkeys for every RMB. Now the unsafe_global_rkey of the protection domain is no longer needed. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
The follow-on patch makes use of ib_map_mr_sg() when introducing separate memory regions for RMBs. This function is based on scatterlists; thus this patch introduces scatterlists for RMBs. Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-