Re: [PATCH] rtnetlink: expose value from SET_NETDEV_DEVTYPE via IFLA_DEVTYPE attribute

me string as new IFLA_DEVTYPE attribute included in the RTM_NEWLINK >>>> messages. >>>> >>>> For network managing daemons that have to classify ARPHRD_ETHER network >>>> devices into different types (like Wireless LAN, Bluetooth etc.), this >>&g

Re: [PATCH] rtnetlink: expose value from SET_NETDEV_DEVTYPE via IFLA_DEVTYPE attribute

new IFLA_DEVTYPE attribute included in the RTM_NEWLINK >>> messages. >>> >>> For network managing daemons that have to classify ARPHRD_ETHER network >>> devices into different types (like Wireless LAN, Bluetooth etc.), this >>> avoids the extra round trip

Re: [PATCH] rtnetlink: expose value from SET_NETDEV_DEVTYPE via IFLA_DEVTYPE attribute

VTYPE attribute included in the RTM_NEWLINK >> messages. >> >> For network managing daemons that have to classify ARPHRD_ETHER network >> devices into different types (like Wireless LAN, Bluetooth etc.), this >> avoids the extra round trip to sysfs and parsing of

[PATCH] rtnetlink: expose value from SET_NETDEV_DEVTYPE via IFLA_DEVTYPE attribute

. For network managing daemons that have to classify ARPHRD_ETHER network devices into different types (like Wireless LAN, Bluetooth etc.), this avoids the extra round trip to sysfs and parsing of the uevent file. Signed-off-by: Marcel Holtmann --- include/uapi/linux/if_link.h | 2 ++ net/core

Re: [PATCH COMMITTED] bluetooth: hci_nokia: Don't include linux/unaligned/le_struct.h directly.

ad. > > Signed-off-by: David S. Miller > --- > drivers/bluetooth/hci_nokia.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marcel Holtmann Regards Marcel

Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)

Hi Ricardo, the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export? >>>

Re: [PATCH] Bluetooth: hci_bcm: Configure SCO routing automatically

Hi Rob, Added support to automatically configure the SCO packet routing at the device setup. The SCO packets are used with the HSP / HFP profiles, but in some devices (ex. CYW43438) they are routed to a PCM output by default. This change allows sending the vendor

Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)

Hi Marcel, >> the commit message is misleading me. If I build something with ACPI or DT >> support, then modinfo will show all modalias information for ACPI and DT >> compatible strings. What else does udev/modprobe actually need? Is something >> broken with the modalias export? > > The main

Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)

Hi Ricardo, > Export serdev table to the module header, allowing module autoload via > udev/modprobe. > > Cc: Lino Sanfilippo > Cc: David S. Miller > Cc: Stefan Wahren > Cc: Rob Herring > Cc: Johan Hovold > Cc: netdev@vger.kernel.org > Signed-off-by: Ricardo Ribalda Delgado > --- >

Re: [RFC] net: Add new LoRaWAN subsystem

Hi Jian-Hong, > A Low-Power Wide-Area Network (LPWAN) is a type of wireless > telecommunication wide area network designed to allow long range > communications at a low bit rate among things (connected objects), such > as sensors operated on a battery. It can be used widely in IoT area. >

Re: [PATCH] Bluetooth: use wait_event API instead of open-coding it

Hi John, > I've seen timeout errors from HCI commands where it looks like > schedule_timeout() has returned immediately; additional logging for the > error case gives: > > req_status=1 req_result=0 remaining=1 jiffies > > so the device is still in state HCI_REQ_PEND and the value

Re: Bluetooth/lock_sock: false positive "WARNING: possible recursive locking detected"

Hi Jiri, >> [ 2891.586061] >> [ 2891.586063] WARNING: possible recursive locking detected >> [ 2891.586065] 4.16.2-10.ge881e16-default #1 Not tainted >> [ 2891.586067] >> [ 2891.586068] kworker/u9:3/873 is

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

