lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150726010414.GK4753@usrtlx11787.corpusers.net>
Date:	Sat, 25 Jul 2015 18:04:14 -0700
From:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
To:	Sebastian Reichel <sre@...nel.org>
CC:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"Cavin, Courtney" <Courtney.Cavin@...ymobile.com>
Subject: Re: [PATCH 3/4] power: Add Qualcomm SMBB driver

On Sat 25 Jul 08:42 PDT 2015, Sebastian Reichel wrote:

> Hi,
> 
> On Thu, Jun 18, 2015 at 02:13:44PM -0700, Bjorn Andersson wrote:
> > Add the Qualcomm Switch-Mode Battery Charger and Boost driver, found in
> > pm8941.
> 
> The driver's sourcecode looks fine to me.

Thanks.

> I'm not convinced by all those new DT properties, though.  I think
> "watermark" should be replaced with "threshold" and "control" with
> "current" for all properties. Additionally some comments.

I think both of these comes from the documentation, but I agree with
your suggestion.

> Note, that I only used the driver's sourcecode as reference, since the
> DT binding document was neither send to me, nor to linux-pm
> mailinglist.
> 

Sorry about that, I will make sure to double check my recipients in the
future.

>  * battery-charge-control-limit
> 
> It's unclear, what this property is used for. Is the limit only
> for "normal" charging or also for fast charging?
> 

This is described as the current limit during fast charging. However,
"fast charging" is the normal state.

I think the most consistent (regards documentation and other properties)
would be:

 qcom,fast-charge-current-limit

>  * fast-charge-low-watermark
>  * fast-charge-high-watermark
> 
> Add a unit to this property. Maybe "fast-charge-start-voltage"
> and "fast-charge-stop-voltage"?
> 

Will update to:

 qcom,fast-charge-{low,high}-threshold-voltage

>  * fast-charge-safe-voltage
>  * fast-charge-safe-current
> 
> These properties are fine to me. I wonder if they should be named
> fast-charge-max-*, though.
> 

The safe naming is in accordance with the hw documentation, so I think
we should keep those.

>  * auto-recharge-low-watermark
> 
> I think the "low" can be dropped. Instead a -voltage
> should be appended, since it could also be a percentage.
> 

qcom,auto-charge-threshold-voltage

>  * minimum-input-voltage
> 
> Add a vendor prefix to this property.
> 

Shouldn't they all have a vendor prefix?

>  * usb-charge-control-limit
> 
> I suggest to remove this from DT. If no USB detection is
> implemented, the default should be 100mA according to USB
> standard.
> 

Right, this have been convenient during testing as no-one actually does
implement the USB current limit propagation. But that should be
corrected and then you're right that this should only default to 100mA.

I'll drop it.

>  * dc-charge-control-limit
> 
> Please add a vendor prefix and I think "dc-current-limit"
> is a more fitting name.
> 

Sounds good.

>  * disable-dc
> 
> Please add a vendor prefix.
> 

Ok

>  * jeita-extended-temp-range
> 
> Looks ok to me.

Thanks for the review, I'll update the patches accordingly and will send
out v2 (and make sure you get the dt binding document as well).

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