i.MX6 USB OTG support is broken on linux-next

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

I'm running next-20140508 kernel on imx6q-sabresd board with USB
mouse/keyboard connected to OTG port.  It  works well on 3.15-rc but
is broken on recent linux-next kernel with the message like below.

...
usb 1-1: device v413c p2107 is not supported
hub 1-0:1.0: unable to enumerate USB device on port 1

With the help from Peter, I found that the issue shows up only when
CONFIG_USB_OTG_FSM is enabled.  The option is enabled by commit 8fd2f1f
(ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host support.)
from IMX tree.

I guess this is a sign that chipidea otg_fsm driver is buggy?  I do not
think dropping CONFIG_USB_OTG_FSM selection from imx_v6_v7_defconfig is
a solution, and we need to fix the issue in usb driver, right?

Shawn

i.MX6 USB OTG support is broken on linux-next

[Peter Chen]

On Fri, May 09, 2014 at 09:00:47PM +0800, Shawn Guo wrote:
> I'm running next-20140508 kernel on imx6q-sabresd board with USB
> mouse/keyboard connected to OTG port.  It  works well on 3.15-rc but
> is broken on recent linux-next kernel with the message like below.
> 
> ...
> usb 1-1: device v413c p2107 is not supported
> hub 1-0:1.0: unable to enumerate USB device on port 1
> 
> With the help from Peter, I found that the issue shows up only when
> CONFIG_USB_OTG_FSM is enabled.  The option is enabled by commit 8fd2f1f
> (ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host support.)
> from IMX tree.
> 
> I guess this is a sign that chipidea otg_fsm driver is buggy?  I do not
> think dropping CONFIG_USB_OTG_FSM selection from imx_v6_v7_defconfig is
> a solution, and we need to fix the issue in usb driver, right?
> 

No, Shawn. The solution of this problem is drop CONFIG_USB_OTG_FSM, I
guess Denis added it wrongly.

According to Embedded Hosts & OTG spec, OTG devices and Embedded Hosts
both have Targeted Host functionality, and each Targeted Host has
its TPL (Targeted Peripheral List), only the devices are at TPL
are supported by Targeted Host.

Current Linux TPL only contains limited devices, each Targeted Host
needs to update its TPL when it makes product, (The comments at
otg_whitelist.h also mention it), and the devices are not at TPL
will not be supported, and will report to user as "an unsupported
device" error, at current Linux configuration, once the CONFIG_USB_OTG_FSM
and CONFIG_USB_OTG are chosen, the host will be Targeted Host.

The reason why Shawn met this problem is: the imx_v6_v7_defconfig set 
CONFIG_USB_OTG_FSM, so the CONFIG_USB_OTG and CONFIG_USB_OTG_WHITELIST
are set according to dependency, it makes imx6 device as Targeted Host,
but the devices connected at Shawn's board are not at TPL, so they are
not be supported.

In a word the CONFIG_USB_OTG_FSM should not be chosen for
defauly kernel configuration. The CONFIG_USB_OTG_FSM should only be chosen
by default when this device goes to make product and the TPL is updated
accordingly.

Peter

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

+ Robin and David,

On Sat, May 10, 2014 at 07:10:05PM +0800, Peter Chen wrote:
> On Fri, May 09, 2014 at 09:00:47PM +0800, Shawn Guo wrote:
> > I'm running next-20140508 kernel on imx6q-sabresd board with USB
> > mouse/keyboard connected to OTG port.  It  works well on 3.15-rc but
> > is broken on recent linux-next kernel with the message like below.
> > 
> > ...
> > usb 1-1: device v413c p2107 is not supported
> > hub 1-0:1.0: unable to enumerate USB device on port 1
> > 
> > With the help from Peter, I found that the issue shows up only when
> > CONFIG_USB_OTG_FSM is enabled.  The option is enabled by commit 8fd2f1f
> > (ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host support.)
> > from IMX tree.
> > 
> > I guess this is a sign that chipidea otg_fsm driver is buggy?  I do not
> > think dropping CONFIG_USB_OTG_FSM selection from imx_v6_v7_defconfig is
> > a solution, and we need to fix the issue in usb driver, right?
> > 
> 
> No, Shawn. The solution of this problem is drop CONFIG_USB_OTG_FSM, I
> guess Denis added it wrongly.
> 
> According to Embedded Hosts & OTG spec, OTG devices and Embedded Hosts
> both have Targeted Host functionality, and each Targeted Host has
> its TPL (Targeted Peripheral List), only the devices are at TPL
> are supported by Targeted Host.
> 
> Current Linux TPL only contains limited devices, each Targeted Host
> needs to update its TPL when it makes product, (The comments at
> otg_whitelist.h also mention it), and the devices are not at TPL
> will not be supported, and will report to user as "an unsupported
> device" error, at current Linux configuration, once the CONFIG_USB_OTG_FSM
> and CONFIG_USB_OTG are chosen, the host will be Targeted Host.
> 
> The reason why Shawn met this problem is: the imx_v6_v7_defconfig set 
> CONFIG_USB_OTG_FSM, so the CONFIG_USB_OTG and CONFIG_USB_OTG_WHITELIST
> are set according to dependency, it makes imx6 device as Targeted Host,
> but the devices connected at Shawn's board are not at TPL, so they are
> not be supported.
> 
> In a word the CONFIG_USB_OTG_FSM should not be chosen for
> defauly kernel configuration. The CONFIG_USB_OTG_FSM should only be chosen
> by default when this device goes to make product and the TPL is updated
> accordingly.

Thanks for the explanation, Peter.

So this is what I see from USB Kconfig.

config USB_OTG_FSM
        tristate "USB 2.0 OTG FSM implementation"
        depends on USB
        select USB_OTG
        select USB_PHY

config USB_OTG_WHITELIST
        bool "Rely on OTG Targeted Peripherals List"
        depends on USB_OTG || EXPERT
        default y if USB_OTG

I see that USB_OTG_FSM has a dependency on USB_OTG, and
USB_OTG_WHITELIST depends on USB_OTG, but USB_OTG does *not* depends
on USB_OTG_WHITELIST.

I'm not sure why we have 'default y if USB_OTG' for USB_OTG_WHITELIST,
when this option only makes sense for product producers per your
explanation.  So maybe dropping the 'default y' is the right fix?

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index cb8e991..9081757 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -65,7 +65,6 @@ config USB_OTG
 config USB_OTG_WHITELIST
        bool "Rely on OTG Targeted Peripherals List"
        depends on USB_OTG || EXPERT
-       default y if USB_OTG
        help
          If you say Y here, the "otg_whitelist.h" file will be used as a
          product whitelist, so USB peripherals not listed there will be

Shawn

i.MX6 USB OTG support is broken on linux-next

[Li Jun]

On Sat, May 10, 2014 at 09:18:36PM +0800, Shawn Guo wrote:
> + Robin and David,
> 
> On Sat, May 10, 2014 at 07:10:05PM +0800, Peter Chen wrote:
> > On Fri, May 09, 2014 at 09:00:47PM +0800, Shawn Guo wrote:
> > > I'm running next-20140508 kernel on imx6q-sabresd board with USB
> > > mouse/keyboard connected to OTG port.  It  works well on 3.15-rc but
> > > is broken on recent linux-next kernel with the message like below.
> > > 
> > > ...
> > > usb 1-1: device v413c p2107 is not supported
> > > hub 1-0:1.0: unable to enumerate USB device on port 1
> > > 
> > > With the help from Peter, I found that the issue shows up only when
> > > CONFIG_USB_OTG_FSM is enabled.  The option is enabled by commit 8fd2f1f
> > > (ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host support.)
> > > from IMX tree.
> > > 
> > > I guess this is a sign that chipidea otg_fsm driver is buggy?  I do not
> > > think dropping CONFIG_USB_OTG_FSM selection from imx_v6_v7_defconfig is
> > > a solution, and we need to fix the issue in usb driver, right?
> > > 
> > 
> > No, Shawn. The solution of this problem is drop CONFIG_USB_OTG_FSM, I
> > guess Denis added it wrongly.
> > 
> > According to Embedded Hosts & OTG spec, OTG devices and Embedded Hosts
> > both have Targeted Host functionality, and each Targeted Host has
> > its TPL (Targeted Peripheral List), only the devices are at TPL
> > are supported by Targeted Host.
> > 
> > Current Linux TPL only contains limited devices, each Targeted Host
> > needs to update its TPL when it makes product, (The comments at
> > otg_whitelist.h also mention it), and the devices are not at TPL
> > will not be supported, and will report to user as "an unsupported
> > device" error, at current Linux configuration, once the CONFIG_USB_OTG_FSM
> > and CONFIG_USB_OTG are chosen, the host will be Targeted Host.
> > 
> > The reason why Shawn met this problem is: the imx_v6_v7_defconfig set 
> > CONFIG_USB_OTG_FSM, so the CONFIG_USB_OTG and CONFIG_USB_OTG_WHITELIST
> > are set according to dependency, it makes imx6 device as Targeted Host,
> > but the devices connected at Shawn's board are not at TPL, so they are
> > not be supported.
> > 
> > In a word the CONFIG_USB_OTG_FSM should not be chosen for
> > defauly kernel configuration. The CONFIG_USB_OTG_FSM should only be chosen
> > by default when this device goes to make product and the TPL is updated
> > accordingly.
> 
> Thanks for the explanation, Peter.
> 
> So this is what I see from USB Kconfig.
> 
> config USB_OTG_FSM
>         tristate "USB 2.0 OTG FSM implementation"
>         depends on USB
>         select USB_OTG
>         select USB_PHY
> 
> config USB_OTG_WHITELIST
>         bool "Rely on OTG Targeted Peripherals List"
>         depends on USB_OTG || EXPERT
>         default y if USB_OTG
> 
> I see that USB_OTG_FSM has a dependency on USB_OTG, and
> USB_OTG_WHITELIST depends on USB_OTG, but USB_OTG does *not* depends
> on USB_OTG_WHITELIST.
> 
> I'm not sure why we have 'default y if USB_OTG' for USB_OTG_WHITELIST,
> when this option only makes sense for product producers per your
> explanation.  So maybe dropping the 'default y' is the right fix?
> 
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index cb8e991..9081757 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -65,7 +65,6 @@ config USB_OTG
>  config USB_OTG_WHITELIST
>         bool "Rely on OTG Targeted Peripherals List"
>         depends on USB_OTG || EXPERT
> -       default y if USB_OTG
>         help
>           If you say Y here, the "otg_whitelist.h" file will be used as a
>           product whitelist, so USB peripherals not listed there will be
> 
> Shawn
As Peter suggested, do not enable OTG_FSM in defconfig since there are very few
HNP&SRP capable device in market. With OTG_FSM enabled, even USB_OTG_WHITELIST
is not selected, the OTG port still can't work the same as before if you connect
a normal usb device to it.

Li Jun

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

On Sat, May 10, 2014 at 09:57:39PM +0800, Li Jun wrote:
> As Peter suggested, do not enable OTG_FSM in defconfig since there are very few
> HNP&SRP capable device in market. With OTG_FSM enabled, even USB_OTG_WHITELIST
> is not selected, the OTG port still can't work the same as before if you connect
> a normal usb device to it.

Oh, okay.  In that case, I will have to drop OTG_FSM from defconfig.
Thanks for the info.

Shawn

i.MX6 USB OTG support is broken on linux-next

[Sascha Hauer]

