- 16 10月, 2011 1 次提交
-
-
由 Bhanu Prakash Gollapudi 提交于
Except for obtaining the netdev from lport, fcoe_get_lesb is the common code for the LLDs. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Acked-by: NYi Zou <yi.zou@intel.com> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
- 27 8月, 2011 1 次提交
-
-
由 Bhanu Prakash Gollapudi 提交于
Export fcoe_get_wwn, fcoe_validate_vport_create and fcoe_wwn_to_str so that all LLDs can use these common function. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
- 25 5月, 2011 1 次提交
-
-
由 Robert Love 提交于
libfcoe's interface consists of create, destroy, enable, disable and create_vn2vn. These are currently module paramaters added durring the module initialization. A concern arose that the module parameters were being added with write permissions before the module had completed initialization. The following code was added to each sysfs store file. * Make sure the module has been initialized, and is not about to be * removed. Module parameter sysfs files are writable before the * module_init function is called and after module_exit. */ if (THIS_MODULE->state != MODULE_STATE_LIVE) goto out_nodev; This check was called out as unhelpful as the module can go dead at any time and therefore its state isn't a reliable thing to look at as a sign of stability and initialization completion. Also, that functional interfaces like these should be added after module initialization. This patch removes the unnecessary checks and hopes to disprove the concern about initialization ordering. Recent fcoe transport rework changes now require fcoe transports to register with libfcoe before any operation can take place. libfcoe may access some static variables but nothing that could cause a problem. Once a fcoe transport is registered, libfcoe is usable and any interface calls will be functional. Signed-off-by: NRobert Love <robert.w.love@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
-
- 01 5月, 2011 4 次提交
-
-
由 Yi Zou 提交于
fix typo of '_attach' -> '_detach' in the comment. Reported-by: NFrank Zhang <frank_1.zhang@intel.com> Signed-off-by: NYi Zou <yi.zou@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Yi Zou 提交于
possible buffer overflow in fcoe_transport_show when reaching the end of buffer and crossing PAGE_SIZE boundary. Signed-off-by: NYi Zou <yi.zou@intel.com> Signed-off-by: NTomas Henzl <thenzl@redhat.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Yi Zou 提交于
When rmmoving the underlying fcoe transport driver module by force when it's attached and in use, the correspoding netdev mapping should be cleaned up properly as well, otherwise the lookup for a given netdev for the transport would still return non NULL pointer, causing "unable to handle paging request" bug. Signed-off-by: NYi Zou <yi.zou@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Robert Love 提交于
This code was incorrectly ported from fcoe.c when the fcoe transport infrastructure was put into place. It was originally needed in fcoe.c when dealing with the rtnl mutex. In that code it was only needed to avoid a lockdep false positive. In libfcoe we don't deal with the rtnl mutex, we don't get the lockdep false positive and therefore we don't need these checks. Signed-off-by: NRobert Love <robert.w.love@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
- 01 3月, 2011 1 次提交
-
-
由 Bhanu Prakash Gollapudi 提交于
When L2 driver is unloaded, libfcoe_destroy tries to access the fcoe transport structure matching the netdev. However, since the netdev is unregistered by that time, it fails to do so. Hence the stale mappings exists in the fcoe-netdev list. Handle NETDEV_UREGISTER device notification mechanism to remove the stale fcoe-netdev mapping. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
- 13 2月, 2011 3 次提交
-
-
由 Bhanu Prakash Gollapudi 提交于
To facilitate LLDDs to reuse the code, skb queue related functions are moved to libfcoe, so that both fcoe and bnx2fc drivers can use them. The common structures fcoe_port, fcoe_percpu_s are moved to libfcoe. fcoe_port will now have an opaque pointer that points to corresponding driver's interface structure. Also, fcoe_start_io and fcoe_fc_crc are moved to libfcoe. As part of this change, fixed fcoe_start_io to return ENOMEM if skb_clone fails. Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Yi Zou 提交于
Now we can include the fcoe_transport.c to the build of the kernel libfcoe module. Move the module information to fcoe_transport, and it will have all the module parameters later for the create/destroy/enable/disable of an FCoE instance. Signed-off-by: NYi Zou <yi.zou@intel.com> Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-
由 Yi Zou 提交于
Add the new fcoe_transport.c file that implements basic fcoe transport interface. Eventually, the sysfs entries to create/destroy/enable/disable an FCoE instance will be coming to the fcoe transport layer, who does a look-up to find the corresponding transport provide and pass the corresponding action over to the identified provider. The fcoe.ko will become the default fcoe transport provider that can support FCoE on any given netdev interfaces, as the Open-FCoE.org's default software FCoE HBA solution. Any vendor specific FCoE HBA driver that is built on top of Open-FCoE's kernel stack of libfc & libfcoe as well as the user land tool of fcoe-utils can easily plug-in and start running FCoE on their network interfaces. The fcoe.ko will be converted to act as the default provider if no vendor specific transport provider is found, as it is always added to the very end of the list of attached transports. Signed-off-by: NYi Zou <yi.zou@intel.com> Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
-