1. 25 Jun, 2014 1 commit
    • Neil Horman's avatar
      bnx2fc: Improve stats update mechanism · d576a5e8
      Neil Horman authored
      Recently had this warning reported:
      
      [  290.489047] Call Trace:
      [  290.489053]  [<ffffffff8169efec>] dump_stack+0x19/0x1b
      [  290.489055]  [<ffffffff810ac7a9>] __might_sleep+0x179/0x230
      [  290.489057]  [<ffffffff816a4ad5>] mutex_lock_nested+0x55/0x520
      [  290.489061]  [<ffffffffa01b9905>] ? bnx2fc_l2_rcv_thread+0xc5/0x4c0 [bnx2fc]
      [  290.489065]  [<ffffffffa0174c1a>] fc_vport_id_lookup+0x3a/0xa0 [libfc]
      [  290.489068]  [<ffffffffa01b9a6c>] bnx2fc_l2_rcv_thread+0x22c/0x4c0 [bnx2fc]
      [  290.489070]  [<ffffffffa01b9840>] ? bnx2fc_vport_destroy+0x110/0x110 [bnx2fc]
      [  290.489073]  [<ffffffff8109e0cd>] kthread+0xed/0x100
      [  290.489075]  [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80
      [  290.489077]  [<ffffffff816b2fec>] ret_from_fork+0x7c/0xb0
      [  290.489078]  [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80
      
      Its due to the fact that we call a potentially sleeping function from the bnx2fc
      rcv path with preemption disabled (via the get_cpu call embedded in the per-cpu
      variable stats lookup in bnx2fc_l2_rcv_thread.
      
      Easy enough fix, we can just move the stats collection later in the function
      where we are sure we won't preempt or sleep.  This also allows us to not have to
      enable pre-emption when doing a per-cpu lookup, since we're certain not to get
      rescheduled.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarEddie Wai <eddie.wai@broadcom.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      d576a5e8
  2. 18 Apr, 2014 1 commit
  3. 20 Mar, 2014 1 commit
    • Srivatsa S. Bhat's avatar
      scsi, bnx2fc: Fix CPU hotplug callback registration · 7229b6d0
      Srivatsa S. Bhat authored
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the bnx2fc code in scsi by using this latter form of callback
      registration.
      
      Cc: Eddie Wai <eddie.wai@broadcom.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7229b6d0
  4. 15 Mar, 2014 2 commits
    • Eddie Wai's avatar
      [SCSI] bnx2fc: Updated version to 2.4.2 · 38e83bff
      Eddie Wai authored
      Old version: 2.4.1
      New version: 2.4.2
      Signed-off-by: default avatarEddie Wai <eddie.wai@broadcom.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      38e83bff
    • Eddie Wai's avatar
      [SCSI] bnx2fc: Fixed scsi_remove_target soft lockup when rmmod bnx2x · 06c4f20d
      Eddie Wai authored
      The problem has been identified to be a change in the scsi_remove_device
      path where a call to the pm_runtime_set_memalloc_noio was added when
      del_gendisk is called in this path.  Note that the new pm routine
      attempts to cycle through all parent devices from the FC target device
      to set the memalloc_noio flag.  Because of this new change, a dependency
      was created between the FC target device and the parent netdev device
      in the destroy path.
      
      In order to synchronized the destroy paths, bnx2fc has been modified
      to flush all destroy workqueues in the NETDEV_UNREGISTER return path.
      
      [    4.123584] BUG: soft lockup - CPU#8 stuck for 22s! [kworker/8:3:8082]
      [    4.123713] Call Trace:
      [    4.123719]  [<ffffffff815dfbe0>] klist_next+0x20/0xf0
      [    4.123725]  [<ffffffff813e9220>] ? pm_save_wakeup_count+0x70/0x70
      [    4.123731]  [<ffffffff813d9e4e>] device_for_each_child+0x4e/0x70
      [    4.123735]  [<ffffffff813e9554>] pm_runtime_set_memalloc_noio+0x94/0xf0
      [    4.123740]  [<ffffffff812d4d74>] del_gendisk+0x264/0x2a0
      [    4.123747]  [<ffffffffa00c6dc9>] sd_remove+0x69/0xb0 [sd_mod]
      [    4.123751]  [<ffffffff813de24f>] __device_release_driver+0x7f/0xf0
      [    4.123754]  [<ffffffff813de2e3>] device_release_driver+0x23/0x30
      [    4.123757]  [<ffffffff813ddab4>] bus_remove_device+0xf4/0x170
      [    4.123760]  [<ffffffff813da475>] device_del+0x135/0x1d0
      [    4.123765]  [<ffffffff81411b75>] __scsi_remove_device+0xc5/0xd0
      [    4.123768]  [<ffffffff81411ba6>] scsi_remove_device+0x26/0x40
      [    4.123770]  [<ffffffff81411d40>] scsi_remove_target+0x160/0x210
      [    4.123775]  [<ffffffffa0420e4c>] fc_rport_final_delete+0xac/0x1f0 [scsi_transport_fc]
      [    4.123780]  [<ffffffff810774ab>] process_one_work+0x17b/0x460
      [    4.123783]  [<ffffffff8107825b>] worker_thread+0x11b/0x400
      [    4.123786]  [<ffffffff81078140>] ? rescuer_thread+0x3e0/0x3e0
      [    4.123791]  [<ffffffff8107e9c0>] kthread+0xc0/0xd0
      [    4.123794]  [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
      [    4.123798]  [<ffffffff8160ceec>] ret_from_fork+0x7c/0xb0
      [    4.123801]  [<ffffffff8107e900>] ? kthread_create_on_node+0x110/0x110
      Signed-off-by: default avatarEddie Wai <eddie.wai@broadcom.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      06c4f20d
  5. 25 Oct, 2013 2 commits
    • Eddie Wai's avatar
    • Eddie Wai's avatar
      [SCSI] BNX2FC: hung task timeout warning observed when rmmod bnx2x with active FCoE targets · 0680810c
      Eddie Wai authored
      [v2] - removed the interface->enabled flag setting which prevented the
             fcoe ctlr link from being brought back up after a MTU change
      
      A rtnl_lock deadlock was observed from the rmmod thread where it
      tries to unregister the fcoe_ctlr device.  This unregistration
      triggered a flush of the sysfs queue of the associated ctlr and led to
      a call to the set_fcoe_ctlr_enabled routine.  This will eventually propagate
      down to call the bnx2fc_disable routine and contented for the rtnl_lock
      in the same context.
      
      This patch creates a subset of the bnx2fc_enable/disable routine which
      removes the unnecesary rtnl_lock and the bnx2fc_dev_lock acquisition from
      the set_fcoe_ctlr_enabled path.
      
       kernel: INFO: task rmmod:7874 blocked for more than 120 seconds.
       kernel:      Tainted: G        W  ---------------    2.6.32-415.0.1.el6.x86_64 #1
       kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       kernel: rmmod         D 000000000000000f     0  7874   6518 0x00000080
       kernel: ffff88022158f7d8 0000000000000086 0000000000000000 0000000000000000
       kernel: ffff88023fe72600 ffff88043c74d410 ffff88043c74d400 ffff88043c74d000
       kernel: ffff88021ecbe5f8 ffff88022158ffd8 000000000000fbc8 ffff88021ecbe5f8
       kernel: Call Trace:
       kernel: [<ffffffff81525985>] schedule_timeout+0x215/0x2e0
       kernel: [<ffffffff810680c0>] ? pick_next_task_fair+0xd0/0x130
       kernel: [<ffffffff81524858>] ? schedule+0x178/0x3b2
       kernel: [<ffffffff81525603>] wait_for_common+0x123/0x180
       kernel: [<ffffffff81066b40>] ? default_wake_function+0x0/0x20
       kernel: [<ffffffff811a486e>] ? ifind_fast+0x5e/0xb0
       kernel: [<ffffffff8152571d>] wait_for_completion+0x1d/0x20
       kernel: [<ffffffff81203868>] sysfs_addrm_finish+0x228/0x270
       kernel: [<ffffffff812014ab>] sysfs_hash_and_remove+0x5b/0x90
       kernel: [<ffffffff812056af>] sysfs_remove_group+0x5f/0x100
       kernel: [<ffffffff81367e8b>] device_remove_groups+0x3b/0x60
       kernel: [<ffffffff8136811d>] device_remove_attrs+0x3d/0x90
       kernel: [<ffffffff81368295>] device_del+0x125/0x1e0
       kernel: [<ffffffff81368372>] device_unregister+0x22/0x60
       kernel: [<ffffffffa038ead2>] fcoe_ctlr_device_delete+0xe2/0xf4 [libfcoe]
       kernel: [<ffffffffa03c43cb>] bnx2fc_interface_release+0x5b/0x90 [bnx2fc]
       kernel: [<ffffffffa03c4370>] ? bnx2fc_interface_release+0x0/0x90 [bnx2fc]
       kernel: [<ffffffff812835e7>] kref_put+0x37/0x70
       kernel: [<ffffffffa03c4192>] __bnx2fc_destroy+0x72/0xa0 [bnx2fc]
       kernel: [<ffffffffa03c5265>] bnx2fc_ulp_exit+0xf5/0x160 [bnx2fc]    <- got bnx2fc_dev_lock mutex_lock
       kernel: [<ffffffffa03b03c6>] cnic_ulp_exit+0xb6/0xc0 [cnic]
       kernel: [<ffffffffa03b5418>] cnic_netdev_event+0x368/0x370 [cnic]
       kernel: [<ffffffffa038c56c>] ? fcoe_del_netdev_mapping+0x8c/0xa0 [libfcoe]
       kernel: [<ffffffff8152a6e5>] notifier_call_chain+0x55/0x80
       kernel: [<ffffffff810a0a46>] raw_notifier_call_chain+0x16/0x20
       kernel: [<ffffffff81459beb>] call_netdevice_notifiers+0x1b/0x20
       kernel: [<ffffffff8145ab34>] rollback_registered_many+0x154/0x280
       kernel: [<ffffffff8145ad08>] rollback_registered+0x38/0x50
       kernel: [<ffffffff8145ad78>] unregister_netdevice_queue+0x58/0xa0
       kernel: [<ffffffff8145add0>] unregister_netdevice+0x10/0x20
       kernel: [<ffffffff8145adfe>] unregister_netdev+0x1e/0x30                  <- got rtnl_lock!!!!!!!!!
       kernel: [<ffffffffa0122278>] __bnx2x_remove+0x48/0x270 [bnx2x] <- got & rel rtnl_lock
       kernel: [<ffffffffa0122554>] bnx2x_remove_one+0x44/0x80 [bnx2x]
       kernel: [<ffffffff812a3af7>] pci_device_remove+0x37/0x70
       kernel: [<ffffffff8136b2ef>] __device_release_driver+0x6f/0xe0
       kernel: [<ffffffff8136b428>] driver_detach+0xc8/0xd0
       kernel: [<ffffffff8136a22e>] bus_remove_driver+0x8e/0x110
       kernel: [<ffffffff8136bc12>] driver_unregister+0x62/0xa0
       kernel: [<ffffffff812a3e04>] pci_unregister_driver+0x44/0xb0
       kernel: [<ffffffffa0191954>] bnx2x_cleanup+0x18/0x73 [bnx2x]
       kernel: [<ffffffff810b8be4>] sys_delete_module+0x194/0x260
       kernel: [<ffffffff810e1347>] ? audit_syscall_entry+0x1d7/0x200
       kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarEddie Wai <eddie.wai@broadcom.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      0680810c
  6. 14 Oct, 2013 1 commit
    • Joe Perches's avatar
      scsi: Convert uses of compare_ether_addr to ether_addr_equal · 6942df7f
      Joe Perches authored
      Preliminary to removing compare_ether_addr altogether:
      
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      6942df7f
  7. 11 Oct, 2013 1 commit
    • Robert Love's avatar
      libfcoe: Make fcoe_sysfs optional / fix fnic NULL exception · 9d34876f
      Robert Love authored
      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: default avatarRobert Love <robert.w.love@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Tested-by: default avatarHiral Patel <hiralpat@cisco.com>
      9d34876f
  8. 02 May, 2013 3 commits
  9. 25 Apr, 2013 1 commit
  10. 25 Mar, 2013 3 commits
  11. 29 Jan, 2013 3 commits
  12. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      Drivers: scsi: remove __dev* attributes. · 6f039790
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Adam Radford <linuxraid@lsi.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f039790
  13. 14 Dec, 2012 5 commits
    • Yi Zou's avatar
      bnx2fc: use fcoe_get_lesb/fcoe_ctlr_get_lesb() directly from libfcoe · b8b3e697
      Yi Zou authored
      Drop the bnx2fc_xxx versions as they are basically the same.
      Signed-off-by: default avatarYi Zou <yi.zou@intel.com>
      Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
      Tested-by: default avatarMarcus Dennis <marcusx.e.dennis@intel.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      b8b3e697
    • Yi Zou's avatar
      bnx2fc: use fcoe_link_speed_update() from the exported symbol in libfcoe · 0e0f9cd6
      Yi Zou authored
      We have fcoe_link_speed_update() in libfcoe ready for use now, take out the
      bnx2fc version which is almost the same.
      Signed-off-by: default avatarYi Zou <yi.zou@intel.com>
      Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
      Tested-by: default avatarMarcus Dennis <marcusx.e.dennis@intel.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      0e0f9cd6
    • Yi Zou's avatar
      bnx2fc: add support to get_netdev for bnx2f_interface · c3d7909b
      Yi Zou authored
      Adds support to fcoe_port's newly added get_netdev fucntion pointer for bnx2fc.
      Signed-off-by: default avatarYi Zou <yi.zou@intel.com>
      Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
      Tested-by: default avatarMarcus Dennis <marcusx.e.dennis@intel.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      c3d7909b
    • Robert Love's avatar
      bnx2fc: Use the fcoe_sysfs control interface · 6e89ea3f
      Robert Love authored
      This patch adds support for the new fcoe_sysfs
      control interface to bnx2fc.ko. It keeps the deprecated
      interface in tact and therefore either the legacy
      or the new control interfaces can be used. A mixed mode
      is not supported. A user must either use the new
      interfaces or the old ones, but not both.
      
      The fcoe_ctlr's link state is now driven by both the
      netdev link state as well as the fcoe_ctlr_device's
      enabled attribute. The link must be up and the
      fcoe_ctlr_device must be enabled before the FCoE
      Controller starts discovery or login.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      6e89ea3f
    • Robert Love's avatar
      libfcoe, fcoe, bnx2fc: Add new fcoe control interface · 6a891b07
      Robert Love authored
      This patch does a few things.
      
      1) Makes /sys/bus/fcoe/ctlr_{create,destroy} interfaces.
         These interfaces take an <ifname> and will either
         create an FCoE Controller or destroy an FCoE
         Controller depending on which file is written to.
      
         The new FCoE Controller will start in a DISABLED
         state and will not do discovery or login until it
         is ENABLED. This pause will allow us to configure
         the FCoE Controller before enabling it.
      
      2) Makes the 'mode' attribute of a fcoe_ctlr_device
         writale. This allows the user to configure the mode
         in which the FCoE Controller will start in when it
         is ENABLED.
      
         Possible modes are 'Fabric', or 'VN2VN'.
      
         The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
         Drivers must implement the set_fcoe_ctlr_mode routine
         to support this feature.
      
         libfcoe offers an exported routine to set a FCoE
         Controller's mode. The mode can only be changed
         when the FCoE Controller is DISABLED.
      
         This patch also removes the get_fcoe_ctlr_mode pointer
         in the fcoe_sysfs function template, the code in
         fcoe_ctlr.c to get the mode and the assignment of
         the fcoe_sysfs function pointer to the fcoe_ctlr.c
         implementation (in fcoe and bnx2fc). fcoe_sysfs can
         return that value for the mode without consulting the
         LLD.
      
      3) Make a 'enabled' attribute of a fcoe_ctlr_device. On a
         read, fcoe_sysfs will return the attribute's value. On
         a write, fcoe_sysfs will call the LLD (if there is a
         callback) to notifiy that the enalbed state has changed.
      
      This patch maintains the old FCoE control interfaces as
      module parameters, but it adds comments pointing out that
      the old interfaces are deprecated.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      6a891b07
  14. 01 Sep, 2012 1 commit
  15. 20 Jul, 2012 5 commits
  16. 27 Jun, 2012 1 commit
  17. 23 May, 2012 2 commits
    • Robert Love's avatar
      [SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE Syfs · 8d55e507
      Robert Love authored
      This patch has the SW FCoE driver and the bnx2fc
      driver make use of the new fcoe_sysfs API added
      earlier in this patch series.
      
      After this patch a fcoe_ctlr_device is allocated with
      private data in this order.
      
      +------------------+   +------------------+
      | fcoe_ctlr_device |   | fcoe_ctlr_device |
      +------------------+   +------------------+
      | fcoe_ctlr        |   | fcoe_ctlr        |
      +------------------+   +------------------+
      | fcoe_interface   |   | bnx2fc_interface |
      +------------------+   +------------------+
      
      libfcoe also takes part in this new model since it
      discovers and manages fcoe_fcf instances. The memory
      allocation is different for FCFs. I didn't want to
      impact libfcoe's fcoe_fcf processing, so this patch
      creates fcoe_fcf_device instances for each discovered
      fcoe_fcf. The two are paired using a (void * priv)
      member of the fcoe_ctlr_device. This allows libfcoe
      to continue maintaining its list of fcoe_fcf instances
      and simply attaches and detaches them from existing
      or new fcoe_fcf_device instances.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      8d55e507
    • Robert Love's avatar
      [SCSI] bnx2fc: Allocate fcoe_ctlr with bnx2fc_interface, not as a member · fd8f8902
      Robert Love authored
          Currently the fcoe_ctlr associated with an interface is allocated
          as a member of struct bnx2fc_interface. This causes problems when
          when later patches attempt to use the new fcoe_sysfs APIs which
          allow us to allocate the bnx2fc_interface as private data to a
          fcoe_ctlr_device instance. The problem is that libfcoe wants to
          be able use pointer math to find a fcoe_ctlr's fcoe_ctlr_device
          as well as finding a fcoe_ctlr_device's assocated fcoe_ctlr. To
          do this we need to allocate the fcoe_ctlr_device, with private
          data for the LLD. The private data will contain the fcoe_ctlr
          and its private data will be the bnx2fc_interface.
      
          +-------------------+
          | fcoe_ctlr_device  |
          +-------------------+
          | fcoe_ctlr         |
          +-------------------+
          | bnx2fc_interface  |
          +-------------------+
      
          This prep work will allow us to go from a fcoe_ctlr_device
          instance to its fcoe_ctlr as well as from a fcoe_ctlr to its
          fcoe_ctlr_device once the fcoe_sysfs API is in use (later
          patches in this series).
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      fd8f8902
  18. 22 May, 2012 1 commit
  19. 28 Mar, 2012 1 commit
  20. 20 Mar, 2012 1 commit
  21. 19 Feb, 2012 3 commits