summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-01-31Bluetooth: Fix OOB data present value for SMP pairingMarcel Holtmann
Before setting the OOB data present flag with SMP pairing, check the newly introduced present tracking that actual OOB data values have been provided. The existence of remote OOB data structure does not actually mean that the correct data values are available. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-31Bluetooth: Fix OOB data present value for BR/EDR Secure ConnectionsMarcel Holtmann
When BR/EDR Secure Connections has been enabled, the OOB data present value can take 2 additional values. The host has to clearly provide details about if P-192 OOB data, P-256 OOB data or a combination of P-192 and P-256 OOB data is present. In case BR/EDR Secure Connections is not enabled or not supported, then check that P-192 OOB data is actually present and return the correct value based on that. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-31Bluetooth: Store OOB data present value for each set of remote OOB dataMarcel Holtmann
Instead of doing complex calculation every time the OOB data is used, just calculate the OOB data present value and store it with the OOB data raw values. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-31Bluetooth: Set HCI_QUIRK_STRICT_DUPLICATE_FILTER for BTUSB_INTELJakub Pawlowski
The Bluetooth controllers from Intel use a strict scanning filter policy that filters based on Bluetooth device addresses and not on RSSI. So tell the core about this. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-30irda: use msecs_to_jiffies for conversionsNicholas Mc Guire
This is only an API consolidation and should make things more readable it replaces var * HZ / 1000 constructs by msecs_to_jiffies(var). Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30rhashtable: Make selftest modularGeert Uytterhoeven
Allow the selftest on the resizable hash table to be built modular, just like all other tests that do not depend on DEBUG_KERNEL. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30net: mark some potential candidates __read_mostlyDaniel Borkmann
They are all either written once or extremly rarely (e.g. from init code), so we can move them to the .data..read_mostly section. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30Merge branch 'cpsw_macid'David S. Miller
Tony Lindgren says: ==================== Changes to cpsw and davinci_emac for getting MAC address Here are a few patches to add common code for cpsw and davinci_emac for getting the MAC address. Looks like we can also now add code to get the MAC address on 3517 but in a slightly different way. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30net: davinci_emac: Get device MAC on 3517Tony Lindgren
Looks like on 3517 davinci_emac MAC address registers have a different layout compared to dm816x and am33xx. Let's add a function to get the 3517 MAC address. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30net: davinci_emac: Get device dm816x MAC address using the cpsw codeTony Lindgren
At least on dm81xx, we can get the davinci_emac MAC address the same way as on am33xx cpsw. Let's also use ether_addr_copy() for davinci_emac while at it. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30net: cpsw: Add a minimal cpsw-common module for shared codeTony Lindgren
Looks like davinci_emac and cpsw can share some code although the device registers have a different layout. At least the code for getting the MAC address using syscon can be shared by passing the register offset. Let's start with that and set up a minimal shared cpsw-shared.c. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-30Bluetooth: btusb: Use wait_on_bit_timeout() for BTUSB_BOOTINGJohan Hedberg
The wait_on_bit_timeout() is a simpler and race-free way of waiting for a bit to be cleared than the current code in btusb.c. This patch updates the code to use the helper function (its btusb copy - to be later updated to use a global one). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-30Bluetooth: btusb: Fix race when waiting for BTUSB_DOWNLOADINGJohan Hedberg
The test for BTUSB_DOWNLOADING must be after adding to the wait queue and setting the TASK_INTERRUPTIBLE state. Otherwise the flag may get cleared after we test for it and we end up getting a timeout since schedule_timeout() waits for the full duration. This patch uses a wait_on_bit_timeout() + wake_up_bit(). To perform the task both race-free as well as in a much simpler way. Since there's no global wait_on_bit_timeout() helper yet (even though all the building blocks for it are in place) this patch creates a temporary local btusb copy of it until the global one has made it to upstream trees. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-30Bluetooth: btusb: Limit hardware error handling to Intel Snowfield PeakMarcel Holtmann
In general all Intel Bluetooth devices support retrieving of additional exception information. However for older generations including Wilkens Peak and Stone Peak it is not as simple. So for now only enable the Intel specific error handling for Snowfield Peak and later devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-29Merge tag 'linux-can-next-for-3.20-20150128' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2015-28-01 this is a pull request of 12 patches for net-next/master. There are 3 patches by Ahmed S. Darwish, which update the kvaser_usb driver and add support for the USBcan-II based adapters. Stéphane Grosjean contributes 7 patches for the peak_usb driver, which add support for the CANFD USB adapters. I contribute 2 patches which clean up the peak_usb driver structure a bit. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-29net: gianfar: remove the unneeded check of disabled deviceKevin Hao
Since commit cd1e65044d44 ("of/device: Don't register disabled devices"), the disabled device will not be registered at all. So we don't need to do the check again in the platform device driver. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-29dev: add per net_device packet type chainsSalam Noureddine
When many pf_packet listeners are created on a lot of interfaces the current implementation using global packet type lists scales poorly. This patch adds per net_device packet type lists to fix this problem. The patch was originally written by Eric Biederman for linux-2.6.29. Tested on linux-3.16. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Salam Noureddine <noureddine@arista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-29rtnetlink: pass link_net to the newlink handlerNicolas Dichtel
When IFLA_LINK_NETNSID is used, the netdevice should be built in this link netns and moved at the end to another netns (pointed by the socket netns or IFLA_NET_NS_[PID|FD]). Existing user of the newlink handler will use the netns argument (src_net) to find a link netdevice or to check some other information into the link netns. For example, to find a netdevice, two information are required: an ifindex (usually from IFLA_LINK) and a netns (this link netns). Note: when using IFLA_LINK_NETNSID and IFLA_NET_NS_[PID|FD], a user may create a netdevice that stands in netnsX and with its link part in netnsY, by sending a rtnl message from netnsZ. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-29Bluetooth: Set HCI_QUIRK_STRICT_DUPLICATE_FILTER for BTUSB_ATH3012Jakub Pawlowski
The Bluetooth controllers from Atheros use a strict scanning filter policy that filters based on Bluetooth device addresses and not on RSSI. So tell the core about this. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-29Bluetooth: ath3k: workaround the compatibility issue with xHCI controllerAdam Lee
BugLink: https://bugs.launchpad.net/bugs/1400215 ath3k devices fail to load firmwares on xHCI buses, but work well on EHCI, this might be a compatibility issue between xHCI and ath3k chips. As my testing result, those chips will work on xHCI buses again with this patch. This workaround is from Qualcomm, they also did some workarounds in Windows driver. Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-29Bluetooth: Fix sending Read Remote Extended Features commandSzymon Janc
This command should only be used if remote device reports that it supports extended features. Otherwise command will fail and connection will be dropped. Some devices support SSP but don't support extended features so current check for SSP support is not enought. Instead of checking for SSP support just check if both ends support Extended Feature. < HCI Command: Create Connection (0x01|0x0005) plen 13 Address: D0:9C:30:00:19:6F (Foster Electric Company, Limited) Packet type: 0xcc18 DM1 may be used DH1 may be used DM3 may be used DH3 may be used DM5 may be used DH5 may be used Page scan repetition mode: R1 (0x01) Page scan mode: Mandatory (0x00) Clock offset: 0x94c8 Role switch: Allow slave (0x01) > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) ncmd 1 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 Status: Success (0x00) Handle: 5 Address: D0:9C:30:00:19:6F (Foster Electric Company, Limited) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 Handle: 5 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 Address: D0:9C:30:00:19:6F (Foster Electric Company, Limited) Page scan repetition mode: R1 (0x01) > HCI Event: Read Remote Supported Features (0x0b) plen 11 Status: Success (0x00) Handle: 5 Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x07 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Park state Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave LE Supported (Controller) 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Simultaneous LE and BR/EDR (Controller) Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Enhanced Power Control < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 Handle: 5 Page: 1 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Command Disallowed (0x0c) < HCI Command: Read Clock Offset (0x01|0x001f) plen 2 Handle: 5 > HCI Event: Command Status (0x0f) plen 4 Read Clock Offset (0x01|0x001f) ncmd 1 Status: Success (0x00) < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 5 Reason: Remote User Terminated Connection (0x13) Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-29nl80211: don't document per-wiphy interface dumpJohannes Berg
Such a feature doesn't exist and isn't really needed since you probably won't have enough interfaces to make it worthwhile, so just remove that from the documentation. Reported-by: booto [on IRC] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-01-29Bluetooth: btusb: Add support for USB based AMP controllersMarcel Holtmann
The Bluetooth HCI transport specification for USB device defines on how a standard AMP controller is identified and operated. This patch adds the needed handling to hook it up to the Bluetooth stack. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28pkt_sched: fq: remove useless TIME_WAIT checkEric Dumazet
TIME_WAIT sockets are not owning any skb. ip_send_unicast_reply() and tcp_v6_send_response() both use regular sockets. We can safely remove a test in sch_fq and save one cache line miss, as sk_state is far away from sk_pacing_rate. Tested at Google for about one year. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-28act_connmark: fix dependencies betterArnd Bergmann
NET_ACT_CONNMARK fails to build if NF_CONNTRACK_MARK is disabled, and d7924450e14ea4 ("act_connmark: Add missing dependency on NF_CONNTRACK_MARK") fixed that case, but missed the cased where NF_CONNTRACK is a loadable module. This adds the second dependency to ensure that NET_ACT_CONNMARK can only be built-in if NF_CONNTRACK is also part of the kernel rather than a loadable module. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-28net: remove sock_iocbChristoph Hellwig
The sock_iocb structure is allocate on stack for each read/write-like operation on sockets, and contains various fields of which only the embedded msghdr and sometimes a pointer to the scm_cookie is ever used. Get rid of the sock_iocb and put a msghdr directly on the stack and pass the scm_cookie explicitly to netlink_mmap_sendmsg. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-28hisilicon: add some missing curly bracesDan Carpenter
The if block was supposed to have curly braces. In the current code we complain about dropped rx packets when we shouldn't. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-28openvswitch: Add support for checksums on UDP tunnels.Jesse Gross
Currently, it isn't possible to request checksums on the outer UDP header of tunnels - the TUNNEL_CSUM flag is ignored. This adds support for requesting that UDP checksums be computed on transmit and properly reported if they are present on receive. Signed-off-by: Jesse Gross <jesse@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-28Merge tag 'nfc-next-3.20-1' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next NFC: 3.20 first pull request This is the first NFC pull request for 3.20. With this one we have: - Secure element support for the ST Micro st21nfca driver. This depends on a few HCI internal changes in order for example to support more than one secure element per controller. - ACPI support for NXP's pn544 HCI driver. This controller is found on many x86 SoCs and is typically enumerated on the ACPI bus there. - A few st21nfca and st21nfcb fixes. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-29Bluetooth: btusb: Ignore unknown Intel devices with generic descriptorMarcel Holtmann
The Intel Bluetooth devices use the generic USB device/interface class descriptors that are assigned to Bluetooth H:2 conforming transports. T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 However newer chips have a bootloader stage and require firmware to be loaded before they are functional. To avoid any confusion for the users, just ignore unknown Intel Bluetooth devices. All the released Intel Bluetooth devices have an entry in the device table identifying their setup and support requirements. The advantage here is that older kernel can be booted with newer devices without causing any disturbance. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-29Bluetooth: btusb: Sort USB_DEVICE entries for Marvell by vendor idMarcel Holtmann
New entries to the USB blacklist/quirk device table should be sorted by USB vendor id. Fix the recent entry fro Marvell devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-29Bluetooth: Move smp_unregister() into hci_dev_do_close() functionMarcel Holtmann
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>
2015-01-28Bluetooth: btusb: Provide hardware error handler for Intel devicesMarcel Holtmann
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Perform a power cycle when receiving hardware error eventMarcel Holtmann
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Introduce hci_dev_do_reset helper functionMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Fix notifying discovery state when powering offJohan Hedberg
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-28Bluetooth: Fix notifying discovery state upon resetJohan Hedberg
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-28Bluetooth: Fix check for SSP when enabling SCJohan Hedberg
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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-28Bluetooth: btusb: Remove redundant call to btusb_free_frags()Johan Hedberg
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-28Bluetooth: btusb: Handle out of order firmware loading complete eventMarcel Holtmann
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Check for P-256 OOB values in Secure Connections Only modeMarcel Holtmann
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Use helper function to determine BR/EDR OOB data presentMarcel Holtmann
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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Clear P-192 values for OOB when in Secure Connections Only modeMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28Bluetooth: Enforce zero-valued hash/rand192 for LE OOBJohan Hedberg
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: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-01-28Bluetooth: btusb: Add firmware loading for Intel Snowfield Peak devicesMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-28can: peak_usb: add support for PEAK new CANFD USB adaptersStephane Grosjean
Add support for the following new PEAK-System technik CANFD USB adapters: PCAN-USB FD single CANFD channel USB adapter PCAN-USB Pro FD dual CANFD channels USB adapter Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Acked-by: Andri Yngvason <andri.yngvason@marel.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-28can: peak_usb: add peak_usb_netif_rx() new functionStephane Grosjean
Add a common function that pushes the skb in the network queue with adding timestamps information, converted from time values read from the PEAK USB adapters. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-28can: peak_usb: export pcan_usb_pro functionsStephane Grosjean
Add support for the following new PEAK-System technik CANFD USB adapters: PCAN-USB FD single CANFD channel USB adapter PCAN-USB Pro FD dual CANFD channels USB adapter The communication protocol has been developed using some mechanisms that did exist in the PCAN-USB Pro, thus, this patch also changes some previously static functions and data into global ones. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-28can: peak_usb: upgrade core to new struct canfd_frameStephane Grosjean
Upgrade PEAK-System USB adapters core to the new data structures (names) and callbacks added for the support of the CANFD extension. This specific patch includes changes that deal with the new struct canfd_frame. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2015-01-28can: peak_usb: upgrade core to data bittiming specsStephane Grosjean
Upgrade PEAK-System USB adapters core to the new data structures (names) and callbacks added for the support of the CANFD extension. This specific patch does the mandatory changes to support new data bittiming specs. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 10:15:45 +0000