[PATCH] backports: add definitions S32_MAX and S32_MIN

[PATCH] backports: add definitions S32_MAX and S32_MIN

[Arend van Spriel]

Since commit 20e32810bcf4 ("cfg80211: Accept multiple RSSI thresholds
for CQM") the backports need to have S32_MAX and S32_MIN which were
introduced in kernel.h since v3.14.

Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
 backport/backport-include/linux/kernel.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/backport/backport-include/linux/kernel.h b/backport/backport-include/linux/kernel.h
index 4ad000c..ea55d7d 100644
--- a/backport/backport-include/linux/kernel.h
+++ b/backport/backport-include/linux/kernel.h
@@ -73,6 +73,14 @@
 #define U32_MAX		((u32)~0U)
 #endif
 
+#ifndef S32_MAX
+#define S32_MAX		((s32)(U32_MAX>>1))
+#endif
+
+#ifndef S32_MIN
+#define S32_MIN		((s32)(-S32_MAX - 1))
+#endif
+
 #ifndef __round_mask
 #define __round_mask(x, y) ((__typeof__(x))((y)-1))
 #define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: [PATCH] backports: add definitions S32_MAX and S32_MIN

[Johannes Berg]

On Wed, 2017-02-22 at 22:18 +0000, Arend van Spriel wrote:
> Since commit 20e32810bcf4 ("cfg80211: Accept multiple RSSI thresholds
> for CQM") the backports need to have S32_MAX and S32_MIN which were
> introduced in kernel.h since v3.14.
> 

Applied, thanks.

I really need to set up automation for this, to continuously monitor a
few trees ...

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: [PATCH] backports: add definitions S32_MAX and S32_MIN

[Arend Van Spriel]

On 23-2-2017 8:49, Johannes Berg wrote:
> On Wed, 2017-02-22 at 22:18 +0000, Arend van Spriel wrote:
>> Since commit 20e32810bcf4 ("cfg80211: Accept multiple RSSI thresholds
>> for CQM") the backports need to have S32_MAX and S32_MIN which were
>> introduced in kernel.h since v3.14.
>>
> 
> Applied, thanks.
> 
> I really need to set up automation for this, to continuously monitor a
> few trees ...

I create a package nightly for our internal tree and wireless-testing
and build for couple of target kernels to run some wifi tests on target
systems. So I tend to hit issues pretty soon. Not covering all target
kernels though.

Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: [PATCH] backports: add definitions S32_MAX and S32_MIN

[Johannes Berg]

> I create a package nightly for our internal tree and wireless-testing
> and build for couple of target kernels to run some wifi tests on
> target systems. So I tend to hit issues pretty soon. Not covering all
> target kernels though.

Ok, that's nice. I'm torn between doing something that runs on our
existing infrastructure (easy, but internal) or building some kind of
infrastructure, likely on the build box we have from the LF... that's
harder but accessible to people other than me.

Or are there any alternatives? Perhaps if I put the scripts upstream
then it doesn't matter that I might actually be running it on our
internal infrastructure, since anyone can just take the scripts and run
them?

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: [PATCH] backports: add definitions S32_MAX and S32_MIN

[Arend Van Spriel]

On 24-2-2017 13:30, Johannes Berg wrote:
> 
>> I create a package nightly for our internal tree and wireless-testing
>> and build for couple of target kernels to run some wifi tests on
>> target systems. So I tend to hit issues pretty soon. Not covering all
>> target kernels though.
> 
> Ok, that's nice. I'm torn between doing something that runs on our
> existing infrastructure (easy, but internal) or building some kind of
> infrastructure, likely on the build box we have from the LF... that's
> harder but accessible to people other than me.
> 
> Or are there any alternatives? Perhaps if I put the scripts upstream
> then it doesn't matter that I might actually be running it on our
> internal infrastructure, since anyone can just take the scripts and run
> them?

The alternative is fine by me.

Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe backports" in