Hello.
On 12/17/2015 05:34 AM, Chanwoo Choi wrote:
On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx>
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig | 8
drivers/extcon/Makefile | 1
drivers/extcon/extcon-max3355.c | 153 ++++++++++++
4 files changed, 183 insertions(+)
[snip]
+ return 0;
+}
+
+static int max3355_remove(struct platform_device *pdev)
+{
+ struct max3355_data *data = platform_get_drvdata(pdev);
+
+ gpiod_set_value_cansleep(data->shdn_gpiod, 0);
Don't need to handle the 'shdn' gpio on resume/suspend funtcion?
But, if the interrput of id gpio is used for wakeup source,
there is no reason to handle it for suspend mode.
You told me to pass IRQF_NO_SUSPEND to devm_request_threaded_irq(), didn't
you?
[snip]
Thanks,
Chanwoo Choi
MBR, Sergei
--
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
