All of lore.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 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.