Hi Linus,
Please see the bisection report below about a boot failure, it looks legit as this commit was made today:
commit 5f9277249f9b126f815e23c3078cff3b69ce2715 Author: Linus Walleij linus.walleij@linaro.org AuthorDate: Mon Oct 1 22:43:46 2018 +0200 Commit: Greg Kroah-Hartman gregkh@linuxfoundation.org CommitDate: Fri Jan 24 10:27:24 2020 +0100
regulator: fixed: Default enable high on DT regulators
[ Upstream commit 28be5f15df2ee6882b0a122693159c96a28203c7 ]
KernelCI bisection reports are not publicly sent at the moment while we're trialing some new bisection features.
Thanks, Guillaume
On 24/01/2020 11:47, 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. *
*- If you do send a fix, please include this trailer: *
- Reported-by: "kernelci.org bot" bot@kernelci.org *
*- Hope this helps! *
stable-rc/linux-4.19.y bisection: baseline.login on sun8i-h3-libretech-all-h3-cc
Summary: Start: be6fe2fc68d0 Linux 4.19.99-rc1 Plain log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.98-640-gbe6fe2fc6... HTML log: https://storage.kernelci.org//stable-rc/linux-4.19.y/v4.19.98-640-gbe6fe2fc6... Result: 250d67d6bc05 regulator: fixed: Default enable high on DT regulators
Checks: revert: PASS verify: PASS
Parameters: Tree: stable-rc URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-4.19.y Target: sun8i-h3-libretech-all-h3-cc CPU arch: arm Lab: lab-baylibre Compiler: gcc-8 Config: sunxi_defconfig Test case: baseline.login
Breaking commit found:
commit 250d67d6bc0597c0c0de47b3ea32dc6d4e3f9322 Author: Linus Walleij linus.walleij@linaro.org Date: Mon Oct 1 22:43:46 2018 +0200
regulator: fixed: Default enable high on DT regulators[ Upstream commit 28be5f15df2ee6882b0a122693159c96a28203c7 ] commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") switched to use gpiod_get() to look up the regulator from the gpiolib core whether that is device tree or boardfile. This meant that we activate the code in a603a2b8d86e ("gpio: of: Add special quirk to parse regulator flags") which means the descriptors coming from the device tree already have the right inversion and open drain semantics set up from the gpiolib core. As the fixed regulator was inspected again we got the inverted inversion and things broke. Fix it by ignoring the config in the device tree for now: the later patches in the series will push all inversion handling over to the gpiolib core and set it up properly in the boardfiles for legacy devices, but I did not finish that for this kernel cycle. Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Leonard Crestez leonard.crestez@nxp.com Reported-by: Fabio Estevam festevam@gmail.com Reported-by: John Stultz john.stultz@linaro.org Reported-by: Anders Roxell anders.roxell@linaro.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Tested-by: John Stultz john.stultz@linaro.org Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c index 988a7472c2ab..d68ff65a5adc 100644 --- a/drivers/regulator/fixed.c +++ b/drivers/regulator/fixed.c @@ -84,9 +84,14 @@ of_get_fixed_voltage_config(struct device *dev, of_property_read_u32(np, "startup-delay-us", &config->startup_delay);
- config->enable_high = of_property_read_bool(np, "enable-active-high");
- config->gpio_is_open_drain = of_property_read_bool(np,
"gpio-open-drain");
- /*
* FIXME: we pulled active low/high and open drain handling into* gpiolib so it will be handled there. Delete this in the second* step when we also remove the custom inversion handling for all* legacy boardfiles.*/- config->enable_high = 1;
- config->gpio_is_open_drain = 0;
if (of_find_property(np, "vin-supply", NULL)) config->input_supply = "vin";
Git bisection log:
git bisect start # good: [d183c8e2647a7d45202c14a33631f6c09020f8ac] Linux 4.19.98 git bisect good d183c8e2647a7d45202c14a33631f6c09020f8ac # bad: [be6fe2fc68d0d7571c06b5fc11d2282a6544ec0f] Linux 4.19.99-rc1 git bisect bad be6fe2fc68d0d7571c06b5fc11d2282a6544ec0f # bad: [62715658388c5d59c35c4f7fdcffbc8e8772f39e] ARM: dts: ls1021: Fix SGMII PCS link remaining down after PHY disconnect git bisect bad 62715658388c5d59c35c4f7fdcffbc8e8772f39e # bad: [2d2f9b317958a34ebecf731ac7510c649a2ab33c] driver core: Do not resume suppliers under device_links_write_lock() git bisect bad 2d2f9b317958a34ebecf731ac7510c649a2ab33c # bad: [83ab4275fc5a25992200a394c692542ad8584276] mailbox: ti-msgmgr: Off by one in ti_msgmgr_of_xlate() git bisect bad 83ab4275fc5a25992200a394c692542ad8584276 # good: [864d924463eb890af4ea92cbb4108ebcba42bd6c] usb: gadget: fsl_udc_core: check allocation return value and cleanup on failure git bisect good 864d924463eb890af4ea92cbb4108ebcba42bd6c # bad: [51ee3169bec81a0f48bdb0a7402bfa1d863d6006] mlxsw: reg: QEEC: Add minimum shaper fields git bisect bad 51ee3169bec81a0f48bdb0a7402bfa1d863d6006 # bad: [bf4a2476e727c5a302c40a0e66e1702c2c135b7c] pwm: lpss: Release runtime-pm reference from the driver's remove callback git bisect bad bf4a2476e727c5a302c40a0e66e1702c2c135b7c # bad: [d54e7094b7bd73384d64cc328a0c979522e3cb67] of: Fix property name in of_node_get_device_type git bisect bad d54e7094b7bd73384d64cc328a0c979522e3cb67 # bad: [250d67d6bc0597c0c0de47b3ea32dc6d4e3f9322] regulator: fixed: Default enable high on DT regulators git bisect bad 250d67d6bc0597c0c0de47b3ea32dc6d4e3f9322 # good: [9b2060c15a1b2524fb4ac3f3cc2cf5dcbc293955] cfg80211: regulatory: make initialization more robust git bisect good 9b2060c15a1b2524fb4ac3f3cc2cf5dcbc293955
# first bad commit: [250d67d6bc0597c0c0de47b3ea32dc6d4e3f9322] regulator: fixed: Default enable high on DT regulators
On Fri, Jan 24, 2020 at 12:58:32PM +0000, Guillaume Tucker wrote:
Please see the bisection report below about a boot failure, it looks legit as this commit was made today:
Fix it by ignoring the config in the device tree for now: the later patches in the series will push all inversion handling over to the gpiolib core and set it up properly in the boardfiles for legacy devices, but I did not finish that for this kernel cycle.Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Leonard Crestez leonard.crestez@nxp.com Reported-by: Fabio Estevam festevam@gmail.com Reported-by: John Stultz john.stultz@linaro.org Reported-by: Anders Roxell anders.roxell@linaro.org Signed-off-by: Linus Walleij linus.walleij@linaro.org Tested-by: John Stultz john.stultz@linaro.org Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
Oh dear, this is another bot backported commit which I suspect is lacking some context or other from all the other work that was done with GPIO enables :(
On Fri, Jan 24, 2020 at 2:18 PM Mark Brown broonie@kernel.org wrote:
On Fri, Jan 24, 2020 at 12:58:32PM +0000, Guillaume Tucker wrote:
Please see the bisection report below about a boot failure, it looks legit as this commit was made today:
Fix it by ignoring the config in the device tree for now: the later patches in the series will push all inversion handling over to the gpiolib core and set it up properly in the boardfiles for legacy devices, but I did not finish that for this kernel cycle.
So here the patch clearly says it is for "this kernel cycle" which I feel implies that it is NOT for any previous kernels stable or not...
I'm sorry if I missed the "look at this thing that we will apply to stable soon" mail, sadly there are just too many of these for me to handle sometimes. (Maybe it means I am making too many mistakes to begin with, mea culpa.)
Reported-by: Leonard Crestez <leonard.crestez@nxp.com> Reported-by: Fabio Estevam <festevam@gmail.com> Reported-by: John Stultz <john.stultz@linaro.org> Reported-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>Oh dear, this is another bot backported commit which I suspect is lacking some context or other from all the other work that was done with GPIO enables :(
This AI seems a bit confused :/ Maybe it is the prolific use of the word "fix" that triggers it?
Yours, Linus Walleij
On Fri, Jan 24, 2020 at 02:44:19PM +0100, Linus Walleij wrote:
On Fri, Jan 24, 2020 at 2:18 PM Mark Brown broonie@kernel.org wrote:
On Fri, Jan 24, 2020 at 12:58:32PM +0000, Guillaume Tucker wrote:
Please see the bisection report below about a boot failure, it looks legit as this commit was made today:
Fix it by ignoring the config in the device tree for now: the later patches in the series will push all inversion handling over to the gpiolib core and set it up properly in the boardfiles for legacy devices, but I did not finish that for this kernel cycle.So here the patch clearly says it is for "this kernel cycle" which I feel implies that it is NOT for any previous kernels stable or not...
This read to me as if this patch plasters the issue for now, and a proper fix will follow in the next cycle.
I'm sorry if I missed the "look at this thing that we will apply to stable soon" mail, sadly there are just too many of these for me to handle sometimes. (Maybe it means I am making too many mistakes to begin with, mea culpa.)
Reported-by: Leonard Crestez <leonard.crestez@nxp.com> Reported-by: Fabio Estevam <festevam@gmail.com> Reported-by: John Stultz <john.stultz@linaro.org> Reported-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>Oh dear, this is another bot backported commit which I suspect is lacking some context or other from all the other work that was done with GPIO enables :(
This AI seems a bit confused :/ Maybe it is the prolific use of the word "fix" that triggers it?
Right, it's a combo of a few things: one of them is indeed the work "fix", but few others are the Reported-by tags, the simplicity of the commit, and so on.
I'll drop this patch, sorry about this.
linux-stable-mirror@lists.linaro.org
-
Guillaume Tucker -
Linus Walleij -
Mark Brown -
Sasha Levin