[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHp75VcLADxV9pTf=r-scKWYUCsq5LcjdvYoqMoRBp5HXj6Tyg@mail.gmail.com>
Date: Wed, 5 Jun 2013 16:41:44 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Ryan Mallon <rmallon@...il.com>,
Linus Walleij <linus.walleij@...aro.org>,
Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@...el.com>,
Grant Likely <grant.likely@...retlab.ca>,
Len Brown <lenb@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Cohen <david.a.cohen@...el.com>,
Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH v1.1] gpiolib: append SFI helpers for GPIO API
On Mon, Jun 3, 2013 at 3:26 PM, Joe Perches <joe@...ches.com> wrote:
> On Mon, 2013-06-03 at 11:16 +0300, Andy Shevchenko wrote:
>> On Sun, 2013-06-02 at 19:06 -0700, Joe Perches wrote:
>> > On Mon, 2013-06-03 at 11:59 +1000, Ryan Mallon wrote:
>> > > On 31/05/13 19:27, Andy Shevchenko wrote:
>> > > > + sfi_gpio_table = kmalloc(num * sizeof(*pentry), GFP_KERNEL);
>> > > Use kcalloc when you have a size and a count.
>> > kmalloc_array unless you want zero'ed memory
>> One proposed to use kmemdup to clean up a bit. What do you think?
>
> Seems correct to use kmemdup but what validates num?
num comes from SFI firmware. We only could rely on what kmalloc/kmemdup returns.
> It seems like a possible error path exists there regardless
> of whether kmemdup is used or not.
That's true. The advantage of kmemdup is an implicit memcpy. Thus, we
could drop away that line.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists