Hi, On 10/6/21 4:49 PM, Thomas Weißschuh wrote: > 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. Good point, but something like /sys/power/mem_sleep works very differently then how all the other power_supply properties work. In general if something is supported or not on a psy class device is communicated by the presence / absence of attributes. So I think we should move back to having 2 separate attributes for this after all; and group the 2 together in the doc and document that enabling (setting to 1) one of force_charge / inhibit_charge automatically clears the setting of the other. Then the availability of the features can simply be probed by checking for the presence of the property files. Regards, Hans
