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: <CAAfSe-ukBxD2+Q7tuc_jBk3mJjqPpn0DWUKpCOBaN=UaasuEXw@mail.gmail.com>
Date:   Thu, 28 Sep 2023 17:00:46 +0800
From:   Chunyan Zhang <zhang.lyra@...il.com>
To:     Wenhua Lin <Wenhua.Lin@...soc.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andy@...nel.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.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 Thu, 21 Sept 2023 at 20:27, Wenhua Lin <Wenhua.Lin@...soc.com> 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.
>
> 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;

I would suggest just using this one-dimensional array which is enough
for saving 16-bit values.

To solve the issue mentioned in the commit message, we can set/clear
the bit according to the value of 'offset', for example:

pmic_eic->reg[REG_IE] &= ~BIT(offset);

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

For setting operations:

pmic_eic->reg[REG_IE] |= BIT(offset);

>  }
>
>  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]);

When using the array we can deal with it like below since
sprd_pmic_eic_update() would do a shift for the parameter 'val':

(pmic_eic->reg[REG_IEV] & BIT(offset)) ? 1 : 0;

>         }
>
>         /* 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]);

Similar here.

Thanks,
Chunyan