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]
Date:   Wed, 21 Mar 2018 13:04:36 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Stephen Boyd <sboyd@...eaurora.org>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, Timur Tabi <timur@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Grant Likely <grant.likely@...retlab.ca>,
        linux-gpio@...r.kernel.org
Subject: Re: [PATCH v3 3/3] pinctrl: qcom: Don't allow protected pins to be requested

Quoting Andy Shevchenko (2018-03-21 11:07:09)
> On Wed, 2018-03-21 at 09:58 -0700, Stephen Boyd wrote:
> > +static int msm_pinmux_request(struct pinctrl_dev *pctldev, unsigned
> > offset)
> > +{
> > +     struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
> > +     struct gpio_chip *chip = &pctrl->chip;
> > +
> > +     if (gpiochip_line_is_valid(chip, offset))
> > +             return 0;
> > +
> > +     return -EINVAL;
> 
> Perhaps traditional pattern
> 
> if (!...)
>  return -EINVAL;
> 
> return 0;
> 

Or ternary?

  return gpiochip_line_is_valid(chip, offset) ? 0 : -EINVAL;

> 
> > +}
> 
> >       seq_printf(s, " %dmA", msm_regval_to_drive(drive));
> > -     seq_printf(s, " %s", pulls[pull]);
> > +     seq_printf(s, " %s\n", pulls[pull]);
> 
> I had commented this once, but you ignored by some reason.
> 
> I would rather just move 
>  seq_puts(s, "\n");
> here.
> 
> The rationale behind, besides making diff more neat, is to reduce
> possible burden in the future if someone would like to squeeze more data
> in between.

Sure.

> 
> > +             tmp = kmalloc_array(len, sizeof(tmp[0]), GFP_KERNEL);
> 
> sizeof(*tmp) ?
> 

Ok.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