On 29/12/2018 19:49, Jagan Teki wrote:
On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki <ja...@amarulasolutions.com> wrote:
On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot <jjhib...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
