Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

Arend van Spriel [off-list ref] writes:

On 07/24/2015 07:22 PM, Vineet Gupta wrote:

quoted

On Friday 24 July 2015 08:02 PM, Kalle Valo wrote:

quoted

Vineet Gupta [off-list ref] writes:

quoted

quoted

There's already a generic implementation so use that instead.
---
I'm not sure if the driver usage of atomic_or?() is correct in terms of
storage size of @val for 64 bit arches.

Assuming LP64 programming model for linux on say x86_64: atomic_or()
callers in this driver use long (sana 64 bit) storage and pass it to
atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ?
---
Cc: Brett Rudley <redacted>
Cc: Arend van Spriel <redacted>
Cc: "Franky (Zhenhui) Lin" <redacted>
Cc: Hante Meuleman <redacted>
Cc: Kalle Valo <redacted>
Cc: Pieter-Paul Giesberts <redacted>
Cc: Daniel Kim <redacted>
Cc: <redacted>
Cc: <redacted>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: <redacted>
Cc: <redacted>
Cc: <redacted>
Signed-off-by: Vineet Gupta <redacted>

Signed-off-by: Vineet Gupta <redacted>

What's the plan with this patch? Should I take it to my
wireless-drivers-next tree or will someone else take it?

Per last discussion on this topic, Arend wanted to discuss abt this with Hante.
I'm not taking it anyways so feel free to pick it up if you want !

Well, that was before your "timeline" clarification about the generic
function. One what tree is this patch based?

Yeah, if this patch depends on another patch I need to know about it.
Otherwise I might break something when I apply this patch.

-- 
Kalle Valo

On Monday 27 July 2015 01:08 PM, Kalle Valo wrote:

quoted

quoted

quoted

quoted

Per last discussion on this topic, Arend wanted to discuss abt this with Hante.
I'm not taking it anyways so feel free to pick it up if you want !

Well, that was before your "timeline" clarification about the generic
function. One what tree is this patch based?

Yeah, if this patch depends on another patch I need to know about it.
Otherwise I might break something when I apply this patch.

It was latest linux-next at the time, 4.1-rcx perhaps, don't remember exactly. But
it certainly doesn't depend on any new code  - the patch simply makes use of an
existing API vs. using a local hard coded version of same.

Give it a spin off your existing tree - shdn't be too difficult to test  I presume.

-Vineet