Paul Mackerras writes:
> On Sun, May 04, 2014 at 10:56:08PM +0530, Aneesh Kumar K.V wrote:
>> With debug option "sleep inside atomic section checking" enabled we get
>> the below WARN_ON during a PR KVM boot. This is because upstream now
>> have PREEMPT_COUNT enabled even if we have preempt disab
On Sun, 2014-05-04 at 18:22 +0800, Hongbo Zhang wrote:
> On 05/03/2014 12:46 AM, Vinod Koul wrote:
> > On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zh...@freescale.com wrote:
> >> From: Hongbo Zhang
> >>
> >> This patch adds suspend resume functions for Freescale DMA driver.
> >> .prepare call
On 05/07/2014 07:56 AM, Paul Mackerras wrote:
On Sun, May 04, 2014 at 10:56:08PM +0530, Aneesh Kumar K.V wrote:
With debug option "sleep inside atomic section checking" enabled we get
the below WARN_ON during a PR KVM boot. This is because upstream now
have PREEMPT_COUNT enabled even if we have
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizi
Hi Tony, Benjamin and Paul,
I've tried to fix this bug, but since I don't have either ppc64 nor ia64,
this patch is not tested on those archs. Please review and test it on
those machines.
Thank you,
(2014/05/07 20:55), Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not po
Hello Aneesh,
On 05/07/2014 01:35 AM, Aneesh Kumar K.V wrote:
> Emil Medve writes:
>
>> Currently bootmem is just a wrapper around memblock. This gets rid of
>> the wrapper code just as other ARHC(es) did: x86, arm, etc.
>>
>> For now only cover !NUMA systems/builds
>>
>> Signed-off-by: Emil Me
Hello Scott,
On 05/06/2014 09:44 PM, Scott Wood wrote:
> On Tue, 2014-05-06 at 19:16 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 05/06/2014 04:49 PM, Scott Wood wrote:
>>> On Tue, 2014-05-06 at 13:48 -0500, Emil Medve wrote:
Currently bootmem is just a wrapper around memblock. This
On Mon, Apr 28, 2014 at 9:52 AM, Chris Ball wrote:
> Hi,
>
> On Mon, Apr 28 2014, Stephen Warren wrote:
>> The series,
>> Tested-by: Stephen Warren
>>
>> (On an NVIDIA Tegra "Jetson TK1" board, with the patches applied on top
>> of next-20140428, also with Andrew Bresticker's Tegra SDHCI patches
On Tue, 2014-05-06 at 01:28 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> On 05/05/2014 06:34 PM, Scott Wood wrote:
> > On Sun, 2014-05-04 at 05:59 -0500, Emil Medve wrote:
> >> Anyway, most days PHYs can be discovered so they don't use/need
> >> compatible properties. That's I guess part of the
On Wed, 2014-05-07 at 11:30 +0800, Tang Yuantian wrote:
> From: Tang Yuantian
>
> Basically, this patch does the following:
> 1. Move the codes of parsing boot parameters from setup-common.c
>to driver. In this way, code reader can know directly that
>there are boot parameters that can ch
From: Tang Yuantian
Basically, this patch does the following:
1. Move the codes of parsing boot parameters from setup-common.c
to driver. In this way, code reader can know directly that
there are boot parameters that can change the timeout.
2. Make boot parameter 'booke_wdt_period' effectiv
From: Tang Yuantian
Main changs include:
- Clarified the clock nodes' version number
- Fixed a issue in example
Singed-off-by: Tang Yuantian
---
v2:
- rename this binding
- rewrite the description
.../bindings/clock/{corenet-clock.txt => qoriq-clock.txt} |
Hello Scott,
At this point, I'm getting a bit lost in this thread and I feel we're
getting into more generic comments. I'll continue to answer to some of
your comments to make sure I understand them. However, one major comment
I feel you made was about seeing a full FMan binding. If that's a deal
On Wed, 2014-05-07 at 22:23 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> At this point, I'm getting a bit lost in this thread and I feel we're
> getting into more generic comments. I'll continue to answer to some of
> your comments to make sure I understand them. However, one major comment
> I f
Hello Scott,
On 05/07/2014 10:36 PM, Scott Wood wrote:
> On Wed, 2014-05-07 at 22:23 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> At this point, I'm getting a bit lost in this thread and I feel we're
>> getting into more generic comments. I'll continue to answer to some of
>> your comments t
On Wed, May 07, 2014 at 08:55:51PM +0900, Masami Hiramatsu wrote:
...
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address
Hello Scott,
On 05/07/2014 06:14 PM, Scott Wood wrote:
> On Tue, 2014-05-06 at 01:28 -0500, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 05/05/2014 06:34 PM, Scott Wood wrote:
>>> On Sun, 2014-05-04 at 05:59 -0500, Emil Medve wrote:
Anyway, most days PHYs can be discovered so they don't us
(2014/05/08 13:47), Ananth N Mavinakayanahalli wrote:
> On Wed, May 07, 2014 at 08:55:51PM +0900, Masami Hiramatsu wrote:
>
> ...
>
>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
>> +/*
>> + * On PPC64 ABIv1 the function pointer actually points to the
>> + * function's d
On Thu, May 08, 2014 at 02:40:00PM +0900, Masami Hiramatsu wrote:
> (2014/05/08 13:47), Ananth N Mavinakayanahalli wrote:
> > On Wed, May 07, 2014 at 08:55:51PM +0900, Masami Hiramatsu wrote:
> >
> > ...
> >
> >> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> >> +/*
> >>
During the EEH hotplug event, pcibios_setup_device() will be invoked two
times. And the last time will trigger a warning of re-attachment of iommu
group.
The two times are:
pci_device_add
...
pcibios_add_device
pcibios_setup_device <- 1st time
pcibios_add_pci_dev
20 matches
Mail list logo
