Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

[Peter Zijlstra]

On Wed, Mar 01, 2017 at 01:28:43PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 02:43:23PM +0900, Byungchul Park wrote:

> > It's an optimization, but very essential and important optimization.

Since its not for correctness, please put it in a separate patch with a
good Changelog, the below would make a good beginning of that.

Also, I feel, the source comments can be improved.

> >   in hlocks[]
> >   
> >   A gen_id (4) --+
> >  | previous gen_id
> >   B gen_id (3) <-+
> >   C gen_id (3)
> >   D gen_id (2)
> > oldest -> E gen_id (1)
> > 
> >   in xhlocks[]
> >   
> >^  A gen_id (4) prev_gen_id (3: B's gen id)
> >|  B gen_id (3) prev_gen_id (3: C's gen id)
> >|  C gen_id (3) prev_gen_id (2: D's gen id)
> >|  D gen_id (2) prev_gen_id (1: E's gen id)
> >|  E gen_id (1) prev_gen_id (NA)
> > 
> > Let's consider the case that the gen id of xlock to commit is 3.
> > 
> > In this case, it's engough to generate 'the xlock -> C'. 'the xlock -> B'
> > and 'the xlock -> A' are unnecessary since it's covered by 'C -> B' and
> > 'B -> A' which are already generated by original lockdep.
> > 
> > I use the prev_gen_id to avoid adding this kind of redundant
> > dependencies. In other words, xhlock->prev_gen_id >= xlock->hlock.gen_id
> > means that the previous lock in hlocks[] is able to handle the
> > dependency on its commit stage.
> > 
> 
> Aah, I completely missed it was against held_locks.
> 
> Hurm.. it feels like this is solving a problem we shouldn't be solving
> though.
> 
> That is, ideally we'd already be able to (quickly) tell if a relation
> exists or not, but given how the whole chain_hash stuff is build now, it
> looks like we cannot.
> 
> 
> Let me think about this a bit more.

OK, so neither this nor the chain-hash completely avoid redundant
dependencies. The only way to do that is doing graph-walks for every
proposed link.

Now, we already do a ton of __bfs() walks in check_prev_add(), so one
more might not hurt too much [*].

Esp. with the chain-hash avoiding all the obvious duplicate work, this
might just work.

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index a95e5d1..7baea89 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1860,6 +1860,17 @@ check_prev_add(struct task_struct *curr, struct 
held_lock *prev,
}
}
 
+   /*
+* Is the  ->  redundant?
+*/
+   this.class = hlock_class(prev);
+   this.parent = NULL;
+   ret = check_noncircular(, hlock_class(next), _entry);
+   if (!ret) /* exists, redundant */
+   return 2;
+   if (ret < 0)
+   return print_bfs_bug(ret);
+
if (!*stack_saved) {
if (!save_trace())
return 0;



[*] A while ago someone, and I cannot find the email just now, asked if
we could not implement the RECLAIM_FS inversion stuff with a 'fake' lock
like we use for other things like workqueues etc. I think this should be
possible which allows reducing the 'irq' states and will reduce the
amount of __bfs() lookups we do.

Removing the 1 IRQ state, would result in 4 less __bfs() walks if I'm
not mistaken, more than making up for the 1 we'd have to add to detect
redundant links.


 include/linux/lockdep.h | 11 +-
 include/linux/sched.h   |  1 -
 kernel/locking/lockdep.c| 87 +
 kernel/locking/lockdep_states.h |  1 -
 mm/internal.h   | 40 +++
 mm/page_alloc.c | 13 --
 mm/slab.h   |  7 +++-
 mm/slob.c   |  8 +++-
 mm/vmscan.c | 13 +++---
 9 files changed, 71 insertions(+), 110 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 1e327bb..6ba1a65 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -29,7 +29,7 @@ extern int lock_stat;
  * We'd rather not expose kernel/lockdep_states.h this wide, but we do need
  * the total number of states... :-(
  */
-#define XXX_LOCK_USAGE_STATES  (1+3*4)
+#define XXX_LOCK_USAGE_STATES  (1+2*4)
 
 /*
  * NR_LOCKDEP_CACHING_CLASSES ... Number of classes
@@ -361,10 +361,6 @@ static inline void lock_set_subclass(struct lockdep_map 
*lock,
lock_set_class(lock, lock->name, lock->key, subclass, ip);
 }
 
-extern void lockdep_set_current_reclaim_state(gfp_t gfp_mask);
-extern void lockdep_clear_current_reclaim_state(void);
-extern void lockdep_trace_alloc(gfp_t mask);
-
 struct pin_cookie { unsigned int val; };
 
 #define NIL_COOKIE (struct pin_cookie){ .val = 0U, }
@@ -373,7 +369,7 @@ extern struct pin_cookie lock_pin_lock(struct lockdep_map 
*lock);
 extern void lock_repin_lock(struct lockdep_map *lock, struct pin_cookie);
 extern void lock_unpin_lock(struct lockdep_map *lock, 

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

[Peter Zijlstra]

On Wed, Mar 01, 2017 at 01:28:43PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 01, 2017 at 02:43:23PM +0900, Byungchul Park wrote:

> > It's an optimization, but very essential and important optimization.

Since its not for correctness, please put it in a separate patch with a
good Changelog, the below would make a good beginning of that.

Also, I feel, the source comments can be improved.

> >   in hlocks[]
> >   
> >   A gen_id (4) --+
> >  | previous gen_id
> >   B gen_id (3) <-+
> >   C gen_id (3)
> >   D gen_id (2)
> > oldest -> E gen_id (1)
> > 
> >   in xhlocks[]
> >   
> >^  A gen_id (4) prev_gen_id (3: B's gen id)
> >|  B gen_id (3) prev_gen_id (3: C's gen id)
> >|  C gen_id (3) prev_gen_id (2: D's gen id)
> >|  D gen_id (2) prev_gen_id (1: E's gen id)
> >|  E gen_id (1) prev_gen_id (NA)
> > 
> > Let's consider the case that the gen id of xlock to commit is 3.
> > 
> > In this case, it's engough to generate 'the xlock -> C'. 'the xlock -> B'
> > and 'the xlock -> A' are unnecessary since it's covered by 'C -> B' and
> > 'B -> A' which are already generated by original lockdep.
> > 
> > I use the prev_gen_id to avoid adding this kind of redundant
> > dependencies. In other words, xhlock->prev_gen_id >= xlock->hlock.gen_id
> > means that the previous lock in hlocks[] is able to handle the
> > dependency on its commit stage.
> > 
> 
> Aah, I completely missed it was against held_locks.
> 
> Hurm.. it feels like this is solving a problem we shouldn't be solving
> though.
> 
> That is, ideally we'd already be able to (quickly) tell if a relation
> exists or not, but given how the whole chain_hash stuff is build now, it
> looks like we cannot.
> 
> 
> Let me think about this a bit more.

OK, so neither this nor the chain-hash completely avoid redundant
dependencies. The only way to do that is doing graph-walks for every
proposed link.

Now, we already do a ton of __bfs() walks in check_prev_add(), so one
more might not hurt too much [*].

Esp. with the chain-hash avoiding all the obvious duplicate work, this
might just work.

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index a95e5d1..7baea89 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1860,6 +1860,17 @@ check_prev_add(struct task_struct *curr, struct 
held_lock *prev,
}
}
 
+   /*
+* Is the  ->  redundant?
+*/
+   this.class = hlock_class(prev);
+   this.parent = NULL;
+   ret = check_noncircular(, hlock_class(next), _entry);
+   if (!ret) /* exists, redundant */
+   return 2;
+   if (ret < 0)
+   return print_bfs_bug(ret);
+
if (!*stack_saved) {
if (!save_trace())
return 0;



[*] A while ago someone, and I cannot find the email just now, asked if
we could not implement the RECLAIM_FS inversion stuff with a 'fake' lock
like we use for other things like workqueues etc. I think this should be
possible which allows reducing the 'irq' states and will reduce the
amount of __bfs() lookups we do.

Removing the 1 IRQ state, would result in 4 less __bfs() walks if I'm
not mistaken, more than making up for the 1 we'd have to add to detect
redundant links.


 include/linux/lockdep.h | 11 +-
 include/linux/sched.h   |  1 -
 kernel/locking/lockdep.c| 87 +
 kernel/locking/lockdep_states.h |  1 -
 mm/internal.h   | 40 +++
 mm/page_alloc.c | 13 --
 mm/slab.h   |  7 +++-
 mm/slob.c   |  8 +++-
 mm/vmscan.c | 13 +++---
 9 files changed, 71 insertions(+), 110 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 1e327bb..6ba1a65 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -29,7 +29,7 @@ extern int lock_stat;
  * We'd rather not expose kernel/lockdep_states.h this wide, but we do need
  * the total number of states... :-(
  */
-#define XXX_LOCK_USAGE_STATES  (1+3*4)
+#define XXX_LOCK_USAGE_STATES  (1+2*4)
 
 /*
  * NR_LOCKDEP_CACHING_CLASSES ... Number of classes
@@ -361,10 +361,6 @@ static inline void lock_set_subclass(struct lockdep_map 
*lock,
lock_set_class(lock, lock->name, lock->key, subclass, ip);
 }
 
-extern void lockdep_set_current_reclaim_state(gfp_t gfp_mask);
-extern void lockdep_clear_current_reclaim_state(void);
-extern void lockdep_trace_alloc(gfp_t mask);
-
 struct pin_cookie { unsigned int val; };
 
 #define NIL_COOKIE (struct pin_cookie){ .val = 0U, }
@@ -373,7 +369,7 @@ extern struct pin_cookie lock_pin_lock(struct lockdep_map 
*lock);
 extern void lock_repin_lock(struct lockdep_map *lock, struct pin_cookie);
 extern void lock_unpin_lock(struct lockdep_map *lock, 

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

[Mark Rutland]

On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote:
> The CCP device is part of the AMD Secure Processor. In order to expand the
> usage of the AMD Secure Processor, create a framework that allows functional
> components of the AMD Secure Processor to be initialized and handled
> appropriately.
> 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Tom Lendacky 
> ---
>  drivers/crypto/Kconfig   |   10 +
>  drivers/crypto/ccp/Kconfig   |   43 +++--
>  drivers/crypto/ccp/Makefile  |8 -
>  drivers/crypto/ccp/ccp-dev-v3.c  |   86 +-
>  drivers/crypto/ccp/ccp-dev-v5.c  |   73 -
>  drivers/crypto/ccp/ccp-dev.c |  137 +---
>  drivers/crypto/ccp/ccp-dev.h |   35 
>  drivers/crypto/ccp/sp-dev.c  |  308 
>  drivers/crypto/ccp/sp-dev.h  |  140 
>  drivers/crypto/ccp/sp-pci.c  |  324 
> ++
>  drivers/crypto/ccp/sp-platform.c |  268 +++
>  include/linux/ccp.h  |3 
>  12 files changed, 1240 insertions(+), 195 deletions(-)
>  create mode 100644 drivers/crypto/ccp/sp-dev.c
>  create mode 100644 drivers/crypto/ccp/sp-dev.h
>  create mode 100644 drivers/crypto/ccp/sp-pci.c
>  create mode 100644 drivers/crypto/ccp/sp-platform.c

> diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
> index 346ceb8..8127e18 100644
> --- a/drivers/crypto/ccp/Makefile
> +++ b/drivers/crypto/ccp/Makefile
> @@ -1,11 +1,11 @@
> -obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
> -ccp-objs := ccp-dev.o \
> +obj-$(CONFIG_CRYPTO_DEV_SP_DD) += ccp.o
> +ccp-objs := sp-dev.o sp-platform.o
> +ccp-$(CONFIG_PCI) += sp-pci.o
> +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \
>   ccp-ops.o \
>   ccp-dev-v3.o \
>   ccp-dev-v5.o \
> - ccp-platform.o \
>   ccp-dmaengine.o

It looks like ccp-platform.c has morphed into sp-platform.c (judging by
the compatible string and general shape of the code), and the original
ccp-platform.c is no longer built.

Shouldn't ccp-platform.c be deleted by this patch?

Thanks,
Mark.

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

[Mark Rutland]

On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote:
> The CCP device is part of the AMD Secure Processor. In order to expand the
> usage of the AMD Secure Processor, create a framework that allows functional
> components of the AMD Secure Processor to be initialized and handled
> appropriately.
> 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Tom Lendacky 
> ---
>  drivers/crypto/Kconfig   |   10 +
>  drivers/crypto/ccp/Kconfig   |   43 +++--
>  drivers/crypto/ccp/Makefile  |8 -
>  drivers/crypto/ccp/ccp-dev-v3.c  |   86 +-
>  drivers/crypto/ccp/ccp-dev-v5.c  |   73 -
>  drivers/crypto/ccp/ccp-dev.c |  137 +---
>  drivers/crypto/ccp/ccp-dev.h |   35 
>  drivers/crypto/ccp/sp-dev.c  |  308 
>  drivers/crypto/ccp/sp-dev.h  |  140 
>  drivers/crypto/ccp/sp-pci.c  |  324 
> ++
>  drivers/crypto/ccp/sp-platform.c |  268 +++
>  include/linux/ccp.h  |3 
>  12 files changed, 1240 insertions(+), 195 deletions(-)
>  create mode 100644 drivers/crypto/ccp/sp-dev.c
>  create mode 100644 drivers/crypto/ccp/sp-dev.h
>  create mode 100644 drivers/crypto/ccp/sp-pci.c
>  create mode 100644 drivers/crypto/ccp/sp-platform.c

> diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
> index 346ceb8..8127e18 100644
> --- a/drivers/crypto/ccp/Makefile
> +++ b/drivers/crypto/ccp/Makefile
> @@ -1,11 +1,11 @@
> -obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
> -ccp-objs := ccp-dev.o \
> +obj-$(CONFIG_CRYPTO_DEV_SP_DD) += ccp.o
> +ccp-objs := sp-dev.o sp-platform.o
> +ccp-$(CONFIG_PCI) += sp-pci.o
> +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \
>   ccp-ops.o \
>   ccp-dev-v3.o \
>   ccp-dev-v5.o \
> - ccp-platform.o \
>   ccp-dmaengine.o

It looks like ccp-platform.c has morphed into sp-platform.c (judging by
the compatible string and general shape of the code), and the original
ccp-platform.c is no longer built.

Shouldn't ccp-platform.c be deleted by this patch?

Thanks,
Mark.

[PATCH 06/11] drm/meson: Add support for HDMI venc modes and settings

[Neil Armstrong]

This patch adds support for the supported HDMI Venc modes and add the VPP mux
value to switch to ENCP encoder.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc.c | 1245 +++-
 drivers/gpu/drm/meson/meson_venc.h |7 +
 drivers/gpu/drm/meson/meson_vpp.h  |2 +
 3 files changed, 1249 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index f7c87017..31dc275 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -30,12 +30,37 @@
  * VENC Handle the pixels encoding to the output formats.
  * We handle the following encodings :
  * - CVBS Encoding via the ENCI encoder and VDAC digital to analog converter
- *
- * What is missing :
  * - TMDS/HDMI Encoding via ENCI_DIV and ENCP
  * - Setup of more clock rates for HDMI modes
+ *
+ * What is missing :
  * - LCD Panel encoding via ENCL
  * - TV Panel encoding via ENCT
+ *
+ * VENC paths :
+ *_   _   
+ * vd1---| |-| | | VENC /-|VDAC
+ * vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
+ * osd1--| |-| | | \  | X--HDMI-TX
+ * osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
+ *   |  | |
+ *   |  \--ENCL---|LVDS
+ *   ||
+ *
+ * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC
+ * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI.
+ * The ENCP is designed for Progressive encoding but can also generate
+ * 1080i interlaced pixels, and was initialy desined to encode pixels for
+ * VDAC to output RGB ou YUV analog outputs.
+ * It's output is only used through the ENCP_DVI encoder for HDMI.
+ * The ENCL LVDS encoder is not implemented.
+ *
+ * The ENCI and ENCP encoders needs specially defined parameters for each
+ * supported mode and thus cannot be determined from standard video timings.
+ *
+ * The ENCI end ENCP DVI encoders are more generic and can generate any timings
+ * from the pixel data generated by ENCI or ENCP, so can use the standard video
+ * timings are source for HW parameters.
  */
 
 /* HHI Registers */
@@ -91,6 +116,1219 @@ struct meson_cvbs_enci_mode meson_cvbs_enci_ntsc = {
.analog_sync_adj = 0x9c00,
 };
 
+union meson_hdmi_venc_mode {
+   struct {
+   unsigned int mode_tag;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_even;
+   unsigned int vso_odd;
+   unsigned int macv_max_amp;
+   unsigned int video_prog_mode;
+   unsigned int video_mode;
+   unsigned int sch_adjust;
+   unsigned int yc_delay;
+   unsigned int pixel_start;
+   unsigned int pixel_end;
+   unsigned int top_field_line_start;
+   unsigned int top_field_line_end;
+   unsigned int bottom_field_line_start;
+   unsigned int bottom_field_line_end;
+   } enci;
+   struct {
+   unsigned int dvi_settings;
+   unsigned int video_mode;
+   unsigned int video_mode_adv;
+   unsigned int video_prog_mode;
+   bool video_prog_mode_present;
+   unsigned int video_sync_mode;
+   bool video_sync_mode_present;
+   unsigned int video_yc_dly;
+   bool video_yc_dly_present;
+   unsigned int video_rgb_ctrl;
+   bool video_rgb_ctrl_present;
+   unsigned int video_filt_ctrl;
+   bool video_filt_ctrl_present;
+   unsigned int video_ofld_voav_ofst;
+   bool video_ofld_voav_ofst_present;
+   unsigned int yfp1_htime;
+   unsigned int yfp2_htime;
+   unsigned int max_pxcnt;
+   unsigned int hspuls_begin;
+   unsigned int hspuls_end;
+   unsigned int hspuls_switch;
+   unsigned int vspuls_begin;
+   unsigned int vspuls_end;
+   unsigned int vspuls_bline;
+   unsigned int vspuls_eline;
+   unsigned int eqpuls_begin;
+   bool eqpuls_begin_present;
+   unsigned int eqpuls_end;
+   bool eqpuls_end_present;
+   unsigned int eqpuls_bline;
+   bool eqpuls_bline_present;
+   unsigned int eqpuls_eline;
+   bool eqpuls_eline_present;
+   unsigned int havon_begin;
+   unsigned int havon_end;
+   unsigned int vavon_bline;
+   unsigned int vavon_eline;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_begin;
+   unsigned int vso_end;
+   unsigned int vso_bline;
+

[PATCH 06/11] drm/meson: Add support for HDMI venc modes and settings

[Neil Armstrong]

This patch adds support for the supported HDMI Venc modes and add the VPP mux
value to switch to ENCP encoder.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc.c | 1245 +++-
 drivers/gpu/drm/meson/meson_venc.h |7 +
 drivers/gpu/drm/meson/meson_vpp.h  |2 +
 3 files changed, 1249 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index f7c87017..31dc275 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -30,12 +30,37 @@
  * VENC Handle the pixels encoding to the output formats.
  * We handle the following encodings :
  * - CVBS Encoding via the ENCI encoder and VDAC digital to analog converter
- *
- * What is missing :
  * - TMDS/HDMI Encoding via ENCI_DIV and ENCP
  * - Setup of more clock rates for HDMI modes
+ *
+ * What is missing :
  * - LCD Panel encoding via ENCL
  * - TV Panel encoding via ENCT
+ *
+ * VENC paths :
+ *_   _   
+ * vd1---| |-| | | VENC /-|VDAC
+ * vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
+ * osd1--| |-| | | \  | X--HDMI-TX
+ * osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
+ *   |  | |
+ *   |  \--ENCL---|LVDS
+ *   ||
+ *
+ * The ENCI is designed for PAl or NTSC encoding and can go through the VDAC
+ * directly for CVBS encoding or through the ENCI_DVI encoder for HDMI.
+ * The ENCP is designed for Progressive encoding but can also generate
+ * 1080i interlaced pixels, and was initialy desined to encode pixels for
+ * VDAC to output RGB ou YUV analog outputs.
+ * It's output is only used through the ENCP_DVI encoder for HDMI.
+ * The ENCL LVDS encoder is not implemented.
+ *
+ * The ENCI and ENCP encoders needs specially defined parameters for each
+ * supported mode and thus cannot be determined from standard video timings.
+ *
+ * The ENCI end ENCP DVI encoders are more generic and can generate any timings
+ * from the pixel data generated by ENCI or ENCP, so can use the standard video
+ * timings are source for HW parameters.
  */
 
 /* HHI Registers */
@@ -91,6 +116,1219 @@ struct meson_cvbs_enci_mode meson_cvbs_enci_ntsc = {
.analog_sync_adj = 0x9c00,
 };
 
+union meson_hdmi_venc_mode {
+   struct {
+   unsigned int mode_tag;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_even;
+   unsigned int vso_odd;
+   unsigned int macv_max_amp;
+   unsigned int video_prog_mode;
+   unsigned int video_mode;
+   unsigned int sch_adjust;
+   unsigned int yc_delay;
+   unsigned int pixel_start;
+   unsigned int pixel_end;
+   unsigned int top_field_line_start;
+   unsigned int top_field_line_end;
+   unsigned int bottom_field_line_start;
+   unsigned int bottom_field_line_end;
+   } enci;
+   struct {
+   unsigned int dvi_settings;
+   unsigned int video_mode;
+   unsigned int video_mode_adv;
+   unsigned int video_prog_mode;
+   bool video_prog_mode_present;
+   unsigned int video_sync_mode;
+   bool video_sync_mode_present;
+   unsigned int video_yc_dly;
+   bool video_yc_dly_present;
+   unsigned int video_rgb_ctrl;
+   bool video_rgb_ctrl_present;
+   unsigned int video_filt_ctrl;
+   bool video_filt_ctrl_present;
+   unsigned int video_ofld_voav_ofst;
+   bool video_ofld_voav_ofst_present;
+   unsigned int yfp1_htime;
+   unsigned int yfp2_htime;
+   unsigned int max_pxcnt;
+   unsigned int hspuls_begin;
+   unsigned int hspuls_end;
+   unsigned int hspuls_switch;
+   unsigned int vspuls_begin;
+   unsigned int vspuls_end;
+   unsigned int vspuls_bline;
+   unsigned int vspuls_eline;
+   unsigned int eqpuls_begin;
+   bool eqpuls_begin_present;
+   unsigned int eqpuls_end;
+   bool eqpuls_end_present;
+   unsigned int eqpuls_bline;
+   bool eqpuls_bline_present;
+   unsigned int eqpuls_eline;
+   bool eqpuls_eline_present;
+   unsigned int havon_begin;
+   unsigned int havon_end;
+   unsigned int vavon_bline;
+   unsigned int vavon_eline;
+   unsigned int hso_begin;
+   unsigned int hso_end;
+   unsigned int vso_begin;
+   unsigned int vso_end;
+   unsigned int vso_bline;
+   unsigned int 

[PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN

[Arnd Bergmann]

Enabling CONFIG_KASAN can lead to an instant stack overflow:

drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_broadwell_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 5376 bytes 
is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_skl_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 5296 bytes 
is larger than 3072 bytes [-Werror=frame-larger-than=]

The reason is the INTEL_GVT_MMIO_OFFSET() hack that attempts to convert any type
(including i915_reg_t) into a u32 by reading the first four bytes, in 
combination
with the stack sanitizer that adds a redzone around each instance.

Originally, i915_reg_t was introduced to add a little extra type safety by
disallowing simple type casts, and INTEL_GVT_MMIO_OFFSET() goes the opposite
way by allowing any type as input, including those that are not safe in this
context.

I'm replacing it with an implementation that specifically allows the three
types that are actually used as input: 'i915_reg_t' (from _MMIO constants),
'int' (from other constants), and 'unsigned int' (from function arguments),
and any other type should now provoke a build error. This also solves the
stack overflow as we no longer use a local variable for each instance.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/gvt/mmio.h | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio.h b/drivers/gpu/drm/i915/gvt/mmio.h
index 3bc620f56f35..bf40100fc626 100644
--- a/drivers/gpu/drm/i915/gvt/mmio.h
+++ b/drivers/gpu/drm/i915/gvt/mmio.h
@@ -78,13 +78,20 @@ bool intel_gvt_match_device(struct intel_gvt *gvt, unsigned 
long device);
 int intel_gvt_setup_mmio_info(struct intel_gvt *gvt);
 void intel_gvt_clean_mmio_info(struct intel_gvt *gvt);
 
+static inline u32 intel_gvt_mmio_offset(unsigned int offset)
+{
+   return offset;
+}
+
 struct intel_gvt_mmio_info *intel_gvt_find_mmio_info(struct intel_gvt *gvt,
 unsigned int offset);
-#define INTEL_GVT_MMIO_OFFSET(reg) ({ \
-   typeof(reg) __reg = reg; \
-   u32 *offset = (u32 *)&__reg; \
-   *offset; \
-})
+#define INTEL_GVT_MMIO_OFFSET(reg) \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), int), 
intel_gvt_mmio_offset, \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), unsigned int), 
intel_gvt_mmio_offset, \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), i915_reg_t), 
i915_mmio_reg_offset, \
+   (void)(0) \
+)))(reg)
+
 
 int intel_vgpu_init_mmio(struct intel_vgpu *vgpu);
 void intel_vgpu_reset_mmio(struct intel_vgpu *vgpu);
-- 
2.9.0

[PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN

[Arnd Bergmann]

Enabling CONFIG_KASAN can lead to an instant stack overflow:

drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_broadwell_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the frame size of 5376 bytes 
is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_skl_mmio_info':
drivers/gpu/drm/i915/gvt/handlers.c:2628:1: error: the frame size of 5296 bytes 
is larger than 3072 bytes [-Werror=frame-larger-than=]

The reason is the INTEL_GVT_MMIO_OFFSET() hack that attempts to convert any type
(including i915_reg_t) into a u32 by reading the first four bytes, in 
combination
with the stack sanitizer that adds a redzone around each instance.

Originally, i915_reg_t was introduced to add a little extra type safety by
disallowing simple type casts, and INTEL_GVT_MMIO_OFFSET() goes the opposite
way by allowing any type as input, including those that are not safe in this
context.

I'm replacing it with an implementation that specifically allows the three
types that are actually used as input: 'i915_reg_t' (from _MMIO constants),
'int' (from other constants), and 'unsigned int' (from function arguments),
and any other type should now provoke a build error. This also solves the
stack overflow as we no longer use a local variable for each instance.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/gvt/mmio.h | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio.h b/drivers/gpu/drm/i915/gvt/mmio.h
index 3bc620f56f35..bf40100fc626 100644
--- a/drivers/gpu/drm/i915/gvt/mmio.h
+++ b/drivers/gpu/drm/i915/gvt/mmio.h
@@ -78,13 +78,20 @@ bool intel_gvt_match_device(struct intel_gvt *gvt, unsigned 
long device);
 int intel_gvt_setup_mmio_info(struct intel_gvt *gvt);
 void intel_gvt_clean_mmio_info(struct intel_gvt *gvt);
 
+static inline u32 intel_gvt_mmio_offset(unsigned int offset)
+{
+   return offset;
+}
+
 struct intel_gvt_mmio_info *intel_gvt_find_mmio_info(struct intel_gvt *gvt,
 unsigned int offset);
-#define INTEL_GVT_MMIO_OFFSET(reg) ({ \
-   typeof(reg) __reg = reg; \
-   u32 *offset = (u32 *)&__reg; \
-   *offset; \
-})
+#define INTEL_GVT_MMIO_OFFSET(reg) \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), int), 
intel_gvt_mmio_offset, \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), unsigned int), 
intel_gvt_mmio_offset, \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(reg), i915_reg_t), 
i915_mmio_reg_offset, \
+   (void)(0) \
+)))(reg)
+
 
 int intel_vgpu_init_mmio(struct intel_vgpu *vgpu);
 void intel_vgpu_reset_mmio(struct intel_vgpu *vgpu);