Hi Gustavo, >> so I took this patch back out of bluetooth-next before sending the pull >> request. I think the discussion on how to fix SHASH_DESC_ON_STACK macro >> needs to complete first. Once that has concluded we can revisit if this >> patch is still needed or if another solution has been

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

Hi Gustavo, > In preparation to enabling -Wvla, remove VLA and replace it > with dynamic memory allocation instead. > > The use of stack Variable Length Arrays needs to be avoided, as they > can be a vector for stack exhaustion, which can be both a runtime bug > or a security flaw. Also, in

Re: [PATCH] Bluetooth: Mark expected switch fall-throughs

Hi Gustavo, > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > net/bluetooth/mgmt.c| 1 + > net/bluetooth/rfcomm/sock.c | 1 + > 2 files changed, 2

Re: [PATCH v2] Bluetooth: Remove VLA usage in aes_cmac

Hi Gustavo, > In preparation to enabling -Wvla, remove VLA and replace it > with dynamic memory allocation instead. > > The use of stack Variable Length Arrays needs to be avoided, as they > can be a vector for stack exhaustion, which can be both a runtime bug > or a security flaw. Also, in

Re: pull request: bluetooth 2018-03-16

Hi Dave, >> any issue with this pull request? I ask since it seems to have >> disappeared from patchwork. > > Should be pulled in now, don't know how that happened ;-) awesome. Thanks. Any chance you can pull net into net-next once you send it off to Linus? We have a few further Broadcom

Re: pull request: bluetooth 2018-03-16

Hi Dave, > Here are a few more important Bluetooth driver fixes for the 4.16 > kernel. > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 3d502067599f0db12e74e6646aee8728efe3e5be: > > net/smc: simplify wait when closing

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

; drivers/bluetooth/Kconfig| 4 +--- > drivers/net/wireless/rsi/Kconfig | 4 +++- > 2 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann <mar...@holtmann.org> Since I think Kalle still has to take it through his tree until the btrsi driver makes it into net-next. Regards Marcel

Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd, >>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile >>> index 03cfc1b20c4a..9e8d22712ff3 100644 >>> --- a/drivers/bluetooth/Makefile >>> +++ b/drivers/bluetooth/Makefile >>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o >>> >>>

Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd, > The linkage between the bluetooth driver and the wireless > driver is not defined properly, leading to build problems > such as: > > warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies > (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) >

Re: [PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan

Hi Guo, > This patch fix the bluetooth 6lowpan disconnect fail bug. > > The type of the same address type have different define value in HCI layer > and L2CAP layer.That makes disconnect fail due to wrong network type.User > will not be able to disconnect from console with the network type that

Re: [PATCH v1] Bluetooth: introduce DEFINE_SHOW_ATTRIBUTE() macro

Hi Andy, > This macro deduplicates a lot of similar code across the hci_debugfs.c > module. Targeting to be moved to seq_file.h eventually. > > Signed-off-by: Andy Shevchenko > --- > net/bluetooth/hci_debugfs.c | 184

Re: [PATCH 0/2] Bluetooth: Add device tree compatible for TI CC2560

Hi David, > This series updates the bindings TI WiLink 7/8 Bluetooth to add TI CC256x > chips as well. A compatible string is also added to the hci_ll driver for > TI CC2560. > > David Lechner (2): > dt-bindings: net: add TI CC2560 Bluetooth chip > Bluetooth: hci_ll: add "ti,cc2560" compatible

Re: [PATCH v3 0/3] Bluetooth: hci_ll: Get BD address from NVMEM

Hi David, > This series adds supporting getting the BD address from a NVMEM provider > for "LL" HCI controllers (Texas Instruments). > > v3 changes: > * Additional comments on why swapping bytes is needed. > * Fixed comment style and trailing whitespace. > * Rework error handling for nvmem cell

Re: [PATCH v1] Bluetooth: Utilize %*ph specifier

Hi Andy, > Instead of open coding byte-by-byte printing, re-use %*ph specifier. > > Signed-off-by: Andy Shevchenko > --- > net/bluetooth/hci_debugfs.c | 17 +++-- > 1 file changed, 3 insertions(+), 14 deletions(-) patch has been applied to

Re: [PATCH v2 1/3] Bluetooth: hci_ll: add support for setting public address

Hi David, >>> This adds support for setting the public address on Texas Instruments >>> Bluetooth chips using a vendor-specific command. >>> >>> This has been tested on a CC2560A. The TI wiki also indicates that this >>> command should work on TI WL17xx/WL18xx Bluetooth chips. >>> >>>

Re: [PATCH v2 3/3] Bluetooth: hci_ll: Add optional nvmem BD address source

Hi David, > This adds an optional nvmem consumer to get a BD address from an external > source. The BD address is then set in the Bluetooth chip after the > firmware has been loaded. > > This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS > EV3). > > Signed-off-by: David

Re: [PATCH v2 1/3] Bluetooth: hci_ll: add support for setting public address

Hi David, > This adds support for setting the public address on Texas Instruments > Bluetooth chips using a vendor-specific command. > > This has been tested on a CC2560A. The TI wiki also indicates that this > command should work on TI WL17xx/WL18xx Bluetooth chips. > > Signed-off-by: David

Re: [PATCH v2 2/3] dt-bindings: Add optional nvmem BD address bindings to ti,wlink-st

Hi David, > This adds optional nvmem consumer properties to the ti,wlink-st device tree > bindings to allow specifying the BD address. > > Signed-off-by: David Lechner > --- > > v2 changes: > * Renamed "mac-address" to "bd-address" > * Fixed typos in example > * Specify

Re: [PATCH 2/3] bluetooth: hci_ll: add constant for vendor-specific command

Hi David, >>> This adds a #define for the vendor-specific HCI command to set the >>> baudrate instead of using the bare 0xff36 multiple times. >>> >>> Signed-off-by: David Lechner >>> --- >>> drivers/bluetooth/hci_ll.c | 10 -- >>> 1 file changed, 8 insertions(+), 2

Re: [PATCH 1/3] dt-bindings: Add optional nvmem MAC address bindings to ti,wlink-st

Hi David, > This adds optional nvmem consumer properties to the ti,wlink-st device tree > bindings to allow specifying the Bluetooth MAC address. > > Signed-off-by: David Lechner > --- > Documentation/devicetree/bindings/net/ti,wilink-st.txt | 4 > 1 file changed, 4

Re: [PATCH 3/3] bluetooth: hci_ll: Add optional nvmem MAC address source

Hi David, > This adds an optional nvmem consumer to get a MAC address from an external > source. The MAC address is then set in the Bluetooth chip after the > firmware has been loaded. > > This has been tested working with a TI CC2560A chip (in a LEGO MINDSTORMS > EV3). > > Signed-off-by: David

Re: [PATCH 2/3] bluetooth: hci_ll: add constant for vendor-specific command

Hi David, > This adds a #define for the vendor-specific HCI command to set the > baudrate instead of using the bare 0xff36 multiple times. > > Signed-off-by: David Lechner > --- > drivers/bluetooth/hci_ll.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-)

Re: [PATCH v2 1/2] seq_file: Introduce DEFINE_SHOW_ATTRIBUTE() helper macro

Hi Andy, > The DEFINE_SHOW_ATTRIBUTE() helper macro would be useful for current > users, which are many of them, and for new comers to decrease code > duplication. > > Signed-off-by: Andy Shevchenko > --- > include/linux/seq_file.h | 13 + > 1 file

Re: [PATCH] Bluetooth: Use common error handling code in bt_init()

Hi Markus, > * Improve jump targets so that a bit of exception handling can be better > reused at the end of this function. > > * Adjust five condition checks. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > ---

Re: [PATCH] ieee802154: fix gcc-4.9 warnings

Hi Arnd, > All older compiler versions up to gcc-4.9 produce these > harmless warnings: > > drivers/net/ieee802154/ca8210.c: In function 'ca8210_skb_tx': > drivers/net/ieee802154/ca8210.c:1947:9: warning: missing braces around > initializer [-Wmissing-braces] > > This changes the syntax to

Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup

