- Jan 27, 2021
-
-
Thinh Nguyen authored
commit c28095bc upstream. Use lock to guard against concurrent access for soft-connect/disconnect operations when writing to soft_connect sysfs. Fixes: 2ccea03a ("usb: gadget: introduce UDC Class") Cc: stable@vger.kernel.org Acked-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.Thinh.Nguyen@synopsys.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ryan Chen authored
commit 4e0dcf62 upstream. The vhub engine has two dma mode, one is descriptor list, another is single stage DMA. Each mode has different stop register setting. Descriptor list operation (bit2) : 0 disable reset, 1: enable reset Single mode operation (bit0) : 0 : disable, 1: enable Fixes: 7ecca2a4 ("usb/gadget: Add driver for Aspeed SoC virtual hub") Cc: stable <stable@vger.kernel.org> Acked-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
Ryan Chen <ryan_chen@aspeedtech.com> Link: https://lore.kernel.org/r/20210108081238.10199-2-ryan_chen@aspeedtech.com Signed-off-by:
-
Longfang Liu authored
commit 643a4df7 upstream. The system that use Synopsys USB host controllers goes to suspend when using USB audio player. This causes the USB host controller continuous send interrupt signal to system, When the number of interrupts exceeds 100000, the system will forcibly close the interrupts and output a calltrace error. When the system goes to suspend, the last interrupt is reported to the driver. At this time, the system has set the state to suspend. This causes the last interrupt to not be processed by the system and not clear the interrupt flag. This uncleared interrupt flag constantly triggers new interrupt event. This causing the driver to receive more than 100,000 interrupts, which causes the system to forcibly close the interrupt report and report the calltrace error. so, when the driver goes to sleep and changes the system state to suspend, the interrupt flag needs to be cleared. Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongfang@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Eugene Korenevsky authored
commit 280a9045 upstream. According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever USBCMD.RS=1. However, it is a good practice to wait some time after setting USBCMD.RS (approximately 100ms) until USBSTS.HCHalted become zero. Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs (see BugLink). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095 Acked-by:
Eugene Korenevsky <ekorenevsky@astralinux.ru> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210110173609.GA17313@himera.home Signed-off-by:
-
Pali Rohár authored
commit 54ca955b upstream. Commit c685af11 ("serial: mvebu-uart: fix tx lost characters") fixed tx lost characters at low baud rates but started causing tx lost characters when kernel is going to power off or reboot. TX_EMP tells us when transmit queue is empty therefore all characters were transmitted. TX_RDY tells us when CPU can send a new character. Therefore we need to use different check prior transmitting new character and different check after all characters were sent. This patch splits polling code into two functions: wait_for_xmitr() which waits for TX_RDY and wait_for_xmite() which waits for TX_EMP. When rebooting A3720 platform without this patch on UART is print only: [ 42.699� And with this patch on UART is full output: [ 39.530216] reboot: Restarting system Fixes: c685af11 ("serial: mvebu-uart: fix tx lost characters") Signed-off-by:
Pali Rohár <pali@kernel.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201223191931.18343-1-pali@kernel.org Signed-off-by:
-
Wang Hui authored
commit 927633a6 upstream. In stm_heartbeat_init(): return value gets reset after the first iteration by stm_source_register_device(), so allocation failures after that will, after a clean up, return success. Fix that. Fixes: 11929185 ("stm class: Add heartbeat stm source device") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hui <john.wanghui@huawei.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Link: https://lore.kernel.org/r/20210115195917.3184-2-alexander.shishkin@linux.intel.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Alexander Shishkin authored
commit cb5c681a upstream. This adds support for the Trace Hub in Alder Lake-P. Signed-off-by:
-
Andy Lutomirski authored
commit 67de8dca upstream. The default kernel_fpu_begin() doesn't work on systems that support XMM but haven't yet enabled CR4.OSFXSR. This causes crashes when _mmx_memcpy() is called too early because LDMXCSR generates #UD when the aforementioned bit is clear. Fix it by using kernel_fpu_begin_mask(KFPU_387) explicitly. Fixes: 7ad81676 ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()") Reported-by:
Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Krzysztof Piotr Olędzki <ole@ans.pl> Tested-by:
-
Borislav Petkov authored
commit 1eb8f690 upstream. Move it outside of CONFIG_SMP in order to avoid ifdeffery at the usage sites. Fixes: 76e2fc63 ("x86/cpu/amd: Set __max_die_per_package on AMD") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Andy Lutomirski authored
commit e4512289 upstream. Currently, requesting kernel FPU access doesn't distinguish which parts of the extended ("FPU") state are needed. This is nice for simplicity, but there are a few cases in which it's suboptimal: - The vast majority of in-kernel FPU users want XMM/YMM/ZMM state but do not use legacy 387 state. These users want MXCSR initialized but don't care about the FPU control word. Skipping FNINIT would save time. (Empirically, FNINIT is several times slower than LDMXCSR.) - Code that wants MMX doesn't want or need MXCSR initialized. _mmx_memcpy(), for example, can run before CR4.OSFXSR gets set, and initializing MXCSR will fail because LDMXCSR generates an #UD when the aforementioned CR4 bit is not set. - Any future in-kernel users of XFD (eXtended Feature Disable)-capable dynamic states will need special handling. Add a more specific API that allows callers to specify exactly what they want. Signed-off-by:
-
Mathias Kresin authored
commit 599b3063 upstream. Since commit 55567976 ("genirq/irqdomain: Allow partial trimming of irq_data hierarchy") the irq_data chain is valided. The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi domain hierarchy as valid, since the ipi domain has the irq domain set as parent, but the parent domain has no chip set. Hence the boot ends in a kernel panic. Set the chip for the parent domain as it is done in the mips gic irq driver, to have a valid irq_data chain. Fixes: 3838a547 ("irqchip: mips-cpu: Introduce IPI IRQ domain support") Cc: <stable@vger.kernel.org> # v5.10+ Signed-off-by:
Mathias Kresin <dev@kresin.me> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210107213603.1637781-1-dev@kresin.me Signed-off-by:
-
Ronnie Sahlberg authored
commit 214a5ea0 upstream. RHBZ 1848178 The original intent of returning an error in this function in the patch: "CIFS: Mask off signals when sending SMB packets" was to avoid interrupting packet send in the middle of sending the data (and thus breaking an SMB connection), but we also don't want to fail the request for non-fatal signals even before we have had a chance to try to send it (the reported problem could be reproduced e.g. by exiting a child process when the parent process was in the midst of calling futimens to update a file's timestamps). In addition, since the signal may remain pending when we enter the sending loop, we may end up not sending the whole packet before TCP buffers become full. In this case the code returns -EINTR but what we need here is to return -ERESTARTSYS instead to allow system calls to be restarted. Fixes: b30c74c7 ("CIFS: Mask off signals when sending SMB packets") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit efd597b2 upstream. The power-down mask of the ad5504 is actually a power-up mask. Meaning if a bit is set the corresponding channel is powered up and if it is not set the channel is powered down. The driver currently has this the wrong way around, resulting in the channel being powered up when requested to be powered down and vice versa. Fixes: 3bbbf150 ("staging:iio:dac:ad5504: Use strtobool for boolean values") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Acked-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201209104649.5794-1-lars@metafoo.de Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Vincent Mailhol authored
[ Upstream commit 50aca891 ] After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the peak_usb_netif_rx_ni(). Reordering the lines solves the issue. Fixes: 0a25e1f4 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Link: https://lore.kernel.org/r/20210120114137.200019-4-mailhol.vincent@wanadoo.fr Signed-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vincent Mailhol authored
[ Upstream commit 75854cad ] After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the canfd_frame cfd which aliases skb memory is accessed after the netif_rx_ni(). Fixes: a8f820a3 ("can: add Virtual CAN Tunnel driver (vxcan)") Link: https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vincent@wanadoo.fr Signed-off-by:
-
Vincent Mailhol authored
[ Upstream commit 03f16c50 ] After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the netif_rx_ni() in: stats->rx_bytes += cf->len; Reordering the lines solves the issue. Fixes: 39549eef ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vincent@wanadoo.fr Signed-off-by:
-
Hangbin Liu authored
[ Upstream commit fd23d2dc ] The previous test added an address with a specified metric and check if correspond route was created. I somehow added two logs for the same test. Remove the duplicated one. Reported-by:
Antoine Tenart <atenart@redhat.com> Fixes: 0d29169a ("selftests/net/fib_tests: update addr_metric_test for peer route testing") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20210119025930.2810532-1-liuhangbin@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 07022273 ] THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function: Method (VGBS, 0, Serialized) { If ((^^PCI0.LPCB.EC0.ROLS == Zero)) { VBDS = Zero } Else { VBDS = Zero } Return (VBDS) /* \_SB_.VGBI.VBDS */ } Which is obviously wrong, because it always returns 0 independent of the 2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver to initially report SW_TABLET_MODE = 1 to userspace, which is known to cause problems when the 2-in-1 is actually in laptop mode. During earlier testing this turned out to not be a problem because the 2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state. Further testing however has shown that this Notify() soon after the intel-vbtn driver loads, does not always happen. When the Notify does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in a non-working touchpad. IOW the tablet-mode reporting is not reliable on this device, so it should be dropped from the allow-list, fixing the touchpad sometimes not working. Fixes: 8169bd3e ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Wolfram Sang authored
[ Upstream commit 1b2cfa2d ] I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the SMBus 2.0 specs. No reason to add one to it. Fixes: 886f6f83 ("i2c: octeon: Support I2C_M_RECV_LEN") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Robert Richter <rric@kernel.org> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Ariel Marcovitch authored
[ Upstream commit 2225a8dd ] This is a bug that causes early crashes in builds with an .exit.text section smaller than a page and an .init.text section that ends in the beginning of a physical page (this is kinda random, which might explain why this wasn't really encountered before). The init sections are ordered like this: .init.text .exit.text .init.data Currently, these sections aren't page aligned. Because the init code might become read-only at runtime and because the .init.text section can potentially reside on the same physical page as .init.data, the beginning of .init.data might be mapped read-only along with .init.text. Then when the kernel tries to modify a variable in .init.data (like kthreadd_done, used in kernel_init()) the kernel panics. To avoid this, make _einittext page aligned and also align .exit.text to make sure .init.data is always seperated from the text segments. Fixes: 060ef9d8 ("...
-
Arnd Bergmann authored
[ Upstream commit b1120365 ] Phil Oester reported that a fix for a possible buffer overrun that I sent caused a regression that manifests in this output: Event Message: A PCI parity error was detected on a component at bus 0 device 5 function 0. Severity: Critical Message ID: PCI1308 The original code tried to handle the sense data pointer differently when using 32-bit 64-bit DMA addressing, which would lead to a 32-bit dma_addr_t value of 0x11223344 to get stored 32-bit kernel: 44 33 22 11 ?? ?? ?? ?? 64-bit LE kernel: 44 33 22 11 00 00 00 00 64-bit BE kernel: 00 00 00 00 44 33 22 11 or a 64-bit dma_addr_t value of 0x1122334455667788 to get stored as 32-bit kernel: 88 77 66 55 ?? ?? ?? ?? 64-bit kernel: 88 77 66 55 44 33 22 11 In my patch, I tried to ensure that the same value is used on both 32-bit and 64-bit kernels, and picked what seemed to be the most sensible combination, storing 32-bit addresses in the first four bytes (as 32-bit kernels already did), and 64-bit addresses in eight consecutive bytes (as 64-bit kernels already did), but evidently this was incorrect. Always storing the dma_addr_t pointer as 64-bit little-endian, i.e. initializing the second four bytes to zero in case of 32-bit addressing, apparently solved the problem for Phil, and is consistent with what all 64-bit little-endian machines did before. I also checked in the history that in previous versions of the code, the pointer was always in the first four bytes without padding, and that previous attempts to fix 64-bit user space, big-endian architectures and 64-bit DMA were clearly flawed and seem to have introduced made this worse. Link: https://lore.kernel.org/r/20210104234137.438275-1-arnd@kernel.org Fixes: 381d34e3 ("scsi: megaraid_sas: Check user-provided offsets") Fixes: 107a60dd ("scsi: megaraid_sas: Add support for 64bit consistent DMA") Fixes: 94cd65dd ("[SCSI] megaraid_sas: addded support for big endian architecture") Fixes: 7b2519af ("[SCSI] megaraid_sas: fix 64 bit sense pointer truncation") Reported-by:
Phil Oester <kernel@linuxace.com> Tested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Billy Tsai authored
[ Upstream commit 92ff62a7 ] The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from SCU414 to SCU4B4. Signed-off-by:
Billy Tsai <billy_tsai@aspeedtech.com> Fixes: 2eda1cde ("pinctrl: aspeed: Add AST2600 pinmux support") Reviewed-by:
Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20201217024912.3198-1-billy_tsai@aspeedtech.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Youling Tang authored
[ Upstream commit fdcfeaba ] Use the common INIT_DATA_SECTION rule for the linker script in an effort to regularize the linker script. Signed-off-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1604487550-20040-1-git-send-email-tangyouling@loongson.cn Signed-off-by:
-
Ben Skeggs authored
[ Upstream commit caeb6ab8 ] VRAM offset 0 is a valid address, triggered on GA102. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ben Skeggs authored
[ Upstream commit add42781 ] Signed-off-by:
-
Ben Skeggs authored
[ Upstream commit ba6e9ab0 ] Noticed while debugging GA102. Signed-off-by:
-
Ben Skeggs authored
[ Upstream commit e05e06cd ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by:
-
Ben Skeggs authored
[ Upstream commit 402a8966 ] This issue has generally been covered up by the presence of additional expansion ROMs after the ones we're interested in, with header fetches of subsequent images loading enough of the ROM to hide the issue. Noticed on GA102, which lacks a type 0x70 image compared to TU102,. [ 906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes [ 906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes [ 906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes [ 906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes vs [ 22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes [ 22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes [ 23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes [ 23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes [ 23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes Signed-off-by:
-
Wayne Lin authored
[ Upstream commit 02ce73b0 ] [Why] Find out when we try to disable CRC calculation, crc generation is still enabled. Main reason is that dc_stream_configure_crc() will never get called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE. [How] Add checking condition that when source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call dc_stream_configure_crc() to disable crc calculation. Also, clean up crc window when disable crc calculation. Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Victor Zhao authored
[ Upstream commit f14a5c34 ] psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by:
Victor Zhao <Victor.Zhao@amd.com> Reviewed-by:
Emily.Deng <Emily.Deng@amd.com> Signed-off-by:
-
Sagar Shrikant Kadam authored
[ Upstream commit 0983834a ] Ethernet phy VSC8541-01 on HiFive Unleashed has its reset line connected to a gpio, so enable GPIO driver's required to reset the phy. Signed-off-by:
Sagar Shrikant Kadam <sagar.kadam@sifive.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
-
Sagar Shrikant Kadam authored
[ Upstream commit be969b7c ] HiFive unleashed A00 board has VSC8541-01 ethernet phy, this device is identified as a Revision B device as described in device identification registers. In order to use this phy in the unmanaged mode, it requires a specific reset sequence of logical 0-1-0-1 transition on the NRESET pin as documented here [1]. Currently, the bootloader (fsbl or u-boot-spl) takes care of the phy reset. If due to some reason the phy device hasn't received the reset by the prior stages before the linux macb driver comes into the picture, the MACB mii bus gets probed but the mdio scan fails and is not even able to read the phy ID registers. It gives an error message: "libphy: MACB_mii_bus: probed mdio_bus 10090000.ethernet-ffffffff: MDIO device at address 0 is missing." Thus adding the device OUI (Organizationally Unique Identifier) to the phy device node helps to probe the phy device. [1]: VSC8541-01 datasheet: https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf Signed-off-by:
-
David Woodhouse authored
[ Upstream commit b36b0fe9 ] It's useful to be able to test non-vector event channel delivery, to make sure Linux will work properly on older Xen which doesn't have it. It's also useful for those working on Xen and Xen-compatible hypervisors, because there are guest kernels still in active use which use PCI INTX even when vector delivery is available. Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20210106153958.584169-4-dwmw2@infradead.org Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
David Woodhouse authored
[ Upstream commit 3499ba81 ] For a while, event channel notification via the PCI platform device has been broken, because we attempt to communicate with xenstore before we even have notifications working, with the xs_reset_watches() call in xs_init(). We tend to get away with this on Xen versions below 4.0 because we avoid calling xs_reset_watches() anyway, because xenstore might not cope with reading a non-existent key. And newer Xen *does* have the vector callback support, so we rarely fall back to INTX/GSI delivery. To fix it, clean up a bit of the mess of xs_init() and xenbus_probe() startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM case, deferring it to be called from xenbus_probe() in the XS_HVM case instead. Then fix up the invocation of xenbus_probe() to happen either from its device_initcall if the callback is available early enough, or when the callback is finally set up. This means that the ha...
-
Arnd Bergmann authored
[ Upstream commit c35a824c ] With UBSAN enabled and building with clang, there are occasionally warnings like WARNING: modpost: vmlinux.o(.text+0xc533ec): Section mismatch in reference from the function arch_atomic64_or() to the variable .init.data:numa_nodes_parsed The function arch_atomic64_or() references the variable __initdata numa_nodes_parsed. This is often because arch_atomic64_or lacks a __initdata annotation or the annotation of numa_nodes_parsed is wrong. for functions that end up not being inlined as intended but operating on __initdata variables. Mark these as __always_inline, along with the corresponding asm-generic wrappers. Signed-off-by:
Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210108092024.4034860-1-arnd@kernel.org Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Peter Geis authored
[ Upstream commit f4eccc7f ] Current implementation defaults the hda clocks to clk_m. This causes hda to run too slow to operate correctly. Fix this by defaulting to pll_p and setting the frequency to the correct rate. This matches upstream t124 and downstream t30. Acked-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Ion Agorria <ion@agorria.com> Acked-by:
Sameer Pujar <spujar@nvidia.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20210108135913.2421585-2-pgwipeout@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Seth Miller authored
[ Upstream commit 7c38e769 ] Battery status is being reported for the Elan touchscreen on ASUS UX550 laptops despite not having a batter. It always shows either 0 or 1%. Signed-off-by:
Seth Miller <miller.seth@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Filipe Laíns authored
[ Upstream commit e400071a ] Tested. The device gets correctly exported to userspace and I can see mouse and keyboard events. Signed-off-by:
Filipe Laíns <lains@archlinux.org> Signed-off-by:
-
Damien Le Moal authored
[ Upstream commit 1f1496a9 ] Setup the port uartclk in sifive_serial_probe() so that the base baud rate is correctly printed during device probe instead of always showing "0". I.e. the probe message is changed from 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 0) is a SiFive UART v0 to the correct: 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 115200) is a SiFive UART v0 Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by:
-
Damien Le Moal authored
[ Upstream commit 11f4c2e9 ] If of_clk_init() is not called in time_init(), clock providers defined in the system device tree are not initialized, resulting in failures for other devices to initialize due to missing clocks. Similarly to other architectures and to the default kernel time_init() implementation, call of_clk_init() before executing timer_probe() in time_init(). Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Reviewed-by:
-
