- Sep 28, 2022
-
-
David Leadbeater authored
[ Upstream commit e8d5dfd1 ] CTCP messages should only be at the start of an IRC message, not anywhere within it. While the helper only decodes packes in the ORIGINAL direction, its possible to make a client send a CTCP message back by empedding one into a PING request. As-is, thats enough to make the helper believe that it saw a CTCP message. Fixes: 869f37d8 ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port") Signed-off-by:
David Leadbeater <dgl@dgl.cx> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Igor Ryzhov authored
[ Upstream commit 39aebede ] ct_sip_next_header and ct_sip_get_header return an absolute value of matchoff, not a shift from current dataoff. So dataoff should be assigned matchoff, not incremented by it. This issue can be seen in the scenario when there are multiple Contact headers and the first one is using a hostname and other headers use IP addresses. In this case, ct_sip_walk_headers will work as follows: The first ct_sip_get_header call to will find the first Contact header but will return -1 as the header uses a hostname. But matchoff will be changed to the offset of this header. After that, dataoff should be set to matchoff, so that the next ct_sip_get_header call find the next Contact header. But instead of assigning dataoff to matchoff, it is incremented by it, which is not correct, as matchoff is an absolute value of the offset. So on the next call to the ct_sip_get_header, dataoff will be incorrect, and the next Contact header may not be found at all. Fixes: 05e3ced2 ("[NETFILTER]: nf_conntrack_sip: introduce SIP-URI parsing helper") Signed-off-by:
Igor Ryzhov <iryzhov@nfware.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabio Estevam authored
[ Upstream commit a994b34b ] The 'enable-active-low' property is not a valid one. Only 'enable-active-high' is valid, and when this property is absent the gpio regulator will act as active low by default. Remove the invalid 'enable-active-low' property. Fixes: 2c66fc34 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by:
Fabio Estevam <festevam@denx.de> Link: https://lore.kernel.org/r/20220827175140.1696699-1-festevam@denx.de Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
zain wang authored
[ Upstream commit 8123437c ] We've found the AUX channel to be less reliable with PCLK_EDP at a higher rate (typically 25 MHz). This is especially important on systems with PSR-enabled panels (like Gru-Kevin), since we make heavy, constant use of AUX. According to Rockchip, using any rate other than 24 MHz can cause "problems between syncing the PHY an PCLK", which leads to all sorts of unreliabilities around register operations. Fixes: d67a38c5 ("arm64: dts: rockchip: move core edp from rk3399-kevin to shared chromebook") Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
zain wang <wzz@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220830131212.v2.1.I98d30623f13b785ca77094d0c0fd4339550553b6@changeid Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Brian Norris authored
[ Upstream commit e5467359 ] The Gru-Bob board does not have a pull-up resistor on its WLAN_HOST_WAKE# pin, but Kevin does. The production/vendor kernel specified the pin configuration correctly as a pull-up, but this didn't get ported correctly to upstream. This means Bob's WLAN_HOST_WAKE# pin is floating, causing inconsistent wakeup behavior. Note that bt_host_wake_l has a similar dynamic, but apparently the upstream choice was to redundantly configure both internal and external pull-up on Kevin (see the "Kevin has an external pull up" comment in rk3399-gru.dtsi). This doesn't cause any functional problem, although it's perhaps wasteful. Fixes: 8559bbee ("arm64: dts: rockchip: add Google Bob") Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220822164453.1.I75c57b48b0873766ec993bdfb7bc1e63da5a1637@changeid Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chao Yu authored
commit 7e9c323c upstream. In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 Cc: <stable@kernel.org> Fixes: 81819f0f ("SLUB core") Reported-by:
<syzbot+81684812ea68216e08c5@syzkaller.appspotmail.com> Reviewed-by:
Muchun Song <songmuchun@bytedance.com> Reviewed-by:
Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by:
Chao Yu <chao.yu@oppo.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ard Biesheuvel authored
commit 5f56a74c upstream. We currently check the MokSBState variable to decide whether we should treat UEFI secure boot as being disabled, even if the firmware thinks otherwise. This is used by shim to indicate that it is not checking signatures on boot images. In the kernel, we use this to relax lockdown policies. However, in cases where shim is not even being used, we don't want this variable to interfere with lockdown, given that the variable may be non-volatile and therefore persist across a reboot. This means setting it once will persistently disable lockdown checks on a given system. So switch to the mirrored version of this variable, called MokSBStateRT, which is supposed to be volatile, and this is something we can check. Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Callum Osmotherly authored
commit 1885ff13 upstream. Just as with the 5570 (and the other Dell laptops), this enables the two subwoofer speakers on the Dell Precision 5530 together with the main ones, significantly increasing the audio quality. I've tested this myself on a 5530 and can confirm it's working as expected. Signed-off-by:
Callum Osmotherly <callum.osmotherly@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YyMjQO3mhyXlMbCf@piranha Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luke D. Jones authored
commit ba1f8180 upstream. The ASUS G15 2022 (GA503R) series laptop has the same node-to-DAC pairs as early models and the G14, this includes bass speakers which are by default mapped incorrectly to the 0x06 node. Add a quirk to use the same DAC pairs as the G14. Signed-off-by:
Luke D. Jones <luke@ljones.dev> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220915080921.35563-4-luke@ljones.dev Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luke D. Jones authored
commit bc2c2354 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 authored
commit c611e659 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 authored
commit b16c8f22 upstream. A few entries have been mistakenly inserted in wrong positions without considering the SSID ordering. Place them at right positions. Fixes: b7557267 ("ALSA: hda/realtek: Add quirk for ASUS GA402") Fixes: 94db9cc8 ("ALSA: hda/realtek: Add quirk for ASUS GU603") Fixes: 739d0959 ("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>
-
huangwenhui authored
commit cbcdf8c4 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 authored
commit 4d40ceef 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 authored
commit 3c4d8c24 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>
-
jerry meng authored
commit d640c4cb 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(殷张成) authored
commit f8f67eff 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 authored
commit 766a96dc upstream. A recent commit added an invalid RST expression to a kerneldoc comment in hub.c. The fix is trivial. Fixes: 9c6d7788 ("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>
-
Greg Kroah-Hartman authored
[ Upstream commit fe0a2ac7 ] This reverts commit 8cb339f1 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: 8cb339f1 ("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 authored
[ Upstream commit 58bfe7d8 ] This reverts commit 3d5f7094 . 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: 3d5f7094 ("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>
-
Pawel Laszczak authored
[ Upstream commit b46a6b09 ] ISO OUT endpoint is enabled during queuing first usb request in transfer ring and disabled when TRBERR is reported by controller. After TRBERR and before next transfer added to TR driver must again reenable endpoint but does not. To solve this issue during processing TRBERR event driver must set the flag EP_UPDATE_EP_TRBADDR in priv_ep->flags field. Fixes: 7733f6c3 ("usb: cdns3: Add Cadence USB3 DRD Driver") cc: <stable@vger.kernel.org> Acked-by:
Peter Chen <peter.chen@kernel.org> Signed-off-by:
Pawel Laszczak <pawell@cadence.com> Link: https://lore.kernel.org/r/20220825062137.5766-1-pawell@cadence.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Piyush Mehta authored
[ Upstream commit 8cb339f1 ] 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: 1f7c5166 ("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 authored
[ Upstream commit 3d5f7094 ] 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>
-
Sergiu Moga authored
[ Upstream commit 692a8ebc ] 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: e8faff73 ("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 authored
[ Upstream commit 60efd051 ] 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: 692a8ebc ("tty: serial: atmel: Preserve previous USART mode if RS485 disabled") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Codrin.Ciubotariu@microchip.com authored
[ Upstream commit 477b8383 ] At this moment, TXEMPTY is checked before sending data on RS485 and ISO7816 modes. However, TXEMPTY is risen when FIFO (if used) or the Transmit Shift Register are empty, even though TXRDY might be up and controller is able to receive data. Since the controller sends data only when TXEMPTY is ready, on RS485, when DMA is not used, the RTS pin is driven low after each byte. With this patch, the characters will be transmitted when TXRDY is up and so, RTS pin will remain high between bytes. The performance improvement on RS485 is about 8% with a baudrate of 300. Signed-off-by:
Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Acked-by:
Richard Genoud <richard.genoud@gmail.com> Link: https://lore.kernel.org/r/20200107111656.26308-1-codrin.ciubotariu@microchip.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 692a8ebc ("tty: serial: atmel: Preserve previous USART mode if RS485 disabled") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Siddh Raman Pant authored
[ Upstream commit 60deb9f1 ] ieee80211_scan_rx() tries to access scan_req->flags after a null check, but a UAF is observed when the scan is completed and __ieee80211_scan_completed() executes, which then calls cfg80211_scan_done() leading to the freeing of scan_req. Since scan_req is rcu_dereference()'d, prevent the racing in __ieee80211_scan_completed() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section before we call cfg80211_scan_done(). Cc: stable@vger.kernel.org Link: https://syzkaller.appspot.com/bug?extid=f9acff9bf08a845f225d Reported-by:
<syzbot+f9acff9bf08a845f225d@syzkaller.appspotmail.com> Suggested-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Siddh Raman Pant <code@siddh.me> Link: https://lore.kernel.org/r/20220819200340.34826-1-code@siddh.me Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ikjoon Jang authored
[ Upstream commit 54801195 ] Currently xhci-mtk needs software-managed bandwidth allocation for periodic endpoints, it allocates the microframe index for the first start-split packet for each endpoint. As this index allocation logic should avoid the conflicts with other full/low-speed periodic endpoints, it uses the worst case byte budgets on high-speed bus bandwidth For example, for an isochronos IN endpoint with 192 bytes budget, it will consume the whole 4 u-frames(188 * 4) while the actual full-speed bus budget should be just 192bytes. This patch changes the low/full-speed bandwidth allocation logic to use "approximate" best case budget for lower speed bandwidth management. For the same endpoint from the above example, the approximate best case budget is now reduced to (188 * 2) bytes. Without this patch, many usb audio headsets with 3 interfaces (audio input, audio output, and HID) cannot be configured on xhci-mtk. Signed-off-by:
Ikjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/20210805133937.1.Ia8174b875bc926c12ce427a5a1415dea31cc35ae@changeid Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit d3997fce ] This patch is used to relax bandwidth schedule by allowing multiple Start-Split in the same microframe. Reviewed-and-Tested-by:
Ikjoon Jang <ikjn@chromium.org> Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1623995165-25759-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 54801195 ("usb: xhci-mtk: relax TT periodic bandwidth allocation") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit ccda8c22 ] This is used to provide more information about which case causes bandwidth schedule failure. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/9771f44093053b581e9c4be4b7fb68d9fcecad08.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 54801195 ("usb: xhci-mtk: relax TT periodic bandwidth allocation") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit 338af695 ] Extract a function to load/unload bandwidth info, and remove a dummy check of TT offset. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/6fbc000756a4a4a7efbce651b785fee7561becb6.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 54801195 ("usb: xhci-mtk: relax TT periodic bandwidth allocation") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit 4a56adf4 ] It's clearer to use @sch_tt to check whether need do TT schedule, no function is changed. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/324a76782ccaf857a8f01f67aee435e8ec7d0e28.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 54801195 ("usb: xhci-mtk: relax TT periodic bandwidth allocation") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit 1bf661da ] In USB2 Spec: "11.18.5 TT Response Generation In general, there will be two (or more) complete-split transactions scheduled for a periodic endpoint. However, for interrupt endpoints, the maximum size of the full-/low-speed transaction guarantees that it can never require more than two complete-split transactions. Two complete-split transactions are only required when the transaction spans a microframe boundary." Due to the maxp is 64, and less then 188 (at most in one microframe), seems never span boundary, so use only one CS for FS/LS interrupt transfer, this will save some bandwidth. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/5b9ff09f53d23cf9e5c5437db4ffc18b798bf60c.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 54801195 ("usb: xhci-mtk: relax TT periodic bandwidth allocation") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit 7c986fbc ] Tune the boundary for FS/LS ESIT due to CS: For ISOC out-ep, the controller starts transfer data after the first SS; for others, the data is already transferred before the last CS. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/49e5a269a47984f3126a70c3fb471b0c2874b8c2.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 54801195 ("usb: xhci-mtk: relax TT periodic bandwidth allocation") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Wesley Cheng authored
[ Upstream commit 040f2dbd ] 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 69e131d1 ("usb: dwc3: gadget: Prevent repeat pullup()") Fixes: 77adb8bd ("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 authored
[ Upstream commit 8f8034f4 ] 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: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Thinh Nguyen authored
[ Upstream commit 861c010a ] 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: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Thinh Nguyen authored
[ Upstream commit 69e131d1 ] 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: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Wesley Cheng authored
[ Upstream commit 0066472d ] 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: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Wesley Cheng authored
[ Upstream commit 8217f07a ] 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: 040f2dbd ("usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-