All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Michael Tretter <m.tretter@pengutronix.de>,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
Cc: kernel@pengutronix.de,
	Michael Turquette <mturquette@baylibre.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Jolly Shah <jolly.shah@xilinx.com>,
	Michael Tretter <m.tretter@pengutronix.de>
Subject: Re: [PATCH 4/5] clk: zynqmp: cleanup sizes of firmware responses
Date: Wed, 13 Mar 2019 09:37:33 -0700	[thread overview]
Message-ID: <155249505317.20095.16258634766892338311@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20190312110016.29174-5-m.tretter@pengutronix.de>

Quoting Michael Tretter (2019-03-12 04:00:15)
> @@ -248,7 +251,8 @@ static int zynqmp_pm_clock_get_topology(u32 clock_id, u32 index, u32 *topology)
>         qdata.arg2 = index;
>  
>         ret = eemi_ops->query_data(qdata, ret_payload);
> -       memcpy(topology, &ret_payload[1], CLK_GET_TOPOLOGY_RESP_WORDS * 4);
> +       memcpy(topology, &ret_payload[1],
> +              CLK_GET_TOPOLOGY_RESP_WORDS * sizeof(*topology));

It would be even clearer to have a set of structs that encoded what the
responses looked like, instead of having to unmarshal the response
somewhat manually on top of a u32 buffer.

So something like

	struct topology_resp {
		u32 node[3];
	};

and then just use sizeof(*topology_resp). Also, it's odd that we make a
stack local variable for the response in this function and then copy it
onto the stack again for the caller of this function
(zynqmp_clock_get_topology()) and then pass it to the unmarshal function
that copies it the third time into the struct clk_topology. It would be
better to do the copy at most once into some structure that has the data
all packed together and then use the macros to access the fields
wherever the response is used.


WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Michael Tretter <m.tretter@pengutronix.de>,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
Cc: Jolly Shah <jolly.shah@xilinx.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Michal Simek <michal.simek@xilinx.com>,
	kernel@pengutronix.de, Michael Tretter <m.tretter@pengutronix.de>
Subject: Re: [PATCH 4/5] clk: zynqmp: cleanup sizes of firmware responses
Date: Wed, 13 Mar 2019 09:37:33 -0700	[thread overview]
Message-ID: <155249505317.20095.16258634766892338311@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20190312110016.29174-5-m.tretter@pengutronix.de>

Quoting Michael Tretter (2019-03-12 04:00:15)
> @@ -248,7 +251,8 @@ static int zynqmp_pm_clock_get_topology(u32 clock_id, u32 index, u32 *topology)
>         qdata.arg2 = index;
>  
>         ret = eemi_ops->query_data(qdata, ret_payload);
> -       memcpy(topology, &ret_payload[1], CLK_GET_TOPOLOGY_RESP_WORDS * 4);
> +       memcpy(topology, &ret_payload[1],
> +              CLK_GET_TOPOLOGY_RESP_WORDS * sizeof(*topology));

It would be even clearer to have a set of structs that encoded what the
responses looked like, instead of having to unmarshal the response
somewhat manually on top of a u32 buffer.

So something like

	struct topology_resp {
		u32 node[3];
	};

and then just use sizeof(*topology_resp). Also, it's odd that we make a
stack local variable for the response in this function and then copy it
onto the stack again for the caller of this function
(zynqmp_clock_get_topology()) and then pass it to the unmarshal function
that copies it the third time into the struct clk_topology. It would be
better to do the copy at most once into some structure that has the data
all packed together and then use the macros to access the fields
wherever the response is used.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-13 16:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12 11:00 [PATCH 0/5] clk: zynqmp: fix CLK_FRAC and various cleanups Michael Tretter
2019-03-12 11:00 ` Michael Tretter
2019-03-12 11:00 ` [PATCH 1/5] clk: zynqmp: fix check for fractional clock Michael Tretter
2019-03-12 11:00   ` Michael Tretter
2019-03-12 16:49   ` Stephen Boyd
2019-03-12 16:49     ` Stephen Boyd
2019-03-12 17:25     ` Michael Tretter
2019-03-12 17:25       ` Michael Tretter
2019-03-13 16:24       ` Stephen Boyd
2019-03-13 16:24         ` Stephen Boyd
2019-03-14  8:38         ` Michael Tretter
2019-03-14  8:38           ` Michael Tretter
2019-03-14 15:45           ` Stephen Boyd
2019-03-14 15:45             ` Stephen Boyd
2019-03-19  0:56           ` Jolly Shah
2019-03-19  0:56             ` Jolly Shah
2019-03-19 10:19             ` Michael Tretter
2019-03-19 10:19               ` Michael Tretter
2019-03-12 11:00 ` [PATCH 2/5] clk: zynqmp: fix doc of __zynqmp_clock_get_parents Michael Tretter
2019-03-12 11:00   ` Michael Tretter
2019-03-13 14:48   ` Michal Simek
2019-03-13 14:48     ` Michal Simek
2019-03-12 11:00 ` [PATCH 3/5] clk: zynqmp: do not export zynqmp_clk_register_mux Michael Tretter
2019-03-12 11:00   ` Michael Tretter
2019-03-12 16:52   ` Stephen Boyd
2019-03-12 16:52     ` Stephen Boyd
2019-03-12 17:26     ` Michael Tretter
2019-03-12 17:26       ` Michael Tretter
2019-03-12 11:00 ` [PATCH 4/5] clk: zynqmp: cleanup sizes of firmware responses Michael Tretter
2019-03-12 11:00   ` Michael Tretter
2019-03-13 16:37   ` Stephen Boyd [this message]
2019-03-13 16:37     ` Stephen Boyd
2019-03-12 11:00 ` [PATCH 5/5] clk: zynqmp: make field definitions of query responses consistent Michael Tretter
2019-03-12 11:00   ` Michael Tretter
2019-03-12 11:19   ` Michael Tretter
2019-03-12 11:19     ` Michael Tretter
2019-03-19  0:47   ` Jolly Shah
2019-03-19  0:47     ` Jolly Shah
2019-03-13 14:49 ` [PATCH 0/5] clk: zynqmp: fix CLK_FRAC and various cleanups Michal Simek
2019-03-13 14:49   ` Michal Simek

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=155249505317.20095.16258634766892338311@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=jolly.shah@xilinx.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=michal.simek@xilinx.com \
    --cc=mturquette@baylibre.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 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.