Linux GPIO subsystem development
 help / color / mirror / Atom feed
From: Song Chen <chensong_2000@189.cn>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: krzk@kernel.org, lgirdwood@gmail.com, broonie@kernel.org,
	lee@kernel.org, linus.walleij@linaro.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v2] regulator:s5m8767: Fully convert to GPIO descriptors
Date: Thu, 12 Dec 2024 13:55:35 +0800	[thread overview]
Message-ID: <efade71b-76ce-4dfe-949e-b231b3e411f0@189.cn> (raw)
In-Reply-To: <CAMRc=MfpwuMh-MH1UEHKky09iAs4g9=iGFPptARXzoZrVS8hdQ@mail.gmail.com>



在 2024/12/11 21:51, Bartosz Golaszewski 写道:
> On Wed, Dec 11, 2024 at 6:10 AM Song Chen <chensong_2000@189.cn> wrote:
>>
>> This converts s5m8767 regulator driver to use GPIO descriptors.
>>
>> ---
>> v1 - v2:
>> 1, reedit commit message.
>> 2, remove development code.
>> 3, print error msg in dev_err_probe.
>> 4, doesn't set gpiod directions until successfully requesting
>>     all gpiods. It's pretty much equivalent with original code.
>>
>> Signed-off-by: Song Chen <chensong_2000@189.cn>
>> ---
>>   drivers/regulator/s5m8767.c      | 106 ++++++++++++++-----------------
>>   include/linux/mfd/samsung/core.h |   4 +-
>>   2 files changed, 48 insertions(+), 62 deletions(-)
>>
>> diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
>> index d25cd81e3f36..b23df037336b 100644
>> --- a/drivers/regulator/s5m8767.c
>> +++ b/drivers/regulator/s5m8767.c
>> @@ -5,7 +5,7 @@
>>
>>   #include <linux/cleanup.h>
>>   #include <linux/err.h>
>> -#include <linux/of_gpio.h>
>> +#include <linux/of.h>
>>   #include <linux/gpio/consumer.h>
>>   #include <linux/module.h>
>>   #include <linux/platform_device.h>
>> @@ -35,8 +35,8 @@ struct s5m8767_info {
>>          u8 buck2_vol[8];
>>          u8 buck3_vol[8];
>>          u8 buck4_vol[8];
>> -       int buck_gpios[3];
>> -       int buck_ds[3];
>> +       struct gpio_desc *buck_gpios[3];
>> +       struct gpio_desc *buck_ds[3];
>>          int buck_gpioindex;
>>   };
>>
>> @@ -272,9 +272,9 @@ static inline int s5m8767_set_high(struct s5m8767_info *s5m8767)
>>   {
>>          int temp_index = s5m8767->buck_gpioindex;
>>
>> -       gpio_set_value(s5m8767->buck_gpios[0], (temp_index >> 2) & 0x1);
>> -       gpio_set_value(s5m8767->buck_gpios[1], (temp_index >> 1) & 0x1);
>> -       gpio_set_value(s5m8767->buck_gpios[2], temp_index & 0x1);
>> +       gpiod_set_value(s5m8767->buck_gpios[0], (temp_index >> 2) & 0x1);
>> +       gpiod_set_value(s5m8767->buck_gpios[1], (temp_index >> 1) & 0x1);
>> +       gpiod_set_value(s5m8767->buck_gpios[2], temp_index & 0x1);
>>
> 
> It seems to me that these GPIOs are always manipulated at once. Maybe
> consider adding fwnode_gpiod_get_index_array() to GPIO core and using
> it here to shrink the code a bit more?
> 
> Bart
> 

If I understand you correctly, you mean introducing 
devm_fwnode_gpiod_get_index_array and in s5m8767_set_high calling 
gpiod_set_array_value to control s5m8767->buck_gpios.

That is a good point and i can give it a try, but i'm not sure if gpio 
maintainers like it, they are cautious to introduce new helpers.

Or we can use devm_gpiod_get_array, it's pretty much equivalent effect 
in s5m8767 even without fwnode specified.

Furthermore, speaking of shrinking code, i'm thinking about using a 
bitmap to replace buck2_gpiodvs, buck3_gpiodvs and buck4_gpiodvs,

below snippet can be optimized by this bitmap and __builtin_popcount.

     if (pdata->buck2_gpiodvs) {
         if (pdata->buck3_gpiodvs || pdata->buck4_gpiodvs) {
             dev_err(&pdev->dev, "S5M8767 GPIO DVS NOT VALID\n");
             return -EINVAL;
         }
     }

     if (pdata->buck3_gpiodvs) {
         if (pdata->buck2_gpiodvs || pdata->buck4_gpiodvs) {
             dev_err(&pdev->dev, "S5M8767 GPIO DVS NOT VALID\n");
             return -EINVAL;
         }
     }

     if (pdata->buck4_gpiodvs) {
         if (pdata->buck2_gpiodvs || pdata->buck3_gpiodvs) {
             dev_err(&pdev->dev, "S5M8767 GPIO DVS NOT VALID\n");
             return -EINVAL;
         }
     }

what do you think?

Best regards,

Song

  reply	other threads:[~2024-12-12  5:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-11  5:10 [PATCH v2] regulator:s5m8767: Fully convert to GPIO descriptors Song Chen
2024-12-11 13:25 ` Mark Brown
2024-12-12  6:01   ` Song Chen
2024-12-11 13:51 ` Bartosz Golaszewski
2024-12-12  5:55   ` Song Chen [this message]
2024-12-12 10:29     ` Bartosz Golaszewski
2024-12-13 10:25       ` Song Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=efade71b-76ce-4dfe-949e-b231b3e411f0@189.cn \
    --to=chensong_2000@189.cn \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=krzk@kernel.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox