From: Oliver O'Halloran <oohall@gmail.com>
To: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>,
Jeremy Kerr <jk@ozlabs.org>
Subject: Re: [PATCH v3 1/2] powerpc/powernv: Enhance opal message read interface
Date: Thu, 22 Aug 2019 15:51:41 +1000 [thread overview]
Message-ID: <8446e4f922a140b9fcba60a37105a4090b7b1681.camel@gmail.com> (raw)
In-Reply-To: <20190821081335.20103-1-hegdevasant@linux.vnet.ibm.com>
On Wed, 2019-08-21 at 13:43 +0530, Vasant Hegde wrote:
> Use "opal-msg-size" device tree property to allocate memory for "opal_msg".
>
> Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> Cc: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
> ---
> Changes in v3:
> - Call BUG_ON, if we fail to allocate memory during init.
>
> -Vasant
>
> arch/powerpc/platforms/powernv/opal.c | 29 ++++++++++++++++++---------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index aba443be7daa..4f1f68f568bf 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -58,6 +58,8 @@ static DEFINE_SPINLOCK(opal_write_lock);
> static struct atomic_notifier_head opal_msg_notifier_head[OPAL_MSG_TYPE_MAX];
> static uint32_t opal_heartbeat;
> static struct task_struct *kopald_tsk;
> +static struct opal_msg *opal_msg;
> +static uint64_t opal_msg_size;
>
> void opal_configure_cores(void)
> {
> @@ -271,14 +273,9 @@ static void opal_message_do_notify(uint32_t msg_type, void *msg)
> static void opal_handle_message(void)
> {
> s64 ret;
> - /*
> - * TODO: pre-allocate a message buffer depending on opal-msg-size
> - * value in /proc/device-tree.
> - */
> - static struct opal_msg msg;
> u32 type;
>
> - ret = opal_get_msg(__pa(&msg), sizeof(msg));
> + ret = opal_get_msg(__pa(opal_msg), opal_msg_size);
> /* No opal message pending. */
> if (ret == OPAL_RESOURCE)
> return;
> @@ -290,14 +287,14 @@ static void opal_handle_message(void)
> return;
> }
>
> - type = be32_to_cpu(msg.msg_type);
> + type = be32_to_cpu(opal_msg->msg_type);
>
> /* Sanity check */
> if (type >= OPAL_MSG_TYPE_MAX) {
> pr_warn_once("%s: Unknown message type: %u\n", __func__, type);
> return;
> }
> - opal_message_do_notify(type, (void *)&msg);
> + opal_message_do_notify(type, (void *)opal_msg);
> }
>
> static irqreturn_t opal_message_notify(int irq, void *data)
> @@ -306,9 +303,21 @@ static irqreturn_t opal_message_notify(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static int __init opal_message_init(void)
> +static int __init opal_message_init(struct device_node *opal_node)
> {
> int ret, i, irq;
> + const __be32 *val;
> +
> + val = of_get_property(opal_node, "opal-msg-size", NULL);
> + if (val)
> + opal_msg_size = be32_to_cpup(val);
Use of_property_read_u32()
> +
> + /* If opal-msg-size property is not available then use default size */
> + if (!opal_msg_size)
> + opal_msg_size = sizeof(struct opal_msg);
> +
> + opal_msg = kmalloc(opal_msg_size, GFP_KERNEL);
> + BUG_ON(opal_msg == NULL);
Seems questionable. Why not fall back to using a staticly allocated
struct opal_msg? Or re-try the allocation with the size limited to
sizeof(struct opal_msg)?
> for (i = 0; i < OPAL_MSG_TYPE_MAX; i++)
> ATOMIC_INIT_NOTIFIER_HEAD(&opal_msg_notifier_head[i]);
> @@ -910,7 +919,7 @@ static int __init opal_init(void)
> }
>
> /* Initialise OPAL messaging system */
> - opal_message_init();
> + opal_message_init(opal_node);
>
> /* Initialise OPAL asynchronous completion interface */
> opal_async_comp_init();
next prev parent reply other threads:[~2019-08-22 5:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 8:13 [PATCH v3 1/2] powerpc/powernv: Enhance opal message read interface Vasant Hegde
2019-08-21 8:13 ` [PATCH v3 2/2] powerpc/powernv: Add new opal message type Vasant Hegde
2019-08-22 5:51 ` Oliver O'Halloran [this message]
2019-08-22 15:36 ` [PATCH v3 1/2] powerpc/powernv: Enhance opal message read interface Vasant Hegde
2019-08-23 4:10 ` Vasant Hegde
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=8446e4f922a140b9fcba60a37105a4090b7b1681.camel@gmail.com \
--to=oohall@gmail.com \
--cc=hegdevasant@linux.vnet.ibm.com \
--cc=jk@ozlabs.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.vnet.ibm.com \
/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).