lkml.org 
[lkml]   [2019]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 5/7] bcm-vk: add bcm_vk UAPI
On Thu, Aug 22, 2019 at 9:25 PM Scott Branden
<scott.branden@broadcom.com> wrote:
>
> Add user space api for bcm-vk driver.

> +
> +struct vk_metadata {
> + /* struct version, always backwards compatible */
> + __u32 version;
> +
> + /* Version 0 fields */
> + __u32 card_status;
> +#define VK_CARD_STATUS_FASTBOOT_READY BIT(0)
> +#define VK_CARD_STATUS_FWLOADER_READY BIT(1)
> +
> + __u32 firmware_version;
> + __u32 fw_status;
> + /* End version 0 fields */
> +
> + __u64 reserved[14];
> + /* Total of 16*u64 for all versions */
> +};

I'd suggest getting rid of the API version fields, just leave the version 0
fields here and add a new structure + ioctl if you need other
fields

Versioning usually just adds complexity and is hard to get right.

> +struct vk_access {
> + __u8 barno; /* BAR number to use */
> + __u8 type; /* Type of access */
> +#define VK_ACCESS_READ 0
> +#define VK_ACCESS_WRITE 1
> + __u32 len; /* length of data */
> + __u64 offset; /* offset in BAR */
> + __u32 *data; /* where to read/write data to */
> +};

The pointer in the last member makes the structure incompatible between
32-bit and 64-bit user space. You could work around that using a __u64
member and turning that into a pointer using the u64_to_user_ptr()
macro in the driver in a portable way.

However, since this seems to be a read/write type interface, maybe
it's better to just use read/write file operations.

I also wonder if the interface should be on a higher abstraction level
here.

Arnd

\
 
 \ /
  Last update: 2019-08-27 15:56    [W:0.618 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site