linux-kernel - Re: [PATCH 1/3] iio: light: Add driver for ap3216c

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]

Message-ID: <CAGngYiXPsj-TAZxC43UtAZYTkbztFtDB-z4jW29CthmaoeNy_w@mail.gmail.com>
Date:   Mon, 11 Feb 2019 14:29:58 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Robert Eshleman <bobbyeshleman@...il.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-iio@...r.kernel.org
Subject: Re: [PATCH 1/3] iio: light: Add driver for ap3216c

On Sun, Feb 10, 2019 at 3:39 PM Robert Eshleman <bobbyeshleman@...il.com> wrote:
>
> This patch adds support for the ap3216c ambient light and proximity
> sensor.

PS

Why not use the chip in the mode where the interrupt is automatically cleared by
reading the data? This could work if you read the data in the
interrupt routine, store
it in a buffer, then send the event to iio. Then when userspace wants
to read out the
value, don't actually touch the hardware, but return the buffered value.

I don't think you then need any synchronization primitives to
accomplish this, such as
mutexes, spin locks, etc. Because the interrupt routine is single-threaded.

You don't even need a memory barrier for the buffered value,
because the iio core uses a waitqueue internally, which automatically issues
an mb(). As far as I know.