Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Mon, 9 Oct 2023 16:09:19 +0300
From:   Dmitry Rokosov <ddrokosov@salutedevices.com>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
CC:     <lee@kernel.org>, <pavel@ucw.cz>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <kernel@sberdevices.ru>, <rockosov@gmail.com>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v1 03/11] leds: aw200xx: support HWEN hardware control
Message-ID: <20231009130919.bezr4wvk4pwmc4p3@CAB-WSD-L081021>
References: <20231006160437.15627-1-ddrokosov@salutedevices.com>
 <20231006160437.15627-4-ddrokosov@salutedevices.com>
 <CAHp75VceobJuEnpQY2Hi1hrjTDCSa-zxi7zxaWt5-k9haGDFUg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHp75VceobJuEnpQY2Hi1hrjTDCSa-zxi7zxaWt5-k9haGDFUg@mail.gmail.com>
User-Agent: NeoMutt/20220415
Precedence: bulk

Hello Andy,

Thanks a lot for such a quick review!

Please find my comments below.

On Fri, Oct 06, 2023 at 08:57:23PM +0300, Andy Shevchenko wrote:
> On Fri, Oct 6, 2023 at 7:04 PM Dmitry Rokosov
> <ddrokosov@salutedevices.com> wrote:
> >
> > HWEN is hardware control, which is used for enable/disable aw200xx chip.
> > It's high active, internally pulled down to GND.
> >
> > After HWEN pin set high the chip begins to load the OTP information,
> > which takes 200us to complete. About 200us wait time is needed for
> > internal oscillator startup and display SRAM initialization. After
> > display SRAM initialization, the registers in page1 to page5 can be
> 
> pages 1 to 5
> 
> 

Sure, you are totally right.

> > configured via i2c interface.
> 
> ...
> 
> > +#include <linux/of_gpio.h>
> 
> Definitely not.
> 
> Use agnostic APIs.

Sure

> > @@ -116,6 +117,7 @@ struct aw200xx {
> >         struct mutex mutex;
> 
> >         u32 num_leds;
> >         u32 display_rows;
> > +       int hwen;
> >         struct aw200xx_led leds[];
> 
> Side note: add a patch to use __counted_by() here.

Okay, now I see the patch with __counted_by() some days ago. I will
rebase on it.

> > +       if (!gpio_is_valid(chip->hwen))
> 
> Absolutely not. You may not use legacy GPIO APIs.

Exactly

> > +               return;
> > +
> > +       gpio_set_value(chip->hwen, 1);
> 
> Ditto.

Ok

> > +       usleep_range(400, 500);
> 
> fsleep() ?

Agreed. In this situation fsleep() automatic behaviour is acceptable.

> 
> ...
> 
> > +static void aw200xx_disable(const struct aw200xx *const chip)
> > +{
> > +       if (gpio_is_valid(chip->hwen))
> > +               gpio_set_value(chip->hwen, 0);
> > +}
> 
> As per above.

Ok

> > +static void aw200xx_probe_hwen(struct device *dev, struct aw200xx *chip)
> > +{
> > +       chip->hwen = of_get_named_gpio(dev->of_node, "awinic,hwen-gpio", 0);
> > +       if (gpio_is_valid(chip->hwen))
> > +               if (devm_gpio_request_one(dev, chip->hwen, GPIOF_OUT_INIT_HIGH,
> > +                                         "AW200XX HWEN")) {
> > +                       dev_warn(dev, "Can't request gpio %d, tag it invalid\n",
> > +                                chip->hwen);
> > +                       chip->hwen = -EINVAL;
> > +               }
> > +}
> 
> Please, rewrite this completely using supported APIs and not
> deprecated or obsolete ones.

Yep, I see. I will use devm_gpiod_* API.

-- 
Thank you,
Dmitry