[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <926ce818-4f42-898d-aca8-185b5c7434ba@collabora.com>
Date: Mon, 23 May 2022 10:58:47 +0200
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: matthias.bgg@...il.com, mkorpershoek@...libre.com,
linux-input@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] Input: mtk-pmic-keys - Use regmap_{set,clear}_bits
where possible
Il 23/05/22 06:51, Dmitry Torokhov ha scritto:
> On Fri, May 20, 2022 at 02:51:29PM +0200, AngeloGioacchino Del Regno wrote:
>> Instead of always using regmap_update_bits(), let's go for the shorter
>> regmap_set_bits() and regmap_clear_bits() where possible.
>>
>> No functional change.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> ---
>> drivers/input/keyboard/mtk-pmic-keys.c | 24 ++++++------------------
>> 1 file changed, 6 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
>> index 8e4fa7cd16e6..83d0b90cc8cb 100644
>> --- a/drivers/input/keyboard/mtk-pmic-keys.c
>> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
>> @@ -157,28 +157,16 @@ static void mtk_pmic_keys_lp_reset_setup(struct mtk_pmic_keys *keys,
>>
>> switch (long_press_mode) {
>> case LP_ONEKEY:
>> - regmap_update_bits(keys->regmap, pmic_rst_reg,
>> - MTK_PMIC_PWRKEY_RST,
>> - MTK_PMIC_PWRKEY_RST);
>> - regmap_update_bits(keys->regmap, pmic_rst_reg,
>> - MTK_PMIC_HOMEKEY_RST,
>> - 0);
>> + regmap_set_bits(keys->regmap, pmic_rst_reg, MTK_PMIC_PWRKEY_RST);
>> + regmap_clear_bits(keys->regmap, pmic_rst_reg, MTK_PMIC_HOMEKEY_RST);
>
> Why not combine this into a single update instead? I.e. assuming
>
All downstream kernels (at least, I checked 4 different kernel versions for 4
different SoCs) are doing these updates one-at-a-time, never combining them.
Even though I agree with you about one single update being simply more logical,
I am afraid that (on some SoCs) the IP will not like that so - since I don't have
any *clear* documentation saying that this is possible, or that this is not, I
would leave it like that.
> #define MTK_PMIC_KEY_RST_MASK GENMASK(6, 5)
>
> regmap_update_bits(keys->regmap, pmic_rst_reg,
> MTK_PMIC_KEY_RST_MASK,
> MTK_PMIC_PWRKEY_RST);
>
>> break;
>> case LP_TWOKEY:
>> - regmap_update_bits(keys->regmap, pmic_rst_reg,
>> - MTK_PMIC_PWRKEY_RST,
>> - MTK_PMIC_PWRKEY_RST);
>> - regmap_update_bits(keys->regmap, pmic_rst_reg,
>> - MTK_PMIC_HOMEKEY_RST,
>> - MTK_PMIC_HOMEKEY_RST);
>> + regmap_set_bits(keys->regmap, pmic_rst_reg, MTK_PMIC_PWRKEY_RST);
>> + regmap_set_bits(keys->regmap, pmic_rst_reg, MTK_PMIC_HOMEKEY_RST);
>
> regmap_update_bits(keys->regmap, pmic_rst_reg,
> MTK_PMIC_KEY_RST_MASK,
> MTK_PMIC_PWRKEY_RST | MTK_PMIC_HOMEKEY_RST);
>
>> break;
>> case LP_DISABLE:
>> - regmap_update_bits(keys->regmap, pmic_rst_reg,
>> - MTK_PMIC_PWRKEY_RST,
>> - 0);
>> - regmap_update_bits(keys->regmap, pmic_rst_reg,
>> - MTK_PMIC_HOMEKEY_RST,
>> - 0);
>> + regmap_clear_bits(keys->regmap, pmic_rst_reg, MTK_PMIC_PWRKEY_RST);
>> + regmap_clear_bits(keys->regmap, pmic_rst_reg, MTK_PMIC_HOMEKEY_RST);
>
> regmap_update_bits(keys->regmap, pmic_rst_reg,
> MTK_PMIC_KEY_RST_MASKi, 0);
>
>> break;
>> default:
>> break;
>> --
>> 2.35.1
>>
>
> Thanks.
>
Powered by blists - more mailing lists