- Aug 13, 2021
-
-
Dmitry Baryshkov authoredReset PHY on orientation change to restore USB gadget support on RB5 Signed-off-by:Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
- Aug 12, 2021
-
-
Thara Gopinath authored
Add dt binding documentation to describe Qualcomm Limits Management Hardware node. Signed-off-by:
Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by:
Aníbal Limón <anibal.limon@linaro.org>
-
Thara Gopinath authored
Now that Limits h/w is enabled to monitor thermal events around cpus and throttle the cpu frequencies, remove cpufreq cooling device for the CPU thermal zones which does software throttling of cpu frequencies. Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Thara Gopinath authored
Add LMh nodes for cpu cluster0 and cpu cluster1. Also add interrupt support in cpufreq node to capture the LMh interrupt and let the scheduler know of the max frequency throttling. Reviewed-by:
-
Thara Gopinath authored
Add interrupt support to notify the kernel of h/w initiated frequency throttling by LMh. Convey this to scheduler via thermal presssure interface. Signed-off-by:
-
Thara Gopinath authored
Driver enabling various pieces of Limits Management Hardware(LMh) for cpu cluster0 and cpu cluster1 namely kick starting monitoring of temperature, current, battery current violations, enabling reliability algorithm and setting up various temperature limits. The following has been explained in the cover letter. I am including this here so that this remains in the commit message as well. LMh is a hardware infrastructure on some Qualcomm SoCs that can enforce temperature and current limits as programmed by software for certain IPs like CPU. On many newer LMh is configured by firmware/TZ and no programming is needed from the kernel side. But on certain SoCs like sdm845 the firmware does not do a complete programming of the h/w. On such soc's kernel software has to explicitly set up the temperature limits and turn on various monitoring and enforcing algorithms on the hardware. Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630 Signed-off-by:
-
Thara Gopinath authored
Introduce SCM calls to access/configure limits management hardware(LMH). Reviewed-by:
-
Aníbal Limón authored
This reverts commit 1ca79191. Not in usage at this time in RB5. Signed-off-by:
-
Aníbal Limón authored
This reverts commit 47c5b711. Signed-off-by:
-
Aníbal Limón authored
This reverts commit 72ad1a11. Signed-off-by:
-
Aníbal Limón authored
This reverts commit 8312490b. Signed-off-by:
-
Aníbal Limón authored
This reverts commit ed5c77c8. Signed-off-by:
-
Aníbal Limón authored
This reverts commit a2bcc4a9. Signed-off-by:
-
Aníbal Limón authored
This reverts commit 92ad0339. Signed-off-by:
-
- Aug 11, 2021
-
-
Aníbal Limón authored
Signed-off-by:
-
- Aug 09, 2021
-
-
Aníbal Limón authored
This is the 5.13.9 stable release Signed-off-by:
-
- Aug 08, 2021
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210806081113.718626745@linuxfoundation.org Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Aakash Hemadri <aakashhemdri123@gmail.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Guenter Roeck authored
commit 0d5c3954 upstream. Commit 3a70dd2d ("spi: mediatek: fix fifo rx mode") claims that fifo RX mode was never handled, and adds the presumably missing code to the FIFO transfer function. However, the claim that receive data was not handled is incorrect. It was handled as part of interrupt handling after the transfer was complete. The code added with the above mentioned commit reads data from the receive FIFO before the transfer is started, which is wrong. This results in an actual transfer error on a Hayato Chromebook. Remove the code trying to handle receive data before the transfer is started to fix the problem. Fixes: 3a70dd2d ("spi: mediatek: fix fifo rx mode") Cc: Peter Hess <peter.hess@ph-home.de> Cc: Frank Wunderlich <frank-w@public-files.de> Cc: Tzung-Bi Shih <tzungbi@google.com> Cc: Hsin-Yi Wang <hsinyi@google.com> Signed-off-by:
Hsin-Yi Wang <hsinyi@google.com> Tested-by:
Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20210802030023.1748777-1-linux@roeck-us.net Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Stylon Wang authored
commit 6be50f5d upstream. [Why] Regression found in some embedded panels traces back to the earliest upstreamed ASSR patch. The changed code flow are causing problems with some panels. [How] - Change ASSR enabling code while preserving original code flow as much as possible - Simplify the code on guarding with internal display flag Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213779 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1620 Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Stylon Wang <stylon.wang@amd.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 5e65819a which is commit cb011044 upstream. It is reported to cause problems with systems and probably should not have been backported in the first place :( Link: https://lore.kernel.org/r/20210803165108.4154cd52@endymion Reported-by:
Jean Delvare <jdelvare@suse.de> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Wim Van Sebroeck <wim@linux-watchdog.org> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit c19a2820 which is commit 0ea9fd00 upstream. It has been reported to have problems: https://lore.kernel.org/linux-bluetooth/8735ryk0o7.fsf@baylibre.com/ Reported-by:
-
Jens Axboe authored
[ Upstream commit 991468dc ] Catch an illegal case to queue async from an unrelated task that got the ring fd passed to it. This should not be possible to hit, but better be proactive and catch it explicitly. io-wq is extended to check for early IO_WQ_WORK_CANCEL being set on a work item as well, so it can run the request through the normal cancelation path. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jens Axboe authored
[ Upstream commit 3c30ef0f ] There are two reasons why this shouldn't be done: 1) Ring is exiting, and we're canceling requests anyway. Any request should be canceled anyway. In theory, this could iterate for a number of times if someone else is also driving the target block queue into request starvation, however the likelihood of this happening is miniscule. 2) If the original task decided to pass the ring to another task, then we don't want to be reissuing from this context as it may be an unrelated task or context. No assumptions should be made about the context in which ->release() is run. This can only happen for pure read/write, and we'll get -EFAULT on them anyway. Link: https://lore.kernel.org/io-uring/YPr4OaHv0iv0KTOc@zeniv-ca.linux.org.uk/ Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit d7940911 ] [Why] Vertical and horizontal borders in timings are treated as increasing the active area - vblank and hblank actually shrink. Our input into DML does not include these borders so it incorrectly assumes it has more time than available for vstartup and tmdl calculations for some modes with borders. An example of such a timing would be 640x480@72Hz: h_total: 832 h_border_left: 8 h_addressable: 640 h_border_right: 8 h_front_porch: 16 h_sync_width: 40 v_total: 520 v_border_top: 8 v_addressable: 480 v_border_bottom: 8 v_front_porch: 1 v_sync_width: 3 pix_clk_100hz: 315000 [How] Include borders as part of destination vactive/hactive. This change DCN20+ so it has wide impact, but the destination vactive and hactive are only really used for vstartup calculation anyway. Most modes do not have vertical or horizontal borders. Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Victor Lu authored
[ Upstream commit ec3102dc ] [why] A comparison error made it possible to not iterate through all the specified prefetch modes. [how] Correct "<" to "<=" Reviewed-by:
Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by:
Victor Lu <victorchengchi.lu@amd.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit 234211b8 ] The metadata address is set after the trace event, so the trace is not capturing anything useful. Rather than logging the memory address, it's useful to know if the command carries a metadata payload, so change the trace event to log that true/false state instead. Signed-off-by:
Keith Busch <kbusch@kernel.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Borislav Petkov authored
[ Upstream commit 47e1e233 ] One of the SUSE QA tests triggered: localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000 which comes from x86's version of efi_arch_mem_reserve() trying to reserve a memory region. Usually, that function expects EFI_BOOT_SERVICES_DATA memory descriptors but the above case is for the MOKvar table which is allocated in the EFI shim as runtime services. That lead to a fix changing the allocation of that table to boot services. However, that fix broke booting SEV guests with that shim leading to this kernel fix 8d651ee9 ("x86/ioremap: Map EFI-reserved memory as encrypted for SEV") which extended the ioremap hint to map reserved EFI boot services as decrypted too. However, all that wasn't needed, IMO, because that error message in efi_arch_mem_reserve() was innocuous in this case - if the MOKvar table is not in boot services, then it doesn't need to be reserved in the first place because it is, well, in runtime services which *should* be reserved anyway. So do that reservation for the MOKvar table only if it is allocated in boot services data. I couldn't find any requirement about where that table should be allocated in, unlike the ESRT which allocation is mandated to be done in boot services data by the UEFI spec. Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 82d28b67 ] During probe the parent_clk_id is set to -1 which should not be used to array index within hsdiv_rates[]. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20210717122820.1467-3-peter.ujfalusi@gmail.com Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 78d2a05e ] In case of an error within j721e_audio_startup() the domain->active must be decremented to avoid unbalanced counter. Signed-off-by:
-
Pravin B Shelar authored
[ Upstream commit a17ad096 ] In some cases skb head could be locked and entire header data is pulled from skb. When skb_zerocopy() called in such cases, following BUG is triggered. This patch fixes it by copying entire skb in such cases. This could be optimized incase this is performance bottleneck. ---8<--- kernel BUG at net/core/skbuff.c:2961! invalid opcode: 0000 [#1] SMP PTI CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 5.4.0-77-generic #86-Ubuntu Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:skb_zerocopy+0x37a/0x3a0 RSP: 0018:ffffbcc70013ca38 EFLAGS: 00010246 Call Trace: <IRQ> queue_userspace_packet+0x2af/0x5e0 [openvswitch] ovs_dp_upcall+0x3d/0x60 [openvswitch] ovs_dp_process_packet+0x125/0x150 [openvswitch] ovs_vport_receive+0x77/0xd0 [openvswitch] netdev_port_receive+0x87/0x130 [openvswitch] netdev_frame_hook+0x4b/0x60 [openvswitch] __netif_receive_skb_core+0x2b4/0xc90 __netif_receive_skb_one_core+0x3f/0xa0 __netif_receive_skb+0x18/0x60 process_backlog+0xa9/0x160 net_rx_action+0x142/0x390 __do_softirq+0xe1/0x2d6 irq_exit+0xae/0xb0 do_IRQ+0x5a/0xf0 common_interrupt+0xf/0xf Code that triggered BUG: int skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) { int i, j = 0; int plen = 0; /* length of skb->head fragment */ int ret; struct page *page; unsigned int offset; BUG_ON(!from->head_frag && !hlen); Signed-off-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Oder Chiou authored
[ Upstream commit 6a503e1c ] While using the DMIC recording, the garbled data will be captured by the DMIC. It is caused by the critical power of PLL closed in the jack detect function. Signed-off-by:
Oder Chiou <oder_chiou@realtek.com> Link: https://lore.kernel.org/r/20210716085853.20170-1-oder_chiou@realtek.com Signed-off-by:
-
Jia He authored
[ Upstream commit 6206b798 ] Liajian reported a bug_on hit on a ThunderX2 arm64 server with FastLinQ QL41000 ethernet controller: BUG: scheduling while atomic: kworker/0:4/531/0x00000200 [qed_probe:488()]hw prepare failed kernel BUG at mm/vmalloc.c:2355! Internal error: Oops - BUG: 0 [#1] SMP CPU: 0 PID: 531 Comm: kworker/0:4 Tainted: G W 5.4.0-77-generic #86-Ubuntu pstate: 00400009 (nzcv daif +PAN -UAO) Call trace: vunmap+0x4c/0x50 iounmap+0x48/0x58 qed_free_pci+0x60/0x80 [qed] qed_probe+0x35c/0x688 [qed] __qede_probe+0x88/0x5c8 [qede] qede_probe+0x60/0xe0 [qede] local_pci_probe+0x48/0xa0 work_for_cpu_fn+0x24/0x38 process_one_work+0x1d0/0x468 worker_thread+0x238/0x4e0 kthread+0xf0/0x118 ret_from_fork+0x10/0x18 In this case, qed_hw_prepare() returns error due to hw/fw error, but in theory work queue should be in process context instead of interrupt. The root cause might be the unpaired spin_{un}lock_bh() in _qed_mcp_cmd_and_union(), which causes botton half is disabled incorrectly. Reported-by:
Lijian Zhang <Lijian.Zhang@arm.com> Signed-off-by:
Jia He <justin.he@arm.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 776ac63a ] r8152 driver sets up the MAC address at reset-resume, while rtl8152_set_mac_address() has the temporary autopm get/put. This may lead to a deadlock as the PM lock has been already taken for the execution of the runtime PM callback. This patch adds the workaround to avoid the superfluous autpm when called from rtl8152_reset_resume(). Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 9c23aa51 ] rtl8152_close() takes the refcount via usb_autopm_get_interface() but it doesn't release when RTL8152_UNPLUG test hits. This may lead to the imbalance of PM refcount. This patch addresses it. Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 Signed-off-by:
-
Axel Lin authored
[ Upstream commit ea986908 ] If use dev->parent, the regulator_unregister will not be called when this driver is unloaded. Fix it by using dev instead. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210702142140.2678130-1-axel.lin@ingics.com Signed-off-by:
-
Kyle Russell authored
[ Upstream commit 9cf76a72 ] These are backwards from Table 7-71 of the TLV320AIC3100 spec [1]. This was broken in 12eb4d66 when BCLK_MASTER and WCLK_MASTER were converted from 0x08 and 0x04 to BIT(2) and BIT(3), respectively. -#define AIC31XX_BCLK_MASTER 0x08 -#define AIC31XX_WCLK_MASTER 0x04 +#define AIC31XX_BCLK_MASTER BIT(2) +#define AIC31XX_WCLK_MASTER BIT(3) Probably just a typo since the defines were not listed in bit order. [1] https://www.ti.com/lit/gpn/tlv320aic3100 Signed-off-by:
Kyle Russell <bkylerussell@gmail.com> Link: https://lore.kernel.org/r/20210622010941.241386-1-bkylerussell@gmail.com Signed-off-by:
-
Alain Volmat authored
[ Upstream commit e4a5c198 ] In case of Full-Duplex mode, DXP flag is set when RXP and TXP flags are set. But to avoid 2 different handlings, just add TXP and RXP flag in the mask instead of DXP, and then keep the initial handling of TXP and RXP events. Also rephrase comment about EOTIE which is one of the interrupt enable bits. It is not triggered by any event. Signed-off-by:
Amelie Delaunay <amelie.delaunay@foss.st.com> Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Reviewed-by:
-
Axel Lin authored
[ Upstream commit 6549c46a ] For linear regulators, the n_voltages should be (max - min) / step + 1. Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f. If value is from 20 to 31, the voltage will all be fixed to 3V. And LDO also, just vout range is different from 1.2v to 3v, step is the same. If value is from 18 to 31, the voltage will also be fixed to 3v. Signed-off-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com Signed-off-by:
-
ChiYuan Huang authored
[ Upstream commit 2b6a761b ] Fix wrong mask for strobe-polarity-high. Signed-off-by:
-
Rander Wang authored
[ Upstream commit 33c85168 ] On TGL platform with max98373 codec the trigger start sequence is fe first, then codec component and sdw link is the last. Recently a delay was introduced in max98373 codec driver and this resulted to the start of sdw stream transmission was delayed and the data transmitted by fw can't be consumed by sdw controller, so xrun happened. Adding delay in trigger function is a bad idea. This patch enable spk pin in prepare function and disable it in hw_free to avoid xrun issue caused by delay in trigger. Fixes: 3a27875e ("ASoC: max98373: Added 30ms turn on/off time delay") BugLink: https://github.com/thesofproject/sof/issues/4066 Reviewed-by:
Bard Liao <bard.liao@intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by:
Rander Wang <rander.wang@intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210625205042.65181-2-pierre-louis.bossart@linux.intel.com Signed-off-by:
-
