[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170408.083905.1266827432475392554.davem@davemloft.net>
Date: Sat, 08 Apr 2017 08:39:05 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: felix.manlunas@...ium.com
Cc: netdev@...r.kernel.org, raghu.vatsavayi@...ium.com,
derek.chickles@...ium.com
Subject: Re: [PATCH net-next] liquidio: fix VF incorrectly indicating that
it successfully set its VLAN
From: Felix Manlunas <felix.manlunas@...ium.com>
Date: Thu, 6 Apr 2017 19:22:22 -0700
> For security reasons, NIC firmware does not allow VF to set its VLAN if PF
> set it already. Firmware allows VF to set its VLAN if PF did not set it.
> After the VF instructs the firmware to set the VLAN, VF always indicates
> (via return 0) that the operation is successful--even for the times when it
> isn't.
>
> Put in a mechanism for the VF's set VLAN function to receive the firmware
> response code, then make that function return -EPERM if the firmware
> forbids the operation.
>
> Make that mechanism available for other functions that may, in the future,
> be interested in receiving the response code from the firmware. That
> mechanism involves adding new fields to struct octnic_ctrl_pkt, so make all
> users of struct octnic_ctrl_pkt initialize the struct to zero before using
> it; otherwise, the mechanism might act on uninitialized garbage.
>
> Signed-off-by: Felix Manlunas <felix.manlunas@...ium.com>
> Signed-off-by: Derek Chickles <derek.chickles@...ium.com>
Applied, thanks.
Powered by blists - more mailing lists