-- 
2.9.0

Re: [PATCH 2/2] arc: axs10x: Fix ARC PGU default clock frequency

[Alexey Brodkin]

Hi Jose,

On Wed, 2017-02-22 at 18:19 +, Jose Abreu wrote:
> Default clock frequency for ARC PGU does not match any
> existing HDMI mode, instead the default value matches a
> DVI mode. Change the clock frequency to 74.25MHz so that
> it matches HDMI mode 1280x720@60Hz
> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Rob Herring 
> Cc: Vineet Gupta 
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arc/boot/dts/axs10x_mb.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi 
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 9d882b1..41cfb29 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -51,7 +51,7 @@
>   pguclk: pguclk {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> - clock-frequency = <7444>;
> + clock-frequency = <7425>;
>   };
>   };

Looks good to me but I have to note that with this change in place
monitors that don't report [correct] EDID won't work just because
if EDID is missing Linux kernel calculates pixel clock on its
own and for 1280x720@60 it gets 74.40 MHz which obviously differs from
yours 74.25 MHz and so arc_pgu_crtc_atomic_check() returns -EINVAL.

But with the fix I just sent, see
http://lists.infradead.org/pipermail/linux-snps-arc/2017-March/002173.html
everything will work again.

And once Vlad's patch for AXS PLLs gets accepted we'll finally get
support of multiple modes on AXS10x boards.

That said...

Acked-by: Alexey Brodkin 

Re: [PATCH 2/2] arc: axs10x: Fix ARC PGU default clock frequency

[Alexey Brodkin]

Hi Jose,

On Wed, 2017-02-22 at 18:19 +, Jose Abreu wrote:
> Default clock frequency for ARC PGU does not match any
> existing HDMI mode, instead the default value matches a
> DVI mode. Change the clock frequency to 74.25MHz so that
> it matches HDMI mode 1280x720@60Hz
> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Rob Herring 
> Cc: Vineet Gupta 
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arc/boot/dts/axs10x_mb.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi 
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 9d882b1..41cfb29 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -51,7 +51,7 @@
>   pguclk: pguclk {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> - clock-frequency = <7444>;
> + clock-frequency = <7425>;
>   };
>   };

Looks good to me but I have to note that with this change in place
monitors that don't report [correct] EDID won't work just because
if EDID is missing Linux kernel calculates pixel clock on its
own and for 1280x720@60 it gets 74.40 MHz which obviously differs from
yours 74.25 MHz and so arc_pgu_crtc_atomic_check() returns -EINVAL.

But with the fix I just sent, see
http://lists.infradead.org/pipermail/linux-snps-arc/2017-March/002173.html
everything will work again.

And once Vlad's patch for AXS PLLs gets accepted we'll finally get
support of multiple modes on AXS10x boards.

That said...

Acked-by: Alexey Brodkin 

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

[Alison Schofield]

On Thu, Mar 02, 2017 at 12:14:40PM +0100, Julia Lawall wrote:
> 
> 
> On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote:
> 
> > On Thu, Mar 2, 2017 at 3:20 PM, Julia Lawall  wrote:
> > >
> > >
> > > On Thu, 2 Mar 2017, Julia Lawall wrote:
> > >
> > >>
> > >>
> > >> On Thu, 2 Mar 2017, simran singhal wrote:
> > >>
> > >> > This patch fixes the following sparse warning:
> > >> > warning: cast to restricted __le16
> > >>
> > >> You commit message should not say just fix X.  What have you done to 
> > >> carry
> > >> out the fix and why is this the correct approach?
> > >
> > > This comment applies to all of the patches in the series.
> > >
> > > julia
> > >
> > The changes and sparse warnings for them seems reasonable to me as
> > after doing the
> > change sparse was not showing error like cast to __le16 or something like 
> > this.
> > Also it compiled perfectly.
> 
> This doesn't mean that it actually works.  The function calls at least may
> have been put there for a reason.  Maysbe you can find other patches that
> relate to this call and see what they do.
> 
> julia

Hi Simran, 

Just following on Julia's feedback and I see you've gotten
a message that this breaks little endian machines.

Good for you for trying to go deeper.  I'd suggest taking this one
at a time and figure out what is going on with one of them.  As Julia
says, with this kind of change, you will have to prove why it is
correct.  (You might not be able to change any of these - I don't know,
but I know you'll learn something!)

Look here - and then pick one to trace through -
https://kernelnewbies.org/EndianIssues

Generally - probably best to test the waters with something of this
type, with a single patch.  Get that nailed, then move onto a patchset,
if you have a pattern.

Heads down & good luck!

alisons

> 
> 
> > >>
> > >> julia
> > >>
> > >> >
> > >> > Signed-off-by: simran singhal 
> > >> > ---
> > >> >  drivers/staging/wlan-ng/prism2sta.c | 51 
> > >> > ++---
> > >> >  1 file changed, 25 insertions(+), 26 deletions(-)
> > >> >
> > >> > diff --git a/drivers/staging/wlan-ng/prism2sta.c 
> > >> > b/drivers/staging/wlan-ng/prism2sta.c
> > >> > index 984804b..82d3a70 100644
> > >> > --- a/drivers/staging/wlan-ng/prism2sta.c
> > >> > +++ b/drivers/staging/wlan-ng/prism2sta.c
> > >> > @@ -372,10 +372,9 @@ static int prism2sta_mlmerequest(struct 
> > >> > wlandevice *wlandev,
> > >> > qualmsg->noise.status =
> > >> > P80211ENUM_msgitem_status_data_ok;
> > >> >
> > >> > -   qualmsg->link.data = 
> > >> > le16_to_cpu(hw->qual.cq_curr_bss);
> > >> > -   qualmsg->level.data =
> > >> > -   le16_to_cpu(hw->qual.asl_curr_bss);
> > >> > -   qualmsg->noise.data = 
> > >> > le16_to_cpu(hw->qual.anl_curr_fc);
> > >> > +   qualmsg->link.data = hw->qual.cq_curr_bss;
> > >> > +   qualmsg->level.data = hw->qual.asl_curr_bss;
> > >> > +   qualmsg->noise.data = hw->qual.anl_curr_fc;
> > >> > qualmsg->txrate.data = hw->txrate;
> > >> >
> > >> > break;
> > >> > @@ -603,10 +602,10 @@ static int prism2sta_getcardinfo(struct 
> > >> > wlandevice *wlandev)
> > >> > }
> > >> >
> > >> > /* get all the nic id fields in host byte order */
> > >> > -   hw->ident_nic.id = le16_to_cpu(hw->ident_nic.id);
> > >> > -   hw->ident_nic.variant = le16_to_cpu(hw->ident_nic.variant);
> > >> > -   hw->ident_nic.major = le16_to_cpu(hw->ident_nic.major);
> > >> > -   hw->ident_nic.minor = le16_to_cpu(hw->ident_nic.minor);
> > >> > +   hw->ident_nic.id = hw->ident_nic.id;
> > >> > +   hw->ident_nic.variant = hw->ident_nic.variant;
> > >> > +   hw->ident_nic.major = hw->ident_nic.major;
> > >> > +   hw->ident_nic.minor = hw->ident_nic.minor;
> > >> >
> > >> > netdev_info(wlandev->netdev, "ident: nic h/w: id=0x%02x 
> > >> > %d.%d.%d\n",
> > >> > hw->ident_nic.id, hw->ident_nic.major,
> > >> > @@ -622,10 +621,10 @@ static int prism2sta_getcardinfo(struct 
> > >> > wlandevice *wlandev)
> > >> > }
> > >> >
> > >> > /* get all the private fw id fields in host byte order */
> > >> > -   hw->ident_pri_fw.id = le16_to_cpu(hw->ident_pri_fw.id);
> > >> > -   hw->ident_pri_fw.variant = le16_to_cpu(hw->ident_pri_fw.variant);
> > >> > -   hw->ident_pri_fw.major = le16_to_cpu(hw->ident_pri_fw.major);
> > >> > -   hw->ident_pri_fw.minor = le16_to_cpu(hw->ident_pri_fw.minor);
> > >> > +   hw->ident_pri_fw.id = hw->ident_pri_fw.id;
> > >> > +   hw->ident_pri_fw.variant = hw->ident_pri_fw.variant;
> > >> > +   hw->ident_pri_fw.major = hw->ident_pri_fw.major;
> > >> > +   hw->ident_pri_fw.minor = hw->ident_pri_fw.minor;
> > >> >
> > >> > netdev_info(wlandev->netdev, "ident: pri f/w: id=0x%02x 
> > >> > %d.%d.%d\n",
> > >> > hw->ident_pri_fw.id, hw->ident_pri_fw.major,
> > 

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

[Alison Schofield]

On Thu, Mar 02, 2017 at 12:14:40PM +0100, Julia Lawall wrote:
> 
> 
> On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote:
> 
> > On Thu, Mar 2, 2017 at 3:20 PM, Julia Lawall  wrote:
> > >
> > >
> > > On Thu, 2 Mar 2017, Julia Lawall wrote:
> > >
> > >>
> > >>
> > >> On Thu, 2 Mar 2017, simran singhal wrote:
> > >>
> > >> > This patch fixes the following sparse warning:
> > >> > warning: cast to restricted __le16
> > >>
> > >> You commit message should not say just fix X.  What have you done to 
> > >> carry
> > >> out the fix and why is this the correct approach?
> > >
> > > This comment applies to all of the patches in the series.
> > >
> > > julia
> > >
> > The changes and sparse warnings for them seems reasonable to me as
> > after doing the
> > change sparse was not showing error like cast to __le16 or something like 
> > this.
> > Also it compiled perfectly.
> 
> This doesn't mean that it actually works.  The function calls at least may
> have been put there for a reason.  Maysbe you can find other patches that
> relate to this call and see what they do.
> 
> julia

Hi Simran, 

Just following on Julia's feedback and I see you've gotten
a message that this breaks little endian machines.

Good for you for trying to go deeper.  I'd suggest taking this one
at a time and figure out what is going on with one of them.  As Julia
says, with this kind of change, you will have to prove why it is
correct.  (You might not be able to change any of these - I don't know,
but I know you'll learn something!)

Look here - and then pick one to trace through -
https://kernelnewbies.org/EndianIssues

Generally - probably best to test the waters with something of this
type, with a single patch.  Get that nailed, then move onto a patchset,
if you have a pattern.

Heads down & good luck!

alisons

> 
> 
> > >>
> > >> julia
> > >>
> > >> >
> > >> > Signed-off-by: simran singhal 
> > >> > ---
> > >> >  drivers/staging/wlan-ng/prism2sta.c | 51 
> > >> > ++---
> > >> >  1 file changed, 25 insertions(+), 26 deletions(-)
> > >> >
> > >> > diff --git a/drivers/staging/wlan-ng/prism2sta.c 
> > >> > b/drivers/staging/wlan-ng/prism2sta.c
> > >> > index 984804b..82d3a70 100644
> > >> > --- a/drivers/staging/wlan-ng/prism2sta.c
> > >> > +++ b/drivers/staging/wlan-ng/prism2sta.c
> > >> > @@ -372,10 +372,9 @@ static int prism2sta_mlmerequest(struct 
> > >> > wlandevice *wlandev,
> > >> > qualmsg->noise.status =
> > >> > P80211ENUM_msgitem_status_data_ok;
> > >> >
> > >> > -   qualmsg->link.data = 
> > >> > le16_to_cpu(hw->qual.cq_curr_bss);
> > >> > -   qualmsg->level.data =
> > >> > -   le16_to_cpu(hw->qual.asl_curr_bss);
> > >> > -   qualmsg->noise.data = 
> > >> > le16_to_cpu(hw->qual.anl_curr_fc);
> > >> > +   qualmsg->link.data = hw->qual.cq_curr_bss;
> > >> > +   qualmsg->level.data = hw->qual.asl_curr_bss;
> > >> > +   qualmsg->noise.data = hw->qual.anl_curr_fc;
> > >> > qualmsg->txrate.data = hw->txrate;
> > >> >
> > >> > break;
> > >> > @@ -603,10 +602,10 @@ static int prism2sta_getcardinfo(struct 
> > >> > wlandevice *wlandev)
> > >> > }
> > >> >
> > >> > /* get all the nic id fields in host byte order */
> > >> > -   hw->ident_nic.id = le16_to_cpu(hw->ident_nic.id);
> > >> > -   hw->ident_nic.variant = le16_to_cpu(hw->ident_nic.variant);
> > >> > -   hw->ident_nic.major = le16_to_cpu(hw->ident_nic.major);
> > >> > -   hw->ident_nic.minor = le16_to_cpu(hw->ident_nic.minor);
> > >> > +   hw->ident_nic.id = hw->ident_nic.id;
> > >> > +   hw->ident_nic.variant = hw->ident_nic.variant;
> > >> > +   hw->ident_nic.major = hw->ident_nic.major;
> > >> > +   hw->ident_nic.minor = hw->ident_nic.minor;
> > >> >
> > >> > netdev_info(wlandev->netdev, "ident: nic h/w: id=0x%02x 
> > >> > %d.%d.%d\n",
> > >> > hw->ident_nic.id, hw->ident_nic.major,
> > >> > @@ -622,10 +621,10 @@ static int prism2sta_getcardinfo(struct 
> > >> > wlandevice *wlandev)
> > >> > }
> > >> >
> > >> > /* get all the private fw id fields in host byte order */
> > >> > -   hw->ident_pri_fw.id = le16_to_cpu(hw->ident_pri_fw.id);
> > >> > -   hw->ident_pri_fw.variant = le16_to_cpu(hw->ident_pri_fw.variant);
> > >> > -   hw->ident_pri_fw.major = le16_to_cpu(hw->ident_pri_fw.major);
> > >> > -   hw->ident_pri_fw.minor = le16_to_cpu(hw->ident_pri_fw.minor);
> > >> > +   hw->ident_pri_fw.id = hw->ident_pri_fw.id;
> > >> > +   hw->ident_pri_fw.variant = hw->ident_pri_fw.variant;
> > >> > +   hw->ident_pri_fw.major = hw->ident_pri_fw.major;
> > >> > +   hw->ident_pri_fw.minor = hw->ident_pri_fw.minor;
> > >> >
> > >> > netdev_info(wlandev->netdev, "ident: pri f/w: id=0x%02x 
> > >> > %d.%d.%d\n",
> > >> > hw->ident_pri_fw.id, hw->ident_pri_fw.major,
> > >> > @@ -648,10 +647,10 @@ static int 

Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates

[Patrick Bellasi]

On 02-Mar 17:09, Vincent Guittot wrote:
> On 2 March 2017 at 16:45, Patrick Bellasi  wrote:
> > The current version of schedutil has some issues related to the management
> > of update flags used by systems with frequency domains spawning multiple 
> > CPUs.
> >
> > Each time a CPU utilisation update is issued by the scheduler a set of flags
> > are configured to define (mainly) which class is asking for a utilisation
> > update. These flags are then used by the frequency selection policy to
> > identify the OPP to choose.
> >
> > In the current implementation, CPU flags are overridden each time the
> > scheduler calls schedutil for an update. Such a behaviour produces issues
> > in these scenarios, where we assume CPU1 and CPU2 share the same frequency
> > domain:
> > a) a RT task which executed on CPU1 can keep the domain at an high frequency
> >for a long period of time, even if there are no longer RT tasks on
> >CPUs in that domain
> 
> Normally this is dropped after a tick.
> Nevertheless, there is an issue if the freq_update_delay_ns is shorter
> than a tick because of sugov RT thread

Indeed, I've noticed that a small FAIR task running on CPU2 is quite
likely to be running at an higher OPP just because on the other CPU of
the same frequency domain (i.e. CPU1) sometimes we have the sugov RT
thread running.

In this case, the RT flag in CPU1 is never cleared when that core is
always idle but for the execution of the sugov thread.

-- 
#include 

Patrick Bellasi

Re: [PATCH 14/20] PCI: hisi: update PCI config space remap function

[Lorenzo Pieralisi]

Hi Gabriele,

On Thu, Mar 02, 2017 at 10:56:16AM +, Gabriele Paoloni wrote:
> Hi Lorenzo
> 
> Many thanks for putting all of this together.
> 
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: 27 February 2017 15:14
> > To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Lorenzo
> > Pieralisi; Bjorn Helgaas; Gabriele Paoloni; Wangzhou (B)
> > Subject: [PATCH 14/20] PCI: hisi: update PCI config space remap
> > function
> > 
> > PCI configuration space should be mapped with a memory region type that
> > generates on the CPU host bus non-posted write transations. Update the
> > driver to use the devm_pci_remap_cfg* interface to make sure the
> > correct
> > memory mappings for PCI configuration space are used.
> > 
> > Signed-off-by: Lorenzo Pieralisi 
> > Cc: Bjorn Helgaas 
> > Cc: Gabriele Paoloni 
> > Cc: Zhou Wang 
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index e3e4fed..8042780 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -294,10 +294,9 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > }
> > 
> > reg = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "rc_dbi");
> > -   pci->dbi_base = devm_ioremap_resource(dev, reg);
> > +   pci->dbi_base = devm_pci_remap_cfg_resource(dev, reg);
> > if (IS_ERR(pci->dbi_base))
> > return PTR_ERR(pci->dbi_base);
> > -
> > platform_set_drvdata(pdev, hisi_pcie);
> > 
> > ret = hisi_add_pcie_port(hisi_pcie, pdev);
> > --
> > 2.10.0
> 
> I think you missed a couple of places where cfg space is ioremapped.
> I have added these and merged with your changes in the patch below:
> 
> Thanks again
> Gab
> 
> -
> From: Lorenzo Pieralisi 
> Date: Tue, 21 Feb 2017 15:24:34 +
> Subject: [PATCH 09/15] PCI: hisi: update PCI config space remap function
> 
> PCI configuration space should be mapped with a memory region type that
> generates on the CPU host bus non-posted write transations. Update the
> driver to use the devm_pci_remap_cfg* interface to make sure the correct
> memory mappings for PCI configuration space are used.
> 
> Signed-off-by: Lorenzo Pieralisi 
> Signed-off-by: Gabriele Paoloni 
> Cc: Bjorn Helgaas 
> Cc: Gabriele Paoloni 
> Cc: Zhou Wang 
> ---
>  drivers/pci/dwc/pcie-hisi.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index e3e4fed..a5b542c 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -99,7 +99,7 @@ static int hisi_pcie_init(struct pci_config_window *cfg)
>   return -ENOMEM;
>   }
>  
> - reg_base = devm_ioremap(dev, res->start, resource_size(res));
> + reg_base = devm_pci_remap_cfgspace(dev, res->start, resource_size(res));
>   if (!reg_base)
>   return -ENOMEM;
>  
> @@ -294,10 +294,9 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>   }
>  
>   reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rc_dbi");
> - pci->dbi_base = devm_ioremap_resource(dev, reg);
> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, reg);
>   if (IS_ERR(pci->dbi_base))
>   return PTR_ERR(pci->dbi_base);
> -
>   platform_set_drvdata(pdev, hisi_pcie);
>  
>   ret = hisi_add_pcie_port(hisi_pcie, pdev);
> @@ -358,7 +357,7 @@ static int hisi_pcie_platform_init(struct 
> pci_config_window *cfg)
>   return -EINVAL;
>   }
>  
> - reg_base = devm_ioremap(dev, res->start, resource_size(res));
> + reg_base = devm_pci_remap_cfgspace(dev, res->start, resource_size(res));
>   if (!reg_base)
>   return -ENOMEM;

I will fold the changes into v2 (and I hope other host controllers
maintainers will follow suit - I do not have enough knowledge of
all host bridges drivers internals to understand what ioremap calls
need patching).

Thanks !
Lorenzo

Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates

[Patrick Bellasi]

On 02-Mar 17:09, Vincent Guittot wrote:
> On 2 March 2017 at 16:45, Patrick Bellasi  wrote:
> > The current version of schedutil has some issues related to the management
> > of update flags used by systems with frequency domains spawning multiple 
> > CPUs.
> >
> > Each time a CPU utilisation update is issued by the scheduler a set of flags
> > are configured to define (mainly) which class is asking for a utilisation
> > update. These flags are then used by the frequency selection policy to
> > identify the OPP to choose.
> >
> > In the current implementation, CPU flags are overridden each time the
> > scheduler calls schedutil for an update. Such a behaviour produces issues
> > in these scenarios, where we assume CPU1 and CPU2 share the same frequency
> > domain:
> > a) a RT task which executed on CPU1 can keep the domain at an high frequency
> >for a long period of time, even if there are no longer RT tasks on
> >CPUs in that domain
> 
> Normally this is dropped after a tick.
> Nevertheless, there is an issue if the freq_update_delay_ns is shorter
> than a tick because of sugov RT thread

Indeed, I've noticed that a small FAIR task running on CPU2 is quite
likely to be running at an higher OPP just because on the other CPU of
the same frequency domain (i.e. CPU1) sometimes we have the sugov RT
thread running.

In this case, the RT flag in CPU1 is never cleared when that core is
always idle but for the execution of the sugov thread.

-- 
#include 

Patrick Bellasi

Re: [PATCH 14/20] PCI: hisi: update PCI config space remap function

[Lorenzo Pieralisi]

Hi Gabriele,

On Thu, Mar 02, 2017 at 10:56:16AM +, Gabriele Paoloni wrote:
> Hi Lorenzo
> 
> Many thanks for putting all of this together.
> 
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: 27 February 2017 15:14
> > To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Lorenzo
> > Pieralisi; Bjorn Helgaas; Gabriele Paoloni; Wangzhou (B)
> > Subject: [PATCH 14/20] PCI: hisi: update PCI config space remap
> > function
> > 
> > PCI configuration space should be mapped with a memory region type that
> > generates on the CPU host bus non-posted write transations. Update the
> > driver to use the devm_pci_remap_cfg* interface to make sure the
> > correct
> > memory mappings for PCI configuration space are used.
> > 
> > Signed-off-by: Lorenzo Pieralisi 
> > Cc: Bjorn Helgaas 
> > Cc: Gabriele Paoloni 
> > Cc: Zhou Wang 
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index e3e4fed..8042780 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -294,10 +294,9 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > }
> > 
> > reg = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "rc_dbi");
> > -   pci->dbi_base = devm_ioremap_resource(dev, reg);
> > +   pci->dbi_base = devm_pci_remap_cfg_resource(dev, reg);
> > if (IS_ERR(pci->dbi_base))
> > return PTR_ERR(pci->dbi_base);
> > -
> > platform_set_drvdata(pdev, hisi_pcie);
> > 
> > ret = hisi_add_pcie_port(hisi_pcie, pdev);
> > --
> > 2.10.0
> 
> I think you missed a couple of places where cfg space is ioremapped.
> I have added these and merged with your changes in the patch below:
> 
> Thanks again
> Gab
> 
> -
> From: Lorenzo Pieralisi 
> Date: Tue, 21 Feb 2017 15:24:34 +
> Subject: [PATCH 09/15] PCI: hisi: update PCI config space remap function
> 
> PCI configuration space should be mapped with a memory region type that
> generates on the CPU host bus non-posted write transations. Update the
> driver to use the devm_pci_remap_cfg* interface to make sure the correct
> memory mappings for PCI configuration space are used.
> 
> Signed-off-by: Lorenzo Pieralisi 
> Signed-off-by: Gabriele Paoloni 
> Cc: Bjorn Helgaas 
> Cc: Gabriele Paoloni 
> Cc: Zhou Wang 
> ---
>  drivers/pci/dwc/pcie-hisi.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index e3e4fed..a5b542c 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -99,7 +99,7 @@ static int hisi_pcie_init(struct pci_config_window *cfg)
>   return -ENOMEM;
>   }
>  
> - reg_base = devm_ioremap(dev, res->start, resource_size(res));
> + reg_base = devm_pci_remap_cfgspace(dev, res->start, resource_size(res));
>   if (!reg_base)
>   return -ENOMEM;
>  
> @@ -294,10 +294,9 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>   }
>  
>   reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rc_dbi");
> - pci->dbi_base = devm_ioremap_resource(dev, reg);
> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, reg);
>   if (IS_ERR(pci->dbi_base))
>   return PTR_ERR(pci->dbi_base);
> -
>   platform_set_drvdata(pdev, hisi_pcie);
>  
>   ret = hisi_add_pcie_port(hisi_pcie, pdev);
> @@ -358,7 +357,7 @@ static int hisi_pcie_platform_init(struct 
> pci_config_window *cfg)
>   return -EINVAL;
>   }
>  
> - reg_base = devm_ioremap(dev, res->start, resource_size(res));
> + reg_base = devm_pci_remap_cfgspace(dev, res->start, resource_size(res));
>   if (!reg_base)
>   return -ENOMEM;

I will fold the changes into v2 (and I hope other host controllers
maintainers will follow suit - I do not have enough knowledge of
all host bridges drivers internals to understand what ioremap calls
need patching).

Thanks !
Lorenzo

[PATCH v9 07/11] btrfs_tree.h: fix include from userland

[Nicolas Dichtel]

This patch prepares the uapi export by fixing the following errors:

.../linux/btrfs_tree.h:283:2: error: #error "UUID items require BTRFS_UUID_SIZE 
== 16!"
 #error "UUID items require BTRFS_UUID_SIZE == 16!"

.../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not in 
a function)
  __u8 uuid[BTRFS_UUID_SIZE];
^
.../linux/btrfs_tree.h:796:16: error: ‘BTRFS_DEV_STAT_VALUES_MAX’ undeclared 
here (not in a function)
  __le64 values[BTRFS_DEV_STAT_VALUES_MAX];

Signed-off-by: Nicolas Dichtel 
---
 include/uapi/linux/btrfs_tree.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index 6a261cb52d95..6a754ada59af 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -2,6 +2,7 @@
 #define _BTRFS_CTREE_H_
 
 #include 
+#include 
 
 /*
  * This header contains the structure definitions and constants used
-- 
2.8.1

[PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

[Alexey Brodkin]

Since we cannot always generate exactly requested pixel clock
there's not much sense in checking requested_clock == clk_round_rate().
In that case for quite some modes we'll be getting -EINVAL and no video
output at all.

But given there's some tolerance to real pixel clock in TVs/monitors
we may still give it a try with the clock as close to requested one as
PLL on the board may generate. So we just do a fixup to what current
board may provide.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jose Abreu 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..3f2823c1efc3 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
+static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = >adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
 
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
+   adjusted_mode->clock =
+   clk_round_rate(arcpgu->clk, mode->clock * 1000) / 1000;
 
-   return 0;
+   return true;
 }
 
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -165,8 +163,8 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
+   .mode_fixup = arc_pgu_crtc_mode_fixup,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
-- 
2.7.4

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

[Rafael J. Wysocki]

On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> If the current P-state selection algorithm is set to "performance"
> in intel_pstate_set_policy(), the limits may be initialized from
> scratch, but only if no_turbo is not set and the maximum frequency
> allowed for the given CPU (i.e. the policy object representing it)
> is at least equal to the max frequency supported by the CPU.  In all
> of the other cases, the limits will not be updated.
>
> For example, the following can happen:
>
>  # cat intel_pstate/status
>  active
>  # echo performance > cpufreq/policy0/scaling_governor
>  # cat intel_pstate/min_perf_pct
>  100
>  # echo 94 > intel_pstate/min_perf_pct
>  # cat intel_pstate/min_perf_pct
>  100
>  # cat cpufreq/policy0/scaling_max_freq
>  310
>  echo 300 > cpufreq/policy0/scaling_max_freq
>  # cat intel_pstate/min_perf_pct
>  94
>  # echo 95 > intel_pstate/min_perf_pct
>  # cat intel_pstate/min_perf_pct
>  95
>
> That is confusing for two reasons.  First, the initial attempt to
> change min_perf_pct to 94 seems to have no effect, even though
> setting the global limits should always work.  Second, after
> changing scaling_max_freq for policy0 the global min_perf_pct
> attribute shows 94, even though it should have not been affected
> by that operation in principle.
>
> Moreover, the final attempt to change min_perf_pct to 95 worked
> as expected, because scaling_max_freq for the only policy with
> scaling_governor equal to "performance" was different from the
> maximum at that time.
>
> To make all that confusion go away, modify intel_pstate_set_policy()
> so that it doesn't reinitialize the limits at all.
>
> At the same time, change intel_pstate_set_performance_limits() to
> set min_sysfs_pct to 100 in the "performance" limits set so that
> switching the P-state selection algorithm to "performance" causes
> intel_pstate/min_perf_pct in sysfs to go to 100 (or whatever value
> min_sysfs_pct in the "performance" limits is set to later).
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>
> -> v2: No changes
>
> ---
>  drivers/cpufreq/intel_pstate.c |   10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -382,6 +382,7 @@ static void intel_pstate_set_performance
> intel_pstate_init_limits(limits);
> limits->min_perf_pct = 100;
> limits->min_perf = int_ext_tofp(1);
> +   limits->min_sysfs_pct = 100;

This change breaks the per-CPU limits, so the patch is not correct.

Withdrawing.

Thanks,
Rafael

[PATCH v9 01/11] h8300: put bitsperlong.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/h8300/include/asm/bitsperlong.h  | 14 --
 arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++
 2 files changed, 14 insertions(+), 14 deletions(-)
 delete mode 100644 arch/h8300/include/asm/bitsperlong.h
 create mode 100644 arch/h8300/include/uapi/asm/bitsperlong.h

diff --git a/arch/h8300/include/asm/bitsperlong.h 
b/arch/h8300/include/asm/bitsperlong.h
deleted file mode 100644
index e140e46729ac..
--- a/arch/h8300/include/asm/bitsperlong.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __ASM_H8300_BITS_PER_LONG
-#define __ASM_H8300_BITS_PER_LONG
-
-#include 
-
-#if !defined(__ASSEMBLY__)
-/* h8300-unknown-linux required long */
-#define __kernel_size_t __kernel_size_t
-typedef unsigned long  __kernel_size_t;
-typedef long   __kernel_ssize_t;
-typedef long   __kernel_ptrdiff_t;
-#endif
-
-#endif /* __ASM_H8300_BITS_PER_LONG */
diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
b/arch/h8300/include/uapi/asm/bitsperlong.h
new file mode 100644
index ..e56cf72369b6
--- /dev/null
+++ b/arch/h8300/include/uapi/asm/bitsperlong.h
@@ -0,0 +1,14 @@
+#ifndef _UAPI_ASM_H8300_BITS_PER_LONG
+#define _UAPI_ASM_H8300_BITS_PER_LONG
+
+#include 
+
+#if !defined(__ASSEMBLY__)
+/* h8300-unknown-linux required long */
+#define __kernel_size_t __kernel_size_t
+typedef unsigned long  __kernel_size_t;
+typedef long   __kernel_ssize_t;
+typedef long   __kernel_ptrdiff_t;
+#endif
+
+#endif /* _UAPI_ASM_H8300_BITS_PER_LONG */
-- 
2.8.1

[PATCH v9 07/11] btrfs_tree.h: fix include from userland

[Nicolas Dichtel]

This patch prepares the uapi export by fixing the following errors:

.../linux/btrfs_tree.h:283:2: error: #error "UUID items require BTRFS_UUID_SIZE 
== 16!"
 #error "UUID items require BTRFS_UUID_SIZE == 16!"

.../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not in 
a function)
  __u8 uuid[BTRFS_UUID_SIZE];
^
.../linux/btrfs_tree.h:796:16: error: ‘BTRFS_DEV_STAT_VALUES_MAX’ undeclared 
here (not in a function)
  __le64 values[BTRFS_DEV_STAT_VALUES_MAX];

Signed-off-by: Nicolas Dichtel 
---
 include/uapi/linux/btrfs_tree.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index 6a261cb52d95..6a754ada59af 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -2,6 +2,7 @@
 #define _BTRFS_CTREE_H_
 
 #include 
+#include 
 
 /*
  * This header contains the structure definitions and constants used
-- 
2.8.1

[PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

[Alexey Brodkin]

Since we cannot always generate exactly requested pixel clock
there's not much sense in checking requested_clock == clk_round_rate().
In that case for quite some modes we'll be getting -EINVAL and no video
output at all.

But given there's some tolerance to real pixel clock in TVs/monitors
we may still give it a try with the clock as close to requested one as
PLL on the board may generate. So we just do a fixup to what current
board may provide.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jose Abreu 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..3f2823c1efc3 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
+static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = >adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
 
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
+   adjusted_mode->clock =
+   clk_round_rate(arcpgu->clk, mode->clock * 1000) / 1000;
 
-   return 0;
+   return true;
 }
 
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -165,8 +163,8 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
+   .mode_fixup = arc_pgu_crtc_mode_fixup,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
-- 
2.7.4

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

[Rafael J. Wysocki]

On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> If the current P-state selection algorithm is set to "performance"
> in intel_pstate_set_policy(), the limits may be initialized from
> scratch, but only if no_turbo is not set and the maximum frequency
> allowed for the given CPU (i.e. the policy object representing it)
> is at least equal to the max frequency supported by the CPU.  In all
> of the other cases, the limits will not be updated.
>
> For example, the following can happen:
>
>  # cat intel_pstate/status
>  active
>  # echo performance > cpufreq/policy0/scaling_governor
>  # cat intel_pstate/min_perf_pct
>  100
>  # echo 94 > intel_pstate/min_perf_pct
>  # cat intel_pstate/min_perf_pct
>  100
>  # cat cpufreq/policy0/scaling_max_freq
>  310
>  echo 300 > cpufreq/policy0/scaling_max_freq
>  # cat intel_pstate/min_perf_pct
>  94
>  # echo 95 > intel_pstate/min_perf_pct
>  # cat intel_pstate/min_perf_pct
>  95
>
> That is confusing for two reasons.  First, the initial attempt to
> change min_perf_pct to 94 seems to have no effect, even though
> setting the global limits should always work.  Second, after
> changing scaling_max_freq for policy0 the global min_perf_pct
> attribute shows 94, even though it should have not been affected
> by that operation in principle.
>
> Moreover, the final attempt to change min_perf_pct to 95 worked
> as expected, because scaling_max_freq for the only policy with
> scaling_governor equal to "performance" was different from the
> maximum at that time.
>
> To make all that confusion go away, modify intel_pstate_set_policy()
> so that it doesn't reinitialize the limits at all.
>
> At the same time, change intel_pstate_set_performance_limits() to
> set min_sysfs_pct to 100 in the "performance" limits set so that
> switching the P-state selection algorithm to "performance" causes
> intel_pstate/min_perf_pct in sysfs to go to 100 (or whatever value
> min_sysfs_pct in the "performance" limits is set to later).
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>
> -> v2: No changes
>
> ---
>  drivers/cpufreq/intel_pstate.c |   10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -382,6 +382,7 @@ static void intel_pstate_set_performance
> intel_pstate_init_limits(limits);
> limits->min_perf_pct = 100;
> limits->min_perf = int_ext_tofp(1);
> +   limits->min_sysfs_pct = 100;

This change breaks the per-CPU limits, so the patch is not correct.

Withdrawing.

Thanks,
Rafael

[PATCH v9 01/11] h8300: put bitsperlong.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/h8300/include/asm/bitsperlong.h  | 14 --
 arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++
 2 files changed, 14 insertions(+), 14 deletions(-)
 delete mode 100644 arch/h8300/include/asm/bitsperlong.h
 create mode 100644 arch/h8300/include/uapi/asm/bitsperlong.h

diff --git a/arch/h8300/include/asm/bitsperlong.h 
b/arch/h8300/include/asm/bitsperlong.h
deleted file mode 100644
index e140e46729ac..
--- a/arch/h8300/include/asm/bitsperlong.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __ASM_H8300_BITS_PER_LONG
-#define __ASM_H8300_BITS_PER_LONG
-
-#include 
-
-#if !defined(__ASSEMBLY__)
-/* h8300-unknown-linux required long */
-#define __kernel_size_t __kernel_size_t
-typedef unsigned long  __kernel_size_t;
-typedef long   __kernel_ssize_t;
-typedef long   __kernel_ptrdiff_t;
-#endif
-
-#endif /* __ASM_H8300_BITS_PER_LONG */
diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
b/arch/h8300/include/uapi/asm/bitsperlong.h
new file mode 100644
index ..e56cf72369b6
--- /dev/null
+++ b/arch/h8300/include/uapi/asm/bitsperlong.h
@@ -0,0 +1,14 @@
+#ifndef _UAPI_ASM_H8300_BITS_PER_LONG
+#define _UAPI_ASM_H8300_BITS_PER_LONG
+
+#include 
+
+#if !defined(__ASSEMBLY__)
+/* h8300-unknown-linux required long */
+#define __kernel_size_t __kernel_size_t
+typedef unsigned long  __kernel_size_t;
+typedef long   __kernel_ssize_t;
+typedef long   __kernel_ptrdiff_t;
+#endif
+
+#endif /* _UAPI_ASM_H8300_BITS_PER_LONG */
-- 
2.8.1

[PATCH v9 00/11] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Patches #1 and #2 are just cleanup: some exported headers were still under
a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was
not under an uapi directory.
After these three patches, all exported headers are under an uapi directory:
path #4 stops searching files in non uapi directories.
The patch #5 was spotted by code review: there is no in-tree user of this
functionality.
Patch #6 fixes some warnings/errors reported by 0-day tests.
Patch #7 to #9 fix some errors when the corresponding files are included by
userland.
Patches #10 and #11 remove the need to list explicitly headers. Now all files
under an uapi directory are exported.

This series has been tested with a 'make headers_install' on x86 and a
'make headers_install_all'. I've checked the result of both commands.

This patch is built against linus tree. If I must rebase it against the kbuild
tree, just tell me.
Michal, is this series going through your tree?

v8 -> v9:
  - rebase on top of linus tree
  - patch #8: add include/uapi/linux/crypto.h

v7 -> v8:
  - rebase on top of linus tree
  - add patch #7, #8 and #9

v6 -> v7:
  - rebase on top of linus tree
  - patch #7: remove autogenerated files from the list in the commit log

v5 -> v6:
  - patch #6: remove change of include/uapi/linux/media.h
  - patch #7: fix hdr export when 'make O=' is used (look for genhdr files in
  the right directory)
  - patch #8: fix 'make headers_check'

v4 -> v5:
  - patch #3: get back to v3 (don't export msr-index.h)
  - patch #6: new in this version
  - patch #7: fix compilation by introducing header-n

v3 -> v4:
 - first patch has been included
 - patch #4: get back to v2 and remove arch/x86/include/asm/msr-index.h

v2 -> v3:
 - patch #1: remove arch/arm/include/asm/types.h
 - patch #2: remove arch/h8300/include/asm/bitsperlong.h
 - patch #3: remove arch/nios2/include/uapi/asm/setup.h
 - patch #4: don't export msr-index.h
 - patch #5: fix a typo: s/unput-files3-name/input-files3-name
 - patch #6: no change
 - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y
 - add patch #8

v1 -> v2:
 - add patch #1 to #6
 - patch #7: remove use of header-y

Comments are welcomed,
Nicolas

[PATCH v9 00/11] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Patches #1 and #2 are just cleanup: some exported headers were still under
a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was
not under an uapi directory.
After these three patches, all exported headers are under an uapi directory:
path #4 stops searching files in non uapi directories.
The patch #5 was spotted by code review: there is no in-tree user of this
functionality.
Patch #6 fixes some warnings/errors reported by 0-day tests.
Patch #7 to #9 fix some errors when the corresponding files are included by
userland.
Patches #10 and #11 remove the need to list explicitly headers. Now all files
under an uapi directory are exported.

This series has been tested with a 'make headers_install' on x86 and a
'make headers_install_all'. I've checked the result of both commands.

This patch is built against linus tree. If I must rebase it against the kbuild
tree, just tell me.
Michal, is this series going through your tree?

v8 -> v9:
  - rebase on top of linus tree
  - patch #8: add include/uapi/linux/crypto.h

v7 -> v8:
  - rebase on top of linus tree
  - add patch #7, #8 and #9

v6 -> v7:
  - rebase on top of linus tree
  - patch #7: remove autogenerated files from the list in the commit log

v5 -> v6:
  - patch #6: remove change of include/uapi/linux/media.h
  - patch #7: fix hdr export when 'make O=' is used (look for genhdr files in
  the right directory)
  - patch #8: fix 'make headers_check'

v4 -> v5:
  - patch #3: get back to v3 (don't export msr-index.h)
  - patch #6: new in this version
  - patch #7: fix compilation by introducing header-n

v3 -> v4:
 - first patch has been included
 - patch #4: get back to v2 and remove arch/x86/include/asm/msr-index.h

v2 -> v3:
 - patch #1: remove arch/arm/include/asm/types.h
 - patch #2: remove arch/h8300/include/asm/bitsperlong.h
 - patch #3: remove arch/nios2/include/uapi/asm/setup.h
 - patch #4: don't export msr-index.h
 - patch #5: fix a typo: s/unput-files3-name/input-files3-name
 - patch #6: no change
 - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y
 - add patch #8

v1 -> v2:
 - add patch #1 to #6
 - patch #7: remove use of header-y

Comments are welcomed,
Nicolas

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

[Michal Hocko]

On Thu 02-03-17 09:23:15, Brian Foster wrote:
> On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote:
> > On Thu 02-03-17 08:41:58, Brian Foster wrote:
> > > On Thu, Mar 02, 2017 at 02:27:55PM +0100, Michal Hocko wrote:
> > [...]
> > > > I see your argument about being in sync with other kmem helpers but
> > > > those are bit different because regular page/slab allocators allow never
> > > > fail semantic (even though this is mostly ignored by those helpers which
> > > > implement their own retries but that is a different topic).
> > > > 
> > > 
> > > ... but what I'm trying to understand here is whether this failure
> > > scenario is specific to vmalloc() or whether the other kmem_*()
> > > functions are susceptible to the same problem. For example, suppose we
> > > replaced this kmem_zalloc_greedy() call with a kmem_zalloc(PAGE_SIZE,
> > > KM_SLEEP) call. Could we hit the same problem if the process is killed?
> > 
> > Well, kmem_zalloc uses kmalloc which can also fail when we are out of
> > memory but in that case we can expect the OOM killer releasing some
> > memory which would allow us to make a forward progress on the next
> > retry. So essentially retrying around kmalloc is much more safe in this
> > regard. Failing vmalloc might be permanent because there is no vmalloc
> > space to allocate from or much more likely due to already mentioned
> > patch. So vmalloc is different, really.
> 
> Right.. that's why I'm asking. So it's technically possible but highly
> unlikely due to the different failure characteristics. That seems
> reasonable to me, then. 
> 
> To be clear, do we understand what causes the vzalloc() failure to be
> effectively permanent in this specific reproducer? I know you mention
> above that we could be out of vmalloc space, but that doesn't clarify
> whether there are other potential failure paths or then what this has to
> do with the fact that the process was killed. Does the pending signal
> cause the subsequent failures or are you saying that there is some other
> root cause of the failure, this process would effectively be spinning
> here anyways, and we're just noticing it because it's trying to exit?

In this particular case it is fatal_signal_pending that causes the
permanent failure. This check has been added to prevent from complete
memory reserves depletion on OOM when a killed task has a free ticket to
reserves and vmalloc requests can be really large. In this case there
was no OOM killer going on but fsstress has SIGKILL pending for other
reason. Most probably as a result of the group_exit when all threads
are killed (see zap_process). I could have turn fatal_signal_pending
into tsk_is_oom_victim which would be less likely to hit but in
principle fatal_signal_pending should be better because we do want to
bail out when the process is existing as soon as possible.

What I really wanted to say is that there are other possible permanent
failure paths in vmalloc AFAICS. They are much less probable but they
still exist.

Does that make more sense now?
-- 
Michal Hocko
SUSE Labs

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

[Michal Hocko]

On Thu 02-03-17 09:23:15, Brian Foster wrote:
> On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote:
> > On Thu 02-03-17 08:41:58, Brian Foster wrote:
> > > On Thu, Mar 02, 2017 at 02:27:55PM +0100, Michal Hocko wrote:
> > [...]
> > > > I see your argument about being in sync with other kmem helpers but
> > > > those are bit different because regular page/slab allocators allow never
> > > > fail semantic (even though this is mostly ignored by those helpers which
> > > > implement their own retries but that is a different topic).
> > > > 
> > > 
> > > ... but what I'm trying to understand here is whether this failure
> > > scenario is specific to vmalloc() or whether the other kmem_*()
> > > functions are susceptible to the same problem. For example, suppose we
> > > replaced this kmem_zalloc_greedy() call with a kmem_zalloc(PAGE_SIZE,
> > > KM_SLEEP) call. Could we hit the same problem if the process is killed?
> > 
> > Well, kmem_zalloc uses kmalloc which can also fail when we are out of
> > memory but in that case we can expect the OOM killer releasing some
> > memory which would allow us to make a forward progress on the next
> > retry. So essentially retrying around kmalloc is much more safe in this
> > regard. Failing vmalloc might be permanent because there is no vmalloc
> > space to allocate from or much more likely due to already mentioned
> > patch. So vmalloc is different, really.
> 
> Right.. that's why I'm asking. So it's technically possible but highly
> unlikely due to the different failure characteristics. That seems
> reasonable to me, then. 
> 
> To be clear, do we understand what causes the vzalloc() failure to be
> effectively permanent in this specific reproducer? I know you mention
> above that we could be out of vmalloc space, but that doesn't clarify
> whether there are other potential failure paths or then what this has to
> do with the fact that the process was killed. Does the pending signal
> cause the subsequent failures or are you saying that there is some other
> root cause of the failure, this process would effectively be spinning
> here anyways, and we're just noticing it because it's trying to exit?

In this particular case it is fatal_signal_pending that causes the
permanent failure. This check has been added to prevent from complete
memory reserves depletion on OOM when a killed task has a free ticket to
reserves and vmalloc requests can be really large. In this case there
was no OOM killer going on but fsstress has SIGKILL pending for other
reason. Most probably as a result of the group_exit when all threads
are killed (see zap_process). I could have turn fatal_signal_pending
into tsk_is_oom_victim which would be less likely to hit but in
principle fatal_signal_pending should be better because we do want to
bail out when the process is existing as soon as possible.

What I really wanted to say is that there are other possible permanent
failure paths in vmalloc AFAICS. They are much less probable but they
still exist.

Does that make more sense now?
-- 
Michal Hocko
SUSE Labs

[PATCH v9 04/11] Makefile.headersinst: cleanup input files

[Nicolas Dichtel]

After the last four patches, all exported headers are under uapi/, thus
input-files2 are not needed anymore.
The side effect is that input-files1-name is exactly header-y.

Note also that input-files3-name is genhdr-y.

Signed-off-by: Nicolas Dichtel 
---
 scripts/Makefile.headersinst | 34 +++---
 1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 1106d6ca3a38..3e20d03432d2 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -40,31 +40,20 @@ wrapper-files := $(filter $(header-y), $(generic-y))
 srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
 
-oldsrcdir := $(srctree)/$(subst /uapi,,$(obj))
-
 # all headers files for this dir
 header-y  := $(filter-out $(generic-y), $(header-y))
 all-files := $(header-y) $(genhdr-y) $(wrapper-files)
 output-files  := $(addprefix $(installdir)/, $(all-files))
 
-input-files1  := $(foreach hdr, $(header-y), \
-  $(if $(wildcard $(srcdir)/$(hdr)), \
-   $(wildcard $(srcdir)/$(hdr))) \
-  )
-input-files1-name := $(notdir $(input-files1))
-input-files2  := $(foreach hdr, $(header-y), \
-  $(if  $(wildcard $(srcdir)/$(hdr)),, \
-   $(if $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(error Missing UAPI file $(srcdir)/$(hdr))) \
-  ))
-input-files2-name := $(notdir $(input-files2))
-input-files3  := $(foreach hdr, $(genhdr-y), \
-  $(if $(wildcard $(gendir)/$(hdr)), \
-   $(wildcard $(gendir)/$(hdr)), \
-   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
-  ))
-input-files3-name := $(notdir $(input-files3))
+# Check that all expected files exist
+$(foreach hdr, $(header-y), \
+  $(if $(wildcard $(srcdir)/$(hdr)),, \
+   $(error Missing UAPI file $(srcdir)/$(hdr)) \
+   ))
+$(foreach hdr, $(genhdr-y), \
+  $(if $(wildcard $(gendir)/$(hdr)),, \
+   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
+  ))
 
 # Work out what needs to be removed
 oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h))
@@ -78,9 +67,8 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@))
 quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
 file$(if $(word 2, $(all-files)),s))
   cmd_install = \
-$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(input-files1-name); \
-$(CONFIG_SHELL) $< $(installdir) $(oldsrcdir) $(input-files2-name); \
-$(CONFIG_SHELL) $< $(installdir) $(gendir) $(input-files3-name); \
+$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(header-y); \
+$(CONFIG_SHELL) $< $(installdir) $(gendir) $(genhdr-y); \
 for F in $(wrapper-files); do   \
 echo "\#include " > $(installdir)/$$F;\
 done;   \
-- 
2.8.1

[PATCH v9 04/11] Makefile.headersinst: cleanup input files

[Nicolas Dichtel]

After the last four patches, all exported headers are under uapi/, thus
input-files2 are not needed anymore.
The side effect is that input-files1-name is exactly header-y.

Note also that input-files3-name is genhdr-y.

Signed-off-by: Nicolas Dichtel 
---
 scripts/Makefile.headersinst | 34 +++---
 1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 1106d6ca3a38..3e20d03432d2 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -40,31 +40,20 @@ wrapper-files := $(filter $(header-y), $(generic-y))
 srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
 
-oldsrcdir := $(srctree)/$(subst /uapi,,$(obj))
-
 # all headers files for this dir
 header-y  := $(filter-out $(generic-y), $(header-y))
 all-files := $(header-y) $(genhdr-y) $(wrapper-files)
 output-files  := $(addprefix $(installdir)/, $(all-files))
 
-input-files1  := $(foreach hdr, $(header-y), \
-  $(if $(wildcard $(srcdir)/$(hdr)), \
-   $(wildcard $(srcdir)/$(hdr))) \
-  )
-input-files1-name := $(notdir $(input-files1))
-input-files2  := $(foreach hdr, $(header-y), \
-  $(if  $(wildcard $(srcdir)/$(hdr)),, \
-   $(if $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(error Missing UAPI file $(srcdir)/$(hdr))) \
-  ))
-input-files2-name := $(notdir $(input-files2))
-input-files3  := $(foreach hdr, $(genhdr-y), \
-  $(if $(wildcard $(gendir)/$(hdr)), \
-   $(wildcard $(gendir)/$(hdr)), \
-   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
-  ))
-input-files3-name := $(notdir $(input-files3))
+# Check that all expected files exist
+$(foreach hdr, $(header-y), \
+  $(if $(wildcard $(srcdir)/$(hdr)),, \
+   $(error Missing UAPI file $(srcdir)/$(hdr)) \
+   ))
+$(foreach hdr, $(genhdr-y), \
+  $(if $(wildcard $(gendir)/$(hdr)),, \
+   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
+  ))
 
 # Work out what needs to be removed
 oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h))
@@ -78,9 +67,8 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@))
 quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
 file$(if $(word 2, $(all-files)),s))
   cmd_install = \
-$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(input-files1-name); \
-$(CONFIG_SHELL) $< $(installdir) $(oldsrcdir) $(input-files2-name); \
-$(CONFIG_SHELL) $< $(installdir) $(gendir) $(input-files3-name); \
+$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(header-y); \
+$(CONFIG_SHELL) $< $(installdir) $(gendir) $(genhdr-y); \
 for F in $(wrapper-files); do   \
 echo "\#include " > $(installdir)/$$F;\
 done;   \
