linux-kernel - Re: [PATCH v1 03/11] leds: aw200xx: support HWEN hardware control

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: <20231009130919.bezr4wvk4pwmc4p3@CAB-WSD-L081021>
Date:   Mon, 9 Oct 2023 16:09:19 +0300
From:   Dmitry Rokosov <ddrokosov@...utedevices.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     <lee@...nel.org>, <pavel@....cz>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <kernel@...rdevices.ru>, <rockosov@...il.com>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-leds@...r.kernel.org>
Subject: Re: [PATCH v1 03/11] leds: aw200xx: support HWEN hardware control

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@...utedevices.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