All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	mdroth@linux.vnet.ibm.com, agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH 2/3] spapr: Remove rtas_st_buffer_direct()
Date: Tue, 19 Jan 2016 15:08:51 +1100	[thread overview]
Message-ID: <20160119040851.GZ9301@voom.fritz.box> (raw)
In-Reply-To: <569D9A5B.3050501@ozlabs.ru>

[-- Attachment #1: Type: text/plain, Size: 5315 bytes --]

On Tue, Jan 19, 2016 at 01:07:23PM +1100, Alexey Kardashevskiy wrote:
> On 01/16/2016 12:14 PM, David Gibson wrote:
> >rtas_st_buffer_direct() is a not particularly useful wrapper around
> >cpu_physical_memory_write().  All the callers are in
> >rtas_ibm_configure_connector, where it's better handled by local helper.
> >
> >Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >---
> >  hw/ppc/spapr_rtas.c    | 19 ++++++++++++-------
> >  include/hw/ppc/spapr.h |  8 --------
> >  2 files changed, 12 insertions(+), 15 deletions(-)
> >
> >diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
> >index f4fb9ba..940509e 100644
> >--- a/hw/ppc/spapr_rtas.c
> >+++ b/hw/ppc/spapr_rtas.c
> >@@ -504,6 +504,13 @@ out:
> >  #define CC_VAL_DATA_OFFSET ((CC_IDX_PROP_DATA_OFFSET + 1) * 4)
> >  #define CC_WA_LEN 4096
> >
> >+static void st_cc_buf(target_ulong addr, target_ulong offset,
> >+                      void *buf, size_t len)
> 
> 
> Can we please call it cc_st_buf() to make it clear that "cc" is a prefix and
> not about functionality?

Yeah, st_cc_buf() is not a good name.  I've gone with
"configure_connector_st()" which I hope will be better.

> 
> 
> 
> >+{
> >+    cpu_physical_memory_write(ppc64_phys_to_real(addr + offset),
> >+                              buf, MIN(len, CC_WA_LEN - offset));
> >+}
> >+
> >  static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
> >                                           sPAPRMachineState *spapr,
> >                                           uint32_t token, uint32_t nargs,
> >@@ -526,6 +533,7 @@ static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
> >      }
> >
> >      wa_addr = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 0);
> >+    wa_addr = ppc64_phys_to_real(wa_addr);
> 
> 
> Not needed here, st_cc_buf() also does ppc64_phys_to_real().

Good point, corrected.

> >
> >      drc_index = rtas_ld(wa_addr, 0);
> >      drc = spapr_dr_connector_by_index(drc_index);
> >@@ -569,8 +577,7 @@ static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
> >              /* provide the name of the next OF node */
> >              wa_offset = CC_VAL_DATA_OFFSET;
> >              rtas_st(wa_addr, CC_IDX_NODE_NAME_OFFSET, wa_offset);
> >-            rtas_st_buffer_direct(wa_addr + wa_offset, CC_WA_LEN - wa_offset,
> >-                                  (uint8_t *)name, strlen(name) + 1);
> >+            st_cc_buf(wa_addr, wa_offset, (uint8_t *)name, strlen(name) + 1);
> 
> 
> Since you made @buf a void* in st_cc_buf(), you do not need (uint8_t*) here
> and below.

Ah, yes good point also.

> 
> 
> 
> >              resp = SPAPR_DR_CC_RESPONSE_NEXT_CHILD;
> >              break;
> >          case FDT_END_NODE:
> >@@ -595,8 +602,7 @@ static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
> >              /* provide the name of the next OF property */
> >              wa_offset = CC_VAL_DATA_OFFSET;
> >              rtas_st(wa_addr, CC_IDX_PROP_NAME_OFFSET, wa_offset);
> >-            rtas_st_buffer_direct(wa_addr + wa_offset, CC_WA_LEN - wa_offset,
> >-                                  (uint8_t *)name, strlen(name) + 1);
> >+            st_cc_buf(wa_addr, wa_offset, (uint8_t *)name, strlen(name) + 1);
> >
> >              /* provide the length and value of the OF property. data gets
> >               * placed immediately after NULL terminator of the OF property's
> >@@ -605,9 +611,8 @@ static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
> >              wa_offset += strlen(name) + 1,
> >              rtas_st(wa_addr, CC_IDX_PROP_LEN, prop_len);
> >              rtas_st(wa_addr, CC_IDX_PROP_DATA_OFFSET, wa_offset);
> >-            rtas_st_buffer_direct(wa_addr + wa_offset, CC_WA_LEN - wa_offset,
> >-                                  (uint8_t *)((struct fdt_property *)prop)->data,
> >-                                  prop_len);
> >+            st_cc_buf(wa_addr, wa_offset,
> >+                      (uint8_t *)((struct fdt_property *)prop)->data, prop_len);
> >              resp = SPAPR_DR_CC_RESPONSE_NEXT_PROPERTY;
> >              break;
> >          case FDT_END:
> >diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> >index ec9e7ea..d6f4eb4 100644
> >--- a/include/hw/ppc/spapr.h
> >+++ b/include/hw/ppc/spapr.h
> >@@ -505,14 +505,6 @@ static inline void rtas_st(target_ulong phys, int n, uint32_t val)
> >      stl_be_phys(&address_space_memory, ppc64_phys_to_real(phys + 4*n), val);
> >  }
> >
> >-static inline void rtas_st_buffer_direct(target_ulong phys,
> >-                                         target_ulong phys_len,
> >-                                         uint8_t *buffer, uint16_t buffer_len)
> >-{
> >-    cpu_physical_memory_write(ppc64_phys_to_real(phys), buffer,
> >-                              MIN(buffer_len, phys_len));
> >-}
> >-
> >  typedef void (*spapr_rtas_fn)(PowerPCCPU *cpu, sPAPRMachineState *sm,
> >                                uint32_t token,
> >                                uint32_t nargs, target_ulong args,
> >
> 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-01-19  4:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-16  1:14 [Qemu-devel] [PATCH 0/3] Reduce abuse of rtas_st / rtas_ld David Gibson
2016-01-16  1:14 ` [Qemu-devel] [PATCH 1/3] spapr: Small fixes to rtas_ibm_get_system_parameter, remove rtas_st_buffer David Gibson
2016-01-19  2:00   ` Alexey Kardashevskiy
2016-01-19  3:56     ` David Gibson
2016-01-16  1:14 ` [Qemu-devel] [PATCH 2/3] spapr: Remove rtas_st_buffer_direct() David Gibson
2016-01-19  2:07   ` Alexey Kardashevskiy
2016-01-19  4:08     ` David Gibson [this message]
2016-01-16  1:14 ` [Qemu-devel] [PATCH 3/3] spapr: Remove abuse of rtas_ld() in h_client_architecture_support David Gibson
2016-01-19  2:08   ` Alexey Kardashevskiy
2016-01-17 23:51 ` [Qemu-devel] [PATCH 0/3] Reduce abuse of rtas_st / rtas_ld Alexey Kardashevskiy
2016-01-18  1:24   ` David Gibson

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=20160119040851.GZ9301@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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.