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

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <BYAPR07MB4709344EED0561D7F4DD879FDDF50@BYAPR07MB4709.namprd07.prod.outlook.com>
Date:   Fri, 5 Jul 2019 04:42:57 +0000
From:   Pawel Laszczak <pawell@...ence.com>
To:     Felipe Balbi <balbi@...nel.org>, Greg KH <greg@...ah.com>
CC:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        Roger Quadros <rogerq@...com>, Nishanth Menon <nm@...com>
Subject: RE: linux-next: build failure after merge of the usb and usb-gadget
 trees

Hi,
>
>Hi,
>
>Greg KH <greg@...ah.com> writes:
>
>> On Thu, Jul 04, 2019 at 12:44:08PM +0300, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Pawel Laszczak <pawell@...ence.com> writes:
>>>
>>> >>
>>> >>
>>> >>Hi,
>>> >>
>>> >>Pawel Laszczak <pawell@...ence.com> writes:
>>> >>
>>> >>>>
>>> >>>>Hi,
>>> >>>>
>>> >>>>On Thu, Jul 4, 2019 at 9:59 AM Greg KH <greg@...ah.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.
>>>
>>> The plan is to use this decoding function for xHCI as well. Other host
>>> controllers can use it as well.
>>>
>>> The biggest mistake was to put this under gadget. What you should have
>>> done was create a file under usb/common that only gets compile in if
>>> tracing is enabled.
>>>
>>> Then there's no bloating unless you have a kernel purposefuly built for
>>> debugging and tracing.
>>>
>>> Greg, does that work for you?
>>
>> I guess, but I'd like to see patches before answering that :)
>
>Sure, understandable. I should've done a better job at filtering that
>out. Sorry about htat

I will return debug.c again to usb/common directory. 
I made it as suggested by Felipe.
I will try correct this patches on Monday. 

I apologize for my mistake and for wasting your time.

Regards,
Pawel.