RE: linux-next: build failure after merge of the usb and usb-gadget trees

[Pawel Laszczak <pawell@cadence.com>]

>>
>>
>>Hi,
>>
>>Pawel Laszczak <pawell@cadence.com> writes:
>>
>>>>
>>>>Hi,
>>>>
>>>>On Thu, Jul 4, 2019 at 9:59 AM Greg KH <greg@kroah.com> 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.
>

I think that the best choice is leaving debug.c file 
In drivers/usb/gadget/ directory. 

But to do this I must to add this file to drivers/usb/dwc3/Makefile file and 
drivers/usb/cdns3/Makefile. The code will be compiled into both drivers,
It will increase the size of kernel only when these driver will be enabled.

What do you think about such solution ? 

>>
>>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