On 04/16/2015 04:13 PM, Ivan T. Ivanov wrote:
> Hi,
>
> On Thu, 2015-04-16 at 16:00 +0900, Chanwoo Choi wrote:
>> Hi Peter,
>>
>> On 04/16/2015 10:59 AM, Peter Chen wrote:
>>>
>
>>> Ok, from USB point, external id/vbus value can't decide
>>> which role the controller will be, the controller driver
>>> will decide role according to many things, eg, user configurations,
>>> id/vbus value, OTG HNP, etc.
>>>
>>> So, from USB controller/phy driver, it doesn't care which cable is
>>> inserted, it cares about id/vbus value. Eg, it can get id/vbus value
>>> and it will be notified when the id/vbus value has changed.
>>
>> OK, I change the notifier name and add notifier events as following:
>>
>> - extcon_{register|unregister}_usb_notifier(struct extcon_dev *edev, struct notifier_block *nb);
>> - list of notifier events
>> #define EXTCON_USB_ID_L_VBUS_L0 /* ID low and VBUS low */
>> #define EXTCON_USB_ID_L_VBUS_H1 /* ID low and VBUS high */
>> #define EXTCON_USB_ID_H_VBUS_L2 /* ID high and VBUS low */
>> #define EXTCON_USB_ID_H_VBUS_H3 /* ID high and VBUS high */
>
> I am still confused, why we mix ID and VBUS events into one?
> Those are two lines and they are not necessarily handled by
> the same extcon_dev.
IMO, if some usb driver check both id and vbus pin at the same time,
the usb driver can know the both id and vbus pin state through only one notifier event.
Also,
If some usb driver want to know the state of id pin except of vbus state,
when receiving following events, id pin is low.
#define EXTCON_USB_ID_L_VBUS_L0
#define EXTCON_USB_ID_L_VBUS_H1
when receiving following events, id pin is high.
#define EXTCON_USB_ID_H_VBUS_L2
#define EXTCON_USB_ID_H_VBUS_H3
Also, some usb driver would catch the vbus pin state with same method.
But, it is just my opinion. We may use following notifier events for each pin.
We need to discuss it.
#define EXTCON_USB_ID_LOW
#define EXTCON_USB_ID_HIGH
#define EXTCON_USB_VBUS_LOW
#define EXTCON_USB_VBUS_HIGH
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
