-off-by missing
> author email:raghuram.he...@intel.com
> committer email: mar...@holtmann.org
> Signed-off-by: Amit K Bag
> Signed-off-by: Tumkur Narayan, Chethan
>
> Signed-off-by: Marcel Holtmann
>
> Also, in the same patch:
Hi Luiz,
>>> If user decides to cancel ongoing pairing process (e.g. by clicking
>>> the cancel button on the pairing/passkey window), abort any ongoing
>>> pairing and then terminate the link.
>>>
>>> Signed-off-by: Manish Mandlik
>>> ---
>>> Hello Linux-Bluetooth,
>>>
>>> This patch aborts an
Hi Luiz,
>>> If user decides to cancel ongoing pairing process (e.g. by clicking
>>> the cancel button on the pairing/passkey window), abort any ongoing
>>> pairing and then terminate the link.
>>>
>>> Signed-off-by: Manish Mandlik
>>> ---
>>> Hello Linux-Bluetooth,
>>>
>>> This patch aborts an
sers to use it.
>
> IMO, it would be easiest to take all these patches through the crypto
> tree. But taking just the "crypto:" ones and then me trying to get the
> rest merged later via subsystem trees is also an option.
I am fine if you take the net/bluetooth/smp.c change through the crypto tree.
Acked-by: Marcel Holtmann
Regards
Marcel
Hi Alistair,
> Add binding document for bluetooth part of RTL8723BS/RTL8723CS
>
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Alistair Francis
> ---
> .../bindings/net/realtek-bluetooth.yaml | 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Document
Hi Alistair,
> Add binding document for bluetooth part of RTL8723BS/RTL8723CS
>
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Alistair Francis
> ---
> .../bindings/net/realtek-bluetooth.yaml | 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Document
Hi Alistair,
> The sopine board has an optional RTL8723BS WiFi + BT module that can be
> connected to UART1. Add this to the device tree so that it will work
> for users if connected.
>
> Signed-off-by: Alistair Francis
> ---
> .../allwinner/sun50i-a64-sopine-baseboard.dts | 29 +
Hi Alistair,
> The sopine board has an optional RTL8723BS WiFi + BT module that can be
> connected to UART1. Add this to the device tree so that it will work
> for users if connected.
>
> Signed-off-by: Alistair Francis
> ---
> .../allwinner/sun50i-a64-sopine-baseboard.dts | 29 +
Hi Manish,
> If user decides to cancel ongoing pairing process (e.g. by clicking
> the cancel button on the pairing/passkey window), abort any ongoing
> pairing and then terminate the link.
>
> Signed-off-by: Manish Mandlik
> ---
> Hello Linux-Bluetooth,
>
> This patch aborts any ongoing pairi
Hi Manish,
> If user decides to cancel ongoing pairing process (e.g. by clicking
> the cancel button on the pairing/passkey window), abort any ongoing
> pairing and then terminate the link.
>
> Signed-off-by: Manish Mandlik
> ---
> Hello Linux-Bluetooth,
>
> This patch aborts any ongoing pairi
Hi Christian,
> This series adds a new compatible for the QCA9377 BT device that is found
> in many Android TV box devices, makes minor changes to allow max-speed
> values for the device to be read from device-tree, and updates bindings
> to reflect those changes.
>
> v2 changes: rebase against b
Hi Christian,
> This series adds a new compatible for the QCA9377 BT device that is found
> in many Android TV box devices, makes minor changes to allow max-speed
> values for the device to be read from device-tree, and updates bindings
> to reflect those changes.
>
> v2 changes: rebase against b
Hi Arnd,
>>> I noticed earlier this week that the HCI_CMSG_TSTAMP/HCI_TIME_STAMP
>>> interface has no time64 equivalent, as we apparently missed that when
>>> converting the normal socket timestamps to support both time32 and time64
>>> variants of the sockopt and cmsg data.
> ...
>>> When using H
Hi Arnd,
> I noticed earlier this week that the HCI_CMSG_TSTAMP/HCI_TIME_STAMP
> interface has no time64 equivalent, as we apparently missed that when
> converting the normal socket timestamps to support both time32 and time64
> variants of the sockopt and cmsg data.
>
> The interface was origina
Hi Adam,
As nice as it would be to update firmware faster, that patch broke
at least two different boards, an OMAP4+WL1285 based Motorola Droid
4, as reported by Sebasian Reichel and the Logic PD i.MX6Q +
WL1837MOD.
This reverts commit a2e02f38eff84f199c8e32359eb213f
Hi Sebastian,
> All users of this driver have been converted to the serdev based
> hci_ll driver. The unused driver can be safely dropped now.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/bluetooth/Kconfig| 11 --
> drivers/bluetooth/Makefile | 1 -
>>>
Hi Sebastian,
>>> All users of this driver have been converted to the serdev based
>>> hci_ll driver. The unused driver can be safely dropped now.
>>>
>>> Signed-off-by: Sebastian Reichel
>>> ---
>>> drivers/bluetooth/Kconfig| 11 --
>>> drivers/bluetooth/Makefile | 1 -
>>> drivers/bluet
Hi Jeffrey,
> This reverts commit cde9dde6e11a5ab54b6462cd46d82878926783bc.
>
> The frame reassembly errors were root caused to a transient gpio issue.
> The missing response was root caused to an issue with properly managing
> RFR in the uart driver. Addressing those root causes occurs outside
Hi Jeffrey,
> On the msm8998 mtp, the response to the baudrate change command is
> never
> received. On the Lenovo Miix 630, the response to the baudrate change
> command is corrupted - "Frame reassembly failed (-84)".
>
> Adding a 50ms delay befo
Hi Matthias,
>> On the msm8998 mtp, the response to the baudrate change command is never
>> received. On the Lenovo Miix 630, the response to the baudrate change
>> command is corrupted - "Frame reassembly failed (-84)".
>>
>> Adding a 50ms delay before re-enabling flow to re
Hi Nathan,
> When building with Clang and CONFIG_BT_INTEL unset, the following error
> occurs:
>
> In file included from drivers/bluetooth/hci_ldisc.c:34:
> drivers/bluetooth/btintel.h:188:2: error: void function
> 'btintel_reset_to_bootloader' should not return a value [-Wreturn-type]
>r
Hi Bjorn,
> Clean up the regulator usage in hci_qca and in particular don't
> regulator_set_voltage() for fixed voltages. It cleans up the driver, but more
> important it makes bluetooth work on my Lenovo Yoga C630, where the regulator
> for vddch0 is defined with a voltage range that doesn't over
Hi Jeffrey,
> On the msm8998 mtp, the response to the baudrate change command is never
> received. On the Lenovo Miix 630, the response to the baudrate change
> command is corrupted - "Frame reassembly failed (-84)".
>
> Adding a 50ms delay before re-enabling flow to receive the baudrate change
Hi Mattijs,
> During the setup() stage, HCI device drivers expect the chip to
> acknowledge its setup() completion via vendor specific frames.
>
> If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
> the vendor specific frames are never tranmitted to the driver, as
> they are filt
Hi Mattijs,
> Some HCI devices which have the HCI_QUIRK_NON_PERSISTENT_SETUP [1]
> require a call to setup() to be ran after every open().
>
> During the setup() stage, these devices expect the chip to acknowledge
> its setup() completion via vendor specific frames.
>
> If userspace opens() such
Hi Sebastian,
> All users of this driver have been converted to the serdev based
> hci_ll driver. The unused driver can be safely dropped now.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/bluetooth/Kconfig| 11 --
> drivers/bluetooth/Makefile | 1 -
> drivers/bluetooth/btwilink.c
tooth/hci_core.c:846:28:got unsigned short [usertype]
>> le_max_tx_time
>>
>> Signed-off-by: Ben Dooks
>> ---
>> Cc: Marcel Holtmann
>> Cc: Johan Hedberg
>> Cc: "David S. Miller"
>> Cc: linux-blueto...@vger.kernel.org
>> Cc: net..
x_len
> net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment
> (different base types)
> net/bluetooth/hci_core.c:846:28:expected restricted __le16 [usertype]
> tx_time
> net/bluetooth/hci_core.c:846:28:got unsigned short [usertype]
> le_max_tx_time
&
Hi Adam,
> As nice as it would be to update firmware faster, that patch broke
> at least two different boards, an OMAP4+WL1285 based Motorola Droid
> 4, as reported by Sebasian Reichel and the Logic PD i.MX6Q +
> WL1837MOD.
>
> This reverts commit a2e02f38eff84f199c8e32359eb213f81f270047.
>
> Si
Hi Arnd,
> The btusb_rtl_cmd_timeout() function is used inside of an
> ifdef, leading to a warning when this part is hidden
> from the compiler:
>
> drivers/bluetooth/btusb.c:530:13: error: unused function
> 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function]
>
> Use an IS_ENABLED() check inste
Hi Christophe,
> 'skb_pad()' a few lines above already initializes the "padded" byte to 0.
> So there is no need to do it twice.
>
> All what is needed is to increase the len of the skb. So 'skb_put(..., 1)'
> is enough here.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/bluetooth/hci_n
Hi Yue,
> On Sep 23, 2019, at 16:05, YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> net/bluetooth/smp.c: In function 'smp_irk_matches':
> net/bluetooth/smp.c:505:18: warning:
> variable 'smp' set but not used [-Wunused-but-set-variable]
>
> net/bluetooth/smp.c: In fun
Hi Rui,
> v2: also remove new line from hci_h5.c
>
> The rtl_dev_* calls in the Realtek USB Bluetooth driver add unnecessary
> device prefixes and new lines at the end of most messages, which make the
> dmesg output look like this:
>
> [5.667121] sd 0:0:0:0: [sda] Attached SCSI disk
> [5
Hi Max,
> It does not need the '-' for PTR_ERR(skb) because PTR_ERR(skb) will
> return the negative value during errors.
>
> Signed-off-by: Max Chou
> ---
> drivers/bluetooth/btrtl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Hi Arnd,
>>> The btusb_rtl_cmd_timeout() function is used inside of an
>>> ifdef, leading to a warning when this part is hidden
>>> from the compiler:
>>>
>>> drivers/bluetooth/btusb.c:530:13: error: unused function
>>> 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function]
>>>
>>> Use an IS_ENABL
Hi Arnd,
> The btusb_rtl_cmd_timeout() function is used inside of an
> ifdef, leading to a warning when this part is hidden
> from the compiler:
>
> drivers/bluetooth/btusb.c:530:13: error: unused function
> 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function]
>
> Use an IS_ENABLED() check inste
Hi Bob,
>>> For user experience scanning and DHCP are also important, what kind of >
>>> numbers you get when those are included? No need to have anything> precise,
>>> I would like just to get an understanding where we are> nowadays.
>>
>> Scanning heavily depends on the RF environment and t
Hi Mark,
> In embedded environments the requirements are to be able to pick and
> chose which features one requires built into the kernel. If an
> embedded environment wants to supports loading modules that have been
> kbuilt out of tree, there is a need to enable hidden configurations
> for core
Hi Dan,
>>> Commit 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return
>>> number of queued bytes") changed hidp_send_message to return non-zero
>>> values on success, which some other bits did not expect. This caused
>>> spurious errors to be propagated through the stack, breaking some (
Hi Jiri,
>> hidp_send_message was changed to return non-zero values on success,
>> which some other bits did not expect. This caused spurious errors to be
>> propagated through the stack, breaking some drivers, such as hid-sony
>> for the Dualshock 4 in Bluetooth mode.
>>
>> As pointed out by Dan
Hi Dan,
> Commit 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return
> number of queued bytes") changed hidp_send_message to return non-zero
> values on success, which some other bits did not expect. This caused
> spurious errors to be propagated through the stack, breaking some (all?)
>
Hi Alex,
> Realtek Bluetooth controller provides a BT_DIS reset pin for hardware
> reset of it. The cmd_timeout is helpful on Realtek bluetooth controller
> where the firmware gets stuck.
>
> Signed-off-by: Alex Lu
> ---
> Changes in v2
> - Provide a dedicated btusb_rtl_cmd_timeout in case of R
Hi Max,
> Fix the issue that when the FW size is 32K+, it will fail for the download
> process because of the incorrect index.
>
> When firmware patch length is over 32K, "dl_cmd->index" may >= 0x80. It
> will be thought as "data end" that download process will not complete.
> However, driver sho
Hi Gustavo,
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct mgmt_rp_get_connections {
> ...
>struct mgm
Hi Alex,
> Realtek Bluetooth controller provides a BT_DIS reset pin for hardware
> reset of it. The cmd_timeout is helpful on Realtek bluetooth controller
> where the firmware gets stuck.
>
> Signed-off-by: Alex Lu
> ---
> drivers/bluetooth/btusb.c | 29 +
> 1 file cha
Hi Maxime,
> (Resend to add missing lists, sorry for the noise.)
>
> This series implements bluetooth support for Xunlong Orange Pi 3 board.
>
> The board uses AP6256 WiFi/BT 5.0 chip.
>
> Summary of changes:
>
> - add more delay to let initialize the chip
>
Hi Navid,
> When returning from bpa10x_send_frame, it is necessary to propagate any
> potential errno returned from usb_submit_urb.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/bluetooth/bpa10x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-ne
Hi Jian,
> The ASUS X412FA laptop contains a Realtek RTL8822CE device with an
> associated BT chip using a USB ID of 04ca:4005. This ID is added to the
> driver.
>
> The /sys/kernel/debug/usb/devices portion for this device is:
>
> T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 4 Spd=12 MxCh=
Hi Harish,
> Looks like Deadlock is observed in hci_qca while performing
> stress and stability tests. Since same lock is getting
> acquired from qca_wq_awake_rx and hci_ibs_tx_idle_timeout
> seeing spinlock recursion, irqs should be disable while
> acquiring the spinlock always.
>
> Signed-off-b
Hi Max,
> Fix the issue that when the FW size is 32K+, it will fail for the download
> process because of the incorrect index.
>
> Signed-off-by: Max Chou
> ---
> drivers/bluetooth/btrtl.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btrtl.c b
Hi Alex,
> the rtl: or RTL: prefix in the string is pointless. The rtl_dev_* macros
> already does that.
>
> Signed-off-by: Alex Lu
> ---
> drivers/bluetooth/btrtl.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marc
Hi Alex,
> These printing macros already add a trailing newline, so drop these
> unnecessary additional newlines.
>
> Signed-off-by: Alex Lu
> ---
> drivers/bluetooth/btrtl.c | 56 +++
> 1 file changed, 28 insertions(+), 28 deletions(-)
patch has been applied
Hi Alex,
> This patch is used to print fw version for debug convenience
>
> Signed-off-by: Alex Lu
> ---
> Changes in v3
> - Remove the pointless rtl: prefix in the format string
> Changes in v2
> - Re-order the code so that no forward declaration is needed
>
> drivers/bluetooth/btrtl.c | 56
Hi Alex,
> This patch is used to print fw version for debug convenience
>
> Signed-off-by: Alex Lu
> ---
> Changes in v2
> - Re-order the code so that no forward declaration is needed
>
> drivers/bluetooth/btrtl.c | 56 ---
> 1 file changed, 35 insertions(+),
Hi Alex,
> Realtek Bluetooth controllers can do both LE scan and BR/EDR inquiry
> at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk.
>
> Signed-off-by: Alex Lu
> ---
> drivers/bluetooth/btrtl.c | 5 +
> 1 file changed, 5 insertions(+)
patch has been applied to bluetooth-next tree.
Hi Alex,
> This patch is used to print fw version for debug convenience
>
> Signed-off-by: Alex Lu
> ---
> drivers/bluetooth/btrtl.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> index b7487ab99eed..7219eb98d02d
Hi Harish,
> When SoC receives pre shut down command, it share the same
> with other COEX shared clients. So SoC needs a short time
> after sending VS pre shutdown command before turning off
> the regulators and sending the power off pulse. Along with
> short delay, needs to wait for command compl
Hi Maxime,
>>> (Resend to add missing lists, sorry for the noise.)
>>>
>>> This series implements bluetooth support for Xunlong Orange Pi 3 board.
>>>
>>> The board uses AP6256 WiFi/BT 5.0 chip.
>>>
>>> Summary of changes:
>>>
>>> - add more delay to let initialize the chip
>>> - let the kerne
Hi Harish,
> When SoC receives pre shut down command, it share the same
> with other COEX shared clients. So SoC needs a short time
> after sending VS pre shutdown command before turning off
> the regulators and sending the power off pulse. Along with
> short delay, needs to wait for command compl
Hi Ondrej,
> (Resend to add missing lists, sorry for the noise.)
>
> This series implements bluetooth support for Xunlong Orange Pi 3 board.
>
> The board uses AP6256 WiFi/BT 5.0 chip.
>
> Summary of changes:
>
> - add more delay to let initialize the chip
> - let the kernel detect firmware fi
Hi Michal,
> This reverts commit a0085f2510e8976614ad8f766b209448b385492f.
>
> After this commit systems wake up at random, most commonly when
>
> - put to sleep while bluetooth audio stream is running
> - connected bluetooth audio device is powered off while system is
> asleep
>
> This is brok
Hi Rocky,
> QCA UART Bluetooth controllers can do both LE scan and BR/EDR inquiry
> at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk.
>
> Signed-off-by: Rocky Liao
> ---
> drivers/bluetooth/hci_qca.c | 5 +
> 1 file changed, 5 insertions(+)
patch has been applied to bluetooth-next
Hi Mario,
> This reverts commit a0085f2510e8976614ad8f766b209448b385492f.
>
> This commit has caused regressions in notebooks that support suspend
> to idle such as the XPS 9360, XPS 9370 and XPS 9380.
>
> These notebooks will wakeup from suspend to idle from an unsolicited
> advertising packet
Hi Johannes,
>>> No, as usual, that would break ABI. PAD is a regular attribute, just
>>> empty and ignored for aligning 64-bit values.
>>
>> then I do not grok on how the nla_put_u64_64bit works, but that is
>> fine.
>>
>> I assumed these are similar to the NL80211_SURVEY_INFO_MAX which we
>> a
Hi Johannes,
>> ... [snip]
>
> Please trim quotes a bit.
>
>>> NL80211_SURVEY_INFO_PAD,
>>> + NL80211_SURVEY_INFO_TIME_BSS_RX,
>>
>> wouldn’t this go before the PAD attribute?
>
> No, as usual, that would break ABI. PAD is a regular attribute, just
> empty and ignored for aligning 64-bit
Hi Felix,
> This is useful for checking how much airtime is being used up by other
> transmissions on the channel, e.g. by calculating (time_rx - time_bss_rx)
> or (time_busy - time_bss_rx - time_tx)
>
> Signed-off-by: Felix Fietkau
> ---
> include/net/cfg80211.h | 4
> include/uapi/li
Hi Brian,
>> And if you have a distribution or an OEM that cares, then that is what is
>> going to happen.
>
> I can see where you might not be particularly sympathetic to this
> concern, but where I re-started this thread, I added in Jouni, due to
> his mention of:
>
> "There are such drivers
Hi Brian,
>>> Well, I guess we could just run the command and look for EOPNOTSUPP...
>>
>> this kind of API design and usage is bad. Try-and-error approach is just not
>> sustainable.
>
> Sure. That "suggestion" was quite literally an afterthought. Not
> really a proper suggestion.
>
>> Even w
Hi Brian,
>> So I guess you'd have to figure out what operations the drivers need to
>> support then? I'm not even sure how wpa_s would handle this for SME
>> offload devices.
>
> I'm not intimately familiar with FT, but it looks like the only thing
> wpa_supplicant is asking for is NL80211_CMD_U
Hi Johannes,
>>> Also, I don't really buy the *need* for this since you're just removing
>>> a few kernel/user roundtrips here when new devices are discovered, a
>>> rare event. The parsing isn't really any more complicated for the
>>> userspace side.
>>
>> that is an argument that is coming to b
Hi Nishka,
> Static structure qca_proto, of type hci_uart_proto, is used four times:
> as the last argument in function hci_uart_register_device(), and as the
> only argument to functions hci_uart_register_proto() and
> hci_uart_unregister_proto(). In all three of these functions, the
> parameter
Hi Nishka,
> Static variable header_ops, of type header_ops, is used only once, when
> it is assigned to field header_ops of a variable having type net_device.
> This corresponding field is declared as const in the definition of
> net_device. Hence make header_ops constant as well to protect it fr
Hi Alex,
> From the perspective of controller, global suspend means there is no
> SET_FEATURE (DEVICE_REMOTE_WAKEUP) and controller would drop the
> firmware. It would consume less power. So we should not send this kind
> of SET_FEATURE when host goes to suspend state.
> Otherwise, when making dev
Hi Rocky,
> Don't fall through to print error message when receive sleep indication
> in HCI_IBS_RX_ASLEEP state, this is allowed behavior.
>
> Signed-off-by: Rocky Liao
> ---
> drivers/bluetooth/hci_qca.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
patch has been applied to blue
Hi Yue,
> If CONFIG_ACPI is not set, gcc warn this:
>
> drivers/bluetooth/hci_bcm.c:831:39: warning:
> acpi_bcm_int_last_gpios defined but not used [-Wunused-const-variable=]
> drivers/bluetooth/hci_bcm.c:838:39: warning:
> acpi_bcm_int_first_gpios defined but not used [-Wunused-const-variable=]
Hi Matthias,
> The qca_data structure is allocated with kzalloc() and hence
> zero-initialized. Remove a bunch of unnecessary explicit
> initializations of struct members to zero.
>
> Signed-off-by: Matthias Kaehlcke
> Reviewed-by: Balakrishna Godavarthi
> ---
> just noticed that this patch fel
Hi Claire,
> commit 32646db8cc28 ("Bluetooth: btqca: inject command complete event
> during fw download") added qca_inject_cmd_complete_event() for certain
> qualcomm chips. However, qca_download_firmware() will return without
> calling release_firmware() in this case.
>
> This leads to a memory
Hi Alex,
> usb reset resume will cause downloading firmware again and
> requesting firmware may be failed while host is resuming
>
> Signed-off-by: Alex Lu
> ---
> drivers/bluetooth/btrtl.c | 101 --
> 1 file changed, 97 insertions(+), 4 deletions(-)
>
> diff
Hi Alex,
> From the perspective of controller, global suspend means there is no
> SET_FEATURE (DEVICE_REMOTE_WAKEUP) and controller would drop the
> firmware. It would consume less power. So we should not send this kind
> of SET_FEATURE when host goes to suspend state.
> Otherwise, when making dev
tooth/rfcomm/sock.c | 14 --
> 2 files changed, 12 insertions(+), 8 deletions(-)
I think it is best if this series is applied as a whole. So whoever takes it
Acked-by: Marcel Holtmann
Regards
Marcel
conversion
> here.
>
> Signed-off-by: Arnd Bergmann
> ---
> fs/compat_ioctl.c| 24
> net/bluetooth/hci_sock.c | 21 -
> 2 files changed, 20 insertions(+), 25 deletions(-)
I think it is best if this series is applied as a whole
Hi Johannes,
>> +/*
>> + * auto-detect support for large buffer sizes: af_netlink
>> + * will allocate skbufs larger than 4096 in cases where
>> + * it detects that the client receive buffer (given to
>> + * recvmsg) is bigger. In such c
Hi Alex,
> From the perspective of controller, global suspend means there is no
> SET_FEATURE (DEVICE_REMOTE_WAKEUP) and controller would drop the
> firmware. It would consume less power. So we should not send this kind
> of SET_FEATURE when host goes to suspend state.
> Otherwise, when making dev
Hi Vladis,
> Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
> functions which are called by the certain HCI UART protocols (hci_ath,
> hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
> or directly. This leads to an execution at NULL and can be trigge
uetooth
chip wcn3990")
Signed-off-by: Vladis Dronov
Signed-off-by: Marcel Holtmann
---
drivers/bluetooth/hci_ath.c | 3 +++
drivers/bluetooth/hci_bcm.c | 3 +++
drivers/bluetooth/hci_intel.c | 3 +++
drivers/bluetooth/hci_ldisc.c | 13 +
drivers/bluetooth/hci_mr
Hi Vladis,
> Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
> functions which are called by the certain HCI UART protocols (hci_ath,
> hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
> or directly. This leads to an execution at NULL and can be trigge
Hi Vladis,
>> why is this one hidden behind CONFIG_PM? The general baud rate changes are
>> independent of runtime power management support.
>
> hci_bcm calls hci_uart_set_flow_control() only from functions hidden behind
> #ifdef-CONFIG_PM (surely this can change in the future), and so without
>
Hi Dmitry,
>> syzbot found the following crash on:
>>
>> HEAD commit:6d21a41b Add linux-next specific files for 20190718
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1377958fa0
>> kernel config:
>> https://syzkall
Hi Vladis,
> Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
> functions which are called by the certain HCI UART protocols (hci_ath,
> hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
> or directly. This leads to an execution at NULL and can be trigge
Hi Dmitry,
syzbot found the following crash on:
HEAD commit:6d21a41b Add linux-next specific files for 20190718
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1377958fa0
kernel config: https://syzkaller.appspot.com/x/.co
Hi Dmitry,
>> syzbot found the following crash on:
>>
>> HEAD commit:6d21a41b Add linux-next specific files for 20190718
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1377958fa0
>> kernel config: https://syzkaller.appspot.com/x/.config?x=3430a
Hi Jia-Ju,
> In hci_mgmt_cmd(), there is an if statement on line 1570 to check
> whether hdev is NULL:
>if (hdev && chan->hdev_init)
>
> When hdev is NULL, it is used on line 1575:
>err = handler->func(sk, hdev, cp, len);
>
> Some called functions of handler->func use hdev, such as:
> se
Hi Kai-Heng,
> When Intel 8260 starts to load Bluetooth firmware and WiFi firmware, by
> calling btintel_download_firmware() and iwl_pcie_load_given_ucode_8000()
> respectively, the Bluetooth btintel_download_firmware() aborts half way:
> [ 11.950216] Bluetooth: hci0: Failed to send firmware dat
Hi Harish,
> WCN399x chips are coex chips, it needs a VS pre shutdown
> command while turning off the BT. So that chip can inform
> BT is OFF to other active clients.
>
> Signed-off-by: Harish Bandi
> ---
> drivers/bluetooth/btqca.c | 21 +
> drivers/bluetooth/btqca.h | 7
Hi Matthias,
> The opcode of the command injected by commit 32646db8cc28 ("Bluetooth:
> btqca: inject command complete event during fw download") uses the CPU
> byte format, however it should always be little endian. In practice it
> shouldn't really matter, since all we need is an opcode != 0, bu
Hi Matthias,
> On WCN3990 downloading the NVM sometimes fails with a "TLV response
> size mismatch" error:
>
> [ 174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA
> Downloading qca/crnv21.bin
> [ 174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV
> response siz
Hi,
> Fixed a coding style issue
>
> Signed-off-by: Sheetal Singala <2396shee...@gmail.com>
> ---
> drivers/bluetooth/btintel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
> index bb99c8653aab..4a8b812605f3 100
Hi Sean,
> v7:
> * rebase to latest code base.
>
> v6:
> * fix drivers/bluetooth/btusb.c:2683:2-3: Unneeded semicolon based reported
> by [1]
> * update power-on sequence with adding neccesary tci sleep comand to set up
> low-power environmnet and a delay to wait the device to be stable.
> * so
Hallo Sascha,
> First two patches are a fix for the Marvell HCI driver which fails to
> properly upload the firmware. Third patch adds simple serdev support
> to the driver.
>
> Sascha
>
> Sascha Hauer (3):
> Bluetooth: hci_ldisc: Add function to wait for characters to be sent
> Bluetooth: hci
Hi Dan,
> This change is similar to commit a1616a5ac99e ("Bluetooth: hidp: fix
> buffer overflow") but for the compat ioctl. We take a string from the
> user and forgot to ensure that it's NUL terminated.
>
> I have also changed the strncpy() in to strscpy() in hidp_setup_hid().
> The difference
501 - 600 of 5746 matches
Mail list logo
