Re: Re: [PATCH] extcon : callback function to read cable property
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 example it cannot register with power_supply subsystem > since it's not a power_supply. It's just source for a power_supply. > We register either charger/battery with power supply. I couldn't find a way > to register the cable with power supply subsystem. Yes, I guess that doesn't make much sense. > Anton, > Do you have any suggestion here? > > I think the same case with regulator framework also. A cable doesn��t belong > to a regulator framework. A cable doesn��t expose any control attribute > (current control/voltage > control). It just have properties (eg current) controlled by external agents > (Host machine/wall charger) > > And charger manager is a consumer and not a provider. It cannot decide the > charger cable capabilities. > > I have a modified version of the above patch which uses properties directly. > https://gitorious.org/linux-charging-framework/linux-charging-framework/commit/ff358373dcb32027ebe1a267fc8b8999a3bd37e4 (Please, always inline the patches.) I spent some time trying to understand what exactly you're trying to accomplish and I failed, and that's why: 1. I see only some small snippets of the code, sometimes by means of URLs and references to another patches, which is hard to follow when you have like tens of emails in the thread; 2. I believe I still didn't see a user of this callback. So, basically you're trying to force me to read your mind and guess your ideas, but as it appears, I'm not good at it. :) So, please do the following: - Prepare a complete, but minimal workable solution, a patchset that shows how exactly you use the new features that you introduce; - The series must be an all-in-1 patchset, so people won't need to go back and forth trying to understand how things depend on each other; - Briefly describe how things work, a typical use-case and how drivers interact with each other. E.g. which driver registers extcon_device, which driver reads mA field, which driver sets mA field (and based on what information), which driver listens for the extcon events, which driver produces the extcon events, etc. No need for lengthy explanations about why you made the decisions, just a brief explanation of how things currently work and interact. Thanks, Anton. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re: [PATCH] extcon : callback function to read cable property
> 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 > notifier block of register-interest. Any inputs are welcomed. > > > Anyway, for the USB issue of "suspend/resume at host-side and current-limit > at device-side", we will need to 1. update regulator subsystem to have > notification for current change (it does for enable/disable/voltage-changes) > 2. let the charger use current-regulator 3. let the one who detects (usb > driver?) changes at host-side change the current limit of that current- > regulator 4. let the event from current-regulator relayed via extcon. > We may use power-supply class as well for this issue. (may need to update if > power-supply class does not have notifications and suspend/resume states) > 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 example it cannot register with power_supply subsystem since it's not a power_supply. It's just source for a power_supply. We register either charger/battery with power supply. I couldn't find a way to register the cable with power supply subsystem. Anton, Do you have any suggestion here? I think the same case with regulator framework also. A cable doesn’t belong to a regulator framework. A cable doesn’t expose any control attribute (current control/voltage control). It just have properties (eg current) controlled by external agents (Host machine/wall charger) And charger manager is a consumer and not a provider. It cannot decide the charger cable capabilities. I have a modified version of the above patch which uses properties directly. https://gitorious.org/linux-charging-framework/linux-charging-framework/commit/ff358373dcb32027ebe1a267fc8b8999a3bd37e4 -jtc
RE: Re: [PATCH] extcon : callback function to read cable property
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 notifier block of register-interest. Any inputs are welcomed. Anyway, for the USB issue of suspend/resume at host-side and current-limit at device-side, we will need to 1. update regulator subsystem to have notification for current change (it does for enable/disable/voltage-changes) 2. let the charger use current-regulator 3. let the one who detects (usb driver?) changes at host-side change the current limit of that current- regulator 4. let the event from current-regulator relayed via extcon. We may use power-supply class as well for this issue. (may need to update if power-supply class does not have notifications and suspend/resume states) 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 example it cannot register with power_supply subsystem since it's not a power_supply. It's just source for a power_supply. We register either charger/battery with power supply. I couldn't find a way to register the cable with power supply subsystem. Anton, Do you have any suggestion here? I think the same case with regulator framework also. A cable doesn’t belong to a regulator framework. A cable doesn’t expose any control attribute (current control/voltage control). It just have properties (eg current) controlled by external agents (Host machine/wall charger) And charger manager is a consumer and not a provider. It cannot decide the charger cable capabilities. I have a modified version of the above patch which uses properties directly. https://gitorious.org/linux-charging-framework/linux-charging-framework/commit/ff358373dcb32027ebe1a267fc8b8999a3bd37e4 -jtc
Re: Re: [PATCH] extcon : callback function to read cable property
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 example it cannot register with power_supply subsystem since it's not a power_supply. It's just source for a power_supply. We register either charger/battery with power supply. I couldn't find a way to register the cable with power supply subsystem. Yes, I guess that doesn't make much sense. Anton, Do you have any suggestion here? I think the same case with regulator framework also. A cable doesn��t belong to a regulator framework. A cable doesn��t expose any control attribute (current control/voltage control). It just have properties (eg current) controlled by external agents (Host machine/wall charger) And charger manager is a consumer and not a provider. It cannot decide the charger cable capabilities. I have a modified version of the above patch which uses properties directly. https://gitorious.org/linux-charging-framework/linux-charging-framework/commit/ff358373dcb32027ebe1a267fc8b8999a3bd37e4 (Please, always inline the patches.) I spent some time trying to understand what exactly you're trying to accomplish and I failed, and that's why: 1. I see only some small snippets of the code, sometimes by means of URLs and references to another patches, which is hard to follow when you have like tens of emails in the thread; 2. I believe I still didn't see a user of this callback. So, basically you're trying to force me to read your mind and guess your ideas, but as it appears, I'm not good at it. :) So, please do the following: - Prepare a complete, but minimal workable solution, a patchset that shows how exactly you use the new features that you introduce; - The series must be an all-in-1 patchset, so people won't need to go back and forth trying to understand how things depend on each other; - Briefly describe how things work, a typical use-case and how drivers interact with each other. E.g. which driver registers extcon_device, which driver reads mA field, which driver sets mA field (and based on what information), which driver listens for the extcon events, which driver produces the extcon events, etc. No need for lengthy explanations about why you made the decisions, just a brief explanation of how things currently work and interact. Thanks, Anton. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] extcon : callback function to read cable property
> > > 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.
> >
> > Not just SUSPEND, but we need to handle RESUME , UPDATE etc. Also
> > this doesn’t help us to define a standard interface for the charger
> > cable state/properties. IMHO it's not right to provide different
> > interfaces for different cables. This doesn't help us to standardize the
> charger cable interface.
> >
> > This thread has been running for a quite long time. Unfortunately we
> > couldn't make an agreement on the final solution. I would like to
> > recap the overall requirement and would like to propose alternate
> > solutions. The requirements is to "Provide a generic interface for charger
> cable states and charger cable properties"
> >
> > Even though extcon subsystem handles charger cable states, it's not
> > enough to handle all kind of charger cable states. It can handle just 2
> > states
> CONNECT/DISCONNECT.
> > But there are scenarios where we need to handle more than 2 states
> > (eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any
> > mechanism to read cable properties in a generic way. Extcon
> > charger-cable consumer driver implementations (eg charger-manager),
> > defines charger cable properties statically (current in mA) inside the
> > consumer driver. This is not enough, since the charger cable
> > properties may change dynamically
> >
> > In existing form extcon cannot support different charger cable states
> > and their properties in a generic way. Also we couldn't find a final
> > solution on how to modify the extcon to support these requirements.
> > From the whole discussion what I conclude is
> > * extcon is not designed to support cable properties
>
> 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,
> |...
> |};
> | 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;
>
> This sounds good to me...
If I am right, this logic will help the consumer to know who will provide the
properties and states.
But currently none of these subsystems are capable of giving the charger cable
properties
because the information will be available only to the "provider driver". The
provider driver
need not to be in any of these subsystem. For example if the OTG driver need to
notify the
cable state (CONNECT/DISCONNECT/SUSPEND/RESUME..) and the properties (current
in mA),
it doesn't make sense to register the OTG driver with any of these subsystems.
But still it make sense to register with extcon since it can give the cable
state information.
I think this is applicable for all cable provider drivers.
If we are fine with union, then can we have the cable properties defined as
unions?
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.
We can use the cable_name variable to identify which cable property to use.
>
> > * extcon is not designed to support any cable state other than
> > CONNECT/DISCONNEC
>
> Dunno for this one. Can we get these additional states via "properties" as
> described above?
>
> Thanks,
> Anton.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] extcon : callback function to read cable property
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,
> |...
> |};
> | 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;
>
> This sounds good to me...
>
> > * extcon is not designed to support any cable state other than
> > CONNECT/DISCONNECT
>
> Dunno for this one. Can we get these additional states via "properties" as
> described above?
>
> Thanks,
> Anton.
>
>
The "RFC" patch for this feature is now shown at:
http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commit;h=5655aeef83addaec77a3b9387a3dd18b6c146dd5
(Note that "for-add-feature" branch is sort of "RFC" branch)
I'm now considering relaying notifications of data updates possible via
the notifier block of register-interest. Any inputs are welcomed.
Anyway, for the USB issue of "suspend/resume at host-side and current-limit at
device-side", we will need to
1. update regulator subsystem to have notification for current change
(it does for enable/disable/voltage-changes)
2. let the charger use current-regulator
3. let the one who detects (usb driver?) changes at host-side change the
current limit of that current-regulator
4. let the event from current-regulator relayed via extcon.
We may use power-supply class as well for this issue. (may need to update
if power-supply class does not have notifications and suspend/resume states)
Cheers,
MyungJoo
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
Re: [PATCH] extcon : callback function to read cable property
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
>> > framework receive the changed state of host system from 'Host system
>> > notifier', change charging current of charger cable.
>>
>> Not just SUSPEND, but we need to handle RESUME , UPDATE etc. Also this
>> doesn’t help us to
>> define a standard interface for the charger cable state/properties. IMHO
>> it's not right
>> to provide different interfaces for different cables. This doesn't help us
>> to standardize
>> the charger cable interface.
>>
>> This thread has been running for a quite long time. Unfortunately we
>> couldn't make an
>> agreement on the final solution. I would like to recap the overall
>> requirement and
>> would like to propose alternate solutions. The requirements is to
>> "Provide a generic interface for charger cable states and charger cable
>> properties"
>>
>> Even though extcon subsystem handles charger cable states, it's not enough
>> to handle
>> all kind of charger cable states. It can handle just 2 states
>> CONNECT/DISCONNECT.
>> But there are scenarios where we need to handle more than 2 states
>> (eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any mechanism
>> to
>> read cable properties in a generic way. Extcon charger-cable consumer driver
>> implementations (eg charger-manager), defines charger cable properties
>> statically (current in mA)
>> inside the consumer driver. This is not enough, since the charger cable
>> properties may change dynamically
>>
>> In existing form extcon cannot support different charger cable states and
>> their
>> properties in a generic way. Also we couldn't find a final solution on how
>> to modify the
>> extcon to support these requirements. From the whole discussion what I
>> conclude is
>> * extcon is not designed to support cable properties
>
> 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,
> |...
> |};
> | 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;
>
> This sounds good to me...
+1 for this idea.
>
>> * extcon is not designed to support any cable state other than
>> CONNECT/DISCONNECT
>
> Dunno for this one. Can we get these additional states via "properties" as
> described above?
>
> Thanks,
> Anton.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 system
> > notifier', change charging current of charger cable.
>
> Not just SUSPEND, but we need to handle RESUME , UPDATE etc. Also this
> doesn’t help us to
> define a standard interface for the charger cable state/properties. IMHO it's
> not right
> to provide different interfaces for different cables. This doesn't help us to
> standardize
> the charger cable interface.
>
> This thread has been running for a quite long time. Unfortunately we couldn't
> make an
> agreement on the final solution. I would like to recap the overall
> requirement and
> would like to propose alternate solutions. The requirements is to
> "Provide a generic interface for charger cable states and charger cable
> properties"
>
> Even though extcon subsystem handles charger cable states, it's not enough to
> handle
> all kind of charger cable states. It can handle just 2 states
> CONNECT/DISCONNECT.
> But there are scenarios where we need to handle more than 2 states
> (eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any mechanism to
> read cable properties in a generic way. Extcon charger-cable consumer driver
> implementations (eg charger-manager), defines charger cable properties
> statically (current in mA)
> inside the consumer driver. This is not enough, since the charger cable
> properties may change dynamically
>
> In existing form extcon cannot support different charger cable states and
> their
> properties in a generic way. Also we couldn't find a final solution on how to
> modify the
> extcon to support these requirements. From the whole discussion what I
> conclude is
> * extcon is not designed to support cable properties
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,
|...
|};
| 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;
This sounds good to me...
> * extcon is not designed to support any cable state other than
> CONNECT/DISCONNECT
Dunno for this one. Can we get these additional states via "properties" as
described above?
Thanks,
Anton.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] extcon : callback function to read cable property
> 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 cable. The following structure
> depend on only charger cable. We can check it the following
> >> structure:
> struct extcon_chrg_cbl_props {
> enum extcon_chrgr_cbl_stat cable_state;
> unsigned long mA;
> };
>
> I think that the patch have to support all of cables for
> property
> feature.
> >>>
> >>> My suggestion is to have a structure like this
> >>>
> >>> struct extcon_cablel_props {
> >>> unsigned int cable_state;
> >>> unsigned int data;
> >> Why can't it be float/long/double??
> >>> }
> >>> Not all cables will have more than two states. If any cable has
> >>> more than two states, the above structure makes it flexible to
> >>> represent additional state and the data associated
> >>>
>
> Second,
> Certainly, you should define common properties of all cables
> and specific properties of each cable. The properties of
> charger cable should never be defined only.
> >> IMHO the extcon doesn't know anything about the cable except the
> >> state which is currently it is in and which also is set by the
> >> provider.I am unable to understand why should extcon provide
> more
> >> than what it knows?It should just limit itself to broadcasting
> >> the cable state and exploiting it for any other information would
> >> only lead to
> more un-necessary code.
> >> It should be same as IIO subsystem where the consumer and
> >> provider knows before hand what information they are going to
> >> share and with what precision and IIO core is just a way to do
> >> that.It doesn't know anything beyond what is given by the provider.
> >> Same is the case with driver core where individual driver sets
> >> it's own private data and the driver core just gives that private
> >> data back to the driver as and when it needs but parsing the
> >> private data in the right way is up to the individual driver.
> >>
> >> I fail to understand why is not the case here.
> >
> > The requirement is different from the IIO case. I am trying to
> > extend the Power Supply class to support charging in a generic way
> (https://lkml.org/lkml/2012/10/18/219).
> > The extcon consumer in this case is not a device driver. It's part
> > of power
> supply class driver itself.
> > I am open to any solution to get the cable properties dynamically.
> > Do you find a better but generic mechanism for this?
> >
> > I am trying to extend extcon just because I couldn’t find any
> > other subsystem which gives cable notifications. IMHO, it's good
> > if we can avoid consumer and provider driver level dependencies
> > just by extending extcon. This will ensure that the same driver
> > will work on any
> platform as long as it's having the dependency only on extcon.
> > We shouldn't put any driver level dependency between extcon
> >> consumer
> and provider.
> > When we do like that, the extcon consumer is expecting the similar
> > implementation for the provider on all platforms. This may not be
> > possible
> Is there anything wrong in assuming similar implementation for all
> the providers?I think the providers know what it can provide and
> this may vary quite a lot.Or can we make a generic provider driver
> which will encompass all the randomness in the various provider
> drivers?This generic driver will get all the properties and since
> it will be generice anyone can use it to know what properties to
> expect.This
> >> will keep the extcon design intact.
> >>>
> >>> Maintainer??
> >>
> >> I agreed about opinion of anish singh. The extcon provider driver
> >> provide generic
> >>
> >>
> >> struct extcon_cablel_props {
> >> unsigned int cable_state;
> >> unsigned int data;
> >> }
> >>
> >> You suggested upper structure and said it is only flexible to
> >> represent additional state, But, it is non-standard. What store real
> >> data on "unsigned int data"? It isn't determined and flexible. That
> >> is extcon consumer driver should already know type of real data or
> >> value of real data. The extcon consumer driver has strong dependency
> >> on extcon provider driver. In this case, if extcon provider driver
> >> can change data value of "unsigned int data", extcon consumer provider
> have to be modified according to extcon provider driver.
> >> I think it isn't correct
RE: [PATCH] extcon : callback function to read cable property
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 cable. The following structure
depend on only charger cable. We can check it the following
structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for
property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has
more than two states, the above structure makes it flexible to
represent additional state and the data associated
Second,
Certainly, you should define common properties of all cables
and specific properties of each cable. The properties of
charger cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide
more
than what it knows?It should just limit itself to broadcasting
the cable state and exploiting it for any other information would
only lead to
more un-necessary code.
It should be same as IIO subsystem where the consumer and
provider knows before hand what information they are going to
share and with what precision and IIO core is just a way to do
that.It doesn't know anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets
it's own private data and the driver core just gives that private
data back to the driver as and when it needs but parsing the
private data in the right way is up to the individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to
extend the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part
of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically.
Do you find a better but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any
other subsystem which gives cable notifications. IMHO, it's good
if we can avoid consumer and provider driver level dependencies
just by extending extcon. This will ensure that the same driver
will work on any
platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon
consumer
and provider.
When we do like that, the extcon consumer is expecting the similar
implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all
the providers?I think the providers know what it can provide and
this may vary quite a lot.Or can we make a generic provider driver
which will encompass all the randomness in the various provider
drivers?This generic driver will get all the properties and since
it will be generice anyone can use it to know what properties to
expect.This
will keep the extcon design intact.
Maintainer??
I agreed about opinion of anish singh. The extcon provider driver
provide generic
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
You suggested upper structure and said it is only flexible to
represent additional state, But, it is non-standard. What store real
data on unsigned int data? It isn't determined and flexible. That
is extcon consumer driver should already know type of real data or
value of real data. The extcon consumer driver has strong dependency
on extcon provider driver. In this case, if extcon provider driver
can change data value of unsigned int data, extcon consumer provider
have to be modified according to extcon provider driver.
I think it isn't correct apporach. So, I proposed that we should
define properties for all cables.
I couldn’t find properties common for all type of cables. Alternate
method I can think of is a new driver extcon-charger.c. This driver will
register with extcon subsystem.
The consumer and provider can use the APIs and properties exposed by
this driver. This way we can ensure that extcon design is intact and
the additional charger cable state and properties can be handled by this
driver. Does that make sense?
I don't agree about 'extcon-charger.c' because the 'extcon-class.c' driver
support already charger cable.
Also it is
Re: [PATCH] extcon : callback function to read cable property
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 system
notifier', change charging current of charger cable.
Not just SUSPEND, but we need to handle RESUME , UPDATE etc. Also this
doesn’t help us to
define a standard interface for the charger cable state/properties. IMHO it's
not right
to provide different interfaces for different cables. This doesn't help us to
standardize
the charger cable interface.
This thread has been running for a quite long time. Unfortunately we couldn't
make an
agreement on the final solution. I would like to recap the overall
requirement and
would like to propose alternate solutions. The requirements is to
Provide a generic interface for charger cable states and charger cable
properties
Even though extcon subsystem handles charger cable states, it's not enough to
handle
all kind of charger cable states. It can handle just 2 states
CONNECT/DISCONNECT.
But there are scenarios where we need to handle more than 2 states
(eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any mechanism to
read cable properties in a generic way. Extcon charger-cable consumer driver
implementations (eg charger-manager), defines charger cable properties
statically (current in mA)
inside the consumer driver. This is not enough, since the charger cable
properties may change dynamically
In existing form extcon cannot support different charger cable states and
their
properties in a generic way. Also we couldn't find a final solution on how to
modify the
extcon to support these requirements. From the whole discussion what I
conclude is
* extcon is not designed to support cable properties
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,
|...
|};
| 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;
This sounds good to me...
* extcon is not designed to support any cable state other than
CONNECT/DISCONNECT
Dunno for this one. Can we get these additional states via properties as
described above?
Thanks,
Anton.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 power_supply charging
framework receive the changed state of host system from 'Host system
notifier', change charging current of charger cable.
Not just SUSPEND, but we need to handle RESUME , UPDATE etc. Also this
doesn’t help us to
define a standard interface for the charger cable state/properties. IMHO
it's not right
to provide different interfaces for different cables. This doesn't help us
to standardize
the charger cable interface.
This thread has been running for a quite long time. Unfortunately we
couldn't make an
agreement on the final solution. I would like to recap the overall
requirement and
would like to propose alternate solutions. The requirements is to
Provide a generic interface for charger cable states and charger cable
properties
Even though extcon subsystem handles charger cable states, it's not enough
to handle
all kind of charger cable states. It can handle just 2 states
CONNECT/DISCONNECT.
But there are scenarios where we need to handle more than 2 states
(eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any mechanism
to
read cable properties in a generic way. Extcon charger-cable consumer driver
implementations (eg charger-manager), defines charger cable properties
statically (current in mA)
inside the consumer driver. This is not enough, since the charger cable
properties may change dynamically
In existing form extcon cannot support different charger cable states and
their
properties in a generic way. Also we couldn't find a final solution on how
to modify the
extcon to support these requirements. From the whole discussion what I
conclude is
* extcon is not designed to support cable properties
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,
|...
|};
| 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;
This sounds good to me...
+1 for this idea.
* extcon is not designed to support any cable state other than
CONNECT/DISCONNECT
Dunno for this one. Can we get these additional states via properties as
described above?
Thanks,
Anton.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] extcon : callback function to read cable property
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,
|...
|};
| 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;
This sounds good to me...
* extcon is not designed to support any cable state other than
CONNECT/DISCONNECT
Dunno for this one. Can we get these additional states via properties as
described above?
Thanks,
Anton.
The RFC patch for this feature is now shown at:
http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commit;h=5655aeef83addaec77a3b9387a3dd18b6c146dd5
(Note that for-add-feature branch is sort of RFC branch)
I'm now considering relaying notifications of data updates possible via
the notifier block of register-interest. Any inputs are welcomed.
Anyway, for the USB issue of suspend/resume at host-side and current-limit at
device-side, we will need to
1. update regulator subsystem to have notification for current change
(it does for enable/disable/voltage-changes)
2. let the charger use current-regulator
3. let the one who detects (usb driver?) changes at host-side change the
current limit of that current-regulator
4. let the event from current-regulator relayed via extcon.
We may use power-supply class as well for this issue. (may need to update
if power-supply class does not have notifications and suspend/resume states)
Cheers,
MyungJoo
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�j:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺��)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
RE: [PATCH] extcon : callback function to read cable property
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.
Not just SUSPEND, but we need to handle RESUME , UPDATE etc. Also
this doesn’t help us to define a standard interface for the charger
cable state/properties. IMHO it's not right to provide different
interfaces for different cables. This doesn't help us to standardize the
charger cable interface.
This thread has been running for a quite long time. Unfortunately we
couldn't make an agreement on the final solution. I would like to
recap the overall requirement and would like to propose alternate
solutions. The requirements is to Provide a generic interface for charger
cable states and charger cable properties
Even though extcon subsystem handles charger cable states, it's not
enough to handle all kind of charger cable states. It can handle just 2
states
CONNECT/DISCONNECT.
But there are scenarios where we need to handle more than 2 states
(eg. USB SUSPEND/RESUME/UPDATE etc). Also extcon doesn't have any
mechanism to read cable properties in a generic way. Extcon
charger-cable consumer driver implementations (eg charger-manager),
defines charger cable properties statically (current in mA) inside the
consumer driver. This is not enough, since the charger cable
properties may change dynamically
In existing form extcon cannot support different charger cable states
and their properties in a generic way. Also we couldn't find a final
solution on how to modify the extcon to support these requirements.
From the whole discussion what I conclude is
* extcon is not designed to support cable properties
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,
|...
|};
| 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;
This sounds good to me...
If I am right, this logic will help the consumer to know who will provide the
properties and states.
But currently none of these subsystems are capable of giving the charger cable
properties
because the information will be available only to the provider driver. The
provider driver
need not to be in any of these subsystem. For example if the OTG driver need to
notify the
cable state (CONNECT/DISCONNECT/SUSPEND/RESUME..) and the properties (current
in mA),
it doesn't make sense to register the OTG driver with any of these subsystems.
But still it make sense to register with extcon since it can give the cable
state information.
I think this is applicable for all cable provider drivers.
If we are fine with union, then can we have the cable properties defined as
unions?
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.
We can use the cable_name variable to identify which cable property to use.
* extcon is not designed to support any cable state other than
CONNECT/DISCONNEC
Dunno for this one. Can we get these additional states via properties as
described above?
Thanks,
Anton.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 but,
never support property of other cable. The following structure
depend on only charger cable. We can check it the following
>> structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
>>>
>>> My suggestion is to have a structure like this
>>>
>>> struct extcon_cablel_props {
>>> unsigned int cable_state;
>>> unsigned int data;
>> Why can't it be float/long/double??
>>> }
>>> Not all cables will have more than two states. If any cable has
>>> more than two states, the above structure makes it flexible to
>>> represent additional state and the data associated
>>>
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger
cable should never be defined only.
>> IMHO the extcon doesn't know anything about the cable except the
>> state which is currently it is in and which also is set by the
>> provider.I am unable to understand why should extcon provide more
>> than what it knows?It should just limit itself to broadcasting the
>> cable state and exploiting it for any other information would only
>> lead to
more un-necessary code.
>> It should be same as IIO subsystem where the consumer and provider
>> knows before hand what information they are going to share and with
>> what precision and IIO core is just a way to do that.It doesn't
>> know anything beyond what is given by the provider.
>> Same is the case with driver core where individual driver sets it's
>> own private data and the driver core just gives that private data
>> back to the driver as and when it needs but parsing the private
>> data in the right way is up to the individual driver.
>>
>> I fail to understand why is not the case here.
>
> The requirement is different from the IIO case. I am trying to
> extend the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
> The extcon consumer in this case is not a device driver. It's part
> of power
supply class driver itself.
> I am open to any solution to get the cable properties dynamically.
> Do you find a better but generic mechanism for this?
>
> I am trying to extend extcon just because I couldn’t find any other
> subsystem which gives cable notifications. IMHO, it's good if we can
> avoid consumer and provider driver level dependencies just by
> extending extcon. This will ensure that the same driver will work on
> any
platform as long as it's having the dependency only on extcon.
> We shouldn't put any driver level dependency between extcon
>> consumer
and provider.
> When we do like that, the extcon consumer is expecting the similar
> implementation for the provider on all platforms. This may not be
> possible
Is there anything wrong in assuming similar implementation for all
the providers?I think the providers know what it can provide and this
may vary quite a lot.Or can we make a generic provider driver which
will encompass all the randomness in the various provider
drivers?This generic driver will get all the properties and since it
will be generice anyone can use it to know what properties to expect.This
>> will keep the extcon design intact.
>>>
>>> Maintainer??
>>
>> I agreed about opinion of anish singh. The extcon provider driver provide
>> generic
>>
>>
>> struct extcon_cablel_props {
>> unsigned int cable_state;
>> unsigned int data;
>> }
>>
>> You suggested upper structure and said it is only flexible to represent
>> additional state, But, it is non-standard. What store real data on "unsigned
>> int
>> data"? It isn't determined and flexible. That is extcon consumer driver
>> should
>> already know type of real data or value of real data. The extcon consumer
>> driver has strong dependency on extcon provider driver. In this case, if
>> extcon provider driver can change data value of "unsigned int data", extcon
>> consumer provider have to be modified according to extcon provider driver.
>> I think it isn't correct apporach. So, I proposed that we should define
>> properties for all cables.
>
> I couldn’t find properties common for all type of cables. Alternate method I
> can think of is
Re: RE: [PATCH] extcon : callback function to read cable property
> > >> 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 cable. The following structure
> > >> depend on only charger cable. We can check it the following
> > structure:
> > >> struct extcon_chrg_cbl_props {
> > >> enum extcon_chrgr_cbl_stat cable_state;
> > >> unsigned long mA;
> > >> };
> > >>
> > >> I think that the patch have to support all of cables for property
> > >> feature.
> > >
> > > My suggestion is to have a structure like this
> > >
> > > struct extcon_cablel_props {
> > > unsigned int cable_state;
> > > unsigned int data;
> > Why can't it be float/long/double??
> > > }
> > > Not all cables will have more than two states. If any cable has
> > > more than two states, the above structure makes it flexible to
> > > represent additional state and the data associated
> > >
> > >>
> > >> Second,
> > >> Certainly, you should define common properties of all cables and
> > >> specific properties of each cable. The properties of charger
> > >> cable should never be defined only.
> > IMHO the extcon doesn't know anything about the cable except the
> > state which is currently it is in and which also is set by the
> > provider.I am unable to understand why should extcon provide more
> > than what it knows?It should just limit itself to broadcasting the
> > cable state and exploiting it for any other information would only
> > lead to
> > >> more un-necessary code.
> > It should be same as IIO subsystem where the consumer and provider
> > knows before hand what information they are going to share and with
> > what precision and IIO core is just a way to do that.It doesn't
> > know anything beyond what is given by the provider.
> > Same is the case with driver core where individual driver sets it's
> > own private data and the driver core just gives that private data
> > back to the driver as and when it needs but parsing the private
> > data in the right way is up to the individual driver.
> >
> > I fail to understand why is not the case here.
> > >>>
> > >>> The requirement is different from the IIO case. I am trying to
> > >>> extend the Power Supply class to support charging in a generic way
> > >> (https://lkml.org/lkml/2012/10/18/219).
> > >>> The extcon consumer in this case is not a device driver. It's part
> > >>> of power
> > >> supply class driver itself.
> > >>> I am open to any solution to get the cable properties dynamically.
> > >>> Do you find a better but generic mechanism for this?
> > >>>
> > >>> I am trying to extend extcon just because I couldn’t find any other
> > >>> subsystem which gives cable notifications. IMHO, it's good if we can
> > >>> avoid consumer and provider driver level dependencies just by
> > >>> extending extcon. This will ensure that the same driver will work on
> > >>> any
> > >> platform as long as it's having the dependency only on extcon.
> > >>> We shouldn't put any driver level dependency between extcon
> > consumer
> > >> and provider.
> > >>> When we do like that, the extcon consumer is expecting the similar
> > >>> implementation for the provider on all platforms. This may not be
> > >>> possible
> > >> Is there anything wrong in assuming similar implementation for all
> > >> the providers?I think the providers know what it can provide and this
> > >> may vary quite a lot.Or can we make a generic provider driver which
> > >> will encompass all the randomness in the various provider
> > >> drivers?This generic driver will get all the properties and since it
> > >> will be generice anyone can use it to know what properties to expect.This
> > will keep the extcon design intact.
> > >
> > > Maintainer??
> >
> > I agreed about opinion of anish singh. The extcon provider driver provide
> > generic
> >
> >
> > struct extcon_cablel_props {
> > unsigned int cable_state;
> > unsigned int data;
> > }
> >
> > You suggested upper structure and said it is only flexible to represent
> > additional state, But, it is non-standard. What store real data on
> > "unsigned int
> > data"? It isn't determined and flexible. That is extcon consumer driver
> > should
> > already know type of real data or value of real data. The extcon consumer
> > driver has strong dependency on extcon provider driver. In this case, if
> > extcon provider driver can change data value of "unsigned int data", extcon
> > consumer provider have to be modified according to extcon provider driver.
> > I think it isn't correct apporach. So, I proposed that we
RE: [PATCH] extcon : callback function to read cable property
> >> 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 cable. The following structure
> >> depend on only charger cable. We can check it the following
> structure:
> >> struct extcon_chrg_cbl_props {
> >> enum extcon_chrgr_cbl_stat cable_state;
> >> unsigned long mA;
> >> };
> >>
> >> I think that the patch have to support all of cables for property
> >> feature.
> >
> > My suggestion is to have a structure like this
> >
> > struct extcon_cablel_props {
> > unsigned int cable_state;
> > unsigned int data;
> Why can't it be float/long/double??
> > }
> > Not all cables will have more than two states. If any cable has
> > more than two states, the above structure makes it flexible to
> > represent additional state and the data associated
> >
> >>
> >> Second,
> >> Certainly, you should define common properties of all cables and
> >> specific properties of each cable. The properties of charger
> >> cable should never be defined only.
> IMHO the extcon doesn't know anything about the cable except the
> state which is currently it is in and which also is set by the
> provider.I am unable to understand why should extcon provide more
> than what it knows?It should just limit itself to broadcasting the
> cable state and exploiting it for any other information would only
> lead to
> >> more un-necessary code.
> It should be same as IIO subsystem where the consumer and provider
> knows before hand what information they are going to share and with
> what precision and IIO core is just a way to do that.It doesn't
> know anything beyond what is given by the provider.
> Same is the case with driver core where individual driver sets it's
> own private data and the driver core just gives that private data
> back to the driver as and when it needs but parsing the private
> data in the right way is up to the individual driver.
>
> I fail to understand why is not the case here.
> >>>
> >>> The requirement is different from the IIO case. I am trying to
> >>> extend the Power Supply class to support charging in a generic way
> >> (https://lkml.org/lkml/2012/10/18/219).
> >>> The extcon consumer in this case is not a device driver. It's part
> >>> of power
> >> supply class driver itself.
> >>> I am open to any solution to get the cable properties dynamically.
> >>> Do you find a better but generic mechanism for this?
> >>>
> >>> I am trying to extend extcon just because I couldn’t find any other
> >>> subsystem which gives cable notifications. IMHO, it's good if we can
> >>> avoid consumer and provider driver level dependencies just by
> >>> extending extcon. This will ensure that the same driver will work on
> >>> any
> >> platform as long as it's having the dependency only on extcon.
> >>> We shouldn't put any driver level dependency between extcon
> consumer
> >> and provider.
> >>> When we do like that, the extcon consumer is expecting the similar
> >>> implementation for the provider on all platforms. This may not be
> >>> possible
> >> Is there anything wrong in assuming similar implementation for all
> >> the providers?I think the providers know what it can provide and this
> >> may vary quite a lot.Or can we make a generic provider driver which
> >> will encompass all the randomness in the various provider
> >> drivers?This generic driver will get all the properties and since it
> >> will be generice anyone can use it to know what properties to expect.This
> will keep the extcon design intact.
> >
> > Maintainer??
>
> I agreed about opinion of anish singh. The extcon provider driver provide
> generic
>
>
> struct extcon_cablel_props {
> unsigned int cable_state;
> unsigned int data;
> }
>
> You suggested upper structure and said it is only flexible to represent
> additional state, But, it is non-standard. What store real data on "unsigned
> int
> data"? It isn't determined and flexible. That is extcon consumer driver should
> already know type of real data or value of real data. The extcon consumer
> driver has strong dependency on extcon provider driver. In this case, if
> extcon provider driver can change data value of "unsigned int data", extcon
> consumer provider have to be modified according to extcon provider driver.
> I think it isn't correct apporach. So, I proposed that we should define
> properties for all cables.
I couldn’t find properties common for all type of cables. Alternate method I
can think of is
a new driver "extcon-charger.c". This driver will register with extcon
Re: [PATCH] extcon : callback function to read cable property
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 but,
>> never support property of other cable. The following structure
>> depend on only charger cable. We can check it the following structure:
>> struct extcon_chrg_cbl_props {
>> enum extcon_chrgr_cbl_stat cable_state;
>> unsigned long mA;
>> };
>>
>> I think that the patch have to support all of cables for property
>> feature.
>
> My suggestion is to have a structure like this
>
> struct extcon_cablel_props {
> unsigned int cable_state;
> unsigned int data;
Why can't it be float/long/double??
> }
> Not all cables will have more than two states. If any cable has
> more than two states, the above structure makes it flexible to
> represent additional state and the data associated
>
>>
>> Second,
>> Certainly, you should define common properties of all cables and
>> specific properties of each cable. The properties of charger
>> cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide more
than what it knows?It should just limit itself to broadcasting the
cable state and exploiting it for any other information would only lead to
>> more un-necessary code.
It should be same as IIO subsystem where the consumer and provider
knows before hand what information they are going to share and with
what precision and IIO core is just a way to do that.It doesn't know
anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's
own private data and the driver core just gives that private data
back to the driver as and when it needs but parsing the private data
in the right way is up to the individual driver.
I fail to understand why is not the case here.
>>>
>>> The requirement is different from the IIO case. I am trying to extend
>>> the Power Supply class to support charging in a generic way
>> (https://lkml.org/lkml/2012/10/18/219).
>>> The extcon consumer in this case is not a device driver. It's part of power
>> supply class driver itself.
>>> I am open to any solution to get the cable properties dynamically. Do
>>> you find a better but generic mechanism for this?
>>>
>>> I am trying to extend extcon just because I couldn’t find any other
>>> subsystem which gives cable notifications. IMHO, it's good if we can
>>> avoid consumer and provider driver level dependencies just by
>>> extending extcon. This will ensure that the same driver will work on any
>> platform as long as it's having the dependency only on extcon.
>>> We shouldn't put any driver level dependency between extcon consumer
>> and provider.
>>> When we do like that, the extcon consumer is expecting the similar
>>> implementation for the provider on all platforms. This may not be
>>> possible
>> Is there anything wrong in assuming similar implementation for all the
>> providers?I think the providers know what it can provide and this may vary
>> quite a lot.Or can we make a generic provider driver which will encompass all
>> the randomness in the various provider drivers?This generic driver will get
>> all
>> the properties and since it will be generice anyone can use it to know what
>> properties to expect.This will keep the extcon design intact.
>
> Maintainer??
I agreed about opinion of anish singh. The extcon provider driver provide
generic
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
You suggested upper structure and said it is only flexible to represent
additional state,
But, it is non-standard. What store real data on "unsigned int data"? It isn't
determined
and flexible. That is extcon consumer driver should already know type of real
data or
value of real data. The extcon consumer driver has strong dependency on extcon
provider
driver. In this case, if extcon provider driver can change data value of
"unsigned int data",
extcon consumer provider have to be modified according to extcon provider
driver.
I think it isn't correct apporach. So, I proposed that we should define
properties for all cables.
>>
>>> and does not seems to be a scalable solution. IMHO, the extcon should
>>> provide a mechanism to retrieve the cable properties. Consumer drivers
>>> can use this API to get the cable properties without knowing the
>>> provider driver implementation. This will make the extcon drivers more
>> scalable and reusable
RE: [PATCH] extcon : callback function to read cable property
> >> > > 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 cable. The following structure
> >> > > depend on only charger cable. We can check it the following structure:
> >> > > struct extcon_chrg_cbl_props {
> >> > > enum extcon_chrgr_cbl_stat cable_state;
> >> > > unsigned long mA;
> >> > > };
> >> > >
> >> > > I think that the patch have to support all of cables for property
> feature.
> >> >
> >> > My suggestion is to have a structure like this
> >> >
> >> > struct extcon_cablel_props {
> >> > unsigned int cable_state;
> >> > unsigned int data;
> >> Why can't it be float/long/double??
> >> > }
> >> > Not all cables will have more than two states. If any cable has
> >> > more than two states, the above structure makes it flexible to
> >> > represent additional state and the data associated
> >> >
> >> > >
> >> > > Second,
> >> > > Certainly, you should define common properties of all cables and
> >> > > specific properties of each cable. The properties of charger
> >> > > cable should never be defined only.
> >> IMHO the extcon doesn't know anything about the cable except the
> >> state which is currently it is in and which also is set by the
> >> provider.I am unable to understand why should extcon provide more
> >> than what it knows?It should just limit itself to broadcasting the
> >> cable state and exploiting it for any other information would only lead to
> more un-necessary code.
> >> It should be same as IIO subsystem where the consumer and provider
> >> knows before hand what information they are going to share and with
> >> what precision and IIO core is just a way to do that.It doesn't know
> >> anything beyond what is given by the provider.
> >> Same is the case with driver core where individual driver sets it's
> >> own private data and the driver core just gives that private data
> >> back to the driver as and when it needs but parsing the private data
> >> in the right way is up to the individual driver.
> >>
> >> I fail to understand why is not the case here.
> >
> > The requirement is different from the IIO case. I am trying to extend
> > the Power Supply class to support charging in a generic way
> (https://lkml.org/lkml/2012/10/18/219).
> > The extcon consumer in this case is not a device driver. It's part of power
> supply class driver itself.
> > I am open to any solution to get the cable properties dynamically. Do
> > you find a better but generic mechanism for this?
> >
> > I am trying to extend extcon just because I couldn’t find any other
> > subsystem which gives cable notifications. IMHO, it's good if we can
> > avoid consumer and provider driver level dependencies just by
> > extending extcon. This will ensure that the same driver will work on any
> platform as long as it's having the dependency only on extcon.
> > We shouldn't put any driver level dependency between extcon consumer
> and provider.
> > When we do like that, the extcon consumer is expecting the similar
> > implementation for the provider on all platforms. This may not be
> > possible
> Is there anything wrong in assuming similar implementation for all the
> providers?I think the providers know what it can provide and this may vary
> quite a lot.Or can we make a generic provider driver which will encompass all
> the randomness in the various provider drivers?This generic driver will get
> all
> the properties and since it will be generice anyone can use it to know what
> properties to expect.This will keep the extcon design intact.
Maintainer??
>
> > and does not seems to be a scalable solution. IMHO, the extcon should
> > provide a mechanism to retrieve the cable properties. Consumer drivers
> > can use this API to get the cable properties without knowing the
> > provider driver implementation. This will make the extcon drivers more
> scalable and reusable across multiple platforms.
> >
> >> >
> >> > Hope above structure would be enough to represent the common cable
> >> > state and it's data. If a cable has more than two states, then
> >> > extcon_update_state can be used to notify the consumer 1)Provider
> >> > can just toggle the "state" argument to notify the consumer that
> >> > cable state is changed OR
> >> > 2) Add one more argument like extcon_update_state(struct
> >> > extcon_dev *edev, u32 mask, u32 state1, u32 sate2)
> >> This will cause other drivers to change such as arizona.
> >> > If the state2 is set, then consumers can use get_cable_properties()
> >> > to query the cable properties. State2 need to be used only if the
> >> > cable need to represent more than two state
> >> >
> >> > >
> >> > > Third,
> >> > > If we finish to decide the properties for all
RE: [PATCH] extcon : callback function to read cable property
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 cable. The following structure
depend on only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has
more than two states, the above structure makes it flexible to
represent additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger
cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide more
than what it knows?It should just limit itself to broadcasting the
cable state and exploiting it for any other information would only lead to
more un-necessary code.
It should be same as IIO subsystem where the consumer and provider
knows before hand what information they are going to share and with
what precision and IIO core is just a way to do that.It doesn't know
anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's
own private data and the driver core just gives that private data
back to the driver as and when it needs but parsing the private data
in the right way is up to the individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to extend
the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically. Do
you find a better but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other
subsystem which gives cable notifications. IMHO, it's good if we can
avoid consumer and provider driver level dependencies just by
extending extcon. This will ensure that the same driver will work on any
platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon consumer
and provider.
When we do like that, the extcon consumer is expecting the similar
implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all the
providers?I think the providers know what it can provide and this may vary
quite a lot.Or can we make a generic provider driver which will encompass all
the randomness in the various provider drivers?This generic driver will get
all
the properties and since it will be generice anyone can use it to know what
properties to expect.This will keep the extcon design intact.
Maintainer??
and does not seems to be a scalable solution. IMHO, the extcon should
provide a mechanism to retrieve the cable properties. Consumer drivers
can use this API to get the cable properties without knowing the
provider driver implementation. This will make the extcon drivers more
scalable and reusable across multiple platforms.
Hope above structure would be enough to represent the common cable
state and it's data. If a cable has more than two states, then
extcon_update_state can be used to notify the consumer 1)Provider
can just toggle the state argument to notify the consumer that
cable state is changed OR
2) Add one more argument like extcon_update_state(struct
extcon_dev *edev, u32 mask, u32 state1, u32 sate2)
This will cause other drivers to change such as arizona.
If the state2 is set, then consumers can use get_cable_properties()
to query the cable properties. State2 need to be used only if the
cable need to represent more than two state
Third,
If we finish to decide the properties for all cables, I'd like to
see a example
Why do we think that state and property is the only thing which the
consumer want to know?I am sure there would be some more properties
which would be of some interest to consumers and there is quite a
possibility that in future we might get a patch for that
Re: [PATCH] extcon : callback function to read cable property
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 but,
never support property of other cable. The following structure
depend on only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has
more than two states, the above structure makes it flexible to
represent additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger
cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide more
than what it knows?It should just limit itself to broadcasting the
cable state and exploiting it for any other information would only lead to
more un-necessary code.
It should be same as IIO subsystem where the consumer and provider
knows before hand what information they are going to share and with
what precision and IIO core is just a way to do that.It doesn't know
anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's
own private data and the driver core just gives that private data
back to the driver as and when it needs but parsing the private data
in the right way is up to the individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to extend
the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically. Do
you find a better but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other
subsystem which gives cable notifications. IMHO, it's good if we can
avoid consumer and provider driver level dependencies just by
extending extcon. This will ensure that the same driver will work on any
platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon consumer
and provider.
When we do like that, the extcon consumer is expecting the similar
implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all the
providers?I think the providers know what it can provide and this may vary
quite a lot.Or can we make a generic provider driver which will encompass all
the randomness in the various provider drivers?This generic driver will get
all
the properties and since it will be generice anyone can use it to know what
properties to expect.This will keep the extcon design intact.
Maintainer??
I agreed about opinion of anish singh. The extcon provider driver provide
generic
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
You suggested upper structure and said it is only flexible to represent
additional state,
But, it is non-standard. What store real data on unsigned int data? It isn't
determined
and flexible. That is extcon consumer driver should already know type of real
data or
value of real data. The extcon consumer driver has strong dependency on extcon
provider
driver. In this case, if extcon provider driver can change data value of
unsigned int data,
extcon consumer provider have to be modified according to extcon provider
driver.
I think it isn't correct apporach. So, I proposed that we should define
properties for all cables.
and does not seems to be a scalable solution. IMHO, the extcon should
provide a mechanism to retrieve the cable properties. Consumer drivers
can use this API to get the cable properties without knowing the
provider driver implementation. This will make the extcon drivers more
scalable and reusable across multiple platforms.
Hope above structure would be enough to represent the common cable
state and it's data. If a cable has more than two states, then
extcon_update_state can be used to notify the consumer 1)Provider
can just toggle the state argument to notify the consumer that
cable state is changed OR
2) Add one
RE: [PATCH] extcon : callback function to read cable property
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 cable. The following structure
depend on only charger cable. We can check it the following
structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has
more than two states, the above structure makes it flexible to
represent additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger
cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide more
than what it knows?It should just limit itself to broadcasting the
cable state and exploiting it for any other information would only
lead to
more un-necessary code.
It should be same as IIO subsystem where the consumer and provider
knows before hand what information they are going to share and with
what precision and IIO core is just a way to do that.It doesn't
know anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's
own private data and the driver core just gives that private data
back to the driver as and when it needs but parsing the private
data in the right way is up to the individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to
extend the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part
of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically.
Do you find a better but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other
subsystem which gives cable notifications. IMHO, it's good if we can
avoid consumer and provider driver level dependencies just by
extending extcon. This will ensure that the same driver will work on
any
platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon
consumer
and provider.
When we do like that, the extcon consumer is expecting the similar
implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all
the providers?I think the providers know what it can provide and this
may vary quite a lot.Or can we make a generic provider driver which
will encompass all the randomness in the various provider
drivers?This generic driver will get all the properties and since it
will be generice anyone can use it to know what properties to expect.This
will keep the extcon design intact.
Maintainer??
I agreed about opinion of anish singh. The extcon provider driver provide
generic
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
You suggested upper structure and said it is only flexible to represent
additional state, But, it is non-standard. What store real data on unsigned
int
data? It isn't determined and flexible. That is extcon consumer driver should
already know type of real data or value of real data. The extcon consumer
driver has strong dependency on extcon provider driver. In this case, if
extcon provider driver can change data value of unsigned int data, extcon
consumer provider have to be modified according to extcon provider driver.
I think it isn't correct apporach. So, I proposed that we should define
properties for all cables.
I couldn’t find properties common for all type of cables. Alternate method I
can think of is
a new driver extcon-charger.c. This driver will register with extcon
subsystem.
The consumer and provider can use the APIs and properties exposed by this
driver. This
way we can ensure that extcon design is intact and the additional charger cable
state and
properties can be handled by this driver. Does that make sense?
and does not seems to be a scalable solution. IMHO, the extcon
should provide a mechanism to retrieve the cable properties.
Consumer drivers can use
Re: RE: [PATCH] extcon : callback function to read cable property
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 cable. The following structure
depend on only charger cable. We can check it the following
structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has
more than two states, the above structure makes it flexible to
represent additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger
cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide more
than what it knows?It should just limit itself to broadcasting the
cable state and exploiting it for any other information would only
lead to
more un-necessary code.
It should be same as IIO subsystem where the consumer and provider
knows before hand what information they are going to share and with
what precision and IIO core is just a way to do that.It doesn't
know anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's
own private data and the driver core just gives that private data
back to the driver as and when it needs but parsing the private
data in the right way is up to the individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to
extend the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part
of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically.
Do you find a better but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other
subsystem which gives cable notifications. IMHO, it's good if we can
avoid consumer and provider driver level dependencies just by
extending extcon. This will ensure that the same driver will work on
any
platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon
consumer
and provider.
When we do like that, the extcon consumer is expecting the similar
implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all
the providers?I think the providers know what it can provide and this
may vary quite a lot.Or can we make a generic provider driver which
will encompass all the randomness in the various provider
drivers?This generic driver will get all the properties and since it
will be generice anyone can use it to know what properties to expect.This
will keep the extcon design intact.
Maintainer??
I agreed about opinion of anish singh. The extcon provider driver provide
generic
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
You suggested upper structure and said it is only flexible to represent
additional state, But, it is non-standard. What store real data on
unsigned int
data? It isn't determined and flexible. That is extcon consumer driver
should
already know type of real data or value of real data. The extcon consumer
driver has strong dependency on extcon provider driver. In this case, if
extcon provider driver can change data value of unsigned int data, extcon
consumer provider have to be modified according to extcon provider driver.
I think it isn't correct apporach. So, I proposed that we should define
properties for all cables.
I couldn’t find properties common for all type of cables. Alternate method I
can think of is
a new driver extcon-charger.c. This driver will register with extcon
subsystem.
The consumer and provider can use the APIs and properties exposed by this
driver. This
way we can ensure that extcon design is intact and the additional charger
cable state and
properties can be handled by this driver. Does that make sense?
Adding another API at a device driver is
Re: [PATCH] extcon : callback function to read cable property
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 but,
never support property of other cable. The following structure
depend on only charger cable. We can check it the following
structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has
more than two states, the above structure makes it flexible to
represent additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger
cable should never be defined only.
IMHO the extcon doesn't know anything about the cable except the
state which is currently it is in and which also is set by the
provider.I am unable to understand why should extcon provide more
than what it knows?It should just limit itself to broadcasting the
cable state and exploiting it for any other information would only
lead to
more un-necessary code.
It should be same as IIO subsystem where the consumer and provider
knows before hand what information they are going to share and with
what precision and IIO core is just a way to do that.It doesn't
know anything beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's
own private data and the driver core just gives that private data
back to the driver as and when it needs but parsing the private
data in the right way is up to the individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to
extend the Power Supply class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part
of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically.
Do you find a better but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other
subsystem which gives cable notifications. IMHO, it's good if we can
avoid consumer and provider driver level dependencies just by
extending extcon. This will ensure that the same driver will work on
any
platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon
consumer
and provider.
When we do like that, the extcon consumer is expecting the similar
implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all
the providers?I think the providers know what it can provide and this
may vary quite a lot.Or can we make a generic provider driver which
will encompass all the randomness in the various provider
drivers?This generic driver will get all the properties and since it
will be generice anyone can use it to know what properties to expect.This
will keep the extcon design intact.
Maintainer??
I agreed about opinion of anish singh. The extcon provider driver provide
generic
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
You suggested upper structure and said it is only flexible to represent
additional state, But, it is non-standard. What store real data on unsigned
int
data? It isn't determined and flexible. That is extcon consumer driver
should
already know type of real data or value of real data. The extcon consumer
driver has strong dependency on extcon provider driver. In this case, if
extcon provider driver can change data value of unsigned int data, extcon
consumer provider have to be modified according to extcon provider driver.
I think it isn't correct apporach. So, I proposed that we should define
properties for all cables.
I couldn’t find properties common for all type of cables. Alternate method I
can think of is
a new driver extcon-charger.c. This driver will register with extcon
subsystem.
The consumer and provider can use the APIs and properties exposed by this
driver. This
way we can ensure that extcon design is intact and the additional charger
cable state and
properties can be handled by this driver. Does that make sense?
I don't agree about 'extcon-charger.c' because the 'extcon-class.c' driver
support already charger
cable.
Also it is duplicate feature between 'extcon-class.c' and 'extcon-charger.c'.
Re: [PATCH] extcon : callback function to read cable property
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 patch only support the properties of charger cable but, never
>> > > support property of other cable. The following structure depend on
>> > > only charger cable. We can check it the following structure:
>> > > struct extcon_chrg_cbl_props {
>> > > enum extcon_chrgr_cbl_stat cable_state;
>> > > unsigned long mA;
>> > > };
>> > >
>> > > I think that the patch have to support all of cables for property
>> > > feature.
>> >
>> > My suggestion is to have a structure like this
>> >
>> > struct extcon_cablel_props {
>> > unsigned int cable_state;
>> > unsigned int data;
>> Why can't it be float/long/double??
>> > }
>> > Not all cables will have more than two states. If any cable has more
>> > than two states, the above structure makes it flexible to represent
>> > additional state and the data associated
>> >
>> > >
>> > > Second,
>> > > Certainly, you should define common properties of all cables and
>> > > specific properties of each cable. The properties of charger cable
>> > > should never be defined only.
>> IMHO the extcon doesn't know anything about the cable except the state
>> which is currently it is in and which also is set by the provider.I am
>> unable to
>> understand why should extcon provide more than what it knows?It should
>> just limit itself to broadcasting the cable state and exploiting it for any
>> other
>> information would only lead to more un-necessary code.
>> It should be same as IIO subsystem where the consumer and provider knows
>> before hand what information they are going to share and with what
>> precision and IIO core is just a way to do that.It doesn't know anything
>> beyond what is given by the provider.
>> Same is the case with driver core where individual driver sets it's own
>> private
>> data and the driver core just gives that private data back to the driver as
>> and
>> when it needs but parsing the private data in the right way is up to the
>> individual driver.
>>
>> I fail to understand why is not the case here.
>
> The requirement is different from the IIO case. I am trying to extend the
> Power Supply
> class to support charging in a generic way
> (https://lkml.org/lkml/2012/10/18/219).
> The extcon consumer in this case is not a device driver. It's part of power
> supply class driver itself.
> I am open to any solution to get the cable properties dynamically. Do you
> find a better
> but generic mechanism for this?
>
> I am trying to extend extcon just because I couldn’t find any other
> subsystem which gives
> cable notifications. IMHO, it's good if we can avoid consumer and provider
> driver level
> dependencies just by extending extcon. This will ensure that the same driver
> will work on any platform as long as it's having the dependency only on
> extcon.
> We shouldn't put any driver level dependency between extcon consumer and
> provider.
> When we do like that, the extcon consumer is expecting the
> similar implementation for the provider on all platforms. This may not be
> possible
Is there anything wrong in assuming similar implementation for all the
providers?I think the
providers know what it can provide and this may vary quite a lot.Or
can we make a generic provider
driver which will encompass all the randomness in the various provider
drivers?This generic
driver will get all the properties and since it will be generice
anyone can use it to know what
properties to expect.This will keep the extcon design intact.
> and does not seems to be a scalable solution. IMHO, the extcon should
> provide a mechanism to retrieve
> the cable properties. Consumer drivers can use this API to get the cable
> properties without
> knowing the provider driver implementation. This will make the extcon
> drivers more scalable
> and reusable across multiple platforms.
>
>> >
>> > Hope above structure would be enough to represent the common cable
>> > state and it's data. If a cable has more than two states, then
>> > extcon_update_state can be used to notify the consumer 1)Provider can
>> > just toggle the "state" argument to notify the consumer that cable
>> > state is changed OR
>> > 2) Add one more argument like extcon_update_state(struct extcon_dev
>> > *edev, u32 mask, u32 state1, u32 sate2)
>> This will cause other drivers to change such as arizona.
>> > If the state2 is set, then consumers can use get_cable_properties() to
>> > query the cable properties. State2 need to be used only if the cable
>> > need to represent more than two state
>> >
>> > >
>> > > Third,
>> > > If we finish to decide the properties for all cables, I'd like to
>> > > see a example
>> Why do we think that state and property is the only
Re: [PATCH] extcon : callback function to read cable property
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 only support the properties of charger cable but, never
support property of other cable. The following structure depend on
only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property
feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has more
than two states, the above structure makes it flexible to represent
additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger cable
should never be defined only.
IMHO the extcon doesn't know anything about the cable except the state
which is currently it is in and which also is set by the provider.I am
unable to
understand why should extcon provide more than what it knows?It should
just limit itself to broadcasting the cable state and exploiting it for any
other
information would only lead to more un-necessary code.
It should be same as IIO subsystem where the consumer and provider knows
before hand what information they are going to share and with what
precision and IIO core is just a way to do that.It doesn't know anything
beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's own
private
data and the driver core just gives that private data back to the driver as
and
when it needs but parsing the private data in the right way is up to the
individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to extend the
Power Supply
class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically. Do you
find a better
but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other
subsystem which gives
cable notifications. IMHO, it's good if we can avoid consumer and provider
driver level
dependencies just by extending extcon. This will ensure that the same driver
will work on any platform as long as it's having the dependency only on
extcon.
We shouldn't put any driver level dependency between extcon consumer and
provider.
When we do like that, the extcon consumer is expecting the
similar implementation for the provider on all platforms. This may not be
possible
Is there anything wrong in assuming similar implementation for all the
providers?I think the
providers know what it can provide and this may vary quite a lot.Or
can we make a generic provider
driver which will encompass all the randomness in the various provider
drivers?This generic
driver will get all the properties and since it will be generice
anyone can use it to know what
properties to expect.This will keep the extcon design intact.
and does not seems to be a scalable solution. IMHO, the extcon should
provide a mechanism to retrieve
the cable properties. Consumer drivers can use this API to get the cable
properties without
knowing the provider driver implementation. This will make the extcon
drivers more scalable
and reusable across multiple platforms.
Hope above structure would be enough to represent the common cable
state and it's data. If a cable has more than two states, then
extcon_update_state can be used to notify the consumer 1)Provider can
just toggle the state argument to notify the consumer that cable
state is changed OR
2) Add one more argument like extcon_update_state(struct extcon_dev
*edev, u32 mask, u32 state1, u32 sate2)
This will cause other drivers to change such as arizona.
If the state2 is set, then consumers can use get_cable_properties() to
query the cable properties. State2 need to be used only if the cable
need to represent more than two state
Third,
If we finish to decide the properties for all cables, I'd like to
see a example
Why do we think that state and property is the only thing which the
consumer want to know?I am sure there would be some more properties
which would be of some interest to consumers and there is quite a possibility
that in future we might get a patch for that also.So instead of
RE: [PATCH] extcon : callback function to read cable property
> > > 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 cable. The following structure depend on
> > > only charger cable. We can check it the following structure:
> > > struct extcon_chrg_cbl_props {
> > > enum extcon_chrgr_cbl_stat cable_state;
> > > unsigned long mA;
> > > };
> > >
> > > I think that the patch have to support all of cables for property feature.
> >
> > My suggestion is to have a structure like this
> >
> > struct extcon_cablel_props {
> > unsigned int cable_state;
> > unsigned int data;
> Why can't it be float/long/double??
> > }
> > Not all cables will have more than two states. If any cable has more
> > than two states, the above structure makes it flexible to represent
> > additional state and the data associated
> >
> > >
> > > Second,
> > > Certainly, you should define common properties of all cables and
> > > specific properties of each cable. The properties of charger cable
> > > should never be defined only.
> IMHO the extcon doesn't know anything about the cable except the state
> which is currently it is in and which also is set by the provider.I am unable
> to
> understand why should extcon provide more than what it knows?It should
> just limit itself to broadcasting the cable state and exploiting it for any
> other
> information would only lead to more un-necessary code.
> It should be same as IIO subsystem where the consumer and provider knows
> before hand what information they are going to share and with what
> precision and IIO core is just a way to do that.It doesn't know anything
> beyond what is given by the provider.
> Same is the case with driver core where individual driver sets it's own
> private
> data and the driver core just gives that private data back to the driver as
> and
> when it needs but parsing the private data in the right way is up to the
> individual driver.
>
> I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to extend the Power
Supply
class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically. Do you find
a better
but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other subsystem
which gives
cable notifications. IMHO, it's good if we can avoid consumer and provider
driver level
dependencies just by extending extcon. This will ensure that the same driver
will work on any platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon consumer and
provider.
When we do like that, the extcon consumer is expecting the
similar implementation for the provider on all platforms. This may not be
possible
and does not seems to be a scalable solution. IMHO, the extcon should provide
a mechanism to retrieve
the cable properties. Consumer drivers can use this API to get the cable
properties without
knowing the provider driver implementation. This will make the extcon drivers
more scalable
and reusable across multiple platforms.
> >
> > Hope above structure would be enough to represent the common cable
> > state and it's data. If a cable has more than two states, then
> > extcon_update_state can be used to notify the consumer 1)Provider can
> > just toggle the "state" argument to notify the consumer that cable
> > state is changed OR
> > 2) Add one more argument like extcon_update_state(struct extcon_dev
> > *edev, u32 mask, u32 state1, u32 sate2)
> This will cause other drivers to change such as arizona.
> > If the state2 is set, then consumers can use get_cable_properties() to
> > query the cable properties. State2 need to be used only if the cable
> > need to represent more than two state
> >
> > >
> > > Third,
> > > If we finish to decide the properties for all cables, I'd like to
> > > see a example
> Why do we think that state and property is the only thing which the
> consumer want to know?I am sure there would be some more properties
> which would be of some interest to consumers and there is quite a possibility
> that in future we might get a patch for that also.So instead of that limiting
> it
> to just state is a good idea.
> > > code.
> >
> > Agreed. If we agree on the above structure, I can modify the charging
> > subsystem patch to use the same structure.
> > (https://lkml.org/lkml/2012/10/18/219). This would give a reference for the
> new feature.
> >
> > >
> > > You explained following changed state of USB according to Host state
> > > on other patch.
> > >
RE: [PATCH] extcon : callback function to read cable property
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 cable. The following structure depend on
only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has more
than two states, the above structure makes it flexible to represent
additional state and the data associated
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger cable
should never be defined only.
IMHO the extcon doesn't know anything about the cable except the state
which is currently it is in and which also is set by the provider.I am unable
to
understand why should extcon provide more than what it knows?It should
just limit itself to broadcasting the cable state and exploiting it for any
other
information would only lead to more un-necessary code.
It should be same as IIO subsystem where the consumer and provider knows
before hand what information they are going to share and with what
precision and IIO core is just a way to do that.It doesn't know anything
beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's own
private
data and the driver core just gives that private data back to the driver as
and
when it needs but parsing the private data in the right way is up to the
individual driver.
I fail to understand why is not the case here.
The requirement is different from the IIO case. I am trying to extend the Power
Supply
class to support charging in a generic way
(https://lkml.org/lkml/2012/10/18/219).
The extcon consumer in this case is not a device driver. It's part of power
supply class driver itself.
I am open to any solution to get the cable properties dynamically. Do you find
a better
but generic mechanism for this?
I am trying to extend extcon just because I couldn’t find any other subsystem
which gives
cable notifications. IMHO, it's good if we can avoid consumer and provider
driver level
dependencies just by extending extcon. This will ensure that the same driver
will work on any platform as long as it's having the dependency only on extcon.
We shouldn't put any driver level dependency between extcon consumer and
provider.
When we do like that, the extcon consumer is expecting the
similar implementation for the provider on all platforms. This may not be
possible
and does not seems to be a scalable solution. IMHO, the extcon should provide
a mechanism to retrieve
the cable properties. Consumer drivers can use this API to get the cable
properties without
knowing the provider driver implementation. This will make the extcon drivers
more scalable
and reusable across multiple platforms.
Hope above structure would be enough to represent the common cable
state and it's data. If a cable has more than two states, then
extcon_update_state can be used to notify the consumer 1)Provider can
just toggle the state argument to notify the consumer that cable
state is changed OR
2) Add one more argument like extcon_update_state(struct extcon_dev
*edev, u32 mask, u32 state1, u32 sate2)
This will cause other drivers to change such as arizona.
If the state2 is set, then consumers can use get_cable_properties() to
query the cable properties. State2 need to be used only if the cable
need to represent more than two state
Third,
If we finish to decide the properties for all cables, I'd like to
see a example
Why do we think that state and property is the only thing which the
consumer want to know?I am sure there would be some more properties
which would be of some interest to consumers and there is quite a possibility
that in future we might get a patch for that also.So instead of that limiting
it
to just state is a good idea.
code.
Agreed. If we agree on the above structure, I can modify the charging
subsystem patch to use the same structure.
(https://lkml.org/lkml/2012/10/18/219). This would give a reference for the
new feature.
You explained following changed state of USB according to Host state
on other patch.
---
For USB2.0
1) CONNECT (100mA)-UPDATE(500mA)-DISCONNECT(0mA)
2) CONNECT (100mA)-UPDATE(500mA)-HOST
SUSPEND(2.5mA/500mA)-
RE: [PATCH] extcon : callback function to read cable property
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 properties of charger cable but, never support
> > property of other cable. The following structure depend on only charger
> > cable. We can check it the following structure:
> > struct extcon_chrg_cbl_props {
> > enum extcon_chrgr_cbl_stat cable_state;
> > unsigned long mA;
> > };
> >
> > I think that the patch have to support all of cables for property feature.
>
> My suggestion is to have a structure like this
>
> struct extcon_cablel_props {
> unsigned int cable_state;
> unsigned int data;
Why can't it be float/long/double??
> }
> Not all cables will have more than two states. If any cable has more than two
> states,
> the above structure makes it flexible to represent additional state and the
> data associated
>
> >
> > Second,
> > Certainly, you should define common properties of all cables and specific
> > properties of each cable. The properties of charger cable should never be
> > defined only.
IMHO the extcon doesn't know anything about the cable except the state
which is currently it is in and which also is set by the provider.I am
unable to understand why should extcon provide more than what it
knows?It should just limit itself to broadcasting the cable state and
exploiting it for any other information would only lead to more
un-necessary code.
It should be same as IIO subsystem where the consumer and provider knows
before hand what information they are going to share and with what
precision and IIO core is just a way to do that.It doesn't know anything
beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's own
private data and the driver core just gives that private data back to
the driver as and when it needs but parsing the private data in the
right way is up to the individual driver.
I fail to understand why is not the case here.
>
> Hope above structure would be enough to represent the common cable state and
> it's data. If a cable has more than two states, then extcon_update_state can
> be used to
> notify the consumer
> 1)Provider can just toggle the "state" argument to notify the consumer that
> cable state is
> changed
> OR
> 2) Add one more argument like extcon_update_state(struct extcon_dev *edev,
> u32 mask, u32 state1, u32 sate2)
This will cause other drivers to change such as arizona.
> If the state2 is set, then consumers can use get_cable_properties() to query
> the cable properties. State2 need to be
> used only if the cable need to represent more than two state
>
> >
> > Third,
> > If we finish to decide the properties for all cables, I'd like to see a
> > example
Why do we think that state and property is the only thing which the
consumer want to know?I am sure there would be some more properties
which would be of some interest to consumers and there is quite a
possibility that in future we might get a patch for that also.So instead
of that limiting it to just state is a good idea.
> > code.
>
> Agreed. If we agree on the above structure, I can modify the charging
> subsystem patch
> to use the same structure. (https://lkml.org/lkml/2012/10/18/219). This would
> give a reference
> for the new feature.
>
> >
> > You explained following changed state of USB according to Host state on
> > other patch.
> > ---
> > For USB2.0
> > 1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA)
> > 2) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)-
> > >DISCONNECT(0mA)
> > 3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)-
> > >HOST RESUME(500mA)->DISCONNECT(0mA)
> >
> > For USB 3.0
> > 4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA)
> > 5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)-
> > >DISCONNECT(0mA)
> > 6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)-
> > >HOST RESUME(900mA)->DISCONNECT(0mA)
> > ---
> >
> > I have a question. Can the provider device driver(e.g., extcon-max77693.c/
> > extcon-max8997.c) detect the changed state of host? I'd like to see the
> > example device driver that the provider device driver detect changed state
> > of host.
> > Could you provide example device driver?
>
> Good question. The OTG drivers are capable of identifying the SUSPEND event.
> System cannot setup SDP (USB host) charging with maximum charging current -
> 500mA
> (USB2.0/ 900mA(USB 3)) without enumerating the USB. The USB enumeration can be
> done only with a USB/OTG driver. IMHO the above extcon drivers
> (extcon-max77693.c/ extcon-max8997.c) are not capable of doing the USB
> enumeration
> and identifying the charge current. They can just identify the charger type -
>
RE: [PATCH] extcon : callback function to read cable property
> 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 cable. The following structure depend on only charger
> cable. We can check it the following structure:
> struct extcon_chrg_cbl_props {
> enum extcon_chrgr_cbl_stat cable_state;
> unsigned long mA;
> };
>
> I think that the patch have to support all of cables for property feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
Not all cables will have more than two states. If any cable has more than two
states,
the above structure makes it flexible to represent additional state and the
data associated
>
> Second,
> Certainly, you should define common properties of all cables and specific
> properties of each cable. The properties of charger cable should never be
> defined only.
Hope above structure would be enough to represent the common cable state and
it's data. If a cable has more than two states, then extcon_update_state can be
used to
notify the consumer
1)Provider can just toggle the "state" argument to notify the consumer that
cable state is
changed
OR
2) Add one more argument like extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state1, u32 sate2)
If the state2 is set, then consumers can use get_cable_properties() to query
the cable properties. State2 need to be
used only if the cable need to represent more than two state
>
> Third,
> If we finish to decide the properties for all cables, I'd like to see a
> example
> code.
Agreed. If we agree on the above structure, I can modify the charging
subsystem patch
to use the same structure. (https://lkml.org/lkml/2012/10/18/219). This would
give a reference
for the new feature.
>
> You explained following changed state of USB according to Host state on
> other patch.
> ---
> For USB2.0
> 1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA)
> 2) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)-
> >DISCONNECT(0mA)
> 3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)-
> >HOST RESUME(500mA)->DISCONNECT(0mA)
>
> For USB 3.0
> 4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA)
> 5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)-
> >DISCONNECT(0mA)
> 6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)-
> >HOST RESUME(900mA)->DISCONNECT(0mA)
> ---
>
> I have a question. Can the provider device driver(e.g., extcon-max77693.c/
> extcon-max8997.c) detect the changed state of host? I'd like to see the
> example device driver that the provider device driver detect changed state
> of host.
> Could you provide example device driver?
Good question. The OTG drivers are capable of identifying the SUSPEND event.
System cannot setup SDP (USB host) charging with maximum charging current -
500mA
(USB2.0/ 900mA(USB 3)) without enumerating the USB. The USB enumeration can be
done only with a USB/OTG driver. IMHO the above extcon drivers
(extcon-max77693.c/ extcon-max8997.c) are not capable of doing the USB
enumeration
and identifying the charge current. They can just identify the charger type -
SDP/DCP/CDP/ACA/AC. The intelligence for USB enumeration
should be inside USB/OTG driver.
RE: [PATCH] extcon : callback function to read cable property
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 cable. The following structure depend on only charger
cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
}
Not all cables will have more than two states. If any cable has more than two
states,
the above structure makes it flexible to represent additional state and the
data associated
Second,
Certainly, you should define common properties of all cables and specific
properties of each cable. The properties of charger cable should never be
defined only.
Hope above structure would be enough to represent the common cable state and
it's data. If a cable has more than two states, then extcon_update_state can be
used to
notify the consumer
1)Provider can just toggle the state argument to notify the consumer that
cable state is
changed
OR
2) Add one more argument like extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state1, u32 sate2)
If the state2 is set, then consumers can use get_cable_properties() to query
the cable properties. State2 need to be
used only if the cable need to represent more than two state
Third,
If we finish to decide the properties for all cables, I'd like to see a
example
code.
Agreed. If we agree on the above structure, I can modify the charging
subsystem patch
to use the same structure. (https://lkml.org/lkml/2012/10/18/219). This would
give a reference
for the new feature.
You explained following changed state of USB according to Host state on
other patch.
---
For USB2.0
1) CONNECT (100mA)-UPDATE(500mA)-DISCONNECT(0mA)
2) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-
DISCONNECT(0mA)
3) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-
HOST RESUME(500mA)-DISCONNECT(0mA)
For USB 3.0
4) CONNECT (150mA)-UPDATE(900mA)-DISCONNECT(0mA)
5) CONNECT (150mA)-UPDATE(900mA)- HOST SUSPEND(2.5mA/900mA)-
DISCONNECT(0mA)
6) CONNECT (100mA)-UPDATE(900mA)-HOST SUSPEND(2.5mA/900mA)-
HOST RESUME(900mA)-DISCONNECT(0mA)
---
I have a question. Can the provider device driver(e.g., extcon-max77693.c/
extcon-max8997.c) detect the changed state of host? I'd like to see the
example device driver that the provider device driver detect changed state
of host.
Could you provide example device driver?
Good question. The OTG drivers are capable of identifying the SUSPEND event.
System cannot setup SDP (USB host) charging with maximum charging current -
500mA
(USB2.0/ 900mA(USB 3)) without enumerating the USB. The USB enumeration can be
done only with a USB/OTG driver. IMHO the above extcon drivers
(extcon-max77693.c/ extcon-max8997.c) are not capable of doing the USB
enumeration
and identifying the charge current. They can just identify the charger type -
SDP/DCP/CDP/ACA/AC. The intelligence for USB enumeration
should be inside USB/OTG driver.
RE: [PATCH] extcon : callback function to read cable property
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 properties of charger cable but, never support
property of other cable. The following structure depend on only charger
cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property feature.
My suggestion is to have a structure like this
struct extcon_cablel_props {
unsigned int cable_state;
unsigned int data;
Why can't it be float/long/double??
}
Not all cables will have more than two states. If any cable has more than two
states,
the above structure makes it flexible to represent additional state and the
data associated
Second,
Certainly, you should define common properties of all cables and specific
properties of each cable. The properties of charger cable should never be
defined only.
IMHO the extcon doesn't know anything about the cable except the state
which is currently it is in and which also is set by the provider.I am
unable to understand why should extcon provide more than what it
knows?It should just limit itself to broadcasting the cable state and
exploiting it for any other information would only lead to more
un-necessary code.
It should be same as IIO subsystem where the consumer and provider knows
before hand what information they are going to share and with what
precision and IIO core is just a way to do that.It doesn't know anything
beyond what is given by the provider.
Same is the case with driver core where individual driver sets it's own
private data and the driver core just gives that private data back to
the driver as and when it needs but parsing the private data in the
right way is up to the individual driver.
I fail to understand why is not the case here.
Hope above structure would be enough to represent the common cable state and
it's data. If a cable has more than two states, then extcon_update_state can
be used to
notify the consumer
1)Provider can just toggle the state argument to notify the consumer that
cable state is
changed
OR
2) Add one more argument like extcon_update_state(struct extcon_dev *edev,
u32 mask, u32 state1, u32 sate2)
This will cause other drivers to change such as arizona.
If the state2 is set, then consumers can use get_cable_properties() to query
the cable properties. State2 need to be
used only if the cable need to represent more than two state
Third,
If we finish to decide the properties for all cables, I'd like to see a
example
Why do we think that state and property is the only thing which the
consumer want to know?I am sure there would be some more properties
which would be of some interest to consumers and there is quite a
possibility that in future we might get a patch for that also.So instead
of that limiting it to just state is a good idea.
code.
Agreed. If we agree on the above structure, I can modify the charging
subsystem patch
to use the same structure. (https://lkml.org/lkml/2012/10/18/219). This would
give a reference
for the new feature.
You explained following changed state of USB according to Host state on
other patch.
---
For USB2.0
1) CONNECT (100mA)-UPDATE(500mA)-DISCONNECT(0mA)
2) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-
DISCONNECT(0mA)
3) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-
HOST RESUME(500mA)-DISCONNECT(0mA)
For USB 3.0
4) CONNECT (150mA)-UPDATE(900mA)-DISCONNECT(0mA)
5) CONNECT (150mA)-UPDATE(900mA)- HOST SUSPEND(2.5mA/900mA)-
DISCONNECT(0mA)
6) CONNECT (100mA)-UPDATE(900mA)-HOST SUSPEND(2.5mA/900mA)-
HOST RESUME(900mA)-DISCONNECT(0mA)
---
I have a question. Can the provider device driver(e.g., extcon-max77693.c/
extcon-max8997.c) detect the changed state of host? I'd like to see the
example device driver that the provider device driver detect changed state
of host.
Could you provide example device driver?
Good question. The OTG drivers are capable of identifying the SUSPEND event.
System cannot setup SDP (USB host) charging with maximum charging current -
500mA
(USB2.0/ 900mA(USB 3)) without enumerating the USB. The USB enumeration can be
done only with a USB/OTG driver. IMHO the above extcon drivers
(extcon-max77693.c/ extcon-max8997.c) are not capable of doing the USB
enumeration
and identifying the charge current. They can just identify the charger type -
SDP/DCP/CDP/ACA/AC. The intelligence for USB enumeration
should be inside USB/OTG driver.
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH] extcon : callback function to read cable property
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 with the cable such as
>>>> finding which state it is in and other details.
>>>> So I feel this should not be handled in the extcon.
>>>>
>>>> However it is up to the maintainer to decide.
>>>
>>> Once the consumer gets the notification, it needs to take some action.
>>> One of the action is to read the cable properties. This can be done by
>>> proprietary calls which is known both to the consumer and the provider.
>>> My intention is to avoid this proprietary calls. Since both the
>>> provider and consumer are communicating with the extcon subsystem , I
>>> feel having a callback function of this kind would help to avoid the
>>> use of proprietary calls. Also I agree that extcon notifier chains are
>>> used to notify the cable state (attach/detach). But if a cable has
>>> more than two states (like the charger cable) how do we support it without
>> having a callback function like this?
>>> Let the maintainer take the final decision.
>> Well this use case will keep on growing if we start factor in this kind of
>> changes and that is why I am opposed to adding any other state.
>> Maintainer?
>>>
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 cable. The following structure depend on
only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property feature.
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger cable
should never be defined only.
Third,
If we finish to decide the properties for all cables, I'd like to see a example
code.
You explained following changed state of USB according to Host state on other
patch.
---
For USB2.0
1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA)
2) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)->DISCONNECT(0mA)
3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)->HOST
RESUME(500mA)->DISCONNECT(0mA)
For USB 3.0
4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA)
5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)->DISCONNECT(0mA)
6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)->HOST
RESUME(900mA)->DISCONNECT(0mA)
---
I have a question. Can the provider device driver(e.g., extcon-max77693.c/
extcon-max8997.c) detect the changed state of host? I'd like to see the
example device driver that the provider device driver detect changed state of
host.
Could you provide example device driver?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 with the cable such as
finding which state it is in and other details.
So I feel this should not be handled in the extcon.
However it is up to the maintainer to decide.
Once the consumer gets the notification, it needs to take some action.
One of the action is to read the cable properties. This can be done by
proprietary calls which is known both to the consumer and the provider.
My intention is to avoid this proprietary calls. Since both the
provider and consumer are communicating with the extcon subsystem , I
feel having a callback function of this kind would help to avoid the
use of proprietary calls. Also I agree that extcon notifier chains are
used to notify the cable state (attach/detach). But if a cable has
more than two states (like the charger cable) how do we support it without
having a callback function like this?
Let the maintainer take the final decision.
Well this use case will keep on growing if we start factor in this kind of
changes and that is why I am opposed to adding any other state.
Maintainer?
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 cable. The following structure depend on
only charger cable. We can check it the following structure:
struct extcon_chrg_cbl_props {
enum extcon_chrgr_cbl_stat cable_state;
unsigned long mA;
};
I think that the patch have to support all of cables for property feature.
Second,
Certainly, you should define common properties of all cables and
specific properties of each cable. The properties of charger cable
should never be defined only.
Third,
If we finish to decide the properties for all cables, I'd like to see a example
code.
You explained following changed state of USB according to Host state on other
patch.
---
For USB2.0
1) CONNECT (100mA)-UPDATE(500mA)-DISCONNECT(0mA)
2) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-DISCONNECT(0mA)
3) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-HOST
RESUME(500mA)-DISCONNECT(0mA)
For USB 3.0
4) CONNECT (150mA)-UPDATE(900mA)-DISCONNECT(0mA)
5) CONNECT (150mA)-UPDATE(900mA)- HOST SUSPEND(2.5mA/900mA)-DISCONNECT(0mA)
6) CONNECT (100mA)-UPDATE(900mA)-HOST SUSPEND(2.5mA/900mA)-HOST
RESUME(900mA)-DISCONNECT(0mA)
---
I have a question. Can the provider device driver(e.g., extcon-max77693.c/
extcon-max8997.c) detect the changed state of host? I'd like to see the
example device driver that the provider device driver detect changed state of
host.
Could you provide example device driver?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: RE: [PATCH] extcon : callback function to read cable property
Myunjoo, Ping. Could you please have a look at my response below? -jtc > -Original Message- > From: Tc, Jenny > Sent: Thursday, October 25, 2012 2:55 PM > To: myungjoo@samsung.com; ??? > Cc: linux-kernel@vger.kernel.org; anish kumar > Subject: RE: RE: [PATCH] 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. > > > > > > I understand your point on extcon role. But my concern is, when the > > > consumer driver gets a notification on cable state change, how does > > > the consumer query the cable properties in a generic way. Do you > > > have any > > suggestions for this? > > > > > > A use case can be as below > > > > > > When a USB host cable (SDP) connected to the platform, without USB > > > enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) > > > (As > > per USB charging spec). > > > Once the enumeration is done this can be 500mA/950mA. If the > > > consumer charger driver need to configure the charger chip, it need > > > to know the > > charger cable capabilities. > > > For example a platform PLAT1 may have charger driver CHRGR1 and OTG > > driver OTG1. > > > But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How > > > CHGR1 driver can detect the cable properties without having any > > > platform layer hooks? The platform layer hooks (using platform > > > data)will work only if the consumer is a platform driver. What if > > > it's a > > framework which will have the same flow in all platforms? > > > > In general, > > an extcon user (extcon notifee) knows who's the extcon notifier; the > > user is supposed to know the name of the notifier. > > > > Thus, the extcon user should be able to get the appropriate object; > > i.e., a regulator struct in this case. Then, according to the USB > > state, the current limit of the USB can be changed by the notifier; > > which may notify (regulator subsystem has one) the extcon user to > > react (change current limit of > > charger?) > > The flow we have is "notifier (OTG driver/cable notifier driver) -> extcon-> > charging framework->charger driver" > > When the framework gets notification from the extcon, it just know cable is > connected/disconnected > > For a USB charging the state machine can be > > For USB2.0 > 1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA) > 2)CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)- > >DISCONNECT(0mA) > 3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)- > >HOST RESUME(500mA)->DISCONNECT(0mA) > > For USB 3.0 > 4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA) > 5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)- > >DISCONNECT(0mA) > 6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)- > >HOST RESUME(900mA)->DISCONNECT(0mA) > > > > > Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator > > controlling the charger current and if the OTG2 regulator affects the > > behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the > > consumer- supplier chain should be setup (if the BSP is ideal). > > > > OR > > > > If it is impossible to have any objects of OTG2 (looks strange, > > but..), you may have two cables, USB (data) and Fast-charger.04 (add > > +400mA to USB), where Fast-charger.04 is enabled when USB2 > enumeration > > is done with 5 > > I got your point. It's not just 2 cables we may need 4 cables to support > USB2.0 > and USB3.0 since the charge current can be 100/500 for USB2.0 and 150/900 > for USB 3.0. But what about the states? > > . > > > > > > > > However, the following callback might be considered if there are cases > > where an extcon user has information of extcon_name and cable_name > > while the user CANNOT get any information on which device or object is > > related with the specific cable; in struct extcon, with optional user > > initializing data section: > > > > + struct device **cable_device; > > OR > > + char **cable_device_name; > > > > With any relevant changes in the status with cable_device, we may > > notify any notifier-block that are interested in the specific cable. > > Then, the notifier- block (for register_interest) is going
RE: RE: [PATCH] extcon : callback function to read cable property
Myunjoo, Ping. Could you please have a look at my response below? -jtc -Original Message- From: Tc, Jenny Sent: Thursday, October 25, 2012 2:55 PM To: myungjoo@samsung.com; ??? Cc: linux-kernel@vger.kernel.org; anish kumar Subject: RE: RE: [PATCH] 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. I understand your point on extcon role. But my concern is, when the consumer driver gets a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any suggestions for this? A use case can be as below When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec). Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the charger cable capabilities. For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1. But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a framework which will have the same flow in all platforms? In general, an extcon user (extcon notifee) knows who's the extcon notifier; the user is supposed to know the name of the notifier. Thus, the extcon user should be able to get the appropriate object; i.e., a regulator struct in this case. Then, according to the USB state, the current limit of the USB can be changed by the notifier; which may notify (regulator subsystem has one) the extcon user to react (change current limit of charger?) The flow we have is notifier (OTG driver/cable notifier driver) - extcon- charging framework-charger driver When the framework gets notification from the extcon, it just know cable is connected/disconnected For a USB charging the state machine can be For USB2.0 1) CONNECT (100mA)-UPDATE(500mA)-DISCONNECT(0mA) 2)CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)- DISCONNECT(0mA) 3) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)- HOST RESUME(500mA)-DISCONNECT(0mA) For USB 3.0 4) CONNECT (150mA)-UPDATE(900mA)-DISCONNECT(0mA) 5) CONNECT (150mA)-UPDATE(900mA)- HOST SUSPEND(2.5mA/900mA)- DISCONNECT(0mA) 6) CONNECT (100mA)-UPDATE(900mA)-HOST SUSPEND(2.5mA/900mA)- HOST RESUME(900mA)-DISCONNECT(0mA) Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator controlling the charger current and if the OTG2 regulator affects the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer- supplier chain should be setup (if the BSP is ideal). OR If it is impossible to have any objects of OTG2 (looks strange, but..), you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), where Fast-charger.04 is enabled when USB2 enumeration is done with 5 I got your point. It's not just 2 cables we may need 4 cables to support USB2.0 and USB3.0 since the charge current can be 100/500 for USB2.0 and 150/900 for USB 3.0. But what about the states? . However, the following callback might be considered if there are cases where an extcon user has information of extcon_name and cable_name while the user CANNOT get any information on which device or object is related with the specific cable; in struct extcon, with optional user initializing data section: + struct device **cable_device; OR + char **cable_device_name; With any relevant changes in the status with cable_device, we may notify any notifier-block that are interested in the specific cable. Then, the notifier- block (for register_interest) is going to handle extcon-state changes and cable_device notifications. Currently, the user's nb is for cable attach/detach events with true/false value in the place of 32bit value (val). However, if we add the third possible value for that parameter (0: cable detached, 1: cable attached, 2: cable status changed; go find out what's going on), it is still compatible. I considered using a void pointer instead of cable_device, too. However, that would spoil the subsystem too much; we'll be creating a total chaos: USB-A driver uses struct regulator, USB-B driver uses struct device, USB-C driver uses true/false, and so on. But just by getting the device instance how do we extract the cable properties like cable state and the charge current in a generic way? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message
RE: RE: [PATCH] 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. > > > > I understand your point on extcon role. But my concern is, when the > > consumer driver gets a notification on cable state change, how does > > the consumer query the cable properties in a generic way. Do you have any > suggestions for this? > > > > A use case can be as below > > > > When a USB host cable (SDP) connected to the platform, without USB > > enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As > per USB charging spec). > > Once the enumeration is done this can be 500mA/950mA. If the consumer > > charger driver need to configure the charger chip, it need to know the > charger cable capabilities. > > For example a platform PLAT1 may have charger driver CHRGR1 and OTG > driver OTG1. > > But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How > > CHGR1 driver can detect the cable properties without having any > > platform layer hooks? The platform layer hooks (using platform > > data)will work only if the consumer is a platform driver. What if it's a > framework which will have the same flow in all platforms? > > In general, > an extcon user (extcon notifee) knows who's the extcon notifier; the user is > supposed to know the name of the notifier. > > Thus, the extcon user should be able to get the appropriate object; i.e., a > regulator struct in this case. Then, according to the USB state, the current > limit of the USB can be changed by the notifier; which may notify (regulator > subsystem has one) the extcon user to react (change current limit of > charger?) The flow we have is "notifier (OTG driver/cable notifier driver) -> extcon-> charging framework->charger driver" When the framework gets notification from the extcon, it just know cable is connected/disconnected For a USB charging the state machine can be For USB2.0 1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA) 2)CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)->DISCONNECT(0mA) 3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)->HOST RESUME(500mA)->DISCONNECT(0mA) For USB 3.0 4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA) 5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)->DISCONNECT(0mA) 6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)->HOST RESUME(900mA)->DISCONNECT(0mA) > > Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator > controlling the charger current and if the OTG2 regulator affects the behavior > of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer- > supplier chain should be setup (if the BSP is ideal). > > OR > > If it is impossible to have any objects of OTG2 (looks strange, but..), you > may > have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), > where Fast-charger.04 is enabled when USB2 enumeration is done with 5 I got your point. It's not just 2 cables we may need 4 cables to support USB2.0 and USB3.0 since the charge current can be 100/500 for USB2.0 and 150/900 for USB 3.0. But what about the states? . > > > > However, the following callback might be considered if there are cases > where an extcon user has information of extcon_name and cable_name > while the user CANNOT get any information on which device or object is > related with the specific cable; in struct extcon, with optional user > initializing > data section: > > + struct device **cable_device; > OR > + char **cable_device_name; > > With any relevant changes in the status with cable_device, we may notify > any notifier-block that are interested in the specific cable. Then, the > notifier- > block (for register_interest) is going to handle extcon-state changes and > cable_device notifications. > > Currently, the user's nb is for cable attach/detach events with true/false > value in the place of 32bit value (val). However, if we add the third possible > value for that parameter > (0: cable detached, 1: cable attached, 2: cable status changed; go find out > what's going on), it is still compatible. > > I considered using a void pointer instead of cable_device, too. > However, that would spoil the subsystem too much; we'll be creating a total > chaos: "USB-A driver uses struct regulator", "USB-B driver uses struct > device", "USB-C driver uses true/false", and so on. But just by getting the device instance how do we extract the cable properties like cable state and the charge current in a generic way?
Re: 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: > > 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 through extcon, extcon consumer driver or framework should > > get the additional information of cable from other device driver except of > > extcon. > > > > Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG- > > USB-OFF, Dock) What are common properties among many cables expect > > attached or detached state? > > > > 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 a notification on cable state change, how does the consumer query > the > cable properties in a generic way. Do you have any suggestions for this? > > A use case can be as below > > When a USB host cable (SDP) connected to the platform, without USB enumeration > it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging > spec). > Once the enumeration is done this can be 500mA/950mA. If the consumer charger > driver > need to configure the charger chip, it need to know the charger cable > capabilities. > For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver > OTG1. > But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How > CHGR1 driver can detect the cable properties without having any platform > layer > hooks? The platform layer hooks (using platform data)will work only if the > consumer is > a platform driver. What if it's a framework which will have the same flow in > all platforms? In general, an extcon user (extcon notifee) knows who's the extcon notifier; the user is supposed to know the name of the notifier. Thus, the extcon user should be able to get the appropriate object; i.e., a regulator struct in this case. Then, according to the USB state, the current limit of the USB can be changed by the notifier; which may notify (regulator subsystem has one) the extcon user to react (change current limit of charger?) Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator controlling the charger current and if the OTG2 regulator affects the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer-supplier chain should be setup (if the BSP is ideal). OR If it is impossible to have any objects of OTG2 (looks strange, but..), you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), where Fast-charger.04 is enabled when USB2 enumeration is done with 5. However, the following callback might be considered if there are cases where an extcon user has information of extcon_name and cable_name while the user CANNOT get any information on which device or object is related with the specific cable; in struct extcon, with optional user initializing data section: + struct device **cable_device; OR + char **cable_device_name; With any relevant changes in the status with cable_device, we may notify any notifier-block that are interested in the specific cable. Then, the notifier-block (for register_interest) is going to handle extcon-state changes and cable_device notifications. Currently, the user's nb is for cable attach/detach events with true/false value in the place of 32bit value (val). However, if we add the third possible value for that parameter (0: cable detached, 1: cable attached, 2: cable status changed; go find out what's going on), it is still compatible. I considered using a void pointer instead of cable_device, too. However, that would spoil the subsystem too much; we'll be creating a total chaos: "USB-A driver uses struct regulator", "USB-B driver uses struct device", "USB-C driver uses true/false", and so on. Cheers, MyungJoo
Re: 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: 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 through extcon, extcon consumer driver or framework should get the additional information of cable from other device driver except of extcon. Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG- USB-OFF, Dock) What are common properties among many cables expect attached or detached state? 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 a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any suggestions for this? A use case can be as below When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec). Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the charger cable capabilities. For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1. But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a framework which will have the same flow in all platforms? In general, an extcon user (extcon notifee) knows who's the extcon notifier; the user is supposed to know the name of the notifier. Thus, the extcon user should be able to get the appropriate object; i.e., a regulator struct in this case. Then, according to the USB state, the current limit of the USB can be changed by the notifier; which may notify (regulator subsystem has one) the extcon user to react (change current limit of charger?) Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator controlling the charger current and if the OTG2 regulator affects the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer-supplier chain should be setup (if the BSP is ideal). OR If it is impossible to have any objects of OTG2 (looks strange, but..), you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), where Fast-charger.04 is enabled when USB2 enumeration is done with 5. However, the following callback might be considered if there are cases where an extcon user has information of extcon_name and cable_name while the user CANNOT get any information on which device or object is related with the specific cable; in struct extcon, with optional user initializing data section: + struct device **cable_device; OR + char **cable_device_name; With any relevant changes in the status with cable_device, we may notify any notifier-block that are interested in the specific cable. Then, the notifier-block (for register_interest) is going to handle extcon-state changes and cable_device notifications. Currently, the user's nb is for cable attach/detach events with true/false value in the place of 32bit value (val). However, if we add the third possible value for that parameter (0: cable detached, 1: cable attached, 2: cable status changed; go find out what's going on), it is still compatible. I considered using a void pointer instead of cable_device, too. However, that would spoil the subsystem too much; we'll be creating a total chaos: USB-A driver uses struct regulator, USB-B driver uses struct device, USB-C driver uses true/false, and so on. Cheers, MyungJoo
RE: RE: [PATCH] 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. I understand your point on extcon role. But my concern is, when the consumer driver gets a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any suggestions for this? A use case can be as below When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec). Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the charger cable capabilities. For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1. But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a framework which will have the same flow in all platforms? In general, an extcon user (extcon notifee) knows who's the extcon notifier; the user is supposed to know the name of the notifier. Thus, the extcon user should be able to get the appropriate object; i.e., a regulator struct in this case. Then, according to the USB state, the current limit of the USB can be changed by the notifier; which may notify (regulator subsystem has one) the extcon user to react (change current limit of charger?) The flow we have is notifier (OTG driver/cable notifier driver) - extcon- charging framework-charger driver When the framework gets notification from the extcon, it just know cable is connected/disconnected For a USB charging the state machine can be For USB2.0 1) CONNECT (100mA)-UPDATE(500mA)-DISCONNECT(0mA) 2)CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-DISCONNECT(0mA) 3) CONNECT (100mA)-UPDATE(500mA)-HOST SUSPEND(2.5mA/500mA)-HOST RESUME(500mA)-DISCONNECT(0mA) For USB 3.0 4) CONNECT (150mA)-UPDATE(900mA)-DISCONNECT(0mA) 5) CONNECT (150mA)-UPDATE(900mA)- HOST SUSPEND(2.5mA/900mA)-DISCONNECT(0mA) 6) CONNECT (100mA)-UPDATE(900mA)-HOST SUSPEND(2.5mA/900mA)-HOST RESUME(900mA)-DISCONNECT(0mA) Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator controlling the charger current and if the OTG2 regulator affects the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer- supplier chain should be setup (if the BSP is ideal). OR If it is impossible to have any objects of OTG2 (looks strange, but..), you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), where Fast-charger.04 is enabled when USB2 enumeration is done with 5 I got your point. It's not just 2 cables we may need 4 cables to support USB2.0 and USB3.0 since the charge current can be 100/500 for USB2.0 and 150/900 for USB 3.0. But what about the states? . However, the following callback might be considered if there are cases where an extcon user has information of extcon_name and cable_name while the user CANNOT get any information on which device or object is related with the specific cable; in struct extcon, with optional user initializing data section: + struct device **cable_device; OR + char **cable_device_name; With any relevant changes in the status with cable_device, we may notify any notifier-block that are interested in the specific cable. Then, the notifier- block (for register_interest) is going to handle extcon-state changes and cable_device notifications. Currently, the user's nb is for cable attach/detach events with true/false value in the place of 32bit value (val). However, if we add the third possible value for that parameter (0: cable detached, 1: cable attached, 2: cable status changed; go find out what's going on), it is still compatible. I considered using a void pointer instead of cable_device, too. However, that would spoil the subsystem too much; we'll be creating a total chaos: USB-A driver uses struct regulator, USB-B driver uses struct device, USB-C driver uses true/false, and so on. But just by getting the device instance how do we extract the cable properties like cable state and the charge current in a generic way?
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 connection and disconnection and > >>>>>> it is up to the client to decide what else to do with the cable > >>>>>> such as finding which state it is in and other details. > >>>>>> So I feel this should not be handled in the extcon. > >>>>>> > >>>>>> However it is up to the maintainer to decide. > >>>>> > >>>>> Once the consumer gets the notification, it needs to take some > action. > >>>>> One of the action is to read the cable properties. This can be > >>>>> done by proprietary calls which is known both to the consumer and > >>>>> the > >> provider. > >>>>> My intention is to avoid this proprietary calls. Since both the > >>>>> provider and consumer are communicating with the extcon > subsystem > >>>>> , I feel having a callback function of this kind would help to > >>>>> avoid the use of proprietary calls. Also I agree that extcon > >>>>> notifier chains are used to notify the cable state > >>>>> (attach/detach). But if a cable has more than two states (like the > >>>>> charger cable) how do we support it without > >>>> having a callback function like this? > >>>>> Let the maintainer take the final decision. > >>>> Well this use case will keep on growing if we start factor in this > >>>> kind of changes and that is why I am opposed to adding any other > state. > >>>> Maintainer? > >>>>> > >>>>> > >>>> > >> > >> Hello, > >> > >> > >> I don't think it's appropriate to declare the charger specific > >> properties in extcon.h. The status of a charger should be and can be > >> represented by an instance of regulator, power-supply-class, or charger- > manager. > >> > > Agreed. We can move this to power supply subsystem. > > > >> Thus, we may (I'm still not sure) need to let extcon to relay the > >> instance (struct device? or char *devname?) with some callback > >> similar with get_cable_device(). However, allowing (and encouraging) > >> to pass void pointer of cable_props to extcon users from extcon > >> device appears not adequete. If the both parties can use their own > "private" > >> data structure, why they cannot simply pass their own data witht the > >> "private" data channel? > >> > >> > >> Recap: > >> - The later part of patch: NACK > >> - The first part of patch (callback): need to reconsider the data type. > >> We may get device pointer or device name that is correspondant to the > >> cable, which in turn, guides us to the corresponding data structure > >> (charger- manager, regulator, or something) However, I'm still not > >> sure which should be appropriate for this. > >> > > > > The requirement for this feature came from the implementation of the > > power supply charging framework > > (http://www.spinics.net/lists/kernel/msg1420500.html > > refer charger_cable_event_worker function). The charging framework is > > not a driver. It can be compiled with the power supply class driver to > > support charging. Also the private data structure may not provide a > > generic method for this implementation since the extcon provider > > drivers will be different in different platforms. So it's not necessary > > that the > framework knows the private data structure of the provider. > > Basically the requirement is to have a generic method to retrieve the > > cable properties without knowing the extcon provider driver internal > > implementation. Can you suggest a generic approach for this problem? > > > 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 through extcon, extcon consumer driver or framework should > get the additional information of cable from other device driver except of > extcon. > >
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 connection and disconnection and it is up to the client to decide what else to do with the cable such as finding which state it is in and other details. So I feel this should not be handled in the extcon. However it is up to the maintainer to decide. Once the consumer gets the notification, it needs to take some action. One of the action is to read the cable properties. This can be done by proprietary calls which is known both to the consumer and the provider. My intention is to avoid this proprietary calls. Since both the provider and consumer are communicating with the extcon subsystem , I feel having a callback function of this kind would help to avoid the use of proprietary calls. Also I agree that extcon notifier chains are used to notify the cable state (attach/detach). But if a cable has more than two states (like the charger cable) how do we support it without having a callback function like this? Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer? Hello, I don't think it's appropriate to declare the charger specific properties in extcon.h. The status of a charger should be and can be represented by an instance of regulator, power-supply-class, or charger- manager. Agreed. We can move this to power supply subsystem. Thus, we may (I'm still not sure) need to let extcon to relay the instance (struct device? or char *devname?) with some callback similar with get_cable_device(). However, allowing (and encouraging) to pass void pointer of cable_props to extcon users from extcon device appears not adequete. If the both parties can use their own private data structure, why they cannot simply pass their own data witht the private data channel? Recap: - The later part of patch: NACK - The first part of patch (callback): need to reconsider the data type. We may get device pointer or device name that is correspondant to the cable, which in turn, guides us to the corresponding data structure (charger- manager, regulator, or something) However, I'm still not sure which should be appropriate for this. The requirement for this feature came from the implementation of the power supply charging framework (http://www.spinics.net/lists/kernel/msg1420500.html refer charger_cable_event_worker function). The charging framework is not a driver. It can be compiled with the power supply class driver to support charging. Also the private data structure may not provide a generic method for this implementation since the extcon provider drivers will be different in different platforms. So it's not necessary that the framework knows the private data structure of the provider. Basically the requirement is to have a generic method to retrieve the cable properties without knowing the extcon provider driver internal implementation. Can you suggest a generic approach for this problem? 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 through extcon, extcon consumer driver or framework should get the additional information of cable from other device driver except of extcon. Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG- USB-OFF, Dock) What are common properties among many cables expect attached or detached state? 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 a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any suggestions for this? A use case can be as below When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec). Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the charger cable capabilities. For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1. But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a framework which will have the same flow in all platforms
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 connection and disconnection >>>>>> and it is up to the client to decide what else to do with the >>>>>> cable such as finding which state it is in and other details. >>>>>> So I feel this should not be handled in the extcon. >>>>>> >>>>>> However it is up to the maintainer to decide. >>>>> >>>>> Once the consumer gets the notification, it needs to take some action. >>>>> One of the action is to read the cable properties. This can be >>>>> done by proprietary calls which is known both to the consumer and the >> provider. >>>>> My intention is to avoid this proprietary calls. Since both the >>>>> provider and consumer are communicating with the extcon subsystem >>>>> , I feel having a callback function of this kind would help to >>>>> avoid the use of proprietary calls. Also I agree that extcon >>>>> notifier chains are used to notify the cable state >>>>> (attach/detach). But if a cable has more than two states (like the >>>>> charger cable) how do we support it without >>>> having a callback function like this? >>>>> Let the maintainer take the final decision. >>>> Well this use case will keep on growing if we start factor in this >>>> kind of changes and that is why I am opposed to adding any other state. >>>> Maintainer? >>>>> >>>>> >>>> >> >> Hello, >> >> >> I don't think it's appropriate to declare the charger specific properties in >> extcon.h. The status of a charger should be and can be represented by an >> instance of regulator, power-supply-class, or charger-manager. >> > Agreed. We can move this to power supply subsystem. > >> Thus, we may (I'm still not sure) need to let extcon to relay the instance >> (struct device? or char *devname?) with some callback similar with >> get_cable_device(). However, allowing (and encouraging) to pass void >> pointer of cable_props to extcon users from extcon device appears not >> adequete. If the both parties can use their own "private" >> data structure, why they cannot simply pass their own data witht the >> "private" data channel? >> >> >> Recap: >> - The later part of patch: NACK >> - The first part of patch (callback): need to reconsider the data type. >> We may get device pointer or device name that is correspondant to the >> cable, which in turn, guides us to the corresponding data structure (charger- >> manager, regulator, or something) However, I'm still not sure which should >> be appropriate for this. >> > > The requirement for this feature came from the implementation of the > power supply charging framework > (http://www.spinics.net/lists/kernel/msg1420500.html > refer charger_cable_event_worker function). The charging framework is not a > driver. It can > be compiled with the power supply class driver to support charging. Also the > private data structure may not provide a generic method for this > implementation > since the extcon provider drivers will be different in different platforms. > So it's not > necessary that the framework knows the private data structure of the provider. > Basically the requirement is to have a generic method to retrieve the cable > properties without > knowing the extcon provider driver internal implementation. Can you suggest a > generic approach > for this problem? > 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 through extcon, extcon consumer driver or framework should get the additional information of cable from other device driver except of extcon. Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG-USB-OFF, Dock) What are common properties among many cables expect attached or detached state? > Also the cable states we support in extcon (attach/detach) is not sufficient > to support the cable states of a charger cable which can have more than 2 > states. The charger cable > states can be (1)attach/(2)detach, (3)suspend - host suspend (different from > detach since it's possible to charge > in this state but with a di
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 connection and disconnection and it is up to the client to decide what else to do with the cable such as finding which state it is in and other details. So I feel this should not be handled in the extcon. However it is up to the maintainer to decide. Once the consumer gets the notification, it needs to take some action. One of the action is to read the cable properties. This can be done by proprietary calls which is known both to the consumer and the provider. My intention is to avoid this proprietary calls. Since both the provider and consumer are communicating with the extcon subsystem , I feel having a callback function of this kind would help to avoid the use of proprietary calls. Also I agree that extcon notifier chains are used to notify the cable state (attach/detach). But if a cable has more than two states (like the charger cable) how do we support it without having a callback function like this? Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer? Hello, I don't think it's appropriate to declare the charger specific properties in extcon.h. The status of a charger should be and can be represented by an instance of regulator, power-supply-class, or charger-manager. Agreed. We can move this to power supply subsystem. Thus, we may (I'm still not sure) need to let extcon to relay the instance (struct device? or char *devname?) with some callback similar with get_cable_device(). However, allowing (and encouraging) to pass void pointer of cable_props to extcon users from extcon device appears not adequete. If the both parties can use their own private data structure, why they cannot simply pass their own data witht the private data channel? Recap: - The later part of patch: NACK - The first part of patch (callback): need to reconsider the data type. We may get device pointer or device name that is correspondant to the cable, which in turn, guides us to the corresponding data structure (charger- manager, regulator, or something) However, I'm still not sure which should be appropriate for this. The requirement for this feature came from the implementation of the power supply charging framework (http://www.spinics.net/lists/kernel/msg1420500.html refer charger_cable_event_worker function). The charging framework is not a driver. It can be compiled with the power supply class driver to support charging. Also the private data structure may not provide a generic method for this implementation since the extcon provider drivers will be different in different platforms. So it's not necessary that the framework knows the private data structure of the provider. Basically the requirement is to have a generic method to retrieve the cable properties without knowing the extcon provider driver internal implementation. Can you suggest a generic approach for this problem? 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 through extcon, extcon consumer driver or framework should get the additional information of cable from other device driver except of extcon. Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG-USB-OFF, Dock) What are common properties among many cables expect attached or detached state? Also the cable states we support in extcon (attach/detach) is not sufficient to support the cable states of a charger cable which can have more than 2 states. The charger cable states can be (1)attach/(2)detach, (3)suspend - host suspend (different from detach since it's possible to charge in this state but with a different charge current than the attached state),(4)resume - resume after the suspend, (5)update - update the cable properties after USB enumeration (USB cable supports 100(USB2.0)/150(USB3.0) in an un configured state. But after enumeration it can support up to 500mA(USB 2.0)/900(USB 3.0)) Since extcon is basically intended to support the cable states, how do we support cables with more than two states? You explained about charger cable for charging framework. I think that extcon consumer driver can detect the chagne of system state from idle to suspend, then extcon consumer driver change charge current according to system state(idle or suspend). Also, I think that the main of charging is regulator and the regulator for charging defines max or min limitation of charge current with H/W dependency. The extcon provider driver haven't decided the charge current according to cable type. Now that extcon-max77693
RE: RE: [PATCH] extcon : callback function to read cable property
> > > > > 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 with the > > > > > cable such as finding which state it is in and other details. > > > > > So I feel this should not be handled in the extcon. > > > > > > > > > > However it is up to the maintainer to decide. > > > > > > > > Once the consumer gets the notification, it needs to take some action. > > > > One of the action is to read the cable properties. This can be > > > > done by proprietary calls which is known both to the consumer and the > provider. > > > > My intention is to avoid this proprietary calls. Since both the > > > > provider and consumer are communicating with the extcon subsystem > > > > , I feel having a callback function of this kind would help to > > > > avoid the use of proprietary calls. Also I agree that extcon > > > > notifier chains are used to notify the cable state > > > > (attach/detach). But if a cable has more than two states (like the > > > > charger cable) how do we support it without > > > having a callback function like this? > > > > Let the maintainer take the final decision. > > > Well this use case will keep on growing if we start factor in this > > > kind of changes and that is why I am opposed to adding any other state. > > > Maintainer? > > > > > > > > > > > > > Hello, > > > I don't think it's appropriate to declare the charger specific properties in > extcon.h. The status of a charger should be and can be represented by an > instance of regulator, power-supply-class, or charger-manager. > Agreed. We can move this to power supply subsystem. > Thus, we may (I'm still not sure) need to let extcon to relay the instance > (struct device? or char *devname?) with some callback similar with > get_cable_device(). However, allowing (and encouraging) to pass void > pointer of cable_props to extcon users from extcon device appears not > adequete. If the both parties can use their own "private" > data structure, why they cannot simply pass their own data witht the > "private" data channel? > > > Recap: > - The later part of patch: NACK > - The first part of patch (callback): need to reconsider the data type. > We may get device pointer or device name that is correspondant to the > cable, which in turn, guides us to the corresponding data structure (charger- > manager, regulator, or something) However, I'm still not sure which should > be appropriate for this. > The requirement for this feature came from the implementation of the power supply charging framework (http://www.spinics.net/lists/kernel/msg1420500.html refer charger_cable_event_worker function). The charging framework is not a driver. It can be compiled with the power supply class driver to support charging. Also the private data structure may not provide a generic method for this implementation since the extcon provider drivers will be different in different platforms. So it's not necessary that the framework knows the private data structure of the provider. Basically the requirement is to have a generic method to retrieve the cable properties without knowing the extcon provider driver internal implementation. Can you suggest a generic approach for this problem? Also the cable states we support in extcon (attach/detach) is not sufficient to support the cable states of a charger cable which can have more than 2 states. The charger cable states can be (1)attach/(2)detach, (3)suspend - host suspend (different from detach since it's possible to charge in this state but with a different charge current than the attached state),(4)resume - resume after the suspend, (5)update - update the cable properties after USB enumeration (USB cable supports 100(USB2.0)/150(USB3.0) in an un configured state. But after enumeration it can support up to 500mA(USB 2.0)/900(USB 3.0)) Since extcon is basically intended to support the cable states, how do we support cables with more than two states?
RE: RE: [PATCH] extcon : callback function to read cable property
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 with the cable such as finding which state it is in and other details. So I feel this should not be handled in the extcon. However it is up to the maintainer to decide. Once the consumer gets the notification, it needs to take some action. One of the action is to read the cable properties. This can be done by proprietary calls which is known both to the consumer and the provider. My intention is to avoid this proprietary calls. Since both the provider and consumer are communicating with the extcon subsystem , I feel having a callback function of this kind would help to avoid the use of proprietary calls. Also I agree that extcon notifier chains are used to notify the cable state (attach/detach). But if a cable has more than two states (like the charger cable) how do we support it without having a callback function like this? Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer? Hello, I don't think it's appropriate to declare the charger specific properties in extcon.h. The status of a charger should be and can be represented by an instance of regulator, power-supply-class, or charger-manager. Agreed. We can move this to power supply subsystem. Thus, we may (I'm still not sure) need to let extcon to relay the instance (struct device? or char *devname?) with some callback similar with get_cable_device(). However, allowing (and encouraging) to pass void pointer of cable_props to extcon users from extcon device appears not adequete. If the both parties can use their own private data structure, why they cannot simply pass their own data witht the private data channel? Recap: - The later part of patch: NACK - The first part of patch (callback): need to reconsider the data type. We may get device pointer or device name that is correspondant to the cable, which in turn, guides us to the corresponding data structure (charger- manager, regulator, or something) However, I'm still not sure which should be appropriate for this. The requirement for this feature came from the implementation of the power supply charging framework (http://www.spinics.net/lists/kernel/msg1420500.html refer charger_cable_event_worker function). The charging framework is not a driver. It can be compiled with the power supply class driver to support charging. Also the private data structure may not provide a generic method for this implementation since the extcon provider drivers will be different in different platforms. So it's not necessary that the framework knows the private data structure of the provider. Basically the requirement is to have a generic method to retrieve the cable properties without knowing the extcon provider driver internal implementation. Can you suggest a generic approach for this problem? Also the cable states we support in extcon (attach/detach) is not sufficient to support the cable states of a charger cable which can have more than 2 states. The charger cable states can be (1)attach/(2)detach, (3)suspend - host suspend (different from detach since it's possible to charge in this state but with a different charge current than the attached state),(4)resume - resume after the suspend, (5)update - update the cable properties after USB enumeration (USB cable supports 100(USB2.0)/150(USB3.0) in an un configured state. But after enumeration it can support up to 500mA(USB 2.0)/900(USB 3.0)) Since extcon is basically intended to support the cable states, how do we support cables with more than two states?
Re: RE: [PATCH] extcon : callback function to read cable property
> 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 to the client to decide what else to do with the cable such as > > > > finding which state it is in and other details. > > > > So I feel this should not be handled in the extcon. > > > > > > > > However it is up to the maintainer to decide. > > > > > > Once the consumer gets the notification, it needs to take some action. > > > One of the action is to read the cable properties. This can be done by > > > proprietary calls which is known both to the consumer and the provider. > > > My intention is to avoid this proprietary calls. Since both the > > > provider and consumer are communicating with the extcon subsystem , I > > > feel having a callback function of this kind would help to avoid the > > > use of proprietary calls. Also I agree that extcon notifier chains are > > > used to notify the cable state (attach/detach). But if a cable has > > > more than two states (like the charger cable) how do we support it without > > having a callback function like this? > > > Let the maintainer take the final decision. > > Well this use case will keep on growing if we start factor in this kind of > > changes and that is why I am opposed to adding any other state. > > Maintainer? > > > > > > > > Hello, I don't think it's appropriate to declare the charger specific properties in extcon.h. The status of a charger should be and can be represented by an instance of regulator, power-supply-class, or charger-manager. Thus, we may (I'm still not sure) need to let extcon to relay the instance (struct device? or char *devname?) with some callback similar with get_cable_device(). However, allowing (and encouraging) to pass void pointer of cable_props to extcon users from extcon device appears not adequete. If the both parties can use their own "private" data structure, why they cannot simply pass their own data witht the "private" data channel? Recap: - The later part of patch: NACK - The first part of patch (callback): need to reconsider the data type. We may get device pointer or device name that is correspondant to the cable, which in turn, guides us to the corresponding data structure (charger-manager, regulator, or something) However, I'm still not sure which should be appropriate for this. Cheers! MyungJoo
RE: [PATCH] extcon : callback function to read cable property
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 to the client to decide what else to do with the cable such as > > > finding which state it is in and other details. > > > So I feel this should not be handled in the extcon. > > > > > > However it is up to the maintainer to decide. > > > > Once the consumer gets the notification, it needs to take some action. > > One of the action is to read the cable properties. This can be done by > > proprietary calls which is known both to the consumer and the provider. > > My intention is to avoid this proprietary calls. Since both the > > provider and consumer are communicating with the extcon subsystem , I > > feel having a callback function of this kind would help to avoid the > > use of proprietary calls. Also I agree that extcon notifier chains are > > used to notify the cable state (attach/detach). But if a cable has > > more than two states (like the charger cable) how do we support it without > having a callback function like this? > > Let the maintainer take the final decision. > Well this use case will keep on growing if we start factor in this kind of > changes and that is why I am opposed to adding any other state. > Maintainer? > > > > >
RE: [PATCH] extcon : callback function to read cable property
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 to the client to decide what else to do with the cable such as finding which state it is in and other details. So I feel this should not be handled in the extcon. However it is up to the maintainer to decide. Once the consumer gets the notification, it needs to take some action. One of the action is to read the cable properties. This can be done by proprietary calls which is known both to the consumer and the provider. My intention is to avoid this proprietary calls. Since both the provider and consumer are communicating with the extcon subsystem , I feel having a callback function of this kind would help to avoid the use of proprietary calls. Also I agree that extcon notifier chains are used to notify the cable state (attach/detach). But if a cable has more than two states (like the charger cable) how do we support it without having a callback function like this? Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer?
Re: RE: [PATCH] extcon : callback function to read cable property
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 to the client to decide what else to do with the cable such as finding which state it is in and other details. So I feel this should not be handled in the extcon. However it is up to the maintainer to decide. Once the consumer gets the notification, it needs to take some action. One of the action is to read the cable properties. This can be done by proprietary calls which is known both to the consumer and the provider. My intention is to avoid this proprietary calls. Since both the provider and consumer are communicating with the extcon subsystem , I feel having a callback function of this kind would help to avoid the use of proprietary calls. Also I agree that extcon notifier chains are used to notify the cable state (attach/detach). But if a cable has more than two states (like the charger cable) how do we support it without having a callback function like this? Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer? Hello, I don't think it's appropriate to declare the charger specific properties in extcon.h. The status of a charger should be and can be represented by an instance of regulator, power-supply-class, or charger-manager. Thus, we may (I'm still not sure) need to let extcon to relay the instance (struct device? or char *devname?) with some callback similar with get_cable_device(). However, allowing (and encouraging) to pass void pointer of cable_props to extcon users from extcon device appears not adequete. If the both parties can use their own private data structure, why they cannot simply pass their own data witht the private data channel? Recap: - The later part of patch: NACK - The first part of patch (callback): need to reconsider the data type. We may get device pointer or device name that is correspondant to the cable, which in turn, guides us to the corresponding data structure (charger-manager, regulator, or something) However, I'm still not sure which should be appropriate for this. Cheers! MyungJoo
RE: [PATCH] extcon : callback function to read cable property
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 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 with the cable such as finding which state it is in > > and > > other details. > > So I feel this should not be handled in the extcon. > > > > However it is up to the maintainer to decide. > > Once the consumer gets the notification, it needs to take some action. > One of the action is to read the cable properties. This can be done > by proprietary calls which is known both to the consumer and the provider. > My intention is to avoid this proprietary calls. Since both the provider > and consumer are communicating with the extcon subsystem , I feel having a > callback function of this kind would help to avoid the use of proprietary > calls. Also I agree that extcon notifier chains are used to notify the cable > state (attach/detach). But if a cable has more than two states (like the > charger cable) how do we support it without having a callback function like > this? > Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer? > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] extcon : callback function to read cable property
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 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 with the cable such as finding which state it is in and other details. So I feel this should not be handled in the extcon. However it is up to the maintainer to decide. Once the consumer gets the notification, it needs to take some action. One of the action is to read the cable properties. This can be done by proprietary calls which is known both to the consumer and the provider. My intention is to avoid this proprietary calls. Since both the provider and consumer are communicating with the extcon subsystem , I feel having a callback function of this kind would help to avoid the use of proprietary calls. Also I agree that extcon notifier chains are used to notify the cable state (attach/detach). But if a cable has more than two states (like the charger cable) how do we support it without having a callback function like this? Let the maintainer take the final decision. Well this use case will keep on growing if we start factor in this kind of changes and that is why I am opposed to adding any other state. Maintainer? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] extcon : callback function to read cable property
> 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 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 with the cable such as finding which state it is in and
> other details.
> So I feel this should not be handled in the extcon.
>
> However it is up to the maintainer to decide.
Once the consumer gets the notification, it needs to take some action. One of
the action is to read the cable properties. This can be done by proprietary
calls which is known both to the consumer and the provider. My intention is to
avoid this proprietary calls. Since both the provider and consumer are
communicating with the extcon subsystem , I feel having a callback function of
this kind would help to avoid the use of proprietary calls. Also I agree that
extcon notifier chains are used to notify the cable state (attach/detach). But
if a cable has more than two states (like the charger cable) how do we support
it without having a callback function like this? Let the maintainer take the
final decision.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] extcon : callback function to read cable property
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 increase the charge
> current after USB enumaeration).Also the properties of the cable may
> vary based on the state. FOr example in SUSPENDED state platforms can
> support 0/100/500/950(USB 3.0) mA based on the HW. To initiate charging
> the consumer should be able to get the charger properties dynamically.
>
> Signed-off-by: Jenny TC
> ---
> include/linux/extcon.h | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index 073fd49..2e61ee0 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -122,6 +122,7 @@ struct extcon_dev {
> /* --- Optional callbacks to override class functions --- */
> ssize_t (*print_name)(struct extcon_dev *edev, char *buf);
> ssize_t (*print_state)(struct extcon_dev *edev, char *buf);
> + int (*get_cable_properties)(const char *cable_name, void *cable_props);
>
> /* --- Internal data. Please do not set. --- */
> struct device *dev;
> @@ -177,6 +178,19 @@ struct extcon_specific_cable_nb {
> unsigned long previous_value;
> };
>
> +enum extcon_chrgr_cbl_stat {
> + EXTCON_CHRGR_CABLE_CONNECTED,
> + EXTCON_CHRGR_CABLE_DISCONNECTED,
> + EXTCON_CHRGR_CABLE_SUSPENDED,
> + EXTCON_CHRGR_CABLE_RESUMED,
> + EXTCON_CHRGR_CABLE_UPDATED,
> +};
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 with the cable such as finding which state it
is in and other details.
So I feel this should not be handled in the extcon.
However it is up to the maintainer to decide.
> +
> +struct extcon_chrgr_cbl_props {
> + enum extcon_chrgr_cbl_stat cable_stat;
> + unsigned long mA;
> +};
> +
> #if IS_ENABLED(CONFIG_EXTCON)
>
> /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon : callback function to read cable property
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 increase the charge
current after USB enumaeration).Also the properties of the cable may
vary based on the state. FOr example in SUSPENDED state platforms can
support 0/100/500/950(USB 3.0) mA based on the HW. To initiate charging
the consumer should be able to get the charger properties dynamically.
Signed-off-by: Jenny TC jenny...@intel.com
---
include/linux/extcon.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 073fd49..2e61ee0 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -122,6 +122,7 @@ struct extcon_dev {
/* --- Optional callbacks to override class functions --- */
ssize_t (*print_name)(struct extcon_dev *edev, char *buf);
ssize_t (*print_state)(struct extcon_dev *edev, char *buf);
+ int (*get_cable_properties)(const char *cable_name, void *cable_props);
/* --- Internal data. Please do not set. --- */
struct device *dev;
@@ -177,6 +178,19 @@ struct extcon_specific_cable_nb {
unsigned long previous_value;
};
+enum extcon_chrgr_cbl_stat {
+ EXTCON_CHRGR_CABLE_CONNECTED,
+ EXTCON_CHRGR_CABLE_DISCONNECTED,
+ EXTCON_CHRGR_CABLE_SUSPENDED,
+ EXTCON_CHRGR_CABLE_RESUMED,
+ EXTCON_CHRGR_CABLE_UPDATED,
+};
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 with the cable such as finding which state it
is in and other details.
So I feel this should not be handled in the extcon.
However it is up to the maintainer to decide.
+
+struct extcon_chrgr_cbl_props {
+ enum extcon_chrgr_cbl_stat cable_stat;
+ unsigned long mA;
+};
+
#if IS_ENABLED(CONFIG_EXTCON)
/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] extcon : callback function to read cable property
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 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 with the cable such as finding which state it is in and
other details.
So I feel this should not be handled in the extcon.
However it is up to the maintainer to decide.
Once the consumer gets the notification, it needs to take some action. One of
the action is to read the cable properties. This can be done by proprietary
calls which is known both to the consumer and the provider. My intention is to
avoid this proprietary calls. Since both the provider and consumer are
communicating with the extcon subsystem , I feel having a callback function of
this kind would help to avoid the use of proprietary calls. Also I agree that
extcon notifier chains are used to notify the cable state (attach/detach). But
if a cable has more than two states (like the charger cable) how do we support
it without having a callback function like this? Let the maintainer take the
final decision.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] extcon : callback function to read cable property
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 increase the charge
current after USB enumaeration).Also the properties of the cable may
vary based on the state. FOr example in SUSPENDED state platforms can
support 0/100/500/950(USB 3.0) mA based on the HW. To initiate charging
the consumer should be able to get the charger properties dynamically.
Signed-off-by: Jenny TC
---
include/linux/extcon.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 073fd49..2e61ee0 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -122,6 +122,7 @@ struct extcon_dev {
/* --- Optional callbacks to override class functions --- */
ssize_t (*print_name)(struct extcon_dev *edev, char *buf);
ssize_t (*print_state)(struct extcon_dev *edev, char *buf);
+ int (*get_cable_properties)(const char *cable_name, void *cable_props);
/* --- Internal data. Please do not set. --- */
struct device *dev;
@@ -177,6 +178,19 @@ struct extcon_specific_cable_nb {
unsigned long previous_value;
};
+enum extcon_chrgr_cbl_stat {
+ EXTCON_CHRGR_CABLE_CONNECTED,
+ EXTCON_CHRGR_CABLE_DISCONNECTED,
+ EXTCON_CHRGR_CABLE_SUSPENDED,
+ EXTCON_CHRGR_CABLE_RESUMED,
+ EXTCON_CHRGR_CABLE_UPDATED,
+};
+
+struct extcon_chrgr_cbl_props {
+ enum extcon_chrgr_cbl_stat cable_stat;
+ unsigned long mA;
+};
+
#if IS_ENABLED(CONFIG_EXTCON)
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] extcon : callback function to read cable property
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 increase the charge
current after USB enumaeration).Also the properties of the cable may
vary based on the state. FOr example in SUSPENDED state platforms can
support 0/100/500/950(USB 3.0) mA based on the HW. To initiate charging
the consumer should be able to get the charger properties dynamically.
Signed-off-by: Jenny TC jenny...@intel.com
---
include/linux/extcon.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 073fd49..2e61ee0 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -122,6 +122,7 @@ struct extcon_dev {
/* --- Optional callbacks to override class functions --- */
ssize_t (*print_name)(struct extcon_dev *edev, char *buf);
ssize_t (*print_state)(struct extcon_dev *edev, char *buf);
+ int (*get_cable_properties)(const char *cable_name, void *cable_props);
/* --- Internal data. Please do not set. --- */
struct device *dev;
@@ -177,6 +178,19 @@ struct extcon_specific_cable_nb {
unsigned long previous_value;
};
+enum extcon_chrgr_cbl_stat {
+ EXTCON_CHRGR_CABLE_CONNECTED,
+ EXTCON_CHRGR_CABLE_DISCONNECTED,
+ EXTCON_CHRGR_CABLE_SUSPENDED,
+ EXTCON_CHRGR_CABLE_RESUMED,
+ EXTCON_CHRGR_CABLE_UPDATED,
+};
+
+struct extcon_chrgr_cbl_props {
+ enum extcon_chrgr_cbl_stat cable_stat;
+ unsigned long mA;
+};
+
#if IS_ENABLED(CONFIG_EXTCON)
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
