b2ccf317ed
We have MAX_FW_API_VER_BRANCH, MAX_FW_API_VER_MAJOR, and MAX_FW_API_VER_MINOR that we use in ice_controlq.h to test when a firmware version is newer than expected. This is currently tested by comparing each field separately. Thus, we compare the branch field against the MAX_FW_API_VER_BRANCH, and so forth. This means that currently, if we suppose that the max firmware version is defined as 0.2.1, i.e. Then firmware 0.1.3 will fail to load. This is because the minor version 3 is greater than the max minor version 1. This is not intuitive, because of the notion that increasing the major firmware version to 2 should mean any firmware version with a major version is less than 2 should be considered older than 2... In order to allow both 0.2.1 and 0.1.3 to load, you would have to define the "max" firmware version as 0.2.3.. It is possible that such a firmware version doesn't even exist yet! Fix this by replacing the current logic with an updated check that behaves as follows: First, we check the major version. If it is greater than the expected version, then we prevent driver load. Additionally, a warning message is logged to indicate to the system administrator that they need to update their driver. This is now the only case where the driver will refuse to load. Second, if the major version is less than the expected version, we log an information message indicating the NVM should be updated. Third, if the major version is exact, we'll then check the minor version. If the minor version is more than two versions less than expected, we log an information message indicating the NVM should be updated. If it is more than two versions greater than the expected version, we log an information message that the driver should be updated. To support this, the ice_aq_ver_check function needs its signature updated to pass the HW structure. Since we now pass this structure, there is no need to pass the firmware API versions separately. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> |
||
---|---|---|
Documentation | ||
LICENSES | ||
arch | ||
block | ||
certs | ||
crypto | ||
drivers | ||
firmware | ||
fs | ||
include | ||
init | ||
ipc | ||
kernel | ||
lib | ||
mm | ||
net | ||
samples | ||
scripts | ||
security | ||
sound | ||
tools | ||
usr | ||
virt | ||
.clang-format | ||
.cocciconfig | ||
.get_maintainer.ignore | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
COPYING | ||
CREDITS | ||
Kbuild | ||
Kconfig | ||
MAINTAINERS | ||
Makefile | ||
README |
README
Linux kernel ============ There are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. Please read Documentation/admin-guide/README.rst first. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. The formatted documentation can also be read online at: https://www.kernel.org/doc/html/latest/ There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. See Documentation/00-INDEX for a list of what is contained in each file. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.