- 29 Jan, 2015 1 commit
-
-
Marcel Holtmann authored
The smp_unregister() function needs to be called every time the controller is powered down. There are multiple entry points when this can happen. One is "hciconfig hci0 reset" which will throw a WARN_ON when LE support has been enabled. [ 78.564620] WARNING: CPU: 0 PID: 148 at net/bluetooth/smp.c:3075 smp_register+0xf1/0x170() [ 78.564622] Modules linked in: [ 78.564628] CPU: 0 PID: 148 Comm: kworker/u3:1 Not tainted 3.19.0-rc4-devel+ #404 [ 78.564629] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS [ 78.564635] Workqueue: hci0 hci_rx_work [ 78.564638] ffffffff81b4a7a2 ffff88001cb2fb38 ffffffff8161d881 0000000080000000 [ 78.564642] 0000000000000000 ffff88001cb2fb78 ffffffff8103b870 696e55206e6f6f6d [ 78.564645] ffff88001d965000 0000000000000000 0000000000000000 ffff88001d965000 [ 78.564648] Call Trace: [ 78.564655] [<ffffffff8161d881>] dump_stack+0x4f/0x7b [ 78.564662] [<ffffffff8103b870>] warn_slowpath_common+0x80/0xc0 [ 78.564667] [<ffffffff81544b00>] ? add_uuid+0x1f0/0x1f0 [ 78.564671] [<ffffffff8103b955>] warn_slowpath_null+0x15/0x20 [ 78.564674] [<ffffffff81562d81>] smp_register+0xf1/0x170 [ 78.564680] [<ffffffff81081236>] ? lock_timer_base.isra.30+0x26/0x50 [ 78.564683] [<ffffffff81544bf0>] powered_complete+0xf0/0x120 [ 78.564688] [<ffffffff8152e622>] hci_req_cmd_complete+0x82/0x260 [ 78.564692] [<ffffffff8153554f>] hci_cmd_complete_evt+0x6cf/0x2e20 [ 78.564697] [<ffffffff81623e43>] ? _raw_spin_unlock_irqrestore+0x13/0x30 [ 78.564701] [<ffffffff8106b0af>] ? __wake_up_sync_key+0x4f/0x60 [ 78.564705] [<ffffffff8153a2ab>] hci_event_packet+0xbcb/0x2e70 [ 78.564709] [<ffffffff814094d3>] ? skb_release_all+0x23/0x30 [ 78.564711] [<ffffffff81409529>] ? kfree_skb+0x29/0x40 [ 78.564715] [<ffffffff815296c8>] hci_rx_work+0x1c8/0x3f0 [ 78.564719] [<ffffffff8105bd91>] ? get_parent_ip+0x11/0x50 [ 78.564722] [<ffffffff8105be25>] ? preempt_count_add+0x55/0xb0 [ 78.564727] [<ffffffff8104f65f>] process_one_work+0x12f/0x360 [ 78.564731] [<ffffffff8104ff9b>] worker_thread+0x6b/0x4b0 [ 78.564735] [<ffffffff8104ff30>] ? cancel_delayed_work_sync+0x10/0x10 [ 78.564738] [<ffffffff810542fa>] kthread+0xea/0x100 [ 78.564742] [<ffffffff81620000>] ? __schedule+0x3e0/0x980 [ 78.564745] [<ffffffff81054210>] ? kthread_create_on_node+0x180/0x180 [ 78.564749] [<ffffffff816246ec>] ret_from_fork+0x7c/0xb0 [ 78.564752] [<ffffffff81054210>] ? kthread_create_on_node+0x180/0x180 [ 78.564755] ---[ end trace 8b0d943af76d3736 ]--- This warning is not critical and has only been placed in the code to actually catch this exact situation. To avoid triggering it move the smp_unregister() into hci_dev_do_close() which will now also take care of remove the SMP channel. It is safe to call this function since it only remove the channel if it has been previously registered. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
- 28 Jan, 2015 13 commits
-
-
Marcel Holtmann authored
The Intel Bluetooth controllers can provide an additional exception info string when a hardware error event occurs. The core will now call hdev->hw_error to let the driver read out this information. This change will cause a reset of the hardware to bring it back into functional state and then read the Intel exception info string and print it along with the error information. Signed-off-by:
-
Marcel Holtmann authored
When receiving a HCI Hardware Error event, the controller should be assumed to be non-functional until issuing a HCI Reset command. The Bluetooth hardware errors are vendor specific and so add a new hdev->hw_error callback that drivers can provide to run extra code to handle the hardware error. After completing the vendor specific error handling perform a full reset of the Bluetooth stack by closing and re-opening the transport. Based-on-patch-by:
-
Marcel Holtmann authored
Split the hci_dev_reset ioctl handling into using hci_dev_do_reset helper function. Similar to what has been done with hci_dev_do_open and hci_dev_do_close. Signed-off-by:
-
Johan Hedberg authored
The discovery state should be set to stopped when the HCI device is powered off. This patch adds the appropriate call to the hci_discovery_set_state() function from hci_dev_do_close() which is responsible for the power-off procedure. Signed-off-by:
-
Johan Hedberg authored
When HCI_Reset is issued the discovery state is assumed to be stopped. The hci_cc_reset() handler was trying to set the state but it was doing it without using the hci_discovery_set_state() function. Because of this e.g. the mgmt Discovering event could go without being sent. This patch fixes the code to use the hci_discovery_set_state() function instead of just blindly setting the state value. Signed-off-by:
-
Johan Hedberg authored
There's a check in set_secure_conn() that's supposed to ensure that SSP is enabled before we try to request the controller to enable SC (since SSP is a pre-requisite for it). However, this check only makes sense for controllers actually supporting BR/EDR SC. If we have a 4.0 controller we're only interested in the LE part of SC and should therefore not be requiring SSP to be enabled. This patch adds an additional condition to check for lmp_sc_capable(hdev) before requiring SSP to be enabled. Signed-off-by:
-
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:
-
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: -
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:
-
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:
-
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:
-
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:
-
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:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
- 27 Jan, 2015 1 commit
-
-
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:
-
- 23 Jan, 2015 4 commits
-
-
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:Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
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:
-
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:
-
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:
-
- 22 Jan, 2015 4 commits
-
-
Marcel Holtmann authored
When BR/EDR is supported by a controller, then it is required to enable Secure Simple Pairing first before enabling the Secure Connections feature. Signed-off-by:
-
Marcel Holtmann authored
When a powered on dual-mode controller has been configured to operate as LE only with secure connections, then the BR/EDR side of things can not be switched back on. Do reconfigure the controller it first needs to be powered down. The secure connections feature is implemented in the BR/EDR controller while for LE it is implemented in the host. So explicitly forbid such a transaction to avoid inconsistent states. Signed-off-by:
-
Marcel Holtmann authored
The BR/EDR Secure Connections feature should only be enabled when the Secure Simple Pairing mode has been enabled first. However since secure connections is feature that is valid for BR/EDR and LE, this needs special handling. When enabling secure connections on a LE only configured controller, thent the BR/EDR side should not be enabled in the controller. This patches makes the BR/EDR Secure Connections feature depending on enabling Secure Simple Pairing mode first. Signed-off-by:
-
Szymon Janc authored
Start Discovery was reporting 0 RSSI for invalid RSSI only for BR/EDR devices. LE devices were reported with RSSI 127. Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
-
- 21 Jan, 2015 2 commits
-
-
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:
Rick Dunn <rick@rickdunn.com> Signed-off-by:
-
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:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
-
- 19 Jan, 2015 15 commits
-
-
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:
David S. Miller <davem@davemloft.net>
-
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:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
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:
Fugang Duan <B38611@freescale.com> Acked-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
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:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
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: -
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:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
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:
-
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:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
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: -
Praveen Madhavan authored
We have decided not to productize FCoE on T4. Hence file is removed. Signed-off-by:
Praveen Madhavan <praveenm@chelsio.com> Signed-off-by:
-
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:
-
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: -
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:
Wingman Kwok <w-kwok2@ti.com> Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
-
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:
-
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:
-
