* [PATCH] powerpc/ps3: Fix PS3 repository build warnings
From: Geoff Levand @ 2011-10-12 18:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: cbe-oss-dev, linuxppc-dev
Fix uninitialized variable warnings in build of repository.c
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/repository.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -184,7 +184,7 @@ int ps3_repository_read_bus_type(unsigne
enum ps3_bus_type *bus_type)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -199,7 +199,7 @@ int ps3_repository_read_bus_num_dev(unsi
unsigned int *num_dev)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -239,7 +239,7 @@ int ps3_repository_read_dev_type(unsigne
unsigned int dev_index, enum ps3_dev_type *dev_type)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -256,8 +256,8 @@ int ps3_repository_read_dev_intr(unsigne
enum ps3_interrupt_type *intr_type, unsigned int *interrupt_id)
{
int result;
- u64 v1;
- u64 v2;
+ u64 v1 = 0;
+ u64 v2 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -275,7 +275,7 @@ int ps3_repository_read_dev_reg_type(uns
enum ps3_reg_type *reg_type)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -615,7 +615,7 @@ int ps3_repository_read_stor_dev_num_reg
unsigned int dev_index, unsigned int *num_regions)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -631,7 +631,7 @@ int ps3_repository_read_stor_dev_region_
unsigned int *region_id)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -786,7 +786,7 @@ int ps3_repository_read_mm_info(u64 *rm_
int ps3_repository_read_num_spu_reserved(unsigned int *num_spu_reserved)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -805,7 +805,7 @@ int ps3_repository_read_num_spu_reserved
int ps3_repository_read_num_spu_resource_id(unsigned int *num_resource_id)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -827,8 +827,8 @@ int ps3_repository_read_spu_resource_id(
enum ps3_spu_resource_type *resource_type, unsigned int *resource_id)
{
int result;
- u64 v1;
- u64 v2;
+ u64 v1 = 0;
+ u64 v2 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -854,7 +854,7 @@ static int ps3_repository_read_boot_dat_
int ps3_repository_read_boot_dat_size(unsigned int *size)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -869,7 +869,7 @@ int ps3_repository_read_boot_dat_size(un
int ps3_repository_read_vuart_av_port(unsigned int *port)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -884,7 +884,7 @@ int ps3_repository_read_vuart_av_port(un
int ps3_repository_read_vuart_sysmgr_port(unsigned int *port)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -919,7 +919,7 @@ int ps3_repository_read_boot_dat_info(u6
int ps3_repository_read_num_be(unsigned int *num_be)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("ben", 0),
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Kumar Gala @ 2011-10-12 18:32 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <13184437244040-git-send-email-beckyb@kernel.crashing.org>
On Oct 12, 2011, at 1:22 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>=20
> Currently, it does a cntlzd on the size and then subtracts it from
> 21.... this doesn't take into account the varying size of a "long".
> Just use __ilog instead (and subtract the 10 we have to subtract
> to get to the tsize encoding).
>=20
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/mm/fsl_booke_mmu.c =
b/arch/powerpc/mm/fsl_booke_mmu.c
> index f7802c8..54897c0 100644
> --- a/arch/powerpc/mm/fsl_booke_mmu.c
> +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> @@ -111,7 +111,7 @@ static void settlbcam(int index, unsigned long =
virt, phys_addr_t phys,
> unsigned int tsize, lz;
>=20
> asm (PPC_CNTLZL "%0,%1" : "=3Dr" (lz) : "r" (size));
> - tsize =3D 21 - lz;
> + tsize =3D __ilog2(size) - 10;
If you do this you don't need 'lz' or the asm() statement.
>=20
> #ifdef CONFIG_SMP
> if ((flags & _PAGE_NO_CACHE) =3D=3D 0)
> --=20
> 1.5.6.5
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Becky Bruce @ 2011-10-12 18:22 UTC (permalink / raw)
To: linuxppc-dev
From: Becky Bruce <beckyb@kernel.crashing.org>
Currently, it does a cntlzd on the size and then subtracts it from
21.... this doesn't take into account the varying size of a "long".
Just use __ilog instead (and subtract the 10 we have to subtract
to get to the tsize encoding).
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index f7802c8..54897c0 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -111,7 +111,7 @@ static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned int tsize, lz;
asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (size));
- tsize = 21 - lz;
+ tsize = __ilog2(size) - 10;
#ifdef CONFIG_SMP
if ((flags & _PAGE_NO_CACHE) == 0)
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: K.Prasad @ 2011-10-12 17:39 UTC (permalink / raw)
To: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20111012033359.GR4849@truffala.fritz.box>
On Wed, Oct 12, 2011 at 02:33:59PM +1100, David Gibson wrote:
> On Fri, Sep 16, 2011 at 12:57:10PM +0530, K.Prasad wrote:
> > On Fri, Aug 26, 2011 at 03:05:52PM +0530, K.Prasad wrote:
> > > On Wed, Aug 24, 2011 at 01:59:39PM +1000, David Gibson wrote:
> > > > On Tue, Aug 23, 2011 at 02:55:13PM +0530, K.Prasad wrote:
> > > > > On Tue, Aug 23, 2011 at 03:08:50PM +1000, David Gibson wrote:
> > > > > > On Fri, Aug 19, 2011 at 01:21:36PM +0530, K.Prasad wrote:
[snipped]
> > [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
> >
> > PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> > PowerPC specific ptrace flags that use the watchpoint register. While they are
> > targeted primarily towards BookE users, user-space applications such as GDB
> > have started using them for BookS too.
> >
> > This patch enables the use of generic hardware breakpoint interfaces for these
> > new flags. The version number of the associated data structures
> > "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
>
> Above pargraph needs revision.
>
>
Sure, done.
> > Apart from the usual benefits of using generic hw-breakpoint interfaces, these
> > changes allow debuggers (such as GDB) to use a common set of ptrace flags for
> > their watchpoint needs and allow more precise breakpoint specification (length
> > of the variable can be specified).
> >
> > [Edjunior: Identified an issue in the patch with the sanity check for version
> > numbers]
> >
> > Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
> > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> >
> > diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
> > index f4a5499..04656ec 100644
> > --- a/Documentation/powerpc/ptrace.txt
> > +++ b/Documentation/powerpc/ptrace.txt
> > @@ -127,6 +127,22 @@ Some examples of using the structure to:
> > p.addr2 = (uint64_t) end_range;
> > p.condition_value = 0;
> >
> > +- set a watchpoint in server processors (BookS)
> > +
> > + p.version = 1;
> > + p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
> > + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
> > + or
> > + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
>
> MODE_RANGE_EXACT? Shouldn't that just be MODE_EXACT?
>
That was silly. Thanks for pointing it out.
> > +
> > + p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> > + p.addr = (uint64_t) begin_range;
> > + /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
> > + * addr2 - addr <= 8 Bytes.
> > + */
> > + p.addr2 = (uint64_t) end_range;
> > + p.condition_value = 0;
> > +
> > 3. PTRACE_DELHWDEBUG
> >
> > Takes an integer which identifies an existing breakpoint or watchpoint
> > diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> > index 05b7dd2..2449495 100644
> > --- a/arch/powerpc/kernel/ptrace.c
> > +++ b/arch/powerpc/kernel/ptrace.c
> > @@ -1339,6 +1339,12 @@ static int set_dac_range(struct task_struct *child,
> > static long ppc_set_hwdebug(struct task_struct *child,
> > struct ppc_hw_breakpoint *bp_info)
> > {
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + int ret, len = 0;
> > + struct thread_struct *thread = &(child->thread);
> > + struct perf_event *bp;
> > + struct perf_event_attr attr;
> > +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> > #ifndef CONFIG_PPC_ADV_DEBUG_REGS
> > unsigned long dabr;
> > #endif
> > @@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > */
> > if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
> > (bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
> > - bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
> > bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
> > return -EINVAL;
> >
> > - if (child->thread.dabr)
> > - return -ENOSPC;
> > -
> > if ((unsigned long)bp_info->addr >= TASK_SIZE)
> > return -EIO;
> >
> > @@ -1398,15 +1400,83 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > dabr |= DABR_DATA_READ;
> > if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
> > dabr |= DABR_DATA_WRITE;
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + if (ptrace_get_breakpoints(child) < 0)
> > + return -ESRCH;
> >
> > - child->thread.dabr = dabr;
> > + bp = thread->ptrace_bps[0];
> > + if (!bp_info->addr) {
>
> I think this is treating a hardware breakpoint at address 0 as if it
> didn't exist. That seems wrong.
>
Yes, I think the above the condition need not exist after we've agreed
that 0 is a valid address to set breakpoint upon. One needs to use
PPC_PTRACE_DELHWDEBUG to delete a breakpoint and not by writing 0 (as
done with PTRACE_SET_DEBUGREG).
I'll remove that.
> > + if (bp) {
> > + unregister_hw_breakpoint(bp);
> > + thread->ptrace_bps[0] = NULL;
> > + }
> > + ptrace_put_breakpoints(child);
> > + return 0;
> > + }
> > + /*
> > + * Check if the request is for 'range' breakpoints. We can
> > + * support it if range < 8 bytes.
> > + */
> > + if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
> > + len = bp_info->addr2 - bp_info->addr;
> > + else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
> > + ptrace_put_breakpoints(child);
> > + return -EINVAL;
> > + }
>
> Misindent here. This statement would be clearer if you had {} on all
> of the if branches.
>
Okay, done.
> > + if (bp) {
> > + attr = bp->attr;
> > + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> > + arch_bp_generic_fields(dabr &
> > + (DABR_DATA_WRITE | DABR_DATA_READ),
> > + &attr.bp_type);
> > + attr.bp_len = len;
>
> If gdb is using the new breakpoint interface, surely it should just
> use it, rather than doing this bit frobbing as in the old SET_DABR
> call.
>
I understand that you wanted to avoid this duplication of effort in terms
of encoding and decoding the breakpoint type from
PPC_BREAKPOINT_TRIGGER_READ to DABR_DATA_READ to HW_BREAKPOINT_R.
However HW_BREAKPOINT_R is a generic definition used across
architectures, DABR_DATA_READ is used in the !CONFIG_HAVE_HW_BREAKPOINT
case while PPC_BREAKPOINT_TRIGGER_READ is used in
CONFIG_PPC_ADV_DEBUG_REGS case.
While we could define PPC_BREAKPOINT_TRIGGER_READ and DABR_DATA_READ to
the same value it may not result in any code savings (since the bit
translation is done for !CONFIG_HAVE_HW_BREAKPOINT case anyway). So, I
think it is best left the way it is.
I'm attaching the revised patch (after incorporating your comments).
Kindly let me know your comments.
Thanks,
K.Prasad
---------
[hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
PowerPC specific ptrace flags that use the watchpoint register. While they are
targeted primarily towards BookE users, user-space applications such as GDB
have started using them for BookS too. This patch enables the use of generic
hardware breakpoint interfaces for these new flags.
Apart from the usual benefits of using generic hw-breakpoint interfaces, these
changes allow debuggers (such as GDB) to use a common set of ptrace flags for
their watchpoint needs and allow more precise breakpoint specification (length
of the variable can be specified).
Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
Documentation/powerpc/ptrace.txt | 16 +++++++
arch/powerpc/kernel/ptrace.c | 88 +++++++++++++++++++++++++++++++++++---
2 files changed, 98 insertions(+), 6 deletions(-)
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f4a5499..f2a7a39 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
+- set a watchpoint in server processors (BookS)
+
+ p.version = 1;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+ * addr2 - addr <= 8 Bytes.
+ */
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
3. PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 05b7dd2..be5dc57 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1339,6 +1339,12 @@ static int set_dac_range(struct task_struct *child,
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int ret, len = 0;
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long dabr;
#endif
@@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
*/
if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
(bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
- bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
return -EINVAL;
- if (child->thread.dabr)
- return -ENOSPC;
-
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
@@ -1398,15 +1400,75 @@ static long ppc_set_hwdebug(struct task_struct *child,
dabr |= DABR_DATA_READ;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
dabr |= DABR_DATA_WRITE;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
- child->thread.dabr = dabr;
+ /*
+ * Check if the request is for 'range' breakpoints. We can
+ * support it if range < 8 bytes.
+ */
+ if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE) {
+ len = bp_info->addr2 - bp_info->addr;
+ } else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
+ ptrace_put_breakpoints(child);
+ return -EINVAL;
+ }
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(dabr &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+ attr.bp_len = len;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret) {
+ ptrace_put_breakpoints(child);
+ return ret;
+ }
+ thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(child);
+ thread->dabr = dabr;
+ return 0;
+ }
+
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ attr.bp_len = len;
+ arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, NULL, child);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(child);
+ return PTR_ERR(bp);
+ }
+ ptrace_put_breakpoints(child);
+ return 1;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
+ if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
+ return -EINVAL;
+
+ if (child->thread.dabr)
+ return -ENOSPC;
+
+ child->thread.dabr = dabr;
return 1;
#endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
}
static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
int rc;
@@ -1426,10 +1488,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
#else
if (data != 1)
return -EINVAL;
+
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
+
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
if (child->thread.dabr == 0)
return -ENOENT;
child->thread.dabr = 0;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
return 0;
#endif
@@ -1560,7 +1636,7 @@ long arch_ptrace(struct task_struct *child, long request,
dbginfo.data_bp_alignment = 4;
#endif
dbginfo.sizeof_condition = 0;
- dbginfo.features = 0;
+ dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
if (!access_ok(VERIFY_WRITE, datavp,
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Hans J. Koch @ 2011-10-12 16:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, gregkh, linux-kernel
In-Reply-To: <AEAF26D0-640A-4DD2-82FE-B3BD02662EEC@kernel.crashing.org>
On Wed, Oct 12, 2011 at 11:08:20AM -0500, Kumar Gala wrote:
>
> On Oct 12, 2011, at 10:35 AM, Hans J. Koch wrote:
>
> > On Wed, Oct 12, 2011 at 09:43:36AM -0500, Kumar Gala wrote:
> >> For some devices the default behavior of pgprot_noncached is not
> >> the correct flags for the address space.
> >
> > For what devices? Can you give a real world usecase where this is needed?
> >
> > Thanks,
> > Hans
>
> In the Freescale Networking devices we have a coherent memory interface to our HW queuing system. In that case we want to change the pgprot() to be cache-able instead of non-cached.
Could you please post the kernel part of that driver?
Thanks,
Hans
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 16:19 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
In-Reply-To: <20111012153229.GB21852@local>
On Wed, Oct 12, 2011 at 05:32:29PM +0200, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> > From: Kai Jiang <Kai.Jiang@freescale.com>
> >
> > To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> > extend the width of 'addr' in struct uio_mem. Numerous platforms like
> > embedded PPC, ARM, and X86 have support for systems with larger physical
> > address than logical.
> >
> > Since 'addr' may contain a physical, logical, or virtual address the
> > easiest solution is to just change the type to 'unsigned long long'
> > regardless of which type is utilized.
>
> No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
> Please use that.
I forgot: If you resend this, please update the documentation as well.
(Documentation/DocBook/uio-howto.tmpl)
Thanks,
Hans
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 15:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, hjk, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <1318430145-19898-1-git-send-email-galak@kernel.crashing.org>
On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> From: Kai Jiang <Kai.Jiang@freescale.com>
>
> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> extend the width of 'addr' in struct uio_mem. Numerous platforms like
> embedded PPC, ARM, and X86 have support for systems with larger physical
> address than logical.
>
> Since 'addr' may contain a physical, logical, or virtual address the
> easiest solution is to just change the type to 'unsigned long long'
> regardless of which type is utilized.
No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
Please use that.
Thanks,
Hans
>
> For physical address we can support up to a 44-bit physical address on a
> typical 32-bit system as we utilize remap_pfn_range() for the mapping of
> the memory region and pfn's are represnted by shifting the address by
> the page size (typically 4k).
>
> Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/uio/uio.c | 8 ++++----
> include/linux/uio_driver.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index d2efe82..a927c51 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
>
> static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
> {
> - return sprintf(buf, "0x%lx\n", mem->addr);
> + return sprintf(buf, "0x%llx\n", mem->addr);
> }
>
> static ssize_t map_size_show(struct uio_mem *mem, char *buf)
> @@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
>
> static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
> {
> - return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
> + return sprintf(buf, "0x%llx\n", mem->addr & ~PAGE_MASK);
> }
>
> struct map_sysfs_entry {
> @@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
> page = virt_to_page(idev->info->mem[mi].addr + offset);
> else
> - page = vmalloc_to_page((void *)idev->info->mem[mi].addr
> - + offset);
> + page = vmalloc_to_page((void *)(unsigned long)
> + idev->info->mem[mi].addr + offset);
> get_page(page);
> vmf->page = page;
> return 0;
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 665517c..c1fdb19 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -31,7 +31,7 @@ struct uio_map;
> */
> struct uio_mem {
> const char *name;
> - unsigned long addr;
> + unsigned long long addr;
> unsigned long size;
> int memtype;
> void __iomem *internal_addr;
> --
> 1.7.3.4
>
>
^ permalink raw reply
* Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Hans J. Koch @ 2011-10-12 15:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, hjk, gregkh, linux-kernel
In-Reply-To: <1318430616-20351-1-git-send-email-galak@kernel.crashing.org>
On Wed, Oct 12, 2011 at 09:43:36AM -0500, Kumar Gala wrote:
> For some devices the default behavior of pgprot_noncached is not
> the correct flags for the address space.
For what devices? Can you give a real world usecase where this is needed?
Thanks,
Hans
> Provide a means for the
> kernel side UIO driver to override the flags without having to
> implement its own full mmap callback.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/uio/uio.c | 6 +++++-
> include/linux/uio_driver.h | 2 ++
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index d2efe82..88f4444 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -656,7 +656,11 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
>
> vma->vm_flags |= VM_IO | VM_RESERVED;
>
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + if (idev->info->mem[mi].set_pgprot)
> + vma->vm_page_prot =
> + idev->info->mem[mi].set_pgprot(vma->vm_page_prot);
> + else
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> return remap_pfn_range(vma,
> vma->vm_start,
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 665517c..4c618cd 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -28,6 +28,7 @@ struct uio_map;
> * @memtype: type of memory addr points to
> * @internal_addr: ioremap-ped version of addr, for driver internal use
> * @map: for use by the UIO core only.
> + * @set_pgprot: allow driver to override default(noncached) pgprot
> */
> struct uio_mem {
> const char *name;
> @@ -36,6 +37,7 @@ struct uio_mem {
> int memtype;
> void __iomem *internal_addr;
> struct uio_map *map;
> + pgprot_t (*set_pgprot)(pgprot_t prot);
> };
>
> #define MAX_UIO_MAPS 5
> --
> 1.7.3.4
>
>
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 16:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <AD39F4F8-E9C0-4090-9AEA-644F82DD328B@kernel.crashing.org>
On Wed, Oct 12, 2011 at 11:07:09AM -0500, Kumar Gala wrote:
>
> On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
>
> > On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> >> From: Kai Jiang <Kai.Jiang@freescale.com>
> >>
> >> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> >> extend the width of 'addr' in struct uio_mem. Numerous platforms like
> >> embedded PPC, ARM, and X86 have support for systems with larger physical
> >> address than logical.
> >>
> >> Since 'addr' may contain a physical, logical, or virtual address the
> >> easiest solution is to just change the type to 'unsigned long long'
> >> regardless of which type is utilized.
> >
> > No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
> > Please use that.
>
> Do we believe phys_addr_t is always greater than or equal to size need for logical & virtual addresses?
Yes.
Hans
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Geert Uytterhoeven @ 2011-10-12 16:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <AD39F4F8-E9C0-4090-9AEA-644F82DD328B@kernel.crashing.org>
On Wed, Oct 12, 2011 at 18:07, Kumar Gala <galak@kernel.crashing.org> wrote=
:
> On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
>> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>>> From: Kai Jiang <Kai.Jiang@freescale.com>
>>>
>>> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
>>> extend the width of 'addr' in struct uio_mem. =C2=A0Numerous platforms =
like
>>> embedded PPC, ARM, and X86 have support for systems with larger physica=
l
>>> address than logical.
>>>
>>> Since 'addr' may contain a physical, logical, or virtual address the
>>> easiest solution is to just change the type to 'unsigned long long'
>>> regardless of which type is utilized.
>>
>> No. There's phys_addr_t for that purpose, defined in include/linux/types=
.h.
>> Please use that.
>
> Do we believe phys_addr_t is always greater than or equal to size need fo=
r logical & virtual addresses?
Yes:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Kumar Gala @ 2011-10-12 16:08 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, linux-kernel
In-Reply-To: <20111012153536.GC21852@local>
On Oct 12, 2011, at 10:35 AM, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 09:43:36AM -0500, Kumar Gala wrote:
>> For some devices the default behavior of pgprot_noncached is not
>> the correct flags for the address space.
>=20
> For what devices? Can you give a real world usecase where this is =
needed?
>=20
> Thanks,
> Hans
In the Freescale Networking devices we have a coherent memory interface =
to our HW queuing system. In that case we want to change the pgprot() =
to be cache-able instead of non-cached.
- k
>=20
>> Provide a means for the
>> kernel side UIO driver to override the flags without having to
>> implement its own full mmap callback.
>>=20
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> drivers/uio/uio.c | 6 +++++-
>> include/linux/uio_driver.h | 2 ++
>> 2 files changed, 7 insertions(+), 1 deletions(-)
>>=20
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index d2efe82..88f4444 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -656,7 +656,11 @@ static int uio_mmap_physical(struct =
vm_area_struct *vma)
>>=20
>> vma->vm_flags |=3D VM_IO | VM_RESERVED;
>>=20
>> - vma->vm_page_prot =3D pgprot_noncached(vma->vm_page_prot);
>> + if (idev->info->mem[mi].set_pgprot)
>> + vma->vm_page_prot =3D
>> + =
idev->info->mem[mi].set_pgprot(vma->vm_page_prot);
>> + else
>> + vma->vm_page_prot =3D =
pgprot_noncached(vma->vm_page_prot);
>>=20
>> return remap_pfn_range(vma,
>> vma->vm_start,
>> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
>> index 665517c..4c618cd 100644
>> --- a/include/linux/uio_driver.h
>> +++ b/include/linux/uio_driver.h
>> @@ -28,6 +28,7 @@ struct uio_map;
>> * @memtype: type of memory addr points to
>> * @internal_addr: ioremap-ped version of addr, for driver internal =
use
>> * @map: for use by the UIO core only.
>> + * @set_pgprot: allow driver to override =
default(noncached) pgprot
>> */
>> struct uio_mem {
>> const char *name;
>> @@ -36,6 +37,7 @@ struct uio_mem {
>> int memtype;
>> void __iomem *internal_addr;
>> struct uio_map *map;
>> + pgprot_t (*set_pgprot)(pgprot_t prot);
>> };
>>=20
>> #define MAX_UIO_MAPS 5
>> --=20
>> 1.7.3.4
>>=20
>>=20
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 16:07 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
In-Reply-To: <20111012153229.GB21852@local>
On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>> From: Kai Jiang <Kai.Jiang@freescale.com>
>>=20
>> To support >32-bit physical addresses for UIO_MEM_PHYS type we need =
to
>> extend the width of 'addr' in struct uio_mem. Numerous platforms =
like
>> embedded PPC, ARM, and X86 have support for systems with larger =
physical
>> address than logical.
>>=20
>> Since 'addr' may contain a physical, logical, or virtual address the
>> easiest solution is to just change the type to 'unsigned long long'
>> regardless of which type is utilized.
>=20
> No. There's phys_addr_t for that purpose, defined in =
include/linux/types.h.
> Please use that.
Do we believe phys_addr_t is always greater than or equal to size need =
for logical & virtual addresses?
- k
> Thanks,
> Hans
>=20
>>=20
>> For physical address we can support up to a 44-bit physical address =
on a
>> typical 32-bit system as we utilize remap_pfn_range() for the mapping =
of
>> the memory region and pfn's are represnted by shifting the address by
>> the page size (typically 4k).
>>=20
>> Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
>> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> drivers/uio/uio.c | 8 ++++----
>> include/linux/uio_driver.h | 2 +-
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>=20
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index d2efe82..a927c51 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, =
char *buf)
>>=20
>> static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
>> {
>> - return sprintf(buf, "0x%lx\n", mem->addr);
>> + return sprintf(buf, "0x%llx\n", mem->addr);
>> }
>>=20
>> static ssize_t map_size_show(struct uio_mem *mem, char *buf)
>> @@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, =
char *buf)
>>=20
>> static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
>> {
>> - return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
>> + return sprintf(buf, "0x%llx\n", mem->addr & ~PAGE_MASK);
>> }
>>=20
>> struct map_sysfs_entry {
>> @@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct =
*vma, struct vm_fault *vmf)
>> if (idev->info->mem[mi].memtype =3D=3D UIO_MEM_LOGICAL)
>> page =3D virt_to_page(idev->info->mem[mi].addr + =
offset);
>> else
>> - page =3D vmalloc_to_page((void =
*)idev->info->mem[mi].addr
>> - + offset);
>> + page =3D vmalloc_to_page((void *)(unsigned long)
>> + idev->info->mem[mi].addr + offset);
>> get_page(page);
>> vmf->page =3D page;
>> return 0;
>> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
>> index 665517c..c1fdb19 100644
>> --- a/include/linux/uio_driver.h
>> +++ b/include/linux/uio_driver.h
>> @@ -31,7 +31,7 @@ struct uio_map;
>> */
>> struct uio_mem {
>> const char *name;
>> - unsigned long addr;
>> + unsigned long long addr;
>> unsigned long size;
>> int memtype;
>> void __iomem *internal_addr;
>> --=20
>> 1.7.3.4
>>=20
>>=20
^ permalink raw reply
* [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Kumar Gala @ 2011-10-12 14:43 UTC (permalink / raw)
To: hjk; +Cc: linuxppc-dev, gregkh, linux-kernel
For some devices the default behavior of pgprot_noncached is not
the correct flags for the address space. Provide a means for the
kernel side UIO driver to override the flags without having to
implement its own full mmap callback.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/uio/uio.c | 6 +++++-
include/linux/uio_driver.h | 2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index d2efe82..88f4444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -656,7 +656,11 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
vma->vm_flags |= VM_IO | VM_RESERVED;
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ if (idev->info->mem[mi].set_pgprot)
+ vma->vm_page_prot =
+ idev->info->mem[mi].set_pgprot(vma->vm_page_prot);
+ else
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
return remap_pfn_range(vma,
vma->vm_start,
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 665517c..4c618cd 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -28,6 +28,7 @@ struct uio_map;
* @memtype: type of memory addr points to
* @internal_addr: ioremap-ped version of addr, for driver internal use
* @map: for use by the UIO core only.
+ * @set_pgprot: allow driver to override default(noncached) pgprot
*/
struct uio_mem {
const char *name;
@@ -36,6 +37,7 @@ struct uio_mem {
int memtype;
void __iomem *internal_addr;
struct uio_map *map;
+ pgprot_t (*set_pgprot)(pgprot_t prot);
};
#define MAX_UIO_MAPS 5
--
1.7.3.4
^ permalink raw reply related
* [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 14:35 UTC (permalink / raw)
To: hjk; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
From: Kai Jiang <Kai.Jiang@freescale.com>
To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
extend the width of 'addr' in struct uio_mem. Numerous platforms like
embedded PPC, ARM, and X86 have support for systems with larger physical
address than logical.
Since 'addr' may contain a physical, logical, or virtual address the
easiest solution is to just change the type to 'unsigned long long'
regardless of which type is utilized.
For physical address we can support up to a 44-bit physical address on a
typical 32-bit system as we utilize remap_pfn_range() for the mapping of
the memory region and pfn's are represnted by shifting the address by
the page size (typically 4k).
Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/uio/uio.c | 8 ++++----
include/linux/uio_driver.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index d2efe82..a927c51 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr);
+ return sprintf(buf, "0x%llx\n", mem->addr);
}
static ssize_t map_size_show(struct uio_mem *mem, char *buf)
@@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
+ return sprintf(buf, "0x%llx\n", mem->addr & ~PAGE_MASK);
}
struct map_sysfs_entry {
@@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
page = virt_to_page(idev->info->mem[mi].addr + offset);
else
- page = vmalloc_to_page((void *)idev->info->mem[mi].addr
- + offset);
+ page = vmalloc_to_page((void *)(unsigned long)
+ idev->info->mem[mi].addr + offset);
get_page(page);
vmf->page = page;
return 0;
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 665517c..c1fdb19 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -31,7 +31,7 @@ struct uio_map;
*/
struct uio_mem {
const char *name;
- unsigned long addr;
+ unsigned long long addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
From: Dave Hansen @ 2011-10-12 14:15 UTC (permalink / raw)
To: Suzuki Poulose
Cc: Michal Simek, tmarri, Mahesh Jagannath Salgaonkar, David Laight,
Paul Mackerras, Scott Wood, linux ppc dev, Vivek Goyal
In-Reply-To: <4E943C70.4030106@in.ibm.com>
On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
> On 10/10/11 23:30, Scott Wood wrote:
> > On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
> >> #if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
> >> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START + (KERNELBASE + RELOC_OFFSET)))
> >> #define __pa(x) ((unsigned long)(x) + PHYSICAL_START - (KERNELBASE + RELOC_OFFSET))
> >> #endif
> >
> > Why is this 44x-specific?
>
> As of now, we compile with relocations only for the 44x. We could make this
> generic once the approach is accepted by everyone and implemented on the other
> platforms.
This is not the place to enforce that kind of thing. If
CONFIG_RELOCATABLE is only supported on one platform, then do:
config RELOCATABLE
depends on 44x
and take the 44x reference out of the #ifdef.
-- Dave
^ permalink raw reply
* [PATCH] ll_temac: Add support for ethtool
From: Ricardo Ribalda Delgado @ 2011-10-12 11:47 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-netdev, dhlii, ville.sundell,
grant.likely
Cc: Ricardo Ribalda Delgado
This patch enables the ethtool interface. The implementation is done
using the libphy helper functions.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
drivers/net/ll_temac_main.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 728fe41..91a9804 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -957,6 +957,32 @@ static const struct attribute_group temac_attr_group = {
.attrs = temac_device_attrs,
};
+/* ethtool support */
+static int temac_get_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_gset(lp->phy_dev, cmd);
+}
+
+static int temac_set_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_sset(lp->phy_dev, cmd);
+}
+
+static int temac_nway_reset(struct net_device *ndev)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_start_aneg(lp->phy_dev);
+}
+
+static const struct ethtool_ops temac_ethtool_ops = {
+ .get_settings = temac_get_settings,
+ .set_settings = temac_set_settings,
+ .nway_reset = temac_nway_reset,
+ .get_link = ethtool_op_get_link,
+};
+
static int __devinit temac_of_probe(struct platform_device *op)
{
struct device_node *np;
@@ -978,6 +1004,7 @@ static int __devinit temac_of_probe(struct platform_device *op)
ndev->flags &= ~IFF_MULTICAST; /* clear multicast */
ndev->features = NETIF_F_SG | NETIF_F_FRAGLIST;
ndev->netdev_ops = &temac_netdev_ops;
+ ndev->ethtool_ops= &temac_ethtool_ops;
#if 0
ndev->features |= NETIF_F_IP_CSUM; /* Can checksum TCP/UDP over IPv4. */
ndev->features |= NETIF_F_HW_CSUM; /* Can checksum all the packets. */
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH v14 10/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: Sergei Shtylyov @ 2011-10-12 11:16 UTC (permalink / raw)
To: Tirumala Marri; +Cc: Mark Miesfeld, greg, linux-usb, linuxppc-dev, Fushen Chen
In-Reply-To: <85bdbe5686e64bd0be07b07e2bb9a0ac@mail.gmail.com>
Hello.
On 12-10-2011 2:43, Tirumala Marri wrote:
> <> +# dwc_otg builds in ../dwc along with host support
> <> +config USB_GADGET_DWC_HDRC
> <> + boolean "DesignWare USB Peripheral"
> <> + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY
> <> + select USB_GADGET_DUALSPEED
> <> + select USB_GADGET_SELECTED
> <> + select USB_GADGET_DWC_OTG
> < I don't see where this one is defined...
> [Tirumala Marri] You mean USB_GADGET_SELECTED ? Ok I will add it.
No, I mean USB_GADGET_DWC_OTG. USB_GADGET_SELECTED is already defined.
> --marri
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v3] powerpc/85xx: Adding DCSR node to dtsi device trees
From: Kumar Gala @ 2011-10-12 4:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Stephen George
In-Reply-To: <1316187394-858-1-git-send-email-galak@kernel.crashing.org>
On Sep 16, 2011, at 10:36 AM, Kumar Gala wrote:
> From: Stephen George <stephen.george@freescale.com>
>
> Adding new device tree binding file for the DCSR node. Modifying device
> tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
>
> Signed-off-by: Stephen George <stephen.george@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> v3:
> * fix IRQs #, (should be +16 because of external IRQs starting at 0)
>
> v2:
> * include dscr.txt binding spec
> * moved around dcsr nodes to keep sorted in addr order
applied, dropped p3060 for now (will pick up in the P3060QDS board patch).
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Kumar Gala @ 2011-10-12 4:53 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1316806370-21067-1-git-send-email-agust@denx.de>
On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:
> Remove wrong CONFIG_ prefix in Kconfig file.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] [v3] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-10-12 4:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1316109853-6665-1-git-send-email-timur@freescale.com>
On Sep 15, 2011, at 1:04 PM, Timur Tabi wrote:
> Standarize and document the FPGA nodes used on Freescale QorIQ =
reference
> boards. There are different kinds of FPGAs used on the boards, but
> only two are currently standard: "pixis", "ngpixis", and "qixis". =
Although
> there are minor differences among the boards that have one kind of =
FPGA, most
> of the functionality is the same, so it makes sense to create common
> compatibility strings.
>=20
> We also need to update the P1022DS platform file, because the =
compatible
> string for its PIXIS node has changed. This means that older kernels =
are
> not compatible with newer device trees. This is not a real problem, =
however,
> since that particular function doesn't work anyway. When the DIU is =
active,
> the PIXIS is in "indirect mode", and so cannot be accessed as a =
memory-mapped
> device.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> v3: added "ngpixis" to list
>=20
> v2: removed references to the CPLD
>=20
> This patch only adds "ngpixis" nodes, because that's the easiest. The
> P3060QDS device tree already has a qixis node. Support for older =
boards
> with the old "pixis" will be added later.
applied
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl-booke: Fix setup_initial_memory_limit to not blindly map
From: Kumar Gala @ 2011-10-12 4:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1316187599-27549-2-git-send-email-galak@kernel.crashing.org>
On Sep 16, 2011, at 10:39 AM, Kumar Gala wrote:
> On FSL Book-E devices we support multiple large TLB sizes and so we can
> get into situations in which the initial 1G TLB size is too big and
> we're asked for a size that is not mappable by a single entry (like
> 512M). The single entry is important because when we bring up secondary
> cores they need to ensure any data structure they need to access (eg
> PACA or stack) is always mapped.
>
> So we really need to determine what size will actually be mapped by the
> first TLB entry to ensure we limit early memory references to that
> region. We refactor the map_mem_in_cams() code to provider a helper
> function that we can utilize to determine the size of the first TLB
> entry while taking into account size and alignment constraints.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/mm/fsl_booke_mmu.c | 31 +++++++++++++++++++------------
> arch/powerpc/mm/mmu_decl.h | 2 ++
> arch/powerpc/mm/tlb_nohash.c | 21 ++++++++++++++++++---
> 3 files changed, 39 insertions(+), 15 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: respect mem= setting for early memory limit setup
From: Kumar Gala @ 2011-10-12 4:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1316187599-27549-1-git-send-email-galak@kernel.crashing.org>
On Sep 16, 2011, at 10:39 AM, Kumar Gala wrote:
> For those MMUs that have some form of bolt'd linear mapping (TLB)
> required its rare that one ever sets mem= smaller than the size of that
> mapping.
>
> However, on Book-E 64 parts the initial linear mapping is quite large
> (1G) so its quite reasonable that mem= is set smaller than that.
>
> We need to parse the command line for mem= limit and constrain the
> amount of memory we map initially by it if need be.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/kernel/prom.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 10/13] powerpc: Update mpc85xx/corenet 32-bit defconfigs
From: Kumar Gala @ 2011-10-12 4:29 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798883685-git-send-email-beckyb@kernel.crashing.org>
On Oct 10, 2011, at 3:50 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>
> Results from updates via make savedefconfig.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/configs/corenet32_smp_defconfig | 8 --------
> arch/powerpc/configs/mpc85xx_defconfig | 5 +----
> arch/powerpc/configs/mpc85xx_smp_defconfig | 6 +-----
> 3 files changed, 2 insertions(+), 17 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 12/13] powerpc: Update corenet64_smp_defconfig
From: Kumar Gala @ 2011-10-12 4:29 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798902823-git-send-email-beckyb@kernel.crashing.org>
On Oct 10, 2011, at 3:50 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>
> Updates from make savedefconfig.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/configs/corenet64_smp_defconfig | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix doorbells
From: Kumar Gala @ 2011-10-12 4:26 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1318378002-32531-1-git-send-email-msm@freescale.com>
On Oct 11, 2011, at 7:06 PM, Matthew McClintock wrote:
> Commit 765342526246c97600e5344c0949824d94bb51c3 made some small
> changes to IPI, message_pass in smp_ops was initialized to NULL
> for other platforms but not for 85xx which causes us to always
> use the mpic for IPI's. This patch makes doorbells work again.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied (updated commit message a bit).
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox