From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 094B1C06513 for ; Thu, 4 Jul 2019 09:44:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D207121852 for ; Thu, 4 Jul 2019 09:44:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562233454; bh=W+QdRzxJg0RWKs1MQOT4SIh10aJux9qHAx+nn/mR42s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:List-ID:From; b=feT5k3wdXzAqJA2qKH89NhCjFHIU+Qg2B7XkKap1oKYxCdnM/6DYD1cnZu+ncfXDc j0OQiKAfw15TO3Fg5iGz+NNX2KEdWkh7SrJAeGj6hScL43L5r8yv5z7qewDCJRxYII /o/jfJqmr5q8Lp4H1kqrC5Y8yd8BQ5CbDxfo02mY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727479AbfGDJoN (ORCPT ); Thu, 4 Jul 2019 05:44:13 -0400 Received: from mga12.intel.com ([192.55.52.136]:46969 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727349AbfGDJoN (ORCPT ); Thu, 4 Jul 2019 05:44:13 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2019 02:44:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,450,1557212400"; d="scan'208";a="166789157" Received: from pipin.fi.intel.com (HELO pipin) ([10.237.72.175]) by orsmga003.jf.intel.com with ESMTP; 04 Jul 2019 02:44:09 -0700 From: Felipe Balbi To: Pawel Laszczak , Greg KH Cc: Stephen Rothwell , Linux Next Mailing List , Linux Kernel Mailing List , "linux-usb\@vger.kernel.org" , Roger Quadros , Nishanth Menon Subject: RE: linux-next: build failure after merge of the usb and usb-gadget trees In-Reply-To: References: <20190704163458.63ed69d2@canb.auug.org.au> <20190704065949.GA32707@kroah.com> <87imsiyzo3.fsf@linux.intel.com> Date: Thu, 04 Jul 2019 12:44:08 +0300 Message-ID: <877e8y6snr.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Pawel Laszczak writes: >> >> >>Hi, >> >>Pawel Laszczak writes: >> >>>> >>>>Hi, >>>> >>>>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: >> >>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? -- balbi