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
On Tue, Nov 20, 2012 at 11:08:54AM +, Tc, Jenny wrote:
[...]
> > | We may have:
> > |enum extcon_cable_type {
> > |EXTCON_CT_REGULATOR,
> > |EXTCON_CT_PSY,
> > |EXTCON_CT_CHARGER_CB,
> > |...
> > |};
> > | and have
> > > For example,
> > > Firstly, the power_supply charging framework check state of charger
> > > cable whether attached or detached cable. Second, when power_supply
> > > charging framework receive the changed state of host system from
> > > 'Host system notifier', change charging current of
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,
> |
On Tue, Nov 20, 2012 at 1:24 AM, Anton Vorontsov wrote:
> On Tue, Nov 20, 2012 at 09:14:41AM +, Tc, Jenny wrote:
> [...]
>> > For example,
>> > Firstly, the power_supply charging framework check state of charger cable
>> > whether attached or detached cable. Second, when power_supply charging
On Tue, Nov 20, 2012 at 09:14:41AM +, Tc, Jenny wrote:
[...]
> > For example,
> > Firstly, the power_supply charging framework check state of charger cable
> > whether attached or detached cable. Second, when power_supply charging
> > framework receive the changed state of host system from
> 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 property of
On Tue, Nov 20, 2012 at 09:14:41AM +, Tc, Jenny wrote:
[...]
For example,
Firstly, the power_supply charging framework check state of charger cable
whether attached or detached cable. Second, when power_supply charging
framework receive the changed state of host system from 'Host
On Tue, Nov 20, 2012 at 1:24 AM, Anton Vorontsov cbouatmai...@gmail.com wrote:
On Tue, Nov 20, 2012 at 09:14:41AM +, Tc, Jenny wrote:
[...]
For example,
Firstly, the power_supply charging framework check state of charger cable
whether attached or detached cable. Second, when
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,
|
For example,
Firstly, the power_supply charging framework check state of charger
cable whether attached or detached cable. Second, when power_supply
charging framework receive the changed state of host system from
'Host system notifier', change charging current of charger cable.
On Tue, Nov 20, 2012 at 11:08:54AM +, Tc, Jenny wrote:
[...]
| We may have:
|enum extcon_cable_type {
|EXTCON_CT_REGULATOR,
|EXTCON_CT_PSY,
|EXTCON_CT_CHARGER_CB,
|...
|};
| and have the following
On 11/20/2012 11:42 AM, Tc, Jenny wrote:
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
> > >> 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
On 11/20/2012 10:39 AM, Tc, Jenny wrote:
>> 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
> >> > > 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
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
On 11/20/2012 10:39 AM, Tc, Jenny wrote:
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
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 property of
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
On 11/20/2012 11:42 AM, Tc, Jenny wrote:
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
On Wed, Nov 14, 2012 at 8:05 PM, Tc, Jenny wrote:
>
>
>> > > 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
On Wed, Nov 14, 2012 at 8:05 PM, Tc, Jenny jenny...@intel.com wrote:
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
> > > 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,
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
On Fri, 2012-11-09 at 14:05 +, Tc, Jenny wrote:
> > 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
> 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
> property of
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
property of other
On Fri, 2012-11-09 at 14:05 +, Tc, Jenny wrote:
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
On 10/17/2012 03:34 PM, Tc, Jenny wrote:
>>>> 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
On 10/17/2012 03:34 PM, Tc, Jenny wrote:
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
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
>
> On 10/19/2012 12:13 PM, Tc, Jenny wrote:
> >
> >
> >>>>>> Subject: Re: [PATCH] extcon : callback function to read cable
> >>>>>> property
> >&
Subject: Re: [PATCH] extcon : callback function to read cable property
On 10/19/2012 12:13 PM, Tc, Jenny wrote:
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
On 10/19/2012 12:13 PM, Tc, Jenny wrote:
>
>
>>>>>> Subject: Re: [PATCH] extcon : callback function to read cable
>>>>>> property
>>>>>>
>>>>>> I think the reason why we have extcon is in first place is to
>>&g
On 10/19/2012 12:13 PM, Tc, Jenny wrote:
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
> > > > > 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
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 and it is
up
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
gt; > 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
> >
On Thu, 2012-10-11 at 01:20 +, Tc, Jenny wrote:
From: anish kumar [mailto:anish198519851...@gmail.com]
Sent: Wednesday, October 10, 2012 8:15 PM
To: Tc, Jenny
Cc: myungjoo@samsung.com; cw00.c...@samsung.com; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH] extcon : callback
> From: anish kumar [mailto:anish198519851...@gmail.com]
> Sent: Wednesday, October 10, 2012 8:15 PM
> To: Tc, Jenny
> Cc: myungjoo@samsung.com; cw00.c...@samsung.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] extcon : callback function to read cable pro
On Wed, 2012-10-10 at 15:53 +0530, Jenny TC wrote:
> For some cables a boolean variable will not be enough to represent
> the state and properties of the cable. For example a charger cable can
> have states CONNECT,DISCOONECT,SUSPEND(Host suspend for SDP cable),
> RESUME(Host wakeup), and UPDATE
On Wed, 2012-10-10 at 15:53 +0530, Jenny TC wrote:
For some cables a boolean variable will not be enough to represent
the state and properties of the cable. For example a charger cable can
have states CONNECT,DISCOONECT,SUSPEND(Host suspend for SDP cable),
RESUME(Host wakeup), and UPDATE (to
From: anish kumar [mailto:anish198519851...@gmail.com]
Sent: Wednesday, October 10, 2012 8:15 PM
To: Tc, Jenny
Cc: myungjoo@samsung.com; cw00.c...@samsung.com; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH] extcon : callback function to read cable property
I think the reason why
58 matches
Mail list logo
