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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DCDBC4338F for ; Wed, 28 Jul 2021 09:16:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5E2C260F9C for ; Wed, 28 Jul 2021 09:16:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231465AbhG1JQS convert rfc822-to-8bit (ORCPT ); Wed, 28 Jul 2021 05:16:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:47414 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230520AbhG1JQS (ORCPT ); Wed, 28 Jul 2021 05:16:18 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1EC6D6023F; Wed, 28 Jul 2021 09:16:17 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m8ffj-001Ud6-4P; Wed, 28 Jul 2021 10:16:15 +0100 Date: Wed, 28 Jul 2021 10:16:14 +0100 Message-ID: <878s1qer35.wl-maz@kernel.org> From: Marc Zyngier To: Guillaume Tucker Cc: Robin Murphy , kernelci-results@groups.io, Johan Jonker , Heiko Stuebner , Enric Balletbo i Serra , Maciej Matuszczyk , Jacob Chen , Sandy Huang , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Cameron Nemo , devicetree@vger.kernel.org, Elaine Zhang , Helen Koike , Shunqian Zheng , Ezequiel Garcia , Rob Herring , Yifeng Zhao , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, Collabora Kernel ML Subject: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin In-Reply-To: References: <61002766.1c69fb81.8f53.9f6a@mx.google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: guillaume.tucker@collabora.com, robin.murphy@arm.com, kernelci-results@groups.io, jbx6244@gmail.com, heiko@sntech.de, enric.balletbo@collabora.com, maccraft123mc@gmail.com, jacob2.chen@rock-chips.com, hjc@rock-chips.com, linux-kernel@vger.kernel.org, wens@csie.org, cnemo@tutanota.com, devicetree@vger.kernel.org, zhangqing@rock-chips.com, helen.koike@collabora.com, zhengsq@rock-chips.com, ezequiel@collabora.com, robh+dt@kernel.org, yifeng.zhao@rock-chips.com, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, kernel@collabora.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, 28 Jul 2021 09:59:49 +0100, Guillaume Tucker wrote: > > On 28/07/2021 09:39, Robin Murphy wrote: > > Hi Guillaume, > > > > Not sure what I did to get CC'd on this, but since I'm here... > > You were listed by get_maintainer.pl for the patch found by the > bisection: > > Robin Murphy (authored:1/8=12%,added_lines:9/71=13%,removed_lines:16/41=39%,added_lines:11/45=24%,removed_lines:18/32=56%,authored:1/12=8%,added_lines:22/83=27%,removed_lines:29/69=42%) > > Maybe the logic to automatically build the list of recipients > could look at those stats and apply some threshold if too many > people get listed because of small contributions to some files. > It's not a common issue though, usually the recipients are all > pretty relevant. > > > On 2021-07-28 07:04, Guillaume Tucker wrote: > >> Please see the bisection report below about usb2phy failing to > >> probe on rk3399-gru-kevin. > >> > >> Reports aren't automatically sent to the public while we're > >> trialing new bisection features on kernelci.org but this one > >> looks valid. > >> > >> The bisection was run in the Renesas tree but the same regression > >> is present in mainline for both usb2phy0 and usb2phy1 devices: > >> > >>    https://linux.kernelci.org/test/plan/id/6100af012344eef9b85018f3/ > >>    https://linux.kernelci.org/test/case/id/6100af012344eef9b85018fa/ > >> > >> I don't see any errors in the logs, it looks like the driver is > >> just not probing. > > > > What's the actual testcase for "rockchip-usb2phy0-probed"? If it's looking for a hard-coded path like "/sys/bus/platform/devices/ff770000.syscon:usb2-phy@e450/driver" then it can be expected to fail, since changing the node name is reflected in the device name. > > Dang, you're right. This is the test case: > > https://github.com/kernelci/bootrr/blob/main/boards/google%2Ckevin#L119 > > assert_driver_present rockchip-usb2phy-driver-present rockchip-usb2phy > assert_device_present rockchip-usb2phy0-probed rockchip-usb2phy ff770000.syscon:usb2-phy@e450 > assert_device_present rockchip-usb2phy1-probed rockchip-usb2phy ff770000.syscon:usb2-phy@e460 > > Now that needs a conditional depending on the kernel version. Or > we could try to make it more dynamic rather than with hard-coded > paths, but doing that has its own set of issues too. And this shows once more that DT churn has consequences: it breaks a userspace ABI. Changing userspace visible paths for the sake of keeping a build-time checker quiet seems counter-productive. My preference would be to just revert this patch, and instead have an annotation acknowledging the deviation from the 'standard' and keeping the checker at bay. Thanks, M. -- Without deviation from the norm, progress is not possible.