lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 23 Dec 2014 23:09:44 +0300 From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com> To: David Cohen <david.a.cohen@...ux.intel.com> CC: myungjoo.ham@...sung.com, cw00.choi@...sung.com, linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, baolu.lu@...ux.intel.com Subject: Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s) Hello. On 12/23/2014 10:57 PM, David Cohen wrote: >>> Some platforms have an USB OTG port fully (or partially) controlled by >>> GPIOs: >>> (1) USB ID is connected directly to GPIO >>> Optionally: >>> (2) VBUS is enabled by a GPIO (when ID is grounded) >> Can't the host driver still control Vbus? > I can't a clean way for host driver to control VBUS considering it > depends on USB ID. You're using the cable state notifiers, why not control Vbus from there? You need some way of passing the GPIO to host driver though... I assume you're not using the device tree, and your host controllers live on PCI, so the platform data is out of question. You may be right then... >>> (3) Platform has 2 USB controllers connected to same port: one for >>> device and one for host role. D+/- are switched between phys >>> by GPIO. >>> As per initial version, this driver has the duty to control whether >>> USB-Host cable is plugged in or not: >>> - If yes, OTG port is configured for host role >>> - If no, by standard, the OTG port is configured for device role >>> Signed-off-by: David Cohen <david.a.cohen@...ux.intel.com> >>> --- >>> Hi, >>> Some Intel Bay Trail boards have an unusual way to handle the USB OTG port: >>> - The USB ID pin is connected directly to GPIO on SoC >>> - When in host role, VBUS is provided by enabling a GPIO >>> - Device and host roles are supported by 2 independent controllers with D+/- >>> pins from port switched between different phys according a GPIO level. >>> The ACPI table describes this USB port as a (virtual) device with all the >>> necessary GPIOs. This driver implements support to this virtual device as an >>> extcon class driver. All drivers that depend on the USB OTG port state (USB phy, >>> PMIC, charge detection) will listen to extcon events. >> It's very close to my setup on R-Car R8A7791 based boards. :-) >> I have already submitted Maxim MAX3355 OTG chip GPIO-based driver. > Hm. I'll look for it. Thanks for pointing. http://marc.info/?l=linux-usb&m=141825413802370 In my case, Vbus is not controlled via GPIO though. I would have probably used the generic GPIO extcon driver if I didn't have to drive MAX3355's SHDN# pin high... There were also some other patches for this issue, the one probably interesting to you is there: http://marc.info/?l=linux-usb&m=141877180912359 >>> Comments are welcome. >>> Br, David [...] >>> +static int __init vuport_init(void) >>> +{ >>> + return platform_driver_register(&vuport_driver); >>> +} >>> +subsys_initcall(vuport_init); >> Hm, why? > We have drivers that depend on this one during their probe. What about deferred probing? With EPROBE_DEFER we don't need to play the initcall games any more AFAIU. > Br, David WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists