Commit-ID: de256a4e6b9096070a5305950c7d693395150680
Gitweb: http://git.kernel.org/tip/de256a4e6b9096070a5305950c7d693395150680
Author: Stephane Eranian
AuthorDate: Mon, 20 Jan 2014 16:15:13 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 20 Jan 2014 16:19:09 -0300
perf evsel
Commit-ID: 8a398897ff21f73cb8b15a19514660f032926882
Gitweb: http://git.kernel.org/tip/8a398897ff21f73cb8b15a19514660f032926882
Author: Stephane Eranian
AuthorDate: Fri, 17 Jan 2014 16:34:05 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 20 Jan 2014 16:19:08 -0300
perf stat:
On Thu, Jan 23, 2014 at 3:05 PM, Curt Brune wrote:
> On Thu Jan 23 07:44, Laszlo Papp wrote:
>> On Wed, Jan 22, 2014 at 5:23 PM, Curt Brune wrote:
>> > During device instantiation have the at24 driver add the new device to
>> > the eeprom_dev hardware class. The functionality is enabled by
>> >
On 01/23/2014 05:07 AM, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 04:33:55PM -0500, Waiman Long wrote:
+/**
+ * queue_read_unlock - release read lock of a queue rwlock
+ * @lock : Pointer to queue rwlock structure
+ */
+static inline void queue_read_unlock(struct qrwlock *lock)
+{
+ /*
* David Herrmann wrote:
> >> +#ifdef CONFIG_X86_SYSFB
> >> +# include
> >> +#endif
> >
> > I guess a single space is sufficient?
> >
> > Better yet, I'd include sysfb.h unconditionally:
>
> Unconditionally won't work as only x86 has this header. [...]
Well, in non-x86 code an #ifdef x86 look
Commit-ID: a761a2d8a7175b7b4e8525e0672e1a8d3c051001
Gitweb: http://git.kernel.org/tip/a761a2d8a7175b7b4e8525e0672e1a8d3c051001
Author: Alan Cox
AuthorDate: Mon, 20 Jan 2014 19:10:11 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 20 Jan 2014 16:19:08 -0300
perf tools: Ensure
On Thu, Jan 23, 2014 at 9:12 AM, Waiman Long wrote:
>
> I thought that all atomic RMW instructions are memory barrier.
On x86 they are. Not necessarily elsewhere.
> If they are not, what kind of barrier should be added?
smp_mb__before_atomic_xyz() and smp_mb__after_atomic_xyz() will do it,
and
Sep 17 00:00:00 2001
From: Vladimir Murzin
Date: Thu, 23 Jan 2014 14:54:20 +0400
Subject: [PATCH] Revert "mm/vmalloc: interchage the implementation of
vmalloc_to_{pfn,page}"
This reverts commit ece86e222db48d04bda218a2be70e384518bb08c.
Despite being claimed that patch doesn't introduce any func
Stephen Boyd writes:
> These patches add the clock controller nodes, enable the clock drivers
> on MSM based platforms, and hook it up enough to get the serial console
> working. This is based on the merge of Mike's clk-next branch with
> linux-next-20140116. The changes need the clk-next branch
Hi,
No need to quote the whole message if you reply only to a bit of it.
> > module_init(at24_init);
> >
> > static void __exit at24_exit(void)
> > {
> > i2c_del_driver(&at24_driver);
> > }
> > module_exit(at24_exit);
>
> Couldn't you use module_i2c_driver() instead of this?
He did
On Thu, Jan 23, 2014 at 1:19 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> Include kASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>
>> Signed-off-by: Eugene Surovegin
>> Signed-off-by: Kees Cook
>
> The signoff sequence is weird. If this came from Eugene then the patch
> is
From: Eugene Surovegin
Include kASLR offset in VMCOREINFO ELF notes to assist in debugging.
Signed-off-by: Eugene Surovegin
Signed-off-by: Kees Cook
---
v2:
- make sure "From:" got sent correctly
---
arch/x86/kernel/machine_kexec_64.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/
Hi Levente,
On Thu, Jan 23, 2014 at 3:00 AM, Levente Kurusa wrote:
> Hello,
>
> 2014/1/22 Srikanth Thokala :
>> This is the driver for the AXI Video Direct Memory Access (AXI
>> VDMA) core, which is a soft Xilinx IP core that provides high-
>> bandwidth direct memory access between memory and AXI
Ping?
On Tue, Jan 7, 2014 at 9:03 PM, Erik Faye-Lund wrote:
> When patching gathers, we don't need to check against
> gathers with lower indices than the current one, as
> they are guaranteed to already have been handled.
>
> Signed-off-by: Erik Faye-Lund
> ---
>
> Here's a trivial optimization
On Thu, Jan 23, 2014 at 09:15:38AM -0800, Linus Torvalds wrote:
> On Thu, Jan 23, 2014 at 9:12 AM, Waiman Long wrote:
> >
> > I thought that all atomic RMW instructions are memory barrier.
>
> On x86 they are. Not necessarily elsewhere.
>
> > If they are not, what kind of barrier should be added
On Thu, Jan 23, 2014 at 04:53:50PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 23, 2014 at 12:04:44PM +0100, Sascha Hauer wrote:
> > On Thu, Jan 23, 2014 at 11:56:32AM +0100, Lothar Waßmann wrote:
> > > Hi,
> > >
> > > Sascha Hauer wrote:
> > > > of_pwm_n_cells for the of_xlate handler is
On Thu, Jan 23, 2014 at 5:19 AM, Mark Brown wrote:
>
> spi: Updates for v3.14
gmail hates you. I just found four of your emails in my spam-box.
I don't know why, since it's not the (somewhat) common issue with bad
or missing SPF information. The only thing I can imagine is that gmail
thinks you'
On 23/01/14 18:41, Mark Rutland wrote:
>>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>>> > > index 93cddeb..2da5617 100644
>>> > > --- a/drivers/crypto/s5p-sss.c
>>> > > +++ b/drivers/crypto/s5p-sss.c
>>> > > @@ -22,6 +22,7 @@
>>> > > #include
>>> > > #include
>>> > > #i
On Mon, Jan 20, 2014 at 3:23 PM, Rafael J. Wysocki wrote:
>
> Please pull from the git repository at
gmail still hates you rjwysocki.net address, even if it now says "spf pass".
So it's something else that makes gmail hate you. Spammy ISP?
Linus
--
To unsubscribe from this li
On 01/23/2014 12:15 PM, Linus Torvalds wrote:
On Thu, Jan 23, 2014 at 9:12 AM, Waiman Long wrote:
I thought that all atomic RMW instructions are memory barrier.
On x86 they are. Not necessarily elsewhere.
If they are not, what kind of barrier should be added?
smp_mb__before_atomic_xyz() and
On Thu, Jan 23, 2014 at 10:28:08AM +, Sylwester Nawrocki wrote:
> Hi,
>
> (Adding missing devicetre ML list at CC.)
>
> On 15/01/14 10:14, Naveen Krishna Chatradhi wrote:
> > This patch adds device tree support to the s5p-sss.c crypto driver.
> >
> > Also, Documentation under devicetree/bind
On Thu, Jan 23, 2014 at 5:25 PM, Wolfram Sang wrote:
> Hi,
>
> No need to quote the whole message if you reply only to a bit of it.
>
>> > module_init(at24_init);
>> >
>> > static void __exit at24_exit(void)
>> > {
>> > i2c_del_driver(&at24_driver);
>> > }
>> > module_exit(at24_exit);
Hi Linus,
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:
Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)
are available in the git repository at:
git://github.com/awilliam/linux-vfio.git tags/vfio-v3.14-rc1
for you to fetch changes up to 3be3a074cf5ba641529d8fdae0e0
On Fri, Jan 17, 2014 at 12:25:05PM +, Hanjun Guo wrote:
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * as from 2.5, kernels no longer have an init_tasks structure
> @@ -280,7 +281,7 @@ stati
On Thu, Jan 23, 2014 at 9:47 AM, Waiman Long wrote:
>
> Thank for the info. I am less familiar with that kind of issues on other
> architecture. I will add a smp_mb__after_atomic_dec() & send out a new
> patch.
SInce it's the unlock path,. you need to use the "mb__*before*"
versions, since presum
Hi Hanjun,
On 17/01/14 12:25, Hanjun Guo wrote:
> Implement core functions for parsing MADT table to get the information
> about GIC cpu interface and GIC distributor to prepare for SMP and GIC
> initialization.
>
> Signed-off-by: Hanjun Guo
> ---
> arch/arm64/include/asm/acpi.h |3 +
> dri
Signed-off-by: Nishanth Menon
---
Testing code and relevant dts changes(pending 3.14-rc1 tag):
https://github.com/nmenon/linux-2.6-playground/commits/abb-rev-v3.14-rc1-vnext-20140123
changes in v4 (since v3):
- minor documentation fixes
- logic fix of v3 to picking up setup and co
On Thu, Jan 23, 2014 at 05:47:25PM +, Sylwester Nawrocki wrote:
> On 23/01/14 18:41, Mark Rutland wrote:
> >>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
> >>> > > index 93cddeb..2da5617 100644
> >>> > > --- a/drivers/crypto/s5p-sss.c
> >>> > > +++ b/drivers/crypto/s5p-sss
On Thursday, January 23, 2014 09:47:44 AM Linus Torvalds wrote:
> On Mon, Jan 20, 2014 at 3:23 PM, Rafael J. Wysocki wrote:
> >
> > Please pull from the git repository at
>
> gmail still hates you rjwysocki.net address, even if it now says "spf pass".
>
> So it's something else that makes gmail
On Thu, Jan 23, 2014 at 09:40:44AM -0800, Linus Torvalds wrote:
> On Thu, Jan 23, 2014 at 5:19 AM, Mark Brown wrote:
> > spi: Updates for v3.14
> gmail hates you. I just found four of your emails in my spam-box.
> I don't know why, since it's not the (somewhat) common issue with bad
> or missin
On Fri, Jan 17, 2014 at 12:24:57PM +, Hanjun Guo wrote:
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (C) 2013, Al Stone
> + *
> + * ~~
> + *
> + * This program is free so
> I had earlier submitted a patch [1] to remove the hard coded
> major/minor number for Samsung UART driver, but that was rejected
> because of userspace breakage. Without this patch, Samsung UART driver
> can't bind to the hard-coded device node. Changing the default
> major/minor will also not he
On 01/23/2014 07:14 PM, Cyrill Gorcunov wrote:
> I think setting up dirty bit inside vma_merge() body is a big hammer
> which should not be used, but it's up to caller of vma_merge() to figure
> out if dirty bit should be set or not if merge successed. Thus softdirty
> vma bit should be (and it al
On 01/21/2014 01:25 PM, Borislav Petkov wrote:
On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
cat $(AMD_UCODE_PATH)/* >
ucode_initrd/kernel/x86/microcode/AuthenticAMD.bin
(cd ucode_initrd;find . | cpio -o -H newc >
../$(DISTDIR)/common/ucode_initrd.cpio)
On Wed, Jan 22, 2014 at 11:33 PM, zhuyj wrote:
> Here are the result that we have got:
>
> Actual Tunnel type ifi->ifi_type
> 4IN4 768
> GRE4 778
> 6IN4/6TO4/ISATAP 776
> 4IN6/6IN6/IPIN6 769
>
> So, we can NOT distinguish the actual tunnel type via ifi_type attribute
> except the GRE4 and 4IN4 tun
> Well, it is not the Copyrights section, or you are saying the same
> people should go to MODULE_AUTHOR as in the Copyrights section, even
> if it is potentially several names? I thought this would be the name
> of the person who put the file together even if from existing sources.
You may be ri
Jeff King writes:
> Junio, since you prepare such tarballs[1] anyway for kernel.org, it
> might be worth uploading them to the "Releases" page of git/git. I
> imagine there is a programmatic way to do so via GitHub's API, but I
> don't know offhand. I can look into it if you are interested.
I a
Hi
Here I'm sending some framebuffer patches for matrox, mach64, tga and a
fix for copying on vesafb.
Mikulas
--
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-
In tgafb there is a restriction that prevents the user from setting a
videomode with line length not a multiple of 64 bytes (for example,
800x600 is not allowed).
The reason for this restriction it that functions copyarea_line_8bpp and
copyarea_line_32bpp can not handle a line length that is not a
This patch fixes the hardware cursor on mach64 when font width is not a
multiple of 8 pixels.
If you load such a font, the cursor is expanded to the next 8-byte
boundary and a part of the next character after the cursor is not
visible.
For example, when you load a font with 12-pixel width, the cur
The card works fine in 1980x1080 resolution. Therefore, there is no need
to limit the resolution to 1600 pixels.
Signed-off-by: Mikulas Patocka
---
drivers/video/aty/atyfb_base.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-3.11-rc7-fast/drivers/video/aty/atyfb_bas
This patch fixes mach64 to use unaligned access to the font bitmap.
This fixes unaligned access warning on sparc64 when 14x8 font is loaded.
On x86(64), unaligned access is handled on hardware, so both functions
le32_to_cpup and get_unaligned_le32 perform the same operation.
On RISC machines, un
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
A time to do ls -la /usr/bin:
original patched
32bpp 4.9 3.6
24bpp 4.9 2.9
16bpp 4.9 2.1
8bpp4.9 1.7
Signed-off-by: Mikulas Patocka
---
drivers/v
When X11 is running and the user switches back to console, the card
modifies the content of registers M_MACCESS and M_PITCH in periodic
intervals.
This patch fixes it by restoring the content of these registers before
issuing any accelerator command.
Signed-off-by: Mikulas Patocka
Cc: sta...@vge
On Thu, Jan 23, 2014 at 05:47:02PM +0100, Geert Uytterhoeven wrote:
> Probably your transfer_one_message() forgot to call
> spi_finalize_current_message()? Is this allowed in case of failure?
Probably not, or at least we should be consistent about requiring it or
not. Do you want to send a rever
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
A time to do ls -la /usr/bin:
original patched
32bpp 5.4 3.6
24bpp 5.1 3.0
16bpp 4.9 2.5
8bpp4.9 2.0
Signed-off-by: Mikulas Patocka
---
drivers/v
The function cfb_copyarea is buggy when the copy operation is not aligned on
long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines).
How to reproduce:
- use x86-64 machine
- use a framebuffer driver without acceleration (for example uvesafb)
- set the framebuffer to 8-bit depth
Mode setting in the TGA driver is broken for these reasons:
- info->fix.line_length is set just once in tgafb_init_fix function. If
we change videomode, info->fix.line_length is not recalculated - so
the video mode is changed but the screen is corrupted because of wrong
info->fix.line_length
The functions for data copying copyarea_foreward_8bpp and
copyarea_backward_8bpp are buggy, they produce screen corruption.
This patch fixes the functions and moves the logic to one function
"copyarea_8bpp". For simplicity, the function only handles copying that
is aligned on 8 pixes. If we copy a
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
> Since acpi_evaluate_object() returns acpi_status and not plain int,
> ACPI_FAILURE() should be used for checking its return value. Also
> add some detailed debug info when acpi_evaluate_object() failed.
>
> Reviewed-by: Jani Nikula
> Acked-by:
None of these files are actually using any __init type directives
and hence don't need to include . Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one place to the next.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.inf
Hi Marc,
2014/1/22 Marc C :
> Hi Florian,
>
>> Do not we also need to update drivers/irqchip/irq-gic.c to look for
>> this compatible property? Alternatively should the example DTS contain
>> the following:
>>
>> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
>
> Patch #8 [1] of this se
Hello Linus,
could you please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus
to get a cleanup of JBD log messages and UDF fix of a lockdep warning.
Top of the tree is 4ea7772f828a. The full shortlog is:
Jan Kara (2):
jbd: Revise KERN_EMERG error m
This driver was previously an interface driver. Since USB/IP
exports a whole device, not just an interface, it would make
sense to be a device driver.
This patch also modifies the way userspace sees and uses a
shared device - dealing with interfaces is no longer required.
Signed-off-by: Valentina
On Thu, Jan 23, 2014 at 01:02:43PM +0800, Xiubo Li wrote:
> +menuconfig SND_VF610_SOC
> + tristate "SoC Audio for Freescale VF610 CPUs"
> + select DMA_ENGINE
> + help
> + Say Y or M if you want to add support for codecs attached to
> + the VF610 CPUs.
> +
> +
On Wed, 2014-01-22 at 11:53 -0800, Nicholas A. Bellinger wrote:
> Hi Peter,
>
> Does this satisfy your questions..?
>
> Do you have any more concerns about TASK_RUNNING + prepare_to_wait()
> usage in percpu_ida_alloc() that need to be addressed before I can drop
> this series into target-pending/
On Wed, 2014-01-22 at 07:46 -0800, Frank Mayhar wrote:
> On Tue, 2014-01-21 at 07:58 -0800, Frank Mayhar wrote:
> > Replacing? Or adding to? Is BYPASS always set when DYING is set? (My
> > guess is not but I haven't done an exhaustive analysis.) So the
> > relevant code snippet in __elv_next_re
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt
commit 1739f09e33d8f66bf48ddbc3eca615574da6c4f6 upstream.
Function tracing callbacks expect to have the ftrace_ops that registered it
passed to them, not the address of the vari
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Vijaya Kumar K
commit 4f9b4fb7a2091eec339413a460b1665758401828 upstream.
In case of normal kexec kernel load, all cpu's are offlined
before calling machine_kexec().But in case crash panic cpus
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: H Hartley Sweeten
commit 48108fe3daa0d142f9b97178fdb23704ea3a407b upstream.
The dev->irq passed to request_irq() will always be 0 when the auto_attach
function is called. The pcidev->irq shoul
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Taras Kondratiuk
commit b25f3e1c358434bf850220e04f28eebfc45eb634 upstream.
Kexec disables outer cache before jumping to reboot code, but it doesn't
flush it explicitly. Flush is done implicitl
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Robert Richter
commit bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6 upstream.
On AMD family 10h we see following error messages while waking up from
S3 for all non-boot CPUs leading to a failed IBS
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Paulo Zanoni
commit 0882dae983707455e97479e5e904e37673517ebc upstream.
Properly zero the refcounts and crtc->ddi_pll_set so the previous HW
state doesn't affect the result of reading the curre
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit 8313b8e57f55b15e5b7f7fc5d1630bbf686a9a97 upstream.
If an array is started degraded, and then the missing device
is found it can be re-added and a minimal bitmap-based recovery
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Bob Peterson
commit 62e96cf81988101fe9e086b2877307b6adda5197 upstream.
This patch calls get_write_access in function gfs2_setattr_chown,
which merely increases inode->i_writecount for the dura
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Geert Uytterhoeven
commit f92f455f67fef27929e6043499414605b0c94872 upstream.
{,set}page_address() are macros if WANT_PAGE_VIRTUAL. If
!WANT_PAGE_VIRTUAL, they're plain C functions.
If someon
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit e8b849158508565e0cd6bc80061124afc5879160 upstream.
commit e875ecea266a543e643b19e44cf472f1412708f9
md/raid10 record bad blocks as needed during recovery.
added code to th
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jon Medhurst
commit fe43390702a1b5741fdf217063b05c7612b38303 upstream.
When the pl011 is being used for a console, pl011_console_write forces
the control register (CR) to enable the UART for t
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit b50c259e25d9260b9108dc0c2964c26e5ecbe1c1 upstream.
If we discover a bad block when reading we split the request and
potentially read some of it from a different device.
The c
On Thu, Jan 23, 2014 at 06:04:23PM +, Alan Cox wrote:
> We can then enable that config option for ARM (and in time for any other
> architecture that turns out to need/want it). Eventually it can go away
> (not that its exactly doing any harm if it doesnt).
We'd need to leave it user selectabl
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit 1cc03eb93245e63b0b7a7832165efdc52e25b4e6 upstream.
commit 5d8c71f9e5fbdd95650be00294d238e27a363b5c
md: raid5 crash during degradation
Fixed a crash in an overly simplisti
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Andreas Rohner
commit 70f2fe3a26248724d8a5019681a869abdaf3e89a upstream.
There is a bug in the function nilfs_segctor_collect, which results in
active data being written to a segment, that is
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Hugh Dickins
commit eecc1e426d681351a6026a7d3e7d225f38955b6c upstream.
We see General Protection Fault on RSI in copy_page_rep: that RSI is
what you get from a NULL struct page pointer.
RIP
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jean Delvare
commit 3f9aec7610b39521c7c69d754de7265f6994c194 upstream.
When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jianguo Wu
commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8 upstream.
After a successful hugetlb page migration by soft offline, the source
page will either be freed into hugepage_freelists or
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt
commit 3dc91d4338d698ce77832985f9cb183d8eeaf6be upstream.
While running stress tests on adding and deleting ftrace instances I hit
this bug:
BUG: unable to handle kernel NULL
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: "Eric W. Biederman"
commit f48cfddc6729ef133933062320039808bafa6f45 upstream.
Aditya Kali (adityak...@google.com) wrote:
> Commit bf056bfa80596a5d14b26b17276a56a0dcb080e5:
> "proc: Fix the nam
This is the start of the stable review cycle for the 3.10.28 release.
There are 23 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Jan 25 18:38:43 UTC 2014.
Anything receiv
On 23.01.2014 19:40, Mark Brown wrote:
On Thu, Jan 23, 2014 at 06:04:23PM +, Alan Cox wrote:
We can then enable that config option for ARM (and in time for any other
architecture that turns out to need/want it). Eventually it can go away
(not that its exactly doing any harm if it doesnt).
As usual, we have a batch of fixes that weren't considered significant
enough to warrant going into the later -rcs for previous release, so
they are queued up on this branch.
A handful of these are for various DT fixups for Samsung platforms,
and a handful of other minor things.
There are also a
This is the branch where we usually queue up cleanup efforts, moving
drivers out of the architecture directory, header file restructuring,
etc. Sometimes they tangle with new development so it's hard to keep it
strictly to cleanups.
Some of the things included in this branch are:
* Atmel SAMA5 co
Updates of SoC-near drivers and other driver updates that makes more sense to
take through our tree.
The largest part of this is a conversion of device registration for some
renesas shmobile/sh devices over to use resources. This has required
coordination with the corresponding arch/sh changes, an
Nikolay Aleksandrov's recent bonding option API changes (25a9b54a and e4994612)
introduced u64 as the type of downdelay and updelay. On 32 bit the division and
modulo operations cause compile errors:
ERROR: "__udivdi3" [drivers/net/bonding/bonding.ko] undefined!
ERROR: "__umoddi3" [drivers/net/bon
This branch is reducing in size for every release since most board-related
changes have started happening in devicetrees now. Still, we have some things
going on here.
* Renesas platforms are still adding a bit more legacy device support, something
that should trail off shortly as they move to ful
Here are the main branches for arm-soc for the 3.14 merge window. We'll have a
few more patches towards the end, but this is the bulk of it.
Nothing too surprising in any of it, and we've been able to stay away
from too much conflicts this release cycle, I think the total was around
3 and none of
DT and DT-conversion-related changes for various ARM platforms. Most
of these are to enable various devices on various boards, etc, and not
necessarily worth enumerating.
New boards and systems continue to come in as new devicetree files that
don't require corresponding C changes any more, which i
New core SoC-specific changes.
New platforms:
* Introduction of a vendor, Hisilicon, and one of their SoCs with some
random numerical product name.
* Introduction of EFM32, embedded platform from Silicon Labs (ARMv7m, i.e.
!MMU).
* Marvell Berlin series of SoCs, which include the one in Chromecas
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit f9b0e058cbd04ada76b13afffa7e1df830543c24 upstream.
Commit 4f8ad655dbc8 "writeback: Refactor writeback_single_inode()" added
a condition to skip clean inode. However this is wro
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: H Hartley Sweeten
commit 90daf69a7a3f1d1a41018c799968a0bb896d65e0 upstream.
The SDF_CMD_READ should be one of the s->subdev_flags not part of
the s->type.
Signed-off-by: H Hartley Sweeten
Re
On 2014-01-22 19:43, Andi Kleen wrote:
>>> Huang Ying, can you explain to Jan why you do the wait afterwards?
>>
>> I borrow the code from the original MCE report event code.
>>
>> Andi, could you help us to explain it?
>
> I don't recall all the details, but I believe i also just copied
> it fro
On Thursday 23 January 2014, Boris Ostrovsky wrote:
>On 01/21/2014 01:25 PM, Borislav Petkov wrote:
>> On Tue, Jan 21, 2014 at 12:55:53PM -0500, Boris Ostrovsky wrote:
>>> cat $(AMD_UCODE_PATH)/* >
>>>
>>> ucode_initrd/kernel/x86/microcode/AuthenticAMD.bin
>>>
>>> (cd ucode_init
On Thu, Jan 23, 2014 at 10:38:33AM -0800, Frank Mayhar wrote:
> On Wed, 2014-01-22 at 07:46 -0800, Frank Mayhar wrote:
> > On Tue, 2014-01-21 at 07:58 -0800, Frank Mayhar wrote:
> > > Replacing? Or adding to? Is BYPASS always set when DYING is set? (My
> > > guess is not but I haven't done an ex
On 01/21/2014 08:38 AM, Toralf Förster wrote:
> Jan 21 17:18:57 n22 kernel: INFO: rcu_sched self-detected stall on CPU { 2}
> (t=60001 jiffies g=18494 c=18493 q=183951)
> Jan 21 17:18:57 n22 kernel: sending NMI to all CPUs:
> Jan 21 17:18:57 n22 kernel: NMI backtrace for cpu 2
> Jan 21 17:18:57 n
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Jean Delvare
commit 3f9aec7610b39521c7c69d754de7265f6994c194 upstream.
When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.linaro.org/people/mike.turquette/linux.git
tags/clk-for-linus-3.14-part1
for you to fetch changes up to 2e84d75116c17c20
This is the start of the stable review cycle for the 3.12.9 release.
There are 27 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Jan 25 19:06:36 UTC 2014.
Anything receive
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Hugh Dickins
commit eecc1e426d681351a6026a7d3e7d225f38955b6c upstream.
We see General Protection Fault on RSI in copy_page_rep: that RSI is
what you get from a NULL struct page pointer.
RIP
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Paulo Zanoni
commit 0882dae983707455e97479e5e904e37673517ebc upstream.
Properly zero the refcounts and crtc->ddi_pll_set so the previous HW
state doesn't affect the result of reading the curre
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit f9b0e058cbd04ada76b13afffa7e1df830543c24 upstream.
Commit 4f8ad655dbc8 "writeback: Refactor writeback_single_inode()" added
a condition to skip clean inode. However this is wro
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Andreas Rohner
commit 70f2fe3a26248724d8a5019681a869abdaf3e89a upstream.
There is a bug in the function nilfs_segctor_collect, which results in
active data being written to a segment, that is
301 - 400 of 691 matches
Mail list logo
