- 17 Sep, 2015 40 commits
-
-
Kuba Pawlak authored
SCO packet reassembler may have a fragment of SCO packet, from previous connection, cached and not removed when SCO connection is ended. Packets from new SCO connection are then going to be attached to that fragment, creating an invalid SCO packets. Controllers like Intel's WilkinsPeak are always fragmenting SCO packet into 3 parts (#1, #2, #3). Packet #1 contains SCO header and audio data, others just audio data. if there is a fragment cached from previous connection, i.e. #1, first SCO packet from new connection is going to be attached to it creating packet consisting of fragments #1-#1-#2. This will be forwarded to upper layers. After that, fragment #3 is going to be used as a starting point for another SCO packet. It does not contain a SCO header, but the code expects it, casts a SCO header structure on it, and reads whatever audio data happens to be there as SCO packet length and handle. From that point on, we are assembling random data into SCO packets. Usually it recovers quickly as initial audio data contains mostly zeros (muted stream), but setups of over 4 seconds were observed. Issue manifests itself by printing on the console: Bluetooth: hci0 SCO packet for unknown connection handle 48 Bluetooth: hci0 SCO packet for unknown connection handle 2560 Bluetooth: hci0 SCO packet for unknown connection handle 12288 It may also show random handles if audio data was non-zeroed. Hcidump shows SCO packets with random length and handles. Few messages with handle 0 at connection creation are OK for some controllers (like WilkinsPeak), as there are SCO packets with zeroed handle at the beginning (possible controller bug). Few of such messages at connection end, with a handle looking sane (around 256, 512, 768 ...) is also OK, as these are last SCO packets that were assembled and sent up, before connection was ended, but were not handled in time. This issue may still manifest itself on WilkinsPeak as it sometimes, at SCO connection creation, does not send third fragment of first SCO packet (#1-#2-#1-#2-#3...). This is a firmware bug and this patch does not address it. Signed-off-by:
Kuba Pawlak <kubax.t.pawlak@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Loic Poulain authored
We need to explicitly enable the IRQ wakeup mode to let the controller wake the system from sleep states (like suspend-to-ram). PM suspend/resume callbacks now call the generic intel device PM functions after enabling/disabling IRQ wake. Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Signed-off-by:
-
Loic Poulain authored
Change the way to insert LPM packets into the txq. Use skb_queue_head instead of skb_queue_tail to always prioritise LPM packets over potential tx queue content. Signed-off-by:
-
Alexander Aring authored
This patch supports handling for printout different chipnames between atusb and rzusb. The rzusb contains an at86rf230 and atusb an at86rf231 transceiver. Cc: Stefan Schmidt <stefan@osg.samsung.com> Signed-off-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Marcel Holtmann authored
Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Frederic Danis authored
Retrieve the Interruption used by BCM device, which can be declared as Interruption or GpioInt in the ACPI table. Retrieve IRQ polarity from the ACPI table to use it for host_wake_active parameter of Setup Sleep vendor specific command. Configure BCM device to wake-up the host. Enable IRQ wake while suspended. Signed-off-by:
Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by:
-
Loic Poulain authored
btintel_load_ddc_config is now part of btintel. Signed-off-by:
-
Loic Poulain authored
Apply DDC parameters once controller is in operational mode. Signed-off-by:
-
Loic Poulain authored
btintel_load_ddc_config retrieves the ddc file and sends its content via DDC commands (opcode 0xfc8b). The ddc file should contain one or more DDC structures. A DDC structure is composed of the folowing fields: field: | DDC LEN | DDC ID | DDC VALUE | size: | 1 byte | 2 bytes | DDC LEN - 2 | Signed-off-by:
-
Loic Poulain authored
intel_lpm_suspend/resume are only used in case of CONFIG_PM. Signed-off-by:
-
Vincent Stehlé authored
Fix compilation the following compilation warning, which happens when CONFIG_BT_INTEL is not set: drivers/bluetooth/btintel.h:98:13: warning: ‘btintel_version_info’ defined but not used [-Wunused-function] static void btintel_version_info(struct hci_dev *hdev, struct intel_version *ver) ^ Signed-off-by:Vincent Stehlé <vincent.stehle@laposte.net> Signed-off-by:
-
Stefan Schmidt authored
Signed-off-by:
Stefan Schmidt <stefan@osg.samsung.com> Acked-by:
-
Stefan Schmidt authored
Signed-off-by:
-
Alexander Aring authored
This patch introduce a more detailed information why edge triggered irq's are currently not recommended. It could be that rising/falling edge detection can happen while the irq is disabled. Suggested-by:
-
Alexander Aring authored
This patch introduce debugfs support for collect trac status stats. To clear the stats ifdown the interface of at86rf230 and start the interface again. Signed-off-by:
-
Alexander Aring authored
To abort a TX_ARET_BUSY state it's recommended to switch into TRX_OFF state by doing STATE_TRX_FORCE_OFF. This patch will do always a TRX_OFF state change when the transceiver stucks in any state. From TRX_OFF we can switch to the states which are also possible by TX_ON state. Signed-off-by:
-
Alexander Aring authored
When transmit is done, indicated by trx_end irq, we do first a force state change to TX_ON and then checking the trac status, if the trac status is unequal zero we do a state change to TRX_OFF. This patch changes to the following behaviour, we first check on trac status after trx_end occurs and then doing a normal change to TX_ON without do the state change to TRX_OFF when trac status is unequal zero. The reasons are that the datasheet doesn't described when the trac status register is cleared, we should doing to evaluate the trac status at first. The reason to remove the TRX_OFF change if the trac status is unequal to zero and it was force is the following paragraph inside The at86rf2xx datasheets: "Using FORCE_PLL_ON to interrupt an TX_ARET transaction, it is recommended to check register bits [7:5] of register address 0x32 for value 0. If this value is different, TRX_CMD sequence FORCE_TRX_OFF shall be used immediately followed by TRX_CMD sequence PLL_ON. This performs a state transition to PLL_ON." The meaning is here "to interrupt an TX_ARET transaction" in case of trx_end interrupt the "TX_ARET transaction" is already done and we don't interrupt the "TX_ARET transaction" by doing the change to TX_ON (PLL_ON) here. Additional I changed the force change to normal TX_ON which seems to work here. Signed-off-by:
-
Stefan Schmidt authored
The ESC dispatch value has some history and it originally was 0x7f in rfc4944 (see section-5.1). With the release of rfc6282 this value got part of the LOWPAN_IPHC range and was no longer available for ESC. Instead 0x40 was used as replacement (see section-2 in rfc6282). We have been checking the dispatch byte in an order where IPHC would always be evaluated before ESC and thus we would never reach the ESC check as the IPHC range already covers this value. Signed-off-by:
-
Alexander Aring authored
This patch changes the return value of lowpan packet receive handler to the correct NET_RX_DROP instead RX_DROP. This issue was detected by sparse and reported from Marcel: net/ieee802154/6lowpan/rx.c:329:32: expected int net/ieee802154/6lowpan/rx.c:329:32: got restricted lowpan_rx_result ... Reported-by:
-
Alexander Aring authored
This patch removes a workaround for datagram_size calculation while doing fragmentation on transmit. Reviewed-by:
-
Alexander Aring authored
This patch remove the packet_type to host and leave the mac pkt_type. By running 'grep -r "pkt_type" net/ipv6', the IPv6 stack will evaluate this value for PACKET_BROADCAST. Instead of overwriting this value we will leave the mac value there which is broadcasts if the mac frame was a broadcast frame. Reviewed-by:
-
Alexander Aring authored
This patch adds frame control checks to check if the received frame is something which could contain a 6LoWPAN packet. Reviewed-by:
-
Alexander Aring authored
This patch adds checks for reserved dispatch value. When we have a reserved dispatch value we should drop the skb immediately. Reviewed-by:
-
Alexander Aring authored
This patch adds dummy handlers for all known IEEE 802.15.4 dispatch values which prints a warning that we don't support these dispatches right now. Also we add a warning to the RX_CONTINUE case inside of lowpan_rx_handlers_result which should now never happend. Reviewed-by:
-
Alexander Aring authored
This patch introduce an earlier check if a 6LoWPAN frame can be valid. This contains at first for checking if the header contains a dispatch byte and isn't the nalp dispatch value, which means it isn't a 6LoWPAN packet. Also we add a check if we can derference the dispatch value by checking if skb->len is unequal zero. Reviewed-by:
-
Alexander Aring authored
This patch complete reworks the evaluation of 6lowpan dispatch value by introducing a receive handler mechanism for each dispatch value. A list of changes: - Doing uncompression on-the-fly when FRAG1 is received, this require some special handling for 802.15.4 lltype in generic 6lowpan branch for setting the payload length correct. - Fix dispatch mask for fragmentation. - Add IPv6 dispatch evaluation for FRAG1. - Add skb_unshare for dispatch which might manipulate the skb data buffer. Cc: Jukka Rissanen <jukka.rissanen@linux.intel.com> Reviewed-by:
-
Alexander Aring authored
We should change the skb->dev pointer earlier to the lowpan interface Sometimes we call iphc_decompress which also use some netdev printout functionality. This patch will change that the correct interface will be displayed in this case, which should be the lowpan interface. Reviewed-by:
-
Alexander Aring authored
This patch moves some trivial checks at first before calling skb_share_check which could do some memcpy if the buffer is shared. Reviewed-by:
-
Alexander Aring authored
This patch cleanups the pull of the iphc bytes. We don't need to check if the skb->len contains two bytes, this will be checked by lowpan_fetch_skb_u8. Reviewed-by:
-
Alexander Aring authored
We don't need to check if the wpan interface is running because the lowpan_rcv is the packet layer receive handler for the wpan interface. Instead doing a check if wpan interface is running we should check if the lowpan interface is running before starting 6lowpan adaptation layer. Reviewed-by:
-
Alexander Aring authored
This function is used internally inside of ieee802154 6lowpan module only and not outside of any other module. We don't need to export this function then. Reviewed-by:
-
Alexander Aring authored
Internal mechanism by calling netdev_alloc which use kzalloc already sets these variables to zero. This patch cleanup the setup of net_device. Reviewed-by:
-
Alexander Aring authored
This patch removes one check on null which should be already done by checking before for ARPHRD_IEEE802154. All ARPHRD_IEEE802154 and ARPHRD_IEEE802154_MONITOR should have wdev->ieee802154_ptr, where ARPHRD_IEEE802154 is currently a node interface only. Reviewed-by:
-
Alexander Aring authored
This patch moves the open count handling while doing open of a lowpan interface. We need the packet handler register at first when one lowpan interface is up. There exists a small case when all lowpan interfaces are down and the 802154 packet layer is still registered. To reduce some overhead we will register the packet layer when the first lowpan interface comes up and unregister when the last interface will become down. Reviewed-by:
-
Alexander Aring authored
Inside the IEEE 802.15.4 6LoWPAN subsystem we use two interfaces which are wpan and lowpan interfaces. Instead of using always the variable name "dev" for both we rename the "dev" variable to wdev which means the wpan net_device and ldev which means a lowpan net_device. This avoids confusing and always looking back to see which net_device is meant by the variable name "dev". Reviewed-by:
-
Kieran Bingham authored
if btmrvl_tx_pkt() is called, and the branch if (skb_headroom(skb) < BTM_HEADER_LEN) evaluates positive, a new skb is allocated via skb_realloc_headroom. The original skb is stored in a tmp variable, before being free'd. However on success, the new skb, is not free'd, nor is it returned to the caller which will then double-free the original skb. This issue exists from the original driver submission in commit: #132ff4e5 If this code path had been alive, it would have been noted from the double-free causing a panic. All skb's here should be allocated through bt_skb_alloc which adds 8 bytes as headroom, which is plenty against the 4 bytes pushed on by this driver. This code path is dead, and buggy at the same time, so the cleanest approach is to remove the affected branch. Reported by coverity (CID 113422) Signed-off-by:
Kieran Bingham <kieranbingham@gmail.com> Signed-off-by:
-
Simon Fels authored
With 9380f9ea the order of unsetting the HCI_USER_CHANNEL flag of the HCI device was reverted to ensure the device is first closed before making it available again. Due to hci_dev_close checking for HCI_USER_CHANNEL being set on the device it was never really closed and was kept opened. We're now calling hci_dev_do_close directly to make sure the device is correctly closed and we keep the correct order to unset the flag on our device object. Signed-off-by:
Simon Fels <simon.fels@canonical.com> Signed-off-by:
-
Loic Poulain authored
Don't hide this packet size error. Signed-off-by:
-
Loic Poulain authored
Implement runtime PM suspend/resume callbacks. If LPM supported, controller is put into supsend after a delay of inactivity (1s). Inactivity is based on LPM idle notification and host TX traffic. Signed-off-by:
-
Loic Poulain authored
Add PM suspend/resume callbacks which call lpm_suspend/resume. Add LPM ack in threaded IRQ handler to notify the controller that resume is complete. Protect hci_uart against concurrent removing during suspend/resume. Signed-off-by:
-
