* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 6:04 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 6:04 UTC (permalink / raw)
To: kernelci-results, Johan Jonker, Heiko Stuebner
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
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.
Best wishes,
Guillaume
On 27/07/2021 16:33, KernelCI bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer: *
> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>
> Summary:
> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: renesas
> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
> Branch: master
> Target: rk3399-gru-kevin
> CPU arch: arm64
> Lab: lab-collabora
> Compiler: gcc-8
> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>
> Breaking commit found:
>
> -------------------------------------------------------------------------------
> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> Author: Johan Jonker <jbx6244@gmail.com>
> Date: Tue Jun 1 18:47:59 2021 +0200
>
> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
> in phy-provider.yaml has required "#phy-cells" for phy nodes.
> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
> notifications.
>
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
> phy/phy-provider.yaml
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
> index 4e243d72e16f..248ebb61aa79 100644
> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> @@ -822,7 +822,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - u2phy: usb2-phy@100 {
> + u2phy: usb2phy@100 {
> compatible = "rockchip,px30-usb2phy";
> reg = <0x100 0x20>;
> clocks = <&pmucru SCLK_USBPHY_REF>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index bc0bdc3d86ff..8c821acb21ff 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -819,7 +819,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - u2phy: usb2-phy@100 {
> + u2phy: usb2phy@100 {
> compatible = "rockchip,rk3328-usb2phy";
> reg = <0x100 0x10>;
> clocks = <&xin24m>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index a2eba5357693..c1a253507ac4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1418,7 +1418,7 @@
> status = "disabled";
> };
>
> - u2phy0: usb2-phy@e450 {
> + u2phy0: usb2phy@e450 {
> compatible = "rockchip,rk3399-usb2phy";
> reg = <0xe450 0x10>;
> clocks = <&cru SCLK_USB2PHY0_REF>;
> @@ -1445,7 +1445,7 @@
> };
> };
>
> - u2phy1: usb2-phy@e460 {
> + u2phy1: usb2phy@e460 {
> compatible = "rockchip,rk3399-usb2phy";
> reg = <0xe460 0x10>;
> clocks = <&cru SCLK_USB2PHY1_REF>;
> -------------------------------------------------------------------------------
>
>
> Git bisection log:
>
> -------------------------------------------------------------------------------
> git bisect start
> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
> git bisect good 837188d49823230f47afdbbec7556740e89a8557
> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> -------------------------------------------------------------------------------
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
> Mute This Topic: https://groups.io/mt/84484486/924702
> Group Owner: kernelci-results+owner@groups.io
> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 6:04 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 6:04 UTC (permalink / raw)
To: kernelci-results, Johan Jonker, Heiko Stuebner
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
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.
Best wishes,
Guillaume
On 27/07/2021 16:33, KernelCI bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer: *
> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>
> Summary:
> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: renesas
> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
> Branch: master
> Target: rk3399-gru-kevin
> CPU arch: arm64
> Lab: lab-collabora
> Compiler: gcc-8
> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>
> Breaking commit found:
>
> -------------------------------------------------------------------------------
> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> Author: Johan Jonker <jbx6244@gmail.com>
> Date: Tue Jun 1 18:47:59 2021 +0200
>
> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
> in phy-provider.yaml has required "#phy-cells" for phy nodes.
> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
> notifications.
>
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
> phy/phy-provider.yaml
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
> index 4e243d72e16f..248ebb61aa79 100644
> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> @@ -822,7 +822,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - u2phy: usb2-phy@100 {
> + u2phy: usb2phy@100 {
> compatible = "rockchip,px30-usb2phy";
> reg = <0x100 0x20>;
> clocks = <&pmucru SCLK_USBPHY_REF>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index bc0bdc3d86ff..8c821acb21ff 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -819,7 +819,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - u2phy: usb2-phy@100 {
> + u2phy: usb2phy@100 {
> compatible = "rockchip,rk3328-usb2phy";
> reg = <0x100 0x10>;
> clocks = <&xin24m>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index a2eba5357693..c1a253507ac4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1418,7 +1418,7 @@
> status = "disabled";
> };
>
> - u2phy0: usb2-phy@e450 {
> + u2phy0: usb2phy@e450 {
> compatible = "rockchip,rk3399-usb2phy";
> reg = <0xe450 0x10>;
> clocks = <&cru SCLK_USB2PHY0_REF>;
> @@ -1445,7 +1445,7 @@
> };
> };
>
> - u2phy1: usb2-phy@e460 {
> + u2phy1: usb2phy@e460 {
> compatible = "rockchip,rk3399-usb2phy";
> reg = <0xe460 0x10>;
> clocks = <&cru SCLK_USB2PHY1_REF>;
> -------------------------------------------------------------------------------
>
>
> Git bisection log:
>
> -------------------------------------------------------------------------------
> git bisect start
> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
> git bisect good 837188d49823230f47afdbbec7556740e89a8557
> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
> -------------------------------------------------------------------------------
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
> Mute This Topic: https://groups.io/mt/84484486/924702
> Group Owner: kernelci-results+owner@groups.io
> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
2021-07-28 6:04 ` Guillaume Tucker
(?)
@ 2021-07-28 8:17 ` Geert Uytterhoeven
-1 siblings, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2021-07-28 8:17 UTC (permalink / raw)
To: Guillaume Tucker
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
Hi Guillaume et al,
On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
<guillaume.tucker@collabora.com> 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.
Thanks for your report!
> The bisection was run in the Renesas tree but the same regression
> is present in mainline for both usb2phy0 and usb2phy1 devices:
Exactly, the faulty commit is part of v5.14-rc1.
> > Breaking commit found:
> >
> > -------------------------------------------------------------------------------
> > commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> > Author: Johan Jonker <jbx6244@gmail.com>
> > Date: Tue Jun 1 18:47:59 2021 +0200
> >
> > arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
(a) issues on non-Renesas platforms[2], and
(b) issues not originating in the renesas-devel tree, like this one.
Suggestions for improvement:
1. If a regression is detected in an upstream tree, there is no
need to report it for downstream trees, unless it affects
the downstream tree, or originated there.
2. If a regression is detected for a platform, there is no need
to report it for different platform trees, unless it originated
there.
BTW, I do look at the reports for Renesas platforms, but usually I
don't see what's wrong, and the same platform works fine locally.
Note that yesterday and today I get "Error while loading data from the
server (error code: 500). Please contact the website administrator".
Thanks!
[1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
[2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2021-07-28 8:17 UTC (permalink / raw)
To: Guillaume Tucker
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
Hi Guillaume et al,
On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
<guillaume.tucker@collabora.com> 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.
Thanks for your report!
> The bisection was run in the Renesas tree but the same regression
> is present in mainline for both usb2phy0 and usb2phy1 devices:
Exactly, the faulty commit is part of v5.14-rc1.
> > Breaking commit found:
> >
> > -------------------------------------------------------------------------------
> > commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> > Author: Johan Jonker <jbx6244@gmail.com>
> > Date: Tue Jun 1 18:47:59 2021 +0200
> >
> > arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
(a) issues on non-Renesas platforms[2], and
(b) issues not originating in the renesas-devel tree, like this one.
Suggestions for improvement:
1. If a regression is detected in an upstream tree, there is no
need to report it for downstream trees, unless it affects
the downstream tree, or originated there.
2. If a regression is detected for a platform, there is no need
to report it for different platform trees, unless it originated
there.
BTW, I do look at the reports for Renesas platforms, but usually I
don't see what's wrong, and the same platform works fine locally.
Note that yesterday and today I get "Error while loading data from the
server (error code: 500). Please contact the website administrator".
Thanks!
[1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
[2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:17 ` Geert Uytterhoeven
0 siblings, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2021-07-28 8:17 UTC (permalink / raw)
To: Guillaume Tucker
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
Hi Guillaume et al,
On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
<guillaume.tucker@collabora.com> 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.
Thanks for your report!
> The bisection was run in the Renesas tree but the same regression
> is present in mainline for both usb2phy0 and usb2phy1 devices:
Exactly, the faulty commit is part of v5.14-rc1.
> > Breaking commit found:
> >
> > -------------------------------------------------------------------------------
> > commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> > Author: Johan Jonker <jbx6244@gmail.com>
> > Date: Tue Jun 1 18:47:59 2021 +0200
> >
> > arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
(a) issues on non-Renesas platforms[2], and
(b) issues not originating in the renesas-devel tree, like this one.
Suggestions for improvement:
1. If a regression is detected in an upstream tree, there is no
need to report it for downstream trees, unless it affects
the downstream tree, or originated there.
2. If a regression is detected for a platform, there is no need
to report it for different platform trees, unless it originated
there.
BTW, I do look at the reports for Renesas platforms, but usually I
don't see what's wrong, and the same platform works fine locally.
Note that yesterday and today I get "Error while loading data from the
server (error code: 500). Please contact the website administrator".
Thanks!
[1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
[2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
2021-07-28 8:17 ` Geert Uytterhoeven
(?)
@ 2021-07-28 8:21 ` Geert Uytterhoeven
-1 siblings, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2021-07-28 8:21 UTC (permalink / raw)
To: Guillaume Tucker
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
CC kernelci@groups.io
dropped kernelci-reports@groups.io ("500 This message has been flagged as spam")
dropped Jacob ("550 jacob2.chen@rock-chips.com:user not exist")
On Wed, Jul 28, 2021 at 10:17 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Guillaume et al,
>
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> 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.
>
> Thanks for your report!
>
> > The bisection was run in the Renesas tree but the same regression
> > is present in mainline for both usb2phy0 and usb2phy1 devices:
>
> Exactly, the faulty commit is part of v5.14-rc1.
>
> > > Breaking commit found:
> > >
> > > -------------------------------------------------------------------------------
> > > commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> > > Author: Johan Jonker <jbx6244@gmail.com>
> > > Date: Tue Jun 1 18:47:59 2021 +0200
> > >
> > > arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
> (a) issues on non-Renesas platforms[2], and
> (b) issues not originating in the renesas-devel tree, like this one.
>
> Suggestions for improvement:
> 1. If a regression is detected in an upstream tree, there is no
> need to report it for downstream trees, unless it affects
> the downstream tree, or originated there.
> 2. If a regression is detected for a platform, there is no need
> to report it for different platform trees, unless it originated
> there.
>
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.
> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".
>
> Thanks!
>
> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:21 ` Geert Uytterhoeven
0 siblings, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2021-07-28 8:21 UTC (permalink / raw)
To: Guillaume Tucker
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
CC kernelci@groups.io
dropped kernelci-reports@groups.io ("500 This message has been flagged as spam")
dropped Jacob ("550 jacob2.chen@rock-chips.com:user not exist")
On Wed, Jul 28, 2021 at 10:17 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Guillaume et al,
>
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> 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.
>
> Thanks for your report!
>
> > The bisection was run in the Renesas tree but the same regression
> > is present in mainline for both usb2phy0 and usb2phy1 devices:
>
> Exactly, the faulty commit is part of v5.14-rc1.
>
> > > Breaking commit found:
> > >
> > > -------------------------------------------------------------------------------
> > > commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> > > Author: Johan Jonker <jbx6244@gmail.com>
> > > Date: Tue Jun 1 18:47:59 2021 +0200
> > >
> > > arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
> (a) issues on non-Renesas platforms[2], and
> (b) issues not originating in the renesas-devel tree, like this one.
>
> Suggestions for improvement:
> 1. If a regression is detected in an upstream tree, there is no
> need to report it for downstream trees, unless it affects
> the downstream tree, or originated there.
> 2. If a regression is detected for a platform, there is no need
> to report it for different platform trees, unless it originated
> there.
>
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.
> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".
>
> Thanks!
>
> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:21 ` Geert Uytterhoeven
0 siblings, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2021-07-28 8:21 UTC (permalink / raw)
To: Guillaume Tucker
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
CC kernelci@groups.io
dropped kernelci-reports@groups.io ("500 This message has been flagged as spam")
dropped Jacob ("550 jacob2.chen@rock-chips.com:user not exist")
On Wed, Jul 28, 2021 at 10:17 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Guillaume et al,
>
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> 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.
>
> Thanks for your report!
>
> > The bisection was run in the Renesas tree but the same regression
> > is present in mainline for both usb2phy0 and usb2phy1 devices:
>
> Exactly, the faulty commit is part of v5.14-rc1.
>
> > > Breaking commit found:
> > >
> > > -------------------------------------------------------------------------------
> > > commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
> > > Author: Johan Jonker <jbx6244@gmail.com>
> > > Date: Tue Jun 1 18:47:59 2021 +0200
> > >
> > > arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
> (a) issues on non-Renesas platforms[2], and
> (b) issues not originating in the renesas-devel tree, like this one.
>
> Suggestions for improvement:
> 1. If a regression is detected in an upstream tree, there is no
> need to report it for downstream trees, unless it affects
> the downstream tree, or originated there.
> 2. If a regression is detected for a platform, there is no need
> to report it for different platform trees, unless it originated
> there.
>
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.
> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".
>
> Thanks!
>
> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
2021-07-28 8:17 ` Geert Uytterhoeven
(?)
@ 2021-07-28 8:48 ` Guillaume Tucker
-1 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 8:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
On 28/07/2021 09:17, Geert Uytterhoeven wrote:
> Hi Guillaume et al,
>
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> 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.
>
> Thanks for your report!
>
>> The bisection was run in the Renesas tree but the same regression
>> is present in mainline for both usb2phy0 and usb2phy1 devices:
>
> Exactly, the faulty commit is part of v5.14-rc1.
>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date: Tue Jun 1 18:47:59 2021 +0200
>>>
>>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
> (a) issues on non-Renesas platforms[2], and
One thing to distinguish here is that changes in a tree like the
Renesas one might actually break other platforms, even if it
seems unlikely. But the improvement explained below addresses
this issue.
> (b) issues not originating in the renesas-devel tree, like this one.
That is just because I found the bisection report from the
Renesas tree before getting one from mainline. As we're manually
triaging reports, I mentioned it in my email. And you're right,
we would need to take this into account before having all the
bisection reports sent automatically.
> Suggestions for improvement:
> 1. If a regression is detected in an upstream tree, there is no
> need to report it for downstream trees, unless it affects
> the downstream tree, or originated there.
That's right, we're working on an improvement to be able to
detect "2nd order" regressions, that is to say new failures in a
branch relatively to new failures in an upstream branch. That
would be typically mainline or stable, but sometimes a subsystem
specific one.
> 2. If a regression is detected for a platform, there is no need
> to report it for different platform trees, unless it originated
> there.
>
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.
Until this has been improved, maybe we can just stop sending
email reports to linux-reneas-soc if they're mostly noise. The
bisections will still run and reports like this one are sent to
the people and lists who are related to the changes in the patch
rather than the git tree so it's always relevant to them.
> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".
Yes that's because the Mongo DB service keeps crashing. It's a
sysadmin issue that should hopefully get resolved soon, sorry for
the inconvenience.
Thanks for your feedback.
Best wishes,
Guillaume
> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:48 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 8:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
On 28/07/2021 09:17, Geert Uytterhoeven wrote:
> Hi Guillaume et al,
>
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> 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.
>
> Thanks for your report!
>
>> The bisection was run in the Renesas tree but the same regression
>> is present in mainline for both usb2phy0 and usb2phy1 devices:
>
> Exactly, the faulty commit is part of v5.14-rc1.
>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date: Tue Jun 1 18:47:59 2021 +0200
>>>
>>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
> (a) issues on non-Renesas platforms[2], and
One thing to distinguish here is that changes in a tree like the
Renesas one might actually break other platforms, even if it
seems unlikely. But the improvement explained below addresses
this issue.
> (b) issues not originating in the renesas-devel tree, like this one.
That is just because I found the bisection report from the
Renesas tree before getting one from mainline. As we're manually
triaging reports, I mentioned it in my email. And you're right,
we would need to take this into account before having all the
bisection reports sent automatically.
> Suggestions for improvement:
> 1. If a regression is detected in an upstream tree, there is no
> need to report it for downstream trees, unless it affects
> the downstream tree, or originated there.
That's right, we're working on an improvement to be able to
detect "2nd order" regressions, that is to say new failures in a
branch relatively to new failures in an upstream branch. That
would be typically mainline or stable, but sometimes a subsystem
specific one.
> 2. If a regression is detected for a platform, there is no need
> to report it for different platform trees, unless it originated
> there.
>
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.
Until this has been improved, maybe we can just stop sending
email reports to linux-reneas-soc if they're mostly noise. The
bisections will still run and reports like this one are sent to
the people and lists who are related to the changes in the patch
rather than the git tree so it's always relevant to them.
> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".
Yes that's because the Mongo DB service keeps crashing. It's a
sysadmin issue that should hopefully get resolved soon, sorry for
the inconvenience.
Thanks for your feedback.
Best wishes,
Guillaume
> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:48 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 8:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: kernelci-results, Johan Jonker, Heiko Stuebner,
Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
Linux Kernel Mailing List, Chen-Yu Tsai, Cameron Nemo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Elaine Zhang, Helen Koike, Robin Murphy, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, Linux ARM,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
On 28/07/2021 09:17, Geert Uytterhoeven wrote:
> Hi Guillaume et al,
>
> On Wed, Jul 28, 2021 at 8:05 AM Guillaume Tucker
> <guillaume.tucker@collabora.com> 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.
>
> Thanks for your report!
>
>> The bisection was run in the Renesas tree but the same regression
>> is present in mainline for both usb2phy0 and usb2phy1 devices:
>
> Exactly, the faulty commit is part of v5.14-rc1.
>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date: Tue Jun 1 18:47:59 2021 +0200
>>>
>>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>
> P.S. KernelCI is sending lots of reports to linux-reneas-soc[1] for
> (a) issues on non-Renesas platforms[2], and
One thing to distinguish here is that changes in a tree like the
Renesas one might actually break other platforms, even if it
seems unlikely. But the improvement explained below addresses
this issue.
> (b) issues not originating in the renesas-devel tree, like this one.
That is just because I found the bisection report from the
Renesas tree before getting one from mainline. As we're manually
triaging reports, I mentioned it in my email. And you're right,
we would need to take this into account before having all the
bisection reports sent automatically.
> Suggestions for improvement:
> 1. If a regression is detected in an upstream tree, there is no
> need to report it for downstream trees, unless it affects
> the downstream tree, or originated there.
That's right, we're working on an improvement to be able to
detect "2nd order" regressions, that is to say new failures in a
branch relatively to new failures in an upstream branch. That
would be typically mainline or stable, but sometimes a subsystem
specific one.
> 2. If a regression is detected for a platform, there is no need
> to report it for different platform trees, unless it originated
> there.
>
> BTW, I do look at the reports for Renesas platforms, but usually I
> don't see what's wrong, and the same platform works fine locally.
Until this has been improved, maybe we can just stop sending
email reports to linux-reneas-soc if they're mostly noise. The
bisections will still run and reports like this one are sent to
the people and lists who are related to the changes in the patch
rather than the git tree so it's always relevant to them.
> Note that yesterday and today I get "Error while loading data from the
> server (error code: 500). Please contact the website administrator".
Yes that's because the Mongo DB service keeps crashing. It's a
sysadmin issue that should hopefully get resolved soon, sorry for
the inconvenience.
Thanks for your feedback.
Best wishes,
Guillaume
> [1] https://lore.kernel.org/linux-renesas-soc/?q=kernelci.org
> [2] https://lore.kernel.org/linux-renesas-soc/60ff86ff.1c69fb81.dfe6f.6a7c@mx.google.com/
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
2021-07-28 6:04 ` Guillaume Tucker
(?)
@ 2021-07-28 8:39 ` Robin Murphy
-1 siblings, 0 replies; 30+ messages in thread
From: Robin Murphy @ 2021-07-28 8:39 UTC (permalink / raw)
To: Guillaume Tucker, kernelci-results, Johan Jonker, Heiko Stuebner
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Shunqian Zheng, Ezequiel Garcia,
Rob Herring, Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
Hi Guillaume,
Not sure what I did to get CC'd on this, but since I'm here...
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.
Robin.
> Best wishes,
> Guillaume
>
>
> On 27/07/2021 16:33, KernelCI bot wrote:
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> * This automated bisection report was sent to you on the basis *
>> * that you may be involved with the breaking commit it has *
>> * found. No manual investigation has been done to verify it, *
>> * and the root cause of the problem may be somewhere else. *
>> * *
>> * If you do send a fix, please include this trailer: *
>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
>> * *
>> * Hope this helps! *
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>>
>> Summary:
>> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
>> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
>> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>
>> Checks:
>> revert: PASS
>> verify: PASS
>>
>> Parameters:
>> Tree: renesas
>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
>> Branch: master
>> Target: rk3399-gru-kevin
>> CPU arch: arm64
>> Lab: lab-collabora
>> Compiler: gcc-8
>> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
>> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>>
>> Breaking commit found:
>>
>> -------------------------------------------------------------------------------
>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>> Author: Johan Jonker <jbx6244@gmail.com>
>> Date: Tue Jun 1 18:47:59 2021 +0200
>>
>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>
>> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
>> in phy-provider.yaml has required "#phy-cells" for phy nodes.
>> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
>> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
>> notifications.
>>
>> make ARCH=arm64 dtbs_check
>> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
>> phy/phy-provider.yaml
>>
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
>> index 4e243d72e16f..248ebb61aa79 100644
>> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
>> @@ -822,7 +822,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - u2phy: usb2-phy@100 {
>> + u2phy: usb2phy@100 {
>> compatible = "rockchip,px30-usb2phy";
>> reg = <0x100 0x20>;
>> clocks = <&pmucru SCLK_USBPHY_REF>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> index bc0bdc3d86ff..8c821acb21ff 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> @@ -819,7 +819,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - u2phy: usb2-phy@100 {
>> + u2phy: usb2phy@100 {
>> compatible = "rockchip,rk3328-usb2phy";
>> reg = <0x100 0x10>;
>> clocks = <&xin24m>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index a2eba5357693..c1a253507ac4 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -1418,7 +1418,7 @@
>> status = "disabled";
>> };
>>
>> - u2phy0: usb2-phy@e450 {
>> + u2phy0: usb2phy@e450 {
>> compatible = "rockchip,rk3399-usb2phy";
>> reg = <0xe450 0x10>;
>> clocks = <&cru SCLK_USB2PHY0_REF>;
>> @@ -1445,7 +1445,7 @@
>> };
>> };
>>
>> - u2phy1: usb2-phy@e460 {
>> + u2phy1: usb2phy@e460 {
>> compatible = "rockchip,rk3399-usb2phy";
>> reg = <0xe460 0x10>;
>> clocks = <&cru SCLK_USB2PHY1_REF>;
>> -------------------------------------------------------------------------------
>>
>>
>> Git bisection log:
>>
>> -------------------------------------------------------------------------------
>> git bisect start
>> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
>> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
>> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
>> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
>> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
>> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
>> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
>> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
>> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
>> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
>> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
>> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
>> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
>> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
>> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
>> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
>> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
>> git bisect good 837188d49823230f47afdbbec7556740e89a8557
>> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
>> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
>> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
>> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
>> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
>> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
>> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>> -------------------------------------------------------------------------------
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
>> Mute This Topic: https://groups.io/mt/84484486/924702
>> Group Owner: kernelci-results+owner@groups.io
>> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:39 ` Robin Murphy
0 siblings, 0 replies; 30+ messages in thread
From: Robin Murphy @ 2021-07-28 8:39 UTC (permalink / raw)
To: Guillaume Tucker, kernelci-results, Johan Jonker, Heiko Stuebner
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Shunqian Zheng, Ezequiel Garcia,
Rob Herring, Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
Hi Guillaume,
Not sure what I did to get CC'd on this, but since I'm here...
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.
Robin.
> Best wishes,
> Guillaume
>
>
> On 27/07/2021 16:33, KernelCI bot wrote:
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> * This automated bisection report was sent to you on the basis *
>> * that you may be involved with the breaking commit it has *
>> * found. No manual investigation has been done to verify it, *
>> * and the root cause of the problem may be somewhere else. *
>> * *
>> * If you do send a fix, please include this trailer: *
>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
>> * *
>> * Hope this helps! *
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>>
>> Summary:
>> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
>> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
>> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>
>> Checks:
>> revert: PASS
>> verify: PASS
>>
>> Parameters:
>> Tree: renesas
>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
>> Branch: master
>> Target: rk3399-gru-kevin
>> CPU arch: arm64
>> Lab: lab-collabora
>> Compiler: gcc-8
>> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
>> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>>
>> Breaking commit found:
>>
>> -------------------------------------------------------------------------------
>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>> Author: Johan Jonker <jbx6244@gmail.com>
>> Date: Tue Jun 1 18:47:59 2021 +0200
>>
>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>
>> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
>> in phy-provider.yaml has required "#phy-cells" for phy nodes.
>> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
>> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
>> notifications.
>>
>> make ARCH=arm64 dtbs_check
>> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
>> phy/phy-provider.yaml
>>
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
>> index 4e243d72e16f..248ebb61aa79 100644
>> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
>> @@ -822,7 +822,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - u2phy: usb2-phy@100 {
>> + u2phy: usb2phy@100 {
>> compatible = "rockchip,px30-usb2phy";
>> reg = <0x100 0x20>;
>> clocks = <&pmucru SCLK_USBPHY_REF>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> index bc0bdc3d86ff..8c821acb21ff 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> @@ -819,7 +819,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - u2phy: usb2-phy@100 {
>> + u2phy: usb2phy@100 {
>> compatible = "rockchip,rk3328-usb2phy";
>> reg = <0x100 0x10>;
>> clocks = <&xin24m>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index a2eba5357693..c1a253507ac4 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -1418,7 +1418,7 @@
>> status = "disabled";
>> };
>>
>> - u2phy0: usb2-phy@e450 {
>> + u2phy0: usb2phy@e450 {
>> compatible = "rockchip,rk3399-usb2phy";
>> reg = <0xe450 0x10>;
>> clocks = <&cru SCLK_USB2PHY0_REF>;
>> @@ -1445,7 +1445,7 @@
>> };
>> };
>>
>> - u2phy1: usb2-phy@e460 {
>> + u2phy1: usb2phy@e460 {
>> compatible = "rockchip,rk3399-usb2phy";
>> reg = <0xe460 0x10>;
>> clocks = <&cru SCLK_USB2PHY1_REF>;
>> -------------------------------------------------------------------------------
>>
>>
>> Git bisection log:
>>
>> -------------------------------------------------------------------------------
>> git bisect start
>> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
>> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
>> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
>> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
>> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
>> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
>> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
>> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
>> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
>> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
>> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
>> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
>> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
>> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
>> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
>> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
>> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
>> git bisect good 837188d49823230f47afdbbec7556740e89a8557
>> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
>> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
>> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
>> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
>> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
>> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
>> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>> -------------------------------------------------------------------------------
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
>> Mute This Topic: https://groups.io/mt/84484486/924702
>> Group Owner: kernelci-results+owner@groups.io
>> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:39 ` Robin Murphy
0 siblings, 0 replies; 30+ messages in thread
From: Robin Murphy @ 2021-07-28 8:39 UTC (permalink / raw)
To: Guillaume Tucker, kernelci-results, Johan Jonker, Heiko Stuebner
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Shunqian Zheng, Ezequiel Garcia,
Rob Herring, Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
Hi Guillaume,
Not sure what I did to get CC'd on this, but since I'm here...
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.
Robin.
> Best wishes,
> Guillaume
>
>
> On 27/07/2021 16:33, KernelCI bot wrote:
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> * This automated bisection report was sent to you on the basis *
>> * that you may be involved with the breaking commit it has *
>> * found. No manual investigation has been done to verify it, *
>> * and the root cause of the problem may be somewhere else. *
>> * *
>> * If you do send a fix, please include this trailer: *
>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
>> * *
>> * Hope this helps! *
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>>
>> Summary:
>> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
>> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
>> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>
>> Checks:
>> revert: PASS
>> verify: PASS
>>
>> Parameters:
>> Tree: renesas
>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
>> Branch: master
>> Target: rk3399-gru-kevin
>> CPU arch: arm64
>> Lab: lab-collabora
>> Compiler: gcc-8
>> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
>> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>>
>> Breaking commit found:
>>
>> -------------------------------------------------------------------------------
>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>> Author: Johan Jonker <jbx6244@gmail.com>
>> Date: Tue Jun 1 18:47:59 2021 +0200
>>
>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>
>> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
>> in phy-provider.yaml has required "#phy-cells" for phy nodes.
>> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
>> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
>> notifications.
>>
>> make ARCH=arm64 dtbs_check
>> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
>> phy/phy-provider.yaml
>>
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
>> index 4e243d72e16f..248ebb61aa79 100644
>> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
>> @@ -822,7 +822,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - u2phy: usb2-phy@100 {
>> + u2phy: usb2phy@100 {
>> compatible = "rockchip,px30-usb2phy";
>> reg = <0x100 0x20>;
>> clocks = <&pmucru SCLK_USBPHY_REF>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> index bc0bdc3d86ff..8c821acb21ff 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>> @@ -819,7 +819,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> - u2phy: usb2-phy@100 {
>> + u2phy: usb2phy@100 {
>> compatible = "rockchip,rk3328-usb2phy";
>> reg = <0x100 0x10>;
>> clocks = <&xin24m>;
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> index a2eba5357693..c1a253507ac4 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -1418,7 +1418,7 @@
>> status = "disabled";
>> };
>>
>> - u2phy0: usb2-phy@e450 {
>> + u2phy0: usb2phy@e450 {
>> compatible = "rockchip,rk3399-usb2phy";
>> reg = <0xe450 0x10>;
>> clocks = <&cru SCLK_USB2PHY0_REF>;
>> @@ -1445,7 +1445,7 @@
>> };
>> };
>>
>> - u2phy1: usb2-phy@e460 {
>> + u2phy1: usb2phy@e460 {
>> compatible = "rockchip,rk3399-usb2phy";
>> reg = <0xe460 0x10>;
>> clocks = <&cru SCLK_USB2PHY1_REF>;
>> -------------------------------------------------------------------------------
>>
>>
>> Git bisection log:
>>
>> -------------------------------------------------------------------------------
>> git bisect start
>> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
>> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
>> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
>> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
>> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
>> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
>> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
>> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
>> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
>> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
>> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
>> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
>> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
>> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
>> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
>> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
>> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
>> git bisect good 837188d49823230f47afdbbec7556740e89a8557
>> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
>> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
>> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
>> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
>> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
>> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
>> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>> -------------------------------------------------------------------------------
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
>> Mute This Topic: https://groups.io/mt/84484486/924702
>> Group Owner: kernelci-results+owner@groups.io
>> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
2021-07-28 8:39 ` Robin Murphy
(?)
@ 2021-07-28 8:59 ` Guillaume Tucker
-1 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 8:59 UTC (permalink / raw)
To: Robin Murphy, kernelci-results, Johan Jonker, Heiko Stuebner,
Enric Balletbo i Serra
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Shunqian Zheng, Ezequiel Garcia,
Rob Herring, Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
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.
Enric, is this something you can take care of?
Best wishes,
Guillaume
>> On 27/07/2021 16:33, KernelCI bot wrote:
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>> * This automated bisection report was sent to you on the basis *
>>> * that you may be involved with the breaking commit it has *
>>> * found. No manual investigation has been done to verify it, *
>>> * and the root cause of the problem may be somewhere else. *
>>> * *
>>> * If you do send a fix, please include this trailer: *
>>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
>>> * *
>>> * Hope this helps! *
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>>>
>>> Summary:
>>> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>>> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
>>> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
>>> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>>
>>> Checks:
>>> revert: PASS
>>> verify: PASS
>>>
>>> Parameters:
>>> Tree: renesas
>>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
>>> Branch: master
>>> Target: rk3399-gru-kevin
>>> CPU arch: arm64
>>> Lab: lab-collabora
>>> Compiler: gcc-8
>>> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
>>> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>>>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date: Tue Jun 1 18:47:59 2021 +0200
>>>
>>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
>>> in phy-provider.yaml has required "#phy-cells" for phy nodes.
>>> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
>>> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
>>> notifications.
>>> make ARCH=arm64 dtbs_check
>>> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
>>> phy/phy-provider.yaml
>>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>>> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
>>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> index 4e243d72e16f..248ebb61aa79 100644
>>> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> @@ -822,7 +822,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - u2phy: usb2-phy@100 {
>>> + u2phy: usb2phy@100 {
>>> compatible = "rockchip,px30-usb2phy";
>>> reg = <0x100 0x20>;
>>> clocks = <&pmucru SCLK_USBPHY_REF>;
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> index bc0bdc3d86ff..8c821acb21ff 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> @@ -819,7 +819,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - u2phy: usb2-phy@100 {
>>> + u2phy: usb2phy@100 {
>>> compatible = "rockchip,rk3328-usb2phy";
>>> reg = <0x100 0x10>;
>>> clocks = <&xin24m>;
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> index a2eba5357693..c1a253507ac4 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> @@ -1418,7 +1418,7 @@
>>> status = "disabled";
>>> };
>>> - u2phy0: usb2-phy@e450 {
>>> + u2phy0: usb2phy@e450 {
>>> compatible = "rockchip,rk3399-usb2phy";
>>> reg = <0xe450 0x10>;
>>> clocks = <&cru SCLK_USB2PHY0_REF>;
>>> @@ -1445,7 +1445,7 @@
>>> };
>>> };
>>> - u2phy1: usb2-phy@e460 {
>>> + u2phy1: usb2phy@e460 {
>>> compatible = "rockchip,rk3399-usb2phy";
>>> reg = <0xe460 0x10>;
>>> clocks = <&cru SCLK_USB2PHY1_REF>;
>>> -------------------------------------------------------------------------------
>>>
>>>
>>> Git bisection log:
>>>
>>> -------------------------------------------------------------------------------
>>> git bisect start
>>> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
>>> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
>>> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>>> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
>>> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>>> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
>>> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>>> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
>>> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>>> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
>>> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>>> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
>>> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
>>> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
>>> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>>> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
>>> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
>>> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
>>> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
>>> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
>>> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
>>> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
>>> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
>>> git bisect good 837188d49823230f47afdbbec7556740e89a8557
>>> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
>>> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
>>> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
>>> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
>>> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
>>> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
>>> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> -------------------------------------------------------------------------------
>>>
>>>
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Groups.io Links: You receive all messages sent to this group.
>>> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
>>> Mute This Topic: https://groups.io/mt/84484486/924702
>>> Group Owner: kernelci-results+owner@groups.io
>>> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>
>>>
>>
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:59 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 8:59 UTC (permalink / raw)
To: Robin Murphy, kernelci-results, Johan Jonker, Heiko Stuebner,
Enric Balletbo i Serra
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Shunqian Zheng, Ezequiel Garcia,
Rob Herring, Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
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.
Enric, is this something you can take care of?
Best wishes,
Guillaume
>> On 27/07/2021 16:33, KernelCI bot wrote:
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>> * This automated bisection report was sent to you on the basis *
>>> * that you may be involved with the breaking commit it has *
>>> * found. No manual investigation has been done to verify it, *
>>> * and the root cause of the problem may be somewhere else. *
>>> * *
>>> * If you do send a fix, please include this trailer: *
>>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
>>> * *
>>> * Hope this helps! *
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>>>
>>> Summary:
>>> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>>> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
>>> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
>>> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>>
>>> Checks:
>>> revert: PASS
>>> verify: PASS
>>>
>>> Parameters:
>>> Tree: renesas
>>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
>>> Branch: master
>>> Target: rk3399-gru-kevin
>>> CPU arch: arm64
>>> Lab: lab-collabora
>>> Compiler: gcc-8
>>> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
>>> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>>>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date: Tue Jun 1 18:47:59 2021 +0200
>>>
>>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
>>> in phy-provider.yaml has required "#phy-cells" for phy nodes.
>>> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
>>> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
>>> notifications.
>>> make ARCH=arm64 dtbs_check
>>> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
>>> phy/phy-provider.yaml
>>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>>> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
>>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> index 4e243d72e16f..248ebb61aa79 100644
>>> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> @@ -822,7 +822,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - u2phy: usb2-phy@100 {
>>> + u2phy: usb2phy@100 {
>>> compatible = "rockchip,px30-usb2phy";
>>> reg = <0x100 0x20>;
>>> clocks = <&pmucru SCLK_USBPHY_REF>;
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> index bc0bdc3d86ff..8c821acb21ff 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> @@ -819,7 +819,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - u2phy: usb2-phy@100 {
>>> + u2phy: usb2phy@100 {
>>> compatible = "rockchip,rk3328-usb2phy";
>>> reg = <0x100 0x10>;
>>> clocks = <&xin24m>;
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> index a2eba5357693..c1a253507ac4 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> @@ -1418,7 +1418,7 @@
>>> status = "disabled";
>>> };
>>> - u2phy0: usb2-phy@e450 {
>>> + u2phy0: usb2phy@e450 {
>>> compatible = "rockchip,rk3399-usb2phy";
>>> reg = <0xe450 0x10>;
>>> clocks = <&cru SCLK_USB2PHY0_REF>;
>>> @@ -1445,7 +1445,7 @@
>>> };
>>> };
>>> - u2phy1: usb2-phy@e460 {
>>> + u2phy1: usb2phy@e460 {
>>> compatible = "rockchip,rk3399-usb2phy";
>>> reg = <0xe460 0x10>;
>>> clocks = <&cru SCLK_USB2PHY1_REF>;
>>> -------------------------------------------------------------------------------
>>>
>>>
>>> Git bisection log:
>>>
>>> -------------------------------------------------------------------------------
>>> git bisect start
>>> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
>>> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
>>> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>>> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
>>> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>>> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
>>> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>>> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
>>> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>>> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
>>> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>>> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
>>> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
>>> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
>>> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>>> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
>>> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
>>> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
>>> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
>>> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
>>> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
>>> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
>>> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
>>> git bisect good 837188d49823230f47afdbbec7556740e89a8557
>>> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
>>> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
>>> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
>>> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
>>> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
>>> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
>>> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> -------------------------------------------------------------------------------
>>>
>>>
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Groups.io Links: You receive all messages sent to this group.
>>> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
>>> Mute This Topic: https://groups.io/mt/84484486/924702
>>> Group Owner: kernelci-results+owner@groups.io
>>> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>
>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 8:59 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-07-28 8:59 UTC (permalink / raw)
To: Robin Murphy, kernelci-results, Johan Jonker, Heiko Stuebner,
Enric Balletbo i Serra
Cc: Maciej Matuszczyk, Marc Zyngier, Jacob Chen, Sandy Huang,
linux-kernel, Chen-Yu Tsai, Cameron Nemo, devicetree,
Elaine Zhang, Helen Koike, Shunqian Zheng, Ezequiel Garcia,
Rob Herring, Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
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.
Enric, is this something you can take care of?
Best wishes,
Guillaume
>> On 27/07/2021 16:33, KernelCI bot wrote:
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>> * This automated bisection report was sent to you on the basis *
>>> * that you may be involved with the breaking commit it has *
>>> * found. No manual investigation has been done to verify it, *
>>> * and the root cause of the problem may be somewhere else. *
>>> * *
>>> * If you do send a fix, please include this trailer: *
>>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
>>> * *
>>> * Hope this helps! *
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>> renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
>>>
>>> Summary:
>>> Start: 42d1095acf6e Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>>> Plain log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.txt
>>> HTML log: https://storage.kernelci.org/renesas/master/renesas-devel-2021-07-26-v5.14-rc3/arm64/defconfig+CONFIG_RANDOMIZE_BASE=y/gcc-8/lab-collabora/baseline-nfs-rk3399-gru-kevin.html
>>> Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>>
>>> Checks:
>>> revert: PASS
>>> verify: PASS
>>>
>>> Parameters:
>>> Tree: renesas
>>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
>>> Branch: master
>>> Target: rk3399-gru-kevin
>>> CPU arch: arm64
>>> Lab: lab-collabora
>>> Compiler: gcc-8
>>> Config: defconfig+CONFIG_RANDOMIZE_BASE=y
>>> Test case: baseline-nfs.bootrr.rockchip-usb2phy0-probed
>>>
>>> Breaking commit found:
>>>
>>> -------------------------------------------------------------------------------
>>> commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> Author: Johan Jonker <jbx6244@gmail.com>
>>> Date: Tue Jun 1 18:47:59 2021 +0200
>>>
>>> arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
>>> in phy-provider.yaml has required "#phy-cells" for phy nodes.
>>> The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
>>> Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
>>> notifications.
>>> make ARCH=arm64 dtbs_check
>>> DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
>>> phy/phy-provider.yaml
>>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>>> Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
>>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> index 4e243d72e16f..248ebb61aa79 100644
>>> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
>>> @@ -822,7 +822,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - u2phy: usb2-phy@100 {
>>> + u2phy: usb2phy@100 {
>>> compatible = "rockchip,px30-usb2phy";
>>> reg = <0x100 0x20>;
>>> clocks = <&pmucru SCLK_USBPHY_REF>;
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> index bc0bdc3d86ff..8c821acb21ff 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
>>> @@ -819,7 +819,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> - u2phy: usb2-phy@100 {
>>> + u2phy: usb2phy@100 {
>>> compatible = "rockchip,rk3328-usb2phy";
>>> reg = <0x100 0x10>;
>>> clocks = <&xin24m>;
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> index a2eba5357693..c1a253507ac4 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> @@ -1418,7 +1418,7 @@
>>> status = "disabled";
>>> };
>>> - u2phy0: usb2-phy@e450 {
>>> + u2phy0: usb2phy@e450 {
>>> compatible = "rockchip,rk3399-usb2phy";
>>> reg = <0xe450 0x10>;
>>> clocks = <&cru SCLK_USB2PHY0_REF>;
>>> @@ -1445,7 +1445,7 @@
>>> };
>>> };
>>> - u2phy1: usb2-phy@e460 {
>>> + u2phy1: usb2phy@e460 {
>>> compatible = "rockchip,rk3399-usb2phy";
>>> reg = <0xe460 0x10>;
>>> clocks = <&cru SCLK_USB2PHY1_REF>;
>>> -------------------------------------------------------------------------------
>>>
>>>
>>> Git bisection log:
>>>
>>> -------------------------------------------------------------------------------
>>> git bisect start
>>> # good: [3b9234c27991cbe7e6f97f22c3c7fef521fe34d3] Merge branch 'renesas-arm-dt-for-v5.15' into renesas-devel
>>> git bisect good 3b9234c27991cbe7e6f97f22c3c7fef521fe34d3
>>> # bad: [42d1095acf6e228a6baeec100d31a57c0c4d7704] Merge branch 'renesas-next', tag 'v5.14-rc3' into renesas-devel
>>> git bisect bad 42d1095acf6e228a6baeec100d31a57c0c4d7704
>>> # good: [514798d36572fb8eba6ccff3de10c9615063a7f5] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
>>> git bisect good 514798d36572fb8eba6ccff3de10c9615063a7f5
>>> # good: [a16d8644bad461bb073b92e812080ea6715ddf2b] Merge tag 'staging-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>>> git bisect good a16d8644bad461bb073b92e812080ea6715ddf2b
>>> # good: [6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc] Merge tag 'arm-soc-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>>> git bisect good 6e207b882159ed3e35a4cd4ff0fc155cce5e3cbc
>>> # bad: [8b9cc17a46215af733c83bea36366419133dfa09] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>>> git bisect bad 8b9cc17a46215af733c83bea36366419133dfa09
>>> # good: [f82c6e6dd149757022ba3ed8502d56201652fb0f] Merge tag 'v5.14-rockchip-dts32-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt
>>> git bisect good f82c6e6dd149757022ba3ed8502d56201652fb0f
>>> # bad: [071e5aceebebf1d33b5c29ccfd2688ed39c60007] Merge tag 'arm-drivers-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
>>> git bisect bad 071e5aceebebf1d33b5c29ccfd2688ed39c60007
>>> # good: [1eb5f83ee936de6a69b2bcee95088a6e0ab7c202] Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers
>>> git bisect good 1eb5f83ee936de6a69b2bcee95088a6e0ab7c202
>>> # bad: [c21cc3d8927350db675957bb44633eea9607da85] Merge tag 'qcom-arm64-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
>>> git bisect bad c21cc3d8927350db675957bb44633eea9607da85
>>> # bad: [e1d635bc94bce69e45a2d4e93c94178613e01229] arm64: dts: rockchip: add ir-receiver for rk3399-roc-pc
>>> git bisect bad e1d635bc94bce69e45a2d4e93c94178613e01229
>>> # good: [837188d49823230f47afdbbec7556740e89a8557] arm64: dts: rockchip: add #power-domain-cells to power domain nodes
>>> git bisect good 837188d49823230f47afdbbec7556740e89a8557
>>> # bad: [9fcf74b274a1dc5bcda37c34470061ef1e1130dd] arm64: dts: rockchip: add USB support to rk3308.dtsi
>>> git bisect bad 9fcf74b274a1dc5bcda37c34470061ef1e1130dd
>>> # good: [5a65adfa2ad1542f856fc7de3999d51f3a35d2e2] arm64: dts: rockchip: Add support for PCIe on helios64
>>> git bisect good 5a65adfa2ad1542f856fc7de3999d51f3a35d2e2
>>> # good: [18d5c7bf50c6d820c366c2a23d71d468b14c87d6] arm64: dts: rockchip: add rk817 codec to Odroid Go
>>> git bisect good 18d5c7bf50c6d820c366c2a23d71d468b14c87d6
>>> # bad: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> git bisect bad 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
>>> # first bad commit: [8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a] arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
>>> -------------------------------------------------------------------------------
>>>
>>>
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Groups.io Links: You receive all messages sent to this group.
>>> View/Reply Online (#14460): https://groups.io/g/kernelci-results/message/14460
>>> Mute This Topic: https://groups.io/mt/84484486/924702
>>> Group Owner: kernelci-results+owner@groups.io
>>> Unsubscribe: https://groups.io/g/kernelci-results/unsub [guillaume.tucker@collabora.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>
>>>
>>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
2021-07-28 8:59 ` Guillaume Tucker
(?)
@ 2021-07-28 9:16 ` Marc Zyngier
-1 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2021-07-28 9:16 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Robin Murphy, kernelci-results, Johan Jonker, Heiko Stuebner,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Helen Koike, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 9:16 ` Marc Zyngier
0 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2021-07-28 9:16 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Robin Murphy, kernelci-results, Johan Jonker, Heiko Stuebner,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Helen Koike, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin
@ 2021-07-28 9:16 ` Marc Zyngier
0 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2021-07-28 9:16 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Robin Murphy, kernelci-results, Johan Jonker, Heiko Stuebner,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Helen Koike, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
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.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread
* Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
2021-07-28 9:16 ` Marc Zyngier
(?)
@ 2021-07-28 9:51 ` Heiko Stübner
-1 siblings, 0 replies; 30+ messages in thread
From: Heiko Stübner @ 2021-07-28 9:51 UTC (permalink / raw)
To: Guillaume Tucker, Marc Zyngier, robh+dt
Cc: Robin Murphy, kernelci-results, Johan Jonker,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Helen Koike, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
> 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.
I'd be fine with that, if that is the consensus. And an annotation comment
would be good in that case, just to keep a similar change from getting
submitted.
I guess the interesting question is if dtbscheck has some sort of tooling
to detect these "this is meant to be that way for backwards compatibility"
hence adding Rob for that question.
Heiko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
@ 2021-07-28 9:51 ` Heiko Stübner
0 siblings, 0 replies; 30+ messages in thread
From: Heiko Stübner @ 2021-07-28 9:51 UTC (permalink / raw)
To: Guillaume Tucker, Marc Zyngier, robh+dt
Cc: Robin Murphy, kernelci-results, Johan Jonker,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Helen Koike, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
> 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.
I'd be fine with that, if that is the consensus. And an annotation comment
would be good in that case, just to keep a similar change from getting
submitted.
I guess the interesting question is if dtbscheck has some sort of tooling
to detect these "this is meant to be that way for backwards compatibility"
hence adding Rob for that question.
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
@ 2021-07-28 9:51 ` Heiko Stübner
0 siblings, 0 replies; 30+ messages in thread
From: Heiko Stübner @ 2021-07-28 9:51 UTC (permalink / raw)
To: Guillaume Tucker, Marc Zyngier, robh+dt
Cc: Robin Murphy, kernelci-results, Johan Jonker,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Helen Koike, Shunqian Zheng,
Ezequiel Garcia, Rob Herring, Yifeng Zhao, linux-arm-kernel,
linux-rockchip, Collabora Kernel ML
Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
> 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.
I'd be fine with that, if that is the consensus. And an annotation comment
would be good in that case, just to keep a similar change from getting
submitted.
I guess the interesting question is if dtbscheck has some sort of tooling
to detect these "this is meant to be that way for backwards compatibility"
hence adding Rob for that question.
Heiko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
2021-07-28 9:51 ` Heiko Stübner
(?)
@ 2021-10-01 10:00 ` Guillaume Tucker
-1 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-10-01 10:00 UTC (permalink / raw)
To: robh+dt, Marc Zyngier, Heiko Stübner
Cc: Robin Murphy, kernelci-results, Johan Jonker,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Shunqian Zheng, Ezequiel Garcia,
Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
Hello Rob,
On 28/07/2021 11:51, Heiko Stübner wrote:
> Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
>> 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/
This issue is still present and it got bisected yet again
yesterday by KernelCI.
>>>>> 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.
>
> I'd be fine with that, if that is the consensus. And an annotation comment
> would be good in that case, just to keep a similar change from getting
> submitted.
>
> I guess the interesting question is if dtbscheck has some sort of tooling
> to detect these "this is meant to be that way for backwards compatibility"
> hence adding Rob for that question.
Could you please take a look at Heiko's suggestion above to see
if this should be solved in dtbs_check? If not then we would
need to change the KernelCI test definition to look for a
different name based on the kernel version (which sounds like
breaking user-space).
Thanks,
Guillaume
GitHub: https://github.com/kernelci/kernelci-project/issues/55
-------------------------------------------------------------------------------
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* *
* If you do send a fix, please include this trailer: *
* Reported-by: "kernelci.org bot" <bot@kernelci.org> *
* *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
mainline/master bisection: baseline.bootrr.rockchip-usb2phy1-probed on rk3399-gru-kevin
Summary:
Start: 02d5e016800d Merge tag 'sound-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Plain log: https://storage.kernelci.org/mainline/master/v5.15-rc3-135-g02d5e016800d/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.txt
HTML log: https://storage.kernelci.org/mainline/master/v5.15-rc3-135-g02d5e016800d/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.html
Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: mainline
URL: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Branch: master
Target: rk3399-gru-kevin
CPU arch: arm64
Lab: lab-collabora
Compiler: gcc-8
Config: defconfig
Test case: baseline.bootrr.rockchip-usb2phy1-probed
Breaking commit found:
-------------------------------------------------------------------------------
commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
Author: Johan Jonker <jbx6244@gmail.com>
Date: Tue Jun 1 18:47:59 2021 +0200
arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
@ 2021-10-01 10:00 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-10-01 10:00 UTC (permalink / raw)
To: robh+dt, Marc Zyngier, Heiko Stübner
Cc: Robin Murphy, kernelci-results, Johan Jonker,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Shunqian Zheng, Ezequiel Garcia,
Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
Hello Rob,
On 28/07/2021 11:51, Heiko Stübner wrote:
> Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
>> 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/
This issue is still present and it got bisected yet again
yesterday by KernelCI.
>>>>> 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.
>
> I'd be fine with that, if that is the consensus. And an annotation comment
> would be good in that case, just to keep a similar change from getting
> submitted.
>
> I guess the interesting question is if dtbscheck has some sort of tooling
> to detect these "this is meant to be that way for backwards compatibility"
> hence adding Rob for that question.
Could you please take a look at Heiko's suggestion above to see
if this should be solved in dtbs_check? If not then we would
need to change the KernelCI test definition to look for a
different name based on the kernel version (which sounds like
breaking user-space).
Thanks,
Guillaume
GitHub: https://github.com/kernelci/kernelci-project/issues/55
-------------------------------------------------------------------------------
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* *
* If you do send a fix, please include this trailer: *
* Reported-by: "kernelci.org bot" <bot@kernelci.org> *
* *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
mainline/master bisection: baseline.bootrr.rockchip-usb2phy1-probed on rk3399-gru-kevin
Summary:
Start: 02d5e016800d Merge tag 'sound-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Plain log: https://storage.kernelci.org/mainline/master/v5.15-rc3-135-g02d5e016800d/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.txt
HTML log: https://storage.kernelci.org/mainline/master/v5.15-rc3-135-g02d5e016800d/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.html
Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: mainline
URL: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Branch: master
Target: rk3399-gru-kevin
CPU arch: arm64
Lab: lab-collabora
Compiler: gcc-8
Config: defconfig
Test case: baseline.bootrr.rockchip-usb2phy1-probed
Breaking commit found:
-------------------------------------------------------------------------------
commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
Author: Johan Jonker <jbx6244@gmail.com>
Date: Tue Jun 1 18:47:59 2021 +0200
arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
@ 2021-10-01 10:00 ` Guillaume Tucker
0 siblings, 0 replies; 30+ messages in thread
From: Guillaume Tucker @ 2021-10-01 10:00 UTC (permalink / raw)
To: robh+dt, Marc Zyngier, Heiko Stübner
Cc: Robin Murphy, kernelci-results, Johan Jonker,
Enric Balletbo i Serra, Maciej Matuszczyk, Jacob Chen,
Sandy Huang, linux-kernel, Chen-Yu Tsai, Cameron Nemo,
devicetree, Elaine Zhang, Shunqian Zheng, Ezequiel Garcia,
Yifeng Zhao, linux-arm-kernel, linux-rockchip,
Collabora Kernel ML
Hello Rob,
On 28/07/2021 11:51, Heiko Stübner wrote:
> Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
>> 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/
This issue is still present and it got bisected yet again
yesterday by KernelCI.
>>>>> 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.
>
> I'd be fine with that, if that is the consensus. And an annotation comment
> would be good in that case, just to keep a similar change from getting
> submitted.
>
> I guess the interesting question is if dtbscheck has some sort of tooling
> to detect these "this is meant to be that way for backwards compatibility"
> hence adding Rob for that question.
Could you please take a look at Heiko's suggestion above to see
if this should be solved in dtbs_check? If not then we would
need to change the KernelCI test definition to look for a
different name based on the kernel version (which sounds like
breaking user-space).
Thanks,
Guillaume
GitHub: https://github.com/kernelci/kernelci-project/issues/55
-------------------------------------------------------------------------------
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* *
* If you do send a fix, please include this trailer: *
* Reported-by: "kernelci.org bot" <bot@kernelci.org> *
* *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
mainline/master bisection: baseline.bootrr.rockchip-usb2phy1-probed on rk3399-gru-kevin
Summary:
Start: 02d5e016800d Merge tag 'sound-5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Plain log: https://storage.kernelci.org/mainline/master/v5.15-rc3-135-g02d5e016800d/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.txt
HTML log: https://storage.kernelci.org/mainline/master/v5.15-rc3-135-g02d5e016800d/arm64/defconfig/gcc-8/lab-collabora/baseline-rk3399-gru-kevin.html
Result: 8c3d64251ac5 arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: mainline
URL: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Branch: master
Target: rk3399-gru-kevin
CPU arch: arm64
Lab: lab-collabora
Compiler: gcc-8
Config: defconfig
Test case: baseline.bootrr.rockchip-usb2phy1-probed
Breaking commit found:
-------------------------------------------------------------------------------
commit 8c3d64251ac5c5a3d10364f6b07d3603ac1e7b4a
Author: Johan Jonker <jbx6244@gmail.com>
Date: Tue Jun 1 18:47:59 2021 +0200
arm64: dts: rockchip: rename nodename for phy-rockchip-inno-usb2
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
2021-10-01 10:00 ` Guillaume Tucker
(?)
@ 2021-10-01 16:12 ` Rob Herring
-1 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2021-10-01 16:12 UTC (permalink / raw)
To: Guillaume Tucker, Saravana Kannan, Greg Kroah-Hartman
Cc: Marc Zyngier, Heiko Stübner, Robin Murphy, kernelci-results,
Johan Jonker, Enric Balletbo i Serra, Maciej Matuszczyk,
Jacob Chen, Sandy Huang, linux-kernel, Chen-Yu Tsai,
Cameron Nemo, devicetree, Elaine Zhang, Shunqian Zheng,
Ezequiel Garcia, Yifeng Zhao, linux-arm-kernel,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
On Fri, Oct 1, 2021 at 5:00 AM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
>
> Hello Rob,
I'm adding a few more here as I think there's a wider topic of probing
and modules.
>
> On 28/07/2021 11:51, Heiko Stübner wrote:
> > Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
> >> 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/
>
> This issue is still present and it got bisected yet again
> yesterday by KernelCI.
>
> >>>>> 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.
/sys/bus/platform/devices/ paths are not an ABI. I'll consider
nodenames an ABI if a change is noticed, but not for sysfs path.
From sysfs testings/sys-devices (what /sys/bus/platform/devices/ links to):
What: /sys/devices
Date: February 2006
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
The /sys/devices tree contains a snapshot of the
internal state of the kernel device tree. Devices will
be added and removed dynamically as the machine runs,
and between different kernel versions, the layout of the
devices within this tree will change.
Please do not rely on the format of this tree because of
this. If a program wishes to find different things in
the tree, please use the /sys/class structure and rely
on the symlinks there to point to the proper location
within the /sys/devices tree of the individual devices.
Or rely on the uevent messages to notify programs of
devices being added and removed from this tree to find
the location of those devices.
Note that sometimes not all devices along the directory
chain will have emitted uevent messages, so userspace
programs must be able to handle such occurrences.
> >>>
> >>> 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
Why do you even care about the USB PHY probing directly? It is not
usable on its own. What you care about is whether the USB
controller(s) probed and USB is working.
> >>> 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.
> >
> > I'd be fine with that, if that is the consensus. And an annotation comment
> > would be good in that case, just to keep a similar change from getting
> > submitted.
> >
> > I guess the interesting question is if dtbscheck has some sort of tooling
> > to detect these "this is meant to be that way for backwards compatibility"
> > hence adding Rob for that question.
I would like to have some way to disable specific warnings and/or have
warning levels. The problem is there's not any sort of identifier to
key off of at a granularity smaller than a schema file. So in this
case, we'd have to disable the PHY binding entirely (that's not
actually too bad here). The second problem is where do we put that
control. We could do some sort of source annotation. That would have
to be maintained in the yaml encoded output and also would not work
when we don't have dts source. The schema checks currently require dts
source as we use some of the annotations like /bits/ that are lost in
the dtb, but addressing that to support running the checks on a
running system is something I'm actively working on.
> Could you please take a look at Heiko's suggestion above to see
> if this should be solved in dtbs_check? If not then we would
> need to change the KernelCI test definition to look for a
> different name based on the kernel version (which sounds like
> breaking user-space).
Looking at the above check, that looks horrible to create and maintain
(regardless of this issue). I was actually just wondering if there
were any tests for devices that didn't probe. On the recent VExpress
breakages, we only noticed on the boards that failed to init their
timer. Newer boards that use the arch timer still booted, but a bunch
of devices didn't probe.
Can't we extract every device not bound to a driver, get the
compatible string or modalias, and then compare that to the aliases of
all the modules? Of course, that doesn't work in the built-in case.
That's perhaps something we should fix though. (I'd also like to be
able to extract all driver DT compatibles at build time and have the
same issue.)
Alternatively, couldn't this test list the compatible string instead
of node name and then you search devices for a match?
Or maybe there is a much more simple fix. We could just log failed
probes in a standard way for tools to understand.
Rob
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
@ 2021-10-01 16:12 ` Rob Herring
0 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2021-10-01 16:12 UTC (permalink / raw)
To: Guillaume Tucker, Saravana Kannan, Greg Kroah-Hartman
Cc: Marc Zyngier, Heiko Stübner, Robin Murphy, kernelci-results,
Johan Jonker, Enric Balletbo i Serra, Maciej Matuszczyk,
Jacob Chen, Sandy Huang, linux-kernel, Chen-Yu Tsai,
Cameron Nemo, devicetree, Elaine Zhang, Shunqian Zheng,
Ezequiel Garcia, Yifeng Zhao, linux-arm-kernel,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
On Fri, Oct 1, 2021 at 5:00 AM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
>
> Hello Rob,
I'm adding a few more here as I think there's a wider topic of probing
and modules.
>
> On 28/07/2021 11:51, Heiko Stübner wrote:
> > Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
> >> 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/
>
> This issue is still present and it got bisected yet again
> yesterday by KernelCI.
>
> >>>>> 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.
/sys/bus/platform/devices/ paths are not an ABI. I'll consider
nodenames an ABI if a change is noticed, but not for sysfs path.
From sysfs testings/sys-devices (what /sys/bus/platform/devices/ links to):
What: /sys/devices
Date: February 2006
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
The /sys/devices tree contains a snapshot of the
internal state of the kernel device tree. Devices will
be added and removed dynamically as the machine runs,
and between different kernel versions, the layout of the
devices within this tree will change.
Please do not rely on the format of this tree because of
this. If a program wishes to find different things in
the tree, please use the /sys/class structure and rely
on the symlinks there to point to the proper location
within the /sys/devices tree of the individual devices.
Or rely on the uevent messages to notify programs of
devices being added and removed from this tree to find
the location of those devices.
Note that sometimes not all devices along the directory
chain will have emitted uevent messages, so userspace
programs must be able to handle such occurrences.
> >>>
> >>> 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
Why do you even care about the USB PHY probing directly? It is not
usable on its own. What you care about is whether the USB
controller(s) probed and USB is working.
> >>> 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.
> >
> > I'd be fine with that, if that is the consensus. And an annotation comment
> > would be good in that case, just to keep a similar change from getting
> > submitted.
> >
> > I guess the interesting question is if dtbscheck has some sort of tooling
> > to detect these "this is meant to be that way for backwards compatibility"
> > hence adding Rob for that question.
I would like to have some way to disable specific warnings and/or have
warning levels. The problem is there's not any sort of identifier to
key off of at a granularity smaller than a schema file. So in this
case, we'd have to disable the PHY binding entirely (that's not
actually too bad here). The second problem is where do we put that
control. We could do some sort of source annotation. That would have
to be maintained in the yaml encoded output and also would not work
when we don't have dts source. The schema checks currently require dts
source as we use some of the annotations like /bits/ that are lost in
the dtb, but addressing that to support running the checks on a
running system is something I'm actively working on.
> Could you please take a look at Heiko's suggestion above to see
> if this should be solved in dtbs_check? If not then we would
> need to change the KernelCI test definition to look for a
> different name based on the kernel version (which sounds like
> breaking user-space).
Looking at the above check, that looks horrible to create and maintain
(regardless of this issue). I was actually just wondering if there
were any tests for devices that didn't probe. On the recent VExpress
breakages, we only noticed on the boards that failed to init their
timer. Newer boards that use the arch timer still booted, but a bunch
of devices didn't probe.
Can't we extract every device not bound to a driver, get the
compatible string or modalias, and then compare that to the aliases of
all the modules? Of course, that doesn't work in the built-in case.
That's perhaps something we should fix though. (I'd also like to be
able to extract all driver DT compatibles at build time and have the
same issue.)
Alternatively, couldn't this test list the compatible string instead
of node name and then you search devices for a match?
Or maybe there is a much more simple fix. We could just log failed
probes in a standard way for tools to understand.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Annotation for dtbscheck to ignore a defect (Was: Re: renesas/master bisection: baseline-nfs.bootrr.rockchip-usb2phy0-probed on rk3399-gru-kevin)
@ 2021-10-01 16:12 ` Rob Herring
0 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2021-10-01 16:12 UTC (permalink / raw)
To: Guillaume Tucker, Saravana Kannan, Greg Kroah-Hartman
Cc: Marc Zyngier, Heiko Stübner, Robin Murphy, kernelci-results,
Johan Jonker, Enric Balletbo i Serra, Maciej Matuszczyk,
Jacob Chen, Sandy Huang, linux-kernel, Chen-Yu Tsai,
Cameron Nemo, devicetree, Elaine Zhang, Shunqian Zheng,
Ezequiel Garcia, Yifeng Zhao, linux-arm-kernel,
open list:ARM/Rockchip SoC...,
Collabora Kernel ML
On Fri, Oct 1, 2021 at 5:00 AM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
>
> Hello Rob,
I'm adding a few more here as I think there's a wider topic of probing
and modules.
>
> On 28/07/2021 11:51, Heiko Stübner wrote:
> > Am Mittwoch, 28. Juli 2021, 11:16:14 CEST schrieb Marc Zyngier:
> >> 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/
>
> This issue is still present and it got bisected yet again
> yesterday by KernelCI.
>
> >>>>> 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.
/sys/bus/platform/devices/ paths are not an ABI. I'll consider
nodenames an ABI if a change is noticed, but not for sysfs path.
From sysfs testings/sys-devices (what /sys/bus/platform/devices/ links to):
What: /sys/devices
Date: February 2006
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
The /sys/devices tree contains a snapshot of the
internal state of the kernel device tree. Devices will
be added and removed dynamically as the machine runs,
and between different kernel versions, the layout of the
devices within this tree will change.
Please do not rely on the format of this tree because of
this. If a program wishes to find different things in
the tree, please use the /sys/class structure and rely
on the symlinks there to point to the proper location
within the /sys/devices tree of the individual devices.
Or rely on the uevent messages to notify programs of
devices being added and removed from this tree to find
the location of those devices.
Note that sometimes not all devices along the directory
chain will have emitted uevent messages, so userspace
programs must be able to handle such occurrences.
> >>>
> >>> 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
Why do you even care about the USB PHY probing directly? It is not
usable on its own. What you care about is whether the USB
controller(s) probed and USB is working.
> >>> 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.
> >
> > I'd be fine with that, if that is the consensus. And an annotation comment
> > would be good in that case, just to keep a similar change from getting
> > submitted.
> >
> > I guess the interesting question is if dtbscheck has some sort of tooling
> > to detect these "this is meant to be that way for backwards compatibility"
> > hence adding Rob for that question.
I would like to have some way to disable specific warnings and/or have
warning levels. The problem is there's not any sort of identifier to
key off of at a granularity smaller than a schema file. So in this
case, we'd have to disable the PHY binding entirely (that's not
actually too bad here). The second problem is where do we put that
control. We could do some sort of source annotation. That would have
to be maintained in the yaml encoded output and also would not work
when we don't have dts source. The schema checks currently require dts
source as we use some of the annotations like /bits/ that are lost in
the dtb, but addressing that to support running the checks on a
running system is something I'm actively working on.
> Could you please take a look at Heiko's suggestion above to see
> if this should be solved in dtbs_check? If not then we would
> need to change the KernelCI test definition to look for a
> different name based on the kernel version (which sounds like
> breaking user-space).
Looking at the above check, that looks horrible to create and maintain
(regardless of this issue). I was actually just wondering if there
were any tests for devices that didn't probe. On the recent VExpress
breakages, we only noticed on the boards that failed to init their
timer. Newer boards that use the arch timer still booted, but a bunch
of devices didn't probe.
Can't we extract every device not bound to a driver, get the
compatible string or modalias, and then compare that to the aliases of
all the modules? Of course, that doesn't work in the built-in case.
That's perhaps something we should fix though. (I'd also like to be
able to extract all driver DT compatibles at build time and have the
same issue.)
Alternatively, couldn't this test list the compatible string instead
of node name and then you search devices for a match?
Or maybe there is a much more simple fix. We could just log failed
probes in a standard way for tools to understand.
Rob
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 30+ messages in thread