lkml.org 
[lkml]   [2019]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: linux-next: build failure after merge of the usb and usb-gadget trees
    Date
    >>
    >>
    >>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

    \
     
     \ /
      Last update: 2019-07-04 11:25    [W:4.368 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site