Message ID | 5cec74e8.1c69fb81.37335.9d7b@mx.google.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Delegated to: | Eduardo Valentin |
Headers | show |
Series | linusw/for-next boot bisection: v5.2-rc1-8-g73a790c68d7e on rk3288-veyron-jaq | expand |
Hi Linus, On 28/05/2019 00:38, kernelci.org bot wrote: > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * This automated bisection report was sent to you on the basis * > * that you may be involved with the breaking commit it has * > * found. No manual investigation has been done to verify it, * > * and the root cause of the problem may be somewhere else. * > * Hope this helps! * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > linusw/for-next boot bisection: v5.2-rc1-8-g73a790c68d7e on rk3288-veyron-jaq > > Summary: > Start: 73a790c68d7e Merge branch 'devel' into for-next > Details: https://kernelci.org/boot/id/5cebf03d59b514dd627a3629 > Plain log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.txt > HTML log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.html > Result: 28694e009e51 thermal: rockchip: fix up the tsadc pinctrl setting error > > Checks: > revert: PASS > verify: PASS > > Parameters: > Tree: linusw > URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/ > Branch: for-next > Target: rk3288-veyron-jaq > CPU arch: arm > Lab: lab-collabora > Compiler: gcc-8 > Config: multi_v7_defconfig > Test suite: boot > > Breaking commit found: > > ------------------------------------------------------------------------------- > commit 28694e009e512451ead5519dd801f9869acb1f60 > Author: Elaine Zhang <zhangqing@rock-chips.com> > Date: Tue Apr 30 18:09:44 2019 +0800 > > thermal: rockchip: fix up the tsadc pinctrl setting error This commit has now been reverted in mainline. Would it be OK for you to rebase your for-next branch on v5.2-rc2 or cherry-pick the revert to avoid recurring bisections? Ideally this should have been fixed or reverted in mainline before v5.2-rc1 was released, or even earlier when this was first found in -next on 13th May. Unfortunately it was overlooked and then spread to other branches like yours. Thanks, Guillaume
Hi Guillaume, On Tue, May 28, 2019 at 9:13 AM Guillaume Tucker <guillaume.tucker@collabora.com> wrote: > On 28/05/2019 00:38, kernelci.org bot wrote: > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * This automated bisection report was sent to you on the basis * > > * that you may be involved with the breaking commit it has * > > * found. No manual investigation has been done to verify it, * > > * and the root cause of the problem may be somewhere else. * > > * Hope this helps! * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > > linusw/for-next boot bisection: v5.2-rc1-8-g73a790c68d7e on rk3288-veyron-jaq > > > > Summary: > > Start: 73a790c68d7e Merge branch 'devel' into for-next > > Details: https://kernelci.org/boot/id/5cebf03d59b514dd627a3629 > > Plain log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.txt > > HTML log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.html > > Result: 28694e009e51 thermal: rockchip: fix up the tsadc pinctrl setting error > > > > Checks: > > revert: PASS > > verify: PASS > > > > Parameters: > > Tree: linusw > > URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/ > > Branch: for-next > > Target: rk3288-veyron-jaq > > CPU arch: arm > > Lab: lab-collabora > > Compiler: gcc-8 > > Config: multi_v7_defconfig > > Test suite: boot > > > > Breaking commit found: > > > > ------------------------------------------------------------------------------- > > commit 28694e009e512451ead5519dd801f9869acb1f60 > > Author: Elaine Zhang <zhangqing@rock-chips.com> > > Date: Tue Apr 30 18:09:44 2019 +0800 > > > > thermal: rockchip: fix up the tsadc pinctrl setting error > > This commit has now been reverted in mainline. Would it be OK > for you to rebase your for-next branch on v5.2-rc2 or cherry-pick > the revert to avoid recurring bisections? > > Ideally this should have been fixed or reverted in mainline > before v5.2-rc1 was released, or even earlier when this was first > found in -next on 13th May. Unfortunately it was overlooked and > then spread to other branches like yours. I'm afraid it's gonna spread to even more for-next branches, as most subsystem maintainers base their for-next branch on the previous rc1 release. Typically maintainers do not rebase their for-next branches, and do not cherry-pick fixes, unless they are critical for their subsystem. So you can expect this to show up in e.g. the m68k for-next branch soon... Can't you mark this as a known issue, to prevent spending cycles on the same bisection, and sending out more bisection reports for the same issue? Thanks! Gr{oetje,eeting}s, Geert
On Tue, May 28, 2019 at 9:13 AM Guillaume Tucker <guillaume.tucker@collabora.com> wrote: > This commit has now been reverted in mainline. Would it be OK > for you to rebase your for-next branch on v5.2-rc2 or cherry-pick > the revert to avoid recurring bisections? Sure I can do that, it's a one-off so why not. I rebased my devel branch on -rc2. > Ideally this should have been fixed or reverted in mainline > before v5.2-rc1 was released, or even earlier when this was first > found in -next on 13th May. Unfortunately it was overlooked and > then spread to other branches like yours. Usually what we would want for development trees is to ignore any errors coming from a commit on a release candidate branch, like -rcN, as it is not directly under our control. Yours, Linus Walleij
Hi Geert, On 28/05/2019 08:45, Geert Uytterhoeven wrote: > Hi Guillaume, > > On Tue, May 28, 2019 at 9:13 AM Guillaume Tucker > <guillaume.tucker@collabora.com> wrote: >> On 28/05/2019 00:38, kernelci.org bot wrote: >>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >>> * This automated bisection report was sent to you on the basis * >>> * that you may be involved with the breaking commit it has * >>> * found. No manual investigation has been done to verify it, * >>> * and the root cause of the problem may be somewhere else. * >>> * Hope this helps! * >>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >>> >>> linusw/for-next boot bisection: v5.2-rc1-8-g73a790c68d7e on rk3288-veyron-jaq >>> >>> Summary: >>> Start: 73a790c68d7e Merge branch 'devel' into for-next >>> Details: https://kernelci.org/boot/id/5cebf03d59b514dd627a3629 >>> Plain log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.txt >>> HTML log: https://storage.kernelci.org//linusw/for-next/v5.2-rc1-8-g73a790c68d7e/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-rk3288-veyron-jaq.html >>> Result: 28694e009e51 thermal: rockchip: fix up the tsadc pinctrl setting error >>> >>> Checks: >>> revert: PASS >>> verify: PASS >>> >>> Parameters: >>> Tree: linusw >>> URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/ >>> Branch: for-next >>> Target: rk3288-veyron-jaq >>> CPU arch: arm >>> Lab: lab-collabora >>> Compiler: gcc-8 >>> Config: multi_v7_defconfig >>> Test suite: boot >>> >>> Breaking commit found: >>> >>> ------------------------------------------------------------------------------- >>> commit 28694e009e512451ead5519dd801f9869acb1f60 >>> Author: Elaine Zhang <zhangqing@rock-chips.com> >>> Date: Tue Apr 30 18:09:44 2019 +0800 >>> >>> thermal: rockchip: fix up the tsadc pinctrl setting error >> >> This commit has now been reverted in mainline. Would it be OK >> for you to rebase your for-next branch on v5.2-rc2 or cherry-pick >> the revert to avoid recurring bisections? >> >> Ideally this should have been fixed or reverted in mainline >> before v5.2-rc1 was released, or even earlier when this was first >> found in -next on 13th May. Unfortunately it was overlooked and >> then spread to other branches like yours. > > I'm afraid it's gonna spread to even more for-next branches, as most > subsystem maintainers base their for-next branch on the previous rc1 > release. Typically maintainers do not rebase their for-next branches, > and do not cherry-pick fixes, unless they are critical for their > subsystem. So you can expect this to show up in e.g. the m68k for-next > branch soon... That is what I feared, thanks for confirming. > Can't you mark this as a known issue, to prevent spending cycles on the > same bisection, and sending out more bisection reports for the same > issue? Not really, so I've disabled bisections in the linux-gpio tree and a few other maintainers' trees for now. I'll see if we can come up with a more systematic way of suppressing bisections in similar cases (i.e. the issue has been fixed in mainline later than the base commit for the branch being tested). Thanks, Guillaume
Hi Guillaume, On Tue, May 28, 2019 at 10:36 AM Guillaume Tucker <guillaume.tucker@collabora.com> wrote: > On 28/05/2019 08:45, Geert Uytterhoeven wrote: > > On Tue, May 28, 2019 at 9:13 AM Guillaume Tucker > > <guillaume.tucker@collabora.com> wrote: > >> This commit has now been reverted in mainline. Would it be OK > >> for you to rebase your for-next branch on v5.2-rc2 or cherry-pick > >> the revert to avoid recurring bisections? > >> > >> Ideally this should have been fixed or reverted in mainline > >> before v5.2-rc1 was released, or even earlier when this was first > >> found in -next on 13th May. Unfortunately it was overlooked and > >> then spread to other branches like yours. > > > > I'm afraid it's gonna spread to even more for-next branches, as most > > subsystem maintainers base their for-next branch on the previous rc1 > > release. Typically maintainers do not rebase their for-next branches, > > and do not cherry-pick fixes, unless they are critical for their > > subsystem. So you can expect this to show up in e.g. the m68k for-next > > branch soon... > > That is what I feared, thanks for confirming. > > > Can't you mark this as a known issue, to prevent spending cycles on the > > same bisection, and sending out more bisection reports for the same > > issue? > > Not really, so I've disabled bisections in the linux-gpio tree > and a few other maintainers' trees for now. I'll see if we can > come up with a more systematic way of suppressing bisections in > similar cases (i.e. the issue has been fixed in mainline later > than the base commit for the branch being tested). Having a systematic way would be good, else you will have to disable most other maintainers' trees soon, severely limiting test coverage, or fall back to linux-next testing only, as linux-next will always include\ latest mainline. Thanks! Gr{oetje,eeting}s, Geert
On Tue, May 28, 2019 at 10:36 AM Guillaume Tucker <guillaume.tucker@collabora.com> wrote: > > Can't you mark this as a known issue, to prevent spending cycles on the > > same bisection, and sending out more bisection reports for the same > > issue? > > Not really, so I've disabled bisections in the linux-gpio tree > and a few other maintainers' trees for now. I'll see if we can > come up with a more systematic way of suppressing bisections in > similar cases (i.e. the issue has been fixed in mainline later > than the base commit for the branch being tested). I think this is what the zeroday autobuilder does because they never seem to show this problem. Thanks for looking into it! Yours, Linus Walleij
On Tue, May 28, 2019 at 10:45:13AM +0200, Linus Walleij wrote: > On Tue, May 28, 2019 at 10:36 AM Guillaume Tucker > > Not really, so I've disabled bisections in the linux-gpio tree > > and a few other maintainers' trees for now. I'll see if we can > > come up with a more systematic way of suppressing bisections in > > similar cases (i.e. the issue has been fixed in mainline later > > than the base commit for the branch being tested). > I think this is what the zeroday autobuilder does because > they never seem to show this problem. Thanks for looking > into it! I've got a feeling they do this by deduping after doing the bisection; they also used to have a system where they'd merge a bunch of trees together and do the bisect on that to save repeating bisects.
diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index 9c7643d62ed7..6dc7fc516abf 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -172,6 +172,9 @@ struct rockchip_thermal_data { int tshut_temp; enum tshut_mode tshut_mode; enum tshut_polarity tshut_polarity; + struct pinctrl *pinctrl; + struct pinctrl_state *gpio_state; + struct pinctrl_state *otp_state; }; /** @@ -1242,6 +1245,8 @@ static int rockchip_thermal_probe(struct platform_device *pdev) return error; } + thermal->chip->control(thermal->regs, false); + error = clk_prepare_enable(thermal->clk); if (error) { dev_err(&pdev->dev, "failed to enable converter clock: %d\n", @@ -1267,6 +1272,30 @@ static int rockchip_thermal_probe(struct platform_device *pdev) thermal->chip->initialize(thermal->grf, thermal->regs, thermal->tshut_polarity); + if (thermal->tshut_mode == TSHUT_MODE_GPIO) { + thermal->pinctrl = devm_pinctrl_get(&pdev->dev); + if (IS_ERR(thermal->pinctrl)) { + dev_err(&pdev->dev, "failed to find thermal pinctrl\n"); + return PTR_ERR(thermal->pinctrl); + } + + thermal->gpio_state = pinctrl_lookup_state(thermal->pinctrl, + "gpio"); + if (IS_ERR_OR_NULL(thermal->gpio_state)) { + dev_err(&pdev->dev, "failed to find thermal gpio state\n"); + return -EINVAL; + } + + thermal->otp_state = pinctrl_lookup_state(thermal->pinctrl, + "otpout"); + if (IS_ERR_OR_NULL(thermal->otp_state)) { + dev_err(&pdev->dev, "failed to find thermal otpout state\n"); + return -EINVAL; + } + + pinctrl_select_state(thermal->pinctrl, thermal->otp_state); + } + for (i = 0; i < thermal->chip->chn_num; i++) { error = rockchip_thermal_register_sensor(pdev, thermal, &thermal->sensors[i], @@ -1337,8 +1366,8 @@ static int __maybe_unused rockchip_thermal_suspend(struct device *dev) clk_disable(thermal->pclk); clk_disable(thermal->clk); - - pinctrl_pm_select_sleep_state(dev); + if (thermal->tshut_mode == TSHUT_MODE_GPIO) + pinctrl_select_state(thermal->pinctrl, thermal->gpio_state); return 0; } @@ -1383,7 +1412,8 @@ static int __maybe_unused rockchip_thermal_resume(struct device *dev) for (i = 0; i < thermal->chip->chn_num; i++) rockchip_thermal_toggle_sensor(&thermal->sensors[i], true); - pinctrl_pm_select_default_state(dev); + if (thermal->tshut_mode == TSHUT_MODE_GPIO) + pinctrl_select_state(thermal->pinctrl, thermal->otp_state); return 0; }