* Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support
From: Pin-yen Lin @ 2023-04-20 9:10 UTC (permalink / raw)
To: Stephen Boyd
Cc: Andrzej Hajda, Andy Shevchenko, Benson Leung, Daniel Scally,
Daniel Vetter, David Airlie, Greg Kroah-Hartman, Guenter Roeck,
Heikki Krogerus, Jernej Skrabec, Jonas Karlman,
Krzysztof Kozlowski, Laurent Pinchart, Neil Armstrong,
Prashant Malani, Rafael J . Wysocki, Rob Herring, Robert Foss,
Sakari Ailus, Xin Ji, Marek Vasut, Hsin-Yi Wang,
Thomas Zimmermann, AngeloGioacchino Del Regno, Lyude Paul,
devicetree, dri-devel, linux-acpi, chrome-platform,
Nícolas F . R . A . Prado, Javier Martinez Canillas,
linux-kernel, Krzysztof Kozlowski, Chen-Yu Tsai
In-Reply-To: <CAE-0n51Qy-KDGHOCr4Smpebq1fCURqvJ2RJz6KAtVpv5e+DSGA@mail.gmail.com>
On Thu, Apr 20, 2023 at 2:10 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Stephen Boyd (2023-04-13 17:22:46)
> > Quoting Pin-yen Lin (2023-04-13 02:50:44)
> > >
> > > Actually the `mode-switch` property here is mainly because
> > > `fwnode_typec_mux_get`[1] and `typec_mux_match`[2] only return matches
> > > when the property is present. I am not sure what side effects would be
> > > if I remove the ID-matching condition in `typec_mux_match`, so I added
> > > the property here.
> > >
> > > Is it feasible to remove the `mode-switch` property here given the
> > > existing implementation of the Type-C framework?
> >
> > Omitting the mode-switch property would require changes to the type-c
> > framework.
> >
> > I'm wondering if we can have this anx driver register mode switches for
> > however many endpoints exist in the output port all the time when the
> > aux-bus node doesn't exist. Then the type-c framework can walk from the
> > usb-c-connector to each connected node looking for a device that is both
> > a drm_bridge and a mode-switch. When it finds that combination, it knows
> > that the mode-switch has been found. This hinges on the idea that a
> > device that would have the mode-switch property is a drm_bridge and
> > would register a mode-switch with the type-c framework.
> >
> > It may be a little complicated though, because we would only register
> > one drm_bridge for the input to this anx device. The type-c walking code
> > would need to look at the graph endpoint, and find the parent device to
> > see if it is a drm_bridge.
>
> I've been thinking more about this. I think we should only have the
> 'mode-switch' property possible when the USB input pins (port@2) are
> connected and the DPI input pins are connected (port@0). Probably you
> don't have that case though?
No we don't have the use case that uses the USB input pins on anx7625.
>
> In your case, this device should register either one or two drm_bridges
> that connect to whatever downstream is actually muxing the 2 DP lanes
> with the USB SS lanes onto the usb-c-connector.
What do you mean by "muxing the 2 DP lanes with the USB SS lanes''? In
our use case, the USB data lanes from both ports are connected to a
USB hub, but the DP lanes are muxed by the crosspoint switch on
anx7625. HPD and AUX for the external display are muxed by the EC. You
can find the diagram at
https://lore.kernel.org/linux-usb/YxGzk6DNAt0aCvIY@chromium.org/
> If that is the EC for
> ChromeOS, then the EC should have a binding that accepts some number of
> input ports for DP. The EC would act as a drm_bridge, or in this case
> probably two bridges, and also as two type-c switches for each
> drm_bridge corresponding to the usb-c-connector nodes. When DP is on the
> cable, the type-c switch/mux would signal to the drm_bridge that the
> display is 'connected' via DRM_BRIDGE_OP_DETECT and struct
> drm_bridge_funcs::detect(). Then the drm_bridge in this anx part would
> implement struct drm_bridge_funcs::atomic_enable() and configure the
> crosspoint switch the right way depending on the reg property of the
> output node in port@1.
So there will be two drm bridges that act as the downstreams for
anx7625, and we find the downstream with connector_status_connected to
configure the crosspoint switch? How do we support that kind of
topology given that the drm bridge chain is currently a list? Are you
suggesting making the bridge topology to a tree, or maintaining the
two downstreams inside the anx7625 driver and not attaching them to
the bridge chain?
Also, if we still register mode switches on the two downstream
bridges, why do you prefer that over the original approach that
register switches in the anx7625 driver?
>
> Because you don't have the part that implements the orientation-switch,
> you don't need to implement the code for it. I think simply adding
> support in the binding for mode-switch and orientation-switch if this is
> directly wired to a usb-c-connector should be sufficient. Those
> properties would be at the top-level and not part of the graph binding.
^ permalink raw reply
* Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support
From: Stephen Boyd @ 2023-04-20 6:10 UTC (permalink / raw)
To: Pin-yen Lin
Cc: Andrzej Hajda, Andy Shevchenko, Benson Leung, Daniel Scally,
Daniel Vetter, David Airlie, Greg Kroah-Hartman, Guenter Roeck,
Heikki Krogerus, Jernej Skrabec, Jonas Karlman,
Krzysztof Kozlowski, Laurent Pinchart, Neil Armstrong,
Prashant Malani, Rafael J . Wysocki, Rob Herring, Robert Foss,
Sakari Ailus, Xin Ji, Marek Vasut, Hsin-Yi Wang,
Thomas Zimmermann, AngeloGioacchino Del Regno, Lyude Paul,
devicetree, dri-devel, linux-acpi, chrome-platform,
Nícolas F . R . A . Prado, Javier Martinez Canillas,
linux-kernel, Krzysztof Kozlowski, Chen-Yu Tsai
In-Reply-To: <CAE-0n50atfmr-bFh5XtTCm4WpSijJGSe0B5JP8ni7CCYk7Bs5A@mail.gmail.com>
Quoting Stephen Boyd (2023-04-13 17:22:46)
> Quoting Pin-yen Lin (2023-04-13 02:50:44)
> >
> > Actually the `mode-switch` property here is mainly because
> > `fwnode_typec_mux_get`[1] and `typec_mux_match`[2] only return matches
> > when the property is present. I am not sure what side effects would be
> > if I remove the ID-matching condition in `typec_mux_match`, so I added
> > the property here.
> >
> > Is it feasible to remove the `mode-switch` property here given the
> > existing implementation of the Type-C framework?
>
> Omitting the mode-switch property would require changes to the type-c
> framework.
>
> I'm wondering if we can have this anx driver register mode switches for
> however many endpoints exist in the output port all the time when the
> aux-bus node doesn't exist. Then the type-c framework can walk from the
> usb-c-connector to each connected node looking for a device that is both
> a drm_bridge and a mode-switch. When it finds that combination, it knows
> that the mode-switch has been found. This hinges on the idea that a
> device that would have the mode-switch property is a drm_bridge and
> would register a mode-switch with the type-c framework.
>
> It may be a little complicated though, because we would only register
> one drm_bridge for the input to this anx device. The type-c walking code
> would need to look at the graph endpoint, and find the parent device to
> see if it is a drm_bridge.
I've been thinking more about this. I think we should only have the
'mode-switch' property possible when the USB input pins (port@2) are
connected and the DPI input pins are connected (port@0). Probably you
don't have that case though?
In your case, this device should register either one or two drm_bridges
that connect to whatever downstream is actually muxing the 2 DP lanes
with the USB SS lanes onto the usb-c-connector. If that is the EC for
ChromeOS, then the EC should have a binding that accepts some number of
input ports for DP. The EC would act as a drm_bridge, or in this case
probably two bridges, and also as two type-c switches for each
drm_bridge corresponding to the usb-c-connector nodes. When DP is on the
cable, the type-c switch/mux would signal to the drm_bridge that the
display is 'connected' via DRM_BRIDGE_OP_DETECT and struct
drm_bridge_funcs::detect(). Then the drm_bridge in this anx part would
implement struct drm_bridge_funcs::atomic_enable() and configure the
crosspoint switch the right way depending on the reg property of the
output node in port@1.
Because you don't have the part that implements the orientation-switch,
you don't need to implement the code for it. I think simply adding
support in the binding for mode-switch and orientation-switch if this is
directly wired to a usb-c-connector should be sufficient. Those
properties would be at the top-level and not part of the graph binding.
^ permalink raw reply
* Re: [PATCH] platform: chrome: wilco_ec: remove return value check of debugfs_create_dir()
From: patchwork-bot+chrome-platform @ 2023-04-20 4:10 UTC (permalink / raw)
To: Zhengkang Huang; +Cc: bleung, dzm91, chrome-platform, linux-kernel
In-Reply-To: <20230419100303.343379-1-zkhuang@hust.edu.cn>
Hello:
This patch was applied to chrome-platform/linux.git (for-next)
by Tzung-Bi Shih <tzungbi@kernel.org>:
On Wed, 19 Apr 2023 18:03:03 +0800 you wrote:
> Smatch complains that:
> wilco_ec_debugfs_probe() warn: 'debug_info->dir' is an error
> pointer or valid
>
> Debugfs checks are generally not supposed to be checked
> for errors and it is not necessary here.
>
> [...]
Here is the summary with links:
- platform: chrome: wilco_ec: remove return value check of debugfs_create_dir()
https://git.kernel.org/chrome-platform/c/0ad5ce8407db
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* chrome-platform/for-kernelci baseline: 70 runs, 30 regressions (v6.3-rc1-8-g0ad5ce8407db)
From: kernelci.org bot @ 2023-04-20 3:49 UTC (permalink / raw)
To: kernel-build-reports, kernelci-results, chrome-platform,
eballetbo, bleung, groeck, pmalani
chrome-platform/for-kernelci baseline: 70 runs, 30 regressions (v6.3-rc1-8-g0ad5ce8407db)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
imx53-qsrb | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
imx6dl-riotboard | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
imx6dl-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
imx6q-sabrelite | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
imx6q-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
imx6qp-wandboard-revd1 | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
imx6ul-14x14-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
imx7d-sdb | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
imx7ulp-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
mt8183-kukui-...uniper-sku16 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 3
rk3288-rock2-square | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/job/chrome-platform/branch/for-kernelci/kernel/v6.3-rc1-8-g0ad5ce8407db/plan/baseline/
Test: baseline
Tree: chrome-platform
Branch: for-kernelci
Describe: v6.3-rc1-8-g0ad5ce8407db
URL: https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
SHA: 0ad5ce8407db2e44922ee21d2f2a9de4df336038
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440aaed57b7475aa42e8609
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-C436FA-Flip-hatch.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-C436FA-Flip-hatch.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440aaed57b7475aa42e860e
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:00:43.722827 + set +x
2023-04-20T03:00:43.729455 <8>[ 10.643172] <LAVA_SIGNAL_ENDRUN 0_dmesg 10058019_1.4.2.3.1>
2023-04-20T03:00:43.833534 / # #
2023-04-20T03:00:43.934535 export SHELL=/bin/sh
2023-04-20T03:00:43.934736 #
2023-04-20T03:00:44.035614 / # export SHELL=/bin/sh. /lava-10058019/environment
2023-04-20T03:00:44.035808
2023-04-20T03:00:44.136727 / # . /lava-10058019/environment/lava-10058019/bin/lava-test-runner /lava-10058019/1
2023-04-20T03:00:44.137005
2023-04-20T03:00:44.142709 / # /lava-10058019/bin/lava-test-runner /lava-10058019/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440aad7eff859ab6b2e85f5
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-CM1400CXA-dalboz.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-CM1400CXA-dalboz.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440aad7eff859ab6b2e85fa
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:00:29.442549 + <8>[ 11.558062] <LAVA_SIGNAL_ENDRUN 0_dmesg 10057966_1.4.2.3.1>
2023-04-20T03:00:29.442673 set +x
2023-04-20T03:00:29.547430 / # #
2023-04-20T03:00:29.648533 export SHELL=/bin/sh
2023-04-20T03:00:29.648765 #
2023-04-20T03:00:29.749713 / # export SHELL=/bin/sh. /lava-10057966/environment
2023-04-20T03:00:29.749956
2023-04-20T03:00:29.850977 / # . /lava-10057966/environment/lava-10057966/bin/lava-test-runner /lava-10057966/1
2023-04-20T03:00:29.851422
2023-04-20T03:00:29.855788 / # /lava-10057966/bin/lava-test-runner /lava-10057966/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440aad6eff859ab6b2e85e7
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-cx9400-volteer.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-cx9400-volteer.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440aad6eff859ab6b2e85ec
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:00:31.157600 <8>[ 9.755769] <LAVA_SIGNAL_ENDRUN 0_dmesg 10058021_1.4.2.3.1>
2023-04-20T03:00:31.160817 + set +x
2023-04-20T03:00:31.262454
2023-04-20T03:00:31.363468 / # #export SHELL=/bin/sh
2023-04-20T03:00:31.363693
2023-04-20T03:00:31.464573 / # export SHELL=/bin/sh. /lava-10058021/environment
2023-04-20T03:00:31.464765
2023-04-20T03:00:31.565660 / # . /lava-10058021/environment/lava-10058021/bin/lava-test-runner /lava-10058021/1
2023-04-20T03:00:31.565997
2023-04-20T03:00:31.570794 / # /lava-10058021/bin/lava-test-runner /lava-10058021/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440b025b2c19c6d582e862a
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440b025b2c19c6d582e862f
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:23:04.317273 + set +x
2023-04-20T03:23:04.324509 <8>[ 10.595519] <LAVA_SIGNAL_ENDRUN 0_dmesg 10058025_1.4.2.3.1>
2023-04-20T03:23:04.428916 / # #
2023-04-20T03:23:04.529904 export SHELL=/bin/sh
2023-04-20T03:23:04.530185 #
2023-04-20T03:23:04.631139 / # export SHELL=/bin/sh. /lava-10058025/environment
2023-04-20T03:23:04.631366
2023-04-20T03:23:04.732357 / # . /lava-10058025/environment/lava-10058025/bin/lava-test-runner /lava-10058025/1
2023-04-20T03:23:04.732730
2023-04-20T03:23:04.737165 / # /lava-10058025/bin/lava-test-runner /lava-10058025/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440af38bf0208a6682e8620
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440af38bf0208a6682e8625
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:19:00.922901 + set +x<8>[ 10.723403] <LAVA_SIGNAL_ENDRUN 0_dmesg 10057987_1.4.2.3.1>
2023-04-20T03:19:00.923439
2023-04-20T03:19:01.031223 #
2023-04-20T03:19:01.032555
2023-04-20T03:19:01.134578 / # #export SHELL=/bin/sh
2023-04-20T03:19:01.135292
2023-04-20T03:19:01.237138 / # export SHELL=/bin/sh. /lava-10057987/environment
2023-04-20T03:19:01.237926
2023-04-20T03:19:01.340047 / # . /lava-10057987/environment/lava-10057987/bin/lava-test-runner /lava-10057987/1
2023-04-20T03:19:01.341294
... (13 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440aad4d8cadfd2d82e8633
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14a-cb0001xx-zork.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14a-cb0001xx-zork.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440aad4d8cadfd2d82e8638
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:00:18.512978 + <8>[ 11.509370] <LAVA_SIGNAL_ENDRUN 0_dmesg 10057968_1.4.2.3.1>
2023-04-20T03:00:18.513070 set +x
2023-04-20T03:00:18.617022 / # #
2023-04-20T03:00:18.718016 export SHELL=/bin/sh
2023-04-20T03:00:18.718242 #
2023-04-20T03:00:18.819227 / # export SHELL=/bin/sh. /lava-10057968/environment
2023-04-20T03:00:18.819448
2023-04-20T03:00:18.920298 / # . /lava-10057968/environment/lava-10057968/bin/lava-test-runner /lava-10057968/1
2023-04-20T03:00:18.920616
2023-04-20T03:00:18.925224 / # /lava-10057968/bin/lava-test-runner /lava-10057968/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx53-qsrb | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440a9d88dd5dc44dc2e862c
Results: 4 PASS, 2 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx53-qsrb.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx53-qsrb.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440a9d88dd5dc44dc2e8633
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-20T02:56:00.261903 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:56:00.262075 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:56:00.270763 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xe0cb8000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:56:00.279959 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:56:00.288840 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:56:00.297844 kern :alert : Register r7 information: slab task_struct start c880bb80 pointer offset 0 size 2176
2023-04-20T02:56:00.298109 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:56:00.306873 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-20T02:56:00.315884 kern :alert : Register r10 information: non-slab/vmalloc memory
2023-04-20T02:56:00.316103 kern :alert : Register r11 information: non-slab/vmalloc memory
... (103 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440a9d88dd5dc44dc2e8634
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-20T02:56:00.225635 kern :alert : 8<--- cut here ---
2023-04-20T02:56:00.234670 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:56:00.235026 kern :alert : [c1a50741] *pgd=71a0041e(bad)
2023-04-20T02:56:00.252844 kern :alert : Register r0 information: non-slab/vmalloc memory[ 6.796143] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-20T02:56:00.253072
2023-04-20T02:56:00.253190 kern :alert : Register r1 information: non-paged memory
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6dl-riotboard | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440a9d68dd5dc44dc2e860b
Results: 4 PASS, 2 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx6dl-riotboard.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx6dl-riotboard.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440a9d68dd5dc44dc2e8612
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-20T02:56:00.492725 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:56:00.492911 kern :alert : Register r1 information: non-paged memory
2023-04-20T02:56:00.501681 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:56:00.501873 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:56:00.510753 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0cd4000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:56:00.519646 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:56:00.528805 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:56:00.537910 kern :alert : Register r7 information: slab task_struct start c33d9100 pointer offset 0 size 2176
2023-04-20T02:56:00.538174 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:56:00.546843 kern :alert : Register r9 information: non-slab/vmalloc memory
... (102 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440a9d68dd5dc44dc2e8613
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-20T02:56:00.465455 kern :alert : 8<--- cut here ---
2023-04-20T02:56:00.474483 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:56:00.474688 kern :alert : [c1a50741] *pgd=11a0041e(bad)
2023-04-20T02:56:00.483473 k[ 6.779184] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6dl-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440aabfd8cadfd2d82e85e6
Results: 13 PASS, 12 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6dl-udoo.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6dl-udoo.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440aabfd8cadfd2d82e8600
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-20T02:59:30.884460 k<8>[ 16.173139] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-20T02:59:30.885144 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:59:30.885393 kern :alert : Register r1 information: non-paged memory
2023-04-20T02:59:30.885595 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:59:30.885763 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:59:30.906426 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0cb0000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:59:30.907101 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:59:30.907297 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:59:30.928682 kern :alert : Register r7 information: slab task_struct start c4aacc80 pointer offset 0 size 2176
2023-04-20T02:59:30.929318 kern :alert : Register r8 information: non-slab/vmalloc memory
... (103 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440aabfd8cadfd2d82e8601
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-20T02:59:30.862402 kern :alert : 8<--- cut here ---
2023-04-20T02:59:30.862796 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:59:30.863277 kern :alert : [c1a50741] *pgd=11a1141e(bad)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6q-sabrelite | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440aa012a88dc8c622e8637
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-imx6q-sabrelite.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-imx6q-sabrelite.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440aa012a88dc8c622e863e
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-20T02:56:54.220777 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0e00000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:56:54.221346 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:56:54.221759 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:56:54.222112 kern :alert : Register r7 information: slab task_struct start c3481980 pointer offset 0 size 2176
2023-04-20T02:56:54.222454 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:56:54.222788 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-20T02:56:54.263714 kern :alert : Register r10 information: non-slab/vmalloc memory
2023-04-20T02:56:54.264287 kern :alert : Register r11 information: non-slab/vmalloc memory
2023-04-20T02:56:54.264668 kern :alert : Register r12 information: NULL pointer
2023-04-20T02:56:54.265017 kern :alert : 8<--- cut here ---
... (101 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440aa012a88dc8c622e863f
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-20T02:56:54.177760 kern :alert : 8<--- cut here ---
2023-04-20T02:56:54.178337 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:56:54.178722 kern :alert : [c1a50741] *pgd=11a1141e(bad)
2023-04-20T02:56:54.179075 k<8>[ 9.008095] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-20T02:56:54.179412 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:56:54.179749 kern :alert : Register r1 information: non-paged memory
2023-04-20T02:56:54.180105 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:56:54.180440 kern :alert : Register r3 information: non-paged memory
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6q-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440aa3d0e46e3911a2e8649
Results: 13 PASS, 12 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6q-udoo.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6q-udoo.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440aa3d0e46e3911a2e8663
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-20T02:57:35.586853 k<8>[ 15.160140] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-20T02:57:35.587375 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:57:35.587657 kern :alert : Register r1 information: non-paged memory
2023-04-20T02:57:35.588195 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:57:35.588667 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:57:35.609100 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0d48000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:57:35.609746 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:57:35.610519 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:57:35.631167 kern :alert : Register r7 information: slab task_struct start c24bbb80 pointer offset 0 size 2176
2023-04-20T02:57:35.631837 kern :alert : Register r8 information: non-slab/vmalloc memory
... (102 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440aa3d0e46e3911a2e8664
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-20T02:57:35.564921 kern :alert : 8<--- cut here ---
2023-04-20T02:57:35.565465 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:57:35.566067 kern :alert : [c1a50741] *pgd=11a1141e(bad)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6qp-wandboard-revd1 | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440a9d78dd5dc44dc2e8616
Results: 4 PASS, 2 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx6qp-wandboard-revd1.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx6qp-wandboard-revd1.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440a9d78dd5dc44dc2e861d
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-20T02:56:01.061714 mation: non-slab/vmalloc memory
2023-04-20T02:56:01.061902 kern :alert : Register r1 information: non-paged memory
2023-04-20T02:56:01.070700 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:56:01.070910 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:56:01.079620 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0e0c000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:56:01.088752 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:56:01.097808 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:56:01.107066 kern :alert : Register r7 information: slab task_struct start c261bb80 pointer offset 0 size 2176
2023-04-20T02:56:01.107331 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:56:01.115659 kern :alert : Register r9 information: non-slab/vmalloc memory
... (102 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440a9d78dd5dc44dc2e861e
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-20T02:56:01.034664 kern :alert : 8<--- cut here ---
2023-04-20T02:56:01.043840 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:56:01.044074 kern :alert : [c1a50741] *pgd=11a1141e(bad)
2023-04-20T02:56:01.052681 kern :alert : Register r0 infor[ 5.550612] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6ul-14x14-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440aa6dfedf4342082e860c
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx6ul-14x14-evk.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx6ul-14x14-evk.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440aa6dfedf4342082e8613
failing since 26 days (last pass: v6.2-rc1-8-gf9a0ae83af2e, first fail: v6.3-rc1-4-g9ce5f3b3c18e2)
90 lines
2023-04-20T02:57:55.504408 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:57:55.504652 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:57:55.524708 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xe0c34000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:57:55.525266 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:57:55.525522 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:57:55.539214 kern :alert : Register r7 information: slab task_struct start c7981100 pointer offset 0 size 2176
2023-04-20T02:57:55.540495 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:57:55.550256 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-20T02:57:55.560278 kern :alert : Register r10 information: non-slab/vmalloc memory
2023-04-20T02:57:55.570378 kern :alert : Register r11 information: non-slab/vmalloc memory
... (105 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440aa6dfedf4342082e8614
failing since 26 days (last pass: v6.2-rc1-8-gf9a0ae83af2e, first fail: v6.3-rc1-4-g9ce5f3b3c18e2)
48 lines
2023-04-20T02:57:55.479749 kern :alert : 8<--- cut here ---
2023-04-20T02:57:55.480051 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:57:55.480578 kern :alert : [c1a50741] *pgd=81a1141e(bad)
2023-04-20T02:57:55.480824 kern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:57:55.502703 kern :alert : Register r1 in<8>[ 21.965886] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-20T02:57:55.503028 formation: non-paged memory
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx7d-sdb | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440aa263a7bed01862e8661
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7d-sdb.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7d-sdb.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440aa263a7bed01862e8668
failing since 44 days (last pass: v6.2-rc1-32-g7ae7deb4a4b4, first fail: v6.3-rc1)
90 lines
2023-04-20T02:57:23.065407 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:57:23.105426 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0d8c000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:57:23.106012 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:57:23.106271 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:57:23.106514 kern :alert : Register r7 information: slab task_struct start c2155500 pointer offset 0 size 2176
2023-04-20T02:57:23.106752 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:57:23.107273 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-20T02:57:23.148429 kern :alert : Register r10 information: non-slab/vmalloc memory
2023-04-20T02:57:23.148733 kern :alert : Register r11 information: non-slab/vmalloc memory
2023-04-20T02:57:23.149242 kern :alert : Register r12 information: NULL pointer
... (97 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440aa263a7bed01862e8669
failing since 44 days (last pass: v6.2-rc1-32-g7ae7deb4a4b4, first fail: v6.3-rc1)
48 lines
2023-04-20T02:57:23.062351 kern :alert : 8<--- cut here ---
2023-04-20T02:57:23.062656 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:57:23.063181 kern :alert : [c1a50741] *pgd=81a1141e(bad)
2023-04-20T02:57:23.063431 k<8>[ 10.878537] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-20T02:57:23.063669 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:57:23.063902 kern :alert : Register r1 information: non-paged memory
2023-04-20T02:57:23.064129 kern :alert : Register r2 information: non-slab/vmalloc memory
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx7ulp-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440aa6769c70828fc2e85f3
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7ulp-evk.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7ulp-evk.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440aa6769c70828fc2e85fa
failing since 44 days (last pass: v6.2-rc1-23-g93899a4cb7b1, first fail: v6.3-rc1)
90 lines
2023-04-20T02:58:00.572803 -paged memory
2023-04-20T02:58:00.573134 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-20T02:58:00.573634 kern :alert : Register r3 information: non-paged memory
2023-04-20T02:58:00.595803 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0bdc000 allocated at kernel_clone+0x8c/0x36c
2023-04-20T02:58:00.596106 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-20T02:58:00.596608 kern :alert : Register r6 information: zero-size pointer
2023-04-20T02:58:00.596853 kern :alert : Register r7 information: slab task_struct start c232b300 pointer offset 0 size 2176
2023-04-20T02:58:00.617800 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-20T02:58:00.618117 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-20T02:58:00.618619 kern :alert : Register r10 information: non-slab/vmalloc memory
... (104 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440aa6769c70828fc2e85fb
failing since 44 days (last pass: v6.2-rc1-23-g93899a4cb7b1, first fail: v6.3-rc1)
48 lines
2023-04-20T02:58:00.541802 kern :alert : 8<--- cut here ---
2023-04-20T02:58:00.542102 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:58:00.542604 kern :alert : [c1a50741] *pgd=61a1141e(bad)
2023-04-20T02:58:00.542849 kern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:58:00.551579 kern :alert : Register r1 information: non<8>[ 24.579922] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/6440aad8d8cadfd2d82e865d
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-lenovo-TPad-C13-Yoga-zork.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-lenovo-TPad-C13-Yoga-zork.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/6440aad8d8cadfd2d82e8662
failing since 12 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-20T03:00:24.210726 <8>[ 11.668661] <LAVA_SIGNAL_ENDRUN 0_dmesg 10058027_1.4.2.3.1>
2023-04-20T03:00:24.315707 / # #
2023-04-20T03:00:24.416717 export SHELL=/bin/sh
2023-04-20T03:00:24.416969 #
2023-04-20T03:00:24.517930 / # export SHELL=/bin/sh. /lava-10058027/environment
2023-04-20T03:00:24.518150
2023-04-20T03:00:24.619055 / # . /lava-10058027/environment/lava-10058027/bin/lava-test-runner /lava-10058027/1
2023-04-20T03:00:24.619381
2023-04-20T03:00:24.623972 / # /lava-10058027/bin/lava-test-runner /lava-10058027/1
2023-04-20T03:00:24.630027 + export 'TESTRUN_ID=1_bootrr'
... (11 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
mt8183-kukui-...uniper-sku16 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 3
Details: https://kernelci.org/test/plan/id/6440ad1a7183fc03982e85ee
Results: 166 PASS, 6 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-mt8183-kukui-jacuzzi-juniper-sku16.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-mt8183-kukui-jacuzzi-juniper-sku16.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/arm64/rootfs.cpio.gz
* baseline.bootrr.panel-edp-probed: https://kernelci.org/test/case/id/6440ad1a7183fc03982e863b
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
2023-04-20T03:09:54.261304 /lava-10058152/1/../bin/lava-test-case
2023-04-20T03:09:54.271554 <8>[ 23.452662] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=panel-edp-probed RESULT=fail>
* baseline.bootrr.clk-mt8183-pericfg-probed: https://kernelci.org/test/case/id/6440ad1a7183fc03982e868d
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
2023-04-20T03:09:51.392938 /lava-10058152/1/../bin/lava-test-case
2023-04-20T03:09:51.403360 <8>[ 20.584067] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=clk-mt8183-pericfg-probed RESULT=fail>
* baseline.bootrr.clk-mt8183-infracfg-probed: https://kernelci.org/test/case/id/6440ad1a7183fc03982e868e
failing since 44 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
2023-04-20T03:09:50.364079 /lava-10058152/1/../bin/lava-test-case
2023-04-20T03:09:50.374588 <8>[ 19.555504] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=clk-mt8183-infracfg-probed RESULT=fail>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
rk3288-rock2-square | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/6440a9e00e99bbcd722e85fc
Results: 10 PASS, 2 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-rk3288-rock2-square.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-8-g0ad5ce8407db/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-rk3288-rock2-square.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230414.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/6440a9e00e99bbcd722e8609
failing since 8 days (last pass: v6.3-rc1-6-g14bb09b32f43, first fail: v6.3-rc1-7-g419346a03810)
30 lines
* baseline.dmesg.alert: https://kernelci.org/test/case/id/6440a9e00e99bbcd722e860a
failing since 8 days (last pass: v6.3-rc1-6-g14bb09b32f43, first fail: v6.3-rc1-7-g419346a03810)
16 lines
2023-04-20T02:56:18.568447 kern :alert : 8<--- cut here ---
2023-04-20T02:56:18.568516 kern :alert : Unhandled faul<8>[ 13.003592] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=16>
2023-04-20T02:56:18.568566 t: alignment exception (0x001) at 0xc1a50741
2023-04-20T02:56:18.568615 kern :alert : [c1a50741] *pgd=01a1141e(bad)
2023-04-20T02:56:18.568660 kern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-20T02:56:18.568703 kern :alert : Register r1 informat<8>[ 13.029414] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=emerg RESULT=fail UNITS=lines MEASUREMENT=30>
2023-04-20T02:56:18.568751 ion: non-paged memory
^ permalink raw reply
* chrome-platform/for-kernelci build: 5 builds: 0 failed, 5 passed (v6.3-rc1-8-g0ad5ce8407db)
From: kernelci.org bot @ 2023-04-20 3:05 UTC (permalink / raw)
To: kernel-build-reports, kernelci-results, chrome-platform,
eballetbo, bleung, groeck, pmalani
chrome-platform/for-kernelci build: 5 builds: 0 failed, 5 passed (v6.3-rc1-8-g0ad5ce8407db)
Full Build Summary: https://kernelci.org/build/chrome-platform/branch/for-kernelci/kernel/v6.3-rc1-8-g0ad5ce8407db/
Tree: chrome-platform
Branch: for-kernelci
Git Describe: v6.3-rc1-8-g0ad5ce8407db
Git Commit: 0ad5ce8407db2e44922ee21d2f2a9de4df336038
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
Built: 3 unique architectures
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH] platform: chrome: wilco_ec: remove return value check of debugfs_create_dir()
From: patchwork-bot+chrome-platform @ 2023-04-20 1:50 UTC (permalink / raw)
To: Zhengkang Huang; +Cc: bleung, dzm91, chrome-platform, linux-kernel
In-Reply-To: <20230419100303.343379-1-zkhuang@hust.edu.cn>
Hello:
This patch was applied to chrome-platform/linux.git (for-kernelci)
by Tzung-Bi Shih <tzungbi@kernel.org>:
On Wed, 19 Apr 2023 18:03:03 +0800 you wrote:
> Smatch complains that:
> wilco_ec_debugfs_probe() warn: 'debug_info->dir' is an error
> pointer or valid
>
> Debugfs checks are generally not supposed to be checked
> for errors and it is not necessary here.
>
> [...]
Here is the summary with links:
- platform: chrome: wilco_ec: remove return value check of debugfs_create_dir()
https://git.kernel.org/chrome-platform/c/0ad5ce8407db
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] platform: chrome: wilco_ec: remove return value check of debugfs_create_dir()
From: Zhengkang Huang @ 2023-04-19 10:03 UTC (permalink / raw)
To: Benson Leung; +Cc: Zhengkang Huang, Dongliang Mu, chrome-platform, linux-kernel
Smatch complains that:
wilco_ec_debugfs_probe() warn: 'debug_info->dir' is an error
pointer or valid
Debugfs checks are generally not supposed to be checked
for errors and it is not necessary here.
Just delete the dead code.
Signed-off-by: Zhengkang Huang <zkhuang@hust.edu.cn>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
---
NOTES: The issue is found by static analysis and remains untested.
---
drivers/platform/chrome/wilco_ec/debugfs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c b/drivers/platform/chrome/wilco_ec/debugfs.c
index a812788a0bdc..7a13f13b16cd 100644
--- a/drivers/platform/chrome/wilco_ec/debugfs.c
+++ b/drivers/platform/chrome/wilco_ec/debugfs.c
@@ -251,8 +251,6 @@ static int wilco_ec_debugfs_probe(struct platform_device *pdev)
return 0;
debug_info->ec = ec;
debug_info->dir = debugfs_create_dir("wilco_ec", NULL);
- if (!debug_info->dir)
- return 0;
debugfs_create_file("raw", 0644, debug_info->dir, NULL, &fops_raw);
debugfs_create_file("h1_gpio", 0444, debug_info->dir, ec,
&fops_h1_gpio);
--
2.40.0
^ permalink raw reply related
* Re: [PATCH 000/117] media: Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-04-17 8:54 UTC (permalink / raw)
To: Biju Das
Cc: Laurent Pinchart, Heiko Stuebner, Eddie James, Hans Verkuil,
Alim Akhtar, Dmitry Osipenko,
linux-stm32@st-md-mailman.stormreply.com, Jerome Brunet,
linux-samsung-soc@vger.kernel.org, Robert Foss, Sean Young,
Samuel Holland, Kevin Hilman, Michal Simek, Antti Palosaari,
NXP Linux Team, linux-sunxi@lists.linux.dev, ye xingchen,
Sascha Hauer, Łukasz Stelmach, Eugen Hristev, Shuah Khan,
Andrzej Pietrasiewicz, Hyun Kwon, Andrew Jeffery, Michael Tretter,
Benoit Parrot, Moudy Ho, kernel@pengutronix.de, Hans Verkuil,
Claudiu Beznea, Ming Qian, Andrew-CT Chen, Alexandre Belloni,
Sylwester Nawrocki, linux-aspeed@lists.ozlabs.org, Yunfei Dong,
Lad, Prabhakar, Thierry Reding, Guenter Roeck,
chrome-platform@lists.linux.dev, Jonathan Hunter,
linux-rockchip@lists.infradead.org, Fabien Dessenne,
Ezequiel Garcia, Alain Volmat, Marek Szyprowski, Colin Ian King,
linux-media@vger.kernel.org, Jacopo Mondi, Rory Liu,
Martin Blumenstingl, linux-arm-msm@vger.kernel.org, Sean Wang,
Fabrizio Castro, Maxime Ripard, linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, Neil Armstrong, Zhou Peng,
Paul Kocialkowski, Maxime Coquelin, Christophe JAILLET,
Jacek Anaszewski, Dan Carpenter, Dafna Hirschfeld,
Xavier Roumegue, Ettore Chimenti, Vikash Garodia,
Matthias Brugger, Andrzej Hajda, Fabio Estevam,
Jean-Christophe Trotin, Stanimir Varbanov, Kieran Bingham,
Jernej Skrabec, Chen-Yu Tsai, Jacob Chen, Joel Stanley,
Yang Yingliang, Patrice Chotard, Bin Liu, Nathan Chancellor,
Sylwester Nawrocki, Mauro Carvalho Chehab, Benson Leung,
Daniel W. S. Almeida, Qiheng Lin, Konrad Dybcio, Kieran Bingham,
Yang Li, Sakari Ailus, Ricardo Ribalda, Shawn Guo, Minghsiu Tsai,
Daniel Almeida, Alexandre Torgue, Todor Tomov, Mirela Rabulea,
Ajye Huang, Scott Chao, linux-renesas-soc@vger.kernel.org,
Hugues Fruchet, openbmc@lists.ozlabs.org, Andy Gross,
Mikhail Ulyanov, Prabhakar Mahadev Lad, Eduardo Valentin,
Rui Miguel Silva, linux-mediatek@lists.infradead.org, Yong Deng,
linux-tegra@vger.kernel.org, Tiffany Lin,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Houlong Wei, Krzysztof Kozlowski, Philipp Zabel,
Niklas Söderlund
In-Reply-To: <OS0PR01MB59221153A63F64BBAD3ED20D869C9@OS0PR01MB5922.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
On Mon, Apr 17, 2023 at 07:57:57AM +0000, Biju Das wrote:
> Hi Uwe,
> > > I think the series got applied to the master branch of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git.
> > > It should thus appear in v6.4.
> >
> > I guess that linux-stable.git is a copy&paste failure (and it's not there).
> > I don't see the series in the master branch of
> > git://linuxtv.org/media_tree.git either.
> >
> > .. a bit later ...
> >
> > ah, it's in git://linuxtv.org/mchehab/media-next.git
> >
> > I guess I was just to quick and probably the series will be included in
> > today's next.
>
> I believe patchwork <patchwork@linuxtv.org> will send notification to
> author and along with people who applied tags for that patch.
Indeed, I got such a notification on Apr 11. But even if I had that on
my radar when asking and considered such notifications reliable in
general, I would have asked, as the patches didn't apprear in next up to
now.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH 000/117] media: Convert to platform remove callback returning void
From: Biju Das @ 2023-04-17 7:57 UTC (permalink / raw)
To: Uwe Kleine-König, Laurent Pinchart
Cc: Heiko Stuebner, Eddie James, Hans Verkuil, Alim Akhtar,
Dmitry Osipenko, linux-stm32@st-md-mailman.stormreply.com,
Marek Szyprowski, linux-samsung-soc@vger.kernel.org, Robert Foss,
Dafna Hirschfeld, Samuel Holland, Kevin Hilman, Michal Simek,
Antti Palosaari, NXP Linux Team, Jerome Brunet,
linux-sunxi@lists.linux.dev, ye xingchen, Sascha Hauer,
Łukasz Stelmach, Eugen Hristev, Shuah Khan, Hyun Kwon,
Andrew Jeffery, Michael Tretter, Moudy Ho, kernel@pengutronix.de,
Hans Verkuil, Claudiu Beznea, Ming Qian, Andrew-CT Chen,
Alexandre Belloni, Sylwester Nawrocki,
linux-aspeed@lists.ozlabs.org, Yunfei Dong, Lad, Prabhakar,
Thierry Reding, Guenter Roeck, chrome-platform@lists.linux.dev,
Jonathan Hunter, linux-rockchip@lists.infradead.org,
Fabien Dessenne, Ezequiel Garcia, Alain Volmat,
Andrzej Pietrasiewicz, Colin Ian King,
linux-media@vger.kernel.org, Jacopo Mondi, Rory Liu,
Martin Blumenstingl, linux-arm-msm@vger.kernel.org, Sean Wang,
Maxime Ripard, Fabrizio Castro, linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, Neil Armstrong, Zhou Peng,
Paul Kocialkowski, Maxime Coquelin,
linux-mediatek@lists.infradead.org, Jacek Anaszewski,
Dan Carpenter, Sean Young, Xavier Roumegue, Ettore Chimenti,
Vikash Garodia, linux-tegra@vger.kernel.org, Eduardo Valentin,
Andrzej Hajda, Fabio Estevam, Jean-Christophe Trotin,
Stanimir Varbanov, Kieran Bingham, Jernej Skrabec, Chen-Yu Tsai,
Jacob Chen, Joel Stanley, Yang Yingliang, Patrice Chotard,
Bin Liu, Nathan Chancellor, Sylwester Nawrocki,
Mauro Carvalho Chehab, Benson Leung, Daniel W. S. Almeida,
Qiheng Lin, Konrad Dybcio, Kieran Bingham, Yang Li, Sakari Ailus,
Ricardo Ribalda, Shawn Guo, Minghsiu Tsai, Daniel Almeida,
Alexandre Torgue, Todor Tomov, Mirela Rabulea, Ajye Huang,
Scott Chao, linux-renesas-soc@vger.kernel.org, Hugues Fruchet,
openbmc@lists.ozlabs.org, Andy Gross, Mikhail Ulyanov,
Prabhakar Mahadev Lad, Benoit Parrot, Rui Miguel Silva,
Christophe JAILLET, Yong Deng, Matthias Brugger, Tiffany Lin,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Houlong Wei, Krzysztof Kozlowski, Philipp Zabel,
Niklas Söderlund
In-Reply-To: <20230417073049.2b5b35hpjrjcrlge@pengutronix.de>
Hi Uwe,
> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Sent: Monday, April 17, 2023 8:31 AM
> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Heiko Stuebner <heiko@sntech.de>; Eddie James <eajames@linux.ibm.com>;
> Hans Verkuil <hverkuil@xs4all.nl>; Alim Akhtar <alim.akhtar@samsung.com>;
> Dmitry Osipenko <digetx@gmail.com>; linux-stm32@st-md-
> mailman.stormreply.com; Marek Szyprowski <m.szyprowski@samsung.com>; linux-
> samsung-soc@vger.kernel.org; Robert Foss <rfoss@kernel.org>; Dafna
> Hirschfeld <dafna@fastmail.com>; Samuel Holland <samuel@sholland.org>; Kevin
> Hilman <khilman@baylibre.com>; Michal Simek <michal.simek@xilinx.com>; Antti
> Palosaari <crope@iki.fi>; NXP Linux Team <linux-imx@nxp.com>; Jerome Brunet
> <jbrunet@baylibre.com>; linux-sunxi@lists.linux.dev; ye xingchen
> <ye.xingchen@zte.com.cn>; Sascha Hauer <s.hauer@pengutronix.de>; Łukasz
> Stelmach <l.stelmach@samsung.com>; Eugen Hristev
> <eugen.hristev@collabora.com>; Shuah Khan <skhan@linuxfoundation.org>; Hyun
> Kwon <hyun.kwon@xilinx.com>; Andrew Jeffery <andrew@aj.id.au>; Michael
> Tretter <m.tretter@pengutronix.de>; Moudy Ho <moudy.ho@mediatek.com>;
> kernel@pengutronix.de; Hans Verkuil <hverkuil-cisco@xs4all.nl>; Claudiu
> Beznea <claudiu.beznea@microchip.com>; Ming Qian <ming.qian@nxp.com>;
> Andrew-CT Chen <andrew-ct.chen@mediatek.com>; Alexandre Belloni
> <alexandre.belloni@bootlin.com>; Sylwester Nawrocki
> <s.nawrocki@samsung.com>; linux-aspeed@lists.ozlabs.org; Yunfei Dong
> <yunfei.dong@mediatek.com>; Lad, Prabhakar <prabhakar.csengg@gmail.com>;
> Thierry Reding <thierry.reding@gmail.com>; Guenter Roeck
> <groeck@chromium.org>; chrome-platform@lists.linux.dev; Jonathan Hunter
> <jonathanh@nvidia.com>; linux-rockchip@lists.infradead.org; Fabien Dessenne
> <fabien.dessenne@foss.st.com>; Ezequiel Garcia
> <ezequiel@vanguardiasur.com.ar>; Alain Volmat <alain.volmat@foss.st.com>;
> Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>; Colin Ian King
> <colin.i.king@gmail.com>; linux-media@vger.kernel.org; Jacopo Mondi
> <jacopo@jmondi.org>; Rory Liu <hellojacky0226@hotmail.com>; Martin
> Blumenstingl <martin.blumenstingl@googlemail.com>; linux-arm-
> msm@vger.kernel.org; Sean Wang <sean.wang@mediatek.com>; Maxime Ripard
> <mripard@kernel.org>; Fabrizio Castro <fabrizio.castro.jz@renesas.com>;
> linux-amlogic@lists.infradead.org; linux-arm-kernel@lists.infradead.org;
> Neil Armstrong <neil.armstrong@linaro.org>; Zhou Peng <eagle.zhou@nxp.com>;
> Paul Kocialkowski <paul.kocialkowski@bootlin.com>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; linux-mediatek@lists.infradead.org; Jacek
> Anaszewski <jacek.anaszewski@gmail.com>; Dan Carpenter <error27@gmail.com>;
> Sean Young <sean@mess.org>; Xavier Roumegue <xavier.roumegue@oss.nxp.com>;
> Ettore Chimenti <ek5.chimenti@gmail.com>; Vikash Garodia
> <quic_vgarodia@quicinc.com>; linux-tegra@vger.kernel.org; Eduardo Valentin
> <edubezval@gmail.com>; Andrzej Hajda <andrzej.hajda@intel.com>; Fabio
> Estevam <festevam@gmail.com>; Jean-Christophe Trotin <jean-
> christophe.trotin@foss.st.com>; Stanimir Varbanov
> <stanimir.k.varbanov@gmail.com>; Kieran Bingham
> <kieran.bingham@ideasonboard.com>; Jernej Skrabec
> <jernej.skrabec@gmail.com>; Chen-Yu Tsai <wens@csie.org>; Jacob Chen <jacob-
> chen@iotwrt.com>; Joel Stanley <joel@jms.id.au>; Yang Yingliang
> <yangyingliang@huawei.com>; Patrice Chotard <patrice.chotard@foss.st.com>;
> Bin Liu <bin.liu@mediatek.com>; Nathan Chancellor <nathan@kernel.org>;
> Sylwester Nawrocki <sylvester.nawrocki@gmail.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Benson Leung <bleung@chromium.org>; Daniel W. S.
> Almeida <dwlsalmeida@gmail.com>; Qiheng Lin <linqiheng@huawei.com>; Konrad
> Dybcio <konrad.dybcio@linaro.org>; Kieran Bingham
> <kieran.bingham+renesas@ideasonboard.com>; Yang Li
> <yang.lee@linux.alibaba.com>; Sakari Ailus <sakari.ailus@linux.intel.com>;
> Ricardo Ribalda <ribalda@chromium.org>; Shawn Guo <shawnguo@kernel.org>;
> Minghsiu Tsai <minghsiu.tsai@mediatek.com>; Daniel Almeida
> <daniel.almeida@collabora.com>; Alexandre Torgue
> <alexandre.torgue@foss.st.com>; Todor Tomov <todor.too@gmail.com>; Mirela
> Rabulea <mirela.rabulea@nxp.com>; Ajye Huang <ajye_huang@compal.corp-
> partner.google.com>; Scott Chao <scott_chao@wistron.corp-
> partner.google.com>; linux-renesas-soc@vger.kernel.org; Hugues Fruchet
> <hugues.fruchet@foss.st.com>; openbmc@lists.ozlabs.org; Andy Gross
> <agross@kernel.org>; Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>;
> Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>; Benoit
> Parrot <bparrot@ti.com>; Rui Miguel Silva <rmfrfs@gmail.com>; Christophe
> JAILLET <christophe.jaillet@wanadoo.fr>; Yong Deng <yong.deng@magewell.com>;
> Matthias Brugger <matthias.bgg@gmail.com>; Tiffany Lin
> <tiffany.lin@mediatek.com>; AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>; Bjorn Andersson
> <andersson@kernel.org>; Nicolas Ferre <nicolas.ferre@microchip.com>; Houlong
> Wei <houlong.wei@mediatek.com>; Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org>; Philipp Zabel <p.zabel@pengutronix.de>;
> Niklas Söderlund <niklas.soderlund@ragnatech.se>
> Subject: Re: [PATCH 000/117] media: Convert to platform remove callback
> returning void
>
> Hello Laurent,
>
> On Mon, Apr 17, 2023 at 09:19:28AM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 17, 2023 at 08:02:03AM +0200, Uwe Kleine-König wrote:
> > > On Sun, Mar 26, 2023 at 04:30:25PM +0200, Uwe Kleine-König wrote:
> > > > Hello,
> > > >
> > > > this series adapts the platform drivers below drivers/pci to use
> > > > the
> > >
> > > copy&paste failure here: s/pci/media/ of course.
> > >
> > > > .remove_new() callback. Compared to the traditional .remove()
> > > > callback
> > > > .remove_new() returns no value. This is a good thing because the
> > > > driver core doesn't (and cannot) cope for errors during remove.
> > > > The only effect of a non-zero return value in .remove() is that
> > > > the driver core emits a warning. The device is removed anyhow and
> > > > an early return from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors
> > > > cannot reasonably assume any more that there is some kind of cleanup
> later.
> > > >
> > > > Only three drivers needed some preparation first to make sure they
> > > > return 0 unconditionally in their remove callback. Then all
> > > > drivers could be trivially converted without side effects to
> .remove_new().
> > > >
> > > > The changes to the individual drivers are all orthogonal. If I
> > > > need to resend some patches because of some review feedback, I'd
> > > > like to only send the patches that actually needed changes, so
> > > > please pick up the remaining patches that don't need changing to
> reduce the amount of mail.
> > >
> > > I didn't hear anything back about application of this series. Is
> > > there a blocker somewhere?
> >
> > I think the series got applied to the master branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git.
> > It should thus appear in v6.4.
>
> I guess that linux-stable.git is a copy&paste failure (and it's not there).
> I don't see the series in the master branch of
> git://linuxtv.org/media_tree.git either.
>
> .. a bit later ...
>
> ah, it's in git://linuxtv.org/mchehab/media-next.git
>
> I guess I was just to quick and probably the series will be included in
> today's next.
I believe patchwork <patchwork@linuxtv.org> will send notification to
author and along with people who applied tags for that patch.
I normally get notification from patchwork <patchwork@linuxtv.org>
When the state of patch changes.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH 000/117] media: Convert to platform remove callback returning void
From: Laurent Pinchart @ 2023-04-17 7:35 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stuebner, Eddie James, Hans Verkuil, Alim Akhtar,
Dmitry Osipenko, linux-stm32, Marek Szyprowski, linux-samsung-soc,
Robert Foss, Dafna Hirschfeld, Samuel Holland, Kevin Hilman,
Michal Simek, Antti Palosaari, NXP Linux Team, Jerome Brunet,
linux-sunxi, ye xingchen, Sascha Hauer, Łukasz Stelmach,
Eugen Hristev, Shuah Khan, Hyun Kwon, Andrew Jeffery,
Michael Tretter, Moudy Ho, kernel, Hans Verkuil, Claudiu Beznea,
Ming Qian, Andrew-CT Chen, Alexandre Belloni, Sylwester Nawrocki,
linux-aspeed, Yunfei Dong, Lad, Prabhakar, Thierry Reding,
Guenter Roeck, chrome-platform, Jonathan Hunter, linux-rockchip,
Fabien Dessenne, Ezequiel Garcia, Alain Volmat,
Andrzej Pietrasiewicz, Colin Ian King, linux-media, Jacopo Mondi,
Rory Liu, Martin Blumenstingl, linux-arm-msm, Sean Wang,
Maxime Ripard, Fabrizio Castro, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Zhou Peng, Paul Kocialkowski, Maxime Coquelin,
linux-mediatek, Jacek Anaszewski, Dan Carpenter, Sean Young,
Xavier Roumegue, Ettore Chimenti, Vikash Garodia, linux-tegra,
Eduardo Valentin, Andrzej Hajda, Fabio Estevam,
Jean-Christophe Trotin, Stanimir Varbanov, Kieran Bingham,
Jernej Skrabec, Chen-Yu Tsai, Jacob Chen, Joel Stanley,
Yang Yingliang, Patrice Chotard, Bin Liu, Nathan Chancellor,
Sylwester Nawrocki, Mauro Carvalho Chehab, Benson Leung,
Daniel W. S. Almeida, Qiheng Lin, Konrad Dybcio, Kieran Bingham,
Yang Li, Sakari Ailus, Ricardo Ribalda, Shawn Guo, Minghsiu Tsai,
Daniel Almeida, Alexandre Torgue, Todor Tomov, Mirela Rabulea,
Ajye Huang, Scott Chao, linux-renesas-soc, Hugues Fruchet,
openbmc, Andy Gross, Mikhail Ulyanov, Lad Prabhakar,
Benoit Parrot, Rui Miguel Silva, Christophe JAILLET, Yong Deng,
Matthias Brugger, Tiffany Lin, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Houlong Wei, Krzysztof Kozlowski,
Philipp Zabel, Niklas Söderlund
In-Reply-To: <20230417073049.2b5b35hpjrjcrlge@pengutronix.de>
On Mon, Apr 17, 2023 at 09:30:49AM +0200, Uwe Kleine-König wrote:
> Hello Laurent,
>
> On Mon, Apr 17, 2023 at 09:19:28AM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 17, 2023 at 08:02:03AM +0200, Uwe Kleine-König wrote:
> > > On Sun, Mar 26, 2023 at 04:30:25PM +0200, Uwe Kleine-König wrote:
> > > > Hello,
> > > >
> > > > this series adapts the platform drivers below drivers/pci to use the
> > >
> > > copy&paste failure here: s/pci/media/ of course.
> > >
> > > > .remove_new() callback. Compared to the traditional .remove() callback
> > > > .remove_new() returns no value. This is a good thing because the driver core
> > > > doesn't (and cannot) cope for errors during remove. The only effect of a
> > > > non-zero return value in .remove() is that the driver core emits a warning. The
> > > > device is removed anyhow and an early return from .remove() usually yields a
> > > > resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably assume any more that there is some kind of cleanup later.
> > > >
> > > > Only three drivers needed some preparation first to make sure they
> > > > return 0 unconditionally in their remove callback. Then all drivers
> > > > could be trivially converted without side effects to .remove_new().
> > > >
> > > > The changes to the individual drivers are all orthogonal. If I need to
> > > > resend some patches because of some review feedback, I'd like to only
> > > > send the patches that actually needed changes, so please pick up the
> > > > remaining patches that don't need changing to reduce the amount of mail.
> > >
> > > I didn't hear anything back about application of this series. Is there a
> > > blocker somewhere?
> >
> > I think the series got applied to the master branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git.
> > It should thus appear in v6.4.
>
> I guess that linux-stable.git is a copy&paste failure (and it's not
> there). I don't see the series in the master branch of
> git://linuxtv.org/media_tree.git either.
Oops sorry. It was a copy & paste mistake indeed, I meant
git://linuxtv.org/media_stage.git
> .. a bit later ...
>
> ah, it's in git://linuxtv.org/mchehab/media-next.git
>
> I guess I was just to quick and probably the series will be included in
> today's next.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 000/117] media: Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-04-17 7:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Heiko Stuebner, Eddie James, Hans Verkuil, Alim Akhtar,
Dmitry Osipenko, linux-stm32, Marek Szyprowski, linux-samsung-soc,
Robert Foss, Dafna Hirschfeld, Samuel Holland, Kevin Hilman,
Michal Simek, Antti Palosaari, NXP Linux Team, Jerome Brunet,
linux-sunxi, ye xingchen, Sascha Hauer, Łukasz Stelmach,
Eugen Hristev, Shuah Khan, Hyun Kwon, Andrew Jeffery,
Michael Tretter, Moudy Ho, kernel, Hans Verkuil, Claudiu Beznea,
Ming Qian, Andrew-CT Chen, Alexandre Belloni, Sylwester Nawrocki,
linux-aspeed, Yunfei Dong, Lad, Prabhakar, Thierry Reding,
Guenter Roeck, chrome-platform, Jonathan Hunter, linux-rockchip,
Fabien Dessenne, Ezequiel Garcia, Alain Volmat,
Andrzej Pietrasiewicz, Colin Ian King, linux-media, Jacopo Mondi,
Rory Liu, Martin Blumenstingl, linux-arm-msm, Sean Wang,
Maxime Ripard, Fabrizio Castro, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Zhou Peng, Paul Kocialkowski, Maxime Coquelin,
linux-mediatek, Jacek Anaszewski, Dan Carpenter, Sean Young,
Xavier Roumegue, Ettore Chimenti, Vikash Garodia, linux-tegra,
Eduardo Valentin, Andrzej Hajda, Fabio Estevam,
Jean-Christophe Trotin, Stanimir Varbanov, Kieran Bingham,
Jernej Skrabec, Chen-Yu Tsai, Jacob Chen, Joel Stanley,
Yang Yingliang, Patrice Chotard, Bin Liu, Nathan Chancellor,
Sylwester Nawrocki, Mauro Carvalho Chehab, Benson Leung,
Daniel W. S. Almeida, Qiheng Lin, Konrad Dybcio, Kieran Bingham,
Yang Li, Sakari Ailus, Ricardo Ribalda, Shawn Guo, Minghsiu Tsai,
Daniel Almeida, Alexandre Torgue, Todor Tomov, Mirela Rabulea,
Ajye Huang, Scott Chao, linux-renesas-soc, Hugues Fruchet,
openbmc, Andy Gross, Mikhail Ulyanov, Lad Prabhakar,
Benoit Parrot, Rui Miguel Silva, Christophe JAILLET, Yong Deng,
Matthias Brugger, Tiffany Lin, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Houlong Wei, Krzysztof Kozlowski,
Philipp Zabel, Niklas Söderlund
In-Reply-To: <20230417061928.GD28551@pendragon.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]
Hello Laurent,
On Mon, Apr 17, 2023 at 09:19:28AM +0300, Laurent Pinchart wrote:
> On Mon, Apr 17, 2023 at 08:02:03AM +0200, Uwe Kleine-König wrote:
> > On Sun, Mar 26, 2023 at 04:30:25PM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > this series adapts the platform drivers below drivers/pci to use the
> >
> > copy&paste failure here: s/pci/media/ of course.
> >
> > > .remove_new() callback. Compared to the traditional .remove() callback
> > > .remove_new() returns no value. This is a good thing because the driver core
> > > doesn't (and cannot) cope for errors during remove. The only effect of a
> > > non-zero return value in .remove() is that the driver core emits a warning. The
> > > device is removed anyhow and an early return from .remove() usually yields a
> > > resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably assume any more that there is some kind of cleanup later.
> > >
> > > Only three drivers needed some preparation first to make sure they
> > > return 0 unconditionally in their remove callback. Then all drivers
> > > could be trivially converted without side effects to .remove_new().
> > >
> > > The changes to the individual drivers are all orthogonal. If I need to
> > > resend some patches because of some review feedback, I'd like to only
> > > send the patches that actually needed changes, so please pick up the
> > > remaining patches that don't need changing to reduce the amount of mail.
> >
> > I didn't hear anything back about application of this series. Is there a
> > blocker somewhere?
>
> I think the series got applied to the master branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git.
> It should thus appear in v6.4.
I guess that linux-stable.git is a copy&paste failure (and it's not
there). I don't see the series in the master branch of
git://linuxtv.org/media_tree.git either.
.. a bit later ...
ah, it's in git://linuxtv.org/mchehab/media-next.git
I guess I was just to quick and probably the series will be included in
today's next.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 000/117] media: Convert to platform remove callback returning void
From: Laurent Pinchart @ 2023-04-17 6:19 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mauro Carvalho Chehab, linux-aspeed, Alim Akhtar, Hans Verkuil,
Benson Leung, Ajye Huang, Rory Liu, Scott Chao, Neil Armstrong,
Kevin Hilman, Marek Szyprowski, Ettore Chimenti, Alain Volmat,
Maxime Coquelin, Alexandre Torgue, Sean Young, Sakari Ailus,
Ricardo Ribalda, Yang Yingliang, Thierry Reding, Jonathan Hunter,
Antti Palosaari, Michael Tretter, Ming Qian, Zhou Peng,
Eddie James, Joel Stanley, Eugen Hristev, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Maxime Ripard, Philipp Zabel,
Bin Liu, Matthias Brugger, Minghsiu Tsai, Houlong Wei,
Andrew-CT Chen, Moudy Ho, Qiheng Lin, Tiffany Lin, Yunfei Dong,
Dmitry Osipenko, Xavier Roumegue, Mirela Rabulea, Shawn Guo,
Sascha Hauer, Rui Miguel Silva, Robert Foss, Todor Tomov,
Andy Gross, Bjorn Andersson, Stanimir Varbanov, Vikash Garodia,
Niklas Söderlund, Fabrizio Castro, Kieran Bingham,
Mikhail Ulyanov, Jacopo Mondi, Lad Prabhakar, Nathan Chancellor,
Yang Li, Dan Carpenter, Jacob Chen, Ezequiel Garcia,
Heiko Stuebner, Dafna Hirschfeld, Krzysztof Kozlowski,
Colin Ian King, Sylwester Nawrocki, Sylwester Nawrocki,
Łukasz Stelmach, Andrzej Pietrasiewicz, Jacek Anaszewski,
Andrzej Hajda, Fabien Dessenne, Patrice Chotard, Hugues Fruchet,
Jean-Christophe Trotin, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Yong Deng, Paul Kocialkowski, Christophe JAILLET,
Lad, Prabhakar, Benoit Parrot, Hyun Kwon, Michal Simek,
ye xingchen, Eduardo Valentin, Sean Wang, Daniel W. S. Almeida,
Shuah Khan, Daniel Almeida, Hans Verkuil, Guenter Roeck,
Fabio Estevam, linux-stm32, Jerome Brunet, chrome-platform,
linux-samsung-soc, Konrad Dybcio, openbmc, Kieran Bingham,
linux-rockchip, NXP Linux Team, linux-sunxi, linux-media,
Martin Blumenstingl, linux-arm-msm, linux-mediatek, linux-tegra,
linux-amlogic, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-renesas-soc, kernel
In-Reply-To: <20230417060203.le3izz56wt73si6k@pengutronix.de>
Hi Uwe,
On Mon, Apr 17, 2023 at 08:02:03AM +0200, Uwe Kleine-König wrote:
> Hello Mauro
>
> On Sun, Mar 26, 2023 at 04:30:25PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > this series adapts the platform drivers below drivers/pci to use the
>
> copy&paste failure here: s/pci/media/ of course.
>
> > .remove_new() callback. Compared to the traditional .remove() callback
> > .remove_new() returns no value. This is a good thing because the driver core
> > doesn't (and cannot) cope for errors during remove. The only effect of a
> > non-zero return value in .remove() is that the driver core emits a warning. The
> > device is removed anyhow and an early return from .remove() usually yields a
> > resource leak.
> >
> > By changing the remove callback to return void driver authors cannot
> > reasonably assume any more that there is some kind of cleanup later.
> >
> > Only three drivers needed some preparation first to make sure they
> > return 0 unconditionally in their remove callback. Then all drivers
> > could be trivially converted without side effects to .remove_new().
> >
> > The changes to the individual drivers are all orthogonal. If I need to
> > resend some patches because of some review feedback, I'd like to only
> > send the patches that actually needed changes, so please pick up the
> > remaining patches that don't need changing to reduce the amount of mail.
>
> I didn't hear anything back about application of this series. Is there a
> blocker somewhere?
I think the series got applied to the master branch of
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git.
It should thus appear in v6.4.
The corresponding series for staging media drivers has also been applied
to the same branch as far as I can tell.
> Apart from the three preparatory patches that are a precondition to the
> conversion of the respective drivers, the patches are all pairwise
> orthogonal. So from my POV the best would be to apply all patches that
> still apply (which might be all), I will care for the fallout later
> then.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 000/117] media: Convert to platform remove callback returning void
From: Uwe Kleine-König @ 2023-04-17 6:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: linux-aspeed, Alim Akhtar, Hans Verkuil, Benson Leung, Ajye Huang,
Rory Liu, Scott Chao, Neil Armstrong, Kevin Hilman,
Marek Szyprowski, Ettore Chimenti, Alain Volmat, Maxime Coquelin,
Alexandre Torgue, Sean Young, Sakari Ailus, Ricardo Ribalda,
Laurent Pinchart, Yang Yingliang, Thierry Reding, Jonathan Hunter,
Antti Palosaari, Michael Tretter, Ming Qian, Zhou Peng,
Eddie James, Joel Stanley, Eugen Hristev, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Maxime Ripard, Philipp Zabel,
Bin Liu, Matthias Brugger, Minghsiu Tsai, Houlong Wei,
Andrew-CT Chen, Moudy Ho, Qiheng Lin, Tiffany Lin, Yunfei Dong,
Dmitry Osipenko, Xavier Roumegue, Mirela Rabulea, Shawn Guo,
Sascha Hauer, Rui Miguel Silva, Robert Foss, Todor Tomov,
Andy Gross, Bjorn Andersson, Stanimir Varbanov, Vikash Garodia,
Niklas Söderlund, Fabrizio Castro, Kieran Bingham,
Mikhail Ulyanov, Jacopo Mondi, Lad Prabhakar, Nathan Chancellor,
Yang Li, Dan Carpenter, Jacob Chen, Ezequiel Garcia,
Heiko Stuebner, Dafna Hirschfeld, Krzysztof Kozlowski,
Colin Ian King, Sylwester Nawrocki, Sylwester Nawrocki,
Łukasz Stelmach, Andrzej Pietrasiewicz, Jacek Anaszewski,
Andrzej Hajda, Fabien Dessenne, Patrice Chotard, Hugues Fruchet,
Jean-Christophe Trotin, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Yong Deng, Paul Kocialkowski, Christophe JAILLET,
Lad, Prabhakar, Benoit Parrot, Hyun Kwon, Michal Simek,
ye xingchen, Eduardo Valentin, Sean Wang, Daniel W. S. Almeida,
Shuah Khan, Daniel Almeida, Hans Verkuil, Guenter Roeck,
Fabio Estevam, linux-stm32, Jerome Brunet, chrome-platform,
linux-samsung-soc, Konrad Dybcio, openbmc, Kieran Bingham,
linux-rockchip, NXP Linux Team, linux-sunxi, linux-media,
Martin Blumenstingl, linux-arm-msm, linux-mediatek, linux-tegra,
linux-amlogic, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-renesas-soc, kernel
In-Reply-To: <20230326143224.572654-1-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
Hello Mauro
On Sun, Mar 26, 2023 at 04:30:25PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this series adapts the platform drivers below drivers/pci to use the
copy&paste failure here: s/pci/media/ of course.
> .remove_new() callback. Compared to the traditional .remove() callback
> .remove_new() returns no value. This is a good thing because the driver core
> doesn't (and cannot) cope for errors during remove. The only effect of a
> non-zero return value in .remove() is that the driver core emits a warning. The
> device is removed anyhow and an early return from .remove() usually yields a
> resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably assume any more that there is some kind of cleanup later.
>
> Only three drivers needed some preparation first to make sure they
> return 0 unconditionally in their remove callback. Then all drivers
> could be trivially converted without side effects to .remove_new().
>
> The changes to the individual drivers are all orthogonal. If I need to
> resend some patches because of some review feedback, I'd like to only
> send the patches that actually needed changes, so please pick up the
> remaining patches that don't need changing to reduce the amount of mail.
I didn't hear anything back about application of this series. Is there a
blocker somewhere?
Apart from the three preparatory patches that are a precondition to the
conversion of the respective drivers, the patches are all pairwise
orthogonal. So from my POV the best would be to apply all patches that
still apply (which might be all), I will care for the fallout later
then.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support
From: Stephen Boyd @ 2023-04-14 0:22 UTC (permalink / raw)
To: Pin-yen Lin
Cc: Andrzej Hajda, Andy Shevchenko, Benson Leung, Daniel Scally,
Daniel Vetter, David Airlie, Greg Kroah-Hartman, Guenter Roeck,
Heikki Krogerus, Jernej Skrabec, Jonas Karlman,
Krzysztof Kozlowski, Laurent Pinchart, Neil Armstrong,
Prashant Malani, Rafael J . Wysocki, Rob Herring, Robert Foss,
Sakari Ailus, Xin Ji, Marek Vasut, Hsin-Yi Wang,
Thomas Zimmermann, AngeloGioacchino Del Regno, Lyude Paul,
devicetree, dri-devel, linux-acpi, chrome-platform,
Nícolas F . R . A . Prado, Javier Martinez Canillas,
linux-kernel, Krzysztof Kozlowski, Chen-Yu Tsai
In-Reply-To: <CAEXTbpdcbB_z4ZGCGzc-cM74ECKyxekbroKCWFnhH8eR=4HmvA@mail.gmail.com>
Quoting Pin-yen Lin (2023-04-13 02:50:44)
> Hi Stephen,
>
> On Wed, Apr 12, 2023 at 10:38 AM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Pin-yen Lin (2023-03-31 02:11:39)
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index b42553ac505c..604c7391d74f 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -12,7 +12,8 @@ maintainers:
> > >
> > > description: |
> > > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > > - designed for portable devices.
> > > + designed for portable devices. Product brief is available at
> > > + https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
> > >
> > > properties:
> > > compatible:
> > > @@ -112,9 +113,40 @@ properties:
> > > data-lanes: true
> > >
> > > port@1:
> > > - $ref: /schemas/graph.yaml#/properties/port
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > description:
> > > - Video port for panel or connector.
> > > + Video port for panel or connector. Each endpoint connects to a video
> > > + output downstream, and the "data-lanes" property is used to describe
> > > + the pin connections. 0, 1, 2, 3 in "data-lanes" maps to SSRX1, SSTX1,
> > > + SSRX2, SSTX2, respectively.
> > > +
> > > + patternProperties:
> > > + "^endpoint@[01]$":
> > > + $ref: /schemas/media/video-interfaces.yaml#
> > > + properties:
> > > + reg: true
> > > +
> > > + remote-endpoint: true
> > > +
> > > + data-lanes:
> > > + oneOf:
> > > + - items:
> > > + - enum: [0, 1, 2, 3]
> > > +
> > > + - items:
> > > + - const: 0
> > > + - const: 1
> > > +
> > > + - items:
> > > + - const: 2
> > > + - const: 3
> > > +
> > > + mode-switch:
> >
> > Is it possible to not have this property? Can we have the driver for
> > this anx device look at the remote-endpoint and if it sees that it is
> > not a drm_bridge or panel on the other end, or a DP connector, that it
> > should register a typec mode switch (or two depending on the number of
> > endpoints in port@1)? Is there any case where that doesn't hold true?
> >
> > I see these possible scenarios:
> >
> > 1. DPI to DP bridge steering DP to one of two usb-c-connectors
> >
> > In this case, endpoint@0 is connected to one usb-c-connector and
> > endpoint@1 is connected to another usb-c-connector. The input endpoint
> > is only connected to DPI. The USB endpoint is not present (although I
> > don't see this described in the binding either, so we would need a
> > port@2, entirely optional to describe USB3 input). The driver will
> > register two mode switches.
> >
> > 2. DPI to DP bridge with USB3 to one usb-c-connector
> >
> > In this case, endpoint@1 doesn't exist. The SSTX1/2 and SSRX1/2 pins are
> > all connected to a usb-c-connector node. The input ports (0 and 2) are
> > connected to both DPI and USB. The device acts as both a mode-switch and
> > an orientation-switch. It registers both switches. I wonder if there is
> > any benefit to describing SBU connections or CC connections? Maybe we
> > don't register the orientation-switch if the SBU or CC connection isn't
> > described?
> >
> > 3. DPI to DP bridge connected to eDP panel
> >
> > In this case, endpoint@1 doesn't exist. The USB endpoint is not present
> > (port@2). Depending on how the crosspoint should be configured, we'll
> > need to use data-lanes in the port@1 endpoint to describe which SSTRX
> > pair to use (1 or 2). Or we'll have to use the endpoint's reg property
> > to describe which pair to drive DP on. Presumably the default
> > configuration is SSRX2/SSTX2 providing 2 lanes of DP to an eDP panel.
> > The endpoint@0 in port@1 will be connected to a drm_panel, and the
> > driver will be able to detect this properly by checking for the
> > existence of an aux-bus node or the return value of
> > of_dp_aux_populate_bus().
>
> Can we assume that the eDP panel always stays behind an `aux-bus`
> node? Can't the panel be connected to the bridge directly in the
> graph? Though this might not matter if we only register mode switches
> when there are usb-c-connectors connected.
The panel is connected to the bridge in the graph. I think we should
assume the eDP panel is on an aux-bus. Maybe another scenario is a
design that has a DP to HDMI bridge wired down on the device? In which
case the output port would be connected to the HDMI bridge.
> >
> > 4. DPI to DP bridge connected to DP connector
> >
> > This is similar to the eDP panel scenario #3. In this case, endpoint@1
> > doesn't exist. The USB endpoint is not present (port@2). Same story
> > about port@1 and lane configuration, but we don't have an aux-bus node.
> > In this case, the drivers/gpu/drm/bridge/display-connector.c driver will
> > probe for the dp-connector node and add a drm_bridge. This anx driver
> > will similarly add a drm_bridge, but it needs to look at the node
> > connected on port@1:endpoint@0 with drm_of_get_bridge() and check if it
> > is a drm_bridge (DP connector) or if it is some type-c thing (connector
> > or orientation-switch).
> >
> > I think having this mode-switch property here lets us avoid calling
> > drm_of_get_bridge() unconditionally in anx7625_parse_dt().
> > drm_of_get_bridge() will always return -EPROBE_DEFER when this is the
> > last drm_bridge in the chain and the other side of the endpoint is a
> > type-c thing (scenarios #1 and #2). Maybe we should teach
> > drm_of_get_bridge() that a drm_bridge might be connected to a type-c
> > device and have it not return -EPROBE_DEFER in that case. Or make some
> > new API like drm_of_get_bridge_typec() that checks if the typec
> > framework knows about the endpoint in question (as either a typec switch
> > or a connector) and returns a NULL bridge pointer. If we had that then I
> > think this property is not necessary.
> >
> > Hopefully the usb-c-connector can always be registered with the typec
> > framework? I'm worried that the driver that registers the
> > usb-c-connector node may want to form a struct typec_port with
> > typec_register_port() and that will get stuck in a similar -EPROBE_DEFER
> > loop waiting for this mode-switch to appear. So having this property
> > also avoids that problem by telling typec framework to wait until this
> > driver can register a mode-switch.
> >
> > TL;DR: Is this mode-switch property a workaround for probe defer? Can we
> > figure out where the mode switch is in software and not have the
> > property in DT? If we can it would certainly improve things because
> > forgetting to add the property can lead to broken behavior, and we don't
> > do anything like this for chains of drm_bridge devices. We just describe
> > the display chain and let the kernel figure out which bridge should
> > handle hpd, edid reading, or mode detection, etc.
>
> Actually the `mode-switch` property here is mainly because
> `fwnode_typec_mux_get`[1] and `typec_mux_match`[2] only return matches
> when the property is present. I am not sure what side effects would be
> if I remove the ID-matching condition in `typec_mux_match`, so I added
> the property here.
>
> Is it feasible to remove the `mode-switch` property here given the
> existing implementation of the Type-C framework?
Omitting the mode-switch property would require changes to the type-c
framework.
I'm wondering if we can have this anx driver register mode switches for
however many endpoints exist in the output port all the time when the
aux-bus node doesn't exist. Then the type-c framework can walk from the
usb-c-connector to each connected node looking for a device that is both
a drm_bridge and a mode-switch. When it finds that combination, it knows
that the mode-switch has been found. This hinges on the idea that a
device that would have the mode-switch property is a drm_bridge and
would register a mode-switch with the type-c framework.
It may be a little complicated though, because we would only register
one drm_bridge for the input to this anx device. The type-c walking code
would need to look at the graph endpoint, and find the parent device to
see if it is a drm_bridge.
^ permalink raw reply
* Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support
From: Pin-yen Lin @ 2023-04-13 9:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Andrzej Hajda, Andy Shevchenko, Benson Leung, Daniel Scally,
Daniel Vetter, David Airlie, Greg Kroah-Hartman, Guenter Roeck,
Heikki Krogerus, Jernej Skrabec, Jonas Karlman,
Krzysztof Kozlowski, Laurent Pinchart, Neil Armstrong,
Prashant Malani, Rafael J . Wysocki, Rob Herring, Robert Foss,
Sakari Ailus, Xin Ji, Marek Vasut, Hsin-Yi Wang,
Thomas Zimmermann, AngeloGioacchino Del Regno, Lyude Paul,
devicetree, dri-devel, linux-acpi, chrome-platform,
Nícolas F . R . A . Prado, Javier Martinez Canillas,
linux-kernel, Krzysztof Kozlowski, Chen-Yu Tsai
In-Reply-To: <CAE-0n51E5foFWQAsA73662_5e6XP426wuUCVVmcS5UWwiYpDmw@mail.gmail.com>
Hi Stephen,
On Wed, Apr 12, 2023 at 10:38 AM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Pin-yen Lin (2023-03-31 02:11:39)
> > diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > index b42553ac505c..604c7391d74f 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > @@ -12,7 +12,8 @@ maintainers:
> >
> > description: |
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > - designed for portable devices.
> > + designed for portable devices. Product brief is available at
> > + https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
> >
> > properties:
> > compatible:
> > @@ -112,9 +113,40 @@ properties:
> > data-lanes: true
> >
> > port@1:
> > - $ref: /schemas/graph.yaml#/properties/port
> > + $ref: /schemas/graph.yaml#/$defs/port-base
> > description:
> > - Video port for panel or connector.
> > + Video port for panel or connector. Each endpoint connects to a video
> > + output downstream, and the "data-lanes" property is used to describe
> > + the pin connections. 0, 1, 2, 3 in "data-lanes" maps to SSRX1, SSTX1,
> > + SSRX2, SSTX2, respectively.
> > +
> > + patternProperties:
> > + "^endpoint@[01]$":
> > + $ref: /schemas/media/video-interfaces.yaml#
> > + properties:
> > + reg: true
> > +
> > + remote-endpoint: true
> > +
> > + data-lanes:
> > + oneOf:
> > + - items:
> > + - enum: [0, 1, 2, 3]
> > +
> > + - items:
> > + - const: 0
> > + - const: 1
> > +
> > + - items:
> > + - const: 2
> > + - const: 3
> > +
> > + mode-switch:
>
> Is it possible to not have this property? Can we have the driver for
> this anx device look at the remote-endpoint and if it sees that it is
> not a drm_bridge or panel on the other end, or a DP connector, that it
> should register a typec mode switch (or two depending on the number of
> endpoints in port@1)? Is there any case where that doesn't hold true?
>
> I see these possible scenarios:
>
> 1. DPI to DP bridge steering DP to one of two usb-c-connectors
>
> In this case, endpoint@0 is connected to one usb-c-connector and
> endpoint@1 is connected to another usb-c-connector. The input endpoint
> is only connected to DPI. The USB endpoint is not present (although I
> don't see this described in the binding either, so we would need a
> port@2, entirely optional to describe USB3 input). The driver will
> register two mode switches.
>
> 2. DPI to DP bridge with USB3 to one usb-c-connector
>
> In this case, endpoint@1 doesn't exist. The SSTX1/2 and SSRX1/2 pins are
> all connected to a usb-c-connector node. The input ports (0 and 2) are
> connected to both DPI and USB. The device acts as both a mode-switch and
> an orientation-switch. It registers both switches. I wonder if there is
> any benefit to describing SBU connections or CC connections? Maybe we
> don't register the orientation-switch if the SBU or CC connection isn't
> described?
>
> 3. DPI to DP bridge connected to eDP panel
>
> In this case, endpoint@1 doesn't exist. The USB endpoint is not present
> (port@2). Depending on how the crosspoint should be configured, we'll
> need to use data-lanes in the port@1 endpoint to describe which SSTRX
> pair to use (1 or 2). Or we'll have to use the endpoint's reg property
> to describe which pair to drive DP on. Presumably the default
> configuration is SSRX2/SSTX2 providing 2 lanes of DP to an eDP panel.
> The endpoint@0 in port@1 will be connected to a drm_panel, and the
> driver will be able to detect this properly by checking for the
> existence of an aux-bus node or the return value of
> of_dp_aux_populate_bus().
Can we assume that the eDP panel always stays behind an `aux-bus`
node? Can't the panel be connected to the bridge directly in the
graph? Though this might not matter if we only register mode switches
when there are usb-c-connectors connected.
>
> 4. DPI to DP bridge connected to DP connector
>
> This is similar to the eDP panel scenario #3. In this case, endpoint@1
> doesn't exist. The USB endpoint is not present (port@2). Same story
> about port@1 and lane configuration, but we don't have an aux-bus node.
> In this case, the drivers/gpu/drm/bridge/display-connector.c driver will
> probe for the dp-connector node and add a drm_bridge. This anx driver
> will similarly add a drm_bridge, but it needs to look at the node
> connected on port@1:endpoint@0 with drm_of_get_bridge() and check if it
> is a drm_bridge (DP connector) or if it is some type-c thing (connector
> or orientation-switch).
>
> I think having this mode-switch property here lets us avoid calling
> drm_of_get_bridge() unconditionally in anx7625_parse_dt().
> drm_of_get_bridge() will always return -EPROBE_DEFER when this is the
> last drm_bridge in the chain and the other side of the endpoint is a
> type-c thing (scenarios #1 and #2). Maybe we should teach
> drm_of_get_bridge() that a drm_bridge might be connected to a type-c
> device and have it not return -EPROBE_DEFER in that case. Or make some
> new API like drm_of_get_bridge_typec() that checks if the typec
> framework knows about the endpoint in question (as either a typec switch
> or a connector) and returns a NULL bridge pointer. If we had that then I
> think this property is not necessary.
>
> Hopefully the usb-c-connector can always be registered with the typec
> framework? I'm worried that the driver that registers the
> usb-c-connector node may want to form a struct typec_port with
> typec_register_port() and that will get stuck in a similar -EPROBE_DEFER
> loop waiting for this mode-switch to appear. So having this property
> also avoids that problem by telling typec framework to wait until this
> driver can register a mode-switch.
>
> TL;DR: Is this mode-switch property a workaround for probe defer? Can we
> figure out where the mode switch is in software and not have the
> property in DT? If we can it would certainly improve things because
> forgetting to add the property can lead to broken behavior, and we don't
> do anything like this for chains of drm_bridge devices. We just describe
> the display chain and let the kernel figure out which bridge should
> handle hpd, edid reading, or mode detection, etc.
Actually the `mode-switch` property here is mainly because
`fwnode_typec_mux_get`[1] and `typec_mux_match`[2] only return matches
when the property is present. I am not sure what side effects would be
if I remove the ID-matching condition in `typec_mux_match`, so I added
the property here.
Is it feasible to remove the `mode-switch` property here given the
existing implementation of the Type-C framework?
[1]: https://elixir.bootlin.com/linux/latest/source/drivers/usb/typec/mux.c#L351
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/usb/typec/mux.c#L290
Best regards,
Pin-yen
^ permalink raw reply
* Re: [PATCH] platform/chrome: cros_ec_debugfs: fix kernel-doc warning
From: Tzung-Bi Shih @ 2023-04-12 2:48 UTC (permalink / raw)
To: Prashant Malani
Cc: bleung, groeck, chrome-platform, robbarnes, kernel test robot
In-Reply-To: <CACeCKaduOqLwGsGLEVzdG2hDNq8=07a_V-uGLZWT0f3+Wb603Q@mail.gmail.com>
On Tue, Apr 11, 2023 at 10:38:15AM -0700, Prashant Malani wrote:
> On Mon, Apr 10, 2023 at 10:33 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >
> > Fix the following kernel-doc warning:
> >
> > $ ./scripts/kernel-doc -none drivers/platform/chrome/*
> > [...]
> > warning: This comment starts with '/**', but isn't a kernel-doc comment.
> >
> > Fixes: 14bb09b32f43 ("platform/chrome: cros_ec: Separate logic for getting panic info")
> > Reported-by: kernel test robot <lkp@intel.com>
> > Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> > ---
> > I should put it in my checklist in the future before pushing patches to
> > for-next.
>
> Can this be added to kernelci?
I'm afraid not; build tests performed by KernelCI only for its tests. 0-day
performs better on such kind of static checks.
^ permalink raw reply
* Re: [PATCH] platform/chrome: cros_ec_debugfs: fix kernel-doc warning
From: patchwork-bot+chrome-platform @ 2023-04-12 2:40 UTC (permalink / raw)
To: Tzung-Bi Shih; +Cc: bleung, groeck, chrome-platform, robbarnes, lkp
In-Reply-To: <20230411053308.1572493-1-tzungbi@kernel.org>
Hello:
This patch was applied to chrome-platform/linux.git (for-next)
by Tzung-Bi Shih <tzungbi@kernel.org>:
On Tue, 11 Apr 2023 13:33:08 +0800 you wrote:
> Fix the following kernel-doc warning:
>
> $ ./scripts/kernel-doc -none drivers/platform/chrome/*
> [...]
> warning: This comment starts with '/**', but isn't a kernel-doc comment.
>
> Fixes: 14bb09b32f43 ("platform/chrome: cros_ec: Separate logic for getting panic info")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
>
> [...]
Here is the summary with links:
- platform/chrome: cros_ec_debugfs: fix kernel-doc warning
https://git.kernel.org/chrome-platform/c/419346a03810
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v15 04/10] dt-bindings: display: bridge: anx7625: Add mode-switch support
From: Stephen Boyd @ 2023-04-12 1:38 UTC (permalink / raw)
To: Andrzej Hajda, Andy Shevchenko, Benson Leung, Daniel Scally,
Daniel Vetter, David Airlie, Greg Kroah-Hartman, Guenter Roeck,
Heikki Krogerus, Jernej Skrabec, Jonas Karlman,
Krzysztof Kozlowski, Laurent Pinchart, Neil Armstrong,
Pin-yen Lin, Prashant Malani, Rafael J . Wysocki, Rob Herring,
Robert Foss, Sakari Ailus
Cc: Xin Ji, Marek Vasut, Hsin-Yi Wang, Thomas Zimmermann,
AngeloGioacchino Del Regno, Lyude Paul, devicetree, dri-devel,
linux-acpi, chrome-platform, Nícolas F . R . A . Prado,
Javier Martinez Canillas, linux-kernel, Krzysztof Kozlowski,
Chen-Yu Tsai
In-Reply-To: <20230331091145.737305-5-treapking@chromium.org>
Quoting Pin-yen Lin (2023-03-31 02:11:39)
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index b42553ac505c..604c7391d74f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -12,7 +12,8 @@ maintainers:
>
> description: |
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> - designed for portable devices.
> + designed for portable devices. Product brief is available at
> + https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
>
> properties:
> compatible:
> @@ -112,9 +113,40 @@ properties:
> data-lanes: true
>
> port@1:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
> description:
> - Video port for panel or connector.
> + Video port for panel or connector. Each endpoint connects to a video
> + output downstream, and the "data-lanes" property is used to describe
> + the pin connections. 0, 1, 2, 3 in "data-lanes" maps to SSRX1, SSTX1,
> + SSRX2, SSTX2, respectively.
> +
> + patternProperties:
> + "^endpoint@[01]$":
> + $ref: /schemas/media/video-interfaces.yaml#
> + properties:
> + reg: true
> +
> + remote-endpoint: true
> +
> + data-lanes:
> + oneOf:
> + - items:
> + - enum: [0, 1, 2, 3]
> +
> + - items:
> + - const: 0
> + - const: 1
> +
> + - items:
> + - const: 2
> + - const: 3
> +
> + mode-switch:
Is it possible to not have this property? Can we have the driver for
this anx device look at the remote-endpoint and if it sees that it is
not a drm_bridge or panel on the other end, or a DP connector, that it
should register a typec mode switch (or two depending on the number of
endpoints in port@1)? Is there any case where that doesn't hold true?
I see these possible scenarios:
1. DPI to DP bridge steering DP to one of two usb-c-connectors
In this case, endpoint@0 is connected to one usb-c-connector and
endpoint@1 is connected to another usb-c-connector. The input endpoint
is only connected to DPI. The USB endpoint is not present (although I
don't see this described in the binding either, so we would need a
port@2, entirely optional to describe USB3 input). The driver will
register two mode switches.
2. DPI to DP bridge with USB3 to one usb-c-connector
In this case, endpoint@1 doesn't exist. The SSTX1/2 and SSRX1/2 pins are
all connected to a usb-c-connector node. The input ports (0 and 2) are
connected to both DPI and USB. The device acts as both a mode-switch and
an orientation-switch. It registers both switches. I wonder if there is
any benefit to describing SBU connections or CC connections? Maybe we
don't register the orientation-switch if the SBU or CC connection isn't
described?
3. DPI to DP bridge connected to eDP panel
In this case, endpoint@1 doesn't exist. The USB endpoint is not present
(port@2). Depending on how the crosspoint should be configured, we'll
need to use data-lanes in the port@1 endpoint to describe which SSTRX
pair to use (1 or 2). Or we'll have to use the endpoint's reg property
to describe which pair to drive DP on. Presumably the default
configuration is SSRX2/SSTX2 providing 2 lanes of DP to an eDP panel.
The endpoint@0 in port@1 will be connected to a drm_panel, and the
driver will be able to detect this properly by checking for the
existence of an aux-bus node or the return value of
of_dp_aux_populate_bus().
4. DPI to DP bridge connected to DP connector
This is similar to the eDP panel scenario #3. In this case, endpoint@1
doesn't exist. The USB endpoint is not present (port@2). Same story
about port@1 and lane configuration, but we don't have an aux-bus node.
In this case, the drivers/gpu/drm/bridge/display-connector.c driver will
probe for the dp-connector node and add a drm_bridge. This anx driver
will similarly add a drm_bridge, but it needs to look at the node
connected on port@1:endpoint@0 with drm_of_get_bridge() and check if it
is a drm_bridge (DP connector) or if it is some type-c thing (connector
or orientation-switch).
I think having this mode-switch property here lets us avoid calling
drm_of_get_bridge() unconditionally in anx7625_parse_dt().
drm_of_get_bridge() will always return -EPROBE_DEFER when this is the
last drm_bridge in the chain and the other side of the endpoint is a
type-c thing (scenarios #1 and #2). Maybe we should teach
drm_of_get_bridge() that a drm_bridge might be connected to a type-c
device and have it not return -EPROBE_DEFER in that case. Or make some
new API like drm_of_get_bridge_typec() that checks if the typec
framework knows about the endpoint in question (as either a typec switch
or a connector) and returns a NULL bridge pointer. If we had that then I
think this property is not necessary.
Hopefully the usb-c-connector can always be registered with the typec
framework? I'm worried that the driver that registers the
usb-c-connector node may want to form a struct typec_port with
typec_register_port() and that will get stuck in a similar -EPROBE_DEFER
loop waiting for this mode-switch to appear. So having this property
also avoids that problem by telling typec framework to wait until this
driver can register a mode-switch.
TL;DR: Is this mode-switch property a workaround for probe defer? Can we
figure out where the mode switch is in software and not have the
property in DT? If we can it would certainly improve things because
forgetting to add the property can lead to broken behavior, and we don't
do anything like this for chains of drm_bridge devices. We just describe
the display chain and let the kernel figure out which bridge should
handle hpd, edid reading, or mode detection, etc.
^ permalink raw reply
* Re:Re: [PATCH] platform/chrome: cros_ec_typec: Add missing fwnode_handle_put()
From: Liang He @ 2023-04-12 0:26 UTC (permalink / raw)
To: Prashant Malani; +Cc: bleung, groeck, chrome-platform
In-Reply-To: <CACeCKacsy5tbSFATgtsDYfAJi68ExpbJDBGv2Z0K4N-dC7H8aA@mail.gmail.com>
At 2023-04-12 04:30:35, "Prashant Malani" <pmalani@chromium.org> wrote:
>Hi Liang He,
>
>Can you please resend this patch? I don't see it in patchwork or the
>mailing list any more.
>
>Thanks!
>
I will resend now, thanks for your work on my patch.
Liang
>On Tue, Mar 21, 2023 at 9:11 PM Liang He <windhl@126.com> wrote:
>>
>> In cros_typec_init_ports(), we should add fwnode_handle_put()
>> when break out of the iteration device_for_each_child_node()
>> as it will automatically increase and decrease the refcounter.
>>
>> Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver")
>> Signed-off-by: Liang He <windhl@126.com>
>> ---
>> drivers/platform/chrome/cros_ec_typec.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
>> index 2a7ff14dc37e..3a242effc85d 100644
>> --- a/drivers/platform/chrome/cros_ec_typec.c
>> +++ b/drivers/platform/chrome/cros_ec_typec.c
>> @@ -443,6 +443,7 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
>> return 0;
>>
>> unregister_ports:
>> + fwnode_handle_put(fwnode);
>> cros_unregister_ports(typec);
>> return ret;
>> }
>> --
>> 2.25.1
>>
^ permalink raw reply
* Re: [PATCH] platform/chrome: cros_ec_typec: Add missing fwnode_handle_put()
From: Prashant Malani @ 2023-04-11 20:30 UTC (permalink / raw)
To: Liang He; +Cc: bleung, groeck, chrome-platform
In-Reply-To: <20230322041054.1856718-1-windhl@126.com>
Hi Liang He,
Can you please resend this patch? I don't see it in patchwork or the
mailing list any more.
Thanks!
On Tue, Mar 21, 2023 at 9:11 PM Liang He <windhl@126.com> wrote:
>
> In cros_typec_init_ports(), we should add fwnode_handle_put()
> when break out of the iteration device_for_each_child_node()
> as it will automatically increase and decrease the refcounter.
>
> Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver")
> Signed-off-by: Liang He <windhl@126.com>
> ---
> drivers/platform/chrome/cros_ec_typec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
> index 2a7ff14dc37e..3a242effc85d 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -443,6 +443,7 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
> return 0;
>
> unregister_ports:
> + fwnode_handle_put(fwnode);
> cros_unregister_ports(typec);
> return ret;
> }
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] platform/chrome: cros_ec_debugfs: fix kernel-doc warning
From: Prashant Malani @ 2023-04-11 17:38 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: bleung, groeck, chrome-platform, robbarnes, kernel test robot
In-Reply-To: <20230411053308.1572493-1-tzungbi@kernel.org>
On Mon, Apr 10, 2023 at 10:33 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
>
> Fix the following kernel-doc warning:
>
> $ ./scripts/kernel-doc -none drivers/platform/chrome/*
> [...]
> warning: This comment starts with '/**', but isn't a kernel-doc comment.
>
> Fixes: 14bb09b32f43 ("platform/chrome: cros_ec: Separate logic for getting panic info")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> ---
> I should put it in my checklist in the future before pushing patches to
> for-next.
Can this be added to kernelci?
>
> drivers/platform/chrome/cros_ec_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c b/drivers/platform/chrome/cros_ec_debugfs.c
> index 414ebfffcf83..c876120e0ebc 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -400,7 +400,7 @@ static void cros_ec_cleanup_console_log(struct cros_ec_debugfs *debug_info)
> }
> }
>
> -/**
> +/*
> * Returns the size of the panicinfo data fetched from the EC
> */
> static int cros_ec_get_panicinfo(struct cros_ec_device *ec_dev, uint8_t *data,
> --
> 2.40.0.577.gac1e443424-goog
>
>
^ permalink raw reply
* chrome-platform/for-kernelci sleep: 7 runs, 1 regressions (v6.3-rc1-7-g419346a03810)
From: kernelci.org bot @ 2023-04-11 11:05 UTC (permalink / raw)
To: kernel-build-reports, kernelci-results, chrome-platform,
eballetbo, bleung, groeck, pmalani
chrome-platform/for-kernelci sleep: 7 runs, 1 regressions (v6.3-rc1-7-g419346a03810)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
-----------------+-------+---------------+----------+----------------------------+------------
rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/job/chrome-platform/branch/for-kernelci/kernel/v6.3-rc1-7-g419346a03810/plan/sleep/
Test: sleep
Tree: chrome-platform
Branch: for-kernelci
Describe: v6.3-rc1-7-g419346a03810
URL: https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
SHA: 419346a0381034fcc0866be9605108c8612847de
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
-----------------+-------+---------------+----------+----------------------------+------------
rk3399-gru-kevin | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 1
Details: https://kernelci.org/test/plan/id/643533f7da8fd141f92e85f6
Results: 12 PASS, 1 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/sleep-rk3399-gru-kevin.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/sleep-rk3399-gru-kevin.html
Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye/20230407.0/arm64/rootfs.cpio.gz
* sleep.rtcwake-mem-2: https://kernelci.org/test/case/id/643533f7da8fd141f92e8600
new failure (last pass: v6.3-rc1-6-g14bb09b32f43)
2023-04-11T10:13:18.710107 rtcwake: assuming RTC uses UTC ...
2023-04-11T10:13:18.716460 rtcwake: wakeup from "mem" using rtc0 at Mon Apr 10 01:08:33 2023
2023-04-11T10:13:18.730290 <6>[ 35.747416] PM: suspend entry (deep)
2023-04-11T10:13:18.755101 <6>[ 35.770695] Filesystems sync: 0.000 seconds
2023-04-11T10:13:18.770950 <6>[ 35.787824] Freezing user space processes
2023-04-11T10:13:18.794286 <6>[ 35.807298] Freezing user space processes completed (elapsed 0.008 seconds)
2023-04-11T10:13:18.801670 <6>[ 35.818737] OOM killer disabled.
2023-04-11T10:13:18.809611 <6>[ 35.825928] Freezing remaining freezable tasks
2023-04-11T10:13:18.823267 <6>[ 35.835522] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
2023-04-11T10:13:18.833472 <6>[ 35.846964] printk: Suspending console(s) (use no_console_suspend to debug)
... (15 line(s) more)
^ permalink raw reply
* chrome-platform/for-kernelci baseline: 86 runs, 33 regressions (v6.3-rc1-7-g419346a03810)
From: kernelci.org bot @ 2023-04-11 10:50 UTC (permalink / raw)
To: kernel-build-reports, kernelci-results, chrome-platform,
eballetbo, bleung, groeck, pmalani
chrome-platform/for-kernelci baseline: 86 runs, 33 regressions (v6.3-rc1-7-g419346a03810)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
imx6dl-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
imx6q-sabrelite | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
imx6q-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
imx6qp-wandboard-revd1 | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
imx6ul-14x14-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
imx7d-sdb | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
imx7ulp-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
mt8183-kukui-...uniper-sku16 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 3
odroid-xu3 | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 1
qemu_x86_64 | x86_64 | lab-broonie | gcc-10 | x86_64_defconfig | 1
qemu_x86_64 | x86_64 | lab-broonie | gcc-10 | x86_64_defcon...6-chromebook | 1
qemu_x86_64-uefi | x86_64 | lab-broonie | gcc-10 | x86_64_defconfig | 1
qemu_x86_64-uefi | x86_64 | lab-broonie | gcc-10 | x86_64_defcon...6-chromebook | 1
qemu_x86_64-uefi-mixed | x86_64 | lab-broonie | gcc-10 | x86_64_defconfig | 1
qemu_x86_64-uefi-mixed | x86_64 | lab-broonie | gcc-10 | x86_64_defcon...6-chromebook | 1
rk3288-rock2-square | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/job/chrome-platform/branch/for-kernelci/kernel/v6.3-rc1-7-g419346a03810/plan/baseline/
Test: baseline
Tree: chrome-platform
Branch: for-kernelci
Describe: v6.3-rc1-7-g419346a03810
URL: https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
SHA: 419346a0381034fcc0866be9605108c8612847de
Test Regressions
----------------
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-C436FA-Flip-hatch | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352f2e48e317add82e8611
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-C436FA-Flip-hatch.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-C436FA-Flip-hatch.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352f2e48e317add82e8616
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:57:46.789628 + set +x
2023-04-11T09:57:46.796402 <8>[ 10.577062] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933808_1.4.2.3.1>
2023-04-11T09:57:46.904536 / # #
2023-04-11T09:57:47.007249 export SHELL=/bin/sh
2023-04-11T09:57:47.008133 #
2023-04-11T09:57:47.110192 / # export SHELL=/bin/sh. /lava-9933808/environment
2023-04-11T09:57:47.111009
2023-04-11T09:57:47.212949 / # . /lava-9933808/environment/lava-9933808/bin/lava-test-runner /lava-9933808/1
2023-04-11T09:57:47.214310
2023-04-11T09:57:47.219756 / # /lava-9933808/bin/lava-test-runner /lava-9933808/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-CM1400CXA-dalboz | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352e07b24c23ac5d2e85e6
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-CM1400CXA-dalboz.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-CM1400CXA-dalboz.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352e07b24c23ac5d2e85eb
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:52:48.467091 + set<8>[ 11.584094] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933871_1.4.2.3.1>
2023-04-11T09:52:48.467575 +x
2023-04-11T09:52:48.575002 / # #
2023-04-11T09:52:48.677980 export SHELL=/bin/sh
2023-04-11T09:52:48.678778 #
2023-04-11T09:52:48.781037 / # export SHELL=/bin/sh. /lava-9933871/environment
2023-04-11T09:52:48.781894
2023-04-11T09:52:48.883897 / # . /lava-9933871/environment/lava-9933871/bin/lava-test-runner /lava-9933871/1
2023-04-11T09:52:48.885191
2023-04-11T09:52:48.890137 / # /lava-9933871/bin/lava-test-runner /lava-9933871/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
asus-cx9400-volteer | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352df44819abe7bf2e8602
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-cx9400-volteer.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-asus-cx9400-volteer.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352df44819abe7bf2e8607
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:52:36.073919 <8>[ 11.317577] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933865_1.4.2.3.1>
2023-04-11T09:52:36.077292 + set +x
2023-04-11T09:52:36.182945 #
2023-04-11T09:52:36.184302
2023-04-11T09:52:36.286686 / # #export SHELL=/bin/sh
2023-04-11T09:52:36.287491
2023-04-11T09:52:36.389431 / # export SHELL=/bin/sh. /lava-9933865/environment
2023-04-11T09:52:36.390344
2023-04-11T09:52:36.492462 / # . /lava-9933865/environment/lava-9933865/bin/lava-test-runner /lava-9933865/1
2023-04-11T09:52:36.493925
... (13 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
hp-x360-12b-c...4020-octopus | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352dfb3a0b1d3dcd2e8611
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-12b-ca0010nr-n4020-octopus.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352dfb3a0b1d3dcd2e8616
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:52:46.184002 + set +x
2023-04-11T09:52:46.190293 <8>[ 10.257384] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933834_1.4.2.3.1>
2023-04-11T09:52:46.295661 / # #
2023-04-11T09:52:46.396748 export SHELL=/bin/sh
2023-04-11T09:52:46.396987 #
2023-04-11T09:52:46.497910 / # export SHELL=/bin/sh. /lava-9933834/environment
2023-04-11T09:52:46.498141
2023-04-11T09:52:46.599127 / # . /lava-9933834/environment/lava-9933834/bin/lava-test-runner /lava-9933834/1
2023-04-11T09:52:46.599431
2023-04-11T09:52:46.604158 / # /lava-9933834/bin/lava-test-runner /lava-9933834/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
hp-x360-14-G1-sona | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352dd0531933076e2e85eb
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352dd0531933076e2e85f0
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:52:04.545902 <8>[ 10.932533] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933830_1.4.2.3.1>
2023-04-11T09:52:04.549595 + set +x
2023-04-11T09:52:04.651364 /#
2023-04-11T09:52:04.752458 # #export SHELL=/bin/sh
2023-04-11T09:52:04.752619
2023-04-11T09:52:04.853688 / # export SHELL=/bin/sh. /lava-9933830/environment
2023-04-11T09:52:04.853886
2023-04-11T09:52:04.954712 / # . /lava-9933830/environment/lava-9933830/bin/lava-test-runner /lava-9933830/1
2023-04-11T09:52:04.954952
2023-04-11T09:52:04.959777 / # /lava-9933830/bin/lava-test-runner /lava-9933830/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
hp-x360-14a-cb0001xx-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352df2497f145f652e86f5
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14a-cb0001xx-zork.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14a-cb0001xx-zork.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352df2497f145f652e86fa
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:52:33.682881 + set<8>[ 10.689630] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933814_1.4.2.3.1>
2023-04-11T09:52:33.682992 +x
2023-04-11T09:52:33.787661 / # #
2023-04-11T09:52:33.888681 export SHELL=/bin/sh
2023-04-11T09:52:33.888926 #
2023-04-11T09:52:33.989879 / # export SHELL=/bin/sh. /lava-9933814/environment
2023-04-11T09:52:33.990081
2023-04-11T09:52:34.091077 / # . /lava-9933814/environment/lava-9933814/bin/lava-test-runner /lava-9933814/1
2023-04-11T09:52:34.091440
2023-04-11T09:52:34.095998 / # /lava-9933814/bin/lava-test-runner /lava-9933814/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6dl-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64353107ac39dc55e22e867f
Results: 13 PASS, 12 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6dl-udoo.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6dl-udoo.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64353107ac39dc55e22e8699
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-11T10:05:17.443181 k<8>[ 17.836621] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-11T10:05:17.443546 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T10:05:17.443770 kern :alert : Register r1 information: non-paged memory
2023-04-11T10:05:17.444229 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-11T10:05:17.444504 kern :alert : Register r3 information: non-paged memory
2023-04-11T10:05:17.465275 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0ce4000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T10:05:17.465869 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T10:05:17.466114 kern :alert : Register r6 information: zero-size pointer
2023-04-11T10:05:17.488468 kern :alert : Register r7 information: slab task_struct start c4c5d500 pointer offset 0 size 2176
2023-04-11T10:05:17.489014 kern :alert : Register r8 information: non-slab/vmalloc memory
... (102 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64353107ac39dc55e22e869a
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-11T10:05:17.421257 kern :alert : 8<--- cut here ---
2023-04-11T10:05:17.421641 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T10:05:17.422120 kern :alert : [c1a50741] *pgd=11a1141e(bad)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6q-sabrelite | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352f5662351768132e867b
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-imx6q-sabrelite.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-imx6q-sabrelite.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352f5662351768132e8682
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-11T09:58:35.134951 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T09:58:35.139339 kern :alert : Register r1 information: non-paged memory
2023-04-11T09:58:35.146204 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-11T09:58:35.149692 kern :alert : Register r3 information: non-paged memory
2023-04-11T09:58:35.160708 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0e00000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T09:58:35.166953 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T09:58:35.172116 kern :alert : Register r6 information: zero-size pointer
2023-04-11T09:58:35.180804 kern :alert : Register r7 information: slab task_struct start c266b300 pointer offset 0 size 2176
2023-04-11T09:58:35.185316 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-11T09:58:35.190205 kern :alert : Register r9 information: non-slab/vmalloc memory
... (101 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352f5662351768132e8683
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-11T09:58:35.108116 kern :alert : 8<--- cut here ---
2023-04-11T09:58:35.116193 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T09:58:35.119261 kern :alert : [c1a50741] *pgd=11a1141e(bad)
2023-04-11T09:58:35.130584 k<8>[ 7.939330] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6q-udoo | arm | lab-broonie | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352fd0552f67e7472e85f1
Results: 13 PASS, 12 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6q-udoo.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-broonie/baseline-imx6q-udoo.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352fd0552f67e7472e860b
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-11T10:00:16.851930 k<8>[ 16.404150] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-11T10:00:16.852534 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T10:00:16.852883 kern :alert : Register r1 information: non-paged memory
2023-04-11T10:00:16.853467 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-11T10:00:16.853745 kern :alert : Register r3 information: non-paged memory
2023-04-11T10:00:16.874083 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0d54000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T10:00:16.874863 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T10:00:16.875171 kern :alert : Register r6 information: zero-size pointer
2023-04-11T10:00:16.896283 kern :alert : Register r7 information: slab task_struct start c4908880 pointer offset 0 size 2176
2023-04-11T10:00:16.896861 kern :alert : Register r8 information: non-slab/vmalloc memory
... (102 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352fd0552f67e7472e860c
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-11T10:00:16.830088 kern :alert : 8<--- cut here ---
2023-04-11T10:00:16.830610 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T10:00:16.831217 kern :alert : [c1a50741] *pgd=11a1141e(bad)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6qp-wandboard-revd1 | arm | lab-pengutronix | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352f30739b42dc552e8606
Results: 4 PASS, 2 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx6qp-wandboard-revd1.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-pengutronix/baseline-imx6qp-wandboard-revd1.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352f30739b42dc552e860d
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
90 lines
2023-04-11T09:57:59.844638 mation: non-slab/vmalloc memory
2023-04-11T09:57:59.844788 kern :alert : Register r1 information: non-paged memory
2023-04-11T09:57:59.853723 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-11T09:57:59.853906 kern :alert : Register r3 information: non-paged memory
2023-04-11T09:57:59.862751 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0ddc000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T09:57:59.871740 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T09:57:59.880738 kern :alert : Register r6 information: zero-size pointer
2023-04-11T09:57:59.889883 kern :alert : Register r7 information: slab task_struct start c238cc80 pointer offset 0 size 2176
2023-04-11T09:57:59.890049 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-11T09:57:59.898862 kern :alert : Register r9 information: non-slab/vmalloc memory
... (102 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352f30739b42dc552e860e
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
48 lines
2023-04-11T09:57:59.817873 kern :alert : 8<--- cut here ---
2023-04-11T09:57:59.826640 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T09:57:59.826842 kern :alert : [c1a50741] *pgd=11a1141e(bad)
2023-04-11T09:57:59.835844 kern :alert : Register r0 infor[ 5.540738] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx6ul-14x14-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352f99916c391aec2e8610
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx6ul-14x14-evk.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx6ul-14x14-evk.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352f99916c391aec2e8617
failing since 18 days (last pass: v6.2-rc1-8-gf9a0ae83af2e, first fail: v6.3-rc1-4-g9ce5f3b3c18e2)
90 lines
2023-04-11T09:59:22.459643 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-11T09:59:22.459886 kern :alert : Register r3 information: non-paged memory
2023-04-11T09:59:22.479975 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xe0c40000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T09:59:22.480562 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T09:59:22.480823 kern :alert : Register r6 information: zero-size pointer
2023-04-11T09:59:22.494842 kern :alert : Register r7 information: slab task_struct start c7985d80 pointer offset 0 size 2176
2023-04-11T09:59:22.496082 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-11T09:59:22.505866 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-11T09:59:22.514152 kern :alert : Register r10 information: non-slab/vmalloc memory
2023-04-11T09:59:22.524155 kern :alert : Register r11 information: non-slab/vmalloc memory
... (105 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352f99916c391aec2e8618
failing since 18 days (last pass: v6.2-rc1-8-gf9a0ae83af2e, first fail: v6.3-rc1-4-g9ce5f3b3c18e2)
48 lines
2023-04-11T09:59:22.435976 kern :alert : 8<--- cut here ---
2023-04-11T09:59:22.436300 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T09:59:22.436807 kern :alert : [c1a50741] *pgd=81a1141e(bad)
2023-04-11T09:59:22.437055 kern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T09:59:22.457972 kern :alert : Register r1 in<8>[ 19.364054] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-11T09:59:22.458285 formation: non-paged memory
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx7d-sdb | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352f8724dca14d8f2e86a7
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7d-sdb.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7d-sdb.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352f8724dca14d8f2e86ae
failing since 36 days (last pass: v6.2-rc1-32-g7ae7deb4a4b4, first fail: v6.3-rc1)
90 lines
2023-04-11T09:59:19.966493 kern :alert : Register r3 information: non-paged memory
2023-04-11T09:59:20.006480 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0e24000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T09:59:20.007001 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T09:59:20.007255 kern :alert : Register r6 information: zero-size pointer
2023-04-11T09:59:20.007492 kern :alert : Register r7 information: slab task_struct start c38ccc80 pointer offset 0 size 2176
2023-04-11T09:59:20.007725 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-11T09:59:20.008200 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-11T09:59:20.049565 kern :alert : Register r10 information: non-slab/vmalloc memory
2023-04-11T09:59:20.050283 kern :alert : Register r11 information: non-slab/vmalloc memory
2023-04-11T09:59:20.050541 kern :alert : Register r12 information: NULL pointer
... (97 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352f8724dca14d8f2e86af
failing since 36 days (last pass: v6.2-rc1-32-g7ae7deb4a4b4, first fail: v6.3-rc1)
48 lines
2023-04-11T09:59:19.963474 kern :alert : 8<--- cut here ---
2023-04-11T09:59:19.963792 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T09:59:19.964295 kern :alert : [c1a50741] *pgd=81a1141e(bad)
2023-04-11T09:59:19.964541 k<8>[ 10.883219] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
2023-04-11T09:59:19.964779 ern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T09:59:19.965010 kern :alert : Register r1 information: non-paged memory
2023-04-11T09:59:19.965236 kern :alert : Register r2 information: non-slab/vmalloc memory
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
imx7ulp-evk | arm | lab-nxp | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352f96916c391aec2e8604
Results: 3 PASS, 3 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7ulp-evk.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-nxp/baseline-imx7ulp-evk.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352f96916c391aec2e860b
failing since 36 days (last pass: v6.2-rc1-23-g93899a4cb7b1, first fail: v6.3-rc1)
90 lines
2023-04-11T09:59:24.163973 -paged memory
2023-04-11T09:59:24.164523 kern :alert : Register r2 information: non-slab/vmalloc memory
2023-04-11T09:59:24.164773 kern :alert : Register r3 information: non-paged memory
2023-04-11T09:59:24.186018 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0bdc000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T09:59:24.186332 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T09:59:24.186832 kern :alert : Register r6 information: zero-size pointer
2023-04-11T09:59:24.187106 kern :alert : Register r7 information: slab task_struct start c232dd80 pointer offset 0 size 2176
2023-04-11T09:59:24.207994 kern :alert : Register r8 information: non-slab/vmalloc memory
2023-04-11T09:59:24.208288 kern :alert : Register r9 information: non-slab/vmalloc memory
2023-04-11T09:59:24.208786 kern :alert : Register r10 information: non-slab/vmalloc memory
... (104 line(s) more)
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352f96916c391aec2e860c
failing since 36 days (last pass: v6.2-rc1-23-g93899a4cb7b1, first fail: v6.3-rc1)
48 lines
2023-04-11T09:59:24.132024 kern :alert : 8<--- cut here ---
2023-04-11T09:59:24.132323 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T09:59:24.132823 kern :alert : [c1a50741] *pgd=61a1141e(bad)
2023-04-11T09:59:24.133065 kern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T09:59:24.142371 kern :alert : Register r1 information: non<8>[ 24.579213] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=48>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
lenovo-TPad-C13-Yoga-zork | x86_64 | lab-collabora | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352ddf4819abe7bf2e85f1
Results: 6 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-lenovo-TPad-C13-Yoga-zork.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-lenovo-TPad-C13-Yoga-zork.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.bootrr.deferred-probe-empty: https://kernelci.org/test/case/id/64352ddf4819abe7bf2e85f6
failing since 3 days (last pass: v6.3-rc1-4-g9ce5f3b3c18e2, first fail: v6.3-rc1-5-gd946c9118047)
2023-04-11T09:52:22.981559 + set +x<8>[ 11.872917] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933835_1.4.2.3.1>
2023-04-11T09:52:22.981641
2023-04-11T09:52:23.086339 / # #
2023-04-11T09:52:23.187340 export SHELL=/bin/sh
2023-04-11T09:52:23.187523 #
2023-04-11T09:52:23.288416 / # export SHELL=/bin/sh. /lava-9933835/environment
2023-04-11T09:52:23.288552
2023-04-11T09:52:23.389447 / # . /lava-9933835/environment/lava-9933835/bin/lava-test-runner /lava-9933835/1
2023-04-11T09:52:23.389728
2023-04-11T09:52:23.394120 / # /lava-9933835/bin/lava-test-runner /lava-9933835/1
... (12 line(s) more)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
mt8183-kukui-...uniper-sku16 | arm64 | lab-collabora | gcc-10 | defconfig+arm64-chromebook | 3
Details: https://kernelci.org/test/plan/id/643531daa685dab5252e8614
Results: 166 PASS, 6 FAIL, 0 SKIP
Full config: defconfig+arm64-chromebook
Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-mt8183-kukui-jacuzzi-juniper-sku16.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/baseline-mt8183-kukui-jacuzzi-juniper-sku16.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/arm64/rootfs.cpio.gz
* baseline.bootrr.panel-edp-probed: https://kernelci.org/test/case/id/643531dba685dab5252e8662
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
2023-04-11T10:09:17.370098 /lava-9934029/1/../bin/lava-test-case
2023-04-11T10:09:17.376584 <8>[ 23.643828] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=panel-edp-probed RESULT=fail>
* baseline.bootrr.clk-mt8183-pericfg-probed: https://kernelci.org/test/case/id/643531dba685dab5252e86bb
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
2023-04-11T10:09:14.505666 /lava-9934029/1/../bin/lava-test-case
2023-04-11T10:09:14.515933 <8>[ 20.780089] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=clk-mt8183-pericfg-probed RESULT=fail>
* baseline.bootrr.clk-mt8183-infracfg-probed: https://kernelci.org/test/case/id/643531dba685dab5252e86bc
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
2023-04-11T10:09:13.459763 <3>[ 19.727295] Bluetooth: hci0: Opcode 0x1002 failed: -110
2023-04-11T10:09:13.466385 <3>[ 19.727474] Bluetooth: hci0: command 0x1002 tx timeout
2023-04-11T10:09:13.478525 /lava-9934029/1/../bin/lava-test-case
2023-04-11T10:09:13.487919 <8>[ 19.751925] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=clk-mt8183-infracfg-probed RESULT=fail>
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
odroid-xu3 | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 1
Details: https://kernelci.org/test/plan/id/64352fc9552f67e7472e85e6
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-odroid-xu3.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-odroid-xu3.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352fc9552f67e7472e85e7
new failure (last pass: v6.3-rc1-6-g14bb09b32f43)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
qemu_x86_64 | x86_64 | lab-broonie | gcc-10 | x86_64_defconfig | 1
Details: https://kernelci.org/test/plan/id/64352decb179bfceb22e861d
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig/gcc-10/lab-broonie/baseline-qemu_x86_64.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig/gcc-10/lab-broonie/baseline-qemu_x86_64.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352decb179bfceb22e861e
failing since 18 days (last pass: v6.3-rc1-2-gdb7df0cfaff3f, first fail: v6.3-rc1-4-g9ce5f3b3c18e2)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
qemu_x86_64 | x86_64 | lab-broonie | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352e4eef02ccbc642e861e
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-broonie/baseline-qemu_x86_64.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-broonie/baseline-qemu_x86_64.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352e4eef02ccbc642e861f
failing since 18 days (last pass: v6.3-rc1-2-gdb7df0cfaff3f, first fail: v6.3-rc1-4-g9ce5f3b3c18e2)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
qemu_x86_64-uefi | x86_64 | lab-broonie | gcc-10 | x86_64_defconfig | 1
Details: https://kernelci.org/test/plan/id/64352d72646ec71e242e85f4
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352d72646ec71e242e85f5
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
qemu_x86_64-uefi | x86_64 | lab-broonie | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352e12f33d96e0062e8600
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352e12f33d96e0062e8601
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
qemu_x86_64-uefi-mixed | x86_64 | lab-broonie | gcc-10 | x86_64_defconfig | 1
Details: https://kernelci.org/test/plan/id/64352dc271df3756572e85eb
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi-mixed.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi-mixed.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352dc271df3756572e85ec
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
qemu_x86_64-uefi-mixed | x86_64 | lab-broonie | gcc-10 | x86_64_defcon...6-chromebook | 1
Details: https://kernelci.org/test/plan/id/64352e3afb8caac2992e8607
Results: 0 PASS, 1 FAIL, 0 SKIP
Full config: x86_64_defconfig+x86-chromebook
Compiler: gcc-10 (gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi-mixed.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-broonie/baseline-qemu_x86_64-uefi-mixed.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/x86/rootfs.cpio.gz
* baseline.login: https://kernelci.org/test/case/id/64352e3afb8caac2992e8608
failing since 36 days (last pass: v6.2-rc1-35-g75a273974d7a, first fail: v6.3-rc1-1-gad79d30ce40d)
platform | arch | lab | compiler | defconfig | regressions
-----------------------------+--------+-----------------+----------+------------------------------+------------
rk3288-rock2-square | arm | lab-collabora | gcc-10 | multi_v7_defconfig | 2
Details: https://kernelci.org/test/plan/id/64352f545094c0f0552e85f6
Results: 10 PASS, 2 FAIL, 1 SKIP
Full config: multi_v7_defconfig
Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110)
Plain log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-rk3288-rock2-square.txt
HTML log: https://storage.kernelci.org//chrome-platform/for-kernelci/v6.3-rc1-7-g419346a03810/arm/multi_v7_defconfig/gcc-10/lab-collabora/baseline-rk3288-rock2-square.html
Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/20230407.0/armel/rootfs.cpio.gz
* baseline.dmesg.emerg: https://kernelci.org/test/case/id/64352f545094c0f0552e8603
new failure (last pass: v6.3-rc1-6-g14bb09b32f43)
30 lines
2023-04-11T09:58:30.546654 kern :alert : Register r2 information: n<8>[ 14.683995] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=emerg RESULT=fail UNITS=lines MEASUREMENT=30>
2023-04-11T09:58:30.547100 on-slab/vmalloc memory
2023-04-11T09:58:30.547446 kern :alert : Register r3 information: <8>[ 14.698953] <LAVA_SIGNAL_ENDRUN 0_dmesg 9933889_1.5.2.4.1>
2023-04-11T09:58:30.547941 non-paged memory
2023-04-11T09:58:30.548256 kern :alert : Register r4 information: 2-page vmalloc region starting at 0xf0d44000 allocated at kernel_clone+0x8c/0x36c
2023-04-11T09:58:30.548563 kern :alert : Register r5 information: non-slab/vmalloc memory
2023-04-11T09:58:30.548847 kern :alert : Register r6 information: zero-size pointer
* baseline.dmesg.alert: https://kernelci.org/test/case/id/64352f545094c0f0552e8604
new failure (last pass: v6.3-rc1-6-g14bb09b32f43)
16 lines
2023-04-11T09:58:30.498076 kern :alert : 8<--- cut here ---
2023-04-11T09:58:30.498515 kern :alert : Unhandled fault: alignment exception (0x001) at 0xc1a50741
2023-04-11T09:58:30.498770 kern :alert : [c1<8>[ 14.654594] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=alert RESULT=fail UNITS=lines MEASUREMENT=16>
2023-04-11T09:58:30.498975 a50741] *pgd=01a1141e(bad)
2023-04-11T09:58:30.499173 kern :alert : Register r0 information: non-slab/vmalloc memory
2023-04-11T09:58:30.499381 kern :alert : Register r1 information: non-paged memory
^ permalink raw reply
* chrome-platform/for-kernelci build: 5 builds: 0 failed, 5 passed (v6.3-rc1-7-g419346a03810)
From: kernelci.org bot @ 2023-04-11 10:06 UTC (permalink / raw)
To: kernel-build-reports, kernelci-results, chrome-platform,
eballetbo, bleung, groeck, pmalani
chrome-platform/for-kernelci build: 5 builds: 0 failed, 5 passed (v6.3-rc1-7-g419346a03810)
Full Build Summary: https://kernelci.org/build/chrome-platform/branch/for-kernelci/kernel/v6.3-rc1-7-g419346a03810/
Tree: chrome-platform
Branch: for-kernelci
Git Describe: v6.3-rc1-7-g419346a03810
Git Commit: 419346a0381034fcc0866be9605108c8612847de
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
Built: 3 unique architectures
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
defconfig (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig+x86-chromebook (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH] platform/chrome: cros_ec_debugfs: fix kernel-doc warning
From: patchwork-bot+chrome-platform @ 2023-04-11 8:40 UTC (permalink / raw)
To: Tzung-Bi Shih; +Cc: bleung, groeck, chrome-platform, robbarnes, lkp
In-Reply-To: <20230411053308.1572493-1-tzungbi@kernel.org>
Hello:
This patch was applied to chrome-platform/linux.git (for-kernelci)
by Tzung-Bi Shih <tzungbi@kernel.org>:
On Tue, 11 Apr 2023 13:33:08 +0800 you wrote:
> Fix the following kernel-doc warning:
>
> $ ./scripts/kernel-doc -none drivers/platform/chrome/*
> [...]
> warning: This comment starts with '/**', but isn't a kernel-doc comment.
>
> Fixes: 14bb09b32f43 ("platform/chrome: cros_ec: Separate logic for getting panic info")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
>
> [...]
Here is the summary with links:
- platform/chrome: cros_ec_debugfs: fix kernel-doc warning
https://git.kernel.org/chrome-platform/c/419346a03810
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox