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

DISCUSSION Shawn Guo 4 participants 17 messages May 9, 2014 – May 13, 2014 USB

Share & tools

Shawn Guo

author

2014-05-09 13:00 UTC #0 lore raw

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

Peter Chen

2014-05-10 11:10 UTC #1 lore raw

Quoted 8 lines · 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

Quoted 9 lines

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

Shawn Guo

author

2014-05-10 13:18 UTC #2 lore raw

+ Robin and David,

Quoted 40 lines · Peter Chen

Quoted 8 lines · 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
Quoted 9 lines
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.

Quoted 4 lines

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?

drivers/usb/core/Kconfig +0 -1

index cb8e991..9081757 100644
@@ -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

Li Jun

2014-05-10 13:57 UTC #3 lore raw

Quoted 84 lines · Shawn Guo

+ Robin and David,
Quoted 40 lines · Peter Chen
Quoted 8 lines · 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
Quoted 9 lines
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.
Quoted 4 lines
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?
drivers/usb/core/Kconfig +0 -1
index cb8e991..9081757 100644
@@ -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

Quoted 1 line

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

Peter Chen

2014-05-11 00:40 UTC #8 lore raw

In reply to Shawn Guo

Quoted 69 lines · Peter Chen

Quoted 11 lines · Shawn Guo
Quoted 10 lines
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
Quoted 1 line
Quoted 1 line
(ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host
support.)
Quoted 3 lines
Quoted 3 lines
from IMX tree.
I guess this is a sign that chipidea otg_fsm driver is buggy? I do
not
Quoted 1 line
Quoted 1 line
think dropping CONFIG_USB_OTG_FSM selection from imx_v6_v7_defconfig
is
Quoted 11 lines
Quoted 2 lines
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.
Quoted 5 lines
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
Quoted 10 lines
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
Quoted 2 lines
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

Quoted 8 lines

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

Quoted 14 lines

drivers/usb/core/Kconfig +0 -1

index cb8e991..9081757 100644
@@ -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

Shawn Guo

author

2014-05-11 01:34 UTC #4 lore raw

In reply to Li Jun

Quoted 4 lines · Li Jun

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

Shawn Guo

author

2014-05-11 01:40 UTC #9 lore raw

In reply to Peter Chen

Quoted 10 lines · 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

Peter Chen

2014-05-12 01:22 UTC #10 lore raw

Quoted 8 lines

Quoted 7 lines
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.

Quoted 5 lines

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

Sascha Hauer

2014-05-12 05:45 UTC #5 lore raw

In reply to Li Jun

Quoted 16 lines · Li Jun

Quoted 15 lines · Shawn Guo

+ Robin and David,

drivers/usb/core/Kconfig +0 -1

index cb8e991..9081757 100644
@@ -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

Quoted 5 lines

Quoted 1 line
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

Signature · 4 lines

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 |

Shawn Guo

author

2014-05-12 13:54 UTC #11 lore raw

In reply to Peter Chen

Quoted 8 lines · On Mon, May 12, 2014 at 09:22:33AM +0800, Chen Peter-B29397 wrote:

Quoted 8 lines
Quoted 7 lines
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.

Quoted 8 lines

Quoted 5 lines
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

Peter Chen

2014-05-13 00:25 UTC #12 lore raw

Quoted 6 lines

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

Quoted 7 lines

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

Peter Chen

2014-05-13 00:33 UTC #6 lore raw

In reply to Sascha Hauer

Quoted 28 lines · Li Jun

Quoted 14 lines · Shawn Guo
drivers/usb/core/Kconfig config USB_OTG · line 69
Quoted 13 lines
+ Robin and David,
drivers/usb/core/Kconfig +0 -1
index cb8e991..9081757 100644
@@ -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
Quoted 1 line
drivers/usb/core/Kconfig config USB_OTG · line 70
Quoted 1 line
drivers/usb/core/Kconfig +0 -0
          product whitelist, so USB peripherals not listed there will
be
Quoted 3 lines
Quoted 2 lines
Shawn
As Peter suggested, do not enable OTG_FSM in defconfig since there are
very few
Quoted 1 line
HNP&SRP capable device in market. With OTG_FSM enabled, even
USB_OTG_WHITELIST
Quoted 1 line
is not selected, the OTG port still can't work the same as before if
you connect

Quoted 9 lines

Quoted 1 line
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

Li Jun

2014-05-13 01:10 UTC #14 lore raw

In reply to Shawn Guo

Quoted 21 lines · Shawn Guo

Quoted 10 lines · On Tue, May 13, 2014 at 08:25:18AM +0800, Chen Peter-B29397 wrote:
Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.

Quoted 7 lines

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

Quoted 4 lines

Quoted 4 lines
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.

Shawn Guo

author

2014-05-13 01:42 UTC #13 lore raw

In reply to Peter Chen

Quoted 10 lines · On Tue, May 13, 2014 at 08:25:18AM +0800, Chen Peter-B29397 wrote:

Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
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

Quoted 4 lines

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 Chen

2014-05-13 02:40 UTC #16 lore raw

Quoted 15 lines

Quoted 15 lines
Quoted 14 lines
Quoted 6 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 2 lines
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

Quoted 5 lines

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.

Quoted 1 line

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

Quoted 6 lines

Shawn
Quoted 4 lines
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.

Shawn Guo

author

2014-05-13 02:40 UTC #15 lore raw

In reply to Li Jun

Quoted 4 lines · Li Jun

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.

Quoted 5 lines

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

Sascha Hauer

2014-05-13 05:48 UTC #7 lore raw

In reply to Peter Chen

Quoted 35 lines · Peter Chen

Quoted 35 lines · Li Jun
Quoted 14 lines · Shawn Guo
drivers/usb/core/Kconfig config USB_OTG · line 69
Quoted 13 lines
+ Robin and David,
drivers/usb/core/Kconfig +0 -1
index cb8e991..9081757 100644
@@ -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
Quoted 1 line
drivers/usb/core/Kconfig config USB_OTG · line 70
Quoted 1 line
drivers/usb/core/Kconfig +0 -0
          product whitelist, so USB peripherals not listed there will
be
Quoted 3 lines
Quoted 2 lines
Shawn
As Peter suggested, do not enable OTG_FSM in defconfig since there are
very few
Quoted 1 line
HNP&SRP capable device in market. With OTG_FSM enabled, even
USB_OTG_WHITELIST
Quoted 1 line
is not selected, the OTG port still can't work the same as before if
you connect
Quoted 1 line
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.

Quoted 6 lines

Quoted 2 lines
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

Signature · 4 lines

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 |