Hi,
Robert Jarzmik <robert.jarzmik@xxxxxxx> writes:
>> your commit 7acc9973e3c4 ("usb: phy: generic: add vbus support") added
>> GPIO-based VBUS handling for phy-generic.c, but that ends up calling
>> usb_gadget_vbus_connect() which forces NOP to depend on the gadget API.
>>
>> I was grepping around and couldn't find any users for that VBUS gpio
>> _and_ we have phy-gpio-vbus.c which does the same thing.
> Indeed, I remember creating this commit out of phy-gpio-vbus-usb.c
> This is used in pxa device-tree platforms, that's why your grep didn't find them
> as device-tree descriptions are out of tree.
>
>> I'm wondering if we should drop the usb_gadget_vbus_connect() support so
>> other phy-generic users (like ehci-omap) can rely on it without
>> depending on the gadget API.
> I understand, from a layering perspective that makes perfect sense.
>
>> Thoughts?
> Yeah, kind of. phy-generic has an atomic notifier for connection events. I think
> we could leverage that and :
> - remove the usb_gadget_vbus_*() calls
> - amend the drivers (for my part I have pxa27x_udc.c and probably pxa25x_udc.c)
> to subscribe to the notifier, and in the action function call either
> usb_gadget_vbus_connect() or usb_gadget_vbus_disconnect().
>
> Would that kind of approach solve the layering issue, what do you think ?
I like second option of having PHY simply sending the notification and
relying on UDC to actually call usb_gadget_vbus_*().
I could write the patches, but I wouldn't have any means to test them
:-s
Let me know if you prefer to write them yourself or want me to give it a
shot.
cheers
--
balbi
Attachment:
signature.asc
Description: PGP signature
