All of lore.kernel.org
 help / color / mirror / Atom feed
From: m.szyprowski@samsung.com (Marek Szyprowski)
To: linux-arm-kernel@lists.infradead.org
Subject: next build: 304 warnings 0 failures (next/next-20141013)
Date: Mon, 13 Oct 2014 11:38:55 +0200	[thread overview]
Message-ID: <543B9DAF.3040707@samsung.com> (raw)
In-Reply-To: <8786463.d9VIC5J1Iz@wuerfel>

Hello,

On 2014-10-13 11:12, Arnd Bergmann wrote:
> On Monday 13 October 2014 09:46:18 Russell King - ARM Linux wrote:
>> On Sun, Oct 12, 2014 at 10:32:02PM -0700, Olof's autobuilder wrote:
>>>        1 arch/arm/mach-cns3xxx/pcie.c:313:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> This should be fixed.
> This is an ancient bug, both Mark Brown and I have suggested fixes,
> we just need to apply one of them.
>
>>>        1 arch/arm/mach-omap1/board-htcherald.c:296:2: warning: initialization makes pointer from integer without a cast [enabled by default]
>>>        1 arch/arm/mach-omap1/board-htcherald.c:296:2: warning: (near initialization for 'gpio_leds[0].gpiod') [enabled by default]
>>>        1 arch/arm/mach-omap1/board-htcherald.c:297:2: warning: initialization makes pointer from integer without a cast [enabled by default]
>>>        1 arch/arm/mach-omap1/board-htcherald.c:297:2: warning: (near initialization for 'gpio_leds[1].gpiod') [enabled by default]
>> ...
>>
>> All of these need fixing.
> Hadn't seen this one before, I guess it's because of
> https://lkml.org/lkml/2014/9/16/222.
>
> adding Mika and Linus to Cc, should be easy to fix using
> named initializers like all other 120+ platforms do,
> but to be on the safe side, we could also move the new
> 'gpiod' member to the end of 'struct gpio_led'.
>
>>>        2 drivers/base/dma-contiguous.c:244:2: warning: initialization from incompatible pointer type
>>>        2 drivers/base/dma-contiguous.c:244:2: warning: (near initialization for 'rmem_cma_ops.device_init')
>> This does too.
>>
>>>        3 drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type
>>>        3 drivers/base/dma-coherent.c:303:2: warning: (near initialization for 'rmem_dma_ops.device_init')
>>>        8 drivers/base/dma-contiguous.c:244:2: warning: initialization from incompatible pointer type [enabled by default]
>>>        8 drivers/base/dma-contiguous.c:244:2: warning: (near initialization for 'rmem_cma_ops.device_init') [enabled by default]
>>>       50 drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type [enabled by default]
>>>       50 drivers/base/dma-coherent.c:303:2: warning: (near initialization for 'rmem_dma_ops.device_init') [enabled by default]
>> And these.
>>
>> None of these warnings should hit mainline; they should all be fixed now,
>> before any of the changes which caused them are merged.
> Adding Marek as well. No idea how this slipped in, apparently the device_init
> callback declaration has always used 'void' as the return type, while all
> functions assigned to it have always returned 'int' and the caller
> in __reserved_mem_init_node() actually evaluates the return code.

Patches adding of_reservedmem support for dma-contiguous and 
dma-coherent were posted together
with a patch adding a return value. However, for some reasons the latter 
was dropped. My fault
that I've posted that patch in a hurry and missed adding return value 
check in some places.

I've posted a fix and I hope it can get merged as a 'fix':
https://lkml.org/lkml/2014/10/9/178


> This seems to be the obvious fix:
>
> diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
> index 5b5efae09135..3c2cf6fc5e78 100644
> --- a/include/linux/of_reserved_mem.h
> +++ b/include/linux/of_reserved_mem.h
> @@ -16,7 +16,7 @@ struct reserved_mem {
>   };
>   
>   struct reserved_mem_ops {
> -	void	(*device_init)(struct reserved_mem *rmem,
> +	int	(*device_init)(struct reserved_mem *rmem,
>   			       struct device *dev);
>   	void	(*device_release)(struct reserved_mem *rmem,
>   				  struct device *dev);
>
>
> 	Arnd
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

  reply	other threads:[~2014-10-13  9:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <543b63d2.a479420a.486e.ffffb6e2@mx.google.com>
2014-10-13  8:46 ` next build: 304 warnings 0 failures (next/next-20141013) Russell King - ARM Linux
2014-10-13  9:12   ` Arnd Bergmann
2014-10-13  9:38     ` Marek Szyprowski [this message]
2014-10-14  8:54     ` Mika Westerberg
2014-10-14  9:17       ` Arnd Bergmann
2014-10-14 13:16         ` Mika Westerberg

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=543B9DAF.3040707@samsung.com \
    --to=m.szyprowski@samsung.com \
    --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.