* Re: linux-next: manual merge of the usb tree with the trivial tree
From: Greg KH @ 2010-10-06 3:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Joe Perches, Jiri Kosina,
Sergei Shtylyov, Felipe Balbi
In-Reply-To: <20101006141414.abf7431f.sfr@canb.auug.org.au>
On Wed, Oct 06, 2010 at 02:14:14PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/musb/musb_gadget.c between commit
> 7f26b3a7533bbc1ddd88b297c935ee4da8f74cea ("drivers/usb: Remove
> unnecessary return's from void functions") from the trivial tree and
> commit 82cccbf2458e50dabf8b9946b3f0ef0e8d31711f ("usb: musb: gadget: kill
> unreachable code in musb_g_rx()") from the usb tree.
>
> The latter also fixes the problem fixed in the former, so I just used the
> latter.
That sounds great, thanks for doing this.
greg k-h
^ permalink raw reply
* linux-next: manual merge of the staging-next tree with the omap tree
From: Stephen Rothwell @ 2010-10-06 3:21 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Charulatha V, Felipe Contreras,
Tony Lindgren, linux-omap
Hi Greg,
Today's linux-next merge of the staging-next tree got a conflict in
arch/arm/plat-omap/devices.c between commit
f2ce62312650211f6cf665cd6dc519c334c4071e ("OMAP: WDT: Split OMAP1 and
OMAP2PLUS device registration") from the omap tree and commit
90173882ed15a8034d6d162da5f343a2c7d87587 ("omap: add dsp platform
device") from the staging-next tree.
Just overlapping removal/additions (I think). I fixed it up (see below)
and can carry the changes as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/plat-omap/devices.c
index 1e2383e,4c8f9b9..0000000
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@@ -231,6 -233,75 +232,35 @@@ static void omap_init_uwire(void
static inline void omap_init_uwire(void) {}
#endif
-/*-------------------------------------------------------------------------*/
-
-#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-
-static struct resource wdt_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap_wdt_device = {
- .name = "omap_wdt",
- .id = -1,
- .num_resources = ARRAY_SIZE(wdt_resources),
- .resource = wdt_resources,
-};
-
-static void omap_init_wdt(void)
-{
- if (cpu_is_omap16xx())
- wdt_resources[0].start = 0xfffeb000;
- else if (cpu_is_omap2420())
- wdt_resources[0].start = 0x48022000; /* WDT2 */
- else if (cpu_is_omap2430())
- wdt_resources[0].start = 0x49016000; /* WDT2 */
- else if (cpu_is_omap343x())
- wdt_resources[0].start = 0x48314000; /* WDT2 */
- else if (cpu_is_omap44xx())
- wdt_resources[0].start = 0x4a314000;
- else
- return;
-
- wdt_resources[0].end = wdt_resources[0].start + 0x4f;
-
- (void) platform_device_register(&omap_wdt_device);
-}
-#else
-static inline void omap_init_wdt(void) {}
-#endif
-
+ #if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+
+ static phys_addr_t omap_dsp_phys_mempool_base;
+
+ void __init omap_dsp_reserve_sdram_memblock(void)
+ {
+ phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
+ if (!paddr) {
+ pr_err("%s: failed to reserve %x bytes\n",
+ __func__, size);
+ return;
+ }
+
+ omap_dsp_phys_mempool_base = paddr;
+ }
+
+ phys_addr_t omap_dsp_get_mempool_base(void)
+ {
+ return omap_dsp_phys_mempool_base;
+ }
+ EXPORT_SYMBOL(omap_dsp_get_mempool_base);
+ #endif
+
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
^ permalink raw reply
* linux-next: manual merge of the usb tree with the trivial tree
From: Stephen Rothwell @ 2010-10-06 3:14 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Joe Perches, Jiri Kosina,
Sergei Shtylyov, Felipe Balbi
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/musb/musb_gadget.c between commit
7f26b3a7533bbc1ddd88b297c935ee4da8f74cea ("drivers/usb: Remove
unnecessary return's from void functions") from the trivial tree and
commit 82cccbf2458e50dabf8b9946b3f0ef0e8d31711f ("usb: musb: gadget: kill
unreachable code in musb_g_rx()") from the usb tree.
The latter also fixes the problem fixed in the former, so I just used the
latter.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the tip tree with Linus' tree
From: Stephen Rothwell @ 2010-10-06 2:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Linus Torvalds, Jason Baron
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/module.c between commit
5336377d6225959624146629ce3fc88ee8ecda3d ("modules: Fix module_bug_list
list corruption race") from Linus' tree and commit
d9f5ab7b1c0a520867af389bab5d5fcdbd0e407e ("jump label: x86 support") from
the tip tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/kernel/module.c
index 1c355c5,5399f58..0000000
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@@ -239,7 -239,10 +239,10 @@@ int module_finalize(const Elf_Ehdr *hdr
apply_paravirt(pseg, pseg + para->sh_size);
}
+ /* make jump label nops */
+ jump_label_apply_nops(me);
+
- return module_bug_finalize(hdr, sechdrs, me);
+ return 0;
}
void module_arch_cleanup(struct module *mod)
^ permalink raw reply
* linux-next: manual merge of the rcu tree with Linus' tree
From: Stephen Rothwell @ 2010-10-06 2:38 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: linux-next, linux-kernel, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in
include/linux/rcupdate.h between commit
b3a084b9b684622b149e8dcf03855bf0d5fb588b ("rcu: rcu_read_lock_bh_held():
disabling irqs also disables bh") from Linus' tree and commit
ca5ecddfa8fcbd948c95530e7e817cee9fb43a3d ("rcu: define __rcu address
space modifier for sparse") from the rcu tree.
I am not sure how to fix this, so I just used the version from the rcu
tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the kgdb tree with the input tree
From: Stephen Rothwell @ 2010-10-06 2:04 UTC (permalink / raw)
To: Jason Wessel; +Cc: linux-next, linux-kernel, Dmitry Torokhov
Hi Jason,
Today's linux-next merge of the kgdb tree got a conflict in
drivers/char/sysrq.c between commit
1966cb225c6f9040ca163802cbd052c393d4448f ("Input: sysrq - add locking to
sysrq_filter()") from the input tree and commit
02307772717c91a108aca2e999bbc586a85d06a2 ("sysrq,keyboard: properly deal
with alt-sysrq in sysrq input filter") from the kgdb tree.
Just context changes. I fixed it up (see below) and can carry the fax as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/char/sysrq.c
index f0ad694,9b97aad..0000000
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@@ -566,7 -566,57 +566,58 @@@ static const unsigned char sysrq_xlate[
static bool sysrq_down;
static int sysrq_alt_use;
static int sysrq_alt;
+static DEFINE_SPINLOCK(sysrq_event_lock);
+ static bool sysrq_kbd_triggered;
+
+ /*
+ * This function was a copy of input_pass_event but modified to allow
+ * by-passing a specific filter, to allow for injected events without
+ * filter recursion.
+ */
+ static void input_pass_event_ignore(struct input_dev *dev,
+ unsigned int type, unsigned int code, int value,
+ struct input_handle *ignore_handle)
+ {
+ struct input_handler *handler;
+ struct input_handle *handle;
+
+ rcu_read_lock();
+
+ handle = rcu_dereference(dev->grab);
+ if (handle)
+ handle->handler->event(handle, type, code, value);
+ else {
+ bool filtered = false;
+
+ list_for_each_entry_rcu(handle, &dev->h_list, d_node) {
+ if (!handle->open || handle == ignore_handle)
+ continue;
+ handler = handle->handler;
+ if (!handler->filter) {
+ if (filtered)
+ break;
+
+ handler->event(handle, type, code, value);
+
+ } else if (handler->filter(handle, type, code, value))
+ filtered = true;
+ }
+ }
+
+ rcu_read_unlock();
+ }
+
+ /*
+ * Pass along alt-print_screen, if there was no sysrq processing by
+ * sending a key press down and then passing the key up event.
+ */
+ static void simulate_alt_sysrq(struct input_handle *handle)
+ {
+ input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 1, handle);
+ input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+ input_pass_event_ignore(handle->dev, EV_KEY, KEY_SYSRQ, 0, handle);
+ input_pass_event_ignore(handle->dev, EV_SYN, SYN_REPORT, 0, handle);
+ }
static bool sysrq_filter(struct input_handle *handle, unsigned int type,
unsigned int code, int value)
^ permalink raw reply
* linux-next: manual merge of the net tree with the wireless tree
From: Stephen Rothwell @ 2010-10-06 1:09 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Dan Carpenter, Joe Perches,
John W. Linville
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/wireless/ipw2x00/ipw2200.c between commit
2ee4e27cf25ab647137713ca16377d8d9e138ea2 ("ipw2200: check for allocation
failures") from the wireless tree and commit
baeb2ffab4e67bb9174e6166e070a9a8ec94b0f6 ("drivers/net: Convert unbounded
kzalloc calls to kcalloc") from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/ipw2x00/ipw2200.c
index d04d760,0f25083..0000000
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@@ -11467,13 -11467,9 +11467,13 @@@ static int ipw_net_init(struct net_devi
bg_band->band = IEEE80211_BAND_2GHZ;
bg_band->n_channels = geo->bg_channels;
- bg_band->channels =
- kzalloc(geo->bg_channels *
- sizeof(struct ieee80211_channel), GFP_KERNEL);
+ bg_band->channels = kcalloc(geo->bg_channels,
+ sizeof(struct ieee80211_channel),
+ GFP_KERNEL);
+ if (!bg_band->channels) {
+ rc = -ENOMEM;
+ goto out;
+ }
/* translate geo->bg to bg_band.channels */
for (i = 0; i < geo->bg_channels; i++) {
bg_band->channels[i].band = IEEE80211_BAND_2GHZ;
@@@ -11506,13 -11502,9 +11506,13 @@@
a_band->band = IEEE80211_BAND_5GHZ;
a_band->n_channels = geo->a_channels;
- a_band->channels =
- kzalloc(geo->a_channels *
- sizeof(struct ieee80211_channel), GFP_KERNEL);
+ a_band->channels = kcalloc(geo->a_channels,
+ sizeof(struct ieee80211_channel),
+ GFP_KERNEL);
+ if (!a_band->channels) {
+ rc = -ENOMEM;
+ goto out;
+ }
/* translate geo->bg to a_band.channels */
for (i = 0; i < geo->a_channels; i++) {
a_band->channels[i].band = IEEE80211_BAND_2GHZ;
^ permalink raw reply
* linux-next: build warnings after merge of the kbuild-current tree
From: Stephen Rothwell @ 2010-10-06 0:44 UTC (permalink / raw)
To: Michal Marek; +Cc: linux-next, linux-kernel, Arnaud Lacombe
[-- Attachment #1: Type: text/plain, Size: 14311 bytes --]
Hi Michal,
After merging the kbuild-current tree, today's (and yesterday's)
linux-next build (x86_64 allmodconfig and other builds as well) produced
these warnings:
warning: (IEEE1394_PCILYNX && (PCI || BROKEN) && PCI && IEEE1394 && I2C || SFC && NETDEVICES && NETDEV_10000 && PCI && INET || I2C_VIA && I2C && PCI && EXPERIMENTAL || I2C_HYDRA && I2C && PCI && PPC_CHRP && EXPERIMENTAL || I2C_GPIO && I2C && GENERIC_GPIO || I2C_IXP2000 && I2C && ARCH_IXP2000 || I2C_SIMTEC && I2C || I2C_VERSATILE && I2C && (ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS) || I2C_PARPORT && I2C && PARPORT || I2C_PARPORT_LIGHT && I2C || I2C_ACORN && I2C && ARCH_ACORN || SCx200_I2C && I2C && SCx200_GPIO || VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR || VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_AU0828 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && I2C && INPUT && DVB_CORE && USB && VIDEO_V4L2 || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR || VIDEO_SAA7164 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C || DVB_PLUTO2 && MEDIA_SUPPORT && DVB_CAPTURE_DRIVERS && DVB_CORE && PCI && I2C || DRM && HAS_IOMEM && (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU || FB_DDC && HAS_IOMEM && FB || FB_VIA && HAS_IOMEM && FB && PCI && X86 || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT) selects I2C_ALGOBIT which has unmet direct dependencies (I2C && !I2C_HELPER_AUTO)
warning: (I2C_PCA_PLATFORM && I2C || I2C_PCA_ISA && I2C && ISA) selects I2C_ALGOPCA which has unmet direct dependencies (I2C && !I2C_HELPER_AUTO)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TVAUDIO which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TDA7432 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI && VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TDA9840 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && !VIDEO_HELPER_CHIPS_AUTO && I2C)
warning: (VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI && VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TEA6415C which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && !VIDEO_HELPER_CHIPS_AUTO && I2C)
warning: (VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI && VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TEA6420 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && !VIDEO_HELPER_CHIPS_AUTO && I2C)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA || VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_MSP3400 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR) selects VIDEO_CS5345 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA) selects VIDEO_CS53L32A which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_M52790 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA) selects VIDEO_WM8775 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_WM8739 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_VP27SMPX which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO || VIDEO_SAA7134 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_SAA6588 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_LML33 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_BT819 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_LML33 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO || VIDEO_ZORAN_AVS6EYES && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && EXPERIMENTAL && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_BT856 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_AVS6EYES && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && EXPERIMENTAL && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_BT866 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_AVS6EYES && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && EXPERIMENTAL && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_KS0127 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CAFE_CCIC && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI && I2C && VIDEO_V4L2) selects VIDEO_OV7670 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && I2C && VIDEO_V4L2)
warning: (VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && I2C && VIDEO_V4L2)
warning: (VIDEO_ZORAN_DC10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_SAA7110 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_BUZ && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO || VIDEO_ZORAN_LML33R10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO || VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI && VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA || VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO || VIDEO_USBVISION && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && I2C && VIDEO_V4L2 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_SAA711X which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_SAA717X which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TVP5150 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_DC30 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_VPX3220 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA || VIDEO_CX231XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT) selects VIDEO_CX25840 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX88_BLACKBIRD && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_CX88 || VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT) selects VIDEO_CX2341X which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && VIDEO_V4L2_COMMON)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_SAA7127 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_BUZ && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_SAA7185 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_LML33R10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_ADV7170 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_DC30 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN && VIDEO_HELPER_CHIPS_AUTO || VIDEO_ZORAN_DC10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_ADV7175 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_UPD64031A which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_UPD64083 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
After reverting commit ff5ff6060bf880aac233e68dd666cbe9e39ec620
("kconfig: delay symbol direct dependency initialization") it produces no
such warnings.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build failure in Linus' tree
From: Stephen Rothwell @ 2010-10-06 0:09 UTC (permalink / raw)
To: Linus; +Cc: linux-next, linux-kernel, ppc-dev
Hi Linus,
Today's linux-next initial build (powerpc ppc64_defconfig) failed like
this:
cc1: warnings being treated as errors
arch/powerpc/kernel/module.c: In function 'module_finalize':
arch/powerpc/kernel/module.c:66: error: unused variable 'err'
Caused by commit 5336377d6225959624146629ce3fc88ee8ecda3d ("modules: Fix
module_bug_list list corruption race").
I added the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 6 Oct 2010 11:06:44 +1100
Subject: [PATCH] powerpc: remove unused variable
Since powerpc uses -Werror on arch powerpc, the build was broken like
this:
cc1: warnings being treated as errors
arch/powerpc/kernel/module.c: In function 'module_finalize':
arch/powerpc/kernel/module.c:66: error: unused variable 'err'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/module.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 4ef93ae..49cee9d 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -63,7 +63,6 @@ int module_finalize(const Elf_Ehdr *hdr,
const Elf_Shdr *sechdrs, struct module *me)
{
const Elf_Shdr *sect;
- int err;
/* Apply feature fixups */
sect = find_section(hdr, sechdrs, "__ftr_fixup");
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: failed to fetch the ecryptfs tree
From: Stephen Rothwell @ 2010-10-05 23:24 UTC (permalink / raw)
To: Tyler Hicks; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
Hi Tyler,
Trying to fetch the ecryptfs tree today gave me this error:
fatal: Couldn't find remote ref refs/heads/next
I will use the ecryptfs tree from next-20101005 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for October 1 (staging/olpc_dcon)
From: Andres Salomon @ 2010-10-05 19:33 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, Randy Dunlap, Stephen Rothwell, driverdevel, linux-next,
LKML, Chris Ball, Jon Nettleton
In-Reply-To: <20101005190818.GD20825@kroah.com>
On Tue, 5 Oct 2010 12:08:18 -0700
Greg KH <greg@kroah.com> wrote:
> On Sat, Oct 02, 2010 at 06:03:34PM -0700, Andres Salomon wrote:
> > On Sat, 2 Oct 2010 11:51:54 -0700
> > Greg KH <gregkh@suse.de> wrote:
> >
> > > On Fri, Oct 01, 2010 at 07:24:54PM -0700, Andres Salomon wrote:
> > > > On Fri, 1 Oct 2010 15:45:31 -0700
> > > > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > >
> > > > > On Fri, 1 Oct 2010 15:37:56 +1000 Stephen Rothwell wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Changes since 20100930:
> > > > >
> > > > >
> > > > > drivers/staging/olpc_dcon/olpc_dcon_xo_1.c:57: error: implicit
> > > > > declaration of function 'geode_gpio_event_irq'
> > > > > drivers/staging/olpc_dcon/olpc_dcon_xo_1.c:57: error: implicit
> > > > > declaration of function 'geode_gpio'
> > > >
> > > > Yep, it's pending a cs5535-gpio patch
> > > > (https://patchwork.kernel.org/patch/209482/).
> > >
> > > Wait, as I didn't apply the later patches, what I did apply should
> > > have still built properly (remember our rule, no breakage at any
> > > point in a patch series.) So, should I revert the last olpc patch
> > > that caused this problem?
> > >
> >
> > Sorry, I thought that was made clear by the "this patch is necessary
> > for building the driver" comments in each patch description. The
> > original driver that was submitted doesn't build unless all patches
> > are applied (the only which touches external APIs is the pending
> > cs5535-gpio one).
>
> Ok, I'll go mark the driver as depending on CONFIG_BROKEN for now,
> until we get that resolved, as we can't have a driver that breaks the
> build in the tree.
>
> thanks,
>
> greg k-h
Sounds good. After the two outstanding patches are applied,
CONFIG_BROKEN can be safely removed.
^ permalink raw reply
* Re: linux-next: Tree for October 4
From: Greg KH @ 2010-10-05 19:11 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Zimny Lech, Stephen Rothwell, linux-next, LKML
In-Reply-To: <49602.216.212.242.109.1286305155.squirrel@xenotime.net>
On Tue, Oct 05, 2010 at 11:59:15AM -0700, Randy Dunlap wrote:
>
> On Mon, October 4, 2010 10:48 pm, Zimny Lech wrote:
> > Hi,
> >
> >
> > 2010/10/4 Stephen Rothwell <sfr@canb.auug.org.au>:
> >
> >> Hi all,
> >>
> >>
> >> This tree is not as well tested as others since it was only built after
> >> all the merges had been done.
> >
> > Randy said that he had already sent a patch for this
> >
> >
> > /home/test/linux-2.6/drivers/base/core.c: In function
> > 'get_device_parent':
> > /home/test/linux-2.6/drivers/base/core.c:634:3: error: 'block_class'
> > undeclared (first use in this function)
> > /home/test/linux-2.6/drivers/base/core.c:634:3: note: each undeclared
> > identifier is reported only once for each function it appears in
> > /home/test/linux-2.6/drivers/base/core.c: In function
> > 'device_add_class_symlinks':
> > /home/test/linux-2.6/drivers/base/core.c:723:2: error: 'block_class'
> > undeclared (first use in this function)
> > /home/test/linux-2.6/drivers/base/core.c: In function
> > 'device_remove_class_symlinks':
> > /home/test/linux-2.6/drivers/base/core.c:751:2: error: 'block_class'
> > undeclared (first use in this function) make[3]: *** [drivers/base/core.o]
> > Error 1
> > make[2]: *** [drivers/base] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [sub-make] Error 2
>
>
> I sure did, but Greg may be backlogged or just ignoring it.
backlogged, I was in Tokyo last week, catching up now...
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for October 1 (staging/olpc_dcon)
From: Greg KH @ 2010-10-05 19:08 UTC (permalink / raw)
To: Andres Salomon
Cc: Greg KH, Randy Dunlap, Stephen Rothwell, driverdevel, linux-next,
LKML, Chris Ball, Jon Nettleton
In-Reply-To: <20101002180334.7894bdfe@debxo>
On Sat, Oct 02, 2010 at 06:03:34PM -0700, Andres Salomon wrote:
> On Sat, 2 Oct 2010 11:51:54 -0700
> Greg KH <gregkh@suse.de> wrote:
>
> > On Fri, Oct 01, 2010 at 07:24:54PM -0700, Andres Salomon wrote:
> > > On Fri, 1 Oct 2010 15:45:31 -0700
> > > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > >
> > > > On Fri, 1 Oct 2010 15:37:56 +1000 Stephen Rothwell wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Changes since 20100930:
> > > >
> > > >
> > > > drivers/staging/olpc_dcon/olpc_dcon_xo_1.c:57: error: implicit
> > > > declaration of function 'geode_gpio_event_irq'
> > > > drivers/staging/olpc_dcon/olpc_dcon_xo_1.c:57: error: implicit
> > > > declaration of function 'geode_gpio'
> > >
> > > Yep, it's pending a cs5535-gpio patch
> > > (https://patchwork.kernel.org/patch/209482/).
> >
> > Wait, as I didn't apply the later patches, what I did apply should
> > have still built properly (remember our rule, no breakage at any
> > point in a patch series.) So, should I revert the last olpc patch
> > that caused this problem?
> >
>
> Sorry, I thought that was made clear by the "this patch is necessary
> for building the driver" comments in each patch description. The
> original driver that was submitted doesn't build unless all patches are
> applied (the only which touches external APIs is the pending
> cs5535-gpio one).
Ok, I'll go mark the driver as depending on CONFIG_BROKEN for now, until
we get that resolved, as we can't have a driver that breaks the build in
the tree.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for October 4
From: Randy Dunlap @ 2010-10-05 18:59 UTC (permalink / raw)
To: Zimny Lech
Cc: Stephen Rothwell, linux-next, LKML, Greg Kroah-Hartman,
Randy Dunlap
In-Reply-To: <AANLkTi=5k=29G+xLrN_1F-ho+90k_KAwcb++eKzHA+Ai@mail.gmail.com>
On Mon, October 4, 2010 10:48 pm, Zimny Lech wrote:
> Hi,
>
>
> 2010/10/4 Stephen Rothwell <sfr@canb.auug.org.au>:
>
>> Hi all,
>>
>>
>> This tree is not as well tested as others since it was only built after
>> all the merges had been done.
>
> Randy said that he had already sent a patch for this
>
>
> /home/test/linux-2.6/drivers/base/core.c: In function
> 'get_device_parent':
> /home/test/linux-2.6/drivers/base/core.c:634:3: error: 'block_class'
> undeclared (first use in this function)
> /home/test/linux-2.6/drivers/base/core.c:634:3: note: each undeclared
> identifier is reported only once for each function it appears in
> /home/test/linux-2.6/drivers/base/core.c: In function
> 'device_add_class_symlinks':
> /home/test/linux-2.6/drivers/base/core.c:723:2: error: 'block_class'
> undeclared (first use in this function)
> /home/test/linux-2.6/drivers/base/core.c: In function
> 'device_remove_class_symlinks':
> /home/test/linux-2.6/drivers/base/core.c:751:2: error: 'block_class'
> undeclared (first use in this function) make[3]: *** [drivers/base/core.o]
> Error 1
> make[2]: *** [drivers/base] Error 2
> make[1]: *** [drivers] Error 2
> make: *** [sub-make] Error 2
I sure did, but Greg may be backlogged or just ignoring it.
--
~Randy
^ permalink raw reply
* Re: linux-next: build failure after merge of the drivers-x86 tree
From: Ike Panhc @ 2010-10-05 10:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Matthew Garrett, linux-next, linux-kernel, Len Brown
In-Reply-To: <20101005151126.eadae817.sfr@canb.auug.org.au>
On 10/05/2010 12:11 PM, Stephen Rothwell wrote:
> Hi Matthew,
>
> After merging the drivers-x86 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> make[4]: *** No rule to make target `drivers/platform/x86/ideapad_laptop.c', needed by `drivers/platform/x86/ideapad_laptop.o'. Stop.
>
> Caused by commit 9efe5c1540a1e03cb2e0fca85e49fc4c57c6e771 ("ideapad:
> Change the driver name to ideapad-laptop"). The commit renames
> ideapad_acpi.c to ideapad-laptop.c but the Makefile uses ideapad_laptop.o
> (note underscore v. dash).
>
> Presumably this was never even build tested :-(
>
> I have used the drivers-x86 tree from next-20101004 for today.
Sorry, my fault.
This line is wrong,
+obj-$(CONFIG_IDEAPAD_LAPTOP) += ideapad_laptop.o
shall be
+obj-$(CONFIG_IDEAPAD_LAPTOP) += ideapad-laptop.o
How shall I fix it? resend the whole patches or just this one?
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Ingo Molnar @ 2010-10-05 9:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Tejun Heo, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20101005193803.e805b3eb.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Tue, 5 Oct 2010 09:01:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> > Fortunately there's a really simple solution: wait for an explicit
> > reply from a maintainer before adding a new-feature tree. (Solicite
> > again via a To: email if the Cc: went unanswered by the
> > maintainers.)
>
> Sure we can try that.
Thanks.
> > Could you please start using that method for all subsystems i
> > co-maintain?
>
> So, to be clear, from the MAINTAINERS file that would be LOCKDEP AND
> LOCKSTAT, PERFORMANCE EVENTS SUBSYSTEM, SCHEDULER, TRACING, and X86
> ARCHITECTURE. [...]
Yep - those are the main ones.
( You might want to apply the process generally as well - it's rather
rare that trees parallel to maintainer trees get added to linux-next
and IMO it pays to make sure the maintainers are actively fine with
such additions.
A Cc: to a mail with no patch content is easy to miss and it's useful
to solicit a 'yeah, sure it's fine' mail from a maintainer - just like
we solicit Acked-by's from maintainers for much smaller matters than
full trees (individual patches).
This would further ensure that linux-next is indeed a stable
approximation of the 'next Linux' as intended by maintainers.
To me this looks like a pretty obvious and useful thing to do. )
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: Tree for October 5
From: Arnd Bergmann @ 2010-10-05 8:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Zimny Lech, linux-next, LKML, Valdis.Kletnieks
In-Reply-To: <20101005194232.de733b2b.sfr@canb.auug.org.au>
On Tuesday 05 October 2010, Stephen Rothwell wrote:
> Hi,
>
> On Tue, 5 Oct 2010 09:38:49 +0200 Zimny Lech <napohybelskurwysynom2010@gmail.com> wrote:
> >
> > Also, I saw this
> > /home/test/linux-2.6/include/linux/fs.h:1274:20: warning: function
> > declaration isn't a prototype
> > /home/test/linux-2.6/include/linux/fs.h:1278:20: warning: function
> > declaration isn't a prototype
> >
> > It was fixed in -mmotm by Valdis Kletnieks.
>
> Yeah, it was fixed in linux-next, but rebroken by a rebase of the bkl-vfs
> tree since yesterday.
Ok, fixed it again now. Sorry for messing this up twice.
Arnd
^ permalink raw reply
* Re: linux-next: Tree for October 5
From: Stephen Rothwell @ 2010-10-05 8:42 UTC (permalink / raw)
To: Zimny Lech; +Cc: linux-next, LKML, Valdis.Kletnieks, Arnd Bergmann
In-Reply-To: <AANLkTikF+-0ybP3RMA-7wr8DMit6At=G1W7oB0UO4Mvz@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Hi,
On Tue, 5 Oct 2010 09:38:49 +0200 Zimny Lech <napohybelskurwysynom2010@gmail.com> wrote:
>
> Also, I saw this
> /home/test/linux-2.6/include/linux/fs.h:1274:20: warning: function
> declaration isn't a prototype
> /home/test/linux-2.6/include/linux/fs.h:1278:20: warning: function
> declaration isn't a prototype
>
> It was fixed in -mmotm by Valdis Kletnieks.
Yeah, it was fixed in linux-next, but rebroken by a rebase of the bkl-vfs
tree since yesterday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Stephen Rothwell @ 2010-10-05 8:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Tejun Heo, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20101005070123.GF12267@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
Hi Ingo,
On Tue, 5 Oct 2010 09:01:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> Fortunately there's a really simple solution: wait for an explicit reply
> from a maintainer before adding a new-feature tree. (Solicite again via
> a To: email if the Cc: went unanswered by the maintainers.)
Sure we can try that.
> Could you please start using that method for all subsystems i
> co-maintain?
So, to be clear, from the MAINTAINERS file that would be LOCKDEP AND
LOCKSTAT, PERFORMANCE EVENTS SUBSYSTEM, SCHEDULER, TRACING, and X86
ARCHITECTURE. Any others? If so could you please update the MAINTAINERS
file as (at my age) I am likely to forget and other may not guess.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for October 5
From: Zimny Lech @ 2010-10-05 7:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Valdis.Kletnieks, Arnd Bergmann
In-Reply-To: <20101005161220.0bef433f.sfr@canb.auug.org.au>
Hi,
I see the same build errors as in -next 2010-10-04
Also, I saw this
/home/test/linux-2.6/include/linux/fs.h:1274:20: warning: function
declaration isn't a prototype
/home/test/linux-2.6/include/linux/fs.h:1278:20: warning: function
declaration isn't a prototype
It was fixed in -mmotm by Valdis Kletnieks.
--
Slawa!
N.P.S.
Les fleurs du mal unfold
Comme les fleurs du mal
Dark demons of my soul
Un amour fatal
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Ingo Molnar @ 2010-10-05 7:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Tejun Heo, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20101005174524.b62d14a1.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Not sure what I can do beyond making sure that all relevant people are
> informed about what trees are being merged. [...]
Fortunately there's a really simple solution: wait for an explicit reply
from a maintainer before adding a new-feature tree. (Solicite again via
a To: email if the Cc: went unanswered by the maintainers.)
Could you please start using that method for all subsystems i
co-maintain?
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Tejun Heo @ 2010-10-05 6:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <4CAACBDA.6090308@kernel.org>
On 10/05/2010 08:55 AM, Tejun Heo wrote:
> I think Stephen had done enough. At the time, I wasn't sure which
> tree it was going to go through and it took some time before Thomas
> responded, so I was intending to push it through separately. I should
> have retracted the tree right after it was determined to be
> reimplemented but forgot. That's my mistake not Stephen's. Sorry
> about that.
Oooh, apparently I knew it was gonna go through genirq but expected it
to go through as-is and wanted to accelerate testing. FWIW, I'm
sure everyone involved was notified of the move at the time. At any
rate, won't happen again.
Thanks.
--
tejun
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Tejun Heo @ 2010-10-05 6:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20101005063227.GB12267@elte.hu>
Hello, Ingo.
On 10/05/2010 08:32 AM, Ingo Molnar wrote:
>
> * Tejun Heo <tj@kernel.org> wrote:
>
>>> I think I fixed it all up (see below). I can carry this fix (or a
>>> better one) as necessary.
>>
>> Can you please drop lost-spurious-irq for now? It needs to be
>> reimplemented. I'll send a merge request again when it's ready.
>
> Please send irq merge requests to Thomas instead and wait for those
> genirq bits to show up upstream. (You did so in the past and the review
> process was ongoing AFAICS)
>
> Otherwise we would be dilluting linux-next testing with random side
> effects from a tree that wasnt yet (in that form) scheduled to go
> upstream by its respective maintainer at that time.
>
> We were lucky that this showed up as merge complications - what if
> instead it merged 'fine' on the textual and build/boot level but
> mis-merged on the functional level in subtle ways? Thomas would be
> sending something to Linus that was never really tested in linux-next in
> that form, caused problems upstream, and Linus would be rightfully upset
> about the situation.
>
> Stephen, you need to enforce such things ...
I think Stephen had done enough. At the time, I wasn't sure which
tree it was going to go through and it took some time before Thomas
responded, so I was intending to push it through separately. I should
have retracted the tree right after it was determined to be
reimplemented but forgot. That's my mistake not Stephen's. Sorry
about that.
Thanks.
--
tejun
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Stephen Rothwell @ 2010-10-05 6:45 UTC (permalink / raw)
To: Ingo Molnar
Cc: Tejun Heo, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20101005063227.GB12267@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
Hi Ingo,
On Tue, 5 Oct 2010 08:32:27 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> Please send irq merge requests to Thomas instead and wait for those
> genirq bits to show up upstream. (You did so in the past and the review
> process was ongoing AFAICS)
>
> Otherwise we would be dilluting linux-next testing with random side
> effects from a tree that wasnt yet (in that form) scheduled to go
> upstream by its respective maintainer at that time.
>
> We were lucky that this showed up as merge complications - what if
> instead it merged 'fine' on the textual and build/boot level but
> mis-merged on the functional level in subtle ways? Thomas would be
> sending something to Linus that was never really tested in linux-next in
> that form, caused problems upstream, and Linus would be rightfully upset
> about the situation.
>
> Stephen, you need to enforce such things ...
At the time that this tree was added to linux-next (in July), I responded
to Tejun like this:
------------------------------------------------------------------------
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Tejun Heo <tj@kernel.org>
Cc: "linux-next@vger.kernel.org" <linux-next@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: please pull in from lost-spurious-irq branch
Date: Thu, 29 Jul 2010 01:35:09 +1000
Hi Tejun,
On Wed, 28 Jul 2010 15:50:55 +0200 Tejun Heo <tj@kernel.org> wrote:
>
> If possible, can you please pull the following branch into linux-next?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git lost-spurious-irq
>
> It's scheduled to go through tip/genirq, so once it shows up in tip,
> the above branch can be dropped from linux-next. As the merge window
> is closing in, I'm hoping to get it tested enough in linux-next. The
> branch is based on rc3 but merges without conflict into the current
> mainline.
OK, added from today. I'll keep an eye out for it in the tip tree.
------------------------------------------------------------------------
Not sure what I can do beyond making sure that all relevant people are
informed about what trees are being merged. There is a certain amount of
good faith involved in all our development processes.
In any case, it will be dropped tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the lost-spurious-irq tree with the tip tree
From: Ingo Molnar @ 2010-10-05 6:32 UTC (permalink / raw)
To: Tejun Heo
Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <4CAABC0E.3030700@kernel.org>
* Tejun Heo <tj@kernel.org> wrote:
> > I think I fixed it all up (see below). I can carry this fix (or a
> > better one) as necessary.
>
> Can you please drop lost-spurious-irq for now? It needs to be
> reimplemented. I'll send a merge request again when it's ready.
Please send irq merge requests to Thomas instead and wait for those
genirq bits to show up upstream. (You did so in the past and the review
process was ongoing AFAICS)
Otherwise we would be dilluting linux-next testing with random side
effects from a tree that wasnt yet (in that form) scheduled to go
upstream by its respective maintainer at that time.
We were lucky that this showed up as merge complications - what if
instead it merged 'fine' on the textual and build/boot level but
mis-merged on the functional level in subtle ways? Thomas would be
sending something to Linus that was never really tested in linux-next in
that form, caused problems upstream, and Linus would be rightfully upset
about the situation.
Stephen, you need to enforce such things ...
Thanks,
Ingo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox