From: Chanwoo Choi <cw00.choi@samsung.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
myungjoo.ham@samsung.com, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-sh@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH] extcon: add MAX3355 driver
Date: Tue, 10 Nov 2015 08:52:26 +0900 [thread overview]
Message-ID: <564131BA.9010809@samsung.com> (raw)
In-Reply-To: <5640E4D5.4020001@cogentembedded.com>
Hello,
I received the reply from you after too long time (17~18day).
You better to reply it more a little more quickly
if you have the question or new patches.
On 2015년 11월 10일 03:24, Sergei Shtylyov wrote:
> Hello.
>
> On 10/23/2015 08:56 AM, Chanwoo Choi wrote:
>
>>>>>> MAX3355E chip integrates a charge pump and comparators to enable a system with
>>>>>> an integrated USB OTG dual-role transceiver to function as a 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're not currently intested in them), the OFFVBUS# signal
>>>>>> is controlled by the host controllers, there's also the SHDN# signal wired to
>>>>>> GPIO, which should be high for normal operation.
>>>>
>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>>
>>>>>> ---
>>>>>> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>>>>
>>>>>> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
>>>>>> drivers/extcon/Kconfig | 6
>>>>>> drivers/extcon/Makefile | 1
>>>>>> drivers/extcon/extcon-max3355.c | 122
>>>>>> ++++++++++++
>>>>>> 4 files changed, 150 insertions(+)
>>>>
>>>>>> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
>>>>>> ===================================================================
>>>>>> --- /dev/null
>>>>>> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
>>>>>> @@ -0,0 +1,21 @@
>>>>>> +MAX3355 USB OTG chip
>>>>
>>>>> Need manufactor information as following :
>>>>> -> Maxim MAX3355
>>>>
>>>> Would be Maxim enough? Or perhaps I should use Maxim Integrated [Products]?
>>>
>>> You haven't replied to my questions.
>>>
>>>>>> +--------------------
>>>>>> +
>>>>>> +MAX3355 integrates a charge pump and comparators to enable a system with an
>>>>>> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
>>>>>> +device.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: should be "maxim,max3355";
>>>>>> +- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
>>>>>> GPIO pin
>>>>>> + connected to the MAX3355's SHDN# pin;
>>>>>> +- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
>>>>>> + connected to the MAX3355's ID_OUT pin.
>>>>>> +
>>>>>> +Example (Koelsch board):
>>>>>> +
>>>>>> + usb-otg {
>>>>>> + compatible = "maxim,max3355";
>>>>>> + maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
>>>>>> + maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
>>>>
>>>>> Kernel already supported the gpio helper function to get gpio from devicetree.
>>>>> I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
>>>>> include/linux/of_gpio.h.
>>>>
>>>>> gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
>>>>
>>>> OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
>>>> to insist on using this one...
>>>
>>> Moreover, it now says "gpios" isn't allowed for the new bindings. So I have to strongly disagree here...
>>
>> OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
>> instead of using devm_gpio_request_one() directly as following:
>> You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.
>>
>> For example,
>> data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
>> data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);
>
> Thanks, done now. I just had another idea: how about I add an optional "enable-gpio" property to the 'extcon-usb-gpio' driver? I wouldn't need my own driver then at all... :-)
What is meaning of 'enable-gpio' property?
You better to explain your goal about 'enable-gpio' property
Also, If you think that it is generic way about
adding 'enable-gpio' property to extcon-usb-gpio.c,
you can try it.
Thanks,
Chanwoo Choi
next prev parent reply other threads:[~2015-11-09 23:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 23:28 [PATCH] extcon: add MAX3355 driver Sergei Shtylyov
2014-12-11 1:46 ` Chanwoo Choi
2014-12-11 9:07 ` Geert Uytterhoeven
2014-12-11 12:47 ` Sergei Shtylyov
[not found] ` <54899264.30009-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2014-12-11 12:51 ` Chanwoo Choi
[not found] ` <14631865.01KLlU2iKL-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
2014-12-17 0:31 ` Chanwoo Choi
[not found] ` <5490CEE2.1030900-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-12-17 21:58 ` Sergei Shtylyov
2015-10-20 18:20 ` Sergei Shtylyov
2015-10-21 2:57 ` Chanwoo Choi
[not found] ` <5626FF05.80908-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-10-22 22:41 ` Sergei Shtylyov
2015-10-23 5:56 ` Chanwoo Choi
2015-11-09 18:24 ` Sergei Shtylyov
2015-11-09 23:52 ` Chanwoo Choi [this message]
2015-11-10 11:03 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564131BA.9010809@samsung.com \
--to=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=myungjoo.ham@samsung.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sergei.shtylyov@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).