lkml.org 
[lkml]   [2020]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH] gpio: uapi: v2 proposal
    On Sat, May 16, 2020 at 8:45 AM Kent Gibson <warthog618@gmail.com> wrote:

    > Add a new version of the uAPI to address existing 32/64bit alignment
    > issues, add support for debounce, and provide some future proofing by
    > adding padding reserved for future use.
    >
    > Signed-off-by: Kent Gibson <warthog618@gmail.com>

    I don't see any major problems with it, just some comments:

    + * @padding: reserved for future use and should be zero filled

    *MUST* be zerofilled is what it should say.

    > +struct gpioline_config {
    > + __u8 default_values[GPIOLINES_MAX];

    So 32 bytes

    > + __u32 flags;
    > + __u8 direction;
    > + __u8 drive;
    > + __u8 bias;
    > + __u8 edge_detection;

    Some comment in the struc that this adds up to 32 bits?

    > + __u32 debounce;
    > + __u32 padding[7]; /* for future use */

    What we need to do inside the kernel with all of these
    is to ascertain that they are 0 for now when they are
    sent in and refuse them otherwise, I think it was Lars-Peter
    Clausen who said that they had to retire a whole slew of
    ioctl()s because some userspace just used unallocated
    memory for this and since that was random bytes it needed to
    be supported with that content forever and the reserved
    padding could never be used for the reserved purpose.

    This kind of comment goes for all the structs.

    But mostly it is a question about the kernel code receiving
    or emitting these.

    Yours,
    Linus Walleij

    \
     
     \ /
      Last update: 2020-05-25 10:40    [W:3.925 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site