[{"id":1755182,"web_url":"http://patchwork.ozlabs.org/comment/1755182/","msgid":"","list_archive_url":null,"date":"2017-08-23T13:07:54","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":21036,"url":"http://patchwork.ozlabs.org/api/people/21036/","name":"Ulf Hansson","email":"ulf.hansson@linaro.org"},"content":"On 23 August 2017 at 07:42, Kishon Vijay Abraham I wrote:\n> Add binding for the TI's sdhci-omap controller. This now includes only\n> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n> include all the properties.\n>\n> Signed-off-by: Kishon Vijay Abraham I \n> ---\n> Changes from v2:\n> *) Fixed example to use the updated compatible\n>\n> Changes from v1:\n> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n> of using the ti-omap-hsmmc.txt as suggested by Tony\n> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n> 1 file changed, 22 insertions(+)\n> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>\n> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> new file mode 100644\n> index 000000000000..139695ad2d58\n> --- /dev/null\n> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> @@ -0,0 +1,22 @@\n> +* TI OMAP SDHCI Controller\n> +\n> +Refer to mmc.txt for standard MMC bindings.\n> +\n> +Required properties:\n> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n> +\n> +Optional properties:\n> +- ti,dual-volt: boolean, supports dual voltage cards\n> +- ti,non-removable: non-removable slot (like eMMC)\n> +\n> +Example:\n> + mmc1: mmc@0x4809c000 {\n> + compatible = \"ti,dra7-sdhci\";\n> + reg = <0x4809c000 0x400>;\n> + ti,hwmods = \"mmc1\";\n> + ti,dual-volt;\n> + bus-width = <4>;\n> + vmmc-supply = <&vmmc>; /* phandle to regulator node */\n> + ti,non-removable;\n> + };\n> --\n> 2.11.0\n>\n\nI am wondering a bit on the long term plan here.\n\nIdeally at some point in future, we would like to remove the old\nomap_hsmmc driver, but from compatible string point of view, that\nmeans we first needs to deprecate the old ones for a while. Right?\n\nThat said, what is then the reason to why we should bring over the\nexisting omap_hsmmc bindings to the sdhci-omap bindings?\n\nFor example, \"ti,dual-volt\" can likely be replaced with something\nbetter that already exists (either a common mmc binding or an sdhci\nbinding). For \"ti,non-removable\", we already have a common mmc binding\n\"non-removable\" for this.\n\nKind regards\nUffe\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","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=\"Vm/ZXl45\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xcnmC6dj3z9s7m\n\tfor ;\n\tWed, 23 Aug 2017 23:08:11 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753973AbdHWNH5 (ORCPT\n\t);\n\tWed, 23 Aug 2017 09:07:57 -0400","from mail-qk0-f178.google.com ([209.85.220.178]:33040 \"EHLO\n\tmail-qk0-f178.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753956AbdHWNH4 (ORCPT\n\t); Wed, 23 Aug 2017 09:07:56 -0400","by mail-qk0-f178.google.com with SMTP id a77so466558qkb.0\n\tfor ;\n\tWed, 23 Aug 2017 06:07:55 -0700 (PDT)","by 10.200.63.69 with HTTP; Wed, 23 Aug 2017 06:07:54 -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=LcnQaan4bo9lSv3UB2ySCw7V+WiGAp8AI1PSJ1A9bRM=;\n\tb=Vm/ZXl45q0Vjhkk9ntNMS9QgwThGEgsK+MEKMITxOW6n+CYTsZ/JNOnmrD9p4lynLr\n\t7QqVGm+xfnFiLKMjjIw0XuXgnRUr2Nypy5mqEgEIVuWnklPnkleewA3eZCCN8tnbTcrn\n\t8W5ntroIC+6yDMubgkHmxFNPtbQBzCXPppTCk=","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=LcnQaan4bo9lSv3UB2ySCw7V+WiGAp8AI1PSJ1A9bRM=;\n\tb=b02VjsTcd8YEqqrii5aK7UAjoisQhP09nfr1St1y2M3q/sGhK5VACkOYBN3kbJHzZ3\n\tmfr4VWHigY8Trce5oG70cSYkMJKmFc6uUQzMYKiO99CMg0m/QieE0h8Qmjj6SAy5JObi\n\t9PZg/1/56DQb8w6X9xKQLWxpGYkS+N1ly6G1zy0NPAhCDqyZRcWI3Hwb4453WIvQnaMt\n\t7+bbT+QGfORaa8/RUussxQZQviU32Jlp/THaNL0QsVd87IoB9v+4xigRmYR5G1JbkVok\n\trPeEpym7uZZC6MFyWgvHgZB6O7U3fhXgxklya23gdK46PeuD7cCtvp80fIBY+TdbP3JE\n\tB/GA==","X-Gm-Message-State":"AHYfb5iN8yMTdXqnPVjvMCuGebQvFbLGHBJc+r+CaEpKi3jrJjDbMwrg\n\tbwp4vmgHoIn1v/iQBr47uCiljTYLunWn","X-Received":"by 10.55.185.2 with SMTP id j2mr3710660qkf.158.1503493675244;\n\tWed, 23 Aug 2017 06:07:55 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170823054246.23927-1-kishon@ti.com>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>","From":"Ulf Hansson ","Date":"Wed, 23 Aug 2017 15:07:54 +0200","Message-ID":"","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","To":"Kishon Vijay Abraham I ","Cc":"Adrian Hunter , Rob Herring ,\n\tTony Lindgren , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1755245,"web_url":"http://patchwork.ozlabs.org/comment/1755245/","msgid":"","list_archive_url":null,"date":"2017-08-23T13:56:35","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":14965,"url":"http://patchwork.ozlabs.org/api/people/14965/","name":"Kishon Vijay Abraham I","email":"kishon@ti.com"},"content":"Hi Uffe,\n\nOn Wednesday 23 August 2017 06:37 PM, Ulf Hansson wrote:\n> On 23 August 2017 at 07:42, Kishon Vijay Abraham I wrote:\n>> Add binding for the TI's sdhci-omap controller. This now includes only\n>> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n>> include all the properties.\n>>\n>> Signed-off-by: Kishon Vijay Abraham I \n>> ---\n>> Changes from v2:\n>> *) Fixed example to use the updated compatible\n>>\n>> Changes from v1:\n>> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n>> of using the ti-omap-hsmmc.txt as suggested by Tony\n>> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n>> 1 file changed, 22 insertions(+)\n>> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>\n>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>> new file mode 100644\n>> index 000000000000..139695ad2d58\n>> --- /dev/null\n>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>> @@ -0,0 +1,22 @@\n>> +* TI OMAP SDHCI Controller\n>> +\n>> +Refer to mmc.txt for standard MMC bindings.\n>> +\n>> +Required properties:\n>> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n>> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n>> +\n>> +Optional properties:\n>> +- ti,dual-volt: boolean, supports dual voltage cards\n>> +- ti,non-removable: non-removable slot (like eMMC)\n>> +\n>> +Example:\n>> + mmc1: mmc@0x4809c000 {\n>> + compatible = \"ti,dra7-sdhci\";\n>> + reg = <0x4809c000 0x400>;\n>> + ti,hwmods = \"mmc1\";\n>> + ti,dual-volt;\n>> + bus-width = <4>;\n>> + vmmc-supply = <&vmmc>; /* phandle to regulator node */\n>> + ti,non-removable;\n>> + };\n>> --\n>> 2.11.0\n>>\n> \n> I am wondering a bit on the long term plan here.\n> \n> Ideally at some point in future, we would like to remove the old\n> omap_hsmmc driver, but from compatible string point of view, that\n> means we first needs to deprecate the old ones for a while. Right?\n\nright but sdhci-omap is still lacking features that was present in omap_hsmmc\nlike context save/restore, SDIO support etc. I think we should deprecate\nomap_hsmmc compatible once we add all the features in sdhci-omap?\n> \n> That said, what is then the reason to why we should bring over the\n> existing omap_hsmmc bindings to the sdhci-omap bindings?\n\nThis is mainly for old dt compatibility. Even after removing the omap_hsmmc\ndriver, users should still be able to use newer kernel with their existing dtbs.\n\nThanks\nKishon\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"VsROd6wp\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xcpv85kHKz9s8V\n\tfor ;\n\tWed, 23 Aug 2017 23:59:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754053AbdHWN7B (ORCPT\n\t);\n\tWed, 23 Aug 2017 09:59:01 -0400","from fllnx209.ext.ti.com ([198.47.19.16]:10179 \"EHLO\n\tfllnx209.ext.ti.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754001AbdHWN66 (ORCPT\n\t); Wed, 23 Aug 2017 09:58:58 -0400","from dlelxv90.itg.ti.com ([172.17.2.17])\n\tby fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id v7NDuj5q004874; \n\tWed, 23 Aug 2017 08:56:45 -0500","from DFLE114.ent.ti.com (dfle114.ent.ti.com [10.64.6.35])\n\tby dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id v7NDue2o020914; \n\tWed, 23 Aug 2017 08:56:40 -0500","from DFLE104.ent.ti.com (10.64.6.25) by DFLE114.ent.ti.com\n\t(10.64.6.35) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tWed, 23 Aug 2017 08:56:39 -0500","from dlep33.itg.ti.com (157.170.170.75) by DFLE104.ent.ti.com\n\t(10.64.6.25) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Wed, 23 Aug 2017 08:56:39 -0500","from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id v7NDuaKS018542;\n\tWed, 23 Aug 2017 08:56:36 -0500"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1503496605;\n\tbh=Gn+Rc9pL14Kk2zz+eWInxeZ6aZJ9Z7GKiOYFJofjAEk=;\n\th=Subject:To:References:CC:From:Date:In-Reply-To;\n\tb=VsROd6wpgBfX9k1JH1tBdSi9rLDwQcqeUGxM9srBcNI4wpXlVcO2a7GSFdsuzvsjp\n\tSZb67P6fxEHIkphRzwpJQmn1R1frRf8j46sWz3IcD8kMjU508b6NujGHFVfioNzU5v\n\ts2HsIJZZR0UkaOt+RhkwgeRJiH8jhJHeYMUupN6c=","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","To":"Ulf Hansson ","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t","CC":"Adrian Hunter , Rob Herring ,\n\tTony Lindgren , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","From":"Kishon Vijay Abraham I ","Message-ID":"","Date":"Wed, 23 Aug 2017 19:26:35 +0530","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"7bit","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1756263,"web_url":"http://patchwork.ozlabs.org/comment/1756263/","msgid":"","list_archive_url":null,"date":"2017-08-24T11:29:39","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":21036,"url":"http://patchwork.ozlabs.org/api/people/21036/","name":"Ulf Hansson","email":"ulf.hansson@linaro.org"},"content":"On 23 August 2017 at 15:56, Kishon Vijay Abraham I wrote:\n> Hi Uffe,\n>\n> On Wednesday 23 August 2017 06:37 PM, Ulf Hansson wrote:\n>> On 23 August 2017 at 07:42, Kishon Vijay Abraham I wrote:\n>>> Add binding for the TI's sdhci-omap controller. This now includes only\n>>> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n>>> include all the properties.\n>>>\n>>> Signed-off-by: Kishon Vijay Abraham I \n>>> ---\n>>> Changes from v2:\n>>> *) Fixed example to use the updated compatible\n>>>\n>>> Changes from v1:\n>>> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n>>> of using the ti-omap-hsmmc.txt as suggested by Tony\n>>> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n>>> 1 file changed, 22 insertions(+)\n>>> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>>\n>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>> new file mode 100644\n>>> index 000000000000..139695ad2d58\n>>> --- /dev/null\n>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>> @@ -0,0 +1,22 @@\n>>> +* TI OMAP SDHCI Controller\n>>> +\n>>> +Refer to mmc.txt for standard MMC bindings.\n>>> +\n>>> +Required properties:\n>>> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n>>> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n>>> +\n>>> +Optional properties:\n>>> +- ti,dual-volt: boolean, supports dual voltage cards\n>>> +- ti,non-removable: non-removable slot (like eMMC)\n>>> +\n>>> +Example:\n>>> + mmc1: mmc@0x4809c000 {\n>>> + compatible = \"ti,dra7-sdhci\";\n>>> + reg = <0x4809c000 0x400>;\n>>> + ti,hwmods = \"mmc1\";\n>>> + ti,dual-volt;\n>>> + bus-width = <4>;\n>>> + vmmc-supply = <&vmmc>; /* phandle to regulator node */\n>>> + ti,non-removable;\n>>> + };\n>>> --\n>>> 2.11.0\n>>>\n>>\n>> I am wondering a bit on the long term plan here.\n>>\n>> Ideally at some point in future, we would like to remove the old\n>> omap_hsmmc driver, but from compatible string point of view, that\n>> means we first needs to deprecate the old ones for a while. Right?\n>\n> right but sdhci-omap is still lacking features that was present in omap_hsmmc\n> like context save/restore, SDIO support etc. I think we should deprecate\n> omap_hsmmc compatible once we add all the features in sdhci-omap?\n>>\n>> That said, what is then the reason to why we should bring over the\n>> existing omap_hsmmc bindings to the sdhci-omap bindings?\n>\n> This is mainly for old dt compatibility. Even after removing the omap_hsmmc\n> driver, users should still be able to use newer kernel with their existing dtbs.\n\nI guess we have two options.\n\n1) Allow us to invent and use new bindings - and a new compatible.\nWhen everything is implemented in sdhci-omap, we can deprecate the old\nomap_hsmmc driver and its corresponding compatible/bindings. At some\npoint later we can remove the legacy driver/bindings altogether - of\ncourse that might take a while. This option allows us to re-think some\nof the old bindings and really clean up some if its related code. For\nexample, I think \"ti,dual-volt\" is a bad binding. Instead it would be\nbetter to use the existing mmc bindings about which speed mode the\ncontroller/board supports (as the voltage level comes with it).\n\n2) Invent only a new compatible, but stick to use the old omap hsmmc\nbindings and thus also deploy the similar code dealing with them. When\neverything is implemented move the old omap_hsmmc compatibles into the\nnew sdhci-omap driver and them remove the old omap_hsmmc driver. At\nthat point we could also deprecate the old omap hsmmc compatibles, but\nto me that is rather pointless.\n\nThe two options has different advantages, feel free to pick any of them!\n\nKind regards\nUffe\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","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=\"HbbPxaj6\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdMXV1X1Dz9s8P\n\tfor ;\n\tThu, 24 Aug 2017 21:30:02 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752227AbdHXL3n (ORCPT\n\t);\n\tThu, 24 Aug 2017 07:29:43 -0400","from mail-qt0-f169.google.com ([209.85.216.169]:35107 \"EHLO\n\tmail-qt0-f169.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752160AbdHXL3l (ORCPT\n\t); Thu, 24 Aug 2017 07:29:41 -0400","by mail-qt0-f169.google.com with SMTP id o15so1413452qtg.2\n\tfor ;\n\tThu, 24 Aug 2017 04:29:40 -0700 (PDT)","by 10.200.63.69 with HTTP; Thu, 24 Aug 2017 04:29:39 -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=VIhdm9yEeeTXzPnMX0FRgdOxbeEM6+MpVB+ZuXGrer8=;\n\tb=HbbPxaj6f932iaNAz57t8f1t/boZM5YrjcRiWasSWP5fWLLYcmwfS8LeOiaG1BWmlv\n\tdoiyY3fYyUhfSQEen4oOKazHdaImhjecNrGBsY2gIf+TFHlb1SENc+DQ4CFcPpCaZh4+\n\t9Z9hBfTQEl34AfvOUPYoJm0k4Ci8ej3HXXu+E=","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=VIhdm9yEeeTXzPnMX0FRgdOxbeEM6+MpVB+ZuXGrer8=;\n\tb=bOCgVIsDv29Hbom67HLEuCu2LWoEecxelMsXiiU5Tv+AMPUKCJ3gU7RdoWMcxYYBKo\n\tVVDwSpeFybRqX6L//wOe9XgQQ5aYvyT0pwGMFTHtPRcaYeLtoaSElfklbzV23mY8l5LR\n\t/h6zitvBEpPcL0cE1+7dlPPCNvp46IguGx4eldHUZga4VbOuHRQ3m1Aj3HDflQQyNKR9\n\tg4YGcIIW1l7AP0lggRdtjB8QXE8iconXIrLv4KXetcRfvZm1OknkNnCfl5BDDawC3jY4\n\tM9pFRa0geyRYEucKQI+yZCdzgdQ0RavKOjWCA6lCXgBeOGDrYPPoL8n/cPfhchMiO+wN\n\tHG/w==","X-Gm-Message-State":"AHYfb5gphGWpMTwgS5lPwYeiXweHIcKOcHQ90gYNJVqEzbV8/LDF5rzF\n\tGdJkHV8FjVNolF3bMAKPeUV0OiwqE3D4","X-Received":"by 10.200.55.217 with SMTP id e25mr75445qtc.221.1503574180352;\n\tThu, 24 Aug 2017 04:29:40 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t","From":"Ulf Hansson ","Date":"Thu, 24 Aug 2017 13:29:39 +0200","Message-ID":"","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","To":"Kishon Vijay Abraham I ","Cc":"Adrian Hunter , Rob Herring ,\n\tTony Lindgren , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759229,"web_url":"http://patchwork.ozlabs.org/comment/1759229/","msgid":"<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>","list_archive_url":null,"date":"2017-08-29T11:20:22","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":14965,"url":"http://patchwork.ozlabs.org/api/people/14965/","name":"Kishon Vijay Abraham I","email":"kishon@ti.com"},"content":"Hi Uffe,\n\nOn Thursday 24 August 2017 04:59 PM, Ulf Hansson wrote:\n> On 23 August 2017 at 15:56, Kishon Vijay Abraham I wrote:\n>> Hi Uffe,\n>>\n>> On Wednesday 23 August 2017 06:37 PM, Ulf Hansson wrote:\n>>> On 23 August 2017 at 07:42, Kishon Vijay Abraham I wrote:\n>>>> Add binding for the TI's sdhci-omap controller. This now includes only\n>>>> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n>>>> include all the properties.\n>>>>\n>>>> Signed-off-by: Kishon Vijay Abraham I \n>>>> ---\n>>>> Changes from v2:\n>>>> *) Fixed example to use the updated compatible\n>>>>\n>>>> Changes from v1:\n>>>> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n>>>> of using the ti-omap-hsmmc.txt as suggested by Tony\n>>>> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n>>>> 1 file changed, 22 insertions(+)\n>>>> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>>>\n>>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>>> new file mode 100644\n>>>> index 000000000000..139695ad2d58\n>>>> --- /dev/null\n>>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>>> @@ -0,0 +1,22 @@\n>>>> +* TI OMAP SDHCI Controller\n>>>> +\n>>>> +Refer to mmc.txt for standard MMC bindings.\n>>>> +\n>>>> +Required properties:\n>>>> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n>>>> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n>>>> +\n>>>> +Optional properties:\n>>>> +- ti,dual-volt: boolean, supports dual voltage cards\n>>>> +- ti,non-removable: non-removable slot (like eMMC)\n>>>> +\n>>>> +Example:\n>>>> + mmc1: mmc@0x4809c000 {\n>>>> + compatible = \"ti,dra7-sdhci\";\n>>>> + reg = <0x4809c000 0x400>;\n>>>> + ti,hwmods = \"mmc1\";\n>>>> + ti,dual-volt;\n>>>> + bus-width = <4>;\n>>>> + vmmc-supply = <&vmmc>; /* phandle to regulator node */\n>>>> + ti,non-removable;\n>>>> + };\n>>>> --\n>>>> 2.11.0\n>>>>\n>>>\n>>> I am wondering a bit on the long term plan here.\n>>>\n>>> Ideally at some point in future, we would like to remove the old\n>>> omap_hsmmc driver, but from compatible string point of view, that\n>>> means we first needs to deprecate the old ones for a while. Right?\n>>\n>> right but sdhci-omap is still lacking features that was present in omap_hsmmc\n>> like context save/restore, SDIO support etc. I think we should deprecate\n>> omap_hsmmc compatible once we add all the features in sdhci-omap?\n>>>\n>>> That said, what is then the reason to why we should bring over the\n>>> existing omap_hsmmc bindings to the sdhci-omap bindings?\n>>\n>> This is mainly for old dt compatibility. Even after removing the omap_hsmmc\n>> driver, users should still be able to use newer kernel with their existing dtbs.\n> \n> I guess we have two options.\n> \n> 1) Allow us to invent and use new bindings - and a new compatible.\n> When everything is implemented in sdhci-omap, we can deprecate the old\n> omap_hsmmc driver and its corresponding compatible/bindings. At some\n> point later we can remove the legacy driver/bindings altogether - of\n> course that might take a while. This option allows us to re-think some\n> of the old bindings and really clean up some if its related code. For\n> example, I think \"ti,dual-volt\" is a bad binding. Instead it would be\n> better to use the existing mmc bindings about which speed mode the\n> controller/board supports (as the voltage level comes with it).\n> \n> 2) Invent only a new compatible, but stick to use the old omap hsmmc\n> bindings and thus also deploy the similar code dealing with them. When\n> everything is implemented move the old omap_hsmmc compatibles into the\n> new sdhci-omap driver and them remove the old omap_hsmmc driver. At\n> that point we could also deprecate the old omap hsmmc compatibles, but\n> to me that is rather pointless.\n> \n> The two options has different advantages, feel free to pick any of them!\n\nOkay. I'll send a new version with option '1' (new compatible/new bindings).\n\nAnd when we deprecate the omap_hsmmc driver (some time later), we'll add\nsupport for the legacy bindings in sdhci-omap driver (so that old dtbs continue\nto work). Tony, are you okay with this?\n\nThanks\nKishon\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"uMHSWWMY\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhR7105Swz9t6f\n\tfor ;\n\tTue, 29 Aug 2017 21:21:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752936AbdH2LVM (ORCPT\n\t);\n\tTue, 29 Aug 2017 07:21:12 -0400","from fllnx210.ext.ti.com ([198.47.19.17]:24145 \"EHLO\n\tfllnx210.ext.ti.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752931AbdH2LVK (ORCPT\n\t); Tue, 29 Aug 2017 07:21:10 -0400","from dflxv15.itg.ti.com ([128.247.5.124])\n\tby fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id v7TBKRW5028390; \n\tTue, 29 Aug 2017 06:20:27 -0500","from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25])\n\tby dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id v7TBKRaH002582;\n\tTue, 29 Aug 2017 06:20:27 -0500","from DFLE114.ent.ti.com (10.64.6.35) by DFLE104.ent.ti.com\n\t(10.64.6.25) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tTue, 29 Aug 2017 06:20:27 -0500","from dlep33.itg.ti.com (157.170.170.75) by DFLE114.ent.ti.com\n\t(10.64.6.35) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Tue, 29 Aug 2017 06:20:27 -0500","from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id v7TBKMAZ017660;\n\tTue, 29 Aug 2017 06:20:23 -0500"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1504005627;\n\tbh=zPyWXYqr/GlAMfQti36kVzIGlXQiQbb9K+p3lp8DXWM=;\n\th=Subject:To:References:CC:From:Date:In-Reply-To;\n\tb=uMHSWWMYyZJo+e6hUDecArpd5RLh7ALrBgkx2IWxCszDM63n+qF677gVwEMlWT5co\n\tY8p12/xeuIWY6O4MGhq56QgVh5qcWyO6hdmuDc9mw8cPcbNUa+CpYs/sO1D89Xe1FT\n\tvzo/bvQb0ulNLawlO4zr4kPZJLgOCN0cfNTZjIrU=","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","To":"Ulf Hansson ","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t","CC":"Adrian Hunter , Rob Herring ,\n\tTony Lindgren , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","From":"Kishon Vijay Abraham I ","Message-ID":"<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>","Date":"Tue, 29 Aug 2017 16:50:22 +0530","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"7bit","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759254,"web_url":"http://patchwork.ozlabs.org/comment/1759254/","msgid":"<20170829115050.3axlr5uysmqlhvd2@earth>","list_archive_url":null,"date":"2017-08-29T11:50:50","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":71508,"url":"http://patchwork.ozlabs.org/api/people/71508/","name":"Sebastian Reichel","email":"sebastian.reichel@collabora.co.uk"},"content":"Hi,\n\nOn Tue, Aug 29, 2017 at 04:50:22PM +0530, Kishon Vijay Abraham I wrote:\n> Hi Uffe,\n> \n> On Thursday 24 August 2017 04:59 PM, Ulf Hansson wrote:\n> > On 23 August 2017 at 15:56, Kishon Vijay Abraham I wrote:\n> >> Hi Uffe,\n> >>\n> >> On Wednesday 23 August 2017 06:37 PM, Ulf Hansson wrote:\n> >>> On 23 August 2017 at 07:42, Kishon Vijay Abraham I wrote:\n> >>>> Add binding for the TI's sdhci-omap controller. This now includes only\n> >>>> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n> >>>> include all the properties.\n> >>>>\n> >>>> Signed-off-by: Kishon Vijay Abraham I \n> >>>> ---\n> >>>> Changes from v2:\n> >>>> *) Fixed example to use the updated compatible\n> >>>>\n> >>>> Changes from v1:\n> >>>> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n> >>>> of using the ti-omap-hsmmc.txt as suggested by Tony\n> >>>> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n> >>>> 1 file changed, 22 insertions(+)\n> >>>> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> >>>>\n> >>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> >>>> new file mode 100644\n> >>>> index 000000000000..139695ad2d58\n> >>>> --- /dev/null\n> >>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> >>>> @@ -0,0 +1,22 @@\n> >>>> +* TI OMAP SDHCI Controller\n> >>>> +\n> >>>> +Refer to mmc.txt for standard MMC bindings.\n> >>>> +\n> >>>> +Required properties:\n> >>>> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n> >>>> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n> >>>> +\n> >>>> +Optional properties:\n> >>>> +- ti,dual-volt: boolean, supports dual voltage cards\n> >>>> +- ti,non-removable: non-removable slot (like eMMC)\n> >>>> +\n> >>>> +Example:\n> >>>> + mmc1: mmc@0x4809c000 {\n> >>>> + compatible = \"ti,dra7-sdhci\";\n> >>>> + reg = <0x4809c000 0x400>;\n> >>>> + ti,hwmods = \"mmc1\";\n> >>>> + ti,dual-volt;\n> >>>> + bus-width = <4>;\n> >>>> + vmmc-supply = <&vmmc>; /* phandle to regulator node */\n> >>>> + ti,non-removable;\n> >>>> + };\n> >>>> --\n> >>>> 2.11.0\n> >>>>\n> >>>\n> >>> I am wondering a bit on the long term plan here.\n> >>>\n> >>> Ideally at some point in future, we would like to remove the old\n> >>> omap_hsmmc driver, but from compatible string point of view, that\n> >>> means we first needs to deprecate the old ones for a while. Right?\n> >>\n> >> right but sdhci-omap is still lacking features that was present in omap_hsmmc\n> >> like context save/restore, SDIO support etc. I think we should deprecate\n> >> omap_hsmmc compatible once we add all the features in sdhci-omap?\n> >>>\n> >>> That said, what is then the reason to why we should bring over the\n> >>> existing omap_hsmmc bindings to the sdhci-omap bindings?\n> >>\n> >> This is mainly for old dt compatibility. Even after removing the omap_hsmmc\n> >> driver, users should still be able to use newer kernel with their existing dtbs.\n> > \n> > I guess we have two options.\n> > \n> > 1) Allow us to invent and use new bindings - and a new compatible.\n> > When everything is implemented in sdhci-omap, we can deprecate the old\n> > omap_hsmmc driver and its corresponding compatible/bindings. At some\n> > point later we can remove the legacy driver/bindings altogether - of\n> > course that might take a while. This option allows us to re-think some\n> > of the old bindings and really clean up some if its related code. For\n> > example, I think \"ti,dual-volt\" is a bad binding. Instead it would be\n> > better to use the existing mmc bindings about which speed mode the\n> > controller/board supports (as the voltage level comes with it).\n> > \n> > 2) Invent only a new compatible, but stick to use the old omap hsmmc\n> > bindings and thus also deploy the similar code dealing with them. When\n> > everything is implemented move the old omap_hsmmc compatibles into the\n> > new sdhci-omap driver and them remove the old omap_hsmmc driver. At\n> > that point we could also deprecate the old omap hsmmc compatibles, but\n> > to me that is rather pointless.\n> > \n> > The two options has different advantages, feel free to pick any of them!\n> \n> Okay. I'll send a new version with option '1' (new compatible/new bindings).\n> \n> And when we deprecate the omap_hsmmc driver (some time later), we'll add\n> support for the legacy bindings in sdhci-omap driver (so that old dtbs continue\n> to work). Tony, are you okay with this?\n\nI think you should Cc Rob Herring and Mark Rutland (DT binding\nmaintainers). This sounds like \"I use DT to describe driver\nbehaviour\" instead of \"I use DT to describe hardware\".\n\nI would expect the conversion to look like the one done for UART,\nsee CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the\nsame compatible value and you can choose using kernel configuration.\n\n-- Sebastian","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhRmK5WL3z9s65\n\tfor ;\n\tTue, 29 Aug 2017 21:50:57 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751263AbdH2Lu4 (ORCPT\n\t);\n\tTue, 29 Aug 2017 07:50:56 -0400","from bhuna.collabora.co.uk ([46.235.227.227]:56311 \"EHLO\n\tbhuna.collabora.co.uk\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751241AbdH2Luy (ORCPT\n\t); Tue, 29 Aug 2017 07:50:54 -0400","from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender:\n\tsre) with ESMTPSA id 375D626B453"],"Date":"Tue, 29 Aug 2017 13:50:50 +0200","From":"Sebastian Reichel ","To":"Kishon Vijay Abraham I ","Cc":"Ulf Hansson ,\n\tAdrian Hunter ,\n\tRob Herring , \n\tTony Lindgren , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170829115050.3axlr5uysmqlhvd2@earth>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha512;\n\tprotocol=\"application/pgp-signature\"; boundary=\"vvmy2soxjwr7yu7c\"","Content-Disposition":"inline","In-Reply-To":"<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>","User-Agent":"NeoMutt/20170609 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759363,"web_url":"http://patchwork.ozlabs.org/comment/1759363/","msgid":"<20170829135822.GR6008@atomide.com>","list_archive_url":null,"date":"2017-08-29T13:58:23","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":365,"url":"http://patchwork.ozlabs.org/api/people/365/","name":"Tony Lindgren","email":"tony@atomide.com"},"content":"* Sebastian Reichel [170829 04:51]:\n> On Tue, Aug 29, 2017 at 04:50:22PM +0530, Kishon Vijay Abraham I wrote:\n> > On Thursday 24 August 2017 04:59 PM, Ulf Hansson wrote:\n> > > I guess we have two options.\n> > > \n> > > 1) Allow us to invent and use new bindings - and a new compatible.\n> > > When everything is implemented in sdhci-omap, we can deprecate the old\n> > > omap_hsmmc driver and its corresponding compatible/bindings. At some\n> > > point later we can remove the legacy driver/bindings altogether - of\n> > > course that might take a while. This option allows us to re-think some\n> > > of the old bindings and really clean up some if its related code. For\n> > > example, I think \"ti,dual-volt\" is a bad binding. Instead it would be\n> > > better to use the existing mmc bindings about which speed mode the\n> > > controller/board supports (as the voltage level comes with it).\n> > > \n> > > 2) Invent only a new compatible, but stick to use the old omap hsmmc\n> > > bindings and thus also deploy the similar code dealing with them. When\n> > > everything is implemented move the old omap_hsmmc compatibles into the\n> > > new sdhci-omap driver and them remove the old omap_hsmmc driver. At\n> > > that point we could also deprecate the old omap hsmmc compatibles, but\n> > > to me that is rather pointless.\n> > > \n> > > The two options has different advantages, feel free to pick any of them!\n> > \n> > Okay. I'll send a new version with option '1' (new compatible/new bindings).\n\nAgreed.\n\n> > And when we deprecate the omap_hsmmc driver (some time later), we'll add\n> > support for the legacy bindings in sdhci-omap driver (so that old dtbs continue\n> > to work). Tony, are you okay with this?\n> \n> I think you should Cc Rob Herring and Mark Rutland (DT binding\n> maintainers). This sounds like \"I use DT to describe driver\n> behaviour\" instead of \"I use DT to describe hardware\".\n\nYes please.\n\n> I would expect the conversion to look like the one done for UART,\n> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the\n> same compatible value and you can choose using kernel configuration.\n\nThat does not work unfortunately :( We are now stuck in a situation\nwhere two drivers are attempting to probe with the same compatible\nand we can't enable 8250_OMAP because of the user space breakage\nwith the device names. And I'm actuallly thinking we should add a\nnew compatible for 8250-omap to be able to start enabling it one\nboard at a time.\n\nIt's best to enable devices to use the new compatible as things are\ntested rather than hope for some magic \"flag day\" flip that might\nnever happen. Having two days attempting to probe with the same\nbinding just won't work.\n\nSo yeah, I agree with Kishon that we should stick with generic\nand sdhci bindings. And then we can start already using it for\nboards that can use it, then eventually when we're ready, start\nparsing also the legacy bindings and maybe drop the old driver.\n\nRegards,\n\nTony\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhVbm66tPz9t38\n\tfor ;\n\tTue, 29 Aug 2017 23:58:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752560AbdH2N62 convert rfc822-to-8bit (ORCPT\n\t);\n\tTue, 29 Aug 2017 09:58:28 -0400","from muru.com ([72.249.23.125]:38342 \"EHLO muru.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751516AbdH2N61 (ORCPT );\n\tTue, 29 Aug 2017 09:58:27 -0400","from atomide.com (localhost [127.0.0.1])\n\tby muru.com (Postfix) with ESMTPS id E8900813A;\n\tTue, 29 Aug 2017 13:58:46 +0000 (UTC)"],"Date":"Tue, 29 Aug 2017 06:58:23 -0700","From":"Tony Lindgren ","To":"Sebastian Reichel ","Cc":"Kishon Vijay Abraham I ,\n\tUlf Hansson ,\n\tAdrian Hunter ,\n\tRob Herring , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170829135822.GR6008@atomide.com>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>\n\t<20170829115050.3axlr5uysmqlhvd2@earth>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","Content-Transfer-Encoding":"8BIT","In-Reply-To":"<20170829115050.3axlr5uysmqlhvd2@earth>","User-Agent":"Mutt/1.8.3 (2017-05-23)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759404,"web_url":"http://patchwork.ozlabs.org/comment/1759404/","msgid":"<20170829144338.GY6008@atomide.com>","list_archive_url":null,"date":"2017-08-29T14:43:38","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":365,"url":"http://patchwork.ozlabs.org/api/people/365/","name":"Tony Lindgren","email":"tony@atomide.com"},"content":"* Tony Lindgren [170829 06:58]:\n> It's best to enable devices to use the new compatible as things are\n> tested rather than hope for some magic \"flag day\" flip that might\n> never happen. Having two days attempting to probe with the same\n> binding just won't work.\n\nHehe I mean \"Having two drivers attempting to probe with the same\nbinding\" above.\n\nTony\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhWc1751lz9t38\n\tfor ;\n\tWed, 30 Aug 2017 00:44:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753623AbdH2Onn (ORCPT\n\t);\n\tTue, 29 Aug 2017 10:43:43 -0400","from muru.com ([72.249.23.125]:38444 \"EHLO muru.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752893AbdH2Onm (ORCPT );\n\tTue, 29 Aug 2017 10:43:42 -0400","from atomide.com (localhost [127.0.0.1])\n\tby muru.com (Postfix) with ESMTPS id 0313F813A;\n\tTue, 29 Aug 2017 14:44:01 +0000 (UTC)"],"Date":"Tue, 29 Aug 2017 07:43:38 -0700","From":"Tony Lindgren ","To":"Sebastian Reichel ","Cc":"Kishon Vijay Abraham I ,\n\tUlf Hansson ,\n\tAdrian Hunter ,\n\tRob Herring , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170829144338.GY6008@atomide.com>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>\n\t<20170829115050.3axlr5uysmqlhvd2@earth>\n\t<20170829135822.GR6008@atomide.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170829135822.GR6008@atomide.com>","User-Agent":"Mutt/1.8.3 (2017-05-23)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759549,"web_url":"http://patchwork.ozlabs.org/comment/1759549/","msgid":"<20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop>","list_archive_url":null,"date":"2017-08-29T17:09:20","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote:\n> * Sebastian Reichel [170829 04:51]:\n> > On Tue, Aug 29, 2017 at 04:50:22PM +0530, Kishon Vijay Abraham I wrote:\n> > > On Thursday 24 August 2017 04:59 PM, Ulf Hansson wrote:\n> > > > I guess we have two options.\n> > > > \n> > > > 1) Allow us to invent and use new bindings - and a new compatible.\n> > > > When everything is implemented in sdhci-omap, we can deprecate the old\n> > > > omap_hsmmc driver and its corresponding compatible/bindings. At some\n> > > > point later we can remove the legacy driver/bindings altogether - of\n> > > > course that might take a while. This option allows us to re-think some\n> > > > of the old bindings and really clean up some if its related code. For\n> > > > example, I think \"ti,dual-volt\" is a bad binding. Instead it would be\n> > > > better to use the existing mmc bindings about which speed mode the\n> > > > controller/board supports (as the voltage level comes with it).\n> > > > \n> > > > 2) Invent only a new compatible, but stick to use the old omap hsmmc\n> > > > bindings and thus also deploy the similar code dealing with them. When\n> > > > everything is implemented move the old omap_hsmmc compatibles into the\n> > > > new sdhci-omap driver and them remove the old omap_hsmmc driver. At\n> > > > that point we could also deprecate the old omap hsmmc compatibles, but\n> > > > to me that is rather pointless.\n> > > > \n> > > > The two options has different advantages, feel free to pick any of them!\n> > > \n> > > Okay. I'll send a new version with option '1' (new compatible/new bindings).\n> \n> Agreed.\n> \n> > > And when we deprecate the omap_hsmmc driver (some time later), we'll add\n> > > support for the legacy bindings in sdhci-omap driver (so that old dtbs continue\n> > > to work). Tony, are you okay with this?\n> > \n> > I think you should Cc Rob Herring and Mark Rutland (DT binding\n> > maintainers). This sounds like \"I use DT to describe driver\n> > behaviour\" instead of \"I use DT to describe hardware\".\n\nIndeed...\n\n> \n> Yes please.\n> \n> > I would expect the conversion to look like the one done for UART,\n> > see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the\n> > same compatible value and you can choose using kernel configuration.\n> \n> That does not work unfortunately :( We are now stuck in a situation\n> where two drivers are attempting to probe with the same compatible\n> and we can't enable 8250_OMAP because of the user space breakage\n> with the device names. And I'm actuallly thinking we should add a\n> new compatible for 8250-omap to be able to start enabling it one\n> board at a time.\n\nIs that the only problem? Presumably, the SD driver doesn't have a \nuserspace facing issue.\n\n> It's best to enable devices to use the new compatible as things are\n> tested rather than hope for some magic \"flag day\" flip that might\n> never happen. Having two days attempting to probe with the same\n> binding just won't work.\n\nAren't you just picking whether the flag day is in DT or the kernel? I \nguess you're assuming one kernel build and it would be switching all \nboards at one. \n\n> So yeah, I agree with Kishon that we should stick with generic\n> and sdhci bindings. And then we can start already using it for\n> boards that can use it, then eventually when we're ready, start\n> parsing also the legacy bindings and maybe drop the old driver.\n\nI assume there are some other common properties you would switch to in \nthe transition? You could make the legacy driver bail from probe based \non presence or absence of other properties. Or you could just blacklist \nconverted platforms in the legacy driver. The point is that the problems \nare solvable in the kernel.\n\nBut if your really want a new compatible, I don't really care. It's \nonly one device.\n\nRob\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhZqn6lfqz9s76\n\tfor ;\n\tWed, 30 Aug 2017 03:09:25 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751066AbdH2RJY (ORCPT\n\t);\n\tTue, 29 Aug 2017 13:09:24 -0400","from mail-oi0-f67.google.com ([209.85.218.67]:34017 \"EHLO\n\tmail-oi0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750815AbdH2RJX (ORCPT\n\t); Tue, 29 Aug 2017 13:09:23 -0400","by mail-oi0-f67.google.com with SMTP id w10so3547121oie.1;\n\tTue, 29 Aug 2017 10:09:22 -0700 (PDT)","from localhost (216-188-254-6.dyn.grandenetworks.net.\n\t[216.188.254.6]) by smtp.gmail.com with ESMTPSA id\n\tt202sm3581876oif.48.2017.08.29.10.09.20\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 29 Aug 2017 10:09:21 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=Tsdpya/by6ulToimN2DARk/d6f0JU/uTIB8zmAw8GsQ=;\n\tb=uA0jRlURT27596t5XB/ustasnoPMs/46qOkqxNVlgIgwz8rPtnOPFUvqck28AReWrG\n\tINhEbuL38uXVNu07JbxJlMOMxjQLgrZhlx+Ku+3FEeuDBuZDtOTSSSlMBXQxk3kzEjld\n\tafvsrXFlb+CFzmvg6FjEvdimURIEBGoMKyoq48ESVsJ7ndbqm+2VZDNT8F7tNcRAdEzL\n\t23PxM2bI8plvQ+kBTZWAMuE0jmk7p6sLV0NyEI+U/uCu6cSTl9dlkveIgZ5LJ2yqQ2Er\n\tBdTzihGyWo6IG7nG9JaAvF2dHwQgP3HaOUyLh/cBUdkDjTWWv1cgYykI7/YaXKaowOGJ\n\tWRww==","X-Gm-Message-State":"AHYfb5hg8Xz7O/ipQV+FllxYVKSZwepK68cillR09GbnwM1Ak4iaMHaP\n\tmnWDW5GJW4hDdw==","X-Received":"by 10.202.81.200 with SMTP id f191mr936343oib.158.1504026562150; \n\tTue, 29 Aug 2017 10:09:22 -0700 (PDT)","Date":"Tue, 29 Aug 2017 12:09:20 -0500","From":"Rob Herring ","To":"Tony Lindgren ","Cc":"Sebastian Reichel ,\n\tKishon Vijay Abraham I ,\n\tUlf Hansson ,\n\tAdrian Hunter , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>\n\t<20170829115050.3axlr5uysmqlhvd2@earth>\n\t<20170829135822.GR6008@atomide.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170829135822.GR6008@atomide.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759551,"web_url":"http://patchwork.ozlabs.org/comment/1759551/","msgid":"<20170829171121.cxjwrzhbotdkddec@rob-hp-laptop>","list_archive_url":null,"date":"2017-08-29T17:11:21","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Wed, Aug 23, 2017 at 11:12:46AM +0530, Kishon Vijay Abraham I wrote:\n> Add binding for the TI's sdhci-omap controller. This now includes only\n> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n> include all the properties.\n> \n> Signed-off-by: Kishon Vijay Abraham I \n> ---\n> Changes from v2:\n> *) Fixed example to use the updated compatible\n> \n> Changes from v1:\n> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n> of using the ti-omap-hsmmc.txt as suggested by Tony\n> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n> 1 file changed, 22 insertions(+)\n> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> \n> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> new file mode 100644\n> index 000000000000..139695ad2d58\n> --- /dev/null\n> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n> @@ -0,0 +1,22 @@\n> +* TI OMAP SDHCI Controller\n> +\n> +Refer to mmc.txt for standard MMC bindings.\n> +\n> +Required properties:\n> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n> +\n> +Optional properties:\n> +- ti,dual-volt: boolean, supports dual voltage cards\n> +- ti,non-removable: non-removable slot (like eMMC)\n\nWell, if you are doing a new compatible, then why aren't you using \ncommon properties?\n\n> +\n> +Example:\n> +\tmmc1: mmc@0x4809c000 {\n\nDrop the '0x'.\n\n> +\t\tcompatible = \"ti,dra7-sdhci\";\n> +\t\treg = <0x4809c000 0x400>;\n> +\t\tti,hwmods = \"mmc1\";\n> +\t\tti,dual-volt;\n> +\t\tbus-width = <4>;\n> +\t\tvmmc-supply = <&vmmc>; /* phandle to regulator node */\n> +\t\tti,non-removable;\n> +\t};\n> -- \n> 2.11.0\n> \n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhZtN2bDkz9t2v\n\tfor ;\n\tWed, 30 Aug 2017 03:11:40 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751237AbdH2RLZ (ORCPT\n\t);\n\tTue, 29 Aug 2017 13:11:25 -0400","from mail-oi0-f67.google.com ([209.85.218.67]:35914 \"EHLO\n\tmail-oi0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751180AbdH2RLY (ORCPT\n\t); Tue, 29 Aug 2017 13:11:24 -0400","by mail-oi0-f67.google.com with SMTP id x184so3540173oia.3;\n\tTue, 29 Aug 2017 10:11:23 -0700 (PDT)","from localhost (216-188-254-6.dyn.grandenetworks.net.\n\t[216.188.254.6]) by smtp.gmail.com with ESMTPSA id\n\tx72sm954259oif.16.2017.08.29.10.11.22\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 29 Aug 2017 10:11:22 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=bywgsYXLHaHN3oKaqiNQvyy3csD5QWRZr/BUB5KqlyI=;\n\tb=belETU4O1JE3t6PNWAbq7GVc7KEfVi6nE+ZNXrjBBo3nmLjx3LRDIkUTolCBUBlkE1\n\toMILhSibalJwEhIFuY8ZkZnlFA8T3jfi4WFjUjJdqWJEY5nRqcVTg8Fwqmq0y+g3QhKm\n\t73KiJZ5Hg191jwAUXp8SreOso89PRlsQyf9wq+aSUJfhc+tt2+849wuYsFc/D1vXLMUe\n\tLoRgLLlHKWVVhdvejkU/1DAfoRbElVyZqueedlLqkF5CdD/PqzyotHeYuSBi3Fi8dJmk\n\tYDzomXZ47IKyZKtcKIrkNEetb/anDNx7KOYAHxepdpGaW6PFIzjNc70AbNlHCvVrQMAO\n\tXjYA==","X-Gm-Message-State":"AHYfb5iBY04SWKXCQV8BrVG5eJkXeIeJqv5viotCuecac9vngg5JX67f\n\t3JRP3GjmK5RwKw==","X-Received":"by 10.202.245.67 with SMTP id t64mr893448oih.19.1504026683269;\n\tTue, 29 Aug 2017 10:11:23 -0700 (PDT)","Date":"Tue, 29 Aug 2017 12:11:21 -0500","From":"Rob Herring ","To":"Kishon Vijay Abraham I ","Cc":"Ulf Hansson ,\n\tAdrian Hunter ,\n\tTony Lindgren , Sekhar Nori ,\n\tRussell King ,\n\tRavikumar Kattekola , linux-mmc@vger.kernel.org,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tlinux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170829171121.cxjwrzhbotdkddec@rob-hp-laptop>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170823054246.23927-1-kishon@ti.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1759571,"web_url":"http://patchwork.ozlabs.org/comment/1759571/","msgid":"<20170829173913.GD6008@atomide.com>","list_archive_url":null,"date":"2017-08-29T17:39:14","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":365,"url":"http://patchwork.ozlabs.org/api/people/365/","name":"Tony Lindgren","email":"tony@atomide.com"},"content":"* Rob Herring [170829 10:09]:\n> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote:\n> > * Sebastian Reichel [170829 04:51]:\n> > > I would expect the conversion to look like the one done for UART,\n> > > see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the\n> > > same compatible value and you can choose using kernel configuration.\n> > \n> > That does not work unfortunately :( We are now stuck in a situation\n> > where two drivers are attempting to probe with the same compatible\n> > and we can't enable 8250_OMAP because of the user space breakage\n> > with the device names. And I'm actuallly thinking we should add a\n> > new compatible for 8250-omap to be able to start enabling it one\n> > board at a time.\n> \n> Is that the only problem? Presumably, the SD driver doesn't have a \n> userspace facing issue.\n\nNo userspace issue with the sdhci-omap. But the sdhci-omap driver\nstill has the issue of trying enable it for everything at once and\nexpect everything to work. The sdhci-omap driver can already be\nused for boards that don't need power management for example, but\nwill break things for devices running on batteries.\n\n> > It's best to enable devices to use the new compatible as things are\n> > tested rather than hope for some magic \"flag day\" flip that might\n> > never happen. Having two days attempting to probe with the same\n> > binding just won't work.\n> \n> Aren't you just picking whether the flag day is in DT or the kernel? I \n> guess you're assuming one kernel build and it would be switching all \n> boards at one. \n\nRight, this would be risky and would take unnecessarily long\nto use the new driver on boards that can already use it. While\npower management won't work yet, I'd expect the sdhci-omap be\nfaster on SoCs that can do ADMA.\n\n> > So yeah, I agree with Kishon that we should stick with generic\n> > and sdhci bindings. And then we can start already using it for\n> > boards that can use it, then eventually when we're ready, start\n> > parsing also the legacy bindings and maybe drop the old driver.\n> \n> I assume there are some other common properties you would switch to in \n> the transition? You could make the legacy driver bail from probe based \n> on presence or absence of other properties. Or you could just blacklist \n> converted platforms in the legacy driver. The point is that the problems \n> are solvable in the kernel.\n\nYes this could be done too. But let's enable it on per-board\nbasis rather than attempt to flip it on at once.\n\n> But if your really want a new compatible, I don't really care. It's \n> only one device.\n\nBoth a new compatible or a check for some resource work just fine\nfor me as long as the driver can be selected on per-board basis.\n\nRegards,\n\nTony\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhbVb1LL0z9t3J\n\tfor ;\n\tWed, 30 Aug 2017 03:39:35 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751223AbdH2RjT (ORCPT\n\t);\n\tTue, 29 Aug 2017 13:39:19 -0400","from muru.com ([72.249.23.125]:38646 \"EHLO muru.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750822AbdH2RjS (ORCPT );\n\tTue, 29 Aug 2017 13:39:18 -0400","from atomide.com (localhost [127.0.0.1])\n\tby muru.com (Postfix) with ESMTPS id 08875813A;\n\tTue, 29 Aug 2017 17:39:37 +0000 (UTC)"],"Date":"Tue, 29 Aug 2017 10:39:14 -0700","From":"Tony Lindgren ","To":"Rob Herring ","Cc":"Sebastian Reichel ,\n\tKishon Vijay Abraham I ,\n\tUlf Hansson ,\n\tAdrian Hunter , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170829173913.GD6008@atomide.com>","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>\n\t<20170829115050.3axlr5uysmqlhvd2@earth>\n\t<20170829135822.GR6008@atomide.com>\n\t<20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop>","User-Agent":"Mutt/1.8.3 (2017-05-23)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1763077,"web_url":"http://patchwork.ozlabs.org/comment/1763077/","msgid":"<06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com>","list_archive_url":null,"date":"2017-09-05T08:52:55","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":14965,"url":"http://patchwork.ozlabs.org/api/people/14965/","name":"Kishon Vijay Abraham I","email":"kishon@ti.com"},"content":"Hi,\n\nOn Tuesday 29 August 2017 11:09 PM, Tony Lindgren wrote:\n> * Rob Herring [170829 10:09]:\n>> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote:\n>>> * Sebastian Reichel [170829 04:51]:\n>>>> I would expect the conversion to look like the one done for UART,\n>>>> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the\n>>>> same compatible value and you can choose using kernel configuration.\n>>>\n>>> That does not work unfortunately :( We are now stuck in a situation\n>>> where two drivers are attempting to probe with the same compatible\n>>> and we can't enable 8250_OMAP because of the user space breakage\n>>> with the device names. And I'm actuallly thinking we should add a\n>>> new compatible for 8250-omap to be able to start enabling it one\n>>> board at a time.\n>>\n>> Is that the only problem? Presumably, the SD driver doesn't have a \n>> userspace facing issue.\n> \n> No userspace issue with the sdhci-omap. But the sdhci-omap driver\n> still has the issue of trying enable it for everything at once and\n> expect everything to work. The sdhci-omap driver can already be\n> used for boards that don't need power management for example, but\n> will break things for devices running on batteries.\n> \n>>> It's best to enable devices to use the new compatible as things are\n>>> tested rather than hope for some magic \"flag day\" flip that might\n>>> never happen. Having two days attempting to probe with the same\n>>> binding just won't work.\n>>\n>> Aren't you just picking whether the flag day is in DT or the kernel? I \n>> guess you're assuming one kernel build and it would be switching all \n>> boards at one. \n> \n> Right, this would be risky and would take unnecessarily long\n> to use the new driver on boards that can already use it. While\n> power management won't work yet, I'd expect the sdhci-omap be\n> faster on SoCs that can do ADMA.\n> \n>>> So yeah, I agree with Kishon that we should stick with generic\n>>> and sdhci bindings. And then we can start already using it for\n>>> boards that can use it, then eventually when we're ready, start\n>>> parsing also the legacy bindings and maybe drop the old driver.\n>>\n>> I assume there are some other common properties you would switch to in \n>> the transition? You could make the legacy driver bail from probe based \n>> on presence or absence of other properties. Or you could just blacklist \n>> converted platforms in the legacy driver. The point is that the problems \n>> are solvable in the kernel.\n> \n> Yes this could be done too. But let's enable it on per-board\n> basis rather than attempt to flip it on at once.\n> \n>> But if your really want a new compatible, I don't really care. It's \n>> only one device.\n> \n> Both a new compatible or a check for some resource work just fine\n> for me as long as the driver can be selected on per-board basis.\n\nNew compatible sounds simpler to me since it allows to select a driver per-MMC\ninstance. (SDIO support is not added/validated in sdhci-omap).\n\nTo summarize, we'll create new compatible and new bindings for sdhci-omap and\nstart enabling sdhci-omap on per-board basis. When all the TI platforms starts\nto use sdhci-omap, omap-hsmmc will be removed at which point support for old\ncompatible and old dt bindings will be added to sdhci-omap.c. Does this sound\nreasonable?\n\nThanks\nKishon\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"Id0Nl48I\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmgWJ0kXWz9s7h\n\tfor ;\n\tTue, 5 Sep 2017 18:54:20 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751707AbdIEIyD (ORCPT\n\t);\n\tTue, 5 Sep 2017 04:54:03 -0400","from lelnx194.ext.ti.com ([198.47.27.80]:20143 \"EHLO\n\tlelnx194.ext.ti.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750913AbdIEIxp (ORCPT\n\t); Tue, 5 Sep 2017 04:53:45 -0400","from dlelxv90.itg.ti.com ([172.17.2.17])\n\tby lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id v858r0s3019631; \n\tTue, 5 Sep 2017 03:53:00 -0500","from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34])\n\tby dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id v858r0n1031768; \n\tTue, 5 Sep 2017 03:53:00 -0500","from DFLE105.ent.ti.com (10.64.6.26) by DFLE113.ent.ti.com\n\t(10.64.6.34) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tTue, 5 Sep 2017 03:53:00 -0500","from dlep33.itg.ti.com (157.170.170.75) by DFLE105.ent.ti.com\n\t(10.64.6.26) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Tue, 5 Sep 2017 03:53:00 -0500","from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id v858quXg021355;\n\tTue, 5 Sep 2017 03:52:57 -0500"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1504601580;\n\tbh=IMzsrrln/rvWBcl7FPr1siqX0p4GNqGQ0DX75HahwJI=;\n\th=Subject:To:References:CC:From:Date:In-Reply-To;\n\tb=Id0Nl48IIp30dufh6cOLNT0/0z7P9Ek5NL7se1dOEKbJwC9el8qMVTo8A4oPFJmDb\n\tEoKXcwDHLuyNSZBPYmzFt165Bzk6OZJg3M0ZNt5sfCr5vLDzAArLRnjhLEN8W0C/GL\n\t9sIraQVl5eo3EejYbs+ZQosIvExQ/KuELi0fFsjc=","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","To":"Tony Lindgren , Rob Herring ","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>\n\t<20170829115050.3axlr5uysmqlhvd2@earth>\n\t<20170829135822.GR6008@atomide.com>\n\t<20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop>\n\t<20170829173913.GD6008@atomide.com>","CC":"Sebastian Reichel ,\n\tUlf Hansson ,\n\tAdrian Hunter , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","From":"Kishon Vijay Abraham I ","Message-ID":"<06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com>","Date":"Tue, 5 Sep 2017 14:22:55 +0530","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.0","MIME-Version":"1.0","In-Reply-To":"<20170829173913.GD6008@atomide.com>","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"7bit","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1763079,"web_url":"http://patchwork.ozlabs.org/comment/1763079/","msgid":"<37ea03ef-688f-40e6-32ce-f4637e8faf9b@ti.com>","list_archive_url":null,"date":"2017-09-05T08:53:59","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":14965,"url":"http://patchwork.ozlabs.org/api/people/14965/","name":"Kishon Vijay Abraham I","email":"kishon@ti.com"},"content":"Hi,\n\nOn Tuesday 29 August 2017 10:41 PM, Rob Herring wrote:\n> On Wed, Aug 23, 2017 at 11:12:46AM +0530, Kishon Vijay Abraham I wrote:\n>> Add binding for the TI's sdhci-omap controller. This now includes only\n>> a subset of properties documented in ti-omap-hsmmc.txt but will eventually\n>> include all the properties.\n>>\n>> Signed-off-by: Kishon Vijay Abraham I \n>> ---\n>> Changes from v2:\n>> *) Fixed example to use the updated compatible\n>>\n>> Changes from v1:\n>> *) Create a new sdhci-omap.txt document for TI's sdhci-omap controller instead\n>> of using the ti-omap-hsmmc.txt as suggested by Tony\n>> .../devicetree/bindings/mmc/sdhci-omap.txt | 22 ++++++++++++++++++++++\n>> 1 file changed, 22 insertions(+)\n>> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>>\n>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>> new file mode 100644\n>> index 000000000000..139695ad2d58\n>> --- /dev/null\n>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt\n>> @@ -0,0 +1,22 @@\n>> +* TI OMAP SDHCI Controller\n>> +\n>> +Refer to mmc.txt for standard MMC bindings.\n>> +\n>> +Required properties:\n>> +- compatible: Should be \"ti,dra7-sdhci\" for DRA7 and DRA72 controllers\n>> +- ti,hwmods: Must be \"mmc\", is controller instance starting 1\n>> +\n>> +Optional properties:\n>> +- ti,dual-volt: boolean, supports dual voltage cards\n>> +- ti,non-removable: non-removable slot (like eMMC)\n> \n> Well, if you are doing a new compatible, then why aren't you using \n> common properties?\n\nyeah, now moved to generic bindings.\n> \n>> +\n>> +Example:\n>> +\tmmc1: mmc@0x4809c000 {\n> \n> Drop the '0x'.\n\nsure, will fix it.\n\nThanks\nKishon\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ti.com header.i=@ti.com header.b=\"fPOhFs7C\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmgXH6gpDz9s7h\n\tfor ;\n\tTue, 5 Sep 2017 18:55:11 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751621AbdIEIyy (ORCPT\n\t);\n\tTue, 5 Sep 2017 04:54:54 -0400","from lelnx193.ext.ti.com ([198.47.27.77]:25255 \"EHLO\n\tlelnx193.ext.ti.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750933AbdIEIyk (ORCPT\n\t); Tue, 5 Sep 2017 04:54:40 -0400","from dlelxv90.itg.ti.com ([172.17.2.17])\n\tby lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id v858s33E028969; \n\tTue, 5 Sep 2017 03:54:03 -0500","from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25])\n\tby dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id v858s32V002425; \n\tTue, 5 Sep 2017 03:54:03 -0500","from DFLE113.ent.ti.com (10.64.6.34) by DFLE104.ent.ti.com\n\t(10.64.6.25) with Microsoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34;\n\tTue, 5 Sep 2017 03:54:03 -0500","from dflp32.itg.ti.com (10.64.6.15) by DFLE113.ent.ti.com\n\t(10.64.6.34) with Microsoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend\n\tTransport; Tue, 5 Sep 2017 03:54:03 -0500","from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153])\n\tby dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id v858rx9P003076;\n\tTue, 5 Sep 2017 03:54:00 -0500"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com;\n\ts=ti-com-17Q1; t=1504601643;\n\tbh=kWp6UV/1PK9rvX6r4L0bTjkv9jkPouhyxtiDcWcobGA=;\n\th=Subject:To:References:CC:From:Date:In-Reply-To;\n\tb=fPOhFs7CApoAGw/A5drUCK+sNZ3ZfN0DjOFrIVgzAn2nPvUY1wrGF6viaa9MEOsUJ\n\t5hQtbGaqIoiz2iHHv1IqHOUXmkxssVlww9IFI5BiUNNm3zNsGEQiqdwmGYFCWs8eCw\n\toGrwbqU33ZS5fzOXAKhp197KjANDcJvrkz1CJaHE=","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","To":"Rob Herring ","References":"<20170821142132.GH6008@atomide.com>\n\t<20170823054246.23927-1-kishon@ti.com>\n\t<20170829171121.cxjwrzhbotdkddec@rob-hp-laptop>","CC":"Ulf Hansson ,\n\tAdrian Hunter ,\n\tTony Lindgren , Sekhar Nori ,\n\tRussell King ,\n\tRavikumar Kattekola , ,\n\t, ,\n\t, ","From":"Kishon Vijay Abraham I ","Message-ID":"<37ea03ef-688f-40e6-32ce-f4637e8faf9b@ti.com>","Date":"Tue, 5 Sep 2017 14:23:59 +0530","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.0","MIME-Version":"1.0","In-Reply-To":"<20170829171121.cxjwrzhbotdkddec@rob-hp-laptop>","Content-Type":"text/plain; charset=\"windows-1252\"","Content-Transfer-Encoding":"7bit","X-EXCLAIMER-MD-CONFIG":"e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1763505,"web_url":"http://patchwork.ozlabs.org/comment/1763505/","msgid":"<20170905165145.GC5024@atomide.com>","list_archive_url":null,"date":"2017-09-05T16:51:45","subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","submitter":{"id":365,"url":"http://patchwork.ozlabs.org/api/people/365/","name":"Tony Lindgren","email":"tony@atomide.com"},"content":"* Kishon Vijay Abraham I [170905 01:53]:\n> Hi,\n> \n> On Tuesday 29 August 2017 11:09 PM, Tony Lindgren wrote:\n> > * Rob Herring [170829 10:09]:\n> >> On Tue, Aug 29, 2017 at 06:58:23AM -0700, Tony Lindgren wrote:\n> >>> * Sebastian Reichel [170829 04:51]:\n> >>>> I would expect the conversion to look like the one done for UART,\n> >>>> see CONFIG_SERIAL_OMAP vs CONFIG_SERIAL_8250_OMAP. Both use the\n> >>>> same compatible value and you can choose using kernel configuration.\n> >>>\n> >>> That does not work unfortunately :( We are now stuck in a situation\n> >>> where two drivers are attempting to probe with the same compatible\n> >>> and we can't enable 8250_OMAP because of the user space breakage\n> >>> with the device names. And I'm actuallly thinking we should add a\n> >>> new compatible for 8250-omap to be able to start enabling it one\n> >>> board at a time.\n> >>\n> >> Is that the only problem? Presumably, the SD driver doesn't have a \n> >> userspace facing issue.\n> > \n> > No userspace issue with the sdhci-omap. But the sdhci-omap driver\n> > still has the issue of trying enable it for everything at once and\n> > expect everything to work. The sdhci-omap driver can already be\n> > used for boards that don't need power management for example, but\n> > will break things for devices running on batteries.\n> > \n> >>> It's best to enable devices to use the new compatible as things are\n> >>> tested rather than hope for some magic \"flag day\" flip that might\n> >>> never happen. Having two days attempting to probe with the same\n> >>> binding just won't work.\n> >>\n> >> Aren't you just picking whether the flag day is in DT or the kernel? I \n> >> guess you're assuming one kernel build and it would be switching all \n> >> boards at one. \n> > \n> > Right, this would be risky and would take unnecessarily long\n> > to use the new driver on boards that can already use it. While\n> > power management won't work yet, I'd expect the sdhci-omap be\n> > faster on SoCs that can do ADMA.\n> > \n> >>> So yeah, I agree with Kishon that we should stick with generic\n> >>> and sdhci bindings. And then we can start already using it for\n> >>> boards that can use it, then eventually when we're ready, start\n> >>> parsing also the legacy bindings and maybe drop the old driver.\n> >>\n> >> I assume there are some other common properties you would switch to in \n> >> the transition? You could make the legacy driver bail from probe based \n> >> on presence or absence of other properties. Or you could just blacklist \n> >> converted platforms in the legacy driver. The point is that the problems \n> >> are solvable in the kernel.\n> > \n> > Yes this could be done too. But let's enable it on per-board\n> > basis rather than attempt to flip it on at once.\n> > \n> >> But if your really want a new compatible, I don't really care. It's \n> >> only one device.\n> > \n> > Both a new compatible or a check for some resource work just fine\n> > for me as long as the driver can be selected on per-board basis.\n> \n> New compatible sounds simpler to me since it allows to select a driver per-MMC\n> instance. (SDIO support is not added/validated in sdhci-omap).\n> \n> To summarize, we'll create new compatible and new bindings for sdhci-omap and\n> start enabling sdhci-omap on per-board basis. When all the TI platforms starts\n> to use sdhci-omap, omap-hsmmc will be removed at which point support for old\n> compatible and old dt bindings will be added to sdhci-omap.c. Does this sound\n> reasonable?\n\nSounds like a plan to me.\n\nRegards,\n\nTony\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" 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-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@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=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xmt6p5zYrz9sPs\n\tfor ;\n\tWed, 6 Sep 2017 02:52:18 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752248AbdIEQvu (ORCPT\n\t);\n\tTue, 5 Sep 2017 12:51:50 -0400","from muru.com ([72.249.23.125]:39536 \"EHLO muru.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752295AbdIEQvt (ORCPT );\n\tTue, 5 Sep 2017 12:51:49 -0400","from atomide.com (localhost [127.0.0.1])\n\tby muru.com (Postfix) with ESMTPS id 4B17781FE;\n\tTue, 5 Sep 2017 16:52:17 +0000 (UTC)"],"Date":"Tue, 5 Sep 2017 09:51:45 -0700","From":"Tony Lindgren ","To":"Kishon Vijay Abraham I ","Cc":"Rob Herring ,\n\tSebastian Reichel ,\n\tUlf Hansson ,\n\tAdrian Hunter , Sekhar Nori ,\n\tRussell King , Ravikumar Kattekola ,\n\t\"linux-mmc@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tlinux-omap ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t","Subject":"Re: [PATCH v3 3/5] dt-bindings: sdhci-omap: Add bindings for the\n\tsdhci-omap controller","Message-ID":"<20170905165145.GC5024@atomide.com>","References":"<20170823054246.23927-1-kishon@ti.com>\n\t\n\t\n\t\n\t<0c7e0705-d9c2-4499-54ba-cbd84589dc01@ti.com>\n\t<20170829115050.3axlr5uysmqlhvd2@earth>\n\t<20170829135822.GR6008@atomide.com>\n\t<20170829170920.xpgk5ywlvfgrtbqi@rob-hp-laptop>\n\t<20170829173913.GD6008@atomide.com>\n\t<06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<06199a7e-456d-708d-6f2f-81f6bbfea2ba@ti.com>","User-Agent":"Mutt/1.8.3 (2017-05-23)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]