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: <5240BA4A.4010007@nvidia.com>
Date:	Mon, 23 Sep 2013 18:01:46 -0400
From:	Rhyland Klein <rklein@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Anton Vorontsov <anton@...msg.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Manish Badarkhe <badarkhe.manish@...il.com>,
	Darbha Sriharsha <dsriharsha@...dia.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [Patch V2] drivers: power: Add support for bq24735 charger

On 9/23/2013 5:53 PM, Stephen Warren wrote:
> On 09/19/2013 10:18 AM, Rhyland Klein wrote:
>> Adding driver support for bq24735 charger chipset.
> 
>> diff --git a/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt
> 
>> +Optional properties :
>> + - ti,ac-detect: This gpio is optionally used to read the ac adapter
>> +   presence.
> 
> GPIO property names ought to end in "-gpios", i.e. "ti,ac-detect-gpios".

V3 (still in the process of finishing up and testing, will have this change.

> 
>> + - ti,charge-current : Used to control and set the charging current. This value
>> +   must follow the below guidelines:
>> +	bit 0 - 5:	Not used
>> +	bit 6:		1 = Adds 64mA of charger current
>> +	bit 7:		1 = Adds 128mA of charger current
>> +	bit 8:		1 = Adds 256mA of charger current
>> +	bit 9:		1 = Adds 512mA of charger current
>> +	bit 10:		1 = Adds 1024mA of charger current
>> +	bit 11:		1 = Adds 2048mA of charger current
>> +	bit 12:		1 = Adds 4096mA of charger current
>> +	bit 13 - 15:	Not used
> 
> That's a little odd. Why not just put the number of mA directly into the
> property unshifted?

This is how the hw register is defined, its the literal number of mA.
This is cleaned up in the upcoming revision.

> 
>> +   Setting the value to < 128mA or > 8.128A terminates charging.
> 
> "terminates charging" is a driver action, not a description of HW. It's
> fine to say that what min/max value should be specified in the property
> for it to be valid, but not what action SW should take in response to that.

This isn't sw. This is defined in the HW documentation as to what
happens if an invalid value is used.

> 
> Those same two comments apply to other properties too.
> 
>> + - ti,input-current:	Used to control and set the charger input current. This
>> +   value must follow the below guidelines:
> 
> What if this value is inconsistent with the charger's power consumption
> derived from the other two properties? Is it really necessary to include
> this property in the DT and hence create the potential for mismatch?
> 

This is a field which can be set in the device's registers. I think it
is being used in our downstream kernel. I maintained support for these 3
fields for the sake of completely defining the dt binding up front.

-rhyland


-- 
nvpublic
--
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