From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties Date: Tue, 23 Aug 2016 18:06:26 -0500 Message-ID: References: <20160707222114.1673-1-stephen.boyd@linaro.org> <20160707222114.1673-4-stephen.boyd@linaro.org> <20160718022355.GA8568@rob-hp-laptop> <147043320014.26915.7483025835695600714@sboyd-linaro> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Stephen Boyd Cc: Linux USB List , linux-arm-kernel , Linux Kernel Mailing List , linux-arm-msm , Andy Gross , Bjorn Andersson , Neil Armstrong , Arnd Bergmann , Felipe Balbi , Greg Kroah-Hartman , Heikki Krogerus , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-arm-msm@vger.kernel.org On Tue, Aug 23, 2016 at 3:00 PM, Stephen Boyd wrote: > On Fri, Aug 5, 2016 at 2:40 PM, Stephen Boyd wrote: >> Quoting Rob Herring (2016-07-17 19:23:55) >>> On Thu, Jul 07, 2016 at 03:20:54PM -0700, Stephen Boyd wrote: >>> > +------- >>> > + >>> > +usb { >>> > + compatible = "vendor,usb-controller"; >>> > + >>> > + ulpi { >>> > + phy { >>> > + compatible = "vendor,phy"; >>> > + ulpi-vendor = /bits/ 16 <0x1d6b>; >>> > + ulpi-product = /bits/ 16 <0x0002>; >>> > + }; >>> > + }; >>> >>> I'm still having concerns about describing both phys and devices. If I >>> have a controller with 2 ports and 2 devices attached, I'd have >>> something like this under the USB controller: >>> >>> ulpi { >>> phy@1 { >>> }; >>> phy@2 { >>> }; >>> }; >> >> My understanding is there would only be one status="ok" node on the ULPI >> bus for the single phy that a usb controller would have. At the least, >> the kernel's ULPI layer only seems to support one ULPI phy for a >> controller right now. So even if there are two ports, it doesn't mean >> there are two phys. >> >>> >>> dev@1 { >>> ... >>> }; >>> >>> dev@2 { >>> ... >>> }; >>> >>> >>> That doesn't seem the best, but I don't have a better suggestion. Maybe >>> the device nodes need to go under the phy nodes? >>> >> >> What if we moved the dev@1 and dev@2 to another sub node like "ports" or >> "usb-devices"? Legacy code can support having those devices directly >> underneath the usb controller, but future users would always need to put >> them in a different sub-node so that we can easily differentiate the >> different busses that a usb controller node may support? >> >> I'm not sure I see any need to relate the phy to the ports that are on >> the controller, but if that is needed then perhaps you're right and we >> should move the ports underneath the phy. USB core could be modified to >> go through the legacy path or through the phy, if it even exists, to >> find ports. >> >> Do we typically do this for other phy designs like sata or pci? The phy >> always seemed like a parallel thing to the logical bus that the phy is >> used for. > > Rob does this sound ok to you? Well, if there's only ever 1 phy under the controller, then as you had it is fine. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754139AbcHWXGx (ORCPT ); Tue, 23 Aug 2016 19:06:53 -0400 Received: from mail.kernel.org ([198.145.29.136]:44864 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752090AbcHWXGv (ORCPT ); Tue, 23 Aug 2016 19:06:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160707222114.1673-1-stephen.boyd@linaro.org> <20160707222114.1673-4-stephen.boyd@linaro.org> <20160718022355.GA8568@rob-hp-laptop> <147043320014.26915.7483025835695600714@sboyd-linaro> From: Rob Herring Date: Tue, 23 Aug 2016 18:06:26 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties To: Stephen Boyd Cc: Linux USB List , linux-arm-kernel , Linux Kernel Mailing List , linux-arm-msm , Andy Gross , Bjorn Andersson , Neil Armstrong , Arnd Bergmann , Felipe Balbi , Greg Kroah-Hartman , Heikki Krogerus , "devicetree@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 23, 2016 at 3:00 PM, Stephen Boyd wrote: > On Fri, Aug 5, 2016 at 2:40 PM, Stephen Boyd wrote: >> Quoting Rob Herring (2016-07-17 19:23:55) >>> On Thu, Jul 07, 2016 at 03:20:54PM -0700, Stephen Boyd wrote: >>> > +------- >>> > + >>> > +usb { >>> > + compatible = "vendor,usb-controller"; >>> > + >>> > + ulpi { >>> > + phy { >>> > + compatible = "vendor,phy"; >>> > + ulpi-vendor = /bits/ 16 <0x1d6b>; >>> > + ulpi-product = /bits/ 16 <0x0002>; >>> > + }; >>> > + }; >>> >>> I'm still having concerns about describing both phys and devices. If I >>> have a controller with 2 ports and 2 devices attached, I'd have >>> something like this under the USB controller: >>> >>> ulpi { >>> phy@1 { >>> }; >>> phy@2 { >>> }; >>> }; >> >> My understanding is there would only be one status="ok" node on the ULPI >> bus for the single phy that a usb controller would have. At the least, >> the kernel's ULPI layer only seems to support one ULPI phy for a >> controller right now. So even if there are two ports, it doesn't mean >> there are two phys. >> >>> >>> dev@1 { >>> ... >>> }; >>> >>> dev@2 { >>> ... >>> }; >>> >>> >>> That doesn't seem the best, but I don't have a better suggestion. Maybe >>> the device nodes need to go under the phy nodes? >>> >> >> What if we moved the dev@1 and dev@2 to another sub node like "ports" or >> "usb-devices"? Legacy code can support having those devices directly >> underneath the usb controller, but future users would always need to put >> them in a different sub-node so that we can easily differentiate the >> different busses that a usb controller node may support? >> >> I'm not sure I see any need to relate the phy to the ports that are on >> the controller, but if that is needed then perhaps you're right and we >> should move the ports underneath the phy. USB core could be modified to >> go through the legacy path or through the phy, if it even exists, to >> find ports. >> >> Do we typically do this for other phy designs like sata or pci? The phy >> always seemed like a parallel thing to the logical bus that the phy is >> used for. > > Rob does this sound ok to you? Well, if there's only ever 1 phy under the controller, then as you had it is fine. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: robh@kernel.org (Rob Herring) Date: Tue, 23 Aug 2016 18:06:26 -0500 Subject: [PATCH v2 03/22] usb: ulpi: Support device discovery via device properties In-Reply-To: References: <20160707222114.1673-1-stephen.boyd@linaro.org> <20160707222114.1673-4-stephen.boyd@linaro.org> <20160718022355.GA8568@rob-hp-laptop> <147043320014.26915.7483025835695600714@sboyd-linaro> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Aug 23, 2016 at 3:00 PM, Stephen Boyd wrote: > On Fri, Aug 5, 2016 at 2:40 PM, Stephen Boyd wrote: >> Quoting Rob Herring (2016-07-17 19:23:55) >>> On Thu, Jul 07, 2016 at 03:20:54PM -0700, Stephen Boyd wrote: >>> > +------- >>> > + >>> > +usb { >>> > + compatible = "vendor,usb-controller"; >>> > + >>> > + ulpi { >>> > + phy { >>> > + compatible = "vendor,phy"; >>> > + ulpi-vendor = /bits/ 16 <0x1d6b>; >>> > + ulpi-product = /bits/ 16 <0x0002>; >>> > + }; >>> > + }; >>> >>> I'm still having concerns about describing both phys and devices. If I >>> have a controller with 2 ports and 2 devices attached, I'd have >>> something like this under the USB controller: >>> >>> ulpi { >>> phy at 1 { >>> }; >>> phy at 2 { >>> }; >>> }; >> >> My understanding is there would only be one status="ok" node on the ULPI >> bus for the single phy that a usb controller would have. At the least, >> the kernel's ULPI layer only seems to support one ULPI phy for a >> controller right now. So even if there are two ports, it doesn't mean >> there are two phys. >> >>> >>> dev at 1 { >>> ... >>> }; >>> >>> dev at 2 { >>> ... >>> }; >>> >>> >>> That doesn't seem the best, but I don't have a better suggestion. Maybe >>> the device nodes need to go under the phy nodes? >>> >> >> What if we moved the dev at 1 and dev at 2 to another sub node like "ports" or >> "usb-devices"? Legacy code can support having those devices directly >> underneath the usb controller, but future users would always need to put >> them in a different sub-node so that we can easily differentiate the >> different busses that a usb controller node may support? >> >> I'm not sure I see any need to relate the phy to the ports that are on >> the controller, but if that is needed then perhaps you're right and we >> should move the ports underneath the phy. USB core could be modified to >> go through the legacy path or through the phy, if it even exists, to >> find ports. >> >> Do we typically do this for other phy designs like sata or pci? The phy >> always seemed like a parallel thing to the logical bus that the phy is >> used for. > > Rob does this sound ok to you? Well, if there's only ever 1 phy under the controller, then as you had it is fine. Rob