On Sat, May 10, 2014 at 09:57:39PM +0800, Li Jun wrote:
> On Sat, May 10, 2014 at 09:18:36PM +0800, Shawn Guo wrote:
> > + Robin and David,
> > 
> > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> > index cb8e991..9081757 100644
> > --- a/drivers/usb/core/Kconfig
> > +++ b/drivers/usb/core/Kconfig
> > @@ -65,7 +65,6 @@ config USB_OTG
> >  config USB_OTG_WHITELIST
> >         bool "Rely on OTG Targeted Peripherals List"
> >         depends on USB_OTG || EXPERT
> > -       default y if USB_OTG
> >         help
> >           If you say Y here, the "otg_whitelist.h" file will be used as a
> >           product whitelist, so USB peripherals not listed there will be
> > 
> > Shawn
> As Peter suggested, do not enable OTG_FSM in defconfig since there are very few
> HNP&SRP capable device in market. With OTG_FSM enabled, even USB_OTG_WHITELIST
> is not selected, the OTG port still can't work the same as before if you connect
> a normal usb device to it.

If a device is not HNP/SRP capable then it should not be used on this
device. If we can't detect this during runtime then there should be some
devicetree property for that. Making such decisions during compile time
is not an option in the days of multimachine kernels.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

i.MX6 USB OTG support is broken on linux-next

[Peter Chen]

 
> 
> On Sat, May 10, 2014 at 09:57:39PM +0800, Li Jun wrote:
> > On Sat, May 10, 2014 at 09:18:36PM +0800, Shawn Guo wrote:
> > > + Robin and David,
> > >
> > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> > > index cb8e991..9081757 100644
> > > --- a/drivers/usb/core/Kconfig
> > > +++ b/drivers/usb/core/Kconfig
> > > @@ -65,7 +65,6 @@ config USB_OTG
> > >  config USB_OTG_WHITELIST
> > >         bool "Rely on OTG Targeted Peripherals List"
> > >         depends on USB_OTG || EXPERT
> > > -       default y if USB_OTG
> > >         help
> > >           If you say Y here, the "otg_whitelist.h" file will be used
> as a
> > >           product whitelist, so USB peripherals not listed there will
> be
> > >
> > > Shawn
> > As Peter suggested, do not enable OTG_FSM in defconfig since there are
> very few
> > HNP&SRP capable device in market. With OTG_FSM enabled, even
> USB_OTG_WHITELIST
> > is not selected, the OTG port still can't work the same as before if
> you connect
> > a normal usb device to it.
> 
> If a device is not HNP/SRP capable then it should not be used on this
> device. If we can't detect this during runtime then there should be some
> devicetree property for that. Making such decisions during compile time
> is not an option in the days of multimachine kernels.
> 
> Sascha
> 

I don't think OTG option should be set for multi-machine kernel configurations,
the otg device will not be server, and it is a customized device (eg, the Targeted
Peripherals List need to be updated when it goes to be product).

Felipe, what's your opinion?

Peter

 

i.MX6 USB OTG support is broken on linux-next

[Sascha Hauer]

On Tue, May 13, 2014 at 12:33:30AM +0000, Peter Chen wrote:
>  
> > 
> > On Sat, May 10, 2014 at 09:57:39PM +0800, Li Jun wrote:
> > > On Sat, May 10, 2014 at 09:18:36PM +0800, Shawn Guo wrote:
> > > > + Robin and David,
> > > >
> > > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> > > > index cb8e991..9081757 100644
> > > > --- a/drivers/usb/core/Kconfig
> > > > +++ b/drivers/usb/core/Kconfig
> > > > @@ -65,7 +65,6 @@ config USB_OTG
> > > >  config USB_OTG_WHITELIST
> > > >         bool "Rely on OTG Targeted Peripherals List"
> > > >         depends on USB_OTG || EXPERT
> > > > -       default y if USB_OTG
> > > >         help
> > > >           If you say Y here, the "otg_whitelist.h" file will be used
> > as a
> > > >           product whitelist, so USB peripherals not listed there will
> > be
> > > >
> > > > Shawn
> > > As Peter suggested, do not enable OTG_FSM in defconfig since there are
> > very few
> > > HNP&SRP capable device in market. With OTG_FSM enabled, even
> > USB_OTG_WHITELIST
> > > is not selected, the OTG port still can't work the same as before if
> > you connect
> > > a normal usb device to it.
> > 
> > If a device is not HNP/SRP capable then it should not be used on this
> > device. If we can't detect this during runtime then there should be some
> > devicetree property for that. Making such decisions during compile time
> > is not an option in the days of multimachine kernels.
> > 
> > Sascha
> > 
> 
> I don't think OTG option should be set for multi-machine kernel configurations,
> the otg device will not be server, and it is a customized device (eg, the Targeted
> Peripherals List need to be updated when it goes to be product).

I want to enable OTG support when one of the devices I want to run the
kernel on is OTG capable. OTG is just a driver, there's no sane reason
to break stuff just because it's enabled in the config. We're long past
the point of single machine kernels.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

i.MX6 USB OTG support is broken on linux-next

[Peter Chen]

 
> 
> On Sat, May 10, 2014 at 07:10:05PM +0800, Peter Chen wrote:
> > On Fri, May 09, 2014 at 09:00:47PM +0800, Shawn Guo wrote:
> > > I'm running next-20140508 kernel on imx6q-sabresd board with USB
> > > mouse/keyboard connected to OTG port.  It  works well on 3.15-rc but
> > > is broken on recent linux-next kernel with the message like below.
> > >
> > > ...
> > > usb 1-1: device v413c p2107 is not supported
> > > hub 1-0:1.0: unable to enumerate USB device on port 1
> > >
> > > With the help from Peter, I found that the issue shows up only when
> > > CONFIG_USB_OTG_FSM is enabled.  The option is enabled by commit
> 8fd2f1f
> > > (ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host
> support.)
> > > from IMX tree.
> > >
> > > I guess this is a sign that chipidea otg_fsm driver is buggy?  I do
> not
> > > think dropping CONFIG_USB_OTG_FSM selection from imx_v6_v7_defconfig
> is
> > > a solution, and we need to fix the issue in usb driver, right?
> > >
> >
> > No, Shawn. The solution of this problem is drop CONFIG_USB_OTG_FSM, I
> > guess Denis added it wrongly.
> >
> > According to Embedded Hosts & OTG spec, OTG devices and Embedded Hosts
> > both have Targeted Host functionality, and each Targeted Host has
> > its TPL (Targeted Peripheral List), only the devices are at TPL
> > are supported by Targeted Host.
> >
> > Current Linux TPL only contains limited devices, each Targeted Host
> > needs to update its TPL when it makes product, (The comments at
> > otg_whitelist.h also mention it), and the devices are not at TPL
> > will not be supported, and will report to user as "an unsupported
> > device" error, at current Linux configuration, once the
> CONFIG_USB_OTG_FSM
> > and CONFIG_USB_OTG are chosen, the host will be Targeted Host.
> >
> > The reason why Shawn met this problem is: the imx_v6_v7_defconfig set
> > CONFIG_USB_OTG_FSM, so the CONFIG_USB_OTG and CONFIG_USB_OTG_WHITELIST
> > are set according to dependency, it makes imx6 device as Targeted Host,
> > but the devices connected at Shawn's board are not at TPL, so they are
> > not be supported.
> >
> > In a word the CONFIG_USB_OTG_FSM should not be chosen for
> > defauly kernel configuration. The CONFIG_USB_OTG_FSM should only be
> chosen
> > by default when this device goes to make product and the TPL is updated
> > accordingly.
> 
> Thanks for the explanation, Peter.
> 
> So this is what I see from USB Kconfig.
> 
> config USB_OTG_FSM
>         tristate "USB 2.0 OTG FSM implementation"
>         depends on USB
>         select USB_OTG
>         select USB_PHY
> 
> config USB_OTG_WHITELIST
>         bool "Rely on OTG Targeted Peripherals List"
>         depends on USB_OTG || EXPERT
>         default y if USB_OTG
> 
> I see that USB_OTG_FSM has a dependency on USB_OTG, and
> USB_OTG_WHITELIST depends on USB_OTG, but USB_OTG does *not* depends
> on USB_OTG_WHITELIST.
> 
> I'm not sure why we have 'default y if USB_OTG' for USB_OTG_WHITELIST,
> when this option only makes sense for product producers per your
> explanation.  So maybe dropping the 'default y' is the right fix?
> 

As I explained before: 
"OTG devices and Embedded Hosts both have Targeted Host functionality,
and each Targeted Host has its TPL (Targeted Peripheral List), only the 
devices are at TPL are supported by Targeted Host."

So when the board is OTG & EH (CONFIG_USB_OTG is set), it should
have TPL according to spec. In fact, even the CONFIG_USB_OTG_WHITELIST
is not set, the non-TPL devices have not worked well, eg, it will
not be enumerated again after it has disconnected from host 10 seconds
later due to vbus has turned off by host.

Peter

> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index cb8e991..9081757 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -65,7 +65,6 @@ config USB_OTG
>  config USB_OTG_WHITELIST
>         bool "Rely on OTG Targeted Peripherals List"
>         depends on USB_OTG || EXPERT
> -       default y if USB_OTG
>         help
>           If you say Y here, the "otg_whitelist.h" file will be used as a
>           product whitelist, so USB peripherals not listed there will be
> 
> Shawn

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

On Sun, May 11, 2014 at 08:40:25AM +0800, Chen Peter-B29397 wrote:
> As I explained before: 
> "OTG devices and Embedded Hosts both have Targeted Host functionality,
> and each Targeted Host has its TPL (Targeted Peripheral List), only the 
> devices are at TPL are supported by Targeted Host."
> 
> So when the board is OTG & EH (CONFIG_USB_OTG is set), it should
> have TPL according to spec. In fact, even the CONFIG_USB_OTG_WHITELIST
> is not set, the non-TPL devices have not worked well, eg, it will
> not be enumerated again after it has disconnected from host 10 seconds
> later due to vbus has turned off by host.

So all in all, it sounds to me that in my case, USB_OTG_FSM shouldn't be
set, neither in defconfig nor manually in menuconfig, right?

What about USB_OTG?  Can I set it in defconfig or manually in
menuconfig?

Shawn

i.MX6 USB OTG support is broken on linux-next

[Peter Chen]

 
> >
> > So when the board is OTG & EH (CONFIG_USB_OTG is set), it should have
> > TPL according to spec. In fact, even the CONFIG_USB_OTG_WHITELIST is
> > not set, the non-TPL devices have not worked well, eg, it will not be
> > enumerated again after it has disconnected from host 10 seconds later
> > due to vbus has turned off by host.
> 
> So all in all, it sounds to me that in my case, USB_OTG_FSM shouldn't be
> set, neither in defconfig nor manually in menuconfig, right?
> 
> What about USB_OTG?  Can I set it in defconfig or manually in menuconfig?
> 

In your case, you should not set CONFIG_USB_OTG no matter at defconfig
and at menuconfig.

Peter

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

On Mon, May 12, 2014 at 09:22:33AM +0800, Chen Peter-B29397 wrote:
>  
> > >
> > > So when the board is OTG & EH (CONFIG_USB_OTG is set), it should have
> > > TPL according to spec. In fact, even the CONFIG_USB_OTG_WHITELIST is
> > > not set, the non-TPL devices have not worked well, eg, it will not be
> > > enumerated again after it has disconnected from host 10 seconds later
> > > due to vbus has turned off by host.
> > 
> > So all in all, it sounds to me that in my case, USB_OTG_FSM shouldn't be
> > set, neither in defconfig nor manually in menuconfig, right?
> > 
> > What about USB_OTG?  Can I set it in defconfig or manually in menuconfig?
> > 
> 
> In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> and at menuconfig.

Hmm, at least in my testing (USB mouse/keyboard connected to OTG port),
it works as before even I enable CONFIG_USB_OTG, as long as I do *not*
enable CONFIG_USB_OTG_FSM.

