On 2021-10-06T10:10+0200, Hans de Goede wrote: > Hi, > > On 10/6/21 12:06 AM, Sebastian Reichel wrote: > > Hi, > > > > On Tue, Oct 05, 2021 at 08:01:12PM +0200, Hans de Goede wrote: > >> Right, force-discharge automatically implies charging is > >> being inhibited, so putting this in one file makes sense. > >> > >> Any suggestion for the name of the file? > > > > Maybe like this? > > > > --------------------------------------------------------------------- > > What: /sys/class/power_supply/<supply_name>/charge_behaviour > > Date: October 2021 > > Contact: linux-pm@xxxxxxxxxxxxxxx > > Description: > > Configure battery behaviour when a charger is being connected. > > > > Access: Read, Write > > > > Valid values: > > > > 0: auto / no override > > When charger is connected battery should be charged > > 1: force idle > > When charger is connected the battery should neither be charged > > nor discharged. > > 2: force discharge > > When charger is connected the battery should be discharged > > anyways. > > --------------------------------------------------------------------- > > That looks good to me. Although I just realized that some hw may > only support 1. or 2. maybe explicitly document this and that > EOPNOTSUPP will be reported when the value is not supported > (vs EINVAL for plain invalid values) ? Would that not force a userspace applications to offer all possibilities to the user only to tell them that it's not supported? If the driver knows what is supported and what not it should make this discoverable without actually performing the operation. Maybe something along the lines of /sys/power/mem_sleep. Thomas
