Enabling SYNCLINK_CS as a module builds synclink_cs, not synclinkmp.
Signed-off-by: Jean Delvare
---
Who wants to pick this?
drivers/char/pcmcia/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-3.15-rc1.orig/drivers/char/pcmcia/Kconfig 2014-03-31
Hi Miklos,
On Fri, Apr 11, 2014 at 12:25 PM, Miklos Szeredi wrote:
> This series wires up the recently added renameat2 syscall for archs that are
> up-to-date in the sense that they appear to support the latest syscalls. I
> haven't touched the rest of them..
>
> Plus three NR_syscalls
The sequence of calls for dynticks CPUs was a bit confusing and so adding a
comment in tick_nohz_idle_exit() routine to mention it clearly. All information
required is in commit and this conversation with Frederic.
https://lkml.org/lkml/2014/4/10/355
Suggested-by: Frederic Weisbecker
On 04/14/2014 09:24 AM, Torsten Duwe wrote:
> On Mon, Apr 14, 2014 at 09:09:14AM -0700, H. Peter Anvin wrote:
>> I think the default should be zero, so each hwrng driver maintainer would
>> have to consider what guarantees that particular driver can give. If
>> anything 50% ought to be the
We have added a wrapper around tick_do_broadcast_on_off() which doesn't have
anything so special that we should keep it. It just had a check if cpu is online
or not. Just merge these two routines and keep one: tick_broadcast_on_off().
This would get rid of an extra function call that we are doing
Hi Miklos,
On Fri, Apr 11, 2014 at 12:25 PM, Miklos Szeredi wrote:
> From: Miklos Szeredi
Thanks!
> Signed-off-by: Miklos Szeredi
> Cc: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond
We are doing an extra comparison in tick_do_broadcast_on_off():
if (*reason == CLOCK_EVT_NOTIFY_BROADCAST_FORCE)
tick_broadcast_force = 1;
Whereas it can be handled easily in the switch block only.
It doesn't look like there is any strict ordering of
On Mon, Apr 14, 2014 at 12:19 PM, Pranith Kumar wrote:
> Hi Paul,
>
> On Mon, Apr 14, 2014 at 12:07 PM, Paul E. McKenney
> wrote:
>> On Sun, Apr 13, 2014 at 05:53:53PM -0400, Pranith Kumar wrote:
>>> remove duplicate definition of extern resched_cpu
>>>
>>> Signed-off-by: Pranith Kumar
>>
>>
All users of clockevents_handle_noop() are setting old->event_handler to it
after calling clockevents_exchange_device() and so it would be better if we can
do this at a single place. The only thing we need to make sure is, we preserve
it before calling clockevents_exchange_device() in case we need
As a nice side effect this fixes the cf_port leak on
dma_coerce_mask_and_coherent() or ata_host_activate()
failure.
Cc: Ralf Baechle
Cc: David Daney
Suggested-by: Guenter Roeck
Signed-off-by: Bartlomiej Zolnierkiewicz
---
Compile tested only.
drivers/ata/pata_octeon_cf.c | 50
On Mon, 14 Apr 2014 stef...@seibold.net wrote:
> Zitat von Alan Stern :
>
>
> >> <6>[ 167.936921] usb 2-2.1: new full-speed USB device number 3
> >> using ohci-pci
> >> <6>[ 168.067890] usb 2-2.1: New USB device found, idVendor=076b,
> >> idProduct=a021
> >> <6>[ 168.074871] usb 2-2.1: New
Signed-off-by: Viresh Kumar
---
kernel/time/tick-sched.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 22b9505..f1bc258 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -792,7 +792,7 @@
Local variable 'now' is used at only one place and so can be easily replaced by
ktime_get() instead.
Signed-off-by: Viresh Kumar
---
kernel/time/tick-sched.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index
Some of the checks which may force tick_do_broadcast_on_off() to return early
can be done before taking locks. This would make these codepaths faster.
Signed-off-by: Viresh Kumar
---
kernel/time/tick-broadcast.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff
can_stop_idle_tick() checks if a local softirq is pending or not, and in case
it is pending we call the same routine two more times.
Rather store the value in a local variable and reuse it.
Signed-off-by: Viresh Kumar
---
kernel/time/tick-sched.c | 10 +-
1 file changed, 5
Fix sparse complaint: "Using plain integer as NULL pointer"
Signed-off-by: Denis Pithon
---
drivers/staging/lustre/lustre/ptlrpc/sec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec.c
b/drivers/staging/lustre/lustre/ptlrpc/sec.c
This patch introduces a derating factor to struct hwrng for
the random bits going into the kernel input pool, and a common
default derating for drivers which do not specify one.
Signed-off-by: Torsten Duwe
---
drivers/char/hw_random/core.c | 11 ++-
include/linux/hw_random.h |
NO_HZ feature can be enabled/disabled from bootargs if we have a string 'nohz='
followed by 'on' or 'off'. The default value of this variable is '1'. When 'on'
is passed as bootarg, we don't have to overwrite this variable by '1'.
Also, an extra blank line is removed.
Signed-off-by: Viresh
We are doing this currently:
int cpu;
cpu = smp_processor_id();
And we can rewrite it to make it shorter:
int cpu = smp_processor_id();
Signed-off-by: Viresh Kumar
---
kernel/time/tick-sched.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
There is only one caller of tick_check_oneshot_change(), i.e.
hrtimer_run_pending(). Firstly hrtimer_run_pending() is calling this routine
after doing a '!' of its parameter and then tick_check_oneshot_change() is also
using it after doing a '!' of its parameter.
It would be more efficient and
tick_check_percpu() and tick_check_preferred() are called from two places and in
exactly same order. So, would make sense to call tick_check_percpu() from
tick_check_preferred() instead, so that their common caller can just call
tick_check_preferred().
Signed-off-by: Viresh Kumar
---
We are accessing &__get_cpu_var(tick_cpu_device) at several places in kernel.
Lets create another routine tick_get_cpu_device() which would return
tick_cpu_device for this-cpu.
Signed-off-by: Viresh Kumar
---
include/linux/tick.h | 5 +
kernel/hrtimer.c | 2 +-
Some fields of 'struct tick_sched' didn't had a description in the kernel doc
comment present above its declaration. Add them.
Signed-off-by: Viresh Kumar
---
include/linux/tick.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/tick.h
tick_cpu_device isn't local only to kernel/time/ directory and its declaration
is present in hrtimer.h and tick-internal.h. Rather move it to a common place,
i.e. tick.h.
Signed-off-by: Viresh Kumar
---
include/linux/hrtimer.h | 3 ---
include/linux/tick.h| 2 ++
There are multiple users of tick_get_device() which are currently using
_cpu(tick_cpu_device, cpu) directly. Would be better to move definition of
tick_get_device() to tick.h and move others to use this routine instead.
This change reduced size of bzImage for x86 by 96 bytes.
Signed-off-by:
Hi Thomas,
These are separate cleanups from the timers/hrtimers ones I did. I was waiting
for the merge window to close in order to send these and by the time it
happened, I got a long pending list.
These are mostly cleanups, reorders for better readability or efficiency, and
few bugfixes.
I
Please read Documentation/this_cpu_ops.txt for reference for how to use
these functions. However, you want to avoid forming a pointer if you
can; it is relatively expensive to do so.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 04/14/2014 01:39 AM, Chen, Gong wrote:
> @@ -619,7 +619,7 @@ void machine_check_poll(enum mcp_flags flags, mce_banks_t
> *b)
> continue;
>
> v = _cpu_var(mce_polled_error);
> - set_bit(0, v);
> + *v = 1;
>
On Sun, Apr 13, 2014 at 12:18 PM, Marek Vasut wrote:
[...]
>> +#define OPCODE_RDFSR0x70 /* read flag status register */
>
> I know this is not your fault, but can you please indent this properly with
> tabs?
>
>> #define OPCODE_NORM_READ0x03/* Read data bytes
Hi Paul,
On Mon, Apr 14, 2014 at 12:07 PM, Paul E. McKenney
wrote:
> On Sun, Apr 13, 2014 at 05:53:53PM -0400, Pranith Kumar wrote:
>> remove duplicate definition of extern resched_cpu
>>
>> Signed-off-by: Pranith Kumar
>
> Hello, Pranith,
>
> When I apply this patch I get the following:
>
>
Hi Davidlohr,
Thanks for providing the DMAR table. According to the DMAR
table, one bug in the iommu driver fails to handle this entry:
[1D2h 0466 1] Device Scope Entry Type : 01
[1D3h 0467 1] Entry Length : 0A
[1D4h 0468 2] Reserved :
On 04/14/2014 01:39 AM, Chen, Gong wrote:
> @@ -1287,14 +1287,14 @@ static unsigned long (*mce_adjust_timer)(unsigned
> long interval) =
>
> static int cmc_error_seen(void)
> {
> - unsigned long *v = &__get_cpu_var(mce_polled_error);
> + unsigned long *v = this_cpu_ptr(_polled_error);
On Wed, Mar 19, 2014 at 06:47:35AM +, Peter Zijlstra wrote:
> ARM uses ll/sc primitives that do not imply barriers for all regular
> atomic ops, therefore smp_mb__{before,after} need be a full barrier.
>
> Since ARM doesn't use asm-generic/barrier.h include the required
> definitions in its
On 14/04/14 08:40, Jungseok Lee wrote:
> This patch deals with checkpatch complaint as fixing line length
> exceeding 80 characters.
>
> WARNING: line over 80 characters
>
> Signed-off-by: Jungseok Lee
> Reviewed-by: Sungjinn Chung
> ---
> arch/arm/kvm/mmu.c |4 ++--
> 1 file changed, 2
With bigalloc enabled we must use EXT4_CLUSTERS_PER_GROUP() instead of
EXT4_BLOCKS_PER_GROUP() otherwise we will go beyond the allocated buffer.
$ mount -t ext4 /dev/vde /vde
[ 70.573993] EXT4-fs DEBUG (fs/ext4/mballoc.c, 2346): ext4_mb_alloc_groupinfo:
[ 70.575174] allocated s_groupinfo
sched_can_stop_tick() was using 7 spaces instead of 8 spaces or a 'tab' at the
beginning of each line. Which doesn't align with the Coding Guidelines.
Also it removes the *rq variable as it was used at only one place and hence we
can directly use this_rq() instead.
Signed-off-by: Viresh Kumar
On Mon, Apr 14, 2014 at 9:02 AM, Masami Ichikawa wrote:
> kmemleak reported some memory leak as below.
grrr. yes. sorry.
> unreferenced object 0x8800d6ea4000 (size 512):
> comm "sshd", pid 278, jiffies 4294898315 (age 46.653s)
> hex dump (first 32 bytes):
> 21 00 00 00 04 00 00 00
On Wed, Mar 12, 2014 at 09:56:34PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 06, 2014 at 09:11:22PM +0100, Alexander Gordeev wrote:
> > As result of deprecation of MSI-X/MSI enablement functions
> > pci_enable_msix() and pci_enable_msi_block() all drivers
> > using these two interfaces need to be
Move the declaration/definition of allow_signal/disallow_signal to
signal.h/signal.c. The new place is more logical and allows to use
the static helpers in signal.c (see the next changes).
While at it, make them return void and remove the valid_signal()
check. Nobody checks the returned value,
On Mon, Apr 14, 2014 at 08:49:58AM -0700, Andy Lutomirski wrote:
> [Resent because I forgot to email lkml. This also surreptitiously
> fixes a silly typo on a patch description.]
>
> This is my attempt to come up with a workable way to use so-called
> entropy sources like a TPM to feed
On Mon, Apr 14, 2014 at 9:31 PM, Bartlomiej Zolnierkiewicz
wrote:
> Add missing cf_exit() and clk_put() calls to ata_host_activate()
> failure path.
>
> Cc: Viresh Kumar
> Cc: Shiraz Hashim
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> v2:
> - re-order code and then drop redundant goto
On 14/04/14 08:41, Jungseok Lee wrote:
> This patch adds 4 levels of translation tables implementation for both
> HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4 levels
> guest can run on ARMv8 architecture as introducing this feature.
>
> Signed-off-by: Jungseok Lee
>
On April 14, 2014 2:59:32 PM GMT+01:00, "Joël Porquet" wrote:
>
>
>On Saturday, April 12, 2014 06:28:07 PM Jonathan Cameron wrote:
>>
>> On 09/04/14 19:09, Joel Porquet wrote:
>> > As suggested by checkpatch.pl, use dev_info() instead of
>> > printk(KERN_INFO ...) to print message.
>> >
>> >
I think the default should be zero, so each hwrng driver maintainer would have
to consider what guarantees that particular driver can give. If anything 50%
ought to be the maximum.
On April 14, 2014 9:02:11 AM PDT, Torsten Duwe wrote:
>More or less a resend of v2.
>
>On Wed, Mar 26, 2014 at
From: Andi Kleen
perf stat -rX prints the stddev for multiple measurements.
Just looking at the stddev for judging the quality of the data
is a bit dangerous The simplest sanity check is to just look
at a simple plot. This patchs add a sparkline to the end
of the measurements to make it simple
This patch introduces a derating factor to struct hwrng for
the random bits going into the kernel input pool, and a common
default derating for drivers which do not specify one.
Signed-off-by: Torsten Duwe
---
drivers/char/hw_random/core.c | 11 ++-
include/linux/hw_random.h |
This can be viewed as the in-kernel equivalent of hwrngd;
like FUSE it is a good thing to have a mechanism in user land,
but for some reasons (simplicity, secrecy, integrity, speed)
it may be better to have it in kernel space.
This patch creates a thread once a hwrng registers, and uses
the
On Mon, 14 Apr 2014 13:27:14 +0200
Ingo Molnar wrote:
> So I rebased the patch Steve tested as-is and only fixed the patch
> description and some comments in the code, preserving Steve's testing
> status, and propagated it into x86/urgent.
I pulled your latest x86/urgent branch, booted it and
On Sun 13-04-14 07:21:32, Matthew Wilcox wrote:
> On Wed, Apr 09, 2014 at 11:12:03PM +0200, Jan Kara wrote:
> > This would be fine except that unmap_mapping_range() grabs i_mmap_mutex
> > again :-|. But it might be easier to provide a version of that function
> > which assumes i_mmap_mutex is
This patch adds an interface to the random pool for feeding entropy in-kernel.
It may serve as a destination for dedicated HWRNGs.
It resembles -- and could be merged with -- the ioctl(RNDADDENTROPY) code, plus
a sleep condition for eager writers.
Signed-off-by: Torsten Duwe
---
kmemleak reported some memory leak as below.
unreferenced object 0x8800d6ea4000 (size 512):
comm "sshd", pid 278, jiffies 4294898315 (age 46.653s)
hex dump (first 32 bytes):
21 00 00 00 04 00 00 00 15 00 01 00 3e 00 00 c0 !...>...
06 00 00 00 00 00 00 00 21 00 00 00 00 00
More or less a resend of v2.
On Wed, Mar 26, 2014 at 06:03:37PM -0700, H. Peter Anvin wrote:
> I'm wondering more about the default. We default to 50% for
> arch_get_random_seed, and this is supposed to be the default for in effect
> unverified hwrngs...
Done. 50% is now the default, that's
Add missing cf_exit() and clk_put() calls to ata_host_activate()
failure path.
Cc: Viresh Kumar
Cc: Shiraz Hashim
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- re-order code and then drop redundant goto statement
drivers/ata/pata_arasan_cf.c |7 +--
1 file changed, 5
Hi,
On Tuesday, April 01, 2014 09:50:42 AM Viresh Kumar wrote:
> On Mon, Mar 31, 2014 at 11:19 PM, Bartlomiej Zolnierkiewicz
> wrote:
> > Add missing cf_exit() and clk_put() calls to ata_host_activate()
> > failure path.
> >
> > Cc: Viresh Kumar
> > Cc: Shiraz Hashim
> > Signed-off-by:
Adding automated test for memory maps lookup within multiple machines
threads.
The test creates 4 threads and separated memory maps.
It checks that we could use thread__find_addr_map function with thread
object based on TID to find memory maps.
Cc: Don Zickus
Cc: Corey Ashford
Cc: David Ahern
hi,
this patchset moves thread's map_groups to be dynamically
allocated and shared within process threads.
The main benefit would be to be able to look up memory
map from any thread that belongs to the process.
This implements one of the solution ideas for issue
described by Don in following
On Mon, Apr 14, 2014 at 08:45:16AM -0700, James Bottomley wrote:
> Your subject line is very tame. It should be the one line summary of
> why we apply the patch, so it should read something like
>
> hpsa: fix NULL deref in performant mode
>
> On Thu, 2014-04-10 at 17:17 -0500,
Sharing map groups within all process threads. This way
there's only one copy of mmap info and it's reachable
from any thread within the process.
Original-patch-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc:
From: Arnaldo Carvalho de Melo
We will share it among threads in the same process.
Signed-off-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane
This test create 2 processes abstractions, with several threads
and checks they properly share and maintain map groups info.
Cc: Don Zickus
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho
From: Arnaldo Carvalho de Melo
Moving towards sharing map groups within a process threads.
Because of this we need the map groups to be dynamically allocated. No
other functional change is intended in here.
Based on a patch by Jiri Olsa, but this time _just_ making the
conversion from
[Resent because I forgot to email lkml. This also surreptitiously
fixes a silly typo on a patch description.]
This is my attempt to come up with a workable way to use so-called
entropy sources like a TPM to feed /dev/urandom.
Arguably we should be feeding the input pool as well, but if the
TPMs contain a DRBG. Use it.
On some but not all TPMs, this will also call add_drbg_randomness on
resume. As a future improvement, this could be tweaked to cover all
of them, but I'll leave that to someone more familiar with the
individual drivers.
Signed-off-by: Andy Lutomirski
---
There has been a longstanding debate as to how devices such as TPMs
should be used to seed the kernel's RNG. Arguments in this debate
include:
- The TPM is untrustworthy and possibly malicious, so we shouldn't use
it.
- The TPM almost certainly supplies no real entropy, so we shouldn't
On Mon, Apr 14, 2014 at 12:15:01PM +0200, Michael Kerrisk wrote:
> Alex,
>
> Your commit a0715cc22601e8830ace98366c0c2bd8da52af52 added the prctl()
> PR_SET_THP_DISABLE and PR_GET_THP_DISABLE flags.
>
> The text below attempts to document these flags for the prctl(3).
> Could you (and anyone
On Sun 13-04-14 18:10:30, xypron.g...@gmx.de wrote:
> From: Heinrich Schuchardt
>
> Before the patch,
> read creates FAN_ACCESS_PERM and FAN_ACCESS events,
> readdir creates only FAN_ACCESS_PERM events.
>
> This is inconsistent.
>
> After the patch,
> readdir creates FAN_ACCESS_PERM and
On Thu, Mar 27, 2014 at 10:40:49PM -0400, Tejun Heo wrote:
[..]
> This patchset finally implements the default unified hierarchy. The
> goal is providing enough flexibility while enforcing stricter common
> structure where appropriate to address the above listed issues.
>
> Controllers which
allow_signal() does sigdelset(current->blocked) due to historic
reason, previously it could be called by a daemonize()'ed kthread,
and daemonize() played with current->blocked.
Now that daemonize() has gone away we can remove sigdelset() and
recalc_sigpending(). If a user really wants to unblock
On 04/14/2014 04:31 AM, Bart Tanghe wrote:
> Is it the responsibility of the pwm driver to handle the pinmux of the
> io pins? Or is the end user, or a parent driver responsible to handle this?
> Idem for the clock?
The pinmux driver is responsible for writing to the pinmux registers.
This can be
For both of these, though, it is really kind of broken that it is a global
switch, whereas typically only one application on the whole system needs it, so
it would be much better to have application-specific controls. How to do that
is another matter...
On April 14, 2014 12:27:56 AM PDT, Ingo
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, April 14, 2014 1:15 AM
> To: KY Srinivasan
> Cc: o...@aepfle.de; a...@canonical.com; x...@kernel.org;
> t...@linutronix.de; de...@linuxdriverproject.org;
> gre...@linuxfoundation.org; jasow...@redhat.com;
Sorry for the delay, I've been having to take turns for this box.
On Fri, 2014-04-11 at 09:18 +, Woodhouse, David wrote:
> On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
> > Attaching a dmesg from one of the kernels that boots. It doesn't appear
> > to have much of the related
Zitat von Benjamin Herrenschmidt :
On Sun, 2014-04-13 at 21:22 +0200, Stefani Seibold wrote:
When executing a kexec kernel on a PowerPC board the new started kernel
will not find already enumerated USB devices due a missing reset on the
USB bus.
As a work around a
echo 1
Your subject line is very tame. It should be the one line summary of
why we apply the patch, so it should read something like
hpsa: fix NULL deref in performant mode
On Thu, 2014-04-10 at 17:17 -0500, scame...@beardog.cce.hp.com wrote:
> Without this, you'll see a null pointer dereference in
>
acpi_processor_add() assumes that present at boot CPUs
are always onlined, it is not so if a CPU failed to become
onlined. As result acpi_processor_add() will mark such CPU
device as onlined in sysfs and following attempts to
online/offline it using /sys/device/system/cpu/cpuX/online
attribute
disallow_signal() simply sets SIG_IGN, this is not enough and
recalc_sigpending() is simply pointless because in can never
change the state of TIF_SIGPENDING.
If we ignore a signal, we also need to do flush_sigqueue_mask() for
the case when this signal is pending, this way recalc_sigpending()
can
Hi,
On Fri, Apr 11, 2014 at 8:33 PM, wrote:
> From: Graham Moore
>
> Some new Micron flash chips require reading the flag
> status register to determine when operations have completed.
>
> Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> require reading the status
On Mon, Apr 14, 2014 at 04:13:35PM +0100, Steve Capper wrote:
> On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
[ ... ]
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 0fd5650..0b0b16a 100644
> > --- a/arch/arm64/kernel/head.S
> > +++
jffs2_garbage_collect_thread() does disallow_signal(SIGHUP) around
jffs2_garbage_collect_pass() and the comment says "We don't want
SIGHUP to interrupt us".
But disallow_signal() can't ensure that jffs2_garbage_collect_pass()
won't be interrupted by SIGHUP, the problem is that SIGHUP can be
BugLink: http://bugs.launchpad.net/bugs/1306677
While booting the PPC64EL kernel, the command line gets truncated to 512
characters. This is due to a hard limit of 512 defined for COMMAND_LINE_SIZE.
It would be beneficial to have a command line longer than 512 characters, as
iscsi targets and
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
index 6980fa1..d90f82a 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
+++
On 04/14/2014 05:11 PM, Ingo Molnar wrote:
* Jovi Zhangwei wrote:
Obviously many people love ktap nowadays even though it's not a
C-family language, [...]
Imagine how much more widespread it would become amongst kernel
developers if it had C syntax - see PeterZ's reply for example.
+1
I
On 8 April 2014 14:13, Dave Martin wrote:
> On Wed, Mar 26, 2014 at 04:49:09PM +, Jay Foad wrote:
>> The emulation for single and double precision multiply accumulate
>> instructions correctly normalised any denormal values in the operand
>> registers, but failed to normalise the destination
Please send the complete oops message.
Is this a regression? If so, do you know what the last kernel version
was that worked?
Thanks
James
On 14/04/14 14:33, Zhan Jianyu wrote:
> When I tried to connect my VPN, I got a panic, saying
> a NULL poiter dereference at 0x02c0
>
> I came
Zitat von Alan Stern :
<6>[ 167.936921] usb 2-2.1: new full-speed USB device number 3
using ohci-pci
<6>[ 168.067890] usb 2-2.1: New USB device found, idVendor=076b,
idProduct=a021
<6>[ 168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
<6>[ 168.082226] usb
Disabling the DMFC module while there is still data in the FIFOs could
cause the "new frame before end of frame" error state when the DMFC is
enabled again.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 25 +++--
1 file changed, 23
The former has to be done before disabling the DMFC, the latter has to be
done afterwards. Otherwise the DMFC FIFOs never get cleared properly.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 +
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 68
Now that ipu_dc_disable_channel correctly waits for the channel to finish,
we can reorder the enable/disable order to first stop the DC and DI and
only then disable the IDMAC. Enabling is done the other way around: IDMAC
first, then DC, then DI.
This avoids an issue where sometimes the channel
This allows to request the DC related interrupts.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 1 +
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 19 +--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git
Wait for the DC Frame Complete or DP Sync Flow End interrupts
before disabling DC channels.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++--
1 file changed, 50 insertions(+), 21 deletions(-)
diff --git
Repeatedly enabling and disabling the display currently can lead to a state
in which the IPU doesn't produce a valid signal anymore because we disable
IPU submodules before they can finish their interaction.
This series reorders the enable/disable sequence so that we first wait for the
DC/DP to
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 22 ++
drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
Now that allow_signal() is really trivial we can unify it with
disallow_signal(). Add the new helper, kernel_sigaction(), and
reimplement allow_signal/disallow_signal as a trivial wrappers.
This saves one EXPORT_SYMBOL() and the new helper can have more
users.
Signed-off-by: Oleg Nesterov
---
Now that we have kernel_sigaction() we can change wait_for_helper()
to use it and cleanups the code a bit.
Signed-off-by: Oleg Nesterov
---
kernel/kmod.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 6b375af..c18c891 100644
---
The usage of "task_struct *t" and "current" in do_sigaction() looks
really annoying and chaotic. Initially "t" is used as a cached value
of current but not consistently, then it is reused as a loop variable
and we have to use "current" again.
Cleanup this mess and also convert the code to use
"rm_from_queue_full" looks ugly and misleading, especially now that
rm_from_queue() has gone away. Rename it to flush_sigqueue_mask(),
this matches flush_sigqueue() we already have.
Also remove the obsolete comment which explains the difference with
rm_from_queue() we already killed.
ll_set_cpu_coherent is always used on the current CPU, so instead of
passing the CPU id as argument, ll_set_cpu_coherent() can find it by
itself.
Signed-off-by: Gregory CLEMENT
Acked-by: Thomas Petazzoni
---
arch/arm/mach-mvebu/coherency.c| 10 +-
arch/arm/mach-mvebu/coherency.h
This patch set adds the CPU idle support for Armada XP and prepares
the support for Armada 370. This was based on the work of Nadav
Haklai.
The main change in this new version is a rebasing onto the v3.15-rc1
and the last PMSU reworked series sent by Thomas Petazzoni:
When going to deep idle we need to disable the SoC snooping (aka
hardware coherency support). Playing with the coherency fabric
requires to use assembly code to be sure that the compiler doesn't
reorder the instructions nor do wrong optimization.
Signed-off-by: Gregory CLEMENT
---
Actually enabling coherency and adding a CPU on a SMP group are two
different operations which can be done separately. This patch splits
this in two functions.
Moreover as they use common pattern, this patch also creates local low
level functions (ll_get_coherency_base and ll_get_cpuid) to be
501 - 600 of 2040 matches
Mail list logo
