Re: [PATCH] extcon : callback function to read cable property

[Chanwoo Choi]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/