Luke D. Jones [Thu, 15 Sep 2022 08:09:20 +0000 (20:09 +1200)]
ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack
commit
bc2c23549ccd7105eb6ff0d4f0ac519285628673 upstream.
Fixes up the pincfg for ASUS ROG Strix G15 (G533Z) headphone combo jack
[ Fixed the position in the quirk table by tiwai ]
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220915080921.35563-3-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luke D. Jones [Thu, 15 Sep 2022 08:09:19 +0000 (20:09 +1200)]
ALSA: hda/realtek: Add pincfg for ASUS G513 HP jack
commit
c611e659044168e7abcbae8ba1ea833521498fbb upstream.
Fixes up the pincfg for ASUS ROG Strix G513 headphone and mic combo jack
[ Fixed the position in the quirk table by tiwai ]
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220915080921.35563-2-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 15 Sep 2022 15:47:24 +0000 (17:47 +0200)]
ALSA: hda/realtek: Re-arrange quirk table entries
commit
b16c8f229a58eaddfc58aab447253464abd3c85e upstream.
A few entries have been mistakenly inserted in wrong positions without
considering the SSID ordering. Place them at right positions.
Fixes:
b7557267c233 ("ALSA: hda/realtek: Add quirk for ASUS GA402")
Fixes:
94db9cc8f8fa ("ALSA: hda/realtek: Add quirk for ASUS GU603")
Fixes:
739d0959fbed ("ALSA: hda: Add quirk for ASUS Flow x13")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220915154724.31634-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Callum Osmotherly [Wed, 14 Sep 2022 09:14:00 +0000 (18:44 +0930)]
ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5570 laptop
commit
bdc9b7396f7d4d6533e70fd8d5472f505b5ef58f upstream.
The Dell Precision 5570 uses the same 4-speakers-on-ALC289 just like the
previous Precision 5560. I replicated that patch onto this one, and can
confirm that the audio is much better (the woofers are now working);
I've tested it on my Dell Precision 5570.
Signed-off-by: Callum Osmotherly <callum.osmotherly@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/YyGbWM5wEoFMbW2v@piranha
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
huangwenhui [Tue, 13 Sep 2022 05:46:22 +0000 (13:46 +0800)]
ALSA: hda/realtek: Add quirk for Huawei WRT-WX9
commit
cbcdf8c4d35cd74aee8581eb2f0453e0ecab7b05 upstream.
Fixes headphone and headset microphone detection on Huawei WRT-WX9.
Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220913054622.15979-1-huangwenhuia@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kai Vehmanen [Mon, 12 Sep 2022 18:37:16 +0000 (21:37 +0300)]
ALSA: hda: add Intel 5 Series / 3400 PCI DID
commit
4d40ceef4745536289012670103c59264e0fb3ec upstream.
Handle 0x3b57 variant with same AZX_DCAPS_INTEL_PCH_NOPM
capabilities as 0x3b56. In practise this allow use of HDMI/DP
display audio via i915.
BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/2751
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220912183716.2126312-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohan Kumar [Tue, 13 Sep 2022 05:36:41 +0000 (11:06 +0530)]
ALSA: hda/tegra: set depop delay for tegra
commit
3c4d8c24fb6c44f426e447b04800b0ed61a7b5ae upstream.
Reduce the suspend time by setting depop delay to 10ms for
tegra.
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220913053641.23299-1-mkumard@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 19 Sep 2022 12:35:16 +0000 (14:35 +0200)]
ALSA: core: Fix double-free at snd_card_new()
commit
c3afa2a402d1ecefa59f88d55d9e765f52f75bd9 upstream.
During the code change to add the support for devres-managed card
instance, we put an explicit kfree(card) call at the error path in
snd_card_new(). This is needed for the early error path before the
card is initialized with the device, but is rather superfluous and
causes a double-free at the error path after the card instance is
initialized, as the destructor of the card object already contains a
kfree() call.
This patch fixes the double-free situation by removing the superfluous
kfree(). Meanwhile we need to call kfree() explicitly for the early
error path, so it's added there instead.
Fixes:
e8ad415b7a55 ("ALSA: core: Add managed card creation")
Reported-by: Rondreis <linhaoguo86@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAB7eexL1zBnB636hwS27d-LdPYZ_R1-5fJS_h=ZbCWYU=UPWJg@mail.gmail.com
Link: https://lore.kernel.org/r/20220919123516.28222-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 20 Sep 2022 11:39:29 +0000 (13:39 +0200)]
Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare"
commit
79764ec772bc1346441ae1c4b1f3bd1991d634e8 upstream.
This reverts commit
ff878b408a03bef5d610b7e2302702e16a53636e.
Unfortunately the recent fix seems bringing another regressions with
PulseAudio / pipewire, at least for Steinberg and MOTU devices.
As a temporary solution, do a straight revert. The issue for Android
will be revisited again later by another different fix (if any).
Fixes:
ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jerry meng [Mon, 5 Sep 2022 06:35:33 +0000 (14:35 +0800)]
USB: serial: option: add Quectel RM520N
commit
d640c4cb8f2f933c0ca896541f9de7fb1ae245f4 upstream.
add support for Quectel RM520N which is based on Qualcomm SDX62 chip.
0x0801: DIAG + NMEA + AT + MODEM + RMNET
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0801 Rev= 5.04
S: Manufacturer=Quectel
S: Product=RM520N-GL
S: SerialNumber=
384af524
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: jerry meng <jerry-meng@foxmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carl Yin(殷张成) [Fri, 2 Sep 2022 09:49:43 +0000 (09:49 +0000)]
USB: serial: option: add Quectel BG95 0x0203 composition
commit
f8f67eff6847f9b8d753fa029723bcc54296055a upstream.
Add support for the following Quectel BG95 composition:
0x0203: Diag + GNSS + Modem + ECM
usb-devices output:
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0203 Rev= 0.00
S: Manufacturer=Quectel, Incorporated
S: Product=Quectel LPWA Module
S: SerialNumber=
71d3a21b
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 3 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Carl Yin <carl.yin@quectel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Thu, 1 Sep 2022 14:36:34 +0000 (10:36 -0400)]
USB: core: Fix RST error in hub.c
commit
766a96dc558385be735a370db867e302c8f22153 upstream.
A recent commit added an invalid RST expression to a kerneldoc comment
in hub.c. The fix is trivial.
Fixes:
9c6d778800b9 ("USB: core: Prevent nested device-reset calls")
Cc: <stable@vger.kernel.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/YxDDcsLtRZ7c20pq@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phil Auld [Tue, 6 Sep 2022 20:35:42 +0000 (16:35 -0400)]
drivers/base: Fix unsigned comparison to -1 in CPUMAP_FILE_MAX_BYTES
commit
d7f06bdd6ee87fbefa05af5f57361d85e7715b11 upstream.
As PAGE_SIZE is unsigned long, -1 > PAGE_SIZE when NR_CPUS <= 3.
This leads to very large file sizes:
topology$ ls -l
total 0
-r--r--r-- 1 root root
18446744073709551615 Sep 5 11:59 core_cpus
-r--r--r-- 1 root root 4096 Sep 5 11:59 core_cpus_list
-r--r--r-- 1 root root 4096 Sep 5 10:58 core_id
-r--r--r-- 1 root root
18446744073709551615 Sep 5 10:10 core_siblings
-r--r--r-- 1 root root 4096 Sep 5 11:59 core_siblings_list
-r--r--r-- 1 root root
18446744073709551615 Sep 5 11:59 die_cpus
-r--r--r-- 1 root root 4096 Sep 5 11:59 die_cpus_list
-r--r--r-- 1 root root 4096 Sep 5 11:59 die_id
-r--r--r-- 1 root root
18446744073709551615 Sep 5 11:59 package_cpus
-r--r--r-- 1 root root 4096 Sep 5 11:59 package_cpus_list
-r--r--r-- 1 root root 4096 Sep 5 10:58 physical_package_id
-r--r--r-- 1 root root
18446744073709551615 Sep 5 10:10 thread_siblings
-r--r--r-- 1 root root 4096 Sep 5 11:59 thread_siblings_list
Adjust the inequality to catch the case when NR_CPUS is configured
to a small value.
Fixes:
7ee951acd31a ("drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist")
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Yury Norov <yury.norov@gmail.com>
Cc: stable@vger.kernel.org
Cc: feng xiangjun <fengxj325@gmail.com>
Reported-by: feng xiangjun <fengxj325@gmail.com>
Signed-off-by: Phil Auld <pauld@redhat.com>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Link: https://lore.kernel.org/r/20220906203542.1796629-1-pauld@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 2 Sep 2022 07:10:08 +0000 (09:10 +0200)]
Revert "usb: gadget: udc-xilinx: replace memcpy with memcpy_toio"
[ Upstream commit
fe0a2ac7c627b064c479ad0c3b25e531d342e048 ]
This reverts commit
8cb339f1c1f04baede9d54c1e40ac96247a6393b as it
throws up a bunch of sparse warnings as reported by the kernel test
robot.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202209020044.CX2PfZzM-lkp@intel.com
Fixes:
8cb339f1c1f0 ("usb: gadget: udc-xilinx: replace memcpy with memcpy_toio")
Cc: stable@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Piyush Mehta <piyush.mehta@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Wed, 31 Aug 2022 08:34:25 +0000 (10:34 +0200)]
Revert "usb: add quirks for Lenovo OneLink+ Dock"
[ Upstream commit
58bfe7d8e31014d7ce246788df99c56e3cfe6c68 ]
This reverts commit
3d5f70949f1b1168fbb17d06eb5c57e984c56c58.
The quirk does not work properly, more work is needed to determine what
should be done here.
Reported-by: Oliver Neukum <oneukum@suse.com>
Cc: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Fixes:
3d5f70949f1b ("usb: add quirks for Lenovo OneLink+ Dock")
Link: https://lore.kernel.org/r/9a17ea86-079f-510d-e919-01bc53a6d09f@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Piyush Mehta [Wed, 24 Aug 2022 07:12:53 +0000 (12:42 +0530)]
usb: gadget: udc-xilinx: replace memcpy with memcpy_toio
[ Upstream commit
8cb339f1c1f04baede9d54c1e40ac96247a6393b ]
For ARM processor, unaligned access to device memory is not allowed.
Method memcpy does not take care of alignment.
USB detection failure with the unaligned address of memory access, with
below kernel crash. To fix the unaligned address the kernel panic issue,
replace memcpy with memcpy_toio method.
Kernel crash:
Unable to handle kernel paging request at virtual address
ffff80000c05008a
Mem abort info:
ESR = 0x96000061
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x21: alignment fault
Data abort info:
ISV = 0, ISS = 0x00000061
CM = 0, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=
000000000143b000
[
ffff80000c05008a] pgd=
100000087ffff003, p4d=
100000087ffff003,
pud=
100000087fffe003, pmd=
1000000800bcc003, pte=
00680000a0010713
Internal error: Oops:
96000061 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate:
200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __memcpy+0x30/0x260
lr : __xudc_ep0_queue+0xf0/0x110
sp :
ffff800008003d00
x29:
ffff800008003d00 x28:
ffff800009474e80 x27:
00000000000000a0
x26:
0000000000000100 x25:
0000000000000012 x24:
ffff000800bc8080
x23:
0000000000000001 x22:
0000000000000012 x21:
ffff000800bc8080
x20:
0000000000000012 x19:
ffff000800bc8080 x18:
0000000000000000
x17:
ffff800876482000 x16:
ffff800008004000 x15:
0000000000004000
x14:
00001f09785d0400 x13:
0103020101005567 x12:
0781400000000200
x11:
00000000c5672a10 x10:
00000000000008d0 x9 :
ffff800009463cf0
x8 :
ffff8000094757b0 x7 :
0201010055670781 x6 :
4000000002000112
x5 :
ffff80000c05009a x4 :
ffff000800a15012 x3 :
ffff00080362ad80
x2 :
0000000000000012 x1 :
ffff000800a15000 x0 :
ffff80000c050088
Call trace:
__memcpy+0x30/0x260
xudc_ep0_queue+0x3c/0x60
usb_ep_queue+0x38/0x44
composite_ep0_queue.constprop.0+0x2c/0xc0
composite_setup+0x8d0/0x185c
configfs_composite_setup+0x74/0xb0
xudc_irq+0x570/0xa40
__handle_irq_event_percpu+0x58/0x170
handle_irq_event+0x60/0x120
handle_fasteoi_irq+0xc0/0x220
handle_domain_irq+0x60/0x90
gic_handle_irq+0x74/0xa0
call_on_irq_stack+0x2c/0x60
do_interrupt_handler+0x54/0x60
el1_interrupt+0x30/0x50
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x78/0x7c
arch_cpu_idle+0x18/0x2c
do_idle+0xdc/0x15c
cpu_startup_entry+0x28/0x60
rest_init+0xc8/0xe0
arch_call_rest_init+0x10/0x1c
start_kernel+0x694/0x6d4
__primary_switched+0xa4/0xac
Fixes:
1f7c51660034 ("usb: gadget: Add xilinx usb2 device support")
Cc: stable@vger.kernel.org
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
Link: https://lore.kernel.org/r/20220824071253.1261096-1-piyush.mehta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jean-Francois Le Fillatre [Wed, 24 Aug 2022 19:13:21 +0000 (21:13 +0200)]
usb: add quirks for Lenovo OneLink+ Dock
[ Upstream commit
3d5f70949f1b1168fbb17d06eb5c57e984c56c58 ]
The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers:
17ef:1018 upstream
17ef:1019 downstream
Those two controllers both have problems with some USB3.0 devices,
particularly self-powered ones. Typical error messages include:
Timeout while waiting for setup device command
device not accepting address X, error -62
unable to enumerate USB device
By process of elimination the controllers themselves were identified as
the cause of the problem. Through trial and error the issue was solved
by using USB_QUIRK_RESET_RESUME for both chips.
Signed-off-by: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220824191320.17883-1-jflf_kernel@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wesley Cheng [Thu, 28 Jul 2022 02:06:47 +0000 (19:06 -0700)]
usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop
[ Upstream commit
040f2dbd2010c43f33ad27249e6dac48456f4d99 ]
Relocate the pullups_connected check until after it is ensured that there
are no runtime PM transitions. If another context triggered the DWC3
core's runtime resume, it may have already enabled the Run/Stop. Do not
re-run the entire pullup sequence again, as it may issue a core soft
reset while Run/Stop is already set.
This patch depends on
commit
69e131d1ac4e ("usb: dwc3: gadget: Prevent repeat pullup()")
Fixes:
77adb8bdf422 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thinh Nguyen [Fri, 22 Apr 2022 02:22:44 +0000 (19:22 -0700)]
usb: dwc3: gadget: Don't modify GEVNTCOUNT in pullup()
[ Upstream commit
8f8034f493b5eb1ad21ff392fd30c0cf9e71f73f ]
If the GEVNTCOUNT indicates events in the event buffer, the driver needs
to acknowledge them before the controller can halt. Simply let the
interrupt handler acknowledges the remaining event generated by the
controller while polling for DSTS.DEVCTLHLT. This avoids disabling irq
and taking care of race condition between the interrupt handlers and
pullup().
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ea306ec93c41ccafbdb5d16404ff3b6eca299613.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
040f2dbd2010 ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thinh Nguyen [Fri, 22 Apr 2022 02:22:38 +0000 (19:22 -0700)]
usb: dwc3: gadget: Refactor pullup()
[ Upstream commit
861c010a2ee1bc4a66d23f0da4aa22e75d8eaa24 ]
Move soft-disconnect sequence out of dwc3_gadget_pullup(). No
functional change here.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/4c0f259b17d95acaaa931f90276683a48a32fe22.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
040f2dbd2010 ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thinh Nguyen [Fri, 22 Apr 2022 02:22:31 +0000 (19:22 -0700)]
usb: dwc3: gadget: Prevent repeat pullup()
[ Upstream commit
69e131d1ac4e52a59ec181ab4f8aa8c48cd8fb64 ]
Don't do soft-disconnect if it's previously done. Likewise, don't do
soft-connect if the device is currently connected and running. It would
break normal operation.
Currently the caller of pullup() (udc's sysfs soft_connect) only checks
if it had initiated disconnect to prevent repeating soft-disconnect. It
doesn't check for soft-connect. To be safe, let's keep the check here
regardless whether the udc core is fixed.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1c1345bd66c97a9d32f77d63aaadd04b7b037143.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
040f2dbd2010 ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wesley Cheng [Wed, 16 Mar 2022 01:13:58 +0000 (18:13 -0700)]
usb: dwc3: Issue core soft reset before enabling run/stop
[ Upstream commit
0066472de157439d58454f4a55786f1045ea5681 ]
It is recommended by the Synopsis databook to issue a DCTL.CSftReset
when reconnecting from a device-initiated disconnect routine. This
resolves issues with enumeration during fast composition switching
cases, which result in an unknown device on the host.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220316011358.3057-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
040f2dbd2010 ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wesley Cheng [Fri, 17 Sep 2021 02:18:52 +0000 (19:18 -0700)]
usb: dwc3: gadget: Avoid starting DWC3 gadget during UDC unbind
[ Upstream commit
8217f07a50236779880f13e87f99224cd9117f83 ]
There is a race present where the DWC3 runtime resume runs in parallel
to the UDC unbind sequence. This will eventually lead to a possible
scenario where we are enabling the run/stop bit, without a valid
composition defined.
Thread#1 (handling UDC unbind):
usb_gadget_remove_driver()
-->usb_gadget_disconnect()
-->dwc3_gadget_pullup(0)
--> continue UDC unbind sequence
-->Thread#2 is running in parallel here
Thread#2 (handing next cable connect)
__dwc3_set_mode()
-->pm_runtime_get_sync()
-->dwc3_gadget_resume()
-->dwc->gadget_driver is NOT NULL yet
-->dwc3_gadget_run_stop(1)
--> _dwc3gadget_start()
...
Fix this by tracking the pullup disable routine, and avoiding resuming
of the DWC3 gadget. Once the UDC is re-binded, that will trigger the
pullup enable routine, which would handle enabling the DWC3 gadget.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20210917021852.2037-1-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
040f2dbd2010 ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Larry Finger [Sun, 14 Aug 2022 17:50:27 +0000 (12:50 -0500)]
staging: r8188eu: Add Rosewill USB-N150 Nano to device tables
[ Upstream commit
e01f5c8d6af231b3b09e23c1fe8a4057cdcc4e42 ]
This device is reported as using the RTL8188EUS chip.
It has the improbable USB ID of 0bda:ffef, which normally would belong
to Realtek, but this ID works for the reporter.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220814175027.2689-1-Larry.Finger@lwfinger.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Candy Febriyanto [Thu, 18 Nov 2021 16:37:34 +0000 (23:37 +0700)]
staging: r8188eu: Remove support for devices with 8188FU chipset (0bda:f179)
[ Upstream commit
6723b283c44a3fdf9f922ae9788aab38bd909211 ]
The new r8188eu driver doesn't actually support devices with vendor ID 0bda
and product ID f179[0][1][2], remove the ID so owners of these devices
don't have to blacklist the staging driver.
[0] https://github.com/lwfinger/rtl8188eu/issues/366#issuecomment-
888511731
[1] https://github.com/lwfinger/rtl8188eu/issues/385
[2] https://github.com/lwfinger/rtl8188eu/issues/385#issuecomment-
973013539
Cc: Larry Finger <Larry.Finger@lwfinger.net>
CC: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: Candy Febriyanto <cfebriyanto@gmail.com>
Link: https://lore.kernel.org/r/YZaBTq9vlMaJDFz2@mainframe.localdomain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
e01f5c8d6af2 ("staging: r8188eu: Add Rosewill USB-N150 Nano to device tables")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alex Deucher [Tue, 30 Aug 2022 14:59:49 +0000 (10:59 -0400)]
drm/amdgpu: make sure to init common IP before gmc
[ Upstream commit
a8671493d2074950553da3cf07d1be43185ef6c6 ]
Move common IP init before GMC init so that HDP gets
remapped before GMC init which uses it.
This fixes the Unsupported Request error reported through
AER during driver load. The error happens as a write happens
to the remap offset before real remapping is done.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216373
The error was unnoticed before and got visible because of the commit
referenced below. This doesn't fix anything in the commit below, rather
fixes the issue in amdgpu exposed by the commit. The reference is only
to associate this commit with below one so that both go together.
Fixes:
8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Victor Skvortsov [Thu, 16 Dec 2021 17:01:45 +0000 (17:01 +0000)]
drm/amdgpu: Separate vf2pf work item init from virt data exchange
[ Upstream commit
892deb48269c65376f3eeb5b4c032ff2c2979bd7 ]
We want to be able to call virt data exchange conditionally
after gmc sw init to reserve bad pages as early as possible.
Since this is a conditional call, we will need
to call it again unconditionally later in the init sequence.
Refactor the data exchange function so it can be
called multiple times without re-initializing the work item.
v2: Cleaned up the code. Kept the original call to init_exchange_data()
inside early init to initialize the work item, afterwards call
exchange_data() when needed.
Signed-off-by: Victor Skvortsov <victor.skvortsov@amd.com>
Reviewed By: Shaoyun.liu <Shaoyun.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Fri, 23 Sep 2022 12:15:52 +0000 (14:15 +0200)]
Linux 5.15.70
Link: https://lore.kernel.org/r/20220921153646.931277075@linuxfoundation.org
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Ron Economos <re@w6rz.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 5 Sep 2022 13:06:30 +0000 (15:06 +0200)]
ALSA: hda/sigmatel: Fix unused variable warning for beep power change
commit
51bdc8bb82525cd70feb92279c8b7660ad7948dd upstream.
The newly added stac_check_power_status() caused a compile warning
when CONFIG_SND_HDA_INPUT_BEEP is disabled. Fix it.
Fixes:
414d38ba8710 ("ALSA: hda/sigmatel: Keep power up while beep is enabled")
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20220905130630.2845-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tetsuo Handa [Thu, 25 Aug 2022 08:38:38 +0000 (17:38 +0900)]
cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
commit
43626dade36fa74d3329046f4ae2d7fdefe401c6 upstream.
syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at
cpuset_attach() [1], for commit
4f7e7236435ca0ab ("cgroup: Fix
threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that
cpuset_attach() is also called from cgroup_attach_task_all().
Add cpus_read_lock() like what cgroup_procs_write_start() does.
Link: https://syzkaller.appspot.com/bug?extid=29d3a3b4d86c8136ad9e
Reported-by: syzbot <syzbot+29d3a3b4d86c8136ad9e@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes:
4f7e7236435ca0ab ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock")
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mingwei Zhang [Thu, 21 Apr 2022 03:14:07 +0000 (03:14 +0000)]
KVM: SEV: add cache flush to solve SEV cache incoherency issues
commit
683412ccf61294d727ead4a73d97397396e69a6b upstream.
Flush the CPU caches when memory is reclaimed from an SEV guest (where
reclaim also includes it being unmapped from KVM's memslots). Due to lack
of coherency for SEV encrypted memory, failure to flush results in silent
data corruption if userspace is malicious/broken and doesn't ensure SEV
guest memory is properly pinned and unpinned.
Cache coherency is not enforced across the VM boundary in SEV (AMD APM
vol.2 Section 15.34.7). Confidential cachelines, generated by confidential
VM guests have to be explicitly flushed on the host side. If a memory page
containing dirty confidential cachelines was released by VM and reallocated
to another user, the cachelines may corrupt the new user at a later time.
KVM takes a shortcut by assuming all confidential memory remain pinned
until the end of VM lifetime. Therefore, KVM does not flush cache at
mmu_notifier invalidation events. Because of this incorrect assumption and
the lack of cache flushing, malicous userspace can crash the host kernel:
creating a malicious VM and continuously allocates/releases unpinned
confidential memory pages when the VM is running.
Add cache flush operations to mmu_notifier operations to ensure that any
physical memory leaving the guest VM get flushed. In particular, hook
mmu_notifier_invalidate_range_start and mmu_notifier_release events and
flush cache accordingly. The hook after releasing the mmu lock to avoid
contention with other vCPUs.
Cc: stable@vger.kernel.org
Suggested-by: Sean Christpherson <seanjc@google.com>
Reported-by: Mingwei Zhang <mizhang@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Message-Id: <
20220421031407.2516575-4-mizhang@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[OP: adjusted KVM_X86_OP_OPTIONAL() -> KVM_X86_OP_NULL, applied
kvm_arch_guest_memory_reclaimed() call in kvm_set_memslot()]
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sewookseo [Thu, 7 Jul 2022 10:01:39 +0000 (10:01 +0000)]
net: Find dst with sk's xfrm policy not ctl_sk
commit
e22aa14866684f77b4f6b6cae98539e520ddb731 upstream.
If we set XFRM security policy by calling setsockopt with option
IPV6_XFRM_POLICY, the policy will be stored in 'sock_policy' in 'sock'
struct. However tcp_v6_send_response doesn't look up dst_entry with the
actual socket but looks up with tcp control socket. This may cause a
problem that a RST packet is sent without ESP encryption & peer's TCP
socket can't receive it.
This patch will make the function look up dest_entry with actual socket,
if the socket has XFRM policy(sock_policy), so that the TCP response
packet via this function can be encrypted, & aligned on the encrypted
TCP socket.
Tested: We encountered this problem when a TCP socket which is encrypted
in ESP transport mode encryption, receives challenge ACK at SYN_SENT
state. After receiving challenge ACK, TCP needs to send RST to
establish the socket at next SYN try. But the RST was not encrypted &
peer TCP socket still remains on ESTABLISHED state.
So we verified this with test step as below.
[Test step]
1. Making a TCP state mismatch between client(IDLE) & server(ESTABLISHED).
2. Client tries a new connection on the same TCP ports(src & dst).
3. Server will return challenge ACK instead of SYN,ACK.
4. Client will send RST to server to clear the SOCKET.
5. Client will retransmit SYN to server on the same TCP ports.
[Expected result]
The TCP connection should be established.
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Sehee Lee <seheele@google.com>
Signed-off-by: Sewook Seo <sewookseo@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hyunwoo Kim [Mon, 20 Jun 2022 14:17:46 +0000 (07:17 -0700)]
video: fbdev: pxa3xx-gcu: Fix integer overflow in pxa3xx_gcu_write
[ Upstream commit
a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7 ]
In pxa3xx_gcu_write, a count parameter of type size_t is passed to words of
type int. Then, copy_from_user() may cause a heap overflow because it is used
as the third argument of copy_from_user().
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Youling Tang [Thu, 1 Sep 2022 11:10:59 +0000 (19:10 +0800)]
mksysmap: Fix the mismatch of 'L0' symbols in System.map
[ Upstream commit
c17a2538704f926ee4d167ba625e09b1040d8439 ]
When System.map was generated, the kernel used mksysmap to filter the
kernel symbols, we need to filter "L0" symbols in LoongArch architecture.
$ cat System.map | grep L0
9000000000221540 t L0
The L0 symbol exists in System.map, but not in .tmp_System.map. When
"cmp -s System.map .tmp_System.map" will show "Inconsistent kallsyms
data" error message in link-vmlinux.sh script.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Clément Péron [Tue, 6 Sep 2022 15:30:33 +0000 (17:30 +0200)]
drm/panfrost: devfreq: set opp to the recommended one to configure regulator
[ Upstream commit
d76034a427a2660b080bc155e4fd8f6393eefb48 ]
Enabling panfrost GPU OPP with dynamic regulator will make OPP
responsible to enable and configure it.
Unfortunately OPP configure and enable the regulator when an OPP
is asked to be set, which is not the case during
panfrost_devfreq_init().
This leave the regulator unconfigured and if no GPU load is
triggered, no OPP is asked to be set which make the regulator framework
switching it off during regulator_late_cleanup() without
noticing and therefore make the board hang as any access to GPU
memory space make bus locks up.
Call dev_pm_opp_set_opp() with the recommend OPP in
panfrost_devfreq_init() to enable the regulator, this will properly
configure and enable the regulator and will avoid any switch off
by regulator_late_cleanup().
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220906153034.153321-5-peron.clem@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexander Sverdlin [Tue, 6 Sep 2022 09:59:43 +0000 (11:59 +0200)]
MIPS: OCTEON: irq: Fix octeon_irq_force_ciu_mapping()
[ Upstream commit
ba912afbd611d3a5f22af247721a071ad1d5b9e0 ]
For irq_domain_associate() to work the virq descriptor has to be
pre-allocated in advance. Otherwise the following happens:
WARNING: CPU: 0 PID: 0 at .../kernel/irq/irqdomain.c:527 irq_domain_associate+0x298/0x2e8
error: virq128 is not allocated
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.78-... #1
...
Call Trace:
[<
ffffffff801344c4>] show_stack+0x9c/0x130
[<
ffffffff80769550>] dump_stack+0x90/0xd0
[<
ffffffff801576d0>] __warn+0x118/0x130
[<
ffffffff80157734>] warn_slowpath_fmt+0x4c/0x70
[<
ffffffff801b83c0>] irq_domain_associate+0x298/0x2e8
[<
ffffffff80a43bb8>] octeon_irq_init_ciu+0x4c8/0x53c
[<
ffffffff80a76cbc>] of_irq_init+0x1e0/0x388
[<
ffffffff80a452cc>] init_IRQ+0x4c/0xf4
[<
ffffffff80a3cc00>] start_kernel+0x404/0x698
Use irq_alloc_desc_at() to avoid the above problem.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Tue, 6 Sep 2022 21:09:11 +0000 (22:09 +0100)]
afs: Return -EAGAIN, not -EREMOTEIO, when a file already locked
[ Upstream commit
0066f1b0e27556381402db3ff31f85d2a2265858 ]
When trying to get a file lock on an AFS file, the server may return
UAEAGAIN to indicate that the lock is already held. This is currently
translated by the default path to -EREMOTEIO.
Translate it instead to -EAGAIN so that we know we can retry it.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey E Altman <jaltman@auristor.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Link: https://lore.kernel.org/r/166075761334.3533338.2591992675160918098.stgit@warthog.procyon.org.uk/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
jerry.meng [Mon, 5 Sep 2022 01:24:52 +0000 (09:24 +0800)]
net: usb: qmi_wwan: add Quectel RM520N
[ Upstream commit
e1091e226a2bab4ded1fe26efba2aee1aab06450 ]
add support for Quectel RM520N which is based on Qualcomm SDX62 chip.
0x0801: DIAG + NMEA + AT + MODEM + RMNET
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0801 Rev= 5.04
S: Manufacturer=Quectel
S: Product=RM520N-GL
S: SerialNumber=
384af524
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: jerry.meng <jerry-meng@foxmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Link: https://lore.kernel.org/r/tencent_E50CA8A206904897C2D20DDAE90731183C05@qq.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mohan Kumar [Mon, 5 Sep 2022 17:24:20 +0000 (22:54 +0530)]
ALSA: hda/tegra: Align BDL entry to 4KB boundary
[ Upstream commit
8d44e6044a0e885acdd01813768a0b27906d64fd ]
AZA HW may send a burst read/write request crossing 4K memory boundary.
The 4KB boundary is not guaranteed by Tegra HDA HW. Make SW change to
include the flag AZX_DCAPS_4K_BDLE_BOUNDARY to align BDLE to 4K
boundary.
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20220905172420.3801-1-mkumard@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Sun, 4 Sep 2022 07:27:50 +0000 (09:27 +0200)]
ALSA: hda/sigmatel: Keep power up while beep is enabled
[ Upstream commit
414d38ba871092aeac4ed097ac4ced89486646f7 ]
It seems that the beep playback doesn't work well on IDT codec devices
when the codec auto-pm is enabled. Keep the power on while the beep
switch is enabled.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1200544
Link: https://lore.kernel.org/r/20220904072750.26164-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Soenke Huster [Fri, 2 Sep 2022 08:19:58 +0000 (10:19 +0200)]
wifi: mac80211_hwsim: check length for virtio packets
[ Upstream commit
8c0427842aaef161a38ac83b7e8d8fe050b4be04 ]
An invalid packet with a length shorter than the specified length in the
netlink header can lead to use-after-frees and slab-out-of-bounds in the
processing of the netlink attributes, such as the following:
BUG: KASAN: slab-out-of-bounds in __nla_validate_parse+0x1258/0x2010
Read of size 2 at addr
ffff88800ac7952c by task kworker/0:1/12
Workqueue: events hwsim_virtio_rx_work
Call Trace:
<TASK>
dump_stack_lvl+0x45/0x5d
print_report.cold+0x5e/0x5e5
kasan_report+0xb1/0x1c0
__nla_validate_parse+0x1258/0x2010
__nla_parse+0x22/0x30
hwsim_virtio_handle_cmd.isra.0+0x13f/0x2d0
hwsim_virtio_rx_work+0x1b2/0x370
process_one_work+0x8df/0x1530
worker_thread+0x575/0x11a0
kthread+0x29d/0x340
ret_from_fork+0x22/0x30
</TASK>
Discarding packets with an invalid length solves this.
Therefore, skb->len must be set at reception.
Change-Id: Ieaeb9a4c62d3beede274881a7c2722c6c6f477b6
Signed-off-by: Soenke Huster <soenke.huster@eknoes.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Tue, 5 Apr 2022 12:34:09 +0000 (13:34 +0100)]
rxrpc: Fix calc of resend age
[ Upstream commit
214a9dc7d852216e83acac7b75bc18f01ce184c2 ]
Fix the calculation of the resend age to add a microsecond value as
microseconds, not nanoseconds.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Fri, 6 May 2022 22:55:21 +0000 (23:55 +0100)]
rxrpc: Fix local destruction being repeated
[ Upstream commit
d3d863036d688313f8d566b87acd7d99daf82749 ]
If the local processor work item for the rxrpc local endpoint gets requeued
by an event (such as an incoming packet) between it getting scheduled for
destruction and the UDP socket being closed, the rxrpc_local_destroyer()
function can get run twice. The second time it can hang because it can end
up waiting for cleanup events that will never happen.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hannes Reinecke [Wed, 24 Aug 2022 06:00:33 +0000 (08:00 +0200)]
scsi: lpfc: Return DID_TRANSPORT_DISRUPTED instead of DID_REQUEUE
[ Upstream commit
c0a50cd389c3ed54831e240023dd12bafa56b3a6 ]
When the driver hits an internal error condition returning DID_REQUEUE the
I/O will be retried on the same ITL nexus. This will inhibit multipathing,
resulting in endless retries even if the error could have been resolved by
using a different ITL nexus. Return DID_TRANSPORT_DISRUPTED to allow for
multipath to engage and route I/O to another ITL nexus.
Link: https://lore.kernel.org/r/20220824060033.138661-1-hare@suse.de
Reviewed-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiaolei Wang [Thu, 25 Aug 2022 11:19:22 +0000 (19:19 +0800)]
regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe()
[ Upstream commit
78e1e867f44e6bdc72c0e6a2609a3407642fb30b ]
The pfuze_chip::regulator_descs is an array of size
PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators
is the pointer to the real regulators of a specific device.
The number of real regulator is supposed to be less than
the PFUZE100_MAX_REGULATOR, so we should use the size of
'regulator_num * sizeof(struct pfuze_regulator)' in memcpy().
This fixes the out of bounds access bug reported by KASAN.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Tue, 23 Aug 2022 08:09:57 +0000 (10:09 +0200)]
ASoC: nau8824: Fix semaphore unbalance at error paths
[ Upstream commit
5628560e90395d3812800a8e44a01c32ffa429ec ]
The semaphore of nau8824 wasn't properly unlocked at some error
handling code paths, hence this may result in the unbalance (and
potential lock-up). Fix them to handle the semaphore up properly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20220823081000.2965-3-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jassi Brar [Mon, 1 Aug 2022 14:10:05 +0000 (09:10 -0500)]
arm64: dts: juno: Add missing MHU secure-irq
[ Upstream commit
422ab8fe15e30066d4c8e236b747c77069bfca45 ]
The MHU secure interrupt exists physically but is missing in the DT node.
Specify the interrupt in DT node to fix a warning on Arm Juno board:
mhu@
2b1f0000: interrupts: [[0, 36, 4], [0, 35, 4]] is too short
Link: https://lore.kernel.org/r/20220801141005.599258-1-jassisinghbrar@gmail.com
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zheyu Ma [Mon, 4 Apr 2022 08:47:17 +0000 (16:47 +0800)]
video: fbdev: i740fb: Error out if 'pixclock' equals zero
commit
15cf0b82271b1823fb02ab8c377badba614d95d5 upstream.
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero in the function
i740fb_check_var().
The following log reveals it:
divide error: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:444 [inline]
RIP: 0010:i740fb_set_par+0x272f/0x3bb0 drivers/video/fbdev/i740fb.c:739
Call Trace:
fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1036
do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1112
fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1191
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Stefan Ghinea <stefan.ghinea@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlos Llamas [Tue, 20 Sep 2022 05:24:43 +0000 (05:24 +0000)]
binder: remove inaccurate mmap_assert_locked()
Acquiring the mmap_lock during exit_mmap() was only added recently in
v5.17 by commit
64591e8605d6 ("mm: protect free_pgtables with mmap_lock
write lock in exit_mmap"). Soon after, asserts for holding this lock
were added to the binder_alloc_set_vma() callback by the following two
fix commits in mainline: commit
b0cab80ecd54 ("android: binder: fix
lockdep check on clearing vma") and commit
a43cfc87caaf ("android:
binder: stop saving a pointer to the VMA").
These two fix commits were picked for stable trees including v5.15 were
unfortunately the mmap_lock is not held during exit_mmap() yet and this
unmet dependency leads to the following BUG report:
------------[ cut here ]------------
kernel BUG at include/linux/mmap_lock.h:156!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 3 PID: 437 Comm: binder Not tainted 5.15.68 #5
Hardware name: linux,dummy-virt (DT)
pstate:
60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : binder_alloc_vma_close+0x6c/0x70
lr : binder_alloc_vma_close+0x6c/0x70
sp :
ffff800008687a70
x29:
ffff800008687a70 x28:
ffff02a7ccf89d00 x27:
ffff02a7c92f99e8
x26:
000000000000012a x25:
ffff02a7c6284740 x24:
ffff02a7ccf8a360
x23:
ffff02a7c92f9980 x22:
1ffff000010d0f6c x21:
ffff02a7c92f99e8
x20:
ffff02a7c92f9980 x19:
ffff02a7d16b79a8 x18:
0000ffffe1702d20
x17:
3334373239343932 x16:
34206e6163735f74 x15:
78656e5f616d756e
x14:
0a30303030303030 x13:
7366666f5f6e6163 x12:
ffff60550564a12b
x11:
1fffe0550564a12a x10:
ffff60550564a12a x9 :
dfff800000000000
x8 :
ffff02a82b250957 x7 :
0000000000000001 x6 :
ffff60550564a12a
x5 :
ffff02a82b250950 x4 :
dfff800000000000 x3 :
0000000000000000
x2 :
0000000000000000 x1 :
ffff02a7ccf89d00 x0 :
0000000000000374
Call trace:
binder_alloc_vma_close+0x6c/0x70
binder_vma_close+0x38/0xf4
remove_vma+0x4c/0x94
exit_mmap+0x14c/0x2bc
__mmput+0x70/0x19c
mmput+0x68/0x80
do_exit+0x484/0xeb0
do_group_exit+0x5c/0x100
[...]
This patch removes the inaccurate assert specifically from v5.15 since
it's the only release with such issue. Note the mmap_lock is technically
not needed here as the mm->mm_users has dropped to zero at this point.
More context: https://lore.kernel.org/all/YxpQaio7xm3z9TUw@google.com/.
Fixes:
b0cab80ecd54 ("android: binder: fix lockdep check on clearing vma")
Fixes:
a43cfc87caaf ("android: binder: stop saving a pointer to the VMA")
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org> # v5.15
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 9 Sep 2022 15:53:27 +0000 (11:53 -0400)]
drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega
commit
e3163bc8ffdfdb405e10530b140135b2ee487f89 upstream.
This mirrors what we do for other asics and this way we are
sure the sdma doorbell range is properly initialized.
There is a comment about the way doorbells on gfx9 work that
requires that they are initialized for other IPs before GFX
is initialized. However, the statement says that it applies to
multimedia as well, but the VCN code currently initializes
doorbells after GFX and there are no known issues there. In my
testing at least I don't see any problems on SDMA.
This is a prerequisite for fixing the Unsupported Request error
reported through AER during driver load.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216373
The error was unnoticed before and got visible because of the commit
referenced below. This doesn't fix anything in the commit below, rather
fixes the issue in amdgpu exposed by the commit. The reference is only
to associate this commit with below one so that both go together.
Fixes:
8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@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>
Alex Deucher [Fri, 9 Sep 2022 15:47:20 +0000 (11:47 -0400)]
drm/amdgpu: move nbio ih_doorbell_range() into ih code for vega
commit
dc1d85cb790f2091eea074cee24a704b2d6c4a06 upstream.
This mirrors what we do for other asics and this way we are
sure the ih doorbell range is properly initialized.
There is a comment about the way doorbells on gfx9 work that
requires that they are initialized for other IPs before GFX
is initialized. In this case IH is initialized before GFX,
so there should be no issue.
This is a prerequisite for fixing the Unsupported Request error
reported through AER during driver load.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216373
The error was unnoticed before and got visible because of the commit
referenced below. This doesn't fix anything in the commit below, rather
fixes the issue in amdgpu exposed by the commit. The reference is only
to associate this commit with below one so that both go together.
Fixes:
8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@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>
Lijo Lazar [Thu, 8 Sep 2022 02:58:57 +0000 (08:28 +0530)]
drm/amdgpu: Don't enable LTR if not supported
commit
6c20490663553cd7e07d8de8af482012329ab9d6 upstream.
As per PCIE Base Spec r4.0 Section 6.18
'Software must not enable LTR in an Endpoint unless the Root Complex
and all intermediate Switches indicate support for LTR.'
This fixes the Unsupported Request error reported through AER during
ASPM enablement.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216455
The error was unnoticed before and got visible because of the commit
referenced below. This doesn't fix anything in the commit below, rather
fixes the issue in amdgpu exposed by the commit. The reference is only
to associate this commit with below one so that both go together.
Fixes:
8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
Reported-by: Gustaw Smolarczyk <wielkiegie@gmail.com>
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ben Hutchings [Tue, 25 Aug 2020 22:27:40 +0000 (23:27 +0100)]
tools/include/uapi: Fix <asm/errno.h> for parisc and xtensa
commit
95363747a6f39e88a3052fcf6ce6237769495ce0 upstream.
tools/include/uapi/asm/errno.h currently attempts to include
non-existent arch-specific errno.h header for xtensa.
Remove this case so that <asm-generic/errno.h> is used instead,
and add the missing arch-specific header for parisc.
References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ia64&ver=5.8.3-1%7Eexp1&stamp=
1598340829&raw=1
Signed-off-by: Ben Hutchings <benh@debian.org>
Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
Cc: <stable@vger.kernel.org> # 5.10+
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Tue, 13 Sep 2022 06:51:10 +0000 (08:51 +0200)]
parisc: Allow CONFIG_64BIT with ARCH=parisc
commit
805ce8614958c925877ba6b6dc26cdf9f8800474 upstream.
The previous patch triggered a build failure for the debian kernel,
which has CONFIG_64BIT enabled, uses the CROSS_COMPILER environment
variable and uses ARCH=parisc to configure the kernel for 64-bit
support.
This patch weakens the previous patch while keeping the recommended way
to configure the kernel with:
ARCH=parisc -> build 32-bit kernel
ARCH=parisc64 -> build 64-bit kernel
while adding the possibility for debian to configure a 64-bit kernel
even if ARCH=parisc is set (PA8X00 CPU has to be selected and
CONFIG_64BIT needs to be enabled).
The downside of this patch is, that we now have a small window open
again where people may get it wrong: if they enable CONFIG_64BIT and try
to compile with a 32-bit compiler.
Fixes:
3dcfb729b5f4 ("parisc: Make CONFIG_64BIT available for ARCH=parisc64 only")
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 5.15+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Metzmacher [Wed, 14 Sep 2022 03:25:47 +0000 (05:25 +0200)]
cifs: always initialize struct msghdr smb_msg completely
commit
bedc8f76b3539ac4f952114b316bcc2251e808ce upstream.
So far we were just lucky because the uninitialized members
of struct msghdr are not used by default on a SOCK_STREAM tcp
socket.
But as new things like msg_ubuf and sg_from_iter where added
recently, we should play on the safe side and avoid potention
problems in future.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Metzmacher [Wed, 14 Sep 2022 03:25:46 +0000 (05:25 +0200)]
cifs: don't send down the destination address to sendmsg for a SOCK_STREAM
commit
17d3df38dc5f4cec9b0ac6eb79c1859b6e2693a4 upstream.
This is ignored anyway by the tcp layer.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Cc: stable@vger.kernel.org
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ronnie Sahlberg [Mon, 12 Sep 2022 03:04:46 +0000 (13:04 +1000)]
cifs: revalidate mapping when doing direct writes
commit
7500a99281dfed2d4a84771c933bcb9e17af279b upstream.
Kernel bugzilla: 216301
When doing direct writes we need to also invalidate the mapping in case
we have a cached copy of the affected page(s) in memory or else
subsequent reads of the data might return the old/stale content
before we wrote an update to the server.
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thierry Reding [Wed, 24 Aug 2022 15:32:56 +0000 (17:32 +0200)]
of/device: Fix up of_dma_configure_id() stub
commit
40bfe7a86d84cf08ac6a8fe2f0c8bf7a43edd110 upstream.
Since the stub version of of_dma_configure_id() was added in commit
a081bd4af4ce ("of/device: Add input id to of_dma_configure()"), it has
not matched the signature of the full function, leading to build failure
reports when code using this function is built on !OF configurations.
Fixes:
a081bd4af4ce ("of/device: Add input id to of_dma_configure()")
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Link: https://lore.kernel.org/r/20220824153256.1437483-1-thierry.reding@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yang Yingliang [Wed, 24 Aug 2022 09:36:57 +0000 (17:36 +0800)]
parisc: ccio-dma: Add missing iounmap in error path in ccio_probe()
[ Upstream commit
38238be4e881a5d0abbe4872b4cd6ed790be06c8 ]
Add missing iounmap() before return from ccio_probe(), if ccio_init_resources()
fails.
Fixes:
d46c742f827f ("parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources()")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Roesch [Mon, 12 Sep 2022 16:53:25 +0000 (09:53 -0700)]
block: blk_queue_enter() / __bio_queue_enter() must return -EAGAIN for nowait
[ Upstream commit
56f99b8d06ef1ed1c9730948f9f05ac2b930a20b ]
Today blk_queue_enter() and __bio_queue_enter() return -EBUSY for the
nowait code path. This is not correct: they should return -EAGAIN
instead.
This problem was detected by fio. The following command exposed the
above problem:
t/io_uring -p0 -d128 -b4096 -s32 -c32 -F1 -B0 -R0 -X1 -n24 -P1 -u1 -O0 /dev/ng0n1
By applying the patch, the retry case is handled correctly in the slow
path.
Signed-off-by: Stefan Roesch <shr@fb.com>
Fixes:
bfd343aa1718 ("blk-mq: don't wait in blk_mq_queue_enter() if __GFP_WAIT isn't set")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stuart Menefy [Thu, 8 Sep 2022 15:52:43 +0000 (16:52 +0100)]
drm/meson: Fix OSD1 RGB to YCbCr coefficient
[ Upstream commit
6463d3930ba5b6addcfc8f80a4543976a2fc7656 ]
VPP_WRAP_OSD1_MATRIX_COEF22.Coeff22 is documented as being bits 0-12,
not 16-28.
Without this the output tends to have a pink hue, changing it results
in better color accuracy.
The vendor kernel doesn't use this register. However the code which
sets VIU2_OSD1_MATRIX_COEF22 also uses bits 0-12. There is a slightly
different style of registers for configuring some of the other matrices,
which do use bits 16-28 for this coefficient, but those have names
ending in MATRIX_COEF22_30, and this is not one of those.
Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
Fixes:
728883948b0d ("drm/meson: Add G12A Support for VIU setup")
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220908155243.687143-1-stuart.menefy@mathembedded.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stuart Menefy [Thu, 8 Sep 2022 15:51:03 +0000 (16:51 +0100)]
drm/meson: Correct OSD1 global alpha value
[ Upstream commit
6836829c8ea453c9e3e518e61539e35881c8ed5f ]
VIU_OSD1_CTRL_STAT.GLOBAL_ALPHA is a 9 bit field, so the maximum
value is 0x100 not 0xff.
This matches the vendor kernel.
Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
Fixes:
bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220908155103.686904-1-stuart.menefy@mathembedded.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pali Rohár [Tue, 6 Sep 2022 10:54:31 +0000 (12:54 +0200)]
gpio: mpc8xxx: Fix support for IRQ_TYPE_LEVEL_LOW flow_type in mpc85xx
[ Upstream commit
279c12df8d2efb28def9d037f288cbfb97c30fe2 ]
Commit
e39d5ef67804 ("powerpc/5xxx: extend mpc8xxx_gpio driver to support
mpc512x gpios") implemented support for IRQ_TYPE_LEVEL_LOW flow type in
mpc512x via falling edge type. Do same for mpc85xx which support was added
in commit
345e5c8a1cc3 ("powerpc: Add interrupt support to mpc8xxx_gpio").
Fixes probing of lm90 hwmon driver on mpc85xx based board which use level
interrupt. Without it kernel prints error and refuse lm90 to work:
[ 15.258370] genirq: Setting trigger mode 8 for irq 49 failed (mpc8xxx_irq_set_type+0x0/0xf8)
[ 15.267168] lm90 0-004c: cannot request IRQ 49
[ 15.272708] lm90: probe of 0-004c failed with error -22
Fixes:
345e5c8a1cc3 ("powerpc: Add interrupt support to mpc8xxx_gpio")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Thu, 25 Aug 2022 18:49:05 +0000 (14:49 -0400)]
NFSv4: Turn off open-by-filehandle and NFS re-export for NFSv4.0
[ Upstream commit
2a9d683b48c8a87e61a4215792d44c90bcbbb536 ]
The NFSv4.0 protocol only supports open() by name. It cannot therefore
be used with open_by_handle() and friends, nor can it be re-exported by
knfsd.
Reported-by: Chuck Lever III <chuck.lever@oracle.com>
Fixes:
20fa19027286 ("nfs: add export operations")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Wu [Fri, 19 Aug 2022 02:45:41 +0000 (10:45 +0800)]
pinctrl: sunxi: Fix name for A100 R_PIO
[ Upstream commit
76648c867c6c03b8a468d9c9222025873ecc613d ]
The name of A100 R_PIO driver should be sun50i-a100-r-pinctrl,
not sun50iw10p1-r-pinctrl.
Fixes:
473436e7647d6 ("pinctrl: sunxi: add support for the Allwinner A100 pin controller")
Signed-off-by: Michael Wu <michael@allwinnertech.com>
Acked-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20220819024541.74191-1-michael@allwinnertech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
João H. Spies [Mon, 8 Aug 2022 02:51:20 +0000 (02:51 +0000)]
pinctrl: rockchip: Enhance support for IRQ_TYPE_EDGE_BOTH
[ Upstream commit
b871656aa4f54e04207f62bdd0d7572be1d86b36 ]
Switching between falling/rising edges for IRQ_TYPE_EDGE_BOTH on pins that
require debounce can cause the device to lose events due to a desync
between pin state and irq type.
This problem is resolved by switching between IRQ_TYPE_LEVEL_LOW and
IRQ_TYPE_LEVEL_HIGH instead.
Fixes:
936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")
Signed-off-by: João H. Spies <jhlspies@gmail.com>
Link: https://lore.kernel.org/r/20220808025121.110223-1-jhlspies@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Molly Sophia [Sun, 7 Aug 2022 12:26:45 +0000 (20:26 +0800)]
pinctrl: qcom: sc8180x: Fix wrong pin numbers
[ Upstream commit
48ec73395887694f13c9452b4dcfb43710451757 ]
The pin numbers for UFS_RESET and SDC2_* are not
consistent in the pinctrl driver for sc8180x.
So fix it.
Signed-off-by: Molly Sophia <mollysophia379@gmail.com>
Fixes:
97423113ec4b ("pinctrl: qcom: Add sc8180x TLMM driver")
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220807122645.13830-3-mollysophia379@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Molly Sophia [Sun, 7 Aug 2022 12:26:44 +0000 (20:26 +0800)]
pinctrl: qcom: sc8180x: Fix gpio_wakeirq_map
[ Upstream commit
6124cec530c7d8faab96d340ab2df5161e5d1c8a ]
Currently in the wakeirq_map, gpio36 and gpio37 have the same wakeirq
number, resulting in gpio37 being unable to trigger interrupts.
It looks like that this is a typo in the wakeirq map. So fix it.
Signed-off-by: Molly Sophia <mollysophia379@gmail.com>
Fixes:
97423113ec4b ("pinctrl: qcom: Add sc8180x TLMM driver")
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220807122645.13830-2-mollysophia379@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergey Shtylyov [Sat, 13 Aug 2022 20:34:16 +0000 (23:34 +0300)]
of: fdt: fix off-by-one error in unflatten_dt_nodes()
[ Upstream commit
2f945a792f67815abca26fa8a5e863ccf3fa1181 ]
Commit
78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
forgot to fix up the depth check in the loop body in unflatten_dt_nodes()
which makes it possible to overflow the nps[] buffer...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
Fixes:
78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergiu Moga [Wed, 24 Aug 2022 14:29:03 +0000 (17:29 +0300)]
tty: serial: atmel: Preserve previous USART mode if RS485 disabled
[ Upstream commit
692a8ebcfc24f4a5bea0eb2967e450f584193da6 ]
Whenever the atmel_rs485_config() driver method would be called,
the USART mode is reset to normal mode before even checking if
RS485 flag is set, thus resulting in losing the previous USART
mode in the case where the checking fails.
Some tools, such as `linux-serial-test`, lead to the driver calling
this method when doing the setup of the serial port: after setting the
port mode (Hardware Flow Control, Normal Mode, RS485 Mode, etc.),
`linux-serial-test` tries to enable/disable RS485 depending on
the commandline arguments that were passed.
Example of how this issue could reveal itself:
When doing a serial communication with Hardware Flow Control through
`linux-serial-test`, the tool would lead to the driver roughly doing
the following:
- set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS bit in the
ATMEL_US_MR register) through the atmel_set_termios() to enable
Hardware Flow Control
- disable RS485 through the atmel_config_rs485() method
Thus, when the latter is called, the mode will be reset and the
previously set bit is unset, leaving USART in normal mode instead of
the expected Hardware Flow Control mode.
This fix ensures that this reset is only done if the checking for
RS485 succeeds and that the previous mode is preserved otherwise.
Fixes:
e8faff7330a35 ("ARM: 6092/1: atmel_serial: support for RS485 communications")
Cc: stable <stable@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com>
Link: https://lore.kernel.org/r/20220824142902.502596-1-sergiu.moga@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lino Sanfilippo [Sun, 10 Apr 2022 10:46:42 +0000 (12:46 +0200)]
serial: atmel: remove redundant assignment in rs485_config
[ Upstream commit
60efd0513916f195dd85bfbf21653f74f9ab019c ]
In uart_set_rs485_config() the serial core already assigns the passed
serial_rs485 struct to the uart port.
So remove the assignment from the drivers rs485_config() function to avoid
redundancy.
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Link: https://lore.kernel.org/r/20220410104642.32195-10-LinoSanfilippo@gmx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of:
692a8ebcfc24 ("tty: serial: atmel: Preserve previous USART mode if RS485 disabled")
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Sat, 5 Mar 2022 12:32:00 +0000 (20:32 +0800)]
drm/tegra: vic: Fix build warning when CONFIG_PM=n
[ Upstream commit
b5d5288a46876f6767950449aea310f71ac86277 ]
drivers/gpu/drm/tegra/vic.c:326:12: error: ‘vic_runtime_suspend’ defined but not used [-Werror=unused-function]
static int vic_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/tegra/vic.c:292:12: error: ‘vic_runtime_resume’ defined but not used [-Werror=unused-function]
static int vic_runtime_resume(struct device *dev)
^~~~~~~~~~~~~~~~~~
Mark it as __maybe_unused.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Stable-dep-of:
c7860cbee998 ("drm/tegra: Fix vmapping of prime buffers")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Tue, 20 Sep 2022 10:39:46 +0000 (12:39 +0200)]
Linux 5.15.69
Link: https://lore.kernel.org/r/20220916100446.916515275@linuxfoundation.org
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Tested-by: Ron Economos <re@w6rz.net>
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jarrah Gosbell [Tue, 23 Aug 2022 17:00:37 +0000 (10:00 -0700)]
Input: goodix - add compatible string for GT1158
commit
80b9ebd3e478cd41526cbf84f80c3e0eb885d1d3 upstream.
Add compatible string for GT1158 missing from the previous patch.
Fixes:
425fe4709c76 ("Input: goodix - add support for GT1158")
Signed-off-by: Jarrah Gosbell <kernel@undef.tools>
Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sindhu-Devale [Tue, 6 Sep 2022 22:32:43 +0000 (17:32 -0500)]
RDMA/irdma: Use s/g array in post send only when its valid
commit
2c8844431d065ae15a6b442f5769b60aeaaa07af upstream.
Send with invalidate verb call can pass in an
uninitialized s/g array with 0 sge's which is
filled into irdma WQE and causes a HW asynchronous
event.
Fix this by using the s/g array in irdma post send
only when its valid.
Fixes: 551c46e ("RDMA/irdma: Add user/kernel shared libraries")
Signed-off-by: Sindhu-Devale <sindhu.devale@intel.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
Link: https://lore.kernel.org/r/20220906223244.1119-5-shiraz.saleem@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jing Leng [Thu, 21 Jul 2022 01:48:15 +0000 (18:48 -0700)]
usb: gadget: f_uac2: fix superspeed transfer
commit
f511aef2ebe5377d4c263842f2e0c0b8e274e8e5 upstream.
On page 362 of the USB3.2 specification (
https://usb.org/sites/default/files/usb_32_20210125.zip),
The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned
by Enhanced SuperSpeed devices that are operating at Gen X speed.
Each endpoint described in an interface is followed by a 'SuperSpeed
Endpoint Companion Descriptor'.
If users use SuperSpeed UDC, host can't recognize the device if endpoint
doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed.
Currently in the uac2 driver code:
1. ss_epout_desc_comp follows ss_epout_desc;
2. ss_epin_fback_desc_comp follows ss_epin_fback_desc;
3. ss_epin_desc_comp follows ss_epin_desc;
4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint
Companion Descriptor' followed, so we should add it.
Fixes:
eaf6cbe09920 ("usb: gadget: f_uac2: add volume and mute support")
Cc: stable <stable@kernel.org>
Signed-off-by: Jing Leng <jleng@ambarella.com>
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Link: https://lore.kernel.org/r/20220721014815.14453-1-quic_jackp@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 2 Sep 2021 22:47:58 +0000 (23:47 +0100)]
usb: gadget: f_uac2: clean up some inconsistent indenting
commit
18d6b39ee8959c6e513750879b52fd215533cc87 upstream.
There are bunch of statements where the indentation is not correct,
clean these up.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210902224758.57600-1-colin.king@canonical.com
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathew McBride [Thu, 1 Sep 2022 05:21:49 +0000 (05:21 +0000)]
soc: fsl: select FSL_GUTS driver for DPIO
commit
9a472613f5bccf1b36837423495ae592a9c5182f upstream.
The soc/fsl/dpio driver will perform a soc_device_match()
to determine the optimal cache settings for a given CPU core.
If FSL_GUTS is not enabled, this search will fail and
the driver will not configure cache stashing for the given
DPIO, and a string of "unknown SoC" messages will appear:
fsl_mc_dpio dpio.7: unknown SoC version
fsl_mc_dpio dpio.6: unknown SoC version
fsl_mc_dpio dpio.5: unknown SoC version
Fixes:
51da14e96e9b ("soc: fsl: dpio: configure cache stashing destination")
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220901052149.23873-2-matt@traverse.com.au'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Thu, 15 Sep 2022 14:25:19 +0000 (16:25 +0200)]
mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()
This is a stable-specific patch.
I botched the stable-specific rewrite of
commit
b67fbebd4cf98 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"):
As Hugh pointed out, unmap_region() actually operates on a list of VMAs,
and the variable "vma" merely points to the first VMA in that list.
So if we want to check whether any of the VMAs we're operating on is
PFNMAP or MIXEDMAP, we have to iterate through the list and check each VMA.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hu Xiaoying [Thu, 1 Sep 2022 04:57:37 +0000 (12:57 +0800)]
usb: storage: Add ASUS <0x0b05:0x1932> to IGNORE_UAS
[ Upstream commit
c61feaee68b9735be06f162bc046c7f1959efb0c ]
USB external storage device(0x0b05:1932), use gnome-disk-utility tools
to test usb write < 30MB/s.
if does not to load module of uas for this device, can increase the
write speed from 20MB/s to >40MB/s.
Suggested-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Hu Xiaoying <huxiaoying@kylinos.cn>
Link: https://lore.kernel.org/r/20220901045737.3438046-1-huxiaoying@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Mon, 29 Aug 2022 16:35:44 +0000 (18:35 +0200)]
platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes
[ Upstream commit
c3b82d26bc85f5fc2fef5ec8cce17c89633a55a8 ]
2 keymap fixes for the Acer Aspire One AOD270 and the same hardware
rebranded as Packard Bell Dot SC:
1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC,
this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping
for this.
2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate
input event with the "Video Bus" input device events. But on these devices
the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN
instead of using KE_IGNORE so that udev/hwdb can override it on these devs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yu Zhe [Thu, 25 Aug 2022 01:18:44 +0000 (09:18 +0800)]
perf/arm_pmu_platform: fix tests for platform_get_irq() failure
[ Upstream commit
6bb0d64c100091e131cd16710b62fda3319cd0af ]
The platform_get_irq() returns negative error codes. It can't actually
return zero.
Signed-off-by: Yu Zhe <yuzhe@nfschina.com>
Link: https://lore.kernel.org/r/20220825011844.8536-1-yuzhe@nfschina.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kurt Kanzenbach [Tue, 30 Aug 2022 16:34:48 +0000 (18:34 +0200)]
net: dsa: hellcreek: Print warning only once
[ Upstream commit
52267ce25f60f37ae40ccbca0b21328ebae5ae75 ]
In case the source port cannot be decoded, print the warning only once. This
still brings attention to the user and does not spam the logs at the same time.
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20220830163448.8921-1-kurt@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chengming Gui [Tue, 30 Aug 2022 08:33:01 +0000 (16:33 +0800)]
drm/amd/amdgpu: skip ucode loading if ucode_size == 0
[ Upstream commit
39c84b8e929dbd4f63be7e04bf1a2bcd92b44177 ]
Restrict the ucode loading check to avoid frontdoor loading error.
Signed-off-by: Chengming Gui <Jack.Gui@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maurizio Lombardi [Mon, 29 Aug 2022 12:40:30 +0000 (14:40 +0200)]
nvmet-tcp: fix unhandled tcp states in nvmet_tcp_state_change()
[ Upstream commit
478814a5584197fa1fb18377653626e3416e7cd6 ]
TCP_FIN_WAIT2 and TCP_LAST_ACK were not handled, the connection is closing
so we can ignore them and avoid printing the "unhandled state"
warning message.
[ 1298.852386] nvmet_tcp: queue 2 unhandled state 5
[ 1298.879112] nvmet_tcp: queue 7 unhandled state 5
[ 1298.884253] nvmet_tcp: queue 8 unhandled state 5
[ 1298.889475] nvmet_tcp: queue 9 unhandled state 5
v2: Do not call nvmet_tcp_schedule_release_queue(), just ignore
the fin_wait2 and last_ack states.
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Tulli [Mon, 29 Aug 2022 18:21:03 +0000 (11:21 -0700)]
Input: iforce - add support for Boeder Force Feedback Wheel
[ Upstream commit
9c9c71168f7979f3798b61c65b4530fbfbcf19d1 ]
Add a new iforce_device entry to support the Boeder Force Feedback Wheel
device.
Signed-off-by: Greg Tulli <greg.iforce@gmail.com>
Link: https://lore.kernel.org/r/3256420-c8ac-31b-8499-3c488a9880fd@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Li Qiong [Mon, 29 Aug 2022 07:12:59 +0000 (15:12 +0800)]
ieee802154: cc2520: add rc code in cc2520_tx()
[ Upstream commit
ffd7bdddaab193c38416fd5dd416d065517d266e ]
The rc code is 0 at the error path "status & CC2520_STATUS_TX_UNDERFLOW".
Assign rc code with '-EINVAL' at this error path to fix it.
Signed-off-by: Li Qiong <liqiong@nfschina.com>
Link: https://lore.kernel.org/r/20220829071259.18330-1-liqiong@nfschina.com
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Mon, 22 Aug 2022 04:10:25 +0000 (04:10 +0000)]
gpio: mockup: remove gpio debugfs when remove device
[ Upstream commit
303e6da99429510b1e4edf833afe90ac8542e747 ]
GPIO mockup debugfs is created in gpio_mockup_probe() but
forgot to remove when remove device. This patch add a devm
managed callback for removing them.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kai-Heng Feng [Fri, 26 Aug 2022 00:25:30 +0000 (08:25 +0800)]
tg3: Disable tg3 device on system reboot to avoid triggering AER
[ Upstream commit
2ca1c94ce0b65a2ce7512b718f3d8a0fe6224bca ]
Commit
d60cd06331a3 ("PM: ACPI: reboot: Use S5 for reboot") caused a
reboot hang on one Dell servers so the commit was reverted.
Someone managed to collect the AER log and it's caused by MSI:
[ 148.762067] ACPI: Preparing to enter system sleep state S5
[ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5
[ 148.803731] {1}[Hardware Error]: event severity: recoverable
[ 148.810191] {1}[Hardware Error]: Error 0, type: fatal
[ 148.816088] {1}[Hardware Error]: section_type: PCIe error
[ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point
[ 148.829026] {1}[Hardware Error]: version: 3.0
[ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010
[ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0
[ 148.847309] {1}[Hardware Error]: slot: 0
[ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00
[ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f
[ 148.865145] {1}[Hardware Error]: class_code: 020000
[ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000
[ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030
[ 148.886575] {1}[Hardware Error]: TLP Header:
40000001 0000030f 90028090 00000000
[ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000
[ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First)
[ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID
[ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030
[ 148.925558] tg3 0000:04:00.0: AER: TLP Header:
40000001 0000030f 90028090 00000000
The MSI is probably raised by incoming packets, so power down the device
and disable bus mastering to stop the traffic, as user confirmed this
approach works.
In addition to that, be extra safe and cancel reset task if it's running.
Cc: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/
BugLink: https://bugs.launchpad.net/bugs/1917471
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Even Xu [Thu, 4 Aug 2022 00:59:19 +0000 (08:59 +0800)]
hid: intel-ish-hid: ishtp: Fix ishtp client sending disordered message
[ Upstream commit
e1fa076706209cc447d7a2abd0843a18277e5ef7 ]
There is a timing issue captured during ishtp client sending stress tests.
It was observed during stress tests that ISH firmware is getting out of
ordered messages. This is a rare scenario as the current set of ISH client
drivers don't send much data to firmware. But this may not be the case
going forward.
When message size is bigger than IPC MTU, ishtp splits the message into
fragments and uses serialized async method to send message fragments.
The call stack:
ishtp_cl_send_msg_ipc->ipc_tx_callback(first fregment)->
ishtp_send_msg(with callback)->write_ipc_to_queue->
write_ipc_from_queue->callback->ipc_tx_callback(next fregment)......
When an ipc write complete interrupt is received, driver also calls
write_ipc_from_queue->ipc_tx_callback in ISR to start sending of next fragment.
Through ipc_tx_callback uses spin_lock to protect message splitting, as the
serialized sending method will call back to ipc_tx_callback again, so it doesn't
put sending under spin_lock, it causes driver cannot guarantee all fragments
be sent in order.
Considering this scenario:
ipc_tx_callback just finished a fragment splitting, and not call ishtp_send_msg
yet, there is a write complete interrupt happens, then ISR->write_ipc_from_queue
->ipc_tx_callback->ishtp_send_msg->write_ipc_to_queue......
Because ISR has higher exec priority than normal thread, this causes the new
fragment be sent out before previous fragment. This disordered message causes
invalid message to firmware.
The solution is, to send fragments synchronously:
Use ishtp_write_message writing fragments into tx queue directly one by one,
instead of ishtp_send_msg only writing one fragment with completion callback.
As no completion callback be used, so change ipc_tx_callback to ipc_tx_send.
Signed-off-by: Even Xu <even.xu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jason Wang [Thu, 4 Aug 2022 00:58:14 +0000 (08:58 +0800)]
HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
[ Upstream commit
94553f8a218540d676efbf3f7827ed493d1057cf ]
The double `like' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Krzysztof Kozlowski [Fri, 5 Aug 2022 07:55:03 +0000 (09:55 +0200)]
dt-bindings: iio: gyroscope: bosch,bmg160: correct number of pins
[ Upstream commit
767470209cedbe2cc72ba38d77c9f096d2c7694c ]
BMG160 has two interrupt pins to which interrupts can be freely mapped.
Correct the schema to express such case and fix warnings like:
qcom/msm8916-alcatel-idol347.dtb: gyroscope@68: interrupts: [[97, 1], [98, 1]] is too long
However the basic issue still persists - the interrupts should come in a
defined order.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220805075503.16983-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rob Clark [Sun, 7 Aug 2022 16:09:01 +0000 (09:09 -0700)]
drm/msm/rd: Fix FIFO-full deadlock
[ Upstream commit
174974d8463b77c2b4065e98513adb204e64de7d ]
If the previous thing cat'ing $debugfs/rd left the FIFO full, then
subsequent open could deadlock in rd_write() (because open is blocked,
not giving a chance for read() to consume any data in the FIFO). Also
it is generally a good idea to clear out old data from the FIFO.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/496706/
Link: https://lore.kernel.org/r/20220807160901.2353471-2-robdclark@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maximilian Luz [Wed, 10 Aug 2022 14:01:33 +0000 (16:01 +0200)]
platform/surface: aggregator_registry: Add support for Surface Laptop Go 2
[ Upstream commit
84b8e403435c8fb94b872309673764a447961e00 ]
The Surface Laptop Go 2 seems to have the same SAM client devices as the
Surface Laptop Go 1, so re-use its node group.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20220810140133.99087-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ondrej Jirman [Thu, 11 Aug 2022 23:16:54 +0000 (16:16 -0700)]
Input: goodix - add support for GT1158
[ Upstream commit
425fe4709c76e35f93f4c0e50240f0b61b2a2e54 ]
This controller is used by PinePhone and PinePhone Pro. Support for
the PinePhone Pro will be added in a later patch set.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Jarrah Gosbell <kernel@undef.tools>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220809091200.290492-1-kernel@undef.tools
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Baolu [Tue, 23 Aug 2022 06:15:54 +0000 (14:15 +0800)]
iommu/vt-d: Fix kdump kernels boot failure with scalable mode
[ Upstream commit
0c5f6c0d8201a809a6585b07b6263e9db2c874a3 ]
The translation table copying code for kdump kernels is currently based
on the extended root/context entry formats of ECS mode defined in older
VT-d v2.5, and doesn't handle the scalable mode formats. This causes
the kexec capture kernel boot failure with DMAR faults if the IOMMU was
enabled in scalable mode by the previous kernel.
The ECS mode has already been deprecated by the VT-d spec since v3.0 and
Intel IOMMU driver doesn't support this mode as there's no real hardware
implementation. Hence this converts ECS checking in copying table code
into scalable mode.
The existing copying code consumes a bit in the context entry as a mark
of copied entry. It needs to work for the old format as well as for the
extended context entries. As it's hard to find such a common bit for both
legacy and scalable mode context entries. This replaces it with a per-
IOMMU bitmap.
Fixes:
7373a8cc38197 ("iommu/vt-d: Setup context and enable RID2PASID support")
Cc: stable@vger.kernel.org
Reported-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Wen Jin <wen.jin@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20220817011035.3250131-1-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brian Norris [Sat, 27 Aug 2022 00:44:17 +0000 (17:44 -0700)]
tracefs: Only clobber mode/uid/gid on remount if asked
[ Upstream commit
47311db8e8f33011d90dee76b39c8886120cdda4 ]
Users may have explicitly configured their tracefs permissions; we
shouldn't overwrite those just because a second mount appeared.
Only clobber if the options were provided at mount time.
Note: the previous behavior was especially surprising in the presence of
automounted /sys/kernel/debug/tracing/.
Existing behavior:
## Pre-existing status: tracefs is 0755.
# stat -c '%A' /sys/kernel/tracing/
drwxr-xr-x
## (Re)trigger the automount.
# umount /sys/kernel/debug/tracing
# stat -c '%A' /sys/kernel/debug/tracing/.
drwx------
## Unexpected: the automount changed mode for other mount instances.
# stat -c '%A' /sys/kernel/tracing/
drwx------
New behavior (after this change):
## Pre-existing status: tracefs is 0755.
# stat -c '%A' /sys/kernel/tracing/
drwxr-xr-x
## (Re)trigger the automount.
# umount /sys/kernel/debug/tracing
# stat -c '%A' /sys/kernel/debug/tracing/.
drwxr-xr-x
## Expected: the automount does not change other mount instances.
# stat -c '%A' /sys/kernel/tracing/
drwxr-xr-x
Link: https://lkml.kernel.org/r/20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid
Cc: stable@vger.kernel.org
Fixes:
4282d60689d4f ("tracefs: Add new tracefs file system")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yipeng Zou [Thu, 1 Sep 2022 10:45:14 +0000 (18:45 +0800)]
tracing: hold caller_addr to hardirq_{enable,disable}_ip
[ Upstream commit
54c3931957f6a6194d5972eccc36d052964b2abe ]
Currently, The arguments passing to lockdep_hardirqs_{on,off} was fixed
in CALLER_ADDR0.
The function trace_hardirqs_on_caller should have been intended to use
caller_addr to represent the address that caller wants to be traced.
For example, lockdep log in riscv showing the last {enabled,disabled} at
__trace_hardirqs_{on,off} all the time(if called by):
[ 57.853175] hardirqs last enabled at (2519): __trace_hardirqs_on+0xc/0x14
[ 57.853848] hardirqs last disabled at (2520): __trace_hardirqs_off+0xc/0x14
After use trace_hardirqs_xx_caller, we can get more effective information:
[ 53.781428] hardirqs last enabled at (2595): restore_all+0xe/0x66
[ 53.782185] hardirqs last disabled at (2596): ret_from_exception+0xa/0x10
Link: https://lkml.kernel.org/r/20220901104515.135162-2-zouyipeng@huawei.com
Cc: stable@vger.kernel.org
Fixes:
c3bc8fd637a96 ("tracing: Centralize preemptirq tracepoints and unify their usage")
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Borislav Petkov [Wed, 23 Mar 2022 19:02:41 +0000 (20:02 +0100)]
task_stack, x86/cea: Force-inline stack helpers
[ Upstream commit
e87f4152e542610d0b4c6c8548964a68a59d2040 ]
Force-inline two stack helpers to fix the following objtool warnings:
vmlinux.o: warning: objtool: in_task_stack()+0xc: call to task_stack_page() leaves .noinstr.text section
vmlinux.o: warning: objtool: in_entry_stack()+0x10: call to cpu_entry_stack() leaves .noinstr.text section
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220324183607.31717-2-bp@alien8.de
Stable-dep-of:
54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Borislav Petkov [Wed, 23 Mar 2022 22:24:12 +0000 (23:24 +0100)]
x86/mm: Force-inline __phys_addr_nodebug()
[ Upstream commit
ace1a98519270c586c0d4179419292df67441cd1 ]
Fix:
vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0x8b: call to __phys_addr_nodebug() leaves .noinstr.text section
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220324183607.31717-4-bp@alien8.de
Stable-dep-of:
54c3931957f6 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip")
Signed-off-by: Sasha Levin <sashal@kernel.org>