1. 28 Jan, 2015 7 commits
    • Johan Hedberg's avatar
      Bluetooth: btusb: Remove redundant call to btusb_free_frags() · 838f66e3
      Johan Hedberg authored
      The btusb_disconnect() callback calls hci_unregister_dev() which in turn
      calls btusb_close() if the HCI device is powered. The btusb_close()
      function in turn will call btusb_free_frags(). It's therefore
      unnecessary to have another call to btusb_free_frags() in the
      btusb_disconnect() function. Besides the redundancy the second call
      seems to also cause some strange stability issues which this patch then
      also fixes.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      838f66e3
    • Marcel Holtmann's avatar
      Bluetooth: btusb: Handle out of order firmware loading complete event · ce6bb929
      Marcel Holtmann authored
      When loading the Intel firmware it can happen that the firmware loading
      complete vendor event arrives before the command complete event for the
      last firmware fragment.
      
      < HCI Command: Vendor (0x3f|0x0009) plen 7
              01 02 fc 03 00 00 00
      > HCI Event: Vendor (0xff) plen 5
              06 00 00 00 00
      > HCI Event: Command Complete (0x0e) plen 4
            Vendor (0x3f|0x0009) ncmd 31
              Status: Success (0x00)
      
      This is mainly caused by the fact that the vendor command and its
      command complete event are transported over the bulk endpoints. The
      firmware loading complete event however is send over the interrupt
      endpoint. So with just bad timing one event arrives before the other.
      
      Currently the code does not account for it. There are precautions for
      receiving firmware loading complete event quickly, but not for receiving
      it before the command complete.
      
      Introduce an extra flag that tracks when the firmware sending has
      completed from the driver point of view and track the completion of
      the firmware loading procedure with a different flag. That way the
      wakeup can be handled properly.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      ce6bb929
    • Marcel Holtmann's avatar
      Bluetooth: Check for P-256 OOB values in Secure Connections Only mode · aa5b0345
      Marcel Holtmann authored
      If Secure Connections Only mode has been enabled, the it is important
      to check that OOB data for P-256 values is provided. In case it is not,
      then tell the remote side that no OOB data is present.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      aa5b0345
    • Marcel Holtmann's avatar
      Bluetooth: Use helper function to determine BR/EDR OOB data present · a83ed81e
      Marcel Holtmann authored
      When replying to the IO capability request for Secure Simple Pairing and
      Secure Connections, the OOB data present fields needs to set. Instead of
      making the calculation inline, split this into a separate helper
      function.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a83ed81e
    • Marcel Holtmann's avatar
      Bluetooth: Clear P-192 values for OOB when in Secure Connections Only mode · 6665d057
      Marcel Holtmann authored
      When Secure Connections Only mode has been enabled and remote OOB data
      is requested, then only provide P-256 hash and randomizer vaulues. The
      fields for P-192 hash and randomizer should be set to zero.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6665d057
    • Johan Hedberg's avatar
      Bluetooth: Enforce zero-valued hash/rand192 for LE OOB · d25b78e2
      Johan Hedberg authored
      Until legacy SMP OOB pairing is implemented user space should be given a
      clear error when trying to use it. This patch adds a corresponding check
      to the Add Remote OOB Data handler function which returns "invalid
      parameters" if non-zero Rand192 or Hash192 parameters were given for an
      LE address.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d25b78e2
    • Marcel Holtmann's avatar
      Bluetooth: btusb: Add firmware loading for Intel Snowfield Peak devices · cda0dd78
      Marcel Holtmann authored
      The Intel Snowfield Peak devices do not come with Bluetooth firmware
      loaded and thus require a full download of the operational Bluetooth
      firmware when the device is connected via USB.
      
      Snowfield Peak devices start with a bootloader mode that only accepts
      a very limited set of HCI commands. The supported commands are enough
      to identify the hardware and select the right firmware to load.
      
      Previous patches to the btusb driver allow overwriting the handling
      for bulk receive endpoint packets and HCI events processing. The
      firmware loading makes heavy use of these new internal callbacks.
      
      This patch also introduces additional internal states to track if the
      device is in bootloader or operational mode. This allows for correct
      feedback about the firmware loading procedure.
      
      Output from /sys/kernel/debug/usb/devices for this device:
      
      T:  Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=8087 ProdID=0a2b Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Based-on-patch-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      cda0dd78
  2. 27 Jan, 2015 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: btusb: Add support for Dynex/Insignia USB dongles · d049f4e5
      Marcel Holtmann authored
      The Dynex/Insignia USB dongles are Broadcom BCM20702B0 based and require
      firmware update before operation.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=19ff ProdID=0239 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      Since this is an unsual USB vendor ID (0x19ff), these dongles are added
      via USB_DEVICE macro and not USB_VENDOR_AND_INTERFACE_INFO as done for
      mainstream Broadcom based dongles.
      
      The latest known working firmware is BCM20702B0_002.001.014.0527.0557.hex
      which needs to be converted using hex2hcd utility and then installed
      as /lib/firmware/brcm/BCM20702A0-19ff-0239.hcd to make this device fully
      operational.
      
      Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=2000 lmp_ver=06 lmp_subver=410e
      Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=222d lmp_ver=06 lmp_subver=410e
      
      With this firmware the device reports support for connectionless slave
      broadcast (master and slave) feature used by 3D Glasses and TVs.
      
        < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1
                Page: 2
        > HCI Event: Command Complete (0x0e) plen 14
              Read Local Extended Features (0x04|0x0004) ncmd 1
                Status: Success (0x00)
                Page: 2/2
                Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                  Connectionless Slave Broadcast - Master
                  Connectionless Slave Broadcast - Slave
                  Synchronization Train
                  Synchronization Scan
      
      However there are some flaws with this feature. The Set Event Mask Page 2
      command is actually not supported and with that all connectionless slave
      broadcast events are always enabled.
      
        < HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8
                Mask: 0x00000000000f0000
                  Synchronization Train Received
                  Connectionless Slave Broadcast Receive
                  Connectionless Slave Broadcast Timeout
                  Truncated Page Complete
        > HCI Event: Command Complete (0x0e) plen 4
              Set Event Mask Page 2 (0x03|0x0063) ncmd 1
                Status: Unknown HCI Command (0x01)
      
      In addition the Synchronization Train Received event is actually broken
      on this controller. It mixes up the order of parameters. According to the
      Bluetooth Core specification the fields are like this:
      
        struct hci_ev_sync_train_received {
                __u8     status;
                bdaddr_t bdaddr;
                __le32   offset;
                __u8     map[10];
                __u8     lt_addr;
                __le32   instant;
                __le16   interval;
                __u8     service_data;
        } __packed;
      
      This controller however sends the service_data as 5th parameter instead
      of having it as last parameter.
      
        struct hci_ev_sync_train_received {
                __u8     status;
                bdaddr_t bdaddr;
                __le32   offset;
                __u8     map[10];
                __u8     service_data;
                __u8     lt_addr;
                __le32   instant;
                __le16   interval;
        } __packed;
      
      So anybody trying to use this hardware for utilizing connectionless slave
      broadcast receivers (aka 3D Glasses), be warned about this shortcoming.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      d049f4e5
  3. 23 Jan, 2015 4 commits
    • Peter Hurley's avatar
      Bluetooth: Fix nested sleeps · dfb2fae7
      Peter Hurley authored
      l2cap/rfcomm/sco_sock_accept() are wait loops which may acquire
      sleeping locks. Since both wait loops and sleeping locks use
      task_struct.state to sleep and wake, the nested sleeping locks
      destroy the wait loop state.
      
      Use the newly-minted wait_woken() and DEFINE_WAIT_FUNC() for the
      wait loop. DEFINE_WAIT_FUNC() allows an alternate wake function
      to be specified; in this case, the predefined scheduler function,
      woken_wake_function(). This wait construct ensures wakeups will
      not be missed without requiring the wait loop to set the
      task state before condition evaluation. How this works:
      
       CPU 0                            |  CPU 1
                                        |
                                        | is <condition> set?
                                        | no
      set <condition>                   |
                                        |
      wake_up_interruptible             |
        woken_wake_function             |
          set WQ_FLAG_WOKEN             |
          try_to_wake_up                |
                                        | wait_woken
                                        |   set TASK_INTERRUPTIBLE
                                        |   WQ_FLAG_WOKEN? yes
                                        |   set TASK_RUNNING
                                        |
                                        | - loop -
      				  |
      				  | is <condition> set?
                                        | yes - exit wait loop
      
      Fixes "do not call blocking ops when !TASK_RUNNING" warnings
      in l2cap_sock_accept(), rfcomm_sock_accept() and sco_sock_accept().
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      dfb2fae7
    • Johan Hedberg's avatar
      Bluetooth: Convert Set SC to use HCI Request · a1443f5a
      Johan Hedberg authored
      This patch converts the Set Secure Connection HCI handling to use a HCI
      request instead of using a hard-coded callback in hci_event.c. This e.g.
      ensures that we don't clear the flags incorrectly if something goes
      wrong with the power up process (not related to a mgmt Set SC command).
      
      The code can also be simplified a bit since only one pending Set SC
      command is allowed, i.e. mgmt_pending_foreach usage is not needed.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a1443f5a
    • Johan Hedberg's avatar
      Bluetooth: Remove incorrect check for BDADDR_BREDR address type · 484aabc1
      Johan Hedberg authored
      The Add Remote OOB Data mgmt command should allow data to be passed for
      LE as well. This patch removes a left-over check for BDADDR_BREDR that
      should not be there anymore.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      484aabc1
    • Johan Hedberg's avatar
      Bluetooth: Check for valid bdaddr in add_remote_oob_data · 5d57e796
      Johan Hedberg authored
      Before doing any other verifications, the add_remote_oob_data function
      should first check that the given address is valid. This patch adds such
      a missing check to the beginning of the function.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5d57e796
  4. 22 Jan, 2015 4 commits
  5. 21 Jan, 2015 2 commits
    • Rick Dunn's avatar
      Bluetooth: btusb: Add Broadcom patchram support for ASUSTek devices · 9a5abdaa
      Rick Dunn authored
      T:  Bus=03 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0b05 ProdID=17cf Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=54271E3298CD
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      Firmware is extracted from the latest Broadcom BCM4352 Windows driver
      by extracting the zip and searching the .hex file names for '17cf'.
      
      The hex file must then be converted to hcd format using the hex2hcd
      utility and then moved to /lib/firmware/brcm/.
      Signed-off-by: default avatarRick Dunn <rick@rickdunn.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      9a5abdaa
    • Dmitry Tunin's avatar
      Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device · 033efa92
      Dmitry Tunin authored
      Add support of 13d3:3423 device.
      
      BugLink: https://bugs.launchpad.net/bugs/1411193
      
      T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=13d3 ProdID=3423 Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
      E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
      E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
      I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
      I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
      I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
      I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
      I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
      Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      033efa92
  6. 19 Jan, 2015 22 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-next-for-davem-2015-01-19' of... · 0c490874
      David S. Miller authored
      Merge tag 'mac80211-next-for-davem-2015-01-19' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
      
      Some further updates for net-next:
       * fix network-manager which was broken by the previous changes
       * fix delete-station events, which were broken by me making the
         genlmsg_end() mistake
       * fix a timer left running during suspend in some race conditions
         that would cause an annoying (but harmless) warning
       * (less important, but in the tree already) remove 80+80 MHz rate
         reporting since the spec doesn't distinguish it from 160 MHz;
         as the bitrate they're both 160 MHz bandwidth
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c490874
    • Johannes Berg's avatar
      phonet netlink: allow multiple messages per skb in route dump · 926e9878
      Johannes Berg authored
      My previous patch to this file changed the code to be bug-compatible
      towards userspace. Unless userspace (which I wasn't able to find)
      implements the dump reader by hand in a wrong way, this isn't needed.
      If it uses libnl or similar code putting multiple messages into a
      single SKB is far more efficient.
      
      Change the code to do this. While at it, also clean it up and don't
      use so many variables - just store the address in the callback args
      directly.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      926e9878
    • Nimrod Andy's avatar
      ARM: dts: imx6sx: correct i.MX6sx sdb board enet phy address · fc834777
      Nimrod Andy authored
      The commit (3d125f9c) cause i.MX6SX sdb enet cannot work. The cause is
      the commit add mdio node with un-correct phy address.
      
      The patch just correct i.MX6sx sdb board enet phy address.
      Signed-off-by: default avatarFugang Duan <B38611@freescale.com>
      Acked-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc834777
    • Felix Fietkau's avatar
      net: sched: Introduce connmark action · 22a5dc0e
      Felix Fietkau authored
      This tc action allows you to retrieve the connection tracking mark
      This action has been used heavily by openwrt for a few years now.
      
      There are known limitations currently:
      
      doesn't work for initial packets, since we only query the ct table.
        Fine given use case is for returning packets
      
      no implicit defrag.
        frags should be rare so fix later..
      
      won't work for more complex tasks, e.g. lookup of other extensions
        since we have no means to store results
      
      we still have a 2nd lookup later on via normal conntrack path.
      This shouldn't break anything though since skb->nfct isn't altered.
      
      V2:
      remove unnecessary braces (Jiri)
      change the action identifier to 14 (Jiri)
      Fix some stylistic issues caught by checkpatch
      V3:
      Move module params to bottom (Cong)
      Get rid of tcf_hashinfo_init and friends and conform to newer API (Cong)
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22a5dc0e
    • David S. Miller's avatar
      Merge branch 'dsa-next' · cbcd1fa7
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: DSA fixes for bridge and ip-autoconf
      
      These two patches address some real world use cases of the DSA master and slave
      network devices.
      
      You have already seen patch 1 previously and you rejected it since my
      explanations were not good enough to provide a justification as to why it is
      useful, hopefully this time my explanation is better.
      
      Patch 2 solves a different, yet very real problem as well at the bridge layer
      when using DSA network devices.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbcd1fa7
    • Florian Fainelli's avatar
      net: bridge: reject DSA-enabled master netdevices as bridge members · 8db0a2ee
      Florian Fainelli authored
      DSA-enabled master network devices with a switch tagging protocol should
      strip the protocol specific format before handing the frame over to
      higher layer.
      
      When adding such a DSA master network device as a bridge member, we go
      through the following code path when receiving a frame:
      
      __netif_receive_skb_core
      	-> first ptype check against ptype_all is not returning any
      	   handler for this skb
      
      	-> check and invoke rx_handler:
      		-> deliver frame to the bridge layer: br_handle_frame
      
      DSA registers a ptype handler with the fake ETH_XDSA ethertype, which is
      called *after* the bridge-layer rx_handler has run. br_handle_frame()
      tries to parse the frame it received from the DSA master network device,
      and will not be able to match any of its conditions and jumps straight
      at the end of the end of br_handle_frame() and returns
      RX_HANDLER_CONSUMED there.
      
      Since we returned RX_HANDLER_CONSUMED, __netif_receive_skb_core() stops
      RX processing for this frame and returns NET_RX_SUCCESS, so we never get
      a chance to call our switch tag packet processing logic and deliver
      frames to the DSA slave network devices, and so we do not get any
      functional bridge members at all.
      
      Instead of cluttering the bridge receive path with DSA-specific checks,
      and rely on assumptions about how __netif_receive_skb_core() is
      processing frames, we simply deny adding the DSA master network device
      (conduit interface) as a bridge member, leaving only the slave DSA
      network devices to be bridge members, since those will work correctly in
      all circumstances.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8db0a2ee
    • Florian Fainelli's avatar
      net: ipv4: handle DSA enabled master network devices · 728c0208
      Florian Fainelli authored
      The logic to configure a network interface for kernel IP
      auto-configuration is very simplistic, and does not handle the case
      where a device is stacked onto another such as with DSA. This causes the
      kernel not to open and configure the master network device in a DSA
      switch tree, and therefore slave network devices using this master
      network devices as conduit device cannot be open.
      
      This restriction comes from a check in net/dsa/slave.c, which is
      basically checking the master netdev flags for IFF_UP and returns
      -ENETDOWN if it is not the case.
      
      Automatically bringing-up DSA master network devices allows DSA slave
      network devices to be used as valid interfaces for e.g: NFS root booting
      by allowing kernel IP autoconfiguration to succeed on these interfaces.
      
      On the reverse path, make sure we do not attempt to close a DSA-enabled
      device as this would implicitely prevent the slave DSA network device
      from operating.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      728c0208
    • Ben Hutchings's avatar
      mii: Handle link state changes for forced modes in mii_check_media() · 5bdc7380
      Ben Hutchings authored
      mii_check_media() does not update the link (carrier) state or log link
      changes when the link mode is forced.  Drivers using the mii library
      must do this themselves, but most of them do not.
      
      Instead of changing them all, provide a sensible default behaviour
      similar to mii_check_link() when the mode is forced.
      
      via-rhine depends on it being a no-op in this case, so make its call
      to mii_check_media() conditional.
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5bdc7380
    • David S. Miller's avatar
      Merge branch 'csiostor' · 8f1115b4
      David S. Miller authored
      Praveen Madhavan says:
      
      ====================
      csiostor: Remove T4 FCoE support
      
      We found a subtle issue with FCoE on T4 very late in the game
      and decided not to productize FCoE on T4 and therefore there
      are no customers that will be impacted by this change. FCoE is
      supported on T5 cards.
      
      Please apply on net-next since depends on previous commits.
      
      Changes in v2:
        - Make the commit message more clearer.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f1115b4
    • Praveen Madhavan's avatar
      csiostor:Removed file csio_hw_t4.c · d3944315
      Praveen Madhavan authored
      We have decided not to productize FCoE on T4.
      Hence file is removed.
      Signed-off-by: default avatarPraveen Madhavan <praveenm@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3944315
    • Praveen Madhavan's avatar
      csiostor:Remove T4 FCoE Support. · 3fb4c22e
      Praveen Madhavan authored
      We found a subtle issue with FCoE on T4 very late in the game
      and decided not to productize FCoE on T4 and therefore there
      are no customers that will be impacted by this change. Hence
      T4 FCoE support is removed. FCoE supported only on T5 cards.
      
      changes in v2:
        - Make the commit message more clearer.
      Signed-off-by: default avatarPraveen Madhavan <praveenm@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3fb4c22e
    • David S. Miller's avatar
      Merge branch 'netcp' · b66a4eaa
      David S. Miller authored
      Murali Karicheri says:
      
      ====================
      net: Add Keystone NetCP ethernet driver support
      
      The Network Coprocessor (NetCP) is a hardware accelerator that processes
      Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
      switch sub-module to send and receive packets. NetCP also includes a packet
      accelerator (PA) module to perform packet classification operations such as
      header matching, and packet modification operations such as checksum
      generation. NetCP can also optionally include a Security Accelerator(SA)
      capable of performing IPSec operations on ingress/egress packets.
      
      Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
      includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
      1Gb/s rates per Ethernet port.
      
      Both GBE and XGBE network processors supported using common driver. It
      is also designed to handle future variants of NetCP.
      
      version history
      ---------------
      v7->v8
      
       - Reworked comments against v7, related to checker warning.
       - Patch 2/4 that has all of the driver code in v7 is now split into 3
         patches based on functionality so that we have 3 smaller patches
         review instead of a big patch.
       - Patch for MAINTAINER is merged to 2/4 along with netcp core driver
       - Separate patch (3/4) for 1G and  (4/4) for 10G
       - Removed big endian support for initial version (will add it later)
      
      v6->v7
       - Fixed some minor documentation error and also modified the netcp driver
         to fix the set* functions to include correct le/be macros.
      
      v5->v6
       - updated version after incorporating comments [6] from David Miller,
         David Laight & Geert Uytterhoeven on v5. I would like get this in
         for v3.19 merge window if the latest version is acceptable.
      
      v4->v5
       - Sorry to spin v5 quickly but I missed few check-patch warnings which
         were pointed by Joe Perches(thanks). I folded his changes [5] along with
         few more check-patch warning fixes. I would like get this in for v3.18
         merge window if David is happy with this version.
      
      v3->v4
       - Couple of fixes in in error path as pointed [4] out by David. Rest of
         the patches are unchanged from v3.
      
      v2->v3
       - Update v3 after incorporating Jamal and David Miller's comment/suggestion
         from earlier versions [1] [2].  After per the discussion here [3], the
         controversial custom exports have been dropped now. And for future
         future offload support additions, we will plug into generic frameworks
         as an when they are available.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b66a4eaa
    • Wingman Kwok's avatar
      net: netcp: Enhance GBE driver to support 10G Ethernet · 90cff9e2
      Wingman Kwok authored
      This patch enhances the NetCP gbe driver to support 10GbE subsystem
      available in Keystone NetCP. The 3-port 10GbE switch sub-module contains
      the following components:- 10GbE Switch, MDIO Module, 2 PCS-R Modules
      (10GBase-R) and 2 SGMII modules (10/100/1000Base-T). The GBE driver
      together with netcp core driver provides support for 10G Ethernet
      on Keystone SoCs.
      
      10GbE hardware spec is available at
      
      http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spruhj5&fileType=pdf
      
       Cc: David Miller <davem@davemloft.net>
       Cc: Rob Herring <robh+dt@kernel.org>
       Cc: Grant Likely <grant.likely@linaro.org>
       Cc: Santosh Shilimkar <santosh.shilimkar@kernel.org>
       Cc: Pawel Moll <pawel.moll@arm.com>
       Cc: Mark Rutland <mark.rutland@arm.com>
       Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
       Cc: Kumar Gala <galak@codeaurora.org>
      Signed-off-by: default avatarWingman Kwok <w-kwok2@ti.com>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90cff9e2
    • Wingman Kwok's avatar
      net: netcp: Add Keystone NetCP GbE driver · 6f8d3f33
      Wingman Kwok authored
      This patch add support for 1G Ethernet driver based on Keystone
      NetCP hardware. The gigabit Ethernet (GbE) switch subsystem is one of the main
      components of the network coprocessor (NETCP) peripheral. The purpose of the
      gigabit Ethernet switch subsystem in the NETCP is to provide an interface to
      transfer data between the host device and another connected device in
      compliance with the Ethernet protocol. GbE consists of 5 port Ethernet Switch
      module, 4 Serial Gigabit Media Independent Interface (SGMII) modules, MDIO
      module and SerDes.
      
      Driver for 5 port GbE switch and SGMII module is added in this patch. These
      hardware modules along with netcp core driver provides Network driver functions
      for 1G Ethernet.
      
      Detailed hardware spec is available at
      
      http://www.ti.com/lit/ug/sprugv9d/sprugv9d.pdf
      
       Cc: David Miller <davem@davemloft.net>
       Cc: Rob Herring <robh+dt@kernel.org>
       Cc: Grant Likely <grant.likely@linaro.org>
       Cc: Santosh Shilimkar <santosh.shilimkar@kernel.org>
       Cc: Pawel Moll <pawel.moll@arm.com>
       Cc: Mark Rutland <mark.rutland@arm.com>
       Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
       Cc: Kumar Gala <galak@codeaurora.org>
      Signed-off-by: default avatarWingman Kwok <w-kwok2@ti.com>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f8d3f33
    • Karicheri, Muralidharan's avatar
      net: netcp: Add Keystone NetCP core ethernet driver · 84640e27
      Karicheri, Muralidharan authored
      The network coprocessor (NetCP) is a hardware accelerator available in
      Keystone SoCs that processes Ethernet packets. NetCP consists of following
      hardware components
      
       1 Gigabit Ethernet (GbE) subsystem with a Ethernet switch sub-module to
         send and receive packets.
       2 Packet Accelerator (PA) module to perform packet classification
         operations such as header matching, and packet modification operations
         such as checksum generation.
       3 Security Accelerator(SA) capable of performing IPSec operations on
         ingress/egress packets.
       4 An optional 10 Gigabit Ethernet Subsystem (XGbE) which includes a
         3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates
         per Ethernet port.
       5 Packet DMA and Queue Management Subsystem (QMSS) to enqueue and dequeue
         packets and DMA the packets between memory and NetCP hardware components
         described above.
      
      NetCP core driver make use of the Keystone Navigator driver API to allocate
      DMA channel for the Ethenet device and to handle packet queue/de-queue,
      Please refer API's in include/linux/soc/ti/knav_dma.h and
      drivers/soc/ti/knav_qmss.h for details.
      
      NetCP driver consists of NetCP core driver and at a minimum Gigabit
      Ethernet (GBE) module (1) driver to implement the Network device function.
      Other modules (2,3) can be optionally added to achieve supported hardware
      acceleration function. The initial version of the driver include NetCP
      core driver and GBE driver modules.
      
      Please refer Documentation/devicetree/bindings/net/keystone-netcp.txt
      for design of the driver.
      
       Cc: David Miller <davem@davemloft.net>
       Cc: Rob Herring <robh+dt@kernel.org>
       Cc: Grant Likely <grant.likely@linaro.org>
       Cc: Santosh Shilimkar <santosh.shilimkar@kernel.org>
       Cc: Pawel Moll <pawel.moll@arm.com>
       Cc: Mark Rutland <mark.rutland@arm.com>
       Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
       Cc: Kumar Gala <galak@codeaurora.org>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarWingman Kwok <w-kwok2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84640e27
    • Karicheri, Muralidharan's avatar
      Documentation: dt: net: Add binding doc for Keystone NetCP ethernet driver · 44eefcdf
      Karicheri, Muralidharan authored
      The network coprocessor (NetCP) is a hardware accelerator that processes
      Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
      switch sub-module to send and receive packets. NetCP also includes a packet
      accelerator (PA) module to perform packet classification operations such as
      header matching, and packet modification operations such as checksum
      generation. NetCP can also optionally include a Security Accelerator(SA)
      capable of performing IPSec operations on ingress/egress packets.
      
      Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
      includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
      1Gb/s rates per Ethernet port.
      
      NetCP Subsystem device tree layout looks something like below:
      
      -----------------------------
        NetCP subsystem(10G or 1G)
      -----------------------------
      	|
      	|-> NetCP Devices ->	|
      	|			|-> GBE/XGBE Switch
      	|			|
      	|			|-> Packet Accelerator
      	|			|
      	|			|-> Security Accelerator
      	|
      	|
      	|
      	|-> NetCP Interfaces ->	|
      				|-> Ethernet Port 0
      				|
      				|-> Ethernet Port 1
      				|
      				|-> Ethernet Port 2
      				|
      				|-> Ethernet Port 3
      
      Common driver supports GBE as well XGBE network processors.
      
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Santosh Shilimkar <santosh.shilimkar@kernel.org>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44eefcdf
    • Felipe Balbi's avatar
      net: ethernet: ti: cpsw: fix buld break when NET_POLL_CONTROLLER · 92cb13fb
      Felipe Balbi authored
      Commit c03abd84 (net: ethernet: cpsw: don't requests IRQs we don't
      use) left one build breakage when NET_POLL_CONTROLLER is enabled.
      
      Fix this build break by referring to the correct irqs_table array.
      
      Fixes: c03abd84 (net: ethernet: cpsw: don't requests IRQs we don't use)
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92cb13fb
    • David S. Miller's avatar
      Merge branch 'link_netns' · 7f9091f0
      David S. Miller authored
      Merge branch 'link_netns'
      
      Nicolas Dichtel says:
      
      ====================
      netns: allow to identify peer netns
      
      The goal of this serie is to be able to multicast netlink messages with an
      attribute that identify a peer netns.
      This is needed by the userland to interpret some information contained in
      netlink messages (like IFLA_LINK value, but also some other attributes in case
      of x-netns netdevice (see also
      http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
      http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).
      
      Ids of peer netns can be set by userland via a new rtnl cmd RTM_NEWNSID. When
      the kernel needs an id for a peer (for example when advertising a new x-netns
      interface via netlink), if the user didn't allocate an id, one will be
      automatically allocated.
      These ids are stored per netns and are local (ie only valid in the netns where
      they are set). To avoid allocating an int for each peer netns, I use
      idr_for_each() to retrieve the id of a peer netns. Note that it will be possible
      to add a table (struct net -> id) later to optimize this lookup if needed.
      
      Patch 1/4 introduces the rtnetlink API mechanism to set and get these ids.
      Patch 2/4 and 3/4 implements an example of how to use these ids when advertising
      information about a x-netns interface.
      And patch 4/4 shows that the netlink messages can be symetric between a GET and
      a SET.
      
      iproute2 patches are available, I can send them on demand.
      
      Here is a small screenshot to show how it can be used by userland.
      
      $ ip netns add foo
      $ ip netns del foo
      $ ip netns
      $ touch /var/run/netns/init_net
      $ mount --bind /proc/1/ns/net /var/run/netns/init_net
      $ ip netns add foo
      $ ip -n foo netns
      foo
      init_net
      $ ip -n foo netns set init_net 0
      $ ip -n foo netns set foo 1
      
      $ ip netns
      foo
      init_net
      $ ip -n foo netns
      foo (id: 1)
      init_net (id: 0)
      
      $ ip -n foo link add ipip1 link-netnsid 0 type ipip remote 10.16.0.121 local 10.16.0.249
      $ ip -n foo link ls ipip1
      6: ipip1@NONE: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
          link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 0
      
      $ ip netns
      foo
      init_net
      $ ip -n foo link add ipip2 type ipip remote 10.16.0.121 local 10.16.0.249
      $ ip -n foo link set ipip2 netns init_net
      $ ip link ls ipip2
      7: ipip2@NONE: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
          link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 0
      $ ip netns
      foo (id: 0)
      init_net
      
      v4 -> v5:
        use rtnetlink instead of genetlink
        allocate automatically an id if user didn't assign one
        rename include/uapi/linux/netns.h to include/uapi/linux/net_namespace.h
        add vxlan in patch #3
      
      RFCv3 -> v4:
        rebase on net-next
        add copyright text in the new netns.h file
      
      RFCv2 -> RFCv3:
        ids are now defined by userland (via netlink). Ids are stored in each netns
        (and they are local to this netns).
        add get_link_net support for ip6 tunnels
        netnsid is now a s32 instead of a u32
      
      RFCv1 -> RFCv2:
        remove useless ()
        ids are now stored in the user ns. It's possible to get an id for a peer netns
        only if the current netns and the peer netns have the same user ns parent.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f9091f0
    • Nicolas Dichtel's avatar
      rtnl: allow to create device with IFLA_LINK_NETNSID set · 317f4810
      Nicolas Dichtel authored
      This patch adds the ability to create a netdevice in a specified netns and
      then move it into the final netns. In fact, it allows to have a symetry between
      get and set rtnl messages.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      317f4810
    • Nicolas Dichtel's avatar
      tunnels: advertise link netns via netlink · 1728d4fa
      Nicolas Dichtel authored
      Implement rtnl_link_ops->get_link_net() callback so that IFLA_LINK_NETNSID is
      added to rtnetlink messages.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1728d4fa
    • Nicolas Dichtel's avatar
      rtnl: add link netns id to interface messages · d37512a2
      Nicolas Dichtel authored
      This patch adds a new attribute (IFLA_LINK_NETNSID) which contains the 'link'
      netns id when this netns is different from the netns where the interface
      stands (for example for x-net interfaces like ip tunnels).
      With this attribute, it's possible to interpret correctly all advertised
      information (like IFLA_LINK, etc.).
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d37512a2
    • Nicolas Dichtel's avatar
      netns: add rtnl cmd to add and get peer netns ids · 0c7aecd4
      Nicolas Dichtel authored
      With this patch, a user can define an id for a peer netns by providing a FD or a
      PID. These ids are local to the netns where it is added (ie valid only into this
      netns).
      
      The main function (ie the one exported to other module), peernet2id(), allows to
      get the id of a peer netns. If no id has been assigned by the user, this
      function allocates one.
      
      These ids will be used in netlink messages to point to a peer netns, for example
      in case of a x-netns interface.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c7aecd4