1. 15 12月, 2012 1 次提交
    • R
      libfcoe, fcoe, bnx2fc: Add new fcoe control interface · 6a891b07
      Robert Love 提交于
      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: NRobert Love <robert.w.love@intel.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      6a891b07
  2. 23 5月, 2012 1 次提交
    • R
      [SCSI] libfcoe: Add fcoe_sysfs · 9a74e884
      Robert Love 提交于
      This patch adds a 'fcoe bus' infrastructure to the kernel
      that is driven by changes to libfcoe which allow LLDs to
      present FIP (FCoE Initialization Protocol) discovered
      entities and their attributes to user space via sysfs.
      
      This patch adds the following APIs-
      
      fcoe_ctlr_device_add
      fcoe_ctlr_device_delete
      fcoe_fcf_device_add
      fcoe_fcf_device_delete
      
      They allow the LLD to expose the FCoE ENode Controller
      and any discovered FCFs (Fibre Channel Forwarders, e.g.
      FCoE switches) to the user. Each of these new devices
      has their own bus_type so that they are grouped together
      for easy lookup from a user space application. Each
      new class has an attribute_group to expose attributes
      for any created instances. The attributes are-
      
      fcoe_ctlr_device
      * fcf_dev_loss_tmo
      * lesb_link_fail
      * lesb_vlink_fail
      * lesb_miss_fka
      * lesb_symb_err
      * lesb_err_block
      * lesb_fcs_error
      
      fcoe_fcf_device
      * fabric_name
      * switch_name
      * priority
      * selected
      * fc_map
      * vfid
      * mac
      * fka_peroid
      * fabric_state
      * dev_loss_tmo
      
      A device loss infrastructre similar to the FC Transport's
      is also added by this patch. It is nice to have so that a
      link flapping adapter doesn't continually advance the count
      used to identify the discovered FCF. FCFs will exist in a
      "Disconnected" state until either the timer expires or the
      FCF is rediscovered and becomes "Connected."
      
      This patch generates a few checkpatch.pl WARNINGS that
      I'm not sure what to do about. They're macros modeled
      around the FC Transport attribute building macros, which
      have the same 'feature' where the caller can ommit a cast
      in the argument list and no cast occurs in the code. I'm
      not sure how to keep the code condensed while keeping the
      macros. Any advice would be appreciated.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      9a74e884