All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amelie DELAUNAY <amelie.delaunay@st.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Roger Quadros <rogerq@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Tony Prisk <linux@prisktech.co.nz>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply
Date: Fri, 23 Feb 2018 10:46:52 +0000	[thread overview]
Message-ID: <55196991-f9c1-6d8d-368f-2ab5f8e81c56@st.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1802221325220.1295-100000@iolanthe.rowland.org>



On 02/22/2018 07:27 PM, Alan Stern wrote:
> On Thu, 22 Feb 2018, Amelie DELAUNAY wrote:
> 
>>>>>>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>>>>>> @@ -19,6 +19,7 @@ Optional properties:
>>>>>>>      - phys : phandle + phy specifier pair
>>>>>>>      - phy-names : "usb"
>>>>>>>      - resets : phandle + reset specifier pair
>>>>>>> + - vbus-supply : phandle of regulator supplying vbus
>>>>>>>     
>>>>>>
>>>>>> Can platforms have more than one regulator e.g. one regulator per port?
>>>>>>
>>>>>
>>>>> I imagine that yes, platforms could have one regulator per port.
>>>>> Regulator consumers bindings impose a <name>-supply property per
>>>>> regulator, so, what do you think about :
>>>>> vbus0-supply for port#0
>>>>> vbus1-supply for port#1
>>>>> ...
>>>>> vbusN-supply for port#N
>>>>>
>>>>> And then in probe, allocate 'struct regulator *vbus_supplies' with a
>>>>> size corresponding to 'HCS_N_PORTS(ehci->hcs_params) * sizeof(struct
>>>>> regulator *)'.
>>>>> And loop to get optional regulator vbus0, vbus1,..., vbusN.
>>>>> And then enable/disable the corresponding regulator in
>>>>> ehci_platform_port_power thanks to portnum.
>>>>
>>>> Looks fine to me but we need to get Alan's opinion if this is worth the effort.
>>>> If there isn't a single platform needing it we could probably do without it
>>>> but the DT binding must be scalable to add this feature in the future.
>>>
>>> I agree that for now there don't seem to be any platforms requiring
>>> more than one regulator, but this should be implemented in a way that
>>> could be expanded if necessary.
>>>
>>> Anyway, the basic idea is reasonable.  I don't know to what extent
>>> people want to power-off their EHCI ports, but if they do then we ought
>>> to turn off external regulators at the same time.
>>>
>>> Is there a real-life use case for this?
>>>
>>> Alan Stern
>>>
>>
>> On my setup I have the following:
>>
>>                    regulator_____vbus
>>    _________________             \
>> | EHCI controller |-port0-----[USB connector]
>> |_________________|-port1-----X
>>
>> So, I have one regulator only for port0. But I could I have one more if
>> port1 was connected. My current regulator could also supplies port1.
>>
>> To allocate a vbus_supplies array depending on N_PORTS, I have to move
>> this initialization from probe to ehci_platform_reset, after ehci_setup
>> is done.
>> Then, I have to define each regulator id depending on the port number.
>> This imposes a binding like
>> - portN_vbus-supply : phandle of regulator supplying vbus for port N
>> But I don't know if we can describe it like this in dt-bindings ?
>>
>> &ehci {
>> 	...
>> 	port0_vbus-supply = <&vbus_reg>;
>> 	port1_vbus-supply = <&vbus_reg>; //Could be another regulator, or not
>> specified if port is not connected.
>> 	...
>> };
>>
>> Is it ok to move vbus_supplies initialization in ehci_platform_reset ?
> 
> Yes, it's okay to move the code if you need to.
> 
> However, I can not speak on the DT implications.  Someone who knows
> more about it should chime in.
> 
> Alan Stern
> 

Thanks Alan,

I'm going to send a v3 including all these changes to ease review.

Regards,
Amelie

WARNING: multiple messages have this Message-ID (diff)
From: Amelie DELAUNAY <amelie.delaunay@st.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Tony Prisk <linux@prisktech.co.nz>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply
Date: Fri, 23 Feb 2018 10:46:52 +0000	[thread overview]
Message-ID: <55196991-f9c1-6d8d-368f-2ab5f8e81c56@st.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1802221325220.1295-100000@iolanthe.rowland.org>



On 02/22/2018 07:27 PM, Alan Stern wrote:
> On Thu, 22 Feb 2018, Amelie DELAUNAY wrote:
> 
>>>>>>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>>>>>> @@ -19,6 +19,7 @@ Optional properties:
>>>>>>>      - phys : phandle + phy specifier pair
>>>>>>>      - phy-names : "usb"
>>>>>>>      - resets : phandle + reset specifier pair
>>>>>>> + - vbus-supply : phandle of regulator supplying vbus
>>>>>>>     
>>>>>>
>>>>>> Can platforms have more than one regulator e.g. one regulator per port?
>>>>>>
>>>>>
>>>>> I imagine that yes, platforms could have one regulator per port.
>>>>> Regulator consumers bindings impose a <name>-supply property per
>>>>> regulator, so, what do you think about :
>>>>> vbus0-supply for port#0
>>>>> vbus1-supply for port#1
>>>>> ...
>>>>> vbusN-supply for port#N
>>>>>
>>>>> And then in probe, allocate 'struct regulator *vbus_supplies' with a
>>>>> size corresponding to 'HCS_N_PORTS(ehci->hcs_params) * sizeof(struct
>>>>> regulator *)'.
>>>>> And loop to get optional regulator vbus0, vbus1,..., vbusN.
>>>>> And then enable/disable the corresponding regulator in
>>>>> ehci_platform_port_power thanks to portnum.
>>>>
>>>> Looks fine to me but we need to get Alan's opinion if this is worth the effort.
>>>> If there isn't a single platform needing it we could probably do without it
>>>> but the DT binding must be scalable to add this feature in the future.
>>>
>>> I agree that for now there don't seem to be any platforms requiring
>>> more than one regulator, but this should be implemented in a way that
>>> could be expanded if necessary.
>>>
>>> Anyway, the basic idea is reasonable.  I don't know to what extent
>>> people want to power-off their EHCI ports, but if they do then we ought
>>> to turn off external regulators at the same time.
>>>
>>> Is there a real-life use case for this?
>>>
>>> Alan Stern
>>>
>>
>> On my setup I have the following:
>>
>>                    regulator_____vbus
>>    _________________             \
>> | EHCI controller |-port0-----[USB connector]
>> |_________________|-port1-----X
>>
>> So, I have one regulator only for port0. But I could I have one more if
>> port1 was connected. My current regulator could also supplies port1.
>>
>> To allocate a vbus_supplies array depending on N_PORTS, I have to move
>> this initialization from probe to ehci_platform_reset, after ehci_setup
>> is done.
>> Then, I have to define each regulator id depending on the port number.
>> This imposes a binding like
>> - portN_vbus-supply : phandle of regulator supplying vbus for port N
>> But I don't know if we can describe it like this in dt-bindings ?
>>
>> &ehci {
>> 	...
>> 	port0_vbus-supply = <&vbus_reg>;
>> 	port1_vbus-supply = <&vbus_reg>; //Could be another regulator, or not
>> specified if port is not connected.
>> 	...
>> };
>>
>> Is it ok to move vbus_supplies initialization in ehci_platform_reset ?
> 
> Yes, it's okay to move the code if you need to.
> 
> However, I can not speak on the DT implications.  Someone who knows
> more about it should chime in.
> 
> Alan Stern
> 

Thanks Alan,

I'm going to send a v3 including all these changes to ease review.

Regards,
Amelie

WARNING: multiple messages have this Message-ID (diff)
From: Amelie Delaunay <amelie.delaunay@st.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Roger Quadros <rogerq@ti.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Tony Prisk <linux@prisktech.co.nz>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [v2] usb: host: ehci-platform: add support for optional external vbus supply
Date: Fri, 23 Feb 2018 10:46:52 +0000	[thread overview]
Message-ID: <55196991-f9c1-6d8d-368f-2ab5f8e81c56@st.com> (raw)

DQoNCk9uIDAyLzIyLzIwMTggMDc6MjcgUE0sIEFsYW4gU3Rlcm4gd3JvdGU6DQo+IE9uIFRodSwg
MjIgRmViIDIwMTgsIEFtZWxpZSBERUxBVU5BWSB3cm90ZToNCj4gDQo+Pj4+Pj4+IC0tLSBhL0Rv
Y3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91c2IvdXNiLWVoY2kudHh0DQo+Pj4+Pj4+
ICsrKyBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91c2IvdXNiLWVoY2kudHh0
DQo+Pj4+Pj4+IEBAIC0xOSw2ICsxOSw3IEBAIE9wdGlvbmFsIHByb3BlcnRpZXM6DQo+Pj4+Pj4+
ICAgICAgLSBwaHlzIDogcGhhbmRsZSArIHBoeSBzcGVjaWZpZXIgcGFpcg0KPj4+Pj4+PiAgICAg
IC0gcGh5LW5hbWVzIDogInVzYiINCj4+Pj4+Pj4gICAgICAtIHJlc2V0cyA6IHBoYW5kbGUgKyBy
ZXNldCBzcGVjaWZpZXIgcGFpcg0KPj4+Pj4+PiArIC0gdmJ1cy1zdXBwbHkgOiBwaGFuZGxlIG9m
IHJlZ3VsYXRvciBzdXBwbHlpbmcgdmJ1cw0KPj4+Pj4+PiAgICAgDQo+Pj4+Pj4NCj4+Pj4+PiBD
YW4gcGxhdGZvcm1zIGhhdmUgbW9yZSB0aGFuIG9uZSByZWd1bGF0b3IgZS5nLiBvbmUgcmVndWxh
dG9yIHBlciBwb3J0Pw0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gSSBpbWFnaW5lIHRoYXQgeWVzLCBw
bGF0Zm9ybXMgY291bGQgaGF2ZSBvbmUgcmVndWxhdG9yIHBlciBwb3J0Lg0KPj4+Pj4gUmVndWxh
dG9yIGNvbnN1bWVycyBiaW5kaW5ncyBpbXBvc2UgYSA8bmFtZT4tc3VwcGx5IHByb3BlcnR5IHBl
cg0KPj4+Pj4gcmVndWxhdG9yLCBzbywgd2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgOg0KPj4+Pj4g
dmJ1czAtc3VwcGx5IGZvciBwb3J0IzANCj4+Pj4+IHZidXMxLXN1cHBseSBmb3IgcG9ydCMxDQo+
Pj4+PiAuLi4NCj4+Pj4+IHZidXNOLXN1cHBseSBmb3IgcG9ydCNODQo+Pj4+Pg0KPj4+Pj4gQW5k
IHRoZW4gaW4gcHJvYmUsIGFsbG9jYXRlICdzdHJ1Y3QgcmVndWxhdG9yICp2YnVzX3N1cHBsaWVz
JyB3aXRoIGENCj4+Pj4+IHNpemUgY29ycmVzcG9uZGluZyB0byAnSENTX05fUE9SVFMoZWhjaS0+
aGNzX3BhcmFtcykgKiBzaXplb2Yoc3RydWN0DQo+Pj4+PiByZWd1bGF0b3IgKiknLg0KPj4+Pj4g
QW5kIGxvb3AgdG8gZ2V0IG9wdGlvbmFsIHJlZ3VsYXRvciB2YnVzMCwgdmJ1czEsLi4uLCB2YnVz
Ti4NCj4+Pj4+IEFuZCB0aGVuIGVuYWJsZS9kaXNhYmxlIHRoZSBjb3JyZXNwb25kaW5nIHJlZ3Vs
YXRvciBpbg0KPj4+Pj4gZWhjaV9wbGF0Zm9ybV9wb3J0X3Bvd2VyIHRoYW5rcyB0byBwb3J0bnVt
Lg0KPj4+Pg0KPj4+PiBMb29rcyBmaW5lIHRvIG1lIGJ1dCB3ZSBuZWVkIHRvIGdldCBBbGFuJ3Mg
b3BpbmlvbiBpZiB0aGlzIGlzIHdvcnRoIHRoZSBlZmZvcnQuDQo+Pj4+IElmIHRoZXJlIGlzbid0
IGEgc2luZ2xlIHBsYXRmb3JtIG5lZWRpbmcgaXQgd2UgY291bGQgcHJvYmFibHkgZG8gd2l0aG91
dCBpdA0KPj4+PiBidXQgdGhlIERUIGJpbmRpbmcgbXVzdCBiZSBzY2FsYWJsZSB0byBhZGQgdGhp
cyBmZWF0dXJlIGluIHRoZSBmdXR1cmUuDQo+Pj4NCj4+PiBJIGFncmVlIHRoYXQgZm9yIG5vdyB0
aGVyZSBkb24ndCBzZWVtIHRvIGJlIGFueSBwbGF0Zm9ybXMgcmVxdWlyaW5nDQo+Pj4gbW9yZSB0
aGFuIG9uZSByZWd1bGF0b3IsIGJ1dCB0aGlzIHNob3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBhIHdh
eSB0aGF0DQo+Pj4gY291bGQgYmUgZXhwYW5kZWQgaWYgbmVjZXNzYXJ5Lg0KPj4+DQo+Pj4gQW55
d2F5LCB0aGUgYmFzaWMgaWRlYSBpcyByZWFzb25hYmxlLiAgSSBkb24ndCBrbm93IHRvIHdoYXQg
ZXh0ZW50DQo+Pj4gcGVvcGxlIHdhbnQgdG8gcG93ZXItb2ZmIHRoZWlyIEVIQ0kgcG9ydHMsIGJ1
dCBpZiB0aGV5IGRvIHRoZW4gd2Ugb3VnaHQNCj4+PiB0byB0dXJuIG9mZiBleHRlcm5hbCByZWd1
bGF0b3JzIGF0IHRoZSBzYW1lIHRpbWUuDQo+Pj4NCj4+PiBJcyB0aGVyZSBhIHJlYWwtbGlmZSB1
c2UgY2FzZSBmb3IgdGhpcz8NCj4+Pg0KPj4+IEFsYW4gU3Rlcm4NCj4+Pg0KPj4NCj4+IE9uIG15
IHNldHVwIEkgaGF2ZSB0aGUgZm9sbG93aW5nOg0KPj4NCj4+ICAgICAgICAgICAgICAgICAgICBy
ZWd1bGF0b3JfX19fX3ZidXMNCj4+ICAgIF9fX19fX19fX19fX19fX19fICAgICAgICAgICAgIFwN
Cj4+IHwgRUhDSSBjb250cm9sbGVyIHwtcG9ydDAtLS0tLVtVU0IgY29ubmVjdG9yXQ0KPj4gfF9f
X19fX19fX19fX19fX19ffC1wb3J0MS0tLS0tWA0KPj4NCj4+IFNvLCBJIGhhdmUgb25lIHJlZ3Vs
YXRvciBvbmx5IGZvciBwb3J0MC4gQnV0IEkgY291bGQgSSBoYXZlIG9uZSBtb3JlIGlmDQo+PiBw
b3J0MSB3YXMgY29ubmVjdGVkLiBNeSBjdXJyZW50IHJlZ3VsYXRvciBjb3VsZCBhbHNvIHN1cHBs
aWVzIHBvcnQxLg0KPj4NCj4+IFRvIGFsbG9jYXRlIGEgdmJ1c19zdXBwbGllcyBhcnJheSBkZXBl
bmRpbmcgb24gTl9QT1JUUywgSSBoYXZlIHRvIG1vdmUNCj4+IHRoaXMgaW5pdGlhbGl6YXRpb24g
ZnJvbSBwcm9iZSB0byBlaGNpX3BsYXRmb3JtX3Jlc2V0LCBhZnRlciBlaGNpX3NldHVwDQo+PiBp
cyBkb25lLg0KPj4gVGhlbiwgSSBoYXZlIHRvIGRlZmluZSBlYWNoIHJlZ3VsYXRvciBpZCBkZXBl
bmRpbmcgb24gdGhlIHBvcnQgbnVtYmVyLg0KPj4gVGhpcyBpbXBvc2VzIGEgYmluZGluZyBsaWtl
DQo+PiAtIHBvcnROX3ZidXMtc3VwcGx5IDogcGhhbmRsZSBvZiByZWd1bGF0b3Igc3VwcGx5aW5n
IHZidXMgZm9yIHBvcnQgTg0KPj4gQnV0IEkgZG9uJ3Qga25vdyBpZiB3ZSBjYW4gZGVzY3JpYmUg
aXQgbGlrZSB0aGlzIGluIGR0LWJpbmRpbmdzID8NCj4+DQo+PiAmZWhjaSB7DQo+PiAJLi4uDQo+
PiAJcG9ydDBfdmJ1cy1zdXBwbHkgPSA8JnZidXNfcmVnPjsNCj4+IAlwb3J0MV92YnVzLXN1cHBs
eSA9IDwmdmJ1c19yZWc+OyAvL0NvdWxkIGJlIGFub3RoZXIgcmVndWxhdG9yLCBvciBub3QNCj4+
IHNwZWNpZmllZCBpZiBwb3J0IGlzIG5vdCBjb25uZWN0ZWQuDQo+PiAJLi4uDQo+PiB9Ow0KPj4N
Cj4+IElzIGl0IG9rIHRvIG1vdmUgdmJ1c19zdXBwbGllcyBpbml0aWFsaXphdGlvbiBpbiBlaGNp
X3BsYXRmb3JtX3Jlc2V0ID8NCj4gDQo+IFllcywgaXQncyBva2F5IHRvIG1vdmUgdGhlIGNvZGUg
aWYgeW91IG5lZWQgdG8uDQo+IA0KPiBIb3dldmVyLCBJIGNhbiBub3Qgc3BlYWsgb24gdGhlIERU
IGltcGxpY2F0aW9ucy4gIFNvbWVvbmUgd2hvIGtub3dzDQo+IG1vcmUgYWJvdXQgaXQgc2hvdWxk
IGNoaW1lIGluLg0KPiANCj4gQWxhbiBTdGVybg0KPiANCg0KVGhhbmtzIEFsYW4sDQoNCkknbSBn
b2luZyB0byBzZW5kIGEgdjMgaW5jbHVkaW5nIGFsbCB0aGVzZSBjaGFuZ2VzIHRvIGVhc2UgcmV2
aWV3Lg0KDQpSZWdhcmRzLA0KQW1lbGll
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: amelie.delaunay@st.com (Amelie DELAUNAY)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply
Date: Fri, 23 Feb 2018 10:46:52 +0000	[thread overview]
Message-ID: <55196991-f9c1-6d8d-368f-2ab5f8e81c56@st.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1802221325220.1295-100000@iolanthe.rowland.org>



