Re: [PATCH 3/8] platform: arm64: qcom-hamoa-ec: Switch fan profile based on power supply state

Anvesh Jain P <[email protected]> Thu, 30 Jul 2026 11:51:58 +0530
Newsgroups org.kernel.vger.platform-driver-x86,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 7/29/2026 4:32 PM, Konrad Dybcio wrote:
> On 7/28/26 7:44 PM, Anvesh Jain P wrote:
>> Add the EC command definitions and handler functions for switching and
>> reading the EC fan profile.
>>
>> Register a power supply notifier so the driver can react to AC/battery
>> transitions: on each PSY_EVENT_PROP_CHANGED notification, queue work
>> that checks power_supply_is_system_supplied() and, if the AC/battery
>> state has actually changed, switches the fan profile to the
>> performance profile on AC or the battery-saver profile on battery.
>> Track the last-applied state in on_ac_power to avoid redundant EC
>> writes. Run the initial sync once at probe time, and defer the actual
>> switch to a work item since the notifier callback runs in atomic
>> context.
>>
>> Serialize the fan profile write under the existing io_lock mutex,
>> alongside the other EC command sequences.
>>
>> Signed-off-by: Anvesh Jain P <[email protected]>
>> ---
> 
> [...]
> 
>> +static int qcom_ec_set_fan_profile(struct qcom_ec *ec, u8 profile_id)
>> +{
>> +	int ret;
>> +
>> +	ret = i2c_smbus_write_byte_data(ec->client, EC_FAN_PROFILE_CMD, profile_id);
> 
> Shouldn't all the accesses be serialized after patch 2?
>

It already is, both call sites hold ec->io_lock around these calls, same
as every other qcom_ec_read()/qcom_ec_write() site in the driver. None
of these low-level accessors take the lock themselves; that's
intentional so callers can wrap multi-command sequences atomically. No
gap here.

> [...]
> 
>> +static int qcom_ec_update_profile_from_power_supply(struct qcom_ec *ec)
>> +{
>> +	int on_ac_power;
>> +	u8 profile;
>> +	int ret = 0;
>> +
>> +	on_ac_power = power_supply_is_system_supplied() > 0 ? 1 : 0;
> 
> Comparisons already return a boolean value (i.e. the ternary operator is
> not necessary here)
>

Ack, will drop the ternary — on_ac_power =
power_supply_is_system_supplied() > 0; is equivalent.

>> +
>> +	profile = on_ac_power ? EC_FAN_PROFILE_BEST_PERF_PLUGGED_IN :
>> +				EC_FAN_PROFILE_BETTER_BATT_ON_BATT;
> 
> Is being on a (powerful) charger a prerequisite for entering this profile?
> Currently plugging in a 5W charger would trigger the switch as well.
> 
> Should this instead be exposed as a fan profile for userspace?
> 
> Konrad

Fair point — power_supply_is_system_supplied() only checks mains
presence, not charger wattage, so even a 5W charger triggers the "best
performance" profile. And exposing this via platform_profile instead of
an automatic AC/battery switch would let userspace make the call
instead. Will check on the feasibility of making this possible.

-- 
Best Regards,
Anvesh