Since it works for my case, I'm wondering why you think I shouldn't
enable CONFIG_USB_OTG at all.

Shawn

i.MX6 USB OTG support is broken on linux-next

[Peter Chen]

 
> > >
> >
> > In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> > and at menuconfig.
> 
> Hmm, at least in my testing (USB mouse/keyboard connected to OTG port),
> it works as before even I enable CONFIG_USB_OTG, as long as I do *not*
> enable CONFIG_USB_OTG_FSM.
> 
> Since it works for my case, I'm wondering why you think I shouldn't
> enable CONFIG_USB_OTG at all.
> 

If your device is not OTG device, there is no reason you need to enable
CONFIG_USB_OTG. Yes, it may work for some devices when enable CONFIG_USB_OTG,
but it will confuse other host or device which is connected with you, eg,
your device will report your have supported some otg capabilities, eg, SRP or
HNP.

Peter

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

On Tue, May 13, 2014 at 08:25:18AM +0800, Chen Peter-B29397 wrote:
>  
> > > >
> > >
> > > In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> > > and at menuconfig.
> > 
> > Hmm, at least in my testing (USB mouse/keyboard connected to OTG port),
> > it works as before even I enable CONFIG_USB_OTG, as long as I do *not*
> > enable CONFIG_USB_OTG_FSM.
> > 
> > Since it works for my case, I'm wondering why you think I shouldn't
> > enable CONFIG_USB_OTG at all.
> > 
> 
> If your device is not OTG device, there is no reason you need to enable
> CONFIG_USB_OTG.

Whether I should enable CONFIG_USB_OTG depends on what devices I will
use?  This is insane to me.

Look, there is an USB OTG port on my board, and it should just be the
reason that's good enough for me to build a kernel with CONFIG_USB_OTG,
shouldn't it?  I do not even know what type of devices will be plugged
into this USB OTG port when I was building the kernel.

Shawn

> Yes, it may work for some devices when enable CONFIG_USB_OTG,
> but it will confuse other host or device which is connected with you, eg,
> your device will report your have supported some otg capabilities, eg, SRP or
> HNP.

i.MX6 USB OTG support is broken on linux-next

[Li Jun]

On Tue, May 13, 2014 at 09:42:48AM +0800, Shawn Guo wrote:
> On Tue, May 13, 2014 at 08:25:18AM +0800, Chen Peter-B29397 wrote:
> >  
> > > > >
> > > >
> > > > In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> > > > and at menuconfig.
> > > 
> > > Hmm, at least in my testing (USB mouse/keyboard connected to OTG port),
> > > it works as before even I enable CONFIG_USB_OTG, as long as I do *not*
> > > enable CONFIG_USB_OTG_FSM.
> > > 
> > > Since it works for my case, I'm wondering why you think I shouldn't
> > > enable CONFIG_USB_OTG at all.
> > > 
> > 
> > If your device is not OTG device, there is no reason you need to enable
> > CONFIG_USB_OTG.
> 
> Whether I should enable CONFIG_USB_OTG depends on what devices I will
> use?  This is insane to me.
> 
> Look, there is an USB OTG port on my board, and it should just be the
> reason that's good enough for me to build a kernel with CONFIG_USB_OTG,
> shouldn't it?  I do not even know what type of devices will be plugged
> into this USB OTG port when I was building the kernel.
> 
> Shawn
> 

Firstly, w/o USB_OTG and USB_OTG_FSM, your OTG port will work well as before
(i.e. it can be host or can be gadget as you want, so it's enough for you if
connect normal usb device or PC host), I assume you are not wanting more here,
this dual role functionality actually is not the part of "CONFIG_USB_OTG";

What USB_OTG + USB_OTG_FSM does is *specific* for HNP and SRP, it's based on
OTG spec and will *not* work well with a normal usb device, that's the reason
behind in disable USB_OTG, which is not needed, and even impact your expecting
function in your case...

Li Jun

> > Yes, it may work for some devices when enable CONFIG_USB_OTG,
> > but it will confuse other host or device which is connected with you, eg,
> > your device will report your have supported some otg capabilities, eg, SRP or
> > HNP.

i.MX6 USB OTG support is broken on linux-next

[Shawn Guo]

On Tue, May 13, 2014 at 09:10:36AM +0800, Li Jun wrote:
> Firstly, w/o USB_OTG and USB_OTG_FSM, your OTG port will work well as before
> (i.e. it can be host or can be gadget as you want, so it's enough for you if
> connect normal usb device or PC host), I assume you are not wanting more here,
> this dual role functionality actually is not the part of "CONFIG_USB_OTG";

Okay, I think this is why I was confused.  Thanks for the clarification.

The problem is how people like me who does not know Linux USB too much
get that, considering what the help text of CONFIG_USB_OTG tells people
is just like below.

config USB_OTG
        bool "OTG support"
	...
        help
          The most notable feature of USB OTG is support for a
          "Dual-Role" device, which can act as either a device
          or a host. The initial role is decided by the type of
          plug inserted and can be changed later when two dual
          role devices talk to each other.

          Select this only if your board has Mini-AB/Micro-AB
          connector.

So the text tells CONFIG_USB_OTG is there for Dual-Role device support,
while you're saying the support is not the part of CONFIG_USB_OTG.  As a
person who never looked at usb code, I'm completely confused here.

> 
> What USB_OTG + USB_OTG_FSM does is *specific* for HNP and SRP, it's based on
> OTG spec and will *not* work well with a normal usb device, that's the reason
> behind in disable USB_OTG, which is not needed, and even impact your expecting
> function in your case...

Again, the help text of CONFIG_USB_OTG does *not* tell that.

Shawn

i.MX6 USB OTG support is broken on linux-next

[Peter Chen]

 
> >
> > > > >
> > > >
> > > > In your case, you should not set CONFIG_USB_OTG no matter at
> > > > defconfig and at menuconfig.
> > >
> > > Hmm, at least in my testing (USB mouse/keyboard connected to OTG
> > > port), it works as before even I enable CONFIG_USB_OTG, as long as I
> > > do *not* enable CONFIG_USB_OTG_FSM.
> > >
> > > Since it works for my case, I'm wondering why you think I shouldn't
> > > enable CONFIG_USB_OTG at all.
> > >
> >
> > If your device is not OTG device, there is no reason you need to
> > enable CONFIG_USB_OTG.
> 
> Whether I should enable CONFIG_USB_OTG depends on what devices I will use?
> This is insane to me.
> 

Sorry, here, your device = your board

> Look, there is an USB OTG port on my board, and it should just be the
> reason that's good enough for me to build a kernel with CONFIG_USB_OTG,
> shouldn't it?  I do not even know what type of devices will be plugged
> into this USB OTG port when I was building the kernel.
> 

There is NO term for "OTG port" at USB spec, it only has a term of "OTG device",
which means " Device that provides both host and peripheral capabilities
over a single Micro-AB receptacle". If your device is an "OTG device",
and supports role switch without disconnect your usb cable (HNP),
you should set CONFIG_USB_OTG.

Taking imx6 sabreSD board as an example, it is a Micro-B port.
>From what kinds of port (A or B), we don't know which capabilities your
device has, with different cables, you will get different functions.
Currently, the capabilities are decided by: controller capabilities (otg,
host/device-only, etc) and can be override by dts due to board design.
otg has special protocol and TPL requirements, it is decided by
kernel configuration.

The Kconfig description for USB_OTG is not very accurate, it should mention
the HNP and SRP supported are needed for that config, not just dual-role
switch through ID pin, I will submit a patch for that

Peter

> Shawn
> 
> > Yes, it may work for some devices when enable CONFIG_USB_OTG, but it
> > will confuse other host or device which is connected with you, eg,
> > your device will report your have supported some otg capabilities, eg,
> > SRP or HNP.