Jacob Keller [Mon, 6 Feb 2017 22:38:40 +0000 (14:38 -0800)]
i40e: rework exit flow of i40e_add_fdir_ethtool
Refactor the exit flow of the i40e_add_fdir_ethtool function. Move the
input_label to the end of the function, removing the dependency on
having a non-zero return value. Add a comment explaining why it is ok
not to free the fdir data structure, because the structure is now stored
in the fdir_filter_list.
Change-Id: I723342181d59cd0c9f3b31140c37961ba37bb242 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 01016da1e58136518252822738fe833c662df916) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:39 +0000 (14:38 -0800)]
i40e: don't use arrays for (src|dst)_ip
The code originally included src_ip and dst_ip with enough space to
support ipv6 filters. However, no actual support for ipv6 filters has
been implemented. Thus, remove the arrays and just use __be32 values.
Should ipv6 support be added in the future, we can replace these with
a union that has sizes for both values.
Change-Id: I1bc04032244a80eb6ebc8a4e6c723a4a665c1dd5 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 8ce43dce6f272202dcd127e0e288b37277ca87dd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:38 +0000 (14:38 -0800)]
i40e: send correct port number to AdminQ when enabling UDP tunnels
The firmware expects the port numbers for offloaded UDP tunnels in
Little Endian format. We accidentally sent the value in Big Endian
format which obviously will cause the wrong port number to be put into
the UDP tunnels list. This results in VxLAN and Geneve tunnel Rx
offloads being essentially disabled, unless the port number happens to
be identical after byte swapping. Note that i40e_aq_add_udp_tunnel()
will byteswap the parameter from host order into Little Endian so we
don't need worry about passing strictly a __le16 value to the command.
This patch essentially reverts b3f5c7bc88ba ("i40e: Fix for extra byte
swap in tunnel setup", 2016-08-24), but in a way that makes the result
much more clear to the reader.
Fixes: b3f5c7bc88ba ("i40e: Fix for extra byte swap in tunnel setup", 2016-08-24) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Williams, Mitch A <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit fe0b0cd97b4f210ecd1693edba6eec10820e11f2) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Harshitha Ramamurthy [Fri, 3 Feb 2017 18:57:42 +0000 (10:57 -0800)]
i40e: rename auto_disable_flags to hw_disabled_flags
A previous commit introduced a field that tracks the features
that are disabled due to HW resource limitations as opposed
to the featured disabled by the user. This patch changes the
name of the field to make it more readable since it might get
confusing when looking at code containing both the flags
field and the auto_disable_features field together.
Change-ID: Idcc9888659698f6fe3ccff17c8c3f09b5026f708 Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b77ac975930741f0b6612b18e55d7a72c81ea2ac) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Mon, 30 Jan 2017 20:29:37 +0000 (12:29 -0800)]
i40e/i40evf: Change version from 1.6.27 to 2.1.7
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 15990832cd3e7e8904f8dacdabfa33adb9a836d6) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Mon, 30 Jan 2017 20:29:36 +0000 (12:29 -0800)]
i40e: Allow untrusted VFs to have more filters
Our original filter limit of 8 was based on behavior that we saw from
Linux VMs. Now we're running Other Operating Systems under KVM and we
see that they commonly use more MAC filters. Since it seems weird to
require people to enable trusted VFs just to boot their OS, bump the
number of filters allowed by default.
Change-ID: I76b2dcb2ad6017e39231ad3096c3fb6f065eef5e Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 4dbc56613962bfa597c345d8eff839870293c0a5) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Filip Sadowski [Mon, 30 Jan 2017 20:29:34 +0000 (12:29 -0800)]
i40e: Clarify steps in MAC/VLAN filters initialization routine
This patch clarifies the reason for removal of automatically
firmware-generated filter and explicit addition of filter which
accepts frames with any VLAN id.
Change-ID: Iabf180b6d61c4d8a36d3bcf8457c377a6f2aca0e Signed-off-by: Filip Sadowski <filip.sadowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3954b39102677c879d7663621fb9a7e0da349274) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Lihong Yang [Mon, 30 Jan 2017 20:29:33 +0000 (12:29 -0800)]
i40e: fix RSS queues only operating on PF0
This patch fixes the issue that RSS offloading only works on PF0 by
using the direct register writing of the hash keys for the VFs instead
of using the admin queue command to do so.
Change-ID: Ia02cda7dbaa23def342e8786097a2c03db6f580b Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 26f77e53cfee2b1b066071353be03988897e23c3) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Lihong Yang [Mon, 30 Jan 2017 20:29:32 +0000 (12:29 -0800)]
i40e: fix ethtool to get EEPROM data from X722 interface
Currently ethtool -e will error out with a X722 interface
as its EEPROM has a scope limit at offset 0x5B9FFF.
This patch fixes the issue by setting the EEPROM length to
the scope limit to avoid NVM read failure beyond that.
Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372 Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit c271dd6c391b535226cf1a81aaad9f33cb5899d3) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Tue, 24 Jan 2017 18:24:01 +0000 (10:24 -0800)]
i40e: don't add more vectors to num_lan_msix than number of CPUs
This is a solution to avoid adding too many queues to num_lan_msix.
A recent refactor of queue pairs accidentally added all remaining
vectors to the num_lan_msix which can have adverse performance issues,
due to enabling more queues than the number of CPU cores.
This patch removes the old calculation, and replaces it with a simple
algorithm.
1) add queue pairs up to num_online_cpus(), but capped at half of total
vectors
2) then add alternative features such as flow directory and similar
3) finally, add the remaining vectors back to queue pairs, but capped
such that the total number of queue pairs does not exceed
num_online_cpus().
Change-ID: I668abf67d5011a1248866daba8885f4ff00cb8d9 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit c0cf70a6fc373570f86c6dc4799d775363b9946e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Tue, 24 Jan 2017 18:24:00 +0000 (10:24 -0800)]
i40e: KISS the client interface
(KISS is Keep It Simple, Stupid. Or is it?)
The client interface vastly overengineered for what it needs to do.
It was originally designed to support multiple clients on multiple
netdevs, possibly even with multiple drivers. None of this happened,
and now we know that there will only ever be one client for i40e
(i40iw) and one for i40evf (i40iwvf). So, time for some KISS. Since
i40e and i40evf are a Dynasty, we'll simplify this one to match the
VF interface.
First, be a Destroyer and remove all of the lists and locks required
to support multiple clients. Keep one static around to keep track of
one client, and track the client instances for each netdev in the
driver's pf (or adapter) struct. Now it's Almost Human.
Since we already know the client type is iWarp, get rid of any checks
for this. Same for VSI type - it's always going to be the same type,
so it's just a Parasite.
While we're at it, fix up some comments. This makes the function
headers actually match the functions.
These changes reduce code complexity, simplify maintenance,
squash some lurking timing bugs, and allow us to Rock and Roll All
Nite.
Change-ID: I1ea79948ad73b8685272451440a34507f9a9012e Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 0ef2d5afb12d379f4dd5df696219a01b88bb778a)
Conflict resolved:
drivers/net/ethernet/intel/i40e/i40e_main.c Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Shannon Nelson [Tue, 24 Jan 2017 18:23:58 +0000 (10:23 -0800)]
i40e: fix up recent proxy and wol bits for X722_SUPPORT
Some opcodes added & reordered to be in numerical order with the
rest of the opcodes.
This patch adds admin queue structs to support Wake on LAN feature
for X722.
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d60be2ca9c42e127702a8fd556d696b101f3c09b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Aaron Salter [Fri, 2 Dec 2016 20:33:02 +0000 (12:33 -0800)]
i40e: Acquire NVM lock before reads on all devices
Acquire NVM lock before reads on all devices. Previously, locks were
only used for X722 and later. Fixes an issue where simultaneous X710
NVM accesses were interfering with each other.
Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638 Signed-off-by: Aaron Salter <aaron.k.salter@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 96a39aed25e6559b160786117df124084feb9080) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Masahiro Yamada [Mon, 27 Feb 2017 22:29:06 +0000 (14:29 -0800)]
scripts/spelling.txt: add "varible" pattern and fix typo instances
Fix typos and add the following to the scripts/spelling.txt:
varible||variable
While we are here, tidy up the comment blocks that fit in a single line
for drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c and
net/sctp/transport.c.
Benjamin Poirier [Fri, 13 Jan 2017 01:04:14 +0000 (17:04 -0800)]
i40e: Invoke softirqs after napi_reschedule
The following message is logged from time to time when using i40e:
NOHZ: local_softirq_pending 08
i40e may schedule napi from a workqueue. Afterwards, softirqs are not run
in a deterministic time frame. The problem is the same as what was
described in commit ec13ee80145c ("virtio_net: invoke softirqs after
__napi_schedule") and this patch applies the same fix to i40e.
Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 83a0c6e589017ce737720b9e05e2fa3fe4f7b860) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Carolyn Wyborny [Wed, 21 Dec 2016 23:04:47 +0000 (18:04 -0500)]
i40e: remove duplicate device id from PCI table
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit ee847d935156b041679ad82c269796dae1afaa6b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:17 +0000 (15:44 -0800)]
i40e: mark the value passed to csum_replace_by_diff as __wsum
Fix, or rather, avoid a sparse warning caused by the fact that
csum_replace_by_diff expects to receive a __wsum value. Since the
calculation appears to work, simply typecast the passed paylen value to
__wsum to avoid the warning.
This seems pretty fishy since __wsum was obviously annotated as
a separate type on purpose, so this throws the entire calculation into
question. Since it currently appears to behave as expected, the typecast
is probably safe.
Change-ID: I4fdc5cddd589abc16098176e8a61127e761488f4 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b9c015d421946fe3675fcb9cbacd0a37f1d3263c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Harshitha Ramamurthy [Mon, 12 Dec 2016 23:44:16 +0000 (15:44 -0800)]
i40e: Error handling for link event
There exists an intermittent bug which causes the 'Link Detected'
field reported by the 'ethtool <iface>' command to be 'Yes' when
in fact, there is no link. This patch fixes the problem by
enabling temporary link polling when i40e_get_link_status returns
an error. This causes the driver to remember that an admin queue
command failed and polls, until the function returns with a success.
Change-Id: I64c69b008db4017b8729f3fc27b8f65c8fe2eaa0 Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit ae13670824d5adadc95a881ebfaa6fa8735218f0) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:15 +0000 (15:44 -0800)]
i40e: properly convert le16 value to CPU format
This ensures that the pvid which is stored in __le16 format is converted
to the CPU format. This will fix comparison issues on Big Endian
platforms.
Change-ID: I92c80d1315dc2a0f9f095d5a0c48d461beb052ed Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 5cb259016b4258d7ac53588a01d17da1ceda84b7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:14 +0000 (15:44 -0800)]
i40e: convert to cpu from le16 to generate switch_id correctly
On Big Endian platforms we would incorrectly calculate the wrong switch
id since we did not properly convert the le16 value into CPU format.
Caught by sparse.
Change-ID: I69a2f9fa064a0a91691f7d0e6fcc206adceb8e36 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 2ae0bf501425cbddc8b992a2b65fc04d911cae8c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Mon, 12 Dec 2016 23:44:13 +0000 (15:44 -0800)]
i40e: refactor AQ CMD buffer debug printing
This patch refactors the '%*ph' printk format specifier to instead use
the print_hex_dump function, as recommended by the '%*ph' documentation.
This produces better/more standardized output.
Change-ID: Id56700b4e8abc40ff8c04bc8379e7df04cb4d6fd Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 773d4023badee2e196f4125a94fe9d5a739720a0) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Carolyn Wyborny [Mon, 12 Dec 2016 23:44:12 +0000 (15:44 -0800)]
i40e: Fix Adaptive ITR enabling
This patch fixes a bug introduced with the addition of the per queue
ITR feature support in ethtool. With that addition, there were
functions added which converted the ITR settings to binary values.
The IS_ENABLED macros that run on those values check whether a bit
is set or not and with the value being binary, the bit check always
returned ITR disabled which prevents any updating of the ITR rate.
This patch fixes the problem by changing the functions to return the
current ITR value instead and renaming it to better reflect
its function. These functions now provide a value which will be
accurately asessed and update the ITR as intended.
Change-ID: I14f1d088d052e27f652aaa3113e186415ddea1fc Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3c234c4709529298498b597bcff35f56ac866a99) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Mon, 12 Dec 2016 23:44:11 +0000 (15:44 -0800)]
i40evf: add comment
Add a comment to reduce confusion.
Change-ID: I3d5819c0f3f5174680442ae54398a073d4a61f4f Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 51f38262669b88b6f5ec52cb93dc72c58d85dc1f) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Mon, 12 Dec 2016 23:44:10 +0000 (15:44 -0800)]
i40evf: free rings in remove function
When the i40evf_remove() calls netdev close, the device doesn't actually
close - it schedules the work for the watchdog to perform. Since we're
stopping the watchdog, this work doesn't get done. However, we're
resetting the part, so we can free resources after the reset request has
gone through. This plugs a memory leak.
Change-ID: Id5335dcaf76ce00d2a4c3d26e9faf711d7f051cf Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 8a68badd12a8b708a02d54cd5aac4d07851a6d5a) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:09 +0000 (15:44 -0800)]
i40e: remove unnecessary call to i40e_update_link_info
This call is made just prior to running i40e_link_event. In
i40e_link_event, we set hw->phy.get_link_info to true just prior to
calling i40e_get_link_status, which conveniently runs
i40e_update_link_info for us. Thus, we are running i40e_update_link_info
twice, which seems like something we don't need to do...
Change-ID: I36467a570f44b7546d218c99e134ff97c2709315 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 03aa268b146127361c206fe3942add2adf6ce1d7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Joshua Hay [Mon, 12 Dec 2016 23:44:08 +0000 (15:44 -0800)]
i40e: enable mc magic pkt wakeup during power down
This patch adds a call to the mac_address_write admin q function during
power down to update the PRTPM_SAH/SAL registers with the MC_MAG_EN bit
thus enabling multicast magic packet wakeup.
A FW workaround is needed to write the multicast magic wake up enable
bit in the PRTPM_SAH register. The FW expects the mac address write
admin q cmd to be called first with one of the WRITE_TYPE_LAA flags
and then with the multicast relevant flags.
*Note: This solution only works for X722 devices currently. A PFR will
clear the previously mentioned bit by default, but X722 has support for a
WOL_PRESERVE_ON_PFR flag which prevents the bit from being cleared. Once
other devices support this flag, this solution should work as well.
Change-ID: I51bd5b8535bd9051c2676e27c999c1657f786827 Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 1d68005db4e72082f3e537d6c0cf831a71a7e2ee) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Mon, 12 Dec 2016 23:44:07 +0000 (15:44 -0800)]
i40e: fix disable overflow promiscuous mode
There exists a bug in which the driver is unable to exit overflow
promiscuous mode after having added "too many" mac filters. It is
expected that after triggering overflow promiscuous, removing the
failed/extra filters should then disable overflow promiscuous mode.
The bug exists because we were intentionally skipping the sync_vsi_filter
path in cases where we were removing failed filters since they shouldn't
have been added to the firmware in the first place, however we still
need to go through the sync_vsi_filter code path to determine whether or
not it is ok to exit overflow promiscuous mode. This patch fixes the
bug by making sure we go through the sync_vsi_filter path in cases of
failed filters.
Change-ID: I634d249ca3e5fa50729553137c295e73e7722143 Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit a410c821c0cf50bc0b73a91435852cd04b2c7acd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Henry Tieman [Fri, 2 Dec 2016 20:33:01 +0000 (12:33 -0800)]
i40e: Save more link abilities when using ethtool
Ethtool support needs to save more PHY information. The
added information includes FEC capabilities and 25G link
types. Without this change it is possible to lose 25G or
FEC settings by using ethtool.
Change-ID: Ie42255b1e901ffbf9583b8c46466a54894114280 Signed-off-by: Henry Tieman <henry.w.tieman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b7eaf8f16e87c3896e9b8c0b2e54d71210d43b48) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:33:00 +0000 (12:33 -0800)]
i40e: avoid race condition when sending filters to firmware for addition
Refactor how we add new filters to firmware to avoid a race condition
that can occur due to removing filters from the hash temporarily.
To understand the race condition, suppose that you have a number of MAC
filters, but have not yet added any VLANs. Now, add two VLANs in rapid
succession. A possible resulting flow would look something like the
following:
(1) lock hash for add VLAN
(2) add the new MAC/VLAN combos for each current MAC filter
(3) unlock hash
(4) lock hash for filter sync
(5) notice that we have a VLAN, so prepare to update all MAC filters
with VLAN=-1 to be VLAN=0.
(6) move NEW and REMOVE filters to temporary list
(7) unlock hash
(8) lock hash for add VLAN
(9) add new MAC/VLAN combos. Notice that no MAC filters are currently in
the hash list, so we don't add any VLANs <--- BUG!
(10) unlock hash
(11) sync the temporary lists to firmware
(12) lock hash for post-sync
(13) move the temporary elements back to the main list
....
Because we take filters out of the main hash into temporary lists, we
introduce a narrow window where it is possible that other callers to the
list will not see some of the filters which were previously added but
have not yet been finalized. This results in sometimes dropping VLAN
additions, and could also result in failing to add a MAC address on the
newly added VLAN.
One obvious way to avoid this race condition would be to lock the entire
firmware process. Unfortunately this does not work because adminq
firmware commands take a mutex which results in a sleep while atomic
BUG(). So, we can't use the simplest approach.
An alternative approach is to simply not remove the filters from the
hash list while adding. Instead, add an i40e_new_mac_filter structure
which we will use to track added filters. This avoids the need to remove
the filter from the hash list. We'll store a pointer to the original
i40e_mac_filter, along with our own copy of the state.
We won't update the state directly, so as to avoid race with other code
that may modify the state while under the lock. We are safe to read
f->macaddr and f->vlan since these only change in two locations. The
first is on filter creation, which must have already occurred. The
second is inside i40e_correct_vlan_filters which was previously run
after creation of this object and can't be run again until after. Thus,
we should be safe to read the MAC address and VLAN while outside the
lock.
We also aren't going to run into a use-after-free issue because the only
place where we free filters is when they are marked FAILED or when we
remove them inside the sync subtask. Since the subtask has its own
critical flag to prevent duplicate runs, we know this won't happen. We
also know that the only location to transition a filter from NEW to
FAILED is inside the subtask also, so we aren't worried about that
either.
Use the wrapper i40e_new_mac_filter for additions, and once we've
finalized the addition to firmware, we will update the filter state
inside a lock, and then free the wrapper structure.
In order to avoid a possible race condition with filter deletion, we
won't update the original filter state unless it is still
I40E_FILTER_NEW when we finish the firmware sync.
This approach is more complex, but avoids race conditions related to
filters being temporarily removed from the list. We do not need the same
behavior for deletion because we always unconditionally removed the
filters from the list regardless of the firmware status.
Change-Id: I14b74bc2301f8e69433fbe77ebca532db20c5317 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 671889e6740ac7ab84d1420525b50d1d47001102) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:32:59 +0000 (12:32 -0800)]
i40e: allow i40e_update_filter_state to skip broadcast filters
Fix a bug where we modified the mac_filter_hash while outside a lock,
when handling addition of broadcast filters.
Normally, we add filters to firmware by batching the additions into
lists and issuing 1 update for every few filters. Broadcast filters are
handled differently, by instead setting the broadcast promiscuous mode
flags. In order to make sure the 1<->1 mapping of filters in our
addition array lined up with filters in the hlist tmp_add_list, we had
to remove the filter and move it back to the main hash. However, we
didn't do this under lock, which could cause consistency problems for
the list.
Fix this by updating i40e_update_filter_state logic so that it knows to
avoid broadcast filters. This ensures that we don't have to remove the
filter separately, and can put it back using the normal flow.
Change-ID: Id288fade80b3e3a9a54b68cc249188cb95147518 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d88d40b01c5c0dad6a1dca3b18267849eef4a2a9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:32:58 +0000 (12:32 -0800)]
i40e: don't warn every time we clear an Rx timestamp register
The intent of this message was to indicate to a user that we might have
missed a timestamp event for a valid packet. The original method of
detecting the missed events relied on waiting until all 4 registers were
filled.
A recent commit d55458c0cd7a5 ("i40e: replace PTP Rx timestamp hang
logic") replaced this logic with much better detection
scheme that could detect a stalled Rx timestamp register even when other
registers were still functional.
The new logic means that a message will be displayed almost as soon as
a timestamp for a dropped frame occurs. This new logic highlights that
the hardware will attempt timestamp for frames which it later decides to
drop. The most prominent example is when a multicast PTP frame is
received on a multicast address that we are not subscribed to.
Because the hardware initiates the Rx timestamp as soon as possible, it
will latch an RXTIME register, but then drop the packet.
This results in users being confused by the message as they are not
expecting to see dropped timestamp messages unless their application
also indicates that timestamps were missing.
Resolve this by reducing the severity and frequency of the displayed
message. We now only print the message if 3 or 4 of the RXTIME registers
are stalled and get cleared within the same watchdog event. This ensures
that the common case does not constantly display the message.
Additionally, since the message is likely not as meaningful to most
users, reduce the message to a dev_dbg instead of a dev_warn.
Users can still get a count of the number of timestamps dropped by
reading the ethtool statistics value, if necessary.
Change-ID: I35494442226a444c418dfb4f91a3070d06c8435c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e6e3fc2bd3ee03117e1ce388c897fc3b2da97d65) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Henry Tieman [Fri, 2 Dec 2016 20:32:57 +0000 (12:32 -0800)]
i40e: Save link FEC info from link up event
Store the FEC status bits from the link up event into the
hw_link_info structure.
Change-ID: I9a7b256f6dfb0dce89c2f503075d0d383526832e Signed-off-by: Henry Tieman <henry.w.tieman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3e03d7ccf4418c87a134bbfa79c05090296767f7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Sudheer Mogilappagari [Fri, 10 Feb 2017 07:58:22 +0000 (23:58 -0800)]
i40e: Add bus number info to i40e_bus_info struct
Currently i40e_bus_info has PCI device and function info only and log
messages print device number as bus number. Added field to provide bus
number info and modified log statements to print bus, device and
function information.
Change-ID: I811617cee2714cc0d6bade8d369f57040990756f Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b3f028fc8abdf72c6ed1103e60e89dd60538f126) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 10 Feb 2017 07:46:50 +0000 (23:46 -0800)]
i40e: Clean up dead code
The function i40e_client_prepare() can never return an error. So make it
void and quit checking its return value.
Change-ID: I9ff311e2324dde329eb68648efb2c94aaff856db Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3bb83baf9ac9c73f4da051cae17042f264832e61) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 29 Nov 2016 00:06:11 +0000 (16:06 -0800)]
i40e/i40evf : Changed version from 1.6.25 to 1.6.27
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit cfffef76e7fa5b9ac3ec8298336d0265bc86af3c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 10 Feb 2017 07:44:27 +0000 (23:44 -0800)]
i40e: update comment explaining where FDIR buffers are freed
The original comment implies that the only location where the raw_packet
buffer will be freed is in i40e_clean_tx_ring() which is incorrect. In
fact this isn't even the normal case. Update the comment explaining
where the memory is freed.
Change-ID: Ie0defc35ed1c3af183f81fdc60b6d783707a5595 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit a158aeaf5bb5b014240b360693751476aca7440b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:43:30 +0000 (23:43 -0800)]
i40e/i40evf: eliminate i40e_pull_tail()
Reorganize the i40e_pull_tail() logic, doing it in i40e_add_rx_frag()
where it's cheaper. The igb driver does this the same way.
Also renames i40e_page_is_reserved() to reflect what it actually
tests.
Change-ID: Icd9cc507aae1fcdc02308b3a09034111b4c24071 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9b37c937313bf6769d0b018ca35180b379d40862) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:40:25 +0000 (23:40 -0800)]
i40e/i40evf: Moves skb from i40e_rx_buffer to i40e_ring
This patch reduces the size of struct i40e_rx_buffer by one pointer,
and makes the i40e driver a little more consistent with the igb driver
in terms of packets that span buffers.
We do this by moving the skb field from struct i40e_rx_buffer to
struct i40e_ring. We pass the skb we already have (or NULL if we
don't) to i40e_fetch_rx_buffer(), which skips the skb allocation if we
already have one for this packet.
Change-ID: I4ad48a531844494ba0c5d8e1a62209a057f661b0 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e72e56597ba15ce70f4fc1eb2ceeaa8da0d4ab5e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:37:28 +0000 (23:37 -0800)]
i40e/i40evf: Limit DMA sync of RX buffers to actual packet size
On packet RX, we perform a DMA sync for CPU before passing the
packet up. Here we limit that sync to the actual length of the
incoming packet, rather than always syncing the entire buffer.
Change-ID: I626aaf6c37275a8ce9e81efcaa773f327b331487 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7987dcd7b95111a5acbf5abdbf155eedacd3546b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 10 Feb 2017 07:35:18 +0000 (23:35 -0800)]
i40evf: track outstanding client request
The iWarp client cannot continue until this operation has been completed
by the PF driver. Sleep (with timeout) until the reply from the PF
driver has been received.
Change-ID: I5dc41b857bba32d0218b7ce167b5da122dadf349 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e5f77f4a2ff2d6ce2d973ebc62084d92f203c9f6) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 10 Feb 2017 07:29:13 +0000 (23:29 -0800)]
i40e: don't check params until after checking for client instance
We can avoid the minor bit of work by calling check params after we
check for the client instance, since we're about to return early in
cases where we do not have a client.
Change-ID: I56f8ea2ba48d4f571fa331c9ace50819a022fa1c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d7ce6422d6e64502d9f6acff9a4466e2ddb64721) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Tue, 29 Nov 2016 00:06:03 +0000 (16:06 -0800)]
i40e: add interrupt rate limit verbosity
Due to the resolution of the register controlling interrupt rate
limiting, setting certain values for the interrupt rate limit make it
appear as though the limiting is not completely accurate. The problem
is that the interrupt rate limit is getting rounded down to the nearest
multiple of 4. This patch fixes the problem by adding some feedback to
the user as to the actual interrupt rate limit being used when it
differs from the requested limit. Without this patch setting interrupt
rate limits may appear to behave inaccurately.
Change-ID: I3093cf3f2d437d35a4c4f4bb5af5ce1b85ab21b7 Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 33084060fb6d51ff566439a387f69ed90301280c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Tue, 29 Nov 2016 00:06:02 +0000 (16:06 -0800)]
i40e: refactor macro INTRL_USEC_TO_REG
This patch refactors the macro INTRL_USEC_TO_REG into a static inline
function and fixes a couple subtle bugs caused by the macro.
This patch fixes a bug which was caused by passing a bad register value
to the firmware. If enabling interrupt rate limiting, a non-zero value
for the rate limit must be used. Otherwise the firmware sets the
interrupt rate limit to the maximum value. Due to the limited
resolution of the register, attempting to set a value of 1, 2, or 3
would be rounded down to 0 and limiting was left enabled, causing
unexpected behavior.
This patch also fixes a possible bug in which using the macro itself can
introduce unintended side-affects because the macro argument is used
more than once in the macro definition (e.g. a variable post-increment
argument would perform a double increment on the variable).
Without this patch, attempting to set interrupt rate limits of 1, 2, or
3 results in unexpected behavior and future use of this macro could
cause subtle bugs.
Change-Id: I83ac842de0ca9c86761923d6e3a4d7b1b95f2b3f Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 1c0e6a3613d3f0bb088a3160095c8da4c1214d02) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Tue, 29 Nov 2016 00:06:01 +0000 (16:06 -0800)]
i40e: remove unused function
After refactoring the client open and close code, this is no longer
needed. Remove it.
Change-ID: If8e6e32baa354d857c2fd8b2f19404f1786011c4 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 04766b22cf805011620f546384b271586548e8a7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jayaprakash Shanmugam [Tue, 29 Nov 2016 00:06:00 +0000 (16:06 -0800)]
i40e: Remove FPK HyperV VF device ID
Requirement for VFs to use the VMBus has been removed that's why
removing Hyper-V VF device ID.
Change-ID: I84f0964f443ee0db3e5e444b5ace996eb71b8280 Signed-off-by: Jayaprakash Shanmugam <jayaprakash.shanmugam@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 11131e2b8e9454f79ebfc71e45fe246948ce4997) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alexander Duyck [Tue, 29 Nov 2016 00:05:59 +0000 (16:05 -0800)]
i40e: Quick refactor to start moving data off stack and into Tx buffer info
This patch does some quick work to pull some of the data off of the stack
and hopefully start storing it in the Tx buffer info section of the Tx
ring. Ideally we should be moving away from having to store much of
anything on the stack and can just maintain it all in the descriptor rings.
Change-ID: I4b4715ea1920e122502482b3f9e56a9a6cb1e9fe Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 52ea3e802047552a8c1ec8c42cad361ffd4ca09c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Tushar Dave [Sat, 19 Nov 2016 21:53:58 +0000 (13:53 -0800)]
i40e: remove unnecessary __packed
'struct i40e_dma_mem' defined with 'packed' directive causing kernel
unaligned errors on sparc.
e.g.
i40e: Intel(R) Ethernet Connection XL710 Network Driver - version
1.6.16-k
i40e: Copyright (c) 2013 - 2014 Intel Corporation.
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
Kernel unaligned access at TPC[44894c] dma_4v_alloc_coherent+0x1ac/0x300
i40e 0000:03:00.0: fw 5.1.40981 api 1.5 nvm 5.04 0x80002548 0.0.0
This can be fixed with get_unaligned/put_unaligned(). However no
reference in driver shows that 'struct i40e_dma_mem' directly shoved
into NIC hardware. But instead fields of the struct are being read and
used for hardware. Therefore, __packed is unnecessary for 'struct
i40e_dma_mem'.
In addition, although 'struct i40e_virt_mem' doesn't cause any
unaligned access, keeping it packed is unnecessary as well because
of aforementioned reason.
This change make 'struct i40e_dma_mem' and 'struct i40e_virt_mem'
unpacked.
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9588397d24eecb7298bce9307b589a5bc0ccafdd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 11 Nov 2016 20:39:39 +0000 (12:39 -0800)]
i40evf: remove unused device ID
This device ID was intended for use when running Linux VF drivers under
Hyper-V, but we have determined that it is not necessary. Since it is
unused, and will never be used, remove it.
Change-ID: I74998ab4237db043cd400547bb54a0a5e2a37ea5 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 17901e1bde9b959b535d075f137d5a86ca64f1c9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Fri, 11 Nov 2016 20:39:38 +0000 (12:39 -0800)]
i40e: Deprecating unused macro
I40E_MAC_X710 was supposed to be for 10G and I40E_MAC_XL710
was supposed to be for 40G. But function i40e_is_mac_710
sets I40E_MAC_XL710 for all device IDS, I40E_MAC_X710 is not
used at all. As there is nothing to compare there is no need
for this function. Thus deprecating this extra macro and
removing this function entirely and replacing it with a direct
check.
Change-ID: I7d1769954dccd574a290ac04adb836ebd156730e Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 6de432c5ae28e7330e14e85c4c614a67a0a12263) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:37 +0000 (12:39 -0800)]
i40e: when adding or removing MAC filters, correctly handle VLANs
Instead of using i40e_add_filter or i40e_del_filter directly, when
adding a MAC address, we should normally be using i40e_add_mac_filter or
i40e_del_mac_filter. These functions correctly handle the various cases
of VLAN mode or PVID settings. This ensures consistency and avoids the
issues that can occur with the recent addition of a WARN_ON() in
i40e_sync_vsi_filters.
Change-ID: I7fe62db063391fdd1180b2d6a6a3c5ab4307eeee Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9569a9a4547d5636827c3f6b09be73ed924b1d16) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:36 +0000 (12:39 -0800)]
i40e: avoid O(n^2) loop when deleting all filters
Use __i40e_del_filter instead of using i40e_del_filter() which will
avoid doing an additional search to delete a filter we already have the
pointer for.
Change-ID: Iea5a7e3cafbf8c682ed9d3b6c69cf5ff53f44daf Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 148141bb26cf942e6bc7249c55d9958dd62dd4f2) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:35 +0000 (12:39 -0800)]
i40e: rename i40e_put_mac_in_vlan and i40e_del_mac_all_vlan
These functions purpose is to add a new MAC filter correctly, whether
we're using VLANs or not. Their goal is to ensure that all active VLANs
get the new MAC filter. Rename them so that their intent is clear. They
function correctly regardless of whether we have any active VLANs or
only have I40E_VLAN_ANY filters. The new names convey how they function
in a more clear manner.
Change-ID: Iec1961f968c0223a7132724a74e26a665750b107 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit feffdbe47d6f4c02b5e2764e14490c5f9d250bdb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:34 +0000 (12:39 -0800)]
i40e: no need to check is_vsi_in_vlan before calling i40e_del_mac_all_vlan
This function won't be appreciably slower when in VLAN mode, so there is
no real reason to not just call it directly. In either case, we still
must search the full table for a MAC/VLAN pair. We do get to stop
searching a tiny bit early in the case of knowing we are not in VLAN
mode, but this is a minor savings and we can avoid the code complexity
by not having to worry about the check.
Change-ID: I533412195b3a42f51cf629e3675dd5145aea8625 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d983001f044cf823490af7dcfcde39cfb42be0db) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:33 +0000 (12:39 -0800)]
i40e: fold the i40e_is_vsi_in_vlan check into i40e_put_mac_in_vlan
Fold the check for determining when to call i40e_put_mac_in_vlan directly
into the function so that we don't need to decide which function to use
ahead of time. This allows us to just call i40e_put_mac_in_vlan directly
without having to check ahead of time.
Change-ID: Ifff526940748ac14b8418be5df5a149502eed137 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7aaf9536c45021772a5bc6cd4b620a11eac750f7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Wed, 7 Dec 2016 22:05:34 +0000 (14:05 -0800)]
i40e: don't allow i40e_vsi_(add|kill)_vlan to operate when VID<1
Now that we have the separate i40e_(add|rm)_vlan_all_mac functions, we
should not be using the i40e_vsi_kill_vlan or i40e_vsi_add_vlan
functions when PVID is set or when VID is less than 1. This allows us to
remove some checks in i40e_vsi_add_vlan and ensures that callers which
need to handle VID=0 or VID=-1 don't accidentally invoke the VLAN mode
handling used to convert filters when entering VLAN mode. We also update
the functions to take u16 instead of s16 as well since they no longer
expect to be called with VID=I40E_VLAN_ANY.
Change-ID: Ibddf44a8bb840dde8ceef2a4fdb92fd953b05a57 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit f94484b7584765eebded5d7bfdeb0b2c7b1caf51) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 8 Nov 2016 21:05:19 +0000 (13:05 -0800)]
i40e: Changed version from 1.6.21 to 1.6.25
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 360238693d2bc93fb6ff73146ed358e84fe67961) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Sowmini Varadhan [Wed, 7 Jun 2017 21:09:38 +0000 (14:09 -0700)]
rds: tcp: fix memory leak in TIME_WAIT sockets
Due to a toxic cocktail of an endian-ness bug, plus some other changes
in mprds to make sure that the side with the numerically smaller address
must initiate the tcp connection, end result is an infinite connection
attempt and a memory leak in TIME_WAIT sockets.
Sowmini Varadhan [Wed, 31 May 2017 19:11:20 +0000 (12:11 -0700)]
rds: tcp: canonical connection order for all paths with index > 0
The rds_connect_worker() has a bug in the check that enforces the
canonical connection order described in the comments of
rds_tcp_state_change(). The intention is to make sure that all
the multipath connections are always initiated by the smaller IP
address via rds_start_mprds. To achieve this, rds_connection_worker
should check that cp_index > 0.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sowmini Varadhan [Wed, 31 May 2017 19:08:34 +0000 (12:08 -0700)]
rds: tcp: allow progress of rds_conn_shutdown if the rds_connection is marked ERROR by an intervening FIN
rds_conn_shutdown() runs in workq context, and marks the rds_connection
as DISCONNECTING before quiescing Tx/Rx paths. However, after all I/O
has quiesced, we may still find the rds_connection state to be
RDS_CONN_ERROR if an intervening FIN was processed in softirq context.
This is not a fatal error: rds_conn_shutdown() should continue the
shutdown, and there is no need to log noisy messages about this event.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wei Lin Guay [Wed, 7 Dec 2016 08:08:09 +0000 (09:08 +0100)]
IB/cm: remove unnecessary ib_query_device in PSIF RNR WA
The query device is performed in CM REQ/REP to retrieve the
vendorID of the sif device. This operation is illegal because
it is calling a sleeping function (ib_query_device) from
a non-sleepable context. Thus, this patch removes this illegal
call and reuses the cached vendorID/DeviceID in the pci_dev
data structure.
James Smart [Fri, 21 Apr 2017 23:05:05 +0000 (16:05 -0700)]
Fix Express lane queue creation.
The older sli4 adapters only supported the 64 byte WQE entry size.
The new adapter (fw) support both 64 and 128 byte WQE entry sizies.
The Express lane WQ was not being created with the 128 byte WQE sizes
when it was supported.
Not having the right WQE size created for the express lane work queue
caused the the firmware to overwrite the lun indentifier in the FCP header.
This patch correctly creates the express lane work queue with the
supported size.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
(cherry picked from commit 7e04e21afa82ef024416f5413b5bdb66e0505bcd)
Hou Tao [Fri, 3 Feb 2017 22:39:07 +0000 (14:39 -0800)]
xfs: reset b_first_retry_time when clear the retry status of xfs_buf_t
After successful IO or permanent error, b_first_retry_time also
needs to be cleared, else the invalid first retry time will be
used by the next retry check.
Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
(cherry picked from commit 4dd2eb633598cb6a5a0be2fd9a2be0819f5eeb5f)
Carlos Maiolino [Wed, 4 Jan 2017 04:34:17 +0000 (20:34 -0800)]
xfs: fix max_retries _show and _store functions
max_retries _show and _store functions should test against cfg->max_retries,
not cfg->retry_timeout
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
(cherry picked from commit ff97f2399edac1e0fb3fa7851d5fbcbdf04717cf)
Eric Sandeen [Tue, 13 Sep 2016 21:51:30 +0000 (07:51 +1000)]
xfs: normalize "infinite" retries in error configs
As it stands today, the "fail immediately" vs. "retry forever"
values for max_retries and retry_timeout_seconds in the xfs metadata
error configurations are not consistent.
A retry_timeout_seconds of 0 means "retry forever," but a
max_retries of 0 means "fail immediately."
retry_timeout_seconds < 0 is disallowed, while max_retries == -1
means "retry forever."
Make this consistent across the error configs, such that a value of
0 means "fail immediately" (i.e. wait 0 seconds, or retry 0 times),
and a value of -1 always means "retry forever."
This makes retry_timeout a signed long to accommodate the -1, even
though it stores jiffies. Given our limit of a 1 day maximum
timeout, this should be sufficient even at much higher HZ values
than we have available today.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 77169812739dd800bc3620d781a77c50c75165cc)
Eric Sandeen [Wed, 20 Jul 2016 00:54:09 +0000 (10:54 +1000)]
xfs: don't reset b_retries to 0 on every failure
With the code as it stands today, b_retries never increments because
it gets reset to 0 in the error callback.
Remove that, and fix a similar problem where the first retry time
was constantly being overwritten, which defeated the timeout tunable
as well. We now only set first retry time if a non-zero timeout is
set, to match the behavior of only incrementing retries if a retry
value is set.
This way max retries & timeouts consistently take effect after a
tunable is set, rather than acting retroactively on a buffer which
has failed at some point in the past and has accumulated state from
those prior failures.
Thanks to dchinner for talking through this with me.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 5539d36752eb789f4067a9f88e72177895d56317)
Eric Sandeen [Wed, 20 Jul 2016 00:48:51 +0000 (10:48 +1000)]
xfs: fix xfs_error_get_cfg for negative errnos
xfs_error_get_cfg() is called with bp->b_error as an arg, which is
negative, so the switch statement won't ever find any matches.
This results in only the default error handler having any effect, as
EIO/ENOSPC/ENODEV get ignored due to the wrong sign.
It seems simplest to always flip the error sign to positive, so that
we can handle either negative errors in bp->b_error, or possibly a
positive errno via something like xfs_error_get_cfg(EIO) - this
future-proofs the function.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e97f6c545f963abd7de56a58a29ba73a9edee015)
Carlos Maiolino [Wed, 18 May 2016 01:11:27 +0000 (11:11 +1000)]
xfs: add "fail at unmount" error handling configuration
If we take "retry forever" literally on metadata IO errors, we can
hang at unmount, once it retries those writes forever. This is the
default behavior, unfortunately.
Add an error configuration option for this behavior and default it
to "fail" so that an unmount will trigger actuall errors, a shutdown
and allow the unmount to succeed. It will be noisy, though, as it
will log the errors and shutdown that occurs.
To fix this, we need to mark the filesystem as being in the process
of unmounting. Do this with a mount flag that is added at the
appropriate time (i.e. before the blocking AIL sync). We also need
to add this flag if mount fails after the initial phase of log
recovery has been run.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e6b3bb78962e65c4ad125598755cfbf2a8779e86)
Carlos Maiolino [Wed, 18 May 2016 01:09:28 +0000 (11:09 +1000)]
xfs: add configuration handlers for specific errors
now most of the infrastructure is in place, we can start adding
support for configuring specific errors such as ENODEV, ENOSPC, EIO,
etc. Add these error configurations and configure them all to have
appropriate behaviours. That is, all will be configured to retry
forever by default, except for ENODEV, which is an unrecoverable
error, so it will be configured to not retry on error
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e0a431b3a3cc3d0a4c38ccfca8c7320fde40efb6)
Carlos Maiolino [Wed, 18 May 2016 01:08:15 +0000 (11:08 +1000)]
xfs: add configuration of error failure speed
On reception of an error, we can fail immediately, perform some
bound amount of retries or retry indefinitely. The current behaviour
we have is to retry forever.
However, we'd like the ability to choose how long the filesystem
should try after an error, it can either fail immediately, retry a
few times, or retry forever. This is implemented by using
max_retries sysfs attribute, to hold the amount of times we allow
the filesystem to retry after an error. Being -1 a special case
where the filesystem will retry indefinitely.
Add both a maximum retry count and a retry timeout so that we can
bound by time and/or physical IO attempts.
Finally, plumb these into xfs_buf_iodone error processing so that
the error behaviour follows the selected configuration.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit a5ea70d25d76950e11690110b526374307d05d81)
Carlos Maiolino [Wed, 18 May 2016 01:06:44 +0000 (11:06 +1000)]
xfs: introduce table-based init for error behaviors
Before we start expanding the number of error classes and errors we
can configure behaviour for, we need a simple and clear way to
define the default behaviour that we initialized each mount with.
Introduce a table based method for keeping the initial configuration
in, and apply that to the existing initialization code.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit ef6a50fbb1bba7951aa23adcfb40e99ca72dc51c)
Carlos Maiolino [Wed, 18 May 2016 01:05:33 +0000 (11:05 +1000)]
xfs: add configurable error support to metadata buffers
With the error configuration handle for async metadata write errors
in place, we can now add initial support to the IO error processing
in xfs_buf_iodone_error().
Add an infrastructure function to look up the configuration handle,
and rearrange the error handling to prepare the way for different
error handling conigurations to be used.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit df3093907ccc718459c54c99da29dd774af41186)
Carlos Maiolino [Wed, 18 May 2016 01:01:00 +0000 (11:01 +1000)]
xfs: introduce metadata IO error class
Now we have the basic infrastructure, add the first error class so
we can build up the infrastructure in a meaningful way. Add the
metadata async write IO error class and sysfs entry, and introduce a
default configuration that matches the existing "retry forever"
behavior for async write metadata buffers.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit ffd40ef697dfd3e06f44b1bb5fea93079de8c77d)
Carlos Maiolino [Wed, 18 May 2016 00:58:51 +0000 (10:58 +1000)]
xfs: configurable error behavior via sysfs
We need to be able to change the way XFS behaviours in error
conditions depending on the type of underlying storage. This is
necessary for handling non-traditional block devices with extended
error cases, such as thin provisioned devices that can return ENOSPC
as an IO error.
Introduce the basic sysfs infrastructure needed to define and
configure error behaviours. This is done to be generic enough to
extend to configuring behaviour in other error conditions, such as
ENOMEM, which also has different desired behaviours according to
machine configuration.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 192852be8b5fb14268c2133fe9ce5312e4745963)
Mike Kravetz [Fri, 2 Jun 2017 21:51:12 +0000 (14:51 -0700)]
sparc64: mm: fix copy_tsb to correctly copy huge page TSBs
When a TSB grows beyond its current capacity, a new TSB is allocated
and copy_tsb is called to copy entries from the old TSB to the new.
A hash shift based on page size is used to calculate the index of an
entry in the TSB. copy_tsb has hard coded PAGE_SHIFT in these
calculations. However, for huge page TSBs the value REAL_HPAGE_SHIFT
should be used. As a result, when copy_tsb is called for a huge page
TSB the entries are placed at the incorrect index in the newly
allocated TSB. When doing hardware table walk, the MMU does not
match these entries and we end up in the TSB miss handling code.
This code will then create and write an entry to the correct index
in the TSB. We take a performance hit for the table walk miss and
recreation of these entries.
Pass a new parameter to copy_tsb that is the page size shift to be
used when copying the TSB.
Suggested-by: Anthony Yznaga <anthony.yznaga@oracle.com> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from Linus repo on 7 July 2017
commit 654f4807624a657f364417c2a7454f0df9961734) Reviewed-by: Steve Sistare steven.sistare@oracle.com Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
IB/mlx4: Fix incorrect order of formal and actual parameters
The last two actual parameters when calling id_map_find_by_sl_id()
from id_map_get() are swapped. However, the same formal parameters to
id_map_get() have them swapped as well, inverting the effect of the
first error.
This commit improves readability, but makes no functional change to
the code.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com> Reviewed-by: Knut Omang <knut.omang@oracle.com> Acked-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
(cherry picked from commit b03ee4ca0cec348c84dccf08aaec2454c4d236c2)
Now that we're guaranteed to have a meaningful root dentry, we can just
export seq_dentry() and use it in btrfs_show_options(). The subvolume ID
is easy to get and can also be useful, so put that in there, too.
Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com>
(cherry picked from commit c8d3fe028f64054d75c72566efb9ecf3c75ee161) Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Current sense_len checks for size of cp->sense_buffer which is of type
pointer. Passing truncated sense data(size of pointer) to upper scsi
layers(aula) is causing delay in discovering FC LUN's.
Fixed sense_len assignment to SCSI_SENSE_BUFFERSIZE, this resolved
delay in discovering FC LUN's.
As part of updating NVMe driver (Bug 25130845), the nvme device mapping was done
before getting the nvme device information. This change got introduced while
resolving a merge conflict. This caused the kernel panic during nvme probe.
Signed-off-by: Ashok Vairavan <ashok.vairavan@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Thomas Tai [Fri, 6 Jan 2017 14:18:38 +0000 (06:18 -0800)]
sparc: Fix kernel BUG at arch/sparc/kernel/mdesc.c
When running ldoms reboot test for long hours, ldom guest panic with
kernel BUG at arch/sparc/kernel/mdesc.c:176! It is because the mdesc
size has changed, mdesc_update should retry the operation by decrement
refcnt before mdesc_free.
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-By: Liam Merwick <Liam.Merwick@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-by: Chris Hyser <chris.hyser@oracle.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shamir Rabinovitch [Tue, 14 Mar 2017 16:35:27 +0000 (09:35 -0700)]
sparc64/mlx4_core: relaxed order for mlx4_core dma mappings
SPARC PCI require relaxed order PCI transactions from the HCA to the
host memory to enable maximum performance. CX3 is not capable of setting
the relaxed order for the PCI transactions. Only mlx4_core driver can set
relaxed order on the right DMA mappings. Fix it!
This is temporary fix only for UEK4. Upstream changed the way the IB
subsystem work with DMA and upstreaming of this fix requires first to
fix net-next tree panic when rdma service is started (Orabug 25760394)
and only then upstreaming the fix for the SPARC/CX3 performance issue.
This cannot be done in short time and require back-port of lots of
upstream code introduced with upstream commit: "Merge tag
'for-next-dma_ops' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma".
The current decision is to limit the change to mlx4 drivers and the ULPs
that use it. This patch only override the mlx4 DMA functions as opposed
for doing this from ib_verbs DMA functions.
This patch is already used in UEK2/SPARC and was proven as working under
all the product testing and so it is ported as-is.
IOCTL for ccb submission failed due to get_user_pages error should
return EFAULT instead of EPERM. This was a regression introduced by a
prior patch that cleaned up a few functions in this code path.
Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com>
Anthony Yznaga [Wed, 31 May 2017 19:34:59 +0000 (12:34 -0700)]
sparc64: fix M8 ADI support
For platforms that support ADI two things must be done during boot.
First, etrap is patched to ensure that execution in the kernel runs with
PSTATE.mcde=1. This ensures that version checking is enabled if the
kernel accesses ADI-enabled user memory through copy_{to/from}_user,
etc..
Second, the initialization of the common flags used in TTEs must be
adjusted to not set TTE.cv (cacheable-in-virtually-indexed-cache) which
has been replaced by TTE.mcd which enables MCD (aka ADI).
These steps are currently done for M7. This patch adds support for M8
and does some minor cleanup to avoid M7-specific naming and reduce the
number of places chip type needs to be checked (and adjusted in the
future).
Orabug: 26096575 Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com> Reviewed-by: Steve Sistare <steven.sistare@oracle.com>
Return value check of atomic_dec_if_positive is required as it returns
old value minus one. Without this fix, driver will send small ios to
firmware path and that will be a performance issue.
Not critical, but good to have r1_ldio_hint as default value in sdev
private.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 49524b3c6e12375627ddd870613fcc6b24909898) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
For RAID1 FastPath writes, driver needs to allocate extra commands
internally to accommodate for the extra peer command being sent.
Currently driver is allocating 2 extra commands for each but only one
extra command is necessary. Set RAID_1_10_RMW_CMDS to 2 and also change
macro name to RAID_1_PEER_CMDS.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a73b0a4b5d17ee39b2cbac7638a97077189b80cc) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Fix indentation issues and smatch warning reported by Dan Carpenter
for previous series as discussed below.
http://www.spinics.net/lists/linux-scsi/msg103635.html
http://www.spinics.net/lists/linux-scsi/msg103603.html
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 41064f1bf8886bc43afbd9aa23a698f97bc65664) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
projects / users / jedix / linux-maple.git / log