Merge branch 'qed-Status-block-changes'
authorDavid S. Miller <davem@davemloft.net>
Thu, 1 Jun 2017 16:17:21 +0000 (12:17 -0400)
committerDavid S. Miller <davem@davemloft.net>
Thu, 1 Jun 2017 16:17:21 +0000 (12:17 -0400)
commit40aa306f8dafaf872da1a71479e933bd3ce0c294
tree544343c0669d24ddbf00f09864dbc44b359a9795
parent7b954ed7529b6bae8712345dd9d22afa57b96dca
parent1ee240e31d4c0a5fd37ebaf064ca1f6cb6adcb6f
Merge branch 'qed-Status-block-changes'

Yuval Mintz says:

====================
qed: Status block changes

The device maintains a CAM mapping of the internal status blocks
and the various PF/VF MSI-x vector mappings.
During initialization, the driver reads the HW memory and constructs
a shadow SW implementation which it would later use for manipulation
of interrupts. E.g., when enabling VFs and setting their MSI-x tables.

The driver currently has some very strict assumptions on the order the
entries are placed in the CAM. Specifically, it assumes that all entries
belonging to a PF would be consecutive and in-order in the CAM, and that
the VF entries would then follow. But there's no actual HW constraint
enforcing this assumption [although management firmware does set it
accordingly to same assumption initially].

Since the CAM is re-configurable, there are now SW flows employeed
by other OSes that might cause the assumption to be invalid.
Such flows allow the PF to forfeit some of it's available interrupts
in favor of its VFs or vice versa.
While those are not employeed today by qed, we want to relax the
assumptions as much as we can -
both to allow functionality after PDA as well as allowing future
compatibility where the driver would be loaded after a newer one has
'dirtied' the CAM configuration.

In addition to patches meant for the above relaxation, the series
also contains various cleanups & refactoring for interrupt logic
[most of which is !semantic].
====================

Signed-off-by: David S. Miller <davem@davemloft.net>