On Mon, Dec 09, 2013 at 10:05:40AM -0600, Aaron Sierra wrote:
> This patch updates the vme_master and vme_slave structures to use
> types with well defined size and to prevent the compiler from
> inserting padding (between enable and vme_addr for one).
> 
> The original vme_master and vme_slave structs would be different
> sizes and have different layouts depending on whether they were built
> for a 32-bit or 64-bit system.
> 
> On x86 it is possible to have a 32-bit userspace and a 64-bit kernel.
> In this type of environment, the userspace and kernel vme_user APIs
> would disagree and prevent ioctls from executing (based on ioctl
> signatures from _IOR and _IOW).
> 
> Signed-off-by: Aaron Sierra <asie...@xes-inc.com>
> Acked-by: Martyn Welch <martyn.we...@ge.com>
> ---
>  drivers/staging/vme/devices/vme_user.h |   20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/vme/devices/vme_user.h 
> b/drivers/staging/vme/devices/vme_user.h
> index 280ccc7..c3b4964 100644
> --- a/drivers/staging/vme/devices/vme_user.h
> +++ b/drivers/staging/vme/devices/vme_user.h
> @@ -7,10 +7,10 @@
>   * VMEbus Master Window Configuration Structure
>   */
>  struct vme_master {
> -     int enable;                     /* State of Window */
> -     unsigned long long vme_addr;    /* Starting Address on the VMEbus */
> -     unsigned long long size;        /* Window Size */
> -     u32 aspace;                     /* Address Space */
> +     u32 enable;             /* State of Window */
> +     u64 vme_addr;           /* Starting Address on the VMEbus */
> +     u64 size;               /* Window Size */
> +     u32 aspace;             /* Address Space */

Variable types that cross the user/kernel boundry need to have "__" in
the front of them.  SO these need to be "__u32", "__u64" and the like.
Care to send a patch that fixes this as an add-on to this one (I'll take
this one as it's good on it's own.)

thanks,

greg k-h
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to