On 02/22/2018 07:27 PM, Alan Stern wrote:
> On Thu, 22 Feb 2018, Amelie DELAUNAY wrote:
> 
>>>>>>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>>>>>>> @@ -19,6 +19,7 @@ Optional properties:
>>>>>>>      - phys : phandle + phy specifier pair
>>>>>>>      - phy-names : "usb"
>>>>>>>      - resets : phandle + reset specifier pair
>>>>>>> + - vbus-supply : phandle of regulator supplying vbus
>>>>>>>     
>>>>>>
>>>>>> Can platforms have more than one regulator e.g. one regulator per port?
>>>>>>
>>>>>
>>>>> I imagine that yes, platforms could have one regulator per port.
>>>>> Regulator consumers bindings impose a <name>-supply property per
>>>>> regulator, so, what do you think about :
>>>>> vbus0-supply for port#0
>>>>> vbus1-supply for port#1
>>>>> ...
>>>>> vbusN-supply for port#N
>>>>>
>>>>> And then in probe, allocate 'struct regulator *vbus_supplies' with a
>>>>> size corresponding to 'HCS_N_PORTS(ehci->hcs_params) * sizeof(struct
>>>>> regulator *)'.
>>>>> And loop to get optional regulator vbus0, vbus1,..., vbusN.
>>>>> And then enable/disable the corresponding regulator in
>>>>> ehci_platform_port_power thanks to portnum.
>>>>
>>>> Looks fine to me but we need to get Alan's opinion if this is worth the effort.
>>>> If there isn't a single platform needing it we could probably do without it
>>>> but the DT binding must be scalable to add this feature in the future.
>>>
>>> I agree that for now there don't seem to be any platforms requiring
>>> more than one regulator, but this should be implemented in a way that
>>> could be expanded if necessary.
>>>
>>> Anyway, the basic idea is reasonable.  I don't know to what extent
>>> people want to power-off their EHCI ports, but if they do then we ought
>>> to turn off external regulators at the same time.
>>>
>>> Is there a real-life use case for this?
>>>
>>> Alan Stern
>>>
>>
>> On my setup I have the following:
>>
>>                    regulator_____vbus
>>    _________________             \
>> | EHCI controller |-port0-----[USB connector]
>> |_________________|-port1-----X
>>
>> So, I have one regulator only for port0. But I could I have one more if
>> port1 was connected. My current regulator could also supplies port1.
>>
>> To allocate a vbus_supplies array depending on N_PORTS, I have to move
>> this initialization from probe to ehci_platform_reset, after ehci_setup
>> is done.
>> Then, I have to define each regulator id depending on the port number.
>> This imposes a binding like
>> - portN_vbus-supply : phandle of regulator supplying vbus for port N
>> But I don't know if we can describe it like this in dt-bindings ?
>>
>> &ehci {
>> 	...
>> 	port0_vbus-supply = <&vbus_reg>;
>> 	port1_vbus-supply = <&vbus_reg>; //Could be another regulator, or not
>> specified if port is not connected.
>> 	...
>> };
>>
>> Is it ok to move vbus_supplies initialization in ehci_platform_reset ?
> 
> Yes, it's okay to move the code if you need to.
> 
> However, I can not speak on the DT implications.  Someone who knows
> more about it should chime in.
> 
> Alan Stern
> 

