On Thu, Nov 22, 2012 at 01:00:52PM +, Tc, Jenny wrote:
[...]
> For this solution to work, the cable provider itself
> need to register with any of these subsystems -
> power_supply/regulator/charger manager
> IMHO a cable provider shouldn't register itself with any of the subsystem.
>
> For
> The "RFC" patch for this feature is now shown at:
> http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commit;h=5655a
> eef83addaec77a3b9387a3dd18b6c146dd5
> (Note that "for-add-feature" branch is sort of "RFC" branch)
>
> I'm now considering relaying notifications of data updates
The RFC patch for this feature is now shown at:
http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commit;h=5655a
eef83addaec77a3b9387a3dd18b6c146dd5
(Note that for-add-feature branch is sort of RFC branch)
I'm now considering relaying notifications of data updates possible via the
On Thu, Nov 22, 2012 at 01:00:52PM +, Tc, Jenny wrote:
[...]
For this solution to work, the cable provider itself
need to register with any of these subsystems -
power_supply/regulator/charger manager
IMHO a cable provider shouldn't register itself with any of the subsystem.
For
Anton Vorontsov wrote:
> The idea of using union seemed good to me, what happened to it?
>
> I mean, MyungJoo Ham wrote:
>
> | We may have:
> |enum extcon_cable_type {
> |EXTCON_CT_REGULATOR,
> |EXTCON_CT_PSY,
> |EXTCON_CT_CHARGER_CB,
> |
Anton Vorontsov wrote:
The idea of using union seemed good to me, what happened to it?
I mean, MyungJoo Ham wrote:
| We may have:
|enum extcon_cable_type {
|EXTCON_CT_REGULATOR,
|EXTCON_CT_PSY,
|EXTCON_CT_CHARGER_CB,
|
> > >> I think that the role of extcon subsystem notify changed
> > >> state(attached/detached) of cable to notifiee, but if you want to
> > >> add property feature of cable, you should solve ambiguous issues.
> > >>
> > >> First,
> > >> This patch only support the
I think that the role of extcon subsystem notify changed
state(attached/detached) of cable to notifiee, but if you want to
add property feature of cable, you should solve ambiguous issues.
First,
This patch only support the properties of charger cable but,
never support
extcon : callback function to read cable property
>
> > Subject: Re: RE: [PATCH] extcon : callback function to read cable
> > property
> > > For charger cable the current each cable can provide will be common.
> > > But may not be relevant for other cables.
> &g
to read cable property
Subject: Re: RE: [PATCH] extcon : callback function to read cable
property
For charger cable the current each cable can provide will be common.
But may not be relevant for other cables.
I understand your point on extcon role. But my concern is, when
> Subject: Re: RE: [PATCH] extcon : callback function to read cable property
> > For charger cable the current each cable can provide will be common.
> > But may not be relevant for other cables.
> >
> > I understand your point on extcon role. But my concern is, when t
>
> > Subject: Re: [PATCH] extcon : callback function to read cable property
> >
> > On 10/19/2012 12:13 PM, Tc, Jenny wrote:
> > The rold of extcon inform only attached/detached state of extcon consumer
> > driver from extcon provider driver. After extcon con
Subject: Re: [PATCH] extcon : callback function to read cable property
On 10/19/2012 12:13 PM, Tc, Jenny wrote:
The rold of extcon inform only attached/detached state of extcon consumer
driver from extcon provider driver. After extcon consumer driver detect the
state of cable
Subject: Re: RE: [PATCH] extcon : callback function to read cable property
For charger cable the current each cable can provide will be common.
But may not be relevant for other cables.
I understand your point on extcon role. But my concern is, when the
consumer driver gets
> > > > > Subject: Re: [PATCH] extcon : callback function to read cable
> > > > > property
> > > > >
> > > > > I think the reason why we have extcon is in first place is to
> > > > > only notify the clients of cable conne
Subject: Re: [PATCH] extcon : callback function to read cable
property
I think the reason why we have extcon is in first place is to
only notify the clients of cable connection and disconnection
and it is up to the client to decide what else to do
> Myunjoo/Chanwoo
>
> Ping...
> Could you please review this patch?
>
> -jtc
>
> > > > Subject: Re: [PATCH] extcon : callback function to read cable
> > > > property
> > > >
> > > > I think the reason why we have extcon is in
Myunjoo/Chanwoo
Ping...
Could you please review this patch?
-jtc
Subject: Re: [PATCH] extcon : callback function to read cable
property
I think the reason why we have extcon is in first place is to only
notify the clients of cable connection and disconnection
18 matches
Mail list logo