Hi Bjorn, >>> Bluetooth BD address can be retrieved in the same way as >>> for wcnss-wlan MAC address. This patch mainly stores the >>> local-mac-address property and sets the BD address during >>> hci device setup. >>> >>> Signed-off-by: Loic Poulain >>> Signed-off-by:

Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup

Hi Rob, >>> Bluetooth BD address can be retrieved in the same way as >>> for wcnss-wlan MAC address. This patch mainly stores the >>> local-mac-address property and sets the BD address during >>> hci device setup. >>> >>> Signed-off-by: Loic Poulain >>> Signed-off-by:

Re: [PATCH 1/2] Bluetooth: make baswap src const

Hi Bjorn, > Signed-off-by: Loic Poulain > Signed-off-by: Bjorn Andersson > --- > include/net/bluetooth/bluetooth.h | 2 +- > net/bluetooth/lib.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) patch has been applied

Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup

Hi Bjorn, > Bluetooth BD address can be retrieved in the same way as > for wcnss-wlan MAC address. This patch mainly stores the > local-mac-address property and sets the BD address during > hci device setup. > > Signed-off-by: Loic Poulain > Signed-off-by: Bjorn

Re: [PATCH 3/7] ieee802154: 6lowpan: make header_ops const

Hi Bhumika, > Make this const as it is only stored as a reference in a const field of > a net_device structure. > > Signed-off-by: Bhumika Goyal > --- > net/ieee802154/6lowpan/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to

Re: Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]

Hi Jiri, >>> It looks like bnep_session has same pattern as the issue reported in >>> old rfcomm: >>> >>> while (1) { >>> set_current_state(TASK_INTERRUPTIBLE); >>> if (condition) >>> break; >>> // may call might_sleep here >>>

Re: [PATCH] ieee802154: ca8210: Fix a potential NULL pointer dereference

Hi Christophe, > 'spi' is known to be NULL, so we dereference a NULL pointer here. > Use 'pr_crit()' instead of 'dev_crit()' to report the message. > > Signed-off-by: Christophe JAILLET > --- > drivers/net/ieee802154/ca8210.c | 5 + > 1 file changed, 1

Re: [PATCH] Bluetooth: make device_type const

Hi Bhumika, > Make these const as they are only stored in the type field of a device > structure, which is const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal > --- > net/bluetooth/hci_sysfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) patch has

Re: [PATCH net-next 2/3 v4] net: arp: Add support for raw IP device

Hi Subash, > Define the raw IP type. This is needed for raw IP net devices > like rmnet. > > Signed-off-by: Subash Abhinov Kasiviswanathan > --- > include/uapi/linux/if_arp.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/linux/if_arp.h

Re: [PATCH][next] Bluetooth: kfree tmp rather than an alias to it

Hi Colin, > While the kfree of dhkey_a is of the same address of tmp, it > probably is clearer and more human readable if tmp is kfree'd > rather than dhkey_a. > > Detected by CoverityScan, CID#1448650 ("Free of address-of expression") > Signed-off-by: Colin Ian King >

Re: [PATCHv2] bluetooth: document config options

Hi Pavel, > On Aug 8, 2017, at 15:48, Pavel Machek wrote: > > Kernel config options should include useful help text; I had to look > up the terms on wikipedia. > > Signed-off-by: Pavel Machek > > --- > >> are you planning to send a patch with updated wording for

Re: [PATCH 0/6] In-kernel QMI handling

Hi Bjorn, >> This series starts by moving the common definitions of the QMUX protocol to >> the >> uapi header, as they are shared with clients - both in kernel and userspace. >> >> This series then introduces in-kernel helper functions for aiding the >> handling >> of QMI encoded messages in

Re: [PATCH 0/6] In-kernel QMI handling

Hi Bjorn, > This series starts by moving the common definitions of the QMUX > protocol to the > uapi header, as they are shared with clients - both in kernel and > userspace. > > This series then introduces in-kernel helper functions for aiding the > handling > of

Re: [PATCH 0/6] In-kernel QMI handling

