- 10 Dec, 2019 40 commits
-
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 64b9d16e ] Clang warns: drivers/atm/zatm.c:513:7: error: while loop has empty body [-Werror,-Wempty-body] zwait; ^ drivers/atm/zatm.c:513:7: note: put the semicolon on a separate line to silence this warning Get rid of this warning by using an empty do-while loop. While we're at it, add parentheses to make it clear that this is a function-like macro. Link: https://github.com/ClangBuiltLinux/linux/issues/42Suggested-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Trond Myklebust authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit e732f448 ] Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Mattias Jacobsson authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 09015855 ] Upon success the update_status handler returns a positive number corresponding to the number of bytes transferred by usb_control_msg. However the return code of the update_status handler should indicate if an error occurred(negative) or how many bytes of the user's input to sysfs that was consumed. Return code zero indicates all bytes were consumed. The bug can for example result in the update_status handler being called twice, the second time with only the "unconsumed" part of the user's input to sysfs. Effectively setting an incorrect brightness. Change the update_status handler to return zero for all successful transactions and forward usb_control_msg's error code upon failure. Signed-off-by:
Mattias Jacobsson <2pi@mok.nu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit fc0c8b36 ] There's some antiquated debug output that's trying to do a hand-made hexdump and turning into horrible 1-byte-per-line output these days. Use print_hex_dump() instead Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Philipp Klocke authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit eb7ebfa3 ] Compiling with clang yields the following warning: sound/i2c/cs8427.c:140:31: warning: implicit conversion from 'int' to 'char' changes value from 160 to -96 [-Wconstant-conversion] data[0] = CS8427_REG_AUTOINC | CS8427_REG_CORU_DATABUF; ~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ Because CS8427_REG_AUTOINC is defined as 128, it is too big for a char field. So change data from char to unsigned char, that it can hold the value. This patch does not change the generated code. Signed-off-by:
Philipp Klocke <philipp97kl@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit c2712b85 ] Andy had some concerns about using regs_get_kernel_stack_nth() in a new function regs_get_kernel_argument() as if there's any error in the stack code, it could cause a bad memory access. To be on the safe side, call probe_kernel_read() on the stack address to be extra careful in accessing the memory. A helper function, regs_get_kernel_stack_nth_addr(), was added to just return the stack address (or NULL if not on the stack), that will be used to find the address (and could be used by other functions) and read the address with kernel_probe_read(). Requested-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20181017165951.09119177@gandalf.local.homeSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Kyeongdon Kim authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 33c4368e ] This fixes the "'hash' may be used uninitialized in this function" net/unix/af_unix.c:1041:20: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized] addr->hash = hash ^ sk->sk_type; Signed-off-by:
Kyeongdon Kim <kyeongdon.kim@lge.com> Signed-off-by:
-
Christoph Hellwig authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 6c404a68 ] We need to transfer device ownership to the CPU before we can manipulate the mapped data. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Christoph Hellwig authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 3a5bd702 ] We can't just transfer ownership to the CPU and then unmap, as this will break with swiotlb. Instead unmap the command and sense buffer a little earlier in the I/O completion handler and get rid of the pci_dma_sync_sg_for_cpu call entirely. Signed-off-by:
-
Lubomir Rintel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 4917fb90 ] A typo that makes it impossible to get the correct clocks for MMP2_CLK_SDH2 and MMP2_CLK_SDH3. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Fixes: 1ec770d9 ("clk: mmp: add mmp2 DT support for clock driver") Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 20054597 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/iscsi_tcp.c:803:15: warning: implicit conversion from enumeration type 'enum iscsi_host_param' to different enumeration type 'enum iscsi_param' [-Wenum-conversion] &addr, param, buf); ^~~~~ 1 warning generated. iscsi_conn_get_addr_param handles ISCSI_HOST_PARAM_IPADDRESS just fine so add an explicit cast to iscsi_param to make it clear to Clang that this is expected behavior. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 362b5da3 ] Clang warns when an enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:3476:13: warning: implicit conversion from enumeration type 'enum sci_task_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = sci_controller_start_task(ihost, ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/host.c:2744:10: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return SCI_SUCCESS; ~~~~~~ ^~~~~~~~~~~ drivers/scsi/isci/host.c:2753:9: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return status; ~~~~~~ ^~~~~~ Avoid all of these implicit conversion by just making sci_controller_start_task use sci_status. This silences Clang and has no functional change since sci_task_status has all of its values mapped to something in sci_status. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit e9e9a103 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:1629:13: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/request.c:1631:12: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ status is of type sci_status but SCI_IO_FAILURE_RESPONSE_VALID is of type sci_io_status. Use SCI_FAILURE_IO_RESPONSE_VALID, which is from sci_status and has SCI_IO_FAILURE_RESPONSE_VALID's exact value since that is what SCI_IO_FAILURE_RESPONSE_VALID is mapped to in the isci.h file. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Uros Bizjak authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 5ebb272b ] Register operand size of invvpid and invept instruction in 64-bit mode has always 64 bits. Adjust inline function argument type to reflect correct size. Signed-off-by:
Uros Bizjak <ubizjak@gmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Gustavo A. R. Silva authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 5d25ff7a ] Add missing break statement in order to prevent the code from falling through to case TEST_UNIT_READY. Addresses-Coverity-ID: 1357338 ("Missing break in switch") Suggested-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Omar Sandoval authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 53d0f8db ] The error handling in fd_probe_drives() doesn't clean up at all. Fix it up in preparation for converting to blk-mq. While we're here, get rid of the commented out amiga_floppy_remove(). Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Wenwen Wang authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 6b995f4e ] In _scif_prog_signal(), the boolean variable 'x100' is used to indicate whether the MIC Coprocessor is X100. If 'x100' is true, the status descriptor will be used to write the value to the destination. Otherwise, a DMA pool will be allocated for this purpose. Specifically, if the DMA pool is allocated successfully, two memory addresses will be returned. One is for the CPU and the other is for the device to access the DMA pool. The former is stored to the variable 'status' and the latter is stored to the variable 'src'. After the allocation, the address in 'src' is saved to 'status->src_dma_addr', which is actually in the DMA pool, and 'src' is then modified. Later on, if an error occurs, the execution flow will transfer to the label 'dma_fail', which will check 'x100' and free up the allocated DMA pool if 'x100' is false. The point here is that 'status->src_dma_addr' is used for freeing up the DMA pool. As mentioned before, 'status->src_dma_addr' is in the DMA pool. And thus, the device is able to modify this data. This can potentially cause failures when freeing up the DMA pool because of the modified device address. This patch avoids the above issue by using the variable 'src' (with necessary calculation) to free up the DMA pool. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Signed-off-by:
-
Duncan Laurie authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 655603de ] The sysfs handler should return the number of bytes consumed, which in the case of a successful write is the entire buffer. Also fix a bug where param.data_len was being set to (count - (2 * sizeof(u32))) instead of just (count - sizeof(u32)). The latter is correct because we skip over the leading u32 which is our param.type, but we were also incorrectly subtracting sizeof(u32) on the line where we were actually setting param.data_len: param.data_len = count - sizeof(u32); This meant that for our example event.kernel_software_watchdog with total length 10 bytes, param.data_len was just 2 prior to this change. To test, successfully append an event to the log with gsmi sysfs. This sample event is for a "Kernel Software Watchdog" > xxd -g 1 event.kernel_software_watchdog 0000000: 01 00 00 00 ad de 06 00 00 00 > cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog > mosys eventlog list | tail -1 14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-by:
Vadim Bendebury <vbendeb@chromium.org> Reviewed-by:
Stefan Reinauer <reinauer@chromium.org> Signed-off-by:
Furquan Shaikh <furquan@google.com> Tested-by:
Furquan Shaikh <furquan@chromium.org> Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Reviewed-by:
Justin TerAvest <teravest@chromium.org> [zwisler: updated changelog for 2nd bug fix and upstream] Signed-off-by:
Ross Zwisler <zwisler@google.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Nikolay Borisov authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 315bed43 ] In btrfs_search_old_slot get_old_root is always used with the assumption it cannot fail. However, this is not true in rare circumstance it can fail and return null. This will lead to null point dereference when the header is read. Fix this by checking the return value and properly handling NULL by setting ret to -EIO and returning gracefully. Coverity-id: 1087503 Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
Lu Fengqi <lufq.fnst@cn.fujitsu.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Chaotian Jing authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit f38a9774 ] when msdc_cmd_is_ready return fail, the req_timeout work has not been inited and cancel_delayed_work() will return false, then, the request return directly and never call mmc_request_done(). so need call mod_delayed_work() before msdc_cmd_is_ready() Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Sergei Shtylyov authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit f34c6e62 ] Since commit 9ec36caf ("of/irq: do irq resolution in platform_get_irq") platform_get_irq() can return -EPROBE_DEFER. However, the driver overrides an error returned by that function with -ENOENT which breaks the deferred probing. Propagate upstream an error code returned by platform_get_irq() and remove the bogus "platform" from the error message, while at it... Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Ali MJ Al-Nasrawy authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 2258ee58 ] Beacons are not updated to reflect TIM changes. This is not compliant with power-saving client stations as the beacons do not have valid TIM and can cause the network to stall at random occasions and to have highly variable latencies. Fix it by updating beacon templates on mac80211 set_tim callback. Addresses an issue described in: https://marc.info/?i=20180911163534.21312d08%20()%20manjaroSigned-off-by:
Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Sam Bobroff authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 473af09b ] eeh_add_to_parent_pe() sometimes removes the EEH_PE_KEEP flag, but it incorrectly removes it from pe->type, instead of pe->state. However, rather than clearing it from the correct field, remove it. Inspection of the code shows that it can't ever have had any effect (even if it had been cleared from the correct field), because the field is never tested after it is cleared by the statement in question. The clear statement was added by commit 807a827d ("powerpc/eeh: Keep PE during hotplug"), but it didn't explain why it was necessary. Signed-off-by:
Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 014704e6 ] The "count < sizeof(struct os_area_db)" comparison is type promoted to size_t so negative values of "count" are treated as very high values and we accidentally return success instead of a negative error code. This doesn't really change runtime much but it fixes a static checker warning. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Al Viro authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 27230e51 ] compat_ptr() for pointer-taking ones... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Andreas Gruenbacher authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit ec23df2b ] Reservations in gfs can span multiple gfs2_bitmaps (but they won't span multiple resource groups). When removing a reservation, we want to clear the GBF_FULL flags of all involved gfs2_bitmaps, not just that of the first bitmap. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Reviewed-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Sergey Senozhatsky authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit d2130e82 ] The way we calculate logbuf free space percentage overflows signed integer: int free; free = __LOG_BUF_LEN - log_next_idx; pr_info("early log buf free: %u(%u%%)\n", free, (free * 100) / __LOG_BUF_LEN); We support LOG_BUF_LEN of up to 1<<25 bytes. Since setup_log_buf() is called during early init, logbuf is mostly empty, so __LOG_BUF_LEN - log_next_idx is close to 1<<25. Thus when we multiply it by 100, we overflow signed integer value range: 100 is 2^6 + 2^5 + 2^2. Example, booting with LOG_BUF_LEN 1<<25 and log_buf_len=2G boot param: [ 0.075317] log_buf_len: -2147483648 bytes [ 0.075319] early log buf free: 33549896(-28%) Make "free" unsigned integer and use appropriate printk() specifier. Link: http://lkml.kernel.org/r/20181010113308.9337-1-sergey.senozhatsky@gmail.com To: Steven Rostedt <rostedt@goodmis.org> Cc: linux-kernel@vger.kernel.org Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
Takashi Sakamoto authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 51e68fb0 ] In some error paths, reference count of firewire unit is not decreased. This commit fixes the bug. Fixes: 5b14ec25('ALSA: firewire: release reference count of firewire unit in .remove callback of bus driver') Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Adrian Bunk authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 65a576e2 ] NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC, which is the opposite of what should happen and can cause nasty regulatory problems. if/else converted to a switch without default to make gcc warn on unhandled enum values. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit ea893695 ] A recent bugfix added a call to i8042_install_filter but did not add the dependency, leading to possible link errors: drivers/platform/built-in.o: In function `asus_nb_wmi_quirks': asus-nb-wmi.c:(.text+0x23af): undefined reference to `i8042_install_filter' This adds a dependency on SERIO_I8042||SERIO_I8042=n to indicate that we can build the driver when the i8042 driver is disabled, but it cannot be built-in when that is a loadable module. Fixes: b5643539 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Kiernan Hager authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit db2582af ] This patch adds support for ALS on the Zenbook UX430UQ to the asus_nb_wmi driver. It also renames "quirk_asus_ux330uak" to "quirk_asus_forceals" because it is now used for more than one model of computer, and should thus have a more general name. Signed-off-by:
Kiernan Hager <kah.listaddress@gmail.com> [andy: massaged commit message, fixed indentation and commas in the code] Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Oleksij Rempel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit e9b61518 ] some laptops, for example ASUS UX330UAK, have brocken als_get function but working als_set funktion. In this case, ALS will stay turned off. Method (WMNB, 3, Serialized) { ... If (Local0 == 0x53545344) { ... If (IIA0 == 0x00050001) { If (!ALSP) { Return (0x02) } Local0 = (GALS & 0x10) <<<---- bug, should be: (GALS () & 0x10) If (Local0) { Return (0x00050001) } Else { Return (0x00050000) } } ..... If (Local0 == 0x53564544) { ... If (IIA0 == 0x00050001) { Return (ALSC (IIA1)) } ...... Method (GALS, 0, NotSerialized) { Local0 = Zero Local0 |= 0x20 If (ALAE) { Local0 |= 0x10 } Local1 = 0x0A Local1 <<= 0x08 Local0 |= Local1 Return (Local0) } Since it works without problems on Windows I assume ASUS WMI driver for Win never trying to get ALS state, and instead it is setting it by default to ON. This patch will do the same. Turn ALS on by default. Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
Oleksij Rempel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit aca234f6 ] Asus Zenbook ux31a is providing ACPI0008 interface for ALS (Ambient Light Sensor), which is accessible for OS => Win 7. This sensor can be used with iio/acpi-als driver. Since it is disabled by default, we should use asus-wmi interface to enable it. Signed-off-by:
-
Kai-Chuan Hsieh authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 8023eff1 ] The bluetooth adapter Atheros AR3012 can't be enumerated and make the bluetooth function broken. T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 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 I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The error is: usb 2-6: device not accepting address 7, error -62 usb usb2-port6: unable to enumerate USB device It is caused by adapter's connected port is mapped to xHC controller, but the xHCI is not supported by the usb device. The output of 'sudo lspci -nnxxx -s 00:14.0': 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00 By referencing Intel Platform Controller Hub(PCH) datasheet, the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h decides the setting of mapping the port to EHCI controller or xHC controller. And the port mapped to xHC will enable xHCI during bus resume. The setting of disabling bluetooth adapter's connected port is 0x000001D9. The value can be obtained by few times 1 bit flip operation. The suited configuration should have the 'lsusb -t' result with bluetooth using ehci: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M Signed-off-by:
Kai-Chuan Hsieh <kai.chiuan@gmail.com> Acked-by:
Corentin Chary <corentin.chary@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> [andy: resolve merge conflict in asus-wmi.h] Signed-off-by:
-
zino lin authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 999d4376 ] acpi_video0 doesn't work, asus-wmi brightness interface doesn't work, too. So, we use native brightness interface to handle the brightness adjustion, and add quirk_asus_ux303ub. Signed-off-by:
zino lin <linzino7@gmail.com> Acked-by:
-
Oleksij Rempel authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit b5643539 ] Some revisions of the ASUS Q500A series have a keyboard related issue which is reproducible only after Windows with installed ASUS tools is started. In this case the Linux side will have a blocked keyboard or report incorrect or incomplete hotkey events. To make Linux work properly again, a complete power down (unplug power supply and remove battery) is needed. Linux/atkbd after a clean start will get the following code on VOLUME_UP key: {0xe0, 0x30, 0xe0, 0xb0}. After Windows, the same key will generate this codes: {0xe1, 0x23, 0xe0, 0x30, 0xe0, 0xb0}. As result atkdb will be confused by buggy codes. This patch is filtering this buggy code out. https://bugzilla.kernel.org/show_bug.cgi?id=119391Signed-off-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 6b7ff2af ] The Asus Z550MA has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. Signed-off-by:
João Paulo Rechi Vita <jprvita@endlessm.com> Reported-by:
Ming Shuo Chiu <chiu@endlessm.com> Reviewed-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 02db9ff7 ] The Asus U303LB has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. Signed-off-by:
Mousou Yuu <guogaishiwo@gmail.com> Reviewed-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit 2d735244 ] The Asus N552VW has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. Signed-off-by:
-
João Paulo Rechi Vita authored
BugLink: https://bugs.launchpad.net/bugs/1854855 [ Upstream commit a961a285 ] The Asus X456UF has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from registering RFKill switches at all for this laptop and allows asus-wireless to drive the LED through the ASHS ACPI device. This laptop already has a quirk for setting WAPF=4, so this commit creates a new quirk, quirk_no_rfkill_wapf4, which both disables rfkill and sets WAPF=4. Signed-off-by:
Carlo Caione <carlo@endlessm.com> Reviewed-by:
-