-- 
2.8.1

Re: [RFC 04/11] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

[Anshuman Khandual]

On 03/02/2017 12:09 PM, Minchan Kim wrote:
> If the page is mapped and rescue in ttuo, page_mapcount(page) == 0 cannot

Nit: "ttuo" is very cryptic. Please expand it.

> be true so page_mapcount check in ttu is enough to return SWAP_SUCCESS.
> IOW, SWAP_MLOCK check is redundant so remove it.

Right, page_mapcount(page) should be enough to tell whether swapping
out happened successfully or the page is still mapped in some page
table.

> 
> Signed-off-by: Minchan Kim 
> ---
>  mm/rmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 3a14013..0a48958 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1523,7 +1523,7 @@ int try_to_unmap(struct page *page, enum ttu_flags 
> flags)
>   else
>   ret = rmap_walk(page, );
>  
> - if (ret != SWAP_MLOCK && !page_mapcount(page))
> + if (!page_mapcount(page))
>   ret = SWAP_SUCCESS;
>   return ret;
>  }
> 

Re: [RFC 04/11] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

[Anshuman Khandual]

On 03/02/2017 12:09 PM, Minchan Kim wrote:
> If the page is mapped and rescue in ttuo, page_mapcount(page) == 0 cannot

Nit: "ttuo" is very cryptic. Please expand it.

> be true so page_mapcount check in ttu is enough to return SWAP_SUCCESS.
> IOW, SWAP_MLOCK check is redundant so remove it.

Right, page_mapcount(page) should be enough to tell whether swapping
out happened successfully or the page is still mapped in some page
table.

> 
> Signed-off-by: Minchan Kim 
> ---
>  mm/rmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 3a14013..0a48958 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1523,7 +1523,7 @@ int try_to_unmap(struct page *page, enum ttu_flags 
> flags)
>   else
>   ret = rmap_walk(page, );
>  
> - if (ret != SWAP_MLOCK && !page_mapcount(page))
> + if (!page_mapcount(page))
>   ret = SWAP_SUCCESS;
>   return ret;
>  }
> 

[PATCH v9 11/11] uapi: export all arch specifics directories

[Nicolas Dichtel]

This patch removes the need of subdir-y. Now all files/directories under
arch//include/uapi/ are exported.

The only change for userland is the layout of the command 'make
headers_install_all': directories asm- are replaced by arch-/.
Those new directories contains all files/directories of the specified arch.

Note that only cris and tile have more directories than only asm:
 - arch-v[10|32] for cris;
 - arch for tile.

Signed-off-by: Nicolas Dichtel 
---
 Documentation/kbuild/makefiles.txt | 15 +--
 Makefile   |  6 +++---
 arch/cris/include/uapi/asm/Kbuild  |  3 ---
 arch/tile/include/uapi/asm/Kbuild  |  2 --
 scripts/Makefile.headersinst   |  3 +--
 5 files changed, 5 insertions(+), 24 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 91ffb391ed54..223b33d5195a 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -49,7 +49,6 @@ This document describes the Linux kernel Makefiles.
--- 7.3 generic-y
--- 7.4 generated-y
--- 7.5 mandatory-y
-   --- 7.6 subdir-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1265,7 +1264,7 @@ The pre-processing does:
 - drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
 
 All headers under include/uapi/, include/generated/uapi/,
-arch//include/uapi/asm/ and arch//include/generated/uapi/asm/
+arch//include/uapi/ and arch//include/generated/uapi/
 are exported.
 
 A Kbuild file may be defined under arch//include/uapi/asm/ and
@@ -1338,18 +1337,6 @@ See subsequent chapter for the syntax of the Kbuild file.
The convention is to list one subdir per line and
preferably in alphabetic order.
 
-   --- 7.6 subdir-y
-
-   subdir-y may be used to specify a subdirectory to be exported.
-
-   Example:
-   #arch/cris/include/uapi/asm/Kbuild
-   subdir-y += ../arch-v10/arch/
-   subdir-y += ../arch-v32/arch/
-
-   The convention is to list one subdir per line and
-   preferably in alphabetic order.
-
 === 8 Kbuild Variables
 
 The top Makefile exports the following variables:
diff --git a/Makefile b/Makefile
index 4cb6b0a1152b..e9ac52330215 100644
--- a/Makefile
+++ b/Makefile
@@ -1128,7 +1128,7 @@ firmware_install:
 export INSTALL_HDR_PATH = $(objtree)/usr
 
 # If we do an all arch process set dst to asm-$(hdr-arch)
-hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
+hdr-dst = $(if $(KBUILD_HEADERS), dst=include/arch-$(hdr-arch), dst=include)
 
 PHONY += archheaders
 archheaders:
@@ -1149,7 +1149,7 @@ headers_install: __headers
$(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \
  $(error Headers not exportable for the $(SRCARCH) architecture))
$(Q)$(MAKE) $(hdr-inst)=include/uapi
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst)
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi $(hdr-dst)
 
 PHONY += headers_check_all
 headers_check_all: headers_install_all
@@ -1158,7 +1158,7 @@ headers_check_all: headers_install_all
 PHONY += headers_check
 headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) 
HDRCHECK=1
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/ $(hdr-dst) 
HDRCHECK=1
 
 # ---
 # Kernel selftest
diff --git a/arch/cris/include/uapi/asm/Kbuild 
b/arch/cris/include/uapi/asm/Kbuild
index d0c5471856e0..b15bf6bc0e94 100644
--- a/arch/cris/include/uapi/asm/Kbuild
+++ b/arch/cris/include/uapi/asm/Kbuild
@@ -1,5 +1,2 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
-
-subdir-y += ../arch-v10/arch/
-subdir-y += ../arch-v32/arch/
diff --git a/arch/tile/include/uapi/asm/Kbuild 
b/arch/tile/include/uapi/asm/Kbuild
index e0a50111e07f..0c74c3c5ebfa 100644
--- a/arch/tile/include/uapi/asm/Kbuild
+++ b/arch/tile/include/uapi/asm/Kbuild
@@ -2,5 +2,3 @@
 include include/uapi/asm-generic/Kbuild.asm
 
 generic-y += ucontext.h
-
-subdir-y += ../arch
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 122945618ae2..1aeb4f45208f 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -2,7 +2,7 @@
 # Installing headers
 #
 # All headers under include/uapi, include/generated/uapi,
-# arch//include/uapi/asm and arch//include/generated/uapi/asm are
+# arch//include/uapi and arch//include/generated/uapi are
 # exported.
 # They are preprocessed to remove __KERNEL__ section of the file.
 #
@@ -30,7 +30,6 @@ installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
 subdirs   := $(patsubst 

[PATCH v9 11/11] uapi: export all arch specifics directories

[Nicolas Dichtel]

This patch removes the need of subdir-y. Now all files/directories under
arch//include/uapi/ are exported.

The only change for userland is the layout of the command 'make
headers_install_all': directories asm- are replaced by arch-/.
Those new directories contains all files/directories of the specified arch.

Note that only cris and tile have more directories than only asm:
 - arch-v[10|32] for cris;
 - arch for tile.

Signed-off-by: Nicolas Dichtel 
---
 Documentation/kbuild/makefiles.txt | 15 +--
 Makefile   |  6 +++---
 arch/cris/include/uapi/asm/Kbuild  |  3 ---
 arch/tile/include/uapi/asm/Kbuild  |  2 --
 scripts/Makefile.headersinst   |  3 +--
 5 files changed, 5 insertions(+), 24 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 91ffb391ed54..223b33d5195a 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -49,7 +49,6 @@ This document describes the Linux kernel Makefiles.
--- 7.3 generic-y
--- 7.4 generated-y
--- 7.5 mandatory-y
-   --- 7.6 subdir-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1265,7 +1264,7 @@ The pre-processing does:
 - drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
 
 All headers under include/uapi/, include/generated/uapi/,
-arch//include/uapi/asm/ and arch//include/generated/uapi/asm/
+arch//include/uapi/ and arch//include/generated/uapi/
 are exported.
 
 A Kbuild file may be defined under arch//include/uapi/asm/ and
@@ -1338,18 +1337,6 @@ See subsequent chapter for the syntax of the Kbuild file.
The convention is to list one subdir per line and
preferably in alphabetic order.
 
-   --- 7.6 subdir-y
-
-   subdir-y may be used to specify a subdirectory to be exported.
-
-   Example:
-   #arch/cris/include/uapi/asm/Kbuild
-   subdir-y += ../arch-v10/arch/
-   subdir-y += ../arch-v32/arch/
-
-   The convention is to list one subdir per line and
-   preferably in alphabetic order.
-
 === 8 Kbuild Variables
 
 The top Makefile exports the following variables:
diff --git a/Makefile b/Makefile
index 4cb6b0a1152b..e9ac52330215 100644
--- a/Makefile
+++ b/Makefile
@@ -1128,7 +1128,7 @@ firmware_install:
 export INSTALL_HDR_PATH = $(objtree)/usr
 
 # If we do an all arch process set dst to asm-$(hdr-arch)
-hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
+hdr-dst = $(if $(KBUILD_HEADERS), dst=include/arch-$(hdr-arch), dst=include)
 
 PHONY += archheaders
 archheaders:
@@ -1149,7 +1149,7 @@ headers_install: __headers
$(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \
  $(error Headers not exportable for the $(SRCARCH) architecture))
$(Q)$(MAKE) $(hdr-inst)=include/uapi
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst)
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi $(hdr-dst)
 
 PHONY += headers_check_all
 headers_check_all: headers_install_all
@@ -1158,7 +1158,7 @@ headers_check_all: headers_install_all
 PHONY += headers_check
 headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) 
HDRCHECK=1
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/ $(hdr-dst) 
HDRCHECK=1
 
 # ---
 # Kernel selftest
diff --git a/arch/cris/include/uapi/asm/Kbuild 
b/arch/cris/include/uapi/asm/Kbuild
index d0c5471856e0..b15bf6bc0e94 100644
--- a/arch/cris/include/uapi/asm/Kbuild
+++ b/arch/cris/include/uapi/asm/Kbuild
@@ -1,5 +1,2 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
-
-subdir-y += ../arch-v10/arch/
-subdir-y += ../arch-v32/arch/
diff --git a/arch/tile/include/uapi/asm/Kbuild 
b/arch/tile/include/uapi/asm/Kbuild
index e0a50111e07f..0c74c3c5ebfa 100644
--- a/arch/tile/include/uapi/asm/Kbuild
+++ b/arch/tile/include/uapi/asm/Kbuild
@@ -2,5 +2,3 @@
 include include/uapi/asm-generic/Kbuild.asm
 
 generic-y += ucontext.h
-
-subdir-y += ../arch
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 122945618ae2..1aeb4f45208f 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -2,7 +2,7 @@
 # Installing headers
 #
 # All headers under include/uapi, include/generated/uapi,
-# arch//include/uapi/asm and arch//include/generated/uapi/asm are
+# arch//include/uapi and arch//include/generated/uapi are
 # exported.
 # They are preprocessed to remove __KERNEL__ section of the file.
 #
@@ -30,7 +30,6 @@ installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
 subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard 

Re: [PATCH] clk: core: Copy connection id

[Leonard Crestez]

On Tue, 2017-02-28 at 00:05 -0800, sb...@codeaurora.org wrote:
> On 02/25, Leonard Crestez wrote:
> > 
> > On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote:
> > > 
> > > On 02/20, Leonard Crestez wrote:
> > > > 
> > > > Some drivers use sprintf to build clk connection id names but
> > > > the
> > > > clk
> > > > core will save those strings and occasionally print them back.
> > > > Duplicate
> > > > the con_id strings instead of fixing all the users.
> > > Good catch. What about dev_id though? That could also have the
> > > same problem if some device is removed and we're still holding a
> > > reference to the kobject's name. This is probably more rare than
> > > what is happening here, but still seems possible that we might
> > > trip over that later.
> > A device should normally free the clks it uses before it is
> > destroyed.
> > This means that if dev_id is pointing to freed memory then the clk
> > itself was probably leaked, right?
> Sure. clk_get_sys() could be called and then we could have
> something sprintf the dev_id there. A quick grep doesn't show any
> place where that happens though so it seems safe right now.
> 
> That said, it would be nice to clearly document that we don't
> expect dev_id to be freed or changed during the lifetime of the
> clk structure, but we do allow con_id to change. Perhaps the copy
> shows that, but a comment would also be useful so we don't have
> people wondering why dev_id isn't copied as well.

This should be mentioned on the public documentation for clk_get_sys,
clk_get and devm_clk_get, right? These seem to be the public entry
points to the clk subsystem and users are expected to read their docs.

Do you want me to resend the patch with these notes?

I'm not comfortable adding to documentation when I don't fully
understand the system myself. I only discovered this while looking into
unrelated driver issues.

Re: [PATCH] clk: core: Copy connection id

[Leonard Crestez]

On Tue, 2017-02-28 at 00:05 -0800, sb...@codeaurora.org wrote:
> On 02/25, Leonard Crestez wrote:
> > 
> > On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote:
> > > 
> > > On 02/20, Leonard Crestez wrote:
> > > > 
> > > > Some drivers use sprintf to build clk connection id names but
> > > > the
> > > > clk
> > > > core will save those strings and occasionally print them back.
> > > > Duplicate
> > > > the con_id strings instead of fixing all the users.
> > > Good catch. What about dev_id though? That could also have the
> > > same problem if some device is removed and we're still holding a
> > > reference to the kobject's name. This is probably more rare than
> > > what is happening here, but still seems possible that we might
> > > trip over that later.
> > A device should normally free the clks it uses before it is
> > destroyed.
> > This means that if dev_id is pointing to freed memory then the clk
> > itself was probably leaked, right?
> Sure. clk_get_sys() could be called and then we could have
> something sprintf the dev_id there. A quick grep doesn't show any
> place where that happens though so it seems safe right now.
> 
> That said, it would be nice to clearly document that we don't
> expect dev_id to be freed or changed during the lifetime of the
> clk structure, but we do allow con_id to change. Perhaps the copy
> shows that, but a comment would also be useful so we don't have
> people wondering why dev_id isn't copied as well.

This should be mentioned on the public documentation for clk_get_sys,
clk_get and devm_clk_get, right? These seem to be the public entry
points to the clk subsystem and users are expected to read their docs.

Do you want me to resend the patch with these notes?

I'm not comfortable adding to documentation when I don't fully
understand the system myself. I only discovered this while looking into
unrelated driver issues.

[PATCH v9 05/11] Makefile.headersinst: remove destination-y option

[Nicolas Dichtel]

This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y
for exported headers") but never used in-tree.

Signed-off-by: Nicolas Dichtel 
Acked-by: Paul Bolle 
---
 Documentation/kbuild/makefiles.txt | 23 ---
 scripts/Makefile.headersinst   |  2 +-
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 9b9c4797fc55..37b525d329ae 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -46,9 +46,8 @@ This document describes the Linux kernel Makefiles.
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 genhdr-y
-   --- 7.3 destination-y
-   --- 7.4 generic-y
-   --- 7.5 generated-y
+   --- 7.3 generic-y
+   --- 7.4 generated-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1295,21 +1294,7 @@ See subsequent chapter for the syntax of the Kbuild file.
#include/linux/Kbuild
genhdr-y += version.h
 
-   --- 7.3 destination-y
-
-   When an architecture has a set of exported headers that needs to be
-   exported to a different directory destination-y is used.
-   destination-y specifies the destination directory for all exported
-   headers in the file where it is present.
-
-   Example:
-   #arch/xtensa/platforms/s6105/include/platform/Kbuild
-   destination-y := include/linux
-
-   In the example above all exported headers in the Kbuild file
-   will be located in the directory "include/linux" when exported.
-
-   --- 7.4 generic-y
+   --- 7.3 generic-y
 
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
@@ -1336,7 +1321,7 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
-   --- 7.5 generated-y
+   --- 7.4 generated-y
 
If an architecture generates other header files alongside generic-y
wrappers, and not included in genhdr-y, then generated-y specifies
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 3e20d03432d2..876b42cfede4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -14,7 +14,7 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
 include $(kbuild-file)
 
 # called may set destination dir (when installing to asm/)
-_dst := $(if $(destination-y),$(destination-y),$(if $(dst),$(dst),$(obj)))
+_dst := $(if $(dst),$(dst),$(obj))
 
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
-- 
2.8.1

[PATCH v9 05/11] Makefile.headersinst: remove destination-y option

[Nicolas Dichtel]

This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y
for exported headers") but never used in-tree.

Signed-off-by: Nicolas Dichtel 
Acked-by: Paul Bolle 
---
 Documentation/kbuild/makefiles.txt | 23 ---
 scripts/Makefile.headersinst   |  2 +-
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 9b9c4797fc55..37b525d329ae 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -46,9 +46,8 @@ This document describes the Linux kernel Makefiles.
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 genhdr-y
-   --- 7.3 destination-y
-   --- 7.4 generic-y
-   --- 7.5 generated-y
+   --- 7.3 generic-y
+   --- 7.4 generated-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1295,21 +1294,7 @@ See subsequent chapter for the syntax of the Kbuild file.
#include/linux/Kbuild
genhdr-y += version.h
 
-   --- 7.3 destination-y
-
-   When an architecture has a set of exported headers that needs to be
-   exported to a different directory destination-y is used.
-   destination-y specifies the destination directory for all exported
-   headers in the file where it is present.
-
-   Example:
-   #arch/xtensa/platforms/s6105/include/platform/Kbuild
-   destination-y := include/linux
-
-   In the example above all exported headers in the Kbuild file
-   will be located in the directory "include/linux" when exported.
-
-   --- 7.4 generic-y
+   --- 7.3 generic-y
 
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
@@ -1336,7 +1321,7 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
-   --- 7.5 generated-y
+   --- 7.4 generated-y
 
If an architecture generates other header files alongside generic-y
wrappers, and not included in genhdr-y, then generated-y specifies
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 3e20d03432d2..876b42cfede4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -14,7 +14,7 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
 include $(kbuild-file)
 
 # called may set destination dir (when installing to asm/)
-_dst := $(if $(destination-y),$(destination-y),$(if $(dst),$(dst),$(obj)))
+_dst := $(if $(dst),$(dst),$(obj))
 
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
-- 
2.8.1

[PATCH v9 06/11] uapi: includes linux/types.h before exporting files

[Nicolas Dichtel]

Some files will be exported after the next patch. 0-day tests report the
following warning/error:
./usr/include/linux/bcache.h:8: include of  is preferred over 

./usr/include/linux/bcache.h:11: found __[us]{8,16,32,64} type without #include 

./usr/include/linux/qrtr.h:8: found __[us]{8,16,32,64} type without #include 

./usr/include/linux/cryptouser.h:39: found __[us]{8,16,32,64} type without 
#include 
./usr/include/linux/pr.h:14: found __[us]{8,16,32,64} type without #include 

./usr/include/linux/btrfs_tree.h:337: found __[us]{8,16,32,64} type without 
#include 
./usr/include/rdma/bnxt_re-abi.h:45: found __[us]{8,16,32,64} type without 
#include 

Signed-off-by: Nicolas Dichtel 
---
 include/uapi/linux/bcache.h | 2 +-
 include/uapi/linux/btrfs_tree.h | 2 ++
 include/uapi/linux/cryptouser.h | 2 ++
 include/uapi/linux/pr.h | 2 ++
 include/uapi/linux/qrtr.h   | 1 +
 include/uapi/rdma/bnxt_re-abi.h | 2 ++
 6 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bcache.h b/include/uapi/linux/bcache.h
index 22b6ad31c706..e3bb0635e94a 100644
--- a/include/uapi/linux/bcache.h
+++ b/include/uapi/linux/bcache.h
@@ -5,7 +5,7 @@
  * Bcache on disk data structures
  */
 
-#include 
+#include 
 
 #define BITMASK(name, type, field, offset, size)   \
 static inline __u64 name(const type *k)\
diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index d5ad15a106a7..6a261cb52d95 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -1,6 +1,8 @@
 #ifndef _BTRFS_CTREE_H_
 #define _BTRFS_CTREE_H_
 
+#include 
+
 /*
  * This header contains the structure definitions and constants used
  * by file system objects that can be retrieved using
diff --git a/include/uapi/linux/cryptouser.h b/include/uapi/linux/cryptouser.h
index 11d21fce14d6..c6a09c5261e7 100644
--- a/include/uapi/linux/cryptouser.h
+++ b/include/uapi/linux/cryptouser.h
@@ -18,6 +18,8 @@
  * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
  */
 
