From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] power_supply: Added support for power supply attribute sources
Date: Mon, 16 Jul 2012 01:21:20 -0700 [thread overview]
Message-ID: <20120716082119.GA26238@lizard> (raw)
In-Reply-To: <1340627842-31908-1-git-send-email-ramakrishna.pallala@intel.com>
Hi Ramakrishna,
On Mon, Jun 25, 2012 at 06:07:22PM +0530, Ramakrishna Pallala wrote:
> On some platforms one driver(or HW chip) may not be able to provide all
> the necessary attributes of the power supply connected to the platform or
> may provide very limited info which can be used by core/primary drivers.
>
> For example a temperature sensor chip placed near the battery can be used
> to report battery ambient temperature but it does not makes sense to register
> sensor driver with power supply class. Or even a ADC driver or platform
> driver may report power supply properties like voltage/current or charging
> status but registering all those driver with power supply class is not a
> practical or ideal approach.
>
> This patch adds the generic support to register the drivers as power
> supply attribute(properties) sources and adds an interface to read
> these attributes from power supply class drivers.
So, you would add power_supply_attributes_register() calls into ADC
drivers? This is not right.
The right approach would be to write a power supply driver that would
accept ADC device/channel (or just a callback) for getting needed
information to report.
I.e.
/*
* Here I just made up adc_channel struct for simplicity of the
* example; For real ADC dev, you really want to use Industrial IO
* framework, i.e. include/linux/iio/iio.h.
*/
struct adc_channel {
...
int (*get_value)(struct *adc_channel);
};
struct adc_power_supply_platform_data {
struct adc_channel *voltage;
struct adc_channel *current;
};
And the "adc power supply" driver would then call:
...
case POWER_SUPPLY_PROP_CURRENT:
prop->intval = voltage->get_value(voltage);
...
Sure, sometimes it's not only ADC, but sensors, regulators
and so forth. So pass all the devices to the power_supply driver,
and teach the driver to work with the facilities.
As an example of such a platform driver, see drivers/power/pda_power.c.
It is a generic driver for platforms with two power sources (AC/USB),
optinally connected to a battery.
[..]
> +struct power_supply_attr_query {
> + enum power_supply_property property;
> + enum power_supply_type type;
> + /* variable to store result */
> + union power_supply_propval res;
> +};
[...]
> +extern int power_supply_get_external_attr(
> + struct power_supply_attr_query *query);
And even if we'd consider adding this feature, the interface seems
very limited. What if there are two, say, batteries?
I don't think it's the right approach, sorry.
Kind regards,
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
next prev parent reply other threads:[~2012-07-16 8:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 12:37 [PATCH] power_supply: Added support for power supply attribute sources Ramakrishna Pallala
2012-07-16 3:02 ` Pallala, Ramakrishna
2012-07-16 8:21 ` Anton Vorontsov [this message]
2012-07-20 9:54 ` Pallala, Ramakrishna
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=20120716082119.GA26238@lizard \
--to=cbouatmailru@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ramakrishna.pallala@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.