All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
	George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
	jbeulich@suse.com
Subject: Re: [PATCH for 4.7] pvusb: add missing definition to usbif.h
Date: Thu, 5 May 2016 10:02:25 +0100	[thread overview]
Message-ID: <20160505090225.GY2111@citrix.com> (raw)
In-Reply-To: <1462430205-21346-1-git-send-email-jgross@suse.com>

On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
> The pvusb request structure contains the transfer_flags member which
> is missing definitions of it's semantics.
> 
> Add the definition of the USBIF_SHORT_NOT_OK flag.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> Please consider taking this patch for 4.7 release. I believe this is the
> last bit missing for support of qemu based pvusb backend. The risk of the
> patch should be zero, as no Xen component is using this header.
> ---
>  xen/include/public/io/usbif.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/include/public/io/usbif.h b/xen/include/public/io/usbif.h
> index 9ef0cdc..4053c24 100644
> --- a/xen/include/public/io/usbif.h
> +++ b/xen/include/public/io/usbif.h
> @@ -187,6 +187,7 @@ struct usbif_urb_request {
>  	/* basic urb parameter */
>  	uint32_t pipe;
>  	uint16_t transfer_flags;
> +#define USBIF_SHORT_NOT_OK	0x0001

Where does this come from? Should it be surrounded by define guard?

#ifndef USBIF_SHORT_NOT_OK
#define USBIF_SHORT_NOT_OK 0x0001
#endif

Why does it need to be in our public header? If we end up taking this
I think it should at least start with XEN_ prefix.

>  	uint16_t buffer_length;
>  	union {
>  		uint8_t ctrl[8]; /* setup_packet (Ctrl) */
> -- 
> 2.6.6
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-05-05  9:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-05  6:36 [PATCH for 4.7] pvusb: add missing definition to usbif.h Juergen Gross
2016-05-05  9:02 ` Wei Liu [this message]
2016-05-05  9:10   ` Juergen Gross
2016-05-05  9:22     ` Wei Liu
2016-05-06  5:01       ` Juergen Gross
2016-05-06  7:49         ` Jan Beulich
2016-05-06  7:56           ` Jan Beulich
2016-05-06  9:48             ` Wei Liu
2016-05-06  9:48         ` Wei Liu

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=20160505090225.GY2111@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.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.