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 --]
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).