From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 365373D1711 for ; Mon, 27 Apr 2026 14:09:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777298945; cv=none; b=nM4Oq7muY8WI9RXj0Vts0UmNz4YpTztHobpOON3mdoi62IBwdNNLEjCy+Ow/6pFktu/a5oQzaImVeguG3PxRDWUtEPa9svwiCZkAGLpw9ReufpA2NprIMY/THe6efeGz7KUvfcX27UelELuNy5BScC3iv/6iM2gCQsWXdtnPidI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777298945; c=relaxed/simple; bh=6iBp5T/boDDw3f8vu9674vxoHItIhbflv+gOtQ8i928=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Wsp3SzbH+XDsLa1MUWnBMXXdpZHhyZVgae3yPJqVDuCmo2Kzmr5iA4fY1XA0a0oSnzCLB+GU2sEkxU4QuBBA4f51yP8itoZ9wPGukq7DRBBiIiBMGvDs8J8n8TQ/t6QBbHeLTWjz6jLDSfM5/F6ZTsRCa+Da+Twv60cdn6rtJ0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZhD6B8wF; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZhD6B8wF" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2ae1255a90bso8570305ad.1 for ; Mon, 27 Apr 2026 07:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777298943; x=1777903743; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=0xqpRZaDGVxEqa2CyY0E4vPQn/D7tfhzxeK6F4mGsO0=; b=ZhD6B8wFNKys5HD7qL9JidzIVzeFrjpKTu/2Xpx190l37XkrceE4rxp1mXHDv9uw8K 30YxUnvrqCzhrNYtwb+H7D8xwkM96BbpaTMmwEYTkx0jv/7Y4Ksvq+/Bdzzr1ffZNqDE jRxO5ZHP1nBA9zQWfaFljjITN4J23Pzde01yQEDfi5HFw3OOx4hP83w/OWgLryMDwFkF 5ut63ux3uZFgItjur0ReAKicMSpi5KHGxeUDB4hF8PWOfY4FC4C4mqlNopPHVqlD31x1 eXsWT0fbxIoeCTkP1uVMVDn8fbK8lvbO/Th9kn7sqppO2b7koGqQy2SH5r7/XQs7bGO6 FmYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777298943; x=1777903743; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0xqpRZaDGVxEqa2CyY0E4vPQn/D7tfhzxeK6F4mGsO0=; b=UJmgUOLMsJOSXhNsddjDTeaDMzImW/Vsf1EOot5j2uMifmE63yPuJkDgl0n1nvlSH4 k0CNuxGegZxNiWTf3a58j5O0vzPlvhjDJ9+MrGRyXP+xYI9Hv/6CFc061PKct2hRU+Qw 6CDadKdUu5tSA9XI34xXmrUk8Bca2DYUYHEX2Dm9rAbKHFU9cemh1+hgI7RGCEfkFbWY WzB/MG5MVQd3AraOdUfxI7ABs4g1tEvaA6rq9dUk725X/WeI7BLjXASexxAKMgCZcOSq tqEcWDvz1mJeg//SvxOCoR0/Bj4QegyINT5nx1cPUkZIJKlGk3pkUZHbGT8O59xslIIj FyOQ== X-Forwarded-Encrypted: i=1; AFNElJ86NTjAE5fssr7nRoGqvUp0D9BqHGMAF9jyz5aHVGuU1JqWmQJEGYJgqgN5hmdv2okDy0zAeLXEEINlqh4=@vger.kernel.org X-Gm-Message-State: AOJu0YzcFSQAN0Cpu46+UI0T9KyXFiHpZTTvHlwarrniA5mXcumWfA1h EG0J4zhqbOFSX2tlbTQwX5cY/YJXew0KVkTCZ2FCaMVyfFNbRwuYU5Ta X-Gm-Gg: AeBDiesDWVP+Dij+MEK0KXrJ7dQ4FRaOxit08I/0lWieggL7ZMJMBpjL02NAws47dQo XL9vSxSOwAnmH8KZojKogOKtWyGaRzTCZ5/NFWnAq9XmBy1NBMZ4ssLXRWrB9kiStrye0gk+g5F X9I7gVXLpWZ8Gv/0d29Q8kP+v+ICge6X+mo/lhRPkqvgezpWH0QR+Kx8Rl1lLMzN3v89NhifRgC Kf3d+XUE+7D9uDQj9Df1KfqBxsfd6p8koyiTIa2/8BocsgUkY4uQ4LNjfKYYvWW5mUJ3lRxOq17 5+vcPieFy7m2IZhfGekOd/y/9YiJ3yPB/J+Jk16BFsUZU7ONVWURVqy3rQnm7UoNvB+eLoFPk0Y 8TextHn6v3hyadp0Jt2E62b6aViBH0T8hugPmmWfLDj5XLw97lxlYR7XgO7MZVvNZ7DaTwAgInm 20A4sT6I3bOap4NTaUQuBd0uB79le/Y8uzEr7iiyYh X-Received: by 2002:a17:902:8696:b0:2b2:5c84:32ba with SMTP id d9443c01a7336-2b5f9ece9f3mr169617925ad.2.1777298943363; Mon, 27 Apr 2026 07:09:03 -0700 (PDT) Received: from magniquick ([45.112.148.110]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b5fa9ff98csm307322975ad.3.2026.04.27.07.08.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2026 07:09:02 -0700 (PDT) From: Navon John Lukose To: Hans de Goede , Ilpo Jarvinen , Sebastian Reichel Cc: platform-driver-x86@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Jorge Lopez Subject: [RFC] HP laptop charge mode control via POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR Date: Mon, 27 Apr 2026 19:38:57 +0530 Message-ID: <20260427140857.397971-1-navonjohnlukose@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, I have been looking at battery charge control on an HP laptop, and I would like to check the right upstream direction before preparing a patch. This is not a new userspace ABI. The kernel already has POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR, and some existing drivers expose charge modes without exposing charge thresholds. I am trying to confirm whether that is the right interface for this HP firmware interface, and where the implementation should live. On this machine, Linux currently exposes no native battery charge thresholds: - no charge_control_start_threshold - no charge_control_end_threshold The existing HP kernel drivers also do not expose this feature here: - hp-wmi does not expose battery charge mode control - hp-bioscfg is present, but does not expose Battery Health Manager or related battery threshold attributes on this machine However, the firmware exposes working ACPI methods for charge mode control: - \SBCC 0x0000 -> normal charging / auto - \SBCO 0x0500 -> inhibit charge - \SBCO 0x0200 -> force discharge while on AC These mappings have been tested from Linux by observing battery and adapter state transitions: - auto allows normal charging - inhibit-charge leaves AC online and reports Not charging / zero current - force-discharge makes the battery path discharge while AC is connected My current thinking is: - expose only POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR - support AUTO, INHIBIT_CHARGE, and FORCE_DISCHARGE - do not synthesize charge_control_*_threshold properties in the kernel - leave policies such as "resume below 75%, stop above 80%" to userspace For driver placement, this seems HP-specific rather than generic power-supply logic, so I think it should probably live under drivers/platform/x86/hp/ and register a power_supply extension on the battery, similar to other platform drivers that use power_supply_register_extension() from a battery hook. Does that sound like the right direction? In particular: 1. Is POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR the right ABI for an HP platform that appears to expose only mode-based charging control? 2. Should this be implemented as part of an existing HP driver such as hp-wmi, or as a small new HP-specific driver under drivers/platform/x86/hp/? 3. What should the driver gate support on? For example, should this be gated by DMI quirks, HP WMI/BIOS GUID presence, ACPI method presence, or some combination of those? Thanks, Navon John Lukose