linux-kernel - Re: [PATCH v7 2/2] iio: light: Add support for ltrf216a sensor

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 11 Jul 2022 16:22:37 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Dmitry Osipenko <dmitry.osipenko@...labora.com>
Cc:     Shreeya Patel <shreeya.patel@...labora.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>, Zhigang.Shi@...eon.com,
        krisman@...labora.com, linux-iio <linux-iio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Collabora Kernel ML <kernel@...labora.com>,
        alvaro.soliverez@...labora.com
Subject: Re: [PATCH v7 2/2] iio: light: Add support for ltrf216a sensor

On Mon, Jul 11, 2022 at 4:04 PM Dmitry Osipenko
<dmitry.osipenko@...labora.com> wrote:
> On 7/11/22 16:41, Andy Shevchenko wrote:
> > On Mon, Jul 11, 2022 at 3:39 PM Shreeya Patel
> > <shreeya.patel@...labora.com> wrote:
> >> On 11/07/22 18:36, Andy Shevchenko wrote:
> >>> On Mon, Jul 11, 2022 at 1:30 PM Shreeya Patel

...

> >>>> +static const struct regmap_config ltrf216a_regmap_config = {
> >>>> +       .name = LTRF216A_DRV_NAME,
> >>>> +       .reg_bits = 8,
> >>>> +       .val_bits = 8,
> >>>> +       .max_register = LTRF216A_MAX_REG,
> >>> Why do you use regmap locking? What for?
> >>
> >> Why do we want to skip the internal locking if it doesn't bring any
> >> benefits?
> >
> > Can you elaborate on the "no benefits" part, please?
>
> Since the regmap's lock will never be contended, thus it's free to keep

I'm skeptical about "free" here. My concerns are:
1) grosser code base;
2) slower code flow (even nop takes time to process).

> using it. If later on we will need to change the driver's code such that
> the lock will become needed, then we won't need to bother with
> re-enabling it. The comment to the driver's mutex states clearly that
> it's intended to protect the cached value.
>
> Hence what is point in disabling the regmap's lock? There are very few
> drivers that disable the regmap's lock and most of them do that for the
> good reason.

Most of the drivers that have its own lock _and_ regmap lock took the
locking scheme wrong. It is 101 when writing a driver to have a clear
picture of what lock protects what data (or I/O).

Even if lock is _almost_ free, it's still required to provide
understanding of how each of the locks is being used in the code.

That said, the main point of my review comment is to make the author
think about it, or just elaborate if it has been thought through
already.

-- 
With Best Regards,
Andy Shevchenko