Hello Russell,
Would you please consider this patch for the next merge window? It
is a very old patch (March 2014) which has been left over.
See some of the original threads here:
http://marc.info/?l=linux-arm-kernel&m=138920414402610&w=2
http://marc.info/?l=linux-arm-kernel&m=139031200118436&w=2
Many thanks,
Stefano
---
Remove !GENERIC_ATOMIC64 build dependency:
- introduce xen_atomic64_xchg
- use it to implement xchg_xen_ulong
Remove !CPU_V6 build dependency:
- introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
CONFIG_CPU_V6
- implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
Signed-off-by: Stefano Stabellini <[email protected]>
Reviewed-by: Will Deacon <[email protected]>
Acked-by: Ian Campbell <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 34e1569..e09ed94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1807,8 +1807,7 @@ config XEN_DOM0
config XEN
bool "Xen guest support on ARM"
depends on ARM && AEABI && OF
- depends on CPU_V7 && !CPU_V6
- depends on !GENERIC_ATOMIC64
+ depends on CPU_V7
depends on MMU
select ARCH_DMA_ADDR_T_64BIT
select ARM_PSCI
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 97882f9..3b342ec 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -152,6 +152,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
* cmpxchg only support 32-bits operands on ARMv6.
*/
+static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg8\n"
+ " ldrexb %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexbeq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
+static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval, res;
+
+ do {
+ asm volatile("@ __cmpxchg16\n"
+ " ldrexh %1, [%2]\n"
+ " mov %0, #0\n"
+ " teq %1, %3\n"
+ " strexheq %0, %4, [%2]\n"
+ : "=&r" (res), "=&r" (oldval)
+ : "r" (ptr), "Ir" (old), "r" (new)
+ : "memory", "cc");
+ } while (res);
+
+ return oldval;
+}
+
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
{
@@ -162,28 +200,10 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
switch (size) {
#ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */
case 1:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexb %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexbeq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg8(ptr, old, new);
break;
case 2:
- do {
- asm volatile("@ __cmpxchg1\n"
- " ldrexh %1, [%2]\n"
- " mov %0, #0\n"
- " teq %1, %3\n"
- " strexheq %0, %4, [%2]\n"
- : "=&r" (res), "=&r" (oldval)
- : "r" (ptr), "Ir" (old), "r" (new)
- : "memory", "cc");
- } while (res);
+ oldval = __cmpxchg16(ptr, old, new);
break;
#endif
case 4:
diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
index 9732b8e..4103319 100644
--- a/arch/arm/include/asm/sync_bitops.h
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -20,7 +20,29 @@
#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
#define sync_test_and_change_bit(nr, p) _test_and_change_bit(nr, p)
#define sync_test_bit(nr, addr) test_bit(nr, addr)
-#define sync_cmpxchg cmpxchg
+static inline unsigned long sync_cmpxchg(volatile void *ptr,
+ unsigned long old,
+ unsigned long new)
+{
+ unsigned long oldval;
+ int size = sizeof(*(ptr));
+
+ smp_mb();
+ switch (size) {
+ case 1:
+ oldval = __cmpxchg8(ptr, old, new);
+ break;
+ case 2:
+ oldval = __cmpxchg16(ptr, old, new);
+ break;
+ default:
+ oldval = __cmpxchg(ptr, old, new, size);
+ break;
+ }
+ smp_mb();
+
+ return oldval;
+}
#endif
diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
index 71e473d..f646422 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,37 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs->ARM_cpsr);
}
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \
+#ifdef CONFIG_GENERIC_ATOMIC64
+/* if CONFIG_GENERIC_ATOMIC64 is defined we cannot use the generic
+ * atomic64_xchg function because it is implemented using spin locks.
+ * Here we need proper atomic instructions to read and write memory
+ * shared with the hypervisor.
+ */
+static inline u64 xen_atomic64_xchg(atomic64_t *ptr, u64 new)
+{
+ u64 result;
+ unsigned long tmp;
+
+ smp_mb();
+
+ __asm__ __volatile__("@ xen_atomic64_xchg\n"
+"1: ldrexd %0, %H0, [%3]\n"
+" strexd %1, %4, %H4, [%3]\n"
+" teq %1, #0\n"
+" bne 1b"
+ : "=&r" (result), "=&r" (tmp), "+Qo" (ptr->counter)
+ : "r" (&ptr->counter), "r" (new)
+ : "cc");
+
+ smp_mb();
+
+ return result;
+}
+#else
+#define xen_atomic64_xchg atomic64_xchg
+#endif
+
+#define xchg_xen_ulong(ptr, val) xen_atomic64_xchg(container_of((ptr), \
atomic64_t, \
counter), (val))
On Tue, Dec 22, 2015 at 02:17:17PM +0000, Stefano Stabellini wrote:
> Hello Russell,
>
> Would you please consider this patch for the next merge window? It
> is a very old patch (March 2014) which has been left over.
This patch has some obvious problems...
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 34e1569..e09ed94 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1807,8 +1807,7 @@ config XEN_DOM0
> config XEN
> bool "Xen guest support on ARM"
> depends on ARM && AEABI && OF
> - depends on CPU_V7 && !CPU_V6
> - depends on !GENERIC_ATOMIC64
> + depends on CPU_V7
How sure are we that this won't cause regressions? How much testing
has been done with these changed dependencies?
> diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
> index 9732b8e..4103319 100644
> --- a/arch/arm/include/asm/sync_bitops.h
> +++ b/arch/arm/include/asm/sync_bitops.h
> @@ -20,7 +20,29 @@
> #define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
> #define sync_test_and_change_bit(nr, p) _test_and_change_bit(nr, p)
> #define sync_test_bit(nr, addr) test_bit(nr, addr)
> -#define sync_cmpxchg cmpxchg
>
> +static inline unsigned long sync_cmpxchg(volatile void *ptr,
> + unsigned long old,
> + unsigned long new)
> +{
> + unsigned long oldval;
> + int size = sizeof(*(ptr));
This is buggy. You're doing sizeof(void) here, which on GCC will always
be 1:
A consequence of this is that `sizeof' is also allowed on `void' and
on function types, and returns 1.
> +
> + smp_mb();
> + switch (size) {
> + case 1:
> + oldval = __cmpxchg8(ptr, old, new);
> + break;
> + case 2:
> + oldval = __cmpxchg16(ptr, old, new);
> + break;
The ldrexb/ldrexh instructions are not available on ARMv6 CPUs. __xchg()
and friends avoided these for ARMv6 CPUs, but this does not.
I'd expect anything that uses sync_cmpxchg() will fail to build when a
kernel including ARMv6 is attempted.
So... I don't think this patch is ready.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 02:17:17PM +0000, Stefano Stabellini wrote:
> > Hello Russell,
> >
> > Would you please consider this patch for the next merge window? It
> > is a very old patch (March 2014) which has been left over.
>
> This patch has some obvious problems...
>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 34e1569..e09ed94 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1807,8 +1807,7 @@ config XEN_DOM0
> > config XEN
> > bool "Xen guest support on ARM"
> > depends on ARM && AEABI && OF
> > - depends on CPU_V7 && !CPU_V6
> > - depends on !GENERIC_ATOMIC64
> > + depends on CPU_V7
>
> How sure are we that this won't cause regressions? How much testing
> has been done with these changed dependencies?
I did build-test a range of combinations of those options, sorry for not
spotting the error below.
> > diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
> > index 9732b8e..4103319 100644
> > --- a/arch/arm/include/asm/sync_bitops.h
> > +++ b/arch/arm/include/asm/sync_bitops.h
> > @@ -20,7 +20,29 @@
> > #define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
> > #define sync_test_and_change_bit(nr, p) _test_and_change_bit(nr, p)
> > #define sync_test_bit(nr, addr) test_bit(nr, addr)
> > -#define sync_cmpxchg cmpxchg
> >
> > +static inline unsigned long sync_cmpxchg(volatile void *ptr,
> > + unsigned long old,
> > + unsigned long new)
> > +{
> > + unsigned long oldval;
> > + int size = sizeof(*(ptr));
>
> This is buggy. You're doing sizeof(void) here, which on GCC will always
> be 1:
>
> A consequence of this is that `sizeof' is also allowed on `void' and
> on function types, and returns 1.
You are right, thank you very much for looking at the patch and finding
this bug. I think the issue can be solved with something like:
+#define sync_cmpxchg(ptr, o, n) ({ \
+ (__typeof(*ptr))__sync_cmpxchg((ptr), \
+ (unsigned long)(o), \
+ (unsigned long)(n), \
+ sizeof(*(ptr))); \
+})
+static inline unsigned long __sync_cmpxchg(volatile void *ptr,
+ unsigned long old,
+ unsigned long new,
+ int size)
+{
> > +
> > + smp_mb();
> > + switch (size) {
> > + case 1:
> > + oldval = __cmpxchg8(ptr, old, new);
> > + break;
> > + case 2:
> > + oldval = __cmpxchg16(ptr, old, new);
> > + break;
>
> The ldrexb/ldrexh instructions are not available on ARMv6 CPUs. __xchg()
> and friends avoided these for ARMv6 CPUs, but this does not.
>
> I'd expect anything that uses sync_cmpxchg() will fail to build when a
> kernel including ARMv6 is attempted.
The code builds, but of course it could not actually run on CPU_V6. But
the use case for me is building drivers/xen/grant-table.c, which can
only run on CPU_V7 anyway, so it is not a problem.
Is that acceptable for you? If not, do you have any other suggestions?
> So... I don't think this patch is ready.
On Tue, Dec 22, 2015 at 03:45:19PM +0000, Stefano Stabellini wrote:
> The code builds, but of course it could not actually run on CPU_V6. But
> the use case for me is building drivers/xen/grant-table.c, which can
> only run on CPU_V7 anyway, so it is not a problem.
What I'm concerned about in this case is if you try to use instructions
which are not supported by the CPU, even in assembly, the assembler
will barf.
So, if we're building an ARMv6 + ARMv7 kernel, and you try to use
LDREXB in generic code, even though you may intend it to only be
executed on ARMv7, the assembler will error out.
We used to be able to work around that by passing -Wa,-march=armv7
to the compiler for specific files, which would then tell the assembler
to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops
which override the command line. So now the only way to do it is to
override the assemblers selected archtecture using .arch pseudo-ops
in the assembly code.
So, what I'm saying is that dropping the !ARMv6 dependency is not as
simple as it would seem, and I'm nervous about including any such
patches this close to Christmas and the merge window.
I've recently been through a run of "apply this patch, no it's wrong,
drop it, apply the next version, no it's still wrong, drop it again."
So, today is the last day I'm accepting _known_ good patches into my
tree for the 4.5 merge window. This is not yet a known good patch
because it hasn't been through several iterations of testing - and I
don't want to be adding and removing patches from my tree over
Christmas.
I'd rather leave my tree in a known good state before Christmas so
that those who want to fiddle with the kernel over the holiday break
can do so without having the hassle of trees containing partially
tested patches.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 03:45:19PM +0000, Stefano Stabellini wrote:
> > The code builds, but of course it could not actually run on CPU_V6. But
> > the use case for me is building drivers/xen/grant-table.c, which can
> > only run on CPU_V7 anyway, so it is not a problem.
>
> What I'm concerned about in this case is if you try to use instructions
> which are not supported by the CPU, even in assembly, the assembler
> will barf.
>
> So, if we're building an ARMv6 + ARMv7 kernel, and you try to use
> LDREXB in generic code, even though you may intend it to only be
> executed on ARMv7, the assembler will error out.
>
> We used to be able to work around that by passing -Wa,-march=armv7
> to the compiler for specific files, which would then tell the assembler
> to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops
> which override the command line. So now the only way to do it is to
> override the assemblers selected archtecture using .arch pseudo-ops
> in the assembly code.
>
> So, what I'm saying is that dropping the !ARMv6 dependency is not as
> simple as it would seem, and I'm nervous about including any such
> patches this close to Christmas and the merge window.
Sure, that's understandable.
Merge window aside, do you think that for the future it might be better
to change approach and write a Xen specific implementation of
sync_cmpxchg? Like this older patch tried to do
http://marc.info/?l=linux-arm-kernel&m=138436406724990&w=2
?
Hi Stefano,
[auto build test WARNING on arm/for-next]
[also build test WARNING on v4.4-rc6 next-20151222]
url: https://github.com/0day-ci/linux/commits/Stefano-Stabellini/arm-remove-CPU_V6-and-GENERIC_ATOMIC64-build-dependencies-for-XEN/20151222-222129
base: http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/gpu/drm/exynos/exynos_drm_ipp.c: In function 'ipp_get_mem_node':
>> drivers/gpu/drm/exynos/exynos_drm_ipp.c:585:4: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat=]
DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/clk.h:16,
from drivers/gpu/drm/sti/sti_hqvdp.c:7:
drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/gpu/drm/sti/sti_hqvdp.c:605:3: note: in expansion of macro 'dev_dbg'
dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
^
drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/gpu/drm/sti/sti_hqvdp.c:931:2: note: in expansion of macro 'dev_dbg'
dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/soc_camera/mx3_camera.c:13:
drivers/media/platform/soc_camera/mx3_camera.c: In function 'mx3_cam_dma_done':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/media/platform/soc_camera/mx3_camera.c:149:2: note: in expansion of macro 'dev_dbg'
dev_dbg(chan->device->dev, "callback cookie %d, active DMA 0x%08x\n",
^
drivers/media/platform/soc_camera/mx3_camera.c: In function 'mx3_videobuf_queue':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/media/platform/soc_camera/mx3_camera.c:341:2: note: in expansion of macro 'dev_dbg'
dev_dbg(icd->parent, "Submitted cookie %d DMA 0x%08x\n",
^
drivers/media/platform/soc_camera/mx3_camera.c: In function 'mx3_videobuf_release':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/media/platform/soc_camera/mx3_camera.c:370:2: note: in expansion of macro 'dev_dbg'
dev_dbg(icd->parent,
^
--
drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
>> drivers/net/ethernet/ti/davinci_cpdma.c:182:18: warning: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type
pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
^
In file included from arch/arm/include/asm/dma-mapping.h:49:0,
from include/linux/dma-mapping.h:87,
from drivers/net/ethernet/ti/davinci_cpdma.c:21:
include/asm-generic/dma-mapping-common.h:286:21: note: expected 'dma_addr_t *' but argument is of type 'phys_addr_t *'
static inline void *dma_alloc_coherent(struct device *dev, size_t size,
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from drivers/soc/ti/knav_qmss_queue.c:19:
drivers/soc/ti/knav_qmss_queue.c: In function 'knav_queue_setup_region':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/soc/ti/knav_qmss_queue.c:1025:2: note: in expansion of macro 'dev_dbg'
dev_dbg(kdev->dev,
^
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 10 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/soc/ti/knav_qmss_queue.c:1025:2: note: in expansion of macro 'dev_dbg'
dev_dbg(kdev->dev,
^
drivers/soc/ti/knav_qmss_queue.c: In function 'knav_queue_setup_link_ram':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/soc/ti/knav_qmss_queue.c:1175:3: note: in expansion of macro 'dev_dbg'
dev_dbg(kdev->dev, "linkram0: phys:%x, virt:%p, size:%x\n",
^
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/soc/ti/knav_qmss_queue.c:1184:3: note: in expansion of macro 'dev_dbg'
dev_dbg(kdev->dev, "linkram1: phys:%x, virt:%p, size:%x\n",
^
--
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from drivers/soc/ti/knav_qmss_acc.c:19:
drivers/soc/ti/knav_qmss_acc.c: In function 'knav_acc_int_handler':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
>> drivers/soc/ti/knav_qmss_acc.c:125:2: note: in expansion of macro 'dev_dbg'
dev_dbg(kdev->dev, "acc-irq: channel %d, list %d, virt %p, phys %x\n",
^
drivers/soc/ti/knav_qmss_acc.c: In function 'knav_init_acc_range':
include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/soc/ti/knav_qmss_acc.c:594:3: note: in expansion of macro 'dev_dbg'
dev_dbg(kdev->dev, "%s: channel %d, phys %08x, virt %8p\n",
^
--
drivers/video/fbdev/da8xx-fb.c: In function 'fb_probe':
>> drivers/video/fbdev/da8xx-fb.c:1429:19: warning: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type
par->vram_virt = dma_alloc_coherent(NULL,
^
In file included from arch/arm/include/asm/dma-mapping.h:49:0,
from include/linux/dma-mapping.h:87,
from drivers/video/fbdev/da8xx-fb.c:25:
include/asm-generic/dma-mapping-common.h:286:21: note: expected 'dma_addr_t *' but argument is of type 'resource_size_t *'
static inline void *dma_alloc_coherent(struct device *dev, size_t size,
^
>> drivers/video/fbdev/da8xx-fb.c:1450:24: warning: passing argument 3 of 'dma_zalloc_coherent' from incompatible pointer type
par->v_palette_base = dma_zalloc_coherent(NULL, PALETTE_SIZE,
^
In file included from drivers/video/fbdev/da8xx-fb.c:25:0:
include/linux/dma-mapping.h:187:21: note: expected 'dma_addr_t *' but argument is of type 'resource_size_t *'
static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
^
--
In file included from include/linux/dma-mapping.h:87:0,
from include/linux/dma-buf.h:31,
from drivers/gpu/drm/armada/armada_gem.c:8:
drivers/gpu/drm/armada/armada_gem.c: In function 'armada_gem_alloc_private_object':
>> arch/arm/include/asm/dma-mapping.h:16:24: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
^
>> drivers/gpu/drm/armada/armada_gem.c:204:18: note: in expansion of macro 'DMA_ERROR_CODE'
obj->dev_addr = DMA_ERROR_CODE;
^
drivers/gpu/drm/armada/armada_gem.c: In function 'armada_gem_alloc_object':
>> arch/arm/include/asm/dma-mapping.h:16:24: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
^
drivers/gpu/drm/armada/armada_gem.c:228:18: note: in expansion of macro 'DMA_ERROR_CODE'
obj->dev_addr = DMA_ERROR_CODE;
^
vim +585 drivers/gpu/drm/exynos/exynos_drm_ipp.c
c4a856a7 Andrzej Hajda 2014-08-28 569 DRM_DEBUG_KMS("i[%d]handle[0x%x]\n", i, qbuf->handle[i]);
c4a856a7 Andrzej Hajda 2014-08-28 570
c4a856a7 Andrzej Hajda 2014-08-28 571 /* get dma address by handle */
c4a856a7 Andrzej Hajda 2014-08-28 572 if (qbuf->handle[i]) {
c4a856a7 Andrzej Hajda 2014-08-28 573 dma_addr_t *addr;
c4a856a7 Andrzej Hajda 2014-08-28 574
c4a856a7 Andrzej Hajda 2014-08-28 575 addr = exynos_drm_gem_get_dma_addr(drm_dev,
d9b9734c Andrzej Hajda 2014-09-02 576 qbuf->handle[i], c_node->filp);
c4a856a7 Andrzej Hajda 2014-08-28 577 if (IS_ERR(addr)) {
c4a856a7 Andrzej Hajda 2014-08-28 578 DRM_ERROR("failed to get addr.\n");
c4a856a7 Andrzej Hajda 2014-08-28 579 ipp_put_mem_node(drm_dev, c_node, m_node);
c4a856a7 Andrzej Hajda 2014-08-28 580 return ERR_PTR(-EFAULT);
c4a856a7 Andrzej Hajda 2014-08-28 581 }
c4a856a7 Andrzej Hajda 2014-08-28 582
c4a856a7 Andrzej Hajda 2014-08-28 583 buf_info->handles[i] = qbuf->handle[i];
c4a856a7 Andrzej Hajda 2014-08-28 584 buf_info->base[i] = *addr;
c4a856a7 Andrzej Hajda 2014-08-28 @585 DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
c4a856a7 Andrzej Hajda 2014-08-28 586 buf_info->base[i], buf_info->handles[i]);
c4a856a7 Andrzej Hajda 2014-08-28 587 }
c4a856a7 Andrzej Hajda 2014-08-28 588 }
c4a856a7 Andrzej Hajda 2014-08-28 589
c4a856a7 Andrzej Hajda 2014-08-28 590 mutex_lock(&c_node->mem_lock);
e44bf6b7 Beata Michalska 2015-03-04 591 if (ipp_validate_mem_node(drm_dev, m_node, c_node)) {
e44bf6b7 Beata Michalska 2015-03-04 592 ipp_put_mem_node(drm_dev, c_node, m_node);
e44bf6b7 Beata Michalska 2015-03-04 593 mutex_unlock(&c_node->mem_lock);
:::::: The code at line 585 was first introduced by commit
:::::: c4a856a733b0aa3c62ce53efa20cc09feefb7739 drm/exynos/ipp: move nodes cleaning to separate function
:::::: TO: Andrzej Hajda <[email protected]>
:::::: CC: Inki Dae <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation