From patchwork Tue Jun 14 15:33:32 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Arnaud Lacombe X-Patchwork-Id: 879312 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5EFXY1J013449 for ; Tue, 14 Jun 2011 15:33:35 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753152Ab1FNPde (ORCPT ); Tue, 14 Jun 2011 11:33:34 -0400 Received: from mail-pv0-f174.google.com ([74.125.83.174]:43221 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752000Ab1FNPdd convert rfc822-to-8bit (ORCPT ); Tue, 14 Jun 2011 11:33:33 -0400 Received: by pvg12 with SMTP id 12so2676667pvg.19 for ; Tue, 14 Jun 2011 08:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=00jB9ulxsHRfLWTFrD9La+tCp5oFVBFO36WNx11rJLc=; b=pVTSWl1Pcy214h1p1sMlCZGZH2CB4wLw9JuFM7y1PP2iI2Rsa8i57zI4yrGkRqYx3Q oYr0E+WEjzRy7wMsx389dv7VvH+mC8lr9fb3Wi6EjOYmtXyIFSEvat9ig82l1ixDSTdB lqGGu50YICH5k3OXcNpCzgtjLizsWofW13yYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RiZ+D1Lcs7ARqtBQpIfVxylA3Oq/fFmSZnVaDj4Ruw8vy6BTQdy/iV+1nbYSeFnfXa 0Pq1RuiR7q14DlJLs7eNYla4O8Fw4dMdsbkMdQJ9g8tES2prRQ2tgfaHbQE098Z+JUrI /eN9vWAcEEF59INVHM9r95O5a7EB/JJJMr0Tg= MIME-Version: 1.0 Received: by 10.68.22.198 with SMTP id g6mr2950358pbf.218.1308065612532; Tue, 14 Jun 2011 08:33:32 -0700 (PDT) Received: by 10.68.56.8 with HTTP; Tue, 14 Jun 2011 08:33:32 -0700 (PDT) In-Reply-To: <20110614073218.GR2353@legolas.emea.dhcp.ti.com> References: <20110613085534.GD3633@legolas.emea.dhcp.ti.com> <20110613153516.GC2353@legolas.emea.dhcp.ti.com> <20110614073218.GR2353@legolas.emea.dhcp.ti.com> Date: Tue, 14 Jun 2011 11:33:32 -0400 Message-ID: Subject: Re: generate one module from multiple object files (was: Re: [PATCH 2/2] usb: gadget: convert all users to the new udc) From: Arnaud Lacombe To: balbi@ti.com Cc: Michal Nazarewicz , Alan Stern , Sebastian Andrzej Siewior , Greg KH , Linux USB Mailing List , linux-kbuild@vger.kernel.org Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Tue, 14 Jun 2011 15:33:35 +0000 (UTC) Hi, On Tue, Jun 14, 2011 at 3:32 AM, Felipe Balbi wrote: > On Tue, Jun 14, 2011 at 08:28:05AM +0200, Michal Nazarewicz wrote: >> On Mon, 13 Jun 2011 17:35:17 +0200, Felipe Balbi wrote: >> >We also need to a find a better way to get rid of the inclusion of C >> >source files. I understand why Dave did it, but it's been quite some >> >time since those patches were committed - e.g. >> >7e75bc0f9006e995a0fa25f0a285addc3d5fd5cb - and no progress has been made >> >to fix that up. Probably Clang's link-time optimization would help a lot >> >on that, but Clang still needs quite some work to be usable for us, so >> >we need something else. Any ideas ? >> >> To me it always seemed like it's a bug in/lack of feature of Kbuild. >> Would making Kbuild allow building module from separate .o files be >> a problem? > > maybe the guys at linux-kbuild@vger can help answering this. > What is the problem exactly ? The following patch: if (gadget_is_otg(cdev->gadget)) { Thanks, - Arnaud >> Also, at one point in time I had an idea of a framework in which each >> individual composite function would be a separate module.  I haven't >> thought it through though so it's probably not such a great idea after >> all. ;) > > such a framework won't work for Certification. The original composite > framework that I implemented with the guidance of Dave was doing exactly > that. Each function driver was a module of its own and you built > composite gadgets by loading the different drivers. > > That was until Dave explained to me why it wouldn't fly. You can't have > completely dynamic USB peripherals. If you go to certification with > something like that, you will be denied certification as your device can > change how it appears to the bus at any time. > > So, the way we have things now, is good. We just need to figure out a > way to avoid the inclusion of C files. > > -- > balbi > --- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 4fe92b1..cc432b8 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,6 +34,12 @@ obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o # USB gadget drivers # g_zero-y := zero.o +g_zero-y += composite.o +g_zero-y += usbstring.o +g_zero-y += config.o +g_zero-y += epautoconf.o +g_zero-y += f_sourcesink.o +g_zero-y += f_loopback.o g_audio-y := audio.o g_ether-y := ether.o g_serial-y := serial.o diff --git a/drivers/usb/gadget/zero.c b/drivers/usb/gadget/zero.c index 6d16db9..9e74d8f 100644 --- a/drivers/usb/gadget/zero.c +++ b/drivers/usb/gadget/zero.c @@ -60,23 +60,6 @@ /*-------------------------------------------------------------------------*/ -/* - * Kbuild is not very cooperative with respect to linking separately - * compiled library objects into one module. So for now we won't use - * separate compilation ... ensuring init/exit sections work to shrink - * the runtime footprint, and giving us at least some parts of what - * a "gcc --combine ... part1.c part2.c part3.c ... " build would. - */ -#include "composite.c" -#include "usbstring.c" -#include "config.c" -#include "epautoconf.c" - -#include "f_sourcesink.c" -#include "f_loopback.c" - -/*-------------------------------------------------------------------------*/ - #define DRIVER_VERSION "Cinco de Mayo 2008" static const char longname[] = "Gadget Zero"; build fine for me with CONFIG_USB_ZERO=[ym], beside an obvious visibility issue: diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c index b37960f..2300a3d 100644 --- a/drivers/usb/gadget/f_loopback.c +++ b/drivers/usb/gadget/f_loopback.c @@ -372,8 +372,8 @@ int __init loopback_add(struct usb_composite_dev *cdev, bool autoresume) loopback_driver.iConfiguration = id; /* support autoresume for remote wakeup testing */ - if (autoresume) - sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP; +// if (autoresume) +// sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP; /* support OTG systems */