From: oliver+list@schinagl.nl (Oliver Schinagl)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
Date: Mon, 10 Jun 2013 23:43:19 +0200 [thread overview]
Message-ID: <51B64877.4040908@schinagl.nl> (raw)
In-Reply-To: <CAHp75Vdqc9xiPBvQUB3Hfb4EBFUsoVxyuH8MK=9spJ4+rieoDQ@mail.gmail.com>
On 06/06/13 21:16, Andy Shevchenko wrote:
Thank you andy for your review, I do have a few questions/comments if
you don't mind.
> On Sun, Jun 2, 2013 at 5:58 PM, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
<snip>
>> + if (likely((SID_SIZE))) {
>
> Extra braces.
> Use antipattern here.
While I accidentally dropped the pointer here, sorry for the confusion,
what is antipattern? I have asked around and nobody really knew.
Wikipedia mentions it as a software development thing, but you make it
sound like it is some sort of tool?
<snip>
>> + if (unlikely(!pdev->dev.of_node)) {
>> + dev_err(dev, "No devicetree data available\n");
>> + ret = -EFAULT;
>> + goto exit;
>
> Plain return here and in entire function where it applies.
Why? I know there's conflicting preferences here. The general consensus
seems, don't return mid function if you don't absolutely have to. Yet,
you make it sound, just return wherever. I take it that really is just a
preference? I think i see both constructs throughout the kernel. So one
review prefers the one method, the next the other?
<snip>
>> +
>> + ret = device_create_bin_file(dev, &sid_bin_attr);
>> + if (unlikely(ret)) {
>
> Any benifit of (un)likely in probe()?
Does it hurt however in any way though? It's just a compiler
optimization isn't it.
<snip>
>
> --
> With Best Regards,
> Andy Shevchenko
>
Thank you for your time, it is much appreciated :)
Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Schinagl <oliver+list@schinagl.nl>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: maxime.ripard@free-electrons.com, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
Oliver Schinagl <oliver@schinagl.nl>
Subject: Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
Date: Mon, 10 Jun 2013 23:43:19 +0200 [thread overview]
Message-ID: <51B64877.4040908@schinagl.nl> (raw)
In-Reply-To: <CAHp75Vdqc9xiPBvQUB3Hfb4EBFUsoVxyuH8MK=9spJ4+rieoDQ@mail.gmail.com>
On 06/06/13 21:16, Andy Shevchenko wrote:
Thank you andy for your review, I do have a few questions/comments if
you don't mind.
> On Sun, Jun 2, 2013 at 5:58 PM, Oliver Schinagl <oliver+list@schinagl.nl> wrote:
>> From: Oliver Schinagl <oliver@schinagl.nl>
<snip>
>> + if (likely((SID_SIZE))) {
>
> Extra braces.
> Use antipattern here.
While I accidentally dropped the pointer here, sorry for the confusion,
what is antipattern? I have asked around and nobody really knew.
Wikipedia mentions it as a software development thing, but you make it
sound like it is some sort of tool?
<snip>
>> + if (unlikely(!pdev->dev.of_node)) {
>> + dev_err(dev, "No devicetree data available\n");
>> + ret = -EFAULT;
>> + goto exit;
>
> Plain return here and in entire function where it applies.
Why? I know there's conflicting preferences here. The general consensus
seems, don't return mid function if you don't absolutely have to. Yet,
you make it sound, just return wherever. I take it that really is just a
preference? I think i see both constructs throughout the kernel. So one
review prefers the one method, the next the other?
<snip>
>> +
>> + ret = device_create_bin_file(dev, &sid_bin_attr);
>> + if (unlikely(ret)) {
>
> Any benifit of (un)likely in probe()?
Does it hurt however in any way though? It's just a compiler
optimization isn't it.
<snip>
>
> --
> With Best Regards,
> Andy Shevchenko
>
Thank you for your time, it is much appreciated :)
Oliver
next prev parent reply other threads:[~2013-06-10 21:43 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-02 14:58 [PATCH 0/2] v2 Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-06-02 14:58 ` Oliver Schinagl
2013-06-02 14:58 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-06-02 14:58 ` Oliver Schinagl
2013-06-02 15:09 ` Russell King - ARM Linux
2013-06-02 15:09 ` Russell King - ARM Linux
2013-06-02 15:21 ` Oliver Schinagl
2013-06-02 15:21 ` Oliver Schinagl
2013-06-06 19:16 ` Andy Shevchenko
2013-06-06 19:16 ` Andy Shevchenko
2013-06-10 21:43 ` Oliver Schinagl [this message]
2013-06-10 21:43 ` Oliver Schinagl
2013-06-11 10:51 ` Andy Shevchenko
2013-06-11 10:51 ` Andy Shevchenko
2013-06-11 17:44 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses; Unanswered comments Oliver Schinagl
2013-06-11 17:44 ` Oliver Schinagl
2013-06-02 14:58 ` [PATCH 2/2] Add sunxi-sid to dts for sun4i and sun5i Oliver Schinagl
2013-06-02 14:58 ` Oliver Schinagl
-- strict thread matches above, loose matches on Subject: below --
2013-08-27 14:13 [PATCHv5 0/2] Driver for Allwinner sunxi Security ID oliver+list at schinagl.nl
2013-08-27 14:13 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses oliver+list at schinagl.nl
2013-08-27 14:13 ` oliver+list
2013-08-27 15:42 ` Maxime Ripard
2013-08-27 15:42 ` Maxime Ripard
2013-06-17 20:59 [PATCH 0/2] v4 Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-06-17 20:59 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-06-17 20:59 ` Oliver Schinagl
2013-06-17 21:06 ` Tomasz Figa
2013-06-17 21:06 ` Tomasz Figa
2013-06-17 22:58 ` Greg KH
2013-06-17 22:58 ` Greg KH
2013-06-24 9:29 ` Maxime Ripard
2013-06-24 9:29 ` Maxime Ripard
2013-06-24 16:04 ` Greg KH
2013-06-24 16:04 ` Greg KH
2013-06-24 17:11 ` Oliver Schinagl
2013-06-24 17:11 ` Oliver Schinagl
2013-06-24 18:15 ` Greg KH
2013-06-24 18:15 ` Greg KH
2013-06-24 21:21 ` Oliver Schinagl
2013-06-24 21:21 ` Oliver Schinagl
2013-06-24 21:46 ` Greg KH
2013-06-24 21:46 ` Greg KH
2013-06-26 8:32 ` Oliver Schinagl
2013-06-26 8:32 ` Oliver Schinagl
2013-06-26 17:51 ` Greg KH
2013-06-26 17:51 ` Greg KH
2013-07-05 7:24 ` Oliver Schinagl
2013-07-05 7:24 ` Oliver Schinagl
2013-07-06 19:36 ` Greg KH
2013-07-06 19:36 ` Greg KH
2013-07-07 0:17 ` Greg KH
2013-07-07 0:17 ` Greg KH
2013-06-26 9:10 ` Russell King - ARM Linux
2013-06-26 9:10 ` Russell King - ARM Linux
2013-06-26 17:51 ` Greg KH
2013-06-26 17:51 ` Greg KH
2013-06-24 21:04 ` Maxime Ripard
2013-06-24 21:04 ` Maxime Ripard
2013-06-26 9:22 ` Geert Uytterhoeven
2013-06-26 9:22 ` Geert Uytterhoeven
2013-06-26 9:22 ` Geert Uytterhoeven
2013-06-26 17:49 ` Greg KH
2013-06-26 17:49 ` Greg KH
2013-06-26 17:49 ` Greg KH
2013-06-18 5:41 ` Andy Shevchenko
2013-06-18 5:41 ` Andy Shevchenko
2013-06-14 23:16 [PATCH 0/2] v3 Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-06-14 23:16 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-06-14 23:16 ` Oliver Schinagl
2013-06-15 2:14 ` Andy Shevchenko
2013-06-15 2:14 ` Andy Shevchenko
2013-06-15 9:34 ` Oliver Schinagl
2013-06-15 9:34 ` Oliver Schinagl
2013-06-15 10:28 ` Tomasz Figa
2013-06-15 10:28 ` Tomasz Figa
2013-06-17 10:36 ` Oliver Schinagl
2013-06-17 10:36 ` Oliver Schinagl
2013-06-17 11:25 ` Russell King - ARM Linux
2013-06-17 11:25 ` Russell King - ARM Linux
2013-06-17 11:32 ` Oliver Schinagl
2013-06-17 11:32 ` Oliver Schinagl
2013-06-17 11:51 ` Maxime Ripard
2013-06-17 11:51 ` Maxime Ripard
2013-06-17 12:04 ` Oliver Schinagl
2013-06-17 12:04 ` Oliver Schinagl
2013-06-17 12:51 ` Tomasz Figa
2013-06-17 12:51 ` Tomasz Figa
2013-06-17 13:10 ` Oliver Schinagl
2013-06-17 13:10 ` Oliver Schinagl
2013-06-17 13:23 ` Tomasz Figa
2013-06-17 13:23 ` Tomasz Figa
2013-06-17 13:47 ` Oliver Schinagl
2013-06-17 13:47 ` Oliver Schinagl
2013-05-17 13:35 [PATCH 0/2] Driver for Allwinner sunxi Security ID Oliver Schinagl
2013-05-17 13:35 ` [PATCH 1/2] Initial support for Allwinner's Security ID fuses Oliver Schinagl
2013-05-17 13:35 ` Oliver Schinagl
2013-05-17 13:45 ` Arnd Bergmann
2013-05-17 13:45 ` Arnd Bergmann
2013-05-17 18:54 ` Oliver Schinagl
2013-05-17 18:54 ` Oliver Schinagl
2013-05-17 21:18 ` Maxime Ripard
2013-05-17 21:18 ` Maxime Ripard
2013-05-18 17:19 ` Oliver Schinagl
2013-05-18 17:19 ` Oliver Schinagl
2013-05-19 15:22 ` Maxime Ripard
2013-05-19 15:22 ` Maxime Ripard
2013-05-24 21:50 ` Oliver Schinagl
2013-05-24 21:50 ` Oliver Schinagl
2013-05-25 12:22 ` Maxime Ripard
2013-05-25 12:22 ` Maxime Ripard
2013-05-25 19:25 ` Oliver Schinagl
2013-05-25 19:25 ` Oliver Schinagl
2013-05-26 9:35 ` Maxime Ripard
2013-05-26 9:35 ` Maxime Ripard
2013-05-23 7:56 ` Linus Walleij
2013-05-23 7:56 ` Linus Walleij
2013-05-23 8:10 ` Oliver Schinagl
2013-05-23 8:10 ` Oliver Schinagl
2013-05-23 8:20 ` Linus Walleij
2013-05-23 8:20 ` Linus Walleij
2013-05-23 14:58 ` Maxime Ripard
2013-05-23 14:58 ` Maxime Ripard
2013-05-23 15:05 ` Oliver Schinagl
2013-05-23 15:05 ` Oliver Schinagl
2013-05-23 15:27 ` Maxime Ripard
2013-05-23 15:27 ` Maxime Ripard
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=51B64877.4040908@schinagl.nl \
--to=oliver+list@schinagl.nl \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.