Re: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support

[Michael Walle]

Hi,

On Thu Jul 16, 2026 at 8:26 AM CEST, Yu-Chun Lin wrote:
>>> > @@ -185,7 +218,7 @@ static int gpio_regmap_set_direction(struct
>>> gpio_chip *chip,
>>> >                                    unsigned int offset, bool output)
>>> > {
>>> >       struct gpio_regmap *gpio = gpiochip_get_data(chip);
>>> > -     unsigned int base, val, reg, mask;
>>> > +     unsigned int base, val, reg, mask, wren_mask;
>>> >       int invert, ret;
>>> >
>>> >       if (gpio->reg_dir_out_base) {
>>> > @@ -198,7 +231,12 @@ static int gpio_regmap_set_direction(struct
>>> gpio_chip *chip,
>>> >               return -ENOTSUPP;
>>> >       }
>>> >
>>> > -     ret = gpio->reg_mask_xlate(gpio, base, offset, &reg, &mask);
>>> > +     ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_OP, base,
>>> offset, &reg, &mask);
>>> > +     if (ret)
>>> > +             return ret;
>>> > +
>>> > +     ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP,
>>> base, offset, &reg,
>>> > +                                &wren_mask);
>>> 
>>> What constrains these two to provide the same value back for reg?
>>> To me it seems like the write enable might well be in a different register.
>>> 
>>> >       if (ret)
>>> >               return ret;
>>> >
>>> > @@ -207,7 +245,7 @@ static int gpio_regmap_set_direction(struct
>>> gpio_chip *chip,
>>> >       else
>>> >               val = output ? mask : 0;
>>> >
>>> > -     return regmap_update_bits(gpio->regmap, reg, mask, val);
>>> > +     return regmap_update_bits(gpio->regmap, reg, mask | wren_mask,
>>> > + val | wren_mask);
>>> >  }
>>> >
>>> >  static int gpio_regmap_direction_input(struct gpio_chip *chip,
>>
>> My initial design indeed assumed that the WREN mask and Data mask reside in
>> the same register.
>>  
>> Regarding WREN support, especially if WREN and Data use separate registers, I
>> came up with three ideas. Which direction do you prefer?
>>  
>> Approach 1: Provide Custom Callbacks in config (Let consumer driver handle it)
>> We can add '.set' and '.set_direction' function pointers in
>> 'struct gpio_regmap_config'. If a driver requires WREN, it can implement these
>> callbacks itself.
>> 
>> static void gpio_regmap_set(struct gpio_chip *chip, unsigned int offset, int val)
>> {
>>         struct gpio_regmap *gpio = gpiochip_get_data(chip);
>>  
>>         /* If the driver provides a custom set (to handle WREN), delegate to it */
>>         if (gpio->set) {
>>                 gpio->set(chip, offset, val);
>>                 return;
>>         }
>>         /* ... existing generic regmap logic ... */
>> }
>>
>> Pros: Clean core, no need to touch existing drivers' xlate signature. The consumer
>> driver handles its own locking for different registers.
>> Cons: It feels a bit strange and inconsistent to expose only '.set' and
>> '.set_direction' overrides while keeping other operations entirely abstracted.
>>  
>> Approach 2: Handle separate WREN register in the core (with locking concerns)
>> We keep the 'XX_WREN_OP' in 'xlate'. If someone needs WREN and 'wren_reg != reg',
>> we write to both.
>>  
>> static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
>>                            int val)
>> {
>>         /* skip */
>>         ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, &wren_reg,
>>                                    &wren_mask);
>>         if (ret == -ENOTSUPP)
>>                 has_wren = false;
>>         else if (ret)
>>                 return ret;
>> 
>>        ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_OP, base, offset, &reg, &mask);
>> 
>>        if (has_wren && reg == wren_reg) {
>>                mask |= wren_mask;
>>                mask_val |= wren_mask;
>>                has_wren = false;
>>        }
>> 
>>        if (has_wren)
>>                ret = regmap_set_bits(gpio->regmap, wren_reg, wren_mask); 
>> 
>>         /* ignore input values which shadow the old output value */
>>         if (gpio->reg_dat_base == gpio->reg_set_base)
>>                 ret = regmap_write_bits(gpio->regmap, reg, mask, mask_val);
>>         else
>>                 ret = regmap_update_bits(gpio->regmap, reg, mask, mask_val);
>>  
>>         return ret;
>> }
>>  
>> Pros: Keeps all WREN logic unified inside the core framework.
>> Cons: Introduces a locking issue. writing to 'wren_reg' and then 'reg' requires an
>> external lock to be atomic, which seems to defeat the purpose of relying on regmap's
>> internal lock. 
>> 
>> Approach 3: Assume WREN and Data always share the same register
>> 
>> static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset, int val)
>> {
>>         /* ... */
>>         ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, &reg, &wren_mask);
>>         if (ret == -ENOTSUPP)
>>                 wren_mask = 0;
>>         else if (ret)
>>                 return ret;
>>  
>>         ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_OP, base, offset, &reg, &mask);
>>  
>>         ret = regmap_update_bits(gpio->regmap, reg, mask | wren_mask, mask_val | wren_mask);
>>         return ret;
>> }
>>  
>> Regarding this approach, I would like to ask from your experience: Is it
>> actually common for hardware designs to place WREN and Data bits in completely
>> different registers for GPIO operations?

I'd say that such a write enable bit by itself is pretty uncommon
for a gpio controller, regardless if it's in the same register or in
a different one.

>> If they practically always share the same register, this simpler approach might
>> suffice.

It seems, that your hardware has it in one register. Why do you need
a separate mask anyway? Why can't the xlate callback just set the
bit in addition to the gpio bit? It looks like in the end you're
doing a "mask |  wren_mask" anyway. What am I missing here?

-michael