On Mon, 02 Feb 2015 11:41:40 -0800
Stephen Boyd wrote:
+ trace_clk_unprepare_complete(clk);
> >>clk_core_unprepare(clk->parent);
> > I guess you do not care about the clk_core_unprepare time.
>
> Function trace will handle that?
>
If gcc doesn't inline it.
-- Steve
--
To unsubscribe
On Fri, Jan 30, 2015 at 06:43:33PM +, Ian Abbott wrote:
> The SPI_IOC_MESSAGE(n) ioctl commands' argument points to an array of n
> struct spi_ioc_transfer elements. The spidev's compat_ioctl handler
> just converts this pointer and passes it on to the unlocked_ioctl
> handler to process it.
As promised/threatened on IRC.
Thanx, Paul
rcu: Reverse rcu_dereference_check() conditions
The rcu_dereference_check() family of primitives evaluates the RCU
lockdep
Hello Richard
>
> Hmm, will we ever need the new function for in-tree drivers?
> In general we add new functions only if they have an in-tree user
> for it.
It is part of a driver for a camera at qtec.com .
The policy so far has been that we offer the code to our clients but
we cannot afford to
On 01/31/15 14:37, Robert Jarzmik wrote:
> As pxa27x_clocks_init() is called from early boot stage, it has to be
> reachable from pxa architecture code, as are pxa25x_clocks_init() and
> pxa2xx_clock_init().
>
> Remove the static declaration, which was introduced before the order
> issue between cl
On Mon, 02 Feb 2015 16:20:42 +0100 SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 2 Feb 2015 15:10:57 +0100
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> * This issue was detected by us
Hey,
On Mon, Feb 02, 2015 at 10:26:44PM +0300, Konstantin Khlebnikov wrote:
> Removing memcg pointer from struct page might be tricky.
> It's not clear what to do with truncated pages: either link them
> with lru differently or remove from lru right at truncate.
> Swap cache pages have the same pr
On Mon, Feb 2, 2015 at 8:34 PM, Maciej W. Rozycki wrote:
> On Mon, 2 Feb 2015, Kay Sievers wrote:
>
>> > I thought that fixing the udev behavior would solve the problem. But
>> > it turned out that I was too naive. A bigger problem is that all
>> > user-space stuff misinterprets DISK_EVENT_EJECT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/2015 02:21 PM, Oleg Nesterov wrote:
> I'll try to read this patch tomorrow. Too late for me.
>
> I think it is fine, but
>
> On 02/02, r...@redhat.com wrote:
>>
>> This also fixes the lazy FPU restore disabling in drop_fpu,
>> which only re
On 02/02/15 05:37, Heikki Krogerus wrote:
> If the divider or multiplier values values are 0 in the
s/values//
> register, bypassing the divider and returning the parent
> clock rate in clk_fd_recalc_rate().
>
> Signed-off-by: Heikki Krogerus
> ---
Reviewed-by: Stephen Boyd
> drivers/clk/clk
On 02/02/15 08:00, Steven Rostedt wrote:
> On Fri, 30 Jan 2015 16:16:11 -0800
> Stephen Boyd wrote:
>
>> It's useful to have tracepoints around operations that change the
>> hardware state so that we can debug clock hardware performance
>> and operations. Four basic types of events are supported:
On Mon, Feb 2, 2015 at 11:10 AM, Joe Perches wrote:
>
> Perhaps removing the while and using fls(x) would be better.
No. fls is often slow, and you then do have to also round it down to
an even bit number etc, so it gets somewhat complex too.
We *probably* have some argument range that we care m
From: "Steven Rostedt (Red Hat)"
Add tracefs_configured() to return true if tracefs is configured in the
kernel (succeeds to find tracefs), and debugfs_configured() if debugfs is
configured in the kernel (succeeds to find debugfs).
Signed-off-by: Steven Rostedt
---
tools/lib/api/fs/debugfs.c |
Hi!
Am 02.02.2015 um 20:33 schrieb Ricardo Ribalda Delgado:
> Hello
>
> On Mon, Feb 2, 2015 at 8:17 PM, Richard Weinberger
> wrote:
>> On Mon, Feb 2, 2015 at 5:22 PM, Ricardo Ribalda Delgado
>>
>> Can you please also send a patch which shows the usage of this new function
>> by a driver?
>
> It
From: "Steven Rostedt (Red Hat)"
As tracefs may be mounted instead of debugfs to get to the event directories,
have perf know about tracefs, and use that file system over debugfs if it
is present.
Signed-off-by: Steven Rostedt
---
tools/perf/tests/open-syscall-all-cpus.c | 7 +++-
tools/perf/
As I'm trying to move the tracing directory from debugfs, perf needs to
be aware of this as system admins will now be able to mount the tracing
directory without needing to mount debugfs. This patch series addresses
this and makes perf aware of tracefs.
I based this series on a recent tip branch:
From: "Steven Rostedt (Red Hat)"
It's rather strange to be checking the debugfs MAGIC number for the
tracing directory. A system admin may want to have a custom set of events
to trace and it should be allowed to let the admin make a temp file
(even for tracing virtual boxes, this is useful).
Als
From: "Steven Rostedt (Red Hat)"
Instead of hard coding "/sys/kernel/debug" everywhere, create
a macro to hold where the default path exists.
Signed-off-by: Steven Rostedt
---
tools/lib/api/fs/debugfs.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/lib/ap
From: "Steven Rostedt (Red Hat)"
In preparation for adding tracefs for perf to use, create a findfs
helper utility that find_debugfs uses instead of hard coding the search
in the code. This will allow for a find_tracefs to be used as well.
Signed-off-by: Steven Rostedt
---
tools/lib/api/Makefi
From: "Steven Rostedt (Red Hat)"
Since tracefs will now hold the event directory for perf, and
even though by default, debugfs still mounts tracefs on the
debugfs/tracing directory, the system admin may now choose to not
mount debugfs and instead just mount tracefs instead.
Having tracefs helper
Hello
On Mon, Feb 2, 2015 at 8:17 PM, Richard Weinberger
wrote:
> On Mon, Feb 2, 2015 at 5:22 PM, Ricardo Ribalda Delgado
>
> Can you please also send a patch which shows the usage of this new function
> by a driver?
It is currently out of tree, but here you can see the relevant code:
mtd_offse
On Mon, 2 Feb 2015, Kay Sievers wrote:
> > I thought that fixing the udev behavior would solve the problem. But
> > it turned out that I was too naive. A bigger problem is that all
> > user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
> > see this as if the disk is *ready* to b
On Mon, Feb 02, 2015 at 02:03:33PM -0500, Peter Hurley wrote:
> On 02/02/2015 11:11 AM, Paul E. McKenney wrote:
> > On Tue, Jan 20, 2015 at 09:03:12AM -0500, Peter Hurley wrote:
> >> On 01/19/2015 07:30 PM, Paul E. McKenney wrote:
> >>> On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wro
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backward
On Mon, Feb 02, 2015 at 11:55:03AM +0800, Wang, Yalin wrote:
> This patch change non-atomic bitops,
> add a if() condition to test it, before set/clear the bit.
> so that we don't need dirty the cache line, if this bit
> have been set or clear. On SMP system, dirty cache line will
> need invalidate
Arnd, Olof, Kevin,
As advised by Olof, here is a second attempt with this pull-request but this
time with the at91-3.19-fixes branch as a base. Here is how I did it:
- took v3.19-rc4
- merged my at91-3.19-fixes branch that is now in Linus' tree
- merged my at91-cleanup3 tag that you already have i
On 30.01.2015 19:07, Tejun Heo wrote:
Hey, again.
On Fri, Jan 30, 2015 at 01:27:37AM -0500, Tejun Heo wrote:
The previous behavior was pretty unpredictable in terms of shared file
ownership too. I wonder whether the better thing to do here is either
charging cases like this to the common ances
apic_force_enable is not defined for amd64.
Without this patch:
LD init/built-in.o
arch/x86/built-in.o: In function `dtb_lapic_setup':
kernel/devicetree.c:155:
undefined reference to `apic_force_enable'
Makefile:923: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Signed-off-
linked in:
> > [ 10.568237] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
> > 3.19.0-rc6-next-20150202 #2037
> > [ 10.568237] Hardware name: Generic OMAP4 (Flattened Device Tree)
> > [ 10.568267] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x
osc_init() is marked as the module_init function in osc_request.c
and is never used anywhere else. Hence, it can (and should) be
declared static.
sparse also complained about this with the following warning, which
is fixed by this patch.
andreas@workbox:~/linux-next$ make C=1 M=drivers/staging/lu
I'll try to read this patch tomorrow. Too late for me.
I think it is fine, but
On 02/02, r...@redhat.com wrote:
>
> This also fixes the lazy FPU restore disabling in drop_fpu, which
> only really works when !use_eager_fpu().
> ...
>
> --- a/arch/x86/include/asm/fpu-internal.h
> +++ b/arch/x86/inc
Are we good with this?
/Jarkko
On Thu, Jan 29, 2015 at 06:43:12PM +, Scot Doyle wrote:
> On Thu, 29 Jan 2015, Jarkko Sakkinen wrote:
> > Fixed suspend/resume paths for TPM 2.0 and consolidated all the
> > associated code to the tpm_pm_suspend() and tpm_pm_resume()
> > functions. Resume path s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/2015 01:55 PM, Oleg Nesterov wrote:
> On 02/02, r...@redhat.com wrote:
>>
>> From: Rik van Riel
>>
>> With Oleg's patch "x86, fpu: don't abuse FPU in kernel threads
>> if use_eager_fpu()", kernel threads no longer have an FPU state
>> even
On Mon, Feb 2, 2015 at 5:22 PM, Ricardo Ribalda Delgado
wrote:
> Currently, there is no way to find out the offset of an mtd partition by
> a driver. This might be needed by external hardware.
>
> For example, a flash containing the firmware of an external device that
> is also accessible by the m
When tapping a clickpad with two fingers, there is a chance that the
sensor sees first only one finger, and at the next scan only the
second one.
In this case, the sensors says that there has been only one finger
on the clickpad, which moved really fast between two scans.
We can try to counter thi
On Mon, Feb 02, 2015 at 08:07:51PM +0100, Pali Rohár wrote:
> On Monday 02 February 2015 20:01:11 Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Feb 02, 2015 at 07:58:59PM +0100, Pali Rohár wrote:
> > > On Monday 02 February 2015 19:54:58 Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Sat, Jan 3
On 02.02.2015 15:16, Al Viro wrote:
> On Mon, Feb 02, 2015 at 02:36:43PM +0100, Andreas Ruprecht wrote:
>> When running sparse on the osc/ subdirectory, it shows the
>> following warning:
>>
>> andreas@workbox:~/linux-next$ make C=1 M=drivers/staging/lustre/lustre/osc/
>> [...]
>> drivers/staging/l
On Mon, Feb 2, 2015 at 11:00 AM, Linus Torvalds
wrote:
>
> (I'm also not entirely sure what uses int_sqrt() that ends up being so
> performance-critical, so it would be good to document that too, since
> that probably also matters for the "what's the normal argument range"
> question..)
... it's
On Wednesday 28 January 2015 14:51:23 Marc Zyngier wrote:
> void __weak pcibios_update_irq(struct pci_dev *dev, int irq)
> {
> - dev_dbg(&dev->dev, "assigning IRQ %02d\n", irq);
> - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
> + struct irq_data *d;
> +
> + d = ir
On Mon, 2015-02-02 at 09:12 -0800, Anshul Garg wrote:
> From: Anshul Garg
>
> Unnecessary instructions are executing even though m is
> greater than x so added logic to make m less than equal to
> x before performing these operations.
>
> Signed-off-by: Anshul Garg
> ---
> lib/int_sqrt.c |
On Monday 02 February 2015 20:01:11 Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 02, 2015 at 07:58:59PM +0100, Pali Rohár wrote:
> > On Monday 02 February 2015 19:54:58 Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote:
> > > > This patch adds remov
On 2015-02-02 13:47, Mimi Zohar wrote:
On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
Quoting Casey Schaufler (ca...@schaufler-ca.com):
I'm game to participate in such an effort. The POSIX scheme
is workable, but given that it's 20 years old and hasn't
developed real traction it's hard
Quoting Steven Rostedt (2015-02-02 08:00:33)
> On Fri, 30 Jan 2015 16:16:11 -0800
> Stephen Boyd wrote:
>
> > It's useful to have tracepoints around operations that change the
> > hardware state so that we can debug clock hardware performance
> > and operations. Four basic types of events are sup
On 02/02/2015 11:11 AM, Paul E. McKenney wrote:
> On Tue, Jan 20, 2015 at 09:03:12AM -0500, Peter Hurley wrote:
>> On 01/19/2015 07:30 PM, Paul E. McKenney wrote:
>>> On Tue, Jan 06, 2015 at 12:47:53PM -0800, Paul E. McKenney wrote:
On Tue, Jan 06, 2015 at 02:57:37PM -0500, Peter Hurley wrote:
On Mon, Feb 2, 2015 at 2:20 PM, Takashi Iwai wrote:
> we've got a bug report about the mishandling of DVD/CDROM media eject
> button, and it seems indeed broken since some time ago. In short:
> when the eject button is pressed, the media is forcibly ejected no
> matter whether it's mounted or in
On 02/02/2015 06:45 AM, Hanjun Guo wrote:
From: Graeme Gregory
Add documentation for the guidelines of how to use ACPI
on ARM64.
This patch has a slight corruption to it:
In-Reply-To: <1422881149-8177-1-git-send-email-hanjun@linaro.org>
References: <1422881149-8177-1-git-send-email-hanju
Hi,
On Mon, Feb 02, 2015 at 07:58:59PM +0100, Pali Rohár wrote:
> On Monday 02 February 2015 19:54:58 Felipe Balbi wrote:
> > Hi,
> >
> > On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote:
> > > This patch adds removable mass storage support to g_nokia
> > > gadget (for N900). It means t
Hmm. I don't disagree, but would like some more feedback.
Davidlohr - you were the person to touch this function last (commit
30493cc9dddb: "lib/int_sqrt.c: optimize square root algorithm"), and
you did so for performance reasons. And in fact, when you did that,
you removed that initial loop:
-
On 2/2/2015 10:08 AM, Serge Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
>> I'm game to participate in such an effort. The POSIX scheme
>> is workable, but given that it's 20 years old and hasn't
>> developed real traction it's hard to call it successful.
> Over the years we've
On Monday 02 February 2015 19:54:58 Felipe Balbi wrote:
> Hi,
>
> On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote:
> > This patch adds removable mass storage support to g_nokia
> > gadget (for N900). It means that at runtime block device
> > can be exported or unexported. So it does not
On 02/02, r...@redhat.com wrote:
>
> From: Rik van Riel
>
> With Oleg's patch "x86, fpu: don't abuse FPU in kernel threads if
> use_eager_fpu()", kernel threads no longer have an FPU state even
> on systems with use_eager_fpu()
>
> That in turn means that a task may still have its FPU state
> load
Instead of declaring a new type, define a new struct.
Signed-off-by: Ricardo Ribalda Delgado
---
v2: Suggested by Joe Perches
Replace unnecessary casting.
drivers/staging/unisys/visorutil/procobjecttree.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers
Hi,
On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote:
> This patch adds removable mass storage support to g_nokia gadget (for N900).
> It means that at runtime block device can be exported or unexported.
> So it does not export anything by default and thus allows to use MyDocs
> partitio
On 2/1/2015 7:55 PM, Wang, Yalin wrote:
This patch change non-atomic bitops,
add a if() condition to test it, before set/clear the bit.
so that we don't need dirty the cache line, if this bit
have been set or clear. On SMP system, dirty cache line will
need invalidate other processors cache line,
On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
> Quoting Casey Schaufler (ca...@schaufler-ca.com):
> > I'm game to participate in such an effort. The POSIX scheme
> > is workable, but given that it's 20 years old and hasn't
> > developed real traction it's hard to call it successful.
>
>
On Mon, Feb 02, 2015 at 12:43:50AM -0500, Peter Hurley wrote:
> On 02/02/2015 12:33 AM, Eddie Huang wrote:
> > Hi Peter,
> >
> > On Sun, 2015-02-01 at 21:24 -0800, Greg Kroah-Hartman wrote:
> >> On Mon, Feb 02, 2015 at 12:15:31AM -0500, Peter Hurley wrote:
> >>> On 02/01/2015 11:28 PM, Greg Kroah-
On Sun, Feb 1, 2015 at 9:54 PM, Dave Chinner wrote:
>
> Simple enough - the patch below removes the warning from generic/036
> for me.
So because this is a debugging thing, I'd actually prefer these
"sched_annotate_sleep()" calls to always come with short comments in
code why they exist and why
On Mon, Feb 02, 2015 at 09:08:30AM +0100, Michal Simek wrote:
> Hi Greg,
>
> On 01/31/2015 12:22 AM, Greg Kroah-Hartman wrote:
> > On Thu, Jan 15, 2015 at 03:55:07PM +0100, Michal Simek wrote:
> >> No functional changes.
> >>
> >> Signed-off-by: Michal Simek
> >> ---
> >
> > I can't take gpg-sig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/2015 01:34 PM, Oleg Nesterov wrote:
> On 02/02, r...@redhat.com wrote:
>>
>> From: Rik van Riel
>>
>> fpu.preload only gets set if new->thread.fpu_counter is already
>> larger than 5. Incrementing it further does absolutely nothing.
>> Re
On Mon, 2 Feb 2015, Ricardo Ribalda Delgado wrote:
> apic_force_enable is not defined for amd64.
>
> Without this patch:
>
> LD init/built-in.o
> arch/x86/built-in.o: In function `dtb_lapic_setup':
> kernel/devicetree.c:155:
> undefined reference to `apic_force_enable'
> Makefile:923: recip
On 02/02, r...@redhat.com wrote:
>
> From: Rik van Riel
>
> fpu.preload only gets set if new->thread.fpu_counter is already
> larger than 5. Incrementing it further does absolutely nothing.
> Remove those lines.
I _think_ that we increment it further on purpose. Note that fpu_counter
is "char", s
On Mon, 2015-02-02 at 19:26 +0100, Ricardo Ribalda Delgado wrote:
> Instead of declaring a new type, define a new struct.
[]
> diff --git a/drivers/staging/unisys/visorutil/procobjecttree.c
> b/drivers/staging/unisys/visorutil/procobjecttree.c
[]
> @@ -340,7 +341,9 @@ EXPORT_SYMBOL_GPL(visor_proc_
On 1/27/2015 9:31 AM, Guenter Roeck wrote:
On Tue, Jan 27, 2015 at 07:51:23PM +1100, Stephen Rothwell wrote:
Hi all,
Changes since 20150123:
The arm64 tree gained a conflict against Linus' tree.
The net-next tree gained conflicts against the arm-soc and net trees.
The drm-panel tree gained a
Instead of declaring a new type, define a new struct.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/staging/unisys/visorutil/procobjecttree.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/visorutil/procobjecttree.c
b/drivers/stagin
Fix minor code stype problems found by checkpatch.pl
Ricardo Ribalda Delgado (2):
staging/unisys/visorutil/procobjecttree: Code Style
staging/unisys/visorutil/procobjecttree: Replace typedef
drivers/staging/unisys/visorutil/procobjecttree.c | 23 +--
1 file changed, 13 in
Lines should not be over 80 characters
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/staging/unisys/visorutil/procobjecttree.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/visorutil/procobjecttree.c
b/drivers/staging/unisys/visorutil
From: Markus Elfring
Date: Mon, 2 Feb 2015 18:26:34 +0100
The pci_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
driver
On Mon, Feb 02, 2015 at 09:33:09AM +0530, Viresh Kumar wrote:
> On 1 February 2015 at 00:29, Eduardo Valentin wrote:
> > From: Arnd Bergmann
> >
>
> Acked-by: Viresh Kumar
Thanks!
>
> Now as these are all compilable as modules, should we look into the drivers as
> well to see what they ar
On Mon, Feb 02, 2015 at 06:08:17PM +, Marc Zyngier wrote:
> Hi Russell,
>
> On 02/02/15 16:33, Russell King - ARM Linux wrote:
> > What your change would mean is that the IRQs currently being programmed
> >> = 16 would be programmed into with numbers with 16 removed from them.
> > This means t
Ivan,
On Mon, Feb 02, 2015 at 05:19:30PM +0200, Ivan T. Ivanov wrote:
> Add support for the temperature alarm peripheral found inside
> Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
> peripheral outputs a pulse on an interrupt line whenever the
> thermal over temperature stage va
* Roger Quadros [150126 01:23]:
> On 24/01/15 22:28, Semen Protsenko wrote:
> > Fix sparse warning:
> > warning: symbol 'gpmc_cs_get_name' was not declared. Should it be static?
> >
> > Signed-off-by: Semen Protsenko
>
> Acked-by: Roger Quadros
Roger is going to queue this, so:
Acked-by: T
On 01/29/2015 05:33 PM, Rik van Riel wrote:
>> > Hmm, if the the thread was not using the FPU, and this fails to
>> > save anything in to the xsave_buf, what will bndcsr point to?
> If the thread was not using the FPU, can we reach the
> bound range exception?
>
> I believe the MPX feature uses in
Quoting Andy Lutomirski (l...@amacapital.net):
> On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn wrote:
> > A key concept behind posix capabilities is that the privilege comes from
> > both the person and the file being executed. As you say below basically
> > anything can be executed by the program
Hi Russell,
On 02/02/15 16:33, Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2015 at 02:51:23PM +, Marc Zyngier wrote:
>> void __weak pcibios_update_irq(struct pci_dev *dev, int irq)
>> {
>> -dev_dbg(&dev->dev, "assigning IRQ %02d\n", irq);
>> -pci_write_config_byte(dev, PCI_INTE
Quoting Casey Schaufler (ca...@schaufler-ca.com):
> I'm game to participate in such an effort. The POSIX scheme
> is workable, but given that it's 20 years old and hasn't
> developed real traction it's hard to call it successful.
Over the years we've several times discussed possible reasons for th
From: Rik van Riel
With Oleg's patch "x86, fpu: don't abuse FPU in kernel threads if
use_eager_fpu()", kernel threads no longer have an FPU state even
on systems with use_eager_fpu()
That in turn means that a task may still have its FPU state
loaded in the FPU registers, if the task only got int
On Mon, Feb 2, 2015 at 5:34 AM, Josh Boyer wrote:
> Hi Sasha and John,
>
> As we rolled out 3.18.5 in Fedora, we've had a number of people
> complain about chrony no longer working when they reboot. It seems
> the calls to adjtimex chrony is making are failing, and then it fails
> to start. Look
From: Rik van Riel
Replace magic assignments of fpu.last_cpu = ~0 with more explicit
disable_task_lazy_fpu_restore calls.
This also fixes the lazy FPU restore disabling in drop_fpu, which
only really works when !use_eager_fpu(). This is fine for now,
because fpu_lazy_restore() is only used when
These go on top of Oleg's patches.
The mechanism to disable lazy FPU restore is inscrutible
in several places, and dubious at best in one.
These patches make things explicit.
They also get rid of some apparently useless or redundant
code, and make fpu_lazy_restore work when in eager FPU mode.
-
From: Rik van Riel
fpu.preload only gets set if new->thread.fpu_counter is already
larger than 5. Incrementing it further does absolutely nothing.
Remove those lines.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/fpu-internal.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x
From: Rik van Riel
Use an explicit if/else branch after __save_init_fpu(old) in
switch_fpu_prepare. This makes substituting the assignment
with a call to task_disable_lazy_fpu() in the next patch easier
to review.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/fpu-internal.h | 5 +++--
From: Rik van Riel
Currently there are a few magic assignments sprinkled through the
code that disable lazy FPU state restoring, some more effective than
others, and all equally mystifying.
It would be easier to have a helper to explicitly disable lazy
FPU state restoring for a task.
Signed-off
From: Rik van Riel
We need another lazy restore related function, that will be called
from a function that is above where the lazy restore functions are
now. It would be nice to keep all three functions grouped together.
Signed-off-by: Rik van Riel
---
arch/x86/include/asm/fpu-internal.h | 36
On Mon, 2015-02-02 at 17:26 +0100, h...@lst.de wrote:
> On Mon, Feb 02, 2015 at 03:30:27PM +, James Bottomley wrote:
> > Cc added for linux-scsi, since this is the origin of the problem. How
> > important is bisectability in this? It won't affect any non-embedded
> > user, since most don't bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2015 04:46 PM, Dave Hansen wrote:
> On 01/30/2015 09:49 AM, r...@redhat.com wrote:
>> @@ -440,8 +440,9 @@ static inline fpu_switch_t
>> switch_fpu_prepare(struct task_struct *old, struct ta
>> new->thread.fpu_counter > 5); if (__thread_has_fp
On 2/2/2015 8:21 AM, Christoph Lameter wrote:
> Linux capabilities suffer from the problem that they are not inheritable
> like regular process characteristics under Unix. This is behavior that
> is counter intuitive to the expected behavior of processes in Unix.
http://wt.tuxomania.net/publicatio
On Wed, Jan 28, 2015 at 04:50:44PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 28, 2015 at 01:24:11AM +0100, Frederic Weisbecker wrote:
> > +++ b/kernel/sched/core.c
> > @@ -2760,7 +2760,6 @@ static void __sched __schedule(void)
> > struct rq *rq;
> > int cpu;
> >
> > - preempt_disable()
On Mon, Feb 02, 2015 at 09:46:46AM -0800, Mike Turquette wrote:
> This looks like mis-matched enable/disable calls. We now have unique
> struct clk pointers for every call to clk_get. I haven't yet looked
> through the hwmod code but I have a feeling that we're doing something
> like this:
>
>
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all the instructions from the beginning
of the function until the given address. The code might be modified
by another Kprobe. In this case, the current code is read into a buffer,
int3 breakpoint is repl
te"
> > >> >> > parameter,
> > >> >> > e.g. on r8a7791:
> > >> >>
> > >> >> Hmm.. I wonder if we should assign core->req_rate to be the same as
> > >> >> core->rate during __clk_init()? Tha
Based on Boris Brezillion's work this is a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initially configure specific GPIO
when the GPIO controller is probed.
The actual DT scanning to collect the GPIO specific data is performed
as part of gpiochip_add().
The
Add GPIO hogging documentation to gpio.txt
Signed-off-by: Benoit Parrot
Reviewed-by: Alexandre Courbot
---
Documentation/devicetree/bindings/gpio/gpio.txt | 30 +
1 file changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentat
This patch set re-introduces the gpio hogging concept first
presented by Boris Brezillion.
This patch set provides a way to initially configure specific GPIO
when the GPIO controller is probed.
The actual DT scanning to collect the GPIO specific data is performed
as part of of_gpiochip_add().
Th
On 31 Jan 2015, n...@esperi.org.uk told this:
> I'll let it run overnight and give it a reboot in the morning.
Alas, my latest reboot hit:
[ 215.245158] BUG: unable to handle kernel NULL pointer dereference at 0004
[ 215.251602] IP: [] rpc_new_client+0x13b/0x1f2
[ 215.251602] *pde = 00
The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce:
Linux 3.19-rc6 (2015-01-25 20:04:41 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git
tags/please-pull-fixmcelog
for you to fetch changes up to 728b6f14abaa7f
On 2 Feb 2015, Myron Stowe verbalised:
> Nix:
>
> Thanks for the work you've already done with the bisection. Let's see
> if we can get to the bottom of this. Would you capture two couple sets
> of logs, one without the issue and another set with the commit at issue
> included for comparison.
>
On Mon, Feb 02, 2015 at 04:42:40PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 02, 2015 at 01:33:14AM -0500, Vince Weaver wrote:
> > [407484.309136] [ cut here ]
> > [407484.588602] <>[]
> > perf_prepare_sample+0x2ec/0x3c0
> > [407484.597358] [] __perf_event_overflow+
On Mon, Feb 02, 2015 at 11:56:09PM +0900, Namhyung Kim wrote:
> Hi Jiri and Adrian,
>
> On Mon, Feb 2, 2015 at 9:13 PM, Jiri Olsa wrote:
> > On Mon, Feb 02, 2015 at 02:07:27PM +0200, Adrian Hunter wrote:
> >
> > SNIP
> >
> >> >>
> >> >> Why not make it the same as all the other data. i.e. find th
On Wed, Jan 28, 2015 at 04:46:37PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 28, 2015 at 01:24:12AM +0100, Frederic Weisbecker wrote:
> > PREEMPT_ACTIVE implies non-preemptible context and thus atomic context
> > despite what in_atomic*() APIs reports about it. These functions
> > shouldn't ignore
On Mon, Feb 02, 2015 at 07:14:31PM +0200, grygorii.stras...@linaro.org wrote:
> From: Grygorii Strashko
>
> Setting a dev_pm_ops suspend/resume pair but not a set of
> hibernation functions means those pm functions will not be
> called upon hibernation.
> Fix this by using SIMPLE_DEV_PM_OPS, whic
301 - 400 of 835 matches
Mail list logo
