All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Bhushan Bharat-R65777 <R65777@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] booke: Added ONE_REG interface for IAC/DAC debug registers
Date: Tue, 24 Jul 2012 14:56:46 +0000	[thread overview]
Message-ID: <500EB7AE.1090004@suse.de> (raw)
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03DD6CD4@039-SN2MPN1-023.039d.mgd.msft.net>

On 07/24/2012 03:26 PM, Bhushan Bharat-R65777 wrote:
>>>>>>> +struct kvmppc_debug_reg {
>>>>>>> +#ifdef CONFIG_BOOKE
>>>>>>> +	u32 dbcr0;
>>>>>>> +	u32 dbcr1;
>>>>>>> +	u32 dbcr2;
>>>>>>> +#ifdef CONFIG_KVM_E500MC
>>>>>>> +	u32 dbcr4;
>>>>>>> +#endif
>>>>>>> +	u64 iac[KVMPPC_MAX_IAC];
>>>>>>> +	u64 dac[KVMPPC_MAX_DAC];
>>>>>>> +#endif
>>>>>>> +};
>>>>>> Is there any reason for this to be a separate struct?
>>>>> No specific reason, The rest of debug ( which will follow sometime
>>>>> soon) uses
>>>> this structure and looks to make code look easy.
>>>>
>>>> So why not use an fsl / booke specific struct for the debug patches
>>>> then? Debug registers are really nothing common between book3s and
>>>> booke, so we shouldn't treat them as such by using the same struct
>> definition.
>>> All elements of struct are under #ifdef CONFIG_BOOKE? So for book3s it is as
>> good as void, only struct type if declared. Do you want the struct type also
>> under config_booke ?
>>
>> struct kvmppc_booke_debug_reg {
>>      <lots of defines>
>> };
>>
>> struct kvmppc_book3s_debug_reg {
>>      <lots of other defines>
>> };
>>
>> void booke_foo() {
>>     struct kvmppc_booke_debug_reg r;
> kvmppc_booke_debug_reg or kvmppc_book3s_debug_reg ?

In booke_foo() you certainly will never want to use struct 
kvmppc_book3s_debug_reg, no?


Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Bhushan Bharat-R65777 <R65777@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] booke: Added ONE_REG interface for IAC/DAC debug registers
Date: Tue, 24 Jul 2012 16:56:46 +0200	[thread overview]
Message-ID: <500EB7AE.1090004@suse.de> (raw)
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03DD6CD4@039-SN2MPN1-023.039d.mgd.msft.net>

On 07/24/2012 03:26 PM, Bhushan Bharat-R65777 wrote:
>>>>>>> +struct kvmppc_debug_reg {
>>>>>>> +#ifdef CONFIG_BOOKE
>>>>>>> +	u32 dbcr0;
>>>>>>> +	u32 dbcr1;
>>>>>>> +	u32 dbcr2;
>>>>>>> +#ifdef CONFIG_KVM_E500MC
>>>>>>> +	u32 dbcr4;
>>>>>>> +#endif
>>>>>>> +	u64 iac[KVMPPC_MAX_IAC];
>>>>>>> +	u64 dac[KVMPPC_MAX_DAC];
>>>>>>> +#endif
>>>>>>> +};
>>>>>> Is there any reason for this to be a separate struct?
>>>>> No specific reason, The rest of debug ( which will follow sometime
>>>>> soon) uses
>>>> this structure and looks to make code look easy.
>>>>
>>>> So why not use an fsl / booke specific struct for the debug patches
>>>> then? Debug registers are really nothing common between book3s and
>>>> booke, so we shouldn't treat them as such by using the same struct
>> definition.
>>> All elements of struct are under #ifdef CONFIG_BOOKE? So for book3s it is as
>> good as void, only struct type if declared. Do you want the struct type also
>> under config_booke ?
>>
>> struct kvmppc_booke_debug_reg {
>>      <lots of defines>
>> };
>>
>> struct kvmppc_book3s_debug_reg {
>>      <lots of other defines>
>> };
>>
>> void booke_foo() {
>>     struct kvmppc_booke_debug_reg r;
> kvmppc_booke_debug_reg or kvmppc_book3s_debug_reg ?

In booke_foo() you certainly will never want to use struct 
kvmppc_book3s_debug_reg, no?


Alex


  reply	other threads:[~2012-07-24 14:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 11:19 [PATCH v2] booke: Added ONE_REG interface for IAC/DAC debug registers Bharat Bhushan
2012-07-23 11:31 ` Bharat Bhushan
2012-07-23 15:42 ` Scott Wood
2012-07-23 15:42   ` Scott Wood
2012-07-23 15:48   ` Bhushan Bharat-R65777
2012-07-23 15:48     ` Bhushan Bharat-R65777
2012-07-23 16:02     ` Scott Wood
2012-07-23 16:02       ` Scott Wood
2012-07-23 17:41     ` Alexander Graf
2012-07-23 17:41       ` Alexander Graf
2012-07-24  1:04       ` Bhushan Bharat-R65777
2012-07-24  1:04         ` Bhushan Bharat-R65777
2012-07-24 12:46         ` Alexander Graf
2012-07-24 12:46           ` Alexander Graf
2012-07-24 13:26           ` Bhushan Bharat-R65777
2012-07-24 13:26             ` Bhushan Bharat-R65777
2012-07-24 14:56             ` Alexander Graf [this message]
2012-07-24 14:56               ` Alexander Graf

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=500EB7AE.1090004@suse.de \
    --to=agraf@suse.de \
    --cc=B07421@freescale.com \
    --cc=R65777@freescale.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    /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.