Message ID | 20230628-mtk-usb-v1-1-3c5b2ea3d6b9@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp9211871vqr; Wed, 28 Jun 2023 14:12:28 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4YuxU7WvIP7bEXFATwZFi9InsarLJ6iJUvrpl6T5y/xxF1iLa2eigzOr3UCYyPPIPfErCM X-Received: by 2002:a17:906:74da:b0:976:50a4:ac40 with SMTP id z26-20020a17090674da00b0097650a4ac40mr29571308ejl.0.1687986748501; Wed, 28 Jun 2023 14:12:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687986748; cv=none; d=google.com; s=arc-20160816; b=X5lULYjtBdxsYXOAC0I+//h3QuRrA/wpNCXo/uQGos9+k3jHx45Qy0lL7vepj/AIZI eCf7blVL/OCn6VdENEUcpG6Xn8p+bHEds6/tNOReDlhPc+xkz/9HLy/oDXKNZ4loC6+U 229rMBWeCOpLrejk0qa2d5iyf9ouAwHEfklJFD6nupwV9pSiCUmdVPZ/aSxlDlS7bDzu 2I/47FlL0/FpwWwoNU5KJvsf881Ke/kHcZiDZFoA/YOMejshZ00+5gYEyKXv3xedq7Xj lAvq56HKaW9Xp6WWPKUyIC7+d8GDQDb5HjgvGQ+0LvYqX89LnEUhJ+7YyqhYsEWSNWVA YEUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=UsCShzZlSVVvcFLIXVSwDFqSlgHSwDOBYWNFsuS3DSk=; fh=qDl/W3wQI8JSjdaWI/kZSP6OfAD3hRQC88NOk4kJwXY=; b=kUOShsMoOdgDlT012e8ACTyqozgYOLHaRZzQtjdwCG+dVjG9fnYjr5izOqFo4nscRM SEaFmXruYsUu1bX8EinV6iQXjfLEwh8LVlLO+00QGQ0uX/ed/VC5uc3A+vhid0Cl5tcd gJEuCrKDnNrNFn7ji8c2rlEwwR4+U8EDVxL7iJjQcPY8rm4+2ttgVVqgDGFc4YU0o/pa kgEOAhqHOJJWNpJTPuxlUtnQw/vy+ozan7uJs9ZSuN+YuUDwRI0Poj/pNxJMvoAqBdzs I5qXWp2js03yg1sSHlBwwTIwzuSef1V+eV8iE78VLmVhW2p+MstpoiHE91rBFp/RnEIx W33Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gf1z7fvd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ci22-20020a170906c35600b0098e1627c0e6si5207478ejb.789.2023.06.28.14.12.01; Wed, 28 Jun 2023 14:12:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gf1z7fvd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231882AbjF1VBA (ORCPT <rfc822;ivan.orlov0322@gmail.com> + 99 others); Wed, 28 Jun 2023 17:01:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231324AbjF1VA6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 28 Jun 2023 17:00:58 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C99219B0 for <linux-kernel@vger.kernel.org>; Wed, 28 Jun 2023 14:00:56 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5149aafef44so63040a12.0 for <linux-kernel@vger.kernel.org>; Wed, 28 Jun 2023 14:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1687986054; x=1690578054; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=UsCShzZlSVVvcFLIXVSwDFqSlgHSwDOBYWNFsuS3DSk=; b=gf1z7fvdf39g4KKD/BiXeAwUKU9fw2x0hEBrNDJJyNbmNaK3snqEk5nWKnsdpiXJU9 rUYr++ERpnuEOlbDGNb4S79qtgq9GIZU3n/Qi6FW0W7le8YRHwHuzpHLVJBoY/KvP7vK MmGCrMty3QMhNcwlzFfy2hN6mNU1eA+Ez6H2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687986054; x=1690578054; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UsCShzZlSVVvcFLIXVSwDFqSlgHSwDOBYWNFsuS3DSk=; b=DpB5Dm5ngikxNaN0TFmKuItPpDwViN9VzL3cMzbbIrOc8HyHBKri0dS4QWeWEnvxsL +53ImdvFH3k4ySpjv842rXw60eg2n//eGuVta1btIMnNMgCR2D5nY9PbjR4ZcTv5hYKb nQ+tJ4Bmmq3XVli2mvjukyX+65QTl3dTcqS2JkTb6CpB9SbRHbbRcHOyrjfCIQ8UTHSf b2PO0a1YaXtiSYvdGfzh1VlH1607lyKm+X85fM6VNZJt5oJmuDT8fnKdGlUZcsbwq6DE t9T2gGvIi0H1M1Pee+sgt7LIKkMPZrEAZyfQGpM0NUmNSodBUjaPGN0qS+wCG8HdQEwO 2oNw== X-Gm-Message-State: AC+VfDxmxnILSQH03wN01i+5957K76nJQfCF8fHY7Iolc5ravXUM6+VD /5ZxrZzSq/UgY6bvGOjjVC0AL9TcL1O/4SWWDMvEq1qW X-Received: by 2002:aa7:d68c:0:b0:51d:ad2b:3700 with SMTP id d12-20020aa7d68c000000b0051dad2b3700mr3574181edr.26.1687986054579; Wed, 28 Jun 2023 14:00:54 -0700 (PDT) Received: from alco.roam.corp.google.com (80.71.134.83.ipv4.parknet.dk. [80.71.134.83]) by smtp.gmail.com with ESMTPSA id n3-20020a05640206c300b0051d9246f963sm4308203edy.9.2023.06.28.14.00.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 14:00:54 -0700 (PDT) From: Ricardo Ribalda <ribalda@chromium.org> Date: Wed, 28 Jun 2023 23:00:49 +0200 Subject: [PATCH] usb: xhci-mtk: set the dma max_seg_size MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230628-mtk-usb-v1-1-3c5b2ea3d6b9@chromium.org> X-B4-Tracking: v=1; b=H4sIAICfnGQC/x2MQQqDQAwAvyI5G9hu1bZ+pfSw0WwNtVvZVBHEv xs8zjDMBspZWKEtNsi8iMovGVzKArohpDej9Mbgnb+6xt/x+//grIQUnasfsamov4HVFJSRckj dYH2ax9HklDnKeu6fr30/ANYVTB1uAAAA To: Chunfeng Yun <chunfeng.yun@mediatek.com>, Mathias Nyman <mathias.nyman@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Ricardo Ribalda <ribalda@chromium.org>, Ricardo Ribalda Delgado <ribalda@chromium.org> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=7476; i=ribalda@chromium.org; h=from:subject:message-id; bh=06OAba3Q1UxsiXAo8+me3vjx/v7V85FJ1TwyHzGclyw=; b=owEBbQKS/ZANAwAKAdE30T7POsSIAcsmYgBknJ+DwpST5JpzX41iapqQoctiKSPyHtn6bPLuP tz8yhw2Zs6JAjMEAAEKAB0WIQREDzjr+/4oCDLSsx7RN9E+zzrEiAUCZJyfgwAKCRDRN9E+zzrE iChSD/9FF2FMrwkZeGzhZggbNH3e4Uk6Jx8vNjqMwG2i3yk/fNMJ2x/7g/aFczl3+ovGLOTr9lq 2H5LZFjauIMfxz667H4hEojghWPx96lqu3zOyXN79qnHAJevPITGEYQR99pPowS74KM21fbnVHq wWzZP4hlshEqZJDBQrv4GrcM+ysEnlmMKPHOwrYq+4qdeaRNPVI7WY1k4T4UQCS9SDDm+BGgL68 GjsFsQbsVyo8/Q+b7aWZkfRCm7rBmupn0LhuWX2l2SHmFfhPnDCj/we3hZI02ij2FgqY2erE1C3 Rk5wWC3iYzZpDTFYp4KXnVyApVzMWDClSSvafno4C83DaV1zcKFyUPMkpwqaRg4dK5k0J9HskiA prA2MxlMEMLX+t2OaeS28tVWIbsChCz+ydUYl4+WyvQ853sW9D3njCQdXZwGzEdy188iCGPVIwt AzbG+Nz/7vfgtvYiT44elH6q7DKnbjX4KLfetIlqglgOOqlX5yHlKPQMGQgKCsc4gAxWqO6KgCg DuaxYymgoYrpmro+yAaB0Oh2T9kHD4KcJto4wvf3+miqBMQ5iadq0R5wyrUADPL92aMrNtTI4Oz vQuoxdZUXVNUNwlRJRg/1v/vj6Q1d1V3ZP6WSboXMzbqBOmG7m52RovcyDOfL/3ODVHwamkQLEK AuvkTtlkdNIPPeQ== X-Developer-Key: i=ribalda@chromium.org; a=openpgp; fpr=9EC3BB66E2FC129A6F90B39556A0D81F9F782DA9 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769982256133471872?= X-GMAIL-MSGID: =?utf-8?q?1769982393174357311?= |
Series |
usb: xhci-mtk: set the dma max_seg_size
|
|
Commit Message
Ricardo Ribalda
June 28, 2023, 9 p.m. UTC
Allow devices to have dma operations beyond 64K, and avoid warnings such as: DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> --- Fix warnings such as: [ 451.089443] ------------[ cut here ]------------ [ 451.089498] DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] [ 451.089617] WARNING: CPU: 7 PID: 14227 at kernel/dma/debug.c:1163 debug_dma_map_sg+0x5bc/0x950 [ 451.089674] Modules linked in: xfrm_interface tun hci_vhci bridge stp llc veth xt_cgroup xt_MASQUERADE uinput rfcomm ip6table_nat fuse 8021q algif_hash algif_skcipher af_alg r8153_ecm cdc_ether usbnet r8152 mii mtk_vcodec_dec_hw mt7921s mt76_sdio mt7921_common mt76_connac_lib mt76 uvcvideo videobuf2_vmalloc mtk_vcodec_dec v4l2_h264 mtk_vcodec_enc mtk_jpeg v4l2_vp9 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 btmtksdio videobuf2_common mtk_vcodec_common btmtk mac80211 snd_sof_mt8186 snd_sof_xtensa_dsp snd_sof_of snd_sof snd_sof_utils mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi hid_rmi rmi_core serio bluetooth ecdh_generic ecc cfg80211 lzo_rle lzo_compress zram joydev [ 451.090285] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 [ 451.090333] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) [ 451.090356] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 451.090401] pc : debug_dma_map_sg+0x5bc/0x950 [ 451.090433] lr : debug_dma_map_sg+0x5bc/0x950 [ 451.090462] sp : ffffffc01fdd75e0 [ 451.090479] x29: ffffffc01fdd7640 x28: ffffff80c1280300 x27: 0000000000010000 [ 451.090531] x26: ffffff80c1ec9600 x25: 1ffffff01a749501 x24: ffffff80d3a4a800 [ 451.090581] x23: dfffffc000000000 x22: ffffff80d3a4a80c x21: ffffffc00aae5740 [ 451.090631] x20: ffffffffffffffff x19: ffffff80d3a4a810 x18: 0000000000000000 [ 451.090680] x17: 64206e6168742072 x16: 65676e6f6c20746e x15: 656d676573206773 [ 451.090731] x14: 20676e697070616d x13: 0000000000000001 x12: 0000000000000001 [ 451.090779] x11: 0000000000000000 x10: 0000000000040000 x9 : 3c6fd66e79e32400 [ 451.090828] x8 : 3c6fd66e79e32400 x7 : 0000000000000001 x6 : 0000000000000001 [ 451.090877] x5 : ffffffc01fdd7158 x4 : ffffffc00b64e2a0 x3 : ffffffc008f92adc [ 451.090926] x2 : 0000000100000000 x1 : ffffff8057afd940 x0 : 000000000000006f [ 451.090976] Call trace: [ 451.090994] debug_dma_map_sg+0x5bc/0x950 [ 451.091026] dma_alloc_noncontiguous+0x2f4/0x404 [ 451.091060] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.091150] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.091228] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.091305] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.091379] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] [ 451.091446] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] [ 451.091507] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] [ 451.091555] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.091631] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.091705] v4l_streamon+0x74/0xa8 [ 451.091738] __video_do_ioctl+0x90c/0xa40 [ 451.091769] video_usercopy+0xa44/0x1ef8 [ 451.091799] video_ioctl2+0x44/0x58 [ 451.091830] v4l2_ioctl+0x138/0x164 [ 451.091860] __arm64_sys_ioctl+0x154/0x1d0 [ 451.091892] invoke_syscall+0x98/0x278 [ 451.091923] el0_svc_common+0x214/0x274 [ 451.091953] do_el0_svc+0x9c/0x19c [ 451.091982] el0_svc+0x5c/0xc0 [ 451.092013] el0t_64_sync_handler+0x78/0x108 [ 451.092045] el0t_64_sync+0x1a4/0x1a8 [ 451.092081] Kernel panic - not syncing: kernel: panic_on_warn set ... [ 451.092103] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 [ 451.092148] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) [ 451.092171] Call trace: [ 451.092186] dump_backtrace+0x0/0x4e8 [ 451.092219] show_stack+0x34/0x44 [ 451.092247] dump_stack_lvl+0xdc/0x11c [ 451.092278] dump_stack+0x1c/0x48 [ 451.092307] panic+0x2a4/0x7b8 [ 451.092335] check_panic_on_warn+0xb8/0x104 [ 451.092369] __warn+0x16c/0x230 [ 451.092399] report_bug+0x160/0x280 [ 451.092432] bug_handler+0x48/0xb8 [ 451.092466] call_break_hook+0x180/0x1b4 [ 451.092498] brk_handler+0x30/0xbc [ 451.092529] do_debug_exception+0x16c/0x31c [ 451.092563] el1_dbg+0x64/0x80 [ 451.092592] el1h_64_sync_handler+0x70/0xb4 [ 451.092624] el1h_64_sync+0x7c/0x80 [ 451.092653] debug_dma_map_sg+0x5bc/0x950 [ 451.092685] dma_alloc_noncontiguous+0x2f4/0x404 [ 451.092717] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.092794] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.092868] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.092942] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.093015] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] [ 451.093079] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] [ 451.093139] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] [ 451.093187] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.093261] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] [ 451.093334] v4l_streamon+0x74/0xa8 [ 451.093366] __video_do_ioctl+0x90c/0xa40 [ 451.093398] video_usercopy+0xa44/0x1ef8 [ 451.093428] video_ioctl2+0x44/0x58 [ 451.093457] v4l2_ioctl+0x138/0x164 [ 451.093487] __arm64_sys_ioctl+0x154/0x1d0 [ 451.093518] invoke_syscall+0x98/0x278 [ 451.093548] el0_svc_common+0x214/0x274 [ 451.093578] do_el0_svc+0x9c/0x19c [ 451.093607] el0_svc+0x5c/0xc0 [ 451.093637] el0t_64_sync_handler+0x78/0x108 [ 451.093669] el0t_64_sync+0x1a4/0x1a8 [ 451.093701] SMP: stopping secondary CPUs [ 451.093777] Kernel Offset: disabled [ 451.093797] CPU features: 0xc00181c1,a3300e42 [ 451.093822] Memory Limit: none Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org> --- drivers/usb/host/xhci-mtk.c | 2 ++ 1 file changed, 2 insertions(+) --- base-commit: 1b2c92a1cb2469d8c0079dbf496ab86e22e1cb7c change-id: 20230628-mtk-usb-bf0059f64bd7 Best regards,
Comments
On Wed, Jun 28, 2023 at 11:04:20PM +0200, Ricardo Ribalda wrote: > On Wed, 28 Jun 2023 at 23:00, Ricardo Ribalda <ribalda@chromium.org> wrote: > > > > Allow devices to have dma operations beyond 64K, and avoid warnings such > > as: > > > > DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > Reported-by: Zubin Mithra <zsm@chromium.org> Should this be cc'd to stable@ as well? Tested-by: Zubin Mithra <zsm@chromium.org> > > --- > > Fix warnings such as: > > > > [ 451.089443] ------------[ cut here ]------------ > > [ 451.089498] DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > [ 451.089617] WARNING: CPU: 7 PID: 14227 at kernel/dma/debug.c:1163 debug_dma_map_sg+0x5bc/0x950 > > [ 451.089674] Modules linked in: xfrm_interface tun hci_vhci bridge stp llc veth xt_cgroup xt_MASQUERADE uinput rfcomm ip6table_nat fuse 8021q algif_hash algif_skcipher af_alg r8153_ecm cdc_ether usbnet r8152 mii mtk_vcodec_dec_hw mt7921s mt76_sdio mt7921_common mt76_connac_lib mt76 uvcvideo videobuf2_vmalloc mtk_vcodec_dec v4l2_h264 mtk_vcodec_enc mtk_jpeg v4l2_vp9 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 btmtksdio videobuf2_common mtk_vcodec_common btmtk mac80211 snd_sof_mt8186 snd_sof_xtensa_dsp snd_sof_of snd_sof snd_sof_utils mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi hid_rmi rmi_core serio bluetooth ecdh_generic ecc cfg80211 lzo_rle lzo_compress zram joydev > > [ 451.090285] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > > [ 451.090333] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) > > [ 451.090356] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > [ 451.090401] pc : debug_dma_map_sg+0x5bc/0x950 > > [ 451.090433] lr : debug_dma_map_sg+0x5bc/0x950 > > [ 451.090462] sp : ffffffc01fdd75e0 > > [ 451.090479] x29: ffffffc01fdd7640 x28: ffffff80c1280300 x27: 0000000000010000 > > [ 451.090531] x26: ffffff80c1ec9600 x25: 1ffffff01a749501 x24: ffffff80d3a4a800 > > [ 451.090581] x23: dfffffc000000000 x22: ffffff80d3a4a80c x21: ffffffc00aae5740 > > [ 451.090631] x20: ffffffffffffffff x19: ffffff80d3a4a810 x18: 0000000000000000 > > [ 451.090680] x17: 64206e6168742072 x16: 65676e6f6c20746e x15: 656d676573206773 > > [ 451.090731] x14: 20676e697070616d x13: 0000000000000001 x12: 0000000000000001 > > [ 451.090779] x11: 0000000000000000 x10: 0000000000040000 x9 : 3c6fd66e79e32400 > > [ 451.090828] x8 : 3c6fd66e79e32400 x7 : 0000000000000001 x6 : 0000000000000001 > > [ 451.090877] x5 : ffffffc01fdd7158 x4 : ffffffc00b64e2a0 x3 : ffffffc008f92adc > > [ 451.090926] x2 : 0000000100000000 x1 : ffffff8057afd940 x0 : 000000000000006f > > [ 451.090976] Call trace: > > [ 451.090994] debug_dma_map_sg+0x5bc/0x950 > > [ 451.091026] dma_alloc_noncontiguous+0x2f4/0x404 > > [ 451.091060] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091150] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091228] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091305] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091379] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.091446] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.091507] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] > > [ 451.091555] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091631] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091705] v4l_streamon+0x74/0xa8 > > [ 451.091738] __video_do_ioctl+0x90c/0xa40 > > [ 451.091769] video_usercopy+0xa44/0x1ef8 > > [ 451.091799] video_ioctl2+0x44/0x58 > > [ 451.091830] v4l2_ioctl+0x138/0x164 > > [ 451.091860] __arm64_sys_ioctl+0x154/0x1d0 > > [ 451.091892] invoke_syscall+0x98/0x278 > > [ 451.091923] el0_svc_common+0x214/0x274 > > [ 451.091953] do_el0_svc+0x9c/0x19c > > [ 451.091982] el0_svc+0x5c/0xc0 > > [ 451.092013] el0t_64_sync_handler+0x78/0x108 > > [ 451.092045] el0t_64_sync+0x1a4/0x1a8 > > [ 451.092081] Kernel panic - not syncing: kernel: panic_on_warn set ... > > [ 451.092103] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > > [ 451.092148] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) > > [ 451.092171] Call trace: > > [ 451.092186] dump_backtrace+0x0/0x4e8 > > [ 451.092219] show_stack+0x34/0x44 > > [ 451.092247] dump_stack_lvl+0xdc/0x11c > > [ 451.092278] dump_stack+0x1c/0x48 > > [ 451.092307] panic+0x2a4/0x7b8 > > [ 451.092335] check_panic_on_warn+0xb8/0x104 > > [ 451.092369] __warn+0x16c/0x230 > > [ 451.092399] report_bug+0x160/0x280 > > [ 451.092432] bug_handler+0x48/0xb8 > > [ 451.092466] call_break_hook+0x180/0x1b4 > > [ 451.092498] brk_handler+0x30/0xbc > > [ 451.092529] do_debug_exception+0x16c/0x31c > > [ 451.092563] el1_dbg+0x64/0x80 > > [ 451.092592] el1h_64_sync_handler+0x70/0xb4 > > [ 451.092624] el1h_64_sync+0x7c/0x80 > > [ 451.092653] debug_dma_map_sg+0x5bc/0x950 > > [ 451.092685] dma_alloc_noncontiguous+0x2f4/0x404 > > [ 451.092717] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.092794] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.092868] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.092942] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.093015] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.093079] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.093139] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] > > [ 451.093187] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.093261] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.093334] v4l_streamon+0x74/0xa8 > > [ 451.093366] __video_do_ioctl+0x90c/0xa40 > > [ 451.093398] video_usercopy+0xa44/0x1ef8 > > [ 451.093428] video_ioctl2+0x44/0x58 > > [ 451.093457] v4l2_ioctl+0x138/0x164 > > [ 451.093487] __arm64_sys_ioctl+0x154/0x1d0 > > [ 451.093518] invoke_syscall+0x98/0x278 > > [ 451.093548] el0_svc_common+0x214/0x274 > > [ 451.093578] do_el0_svc+0x9c/0x19c > > [ 451.093607] el0_svc+0x5c/0xc0 > > [ 451.093637] el0t_64_sync_handler+0x78/0x108 > > [ 451.093669] el0t_64_sync+0x1a4/0x1a8 > > [ 451.093701] SMP: stopping secondary CPUs > > [ 451.093777] Kernel Offset: disabled > > [ 451.093797] CPU features: 0xc00181c1,a3300e42 > > [ 451.093822] Memory Limit: none > > > > Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org> > > --- > > drivers/usb/host/xhci-mtk.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > > index 90cf40d6d0c3..605b1e1a5098 100644 > > --- a/drivers/usb/host/xhci-mtk.c > > +++ b/drivers/usb/host/xhci-mtk.c > > @@ -643,6 +643,8 @@ static int xhci_mtk_probe(struct platform_device *pdev) > > pm_runtime_put_autosuspend(dev); > > pm_runtime_forbid(dev); > > > > + dma_set_max_seg_size(dev, UINT_MAX); > > + > > return 0; > > > > dealloc_usb3_hcd: > > > > --- > > base-commit: 1b2c92a1cb2469d8c0079dbf496ab86e22e1cb7c > > change-id: 20230628-mtk-usb-bf0059f64bd7 > > > > Best regards, > > -- > > Ricardo Ribalda Delgado <ribalda@chromium.org> > > > > > -- > Ricardo Ribalda
Hi Zubin On Wed, 28 Jun 2023 at 23:57, Zubin Mithra <zsm@chromium.org> wrote: > > On Wed, Jun 28, 2023 at 11:04:20PM +0200, Ricardo Ribalda wrote: > > On Wed, 28 Jun 2023 at 23:00, Ricardo Ribalda <ribalda@chromium.org> wrote: > > > > > > Allow devices to have dma operations beyond 64K, and avoid warnings such > > > as: > > > > > > DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > Reported-by: Zubin Mithra <zsm@chromium.org> > > Should this be cc'd to stable@ as well? Not sure, in most of the cases this is "just" a warning fix. Let the maintainer decide: Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller") Cc: stable@vger.kernel.org
On Thu, Jun 29, 2023 at 09:13:23AM +0200, Ricardo Ribalda wrote: > Hi Zubin > > On Wed, 28 Jun 2023 at 23:57, Zubin Mithra <zsm@chromium.org> wrote: > > > > On Wed, Jun 28, 2023 at 11:04:20PM +0200, Ricardo Ribalda wrote: > > > On Wed, 28 Jun 2023 at 23:00, Ricardo Ribalda <ribalda@chromium.org> wrote: > > > > > > > > Allow devices to have dma operations beyond 64K, and avoid warnings such > > > > as: > > > > > > > > DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > > > > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > > Reported-by: Zubin Mithra <zsm@chromium.org> > > > > Should this be cc'd to stable@ as well? > > Not sure, in most of the cases this is "just" a warning fix. Let the > maintainer decide: Warnings can cause reboots as the majority of the linux systems in the world run panic-on-warn, so yes, it should be backported. thanks, greg k-h
On 2023-06-29 09:40, Greg Kroah-Hartman wrote: > On Thu, Jun 29, 2023 at 09:13:23AM +0200, Ricardo Ribalda wrote: >> Hi Zubin >> >> On Wed, 28 Jun 2023 at 23:57, Zubin Mithra <zsm@chromium.org> wrote: >>> >>> On Wed, Jun 28, 2023 at 11:04:20PM +0200, Ricardo Ribalda wrote: >>>> On Wed, 28 Jun 2023 at 23:00, Ricardo Ribalda <ribalda@chromium.org> wrote: >>>>> >>>>> Allow devices to have dma operations beyond 64K, and avoid warnings such >>>>> as: >>>>> >>>>> DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] >>>>> >>>>> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> >>>> Reported-by: Zubin Mithra <zsm@chromium.org> >>> >>> Should this be cc'd to stable@ as well? >> >> Not sure, in most of the cases this is "just" a warning fix. Let the >> maintainer decide: > > Warnings can cause reboots as the majority of the linux systems in the > world run panic-on-warn, so yes, it should be backported. Although in this particular case, running DMA_API_DEBUG=y on production systems is a pretty inadvisable thing to do anyway ;) However I'm glad I looked, since I think this also points to a bug in dma_alloc_noncontiguous() - it's one thing to blame a driver for trying to map a malformed scatterlist of its own, but if the DMA API is generating one internally without respecting the device's (claimed) parameters, then that's on us. I'll have a look into it... Thanks, Robin.
On 2023-06-28 22:00, Ricardo Ribalda wrote: > Allow devices to have dma operations beyond 64K, and avoid warnings such > as: Hang on, is this actually correct? I just had a vague memory of XHCI having some restrictions, and sure enough according to the spec it *does* require buffers to be split at 64KB boundaries, since that's the maximum length a single TRB can encode - that's exactly the kind of constraint that the max_seg_size abstraction is intended to represent, so it seems a bit odd to be explicitly claiming a very different value. Thanks, Robin. > DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > --- > Fix warnings such as: > > [ 451.089443] ------------[ cut here ]------------ > [ 451.089498] DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > [ 451.089617] WARNING: CPU: 7 PID: 14227 at kernel/dma/debug.c:1163 debug_dma_map_sg+0x5bc/0x950 > [ 451.089674] Modules linked in: xfrm_interface tun hci_vhci bridge stp llc veth xt_cgroup xt_MASQUERADE uinput rfcomm ip6table_nat fuse 8021q algif_hash algif_skcipher af_alg r8153_ecm cdc_ether usbnet r8152 mii mtk_vcodec_dec_hw mt7921s mt76_sdio mt7921_common mt76_connac_lib mt76 uvcvideo videobuf2_vmalloc mtk_vcodec_dec v4l2_h264 mtk_vcodec_enc mtk_jpeg v4l2_vp9 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 btmtksdio videobuf2_common mtk_vcodec_common btmtk mac80211 snd_sof_mt8186 snd_sof_xtensa_dsp snd_sof_of snd_sof snd_sof_utils mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi hid_rmi rmi_core serio bluetooth ecdh_generic ecc cfg80211 lzo_rle lzo_compress zram joydev > [ 451.090285] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > [ 451.090333] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) > [ 451.090356] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 451.090401] pc : debug_dma_map_sg+0x5bc/0x950 > [ 451.090433] lr : debug_dma_map_sg+0x5bc/0x950 > [ 451.090462] sp : ffffffc01fdd75e0 > [ 451.090479] x29: ffffffc01fdd7640 x28: ffffff80c1280300 x27: 0000000000010000 > [ 451.090531] x26: ffffff80c1ec9600 x25: 1ffffff01a749501 x24: ffffff80d3a4a800 > [ 451.090581] x23: dfffffc000000000 x22: ffffff80d3a4a80c x21: ffffffc00aae5740 > [ 451.090631] x20: ffffffffffffffff x19: ffffff80d3a4a810 x18: 0000000000000000 > [ 451.090680] x17: 64206e6168742072 x16: 65676e6f6c20746e x15: 656d676573206773 > [ 451.090731] x14: 20676e697070616d x13: 0000000000000001 x12: 0000000000000001 > [ 451.090779] x11: 0000000000000000 x10: 0000000000040000 x9 : 3c6fd66e79e32400 > [ 451.090828] x8 : 3c6fd66e79e32400 x7 : 0000000000000001 x6 : 0000000000000001 > [ 451.090877] x5 : ffffffc01fdd7158 x4 : ffffffc00b64e2a0 x3 : ffffffc008f92adc > [ 451.090926] x2 : 0000000100000000 x1 : ffffff8057afd940 x0 : 000000000000006f > [ 451.090976] Call trace: > [ 451.090994] debug_dma_map_sg+0x5bc/0x950 > [ 451.091026] dma_alloc_noncontiguous+0x2f4/0x404 > [ 451.091060] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091150] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091228] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091305] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091379] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.091446] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.091507] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] > [ 451.091555] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091631] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091705] v4l_streamon+0x74/0xa8 > [ 451.091738] __video_do_ioctl+0x90c/0xa40 > [ 451.091769] video_usercopy+0xa44/0x1ef8 > [ 451.091799] video_ioctl2+0x44/0x58 > [ 451.091830] v4l2_ioctl+0x138/0x164 > [ 451.091860] __arm64_sys_ioctl+0x154/0x1d0 > [ 451.091892] invoke_syscall+0x98/0x278 > [ 451.091923] el0_svc_common+0x214/0x274 > [ 451.091953] do_el0_svc+0x9c/0x19c > [ 451.091982] el0_svc+0x5c/0xc0 > [ 451.092013] el0t_64_sync_handler+0x78/0x108 > [ 451.092045] el0t_64_sync+0x1a4/0x1a8 > [ 451.092081] Kernel panic - not syncing: kernel: panic_on_warn set ... > [ 451.092103] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > [ 451.092148] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) > [ 451.092171] Call trace: > [ 451.092186] dump_backtrace+0x0/0x4e8 > [ 451.092219] show_stack+0x34/0x44 > [ 451.092247] dump_stack_lvl+0xdc/0x11c > [ 451.092278] dump_stack+0x1c/0x48 > [ 451.092307] panic+0x2a4/0x7b8 > [ 451.092335] check_panic_on_warn+0xb8/0x104 > [ 451.092369] __warn+0x16c/0x230 > [ 451.092399] report_bug+0x160/0x280 > [ 451.092432] bug_handler+0x48/0xb8 > [ 451.092466] call_break_hook+0x180/0x1b4 > [ 451.092498] brk_handler+0x30/0xbc > [ 451.092529] do_debug_exception+0x16c/0x31c > [ 451.092563] el1_dbg+0x64/0x80 > [ 451.092592] el1h_64_sync_handler+0x70/0xb4 > [ 451.092624] el1h_64_sync+0x7c/0x80 > [ 451.092653] debug_dma_map_sg+0x5bc/0x950 > [ 451.092685] dma_alloc_noncontiguous+0x2f4/0x404 > [ 451.092717] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.092794] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.092868] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.092942] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.093015] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.093079] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.093139] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] > [ 451.093187] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.093261] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.093334] v4l_streamon+0x74/0xa8 > [ 451.093366] __video_do_ioctl+0x90c/0xa40 > [ 451.093398] video_usercopy+0xa44/0x1ef8 > [ 451.093428] video_ioctl2+0x44/0x58 > [ 451.093457] v4l2_ioctl+0x138/0x164 > [ 451.093487] __arm64_sys_ioctl+0x154/0x1d0 > [ 451.093518] invoke_syscall+0x98/0x278 > [ 451.093548] el0_svc_common+0x214/0x274 > [ 451.093578] do_el0_svc+0x9c/0x19c > [ 451.093607] el0_svc+0x5c/0xc0 > [ 451.093637] el0t_64_sync_handler+0x78/0x108 > [ 451.093669] el0t_64_sync+0x1a4/0x1a8 > [ 451.093701] SMP: stopping secondary CPUs > [ 451.093777] Kernel Offset: disabled > [ 451.093797] CPU features: 0xc00181c1,a3300e42 > [ 451.093822] Memory Limit: none > > Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org> > --- > drivers/usb/host/xhci-mtk.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > index 90cf40d6d0c3..605b1e1a5098 100644 > --- a/drivers/usb/host/xhci-mtk.c > +++ b/drivers/usb/host/xhci-mtk.c > @@ -643,6 +643,8 @@ static int xhci_mtk_probe(struct platform_device *pdev) > pm_runtime_put_autosuspend(dev); > pm_runtime_forbid(dev); > > + dma_set_max_seg_size(dev, UINT_MAX); > + > return 0; > > dealloc_usb3_hcd: > > --- > base-commit: 1b2c92a1cb2469d8c0079dbf496ab86e22e1cb7c > change-id: 20230628-mtk-usb-bf0059f64bd7 > > Best regards,
Hi Robin On Thu, 29 Jun 2023 at 20:11, Robin Murphy <robin.murphy@arm.com> wrote: > > On 2023-06-28 22:00, Ricardo Ribalda wrote: > > Allow devices to have dma operations beyond 64K, and avoid warnings such > > as: > > Hang on, is this actually correct? I just had a vague memory of XHCI > having some restrictions, and sure enough according to the spec it > *does* require buffers to be split at 64KB boundaries, since that's the > maximum length a single TRB can encode - that's exactly the kind of > constraint that the max_seg_size abstraction is intended to represent, > so it seems a bit odd to be explicitly claiming a very different value. > > Thanks, > Robin. I think we had a similar discussion for 93915a4170e9 ("xhci-pci: set the dma max_seg_size") on https://lore.kernel.org/all/1fe8f8a7-c88f-0c91-e74f-4d3f2f885c89@linux.intel.com/ ``` Preferred max segment size of sg list would be 64k as xHC hardware has 64k TRB payload size limit, but xhci driver will take care of larger segments, splitting them into 64k chunks. ``` > > > DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > --- > > Fix warnings such as: > > > > [ 451.089443] ------------[ cut here ]------------ > > [ 451.089498] DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] > > [ 451.089617] WARNING: CPU: 7 PID: 14227 at kernel/dma/debug.c:1163 debug_dma_map_sg+0x5bc/0x950 > > [ 451.089674] Modules linked in: xfrm_interface tun hci_vhci bridge stp llc veth xt_cgroup xt_MASQUERADE uinput rfcomm ip6table_nat fuse 8021q algif_hash algif_skcipher af_alg r8153_ecm cdc_ether usbnet r8152 mii mtk_vcodec_dec_hw mt7921s mt76_sdio mt7921_common mt76_connac_lib mt76 uvcvideo videobuf2_vmalloc mtk_vcodec_dec v4l2_h264 mtk_vcodec_enc mtk_jpeg v4l2_vp9 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 btmtksdio videobuf2_common mtk_vcodec_common btmtk mac80211 snd_sof_mt8186 snd_sof_xtensa_dsp snd_sof_of snd_sof snd_sof_utils mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi hid_rmi rmi_core serio bluetooth ecdh_generic ecc cfg80211 lzo_rle lzo_compress zram joydev > > [ 451.090285] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > > [ 451.090333] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) > > [ 451.090356] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > [ 451.090401] pc : debug_dma_map_sg+0x5bc/0x950 > > [ 451.090433] lr : debug_dma_map_sg+0x5bc/0x950 > > [ 451.090462] sp : ffffffc01fdd75e0 > > [ 451.090479] x29: ffffffc01fdd7640 x28: ffffff80c1280300 x27: 0000000000010000 > > [ 451.090531] x26: ffffff80c1ec9600 x25: 1ffffff01a749501 x24: ffffff80d3a4a800 > > [ 451.090581] x23: dfffffc000000000 x22: ffffff80d3a4a80c x21: ffffffc00aae5740 > > [ 451.090631] x20: ffffffffffffffff x19: ffffff80d3a4a810 x18: 0000000000000000 > > [ 451.090680] x17: 64206e6168742072 x16: 65676e6f6c20746e x15: 656d676573206773 > > [ 451.090731] x14: 20676e697070616d x13: 0000000000000001 x12: 0000000000000001 > > [ 451.090779] x11: 0000000000000000 x10: 0000000000040000 x9 : 3c6fd66e79e32400 > > [ 451.090828] x8 : 3c6fd66e79e32400 x7 : 0000000000000001 x6 : 0000000000000001 > > [ 451.090877] x5 : ffffffc01fdd7158 x4 : ffffffc00b64e2a0 x3 : ffffffc008f92adc > > [ 451.090926] x2 : 0000000100000000 x1 : ffffff8057afd940 x0 : 000000000000006f > > [ 451.090976] Call trace: > > [ 451.090994] debug_dma_map_sg+0x5bc/0x950 > > [ 451.091026] dma_alloc_noncontiguous+0x2f4/0x404 > > [ 451.091060] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091150] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091228] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091305] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091379] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.091446] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.091507] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] > > [ 451.091555] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091631] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.091705] v4l_streamon+0x74/0xa8 > > [ 451.091738] __video_do_ioctl+0x90c/0xa40 > > [ 451.091769] video_usercopy+0xa44/0x1ef8 > > [ 451.091799] video_ioctl2+0x44/0x58 > > [ 451.091830] v4l2_ioctl+0x138/0x164 > > [ 451.091860] __arm64_sys_ioctl+0x154/0x1d0 > > [ 451.091892] invoke_syscall+0x98/0x278 > > [ 451.091923] el0_svc_common+0x214/0x274 > > [ 451.091953] do_el0_svc+0x9c/0x19c > > [ 451.091982] el0_svc+0x5c/0xc0 > > [ 451.092013] el0t_64_sync_handler+0x78/0x108 > > [ 451.092045] el0t_64_sync+0x1a4/0x1a8 > > [ 451.092081] Kernel panic - not syncing: kernel: panic_on_warn set ... > > [ 451.092103] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > > [ 451.092148] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) > > [ 451.092171] Call trace: > > [ 451.092186] dump_backtrace+0x0/0x4e8 > > [ 451.092219] show_stack+0x34/0x44 > > [ 451.092247] dump_stack_lvl+0xdc/0x11c > > [ 451.092278] dump_stack+0x1c/0x48 > > [ 451.092307] panic+0x2a4/0x7b8 > > [ 451.092335] check_panic_on_warn+0xb8/0x104 > > [ 451.092369] __warn+0x16c/0x230 > > [ 451.092399] report_bug+0x160/0x280 > > [ 451.092432] bug_handler+0x48/0xb8 > > [ 451.092466] call_break_hook+0x180/0x1b4 > > [ 451.092498] brk_handler+0x30/0xbc > > [ 451.092529] do_debug_exception+0x16c/0x31c > > [ 451.092563] el1_dbg+0x64/0x80 > > [ 451.092592] el1h_64_sync_handler+0x70/0xb4 > > [ 451.092624] el1h_64_sync+0x7c/0x80 > > [ 451.092653] debug_dma_map_sg+0x5bc/0x950 > > [ 451.092685] dma_alloc_noncontiguous+0x2f4/0x404 > > [ 451.092717] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.092794] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.092868] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.092942] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.093015] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.093079] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] > > [ 451.093139] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] > > [ 451.093187] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.093261] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] > > [ 451.093334] v4l_streamon+0x74/0xa8 > > [ 451.093366] __video_do_ioctl+0x90c/0xa40 > > [ 451.093398] video_usercopy+0xa44/0x1ef8 > > [ 451.093428] video_ioctl2+0x44/0x58 > > [ 451.093457] v4l2_ioctl+0x138/0x164 > > [ 451.093487] __arm64_sys_ioctl+0x154/0x1d0 > > [ 451.093518] invoke_syscall+0x98/0x278 > > [ 451.093548] el0_svc_common+0x214/0x274 > > [ 451.093578] do_el0_svc+0x9c/0x19c > > [ 451.093607] el0_svc+0x5c/0xc0 > > [ 451.093637] el0t_64_sync_handler+0x78/0x108 > > [ 451.093669] el0t_64_sync+0x1a4/0x1a8 > > [ 451.093701] SMP: stopping secondary CPUs > > [ 451.093777] Kernel Offset: disabled > > [ 451.093797] CPU features: 0xc00181c1,a3300e42 > > [ 451.093822] Memory Limit: none > > > > Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org> > > --- > > drivers/usb/host/xhci-mtk.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > > index 90cf40d6d0c3..605b1e1a5098 100644 > > --- a/drivers/usb/host/xhci-mtk.c > > +++ b/drivers/usb/host/xhci-mtk.c > > @@ -643,6 +643,8 @@ static int xhci_mtk_probe(struct platform_device *pdev) > > pm_runtime_put_autosuspend(dev); > > pm_runtime_forbid(dev); > > > > + dma_set_max_seg_size(dev, UINT_MAX); > > + > > return 0; > > > > dealloc_usb3_hcd: > > > > --- > > base-commit: 1b2c92a1cb2469d8c0079dbf496ab86e22e1cb7c > > change-id: 20230628-mtk-usb-bf0059f64bd7 > > > > Best regards,
On 2023-06-29 19:29, Ricardo Ribalda wrote: > Hi Robin > > On Thu, 29 Jun 2023 at 20:11, Robin Murphy <robin.murphy@arm.com> wrote: >> >> On 2023-06-28 22:00, Ricardo Ribalda wrote: >>> Allow devices to have dma operations beyond 64K, and avoid warnings such >>> as: >> >> Hang on, is this actually correct? I just had a vague memory of XHCI >> having some restrictions, and sure enough according to the spec it >> *does* require buffers to be split at 64KB boundaries, since that's the >> maximum length a single TRB can encode - that's exactly the kind of >> constraint that the max_seg_size abstraction is intended to represent, >> so it seems a bit odd to be explicitly claiming a very different value. >> >> Thanks, >> Robin. > > I think we had a similar discussion for 93915a4170e9 ("xhci-pci: set > the dma max_seg_size") > on > https://lore.kernel.org/all/1fe8f8a7-c88f-0c91-e74f-4d3f2f885c89@linux.intel.com/ > > ``` > Preferred max segment size of sg list would be 64k as xHC hardware has > 64k TRB payload size > limit, but xhci driver will take care of larger segments, splitting > them into 64k chunks. > ``` OK, but it still seems off to me to claim to support something that the hardware doesn't support, and the driver has to fake, especially when it's only to paper over a warning which isn't even the driver's fault in the first place. The aim of the DMA_API_DEBUG_SG warnings wasn't to go round blindly adding dma_set_max_seg_size(UINT_MAX) all over the place, it was always to consider whether the dma_map_sg() call and/or the scatterlist itself are right, just as much as whether the driver may have forgotten to set an appropriate parameter. As I've already raised, in this particular case I think it's actually the debug check that's misplaced, since it's not dma_map_sg() anyway, but as it stands, the implementations of dma_alloc_noncontiguous() are definitely doing the wrong thing with respect to what it is then asking to validate. Unless there is some known reason to make this change to any USB host controller *other* than that someone sees UVC allocate a >64KB buffer via this path on a system which happens to have that particular HCD, it is not the right change to make. Thanks, Robin. > >> >>> DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] >>> >>> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> >>> --- >>> Fix warnings such as: >>> >>> [ 451.089443] ------------[ cut here ]------------ >>> [ 451.089498] DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device claims to support [len=98304] [max=65536] >>> [ 451.089617] WARNING: CPU: 7 PID: 14227 at kernel/dma/debug.c:1163 debug_dma_map_sg+0x5bc/0x950 >>> [ 451.089674] Modules linked in: xfrm_interface tun hci_vhci bridge stp llc veth xt_cgroup xt_MASQUERADE uinput rfcomm ip6table_nat fuse 8021q algif_hash algif_skcipher af_alg r8153_ecm cdc_ether usbnet r8152 mii mtk_vcodec_dec_hw mt7921s mt76_sdio mt7921_common mt76_connac_lib mt76 uvcvideo videobuf2_vmalloc mtk_vcodec_dec v4l2_h264 mtk_vcodec_enc mtk_jpeg v4l2_vp9 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 btmtksdio videobuf2_common mtk_vcodec_common btmtk mac80211 snd_sof_mt8186 snd_sof_xtensa_dsp snd_sof_of snd_sof snd_sof_utils mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi hid_rmi rmi_core serio bluetooth ecdh_generic ecc cfg80211 lzo_rle lzo_compress zram joydev >>> [ 451.090285] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 >>> [ 451.090333] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) >>> [ 451.090356] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) >>> [ 451.090401] pc : debug_dma_map_sg+0x5bc/0x950 >>> [ 451.090433] lr : debug_dma_map_sg+0x5bc/0x950 >>> [ 451.090462] sp : ffffffc01fdd75e0 >>> [ 451.090479] x29: ffffffc01fdd7640 x28: ffffff80c1280300 x27: 0000000000010000 >>> [ 451.090531] x26: ffffff80c1ec9600 x25: 1ffffff01a749501 x24: ffffff80d3a4a800 >>> [ 451.090581] x23: dfffffc000000000 x22: ffffff80d3a4a80c x21: ffffffc00aae5740 >>> [ 451.090631] x20: ffffffffffffffff x19: ffffff80d3a4a810 x18: 0000000000000000 >>> [ 451.090680] x17: 64206e6168742072 x16: 65676e6f6c20746e x15: 656d676573206773 >>> [ 451.090731] x14: 20676e697070616d x13: 0000000000000001 x12: 0000000000000001 >>> [ 451.090779] x11: 0000000000000000 x10: 0000000000040000 x9 : 3c6fd66e79e32400 >>> [ 451.090828] x8 : 3c6fd66e79e32400 x7 : 0000000000000001 x6 : 0000000000000001 >>> [ 451.090877] x5 : ffffffc01fdd7158 x4 : ffffffc00b64e2a0 x3 : ffffffc008f92adc >>> [ 451.090926] x2 : 0000000100000000 x1 : ffffff8057afd940 x0 : 000000000000006f >>> [ 451.090976] Call trace: >>> [ 451.090994] debug_dma_map_sg+0x5bc/0x950 >>> [ 451.091026] dma_alloc_noncontiguous+0x2f4/0x404 >>> [ 451.091060] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.091150] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.091228] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.091305] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.091379] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] >>> [ 451.091446] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] >>> [ 451.091507] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] >>> [ 451.091555] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.091631] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.091705] v4l_streamon+0x74/0xa8 >>> [ 451.091738] __video_do_ioctl+0x90c/0xa40 >>> [ 451.091769] video_usercopy+0xa44/0x1ef8 >>> [ 451.091799] video_ioctl2+0x44/0x58 >>> [ 451.091830] v4l2_ioctl+0x138/0x164 >>> [ 451.091860] __arm64_sys_ioctl+0x154/0x1d0 >>> [ 451.091892] invoke_syscall+0x98/0x278 >>> [ 451.091923] el0_svc_common+0x214/0x274 >>> [ 451.091953] do_el0_svc+0x9c/0x19c >>> [ 451.091982] el0_svc+0x5c/0xc0 >>> [ 451.092013] el0t_64_sync_handler+0x78/0x108 >>> [ 451.092045] el0t_64_sync+0x1a4/0x1a8 >>> [ 451.092081] Kernel panic - not syncing: kernel: panic_on_warn set ... >>> [ 451.092103] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted 5.15.118-lockdep-19753-g1b0a8b16661d #1 cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 >>> [ 451.092148] Hardware name: Google Rusty sku196608/196609/196610/196611 board (DT) >>> [ 451.092171] Call trace: >>> [ 451.092186] dump_backtrace+0x0/0x4e8 >>> [ 451.092219] show_stack+0x34/0x44 >>> [ 451.092247] dump_stack_lvl+0xdc/0x11c >>> [ 451.092278] dump_stack+0x1c/0x48 >>> [ 451.092307] panic+0x2a4/0x7b8 >>> [ 451.092335] check_panic_on_warn+0xb8/0x104 >>> [ 451.092369] __warn+0x16c/0x230 >>> [ 451.092399] report_bug+0x160/0x280 >>> [ 451.092432] bug_handler+0x48/0xb8 >>> [ 451.092466] call_break_hook+0x180/0x1b4 >>> [ 451.092498] brk_handler+0x30/0xbc >>> [ 451.092529] do_debug_exception+0x16c/0x31c >>> [ 451.092563] el1_dbg+0x64/0x80 >>> [ 451.092592] el1h_64_sync_handler+0x70/0xb4 >>> [ 451.092624] el1h_64_sync+0x7c/0x80 >>> [ 451.092653] debug_dma_map_sg+0x5bc/0x950 >>> [ 451.092685] dma_alloc_noncontiguous+0x2f4/0x404 >>> [ 451.092717] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.092794] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.092868] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.092942] uvc_start_streaming+0x20c/0x3d4 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.093015] vb2_start_streaming+0x118/0x400 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] >>> [ 451.093079] vb2_core_streamon+0x258/0x360 [videobuf2_common 252dc8c49960dcb8e329e2787100c89e1899c17f] >>> [ 451.093139] vb2_streamon+0x88/0xbc [videobuf2_v4l2 f4acca89bfe3410cd8f3ca536255fc3877fe63db] >>> [ 451.093187] uvc_queue_streamon+0x44/0x68 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.093261] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo 1a151fdc876854366480a9c6b7aaa4b7999fb493] >>> [ 451.093334] v4l_streamon+0x74/0xa8 >>> [ 451.093366] __video_do_ioctl+0x90c/0xa40 >>> [ 451.093398] video_usercopy+0xa44/0x1ef8 >>> [ 451.093428] video_ioctl2+0x44/0x58 >>> [ 451.093457] v4l2_ioctl+0x138/0x164 >>> [ 451.093487] __arm64_sys_ioctl+0x154/0x1d0 >>> [ 451.093518] invoke_syscall+0x98/0x278 >>> [ 451.093548] el0_svc_common+0x214/0x274 >>> [ 451.093578] do_el0_svc+0x9c/0x19c >>> [ 451.093607] el0_svc+0x5c/0xc0 >>> [ 451.093637] el0t_64_sync_handler+0x78/0x108 >>> [ 451.093669] el0t_64_sync+0x1a4/0x1a8 >>> [ 451.093701] SMP: stopping secondary CPUs >>> [ 451.093777] Kernel Offset: disabled >>> [ 451.093797] CPU features: 0xc00181c1,a3300e42 >>> [ 451.093822] Memory Limit: none >>> >>> Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org> >>> --- >>> drivers/usb/host/xhci-mtk.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c >>> index 90cf40d6d0c3..605b1e1a5098 100644 >>> --- a/drivers/usb/host/xhci-mtk.c >>> +++ b/drivers/usb/host/xhci-mtk.c >>> @@ -643,6 +643,8 @@ static int xhci_mtk_probe(struct platform_device *pdev) >>> pm_runtime_put_autosuspend(dev); >>> pm_runtime_forbid(dev); >>> >>> + dma_set_max_seg_size(dev, UINT_MAX); >>> + >>> return 0; >>> >>> dealloc_usb3_hcd: >>> >>> --- >>> base-commit: 1b2c92a1cb2469d8c0079dbf496ab86e22e1cb7c >>> change-id: 20230628-mtk-usb-bf0059f64bd7 >>> >>> Best regards, > > >
On 29.6.2023 22.19, Robin Murphy wrote: > On 2023-06-29 19:29, Ricardo Ribalda wrote: >> Hi Robin >> >> On Thu, 29 Jun 2023 at 20:11, Robin Murphy <robin.murphy@arm.com> wrote: >>> >>> On 2023-06-28 22:00, Ricardo Ribalda wrote: >>>> Allow devices to have dma operations beyond 64K, and avoid warnings such >>>> as: >>> >>> Hang on, is this actually correct? I just had a vague memory of XHCI >>> having some restrictions, and sure enough according to the spec it >>> *does* require buffers to be split at 64KB boundaries, since that's the >>> maximum length a single TRB can encode - that's exactly the kind of >>> constraint that the max_seg_size abstraction is intended to represent, >>> so it seems a bit odd to be explicitly claiming a very different value. >>> >>> Thanks, >>> Robin. >> >> I think we had a similar discussion for 93915a4170e9 ("xhci-pci: set >> the dma max_seg_size") >> on >> https://lore.kernel.org/all/1fe8f8a7-c88f-0c91-e74f-4d3f2f885c89@linux.intel.com/ >> >> ``` >> Preferred max segment size of sg list would be 64k as xHC hardware has >> 64k TRB payload size >> limit, but xhci driver will take care of larger segments, splitting >> them into 64k chunks. >> ``` > > OK, but it still seems off to me to claim to support something that the hardware doesn't support, and the driver has to fake, especially when it's only to paper over a warning which isn't even the driver's fault in the first place. xHC Hardware has odd alignments and size restrictions that the driver anyway need to sort out. The 64K is already fake, it's the most common max supported size for TRBs, but not always true. Varies depending on TRB location in TRB ring. xhci driver can handle any size. > > The aim of the DMA_API_DEBUG_SG warnings wasn't to go round blindly adding dma_set_max_seg_size(UINT_MAX) all over the place, it was always to consider whether the dma_map_sg() call and/or the scatterlist itself are right, just as much as whether the driver may have forgotten to set an appropriate parameter. As I've already raised, in this particular case I think it's actually the debug check that's misplaced, since it's not dma_map_sg() anyway, but as it stands, the implementations of dma_alloc_noncontiguous() are definitely doing the wrong thing with respect to what it is then asking to validate. Agree that this seems to be an issue in the DMA debugging side. Would it need to take into account cases where device driver can support different sizes than the host controller? > > Unless there is some known reason to make this change to any USB host controller *other* than that someone sees UVC allocate a >64KB buffer via this path on a system which happens to have that particular HCD, it is not the right change to make. This would be all USB 3.x hosts, from all vendors. keeping the 64K max seg size, and fixing the dma debug side would be optimal, but until that gets done I think we can take this oneliner as it resolves a real world issue where USB isn't working. Thanks -Mathias
On Fri, 2023-06-30 at 14:25 +0300, Mathias Nyman wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 29.6.2023 22.19, Robin Murphy wrote: > > On 2023-06-29 19:29, Ricardo Ribalda wrote: > >> Hi Robin > >> > >> On Thu, 29 Jun 2023 at 20:11, Robin Murphy <robin.murphy@arm.com> > wrote: > >>> > >>> On 2023-06-28 22:00, Ricardo Ribalda wrote: > >>>> Allow devices to have dma operations beyond 64K, and avoid > warnings such > >>>> as: > >>> > >>> Hang on, is this actually correct? I just had a vague memory of > XHCI > >>> having some restrictions, and sure enough according to the spec > it > >>> *does* require buffers to be split at 64KB boundaries, since > that's the > >>> maximum length a single TRB can encode - that's exactly the kind > of > >>> constraint that the max_seg_size abstraction is intended to > represent, > >>> so it seems a bit odd to be explicitly claiming a very different > value. > >>> > >>> Thanks, > >>> Robin. > >> > >> I think we had a similar discussion for 93915a4170e9 ("xhci-pci: > set > >> the dma max_seg_size") > >> on > >> > https://lore.kernel.org/all/1fe8f8a7-c88f-0c91-e74f-4d3f2f885c89@linux.intel.com/ > >> > >> ``` > >> Preferred max segment size of sg list would be 64k as xHC hardware > has > >> 64k TRB payload size > >> limit, but xhci driver will take care of larger segments, > splitting > >> them into 64k chunks. > >> ``` > > > > OK, but it still seems off to me to claim to support something that > the hardware doesn't support, and the driver has to fake, especially > when it's only to paper over a warning which isn't even the driver's > fault in the first place. > > xHC Hardware has odd alignments and size restrictions that the driver > anyway need to sort out. > The 64K is already fake, it's the most common max supported size for > TRBs, but not always true. > Varies depending on TRB location in TRB ring. > > xhci driver can handle any size. > > > > > The aim of the DMA_API_DEBUG_SG warnings wasn't to go round blindly > adding dma_set_max_seg_size(UINT_MAX) all over the place, it was > always to consider whether the dma_map_sg() call and/or the > scatterlist itself are right, just as much as whether the driver may > have forgotten to set an appropriate parameter. As I've already > raised, in this particular case I think it's actually the debug check > that's misplaced, since it's not dma_map_sg() anyway, but as it > stands, the implementations of dma_alloc_noncontiguous() are > definitely doing the wrong thing with respect to what it is then > asking to validate. > > Agree that this seems to be an issue in the DMA debugging side. > Would it need to take into account cases where device driver can > support different sizes than the host controller? static inline unsigned int dma_get_max_seg_size(struct device *dev) { if (dev->dma_parms && dev->dma_parms->max_segment_size) return dev->dma_parms->max_segment_size; return SZ_64K; } By the way, why it returns SZ_64K, but not UINT_MAX? I find many drivers set max_segment_size as UINT_MAX, seem it's better to return UNIT_MAX by default, if there is no limitation for a driver. > > > > > Unless there is some known reason to make this change to any USB > host controller *other* than that someone sees UVC allocate a >64KB > buffer via this path on a system which happens to have that > particular HCD, it is not the right change to make. > > This would be all USB 3.x hosts, from all vendors. > > keeping the 64K max seg size, and fixing the dma debug side would be > optimal, but until that gets done I think > we can take this oneliner as it resolves a real world issue where USB > isn't working. > > Thanks > -Mathias >
On Wed, 2023-06-28 at 23:00 +0200, Ricardo Ribalda wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Allow devices to have dma operations beyond 64K, and avoid warnings > such > as: > > DMA-API: xhci-mtk 11200000.usb: mapping sg segment longer than device > claims to support [len=98304] [max=65536] > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > --- > Fix warnings such as: > > [ 451.089443] ------------[ cut here ]------------ > [ 451.089498] DMA-API: xhci-mtk 11200000.usb: mapping sg segment > longer than device claims to support [len=98304] [max=65536] > [ 451.089617] WARNING: CPU: 7 PID: 14227 at kernel/dma/debug.c:1163 > debug_dma_map_sg+0x5bc/0x950 > [ 451.089674] Modules linked in: xfrm_interface tun hci_vhci bridge > stp llc veth xt_cgroup xt_MASQUERADE uinput rfcomm ip6table_nat fuse > 8021q algif_hash algif_skcipher af_alg r8153_ecm cdc_ether usbnet > r8152 mii mtk_vcodec_dec_hw mt7921s mt76_sdio mt7921_common > mt76_connac_lib mt76 uvcvideo videobuf2_vmalloc mtk_vcodec_dec > v4l2_h264 mtk_vcodec_enc mtk_jpeg v4l2_vp9 videobuf2_dma_contig > videobuf2_memops v4l2_mem2mem videobuf2_v4l2 btmtksdio > videobuf2_common mtk_vcodec_common btmtk mac80211 snd_sof_mt8186 > snd_sof_xtensa_dsp snd_sof_of snd_sof snd_sof_utils mtk_scp mtk_rpmsg > rpmsg_core mtk_scp_ipi hid_rmi rmi_core serio bluetooth ecdh_generic > ecc cfg80211 lzo_rle lzo_compress zram joydev > [ 451.090285] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted > 5.15.118-lockdep-19753-g1b0a8b16661d #1 > cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > [ 451.090333] Hardware name: Google Rusty > sku196608/196609/196610/196611 board (DT) > [ 451.090356] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 451.090401] pc : debug_dma_map_sg+0x5bc/0x950 > [ 451.090433] lr : debug_dma_map_sg+0x5bc/0x950 > [ 451.090462] sp : ffffffc01fdd75e0 > [ 451.090479] x29: ffffffc01fdd7640 x28: ffffff80c1280300 x27: > 0000000000010000 > [ 451.090531] x26: ffffff80c1ec9600 x25: 1ffffff01a749501 x24: > ffffff80d3a4a800 > [ 451.090581] x23: dfffffc000000000 x22: ffffff80d3a4a80c x21: > ffffffc00aae5740 > [ 451.090631] x20: ffffffffffffffff x19: ffffff80d3a4a810 x18: > 0000000000000000 > [ 451.090680] x17: 64206e6168742072 x16: 65676e6f6c20746e x15: > 656d676573206773 > [ 451.090731] x14: 20676e697070616d x13: 0000000000000001 x12: > 0000000000000001 > [ 451.090779] x11: 0000000000000000 x10: 0000000000040000 x9 : > 3c6fd66e79e32400 > [ 451.090828] x8 : 3c6fd66e79e32400 x7 : 0000000000000001 x6 : > 0000000000000001 > [ 451.090877] x5 : ffffffc01fdd7158 x4 : ffffffc00b64e2a0 x3 : > ffffffc008f92adc > [ 451.090926] x2 : 0000000100000000 x1 : ffffff8057afd940 x0 : > 000000000000006f > [ 451.090976] Call trace: > [ 451.090994] debug_dma_map_sg+0x5bc/0x950 > [ 451.091026] dma_alloc_noncontiguous+0x2f4/0x404 > [ 451.091060] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091150] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091228] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091305] uvc_start_streaming+0x20c/0x3d4 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091379] vb2_start_streaming+0x118/0x400 [videobuf2_common > 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.091446] vb2_core_streamon+0x258/0x360 [videobuf2_common > 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.091507] vb2_streamon+0x88/0xbc [videobuf2_v4l2 > f4acca89bfe3410cd8f3ca536255fc3877fe63db] > [ 451.091555] uvc_queue_streamon+0x44/0x68 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091631] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.091705] v4l_streamon+0x74/0xa8 > [ 451.091738] __video_do_ioctl+0x90c/0xa40 > [ 451.091769] video_usercopy+0xa44/0x1ef8 > [ 451.091799] video_ioctl2+0x44/0x58 > [ 451.091830] v4l2_ioctl+0x138/0x164 > [ 451.091860] __arm64_sys_ioctl+0x154/0x1d0 > [ 451.091892] invoke_syscall+0x98/0x278 > [ 451.091923] el0_svc_common+0x214/0x274 > [ 451.091953] do_el0_svc+0x9c/0x19c > [ 451.091982] el0_svc+0x5c/0xc0 > [ 451.092013] el0t_64_sync_handler+0x78/0x108 > [ 451.092045] el0t_64_sync+0x1a4/0x1a8 > [ 451.092081] Kernel panic - not syncing: kernel: panic_on_warn set > ... > [ 451.092103] CPU: 7 PID: 14227 Comm: syz-executor.0 Not tainted > 5.15.118-lockdep-19753-g1b0a8b16661d #1 > cd3ddfc5e13dbbbea438d3161fcad4d98ec474f4 > [ 451.092148] Hardware name: Google Rusty > sku196608/196609/196610/196611 board (DT) > [ 451.092171] Call trace: > [ 451.092186] dump_backtrace+0x0/0x4e8 > [ 451.092219] show_stack+0x34/0x44 > [ 451.092247] dump_stack_lvl+0xdc/0x11c > [ 451.092278] dump_stack+0x1c/0x48 > [ 451.092307] panic+0x2a4/0x7b8 > [ 451.092335] check_panic_on_warn+0xb8/0x104 > [ 451.092369] __warn+0x16c/0x230 > [ 451.092399] report_bug+0x160/0x280 > [ 451.092432] bug_handler+0x48/0xb8 > [ 451.092466] call_break_hook+0x180/0x1b4 > [ 451.092498] brk_handler+0x30/0xbc > [ 451.092529] do_debug_exception+0x16c/0x31c > [ 451.092563] el1_dbg+0x64/0x80 > [ 451.092592] el1h_64_sync_handler+0x70/0xb4 > [ 451.092624] el1h_64_sync+0x7c/0x80 > [ 451.092653] debug_dma_map_sg+0x5bc/0x950 > [ 451.092685] dma_alloc_noncontiguous+0x2f4/0x404 > [ 451.092717] uvc_alloc_urb_buffers+0x1e8/0x600 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.092794] uvc_video_start_transfer+0xaf4/0x1628 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.092868] uvc_video_start_streaming+0x154/0x2d8 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.092942] uvc_start_streaming+0x20c/0x3d4 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.093015] vb2_start_streaming+0x118/0x400 [videobuf2_common > 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.093079] vb2_core_streamon+0x258/0x360 [videobuf2_common > 252dc8c49960dcb8e329e2787100c89e1899c17f] > [ 451.093139] vb2_streamon+0x88/0xbc [videobuf2_v4l2 > f4acca89bfe3410cd8f3ca536255fc3877fe63db] > [ 451.093187] uvc_queue_streamon+0x44/0x68 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.093261] uvc_ioctl_streamon+0xd8/0x124 [uvcvideo > 1a151fdc876854366480a9c6b7aaa4b7999fb493] > [ 451.093334] v4l_streamon+0x74/0xa8 > [ 451.093366] __video_do_ioctl+0x90c/0xa40 > [ 451.093398] video_usercopy+0xa44/0x1ef8 > [ 451.093428] video_ioctl2+0x44/0x58 > [ 451.093457] v4l2_ioctl+0x138/0x164 > [ 451.093487] __arm64_sys_ioctl+0x154/0x1d0 > [ 451.093518] invoke_syscall+0x98/0x278 > [ 451.093548] el0_svc_common+0x214/0x274 > [ 451.093578] do_el0_svc+0x9c/0x19c > [ 451.093607] el0_svc+0x5c/0xc0 > [ 451.093637] el0t_64_sync_handler+0x78/0x108 > [ 451.093669] el0t_64_sync+0x1a4/0x1a8 > [ 451.093701] SMP: stopping secondary CPUs > [ 451.093777] Kernel Offset: disabled > [ 451.093797] CPU features: 0xc00181c1,a3300e42 > [ 451.093822] Memory Limit: none > > Signed-off-by: Ricardo Ribalda Delgado <ribalda@chromium.org> > --- > drivers/usb/host/xhci-mtk.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci- > mtk.c > index 90cf40d6d0c3..605b1e1a5098 100644 > --- a/drivers/usb/host/xhci-mtk.c > +++ b/drivers/usb/host/xhci-mtk.c > @@ -643,6 +643,8 @@ static int xhci_mtk_probe(struct platform_device > *pdev) > pm_runtime_put_autosuspend(dev); > pm_runtime_forbid(dev); > > +dma_set_max_seg_size(dev, UINT_MAX); > + Would you please help to add it after "device_init_wakeup(dev, true);" at about line 594. Thanks a lot > return 0; > > dealloc_usb3_hcd: > > --- > base-commit: 1b2c92a1cb2469d8c0079dbf496ab86e22e1cb7c > change-id: 20230628-mtk-usb-bf0059f64bd7 > > Best regards, > -- > Ricardo Ribalda Delgado <ribalda@chromium.org> >
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c index 90cf40d6d0c3..605b1e1a5098 100644 --- a/drivers/usb/host/xhci-mtk.c +++ b/drivers/usb/host/xhci-mtk.c @@ -643,6 +643,8 @@ static int xhci_mtk_probe(struct platform_device *pdev) pm_runtime_put_autosuspend(dev); pm_runtime_forbid(dev); + dma_set_max_seg_size(dev, UINT_MAX); + return 0; dealloc_usb3_hcd: