[Patch] network-i40e:NVM bug fixes (cherrypick from 4.14)

[quanxian]

Description:
Theses two commits need to be cherrypicked from upstream to 4.12/4.13 and integrated into 17.10

Target Kernel: 4.14
Target Release: 17.10

Action: Cherrypick

Here are the two commit id's:

    commit 3c8f3e96af3a6799841761923d000566645f0942
    Author: Jacob Keller <email address hidden>
    Date: Fri Sep 1 13:43:08 2017 -0700

        i40e: point wb_desc at the nvm_wb_desc during i40e_read_nvm_aq

        When introducing the functions to read the NVM through the AdminQ,
    we
        did not correctly mark the wb_desc.

        Fixes: 7073f46e443e ("i40e: Add AQ commands for NVM Update for
    X722", 2015-06-05)
        Signed-off-by: Jacob Keller <email address hidden>
        Tested-by: Andrew Bowers <email address hidden>
        Signed-off-by: Jeff Kirsher <email address hidden>

    commit 09f79fd49d94cda5837e9bfd0cb222232b3b6d9f
    Author: Anjali Singhai Jain <email address hidden>
    Date: Fri Sep 1 13:42:49 2017 -0700

        i40e: avoid NVM acquire deadlock during NVM update

        X722 devices use the AdminQ to access the NVM, and this requires
    taking
        the AdminQ lock. Because of this, we lock the AdminQ during
        i40e_read_nvm(), which is also called in places where the lock is
        already held, such as the firmware update path which wants to lock
    once
        and then unlock when finished after performing several tasks.

        Although this should have only affected X722 devices, commit
        96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices",
        2016-12-02) added locking for all NVM reads, regardless of device
        family.

        This resulted in us accidentally causing NVM acquire timeouts on
    all
        devices, causing failed firmware updates which left the eeprom in
        a corrupt state.

        Create unsafe non-locked variants of i40e_read_nvm_word and
        i40e_read_nvm_buffer, __i40e_read_nvm_word and
    __i40e_read_nvm_buffer
        respectively. These variants will not take the NVM lock and are
    expected
        to only be called in places where the NVM lock is already held if
        needed.

        Since the only caller of i40e_read_nvm_buffer() was in such a path,
        remove it entirely in favor of the unsafe version. If necessary we
    can
        always add it back in the future.

        Additionally, we now need to hold the NVM lock in
    i40e_validate_checksum
        because the call to i40e_calc_nvm_checksum now assumes that the NVM
    lock
        is held. We can further move the call to read
    I40E_SR_SW_CHECKSUM_WORD
        up a bit so that we do not need to acquire the NVM lock twice.

        This should resolve firmware updates and also fix potential raise
    that
        could have caused the driver to report an invalid NVM checksum upon
        driver load.

        Reported-by: Stefan Assmann <email address hidden>
        Fixes: 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all
    devices", 2016-12-02)
        Signed-off-by: Anjali Singhai Jain <email address hidden>
        Signed-off-by: Jacob Keller <email address hidden>
        Tested-by: Andrew Bowers <email address hidden>
        Signed-off-by: Jeff Kirsher <email address hidden>

[quanxian (quanxian-wang)]

cherrypick is needed for 17.10 release.

[Seth Forshee (sforshee)]

Cherry picked fixes from upstream to 4.12 and 4.13 artful kernel tress.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 4.13.0-11.12

---------------
linux (4.13.0-11.12) artful; urgency=low

  * linux: 4.13.0-11.12 -proposed tracker (LP: #1716699)

  * kernel panic -not syncing: Fatal exception: panic_on_oops (LP: #1708399)
    - s390/mm: fix local TLB flushing vs. detach of an mm address space
    - s390/mm: fix race on mm->context.flush_mm

  * CVE-2017-1000251
    - Bluetooth: Properly check L2CAP config option output buffer length

 -- Seth Forshee <email address hidden> Tue, 12 Sep 2017 10:18:38 -0500