- 07 Dec, 2015 1 commit
-
-
Bjørn Mork authored
The notifier calls were thrown in as a last-minute fix for an imagined "this device could be part of a bridge" problem. That revealed a certain lack of locking. Not to mention testing... Avoid this splat: RTNL: assertion failed at net/core/dev.c (1639) CPU: 0 PID: 4293 Comm: bash Not tainted 4.4.0-rc3+ #358 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 0000000000000000 ffff8800ad253d60 ffffffff8122f7cf ffff8800ad253d98 ffff8800ad253d88 ffffffff813833ab 0000000000000002 ffff880230f48560 ffff880230a12900 ffff8800ad253da0 ffffffff813833da 0000000000000002 Call Trace: [<ffffffff8122f7cf>] dump_stack+0x4b/0x63 [<ffffffff813833ab>] call_netdevice_notifiers_info+0x3d/0x59 [<ffffffff813833da>] call_netdevice_notifiers+0x13/0x15 [<ffffffffa09be227>] raw_ip_store+0x81/0x193 [qmi_wwan] [<ffffffff8131e149>] dev_attr_store+0x20/0x22 [<ffffffff811d858b>] sysfs_kf_write+0x49/0x50 [<ffffffff811d8027>] kernfs_fop_write+0x10a/0x151 [<ffffffff8117249a>] __vfs_write+0x26/0xa5 [<ffffffff81085ed4>] ? percpu_down_read+0x53/0x7f [<ffffffff81174c9e>] ? __sb_start_write+0x5f/0xb0 [<ffffffff81174c9e>] ? __sb_start_write+0x5f/0xb0 [<ffffffff81172c37>] vfs_write+0xa3/0xe7 [<ffffffff811734ad>] SyS_write+0x50/0x7e [<ffffffff8145c517>] entry_SYSCALL_64_fastpath+0x12/0x6f Fixes: 32f7adf6 ("net: qmi_wwan: support "raw IP" mode") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 06 Dec, 2015 24 commits
-
-
Singhai, Anjali authored
This reverts commit 8fe26999. The case where VXLAN is a module and i40e driver is inbuilt will not be handled properly with this change since i40e will have an undefined symbol vxlan_get_rx_port in it. v2: Add a signed-off-by. Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Acked-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2015-12-05 This series contains updates to fm10k only. Jacob provides the remaining fm10k patches in the series. First change ensures that all the logic regarding the setting of netdev features is consolidated in one place of the driver. Fixed an issue where an assumption was being made on how many queues are available, especially when init_hw_vf() errors out. Fixed up an number of issues with init_hw() where failures were not being handled properly or at all, so update the driver to check returned error codes and respond appropriately. Fixed up typecasting issues found where either the incorrect typecast size was used or explicitly typecast values. Added additional debugging statistics and rename statistic to better reflect its true value. Added support for ITR scaling based on PCIe link speed for fm10k. Fixed up code comment where "hardware" was misspelled. v2: Dropped patches #1 and #10 from original submission, patch #1 was from Nick Krause and due to his past kernel interactions, dropping his patch. Patch #10 had questions and concerns from Tom Herbert which cannot be addressed at this time since the author (Jacob Keller) is currently on sabbatical, so dropping this patch for now until we can properly address Tom's questions and concerns. ==================== Signed-off-by: -
Jacob Keller authored
Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
-
Jacob Keller authored
Signed-off-by:
-
Jacob Keller authored
The current default ITR for Tx is overly restrictive. Using a simple netperf TCP_STREAM test, we top out at about 10Gb/s for a single thread when running using 1500 byte frames. By reducing the ITR value to 25usec (up to 40K interrupts a second from 10K), we are able to achieve 36Gb/s for a single thread TCP stream test. Signed-off-by:
-
Jacob Keller authored
Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
-
Jacob Keller authored
The existing adaptive ITR algorithm is overly restrictive. It throttles incorrectly for various traffic rates, and does not produce good performance. The algorithm now allows for more interrupts per second, and does some calculation to help improve for smaller packet loads. In addition, take into account the new itr_scale from the hardware which indicates how much to scale due to PCIe link speed. Reported-by:
Matthew Vick <matthew.vick@intel.com> Reported-by:
Alex Duyck <alexander.duyck@gmail.com> Signed-off-by:
-
Jacob Keller authored
Define a macro for identifying when the itr value is dynamic or adaptive. The concept was taken from i40e. This helps make clear what the check is, and reduces the line length to something more reasonable in a few places. Signed-off-by:
-
Jacob Keller authored
The Intel Ethernet Switch FM10000 Host Interface interrupt throttle timers are based on the PCIe link speed. Because of this, the value being programmed into the ITR registers must be scaled accordingly. For the PF, this is as simple as reading the PCIe link speed and storing the result. However, in the case of SR-IOV, the VF's interrupt throttle timers are based on the link speed of the PF. However, the VF is unable to get the link speed information from its configuration space, so the PF must inform it of what scale to use. Rather than pass this scale via mailbox message, take advantage of unused bits in the TDLEN register to pass the scale. It is the responsibility of the PF to program this for the VF while setting up the VF queues and the responsibility of the VF to get the information accordingly. This is preferable because it allows the VF to set up the interrupts properly during initialization and matches how the MAC address is passed in the TDBAL/TDBAH registers. Since we're modifying fm10k_type.h, we may as well also update the copyright year. Reported-by:
-
Jacob Keller authored
Originally this statistic was renamed because the method of dropping was called "drop_oversized_messages", but this logic has changed much, and this counter does actually represent messages which we failed to transmit for a number of reasons. Rename the counter back to tx_dropped since this is when it will increment, and it is less confusing. Signed-off-by:
-
Jacob Keller authored
A previous bug was uncovered by addition of a debug stat to indicate the actual number of DWORDS we pulled from the mbmem. It turned out this was not the same as the tx_dwords counter. While the previous bug fix should have corrected this in all cases, add some debug stats that count the number of DWORDs pushed or pulled from the mbmem. A future debugger may take advantage of this statistic for debugging purposes. Since we're modifying fm10k_mbx.h, update the copyright year as well. Signed-off-by:
-
Jacob Keller authored
Signed-off-by:
-
Jacob Keller authored
Since the resultant data type of the mac_update.mac_upper field is u16, it does not make sense to typecast u8 variables to u32 first. Since we're modifying fm10k_pf.c, also update the copyright year. Reported-by:
-
Jacob Keller authored
The init_hw function may fail, and in the case of VFs, it might change the number of maximum queues available. Thus, for every flow which checks init_hw, we need to ensure that we clear the queue scheme before, and initialize it after. The fm10k_io_slot_reset path will end up triggering a reset so fm10k_reinit needs this change. The fm10k_io_error_detected and fm10k_io_resume also need to properly clear and reinitialize the queue scheme. Signed-off-by:
-
Jacob Keller authored
A recent change modified init_hw in some flows the function may fail on VF devices. For example, if a VF doesn't yet own its own queues. However, many callers of init_hw didn't bother to check the error code. Other callers checked but only displayed diagnostic messages without actually handling the consequences. Fix this by (a) always returning and preventing the netdevice from going up, and (b) printing the diagnostic in every flow for consistency. This should resolve an issue where VF drivers would attempt to come up before the PF has finished assigning queues. In addition, change the dmesg output to explicitly show the actual function that failed, instead of combining reset_hw and init_hw into a single check, to help for future debugging. Fixes: 1d568b0f6424 ("fm10k: do not assume VF always has 1 queue") Signed-off-by: -
Jacob Keller authored
VF drivers must detect how many queues are available. Previously, the driver assumed that each VF has at minimum 1 queue. This assumption is incorrect, since it is possible that the PF has not yet assigned the queues to the VF by the time the VF checks. To resolve this, we added a check first to ensure that the first queue is infact owned by the VF at init_hw_vf time. However, the code flow did not reset hw->mac.max_queues to 0. In some cases, such as during reinit flows, we call init_hw_vf without clearing the previous value of hw->mac.max_queues. Due to this, when init_hw_vf errors out, if its error code is not properly handled the VF driver may still believe it has queues which no longer belong to it. Fix this by clearing the hw->mac.max_queues on exit due to errors. Signed-off-by:
-
Jacob Keller authored
Don't change netdev hw_features later in fm10k_probe, instead set all values inside fm10k_alloc_netdev. To do so, we need to know the MAC type (whether it is PF or VF) in order to determine what to do. This helps ensure that all logic regarding features is co-located. Signed-off-by:
-
David S. Miller authored
Sergei Shtylyov says: ==================== Renesas: read MAC address registers only once Here's 2 patches against DaveM's 'net-next.git' repo. Here we optimize the MAC address register reading (left over from a bootloader). [1/2] ravb: read MAC address registers only once [2/2] sh_eth: read MAC address registers only once ==================== Signed-off-by: -
Sergei Shtylyov authored
The code reading the MAHR/MALR registers in read_mac_address() is terribly ineffective -- it reads MAHR 4 times and MALR 2 times, while it's enough to read each register only once. Use the local variables to achieve that, somewhat beautifying the code while at it... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Sergei Shtylyov authored
The code reading the MAHR/MALR registers in ravb_read_mac_address() is terribly ineffective -- it reads MAHR 4 times and MALR 2 times, while it's enough to read each register only once. Use the local variables to achieve that, somewhat beautifying the code while at it... Signed-off-by:
-
David S. Miller authored
Michal Schmidt says: ==================== bnx2x: fewer error messages, simplification This removes one redundant error message in bnx2x and changes another one to WARN_ONCE. The third patch is a small simplification in ethtool stats. ==================== Signed-off-by: -
Michal Schmidt authored
The 'flags' field in bnx2x_stats_arr[] serves only one purpose - to tell us if the statistic is a per-port stat and thus should not be shown for virtual functions. It's strange that the field can have three different values. A boolean will do just fine. Also remove IS_FUNC_STAT(). It was used only once and it's in fact just a negation of IS_PORT_STAT(). Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
-
Michal Schmidt authored
It's supposed to be impossible for TPA to give us anything else than IPv4 or IPv6 here. But in case there is a way to reach this error by some strange received frames, we don't want to flood the kernel log. WARN_ONCE is better for this purpose. Signed-off-by:
-
Michal Schmidt authored
alloc_pages() already prints a warning when it fails. No need to emit another message. Certainly not at KERN_ERR level, because it is no big deal if this GFP_ATOMIC allocation fails occasionally. Signed-off-by:
-
- 05 Dec, 2015 8 commits
-
-
Jiri Pirko authored
As suggested by Eric, these helpers should have const dev param. Suggested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Daniel Pieczko authored
A change in MCFW behaviour means that the net driver must update its record of the warm_boot_count by reading it from the ER_DZ_BIU_MC_SFT_STATUS register. On v4.6.x MCFW the global boot count was incremented when some functions needed to be reset to enable multicast chaining, so all functions saw the same value. In that case, the driver needed to increment its warm_boot_count when other functions were reset, to avoid noticing it later and then trying to reset itself to recover unnecessarily. With v4.7+ MCFW, the boot count in firmware doesn't change as that is unnecessary since the PFs that have been reset will each receive an MC reboot notification. In that case, the driver re-reads the unchanged value. Signed-off-by:
Bert Kenward <bkenward@solarflare.com> Signed-off-by:
-
LABBE Corentin authored
The simple_strtol function is obsolete. This patch replace it by kstrtoint. This will simplify code, since some error case not handled by simple_strtol are handled by kstrtoint. Signed-off-by:
LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Allow BATMAN to use hdlc-eth interfaces BATMAN works over Ethernet like interfaces. hdlc-eth provides the need requirements. However, hdlc devices are often created as raw hdlc devices, which batman cannot use, and are then be transmuted into other types using sethdlc(1). Have the HDLC code emit NETDEV_*_TYPE_CHANGE events when the type changes, and have BATMAN react on these events. ==================== Signed-off-by: -
Andrew Lunn authored
A network interface can change type. It may change from a type which batman does not support, e.g. hdlc, to one it does, e.g. hdlc-eth. When an interface changes type, it sends two notifications. Handle these notifications. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
An interface changing type may not have IPv6 addresses. Don't call the address configuration type change in this case. Signed-off-by:
-
Andrew Lunn authored
An HDLC device can change type when the protocol driver is changed. Calling the notifier change allows potential users of the interface know about this planned change, and even block it. After the change has occurred, send a second notification to users can evaluate the new device type etc. Signed-off-by:
-
Andrew Lunn authored
The current code first unregisters the device, and then detaches the protocol from it. This should be performed the other way around, since the detach may try to use state which has been freed by the unregister. Swap the order, so that we first detach and then remove the netdev. Signed-off-by:
-
- 04 Dec, 2015 7 commits
-
-
David S. Miller authored
Bjørn Mork says: ==================== net: qmi_wwan: MDM9x30 support We add new device IDs all the time, often without any testing on actual hardware. This is usually OK as long as the device is similar to already supported devices, using the same chipset and firmware basis. But the Sierra Wireless MC7455 is an example of a new chipset generation. Adding it based on assumed similarity with its ancestors proved too optimistic. This series adds the missing bits and pieces necessary to support LTE Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks to Sierra Wireless for providing MC7455 samples for testing The most important change is the "raw-ip" support. The series also adds a necessary control request, removes an unsupported device ID, and adds a driver specific entry in MAINTAINERS. A few random notes about "raw-ip": "I rather have these all running in raw IP mode. The 802.3 framing is utterly stupid." - Marcel Holtmann in Jan 2012 [1] Marcel was right. I should have listened to him. What more can I say? The 802.3 framing has provided a steady supply of firmware bugs for many years. We've added driver workarounds for many of these, but there are still known bugs where the workaround is so yucky that we have refused to apply it. But all that is over now. The latest generation Qualcomm chips no longer supports 802.3 framing at all. I had two open questions regarding the "raw-ip" userspace API: 1) Should we continue faking an ethernet device, even if we don't use the L2 headers on the USB link anymore? There was a vote in favour of the "headerless" device. This is the honest representation of the hardware/firmware interface. 2) What input should the driver base its framing on? Snooping or directly manipulating QMI is considered out of the question. We delegated all QMI handling to userspace from the beginning. We have so far required userspace to configure the firmware for "802.3" framing, or fail if that proved impossible. This requirement is now changed. Userspace must now inform the driver if it negotiates "raw-ip" framing. Two alternative interfaces were proposed: - ethtool private driver flag, or - sysfs file The NetworkManager/ModemManager developers were in favour of the sysfs alternative. These questions (or any other you migh have :) are of course still open. This patch set presents the solutions I currently prefer, considering the above. All comments are appreciated, even simple '+1' ones. ==================== Signed-off-by: -
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
QMI wwan devices have traditionally emulated ethernet devices by default. But they have always had the capability of operating without any L2 header at all, transmitting and receiving "raw" IP packets over the USB link. This firmware feature used to be configurable through the QMI management protocol. Traditionally there was no way to verify the firmware mode without attempting to change it. And the firmware would often disallow changes anyway, i.e. due to a session already being established. In some cases, this could be a hidden firmware internal session, completely outside host control. For these reasons, sticking with the "well known" default mode was safest. But newer generations of QMI hardware and firmware have moved towards defaulting to "raw IP" mode instead, followed by an increasing number of bugs in the already buggy "802.3" firmware implementation. At the same time, the QMI management protocol gained the ability to detect the current mode. This has enabled the userspace QMI management application to verify the current firmware mode without trying to modify it. Following this development, the latest QMI hardware and firmware (the MDM9x30 generation) has dropped support for "802.3" mode entirely. Support for "raw IP" framing in the driver is therefore necessary for these devices, and to a certain degree to work around problems with the previous generation, This patch adds support for "raw IP" framing for QMI devices, changing the netdev from an ethernet device to an ARPHRD_NONE p-t-p device when "raw IP" framing is enabled. The firmware setup is fully delegated to the QMI userspace management application, through simple tunneling of the QMI protocol. The driver will therefore not know which mode has been "negotiated" between firmware and userspace. Allowing userspace to inform the driver of the result through a sysfs switch is considered a better alternative than to change the well established clean delegation of firmware management to userspace. Signed-off-by:
-
Bjørn Mork authored
Assume the minidriver has taken care of all L2 header parsing if it sets skb->protocol. This allows the minidriver to support non-ethernet L2 headers, and even operate without any L2 header at all. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Bjørn Mork authored
This turned out to be a bootloader device ID. No need for that in this driver. It will only provide a single serial function. Signed-off-by:
-
Bjørn Mork authored
MDM9x30 based modems appear to go into a deeper sleep when suspended without "Remote Wakeup" enabled. The QMI interface will not respond unless a "set DTR" control request is sent on resume. The effect is similar to a QMI_CTL SYNC request, resetting (some of) the firmware state. We allow userspace sessions to span multiple character device open/close sequences. This means that userspace can depend on firmware state while both the netdev and the character device are closed. We have disabled "needs_remote_wakeup" at this point to allow devices without remote wakeup support to be auto-suspended. To make sure the MDM9x30 keeps firmware state, we need to keep "needs_remote_wakeup" always set. We also need to issue a "set DTR" request to enable the QMI interface. Signed-off-by:
-
