Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2302060imu; Tue, 6 Nov 2018 12:15:42 -0800 (PST) X-Google-Smtp-Source: AJdET5cU76GOBUiblDVvwmTemMn9sP99YriPNibt1DawVO9rKZsoHKO44l4/yPgZzg25/pq7HvgP X-Received: by 2002:a63:fe48:: with SMTP id x8mr8791040pgj.261.1541535342096; Tue, 06 Nov 2018 12:15:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541535342; cv=none; d=google.com; s=arc-20160816; b=a4BA+177lqhoj+V5+HU1facTx47UVAkkXhDmy/bRINcBdhqunreDdoNR1oQvMudc4V JG+e7K6vH5DBbtEiQrg5z7ciNV3PmU3cbZj7vkH2sDXAAT0vFBMqPlbAnGbbHYEUVquK IEevKTIfD3ilZTKrgUXwDkkZI8ZeEJ9XJyylZkBiuzGydf5bExkTRRzJtHQHE8AfA6Zg HUWTXpr/5Lazljz4Ut7dX12P2KNAYA+VBF4sOWxX7Lb6AhDXyui246R+al0ALC/KAh+h 4uADCnTt7AXj2Kmniaz85fB2qmh3D9K92g9LQi4v3AHgckxdCpQKIkRmPxPcgB1nFUGn W8Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=tcslFpk0W53zOF+y25Wq/2pkDzrUWGzGbw1NypFVdy4=; b=xQk8G+oJa+84LzQrwgGO9L1E6Muqf/I+IH0YbG2cgHevz5YkeAM8hXVJoO9pwwU2Z2 1rq81kFv+6SnaWg2wDTm7FGVPps/XhVyNIJNMsTmCv/qsW2kRfV1L6U+mHjL/L3p1dLA /qU4ekXOqee/qvgEF8Y7W9OP5AbYP2IZavA2+kRFY4DYSJ7DGV1dqHsJRtPAcDNDTBV6 Y3rdukg4UsbRQzwRVATcMhK3qLA4CxejiC0sTDvjJ8CgDZPDNh8/deGZJxwcRYYhy/Ov HFYJf7gVN5gCF2BuLlB+YltdSMbM1aw5IbqHcggMLGFXnxkaTbVyLp2yN11BwMTp8BqM zrCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=B8ZFnvbx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r18si1268015pgb.491.2018.11.06.12.15.26; Tue, 06 Nov 2018 12:15:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=B8ZFnvbx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388207AbeKGFln (ORCPT + 99 others); Wed, 7 Nov 2018 00:41:43 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:37456 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725936AbeKGFlm (ORCPT ); Wed, 7 Nov 2018 00:41:42 -0500 Received: by mail-pg1-f195.google.com with SMTP id c10-v6so6303772pgq.4; Tue, 06 Nov 2018 12:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tcslFpk0W53zOF+y25Wq/2pkDzrUWGzGbw1NypFVdy4=; b=B8ZFnvbx9NL09YqAqjFS9wFKCdDBQcAW9Wn284fBveFiQ/ae0s4sQm+fmS51Hjiffl lGXy27tkMmLodBJMaC8+W3FwK/+b6b6f7atm7PrKp+qPLx1wtxN+V2Q3xCETn3lKT4JZ c1s1bpCymFeyIrG6hDbH9kgDbA13ThGkGOoHDDxU3CSai38xfdNodMnt5ev372NroPcX J/wF5m9XNAU96YZoZIeA+6npSqjBKlMayfr056nGyouBXe9Gl0URQf8t6fjo9uQ4R0Ae XfLUZlaUDCMqytLbgthaLHE7WEvA7lQqy2yxo+5/e2K8wbZb2B4tNQH9chJ7m5LI2Tc9 FZmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tcslFpk0W53zOF+y25Wq/2pkDzrUWGzGbw1NypFVdy4=; b=QubVibwfdoXkpKMb3gg8PKQIlhlbmlvZIHSy2b3e/FaWgBSFeoDEf5zSFyjf+KLIJr 0c4B7uUyP64EE0YaUCug+lO0hw2DaYIlThpRujAAJn69MARF4XHEhxTgFPN/4zOCn7Jc jl1uZLxcOxl1BA9b9qc4dKl2xkIBWOfnIUmmH3U71NuxjS9GZH+ecXpJvtZM5UjmVzLs +OdFVw7FWQW0o9QJN5wT27n1ZJ+8YLjXw6psJGr+efik7EriAcgaZbgl5+BX1qkmweh0 pGYOVRRep1AY28tDK2FUoPQkYoIwWpNWcfVmocynR0uxVYa/mPKrrvR6zJ+cGiD5AUZc IaTQ== X-Gm-Message-State: AGRZ1gKuwY7W4YF+5ItF0aenECDQWvTBBl4CseHTAzxYs0QYizcup9YD hMrpDdtAFy0Rv/RwKdJ6683nhdvVf4dF08sQK5URwUPA X-Received: by 2002:a62:682:: with SMTP id 124-v6mr14301379pfg.161.1541535285879; Tue, 06 Nov 2018 12:14:45 -0800 (PST) MIME-Version: 1.0 References: <20181103065732.12134-1-jprvita@endlessm.com> <566af8d6-638e-8c7b-71b4-a7a8d6e71cdb@redhat.com> In-Reply-To: <566af8d6-638e-8c7b-71b4-a7a8d6e71cdb@redhat.com> From: =?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?= Date: Tue, 6 Nov 2018 12:14:08 -0800 Message-ID: Subject: Re: [PATCH] ACPI / battery: Fix reporting "Not charging" when capacity is 100% To: Hans de Goede Cc: "Rafael J . Wysocki" , Len Brown , linux-acpi@vger.kernel.org, Daniel Drake , Sebastian Reichel , LKML , linux@endlessm.com, =?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Hans, thanks for your quick response, On Sat, Nov 3, 2018 at 4:28 AM Hans de Goede wrote: > > Hi, > > On 03-11-18 07:57, Jo=C3=A3o Paulo Rechi Vita wrote: > > Commit 19fffc8450d4378580a8f019b195c4617083176f fixed reporting > > "Discharging" on some machines when AC was connected but the battery wa= s > > not charging. But now on these machines the battery status is reported > > as "Not charging" even when the battery is fully charged. > > > > This commit takes the battery capacity into consideration when checking > > if "Not charging" should be returned and "Full" is returned when the > > capacity is 100%. > > > > Signed-off-by: Jo=C3=A3o Paulo Rechi Vita > > acpi_battery_handle_discharging() only gets called if the ACPI_BATTERY_ST= ATE_DISCHARGING > bit is set by the firmware in that case if we are not actually dischargin= g > returning POWER_SUPPLY_STATUS_NOT_CHARGING is the only correct thing to d= o, > we should never return POWER_SUPPLY_STATUS_FULL when the > ACPI_BATTERY_STATE_DISCHARGING bit is set. > I understand the reason behind your original patch, but can you elaborate on why would it be wrong to return POWER_SUPPLY_STATUS_FULL if the battery is full and we know it is not actually discharging? IIUC that is the state returned on hw / firmware that behaves correctly when there is AC power and the battery has 100% of charge. > I was about to point you to the upower bug for upower not > handling POWER_SUPPLY_STATUS_NOT_CHARGING as well as it > could atm, but I see you've already found that and are working > on fixing that. That is great, thank you. > Yes, I'm trying to fix this problem, but it touches different points across the stack and there are different possible approaches for how to present the "Not charging" state to the user. This patch is not necessarily part of, although closely related to, the bigger problem of better handling "Not charging". It actually addresses the problem that the kernel returns "Not charging" when AC is present and the battery is fully charged, which seems wrong to me, despite of "Not charging" not being strictly defined anywhere (at least that I know of). > As for this kernel-side fix I do not believe that fixing thus in > the kernel is the right thing to do. We try to stay away from > heuristics using full_charge_capacity in the kernel since that > is not really reliable / deterministic. > At first I thought that returning POWER_SUPPLY_STATUS_FULL when the battery is full and AC is present was deterministic enough to have it in the kernel. But I don't have any prior experience working with this kind of hardware, so I may very well be wrong on this assumption. It would be great to get some extra clarification though. Thanks, -- Jo=C3=A3o Paulo Rechi Vita http://about.me/jprvita