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

[Greg KH <greg@kroah.com>]

On Thu, Jul 04, 2019 at 11:25:16AM +0300, Felipe Balbi wrote:
> 
> 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.
> 
> 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.

How do I revert a tag?  How about I just revert individual commits,
which ones should I revert?

thanks,

greg k-h