linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alex A. Mihaylov" <minimumlaw@rambler.ru>
To: Sebastian Reichel <sre@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, zbr@ioremap.net
Subject: Re: [PATCH 1/2] Add support for OneWire (W1) devices family 0x26 (MAX17211/MAX17215)
Date: Mon, 1 May 2017 09:13:54 +0300	[thread overview]
Message-ID: <f103ca48-1535-20ab-9384-f8dd34b7b57b@rambler.ru> (raw)
In-Reply-To: <20170430205337.kwuwcyesofvqjddl@earth>

Hi!


30.04.17 23:53, Sebastian Reichel wrote::
>>>> Slave device provide software layer for access to internal registers
>>>> MAX17211/MAX17215 chip.
>>> Please convert this to regmap.There is no generic w1 handler, but you can provide custom
>>> read/write functions.
>> I think regmap be overkill for this driver. the perception.
> I did not ask for full usage of all regmap features. Just register
> the read/write handler as regmap handler and use regmap_read/write
> to get values.
>
OK, I think about this. But max17211-battery use ONLY 
w1_max12711x_reg_get(). This is very simple function.

Second function w1_max1721x_reg_set() writen for extend feature list 
(factory calibrating and init battery).  I think, this code must _NOT_ 
be writen, and must _NOT_ be accessible for end user. Change calibration 
values potentially can damage battery or device. Theory, I can unexport 
this function and remove them from drivers code.

So output registers of Maxim M5 Fuel Gauge algorithm very simple: one 
register - one value. In driver I have two points with bitfield. First - 
battery connected from power supply props. Second: very optional device 
type from probe. This value _NOT_ used from driver - just write device 
type, if manufacturer not fill this data in chip nvram.

This moment driver use 14 registers. Ok, let's some time above will be 
14*3=42 registers accessible with w1_max1721x_reg_get(). This value is 
greatly overestimated - so many properties are not in the class 
POWER_SUPPLY. But register range in MAX1721X is 0x1F0 (496 words or 992 
bytes) of RAM for cache registers. As embedded system developer I 
dislike so ram management.

As result I repeat: regmap will be overkill for this driver. But OK, I 
try to write this code. Just for fun.

  reply	other threads:[~2017-05-01  6:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29 14:34 [PATCH 0/2] Add support for MAX1721x fuel gauge chips Alex A. Mihaylov
2017-04-29 14:34 ` [PATCH 1/2] Add support for OneWire (W1) devices family 0x26 (MAX17211/MAX17215) Alex A. Mihaylov
2017-04-29 15:59   ` Sebastian Reichel
2017-04-30  5:21     ` Alex A. Mihaylov
2017-04-30 20:53       ` Sebastian Reichel
2017-05-01  6:13         ` Alex A. Mihaylov [this message]
2017-04-29 14:34 ` [PATCH 2/2] Add driver for MAX17211/MAX17215 fuel gauge Alex A. Mihaylov
2017-04-29 16:40   ` Sebastian Reichel
2017-04-30 17:32     ` Михайлов Алексей Анатольевич
2017-04-30 20:44       ` Sebastian Reichel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f103ca48-1535-20ab-9384-f8dd34b7b57b@rambler.ru \
    --to=minimumlaw@rambler.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=sre@kernel.org \
    --cc=zbr@ioremap.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).