linux-kernel - Re: [v6 12/14] iio: imu: add BNO055 serdev driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Jun 2022 18:52:33 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Andrea Merello <andrea.merello@....it>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Matt Ranostay <matt.ranostay@...sulko.com>,
        Alexandru Ardelean <ardeleanalex@...il.com>,
        jmondi <jacopo@...ndi.org>
Subject: Re: [v6 12/14] iio: imu: add BNO055 serdev driver

On Mon, Jun 13, 2022 at 2:05 PM <andrea.merello@....it> wrote:
>
> From: Andrea Merello <andrea.merello@....it>
>
> Add a serdev driver for communicating to a BNO055 IMU via serial bus, and
> enable the BNO055 core driver to work in this scenario.

...

> + * This driver is besed on

based

> + *     Plantower PMS7003 particulate matter sensor driver
> + *     Which is
> + *     Copyright (c) Tomasz Duszynski <tduszyns@...il.com>

...

> +/*
> + * Read operation overhead:
> + *  4 bytes req + 2byte resp hdr.
> + *  6 bytes = 60 bit (considering 1start + 1stop bits).
> + *  60/115200 = ~520uS + about 2500mS dealay -> ~3mS

delay

> + * In 3mS we could read back about 34 bytes that means 17 samples, this means
> + * that in case of scattered read in which the gap is 17 samples or less it is

reads

> + * still convenient to go for a burst.
> + * We have to take into account also IMU response time - IMU seems to be often
> + * reasonably quick to respond, but sometimes it seems to be in some "critical
> + * section" in which it delays handling of serial protocol. Because of this we
> + * round-up to 22, which is the max number of samples, always bursting indeed.
> + */

...

> +/*
> + * Sends a read or write command.

Send

...

> +/*
> + * Handler for received data; this is called from the reicever callback whenever

receiver

> + * it got some packet from the serial bus. The status tell us whether the

tells

> + * packet is valid (i.e. header ok && received payload len consistent wrt the
> + * header). It's now our responsability to check whether this is what we

responsibility

> + * expected, of whether we got some unexpected, yet valid, packet.
> + */

...

> +               /*
> +                * New packet.
> +                * Check for its 1st byte, that identifies the pkt type.

byte that

> +                */

-- 
With Best Regards,
Andy Shevchenko