All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Jackson <ian.jackson@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: linux 4.19 does not build on armhf Re: [linux-4.19 test] 135420: regressions - FAIL
Date: Tue, 30 Apr 2019 08:05:39 -0600	[thread overview]
Message-ID: <5CC85633020000780022A804@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <23752.17186.527512.614163@mariner.uk.xensource.com>

>>> On 30.04.19 at 14:44, <ian.jackson@citrix.com> wrote:
> osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
>> flight 135420 linux-4.19 real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/135420/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-armhf-pvops             6 kernel-build             fail REGR. vs. 129313
> 
> http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log
> 
>   drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’:
>   drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of 
> ‘dma_alloc_coherent’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>     ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL);
>                                                  ^
>   In file included from drivers/firmware/qcom_scm.c:21:0:
>   ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka 
> long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka 
> unsigned int *}’
>    static inline void *dma_alloc_coherent(struct device *dev, size_t size,
>                        ^~~~~~~~~~~~~~~~~~
>   cc1: some warnings being treated as errors

The code is still the same in 5.1-rc7, so presumably the problem went
unnoticed till now. While it looks like it's straightforward to fix (thanks
to the 32-bit variant of __qcom_scm_assign_mem() doing nothing
with the passed in values, so it being "fine" for them to get truncated
during the call) the aspect that puzzles me is - where does this
-Werror=incompatible-pointer-types come from? Was the prior gcc
version indeed 4.9.x or older (which seems pretty old to me)? The
specific warning control (which Linux converts to an error) was
introduced for gcc 5.x.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <ian.jackson@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [Xen-devel] linux 4.19 does not build on armhf Re: [linux-4.19 test] 135420: regressions - FAIL
Date: Tue, 30 Apr 2019 08:05:39 -0600	[thread overview]
Message-ID: <5CC85633020000780022A804@prv1-mh.provo.novell.com> (raw)
Message-ID: <20190430140539.hrCmdgq9iSyVN3T19CTVtK9PQQYFfzGMKBOQNoHsg-8@z> (raw)
In-Reply-To: <23752.17186.527512.614163@mariner.uk.xensource.com>

>>> On 30.04.19 at 14:44, <ian.jackson@citrix.com> wrote:
> osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"):
>> flight 135420 linux-4.19 real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/135420/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-armhf-pvops             6 kernel-build             fail REGR. vs. 129313
> 
> http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log
> 
>   drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’:
>   drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of 
> ‘dma_alloc_coherent’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>     ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL);
>                                                  ^
>   In file included from drivers/firmware/qcom_scm.c:21:0:
>   ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka 
> long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka 
> unsigned int *}’
>    static inline void *dma_alloc_coherent(struct device *dev, size_t size,
>                        ^~~~~~~~~~~~~~~~~~
>   cc1: some warnings being treated as errors

The code is still the same in 5.1-rc7, so presumably the problem went
unnoticed till now. While it looks like it's straightforward to fix (thanks
to the 32-bit variant of __qcom_scm_assign_mem() doing nothing
with the passed in values, so it being "fine" for them to get truncated
during the call) the aspect that puzzles me is - where does this
-Werror=incompatible-pointer-types come from? Was the prior gcc
version indeed 4.9.x or older (which seems pretty old to me)? The
specific warning control (which Linux converts to an error) was
introduced for gcc 5.x.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-04-30 14:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30 11:34 [linux-4.19 test] 135420: regressions - FAIL osstest service owner
2019-04-30 11:34 ` [Xen-devel] " osstest service owner
2019-04-30 12:44 ` linux 4.19 does not build on armhf " Ian Jackson
2019-04-30 12:44   ` [Xen-devel] " Ian Jackson
2019-04-30 14:05   ` Jan Beulich [this message]
2019-04-30 14:05     ` Jan Beulich
2019-04-30 14:06   ` qcom_scm: Incompatible pointer type build failure Julien Grall
2019-04-30 14:06   ` Julien Grall
2019-04-30 14:06     ` [Xen-devel] " Julien Grall
2019-05-17 16:10     ` Ian Jackson
2019-05-17 16:10       ` [Xen-devel] " Ian Jackson
2019-05-17 16:10       ` Ian Jackson
2019-05-17 21:09       ` [PATCH 0/3] qcom_scm: Fix some dma mapping things Stephen Boyd
2019-05-17 21:09       ` [PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings Stephen Boyd
2019-05-20  9:41         ` Ian Jackson
2019-05-20 13:20           ` Julien Grall
2019-05-30 16:51             ` [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI Ian Jackson
2019-05-30 16:51               ` [Xen-devel] " Ian Jackson
2019-05-30 16:51               ` Ian Jackson
2019-05-31 15:52               ` Julien Grall
2019-05-31 15:52               ` Julien Grall
2019-05-31 15:52                 ` [Xen-devel] " Julien Grall
2019-05-17 21:09       ` [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() Stephen Boyd
2019-07-22 23:27         ` Bjorn Andersson
2019-07-23  0:04           ` Stephen Boyd
2019-07-23  0:21             ` Bjorn Andersson
2019-05-17 21:09       ` [PATCH 3/3] firmware: qcom_scm: Fix some typos in docs and printks Stephen Boyd

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=5CC85633020000780022A804@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=ian.jackson@citrix.com \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.