* Re: linux-next: Tree for Aug 26 (git-bisect: [0856a30] Scm: Remove unnecessary pid & credential references in Unix socket's send and receive path)
From: Sedat Dilek @ 2011-09-04 10:43 UTC (permalink / raw)
To: Stephen Rothwell, tim.c.chen
Cc: linux-next, LKML, jirislaby, David Miller, Yan, Zheng,
Valdis.Kletnieks, netdev
In-Reply-To: <CA+icZUXOnoG07Z8-AAUNqvuJmq6-OY1_dTzkxsBOLczoNYYGEw@mail.gmail.com>
On Fri, Sep 2, 2011 at 11:43 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> On Fri, Aug 26, 2011 at 7:00 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>>
>> Changes since 20110825:
>>
>> The slave-dma tree gained a conflict against Linus' tree.
>>
>> I have reverted the x86/spinlocks branch from the tip tree for today.
>>
>> The ptrace tree lost its build failure.
>>
>> The xen tree lost its conflict since I reveretd the version of the same
>> patches in the tip tree..
>>
>> The tty tree still has its build failure but I applied a supplied test
>> patch for it.
>>
>> The staging tree lost its build failures and gained a conflict against
>> the net tree.
>>
>> The moduleh tree lost a conflict.
>>
>> The akpm tree lost its build failure.
>>
>> ----------------------------------------------------------------------------
>>
>
> Hi,
>
> I saw diverse strange kernel-panics letting my notebook blink and
> scream a high-frequency tone, really ugly.
>
> My last good linux-next (l-n) kernel was next-20110818 and the next
> l-n kernel in series which I built and was broken: next-20110826.
> ( BTW, 29/31 Aug are broken too. )
>
> For the correctness I built 22/23/24/25 Aug which were all good.
> As usual when I do once a year a git-bisect... its the last step of 12
> steps in total (see git-bisect_visualize.txt and
> git-bisect_view-stat.txt).
>
> I was irritated by using next-20110825 and next-20110826 as git-bisect
> good and bad, as the first offered commit-id pointed me to
> 3.1-rc1-665-gec5efe7, but I was sure the culprit is definitely
> v3.1-rc3+ and furthermore I got no info how many revisions have to be
> walked through. So, I cancelled this run.
>
> Next thought was to do a git format-patch using above mentionned
> commit-ids (of the tags): 819 single patches.
> I took the commit-ids of 0001 (good) and 0818 (bad) - 0819 was
> linux-specific mumbo-jumbo.
>
> Jiri has reported a similiar breakage in [2] and returning CULPRIT
> commit [1] helped him.
> ( This git-bisect steal a whole Friday. Anyway, it's good to see we
> isolated the "bad" patch. )
>
> As a personal conclusion, trust more git-bisect...
> It does not hurt to NOT turn off brain my looking over the single
> patches, there were lots of staging, arm, powerpc which could be
> surely ignored, but in the end you are wiser - 12 steps are faster
> than reverting xxx single commits on spec.
>
> - Sedat -
>
> [1] http://git.us.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0856a304091b33a8e8f9f9c98e776f425af2b625
> [2] http://lkml.org/lkml/2011/9/1/332
> [3] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
> [4] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect
>
> P.S.: Used 0001 (good) and 0818 (bad) for git-bisect
>
> $ head -5 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch
> 0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch
> ==> 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch <==
> From eb39d34004888afcc0a44d9c36383cd69fa3b3b9 Mon Sep 17 00:00:00 2001
> From: Nicholas Bellinger <nab@linux-iscsi.org>
> Date: Tue, 26 Jul 2011 16:59:00 -0700
> Subject: [PATCH 001/819] target: Change TCM_NON_EXISTENT_LUN response to
> ASC=LOGICAL UNIT NOT SUPPORTED
>
> ==> 0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch <==
> From 9b198e560524e3fe341cd2ae478a1cdf2f57fc33 Mon Sep 17 00:00:00 2001
> From: Clifton Barnes <cabarnes@indesign-llc.com>
> Date: Thu, 25 Aug 2011 09:47:59 +1000
> Subject: [PATCH 818/819] Fixes the deadlock when inserting and removing the
> ds2780.
>
Issue fixed, see "[PATCH -next v2] unix stream: Fix use-after-free crashes" [1].
- Sedat -
[1] http://marc.info/?l=linux-netdev&m=131511507007022&w=2
^ permalink raw reply
* linux-next: Tree for Sept 5
From: Stephen Rothwell @ 2011-09-05 7:29 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 21318 bytes --]
Hi all,
With master.kernel.org down, there is not much change from September 1
and the actual release will be delayed until master returns. I will
still do the overnight builds, though.
The powerpc allyesconfig build still fails today.
Changes since 20110901:
Dropped tree: mips (acidentally, sorry)
The slave-dma tree lost its conflict.
The l2-mtd tree lost its conflict.
I have still reverted the x86/spinlocks branch from the tip tree for
today.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 199 trees (counting Linus' and 27 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 Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging kbuild-current/rc-fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/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 driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
Merging arm-lpae/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgalloc.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/tlb.h
CONFLICT (content): Merge conflict in arch/arm/kernel/head.S
CONFLICT (content): Merge conflict in arch/arm/mm/dma-mapping.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging arm-soc/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-u300/Makefile.boot
Merging at91/at91-next
Merging davinci/davinci-next
Merging i.MX/for-next
Merging linux-spec/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
CONFLICT (delete/modify): arch/arm/mach-exynos4/mach-smdkc210.c deleted in s5p/for-next and modified in HEAD. Version HEAD of arch/arm/mach-exynos4/mach-smdkc210.c left in tree.
$ git rm -f arch/arm/mach-exynos4/mach-smdkc210.c
Applying: s5p: merge fixup for atags_offset use
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging openrisc/for-upstream
Merging parisc/for-next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/powerpc/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging unicore32/unicore32
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/dev
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/xfs_super.c
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/hid/hid-ids.h
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging docs/docs-move
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging powertools/tools-test
Merging cpupowerutils/master
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging iscsi-target/for-next
Merging slave-dma/next
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (delete/modify): arch/powerpc/configs/40x/hcu4_defconfig deleted in HEAD and modified in net/master. Version net/master of arch/powerpc/configs/40x/hcu4_defconfig left in tree.
$ git rm -f arch/powerpc/configs/40x/hcu4_defconfig
Merging wireless/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-pci.c
Merging bluetooth/master
Merging mtd/master
Merging l2-mtd/master
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging input-mt/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/fbdev-next
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security/next
CONFLICT (content): Merge conflict in fs/ocfs2/xattr.c
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging iommu/next
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging pm/linux-next
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/board-ap4evb.c
CONFLICT (content): Merge conflict in arch/s390/include/asm/thread_info.h
CONFLICT (content): Merge conflict in drivers/mfd/twl4030-irq.c
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/mcheck/mce.c
Merging devicetree/devicetree/next
CONFLICT (content): Merge conflict in drivers/of/base.c
Merging spi/spi/next
Merging gpio/gpio/next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/mm/fault.c
[master e9aaf9f] Revert "Merge branch 'x86/spinlocks' into auto-latest"
Merging rcu/rcu/next
Merging kvm/linux-next
Merging oprofile/for-next
Merging ptrace/ptrace
Merging xen/upstream/xen
Merging xen-two/linux-next
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
Merging regmap/for-next
Merging driver-core/driver-core-next
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/devices.c
Merging tty/tty-next
Merging usb/usb-next
Merging staging/staging-next
CONFLICT (delete/modify): drivers/staging/rtl8192e/r8192E_core.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/rtl8192e/r8192E_core.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/xgifb/XGI_main_26.c
$ git rm -f drivers/staging/rtl8192e/r8192E_core.c
Merging bkl-config/config
Merging tmem/linux-next
Merging writeback/next
Merging arm-dt/devicetree/arm-next
Merging moduleh/module.h-split
CONFLICT (content): Merge conflict in arch/arm/mach-bcmring/mm.c
CONFLICT (content): Merge conflict in drivers/scsi/libfc/fc_lport.c
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
Applying: dm: use export.h instead of module.h where possible
Applying: block: bsg-lib.c needs export.h not module.h
Applying: PM: EXPORT_SYMBOL needs export.h
Merging kvmtool/master
CONFLICT (content): Merge conflict in include/net/9p/9p.h
Merging scsi-post-merge/merge-base:master
$ git checkout akpm
Applying: Because of x86-implement-strict-user-copy-checks-for-x86_64.patch
Applying: When no floppy is found the module code can be released while a timer
Applying: Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on
Applying: Fix the following memory leak:
Applying: The parameter's origin type is long. On an i386 architecture, it can
Applying: Since the commit below which added O_PATH support to the *at() calls, the
Applying: Add support for Aspire 1410 BIOS v1.3314. Fixes the following error:
Applying: This makes the iris driver use the platform API, so it is properly exposed
Applying: On x86_32 casting the unsigned int result of get_random_int() to long may
Applying: This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
Applying: Cc: Ed Wildgoose <git@wildgooses.com>
Applying: Replace the bubble sort in sanitize_e820_map() with a call to the generic
Applying: The x86 timer interrupt handler is the only handler not traced in the
Applying: The current interrupt traces from irq_handler_entry and irq_handler_exit
Applying: Don't allow everybody to use a modem.
Applying: The address limit is already set in flush_old_exec() so this
Applying: A call to va_copy() should always be followed by a call to va_end() in the
Applying: Don't dereference em if it's NULL or an error pointer.
Applying: Some messing with error codes to return 0 on out id's and match
Applying: kbuf is a buffer that is local to this function, so all of the error paths
Applying: fb_set_suspend() must be called with the console semaphore held, which
Applying: hwmon was using an idr with a NULL pointer, so convert to an
Applying: A straightforward looking use of idr for a device id.
Applying: This patchset aims at addressing /proc/stat issue which has been
Applying: update_ts_time_stat currently updates idle time even if we are in iowait
Applying: get_cpu_{idle,iowait}_time_us update idle/iowait counters unconditionally
Applying: show_stat handler of the /proc/stat file relies on kstat_cpu(cpu)
Applying: The address limit is already set in flush_old_exec() so this
Applying: The address limit is already set in flush_old_exec() so this
Applying: Add new check (assert_init) to make sure objects are initialized and
Applying: del_timer_sync() calls debug_object_assert_init() to assert that a timer
Applying: ext4_{set,clear}_bit() is defined as __test_and_{set,clear}_bit_le() for
Applying: The dqc_bitmap field of struct ocfs2_local_disk_chunk is 32-bit aligned,
Applying: The address limit is already set in flush_old_exec() so those calls to
Applying: When do pci remove/rescan on system that have more iommus, got
Applying: The current implementation of dmi_name_in_vendors() is an invitation to
Applying: For headers that get exported to userland and make use of u32 style
Applying: Fix sparse warnings of right shift bigger than source value size:
Applying: We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :
Applying: Some mangling of errors was necessary to maintain current interface.
Applying: This does involve additional use of the spin lock in idr.c. Is this an
Applying: Instead of open coding this function use kstrtoul_from_user() directly.
Applying: brd_make_request() always returns 0, which doesn't make much sense.
Applying: The address limit is already set in flush_old_exec() so this assignment of
Applying: Unbreak the alpha build.
Applying: Unbreak alpha build.
Applying: Unbreak alpha build.
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: The basic idea behind cross memory attach is to allow MPI programs doing
Applying: - Add x86_64 specific wire up
Applying: > You might get some speed benefit by optimising for the small copies
Applying: acct_isolated of compaction uses page_lru_base_type which returns only
Applying: Change ISOLATE_XXX macro with bitwise isolate_mode_t type. Normally,
Applying: In async mode, compaction doesn't migrate dirty or writeback pages. So,
Applying: In __zone_reclaim case, we don't want to shrink mapped page. Nonetheless,
Applying: unmap_and_move() is one a big messy function. Clean it up.
Applying: radix_tree_tag_get()'s BUG (when it sees a tag after saw_unset_tag) was
Applying: per-task block plug can reduce block queue lock contention and increase
Applying: The tracing ring-buffer used this function briefly, but not anymore.
Applying: After selecting a task to kill, the oom killer iterates all processes and
Applying: Add the leading word "tmpfs" to the Kconfig string to make it blindingly
Applying: When we get a bad_page bug report, it's useful to see what modules the
Applying: Without swap, anonymous pages are not scanned. As such, they should not
Applying: fix comment
Applying: The nr_force_scan[] tuple holds the effective scan numbers for anon and
Applying: Some kernel components pin user space memory (infiniband and perf) (by
Applying: Add comments to explain the page statistics field in the mm_struct.
Applying: add missing ;
Applying: Testing from the XFS folk revealed that there is still too much I/O from
Applying: Lumpy reclaim worked with two passes - the first which queued pages for IO
Applying: Direct reclaim should never writeback pages. For now, handle the
Applying: Direct reclaim should never writeback pages. Warn if an attempt is made.
Applying: It is preferable that no dirty pages are dispatched for cleaning from the
Applying: Workloads that are allocating frequently and writing files place a large
Applying: When direct reclaim encounters a dirty page, it gets recycled around the
Applying: It's possible a zone watermark is ok when entering the balance_pgdat()
Applying: printk_ratelimit() should not be used, because it shares ratelimiting
Applying: memchr_inv() is mainly used to check whether the whole buffer is filled
Applying: Use newly introduced memchr_inv() for page verification.
Applying: A shrinker function can return -1, means that it cannot do anything
Applying: Use atomic-long operations instead of looping around cmpxchg().
Applying: massage atomic.h inclusions
Applying: The /proc/vmallocinfo shows information about vmalloc allocations in
Applying: Commit 645747462435 ("vmscan: detect mapped file pages used only once")
Applying: Logic added in commit 8cab4754d24a0 ("vmscan: make mapped executable pages
Applying: SPARC32 require access to the start address. Add a new helper
Applying: With the NO_BOOTMEM symbol added architectures may now use the following
Applying: Using "- 1" relies on the old_end to be page aligned and PAGE_SIZE > 1,
Applying: This replaces ptep_clear_flush() with ptep_get_and_clear() and a single
Applying: This adds THP support to mremap (decreases the number of split_huge_page()
Applying: coding-style nitpicking
Applying: Cc: Andrea Arcangeli <aarcange@redhat.com>
Applying: Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applying: vmstat_text is only available when PROC_FS or SYSFS is enabled. This
Applying: reduce ifdeffery
Applying: Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applying: Make the security_inode_init_security() initxattrs arg const, to match the
Applying: The current implementation of the /dev/hpet driver couples opening the
Applying: smp_call_function() only lets all other CPUs execute a specific function,
Applying: auto_demotion_disable is called only for online CPUs. For hotplugged
Applying: Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following warning:
Applying: Strict user copy checks are only really supported on x86_32 even though
Applying: The help text for this config is duplicated across the x86, parisc, and
Applying: s/lib-/obj-/ for usercopy.o
Applying: After an "unexpected" reboot, I found this Oops in my logs:
Applying: In the move of the lis3 driver, the hp_accel.c file got dropped from the
Applying: Add axis correction for HP EliteBook 2730p.
Applying: Add axis correction for HP EliteBook 8540w.
Applying: Add axis correction for HP ProBook 6555b.
Applying: Adapt the help text for CONFIG_HP_ACCEL to the move of
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Change exported functions to use the device given as parameter
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: Cc: Al Viro <viro@zeniv.linux.org.uk>
Applying: Add V2 of the LED driver for a single timer channel for the TPU hardware
Applying: include linux/module.h
Applying: The memory for struct led_trigger should be kfreed in the
Applying: Currently termination logic (\0 or \n\0) is hardcoded in _kstrtoull(),
Applying: Add support for slice by 8 to existing crc32 algorithm. Also modify
Applying: don't include asm/msr.h
Applying: epoll can acquire recursively acquire ep->mtx on multiple "struct
Applying: Currently in oprofilefs, files that use ulong_fops mis-handle writes of
Applying: This is the one use of an ida that doesn't retry on receiving -EAGAIN.
Applying: One can get this information from minix/inode.c, but adding the
Applying: The memcg code sometimes uses "struct mem_cgroup *mem" and sometimes uses
Applying: Before calling schedule_timeout(), task state should be changed.
Applying: Signed-off-by: Bob Liu <lliubbo@gmail.com>
Applying: While back-porting Johannes Weiner's patch "mm: memcg-aware global
Applying: If somebody is touching data too early, it might be easier to diagnose a
Applying: Both mem_cgroup_charge_statistics() and mem_cgroup_move_account() were
Applying: On reading sysctl dirs we should return -EISDIR instead of -EINVAL.
Applying: Force this on for -next/mm testing purposes.
Applying: Expand root=PARTUUID=UUID syntax to support selecting a root partition by
Applying: After merging the akpm tree, today's linux-next build (lost of them)
Applying: The discovered bit in PGCCSR register indicates if the device has been
Applying: Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge device.
Applying: When I tried to send a patch to remove it, Andi told me we still need to
Applying: A default echo function has been provided so it is no longer an error when
Applying: This client driver allows you to use a GPIO pin as a source for PPS
Applying: remove unneeded cast of void*
Applying: Straightforward. As an aside, the ida_init calls are not needed as far as
Applying: Simply creates one point to call the w1 interface.
Applying: Adds a nolock function to the w1 interface to avoid locking the
Applying: Fixes the deadlock when inserting and removing the ds2780.
Merging akpm
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the moduleh tree
From: Felipe Balbi @ 2011-09-05 10:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: balbi, Stephen Rothwell, Paul Gortmaker, linux-next, linux-kernel,
Greg KH
In-Reply-To: <CAMuHMdWGtsNN3_26PZYOGQjDid4rXRxxssQVDCDsNSim_FJwdg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]
Hi,
On Fri, Sep 02, 2011 at 08:32:09PM +0200, Geert Uytterhoeven wrote:
> On Tue, Aug 23, 2011 at 11:59, Felipe Balbi <balbi@ti.com> wrote:
> > On Tue, Aug 23, 2011 at 03:08:54PM +1000, Stephen Rothwell wrote:
> >> After merging the moduleh tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/usb/dwc3/dwc3-pci.c: In function 'dwc3_pci_init':
> >> drivers/usb/dwc3/dwc3-pci.c:211:9: error: 'THIS_MODULE' undeclared (first use in this function)
> >>
> >> Caused by the interaction of the module.h split up with commit
> >> 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") from the usb
> >> tree.
> >>
> >> I have applied this patch for today (Greg, this should be applied to your
> >> tree):
> >>
> >> From: Stephen Rothwell <sfr@canb.auug.org.au>
> >> Date: Tue, 23 Aug 2011 15:05:25 +1000
> >> Subject: [PATCH] usb: include module.h in the DesignWare USB3 DRD driver
> >>
> >> Fixes this build error:
> >>
> >> drivers/usb/dwc3/dwc3-pci.c: In function 'dwc3_pci_init':
> >> drivers/usb/dwc3/dwc3-pci.c:211:9: error: 'THIS_MODULE' undeclared (first use in this function)
> >>
> >> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >> ---
> >> drivers/usb/dwc3/dwc3-pci.c | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> >> index 2578595..e3b77d2 100644
> >> --- a/drivers/usb/dwc3/dwc3-pci.c
> >> +++ b/drivers/usb/dwc3/dwc3-pci.c
> >> @@ -38,6 +38,7 @@
> >> */
> >>
> >> #include <linux/kernel.h>
> >> +#include <linux/module.h>
> >
> > that was my fault, I didn't know about Paul's commit. Please Greg, apply
> > this to your tree:
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
>
> The include should also be added to drivers/usb/dwc3/core.c and
> drivers/usb/dwc3/dwc3-omap.c,
> cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/4491952/
that's true, here's a patch for that:
From 2b248785ee47dd16bb8fa544f80f7e2e51919e8c Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Mon, 5 Sep 2011 13:37:28 +0300
Subject: [PATCH] usb: dwc3: add module.h to dwc3-omap.c and core.c
Organization: Texas Instruments\n
We need that header because of THIS_MODULE.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/usb/dwc3/core.c | 1 +
drivers/usb/dwc3/dwc3-omap.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6aa0913..64ba097 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -37,6 +37,7 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index ddbf38a..8a5d6ae 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -37,6 +37,7 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/interrupt.h>
--
1.7.6.396.ge0613
I'll send this to Greg once hera is back up and running.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
* linux-next: no tree for Sept 6
From: Stephen Rothwell @ 2011-09-06 6:40 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 278 bytes --]
Hi all,
With master.kernel.org down, there is not much change from yesterday and
I cannot publish the resulting linux-next tree anyway, so there is no
tree today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Arnaud Lacombe @ 2011-09-06 17:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20110906164049.4dd3961cb82800b8d7cc8741@canb.auug.org.au>
Hi,
On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> With master.kernel.org down, there is not much change from yesterday and
> I cannot publish the resulting linux-next tree anyway, so there is no
> tree today.
>
What about github ? gitorious ?
If you fork linus' tree on github, you should still be within the disk
usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
Thanks,
- Arnaud
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Josh Boyer @ 2011-09-06 17:23 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <CACqU3MXcZ72eYNd=duPYdR_gOe-ejnHoLSMqK_ZU3y=MR2-0+A@mail.gmail.com>
On Tue, Sep 6, 2011 at 1:17 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> With master.kernel.org down, there is not much change from yesterday and
>> I cannot publish the resulting linux-next tree anyway, so there is no
>> tree today.
>>
> What about github ? gitorious ?
>
> If you fork linus' tree on github, you should still be within the disk
> usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
Well... that would be helpful if all of the trees that linux-next
pulls from are hosted somewhere other than kernel.org as well. A lot
of them are not, which means you would get an incomplete linux-next
tree at best. Probably better to just wait.
josh
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Arnaud Lacombe @ 2011-09-06 17:29 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <CA+5PVA7CETUa0i3U20ifz5YjXAywTGD2NEQt1GcJz1OwY_DtEg@mail.gmail.com>
Hi,
On Tue, Sep 6, 2011 at 1:23 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 1:17 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi all,
>>>
>>> With master.kernel.org down, there is not much change from yesterday and
>>> I cannot publish the resulting linux-next tree anyway, so there is no
>>> tree today.
>>>
>> What about github ? gitorious ?
>>
>> If you fork linus' tree on github, you should still be within the disk
>> usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
>
> Well... that would be helpful if all of the trees that linux-next
> pulls from are hosted somewhere other than kernel.org as well. A lot
> of them are not, which means you would get an incomplete linux-next
> tree at best. Probably better to just wait.
>
That's just insane...
git is distributed, but still used centrally. Kernel development
should just not be impacted by such issues.
- Arnaud
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Randy Dunlap @ 2011-09-06 17:37 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Josh Boyer, Stephen Rothwell, linux-next, LKML
In-Reply-To: <CACqU3MXQw4+QyBmCPcO8ZmYu0T6N+DStXBoa=JUv+ej6cWMTnw@mail.gmail.com>
On Tue, 6 Sep 2011 13:29:23 -0400 Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Sep 6, 2011 at 1:23 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> > On Tue, Sep 6, 2011 at 1:17 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> >> Hi,
> >>
> >> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> Hi all,
> >>>
> >>> With master.kernel.org down, there is not much change from yesterday and
> >>> I cannot publish the resulting linux-next tree anyway, so there is no
> >>> tree today.
> >>>
> >> What about github ? gitorious ?
> >>
> >> If you fork linus' tree on github, you should still be within the disk
> >> usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
> >
> > Well... that would be helpful if all of the trees that linux-next
> > pulls from are hosted somewhere other than kernel.org as well. A lot
> > of them are not, which means you would get an incomplete linux-next
> > tree at best. Probably better to just wait.
> >
> That's just insane...
>
> git is distributed, but still used centrally. Kernel development
> should just not be impacted by such issues.
Key word is "should," but reality intervenes.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Josh Boyer @ 2011-09-06 18:18 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <CACqU3MXQw4+QyBmCPcO8ZmYu0T6N+DStXBoa=JUv+ej6cWMTnw@mail.gmail.com>
On Tue, Sep 6, 2011 at 1:29 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Tue, Sep 6, 2011 at 1:23 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Tue, Sep 6, 2011 at 1:17 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> Hi,
>>>
>>> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>> Hi all,
>>>>
>>>> With master.kernel.org down, there is not much change from yesterday and
>>>> I cannot publish the resulting linux-next tree anyway, so there is no
>>>> tree today.
>>>>
>>> What about github ? gitorious ?
>>>
>>> If you fork linus' tree on github, you should still be within the disk
>>> usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
>>
>> Well... that would be helpful if all of the trees that linux-next
>> pulls from are hosted somewhere other than kernel.org as well. A lot
>> of them are not, which means you would get an incomplete linux-next
>> tree at best. Probably better to just wait.
>>
> That's just insane...
It's insane for people to host their git trees for kernel work on kernel.org?
> git is distributed, but still used centrally. Kernel development
> should just not be impacted by such issues.
No... git is still used in a distributed fashion. It's just that most
maintainers host the public trees that people pull from on kernel.org.
Some have pushed public trees to github or elsewhere, but not all of
them.
josh
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Arnaud Lacombe @ 2011-09-06 18:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <CA+5PVA7Oj9BNTA93m8-rj4a7Ze_N7m3mG0-+GLG1zUSG+ekqJQ@mail.gmail.com>
Hi,
On Tue, Sep 6, 2011 at 2:18 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 1:29 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Sep 6, 2011 at 1:23 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> On Tue, Sep 6, 2011 at 1:17 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>> Hi all,
>>>>>
>>>>> With master.kernel.org down, there is not much change from yesterday and
>>>>> I cannot publish the resulting linux-next tree anyway, so there is no
>>>>> tree today.
>>>>>
>>>> What about github ? gitorious ?
>>>>
>>>> If you fork linus' tree on github, you should still be within the disk
>>>> usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
>>>
>>> Well... that would be helpful if all of the trees that linux-next
>>> pulls from are hosted somewhere other than kernel.org as well. A lot
>>> of them are not, which means you would get an incomplete linux-next
>>> tree at best. Probably better to just wait.
>>>
>> That's just insane...
>
> It's insane for people to host their git trees for kernel work on kernel.org?
>
Yes. It is looking for trouble by creating a wonderful single point of
failure. Which happened to have failed.
If I were to be really paranoid, I would no longer trust any code on
git.kernel.org unless all the current repository were to be destroyed,
and re-uploaded by their owner.
- Arnaud
>> git is distributed, but still used centrally. Kernel development
>> should just not be impacted by such issues.
>
> No... git is still used in a distributed fashion. It's just that most
> maintainers host the public trees that people pull from on kernel.org.
> Some have pushed public trees to github or elsewhere, but not all of
> them.
>
> josh
>
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Mauro Carvalho Chehab @ 2011-09-07 14:08 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Josh Boyer, Stephen Rothwell, linux-next, LKML
In-Reply-To: <CACqU3MW3w10LsZvyY4RNQ1-0TgrW39PaGeVnj78bk+p6c=1uFQ@mail.gmail.com>
Em 06-09-2011 15:30, Arnaud Lacombe escreveu:
> Hi,
>
> On Tue, Sep 6, 2011 at 2:18 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>> On Tue, Sep 6, 2011 at 1:29 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> Hi,
>>>
>>> On Tue, Sep 6, 2011 at 1:23 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>>> On Tue, Sep 6, 2011 at 1:17 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> With master.kernel.org down, there is not much change from yesterday and
>>>>>> I cannot publish the resulting linux-next tree anyway, so there is no
>>>>>> tree today.
>>>>>>
>>>>> What about github ? gitorious ?
>>>>>
>>>>> If you fork linus' tree on github, you should still be within the disk
>>>>> usage limit. My linux-2.6-next.git bare tree mirror is about 303MB.
>>>>
>>>> Well... that would be helpful if all of the trees that linux-next
>>>> pulls from are hosted somewhere other than kernel.org as well. A lot
>>>> of them are not, which means you would get an incomplete linux-next
>>>> tree at best. Probably better to just wait.
>>>>
>>> That's just insane...
>>
>> It's insane for people to host their git trees for kernel work on kernel.org?
>>
> Yes. It is looking for trouble by creating a wonderful single point of
> failure. Which happened to have failed.
It seems that we need a backup plan. In my case, I could put the tree
for -next at infradead or at linuxtv, but that means to re-configure
everything at Stephen's side.
Does anyone have an ETA for hera to come back to live? If they're
planning to recover it into one or two days, then it is probably better
to wait. Otherwise, I think it would be wiser to move the repo to
some other place while they're preparing a new infrastructure.
> If I were to be really paranoid, I would no longer trust any code on
> git.kernel.org unless all the current repository were to be destroyed,
> and re-uploaded by their owner.
In any case, I'll just do a push -f after hera return, and do a
git repack -A -d on my repository there, to remove any bad object
that might be inserted by someone's else.
>
> - Arnaud
>
>>> git is distributed, but still used centrally. Kernel development
>>> should just not be impacted by such issues.
>>
>> No... git is still used in a distributed fashion. It's just that most
>> maintainers host the public trees that people pull from on kernel.org.
>> Some have pushed public trees to github or elsewhere, but not all of
>> them.
>>
>> josh
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: no tree for Sept 6
From: Stephen Rothwell @ 2011-09-07 7:16 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: linux-next, LKML
In-Reply-To: <CACqU3MXcZ72eYNd=duPYdR_gOe-ejnHoLSMqK_ZU3y=MR2-0+A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi Arnaud,
On Tue, 6 Sep 2011 13:17:21 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> On Tue, Sep 6, 2011 at 2:40 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > With master.kernel.org down, there is not much change from yesterday and
> > I cannot publish the resulting linux-next tree anyway, so there is no
> > tree today.
> >
> What about github ? gitorious ?
I am restricted by my employer as to where I can publish the linux-next
tree.
Besides, I am having a nice restful time :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the at91 tree with the arm tree
From: Stephen Rothwell @ 2011-09-09 1:20 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Ferre
Cc: linux-next, linux-kernel, Russell King
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
Hi all,
Today's linux-next merge of the at91 tree got a conflict in
arch/arm/mach-at91/board-usb-a9260.c between commit 2f8163baada3 ("ARM:
gpio: convert includes of mach/gpio.h and asm/gpio.h to linux/gpio.h")
from the arm tree and commit 6939fd49787e ("at91: merge board USB-A9260
and USB-A9263 together") from the at91 tree.
The latter removes the file modified by the former, so I did thet.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the i.MX tree with the arm-soc tree
From: Stephen Rothwell @ 2011-09-09 1:40 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-next, linux-kernel, Arnd Bergmann,
"Uwe Kleine-König"
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
Hi Sascha,
Today's linux-next merge of the i.MX tree got a conflict in
arch/arm/mach-imx/Makefile between commit 91dc67d94810 ("Merge branch
'next/devel' of
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc
into for-next") from the arm-soc tree and commit ea754946551b ("Merge
branch 'imx-features' and 'imx-cleanup' into master") from the i.MX tree.
The conflict looks like this:
diff --cc arch/arm/mach-imx/Makefile
index f87cc55,d22096a..0000000
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@@ -3,7 -3,7 +3,11 @@@ obj-$(CONFIG_IMX_HAVE_DMA_V1) += dma-v1
obj-$(CONFIG_SOC_IMX1) += clock-imx1.o mm-imx1.o
obj-$(CONFIG_SOC_IMX21) += clock-imx21.o mm-imx21.o
++<<<<<<< HEAD
+obj-$(CONFIG_SOC_MX25) += clock-imx25.o mm-imx25.o ehci-imx25.o cpu-imx25.o
++=======
+ obj-$(CONFIG_SOC_IMX25) += clock-imx25.o mm-imx25.o ehci-imx25.o cpu-imx25.o
++>>>>>>> i.MX/for-next
obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
obj-$(CONFIG_SOC_IMX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
Given that there are no other references to SOC_MX25 in the resulting
tree, I used the latter version.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the i.MX tree with the arm-soc tree
From: Stephen Rothwell @ 2011-09-09 1:44 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-next, linux-kernel, Fabio Estevam, Arnd Bergmann,
"Uwe Kleine-König", Arnaud Patard (Rtp)
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
Hi Sascha,
Today's linux-next merge of the i.MX tree got a conflict in
arch/arm/plat-mxc/devices/platform-pata_imx.c between commit 236c4e8be436
("ARM: imx: Add PATA resources for other i.MX processors") from the
arm-soc tree and commit 8354b5d2a1c5 ("ARM: imx: Add PATA resources for
other i.MX processors") from the i.MX tree.
The latter appears to be a corrected version of the former (despite
having the same Author date ...) so I used that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the l2-mtd tree with the at91 tree
From: Stephen Rothwell @ 2011-09-09 3:29 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, Dmitry Eremin-Solenikov, Nico Erfurth,
Jean-Christophe PLAGNIOL-VILLARD, Nicolas Ferre
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
arch/arm/mach-at91/board-usb-a9260.c between commit 6939fd49787e ("at91:
merge board USB-A9260 and USB-A9263 together") from the at91 tree and
commit 29921652b159 ("mtd: ATMEL, AVR32: inline nand partition table
access") from the l2-mtd tree.
The former removed the file modified by the latter, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the mfd tree with Linus' tree
From: Stephen Rothwell @ 2011-09-09 4:22 UTC (permalink / raw)
To: Samuel Ortiz
Cc: linux-next, linux-kernel, Felipe Balbi, Sebastian Reichel,
John Stultz, Ilkka Koskinen
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi Samuel,
Today's linux-next merge of the mfd tree got a conflict in
drivers/rtc/rtc-twl.c between commits dec35d19c4ec ("rtc: rtc-twl: Switch
to using threaded irq") and 34d623d11316 ("rtc: rtc-twl: Remove lockdep
related local_irq_enable()") from Linus' tree and commit 02e964b17e2f
("rtc: Move twl to threaded irq") from the mfd tree.
The 2 commits from Linus' tree do exactly what the single mfd tree commit
does. I used the version from Linus' tree (which had further changes).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: Tree for Sept 9
From: Stephen Rothwell @ 2011-09-09 6:38 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 22296 bytes --]
Hi all,
With master.kernel.org down, there is not much change from September 1
and the actual release will be delayed until master returns. I will
still do the overnight builds, though.
The powerpc allyesconfig build still fails today.
Changes since 20110905:
Undropped tree: mips
The at91 tree gained a conflict against the arm tree.
The i.MX tree gained conflicts against the arm-soc tree.
The l2-mtd tree gained a conflict against the at91 tree.
The mfd tree gained a conflict against Linus' tree.
I have still reverted the x86/spinlocks branch from the tip tree for
today.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 199 trees (counting Linus' and 27 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 Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging kbuild-current/rc-fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/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 driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
Merging arm-lpae/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgalloc.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/tlb.h
CONFLICT (content): Merge conflict in arch/arm/kernel/head.S
CONFLICT (content): Merge conflict in arch/arm/mm/dma-mapping.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging arm-soc/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-u300/Makefile.boot
Merging at91/at91-next
CONFLICT (delete/modify): arch/arm/mach-at91/board-usb-a9260.c deleted in at91/at91-next and modified in HEAD. Version HEAD of arch/arm/mach-at91/board-usb-a9260.c left in tree.
$ git rm -f arch/arm/mach-at91/board-usb-a9260.c
Merging davinci/davinci-next
Merging i.MX/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-imx/Makefile
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/devices/platform-pata_imx.c
Merging linux-spec/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
CONFLICT (delete/modify): arch/arm/mach-exynos4/mach-smdkc210.c deleted in s5p/for-next and modified in HEAD. Version HEAD of arch/arm/mach-exynos4/mach-smdkc210.c left in tree.
$ git rm -f arch/arm/mach-exynos4/mach-smdkc210.c
Applying: s5p: merge fixup for atags_offset use
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging openrisc/for-upstream
Merging parisc/for-next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/powerpc/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging unicore32/unicore32
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/dev
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/trans_virtio.c
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/xfs_super.c
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/hid/hid-ids.h
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging docs/docs-move
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging powertools/tools-test
Merging cpupowerutils/master
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging iscsi-target/for-next
Merging slave-dma/next
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (delete/modify): arch/powerpc/configs/40x/hcu4_defconfig deleted in HEAD and modified in net/master. Version net/master of arch/powerpc/configs/40x/hcu4_defconfig left in tree.
$ git rm -f arch/powerpc/configs/40x/hcu4_defconfig
Merging wireless/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-pci.c
Merging bluetooth/master
Merging mtd/master
Merging l2-mtd/master
CONFLICT (delete/modify): arch/arm/mach-at91/board-usb-a9260.c deleted in HEAD and modified in l2-mtd/master. Version l2-mtd/master of arch/arm/mach-at91/board-usb-a9260.c left in tree.
CONFLICT (content): Merge conflict in drivers/mtd/maps/lantiq-flash.c
$ git rm -f arch/arm/mach-at91/board-usb-a9260.c
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging input-mt/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/rtc/rtc-twl.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/fbdev-next
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security/next
CONFLICT (content): Merge conflict in fs/ocfs2/xattr.c
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging iommu/next
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging pm/linux-next
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/board-ap4evb.c
CONFLICT (content): Merge conflict in arch/s390/include/asm/thread_info.h
CONFLICT (content): Merge conflict in drivers/mfd/twl4030-irq.c
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/mcheck/mce.c
Merging devicetree/devicetree/next
CONFLICT (content): Merge conflict in drivers/of/base.c
Merging spi/spi/next
Merging gpio/gpio/next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/mm/fault.c
[master 9f518a5] Revert "Merge branch 'x86/spinlocks' into auto-latest"
Merging rcu/rcu/next
Merging kvm/linux-next
Merging oprofile/for-next
Merging ptrace/ptrace
Merging xen/upstream/xen
Merging xen-two/linux-next
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
Merging regmap/for-next
Merging driver-core/driver-core-next
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/devices.c
Merging tty/tty-next
Merging usb/usb-next
Merging staging/staging-next
CONFLICT (delete/modify): drivers/staging/rtl8192e/r8192E_core.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/rtl8192e/r8192E_core.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/xgifb/XGI_main_26.c
$ git rm -f drivers/staging/rtl8192e/r8192E_core.c
Merging bkl-config/config
Merging tmem/linux-next
Merging writeback/next
Merging arm-dt/devicetree/arm-next
Merging moduleh/module.h-split
CONFLICT (content): Merge conflict in arch/arm/mach-bcmring/mm.c
CONFLICT (content): Merge conflict in drivers/scsi/libfc/fc_lport.c
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
Applying: dm: use export.h instead of module.h where possible
Applying: block: bsg-lib.c needs export.h not module.h
Applying: PM: EXPORT_SYMBOL needs export.h
Merging kvmtool/master
CONFLICT (content): Merge conflict in include/net/9p/9p.h
Merging scsi-post-merge/merge-base:master
$ git checkout akpm
Applying: Because of x86-implement-strict-user-copy-checks-for-x86_64.patch
Applying: When no floppy is found the module code can be released while a timer
Applying: Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on
Applying: Fix the following memory leak:
Applying: The parameter's origin type is long. On an i386 architecture, it can
Applying: Since the commit below which added O_PATH support to the *at() calls, the
Applying: Add support for Aspire 1410 BIOS v1.3314. Fixes the following error:
Applying: This makes the iris driver use the platform API, so it is properly exposed
Applying: On x86_32 casting the unsigned int result of get_random_int() to long may
Applying: This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
Applying: Cc: Ed Wildgoose <git@wildgooses.com>
Applying: Replace the bubble sort in sanitize_e820_map() with a call to the generic
Applying: The x86 timer interrupt handler is the only handler not traced in the
Applying: The current interrupt traces from irq_handler_entry and irq_handler_exit
Applying: Don't allow everybody to use a modem.
Applying: The address limit is already set in flush_old_exec() so this
Applying: A call to va_copy() should always be followed by a call to va_end() in the
Applying: Don't dereference em if it's NULL or an error pointer.
Applying: Some messing with error codes to return 0 on out id's and match
Applying: kbuf is a buffer that is local to this function, so all of the error paths
Applying: fb_set_suspend() must be called with the console semaphore held, which
Applying: hwmon was using an idr with a NULL pointer, so convert to an
Applying: A straightforward looking use of idr for a device id.
Applying: This patchset aims at addressing /proc/stat issue which has been
Applying: update_ts_time_stat currently updates idle time even if we are in iowait
Applying: get_cpu_{idle,iowait}_time_us update idle/iowait counters unconditionally
Applying: show_stat handler of the /proc/stat file relies on kstat_cpu(cpu)
Applying: The address limit is already set in flush_old_exec() so this
Applying: The address limit is already set in flush_old_exec() so this
Applying: Add new check (assert_init) to make sure objects are initialized and
Applying: del_timer_sync() calls debug_object_assert_init() to assert that a timer
Applying: ext4_{set,clear}_bit() is defined as __test_and_{set,clear}_bit_le() for
Applying: The dqc_bitmap field of struct ocfs2_local_disk_chunk is 32-bit aligned,
Applying: The address limit is already set in flush_old_exec() so those calls to
Applying: When do pci remove/rescan on system that have more iommus, got
Applying: The current implementation of dmi_name_in_vendors() is an invitation to
Applying: For headers that get exported to userland and make use of u32 style
Applying: Fix sparse warnings of right shift bigger than source value size:
Applying: We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :
Applying: Some mangling of errors was necessary to maintain current interface.
Applying: This does involve additional use of the spin lock in idr.c. Is this an
Applying: Instead of open coding this function use kstrtoul_from_user() directly.
Applying: brd_make_request() always returns 0, which doesn't make much sense.
Applying: The address limit is already set in flush_old_exec() so this assignment of
Applying: Unbreak the alpha build.
Applying: Unbreak alpha build.
Applying: Unbreak alpha build.
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: The basic idea behind cross memory attach is to allow MPI programs doing
Applying: - Add x86_64 specific wire up
Applying: > You might get some speed benefit by optimising for the small copies
Applying: acct_isolated of compaction uses page_lru_base_type which returns only
Applying: Change ISOLATE_XXX macro with bitwise isolate_mode_t type. Normally,
Applying: In async mode, compaction doesn't migrate dirty or writeback pages. So,
Applying: In __zone_reclaim case, we don't want to shrink mapped page. Nonetheless,
Applying: unmap_and_move() is one a big messy function. Clean it up.
Applying: radix_tree_tag_get()'s BUG (when it sees a tag after saw_unset_tag) was
Applying: per-task block plug can reduce block queue lock contention and increase
Applying: The tracing ring-buffer used this function briefly, but not anymore.
Applying: After selecting a task to kill, the oom killer iterates all processes and
Applying: Add the leading word "tmpfs" to the Kconfig string to make it blindingly
Applying: When we get a bad_page bug report, it's useful to see what modules the
Applying: Without swap, anonymous pages are not scanned. As such, they should not
Applying: fix comment
Applying: The nr_force_scan[] tuple holds the effective scan numbers for anon and
Applying: Some kernel components pin user space memory (infiniband and perf) (by
Applying: Add comments to explain the page statistics field in the mm_struct.
Applying: add missing ;
Applying: Testing from the XFS folk revealed that there is still too much I/O from
Applying: Lumpy reclaim worked with two passes - the first which queued pages for IO
Applying: Direct reclaim should never writeback pages. For now, handle the
Applying: Direct reclaim should never writeback pages. Warn if an attempt is made.
Applying: It is preferable that no dirty pages are dispatched for cleaning from the
Applying: Workloads that are allocating frequently and writing files place a large
Applying: When direct reclaim encounters a dirty page, it gets recycled around the
Applying: It's possible a zone watermark is ok when entering the balance_pgdat()
Applying: printk_ratelimit() should not be used, because it shares ratelimiting
Applying: memchr_inv() is mainly used to check whether the whole buffer is filled
Applying: Use newly introduced memchr_inv() for page verification.
Applying: A shrinker function can return -1, means that it cannot do anything
Applying: Use atomic-long operations instead of looping around cmpxchg().
Applying: massage atomic.h inclusions
Applying: The /proc/vmallocinfo shows information about vmalloc allocations in
Applying: Commit 645747462435 ("vmscan: detect mapped file pages used only once")
Applying: Logic added in commit 8cab4754d24a0 ("vmscan: make mapped executable pages
Applying: SPARC32 require access to the start address. Add a new helper
Applying: With the NO_BOOTMEM symbol added architectures may now use the following
Applying: Using "- 1" relies on the old_end to be page aligned and PAGE_SIZE > 1,
Applying: This replaces ptep_clear_flush() with ptep_get_and_clear() and a single
Applying: This adds THP support to mremap (decreases the number of split_huge_page()
Applying: coding-style nitpicking
Applying: Cc: Andrea Arcangeli <aarcange@redhat.com>
Applying: Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applying: vmstat_text is only available when PROC_FS or SYSFS is enabled. This
Applying: reduce ifdeffery
Applying: Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applying: Make the security_inode_init_security() initxattrs arg const, to match the
Applying: The current implementation of the /dev/hpet driver couples opening the
Applying: smp_call_function() only lets all other CPUs execute a specific function,
Applying: auto_demotion_disable is called only for online CPUs. For hotplugged
Applying: Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following warning:
Applying: Strict user copy checks are only really supported on x86_32 even though
Applying: The help text for this config is duplicated across the x86, parisc, and
Applying: s/lib-/obj-/ for usercopy.o
Applying: After an "unexpected" reboot, I found this Oops in my logs:
Applying: In the move of the lis3 driver, the hp_accel.c file got dropped from the
Applying: Add axis correction for HP EliteBook 2730p.
Applying: Add axis correction for HP EliteBook 8540w.
Applying: Add axis correction for HP ProBook 6555b.
Applying: Adapt the help text for CONFIG_HP_ACCEL to the move of
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Change exported functions to use the device given as parameter
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: Cc: Al Viro <viro@zeniv.linux.org.uk>
Applying: Add V2 of the LED driver for a single timer channel for the TPU hardware
Applying: include linux/module.h
Applying: The memory for struct led_trigger should be kfreed in the
Applying: Currently termination logic (\0 or \n\0) is hardcoded in _kstrtoull(),
Applying: Add support for slice by 8 to existing crc32 algorithm. Also modify
Applying: don't include asm/msr.h
Applying: epoll can acquire recursively acquire ep->mtx on multiple "struct
Applying: Currently in oprofilefs, files that use ulong_fops mis-handle writes of
Applying: This is the one use of an ida that doesn't retry on receiving -EAGAIN.
Applying: One can get this information from minix/inode.c, but adding the
Applying: The memcg code sometimes uses "struct mem_cgroup *mem" and sometimes uses
Applying: Before calling schedule_timeout(), task state should be changed.
Applying: Signed-off-by: Bob Liu <lliubbo@gmail.com>
Applying: While back-porting Johannes Weiner's patch "mm: memcg-aware global
Applying: If somebody is touching data too early, it might be easier to diagnose a
Applying: Both mem_cgroup_charge_statistics() and mem_cgroup_move_account() were
Applying: On reading sysctl dirs we should return -EISDIR instead of -EINVAL.
Applying: Force this on for -next/mm testing purposes.
Applying: Expand root=PARTUUID=UUID syntax to support selecting a root partition by
Applying: After merging the akpm tree, today's linux-next build (lost of them)
Applying: The discovered bit in PGCCSR register indicates if the device has been
Applying: Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge device.
Applying: When I tried to send a patch to remove it, Andi told me we still need to
Applying: A default echo function has been provided so it is no longer an error when
Applying: This client driver allows you to use a GPIO pin as a source for PPS
Applying: remove unneeded cast of void*
Applying: Straightforward. As an aside, the ida_init calls are not needed as far as
Applying: Simply creates one point to call the w1 interface.
Applying: Adds a nolock function to the w1 interface to avoid locking the
Applying: Fixes the deadlock when inserting and removing the ds2780.
Merging akpm
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the i.MX tree with the arm-soc tree
From: Uwe Kleine-König @ 2011-09-09 6:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Sascha Hauer, linux-next, linux-kernel, Fabio Estevam,
Arnd Bergmann, Arnaud Patard (Rtp)
In-Reply-To: <20110909114436.5afc4ef772143d90ce75c7c5@canb.auug.org.au>
Hi Stephen,
(I'm responsible for this, as Sascha is on vacation.)
On Fri, Sep 09, 2011 at 11:44:36AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the i.MX tree got a conflict in
> arch/arm/plat-mxc/devices/platform-pata_imx.c between commit 236c4e8be436
> ("ARM: imx: Add PATA resources for other i.MX processors") from the
> arm-soc tree and commit 8354b5d2a1c5 ("ARM: imx: Add PATA resources for
> other i.MX processors") from the i.MX tree.
>
> The latter appears to be a corrected version of the former (despite
> having the same Author date ...) so I used that.
Yeah, if you look at the commit logs you will notice that the better
commit has an additional comment:
[ukleinek: squashed in a fix by Arnaud Patard (Rtp) <arnaud.patard@rtp-net.o
fixing the resource size calculation]
Arnd already promised me to replace the older version of the imx tree in
arm-soc with the current one. The problem is just that kernel.org is
down ...
Do you prefer that conflicts like these are resolved before you get
them?
(I.e. I could have done
git merge -s ours $somecommitfromthearmsoctree
but I wasn't sure that this is a good idea and so decided to wait until
you write a mail about the conflict.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: linux-next: manual merge of the i.MX tree with the arm-soc tree
From: Uwe Kleine-König @ 2011-09-09 6:41 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Sascha Hauer, linux-next, linux-kernel, Arnd Bergmann
In-Reply-To: <20110909114016.4a2a35295d3c84e37663289e@canb.auug.org.au>
Hello,
On Fri, Sep 09, 2011 at 11:40:16AM +1000, Stephen Rothwell wrote:
> The conflict looks like this:
>
> diff --cc arch/arm/mach-imx/Makefile
> index f87cc55,d22096a..0000000
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@@ -3,7 -3,7 +3,11 @@@ obj-$(CONFIG_IMX_HAVE_DMA_V1) += dma-v1
> obj-$(CONFIG_SOC_IMX1) += clock-imx1.o mm-imx1.o
> obj-$(CONFIG_SOC_IMX21) += clock-imx21.o mm-imx21.o
>
> ++<<<<<<< HEAD
> +obj-$(CONFIG_SOC_MX25) += clock-imx25.o mm-imx25.o ehci-imx25.o cpu-imx25.o
> ++=======
> + obj-$(CONFIG_SOC_IMX25) += clock-imx25.o mm-imx25.o ehci-imx25.o cpu-imx25.o
> ++>>>>>>> i.MX/for-next
>
> obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
> obj-$(CONFIG_SOC_IMX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
>
> Given that there are no other references to SOC_MX25 in the resulting
> tree, I used the latter version.
That's right.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: linux-next: manual merge of the l2-mtd tree with the at91 tree
From: Artem Bityutskiy @ 2011-09-09 6:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Dmitry Eremin-Solenikov, Nico Erfurth,
Jean-Christophe PLAGNIOL-VILLARD, Nicolas Ferre
In-Reply-To: <20110909132920.3696fbb6c1b90cded9727d30@canb.auug.org.au>
On Fri, 2011-09-09 at 13:29 +1000, Stephen Rothwell wrote:
> Hi Artem,
>
> Today's linux-next merge of the l2-mtd tree got a conflict in
> arch/arm/mach-at91/board-usb-a9260.c between commit 6939fd49787e ("at91:
> merge board USB-A9260 and USB-A9263 together") from the at91 tree and
> commit 29921652b159 ("mtd: ATMEL, AVR32: inline nand partition table
> access") from the l2-mtd tree.
>
> The former removed the file modified by the latter, so I did that.
OK, thanks, I guess you'll carry this modification so far, we'll need to
take care of the conflict when merging.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: linux-next: manual merge of the l2-mtd tree with the at91 tree
From: Stephen Rothwell @ 2011-09-09 6:45 UTC (permalink / raw)
To: dedekind1
Cc: linux-next, linux-kernel, Dmitry Eremin-Solenikov, Nico Erfurth,
Jean-Christophe PLAGNIOL-VILLARD, Nicolas Ferre
In-Reply-To: <1315550734.7905.14.camel@sauron>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
Hi Artem,
On Fri, 09 Sep 2011 09:45:28 +0300 Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> OK, thanks, I guess you'll carry this modification so far, we'll need to
> take care of the conflict when merging.
Yep, no worries.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the l2-mtd tree with the at91 tree
From: Nicolas Ferre @ 2011-09-09 9:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dedekind1, linux-next, linux-kernel, Dmitry Eremin-Solenikov,
Nico Erfurth, Jean-Christophe PLAGNIOL-VILLARD,
Russell King - ARM Linux
In-Reply-To: <20110909164539.bae897109d3de0e67f0db69a@canb.auug.org.au>
Le 09/09/2011 08:45, Stephen Rothwell :
> Hi Artem,
>
> On Fri, 09 Sep 2011 09:45:28 +0300 Artem Bityutskiy
> <dedekind1@gmail.com> wrote:
>>
>> OK, thanks, I guess you'll carry this modification so far, we'll
>> need to take care of the conflict when merging.
>
> Yep, no worries.
Stephen,
I have seen the two manual merges that you made concerning our
at91-next tree. This is when we realize how linux-next is a great tool ;-)
So, as I am not so used to this kind of situation, I wonder if I need
to included those two patches from Russell's and Artem's git trees in
our at91-next one or if I only carry on with current patch series
until Linus merges all this himself?
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: linux-next: manual merge of the l2-mtd tree with the at91 tree
From: Stephen Rothwell @ 2011-09-09 10:27 UTC (permalink / raw)
To: Nicolas Ferre
Cc: dedekind1, linux-next, linux-kernel, Dmitry Eremin-Solenikov,
Nico Erfurth, Jean-Christophe PLAGNIOL-VILLARD,
Russell King - ARM Linux
In-Reply-To: <4E69E21F.5070701@atmel.com>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi Nicolas,
On Fri, 09 Sep 2011 11:53:35 +0200 Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>
> So, as I am not so used to this kind of situation, I wonder if I need
> to included those two patches from Russell's and Artem's git trees in
> our at91-next one or if I only carry on with current patch series
> until Linus merges all this himself?
Just carry on, the conflicts will be fixed up When Linus merges your tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: at91 next tree
From: Nicolas Ferre @ 2011-09-09 12:14 UTC (permalink / raw)
To: Stephen Rothwell, linux-next
Cc: Jean-Christophe PLAGNIOL-VILLARD, Andrew Victor, Russell King,
Patrice VILCHEZ, 'linux-arm-kernel@lists.infradead.org'
In-Reply-To: <20110423095558.99ee7136.sfr@canb.auug.org.au>
Stephen,
Le 23/04/2011 01:55, Stephen Rothwell :
> Hi,
>
> On Fri, 22 Apr 2011 17:51:22 +0200 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
>>
>> I'd like to known how we could get the at91 at91-next branch pull
>> in the next tree automaticaly?
>
> You request it :-)
>
>> git://github.com/at91linux/linux-2.6-at91.git at91-next
>
> I have added that tree to linux-next.
Can you please move our at91-next branch that is included currently in
linux-next to the "2.6-less" github tree?
git://github.com/at91linux/linux-at91.git
(I hope that the merge conflicts that you have just resolved will not
suffer from this move: but as commits are the same, I am pretty sure
that it will be transparent).
Thanks for your help, best regards,
--
Nicolas Ferre
^ 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