From: Rafael J. Wysocki
During system suspend mark ACPI buttons (other than the lid) as
"suspended" and if in that state, report wakeup events on button
events, but do not propagate those events up the stack.
This prevents systems from being turned off after a button-triggered
wakeup from the
On 07/18/2014 03:09 PM, Stephen Boyd wrote:
> During suspend we call sched_clock_poll() to update the epoch and
> accumulated time and reprogram the sched_clock_timer to fire
> before the next wrap-around time. Unfortunately,
> sched_clock_poll() doesn't restart the timer, instead it relies
> on
From: Rafael J. Wysocki
After the introduction of freeze_ops it makes more sense to move
all of the platform suspend operations to separate functions that
each will do all of the necessary checks and choose the right
callback to execute istead of doing all that in the core code
which makes it
On Fri, Jul 18, 2014 at 05:38:30PM +0300, Andrey Utkin wrote:
> Is there script for automated checkpatch.pl && get_maintainers.pl &&
> git send-email for range of commits? I see none. Would it be welcome
> to submit such one to kernel tree?
Too much automation can be a really bad thing. You
On Fri, Jul 18, 2014 at 2:18 PM, Andy Lutomirski wrote:
> populate_seccomp_data is expensive: it works by inspecting
> task_pt_regs and various other bits to piece together all the
> information, and it's does so in multiple partially redundant steps.
>
> Arch-specific code in the syscall entry
During suspend we call sched_clock_poll() to update the epoch and
accumulated time and reprogram the sched_clock_timer to fire
before the next wrap-around time. Unfortunately,
sched_clock_poll() doesn't restart the timer, instead it relies
on the hrtimer layer to do that and during suspend we
From: Hannes Frederic Sowa
The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
actually increase entropy_count if during assignment of the unsigned
expression on the RHS (mind the -=) we reduce the value modulo
2^width(int) and assign it to entropy_count. Trinity found this.
[
On Wed, Jul 16, 2014 at 06:09:58PM +0800, Lai Jiangshan wrote:
> In this code:
> if ((worker->flags & WORKER_UNBOUND) && need_more_worker(pool))
> wake_up_worker(pool);
>
> the first test is unneeded. Even the first test is removed, it doesn't affect
> the wake-up logic when
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
On Fri, Jul 18, 2014 at 05:06:04PM +0200, Thierry Reding wrote:
> I think the following patches can go through your tree without causing
> breakage through unresolved dependencies:
>
> [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding
> [PATCH v3 6/8] ata: ahci_platform:
On Fri, Jul 18, 2014 at 05:25:04PM -0400, Theodore Ts'o wrote:
> > As indicated by credit_entropy_bits entropy_count cannot get negative,
> > so I don't see any reason to include a check for entropy_count < 0
> > here. Do you agree?
>
> No, the check is important; after we subtract ibytes <<
> On Fri, Jul 18, 2014 at 08:40:42PM +, Conrad Kostecki wrote:
> > Where is the problem? Why is the microcode not being loaded early?
>
> CONFIG_MICROCODE_INTEL_EARLY=y set in .config?
Yes!
Galactica tmp # grep -i microcode /boot/config-3.15.5
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
#
> -Original Message-
> From: Sitsofe Wheeler [mailto:sits...@gmail.com]
> Sent: Tuesday, July 15, 2014 1:09 AM
> To: Haiyang Zhang
> Cc: KY Srinivasan; David S. Miller; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re:
On Friday, July 18, 2014 01:57:17 PM Joerg Roedel wrote:
> Hi,
>
> here is a patch set to improve the scalability of the memory
> bitmap implementation used for hibernation. The current
> implementation does not scale well to machines with several
> TB of memory. A resume on those machines may
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
Hi,
On Fri, Jul 18, 2014, at 23:25, Theodore Ts'o wrote:
> On Wed, Jul 16, 2014 at 09:18:15PM +0200, Hannes Frederic Sowa wrote:
> > The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
> > actually increase entropy_count if during assignment of the unsigned
> > expression on the
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
> > > I'm not sure what the appropriate action for a video
On Fri, Jul 18, 2014 at 7:12 AM, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> This is the latest regressions that we found while testing the at91sam9n12 and
> at91sam9x5 platforms following our move to CCF.
> I created a pull-request this time because I have 3 patches: there should be
> no
On 18.07.2014 22:03, poma wrote:
On 18.07.2014 16:20, Christoph Lameter wrote:
On Fri, 18 Jul 2014, poma wrote:
I guess someone working over the summertime. :)
Cache names should not contain blanks. I guess the
WARN_ON(strchr(name, ' ')); /* It confuses parsers */
was triggered?
On 18.07.2014 22:16, poma wrote:
On 18.07.2014 22:07, James Bottomley wrote:
On Fri, 2014-07-18 at 22:01 +0200, poma wrote:
On 18.07.2014 16:17, Christoph Hellwig wrote:
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
Slab warns, because the name of the cache being created
On Fri, Jul 18, 2014 at 02:23:04PM -0700, Tony Luck wrote:
> On Thu, Jul 17, 2014 at 3:50 AM, Borislav Petkov wrote:
> > Well, maybe it is about time we tracked shared banks.
>
> For cpus that support CMCI and the MCi_CTL2 registers we do track
> sharing. Only one cpu gets to be the "owner" of a
Two global variables, "syslog_prev" and "console_prev", maintain a
copy of the flags value used in the log record most recently
formatted for syslog or the console, respectively.
Initially there is no previous formatted log record, and these
variables simply have an initial value 0. And
Each log record has a "flags" field. The flags keep track of, for
instance, whether the record was saved in its entirety (as opposed
to being one of multiple records that should be merged as a single
unit). A log record's flags field alone is not currently sufficient
to know how the record
Two log record flags--LOG_CONT and LOG_NEWLINE--are mutually
exclusive. That is, one or the other is always set, but they are
never both set at the same time in a log record flags field. What
follows is a great deal of explanation that aims to prove this
assertion.
Having that knowledge allows
In devkmsg_read(), a variable "cont" holds a character that's used
to indicate whether a given log line is a "continuation", that is,
whether a log record should be merged with the one before or after
it. If a record should be merged with its successor (but not its
predecessor) that character is
It is possible for the log to be filled too quickly for the consoles
to be able to keep up. This is detected in console_unlock(), and when
it occurs, a message is inserted to note the event. When reviewing
some nearby code, Petr Mládek suggested it might be nicer if this
message were placed on a
This patch fixes a problem similar to what was addressed in the
previous patch.
All paths that read and format log records (for consoles, and for
reading via syslog and /dev/kmsg) go through msg_print_text(). That
function starts with some logic to determine whether the given log
record when
This patch corrects a few more typographical errors in "printk.c".
Signed-off-by: Alex Elder
Reviewed-by: Petr Mládek
---
kernel/printk/printk.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index a5ad81c..fd1ecd4
If a log record has LOG_PREFIX set, its predecessor record should be
terminated if it was marked LOG_CONT.
In devkmsg_read(), this condition was being ignored, which would
lead to such records showing up combined when reading /dev/kmsg.
Fix this oversight.
We should similarly insert a newline in
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > > device from doing anything, which isn't what you
On Wed, Jul 16, 2014 at 09:18:15PM +0200, Hannes Frederic Sowa wrote:
> The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
> actually increase entropy_count if during assignment of the unsigned
> expression on the RHS (mind the -=) we reduce the value modulo
> 2^width(int) and
On Fri, Jul 18, 2014 at 08:40:42PM +, Conrad Kostecki wrote:
> Where is the problem? Why is the microcode not being loaded early?
CONFIG_MICROCODE_INTEL_EARLY=y set in .config?
You can also try with a recent distro kernel and initrd which has
microcode in it to rule out you're doing
On Thu, Jul 17, 2014 at 3:50 AM, Borislav Petkov wrote:
> Well, maybe it is about time we tracked shared banks.
For cpus that support CMCI and the MCi_CTL2 registers we do track
sharing. Only one cpu gets to be the "owner" of a bank that supports
CMCI (the first one to find it and set bit 30 in
On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
Nicolas Pitre wrote:
>
> Here's the patch I have at the head of the series now, with the above
> ugliness changed to an unconditional __tracepoint_string attribute.
>
I was thinking of something like this. Feel free to add this to your
series.
--
populate_seccomp_data is expensive: it works by inspecting
task_pt_regs and various other bits to piece together all the
information, and it's does so in multiple partially redundant steps.
Arch-specific code in the syscall entry path can do much better.
Admittedly this adds a bit of additional
This splits syscall_trace_enter into syscall_trace_enter_phase1 and
syscall_trace_enter_phase2. Only phase 2 has full pt_regs, and only
phase 2 is permitted to modify any of pt_regs except for orig_ax.
The intent is that phase 1 can be called from the syscall fast path.
Signed-off-by: Andy
For slowpath syscalls, we initialize regs->ax to -ENOSYS and stick
the syscall number into regs->orig_ax prior to any possible tracing
and syscall execution. This is user-visible ABI used by ptrace
syscall emulation and seccomp.
For fastpath syscalls, there's no good reason not to do the same
is_compat_task() is the wrong check for audit arch; the check should
be is_ia32_task(): x32 syscalls should be AUDIT_ARCH_X86_64, not
AUDIT_ARCH_I386.
CONFIG_AUDITSYSCALL is currently incompatible with x32, so this has
no visible effect.
Signed-off-by: Andy Lutomirski
---
On KVM on my box, this reduces the overhead from an always-accept
seccomp filter from ~130ns to ~17ns. Most of that comes from
avoiding IRET on every syscall when seccomp is enabled.
In extremely approximate hacked-up benchmarking, just bypassing IRET
saves about 80ns, so there's another 43ns of
The reason I did this is to add a seccomp API that will be usable
for an x86 fast path. The x86 entry code needs to use a rather
expensive slow path for a syscall that might be visible to things
like ptrace. By splitting seccomp into two phases, we can check
whether we need the slow path and
The secure_computing function took a syscall number parameter, but
it only paid any attention to that parameter if seccomp mode 1 was
enabled. Rather than coming up with a kludge to get the parameter
to work in mode 2, just remove the parameter.
To avoid churn in arches that don't have seccomp
This is both a cleanup and a speedup. It reduces overhead due to
installing a trivial seccomp filter by 87%. The speedup comes from
avoiding the full syscall tracing mechanism for filters that don't
return SECCOMP_RET_TRACE.
This series works by splitting the seccomp hooks into two phases.
The
Thomas,
Here are the core changes I've gathered so far for v3.17. irq-gic.c has
been a little adventuresome this cycle. There's still the possibility
of some more code making it in for gic (assuming we don't run out of
time), which is why I merged a tag into core instead of the branch.
As
I am announcing the release of the Linux 3.13.11.5 kernel.
The updated 3.13.y tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y
and can be browsed at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog
The diff from v3.13.11.4 is
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file
2014-07-18 23:48 GMT+03:00 Julian Anastasov :
> The above check ensures the set_arglen[] value (some
> struct size) does not exceed the arg[MAX_ARG_LEN] space. You can check
> commit 04bcef2a83f40c ("ipvs: Add boundary check on ioctl arguments")
> for more info.
Thanks for info.
What
On Fri, Jul 18, 2014 at 02:44:34PM -0600, Shuah Khan wrote:
> Add a new devtest make target to enable developer testing. This
> new target does full build (make all) and then runs selftests.
>
> Signed-off-by: Shuah Khan
Nice to see this.
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from
>
> All these things are not introduced by your patch but now that
> you show some love and care for this file maybe we could take
> the next step and bring more order to the current semi chaos?
And I just noticed...
These are never used - and only defined a few places:
#define inb_p(addr)
Hello,
On Fri, 18 Jul 2014, Andrey Utkin wrote:
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80601
> Reported-by: David Binderman
> Signed-off-by: Andrey Utkin
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On Fri, 2014-07-18 at 16:37 -0400, Nicholas Krause wrote:
> The comment for size of frame not being needed is incorrect , the
> function called needs this parameter.
Actually, that's not correct. The point of the FIXME is that fram_size
is only used in a debug print and could be eliminated since
On Wed, Jul 16, 2014 at 01:01:22PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Currently driver writers need to use io{read,write}{8,16,32}_rep() when
> accessing FIFO registers portably. This is bad for two reasons: it is
> inconsistent with how other registers are accessed using
On 07/18/2014 01:20 PM, Andy Lutomirski wrote:
>>
>> The reason this is a concern is that: (x > x + n) and its variants is
>> often used to mean (x > INT_MAX - n) without the type knowledge, but
>> that is actually invalid standard C because signed types are not
>> guaranteed to wrap.
>
> Right,
On Fri, 18 Jul 2014, Steven Rostedt wrote:
> On Fri, 18 Jul 2014 01:18:55 -0400
> Nicolas Pitre wrote:
>
>
> > diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> > index be8e1bde07..e154d176cf 100644
> > --- a/arch/x86/kernel/smp.c
> > +++ b/arch/x86/kernel/smp.c
> > @@ -31,6 +31,12
Hi!
I'am trying to use the feature of loading early an intel microcode.
According to the documentation (early-microcode.txt) that should be possible.
I am currently using my own initrd, so I've created a second one, as the docs
specified and merged it with my own.
Galactica linux # file
On Fri, 18 Jul 2014, Steven Rostedt wrote:
> On Fri, 18 Jul 2014 01:18:53 -0400
> Nicolas Pitre wrote:
>
>
> > -#ifdef CONFIG_IRQ_WORK
> > -void arch_irq_work_raise(void)
> > -{
> > - if (is_smp())
> > - smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
> > -}
> >
Hi guys, please queue up the following changes for v3.17.
The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
On Qualcomm APQ8064 SOCs, SD card controller has an additional glue
called DML (Data Mover Local/Lite) to assist dma transfers.
This hardware needs to be setup before any dma transfer is requested.
DML itself is not a DMA engine, its just a gule between the SD card
controller and dma controller.
Thomas,
Here's all of the fixes I have queued up for v3.16. Nothing else is
allowed to break ;-)
This is an incremental pull request on the irqchip/urgent branch from
tags/irqchip-urgent-3.16 up to tags/irqchip-urgent-3.16-2.
Please pull.
thx,
Jason.
The following changes since commit
On 07/18/2014 10:37 PM, Nicholas Krause wrote:
> The comment for size of frame not being needed is incorrect , the
> function called needs this parameter.
Thanks for the patch Nicholas.
It has been queued up:
https://patchwork.kernel.org/patch/4587631/
and
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
tags/rdma-for-linus
InfiniBand/RDMA fixes for 3.16
- cxgb4 hardware driver regression fixes
- mlx5 hardware driver regression
Add a new devtest make target to enable developer testing. This
new target does full build (make all) and then runs selftests.
Signed-off-by: Shuah Khan
---
Makefile | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Makefile b/Makefile
index f3c543d..1ef3128 100644
--- a/Makefile
On Fri, Jul 18, 2014 at 06:24:15PM +0300, Andrey Utkin wrote:
> 2014-07-18 17:46 GMT+03:00 Benoit Taine :
> > On 18/07/2014 17:38, Andrey Utkin wrote:
> >> Is there script for automated checkpatch.pl && get_maintainers.pl &&
> >> git send-email for range of commits? I see none. Would it be welcome
On Fri, 2014-07-18 at 12:40 -0700, Gregory Fong wrote:
> The following would incorrectly pass checkpatch:
>
> void foo(void)
> {
> if (a) {
> something;
> somethingelse;
> } else {
> messed_up_indentation;
> }
The comment for size of frame not being needed is incorrect , the
function called needs this parameter.
Signed-off-by: Nicholas Krause
---
arch/parisc/kernel/signal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
index
Rob,
On 07/18/2014 03:31 PM, Rob Herring wrote:
On Fri, Jul 18, 2014 at 10:14 AM, Murali Karicheri wrote:
--- Cut ---
+
+Optional properties:-
+ phys: phandle to Generic Keystone SerDes phy for PCI
+ phy-names: name of the Generic Keystine SerDes phy for PCI
+ - If boot
On Fri, 18 Jul 2014 01:18:55 -0400
Nicolas Pitre wrote:
> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> index be8e1bde07..e154d176cf 100644
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -31,6 +31,12 @@
> #include
> #include
> #include
> +
> +#define
On Fri, Jul 18, 2014 at 12:46:29PM -0700, John Stultz wrote:
> On 07/18/2014 12:34 PM, Peter Zijlstra wrote:
> > On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
> >> Also, assuming we someday will merge the x86 sched_clock logic into
> >> the generic sched_clock code, we'll have to
On Fri, Jul 18, 2014 at 1:15 PM, H. Peter Anvin wrote:
> On 07/18/2014 01:08 PM, Andy Lutomirski wrote:
>>
>> i isn't an index in to the syms array at all. This code is completely
>> wrong. See the patch I sent in reply to Stephen's original email.
>>
>> But, to your earlier point, presumably
On 07/18/2014 03:50 PM, Arnd Bergmann wrote:
On Friday 18 July 2014 14:31:39 Rob Herring wrote:
+
+ Example:
+ pcie_msi_intc: msi-interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells =<1>;
+ interrupt-parent
On 18.07.2014 22:07, James Bottomley wrote:
On Fri, 2014-07-18 at 22:01 +0200, poma wrote:
On 18.07.2014 16:17, Christoph Hellwig wrote:
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
Slab warns, because the name of the cache being created contains spaces.
The "bad" cache
On Wed, Jul 16, 2014 at 8:40 PM, Nick Krause wrote:
> On Wed, Jul 16, 2014 at 3:12 AM, Steven Miao wrote:
>> Hi Nick,
>>
>> On Sun, Jul 13, 2014 at 6:18 AM, Nick Krause wrote:
>>> On Fri, Jul 11, 2014 at 12:18 PM, Nick Krause wrote:
Hey Steven,
I having been testing what builds are
On 07/18/2014 01:08 PM, Andy Lutomirski wrote:
>
> i isn't an index in to the syms array at all. This code is completely
> wrong. See the patch I sent in reply to Stephen's original email.
>
> But, to your earlier point, presumably this could warn:
>
> for (int i = 0; i < 10; i++)
> if
A 'line over 80 characters' issue fixed.
Signed-off-by: Sam Asadi
---
drivers/staging/comedi/drivers/adl_pci9118.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index
A 'quoted string split across lines' issue fixed, while a better use of
language applied to the comment.
Signed-off-by: Sam Asadi
---
drivers/staging/comedi/drivers/adl_pci9118.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Signed-off-by: Alexey Dobriyan
---
fs/proc/base.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -200,9 +200,16 @@ static int proc_root_link(struct dentry *dentry, struct
path *path)
return result;
}
-static int
On Thu, Jul 17, 2014 at 03:53:46PM -0700, Andrew Morton wrote:
> On Thu, 17 Jul 2014 00:32:47 +0300 Alexey Dobriyan
> wrote:
>
> > Convert /proc/$PID/cmdline to seq_file interface.
> >
> > XXX
>
> Unsure what XXX signifies.
>
> > This one must be buggy.
> >
> > seq_file buffer is
On Fri, 18 Jul 2014, Patrik Fimml wrote:
> On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > device from doing anything, which isn't what you want. You want to
> > ignore any activity the device may
On Fri, Jul 18, 2014 at 1:05 PM, H. Peter Anvin wrote:
> On 07/18/2014 12:57 PM, Andy Lutomirski wrote:
>>
>> This particular warning is IMO in a particularly dumb category: GCC
>> optimizes some code and then warns about a construct that wasn't there
>> in the original code. In this case, I
>From 0a4bd997ba9725565883c688d7dcee8264abf71c Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 18 Jul 2014 16:07:14 -0400
throtl_pd_init() is called under the queue lock but needs to allocate
the percpu stats area. This is currently handled by queueing it on a
list and scheduling a work
Hello,
So, I have another case where percpu allocation needs to be performed
from an atomic context (also on the IO path), so I wrote up a simple
percpu alloc cache which is filled asynchronously and replaced
blk-throttle's custom implementation with it.
I still think it's quite unlikely that we
On Fri, 2014-07-18 at 22:01 +0200, poma wrote:
> On 18.07.2014 16:17, Christoph Hellwig wrote:
> > On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
> >> Slab warns, because the name of the cache being created contains spaces.
> >> The "bad" cache is created by
On 07/18/2014 12:57 PM, Andy Lutomirski wrote:
>
> This particular warning is IMO in a particularly dumb category: GCC
> optimizes some code and then warns about a construct that wasn't there
> in the original code. In this case, I think it unrolled a loop and
> discovered that one iteration
On Fri, 18 Jul 2014 01:18:53 -0400
Nicolas Pitre wrote:
> -#ifdef CONFIG_IRQ_WORK
> -void arch_irq_work_raise(void)
> -{
> - if (is_smp())
> - smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
> -}
> +static const char *ipi_types[NR_IPI]
> +#ifdef CONFIG_TRACING
>
On 18.07.2014 16:20, Christoph Lameter wrote:
On Fri, 18 Jul 2014, poma wrote:
I guess someone working over the summertime. :)
Cache names should not contain blanks. I guess the
WARN_ON(strchr(name, ' ')); /* It confuses parsers */
was triggered?
I can only guess also. ;)
poma
On 18.07.2014 16:17, Christoph Hellwig wrote:
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by
On Fri, Jul 18, 2014 at 2:10 PM, Randy Dunlap wrote:
> On 07/18/2014 10:45 AM, Nick Krause wrote:
>> Hey Greg and others,
>> When I built the usb directory today to check a patch I am also
>> sending to. I seem to hitting
>> a few compiler errors and a lot of warnings. I am going to attach a
>>
This article,
http://www.phoronix.com/scan.php?page=article=intel_iris5100_winlin=4
shows that iris graphics are faster
on windows. I was wondering if this is correct and we need to improve them.
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, Jul 18, 2014 at 12:16 PM, H. Peter Anvin wrote:
> On 07/17/2014 10:00 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64
>> allmodconfig) produced these warnings:
>>
>> In file included from arch/x86/vdso/vdso2c.c:161:0:
>>
On Fri, Jul 18, 2014 at 08:26:36AM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> It's not quite clear that msi-controller is already checked
> by of_msi_chip_add. So, this patch add a note to clarify.
>
> Also, clean up redundant logic and unnecessary pr_info.
>
On Fri, Jul 18, 2014 at 3:09 PM, Alan Stern wrote:
> On Fri, 18 Jul 2014, Nicholas Krause wrote:
>
>> I am removing two fix mes in this file as after dicussing then it seems
>> there is no reason to check against Null for usb_device as it can never
>> be NULL and this is check is therefore not
On Fri, Jul 18, 2014 at 2:20 PM, Sam Ravnborg wrote:
> On Fri, Jul 18, 2014 at 01:06:41PM -0400, Nick Krause wrote:
>> On Fri, Jul 18, 2014 at 10:08 AM, Steven Rostedt wrote:
>> > On Thu, Jul 17, 2014 at 11:05:12PM -0400, Nick Krause wrote:
>> >> On Thu, Jul 17, 2014 at 1:38 PM, Nick Krause
On Friday 18 July 2014 14:31:39 Rob Herring wrote:
> > +
> > + Example:
> > + pcie_msi_intc: msi-interrupt-controller {
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + interrupt-parent = <>;
> > +
On 07/18/2014 12:34 PM, Peter Zijlstra wrote:
> On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
>> Also, assuming we someday will merge the x86 sched_clock logic into
>> the generic sched_clock code, we'll have to handle cases where they
>> aren't the same.
> I prefer that to not
On 07/16/14 20:59, Tomasz Figa wrote:
Hi Krzysztof,
On 14.07.2014 09:45, Krzysztof Kozlowski wrote:
Fix building of exynos defconfig with disabled PM_SLEEP:
CONFIG_PM_SLEEP=n
CONFIG_PM_SLEEP_SMP=n
CONFIG_SUSPEND=n
by moving functions for power up/down of CPU and cluster to platsmp.c
The build
On 07/16/14 09:56, Tomasz Figa wrote:
On 16.07.2014 02:53, Kukjin Kim wrote:
Kukjin Kim wrote:
On 07/05/14 02:48, Tomasz Figa wrote:
Move debug-macro.S from mach/include to include/debug where
all other common debug macros are.
Signed-off-by: Tomasz Figa
---
arch/arm/Kconfig.debug
The following would incorrectly pass checkpatch:
void foo(void)
{
if (a) {
something;
somethingelse;
} else {
messed_up_indentation;
}
}
Assume single-tab indentation of blocks to catch this.
Also add "else"
On 07/18/2014 09:14 AM, Alex Elder wrote:
> Two log record flags--LOG_CONT and LOG_NEWLINE--are mutually
> exclusive. That is, one or the other is always set, but they are
> never both set at the same time in a log record flags field. What
> follows is a great deal of explanation that aims to
On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
> Also, assuming we someday will merge the x86 sched_clock logic into
> the generic sched_clock code, we'll have to handle cases where they
> aren't the same.
I prefer that to not happen. I spend quite a bit of time and effort to
make
On Fri, Jul 18, 2014 at 10:14 AM, Murali Karicheri wrote:
> keystone PCIe controller is based on v3.65 version of the
> designware h/w. Main differences are
> 1. No ATU support
> 2. Legacy and MSI irq functions are implemented in
>application register space
>
This adds support for the touchscreen on Samsung s3c64xx.
The driver is completely untested but shows roughly how
it could be done, following the example of the at91 driver.
Open questions include:
- compared to the old plat-samsung/adc driver, there is
no support for prioritizing ts over
101 - 200 of 2038 matches
Mail list logo
