Message ID | 1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com (mailing list archive) |
---|---|
Headers | show |
Series | add USB GPIO based connection detection driver | expand |
On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > Because the USB Connector is introduced and the requirement of > usb-connector.txt binding, the old way using extcon to support > USB Dual-Role switch is now deprecated, meanwhile there is no > available common driver when use Type-B connector, typically > using an input GPIO to detect USB ID pin. However while this was going on, drivers/extcon/extcon-fsa9480.c was merged and that detects not only GPIO on the USB port but multiplexed usecases such as UART over the USB micro PHY (and no that UART is not a USB UART, but an actual RX/TX over D-/D+). That driver also measure a whole slew of funny resistance values on the ID pin, that is how it does its job. But for just "hey I'm plugged in" we can surely keep this ID on GPIO detection in the USB subsystem. I just get a bit insecure about how we should ideally handle these "funny-PHY's". Yours, Linus Walleij
On Mon, 2019-08-05 at 12:06 +0200, Linus Walleij wrote: > On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > > > Because the USB Connector is introduced and the requirement of > > usb-connector.txt binding, the old way using extcon to support > > USB Dual-Role switch is now deprecated, meanwhile there is no > > available common driver when use Type-B connector, typically > > using an input GPIO to detect USB ID pin. > > However while this was going on, > drivers/extcon/extcon-fsa9480.c was merged and that detects > not only GPIO on the USB port but multiplexed usecases such > as UART over the USB micro PHY (and no that UART is not > a USB UART, but an actual RX/TX over D-/D+). > > That driver also measure a whole slew of funny resistance > values on the ID pin, that is how it does its job. I look into the spec of fsa9480, it indeed detect many USB accessories. But this driver is used for simplest cases that only uses micro receptacle with id-pin/vbus-pin > > But for just "hey I'm plugged in" we can surely keep this > ID on GPIO detection in the USB subsystem. Sorry, you mean provide a common API? could you please describe more clearer about your suggestion? Introducing a single driver using usb_role_switch will help to keep transparent for USB controller driver, no matter it uses type-c or micro Thanks a lot > > I just get a bit insecure about how we should ideally > handle these "funny-PHY's". > > Yours, > Linus Walleij
On Tue, Aug 6, 2019 at 9:48 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > On Mon, 2019-08-05 at 12:06 +0200, Linus Walleij wrote: > > On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > > But for just "hey I'm plugged in" we can surely keep this > > ID on GPIO detection in the USB subsystem. > > Sorry, you mean provide a common API? could you please describe more > clearer about your suggestion? Sorry I am not suggesting anything, this code is fine. But: > > I just get a bit insecure about how we should ideally > > handle these "funny-PHY's". I am more thinking about which subsystem these things really belong in. But let's keep it like this for the simple GPIO case. Acked-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij