- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] regulator: defer probe when trying to get voltage from" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From cf1ad559a20d1930aa7b47a52f54e1f8718de301 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux(a)rere.qmqm.pl> Date: Mon, 2 Nov 2020 22:27:27 +0100 Subject: [PATCH] regulator: defer probe when trying to get voltage from unresolved supply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable(a)vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Reported-by: Ondřej Jirman <megous(a)megous.com> Reported-by: Corentin Labbe <clabbe.montjoie(a)gmail.com> Tested-by: Ondřej Jirman <megous(a)megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.16043519… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index a4ffd71696da..a5ad553da8cd 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4165,6 +4165,8 @@ int regulator_get_voltage_rdev(struct regulator_dev *rdev) ret = rdev->desc->fixed_uV; } else if (rdev->supply) { ret = regulator_get_voltage_rdev(rdev->supply->rdev); + } else if (rdev->supply_name) { + return -EPROBE_DEFER; } else { return -EINVAL; }

4 years, 11 months

1
0
0 0

FAILED: patch "[PATCH] regulator: defer probe when trying to get voltage from" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From cf1ad559a20d1930aa7b47a52f54e1f8718de301 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux(a)rere.qmqm.pl> Date: Mon, 2 Nov 2020 22:27:27 +0100 Subject: [PATCH] regulator: defer probe when trying to get voltage from unresolved supply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable(a)vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Reported-by: Ondřej Jirman <megous(a)megous.com> Reported-by: Corentin Labbe <clabbe.montjoie(a)gmail.com> Tested-by: Ondřej Jirman <megous(a)megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.16043519… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index a4ffd71696da..a5ad553da8cd 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4165,6 +4165,8 @@ int regulator_get_voltage_rdev(struct regulator_dev *rdev) ret = rdev->desc->fixed_uV; } else if (rdev->supply) { ret = regulator_get_voltage_rdev(rdev->supply->rdev); + } else if (rdev->supply_name) { + return -EPROBE_DEFER; } else { return -EINVAL; }

4 years, 11 months

1
0
0 0

FAILED: patch "[PATCH] regulator: defer probe when trying to get voltage from" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From cf1ad559a20d1930aa7b47a52f54e1f8718de301 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux(a)rere.qmqm.pl> Date: Mon, 2 Nov 2020 22:27:27 +0100 Subject: [PATCH] regulator: defer probe when trying to get voltage from unresolved supply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable(a)vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Reported-by: Ondřej Jirman <megous(a)megous.com> Reported-by: Corentin Labbe <clabbe.montjoie(a)gmail.com> Tested-by: Ondřej Jirman <megous(a)megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.16043519… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index a4ffd71696da..a5ad553da8cd 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4165,6 +4165,8 @@ int regulator_get_voltage_rdev(struct regulator_dev *rdev) ret = rdev->desc->fixed_uV; } else if (rdev->supply) { ret = regulator_get_voltage_rdev(rdev->supply->rdev); + } else if (rdev->supply_name) { + return -EPROBE_DEFER; } else { return -EINVAL; }

4 years, 11 months

1
0
0 0

[PATCH] iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used

by Paul Cercueil