+#include 
+
 /* Netlink configuration messages.  */
 enum {
CRYPTO_MSG_BASE = 0x10,
diff --git a/include/uapi/linux/pr.h b/include/uapi/linux/pr.h
index 57d7c0f916b6..645ef3cf3dd0 100644
--- a/include/uapi/linux/pr.h
+++ b/include/uapi/linux/pr.h
@@ -1,6 +1,8 @@
 #ifndef _UAPI_PR_H
 #define _UAPI_PR_H
 
+#include 
+
 enum pr_type {
PR_WRITE_EXCLUSIVE  = 1,
PR_EXCLUSIVE_ACCESS = 2,
diff --git a/include/uapi/linux/qrtr.h b/include/uapi/linux/qrtr.h
index 66c0748d26e2..b14ee91ec387 100644
--- a/include/uapi/linux/qrtr.h
+++ b/include/uapi/linux/qrtr.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_QRTR_H
 #define _LINUX_QRTR_H
 
+#include 
 #include 
 
 struct sockaddr_qrtr {
diff --git a/include/uapi/rdma/bnxt_re-abi.h b/include/uapi/rdma/bnxt_re-abi.h
index e2c8a3f0ccec..74018bd18d72 100644
--- a/include/uapi/rdma/bnxt_re-abi.h
+++ b/include/uapi/rdma/bnxt_re-abi.h
@@ -39,6 +39,8 @@
 #ifndef __BNXT_RE_UVERBS_ABI_H__
 #define __BNXT_RE_UVERBS_ABI_H__
 
+#include 
+
 #define BNXT_RE_ABI_VERSION1
 
 struct bnxt_re_uctx_resp {
-- 
2.8.1

[PATCH v9 06/11] uapi: includes linux/types.h before exporting files

[Nicolas Dichtel]

Some files will be exported after the next patch. 0-day tests report the
following warning/error:
./usr/include/linux/bcache.h:8: include of  is preferred over 

./usr/include/linux/bcache.h:11: found __[us]{8,16,32,64} type without #include 

./usr/include/linux/qrtr.h:8: found __[us]{8,16,32,64} type without #include 

./usr/include/linux/cryptouser.h:39: found __[us]{8,16,32,64} type without 
#include 
./usr/include/linux/pr.h:14: found __[us]{8,16,32,64} type without #include 

./usr/include/linux/btrfs_tree.h:337: found __[us]{8,16,32,64} type without 
#include 
./usr/include/rdma/bnxt_re-abi.h:45: found __[us]{8,16,32,64} type without 
#include 

Signed-off-by: Nicolas Dichtel 
---
 include/uapi/linux/bcache.h | 2 +-
 include/uapi/linux/btrfs_tree.h | 2 ++
 include/uapi/linux/cryptouser.h | 2 ++
 include/uapi/linux/pr.h | 2 ++
 include/uapi/linux/qrtr.h   | 1 +
 include/uapi/rdma/bnxt_re-abi.h | 2 ++
 6 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bcache.h b/include/uapi/linux/bcache.h
index 22b6ad31c706..e3bb0635e94a 100644
--- a/include/uapi/linux/bcache.h
+++ b/include/uapi/linux/bcache.h
@@ -5,7 +5,7 @@
  * Bcache on disk data structures
  */
 
-#include 
+#include 
 
 #define BITMASK(name, type, field, offset, size)   \
 static inline __u64 name(const type *k)\
diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index d5ad15a106a7..6a261cb52d95 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -1,6 +1,8 @@
 #ifndef _BTRFS_CTREE_H_
 #define _BTRFS_CTREE_H_
 
+#include 
+
 /*
  * This header contains the structure definitions and constants used
  * by file system objects that can be retrieved using
diff --git a/include/uapi/linux/cryptouser.h b/include/uapi/linux/cryptouser.h
index 11d21fce14d6..c6a09c5261e7 100644
--- a/include/uapi/linux/cryptouser.h
+++ b/include/uapi/linux/cryptouser.h
@@ -18,6 +18,8 @@
  * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
  */
 
+#include 
+
 /* Netlink configuration messages.  */
 enum {
CRYPTO_MSG_BASE = 0x10,
diff --git a/include/uapi/linux/pr.h b/include/uapi/linux/pr.h
index 57d7c0f916b6..645ef3cf3dd0 100644
--- a/include/uapi/linux/pr.h
+++ b/include/uapi/linux/pr.h
@@ -1,6 +1,8 @@
 #ifndef _UAPI_PR_H
 #define _UAPI_PR_H
 
+#include 
+
 enum pr_type {
PR_WRITE_EXCLUSIVE  = 1,
PR_EXCLUSIVE_ACCESS = 2,
diff --git a/include/uapi/linux/qrtr.h b/include/uapi/linux/qrtr.h
index 66c0748d26e2..b14ee91ec387 100644
--- a/include/uapi/linux/qrtr.h
+++ b/include/uapi/linux/qrtr.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_QRTR_H
 #define _LINUX_QRTR_H
 
+#include 
 #include 
 
 struct sockaddr_qrtr {
diff --git a/include/uapi/rdma/bnxt_re-abi.h b/include/uapi/rdma/bnxt_re-abi.h
index e2c8a3f0ccec..74018bd18d72 100644
--- a/include/uapi/rdma/bnxt_re-abi.h
+++ b/include/uapi/rdma/bnxt_re-abi.h
@@ -39,6 +39,8 @@
 #ifndef __BNXT_RE_UVERBS_ABI_H__
 #define __BNXT_RE_UVERBS_ABI_H__
 
+#include 
+
 #define BNXT_RE_ABI_VERSION1
 
 struct bnxt_re_uctx_resp {
-- 
2.8.1

[PATCH] staging: speakup: replace simple_strtoul with kstrtou8

[Marcin Ciupak]

Replace simple_strtoul with kstrtou8.
simple_strtoul is marked for obsoletion.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/speakup/varhandlers.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..c219db745865 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -323,11 +323,10 @@ char *spk_strlwr(char *s)
 
 char *spk_s2uchar(char *start, char *dest)
 {
-   int val;
+   int ret;
 
-   val = simple_strtoul(skip_spaces(start), , 10);
+   ret = kstrtou8(skip_spaces(start), 10, dest);
if (*start == ',')
start++;
-   *dest = (u_char)val;
return start;
 }
-- 
2.11.1

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

[Rafael J. Wysocki]

On Thu, Mar 2, 2017 at 6:18 PM, Rafael J. Wysocki  wrote:
> On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki  wrote:
>> From: Rafael J. Wysocki 
>>
>> If the current P-state selection algorithm is set to "performance"
>> in intel_pstate_set_policy(), the limits may be initialized from
>> scratch, but only if no_turbo is not set and the maximum frequency
>> allowed for the given CPU (i.e. the policy object representing it)
>> is at least equal to the max frequency supported by the CPU.  In all
>> of the other cases, the limits will not be updated.
>>
>> For example, the following can happen:
>>
>>  # cat intel_pstate/status
>>  active
>>  # echo performance > cpufreq/policy0/scaling_governor
>>  # cat intel_pstate/min_perf_pct
>>  100
>>  # echo 94 > intel_pstate/min_perf_pct
>>  # cat intel_pstate/min_perf_pct
>>  100
>>  # cat cpufreq/policy0/scaling_max_freq
>>  310
>>  echo 300 > cpufreq/policy0/scaling_max_freq
>>  # cat intel_pstate/min_perf_pct
>>  94
>>  # echo 95 > intel_pstate/min_perf_pct
>>  # cat intel_pstate/min_perf_pct
>>  95
>>
>> That is confusing for two reasons.  First, the initial attempt to
>> change min_perf_pct to 94 seems to have no effect, even though
>> setting the global limits should always work.  Second, after
>> changing scaling_max_freq for policy0 the global min_perf_pct
>> attribute shows 94, even though it should have not been affected
>> by that operation in principle.
>>
>> Moreover, the final attempt to change min_perf_pct to 95 worked
>> as expected, because scaling_max_freq for the only policy with
>> scaling_governor equal to "performance" was different from the
>> maximum at that time.
>>
>> To make all that confusion go away, modify intel_pstate_set_policy()
>> so that it doesn't reinitialize the limits at all.
>>
>> At the same time, change intel_pstate_set_performance_limits() to
>> set min_sysfs_pct to 100 in the "performance" limits set so that
>> switching the P-state selection algorithm to "performance" causes
>> intel_pstate/min_perf_pct in sysfs to go to 100 (or whatever value
>> min_sysfs_pct in the "performance" limits is set to later).
>>
>> Signed-off-by: Rafael J. Wysocki 
>> ---
>>
>> -> v2: No changes
>>
>> ---
>>  drivers/cpufreq/intel_pstate.c |   10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> Index: linux-pm/drivers/cpufreq/intel_pstate.c
>> ===
>> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
>> +++ linux-pm/drivers/cpufreq/intel_pstate.c
>> @@ -382,6 +382,7 @@ static void intel_pstate_set_performance
>> intel_pstate_init_limits(limits);
>> limits->min_perf_pct = 100;
>> limits->min_perf = int_ext_tofp(1);
>> +   limits->min_sysfs_pct = 100;
>
> This change breaks the per-CPU limits, so the patch is not correct.
>
> Withdrawing.

Actually, it appears to be fixable, so I will send a new version
later, most likely.

Thanks,
Rafael

[PATCH] staging: speakup: replace simple_strtoul with kstrtou8

[Marcin Ciupak]

Replace simple_strtoul with kstrtou8.
simple_strtoul is marked for obsoletion.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/speakup/varhandlers.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..c219db745865 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -323,11 +323,10 @@ char *spk_strlwr(char *s)
 
 char *spk_s2uchar(char *start, char *dest)
 {
-   int val;
+   int ret;
 
-   val = simple_strtoul(skip_spaces(start), , 10);
+   ret = kstrtou8(skip_spaces(start), 10, dest);
if (*start == ',')
start++;
-   *dest = (u_char)val;
return start;
 }
-- 
2.11.1

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

[Rafael J. Wysocki]

On Thu, Mar 2, 2017 at 6:18 PM, Rafael J. Wysocki  wrote:
> On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki  wrote:
>> From: Rafael J. Wysocki 
>>
>> If the current P-state selection algorithm is set to "performance"
>> in intel_pstate_set_policy(), the limits may be initialized from
>> scratch, but only if no_turbo is not set and the maximum frequency
>> allowed for the given CPU (i.e. the policy object representing it)
>> is at least equal to the max frequency supported by the CPU.  In all
>> of the other cases, the limits will not be updated.
>>
>> For example, the following can happen:
>>
>>  # cat intel_pstate/status
>>  active
>>  # echo performance > cpufreq/policy0/scaling_governor
>>  # cat intel_pstate/min_perf_pct
>>  100
>>  # echo 94 > intel_pstate/min_perf_pct
>>  # cat intel_pstate/min_perf_pct
>>  100
>>  # cat cpufreq/policy0/scaling_max_freq
>>  310
>>  echo 300 > cpufreq/policy0/scaling_max_freq
>>  # cat intel_pstate/min_perf_pct
>>  94
>>  # echo 95 > intel_pstate/min_perf_pct
>>  # cat intel_pstate/min_perf_pct
>>  95
>>
>> That is confusing for two reasons.  First, the initial attempt to
>> change min_perf_pct to 94 seems to have no effect, even though
>> setting the global limits should always work.  Second, after
>> changing scaling_max_freq for policy0 the global min_perf_pct
>> attribute shows 94, even though it should have not been affected
>> by that operation in principle.
>>
>> Moreover, the final attempt to change min_perf_pct to 95 worked
>> as expected, because scaling_max_freq for the only policy with
>> scaling_governor equal to "performance" was different from the
>> maximum at that time.
>>
>> To make all that confusion go away, modify intel_pstate_set_policy()
>> so that it doesn't reinitialize the limits at all.
>>
>> At the same time, change intel_pstate_set_performance_limits() to
>> set min_sysfs_pct to 100 in the "performance" limits set so that
>> switching the P-state selection algorithm to "performance" causes
>> intel_pstate/min_perf_pct in sysfs to go to 100 (or whatever value
>> min_sysfs_pct in the "performance" limits is set to later).
>>
>> Signed-off-by: Rafael J. Wysocki 
>> ---
>>
>> -> v2: No changes
>>
>> ---
>>  drivers/cpufreq/intel_pstate.c |   10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> Index: linux-pm/drivers/cpufreq/intel_pstate.c
>> ===
>> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
>> +++ linux-pm/drivers/cpufreq/intel_pstate.c
>> @@ -382,6 +382,7 @@ static void intel_pstate_set_performance
>> intel_pstate_init_limits(limits);
>> limits->min_perf_pct = 100;
>> limits->min_perf = int_ext_tofp(1);
>> +   limits->min_sysfs_pct = 100;
>
> This change breaks the per-CPU limits, so the patch is not correct.
>
> Withdrawing.

Actually, it appears to be fixable, so I will send a new version
later, most likely.

Thanks,
Rafael

Re: [tpmdd-devel] [PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

[Andrew Lunn]

> >> Hi Enric
> >>
> >> Maybe you should remember that you need to use smaller transfers? If
> >> you don't remember, but use the full size message every time and only
> >> drop back on error, the i2c core is going to log rate limited
> >> messages. By remembering, there will only be one such message in the
> >> log.
> >>
> 

> Maybe I did not explain well but this is what the code does, when
> i2c-core fails with -EOPNOTSUPP because the msg is too long for this
> adapter it loop with a smaller chunk of fixed size, so you only see
> the i2c-core message once.

Hi Enric

Would it not be more accurate to say, that you only see the i2c-core
message once, for this transfer request. Is the next transfer request
again going to use the longer length? then fail, maybe generate
another i2c core message, depending on rate limiting, and then use the
lower message size? I think it does.

Which is why i suggested remembering the length.

  Andrew

Re: [tpmdd-devel] [PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

[Andrew Lunn]

> >> Hi Enric
> >>
> >> Maybe you should remember that you need to use smaller transfers? If
> >> you don't remember, but use the full size message every time and only
> >> drop back on error, the i2c core is going to log rate limited
> >> messages. By remembering, there will only be one such message in the
> >> log.
> >>
> 

> Maybe I did not explain well but this is what the code does, when
> i2c-core fails with -EOPNOTSUPP because the msg is too long for this
> adapter it loop with a smaller chunk of fixed size, so you only see
> the i2c-core message once.

Hi Enric

Would it not be more accurate to say, that you only see the i2c-core
message once, for this transfer request. Is the next transfer request
again going to use the longer length? then fail, maybe generate
another i2c core message, depending on rate limiting, and then use the
lower message size? I think it does.

Which is why i suggested remembering the length.

  Andrew

[PATCH 10/26] brcmsmac: reindent split functions

[Arnd Bergmann]

In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.

No changes other than whitespace are intended here.

Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 +---
 1 file changed, 697 insertions(+), 810 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index d76c092bb6b4..9b39789c673d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16074,7 +16074,8 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
NPHY_REV3_RFSEQ_CMD_END
};
-   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
+   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] =
+   { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
u32 leg_data_weights;
u8 chan_freq_range = 0;
@@ -16114,526 +16115,452 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
int coreNum;
 
 
-   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
-   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
-
-   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
-   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
-   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
-   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
-   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
-   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
-   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
-   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
-   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
-   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
-   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
-   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
-   }
-
-   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
-   write_phy_reg(pi, 0x23f, 0x1b0);
-   write_phy_reg(pi, 0x240, 0x1b0);
-   }
+   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
+   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
+
+   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
+   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
+   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
+   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
+   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
+   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
+   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
+   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
+   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
+   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
+   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
+   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
+   }
 
-   if (NREV_GE(pi->pubpi.phy_rev, 8))
-   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
+   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
+   write_phy_reg(pi, 0x23f, 0x1b0);
+   write_phy_reg(pi, 0x240, 0x1b0);
+   }
 
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x00, 16,
-_control);
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x10, 16,
-_control);
+   if (NREV_GE(pi->pubpi.phy_rev, 8))
+   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
 
-   wlc_phy_table_read_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-   1, 0, 32, _data_weights);
-   leg_data_weights = leg_data_weights & 0xff;
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-1, 0, 32, 

[PATCH 10/26] brcmsmac: reindent split functions

[Arnd Bergmann]

In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.

No changes other than whitespace are intended here.

Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 +---
 1 file changed, 697 insertions(+), 810 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index d76c092bb6b4..9b39789c673d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16074,7 +16074,8 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
NPHY_REV3_RFSEQ_CMD_END
};
-   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
+   static const u8 rfseq_rx2tx_dlys_rev3_ipa[] =
+   { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
u32 leg_data_weights;
u8 chan_freq_range = 0;
@@ -16114,526 +16115,452 @@ static void wlc_phy_workarounds_nphy_rev7(struct 
brcms_phy *pi)
int coreNum;
 
 
-   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
-   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
-
-   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
-   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
-   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
-   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
-   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
-   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
-   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
-   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
-   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
-   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
-   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
-   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
-   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
-   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
-   }
-
-   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
-   write_phy_reg(pi, 0x23f, 0x1b0);
-   write_phy_reg(pi, 0x240, 0x1b0);
-   }
+   if (NREV_IS(pi->pubpi.phy_rev, 7)) {
+   mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
+
+   mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
+   mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
+   mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
+   mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
+   mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
+   mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
+   mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
+   mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
+   mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
+   mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
+   mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
+   mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
+   mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
+   mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
+   }
 
-   if (NREV_GE(pi->pubpi.phy_rev, 8))
-   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
+   if (NREV_LE(pi->pubpi.phy_rev, 8)) {
+   write_phy_reg(pi, 0x23f, 0x1b0);
+   write_phy_reg(pi, 0x240, 0x1b0);
+   }
 
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x00, 16,
-_control);
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x10, 16,
-_control);
+   if (NREV_GE(pi->pubpi.phy_rev, 8))
+   mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
 
-   wlc_phy_table_read_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-   1, 0, 32, _data_weights);
-   leg_data_weights = leg_data_weights & 0xff;
-   wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_CMPMETRICDATAWEIGHTTBL,
-1, 0, 32, _data_weights);
+   

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Igor Mammedov]

On Thu, 2 Mar 2017 15:28:16 +0100
Michal Hocko  wrote:

> On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
> [...]
> > When trying to support memory unplug on guest side in RHEL7,
> > experience shows otherwise. Simplistic udev rule which onlines
> > added block doesn't work in case one wants to online it as movable.
> > 
> > Hotplugged blocks in current kernel should be onlined in reverse
> > order to online blocks as movable depending on adjacent blocks zone.  
> 
> Could you be more specific please? Setting online_movable from the udev
> rule should just work regardless of the ordering or the state of other
> memblocks. If that doesn't work I would call it a bug.
It's rather an implementation constrain than a bug
for details and workaround patch see
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314306#c7
patch attached there is limited by another memory hotplug
issue, which is NORMAL/MOVABLE zone balance, if kernel runs
on configuration where the most of memory is hot-removable
kernel might experience lack of memory in zone NORMAL.

> 
> > Which means simple udev rule isn't usable since it gets event from
> > the first to the last hotplugged block order. So now we would have
> > to write a daemon that would
> >  - watch for all blocks in hotplugged memory appear (how would it know)
> >  - online them in right order (order might also be different depending
> >on kernel version)
> >-- it becomes even more complicated in NUMA case when there are
> >   multiple zones and kernel would have to provide user-space
> >   with information about zone maps
> > 
> > In short current experience shows that userspace approach
> >  - doesn't solve issues that Vitaly has been fixing (i.e. onlining
> >fast and/or under memory pressure) when udev (or something else
> >might be killed)  
> 
> yeah and that is why the patch does the onlining from the kernel.
onlining in this patch is limited to hyperv and patch breaks
auto-online on x86 kvm/vmware/baremetal as they reuse the same
hotplug path.

> > > Can you imagine any situation when somebody actually might want to have
> > > this knob enabled? From what I understand it doesn't seem to be the
> > > case.  
> > For x86:
> >  * this config option is enabled by default in recent Fedora,  
> 
> How do you want to support usecases which really want to online memory
> as movable? Do you expect those users to disable the option because
> unless I am missing something the in kernel auto onlining only supporst
> regular onlining.
current auto onlining config option does what it's been designed for,
i.e. it onlines hotplugged memory.
It's possible for non average Fedora user to override default
(commit 86dd995d6) if she/he needs non default behavior
(i.e. user knows how to online manually and/or can write
a daemon that would handle all of nuances of kernel in use).

For the rest when Fedora is used in cloud and user increases memory
via management interface of whatever cloud she/he uses, it just works.

So it's choice of distribution to pick its own default that makes
majority of user-base happy and this patch removes it without taking
that in consideration.

How to online memory is different issue not related to this patch,
current default onlining as ZONE_NORMAL works well for scaling
up VMs.

Memory unplug is rather new and it doesn't work reliably so far,
moving onlining to user-space won't really help. Further work
is need to be done so that it would work reliably.

Now about the question of onlining removable memory as movable,
x86 kernel is able to get info, if hotadded memory is removable,
from ACPI subsystem and online it as movable one without any
intervention from user-space where it's hard to do so,
as patch[1] shows.
Problem is still researched and when we figure out how to fix
hot-remove issues we might enable auto-onlining by default for x86.

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

[Igor Mammedov]

On Thu, 2 Mar 2017 15:28:16 +0100
Michal Hocko  wrote:

> On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
> [...]
> > When trying to support memory unplug on guest side in RHEL7,
> > experience shows otherwise. Simplistic udev rule which onlines
> > added block doesn't work in case one wants to online it as movable.
> > 
> > Hotplugged blocks in current kernel should be onlined in reverse
> > order to online blocks as movable depending on adjacent blocks zone.  
> 
> Could you be more specific please? Setting online_movable from the udev
> rule should just work regardless of the ordering or the state of other
> memblocks. If that doesn't work I would call it a bug.
It's rather an implementation constrain than a bug
for details and workaround patch see
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314306#c7
patch attached there is limited by another memory hotplug
issue, which is NORMAL/MOVABLE zone balance, if kernel runs
on configuration where the most of memory is hot-removable
kernel might experience lack of memory in zone NORMAL.

> 
> > Which means simple udev rule isn't usable since it gets event from
> > the first to the last hotplugged block order. So now we would have
> > to write a daemon that would
> >  - watch for all blocks in hotplugged memory appear (how would it know)
> >  - online them in right order (order might also be different depending
> >on kernel version)
> >-- it becomes even more complicated in NUMA case when there are
> >   multiple zones and kernel would have to provide user-space
> >   with information about zone maps
> > 
> > In short current experience shows that userspace approach
> >  - doesn't solve issues that Vitaly has been fixing (i.e. onlining
> >fast and/or under memory pressure) when udev (or something else
> >might be killed)  
> 
> yeah and that is why the patch does the onlining from the kernel.
onlining in this patch is limited to hyperv and patch breaks
auto-online on x86 kvm/vmware/baremetal as they reuse the same
hotplug path.

> > > Can you imagine any situation when somebody actually might want to have
> > > this knob enabled? From what I understand it doesn't seem to be the
> > > case.  
> > For x86:
> >  * this config option is enabled by default in recent Fedora,  
> 
> How do you want to support usecases which really want to online memory
> as movable? Do you expect those users to disable the option because
> unless I am missing something the in kernel auto onlining only supporst
> regular onlining.
current auto onlining config option does what it's been designed for,
i.e. it onlines hotplugged memory.
It's possible for non average Fedora user to override default
(commit 86dd995d6) if she/he needs non default behavior
(i.e. user knows how to online manually and/or can write
a daemon that would handle all of nuances of kernel in use).

For the rest when Fedora is used in cloud and user increases memory
via management interface of whatever cloud she/he uses, it just works.

So it's choice of distribution to pick its own default that makes
majority of user-base happy and this patch removes it without taking
that in consideration.

How to online memory is different issue not related to this patch,
current default onlining as ZONE_NORMAL works well for scaling
up VMs.

Memory unplug is rather new and it doesn't work reliably so far,
moving onlining to user-space won't really help. Further work
is need to be done so that it would work reliably.

Now about the question of onlining removable memory as movable,
x86 kernel is able to get info, if hotadded memory is removable,
from ACPI subsystem and online it as movable one without any
intervention from user-space where it's hard to do so,
as patch[1] shows.
Problem is still researched and when we figure out how to fix
hot-remove issues we might enable auto-onlining by default for x86.

[PATCH 11/26] rtlwifi: reduce stack usage for KASAN

[Arnd Bergmann]

When CONFIG_KASAN is set, we use a large amount of stack in the btcoexist code,
presumably due to lots of inlining of functions that each add to the kernel
stack.

net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:3762:1: error: the 
frame size of 4032 bytes is larger than 3072 bytes
net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3076:1: error: the 
frame size of 4104 bytes is larger than 3072 bytes
net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3740:1: error: the 
frame size of 3408 bytes is larger than 3072 bytes

I went through these recursively and marked functions as noinline_for_kasan
until no function used more than a kilobyte. While I saw the warning only for
three of the five files, I'm changing all five the same way for consistency.
This should help in case gcc later makes different inlining decisions.

Signed-off-by: Arnd Bergmann 
---
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c| 41 +++---
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 26 +++---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 34 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 36 +--
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 38 ++--
 5 files changed, 88 insertions(+), 87 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index ffa1f438424d..8433c406a3c0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -455,7 +455,7 @@ static void halbtc8192e2ant_querybt_info(struct btc_coexist 
*btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
 }
 
