linux-stable.git/include/scsi/libfcoe.h, branch v4.9.296

scsi: fcoe: Fix mismatched fcoe_wwn_from_mac declaration

2021-05-22T08:40:25+00:00

[ Upstream commit 5b11c9d80bde81f6896cc85b23aeaa9502a704ed ]

An old cleanup changed the array size from MAX_ADDR_LEN to unspecified in
the declaration, but now gcc-11 warns about this:

drivers/scsi/fcoe/fcoe_ctlr.c:1972:37: error: argument 1 of type ‘unsigned char[32]’ with mismatched bound [-Werror=array-parameter=]
 1972 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN],
      |                       ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In file included from /git/arm-soc/drivers/scsi/fcoe/fcoe_ctlr.c:33:
include/scsi/libfcoe.h:252:37: note: previously declared as ‘unsigned char[]’
  252 | u64 fcoe_wwn_from_mac(unsigned char mac[], unsigned int, unsigned int);
      |                       ~~~~~~~~~~~~~~^~~~~

Change the type back to what the function definition uses.

Link: https://lore.kernel.org/r/20210322164702.957810-1-arnd@kernel.org
Fixes: fdd78027fd47 ("[SCSI] fcoe: cleans up libfcoe.h and adds fcoe.h for fcoe module")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure

2019-08-11T10:22:12+00:00

commit 023358b136d490ca91735ac6490db3741af5a8bd upstream.

Gcc-9 complains for a memset across pointer boundaries, which happens as
the code tries to allocate a flexible array on the stack.  Turns out we
cannot do this without relying on gcc-isms, so with this patch we'll embed
the fc_rport_priv structure into fcoe_rport, can use the normal
'container_of' outcast, and will only have to do a memset over one
structure.

Signed-off-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

fcoe: implement FIP VLAN responder

2016-07-20T23:49:41+00:00

When running in VN2VN mode there is no central instance which would send
out any FIP VLAN discovery notifications. So this patch adds a new sysfs
attribute 'fip_vlan_responder' which will activate a FIP VLAN discovery
responder.

Signed-off-by: Hannes Reinecke 
Acked-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen

fcoe: use enum for fip_mode

2016-07-14T02:05:28+00:00

The FIP mode is independent on the FIP state machine, so use a separate
enum for that instead of overloading it with state machine values.

Signed-off-by: Hannes Reinecke 
Acked-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen

fcoe: convert to kworker

2016-07-13T03:16:31+00:00

The driver creates its own per-CPU threads which are updated based on
CPU hotplug events. It is also possible to use kworkers and remove some
of the kthread infrastrucure.

The code checked ->thread to decide if there is an active per-CPU
thread. By using the kworker infrastructure this is no longer
possible (or required). The thread pointer is saved in `kthread' instead
of `thread' so anything trying to use thread is caught by the
compiler. Currently only the bnx2fc driver is using struct fcoe_percpu_s
and the kthread member.

After a CPU went offline, we may still enqueue items on the "offline"
CPU. This isn't much of a problem. The work will be done on a random
CPU. The allocated crc_eof_page page won't be cleaned up. It is probably
expected that the CPU comes up at some point so it should not be a
problem. The crc_eof_page memory is released of course once the module
is removed.

This patch was only compile-tested due to -ENODEV.

Cc: Vasu Dev 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Cc: Christoph Hellwig 
Cc: fcoe-devel@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
Tested-by: Johannes Thumshirn 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen

libfcoe: Make fcoe_sysfs optional / fix fnic NULL exception

2013-10-11T20:25:40+00:00

fnic doesn't use any of the create/destroy/enable/disable interfaces
either from the (legacy) module paramaters or the (new) fcoe_sysfs
interfaces. When fcoe_sysfs was introduced fnic wasn't changed since
it wasn't using the interfaces. libfcoe incorrectly assumed that that
all of its users were using fcoe_sysfs and when adding and deleting
FCFs would assume the existance of a fcoe_ctlr_device. fnic was not
allocating this structure because it doesn't care about the standard
user interfaces (fnic starts on link only). If/When libfcoe tried to use
the fcoe_ctlr_device's lock for the first time a NULL pointer exception
would be triggered.

