* linux-next: build warnings after merge of the kspp tree
From: Stephen Rothwell @ 2016-06-22 5:14 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-next, linux-kernel, Emese Revfy
Hi Kees,
After merging the kspp tree, today's linux-next build (i386 defconfig)
produced these warning:
x86_64-linux-gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
(over 2000 of these)
Introduced (maybe) by commit
e2135c84d5d2 ("kbuild: no gcc-plugins during cc-option tests")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the kspp tree
From: Stephen Rothwell @ 2016-06-22 4:58 UTC (permalink / raw)
To: Andrew Morton, Kees Cook
Cc: linux-next, linux-kernel, Emese Revfy, Vladimir Davydov
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/page_alloc.c
between commit:
0df42965deb7 ("latent_entropy: Add the extra_latent_entropy kernel parameter")
from the kspp tree and commit:
6f4f5445297d ("mm: charge/uncharge kmemcg from generic page allocator paths")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc mm/page_alloc.c
index 02c7a0e6e66a,180f5afc5a1f..000000000000
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -63,7 -63,7 +63,8 @@@
#include <linux/sched/rt.h>
#include <linux/page_owner.h>
#include <linux/kthread.h>
+#include <linux/random.h>
+ #include <linux/memcontrol.h>
#include <asm/sections.h>
#include <asm/tlbflush.h>
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the arm64 tree
From: Stephen Rothwell @ 2016-06-22 4:54 UTC (permalink / raw)
To: Andrew Morton, Catalin Marinas
Cc: linux-next, linux-kernel, Jisheng Zhang, Krzysztof Kozlowski
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm64/mm/dma-mapping.c
between commit:
b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")
from the arm64 tree and commit:
29af59a63ef1 ("arm64: dma-mapping: constify attrs passed to internal functions")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/mm/dma-mapping.c
index 46a4157adc17,0ef620a34c4e..000000000000
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@@ -30,9 -29,7 +30,9 @@@
#include <asm/cacheflush.h>
+static int swiotlb __read_mostly;
+
- static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
+ static pgprot_t __get_dma_pgprot(const struct dma_attrs *attrs, pgprot_t prot,
bool coherent)
{
if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))
^ permalink raw reply
* linux-next: manual merge of the drm-misc tree with the arm tree
From: Stephen Rothwell @ 2016-06-22 1:47 UTC (permalink / raw)
To: Daniel Vetter, intel-gfx, dri-devel, Russell King
Cc: linux-next, linux-kernel
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/sti/sti_drv.c
between commit:
062993b15e8e ("drm: convert DT component matching to component_match_add_release()")
from the arm tree and commit:
84601dbdea36 ("drm: sti: rework init sequence")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/sti/sti_drv.c
index 8abb57a94651,96bd3d08b2d4..000000000000
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@@ -340,14 -320,79 +320,84 @@@ static int compare_of(struct device *de
return dev->of_node == data;
}
+static void release_of(struct device *dev, void *data)
+{
+ of_node_put(data);
+}
+
+ static int sti_init(struct drm_device *ddev)
+ {
+ struct sti_private *private;
+
+ private = kzalloc(sizeof(*private), GFP_KERNEL);
+ if (!private)
+ return -ENOMEM;
+
+ ddev->dev_private = (void *)private;
+ dev_set_drvdata(ddev->dev, ddev);
+ private->drm_dev = ddev;
+
+ mutex_init(&private->commit.lock);
+ INIT_WORK(&private->commit.work, sti_atomic_work);
+
+ drm_mode_config_init(ddev);
+
+ sti_mode_config_init(ddev);
+
+ drm_kms_helper_poll_init(ddev);
+
+ return 0;
+ }
+
+ static void sti_cleanup(struct drm_device *ddev)
+ {
+ struct sti_private *private = ddev->dev_private;
+
+ if (private->fbdev) {
+ drm_fbdev_cma_fini(private->fbdev);
+ private->fbdev = NULL;
+ }
+
+ drm_kms_helper_poll_fini(ddev);
+ drm_vblank_cleanup(ddev);
+ kfree(private);
+ ddev->dev_private = NULL;
+ }
+
static int sti_bind(struct device *dev)
{
- return drm_platform_init(&sti_driver, to_platform_device(dev));
+ struct drm_device *ddev;
+ int ret;
+
+ ddev = drm_dev_alloc(&sti_driver, dev);
+ if (!ddev)
+ return -ENOMEM;
+
+ ddev->platformdev = to_platform_device(dev);
+
+ ret = sti_init(ddev);
+ if (ret)
+ goto err_drm_dev_unref;
+
+ ret = component_bind_all(ddev->dev, ddev);
+ if (ret)
+ goto err_cleanup;
+
+ ret = drm_dev_register(ddev, 0);
+ if (ret)
+ goto err_register;
+
+ drm_mode_config_reset(ddev);
+
+ return 0;
+
+ err_register:
+ drm_mode_config_cleanup(ddev);
+ err_cleanup:
+ sti_cleanup(ddev);
+ err_drm_dev_unref:
+ drm_dev_unref(ddev);
+ return ret;
}
static void sti_unbind(struct device *dev)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
From: Stephen Rothwell @ 2016-06-22 1:40 UTC (permalink / raw)
To: Daniel Vetter, intel-gfx, dri-devel
Cc: Jani Nikula, Lyude, linux-next, linux-kernel, Paulo Zanoni
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_fbc.c
between commit:
1e3fa0acfec6 ("drm/i915/fbc: Disable on HSW by default for now")
from the drm-intel-fixes tree and commit:
80788a0fbbdf ("drm/i915/fbc: sanitize i915.enable_fbc during FBC init")
from the drm-intel tree.
I fixed it up (since the former patch appears on both trees, I just
used the latter) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Arnd Bergmann @ 2016-06-21 21:14 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Chris Metcalf, Sudip Mukherjee, Stephen Rothwell, linux-next,
Ingo Molnar, linux-kernel, linux-arch
In-Reply-To: <20160621185048.GR30909@twins.programming.kicks-ass.net>
On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:
>
> > So what's your build process for the cross tools, by the way? I'm assuming
> > you're not doing a total bootstrap cross-tool build since you'd need minimal
> > kernel headers (linux/errno.h or whatever) in that case. I assume you're using
> > the host headers to build the cross tool?
> >
> > So I'm a little confused how the other kernel headers are working out for you,
> > e.g. <arch/icache.h> is referenced when building the tilegx libgcc.
>
> I've no idea; I use this thing:
>
> git://git.infradead.org/users/segher/buildall.git
>
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).
>
> I have binutils-gdb.git and gcc.bit checkouts and point the buildall
> config to that (both are on latest stable branches binutils-2_26-branch
> and gcc-6-branch resp.). And I point the kernel path to my current
> hacked up tree.
>
> I don't really rebuild the entire toolchains often, mostly only when I
> really need a new GCC or its getting really old (like I used 5.3.0 for a
> long while).
I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.
Arnd
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 18:50 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <ff97cde6-44e2-e25d-7bd2-78dbf344fc7b@mellanox.com>
On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
>
> Yes, it's probably the right thing to do. All the internal routines with "atomic32"
> or "atomic64" I assume you mean?
Yep, after this patch we have a few __atomic_ and a few __atomic32_,
which is rather unbecoming. Lemme go convert them all to __atomic32_.
> So what's your build process for the cross tools, by the way? I'm assuming
> you're not doing a total bootstrap cross-tool build since you'd need minimal
> kernel headers (linux/errno.h or whatever) in that case. I assume you're using
> the host headers to build the cross tool?
>
> So I'm a little confused how the other kernel headers are working out for you,
> e.g. <arch/icache.h> is referenced when building the tilegx libgcc.
I've no idea; I use this thing:
git://git.infradead.org/users/segher/buildall.git
Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).
I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.
I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).
^ permalink raw reply
* Re: [PATCH 2/2] ipc/sem: sem_lock with hysteresis
From: Davidlohr Bueso @ 2016-06-21 20:29 UTC (permalink / raw)
To: Manfred Spraul
Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Andrew Morton, LKML, linux-next, 1vier1, felixh
In-Reply-To: <1466280142-19741-2-git-send-email-manfred@colorfullife.com>
On Sat, 18 Jun 2016, Manfred Spraul wrote:
>sysv sem has two lock modes: One with per-semaphore locks, one lock mode
>with a single big lock for the whole array.
>When switching from the per-semaphore locks to the big lock, all
>per-semaphore locks must be scanned for ongoing operations.
>
>The patch adds a hysteresis for switching from the big lock to the per
>semaphore locks. This reduces how often the per-semaphore locks must
>be scanned.
Isn't this very arbitrary depending on the workload? Ie the other way around:
when we have a lot more simple ops going on not so good. While I'm more worried
about combinations that could cause enough complex ops to always delay taking
the finer grained lock, this change also obviously makes simple ops more expensive
on newly created segments.
In general I don't trust magic numbers much. What sort of numbers have you seen
with this patch? Is this a real concern (particularly because a lot of the sem->lock
work was because real world workloads were doing a lot more simple ops afaicr)?
Thanks,
Davidlohr
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 19:04 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621185048.GR30909@twins.programming.kicks-ass.net>
On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote:
> I've no idea; I use this thing:
>
> git://git.infradead.org/users/segher/buildall.git
>
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).
Oops, I do have..
sjlj-exceptions is causing aarch64 to fail, so I killed it, its not like
the kernel needs that.
diff --git a/build-gcc b/build-gcc
index a93c624..183f445 100755
--- a/build-gcc
+++ b/build-gcc
@@ -22,7 +22,7 @@ $ECHO -ne " gcc:" && \
$GCC_SRC/configure \
--target=$TARGET --enable-targets=all --prefix=$PREFIX \
--enable-languages=c --without-headers --disable-bootstrap \
- --enable-sjlj-exceptions --with-system-libunwind \
+ --disable-sjlj-exceptions --with-system-libunwind \
--disable-nls --disable-threads --disable-shared \
--disable-libmudflap --disable-libssp --disable-libgomp \
--disable-decimal-float --disable-libquadmath \
^ permalink raw reply related
* Re: linux-next: Tree for Jun 21
From: Chris Metcalf @ 2016-06-21 18:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621182844.GT30927@twins.programming.kicks-ass.net>
On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
>
>> >OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
>> >can build me a kernel with it.
> The below, much larger than desired, patch seems to make it go again.
>
> I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> with the builtin C11 atomic primitives.
>
> You want me to rename them all to regain consistent naming?
Yes, it's probably the right thing to do. All the internal routines with "atomic32"
or "atomic64" I assume you mean?
So what's your build process for the cross tools, by the way? I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case. I assume you're using
the host headers to build the cross tool?
So I'm a little confused how the other kernel headers are working out for you,
e.g. <arch/icache.h> is referenced when building the tilegx libgcc.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 18:28 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621172918.GS30927@twins.programming.kicks-ass.net>
On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> can build me a kernel with it.
The below, much larger than desired, patch seems to make it go again.
I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
with the builtin C11 atomic primitives.
You want me to rename them all to regain consistent naming?
---
arch/tile/include/asm/atomic_32.h | 16 ++++++++--------
arch/tile/include/asm/futex.h | 6 +++---
arch/tile/lib/atomic_32.c | 8 ++++----
arch/tile/lib/atomic_asm_32.S | 8 ++++----
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/tile/include/asm/atomic_32.h b/arch/tile/include/asm/atomic_32.h
index da8eb4e..e063825 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t *v) \
{ \
_atomic64_fetch_##op(&v->counter, i); \
} \
-static inline void atomic64_##op(long long i, atomic64_t *v) \
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v) \
{ \
smp_mb(); \
return _atomic64_fetch_##op(&v->counter, i); \
}
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
#undef ATOMIC64_OPS
@@ -272,10 +272,10 @@ extern struct __get_user __atomic_xchg(volatile int *p, int *lock, int n);
extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int n);
extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
long long o, long long n);
extern long long __atomic64_xchg(volatile long long *p, int *lock, long long n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..479b28b 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -82,9 +82,9 @@
#define __futex_set() __futex_call(__atomic_xchg)
#define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
#define __futex_cmpxchg() \
{ \
diff --git a/arch/tile/lib/atomic_32.c b/arch/tile/lib/atomic_32.c
index 5b6bd93..64d12fa 100644
--- a/arch/tile/lib/atomic_32.c
+++ b/arch/tile/lib/atomic_32.c
@@ -90,25 +90,25 @@ EXPORT_SYMBOL(_atomic_cmpxchg);
unsigned long _atomic_fetch_or(volatile unsigned long *p, unsigned long mask)
{
- return __atomic_fetch_or((int *)p, __atomic_setup(p), mask).val;
+ return __atomic32_fetch_or((int *)p, __atomic_setup(p), mask).val;
}
EXPORT_SYMBOL(_atomic_fetch_or);
unsigned long _atomic_fetch_and(volatile unsigned long *p, unsigned long mask)
{
- return __atomic_fetch_and((int *)p, __atomic_setup(p), mask).val;
+ return __atomic32_fetch_and((int *)p, __atomic_setup(p), mask).val;
}
EXPORT_SYMBOL(_atomic_fetch_and);
unsigned long _atomic_fetch_andn(volatile unsigned long *p, unsigned long mask)
{
- return __atomic_fetch_andn((int *)p, __atomic_setup(p), mask).val;
+ return __atomic32_fetch_andn((int *)p, __atomic_setup(p), mask).val;
}
EXPORT_SYMBOL(_atomic_fetch_andn);
unsigned long _atomic_fetch_xor(volatile unsigned long *p, unsigned long mask)
{
- return __atomic_fetch_xor((int *)p, __atomic_setup(p), mask).val;
+ return __atomic32_fetch_xor((int *)p, __atomic_setup(p), mask).val;
}
EXPORT_SYMBOL(_atomic_fetch_xor);
diff --git a/arch/tile/lib/atomic_asm_32.S b/arch/tile/lib/atomic_asm_32.S
index 507abdd..e78fed0 100644
--- a/arch/tile/lib/atomic_asm_32.S
+++ b/arch/tile/lib/atomic_asm_32.S
@@ -177,10 +177,10 @@ atomic_op _xchg, 32, "move r24, r2"
atomic_op _xchg_add, 32, "add r24, r22, r2"
atomic_op _xchg_add_unless, 32, \
"sne r26, r22, r2; { bbns r26, 3f; add r24, r22, r3 }"
-atomic_op _fetch_or, 32, "or r24, r22, r2"
-atomic_op _fetch_and, 32, "and r24, r22, r2"
-atomic_op _fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
-atomic_op _fetch_xor, 32, "xor r24, r22, r2"
+atomic_op 32_fetch_or, 32, "or r24, r22, r2"
+atomic_op 32_fetch_and, 32, "and r24, r22, r2"
+atomic_op 32_fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
+atomic_op 32_fetch_xor, 32, "xor r24, r22, r2"
atomic_op 64_cmpxchg, 64, "{ seq r26, r22, r2; seq r27, r23, r3 }; \
{ bbns r26, 3f; move r24, r4 }; { bbns r27, 3f; move r25, r5 }"
^ permalink raw reply related
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 17:29 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621170607.GQ30154@twins.programming.kicks-ass.net>
On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> > This has been true since gcc 4.x when tilepro support was first added.
> >
> > In any case if you replace the #include <asm/unistd.h> with
> >
> > #define __NR_FAST_cmpxchg -1
> > #define __NR_FAST_atomic_update -2
> > #define __NR_FAST_cmpxchg64 -3
> >
> > that should also probably fix it, though I haven't tested it. It probably
> > wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> > since it's not like those fast system call numbers will ever change.
OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
can build me a kernel with it.
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 17:06 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <94270f5c-1a28-f9d7-2b5a-eb874dc35398@mellanox.com>
On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include. There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
>
> I figured I would take a stab at diagnosing this myself, and it looks like the
> toolchain build assumes that the kernel headers have already been installed
> and therefore we have <asm/unistd.h> available. This actually seems like
> a reasonable prerequisite for building the toolchain. I'm guessing you
> don't? Should you? Or perhaps the compiler shouldn't make that assumption?
I can build:
ls -la /opt/cross/bin/*-gcc | wc -l
27
compilers without installing kernel headers.
> This has been true since gcc 4.x when tilepro support was first added.
>
> In any case if you replace the #include <asm/unistd.h> with
>
> #define __NR_FAST_cmpxchg -1
> #define __NR_FAST_atomic_update -2
> #define __NR_FAST_cmpxchg64 -3
>
> that should also probably fix it, though I haven't tested it. It probably
> wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> since it's not like those fast system call numbers will ever change.
OK, I'll go test that right after I've got the kid in bed .. I'll let
you know.
^ permalink raw reply
* Re: [PATCH] mwifiex: Reduce endian conversion for REG Host Commands
From: kbuild test robot @ 2016-06-21 16:41 UTC (permalink / raw)
To: Prasun Maiti
Cc: kbuild-all, Amitkumar Karwar, Nishant Sarmukadam, Linux Wireless,
Linux Next, Linux Kernel, Kalle Valo
In-Reply-To: <1466519967-15555-1-git-send-email-prasunmaiti87@gmail.com>
Hi,
[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Prasun-Maiti/mwifiex-Reduce-endian-conversion-for-REG-Host-Commands/20160621-224149
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:17: sparse: incompatible types in comparison expression (different base types)
In file included from include/linux/list.h:8:0,
from include/linux/wait.h:6,
from drivers/net/wireless/marvell/mwifiex/decl.h:26,
from drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:20:
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c: In function 'mwifiex_eeprom_read':
include/linux/kernel.h:742:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_min1 == &_min2); \
^
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:34: note: in expansion of macro 'min'
memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
^~~
--
include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:820:25: sparse: incompatible types in comparison expression (different base types)
In file included from include/linux/list.h:8:0,
from include/linux/wait.h:6,
from drivers/net/wireless/marvell/mwifiex/decl.h:26,
from drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:20:
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c: In function 'mwifiex_ret_reg_access':
include/linux/kernel.h:742:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_min1 == &_min2); \
^
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:821:6: note: in expansion of macro 'min'
min(MAX_EEPROM_DATA, eeprom->byte_count));
^~~
vim +1339 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
1323 */
1324 int
1325 mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
1326 u8 *value)
1327 {
1328 int ret;
1329 struct mwifiex_ds_read_eeprom rd_eeprom;
1330
1331 rd_eeprom.offset = offset;
1332 rd_eeprom.byte_count = bytes;
1333
1334 /* Send request to firmware */
1335 ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
1336 HostCmd_ACT_GEN_GET, 0, &rd_eeprom, true);
1337
1338 if (!ret)
> 1339 memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
1340 rd_eeprom.byte_count));
1341 return ret;
1342 }
1343
1344 /*
1345 * This function sets a generic IE. In addition to generic IE, it can
1346 * also handle WPA, WPA2 and WAPI IEs.
1347 */
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Chris Metcalf @ 2016-06-21 15:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621141435.GB7381@worktop>
On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
>>> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
>>> so should be easy enough to include. There's also a cross-toolchain for x64 I put
>>> up a while ago [1] that you could grab if you wanted to try it.
>> I usually build my own set -- and just did. But tilepro was not
>> included. Lemme go do so.
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux
I figured I would take a stab at diagnosing this myself, and it looks like the
toolchain build assumes that the kernel headers have already been installed
and therefore we have <asm/unistd.h> available. This actually seems like
a reasonable prerequisite for building the toolchain. I'm guessing you
don't? Should you? Or perhaps the compiler shouldn't make that assumption?
This has been true since gcc 4.x when tilepro support was first added.
In any case if you replace the #include <asm/unistd.h> with
#define __NR_FAST_cmpxchg -1
#define __NR_FAST_atomic_update -2
#define __NR_FAST_cmpxchg64 -3
that should also probably fix it, though I haven't tested it. It probably
wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
since it's not like those fast system call numbers will ever change.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
^ permalink raw reply
* Re: [PATCH] mwifiex: Reduce endian conversion for REG Host Commands
From: kbuild test robot @ 2016-06-21 14:57 UTC (permalink / raw)
To: Prasun Maiti
Cc: kbuild-all-JC7UmRfGjtg, Amitkumar Karwar, Nishant Sarmukadam,
Linux Wireless, Linux Next, Linux Kernel, Kalle Valo
In-Reply-To: <1466519967-15555-1-git-send-email-prasunmaiti87-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4115 bytes --]
Hi,
[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Prasun-Maiti/mwifiex-Reduce-endian-conversion-for-REG-Host-Commands/20160621-224149
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
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=sparc64
All warnings (new ones prefixed by >>):
In file included from arch/sparc/include/asm/string.h:4:0,
from include/linux/string.h:18,
from include/linux/bitmap.h:8,
from include/linux/cpumask.h:11,
from include/linux/rcupdate.h:40,
from include/linux/sysctl.h:25,
from include/linux/timer.h:244,
from drivers/net/wireless/marvell/mwifiex/decl.h:27,
from drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:20:
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c: In function 'mwifiex_eeprom_read':
include/linux/kernel.h:742:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_min1 == &_min2); \
^
arch/sparc/include/asm/string_64.h:25:48: note: in definition of macro 'memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:34: note: in expansion of macro 'min'
memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
^
--
In file included from arch/sparc/include/asm/string.h:4:0,
from include/linux/string.h:18,
from include/linux/bitmap.h:8,
from include/linux/cpumask.h:11,
from include/linux/rcupdate.h:40,
from include/linux/sysctl.h:25,
from include/linux/timer.h:244,
from drivers/net/wireless/marvell/mwifiex/decl.h:27,
from drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:20:
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c: In function 'mwifiex_ret_reg_access':
include/linux/kernel.h:742:17: warning: comparison of distinct pointer types lacks a cast
(void) (&_min1 == &_min2); \
^
arch/sparc/include/asm/string_64.h:25:48: note: in definition of macro 'memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
>> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:821:6: note: in expansion of macro 'min'
min(MAX_EEPROM_DATA, eeprom->byte_count));
^
vim +/min +1339 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
1323 */
1324 int
1325 mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
1326 u8 *value)
1327 {
1328 int ret;
1329 struct mwifiex_ds_read_eeprom rd_eeprom;
1330
1331 rd_eeprom.offset = offset;
1332 rd_eeprom.byte_count = bytes;
1333
1334 /* Send request to firmware */
1335 ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
1336 HostCmd_ACT_GEN_GET, 0, &rd_eeprom, true);
1337
1338 if (!ret)
> 1339 memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
1340 rd_eeprom.byte_count));
1341 return ret;
1342 }
1343
1344 /*
1345 * This function sets a generic IE. In addition to generic IE, it can
1346 * also handle WPA, WPA2 and WAPI IEs.
1347 */
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 46468 bytes --]
^ permalink raw reply
* Re: [PATCH] mwifiex: Reduce endian conversion for REG Host Commands
From: kbuild test robot @ 2016-06-21 14:55 UTC (permalink / raw)
To: Prasun Maiti
Cc: kbuild-all-JC7UmRfGjtg, Amitkumar Karwar, Nishant Sarmukadam,
Linux Wireless, Linux Next, Linux Kernel, Kalle Valo
In-Reply-To: <1466519967-15555-1-git-send-email-prasunmaiti87-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]
Hi,
[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Prasun-Maiti/mwifiex-Reduce-endian-conversion-for-REG-Host-Commands/20160621-224149
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
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=tile
All warnings (new ones prefixed by >>):
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c: In function 'mwifiex_eeprom_read':
>> drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:1339:34: warning: comparison of distinct pointer types lacks a cast [enabled by default]
--
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c: In function 'mwifiex_ret_reg_access':
>> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:821:6: warning: comparison of distinct pointer types lacks a cast [enabled by default]
vim +1339 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
1323 */
1324 int
1325 mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
1326 u8 *value)
1327 {
1328 int ret;
1329 struct mwifiex_ds_read_eeprom rd_eeprom;
1330
1331 rd_eeprom.offset = offset;
1332 rd_eeprom.byte_count = bytes;
1333
1334 /* Send request to firmware */
1335 ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
1336 HostCmd_ACT_GEN_GET, 0, &rd_eeprom, true);
1337
1338 if (!ret)
> 1339 memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
1340 rd_eeprom.byte_count));
1341 return ret;
1342 }
1343
1344 /*
1345 * This function sets a generic IE. In addition to generic IE, it can
1346 * also handle WPA, WPA2 and WAPI IEs.
1347 */
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 44867 bytes --]
^ permalink raw reply
* [PATCH] mwifiex: Reduce endian conversion for REG Host Commands
From: Prasun Maiti @ 2016-06-21 14:39 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Nishant Sarmukadam, Linux Wireless, Linux Next, Linux Kernel,
Kalle Valo
For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are
saved to driver. So, "leX_to_cpu" conversion is required too many
times afterwards in driver.
This patch reduces the endian: conversion without saving "cpu_to_leX"
converted values in driver. This will convert endianness in prepare
command and command response path.
Signed-off-by: Prasun Maiti <prasunmaiti87@gmail.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 ++++++++---------
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 35 +++++++++++-----------
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 21 ++++++-------
3 files changed, 40 insertions(+), 44 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index e436574..9df02ba 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
mac_reg = &cmd->params.mac_reg;
mac_reg->action = cpu_to_le16(cmd_action);
- mac_reg->offset =
- cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
- mac_reg->value = reg_rw->value;
+ mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+ mac_reg->value = cpu_to_le32(reg_rw->value);
break;
}
case HostCmd_CMD_BBP_REG_ACCESS:
@@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
bbp_reg = &cmd->params.bbp_reg;
bbp_reg->action = cpu_to_le16(cmd_action);
- bbp_reg->offset =
- cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
- bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
+ bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+ bbp_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_RF_REG_ACCESS:
@@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
rf_reg = &cmd->params.rf_reg;
rf_reg->action = cpu_to_le16(cmd_action);
- rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
- rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
+ rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+ rf_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_PMIC_REG_ACCESS:
@@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
pmic_reg = &cmd->params.pmic_reg;
pmic_reg->action = cpu_to_le16(cmd_action);
- pmic_reg->offset =
- cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
- pmic_reg->value = (u8) le32_to_cpu(reg_rw->value);
+ pmic_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+ pmic_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_CAU_REG_ACCESS:
@@ -1177,9 +1174,8 @@ static int mwifiex_cmd_reg_access(struct host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*cau_reg) + S_DS_GEN);
cau_reg = &cmd->params.rf_reg;
cau_reg->action = cpu_to_le16(cmd_action);
- cau_reg->offset =
- cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
- cau_reg->value = (u8) le32_to_cpu(reg_rw->value);
+ cau_reg->offset = cpu_to_le16((u16) reg_rw->offset);
+ cau_reg->value = (u8) reg_rw->value;
break;
}
case HostCmd_CMD_802_11_EEPROM_ACCESS:
@@ -1190,8 +1186,8 @@ static int mwifiex_cmd_reg_access(struct host_cmd_ds_command *cmd,
cmd->size = cpu_to_le16(sizeof(*cmd_eeprom) + S_DS_GEN);
cmd_eeprom->action = cpu_to_le16(cmd_action);
- cmd_eeprom->offset = rd_eeprom->offset;
- cmd_eeprom->byte_count = rd_eeprom->byte_count;
+ cmd_eeprom->offset = cpu_to_le16(rd_eeprom->offset);
+ cmd_eeprom->byte_count = cpu_to_le16(rd_eeprom->byte_count);
cmd_eeprom->value = 0;
break;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index d18c797..d7a9c79 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -781,44 +781,43 @@ static int mwifiex_ret_reg_access(u16 type, struct host_cmd_ds_command *resp,
switch (type) {
case HostCmd_CMD_MAC_REG_ACCESS:
r.mac = &resp->params.mac_reg;
- reg_rw->offset = cpu_to_le32((u32) le16_to_cpu(r.mac->offset));
- reg_rw->value = r.mac->value;
+ reg_rw->offset = (u32) le16_to_cpu(r.mac->offset);
+ reg_rw->value = le32_to_cpu(r.mac->value);
break;
case HostCmd_CMD_BBP_REG_ACCESS:
r.bbp = &resp->params.bbp_reg;
- reg_rw->offset = cpu_to_le32((u32) le16_to_cpu(r.bbp->offset));
- reg_rw->value = cpu_to_le32((u32) r.bbp->value);
+ reg_rw->offset = (u32) le16_to_cpu(r.bbp->offset);
+ reg_rw->value = (u32) r.bbp->value;
break;
case HostCmd_CMD_RF_REG_ACCESS:
r.rf = &resp->params.rf_reg;
- reg_rw->offset = cpu_to_le32((u32) le16_to_cpu(r.rf->offset));
- reg_rw->value = cpu_to_le32((u32) r.bbp->value);
+ reg_rw->offset = (u32) le16_to_cpu(r.rf->offset);
+ reg_rw->value = (u32) r.bbp->value;
break;
case HostCmd_CMD_PMIC_REG_ACCESS:
r.pmic = &resp->params.pmic_reg;
- reg_rw->offset = cpu_to_le32((u32) le16_to_cpu(r.pmic->offset));
- reg_rw->value = cpu_to_le32((u32) r.pmic->value);
+ reg_rw->offset = (u32) le16_to_cpu(r.pmic->offset);
+ reg_rw->value = (u32) r.pmic->value;
break;
case HostCmd_CMD_CAU_REG_ACCESS:
r.rf = &resp->params.rf_reg;
- reg_rw->offset = cpu_to_le32((u32) le16_to_cpu(r.rf->offset));
- reg_rw->value = cpu_to_le32((u32) r.rf->value);
+ reg_rw->offset = (u32) le16_to_cpu(r.rf->offset);
+ reg_rw->value = (u32) r.rf->value;
break;
case HostCmd_CMD_802_11_EEPROM_ACCESS:
r.eeprom = &resp->params.eeprom;
- pr_debug("info: EEPROM read len=%x\n", r.eeprom->byte_count);
- if (le16_to_cpu(eeprom->byte_count) <
- le16_to_cpu(r.eeprom->byte_count)) {
- eeprom->byte_count = cpu_to_le16(0);
+ pr_debug("info: EEPROM read len=%x\n", le16_to_cpu(r.eeprom->byte_count));
+ if (eeprom->byte_count < le16_to_cpu(r.eeprom->byte_count)) {
+ eeprom->byte_count = 0;
pr_debug("info: EEPROM read length is too big\n");
return -1;
}
- eeprom->offset = r.eeprom->offset;
- eeprom->byte_count = r.eeprom->byte_count;
- if (le16_to_cpu(eeprom->byte_count) > 0)
+ eeprom->offset = le16_to_cpu(r.eeprom->offset);
+ eeprom->byte_count = le16_to_cpu(r.eeprom->byte_count);
+ if (eeprom->byte_count > 0)
memcpy(&eeprom->value, &r.eeprom->value,
- le16_to_cpu(r.eeprom->byte_count));
+ min(MAX_EEPROM_DATA, eeprom->byte_count));
break;
default:
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 8e08626..d48379a5 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1247,7 +1247,7 @@ static int mwifiex_reg_mem_ioctl_reg_rw(struct mwifiex_private *priv,
{
u16 cmd_no;
- switch (le32_to_cpu(reg_rw->type)) {
+ switch (reg_rw->type) {
case MWIFIEX_REG_MAC:
cmd_no = HostCmd_CMD_MAC_REG_ACCESS;
break;
@@ -1282,9 +1282,9 @@ mwifiex_reg_write(struct mwifiex_private *priv, u32 reg_type,
{
struct mwifiex_ds_reg_rw reg_rw;
- reg_rw.type = cpu_to_le32(reg_type);
- reg_rw.offset = cpu_to_le32(reg_offset);
- reg_rw.value = cpu_to_le32(reg_value);
+ reg_rw.type = reg_type;
+ reg_rw.offset = reg_offset;
+ reg_rw.value = reg_value;
return mwifiex_reg_mem_ioctl_reg_rw(priv, ®_rw, HostCmd_ACT_GEN_SET);
}
@@ -1302,14 +1302,14 @@ mwifiex_reg_read(struct mwifiex_private *priv, u32 reg_type,
int ret;
struct mwifiex_ds_reg_rw reg_rw;
- reg_rw.type = cpu_to_le32(reg_type);
- reg_rw.offset = cpu_to_le32(reg_offset);
+ reg_rw.type = reg_type;
+ reg_rw.offset = reg_offset;
ret = mwifiex_reg_mem_ioctl_reg_rw(priv, ®_rw, HostCmd_ACT_GEN_GET);
if (ret)
goto done;
- *value = le32_to_cpu(reg_rw.value);
+ *value = reg_rw.value;
done:
return ret;
@@ -1328,15 +1328,16 @@ mwifiex_eeprom_read(struct mwifiex_private *priv, u16 offset, u16 bytes,
int ret;
struct mwifiex_ds_read_eeprom rd_eeprom;
- rd_eeprom.offset = cpu_to_le16((u16) offset);
- rd_eeprom.byte_count = cpu_to_le16((u16) bytes);
+ rd_eeprom.offset = offset;
+ rd_eeprom.byte_count = bytes;
/* Send request to firmware */
ret = mwifiex_send_cmd(priv, HostCmd_CMD_802_11_EEPROM_ACCESS,
HostCmd_ACT_GEN_GET, 0, &rd_eeprom, true);
if (!ret)
- memcpy(value, rd_eeprom.value, MAX_EEPROM_DATA);
+ memcpy(value, rd_eeprom.value, min(MAX_EEPROM_DATA,
+ rd_eeprom.byte_count));
return ret;
}
--
1.9.1
^ permalink raw reply related
* Re: linux-next: Tree for Jun 21
From: Sudip Mukherjee @ 2016-06-21 14:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Chris Metcalf, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621141435.GB7381@worktop>
On Tue, Jun 21, 2016 at 04:14:35PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > > I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> > > so should be easy enough to include. There's also a cross-toolchain for x64 I put
> > > up a while ago [1] that you could grab if you wanted to try it.
> >
> > I usually build my own set -- and just did. But tilepro was not
> > included. Lemme go do so.
>
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux
I have not tried with binutils-2_26. But if you want my compiler, its at
http://chat.vectorindia.net/crosstool/x86_64/5.3.0/tilepro-linux-gnu.tar.xz
regards
sudip
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 14:25 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <2c751e92-9dcb-a42c-7ecb-764d3974c1e4@mellanox.com>
On Tue, Jun 21, 2016 at 10:20:39AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include. There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
>
> That's unexpected. I'll pass this over to our compiler folks. Thanks!
If you need more info like gcc-configure, gcc-build logs or exact
gcc-6-branch commitid, please let me know.
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Chris Metcalf @ 2016-06-21 14:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621141435.GB7381@worktop>
On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
>>> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
>>> so should be easy enough to include. There's also a cross-toolchain for x64 I put
>>> up a while ago [1] that you could grab if you wanted to try it.
>> I usually build my own set -- and just did. But tilepro was not
>> included. Lemme go do so.
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux
That's unexpected. I'll pass this over to our compiler folks. Thanks!
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 14:14 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621140408.GE3704@worktop>
On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> > so should be easy enough to include. There's also a cross-toolchain for x64 I put
> > up a while ago [1] that you could grab if you wanted to try it.
>
> I usually build my own set -- and just did. But tilepro was not
> included. Lemme go do so.
binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux
---
/usr/local/src/buildall/tilepro/gcc/./gcc/xgcc -B/usr/local/src/buildall/tilepro/gcc/./gcc/ -B/opt/cross/tilepro-linux/bin/ -B/opt/cross/tilepro-linux/lib/ -isystem /opt/cross/tilepro-linux/include -isystem /opt/cross/tilepro-linux/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -I. -I. -I../.././gcc -I/usr/local/src/gcc/libgcc -I/usr/local/src/gcc/libgcc/. -I/usr/local/src/gcc/libgcc/../gcc -I/usr/local/src/gcc/libgcc/../include -DHAVE_CC_TLS -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep -fexceptions -c /usr/local/src/gcc/libgcc
/unwind-sjlj.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/local/src/gcc/libgcc/config/tilepro/atomic.c:26:0:
/usr/local/src/gcc/libgcc/config/tilepro/atomic.h:98:24: fatal error: asm/unistd.h: No such file or directory
#include <asm/unistd.h>
^
compilation terminated.
mv -f softmpy.visT softmpy.vis
make[2]: *** [atomic.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/usr/local/src/buildall/tilepro/gcc/tilepro-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/local/src/buildall/tilepro/gcc'
make: *** [all] Error 2
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 14:04 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <5ed77f4c-44eb-ca02-1373-e878d3dea31e@mellanox.com>
On Tue, Jun 21, 2016 at 09:47:00AM -0400, Chris Metcalf wrote:
> On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> >>You need to have a tilepro toolchain (not tilegx)
> >Ah, should I go use TARGET=tilepro-linux ?
>
> Yes.
> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> so should be easy enough to include. There's also a cross-toolchain for x64 I put
> up a while ago [1] that you could grab if you wanted to try it.
I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Chris Metcalf @ 2016-06-21 13:47 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <20160621124247.GM30921@twins.programming.kicks-ass.net>
On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
>> You need to have a tilepro toolchain (not tilegx)
> Ah, should I go use TARGET=tilepro-linux ?
Yes.
>> and build with ARCH=tilepro.
> tilepro)
> ARCH=tile
> CROSS_COMPILE=tilegx-linux-
> if [ "$CONFIG" == "defconfig" ] ; then
> CONFIG=tilepro_defconfig
> fi
> ;;
>
> So I suppose that too is wrong.
Yup. That's actually just building exactly what "tilegx" would build by default.
I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
so should be easy enough to include. There's also a cross-toolchain for x64 I put
up a while ago [1] that you could grab if you wanted to try it.
[1] http://www.mellanox.com/repository/solutions/tile-scm/tilepro-x86_64.tar.bz2
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
^ permalink raw reply
* Re: linux-next: Tree for Jun 21
From: Peter Zijlstra @ 2016-06-21 12:42 UTC (permalink / raw)
To: Chris Metcalf
Cc: Sudip Mukherjee, Stephen Rothwell, linux-next, Ingo Molnar,
linux-kernel, linux-arch
In-Reply-To: <f43656af-050c-82b3-e10d-66be072be320@mellanox.com>
On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
>
> On inspection, I note that the arch/tile/include/atomic_32.h header has
>
> ATOMIC64_OP(and)
> ATOMIC64_OP(or)
> ATOMIC64_OP(xor)
>
> but these should be ATOMIC64_OPS, plural.
Bugger, I'll go fix. Clearly nobody has tilepro toolchains :/
> Peter, what toolchain were you using for tilepro build testing?
tilegx-linux-
> You need to have a tilepro toolchain (not tilegx)
Ah, should I go use TARGET=tilepro-linux ?
> and build with ARCH=tilepro.
tilepro)
ARCH=tile
CROSS_COMPILE=tilegx-linux-
if [ "$CONFIG" == "defconfig" ] ; then
CONFIG=tilepro_defconfig
fi
;;
So I suppose that too is wrong.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox