* [PATCH] usb: dwc3: core: clarify usb-phy array binding @ 2013-08-09 15:40 Kumar Gala 2013-08-09 16:28 ` Mark Rutland 0 siblings, 1 reply; 13+ messages in thread From: Kumar Gala @ 2013-08-09 15:40 UTC (permalink / raw) To: balbi, Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell, Kumar Gala Cc: devicetree, linux-usb, linux-kernel The binding spec wasn't clear that the order of the phandles in the usb-phy array has meaning. Clarify this point in the binding that it should be <USB2-HS-PHY, USB3-SS-PHY>. Signed-off-by: Kumar Gala <galak@codeaurora.org> --- Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 7a95c65..8a9770b 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,7 +6,9 @@ Required properties: - compatible: must be "synopsys,dwc3" - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. - - usb-phy : array of phandle for the PHY device + - usb-phy : array of phandle for the PHY device. The first element + in the array is expected to be a handle to the USB2/HS PHY and + the second element is expected to be a handle to the USB3/SS PHY Optional properties: - tx-fifo-resize: determines if the FIFO *has* to be reallocated. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-08-09 15:40 [PATCH] usb: dwc3: core: clarify usb-phy array binding Kumar Gala @ 2013-08-09 16:28 ` Mark Rutland 2013-08-09 18:42 ` Kumar Gala 0 siblings, 1 reply; 13+ messages in thread From: Mark Rutland @ 2013-08-09 16:28 UTC (permalink / raw) To: Kumar Gala Cc: balbi, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: > The binding spec wasn't clear that the order of the phandles in the > usb-phy array has meaning. Clarify this point in the binding that > it should be <USB2-HS-PHY, USB3-SS-PHY>. > > Signed-off-by: Kumar Gala <galak@codeaurora.org> > --- > Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt > index 7a95c65..8a9770b 100644 > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > @@ -6,7 +6,9 @@ Required properties: > - compatible: must be "synopsys,dwc3" > - reg : Address and length of the register set for the device > - interrupts: Interrupts used by the dwc3 controller. > - - usb-phy : array of phandle for the PHY device > + - usb-phy : array of phandle for the PHY device. The first element > + in the array is expected to be a handle to the USB2/HS PHY and > + the second element is expected to be a handle to the USB3/SS PHY Just to check - it's not valid to have a USB3 phy without a USB2 phy? Mark. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-08-09 16:28 ` Mark Rutland @ 2013-08-09 18:42 ` Kumar Gala 2013-08-12 18:05 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Kumar Gala @ 2013-08-09 18:42 UTC (permalink / raw) To: Mark Rutland Cc: balbi, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: > On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: >> The binding spec wasn't clear that the order of the phandles in the >> usb-phy array has meaning. Clarify this point in the binding that >> it should be <USB2-HS-PHY, USB3-SS-PHY>. >> >> Signed-off-by: Kumar Gala <galak@codeaurora.org> >> --- >> Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt >> index 7a95c65..8a9770b 100644 >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt >> @@ -6,7 +6,9 @@ Required properties: >> - compatible: must be "synopsys,dwc3" >> - reg : Address and length of the register set for the device >> - interrupts: Interrupts used by the dwc3 controller. >> - - usb-phy : array of phandle for the PHY device >> + - usb-phy : array of phandle for the PHY device. The first element >> + in the array is expected to be a handle to the USB2/HS PHY and >> + the second element is expected to be a handle to the USB3/SS PHY > > Just to check - it's not valid to have a USB3 phy without a USB2 phy? Don't know, hopefully Felipe will chime in on that. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-08-09 18:42 ` Kumar Gala @ 2013-08-12 18:05 ` Felipe Balbi 2013-08-13 13:34 ` Mark Rutland 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2013-08-12 18:05 UTC (permalink / raw) To: Kumar Gala Cc: Mark Rutland, balbi, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1606 bytes --] On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: > > On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: > > > On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: > >> The binding spec wasn't clear that the order of the phandles in the > >> usb-phy array has meaning. Clarify this point in the binding that > >> it should be <USB2-HS-PHY, USB3-SS-PHY>. > >> > >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > >> --- > >> Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt > >> index 7a95c65..8a9770b 100644 > >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt > >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > >> @@ -6,7 +6,9 @@ Required properties: > >> - compatible: must be "synopsys,dwc3" > >> - reg : Address and length of the register set for the device > >> - interrupts: Interrupts used by the dwc3 controller. > >> - - usb-phy : array of phandle for the PHY device > >> + - usb-phy : array of phandle for the PHY device. The first element > >> + in the array is expected to be a handle to the USB2/HS PHY and > >> + the second element is expected to be a handle to the USB3/SS PHY > > > > Just to check - it's not valid to have a USB3 phy without a USB2 phy? > > Don't know, hopefully Felipe will chime in on that. that'd be a really non-standard implementation. Per-spec, USB3 is *always* backwards compatible with USB2. -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-08-12 18:05 ` Felipe Balbi @ 2013-08-13 13:34 ` Mark Rutland 2013-08-27 18:53 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Mark Rutland @ 2013-08-13 13:34 UTC (permalink / raw) To: Felipe Balbi Cc: Kumar Gala, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel On Mon, Aug 12, 2013 at 07:05:53PM +0100, Felipe Balbi wrote: > On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: > > > > On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: > > > > > On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: > > >> The binding spec wasn't clear that the order of the phandles in the > > >> usb-phy array has meaning. Clarify this point in the binding that > > >> it should be <USB2-HS-PHY, USB3-SS-PHY>. > > >> > > >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > > >> --- > > >> Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- > > >> 1 file changed, 3 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt > > >> index 7a95c65..8a9770b 100644 > > >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt > > >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > > >> @@ -6,7 +6,9 @@ Required properties: > > >> - compatible: must be "synopsys,dwc3" > > >> - reg : Address and length of the register set for the device > > >> - interrupts: Interrupts used by the dwc3 controller. > > >> - - usb-phy : array of phandle for the PHY device > > >> + - usb-phy : array of phandle for the PHY device. The first element > > >> + in the array is expected to be a handle to the USB2/HS PHY and > > >> + the second element is expected to be a handle to the USB3/SS PHY > > > > > > Just to check - it's not valid to have a USB3 phy without a USB2 phy? > > > > Don't know, hopefully Felipe will chime in on that. > > that'd be a really non-standard implementation. Per-spec, USB3 is > *always* backwards compatible with USB2. I'm slightly confused here. From a quick look at the driver, it expects two separate phys to be present -- one handling only USB2, and one handling USB3 (with USB2 backwards compatibility). So it's not physically possible for someone to just wire up a single phy to the device, either USB2-only or USB3? You can describe the USB2-only case in the dt by only listing the first phy (though the driver won't support it as it expects both to be present), but it's impossible to describe that you've wired up a single phy that's USB3 capable. Thanks, Mark. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-08-13 13:34 ` Mark Rutland @ 2013-08-27 18:53 ` Felipe Balbi 2013-08-28 16:01 ` Mark Rutland 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2013-08-27 18:53 UTC (permalink / raw) To: Mark Rutland Cc: Felipe Balbi, Kumar Gala, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2920 bytes --] Hi, On Tue, Aug 13, 2013 at 02:34:10PM +0100, Mark Rutland wrote: > On Mon, Aug 12, 2013 at 07:05:53PM +0100, Felipe Balbi wrote: > > On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: > > > > > > On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: > > > > > > > On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: > > > >> The binding spec wasn't clear that the order of the phandles in the > > > >> usb-phy array has meaning. Clarify this point in the binding that > > > >> it should be <USB2-HS-PHY, USB3-SS-PHY>. > > > >> > > > >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > > > >> --- > > > >> Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- > > > >> 1 file changed, 3 insertions(+), 1 deletion(-) > > > >> > > > >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt > > > >> index 7a95c65..8a9770b 100644 > > > >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt > > > >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > > > >> @@ -6,7 +6,9 @@ Required properties: > > > >> - compatible: must be "synopsys,dwc3" > > > >> - reg : Address and length of the register set for the device > > > >> - interrupts: Interrupts used by the dwc3 controller. > > > >> - - usb-phy : array of phandle for the PHY device > > > >> + - usb-phy : array of phandle for the PHY device. The first element > > > >> + in the array is expected to be a handle to the USB2/HS PHY and > > > >> + the second element is expected to be a handle to the USB3/SS PHY > > > > > > > > Just to check - it's not valid to have a USB3 phy without a USB2 phy? > > > > > > Don't know, hopefully Felipe will chime in on that. > > > > that'd be a really non-standard implementation. Per-spec, USB3 is > > *always* backwards compatible with USB2. > > I'm slightly confused here. From a quick look at the driver, it expects > two separate phys to be present -- one handling only USB2, and one > handling USB3 (with USB2 backwards compatibility). > > So it's not physically possible for someone to just wire up a single phy > to the device, either USB2-only or USB3? of course it is :-) In fact, TI has done it. But it causes a whole bunch of other problems to support that sort of model. For one, in some systems, a clock generated by the USB3 PHY is backfed into the IP and if USB3 PHY isn't running, the dwc3 IP won't start. I even wrote a patch making USB3 PHY optional, but didn't push it exactly because it broke some other systems and I can't guarantee users won't mess up their DTS/pdata. > You can describe the USB2-only case in the dt by only listing the first > phy (though the driver won't support it as it expects both to be > present), but it's impossible to describe that you've wired up a single > phy that's USB3 capable. you might be right there... -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-08-27 18:53 ` Felipe Balbi @ 2013-08-28 16:01 ` Mark Rutland 2013-09-18 14:21 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Mark Rutland @ 2013-08-28 16:01 UTC (permalink / raw) To: Felipe Balbi Cc: Kumar Gala, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel On Tue, Aug 27, 2013 at 07:53:29PM +0100, Felipe Balbi wrote: > Hi, > > On Tue, Aug 13, 2013 at 02:34:10PM +0100, Mark Rutland wrote: > > On Mon, Aug 12, 2013 at 07:05:53PM +0100, Felipe Balbi wrote: > > > On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: > > > > > > > > On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: > > > > > > > > > On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: > > > > >> The binding spec wasn't clear that the order of the phandles in the > > > > >> usb-phy array has meaning. Clarify this point in the binding that > > > > >> it should be <USB2-HS-PHY, USB3-SS-PHY>. > > > > >> > > > > >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > > > > >> --- > > > > >> Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- > > > > >> 1 file changed, 3 insertions(+), 1 deletion(-) > > > > >> > > > > >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt > > > > >> index 7a95c65..8a9770b 100644 > > > > >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt > > > > >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > > > > >> @@ -6,7 +6,9 @@ Required properties: > > > > >> - compatible: must be "synopsys,dwc3" > > > > >> - reg : Address and length of the register set for the device > > > > >> - interrupts: Interrupts used by the dwc3 controller. > > > > >> - - usb-phy : array of phandle for the PHY device > > > > >> + - usb-phy : array of phandle for the PHY device. The first element > > > > >> + in the array is expected to be a handle to the USB2/HS PHY and > > > > >> + the second element is expected to be a handle to the USB3/SS PHY > > > > > > > > > > Just to check - it's not valid to have a USB3 phy without a USB2 phy? > > > > > > > > Don't know, hopefully Felipe will chime in on that. > > > > > > that'd be a really non-standard implementation. Per-spec, USB3 is > > > *always* backwards compatible with USB2. > > > > I'm slightly confused here. From a quick look at the driver, it expects > > two separate phys to be present -- one handling only USB2, and one > > handling USB3 (with USB2 backwards compatibility). > > > > So it's not physically possible for someone to just wire up a single phy > > to the device, either USB2-only or USB3? > > of course it is :-) In fact, TI has done it. But it causes a whole bunch > of other problems to support that sort of model. For one, in some > systems, a clock generated by the USB3 PHY is backfed into the IP and if > USB3 PHY isn't running, the dwc3 IP won't start. That sounds like a mess. But unless I've misunderstood, that doesn't sound like a general problem with having one phy, but rather an integration issue on a specific system? Presumably in that case as long as the phy was brought up before poking the rest of the IP, the unit would function correctly. > > I even wrote a patch making USB3 PHY optional, but didn't push it > exactly because it broke some other systems and I can't guarantee users > won't mess up their DTS/pdata. Does that mean that their dts or pdata are wrong at the moment, but they're spared because the driver bails out due to a missing phy? If their pdata's wrong, that should be fixable relatively easily, but if the dt is wrong then I'm not sure how we can support those systems sensibly. That sounds like an ideal candidate for a dt quirks mechanism... > > > You can describe the USB2-only case in the dt by only listing the first > > phy (though the driver won't support it as it expects both to be > > present), but it's impossible to describe that you've wired up a single > > phy that's USB3 capable. > > you might be right there... Would it be possible to have something like (an optional) usb-phy-names? If not present, we assume the current situation, if present then we use it to figure out which phys are present. Maybe I'm missing something that makes that impossible? Thanks, Mark. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding @ 2013-09-18 14:21 ` Felipe Balbi 0 siblings, 0 replies; 13+ messages in thread From: Felipe Balbi @ 2013-09-18 14:21 UTC (permalink / raw) To: Mark Rutland Cc: Felipe Balbi, Kumar Gala, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2909 bytes --] Hi, On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote: > > > So it's not physically possible for someone to just wire up a single phy > > > to the device, either USB2-only or USB3? > > > > of course it is :-) In fact, TI has done it. But it causes a whole bunch > > of other problems to support that sort of model. For one, in some > > systems, a clock generated by the USB3 PHY is backfed into the IP and if > > USB3 PHY isn't running, the dwc3 IP won't start. > > That sounds like a mess. But unless I've misunderstood, that doesn't well, it is :-) > sound like a general problem with having one phy, but rather an > integration issue on a specific system? Presumably in that case as long > as the phy was brought up before poking the rest of the IP, the unit > would function correctly. right, but what 'brings up' the PHY is usb_phy_init(). If we don't add usb3phy to DTS or skip usb3phy in case maximum-speed < superspeed, then we're screwed :-) > > I even wrote a patch making USB3 PHY optional, but didn't push it > > exactly because it broke some other systems and I can't guarantee users > > won't mess up their DTS/pdata. > > Does that mean that their dts or pdata are wrong at the moment, but > they're spared because the driver bails out due to a missing phy? If > their pdata's wrong, that should be fixable relatively easily, but if > the dt is wrong then I'm not sure how we can support those systems > sensibly. That sounds like an ideal candidate for a dt quirks > mechanism... hmm, the idea of the patch was: switch (maximum-speed) { case SUPER: grab_and_initialize_usb3_phy(); grab_and_initialize_usb2_phy(); break; case HIGH: case FULL: case LOW: grab_and_initialize_usb2_phy(); break; } now, imagine someone wants to run his dwc3 in highspeed mode, we wouldn't initialize USB3 PHY which could cause the whole IP to break. I tried poking around on device's registers to see if there was any way to detect that the IP needs somethin back from USB3 PHY, but couldn't find anything. Since we can't know how the IP was integrated, it's best to leave it alone and require NOP xceiv to be used. > > > You can describe the USB2-only case in the dt by only listing the first > > > phy (though the driver won't support it as it expects both to be > > > present), but it's impossible to describe that you've wired up a single > > > phy that's USB3 capable. > > > > you might be right there... > > Would it be possible to have something like (an optional) usb-phy-names? > If not present, we assume the current situation, if present then we use > it to figure out which phys are present. Maybe I'm missing something > that makes that impossible? you're missing the point regarding the IP possibly needing something back from the PHY (e.g. a clock which PHY generates). -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding @ 2013-09-18 14:21 ` Felipe Balbi 0 siblings, 0 replies; 13+ messages in thread From: Felipe Balbi @ 2013-09-18 14:21 UTC (permalink / raw) To: Mark Rutland Cc: Felipe Balbi, Kumar Gala, rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Pawel Moll, Stephen Warren, Ian Campbell, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 2909 bytes --] Hi, On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote: > > > So it's not physically possible for someone to just wire up a single phy > > > to the device, either USB2-only or USB3? > > > > of course it is :-) In fact, TI has done it. But it causes a whole bunch > > of other problems to support that sort of model. For one, in some > > systems, a clock generated by the USB3 PHY is backfed into the IP and if > > USB3 PHY isn't running, the dwc3 IP won't start. > > That sounds like a mess. But unless I've misunderstood, that doesn't well, it is :-) > sound like a general problem with having one phy, but rather an > integration issue on a specific system? Presumably in that case as long > as the phy was brought up before poking the rest of the IP, the unit > would function correctly. right, but what 'brings up' the PHY is usb_phy_init(). If we don't add usb3phy to DTS or skip usb3phy in case maximum-speed < superspeed, then we're screwed :-) > > I even wrote a patch making USB3 PHY optional, but didn't push it > > exactly because it broke some other systems and I can't guarantee users > > won't mess up their DTS/pdata. > > Does that mean that their dts or pdata are wrong at the moment, but > they're spared because the driver bails out due to a missing phy? If > their pdata's wrong, that should be fixable relatively easily, but if > the dt is wrong then I'm not sure how we can support those systems > sensibly. That sounds like an ideal candidate for a dt quirks > mechanism... hmm, the idea of the patch was: switch (maximum-speed) { case SUPER: grab_and_initialize_usb3_phy(); grab_and_initialize_usb2_phy(); break; case HIGH: case FULL: case LOW: grab_and_initialize_usb2_phy(); break; } now, imagine someone wants to run his dwc3 in highspeed mode, we wouldn't initialize USB3 PHY which could cause the whole IP to break. I tried poking around on device's registers to see if there was any way to detect that the IP needs somethin back from USB3 PHY, but couldn't find anything. Since we can't know how the IP was integrated, it's best to leave it alone and require NOP xceiv to be used. > > > You can describe the USB2-only case in the dt by only listing the first > > > phy (though the driver won't support it as it expects both to be > > > present), but it's impossible to describe that you've wired up a single > > > phy that's USB3 capable. > > > > you might be right there... > > Would it be possible to have something like (an optional) usb-phy-names? > If not present, we assume the current situation, if present then we use > it to figure out which phys are present. Maybe I'm missing something > that makes that impossible? you're missing the point regarding the IP possibly needing something back from the PHY (e.g. a clock which PHY generates). -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding 2013-09-18 14:21 ` Felipe Balbi @ 2013-09-18 16:46 ` Mark Rutland -1 siblings, 0 replies; 13+ messages in thread From: Mark Rutland @ 2013-09-18 16:46 UTC (permalink / raw) To: Felipe Balbi Cc: Kumar Gala, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel On Wed, Sep 18, 2013 at 03:21:18PM +0100, Felipe Balbi wrote: > Hi, > > On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote: > > > > So it's not physically possible for someone to just wire up a single phy > > > > to the device, either USB2-only or USB3? > > > > > > of course it is :-) In fact, TI has done it. But it causes a whole bunch > > > of other problems to support that sort of model. For one, in some > > > systems, a clock generated by the USB3 PHY is backfed into the IP and if > > > USB3 PHY isn't running, the dwc3 IP won't start. > > > > That sounds like a mess. But unless I've misunderstood, that doesn't > > well, it is :-) > > > sound like a general problem with having one phy, but rather an > > integration issue on a specific system? Presumably in that case as long > > as the phy was brought up before poking the rest of the IP, the unit > > would function correctly. > > right, but what 'brings up' the PHY is usb_phy_init(). If we don't add > usb3phy to DTS or skip usb3phy in case maximum-speed < superspeed, then > we're screwed :-) :( > > > > I even wrote a patch making USB3 PHY optional, but didn't push it > > > exactly because it broke some other systems and I can't guarantee users > > > won't mess up their DTS/pdata. > > > > Does that mean that their dts or pdata are wrong at the moment, but > > they're spared because the driver bails out due to a missing phy? If > > their pdata's wrong, that should be fixable relatively easily, but if > > the dt is wrong then I'm not sure how we can support those systems > > sensibly. That sounds like an ideal candidate for a dt quirks > > mechanism... > > hmm, the idea of the patch was: > > switch (maximum-speed) { > case SUPER: > grab_and_initialize_usb3_phy(); > grab_and_initialize_usb2_phy(); > break; > case HIGH: > case FULL: > case LOW: > grab_and_initialize_usb2_phy(); > break; > } > > now, imagine someone wants to run his dwc3 in highspeed mode, we > wouldn't initialize USB3 PHY which could cause the whole IP to break. When you say wants to run it in highspeed mode, you mean that they want this configured at run-time, or they deliberately omit a phy when describing the hardware in the DT? For the former I appreciate that it's a problem, but for the latter I'd argue that's their fault. As far as I can see we initialise both PHYs in the probe path and never uninitialise them, so the only problem would be if someone's trying to be too clever. As we never check the return value of usb_phy_init, they can still attempt to work around our best efforts... I appreciate that we should not break existing DTs. More on that below. > > I tried poking around on device's registers to see if there was any way > to detect that the IP needs somethin back from USB3 PHY, but couldn't > find anything. > > Since we can't know how the IP was integrated, it's best to leave it > alone and require NOP xceiv to be used. Agreed for the existing systems, but I still think we can work around this for new DTs... > > > > > You can describe the USB2-only case in the dt by only listing the first > > > > phy (though the driver won't support it as it expects both to be > > > > present), but it's impossible to describe that you've wired up a single > > > > phy that's USB3 capable. > > > > > > you might be right there... > > > > Would it be possible to have something like (an optional) usb-phy-names? > > If not present, we assume the current situation, if present then we use > > it to figure out which phys are present. Maybe I'm missing something > > that makes that impossible? > > you're missing the point regarding the IP possibly needing something > back from the PHY (e.g. a clock which PHY generates). I'm not sure why that detracts from the usb-phy-names idea -- if not present, we stick with the current behaviour and require both PHYs or fail early. No existing dts suddently explode, though none gain new functionality either. If someone's explicitly placed usb-phy-names, we know that they're up-to-date on the lastest binding, something like: - usb-phy: A list of phandles to PHYs. If usb-phy-names is not present, the USB2/HS PHY should be first, followed by the USB3/SS PHY. If usb-phy-names is present, it defines the order of PHYs. - usb-phy-names: The names of PHYs described in the usb-phy property. Valid values are "usb2" and "usb3". Should be used iff a subset of PHYs are connected. Compatibility note: The DWC3 IP can be integrated in such a way as to require outputs from particular PHYs for *any* level of operation. This cannot be detected by the OS, and on such systems all required PHYs must be described. Given that, if they list fewer PHYs than present and their system really requires a particular PHY, we can quite happily allow their system to explode in the knowledge it's their fault, not ours :) If they try to use their new DT on an old platform then the kernel will refuse to use the DWC3, which would currently be the case anyway. Thanks, Mark. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding @ 2013-09-18 16:46 ` Mark Rutland 0 siblings, 0 replies; 13+ messages in thread From: Mark Rutland @ 2013-09-18 16:46 UTC (permalink / raw) To: Felipe Balbi Cc: Kumar Gala, rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Pawel Moll, Stephen Warren, Ian Campbell, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On Wed, Sep 18, 2013 at 03:21:18PM +0100, Felipe Balbi wrote: > Hi, > > On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote: > > > > So it's not physically possible for someone to just wire up a single phy > > > > to the device, either USB2-only or USB3? > > > > > > of course it is :-) In fact, TI has done it. But it causes a whole bunch > > > of other problems to support that sort of model. For one, in some > > > systems, a clock generated by the USB3 PHY is backfed into the IP and if > > > USB3 PHY isn't running, the dwc3 IP won't start. > > > > That sounds like a mess. But unless I've misunderstood, that doesn't > > well, it is :-) > > > sound like a general problem with having one phy, but rather an > > integration issue on a specific system? Presumably in that case as long > > as the phy was brought up before poking the rest of the IP, the unit > > would function correctly. > > right, but what 'brings up' the PHY is usb_phy_init(). If we don't add > usb3phy to DTS or skip usb3phy in case maximum-speed < superspeed, then > we're screwed :-) :( > > > > I even wrote a patch making USB3 PHY optional, but didn't push it > > > exactly because it broke some other systems and I can't guarantee users > > > won't mess up their DTS/pdata. > > > > Does that mean that their dts or pdata are wrong at the moment, but > > they're spared because the driver bails out due to a missing phy? If > > their pdata's wrong, that should be fixable relatively easily, but if > > the dt is wrong then I'm not sure how we can support those systems > > sensibly. That sounds like an ideal candidate for a dt quirks > > mechanism... > > hmm, the idea of the patch was: > > switch (maximum-speed) { > case SUPER: > grab_and_initialize_usb3_phy(); > grab_and_initialize_usb2_phy(); > break; > case HIGH: > case FULL: > case LOW: > grab_and_initialize_usb2_phy(); > break; > } > > now, imagine someone wants to run his dwc3 in highspeed mode, we > wouldn't initialize USB3 PHY which could cause the whole IP to break. When you say wants to run it in highspeed mode, you mean that they want this configured at run-time, or they deliberately omit a phy when describing the hardware in the DT? For the former I appreciate that it's a problem, but for the latter I'd argue that's their fault. As far as I can see we initialise both PHYs in the probe path and never uninitialise them, so the only problem would be if someone's trying to be too clever. As we never check the return value of usb_phy_init, they can still attempt to work around our best efforts... I appreciate that we should not break existing DTs. More on that below. > > I tried poking around on device's registers to see if there was any way > to detect that the IP needs somethin back from USB3 PHY, but couldn't > find anything. > > Since we can't know how the IP was integrated, it's best to leave it > alone and require NOP xceiv to be used. Agreed for the existing systems, but I still think we can work around this for new DTs... > > > > > You can describe the USB2-only case in the dt by only listing the first > > > > phy (though the driver won't support it as it expects both to be > > > > present), but it's impossible to describe that you've wired up a single > > > > phy that's USB3 capable. > > > > > > you might be right there... > > > > Would it be possible to have something like (an optional) usb-phy-names? > > If not present, we assume the current situation, if present then we use > > it to figure out which phys are present. Maybe I'm missing something > > that makes that impossible? > > you're missing the point regarding the IP possibly needing something > back from the PHY (e.g. a clock which PHY generates). I'm not sure why that detracts from the usb-phy-names idea -- if not present, we stick with the current behaviour and require both PHYs or fail early. No existing dts suddently explode, though none gain new functionality either. If someone's explicitly placed usb-phy-names, we know that they're up-to-date on the lastest binding, something like: - usb-phy: A list of phandles to PHYs. If usb-phy-names is not present, the USB2/HS PHY should be first, followed by the USB3/SS PHY. If usb-phy-names is present, it defines the order of PHYs. - usb-phy-names: The names of PHYs described in the usb-phy property. Valid values are "usb2" and "usb3". Should be used iff a subset of PHYs are connected. Compatibility note: The DWC3 IP can be integrated in such a way as to require outputs from particular PHYs for *any* level of operation. This cannot be detected by the OS, and on such systems all required PHYs must be described. Given that, if they list fewer PHYs than present and their system really requires a particular PHY, we can quite happily allow their system to explode in the knowledge it's their fault, not ours :) If they try to use their new DT on an old platform then the kernel will refuse to use the DWC3, which would currently be the case anyway. Thanks, Mark. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding @ 2013-09-18 16:56 ` Felipe Balbi 0 siblings, 0 replies; 13+ messages in thread From: Felipe Balbi @ 2013-09-18 16:56 UTC (permalink / raw) To: Mark Rutland Cc: Felipe Balbi, Kumar Gala, rob.herring, Pawel Moll, Stephen Warren, Ian Campbell, devicetree, linux-usb, linux-kernel [-- Attachment #1: Type: text/plain, Size: 6566 bytes --] Hi, On Wed, Sep 18, 2013 at 05:46:10PM +0100, Mark Rutland wrote: > > > > I even wrote a patch making USB3 PHY optional, but didn't push it > > > > exactly because it broke some other systems and I can't guarantee users > > > > won't mess up their DTS/pdata. > > > > > > Does that mean that their dts or pdata are wrong at the moment, but > > > they're spared because the driver bails out due to a missing phy? If > > > their pdata's wrong, that should be fixable relatively easily, but if > > > the dt is wrong then I'm not sure how we can support those systems > > > sensibly. That sounds like an ideal candidate for a dt quirks > > > mechanism... > > > > hmm, the idea of the patch was: > > > > switch (maximum-speed) { > > case SUPER: > > grab_and_initialize_usb3_phy(); > > grab_and_initialize_usb2_phy(); > > break; > > case HIGH: > > case FULL: > > case LOW: > > grab_and_initialize_usb2_phy(); > > break; > > } > > > > now, imagine someone wants to run his dwc3 in highspeed mode, we > > wouldn't initialize USB3 PHY which could cause the whole IP to break. > > When you say wants to run it in highspeed mode, you mean that they want > this configured at run-time, or they deliberately omit a phy when > describing the hardware in the DT? it doesn't really matter, I guess. TI's DRA7xx platforms, for instance, don't even provide a USB3 PHY and now way to connect one (since PIPE3 interface isn't brought out of the chip). Granted the problem is bigger in superspeed capable integration where we want to run at highspeed for e.g. test purposes. > For the former I appreciate that it's a problem, but for the latter I'd > argue that's their fault. As far as I can see we initialise both PHYs in true, we can look at it that way. > the probe path and never uninitialise them, so the only problem would be > if someone's trying to be too clever. As we never check the return value > of usb_phy_init, they can still attempt to work around our best > efforts... > > I appreciate that we should not break existing DTs. More on that below. k > > I tried poking around on device's registers to see if there was any way > > to detect that the IP needs somethin back from USB3 PHY, but couldn't > > find anything. > > > > Since we can't know how the IP was integrated, it's best to leave it > > alone and require NOP xceiv to be used. > > Agreed for the existing systems, but I still think we can work around > this for new DTs... perhaps, but wouldn't that be a quirk ? If it's a quirk, perhaps we'd be better off adding a quirk flag to skip USB?PHY in some platforms. Then we could: diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 474162e..5d39e0e 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -387,16 +387,29 @@ static int dwc3_probe(struct platform_device *pdev) if (node) { dwc->maximum_speed = of_usb_get_maximum_speed(node); - dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0); - dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1); + if (of_device_is_compatible(node, "ti,dra7xxx-dwc3")) + dwc->quirks |= DWC3_SKIP_USB3PHY; + + if (!dwc->quirks & DWC3_SKIP_USB2_PHY) + dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, + "usb-phy", 0); + + if (!dwc->quirks & DWC3_SKIP_USB3_PHY) + dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, + "usb-phy", 1); dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize"); dwc->dr_mode = of_usb_get_dr_mode(node); + } else if (pdata) { dwc->maximum_speed = pdata->maximum_speed; + dwc->quirks = pdata->quirks; - dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2); - dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3); + if (!dwc->quirks & DWC3_SKIP_USB2_PHY) + dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2); + + if (!dwc->quirks & DWC3_SKIP_USB3_PHY) + dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3); dwc->needs_fifo_resize = pdata->tx_fifo_resize; dwc->dr_mode = pdata->dr_mode; @@ -732,6 +745,9 @@ static const struct dev_pm_ops dwc3_dev_pm_ops = { #ifdef CONFIG_OF static const struct of_device_id of_dwc3_match[] = { { + .compatible = "ti,dra7xxx-dwc3", + }, + { .compatible = "snps,dwc3" }, { > > > > > You can describe the USB2-only case in the dt by only listing the first > > > > > phy (though the driver won't support it as it expects both to be > > > > > present), but it's impossible to describe that you've wired up a single > > > > > phy that's USB3 capable. > > > > > > > > you might be right there... > > > > > > Would it be possible to have something like (an optional) usb-phy-names? > > > If not present, we assume the current situation, if present then we use > > > it to figure out which phys are present. Maybe I'm missing something > > > that makes that impossible? > > > > you're missing the point regarding the IP possibly needing something > > back from the PHY (e.g. a clock which PHY generates). > > I'm not sure why that detracts from the usb-phy-names idea -- if not > present, we stick with the current behaviour and require both PHYs or > fail early. No existing dts suddently explode, though none gain new > functionality either. > > If someone's explicitly placed usb-phy-names, we know that they're > up-to-date on the lastest binding, something like: > > - usb-phy: A list of phandles to PHYs. If usb-phy-names is not > present, the USB2/HS PHY should be first, followed by the > USB3/SS PHY. If usb-phy-names is present, it defines the > order of PHYs. > > - usb-phy-names: The names of PHYs described in the usb-phy property. > Valid values are "usb2" and "usb3". Should be used iff > a subset of PHYs are connected. > > Compatibility note: The DWC3 IP can be integrated in > such a way as to require outputs from particular PHYs > for *any* level of operation. This cannot be detected > by the OS, and on such systems all required PHYs must > be described. > > Given that, if they list fewer PHYs than present and their system really > requires a particular PHY, we can quite happily allow their system to > explode in the knowledge it's their fault, not ours :) LOL :-) Perhaps :-D > If they try to use their new DT on an old platform then the kernel will > refuse to use the DWC3, which would currently be the case anyway. right. -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding @ 2013-09-18 16:56 ` Felipe Balbi 0 siblings, 0 replies; 13+ messages in thread From: Felipe Balbi @ 2013-09-18 16:56 UTC (permalink / raw) To: Mark Rutland Cc: Felipe Balbi, Kumar Gala, rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Pawel Moll, Stephen Warren, Ian Campbell, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 6566 bytes --] Hi, On Wed, Sep 18, 2013 at 05:46:10PM +0100, Mark Rutland wrote: > > > > I even wrote a patch making USB3 PHY optional, but didn't push it > > > > exactly because it broke some other systems and I can't guarantee users > > > > won't mess up their DTS/pdata. > > > > > > Does that mean that their dts or pdata are wrong at the moment, but > > > they're spared because the driver bails out due to a missing phy? If > > > their pdata's wrong, that should be fixable relatively easily, but if > > > the dt is wrong then I'm not sure how we can support those systems > > > sensibly. That sounds like an ideal candidate for a dt quirks > > > mechanism... > > > > hmm, the idea of the patch was: > > > > switch (maximum-speed) { > > case SUPER: > > grab_and_initialize_usb3_phy(); > > grab_and_initialize_usb2_phy(); > > break; > > case HIGH: > > case FULL: > > case LOW: > > grab_and_initialize_usb2_phy(); > > break; > > } > > > > now, imagine someone wants to run his dwc3 in highspeed mode, we > > wouldn't initialize USB3 PHY which could cause the whole IP to break. > > When you say wants to run it in highspeed mode, you mean that they want > this configured at run-time, or they deliberately omit a phy when > describing the hardware in the DT? it doesn't really matter, I guess. TI's DRA7xx platforms, for instance, don't even provide a USB3 PHY and now way to connect one (since PIPE3 interface isn't brought out of the chip). Granted the problem is bigger in superspeed capable integration where we want to run at highspeed for e.g. test purposes. > For the former I appreciate that it's a problem, but for the latter I'd > argue that's their fault. As far as I can see we initialise both PHYs in true, we can look at it that way. > the probe path and never uninitialise them, so the only problem would be > if someone's trying to be too clever. As we never check the return value > of usb_phy_init, they can still attempt to work around our best > efforts... > > I appreciate that we should not break existing DTs. More on that below. k > > I tried poking around on device's registers to see if there was any way > > to detect that the IP needs somethin back from USB3 PHY, but couldn't > > find anything. > > > > Since we can't know how the IP was integrated, it's best to leave it > > alone and require NOP xceiv to be used. > > Agreed for the existing systems, but I still think we can work around > this for new DTs... perhaps, but wouldn't that be a quirk ? If it's a quirk, perhaps we'd be better off adding a quirk flag to skip USB?PHY in some platforms. Then we could: diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 474162e..5d39e0e 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -387,16 +387,29 @@ static int dwc3_probe(struct platform_device *pdev) if (node) { dwc->maximum_speed = of_usb_get_maximum_speed(node); - dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0); - dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1); + if (of_device_is_compatible(node, "ti,dra7xxx-dwc3")) + dwc->quirks |= DWC3_SKIP_USB3PHY; + + if (!dwc->quirks & DWC3_SKIP_USB2_PHY) + dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, + "usb-phy", 0); + + if (!dwc->quirks & DWC3_SKIP_USB3_PHY) + dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, + "usb-phy", 1); dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize"); dwc->dr_mode = of_usb_get_dr_mode(node); + } else if (pdata) { dwc->maximum_speed = pdata->maximum_speed; + dwc->quirks = pdata->quirks; - dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2); - dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3); + if (!dwc->quirks & DWC3_SKIP_USB2_PHY) + dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2); + + if (!dwc->quirks & DWC3_SKIP_USB3_PHY) + dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3); dwc->needs_fifo_resize = pdata->tx_fifo_resize; dwc->dr_mode = pdata->dr_mode; @@ -732,6 +745,9 @@ static const struct dev_pm_ops dwc3_dev_pm_ops = { #ifdef CONFIG_OF static const struct of_device_id of_dwc3_match[] = { { + .compatible = "ti,dra7xxx-dwc3", + }, + { .compatible = "snps,dwc3" }, { > > > > > You can describe the USB2-only case in the dt by only listing the first > > > > > phy (though the driver won't support it as it expects both to be > > > > > present), but it's impossible to describe that you've wired up a single > > > > > phy that's USB3 capable. > > > > > > > > you might be right there... > > > > > > Would it be possible to have something like (an optional) usb-phy-names? > > > If not present, we assume the current situation, if present then we use > > > it to figure out which phys are present. Maybe I'm missing something > > > that makes that impossible? > > > > you're missing the point regarding the IP possibly needing something > > back from the PHY (e.g. a clock which PHY generates). > > I'm not sure why that detracts from the usb-phy-names idea -- if not > present, we stick with the current behaviour and require both PHYs or > fail early. No existing dts suddently explode, though none gain new > functionality either. > > If someone's explicitly placed usb-phy-names, we know that they're > up-to-date on the lastest binding, something like: > > - usb-phy: A list of phandles to PHYs. If usb-phy-names is not > present, the USB2/HS PHY should be first, followed by the > USB3/SS PHY. If usb-phy-names is present, it defines the > order of PHYs. > > - usb-phy-names: The names of PHYs described in the usb-phy property. > Valid values are "usb2" and "usb3". Should be used iff > a subset of PHYs are connected. > > Compatibility note: The DWC3 IP can be integrated in > such a way as to require outputs from particular PHYs > for *any* level of operation. This cannot be detected > by the OS, and on such systems all required PHYs must > be described. > > Given that, if they list fewer PHYs than present and their system really > requires a particular PHY, we can quite happily allow their system to > explode in the knowledge it's their fault, not ours :) LOL :-) Perhaps :-D > If they try to use their new DT on an old platform then the kernel will > refuse to use the DWC3, which would currently be the case anyway. right. -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-09-18 16:58 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-08-09 15:40 [PATCH] usb: dwc3: core: clarify usb-phy array binding Kumar Gala 2013-08-09 16:28 ` Mark Rutland 2013-08-09 18:42 ` Kumar Gala 2013-08-12 18:05 ` Felipe Balbi 2013-08-13 13:34 ` Mark Rutland 2013-08-27 18:53 ` Felipe Balbi 2013-08-28 16:01 ` Mark Rutland 2013-09-18 14:21 ` Felipe Balbi 2013-09-18 14:21 ` Felipe Balbi 2013-09-18 16:46 ` Mark Rutland 2013-09-18 16:46 ` Mark Rutland 2013-09-18 16:56 ` Felipe Balbi 2013-09-18 16:56 ` Felipe Balbi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.