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.