* linux-next: manual merge of the boot-params tree
From: Stephen Rothwell @ 2008-12-18 9:35 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Paul Mundt
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Hi Rusty,
Today's linux-next merge of the boot-params tree got a conflict in
arch/sh/boards/mach-microdev/setup.c between commit
cee3e05ee0c727945280b754b3d4bfe0d7bcb622 ("sh: mach-microdev: Split out
the fdc37c93xapm initialization code") from the sh tree and commit
0de5c2d9f02d2018fd671ca1015432dffa5eb338 ("param:
arch_get_boot_command_line()") from the boot-params tree.
The former removed the code that the latter changed.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for December 15 (mfd)
From: Samuel Ortiz @ 2008-12-18 9:45 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <20081217114300.9476f8da.randy.dunlap@oracle.com>
On Wed, Dec 17, 2008 at 11:43:00AM -0800, Randy Dunlap wrote:
> On Mon, 15 Dec 2008 11:26:34 -0800 Randy Dunlap wrote:
>
> > Lots of mfd build failures like this:
> >
> >
> > build-r7123.out:/local/linsrc/linux-next-20081215/drivers/mfd/twl4030-irq.c:183: error: 'irq_desc' undeclared (first use in this function)
> > build-r7123.out:/local/linsrc/linux-next-20081215/drivers/mfd/twl4030-irq.c:455: error: 'irq_desc' undeclared (first use in this function)
> > build-r7123.out:/local/linsrc/linux-next-20081215/drivers/mfd/twl4030-irq.c:515: error: 'irq_desc' undeclared (first use in this function)
> > build-r7123.out:make[3]: *** [drivers/mfd/twl4030-irq.o] Error 1
>
>
> This build error still happens in linux-next-20081217.
>
> It only occurs when I2C=y (see drivers/mfd/Kconfig).
>
> Stephen, doing an allyesconfig i386 or x86_64 build will catch this,
> then you can drop the mfd tree and hopefully prod someone into fixing this...
Sorry for the delay, I was away from the interweb for the last 2 days.
I'll look into it.
Cheers,
Samuel.
> ---
> ~Randy
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [BUILD-FAILURE] next-20081217-s390x-'struct device' has no member named 'knode_parent'
From: Martin Schwidefsky @ 2008-12-18 9:47 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Stephen Rothwell, linux-next, LKML, linux-s390, heiko.carstens
In-Reply-To: <20081217181745.GA18420@linux.vnet.ibm.com>
On Wed, 2008-12-17 at 23:47 +0530, Kamalesh Babulal wrote:
> drivers/s390/cio/device.c: In function 'io_subchannel_register':
> drivers/s390/cio/device.c:913: error: 'struct device' has no member
> named 'knode_parent'
> make[2]: *** [drivers/s390/cio/device.o] Error 1
> make[1]: *** [drivers/s390/cio] Error 2
> make: *** [drivers/s390] Error 2
Should be fixed now by the following patch from Cornelia:
commit efe46b59567ae999ff7d344170d21f093159ad80
Author: Cornelia Huck <cornelia.huck@de.ibm.com>
Date: Thu Dec 18 10:26:55 2008 +0100
[S390] cio: Use device_is_registered().
Check if a ccw device is registered via device_is_registered()
and not via the old kludge of checking the membership in driver
core internal klists.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
You'll find the fix in the features branch of git390 which will be
included in the next linux-next kernel.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: linux-next: rr series import failure
From: Ingo Molnar @ 2008-12-18 10:36 UTC (permalink / raw)
To: Rusty Russell
Cc: Mike Travis, Stephen Rothwell, linux-next, Ingo Molnar, Greg KH
In-Reply-To: <200812181119.16550.rusty@rustcorp.com.au>
* Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Thursday 18 December 2008 10:57:25 Mike Travis wrote:
> > > cpumask:add_sysfs_displays_for_configured_and_disabled_cpu_maps.patch
> > Rusty - do you want to do this in your rr queue?
>
> Once Greg's happy and Ack'ed, and we've run it through normal tests,
> I'll put it in the cpumask git tree and Ingo can simply merge it from
> there.
>
> Thanks,
> Rusty.
perfect, thanks Rusty!
Ingo
^ permalink raw reply
* Re: linux-next: Tree for December 15 (mfd)
From: Samuel Ortiz @ 2008-12-18 10:57 UTC (permalink / raw)
To: Randy Dunlap, David Brownell; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <20081217114300.9476f8da.randy.dunlap@oracle.com>
On Wed, Dec 17, 2008 at 11:43:00AM -0800, Randy Dunlap wrote:
> On Mon, 15 Dec 2008 11:26:34 -0800 Randy Dunlap wrote:
>
> > Lots of mfd build failures like this:
> >
> >
> > build-r7123.out:/local/linsrc/linux-next-20081215/drivers/mfd/twl4030-irq.c:183: error: 'irq_desc' undeclared (first use in this function)
> > build-r7123.out:/local/linsrc/linux-next-20081215/drivers/mfd/twl4030-irq.c:455: error: 'irq_desc' undeclared (first use in this function)
> > build-r7123.out:/local/linsrc/linux-next-20081215/drivers/mfd/twl4030-irq.c:515: error: 'irq_desc' undeclared (first use in this function)
> > build-r7123.out:make[3]: *** [drivers/mfd/twl4030-irq.o] Error 1
>
>
> This build error still happens in linux-next-20081217.
It should be fixed with the latest mfd tree.
David, are you ok with this fix:
http://git.o-hand.com/cgit.cgi/linux-mfd/commit/?h=for-next&id=1e6b6a411fd4f6f99e4d9f003946823007e3c34f
Cheers,
Samuel.
> It only occurs when I2C=y (see drivers/mfd/Kconfig).
>
> Stephen, doing an allyesconfig i386 or x86_64 build will catch this,
> then you can drop the mfd tree and hopefully prod someone into fixing this...
>
> ---
> ~Randy
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: linux-next: Tree for December 15 (mfd)
From: David Brownell @ 2008-12-18 11:02 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML
In-Reply-To: <20081218105700.GC2517@sortiz.org>
On Thursday 18 December 2008, Samuel Ortiz wrote:
> David, are you ok with this fix:
> http://git.o-hand.com/cgit.cgi/linux-mfd/commit/?h=for-next&id=1e6b6a411fd4f6f99e4d9f003946823007e3c34f
I'd rather remove that "if (can't happen) { pr_err, return }"
code myself ... otherwise, sure.
- Dave
^ permalink raw reply
* linux-next: kvm tree build failure
From: Stephen Rothwell @ 2008-12-18 11:05 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-next, Jan Kiszka, kvm
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
Hi Avi,
Today's linux-next build (powerpc ppc44x_config) failed like this:
In file included from include/linux/kvm_host.h:27,
from arch/powerpc/include/asm/kvm_44x.h:23,
from arch/powerpc/kernel/asm-offsets.c:52:
arch/powerpc/include/asm/kvm_host.h:203: error: redefinition of 'struct kvm_guest_debug'
Caused by commit 887e823e3f9c402ff2fe1ea2dc25072ebe81b5b1 ("KVM: New
guest debug interface") which added struct kvm_guest_debug to
include/linux/kvm.h but didn't remove it from
arch/powerpc/include/asm/kvm_host.h. (ia64 and s390 probably have the
same problem.)
I have reverted the kvm tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] KVM: Remove old kvm_guest_debug structs (was: linux-next: kvm tree build failure)
From: Jan Kiszka @ 2008-12-18 11:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Avi Kivity, linux-next, kvm
In-Reply-To: <20081218220526.b97c69e4.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (powerpc ppc44x_config) failed like this:
>
> In file included from include/linux/kvm_host.h:27,
> from arch/powerpc/include/asm/kvm_44x.h:23,
> from arch/powerpc/kernel/asm-offsets.c:52:
> arch/powerpc/include/asm/kvm_host.h:203: error: redefinition of 'struct kvm_guest_debug'
>
> Caused by commit 887e823e3f9c402ff2fe1ea2dc25072ebe81b5b1 ("KVM: New
> guest debug interface") which added struct kvm_guest_debug to
> include/linux/kvm.h but didn't remove it from
> arch/powerpc/include/asm/kvm_host.h. (ia64 and s390 probably have the
> same problem.)
>
> I have reverted the kvm tree for today.
Yes, missed them. This patch should cure the issue.
Jan
--------->
Remove the remaining arch fragments of the old guest debug interface
that now break non-x86 builds.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
arch/ia64/include/asm/kvm_host.h | 2 --
arch/powerpc/include/asm/kvm_host.h | 6 ------
arch/s390/include/asm/kvm_host.h | 3 ---
3 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 0560f3f..f262efe 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -235,8 +235,6 @@ struct kvm_vm_data {
struct kvm;
struct kvm_vcpu;
-struct kvm_guest_debug{
-};
struct kvm_mmio_req {
uint64_t addr; /* physical address */
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index c1e436f..a226005 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -200,10 +200,4 @@ struct kvm_vcpu_arch {
unsigned long pending_exceptions;
};
-struct kvm_guest_debug {
- int enabled;
- unsigned long bp[4];
- int singlestep;
-};
-
#endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 3c55e41..c6e674f 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -21,9 +21,6 @@
/* memory slots that does not exposed to userspace */
#define KVM_PRIVATE_MEM_SLOTS 4
-struct kvm_guest_debug {
-};
-
struct sca_entry {
atomic_t scn;
__u64 reserved;
--
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux
^ permalink raw reply related
* Re: [PATCH] KVM: Remove old kvm_guest_debug structs
From: Avi Kivity @ 2008-12-18 11:40 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Stephen Rothwell, Avi Kivity, linux-next, kvm
In-Reply-To: <494A34FE.3040607@siemens.com>
Jan Kiszka wrote:
> Remove the remaining arch fragments of the old guest debug interface
> that now break non-x86 builds.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* linux-next: Tree for December 18
From: Stephen Rothwell @ 2008-12-18 12:06 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8897 bytes --]
Hi all,
Changes since 20081217:
New tree:
fscache
Undropped tree:
nommu
boot-params
Dropped trees (temporarily):
scsi (build problem)
mtd (build problems)
kvm (build problem)
rr (quilt series import problem)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
perfmon3 (concerns from the x86 team)
audit (difficult conflicts)
The sound tree lost its conflict and merge fixup patch.
The watchdog tree lost its conflict.
The boot-params tree gained a conflict against the sh tree but lost its
build problems.
The kvm tree gained a build problem and was dropped.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-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,
44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 134 trees (counting Linus' and 15 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 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/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging audit-current/for-linus
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
CONFLICT (content): Merge conflict in drivers/char/Makefile
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in arch/powerpc/platforms/85xx/mpc85xx_mds.c
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in scripts/recordmcount.pl
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/xfs_rename.c
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in arch/x86/kernel/reboot.c
Merging dlm/next
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (delete/modify): arch/sparc64/kernel/idprom.c deleted in HEAD and modified in net/master. Version net/master of arch/sparc64/kernel/idprom.c left in tree.
CONFLICT (content): Merge conflict in fs/lockd/host.c
CONFLICT (content): Merge conflict in fs/lockd/mon.c
$ git rm -f arch/sparc64/kernel/idprom.c
Applying: net: async_tx merge fix
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging rr_cpumask/master
CONFLICT (content): Merge conflict in arch/x86/kernel/io_apic.c
CONFLICT (content): Merge conflict in kernel/sched.c
CONFLICT (content): Merge conflict in kernel/sched_stats.h
Merging cifs/master
CONFLICT (content): Merge conflict in fs/cifs/connect.c
Applying: cifs: update for new IP4/6 address printing
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/ioctl.c
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/bio.c
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/net/tg3.c
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
Merging pcmcia/master
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 kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
CONFLICT (content): Merge conflict in fs/cifs/cifs_fs_sb.h
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_cred.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_globals.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_ioctl.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.h
Merging lblnet/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging quilt/ttydev
CONFLICT (content): Merge conflict in fs/devpts/inode.c
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
CONFLICT (content): Merge conflict in kernel/sched.c
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
CONFLICT (content): Merge conflict in Documentation/sysctl/vm.txt
CONFLICT (content): Merge conflict in kernel/fork.c
Merging boot-params/master
CONFLICT (content): Merge conflict in arch/arm/kernel/setup.c
CONFLICT (content): Merge conflict in arch/parisc/kernel/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-microdev/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-migor/setup.c
CONFLICT (content): Merge conflict in init/main.c
Merging trivial/for-next
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/winbond/linux/wbusb.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/winbond/linux/wbusb.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211netdev.c
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211wext.c
$ git rm -f drivers/staging/winbond/linux/wbusb.c
Merging scsi-post-merge/master
Merging fscache/master
Created commit b19a7ac: Revert "Merge commit 'kvm/master'"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [mmotm and linux-next][PATCH] irq: enclose irq_desc_lock_class in CONFIG_LOCKDEP
From: Ingo Molnar @ 2008-12-18 13:36 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Andrew Morton, Yinghai Lu, LKML, linux-next
In-Reply-To: <20081217193815.F674.KOSAKI.MOTOHIRO@jp.fujitsu.com>
* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > >> or, following #ifdef ?
> > >>
> > >> #if defined(CONFIG_SPARSE_IRQ) || defined(CONFIG_TRACE_IRQFLAGS)
> > >>
> > >> /*
> > >> * lockdep: we want to handle all irq_desc locks as a single lock-class:
> > >> */
> > >> static struct lock_class_key irq_desc_lock_class;
> > >
> > > instead of increasing the #ifdef jungle, how about removing some? For
> > > example is this distinction:
> > >
> > >> > #ifndef CONFIG_SPARSE_IRQ
> > >
> > > really needed? We should use symmetric lock class annotations, regardless
> > > of how irq_desc[] is laid out.
> >
> > it seems make much sense. I'll test your idea tommorow.
>
> Ingo, you are right. I confirmed your idea works well.
>
>
> I tested following ten pattern.
>
> o handle.c can compile without any warnings?
>
> SPARSE_IRQ TRACE_IRQ LOCKDEP
> ------------------------------------------
> n n n
> Y n n
> n Y n
> n n Y
> Y Y n
> N Y Y
> Y n Y
> Y Y Y
>
>
> o builded kernel works well? (tested on x86_64)
>
> SPARSE_IRQ TRACE_IRQ LOCKDEP
> ------------------------------------------
> n n n
> Y Y Y
>
>
> ==
> Subject: [PATCH] irq: remove unnecessary ifdef
Applied to tip/irq/sparseirq, thanks!
Ingo
^ permalink raw reply
* Re: [BUILD-FAILURE] next-20081217-s390x-'struct device' has no member named 'knode_parent'
From: Kamalesh Babulal @ 2008-12-18 17:17 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Stephen Rothwell, linux-next, LKML, linux-s390, heiko.carstens
In-Reply-To: <1229593665.7086.1.camel@localhost>
* Martin Schwidefsky <schwidefsky@de.ibm.com> [2008-12-18 10:47:45]:
> On Wed, 2008-12-17 at 23:47 +0530, Kamalesh Babulal wrote:
> > drivers/s390/cio/device.c: In function 'io_subchannel_register':
> > drivers/s390/cio/device.c:913: error: 'struct device' has no member
> > named 'knode_parent'
> > make[2]: *** [drivers/s390/cio/device.o] Error 1
> > make[1]: *** [drivers/s390/cio] Error 2
> > make: *** [drivers/s390] Error 2
>
> Should be fixed now by the following patch from Cornelia:
>
> commit efe46b59567ae999ff7d344170d21f093159ad80
> Author: Cornelia Huck <cornelia.huck@de.ibm.com>
> Date: Thu Dec 18 10:26:55 2008 +0100
>
> [S390] cio: Use device_is_registered().
>
> Check if a ccw device is registered via device_is_registered()
> and not via the old kludge of checking the membership in driver
> core internal klists.
>
> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
>
> You'll find the fix in the features branch of git390 which will be
> included in the next linux-next kernel.
Hi Martin,
Thanks, the patch fixes the build failure.I tested the patch with
today's next (20081218), which also has the same build failure.
>
> --
> blue skies,
> Martin.
>
> "Reality continues to ruin my life." - Calvin.
>
>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: linux-next: Tree for December 17 (DVB)
From: Randy Dunlap @ 2008-12-18 17:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: v4l-dvb-maintainer, mchehab, linux-next, LKML
In-Reply-To: <20081217161311.454e58ce.randy.dunlap@oracle.com>
On Wed, 17 Dec 2008 16:13:11 -0800 Randy Dunlap wrote:
> On Wed, 17 Dec 2008 23:25:36 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20081216:
> >
> > Undropped tree:
> > v4l-dvb
>
>
> build-r7329.out:/local/linsrc/linux-next-20081217/drivers/media/video/tuner-core.c:1111: error: 'tuner_ioctl' undeclared here (not in a function)
> build-r7329.out:make[4]: *** [drivers/media/video/tuner-core.o] Error 1
>
> config attached.
Same build error in next-20081218.
---
~Randy
^ permalink raw reply
* Re: linux-next: Tree for December 18 (slow-work)
From: Randy Dunlap @ 2008-12-18 17:21 UTC (permalink / raw)
To: Stephen Rothwell, dhowells; +Cc: linux-next, LKML
In-Reply-To: <20081218230637.c879a046.sfr@canb.auug.org.au>
when CONFIG_SYSCTL=n:
build-r7380.out:/local/linsrc/linux-next-20081218/kernel/slow-work.c:612: error: 'slow_work_max_max_threads' undeclared (first use in this function)
build-r7380.out:make[2]: *** [kernel/slow-work.o] Error 1
---
~Randy
^ permalink raw reply
* Re: linux-next: Tree for December 18 (fscache)
From: Randy Dunlap @ 2008-12-18 17:25 UTC (permalink / raw)
To: Stephen Rothwell, dhowells; +Cc: linux-next, LKML
In-Reply-To: <20081218230637.c879a046.sfr@canb.auug.org.au>
On Thu, 18 Dec 2008 23:06:37 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20081217:
>
> New tree:
> fscache
When CONFIG_BLOCK=n:
build-r7417.out:/local/linsrc/linux-next-20081218/fs/cachefiles/cf-interface.c:357: error: implicit declaration of function 'fsync_super'
build-r7417.out:make[3]: *** [fs/cachefiles/cf-interface.o] Error 1
Should include/linux/buffer_head.h have an empty stub for fsync_super()
or does fscache even make sense when CONFIG_BLOCK=n?
---
~Randy
^ permalink raw reply
* Re: linux-next: Tree for December 18 (slow-work)
From: David Howells @ 2008-12-18 17:45 UTC (permalink / raw)
To: Randy Dunlap; +Cc: dhowells, Stephen Rothwell, linux-next, LKML
In-Reply-To: <20081218092145.7e1566ef.randy.dunlap@oracle.com>
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> when CONFIG_SYSCTL=n:
>
> build-r7380.out:/local/linsrc/linux-next-20081218/kernel/slow-work.c:612: error: 'slow_work_max_max_threads' undeclared (first use in this function)
> build-r7380.out:make[2]: *** [kernel/slow-work.o] Error 1
Bah.
David
^ permalink raw reply
* Re: linux-next: Tree for December 18 (fscache)
From: David Howells @ 2008-12-18 17:47 UTC (permalink / raw)
To: Randy Dunlap; +Cc: dhowells, Stephen Rothwell, linux-next, LKML
In-Reply-To: <20081218092557.b274e9dd.randy.dunlap@oracle.com>
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Should include/linux/buffer_head.h have an empty stub for fsync_super()
> or does fscache even make sense when CONFIG_BLOCK=n?
FS-Cache might. CacheFiles probably doesn't.
There've been discussions about a separate caching backend to deal with
non-rotating media such as large chunks of battery-backed RAM or flash.
FS-Cache might make sense in such a situation as these could be accessed in
other ways (such as through MTD or even directly).
I'll make CONFIG_CACHEFILES dependent on CONFIG_BLOCK.
David
^ permalink raw reply
* Re: linux-next: Tree for December 17 (Radeon DRM BUG)
From: Bartlomiej Zolnierkiewicz @ 2008-12-18 19:00 UTC (permalink / raw)
To: Dave Airlie
Cc: Kevin Winchester, Stephen Rothwell, linux-next, LKML, Dave Airlie,
Andrew Morton
In-Reply-To: <21d7e9970812172247t3d67e6f0waffa99587e2e024b@mail.gmail.com>
On Thursday 18 December 2008, Dave Airlie wrote:
> On Thu, Dec 18, 2008 at 10:14 AM, Kevin Winchester
> <kjwinchester@gmail.com> wrote:
> > Stephen Rothwell wrote:
> >>
> >> Hi all,
> >>
> >>
> >
> > I get the following BUG in the radeon drm code with today's linux-next when
> > I run "startx". I have not built or tested linux-next in a while, but the
> > problem definitely does not occur in mainline.
[...]
This reminds me that drm tree in linux-next still results in BSOD (Black
Screen Of Death) on starting X for me (as reported on Saturday [1]).
Actually there is more to it as I discovered that my custom X radeon driver
(which is xorg-x11-drv-ati-6.9.0-61.fc10.i386 with "radeon: no need for this
anymore" from radeon-gem-cs change reverted, please see [2] for my previous
monologue) works fine while following stock driver versions:
xorg-x11-drv-ati-6.8.0-19.fc9.i386
xorg-x11-drv-ati-6.9.0-61.fc10.i386
xorg-x11-drv-ati-6.9.0-62.fc10.i386
result in BSOD. OTOH they all work with next-20081128 (modulo hangs with
fc10 ones when "radeon: no need for this anymore" change is not reverted).
[ BTW xorg-x11-drv-ati-6.9.0-62.fc10.i386 still causes hangs when used with
non-Fedora kernels and Fedora/kms kernel still has performance problems ]
IOW there are a lot of compatibility issues in recent drm/radeon changes.
Dave, could you please start looking into these problems? I'm sure that we
all want recent drm changes + kms in 2.6.29 but given tight schedule and the
way things are looking right now I'm quite sceptical...
[1] http://lkml.org/lkml/2008/12/13/76
[2] http://lkml.org/lkml/2008/12/13/77
Thanks,
Bart
^ permalink raw reply
* Re: linux-next: Tree for December 17 (Radeon DRM BUG)
From: Dave Airlie @ 2008-12-18 20:49 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Dave Airlie, Kevin Winchester, Stephen Rothwell, linux-next, LKML,
Andrew Morton
In-Reply-To: <200812182000.41727.bzolnier@gmail.com>
On Thu, 2008-12-18 at 20:00 +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 18 December 2008, Dave Airlie wrote:
> > On Thu, Dec 18, 2008 at 10:14 AM, Kevin Winchester
> > <kjwinchester@gmail.com> wrote:
> > > Stephen Rothwell wrote:
> > >>
> > >> Hi all,
> > >>
> > >>
> > >
> > > I get the following BUG in the radeon drm code with today's linux-next when
> > > I run "startx". I have not built or tested linux-next in a while, but the
> > > problem definitely does not occur in mainline.
>
> [...]
>
> This reminds me that drm tree in linux-next still results in BSOD (Black
> Screen Of Death) on starting X for me (as reported on Saturday [1]).
>
> Actually there is more to it as I discovered that my custom X radeon driver
> (which is xorg-x11-drv-ati-6.9.0-61.fc10.i386 with "radeon: no need for this
> anymore" from radeon-gem-cs change reverted, please see [2] for my previous
> monologue) works fine while following stock driver versions:
>
> xorg-x11-drv-ati-6.8.0-19.fc9.i386
> xorg-x11-drv-ati-6.9.0-61.fc10.i386
> xorg-x11-drv-ati-6.9.0-62.fc10.i386
>
> result in BSOD. OTOH they all work with next-20081128 (modulo hangs with
> fc10 ones when "radeon: no need for this anymore" change is not reverted).
>
> [ BTW xorg-x11-drv-ati-6.9.0-62.fc10.i386 still causes hangs when used with
> non-Fedora kernels and Fedora/kms kernel still has performance problems ]
>
> IOW there are a lot of compatibility issues in recent drm/radeon changes.
>
> Dave, could you please start looking into these problems? I'm sure that we
> all want recent drm changes + kms in 2.6.29 but given tight schedule and the
> way things are looking right now I'm quite sceptical...
>
> [1] http://lkml.org/lkml/2008/12/13/76
> [2] http://lkml.org/lkml/2008/12/13/77
>
Bart,
please file bugs in RH bugzilla for Fedora issues. Fedora is shipping
drivers that aren't upstream, and I'm attempting to resolve the issues
as they arise. However not having a bug to track stuff in means it just
goes far enough out of my inbox that I forget about it.
The revert isn't a fix for -ati, and I haven't seen any reports of
performance problems with profiles attached in my bugzilla.
I'm booting drm-next on more various radeon hw today to see what I can
reproduce, most of the kms changes for 2.6.29 are nothing to do with
radeon at all, we are only upstreaming KMS for Intel hw, so I'm not sure
what the sceptical bit is about. Its much more likely this is
multi-master changes before KMS that are interacting badly.
Dave.
> Thanks,
> Bart
^ permalink raw reply
* Re: linux-next: Tree for December 17 (Radeon DRM BUG)
From: Bartlomiej Zolnierkiewicz @ 2008-12-18 22:09 UTC (permalink / raw)
To: Dave Airlie
Cc: Dave Airlie, Kevin Winchester, Stephen Rothwell, linux-next, LKML,
Andrew Morton
In-Reply-To: <1229633355.5650.4.camel@optimus>
tOn Thursday 18 December 2008, Dave Airlie wrote:
> On Thu, 2008-12-18 at 20:00 +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 18 December 2008, Dave Airlie wrote:
> > > On Thu, Dec 18, 2008 at 10:14 AM, Kevin Winchester
> > > <kjwinchester@gmail.com> wrote:
> > > > Stephen Rothwell wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >>
> > > >
> > > > I get the following BUG in the radeon drm code with today's linux-next when
> > > > I run "startx". I have not built or tested linux-next in a while, but the
> > > > problem definitely does not occur in mainline.
> >
> > [...]
> >
> > This reminds me that drm tree in linux-next still results in BSOD (Black
> > Screen Of Death) on starting X for me (as reported on Saturday [1]).
> >
> > Actually there is more to it as I discovered that my custom X radeon driver
> > (which is xorg-x11-drv-ati-6.9.0-61.fc10.i386 with "radeon: no need for this
> > anymore" from radeon-gem-cs change reverted, please see [2] for my previous
> > monologue) works fine while following stock driver versions:
> >
> > xorg-x11-drv-ati-6.8.0-19.fc9.i386
> > xorg-x11-drv-ati-6.9.0-61.fc10.i386
> > xorg-x11-drv-ati-6.9.0-62.fc10.i386
> >
> > result in BSOD. OTOH they all work with next-20081128 (modulo hangs with
> > fc10 ones when "radeon: no need for this anymore" change is not reverted).
> >
> > [ BTW xorg-x11-drv-ati-6.9.0-62.fc10.i386 still causes hangs when used with
> > non-Fedora kernels and Fedora/kms kernel still has performance problems ]
> >
> > IOW there are a lot of compatibility issues in recent drm/radeon changes.
> >
> > Dave, could you please start looking into these problems? I'm sure that we
> > all want recent drm changes + kms in 2.6.29 but given tight schedule and the
> > way things are looking right now I'm quite sceptical...
> >
> > [1] http://lkml.org/lkml/2008/12/13/76
> > [2] http://lkml.org/lkml/2008/12/13/77
> >
>
> Bart,
>
> please file bugs in RH bugzilla for Fedora issues. Fedora is shipping
> drivers that aren't upstream, and I'm attempting to resolve the issues
> as they arise. However not having a bug to track stuff in means it just
> goes far enough out of my inbox that I forget about it.
OK, I'll try to put all issues into RH bugzilla once I find some time.
[ OTOH the hang issue mentioned above happens only with vanilla kernels,
Fedora kernels are not affected because they ship KMS. Anyway, you
could have just told me that you prefer to have a RH bugzilla bug for
it two weeks ago (and indeed KMS performance issue should have been
handled through bugzilla -- however this one is of lower priority). ]
> The revert isn't a fix for -ati, and I haven't seen any reports of
> performance problems with profiles attached in my bugzilla.
"isn't a fix" is a brave statement since it makes a difference between hang
within minutes and rock stable operation (sure the revert itself may not be
a proper fix but it works and is a good starting point). I spend quite some
time narrowing down the bug and this is not exactly the reaction I expected.
[ Well, I can fix/workaround the issues that I encounter quite quickly and I
don't really have to put extra time into narrowing them down so they can be
fixed in upstream distro if distro people don't see a value in such work. ]
> I'm booting drm-next on more various radeon hw today to see what I can
> reproduce, most of the kms changes for 2.6.29 are nothing to do with
> radeon at all, we are only upstreaming KMS for Intel hw, so I'm not sure
> what the sceptical bit is about. Its much more likely this is
F9 -> F10 upgrade has been a nightmare for me thanks to radeon/kms
changes (which are still Fedora specific stuff and it is good to hear
that they will not be upstreamed now).
On top of it drm-next tree has been broken for me since next-20081203
(yes, that is two weeks period!).
It could be just my luck and things may be working perfectly for 99.9%
of other people but are you still surprised that I'm sceptical?
> multi-master changes before KMS that are interacting badly.
Yes, multi-master changes are to blame but currently KMS patch depends on
them (though maybe it could be made independent -- I don't know this).
If you want me to try some debugging I will be happy to help but please
start taking more serious approach, and if you don't have the idea where
the problem is or don't have time to work on it currently please just
drop the broken changes from drm-next tree for now.
Thanks,
Bart
^ permalink raw reply
* Re: linux-next: Tree for December 17 (Radeon DRM BUG)
From: Dave Airlie @ 2008-12-18 23:39 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Dave Airlie, Kevin Winchester, Stephen Rothwell, linux-next, LKML,
Andrew Morton
In-Reply-To: <200812182309.23254.bzolnier@gmail.com>
On Thu, 2008-12-18 at 23:09 +0100, Bartlomiej Zolnierkiewicz wrote:
> tOn Thursday 18 December 2008, Dave Airlie wrote:
> > On Thu, 2008-12-18 at 20:00 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Thursday 18 December 2008, Dave Airlie wrote:
> > > > On Thu, Dec 18, 2008 at 10:14 AM, Kevin Winchester
> > > > <kjwinchester@gmail.com> wrote:
> > > > > Stephen Rothwell wrote:
> > > > >>
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >
> > > > > I get the following BUG in the radeon drm code with today's linux-next when
> > > > > I run "startx". I have not built or tested linux-next in a while, but the
> > > > > problem definitely does not occur in mainline.
> > >
> > > [...]
> > >
> > > This reminds me that drm tree in linux-next still results in BSOD (Black
> > > Screen Of Death) on starting X for me (as reported on Saturday [1]).
> > >
> > > Actually there is more to it as I discovered that my custom X radeon driver
> > > (which is xorg-x11-drv-ati-6.9.0-61.fc10.i386 with "radeon: no need for this
> > > anymore" from radeon-gem-cs change reverted, please see [2] for my previous
> > > monologue) works fine while following stock driver versions:
> > >
> > > xorg-x11-drv-ati-6.8.0-19.fc9.i386
> > > xorg-x11-drv-ati-6.9.0-61.fc10.i386
> > > xorg-x11-drv-ati-6.9.0-62.fc10.i386
> > >
> > > result in BSOD. OTOH they all work with next-20081128 (modulo hangs with
> > > fc10 ones when "radeon: no need for this anymore" change is not reverted).
> > >
> > > [ BTW xorg-x11-drv-ati-6.9.0-62.fc10.i386 still causes hangs when used with
> > > non-Fedora kernels and Fedora/kms kernel still has performance problems ]
> > >
> > > IOW there are a lot of compatibility issues in recent drm/radeon changes.
> > >
> > > Dave, could you please start looking into these problems? I'm sure that we
> > > all want recent drm changes + kms in 2.6.29 but given tight schedule and the
> > > way things are looking right now I'm quite sceptical...
> > >
> > > [1] http://lkml.org/lkml/2008/12/13/76
> > > [2] http://lkml.org/lkml/2008/12/13/77
> > >
> >
> > Bart,
> >
> > please file bugs in RH bugzilla for Fedora issues. Fedora is shipping
> > drivers that aren't upstream, and I'm attempting to resolve the issues
> > as they arise. However not having a bug to track stuff in means it just
> > goes far enough out of my inbox that I forget about it.
>
> OK, I'll try to put all issues into RH bugzilla once I find some time.
>
> [ OTOH the hang issue mentioned above happens only with vanilla kernels,
> Fedora kernels are not affected because they ship KMS. Anyway, you
> could have just told me that you prefer to have a RH bugzilla bug for
> it two weeks ago (and indeed KMS performance issue should have been
> handled through bugzilla -- however this one is of lower priority). ]
I know, literally I didn't see a mail in my inbox and forgot about this
bug until it showed up again, so I should mention Fedora BZ for Fedora
bugs earlier indeed..
drm-next should be fine in the next iteration, there was a missing patch
hunk in the last commit, and then a locking bug after that.
I'll try and look at the other stability issues you are seeing with
Fedora today,
however halving the amount of video RAM everyone gets as a fix for an
issue you are seeing is clearly not the answer, I'd like to actually
track down the root cause of where it went wrong.
Dave.
>
> > The revert isn't a fix for -ati, and I haven't seen any reports of
> > performance problems with profiles attached in my bugzilla.
>
> "isn't a fix" is a brave statement since it makes a difference between hang
> within minutes and rock stable operation (sure the revert itself may not be
> a proper fix but it works and is a good starting point). I spend quite some
> time narrowing down the bug and this is not exactly the reaction I expected.
>
> [ Well, I can fix/workaround the issues that I encounter quite quickly and I
> don't really have to put extra time into narrowing them down so they can be
> fixed in upstream distro if distro people don't see a value in such work. ]
>
> > I'm booting drm-next on more various radeon hw today to see what I can
> > reproduce, most of the kms changes for 2.6.29 are nothing to do with
> > radeon at all, we are only upstreaming KMS for Intel hw, so I'm not sure
> > what the sceptical bit is about. Its much more likely this is
>
> F9 -> F10 upgrade has been a nightmare for me thanks to radeon/kms
> changes (which are still Fedora specific stuff and it is good to hear
> that they will not be upstreamed now).
>
> On top of it drm-next tree has been broken for me since next-20081203
> (yes, that is two weeks period!).
>
> It could be just my luck and things may be working perfectly for 99.9%
> of other people but are you still surprised that I'm sceptical?
>
> > multi-master changes before KMS that are interacting badly.
>
> Yes, multi-master changes are to blame but currently KMS patch depends on
> them (though maybe it could be made independent -- I don't know this).
>
> If you want me to try some debugging I will be happy to help but please
> start taking more serious approach, and if you don't have the idea where
> the problem is or don't have time to work on it currently please just
> drop the broken changes from drm-next tree for now.
>
> Thanks,
> Bart
^ permalink raw reply
* Re: linux-next: Tree for December 18 (irq.h documentation)
From: Randy Dunlap @ 2008-12-18 23:57 UTC (permalink / raw)
To: Stephen Rothwell, Yinghai Lu; +Cc: linux-next, LKML, Ingo Molnar
In-Reply-To: <20081218230637.c879a046.sfr@canb.auug.org.au>
Hi YH,
Whenever you update a struct in a header file that uses kernel-doc,
like struct irq_desc in include/linux/irq.h, please also update the
corresponding kernel-doc notation for the new struct members, so
that kernel-doc warnings are not caused:
from linux-next-20081218:
Warning(linux-next-20081218//include/linux/irq.h:192): No description found for parameter 'timer_rand_state'
Warning(linux-next-20081218//include/linux/irq.h:192): No description found for parameter 'kstat_irqs'
Warning(linux-next-20081218//include/linux/irq.h:192): No description found for parameter 'irq_2_iommu'
Please add kernel-doc notation for those missing struct members.
Thanks,
---
~Randy
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: Stephen Rothwell @ 2008-12-19 0:05 UTC (permalink / raw)
To: dhowells
Cc: Andrew Morton, Bernd Schubert, nfsv4, hch, linux-kernel, steved,
linux-fsdevel, rwheeler, linux-next
In-Reply-To: <20081218152616.a24c013f.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
Hi David,
Given the ongoing discussions around FS-Cache, I have removed it from
linux-next. Please ask me to include it again (if sensible) once some
decision has been reached about its future.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for December 18 (patch: kernel-doc notation)
From: Randy Dunlap @ 2008-12-19 0:14 UTC (permalink / raw)
To: Stephen Rothwell, Dave Chinner; +Cc: linux-next, LKML, akpm
In-Reply-To: <20081218230637.c879a046.sfr@canb.auug.org.au>
fs/inode.c and mm/filemap.c need kernel-doc fixes.
What tree were these merged into for linux-next?
How do I get these doc fixes merged? (2 patches below)
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix fs/inode.c kernel-doc function parameters:
Warning(linux-next-20081218//fs/inode.c:120): No description found for parameter 'sb'
Warning(linux-next-20081218//fs/inode.c:120): No description found for parameter 'inode'
Warning(linux-next-20081218//fs/inode.c:588): No description found for parameter 'sb'
Warning(linux-next-20081218//fs/inode.c:588): No description found for parameter 'inode'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Dave Chinner <david@fromorbit.com>
---
fs/inode.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-next-20081218.orig/fs/inode.c
+++ linux-next-20081218/fs/inode.c
@@ -110,8 +110,8 @@ static void wake_up_inode(struct inode *
/**
* inode_init_always - perform inode structure intialisation
- * @sb - superblock inode belongs to.
- * @inode - inode to initialise
+ * @sb: superblock inode belongs to
+ * @inode: inode to initialise
*
* These are initializations that need to be done on every inode
* allocation as the fields are not initialised by slab allocation.
@@ -574,8 +574,8 @@ __inode_add_to_lists(struct super_block
/**
* inode_add_to_lists - add a new inode to relevant lists
- * @sb - superblock inode belongs to.
- * @inode - inode to mark in use
+ * @sb: superblock inode belongs to
+ * @inode: inode to mark in use
*
* When an inode is allocated it needs to be accounted for, added to the in use
* list, the owning superblock and the inode hash. This needs to be done under
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix mm/filemap.c functions' kernel-doc:
Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:575): No description found for parameter 'page'
Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:575): No description found for parameter 'waiter'
Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:2348): No description found for parameter 'mapping'
Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:2348): No description found for parameter 'index'
Warning(/local/linsrc/linux-next-20081218//mm/filemap.c:2348): No description found for parameter 'source'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Dave Chinner <david@fromorbit.com>
---
mm/filemap.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- linux-next-20081218.orig/mm/filemap.c
+++ linux-next-20081218/mm/filemap.c
@@ -566,8 +566,8 @@ EXPORT_SYMBOL(wait_on_page_bit);
/**
* add_page_wait_queue - Add an arbitrary waiter to a page's wait queue
- * @page - Page defining the wait queue of interest
- * @waiter - Waiter to add to the queue
+ * @page: Page defining the wait queue of interest
+ * @waiter: Waiter to add to the queue
*
* Add an arbitrary @waiter to the wait queue for the nominated @page.
*/
@@ -2328,11 +2328,10 @@ generic_file_buffered_write(struct kiocb
EXPORT_SYMBOL(generic_file_buffered_write);
/**
- * generic_file_buffered_write_one_page - Write a single page of data to an
- * inode
- * @mapping - The address space of the target inode
- * @index - The target page in the target inode to fill
- * @source - The data to write into the target page
+ * generic_file_buffered_write_one_page - Write a single page of data to an inode
+ * @mapping: The address space of the target inode
+ * @index: The target page in the target inode to fill
+ * @source: The data to write into the target page
*
* Write the data from the source page to the page in the nominated address
* space at the @index specified. Note that the file will not be extended if
^ permalink raw reply
* linux-next: perfmon3 tree removed
From: Stephen Rothwell @ 2008-12-19 0:20 UTC (permalink / raw)
To: stephane eranian; +Cc: linux-next, Thomas Gleixner, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
Hi Stephane,
Due to ongoing discussions and development, I have removed perfmon3 from
linux-next. This should be revisited when things settle back down again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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