On Thu, Jul 04, 2019 at 11:45:11AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Greg KH <greg@xxxxxxxxx> writes:
>
> > On Thu, Jul 04, 2019 at 11:25:16AM +0300, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Pawel Laszczak <pawell@xxxxxxxxxxx> writes:
> >>
> >> >>
> >> >>Hi,
> >> >>
> >> >>On Thu, Jul 4, 2019 at 9:59 AM Greg KH <greg@xxxxxxxxx> wrote:
> >> >>>
> >> >>> On Thu, Jul 04, 2019 at 04:34:58PM +1000, Stephen Rothwell wrote:
> >> >>> > Hi all,
> >> >>> >
> >> >>> > After merging the usb tree, today's linux-next build (arm
> >> >>> > multi_v7_defconfig) failed like this:
> >> >>> >
> >> >>> > arm-linux-gnueabi-ld: drivers/usb/dwc3/trace.o: in function `trace_raw_output_dwc3_log_ctrl':
> >> >>> > trace.c:(.text+0x119c): undefined reference to `usb_decode_ctrl'
> >> >>> >
> >> >>> > Caused by commit
> >> >>> >
> >> >>> > 3db1b636c07e ("usb:gadget Separated decoding functions from dwc3 driver.")
> >> >>> >
> >> >>> > I have used the usb tree from next-20190703 for today.
> >> >>> >
> >> >>> > This also occurs in the usb-gadget tree so I have used the version of
> >> >>> > that from next-20190703 as well.
> >> >>>
> >> >>> Odd, I thought I pulled the usb-gadget tree into mine. Felipe, can you
> >> >>> take a look at this to see if I messed something up?
> >> >>
> >> >>This looks like it was caused by Pawel's patches.
> >> >>
> >> >>I'll try to reproduce here and see what's causing it.
> >> >
> >> > Problem is in my Patch. I reproduced it, but I don't understand why compiler
> >> > complains about usb_decode_ctrl. It's compiled into libcomposite.ko and
> >> > declaration is in drivers/usb/gadget.h.
> >>
> >> That's because in multi_v7_defconfig dwc3 is built-in while libcomposite
> >> is a module:
> >>
> >> CONFIG_USB_DWC3=y
> >> CONFIG_USB_LIBCOMPOSITE=m
> >>
> >>
> >> I remember that when you were doing this work, I asked you to move
> >> functions to usb/common. Why did you deviate from that suggestion? It's
> >> clear that decoding a ctrl request can be used by peripheral and host
> >> and we wouldn't have to deal with this problem if you had just followed
> >> the suggestion.
> >>
> >> Now we have to come up with a way to fix this that doesn't involve
> >> reverting my part2 tag in its entirety because there are other important
> >> things there.
> >>
> >> This is what I get for trusting people to do their part. I couldn't even
> >> compile test this since I don't have ARM compilers anymore (actually,
> >> just installed to test). Your customer, however, uses ARM cores so I
> >> would expect you to have at least compile tested this on ARM. How come
> >> this wasn't verified by anybody at TI?
> >>
> >> TI used to have automated testing for many of the important defconfigs,
> >> is that completely gone? Are you guys relying entirely on linux-next?
> >>
> >> Greg, if you prefer, please revert my part2 tag. If you do so, please
> >> let me know so I can drop the tag and commits from my tree as well.
> >
> > How do I revert a tag? How about I just revert individual commits,
> > which ones should I revert?
>
> Anything from Pawel. Here's the full list:
>
> 573aff747ee3 usb:cdns3 Fix for stuck packets in on-chip OUT buffer.
> 8bc1901ca7b0 usb:cdns3 Add Cadence USB3 DRD Driver
> c2af6b07803e usb:gadget Simplify usb_decode_get_set_descriptor function.
> ca888ce7495e usb:gadget Patch simplify usb_decode_set_clear_feature function.
> 3db1b636c07e usb:gadget Separated decoding functions from dwc3 driver.
> e8a8b40cc892 dt-bindings: add binding for USBSS-DRD controller.
>
> I just tested a branch without these patches and it builds fine:
>
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- multi_v7_defconfig
> HOSTCC scripts/kconfig/conf.o
> HOSTCC scripts/kconfig/confdata.o
> HOSTCC scripts/kconfig/expr.o
> HOSTCC scripts/kconfig/lexer.lex.o
> HOSTCC scripts/kconfig/parser.tab.o
> HOSTCC scripts/kconfig/preprocess.o
> HOSTCC scripts/kconfig/symbol.o
> HOSTLD scripts/kconfig/conf
> #
> # configuration written to .config
> #
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j32 -s
> $
All now reverted.
When these are resent, I want to review them as well as I thought the
cdns3 driver still needed work before it could be merged...
thanks,
greg k-h
