linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ravi Chandra Sadineni <ravisadineni@chromium.org>
To: Guenter Roeck <groeck@google.com>
Cc: Benson Leung <bleung@chromium.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Guenter Roeck <groeck@chromium.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Todd Broch <tbroch@google.com>,
	Daisuke Nojiri <dnojiri@google.com>
Subject: Re: [PATCH] cros_ec: Expose sysfile to force battery cut-off on shutdown.
Date: Sun, 3 Mar 2019 17:02:42 -0800	[thread overview]
Message-ID: <CAEZbON7ugRGpFuj6mwHoSqdyYNFyNKEsGkhFjV7XuwsW28JXcQ@mail.gmail.com> (raw)
In-Reply-To: <CABXOdTdXcCeqkqcH69dG62mLmurbDOcrhhVGm6BgnBzR-1KETg@mail.gmail.com>

Hi Guenter,

On Fri, Mar 1, 2019 at 1:00 PM Guenter Roeck <groeck@google.com> wrote:
>
> On Fri, Mar 1, 2019 at 11:22 AM RaviChandra Sadineni <ravisadineni@chromium.org> wrote:
>>
>> On chromebooks, power_manager daemon normally shutsdown(S5) the device
>> when the battery charge falls below 4% threshold. ChromeOS EC then
>> normally spends an hour in S5 before hibernating. If the battery charge
>> falls below critical threshold in the mean time, EC does a battery cutoff
>> instead of hibernating. On some chromebooks, S5 is optimal enough
>> resulting in EC hibernating without battery cut-off. This results in
>> battery deep-discharging. This is a bad user experience as battery
>> has to trickle charge before booting when the A.C is plugged in the next
>> time.
>>
>> This patch exposes a sysfs file for an userland daemon to suggest EC if it
>> has to do a battery cut-off instead of hibernating when the system enters
>> S5 next time.
>>
>> Signed-off-by: RaviChandra Sadineni <ravisadineni@chromium.org>
>> ---
>>  drivers/platform/chrome/cros_ec_sysfs.c | 34 +++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_sysfs.c b/drivers/platform/chrome/cros_ec_sysfs.c
>> index f34a50121064..151c7c143941 100644
>> --- a/drivers/platform/chrome/cros_ec_sysfs.c
>> +++ b/drivers/platform/chrome/cros_ec_sysfs.c
>> @@ -322,14 +322,48 @@ static ssize_t kb_wake_angle_store(struct device *dev,
>>         return count;
>>  }
>>
>> +/* Battery cut-off control */
>> +static ssize_t cutoff_battery_at_shutdown_store(struct device *dev,
>> +                                  struct device_attribute *attr,
>> +                                  const char *buf, size_t count)
>> +{
>> +       struct ec_params_battery_cutoff *param;
>> +       struct cros_ec_command *msg;
>> +       int ret;
>> +       struct cros_ec_dev *ec = container_of(
>> +                       dev, struct cros_ec_dev, class_dev);
>> +       uint8_t cutoff_battery;
>> +
>> +       if (kstrtou8(buf, 10, &cutoff_battery) || (cutoff_battery != 1))
>
>
> Excessive ( ). Also, why not kstrtobool() ?
Done.
>
>>
>> +               return -EINVAL;
>> +
>>
>> +       msg = kmalloc(sizeof(*msg) + EC_HOST_PARAM_SIZE, GFP_KERNEL);
>> +       if (!msg)
>> +               return -ENOMEM;
>> +
>> +       param = (struct ec_params_battery_cutoff *)msg->data;
>> +       msg->command = EC_CMD_BATTERY_CUT_OFF + ec->cmd_offset;
>> +       msg->version = 1;
>> +       param->flags = EC_BATTERY_CUTOFF_FLAG_AT_SHUTDOWN;
>
>
> For some reason I fail to see where cutoff_battery is used to determine what to send to the EC. Am I missing something ?
Currently there is no way to reset the flag. i.e EC does not expose a
console command to reset the flag once set. So I intend to accept only
true bool flag. Is there a better way to do this ?
>
>>
>> +       msg->outsize = sizeof(*param);
>> +       msg->insize = 0;
>> +       ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
>> +       kfree(msg);
>> +       if (ret < 0)
>> +               return ret;
>> +       return count;
>> +}
>> +
>>  /* Module initialization */
>>
>>  static DEVICE_ATTR_RW(reboot);
>>  static DEVICE_ATTR_RO(version);
>>  static DEVICE_ATTR_RO(flashinfo);
>>  static DEVICE_ATTR_RW(kb_wake_angle);
>> +static DEVICE_ATTR_WO(cutoff_battery_at_shutdown);
>>
>
> I personally dislike excessively long sysfs attribute names. I would prefer to see a shorter name and have it documented in Documentation/ABI/testing/sysfs-class-chromeos.
>
> Is WO really desirable and warranted here ?
Currently EC does not expose a host command to read the status.
Maintaining the state in the kernel might not work as the state can go
out of sync. For example, when AC is plugged in, EC resets the flag
and the kernel will not be aware of it.
>
>>
>>  static struct attribute *__ec_attrs[] = {
>> +       &dev_attr_cutoff_battery_at_shutdown.attr,
>>         &dev_attr_kb_wake_angle.attr,
>>         &dev_attr_reboot.attr,
>>         &dev_attr_version.attr,
>> --
>> 2.20.1
>>

Thanks,
Ravi

      parent reply	other threads:[~2019-03-04  1:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 19:21 [PATCH] cros_ec: Expose sysfile to force battery cut-off on shutdown RaviChandra Sadineni
     [not found] ` <CABXOdTdXcCeqkqcH69dG62mLmurbDOcrhhVGm6BgnBzR-1KETg@mail.gmail.com>
2019-03-04  0:54   ` [PATCH V2] " RaviChandra Sadineni
2019-03-04 14:49     ` kbuild test robot
2019-03-04 14:58     ` kbuild test robot
     [not found]     ` <CABXOdTdvMKGHoE5JQBLca_6V+ihRiUedgnyb2or8GraBDsKYWQ@mail.gmail.com>
2019-03-05  0:51       ` [PATCH V3] " RaviChandra Sadineni
2019-03-05  0:53       ` RaviChandra Sadineni
2019-03-07 11:56         ` Enric Balletbo i Serra
2019-03-08  0:11           ` [PATCH V4] cros_ec: Expose sysfile to force battery cutoff " RaviChandra Sadineni
2019-03-09  1:42           ` [PATCH V5] platform/chrome: mfd/cros_ec_dev: Add sysfile to force RaviChandra Sadineni
2019-03-13 17:38             ` Enric Balletbo i Serra
2019-03-09  1:46           ` [PATCH V3] cros_ec: Expose sysfile to force battery cut-off on shutdown Ravi Chandra Sadineni
2019-03-05  1:00       ` [PATCH V2] " Ravi Chandra Sadineni
     [not found]         ` <CAC0y+AgmxjQv5gm4Bc5mMhnX_PwrixGfraHxg+EGvZXhi2mGPg@mail.gmail.com>
2019-03-05 17:59           ` Ravi Chandra Sadineni
2019-03-04  1:02   ` Ravi Chandra Sadineni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEZbON7ugRGpFuj6mwHoSqdyYNFyNKEsGkhFjV7XuwsW28JXcQ@mail.gmail.com \
    --to=ravisadineni@chromium.org \
    --cc=bleung@chromium.org \
    --cc=dnojiri@google.com \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=groeck@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tbroch@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).