From: Marc Zyngier <maz@kernel.org>
To: Guillaume Tucker <guillaume.tucker@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
kernelci-results@groups.io, Johan Jonker <jbx6244@gmail.com>,
Heiko Stuebner <heiko@sntech.de>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Maciej Matuszczyk <maccraft123mc@gmail.com>,
Jacob Chen <jacob2.chen@rock-chips.com>,
Sandy Huang <hjc@rock-chips.com>,
linux-kernel@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>,
Cameron Nemo <cnemo@tutanota.com>,
devicetree@vger.kernel.org,
Elaine Zhang <zhangqing@rock-chips.com>,
Helen Koike <helen.koike@collabora.com>,
Shunqian Zheng <zhengsq@rock-chips.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Rob Herring <robh+dt@kernel.org>,
Yifeng Zhao <yifeng.zhao@rock-chips.com>,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
Collabora Kernel ML <kernel@collabora.com>
Subject: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
Date: Wed, 28 Jul 2021 10:16:14 +0100 [thread overview]
Message-ID: <878s1qer35.wl-maz@kernel.org> (raw)
In-Reply-To: <cff1e2d1-ceee-eee8-de14-a268429acbc3@collabora.com>
On Wed, 28 Jul 2021 09:59:49 +0100,
Guillaume Tucker <guillaume.tucker@collabora.com> 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 <robin.murphy@arm.com> (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.
next prev parent reply other threads:[~2021-07-28 9:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <61002766.1c69fb81.8f53.9f6a@mx.google.com>
2021-07-28 6:04 ` renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin Guillaume Tucker
2021-07-28 8:17 ` Geert Uytterhoeven
2021-07-28 8:21 ` Geert Uytterhoeven
2021-07-28 8:48 ` Guillaume Tucker
2021-07-28 8:39 ` Robin Murphy
2021-07-28 8:59 ` Guillaume Tucker
2021-07-28 9:16 ` Marc Zyngier [this message]
2021-07-28 9:51 ` Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin) Heiko Stübner
2021-10-01 10:00 ` Guillaume Tucker
2021-10-01 16:12 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878s1qer35.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=cnemo@tutanota.com \
--cc=devicetree@vger.kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=ezequiel@collabora.com \
--cc=guillaume.tucker@collabora.com \
--cc=heiko@sntech.de \
--cc=helen.koike@collabora.com \
--cc=hjc@rock-chips.com \
--cc=jacob2.chen@rock-chips.com \
--cc=jbx6244@gmail.com \
--cc=kernel@collabora.com \
--cc=kernelci-results@groups.io \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maccraft123mc@gmail.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=wens@csie.org \
--cc=yifeng.zhao@rock-chips.com \
--cc=zhangqing@rock-chips.com \
--cc=zhengsq@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).