From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0A85C3DA41 for ; Thu, 11 Jul 2024 04:13:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tRvWdH2sgEWMYZdUksWGlEzG3jsHq5MNinuSGFz8Ric=; b=nlrq33Wcp9459LsBQLG4xz/dlx ctMpxgPxa/9S0DiAxouMWsuXYuOJo+UvdqLy17b8C+wyDi2nZ/QfDH6hfSD88NV3k/YVfTJoj4Bg8 s7PgLi9e96SR/znljatn9NsL6PCmiX+FFjwCFkJqOn+ww431bZAKKzUci48l2Hw2siWz6gTihKW4H j3xzO7gHon6Ngjr5bJfz0MlUcjlPG3oSPdxiRJXlouqfKKuXWUHYMr214ncAhOBmOGLrV2oK9099n dz615DJ12/eZfk37VjQ9iCG7g/z+PFLLsVBBN8SZQiQPSCXK4PBsE2Vh9zdFAGM68bfQhKoaUy47t NrQBdrQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRlBa-0000000Cee9-2Ar3; Thu, 11 Jul 2024 04:13:38 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sRlBJ-0000000CeYf-0n1y; Thu, 11 Jul 2024 04:13:22 +0000 X-UUID: e422554c3f3b11ef955bff358274dad2-20240710 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date:Message-ID; bh=tRvWdH2sgEWMYZdUksWGlEzG3jsHq5MNinuSGFz8Ric=; b=NpblMkigXzN5S9G2DSwzw1k0fGbyUVDauKYm3mULBHVA/wTpt41ErLPoFl1RDjk2RKRBKaXWIIVa4mFuoxhcQQJEith3L4/RQwu5f+kHVewph58v+0oj7MyddvoF+B0J/RAYofjq2MeN5a4TBhUSz9KUU0FtHRrcvYDYQ30iupk=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.40,REQID:a7cb309a-ab27-4be4-9d8e-14d51af62c5b,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:ba885a6,CLOUDID:cd19520d-46b0-425a-97d3-4623fe284021,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:1,File:nil,RT:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1, SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 0,NGT X-CID-BAS: 0,NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR,TF_CID_SPAM_ULS X-UUID: e422554c3f3b11ef955bff358274dad2-20240710 Received: from mtkmbs09n2.mediatek.inc [(172.21.101.94)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1274993414; Wed, 10 Jul 2024 21:13:13 -0700 Received: from mtkmbs13n1.mediatek.inc (172.21.101.193) by mtkmbs13n2.mediatek.inc (172.21.101.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Thu, 11 Jul 2024 12:13:11 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkmbs13n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Thu, 11 Jul 2024 12:13:07 +0800 Message-ID: Date: Thu, 11 Jul 2024 12:13:04 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Probe failure of usb controller @11290000 on MT8195 after next-20231221 Content-Language: en-US To: =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= , AngeloGioacchino Del Regno , Chunfeng Yun CC: Matthias Brugger , , , , , , Chen-Yu Tsai , Bear Wang , Pablo Sun References: <9fce9838-ef87-4d1b-b3df-63e1ddb0ec51@notapiano> <064935d8-fbda-4eda-b013-8c8fc63b561c@collabora.com> <375b2345-657a-4b8f-b5e3-dc16784ffde9@notapiano> From: Macpaul Lin In-Reply-To: <375b2345-657a-4b8f-b5e3-dc16784ffde9@notapiano> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240710_211321_257439_591144BE X-CRM114-Status: GOOD ( 27.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 7/11/24 03:15, Nícolas F. R. A. Prado wrote: > On Fri, Jan 19, 2024 at 10:12:07AM +0100, AngeloGioacchino Del Regno wrote: >> Il 18/01/24 19:36, Nícolas F. R. A. Prado ha scritto: >>> Hi, >>> >>> KernelCI has identified a failure in the probe of one of the USB controllers on >>> the MT8195-Tomato Chromebook [1]: >>> >>> [ 16.336840] xhci-mtk 11290000.usb: uwk - reg:0x400, version:104 >>> [ 16.337081] xhci-mtk 11290000.usb: xHCI Host Controller >>> [ 16.337093] xhci-mtk 11290000.usb: new USB bus registered, assigned bus number 5 >>> [ 16.357114] xhci-mtk 11290000.usb: clocks are not stable (0x1003d0f) >>> [ 16.357119] xhci-mtk 11290000.usb: can't setup: -110 >>> [ 16.357128] xhci-mtk 11290000.usb: USB bus 5 deregistered >>> [ 16.359484] xhci-mtk: probe of 11290000.usb failed with error -110 >>> >>> A previous message [2] suggests that a force-mode phy property that has been >>> merged might help with addressing the issue, however it's not clear to me how, >>> given that the controller at 1129000 uses a USB2 phy and the phy driver patch >>> only looks for the property on USB3 phys. >>> >>> Worth noting that the issue doesn't always happen. For instance the test did >>> pass for next-20240110 and then failed again on today's next [3]. But it does >>> seem that the issue was introduced, or at least became much more likely, between >>> next-20231221 and next-20240103, given that it never happened out of 10 runs >>> before, and after that has happened 5 out of 7 times. >>> >>> Note: On the Tomato Chromebook specifically this USB controller is not connected >>> to anything. >>> >>> [1] https://urldefense.com/v3/__https://linux.kernelci.org/test/case/id/659ce3506673076a8c52a428/__;!!CTRNKA9wMg0ARbw!jtg5drII8WUPwTiL4sWZiSRPXN-EBN8ctTGI85sirqvkmaUbA5z-wrLqPPfxlZZkQ7NItOWDT97OSdENT5oGHKY$ >>> [2] https://lore.kernel.org/all/239def9b-437b-9211-7844-af4332651df0@mediatek.com/ >>> [3] https://urldefense.com/v3/__https://linux.kernelci.org/test/case/id/65a8c66ee89acb56ac52a405/__;!!CTRNKA9wMg0ARbw!jtg5drII8WUPwTiL4sWZiSRPXN-EBN8ctTGI85sirqvkmaUbA5z-wrLqPPfxlZZkQ7NItOWDT97OSdENi-d0sVc$ >>> >>> Thanks, >>> Nícolas >> >> Hey Nícolas, >> >> I wonder if this is happening because of async probe... I have seen those happening >> once in a (long) while on MT8186 as well with the same kind of flakiness and I am >> not even able to reproduce anymore. >> >> For MT8195 Tomato, I guess we can simply disable that controller without any side >> effects but, at the same time, I'm not sure that this would be the right thing to >> do in this case. >> >> Besides, the controller at 11290000 is the only one that doesn't live behind MTU3, >> but I don't know if that can ring any bell.... > > An update on this issue: it looks like it only happens if "xhci-mtk > 11290000.usb" probes before "mtk-pcie-gen3 112f8000.pcie". What they have in > common is that both of those nodes use phys that share the same t-phy block: > pcie uses the usb3 phy while xhci uses the usb2 phy. So it seems that some of > the initialization done by the pcie controller might be implicitly needed by the > usb controller. > > This should help to narrow down the issue and find a proper fix for it. > > Thanks, > Nícolas 'force-mode' should only applied to the boards which require XHCI function instead of a PCIE port. For example, mt8395-genio-1200-evk.dts requires property 'force-mode' to fix probe issue for USBC @11290000. https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/commit/?h=v6.10-next/dts64&id=666e6f39faff05fe12bfc64c64aa9015135ce783 'force-mode' should be no need for tomato boards and the behavior should be the same as before. Another possibility is the firmware change on tomato boards. I'm not sure if there is any changes on tomato's recent firmware for tphy of this port, which could also be a reason causes this kind of failure. I don't have tomato boards on hand. Thanks Macpaul Lin