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.
Pawel, please make sure this never happens again. It's pretty simple to
avoid this sort of thing. I'll keep ARM compiler installed for
build-testing as well.
--
balbi
