Linux-Next discussions
 help / color / mirror / Atom feed
* linux-next: manual merge of the trivial tree with the  tree
From: Stephen Rothwell @ 2009-11-09  4:43 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: linux-next, linux-kernel, Thadeu Lima de Souza Cascardo,
	Bartlomiej Zolnierkiewicz, John W. Linville

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/net/wireless/rt2x00/rt2800usb.c between commit
fcf5154118849cca3cdf424e83f863225d8173e7 ("rt2800: add rt2800lib (part
three)") from the wireless tree and commit
305409a25f7df3c359ba67cbeb62763eeb7156e9 ("tree-wide: fix some typos and
punctuation in comments") from the trivial tree.

The misspelling is moved to a new file
(drivers/net/wireless/rt2x00/rt2800lib.c), but I didn't bother fixing it up.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2009-11-09  4:59 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, wg, haas
In-Reply-To: <20091109130323.5dcc7829.sfr@canb.auug.org.au>

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 9 Nov 2009 13:03:23 +1100

> Hi all,
> 
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/can/usb/ems_usb.c between commit
> 2b2072e902848a63168570f500a5726744b3873a ("ems_usb: Fix byte order issues
> on big endian machines") from the net-current tree and commit
> 7b6856a0296a8f187bb88ba31fa83a08abba7966 ("can: provide library functions
> for skb allocation") from the net tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix
> for a while.

I'll do a merge and resolve this, thanks Stephen!

^ permalink raw reply

* linux-next: manual merge of the staging tree with the pcmcia tree
From: Stephen Rothwell @ 2009-11-09  7:15 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Daniel Patrick Johnson,
	Dominik Brodowski

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/comedi/drivers/ni_mio_cs.c between commit
4e338b7f55b4c30e60fa3fa9ff3d21e930f40116 ("pcmcia/staging: update comedi
drivers") from the pcmcia tree and commit
bd7881ee58045b4b684f4400b24081656e0c6986 ("Staging: comedi: ni_mio_cs.c:
coding style cleanup") from the staging tree.

I fixed it up (mainly using the pcmcia tree version when there was a
clash) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* linux-next: manual merge of the staging tree with the pcmcia tree
From: Stephen Rothwell @ 2009-11-09  7:15 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Bart Massey, Dominik Brodowski

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/comedi/drivers/ni_labpc_cs.c between commit
4e338b7f55b4c30e60fa3fa9ff3d21e930f40116 ("pcmcia/staging: update comedi
drivers") from the pcmcia tree and commits
c22f24e5f0ed5a45e4b339577a1151c4bbb8977a ("Staging: comedi: ni_labpc_cs:
added mandatory whitespace to comparison") and
f195fbc2466c79cda709074fdbb969079e0787e0 ("Staging: comedi: ni_labpc_cs:
wrapped long comments") from the staging tree.

I fixed it up (using the pcmcia tree version where there was a clash) and
can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* linux-next: manual merge of the staging tree with the pcmcia tree
From: Stephen Rothwell @ 2009-11-09  7:15 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Dominik Brodowski, Vadim Mutilin

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/comedi/drivers/cb_das16_cs.c between commit
4e338b7f55b4c30e60fa3fa9ff3d21e930f40116 ("pcmcia/staging: update comedi
drivers") from the pcmcia tree and commit
e18c724339a542aac71d1d47b0695bf7b4a5c3a3 ("STAGING: comedi: cb_das16_cs:
fixing coding style errors") from the staging tree.

I fixed it up (using the pcmcia tree version when there is a clash) and
can carry the fix as necessary.

[Greg, that staging tree commit has no SOB from its author ...]
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the pcmcia tree with the mtd tree
From: Dominik Brodowski @ 2009-11-09  7:25 UTC (permalink / raw)
  To: Stephen Rothwell, David Woodhouse; +Cc: linux-next, linux-mtd
In-Reply-To: <20091109144221.f27d7242.sfr@canb.auug.org.au>

Hi David,

could you drop it from your tree, please? It depends on a patch which is in
the PCMCIA tree, and so it isn't a good idea to carry this patch in the
linux-mtd tree (well, it doesn't matter all that much as this driver is
marked BROKEN anyways, but...)

Best,
	Dominik

^ permalink raw reply

* linux-next: rr tree build warnings
From: Stephen Rothwell @ 2009-11-09  7:31 UTC (permalink / raw)
  To: Rusty Russell; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Hi Rusty,

Today's linux-next build (x86_64 allmodconfig) produced these warnings:

drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'

Introduced by commit 9f94999724555729819ea0143eab1d0529c029d1
("param:param_ops").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: pcmcia tree build warning
From: Dominik Brodowski @ 2009-11-09  7:32 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20091109145451.c9f1c4c3.sfr@canb.auug.org.au>

Hi Stephen,

this issue just got fixed by hiding it behind the driver-specific
DEBUG define -- thanks! :)

Best,
	Dominik

^ permalink raw reply

* Re: linux-next: rr tree build warnings
From: Stephen Rothwell @ 2009-11-09  7:40 UTC (permalink / raw)
  To: Rusty Russell; +Cc: linux-next, linux-kernel
In-Reply-To: <20091109183104.2bf7add6.sfr@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

Hi Rusty,

On Mon, 9 Nov 2009 18:31:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> 
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> 
> Introduced by commit 9f94999724555729819ea0143eab1d0529c029d1
> ("param:param_ops").

I am also getting some section mismatch warnings like this:

WARNING: drivers/mtd/ubi/ubi.o(.data+0x1c0): Section mismatch in reference from the variable __ops_mtd to the function .init.text:ubi_mtd_param_parse()
The variable __ops_mtd references
the function __init ubi_mtd_param_parse()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 

Which are probably also related to the above change.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: limits tree fetch failure
From: Jiri Slaby @ 2009-11-09  8:02 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20091109103017.6099f588.sfr@canb.auug.org.au>

On 11/09/2009 12:30 AM, Stephen Rothwell wrote:
> Today's linux-next fetch of the limits tree produced this error:
> 
> decibel.fi.muni.cz[0: 147.251.50.163]: errno=Connection timed out
> fatal: unable to connect a socket (Connection timed out)

Hi, ah, power outages and electricity reconnections. It's up and running
now. Thanks.

^ permalink raw reply

* linux-next: wireless tree build failure
From: Stephen Rothwell @ 2009-11-09  8:08 UTC (permalink / raw)
  To: John W. Linville; +Cc: linux-next, linux-kernel, Bartlomiej Zolnierkiewicz

Hi John,

Today's linux-next build (powerpc allyesconfig) failed like this:

In file included from drivers/net/wireless/rt2x00/rt2800lib.c:35:
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_vendor_request_sw':
drivers/net/wireless/rt2x00/rt2x00usb.h:205: error: 'USB_DIR_OUT' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:205: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:205: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_eeprom_read':
drivers/net/wireless/rt2x00/rt2x00usb.h:223: error: 'USB_DIR_IN' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:223: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:223: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_register_read':
drivers/net/wireless/rt2x00/rt2x00usb.h:243: error: 'USB_DIR_IN' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:243: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:243: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_register_read_lock':
drivers/net/wireless/rt2x00/rt2x00usb.h:263: error: 'USB_DIR_IN' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:263: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:263: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_register_multiread':
drivers/net/wireless/rt2x00/rt2x00usb.h:283: error: 'USB_DIR_IN' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:283: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:283: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_register_write':
drivers/net/wireless/rt2x00/rt2x00usb.h:303: error: 'USB_DIR_OUT' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:303: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:303: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_register_write_lock':
drivers/net/wireless/rt2x00/rt2x00usb.h:322: error: 'USB_DIR_OUT' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:322: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:322: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: In function 'rt2x00usb_register_multiwrite':
drivers/net/wireless/rt2x00/rt2x00usb.h:342: error: 'USB_DIR_OUT' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:342: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h:342: error: 'USB_RECIP_DEVICE' undeclared (first use in this function)
drivers/net/wireless/rt2x00/rt2x00usb.h: At top level:
drivers/net/wireless/rt2x00/rt2x00usb.h:439: warning: 'struct usb_interface' declared inside parameter list
drivers/net/wireless/rt2x00/rt2x00usb.h:439: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/net/wireless/rt2x00/rt2x00usb.h:440: warning: 'struct usb_interface' declared inside parameter list
drivers/net/wireless/rt2x00/rt2x00usb.h:442: warning: 'struct usb_interface' declared inside parameter list
drivers/net/wireless/rt2x00/rt2x00usb.h:443: warning: 'struct usb_interface' declared inside parameter list

Presumably because drivers/net/wireless/rt2x00/rt2x00usb.h needs to have
linux/usb/ch9.h included.

I applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 9 Nov 2009 19:04:19 +1100
Subject: [PATCH] wireless/rt2x00usb: include usb.h to get needed constants

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/wireless/rt2x00/rt2x00usb.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.h b/drivers/net/wireless/rt2x00/rt2x00usb.h
index 9943e42..1c9d6ca 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.h
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.h
@@ -26,6 +26,8 @@
 #ifndef RT2X00USB_H
 #define RT2X00USB_H
 
+#include <linux/usb.h>
+
 #define to_usb_device_intf(d) \
 ({ \
 	struct usb_interface *intf = to_usb_interface(d); \
-- 
1.6.5.2


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply related

* Re: linux-next: tip tree build warning
From: Ingo Molnar @ 2009-11-09  8:10 UTC (permalink / raw)
  To: Cyrill Gorcunov
  Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Maciej W. Rozycki, Yinghai Lu
In-Reply-To: <20091108213055.GA13555@lenovo>


* Cyrill Gorcunov <gorcunov@gmail.com> wrote:

> +++ linux-2.6.git/arch/x86/include/asm/apic.h
> @@ -310,7 +310,7 @@ struct apic {
>  	int (*apicid_to_node)(int logical_apicid);
>  	int (*cpu_to_logical_apicid)(int cpu);
>  	int (*cpu_present_to_apicid)(int mps_cpu);
> -	physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
> +	void (*apicid_to_cpu_present)(int phys_apicid, physid_mask_t *map);

Yep, passing masks by reference is unconditonal goodness - that's the 
cleanup we want.

Mind sending a delta patch against tip:master?

	Ingo

^ permalink raw reply

* linux-next: Tree for November 9
From: Stephen Rothwell @ 2009-11-09  8:22 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 8519 bytes --]

Hi all,

Changes since 20091106:

The sparc tree lost its build failure.

The net tree lost a conflict, but gained another against the net-current
tree and a build failure for which I applied a patch.

The wireless tree gained a build failure for which I applied a patch.

The pcmcia tree gained a conflict against the mtd tree.

The trivial tree gained a conflict against the wireless tree.

The staging tree gained 3 conflicts against the pcmcia tree.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 146 trees (counting Linus' and 22 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/davinci-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
CONFLICT (content): Merge conflict in arch/avr32/mach-at32ap/include/mach/cpu.h
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
CONFLICT (content): Merge conflict in drivers/rtc/Kconfig
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging kbuild/master
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
CONFLICT (content): Merge conflict in arch/powerpc/kvm/timing.h
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/can/usb/ems_usb.c
CONFLICT (delete/modify): drivers/net/sfc/sfe4001.c deleted in net/master and modified in HEAD. Version HEAD of drivers/net/sfc/sfe4001.c left in tree.
CONFLICT (content): Merge conflict in drivers/net/wireless/libertas/cmd.c
CONFLICT (content): Merge conflict in drivers/staging/rtl8187se/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/rtl8192e/Kconfig
$ git rm -f drivers/net/sfc/sfe4001.c
Applying: net: merge fixup for drivers/net/sfc/falcon_boards.c
Merging wireless/master
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/Makefile
Applying: net/appletalk: using compat_ptr needs inclusion of linux/compat.h
Merging mtd/master
Merging crypto/master
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3evm.c
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging tmio-mmc/linux-next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/pcmciamtd.c
CONFLICT (content): Merge conflict in drivers/pcmcia/Makefile
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
CONFLICT (content): Merge conflict in drivers/mfd/Kconfig
CONFLICT (content): Merge conflict in drivers/mfd/Makefile
Merging security-testing/next
CONFLICT (content): Merge conflict in Documentation/dontdiff
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in drivers/net/wireless/rt2x00/rt2800usb.c
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
CONFLICT (content): Merge conflict in drivers/misc/Makefile
Merging drbd/for-jens
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in drivers/net/Kconfig
CONFLICT (content): Merge conflict in lib/Kconfig
Merging i7core_edac/linux_next
Merging devicetree/next-devicetree
Merging limits/writable_limits
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/kernel/kgdb.c
Merging oprofile/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/x86/kvm/svm.c
CONFLICT (content): Merge conflict in kernel/softlockup.c
CONFLICT (content): Merge conflict in mm/percpu.c
Applying: percpu: merge fixup for variable renaming
Merging sfi/sfi-test
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging quilt/driver-core
Merging quilt/tty
Merging quilt/usb
Merging quilt/staging
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/cb_das16_cs.c
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_labpc_cs.c
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_mio_cs.c
Merging scsi-post-merge/master
Applying: wireless/rt2x00usb: include usb.h to get needed constants

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the trivial tree with the  tree
From: Jiri Kosina @ 2009-11-09  8:45 UTC (permalink / raw)
  To: Stephen Rothwell, John W. Linville
  Cc: linux-next, linux-kernel, Thadeu Lima de Souza Cascardo,
	Bartlomiej Zolnierkiewicz
In-Reply-To: <20091109154305.49d3eb7c.sfr@canb.auug.org.au>

On Mon, 9 Nov 2009, Stephen Rothwell wrote:

> Today's linux-next merge of the trivial tree got a conflict in
> drivers/net/wireless/rt2x00/rt2800usb.c between commit
> fcf5154118849cca3cdf424e83f863225d8173e7 ("rt2800: add rt2800lib (part
> three)") from the wireless tree and commit
> 305409a25f7df3c359ba67cbeb62763eeb7156e9 ("tree-wide: fix some typos and
> punctuation in comments") from the trivial tree.
> 
> The misspelling is moved to a new file
> (drivers/net/wireless/rt2x00/rt2800lib.c), but I didn't bother fixing it up.

Sure, thanks for letting me know.

John, I think it'd be best if you just take the appropriate hunks from 
that tree-wide patch into your tree, if you don't mind.

Please find the patch with extracted hunks below, and let me know if/when 
you have applied it, so that I can drop it. Thanks.



From: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Subject: rt2x00: fix some typos and punctuation in comments

fix some typos and punctuation in comments

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 9fe770f..68b43e3 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1257,7 +1257,7 @@ static int rt2800usb_init_registers(struct rt2x00_dev *rt2x00dev)
 	unsigned int i;
 
 	/*
-	 * Wait untill BBP and RF are ready.
+	 * Wait until BBP and RF are ready.
 	 */
 	for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
 		rt2x00usb_register_read(rt2x00dev, MAC_CSR0, &reg);
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index b20e3ea..343e565 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -51,7 +51,7 @@ MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
  * These indirect registers work with busy bits,
  * and we will try maximal REGISTER_BUSY_COUNT times to access
  * the register while taking a REGISTER_BUSY_DELAY us delay
- * between each attampt. When the busy bit is still set at that time,
+ * between each attempt. When the busy bit is still set at that time,
  * the access attempt is considered to have failed,
  * and we will print an error.
  */
@@ -386,7 +386,7 @@ static int rt61pci_config_shared_key(struct rt2x00_dev *rt2x00dev,
 		 * The driver does not support the IV/EIV generation
 		 * in hardware. However it doesn't support the IV/EIV
 		 * inside the ieee80211 frame either, but requires it
-		 * to be provided seperately for the descriptor.
+		 * to be provided separately for the descriptor.
 		 * rt2x00lib will cut the IV/EIV data out of all frames
 		 * given to us by mac80211, but we must tell mac80211
 		 * to generate the IV/EIV data.
@@ -397,7 +397,7 @@ static int rt61pci_config_shared_key(struct rt2x00_dev *rt2x00dev,
 	/*
 	 * SEC_CSR0 contains only single-bit fields to indicate
 	 * a particular key is valid. Because using the FIELD32()
-	 * defines directly will cause a lot of overhead we use
+	 * defines directly will cause a lot of overhead, we use
 	 * a calculation to determine the correct bit directly.
 	 */
 	mask = 1 << key->hw_key_idx;
@@ -425,11 +425,11 @@ static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,
 		/*
 		 * rt2x00lib can't determine the correct free
 		 * key_idx for pairwise keys. We have 2 registers
-		 * with key valid bits. The goal is simple, read
-		 * the first register, if that is full move to
+		 * with key valid bits. The goal is simple: read
+		 * the first register. If that is full, move to
 		 * the next register.
-		 * When both registers are full, we drop the key,
-		 * otherwise we use the first invalid entry.
+		 * When both registers are full, we drop the key.
+		 * Otherwise, we use the first invalid entry.
 		 */
 		rt2x00pci_register_read(rt2x00dev, SEC_CSR2, &reg);
 		if (reg && reg == ~0) {
@@ -464,8 +464,8 @@ static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,
 					      &addr_entry, sizeof(addr_entry));
 
 		/*
-		 * Enable pairwise lookup table for given BSS idx,
-		 * without this received frames will not be decrypted
+		 * Enable pairwise lookup table for given BSS idx.
+		 * Without this, received frames will not be decrypted
 		 * by the hardware.
 		 */
 		rt2x00pci_register_read(rt2x00dev, SEC_CSR4, &reg);
@@ -487,7 +487,7 @@ static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,
 	/*
 	 * SEC_CSR2 and SEC_CSR3 contain only single-bit fields to indicate
 	 * a particular key is valid. Because using the FIELD32()
-	 * defines directly will cause a lot of overhead we use
+	 * defines directly will cause a lot of overhead, we use
 	 * a calculation to determine the correct bit directly.
 	 */
 	if (key->hw_key_idx < 32) {
@@ -556,7 +556,7 @@ static void rt61pci_config_intf(struct rt2x00_dev *rt2x00dev,
 	if (flags & CONFIG_UPDATE_TYPE) {
 		/*
 		 * Clear current synchronisation setup.
-		 * For the Beacon base registers we only need to clear
+		 * For the Beacon base registers, we only need to clear
 		 * the first byte since that byte contains the VALID and OWNER
 		 * bits which (when set to 0) will invalidate the entire beacon.
 		 */
@@ -1168,8 +1168,8 @@ static int rt61pci_check_firmware(struct rt2x00_dev *rt2x00dev,
 		return FW_BAD_LENGTH;
 
 	/*
-	 * The last 2 bytes in the firmware array are the crc checksum itself,
-	 * this means that we should never pass those 2 bytes to the crc
+	 * The last 2 bytes in the firmware array are the crc checksum itself.
+	 * This means that we should never pass those 2 bytes to the crc
 	 * algorithm.
 	 */
 	fw_crc = (data[len - 2] << 8 | data[len - 1]);
@@ -1986,7 +1986,7 @@ static void rt61pci_fill_rxdone(struct queue_entry *entry,
 
 		/*
 		 * Hardware has stripped IV/EIV data from 802.11 frame during
-		 * decryption. It has provided the data seperately but rt2x00lib
+		 * decryption. It has provided the data separately but rt2x00lib
 		 * should decide if it should be reinserted.
 		 */
 		rxdesc->flags |= RX_FLAG_IV_STRIPPED;
@@ -2042,7 +2042,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
 	 * During each loop we will compare the freshly read
 	 * STA_CSR4 register value with the value read from
 	 * the previous loop. If the 2 values are equal then
-	 * we should stop processing because the chance it
+	 * we should stop processing because the chance is
 	 * quite big that the device has been unplugged and
 	 * we risk going into an endless loop.
 	 */
@@ -2330,7 +2330,7 @@ static int rt61pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_FRAME_TYPE, &rt2x00dev->flags);
 
 	/*
-	 * Detect if this device has an hardware controlled radio.
+	 * Detect if this device has a hardware controlled radio.
 	 */
 	if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
 		__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
@@ -2355,7 +2355,7 @@ static int rt61pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
 		__set_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags);
 
 	/*
-	 * When working with a RF2529 chip without double antenna
+	 * When working with a RF2529 chip without double antenna,
 	 * the antenna settings should be gathered from the NIC
 	 * eeprom word.
 	 */
@@ -2668,7 +2668,7 @@ static int rt61pci_conf_tx(struct ieee80211_hw *hw, u16 queue_idx,
 
 	/*
 	 * We only need to perform additional register initialization
-	 * for WMM queues/
+	 * for WMM queues.
 	 */
 	if (queue_idx >= 4)
 		return 0;

^ permalink raw reply related

* Re: linux-next: Tree for November 2 (wireless/wl1271)
From: Luciano Coelho @ 2009-11-09 11:20 UTC (permalink / raw)
  To: ext Kalle Valo
  Cc: ext John W. Linville, Randy Dunlap, Stephen Rothwell,
	linux-next@vger.kernel.org, LKML, linux-wireless@vger.kernel.org
In-Reply-To: <87ljiifwnc.fsf@purkki.valot.fi>

ext Kalle Valo wrote:
> Luciano Coelho <luciano.coelho@nokia.com> writes:
> 
>> Coelho Luciano (Nokia-D/Helsinki) wrote:
>>> ext John W. Linville wrote:
>>>> Helps if I actually Cc: Luca...
>>> Yes, it does. :) I would see this at some point but CCing me speed
>>> things up quite a lot.
>>
>> BTW, I think we need this for wl1251 as well.  CC'ing Kalle too.
> 
> Thanks, but upstream wl1251 doesn't have ARP filter. There is an
> internal patch but I haven't submitted it, yet.

Oh, okay.  Sorry for not checking.  I just noticed that our wl1271 
implementation was based on the implementation for wl1251, so I just assumed it 
was needed as well.

-- 
Cheers,
Luca.

^ permalink raw reply

* Re: linux-next: wireless tree build failure
From: Bartlomiej Zolnierkiewicz @ 2009-11-09 13:37 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: John W. Linville, linux-next, linux-kernel
In-Reply-To: <20091109190812.b2f75760.sfr@canb.auug.org.au>


Hi,

On Monday 09 November 2009 09:08:12 Stephen Rothwell wrote:
> Hi John,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:

This was fixed yesterday by Hauke Mehrtens for wireless-testing
(http://patchwork.kernel.org/patch/58495/) and in the way preserving
bisectability in rt2800 tree.

Stephen, until someone explains me how they would like to coordinate
patch-flow w/ rt2800 tree please do not cc: me on rt2x00 patches as
I have completely no control over what people are doing with my patches
posted to linux-wireless for review.

[ Yesterday I've just noticed by accident (mail from Hauke) that older
  versions of my patches were merged into wireless-testing. ]

--
Bartlomiej Zolnierkiewicz

^ permalink raw reply

* Re: linux-next: manual merge of the trivial tree with the  tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-09 15:08 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Stephen Rothwell, John W. Linville, linux-next, linux-kernel,
	Thadeu Lima de Souza Cascardo
In-Reply-To: <alpine.LSU.2.00.0911090944200.15039@wotan.suse.de>

On Monday 09 November 2009 09:45:50 Jiri Kosina wrote:

> From: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> Subject: rt2x00: fix some typos and punctuation in comments
> 
> fix some typos and punctuation in comments
> 
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

FWIW the patch is in rt2800 tree now.

-- 
Bartlomiej Zolnierkiewicz

^ permalink raw reply

* Re: linux-next: manual merge of the trivial tree with the  tree
From: Jiri Kosina @ 2009-11-09 15:25 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Stephen Rothwell, John W. Linville, linux-next, linux-kernel,
	Thadeu Lima de Souza Cascardo
In-Reply-To: <200911091608.36757.bzolnier@gmail.com>

On Mon, 9 Nov 2009, Bartlomiej Zolnierkiewicz wrote:

> > From: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> > Subject: rt2x00: fix some typos and punctuation in comments
> > 
> > fix some typos and punctuation in comments
> > 
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> FWIW the patch is in rt2800 tree now.

I have dropped the respective hunk from my tree (I hope that being in your 
tree means that it will get upstream one day, I must say I got completely 
lost in the recent rt2x00 flames :) ).

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

^ permalink raw reply

* Re: linux-next: Tree for October 29 (x86 posttest)
From: Masami Hiramatsu @ 2009-11-10  0:40 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <20091106085954.39eb2789.rdunlap@xenotime.net>

Randy Dunlap wrote:
> On Thu, 29 Oct 2009 12:48:12 -0400 Masami Hiramatsu wrote:
>
>> Randy Dunlap wrote:
>>> On Thu, 29 Oct 2009 18:29:19 +1100 Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> [I accidentally deleted my merge log today, so sorry to anyone who
>>>> actually reads them :-), the summary still appears below.]
>>>
>>>
>>> I'm getting this on x86_64:
>>>
>>>     TEST    posttest
>>> Error: ffffffff810299e2:	f2 41 0f 28 52 b0    	repnz movaps -0x50(%r10),%xmm2
>>> Error: objdump says 6 bytes, but insn_get_length() says 4 (attr:0)
>>> make[2]: *** [posttest] Error 2
>>
>> Ah, that's should be fixed by AVX support patch which I've posted.
>> http://git.kernel.org/tip/e0e492e99b372c6990a5daca9e4683c341f1330e
>
> Has that been merged into linux-next?
> I'm still seeing this failure in linux-next-20091106.

I checked it has been merged.
So, it should disappear from linux-next-20091109. :-)

Thanks!

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

^ permalink raw reply

* Re: linux-next: Tree for October 29 (x86 posttest)
From: Stephen Rothwell @ 2009-11-10  2:08 UTC (permalink / raw)
  To: Masami Hiramatsu; +Cc: Randy Dunlap, linux-next, LKML
In-Reply-To: <4AF8B66B.3010405@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

Hi all,

On Mon, 09 Nov 2009 19:40:11 -0500 Masami Hiramatsu <mhiramat@redhat.com> wrote:
>
> Randy Dunlap wrote:
> > On Thu, 29 Oct 2009 12:48:12 -0400 Masami Hiramatsu wrote:
> >
> >> Randy Dunlap wrote:
> >>>
> >>> I'm getting this on x86_64:
> >>>
> >>>     TEST    posttest
> >>> Error: ffffffff810299e2:	f2 41 0f 28 52 b0    	repnz movaps -0x50(%r10),%xmm2
> >>> Error: objdump says 6 bytes, but insn_get_length() says 4 (attr:0)
> >>> make[2]: *** [posttest] Error 2
> >>
> >> Ah, that's should be fixed by AVX support patch which I've posted.
> >> http://git.kernel.org/tip/e0e492e99b372c6990a5daca9e4683c341f1330e
> >
> > Has that been merged into linux-next?
> > I'm still seeing this failure in linux-next-20091106.
> 
> I checked it has been merged.
> So, it should disappear from linux-next-20091109. :-)

That commit (e0e492e99b372c6990a5daca9e4683c341f1330e "x86: AVX
instruction set decoder support") has been in linux-next since
next-20091104, so if Randy's problem still existed in next-20091106, then
it may be a different problem.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: rr tree build warnings
From: Rusty Russell @ 2009-11-10  2:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20091109183104.2bf7add6.sfr@canb.auug.org.au>

On Mon, 9 Nov 2009 06:01:04 pm Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> 
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> drivers/usb/storage/libusual.c:239: warning: passing argument 1 of '__check_old_set_param' from incompatible pointer type
> include/linux/moduleparam.h:165: note: expected 'int (*)(const char *, struct kernel_param *)' but argument is of type 'int (*)(const char *, const struct kernel_param *)'
> 
> Introduced by commit 9f94999724555729819ea0143eab1d0529c029d1
> ("param:param_ops").

Thanks Stephen!  Overzealous conversion; harmless but annoying.

I've fixed this properly now...
Rusty.

^ permalink raw reply

* Re: linux-next: rr tree build warnings
From: Rusty Russell @ 2009-11-10  2:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Sam Ravnborg
In-Reply-To: <20091109184046.2a802372.sfr@canb.auug.org.au>

On Mon, 9 Nov 2009 06:10:46 pm Stephen Rothwell wrote:
> I am also getting some section mismatch warnings like this:
> 
> WARNING: drivers/mtd/ubi/ubi.o(.data+0x1c0): Section mismatch in reference from the variable __ops_mtd to the function .init.text:ubi_mtd_param_parse()
> The variable __ops_mtd references
> the function __init ubi_mtd_param_parse()

Right.  This needs a new rule in modpost; here's what I've added:

diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -97,10 +97,10 @@ struct kparam_array
 
 /* Obsolete - use module_param_cb() */
 #define module_param_call(name, set, get, arg, perm)			\
-	static struct kernel_param_ops __ops_##name =			\
+	static struct kernel_param_ops __param_ops_##name =		\
 		 { (void *)set, (void *)get };				\
 	__module_param_call(MODULE_PARAM_PREFIX,			\
-			    name, &__ops_##name, arg,			\
+			    name, &__param_ops_##name, arg,		\
 			    __same_type(*(arg), bool),			\
 			    (perm) + sizeof(__check_old_set_param(set))*0)
 
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -951,6 +951,13 @@ static int section_mismatch(const char *
  *   fromsec = .data*
  *   atsym   =__param*
  *
+ * Pattern 1a:
+ *   module_param_call() ops can refer to __init set function if permissions=0
+ *   The pattern is identified by:
+ *   tosec   = .init.text
+ *   fromsec = .data*
+ *   atsym   = __param_ops_*
+ *
  * Pattern 2:
  *   Many drivers utilise a *driver container with references to
  *   add, remove, probe functions etc.
@@ -984,6 +991,12 @@ static int secref_whitelist(const char *
 	    (strncmp(fromsym, "__param", strlen("__param")) == 0))
 		return 0;
 
+	/* Check for pattern 1a */
+	if (strcmp(tosec, ".init.text") == 0 &&
+	    match(fromsec, data_sections) &&
+	    (strncmp(fromsym, "__param_ops_", strlen("__param_ops_")) == 0))
+		return 0;
+
 	/* Check for pattern 2 */
 	if (match(tosec, init_exit_sections) &&
 	    match(fromsec, data_sections) &&

^ permalink raw reply

* linux-next: new tree: sysctl
From: Stephen Rothwell @ 2009-11-10  4:33 UTC (permalink / raw)
  To: linux-next
  Cc: LKML, Eric W. Biederman, linux-arch, Benjamin Herrenschmidt,
	Paul Mackerras, Tony Luck, Fenghua Yu, Ralf Baechle,
	Kyle McMartin, Thibaut Varene, Carsten Otte,
	Christian Borntraeger, David S. Miller, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

Hi all,

Eric has requested that the tree at
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/sysctl-2.6.git#master
be added to linux-next and I will add it from today.

Before anyone else jumps to the wrong conclusion (as I did :-)) this tree
currently only contains the set of patches posted in the thread "generic
compat_sys_sysctl".
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: linux-next: Tree for October 29 (x86 posttest)
From: Masami Hiramatsu @ 2009-11-10  4:55 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Randy Dunlap, linux-next, LKML
In-Reply-To: <20091110130841.81d76a4b.sfr@canb.auug.org.au>

Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 09 Nov 2009 19:40:11 -0500 Masami Hiramatsu<mhiramat@redhat.com>  wrote:
>>
>> Randy Dunlap wrote:
>>> On Thu, 29 Oct 2009 12:48:12 -0400 Masami Hiramatsu wrote:
>>>
>>>> Randy Dunlap wrote:
>>>>>
>>>>> I'm getting this on x86_64:
>>>>>
>>>>>      TEST    posttest
>>>>> Error: ffffffff810299e2:	f2 41 0f 28 52 b0    	repnz movaps -0x50(%r10),%xmm2
>>>>> Error: objdump says 6 bytes, but insn_get_length() says 4 (attr:0)
>>>>> make[2]: *** [posttest] Error 2
>>>>
>>>> Ah, that's should be fixed by AVX support patch which I've posted.
>>>> http://git.kernel.org/tip/e0e492e99b372c6990a5daca9e4683c341f1330e
>>>
>>> Has that been merged into linux-next?
>>> I'm still seeing this failure in linux-next-20091106.
>>
>> I checked it has been merged.
>> So, it should disappear from linux-next-20091109. :-)
> 
> That commit (e0e492e99b372c6990a5daca9e4683c341f1330e "x86: AVX
> instruction set decoder support") has been in linux-next since
> next-20091104, so if Randy's problem still existed in next-20091106, then
> it may be a different problem.

Hmm, this seems a bad sequence, movaps can't have repnz prefix,
since movaps is not string operation... It might happen since
AVX opcodes supporting processors are not released yet.

Anyway, I think we'd better change the posttest to report it
as warning instead of errors.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

^ permalink raw reply

* Re: linux-next: rr tree build warnings
From: Sam Ravnborg @ 2009-11-10  5:20 UTC (permalink / raw)
  To: Rusty Russell; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <200911101250.58516.rusty@rustcorp.com.au>

On Tue, Nov 10, 2009 at 12:50:58PM +1030, Rusty Russell wrote:
> On Mon, 9 Nov 2009 06:10:46 pm Stephen Rothwell wrote:
> > I am also getting some section mismatch warnings like this:
> > 
> > WARNING: drivers/mtd/ubi/ubi.o(.data+0x1c0): Section mismatch in reference from the variable __ops_mtd to the function .init.text:ubi_mtd_param_parse()
> > The variable __ops_mtd references
> > the function __init ubi_mtd_param_parse()
> 
> Right.  This needs a new rule in modpost; here's what I've added:

Looks fine.

Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox