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

Felipe Balbi
2019-07-04T09:45:14Z

Hi,

Pawel Laszczak <pawell@cadence.com> writes:

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

Frankly, I think it's not a solution :-)

If we _must_ keep it under drivers/usb/gadget, then we need to find a
way to build this so that if any user is built-in, that file has to be
built-in as well.

--
balbi