Re: [Patch V2] drivers: power: Add support for bq24735 charger

[Rhyland Klein]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/