On Tue, 05 May 2015, Julia Lawall wrote:
>
>
> On Tue, 5 May 2015, Nicholas Mc Guire wrote:
>
> > On Tue, 05 May 2015, Julia Lawall wrote:
> >
> > > > +@match@
> > > > +identifier f,ret;
> > > > +position p;
> > > > +type T1,T2;
> > > > +@@
> > > > +
> > > > +T1 f(...) {
> > > > + T2 ret;
> > >
On Fri, 08 May 2015, Geert Uytterhoeven wrote:
> On Thu, May 7, 2015 at 9:01 AM, Lee Jones wrote:
> >> I have a follow up question regarding interrupt. I see many I2C bus drivers
> >> request interrupt with flag = 0. Why not using IRQF_SHARED?
> >
> > Probably because that particular IRQ is only
On Thu, May 7, 2015 at 9:40 PM, Steven Rostedt wrote:
> [ cut here ]
> WARNING: CPU: 2 PID: 0 at
> /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_uncore.c:566
> hsw_unclaimed_reg_debug.isra.10+0x6c/0x84()
> Unclaimed register detected before writing
Thanks. I'm leaning towards tossing your patch 2/2 and replacing it with
> >>> my patch and a note that it's based on an earlier patch from you.
> >> It appears this has landed in linux-next in the form of 882667c1fcf1
> >> clk: prevent orphan clocks from being
The binding uses assigned-clock-parents when it should use
assigned-clock-rates. Furthermore, the part that describes how
they relate to the assigned-clocks property is not clear about
what is related. Correct and clarify this part of the binding.
Reported-by: Krzysztof Kozlowski
Signed-off-by: S
On Thu, 07 May 2015, Peter Griffin wrote:
> Hi Lee,
>
> On Thu, 07 May 2015, Lee Jones wrote:
>
>
>
> > > > Required properties
> > > >
> > > > -- compatible : Must be one of: "st,stih407-lpc" "st,stih416-lpc"
> > > > - "st,stih415-lpc" "st,stid127-lpc"
> >
On Thu, May 7, 2015 at 9:01 AM, Lee Jones wrote:
>> I have a follow up question regarding interrupt. I see many I2C bus drivers
>> request interrupt with flag = 0. Why not using IRQF_SHARED?
>
> Probably because that particular IRQ is only used by the I2C
> Controller. I'm not exactly sure that y
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
In addition, an asynchronous API call of get_blocking_random_bytes_cb
is provided which returns immediately to the caller after submitting
the re
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now
The CPU Jitter RNG provides a source of good entropy by
collecting CPU executing time jitter. The entropy in the CPU
execution time jitter is magnified by the CPU Jitter Random
Number Generator. The CPU Jitter Random Number Generator uses
the CPU execution timing jitter to generate a bit stream
whi
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
doe
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
On Sun, Jan 26, 2014 at 4:08 PM, Pavel Machek wrote:
> Dunno. Config option plus sysfs attribute is overdoing it a bit.
Agreed.
Have discussed w/ Rafael, and current plan is to simply delete.
Updated patch on the way...
thanks,
Len Brown, Intel Open Source Technology Center
--
To unsubscribe fr
From: Len Brown
Replace the hard-coded mdelay(10) in cpu_up() to a variable udelay.
Add a boot-time override, "cpu_init_udelay=N"
Default unchanged at 10ms on all systems.
Signed-off-by: Len Brown
---
Documentation/kernel-parameters.txt | 6 ++
arch/x86/kernel/smpboot.c | 28 +
From: Len Brown
Modern processor familes are on a white-list to remove
the costly cpu_init_udelay 1. Unknown processor families
get the traditional 10ms delay in cpu_up().
This seemed more efficient than forcing modern processors
to exhaustively search a black-list having all the old
proces
Thanks for testing, Aravind, Borislav,
I went with Ingo's suggestion to made this a quirk.
However, I went with a white-list instead of a black-list,
because fewer comparisons are needed for modern processors.
Families are added infrequently, and finally, we get the option
to stick something other
* Andy Lutomirski wrote:
> > So do you mean:
> >
> >this_cpu_set(rcu_state) = IN_KERNEL;
> >...
> >this_cpu_inc(rcu_qs_ctr);
> >this_cpu_set(rcu_state) = IN_USER;
> >
> > ?
> >
> > So in your proposal we'd have an INC and two MOVs. I think we can make
> > it just two simple store
On Fri, May 8, 2015 at 3:54 AM, Guenter Roeck wrote:
> On Thu, May 07, 2015 at 04:47:15PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20150506:
>>
>> The ext4 tree gained a build failure so I used the version from
>> next-20150506.
>>
>> The vfs tree gained a conflict against the
On Thu, May 07, 2015 at 01:22:11PM -0400, Peter Hurley wrote:
> On 05/07/2015 01:09 PM, Maciej W. Rozycki wrote:
> > On Mon, 4 May 2015, Peter Hurley wrote:
> >
> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
> the message is new but not the behavior.
> >>>
> >>>
On Sat, Apr 11, 2015 at 09:40:34PM +0200, Robert Jarzmik wrote:
> This is a new driver for pxa SoCs, which is also compatible with the former
> mmp_pdma.
The rationale is fine, is there a plan to remove old mmp_pdma then?
> +config PXA_DMA
> + bool "PXA DMA support"
no prompt?
> +
> +#define
On Tue, 2015-05-05 at 02:06 +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 28, 2015 06:22:05 PM Dan Williams wrote:
> > On Tue, Apr 28, 2015 at 5:25 PM, Rafael J. Wysocki
> > wrote:
> > > On Tuesday, April 28, 2015 02:24:12 PM Dan Williams wrote:
> > >> Changes since v1 [1]: Incorporates fee
* Hemant Kumar wrote:
>
> On 05/08/2015 09:58 AM, Ingo Molnar wrote:
> >* Hemant Kumar wrote:
> >
> >> # perf kvm stat report -p 60515
> >>Analyze events for pid(s) 60515, all VCPUs:
> >>
> >>VM-EXITSamples Samples% Time%Min Time Max
> >> Time Avg
On Thu, May 07, 2015 at 02:49:39PM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > The TIF_RCU_QS thing is just a fancy way for synchronize_rcu()
> > (being executed on some other CPU not doing RT work) to
> > intelligently wait for the remote (RT work doing) CPU to finish
> > execut
On 05/08/2015 09:58 AM, Ingo Molnar wrote:
* Hemant Kumar wrote:
# perf kvm stat report -p 60515
Analyze events for pid(s) 60515, all VCPUs:
VM-EXITSamples Samples% Time%Min Time Max
Time Avg time
H_DATA_STORAGE 500635.30% 0.13%
On 05/07/2015 09:14 PM, NeilBrown wrote:
> On Wed, 6 May 2015 23:34:17 -0700 Ming Lin wrote:
>
>> If a read request fits entirely in a chunk, it will be passed directly to the
>> underlying device (providing it hasn't failed of course). If it doesn't fit,
>> the slightly less efficient path tha
For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.
./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
./perf report -f
On 05/07/2015 20:52, Nicholas Krause wrote:
> This fixes the make error when building the ip32_defconfig
> configuration due to using sgio2_cmos_devinit rather then
> the correct function,sgio2_rtc_devinit in a device_initcall
> below this function's definition.
>
> Signed-off-by: Nicholas Krause
For arm & arm64, when tracing with tracepoint events, the IP and cpsr
are set to 0, preventing the perf code parsing the callchain and
resolving the symbols correctly.
These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary registe
For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.
./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
./perf repo
Consider "(u64)insn1.imm << 32 | imm" in the arm64 JIT. Since imm is
signed 32-bit, it is sign-extended to 64-bit, losing the high 32 bits.
The fix is to convert imm to u32 first and zero-extend it to u64.
Also extend test_bpf to catch this JIT bug; the interpreter is correct.
Before:
test_bpf:
Al,
I was wondering about the struct page rules of
iov_iter_get_pages_alloc(), used in various places. There's no
documentation whatsoever in lib/iov_iter.c, nor in
include/linux/uio.h, and the changelog that introduced it only says:
commit 91f79c43d1b54d7154b118860d81b39bad07dfff
Author: A
Hi all,
Changes since 20150507:
New tree : rtc
The ext4 tree still had its build failure so I used the version from
next-20150506.
Non-merge commits (relative to Linus' tree): 2631
2535 files changed, 117241 insertions(+), 49326 dele
On Fri, May 08, 2015 at 03:28:00PM +1000, NeilBrown wrote:
> On Wed, 6 May 2015 17:45:49 +0800 Yuanhan Liu
> wrote:
>
> > Move the code that put one idle sh(hot in cache, but happens to be
> > zero referenced) back to active stage to __find_stripe(). Because
> > that's what need to do every time
On Thursday 07 May 2015 11:49 AM, Heikki Krogerus wrote:
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
set optimized value to it. In order to not loose the
optimized value, the driver stores it during probe and
restores it every
On Friday 08 May 2015 12:25 AM, Felipe Balbi wrote:
On Thu, May 07, 2015 at 09:19:31AM +0300, Heikki Krogerus wrote:
ULPI PHYs need to be bound to their controllers with a
lookup. This adds helpers that the ULPI drivers can use to
do both, the registration of the PHY and the lookup, at the
sam
EP-2DAD0AFA905A4ACB804C4F82A001242F
Hi Andrew,
Presently in oom_kill.c we calculate badness score of the victim task as per
the present RSS counter value of the task.
RSS counter value for any task is usually '[Private (Dirty/Clean)] + [Shared
(Dirty/Clean)]' of the task.
We have encountered a
Update FALLOC_FL_INSERT_RANGE flag in fallocate.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
man2/fallocate.2 | 89
1 file changed, 84 insertions(+), 5 deletions(-)
diff --git a/man2/fallocate.2 b/man2/fallocate.2
index
> -Original Message-
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> Sent: Thursday, May 07, 2015 6:32 PM
> To: Mehresh Ramneek-B31383; linux-kernel@vger.kernel.org
> Cc: ba...@ti.com; linux-...@vger.kernel.org; st...@rowland.harvard.edu;
> gre...@linuxfoundation.org
On Wed, 6 May 2015 17:45:49 +0800 Yuanhan Liu
wrote:
> Move the code that put one idle sh(hot in cache, but happens to be
> zero referenced) back to active stage to __find_stripe(). Because
> that's what need to do every time you invoke __find_stripe().
>
> Moving it there avoids duplicate code
On Thu, May 07, 2015 at 09:27:45PM -0700, Doug Anderson wrote:
> If you've got code that does this in a tight loop
> 1. Open watchdog
> 2. Send 'expect close'
> 3. Close watchdog
> ...you'll eventually trigger a watchdog reset. You can reproduce this
> by using daisydog (1) and running:
>
On Tue, May 05, 2015 at 12:46:32PM +0100, Srinivas Kandagatla wrote:
> Hi Stephen,
>
> Sorry I took so long to reply.
>
>
> On 09/04/15 15:45, Stephen Boyd wrote:
> >On 04/07, Srinivas Kandagatla wrote:
> >>On 07/04/15 19:45, Stephen Boyd wrote:
> >>>On 03/30, Srinivas Kandagatla wrote:
> >>>
>
On Thu, May 07, 2015 at 09:27:44PM -0700, Doug Anderson wrote:
> Right now the dw_wdt uses a spinlock to protect dw_wdt_open(). The
> problem is that while holding the spinlock we call:
> -> dw_wdt_set_top()
>-> dw_wdt_top_in_seconds()
> -> clk_get_rate()
> -> clk_prepare_lock()
It seems odd to me to use BUG() for what you appear to be using it for..
not that I know exactly what that it mind you, but when you said when
some other gizmo in your box has a problem you crash the kernel, my head
tilted to the side - surely there's a more controlled response possible
than poking
On Thu, May 07, 2015 at 08:18:43PM +0100, One Thousand Gnomes wrote:
> > We could keep heap metadata as R/O and only make it R/W inside of
> > malloc() itself to catch corruption more quickly.
>
> If you implement multiple malloc pools you can chop up lots of stuff.
>
> In library land it isn't j
Hi Walleij,
Acked-by: Sonic Zhang
Sonic
On Thu, May 7, 2015 at 5:53 PM, Linus Walleij wrote:
> While the pinmux_ops are ideally just a vtable for pin mux
> calls, the "strict" setting belongs so intuitively with the
> pin multiplexing that we should move it here anyway. Putting
> it in the to
I've had reports of UEFI platforms failing iSCSI boot in various
configurations, that ended up being caused by network initialization
scripts getting tripped up by unexpected null addresses (0.0.0.0) being
reported for gateways, dhcp servers, and dns servers.
The tianocore EDK2 iSCSI driver genera
On Fri, 2015-05-08 at 04:16 +, Oza (Pawandeep) Oza wrote:
> So Mike, is this reason strong enough for you ?
Nope. I think you did the right thing in removing your dependency on
jiffies reliability in a dying box. You don't have to convince me of
anything though, CC timer subsystem maintainer
On 4 May 2015 at 14:24, Shilpasri G Bhat wrote:
> This patchset intends to add frequency throttle reporting mechanism
> to powernv-cpufreq driver when OCC throttles the frequency. OCC is an
> On-Chip-Controller which takes care of the power and thermal safety of
> the chip. The CPU frequency can b
bdi_unregister() now contains very little functionality.
It contains a "WARN_ON" if bdi->dev is NULL. This warning is of no
real consequence as bdi->dev isn't needed by anything else in the function,
and it triggers if
blk_cleanup_queue() -> bdi_destroy()
is called before bdi_unregister, whi
Dear Kernel Maintainer,
Submitting the following information for kernel bug review.
[1.] Lenovo SL510 will not resume from suspend
[2.] When using the following three steps to suspend the laptop the will
not resume from suspend. The suspend light flash rapidly instead of slowly.
1. systemctl susp
On Thu, 7 May 2015 21:27:44 -0700
Doug Anderson wrote:
> Right now the dw_wdt uses a spinlock to protect dw_wdt_open(). The
> problem is that while holding the spinlock we call:
> -> dw_wdt_set_top()
>-> dw_wdt_top_in_seconds()
> -> clk_get_rate()
> -> clk_prepare_lock()
>
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, May 07, 2015 8:16 PM
> To: Mehresh Ramneek-B31383
> Cc: linux-kernel@vger.kernel.org; ba...@ti.com; linux-...@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: Re: [PATCH 02/10] drivers:hos
* One Thousand Gnomes wrote:
> On Thu, 7 May 2015 21:26:20 +0200
> Ingo Molnar wrote:
>
> >
> > * One Thousand Gnomes wrote:
> >
> > > > We could keep heap metadata as R/O and only make it R/W inside of
> > > > malloc() itself to catch corruption more quickly.
> > >
> > > If you implement
On 05/07/2015 09:27 PM, Doug Anderson wrote:
Right now the dw_wdt uses a spinlock to protect dw_wdt_open(). The
problem is that while holding the spinlock we call:
-> dw_wdt_set_top()
-> dw_wdt_top_in_seconds()
-> clk_get_rate()
-> clk_prepare_lock()
-> mutex_lo
On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
> On Wed, 29 Apr 2015 21:28:38 +0530
> Shreyas B Prabhu wrote:
>
>>
>>
>> On Wednesday 29 April 2015 08:48 PM, Steven Rostedt wrote:
>>> On Wed, 29 Apr 2015 20:19:28 +0530
>>> Shreyas B Prabhu wrote:
>>>
IIUC there is no existing
On Sat, Apr 11, 2015 at 09:40:32PM +0200, Robert Jarzmik wrote:
> Document the new design of the pxa dma driver.
>
> Signed-off-by: Robert Jarzmik
> ---
> Documentation/dmaengine/pxa_dma.txt | 157
>
> 1 file changed, 157 insertions(+)
> create mode 100644
This is a new one I think, I hit it on the haswell machine running
4.1-rc2.
The backtrace is complex enough I'm not really sure what's going on here.
The fuzzer has been having weird issues where it's been getting
overflow signals from invalid fds. This seems to happen
when an overflow signal
* Hemant Kumar wrote:
> # perf kvm stat report -p 60515
> Analyze events for pid(s) 60515, all VCPUs:
>
>VM-EXITSamples Samples% Time%Min Time Max
> Time Avg time
>
> H_DATA_STORAGE 500635.30% 0.13% 1.94us 49.46us
> 12.3
If you've got code that does this in a tight loop
1. Open watchdog
2. Send 'expect close'
3. Close watchdog
...you'll eventually trigger a watchdog reset. You can reproduce this
by using daisydog (1) and running:
while true; do daisydog -c > /dev/null; done
The problem is that each time y
Right now the dw_wdt uses a spinlock to protect dw_wdt_open(). The
problem is that while holding the spinlock we call:
-> dw_wdt_set_top()
-> dw_wdt_top_in_seconds()
-> clk_get_rate()
-> clk_prepare_lock()
-> mutex_lock()
Locking a mutex while holding a spinlock is n
On Thu, May 07, 2015 at 10:04:32PM +0200, Greg Kroah-Hartman wrote:
> On Thu, May 07, 2015 at 03:06:52PM +0530, Sudip Mukherjee wrote:
> > the previous patch of the series made this variable unused.
>
> What do you mean? There was only one other patch in this series, never
> send a patch that cau
On Thu, 7 May 2015, Peter Zijlstra wrote:
> Indeed so; and we can make an analogous argument for hwc. However:
>
> > I think it is more likely related to the bitmask (idxmsk). But then
> > it is always allocated with the constraint even with the HT bug
> > workaround. So most, likely the index
On Thu, May 07, 2015 at 10:18:49AM +0200, Paul Bolle wrote:
> Just a nit: a license mismatch.
>
> On Wed, 2015-05-06 at 01:37 -0700, Gregory Fong wrote:
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-brcmstb.c
>
> > + * This program is free software; you can redistribute it and/or
> > + * modify i
On Fri, 1 May 2015, Ingo Molnar wrote:
> So fffe corresponds to 2 events left until overflow,
> right? And on Haswell we don't set x86_pmu.limit_period AFAICS, so we
> allow these super short periods.
>
> Maybe like on Broadwell we need a quirk on Nehalem/Haswell as well,
> one sim
So Mike, is this reason strong enough for you ?
I understand your point: solve the BUG, and I do tend to agree with you.
But by design and implementation, the BUG() is just a beginning of the end for
dying kernel.
And what happens in between this 'the beginning' and 'the end' is not less
import
On Wed, 6 May 2015 23:34:17 -0700 Ming Lin wrote:
> If a read request fits entirely in a chunk, it will be passed directly to the
> underlying device (providing it hasn't failed of course). If it doesn't fit,
> the slightly less efficient path that uses the stripe_cache is used.
> Requests that
On 5/7/15 5:37 PM, Suravee Suthikulpanit wrote:
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
This patch simplifies this process by introducing a new device
prop
Initial commit for a new SoC family, UniPhier, developed by
Socionext Inc. (formerly, System LSI Business Division of
Panasonic Corporation).
This commit includes a minimal set of components for booting the
kernel, including SMP support.
Signed-off-by: Masahiro Yamada
---
Changes in v7: None
Ch
Initial device trees for UniPhier SoCs: PH1-sLD3, PH1-LD4, PH1-Pro4,
and PH1-sLD8.
Signed-off-by: Masahiro Yamada
---
Changes in v7:
- Remove redundant "fifo-size" from the 16550A uart node
Changes in v6:
- Remove redundant interrupt-parent property from timer nodes.
Changes in v5: None
Ch
Signed-off-by: Masahiro Yamada
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1939513..3c31a27 100644
--- a/MAINTAI
Hi Dave,
Thanks for your comment!
On Fri, May 8, 2015 at 6:20 AM, Dave Chinner wrote:
> On Thu, May 07, 2015 at 08:32:39PM +0800, Ming Lei wrote:
>> On Thu, May 7, 2015 at 3:24 PM, Christoph Hellwig wrote:
>> >> @@ -441,6 +500,12 @@ static void do_loop_switch(struct loop_device *lo,
>> >> stru
Add UniPhier, a new citizen in the ARM multi platform.
Signed-off-by: Masahiro Yamada
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --gi
This is an initial series for supporting Socionext UniPhier SoCs,
based on ARM Cortex-A9, mainly used for digital TVs, video recorders, etc.
Masahiro Yamada (4):
ARM: UniPhier: add basic support for UniPhier architecture
ARM: multi_v7_defconfig: enable UniPhier SoC family
ARM: dts: UniPhier
On 08.05.2015 13:01, Anand Moon wrote:
> Hi Krysztof,
>
> Actually the patch is based on https://lkml.org/lkml/2015/4/3/389
> I don't know how to measure the energy consumption when compared to
> cpufreq-exynos.
It does not have to be energy consumption. It may be something else
visible, like wro
The port.type has already been set by of_platform_serial_setup()
called from a few lines above.
Setting it to the same value is redundant.
Signed-off-by: Masahiro Yamada
---
drivers/tty/serial/of_serial.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/of_serial.c b/driver
Hi Krysztof,
Actually the patch is based on https://lkml.org/lkml/2015/4/3/389
I don't know how to measure the energy consumption when compared to
cpufreq-exynos.
I will update the commit log and resend it with you review.
-Anand Moon
On 8 May 2015 at 05:44, Krzysztof Kozlowski wrote:
> 201
Hi,
On Thu, May 7, 2015 at 6:47 PM, Guenter Roeck wrote:
> On 05/07/2015 03:09 PM, Doug Anderson wrote:
>>
>> Right now the dw_wdt uses a spinlock to protect dw_wdt_open(). The
>> problem is that while holding the spinlock we call:
>> -> dw_wdt_set_top()
>> -> dw_wdt_top_in_seconds()
>>
On 05/08/2015 02:29 AM, Rafael J. Wysocki wrote:
> On Thursday, May 07, 2015 05:49:22 PM Preeti U Murthy wrote:
>> On 05/05/2015 02:11 PM, Preeti U Murthy wrote:
>>> On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
Hi Preeti,
On 05/05/2015 09:30 AM, Preeti U Murthy wrote:
> Hi Shi
On Wed, May 06, 2015 at 12:13:42PM +0200, Maxime Ripard wrote:
> On Wed, May 06, 2015 at 11:31:31AM +0200, Jens Kuske wrote:
> > The H3 SoC has the same dma engine as the A31 (sun6i), with a
> > reduced amount of endpoints and physical channels. Add the proper
> > config data and compatible string
On Thu, May 07, 2015 at 12:48:34PM +0300, Peter Ujfalusi wrote:
> On 05/04/2015 08:38 AM, Vinod Koul wrote:
> > On Thu, Apr 09, 2015 at 12:35:49PM +0300, Peter Ujfalusi wrote:
> >> +int omap_dmaxbar_init(void)
> >> +{
> >> + return platform_driver_register(&ti_dma_xbar_driver);
> >> +}
> >> +arch_
On May 8, 2015 8:11 AM, "Dave Chinner" wrote:
>
> On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote:
> > On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> > > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> > > > Add the O_NOMTIME flag which prevents mtime from
On Thu, May 7, 2015 at 9:21 AM, H.J. Lu wrote:
> On Thu, May 7, 2015 at 4:52 AM, Jan Beulich wrote:
> On 07.05.15 at 08:02, wrote:
>>> AFAICT gas will produce relocations for jumps to global labels in the
>>> same file. This doesn't seem directly harmful to me, except that, on
>>> x86, it f
In glibc 2.21 (and several previous), a call to opendir() will
result in a 32K (BUFSIZ*4) buffer being allocated and passed to
getdents.
However a call to fdopendir() results in an 'fstat' request to
determine block size and a matching buffer allocated for subsequent
use with getdents. This will
On 2015/5/8 10:29, Yun Wu (Abel) wrote:
> Hi Gerry,
> On 2015/5/4 11:15, Jiang Liu wrote:
>
>> NUMA node information is per-irq instead of per-irqchip, so move it into
>> struct irq_common_data.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> arch/sh/kernel/irq.c |2 +-
>> arch/x86/kernel
On Thu, 2015-05-07 at 13:31 -0700, Jacob Pan wrote:
> On Fri, 8 May 2015 03:39:04 +0930
> Anand Moon wrote:
>
> > To install tmon we issue "make install" which produces bellow error.
> >
> looks good, there is no config file for now.
>
> Thanks for the fix.
> Acked-by: Jacob Pan
>
patch appl
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim
Acked-by: Seung-Woo Kim
Reviewed-by: Varka Bhadram
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ktd
This patch adds vendor prefix for Kinetic technologies
Signed-off-by: Ingi Kim
Acked-by: Rob Herring
Acked-by: Seung-Woo Kim
Reviewed-by: Varka Bhadram
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindin
This patch adds ktd2692 Flash LED driver with LED Flash class
Change in v8:
- Add led-max-microamp mandatory property for LEDs current
base on Jacek's patch [1]
patch [1] [PATCH v6] DT: leds: Improve description of
flash LEDs related properties
- Fix b
This patch adds the device tree bindings for ktd2692 flash LEDs.
Add Optional properties of child node for Flash LED
Signed-off-by: Ingi Kim
Acked-by: Seung-Woo Kim
Reviewed-by: Varka Bhadram
---
.../devicetree/bindings/leds/leds-ktd2692.txt | 50 ++
1 file changed, 50
Currently, a fill-up partition (indicated by '-') must be the last
partition, and no other partitions can go after it. Change the
cmdlinepart parsing code to allow a fill-up partition at any point.
This is useful, for example, if you want to reserve a partition at the
end of the flash where the ba
On 04/30/2015 07:36 PM, Paolo Bonzini wrote:
smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages
should not be reused for different values of it. Thus, it has to be
added to the mask in kvm_mmu_pte_write.
Good catch!
Reviewed-by: Xiao Guangrong
--
To unsubscribe from th
On Thu, 7 May 2015 15:09:24 -0700
Doug Anderson wrote:
> If you've got code that does this in a tight loop
> 1. Open watchdog
> 2. Send 'expect close'
> 3. Close watchdog
> ...you'll eventually trigger a watchdog reset. You can reproduce this
> by using daisydog (1) and running:
> while
On Thu, May 07, 2015 at 12:53:46PM -0700, Andy Lutomirski wrote:
> On Thu, May 7, 2015 at 12:09 PM, Richard Weinberger
> wrote:
> > On Thu, May 7, 2015 at 7:20 PM, Zach Brown wrote:
> >> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> >>> On Wed, May 06, 2015 at 03:00:12PM -0700,
On Thu, 7 May 2015 15:09:23 -0700
Doug Anderson wrote:
> Right now the dw_wdt uses a spinlock to protect dw_wdt_open(). The
> problem is that while holding the spinlock we call:
> -> dw_wdt_set_top()
>-> dw_wdt_top_in_seconds()
> -> clk_get_rate()
> -> clk_prepare_lock()
>
On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote:
> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> > > Add the O_NOMTIME flag which prevents mtime from being updated which can
> > > greatly reduce the IO over
On a system that has multiple devices on the mmc bus the host can
block on the mutex that protects access to the bus. Some operations
require the status of the device to be polled to see when the device
finishes executing the previous command that was sent to it (if
there is no busy detection in ha
On 2015/5/4 11:15, Jiang Liu wrote:
[...]
> diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
> index dd1109fb241e..3010e99abf3e 100644
> --- a/include/linux/irqdesc.h
> +++ b/include/linux/irqdesc.h
> @@ -47,6 +47,7 @@ struct pt_regs;
> * @name:flow handler name for /pr
Hi Gerry,
On 2015/5/4 11:15, Jiang Liu wrote:
> NUMA node information is per-irq instead of per-irqchip, so move it into
> struct irq_common_data.
>
> Signed-off-by: Jiang Liu
> ---
> arch/sh/kernel/irq.c |2 +-
> arch/x86/kernel/apic/vector.c |8
> arch/x86/platform/u
On Thu, May 07, 2015 at 11:06:06AM -0400, Dan Streetman wrote:
>
> The crypto 842-nx has (significant) code in it to handle any alignment
> and length input buffers, to match them to what the driver requires.
> Would it be better to move that into the crypto code, so that any
> crypto compression
1 - 100 of 1072 matches
Mail list logo
