Here rcu_assign_pointer() is ensuring that the
initialization of a structure is carried out before storing a pointer
to that structure.
So, rcu_assign_pointer(p, NULL) can always safely be converted to
RCU_INIT_POINTER(p, NULL).
Signed-off-by: Monam Agarwal
---
arch/x86/kvm/vmx.c |2 +-
1
This patch introduce is_merged_page() to check whether current page is merged
in f2fs bio cache. When page is not in cache, we can avoid submitting bio cache,
resulting in having more chance to merge pages.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c|8
fs/f2fs/f2fs.h|2 +-
Here rcu_assign_pointer() is ensuring that the
initialization of a structure is carried out before storing a pointer
to that structure.
So, rcu_assign_pointer(p, NULL) can always safely be converted to
RCU_INIT_POINTER(p, NULL).
Signed-off-by: Monam Agarwal
---
arch/powerpc/platforms/cell/spu_sy
On Wed, Mar 19, 2014 at 02:28:41PM +0100, Lothar Waßmann wrote:
>
> Signed-off-by: Lothar Waßmann
> ---
> arch/arm/boot/dts/imx53-tx53-x03x.dts |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts
> b/arch/arm/boot/dts/imx53-tx
Quoting Mike Galbraith :
On Thu, 2014-03-20 at 12:01 -0300, Glauber Costa wrote:
On Wed, Mar 19, 2014 at 6:42 AM, wrote:
> In consolidated environments, when there are multiple virtual
machines (VMs)
> running on one CPU core, timekeeping will be a problem to the guest OS.
> Here, I repor
On Wed, Mar 19, 2014 at 02:28:37PM +0100, Lothar Waßmann wrote:
>
> Signed-off-by: Lothar Waßmann
Please add something in the commit log, e.g. why regulator-boot-on is
redundant in this case.
Shawn
> ---
> arch/arm/boot/dts/imx53-tx53-x13x.dts |2 --
> 1 file changed, 2 deletions(-)
>
>
On Wed, Mar 19, 2014 at 02:28:40PM +0100, Lothar Waßmann wrote:
>
> Signed-off-by: Lothar Waßmann
> ---
> arch/arm/boot/dts/imx53-tx53-x13x.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx53-tx53-x13x.dts
> b/arch/arm/boot/dts/imx53-tx53-x13x.d
From: Mark Charlebois
Patch to prevent warning of a buggy compiler when using clang and
the ARM_UNWIND option.
Clang defines (at least on the current trunk) GNUC, GNUC_MINOR, and
GNUC_PATCHLEVEL to 4, 2, and 1 respectively.
This version of GCC gets flagged as buggy, but it isn't actually an
iss
From: Behan Webster
Similar to the fix in 40413dcb7b273bda681dca38e6ff0bbb3728ef11
MODULE_DEVICE_TABLE(x86cpu, ...) expects the struct to be called struct
x86cpu_device_id, and not struct x86_cpu_id which is what is used in the rest
of the kernel code. Although gcc seems to ignore this error, c
From: Behan Webster
Fix uninitialized return code in default case in cmpxchg-local.h
This patch fixes the code to prevent an uninitialized return value that is
detected
when compiling with clang. The bug produces numerous warnings when compiling the
Linux kernel with clang.
Signed-off-by: Beha
Oleg Nesterov wrote:
> Tetsuo, what do you think?
I don't like blocking SIGKILL while doing operations that depend on memory
allocation by other processes. If the OOM killer is triggered and it chose
the process blocking SIGKILL in mptsas_init() (I know it unlikely happens),
it generates the OOM k
the coding style patch is attached.
and the break missing one is https://lkml.org/lkml/2014/3/22/4.
sorry for the misspelling subject.
Signed-off-by: Jimmy Li
---
drivers/staging/iio/accel/sca3000_core.c |3 ++-
drivers/staging/iio/adc/ad7192.c |3 ++-
drivers/staging/iio/adc/ad76
On 21/03/14 10:35 PM, Branimir Maksimovic wrote:
This really puzzles me.
bmaxa@maxa:~$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX
560 Ti] (rev a1) (prog-if 00 [VGA controller])
Subsystem: CardExpert Technology Device 0801
Flags: bus mas
fix a missing break.
Signed-off-by: Jimmy Li
---
drivers/staging/iio/resolver/ad2s1200.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/iio/resolver/ad2s1200.c
b/drivers/staging/iio/resolver/ad2s1200.c
index 36eedd8..e2b4820 100644
--- a/drivers/staging/iio/resolver/ad2s
On 2014/3/18 18:48, Russell King - ARM Linux wrote:
> On Tue, Mar 18, 2014 at 06:20:42PM +0800, Liu Hua wrote:
>> When we configure CONFIG_LPAE=y, pfn << PAGE_SHIFT will
>> overflow if pfn >= 0x10 in copy_oldmem_page.
>>
>> So use __pfn_to_phys for converting.
>
> Yes. The sad thing is that i
Hi Linus,
The following changes since commit 10554647b488f58f2c36c78368e9bab4b93da721:
Merge tag 'omap-for-v3.14/fixes-dt-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
(2014-03-08 22:56:31 -0800)
are available in the git repository at:
git://git.kernel
This really puzzles me.
bmaxa@maxa:~$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX
560 Ti] (rev a1) (prog-if 00 [VGA controller])
Subsystem: CardExpert Technology Device 0801
Flags: bus master, fast devsel, latency 0, IRQ 52
Memory at
On 21 March 2014 23:37, Catalin Marinas wrote:
> smp_mb() is all about relative ordering. So if you want memory accesses
> in post_transition() to be visible to other observers before
> transition_ongoing = false, you also need to make sure that the readers
> of transition_ongoing have a barrier b
On Sat, 2014-03-22 at 07:57 +0530, Srikar Dronamraju wrote:
> > > So reverting and applying v3 3/4 and 4/4 patches works for me.
> >
> > Ok, I verified that the above endds up resulting in the same tree as
> > the minimal patch I sent out, modulo (a) some comments and (b) an
> > #ifdef CONFIG_SMP
On Wed, Feb 5, 2014 at 11:01 AM, Matt Porter wrote:
> Adds support for capturing PWM signals using the TI ECAP peripheral.
> This driver supports triggered buffer capture of pulses on multiple
> ECAP instances. In addition, the driver supports configurable polarity
> of the signal to be captured.
- Original Message -
> From: "Steven Rostedt"
> To: "Mathieu Desnoyers"
> Cc: linux-kernel@vger.kernel.org, "Ingo Molnar" , "Frederic
> Weisbecker" ,
> "Andrew Morton" , "Frank Ch. Eigler"
> , "Johannes Berg"
>
> Sent: Friday, March 21, 2014 3:40:00 PM
> Subject: Re: [PATCH v7 2/2] T
Hi
On Friday 21 March 2014, Greg Kroah-Hartman wrote:
> 3.13-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Zhang Rui
>
> commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream.
>
> ACPI table may export resource entry with 0 length.
> > So reverting and applying v3 3/4 and 4/4 patches works for me.
>
> Ok, I verified that the above endds up resulting in the same tree as
> the minimal patch I sent out, modulo (a) some comments and (b) an
> #ifdef CONFIG_SMP in futex_get_mm() that doesn't really matter.
>
> So I committed the
On 2014年03月22日 00:40, Rafael J. Wysocki wrote:
On Friday, March 21, 2014 08:39:39 AM Hanjun Guo wrote:
Hi Rafael,
Hi,
On 2014年03月21日 08:23, Rafael J. Wysocki wrote:
Hi All,
My queue for the first pull request during the upcoming 3.15 merge window
contains the material below. Following the
>From 9ad9432dab2bf4d1c8e6ff9201e88d5ae9f3994a Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Wed, 19 Mar 2014 20:24:22 -0500
Subject: [PATCH 1/1] perf: Add 'merge-recursive' callchain option
Powerpc saves the link register (LR) with each sample to help resolve
callchains for programs
You have received a Fund Donation of 1.5 million GBP From Mr&Mrs Adrian Gillian
Bayford. See link for prove: http://www.bbc.co.uk/news/uk-england-19254228
Please respond to this email with your name, address and phone number.
Thanks
Adrian & Gillian Bayford
--
To unsubscribe from this list: send
On Thu, Mar 20, 2014 at 11:45 PM, Adrian Hunter wrote:
> On 20.03.2014 20:47, Andrew Bresticker wrote:
>> mmc_request() reads the cd-gpio via mmc_gpio_get_cd(), which can sleep,
>> while holding host->lock. This may result in the following BUG:
>>
>> BUG: spinlock wrong CPU on CPU#2, kworker/u8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 05 Mar 2014 20:59:39 +0900
Masami Hiramatsu wrote:
> To avoid a kernel crash by probing on lockdep code, call
> kprobe_int3_handler and kprobe_debug_handler directly
> from do_int3 and do_debug. Since there is a locking code
> in notify_die, lockdep code can be invoked. And because
> the
On Wed, 05 Mar 2014 20:59:32 +0900
Masami Hiramatsu wrote:
> thunk_ra trace_hardirqs_on_thunk,trace_hardirqs_on_caller
> diff --git a/arch/x86/lib/thunk_64.S b/arch/x86/lib/thunk_64.S
> index a63efd6..92d9fea 100644
> --- a/arch/x86/lib/thunk_64.S
> +++ b/arch/x86/lib/thunk_64.S
> @@ -8,6 +
Most of the probe code is the same between all the different
clock controllers. Consolidate the code into a common.c file.
This makes changes to the common probe parts easier and reduces
chances for bugs.
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/co
On Wed, 05 Mar 2014 20:59:25 +0900
Masami Hiramatsu wrote:
> Prohibit probing on native_set_debugreg and native_load_idt.
> Since the kprobes uses do_debug for single stepping,
> functions called from do_debug before notify_die must not
> be probed.
> And also native_load_idt is called from paran
On Tue, Mar 4, 2014 at 5:14 AM, Matt Fleming wrote:
> From: Matt Fleming
>
> It's not possible to dereference the EFI System table directly when
> booting a 64-bit kernel on a 32-bit EFI firmware because the size of
> pointers don't match.
>
> In preparation for supporting the above use case, bui
On Wed, 05 Mar 2014 20:59:18 +0900
Masami Hiramatsu wrote:
> Prohibit probing on debug_stack_reset and debug_stack_set_zero.
> Since the both functions are called from TRACE_IRQS_ON/OFF_DEBUG
> macros which run in int3 ist entry, probing it may cause a soft
> lockup.
>
> This happens when the ke
On Wed, 05 Mar 2014 20:59:11 +0900
Masami Hiramatsu wrote:
>
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 0cfb00f..7062631 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -22,8 +22,9 @@ Appendix B: The kprobes sysctl interface
>
2014-02-06 20:25 GMT+01:00 Ivaylo Dimitrov :
> From: Felipe Balbi
This patch, which is present in 3.14-rc4 as 30a70b026 ("usb: musb: fix
obex in g_nokia.ko causing kernel panic"), breaks USB gadget support
on my Pandaboard. Bisecting points to this commit, reverting it makes
USB gadget support w
uffer:
[ 825.014783](ftrace buffer empty)
[ 825.014783] Modules linked in:
[ 825.014783] CPU: 1 PID: 22304 Comm: trinity-c57 Tainted: GW
3.14.0-rc7-next-20140321-sasha-00018-g0516fe6-dirty #265
[ 825.014783] task: 8802ec7bb000 ti: 8802e3bb8000 task.ti:
8802e3bb8000
[ 825.0
On 03/21/2014 05:30 PM, Andi Kleen wrote:
>
> % grep -r 'rdmsr' arch/x86/* | grep -v safe | wc -l
> 285
>
> I assume it'll keep you all busy for a while.
>
> [compared to a likely one liner in KVM]
>
It's not just KVM, though.
-hpa
--
To unsubscribe from this list: send the line "
On Fri, Mar 21, 2014 at 05:26:17PM -0700, H. Peter Anvin wrote:
> On 03/21/2014 05:22 PM, Andi Kleen wrote:
> >> Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
> >> more of the default, especially for things like this where the error
> >> handling is obvious (doesn't work?
On 03/21/2014 05:22 PM, Andi Kleen wrote:
>> Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
>> more of the default, especially for things like this where the error
>> handling is obvious (doesn't work? Disable the PMU.)
>
> That would be completely wrong. KVM has a full a
> Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
> more of the default, especially for things like this where the error
> handling is obvious (doesn't work? Disable the PMU.)
That would be completely wrong. KVM has a full architectural perfmon PMU,
just no model specific
Am 21.03.2014 20:54, schrieb Mike Snitzer:
> The comparisons used in add_vol() shouldn't be identical. Pretty sure
> the following is correct but it is completely untested.
>
> Signed-off-by: Mike Snitzer
> ---
> drivers/mtd/ubi/fastmap.c |4 ++--
> 1 files changed, 2 insertions(+), 2 delet
On Friday 21 March 2014 23:27:24 Catalin Marinas wrote:
> On 21 Mar 2014, at 19:44, Christopher Covington wrote:
> > On 03/21/2014 12:27 PM, Catalin Marinas wrote:
> >>> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> >>> index 1f8fed9..a62bcc9 100644
> >>> --- a/arch/arm/mm/Kconfig
> >>>
On Fri, Mar 21, 2014 at 6:08 PM, Yufeng Shen wrote:
>
>
> On Fri, Mar 21, 2014 at 4:58 PM, Benjamin Tissoires
> wrote:
>>
>> On Fri, Mar 21, 2014 at 3:39 PM, Yufeng Shen wrote:
>> > There is timeout error during initialization:
>> > kernel: [ 14.167086] hid-multitouch 0003:2512:5003.0001:
>> >
On Mon, Mar 17, 2014 at 04:09:04AM +, Li Zefan wrote:
> They don't have to be atomic_t, because they are simple boolean
> toggles.
>
> Signed-off-by: Li Zefan
A reason for which I had atomic_t was to avoid compiler optimisations
but I don't immediately see how it could go wrong. Assuming tha
On Mon, Mar 17, 2014 at 04:08:00AM +, Li Zefan wrote:
> - remove kmemleak_padding().
> - remove kmemleak_release().
>
> Signed-off-by: Li Zefan
Acked-by: Catalin Marinas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
The mm-of-the-moment snapshot 2014-03-21-16-28 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
Hi Li,
On 17 Mar 2014, at 04:07, Li Zefan wrote:
> Currently if kmemleak is disabled, the kmemleak objects can never be freed,
> no matter if it's disabled by a user or due to fatal errors.
>
> Those objects can be a big waste of memory.
>
> OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE
On Sat, 22 Mar 2014 00:21:59 +0100 Fabian Frederick wrote:
> > What we should do is to fix all these call sites so they can handle
> > memory exhaustion. That's hard so in the interim they should be using
> > __GFP_NOFAIL.
> >
>
> Ok, if even ext4 comments are wrong, things gonna be very diffi
On 21 Mar 2014, at 19:44, Christopher Covington wrote:
> On 03/21/2014 12:27 PM, Catalin Marinas wrote:
>> On Wed, Mar 19, 2014 at 05:35:19PM +, Christopher Covington wrote:
>>> On an LPAE system, the physical addresses used by VirtIO-MMIO may
>>> be larger than 32 bits, even if the header and
On Fri, 21 Mar 2014 13:00:55 -0700
Andrew Morton wrote:
> On Fri, 21 Mar 2014 17:18:30 +0100 Fabian Frederick wrote:
>
> > Loop around congestion_wait on allocation failure/alloc_journal_list
> > like already fixed in other FS.
> >
> > ...
> >
> > --- a/fs/reiserfs/journal.c
> > +++ b/fs/reise
Also remove test for selector in st_pwm_regulator_set_voltage_sel, the checking
is already done in .list_voltage.
Signed-off-by: Axel Lin
---
drivers/regulator/st-pwm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/st-pwm.c b/drivers/regulator/st-
On 03/21/2014 06:53 AM, Paul Gortmaker wrote:
> On 14-03-21 09:32 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 20/03/14 17:16, Paul Gortmaker wrote:
>>> Any randconfig that sets I2C=m and FB_MB862XX_I2C=y will
>>> encounter a final link failure that looks like this:
>>
>> It compiles fine with I2C=m,
Tuukka,
I've reproduced this negative on a 48 thread 2-socket Xeon during boot
(seen it only once, so far).
expected_us gets calculated to be -1, which is truthful, since the
next timer return value was about 500ns in the past
and our math truncates. This, in turn, confuses the heck out of
menu's
Am 21.03.2014 23:55, schrieb Andrew Morton:
> On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler
> wrote:
>
>> Am 21.03.2014 22:03, schrieb Andrew Morton:
>>> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler
>>> wrote:
>>>
The initramfs generation is broken for file and directory name
On Fri, 2014-03-21 at 12:32 -0700, Linus Torvalds wrote:
> On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov wrote:
> >
> > Yes, it seems that it actually needs > 30 secs. It spends most of the time
> > (30.13286 seconds) in [..]
>
> So how about taking a completely different approach:
>
> - just
On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler
wrote:
> Am 21.03.2014 22:03, schrieb Andrew Morton:
> > On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler
> > wrote:
> >
> >> The initramfs generation is broken for file and directory names which
> >> contain
> >> colons or spaces. Print
From: Suleiman Souhlal
This patch adds support for per memory cgroup swap file. The swap file
is marked private in swapon() with a new flag SWAP_FLAG_PRIVATE becasue
only the memory cgroup (and its children) that owns it can use it (in
the case of the children that don't own any swap files, they
From: Suleiman Souhlal
Allow up to 8192 swap files on x86_64. Prior to this patch the limit was
30 swap files, which is not enough if we want to use per memory cgroup
swap files on a machine that has thousands of cgroups.
While this change also reduces the number of bits available for swap
offse
Am 21.03.2014 22:03, schrieb Andrew Morton:
> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler
> wrote:
>
>> The initramfs generation is broken for file and directory names which contain
>> colons or spaces. Print an error and don't try to continue.
> It would be better to fix the it-doesnt-
This series of patches adds support to configure a cgroup to swap to a
particular file by using control file memory.swapfile.
A value of "default" in memory.swapfile indicates that this cgroup should
use the default, system-wide, swap files. A value of "none" indicates that
this cgroup should neve
From: Jamie Liu
swap_list is used by get_swap_page() to find public swap files to swap
to; in the case that there are many private swap files and few public
swap files, get_swap_page() may waste time iterating through private
swap files it can't swap to. Change _enable_swap_info() to not insert
p
Hi Geert,
On 03/21/2014 09:23 AM, Geert Uytterhoeven wrote:
Hi Peter,
On Fri, Mar 21, 2014 at 2:06 PM, Peter Hurley wrote:
@@ -2681,10 +2683,12 @@ int uart_remove_one_port(struct uart_driver *drv,
struct uart_port *uport)
}
/*
-* If the port is used as a console, un
On 03/21/2014 06:06 PM, Andrew Morton wrote:
On Wed, 19 Mar 2014 14:38:32 + Mel Gorman wrote:
>On Fri, Mar 14, 2014 at 11:15:37PM -0400, Sasha Levin wrote:
> >On 03/12/2014 06:36 AM, Mel Gorman wrote:
> > >Andrew, this should go with the patches
> > >mmnuma-reorganize-change_pmd_range.pa
On 03/21/2014 11:22 PM, Alexandre Belloni wrote:
On 21/03/2014 at 22:22:33 +0100, Sebastian Hesselbarth wrote :
On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
This drivers allows to provide DT clocks for the cpu and system PLLs found on
Marvell Berlin SoCs.
Alexandre,
as mentioned on IRC,
On 03/19/2014 10:38 AM, Mel Gorman wrote:
> On Fri, Mar 14, 2014 at 11:15:37PM -0400, Sasha Levin wrote:
>> On 03/12/2014 06:36 AM, Mel Gorman wrote:
>>> Andrew, this should go with the patches
>>> mmnuma-reorganize-change_pmd_range.patch
>>> mmnuma-reorganize-change_pmd_range-fix.patch
>>> move-mm
On 21/03/2014 at 22:22:33 +0100, Sebastian Hesselbarth wrote :
> On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
> >This drivers allows to provide DT clocks for the cpu and system PLLs found on
> >Marvell Berlin SoCs.
>
> Alexandre,
>
> as mentioned on IRC, I now had a closer look on it. Some mi
Please separate the missing break fix into its own patch. That will want to go
in as a fix. The tree it will go through is therefore different from the rest
of this patch which
can take a slower path into the kernel tree.
Jonathan
On March 21, 2014 12:45:51 PM GMT+00:00, Jimmy Li wrote:
>Sig
pn533_probe() calls usb_get_dev(), but there is no usb_put_dev()
in pn533_disconnect(). The patch adds one.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/nfc/pn533.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nfc/pn
On 21/03/2014 at 22:31:09 +0100, Sebastian Hesselbarth wrote :
> On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
> >Document the device tree bindings for the PLLs found on the Marvell Berlin
> >SoCs.
> >
> >Cc: devicet...@vger.kernel.org
>
> You forgot to add Mark Rutland's Reviewed-by. He didn'
On Fri, Mar 21, 2014 at 1:14 PM, delicious quinoa
wrote:
> On Thu, Mar 20, 2014 at 2:55 PM, Sebastian Andrzej Siewior
> wrote:
>> The cycloneV has three gpio controllers, each one with 29 gpios. This patch
>> adds the three controller with the gpio driver which is now sitting the
>> gpio tree.
>>
On 21/03/2014 at 22:35:26 +0100, Sebastian Hesselbarth wrote :
> On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
> >The Berlin BG2CD has two supported PLLs: CPU PLL and System PLL, add those to
> >the SoC device tree.
> >
> >This also moves the remaining clocks from the clocks container node to th
On Wed, 19 Mar 2014 14:38:32 + Mel Gorman wrote:
> On Fri, Mar 14, 2014 at 11:15:37PM -0400, Sasha Levin wrote:
> > On 03/12/2014 06:36 AM, Mel Gorman wrote:
> > >Andrew, this should go with the patches
> > >mmnuma-reorganize-change_pmd_range.patch
> > >mmnuma-reorganize-change_pmd_range-fix.
On Fri, Mar 21, 2014 at 2:10 PM, Sebastian Andrzej Siewior
wrote:
> On 03/21/2014 06:24 PM, Gerhard Sittig wrote:
>> On Thu, Mar 20, 2014 at 20:55 +0100, Sebastian Andrzej Siewior wrote:
>>>
>>> The cycloneV has three gpio controllers, each one with 29 gpios. This patch
>>> adds the three controll
On Wed, 05 Mar 2014 20:59:04 +0900
Masami Hiramatsu wrote:
> struct kprobe_insn_cache {
> struct mutex mutex;
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index ceeadfc..5b5ac76 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -96,9 +96,6 @@ static raw_spinlock_t *kre
On Friday, March 21, 2014 11:34:49 AM MyungJoo Ham wrote:
>
> Dear Rafael,
Hi,
> Here goes bugfix devfreq patch.
>
> Recent patchset of device-tree support / exynos driver updates is omitted in
> this pull request
> as there could be further updates on the patchset.
OK, pulled, but only beca
On 03/21/2014 02:48 PM, Andi Kleen wrote:
> "H. Peter Anvin" writes:
>>
>> That's why at least to some extent The Right Thing is not to try to
>> pretend to be a CPU you don't even know how to emulate.
>>
>> But again, that has its own issues, too, mostly with userspace
>> optimization, and making
"H. Peter Anvin" writes:
>
> That's why at least to some extent The Right Thing is not to try to
> pretend to be a CPU you don't even know how to emulate.
>
> But again, that has its own issues, too, mostly with userspace
> optimization, and making the Linux code more resilient wouldn't hurt.
> In
On 03/21/2014 08:39 PM, Alexandre Belloni wrote:
Now that we support Berlin BG2Q, select CONFIG_MACH_BERLIN_BG2Q so that we can
boot BG2Q based boards like the BG2Q DMP.
Signed-off-by: Alexandre Belloni
Applied to berlin/soc, Thanks!
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file
On 03/21/2014 08:39 PM, Alexandre Belloni wrote:
Now that we start supporting the Marvell Berlin BG2Q, add a symbol allowing to
differentiate that SoC from the other SoCs of the Berlin family.
Signed-off-by: Alexandre Belloni
Applied to berlin/defconfig, Thanks!
---
arch/arm/mach-berlin/K
On Wed, 05 Mar 2014 20:58:57 +0900
Masami Hiramatsu wrote:
> Since the NMI handlers(e.g. perf) can interrupt in the
> single stepping (or preparing the single stepping, do_debug
> etc.), we should consider a kprobe is hit in the NMI
> handler. Even in that case, the kprobe is allowed to be
> reen
On 03/21/2014 02:37 PM, Andi Kleen wrote:
> On Fri, Mar 21, 2014 at 01:46:04PM -0700, H. Peter Anvin wrote:
>> Not really. That is equally braindamaged. The problem is that KVM is
>> telling the host that our is something it simply cannot be.
>
> Well it has to pick something. It's unlikely it
Hi Mathias,
On Tue, Feb 18, 2014 at 11:04:12AM -0800, David Cohen wrote:
> On Tue, Feb 18, 2014 at 12:47:41PM -0600, Felipe Balbi wrote:
> > On Tue, Feb 18, 2014 at 10:00:30AM -0800, David Cohen wrote:
> > > Hi Sarah,
> > >
> > > On Mon, Jan 06, 2014 at 07:02:19PM -0800, David Cohen wrote:
> > >
On Wed, 05 Mar 2014 20:58:50 +0900
Masami Hiramatsu wrote:
> Current kprobes in-kernel page fault handler doesn't
> expect that its single-stepping can be interrupted by
> an NMI handler which may cause a page fault(e.g. perf
> with callback tracing).
> In that case, the page-fault handled by kpr
On Fri, Mar 21, 2014 at 01:46:04PM -0700, H. Peter Anvin wrote:
> Not really. That is equally braindamaged. The problem is that KVM is
> telling the host that our is something it simply cannot be.
Well it has to pick something. It's unlikely it will ever implement 100% of
that particular CPU.
On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
The Berlin BG2 has two supported PLLs: CPU PLL and System PLL, add those to the
SoC device tree.
This also moves the remaining clocks from the clocks container node to the root.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/berlin2.dt
On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
The Berlin BG2CD has two supported PLLs: CPU PLL and System PLL, add those to
the SoC device tree.
This also moves the remaining clocks from the clocks container node to the root.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/berlin2c
On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
The Berlin BG2Q has two supported PLLs: CPU PLL and System PLL, add those to the
SoC device tree.
Note that support for the AVPLL is not yet available.
Above should not be part of the commit message, no need to resend.
I can fix it up.
Sebastia
On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
Document the device tree bindings for the PLLs found on the Marvell Berlin SoCs.
Cc: devicet...@vger.kernel.org
You forgot to add Mark Rutland's Reviewed-by. He didn't mentioned it
explicitly but his "Otherwise this looks fine to me" on v1, is a
Hi Hubert,
Le Fri, 21 Mar 2014 18:08:07 +0100,
Hubert Chaumette a écrit :
>
> Update KSZ9031RN phy fixup for Congatec conga-QEVAL and conga-QMX6 combo :
> set RGMII GTX_CLK and RX_CLK pad skew to +0.96ns.
>
> Signed-off-by: Hubert Chaumette
> ---
> arch/arm/mach-imx/mach-imx6q.c | 3 +++
> 1
On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
This drivers allows to provide DT clocks for the cpu and system PLLs found on
Marvell Berlin SoCs.
Alexandre,
as mentioned on IRC, I now had a closer look on it. Some minor
remarks below. Sorry, I didn't mention them earlier.
Signed-off-by: Al
This patch adds the hooks in the vmscan logic to discard volatile pages
and mark their pte as purged. With this, volatile pages will be purged
under pressure, and their ptes swap entry's marked. If the purged pages
are accessed before being marked non-volatile, we catch this and send a
SIGBUS.
Thi
One issue that some potential users were concerned about, was that
they wanted to ensure that all the pages from one volatile range
were purged before we purge pages from a different volatile range.
This would prevent the case where they have 4 large objects, and
the system purges one page from eac
Currently we don't shrink/scan the anonymous lrus when swap is off.
This is problematic for volatile range purging on swapless systems/
This patch naievely changes the vmscan code to continue scanning
and shrinking the lrus even when there is no swap.
It obviously has performance issues.
Thought
Users of volatile ranges will need to know if memory was discarded.
This patch adds the purged state tracking required to inform userland
when it marks memory as non-volatile that some memory in that range
was purged and needs to be regenerated.
This simplified implementation which uses some of th
This patch introduces the vrange() syscall, which allows for specifying
ranges of memory as volatile, and able to be discarded by the system.
This initial patch simply adds the syscall, and the vma handling,
splitting and merging the vmas as needed, and marking them with
VM_VOLATILE.
No purging o
Just wanted to send out an updated patch set that includes changes from
some of the reviews. Hopefully folks will have some time to look them
over prior to the LSF-MM discussion on volatile ranges on Tuesday (see
below for LSF-MM discussion points to think about).
New changes are:
On Fri, 2014-03-21 at 09:21 +, David Laight wrote:
> From: Scott Wood [mailto:scottw...@freescale.com]
> > On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
> > > I tried to work out what the 'twi, isync' instructions were for (in
> > > in_le32()).
> > > The best I could come up with was
From: Rob Herring
In preparation to support FIX_EARLYCON_MEM on other arches, make the
option per arch.
Signed-off-by: Rob Herring
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
arch/x86/Kconfig| 3 +++
From: Rob Herring
This started out as an attempt to add arm64's earlyprintk support to ARM
in order to get an earlier, runtime setup console on multi-platform
kernels. The first issue was needing the fixmap support which
conveniently Mark Salter was working on and is mostly in place now. Like
man
1 - 100 of 487 matches
Mail list logo
