[{"id":1774282,"web_url":"http://patchwork.ozlabs.org/comment/1774282/","msgid":"","list_archive_url":null,"date":"2017-09-24T19:56:04","subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Sun, Sep 24, 2017 at 9:56 AM, Linus Walleij wrote:\n> Add some reasonable device tree bindings and also add the cable defines\n> to the extcon include in since\n> the GPIO extcon definately need to specify which cable/connector it is\n> detecting.\n>\n> Adding the include file makes the (as it happens) Linux numbers into an\n> ABI, but I do not see any better method. It is possible to define strings\n> for all cable types but it seems like overkill, just reusing Linux'\n> enumerators seems like a good idea.\n>\n> The binding supports any number of GPIOs and connectors, but the driver\n> currently only supports one connector on one GPIO line.\n\nMy view of extcon binding is it is fundamentally broken. I've\nexpressed this multiple times before.\n\nTL;DR: Anything extending the existing extcon binding will be NAKed.\n\n>\n> Cc: devicetree@vger.kernel.org\n> Signed-off-by: Linus Walleij \n> ---\n> .../devicetree/bindings/extcon/extcon-gpio.txt | 24 ++++++++++++++\n> include/dt-bindings/extcon/connectors.h | 38 ++++++++++++++++++++++\n> 2 files changed, 62 insertions(+)\n> create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt\n> create mode 100644 include/dt-bindings/extcon/connectors.h\n>\n> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt\n> new file mode 100644\n> index 000000000000..2f5e21b94a64\n> --- /dev/null\n> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt\n> @@ -0,0 +1,24 @@\n> +External Connector Using GPIO\n\nWhat kind of connector? All connectors external to something... And\nGPIO is not a kind of connector on its own, but an implementation.\n\n> +\n> +Required properties:\n> +- compatible: should be \"extcon-gpio\"\n> +- extcon-gpios: the GPIO lines used for the external connectors\n\nThis doesn't tell me what the GPIOs functions are and should. For\nexample we have hpd-gpios for HDMI hotplug detect in HDMI connector\nbinding.\n\n> + See gpio/gpio.txt\n> +- extcon-connector-types: set to an unsigned integer value arrat representing the types\n> + of this connector, matched to the corresponding GPIO lines in the previous array.\n\nThis should be determined by the compatible string.\n\n> + Those are defined with unique IDs in \n> +- input-debounce: The number of microseconds to wait for the\n> + connector state to stabilize. This property is reused from pin control\n> + See pinctrl/pinctrl-bindings.txt\n> +\n> +Example:\n> +\n> +#include \n> +#include \n> +\n> +extcon {\n> + compatible = \"extcon-gpio\";\n> + extcon-gpios = <&gpio0 42 GPIO_ACTIVE_LOW>;\n> + extcon-connector-types = ;\n> + input-debounce = <20000>; /* 20 ms */\n> +};\n> diff --git a/include/dt-bindings/extcon/connectors.h b/include/dt-bindings/extcon/connectors.h\n> new file mode 100644\n> index 000000000000..61bed24eaadc\n> --- /dev/null\n> +++ b/include/dt-bindings/extcon/connectors.h\n> @@ -0,0 +1,38 @@\n> +#ifndef _DT_BINDINGS_EXTCON_CONNECTORS_H\n> +#define _DT_BINDINGS_EXTCON_CONNECTORS_H\n> +\n> +/* USB external connector */\n> +#define EXTCON_USB 1\n> +#define EXTCON_USB_HOST 2\n> +#define EXTCON_CHG_USB_SDP 5 /* Standard Downstream Port */\n> +#define EXTCON_CHG_USB_DCP 6 /* Dedicated Charging Port */\n> +#define EXTCON_CHG_USB_CDP 7 /* Charging Downstream Port */\n> +#define EXTCON_CHG_USB_ACA 8 /* Accessory Charger Adapter */\n> +#define EXTCON_CHG_USB_FAST 9\n> +#define EXTCON_CHG_USB_SLOW 10\n> +#define EXTCON_CHG_WPT 11 /* Wireless Power Transfer */\n> +#define EXTCON_CHG_USB_PD 12 /* USB Power Delivery */\n\nThese don't all look to be mutually exclusive.\n\nFor USB PD, isn't that discoverable?\n\n> +/* Jack external connector */\n> +#define EXTCON_JACK_MICROPHONE 20\n> +#define EXTCON_JACK_HEADPHONE 21\n> +#define EXTCON_JACK_LINE_IN 22\n> +#define EXTCON_JACK_LINE_OUT 23\n> +#define EXTCON_JACK_VIDEO_IN 24\n> +#define EXTCON_JACK_VIDEO_OUT 25\n> +#define EXTCON_JACK_SPDIF_IN 26 /* Sony Philips Digital InterFace */\n> +#define EXTCON_JACK_SPDIF_OUT 27\n\n> +/* Display external connector */\n> +#define EXTCON_DISP_HDMI 40 /* High-Definition Multimedia Interface */\n> +#define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link */\n> +#define EXTCON_DISP_DVI 42 /* Digital Visual Interface */\n> +#define EXTCON_DISP_VGA 43 /* Video Graphics Array */\n> +#define EXTCON_DISP_DP 44 /* Display Port */\n> +#define EXTCON_DISP_HMD 45 /* Head-Mounted Display */\n\nWe already have connector bindings for most of these. Use those as a\nmodel for whatever you want to do.\n\n> +/* Miscellaneous external connector */\n> +#define EXTCON_DOCK 60\n> +#define EXTCON_JIG 61\n> +#define EXTCON_MECHANICAL 62\n> +\n> +#define EXTCON_NUM 63\n> +\n> +#endif /* _DT_BINDINGS_EXTCON_CONNECTORS_H */\n> --\n> 2.13.5\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe devicetree\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n--\nTo unsubscribe from this list: send the line \"unsubscribe linux-gpio\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=robh@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y0dJX4X7tz9t1t\n\tfor ;\n\tMon, 25 Sep 2017 05:56:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752773AbdIXT40 (ORCPT );\n\tSun, 24 Sep 2017 15:56:26 -0400","from mail.kernel.org ([198.145.29.99]:54596 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752758AbdIXT40 (ORCPT );\n\tSun, 24 Sep 2017 15:56:26 -0400","from mail-qk0-f169.google.com (mail-qk0-f169.google.com\n\t[209.85.220.169])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 7B6F7214E3;\n\tSun, 24 Sep 2017 19:56:25 +0000 (UTC)","by mail-qk0-f169.google.com with SMTP id q8so4918610qkl.12;\n\tSun, 24 Sep 2017 12:56:25 -0700 (PDT)","by 10.12.209.75 with HTTP; Sun, 24 Sep 2017 12:56:04 -0700 (PDT)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 7B6F7214E3","X-Gm-Message-State":"AHPjjUgK3lxcCEVh52UFSz2BmKs7iOTSkiupfnCrvhtT2Z0gv6T3kKUK\n\t7O7V4yEa5vNEMENEVwmRgKoQtlSht41P0gzu4Q==","X-Google-Smtp-Source":"AOwi7QDS9LLKbNxJIjAhYh0emHXCIgS6SEeNdlccHUHaB79w4PdptFojkYfmQ69JQhy/bRn6zQAIop9CYzGbFuK1Ryg=","X-Received":"by 10.55.17.73 with SMTP id b70mr7630641qkh.270.1506282984636;\n\tSun, 24 Sep 2017 12:56:24 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170924145622.4031-2-linus.walleij@linaro.org>","References":"<20170924145622.4031-1-linus.walleij@linaro.org>\n\t<20170924145622.4031-2-linus.walleij@linaro.org>","From":"Rob Herring ","Date":"Sun, 24 Sep 2017 14:56:04 -0500","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","To":"Linus Walleij ","Cc":"MyungJoo Ham ,\n\tChanwoo Choi ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\tJohn Stultz ,\n\tMike Lockwood , Guenter Roeck ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1775067,"web_url":"http://patchwork.ozlabs.org/comment/1775067/","msgid":"","list_archive_url":null,"date":"2017-09-26T00:39:37","subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","submitter":{"id":7055,"url":"http://patchwork.ozlabs.org/api/people/7055/","name":"Linus Walleij","email":"linus.walleij@linaro.org"},"content":"On Sun, Sep 24, 2017 at 9:56 PM, Rob Herring wrote:\n> On Sun, Sep 24, 2017 at 9:56 AM, Linus Walleij wrote:\n>> Add some reasonable device tree bindings and also add the cable defines\n>> to the extcon include in since\n>> the GPIO extcon definately need to specify which cable/connector it is\n>> detecting.\n>>\n>> Adding the include file makes the (as it happens) Linux numbers into an\n>> ABI, but I do not see any better method. It is possible to define strings\n>> for all cable types but it seems like overkill, just reusing Linux'\n>> enumerators seems like a good idea.\n>>\n>> The binding supports any number of GPIOs and connectors, but the driver\n>> currently only supports one connector on one GPIO line.\n>\n> My view of extcon binding is it is fundamentally broken. I've\n> expressed this multiple times before.\n\nSorry, I'm a newcomer in this area, so I was not aware of this.\n\nSince this is a new binding consumer, is it something we can use\nas role model to fix it?\n\nIf I understand correctly from reading up on the mailing list the root of the\nproblem is something like this:\n\n\"extcon\" is a linuxism and ambiguous.\n\nThis driver should probe to \"gpio-connector\" or \"gpio-switch\" or something\nlike that if it should be generic. Or use very domain-specific compatible\nstrings (as you describe below), all supported maybe by the same driver\nin the end.\n\nThe reason it is its own subsystem and not part of input (IIUC) is that\nother drivers need to subscribe to events from these connectors,\nthey are not intended for userspace input such as keyboard or mice\nor similar.\n\nIn the DTS file you will find stuff using extcons as resources with\n = <&extcon>; phandles so they can look them up and subscribe\nto events.\n\nInput has a whole slew of \"events\" that correspond to some of these\nbut a different usecase, but that usecase is just a linuxism in turn, there\nis nothing saying another operating system could have a more versatile\ndefintion of \"input\".\n\nMaybe from a hardware description PoV these should all move over\nto devicetree/bindings/input - they all provice an input signal to the\nsystem. The fact that Linux split a subset of these into \"extcon\"\nis of no concern to the DT bindings.\n\nAnalogous with that some of the stuff in input/ should likely be\nmoved to a new output/ directory. Such as pwm-beeper,\npwm-vibrator etc. The fact that these are in the \"input\" subsystem\nin Linux is just another linuxism.\n\n> TL;DR: Anything extending the existing extcon binding will be NAKed.\n\nThat can be a reasonable stance.\n\nI'm just trying to get this into a state where the code does not stand in\nthe way of kernel clean-up. (Especially I want to get rid of the call\nto gpio_to_desc())\n\nAs stated in the cover letter the alternative will be to simply delete\nthe driver. But it's better if I can fix the situation, we can't have it\nlike this.\n\n>> +External Connector Using GPIO\n>\n> What kind of connector? All connectors external to something... And\n> GPIO is not a kind of connector on its own, but an implementation.\n\nYeah that is a problem with the whole subsystem I guess. Should\nI add a paragraph describing the usecases?\n\nThe whole thing is a bit\nof Androidism and is named like this because Android named it like\nthis in their kernel tree.\n\n>> +Required properties:\n>> +- compatible: should be \"extcon-gpio\"\n>> +- extcon-gpios: the GPIO lines used for the external connectors\n>\n> This doesn't tell me what the GPIOs functions are and should. For\n> example we have hpd-gpios for HDMI hotplug detect in HDMI connector\n> binding.\n\nThe idea is that this array corresponds to the extcon-connector-types\nright below, I'll clarify that if you think the overall idea is OK.\n\n>> + See gpio/gpio.txt\n>> +- extcon-connector-types: set to an unsigned integer value arrat representing the types\n>> + of this connector, matched to the corresponding GPIO lines in the previous array.\n>\n> This should be determined by the compatible string.\n\nSo a GPIO connector is very versatile. It is \"general purpose\" by definition,\nso it needs to be subclassed.\n\nOne possibility is to allow just one GPIO and have one comptible-string per\nuse case.\ncompatible = \"gpio-usb-connector\";\ncompatible = \"gpio-charger-connector\";\ncompatible = \"gpio-headphone-connector\";\netc etc\n\nThese bindings on the other hand, assume that the driver will be able\nto handle an array of gpios with an associated array of connector types,\nwhich reflects how many of the existing extcon-type driver hardware works:\na single PMIC providing some 5 misc extcons for example.\n\nFor this reason there is a generic compatible string and then the device\nis subclassed per-gpio with the per-gpio connector type.\n\n>> +/* USB external connector */\n>> +#define EXTCON_USB 1\n>> +#define EXTCON_USB_HOST 2\n>> +#define EXTCON_CHG_USB_SDP 5 /* Standard Downstream Port */\n>> +#define EXTCON_CHG_USB_DCP 6 /* Dedicated Charging Port */\n>> +#define EXTCON_CHG_USB_CDP 7 /* Charging Downstream Port */\n>> +#define EXTCON_CHG_USB_ACA 8 /* Accessory Charger Adapter */\n>> +#define EXTCON_CHG_USB_FAST 9\n>> +#define EXTCON_CHG_USB_SLOW 10\n>> +#define EXTCON_CHG_WPT 11 /* Wireless Power Transfer */\n>> +#define EXTCON_CHG_USB_PD 12 /* USB Power Delivery */\n>\n> These don't all look to be mutually exclusive.\n>\n> For USB PD, isn't that discoverable?\n\nSomeone else would have to answer, this is based on the current\nconnector types supported by the Linux kernel.\n\n>> +/* Display external connector */\n>> +#define EXTCON_DISP_HDMI 40 /* High-Definition Multimedia Interface */\n>> +#define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link */\n>> +#define EXTCON_DISP_DVI 42 /* Digital Visual Interface */\n>> +#define EXTCON_DISP_VGA 43 /* Video Graphics Array */\n>> +#define EXTCON_DISP_DP 44 /* Display Port */\n>> +#define EXTCON_DISP_HMD 45 /* Head-Mounted Display */\n>\n> We already have connector bindings for most of these. Use those as a\n> model for whatever you want to do.\n\nI guess they are not in Documentation/devicetree/bindings/extcon/*\n\nPlease point me in the right direction and I'll check it out.\n\nYours,\nLinus Walleij\n--\nTo unsubscribe from this list: send the line \"unsubscribe linux-gpio\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"C1QB/qfh\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1MXv0pV8z9t3F\n\tfor ;\n\tTue, 26 Sep 2017 10:39:42 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S935958AbdIZAjl (ORCPT );\n\tMon, 25 Sep 2017 20:39:41 -0400","from mail-it0-f52.google.com ([209.85.214.52]:50444 \"EHLO\n\tmail-it0-f52.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S934122AbdIZAjj (ORCPT\n\t); Mon, 25 Sep 2017 20:39:39 -0400","by mail-it0-f52.google.com with SMTP id y138so1176388itc.5\n\tfor ;\n\tMon, 25 Sep 2017 17:39:39 -0700 (PDT)","by 10.79.143.149 with HTTP; Mon, 25 Sep 2017 17:39:37 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=Hrk/k+cKpBKUWd/pNRo2ae+2SeToiEw8D119rL3/amo=;\n\tb=C1QB/qfhwtksQodaC5me6EIuXgC+N1WaRyJXbDN6sM1hkjrPcnHor+i8hTApc0DqAf\n\t8jiYutKql9D6nhK9q77WhvSqX93F8wWW4kq/ocsrYlRv0B2zWb5Qff3uQTwuKTsYZ5er\n\tlRauVLUe/wZBAlJHKscGfmMWRgozKJ/PI2nXA=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=Hrk/k+cKpBKUWd/pNRo2ae+2SeToiEw8D119rL3/amo=;\n\tb=f1vq1GKXiO1H5GVBZTL+FGgEeoGLEoJJlguAe7PUyGPAPJegiaR8Wh6S2tMQ/7ogkT\n\tUcO4qhukM3uKYhQxBV5NjCPOk2M9IYu7ceHRugEE07gdSXKEZfcQtCkfuWNCJUbIbcYK\n\t0KE6HyFnYTZXPtw6pfPXgtzTREZhZS9EI0dkmzjw0K5bmD1MiMGiYUb0NN5Nutm7wdsr\n\t2pWdSqdwWZI3fJRNCGCQm9Dn7J52dsr+xspVZKDR4Ze23wl2hWLcOH3ghMLJwPWxoW6E\n\tdqNwPRqkmOZC15GkbgrKaoMrl9YP7EcgvIWBVEx1qSpcvVDC0+jok6oGyqrKPjuevxqW\n\tADcQ==","X-Gm-Message-State":"AHPjjUh/86d+7eYy9wv133OgbsksvTySTpB6Si8oTSOGw2u54fSJw3JC\n\tG6RdZrdju5c7nKg2NK+FMJs/VDZHMkUlzz9Vfz5aQA==","X-Google-Smtp-Source":"AOwi7QCKECkjskySYOQXhLMaRV4mv14SUg4ldGkavKlhWLUdG/kStG7h/PcQ/8ke4TJc+8vQliSEpar0i86Slm898GY=","X-Received":"by 10.36.167.5 with SMTP id a5mr3216080itf.69.1506386379008; Mon,\n\t25 Sep 2017 17:39:39 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170924145622.4031-1-linus.walleij@linaro.org>\n\t<20170924145622.4031-2-linus.walleij@linaro.org>\n\t","From":"Linus Walleij ","Date":"Tue, 26 Sep 2017 02:39:37 +0200","Message-ID":"","Subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","To":"Rob Herring ","Cc":"MyungJoo Ham ,\n\tChanwoo Choi ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\tJohn Stultz ,\n\tMike Lockwood , Guenter Roeck ,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1775086,"web_url":"http://patchwork.ozlabs.org/comment/1775086/","msgid":"<59C9B52D.8050909@samsung.com>","list_archive_url":null,"date":"2017-09-26T02:02:21","subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","submitter":{"id":46832,"url":"http://patchwork.ozlabs.org/api/people/46832/","name":"Chanwoo Choi","email":"cw00.choi@samsung.com"},"content":"Hi Rob,\n\nOn 2017년 09월 26일 09:39, Linus Walleij wrote:\n> On Sun, Sep 24, 2017 at 9:56 PM, Rob Herring wrote:\n>> On Sun, Sep 24, 2017 at 9:56 AM, Linus Walleij wrote:\n>>> Add some reasonable device tree bindings and also add the cable defines\n>>> to the extcon include in since\n>>> the GPIO extcon definately need to specify which cable/connector it is\n>>> detecting.\n>>>\n>>> Adding the include file makes the (as it happens) Linux numbers into an\n>>> ABI, but I do not see any better method. It is possible to define strings\n>>> for all cable types but it seems like overkill, just reusing Linux'\n>>> enumerators seems like a good idea.\n>>>\n>>> The binding supports any number of GPIOs and connectors, but the driver\n>>> currently only supports one connector on one GPIO line.\n>>\n>> My view of extcon binding is it is fundamentally broken. I've\n>> expressed this multiple times before.\n> \n> Sorry, I'm a newcomer in this area, so I was not aware of this.\n> \n> Since this is a new binding consumer, is it something we can use\n> as role model to fix it?\n> \n> If I understand correctly from reading up on the mailing list the root of the\n> problem is something like this:\n> \n> \"extcon\" is a linuxism and ambiguous.\n> \n> This driver should probe to \"gpio-connector\" or \"gpio-switch\" or something\n> like that if it should be generic. Or use very domain-specific compatible\n> strings (as you describe below), all supported maybe by the same driver\n> in the end.\n> \n> The reason it is its own subsystem and not part of input (IIUC) is that\n> other drivers need to subscribe to events from these connectors,\n> they are not intended for userspace input such as keyboard or mice\n> or similar.\n> \n> In the DTS file you will find stuff using extcons as resources with\n> = <&extcon>; phandles so they can look them up and subscribe\n> to events.\n> \n> Input has a whole slew of \"events\" that correspond to some of these\n> but a different usecase, but that usecase is just a linuxism in turn, there\n> is nothing saying another operating system could have a more versatile\n> defintion of \"input\".\n> \n> Maybe from a hardware description PoV these should all move over\n> to devicetree/bindings/input - they all provice an input signal to the\n> system. The fact that Linux split a subset of these into \"extcon\"\n> is of no concern to the DT bindings.\n> \n> Analogous with that some of the stuff in input/ should likely be\n> moved to a new output/ directory. Such as pwm-beeper,\n> pwm-vibrator etc. The fact that these are in the \"input\" subsystem\n> in Linux is just another linuxism.\n> \n>> TL;DR: Anything extending the existing extcon binding will be NAKed.\n> \n> That can be a reasonable stance.\n> \n> I'm just trying to get this into a state where the code does not stand in\n> the way of kernel clean-up. (Especially I want to get rid of the call\n> to gpio_to_desc())\n> \n> As stated in the cover letter the alternative will be to simply delete\n> the driver. But it's better if I can fix the situation, we can't have it\n> like this.\n> \n>>> +External Connector Using GPIO\n>>\n>> What kind of connector? All connectors external to something... And\n>> GPIO is not a kind of connector on its own, but an implementation.\n> \n> Yeah that is a problem with the whole subsystem I guess. Should\n> I add a paragraph describing the usecases?\n> \n> The whole thing is a bit\n> of Androidism and is named like this because Android named it like\n> this in their kernel tree.\n> \n>>> +Required properties:\n>>> +- compatible: should be \"extcon-gpio\"\n>>> +- extcon-gpios: the GPIO lines used for the external connectors\n>>\n>> This doesn't tell me what the GPIOs functions are and should. For\n>> example we have hpd-gpios for HDMI hotplug detect in HDMI connector\n>> binding.\n> \n> The idea is that this array corresponds to the extcon-connector-types\n> right below, I'll clarify that if you think the overall idea is OK.\n> \n>>> + See gpio/gpio.txt\n>>> +- extcon-connector-types: set to an unsigned integer value arrat representing the types\n>>> + of this connector, matched to the corresponding GPIO lines in the previous array.\n>>\n>> This should be determined by the compatible string.\n> \n> So a GPIO connector is very versatile. It is \"general purpose\" by definition,\n> so it needs to be subclassed.\n> \n> One possibility is to allow just one GPIO and have one comptible-string per\n> use case.\n> compatible = \"gpio-usb-connector\";\n> compatible = \"gpio-charger-connector\";\n> compatible = \"gpio-headphone-connector\";\n> etc etc\n> \n> These bindings on the other hand, assume that the driver will be able\n> to handle an array of gpios with an associated array of connector types,\n> which reflects how many of the existing extcon-type driver hardware works:\n> a single PMIC providing some 5 misc extcons for example.\n> \n> For this reason there is a generic compatible string and then the device\n> is subclassed per-gpio with the per-gpio connector type.\n> \n>>> +/* USB external connector */\n>>> +#define EXTCON_USB 1\n>>> +#define EXTCON_USB_HOST 2\n>>> +#define EXTCON_CHG_USB_SDP 5 /* Standard Downstream Port */\n>>> +#define EXTCON_CHG_USB_DCP 6 /* Dedicated Charging Port */\n>>> +#define EXTCON_CHG_USB_CDP 7 /* Charging Downstream Port */\n>>> +#define EXTCON_CHG_USB_ACA 8 /* Accessory Charger Adapter */\n>>> +#define EXTCON_CHG_USB_FAST 9\n>>> +#define EXTCON_CHG_USB_SLOW 10\n>>> +#define EXTCON_CHG_WPT 11 /* Wireless Power Transfer */\n>>> +#define EXTCON_CHG_USB_PD 12 /* USB Power Delivery */\n>>\n>> These don't all look to be mutually exclusive.\n>>\n>> For USB PD, isn't that discoverable?\n\nCurrently, EXTCON_CHG_USB_PD is not used on any extcon provider drivers.\nI think that EXTCON_CHG_USB_PD is discoverable according to the H/W design\nsuch as using ADC.\n\nAlso, The charger connectors of extcon are related to power_supply subsystem\nbecause power_supply is in charge of behavior when the connector is attached/detached.\nSo, the extcon defines the EXTCON_CHG_USB_PD in order to detect this type.\n\n> \n> Someone else would have to answer, this is based on the current\n> connector types supported by the Linux kernel.\n> \n>>> +/* Display external connector */\n>>> +#define EXTCON_DISP_HDMI 40 /* High-Definition Multimedia Interface */\n>>> +#define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link */\n>>> +#define EXTCON_DISP_DVI 42 /* Digital Visual Interface */\n>>> +#define EXTCON_DISP_VGA 43 /* Video Graphics Array */\n>>> +#define EXTCON_DISP_DP 44 /* Display Port */\n>>> +#define EXTCON_DISP_HMD 45 /* Head-Mounted Display */\n>>\n>> We already have connector bindings for most of these. Use those as a\n>> model for whatever you want to do.\n> \n> I guess they are not in Documentation/devicetree/bindings/extcon/*\n> \n> Please point me in the right direction and I'll check it out.\n> \n> Yours,\n> Linus Walleij\n> \n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1PNM208Dz9t3R\n\tfor ;\n\tTue, 26 Sep 2017 12:02:27 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754008AbdIZCCZ (ORCPT );\n\tMon, 25 Sep 2017 22:02:25 -0400","from mailout3.samsung.com ([203.254.224.33]:51791 \"EHLO\n\tmailout3.samsung.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751377AbdIZCCX (ORCPT\n\t); Mon, 25 Sep 2017 22:02:23 -0400","from epcas1p1.samsung.com (unknown [182.195.41.45])\n\tby mailout3.samsung.com (KnoxPortal) with ESMTP id\n\t20170926020220epoutp038d93521f1f7273953919ad07b0a81aac~nxvF4JUUf2100621006epoutp03i;\n\tTue, 26 Sep 2017 02:02:20 +0000 (GMT)","from epsmges2p1.samsung.com (unknown [182.195.40.70]) by\n\tepcas1p2.samsung.com (KnoxPortal) with ESMTP id\n\t20170926020220epcas1p24d7f5a37775838a864e27dd53b0ee48a~nxvFmMH5D0813508135epcas1p2L;\n\tTue, 26 Sep 2017 02:02:20 +0000 (GMT)","from epcas2p4.samsung.com ( [182.195.41.56]) by\n\tepsmges2p1.samsung.com (Symantec Messaging Gateway) with SMTP id\n\tFF.0B.04232.C25B9C95; Tue, 26 Sep 2017 11:02:20 +0900 (KST)","from epsmgms2p2new.samsung.com (unknown [182.195.42.143]) by\n\tepcas2p1.samsung.com (KnoxPortal) with ESMTP id\n\t20170926020220epcas2p120a10b682bc55945cc757d2dccd0a0f4~nxvFS2yIT1846718467epcas2p1k;\n\tTue, 26 Sep 2017 02:02:20 +0000 (GMT)","from epmmp2 ( [203.254.227.17]) by epsmgms2p2new.samsung.com\n\t(Symantec Messaging Gateway) with SMTP id D9.94.06856.C25B9C95;\n\tTue, 26 Sep 2017 11:02:20 +0900 (KST)","from [10.113.62.212] by mmp2.samsung.com (Oracle Communications\n\tMessaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id\n\t<0OWV006FJ6ZVDA30@mmp2.samsung.com>;\n\tTue, 26 Sep 2017 11:02:19 +0900 (KST)"],"X-AuditID":"b6c32a45-d3bff70000001088-75-59c9b52ccec4","MIME-version":"1.0","Content-transfer-encoding":"8BIT","Content-type":"text/plain; charset=\"utf-8\"","Message-id":"<59C9B52D.8050909@samsung.com>","Date":"Tue, 26 Sep 2017 11:02:21 +0900","From":"Chanwoo Choi ","Organization":"Samsung Electronics","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101\n\tThunderbird/31.6.0","To":"Linus Walleij , Rob Herring ","Cc":"MyungJoo Ham ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\tJohn Stultz , Guenter Roeck ,\n\t\"devicetree@vger.kernel.org\" ","Subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","In-reply-to":"","X-Brightmail-Tracker":["H4sIAAAAAAAAA02Sa2xLYRjHvee0p2ej27synowwRyS2aK3VdYeYOykmWfhgCHWsb7axtktP\n\tJy5BhzATyy4u20yKjG2Ny26WDcuk5i5bjLmNIW4jkUiwEpfp6SH27cn/+T23fx6W1vxWRrEZ\n\tdhdx2oVMjglVNF6J4bUTz99cHnfr1Aje09au5O/80PIHflZSfL3nJ+LvXShn+NfH71B8d04V\n\tw/dfalLNZM113r2M+emDS4y52e9WmfMbvMj8uW50snIFmZZOBCtxRhN7qsOaYU9L5BYttcyx\n\txJvi9Fr9FD6Bi7YLNpLIzU1K1s7PyAyswkVvEDKzA1KyIIrcpOnTnI5sF4lOd4iuRG6lXm/Q\n\t6eMSdAaDQWecvGqqIT6ArCHpBX0nqaw+fmPDzv1KN6qYmIdCWMBGyD1/l8pDoawGNyHwVHyh\n\tpIQG+xHcPzD4H9Rx9AMjQzUI3uy4zUgJNY6Ab8U9ijzEsjQeA22d6yWZxjHQ+6VIIfM9CAqr\n\tqyiZj4Wrvl6VxCvweGi9HyrJTEBu7X0UbBmOx0LXt1dIiiNxCjR7+lRSPAwvgu6n32mpJ43r\n\tKDjzsjyYGIpNUHzOGywOwUvB33IxOBjwQwY+PamgpWGA50JNKSUfMxQ+XG9QyfFIeOutRTK/\n\tB0F9ec/f4lwEz6tzlDI1GW7l5VDyaWGQe+WXSm6qhtzdGhkxw4VDu5Asz4KT75bIx9+lwPe4\n\tUVGARpcN8Kvsv19lA/w6hmgvGk6yRFsaEQ1Zep0o2MRse5ou1WGrQ8Hfi53XhErak3wIs4gb\n\tonZTN5drlMIGcZPNh4CluWHqMfUBSW0VNm0mTofFmZ1JRB+KD9hdSEdFpjoCn2x3WfTGKXFG\n\tk8mQYOID/zVCvb3xQYoGpwkusp6QLOL8V0exIVFudPhMiGu2/fSp4UlFD40Nl7sWnv74++u6\n\te7v62ptveFKs+ZbEmS1zfnhmva+sGjTd6t5ftX3Bo1H+HSVrz3a2HWlvebd7S+NWS3/vhKgZ\n\tF3u+bnzdzS+rvXaClHb1N78IKz677ap23+KEfLMDWumFfkN457qCiFbXajXpeDbuYERGUs0K\n\tTiGmC/pY2ikKfwBlIQ7xkQMAAA==","H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsVy+t9jQV2drScjDVZO5bCYf+Qcq8WZ37oW\n\tU/4sZ7LYPP8Po8XlXXPYLJ4sPMNkcbtxBZvF/z072B04PDat6mTzuHNtD5vHzu8N7B59W1Yx\n\tenzeJBfAGsVlk5Kak1mWWqRvl8CVMeHbUqaCbxYVW5p7WRsYl+h0MXJySAiYSJyf+4oNxBYS\n\tWMcoMWmHCYjNKyAo8WPyPZYuRg4OZgF5iSOXsiFMdYkpU3K7GLmAqh8wSpy++pUNolxL4uih\n\tF+wgNSwCqhL7r3CBhNmAwvtf3AAr4RdQlLj64zEjSImoQIRE94lKkLCIgLfE7Ts/mUFGMgts\n\tYpI487+fFSQhLGAmMXn9KjaIXReZJP71/AUbxCkQLNH5pJt1AqPALCSXzkK4dBbCpQsYmVcx\n\tSqYWFOem5xYbFRjlpZbrFSfmFpfmpesl5+duYgQG+7bDWv07GB8viT/EKMDBqMTDe4PlZKQQ\n\ta2JZcWXuIUYJDmYlEV75zUAh3pTEyqrUovz4otKc1OJDjNIcLErivPz5xyKFBNITS1KzU1ML\n\tUotgskwcnFINjOVap2fNsP+/udpxdqjZIU+NDdWbrM9bPUryz1N8WJ68Mnf13L/hGnOUSy5O\n\terL/SsBvplIW5SNLJt1vNv399q1lX5G49Vu3hvuyryZ/b72cyxu0Qtn4p4q6ygc7DneT40yn\n\tcoPvfFun4eCopSrxy/X8AgFZ923/Hqyw0Y8yf3xr5YOJF169OqHEUpyRaKjFXFScCABpnv4/\n\tcgIAAA=="],"X-CMS-MailID":"20170926020220epcas2p120a10b682bc55945cc757d2dccd0a0f4","X-Msg-Generator":"CA","X-Sender-IP":"182.195.42.143","X-Local-Sender":"=?utf-8?b?7LWc7LCs7JqwG1RpemVuIFBsYXRmb3JtIExhYihTL1c=?=\n\t=?utf-8?b?7IS87YSwKRvsgrzshLHsoITsnpAbU2VuaW9yIEVuZ2luZWVy?=","X-Global-Sender":"=?utf-8?q?Chanwoo_Choi=1BTizen_Platform_Lab=2E=1BSamsung?=\n\t=?utf-8?q?_Electronics=1BSenior_Engineer?=","X-Sender-Code":"=?utf-8?q?C10=1BTELE=1BC10V8111?=","CMS-TYPE":"102P","DLP-Filter":"Pass","X-CFilter-Loop":"Reflected","X-CMS-RootMailID":"20170926003941epcas4p2a1987500f6e213b6a2ffe973ab1db922","X-RootMTR":"20170926003941epcas4p2a1987500f6e213b6a2ffe973ab1db922","References":"<20170924145622.4031-1-linus.walleij@linaro.org>\n\t<20170924145622.4031-2-linus.walleij@linaro.org>\n\t\n\t\n\t","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1790374,"web_url":"http://patchwork.ozlabs.org/comment/1790374/","msgid":"<59E882C9.9080506@samsung.com>","list_archive_url":null,"date":"2017-10-19T10:47:37","subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","submitter":{"id":46832,"url":"http://patchwork.ozlabs.org/api/people/46832/","name":"Chanwoo Choi","email":"cw00.choi@samsung.com"},"content":"Hi Rob,\n\n[snip]\n\n>>\n>>>> +External Connector Using GPIO\n>>>\n>>> What kind of connector? All connectors external to something... And\n>>> GPIO is not a kind of connector on its own, but an implementation.\n>>\n>> Yeah that is a problem with the whole subsystem I guess. Should\n>> I add a paragraph describing the usecases?\n>>\n>> The whole thing is a bit\n>> of Androidism and is named like this because Android named it like\n>> this in their kernel tree.\n>>\n>>>> +Required properties:\n>>>> +- compatible: should be \"extcon-gpio\"\n>>>> +- extcon-gpios: the GPIO lines used for the external connectors\n>>>\n>>> This doesn't tell me what the GPIOs functions are and should. For\n>>> example we have hpd-gpios for HDMI hotplug detect in HDMI connector\n>>> binding.\n>>\n>> The idea is that this array corresponds to the extcon-connector-types\n>> right below, I'll clarify that if you think the overall idea is OK.\n>>\n>>>> + See gpio/gpio.txt\n>>>> +- extcon-connector-types: set to an unsigned integer value arrat representing the types\n>>>> + of this connector, matched to the corresponding GPIO lines in the previous array.\n>>>\n>>> This should be determined by the compatible string.\n>>\n>> So a GPIO connector is very versatile. It is \"general purpose\" by definition,\n>> so it needs to be subclassed.\n>>\n>> One possibility is to allow just one GPIO and have one comptible-string per\n>> use case.\n>> compatible = \"gpio-usb-connector\";\n>> compatible = \"gpio-charger-connector\";\n>> compatible = \"gpio-headphone-connector\";\n>> etc etc\n>>\n>> These bindings on the other hand, assume that the driver will be able\n>> to handle an array of gpios with an associated array of connector types,\n>> which reflects how many of the existing extcon-type driver hardware works:\n>> a single PMIC providing some 5 misc extcons for example.\n>>\n>> For this reason there is a generic compatible string and then the device\n>> is subclassed per-gpio with the per-gpio connector type.\n\nThe \"drivers/input/keyboard/gpio_keys.c\" driver used the 'linux,code' property\nto get the key type as following in the device-tree file:\n\ngpio-keys { \n\tcompatible = \"gpio-keys\";\n\n\tkey-1 {\n\t\tgpios = <&gpio5 0 GPIO_ACTIVE_LOW>;\n\t\tlinux,code = ;\n\t\tlabel = \"SW2-1\";\n\t\twakeup-source;\n\t};\n\n\tkey-2 {\n\t\tgpios = <&gpio5 1 GPIO_ACTIVE_LOW>;\n\t\tlinux,code = ;\n\t\tlabel = \"SW2-2\";\n\t\twakeup-source;\n\t};\n};\n\n\nIMO, extcon-gpio.c uses the 'gpio-connectors' compatible\ninstead of 'extcon-gpio' and then define the connector type\nin the include/dt-bindings/extcon/connectors.h. How about this?\n\nFor example,\nIn the include/dt-bindings/extcon/connectors.h,\n\n#define CONNECTOR_USB\t\t1 /* EXTCON_USB */\n#define CONNECTOR_USB_HOST\t2 /* EXTCON_USB_HOST */\n#define CONNECTOR_CHG_USB_SDP\t5 /* EXTCON_CHG_USB_SDP */\n#define CONNECTOR_CHG_USB_DCP\t6 /* EXTCON_CHG_USB_DCP */\n#define CONNECTOR_CHG_USB_CDP\t7 /* EXTCON_CHG_USB_CDP */\n#define CONNECTOR_CHG_USB_ACA\t8 /* EXTCON_CHG_USB_ACA */\n...\n#define CONNECTOR_HDMI\t\t40 /* EXTCON_DISP_HDMI */\n...\n\nIn the devicetree example for 'gpio-connectors', \n\n\tusb-connector {\n\t\tcompatible = \"gpio-connectors\";\n\t\tgpios = <&gpio5 0 GPIO_ACTIVE_LOW>;\n\t\tlinux,connector = ;\n\t\twakeup-source;\n\t};\n\n\thdmi-connector {\n\t\tgpios = <&gpio5 1 GPIO_ACTIVE_LOW>;\n\t\tlinux,connector = ;\n\t\twakeup-source;\t\n\t};\n\n\n>>\n>>>> +/* USB external connector */\n>>>> +#define EXTCON_USB 1\n>>>> +#define EXTCON_USB_HOST 2\n>>>> +#define EXTCON_CHG_USB_SDP 5 /* Standard Downstream Port */\n>>>> +#define EXTCON_CHG_USB_DCP 6 /* Dedicated Charging Port */\n>>>> +#define EXTCON_CHG_USB_CDP 7 /* Charging Downstream Port */\n>>>> +#define EXTCON_CHG_USB_ACA 8 /* Accessory Charger Adapter */\n>>>> +#define EXTCON_CHG_USB_FAST 9\n>>>> +#define EXTCON_CHG_USB_SLOW 10\n>>>> +#define EXTCON_CHG_WPT 11 /* Wireless Power Transfer */\n>>>> +#define EXTCON_CHG_USB_PD 12 /* USB Power Delivery */\n>>>\n>>> These don't all look to be mutually exclusive.\n>>>\n>>> For USB PD, isn't that discoverable?\n> \n> Currently, EXTCON_CHG_USB_PD is not used on any extcon provider drivers.\n> I think that EXTCON_CHG_USB_PD is discoverable according to the H/W design\n> such as using ADC.\n> \n> Also, The charger connectors of extcon are related to power_supply subsystem\n> because power_supply is in charge of behavior when the connector is attached/detached.\n> So, the extcon defines the EXTCON_CHG_USB_PD in order to detect this type.\n> \n>>\n>> Someone else would have to answer, this is based on the current\n>> connector types supported by the Linux kernel.\n>>\n>>>> +/* Display external connector */\n>>>> +#define EXTCON_DISP_HDMI 40 /* High-Definition Multimedia Interface */\n>>>> +#define EXTCON_DISP_MHL 41 /* Mobile High-Definition Link */\n>>>> +#define EXTCON_DISP_DVI 42 /* Digital Visual Interface */\n>>>> +#define EXTCON_DISP_VGA 43 /* Video Graphics Array */\n>>>> +#define EXTCON_DISP_DP 44 /* Display Port */\n>>>> +#define EXTCON_DISP_HMD 45 /* Head-Mounted Display */\n>>>\n>>> We already have connector bindings for most of these. Use those as a\n>>> model for whatever you want to do.\n>>\n>> I guess they are not in Documentation/devicetree/bindings/extcon/*\n>>\n>> Please point me in the right direction and I'll check it out.\n>>\n>> Yours,\n>> Linus Walleij\n>>\n>>\n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yHlxp3S0Wz9t42\n\tfor ;\n\tThu, 19 Oct 2017 21:47:42 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751959AbdJSKrk (ORCPT );\n\tThu, 19 Oct 2017 06:47:40 -0400","from mailout1.samsung.com ([203.254.224.24]:41575 \"EHLO\n\tmailout1.samsung.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751922AbdJSKri (ORCPT\n\t); Thu, 19 Oct 2017 06:47:38 -0400","from epcas1p3.samsung.com (unknown [182.195.41.47])\n\tby mailout1.samsung.com (KnoxPortal) with ESMTP id\n\t20171019104736epoutp015a95a6a843f108a698990bda42f70788~u8vQ8IWye2117021170epoutp01H;\n\tThu, 19 Oct 2017 10:47:36 +0000 (GMT)","from epsmges2p4.samsung.com (unknown [182.195.40.66]) by\n\tepcas1p4.samsung.com (KnoxPortal) with ESMTP id\n\t20171019104735epcas1p4ecbad02003b9602a51cf8d6318140ffc~u8vQsdQaD1874218742epcas1p4c;\n\tThu, 19 Oct 2017 10:47:35 +0000 (GMT)","from epcas2p2.samsung.com ( [182.195.41.54]) by\n\tepsmges2p4.samsung.com (Symantec Messaging Gateway) with SMTP id\n\tC8.1D.04101.7C288E95; Thu, 19 Oct 2017 19:47:35 +0900 (KST)","from epsmgms2p2new.samsung.com (unknown [182.195.42.143]) by\n\tepcas2p4.samsung.com (KnoxPortal) with ESMTP id\n\t20171019104735epcas2p47b916a46d6984b61e15ffc6805726885~u8vQabUjj2639626396epcas2p4h;\n\tThu, 19 Oct 2017 10:47:35 +0000 (GMT)","from epmmp1.local.host ( [203.254.227.16]) by\n\tepsmgms2p2new.samsung.com (Symantec Messaging Gateway) with SMTP id\n\t9A.C2.06856.7C288E95; Thu, 19 Oct 2017 19:47:35 +0900 (KST)","from [10.113.62.212] by mmp1.samsung.com (Oracle Communications\n\tMessaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id\n\t<0OY2009MTGNAVT90@mmp1.samsung.com>;\n\tThu, 19 Oct 2017 19:47:35 +0900 (KST)"],"X-AuditID":"b6c32a48-c0fff70000001005-df-59e882c7adaa","Message-id":"<59E882C9.9080506@samsung.com>","Date":"Thu, 19 Oct 2017 19:47:37 +0900","From":"Chanwoo Choi ","Organization":"Samsung Electronics","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101\n\tThunderbird/31.6.0","MIME-version":"1.0","To":"Linus Walleij , Rob Herring ","Cc":"MyungJoo Ham ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\tJohn Stultz , Guenter Roeck ,\n\t\"devicetree@vger.kernel.org\" ","Subject":"Re: [PATCH 1/8] extcon: gpio: Add DT bindings","In-reply-to":"<59C9B52D.8050909@samsung.com>","Content-type":"text/plain; charset=\"utf-8\"","Content-transfer-encoding":"7bit","X-Brightmail-Tracker":["H4sIAAAAAAAAA01Se0hTYRTn293urtbqNnt8GJTdElLbcnPOa2gYRV3QP8QItJde3Yea7sHu\n\tFI0IzR5mEZYVQxZbkZrDKOeD+SB1RosYBZlWKEkpapJET7OMtd1r4H+/c77f75zfOd8hMHkF\n\tHk4UGizIbGCLKTxU3DkYpVV4z8xkxS54Ymj74+cS2vdHQV9fbBLRbfZFQA9123B68rZPRI9W\n\t3sNpf69bmkIwLudFnBkb6cWZrvkKKXOl3QmYb65N6ZLDKKkAsTpkjkCGPKOu0JCfTKUezN6b\n\tHa+NVSlUiXQCFWFg9SiZ2peWrthfWBywQkWUssUlgVQ6y3HUzt1JZmOJBUUUGDlLMnVEpVIr\n\tVbEJSrVardTEHduljg9QclBBx91Okal5R5n10hRWAdxUDQghIKmBD+te4DUglJCTbgCHGqvx\n\t4IOcnAdw3r65BhA8qfZ3jMDpAfDyU4dUCN4BeNF6RhwUyMho2Ln4FASxmIyE/a8aJUGMB/J9\n\tM2/4oqvJLXD41wTPWUdmwi77T6mgXQN/1b3j66wlU+Ho2AIWbICRLhG8/97Gk8JILax74OQL\n\thZAx8JPzCS/AyCg48/3aEt4M21rmeDEkR3HorWuRCnPug11nfyzhMDjrbV/CG+GUsxUIggsA\n\tttmCNoJBNYDjzZUSgRUHn9VUioQWq2D14F+psBgZrD4vFygM7L55FgjpPbBhOkNY41cRfFF1\n\tohZsql82aP0y3/XLfDsA5gTrkYnT5yNObdIoOVbPlRjylXlGvQvw1xfNuEH/8zQPIAlArZQ5\n\tbk5nySVsKVeu9wBIYNRamTF9Jksu07HlJ5HZmG0uKUacB8QHPuUqFr4uzxi4ZYMlW6VJjNVo\n\tteoELR24sA2y050jmXIyn7WgIoRMyPxfJyJCwivAlVz7wKkM8WTSqa2XxwccDv/LW0e3GaN3\n\tR/Z97CmauLF/p43pGE85ec55qXWFJPe8W8zc+TB8Y/i4psfqlzc9OYB889SjqrLPcy/ts/Dt\n\t0KEJfXdmSsNEaWRoFqYc8deapDlf9DbXa6vdZPc51NSIx6vcrrdYQ2Laddfa/GWUmCtgVdGY\n\tmWP/AVQrwViTAwAA","H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsVy+t9jAd3jTS8iDdYuEbGYf+Qcq8WZ37oW\n\tU/4sZ7LYPP8Po8XlXXPYLJ4sPMNkcbtxBZvF/z072B04PDat6mTzuHNtD5vHzu8N7B59W1Yx\n\tenzeJBfAGsVlk5Kak1mWWqRvl8CVsXXJNqaClToVM7qfMTcw7lDqYuTgkBAwkZjwS7uLkYtD\n\tSGAno8TW7fdZIJwHjBLnj71j72Lk5OAV0JLY9ucEI4jNIqAqceDKMlYQmw0ovv/FDTYQm19A\n\tUeLqj8eMIENFBSIkuk9UQrQKSvyYfI8FxBYR8Ja4fecnM8h8ZoFNTBJn/veDzREWMJOYvH4V\n\tG8TiT0wSWzfPAlvMKaAt8WbVMRaQocwC6hJTpuSChJkF5CU2r3nLPIFRYBaSHbMQqmYhqVrA\n\tyLyKUTK1oDg3PbfYqMAoL7Vcrzgxt7g0L10vOT93EyMw5Lcd1urfwfh4SfwhRgEORiUeXo8p\n\tzyOFWBPLiitzDzFKcDArifDmB7yIFOJNSaysSi3Kjy8qzUktPsQozcGiJM7Ln38sUkggPbEk\n\tNTs1tSC1CCbLxMEp1cAo/OK7zqxlM6JTLPnzQsT2hEsdjzjqO7dtWqhEU+qDg694POISDr26\n\tayjEFZqxzXNe3LQl+xz2Jjv6+f4LTFbLlw6NE7Wz27hQvDv71LGbsU7K3S7zDks9ylyidIWn\n\t9s+HhQtbnomGikdN13tyVPLOo495in7TzA/w+Pg3K7yUY1/0a0uL7yklluKMREMt5qLiRABw\n\tjC5ndQIAAA=="],"X-CMS-MailID":"20171019104735epcas2p47b916a46d6984b61e15ffc6805726885","X-Msg-Generator":"CA","X-Sender-IP":"182.195.42.143","X-Local-Sender":"=?utf-8?b?7LWc7LCs7JqwG1RpemVuIFBsYXRmb3JtIExhYihTL1c=?=\n\t=?utf-8?b?7IS87YSwKRvsgrzshLHsoITsnpAbU2VuaW9yIEVuZ2luZWVy?=","X-Global-Sender":"=?utf-8?q?Chanwoo_Choi=1BTizen_Platform_Lab=2E=1BSamsung?=\n\t=?utf-8?q?_Electronics=1BSenior_Engineer?=","X-Sender-Code":"=?utf-8?q?C10=1BTELE=1BC10V8111?=","CMS-TYPE":"102P","DLP-Filter":"Pass","X-CFilter-Loop":"Reflected","X-CMS-RootMailID":"20170926003941epcas4p2a1987500f6e213b6a2ffe973ab1db922","X-RootMTR":"20170926003941epcas4p2a1987500f6e213b6a2ffe973ab1db922","References":"<20170924145622.4031-1-linus.walleij@linaro.org>\n\t<20170924145622.4031-2-linus.walleij@linaro.org>\n\t\n\t\n\t\n\t<59C9B52D.8050909@samsung.com>","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}}]