Hi Bjorn, >>> This series starts by moving the common definitions of the QMUX >>> protocol to the >>> uapi header, as they are shared with clients - both in kernel and >>> userspace. >>> >>> This series then introduces in-kernel helper functions for aiding the >>> handling >>> of QMI encoded

Re: [PATCH] bluetooth: document config options

Hi Pavel, >>> Kernel config options should include useful help text; I had to look >>> up the terms on wikipedia. >>> >>> Signed-off-by: Pavel Machek >>> >>> diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig >>> index 68f951b..133c8a6 100644 >>> ---

Re: [PATCH net-next 1/3] bluetooth: 6lowpan dev_close never returns error

014-06-18 626 } > 7f118253 Jukka Rissanen2014-06-18 627 > > :: The code at line 621 was first introduced by commit > :: 7f118253820fc3ad38659485adb3ebdfe64820e1 Bluetooth: 6LoWPAN: Remove > network devices when unloading > > :: TO: Jukka Rissane

Re: [PATCH] bluetooth: document config options

Hi Pavel, >>> Kernel config options should include useful help text; I had to look >>> up the terms on wikipedia. >>> >>> Signed-off-by: Pavel Machek >>> >>> diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig >>> index 68f951b..133c8a6 100644 >>> ---

Re: [PATCH] bluetooth: document config options

Hi Pavel, > Kernel config options should include useful help text; I had to look > up the terms on wikipedia. > > Signed-off-by: Pavel Machek > > diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig > index 68f951b..133c8a6 100644 > --- a/net/bluetooth/Kconfig > +++

Re: Lots of new warnings with gcc-7.1.1

Hi Linus, > At the same time, others aren't quite as insane, and in many cases the > warnings might be easy to just fix. > > And some actually look valid, although they might still require odd input: > > net/bluetooth/smp.c: In function ‘le_max_key_size_read’: > net/bluetooth/smp.c:3372:29:

Re: [PATCH v2] mrf24j40: Fix en error handling path in 'mrf24j40_probe()'

Hi Christophe, > If this check fails, we must release some resources as done everywhere > else in this function before returning an error code. > > Signed-off-by: Christophe JAILLET > --- > V2: initialization of ret in this erro path ws missing. Stupid me! > --- >

Re: Request to add bluetooth module identifier to net/rfkill/rfkill-gpio.c

Hi Sundar, > I have a Cherry Trail laptop with an Atom X5-Z8300. It has a bluetooth > chip that needs the r8723bs (coexisting RTL 8723BS wifi and > bluetooth). > > I am using linux-next (20150817) with the r8723bs staging driver and > the firmware and utility from

Re: [PATCH] Bluetooth: Add sockaddr length checks before accessing sa_family in bind and connect handlers

Hi Mateusz, > Verify that the caller-provided sockaddr structure is large enough to > contain the sa_family field, before accessing it in bind() and connect() > handlers of the Bluetooth sockets. Since neither syscall enforces a minimum > size of the corresponding memory region, very short

