All of lore.kernel.org
 help / color / mirror / Atom feed
From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@au1.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Michael Neuling <mikey@neuling.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Roland McGrath <roland@redhat.com>,
	paulus@samba.org
Subject: Re: [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
Date: Mon, 18 May 2009 21:45:25 +0530	[thread overview]
Message-ID: <20090518161525.GC27641@in.ibm.com> (raw)
In-Reply-To: <1242617732.18075.29.camel@pasglop>

On Mon, May 18, 2009 at 01:35:32PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-14 at 19:13 +0530, K.Prasad wrote:
> > plain text document attachment (ppc64_prepare_code_01)
> > Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
> > relevant constant definitions and function declarations.
> 
> Hi !
> 
> Some comments below...
> 
> > +#define   HBP_NUM	1	/* Number of physical HW breakpoint registers */
> 
> Can you use a more verbose constant ? reg.h is included everywhere so
> the risk of collision is high.
>

This constant is used by the generic HW Breakpoint code in
kernel/hw_breakpoint.c too and renaming it here will require changes
there too, while I don't see any existing name-space clashes.

Instead the definition can be moved into arch/powerpc/include/asm/hw_breakpoint.h
and in arch/power/include/asm/processor.h. What do you think?
 
> >  #define   DABR_TRANSLATION	(1UL << 2)
> >  #define   DABR_DATA_WRITE	(1UL << 1)
> >  #define   DABR_DATA_READ	(1UL << 0)
> > +#define   DABR_DATA_RW		(3UL << 0)
> 
> Do you really need that ? It's just DABR_DATA_WRITE | DABR_DATA_READ :-)
> 

Yes, it looks silly. I will remove it. The HW_BREAKPOINT_RW defined in
arch/powerpc/include/asm/hw_breakpoint.h will instead be defined as:

#define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE)


> Cheers,
> Ben.
>

Thanks,
K.Prasad
 

  reply	other threads:[~2009-05-18 16:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090514133312.360702378@prasadkr_t60p.in.ibm.com>
2009-05-14 13:43 ` [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure K.Prasad
2009-05-18  3:35   ` Benjamin Herrenschmidt
2009-05-18 16:15     ` K.Prasad [this message]
2009-05-14 13:44 ` [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces K.Prasad
2009-05-14 14:50   ` Michael Ellerman
2009-05-14 19:50     ` [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces K.Prasad
2009-05-14 20:20       ` Alan Stern
2009-05-18 16:10         ` K.Prasad
2009-05-18 16:30           ` Alan Stern
2009-05-21  7:15             ` K.Prasad
2009-05-14 13:45 ` [RFC Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces K.Prasad
2009-05-14 13:45 ` [RFC Patch 4/6] Modify process handling code to handle hardware debug registers K.Prasad
2009-05-14 14:54   ` Michael Ellerman
2009-05-14 13:45 ` [RFC Patch 5/6] Modify Data storage exception code to recognise DABR match first K.Prasad
2009-05-14 13:46 ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage K.Prasad
2009-05-14 13:59   ` Geert Uytterhoeven
2009-05-14 14:11     ` Michael Ellerman
2009-05-14 14:18       ` Geert Uytterhoeven
2009-05-14 14:55         ` Michael Ellerman
2009-05-14 19:15     ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64hardware " K.Prasad
2009-05-14 20:21   ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware " Alan Stern
2009-05-18 16:11     ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64hardware " K.Prasad
     [not found] <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
2009-05-21  7:17 ` [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure K.Prasad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090518161525.GC27641@in.ibm.com \
    --to=prasad@linux.vnet.ibm.com \
    --cc=benh@au1.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=paulus@samba.org \
    --cc=roland@redhat.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.