From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: [PATCH v7 05/28] xen/arm: ITS: Port ITS driver to
 Xen
Date: Mon, 21 Sep 2015 12:23:25 +0100
Message-ID: <55FFE8AD.9060208@citrix.com>
References: <1442581755-2668-1-git-send-email-vijay.kilari@gmail.com>
	<1442581755-2668-6-git-send-email-vijay.kilari@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1442581755-2668-6-git-send-email-vijay.kilari@gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: vijay.kilari@gmail.com, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com, stefano.stabellini@citrix.com, tim@xen.org, xen-devel@lists.xen.org
Cc: Prasun.Kapoor@caviumnetworks.com, Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>, manish.jaggi@caviumnetworks.com
List-Id: xen-devel@lists.xenproject.org

Hi Vijay,

The only things I haven't check on this patch was the ITS command structure.

On 18/09/15 14:08, vijay.kilari@gmail.com wrote:
> +/* ITS command structure */
> +typedef union {

Can you please sort this union by command name in alphabetical order.
It's way easier to find a command in the list.

> +    u64 bits[4];
> +    struct __packed {
> +        uint8_t cmd;

NIT: Please stay consistent with usage of the type. You are using u8
everywhere within this union except here.

> +        uint8_t pad[7];

Why a padding of only 56 bits? Shouldn't it be 248 bits (i.e 31 * 8
bits) to fit all the command?

> +    } hdr;
> +    struct __packed {
> +        u8 cmd;
> +        u8 res1[3];
> +        u32 devid;
> +        u64 size:5;
> +        u64 res2:59;
> +        /* XXX: Though itt is 40 bit. Keep it 48 to avoid shift */
> +        u64 res3:8;

It's very confusing for the reviewer to see a mix of usage (u8 res1[n],
u64 res3:8) within the same structure.

The later (i.e u64 field:n) is the best to use because we can match
quickly the size with the spec.

> +        u64 itt:40;
> +        u64 res4:15;
> +        u64 valid:1;
> +        u64 res5;
> +    } mapd;

[..]

> +    struct __packed {
> +        u8 cmd;
> +        u8 res1[3];
> +        u32 devid;
> +        u32 event;
> +        u32 res2;
> +        u64 res3;
> +        u64 res4;
> +    } int_cmd;

Maybe you want to add the suffix _cmd to everyone to avoid having only
one because of C spec issue.

> +    struct __packed {
> +        u8 cmd;
> +        u8 res1[3];
> +        u32 devid;
> +        u32 event;
> +        u32 res2;
> +        u64 res3;
> +        u64 res4;
> +    } clear;
> +    struct __packed {
> +        u8 cmd;
> +        u8 res1[7];
> +        u64 res2;
> +        u16 res3;
> +        u32 ta;

It would have been better to have a full name or a description rather
than only a 2 letter field "ta". I won't ask for a documentation of this
field right now, but it would be a nice follow-up of this series.

> +        u16 res4;
> +        u64 res5;
> +    } sync;
> +} its_cmd_block;


Regards,

-- 
Julien Grall