-static void halbtc8192e2ant_update_btlink_info(struct btc_coexist *btcoexist)
+static noinline_for_kasan void halbtc8192e2ant_update_btlink_info(struct 
btc_coexist *btcoexist)
 {
struct btc_bt_link_info *bt_link_info = >bt_link_info;
bool bt_hson = false;
@@ -751,7 +751,7 @@ static void halbtc8192e2ant_set_fwdec_btpwr(struct 
btc_coexist *btcoexist,
btcoexist->btc_fill_h2c(btcoexist, 0x62, 1, h2c_parameter);
 }
 
-static void halbtc8192e2ant_dec_btpwr(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_dec_btpwr(struct btc_coexist 
*btcoexist,
  bool force_exec, u8 dec_btpwr_lvl)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -817,7 +817,7 @@ static void halbtc8192e2ant_bt_autoreport(struct 
btc_coexist *btcoexist,
coex_dm->pre_bt_auto_report = coex_dm->cur_bt_auto_report;
 }
 
-static void halbtc8192e2ant_fw_dac_swinglvl(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_fw_dac_swinglvl(struct 
btc_coexist *btcoexist,
bool force_exec, u8 fw_dac_swinglvl)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1145,8 +1145,9 @@ static void halbtc8192e2ant_IgnoreWlanAct(struct 
btc_coexist *btcoexist,
coex_dm->pre_ignore_wlan_act = coex_dm->cur_ignore_wlan_act;
 }
 
-static void halbtc8192e2ant_SetFwPstdma(struct btc_coexist *btcoexist, u8 
byte1,
-   u8 byte2, u8 byte3, u8 byte4, u8 byte5)
+static noinline_for_kasan void
+halbtc8192e2ant_SetFwPstdma(struct btc_coexist *btcoexist, u8 byte1,
+   u8 byte2, u8 byte3, u8 byte4, u8 byte5)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
 
@@ -1328,7 +1329,7 @@ static void halbtc8192e2ant_ps_tdma(struct btc_coexist 
*btcoexist,
coex_dm->pre_ps_tdma = coex_dm->cur_ps_tdma;
 }
 
-static void halbtc8192e2ant_set_switch_sstype(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_set_switch_sstype(struct 
btc_coexist *btcoexist,
  u8 sstype)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1365,7 +1366,7 @@ static void halbtc8192e2ant_set_switch_sstype(struct 
btc_coexist *btcoexist,
btcoexist->btc_set(btcoexist, BTC_SET_ACT_SEND_MIMO_PS, );
 }
 
-static void halbtc8192e2ant_switch_sstype(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_switch_sstype(struct 
btc_coexist *btcoexist,
  bool force_exec, u8 new_sstype)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1432,7 +1433,7 @@ static void halbtc8192e2ant_action_bt_inquiry(struct 
btc_coexist *btcoexist)
btc8192e2ant_sw_mec2(btcoexist, false, false, false, 0x18);
 }
 
-static bool halbtc8192e2ant_is_common_action(struct btc_coexist *btcoexist)
+static noinline_for_kasan bool halbtc8192e2ant_is_common_action(struct 
btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
struct btc_bt_link_info *bt_link_info = >bt_link_info;
@@ -2358,7 

[PATCH 11/26] rtlwifi: reduce stack usage for KASAN

[Arnd Bergmann]

When CONFIG_KASAN is set, we use a large amount of stack in the btcoexist code,
presumably due to lots of inlining of functions that each add to the kernel
stack.

net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:3762:1: error: the 
frame size of 4032 bytes is larger than 3072 bytes
net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:3076:1: error: the 
frame size of 4104 bytes is larger than 3072 bytes
net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3740:1: error: the 
frame size of 3408 bytes is larger than 3072 bytes

I went through these recursively and marked functions as noinline_for_kasan
until no function used more than a kilobyte. While I saw the warning only for
three of the five files, I'm changing all five the same way for consistency.
This should help in case gcc later makes different inlining decisions.

Signed-off-by: Arnd Bergmann 
---
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c| 41 +++---
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 26 +++---
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 34 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 36 +--
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 38 ++--
 5 files changed, 88 insertions(+), 87 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index ffa1f438424d..8433c406a3c0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -455,7 +455,7 @@ static void halbtc8192e2ant_querybt_info(struct btc_coexist 
*btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
 }
 
-static void halbtc8192e2ant_update_btlink_info(struct btc_coexist *btcoexist)
+static noinline_for_kasan void halbtc8192e2ant_update_btlink_info(struct 
btc_coexist *btcoexist)
 {
struct btc_bt_link_info *bt_link_info = >bt_link_info;
bool bt_hson = false;
@@ -751,7 +751,7 @@ static void halbtc8192e2ant_set_fwdec_btpwr(struct 
btc_coexist *btcoexist,
btcoexist->btc_fill_h2c(btcoexist, 0x62, 1, h2c_parameter);
 }
 
-static void halbtc8192e2ant_dec_btpwr(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_dec_btpwr(struct btc_coexist 
*btcoexist,
  bool force_exec, u8 dec_btpwr_lvl)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -817,7 +817,7 @@ static void halbtc8192e2ant_bt_autoreport(struct 
btc_coexist *btcoexist,
coex_dm->pre_bt_auto_report = coex_dm->cur_bt_auto_report;
 }
 
-static void halbtc8192e2ant_fw_dac_swinglvl(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_fw_dac_swinglvl(struct 
btc_coexist *btcoexist,
bool force_exec, u8 fw_dac_swinglvl)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1145,8 +1145,9 @@ static void halbtc8192e2ant_IgnoreWlanAct(struct 
btc_coexist *btcoexist,
coex_dm->pre_ignore_wlan_act = coex_dm->cur_ignore_wlan_act;
 }
 
-static void halbtc8192e2ant_SetFwPstdma(struct btc_coexist *btcoexist, u8 
byte1,
-   u8 byte2, u8 byte3, u8 byte4, u8 byte5)
+static noinline_for_kasan void
+halbtc8192e2ant_SetFwPstdma(struct btc_coexist *btcoexist, u8 byte1,
+   u8 byte2, u8 byte3, u8 byte4, u8 byte5)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
 
@@ -1328,7 +1329,7 @@ static void halbtc8192e2ant_ps_tdma(struct btc_coexist 
*btcoexist,
coex_dm->pre_ps_tdma = coex_dm->cur_ps_tdma;
 }
 
-static void halbtc8192e2ant_set_switch_sstype(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_set_switch_sstype(struct 
btc_coexist *btcoexist,
  u8 sstype)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1365,7 +1366,7 @@ static void halbtc8192e2ant_set_switch_sstype(struct 
btc_coexist *btcoexist,
btcoexist->btc_set(btcoexist, BTC_SET_ACT_SEND_MIMO_PS, );
 }
 
-static void halbtc8192e2ant_switch_sstype(struct btc_coexist *btcoexist,
+static noinline_for_kasan void halbtc8192e2ant_switch_sstype(struct 
btc_coexist *btcoexist,
  bool force_exec, u8 new_sstype)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1432,7 +1433,7 @@ static void halbtc8192e2ant_action_bt_inquiry(struct 
btc_coexist *btcoexist)
btc8192e2ant_sw_mec2(btcoexist, false, false, false, 0x18);
 }
 
-static bool halbtc8192e2ant_is_common_action(struct btc_coexist *btcoexist)
+static noinline_for_kasan bool halbtc8192e2ant_is_common_action(struct 
btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
struct btc_bt_link_info *bt_link_info = >bt_link_info;
@@ -2358,7 +2359,7 @@ static 

[PATCH 2/4] Staging:wilc1000:wilc_spi: Fixed alignment to match parenthesis

[Georgios Emmanouil]

Fixed alignment to match parenthesis.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 6bd4047..b48cb1c8 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -408,7 +408,7 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,

if (len2 > ARRAY_SIZE(wb)) {
dev_err(>dev, "spi buffer size too small (%d) (%zu)\n",
-len2, ARRAY_SIZE(wb));
+   len2, ARRAY_SIZE(wb));
return N_FAIL;
}
/* zero spi write buffers. */
--
2.1.4

[PATCH 2/4] Staging:wilc1000:wilc_spi: Fixed alignment to match parenthesis

[Georgios Emmanouil]

Fixed alignment to match parenthesis.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 6bd4047..b48cb1c8 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -408,7 +408,7 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,

if (len2 > ARRAY_SIZE(wb)) {
dev_err(>dev, "spi buffer size too small (%d) (%zu)\n",
-len2, ARRAY_SIZE(wb));
+   len2, ARRAY_SIZE(wb));
return N_FAIL;
}
/* zero spi write buffers. */
--
2.1.4

[PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan

[Arnd Bergmann]

When building with KASAN, we get a stack frame size warning about a function
that could potentially cause a stack overflow:

drivers/media/i2c/adv7604.c: In function 'adv76xx_log_status':
drivers/media/i2c/adv7604.c:2615:1: error: the frame size of 3248 bytes is 
larger than 3072 bytes [-Werror=frame-larger-than=]

This is caused by adv76xx_read_check() being inlined repeatedly, and
marking this function as noinline_for_kasan solves the problem
completely.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/adv7604.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d8bf435db86d..176f46ac85fd 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -339,8 +339,8 @@ static inline unsigned vtotal(const struct v4l2_bt_timings 
*t)
 
 /* --- */
 
-static int adv76xx_read_check(struct adv76xx_state *state,
-int client_page, u8 reg)
+static noinline_for_kasan int adv76xx_read_check(struct adv76xx_state *state,
+int client_page, u8 reg)
 {
struct i2c_client *client = state->i2c_clients[client_page];
int err;
-- 
2.9.0

[PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan

[Arnd Bergmann]

When building with KASAN, we get a stack frame size warning about a function
that could potentially cause a stack overflow:

drivers/media/i2c/adv7604.c: In function 'adv76xx_log_status':
drivers/media/i2c/adv7604.c:2615:1: error: the frame size of 3248 bytes is 
larger than 3072 bytes [-Werror=frame-larger-than=]

This is caused by adv76xx_read_check() being inlined repeatedly, and
marking this function as noinline_for_kasan solves the problem
completely.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/adv7604.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d8bf435db86d..176f46ac85fd 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -339,8 +339,8 @@ static inline unsigned vtotal(const struct v4l2_bt_timings 
*t)
 
 /* --- */
 
-static int adv76xx_read_check(struct adv76xx_state *state,
-int client_page, u8 reg)
+static noinline_for_kasan int adv76xx_read_check(struct adv76xx_state *state,
+int client_page, u8 reg)
 {
struct i2c_client *client = state->i2c_clients[client_page];
int err;
-- 
2.9.0

[PATCH 12/26] wl3501_cs: reduce stack size for KASAN

[Arnd Bergmann]

Inlining functions with local variables can lead to excessive stack usage
with KASAN:

drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt':
drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is 
larger than 1536 bytes [-Werror=frame-larger-than=]

Marking a few functions as noinline_for_kasan avoids the problem

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/wl3501_cs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index acec0d9ec422..15dd8e31d373 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -242,8 +242,8 @@ static int wl3501_get_flash_mac_addr(struct wl3501_card 
*this)
  *
  * Move 'size' bytes from PC to card. (Shouldn't be interrupted)
  */
-static void wl3501_set_to_wla(struct wl3501_card *this, u16 dest, void *src,
- int size)
+static noinline_for_kasan void wl3501_set_to_wla(struct wl3501_card *this,
+u16 dest, void *src, int size)
 {
/* switch to SRAM Page 0 */
wl3501_switch_page(this, (dest & 0x8000) ? WL3501_BSS_SPAGE1 :
@@ -264,8 +264,8 @@ static void wl3501_set_to_wla(struct wl3501_card *this, u16 
dest, void *src,
  *
  * Move 'size' bytes from card to PC. (Shouldn't be interrupted)
  */
-static void wl3501_get_from_wla(struct wl3501_card *this, u16 src, void *dest,
-   int size)
+static noinline_for_kasan void wl3501_get_from_wla(struct wl3501_card *this,
+   u16 src, void *dest, int size)
 {
/* switch to SRAM Page 0 */
wl3501_switch_page(this, (src & 0x8000) ? WL3501_BSS_SPAGE1 :
@@ -1037,7 +1037,7 @@ static inline void wl3501_auth_confirm_interrupt(struct 
wl3501_card *this,
wl3501_mgmt_resync(this);
 }
 
-static inline void wl3501_rx_interrupt(struct net_device *dev)
+static noinline_for_kasan void wl3501_rx_interrupt(struct net_device *dev)
 {
int morepkts;
u16 addr;
-- 
2.9.0

[PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

[Arnd Bergmann]

With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:

broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 
3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 
2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.

Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 197 ++---
 1 file changed, 97 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 42dc8e1f483d..48a4df488d75 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void 
wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
 }
 
 static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
-  u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+  const u8 *dlys, u8 len)
 {
u32 t1_offset, t2_offset;
u8 ctr;
@@ -15240,16 +15240,16 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
 static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 {
u16 currband;
-   s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
-   s8 *lna1_gain_db = NULL;
-   s8 *lna1_gain_db_2 = NULL;
-   s8 *lna2_gain_db = NULL;
-   s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
-   s8 *tia_gain_db;
-   s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
-   s8 *tia_gainbits;
-   u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
-   u16 *rfseq_init_gain;
+   static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+   const s8 *lna1_gain_db = NULL;
+   const s8 *lna1_gain_db_2 = NULL;
+   const s8 *lna2_gain_db = NULL;
+   static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 
};
+   const s8 *tia_gain_db;
+   static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+   const s8 *tia_gainbits;
+   static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+   const u16 *rfseq_init_gain;
u16 init_gaincode;
u16 clip1hi_gaincode;
u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 
if ((freq <= 5080) || (freq == 5825)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   11, 17, 22, 25};
-   s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
16, 20, 24 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 11, 
17, 22, 25};
+   static const s8 lna2A_gain_db_rev7[] = { -1, 6, 
10, 14 };
 
crsminu_th = 0x3e;
lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else if ((freq >= 5500) && (freq <= 5700)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   12, 18, 22, 26};
-   s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
17, 21, 25 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 12, 
18, 22, 26};
+   static const s8 lna2A_gain_db_rev7[] = { 1, 8, 
12, 16 };
 
crsminu_th = 0x45;
clip1md_gaincode_B = 0x14;
@@ -15335,10 +15333,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else {
 
-   s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
-   s8 lna1A_gain_db_2_rev7[] = {
-

[PATCH 00/26] bring back stack frame warning with KASAN

[Arnd Bergmann]

It took a long while to get this done, but I'm finally ready
to send the first half of the KASAN stack size patches that
I did in response to the kernelci.org warnings.

As before, it's worth mentioning that things are generally worse
with gcc-7.0.1 because of the addition of -fsanitize-address-use-after-scope
that are not present on kernelci, so my randconfig testing found
a lot more than kernelci did.

The main areas are:

- READ_ONCE/WRITE_ONCE cause problems in lots of code
- typecheck() causes huge problems in a few places
- I'm introducing "noinline_for_kasan" and use it in a lot
  of places that suffer from inline functions with local variables
  - netlink, as used in various parts of the kernel
  - a number of drivers/media drivers
  - a handful of wireless network drivers
- kmemcheck conflicts with -fsanitize-address-use-after-scope

This series lets us add back a stack frame warning for 3072 bytes
with -fsanitize-address-use-after-scope, or 2048 bytes without it.

I have a follow-up series that further reduces the stack frame
warning limit to 1280 bytes for all 64-bit architectures, and
1536 bytes with basic KASAN support (no -fsanitize-address-use-after-scope).
For now, I'm only posting the first half, in order to keep
it (barely) reviewable.

Both series are tested with many hundred randconfig builds on both
x86 and arm64, which are the only architectures supporting KASAN.

Arnd 

 [PATCH 01/26] compiler: introduce noinline_for_kasan annotation
 [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
 [PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro
 [PATCH 04/26] tty: kbd: reduce stack size with KASAN
 [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan
 [PATCH 06/26] rocker: mark rocker_tlv_put_* functions as
 [PATCH 07/26] brcmsmac: reduce stack size with KASAN
 [PATCH 08/26] brcmsmac: make some local variables 'static const' to
 [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy
 [PATCH 10/26] brcmsmac: reindent split functions
 [PATCH 11/26] rtlwifi: reduce stack usage for KASAN
 [PATCH 12/26] wl3501_cs: reduce stack size for KASAN
 [PATCH 13/26] rtl8180: reduce stack size for KASAN
 [PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access
 [PATCH 15/26] [media] tuners: i2c: reduce stack usage for
 [PATCH 16/26] [media] i2c: adv7604: mark register access as
 [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN
 [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN
 [PATCH 19/26] [media] r820t: mark register functions as
 [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce
 [PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN
 [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with
 [PATCH 23/26] mtd: cfi: reduce stack size with KASAN
 [PATCH 24/26] ocfs2: reduce stack size with KASAN
 [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan
 [PATCH 26/26] kasan: rework Kconfig settings

 arch/x86/include/asm/switch_to.h |2 +-
 drivers/gpu/drm/bridge/parade-ps8622.c   |2 +-
 drivers/gpu/drm/i915/gvt/mmio.h  |   17 +-
 drivers/isdn/hardware/eicon/Kconfig  |1 +
 drivers/media/dvb-frontends/ascot2e.c|3 +-
 drivers/media/dvb-frontends/cxd2841er.c  |4 +-
 drivers/media/dvb-frontends/drx39xyj/drxj.c  |   14 +-
 drivers/media/dvb-frontends/helene.c |4 +-
 drivers/media/dvb-frontends/horus3a.c|2 +-
 drivers/media/dvb-frontends/itd1000.c|2 +-
 drivers/media/dvb-frontends/mt312.c  |2 +-
 drivers/media/dvb-frontends/si2165.c |   14 +-
 drivers/media/dvb-frontends/stb0899_drv.c|2 +-
 drivers/media/dvb-frontends/stb6100.c|2 +-
 drivers/media/dvb-frontends/stv0367.c|2 +-
 drivers/media/dvb-frontends/stv090x.c|2 +-
 drivers/media/dvb-frontends/stv6110.c|2 +-
 drivers/media/dvb-frontends/stv6110x.c   |2 +-
 drivers/media/dvb-frontends/tda8083.c|2 +-
 drivers/media/dvb-frontends/zl10039.c|2 +-
 drivers/media/i2c/adv7604.c  |4 +-
 drivers/media/i2c/cx25840/cx25840-core.c |4 +-
 drivers/media/i2c/ks0127.c   |2 +-
 drivers/media/tuners/r820t.c |4 +-
 drivers/media/tuners/tuner-i2c.h |   15 +-
 drivers/media/usb/em28xx/em28xx-dvb.c|  947 
+--
 

[PATCH 04/26] tty: kbd: reduce stack size with KASAN

[Arnd Bergmann]

As reported by kernelci, some functions in the VT code use significant
amounts of kernel stack when local variables get inlined into the caller
multiple times:

drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger 
than 2048 bytes [-Werror=frame-larger-than=]

Annotating those functions as noinline_for_kasan prevents the inlining
and reduces the overall stack usage in this driver.

Signed-off-by: Arnd Bergmann 
---
 drivers/tty/vt/keyboard.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 397e1509fe51..f8a183c1639f 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -300,13 +300,13 @@ int kbd_rate(struct kbd_repeat *rpt)
 /*
  * Helper Functions.
  */
-static void put_queue(struct vc_data *vc, int ch)
+static noinline_for_kasan void put_queue(struct vc_data *vc, int ch)
 {
tty_insert_flip_char(>port, ch, 0);
tty_schedule_flip(>port);
 }
 
-static void puts_queue(struct vc_data *vc, char *cp)
+static noinline_for_kasan void puts_queue(struct vc_data *vc, char *cp)
 {
while (*cp) {
tty_insert_flip_char(>port, *cp, 0);
@@ -554,7 +554,7 @@ static void fn_inc_console(struct vc_data *vc)
set_console(i);
 }
 
-static void fn_send_intr(struct vc_data *vc)
+static noinline_for_kasan void fn_send_intr(struct vc_data *vc)
 {
tty_insert_flip_char(>port, 0, TTY_BREAK);
tty_schedule_flip(>port);
-- 
2.9.0

[PATCH 12/26] wl3501_cs: reduce stack size for KASAN

[Arnd Bergmann]

Inlining functions with local variables can lead to excessive stack usage
with KASAN:

drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt':
drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is 
larger than 1536 bytes [-Werror=frame-larger-than=]

Marking a few functions as noinline_for_kasan avoids the problem

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/wl3501_cs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index acec0d9ec422..15dd8e31d373 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -242,8 +242,8 @@ static int wl3501_get_flash_mac_addr(struct wl3501_card 
*this)
  *
  * Move 'size' bytes from PC to card. (Shouldn't be interrupted)
  */
-static void wl3501_set_to_wla(struct wl3501_card *this, u16 dest, void *src,
- int size)
+static noinline_for_kasan void wl3501_set_to_wla(struct wl3501_card *this,
+u16 dest, void *src, int size)
 {
/* switch to SRAM Page 0 */
wl3501_switch_page(this, (dest & 0x8000) ? WL3501_BSS_SPAGE1 :
@@ -264,8 +264,8 @@ static void wl3501_set_to_wla(struct wl3501_card *this, u16 
dest, void *src,
  *
  * Move 'size' bytes from card to PC. (Shouldn't be interrupted)
  */
-static void wl3501_get_from_wla(struct wl3501_card *this, u16 src, void *dest,
-   int size)
+static noinline_for_kasan void wl3501_get_from_wla(struct wl3501_card *this,
+   u16 src, void *dest, int size)
 {
/* switch to SRAM Page 0 */
wl3501_switch_page(this, (src & 0x8000) ? WL3501_BSS_SPAGE1 :
@@ -1037,7 +1037,7 @@ static inline void wl3501_auth_confirm_interrupt(struct 
wl3501_card *this,
wl3501_mgmt_resync(this);
 }
 
-static inline void wl3501_rx_interrupt(struct net_device *dev)
+static noinline_for_kasan void wl3501_rx_interrupt(struct net_device *dev)
 {
int morepkts;
u16 addr;
-- 
2.9.0

[PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

[Arnd Bergmann]

With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:

broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 
3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 
2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.

Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 197 ++---
 1 file changed, 97 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 42dc8e1f483d..48a4df488d75 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void 
wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
 }
 
 static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
-  u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+  const u8 *dlys, u8 len)
 {
u32 t1_offset, t2_offset;
u8 ctr;
@@ -15240,16 +15240,16 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
 static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 {
u16 currband;
-   s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
-   s8 *lna1_gain_db = NULL;
-   s8 *lna1_gain_db_2 = NULL;
-   s8 *lna2_gain_db = NULL;
-   s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
-   s8 *tia_gain_db;
-   s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
-   s8 *tia_gainbits;
-   u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
-   u16 *rfseq_init_gain;
+   static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+   const s8 *lna1_gain_db = NULL;
+   const s8 *lna1_gain_db_2 = NULL;
+   const s8 *lna2_gain_db = NULL;
+   static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 
};
+   const s8 *tia_gain_db;
+   static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+   const s8 *tia_gainbits;
+   static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+   const u16 *rfseq_init_gain;
u16 init_gaincode;
u16 clip1hi_gaincode;
u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
 
if ((freq <= 5080) || (freq == 5825)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   11, 17, 22, 25};
-   s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
16, 20, 24 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 11, 
17, 22, 25};
+   static const s8 lna2A_gain_db_rev7[] = { -1, 6, 
10, 14 };
 
crsminu_th = 0x3e;
lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else if ((freq >= 5500) && (freq <= 5700)) {
 
-   s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   12, 18, 22, 26};
-   s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+   static const s8 lna1A_gain_db_rev7[] = { 11, 
17, 21, 25 };
+   static const s8 lna1A_gain_db_2_rev7[] = { 12, 
18, 22, 26};
+   static const s8 lna2A_gain_db_rev7[] = { 1, 8, 
12, 16 };
 
crsminu_th = 0x45;
clip1md_gaincode_B = 0x14;
@@ -15335,10 +15333,9 @@ static void 
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else {
 
-   s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
-   s8 lna1A_gain_db_2_rev7[] = {
-   12, 18, 22, 

[PATCH 00/26] bring back stack frame warning with KASAN

[Arnd Bergmann]

It took a long while to get this done, but I'm finally ready
to send the first half of the KASAN stack size patches that
I did in response to the kernelci.org warnings.

As before, it's worth mentioning that things are generally worse
with gcc-7.0.1 because of the addition of -fsanitize-address-use-after-scope
that are not present on kernelci, so my randconfig testing found
a lot more than kernelci did.

The main areas are:

- READ_ONCE/WRITE_ONCE cause problems in lots of code
- typecheck() causes huge problems in a few places
- I'm introducing "noinline_for_kasan" and use it in a lot
  of places that suffer from inline functions with local variables
  - netlink, as used in various parts of the kernel
  - a number of drivers/media drivers
  - a handful of wireless network drivers
- kmemcheck conflicts with -fsanitize-address-use-after-scope

This series lets us add back a stack frame warning for 3072 bytes
with -fsanitize-address-use-after-scope, or 2048 bytes without it.

I have a follow-up series that further reduces the stack frame
warning limit to 1280 bytes for all 64-bit architectures, and
1536 bytes with basic KASAN support (no -fsanitize-address-use-after-scope).
For now, I'm only posting the first half, in order to keep
it (barely) reviewable.

Both series are tested with many hundred randconfig builds on both
x86 and arm64, which are the only architectures supporting KASAN.

Arnd 

 [PATCH 01/26] compiler: introduce noinline_for_kasan annotation
 [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
 [PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro
 [PATCH 04/26] tty: kbd: reduce stack size with KASAN
 [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan
 [PATCH 06/26] rocker: mark rocker_tlv_put_* functions as
 [PATCH 07/26] brcmsmac: reduce stack size with KASAN
 [PATCH 08/26] brcmsmac: make some local variables 'static const' to
 [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy
 [PATCH 10/26] brcmsmac: reindent split functions
 [PATCH 11/26] rtlwifi: reduce stack usage for KASAN
 [PATCH 12/26] wl3501_cs: reduce stack size for KASAN
 [PATCH 13/26] rtl8180: reduce stack size for KASAN
 [PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access
 [PATCH 15/26] [media] tuners: i2c: reduce stack usage for
 [PATCH 16/26] [media] i2c: adv7604: mark register access as
 [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN
 [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN
 [PATCH 19/26] [media] r820t: mark register functions as
 [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce
 [PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN
 [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with
 [PATCH 23/26] mtd: cfi: reduce stack size with KASAN
 [PATCH 24/26] ocfs2: reduce stack size with KASAN
 [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan
 [PATCH 26/26] kasan: rework Kconfig settings

 arch/x86/include/asm/switch_to.h |2 +-
 drivers/gpu/drm/bridge/parade-ps8622.c   |2 +-
 drivers/gpu/drm/i915/gvt/mmio.h  |   17 +-
 drivers/isdn/hardware/eicon/Kconfig  |1 +
 drivers/media/dvb-frontends/ascot2e.c|3 +-
 drivers/media/dvb-frontends/cxd2841er.c  |4 +-
 drivers/media/dvb-frontends/drx39xyj/drxj.c  |   14 +-
 drivers/media/dvb-frontends/helene.c |4 +-
 drivers/media/dvb-frontends/horus3a.c|2 +-
 drivers/media/dvb-frontends/itd1000.c|2 +-
 drivers/media/dvb-frontends/mt312.c  |2 +-
 drivers/media/dvb-frontends/si2165.c |   14 +-
 drivers/media/dvb-frontends/stb0899_drv.c|2 +-
 drivers/media/dvb-frontends/stb6100.c|2 +-
 drivers/media/dvb-frontends/stv0367.c|2 +-
 drivers/media/dvb-frontends/stv090x.c|2 +-
 drivers/media/dvb-frontends/stv6110.c|2 +-
 drivers/media/dvb-frontends/stv6110x.c   |2 +-
 drivers/media/dvb-frontends/tda8083.c|2 +-
 drivers/media/dvb-frontends/zl10039.c|2 +-
 drivers/media/i2c/adv7604.c  |4 +-
 drivers/media/i2c/cx25840/cx25840-core.c |4 +-
 drivers/media/i2c/ks0127.c   |2 +-
 drivers/media/tuners/r820t.c |4 +-
 drivers/media/tuners/tuner-i2c.h |   15 +-
 drivers/media/usb/em28xx/em28xx-dvb.c|  947 
+--
 

[PATCH 04/26] tty: kbd: reduce stack size with KASAN

[Arnd Bergmann]

As reported by kernelci, some functions in the VT code use significant
amounts of kernel stack when local variables get inlined into the caller
multiple times:

drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger 
than 2048 bytes [-Werror=frame-larger-than=]

Annotating those functions as noinline_for_kasan prevents the inlining
and reduces the overall stack usage in this driver.

Signed-off-by: Arnd Bergmann 
---
 drivers/tty/vt/keyboard.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index 397e1509fe51..f8a183c1639f 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -300,13 +300,13 @@ int kbd_rate(struct kbd_repeat *rpt)
 /*
  * Helper Functions.
  */
-static void put_queue(struct vc_data *vc, int ch)
+static noinline_for_kasan void put_queue(struct vc_data *vc, int ch)
 {
tty_insert_flip_char(>port, ch, 0);
tty_schedule_flip(>port);
 }
 
-static void puts_queue(struct vc_data *vc, char *cp)
+static noinline_for_kasan void puts_queue(struct vc_data *vc, char *cp)
 {
while (*cp) {
tty_insert_flip_char(>port, *cp, 0);
@@ -554,7 +554,7 @@ static void fn_inc_console(struct vc_data *vc)
set_console(i);
 }
 
-static void fn_send_intr(struct vc_data *vc)
+static noinline_for_kasan void fn_send_intr(struct vc_data *vc)
 {
tty_insert_flip_char(>port, 0, TTY_BREAK);
tty_schedule_flip(>port);
-- 
2.9.0

[PATCH 1/4] Staging:wilc1000:wilc_spi: Fixed comment style to the preferred kernel comment style

[Georgios Emmanouil]

Fixed comment style to the preferred kernel comment style.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_spi.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 55d53c3..6bd4047 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -1,11 +1,9 @@
-/* // 
*/
-/*  */
-/* Copyright (c) Atmel Corporation.  All rights reserved. */
-/*  */
-/* Module Name:  wilc_spi.c */
-/*  */
-/*  */
-/* 
 */
+/*
+ * Copyright (c) Atmel Corporation.  All rights reserved.
+ *
+ * Module Name:  wilc_spi.c
+ */
+
 #include 
 #include 
 #include 
--
2.1.4

[PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan

[Arnd Bergmann]

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
stack frames in some functions. This goes unnoticed normally because
CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
KASAN=y").

The kernelci.org build bot however has the warning enabled and that led
me to investigate it a little further, as every build produces these warnings:

net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

With the new noinline_for_kasan annotation, we can avoid the problem
when KASAN is enabled but not change anything otherwise.

Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: kasan-...@googlegroups.com
Signed-off-by: Arnd Bergmann 
---
 include/net/netlink.h | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/net/netlink.h b/include/net/netlink.h
index b239fcd33d80..d84878d8347f 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -755,7 +755,7 @@ static inline int nla_parse_nested(struct nlattr *tb[], int 
maxtype,
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
+static noinline_for_kasan int nla_put_u8(struct sk_buff *skb, int attrtype, u8 
value)
 {
return nla_put(skb, attrtype, sizeof(u8), );
 }
@@ -766,7 +766,7 @@ static inline int nla_put_u8(struct sk_buff *skb, int 
attrtype, u8 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value)
+static noinline_for_kasan int nla_put_u16(struct sk_buff *skb, int attrtype, 
u16 value)
 {
return nla_put(skb, attrtype, sizeof(u16), );
 }
@@ -777,7 +777,7 @@ static inline int nla_put_u16(struct sk_buff *skb, int 
attrtype, u16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value)
+static noinline_for_kasan int nla_put_be16(struct sk_buff *skb, int attrtype, 
__be16 value)
 {
return nla_put(skb, attrtype, sizeof(__be16), );
 }
@@ -788,7 +788,7 @@ static inline int nla_put_be16(struct sk_buff *skb, int 
attrtype, __be16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16 
value)
+static noinline_for_kasan int nla_put_net16(struct sk_buff *skb, int attrtype, 
__be16 value)
 {
return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value);
 }
@@ -799,7 +799,7 @@ static inline int nla_put_net16(struct sk_buff *skb, int 
attrtype, __be16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value)
+static noinline_for_kasan int nla_put_le16(struct sk_buff *skb, int attrtype, 
__le16 value)
 {
return nla_put(skb, attrtype, sizeof(__le16), );
 }
@@ -810,7 +810,7 @@ static inline int nla_put_le16(struct sk_buff *skb, int 
attrtype, __le16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
+static noinline_for_kasan int nla_put_u32(struct sk_buff *skb, int attrtype, 
u32 value)
 {
return nla_put(skb, attrtype, sizeof(u32), );
 }
@@ -821,7 +821,7 @@ static inline int nla_put_u32(struct sk_buff *skb, int 
attrtype, u32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value)
+static noinline_for_kasan int nla_put_be32(struct sk_buff *skb, int attrtype, 
__be32 value)
 {
return nla_put(skb, attrtype, sizeof(__be32), );
 }
@@ -832,7 +832,7 @@ static inline int nla_put_be32(struct sk_buff *skb, int 
attrtype, __be32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32 
value)
+static noinline_for_kasan int nla_put_net32(struct sk_buff *skb, int attrtype, 
__be32 value)
 {
return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value);
 }
@@ -843,7 +843,7 @@ static inline int nla_put_net32(struct sk_buff *skb, int 
attrtype, __be32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 value)
+static noinline_for_kasan int 

[PATCH 1/4] Staging:wilc1000:wilc_spi: Fixed comment style to the preferred kernel comment style

[Georgios Emmanouil]

Fixed comment style to the preferred kernel comment style.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_spi.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 55d53c3..6bd4047 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -1,11 +1,9 @@
-/* // 
*/
-/*  */
-/* Copyright (c) Atmel Corporation.  All rights reserved. */
-/*  */
-/* Module Name:  wilc_spi.c */
-/*  */
-/*  */
-/* 
 */
+/*
+ * Copyright (c) Atmel Corporation.  All rights reserved.
+ *
+ * Module Name:  wilc_spi.c
+ */
+
 #include 
 #include 
 #include 
--
2.1.4

[PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan

[Arnd Bergmann]

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
stack frames in some functions. This goes unnoticed normally because
CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
KASAN=y").

The kernelci.org build bot however has the warning enabled and that led
me to investigate it a little further, as every build produces these warnings:

net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

With the new noinline_for_kasan annotation, we can avoid the problem
when KASAN is enabled but not change anything otherwise.

Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: kasan-...@googlegroups.com
Signed-off-by: Arnd Bergmann 
---
 include/net/netlink.h | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/net/netlink.h b/include/net/netlink.h
index b239fcd33d80..d84878d8347f 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -755,7 +755,7 @@ static inline int nla_parse_nested(struct nlattr *tb[], int 
maxtype,
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
+static noinline_for_kasan int nla_put_u8(struct sk_buff *skb, int attrtype, u8 
value)
 {
return nla_put(skb, attrtype, sizeof(u8), );
 }
@@ -766,7 +766,7 @@ static inline int nla_put_u8(struct sk_buff *skb, int 
attrtype, u8 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value)
+static noinline_for_kasan int nla_put_u16(struct sk_buff *skb, int attrtype, 
u16 value)
 {
return nla_put(skb, attrtype, sizeof(u16), );
 }
@@ -777,7 +777,7 @@ static inline int nla_put_u16(struct sk_buff *skb, int 
attrtype, u16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value)
+static noinline_for_kasan int nla_put_be16(struct sk_buff *skb, int attrtype, 
__be16 value)
 {
return nla_put(skb, attrtype, sizeof(__be16), );
 }
@@ -788,7 +788,7 @@ static inline int nla_put_be16(struct sk_buff *skb, int 
attrtype, __be16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16 
value)
+static noinline_for_kasan int nla_put_net16(struct sk_buff *skb, int attrtype, 
__be16 value)
 {
return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value);
 }
@@ -799,7 +799,7 @@ static inline int nla_put_net16(struct sk_buff *skb, int 
attrtype, __be16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value)
+static noinline_for_kasan int nla_put_le16(struct sk_buff *skb, int attrtype, 
__le16 value)
 {
return nla_put(skb, attrtype, sizeof(__le16), );
 }
@@ -810,7 +810,7 @@ static inline int nla_put_le16(struct sk_buff *skb, int 
attrtype, __le16 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
+static noinline_for_kasan int nla_put_u32(struct sk_buff *skb, int attrtype, 
u32 value)
 {
return nla_put(skb, attrtype, sizeof(u32), );
 }
@@ -821,7 +821,7 @@ static inline int nla_put_u32(struct sk_buff *skb, int 
attrtype, u32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value)
+static noinline_for_kasan int nla_put_be32(struct sk_buff *skb, int attrtype, 
__be32 value)
 {
return nla_put(skb, attrtype, sizeof(__be32), );
 }
@@ -832,7 +832,7 @@ static inline int nla_put_be32(struct sk_buff *skb, int 
attrtype, __be32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32 
value)
+static noinline_for_kasan int nla_put_net32(struct sk_buff *skb, int attrtype, 
__be32 value)
 {
return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value);
 }
@@ -843,7 +843,7 @@ static inline int nla_put_net32(struct sk_buff *skb, int 
attrtype, __be32 value)
  * @attrtype: attribute type
  * @value: numeric value
  */
-static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 value)
+static noinline_for_kasan int nla_put_le32(struct sk_buff *skb, int attrtype, 
__le32 value)
 {
return 

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

[Daniel Vetter]

On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote:
> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
> in combination with a very custom PHY.
> 
> This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2
> patchset at [2] to permit PHY control from outside the dw-hdmi driver.
> 
> The Synopsys DesignWare HDMI TX Controller is integrated like :
>  ___
> |HDMI TOP   |<= HPD
> |___|
> |  ||
> HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
> |Controller||
> |___|<=> DDC
> 
> And uses the following paths for Pixels Encoding :
>_   _   
> vd1---| |-| | | VENC /-|VDAC
> vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
> osd1--| |-| | | \  | X--HDMI-TX
> osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
>   |  | |
>   |  \--ENCL---|LVDS
>   ||
> 
> The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
> ENCP-DVI encoders. Those DVI encoders will format the pixels for the
> Synopsys DesignWare HDMI TX Controller.
> 
> In order to support display modes, the ENCI and ENCP encoders needs very
> specific parameters for *each* display modes, so usage of the CEA VIC
> identifier is necessary. But the DVI timings are generated from the
> drm_mode structure in a generic way.
> 
> To simplify the first push, only the main CEA modes are supported up to
> 1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
> in order to support the Clock Doubling necessary for these modes.
> 
> Support for more traditional modes like the EDID fallback modes is planned
> but will need tome additionnal handling along the CEA modes.
> Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
> for now only the HDMI 1.4 modes are currently available in the drm_edid
> implementation.

Btw, with the neat ascii-art stuff here and in comments in your code, did
you look into assembling all that into a meson driver documentation
chapter like the one for vc4 that was just merged?
-Daniel

> 
> This patchset does :
>  - Fixes the CRTC handling
>  - Fixes the registers definitions
>  - Adds support for device components registration along of-graph
>  - Adds support for HDMI clocks
>  - Adds support for HDMI VENC video modes
>  - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
>  - Adds CMA node to reserve enougth memory for 1080p display
>  - Adds the HDMI controller et connector modes on selected boards
>  - Adds a proper dt-bindings for the HDMI controller et connector
>  - Updates the MAINTAINERS file to track the new files
> 
> [1] 
> http://lkml.kernel.org/r/20170301223915.29888-1-laurent.pinchart+rene...@ideasonboard.com
> [2] 
> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
> 
> Neil Armstrong (11):
>   drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
> sync for vsync commit
>   drm/meson: Add missing HDMI register
>   drm/meson: Add support for components
>   drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
>   drm/meson: add support for HDMI clock support
>   drm/meson: Add support for HDMI venc modes and settings
>   drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
>   ARM64: dts: meson-gx: Add shared CMA dma memory pool
>   ARM64: dts: meson-gx: Add support for HDMI output
>   dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
>   MAINTAINERS: update files for Amlogic DRM Driver
> 
>  .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
>  MAINTAINERS|1 +
>  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
>  .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
>  .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
>  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |4 +
>  drivers/gpu/drm/meson/Kconfig  |6 +
>  drivers/gpu/drm/meson/Makefile |1 +
>  drivers/gpu/drm/meson/meson_crtc.c |   15 +-
>  drivers/gpu/drm/meson/meson_drv.c  |  113 +-
>  drivers/gpu/drm/meson/meson_drv.h  |3 +
>  drivers/gpu/drm/meson/meson_dw_hdmi.c  |  918 +++
>  drivers/gpu/drm/meson/meson_dw_hdmi.h  | 

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

[Daniel Vetter]

On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote:
> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
> in combination with a very custom PHY.
> 
> This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2
> patchset at [2] to permit PHY control from outside the dw-hdmi driver.
> 
> The Synopsys DesignWare HDMI TX Controller is integrated like :
>  ___
> |HDMI TOP   |<= HPD
> |___|
> |  ||
> HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
> |Controller||
> |___|<=> DDC
> 
> And uses the following paths for Pixels Encoding :
>_   _   
> vd1---| |-| | | VENC /-|VDAC
> vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
> osd1--| |-| | | \  | X--HDMI-TX
> osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
>   |  | |
>   |  \--ENCL---|LVDS
>   ||
> 
> The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
> ENCP-DVI encoders. Those DVI encoders will format the pixels for the
> Synopsys DesignWare HDMI TX Controller.
> 
> In order to support display modes, the ENCI and ENCP encoders needs very
> specific parameters for *each* display modes, so usage of the CEA VIC
> identifier is necessary. But the DVI timings are generated from the
> drm_mode structure in a generic way.
> 
> To simplify the first push, only the main CEA modes are supported up to
> 1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
> in order to support the Clock Doubling necessary for these modes.
> 
> Support for more traditional modes like the EDID fallback modes is planned
> but will need tome additionnal handling along the CEA modes.
> Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
> for now only the HDMI 1.4 modes are currently available in the drm_edid
> implementation.

Btw, with the neat ascii-art stuff here and in comments in your code, did
you look into assembling all that into a meson driver documentation
chapter like the one for vc4 that was just merged?
-Daniel

> 
> This patchset does :
>  - Fixes the CRTC handling
>  - Fixes the registers definitions
>  - Adds support for device components registration along of-graph
>  - Adds support for HDMI clocks
>  - Adds support for HDMI VENC video modes
>  - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
>  - Adds CMA node to reserve enougth memory for 1080p display
>  - Adds the HDMI controller et connector modes on selected boards
>  - Adds a proper dt-bindings for the HDMI controller et connector
>  - Updates the MAINTAINERS file to track the new files
> 
> [1] 
> http://lkml.kernel.org/r/20170301223915.29888-1-laurent.pinchart+rene...@ideasonboard.com
> [2] 
> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
> 
> Neil Armstrong (11):
>   drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
> sync for vsync commit
>   drm/meson: Add missing HDMI register
>   drm/meson: Add support for components
>   drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
>   drm/meson: add support for HDMI clock support
>   drm/meson: Add support for HDMI venc modes and settings
>   drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
>   ARM64: dts: meson-gx: Add shared CMA dma memory pool
>   ARM64: dts: meson-gx: Add support for HDMI output
>   dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
>   MAINTAINERS: update files for Amlogic DRM Driver
> 
>  .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
>  MAINTAINERS|1 +
>  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
>  .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
>  .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
>  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |4 +
>  drivers/gpu/drm/meson/Kconfig  |6 +
>  drivers/gpu/drm/meson/Makefile |1 +
>  drivers/gpu/drm/meson/meson_crtc.c |   15 +-
>  drivers/gpu/drm/meson/meson_drv.c  |  113 +-
>  drivers/gpu/drm/meson/meson_drv.h  |3 +
>  drivers/gpu/drm/meson/meson_dw_hdmi.c  |  918 +++
>  drivers/gpu/drm/meson/meson_dw_hdmi.h  | 

[PATCH 07/26] brcmsmac: reduce stack size with KASAN

[Arnd Bergmann]

The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an 
object
on the stack, which will each require a redzone with KASAN and lead to possible
stack overflow:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 
'wlc_phy_workarounds_nphy':
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: warning: 
the frame size of 6312 bytes is larger than 1000 bytes [-Wframe-larger-than=]

This marks the two functions as noinline_for_kasan, avoiding the problem 
entirely.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index b3aab2fe96eb..42dc8e1f483d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14157,7 +14157,7 @@ static void wlc_phy_bphy_init_nphy(struct brcms_phy *pi)
write_phy_reg(pi, NPHY_TO_BPHY_OFF + BPHY_STEP, 0x668);
 }
 
-void
+noinline_for_kasan void
 wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset,
 u32 width, const void *data)
 {
@@ -14171,7 +14171,7 @@ wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, 
u32 len, u32 offset,
wlc_phy_write_table_nphy(pi, );
 }
 
-void
+noinline_for_kasan void
 wlc_phy_table_read_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset,
u32 width, void *data)
 {
-- 
2.9.0

[PATCH 07/26] brcmsmac: reduce stack size with KASAN

[Arnd Bergmann]

The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an 
object
on the stack, which will each require a redzone with KASAN and lead to possible
stack overflow:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 
'wlc_phy_workarounds_nphy':
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: warning: 
the frame size of 6312 bytes is larger than 1000 bytes [-Wframe-larger-than=]

This marks the two functions as noinline_for_kasan, avoiding the problem 
entirely.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index b3aab2fe96eb..42dc8e1f483d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14157,7 +14157,7 @@ static void wlc_phy_bphy_init_nphy(struct brcms_phy *pi)
write_phy_reg(pi, NPHY_TO_BPHY_OFF + BPHY_STEP, 0x668);
 }
 
-void
+noinline_for_kasan void
 wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset,
 u32 width, const void *data)
 {
@@ -14171,7 +14171,7 @@ wlc_phy_table_write_nphy(struct brcms_phy *pi, u32 id, 
u32 len, u32 offset,
wlc_phy_write_table_nphy(pi, );
 }
 
-void
+noinline_for_kasan void
 wlc_phy_table_read_nphy(struct brcms_phy *pi, u32 id, u32 len, u32 offset,
u32 width, void *data)
 {
-- 
2.9.0

[PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan

[Arnd Bergmann]

Inlining these functions creates lots of stack variables when KASAN is
enabled, leading to this warning about potential stack overflow:

drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 
'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 
bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

This marks all of them noinline_for_kasan, which solves the problem by
keeping the redzone inside of the separate stack frames.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/rocker/rocker_tlv.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/rocker/rocker_tlv.h 
b/drivers/net/ethernet/rocker/rocker_tlv.h
index a63ef82e7c72..3a9573fe0191 100644
--- a/drivers/net/ethernet/rocker/rocker_tlv.h
+++ b/drivers/net/ethernet/rocker/rocker_tlv.h
@@ -139,38 +139,38 @@ rocker_tlv_start(struct rocker_desc_info *desc_info)
 int rocker_tlv_put(struct rocker_desc_info *desc_info,
   int attrtype, int attrlen, const void *data);
 
-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info,
-   int attrtype, u8 value)
+static noinline_for_kasan int
+rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u8), );
 }
 
-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info,
-int attrtype, u16 value)
+static noinline_for_kasan int
+rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u16), );
 }
 
-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info,
- int attrtype, __be16 value)
+static noinline_for_kasan int
+rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16 
value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), );
 }
 
-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info,
-int attrtype, u32 value)
+static noinline_for_kasan int
+rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u32), );
 }
 
-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info,
- int attrtype, __be32 value)
+static noinline_for_kasan int
+rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32 
value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), );
 }
 
-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info,
-int attrtype, u64 value)
+static noinline_for_kasan int
+rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u64), );
 }
-- 
2.9.0

[PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan

[Arnd Bergmann]

Inlining these functions creates lots of stack variables when KASAN is
enabled, leading to this warning about potential stack overflow:

drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 
'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 
bytes is larger than 1536 bytes [-Werror=frame-larger-than=]

This marks all of them noinline_for_kasan, which solves the problem by
keeping the redzone inside of the separate stack frames.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/rocker/rocker_tlv.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/rocker/rocker_tlv.h 
b/drivers/net/ethernet/rocker/rocker_tlv.h
index a63ef82e7c72..3a9573fe0191 100644
--- a/drivers/net/ethernet/rocker/rocker_tlv.h
+++ b/drivers/net/ethernet/rocker/rocker_tlv.h
@@ -139,38 +139,38 @@ rocker_tlv_start(struct rocker_desc_info *desc_info)
 int rocker_tlv_put(struct rocker_desc_info *desc_info,
   int attrtype, int attrlen, const void *data);
 
-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info,
-   int attrtype, u8 value)
+static noinline_for_kasan int
+rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u8), );
 }
 
-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info,
-int attrtype, u16 value)
+static noinline_for_kasan int
+rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u16), );
 }
 
-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info,
- int attrtype, __be16 value)
+static noinline_for_kasan int
+rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16 
value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), );
 }
 
-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info,
-int attrtype, u32 value)
+static noinline_for_kasan int
+rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u32), );
 }
 
-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info,
- int attrtype, __be32 value)
+static noinline_for_kasan int
+rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32 
value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), );
 }
 
-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info,
-int attrtype, u64 value)
+static noinline_for_kasan int
+rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value)
 {
return rocker_tlv_put(desc_info, attrtype, sizeof(u64), );
 }
-- 
2.9.0

[PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro

[Arnd Bergmann]

With KASAN enabled, the typecheck macro leads to some serious stack memory,
as seen in the rt2xxx drivers:

drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_init_registers':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5068:1: error: the frame size of 
23768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_config_txpower_rt3593.isra.1':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4126:1: error: the frame size of 
14184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_config_channel_rf3053.isra.5':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2585:1: error: the frame size of 
7632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

If we express the macro in a way that avoids the local variables, this goes
away and the stacks are comparable to building without KASAN.

Signed-off-by: Arnd Bergmann 
---
 include/linux/typecheck.h | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/include/linux/typecheck.h b/include/linux/typecheck.h
index eb5b74a575be..adb1579fa5f0 100644
--- a/include/linux/typecheck.h
+++ b/include/linux/typecheck.h
@@ -5,12 +5,7 @@
  * Check at compile time that something is of a particular type.
  * Always evaluates to 1 so you may use it easily in comparisons.
  */
-#define typecheck(type,x) \
-({ type __dummy; \
-   typeof(x) __dummy2; \
-   (void)(&__dummy == &__dummy2); \
-   1; \
-})
+#define typecheck(type,x) ({(void)((typeof(type) *)NULL == (typeof(x) *)NULL); 
1;})
 
 /*
  * Check at compile time that 'function' is a certain type, or is a pointer
-- 
2.9.0

[PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro

[Arnd Bergmann]

With KASAN enabled, the typecheck macro leads to some serious stack memory,
as seen in the rt2xxx drivers:

drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_init_registers':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5068:1: error: the frame size of 
23768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_config_txpower_rt3593.isra.1':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4126:1: error: the frame size of 
14184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_config_channel_rf3053.isra.5':
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2585:1: error: the frame size of 
7632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

If we express the macro in a way that avoids the local variables, this goes
away and the stacks are comparable to building without KASAN.

Signed-off-by: Arnd Bergmann 
---
 include/linux/typecheck.h | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/include/linux/typecheck.h b/include/linux/typecheck.h
index eb5b74a575be..adb1579fa5f0 100644
--- a/include/linux/typecheck.h
+++ b/include/linux/typecheck.h
@@ -5,12 +5,7 @@
  * Check at compile time that something is of a particular type.
  * Always evaluates to 1 so you may use it easily in comparisons.
  */
-#define typecheck(type,x) \
-({ type __dummy; \
-   typeof(x) __dummy2; \
-   (void)(&__dummy == &__dummy2); \
-   1; \
-})
+#define typecheck(type,x) ({(void)((typeof(type) *)NULL == (typeof(x) *)NULL); 
1;})
 
 /*
  * Check at compile time that 'function' is a certain type, or is a pointer
-- 
2.9.0

[PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Arnd Bergmann]

When CONFIG_KASAN is set, we can run into some code that uses incredible
amounts of kernel stack:

drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

This happens when a sanitizer uses stack memory each time an inline function
gets called. This introduces a new annotation for those functions to make
them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol.

Signed-off-by: Arnd Bergmann 
---
 include/linux/compiler.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index f8110051188f..56b90897a459 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
  */
 #define noinline_for_stack noinline
 
+/*
+ * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
+ * one function gets inlined many times and each instance requires a stack
+ * ckeck.
+ */
+#ifdef CONFIG_KASAN
+#define noinline_for_kasan noinline __maybe_unused
+#else
+#define noinline_for_kasan inline
+#endif
+
 #ifndef __always_inline
 #define __always_inline inline
 #endif
-- 
2.9.0

[PATCH 01/26] compiler: introduce noinline_for_kasan annotation

[Arnd Bergmann]

When CONFIG_KASAN is set, we can run into some code that uses incredible
amounts of kernel stack:

drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

This happens when a sanitizer uses stack memory each time an inline function
gets called. This introduces a new annotation for those functions to make
them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol.

Signed-off-by: Arnd Bergmann 
---
 include/linux/compiler.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index f8110051188f..56b90897a459 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
  */
 #define noinline_for_stack noinline
 
+/*
+ * CONFIG_KASAN can lead to extreme stack usage with certain patterns when
+ * one function gets inlined many times and each instance requires a stack
+ * ckeck.
+ */
+#ifdef CONFIG_KASAN
+#define noinline_for_kasan noinline __maybe_unused
+#else
+#define noinline_for_kasan inline
+#endif
+
 #ifndef __always_inline
 #define __always_inline inline
 #endif
-- 
2.9.0

[PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_*

[Arnd Bergmann]

When CONFIG_KASAN is enabled, we see very large stack usage in some
functions, e.g.:

drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 3184 bytes is 
larger than 1024 bytes [-Wframe-larger-than=]
drivers/media/tuners/tda8290.c: In function 'tda829x_probe':
drivers/media/tuners/tda8290.c:878:1: warning: the frame size of 1088 bytes is 
larger than 1024 bytes [-Wframe-larger-than=]

By annotating the helpers as noinline_for_kasan, we can easily avoid this.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/tuner-i2c.h | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/media/tuners/tuner-i2c.h b/drivers/media/tuners/tuner-i2c.h
index bda67a5a76f2..c8970299799c 100644
--- a/drivers/media/tuners/tuner-i2c.h
+++ b/drivers/media/tuners/tuner-i2c.h
@@ -33,8 +33,8 @@ struct tuner_i2c_props {
char *name;
 };
 
-static inline int tuner_i2c_xfer_send(struct tuner_i2c_props *props,
- unsigned char *buf, int len)
+static noinline_for_kasan int
+tuner_i2c_xfer_send(struct tuner_i2c_props *props, unsigned char *buf, int len)
 {
struct i2c_msg msg = { .addr = props->addr, .flags = 0,
   .buf = buf, .len = len };
@@ -43,8 +43,8 @@ static inline int tuner_i2c_xfer_send(struct tuner_i2c_props 
*props,
return (ret == 1) ? len : ret;
 }
 
-static inline int tuner_i2c_xfer_recv(struct tuner_i2c_props *props,
- unsigned char *buf, int len)
+static noinline_for_kasan int
+tuner_i2c_xfer_recv(struct tuner_i2c_props *props, unsigned char *buf, int len)
 {
struct i2c_msg msg = { .addr = props->addr, .flags = I2C_M_RD,
   .buf = buf, .len = len };
@@ -53,9 +53,10 @@ static inline int tuner_i2c_xfer_recv(struct tuner_i2c_props 
*props,
return (ret == 1) ? len : ret;
 }
 
-static inline int tuner_i2c_xfer_send_recv(struct tuner_i2c_props *props,
-  unsigned char *obuf, int olen,
-  unsigned char *ibuf, int ilen)
+static noinline_for_kasan int
+tuner_i2c_xfer_send_recv(struct tuner_i2c_props *props,
+unsigned char *obuf, int olen,
+unsigned char *ibuf, int ilen)
 {
struct i2c_msg msg[2] = { { .addr = props->addr, .flags = 0,
.buf = obuf, .len = olen },
-- 
2.9.0

[PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

[Arnd Bergmann]

The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: 
the frame size of 1880 bytes is larger than 1536 bytes 
[-Werror=frame-larger-than=]

The affected function is actually a collection of three separate 
implementations,
and each of them is fairly large by itself. Splitting them up is done easily
and improves readability at the same time.

I'm leaving the original indentation to make the review easier.

Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 -
 1 file changed, 104 insertions(+), 74 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 48a4df488d75..d76c092bb6b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16061,52 +16061,8 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct 
brcms_phy *pi)
}
 }
 
-static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
+static void wlc_phy_workarounds_nphy_rev7(struct brcms_phy *pi)
 {
-   static const u8 rfseq_rx2tx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_EXT_PA
-   };
-   u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
-   static const u8 rfseq_tx2rx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_EXT_PA,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS
-   };
-   static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
-   static const u8 rfseq_tx2rx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
-   u8 rfseq_rx2tx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_NOP,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
-
static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
NPHY_REV3_RFSEQ_CMD_NOP,
NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16120,29 +16076,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
};
static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
-
-   s16 alpha0, alpha1, alpha2;
-   s16 beta0, beta1, beta2;
-   u32 leg_data_weights, ht_data_weights, nss1_data_weights,
-   stbc_data_weights;
+   u32 leg_data_weights;
u8 chan_freq_range = 0;
static const u16 dac_control = 0x0002;
u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
-   u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 aux_adc_vmid_rev3[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 *aux_adc_vmid;
u16 aux_adc_gain_rev7[] = { 0x02, 0x02, 0x02, 0x02 };
-   u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 *aux_adc_gain;
-   static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
-   static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
s32 min_nvar_val = 0x18d;
s32 min_nvar_offset_6mbps = 20;
u8 pdetrange;
-   u8 triso;
-   u16 regval;
u16 afectrl_adc_ctrl1_rev7 = 0x20;
u16 afectrl_adc_ctrl2_rev7 = 0x0;
u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
@@ -16171,17 +16113,6 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
u16 freq;
int coreNum;
 
-   if (CHSPEC_IS5G(pi->radio_chanspec))
-   wlc_phy_classifier_nphy(pi, NPHY_ClassifierCtrl_cck_en, 0);
-   else
- 

[PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_*

[Arnd Bergmann]

When CONFIG_KASAN is enabled, we see very large stack usage in some
functions, e.g.:

drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 3184 bytes is 
larger than 1024 bytes [-Wframe-larger-than=]
drivers/media/tuners/tda8290.c: In function 'tda829x_probe':
drivers/media/tuners/tda8290.c:878:1: warning: the frame size of 1088 bytes is 
larger than 1024 bytes [-Wframe-larger-than=]

By annotating the helpers as noinline_for_kasan, we can easily avoid this.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/tuner-i2c.h | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/media/tuners/tuner-i2c.h b/drivers/media/tuners/tuner-i2c.h
index bda67a5a76f2..c8970299799c 100644
--- a/drivers/media/tuners/tuner-i2c.h
+++ b/drivers/media/tuners/tuner-i2c.h
@@ -33,8 +33,8 @@ struct tuner_i2c_props {
char *name;
 };
 
-static inline int tuner_i2c_xfer_send(struct tuner_i2c_props *props,
- unsigned char *buf, int len)
+static noinline_for_kasan int
+tuner_i2c_xfer_send(struct tuner_i2c_props *props, unsigned char *buf, int len)
 {
struct i2c_msg msg = { .addr = props->addr, .flags = 0,
   .buf = buf, .len = len };
@@ -43,8 +43,8 @@ static inline int tuner_i2c_xfer_send(struct tuner_i2c_props 
*props,
return (ret == 1) ? len : ret;
 }
 
-static inline int tuner_i2c_xfer_recv(struct tuner_i2c_props *props,
- unsigned char *buf, int len)
+static noinline_for_kasan int
+tuner_i2c_xfer_recv(struct tuner_i2c_props *props, unsigned char *buf, int len)
 {
struct i2c_msg msg = { .addr = props->addr, .flags = I2C_M_RD,
   .buf = buf, .len = len };
@@ -53,9 +53,10 @@ static inline int tuner_i2c_xfer_recv(struct tuner_i2c_props 
*props,
return (ret == 1) ? len : ret;
 }
 
-static inline int tuner_i2c_xfer_send_recv(struct tuner_i2c_props *props,
-  unsigned char *obuf, int olen,
-  unsigned char *ibuf, int ilen)
+static noinline_for_kasan int
+tuner_i2c_xfer_send_recv(struct tuner_i2c_props *props,
+unsigned char *obuf, int olen,
+unsigned char *ibuf, int ilen)
 {
struct i2c_msg msg[2] = { { .addr = props->addr, .flags = 0,
.buf = obuf, .len = olen },
-- 
2.9.0

[PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

[Arnd Bergmann]

The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:

drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: 
the frame size of 1880 bytes is larger than 1536 bytes 
[-Werror=frame-larger-than=]

The affected function is actually a collection of three separate 
implementations,
and each of them is fairly large by itself. Splitting them up is done easily
and improves readability at the same time.

I'm leaving the original indentation to make the review easier.

Signed-off-by: Arnd Bergmann 
---
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 -
 1 file changed, 104 insertions(+), 74 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 48a4df488d75..d76c092bb6b4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16061,52 +16061,8 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct 
brcms_phy *pi)
}
 }
 
-static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
+static void wlc_phy_workarounds_nphy_rev7(struct brcms_phy *pi)
 {
-   static const u8 rfseq_rx2tx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_EXT_PA
-   };
-   u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
-   static const u8 rfseq_tx2rx_events[] = {
-   NPHY_RFSEQ_CMD_NOP,
-   NPHY_RFSEQ_CMD_EXT_PA,
-   NPHY_RFSEQ_CMD_TX_GAIN,
-   NPHY_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_RFSEQ_CMD_TR_SWITCH,
-   NPHY_RFSEQ_CMD_RXG_FBW,
-   NPHY_RFSEQ_CMD_CLR_HIQ_DIS
-   };
-   static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
-   static const u8 rfseq_tx2rx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
-   u8 rfseq_rx2tx_events_rev3[] = {
-   NPHY_REV3_RFSEQ_CMD_NOP,
-   NPHY_REV3_RFSEQ_CMD_RXG_FBW,
-   NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
-   NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
-   NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
-   NPHY_REV3_RFSEQ_CMD_TX_GAIN,
-   NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
-   NPHY_REV3_RFSEQ_CMD_EXT_PA,
-   NPHY_REV3_RFSEQ_CMD_END
-   };
-   u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
-
static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
NPHY_REV3_RFSEQ_CMD_NOP,
NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16120,29 +16076,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
};
static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43, 
1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
-
-   s16 alpha0, alpha1, alpha2;
-   s16 beta0, beta1, beta2;
-   u32 leg_data_weights, ht_data_weights, nss1_data_weights,
-   stbc_data_weights;
+   u32 leg_data_weights;
u8 chan_freq_range = 0;
static const u16 dac_control = 0x0002;
u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
-   u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 aux_adc_vmid_rev3[] = { 0xa2, 0xb4, 0xb4, 0x89 };
-   u16 *aux_adc_vmid;
u16 aux_adc_gain_rev7[] = { 0x02, 0x02, 0x02, 0x02 };
-   u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
-   u16 *aux_adc_gain;
-   static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
-   static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
s32 min_nvar_val = 0x18d;
s32 min_nvar_offset_6mbps = 20;
u8 pdetrange;
-   u8 triso;
-   u16 regval;
u16 afectrl_adc_ctrl1_rev7 = 0x20;
u16 afectrl_adc_ctrl2_rev7 = 0x0;
u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
@@ -16171,17 +16113,6 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy 
*pi)
u16 freq;
int coreNum;
 
-   if (CHSPEC_IS5G(pi->radio_chanspec))
-   wlc_phy_classifier_nphy(pi, NPHY_ClassifierCtrl_cck_en, 0);
-   else
-   

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

[Christoph Hellwig]

Hi Umesh,

it's linux-bl...@vger.kernel.org, and the place where all block layer
and driver development happens, you can subsribe to it using the
same way you subscribed to linux-kernel, just replacing the list name.

The latest released vesion at this point is Linux 4.10.

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

[Christoph Hellwig]

Hi Umesh,

it's linux-bl...@vger.kernel.org, and the place where all block layer
and driver development happens, you can subsribe to it using the
same way you subscribed to linux-kernel, just replacing the list name.

The latest released vesion at this point is Linux 4.10.

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

[Paolo Bonzini]

On 17/02/2017 17:51, Tom Lendacky wrote:
> 
> It's meant just to notify the user about the condition. The user could
> then decide to use an alternative device that supports a greater DMA
> range (I can probably change it to a dev_warn_once() so that a device
> is identified).  I would be nice if I could issue this message once per
> device that experienced this.  I didn't see anything that would do
> that, though.

dev_warn_once would print once only, not once per device.  But if you
leave the dev_warn elsewhere, this can be just pr_warn_once.

Paolo

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

[Paolo Bonzini]

On 17/02/2017 17:51, Tom Lendacky wrote:
> 
> It's meant just to notify the user about the condition. The user could
> then decide to use an alternative device that supports a greater DMA
> range (I can probably change it to a dev_warn_once() so that a device
> is identified).  I would be nice if I could issue this message once per
> device that experienced this.  I didn't see anything that would do
> that, though.

dev_warn_once would print once only, not once per device.  But if you
leave the dev_warn elsewhere, this can be just pr_warn_once.

Paolo

[PATCH 4/4] Staging:wilc1000:wilc_spi: Added blank line after function and modified comment style

[Georgios Emmanouil]

Added blank line after function and modified comment style.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_spi.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 4f38922..33c2f7c 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -1128,11 +1128,8 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)

return 1;
 }
-/
- *
- *  Global spi HIF function table
- *
- /
+
+/* Global spi HIF function table */
 static const struct wilc_hif_func wilc_hif_spi = {
.hif_init = wilc_spi_init,
.hif_deinit = _wilc_spi_deinit,
--
2.1.4

[PATCH 4/4] Staging:wilc1000:wilc_spi: Added blank line after function and modified comment style

[Georgios Emmanouil]

Added blank line after function and modified comment style.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_spi.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 4f38922..33c2f7c 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -1128,11 +1128,8 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)

return 1;
 }
-/
- *
- *  Global spi HIF function table
- *
- /
+
+/* Global spi HIF function table */
 static const struct wilc_hif_func wilc_hif_spi = {
.hif_init = wilc_spi_init,
.hif_deinit = _wilc_spi_deinit,
--
2.1.4

Re: [PATCHv2 11/14] module: Use set_memory.h header

[Jessica Yu]

+++ Laura Abbott [01/03/17 16:15 -0800]:


set_memory_* functions have moved to set_memory.h. Switch to this
explicitly.

Signed-off-by: Laura Abbott 


Acked-by: Jessica Yu 

Thanks,

Jessica


---
kernel/module.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/kernel/module.c b/kernel/module.c
index 7eba6de..c0f04b3 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -49,6 +49,7 @@
#include 
#include 
#include 
+#include 
#include 
#include 
#include 
--
2.7.4

Re: [PATCHv2 11/14] module: Use set_memory.h header

[Jessica Yu]

+++ Laura Abbott [01/03/17 16:15 -0800]:


set_memory_* functions have moved to set_memory.h. Switch to this
explicitly.

Signed-off-by: Laura Abbott 


Acked-by: Jessica Yu 

Thanks,

Jessica


---
kernel/module.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/kernel/module.c b/kernel/module.c
index 7eba6de..c0f04b3 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -49,6 +49,7 @@
#include 
#include 
#include 
+#include 
#include 
#include 
#include 
--
2.7.4

[PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size

[Arnd Bergmann]

With CONFIG_KASAN, the init function uses a large amount of kernel stack:

drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

By splitting out each part of the switch/case statement that has its own local
variables into a separate function, no single one of them uses more than 500 
bytes,
and with a noinline_for_kasan annotation we can ensure that they are not merged
back together.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 947 ++
 1 file changed, 508 insertions(+), 439 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 82edd37f0d73..83125a05918a 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -934,7 +934,7 @@ static struct lgdt3306a_config 
hauppauge_01595_lgdt3306a_config = {
 
 /* -- */
 
-static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
+static noinline_for_kasan int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
 {
struct dvb_frontend *fe;
struct xc2028_config cfg;
@@ -1126,6 +1126,492 @@ static void em28xx_unregister_dvb(struct em28xx_dvb 
*dvb)
dvb_unregister_adapter(>adapter);
 }
 
+static noinline_for_kasan int em28174_dvb_init_pctv_460e(struct em28xx *dev)
+{
+   struct em28xx_dvb *dvb = dev->dvb;
+   struct i2c_client *client;
+   struct i2c_board_info board_info;
+   struct tda10071_platform_data tda10071_pdata = {};
+   struct a8293_platform_data a8293_pdata = {};
+   int result;
+
+   /* attach demod + tuner combo */
+   tda10071_pdata.clk = 40444000, /* 40.444 MHz */
+   tda10071_pdata.i2c_wr_max = 64,
+   tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
+   tda10071_pdata.pll_multiplier = 20,
+   tda10071_pdata.tuner_i2c_addr = 0x14,
+   memset(_info, 0, sizeof(board_info));
+   strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
+   board_info.addr = 0x55;
+   board_info.platform_data = _pdata;
+   request_module("tda10071");
+   client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], _info);
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   goto out_free;
+   }
+   dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
+   dvb->i2c_client_demod = client;
+
+   /* attach SEC */
+   a8293_pdata.dvb_frontend = dvb->fe[0];
+   memset(_info, 0, sizeof(board_info));
+   strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+   board_info.addr = 0x08;
+   board_info.platform_data = _pdata;
+   request_module("a8293");
+   client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], _info);
+   if (client == NULL || client->dev.driver == NULL) {
+   module_put(dvb->i2c_client_demod->dev.driver->owner);
+   i2c_unregister_device(dvb->i2c_client_demod);
+   result = -ENODEV;
+   goto out_free;
+   }
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   module_put(dvb->i2c_client_demod->dev.driver->owner);
+   i2c_unregister_device(dvb->i2c_client_demod);
+   result = -ENODEV;
+   goto out_free;
+   }
+   dvb->i2c_client_sec = client;
+   result = 0;
+out_free:
+   return result;
+}
+
+static noinline_for_kasan int em28178_dvb_init_pctv_461e(struct em28xx *dev)
+{
+   struct em28xx_dvb *dvb = dev->dvb;
+   struct i2c_client *client;
+   struct i2c_adapter *i2c_adapter;
+   struct i2c_board_info board_info;
+   struct m88ds3103_platform_data m88ds3103_pdata = {};
+   struct ts2020_config ts2020_config = {};
+   struct a8293_platform_data a8293_pdata = {};
+   int result;
+
+   /* attach demod */
+   m88ds3103_pdata.clk = 2700;
+   m88ds3103_pdata.i2c_wr_max = 33;
+   m88ds3103_pdata.ts_mode = M88DS3103_TS_PARALLEL;
+   m88ds3103_pdata.ts_clk = 16000;
+   m88ds3103_pdata.ts_clk_pol = 1;
+   m88ds3103_pdata.agc = 0x99;
+   memset(_info, 0, sizeof(board_info));
+   strlcpy(board_info.type, "m88ds3103", I2C_NAME_SIZE);
+   board_info.addr = 0x68;
+   board_info.platform_data = _pdata;
+   request_module("m88ds3103");
+   client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], _info);
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+   if 

[PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size

[Arnd Bergmann]

With CONFIG_KASAN, the init function uses a large amount of kernel stack:

drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

By splitting out each part of the switch/case statement that has its own local
variables into a separate function, no single one of them uses more than 500 
bytes,
and with a noinline_for_kasan annotation we can ensure that they are not merged
back together.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 947 ++
 1 file changed, 508 insertions(+), 439 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 82edd37f0d73..83125a05918a 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -934,7 +934,7 @@ static struct lgdt3306a_config 
hauppauge_01595_lgdt3306a_config = {
 
 /* -- */
 
-static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
+static noinline_for_kasan int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
 {
struct dvb_frontend *fe;
struct xc2028_config cfg;
@@ -1126,6 +1126,492 @@ static void em28xx_unregister_dvb(struct em28xx_dvb 
*dvb)
dvb_unregister_adapter(>adapter);
 }
 
+static noinline_for_kasan int em28174_dvb_init_pctv_460e(struct em28xx *dev)
+{
+   struct em28xx_dvb *dvb = dev->dvb;
+   struct i2c_client *client;
+   struct i2c_board_info board_info;
+   struct tda10071_platform_data tda10071_pdata = {};
+   struct a8293_platform_data a8293_pdata = {};
+   int result;
+
+   /* attach demod + tuner combo */
+   tda10071_pdata.clk = 40444000, /* 40.444 MHz */
+   tda10071_pdata.i2c_wr_max = 64,
+   tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
+   tda10071_pdata.pll_multiplier = 20,
+   tda10071_pdata.tuner_i2c_addr = 0x14,
+   memset(_info, 0, sizeof(board_info));
+   strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
+   board_info.addr = 0x55;
+   board_info.platform_data = _pdata;
+   request_module("tda10071");
+   client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], _info);
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   goto out_free;
+   }
+   dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
+   dvb->i2c_client_demod = client;
+
+   /* attach SEC */
+   a8293_pdata.dvb_frontend = dvb->fe[0];
+   memset(_info, 0, sizeof(board_info));
+   strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+   board_info.addr = 0x08;
+   board_info.platform_data = _pdata;
+   request_module("a8293");
+   client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], _info);
+   if (client == NULL || client->dev.driver == NULL) {
+   module_put(dvb->i2c_client_demod->dev.driver->owner);
+   i2c_unregister_device(dvb->i2c_client_demod);
+   result = -ENODEV;
+   goto out_free;
+   }
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   module_put(dvb->i2c_client_demod->dev.driver->owner);
+   i2c_unregister_device(dvb->i2c_client_demod);
+   result = -ENODEV;
+   goto out_free;
+   }
+   dvb->i2c_client_sec = client;
+   result = 0;
+out_free:
+   return result;
+}
+
+static noinline_for_kasan int em28178_dvb_init_pctv_461e(struct em28xx *dev)
+{
+   struct em28xx_dvb *dvb = dev->dvb;
+   struct i2c_client *client;
+   struct i2c_adapter *i2c_adapter;
+   struct i2c_board_info board_info;
+   struct m88ds3103_platform_data m88ds3103_pdata = {};
+   struct ts2020_config ts2020_config = {};
+   struct a8293_platform_data a8293_pdata = {};
+   int result;
+
+   /* attach demod */
+   m88ds3103_pdata.clk = 2700;
+   m88ds3103_pdata.i2c_wr_max = 33;
+   m88ds3103_pdata.ts_mode = M88DS3103_TS_PARALLEL;
+   m88ds3103_pdata.ts_clk = 16000;
+   m88ds3103_pdata.ts_clk_pol = 1;
+   m88ds3103_pdata.agc = 0x99;
+   memset(_info, 0, sizeof(board_info));
+   strlcpy(board_info.type, "m88ds3103", I2C_NAME_SIZE);
+   board_info.addr = 0x68;
+   board_info.platform_data = _pdata;
+   request_module("m88ds3103");
+   client = i2c_new_device(>i2c_adap[dev->def_i2c_bus], _info);
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+   if (!try_module_get(client->dev.driver->owner)) {
+

Re: [Outreachy kernel] [PATCH 1/4] staging: speakup: Placed Logical on the previous line

[Alison Schofield]

On Thu, Mar 02, 2017 at 09:05:57PM +0530, Arushi Singhal wrote:
> Placed Logical continuations on the previous line as reported by
> checkpatch.pl.
> 
> Signed-off-by: Arushi Singhal 

Hi Arushi,
I'm not seeing the patch cover letter for this one.  That would be
your [PATCH 0/4] and would come first and then 1 through 4 follow
threaded as your've done.

Stating in imperative might look like this:

place logical continuation on previous line
insert spaces around operator
use tabs for indentation 
align open parenthesis

I didn't look into the changes themselves.

alisons






> ---
>  drivers/staging/speakup/main.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index a12ec2b061fe..25acebb9311f 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -2144,10 +2144,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
> keycode, u_short keysym,
>   if (up_flag || spk_killed || type == KT_SHIFT)
>   goto out;
>   spk_shut_up &= 0xfe;
> - kh = (value == KVAL(K_DOWN))
> - || (value == KVAL(K_UP))
> - || (value == KVAL(K_LEFT))
> - || (value == KVAL(K_RIGHT));
> + kh = (value == KVAL(K_DOWN)) ||
> +   (value == KVAL(K_UP))  ||
> +   (value == KVAL(K_LEFT)) ||
> +   (value == KVAL(K_RIGHT));
>   if ((cursor_track != read_all_mode) || !kh)
>   if (!spk_no_intr)
>   spk_do_flush();
> -- 
> 2.11.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170302153600.13803-1-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [Outreachy kernel] [PATCH 1/4] staging: speakup: Placed Logical on the previous line

[Alison Schofield]

On Thu, Mar 02, 2017 at 09:05:57PM +0530, Arushi Singhal wrote:
> Placed Logical continuations on the previous line as reported by
> checkpatch.pl.
> 
> Signed-off-by: Arushi Singhal 

Hi Arushi,
I'm not seeing the patch cover letter for this one.  That would be
your [PATCH 0/4] and would come first and then 1 through 4 follow
threaded as your've done.

Stating in imperative might look like this:

place logical continuation on previous line
insert spaces around operator
use tabs for indentation 
align open parenthesis

I didn't look into the changes themselves.

alisons






> ---
>  drivers/staging/speakup/main.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index a12ec2b061fe..25acebb9311f 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -2144,10 +2144,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
> keycode, u_short keysym,
>   if (up_flag || spk_killed || type == KT_SHIFT)
>   goto out;
>   spk_shut_up &= 0xfe;
> - kh = (value == KVAL(K_DOWN))
> - || (value == KVAL(K_UP))
> - || (value == KVAL(K_LEFT))
> - || (value == KVAL(K_RIGHT));
> + kh = (value == KVAL(K_DOWN)) ||
> +   (value == KVAL(K_UP))  ||
> +   (value == KVAL(K_LEFT)) ||
> +   (value == KVAL(K_RIGHT));
>   if ((cursor_track != read_all_mode) || !kh)
>   if (!spk_no_intr)
>   spk_do_flush();
> -- 
> 2.11.0
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170302153600.13803-1-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH V3 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Mathieu Poirier]

On Thu, Mar 02, 2017 at 02:22:07PM +0800, Chunyan Zhang wrote:
> From: Orson Zhai 
> 
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
> 
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> and sp9860g dts is for the board level.
> 
> Signed-off-by: Orson Zhai 
> Signed-off-by: Chunyan Zhang 
> ---
>  arch/arm64/boot/dts/sprd/Makefile |   3 +-
>  arch/arm64/boot/dts/sprd/sc9860.dtsi  | 545 
> ++
>  arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 +++
>  arch/arm64/boot/dts/sprd/whale2.dtsi  |  71 
>  4 files changed, 674 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
>  create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
>  create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
> 
> diff --git a/arch/arm64/boot/dts/sprd/Makefile 
> b/arch/arm64/boot/dts/sprd/Makefile
> index b658c5e..f0535e6 100644
> --- a/arch/arm64/boot/dts/sprd/Makefile
> +++ b/arch/arm64/boot/dts/sprd/Makefile
> @@ -1,4 +1,5 @@
> -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
> +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
> + sp9860g-1h10.dtb
>  
>  always   := $(dtb-y)
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
> b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> new file mode 100644
> index 000..0fd6d8c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -0,0 +1,545 @@
> +/*
> + * Spreadtrum SC9860 SoC
> + *
> + * Copyright (C) 2016, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +#include 
> +#include "whale2.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <>;
> + };
> + core1 {
> + cpu = <>;
> + };
> + core2 {
> + cpu = <>;
> + };
> + core3 {
> + cpu = <>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <>;
> + };
> + core1 {
> + cpu = <>;
> + };
> + core2 {
> + cpu = <>;
> + };
> + core3 {
> + cpu = <>;
> + };
> + };
> + };
> +
> + CPU0: cpu@53 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x53>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU1: cpu@530001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530001>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU2: cpu@530002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530002>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU3: cpu@530003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530003>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU4: cpu@530100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530100>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU5: cpu@530101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530101>;
> + enable-method = "psci";
> + 

[PATCH 04/11] drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available

[Neil Armstrong]

Since this is managed now by the components code, if CVBS is not available
and HDMI neither, the drm driver won't bind anyway.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c 
b/drivers/gpu/drm/meson/meson_venc_cvbs.c
index a2bcc70..a96fcb4 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
@@ -248,7 +248,7 @@ int meson_venc_cvbs_create(struct meson_drm *priv)
 
if (!meson_venc_cvbs_connector_is_available(priv)) {
dev_info(drm->dev, "CVBS Output connector not available\n");
-   return -ENODEV;
+   return 0;
}
 
meson_venc_cvbs = devm_kzalloc(priv->dev, sizeof(*meson_venc_cvbs),
-- 
1.9.1

Re: [PATCH V3 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Mathieu Poirier]

On Thu, Mar 02, 2017 at 02:22:07PM +0800, Chunyan Zhang wrote:
> From: Orson Zhai 
> 
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
> 
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> and sp9860g dts is for the board level.
> 
> Signed-off-by: Orson Zhai 
> Signed-off-by: Chunyan Zhang 
> ---
>  arch/arm64/boot/dts/sprd/Makefile |   3 +-
>  arch/arm64/boot/dts/sprd/sc9860.dtsi  | 545 
> ++
>  arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 +++
>  arch/arm64/boot/dts/sprd/whale2.dtsi  |  71 
>  4 files changed, 674 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
>  create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
>  create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
> 
> diff --git a/arch/arm64/boot/dts/sprd/Makefile 
> b/arch/arm64/boot/dts/sprd/Makefile
> index b658c5e..f0535e6 100644
> --- a/arch/arm64/boot/dts/sprd/Makefile
> +++ b/arch/arm64/boot/dts/sprd/Makefile
> @@ -1,4 +1,5 @@
> -dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
> +dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
> + sp9860g-1h10.dtb
>  
>  always   := $(dtb-y)
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
> b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> new file mode 100644
> index 000..0fd6d8c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -0,0 +1,545 @@
> +/*
> + * Spreadtrum SC9860 SoC
> + *
> + * Copyright (C) 2016, Spreadtrum Communications Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
> +
> +#include 
> +#include "whale2.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <>;
> + };
> + core1 {
> + cpu = <>;
> + };
> + core2 {
> + cpu = <>;
> + };
> + core3 {
> + cpu = <>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <>;
> + };
> + core1 {
> + cpu = <>;
> + };
> + core2 {
> + cpu = <>;
> + };
> + core3 {
> + cpu = <>;
> + };
> + };
> + };
> +
> + CPU0: cpu@53 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x53>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU1: cpu@530001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530001>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU2: cpu@530002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530002>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU3: cpu@530003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530003>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU4: cpu@530100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530100>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU5: cpu@530101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x530101>;
> + enable-method = "psci";
> + cpu-idle-states = <_PD _PD>;
> + };
> +
> + CPU6: cpu@530102 {

[PATCH 04/11] drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available

[Neil Armstrong]

Since this is managed now by the components code, if CVBS is not available
and HDMI neither, the drm driver won't bind anyway.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c 
b/drivers/gpu/drm/meson/meson_venc_cvbs.c
index a2bcc70..a96fcb4 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
@@ -248,7 +248,7 @@ int meson_venc_cvbs_create(struct meson_drm *priv)
 
if (!meson_venc_cvbs_connector_is_available(priv)) {
dev_info(drm->dev, "CVBS Output connector not available\n");
-   return -ENODEV;
+   return 0;
}
 
meson_venc_cvbs = devm_kzalloc(priv->dev, sizeof(*meson_venc_cvbs),
-- 
1.9.1

Re: [PATCH] Drivers: hv: util: move waiting for release to hv_utils_transport itself

[Stephen Hemminger]

On Thu,  2 Mar 2017 10:47:49 +0100
Vitaly Kuznetsov  wrote:

> Waiting for release_event in all three drivers introduced issues on release
> as on_reset() hook is not always called. E.g. if the device was never
> opened we will never get the completion.
> 
> Move the waiting code to hvutil_transport_destroy() and make sure it is
> only called when the device is open. hvt->lock serialization should
> guarantee the absence of races.
> 
> Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue")
> Fixes: 20951c7535b5 ("Drivers: hv: util: Fcopy: Fix a rescind processing 
> issue")
> Fixes: d77044d142e9 ("Drivers: hv: util: Backup: Fix a rescind processing 
> issue")
> Reported-by: Dexuan Cui 
> Tested-by: Dexuan Cui 
> Signed-off-by: Vitaly Kuznetsov 

Acked-by: Stephen Hemminger 

Re: [PATCH] Drivers: hv: util: move waiting for release to hv_utils_transport itself

[Stephen Hemminger]

On Thu,  2 Mar 2017 10:47:49 +0100
Vitaly Kuznetsov  wrote:

> Waiting for release_event in all three drivers introduced issues on release
> as on_reset() hook is not always called. E.g. if the device was never
> opened we will never get the completion.
> 
> Move the waiting code to hvutil_transport_destroy() and make sure it is
> only called when the device is open. hvt->lock serialization should
> guarantee the absence of races.
> 
> Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue")
> Fixes: 20951c7535b5 ("Drivers: hv: util: Fcopy: Fix a rescind processing 
> issue")
> Fixes: d77044d142e9 ("Drivers: hv: util: Backup: Fix a rescind processing 
> issue")
> Reported-by: Dexuan Cui 
> Tested-by: Dexuan Cui 
> Signed-off-by: Vitaly Kuznetsov 

Acked-by: Stephen Hemminger