tree e5a5e271c1020d6b07c29bdd35475c4d901c39fb
parent b9118b7221ebb12156d2b08d4d5647bc6076d6bb
parent abd49676c70793ee0a251bc3d8fe1604f9303210
author David S. Miller <davem@davemloft.net> 1475551372 -0400
committer David S. Miller <davem@davemloft.net> 1475551372 -0400

Merge branch 'qed-qedr-infrastructure'

Yuval Mintz says:

====================
qed*: Add qedr infrastructure support

In the last couple of weeks we've been sending RFCs for the qedr
driver - the RoCE driver for QLogic FastLinQ 4xxxx line of adapters.
Latest RFC can be found at [1].

At Doug's advice [2], we've decided to split the series into two:
 - first part contains the qed backbone that's necessary for all the
configurations relating to the qedr driver, as well as the qede
infrastructure that is used for communication between the qedr and qede.
 - Second part consists of the actual qedr driver and introduces almost
no changes to qed/qede.

This is the first of said two parts. The second half would be sent
later this week.

The only 'oddity' in the devision are the Kconfig options -
As this series introduces both LL2 and QEDR-based logic in qed/qede,
I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
Otherwise, a lot of the code introduced would be dead-code [won't even
be compiled] until qedr is accepted.
As a result I've placed the config option in an odd place - under
qlogic's Kconfig. The second series would then remove that option
and add it in its correct place under the infiniband Kconfig.
[I'm fine with pushing it there to begin with, but I didn't want to
'contaminate' non-qlogic configuration files with half-baked options].

Dave - I don't think you were E-mailed with Doug's suggestion.
I think the notion was to have the two halves accepted side-by-side,
but actually the first has no dependency issues, so it's also
possible to simply take this first to net-next, and push the qedr
into rdma once it's merged. But it's basically up to you and Doug;
We'd align with whatever suits you best.
====================

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