Re: [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session

Hi Jeffy, > It looks like bnep_session has same pattern as the issue reported in > old rfcomm: > > while (1) { > set_current_state(TASK_INTERRUPTIBLE); > if (condition) > break; > // may call might_sleep here >

Re: [net-bluetooth] question about potential null pointer dereference

Hi Gustavo, While looking into Coverity ID 1357456 I ran into the following piece of code at net/bluetooth/smp.c:166 166/* The following functions map to the LE SC SMP crypto functions 167 * AES-CMAC, f4, f5, f6, g2 and h6. 168 */ 169 170static int

Re: [net-bluetooth] question about potential null pointer dereference

Hi Gustavo, > While looking into Coverity ID 1357456 I ran into the following piece of code > at net/bluetooth/smp.c:166 > > 166/* The following functions map to the LE SC SMP crypto functions > 167 * AES-CMAC, f4, f5, f6, g2 and h6. > 168 */ > 169 > 170static int aes_cmac(struct crypto_shash

Re: [PATCH] net: ieee802154: fix potential null pointer dereference

Hi Gustavo, > Null check at line 918: if (!spi) {, implies spi might be NULL. > Function spi_get_drvdata() dereference pointer spi. > Move pointer priv assignment after the null check. > > Addresses-Coverity-ID: 140 > Signed-off-by: Gustavo A. R. Silva > --- >

Re: [PATCH net v2 1/2] net: ieee802154: remove explicit set skb->sk

Hi Lin, > Explicit set skb->sk is needless, sock_alloc_send_skb is already set it. > > Signed-off-by: Lin Zhang > Acked-by: Stefan Schmidt > --- > changelog: > > v1 -> v2: >* split v1 into two patches, per Stefan Schmidt. > > Thanks to

Re: [PATCH net v2 2/2] net: ieee802154: fix net_device reference release too early

Hi Lin, > This patch fixes the kernel oops when release net_device reference in > advance. In function raw_sendmsg(i think the dgram_sendmsg has the same > problem), there is a race condition between dev_put and dev_queue_xmit > when the device is gong that maybe lead to dev_queue_ximt to see >

Re: [PATCH 0/2] ieee802154: ca8210: Adjustments for two function implementations

Hi Markus, > Two update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Delete an error message for a failed memory allocation in ca8210_probe() > Delete an error message for a failed memory allocation in ca8210_skb_rx() > >

Re: [PATCH] Bluetooth: Delete error messages for failed memory allocations in two functions

Hallo Markus, > Omit two extra messages for memory allocation failures in these functions. > > This issue was detected by using the Coccinelle software. > > Link: > http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf > Signed-off-by: Markus Elfring

Re: [PATCH] ieee802154: don't select COMMON_CLK

Hi Arnd, > A device driver must not select the COMMON_CLK subsystem, as that conflicts > with platforms that provide a legacy implementation of the clk API: > > drivers/clk/clk.o: In function `clk_enable': > clk.c:(.text.clk_enable+0x0): multiple definition of `clk_enable' >

Re: [PATCH v3 0/4] TI Bluetooth serdev support

Hi Rob, > This series adds serdev support to the HCI LL protocol used on TI BT > modules and enables support on HiKey board with with the WL1835 module. > With this the custom TI UIM daemon and btattach are no longer needed. > > The series is available on this git branch[1]. This version is

Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support

> Signed-off-by: Rob Herring <r...@kernel.org> > Cc: Marcel Holtmann <mar...@holtmann.org> > Cc: Gustavo Padovan <gust...@padovan.org> > Cc: Johan Hedberg <johan.hedb...@gmail.com> > Cc: linux-blueto...@vger.kernel.org > --- > v2:

Re: [RFC 1/3] bpf/wireless: add wifimon program type

Hi Johannes, > Add a new program type for wifi monitor interfaces. This program > type can > * access __sk_buff, but only skb->len > * call bpf_skb_load_bytes() > > The program type is only enabled when something selects the new > Kconfig symbol WANT_BPF_WIFIMON, which will be done by mac80211 >

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi Larry, > The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets > for bluetooth rfkill functionality. > > Tested-by: russianneuroman...@ya.ru > Signed-off-by: Hans de Goede > --- >

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi Hans, >>> The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets >>> for bluetooth rfkill functionality. >>> >>> Tested-by: russianneuroman...@ya.ru >>> Signed-off-by: Hans de Goede >>> --- >>> net/rfkill/rfkill-gpio.c | 1 + >>> 1

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi Hans, > The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets > for bluetooth rfkill functionality. > > Tested-by: russianneuroman...@ya.ru > Signed-off-by: Hans de Goede > --- > net/rfkill/rfkill-gpio.c | 1 + > 1 file changed, 1

Re: [PATCH] bluetooth: 6lowpan: fix delay work init in add_peer_chan()

Hi Michael, > When adding 6lowpan devices very rapidly we sometimes see a crash: > [23122.306615] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0-43-arm64 #1 > Debian 4.9.9.linaro.43-1 > [23122.315400] Hardware name: HiKey Development Board (DT) > [23122.320623] task: 800075443080

Re: [PATCH] bluetooth: 6lowpan: fix use after free in chan_suspend/resume

Hi Michael, > A status field in the skb_cb struct was storing a channel status > based on channel suspend/resume events. This stored status was > then used to return EAGAIN if there were packet sending issues > in snd_pkt(). > > The issue is that the skb has been freed by the time the callback

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

Hi Colin, > Ensure we don't end up with a null pointer dereferences by checking > for for allocation failures. Allocate by sizeof(*ptr) rather than > the type to fix checkpack warnings. Also merge multiple lines into > one line for the kmalloc call. > > Detected by CoverityScan, CID#1422435

Re: [PATCH][bluetooth-next][V2] ieee802154: ca8210: Add checks for kmalloc allocation failures

Hi Dave, >> drivers/net/ieee802154/ca8210.c | 18 ++ > > This file doesn't exist in any of my trees. > because we have not send you a bluetooth-next pull request yet. I review it and take it through my tree first. Regards Marcel

Re: [PATCH] 6lowpan: fix assignment of peer_addr

Hi Colin, > The data from peer->chan->dst is not being copied to peer_addr, the > current code just updates the pointer and not the contents of what > it points to. Fix this with the intended assignment. > > Detected by CoverityScan, CID#1422111 ("Parse warning > (PW.PARAM_SET_BUT_NOT_USED)") >

Re: [PATCH] 6lowpan: set peer_addr correctly again

Hi Arnd, > A bugfix accidentally changed one line to return the peer_addr > from setup_header, causing it to become unused: > > net/bluetooth/6lowpan.c: In function 'setup_header': > net/bluetooth/6lowpan.c:402:14: error: parameter 'peer_addr' set but not used >

Re: [PATCH] Bluetooth: fix assignments on error variable err

Hi Colin, > Variable err is being initialized to zero and then later being > set to the error return from the call to hci_req_run_skb; hence > we can remove the redundant initialization to zero. > > Also on two occassions err is not being set from the error return > from the call to

Re: [PATCH v7 0/6] Bluetooth: 6LoWPAN: Fix lladdr length

Hi Luiz, > These patches fixes lladdr length to be 6 bytes long and not 8 which cause > neighbor advertisement to be sent with wrong lladdr including FF:FE filler > bytes for eui64. > > Note: This does not fix some of the existing crashes which I hope to address > in a different set. > > v2:

Re: [PATCH 05/18] net, bluetooth: convert rfcomm_dlc.refcnt from atomic_t to refcount_t

Hi Elena, > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

Hi Dave, >> By moving these client drivers to use RPMSG instead of the direct SMD >> API we can reuse them ontop of the newly added GLINK wire-protocol >> support found in the 820 and 835 Qualcomm platforms. >> >> As the new (RPMSG-based) and old SMD implementations are mutually >> exclusive we

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

files changed, 108 insertions(+), 104 deletions(-) I think that it is best if Dave takes these directly then and I pull them back down later into our trees. Including the Kconfig fix that I will ACK as well. Acked-by: Marcel Holtmann <mar...@holtmann.org> Regards Marcel

Removing GENL_ID_GENERATE breaks userspace API

Hi Johannes, you have removed GENL_ID_GENERATE in 4.10, but that is actually breaking userspace API. commit a07ea4d9941af5a0c6f0be2a71b51ac9c083c5e5 Author: Johannes Berg Date: Mon Oct 24 14:40:02 2016 +0200 genetlink: no longer support using static family IDs

Re: [PATCH] Bluetooth: fix spelling mistake: "advetising" -> "advertising"

Hi Colin, > trivial fix to spelling mistake in BT_ERR_RATELIMITED error message > > Signed-off-by: Colin Ian King > --- > net/bluetooth/hci_event.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel

Re: [PATCH v7 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

Hi, > The Marvell devices may have many gpio pins, and hence for wakeup > on these out-of-band pins, the chip needs to be told which pin is > to be used for wakeup, using an hci command. > > Thus, we read the pin number etc from the device tree node and send > a command to the chip. > >

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

e| 2 -- > net/wireless/Makefile | 2 -- > 38 files changed, 5 insertions(+), 68 deletions(-) for drivers/bluetooth, net/bluetooth, net/ieee802154 and net/mac802154 Acked-by: Marcel Holtmann <mar...@holtmann.org> Regards Marcel

Re: [PATCH 1/2] wcn36xx: Correct Kconfig dependency

Hi Bjorn, > In the case SMD or WCNSS_CTRL are compiled as modules, wcn36xx must be > compiled as module as well, so we need to mention this dependency. > But we still want allow the driver to be compiled in case either of > those are =n, for compile testing reasons. > > Signed-off-by: Bjorn

Useless debug warning "netlink: 16 bytes leftover after parsing attributes"

Hi, so lately I am seeing a bunch of these warnings: netlink: 16 bytes leftover after parsing attributes.. While they give you the process name, they are still useless to track down the message that causes them. I find them even more useless since an updated userspace on an older kernel can

Re: [PATCHv2] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

Hi Pavel, > bluetooth.h is not part of user API, so __ variants are not neccessary > here. > > Signed-off-by: Pavel Machek > > --- > v2: not touching stuff that Marcel does not want touched, as it will > become API later. patch has been applied to bluetooth-next tree. Regards

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

Hi Pavel, > bluetooth.h is not part of user API, so __ variants are not neccessary > here. > > Signed-off-by: Pavel Machek > > diff --git a/include/net/bluetooth/bluetooth.h > b/include/net/bluetooth/bluetooth.h > index bfd1590..aea0371 100644 > ---

Re: net-next tree broken with CONFIG_NETFILTER_INGRESS=n

Hi Dave, > the net-next tree is broken since a few days now when > CONFIG_NETFILTER_INGRESS=n is set. > > CC net/netfilter/core.o > In file included from ./include/linux/linkage.h:4:0, > from ./include/linux/kernel.h:6, > from net/netfilter/core.c:10: >

net-next tree broken with CONFIG_NETFILTER_INGRESS=n

Hi Dave, the net-next tree is broken since a few days now when CONFIG_NETFILTER_INGRESS=n is set. CC net/netfilter/core.o In file included from ./include/linux/linkage.h:4:0, from ./include/linux/kernel.h:6, from net/netfilter/core.c:10:

Re: [PATCH net-next 8/8] net: qualcomm: add QCA7000 UART driver

Hi Stefan, > This patch adds the Ethernet over UART driver for the > Qualcomm QCA7000 HomePlug GreenPHY. > > Signed-off-by: Stefan Wahren > --- > drivers/net/ethernet/qualcomm/Kconfig | 12 + > drivers/net/ethernet/qualcomm/Makefile | 2 + >

Re: [PATCH v4 1/4] soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API

Hi Bjorn, > Stub the wcnss_ctrl API to allow compile testing wcnss function drivers. > > Cc: Marcel Holtmann <mar...@holtmann.org> > Signed-off-by: Bjorn Andersson <bjorn.anders...@linaro.org> > --- > > There are no other pending changes collid

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

Hi Kalle, >> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD >> channel, as such it should be a SMD client. This patch makes this >> transition, now that we have the necessary frameworks available. >> >> Signed-off-by: Bjorn Andersson > > [...] >

Re: [PATCH v2] Bluetooth: Add LED triggers for HCI frames tx and rx

Hi Guodong, > Two LED triggers are added into hci_dev: tx_led and rx_led. Upon ACL/SCO > packets available in tx or rx, the LEDs will blink. > > For each hci registration, two triggers are added into LED subsystem: > [hdev->name]-tx and [hdev-name]-rx. > Refer to

Re: [PATCH v2] Bluetooth: Add LED triggers for HCI frames tx and rx

Hi Guodong, >>> Two LED triggers are added into hci_dev: tx_led and rx_led. Upon ACL/SCO >>> packets available in tx or rx, the LEDs will blink. >>> >>> For each hci registration, two triggers are added into LED subsystem: >>> [hdev->name]-tx and [hdev-name]-rx. >>> Refer to

  1   2   3   >