On 04/07/19 1:55 PM, 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?
I just checked back to see what happened here. In our product kernel
(which does undergo build test with multiple defconfigs), we are using
v6 of these patches which did not have this issue.
I think 0-day kbuild tester could have caught the issue as well. Within
boundaries of existing infrastructure, that probably was the best bet
here. Not sure why that did not happen (probably just build scheduling).
Thanks,
Sekhar
