summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-07-06perf header: Assign proper ff->ph in perf_event__synthesize_features()Song Liu
bpf/btf write_* functions need ff->ph->env. With this missing, pipe-mode (perf record -o -) would crash like: Program terminated with signal SIGSEGV, Segmentation fault. This patch assign proper ph value to ff. Committer testing: (gdb) run record -o - Starting program: /root/bin/perf record -o - PERFILE2 <SNIP start of perf.data headers> Thread 1 "perf" received signal SIGSEGV, Segmentation fault. __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126 126 memcpy(ff->buf + ff->offset, buf, size); (gdb) bt #0 __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126 #1 do_write (ff=ff@entry=0x7fffffff8f80, buf=buf@entry=0x160, size=4) at util/header.c:137 #2 0x00000000004eddba in write_bpf_prog_info (ff=0x7fffffff8f80, evlist=<optimized out>) at util/header.c:912 #3 0x00000000004f69d7 in perf_event__synthesize_features (tool=tool@entry=0x97cc00 <record>, session=session@entry=0x7fffe9c6d010, evlist=0x7fffe9cae010, process=process@entry=0x4435d0 <process_synthesized_event>) at util/header.c:3695 #4 0x0000000000443c79 in record__synthesize (tail=tail@entry=false, rec=0x97cc00 <record>) at builtin-record.c:1214 #5 0x0000000000444ec9 in __cmd_record (rec=0x97cc00 <record>, argv=<optimized out>, argc=0) at builtin-record.c:1435 #6 cmd_record (argc=0, argv=<optimized out>) at builtin-record.c:2450 #7 0x00000000004ae3e9 in run_builtin (p=p@entry=0x98e058 <commands+216>, argc=argc@entry=3, argv=0x7fffffffd670) at perf.c:304 #8 0x000000000042eded in handle_internal_command (argv=<optimized out>, argc=<optimized out>) at perf.c:356 #9 run_argv (argcp=<optimized out>, argv=<optimized out>) at perf.c:400 #10 main (argc=3, argv=<optimized out>) at perf.c:522 (gdb) After the patch the SEGSEGV is gone. Reported-by: David Carrillo Cisneros <davidca@fb.com> Signed-off-by: Song Liu <songliubraving@fb.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: kernel-team@fb.com Cc: stable@vger.kernel.org # v5.1+ Fixes: 606f972b1361 ("perf bpf: Save bpf_prog_info information as headers to perf.data") Link: http://lkml.kernel.org/r/20190620010453.4118689-1-songliubraving@fb.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-07-06tools arch kvm: Sync kvm headers with the kernel sourcesArnaldo Carvalho de Melo
To pick up the changes from: 41040cf7c5f0 ("arm64/sve: Fix missing SVE/FPSIMD endianness conversions") 6ca00dfafda7 ("KVM: x86: Modify struct kvm_nested_state to have explicit fields for data") None entail changes in tooling. This silences these tools/perf build warnings: Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs from latest version at 'arch/x86/include/uapi/asm/kvm.h' diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h Warning: Kernel ABI header at 'tools/arch/arm64/include/uapi/asm/kvm.h' differs from latest version at 'arch/arm64/include/uapi/asm/kvm.h' diff -u tools/arch/arm64/include/uapi/asm/kvm.h arch/arm64/include/uapi/asm/kvm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Liran Alon <liran.alon@oracle.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Link: https://lkml.kernel.org/n/tip-1cdbq5ulr4d6cx3iv2ye5wdv@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-07-06Merge tag 'dmaengine-fix-5.2' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds
Pull dmaengine fixes from Vinod Koul: - bam_dma fix for completed descriptor count - fix for imx-sdma remove BD_INTR for channel0 and use-after-free on probe error path - endian bug fix in jz4780 IRQ handler * tag 'dmaengine-fix-5.2' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: qcom: bam_dma: Fix completed descriptors count dmaengine: imx-sdma: remove BD_INTR for channel0 dmaengine: imx-sdma: fix use-after-free on probe error path dmaengine: jz4780: Fix an endian bug in IRQ handler
2019-07-06Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two iscsi fixes. One for an oops in the client which can be triggered by the server authentication protocol and the other in the target code which causes data corruption" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: iscsi: set auth_protocol back to NULL if CHAP_A value is not supported scsi: target/iblock: Fix overrun in WRITE SAME emulation
2019-07-06Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds
Pull vfs fixlet from Al Viro: "Fix bogus default y in Kconfig (VALIDATE_FS_PARSER) That thing should not be turned on by default, especially since it's not quiet in case it finds no problems. Geert has sent the obvious fix quite a few times, but it fell through the cracks" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fs: VALIDATE_FS_PARSER should default to n
2019-07-06blk-mq: fix up placement of debugfs directory of queue filesGreg Kroah-Hartman
When the blk-mq debugfs file creation logic was "cleaned up" it was cleaned up too much, causing the queue file to not be created in the correct location. Turns out the check for the directory being present is needed as if that has not happened yet, the files should not be created, and the function will be called later on in the initialization code so that the files can be created in the correct location. Fixes: 6cfc0081b046 ("blk-mq: no need to check return value of debugfs_create functions") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: linux-block@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-07-06Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bugSzymon Janc
Microsoft Surface Precision Mouse provides bogus identity address when pairing. It connects with Static Random address but provides Public Address in SMP Identity Address Information PDU. Address has same value but type is different. Workaround this by dropping IRK if ID address discrepancy is detected. > HCI Event: LE Meta Event (0x3e) plen 19 LE Connection Complete (0x01) Status: Success (0x00) Handle: 75 Role: Master (0x00) Peer address type: Random (0x01) Peer address: E0:52:33:93:3B:21 (Static) Connection interval: 50.00 msec (0x0028) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Master clock accuracy: 0x00 .... > ACL Data RX: Handle 75 flags 0x02 dlen 12 SMP: Identity Address Information (0x09) len 7 Address type: Public (0x00) Address: E0:52:33:93:3B:21 Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl> Tested-by: Maarten Fonville <maarten.fonville@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461 Cc: stable@vger.kernel.org Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: L2CAP: Check bearer type on __l2cap_global_chan_by_addrLuiz Augusto von Dentz
The spec defines PSM and LE_PSM as different domains so a listen on the same PSM is valid if the address type points to a different bearer. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: Use controller sets when availableLuiz Augusto von Dentz
This makes use of controller sets when using Extended Advertising feature thus offloading the scheduling to the controller. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: validate BLE connection interval updatescsonsino
Problem: The Linux Bluetooth stack yields complete control over the BLE connection interval to the remote device. The Linux Bluetooth stack provides access to the BLE connection interval min and max values through /sys/kernel/debug/bluetooth/hci0/ conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval. These values are used for initial BLE connections, but the remote device has the ability to request a connection parameter update. In the event that the remote side requests to change the connection interval, the Linux kernel currently only validates that the desired value is within the acceptable range in the Bluetooth specification (6 - 3200, corresponding to 7.5ms - 4000ms). There is currently no validation that the desired value requested by the remote device is within the min/max limits specified in the conn_min_interval/conn_max_interval configurations. This essentially leads to Linux yielding complete control over the connection interval to the remote device. The proposed patch adds a verification step to the connection parameter update mechanism, ensuring that the desired value is within the min/max bounds of the current connection. If the desired value is outside of the current connection min/max values, then the connection parameter update request is rejected and the negative response is returned to the remote device. Recall that the initial connection is established using the local conn_min_interval/conn_max_interval values, so this allows the Linux administrator to retain control over the BLE connection interval. The one downside that I see is that the current default Linux values for conn_min_interval and conn_max_interval typically correspond to 30ms and 50ms respectively. If this change were accepted, then it is feasible that some devices would no longer be able to negotiate to their desired connection interval values. This might be remedied by setting the default Linux conn_min_interval and conn_max_interval values to the widest supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same behavior as the current implementation, where the remote device could request to change the connection interval value to any value that is permitted by the Bluetooth specification, and Linux would accept the desired value. Signed-off-by: Carey Sonsino <csonsino@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: Add support for LE ping featureSpoorthi Ravishankar Koppad
Changes made to add HCI Write Authenticated Payload timeout command for LE Ping feature. As per the Core Specification 5.0 Volume 2 Part E Section 7.3.94, the following code changes implements HCI Write Authenticated Payload timeout command for LE Ping feature. Signed-off-by: Spoorthi Ravishankar Koppad <spoorthix.k@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: Check state in l2cap_disconnect_rspMatias Karhumaa
Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame #402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 #394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 #403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 #407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by: Matti Kamunen <matti.kamunen@synopsys.com> Reported-by: Ari Timonen <ari.timonen@synopsys.com> Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Merge remote-tracking branch 'asoc/topic/meson' into asoc-nextMark Brown
2019-07-06Merge branch 'asoc-5.3' into asoc-nextMark Brown
2019-07-06Merge branch 'asoc-5.2' into asoc-linusMark Brown
2019-07-06ASoC: SOF: Intel: implement runtime idle for CNL/APLKai Vehmanen
Implement runtime idle for CNL/APL devices using similar runtime PM idle logic as the Intel AZX HDA driver. If any HDA codecs are powered when runtime suspend request comes, return -EBUSY. By doing this, strict ordering is enforced between HDA codec and the HDA controller. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20190702132428.13129-4-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-07-06ASoC: SOF: add runtime idle callbackKai Vehmanen
Add ability to implement a SOF device level runtime idle callback. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20190702132428.13129-3-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-07-06ASoC: hdac_hdmi: report codec link up/down status to busKai Vehmanen
Report codec power status to the HDA codec bus from runtime pm suspend and resume callbacks. This is required to implement runtime idle logic that relies on 'codec_powered' field of hdac_bus to be maintained for all codecs. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20190702132428.13129-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-07-06Bluetooth: hidp: NUL terminate a string in the compat ioctlDan Carpenter
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 is the strncpy() doesn't necessarily NUL terminate the destination string. Either change would fix the problem but it's nice to take a belt and suspenders approach and do both. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: Add new 13d3:3491 QCA_ROME deviceJoão Paulo Rechi Vita
Without the QCA ROME setup routine this adapter fails to establish a SCO connection. T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3491 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: Add new 13d3:3501 QCA_ROME deviceJoão Paulo Rechi Vita
Without the QCA ROME setup routine this adapter fails to establish a SCO connection. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3501 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_bcsp: Fix memory leak in rx_skbTomas Bortoli
Syzkaller found that it is possible to provoke a memory leak by never freeing rx_skb in struct bcsp_struct. Fix by freeing in bcsp_close() Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com> Reported-by: syzbot+98162c885993b72f19c4@syzkaller.appspotmail.com Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth:: btrtl: Add support for RTL8723DULarry Finger
This device is functionally equivalent to the BT part of the RTL8723DE, uses the same firmware, but the LMP subversion and HCI revision are unique. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: btmtkuart: add an implementation for clock osc propertySean Wang
Some board requires explicitily control external osscilator via GPIO. So, add an implementation of a clock property for an external oscillator to the device. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: btmtkuart: add an implementation for boot-gpios propertySean Wang
Not every platform has the pinctrl device integrates the GPIO the function such as MT7621 whose pinctrl and GPIO are separate hardware so the driver adds additional boot-gpios to let the MT766[3,8]U can enter the proper boot mode by gpiod for such platform. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06dt-bindings: net: bluetooth: add clock property to UART-based deviceSean Wang
Some board requires explicitily control external osscilator via GPIO. So, add a clock property for an external oscillator for the device. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06dt-bindings: net: bluetooth: add boot-gpios property to UART-based deviceSean Wang
Not every platform has the pinctrl device integrates the GPIO the function such as MT7621 whose pinctrl and GPIO are separate hardware so adding an additional boot-gpios property for such platform allows them to bring up the device. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: btbcm: Add entry for BCM4359C0 UART bluetoothNeil Armstrong
The BCM4359C0 BT/Wi-Fi compo chip needs an entry to be discovered by the btbcm driver. Tested using an AP6398S module from Ampak. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06dt-bindings: net: bluetooth: Add device property firmware-name for QCA6174Rocky Liao
This patch adds an optional device property "firmware-name" to allow the driver to load customized nvm firmware file based on this property. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_qca: Load customized NVM based on the device propertyRocky Liao
QCA BTSOC NVM is a customized firmware file and different vendors may want to have different BTSOC configuration (e.g. Configure SCO over PCM or I2S, Setting Tx power, etc.) via this file. This patch will allow vendors to download different NVM firmware file by reading a device property "firmware-name". Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Tested-by: Harish Bandi <c-hbandi@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_mrvl: Add serdev supportSascha Hauer
This adds serdev support to the Marvell hci uart driver. Only basic serdev support, none of the fancier features like regulator or enable GPIO support is added for now. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_mrvl: Wait for final ack before switching baudrateSascha Hauer
For the Marvell HCI UART we have to upload two firmware files. The first one is only for switching the baudrate of the device to a higher baudrate. After the baudrate switching firmware has been uploaded the device waits for a final ack (0x5a) before actually switching the baudrate. To send this final ack with the old baudrate give the hci ldisc workqueue a chance to run before switching the baudrate. Without this the final ack will never be received by the device and firmware upload fails. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_ldisc: Add function to wait for characters to be sentSascha Hauer
The hci UART line discipline sends its characters in a workqueue. Some devices like the Marvell Bluetooth chips need to make sure that all queued characters are sent before switching the baudrate. This adds a function to synchronize with the workqueue. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-066lowpan: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Because we don't care if debugfs works or not, this trickles back a bit so we can clean things up by making some functions return void instead of an error value that is never going to fail. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_qca: wcn3990: Drop baudrate change vendor eventMatthias Kaehlcke
Firmware download to the WCN3990 often fails with a 'TLV response size mismatch' error: [ 133.064659] Bluetooth: hci0: setting up wcn3990 [ 133.489150] Bluetooth: hci0: QCA controller version 0x02140201 [ 133.495245] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv [ 133.507214] Bluetooth: hci0: QCA TLV response size mismatch [ 133.513265] Bluetooth: hci0: QCA Failed to download patch (-84) This is caused by a vendor event that corresponds to an earlier command to change the baudrate. The event is not processed in the context of the baudrate change and is later interpreted as response to the firmware download command (which is also a vendor command), but the driver detects that the event doesn't have the expected amount of associated data. More details: For the WCN3990 the vendor command for a baudrate change isn't sent as synchronous HCI command, because the controller sends the corresponding vendor event with the new baudrate. The event is received and decoded after the baudrate change of the host port. Identify the 'unused' event when it is received and don't add it to the queue of RX frames. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: btqca: inject command complete event during fw downloadBalakrishna Godavarthi
Latest qualcomm chips are not sending an command complete event for every firmware packet sent to chip. They only respond with a vendor specific event for the last firmware packet. This optimization will decrease the BT ON time. Due to this we are seeing a timeout error message logs on the console during firmware download. Now we are injecting a command complete event once we receive an vendor specific event for the last RAM firmware packet. Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: Cleanup formatting and coding styleFabian Schindlatz
Fix some warnings and one error reported by checkpatch.pl: - lines longer than 80 characters are wrapped - empty lines inserted to separate variable declarations from the actual code - line break inserted after if (...) Co-developed-by: Thomas Röthenbacher <thomas.roethenbacher@fau.de> Signed-off-by: Thomas Röthenbacher <thomas.roethenbacher@fau.de> Signed-off-by: Fabian Schindlatz <fabian.schindlatz@fau.de> Cc: linux-kernel@i4.cs.fau.de Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: btrtl: HCI reset on close for Realtek BT chipJian-Hong Pan
Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly after on-off several times. Bluetooth daemon sets BT mode failed when this issue happens. Scanning must be active while turning off for this bug to be hit. bluetoothd[1576]: Failed to set mode: Failed (0x03) If BT is turned off, then turned on again, it works correctly again. According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set during probing. So, this patch makes Realtek's BT reset on close to fix this issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429 Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Reviewed-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_ll: Refactor download_firmwareFabian Schindlatz
Extract the new function send_command_from_firmware from download_firmware, which helps with the readability of the switch statement. This way the code is less deeply nested and also no longer exceeds the 80 character limit. Co-developed-by: Thomas Röthenbacher <thomas.roethenbacher@fau.de> Signed-off-by: Thomas Röthenbacher <thomas.roethenbacher@fau.de> Signed-off-by: Fabian Schindlatz <fabian.schindlatz@fau.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: hci_ll: set operational frequency earlierPhilipp Puschmann
Uploading the firmware needs quite a few seconds if done at 115200 kbps. So set the operational frequency, usually 3 MHz, before uploading the firmware. I have successfully tested this with a wl1837mod. Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06Bluetooth: btsdio: Do not bind to non-removable BCM4356Peter Robinson
BCM4356 devices soldered onto the PCB (non-removable) use an UART connection for bluetooth, such as the Rock960, but it also advertise btsdio support as a sdio function. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> CC: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-07-06irq/irqdomain: Fix comment typoZenghui Yu
Fix typo in the comment on top of __irq_domain_add(). Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/1562388072-23492-1-git-send-email-yuzenghui@huawei.com
2019-07-06genirq: Update irq stats from NMI handlersShijith Thotton
The NMI handlers handle_percpu_devid_fasteoi_nmi() and handle_fasteoi_nmi() do not update the interrupt counts. Due to that the NMI interrupt count does not show up correctly in /proc/interrupts. Add the statistics and treat the NMI handlers in the same way as per cpu interrupts and prevent them from updating irq_desc::tot_count as this might be corrupted due to concurrency. [ tglx: Massaged changelog ] Fixes: 2dcf1fbcad35 ("genirq: Provide NMI handlers") Signed-off-by: Shijith Thotton <sthotton@marvell.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/1562313336-11888-1-git-send-email-sthotton@marvell.com
2019-07-06ACPI: PM: Make acpi_sleep_state_supported() non-staticDexuan Cui
With some upcoming patches to save/restore the Hyper-V drivers related states, a Linux VM running on Hyper-V will be able to hibernate. When a Linux VM hibernates, unluckily we must disable the memory hot-add/remove and balloon up/down capabilities in the hv_balloon driver (drivers/hv/hv_balloon.c), because these can not really work according to the design of the related back-end driver on the host. By default, Hyper-V does not enable the virtual ACPI S4 state for a VM; on recent Hyper-V hosts, the administrator is able to enable the virtual ACPI S4 state for a VM, so we hope to use the presence of the virtual ACPI S4 state as a hint for hv_balloon to disable the aforementioned capabilities. In this way, hibernation will work more reliably, from the user's perspective. By marking acpi_sleep_state_supported() non-static, we'll be able to implement a hv_is_hibernation_supported() API in the always-built-in module arch/x86/hyperv/hv_init.c, and the API will be called by hv_balloon. Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-06netfilter: nf_tables: force module load in case select_ops() returns -EAGAINPablo Neira Ayuso
nft_meta needs to pull in the nft_meta_bridge module in case that this is a bridge family rule from the select_ops() path. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2019-07-05Revert "mm: page cache: store only head pages in i_pages"Linus Torvalds
This reverts commit 5fd4ca2d84b249f0858ce28cf637cf25b61a398f. Mikhail Gavrilov reports that it causes the VM_BUG_ON_PAGE() in __delete_from_swap_cache() to trigger: page:ffffd6d34dff0000 refcount:1 mapcount:1 mapping:ffff97812323a689 index:0xfecec363 anon flags: 0x17fffe00080034(uptodate|lru|active|swapbacked) raw: 0017fffe00080034 ffffd6d34c67c508 ffffd6d3504b8d48 ffff97812323a689 raw: 00000000fecec363 0000000000000000 0000000100000000 ffff978433ace000 page dumped because: VM_BUG_ON_PAGE(entry != page) page->mem_cgroup:ffff978433ace000 ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:170! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 221 Comm: kswapd0 Not tainted 5.2.0-0.rc2.git0.1.fc31.x86_64 #1 Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 2202 04/11/2019 RIP: 0010:__delete_from_swap_cache+0x20d/0x240 Code: 30 65 48 33 04 25 28 00 00 00 75 4a 48 83 c4 38 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c6 2f dc 0f 8a 48 89 c7 e8 93 1b fd ff <0f> 0b 48 c7 c6 a8 74 0f 8a e8 85 1b fd ff 0f 0b 48 c7 c6 a8 7d 0f RSP: 0018:ffffa982036e7980 EFLAGS: 00010046 RAX: 0000000000000021 RBX: 0000000000000040 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffff97843d657900 RBP: 0000000000000001 R08: ffffa982036e7835 R09: 0000000000000535 R10: ffff97845e21a46c R11: ffffa982036e7835 R12: ffff978426387120 R13: 0000000000000000 R14: ffffd6d34dff0040 R15: ffffd6d34dff0000 FS: 0000000000000000(0000) GS:ffff97843d640000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00002cba88ef5000 CR3: 000000078a97c000 CR4: 00000000003406e0 Call Trace: delete_from_swap_cache+0x46/0xa0 try_to_free_swap+0xbc/0x110 swap_writepage+0x13/0x70 pageout.isra.0+0x13c/0x350 shrink_page_list+0xc14/0xdf0 shrink_inactive_list+0x1e5/0x3c0 shrink_node_memcg+0x202/0x760 shrink_node+0xe0/0x470 balance_pgdat+0x2d1/0x510 kswapd+0x220/0x420 kthread+0xfb/0x130 ret_from_fork+0x22/0x40 and it's not immediately obvious why it happens. It's too late in the rc cycle to do anything but revert for now. Link: https://lore.kernel.org/lkml/CABXGCsN9mYmBD-4GaaeW_NrDu+FDXLzr_6x+XNxfmFV6QkYCDg@mail.gmail.com/ Reported-and-bisected-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Suggested-by: Jan Kara <jack@suse.cz> Cc: Michal Hocko <mhocko@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Matthew Wilcox <willy@infradead.org> Cc: Kirill Shutemov <kirill@shutemov.name> Cc: William Kucharski <william.kucharski@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-05Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "x86 bugfix patches and one compilation fix for ARM" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: arm64/sve: Fix vq_present() macro to yield a bool KVM: LAPIC: Fix pending interrupt in IRR blocked by software disable LAPIC KVM: nVMX: Change KVM_STATE_NESTED_EVMCS to signal vmcs12 is copied from eVMCS KVM: nVMX: Allow restore nested-state to enable eVMCS when vCPU in SMM KVM: x86: degrade WARN to pr_warn_ratelimited
2019-07-05Merge tag 'mtd/fixes-for-5.2-final' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull mtf fixes from Miquel Raynal: - Fix the memory organization structure of a Macronix SPI-NAND chip. - Fix a build dependency wrongly described. - Fix the sunxi NAND driver for A23/A33 SoCs by (a) reverting the faulty commit introducing broken DMA support and (b) applying another commit bringing working DMA support. * tag 'mtd/fixes-for-5.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: sunxi: Add A23/A33 DMA support with extra MBUS configuration Revert "mtd: rawnand: sunxi: Add A23/A33 DMA support" mtd: rawnand: ingenic: Fix ingenic_ecc dependency mtd: spinand: Fix max_bad_eraseblocks_per_lun info in memorg
2019-07-05Merge branch 'i2c/for-current' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixlet from Wolfram Sang: "I2C has a MAINTAINERS update which will be benfitial for developers, so let's add it right away" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: tegra: Add Dmitry as a reviewer
2019-07-05Merge tag 'nfsd-5.2-2' of git://linux-nfs.org/~bfields/linuxLinus Torvalds
Pull nfsd fixes from Bruce Fields: "Two more quick bugfixes for nfsd: fixing a regression causing mount failures on high-memory machines and fixing the DRC over RDMA" * tag 'nfsd-5.2-2' of git://linux-nfs.org/~bfields/linux: nfsd: Fix overflow causing non-working mounts on 1 TB machines svcrdma: Ignore source port when computing DRC hash
generated by cgit (git 2.34.1) at 2025-09-12 06:41:29 +0000