public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Reichel <sre@kernel.org>
To: "Tc, Jenny" <jenny.tc@intel.com>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Anton Vorontsov <anton.vorontsov@linaro.org>,
	David Woodhouse <dwmw2@infradead.org>,
	"jonghwa3.lee@samsung.com" <jonghwa3.lee@samsung.com>,
	"myungjoo.ham@gmail.com" <myungjoo.ham@gmail.com>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@intel.com>
Subject: Re: [RFC 3/4] power_supply: Introduce charger control interface
Date: Mon, 9 Mar 2015 15:55:17 +0100	[thread overview]
Message-ID: <20150309145517.GB950@earth> (raw)
In-Reply-To: <20ADAB092842284E95860F279283C5642EEC9149@BGSMSX104.gar.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]

Hi,

On Mon, Mar 09, 2015 at 12:47:18PM +0000, Tc, Jenny wrote:
> > > +struct power_supply_charger {
> > > +	int (*get_property)(struct power_supply_charger *psyc,
> > > +			    enum psy_charger_control_property pspc,
> > > +			    union power_supply_propval *val);
> > 
> > The charging framework can simply call the same get_property
> > as used by sysfs. This is already done by all kind of drivers.
> 
> The idea is to separate power supply properties from power supply
> charger properties. Existing power supply properties exposes a generic
> property of a power supply. But the properties introduced above, is used
> to control charging.  But I agree, if the charger properties are moved to
> enum power_supply_property{ }, the existing set_property()/get_property()
> calls can be used

I think making them part of power_supply_property and re-using
existing functions is sensible.

> > > +	int (*set_property)(struct power_supply_charger *psyc,
> > > +			    enum psy_charger_control_property pspc,
> > > +			    const union power_supply_propval *val);
> > 
> > I guess this is needed for values, which are supposed to be
> > writable by the kernel / charging framework, but non-writable
> > by the sysfs. I suggest to add set_property_kernel() instead
> > (and make the above properties part of enum power_supply_property)
> 
> If properties are moved to enum power_supply_property {}, then it's possible
> to reuse the set_property() call. property_is_writeable() can be used to block
> user space  write access.

Right.

> > > +};
> > > +
> > >  struct power_supply {
> > >  	const char *name;
> > >  	enum power_supply_type type;
> > > @@ -200,6 +226,8 @@ struct power_supply {
> > >  	void (*external_power_changed)(struct power_supply *psy);
> > >  	void (*set_charged)(struct power_supply *psy);
> > >
> > > +	struct power_supply_charger *psy_charger;
> > 
> > Why is this a pointer?
> 
> This is introduced to access charger properties using power supply
> object.

The question was why you choose (1) over (2), considering that the
struct contains only two pointers.

(1) struct power_supply_charger *psy_charger;
(2) struct power_supply_charger psy_charger;

> If the properties can be accessed using existing
> set_property/get_property(), then this is not really needed

Right, so don't worry about my comment :)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-03-09 14:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 10:33 [RFC 0/4] Enable power supply charging control Jenny TC
2015-03-06 10:33 ` [RFC 1/4] power_supply: Introduce charging object table Jenny TC
2015-03-06 11:12   ` Oliver Neukum
2015-03-08  1:31     ` Sebastian Reichel
2015-03-08  1:00   ` Sebastian Reichel
2015-03-06 10:33 ` [RFC 2/4] power: core: Add generic interface to get battery specification Jenny TC
2015-03-06 11:16   ` Oliver Neukum
2015-03-09 11:24     ` jonghwa3.lee
2015-03-06 10:33 ` [RFC 3/4] power_supply: Introduce charger control interface Jenny TC
2015-03-08  1:55   ` Sebastian Reichel
2015-03-09 12:47     ` Tc, Jenny
2015-03-09 14:55       ` Sebastian Reichel [this message]
2015-03-06 10:33 ` [RFC 4/4] charger-manager: Enable psy based charge control Jenny TC
2015-03-08  2:14   ` Sebastian Reichel
2015-03-10  5:21     ` Tc, Jenny

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=20150309145517.GB950@earth \
    --to=sre@kernel.org \
    --cc=anton.vorontsov@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=jenny.tc@intel.com \
    --cc=jonghwa3.lee@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox