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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