* Oleg Nesterov [2014-04-19 19:01:55]:
> Change uprobe_init_insn() to make insn_complete() == T, this makes
> other insn_get_*() calls unnecessary.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Srikar Dronamraju
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send
* Oleg Nesterov [2014-04-19 19:01:59]:
> Add the suitable ifdef's around good_insns_* arrays. We do not want
> to add the ugly ifdef's into their only user, uprobe_init_insn(), so
> the "#else" branch simply defines them as NULL. This doesn't generate
> the extra code, gcc is smart enough,
* Oleg Nesterov [2014-04-19 19:02:02]:
> is_64bit_mm() assumes that mm->context.ia32_compat means the 32-bit
> instruction set, this is not true if the task is TIF_X32.
>
> Change set_personality_ia32() to initialize mm->context.ia32_compat
> by TIF_X32 or TIF_IA32 instead of 1. This allows to
On 04/28/2014 09:23 PM, Oleg Nesterov wrote:
> On 04/28, Denys Vlasenko wrote:
>>
>> On 04/28/2014 07:34 PM, Oleg Nesterov wrote:
>>>
>>> It seems that you are right. But it would be really great if you also
>>> provide the test-case which proves the fix ;)
>>
>> Working on a testcase for this. So
On Tue, Apr 29, 2014 at 09:33:09AM +0200, Andreas Herrmann wrote:
> I am sure, it's because some server systems had MMIO ECS access not
> enabled in BIOS. I can't remember which systems were affected.
Ok, now AMD people: what's the story with IO ECS, can we assume that on
everything after F10h,
On Sun, Apr 27, 2014 at 01:06:54PM -0400, Oleg Drokin wrote:
> From: Dmitry Eremin
>
> Pointer 'mod' checked for NULL at line 160 may be dereferenced at line 208.
>
This seems to be a real bug, btw. For example, FSFILT_IOC_SETFLAGS
calls md_setattr() with a NULL mod in ll_iocontrol().
On Tue, 29 Apr 2014, Matt Fleming wrote:
> I would just replace the existing calls to early_ioremap() with
> efi_ioremap() and implement it like so (all in
> arch/x86/platform/efi/early_printk.c),
>
> static void *efi_ioremap(resource_size_t phys_addr, unsigned long size)
> {
> if
On 04/29/2014 01:11 AM, Rafael J. Wysocki wrote:
On Monday, April 28, 2014 01:07:31 PM Daniel Lezcano wrote:
On 04/28/2014 12:28 PM, Peter Zijlstra wrote:
On Mon, Apr 28, 2014 at 12:09:20PM +0200, Daniel Lezcano wrote:
I agree a numerical value is not flexible. But it sounds weird to put a
On Fri, Apr 25, 2014 at 05:09:04PM +0100, Leif Lindholm wrote:
> This set adds support for UEFI to the arm64 port - a stub loader, as
> well as runtime services support for efivars.
>
> It depends on some core EFI patches currently in linux-next.
The patches look fine to me, they've been through
On Tue, Apr 29, 2014 at 07:44:06PM +1000, NeilBrown wrote:
>
>
> It is currently not possible for various wait_on_bit functions to
> implement a timeout.
> While the "action" function that is called to do the waiting could
> certainly use schedule_timeout(), there is no way to carry forward the
On Tue, Apr 08, 2014 at 04:39:25PM +0100, Borislav Petkov wrote:
> On Fri, Apr 04, 2014 at 12:57:28PM -0700, Stephen Boyd wrote:
> > The Krait L1/L2 error reporting hardware is made up a per-CPU
> > interrupt for the L1 cache and a SPI interrupt for the L2.
> >
> > Cc: Lorenzo Pieralisi
> > Cc:
On Sun, Apr 27, 2014 at 01:06:58PM -0400, Oleg Drokin wrote:
> int
> +cfs_cpt_table_print(struct cfs_cpt_table *cptab, char *buf, int len)
> +{
> + int rc = 0;
GCC has a feature where it warns about unitialized variables. If you do
bogus it disables this safety feature. Also the bogus
On Tuesday 29 April 2014 12:36 PM, Ingo Molnar wrote:
>
> * Madhavan Srinivasan wrote:
>
>> Performance data for different FAULT_AROUND_ORDER values from 4 socket
>> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
>> is used to get the stddev values. Test ran in v3.14
This is a small supplement for commit e7428e95a06fb516fac1308bd0e176e27c0b9287
("virtio-net: put virtio-net header inline with data"). TCP packages have
enough room to put virtio-net header in, but UDP packages do not. By
setting dev->needed_headroom for virtio-net device, UDP packages could have
On Fri, 25 Apr, at 01:40:10PM, Borislav Petkov wrote:
>
> Well, the more I think about it, the more I'm persuaded that
> you actually do *really* need that WARN_ON_ONCE check there to
> make sure you're not fiddling with the FPU while in an interrupt
> context and in an unsafe way (see
Let's define fentry_hook depending on CC_USING_FENTRY and use that
macro all over. This saves some #ifdef's here and there.
We do not use the old macro function_hook since it is too generic.
Hence we introduce fentry_hook which corresponds to what it is.
Signed-off-by: Jiri Slaby
Cc: Thomas
On Sun, Apr 27, 2014 at 02:23:24PM +0100, Rafael J. Wysocki wrote:
> Still, I have a rather fundamental problem with the notion that performance
> and energy efficiency are essentially at odds with each other, because quite
> often they aren't. What is good for performance is often good for
29.04.2014, 11:42, "Greg Thelen" :
> On Mon, Apr 28 2014, Roman Gushchin wrote:
>
>> 28.04.2014, 16:27, "Michal Hocko" :
>>> The series is based on top of the current mmotm tree. Once the series
>>> gets accepted I will post a patch which will mark the soft limit as
>>> deprecated with a note
On Thu, Apr 24, 2014 at 10:27:33PM +0900, Namhyung Kim wrote:
SNIP
> Reported-by: Stephane Eranian
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/builtin-record.c | 121
> ++-
> 1 file changed, 51 insertions(+), 70 deletions(-)
>
> diff --git
On Sun, Apr 27, 2014 at 01:07:05PM -0400, Oleg Drokin wrote:
> From: "John L. Hammond"
>
> In llite remove unused declarations, parameters, types, and unused,
> get-only, or set-only structure members. Add static and const
> qualifiers to declarations where possible.
>
> Signed-off-by: John L.
On 29 April 2014 11:45, Arnd Bergmann wrote:
> [hijacking the thread since it has the right Cc list already, sorry]
>
> I stumbled over this doing randconfig builds on linux-next
>
> 8<--
>
> From c11f54f1e5ea0557e076867ca31c90bcb20e3e0c Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann
>
==
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT 2014
18-19 AUGUST
CHICAGO, IL, USA
On Fri, Apr 18, 2014 at 11:19:53PM +0100, Rob Herring wrote:
> Rob Herring (7):
> x86: move FIX_EARLYCON_MEM kconfig into x86
> tty/serial: add generic serial earlycon
> tty/serial: convert 8250 to generic earlycon
> tty/serial: pl011: add generic earlycon support
> tty/serial: add
Hi,
Why is this patch an RFC? If it is ready for upstreaming please drop
the RFC prefix when you post the next version.
On 04/27/2014 10:56 PM, Patrik Jakobsson wrote:
> This driver takes control over the LP8550 backlight driver chip found
> in the mid 2013 and newer MacBook Air (6,1 and 6,2).
On Tue, 29 Apr 2014 10:47:07 +0200
"Michael Kerrisk (man-pages)" wrote:
> [CC+= linux-nfs@]
>
> On 04/29/2014 10:38 AM, Michael Kerrisk (man-pages) wrote:
> > Hi Jeff,
> >
> > I've been looking a bit at the fcntl() documentation of traditional
> > (F_SETLK) record locking, and a question just
Thomas, does this make sense now, with the new description?
On Fri, Apr 18, 2014 at 05:23:11PM +0200, Jiri Bohac wrote:
> On architectures with sizeof(int) < sizeof (long), the
> computation of mask inside apply_slack() can be undefined if the
> computed bit is > 32.
>
> E.g. with: expires =
On Thu, Apr 24, 2014 at 10:27:33PM +0900, Namhyung Kim wrote:
SNIP
> - rec->bytes_written / 24);
> +out_child:
> + if (forks) {
> + int exit_status;
>
> - return 0;
> + if (!child_finished)
> + kill(rec->evlist->workload.pid,
Hi Jeff,
On Tue, Apr 29, 2014 at 1:11 PM, Jeff Layton wrote:
> On Tue, 29 Apr 2014 10:47:07 +0200
> "Michael Kerrisk (man-pages)" wrote:
>
>> [CC+= linux-nfs@]
>>
>> On 04/29/2014 10:38 AM, Michael Kerrisk (man-pages) wrote:
>> > Hi Jeff,
>> >
>> > I've been looking a bit at the fcntl()
From: Arnd Bergmann
Building ARM randconfig got into a situation where CONFIG_INPUT
is turned off and SND_SOC_ALL_CODECS is turned on, which failed
for two codecs trying to use the input subsystem. Some other
drivers also select one of these codecs and consequently need an
explicit dependency
From: Arnd Bergmann
The symbol "nuc900_ac97_data" is used by the nuc900_pcm driver,
which may be a loadable module, so we should export it.
If one tries to build SND_SOC_NUC900 without SND_SOC_NUC900_AC97,
the kernel fails to link because of the reference to nuc900_ac97_data.
Signed-off-by:
This patchset series addresses various bugs found and fixed by Arnd Bergmann
whilst doing randconfig builds.
My involvement has been to review, add/check the maintainers are correct
and submit upstream to try and reduce the backlog.
Best Regards,
Kaixu Xia
Arnd Bergmann (11):
ASoC: CS42L51
From: Arnd Bergmann
The missing dependency can lead to build errors, so
make it explicit in Kconfig.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Philipp Zabel
Cc: Paul Parsons
Cc: Russell King
Cc: Eric Miao
Cc: Haojian Zhuang
Cc:
From: Arnd Bergmann
The codec requires I2C to be enabled, so any other option
that selects it should also depend on I2C.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Peter Ujfalusi
Cc: Jarkko Nikula
Cc: alsa-de...@alsa-project.org
Cc:
From: Arnd Bergmann
The WM8978 driver needs I2C to be enabled, so the
SND_SIU_MIGOR option also requires this.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: alsa-de...@alsa-project.org
Cc: linux-arm-ker...@lists.infradead.org
---
On Tue, Apr 29, 2014 at 12:56:54PM +0200, Jiri Olsa wrote:
>
> perf_counter tools: Propagate signals properly
> commit f7b7c26e01e51fe46097e11f179dc71ce7950084
> Author: Peter Zijlstra
> Date: Wed Jun 10 15:55:59 2009 +0200
>
> but I dont think we need to do that
But but but, then
From: Arnd Bergmann
The cx20442 codec driver used here requires the TTY layer to
be enabled, or we get a link error:
sound/built-in.o: In function `cx20442_codec_remove':
cx20442.c:398: undefined reference to `tty_hangup'
sound/built-in.o: In function `ams_delta_remove':
ams-delta.c:613:
From: Arnd Bergmann
SND_S3C_DMA_LEGACY can only be set on S3C24xx, which does not
(yet) support the dmaengine framework, so samsung_dma_get_ops()
fails to link if S3C24XX_DMA is disabled:
sound/built-in.o: In function `dma_hw_params':
:(.text+0x7f310): undefined reference to `s3c_dma_get_ops'
From: Arnd Bergmann
The WM8904 codec driver needs I2C to be enabled, so the
SND_ATMEL_SOC_WM8904 option also requires this.
Found using randconfig build testing.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: alsa-de...@alsa-project.org
---
From: Arnd Bergmann
This codec requires I2C to be enabled, so any other option
that selects it should also depend on I2C.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Sangbeom Kim
Cc: alsa-de...@alsa-project.org
From: Arnd Bergmann
As we are moving the mmp platform towards multiplatform support,
we have to stop including platform header files.
This changes the pxa-ssp sound driver file to no longer depend
on mach/hardware.h and mach/dma.h. The code using the definitions
from those headers is actually
On 04/24/2014 07:04 PM, John Stultz wrote:
> Continuing the sporadic work on improving the timekeeping
> frequency steering logic when NOHZ is enabled, I've made a number
> of changes to my re-implementation of Miroslav's patch (most
> recently posted here: https://lkml.org/lkml/2014/2/12/401 ),
From: Arnd Bergmann
The UDA1380 driver needs I2C to be enabled, so
SND_SOC_SAMSUNG_H1940_UDA1380 and
SND_SOC_SAMSUNG_RX1950_UDA1380 also
require this.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Sangbeom Kim
On Fri, 25 Apr, at 05:09:07PM, Leif Lindholm wrote:
> From: Mark Salter
>
> ARM and ARM64 architectures use the device tree to pass UEFI parameters
> from stub to kernel. These parameters are things known to the stub but
> not discoverable by the kernel after the stub calls ExitBootSerives().
>
On Fri, 25 Apr, at 05:09:09PM, Leif Lindholm wrote:
> From: Roy Franz
>
> Both ARM and ARM64 stubs will update the device tree that they pass to
> the kernel. In both cases they primarily need to add the same UEFI
> related information, so the function can be shared. Create a new FDT
> related
From: Arnd Bergmann
This codec requires I2C to be enabled, so any other option
that selects it should also depend on I2C.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: alsa-de...@alsa-project.org
---
sound/soc/davinci/Kconfig | 10 +-
On Wed, Apr 23, 2014 at 2:41 PM, James Hogan wrote:
> It appears Miklos Szeredi beat me to it with patch 1 (adding renameat2
> syscall to asm-generic unistd.h), and will be submitting it to Linus
> at some point as part of his renameat2 series.
> Miklos: Do you think it makes sense for you to
From: Arnd Bergmann
dma_addr_t may be 64 bit wide, which causes a build failure
when doing a division on it. Here it is safe to cast to an
u32 type, which avoids the problem.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Ben Dooks
Cc: Kukjin Kim
On 29.04.14 09:33:09, Andreas Herrmann wrote:
> On Mon, Apr 28, 2014 at 11:40:36PM +0200, Borislav Petkov wrote:
> > On Mon, Apr 28, 2014 at 02:50:29PM -0600, Bjorn Helgaas wrote:
> > > This I/O ECS thing seems likely to cause future problems. My
> > > understanding (based on sec 2.8 of [1]) is
From: Arnd Bergmann
This adds a missing dependency for SND_SOC_SMDK_WM8580_PCM to
require REGMAP_I2C to be enabled, avoiding possible build
erorrs.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Sangbeom Kim
Cc:
From: Arnd Bergmann
The missing dependency can lead to build errors, so
make it explicit in Kconfig.
Signed-off-by: Arnd Bergmann
Signed-off-by: Xia Kaixu
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Sangbeom Kim
Cc: alsa-de...@alsa-project.org
Cc:
On Fri, 25 Apr, at 05:09:12PM, Leif Lindholm wrote:
> From: Mark Salter
>
> This patch adds PE/COFF header fields to the start of the kernel
> Image so that it appears as an EFI application to UEFI firmware.
> An EFI stub is included to allow direct booting of the kernel
> Image.
>
>
On Fri, 25 Apr, at 05:09:14PM, Leif Lindholm wrote:
> From: Ard Biesheuvel
>
> Loading unauthenticated FDT blobs directly from storage is a security hazard,
> so this should only be allowed when running with UEFI Secure Boot disabled.
>
> Signed-off-by: Ard Biesheuvel
> Signed-off-by: Leif
> The rest has been queued up for 3.16.
I also aim for 3.16, yet it may take 1 or 2 weeks more until I'll be
able to review the I2C part of those patches.
signature.asc
Description: Digital signature
On Tue, Apr 29, 2014 at 01:19:39PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 29, 2014 at 12:56:54PM +0200, Jiri Olsa wrote:
> >
> > perf_counter tools: Propagate signals properly
> > commit f7b7c26e01e51fe46097e11f179dc71ce7950084
> > Author: Peter Zijlstra
> > Date: Wed Jun 10
On Tue, 29 Apr 2014 11:53:40 +0200
"Michael Kerrisk (man-pages)" wrote:
> On 04/29/2014 11:24 AM, NeilBrown wrote:
> > On Tue, 29 Apr 2014 11:07:16 +0200 "Michael Kerrisk (man-pages)"
> > wrote:
> >
> >> On 04/27/2014 11:28 PM, NeilBrown wrote:
> >>> On Sun, 27 Apr 2014 13:11:33 +0200 "Michael
On Sat, Apr 26, 2014 at 10:03 AM, Jens Axboe wrote:
> On 2014-04-25 18:01, Ming Lei wrote:
>>
>> Hi Jens,
>>
>> On Sat, Apr 26, 2014 at 5:23 AM, Jens Axboe wrote:
>>>
>>> On 04/25/2014 03:10 AM, Ming Lei wrote:
>>>
>>> Sorry, I did run it the other day. It has little to no effect here, but
>>>
On Tue, Apr 29, 2014 at 01:19:39PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 29, 2014 at 12:56:54PM +0200, Jiri Olsa wrote:
> >
> > perf_counter tools: Propagate signals properly
> > commit f7b7c26e01e51fe46097e11f179dc71ce7950084
> > Author: Peter Zijlstra
> > Date: Wed Jun 10
On Tue, Apr 29, 2014 at 01:33:04PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 29, 2014 at 01:19:39PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 29, 2014 at 12:56:54PM +0200, Jiri Olsa wrote:
> > >
> > > perf_counter tools: Propagate signals properly
> > > commit
Hi Jeff,
Something which came up on the last Ganesha conn call is that we have
a pretty strong need for some ability to wait on a set of locks, and perhaps
receive events. Frank Filz believed that you had made a proposal which
would cover this. Can you elaborate on that?
Thanks,
Matt
-
Estimado E-mail del usuario;
Se ha superado 23.432 Repositorio para el conjunto buzón
Servicios Web / Administrador, y habrás problemas al enviar y
recepción de correo, mientras que volver a verificar. Debe actualizar
haciendo clic en enlace de abajo y complete la información para verificar su
Hallo all,
attached to this mail you will find a couple of patches fixing one bug I
have with kernel 3.10 (all subreleases).
These patches have been developed originally by Jan Kara (j...@suse.cz,
I guess you
know him better than I do) for kernel 3.13 and can be found here:
(Pulling in Peter and Stephen)
On Tue, 29 Apr, at 11:28:17AM, Catalin Marinas wrote:
>
> The patches look fine to me, they've been through several rounds of
> review already. How do we propose these get merged as the series
> contains both generic and arm64 patches? And there are dependencies
>
On Tue, 29 Apr 2014 07:40:08 -0400 (EDT)
"Matt W. Benjamin" wrote:
> Hi Jeff,
>
> Something which came up on the last Ganesha conn call is that we have
> a pretty strong need for some ability to wait on a set of locks, and perhaps
> receive events. Frank Filz believed that you had made a
This patchset series addresses various bugs found and fixed by Arnd Bergmann
whilst doing randconfig builds.
My involvement has been to review, add/check the maintainers are correct
and submit upstream to try and reduce the backlog.
Best Regards,
Kaixu Xia
Arnd Bergmann (11):
ASoC: CS42L51
On Tue, Apr 29, 2014 at 01:42:13PM +0200, Alexander Naumann wrote:
> Hallo all,
>
> attached to this mail you will find a couple of patches fixing one bug I
> have with kernel 3.10 (all subreleases).
> These patches have been developed originally by Jan Kara (j...@suse.cz,
> I guess you
> know
On 04/28/2014 05:15 PM, Paul E. McKenney wrote:
> On Mon, Apr 28, 2014 at 01:32:38PM -0700, Randy Dunlap wrote:
>> On 04/28/14 13:06, Paul E. McKenney wrote:
>>> Please see below for a patch against next-20140428 that makes this build
>>> for me. This is derived from Rik's patch, my patch, and
On Thu, Apr 24, 2014 at 10:27:33PM +0900, Namhyung Kim wrote:
> static void record__sig_exit(int exit_status __maybe_unused, void *arg)
> {
> - struct record *rec = arg;
> - int status;
> -
> - if (rec->evlist->workload.pid > 0) {
> - if (!child_finished)
> -
On Mon 28-04-14 17:19:26, Oleg Nesterov wrote:
> Andrew,
>
> You applied the last (4th) memcg-kill-config_mm_owner.patch, but other
> patches in this thread were ignored. Hopefully thi is because I sent
> them chaotically.
All of them are queued AFAICS. I do not know where those emails are
On Tue, Apr 29, 2014 at 10:52:04AM +1000, Dave Chinner wrote:
> > #ifdef CONFIG_FSNOTIFY
> > @@ -240,10 +246,19 @@ void __destroy_inode(struct inode *inode)
> > }
> >
> > #ifdef CONFIG_FS_POSIX_ACL
> > - if (inode->i_acl && inode->i_acl != ACL_NOT_CACHED)
> > -
On 04/29/2014 01:34 PM, Jeff Layton wrote:
> On Tue, 29 Apr 2014 11:53:40 +0200
> "Michael Kerrisk (man-pages)" wrote:
>
>> On 04/29/2014 11:24 AM, NeilBrown wrote:
>>> On Tue, 29 Apr 2014 11:07:16 +0200 "Michael Kerrisk (man-pages)"
>>> wrote:
>>>
On 04/27/2014 11:28 PM, NeilBrown wrote:
Fix format string mismatch in gbefb_show_memsize().
Signed-off-by: Masanari Iida
---
drivers/video/fbdev/gbefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 3ec65a8..4aa56ba 100644
---
Fix format string mismatch in contrast_show().
Signed-off-by: Masanari Iida
---
drivers/video/fbdev/wm8505fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
index 537d199..d2fafbb 100644
---
On 04/29/2014 01:52 PM, Michael Neuling wrote:
> That's not what that patch does. It shouldn't make any user visible changes
> to DSCR or PPR.
It may not when it runs uninterrupted but after the tracee process has stopped,
thread.dscr reflects the default DSCR value as mentioned before. This can
Hi,
just a basic review to keep things rolling...
> On the original Samsung ARM Chromebook these devices were on an I2C
> bus that was shared between the AP and the EC and arbitrated using
> some extranal GPIOs (see i2c-arb-gpio-challenge).
>
> The original arbitration scheme worked well enough
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.
The issue has been observed on embedded systems with
On 04/28, Davidlohr Bueso wrote:
>
> @@ -29,6 +30,7 @@ void use_mm(struct mm_struct *mm)
> tsk->active_mm = mm;
> }
> tsk->mm = mm;
> + vmacache_flush(tsk);
But this can't help, we need to do this in unuse_mm(). And we can race
with vmacache_flush_all() which
On Tuesday 29 April 2014 13:05:15 Ulf Hansson wrote:
> On 29 April 2014 11:45, Arnd Bergmann wrote:
> > drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
> > :(.text+0x806480): undefined reference to `led_classdev_unregister'
> > drivers/built-in.o: In function
On 04/29, Srivatsa S. Bhat wrote:
>
> I guess I'll hold off on testing this fix until I get to reproduce
> the bug more reliably..
perhaps the patch below can help a bit?
---
Subject: [PATCH] vmacache: change
Hi,
checkpatch complains about the spaces before the close parenthesis in
trace events:
ERROR: space prohibited before that close parenthesis ')'
#94: FILE: include/trace/events/thermal.h:14:
+ __field(unsigned int, freq )
However, in that directory, that's actually the
On Tue 29-04-14 14:50:18, Roman Gushchin wrote:
> 29.04.2014, 11:42, "Greg Thelen" :
> > On Mon, Apr 28 2014, Roman Gushchin wrote:
> >
> >> 28.04.2014, 16:27, "Michal Hocko" :
> >>> The series is based on top of the current mmotm tree. Once the series
> >>> gets accepted I will post a patch
Thomas,
Here's a small round of fixes that we need in a stable topic branch as a
part of a larger fix to the mvebu pcie/mbus driver. These have been in
-next for a week or so.
Please pull.
thx,
Jason.
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:
Linux
On Mon, 28 Apr 2014 13:02:28 -0500, Rob Herring wrote:
> On Mon, Apr 28, 2014 at 12:57 PM, Pawel Moll wrote:
> > In "Device Tree powered" systems, platform devices are usually
> > massively populated with of_platform_populate() call, executed
> > at some level of initcalls, either by generic
On Tue, 29 Apr 2014 12:32:17 +0200 Peter Zijlstra
wrote:
> On Tue, Apr 29, 2014 at 07:44:06PM +1000, NeilBrown wrote:
> >
> >
> > It is currently not possible for various wait_on_bit functions to
> > implement a timeout.
> > While the "action" function that is called to do the waiting could
>
BP_PROC_SUPPORT was never defined so removing all the #ifdef'd code
including the bp_proc_create() function.
Signed-off-by: Jan Moskyto Matejka
---
drivers/staging/silicom/bpctl_mod.c | 39 -
1 file changed, 39 deletions(-)
diff --git
My apologies for those receiving this post a 2nd time. The original
post never made it the mailing lists ...
On Fri, 2014-04-25 at 15:25 -0700, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
> >
> >> ssize_t
On Tue, 29 Apr 2014 02:45:22 +
"R, Durgadoss" wrote:
> Hi Jacob,
>
> > -Original Message-
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Monday, April 28, 2014 7:35 PM
> > To: Linux PM; Wysocki, Rafael J; LKML
> > Cc: David E. Box; Alan Cox; R, Durgadoss;
Hi,
so while debugging some hard-to-explain hangs in the past, we have been
going around in circles around the NMI nesting disaster, and I tend to
believe that Steven's fixup (for most part introduced in 3f3c8b8c ("x86:
Add workaround to NMI iret woes")) makes the race *much* smaller, but it
Some cpufreq drivers were redundantly invoking the _begin() and _end()
APIs around frequency transitions, and this double invocation (one from
the cpufreq core and the other from the cpufreq driver) used to result
in a self-deadlock, leading to system hangs during boot. (The _begin()
API makes
Hi Peter,
On 04/28/2014 10:18 AM, Peter Zijlstra wrote:
> Hi Michael,
>
> find below an updated manpage, I did not apply the comments on parts
> that are identical to SCHED_SETSCHEDULER(2) in order to keep these texts
> in alignment. I feel that if we change one we should also change the
>
On Tue, Apr 29, 2014 at 05:13:21PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/kernel/process_64.c: In function 'arch_trigger_all_cpu_backtrace':
>
On 04/29/2014 06:22 PM, Oleg Nesterov wrote:
> On 04/29, Srivatsa S. Bhat wrote:
>>
>> I guess I'll hold off on testing this fix until I get to reproduce
>> the bug more reliably..
>
> perhaps the patch below can help a bit?
>
>
>
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> v2: Removed the coverage of ASYNC_NOTIFICATION drivers, in order to avoid
> false-positives.
I am confused - on top of what patches should I test it?
>
> drivers/cpufreq/cpufreq.c |7 +++
> include/linux/cpufreq.h |1 +
> 2 files
On Tue, Apr 29, 2014 at 1:10 PM, Hans de Goede wrote:
>
> Hi,
>
> Why is this patch an RFC? If it is ready for upstreaming please drop
> the RFC prefix when you post the next version.
I'll do that
> On 04/27/2014 10:56 PM, Patrik Jakobsson wrote:
> > This driver takes control over the LP8550
On Tue, Apr 29, 2014 at 01:35:09PM +0100, Grant Likely wrote:
> When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
> when all modules loaded but some driver still stuck in the deferred list
> and there is a need for external event to kick the deferred queue to probe
>
On 2014-04-29 09:34, Chase Southwood wrote:
This board always has 32 digital inputs. Remove the test when
initializing the subdevice.
Also, since this board is the only one supported by this driver,
remove the boardinfo about the digital inputs and just use the
data directly in the subdevice
Hi Thomas,
* Lorenzo Pieralizi fixed an issue with the arch_arm_timer where the
C3STOP flag for all the arch can cause some trouble by setting the flag
only if the power domain is not always on
* Alexander Shiyan fixed a compilation by changing the init function
to the right prototype
Toshiba Satellite M840 laptop has a complete different keymap although
it's bound with the same ACPI ID "TOS1900". This patch provides an
alternative keymap specific to this machine by identifying via DMI
matching. The keymap table doesn't fill all entries that were used
before since some keys
From: Lorenzo Pieralisi
ARM arch timers are tightly coupled with the CPU logic and lose context
on platform implementing HW power management when cores are powered
down at run-time. Marking the arch timers as C3STOP regardless of power
management capabilities causes issues on platforms with no
On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman wrote:
> Geert Uytterhoeven writes:
>
> > When adding a device from DT, check if its clocks are suitable for Runtime
> > PM, and register them with the PM core.
> > If Runtime PM is disabled, just enable the clock.
> >
> > This allows the PM core
On Mon, Apr 28, 2014 at 6:53 PM, Alex Williamson
wrote:
> On Mon, 2014-04-28 at 17:52 +0200, Antonios Motakis wrote:
>> The ARM SMMU driver expects the IOMMU_EXEC flag, otherwise it will
>> set the page tables for a device as XN (execute never). This affects
>> devices such as the ARM PL330 DMA
901 - 1000 of 1468 matches
Mail list logo