[Raring/Saucy][PATCH] be2net: pass if_id for v1 and V2 versions of TX_CREATE cmd
Kamal Mostafa
kamal at canonical.com
Wed Nov 6 21:52:48 UTC 2013
On Wed, 2013-11-06 at 12:01 -0600, Seth Forshee wrote:
> On Wed, Nov 06, 2013 at 05:32:56PM +0000, Sarveshwar Bandi wrote:
> > Yes. The patch has been pulled into stable by greg. See mail below:
>
> Great, thanks. Has Kamal also picked it up for 3.8 stable?
>
No, I didn't pick this one up for 3.8-stable:
0fb88d61bc60779dde88b0fc268da17eb81d0412
be2net: pass if_id for v1 and V2 versions of TX_CREATE cmd
because the patch doesn't apply, and it appeared to be not relevant for
3.8 or earlier.
tl;dr: If someone wants to supply a useful backport of it, I'll take it.
Longer: The purpose of the mainline patch (attached) appears to be to
move the line:
req->if_id = cpu_to_le16(adapter->if_handle);
down outside of the if-elseif-else so as to ensure that req->if_id has a
chance to get set for "all" the adapter types (the elseif and else
paths), not just the if (lancer_chip(adapter)) path.
But in 3.8, there is no elseif or else clause there... just the if
(lancer_chip(adapter)) clause, where an if_id member gets set by the
AMAP_SET_BITS macro. Is there actually any need to move that outside
this clause? In 3.8:
if (lancer_chip(adapter)) {
req->hdr.version = 1;
AMAP_SET_BITS(struct amap_tx_context, if_id, ctxt,
adapter->if_handle);
}
Note also that there isn't actually any "req->if_id" member (struct
be_cmd_req_eth_tx_create) in 3.8.
-Kamal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-be2net-pass-if_id-for-v1-and-V2-versions-of-TX_CREAT.patch
Type: text/x-patch
Size: 1615 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20131106/e6666cdc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20131106/e6666cdc/attachment.sig>
More information about the kernel-team
mailing list