On 09/13/2012 12:08 AM, Rob Herring wrote:
Geert is right here. If it is a physical address, it should be
phys_addr_t.
While generally true, for the DT specific code I think it should be a
fixed u64. The size of the address is defined by the FDT, not the
kernel. It is very likely we could have
On Thu, Sep 13, 2012 at 2:01 AM, Benjamin Herrenschmidt
wrote:
> On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
>> I'm reviving an old patch from 2009 that adds support for GXT4000P and
>> GXT6500P
>> adapter to the gxt4500 driver.
>
> Who is the original author ?
Signed-off-by: Nico Macrio
On Wed, Sep 12, 2012 at 10:05:33AM -0400, Eric Millbrandt wrote:
Please fix your mailer to word wrap within paragraphs.
> On 2012-09-11 Mark Brown wrote:
> > I only noticed DT bindings being added for pcm030, not for efika?
> When I looked I didn't see the Efika (PPC 5200B) DT in-tree. It only
> >
> >> -Original Message-
> >> From: Chris Ball [mailto:c...@laptop.org]
> >> Sent: Wednesday, September 12, 2012 4:59 AM
> >> To: Kumar Gala
> >> Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
> >> linux- m...@vger.kernel.org; Anton Vorontsov
> >> Subject: Re: [PATCH 2/3
On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
> I'm reviving an old patch from 2009 that adds support for GXT4000P and
> GXT6500P
> adapter to the gxt4500 driver.
Who is the original author ?
Cheers,
Ben.
> See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
> and h
On 9/12/2012 4:23 PM, Rob Herring wrote:
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globall
On Wed, 2012-09-12 at 18:00 -0500, Scott Wood wrote:
> PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE. We
> got away with it because PUD and PMD had the same index size, but this is
> no longer true with Aneesh's patchset to support a 46-bit user effective
> address space.
Ah,
PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE. We
got away with it because PUD and PMD had the same index size, but this is
no longer true with Aneesh's patchset to support a 46-bit user effective
address space.
Signed-off-by: Scott Wood
---
arch/powerpc/include/asm/pgtable
Right, as far as i'm concerced that patch always worked without issues.
--nico
On Wed, 12 Sep 2012 18:06:44 +0200
Dan Horák wrote:
> I'm reviving an old patch from 2009 that adds support for GXT4000P and
> GXT6500P
> adapter to the gxt4500 driver.
>
> See threads at http://marc.info/?l=lin
On Wed, 12 Sep 2012, Rob Herring wrote:
> On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
> > On some PAE architectures, the entire range of physical memory could reside
> > outside the 32-bit limit. These systems need the ability to specify the
> > initrd location using 64-bit numbers.
> >
> >
On 09/12/2012 02:58 PM, Sebastian Andrzej Siewior wrote:
> On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>>>
>>> Why not phys_addr_
On 09/12/2012 04:45 PM, Alexander Graf wrote:
>
>
> On 12.09.2012, at 23:38, Scott Wood wrote:
>
>> On 09/12/2012 01:56 PM, Alexander Graf wrote:
>>>
>>>
>>> On 12.09.2012, at 15:18, Mihai Caraman wrote:
>>>
The current form of DO_KVM macro restricts its use to one call per input
par
On 12.09.2012, at 23:38, Scott Wood wrote:
> On 09/12/2012 01:56 PM, Alexander Graf wrote:
>>
>>
>> On 12.09.2012, at 15:18, Mihai Caraman wrote:
>>
>>> The current form of DO_KVM macro restricts its use to one call per input
>>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr
On 09/12/2012 01:56 PM, Alexander Graf wrote:
>
>
> On 12.09.2012, at 15:18, Mihai Caraman wrote:
>
>> The current form of DO_KVM macro restricts its use to one call per input
>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
>> definition.
>> Duplicate calls of DO_KVM ar
On 09/12/2012 03:31 PM, Nicolas Pitre wrote:
> On Wed, 12 Sep 2012, Rob Herring wrote:
>
>> On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
Why not phys_addr_t?
The rest of the memory specific bits of the device-tree code use u64 for
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup
On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:
> Freescale PCIe IP block revision bigger than rev2.2 will also need
> redefine the sequence of inbound windows. So change to use IP block
> revision instead of compatible for the judgment.
>
> Signed-off-by: Roy Zang
> ---
>
> arch/powerpc/sysdev/fs
On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:
> Signed-off-by: Roy Zang
> ---
> arch/powerpc/sysdev/fsl_pci.h |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
applied to next
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.or
On Aug 28, 2012, at 2:44 AM, Jia Hongtao wrote:
> We unified the Freescale pci/pcie initialization by changing the fsl_pci
> to a platform driver. In previous PCI code architecture the initialization
> routine is called at board_setup_arch stage. Now the initialization is done
> in probe function
On Sep 12, 2012, at 5:36 AM, Shaohui Xie wrote:
> Device node adt7461 was wrongly added in p5040ds.dts, it should be added
> into i2c instead of localbus, when build p5040ds.dtb, a warning will dump:
>
> Warning (reg_format): "reg" property in
> /localbus@ffe124000/nand@2,0/adt7461@4c has invali
On 12.09.2012, at 15:18, Mihai Caraman wrote:
> The current form of DO_KVM macro restricts its use to one call per input
> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
> definition.
> Duplicate calls of DO_KVM are required by distinct implementations of
> exeption handl
On 9/12/2012 12:16 PM, Geert Uytterhoeven wrote:
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy wrote:
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch removed the tasklet and moved the wait queue into the
private structure. It also cleaned up the response CRQ path.
Signed-off-by: Ashley Lai
---
James,
This patch is based on your "next" branch.
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
Thanks,
Ashley
Anticipating growth in coming years, we should ensure we are getting a
good lead on testing.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/configs/pseries_defconfig
b/arch/powerpc/configs/pseries_defconfig
index 1f65b3c..a0e0e53 100644
--- a/arch/powerpc/configs/pseries_defco
Hi,
On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote:
> >
> > On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote:
> >> At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
> >>> How do you test the patch? As Andrew says, for hot-removing memory,
> >>> we need a particular hardwa
Hi Mark,
On 2012-09-12 Mark Brown wrote:
> On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
>> The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared
>> platform data with mpc5200_dma.
>
> This looks good but depends on patch 1 so I can't apply it - if you can
> rebase thi
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of th
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds sup
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds sup
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds sup
Hi Mark,
On 2012-09-11 Mark Brown wrote:
>> --- a/arch/powerpc/platforms/52xx/Kconfig
>> +++ b/arch/powerpc/platforms/52xx/Kconfig
>> @@ -1,6 +1,7 @@
>> config PPC_MPC52xx bool "52xx-based boards"depends on 6xx +
>> select
>> FSL_SOC select PPC_CLOCKselect PPC_PCI_CH
Hi Mark,
On 2012-09-11 Mark Brown wrote:
> On Tue, Sep 11, 2012 at 10:14:49PM -0400, Eric Millbrandt wrote:
>> MPC5200 ASoC setup can now be done in the device tree.
>
> I only noticed DT bindings being added for pcm030, not for efika?
>
When I looked I didn't see the Efika (PPC 5200B) DT in-tree.
On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
> The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared platform data
> with mpc5200_dma.
This looks good but depends on patch 1 so I can't apply it - if you can
rebase things so this is patch 1 I'll apply it.
_
The current form of DO_KVM macro restricts its use to one call per input
parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
definition.
Duplicate calls of DO_KVM are required by distinct implementations of
exeption handlers which are delegated at runtime. Use a rare label number
On Sep 12, 2012, at 1:18 AM, Huang Changming-R66093 wrote:
>
>
> Best Regards
> Jerry Huang
>
>
>> -Original Message-
>> From: Chris Ball [mailto:c...@laptop.org]
>> Sent: Wednesday, September 12, 2012 4:59 AM
>> To: Kumar Gala
>> Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, September 06, 2012 10:28 PM
> To: Enrico Scholz
> Cc: ba...@ti.com; Chen Peter-B29397; linux-...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Li Yang-R58472; gre...@linuxfoundation.org
> Subject: Re:
Device node adt7461 was wrongly added in p5040ds.dts, it should be added
into i2c instead of localbus, when build p5040ds.dtb, a warning will dump:
Warning (reg_format): "reg" property in
/localbus@ffe124000/nand@2,0/adt7461@4c has invalid length (4 bytes)
(#address-cells == 1, #size-cells == 1)
Hi Michael,
On Wed, 12 Sep 2012 17:52:40 +1000 Michael Ellerman
wrote:
>
> +#define DUMP(name, format) \
> + printf(" %-*s = %#-*"format"\t(0x%lx)\n", 16, #name, 18, p->name, \
> + (u64)((void *)&(p->name) - (void *)p));
I must say that I hate macros that reference (assumed) glo
On Wed, 2012-09-12 at 16:55 +0800, tiejun.chen wrote:
> > to worry about nor stack frame to create etc...
>
> If you don't like this v4, let me know and then I can go back memcpy
> for next
> version.
Just open code the whole copy. It should be easy really. As I said, you
have the src and dst a
Hi,
Any feedback?
--
Kirill A. Shutemov
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> >> Will this engine be coordinating with another to handle memory copies?
> >> The dma mapping code for async_tx/raid is broken when dma mapping
> >> requests overlap or cross dma device boundaries [1].
> >>
> >> [1]: http://marc.info/?l=linux-arm-kernel&m=129407269402930&w=2
> > Yes, it needs f
On 09/12/2012 04:43 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-09-12 at 16:38 +0800, tiejun.chen wrote:
So you need to store that old r1 somewhere fist then retrieve it
after the memcpy call. That or open-code the memcpy to avoid all
the clobbering problems.
Maybe we can use copy_and_flush
On Wed, 2012-09-12 at 17:52 +1000, Michael Ellerman wrote:
> This was originally motivated by a desire to see the mapping between
> logical and hardware cpu numbers.
>
> But it seemed that it made more sense to just add a command to dump
> (most of) the paca.
>
> With no arguments "dp" will dump
On Wed, 2012-09-12 at 16:38 +0800, tiejun.chen wrote:
> > So you need to store that old r1 somewhere fist then retrieve it
> > after the memcpy call. That or open-code the memcpy to avoid all
> > the clobbering problems.
>
> Maybe we can use copy_and_flush() since looks copy_and_flush() only
> clo
We don't do the real store operation for kprobing 'stwu Rx,(y)R1'
since this may corrupt the exception frame, now we will do this
operation safely in exception return code after migrate current
exception frame below the kprobed function stack.
So we only update gpr[1] here and trigger a thread fla
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline exception frame below the kprobed
function stack and copy the current exception frame to the trampoline.
Then we can do
Somewhere we need this simple copy_and_flush().
Signed-off-by: Tiejun Chen
---
arch/powerpc/kernel/entry_32.S | 27 +++
arch/powerpc/kernel/head_32.S | 26 --
2 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel
We need to add a new thread flag, TIF_EMULATE_STACK_STORE,
for emulating stack store operation while exiting exception.
Signed-off-by: Tiejun Chen
---
arch/powerpc/include/asm/thread_info.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/p
On 09/11/2012 01:51 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-09-11 at 10:20 +0800, Tiejun Chen wrote:
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline exceptio
This was originally motivated by a desire to see the mapping between
logical and hardware cpu numbers.
But it seemed that it made more sense to just add a command to dump
(most of) the paca.
With no arguments "dp" will dump the paca for all possible cpus. If
there are no possible cpus, like early
52 matches
Mail list logo
