- Dec 16, 2020
-
-
Alex Deucher authored
commit 578b6c48 upstream. To avoid a recently added warning: Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf (full crtc mask=0x7) WARNING: CPU: 3 PID: 439 at drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200 [drm] In this case the warning is harmless, but confusing to users. Fixes: 0df10823 ("drm: Validate encoder->possible_crtcs") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209123 Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bean Huo authored
commit 6246d7c9 upstream. The CMD13 polling is needed for commands with R1B responses. In commit a0d4c7eb ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response"), the intent was to introduce this for requests targeted to the RPMB partition. However, the condition to trigger the polling loop became wrong, leading to unnecessary polling. Let's fix the condition to avoid this. Fixes: a0d4c7eb ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response") Cc: stable@vger.kernel.org Reported-by:
Zhan Liu <zliua@micron.com> Signed-off-by:
Zhan Liu <zliua@micron.com> Signed-off-by:
Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Muhammad Husaini Zulkifli authored
commit a42a7ec9 upstream. The commit 16ada730 ("mmc: sdhci-of-arasan: Modify clock operations handling") introduced support for platform specific clock operations. Around the same point in time the commit 36c6aada ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay") was also merged. Unfortunate it was not really tested on top of the previously mentioned commit, which causes clock registration failures for Keem Bay SOC devices. Let's fix this, by properly declaring the clock operation for Keem Bay SOC devices. Fixes: 36c6aada ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay") Signed-off-by:
Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Reviewed-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20201118120120.24908-2-muhammad.husaini.zulkifli@intel.com Cc: stable@vger.kernel.org Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Coiby Xu authored
commit 47a00014 upstream. Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). Together with commit 06abe829 ("pinctrl: amd: fix incorrect way to disable debounce filter") and Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], this will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [2][3] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ 8dcb7a15 ("gpiolib: acpi: Take into account debounce settings") [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Signed-off-by:
Coiby Xu <coiby.xu@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Evan Green authored
commit cdd8fc2d upstream. GPIOs that attempt to use interrupts get thwarted with a message like: "pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because the HOSTSW_OWN offset is incorrect, so every GPIO looks like it's owned by ACPI. Fixes: e278dcb7 ("pinctrl: intel: Add Intel Jasper Lake pin controller support") Cc: stable@vger.kernel.org Signed-off-by:
Evan Green <evgreen@chromium.org> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chris Chiu authored
commit ce6520b0 upstream. The touchpad operates in Basic Mode by default in the Acer BIOS setup, but some Aspire/TravelMate models require the i8042 to be reset in order to be correctly detected. Signed-off-by:
Chris Chiu <chiu@endlessos.org> Link: https://lore.kernel.org/r/20201207071250.15021-1-chiu@endlessos.org Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dmitry Torokhov authored
commit 82e06090 upstream. We need to make sure we are not stomping on the control URB that was issued when opening the device when attempting to toggle buzzer. To do that we need to mark it as pending in cm109_open(). Reported-and-tested-by:
<syzbot+150f793ac5bc18eee150@syzkaller.appspotmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juergen Gross authored
commit ee32f323 upstream. Commit 9e2369c0 ("xen: add helpers to allocate unpopulated memory") introduced usage of ZONE_DEVICE memory for foreign memory mappings. Unfortunately this collides with using page->lru for Xen backend private page caches. Fix that by using page->zone_device_data instead. Cc: <stable@vger.kernel.org> # 5.9 Fixes: 9e2369c0 ("xen: add helpers to allocate unpopulated memory") Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovksy@oracle.com> Reviewed-by:
Jason Andryuk <jandryuk@gmail.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juergen Gross authored
commit ca33479c upstream. Instead of having similar helpers in multiple backend drivers use common helpers for caching pages allocated via gnttab_alloc_pages(). Make use of those helpers in blkback and scsiback. Cc: <stable@vger.kernel.org> # 5.9 Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovksy@oracle.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Libo Chen authored
commit 271e0c9d upstream. This issue was first noticed when I was testing different kernels on Oracle Linux 8 which as Fedora 30+ adopts BLS as default. Even though a kernel entry was added successfully and the index of that kernel entry was retrieved correctly, ktest still wouldn't reboot the system into user-specified kernel. The bug was spotted in subroutine reboot_to where the if-statement never checks for REBOOT_TYPE "grub2bls", therefore the desired entry will not be set for the next boot. Add a check for "grub2bls" so that $grub_reboot $grub_number can be run before a reboot if REBOOT_TYPE is "grub2bls" then we can boot to the correct kernel. Link: https://lkml.kernel.org/r/20201121021243.1532477-1-libo.chen@oracle.com Cc: stable@vger.kernel.org Fixes: ac246645 ("ktest: introduce grub2bls REBOOT_TYPE option") Signed-off-by:
Libo Chen <libo.chen@oracle.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
yong mao authored
commit 903a72ec upstream. The SDIO recheck fix is required for more of the supported variants. Let's add it to those that needs it. Reported-by:
Fabien Parent <fparent@baylibre.com> Reported-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com> Signed-off-by:
Yong Mao <yong.mao@mediatek.com> Link: https://lore.kernel.org/r/20201119030237.9414-1-yong.mao@mediatek.com Fixes: 9e2582e5 ("mmc: mediatek: fix SDIO irq issue") Cc: stable@vger.kernel.org [Ulf: Clarified commitmsg ] Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wenbin Mei authored
commit c0a2074a upstream. Before we got these errors on MT8192 platform: [ 59.153891] Restarting tasks ... [ 59.154540] done. [ 59.159175] PM: suspend exit [ 59.218724] mtk-msdc 11f60000.mmc: phase: [map:fffffffe] [maxlen:31] [final:16] [ 119.776083] mmc0: cqhci: timeout for tag 9 [ 119.780196] mmc0: cqhci: ============ CQHCI REGISTER DUMP =========== [ 119.786709] mmc0: cqhci: Caps: 0x100020b6 | Version: 0x00000510 [ 119.793225] mmc0: cqhci: Config: 0x00000101 | Control: 0x00000000 [ 119.799706] mmc0: cqhci: Int stat: 0x00000000 | Int enab: 0x00000000 [ 119.806177] mmc0: cqhci: Int sig: 0x00000000 | Int Coal: 0x00000000 [ 119.812670] mmc0: cqhci: TDL base: 0x00000000 | TDL up32: 0x00000000 [ 119.819149] mmc0: cqhci: Doorbell: 0x003ffc00 | TCN: 0x00000200 [ 119.825656] mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000 [ 119.832155] mmc0: cqhci: Task clr: 0x00000000 | SSC1: 0x00001000 [ 119.838627] mmc0: cqhci: SSC2: 0x00000000 | DCMD rsp: 0x00000000 [ 119.845174] mmc0: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x0000891c [ 119.851654] mmc0: cqhci: Resp idx: 0x00000000 | Resp arg: 0x00000000 [ 119.865773] mmc0: cqhci: : =========================================== [ 119.872358] mmc0: running CQE recovery From these logs, we found TDL base was back to the default value. After suspend, the mmc host is powered off by HW, and bring CQE register to the default value, so we add system suspend/resume interface, then bring CQE to deactivated state before suspend, it will be enabled by CQE first request after resume. Signed-off-by:
Wenbin Mei <wenbin.mei@mediatek.com> Link: https://lore.kernel.org/r/20201118063405.24906-1-wenbin.mei@mediatek.com Fixes: 88bd652b ("mmc: mediatek: command queue support") Cc: stable@vger.kernel.org [Ulf: Renamed functions] Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans Verkuil authored
commit 45ba1c0b upstream. Starting with firmware version 10 the GET/SET_HDMI_VERSION message was removed and GET/SET_AUTO_POWER_ON was added. The removal of GET/SET_HDMI_VERSION caused the probe of the Pulse-Eight to fail. Add a version check to handle this gracefully. Also show (but do not set) the Auto Power On value. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by:
Maxime Ripard <mripard@kernel.org> Tested-by:
Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans Verkuil authored
commit 024e01de upstream. Commit 601282d6 ("media: pulse8-cec: use adap_free callback") used the adap_free callback to clean up on disconnect. What I forgot was that in the probe it will call cec_delete_adapter() followed by kfree(pulse8) if an error occurs. But by using the adap_free callback, cec_delete_adapter() is already freeing the pulse8 struct. This wasn't noticed since normally the probe works fine, but Pulse-Eight published a new firmware version that caused a probe error, so now it hits this bug. This affects firmware version 12, but probably any version >= 10. Commit aa9eda76 ("media: pulse8-cec: close serio in disconnect, not adap_free") made this worse by adding the line 'pulse8->serio = NULL' right after the call to cec_unregister_adapter in the disconnect() function. Unfortunately, cec_unregister_adapter will typically call cec_delete_adapter (unless a filehandle to the cec device is still open), which frees the pulse8 struct. So now it will also crash on a simple unplug of the Pulse-Eight device. With this fix both the unplug issue and a probe() error situation are handled correctly again. It will still fail to probe() with a v12 firmware, that's something to look at separately. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by:
Maxime Ripard <mripard@kernel.org> Tested-by:
Maxime Ripard <mripard@kernel.org> Fixes: aa9eda76 ("media: pulse8-cec: close serio in disconnect, not adap_free") Fixes: 601282d6 ("media: pulse8-cec: use adap_free callback") Cc: <stable@vger.kernel.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Zijlstra authored
[ Upstream commit 4d916140 ] Because CONFIG_ soup. Fixes: 6e1d2bc6 ("intel_idle: Fix intel_idle() vs tracing") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20201130115402.GO3040@hirez.programming.kicks-ass.net Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Heiko Carstens authored
[ Upstream commit b1cae1f8 ] With commit 58c644ba ("sched/idle: Fix arch_cpu_idle() vs tracing") common code calls arch_cpu_idle() with a lockdep state that tells irqs are on. This doesn't work very well for s390: psw_idle() will enable interrupts to wait for an interrupt. As soon as an interrupt occurs the interrupt handler will verify if the old context was psw_idle(). If that is the case the interrupt enablement bits in the old program status word will be cleared. A subsequent test in both the external as well as the io interrupt handler checks if in the old context interrupts were enabled. Due to the above patching of the old program status word it is assumed the old context had interrupts disabled, and therefore a call to TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in turn makes lockdep incorrectly "think" that interrupts are enabled within the interrupt handler. Fix this by unconditionally calling TRACE_IRQS_OFF when entering interrupt handlers. Also call unconditionally TRACE_IRQS_ON when leaving interrupts handlers. This leaves the special psw_idle() case, which now returns with interrupts disabled, but has an "irqs on" lockdep state. So callers of psw_idle() must adjust the state on their own, if required. This is currently only __udelay_disabled(). Fixes: 58c644ba ("sched/idle: Fix arch_cpu_idle() vs tracing") Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Pankaj Sharma authored
[ Upstream commit 5c7d55bd ] Add support for mcan bit timing and control mode according to bosch mcan IP version 3.3.0. The mcan version read from the Core Release field of CREL register would be 33. Accordingly the properties are to be set for mcan v3.3.0 Signed-off-by:
Pankaj Sharma <pankj.sharma@samsung.com> Link: https://lore.kernel.org/r/1606366302-5520-1-git-send-email-pankj.sharma@samsung.com Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
[ Upstream commit c9aa1280 ] Add touchscreen info for the Irbis TW118 tablet. Reported-and-tested-by:
russianneuromancer <russianneuromancer@ya.ru> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201124110454.114286-1-hdegoede@redhat.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
[ Upstream commit 0f511edc ] Add touchscreen info for the Predia Basic tablet. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201015194949.50566-1-hdegoede@redhat.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Max Verevkin authored
[ Upstream commit 8b205d3e ] The Pavilion 13 x360 PC has a chassis-type which does not indicate it is a convertible, while it is actually a convertible. Add it to the dmi_switches_allow_list. Signed-off-by:
Max Verevkin <me@maxverevkin.tk> Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Timo Witte authored
[ Upstream commit 9e7a005a ] Got a dmesg message on my AMD Renoir based Acer laptop: "acer_wmi: Unknown key number - 0x84" when toggling keyboard background light Signed-off-by:
Timo Witte <timo.witte@gmail.com> Reviewed-by:
"Lee, Chun-Yi" <jlee@suse.com> Link: https://lore.kernel.org/r/20200804001423.36778-1-timo.witte@gmail.com Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Matthias Maier authored
[ Upstream commit 80a8c318 ] This commit enables dual fan control for the following new Lenovo models: P15, P15v. Signed-off-by:
Matthias Maier <tamiko@43-1.org> Link: https://lore.kernel.org/r/20201126000416.2459645-2-tamiko-ibm-acpi-devel@43-1.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
[ Upstream commit c986a702 ] The Thinkpad Yoga 11e 4th gen with the N3450 / Celeron CPU only has one battery which is named BAT1 instead of the expected BAT0, add a quirk for this. This fixes not being able to set the charging tresholds on this model; and this alsoe fixes the following errors in dmesg: ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as error thinkpad_acpi: Error probing battery 2 battery: extension failed to load: ThinkPad Battery Extension battery: extension unregistered: ThinkPad Battery Extension Note that the added quirk is for the "R0K" BIOS versions which are used on the Thinkpad Yoga 11e 4th gen's with a Celeron CPU, there is a separate "R0L" BIOS for the i3/i5 based versions. This may also need the same quirk, but if that really is necessary is unknown. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201109103550.16265-1-hdegoede@redhat.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
[ Upstream commit f2eae188 ] The Yoga 11e series has 2 accelerometers described by a BOSC0200 ACPI node. This setup relies on a Windows service which reads both accelerometers and then calculates the angle between the 2 halves to determine laptop / tent / tablet mode and then reports the calculated mode back to the EC by calling special ACPI methods on the BOSC0200 node. The bmc150 iio driver does not support this (it involves double calculations requiring sqrt and arccos so this really needs to be done in userspace), as a result of this on the Yoga 11e the thinkpad_acpi code always reports SW_TABLET_MODE=0, starting with GNOME 3.38 reporting SW_TABLET_MODE=0 causes GNOME to: 1. Not show the onscreen keyboard when a text-input field is focussed with the touchscreen. 2. Disable accelerometer based auto display-rotation. This makes sense when in laptop-mode but not when in tablet-mode. But since for the Yoga 11e the thinkpad_acpi code always reports SW_TABLET_MODE=0, GNOME does not know when the device is in tablet-mode. Stop reporting the broken (always 0) SW_TABLET_MODE on Yoga 11e models to fix this. Note there are plans for userspace to support 360 degree hinges style 2-in-1s with 2 accelerometers and figure out the mode by itself, see: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216 Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201106140130.46820-1-hdegoede@redhat.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Iakov 'Jake' Kirilenko authored
[ Upstream commit 15d89c9f ] Tested on my P1 gen3, works fine with `thinkfan`. Since thinkpad_acpi fan control is off by default, it is safe to add 2nd fan control for brave overclockers Signed-off-by:
Iakov 'Jake' Kirilenko <jake.kirilenko@gmail.com> Link: https://lore.kernel.org/r/20201105152556.34073-1-jake.kirilenko@gmail.com Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jon Hunter authored
[ Upstream commit fb319496 ] Commit ff4c371d ("arm64: defconfig: Build ADMA and ACONNECT driver") enable the Tegra ADMA and ACONNECT drivers and this is causing resume from system suspend to fail on Jetson TX2. Resume is failing because the ACONNECT driver is being resumed before the BPMP driver, and the ACONNECT driver is attempting to power on a power-domain that is provided by the BPMP. While a proper fix for the resume sequencing problem is identified, disable the ACONNECT for Jetson TX2 temporarily to avoid breaking system suspend. Please note that ACONNECT driver is used by the Audio Processing Engine (APE) on Tegra, but because there is no mainline support for APE on Jetson TX2 currently, disabling the ACONNECT does not disable any useful feature at the moment. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Peter Zijlstra authored
[ Upstream commit 6e1d2bc6 ] cpuidle->enter() callbacks should not call into tracing because RCU has already been disabled. Instead of doing the broadcast thing itself, simply advertise to the cpuidle core that those states stop the timer. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lkml.kernel.org/r/20201123143510.GR3021@hirez.programming.kicks-ass.net Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Peter Zijlstra authored
[ Upstream commit 58c644ba ] We call arch_cpu_idle() with RCU disabled, but then use local_irq_{en,dis}able(), which invokes tracing, which relies on RCU. Switch all arch_cpu_idle() implementations to use raw_local_irq_{en,dis}able() and carefully manage the lockdep,rcu,tracing state like we do in entry. (XXX: we really should change arch_cpu_idle() to not return with interrupts enabled) Reported-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Tested-by:
Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/20201120114925.594122626@infradead.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hao Si authored
[ Upstream commit 2663b338 ] The local variable 'cpumask_t mask' is in the stack memory, and its address is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'. But the memory area where this variable is located is at risk of being modified. During LTP testing, the following error was generated: Unable to handle kernel paging request at virtual address ffff000012e9b790 Mem abort info: ESR = 0x96000007 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000007 CM = 0, WnR = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07 [ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003, pmd=00000027b6d61003, pte=0000000000000000 Internal error: Oops: 96000007 [#1] PREEMPT SMP Modules linked in: xt_conntrack Process read_all (pid: 20171, stack limit = 0x0000000044ea4095) CPU: 14 PID: 20171 Comm: read_all Tainted: G B W Hardware name: NXP Layerscape LX2160ARDB (DT) pstate: 80000085 (Nzcv daIf -PAN -UAO) pc : irq_affinity_hint_proc_show+0x54/0xb0 lr : irq_affinity_hint_proc_show+0x4c/0xb0 sp : ffff00001138bc10 x29: ffff00001138bc10 x28: 0000ffffd131d1e0 x27: 00000000007000c0 x26: ffff8025b9480dc0 x25: ffff8025b9480da8 x24: 00000000000003ff x23: ffff8027334f8300 x22: ffff80272e97d000 x21: ffff80272e97d0b0 x20: ffff8025b9480d80 x19: ffff000009a49000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000040 x11: 0000000000000000 x10: ffff802735b79b88 x9 : 0000000000000000 x8 : 0000000000000000 x7 : ffff000009a49848 x6 : 0000000000000003 x5 : 0000000000000000 x4 : ffff000008157d6c x3 : ffff00001138bc10 x2 : ffff000012e9b790 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: irq_affinity_hint_proc_show+0x54/0xb0 seq_read+0x1b0/0x440 proc_reg_read+0x80/0xd8 __vfs_read+0x60/0x178 vfs_read+0x94/0x150 ksys_read+0x74/0xf0 __arm64_sys_read+0x24/0x30 el0_svc_common.constprop.0+0xd8/0x1a0 el0_svc_handler+0x34/0x88 el0_svc+0x10/0x14 Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041) ---[ end trace b495bdcb0b3b732b ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15 Kernel Offset: disabled CPU features: 0x0,21006008 Memory Limit: none ---[ end Kernel panic - not syncing: Fatal exception ]--- Fix it by using 'cpumask_of(cpu)' to get the cpumask. Signed-off-by:
Hao Si <si.hao@zte.com.cn> Signed-off-by:
Lin Chen <chen.lin5@zte.com.cn> Signed-off-by:
Yi Wang <wang.yi59@zte.com.cn> Signed-off-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Filipe Manana authored
[ Upstream commit a855fbe6 ] When running test case btrfs/017 from fstests, lockdep reported the following splat: [ 1297.067385] ====================================================== [ 1297.067708] WARNING: possible circular locking dependency detected [ 1297.068022] 5.10.0-rc4-btrfs-next-73 #1 Not tainted [ 1297.068322] ------------------------------------------------------ [ 1297.068629] btrfs/189080 is trying to acquire lock: [ 1297.068929] ffff9f2725731690 (sb_internal#2){.+.+}-{0:0}, at: btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.069274] but task is already holding lock: [ 1297.069868] ffff9f2702b61a08 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}, at: btrfs_quota_enable+0x3b/0xa70 [btrfs] [ 1297.070219] which lock already depends on the new lock. [ 1297.071131] the existing dependency chain (in reverse order) is: [ 1297.071721] -> #1 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}: [ 1297.072375] lock_acquire+0xd8/0x490 [ 1297.072710] __mutex_lock+0xa3/0xb30 [ 1297.073061] btrfs_qgroup_inherit+0x59/0x6a0 [btrfs] [ 1297.073421] create_subvol+0x194/0x990 [btrfs] [ 1297.073780] btrfs_mksubvol+0x3fb/0x4a0 [btrfs] [ 1297.074133] __btrfs_ioctl_snap_create+0x119/0x1a0 [btrfs] [ 1297.074498] btrfs_ioctl_snap_create+0x58/0x80 [btrfs] [ 1297.074872] btrfs_ioctl+0x1a90/0x36f0 [btrfs] [ 1297.075245] __x64_sys_ioctl+0x83/0xb0 [ 1297.075617] do_syscall_64+0x33/0x80 [ 1297.075993] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1297.076380] -> #0 (sb_internal#2){.+.+}-{0:0}: [ 1297.077166] check_prev_add+0x91/0xc60 [ 1297.077572] __lock_acquire+0x1740/0x3110 [ 1297.077984] lock_acquire+0xd8/0x490 [ 1297.078411] start_transaction+0x3c5/0x760 [btrfs] [ 1297.078853] btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.079323] btrfs_ioctl+0x2c60/0x36f0 [btrfs] [ 1297.079789] __x64_sys_ioctl+0x83/0xb0 [ 1297.080232] do_syscall_64+0x33/0x80 [ 1297.080680] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1297.081139] other info that might help us debug this: [ 1297.082536] Possible unsafe locking scenario: [ 1297.083510] CPU0 CPU1 [ 1297.084005] ---- ---- [ 1297.084500] lock(&fs_info->qgroup_ioctl_lock); [ 1297.084994] lock(sb_internal#2); [ 1297.085485] lock(&fs_info->qgroup_ioctl_lock); [ 1297.085974] lock(sb_internal#2); [ 1297.086454] *** DEADLOCK *** [ 1297.087880] 3 locks held by btrfs/189080: [ 1297.088324] #0: ffff9f2725731470 (sb_writers#14){.+.+}-{0:0}, at: btrfs_ioctl+0xa73/0x36f0 [btrfs] [ 1297.088799] #1: ffff9f2702b60cc0 (&fs_info->subvol_sem){++++}-{3:3}, at: btrfs_ioctl+0x1f4d/0x36f0 [btrfs] [ 1297.089284] #2: ffff9f2702b61a08 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}, at: btrfs_quota_enable+0x3b/0xa70 [btrfs] [ 1297.089771] stack backtrace: [ 1297.090662] CPU: 5 PID: 189080 Comm: btrfs Not tainted 5.10.0-rc4-btrfs-next-73 #1 [ 1297.091132] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 1297.092123] Call Trace: [ 1297.092629] dump_stack+0x8d/0xb5 [ 1297.093115] check_noncircular+0xff/0x110 [ 1297.093596] check_prev_add+0x91/0xc60 [ 1297.094076] ? kvm_clock_read+0x14/0x30 [ 1297.094553] ? kvm_sched_clock_read+0x5/0x10 [ 1297.095029] __lock_acquire+0x1740/0x3110 [ 1297.095510] lock_acquire+0xd8/0x490 [ 1297.095993] ? btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.096476] start_transaction+0x3c5/0x760 [btrfs] [ 1297.096962] ? btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.097451] btrfs_quota_enable+0xaf/0xa70 [btrfs] [ 1297.097941] ? btrfs_ioctl+0x1f4d/0x36f0 [btrfs] [ 1297.098429] btrfs_ioctl+0x2c60/0x36f0 [btrfs] [ 1297.098904] ? do_user_addr_fault+0x20c/0x430 [ 1297.099382] ? kvm_clock_read+0x14/0x30 [ 1297.099854] ? kvm_sched_clock_read+0x5/0x10 [ 1297.100328] ? sched_clock+0x5/0x10 [ 1297.100801] ? sched_clock_cpu+0x12/0x180 [ 1297.101272] ? __x64_sys_ioctl+0x83/0xb0 [ 1297.101739] __x64_sys_ioctl+0x83/0xb0 [ 1297.102207] do_syscall_64+0x33/0x80 [ 1297.102673] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1297.103148] RIP: 0033:0x7f773ff65d87 This is because during the quota enable ioctl we lock first the mutex qgroup_ioctl_lock and then start a transaction, and starting a transaction acquires a fs freeze semaphore (at the VFS level). However, every other code path, except for the quota disable ioctl path, we do the opposite: we start a transaction and then lock the mutex. So fix this by making the quota enable and disable paths to start the transaction without having the mutex locked, and then, after starting the transaction, lock the mutex and check if some other task already enabled or disabled the quotas, bailing with success if that was the case. Signed-off-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Filipe Manana authored
[ Upstream commit 7aa6d359 ] When adding or removing a qgroup relation we are doing a GFP_KERNEL allocation which is not safe because we are holding a transaction handle open and that can make us deadlock if the allocator needs to recurse into the filesystem. So just surround those calls with a nofs context. Signed-off-by:
Filipe Manana <fdmanana@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Oded Gabbay authored
[ Upstream commit 652b4445 ] There is missing statement and missing "break;" in the ECC handling code in gaudi.c This will cause a wrong behavior upon certain ECC interrupts. Signed-off-by:
Oded Gabbay <ogabbay@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
John Stultz authored
[ Upstream commit 72b55c96 ] Robin Murphy pointed out that if the arm-smmu driver probes before the qcom_scm driver, we may call qcom_scm_qsmmu500_wait_safe_toggle() before the __scm is initialized. Now, getting this to happen is a bit contrived, as in my efforts it required enabling asynchronous probing for both drivers, moving the firmware dts node to the end of the dtsi file, as well as forcing a long delay in the qcom_scm_probe function. With those tweaks we ran into the following crash: [ 2.631040] arm-smmu 15000000.iommu: Stage-1: 48-bit VA -> 48-bit IPA [ 2.633372] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... [ 2.633402] [0000000000000000] user address but active_mm is swapper [ 2.633409] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 2.633415] Modules linked in: [ 2.633427] CPU: 5 PID: 117 Comm: kworker/u16:2 Tainted: G W 5.10.0-rc1-mainline-00025-g272a618fc36-dirty #3971 [ 2.633430] Hardware name: Thundercomm Dragonboard 845c (DT) [ 2.633448] Workqueue: events_unbound async_run_entry_fn [ 2.633456] pstate: 80c00005 (Nzcv daif +PAN +UAO -TCO BTYPE=--) [ 2.633465] pc : qcom_scm_qsmmu500_wait_safe_toggle+0x78/0xb0 [ 2.633473] lr : qcom_smmu500_reset+0x58/0x78 [ 2.633476] sp : ffffffc0105a3b60 ... [ 2.633567] Call trace: [ 2.633572] qcom_scm_qsmmu500_wait_safe_toggle+0x78/0xb0 [ 2.633576] qcom_smmu500_reset+0x58/0x78 [ 2.633581] arm_smmu_device_reset+0x194/0x270 [ 2.633585] arm_smmu_device_probe+0xc94/0xeb8 [ 2.633592] platform_drv_probe+0x58/0xa8 [ 2.633597] really_probe+0xec/0x398 [ 2.633601] driver_probe_device+0x5c/0xb8 [ 2.633606] __driver_attach_async_helper+0x64/0x88 [ 2.633610] async_run_entry_fn+0x4c/0x118 [ 2.633617] process_one_work+0x20c/0x4b0 [ 2.633621] worker_thread+0x48/0x460 [ 2.633628] kthread+0x14c/0x158 [ 2.633634] ret_from_fork+0x10/0x18 [ 2.633642] Code: a9034fa0 d0007f73 29107fa0 91342273 (f9400020) To avoid this, this patch adds a check on qcom_scm_is_available() in the qcom_smmu_impl_init() function, returning -EPROBE_DEFER if its not ready. This allows the driver to try to probe again later after qcom_scm has finished probing. Reported-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Andy Gross <agross@kernel.org> Cc: Maulik Shah <mkshah@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Lina Iyer <ilina@codeaurora.org> Cc: iommu@lists.linux-foundation.org Cc: linux-arm-msm <linux-arm-msm@vger.kernel.org> Link: https://lore.kernel.org/r/20201112220520.48159-1-john.stultz@linaro.org Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ran Wang authored
[ Upstream commit 71d80563 ] Given the case that bootloader(such as UEFI)'s FSPI driver might not handle all interrupts before loading kernel, those legacy interrupts would assert immidiately once kernel's FSPI driver enable them. Further, if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler() would call complete(&f->c) to notify others. However, f->c might not be initialized yet at that time, then cause kernel panic. Of cause, we should fix this issue within bootloader. But it would be better to have this pacth to make dirver more robust (by clearing all interrupt status bits before enabling interrupts). Suggested-by:
Han Xu <han.xu@nxp.com> Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Krzysztof Kozlowski authored
[ Upstream commit e2d3d2e9 ] The Exynos DRM uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X): /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent' Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Xu Qiang authored
[ Upstream commit 74cde1a5 ] On systems without HW-based collections (i.e. anything except GIC-500), we rely on firmware to perform the ITS save/restore. This doesn't really work, as although FW can properly save everything, it cannot fully restore the state of the command queue (the read-side is reset to the head of the queue). This results in the ITS consuming previously processed commands, potentially corrupting the state. Instead, let's always save the ITS state on suspend, disabling it in the process, and restore the full state on resume. This saves us from broken FW as long as it doesn't enable the ITS by itself (for which we can't do anything). This amounts to simply dropping the ITS_FLAGS_SAVE_SUSPEND_STATE. Signed-off-by:
Xu Qiang <xuqiang36@huawei.com> [maz: added warning on resume, rewrote commit message] Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201107104226.14282-1-xuqiang36@huawei.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lijun Pan authored
[ Upstream commit 855a631a ] Sometimes it takes longer than 5 seconds (watchdog timeout) to complete failover, migration, and other resets. In stead of scheduling another timeout reset, we wait for the current one to complete. Suggested-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Lijun Pan <ljp@linux.ibm.com> Reviewed-by:
Dany Madden <drt@linux.ibm.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Georgi Djakov authored
[ Upstream commit 7ab1e911 ] The following errors are noticed during boot on a QCS404 board: [ 2.926647] qcom_icc_rpm_smd_send mas 6 error -6 [ 2.934573] qcom_icc_rpm_smd_send mas 8 error -6 These errors show when we try to configure the GPU and display nodes. Since these particular nodes aren't supported on RPM and are purely local, we should just change their mas_rpm_id to -1 to avoid any requests being sent for these master IDs. Reviewed-by:
Mike Tipton <mdtipton@codeaurora.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20201118111044.26056-1-georgi.djakov@linaro.org Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Georgi Djakov authored
[ Upstream commit c497f932 ] Some nodes are incorrectly marked as RPM-controlled (they have RPM master and slave ids assigned), but are actually controlled by the application CPU instead. The RPM complains when we send requests for resources that it can't control. Let's fix this by replacing the IDs, with the default "-1" in which case no requests are sent. Reviewed-by:
Mike Tipton <mdtipton@codeaurora.org> Link: https://lore.kernel.org/r/20201112105140.10092-1-georgi.djakov@linaro.org Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Can Guo authored
[ Upstream commit 73cc291c ] If someone plays with the UFS clk scaling devfreq governor through sysfs, ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE. This can lead to unexpected error. We cannot just protect it by calling pm_runtime_get_sync() because that may cause a race condition since HBA runtime suspend ops need to suspend clk scaling. To fix this call pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if HBA is runtime ACTIVE, otherwise just bail. governor_store devfreq_performance_handler update_devfreq devfreq_set_target ufshcd_devfreq_target ufshcd_devfreq_scale Link: https://lore.kernel.org/r/1600758548-28576-1-git-send-email-cang@codeaurora.org Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-