[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <508906CE02000078000A4553@nat28.tlf.novell.com>
Date: Thu, 25 Oct 2012 08:30:54 +0100
From: "Jan Beulich" <JBeulich@...e.com>
To: "Stefano Stabellini" <stefano.stabellini@...citrix.com>,
<gregkh@...uxfoundation.org>,
"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
"Randy Dunlap" <rdunlap@...otime.net>
Cc: "Stephen Rothwell" <sfr@...b.auug.org.au>,
"Jeremy Fitzhardinge" <jeremy@...p.org>,
<virtualization@...ts.linux-foundation.org>,
"xen-devel" <xen-devel@...ts.xen.org>,
<linux-kernel@...r.kernel.org>, <linux-next@...r.kernel.org>
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
>>> On 24.10.12 at 23:33, Randy Dunlap <rdunlap@...otime.net> wrote:
> On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 201201023:
>>
>
> on x86_64:
>
> drivers/built-in.o: In function `dbgp_reset_prep':
> (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
>
>
> Full randconfig file is attached.
So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
dbgp_reset_prep() and dbgp_external_startup() get pointlessly
defined and exported. This got broken by the merge
recommendation for the ARM side changes (originally compilation
of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
>From my pov, fixing the USB side would be the clean solution (i.e.
putting those function definitions inside a CONFIG_USB_SUPPORT
conditional).
The alternative of a smaller change would be to extend the
conditional around the respective xen_dbgp_...() declarations
in include/linux/usb/ehci_def.h to become
#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
Please advise towards your preference.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists