Received-SPF: pass (google.com: domain of linux-kernel+bounces-30940-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <064935d8-fbda-4eda-b013-8c8fc63b561c@collabora.com>
Date: Fri, 19 Jan 2024 10:12:07 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Probe failure of usb controller @11290000 on MT8195 after
 next-20231221
To: =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com>,
 Matthias Brugger <matthias.bgg@gmail.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org,
 kernel@collabora.com, Macpaul Lin <macpaul.lin@mediatek.com>,
 Chunfeng Yun <chunfeng.yun@mediatek.com>, Chen-Yu Tsai <wenst@chromium.org>
References: <9fce9838-ef87-4d1b-b3df-63e1ddb0ec51@notapiano>
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Content-Language: en-US
In-Reply-To: <9fce9838-ef87-4d1b-b3df-63e1ddb0ec51@notapiano>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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://linux.kernelci.org/test/case/id/659ce3506673076a8c52a428/
> [2] https://lore.kernel.org/all/239def9b-437b-9211-7844-af4332651df0@mediatek.com/
> [3] https://linux.kernelci.org/test/case/id/65a8c66ee89acb56ac52a405/
> 
> 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....

Cheers,
Angelo