* linux-next: manual merge of the tip tree with Linus' tree
From: Stephen Rothwell @ 2012-06-22 5:01 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, David Rientjes, Linus Torvalds,
Andrew Morton, Lee Schermerhorn
[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in mm/mempolicy.c
between commit c4c0e9e544a0 ("mm, mempolicy: fix mbind() to do
synchronous migration") from Linus' tree and various commits from the tip
tree.
The latter rewrote bits of this file, so I used it and effectively
reapplied the former patch (see below). I hope it came out right.
The diff of this file from the tip tree version looks like this (the
second hunk comes from the slab tree):
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 2218157..aeb58da 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1146,7 +1146,7 @@ long mpol_do_mbind(unsigned long start, unsigned long len,
else {
nr_failed = migrate_pages(&pagelist, new_vma_page,
(unsigned long)vma,
- false, true);
+ false, MIGRATE_SYNC);
}
}
@@ -1702,8 +1702,14 @@ static struct zonelist *policy_zonelist(gfp_t gfp, struct mempolicy *policy,
* task can change it's policy. The system default policy requires no
* such protection.
*/
-unsigned slab_node(struct mempolicy *policy)
+unsigned slab_node(void)
{
+ struct mempolicy *policy;
+
+ if (in_interrupt())
+ return numa_node_id();
+
+ policy = current->mempolicy;
if (!policy || policy->flags & MPOL_F_LOCAL)
return numa_node_id();
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/mempolicy.c
index bd92431,2218157..0000000
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@@ -1097,6 -1085,81 +1085,81 @@@ static struct page *new_vma_page(struc
}
#endif
+ long mpol_do_mbind(unsigned long start, unsigned long len,
+ struct mempolicy *new, unsigned long mode,
+ nodemask_t *nmask, unsigned long flags)
+ {
+ struct mm_struct *mm = current->mm;
+ struct vm_area_struct *vma;
+ int err, nr_failed = 0;
+ unsigned long end;
+ LIST_HEAD(pagelist);
+
+ len = (len + PAGE_SIZE - 1) & PAGE_MASK;
+ end = start + len;
+
+ if (end < start) {
+ err = -EINVAL;
+ goto mpol_out;
+ }
+
+ if (end == start) {
+ err = 0;
+ goto mpol_out;
+ }
+
+ if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) {
+ err = migrate_prep();
+ if (err)
+ goto mpol_out;
+ }
+
+ if (mode != MPOL_NOOP) {
+ NODEMASK_SCRATCH(scratch);
+ err = -ENOMEM;
+ if (scratch) {
+ task_lock(current);
+ err = mpol_set_nodemask(new, nmask, scratch);
+ task_unlock(current);
+ }
+ NODEMASK_SCRATCH_FREE(scratch);
+ if (err)
+ goto mpol_out;
+ }
+
+ vma = check_range(mm, start, end, nmask,
+ flags | MPOL_MF_INVERT, &pagelist);
+
+ err = PTR_ERR(vma); /* maybe ... */
+ if (IS_ERR(vma))
+ goto mpol_out_putback;
+
+ if (mode != MPOL_NOOP) {
+ err = mbind_range(mm, start, end, new);
+ if (err)
+ goto mpol_out_putback;
+ }
+
+ if (!list_empty(&pagelist)) {
+ if (flags & MPOL_MF_LAZY)
+ nr_failed = migrate_pages_unmap_only(&pagelist);
+ else {
+ nr_failed = migrate_pages(&pagelist, new_vma_page,
+ (unsigned long)vma,
- false, true);
++ false, MIGRATE_SYNC);
+ }
+ }
+
+ if (nr_failed && (flags & MPOL_MF_STRICT))
+ err = -EIO;
+
+ mpol_out_putback:
+ putback_lru_pages(&pagelist);
+
+ mpol_out:
+ return err;
+ }
+
static long do_mbind(unsigned long start, unsigned long len,
unsigned short mode, unsigned short mode_flags,
nodemask_t *nmask, unsigned long flags)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* linux-next: build failure after merge of the slave-dma tree
From: Stephen Rothwell @ 2012-06-22 3:00 UTC (permalink / raw)
To: Vinod Koul; +Cc: linux-next, linux-kernel, Zhangfei Gao, Leo Yan, Qiao Zhou
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
Hi Vinod,
After merging the slave-dma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/dma/mmp_tdma.c:21:27: fatal error: mach/regs-icu.h: No such file or directory
Caused by commit c6da0ba8dfc8 ("dmaengine: mmp_tdma: add mmp tdma
support").
I have used the slave-dma tree from next-20120621 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (powerpc related)
From: Michael Ellerman @ 2012-06-22 0:39 UTC (permalink / raw)
To: Alan Modra
Cc: Benjamin Herrenschmidt, Stephen Rothwell, linux-next, ppc-dev,
linux-kernel
In-Reply-To: <20120621114354.GG20973@bubble.grove.modra.org>
On Thu, 2012-06-21 at 21:13 +0930, Alan Modra wrote:
> On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote:
> > Linker bug. That's not a sibling call, but a normal function return
> > via an out-of-line register restore function.
>
> I couldn't see how this might be occurring, then I remembered the
> kernel has this horrible practise of using ld -r to package object
> files. So linker generated functions might be munged together with
> other functions. Does this help? (It won't if the kernel is
> providing its own save/restore functions.)
The kernel does provide its own AIUI.
cheers
^ permalink raw reply
* Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
From: Steven Rostedt @ 2012-06-22 0:29 UTC (permalink / raw)
To: paulmck
Cc: Fengguang Wu, ksummit-2012-discuss@lists.linux-foundation.org,
linux-next@vger.kernel.org
In-Reply-To: <20120622000320.GL2397@linux.vnet.ibm.com>
On Thu, 2012-06-21 at 17:03 -0700, Paul E. McKenney wrote:
> So you are suggesting:
>
> 3. Someone pulls from my tree (rcu/dev) whenever I push something,
> and tests the merge of all maintainers' commits.
>
> My rcu/dev branch is often just a preview of rcu/next, but I sometimes
> have longer lived topic branches (for example, the current rcu/idle
> branch with stuff related to Frederic's work). So maybe this tree
> needs to pull from all of my "rcu/" branches.
Exactly! :-)
-- Steve
^ permalink raw reply
* Re: [PATCH -next] pstore: fix printk format warning in ram.c
From: Randy Dunlap @ 2012-06-22 0:04 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Marco Stornelli, Kees Cook,
Andrew Morton
In-Reply-To: <4FDB8AB8.6060703@xenotime.net>
Greg,
This patch is still needed in linux-next.....
also:
Acked-by: Kees Cook <keescook@chromium.org>
On 06/15/2012 12:19 PM, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix printk format warning (on i386) in pstore:
>
> fs/pstore/ram.c:378:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> ---
> fs/pstore/ram.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20120615.orig/fs/pstore/ram.c
> +++ linux-next-20120615/fs/pstore/ram.c
> @@ -375,7 +375,7 @@ static int __init ramoops_probe(struct p
> goto fail_init_cprz;
>
> if (!cxt->przs && !cxt->cprz) {
> - pr_err("memory size too small, minimum is %lu\n",
> + pr_err("memory size too small, minimum is %zu\n",
> cxt->console_size + cxt->record_size);
> goto fail_cnt;
> }
>
--
~Randy
^ permalink raw reply
* Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
From: Paul E. McKenney @ 2012-06-22 0:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: Fengguang Wu, ksummit-2012-discuss@lists.linux-foundation.org,
linux-next@vger.kernel.org
In-Reply-To: <1340322348.27036.218.camel@gandalf.stny.rr.com>
On Thu, Jun 21, 2012 at 07:45:48PM -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 16:38 -0700, Paul E. McKenney wrote:
>
> > Let me make sure that I understand the current state:
> >
> > 1. Fengguang pulls from my tree (presumably from rcu/next)
> > whenever I push something. He tests my commits in isolation
> > from other maintainers' commits.
> >
> > 2. Stephen also pulls from my tree (rcu/next) whenever I push
> > something. However, Stephen tests the merge of all
> > maintainers' commits.
> >
> > So it sounds to me that Stephen is already doing the job that Steven
> > is suggesting should be done.
> >
> > So, what am I missing here?
>
> That linux-next is only for code that's ready for the next release
> cycle.
>
> What would be nice is a single public repository that holds development
> code that is not ready for the next release cycle, but is in a "working
> state". Basically, one of your "not for inclusion" changes.
>
> For those of us with test machines, it may be nice that we also perform
> some testing, as Fengguang may not hit all permutations that others may
> find.
So you are suggesting:
3. Someone pulls from my tree (rcu/dev) whenever I push something,
and tests the merge of all maintainers' commits.
My rcu/dev branch is often just a preview of rcu/next, but I sometimes
have longer lived topic branches (for example, the current rcu/idle
branch with stuff related to Frederic's work). So maybe this tree
needs to pull from all of my "rcu/" branches.
Thanx, Paul
^ permalink raw reply
* Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
From: Steven Rostedt @ 2012-06-21 23:45 UTC (permalink / raw)
To: paulmck
Cc: Fengguang Wu, ksummit-2012-discuss@lists.linux-foundation.org,
linux-next@vger.kernel.org
In-Reply-To: <20120621233841.GK2397@linux.vnet.ibm.com>
On Thu, 2012-06-21 at 16:38 -0700, Paul E. McKenney wrote:
> Let me make sure that I understand the current state:
>
> 1. Fengguang pulls from my tree (presumably from rcu/next)
> whenever I push something. He tests my commits in isolation
> from other maintainers' commits.
>
> 2. Stephen also pulls from my tree (rcu/next) whenever I push
> something. However, Stephen tests the merge of all
> maintainers' commits.
>
> So it sounds to me that Stephen is already doing the job that Steven
> is suggesting should be done.
>
> So, what am I missing here?
That linux-next is only for code that's ready for the next release
cycle.
What would be nice is a single public repository that holds development
code that is not ready for the next release cycle, but is in a "working
state". Basically, one of your "not for inclusion" changes.
For those of us with test machines, it may be nice that we also perform
some testing, as Fengguang may not hit all permutations that others may
find.
-- Steve
^ permalink raw reply
* Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
From: Paul E. McKenney @ 2012-06-21 23:38 UTC (permalink / raw)
To: Steven Rostedt
Cc: Fengguang Wu, ksummit-2012-discuss@lists.linux-foundation.org,
linux-next@vger.kernel.org
In-Reply-To: <1340293901.27036.182.camel@gandalf.stny.rr.com>
On Thu, Jun 21, 2012 at 11:51:41AM -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 23:26 +0800, Fengguang Wu wrote:
> > On Thu, Jun 21, 2012 at 10:04:26AM -0400, Steven Rostedt wrote:
> > > On Thu, 2012-06-21 at 21:38 +0800, Fengguang Wu wrote:
> > >
> > > > This is the 0-day kernel testing backend I recently started can help.
> > > >
> > > > It runs kernel build/boot tests on each developer's tree and tries to
> > > > find and report possible defects within 24 hours. The timely report
> > > > can effectively constraint the scope of impact to the related people,
> > > > rather than hurting the larger crowd of people in the integration tree.
> > >
> > > Perhaps you would be the perfect candidate to house a linux-devel.git
> > > repo. Have it set up like so:
> >
> > Actually Stephen jumps to my mind at the very start. He has all the
> > experiences, tools and infrastructure to maintain such a tree.
>
> I didn't want to burden him more ;-)
>
> >
> > The most important problem may be, how many developers we can attract
> > to send pull requests to linux-devel. It would be a good quiz in the KS :-)
>
> Agreed. Of course this is the chicken/egg problem. How do you know how
> many developers that it would attract without first doing it.
>
> So far I know of 1 (me ;-) And I think even GregKH said he liked the
> idea.
>
> >
> > FYI, I've added about 170 git trees as my test targets, which contain
> > about 550 active branches. I enjoy a lot looking at the freshly cooked
> > commits being compiled and ran to the degree to keep the servers busy
> > all day :-)
>
> What about trees like my own, where 'master' is very stale, and all the
> goodies happen in the other branches. And last I looked, in my public
> repo, I have 124 branches!
>
> >
> > > If you do not have the time to set up such a repo, I'm willing to do it.
> > > I just do not have the hardware to do the testing that should be done,
> > > but as it would be public, others could test it, and report back to me.
> >
> > Yeah either way is possible and I can sure carry out tests on it. But
> > IMHO Stephen could be the perfect candidate to maintain the tree :)
>
> If he wants to then sure. Otherwise it may become my hobby :-)
Let me make sure that I understand the current state:
1. Fengguang pulls from my tree (presumably from rcu/next)
whenever I push something. He tests my commits in isolation
from other maintainers' commits.
2. Stephen also pulls from my tree (rcu/next) whenever I push
something. However, Stephen tests the merge of all
maintainers' commits.
So it sounds to me that Stephen is already doing the job that Steven
is suggesting should be done.
So, what am I missing here?
Thanx, Paul
^ permalink raw reply
* Re: mmotm 2012-06-21-16-20 uploaded
From: Andrew Morton @ 2012-06-21 23:34 UTC (permalink / raw)
To: linux-kernel, linux-mm, linux-fsdevel, linux-next
In-Reply-To: <20120621232149.F0286A026A@akpm.mtv.corp.google.com>
On Thu, 21 Jun 2012 16:21:49 -0700
akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2012-06-21-16-20 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
Exciting updates to http://www.ozlabs.org/~akpm/mmotm/mmotm-readme.txt:
: The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
: contains daily snapshots of the -mm tree. It is updated more frequently
: than mmotm, and is untested.
It takes me 1.5 hours to 1.5 days to do a -mm release, depending on how
many screwups people have been merging and sending. This makes the
releases less frequent than I'd like.
So I will do daily dumps of the -mm patches into
http://www.ozlabs.org/~akpm/mmots/. They are the same as the mmotm
patches (use the same script), except they will be unannounced and
untested.
^ permalink raw reply
* mmotm 2012-06-21-16-20 uploaded
From: akpm @ 2012-06-21 23:21 UTC (permalink / raw)
To: mm-commits, linux-kernel, linux-mm, linux-fsdevel, linux-next
The mm-of-the-moment snapshot 2012-06-21-16-20 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
It contains the following patches against 3.5-rc3:
(patches marked "*" will be included in linux-next)
origin.patch
* selinux-fix-something.patch
linux-next.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
drivers-block-nvmec-stop-breaking-my-i386-build.patch
thermal-constify-type-argument-for-the-registration-routine.patch
* memory-hotplug-fix-invalid-memory-access-caused-by-stale-kswapd-pointer.patch
* memory-hotplug-fix-invalid-memory-access-caused-by-stale-kswapd-pointer-fix.patch
* drivers-rtc-rtc-spearc-fix-use-after-free-in-spear_rtc_remove.patch
* mn10300-move-setup_jiffies_interrupt-to-cevt-mn10300c.patch
* mn10300-remove-duplicate-definition-of-ptrace_o_tracesysgood.patch
* mn10300-kernel-internalh-needs-linux-irqreturnh.patch
* mn10300-kernel-trapsc-needs-linux-exporth.patch
* mn10300-mm-dma-allocc-needs-linux-exporth.patch
* mn10300-use-elif-definedconfig_-instead-of-elif-config_.patch
* ocfs2-fix-null-pointer-dereferrence-in-__ocfs2_change_file_space.patch
* c-r-prctl-less-paranoid-prctl_set_mm_exe_file.patch
* drivers-gpio-devresc-export-devm_gpio_request_one-to-modules.patch
* mm-thp-abort-compaction-if-migration-page-cannot-be-charged-to-memcg.patch
* fs-jbd2-commitc-use-new-kmap_atomic-api.patch
* cciss-fix-incorrect-scsi-status-reporting.patch
* drivers-media-video-pmsc-needs-linux-slabh.patch
* arch-x86-platform-iris-irisc-register-a-platform-device-and-a-platform-driver.patch
* arch-x86-include-asm-spinlockh-fix-comment.patch
* arch-x86-kernel-cpu-perf_event_intel_uncoreh-make-uncore_pmu_hrtimer_interval-64-bit.patch
cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch
* timeconstpl-remove-deprecated-defined-array.patch
* time-dont-inline-export_symbol-functions.patch
* thermal-fix-potential-out-of-bounds-memory-access.patch
* ocfs2-use-find_last_bit.patch
* ocfs2-use-bitmap_weight.patch
* drivers-scsi-ufs-use-module_pci_driver.patch
* drivers-scsi-ufs-reverse-the-ufshcd_is_device_present-logic.patch
* ufs-fix-incorrect-return-value-about-success-and-failed.patch
* drivers-scsi-atp870uc-fix-bad-use-of-udelay.patch
* vfs-increment-iversion-when-a-file-is-truncated.patch
* fs-push-rcu_barrier-from-deactivate_locked_super-to-filesystems.patch
* hfs-push-lock_super-down.patch
* hfs-get-rid-of-lock_super.patch
* hfs-remove-extra-mdb-write-on-unmount.patch
* hfs-simplify-a-bit-checking-for-r-o.patch
* hfs-introduce-vfs-superblock-object-back-reference.patch
* hfs-get-rid-of-hfs_sync_super.patch
* hfs-get-rid-of-hfs_sync_super-checkpatch-fixes.patch
* fs-xattrc-getxattr-improve-handling-of-allocation-failures.patch
* fs-add-link-restrictions.patch
* mm-slab-remove-duplicate-check.patch
* slab-move-full-state-transition-to-an-initcall.patch
mm.patch
* vmalloc-walk-vmap_areas-by-sorted-list-instead-of-rb_next.patch
* mm-make-vb_alloc-more-foolproof.patch
* mm-make-vb_alloc-more-foolproof-fix.patch
* memcg-rename-mem_cgroup_stat_swapout-as-mem_cgroup_stat_swap.patch
* memcg-rename-mem_cgroup_charge_type_mapped-as-mem_cgroup_charge_type_anon.patch
* memcg-remove-mem_cgroup_charge_type_force.patch
* swap-allow-swap-readahead-to-be-merged.patch
* documentation-update-how-page-cluster-affects-swap-i-o.patch
* mm-account-the-total_vm-in-the-vm_stat_account.patch
* mm-compaction-handle-incorrect-migrate_unmovable-type-pageblocks.patch
* mm-compaction-handle-incorrect-migrate_unmovable-type-pageblocks-fix.patch
* mm-buddy-cleanup-on-should_fail_alloc_page.patch
* mm-prepare-for-removal-of-obsolete-proc-sys-vm-nr_pdflush_threads.patch
* hugetlb-rename-max_hstate-to-hugetlb_max_hstate.patch
* hugetlb-dont-use-err_ptr-with-vm_fault-values.patch
* hugetlb-add-an-inline-helper-for-finding-hstate-index.patch
* hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages.patch
* hugetlb-avoid-taking-i_mmap_mutex-in-unmap_single_vma-for-hugetlb.patch
* hugetlb-simplify-migrate_huge_page.patch
* hugetlb-add-a-list-for-tracking-in-use-hugetlb-pages.patch
* hugetlb-make-some-static-variables-global.patch
* hugetlb-make-some-static-variables-global-mark-hugelb_max_hstate-__read_mostly.patch
* mm-hugetlb-add-new-hugetlb-cgroup.patch
* mm-hugetlb-add-new-hugetlb-cgroup-mark-root_h_cgroup-static.patch
* hugetlb-cgroup-add-the-cgroup-pointer-to-page-lru.patch
* hugetlb-cgroup-add-charge-uncharge-routines-for-hugetlb-cgroup.patch
* hugetlb-cgroup-add-support-for-cgroup-removal.patch
* hugetlb-cgroup-add-hugetlb-cgroup-control-files.patch
* hugetlb-cgroup-migrate-hugetlb-cgroup-info-from-oldpage-to-new-page-during-migration.patch
* hugetlb-cgroup-add-hugetlb-controller-documentation.patch
* hugetlb-move-all-the-in-use-pages-to-active-list.patch
* hugetlb-cgroup-assign-the-page-hugetlb-cgroup-when-we-move-the-page-to-active-list.patch
* hugetlb-cgroup-remove-exclude-and-wakeup-rmdir-calls-from-migrate.patch
* mm-oom-do-not-schedule-if-current-has-been-killed.patch
* mm-memblockc-memblock_double_array-cosmetic-cleanups.patch
* memcg-remove-check-for-signal_pending-during-rmdir.patch
* memcg-clean-up-force_empty_list-return-value-check.patch
* memcg-mem_cgroup_move_parent-doesnt-need-gfp_mask.patch
* memcg-make-mem_cgroup_force_empty_list-return-bool.patch
* memcg-make-mem_cgroup_force_empty_list-return-bool-fix.patch
* mm-compaction-cleanup-on-compaction_deferred.patch
* memcg-prevent-oom-with-too-many-dirty-pages.patch
* tmpfs-implement-numa-node-interleaving.patch
* tmpfs-implement-numa-node-interleaving-fix.patch
* avr32-mm-faultc-port-oom-changes-to-do_page_fault.patch
* avr32-mm-faultc-port-oom-changes-to-do_page_fault-fix.patch
* clk-add-non-config_have_clk-routines.patch
* clk-remove-redundant-depends-on-from-drivers-kconfig.patch
* i2c-i2c-pxa-remove-conditional-compilation-of-clk-code.patch
* usb-marvell-remove-conditional-compilation-of-clk-code.patch
* usb-musb-remove-conditional-compilation-of-clk-code.patch
* ata-pata_arasan-remove-conditional-compilation-of-clk-code.patch
* net-c_can-remove-conditional-compilation-of-clk-code.patch
* net-stmmac-remove-conditional-compilation-of-clk-code.patch
* gadget-m66592-remove-conditional-compilation-of-clk-code.patch
* gadget-r8a66597-remove-conditional-compilation-of-clk-code.patch
* usb-host-r8a66597-remove-conditional-compilation-of-clk-code.patch
* clk-validate-pointer-in-__clk_disable.patch
* nmi-watchdog-fix-for-lockup-detector-breakage-on-resume.patch
* kmsg-dev-kmsg-properly-return-possible-copy_from_user-failure.patch
* printk-add-generic-functions-to-find-kern_level-headers.patch
* printk-add-generic-functions-to-find-kern_level-headers-fix.patch
* printk-add-kern_levelsh-to-make-kern_level-available-for-asm-use.patch
* arch-remove-direct-definitions-of-kern_level-uses.patch
* btrfs-use-printk_get_level-and-printk_skip_level-add-__printf-fix-fallout.patch
* btrfs-use-printk_get_level-and-printk_skip_level-add-__printf-fix-fallout-fix.patch
* btrfs-use-printk_get_level-and-printk_skip_level-add-__printf-fix-fallout-checkpatch-fixes.patch
* sound-use-printk_get_level-and-printk_skip_level.patch
* printk-convert-the-format-for-kern_level-to-a-2-byte-pattern.patch
* printk-only-look-for-prefix-levels-in-kernel-messages.patch
* printk-remove-the-now-unnecessary-c-annotation-for-kern_cont.patch
* vsprintf-add-%pmr-for-bluetooth-mac-address.patch
* vsprintf-add-%pmr-for-bluetooth-mac-address-fix.patch
* lib-vsprintfc-remind-people-to-update-documentation-printk-formatstxt-when-adding-printk-formats.patch
* drivers-video-backlight-atmel-pwm-blc-use-devm_-functions.patch
* drivers-video-backlight-ot200_blc-use-devm_-functions.patch
* drivers-video-backlight-lm3533_blc-use-devm_-functions.patch
* backlight-atmel-pwm-bl-use-devm_gpio_request.patch
* backlight-ot200_bl-use-devm_gpio_request.patch
* backlight-tosa_lcd-use-devm_gpio_request.patch
* backlight-tosa_bl-use-devm_gpio_request.patch
* backlight-lms283gf05-use-devm_gpio_request.patch
* backlight-corgi_lcd-use-devm_gpio_request.patch
* backlight-l4f00242t03-use-devm_gpio_request_one.patch
* string-introduce-memweight.patch
* string-introduce-memweight-fix.patch
* string-introduce-memweight-fix-build-error-caused-by-memweight-introduction.patch
* qnx4fs-use-memweight.patch
* dm-use-memweight.patch
* affs-use-memweight.patch
* video-uvc-use-memweight.patch
* ocfs2-use-memweight.patch
* ext2-use-memweight.patch
* ext3-use-memweight.patch
* ext4-use-memweight.patch
* checkpatch-update-alignment-check.patch
* checkpatch-test-for-non-standard-signatures.patch
* checkpatch-check-usleep_range-arguments.patch
* drivers-rtc-rtc-coh901331c-use-clk_prepare-unprepare.patch
* drivers-rtc-rtc-coh901331c-use-devm-allocation.patch
* drivers-rtc-rtc-ab8500c-use-irqf_oneshot-when-requesting-a-threaded-irq.patch
* rtc-pl031-encapsulate-per-vendor-ops.patch
* rtc-pl031-use-per-vendor-variables-for-special-init.patch
* rtc-pl031-fix-up-irq-flags.patch
* drivers-rtc-rtc-ab8500c-use-uie-emulation.patch
* drivers-rtc-rtc-ab8500c-use-uie-emulation-checkpatch-fixes.patch
* drivers-rtc-rtc-ab8500c-remove-fix-for-ab8500-ed-version.patch
* drivers-rtc-rtc-r9701c-avoid-second-call-to-rtc_valid_tm.patch
* drivers-rtc-rtc-r9701c-check-that-r9701_set_datetime-succeeded.patch
* hfsplus-use-enomem-when-kzalloc-fails.patch
* hfsplus-make-hfsplus_sync_fs-static.patch
* hfsplus-amend-debugging-print.patch
* hfsplus-remove-useless-check.patch
* hfsplus-get-rid-of-write_super.patch
* hfsplus-get-rid-of-write_super-checkpatch-fixes.patch
* kmod-avoid-deadlock-from-recursive-kmod-call.patch
* fork-use-vma_pages-to-simplify-the-code.patch
* fork-use-vma_pages-to-simplify-the-code-fix.patch
* ipc-semc-alternatives-to-preempt_disable.patch
* drivers-char-ipmi-ipmi_watchdogc-remove-local-ioctl-defines-replaced-by-generic-ones.patch
* fs-cachefiles-add-support-for-large-files-in-filesystem-caching.patch
* fs-cachefiles-add-support-for-large-files-in-filesystem-caching-fix.patch
* c-r-fcntl-add-f_getowner_uids-option.patch
* notify_change-check-that-i_mutex-is-held.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
mutex-subsystem-synchro-test-module-fix.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: build failure after merge of the regulator tree
From: Andrew Morton @ 2012-06-21 17:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kim, Milo, Mark Brown, linux-next, linux-kernel, Stephen Warren,
Girdwood, Liam, axel.lin, Alberto Panizzo, Jingoo Han,
Richard Purdie, Grant Likely
In-Reply-To: <20120621210412.72321b3ff43d50930b17f760@canb.auug.org.au>
On Thu, 21 Jun 2012 21:04:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> This export is needed for a patch in the regulator tree, so can we have
> that patch sent to Linus ASAP, please?
Shall do.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: drivers/gpio/devres.c: export devm_gpio_request_one() to modules
Several drivers in linux-next and possibly mainline are failing due to
this missing export.
Cc: Alberto Panizzo <alberto@amarulasolutions.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/gpio/devres.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/gpio/devres.c~drivers-gpio-devresc-export-devm_gpio_request_one-to-modules drivers/gpio/devres.c
--- a/drivers/gpio/devres.c~drivers-gpio-devresc-export-devm_gpio_request_one-to-modules
+++ a/drivers/gpio/devres.c
@@ -98,6 +98,7 @@ int devm_gpio_request_one(struct device
return 0;
}
+EXPORT_SYMBOL(devm_gpio_request_one);
/**
* devm_gpio_free - free an interrupt
_
^ permalink raw reply
* Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
From: Steven Rostedt @ 2012-06-21 15:51 UTC (permalink / raw)
To: Fengguang Wu
Cc: Glauber Costa, Luck, Tony,
ksummit-2012-discuss@lists.linux-foundation.org, Stephen Rothwell,
linux-next@vger.kernel.org
In-Reply-To: <20120621152649.GA15549@localhost>
On Thu, 2012-06-21 at 23:26 +0800, Fengguang Wu wrote:
> On Thu, Jun 21, 2012 at 10:04:26AM -0400, Steven Rostedt wrote:
> > On Thu, 2012-06-21 at 21:38 +0800, Fengguang Wu wrote:
> >
> > > This is the 0-day kernel testing backend I recently started can help.
> > >
> > > It runs kernel build/boot tests on each developer's tree and tries to
> > > find and report possible defects within 24 hours. The timely report
> > > can effectively constraint the scope of impact to the related people,
> > > rather than hurting the larger crowd of people in the integration tree.
> >
> > Perhaps you would be the perfect candidate to house a linux-devel.git
> > repo. Have it set up like so:
>
> Actually Stephen jumps to my mind at the very start. He has all the
> experiences, tools and infrastructure to maintain such a tree.
I didn't want to burden him more ;-)
>
> The most important problem may be, how many developers we can attract
> to send pull requests to linux-devel. It would be a good quiz in the KS :-)
Agreed. Of course this is the chicken/egg problem. How do you know how
many developers that it would attract without first doing it.
So far I know of 1 (me ;-) And I think even GregKH said he liked the
idea.
>
> FYI, I've added about 170 git trees as my test targets, which contain
> about 550 active branches. I enjoy a lot looking at the freshly cooked
> commits being compiled and ran to the degree to keep the servers busy
> all day :-)
What about trees like my own, where 'master' is very stale, and all the
goodies happen in the other branches. And last I looked, in my public
repo, I have 124 branches!
>
> > If you do not have the time to set up such a repo, I'm willing to do it.
> > I just do not have the hardware to do the testing that should be done,
> > but as it would be public, others could test it, and report back to me.
>
> Yeah either way is possible and I can sure carry out tests on it. But
> IMHO Stephen could be the perfect candidate to maintain the tree :)
If he wants to then sure. Otherwise it may become my hobby :-)
-- Steve
^ permalink raw reply
* Re: [Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
From: Fengguang Wu @ 2012-06-21 15:26 UTC (permalink / raw)
To: Steven Rostedt
Cc: Glauber Costa, Luck, Tony,
ksummit-2012-discuss@lists.linux-foundation.org, Stephen Rothwell,
linux-next@vger.kernel.org
In-Reply-To: <1340287466.27036.161.camel@gandalf.stny.rr.com>
On Thu, Jun 21, 2012 at 10:04:26AM -0400, Steven Rostedt wrote:
> On Thu, 2012-06-21 at 21:38 +0800, Fengguang Wu wrote:
>
> > This is the 0-day kernel testing backend I recently started can help.
> >
> > It runs kernel build/boot tests on each developer's tree and tries to
> > find and report possible defects within 24 hours. The timely report
> > can effectively constraint the scope of impact to the related people,
> > rather than hurting the larger crowd of people in the integration tree.
>
> Perhaps you would be the perfect candidate to house a linux-devel.git
> repo. Have it set up like so:
Actually Stephen jumps to my mind at the very start. He has all the
experiences, tools and infrastructure to maintain such a tree.
The most important problem may be, how many developers we can attract
to send pull requests to linux-devel. It would be a good quiz in the KS :-)
> master - holds an integration of set branches *
>
> include-developer-topic - holds a branch that a developer has asked you
> to pull from. This is is also integrated into
> the master branch as the developer may request
>
> exclude-developer-topic - holds a branch that a developer has asked you
> to pull from. The difference between the above
> is that this branch is not to be integrated
> into master. It may cause unneeded conflicts
> that need to be settled still (even the -rt
> tree can go here).
>
> Basically have a series of branches like:
>
> include-jejb-scsi
> include-rostedt-ftrace-multi-buf
> include-jiri-sched-deadline
> exclude-rostedt-preempt-rt
> [..]
>
>
> * master would be an integration of all include-* branches. If one of
> those branches are found to be broken, then you can rebase master to
> exclude it, send an email to the owner of that branch and tell them it
> will not be included until they fix it.
>
> Any branch that starts suffering bit rot, you can send an email to that
> developer to ask them if its still valid. If not, just nuke the branch.
> If it is, encourage them to do more work on it or explain why it's
> suffering from rot, otherwise just nuke it anyway.
>
> This is much easier to do with git than quilt, which is why I do not
> believe this will be like -mm, and mostly ignored (except for a small
> few)
It looks like a clean solution. Stephen may know more caveats about it.
> This can also be a central location to see what's being developed. I
> would even publish where the branches are being pulled from, so if
> people want to know more about the development they can find it.
>
> I really have no clue about all the great things going on in development
> of parts of linux, and I'm sure there's things going on that I do not
> know about that I would like to look in to. This can be a way to show
> what's being done.
FYI, I've added about 170 git trees as my test targets, which contain
about 550 active branches. I enjoy a lot looking at the freshly cooked
commits being compiled and ran to the degree to keep the servers busy
all day :-)
> If you do not have the time to set up such a repo, I'm willing to do it.
> I just do not have the hardware to do the testing that should be done,
> but as it would be public, others could test it, and report back to me.
Yeah either way is possible and I can sure carry out tests on it. But
IMHO Stephen could be the perfect candidate to maintain the tree :)
Thanks,
Fengguang
^ permalink raw reply
* Re: What is the right practice to get new code upstream( was Fwd: [patch] a simple hardware detector for latency as well as throughput ver. 0.1.0)
From: Peter Zijlstra @ 2012-06-21 14:43 UTC (permalink / raw)
To: Robert Richter
Cc: Luming Yu, LKML, tglx, sfr, Andrew Morton, jcm, linux-next,
Ingo Molnar, torvalds
In-Reply-To: <20120621132914.GA24632@erda.amd.com>
On Thu, 2012-06-21 at 15:29 +0200, Robert Richter wrote:
> On 14.06.12 12:04:56, Peter Zijlstra wrote:
> For AMD there's only event 02Bh, which is SMIs Received. I'm not sure it
> > has anything like the FREEZE or if the event is modifyable to count the
> > cycles in SMI.
>
> Peter, which use cases do you have in mind. Is it to root cause
> latencies? Or just to see what happens on the system, you long it
> spends in smi mode? On current systems counting smi cycles seems not
> to be possible.
Yeah exactly. So we can whack vendors over the head with hard evidence
their BIOS is utter shite.
So what we do now is disable interrupts, run a tight TSC read loop and
report fail when you see a big delta.
Now some 'creative' BIOS people thought it would be a good idea to
save/restore TSC over the SMI, this avoids detection. It also completely
wrecks TSC sync across cores.
But the SMI stuff is a real problem for -rt, this feature^Wfailure-add
is a real problem, we've seen SMIs that go well above a ms in duration,
which of course completely wreck the system.
IIRC the worst tglx ever encountered was 0.5s or so.
So ideally the PMU would have 2 events, one counting SMIs one counting
cycles in SMM. Both should ignore any and all FREEZE_IN_SMM bits if such
a thing exists. The hardware should also hard fail if such a counter is
fiddled with from SMM context.
This would give us the capability to log exactly when and for how long
the system is taken from us and makes it impossible to 'fix' from SMM.
^ permalink raw reply
* Re: What is the right practice to get new code upstream( was Fwd: [patch] a simple hardware detector for latency as well as throughput ver. 0.1.0)
From: Robert Richter @ 2012-06-21 13:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Luming Yu, LKML, tglx, sfr, Andrew Morton, jcm, linux-next,
Ingo Molnar, torvalds
In-Reply-To: <1339668296.2559.25.camel@twins>
On 14.06.12 12:04:56, Peter Zijlstra wrote:
For AMD there's only event 02Bh, which is SMIs Received. I'm not sure it
> has anything like the FREEZE or if the event is modifyable to count the
> cycles in SMI.
Peter, which use cases do you have in mind. Is it to root cause
latencies? Or just to see what happens on the system, you long it
spends in smi mode? On current systems counting smi cycles seems not
to be possible.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (powerpc related)
From: Alan Modra @ 2012-06-21 11:43 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Stephen Rothwell, linux-next, ppc-dev,
linux-kernel
In-Reply-To: <20120621104839.GE20973@bubble.grove.modra.org>
On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote:
> Linker bug. That's not a sibling call, but a normal function return
> via an out-of-line register restore function.
I couldn't see how this might be occurring, then I remembered the
kernel has this horrible practise of using ld -r to package object
files. So linker generated functions might be munged together with
other functions. Does this help? (It won't if the kernel is
providing its own save/restore functions.)
Index: bfd/elf64-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-ppc.c,v
retrieving revision 1.387
diff -u -p -r1.387 elf64-ppc.c
@@ -6494,9 +6494,10 @@ ppc64_elf_func_desc_adjust (bfd *obfd AT
/* Provide any missing _save* and _rest* functions. */
htab->sfpr->size = 0;
- for (i = 0; i < sizeof (funcs) / sizeof (funcs[0]); i++)
- if (!sfpr_define (info, &funcs[i]))
- return FALSE;
+ if (!info->relocatable)
+ for (i = 0; i < sizeof (funcs) / sizeof (funcs[0]); i++)
+ if (!sfpr_define (info, &funcs[i]))
+ return FALSE;
elf_link_hash_traverse (&htab->elf, func_desc_adjust, info);
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: linux-next: build failure after merge of the regulator tree
From: Mark Brown @ 2012-06-21 11:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Kim, Milo, linux-next, linux-kernel,
Stephen Warren, Girdwood, Liam, axel.lin, Alberto Panizzo,
Jingoo Han, Richard Purdie, Grant Likely
In-Reply-To: <20120621210412.72321b3ff43d50930b17f760@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
On Thu, Jun 21, 2012 at 09:04:12PM +1000, Stephen Rothwell wrote:
> This export is needed for a patch in the regulator tree, so can we have
> that patch sent to Linus ASAP, please?
It's going to affect pretty much anything that tries to use the API.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the regulator tree
From: Stephen Rothwell @ 2012-06-21 11:04 UTC (permalink / raw)
To: Andrew Morton
Cc: Kim, Milo, Mark Brown, linux-next, linux-kernel, Stephen Warren,
Girdwood, Liam, axel.lin, Alberto Panizzo, Jingoo Han,
Richard Purdie, Grant Likely
In-Reply-To: <CAF+7xWkzKkwfBFQS1vr-Tk2Auu+5HQmX7bZCGJhsmXRi0V5OZw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Hi Andrew,
On Thu, 21 Jun 2012 16:20:46 +0800 Axel Lin <axel.lin@gmail.com> wrote:
>
> 2012/6/21 Kim, Milo <Milo.Kim@ti.com>:
> >> Caused by commit 809d310c7e69 ("regulator: lp872x: Don't allow modular
> >> build") but that was done to fix a different build problem.
> >
> > Sorry for this conflict.
> >
> > Build config of lp872x driver has been changed as tristate.
> > And related undefined symbol error has been fixed.
> > (don't use devm_gpio_request_one() at this moment because it can not be exported.)
>
> I don't think this is the good way, other drivers may have this build problem.
> I think we can fix it by having the patch exporting
> devm_gpio_request_one upstrem ASAP.
>
> BTW, In yesterday's linux-next tree, Andrew has below commit.
>
> commit a291ede7be8359a8986740b11b93f9c80e40210b
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date: Wed Jun 20 09:55:47 2012 +1000
>
> backlight-l4f00242t03-use-devm_gpio_request_one-fix
>
> export devm_gpio_request_one() to modules
>
> Cc: Alberto Panizzo <alberto@amarulasolutions.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This export is needed for a patch in the regulator tree, so can we have
that patch sent to Linus ASAP, please?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (powerpc related)
From: Alan Modra @ 2012-06-21 10:48 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Stephen Rothwell, linux-next, ppc-dev,
linux-kernel
In-Reply-To: <1340264307.1998.20.camel@concordia>
On Thu, Jun 21, 2012 at 05:38:27PM +1000, Michael Ellerman wrote:
> On Thu, 2012-06-21 at 17:07 +1000, Michael Ellerman wrote:
> > On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote:
> > > >
> > > > powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990):
> > > > sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs;
> > > > recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern
> > > >
Linker bug. That's not a sibling call, but a normal function return
via an out-of-line register restore function. Will fix. I'm a bit
surprised to see this with gcc-4.6 though. Or does this gcc-4.6 have
some of my recent mainline gcc patches enabling out-of-line
save/restore functions for -Os?
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: linux-next: build failure after merge of the regulator tree
From: Mark Brown @ 2012-06-21 9:46 UTC (permalink / raw)
To: Kim, Milo
Cc: Stephen Rothwell, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Axel Lin, Stephen Warren,
Girdwood, Liam
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998FC074@DQHE02.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
On Thu, Jun 21, 2012 at 08:13:15AM +0000, Kim, Milo wrote:
> > Caused by commit 809d310c7e69 ("regulator: lp872x: Don't allow modular
> > build") but that was done to fix a different build problem.
>
> Sorry for this conflict.
>
> Build config of lp872x driver has been changed as tristate.
> And related undefined symbol error has been fixed.
> (don't use devm_gpio_request_one() at this moment because it can not be exported.)
I'm not going to apply those patches, they're a step back in terms of
driver quality. We just need to bodge the Kconfig dependencies until
the fix for gpiolib gets merged.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the regulator tree
From: Mark Brown @ 2012-06-21 9:14 UTC (permalink / raw)
To: Axel Lin
Cc: Kim, Milo, Stephen Rothwell, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Warren, Girdwood, Liam
In-Reply-To: <CAF+7xWkzKkwfBFQS1vr-Tk2Auu+5HQmX7bZCGJhsmXRi0V5OZw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
On Thu, Jun 21, 2012 at 04:20:46PM +0800, Axel Lin wrote:
> I don't think this is the good way, other drivers may have this build problem.
> I think we can fix it by having the patch exporting
> devm_gpio_request_one upstrem ASAP.
This isn't any use until someone actually merges the patch which given
that it's for gpiolib could take a very long time.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (wireless-next tree related)
From: Arend van Spriel @ 2012-06-21 8:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: John W. Linville, linux-next, linux-kernel, Pieter-Paul Giesberts,
Franky (Zhenhui) Lin
In-Reply-To: <20120621155911.713748370d898a113e054693@canb.auug.org.au>
On 06/21/2012 07:59 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c: In function
> 'brcmf_sdio_dump_console':
> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3085:3: error:
> implicit declaration of function 'vzalloc'
> [-Werror=implicit-function-declaration]
> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3085:10:
> warning: assignment makes pointer from integer without a cast
> [enabled by default]
> drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3113:2: error:
> implicit declaration of function 'vfree'
> [-Werror=implicit-function-declaration]
>
> Caused by commit 4fc0d0160d59 ("brcmfmac: introduce checkdied
> debugfs functionality") from the wireless-next tree. Forgot to
> include vmalloc.h ?
>
> I have reverted that commit for today.
Hi Stephen,
We have setup a mailing list brcm80211-dev-list@broadcom.com for
reporting driver issues to make sure the right people are informed
regardless organizational changes. Feel free to use that as needed.
Gr. AvS
^ permalink raw reply
* RE: linux-next: build failure after merge of the regulator tree
From: Kim, Milo @ 2012-06-21 8:42 UTC (permalink / raw)
To: axel.lin@gmail.com, Mark Brown
Cc: Stephen Rothwell, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Warren, Girdwood, Liam
In-Reply-To: <CAF+7xWkzKkwfBFQS1vr-Tk2Auu+5HQmX7bZCGJhsmXRi0V5OZw@mail.gmail.com>
> BTW, In yesterday's linux-next tree, Andrew has below commit.
>
> commit a291ede7be8359a8986740b11b93f9c80e40210b
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date: Wed Jun 20 09:55:47 2012 +1000
>
> backlight-l4f00242t03-use-devm_gpio_request_one-fix
>
> export devm_gpio_request_one() to modules
>
> Cc: Alberto Panizzo <alberto@amarulasolutions.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Axel,
Good, thanks a lot !
Mark,
Then please ignore the patch below.
'[PATCH 2/3] regulator: replace devm_gpio_request_one() for loaded module'
https://lkml.org/lkml/2012/6/21/62
But two patches are still valid.
'[PATCH 1/3] regulator: enable module build config for lp872x'
'[PATCH 3/3] regulator: change message level on probing lp872x driver'
https://lkml.org/lkml/2012/6/21/61
https://lkml.org/lkml/2012/6/21/57
Thanks & BR
Milo -
^ permalink raw reply
* Re: linux-next: build failure after merge of the regulator tree
From: Axel Lin @ 2012-06-21 8:20 UTC (permalink / raw)
To: Kim, Milo
Cc: Mark Brown, Stephen Rothwell, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Warren, Girdwood, Liam
In-Reply-To: <A874F61F95741C4A9BA573A70FE3998FC074@DQHE02.ent.ti.com>
2012/6/21 Kim, Milo <Milo.Kim@ti.com>:
>> Caused by commit 809d310c7e69 ("regulator: lp872x: Don't allow modular
>> build") but that was done to fix a different build problem.
>
> Sorry for this conflict.
>
> Build config of lp872x driver has been changed as tristate.
> And related undefined symbol error has been fixed.
> (don't use devm_gpio_request_one() at this moment because it can not be exported.)
I don't think this is the good way, other drivers may have this build problem.
I think we can fix it by having the patch exporting
devm_gpio_request_one upstrem ASAP.
BTW, In yesterday's linux-next tree, Andrew has below commit.
commit a291ede7be8359a8986740b11b93f9c80e40210b
Author: Andrew Morton <akpm@linux-foundation.org>
Date: Wed Jun 20 09:55:47 2012 +1000
backlight-l4f00242t03-use-devm_gpio_request_one-fix
export devm_gpio_request_one() to modules
Cc: Alberto Panizzo <alberto@amarulasolutions.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Regards,
Axel
^ permalink raw reply
* RE: linux-next: build failure after merge of the regulator tree
From: Kim, Milo @ 2012-06-21 8:13 UTC (permalink / raw)
To: Mark Brown, Stephen Rothwell
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Axel Lin, Stephen Warren, Girdwood, Liam
In-Reply-To: <20120621132738.6e797593acc58b3e30902f69@canb.auug.org.au>
> Caused by commit 809d310c7e69 ("regulator: lp872x: Don't allow modular
> build") but that was done to fix a different build problem.
Sorry for this conflict.
Build config of lp872x driver has been changed as tristate.
And related undefined symbol error has been fixed.
(don't use devm_gpio_request_one() at this moment because it can not be exported.)
Please check patches below.
[PATCH 1/3] regulator: enable module build config for lp872x
[PATCH 2/3] regulator: replace devm_gpio_request_one() for loaded module
Thanks & BR
Milo -
^ 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