[U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Reported-by: Priit Laes plaes@plaes.org Reported-by: Jagan Teki jagan@amarulasolutions.com Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com Tested-by: Priit Laes plaes@plaes.org
---
build status available here: https://travis-ci.org/jjhiblot/u-boot/builds/470396811
drivers/usb/gadget/udc/Makefile | 3 ++- drivers/usb/gadget/udc/udc-uclass.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile index 38ac2dd..95dbf0c 100644 --- a/drivers/usb/gadget/udc/Makefile +++ b/drivers/usb/gadget/udc/Makefile @@ -6,4 +6,5 @@ ifndef CONFIG_$(SPL_)DM_USB_GADGET obj-$(CONFIG_USB_DWC3_GADGET) += udc-core.o endif
-obj-$(CONFIG_$(SPL_)DM_USB_GADGET) += udc-uclass.o udc-core.o +obj-$(CONFIG_$(SPL_)DM_USB_GADGET) += udc-core.o +obj-$(CONFIG_$(SPL_)DM) += udc-uclass.o diff --git a/drivers/usb/gadget/udc/udc-uclass.c b/drivers/usb/gadget/udc/udc-uclass.c index e9f8f5f..8d78647 100644 --- a/drivers/usb/gadget/udc/udc-uclass.c +++ b/drivers/usb/gadget/udc/udc-uclass.c @@ -9,6 +9,7 @@ #include <dm/device-internal.h> #include <linux/usb/gadget.h>
+#if CONFIG_IS_ENABLED(DM_USB_GADGET) #define MAX_UDC_DEVICES 4 static struct udevice *dev_array[MAX_UDC_DEVICES]; int usb_gadget_initialize(int index) @@ -51,6 +52,7 @@ int usb_gadget_handle_interrupts(int index) return -EINVAL; return dm_usb_gadget_handle_interrupts(dev_array[index]); } +#endif
UCLASS_DRIVER(usb_gadget_generic) = { .id = UCLASS_USB_GADGET_GENERIC,
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
Better to have proper commit head that tells the real issue.
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
Better to have proper commit head that tells the real issue.
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Any response on this?
We need the fix asap since the release is about a week.
On 12/29/18 7:49 PM, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
Better to have proper commit head that tells the real issue.
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Any response on this?
We need the fix asap since the release is about a week.
I suspect most people are having xmas vacation, so pushing hard won't help. It seems you had some comment on the patch, so I expect a reply from Jean and possibly a V2.
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
JJ
Any response on this?
We need the fix asap since the release is about a week.
On Wed, 2 Jan 2019 11:38:47 +0100 Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Thanks for a detailed explanation. Would you prepare v2 soon?
JJ
Any response on this?
We need the fix asap since the release is about a week.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On 02/01/2019 13:15, Lukasz Majewski wrote:
On Wed, 2 Jan 2019 11:38:47 +0100 Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Thanks for a detailed explanation. Would you prepare v2 soon?
Honestly I don't know what i would change in a v2.
JJ
Any response on this?
We need the fix asap since the release is about a week.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Hi Jagan,
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek), which also includes some other fixes.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On 1/3/19 7:59 AM, Lukasz Majewski wrote:
Hi Jagan,
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek), which also includes some other fixes.
Comment on what ? What do you need from me here ?
This is gadget code, which is not something I monitor closely.
On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski lukma@denx.de wrote:
Hi Jagan,
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for USB gadget devices")
The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be declared even for platforms that do not enable DM_USB_GADGET. Otherwise the driver for their usb peripheral controller fails to bind.
Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek), which also includes some other fixes.
Please don't miss this, sunxi need this fix.
On 1/3/19 8:53 PM, Jagan Teki wrote:
On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski lukma@denx.de wrote:
Hi Jagan,
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for > USB gadget devices") > > The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be > declared even for platforms that do not enable DM_USB_GADGET. > Otherwise the driver for their usb peripheral controller fails > to bind. Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek), which also includes some other fixes.
Please don't miss this, sunxi need this fix.
Absolutely, I have nothing else to do but to monitor this one single patch. Thanks for the pressure, it really helps.
On Fri, 4 Jan 2019 01:23:17 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski lukma@denx.de wrote:
Hi Jagan,
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote: Better to have proper commit head that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID > for USB gadget devices") > > The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to > be declared even for platforms that do not enable > DM_USB_GADGET. Otherwise the driver for their usb > peripheral controller fails to bind. Sorry this is unclear, you are trying to skip DM_USB_GADGET code even though UCLASS_USB_GADGET_GENERIC id used. does it make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek), which also includes some other fixes.
Please don't miss this, sunxi need this fix.
I'm now running build tests on this and Sam's patches. I will prepare PR and send it to Marek or Tom (if Marek is overloaded).
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On 1/3/19 10:47 PM, Lukasz Majewski wrote:
On Fri, 4 Jan 2019 01:23:17 +0530 Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski lukma@denx.de wrote:
Hi Jagan,
On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot jjhiblot@ti.com wrote:
On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki jagan@amarulasolutions.com wrote: > On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot > jjhiblot@ti.com wrote: Better to have proper commit head > that tells the real issue.
I found it hard to come up with a short description of the real issue.
At least this title makes it clear that it is a regression fix, not a new feature.
The details of the failures are in the commit log (or so I thought)
> >> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID >> for USB gadget devices") >> >> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to >> be declared even for platforms that do not enable >> DM_USB_GADGET. Otherwise the driver for their usb >> peripheral controller fails to bind. > Sorry this is unclear, you are trying to skip DM_USB_GADGET > code even though UCLASS_USB_GADGET_GENERIC id used. does it > make sense?
Sorry for the delay. This was indeed a vacation time.
This patch does not skip DM_USB_GADGET. What it does is declare the UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is not set.
DM_USB_GADGET is a new option and not (yet) widely used and some drivers have their own version of the DM support for gadget drivers (ie they implement their own version of usb_gadget_initialize(), usb_gadget_release() and usb_gadget_handle_interrupts()). However all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared. In the past they used UCLASS_USB_DEV_GENERIC, but this option is intended for the host side.
Acked-by: Jagan Teki jagan@openedev.com
Marek, any comments?
Yes, lets wait for Marek's comment and I will prepare PR (to Marek), which also includes some other fixes.
Please don't miss this, sunxi need this fix.
I'm now running build tests on this and Sam's patches. I will prepare PR and send it to Marek or Tom (if Marek is overloaded).
It is still unclear what you wanted me to comment on.
And you know where to send the PR - u-boot-usb.
participants (4)
-
Jagan Teki -
Jean-Jacques Hiblot -
Lukasz Majewski -
Marek Vasut