Hi,

On Wed, Dec 21, 2016 at 01:46:17PM +0100, Pali Rohár wrote:

On Wednesday 21 December 2016 03:49:10 Chris Lapa wrote:

quoted

On 20/12/16 10:34 pm, Pali Rohár wrote:

quoted

On Tuesday 20 December 2016 07:00:41 Chris Lapa wrote:

quoted

I can generate a patch to fix this issue, however the bigger
problem exists as to which revision fuel gauge the
bq27xxx_battery.c driver is intended to support for each family.

Hi! I think driver should support all revisions. There can be (and
probably really is) hardware which uses old revision and such
hardware should be still supported...

I agree. However due to the register address changes across the
spectrum of revisions, each revision will have to be specified
individually. For example, we will need to implement a BQ27510G1,
BQ27510G2, BQ27510G3, BQ27520G1, BQ27520G2, BQ27520G3, BQ27520G4
definitions and prospective device tree additions ti,bq27510g1,
ti,bq27510g2 etc.

The other option is to aim for bottom of the barrel support for all
the devices under the BQ27500 definition but my feeling is it would
get messier fast and be less maintainable.

My preference is to go with the first option if you agree?

Yes. If those chips have different register addresses, then those chips 
are different. Name, generation or suffix does not matter here.

Similarly there could be chips with different name, but same addresses, 
so can use one driver/configuration without any change.

So I'm for different name in device tree (or platform data or what is 
being used) to distinguish between different revisions.

Sounds fine to me. Let's keep the compatible string without revision
as deprecated alias for the version currently implemented by the
driver (for backward compatibility).

-- Sebastian