Since fnic doesn't care about sysfs or user interfaces, the solution
is to drop libfcoe's assumption that all drivers are using fcoe_sysfs.

This patch accomplishes this by changing some of the structure
relationships.

We need a way to determine when a LLD is using fcoe_sysfs or not and
we can do that by checking for the existance of the fcoe_ctlr_device.
Prior to this patch, it was assumed that the fcoe_ctlr structure was
allocated with the fcoe_ctlr_device and immediately followed it in
memory. To reach the fcoe_ctlr_device we would simply go back in memory
from the fcoe_ctlr to get the fcoe_ctlr_device.

Since fnic doesn't allocate the fcoe_ctlr_device, we cannot keep that
assumption. This patch adds a pointer from the fcoe_ctlr to the
fcoe_ctlr_device. For bnx2fc and fcoe we will continue to allocate the
two structures together, but then we'll set the ctlr->cdev pointer
to point at the fcoe_ctlr_device. fnic will not change and will continue
to allocate the fcoe_ctlr itself, and ctlr->cdev will remain NULL.

When libfcoe adds fcoe_fcf's to the fcoe_ctlr it will check if ctlr->cdev
is set and only if so will it continue to interact with fcoe_sysfs.

Signed-off-by: Robert Love 
Acked-by: Neil Horman 
Tested-by: Hiral Patel

libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesb

2012-12-14T18:38:55+00:00

Similarly they can be moved into libfcoe instead of being private to fcoe now.
Also add comments particularly on the term LESB to the corresponding function.

Signed-off-by: Yi Zou 
Cc: Bhanu Prakash Gollapudi 
Tested-by: Marcus Dennis 
Signed-off-by: Robert Love

libfcoe, fcoe: move fcoe_link_speed_update() to libfcoe and export it

2012-12-14T18:38:55+00:00

With the previous patch, fcoe_link_speed_update() can be moved into libfcoe and
exported to used by fcoe, bnx2fc, and etc.

Signed-off-by: Yi Zou 
Cc: Bhanu Prakash Gollapudi 
Tested-by: Marcus Dennis 
Signed-off-by: Robert Love

fcoe: add support to the get_netdev() for fcoe_interface

2012-12-14T18:38:55+00:00

Adds support to fcoe_port's newly added get_netdev fucntion pointer.

Signed-off-by: Yi Zou 
Cc: Bhanu Prakash Gollapudi 
Tested-by: Marcus Dennis 
Signed-off-by: Robert Love

fcoe: prep work to start consolidate the usage of fcoe_netdev

2012-12-14T18:38:55+00:00

Currently, in the default kernel fcoe driver, it is needed to get to the underlying
private per fcoe transport's private structure, e.g., fcoe_interface in
fcoe.ko, and returns the associated netdev. The similar logic exists in other
fcoe drivers, e.g., bnx2fc, so we add a function pointer into the common
fcoe_port struct to allow individual fcoe transport implementaion (fcoe
and bnx2fc) to get the corresponding netdev associated with a give lport.

Then a inline fcoe_get_netdev() is added as part of libfcoe for all underlying
fcoe transport drivers to use regardless of its individual fcoe transport
driver, and also allows move more common code such as fcoe_link_speed_update or
fcoe_ctlr_get_lesb to be in libfcoe, rather than specific to fcoe.

This patch is a prep work that adds aforementioned fucntion pointer, and
followed by the actual code changes to make use of it.

Signed-off-by: Yi Zou 
Cc: Bhanu Prakash Gollapudi 
Tested-by: Marcus Dennis 
Signed-off-by: Robert Love