From 5270ba68ee8b6a5d0de104810ac3c675b0e2e28f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 13 Nov 2021 16:26:58 +0100 Subject: [PATCH] 4.4-stable patches added patches: power-supply-max17042_battery-prevent-int-underflow-in-set_soc_threshold.patch power-supply-max17042_battery-use-vfsoc-for-capacity-when-no-rsns.patch signal-remove-the-bogus-sigkill_pending-in-ptrace_stop.patch --- ...t-int-underflow-in-set_soc_threshold.patch | 35 ++++++++ ...-use-vfsoc-for-capacity-when-no-rsns.patch | 45 ++++++++++ queue-4.4/series | 3 + ...bogus-sigkill_pending-in-ptrace_stop.patch | 82 +++++++++++++++++++ 4 files changed, 165 insertions(+) create mode 100644 queue-4.4/power-supply-max17042_battery-prevent-int-underflow-in-set_soc_threshold.patch create mode 100644 queue-4.4/power-supply-max17042_battery-use-vfsoc-for-capacity-when-no-rsns.patch create mode 100644 queue-4.4/signal-remove-the-bogus-sigkill_pending-in-ptrace_stop.patch diff --git a/queue-4.4/power-supply-max17042_battery-prevent-int-underflow-in-set_soc_threshold.patch b/queue-4.4/power-supply-max17042_battery-prevent-int-underflow-in-set_soc_threshold.patch new file mode 100644 index 00000000000..af1faa685ba --- /dev/null +++ b/queue-4.4/power-supply-max17042_battery-prevent-int-underflow-in-set_soc_threshold.patch @@ -0,0 +1,35 @@ +From e660dbb68c6b3f7b9eb8b9775846a44f9798b719 Mon Sep 17 00:00:00 2001 +From: Sebastian Krzyszkowiak +Date: Tue, 14 Sep 2021 14:18:06 +0200 +Subject: power: supply: max17042_battery: Prevent int underflow in set_soc_threshold + +From: Sebastian Krzyszkowiak + +commit e660dbb68c6b3f7b9eb8b9775846a44f9798b719 upstream. + +max17042_set_soc_threshold gets called with offset set to 1, which means +that minimum threshold value would underflow once SOC got down to 0, +causing invalid alerts from the gauge. + +Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC") +Cc: +Signed-off-by: Sebastian Krzyszkowiak +Reviewed-by: Krzysztof Kozlowski +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/power/max17042_battery.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/power/max17042_battery.c ++++ b/drivers/power/max17042_battery.c +@@ -752,7 +752,8 @@ static void max17042_set_soc_threshold(s + regmap_read(map, MAX17042_RepSOC, &soc); + soc >>= 8; + soc_tr = (soc + off) << 8; +- soc_tr |= (soc - off); ++ if (off < soc) ++ soc_tr |= soc - off; + regmap_write(map, MAX17042_SALRT_Th, soc_tr); + } + diff --git a/queue-4.4/power-supply-max17042_battery-use-vfsoc-for-capacity-when-no-rsns.patch b/queue-4.4/power-supply-max17042_battery-use-vfsoc-for-capacity-when-no-rsns.patch new file mode 100644 index 00000000000..c0a81234725 --- /dev/null +++ b/queue-4.4/power-supply-max17042_battery-use-vfsoc-for-capacity-when-no-rsns.patch @@ -0,0 +1,45 @@ +From 223a3b82834f036a62aa831f67cbf1f1d644c6e2 Mon Sep 17 00:00:00 2001 +From: Henrik Grimler +Date: Wed, 29 Sep 2021 20:14:17 +0200 +Subject: power: supply: max17042_battery: use VFSOC for capacity when no rsns + +From: Henrik Grimler + +commit 223a3b82834f036a62aa831f67cbf1f1d644c6e2 upstream. + +On Galaxy S3 (i9300/i9305), which has the max17047 fuel gauge and no +current sense resistor (rsns), the RepSOC register does not provide an +accurate state of charge value. The reported value is wrong, and does +not change over time. VFSOC however, which uses the voltage fuel gauge +to determine the state of charge, always shows an accurate value. + +For devices without current sense, VFSOC is already used for the +soc-alert (0x0003 is written to MiscCFG register), so with this change +the source of the alert and the PROP_CAPACITY value match. + +Fixes: 359ab9f5b154 ("power_supply: Add MAX17042 Fuel Gauge Driver") +Cc: +Reviewed-by: Krzysztof Kozlowski +Suggested-by: Wolfgang Wiedmeyer +Signed-off-by: Henrik Grimler +Reviewed-by: Hans de Goede +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/power/max17042_battery.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/power/max17042_battery.c ++++ b/drivers/power/max17042_battery.c +@@ -246,7 +246,10 @@ static int max17042_get_property(struct + val->intval = data * 625 / 8; + break; + case POWER_SUPPLY_PROP_CAPACITY: +- ret = regmap_read(map, MAX17042_RepSOC, &data); ++ if (chip->pdata->enable_current_sense) ++ ret = regmap_read(map, MAX17042_RepSOC, &data); ++ else ++ ret = regmap_read(map, MAX17042_VFSOC, &data); + if (ret < 0) + return ret; + diff --git a/queue-4.4/series b/queue-4.4/series index c5232b2fd3d..a6ef0ec4ae2 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -30,3 +30,6 @@ pci-mark-atheros-qca6174-to-avoid-bus-reset.patch ifb-depend-on-netfilter-alternatively-to-tc.patch wcn36xx-fix-ht40-capability-for-2ghz-band.patch mwifiex-read-a-pci-register-after-writing-the-tx-ring-write-pointer.patch +signal-remove-the-bogus-sigkill_pending-in-ptrace_stop.patch +power-supply-max17042_battery-prevent-int-underflow-in-set_soc_threshold.patch +power-supply-max17042_battery-use-vfsoc-for-capacity-when-no-rsns.patch diff --git a/queue-4.4/signal-remove-the-bogus-sigkill_pending-in-ptrace_stop.patch b/queue-4.4/signal-remove-the-bogus-sigkill_pending-in-ptrace_stop.patch new file mode 100644 index 00000000000..5041d81c45e --- /dev/null +++ b/queue-4.4/signal-remove-the-bogus-sigkill_pending-in-ptrace_stop.patch @@ -0,0 +1,82 @@ +From 7d613f9f72ec8f90ddefcae038fdae5adb8404b3 Mon Sep 17 00:00:00 2001 +From: "Eric W. Biederman" +Date: Wed, 1 Sep 2021 13:21:34 -0500 +Subject: signal: Remove the bogus sigkill_pending in ptrace_stop + +From: Eric W. Biederman + +commit 7d613f9f72ec8f90ddefcae038fdae5adb8404b3 upstream. + +The existence of sigkill_pending is a little silly as it is +functionally a duplicate of fatal_signal_pending that is used in +exactly one place. + +Checking for pending fatal signals and returning early in ptrace_stop +is actively harmful. It casues the ptrace_stop called by +ptrace_signal to return early before setting current->exit_code. +Later when ptrace_signal reads the signal number from +current->exit_code is undefined, making it unpredictable what will +happen. + +Instead rely on the fact that schedule will not sleep if there is a +pending signal that can awaken a task. + +Removing the explict sigkill_pending test fixes fixes ptrace_signal +when ptrace_stop does not stop because current->exit_code is always +set to to signr. + +Cc: stable@vger.kernel.org +Fixes: 3d749b9e676b ("ptrace: simplify ptrace_stop()->sigkill_pending() path") +Fixes: 1a669c2f16d4 ("Add arch_ptrace_stop") +Link: https://lkml.kernel.org/r/87pmsyx29t.fsf@disp2133 +Reviewed-by: Kees Cook +Signed-off-by: "Eric W. Biederman" +Signed-off-by: Greg Kroah-Hartman +--- + kernel/signal.c | 17 ++--------------- + 1 file changed, 2 insertions(+), 15 deletions(-) + +--- a/kernel/signal.c ++++ b/kernel/signal.c +@@ -1824,16 +1824,6 @@ static inline int may_ptrace_stop(void) + } + + /* +- * Return non-zero if there is a SIGKILL that should be waking us up. +- * Called with the siglock held. +- */ +-static int sigkill_pending(struct task_struct *tsk) +-{ +- return sigismember(&tsk->pending.signal, SIGKILL) || +- sigismember(&tsk->signal->shared_pending.signal, SIGKILL); +-} +- +-/* + * This must be called with current->sighand->siglock held. + * + * This should be the path for all ptrace stops. +@@ -1858,15 +1848,10 @@ static void ptrace_stop(int exit_code, i + * calling arch_ptrace_stop, so we must release it now. + * To preserve proper semantics, we must do this before + * any signal bookkeeping like checking group_stop_count. +- * Meanwhile, a SIGKILL could come in before we retake the +- * siglock. That must prevent us from sleeping in TASK_TRACED. +- * So after regaining the lock, we must check for SIGKILL. + */ + spin_unlock_irq(¤t->sighand->siglock); + arch_ptrace_stop(exit_code, info); + spin_lock_irq(¤t->sighand->siglock); +- if (sigkill_pending(current)) +- return; + } + + /* +@@ -1875,6 +1860,8 @@ static void ptrace_stop(int exit_code, i + * Also, transition to TRACED and updates to ->jobctl should be + * atomic with respect to siglock and should be done after the arch + * hook as siglock is released and regrabbed across it. ++ * schedule() will not sleep if there is a pending signal that ++ * can awaken the task. + */ + set_current_state(TASK_TRACED); + -- 2.47.2