linux-kernel - Re: [PATCH V2 1/2] gpio: pmic-eic-sprd: Two-dimensional arrays maintain pmic eic

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: <99dc2f99-cb03-bec8-b538-3ad21750adff@linux.alibaba.com>
Date:   Wed, 27 Sep 2023 17:49:11 +0800
From:   Baolin Wang <baolin.wang@...ux.alibaba.com>
To:     Chunyan Zhang <zhang.lyra@...il.com>
Cc:     Wenhua Lin <Wenhua.Lin@...soc.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andy@...nel.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Orson Zhai <orsonzhai@...il.com>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        wenhua lin <wenhua.lin1994@...il.com>,
        Xiongpeng Wu <xiongpeng.wu@...soc.com>
Subject: Re: [PATCH V2 1/2] gpio: pmic-eic-sprd: Two-dimensional arrays
 maintain pmic eic



On 9/27/2023 5:24 PM, Chunyan Zhang wrote:
> On Wed, 27 Sept 2023 at 17:04, Baolin Wang
> <baolin.wang@...ux.alibaba.com> wrote:
>>
>>
>>
>> On 9/21/2023 8:25 PM, Wenhua Lin wrote:
>>> A bank PMIC EIC contains 16 EICs, and the operating registers
>>> are BIT0-BIT15, such as BIT0 of the register operated by EIC0.
>>> Using the one-dimensional array reg[CACHE_NR_REGS] for maintenance
>>> will cause the configuration of other EICs to be affected when
>>> operating a certain EIC. In order to solve this problem, the register
>>> operation bits of each PMIC EIC are maintained through the two-dimensional
>>> array reg[SPRD_PMIC_EIC_NR][CACHE_NR_REGS] to avoid mutual interference.
>>
>> LGTM. And this also deserves a Fixes tag.
> 
> Do we really need a two-dimensional array to save 16-bit value?

I also considering this, but after more thinking, I think this patch is 
a simple fix.

Now I realized the problem is that, if we use one array to cache a bank 
of EICs' status, the pmic_eic->reg[] array can contain incorrect 
configuration for other EICs in the same bank.

Yes, we can have another fix, for example, setting the pmic_eic->reg[] 
to some invalid values (maybe -1) in sprd_pmic_eic_bus_sync_unlock() 
after setting one EIC. Thus when setting another EIC, we can validate if 
the cached reg is a valid value, if not, we do not need to set the 
register. But like I said above, this seems more complicated.

>> Reviewed-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
>>
>>> Signed-off-by: Wenhua Lin <Wenhua.Lin@...soc.com>
>>> ---
>>>    drivers/gpio/gpio-pmic-eic-sprd.c | 21 +++++++++++----------
>>>    1 file changed, 11 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-pmic-eic-sprd.c b/drivers/gpio/gpio-pmic-eic-sprd.c
>>> index c3e4d90f6b18..442968bb2490 100644
>>> --- a/drivers/gpio/gpio-pmic-eic-sprd.c
>>> +++ b/drivers/gpio/gpio-pmic-eic-sprd.c
>>> @@ -57,7 +57,7 @@ struct sprd_pmic_eic {
>>>        struct gpio_chip chip;
>>>        struct regmap *map;
>>>        u32 offset;
>>> -     u8 reg[CACHE_NR_REGS];
>>> +     u8 reg[SPRD_PMIC_EIC_NR][CACHE_NR_REGS];
>>>        struct mutex buslock;
>>>        int irq;
>>>    };
>>> @@ -151,8 +151,8 @@ static void sprd_pmic_eic_irq_mask(struct irq_data *data)
>>>        struct sprd_pmic_eic *pmic_eic = gpiochip_get_data(chip);
>>>        u32 offset = irqd_to_hwirq(data);
>>>
>>> -     pmic_eic->reg[REG_IE] = 0;
>>> -     pmic_eic->reg[REG_TRIG] = 0;
>>> +     pmic_eic->reg[offset][REG_IE] = 0;
>>> +     pmic_eic->reg[offset][REG_TRIG] = 0;
>>>
>>>        gpiochip_disable_irq(chip, offset);
>>>    }
>>> @@ -165,8 +165,8 @@ static void sprd_pmic_eic_irq_unmask(struct irq_data *data)
>>>
>>>        gpiochip_enable_irq(chip, offset);
>>>
>>> -     pmic_eic->reg[REG_IE] = 1;
>>> -     pmic_eic->reg[REG_TRIG] = 1;
>>> +     pmic_eic->reg[offset][REG_IE] = 1;
>>> +     pmic_eic->reg[offset][REG_TRIG] = 1;
>>>    }
>>>
>>>    static int sprd_pmic_eic_irq_set_type(struct irq_data *data,
>>> @@ -174,13 +174,14 @@ static int sprd_pmic_eic_irq_set_type(struct irq_data *data,
>>>    {
>>>        struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
>>>        struct sprd_pmic_eic *pmic_eic = gpiochip_get_data(chip);
>>> +     u32 offset = irqd_to_hwirq(data);
>>>
>>>        switch (flow_type) {
>>>        case IRQ_TYPE_LEVEL_HIGH:
>>> -             pmic_eic->reg[REG_IEV] = 1;
>>> +             pmic_eic->reg[offset][REG_IEV] = 1;
>>>                break;
>>>        case IRQ_TYPE_LEVEL_LOW:
>>> -             pmic_eic->reg[REG_IEV] = 0;
>>> +             pmic_eic->reg[offset][REG_IEV] = 0;
>>>                break;
>>>        case IRQ_TYPE_EDGE_RISING:
>>>        case IRQ_TYPE_EDGE_FALLING:
>>> @@ -222,15 +223,15 @@ static void sprd_pmic_eic_bus_sync_unlock(struct irq_data *data)
>>>                        sprd_pmic_eic_update(chip, offset, SPRD_PMIC_EIC_IEV, 1);
>>>        } else {
>>>                sprd_pmic_eic_update(chip, offset, SPRD_PMIC_EIC_IEV,
>>> -                                  pmic_eic->reg[REG_IEV]);
>>> +                                  pmic_eic->reg[offset][REG_IEV]);
>>>        }
>>>
>>>        /* Set irq unmask */
>>>        sprd_pmic_eic_update(chip, offset, SPRD_PMIC_EIC_IE,
>>> -                          pmic_eic->reg[REG_IE]);
>>> +                          pmic_eic->reg[offset][REG_IE]);
>>>        /* Generate trigger start pulse for debounce EIC */
>>>        sprd_pmic_eic_update(chip, offset, SPRD_PMIC_EIC_TRIG,
>>> -                          pmic_eic->reg[REG_TRIG]);
>>> +                          pmic_eic->reg[offset][REG_TRIG]);
>>>
>>>        mutex_unlock(&pmic_eic->buslock);
>>>    }