| Message ID | 1545382221-21788-1-git-send-email-jjhiblot@ti.com |
|---|---|
| State | Accepted |
| Commit | b3c518a88278619b1e109de114c450237d03e032 |
| Delegated to: | Lukasz Majewski |
| Headers | show |
| Series | [U-Boot] dm: usb: gadget: Fix boot breakage on sunxi platforms | expand |
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.
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,
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(-)