| Message ID | 20140510131815.GT2794@dragon (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
> > 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
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
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
> > > > 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
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
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
> > > > > > > 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
> > 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
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.
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.
> > > > > > > > > > > > > > > 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.
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
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
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