On Thu, Jun 15, 2017 at 06:06:04PM +0800, Peter Chen wrote:
> On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
> > On 15 June 2017 at 11:11, Peter Chen wrote:
> > > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
> > >> > Yes, you
On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
> On 15 June 2017 at 11:11, Peter Chen <hzpeterc...@gmail.com> wrote:
> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
> >> > Yes, you are right. This is the limitation for this po
On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote:
> On 15 June 2017 at 11:11, Peter Chen wrote:
> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote:
> >> > Yes, you are right. This is the limitation for this power sequence
> >> > library, t
ail, won't it?
> >
> > Yes, you are right, thanks for pointing that, I will add mutex_lock for
> > of_pwrseq_on.
>
> Another option is to entirely skip to two step approach.
>
> In other words, make the library to cope with multiple users via the
> same registered library instance.
>
No, the pwrseq instance stores dtb information (clock, gpio, etc), it
needs to be per device.
--
Best Regards,
Peter Chen
ail, won't it?
> >
> > Yes, you are right, thanks for pointing that, I will add mutex_lock for
> > of_pwrseq_on.
>
> Another option is to entirely skip to two step approach.
>
> In other words, make the library to cope with multiple users via the
> same registered library instance.
>
No, the pwrseq instance stores dtb information (clock, gpio, etc), it
needs to be per device.
--
Best Regards,
Peter Chen
On Wed, Jun 14, 2017 at 10:53:29AM +0200, Ulf Hansson wrote:
> On 14 June 2017 at 03:53, Peter Chen <hzpeterc...@gmail.com> wrote:
> > On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
> >> [...]
> >>
> >> > +
> >> > +/**
> &g
On Wed, Jun 14, 2017 at 10:53:29AM +0200, Ulf Hansson wrote:
> On 14 June 2017 at 03:53, Peter Chen wrote:
> > On Tue, Jun 13, 2017 at 12:24:42PM +0200, Ulf Hansson wrote:
> >> [...]
> >>
> >> > +
> >> > +/**
> >> >
ances needs to be registered an
> early boot level, to be safe. To me, that seems like poor design
> choice.
>
> Otherwise I think this looks okay to me.
>
--
Best Regards,
Peter Chen
ances needs to be registered an
> early boot level, to be safe. To me, that seems like poor design
> choice.
>
> Otherwise I think this looks okay to me.
>
--
Best Regards,
Peter Chen
instead (eg, USB hub driver).
For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.
Signed-off-by: Peter Chen <peter.c...@nxp.com>
Tested-by: Maciej S. Szmigi
-off-by: Peter Chen <peter.c...@nxp.com>
Tested-by Joshua Clayton <stillcompil...@gmail.com>
Tested-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
Reviewed-by: Vaibhav Hiremath <hvaibhav.li...@gmail.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
---
drivers/
instead (eg, USB hub driver).
For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.
Signed-off-by: Peter Chen
Tested-by: Maciej S. Szmigiero
Tested-by Joshua Clayton
Reviewed
-off-by: Peter Chen
Tested-by Joshua Clayton
Tested-by: Maciej S. Szmigiero
Reviewed-by: Vaibhav Hiremath
Acked-by: Alan Stern
---
drivers/usb/Kconfig| 1 +
drivers/usb/core/hub.c | 49 +
drivers/usb/core/hub.h | 1 +
3 files changed, 47
From: Joshua Clayton <stillcompil...@gmail.com>
Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a attribute
Signed-off-by: Joshua Clayton <stillcompil...@gmail.com>
Signed-o
From: Joshua Clayton
Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a attribute
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6qdl.dtsi | 6
layton <stillcompil...@gmail.com>
Signed-off-by: Peter Chen <peter.c...@nxp.com>
---
arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index fd222
From: Joshua Clayton
Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.
Signed-off-by: Peter Chen <peter.c...@nxp.
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.
Signed-off-by: Peter Chen
Signed-off
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen <peter.c...@nxp.com>
Acked-by: Philipp Zabel <p.za...@pengutronix.de>
Acked-by: Rob Herring <r...@kernel.org>
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
Add optional properties for power sequence.
Signed-off-by: Peter Chen <peter.c...@nxp.com>
Acked-by: Rob Herring <r...@kernel.org>
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentatio
Add optional properties for power sequence.
Signed-off-by: Peter Chen
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
Acked-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree
msg142815.html
[4] http://www.spinics.net/lists/linux-usb/msg152375.html
Joshua Clayton (2):
ARM: dts: imx6qdl: Enable usb node children with
ARM: dts: imx6q-evi: Fix onboard hub reset line
Peter Chen (5):
binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence lib
msg142815.html
[4] http://www.spinics.net/lists/linux-usb/msg152375.html
Joshua Clayton (2):
ARM: dts: imx6qdl: Enable usb node children with
ARM: dts: imx6q-evi: Fix onboard hub reset line
Peter Chen (5):
binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence lib
>
>Can you confirm that ULPI phys works with IMX6?
>
>It seems that IMX53 and IMX6 use the same chipidea controller and should have
>the
>same behaviour. So I wonder if the issue I encounter can be a SOC issue.
>
Fabien, all imx6 series uses UTMI PHYs, so I am afraid I can't verify it.
Peter
>
>Can you confirm that ULPI phys works with IMX6?
>
>It seems that IMX53 and IMX6 use the same chipidea controller and should have
>the
>same behaviour. So I wonder if the issue I encounter can be a SOC issue.
>
Fabien, all imx6 series uses UTMI PHYs, so I am afraid I can't verify it.
Peter
>
>I have a look at your patches
>(http://www.spinics.net/lists/linux-usb/msg157134.html)
>and I wonder if power sequence is applicable only on hub node?
No, power sequence can be used for any devices which needs to carry out power on
before probe.
> hub are probed too
>late (after
>
>I have a look at your patches
>(http://www.spinics.net/lists/linux-usb/msg157134.html)
>and I wonder if power sequence is applicable only on hub node?
No, power sequence can be used for any devices which needs to carry out power on
before probe.
> hub are probed too
>late (after
On Tue, Jun 06, 2017 at 07:36:10PM +0200, Fabien Lahoudere wrote:
> Hi Peter,
>
> On Tue, 2017-06-06 at 09:55 +0800, Peter Chen wrote:
> > On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> > > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
>
On Tue, Jun 06, 2017 at 07:36:10PM +0200, Fabien Lahoudere wrote:
> Hi Peter,
>
> On Tue, 2017-06-06 at 09:55 +0800, Peter Chen wrote:
> > On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> > > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
>
On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
> > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote:
> > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote:
> > > > On
On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote:
> On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote:
> > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote:
> > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote:
> > > > On
On Mon, Jun 05, 2017 at 10:16:34AM -0400, Alan Stern wrote:
> On Mon, 5 Jun 2017, Peter Chen wrote:
>
> > On Thu, May 18, 2017 at 08:49:00AM +0800, Peter Chen wrote:
> > > Some hard-wired USB devices need to do power sequence to let the
> > > device work normally, t
On Mon, Jun 05, 2017 at 10:16:34AM -0400, Alan Stern wrote:
> On Mon, 5 Jun 2017, Peter Chen wrote:
>
> > On Thu, May 18, 2017 at 08:49:00AM +0800, Peter Chen wrote:
> > > Some hard-wired USB devices need to do power sequence to let the
> > > device work normally, t
y_init(struct ci_hdrc *ci)
> return ret;
> hw_phymode_configure(ci);
> break;
> - case USBPHY_INTERFACE_MODE_ULPI:
> case USBPHY_INTERFACE_MODE_SERIAL:
> hw_phymode_configure(ci);
> ret = _ci_usb_phy_init(ci);
> --
Currently, the hw_phymode_configure is called twice for ULPI PHY, the
two execution are between _ci_usb_phy_init, would you test which one
causes hang? If the second causes hang, you can make a patch for
hw_phymode_configure that if the required PORTSC_PTS is the same
the value in register, do noop.
--
Best Regards,
Peter Chen
y_init(struct ci_hdrc *ci)
> return ret;
> hw_phymode_configure(ci);
> break;
> - case USBPHY_INTERFACE_MODE_ULPI:
> case USBPHY_INTERFACE_MODE_SERIAL:
> hw_phymode_configure(ci);
> ret = _ci_usb_phy_init(ci);
> --
Currently, the hw_phymode_configure is called twice for ULPI PHY, the
two execution are between _ci_usb_phy_init, would you test which one
causes hang? If the second causes hang, you can make a patch for
hw_phymode_configure that if the required PORTSC_PTS is the same
the value in register, do noop.
--
Best Regards,
Peter Chen
On Thu, May 18, 2017 at 08:49:00AM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to d
On Thu, May 18, 2017 at 08:49:00AM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to d
On Thu, May 18, 2017 at 08:48:58AM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power s
On Thu, May 18, 2017 at 08:48:58AM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power s
et_of_node_from_dev(>dev, bus->sysdev);
> dev_set_name(>dev, "usb%d", bus->busnum);
> root_hub = 1;
> } else {
> --
> 2.13.0
I am OK with it, but I suggest adding it for new rc1 since it is based
on the 1st patch which is a bug-fix. If this one is really needed for
stable tree in future, you can cherry-pick it.
--
Best Regards,
Peter Chen
(>dev, bus->sysdev);
> dev_set_name(>dev, "usb%d", bus->busnum);
> root_hub = 1;
> } else {
> --
> 2.13.0
I am OK with it, but I suggest adding it for new rc1 since it is based
on the 1st patch which is a bug-fix. If this one is really needed for
stable tree in future, you can cherry-pick it.
--
Best Regards,
Peter Chen
; Fixes: 69bec7259853 ("USB: core: let USB device know device node")
> Cc: stable <sta...@vger.kernel.org> # v4.6
> Cc: Peter Chen <peter.c...@nxp.com>
> Signed-off-by: Johan Hovold <jo...@kernel.org>
> ---
> drivers/usb/core/usb.c | 2 ++
> 1 file
; Fixes: 69bec7259853 ("USB: core: let USB device know device node")
> Cc: stable# v4.6
> Cc: Peter Chen
> Signed-off-by: Johan Hovold
> ---
> drivers/usb/core/usb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/core/usb.c b/dr
u trigger this issue?
Do you mind sending another patch to fix the same issue for ci_role_show
at core.c?
--
Best Regards,
Peter Chen
= s->private;
>
> - seq_printf(s, "%s\n", ci_role(ci)->name);
> + if (ci->role != CI_ROLE_END)
> + seq_printf(s, "%s\n", ci_role(ci)->name);
>
> return 0;
> }
By the way, how can you trigger this issue?
Do you mind sending another patch to fix the same issue for ci_role_show
at core.c?
--
Best Regards,
Peter Chen
> {
> struct ci_hdrc *ci = s->private;
>
> - seq_printf(s, "%s\n", ci_role(ci)->name);
> + if (ci->role != CI_ROLE_END)
> + seq_printf(s, "%s\n", ci_role(ci)->name);
>
> return 0;
> }
I will queue it, and cc stable
--
Best Regards,
Peter Chen
= s->private;
>
> - seq_printf(s, "%s\n", ci_role(ci)->name);
> + if (ci->role != CI_ROLE_END)
> + seq_printf(s, "%s\n", ci_role(ci)->name);
>
> return 0;
> }
I will queue it, and cc stable
--
Best Regards,
Peter Chen
-off-by: Peter Chen <peter.c...@nxp.com>
Tested-by Joshua Clayton <stillcompil...@gmail.com>
Tested-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
Reviewed-by: Vaibhav Hiremath <hvaibhav.li...@gmail.com>
---
drivers/usb/Kconfig| 1 +
dri
-off-by: Peter Chen
Tested-by Joshua Clayton
Tested-by: Maciej S. Szmigiero
Reviewed-by: Vaibhav Hiremath
---
drivers/usb/Kconfig| 1 +
drivers/usb/core/hub.c | 49 +
drivers/usb/core/hub.h | 1 +
3 files changed, 47 insertions(+), 4 deletions
layton <stillcompil...@gmail.com>
Signed-off-by: Peter Chen <peter.c...@nxp.com>
---
arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index fd222
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.
Signed-off-by: Peter Chen <peter.c...@nxp.
From: Joshua Clayton
Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.
Signed-off-by: Peter Chen
Signed-off
From: Joshua Clayton <stillcompil...@gmail.com>
Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a attribute
Signed-off-by: Joshua Clayton <stillcompil...@gmail.com>
Signed-o
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen <peter.c...@nxp.com>
Acked-by: Philipp Zabel <p.za...@pengutronix.de>
Acked-by: Rob Herring <r...@kernel.org>
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
From: Joshua Clayton
Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a attribute
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6qdl.dtsi | 6
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
Acked-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree
instead (eg, USB hub driver).
For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.
Signed-off-by: Peter Chen <peter.c...@nxp.com>
Tested-by: Maciej S. Szmigi
instead (eg, USB hub driver).
For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.
Signed-off-by: Peter Chen
Tested-by: Maciej S. Szmigiero
Tested-by Joshua Clayton
Reviewed
Add optional properties for power sequence.
Signed-off-by: Peter Chen <peter.c...@nxp.com>
Acked-by: Rob Herring <r...@kernel.org>
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentatio
Add optional properties for power sequence.
Signed-off-by: Peter Chen
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b
142815.html
[4] http://www.spinics.net/lists/linux-usb/msg152375.html
Joshua Clayton (2):
ARM: dts: imx6qdl: Enable usb node children with
ARM: dts: imx6q-evi: Fix onboard hub reset line
Peter Chen (5):
binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence library
power
142815.html
[4] http://www.spinics.net/lists/linux-usb/msg152375.html
Joshua Clayton (2):
ARM: dts: imx6qdl: Enable usb node children with
ARM: dts: imx6q-evi: Fix onboard hub reset line
Peter Chen (5):
binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence library
power
On Tue, May 16, 2017 at 07:28:55PM +0200, Krzysztof Kozlowski wrote:
> On Wed, Feb 15, 2017 at 09:38:09AM +0800, Peter Chen wrote:
> > On Tue, Feb 14, 2017 at 12:21:48PM +0200, Roger Quadros wrote:
> > > Peter,
> > >
> > > On 11/02/17 03:
On Tue, May 16, 2017 at 07:28:55PM +0200, Krzysztof Kozlowski wrote:
> On Wed, Feb 15, 2017 at 09:38:09AM +0800, Peter Chen wrote:
> > On Tue, Feb 14, 2017 at 12:21:48PM +0200, Roger Quadros wrote:
> > > Peter,
> > >
> > > On 11/02/17 03:
,7 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
> },
> {
> .compatible = "fsl,imx51-usbmisc",
> - .data = _usbmisc_ops,
> + .data = _usbmisc_ops,
> },
> {
> .compatible = "fsl,imx53-usbmisc",
Thanks for fixing it.
I prefer using is_imx53_usbmisc stands for if it is imx53 usbmisc
at usbmisc_imx53_init to fix it, you can prefer to:
drivers/usb/phy/phy-mxs-usb.c.
--
Best Regards,
Peter Chen
},
> {
> .compatible = "fsl,imx51-usbmisc",
> - .data = _usbmisc_ops,
> + .data = _usbmisc_ops,
> },
> {
> .compatible = "fsl,imx53-usbmisc",
Thanks for fixing it.
I prefer using is_imx53_usbmisc stands for if it is imx53 usbmisc
at usbmisc_imx53_init to fix it, you can prefer to:
drivers/usb/phy/phy-mxs-usb.c.
--
Best Regards,
Peter Chen
>
>The board file for imx6sx-dbg overrides cpufreq operating points to use higher
>voltages. This is done because the board has a shared rail for VDD_ARM_IN and
>VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value
>suitable for both ARM and SOC.
>
>This was introduced in:
>
>The board file for imx6sx-dbg overrides cpufreq operating points to use higher
>voltages. This is done because the board has a shared rail for VDD_ARM_IN and
>VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value
>suitable for both ARM and SOC.
>
>This was introduced in:
On Wed, Apr 26, 2017 at 04:25:26PM +0800, Jisheng Zhang wrote:
> On Tue, 25 Apr 2017 17:21:59 +0200
> Stefan Wahren <stefan.wah...@i2se.com> wrote:
>
> > Am 25.04.2017 um 11:20 schrieb Peter Chen:
> > >
> > >>>> diff --git a/drivers
On Wed, Apr 26, 2017 at 04:25:26PM +0800, Jisheng Zhang wrote:
> On Tue, 25 Apr 2017 17:21:59 +0200
> Stefan Wahren wrote:
>
> > Am 25.04.2017 um 11:20 schrieb Peter Chen:
> > >
> > >>>> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/
ret);
- goto stop;
+ goto deinit_gadget;
}
}
@@ -1075,7 +1075,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
remove_debug:
dbg_remove_files(ci);
stop:
- if (ci->is_otg)
+ if (ci->is_otg && ci->roles[CI_ROLE_GADGET])
ci_hdrc_otg_destroy(ci);
deinit_gadget:
ci_hdrc_gadget_destroy(ci);
--
Best Regards,
Peter Chen
goto deinit_gadget;
}
}
@@ -1075,7 +1075,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
remove_debug:
dbg_remove_files(ci);
stop:
- if (ci->is_otg)
+ if (ci->is_otg && ci->roles[CI_ROLE_GADGET])
ci_hdrc_otg_destroy(ci);
deinit_gadget:
ci_hdrc_gadget_destroy(ci);
--
Best Regards,
Peter Chen
>> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
>> > index f88e9157fad0..60a786c87c06 100644
>> > --- a/drivers/usb/chipidea/udc.c
>> > +++ b/drivers/usb/chipidea/udc.c
>> > @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct
>> > ci_hdrc *ci) int
>> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
>> > index f88e9157fad0..60a786c87c06 100644
>> > --- a/drivers/usb/chipidea/udc.c
>> > +++ b/drivers/usb/chipidea/udc.c
>> > @@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct
>> > ci_hdrc *ci) int
gt;roles[CI_ROLE_GADGET] = rdrv;
>
> - return udc_start(ci);
> + ret = udc_start(ci);
> + if (!ret)
> + ci->roles[CI_ROLE_GADGET] = rdrv;
> +
> + return ret;
> }
> --
Thanks for fixing it. In fact, we'd better return failure if
ret && ret != -ENXIO at probe, it stands for initialization
for host or gadget has failed.
--
Best Regards,
Peter Chen
rdrv;
>
> - return udc_start(ci);
> + ret = udc_start(ci);
> + if (!ret)
> + ci->roles[CI_ROLE_GADGET] = rdrv;
> +
> + return ret;
> }
> --
Thanks for fixing it. In fact, we'd better return failure if
ret && ret != -ENXIO at probe, it stands for initialization
for host or gadget has failed.
--
Best Regards,
Peter Chen
On Mon, Apr 24, 2017 at 01:25:21PM +, Bernhard Walle wrote:
> Hi,
>
> > Peter Chen <peter.c...@nxp.com> hat am 24. April 2017 um 05:51 geschrieben:
> > >
> > The current code logic is:
> > - When the resume is received from host, the ci->dirver->r
On Mon, Apr 24, 2017 at 01:25:21PM +, Bernhard Walle wrote:
> Hi,
>
> > Peter Chen hat am 24. April 2017 um 05:51 geschrieben:
> > >
> > The current code logic is:
> > - When the resume is received from host, the ci->dirver->resume is
> >
sume doesn't need to be called.
There is a patch to fix clear suspended even the ci->driver->resume is
NULL at v4.12-rc1.
usb: chipidea: udc: update gadget state after bus resume
--
Best Regards,
Peter Chen
sume doesn't need to be called.
There is a patch to fix clear suspended even the ci->driver->resume is
NULL at v4.12-rc1.
usb: chipidea: udc: update gadget state after bus resume
--
Best Regards,
Peter Chen
itialization path.
>
> A new compatible string "smsc,usb3315" is used to decide which
> initialization path to use.
>
Hi Peter,
This is an ULPI PHY, so it is not suitable using generic USB PHY.
Taking a look of drivers/phy/phy-qcom-usb-hs.c, you may have some
clues.
itialization path.
>
> A new compatible string "smsc,usb3315" is used to decide which
> initialization path to use.
>
Hi Peter,
This is an ULPI PHY, so it is not suitable using generic USB PHY.
Taking a look of drivers/phy/phy-qcom-usb-hs.c, you may have some
clues.
Pete
adget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -139,10 +139,8 @@ int usb_ep_disable(struct usb_ep *ep)
> goto out;
>
> ret = ep->ops->disable(ep);
> - if (ret) {
> - ret = ret;
> + if (ret)
> goto out;
>
b/drivers/usb/gadget/udc/core.c
> @@ -139,10 +139,8 @@ int usb_ep_disable(struct usb_ep *ep)
> goto out;
>
> ret = ep->ops->disable(ep);
> - if (ret) {
> - ret = ret;
> + if (ret)
> goto out;
> - }
>
> ep->enabled = false;
>
Reviewed-by: Peter Chen
--
Best Regards,
Peter Chen
isconnected.
> >
> > You don't need to use above two methods together, I suggest using the
> > 2nd method since OTG FSM is hard to maintain due to no mandatory use
> > case for it.
> >
> > --
> >
> > Best Regards,
> > Peter Chen
>
> T
isconnected.
> >
> > You don't need to use above two methods together, I suggest using the
> > 2nd method since OTG FSM is hard to maintain due to no mandatory use
> > case for it.
> >
> > --
> >
> > Best Regards,
> > Peter Chen
>
> T
, and using sysfs entries under
/sys/bus/platform/devices/ci_hdrc.0/inputs
but you may need to patch code to keep vbus always on for A-device,
it is not compliance with OTG spec.
- Using role interface under debugfs (I move it under sysfs for v4.12).
But you need to patch the code and let the A-device switch back to
host after iAP is disconnected.
You don't need to use above two methods together, I suggest using the
2nd method since OTG FSM is hard to maintain due to no mandatory use
case for it.
--
Best Regards,
Peter Chen
der
/sys/bus/platform/devices/ci_hdrc.0/inputs
but you may need to patch code to keep vbus always on for A-device,
it is not compliance with OTG spec.
- Using role interface under debugfs (I move it under sysfs for v4.12).
But you need to patch the code and let the A-device switch back to
host after iAP is disconnected.
You don't need to use above two methods together, I suggest using the
2nd method since OTG FSM is hard to maintain due to no mandatory use
case for it.
--
Best Regards,
Peter Chen
On Wed, Mar 08, 2017 at 06:44:47AM -0800, Guenter Roeck wrote:
> On 03/07/2017 10:50 PM, Peter Chen wrote:
> >
> >>>>You mean type-C trigger an ACPI event, and this ACPI event can notify
> >>>>related USB controller driver doing role switch?
> >&
On Wed, Mar 08, 2017 at 06:44:47AM -0800, Guenter Roeck wrote:
> On 03/07/2017 10:50 PM, Peter Chen wrote:
> >
> >>>>You mean type-C trigger an ACPI event, and this ACPI event can notify
> >>>>related USB controller driver doing role switch?
> >&
>>> You mean type-C trigger an ACPI event, and this ACPI event can notify
>>> related USB controller driver doing role switch?
>>
>> No (firmware programs the dual-role hw/registers), but never mind.
>> That could be the case.
>>
>>> If it is correct, there is a notifier between type-C and USB
>>> You mean type-C trigger an ACPI event, and this ACPI event can notify
>>> related USB controller driver doing role switch?
>>
>> No (firmware programs the dual-role hw/registers), but never mind.
>> That could be the case.
>>
>>> If it is correct, there is a notifier between type-C and USB
>
>On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote:
>> > > What interface you use when you receive this event to handle
>> > > dual-role switch? I am wonder if a common dual-role class is
>> > > needed, then we can have a common user uti
>
>On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote:
>> > > What interface you use when you receive this event to handle
>> > > dual-role switch? I am wonder if a common dual-role class is
>> > > needed, then we can have a common user uti
On Fri, Mar 03, 2017 at 06:36:50AM -0800, Guenter Roeck wrote:
> On 03/02/2017 08:52 PM, Peter Chen wrote:
> >On Thu, Mar 02, 2017 at 08:29:07PM -0800, Guenter Roeck wrote:
> >>On 03/02/2017 07:35 PM, Peter Chen wrote:
> >>>On Tue, Feb 21, 2017 at 05:24:04P
On Fri, Mar 03, 2017 at 06:36:50AM -0800, Guenter Roeck wrote:
> On 03/02/2017 08:52 PM, Peter Chen wrote:
> >On Thu, Mar 02, 2017 at 08:29:07PM -0800, Guenter Roeck wrote:
> >>On 03/02/2017 07:35 PM, Peter Chen wrote:
> >>>On Tue, Feb 21, 2017 at 05:24:04P
On Fri, Mar 03, 2017 at 04:31:33PM +0200, Heikki Krogerus wrote:
> Hi Peter,
>
> On Fri, Mar 03, 2017 at 11:35:29AM +0800, Peter Chen wrote:
> > On Tue, Feb 21, 2017 at 05:24:04PM +0300, Heikki Krogerus wrote:
> > > +/* --- */
&g
301 - 400 of 2227 matches
Mail list logo
