Problem Statement:

 - Driver has fc_id of 0xcc0200

 - Driver gets link down (due to test) and calls fcoe_ctlr_link_down().

 - At this point, the fc_id of the initiator port is zeroed out.

 - Driver gets a link up 14 seconds later.

 - Driver performs FIP VLAN request, gets a response from the switch.

 - No change in VLAN is detected.

 - Driver then notifies libfcoe via fcoe_ctlr_link_up().

 - Libfcoe then issues a multicast discovery solicitation as expected.

 - Cisco FCF responds to that correctly.

 - Libfcoe at this point starts a 3 sec count-down to allow any other FCFs
   to be discovered. However, at this point, it has been 20 seconds since
   the last FKA from the driver (which would have been sent prior to
   backlink toggle), which causes the CVL to be issued from Cisco CVL from
   the switch is dropped by the driver as the vx_port identification
   descriptor is present and has value of 0xcc0200, which does not match
   the driver's value of 0.  Libfcoe completes the 3 sec count down and
   proceeds to issue FLOGI as per protocol.  Switch rejects FLogi request.
   All subsequent FLOGI requests from libfc are rejected by the switch
   (possibly because it is now expecting a new solicitation).  This
   situation will continue until the next link toggle.

Solution:

The Vx_port descriptor in the CVL has three fields:

MAC address
Fabric ID
Port Name

Today, the code checks for both #1 and #2 above. In the case where we went
through a link down, both these will be zero until FLOGI succeeds.

We should change our code to check if any one of these 3 is valid and if
so, handle the CVL (basically switching from AND to OR). The port name
field is definitely expected to be valid always.
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>