- 23 May, 2017 4 commits
-
-
Lin Zhang authored
Explicit set skb->sk is needless, sock_alloc_send_skb is already set it. Signed-off-by:
Lin Zhang <xiaolou4617@gmail.com> Acked-by:
Stefan Schmidt <stefan@osg.samsung.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Jürg Billeter authored
The iBT 3.5 controllers (Intel 8265, Windstorm Peak) need intel/ibt-12-16.sfi and intel/ibt-12-16.ddc firmware files from linux-firmware repository. Signed-off-by:
Jürg Billeter <j@bitron.ch> Signed-off-by:
-
Loic Poulain authored
The caller (hci_core) still owns the skb in case of error, releasing it inside the send function can lead to use-after-free errors. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Signed-off-by:
-
Guodong Xu authored
When __hci_cmd_sync() fails, download_firmware() should also fail, and the same error value should be returned as PTR_ERR(skb). Without this fix, download_firmware() will return a success when it actually failed in __hci_cmd_sync(). Fixes: 37180552 ("bluetooth: hci_uart: add LL protocol serdev driver support") Signed-off-by:
Guodong Xu <guodong.xu@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 22 May, 2017 3 commits
-
-
Markus Elfring authored
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by:
-
Markus Elfring authored
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.pdfSigned-off-by:
-
- 19 May, 2017 1 commit
-
-
Alexander Aring authored
I don't own this mail address anymore. This patch change the mail address to my current one. Signed-off-by:
Alexander Aring <alex.aring@gmail.com> Acked-by:
-
- 18 May, 2017 9 commits
-
-
Tobias Regnery authored
We see the following build failure with CONFIG_BT_HCIUART_NOKIA=y and CONFIG_BT_HCIUART_H4=n: drivers/bluetooth/hci_nokia.c: In function 'nokia_recv': drivers/bluetooth/hci_nokia.c:644:18: error: implicit declaration of function 'h4_recv_buf' [-Werror=implicit-function-declaration] ... Fix this by selecting the BT_HCIUART_H4 symbol like all the other users of the protocoll. Fixes: 7bb31868 ("Bluetooth: add nokia driver") Signed-off-by:
Tobias Regnery <tobias.regnery@gmail.com> Reviewed-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Dean Jenkins authored
When HCI_UART_PROTO_READY is in the set state, the Data Link protocol layer (proto) is bound to the HCI UART driver. This state allows the registered proto function pointers to be used by the HCI UART driver. When unbinding (closing) the Data Link protocol layer, the proto function pointers much be prevented from being used immediately before running the proto close function pointer. Otherwise, there is a risk that a proto non-close function pointer is used during or after the proto close function pointer is used. The consequences are likely to be a kernel crash because the proto close function pointer will free resources used in the Data Link protocol layer. Therefore, add a reader writer lock (rwlock) solution to prevent the close proto function pointer from running by using write_lock_irqsave() whilst the other proto function pointers are protected using read_lock(). This means HCI_UART_PROTO_READY can safely be cleared in the knowledge that no proto function pointers are running. When flag HCI_UART_PROTO_READY is put into the clear state, proto close function pointer can safely be run. Note flag HCI_UART_PROTO_SET being in the set state prevents the proto open function pointer from being run so there is no race condition between proto open and close function pointers. Signed-off-by:
Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by:
-
Marcel Holtmann authored
When the HCI User Channel access is requested, then do not try to undermine it with vendor diagnostic configuration. The exclusive user is required to configure its own vendor diagnostic in that case and can not rely on the host stack support. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Tobias Regnery authored
We see the following link error with CONFIG_BT_HCIUART=y, CONFIG_BT_HCIUART_LL=y and CONFIG_SERIAL_DEV_BUS=m: drivers/built-in.o: In function 'll_close': supp.c:(.text+0x55add4): undefined reference to 'serdev_device_close' supp.c:(.text+0x55add4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_close' drivers/built-in.o: In function 'll_open': supp.c:(.text+0x55aed0): undefined reference to 'serdev_device_open' supp.c:(.text+0x55aed0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_open' drivers/built-in.o: In function `hci_ti_probe': supp.c:(.text+0x55b00c): undefined reference to 'hci_uart_register_device' supp.c:(.text+0x55b00c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'hci_uart_register_device' drivers/built-in.o: In function `ll_setup': supp.c:(.text+0x55b08c): undefined reference to 'serdev_device_set_flow_control' supp.c:(.text+0x55b08c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_set_flow_control' supp.c:(.text+0x55b324): undefined reference to 'serdev_device_set_baudrate' supp.c:(.text+0x55b324): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_set_baudrate' drivers/built-in.o: In function 'll_init': supp.c:(.init.text+0x1b508): undefined reference to '__serdev_device_driver_register' supp.c:(.init.text+0x1b508): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol '__serdev_device_driver_register' Fix this by dependig BT_HCIUART_LL on the BT_HCIUART_SERDEV symbol. This implies a dependency on BT_HCIUART and hci_ll.c is only compiled in if SERIAl_DEV_BUS is built in or SERIAL_DEV_BUS and BT_HCIUART are modules. Fixes: 37180552 ("bluetooth: hci_uart: add LL protocol serdev driver support") Signed-off-by:
-
Marcel Holtmann authored
If the LE Set Default PHY command is supported, the indicate to the controller that the host has no preferences for transmitter PHY or receiver PHY selection. Issuing this command gives the controller a clear indication that other PHY can be selected if available. Signed-off-by:
-
Marcel Holtmann authored
If either LE Set Default PHY command or LE Set PHY commands is supported, then enable the LE PHY Update Complete event. Signed-off-by:
-
Marcel Holtmann authored
If the Channel Selection Algorithm #2 feature is supported, then enable the new LE Channel Selection Algorithm event. Signed-off-by:
-
Marcel Holtmann authored
When LE Data Packet Length Extension is supported, then actually increase the suggested default data length to the maximum to enable higher througput. < HCI Command: LE Read Maximum Data Length (0x08|0x002f) plen 0 > HCI Event: Command Complete (0x0e) plen 12 LE Read Maximum Data Length (0x08|0x002f) ncmd 1 Status: Success (0x00) Max TX octets: 251 Max TX time: 2120 Max RX octets: 251 Max RX time: 2120 < HCI Command: LE Read Suggested Default Data Length (0x08|0x0023) plen 0 > HCI Event: Command Complete (0x0e) plen 8 LE Read Suggested Default Data Length (0x08|0x0023) ncmd 1 Status: Success (0x00) TX octets: 27 TX time: 328 < HCI Command: LE Write Suggested Default Data Length (0x08|0x0024) plen 4 TX octets: 251 TX time: 2120 > HCI Event: Command Complete (0x0e) plen 4 LE Write Suggested Default Data Length (0x08|0x0024) ncmd 1 Status: Success (0x00) Signed-off-by: -
Tedd Ho-Jeong An authored
This patch adds support for Intel Bluetooth device 9460/9560 also known as Jefferson Peak (JfP). The firmware downloading mechanism is same as previous generation. So include the new USB product identifier and whitelist the hardware variant. T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0aaa Rev= 0.02 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 I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Bootloader version: < HCI Command: Intel Read Version (0x3f|0x0005) plen 0 > HCI Event: Command Complete (0x0e) plen 13 Intel Read Version (0x3f|0x0005) ncmd 32 Status: Success (0x00) Hardware platform: 0x37 Hardware variant: 0x11 Hardware revision: 0.0 Firmware variant: 0x06 Firmware revision: 0.1 Firmware build: 42-52.2015 Firmware patch: 0 Signed-off-by:Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
- 17 May, 2017 23 commits
-
-
David S. Miller authored
Andrew Lunn says: ==================== net: phy: marvell: Checkpatch cleanup I will be contributing a few new features to the Marvell PHY driver soon. Start by making the code mostly checkpatch clean. There should not be any functional changes. Just comments set into the correct format, missing blank lines, turn some comparisons around, and refactoring to reduce indentation depth. There is still one camel in the code, but it actually makes sense, so leave it in piece. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
Fold lines longer than 80 characters Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
Makes the code a bit more readable, and solves quite a few checkpatch warnings of lines longer than 80 characters. Signed-off-by:
-
Andrew Lunn authored
Break big functions up by using a number of smaller helper function. Solves some of the over 80 lines warnings, by reducing the indentation level. Signed-off-by:
-
Andrew Lunn authored
Avoid multiple assignments Comparisons should place the constant on the right side of the test Signed-off-by:
-
Andrew Lunn authored
Remove the extra blank lines, add one in where recommended. Signed-off-by:
-
Andrew Lunn authored
Use net style comment blocks, and wrap one block with long lines. Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== tcp: TCP TS option use 1 ms clock TCP Timestamps option is defined in RFC 7323 Traditionally on linux, it has been tied to the internal 'jiffy' variable, because it had been a cheap and good enough generator. Unfortunately some distros use HZ=250 or even HZ=100 leading to not very useful TCP timestamps. For TCP flows in the DC, Google has used usec resolution for more than two years with great success [1]. RCVBUF autotuning is more precise. This series converts tp->tcp_mstamp to a plain u64 value storing a 1 usec TCP clock. This choice will allow us to upstream the 1 usec TS option as discussed in IETF 97. Kathleen Nichols [2] and others advocate for 1ms TS clocks for network analysis. (1ms being the lowest value supported by RFC 7323.) [1] https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf [2] http://netseminar.stanford.edu/seminars/02_02_17.pdf ==================== Signed-off-by:
-
Eric Dumazet authored
TCP Timestamps option is defined in RFC 7323 Traditionally on linux, it has been tied to the internal 'jiffies' variable, because it had been a cheap and good enough generator. For TCP flows on the Internet, 1 ms resolution would be much better than 4ms or 10ms (HZ=250 or HZ=100 respectively) For TCP flows in the DC, Google has used usec resolution for more than two years with great success [1] Receive size autotuning (DRS) is indeed more precise and converges faster to optimal window size. This patch converts tp->tcp_mstamp to a plain u64 value storing a 1 usec TCP clock. This choice will allow us to upstream the 1 usec TS option as discussed in IETF 97. [1] https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdfSigned-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Eric Dumazet authored
After this patch, all uses of tcp_time_stamp will require a change when we introduce 1 ms and/or 1 us TCP TS option. Signed-off-by:
-
Eric Dumazet authored
tcp_time_stamp will become slightly more expensive soon, cache its value. Signed-off-by:
-
Eric Dumazet authored
This CC does not need 1 ms tcp_time_stamp and can use the jiffy based 'timestamp'. Signed-off-by:
-
Eric Dumazet authored
This place wants to use tcp_jiffies32, this is good enough. Signed-off-by:
-
Eric Dumazet authored
tcp_time_stamp will no longer be tied to jiffies. Signed-off-by:
-
Eric Dumazet authored
Use tcp_jiffies32 instead of tcp_time_stamp, since tcp_time_stamp will soon be only used for TCP TS option. Signed-off-by:
-
Eric Dumazet authored
Use tcp_jiffies32 instead of tcp_time_stamp, since tcp_time_stamp will soon be only used for TCP TS option. Signed-off-by:
-
Eric Dumazet authored
Use tcp_jiffies32 instead of tcp_time_stamp, since tcp_time_stamp will soon be only used for TCP TS option. Signed-off-by:
-
Eric Dumazet authored
Use tcp_jiffies32 instead of tcp_time_stamp, since tcp_time_stamp will soon be only used for TCP TS option. Signed-off-by:
-
Eric Dumazet authored
Use tcp_jiffies32 instead of tcp_time_stamp to feed tp->snd_cwnd_stamp. tcp_time_stamp will soon be a litle bit more expensive than simply reading 'jiffies'. Signed-off-by:
-
Eric Dumazet authored
Use tcp_jiffies32 instead of tcp_time_stamp to feed tp->lsndtime. tcp_time_stamp will soon be a litle bit more expensive than simply reading 'jiffies'. Signed-off-by:
-
Eric Dumazet authored
Use our own macro instead of abusing tcp_time_stamp Signed-off-by:
-
Eric Dumazet authored
We abuse tcp_time_stamp for two different cases : 1) base to generate TCP Timestamp options (RFC 7323) 2) A 32bit version of jiffies since some TCP fields are 32bit wide to save memory. Since we want in the future to have 1ms TCP TS clock, regardless of HZ value, we want to cleanup things. tcp_jiffies32 is the truncated jiffies value, which will be used only in places where we want a 'host' timestamp. Signed-off-by:
-
Eric Dumazet authored
Idea is to later convert tp->tcp_mstamp to a full u64 counter using usec resolution, so that we can later have fine grained TCP TS clock (RFC 7323), regardless of HZ value. We try to refresh tp->tcp_mstamp only when necessary. Signed-off-by:
-
