On Thu, Jun 18, 2015 at 12:54 PM, Viresh Kumar wrote:
> Migrate meson6 driver to the new 'set-state' interface provided by
> clockevents core, the earlier 'set-mode' interface is marked obsolete
> now.
>
> This also enables us to implement callbacks for new states of clockevent
> devices, for exam
2015-06-20 01:13 keltezéssel, Rafael J. Wysocki írta:
> On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote:
>> Hi,
>>
>> so after the network card came alive again, I tried kernels
>> 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when
>> loading the r8169 driver, I experience
Hi Herbert,
After merging the crypto tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/mac802154/llsec.c: In function 'llsec_do_encrypt_auth':
/scratch/sfr/next/net/mac802154/llsec.c:675:15: error: 'dst' undeclared (first
use in this function)
sg_init_one(dst, skb_put
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in:
net/mac802154/llsec.c
between commit:
5b0579850017 ("mac802154: fix llsec authentication without encryption BUG")
from the bluetooth tree and commit:
25528fdae4ab ("mac802154: Switch to new AEAD interface")
from
On Fri, Jun 19, 2015 at 10:25 PM, Amitoj Kaur Chawla
wrote:
> Used C89 instead of C99 Comments and removed C99 comments performing
> prints only.
> Problem found using checkpatch.pl
>
> ERROR: do not use C99 // comments
>
> Signed-off-by: Amitoj Kaur Chawla
These changes have already been added
Replace spaces with tabs for indentation to fix the checkpatch.pl warning
'WARNING: please, no spaces at the start of a line'
checkpatch doesn't catch comments indented by spaces but I fixed comments
adjacent to warnings as well so they would remain aligned.
Signed-off-by: Juston Li
---
Changes
On Fri, Jun 19, 2015 at 10:21 PM, Greg KH wrote:
>
> On Fri, Jun 19, 2015 at 10:13:11PM -0700, Juston Li wrote:
> > Replace spaces with tabs for indentation to fix the checkpatch.pl warning
> > 'WARNING: please, no spaces at the start of a line'
> >
> > checkpatch doesn't catch comments indented b
>> Putting a function trace on sys_sync and executing sync manually,
>> I was able to see it take 100ms,
>> though function trace itself could be contributing to that...
>
> It would seem that way - you need to get the traces to dump to
> something that has no sync overhead
I don't think that
Used C89 instead of C99 Comments and removed C99 comments performing
prints only.
Problem found using checkpatch.pl
ERROR: do not use C99 // comments
Signed-off-by: Amitoj Kaur Chawla
---
drivers/staging/sm750fb/ddk750_chip.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
dif
On Fri, Jun 19, 2015 at 10:13:11PM -0700, Juston Li wrote:
> Replace spaces with tabs for indentation to fix the checkpatch.pl warning
> 'WARNING: please, no spaces at the start of a line'
>
> checkpatch doesn't catch comments indented by spaces but I fixed comments
> adjacent to warnings as well
Replace spaces with tabs for indentation to fix the checkpatch.pl warning
'WARNING: please, no spaces at the start of a line'
checkpatch doesn't catch comments indented by spaces but I fixed comments
adjacent to warnings as well so they would remain aligned.
Changes since v1:
fix alignment in ddk
The presence of comments originally caused the two lines
to be over 80 characters long.
The issue is fixed by moving the comments into a separate line.
Signed-off-by: Arjun Krishna Babu
---
drivers/staging/vt6656/rxtx.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/
main: fails to allocate irq for hpet0
[0.288755] irqdomain: fails to allocate irq for hpet0
[0.288820] irqdomain: fails to allocate irq for hpet0
[0.25] irqdomain: fails to allocate irq for hpet0
---
-ss
[ 0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.1.0
On (06/19/15 14:21), Thomas Gleixner wrote:
[..]
> Can you please collect the output of /proc/timer_list for the previous
> patch and then replace the previous patch with the one below and
> gather all the data again?
>
attached.
-ss
Timer List Version: v0.8
HRTIMER_MAX_CLOCK_BASES: 4
no
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
The Coccinelle semantic patch that makes this change is as follows:
//
@eth_zero_addr@
expression e;
@@
-memset(e,0x00,ETH_ALEN);
+eth_zero_addr(e);
//
Signed-off
On Fri, Jun 19, 2015 at 9:27 PM, Steven Rostedt wrote:
> On Fri, 19 Jun 2015 19:25:59 -0400
> Trond Myklebust wrote:
>
>
>> 8<--
>> >From 4876cc779ff525b9c2376d8076edf47815e71f2c Mon Sep 17 00:00:00 2001
>> From: Trond Myklebust
>> Date
On Fri, 19 Jun 2015, Jerome Glisse wrote:
> On Thu, Jun 18, 2015 at 07:06:08PM -0700, Mark Hairgrove wrote:
> > On Thu, 21 May 2015, j.gli...@gmail.com wrote:
>
> [...]
> > > +
> > > +static inline dma_addr_t hmm_pde_from_pfn(dma_addr_t pfn)
> > > +{
> > > + return (pfn << PAGE_SHIFT) | HMM_PDE
Hi Graham,
> -Original Message-
> From: Graham Moore [mailto:grmo...@opensource.altera.com]
> Sent: Saturday, June 20, 2015 12:41 AM
> To: Anurag Kumar Vulisha
> Cc: dw...@infradead.org; computersforpe...@gmail.com;
> ma...@denx.de; shijie.hu...@intel.com; zaj...@gmail.com;
> b...@decadent
On Fri, Jun 19, 2015 at 05:39:11PM -0700, Dave Hansen wrote:
> On 06/19/2015 04:33 PM, Andi Kleen wrote:
> >> > I *think* we can avoid taking the srcu_read_lock() for the
> >> > common case where there are no actual marks on the file
> >> > being modified *or* the vfsmount.
> > What is so expensive
This patch fix some spelling typo in sysfs-bus-fcoe
Signed-off-by: Masanari Iida
---
Documentation/ABI/testing/sysfs-bus-fcoe | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe
b/Documentation/ABI/testing/sysfs-bus-fcoe
inde
On 06/19/2015 06:18 AM, poesc...@lemonage.de wrote:
From: Lars Poeschel
Add a start_enabled module parameter to the omap_wdt that starts the
watchdog on module insertion. The default value is 0 which does not
start the watchdog - which also does not change the behaviour if the
behavior
para
On 06/19/2015 01:34 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.0.6 release.
There are 105 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 ma
On Fri, 19 Jun 2015 19:25:59 -0400
Trond Myklebust wrote:
> 8<--
> >From 4876cc779ff525b9c2376d8076edf47815e71f2c Mon Sep 17 00:00:00 2001
> From: Trond Myklebust
> Date: Fri, 19 Jun 2015 16:17:57 -0400
> Subject: [PATCH v2] SUNRPC: En
On 06/19/2015 01:35 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.14.45 release.
There are 44 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 m
On 06/19/2015 01:36 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.81 release.
There are 29 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 m
On 06/19/2015 02:36 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.81 release.
> There are 29 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 s
On 06/19/2015 02:35 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.45 release.
> There are 44 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 s
On 06/19/2015 02:34 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.0.6 release.
> There are 105 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 sh
On 6/19/15 7:00 AM, Daniel Wagner wrote:
BPF offers another way to generate latency histograms. We attach
kprobes at trace_preempt_off and trace_preempt_on and calculate the
time it takes to from seeing the off/on transition.
...
Signed-off-by: Daniel Wagner
...
With the rebase on net-next n
OK. Thanks.
On 06/18/2015 11:15 PM, Vaishali Thakkar wrote:
In little endian cases, the macros htons and cpu_to_be16 unfolds
to __swab16 which provides special case for constants. In big
endian cases, __constant_htons and htons expand directly to the
same expression. The same applies for __cons
Replace spaces with tabs for indentation to fix the checkpatch.pl warning
'WARNING: please, no spaces at the start of a line'
checkpatch doesn't catch comments indented by spaces but I fixed comments
adjacent to warnings as well so they would remain aligned.
Signed-off-by: Juston Li
---
drivers
On Fri, 19 Jun 2015 20:37:45 -0400
Steven Rostedt wrote:
> > Is it causing any other damage than the rkhunter warning you reported?
>
> Well, not that I know of. Are you sure that this port will be
> reconnected, and is not just a leak. Not sure if you could waste more
> ports this way with con
OK. Thanks.
On 06/18/2015 11:23 PM, Vaishali Thakkar wrote:
In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with
Hi,
On 18/06/2015 at 00:28:06 +0530, Vaibhav Hiremath wrote :
> - pdata = dev_get_platdata(&pdev->dev);
> - if (pdata == NULL)
> - dev_warn(&pdev->dev, "No platform data!\n");
> + if (!pdata && !node) {
> + dev_err(&pdev->dev,
> + "pm80x-rtc
On 06/19/2015 04:33 PM, Andi Kleen wrote:
>> > I *think* we can avoid taking the srcu_read_lock() for the
>> > common case where there are no actual marks on the file
>> > being modified *or* the vfsmount.
> What is so expensive in it? Just the memory barrier in it?
The profiling doesn't hit on th
On Fri, 19 Jun 2015 19:25:59 -0400
Trond Myklebust wrote:
> On Fri, 2015-06-19 at 18:14 -0400, Steven Rostedt wrote:
> > On Fri, 19 Jun 2015 16:30:18 -0400
> > Trond Myklebust wrote:
> >
> > > Steven, how about something like the following patch?
> > >
> >
> > OK, the box I'm running this on
On Fri, Jun 19, 2015 at 04:33:06PM -0700, Andi Kleen wrote:
> On Fri, Jun 19, 2015 at 02:50:25PM -0700, Dave Hansen wrote:
> >
> > From: Dave Hansen
> >
> > I have a _tiny_ microbenchmark that sits in a loop and writes
> > single bytes to a file. Writing one byte to a tmpfs file is
> > around 2
Hi Linus,
smattering of fixes,
mgag200:
don't accept modes that aren't aligned properly as hw can't do it
i915:
two regression fixes
radeon:
one query to allow userspace fixes
one oops fixer for older hw with new options enabled
Dave.
The following changes si
On 19/06/15 16:26, Brian Norris wrote:
> Make use of the new irq_chip chip_{suspend,resume} callbacks.
>
> This is required because if there are no installed child IRQs for
> this chip, the irq_{suspend,resume} functions will not be called.
> However, we still need to save/restore the forwarding m
On 19/06/15 16:26, Brian Norris wrote:
> Some (admittedly odd) irqchips perform functions that are not directly
> related to any of their child IRQ lines, and therefore need to perform
> some tasks during suspend/resume regardless of whether there are
> any "installed" interrupts for the irqchip. H
On Fri, Jun 19, 2015 at 02:50:25PM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> I have a _tiny_ microbenchmark that sits in a loop and writes
> single bytes to a file. Writing one byte to a tmpfs file is
> around 2x slower than reading one byte from a file, which is a
> _bit_ more than I
Some (admittedly odd) irqchips perform functions that are not directly
related to any of their child IRQ lines, and therefore need to perform
some tasks during suspend/resume regardless of whether there are
any "installed" interrupts for the irqchip. However, the current
generic-chip framework does
Make use of the new irq_chip chip_{suspend,resume} callbacks.
This is required because if there are no installed child IRQs for
this chip, the irq_{suspend,resume} functions will not be called.
However, we still need to save/restore the forwarding mask, to enable
the top-level GIC interrupt; other
On Fri, 2015-06-19 at 18:14 -0400, Steven Rostedt wrote:
> On Fri, 19 Jun 2015 16:30:18 -0400
> Trond Myklebust wrote:
>
> > Steven, how about something like the following patch?
> >
>
> OK, the box I'm running this on is using v4.0.5, can you make a patch
> based on that, as whatever you make
On Fri, Jun 19, 2015 at 07:28:11PM +0200, Beata Michalska wrote:
> On 06/19/2015 02:03 AM, Dave Chinner wrote:
> > On Thu, Jun 18, 2015 at 10:25:08AM +0200, Beata Michalska wrote:
> >> On 06/18/2015 01:06 AM, Dave Chinner wrote:
> >>> On Tue, Jun 16, 2015 at 03:09:30PM +0200, Beata Michalska wrote:
The "new_len > old_len" branch in vma_to_resize() looks very confusing.
It only covers the VM_DONTEXPAND/pgoff checks but everything below is
equally unneeded if new_len == old_len.
Change this code to return if "new_len == old_len", new_len < old_len
is not possible, otherwise the code below is w
Minor, but this check is overcomplicated. Two half-intervals do NOT
overlap if END1 <= START2 || END2 <= START1, mremap_to() just needs
to negate this check.
Signed-off-by: Oleg Nesterov
---
mm/mremap.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm
On Friday, June 19, 2015 11:38:28 AM Lv Zheng wrote:
> ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4
>
> The root cause of the reported bug might be one of the followings:
> 1. BIOS may favor the 64-bit firmware waking vector address when the
>version of the FACS is greater than 0 and
move_vma() sets *locked even if move_page_tables() or ->mremap()
fails, change sys_mremap() to check "ret & ~PAGE_MASK".
I think we should simply remove the VM_LOCKED code in move_vma(),
that is why this patch doesn't change move_vma(). But this needs
more cleanups.
Signed-off-by: Oleg Nesterov
move_vma() can't just return if f_op->mremap() fails, we should
unmap the new vma like we do if move_page_tables() fails. To avoid
the code duplication this patch moves the "move entries back" under
the new "if (err)" branch.
Signed-off-by: Oleg Nesterov
---
mm/mremap.c | 15 +++
1
On 06/18, Oleg Nesterov wrote:
>
> I'll send the fixes, but also I'll try to cleanup this code. Not
> sure I will succeed ;)
Yes, I think this code needs more cleanups, but this is not simple ;)
Let me first send the changes which look "obviously correct" to me.
Perhaps I'll send more patches on
Commit-ID: 930e6fcd2bcce9bcd9d4aa7e755678d33f3fe6f4
Gitweb: http://git.kernel.org/tip/930e6fcd2bcce9bcd9d4aa7e755678d33f3fe6f4
Author: Kan Liang
AuthorDate: Wed, 17 Jun 2015 09:51:10 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 18:20:15 -0300
perf tools: Add t
Commit-ID: 9d9cad763ca79dd3697e9f2d1df648e37496582b
Gitweb: http://git.kernel.org/tip/9d9cad763ca79dd3697e9f2d1df648e37496582b
Author: Kan Liang
AuthorDate: Wed, 17 Jun 2015 09:51:11 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 18:27:13 -0300
perf tools: Confi
Commit-ID: c05676c06232e6459a6106ddf0d4e154ce6cd859
Gitweb: http://git.kernel.org/tip/c05676c06232e6459a6106ddf0d4e154ce6cd859
Author: Yannick Brosseau
AuthorDate: Wed, 17 Jun 2015 16:41:10 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 18:14:05 -0300
perf repor
Commit-ID: 3e323dc0a80c3921f30d03ca300426f70dc5a327
Gitweb: http://git.kernel.org/tip/3e323dc0a80c3921f30d03ca300426f70dc5a327
Author: Arnaldo Carvalho de Melo
AuthorDate: Fri, 19 Jun 2015 17:49:29 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 18:14:05 -0300
pe
Commit-ID: ae3b6ab603bce6a74ca089f7a944196863166a52
Gitweb: http://git.kernel.org/tip/ae3b6ab603bce6a74ca089f7a944196863166a52
Author: Arnaldo Carvalho de Melo
AuthorDate: Fri, 19 Jun 2015 17:35:25 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 18:13:59 -0300
pe
Commit-ID: 276af92f107fc35ede78c7cdea323aaec364002c
Gitweb: http://git.kernel.org/tip/276af92f107fc35ede78c7cdea323aaec364002c
Author: Arnaldo Carvalho de Melo
AuthorDate: Fri, 19 Jun 2015 16:36:12 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 16:39:21 -0300
pe
Commit-ID: 0c4a5bcea4609948375173cdea8d73783110a75e
Gitweb: http://git.kernel.org/tip/0c4a5bcea4609948375173cdea8d73783110a75e
Author: Martin Liška
AuthorDate: Fri, 19 Jun 2015 16:10:43 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 16:39:18 -0300
perf annotate:
Commit-ID: 516e536849d26a2bcacd9050f4a7222a14c0f9e4
Gitweb: http://git.kernel.org/tip/516e536849d26a2bcacd9050f4a7222a14c0f9e4
Author: Arnaldo Carvalho de Melo
AuthorDate: Fri, 19 Jun 2015 16:59:43 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 16:59:43 -0300
pe
Commit-ID: 5f00b0f45bc3f1e77f0db0e915fd3302db669914
Gitweb: http://git.kernel.org/tip/5f00b0f45bc3f1e77f0db0e915fd3302db669914
Author: Arnaldo Carvalho de Melo
AuthorDate: Fri, 19 Jun 2015 17:30:20 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 17:30:20 -0300
pe
Commit-ID: fbb7997e308064a0ea26fb5435ee5fa69a588dac
Gitweb: http://git.kernel.org/tip/fbb7997e308064a0ea26fb5435ee5fa69a588dac
Author: Arnaldo Carvalho de Melo
AuthorDate: Fri, 19 Jun 2015 16:56:04 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 16:56:04 -0300
pe
On Friday, June 19, 2015 08:26:31 AM Ingo Molnar wrote:
>
> * Lv Zheng wrote:
>
> > This patch updates acpi_set_firmware_waking_vector() invocations in order
> > to keep 32-bit firmware waking vector favor for Linux.
>
> This sentence does not parse.
>
> > 64-bit firmware waking vector has nev
Commit-ID: a5499b37197ab4b5fed101370df7ccadacbb4340
Gitweb: http://git.kernel.org/tip/a5499b37197ab4b5fed101370df7ccadacbb4340
Author: Adrian Hunter
AuthorDate: Fri, 29 May 2015 16:33:30 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 16:03:33 -0300
perf tools: E
When working on collateral evolutions often times by definition
we end up having to go and transform existing drivers to new APIs
tree wide. You have a few options when this happens:
0) *If* you're lucky your collateral evolution is very specific to
a subsystem and you get to only work with one
On Friday, June 19, 2015 11:38:28 AM Lv Zheng wrote:
> ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4
>
> The root cause of the reported bug might be one of the followings:
Care to describe the bug in the changelog too? And in a few following
changelogs as well?
> 1. BIOS may favor the
The kernel initializes CPU & memory's NUMA topology from ACPI
SRAT table. Some other ACPI tables, such as NFIT and DMAR, also
contain proximity IDs for their device's NUMA topology. This
information can be used to improve performance of these devices.
This patch introduces acpi_map_pxm_to_online
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 79928928c5a27d58ae48285d2a3f7aa835db7547:
>
> Merge tag 'perf-core-for-mingo-2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
On Sat, 2015-06-20 at 01:26 +0200, Rafael J. Wysocki wrote:
> On Friday, June 19, 2015 12:18:32 PM Toshi Kani wrote:
:
> > +/**
> > + * acpi_map_pxm_to_online_node - Map proximity ID to on-line node
> > + * @pxm: ACPI proximity ID
> > + *
> > + * This is similar to acpi_map_pxm_to_node(), but alw
Commit-ID: 75e84ab906ef8935cff3df3d8929f1bafea81599
Gitweb: http://git.kernel.org/tip/75e84ab906ef8935cff3df3d8929f1bafea81599
Author: Lukas Wunner
AuthorDate: Thu, 18 Jun 2015 13:00:32 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 19 Jun 2015 16:39:42 -0300
perf tools: Fi
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 15c1247953e8a45232ed5a5540f291d2d0a77665:
>
> Revert "perf/x86/intel/uncore: Move uncore_box_init() out of driver
> initialization" (2015-06-09 11:44:37 +02
On Fri, Jun 19, 2015 at 02:34:37AM -0400, Len Brown wrote:
> > Can you repeat this test on your system, so that we can determine if
> > the 5ms ""sync time" is actually just the overhead of inode cache
> > traversal? If that is the case, the speed of sync on a clean
> > filesystem is already a solv
* Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 19, 2015 at 08:27:11AM +0200, Ingo Molnar escreveu:
> > * Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jun 18, 2015 at 10:58:13PM +0200, Ingo Molnar escreveu:
> > > > * Arnaldo Carvalho de Melo wrote:
> > > > > z Toggle zeroing of sa
On Friday, June 19, 2015 12:18:32 PM Toshi Kani wrote:
> The kernel initializes CPU & memory's NUMA topology from ACPI
> SRAT table. Some other ACPI tables, such as NFIT and DMAR, also
> contain proximity IDs for their device's NUMA topology. This
> information can be used to improve performance
On Fri, Jun 19, 2015 at 3:41 PM, Brian Norris
wrote:
> + tglx, Kevin
^^ for real this time
> On Thu, Jun 18, 2015 at 08:20:52PM -0700, Gregory Fong wrote:
>> On Thu, Jun 18, 2015 at 5:11 PM, Brian Norris
>> wrote:
>> > This patch set introduces system suspend/resume support for Broadcom STB
>
On Friday, June 19, 2015 03:36:46 PM Tomeu Vizoso wrote:
> On 18 June 2015 at 23:50, Rafael J. Wysocki wrote:
> > On Wednesday, June 17, 2015 03:42:12 PM Tomeu Vizoso wrote:
> >> To decrease the chances of devices deferring their probes because of
> >> dependencies not having probed yet because of
On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote:
> Hi,
>
> so after the network card came alive again, I tried kernels
> 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when
> loading the r8169 driver, I experience the symptoms described
> below. Also, after booting 4.0.5 an
+ tglx, Kevin
On Thu, Jun 18, 2015 at 08:20:52PM -0700, Gregory Fong wrote:
> On Thu, Jun 18, 2015 at 5:11 PM, Brian Norris
> wrote:
> > This patch set introduces system suspend/resume support for Broadcom STB
> > SoCs.
> > There are two suspend modes (S2 and S3) as well as a related low-power
Hi Cyrille,
On Fri, Jun 19, 2015 at 10:49:35AM +0200, Cyrille Pitchen wrote:
> +
> + clk_prepare_enable(clk);
I believe you need to have error handling here, not because it will
actually fail but to handle deferrals.
> + version = readl(map + FX_VERSION);
> + writel(mr, map + FX_MR);
If I sit in a loop and do write()s to small tmpfs files,
__sb_end_write() is third-hottest kernel function due to its
smp_mb().
The stated purpose for the smp_mb() in __sb_end_write() is to
ensure "s_writers are updated before we wake up waiters". We
only wake up waiters if waitqueue_active(), b
Currently, __sb_start_write() and freeze_super() can race with
each other. __sb_start_write() uses a smp_mb() to ensure that
freeze_super() can see its write to sb->s_writers.counter and
that it can see freeze_super()'s update to sb->s_writers.frozen.
This all seems to work fine.
But, this smp_m
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Now that we have pci_iomap_wc() add the respective devres helpers.
Cc: Toshi Kani
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Bjorn Helgaas
Cc: Antonino Daplas
Cc: Jean-Chris
From: "Luis R. Rodriguez"
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.
Add pci_iomap_wc() and pci_iomap_wc_range(
On Tue, Jun 16, 2015 at 12:31 PM, Luis R. Rodriguez wrote:
> On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez wrote:
>> On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez wrote:
>>> Ville,
>>>
>>> the x86 patches are in and on their way to the next version of Linux.
>>> Can I trouble you for you
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
On Fri, Jun 19, 2015 at 10:00:15AM +0200, Krzysztof Hałasa wrote:
> Intersil/Techwell TW686[4589]-based video capture cards have an empty
> (zero) class code. Fix it.
>
> Signed-off-by: Krzysztof Hałasa
Applied to pci/misc for v4.2, with minor tweak as below to use
PCI_CLASS_MULTIMEDIA_OTHER ins
On Fri, 19 Jun 2015 16:30:18 -0400
Trond Myklebust wrote:
> Steven, how about something like the following patch?
>
OK, the box I'm running this on is using v4.0.5, can you make a patch
based on that, as whatever you make needs to go to stable as well.
distcc[31554] ERROR: compile
/home/roste
From: "Luis R. Rodriguez"
This lets drivers take advantage of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e titled
[Trimmed greg at what I'm interpreting as his request.]
On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley wrote:
>> Changes to existing files to add 0pf j2 board support.
>
> Thanks for your patch!
>
> Like Greg already said, splitting
From: "Luis R. Rodriguez"
Arnd,
After a long-winded conversation with Bjorn over use of
EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() he's noted he'd
be OK if this goes through you as an alternative. This series
goes unmodified from the last posted v6 series, I am just
reposting and addressing
From: Abhimanyu Kapur
Add support for debug communications channel based
hvc console for arm64 cpus.
Signed-off-by: Abhimanyu Kapur
Signed-off-by: Timur Tabi
---
arch/arm64/include/asm/dcc.h | 49
drivers/tty/hvc/Kconfig | 2 +-
2 files chang
On Fri, Jun 19, 2015 at 06:07:13PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 18, 2015 at 11:48:40PM +0200, Jiri Olsa escreveu:
> > We need to store command names with the pid. Changing
> > map to be struct holding pid. Process name is coming
> > in shortly.
> >
> > Link: http://lkml.ker
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit 79928928c5a27d58ae48285d2a3f7aa835db7547:
Merge tag 'perf-core-for-mingo-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
(2015-06-18 09:40:46 +0200)
are available in the git
From: Kan Liang
System wide sampling like 'perf top' or 'perf record -a' read all
threads /proc/xxx/maps before sampling. If there are any threads which
generating a keeping growing huge maps, perf will do infinite loop
during synthesizing. Nothing will be sampled.
This patch fixes this issue by
From: Adrian Hunter
The thread-stack represents a thread's current stack. When a thread
exits there can still be many functions on the stack e.g. exit() can be
called many levels deep, so all the callers will never return. To get
that information output, the thread-stack must be flushed.
Previ
From: Arnaldo Carvalho de Melo
When the user presses 'f' to disable events the visual cues are, well,
the percentages not changing and the number of events freezing.
Be more explicit by changing the help line at the bottom of the screen
to show the following messages when 'f' is pressed:
"Pre
1 - 100 of 751 matches
Mail list logo
