lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 04 Jul 2019 12:45:09 +0300
From:   Felipe Balbi <>
To:     Pawel Laszczak <>, Greg KH <>
Cc:     Stephen Rothwell <>,
        Linux Next Mailing List <>,
        Linux Kernel Mailing List <>,
        "linux-usb\" <>,
        Roger Quadros <>, Nishanth Menon <>
Subject: RE: linux-next: build failure after merge of the usb and usb-gadget trees


Pawel Laszczak <> writes:

>>>Pawel Laszczak <> writes:
>>>>>On Thu, Jul 4, 2019 at 9:59 AM Greg KH <> 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:
>>>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.


Powered by blists - more mailing lists