All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: "Tc, Jenny" <jenny.tc@intel.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>,
	anish singh <anish198519851985@gmail.com>,
	"myungjoo.ham@samsung.com" <myungjoo.ham@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"myunjoo.ham@gmail.com" <myunjoo.ham@gmail.com>,
	"lockwood@android.com" <lockwood@android.com>,
	"peterhuewe@gmx.de" <peterhuewe@gmx.de>,
	"broonie@opensource.wolfsonmicro.com" 
	<broonie@opensource.wolfsonmicro.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"jic23@kernel.org" <jic23@kernel.org>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@intel.com>
Subject: Re: [PATCH] extcon : callback function to read cable property
Date: Tue, 20 Nov 2012 03:21:29 -0800	[thread overview]
Message-ID: <20121120112129.GA5759@lizard> (raw)
In-Reply-To: <20ADAB092842284E95860F279283C56444CB72@BGSMSX101.gar.corp.intel.com>

On Tue, Nov 20, 2012 at 11:08:54AM +0000, Tc, Jenny wrote:
[...]
> > | We may have:
> > |        enum extcon_cable_type {
> > |                EXTCON_CT_REGULATOR,
> > |                EXTCON_CT_PSY,
> > |                EXTCON_CT_CHARGER_CB,
> > |                ...
> > |        };
> > | and have the following included at struct extcon_cable:
> > |        union {
> > |                struct regulator *reg;
> > |                struct power_supply *psy;
> > |                struct charger_cable *charger_cb;
> > |                ...
> > |        } cable data;
> > |        enum extcon_cable_type cable_type;
[...]
> struct charger_cable_props {
> 	unsigned long state;
> 	int mA;
> }
> struct extcon_cable {
> 	.....
> 	union {
> 		struct charger_cable_props chrgr_props;
> 		.....
> 	} data;
> 	enum extcon_cable_name cable_name;
> };
> 
> This way we are not restricting the cable properties just to the charger cable.
> We can add other charger cable properties as we identify the properties for them.

Well, to me, it seems that if we have cable *type*, then having properties
of the cable is the next logical step.

So, personally I see nothing wrong with it.

But you can look at this at the different angle: the type is just another
property of the cable. Would it be better to have power_supply-like API
for extcon? :)

if (extcon->get_prop(extcon, EXC_PROP_TYPE) == EXC_TYPE_CHARGER)) {
	int max_uA = extcon->get_prop(extcon, EXC_PROP_MAX_CURRENT;
	...
}

> We can use the cable_name variable to identify  which cable property to use.

This I didn't get, tho. Why would 'cable_name' tell us which property to
use?. The type of the cable defines a set of its properties -- this I can
understand.

Thanks,
Anton.

  reply	other threads:[~2012-11-20 11:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-10 10:23 [PATCH] extcon : callback function to read cable property Jenny TC
2012-10-10 14:45 ` anish kumar
2012-10-11  1:20   ` Tc, Jenny
2012-10-11 13:47     ` anish kumar
2012-10-17  6:34       ` Tc, Jenny
2012-11-08  1:25         ` Chanwoo Choi
2012-11-09 14:05           ` Tc, Jenny
2012-11-10  4:18             ` anish kumar
2012-11-15  4:05               ` Tc, Jenny
2012-11-15 19:31                 ` anish singh
2012-11-20  1:39                   ` Tc, Jenny
2012-11-20  2:29                     ` Chanwoo Choi
2012-11-20  2:42                       ` Tc, Jenny
2012-11-20  6:10                         ` Chanwoo Choi
2012-11-20  9:14                           ` Tc, Jenny
2012-11-20  9:24                             ` Anton Vorontsov
2012-11-20  9:32                               ` anish singh
2012-11-20 11:08                               ` Tc, Jenny
2012-11-20 11:21                                 ` Anton Vorontsov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-10-17  7:08 MyungJoo Ham
2012-10-19  3:13 ` Tc, Jenny
2012-10-20  1:40   ` Chanwoo Choi
2012-10-25  3:18     ` 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=20121120112129.GA5759@lizard \
    --to=cbouatmailru@gmail.com \
    --cc=anish198519851985@gmail.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=cw00.choi@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jenny.tc@intel.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lockwood@android.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=myunjoo.ham@gmail.com \
    --cc=peterhuewe@gmx.de \
    --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.