>
>
>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.
Some time ago Greg wrote:
" It's nice to have these in a common place, but you just bloated all of
the USB-enabled systems in the world for the use of 2 odd-ball system
controllers that almost no one has :) "
So I moved these functions to gadget directory.
It was mistake that I added debug.c file to libcomposite.ko.
>
>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
