All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>,
	Grant Likely <grant.likely@linaro.org>,
	Laura Abbott <lauraa@codeaurora.org>,
	Josh Cartwright <joshc@codeaurora.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: linux-next: build warnings after merge of the akpm-current tree
Date: Fri, 03 Oct 2014 21:28:17 +0200	[thread overview]
Message-ID: <xa1tr3yp2bse.fsf@mina86.com> (raw)
In-Reply-To: <20141003112154.92b5a47b2009293090d18f5a@linux-foundation.org>

On Fri, Oct 03 2014, Andrew Morton wrote:
> On Fri, 3 Oct 2014 17:30:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Andrew,
>> 
>> After merging the akpm-current tree, today's linux-next build (arm
>> multi_v7_defconfig) produced these warnings:
>> 
>> drivers/base/dma-contiguous.c:244:2: warning: initialization from incompatible pointer type
>>   .device_init = rmem_cma_device_init,
>>   ^
>> drivers/base/dma-contiguous.c:244:2: warning: (near initialization for 'rmem_cma_ops.device_init')
>> drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type
>>   .device_init = rmem_dma_device_init,
>>   ^
>> 
>> Introduced by commit e92f6296f3a2 ("drivers: dma-coherent: add
>> initialization from device tree").  This init routine is supposed to
>> return void ...
>
> I'm a bit reluctant to just go in and change rmem_cma_device_init().
>
> Why does it test for rmem->priv==NULL?  Can that really happen?  Why? 
> Is it a legitimate state?

I don't think so, since:

static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
	[…]
	rmem->ops = &rmem_cma_ops;
	rmem->priv = cma;
	[…]
}

The following should fix the warning:

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 6c42289..a9a88b6 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -223,14 +223,9 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
 #undef pr_fmt
 #define pr_fmt(fmt) fmt
 
-static int rmem_cma_device_init(struct reserved_mem *rmem, struct device *dev)
+static void rmem_cma_device_init(struct reserved_mem *rmem, struct device *dev)
 {
-	struct cma *cma = rmem->priv;
-
-	if (!cma)
-		return -ENODEV;
-
-	dev_set_cma_area(dev, cma);
+	dev_set_cma_area(dev, rmem->priv);
 	return 0;
 }

Even if rmem->priv is NULL, the call will simply clear device's
cma_area, but at this point it should be NULL anyway.
 
> And why does dev_set_cma_area() test for dev==NULL?  Can that really
> happen?  Is it legitimate?  Is all this stuff just papering over other
> bugs?

I believe since a2547380393ac82c659b40182b0da8d05a8365f3 dev no longer
can be NULL.  It should be safe to apply this:

diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 569bbd0..ff9804e 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -71,8 +71,7 @@ static inline struct cma *dev_get_cma_area(struct device *dev)
 
 static inline void dev_set_cma_area(struct device *dev, struct cma *cma)
 {
-	if (dev)
-		dev->cma_area = cma;
+	dev->cma_area = cma;
 }
 
 static inline void dma_contiguous_set_default(struct cma *cma)

>
> The whole thing could do with a bit of an audit and cleanup, I suspect.
> Get the states and initialization sequences and error checking all
> sorted out, then get rid of all these tests for NULL.
>

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

  reply	other threads:[~2014-10-03 19:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-03  7:30 linux-next: build warnings after merge of the akpm-current tree Stephen Rothwell
2014-10-03 18:21 ` Andrew Morton
2014-10-03 19:28   ` Michal Nazarewicz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-02-09  6:02 Stephen Rothwell
2022-02-09 16:03 ` Hugh Dickins
2022-03-28 23:04   ` Matthew Wilcox
2022-03-29  3:32     ` Hugh Dickins
2022-03-24  7:27 ` Stephen Rothwell
2022-03-28 19:54   ` Hugh Dickins
2022-03-28 22:10     ` Matthew Wilcox
2021-10-11  7:31 Stephen Rothwell
2021-10-11 17:46 ` Kees Cook
2021-06-15 10:50 Stephen Rothwell
2020-10-06 12:05 Stephen Rothwell
2020-10-06 20:01 ` Peter Xu
2020-10-06 22:03   ` Stephen Rothwell
2020-01-06  6:14 Stephen Rothwell
2017-08-24  7:41 Stephen Rothwell
2017-08-24  8:15 ` Changwei Ge
2017-08-25 21:23   ` Andrew Morton
2017-08-26  1:23     ` Changwei Ge
2017-03-20  5:22 Stephen Rothwell
2017-03-20  9:05 ` Dmitry Vyukov
2017-03-20 12:30   ` Jan Glauber
2017-03-20 17:06     ` Challa, Mahipal
2015-01-27  8:12 Stephen Rothwell
2015-01-27  8:27 ` Vladimir Davydov
2015-01-27  8:27   ` Vladimir Davydov
2014-09-23  8:18 Stephen Rothwell
2014-08-26  7:22 Stephen Rothwell
2014-08-26 10:19 ` Xishi Qiu
2014-08-26 10:19   ` Xishi Qiu
2013-08-29  9:47 Stephen Rothwell
2013-08-29 11:24 ` Maxim Patlasov
2013-08-29 11:24   ` Maxim Patlasov
2013-08-29 19:42   ` Andrew Morton
2013-08-29 19:42     ` Andrew Morton

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=xa1tr3yp2bse.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=grant.likely@linaro.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=joshc@codeaurora.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lauraa@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=sfr@canb.auug.org.au \
    /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.