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