When the command feature of the ADC is used, it is possible to program the ADC, and specify at each step what input should be processed, and in comparison to what reference. This broke the AUX and battery readings when the touchscreen was enabled, most likely because the CMD feature would change the VREF all the time. Now, when AUX or battery are read, we temporarily disable the CMD feature, which means that we won't get touchscreen readings in that time frame. But it now gives correct values for AUX / battery, and the touchscreen isn't disabled for long enough to be an actual issue. Fixes: b96952f498db ("IIO: Ingenic JZ47xx: Add touchscreen mode.") Cc: <stable(a)vger.kernel.org> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/iio/adc/ingenic-adc.c | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c index 92b25083e23f..ecaff6a9b716 100644 --- a/drivers/iio/adc/ingenic-adc.c +++ b/drivers/iio/adc/ingenic-adc.c @@ -177,13 +177,12 @@ static void ingenic_adc_set_config(struct ingenic_adc *adc, mutex_unlock(&adc->lock); } -static void ingenic_adc_enable(struct ingenic_adc *adc, - int engine, - bool enabled) +static void ingenic_adc_enable_unlocked(struct ingenic_adc *adc, + int engine, + bool enabled) { u8 val; - mutex_lock(&adc->lock); val = readb(adc->base + JZ_ADC_REG_ENABLE); if (enabled) @@ -192,20 +191,42 @@ static void ingenic_adc_enable(struct ingenic_adc *adc, val &= ~BIT(engine); writeb(val, adc->base + JZ_ADC_REG_ENABLE); +} + +static void ingenic_adc_enable(struct ingenic_adc *adc, + int engine, + bool enabled) +{ + mutex_lock(&adc->lock); + ingenic_adc_enable_unlocked(adc, engine, enabled); mutex_unlock(&adc->lock); } static int ingenic_adc_capture(struct ingenic_adc *adc, int engine) { + u32 cfg; u8 val; int ret; - ingenic_adc_enable(adc, engine, true); + /* + * Disable CMD_SEL temporarily, because it causes wrong VBAT readings, + * probably due to the switch of VREF. We must keep the lock here to + * avoid races with the buffer enable/disable functions. + */ + mutex_lock(&adc->lock); + cfg = readl(adc->base + JZ_ADC_REG_CFG); + writel(cfg & ~JZ_ADC_REG_CFG_CMD_SEL, adc->base + JZ_ADC_REG_CFG); + + + ingenic_adc_enable_unlocked(adc, engine, true); ret = readb_poll_timeout(adc->base + JZ_ADC_REG_ENABLE, val, !(val & BIT(engine)), 250, 1000); if (ret) - ingenic_adc_enable(adc, engine, false); + ingenic_adc_enable_unlocked(adc, engine, false); + + writel(cfg, adc->base + JZ_ADC_REG_CFG); + mutex_unlock(&adc->lock); return ret; } -- 2.28.0

4 years, 11 months

3
2
0 0

[PATCH] iio/adc: ingenic: Fix battery VREF for JZ4770 SoC

by Paul Cercueil

The reference voltage for the battery is clearly marked as 1.2V in the programming manual. With this fixed, the battery channel now returns correct values. Fixes: a515d6488505 ("IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.") Cc: <stable(a)vger.kernel.org> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/iio/adc/ingenic-adc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c index ecaff6a9b716..19b95905a45c 100644 --- a/drivers/iio/adc/ingenic-adc.c +++ b/drivers/iio/adc/ingenic-adc.c @@ -71,7 +71,7 @@ #define JZ4725B_ADC_BATTERY_HIGH_VREF_BITS 10 #define JZ4740_ADC_BATTERY_HIGH_VREF (7500 * 0.986) #define JZ4740_ADC_BATTERY_HIGH_VREF_BITS 12 -#define JZ4770_ADC_BATTERY_VREF 6600 +#define JZ4770_ADC_BATTERY_VREF 1200 #define JZ4770_ADC_BATTERY_VREF_BITS 12 #define JZ_ADC_IRQ_AUX BIT(0) -- 2.28.0

4 years, 11 months

3
4
0 0

Please consider reverting commit bb1860efc817 ("coresight: Make sysfs functional...") from v5.4.y

by Guenter Roeck

Hi, I get the following build warning in v5.4.75. drivers/hwtracing/coresight/coresight-etm-perf.c: In function 'etm_setup_aux': drivers/hwtracing/coresight/coresight-etm-perf.c:226:37: warning: passing argument 1 of 'coresight_get_enabled_sink' makes pointer from integer without a cast Actually, the warning is fatal, since the call is sink = coresight_get_enabled_sink(true); However, the argument to coresight_get_enabled_sink() is now a pointer. The parameter change was introduced with commit 8fd52a21ab57 ("coresight: Make sysfs functional on topologies with per core sink"). In the upstream kernel, the call is removed with commit bb1860efc817 ("coresight: etm: perf: Sink selection using sysfs is deprecated"). That commit alone would, however, likely not solve the problem. It looks like at least two more commits would be needed. 716f5652a131 coresight: etm: perf: Fix warning caused by etm_setup_aux failure 8e264c52e1da coresight: core: Allow the coresight core driver to be built as a module 39a7661dcf65 coresight: Fix uninitialised pointer bug in etm_setup_aux() Looking into the coresight code, I see several additional commits affecting the sysfs interface since v5.4. I have no idea what would actually be needed for stable code in v5.4.y, short of applying them all. With all this in mind, I would suggest to revert commit 8fd52a21ab57 ("coresight: Make sysfs functional on topologies with per core sink") from v5.4.y, especially since it is not marked as bug fix or for stable. Thanks, Guenter

4 years, 11 months

2
1
0 0

[PATCH AUTOSEL 5.4 01/24] ARM: dts: sun4i-a10: fix cpu_alert temperature

by Sasha Levin

From: Clément Péron <peron.clem(a)gmail.com> [ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ] When running dtbs_check thermal_zone warn about the temperature declared. thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000 It's indeed wrong the real value is 85°C and not 850°C. Signed-off-by: Clément Péron <peron.clem(a)gmail.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/boot/dts/sun4i-a10.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi index e0a9b371c248f..2265ca24c0c71 100644 --- a/arch/arm/boot/dts/sun4i-a10.dtsi +++ b/arch/arm/boot/dts/sun4i-a10.dtsi @@ -143,7 +143,7 @@ map0 { trips { cpu_alert0: cpu-alert0 { /* milliCelsius */ - temperature = <850000>; + temperature = <85000>; hysteresis = <2000>; type = "passive"; }; -- 2.27.0

4 years, 11 months

3
27
0 0

[PATCH AUTOSEL 5.9 01/35] ARM: dts: sun4i-a10: fix cpu_alert temperature

by Sasha Levin

From: Clément Péron <peron.clem(a)gmail.com> [ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ] When running dtbs_check thermal_zone warn about the temperature declared. thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000 It's indeed wrong the real value is 85°C and not 850°C. Signed-off-by: Clément Péron <peron.clem(a)gmail.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/boot/dts/sun4i-a10.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi index 0f95a6ef8543a..1c5a666c54b53 100644 --- a/arch/arm/boot/dts/sun4i-a10.dtsi +++ b/arch/arm/boot/dts/sun4i-a10.dtsi @@ -143,7 +143,7 @@ map0 { trips { cpu_alert0: cpu-alert0 { /* milliCelsius */ - temperature = <850000>; + temperature = <85000>; hysteresis = <2000>; type = "passive"; }; -- 2.27.0

4 years, 11 months

2
38
0 0

stable-rc/linux-5.4.y baseline: 205 runs, 1 regressions (v5.4.75-35-g1ee437936e22)

by kernelci.org bot

stable-rc/linux-5.4.y baseline: 205 runs, 1 regressions (v5.4.75-35-g1ee437936e22) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------+------+--------------+----------+--------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.75-3… Test: baseline Tree: stable-rc Branch: linux-5.4.y Describe: v5.4.75-35-g1ee437936e22 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 1ee437936e224a0e6b85ee87e14a1dd3b2d92f8b Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------+------+--------------+----------+--------------------+------------ beagle-xm | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa726331af77dc70fdb8864 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.75-35-g1ee437936e2… HTML log: https://storage.kernelci.org//stable-rc/linux-5.4.y/v5.4.75-35-g1ee437936e2… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa726331af77dc70fdb8865 new failure (last pass: v5.4.75)

4 years, 11 months

1
0
0 0

stable-rc/linux-4.9.y baseline: 145 runs, 1 regressions (v4.9.241-99-gfe0a8c1fa2f0)

by kernelci.org bot

stable-rc/linux-4.9.y baseline: 145 runs, 1 regressions (v4.9.241-99-gfe0a8c1fa2f0) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+------+------------+----------+-----------------+------------ sun8i-h3-orangepi-pc | arm | lab-clabbe | gcc-8 | sunxi_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.241-… Test: baseline Tree: stable-rc Branch: linux-4.9.y Describe: v4.9.241-99-gfe0a8c1fa2f0 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: fe0a8c1fa2f02981561bad12daca3729f61808ac Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+------+------------+----------+-----------------+------------ sun8i-h3-orangepi-pc | arm | lab-clabbe | gcc-8 | sunxi_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa723051b760c08bfdb88d6 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sunxi_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.241-99-gfe0a8c1fa2… HTML log: https://storage.kernelci.org//stable-rc/linux-4.9.y/v4.9.241-99-gfe0a8c1fa2… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa723051b760c08bfdb88d7 new failure (last pass: v4.9.241)

4 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror