From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chanwoo Choi Date: Fri, 18 Dec 2015 01:04:13 +0000 Subject: Re: [PATCH v3] extcon: add Maxim MAX3355 driver Message-Id: <56735B8D.7030705@samsung.com> List-Id: References: <2473780.4IzuWX8hE2@wasted.cogentembedded.com> <56721AFE.9020103@samsung.com> <56721F31.5060608@samsung.com> <56732719.7020301@cogentembedded.com> In-Reply-To: <56732719.7020301-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Sergei Shtylyov , robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 2015년 12월 18일 06:20, Sergei Shtylyov wrote: > 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 >>>> >>>> --- >>>> 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? Yes. You add the this flag on v4 patch. Looks good to me. Thanks, Chanwoo Choi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934188AbbLRBE1 (ORCPT ); Thu, 17 Dec 2015 20:04:27 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:43389 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933277AbbLRBEY convert rfc822-to-8bit (ORCPT ); Thu, 17 Dec 2015 20:04:24 -0500 X-AuditID: cbfee691-f79766d0000012b6-53-56735b956b59 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT Message-id: <56735B8D.7030705@samsung.com> Date: Fri, 18 Dec 2015 10:04:13 +0900 From: Chanwoo Choi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Sergei Shtylyov , robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, myungjoo.ham@samsung.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: linux-sh@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v3] extcon: add Maxim MAX3355 driver References: <2473780.4IzuWX8hE2@wasted.cogentembedded.com> <56721AFE.9020103@samsung.com> <56721F31.5060608@samsung.com> <56732719.7020301@cogentembedded.com> In-reply-to: <56732719.7020301@cogentembedded.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsWyRsSkRHdqdHGYwfWZ+hbzj5xjteh/s5DV 4tyrlYwWl3fNYbOY82cKs8WiZa3MFkuvX2SyuN24gs1iwvS1LBate4+wW5xZdYvdgdtjzbw1 jB6X+3qZPB5M/c/ksXL5FzaPTas62Tz6tqxi9Pi8SS6APYrLJiU1J7MstUjfLoErY+fmJraC pxIV858+Z21g3CfcxcjJISFgIrHz1W4mCFtM4sK99WxdjFwcQgIrGCU2HlzCDlN0ayJEkZDA LEaJz41hIDavgKDEj8n3WLoYOTiYBdQlpkzJBQkzC4hIfL56mhnC1pZYtvA1M8TMB4wSR2ZM YYfo1ZJYcXMxK4jNIqAqcahjI1icDSi+/8UNNpCZogIREt0nKkF6RQRamSS6J2xgghhqLjF3 6iMwW1jAQmLKl4+MEAsWMUpMfboXbBCngJHEsndPwBISAn/ZJVbd+sUCsU1A4tvkQ2BXSwjI Smw6wAzxpKTEwRU3WCYwis9C8tsshN9mIfltFpLfFjCyrGIUTS1ILihOSi8y1StOzC0uzUvX S87P3cQIjPDT/55N3MF4/4D1IUYBDkYlHl4DtuIwIdbEsuLK3EOMpkAHTWSWEk3OB6aRvJJ4 Q2MzIwtTE1NjI3NLMyVxXh3pn8FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGAWOyO/rC/jF pO8n+nVu98SNytu/Rh4wmKr18uPGV+vSWfe991t5KWi365J3QdEHTW9a37XenyjeusVf57ra uk897yuPbb1i/ihaa07cTHYhxpyjazIyVq1XX7Bt15HUr8ZXQ5Zs1ehmnT07yJYtq6tNlKfg 7I3uxNAPsVsaljmlHpoYKBZ8bK4SS3FGoqEWc1FxIgANyM286wIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42I5/e+xoO7U6OIwg5Nb1CzmHznHatH/ZiGr xblXKxktLu+aw2Yx588UZotFy1qZLZZev8hkcbtxBZvFhOlrWSxa9x5htziz6ha7A7fHmnlr GD0u9/UyeTyY+p/JY+XyL2wem1Z1snn0bVnF6PF5k1wAe1QDo01GamJKapFCal5yfkpmXrqt kndwvHO8qZmBoa6hpYW5kkJeYm6qrZKLT4CuW2YO0JVKCmWJOaVAoYDE4mIlfTtME0JD3HQt YBojdH1DguB6jAzQQMIaxoxzC3+wFeyWqLj++yN7A+MU4S5GTg4JAROJWxN3M0HYYhIX7q1n A7GFBGYxSnxuDAOxeQUEJX5MvsfSxcjBwSwgL3HkUjaEqS4xZUpuFyMXUPUDRokjM6awQ5Rr Say4uZgVxGYRUJU41LERLM4GFN//4gYbSK+oQIRE94lKkF4RgVYmie4JG8BOYBYwl5g79RGY LSxgITHly0dGiAWLGCWmPt0LNohTwEhi2bsnjBMYgY5EOG8WwnmzEM5bwMi8ilEitSC5oDgp PdcwL7Vcrzgxt7g0L10vOT93EyM4ITyT2sF4cJf7IUYBDkYlHt4bzMVhQqyJZcWVuYcYJTiY lUR4A8KBQrwpiZVVqUX58UWlOanFhxhNgf6byCwlmpwPTFZ5JfGGxiZmRpZG5oYWRsbmSuK8 tZciw4QE0hNLUrNTUwtSi2D6mDg4pRoY7Xku2x/b1uSjts33nwD3i/O/HumwHmM8wrPwaeP5 d8/jFbqKU/56XPBYNc3h5MtTk36UTdy121PuVNLb67XLVIMvvWHgXLmGo+SE9Sn3qw+XS06e 0eUUn9TeF6jQ4GC95Mi1d19VK5r5AvO1+NZ1TH7b6C6y+tBErzVv1qtuzLwrlGbEajvxnRJL cUaioRZzUXEiAAawReseAwAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015년 12월 18일 06:20, Sergei Shtylyov wrote: > 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 >>>> >>>> --- >>>> 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? Yes. You add the this flag on v4 patch. Looks good to me. Thanks, Chanwoo Choi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chanwoo Choi Subject: Re: [PATCH v3] extcon: add Maxim MAX3355 driver Date: Fri, 18 Dec 2015 10:04:13 +0900 Message-ID: <56735B8D.7030705@samsung.com> References: <2473780.4IzuWX8hE2@wasted.cogentembedded.com> <56721AFE.9020103@samsung.com> <56721F31.5060608@samsung.com> <56732719.7020301@cogentembedded.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-reply-to: <56732719.7020301-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sergei Shtylyov , robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On 2015=EB=85=84 12=EC=9B=94 18=EC=9D=BC 06:20, Sergei Shtylyov wrote: > Hello. >=20 > On 12/17/2015 05:34 AM, Chanwoo Choi wrote: >=20 >>> On 2015=EB=85=84 12=EC=9B=94 17=EC=9D=BC 03:07, Sergei Shtylyov wro= te: >>>> Maxim Integrated MAX3355E chip integrates a charge pump and compar= ators to >>>> enable a system with an integrated USB OTG dual-role transceiver t= o >>>> function as an USB OTG dual-role device. In addition to sensing/co= ntrolling >>>> Vbus, the chip also passes thru the ID signal from the USB OTG con= nector. >>>> 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 co= ntrollers >>>> sharing the same USB bus; however, we'd like to allow host or gadg= et >>>> drivers to be loaded depending on the cable type, hence the need f= or the >>>> MAX3355 extcon driver. The Vbus status signals are also wired to G= PIOs >>>> (however, we aren't currently interested in them), the OFFVBUS# si= gnal 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 >>>> >>>> --- >>>> 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() c= all; >>>> - renamed 'ret' variable to 'err' in max3355_probe(); >>>> - expanded the Kconfig entry help text; >>>> - added vendor name to the patch summary, the bindings document, t= he 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 | 1= 53 ++++++++++++ >>>> 4 files changed, 183 insertions(+) >>>> >> >> [snip] >> >>>> + return 0; >>>> +} >>>> + >>>> +static int max3355_remove(struct platform_device *pdev) >>>> +{ >>>> + struct max3355_data *data =3D 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. >=20 > You told me to pass IRQF_NO_SUSPEND to devm_request_threaded_irq()= , didn't you? Yes. You add the this flag on v4 patch. Looks good to me. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html