Thanks Alan,

I'm going to send a v3 including all these changes to ease review.

Regards,
Amelie

  reply	other threads:[~2018-02-23 10:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 12:58 [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply Amelie Delaunay
2018-02-20 12:58 ` Amelie Delaunay
2018-02-20 12:58 ` [v2] " Amelie Delaunay
2018-02-20 12:58 ` [PATCH v2] " Amelie Delaunay
2018-02-20 13:02 ` Felipe Balbi
2018-02-20 13:02   ` Felipe Balbi
2018-02-20 13:02   ` [v2] " Felipe Balbi
2018-02-20 13:02   ` [PATCH v2] " Felipe Balbi
2018-02-20 13:48   ` Amelie DELAUNAY
2018-02-20 13:48     ` Amelie DELAUNAY
2018-02-20 13:48     ` [v2] " Amelie Delaunay
2018-02-20 13:48     ` [PATCH v2] " Amelie DELAUNAY
2018-02-20 14:00 ` Roger Quadros
2018-02-20 14:00   ` Roger Quadros
2018-02-20 14:00   ` [v2] " Roger Quadros
2018-02-20 14:00   ` [PATCH v2] " Roger Quadros
2018-02-20 14:46   ` Amelie DELAUNAY
2018-02-20 14:46     ` Amelie DELAUNAY
2018-02-20 14:46     ` [v2] " Amelie Delaunay
2018-02-20 14:46     ` [PATCH v2] " Amelie DELAUNAY
2018-02-20 16:33     ` Roger Quadros
2018-02-20 16:33       ` Roger Quadros
2018-02-20 16:33       ` [v2] " Roger Quadros
2018-02-20 16:33       ` [PATCH v2] " Roger Quadros
2018-02-20 18:10       ` Alan Stern
2018-02-20 18:10         ` Alan Stern
2018-02-20 18:10         ` [v2] " Alan Stern
2018-02-20 18:10         ` [PATCH v2] " Alan Stern
2018-02-22 10:17         ` Amelie DELAUNAY
2018-02-22 10:17           ` Amelie DELAUNAY
2018-02-22 10:17           ` [v2] " Amelie Delaunay
2018-02-22 10:17           ` [PATCH v2] " Amelie DELAUNAY
2018-02-22 18:27           ` Alan Stern
2018-02-22 18:27             ` Alan Stern
2018-02-22 18:27             ` [v2] " Alan Stern
2018-02-22 18:27             ` [PATCH v2] " Alan Stern
2018-02-23 10:46             ` Amelie DELAUNAY [this message]
2018-02-23 10:46               ` Amelie DELAUNAY
2018-02-23 10:46               ` [v2] " Amelie Delaunay
2018-02-23 10:46               ` [PATCH v2] " Amelie DELAUNAY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55196991-f9c1-6d8d-368f-2ab5f8e81c56@st.com \
    --to=amelie.delaunay@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@prisktech.co.nz \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rogerq@ti.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.