devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"Sergei Shtylyov" <sergei.shtylyov@cogentembedded.com>,
	"David Airlie" <airlied@linux.ie>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Simon Horman" <horms@verge.net.au>,
	"Jacopo Mondi" <jacopo+renesas@jmondi.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
	"Vladimir Zapolskiy" <vladimir_zapolskiy@mentor.com>
Subject: Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Date: Tue, 27 Mar 2018 11:06:03 +0200	[thread overview]
Message-ID: <CAMuHMdVEF-6icsLXd3RU56mzGp6TZYpD1E5ViZvaOa=kWGYPvw@mail.gmail.com> (raw)
In-Reply-To: <8115587a-4925-5602-43db-4285a3de7b0e@samsung.com>

Hi Andrezj,

On Tue, Mar 27, 2018 at 10:36 AM, Andrzej Hajda <a.hajda@samsung.com> wrote:
> On 27.03.2018 09:36, Geert Uytterhoeven wrote:
>> On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda <a.hajda@samsung.com> wrote:
>>>>> --- /dev/null
>>>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>>>> +static void thc63_enable(struct drm_bridge *bridge)
>>>>> +{
>>>>> +    struct thc63_dev *thc63 = to_thc63(bridge);
>>>>> +    struct regulator *vcc;
>>>>> +    int i;
>>>> unsigned int i;
>>> Why? You are introducing silly bug this way, see few lines below.
>>>
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>>>> +            vcc = thc63->vccs[i];
>>>>> +            if (!vcc)
>>>>> +                    continue;
>>>>> +
>>>>> +            if (regulator_enable(vcc))
>>>>> +                    goto error_vcc_enable;
>>>>> +    }
>>>>> +
>>>>> +    if (thc63->pdwn)
>>>>> +            gpiod_set_value(thc63->pdwn, 0);
>>>>> +
>>>>> +    if (thc63->oe)
>>>>> +            gpiod_set_value(thc63->oe, 1);
>>>>> +
>>>>> +    return;
>>>>> +
>>>>> +error_vcc_enable:
>>>>> +    dev_err(thc63->dev, "Failed to enable regulator %s\n",
>>>>> +            thc63_reg_names[i]);
>>>>> +
>>>>> +    for (i = i - 1; i >= 0; i--) {
>>> Here, the loop will not end if you define i unsigned.
>> True.
>>
>>> I know one can change the loop, to make it working with unsigned. But
>>> this clearly shows that using unsigned is more risky.
>>> What are advantages of unsigned vs int in this case. Are there some
>>> guidelines/discussions about it?
>> Some people consider signed integers harmful, as they may be converted
>> silently by the compiler to the "larger" unsigned type when needed.
>
> Wow, it sounds crazy, shall we expect gigantic patchsets, converting all
> occurrences of int to "unsigned int" ? :)

No we shall not.

> I know both types have their pros and cons and can behave unexpectedly
> in corner cases, but I do not see why unsigned should be preferred over
> signed in general, or in this particular case.

When looping over array indices, and comparing with ARRAY_SIZE (which
is unsigned), using "unsigned int" is preferred.

However, in this case the error code relies on the index becoming negative,
so a signed integer should be used.

> I guess there were somewhere discussion about it, could you point me to
> it if possible, to avoid unnecessary noise in this thread.

Not here, but Google pointed me to
http://blog.robertelder.org/signed-or-unsigned/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-03-27  9:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16 15:16 [PATCH v6 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge Jacopo Mondi
2018-03-16 15:16 ` [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder Jacopo Mondi
2018-03-20 12:43   ` Laurent Pinchart
2018-03-26 12:08     ` jacopo mondi
2018-03-26 22:22     ` Rob Herring
2018-03-27  6:15       ` Vladimir Zapolskiy
2018-03-27  7:12         ` Andrzej Hajda
2018-03-27  7:33           ` jacopo mondi
2018-03-27  8:27             ` Sergei Shtylyov
2018-03-27  8:30               ` Vladimir Zapolskiy
2018-03-27  8:57                 ` jacopo mondi
2018-03-27  9:37                   ` Vladimir Zapolskiy
2018-03-27 10:10                     ` jacopo mondi
2018-03-27 11:03                       ` Vladimir Zapolskiy
2018-03-29 10:02                         ` jacopo mondi
2018-04-02 13:36                         ` Laurent Pinchart
2018-04-03 12:33                           ` jacopo mondi
2018-04-05 16:33                           ` Rob Herring
2018-04-05 18:53                             ` Laurent Pinchart
2018-04-05 21:27                               ` Rob Herring
2018-03-16 15:16 ` [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver Jacopo Mondi
2018-03-20 13:00   ` Laurent Pinchart
2018-03-27  6:24   ` Vladimir Zapolskiy
2018-03-27  7:28     ` Andrzej Hajda
2018-03-27  7:36       ` Geert Uytterhoeven
2018-03-27  8:36         ` Andrzej Hajda
2018-03-27  9:06           ` Geert Uytterhoeven [this message]
2018-03-27  9:57       ` Vladimir Zapolskiy
2018-03-27  7:30     ` jacopo mondi
2018-03-16 15:16 ` [PATCH v6 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle Jacopo Mondi
2018-03-20 13:01   ` Laurent Pinchart
2018-03-27  6:27     ` Vladimir Zapolskiy

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='CAMuHMdVEF-6icsLXd3RU56mzGp6TZYpD1E5ViZvaOa=kWGYPvw@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=horms@verge.net.au \
    --cc=jacopo+renesas@jmondi.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=robh+dt@kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=vladimir_zapolskiy@mentor.com \
    /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;
as well as URLs for NNTP newsgroup(s).