[{"id":1769788,"web_url":"http://patchwork.ozlabs.org/comment/1769788/","msgid":"","list_archive_url":null,"date":"2017-09-17T20:51:31","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":66366,"url":"http://patchwork.ozlabs.org/api/people/66366/","name":"Martin Blumenstingl","email":"martin.blumenstingl@googlemail.com"},"content":"Hello Mathias, Hello Greg,\n\nOn Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n wrote:\n> This series is the outcome of a discussion with Felipe Balbi,\n> see [0] and [1].\n> The quick-summary of this is:\n> - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n> correct\n> - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and\n> ohci-platform.c) do not have a limitation on the number of PHYs - they\n> support one PHY per actual host port\n> - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two\n> or three USB2 ports enabled on the internal root-hub. The SoCs also\n> provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n> internally \"connected\" to the dwc3 roothub) need to be powered on,\n> otherwise USB devices cannot be enumerated (even if just one PHY is\n> disabled and if the device is plugged into another, enabled port)\n>\n> In my first attempt to get USB supported on the GXL and GXM SoCs I tried\n> to work-around the problem that I could not pass multiple PHYs to the\n> dwc3 controller.\n> This was rejected by Rob Herring (which was definitely the thing to do in\n> my opinion), see [2]\n>\n> This series adds a new \"platform-roothub\". This can be configured through\n> devicetree by passing a child-node with \"reg = <0>\" to the USB\n> controller. Additionally there has to be a child-node for each port on\n> the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n> property. This allows modeling the root-hub in devicetree similar to the\n> USB device binding (documented in devicetree/bindings/usb/usb-device.txt)\n> This avoids and backwards-compatibility problems (which was a concern\n> regardless of the solution, see [3]) since the binding for the root-hub\n> was previously not specified (and we're not using the \"phys\" property of\n> the controller, which might have served different purposes before,\n> depending on the drivers).\n>\n> Additionally this integrates the new platform-roothub into xhci-plat.c\n> which automatically enables it for the dwc3 driver (in host-mode).\n>\n>\n> Changes since RFCv3 at [6]:\n> - moved the DT binding change from patch #3 to patch #1 as suggested\n> by Rob Herring (and slightly adjusted the commit message to account\n> for that)\n> - added Tested-by from Chunfeng Yun (who confirmed that the whole\n> concept and implementation works fine on Mediatek SoCs - many thanks\n> again!) to patch #2\n> - added Rob Herring's ACK to patches 1 and 3\n> - dropped RFC status (RFCv3 -> PATCH v4)\nI just wanted to rebase this to v4.14-rc1 (now that this is out) -\nhowever I noticed that v4 still applies to v4.14-rc1 cleanly (the\npatches are still identical to v4 after rebasing).\n\nwe have an ACK from the devicetree maintainers and a \"Tested-by\" for a\nMediatek (= non-Amlogic) SoC.\nI already have patches for the Amlogic GXL/GXM platforms queued, those\nare just waiting on this series.\n\nwhat is still missing to get this series into v4.15?\n\n> Changes since RFCv2 at [5]:\n> - split phy_{init,exit} and phy_power_{on,off} handling. up until RFCv2\n> I called phy_init plus phy_power_on in platform_roothub_power_on and\n> phy_power_off plus phy_exit in platform_roothub_power_off. However,\n> Chunfeng Yun (a Mediatek SoC developer - many thanks for testing my\n> series and providing great feedback) reported that only using\n> phy_power_off (and omitting phy_exit) during system suspend fixes an\n> issue where USB devices would be re-enumerated when resuming. His\n> original problem description: \"In order to keep link state on mt8173,\n> we just power off all phys(not exit) when system enter suspend, then\n> power on them again (needn't init, otherwise device will be\n> disconnected) when system resume, this can avoid re-enumerating\n> device.\". This fix affects patch #2 and #3 as we now have\n> platform_roothub_init (which calls phy_init internally),\n> platform_roothub_power_on (which calls phy_power_on internally),\n> platform_roothub_power_off (which calls phy_power_off internally) and\n> platform_roothub_exit (which calls phy_exit internally). suspend and\n> resume only call platform_roothub_power_{on,off} to prevent the issue\n> described by Chunfeng Yun (unfortunately I cannot test this because\n> the Amlogic platform currently does not support system suspend).\n> - dropped two struct forward declarations from platform-roothub.h which\n> are not used in the header file (thanks to Chunfeng Yun for spotting\n> this)\n>\n> Changes since RFCv1 at [4]:\n> - split the usb-xhci dt-binding documentation into a separate patch\n> - fixed a typo (\"usb-phy\" -> \"phys\" in the dt-binding example)\n> - rebased to apply against latest usb-next\n>\n>\n> [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001945.html\n> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html\n> [2] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html\n> [3] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001948.html\n> [4] http://marc.info/?l=linux-usb&m=148414866303604&w=2\n> [5] https://www.spinics.net/lists/linux-usb/msg158967.html\n> [6] https://www.spinics.net/lists/devicetree/msg190426.html\n>\n> Martin Blumenstingl (3):\n> dt-bindings: usb: add the documentation for USB root-hub\n> usb: host: add a generic platform USB roothub driver\n> usb: host: xhci: plat: integrate the platform-roothub\n>\n> .../devicetree/bindings/usb/usb-roothub.txt | 46 ++++++\n> Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 +\n> drivers/usb/host/Kconfig | 4 +\n> drivers/usb/host/Makefile | 2 +\n> drivers/usb/host/platform-roothub.c | 180 +++++++++++++++++++++\n> drivers/usb/host/platform-roothub.h | 12 ++\n> drivers/usb/host/xhci-plat.c | 35 +++-\n> drivers/usb/host/xhci.h | 2 +\n> 8 files changed, 286 insertions(+), 2 deletions(-)\n> create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt\n> create mode 100644 drivers/usb/host/platform-roothub.c\n> create mode 100644 drivers/usb/host/platform-roothub.h\n>\n> --\n> 2.14.1\n>\n\nHave a great week!\nRegards,\nMartin\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\" (2048-bit key;\n\tunprotected) header.d=googlemail.com header.i=@googlemail.com\n\theader.b=\"o/6Ws6D7\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwLsq1gXkz9s7v\n\tfor ;\n\tMon, 18 Sep 2017 06:51:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751646AbdIQUvy (ORCPT\n\t);\n\tSun, 17 Sep 2017 16:51:54 -0400","from mail-io0-f195.google.com ([209.85.223.195]:35823 \"EHLO\n\tmail-io0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751576AbdIQUvx (ORCPT\n\t); Sun, 17 Sep 2017 16:51:53 -0400","by mail-io0-f195.google.com with SMTP id d16so7298968ioj.2;\n\tSun, 17 Sep 2017 13:51:53 -0700 (PDT)","by 10.2.51.84 with HTTP; Sun, 17 Sep 2017 13:51:31 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlemail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=gdXdJnZ1sZJJXIQyCtwS/6iH2d4aEEoNxzybnD8sSjc=;\n\tb=o/6Ws6D7laDFq/Yx8kVPxFiDz58jgIALKTFgxnKylhkS2nH5OJpUQDw1JyU6cfEbce\n\tDy+dgBNYP5oJ1adI1+GYC1RlIBbISzpoq5O4CDXkIu4+eXetd/KvXbnSKGc4pSqDlsnt\n\ty06wlwGrWRo4pnJkdfX6D0Cm5lFd9IDCAxwYJ3CBCGEom6RSWhrxcB0bgfku5Qb3axku\n\tiPyK65NsnRbQ+thQ40ICIR5aJzYwd2+oITMFcRBKvsICwrK/nEdP5OhUpVg8MfZNVhDG\n\tpbn4ue8HcBFa6Z8LaZdtFvk5MrIC/5L8Q9eg1oLjwb5rGZ9dJQlH6rcg3VJa1xeJl8jM\n\t33tg==","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=gdXdJnZ1sZJJXIQyCtwS/6iH2d4aEEoNxzybnD8sSjc=;\n\tb=m5attxZk9g5tDxMGgcdDxEZTo+lfmARFpRbyJGlmaozUH6UF34hOPEqwhu45FEUm02\n\tcoj0VkvGtKk4D3sNjN1YWnMFsVbH4O+5QCSKr3T8z2TkxytiZzvCG+boVtm42MdeXwEl\n\tqez0qssNjxRHAe9hJmgZKoFLJ8L99bPQlECdbYVouxG2ofYgxOB+9ffwCtsQ3xNn66QA\n\tI7kKUOc1dxSfgw/Kw/vdHhtmrLaE76u4JSO+YS+IXYKv5eG1EwczwmzW4HCLoI3FsDFu\n\t2zC22/FqvM67x+BXcXe1Q+rhW6PWgHrDVUMjxe5HZknCqLNtKImO9YhPeSpDf/3DdwGi\n\tMrEg==","X-Gm-Message-State":"AHPjjUjhyGsX1XLUUQbpyz0zWWrOko45jscP2LtRUZL3N1DIZ7ajY5xH\n\tGgCo1NaO3X9OVu4BD7uGFrP3ZyEYfyMUFnSDbU0=","X-Google-Smtp-Source":"AOwi7QA0TU54W0G4Tb69IYByHjIApPP4wPe/DPWSA23nI2BT0gpNVGaxdts4KvYjcRJxiE2LFTnpelG72PnHUe77QXg=","X-Received":"by 10.107.18.85 with SMTP id a82mr16072017ioj.251.1505681512416; \n\tSun, 17 Sep 2017 13:51:52 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>","From":"Martin Blumenstingl ","Date":"Sun, 17 Sep 2017 22:51:31 +0200","Message-ID":"","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","To":"mathias.nyman@intel.com, gregkh@linuxfoundation.org","Cc":"robh+dt@kernel.org, devicetree@vger.kernel.org,\n\tmark.rutland@arm.com, arnd@arndb.de,\n\tlinux-amlogic@lists.infradead.org, chunfeng.yun@mediatek.com,\n\tMartin Blumenstingl ,\n\tlinux-usb@vger.kernel.org, felipe.balbi@linux.intel.com","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":1769988,"web_url":"http://patchwork.ozlabs.org/comment/1769988/","msgid":"<20170918084943.GA19123@kroah.com>","list_archive_url":null,"date":"2017-09-18T08:49:43","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":11800,"url":"http://patchwork.ozlabs.org/api/people/11800/","name":"Greg Kroah-Hartman","email":"gregkh@linuxfoundation.org"},"content":"On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:\n> Hello Mathias, Hello Greg,\n> \n> On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n> wrote:\n> > This series is the outcome of a discussion with Felipe Balbi,\n> > see [0] and [1].\n> > The quick-summary of this is:\n> > - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n> > correct\n> > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and\n> > ohci-platform.c) do not have a limitation on the number of PHYs - they\n> > support one PHY per actual host port\n> > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two\n> > or three USB2 ports enabled on the internal root-hub. The SoCs also\n> > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n> > internally \"connected\" to the dwc3 roothub) need to be powered on,\n> > otherwise USB devices cannot be enumerated (even if just one PHY is\n> > disabled and if the device is plugged into another, enabled port)\n> >\n> > In my first attempt to get USB supported on the GXL and GXM SoCs I tried\n> > to work-around the problem that I could not pass multiple PHYs to the\n> > dwc3 controller.\n> > This was rejected by Rob Herring (which was definitely the thing to do in\n> > my opinion), see [2]\n> >\n> > This series adds a new \"platform-roothub\". This can be configured through\n> > devicetree by passing a child-node with \"reg = <0>\" to the USB\n> > controller. Additionally there has to be a child-node for each port on\n> > the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n> > property. This allows modeling the root-hub in devicetree similar to the\n> > USB device binding (documented in devicetree/bindings/usb/usb-device.txt)\n> > This avoids and backwards-compatibility problems (which was a concern\n> > regardless of the solution, see [3]) since the binding for the root-hub\n> > was previously not specified (and we're not using the \"phys\" property of\n> > the controller, which might have served different purposes before,\n> > depending on the drivers).\n> >\n> > Additionally this integrates the new platform-roothub into xhci-plat.c\n> > which automatically enables it for the dwc3 driver (in host-mode).\n> >\n> >\n> > Changes since RFCv3 at [6]:\n> > - moved the DT binding change from patch #3 to patch #1 as suggested\n> > by Rob Herring (and slightly adjusted the commit message to account\n> > for that)\n> > - added Tested-by from Chunfeng Yun (who confirmed that the whole\n> > concept and implementation works fine on Mediatek SoCs - many thanks\n> > again!) to patch #2\n> > - added Rob Herring's ACK to patches 1 and 3\n> > - dropped RFC status (RFCv3 -> PATCH v4)\n> I just wanted to rebase this to v4.14-rc1 (now that this is out) -\n> however I noticed that v4 still applies to v4.14-rc1 cleanly (the\n> patches are still identical to v4 after rebasing).\n> \n> we have an ACK from the devicetree maintainers and a \"Tested-by\" for a\n> Mediatek (= non-Amlogic) SoC.\n> I already have patches for the Amlogic GXL/GXM platforms queued, those\n> are just waiting on this series.\n> \n> what is still missing to get this series into v4.15?\n\nWell, we couldn't do anything until 4.14-rc1 is out, now that it is, let\nus catch up on patch review please...\n\nthanks,\n\ngreg k-h\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 3xwfnp4Xd5z9s4s\n\tfor ;\n\tMon, 18 Sep 2017 18:49:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752700AbdIRItd (ORCPT\n\t);\n\tMon, 18 Sep 2017 04:49:33 -0400","from mail.linuxfoundation.org ([140.211.169.12]:50852 \"EHLO\n\tmail.linuxfoundation.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752531AbdIRItc (ORCPT\n\t); Mon, 18 Sep 2017 04:49:32 -0400","from localhost (LFbn-1-12253-150.w90-92.abo.wanadoo.fr\n\t[90.92.67.150])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPSA id F329C8EE;\n\tMon, 18 Sep 2017 08:49:31 +0000 (UTC)"],"Date":"Mon, 18 Sep 2017 10:49:43 +0200","From":"Greg KH ","To":"Martin Blumenstingl ","Cc":"mathias.nyman@intel.com, robh+dt@kernel.org,\n\tdevicetree@vger.kernel.org, mark.rutland@arm.com, arnd@arndb.de,\n\tlinux-amlogic@lists.infradead.org, chunfeng.yun@mediatek.com,\n\tlinux-usb@vger.kernel.org, felipe.balbi@linux.intel.com","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","Message-ID":"<20170918084943.GA19123@kroah.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.9.0 (2017-09-02)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1778046,"web_url":"http://patchwork.ozlabs.org/comment/1778046/","msgid":"","list_archive_url":null,"date":"2017-10-01T20:32:06","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":66366,"url":"http://patchwork.ozlabs.org/api/people/66366/","name":"Martin Blumenstingl","email":"martin.blumenstingl@googlemail.com"},"content":"Hello Greg, Hello Mathias,\n\nOn Mon, Sep 18, 2017 at 10:49 AM, Greg KH wrote:\n> On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:\n>> Hello Mathias, Hello Greg,\n>>\n>> On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n>> wrote:\n>> > This series is the outcome of a discussion with Felipe Balbi,\n>> > see [0] and [1].\n>> > The quick-summary of this is:\n>> > - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n>> > correct\n>> > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and\n>> > ohci-platform.c) do not have a limitation on the number of PHYs - they\n>> > support one PHY per actual host port\n>> > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two\n>> > or three USB2 ports enabled on the internal root-hub. The SoCs also\n>> > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n>> > internally \"connected\" to the dwc3 roothub) need to be powered on,\n>> > otherwise USB devices cannot be enumerated (even if just one PHY is\n>> > disabled and if the device is plugged into another, enabled port)\n>> >\n>> > In my first attempt to get USB supported on the GXL and GXM SoCs I tried\n>> > to work-around the problem that I could not pass multiple PHYs to the\n>> > dwc3 controller.\n>> > This was rejected by Rob Herring (which was definitely the thing to do in\n>> > my opinion), see [2]\n>> >\n>> > This series adds a new \"platform-roothub\". This can be configured through\n>> > devicetree by passing a child-node with \"reg = <0>\" to the USB\n>> > controller. Additionally there has to be a child-node for each port on\n>> > the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n>> > property. This allows modeling the root-hub in devicetree similar to the\n>> > USB device binding (documented in devicetree/bindings/usb/usb-device.txt)\n>> > This avoids and backwards-compatibility problems (which was a concern\n>> > regardless of the solution, see [3]) since the binding for the root-hub\n>> > was previously not specified (and we're not using the \"phys\" property of\n>> > the controller, which might have served different purposes before,\n>> > depending on the drivers).\n>> >\n>> > Additionally this integrates the new platform-roothub into xhci-plat.c\n>> > which automatically enables it for the dwc3 driver (in host-mode).\n>> >\n>> >\n>> > Changes since RFCv3 at [6]:\n>> > - moved the DT binding change from patch #3 to patch #1 as suggested\n>> > by Rob Herring (and slightly adjusted the commit message to account\n>> > for that)\n>> > - added Tested-by from Chunfeng Yun (who confirmed that the whole\n>> > concept and implementation works fine on Mediatek SoCs - many thanks\n>> > again!) to patch #2\n>> > - added Rob Herring's ACK to patches 1 and 3\n>> > - dropped RFC status (RFCv3 -> PATCH v4)\n>> I just wanted to rebase this to v4.14-rc1 (now that this is out) -\n>> however I noticed that v4 still applies to v4.14-rc1 cleanly (the\n>> patches are still identical to v4 after rebasing).\n>>\n>> we have an ACK from the devicetree maintainers and a \"Tested-by\" for a\n>> Mediatek (= non-Amlogic) SoC.\n>> I already have patches for the Amlogic GXL/GXM platforms queued, those\n>> are just waiting on this series.\n>>\n>> what is still missing to get this series into v4.15?\n>\n> Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let\n> us catch up on patch review please...\nOK, I understand that.\nplease let me know once you've caught up with the review backlog - as\nI said I would like to get this into 4.15 if nothing else comes up\nduring the code-review\n\n\nThank you!\nRegards,\nMartin\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\" (2048-bit key;\n\tunprotected) header.d=googlemail.com header.i=@googlemail.com\n\theader.b=\"OMktyaXY\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y4xmt6jsSz9t3f\n\tfor ;\n\tMon, 2 Oct 2017 07:32:30 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751749AbdJAUc2 (ORCPT\n\t);\n\tSun, 1 Oct 2017 16:32:28 -0400","from mail-io0-f196.google.com ([209.85.223.196]:33949 \"EHLO\n\tmail-io0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751514AbdJAUc1 (ORCPT\n\t); Sun, 1 Oct 2017 16:32:27 -0400","by mail-io0-f196.google.com with SMTP id g32so2227689ioj.1;\n\tSun, 01 Oct 2017 13:32:27 -0700 (PDT)","by 10.2.51.84 with HTTP; Sun, 1 Oct 2017 13:32:06 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlemail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=D8X0oaaGPZ6/XINMMihCNIYkHHiVxqUCwEcfIQQx+hM=;\n\tb=OMktyaXYv5dWWH1IYKr41OLLEou+M4J9tuWCLJc7qYXjox4G2WbPy1o/iFD9ZsEQjK\n\tec+Y002lA9/S2vD5hU89Ru8RiVNCM51R1n2h2B7/fZcPa6Eb4enqBjDJBMP+1b7Lh/Nv\n\ttH9we26gRbxzzOcEn5GL8CfNHeab2Os2meJfjFMzRHhp/RGcaeM56w+9J1cthX64F6DV\n\tO08+pKP27sCcHwKVaBRyEc0AZJ+8BOtJGL2tFghaIC0WKUYw1/l6sOkPLyXcx62uVroc\n\t0PgNkYJEREOVcVRfbkx4S9cErvWeShy7E5LujQBeoZKGj/re8kppR5B//2BFoFBXvPJA\n\tdPow==","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=D8X0oaaGPZ6/XINMMihCNIYkHHiVxqUCwEcfIQQx+hM=;\n\tb=kjjBSN3QG/qvg5UhkcJ/zZbCqwztmumzBq8KWJyYkQ5XyLjughcuhxjtqel2kXLUzF\n\tZ8YuZ5/toteErSlIdczwAXKSIgzCQP+PHIj9zH1zmxFjruDqHbkXwFKKqp+wUp/eKFif\n\tkmtcfooJ0kGeW6nHSeofk3A+k2EzERsnaML6d7JqexSBwmMiV6/5AymbDiyj0OjiRpj4\n\tO03fMIjxSc9f147GbXPC8r5iFZFhJ6nE8Lml6Q8RWVzI98gDYFcvClHyeUviF2+xEwla\n\tl1w/OQdm7WCFwo1gV2HsGFhCQ74dur9TZqOSM+W6vPBJawRMpX/yvlQdE6HFrNPj7smZ\n\tvY4Q==","X-Gm-Message-State":"AHPjjUjzt+ZOVhmPOE5r4v6VPj96O9+7yUq3N4VchGfYZvMdV6MqF667\n\tmR6H7B6MhpLGxgZdHTuS9v1BOf7T5iv/E0C/Pjg=","X-Google-Smtp-Source":"AOwi7QA+A7e+Mnfl/7xmnCx1itqhKcB0A2VbjB36cv5TkrWg1Tmk7U4EA7Jj4jhbXnkUcfWiiDhv6Z49fw7ruwYarxU=","X-Received":"by 10.107.181.10 with SMTP id e10mr19910749iof.245.1506889946760;\n\tSun, 01 Oct 2017 13:32:26 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170918084943.GA19123@kroah.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t\n\t<20170918084943.GA19123@kroah.com>","From":"Martin Blumenstingl ","Date":"Sun, 1 Oct 2017 22:32:06 +0200","Message-ID":"","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","To":"Greg KH , mathias.nyman@intel.com","Cc":"robh+dt@kernel.org, devicetree@vger.kernel.org,\n\tmark.rutland@arm.com, arnd@arndb.de,\n\tlinux-amlogic@lists.infradead.org, chunfeng.yun@mediatek.com,\n\tlinux-usb@vger.kernel.org, felipe.balbi@linux.intel.com","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":1778293,"web_url":"http://patchwork.ozlabs.org/comment/1778293/","msgid":"<1506947708.17300.21.camel@baylibre.com>","list_archive_url":null,"date":"2017-10-02T12:35:08","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":69839,"url":"http://patchwork.ozlabs.org/api/people/69839/","name":"Jerome Brunet","email":"jbrunet@baylibre.com"},"content":"On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote:\n> Hello Greg, Hello Mathias,\n> \n> On Mon, Sep 18, 2017 at 10:49 AM, Greg KH wrote:\n> > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:\n> > > Hello Mathias, Hello Greg,\n> > > \n> > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n> > > wrote:\n> > > > This series is the outcome of a discussion with Felipe Balbi,\n> > > > see [0] and [1].\n> > > > The quick-summary of this is:\n> > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n> > > > correct\n> > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and\n> > > > ohci-platform.c) do not have a limitation on the number of PHYs - they\n> > > > support one PHY per actual host port\n> > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two\n> > > > or three USB2 ports enabled on the internal root-hub. The SoCs also\n> > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n> > > > internally \"connected\" to the dwc3 roothub) need to be powered on,\n> > > > otherwise USB devices cannot be enumerated (even if just one PHY is\n> > > > disabled and if the device is plugged into another, enabled port)\n> > > > \n> > > > In my first attempt to get USB supported on the GXL and GXM SoCs I tried\n> > > > to work-around the problem that I could not pass multiple PHYs to the\n> > > > dwc3 controller.\n> > > > This was rejected by Rob Herring (which was definitely the thing to do\n> > > > in\n> > > > my opinion), see [2]\n> > > > \n> > > > This series adds a new \"platform-roothub\". This can be configured\n> > > > through\n> > > > devicetree by passing a child-node with \"reg = <0>\" to the USB\n> > > > controller. Additionally there has to be a child-node for each port on\n> > > > the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n> > > > property. This allows modeling the root-hub in devicetree similar to the\n> > > > USB device binding (documented in devicetree/bindings/usb/usb-\n> > > > device.txt)\n> > > > This avoids and backwards-compatibility problems (which was a concern\n> > > > regardless of the solution, see [3]) since the binding for the root-hub\n> > > > was previously not specified (and we're not using the \"phys\" property of\n> > > > the controller, which might have served different purposes before,\n> > > > depending on the drivers).\n> > > > \n> > > > Additionally this integrates the new platform-roothub into xhci-plat.c\n> > > > which automatically enables it for the dwc3 driver (in host-mode).\n> > > > \n> > > > \n> > > > Changes since RFCv3 at [6]:\n> > > > - moved the DT binding change from patch #3 to patch #1 as suggested\n> > > > by Rob Herring (and slightly adjusted the commit message to account\n> > > > for that)\n> > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole\n> > > > concept and implementation works fine on Mediatek SoCs - many thanks\n> > > > again!) to patch #2\n> > > > - added Rob Herring's ACK to patches 1 and 3\n> > > > - dropped RFC status (RFCv3 -> PATCH v4)\n> > > \n> > > I just wanted to rebase this to v4.14-rc1 (now that this is out) -\n> > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the\n> > > patches are still identical to v4 after rebasing).\n> > > \n> > > we have an ACK from the devicetree maintainers and a \"Tested-by\" for a\n> > > Mediatek (= non-Amlogic) SoC.\n> > > I already have patches for the Amlogic GXL/GXM platforms queued, those\n> > > are just waiting on this series.\n> > > \n> > > what is still missing to get this series into v4.15?\n> > \n> > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let\n> > us catch up on patch review please...\n> \n> OK, I understand that.\n> please let me know once you've caught up with the review backlog - as\n> I said I would like to get this into 4.15 if nothing else comes up\n> during the code-review\n\nThis series works well on the libretech-cc (le potato)\nFor the series:\n\nTested-by: Jerome Brunet \n\n\n> \n> \n> Thank you!\n> Regards,\n> Martin\n> \n> _______________________________________________\n> linux-amlogic mailing list\n> linux-amlogic@lists.infradead.org\n> http://lists.infradead.org/mailman/listinfo/linux-amlogic\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=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=baylibre-com.20150623.gappssmtp.com\n\theader.i=@baylibre-com.20150623.gappssmtp.com header.b=\"Z4YUj2gZ\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5M7k68mTz9t39\n\tfor ;\n\tMon, 2 Oct 2017 23:35:14 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751188AbdJBMfN (ORCPT\n\t);\n\tMon, 2 Oct 2017 08:35:13 -0400","from mail-wm0-f43.google.com ([74.125.82.43]:54589 \"EHLO\n\tmail-wm0-f43.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751128AbdJBMfM (ORCPT\n\t); Mon, 2 Oct 2017 08:35:12 -0400","by mail-wm0-f43.google.com with SMTP id i124so10257748wmf.3\n\tfor ;\n\tMon, 02 Oct 2017 05:35:11 -0700 (PDT)","from boomer.home ([90.63.244.31]) by smtp.gmail.com with ESMTPSA id\n\tp78sm19974197wma.11.2017.10.02.05.35.09\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 02 Oct 2017 05:35:10 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=baylibre-com.20150623.gappssmtp.com; s=20150623;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=9J6RFa9eIIH/ar5EvyFyNelfoea/YKvweTELenKkjC8=;\n\tb=Z4YUj2gZDbmI/Qf7S+oTz/CBB9k+XEmdceixo3SwYNmO34dEgkkOnfVvNbBhidW+6o\n\tc1E2/JhKAqbQzlrLTQCsImy9X1fItyKHCTGYBh6IE0AZbqp3PwIDAXyCwz2SvYmrt9wq\n\tOi1R3oU30lTnZ5w+rr4QBNHPwcRuXladCpU9SZS/ztjFgSeX2ZHpQ/VCr7Ksq5+itanb\n\twiUG9p4IsAhyqC+WM+HLFpbJque1UvxAsiV39NP/OLwwpADuxlWMBXqix4HO1WsvXp90\n\tCpXC2dDtC/5Z6mntu8WNVnb4ByUrtYV3vk0YfoRPxFU3CKRHt9Pt+GzT6q3M6c+19IIg\n\tQ9cA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=9J6RFa9eIIH/ar5EvyFyNelfoea/YKvweTELenKkjC8=;\n\tb=HjXHfPS5IYT7FX3yiImZ5ikxjwgnASx8rho+WFbPBGcOQzq+8O4beLJWVYiSZwO2Mu\n\tqnRcmufGhdIVf6dXjKG4VnheALw2fkGEjeVZm2LTPnBfGpoDmVhSob91/MTGiEXl7YP1\n\tyGqRIAGHugJFfx1OFgdtwJhvfib5ti+4j/hAgNQcevMbN86flNqrPW6MeU79wJsq0wXb\n\tg4RhR+LZVKx+WWpjjazvo1yWIoiboGFxzebNNsdQrEoDfcULUaWtoF28tx2vBjATvVQU\n\tO5Oryu1O76iiM1p517TEjaBJ2Azj8vbRDaCmgSQ/H+xZ90OulFKd886U1M0PEXnDW5rA\n\tke3A==","X-Gm-Message-State":"AMCzsaV4+r7Odfp9x621GVRFRj7594I/NbQwzy6pVPqs10n3j+PZDVXN\n\toFU5exm4PPPzNCJ3YnO6tVonJQ==","X-Google-Smtp-Source":"AOwi7QDd0oBcfnPETZUMUz3LuUCs6R7PJnKM4OQ9c/Fxi8ltZ8PY6oVs7ql6km+pUCyVJKM9zuZkUQ==","X-Received":"by 10.28.91.194 with SMTP id p185mr6985994wmb.84.1506947710906; \n\tMon, 02 Oct 2017 05:35:10 -0700 (PDT)","Message-ID":"<1506947708.17300.21.camel@baylibre.com>","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","From":"Jerome Brunet ","To":"Martin Blumenstingl ,\n\tGreg KH , mathias.nyman@intel.com","Cc":"mark.rutland@arm.com, devicetree@vger.kernel.org,\n\tfelipe.balbi@linux.intel.com, arnd@arndb.de,\n\tlinux-usb@vger.kernel.org, robh+dt@kernel.org,\n\tchunfeng.yun@mediatek.com, linux-amlogic@lists.infradead.org","Date":"Mon, 02 Oct 2017 14:35:08 +0200","In-Reply-To":"","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t\n\t<20170918084943.GA19123@kroah.com>\n\t","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.24.5 (3.24.5-1.fc26) ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1778298,"web_url":"http://patchwork.ozlabs.org/comment/1778298/","msgid":"<20171002124421.GA2324@kroah.com>","list_archive_url":null,"date":"2017-10-02T12:44:21","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":11800,"url":"http://patchwork.ozlabs.org/api/people/11800/","name":"Greg Kroah-Hartman","email":"gregkh@linuxfoundation.org"},"content":"On Mon, Oct 02, 2017 at 02:35:08PM +0200, Jerome Brunet wrote:\n> On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote:\n> > Hello Greg, Hello Mathias,\n> > \n> > On Mon, Sep 18, 2017 at 10:49 AM, Greg KH wrote:\n> > > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:\n> > > > Hello Mathias, Hello Greg,\n> > > > \n> > > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n> > > > wrote:\n> > > > > This series is the outcome of a discussion with Felipe Balbi,\n> > > > > see [0] and [1].\n> > > > > The quick-summary of this is:\n> > > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n> > > > > correct\n> > > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and\n> > > > > ohci-platform.c) do not have a limitation on the number of PHYs - they\n> > > > > support one PHY per actual host port\n> > > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two\n> > > > > or three USB2 ports enabled on the internal root-hub. The SoCs also\n> > > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n> > > > > internally \"connected\" to the dwc3 roothub) need to be powered on,\n> > > > > otherwise USB devices cannot be enumerated (even if just one PHY is\n> > > > > disabled and if the device is plugged into another, enabled port)\n> > > > > \n> > > > > In my first attempt to get USB supported on the GXL and GXM SoCs I tried\n> > > > > to work-around the problem that I could not pass multiple PHYs to the\n> > > > > dwc3 controller.\n> > > > > This was rejected by Rob Herring (which was definitely the thing to do\n> > > > > in\n> > > > > my opinion), see [2]\n> > > > > \n> > > > > This series adds a new \"platform-roothub\". This can be configured\n> > > > > through\n> > > > > devicetree by passing a child-node with \"reg = <0>\" to the USB\n> > > > > controller. Additionally there has to be a child-node for each port on\n> > > > > the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n> > > > > property. This allows modeling the root-hub in devicetree similar to the\n> > > > > USB device binding (documented in devicetree/bindings/usb/usb-\n> > > > > device.txt)\n> > > > > This avoids and backwards-compatibility problems (which was a concern\n> > > > > regardless of the solution, see [3]) since the binding for the root-hub\n> > > > > was previously not specified (and we're not using the \"phys\" property of\n> > > > > the controller, which might have served different purposes before,\n> > > > > depending on the drivers).\n> > > > > \n> > > > > Additionally this integrates the new platform-roothub into xhci-plat.c\n> > > > > which automatically enables it for the dwc3 driver (in host-mode).\n> > > > > \n> > > > > \n> > > > > Changes since RFCv3 at [6]:\n> > > > > - moved the DT binding change from patch #3 to patch #1 as suggested\n> > > > > by Rob Herring (and slightly adjusted the commit message to account\n> > > > > for that)\n> > > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole\n> > > > > concept and implementation works fine on Mediatek SoCs - many thanks\n> > > > > again!) to patch #2\n> > > > > - added Rob Herring's ACK to patches 1 and 3\n> > > > > - dropped RFC status (RFCv3 -> PATCH v4)\n> > > > \n> > > > I just wanted to rebase this to v4.14-rc1 (now that this is out) -\n> > > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the\n> > > > patches are still identical to v4 after rebasing).\n> > > > \n> > > > we have an ACK from the devicetree maintainers and a \"Tested-by\" for a\n> > > > Mediatek (= non-Amlogic) SoC.\n> > > > I already have patches for the Amlogic GXL/GXM platforms queued, those\n> > > > are just waiting on this series.\n> > > > \n> > > > what is still missing to get this series into v4.15?\n> > > \n> > > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let\n> > > us catch up on patch review please...\n> > \n> > OK, I understand that.\n> > please let me know once you've caught up with the review backlog - as\n> > I said I would like to get this into 4.15 if nothing else comes up\n> > during the code-review\n> \n> This series works well on the libretech-cc (le potato)\n> For the series:\n> \n> Tested-by: Jerome Brunet \n\nHey, I have one of those boards now, was just about to try to get it to\nwork. Is this series necessary for it to run properly on 4.14-rc?\n\nthanks,\n\ngreg k-h\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 3y5ML73FWVz9sRm\n\tfor ;\n\tMon, 2 Oct 2017 23:44:15 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751337AbdJBMoN (ORCPT\n\t);\n\tMon, 2 Oct 2017 08:44:13 -0400","from mail.linuxfoundation.org ([140.211.169.12]:58968 \"EHLO\n\tmail.linuxfoundation.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751326AbdJBMoN (ORCPT\n\t); Mon, 2 Oct 2017 08:44:13 -0400","from localhost (LFbn-1-12253-150.w90-92.abo.wanadoo.fr\n\t[90.92.67.150])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPSA id 180A194F;\n\tMon, 2 Oct 2017 12:44:12 +0000 (UTC)"],"Date":"Mon, 2 Oct 2017 14:44:21 +0200","From":"Greg KH ","To":"Jerome Brunet ","Cc":"Martin Blumenstingl ,\n\tmathias.nyman@intel.com, mark.rutland@arm.com,\n\tdevicetree@vger.kernel.org, felipe.balbi@linux.intel.com,\n\tarnd@arndb.de, linux-usb@vger.kernel.org, robh+dt@kernel.org,\n\tchunfeng.yun@mediatek.com, linux-amlogic@lists.infradead.org","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","Message-ID":"<20171002124421.GA2324@kroah.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t\n\t<20170918084943.GA19123@kroah.com>\n\t\n\t<1506947708.17300.21.camel@baylibre.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1506947708.17300.21.camel@baylibre.com>","User-Agent":"Mutt/1.9.1 (2017-09-22)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1778661,"web_url":"http://patchwork.ozlabs.org/comment/1778661/","msgid":"","list_archive_url":null,"date":"2017-10-02T23:18:05","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":66366,"url":"http://patchwork.ozlabs.org/api/people/66366/","name":"Martin Blumenstingl","email":"martin.blumenstingl@googlemail.com"},"content":"Hi Greg,\n\nOn Mon, Oct 2, 2017 at 2:44 PM, Greg KH wrote:\n> On Mon, Oct 02, 2017 at 02:35:08PM +0200, Jerome Brunet wrote:\n>> On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote:\n>> > Hello Greg, Hello Mathias,\n>> >\n>> > On Mon, Sep 18, 2017 at 10:49 AM, Greg KH wrote:\n>> > > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:\n>> > > > Hello Mathias, Hello Greg,\n>> > > >\n>> > > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n>> > > > wrote:\n>> > > > > This series is the outcome of a discussion with Felipe Balbi,\n>> > > > > see [0] and [1].\n>> > > > > The quick-summary of this is:\n>> > > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n>> > > > > correct\n>> > > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and\n>> > > > > ohci-platform.c) do not have a limitation on the number of PHYs - they\n>> > > > > support one PHY per actual host port\n>> > > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two\n>> > > > > or three USB2 ports enabled on the internal root-hub. The SoCs also\n>> > > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n>> > > > > internally \"connected\" to the dwc3 roothub) need to be powered on,\n>> > > > > otherwise USB devices cannot be enumerated (even if just one PHY is\n>> > > > > disabled and if the device is plugged into another, enabled port)\n>> > > > >\n>> > > > > In my first attempt to get USB supported on the GXL and GXM SoCs I tried\n>> > > > > to work-around the problem that I could not pass multiple PHYs to the\n>> > > > > dwc3 controller.\n>> > > > > This was rejected by Rob Herring (which was definitely the thing to do\n>> > > > > in\n>> > > > > my opinion), see [2]\n>> > > > >\n>> > > > > This series adds a new \"platform-roothub\". This can be configured\n>> > > > > through\n>> > > > > devicetree by passing a child-node with \"reg = <0>\" to the USB\n>> > > > > controller. Additionally there has to be a child-node for each port on\n>> > > > > the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n>> > > > > property. This allows modeling the root-hub in devicetree similar to the\n>> > > > > USB device binding (documented in devicetree/bindings/usb/usb-\n>> > > > > device.txt)\n>> > > > > This avoids and backwards-compatibility problems (which was a concern\n>> > > > > regardless of the solution, see [3]) since the binding for the root-hub\n>> > > > > was previously not specified (and we're not using the \"phys\" property of\n>> > > > > the controller, which might have served different purposes before,\n>> > > > > depending on the drivers).\n>> > > > >\n>> > > > > Additionally this integrates the new platform-roothub into xhci-plat.c\n>> > > > > which automatically enables it for the dwc3 driver (in host-mode).\n>> > > > >\n>> > > > >\n>> > > > > Changes since RFCv3 at [6]:\n>> > > > > - moved the DT binding change from patch #3 to patch #1 as suggested\n>> > > > > by Rob Herring (and slightly adjusted the commit message to account\n>> > > > > for that)\n>> > > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole\n>> > > > > concept and implementation works fine on Mediatek SoCs - many thanks\n>> > > > > again!) to patch #2\n>> > > > > - added Rob Herring's ACK to patches 1 and 3\n>> > > > > - dropped RFC status (RFCv3 -> PATCH v4)\n>> > > >\n>> > > > I just wanted to rebase this to v4.14-rc1 (now that this is out) -\n>> > > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the\n>> > > > patches are still identical to v4 after rebasing).\n>> > > >\n>> > > > we have an ACK from the devicetree maintainers and a \"Tested-by\" for a\n>> > > > Mediatek (= non-Amlogic) SoC.\n>> > > > I already have patches for the Amlogic GXL/GXM platforms queued, those\n>> > > > are just waiting on this series.\n>> > > >\n>> > > > what is still missing to get this series into v4.15?\n>> > >\n>> > > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let\n>> > > us catch up on patch review please...\n>> >\n>> > OK, I understand that.\n>> > please let me know once you've caught up with the review backlog - as\n>> > I said I would like to get this into 4.15 if nothing else comes up\n>> > during the code-review\n>>\n>> This series works well on the libretech-cc (le potato)\n>> For the series:\n>>\n>> Tested-by: Jerome Brunet \n>\n> Hey, I have one of those boards now, was just about to try to get it to\n> work. Is this series necessary for it to run properly on 4.14-rc?\nif you're speaking of the \"libretech-cc (le potato)\" board then indeed, it is\n\nhowever, it's just one piece of the whole puzzle:\n1) we need this series to initialize all USB PHYs correctly\n2) we need to initialize the USB3 PHY with a basic driver, see this series: [0]\n3) all the USB PHYs and the dwc3 controller has to be added to the\n.dts files (no patchset was sent yet because I don't want to maintain\nanother series of patches as long as this one is not accepted yet)\n\nI made a branch which includes all puzzle pieces: [1]\nplease let me know if this works for you!\n\nPS: I will send an official patchset for the .dts changes once the\nother two patchsets are accepted\n\n\nThank you for testing this!\n\n\nRegards,\nMartin\n\n\n[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-September/004780.html\n[1] https://github.com/xdarklight/linux/commits/meson-gxl-usb-test-greg1\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\" (2048-bit key;\n\tunprotected) header.d=googlemail.com header.i=@googlemail.com\n\theader.b=\"MXQw9RAJ\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5dPx11c9z9t4c\n\tfor ;\n\tTue, 3 Oct 2017 10:18:29 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751247AbdJBXS1 (ORCPT\n\t);\n\tMon, 2 Oct 2017 19:18:27 -0400","from mail-it0-f67.google.com ([209.85.214.67]:54267 \"EHLO\n\tmail-it0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751181AbdJBXS0 (ORCPT\n\t); Mon, 2 Oct 2017 19:18:26 -0400","by mail-it0-f67.google.com with SMTP id 85so9281488ith.2;\n\tMon, 02 Oct 2017 16:18:26 -0700 (PDT)","by 10.2.51.84 with HTTP; Mon, 2 Oct 2017 16:18:05 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlemail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=yyqzigIXjPszRfhmLcXfA9QVgBioBkFOfsb1+KnKW48=;\n\tb=MXQw9RAJ+h8bkfepeo9ZBu6GCD0b523oJcDlxJeXiELw9X02oEEin4vMqtORbKHUka\n\tsUgwfI78l2CAyw0UvalFdQH1Ek+iB1TuqVJuKooXymzh9ePc5DkEwDq0ynzwLfcWiupX\n\t9a2sAqOvSQ3TM5u+Yu9X6HH18vmg4FQkP6pNhvPMky7IC9rf/CmlivX/BMbAGsLBRfP6\n\tWg9TV4ILkljNMOiND8dP3OReLFQhRckzrmuoJo/9ICxQKl3AO8609itkpDPbjGorKsgl\n\tkxnQumCeqkEt887/qLH7m1rzoCztpY5BRUjfRTxUtMw2u57qti1QvDtCoaYXUOgbmQy9\n\tlT5Q==","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=yyqzigIXjPszRfhmLcXfA9QVgBioBkFOfsb1+KnKW48=;\n\tb=AXAakYZNOwQfeo28PeTdCGnl1zNkv1t8kO97c++mxBPJj6v/iFP1+G9csVcoSenNJA\n\tpJ4sQIcH9XYYAhuOZcVU8xpDYbj0VlmEDLL5LL9M42qw41K0YbsMqvTabVdG+9GrQOtR\n\tKWHUhPVKfxsddUlbEI4YQzaAQ1t6g6XYwOZHs+yYmbNwFs5/oCcTCaytgLIhX9DkG4EQ\n\t/KQz9F8KGmkJhkVGGKDYnc2AbRXCYvudBqA8Q2EPRicwSOaVEyoNkh4c6Y4EdVZ+WqFl\n\tjA66REiumkd2r3KneVR0tyDKjsan1Y0I03vEJAUYZkRkk4J7FSGOIuuijsHa+De3KPln\n\tkBhA==","X-Gm-Message-State":"AMCzsaUPcLOQE4QWD7iS8Eigod2lMUg6ksFn2j0RvBFlmxoRFaVhGkd5\n\tQNiiEN+7YHEVaFLxzXECSxb/l8bHMFzuGvljyRU=","X-Google-Smtp-Source":"AOwi7QAgboEj6BEmPQsuuGOWYoTGN7JEKtDfA7n0bJE4TApk7F3j8dfE/vwBuB+GOxcoINb//B8LCmrwaMwP5yoEl34=","X-Received":"by 10.36.205.67 with SMTP id l64mr6327299itg.101.1506986305596; \n\tMon, 02 Oct 2017 16:18:25 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171002124421.GA2324@kroah.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t\n\t<20170918084943.GA19123@kroah.com>\n\t\n\t<1506947708.17300.21.camel@baylibre.com>\n\t<20171002124421.GA2324@kroah.com>","From":"Martin Blumenstingl ","Date":"Tue, 3 Oct 2017 01:18:05 +0200","Message-ID":"","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","To":"Greg KH ","Cc":"Jerome Brunet , mathias.nyman@intel.com,\n\tmark.rutland@arm.com, devicetree@vger.kernel.org,\n\tfelipe.balbi@linux.intel.com, arnd@arndb.de,\n\tlinux-usb@vger.kernel.org, robh+dt@kernel.org,\n\tchunfeng.yun@mediatek.com, linux-amlogic@lists.infradead.org","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":1778766,"web_url":"http://patchwork.ozlabs.org/comment/1778766/","msgid":"<1507018544.17300.116.camel@baylibre.com>","list_archive_url":null,"date":"2017-10-03T08:15:44","subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","submitter":{"id":69839,"url":"http://patchwork.ozlabs.org/api/people/69839/","name":"Jerome Brunet","email":"jbrunet@baylibre.com"},"content":"On Mon, 2017-10-02 at 14:44 +0200, Greg KH wrote:\n> On Mon, Oct 02, 2017 at 02:35:08PM +0200, Jerome Brunet wrote:\n> > On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote:\n> > > Hello Greg, Hello Mathias,\n> > > \n> > > On Mon, Sep 18, 2017 at 10:49 AM, Greg KH \n> > > wrote:\n> > > > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:\n> > > > > Hello Mathias, Hello Greg,\n> > > > > \n> > > > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl\n> > > > > wrote:\n> > > > > > This series is the outcome of a discussion with Felipe Balbi,\n> > > > > > see [0] and [1].\n> > > > > > The quick-summary of this is:\n> > > > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these\n> > > > > > correct\n> > > > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c\n> > > > > > and\n> > > > > > ohci-platform.c) do not have a limitation on the number of PHYs -\n> > > > > > they\n> > > > > > support one PHY per actual host port\n> > > > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has\n> > > > > > two\n> > > > > > or three USB2 ports enabled on the internal root-hub. The SoCs\n> > > > > > also\n> > > > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are\n> > > > > > internally \"connected\" to the dwc3 roothub) need to be powered on,\n> > > > > > otherwise USB devices cannot be enumerated (even if just one PHY\n> > > > > > is\n> > > > > > disabled and if the device is plugged into another, enabled port)\n> > > > > > \n> > > > > > In my first attempt to get USB supported on the GXL and GXM SoCs I\n> > > > > > tried\n> > > > > > to work-around the problem that I could not pass multiple PHYs to\n> > > > > > the\n> > > > > > dwc3 controller.\n> > > > > > This was rejected by Rob Herring (which was definitely the thing to\n> > > > > > do\n> > > > > > in\n> > > > > > my opinion), see [2]\n> > > > > > \n> > > > > > This series adds a new \"platform-roothub\". This can be configured\n> > > > > > through\n> > > > > > devicetree by passing a child-node with \"reg = <0>\" to the USB\n> > > > > > controller. Additionally there has to be a child-node for each port\n> > > > > > on\n> > > > > > the root-hub. Each of the child-nodes takes a \"phys\" and \"phy-names\"\n> > > > > > property. This allows modeling the root-hub in devicetree similar to\n> > > > > > the\n> > > > > > USB device binding (documented in devicetree/bindings/usb/usb-\n> > > > > > device.txt)\n> > > > > > This avoids and backwards-compatibility problems (which was a\n> > > > > > concern\n> > > > > > regardless of the solution, see [3]) since the binding for the root-\n> > > > > > hub\n> > > > > > was previously not specified (and we're not using the \"phys\"\n> > > > > > property of\n> > > > > > the controller, which might have served different purposes before,\n> > > > > > depending on the drivers).\n> > > > > > \n> > > > > > Additionally this integrates the new platform-roothub into xhci-\n> > > > > > plat.c\n> > > > > > which automatically enables it for the dwc3 driver (in host-mode).\n> > > > > > \n> > > > > > \n> > > > > > Changes since RFCv3 at [6]:\n> > > > > > - moved the DT binding change from patch #3 to patch #1 as suggested\n> > > > > > by Rob Herring (and slightly adjusted the commit message to\n> > > > > > account\n> > > > > > for that)\n> > > > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole\n> > > > > > concept and implementation works fine on Mediatek SoCs - many\n> > > > > > thanks\n> > > > > > again!) to patch #2\n> > > > > > - added Rob Herring's ACK to patches 1 and 3\n> > > > > > - dropped RFC status (RFCv3 -> PATCH v4)\n> > > > > \n> > > > > I just wanted to rebase this to v4.14-rc1 (now that this is out) -\n> > > > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the\n> > > > > patches are still identical to v4 after rebasing).\n> > > > > \n> > > > > we have an ACK from the devicetree maintainers and a \"Tested-by\" for a\n> > > > > Mediatek (= non-Amlogic) SoC.\n> > > > > I already have patches for the Amlogic GXL/GXM platforms queued, those\n> > > > > are just waiting on this series.\n> > > > > \n> > > > > what is still missing to get this series into v4.15?\n> > > > \n> > > > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let\n> > > > us catch up on patch review please...\n> > > \n> > > OK, I understand that.\n> > > please let me know once you've caught up with the review backlog - as\n> > > I said I would like to get this into 4.15 if nothing else comes up\n> > > during the code-review\n> > \n> > This series works well on the libretech-cc (le potato)\n> > For the series:\n> > \n> > Tested-by: Jerome Brunet \n> \n> Hey, I have one of those boards now, was just about to try to get it to\n> work. Is this series necessary for it to run properly on 4.14-rc?\n\nTo run w/o usb, no. It should already be decent on 4.14-rc.\nTo run with usb, you need this series and:\n\n* the usb3 phy driver sent but (I believe) not yet merged [0]\n* A few DT changes enable the whole thing.\n\nThe whole thing is available here [1]\n\nHowever, while you were at KR2017, we found an unrelated, yet very annoying,\nissue which may trigger \"Synchronous External Aborts\" ... The whole story is\navailable here [2] and the work around patch is available here [3].\n\nIf you have downloaded your image from here [4], the kernel is a v4.13 plus\n* few changes already merged in next or under review (cec, mmc, usb, ...)\n* Overlay support \n* WIP for the hdmi audio.\nSources are here [5]\n\n[0]: https://lkml.kernel.org/r/20170924195000.13276-1-martin.blumenstingl@google\nmail.com\n[1]: https://github.com/libre-computer-project/libretech-linux/commits/linux-4.1\n3/usb\n[2]: https://lkml.kernel.org/r/1507017860.17300.106.camel@baylibre.com\n[3]: https://github.com/libre-computer-project/libretech-linux/commit/0f71f762a9\nc37ab423e0c9e0498081a9a17f2b8a\n[4]: http://baylibre.com/kernel-recipes-mainline-aml-s905x-cc-le-potato/\n[5]: https://github.com/libre-computer-project/libretech-linux/commits/linux-4.1\n3/libretech-cc-overlays\n\n> \n> thanks,\n> \n> greg k-h\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=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=baylibre-com.20150623.gappssmtp.com\n\theader.i=@baylibre-com.20150623.gappssmtp.com header.b=\"xXQgZBbm\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5sKy6JR3z9t4X\n\tfor ;\n\tTue, 3 Oct 2017 19:15:50 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751146AbdJCIPt (ORCPT\n\t);\n\tTue, 3 Oct 2017 04:15:49 -0400","from mail-wr0-f179.google.com ([209.85.128.179]:49794 \"EHLO\n\tmail-wr0-f179.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751111AbdJCIPs (ORCPT\n\t); Tue, 3 Oct 2017 04:15:48 -0400","by mail-wr0-f179.google.com with SMTP id p10so3896611wrc.6\n\tfor ;\n\tTue, 03 Oct 2017 01:15:47 -0700 (PDT)","from boomer ([90.63.244.31]) by smtp.gmail.com with ESMTPSA id\n\t69sm13973226wmm.22.2017.10.03.01.15.45\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tTue, 03 Oct 2017 01:15:46 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=baylibre-com.20150623.gappssmtp.com; s=20150623;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=adi55dFlRJc4H4FWIk/1O9opx/ZYe3pmVzTPsTiLqY0=;\n\tb=xXQgZBbmK498dTMf/I/MkqIIh547v9YtrhHzD3OYnagxIrFPNcbJrW5eutq/q08T2r\n\tB7EWVJ0iUEmytIVbIbQKiDSf5FQ6ChQl93y8A1ikwtphVEqdtQTTQxe4TozEtMIMLDwN\n\tBiuLbH1T+jMlkog4EPriS4JibxATy/CICq5OHbQQBYGTG6h3pHikMSop1bzcoq64eWHs\n\tEdQG2rHxAZ3no/tz++7K4gsu0Y9PeZDLuToG15XxZGLOJzMtUUVb+dltYCHn/kG1f/Kh\n\tpfkb/CrTej+sBDNkIGB+xWp09pvs6ENFphvs4bX94hzhRR46Koh1QbsTMzCW5wJe8TBz\n\to+gQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=adi55dFlRJc4H4FWIk/1O9opx/ZYe3pmVzTPsTiLqY0=;\n\tb=jJ3D2Lylu67dh6IF0YYwrohlo7rf69gne0owWqvdHepAKA7wVNbeTNGaOX6MuEPOPI\n\tXQ+u3DC734K5CUiyZ2OdbxsAxVS59lO574u6en2ElNe8wBn8yNAQJ1LqKYAmi+KMt/q2\n\tVRSZbpQKnH8kg2qcStY///YVuDYxAHxAYVfOHaZo8V8ynQ6kA/SP7A9aRTH8tFAAC6DB\n\tIWfuKAbVXss+XuplJXTltG1oz9rxquTkhAhLMOfdT1mDgOSDURNrdVhnkIOpcF04wA/r\n\thGlINlHhVssyvuyzbAd4mgoVhOGAWykxCozH+/iWbUMgjKbqtwMq99JQHtXnnNR9DHhT\n\tjcyw==","X-Gm-Message-State":"AHPjjUh54uUpwMPdPnGzb2IuRwqA38F6HGPv/f0izVbzKZokKBEVpAw/\n\tq7hq05AUjbiTbpxWjiikZAZMQw==","X-Google-Smtp-Source":"AOwi7QDz9RBEFctHUNtigsoA7rqBqhth1iw+iHL5hiTGMW2HATSwMnXmtCqLHqfoE5PRBqwHg4VDuQ==","X-Received":"by 10.223.197.13 with SMTP id q13mr18080296wrf.80.1507018546659; \n\tTue, 03 Oct 2017 01:15:46 -0700 (PDT)","Message-ID":"<1507018544.17300.116.camel@baylibre.com>","Subject":"Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat","From":"Jerome Brunet ","To":"Greg KH ","Cc":"Martin Blumenstingl ,\n\tmathias.nyman@intel.com, mark.rutland@arm.com,\n\tdevicetree@vger.kernel.org, felipe.balbi@linux.intel.com,\n\tarnd@arndb.de, linux-usb@vger.kernel.org, robh+dt@kernel.org,\n\tchunfeng.yun@mediatek.com, linux-amlogic@lists.infradead.org","Date":"Tue, 03 Oct 2017 10:15:44 +0200","In-Reply-To":"<20171002124421.GA2324@kroah.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t\n\t<20170918084943.GA19123@kroah.com>\n\t\n\t<1506947708.17300.21.camel@baylibre.com>\n\t<20171002124421.GA2324@kroah.com>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.24.5 (3.24.5-1.fc26) ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1779793,"web_url":"http://patchwork.ozlabs.org/comment/1779793/","msgid":"<59D4DC7E.6040003@linux.intel.com>","list_archive_url":null,"date":"2017-10-04T13:05:02","subject":"Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub\n\tdriver","submitter":{"id":63937,"url":"http://patchwork.ozlabs.org/api/people/63937/","name":"Mathias Nyman","email":"mathias.nyman@linux.intel.com"},"content":"On 04.09.2017 00:38, Martin Blumenstingl wrote:\n> Many SoC platforms have separate devices for the USB PHY which are\n> registered through the generic PHY framework. These PHYs have to be\n> enabled to make the USB controller actually work. They also have to be\n> disabled again on shutdown/suspend.\n>\n> Currently (at least) the following HCI platform drivers are using custom\n> code to obtain all PHYs via devicetree for the roothub/controller and\n> disable/enable them when required:\n> - ehci-platform.c has ehci_platform_power_{on,off}\n> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}\n> - ohci-platform.c has ohci_platform_power_{on,off}\n>\n> These drivers are not using the generic devicetree USB device bindings\n> yet which were only introduced recently (documentation is available in\n> devicetree/bindings/usb/usb-device.txt).\n> With this new driver the usb2-phy and usb3-phy can be specified directly\n> in the child-node of the corresponding port of the roothub via\n> devicetree. This can be extended by not just parsing PHYs (some of the\n> other drivers listed above are for example also parsing a list of clocks\n> as well) when required.\n\nusb_add_hcd() in usb/core/hcd.c is already finding, initializing and turning\non a phy, would it make sense to expand that one to support several phys instead?\n\nxhci will add two hcd's one for USB2 and one for USB3\n\n>\n> Signed-off-by: Martin Blumenstingl \n> Tested-by: Chunfeng Yun \n> ---\n> drivers/usb/host/Kconfig | 3 +\n> drivers/usb/host/Makefile | 2 +\n> drivers/usb/host/platform-roothub.c | 180 ++++++++++++++++++++++++++++++++++++\n> drivers/usb/host/platform-roothub.h | 12 +++\n> 4 files changed, 197 insertions(+)\n> create mode 100644 drivers/usb/host/platform-roothub.c\n> create mode 100644 drivers/usb/host/platform-roothub.h\n>\n\nInstead of creating platform-roothub files could this content\nbe added into into core/hcd.*, core/phy.* and host/xhci-plat.c\n\n> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig\n> index fa5692dec832..b8b05c786b2a 100644\n> --- a/drivers/usb/host/Kconfig\n> +++ b/drivers/usb/host/Kconfig\n> @@ -805,6 +805,9 @@ config USB_HCD_SSB\n>\n> \t If unsure, say N.\n>\n> +config USB_PLATFORM_ROOTHUB\n> +\tbool\n> +\n> config USB_HCD_TEST_MODE\n> \tbool \"HCD test mode support\"\n> \t---help---\n> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile\n> index cf2691fffcc0..dc817f82d632 100644\n> --- a/drivers/usb/host/Makefile\n> +++ b/drivers/usb/host/Makefile\n> @@ -29,6 +29,8 @@ obj-$(CONFIG_USB_WHCI_HCD)\t+= whci/\n>\n> obj-$(CONFIG_USB_PCI)\t+= pci-quirks.o\n>\n> +obj-$(CONFIG_USB_PLATFORM_ROOTHUB)\t+= platform-roothub.o\n> +\n> obj-$(CONFIG_USB_EHCI_HCD)\t+= ehci-hcd.o\n> obj-$(CONFIG_USB_EHCI_PCI)\t+= ehci-pci.o\n> obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)\t+= ehci-platform.o\n> diff --git a/drivers/usb/host/platform-roothub.c b/drivers/usb/host/platform-roothub.c\n> new file mode 100644\n> index 000000000000..70d2d97aa8b2\n> --- /dev/null\n> +++ b/drivers/usb/host/platform-roothub.c\n> @@ -0,0 +1,180 @@\n> +/*\n> + * platform roothub driver - a virtual PHY device which passes all phy_*\n> + * function calls to multiple (actual) PHY devices. This is comes handy when\n> + * initializing all PHYs on a root-hub (to keep them all in the same state).\n> + *\n> + * Copyright (C) 2017 Martin Blumenstingl \n> + *\n> + * This program is free software; you can redistribute it and/or modify\n> + * it under the terms of the GNU General Public License version 2 as\n> + * published by the Free Software Foundation.\n> + *\n> + * You should have received a copy of the GNU General Public License\n> + * along with this program. If not, see .\n> + */\n> +\n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +\n> +#include \"platform-roothub.h\"\n> +\n> +#define ROOTHUB_PORTNUM\t\t0\n> +\n> +struct platform_roothub {\n> +\tstruct phy\t\t*phy;\n> +\tstruct list_head\tlist;\n> +};\n> +\n> +static struct platform_roothub *platform_roothub_alloc(struct device *dev)\n> +{\n> +\tstruct platform_roothub *roothub_entry;\n> +\n> +\troothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);\n> +\tif (!roothub_entry)\n> +\t\treturn ERR_PTR(-ENOMEM);\n> +\n> +\tINIT_LIST_HEAD(&roothub_entry->list);\n> +\n> +\treturn roothub_entry;\n> +}\n> +\n> +static int platform_roothub_add_phy(struct device *dev,\n> +\t\t\t\t struct device_node *port_np,\n> +\t\t\t\t const char *con_id, struct list_head *list)\n> +{\n> +\tstruct platform_roothub *roothub_entry;\n> +\tstruct phy *phy = devm_of_phy_get(dev, port_np, con_id);\n> +\n> +\tif (IS_ERR_OR_NULL(phy)) {\n> +\t\tif (!phy || PTR_ERR(phy) == -ENODEV)\n> +\t\t\treturn 0;\n> +\t\telse\n> +\t\t\treturn PTR_ERR(phy);\n> +\t}\n> +\n> +\troothub_entry = platform_roothub_alloc(dev);\n> +\tif (IS_ERR(roothub_entry))\n> +\t\treturn PTR_ERR(roothub_entry);\n> +\n> +\troothub_entry->phy = phy;\n> +\n> +\tlist_add_tail(&roothub_entry->list, list);\n> +\n> +\treturn 0;\n> +}\n> +\n> +struct platform_roothub *platform_roothub_init(struct device *dev)\n> +{\n> +\tstruct device_node *roothub_np, *port_np;\n> +\tstruct platform_roothub *plat_roothub;\n> +\tstruct platform_roothub *roothub_entry;\n> +\tstruct list_head *head;\n> +\tint err;\n> +\n> +\troothub_np = usb_of_get_child_node(dev->of_node, ROOTHUB_PORTNUM);\n> +\tif (!of_device_is_available(roothub_np))\n> +\t\treturn NULL;\n> +\n> +\tplat_roothub = platform_roothub_alloc(dev);\n> +\tif (IS_ERR(plat_roothub))\n> +\t\treturn plat_roothub;\n> +\n> +\tfor_each_available_child_of_node(roothub_np, port_np) {\n> +\t\terr = platform_roothub_add_phy(dev, port_np, \"usb2-phy\",\n> +\t\t\t\t\t &plat_roothub->list);\n> +\t\tif (err)\n> +\t\t\tgoto err_out;\n> +\n> +\t\terr = platform_roothub_add_phy(dev, port_np, \"usb3-phy\",\n> +\t\t\t\t\t &plat_roothub->list);\n\nSo if the first 10 ports have the same phy, and 11th and 12th have an other one, won't we end up\nwith a phy list with 12 entries for 2 phys, and initialize and turn on the same first phy 10 times?\n\nI'm also not sure I understand the reason for having the \"usb3-phy\" and \"usb2-phy\" phy-names\nfor the ports if we anyways just add everything to one list.\n\n-Mathias\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 3y6bct10W1z9t2S\n\tfor ;\n\tThu, 5 Oct 2017 00:01:18 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752066AbdJDNBQ (ORCPT\n\t);\n\tWed, 4 Oct 2017 09:01:16 -0400","from mga02.intel.com ([134.134.136.20]:54316 \"EHLO mga02.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751905AbdJDNBP (ORCPT );\n\tWed, 4 Oct 2017 09:01:15 -0400","from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t04 Oct 2017 06:01:14 -0700","from mattu-haswell.fi.intel.com (HELO [10.237.72.164])\n\t([10.237.72.164])\n\tby FMSMGA003.fm.intel.com with ESMTP; 04 Oct 2017 06:01:11 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,477,1500966000\"; d=\"scan'208\";a=\"906645945\"","Subject":"Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub\n\tdriver","To":"Martin Blumenstingl ,\n\tlinux-usb@vger.kernel.org, gregkh@linuxfoundation.org,\n\tfelipe.balbi@linux.intel.com, mathias.nyman@intel.com","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t<20170903213829.6589-3-martin.blumenstingl@googlemail.com>","Cc":"robh+dt@kernel.org, devicetree@vger.kernel.org,\n\tmark.rutland@arm.com, arnd@arndb.de,\n\tlinux-amlogic@lists.infradead.org, chunfeng.yun@mediatek.com","From":"Mathias Nyman ","Message-ID":"<59D4DC7E.6040003@linux.intel.com>","Date":"Wed, 4 Oct 2017 16:05:02 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101\n\tThunderbird/38.8.0","MIME-Version":"1.0","In-Reply-To":"<20170903213829.6589-3-martin.blumenstingl@googlemail.com>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1782153,"web_url":"http://patchwork.ozlabs.org/comment/1782153/","msgid":"","list_archive_url":null,"date":"2017-10-07T17:08:27","subject":"Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub\n\tdriver","submitter":{"id":66366,"url":"http://patchwork.ozlabs.org/api/people/66366/","name":"Martin Blumenstingl","email":"martin.blumenstingl@googlemail.com"},"content":"Hi Mathias,\n\nthank you for taking the time to go through my patch\n\nOn Wed, Oct 4, 2017 at 3:05 PM, Mathias Nyman\n wrote:\n> On 04.09.2017 00:38, Martin Blumenstingl wrote:\n>>\n>> Many SoC platforms have separate devices for the USB PHY which are\n>> registered through the generic PHY framework. These PHYs have to be\n>> enabled to make the USB controller actually work. They also have to be\n>> disabled again on shutdown/suspend.\n>>\n>> Currently (at least) the following HCI platform drivers are using custom\n>> code to obtain all PHYs via devicetree for the roothub/controller and\n>> disable/enable them when required:\n>> - ehci-platform.c has ehci_platform_power_{on,off}\n>> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}\n>> - ohci-platform.c has ohci_platform_power_{on,off}\n>>\n>> These drivers are not using the generic devicetree USB device bindings\n>> yet which were only introduced recently (documentation is available in\n>> devicetree/bindings/usb/usb-device.txt).\n>> With this new driver the usb2-phy and usb3-phy can be specified directly\n>> in the child-node of the corresponding port of the roothub via\n>> devicetree. This can be extended by not just parsing PHYs (some of the\n>> other drivers listed above are for example also parsing a list of clocks\n>> as well) when required.\n>\n>\n> usb_add_hcd() in usb/core/hcd.c is already finding, initializing and turning\n> on a phy, would it make sense to expand that one to support several phys\n> instead?\n>\n> xhci will add two hcd's one for USB2 and one for USB3\nthat is a great suggestion - thank you for bringing this up!\nas a benefit we would add multiple PHY support for all the other\nuse-cases I found (at least: ehci-platform.c, xhci-mtk.c,\nohci-platform.c) - instead of just handling this in xhci-plat.c\n\nI have one quick question regarding usb/core/hcd.c:\nare hcd_bus_suspend() and hcd_bus_resume() the right places to\npower_{off,on} the PHYs during suspend?\n(currently usb/core/hcd.c doesn't touch the PHY during suspend/resume\n- xhci-mtk.c on the other hand seems to require it during a\nsuspend/resume cycle)\n\n>>\n>> Signed-off-by: Martin Blumenstingl \n>> Tested-by: Chunfeng Yun \n>> ---\n>> drivers/usb/host/Kconfig | 3 +\n>> drivers/usb/host/Makefile | 2 +\n>> drivers/usb/host/platform-roothub.c | 180\n>> ++++++++++++++++++++++++++++++++++++\n>> drivers/usb/host/platform-roothub.h | 12 +++\n>> 4 files changed, 197 insertions(+)\n>> create mode 100644 drivers/usb/host/platform-roothub.c\n>> create mode 100644 drivers/usb/host/platform-roothub.h\n>>\n>\n> Instead of creating platform-roothub files could this content\n> be added into into core/hcd.*, core/phy.* and host/xhci-plat.c\nOK, I will try this and send a patch so we can have a look at the\npotential result and start a discussion based on that (if required)\n\n>\n>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig\n>> index fa5692dec832..b8b05c786b2a 100644\n>> --- a/drivers/usb/host/Kconfig\n>> +++ b/drivers/usb/host/Kconfig\n>> @@ -805,6 +805,9 @@ config USB_HCD_SSB\n>>\n>> If unsure, say N.\n>>\n>> +config USB_PLATFORM_ROOTHUB\n>> + bool\n>> +\n>> config USB_HCD_TEST_MODE\n>> bool \"HCD test mode support\"\n>> ---help---\n>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile\n>> index cf2691fffcc0..dc817f82d632 100644\n>> --- a/drivers/usb/host/Makefile\n>> +++ b/drivers/usb/host/Makefile\n>> @@ -29,6 +29,8 @@ obj-$(CONFIG_USB_WHCI_HCD) += whci/\n>>\n>> obj-$(CONFIG_USB_PCI) += pci-quirks.o\n>>\n>> +obj-$(CONFIG_USB_PLATFORM_ROOTHUB) += platform-roothub.o\n>> +\n>> obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o\n>> obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o\n>> obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o\n>> diff --git a/drivers/usb/host/platform-roothub.c\n>> b/drivers/usb/host/platform-roothub.c\n>> new file mode 100644\n>> index 000000000000..70d2d97aa8b2\n>> --- /dev/null\n>> +++ b/drivers/usb/host/platform-roothub.c\n>> @@ -0,0 +1,180 @@\n>> +/*\n>> + * platform roothub driver - a virtual PHY device which passes all phy_*\n>> + * function calls to multiple (actual) PHY devices. This is comes handy\n>> when\n>> + * initializing all PHYs on a root-hub (to keep them all in the same\n>> state).\n>> + *\n>> + * Copyright (C) 2017 Martin Blumenstingl\n>> \n>> + *\n>> + * This program is free software; you can redistribute it and/or modify\n>> + * it under the terms of the GNU General Public License version 2 as\n>> + * published by the Free Software Foundation.\n>> + *\n>> + * You should have received a copy of the GNU General Public License\n>> + * along with this program. If not, see .\n>> + */\n>> +\n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +#include \n>> +\n>> +#include \"platform-roothub.h\"\n>> +\n>> +#define ROOTHUB_PORTNUM 0\n>> +\n>> +struct platform_roothub {\n>> + struct phy *phy;\n>> + struct list_head list;\n>> +};\n>> +\n>> +static struct platform_roothub *platform_roothub_alloc(struct device\n>> *dev)\n>> +{\n>> + struct platform_roothub *roothub_entry;\n>> +\n>> + roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry),\n>> GFP_KERNEL);\n>> + if (!roothub_entry)\n>> + return ERR_PTR(-ENOMEM);\n>> +\n>> + INIT_LIST_HEAD(&roothub_entry->list);\n>> +\n>> + return roothub_entry;\n>> +}\n>> +\n>> +static int platform_roothub_add_phy(struct device *dev,\n>> + struct device_node *port_np,\n>> + const char *con_id, struct list_head\n>> *list)\n>> +{\n>> + struct platform_roothub *roothub_entry;\n>> + struct phy *phy = devm_of_phy_get(dev, port_np, con_id);\n>> +\n>> + if (IS_ERR_OR_NULL(phy)) {\n>> + if (!phy || PTR_ERR(phy) == -ENODEV)\n>> + return 0;\n>> + else\n>> + return PTR_ERR(phy);\n>> + }\n>> +\n>> + roothub_entry = platform_roothub_alloc(dev);\n>> + if (IS_ERR(roothub_entry))\n>> + return PTR_ERR(roothub_entry);\n>> +\n>> + roothub_entry->phy = phy;\n>> +\n>> + list_add_tail(&roothub_entry->list, list);\n>> +\n>> + return 0;\n>> +}\n>> +\n>> +struct platform_roothub *platform_roothub_init(struct device *dev)\n>> +{\n>> + struct device_node *roothub_np, *port_np;\n>> + struct platform_roothub *plat_roothub;\n>> + struct platform_roothub *roothub_entry;\n>> + struct list_head *head;\n>> + int err;\n>> +\n>> + roothub_np = usb_of_get_child_node(dev->of_node, ROOTHUB_PORTNUM);\n>> + if (!of_device_is_available(roothub_np))\n>> + return NULL;\n>> +\n>> + plat_roothub = platform_roothub_alloc(dev);\n>> + if (IS_ERR(plat_roothub))\n>> + return plat_roothub;\n>> +\n>> + for_each_available_child_of_node(roothub_np, port_np) {\n>> + err = platform_roothub_add_phy(dev, port_np, \"usb2-phy\",\n>> + &plat_roothub->list);\n>> + if (err)\n>> + goto err_out;\n>> +\n>> + err = platform_roothub_add_phy(dev, port_np, \"usb3-phy\",\n>> + &plat_roothub->list);\n>\n>\n> So if the first 10 ports have the same phy, and 11th and 12th have an other\n> one, won't we end up\n> with a phy list with 12 entries for 2 phys, and initialize and turn on the\n> same first phy 10 times?\nindeed, we would call phy_init() and phy_power_on() multiple times on\nthe same PHY.\nhowever, this is not an issue since the PHY framework is doing\nref-counting for us (see [0] and [1] - the PHY driver's .init() and\n.power_on() callbacks will only be called once for each PHY in your\nscenario)\ndo you see any other issues with this?\n\n> I'm also not sure I understand the reason for having the \"usb3-phy\" and\n> \"usb2-phy\" phy-names\n> for the ports if we anyways just add everything to one list.\nthe PHY devicetree bindings state that the \"phy-names\" property is\nmandatory: [2]\n\nwhen moving the whole multiple PHY logic to usb_add_hcd() then it even\nmakes sense to look for specific PHYs (imho):\n- let's assume we have a XHCI controller with two ports\n- both ports have a USB2 PHY, but only one has a USB3 PHY\n- (this basically describes the situation on the Amlogic Meson GXL\nSoCs, Mediatek uses similar designs)\n\nthis would result in the following flow:\n1. usb_add_hcd is called for the high-speed HCD\n2. we would parse the PHYs for the high-speed HCD\n3. usb_add_hcd is called for the super-speed HCD\n4. we would parse the PHYs for the super-speed HCD\ndepending on how we parse the PHYs (mapping the controller-type to\nphy-name \"usb2-phy\" or \"usb3-phy\") we either end up with:\n- 3 PHY handles (2x USB2, 1x USB3) if we take the\ncontroller-type/phy-name into account\n- 6 PHY handles (doubling the amount from the use-case above) if we don't\n\nplease let me know if there is an easier solution - I prefer simple\ncode myself, so I don't want to add complexity where it's not needed.\n\n\nRegards,\nMartin\n\n\n[0] http://elixir.free-electrons.com/linux/v4.14-rc3/source/drivers/phy/phy-core.c#L231\n[1] http://elixir.free-electrons.com/linux/v4.14-rc3/source/drivers/phy/phy-core.c#L296\n[2] http://elixir.free-electrons.com/linux/v4.14-rc3/source/Documentation/devicetree/bindings/phy/phy-bindings.txt#L36\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\" (2048-bit key;\n\tunprotected) header.d=googlemail.com header.i=@googlemail.com\n\theader.b=\"ocHsZwLF\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y8Xz851L2z9t4Z\n\tfor ;\n\tSun, 8 Oct 2017 04:08:52 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751373AbdJGRIu (ORCPT\n\t);\n\tSat, 7 Oct 2017 13:08:50 -0400","from mail-io0-f194.google.com ([209.85.223.194]:37653 \"EHLO\n\tmail-io0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751279AbdJGRIs (ORCPT\n\t); Sat, 7 Oct 2017 13:08:48 -0400","by mail-io0-f194.google.com with SMTP id m201so7177372iom.4;\n\tSat, 07 Oct 2017 10:08:48 -0700 (PDT)","by 10.2.151.220 with HTTP; Sat, 7 Oct 2017 10:08:27 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlemail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=+8DGhmXSXmXP+SbHDiCjpTboUUt/bQqi7VcCmntcHFY=;\n\tb=ocHsZwLFCbSPtt6hkRfgCYAU4kOhljTzNhL30uqRWoTnC//FlYAZYYjXPkwcS2DYkL\n\tdZ7QSODAwGWhCp4c/L3EKoaiPI+dgDT0TlYLNdQRke+n2cs05VflnQTV9euY7PTC4rjn\n\t0Ub0KkSVRVgGMJ6sQXxRu8x32xKs1Pah6eI2CV376KJ4Wg1XLe8nXDYKOs0KS/SckS/g\n\tAXfDC/+wqQK3F9CdYLNT4Rv5B+01I0KpFHO9JHAchrZJKDaCrPONc53dHrQ4xLasw5P9\n\tq3qOvqxa7QmHhLuVfHgeePaePGZel61lZKT04cIp/EXS9hXUpG1ecKTUcT5EsB1K+1P1\n\t9fsA==","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=+8DGhmXSXmXP+SbHDiCjpTboUUt/bQqi7VcCmntcHFY=;\n\tb=C3RXEvshONyA24XJs3NeEN8CkDNwKDKXZHqn7dxghyOJNvDlJQmXRYNJp6GlyN9MJR\n\t5rvdruXX5BX3F/IThmaaptZ7E9jVTWfGoZuFoDdJmwoTHOeUw3p/VmCHG630gJXtQ7+A\n\tjAIK/nm4z9rDke0FpoeSpf/itoCh0wnV5qSfqmO45CnlJmVvnqF6t4P1o1dvSLmdtfLg\n\t3iKBhKO62H60KaQupRj7p/d7fDd/79AuXRRA+HuM0XKprAx/wNXv4ZoJcq/EUPgBdz0q\n\t8A9wbrNNpUg7LcN2/K7AxZXYbun1ubb7nHAMxpGSRsX541NwFO3mSz3FnDN0vh9QItCs\n\tp88A==","X-Gm-Message-State":"AMCzsaVlo7BGSWwVM2eyYgOb3VIhVX1/QZbMt8lNQsrI9q1QawXNZGJ7\n\tJiPbBSt1GXD1hGbXW2kPAPzioSuNzDfV5yJGb7M=","X-Google-Smtp-Source":"AOwi7QAvYDtEDlFAbk3x1/0tmJKLXdSeor0KaDk4fRwxZotk0ywaCsoIf5Kf+dkeabDoeihTRK3YPcRBBZxlpp3itXE=","X-Received":"by 10.107.181.10 with SMTP id e10mr6487333iof.245.1507396127667; \n\tSat, 07 Oct 2017 10:08:47 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<59D4DC7E.6040003@linux.intel.com>","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t<20170903213829.6589-3-martin.blumenstingl@googlemail.com>\n\t<59D4DC7E.6040003@linux.intel.com>","From":"Martin Blumenstingl ","Date":"Sat, 7 Oct 2017 19:08:27 +0200","Message-ID":"","Subject":"Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub\n\tdriver","To":"Mathias Nyman ","Cc":"linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,\n\tfelipe.balbi@linux.intel.com, mathias.nyman@intel.com,\n\trobh+dt@kernel.org, devicetree@vger.kernel.org,\n\tmark.rutland@arm.com, arnd@arndb.de,\n\tlinux-amlogic@lists.infradead.org, chunfeng.yun@mediatek.com","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":1782841,"web_url":"http://patchwork.ozlabs.org/comment/1782841/","msgid":"<59DB7CEC.50006@linux.intel.com>","list_archive_url":null,"date":"2017-10-09T13:43:08","subject":"Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub\n\tdriver","submitter":{"id":63937,"url":"http://patchwork.ozlabs.org/api/people/63937/","name":"Mathias Nyman","email":"mathias.nyman@linux.intel.com"},"content":"On 07.10.2017 20:08, Martin Blumenstingl wrote:\n> Hi Mathias,\n>\n> thank you for taking the time to go through my patch\n>\n> On Wed, Oct 4, 2017 at 3:05 PM, Mathias Nyman\n> wrote:\n>> On 04.09.2017 00:38, Martin Blumenstingl wrote:\n>>>\n>>> Many SoC platforms have separate devices for the USB PHY which are\n>>> registered through the generic PHY framework. These PHYs have to be\n>>> enabled to make the USB controller actually work. They also have to be\n>>> disabled again on shutdown/suspend.\n>>>\n>>> Currently (at least) the following HCI platform drivers are using custom\n>>> code to obtain all PHYs via devicetree for the roothub/controller and\n>>> disable/enable them when required:\n>>> - ehci-platform.c has ehci_platform_power_{on,off}\n>>> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}\n>>> - ohci-platform.c has ohci_platform_power_{on,off}\n>>>\n>>> These drivers are not using the generic devicetree USB device bindings\n>>> yet which were only introduced recently (documentation is available in\n>>> devicetree/bindings/usb/usb-device.txt).\n>>> With this new driver the usb2-phy and usb3-phy can be specified directly\n>>> in the child-node of the corresponding port of the roothub via\n>>> devicetree. This can be extended by not just parsing PHYs (some of the\n>>> other drivers listed above are for example also parsing a list of clocks\n>>> as well) when required.\n>>\n>>\n>> usb_add_hcd() in usb/core/hcd.c is already finding, initializing and turning\n>> on a phy, would it make sense to expand that one to support several phys\n>> instead?\n>>\n>> xhci will add two hcd's one for USB2 and one for USB3\n> that is a great suggestion - thank you for bringing this up!\n> as a benefit we would add multiple PHY support for all the other\n> use-cases I found (at least: ehci-platform.c, xhci-mtk.c,\n> ohci-platform.c) - instead of just handling this in xhci-plat.c\n>\n> I have one quick question regarding usb/core/hcd.c:\n> are hcd_bus_suspend() and hcd_bus_resume() the right places to\n> power_{off,on} the PHYs during suspend?\n> (currently usb/core/hcd.c doesn't touch the PHY during suspend/resume\n> - xhci-mtk.c on the other hand seems to require it during a\n> suspend/resume cycle)\n\nI'm not sure what would be the correct place, hcd_bus_suspend() will be called\ntwice for xhci, oce for each hcd, so then we need to make sure we only turn off\nphys related to that hcd. Host controller can still be running when bus is suspended.\n\nxhci-mtk turns off phy when host controller is suspended and stopped.\n\n>>\n>>\n>> So if the first 10 ports have the same phy, and 11th and 12th have an other\n>> one, won't we end up\n>> with a phy list with 12 entries for 2 phys, and initialize and turn on the\n>> same first phy 10 times?\n> indeed, we would call phy_init() and phy_power_on() multiple times on\n> the same PHY.\n> however, this is not an issue since the PHY framework is doing\n> ref-counting for us (see [0] and [1] - the PHY driver's .init() and\n> .power_on() callbacks will only be called once for each PHY in your\n> scenario)\n\nOk\n\n> do you see any other issues with this?\n>\n\nNot really, fine by me.\n\n>> I'm also not sure I understand the reason for having the \"usb3-phy\" and\n>> \"usb2-phy\" phy-names\n>> for the ports if we anyways just add everything to one list.\n> the PHY devicetree bindings state that the \"phy-names\" property is\n> mandatory: [2]\n>\n> when moving the whole multiple PHY logic to usb_add_hcd() then it even\n> makes sense to look for specific PHYs (imho):\n> - let's assume we have a XHCI controller with two ports\n> - both ports have a USB2 PHY, but only one has a USB3 PHY\n> - (this basically describes the situation on the Amlogic Meson GXL\n> SoCs, Mediatek uses similar designs)\n>\n> this would result in the following flow:\n> 1. usb_add_hcd is called for the high-speed HCD\n> 2. we would parse the PHYs for the high-speed HCD\n> 3. usb_add_hcd is called for the super-speed HCD\n> 4. we would parse the PHYs for the super-speed HCD\n> depending on how we parse the PHYs (mapping the controller-type to\n> phy-name \"usb2-phy\" or \"usb3-phy\") we either end up with:\n> - 3 PHY handles (2x USB2, 1x USB3) if we take the\n> controller-type/phy-name into account\n> - 6 PHY handles (doubling the amount from the use-case above) if we don't\n>\n> please let me know if there is an easier solution - I prefer simple\n> code myself, so I don't want to add complexity where it's not needed.\n\nAh, ok, I'm used to the ACPI tables way of listing ports where a physical USB3 connector\n(HS & SS) is actually described as two separate ports. one HS and one SS.\nWith this layout one port can have only one PHY.\n\nThe Amlogic Meson GXL with two physical USB connectors (USB2&3 and USB2 only)\nwould look something like this in ACPI:\n\nDevice (RHUB) {\n\t...\n\tDevice (HS01) {...}\n\tDevice (HS02) {...}\n\tDevice (SS01) {...}\n\nxhci register layout is similar.\nEach port has its own port status/control register.\nDepending on if a USB2 or USB3 device is connected to a physical connector it will trigger\ndifferent port status registers.\n\nNot sure which way is better.\n\n-Mathias\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 3y9hDW2RKgz9s7h\n\tfor ;\n\tTue, 10 Oct 2017 00:39:23 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754563AbdJINjV (ORCPT\n\t);\n\tMon, 9 Oct 2017 09:39:21 -0400","from mga01.intel.com ([192.55.52.88]:20862 \"EHLO mga01.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754405AbdJINjS (ORCPT );\n\tMon, 9 Oct 2017 09:39:18 -0400","from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t09 Oct 2017 06:39:17 -0700","from mattu-haswell.fi.intel.com (HELO [10.237.72.164])\n\t([10.237.72.164])\n\tby fmsmga001.fm.intel.com with ESMTP; 09 Oct 2017 06:39:14 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.42,500,1500966000\"; d=\"scan'208\";\n\ta=\"1203841556\"","Subject":"Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub\n\tdriver","To":"Martin Blumenstingl ","References":"<20170903213829.6589-1-martin.blumenstingl@googlemail.com>\n\t<20170903213829.6589-3-martin.blumenstingl@googlemail.com>\n\t<59D4DC7E.6040003@linux.intel.com>\n\t","Cc":"linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,\n\tfelipe.balbi@linux.intel.com, mathias.nyman@intel.com,\n\trobh+dt@kernel.org, devicetree@vger.kernel.org,\n\tmark.rutland@arm.com, arnd@arndb.de,\n\tlinux-amlogic@lists.infradead.org, chunfeng.yun@mediatek.com","From":"Mathias Nyman ","Message-ID":"<59DB7CEC.50006@linux.intel.com>","Date":"Mon, 9 Oct 2017 16:43:08 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101\n\tThunderbird/38.8.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]