On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
> Il 26/09/2013 08:31, Michael Ellerman ha scritto:
> > Some powernv systems include a hwrng. Guests can access it via the
> > H_RANDOM hcall.
>
> Is there any reason to do this in the kernel?
It's less code, and it's faster :)
>
On 10/01/2013 05:22 PM, Charles Keepax wrote:
> On Tue, Oct 01, 2013 at 08:04:09AM +0900, Chanwoo Choi wrote:
>> On 09/30/2013 06:52 PM, Charles Keepax wrote:
>>> On Mon, Sep 30, 2013 at 08:37:30AM +0900, Chanwoo Choi wrote:
No, extcon-arizona driver don't currently support DT to get platform
On Thu, Sep 26, 2013 at 01:43:25PM +1000, Dave Chinner wrote:
> On Tue, Sep 24, 2013 at 09:20:50PM +0900, Akira Hayakawa wrote:
> > * Deferring ACK for barrier writes
> > Barrier flags such as REQ_FUA and REQ_FLUSH are handled lazily.
> > Immediately handling these bios badly slows down
* Peter Zijlstra wrote:
> On Tue, Oct 01, 2013 at 09:28:15AM +0200, Ingo Molnar wrote:
>
> > That I mostly agree with, except that without a serious usecase do we
> > have a guarantee that bugs in fancies queueing in rwsems gets ironed
> > out?
>
> Methinks mmap_sem is still a big enough
On Thu, Sep 26, 2013 at 06:01:27PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-09-26 at 16:31 +1000, Michael Ellerman wrote:
>
> > + pr_info("registered powernv hwrng.\n");
>
> First letter of a line should get a capital :-) Also since
> it's per-device, at least indicate the OF
On Tue, Oct 01, 2013 at 08:04:09AM +0900, Chanwoo Choi wrote:
> On 09/30/2013 06:52 PM, Charles Keepax wrote:
> > On Mon, Sep 30, 2013 at 08:37:30AM +0900, Chanwoo Choi wrote:
> >> No, extcon-arizona driver don't currently support DT to get platform data.
> >> I cannot find some dt function to
On Tue, Oct 01, 2013 at 09:48:02AM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Sat, Sep 28, 2013 at 11:55:26AM -0700, Linus Torvalds wrote:
> > > So if the primary reason for this is really just that f*cking anon_vma
> > > lock, then I would seriously suggest:
> >
> > I
On Tue, Oct 01, 2013 at 09:28:15AM +0200, Ingo Molnar wrote:
> That I mostly agree with, except that without a serious usecase do we have
> a guarantee that bugs in fancies queueing in rwsems gets ironed out?
Methinks mmap_sem is still a big enough lock to work out a locking
primitive :-)
In
On Wed, Sep 25, 2013 at 04:33:24PM +0200, Daniel Lezcano wrote:
> On 09/16/2013 11:44 AM, Uwe Kleine-König wrote:
> > Signed-off-by: Uwe Kleine-König
> > ---
> > Hello,
> >
> > I'm not sure that the way I implemented if a given timer is used as
> > clock_source or clock_event_device is robust.
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look at the following
patches:
[PATCH 0/3] WLAN support for
On Tue, Oct 01, 2013 at 09:31:24AM +0200, Andi Kleen wrote:
> Sorry I missed that. No change other than acks/rebase,
> so the previous version should be fine. Thanks.
Yeah, I didn't mail out and it hasn't landed it -tip yet. So you
couldn't have known.
> Outstanding TSX patches i have now
This patch fix validation of maxpacket value given in endpoint descriptor.
Add check of maxpacket for bulk endpoints. If maxpacket is not set in
descriptor, it's set to maximum value for given type on endpoint in used
speed.
Correct maxpacket value is:
FULL-SPEEDHIGH-SPEED
On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
> On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
> > How about no?
> >
> > We have a small number of MSIs available, limited by hardware &
> > firmware, if we don't impose a quota then the first device that
* Peter Zijlstra wrote:
> On Sat, Sep 28, 2013 at 11:55:26AM -0700, Linus Torvalds wrote:
> > So if the primary reason for this is really just that f*cking anon_vma
> > lock, then I would seriously suggest:
>
> I would still like to see the rwsem patches merged; even if we end up
> going back
On Wed, Sep 18, 2013 at 09:22:31AM -0500, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
> > On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
> > > How about no?
> > >
> > > We have a small number of MSIs available, limited by
On 09/27/2013 08:08 PM, Kevin Hilman wrote:
> Javier Martinez Canillas writes:
>
>> The GPIO OMAP controller pins can be used as IRQ and GPIO
>> independently so is necessary to keep track GPIO pins and
>> IRQ lines usage separately to make sure that the bank will
>> always be enabled while
* Waiman Long wrote:
> > I think Waiman's patches (even the later ones) made the queued rwlocks
> > be a side-by-side implementation with the old rwlocks, and I think
> > that was just being unnecessarily careful. It might be useful for
> > testing to have a config option to switch between
On Tue, Oct 01, 2013 at 09:22:03AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 30, 2013 at 02:58:57PM -0700, Andi Kleen wrote:
> > [This has kernel and user parts.
> > Both sides have been reviewed now, so hopefully it's good
> > to merge.]
> > [v2: Address Peter's feedback for the kernel parts]
>
* Peter Zijlstra wrote:
> On Mon, Sep 30, 2013 at 09:13:52AM -0700, Linus Torvalds wrote:
>
> > So unlike a lot of other "let's try to make our locking fancy" that I
> > dislike because it tends to hide the fundamental problem of
> > contention, the rwlock patches make me go "those actually
On Fri, Sep 20, 2013 at 07:26:03AM -0500, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 18, 2013 at 06:50:45PM +0200, Alexander Gordeev wrote:
> > Actually, I do not see much contradiction with what I proposed. The
> > key words here "determine the number of MSIs the controller wants".
> >
> > In
On Mon, Sep 30, 2013 at 02:58:57PM -0700, Andi Kleen wrote:
> [This has kernel and user parts.
> Both sides have been reviewed now, so hopefully it's good
> to merge.]
> [v2: Address Peter's feedback for the kernel parts]
> [v3: Rebased to current tip. Added Ack/Reviewed-by for user tools code]
I
On Thu, Sep 26, 2013 at 04:39:02PM +0200, Alexander Gordeev wrote:
> On Thu, Sep 26, 2013 at 09:11:47AM -0400, Tejun Heo wrote:
> > > Because otherwise we will re-introduce a problem described by Michael:
> > > "We have a small number of MSIs available, limited by hardware &
> > > firmware, if we
* Namhyung Kim wrote:
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -2753,6 +2753,15 @@ int perf_session__read_header(struct perf_session
> *session)
> if (perf_file_header__read(_header, header, fd) < 0)
> return -EINVAL;
>
> + /*
> + *
On Mon, Sep 30, 2013 at 7:34 PM, Linus Torvalds
wrote:
> On Mon, Sep 30, 2013 at 10:12 AM, Arnaldo Carvalho de Melo
> wrote:
>>
>> Checking why that strlcpy failed...
>
> I don't think glibc does strlcpy. It's not a standard C function, and
> it's somewhat controversial (although I dislike
* Bartlomiej Zolnierkiewicz wrote:
> __initdata tag should be placed between the variable name and equal
> sign for the variable to be placed in the intended .init.data section.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Kyungmin Park
> ---
>
* Frederic Weisbecker wrote:
> config VIRT_CPU_ACCOUNTING_GEN
> bool "Full dynticks CPU time accounting"
> - depends on HAVE_CONTEXT_TRACKING && 64BIT
> + depends on HAVE_CONTEXT_TRACKING
> depends on HAVE_VIRT_CPU_ACCOUNTING_GEN
> select VIRT_CPU_ACCOUNTING
>
Hi Amit,
> Hi,
>
> On Tue, Sep 24, 2013 at 1:38 PM, Lukasz Majewski
> wrote:
> > The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 ("thermal:
> > exynos: Add missing definations and code cleanup") has removed
> > setting of test MUX address value at TMU configuration setting.
> >
> > This
* Frederic Weisbecker wrote:
> On Mon, Sep 30, 2013 at 09:07:19AM -0700, Linus Torvalds wrote:
> > On Mon, Sep 30, 2013 at 7:55 AM, Frederic Weisbecker
> > wrote:
> > > ...
> > > the chances for a stack overrun as reported in powerpc for example:
> > >
> > > [ 1002.364577] do_IRQ:
Il 30/09/2013 22:11, Chris Metcalf ha scritto:
> As I said to Gleb in the previous email - sorry for the delay in
> replying to your thoughtful comments!
>
>
> On 9/10/2013 8:47 AM, Paolo Bonzini wrote:
>> Il 28/08/2013 22:58, Chris Metcalf ha scritto:
>>> This change enables support for a
* Peter Zijlstra wrote:
> Change all __wait_event*() implementations to match the corresponding
> wait_event*() signature for convenience.
>
> In particular this does away with the weird 'ret' logic. Since there
> are __wait_event*() users this requires we update them too.
>
> Signed-off-by:
On Mon, Sep 30, 2013 at 03:54:27PM +0200, Ruslan N. Marchenko wrote:
> On Mon, Sep 30, 2013 at 01:54:06PM +0200, Julia Lawall wrote:
> > On Mon, 30 Sep 2013, Ruslan N. Marchenko wrote:
> >
> > > Hi Julia et al.,
> > >
> > > With this commit VIA NANO board get CPU lockup in random places on any
Hello Ingo,
On 10/01/2013 01:46 PM, Ingo Molnar wrote:
>
> * Zhang Yanfei wrote:
>
>> @@ -153,11 +153,18 @@ config MOVABLE_NODE
>> help
>>Allow a node to have only movable memory. Pages used by the kernel,
>>such as direct mapping pages cannot be migrated. So the
Just send a v2 of the patch
http://patchwork.ozlabs.org/patch/279339/
Thanks!
On Tue, Oct 1, 2013 at 8:01 AM, David Miller wrote:
> From: Ricardo Ribalda Delgado
> Date: Tue, 1 Oct 2013 07:46:31 +0200
>
>> What if I move
>>lp->tx_bd_ci = 0;
>>lp->tx_bd_next = 0;
>>
The dma descriptors indexes are only initialized on the probe function.
If a packet is on the buffer when temac_stop is called, the dma
descriptors indexes can be left on a incorrect state where no other
package can be sent.
So an interface could be left in an usable state after ifdow/ifup.
On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote:
> __initdata tag should be placed between the variable name and equal
> sign for the variable to be placed in the intended .init.data section.
I see lots of other occurences of that in arch/powerpc. Why not send a
single
From: Ricardo Ribalda Delgado
Date: Tue, 1 Oct 2013 07:46:31 +0200
> What if I move
>lp->tx_bd_ci = 0;
>lp->tx_bd_next = 0;
>lp->tx_bd_tail = 0;
>lp->rx_bd_ci = 0;
>
> to temac_dma_bd_init? Will this be more correct?
Yes, that would be a lot better.
--
To
Hi,
On Sat, 28 Sep 2013 02:10:12 +0300
Aaro Koskinen wrote:
> Hi,
>
> 3.12-rc2 breaks the boot (BUG: scheduling while atomic, see logs below)
> on Lemote Mini-PC (MIPS). According to git bisect, this is caused by:
>
> ff522058bd717506b2fa066fa564657f2b86477e is the first bad commit
> commit
* Borislav Petkov b...@alien8.de wrote:
On Mon, Sep 30, 2013 at 08:28:48AM +0200, Ingo Molnar wrote:
* H. Peter Anvin h...@zytor.com wrote:
If the goal is to feed this to the field width in printf, which I would
think would be the dominant use, then you do have to account for the
On Tue, Sep 24, 2013 at 1:09 PM, takas...@ops.dti.ne.jp wrote:
From: Shinya Kuribayashi shinya.kuribayashi...@renesas.com
Add calls to clk_prepare and unprepare so that EMMA Mobile EV2 can
migrate to the common clock framework.
Signed-off-by: Shinya Kuribayashi
On Tue, Sep 24, 2013 at 1:10 PM, takas...@ops.dti.ne.jp wrote:
From: Shinya Kuribayashi shinya.kuribayashi...@renesas.com
Add calls to clk_prepare and unprepare so that EMMA Mobile EV2 can
migrate to the common clock framework.
Signed-off-by: Shinya Kuribayashi
Commit-ID: a17bce4d1dce8f3cf714bc2e5d8e4bac009dc077
Gitweb: http://git.kernel.org/tip/a17bce4d1dce8f3cf714bc2e5d8e4bac009dc077
Author: Borislav Petkov b...@alien8.de
AuthorDate: Mon, 30 Sep 2013 11:56:24 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 1 Oct 2013 10:52:30
On Tue, Sep 24, 2013 at 1:15 PM, takas...@ops.dti.ne.jp wrote:
Common clock framework version of emev2 clock support.
smu_clkdiv and smu_gclk are handled.
So far, reparent is not implemented, and is fixed to index #0.
SMU and small numbers of clocks are described in emev2.dtsi.
That
On Tue, Oct 01, 2013 at 11:39:08AM +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
Some powernv systems include a hwrng. Guests
On Tue, Oct 01, 2013 at 09:41:04AM +0530, Manish Badarkhe wrote:
This patch changes the driver to avoid the usage of IS_ERR_OR_NULL()
macro.
Why?
signature.asc
Description: Digital signature
On Tue, Sep 24, 2013 at 1:17 PM, takas...@ops.dti.ne.jp wrote:
Use common clock framework version of clock
drivers/clk/shmobile/clk-emev2.c
instead of sh-clkfwk version
arch/arm/mach-shmobile/clock-emev2.c
kzm9d(without -reference) still uses sh-clkfwk version.
Because two of that
On Tue, Sep 24, 2013 at 1:12 PM, takas...@ops.dti.ne.jp wrote:
Make sh clock framework core depend on HAVE_MACH_CLKDEV, and
set it
- y on sh for backward compatibility
- !CONFIG_COMMON_CLK on sh-mobile
This is a preparation for migration to common clock framework
from sh clock framework on
Fixed a brace coding style issue. (Brace not on the good line)
Signed-off-by: Mathieu Rhéaume math...@codingrhemes.com
---
drivers/acpi/processor_driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index
On Tue, 2013-10-01 at 11:39 +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
Some powernv systems include a hwrng. Guests can
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
If system can create movable node which all memory of the node is allocated
as ZONE_MOVABLE, setup_node_data() cannot allocate memory for the node's
pg_data_t. So, invoke memblock_alloc_nid(...MAX_NUMNODES) again to retry when
the first
On Mon, Sep 30, 2013 at 05:43:48PM +0300, Mika Westerberg wrote:
+static void acpi_i2c_device_pm_get(struct i2c_client *client)
+{
+ struct i2c_adapter *adap = client-adapter;
+
+ /* Make sure the adapter is active */
+ if (ACPI_HANDLE(adap-dev.parent))
+
From: Tang Chen tangc...@cn.fujitsu.com
There is no flag in memblock to describe what type the memory is.
Sometimes, we may use memblock to reserve some memory for special usage.
And we want to know what kind of memory it is. So we need a way to
differentiate memory for different usage.
In
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look
From: Tang Chen tangc...@cn.fujitsu.com
In find_hotpluggable_memory, once we find out a memory region which is
hotpluggable, we want to mark them in memblock.memory. So that we could
control memblock allocator not to allocte hotpluggable memory for the kernel
later.
To achieve this goal, we
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
From: Tang Chen tangc...@cn.fujitsu.com
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
---
arch/metag/mm/init.c |3 ++-
arch/metag/mm/numa.c |3 ++-
arch/microblaze/mm/init.c |3 ++-
arch/powerpc/mm/mem.c |2 +-
From: Tang Chen tangc...@cn.fujitsu.com
When parsing SRAT, we know that which memory area is hotpluggable.
So we invoke function memblock_mark_hotplug() introduced by previous
patch to mark hotpluggable memory in memblock.
Besides, move setting back to top-down allocation just right after
we
From: Tang Chen tangc...@cn.fujitsu.com
At very early time, the kernel have to use some memory such as
loading the kernel image. We cannot prevent this anyway. So any
node the kernel resides in should be un-hotpluggable.
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
Reviewed-by: Zhang
From: Tang Chen tangc...@cn.fujitsu.com
Linux kernel cannot migrate pages used by the kernel. As a result, hotpluggable
memory used by the kernel won't be able to be hot-removed. To solve this
problem, the basic idea is to prevent memblock from allocating hotpluggable
memory for the kernel at
From: Tang Chen tangc...@cn.fujitsu.com
Arrange hotpluggable memory as ZONE_MOVABLE will cause NUMA performance down
because the kernel cannot use movable memory. For users who don't use memory
hotplug and who don't want to lose their NUMA performance, they need a way to
disable this
Il 01/10/2013 10:34, Michael Ellerman ha scritto:
If you really want to have the hypercall, implementing it in QEMU means
that you can support it on all systems, in fact even when running
without KVM.
Sure, I can add a fallback to /dev/hwrng for full emulation.
The QEMU command line
On Tue, Oct 01, 2013 at 07:23:20PM +1000, Paul Mackerras wrote:
On Tue, Oct 01, 2013 at 11:39:08AM +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael
On 10/01/2013 11:23 AM, Paul Mackerras wrote:
On Tue, Oct 01, 2013 at 11:39:08AM +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
Some
Hello guys, this is the part2 of our memory hotplug work. This part
is based on the part1:
x86, memblock: Allocate memory near kernel image before SRAT parsed
You could refer part1 from: https://lkml.org/lkml/2013/9/24/421
Any comments are welcome! Thanks!
[Problem]
The current Linux
On Wed, 2013-09-18 at 11:45 +0800, Xishi Qiu wrote:
to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
-case allows the driver to be built when rfkill is not configured, which which
+case allows the driver to be built when rfkill is not configured, which
case all
The goal of this series is to add I2C support to ST SoCs.
The DT definition is added for STiH415 and STiH416 SoCs on
B2000 and B2020 boards.
The series has been tested working on STiH416-B2020 board.
It applies on top of v3.12-rc3.
Changes since v2:
- Create generic DT property for Anti-glitch
Hi Paul/SH folks.
Would appreciate your ACK/NAK on this.
Thx,
-Vineet
On 09/17/2013 11:47 AM, Vineet Gupta wrote:
Only a couple of arches (sh/x86) use fpu_counter in task_struct so it
can be moved out into ARCH specific thread_struct, reducing the size of
task_struct for other arches.
On Tue, Oct 01, 2013 at 05:51:33PM +1000, Michael Ellerman wrote:
The disadvantage is that any restriction imposed on us above the quota
can only be reported as an error from pci_enable_msix().
The quota code, called from pci_get_msix_limit(), can only do so much to
interogate firmware about
Hi,
On Tuesday, October 01, 2013 08:59:50 AM Ingo Molnar wrote:
* Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by:
The goal of this series is to add I2C support to ST SoCs.
The DT definition is added for STiH415 and STiH416 SoCs on
B2000 and B2020 boards.
The series has been tested working on STiH416-B2020 board.
It applies on top of v3.12-rc3.
Changes since v2:
- Create generic DT property for Anti-glitch
This patch supplies I2C configuration to STiH416 SoC.
Cc: Srinivas Kandagatla srinivas.kandaga...@st.com
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
---
arch/arm/boot/dts/stih416-pinctrl.dtsi | 35 +
arch/arm/boot/dts/stih416.dtsi | 53
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports I2C Standard and Fast modes.
Signed-off-by: Maxime Coquelin
This patch supplies I2C configuration to B2000 and B2020
based on either STiH415 or STiH416 SoCs.
Cc: Srinivas Kandagatla srinivas.kandaga...@st.com
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
---
arch/arm/boot/dts/stih41x-b2000.dtsi |9 +
This patch supplies I2C configuration to STiH415 SoC.
Cc: Srinivas Kandagatla srinivas.kandaga...@st.com
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
---
arch/arm/boot/dts/stih415-pinctrl.dtsi | 36 ++
arch/arm/boot/dts/stih415.dtsi | 53
On 10/01/2013 11:53 AM, Roger Quadros wrote:
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
Warning message triggered with 3.12.0-0.rc3.git0.1.fc21.x86_64.
[ 10.886016] applesmc: key count changed from 261 to 1174405121
Explains the crash, but the new key count is very wrong. 1174405121 =
0x4601.
Which I guess explains the subsequent memory allocation error in the log.
On Tue, Oct 01, 2013 at 08:55:16AM +0200, Ingo Molnar wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, Sep 30, 2013 at 09:07:19AM -0700, Linus Torvalds wrote:
On Mon, Sep 30, 2013 at 7:55 AM, Frederic Weisbecker fweis...@gmail.com
wrote:
...
the chances for
Hi all,
I've uploaded today's linux-next tree to the master branch of the
repository below:
git://gitorious.org/thierryreding/linux-next.git
A next-20131001 tag is also provided for convenience.
The situation is pretty much the same as yesterday. Some conflicts went
away, but most
On Mon, Sep 30, 2013 at 05:02:47PM +0200, Frederic Weisbecker wrote:
Ingo, Thomas,
Please pull the irq/core-v5 branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
irq/core-v5
HEAD: f6f626fa877c96974fadc595ddd72543d8c6106b
I have
Today's linux-next merge of the net-next tree got conflicts in
arch/h8300/include/uapi/asm/socket.h
drivers/net/usb/qmi_wwan.c
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
include/net/secure_seq.h
I removed the h8300 file and fixed up the other three (see
Today's linux-next merge of the sh tree got conflicts in
arch/sh/kernel/cpu/sh2a/Makefile
drivers/tty/serial/sh-sci.c
include/linux/serial_sci.h
I fixed them up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc
Today's linux-next merge of the block tree got conflicts in:
drivers/md/bcache/bcache.h
drivers/md/bcache/bset.c
drivers/md/bcache/journal.c
drivers/md/bcache/request.c
drivers/md/bcache/writeback.c
I fixed it up (see below). Please check if the resolution
Today's linux-next merge of the cgroup tree got a conflict in:
mm/memcontrol.c
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc mm/memcontrol.c
index 1c52ddb,65a46ef..84dcc5c
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -6203,9
Today's linux-next merge of the vfs tree got conflicts in:
fs/nfs/direct.c
fs/nfs/file.c
I fixed them up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc fs/nfs/direct.c
index 239c2fe,d71d66c..e83817c
--- a/fs/nfs/direct.c
+++
Today's linux-next merge of the random tree got a conflict in:
init/main.c
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc init/main.c
index 7cc4b78,586cd33..379090f
--- a/init/main.c
+++ b/init/main.c
@@@ -75,7 -75,7 +75,8 @@@
Today's linux-next merge of the driver-core tree got conflicts in
include/linux/netdevice.h
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc drivers/mtd/nand/atmel_nand.c
index ef9c9f5,bd1ce7d..2dbd913
---
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
On 09/30/2013 08:59 AM, Sricharan R wrote:
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the interrupt
requests lines from the subsystems are not needed at
On Tue, Oct 1, 2013 at 9:34 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Linus,
Since this patch-set doesn't cause any regression and fix a long standing
issue
on OMAP, do you think that it would be possible to include on the -rc series
as
a bugfix or do you prefer
On Mon, Sep 30, 2013 at 09:09:47AM -0500, Suravee Suthikulpanit wrote:
On 4/29/2013 7:30 AM, Oleg Nesterov wrote:
On 04/29, Ingo Molnar wrote:
* Oleg Nesterov o...@redhat.com wrote:
Obviously I can't ack the changes in this area, but to me the whole
series looks fine.
Thanks Oleg - can I add
Il 01/10/2013 11:38, Benjamin Herrenschmidt ha scritto:
So for the sake of that dogma you are going to make us do something that
is about 100 times slower ? (and possibly involves more lines of code)
If it's 100 times slower there is something else that's wrong. It's
most likely not 100 times
On Mon, Sep 30, 2013 at 6:54 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 30, 2013 at 06:48:55PM +0200, Stephane Eranian wrote:
On Mon, Sep 30, 2013 at 6:15 PM, Peter Zijlstra pet...@infradead.org
wrote:
On Mon, Sep 30, 2013 at 05:44:41PM +0200, Stephane Eranian wrote:
On Tue, Oct 01, 2013 at 01:07:22PM +0200, Thierry Reding wrote:
Today's linux-next merge of the random tree got a conflict in:
init/main.c
I fixed it up (see below). Please check if the resolution looks correct.
Looks good, thanks.
-
Hi,
On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote:
On 10/01/2013 11:53 AM, Roger Quadros wrote:
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM,
Generated by: coccinelle/misc/memcpy-assign.cocci
CC: Alexander Shiyan shc_w...@mail.ru
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
drivers/tty/serial/sccnxp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next.orig/drivers/tty/serial/sccnxp.c 2013-10-01
* Ingo Molnar mi...@kernel.org wrote:
Checking why that strlcpy failed...
I don't think glibc does strlcpy. It's not a standard C function,
and
My concern was more about the thinking: ``Is this red OFF thing a
problem? I feel so much more confortable when all entries have
Hi Yoshii-san and Simon,
On Tuesday 24 September 2013 13:52:15 Simon Horman wrote:
[ Cc Laurent ]
On Tue, Sep 24, 2013 at 01:13:31PM +0900, takas...@ops.dti.ne.jp wrote:
Device tree clock binding document for EMMA Mobile EV2 SMU.
Following nodes are defined to describe clock tree.
-
On Tue, 24 Sep 2013, Laxman Dewangan wrote:
The AMS AS3722 is a compact system PMU suitable for mobile phones,
s/AMS/ams
tablets etc. It has 4 DC/DC step-down regulators, 3 DC/DC step-down
controller, 11 LDOs, RTC, automatic battery, temperature and
over-current monitoring, 8 GPIOs, ADC and
This leak was added by v3.11-8748-g1d3d443 vmscan: per-node deferred work
unreferenced object 0x88006ada3bd0 (size 8):
comm criu, pid 14781, jiffies 4295238251 (age 105.641s)
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00
backtrace:
Hi, I am sorry for delay answer.
On Thu, 2013-09-26 at 10:46 +0100, Mark Rutland wrote:
On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote:
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core
Hi,
On Mon, 2013-09-23 at 14:31 -0500, Felipe Balbi wrote:
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration
Hello,
On Tue, Oct 01, 2013 at 05:35:48PM +1000, Michael Ellerman wrote:
Roughly third of the drivers just do not care and bail out once
pci_enable_msix() has not succeeded. Not sure how many of these are
mandated by the hardware.
Yeah, I mean, this type of interface is a trap.
501 - 600 of 1074 matches
Mail list logo
