Message ID | 20221129090112.3451501-1-chenhuiz@axis.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp220297wrr; Tue, 29 Nov 2022 01:07:54 -0800 (PST) X-Google-Smtp-Source: AA0mqf7v2D20Gjba8cEcarPMqggfRkr1M9WZWUbX484Ezi3byrBehI0YwXniQbRoB93JPwMrF4vt X-Received: by 2002:a17:902:9897:b0:186:a98c:4ab8 with SMTP id s23-20020a170902989700b00186a98c4ab8mr36193399plp.118.1669712874705; Tue, 29 Nov 2022 01:07:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669712874; cv=none; d=google.com; s=arc-20160816; b=Y3CtzXm7M85su2fpfW7RAiqY4gOtgOxKNe+LT+fo8irwoxRnSLZpD8PU5auq+AZTrR cf6iKa+j1Udo1usTKjaAwCCyDMoWOq2cZON6qJQ78x+fdmPPDptIba3zKjD4e/cwLhNp lQO5TfvYNNyvBaVD1g46vR947vVx7nb8Y0aygat18quAZb4wSRKzLTJejdrKMlT/t2FK qK/5966MCbrg0FP44NJsEkL75JYFCli2jZRbh/15ConoqtVFYs5nBKo1JLVA6TV8rihd 8C6IU8DXjDkpAPlQuXkTJLk1gmNCTvAeNdg8EiFIS363xpYAsARtZk/sVfEPisxV5JqL m6VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=cXRJQL3OW0O3RetIWNaCoK87alGVsI/co+OWhHfGavI=; b=EFPGMrA/ozrWYxLqGccLGCGh8FEt3mC4z5yxC+AUwY4IXOIxdixyxYunvRa8R9ISUn onhNbFtdEn2jxxmq4oNoMzvbQNjAEE9tPUqrVPFTGPAigt8j930mYB5VrZqWR1n/HV3g 79KoraGAyZe8Cx9+Kk/GvGLgzfFAPM3Xbnbc+3qMUqn/uIvLuLLZJzUj9rJqs4NTW7Vv uvieCqULpDl77Z3ZO+WS2HVMoQxLlHi0dqi/AbXTxynYkor3i78kLKnmpI3zfQRAYAZJ YUmcSQ/Jsm4jC2AVNmagHcYdlALn7lv17MN0viOFpAoS/EcrfRJeRuRU26grzALbeNma taAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=pqZPtrTW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=axis.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ip8-20020a17090b314800b0021944f28622si1194609pjb.74.2022.11.29.01.07.38; Tue, 29 Nov 2022 01:07:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=pqZPtrTW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=axis.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231697AbiK2JB3 (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 29 Nov 2022 04:01:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229712AbiK2JB0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 04:01:26 -0500 Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBB7B65AE; Tue, 29 Nov 2022 01:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1669712485; x=1701248485; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=cXRJQL3OW0O3RetIWNaCoK87alGVsI/co+OWhHfGavI=; b=pqZPtrTWuLZVz68ulQUUcsI3AQbCRlHv+bGAx/s2prnkA3yIJLoJv4V0 WpQKcpdcgyBBiOIQre3DbYpmdTYw1MYjyQmQpZZHLlhXxiOVcYAPXlNKq yXd4Qjp5Qlzkugqh0OQOdaoKHHtmiy9sPmtFjUeOWkxYP0rWte3/1ZLGQ qTCPXvDXMZxBRT9VyfRxh7XtaNpxARNvc26MSzzdBOfanyhumbM0EUvLx vHFXx2hufYfIMAqq2NbW+JXCFvpAMbXxhKN+66pheL5LwhOFpHZ6Lqo7W 3RB7tfvr095se+WCexzPheIp2WNzfrMB+dv8vpzPD91blCbCrfYBauOTD Q==; From: Hermes Zhang <chenhuiz@axis.com> To: Sebastian Reichel <sre@kernel.org> CC: <kernel@axis.com>, Hermes Zhang <chenhuiz@axis.com>, <linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] power: supply: bq256xx: Remove init ichg/vbat with max value Date: Tue, 29 Nov 2022 17:01:12 +0800 Message-ID: <20221129090112.3451501-1-chenhuiz@axis.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750820847199471713?= X-GMAIL-MSGID: =?utf-8?q?1750820847199471713?= |
Series |
power: supply: bq256xx: Remove init ichg/vbat with max value
|
|
Commit Message
Hermes Zhang
Nov. 29, 2022, 9:01 a.m. UTC
Init the ichg and vbat reg with max value is not good. First the chip
already has a default value for ichg and vbat (small value). Init these
two reg with max value will result an unsafe case (e.g. battery is over
charging in a hot environment) if no user space change them later.
Signed-off-by: Hermes Zhang <chenhuiz@axis.com>
---
drivers/power/supply/bq256xx_charger.c | 10 ----------
1 file changed, 10 deletions(-)
Comments
Hi, On Tue, Nov 29, 2022 at 05:01:12PM +0800, Hermes Zhang wrote: > Init the ichg and vbat reg with max value is not good. First the chip > already has a default value for ichg and vbat (small value). Init these > two reg with max value will result an unsafe case (e.g. battery is over > charging in a hot environment) if no user space change them later. > > Signed-off-by: Hermes Zhang <chenhuiz@axis.com> > --- It's the driver's task to setup safe initial maximum values. Pre-kernel values may or may not be safe if you consider things like kexec. If you get unsafe values programmed, then fix the values instead. -- Sebastian > drivers/power/supply/bq256xx_charger.c | 10 ---------- > 1 file changed, 10 deletions(-) > > diff --git a/drivers/power/supply/bq256xx_charger.c b/drivers/power/supply/bq256xx_charger.c > index 01ad84fd147c..d1aa92c10c22 100644 > --- a/drivers/power/supply/bq256xx_charger.c > +++ b/drivers/power/supply/bq256xx_charger.c > @@ -1562,21 +1562,11 @@ static int bq256xx_hw_init(struct bq256xx_device *bq) > if (ret) > return ret; > > - ret = bq->chip_info->bq256xx_set_ichg(bq, > - bat_info->constant_charge_current_max_ua); > - if (ret) > - return ret; > - > ret = bq->chip_info->bq256xx_set_iprechg(bq, > bat_info->precharge_current_ua); > if (ret) > return ret; > > - ret = bq->chip_info->bq256xx_set_vbatreg(bq, > - bat_info->constant_charge_voltage_max_uv); > - if (ret) > - return ret; > - > ret = bq->chip_info->bq256xx_set_iterm(bq, > bat_info->charge_term_current_ua); > if (ret) > -- > 2.30.2 >
Hi, 在 2022/11/29 23:27, Sebastian Reichel 写道: > Hi, > > On Tue, Nov 29, 2022 at 05:01:12PM +0800, Hermes Zhang wrote: >> Init the ichg and vbat reg with max value is not good. First the chip >> already has a default value for ichg and vbat (small value). Init these >> two reg with max value will result an unsafe case (e.g. battery is over >> charging in a hot environment) if no user space change them later. >> >> Signed-off-by: Hermes Zhang <chenhuiz@axis.com> >> --- > It's the driver's task to setup safe initial maximum values. > Pre-kernel values may or may not be safe if you consider things > like kexec. If you get unsafe values programmed, then fix the > values instead. > > -- Sebastian The constant_charge_current_max_ua is either from dts or default value for each chip in the code, but I guess I could ot change them because it has their own meaning (it will be used to check if the setting is valid or not). Do you mean I can set some other value here instead of constant_xxx_max? Best Regards, Hermes >> drivers/power/supply/bq256xx_charger.c | 10 ---------- >> 1 file changed, 10 deletions(-) >> >> diff --git a/drivers/power/supply/bq256xx_charger.c b/drivers/power/supply/bq256xx_charger.c >> index 01ad84fd147c..d1aa92c10c22 100644 >> --- a/drivers/power/supply/bq256xx_charger.c >> +++ b/drivers/power/supply/bq256xx_charger.c >> @@ -1562,21 +1562,11 @@ static int bq256xx_hw_init(struct bq256xx_device *bq) >> if (ret) >> return ret; >> >> - ret = bq->chip_info->bq256xx_set_ichg(bq, >> - bat_info->constant_charge_current_max_ua); >> - if (ret) >> - return ret; >> - >> ret = bq->chip_info->bq256xx_set_iprechg(bq, >> bat_info->precharge_current_ua); >> if (ret) >> return ret; >> >> - ret = bq->chip_info->bq256xx_set_vbatreg(bq, >> - bat_info->constant_charge_voltage_max_uv); >> - if (ret) >> - return ret; >> - >> ret = bq->chip_info->bq256xx_set_iterm(bq, >> bat_info->charge_term_current_ua); >> if (ret) >> -- >> 2.30.2 >>
Hi, On Wed, Nov 30, 2022 at 09:27:42AM +0000, Hermes Zhang wrote: > Hi, > > 在 2022/11/29 23:27, Sebastian Reichel 写道: > > Hi, > > > > On Tue, Nov 29, 2022 at 05:01:12PM +0800, Hermes Zhang wrote: > >> Init the ichg and vbat reg with max value is not good. First the chip > >> already has a default value for ichg and vbat (small value). Init these > >> two reg with max value will result an unsafe case (e.g. battery is over > >> charging in a hot environment) if no user space change them later. > >> > >> Signed-off-by: Hermes Zhang <chenhuiz@axis.com> > >> --- > > It's the driver's task to setup safe initial maximum values. > > Pre-kernel values may or may not be safe if you consider things > > like kexec. If you get unsafe values programmed, then fix the > > values instead. > > > > -- Sebastian > > The constant_charge_current_max_ua is either from dts or default value > for each chip in the code, but I guess I could ot change them because it > has their own meaning (it will be used to check if the setting is valid > or not). Do you mean I can set some other value here instead of > constant_xxx_max? You can just change the DT value to something safe as it is meant to be? -- Sebastian
Hi, On Mon, Dec 05, 2022 at 03:23:53AM +0000, Hermes Zhang wrote: > Init the ichg and vbat reg with max value is not good. First the chip > already has a default value for ichg and vbat (small value). Init these > two reg with max value will result an unsafe case (e.g. battery is over > charging in a hot environment) if no user space change them later. > > Signed-off-by: Hermes Zhang <chenhuiz@axis.com><mailto:chenhuiz@axis.com> > --- > > > It's the driver's task to setup safe initial maximum values. > Pre-kernel values may or may not be safe if you consider things > like kexec. If you get unsafe values programmed, then fix the > values instead. > > -- Sebastian > > > > The constant_charge_current_max_ua is either from dts or default value > for each chip in the code, but I guess I could ot change them because it > has their own meaning (it will be used to check if the setting is valid > or not). Do you mean I can set some other value here instead of > constant_xxx_max? > > > > You can just change the DT value to something safe as it is meant to be? > > > Hi, Please use proper quoting. > I tried it but it doesn't work. As the property in dts (constant_charge_current_max_microamp > and constant_charge_voltage_max_microvolt) means the max current and voltage in CC phase, if > I change them to a safe(small) value, we could not apply any vlaue bigger than them in the > furture: Right, because the bigger values are not safe. > in > bq256xx_set_ichg_curr() > > ichg = clamp(ichg, BQ256XX_ICHG_MIN_uA, ichg_max); > > So the DT value are not match/sutiable for what we want to set here. Either we introduce two > new DT property (for init purpose) to set here or we just remove the setting here as the chip > already has the default values. There are no chip defaults if you use kexec. I'm trying to read between the lines. My understanding is, that you have some kind of userspace based solution to monitor the charging process and reduce the current if it gets dangerous. This process should use higher charge currents then what is considered safe; when it's not running charging should not go above the safe threshold. This effectively means, that you want to take over the decision what is considered safe to userspace. So I suggest adding a module parameter to disable the safety clamp like this: static unsigned bool no_safety = false; module_param(no_safety, bool, 0644); MODULE_PARM_DESC(no_safety, "allow charge currents/voltages considered unsafe by the kernel [default: disallowed]"); ... int ichg_max = bq->init_data.ichg_max; if (no_safety) ichg_max = bq->init_data.ichg_chip_max; -- Sebastian
Hi, On 2022/12/6 5:21, Sebastian Reichel wrote: > Hi, > > On Mon, Dec 05, 2022 at 03:23:53AM +0000, Hermes Zhang wrote: >> Init the ichg and vbat reg with max value is not good. First the chip >> already has a default value for ichg and vbat (small value). Init these >> two reg with max value will result an unsafe case (e.g. battery is over >> charging in a hot environment) if no user space change them later. >> >> Signed-off-by: Hermes Zhang <chenhuiz@axis.com><mailto:chenhuiz@axis.com> >> --- >> >> >> It's the driver's task to setup safe initial maximum values. >> Pre-kernel values may or may not be safe if you consider things >> like kexec. If you get unsafe values programmed, then fix the >> values instead. >> >> -- Sebastian >> >> >> >> The constant_charge_current_max_ua is either from dts or default value >> for each chip in the code, but I guess I could ot change them because it >> has their own meaning (it will be used to check if the setting is valid >> or not). Do you mean I can set some other value here instead of >> constant_xxx_max? >> >> >> >> You can just change the DT value to something safe as it is meant to be? >> >> >> Hi, > > Please use proper quoting. OK. > >> I tried it but it doesn't work. As the property in dts (constant_charge_current_max_microamp >> and constant_charge_voltage_max_microvolt) means the max current and voltage in CC phase, if >> I change them to a safe(small) value, we could not apply any vlaue bigger than them in the >> furture: > > Right, because the bigger values are not safe. > >> in >> bq256xx_set_ichg_curr() >> >> ichg = clamp(ichg, BQ256XX_ICHG_MIN_uA, ichg_max); >> >> So the DT value are not match/sutiable for what we want to set here. Either we introduce two >> new DT property (for init purpose) to set here or we just remove the setting here as the chip >> already has the default values. > > There are no chip defaults if you use kexec. > > I'm trying to read between the lines. My understanding is, that you > have some kind of userspace based solution to monitor the charging > process and reduce the current if it gets dangerous. This process > should use higher charge currents then what is considered safe; when > it's not running charging should not go above the safe threshold. > Yes and thanks for the review. I also go through the whole idea and I think the problem is: when I pass constant_charge_xx_max values in dts, I intend to set the limit of the charging current/voltage which is correct to map to ichg_max/vbatreg_max, but the driver here do extra step to write the max value to ichg/vbatreg regs which I think is not good/safe. So if we want to keep the init setting in driver, I suggest we change the values to the default one: bq->chip_info->bq256xx_def_ichg and bq256xx_def_vbatreg. > This effectively means, that you want to take over the decision what > is considered safe to userspace. So I suggest adding a module parameter > to disable the safety clamp like this: > > static unsigned bool no_safety = false; > module_param(no_safety, bool, 0644); > MODULE_PARM_DESC(no_safety, "allow charge currents/voltages considered unsafe by the kernel [default: disallowed]"); > > ... > > int ichg_max = bq->init_data.ichg_max; > if (no_safety) > ichg_max = bq->init_data.ichg_chip_max; > Yes, this update will work and solve my problem, the only thing is I need set a safe value in dts instead of a real max value to constant_charge_voltage_max_microvolt, the property name and value is not match. I have another idea as described above, please check. Thanks. Best Regards, Hermes
diff --git a/drivers/power/supply/bq256xx_charger.c b/drivers/power/supply/bq256xx_charger.c index 01ad84fd147c..d1aa92c10c22 100644 --- a/drivers/power/supply/bq256xx_charger.c +++ b/drivers/power/supply/bq256xx_charger.c @@ -1562,21 +1562,11 @@ static int bq256xx_hw_init(struct bq256xx_device *bq) if (ret) return ret; - ret = bq->chip_info->bq256xx_set_ichg(bq, - bat_info->constant_charge_current_max_ua); - if (ret) - return ret; - ret = bq->chip_info->bq256xx_set_iprechg(bq, bat_info->precharge_current_ua); if (ret) return ret; - ret = bq->chip_info->bq256xx_set_vbatreg(bq, - bat_info->constant_charge_voltage_max_uv); - if (ret) - return ret; - ret = bq->chip_info->bq256xx_set_iterm(bq, bat_info->charge_term_current_ua); if (ret)