Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <68de450f-da22-02e3-e863-7e17582ee03f@collabora.com>
Date:   Mon, 11 Jul 2022 17:04:04 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH v7 2/2] iio: light: Add support for ltrf216a sensor
Content-Language: en-US
To:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Shreeya Patel <shreeya.patel@collabora.com>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Rob Herring <robh+dt@kernel.org>, Zhigang.Shi@liteon.com,
        krisman@collabora.com, linux-iio <linux-iio@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Collabora Kernel ML <kernel@collabora.com>,
        alvaro.soliverez@collabora.com
References: <20220711112900.61363-1-shreeya.patel@collabora.com>
 <20220711112900.61363-3-shreeya.patel@collabora.com>
 <CAHp75Vf3NDsep5_819=e8yrna_AGh5cew=fs+hHe1q8LCa-PyA@mail.gmail.com>
 <c90e7334-5921-886b-2f9c-869fb55216ca@collabora.com>
 <CAHp75Vf=FOt+N6azar5gifvig8FL4sS3LX1kO8CzNCh2yOk-DQ@mail.gmail.com>
From:   Dmitry Osipenko <dmitry.osipenko@collabora.com>
In-Reply-To: <CAHp75Vf=FOt+N6azar5gifvig8FL4sS3LX1kO8CzNCh2yOk-DQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/11/22 16:41, Andy Shevchenko wrote:
> On Mon, Jul 11, 2022 at 3:39 PM Shreeya Patel
> <shreeya.patel@collabora.com> wrote:
>> On 11/07/22 18:36, Andy Shevchenko wrote:
>>> On Mon, Jul 11, 2022 at 1:30 PM Shreeya Patel
> 
> Please, remove unneeded context when replying!
> 
> ...
> 
>>>> +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
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.

-- 
Best regards,
Dmitry