Re: [PATCH] Make mtdblock can handle partition bigger than 4G.

[Boris Brezillon]

Hi Lepton,

On Fri, 17 Feb 2017 15:37:33 -0800
Lepton Wu  wrote:

Can you please add a commit message and prefix the subject with 'mtd: '.
Something like 'mtd: Fix mtdblock for >4GB MTD devices'.

> Signed-off-by: Lepton Wu 
> ---
>  drivers/mtd/mtdblock.c| 33 +
>  drivers/mtd/mtdblock_ro.c |  4 ++--
>  2 files changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
> index bb4c14f83c75..3d2da76287a7 100644
> --- a/drivers/mtd/mtdblock.c
> +++ b/drivers/mtd/mtdblock.c
> @@ -61,8 +61,8 @@ static void erase_callback(struct erase_info *done)
>   wake_up(wait_q);
>  }
>  
> -static int erase_write (struct mtd_info *mtd, unsigned long pos,
> - int len, const char *buf)
> +static int erase_write(struct mtd_info *mtd, loff_t pos, int len,
> +const char *buf)
>  {
>   struct erase_info erase;
>   DECLARE_WAITQUEUE(wait, current);
> @@ -88,8 +88,7 @@ static int erase_write (struct mtd_info *mtd, unsigned long 
> pos,
>   if (ret) {
>   set_current_state(TASK_RUNNING);
>   remove_wait_queue(_q, );
> - printk (KERN_WARNING "mtdblock: erase of region [0x%lx, 0x%x] "
> -  "on \"%s\" failed\n",
> + pr_warn("mtdblock: erase of region [0x%llx, 0x%x] on \"%s\" 
> failed\n",
>   pos, len, mtd->name);
>   return ret;
>   }
> @@ -139,23 +138,24 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
>  }
>  
>  
> -static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
> - int len, const char *buf)
> +static int do_cached_write(struct mtdblk_dev *mtdblk, loff_t pos,
> +int len, const char *buf)
>  {
>   struct mtd_info *mtd = mtdblk->mbd.mtd;
>   unsigned int sect_size = mtdblk->cache_size;
>   size_t retlen;
>   int ret;
>  
> - pr_debug("mtdblock: write on \"%s\" at 0x%lx, size 0x%x\n",
> + pr_debug("mtdblock: write on \"%s\" at 0x%llx, size 0x%x\n",
>   mtd->name, pos, len);
>  
>   if (!sect_size)
>   return mtd_write(mtd, pos, len, , buf);
>  
>   while (len > 0) {
> - unsigned long sect_start = (pos/sect_size)*sect_size;
> - unsigned int offset = pos - sect_start;
> + unsigned int offset;
> + loff_t sect_start =
> + div_u64_rem(pos, sect_size, ) * sect_size;
>   unsigned int size = sect_size - offset;
>   if( size > len )
>   size = len;
> @@ -209,23 +209,24 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, 
> unsigned long pos,
>  }
>  
>  
> -static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
> -int len, char *buf)
> +static int do_cached_read(struct mtdblk_dev *mtdblk, loff_t pos,
> +   int len, char *buf)
>  {
>   struct mtd_info *mtd = mtdblk->mbd.mtd;
>   unsigned int sect_size = mtdblk->cache_size;
>   size_t retlen;
>   int ret;
>  
> - pr_debug("mtdblock: read on \"%s\" at 0x%lx, size 0x%x\n",
> + pr_debug("mtdblock: read on \"%s\" at 0x%llx, size 0x%x\n",
>   mtd->name, pos, len);

Align the parameters on the open parenthesis.

>  
>   if (!sect_size)
>   return mtd_read(mtd, pos, len, , buf);
>  
>   while (len > 0) {
> - unsigned long sect_start = (pos/sect_size)*sect_size;
> - unsigned int offset = pos - sect_start;
> + unsigned int offset;
> + loff_t sect_start =
> + div_u64_rem(pos, sect_size, ) * sect_size;
>   unsigned int size = sect_size - offset;
>   if (size > len)
>   size = len;
> @@ -259,7 +260,7 @@ static int mtdblock_readsect(struct mtd_blktrans_dev *dev,
> unsigned long block, char *buf)
>  {
>   struct mtdblk_dev *mtdblk = container_of(dev, struct mtdblk_dev, mbd);
> - return do_cached_read(mtdblk, block<<9, 512, buf);
> + return do_cached_read(mtdblk, (loff_t)block<<9, 512, buf);

  ^ block << 9
>  }
>  
>  static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
> @@ -275,7 +276,7 @@ static int mtdblock_writesect(struct mtd_blktrans_dev 
> *dev,
>* return -EAGAIN sometimes, but why bother?
>*/
>   }
> - return do_cached_write(mtdblk, block<<9, 512, buf);
> + return do_cached_write(mtdblk, (loff_t)block<<9, 512, buf);

Ditto.

>  }
>  
>  static int mtdblock_open(struct mtd_blktrans_dev *mbd)
> diff --git a/drivers/mtd/mtdblock_ro.c b/drivers/mtd/mtdblock_ro.c
> index fb5dc89369de..92829e3fb3b7 100644
> --- a/drivers/mtd/mtdblock_ro.c
> +++ b/drivers/mtd/mtdblock_ro.c
> @@ -31,7 +31,7 @@ 

Re: [PATCH] Make mtdblock can handle partition bigger than 4G.

[Boris Brezillon]

Hi Lepton,

On Fri, 17 Feb 2017 15:37:33 -0800
Lepton Wu  wrote:

Can you please add a commit message and prefix the subject with 'mtd: '.
Something like 'mtd: Fix mtdblock for >4GB MTD devices'.

> Signed-off-by: Lepton Wu 
> ---
>  drivers/mtd/mtdblock.c| 33 +
>  drivers/mtd/mtdblock_ro.c |  4 ++--
>  2 files changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
> index bb4c14f83c75..3d2da76287a7 100644
> --- a/drivers/mtd/mtdblock.c
> +++ b/drivers/mtd/mtdblock.c
> @@ -61,8 +61,8 @@ static void erase_callback(struct erase_info *done)
>   wake_up(wait_q);
>  }
>  
> -static int erase_write (struct mtd_info *mtd, unsigned long pos,
> - int len, const char *buf)
> +static int erase_write(struct mtd_info *mtd, loff_t pos, int len,
> +const char *buf)
>  {
>   struct erase_info erase;
>   DECLARE_WAITQUEUE(wait, current);
> @@ -88,8 +88,7 @@ static int erase_write (struct mtd_info *mtd, unsigned long 
> pos,
>   if (ret) {
>   set_current_state(TASK_RUNNING);
>   remove_wait_queue(_q, );
> - printk (KERN_WARNING "mtdblock: erase of region [0x%lx, 0x%x] "
> -  "on \"%s\" failed\n",
> + pr_warn("mtdblock: erase of region [0x%llx, 0x%x] on \"%s\" 
> failed\n",
>   pos, len, mtd->name);
>   return ret;
>   }
> @@ -139,23 +138,24 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
>  }
>  
>  
> -static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
> - int len, const char *buf)
> +static int do_cached_write(struct mtdblk_dev *mtdblk, loff_t pos,
> +int len, const char *buf)
>  {
>   struct mtd_info *mtd = mtdblk->mbd.mtd;
>   unsigned int sect_size = mtdblk->cache_size;
>   size_t retlen;
>   int ret;
>  
> - pr_debug("mtdblock: write on \"%s\" at 0x%lx, size 0x%x\n",
> + pr_debug("mtdblock: write on \"%s\" at 0x%llx, size 0x%x\n",
>   mtd->name, pos, len);
>  
>   if (!sect_size)
>   return mtd_write(mtd, pos, len, , buf);
>  
>   while (len > 0) {
> - unsigned long sect_start = (pos/sect_size)*sect_size;
> - unsigned int offset = pos - sect_start;
> + unsigned int offset;
> + loff_t sect_start =
> + div_u64_rem(pos, sect_size, ) * sect_size;
>   unsigned int size = sect_size - offset;
>   if( size > len )
>   size = len;
> @@ -209,23 +209,24 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, 
> unsigned long pos,
>  }
>  
>  
> -static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
> -int len, char *buf)
> +static int do_cached_read(struct mtdblk_dev *mtdblk, loff_t pos,
> +   int len, char *buf)
>  {
>   struct mtd_info *mtd = mtdblk->mbd.mtd;
>   unsigned int sect_size = mtdblk->cache_size;
>   size_t retlen;
>   int ret;
>  
> - pr_debug("mtdblock: read on \"%s\" at 0x%lx, size 0x%x\n",
> + pr_debug("mtdblock: read on \"%s\" at 0x%llx, size 0x%x\n",
>   mtd->name, pos, len);

Align the parameters on the open parenthesis.

>  
>   if (!sect_size)
>   return mtd_read(mtd, pos, len, , buf);
>  
>   while (len > 0) {
> - unsigned long sect_start = (pos/sect_size)*sect_size;
> - unsigned int offset = pos - sect_start;
> + unsigned int offset;
> + loff_t sect_start =
> + div_u64_rem(pos, sect_size, ) * sect_size;
>   unsigned int size = sect_size - offset;
>   if (size > len)
>   size = len;
> @@ -259,7 +260,7 @@ static int mtdblock_readsect(struct mtd_blktrans_dev *dev,
> unsigned long block, char *buf)
>  {
>   struct mtdblk_dev *mtdblk = container_of(dev, struct mtdblk_dev, mbd);
> - return do_cached_read(mtdblk, block<<9, 512, buf);
> + return do_cached_read(mtdblk, (loff_t)block<<9, 512, buf);

  ^ block << 9
>  }
>  
>  static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
> @@ -275,7 +276,7 @@ static int mtdblock_writesect(struct mtd_blktrans_dev 
> *dev,
>* return -EAGAIN sometimes, but why bother?
>*/
>   }
> - return do_cached_write(mtdblk, block<<9, 512, buf);
> + return do_cached_write(mtdblk, (loff_t)block<<9, 512, buf);

Ditto.

>  }
>  
>  static int mtdblock_open(struct mtd_blktrans_dev *mbd)
> diff --git a/drivers/mtd/mtdblock_ro.c b/drivers/mtd/mtdblock_ro.c
> index fb5dc89369de..92829e3fb3b7 100644
> --- a/drivers/mtd/mtdblock_ro.c
> +++ b/drivers/mtd/mtdblock_ro.c
> @@ -31,7 +31,7 @@ static int mtdblock_readsect(struct 

[PATCH 1/6] staging: rtl8192e: Replaced comparison to NULL statements

[simran singhal]

This patch corrects check generated by checkpatch.pl by
replacing comparison to null statements with equivalent
statements in the form of "!x".

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192e/rtl819x_BAProc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c 
b/drivers/staging/rtl8192e/rtl819x_BAProc.c
index 20260af..bdbd21c 100644
--- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
@@ -83,12 +83,12 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device 
*ieee, u8 *Dst,
netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
   __func__, type, Dst, ieee->dev);
 
-   if (pBA == NULL) {
+   if (!pBA) {
netdev_warn(ieee->dev, "pBA is NULL\n");
return NULL;
}
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
-   if (skb == NULL)
+   if (!skb)
return NULL;
 
memset(skb->data, 0, sizeof(struct rtllib_hdr_3addr));
@@ -154,7 +154,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device 
*ieee, u8 *dst,
DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
 
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
-   if (skb == NULL)
+   if (!skb)
return NULL;
 
skb_reserve(skb, ieee->tx_headroom);
-- 
2.7.4

[PATCH 1/6] staging: rtl8192e: Replaced comparison to NULL statements

[simran singhal]

This patch corrects check generated by checkpatch.pl by
replacing comparison to null statements with equivalent
statements in the form of "!x".

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192e/rtl819x_BAProc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c 
b/drivers/staging/rtl8192e/rtl819x_BAProc.c
index 20260af..bdbd21c 100644
--- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
@@ -83,12 +83,12 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device 
*ieee, u8 *Dst,
netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
   __func__, type, Dst, ieee->dev);
 
-   if (pBA == NULL) {
+   if (!pBA) {
netdev_warn(ieee->dev, "pBA is NULL\n");
return NULL;
}
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
-   if (skb == NULL)
+   if (!skb)
return NULL;
 
memset(skb->data, 0, sizeof(struct rtllib_hdr_3addr));
@@ -154,7 +154,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device 
*ieee, u8 *dst,
DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
 
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
-   if (skb == NULL)
+   if (!skb)
return NULL;
 
skb_reserve(skb, ieee->tx_headroom);
-- 
2.7.4

Re: [4.9.10] ip_route_me_harder() reading off-slab

[Daniel J Blueman]

On 17 February 2017 at 13:36, Eric Dumazet  wrote:
> On Fri, 2017-02-17 at 12:36 +0800, Daniel J Blueman wrote:
>> When booting a VM in libvirt/KVM attached to a local bridge and KASAN
>> enabled on 4.9.10, we see a stream of KASAN warnings about off-slab
>> access [1].
>>
>> Let me know if you'd like more debug.
>
> Could you try the following patch ?
>
> Thanks !
>
> diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
> index 
> b3cc1335adbc1a20dcd225d0501b0a286d27e3c8..18839e59da849f0988924bcbc9873965a3681eb0
>  100644
> --- a/net/ipv4/netfilter.c
> +++ b/net/ipv4/netfilter.c
> @@ -23,7 +23,8 @@ int ip_route_me_harder(struct net *net, struct sk_buff 
> *skb, unsigned int addr_t
> struct rtable *rt;
> struct flowi4 fl4 = {};
> __be32 saddr = iph->saddr;
> -   __u8 flags = skb->sk ? inet_sk_flowi_flags(skb->sk) : 0;
> +   struct sock *sk = skb->sk;
> +   __u8 flags = sk && sk_fullsock(sk) ? inet_sk_flowi_flags(sk) : 0;
> struct net_device *dev = skb_dst(skb)->dev;
> unsigned int hh_len;
>
> @@ -40,7 +41,7 @@ int ip_route_me_harder(struct net *net, struct sk_buff 
> *skb, unsigned int addr_t
> fl4.daddr = iph->daddr;
> fl4.saddr = saddr;
> fl4.flowi4_tos = RT_TOS(iph->tos);
> -   fl4.flowi4_oif = skb->sk ? skb->sk->sk_bound_dev_if : 0;
> +   fl4.flowi4_oif = sk ? sk->sk_bound_dev_if : 0;
> if (!fl4.flowi4_oif)
> fl4.flowi4_oif = l3mdev_master_ifindex(dev);
> fl4.flowi4_mark = skb->mark;
> @@ -61,7 +62,7 @@ int ip_route_me_harder(struct net *net, struct sk_buff 
> *skb, unsigned int addr_t
> xfrm_decode_session(skb, flowi4_to_flowi(), AF_INET) == 0) {
> struct dst_entry *dst = skb_dst(skb);
> skb_dst_set(skb, NULL);
> -   dst = xfrm_lookup(net, dst, flowi4_to_flowi(), skb->sk, 
> 0);
> +   dst = xfrm_lookup(net, dst, flowi4_to_flowi(), sk, 0);
> if (IS_ERR(dst))
> return PTR_ERR(dst);
> skb_dst_set(skb, dst);

Fine work! This nicely resolves the issue. I'll test Florian's
proposed fix also.

Tested-by: Daniel J Blueman 

Thanks,
  Dan
-- 
Daniel J Blueman

Re: [4.9.10] ip_route_me_harder() reading off-slab

[Daniel J Blueman]

On 17 February 2017 at 13:36, Eric Dumazet  wrote:
> On Fri, 2017-02-17 at 12:36 +0800, Daniel J Blueman wrote:
>> When booting a VM in libvirt/KVM attached to a local bridge and KASAN
>> enabled on 4.9.10, we see a stream of KASAN warnings about off-slab
>> access [1].
>>
>> Let me know if you'd like more debug.
>
> Could you try the following patch ?
>
> Thanks !
>
> diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
> index 
> b3cc1335adbc1a20dcd225d0501b0a286d27e3c8..18839e59da849f0988924bcbc9873965a3681eb0
>  100644
> --- a/net/ipv4/netfilter.c
> +++ b/net/ipv4/netfilter.c
> @@ -23,7 +23,8 @@ int ip_route_me_harder(struct net *net, struct sk_buff 
> *skb, unsigned int addr_t
> struct rtable *rt;
> struct flowi4 fl4 = {};
> __be32 saddr = iph->saddr;
> -   __u8 flags = skb->sk ? inet_sk_flowi_flags(skb->sk) : 0;
> +   struct sock *sk = skb->sk;
> +   __u8 flags = sk && sk_fullsock(sk) ? inet_sk_flowi_flags(sk) : 0;
> struct net_device *dev = skb_dst(skb)->dev;
> unsigned int hh_len;
>
> @@ -40,7 +41,7 @@ int ip_route_me_harder(struct net *net, struct sk_buff 
> *skb, unsigned int addr_t
> fl4.daddr = iph->daddr;
> fl4.saddr = saddr;
> fl4.flowi4_tos = RT_TOS(iph->tos);
> -   fl4.flowi4_oif = skb->sk ? skb->sk->sk_bound_dev_if : 0;
> +   fl4.flowi4_oif = sk ? sk->sk_bound_dev_if : 0;
> if (!fl4.flowi4_oif)
> fl4.flowi4_oif = l3mdev_master_ifindex(dev);
> fl4.flowi4_mark = skb->mark;
> @@ -61,7 +62,7 @@ int ip_route_me_harder(struct net *net, struct sk_buff 
> *skb, unsigned int addr_t
> xfrm_decode_session(skb, flowi4_to_flowi(), AF_INET) == 0) {
> struct dst_entry *dst = skb_dst(skb);
> skb_dst_set(skb, NULL);
> -   dst = xfrm_lookup(net, dst, flowi4_to_flowi(), skb->sk, 
> 0);
> +   dst = xfrm_lookup(net, dst, flowi4_to_flowi(), sk, 0);
> if (IS_ERR(dst))
> return PTR_ERR(dst);
> skb_dst_set(skb, dst);

Fine work! This nicely resolves the issue. I'll test Florian's
proposed fix also.

Tested-by: Daniel J Blueman 

Thanks,
  Dan
-- 
Daniel J Blueman

RE: [PATCH] media: uvcvideo: Add support for changing UVC_URBS/UVC_MAX_PACKETS from sysfs

[Anurag Kumar Vulisha]

Ping !

>-Original Message-
>From: Anurag Kumar Vulisha [mailto:anurag.kumar.vuli...@xilinx.com]
>Sent: Friday, February 03, 2017 10:10 PM
>To: Laurent Pinchart ; Mauro Carvalho
>Chehab 
>Cc: Punnaiah Choudary Kalluri ; Anirudha Sarangi
>; linux-me...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Anurag Kumar Vulisha 
>Subject: [PATCH] media: uvcvideo: Add support for changing
>UVC_URBS/UVC_MAX_PACKETS from sysfs
>
>The uvc_video.c driver currently has fixed the maximum UVC_URBS queued to 5
>and max UVC_MAX_PACKETS per URB to 32K. This configuration works fine with
>USB 2.0 and some USB 3.0 cameras on embedded platforms(like Zynq Ultrascale).
>Since embedded platforms has slow processing speed as compared to
>servers/x86 machines, we may need to increase the number of URBs(UVC_URBS)
>queued. Also some next generation USB 3.0 cameras (like ZED stereo camera)
>splits each frame into multiple chunks of 48K bytes (which is greater than the 
>size
>of UVC_MAX_PACKETS per URB), so we may need to increase
>UVC_MAX_PACKETS also at runtime instead of #define it.
>
>This patch adds the solution to change UVC_URBS and UVC_MAX_PACKETS at
>runtime using sysfs layer before starting the video application.
>
>Signed-off-by: Anurag Kumar Vulisha 
>---
> drivers/media/usb/uvc/uvc_driver.c | 89
>++
> drivers/media/usb/uvc/uvc_video.c  | 39 -
> drivers/media/usb/uvc/uvcvideo.h   | 12 +++--
> 3 files changed, 126 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/media/usb/uvc/uvc_driver.c
>b/drivers/media/usb/uvc/uvc_driver.c
>index 04bf350..51c8058 100644
>--- a/drivers/media/usb/uvc/uvc_driver.c
>+++ b/drivers/media/usb/uvc/uvc_driver.c
>@@ -190,6 +190,89 @@ static struct uvc_format_desc uvc_fmts[] = {
>   },
> };
>
>+/* Sysfs attributes for show and store max_urbs/max_packets per URB */
>+
>+static ssize_t get_max_urbs_show(struct device *dev,
>+  struct device_attribute *attr, char *buf) {
>+
>+  struct uvc_streaming *stream = NULL;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+  u32 ret_len = 0;
>+  u32 stream_num = 0;
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  ret_len += scnprintf((char *)(buf + ret_len), PAGE_SIZE,
>+  "stream[%d] = %d\n", stream_num++,
>+  stream->max_urbs);
>+  }
>+
>+  return ret_len;
>+}
>+static DEVICE_ATTR_RO(get_max_urbs);
>+
>+static ssize_t set_max_urbs_store(struct device *dev,
>+  struct device_attribute *attr, const char *buf, size_t count) {
>+
>+  struct uvc_streaming *stream;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  sscanf(buf, "%d", >max_urbs);
>+  }
>+
>+  return count;
>+}
>+static DEVICE_ATTR_WO(set_max_urbs);
>+
>+static ssize_t get_max_packets_show(struct device *dev,
>+  struct device_attribute *attr, char *buf) {
>+
>+  struct uvc_streaming *stream = NULL;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+  u32 ret_len = 0;
>+  u32 stream_num = 0;
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  ret_len += scnprintf((char *)(buf + ret_len), PAGE_SIZE,
>+  "stream[%d] = %d\n", stream_num++,
>+  stream->max_packets);
>+  }
>+
>+  return ret_len;
>+}
>+static DEVICE_ATTR_RO(get_max_packets);
>+
>+static ssize_t set_max_packets_store(struct device *dev,
>+  struct device_attribute *attr, const char *buf, size_t count) {
>+
>+  struct uvc_streaming *stream;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  sscanf(buf, "%d", >max_packets);
>+  }
>+
>+  return count;
>+}
>+static DEVICE_ATTR_WO(set_max_packets);
>+
>+static struct attribute *uvc_attributes[] = {
>+  _attr_get_max_urbs.attr,
>+  _attr_set_max_urbs.attr,
>+  _attr_get_max_packets.attr,
>+  _attr_set_max_packets.attr,
>+  NULL
>+};
>+
>+static const struct attribute_group uvc_attr_group = {
>+  .attrs = uvc_attributes,
>+};
>+
>+
> /* 
>  * Utility functions
>  */
>@@ -2097,6 +2180,12 @@ static int uvc_probe(struct usb_interface *intf,
>   "supported.\n", ret);
>   }
>
>+  ret = sysfs_create_group(>intf->dev.kobj, _attr_group);
>+  if (ret < 0) {
>+  uvc_printk(KERN_ERR, "Failed to 

RE: [PATCH] media: uvcvideo: Add support for changing UVC_URBS/UVC_MAX_PACKETS from sysfs

[Anurag Kumar Vulisha]

Ping !

>-Original Message-
>From: Anurag Kumar Vulisha [mailto:anurag.kumar.vuli...@xilinx.com]
>Sent: Friday, February 03, 2017 10:10 PM
>To: Laurent Pinchart ; Mauro Carvalho
>Chehab 
>Cc: Punnaiah Choudary Kalluri ; Anirudha Sarangi
>; linux-me...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Anurag Kumar Vulisha 
>Subject: [PATCH] media: uvcvideo: Add support for changing
>UVC_URBS/UVC_MAX_PACKETS from sysfs
>
>The uvc_video.c driver currently has fixed the maximum UVC_URBS queued to 5
>and max UVC_MAX_PACKETS per URB to 32K. This configuration works fine with
>USB 2.0 and some USB 3.0 cameras on embedded platforms(like Zynq Ultrascale).
>Since embedded platforms has slow processing speed as compared to
>servers/x86 machines, we may need to increase the number of URBs(UVC_URBS)
>queued. Also some next generation USB 3.0 cameras (like ZED stereo camera)
>splits each frame into multiple chunks of 48K bytes (which is greater than the 
>size
>of UVC_MAX_PACKETS per URB), so we may need to increase
>UVC_MAX_PACKETS also at runtime instead of #define it.
>
>This patch adds the solution to change UVC_URBS and UVC_MAX_PACKETS at
>runtime using sysfs layer before starting the video application.
>
>Signed-off-by: Anurag Kumar Vulisha 
>---
> drivers/media/usb/uvc/uvc_driver.c | 89
>++
> drivers/media/usb/uvc/uvc_video.c  | 39 -
> drivers/media/usb/uvc/uvcvideo.h   | 12 +++--
> 3 files changed, 126 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/media/usb/uvc/uvc_driver.c
>b/drivers/media/usb/uvc/uvc_driver.c
>index 04bf350..51c8058 100644
>--- a/drivers/media/usb/uvc/uvc_driver.c
>+++ b/drivers/media/usb/uvc/uvc_driver.c
>@@ -190,6 +190,89 @@ static struct uvc_format_desc uvc_fmts[] = {
>   },
> };
>
>+/* Sysfs attributes for show and store max_urbs/max_packets per URB */
>+
>+static ssize_t get_max_urbs_show(struct device *dev,
>+  struct device_attribute *attr, char *buf) {
>+
>+  struct uvc_streaming *stream = NULL;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+  u32 ret_len = 0;
>+  u32 stream_num = 0;
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  ret_len += scnprintf((char *)(buf + ret_len), PAGE_SIZE,
>+  "stream[%d] = %d\n", stream_num++,
>+  stream->max_urbs);
>+  }
>+
>+  return ret_len;
>+}
>+static DEVICE_ATTR_RO(get_max_urbs);
>+
>+static ssize_t set_max_urbs_store(struct device *dev,
>+  struct device_attribute *attr, const char *buf, size_t count) {
>+
>+  struct uvc_streaming *stream;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  sscanf(buf, "%d", >max_urbs);
>+  }
>+
>+  return count;
>+}
>+static DEVICE_ATTR_WO(set_max_urbs);
>+
>+static ssize_t get_max_packets_show(struct device *dev,
>+  struct device_attribute *attr, char *buf) {
>+
>+  struct uvc_streaming *stream = NULL;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+  u32 ret_len = 0;
>+  u32 stream_num = 0;
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  ret_len += scnprintf((char *)(buf + ret_len), PAGE_SIZE,
>+  "stream[%d] = %d\n", stream_num++,
>+  stream->max_packets);
>+  }
>+
>+  return ret_len;
>+}
>+static DEVICE_ATTR_RO(get_max_packets);
>+
>+static ssize_t set_max_packets_store(struct device *dev,
>+  struct device_attribute *attr, const char *buf, size_t count) {
>+
>+  struct uvc_streaming *stream;
>+  struct usb_interface *intf = to_usb_interface(dev);
>+  struct uvc_device *udev = usb_get_intfdata(intf);
>+
>+  list_for_each_entry(stream, >streams, list) {
>+  sscanf(buf, "%d", >max_packets);
>+  }
>+
>+  return count;
>+}
>+static DEVICE_ATTR_WO(set_max_packets);
>+
>+static struct attribute *uvc_attributes[] = {
>+  _attr_get_max_urbs.attr,
>+  _attr_set_max_urbs.attr,
>+  _attr_get_max_packets.attr,
>+  _attr_set_max_packets.attr,
>+  NULL
>+};
>+
>+static const struct attribute_group uvc_attr_group = {
>+  .attrs = uvc_attributes,
>+};
>+
>+
> /* 
>  * Utility functions
>  */
>@@ -2097,6 +2180,12 @@ static int uvc_probe(struct usb_interface *intf,
>   "supported.\n", ret);
>   }
>
>+  ret = sysfs_create_group(>intf->dev.kobj, _attr_group);
>+  if (ret < 0) {
>+  uvc_printk(KERN_ERR, "Failed to create sysfs node %d\n", ret);
>+  return ret;
>+  }
>+
>   uvc_trace(UVC_TRACE_PROBE, "UVC device initialized.\n");

Re: [PATCH v2 2/3] extable: verify address is read-only

[kbuild test robot]

Hi Eddie,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
config: x86_64-randconfig-x008-201707 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/trace_clock.h:12:0,
from include/linux/ftrace.h:9,
from kernel/extable.c:18:
   kernel/extable.c: In function 'kernel_ro_address':
   kernel/extable.c:168:6: error: implicit declaration of function 
'is_module_ro_address' [-Werror=implicit-function-declaration]
 if (is_module_ro_address(addr))
 ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/extable.c:168:2: note: in expansion of macro 'if'
 if (is_module_ro_address(addr))
 ^~
   cc1: some warnings being treated as errors

vim +/if +168 kernel/extable.c

12  GNU General Public License for more details.
13  
14  You should have received a copy of the GNU General Public License
15  along with this program; if not, write to the Free Software
16  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  
02111-1307  USA
17  */
  > 18  #include 
19  #include 
20  #include 
21  #include 
22  #include 
23  
24  #include 
25  #include 
26  
27  /*
28   * mutex protecting text section modification (dynamic code patching).
29   * some users need to sleep (allocating memory...) while they hold this 
lock.
30   *
31   * NOT exported to modules - patching kernel text is a really delicate 
matter.
32   */
33  DEFINE_MUTEX(text_mutex);
34  
35  extern struct exception_table_entry __start___ex_table[];
36  extern struct exception_table_entry __stop___ex_table[];
37  
38  /* Cleared by build time tools if the table is already sorted. */
39  u32 __initdata __visible main_extable_sort_needed = 1;
40  
41  /* Sort the kernel's built-in exception table */
42  void __init sort_main_extable(void)
43  {
44  if (main_extable_sort_needed && __stop___ex_table > 
__start___ex_table) {
45  pr_notice("Sorting __ex_table...\n");
46  sort_extable(__start___ex_table, __stop___ex_table);
47  }
48  }
49  
50  /* Given an address, look for it in the exception tables. */
51  const struct exception_table_entry *search_exception_tables(unsigned 
long addr)
52  {
53  const struct exception_table_entry *e;
54  
55  e = search_extable(__start___ex_table, __stop___ex_table-1, 
addr);
56  if (!e)
57  e = search_module_extables(addr);
58  return e;
59  }
60  
61  static inline int init_kernel_text(unsigned long addr)
62  {
63  if (addr >= (unsigned long)_sinittext &&
64  addr < (unsigned long)_einittext)
65  return 1;
66  return 0;
67  }
68  
69  int core_kernel_text(unsigned long addr)
70  {
71  if (addr >= (unsigned long)_stext &&
72  addr < (unsigned long)_etext)
73  return 1;
74  
75  if (system_state == SYSTEM_BOOTING &&
76  init_kernel_text(addr))
77  return 1;
78  return 0;
79  }
80  
81  /**
82   * core_kernel_data - tell if addr points to kernel data
83   * @addr: address to test
84   *
85   * Returns true if @addr passed in is from the core kernel data
86   * section.
87   *
88   * Note: On some archs it may return true for core RODATA, and false
89   *  for others. But will always be true for core RW data.
90   */
91  int core_kernel_data(unsigned long addr)
92  {
93  if (addr >= (unsigned long)_sdata &&
94  addr < (unsigned long)_edata)
95  return 1;
96  return 0;
97  }
98  
99  int __kernel_text_address(unsigned long addr)
   100  {
   101  if (core_kernel_text(addr))
   102  return 1;
   103  if (is_module_text_address(addr))
   104  return 1;
   105  if (is_ftrace_trampoline(addr))
   106  return 1;
   107  /*
   108   * There might be init symbols in saved stacktraces.
   109   * Give those s

Re: [PATCH v2 2/3] extable: verify address is read-only

[kbuild test robot]

Hi Eddie,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
config: x86_64-randconfig-x008-201707 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/trace_clock.h:12:0,
from include/linux/ftrace.h:9,
from kernel/extable.c:18:
   kernel/extable.c: In function 'kernel_ro_address':
   kernel/extable.c:168:6: error: implicit declaration of function 
'is_module_ro_address' [-Werror=implicit-function-declaration]
 if (is_module_ro_address(addr))
 ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/extable.c:168:2: note: in expansion of macro 'if'
 if (is_module_ro_address(addr))
 ^~
   cc1: some warnings being treated as errors

vim +/if +168 kernel/extable.c

12  GNU General Public License for more details.
13  
14  You should have received a copy of the GNU General Public License
15  along with this program; if not, write to the Free Software
16  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  
02111-1307  USA
17  */
  > 18  #include 
19  #include 
20  #include 
21  #include 
22  #include 
23  
24  #include 
25  #include 
26  
27  /*
28   * mutex protecting text section modification (dynamic code patching).
29   * some users need to sleep (allocating memory...) while they hold this 
lock.
30   *
31   * NOT exported to modules - patching kernel text is a really delicate 
matter.
32   */
33  DEFINE_MUTEX(text_mutex);
34  
35  extern struct exception_table_entry __start___ex_table[];
36  extern struct exception_table_entry __stop___ex_table[];
37  
38  /* Cleared by build time tools if the table is already sorted. */
39  u32 __initdata __visible main_extable_sort_needed = 1;
40  
41  /* Sort the kernel's built-in exception table */
42  void __init sort_main_extable(void)
43  {
44  if (main_extable_sort_needed && __stop___ex_table > 
__start___ex_table) {
45  pr_notice("Sorting __ex_table...\n");
46  sort_extable(__start___ex_table, __stop___ex_table);
47  }
48  }
49  
50  /* Given an address, look for it in the exception tables. */
51  const struct exception_table_entry *search_exception_tables(unsigned 
long addr)
52  {
53  const struct exception_table_entry *e;
54  
55  e = search_extable(__start___ex_table, __stop___ex_table-1, 
addr);
56  if (!e)
57  e = search_module_extables(addr);
58  return e;
59  }
60  
61  static inline int init_kernel_text(unsigned long addr)
62  {
63  if (addr >= (unsigned long)_sinittext &&
64  addr < (unsigned long)_einittext)
65  return 1;
66  return 0;
67  }
68  
69  int core_kernel_text(unsigned long addr)
70  {
71  if (addr >= (unsigned long)_stext &&
72  addr < (unsigned long)_etext)
73  return 1;
74  
75  if (system_state == SYSTEM_BOOTING &&
76  init_kernel_text(addr))
77  return 1;
78  return 0;
79  }
80  
81  /**
82   * core_kernel_data - tell if addr points to kernel data
83   * @addr: address to test
84   *
85   * Returns true if @addr passed in is from the core kernel data
86   * section.
87   *
88   * Note: On some archs it may return true for core RODATA, and false
89   *  for others. But will always be true for core RW data.
90   */
91  int core_kernel_data(unsigned long addr)
92  {
93  if (addr >= (unsigned long)_sdata &&
94  addr < (unsigned long)_edata)
95  return 1;
96  return 0;
97  }
98  
99  int __kernel_text_address(unsigned long addr)
   100  {
   101  if (core_kernel_text(addr))
   102  return 1;
   103  if (is_module_text_address(addr))
   104  return 1;
   105  if (is_ftrace_trampoline(addr))
   106  return 1;
   107  /*
   108   * There might be init symbols in saved stacktraces.
   109   * Give those s

Re: [PATCH v2 2/3] extable: verify address is read-only

[kbuild test robot]

Hi Eddie,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/extable.c: In function 'kernel_ro_address':
>> kernel/extable.c:168:6: error: implicit declaration of function 
>> 'is_module_ro_address' [-Werror=implicit-function-declaration]
 if (is_module_ro_address(addr))
 ^~~~
   cc1: some warnings being treated as errors

vim +/is_module_ro_address +168 kernel/extable.c

   162  
   163  /* Verify that address is const or ro_after_init. */
   164  int kernel_ro_address(unsigned long addr)
   165  {
   166  if (core_kernel_ro_data(addr))
   167  return 1;
 > 168  if (is_module_ro_address(addr))
   169  return 1;
   170  
   171  return 0;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [x86] a75a3f6fc9 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Fengguang Wu]

Hi Andy,

On Fri, Feb 17, 2017 at 10:12:36PM -0800, Andy Lutomirski wrote:

On Fri, Feb 17, 2017 at 9:42 PM, Fengguang Wu  wrote:

Greetings,

FYI here is an old bug, however is still active in mainline kernel.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master




[3.185986] init[1] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffe878ff8b8 ax:ff600400 si:7f2c3de62a4c 
di:7ffe878ff978


I don't know what's up with the bisection, but I think this is a
configuration problem in your test setup.  You've configured with:

CONFIG_LEGACY_VSYSCALL_NONE=y

which is not valid when you're running binaries that are compiled with
as old a glibc as you're using.  *Dynamic* glibc binaries have been
fine for a long time, but static glibc binaried (e.g. your init, I
presume) need a glibc that's only a couple years old.

You could fix it by either disallowing that particular configuration
or by updating your distro.


OK, I'll disable that configuration since I'm running various
tiny/large modern/legacy OS images (yocto, openwrt, ubuntu, debian,
RHEL) for doing kernel tests.

Regards,
Fengguang

Re: [PATCH v2 2/3] extable: verify address is read-only

[kbuild test robot]

Hi Eddie,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/extable.c: In function 'kernel_ro_address':
>> kernel/extable.c:168:6: error: implicit declaration of function 
>> 'is_module_ro_address' [-Werror=implicit-function-declaration]
 if (is_module_ro_address(addr))
 ^~~~
   cc1: some warnings being treated as errors

vim +/is_module_ro_address +168 kernel/extable.c

   162  
   163  /* Verify that address is const or ro_after_init. */
   164  int kernel_ro_address(unsigned long addr)
   165  {
   166  if (core_kernel_ro_data(addr))
   167  return 1;
 > 168  if (is_module_ro_address(addr))
   169  return 1;
   170  
   171  return 0;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [x86] a75a3f6fc9 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Fengguang Wu]

Hi Andy,

On Fri, Feb 17, 2017 at 10:12:36PM -0800, Andy Lutomirski wrote:

On Fri, Feb 17, 2017 at 9:42 PM, Fengguang Wu  wrote:

Greetings,

FYI here is an old bug, however is still active in mainline kernel.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master




[3.185986] init[1] vsyscall attempted with vsyscall=none 
ip:ff600400 cs:33 sp:7ffe878ff8b8 ax:ff600400 si:7f2c3de62a4c 
di:7ffe878ff978


I don't know what's up with the bisection, but I think this is a
configuration problem in your test setup.  You've configured with:

CONFIG_LEGACY_VSYSCALL_NONE=y

which is not valid when you're running binaries that are compiled with
as old a glibc as you're using.  *Dynamic* glibc binaries have been
fine for a long time, but static glibc binaried (e.g. your init, I
presume) need a glibc that's only a couple years old.

You could fix it by either disallowing that particular configuration
or by updating your distro.


OK, I'll disable that configuration since I'm running various
tiny/large modern/legacy OS images (yocto, openwrt, ubuntu, debian,
RHEL) for doing kernel tests.

Regards,
Fengguang

Re: [PATCH v2 3/3] Make vmbus register arguments read-only

[kbuild test robot]

Hi Eddie,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
config: i386-randconfig-x007-201707 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/hv/vmbus_drv.c: In function '__vmbus_driver_register':
>> drivers/hv/vmbus_drv.c:1056:26: warning: passing argument 1 of 
>> 'kernel_ro_address' makes integer from pointer without a cast 
>> [-Wint-conversion]
 ret = kernel_ro_address(_driver);
 ^
   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from drivers/hv/vmbus_drv.c:26:
   include/linux/kernel.h:446:12: note: expected 'long unsigned int' but 
argument is of type 'struct hv_driver **'
extern int kernel_ro_address(unsigned long addr);
   ^
   drivers/hv/vmbus_drv.c: In function 'vmbus_device_register':
   drivers/hv/vmbus_drv.c:1127:26: warning: passing argument 1 of 
'kernel_ro_address' makes integer from pointer without a cast [-Wint-conversion]
 ret = kernel_ro_address(_device_obj);
 ^
   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from drivers/hv/vmbus_drv.c:26:
   include/linux/kernel.h:446:12: note: expected 'long unsigned int' but 
argument is of type 'struct hv_device **'
extern int kernel_ro_address(unsigned long addr);
   ^

vim +/kernel_ro_address +1056 drivers/hv/vmbus_drv.c

  1040   *
  1041   * Registers the given driver with Linux through the 
'driver_register()' call
  1042   * and sets up the hyper-v vmbus handling for this driver.
  1043   * It will return the state of the 'driver_register()' call.
  1044   *
  1045   */
  1046  int __vmbus_driver_register(struct hv_driver *hv_driver, struct module 
*owner, const char *mod_name)
  1047  {
  1048  int ret;
  1049  
  1050  pr_info("registering driver %s\n", hv_driver->name);
  1051  
  1052  ret = vmbus_exists();
  1053  if (ret < 0)
  1054  return ret;
  1055  
> 1056  ret = kernel_ro_address(_driver);
  1057  if (ret < 1)
  1058  pr_err("Module address is not read-only.");
  1059  return ret;
  1060  
  1061  hv_driver->driver.name = hv_driver->name;
  1062  hv_driver->driver.owner = owner;
  1063  hv_driver->driver.mod_name = mod_name;
  1064  hv_driver->driver.bus = _bus;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 3/3] Make vmbus register arguments read-only

[kbuild test robot]

Hi Eddie,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
config: i386-randconfig-x007-201707 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/hv/vmbus_drv.c: In function '__vmbus_driver_register':
>> drivers/hv/vmbus_drv.c:1056:26: warning: passing argument 1 of 
>> 'kernel_ro_address' makes integer from pointer without a cast 
>> [-Wint-conversion]
 ret = kernel_ro_address(_driver);
 ^
   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from drivers/hv/vmbus_drv.c:26:
   include/linux/kernel.h:446:12: note: expected 'long unsigned int' but 
argument is of type 'struct hv_driver **'
extern int kernel_ro_address(unsigned long addr);
   ^
   drivers/hv/vmbus_drv.c: In function 'vmbus_device_register':
   drivers/hv/vmbus_drv.c:1127:26: warning: passing argument 1 of 
'kernel_ro_address' makes integer from pointer without a cast [-Wint-conversion]
 ret = kernel_ro_address(_device_obj);
 ^
   In file included from include/linux/list.h:8:0,
from include/linux/module.h:9,
from drivers/hv/vmbus_drv.c:26:
   include/linux/kernel.h:446:12: note: expected 'long unsigned int' but 
argument is of type 'struct hv_device **'
extern int kernel_ro_address(unsigned long addr);
   ^

vim +/kernel_ro_address +1056 drivers/hv/vmbus_drv.c

  1040   *
  1041   * Registers the given driver with Linux through the 
'driver_register()' call
  1042   * and sets up the hyper-v vmbus handling for this driver.
  1043   * It will return the state of the 'driver_register()' call.
  1044   *
  1045   */
  1046  int __vmbus_driver_register(struct hv_driver *hv_driver, struct module 
*owner, const char *mod_name)
  1047  {
  1048  int ret;
  1049  
  1050  pr_info("registering driver %s\n", hv_driver->name);
  1051  
  1052  ret = vmbus_exists();
  1053  if (ret < 0)
  1054  return ret;
  1055  
> 1056  ret = kernel_ro_address(_driver);
  1057  if (ret < 1)
  1058  pr_err("Module address is not read-only.");
  1059  return ret;
  1060  
  1061  hv_driver->driver.name = hv_driver->name;
  1062  hv_driver->driver.owner = owner;
  1063  hv_driver->driver.mod_name = mod_name;
  1064  hv_driver->driver.bus = _bus;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [x86] a75a3f6fc9 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Andy Lutomirski]

On Fri, Feb 17, 2017 at 9:42 PM, Fengguang Wu  wrote:
> Greetings,
>
> FYI here is an old bug, however is still active in mainline kernel.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>

> [3.185986] init[1] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffe878ff8b8 ax:ff600400 si:7f2c3de62a4c 
> di:7ffe878ff978

I don't know what's up with the bisection, but I think this is a
configuration problem in your test setup.  You've configured with:

CONFIG_LEGACY_VSYSCALL_NONE=y

which is not valid when you're running binaries that are compiled with
as old a glibc as you're using.  *Dynamic* glibc binaries have been
fine for a long time, but static glibc binaried (e.g. your init, I
presume) need a glibc that's only a couple years old.

You could fix it by either disallowing that particular configuration
or by updating your distro.

--Andy

Re: [x86] a75a3f6fc9 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Andy Lutomirski]

On Fri, Feb 17, 2017 at 9:42 PM, Fengguang Wu  wrote:
> Greetings,
>
> FYI here is an old bug, however is still active in mainline kernel.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>

> [3.185986] init[1] vsyscall attempted with vsyscall=none 
> ip:ff600400 cs:33 sp:7ffe878ff8b8 ax:ff600400 si:7f2c3de62a4c 
> di:7ffe878ff978

I don't know what's up with the bisection, but I think this is a
configuration problem in your test setup.  You've configured with:

CONFIG_LEGACY_VSYSCALL_NONE=y

which is not valid when you're running binaries that are compiled with
as old a glibc as you're using.  *Dynamic* glibc binaries have been
fine for a long time, but static glibc binaried (e.g. your init, I
presume) need a glibc that's only a couple years old.

You could fix it by either disallowing that particular configuration
or by updating your distro.

--Andy

[PATCH v2 3/3] Make vmbus register arguments read-only

[Eddie Kovsky]

Use the new RO check functions introduced in this series to make the
vmbus register functions verify that the address of their arguments are
read-only. Addresses that fail the verification are rejected.

Signed-off-by: Eddie Kovsky 
---
 drivers/hv/vmbus_drv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index c1b27026f744..e527454ffa59 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1026,6 +1026,11 @@ int __vmbus_driver_register(struct hv_driver *hv_driver, 
struct module *owner, c
if (ret < 0)
return ret;

+   ret = kernel_ro_address(_driver);
+   if (ret < 1)
+   pr_err("Module address is not read-only.");
+   return ret;
+
hv_driver->driver.name = hv_driver->name;
hv_driver->driver.owner = owner;
hv_driver->driver.mod_name = mod_name;
@@ -1092,6 +1097,11 @@ int vmbus_device_register(struct hv_device 
*child_device_obj)
 {
int ret = 0;

+   ret = kernel_ro_address(_device_obj);
+   if (ret < 1)
+   pr_err("Device address is not read-only.");
+   return ret;
+
dev_set_name(_device_obj->device, "%pUl",
 child_device_obj->channel->offermsg.offer.if_instance.b);

--
2.11.1

[PATCH v2 3/3] Make vmbus register arguments read-only

[Eddie Kovsky]

Use the new RO check functions introduced in this series to make the
vmbus register functions verify that the address of their arguments are
read-only. Addresses that fail the verification are rejected.

Signed-off-by: Eddie Kovsky 
---
 drivers/hv/vmbus_drv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index c1b27026f744..e527454ffa59 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1026,6 +1026,11 @@ int __vmbus_driver_register(struct hv_driver *hv_driver, 
struct module *owner, c
if (ret < 0)
return ret;

+   ret = kernel_ro_address(_driver);
+   if (ret < 1)
+   pr_err("Module address is not read-only.");
+   return ret;
+
hv_driver->driver.name = hv_driver->name;
hv_driver->driver.owner = owner;
hv_driver->driver.mod_name = mod_name;
@@ -1092,6 +1097,11 @@ int vmbus_device_register(struct hv_device 
*child_device_obj)
 {
int ret = 0;

+   ret = kernel_ro_address(_device_obj);
+   if (ret < 1)
+   pr_err("Device address is not read-only.");
+   return ret;
+
dev_set_name(_device_obj->device, "%pUl",
 child_device_obj->channel->offermsg.offer.if_instance.b);

--
2.11.1

[PATCH v2 0/3] provide check for ro_after_init memory sections

[Eddie Kovsky]

Provide a mechansim for other functions to verify that their arguments
are read-only. Use this mechansim in the vmbus register functions to
reject arguments that fail this test.

This implements a suggestion made by Kees Cook for the Kernel Self
Protection Project:

* provide mechanism to check for ro_after_init memory areas, and
  reject structures not marked ro_after_init in vmbus_register()

  http://www.openwall.com/lists/kernel-hardening/2017/02/04/1

I have successfully compiled this series on next-20170215 for x86.

Eddie Kovsky (3):
  module: verify address is read-only
  extable: verify address is read-only
  Make vmbus register arguments read-only

 drivers/hv/vmbus_drv.c | 10 ++
 include/linux/kernel.h |  2 ++
 include/linux/module.h |  7 +++
 kernel/extable.c   | 29 +
 kernel/module.c| 44 
 5 files changed, 92 insertions(+)

--
2.11.1

[PATCH v2 0/3] provide check for ro_after_init memory sections

[Eddie Kovsky]

Provide a mechansim for other functions to verify that their arguments
are read-only. Use this mechansim in the vmbus register functions to
reject arguments that fail this test.

This implements a suggestion made by Kees Cook for the Kernel Self
Protection Project:

* provide mechanism to check for ro_after_init memory areas, and
  reject structures not marked ro_after_init in vmbus_register()

  http://www.openwall.com/lists/kernel-hardening/2017/02/04/1

I have successfully compiled this series on next-20170215 for x86.

Eddie Kovsky (3):
  module: verify address is read-only
  extable: verify address is read-only
  Make vmbus register arguments read-only

 drivers/hv/vmbus_drv.c | 10 ++
 include/linux/kernel.h |  2 ++
 include/linux/module.h |  7 +++
 kernel/extable.c   | 29 +
 kernel/module.c| 44 
 5 files changed, 92 insertions(+)

--
2.11.1

[PATCH v2 1/3] module: verify address is read-only

[Eddie Kovsky]

Implement a mechanism to check if a module's address is in
the rodata or ro_after_init sections. It mimics the exsiting functions
that test if an address is inside a module's text section.

Signed-off-by: Eddie Kovsky 
---
 include/linux/module.h |  7 +++
 kernel/module.c| 44 
 2 files changed, 51 insertions(+)

diff --git a/include/linux/module.h b/include/linux/module.h
index 0297c5cd7cdf..1608d3570ee2 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -492,7 +492,9 @@ static inline int module_is_live(struct module *mod)

 struct module *__module_text_address(unsigned long addr);
 struct module *__module_address(unsigned long addr);
+struct module *__module_ro_address(unsigned long addr);
 bool is_module_address(unsigned long addr);
+bool is_module_ro_address(unsigned long addr);
 bool is_module_percpu_address(unsigned long addr);
 bool is_module_text_address(unsigned long addr);

@@ -645,6 +647,11 @@ static inline struct module *__module_address(unsigned 
long addr)
return NULL;
 }

+static inline struct module *__module_ro_address(unsigned long addr)
+{
+   return NULL;
+}
+
 static inline struct module *__module_text_address(unsigned long addr)
 {
return NULL;
diff --git a/kernel/module.c b/kernel/module.c
index 7eba6dea4f41..298cfe4645b1 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4275,6 +4275,50 @@ struct module *__module_text_address(unsigned long addr)
 }
 EXPORT_SYMBOL_GPL(__module_text_address);

+/**
+ * is_module_text_ro_address - is this address inside read-only module code?
+ * @addr: the address to check.
+ *
+ */
+bool is_module_ro_address(unsigned long addr)
+{
+   bool ret;
+
+   preempt_disable();
+   ret = __module_ro_address(addr) != NULL;
+   preempt_enable();
+
+   return ret;
+}
+
+/*
+ * __module_ro_address - get the module whose code contains a read-only 
address.
+ * @addr: the address.
+ *
+ * Must be called with preempt disabled or module mutex held so that
+ * module doesn't get freed during this.
+ */
+struct module *__module_ro_address(unsigned long addr)
+{
+   struct module *mod = __module_address(addr);
+
+   if (mod) {
+   /* Make sure it's within the read-only section. */
+   if (!within(addr, mod->init_layout.base,
+   mod->init_layout.ro_size)
+   && !within(addr, mod->core_layout.base,
+  mod->core_layout.ro_size))
+   mod = NULL;
+   if (!within(addr, mod->init_layout.base,
+   mod->init_layout.ro_after_init_size)
+   && !within(addr, mod->core_layout.base,
+  mod->core_layout.ro_after_init_size))
+   mod = NULL;
+   }
+   return mod;
+}
+EXPORT_SYMBOL_GPL(__module_ro_address);
+
 /* Don't grab lock, we're oopsing. */
 void print_modules(void)
 {
--
2.11.1

[PATCH v2 2/3] extable: verify address is read-only

[Eddie Kovsky]

Provide a mechanism to check if the address of a variable is
const or ro_after_init. It mimics the existing functions that test if an
address is inside the kernel's text section.

Signed-off-by: Eddie Kovsky 
---
 include/linux/kernel.h |  2 ++
 kernel/extable.c   | 29 +
 2 files changed, 31 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..51beea39e6c4 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -444,6 +444,8 @@ extern int core_kernel_data(unsigned long addr);
 extern int __kernel_text_address(unsigned long addr);
 extern int kernel_text_address(unsigned long addr);
 extern int func_ptr_is_kernel_text(void *ptr);
+extern int core_kernel_ro_data(unsigned long addr);
+extern int kernel_ro_address(unsigned long addr);

 unsigned long int_sqrt(unsigned long);

diff --git a/kernel/extable.c b/kernel/extable.c
index 6b0d09051efb..e9608f129730 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -149,3 +149,32 @@ int func_ptr_is_kernel_text(void *ptr)
return 1;
return is_module_text_address(addr);
 }
+
+/**
+ * core_kernel_ro_data - Verify address points to read-only section
+ * @addr: address to test
+ *
+ */
+int core_kernel_ro_data(unsigned long addr)
+{
+   if (addr >= (unsigned long)__start_rodata &&
+   addr < (unsigned long)__end_rodata)
+   return 1;
+
+   if (addr >= (unsigned long)__start_data_ro_after_init &&
+   addr < (unsigned long)__end_data_ro_after_init)
+   return 1;
+
+   return 0;
+}
+
+/* Verify that address is const or ro_after_init. */
+int kernel_ro_address(unsigned long addr)
+{
+   if (core_kernel_ro_data(addr))
+   return 1;
+   if (is_module_ro_address(addr))
+   return 1;
+
+   return 0;
+}
--
2.11.1

[PATCH v2 1/3] module: verify address is read-only

[Eddie Kovsky]

Implement a mechanism to check if a module's address is in
the rodata or ro_after_init sections. It mimics the exsiting functions
that test if an address is inside a module's text section.

Signed-off-by: Eddie Kovsky 
---
 include/linux/module.h |  7 +++
 kernel/module.c| 44 
 2 files changed, 51 insertions(+)

diff --git a/include/linux/module.h b/include/linux/module.h
index 0297c5cd7cdf..1608d3570ee2 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -492,7 +492,9 @@ static inline int module_is_live(struct module *mod)

 struct module *__module_text_address(unsigned long addr);
 struct module *__module_address(unsigned long addr);
+struct module *__module_ro_address(unsigned long addr);
 bool is_module_address(unsigned long addr);
+bool is_module_ro_address(unsigned long addr);
 bool is_module_percpu_address(unsigned long addr);
 bool is_module_text_address(unsigned long addr);

@@ -645,6 +647,11 @@ static inline struct module *__module_address(unsigned 
long addr)
return NULL;
 }

+static inline struct module *__module_ro_address(unsigned long addr)
+{
+   return NULL;
+}
+
 static inline struct module *__module_text_address(unsigned long addr)
 {
return NULL;
diff --git a/kernel/module.c b/kernel/module.c
index 7eba6dea4f41..298cfe4645b1 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4275,6 +4275,50 @@ struct module *__module_text_address(unsigned long addr)
 }
 EXPORT_SYMBOL_GPL(__module_text_address);

+/**
+ * is_module_text_ro_address - is this address inside read-only module code?
+ * @addr: the address to check.
+ *
+ */
+bool is_module_ro_address(unsigned long addr)
+{
+   bool ret;
+
+   preempt_disable();
+   ret = __module_ro_address(addr) != NULL;
+   preempt_enable();
+
+   return ret;
+}
+
+/*
+ * __module_ro_address - get the module whose code contains a read-only 
address.
+ * @addr: the address.
+ *
+ * Must be called with preempt disabled or module mutex held so that
+ * module doesn't get freed during this.
+ */
+struct module *__module_ro_address(unsigned long addr)
+{
+   struct module *mod = __module_address(addr);
+
+   if (mod) {
+   /* Make sure it's within the read-only section. */
+   if (!within(addr, mod->init_layout.base,
+   mod->init_layout.ro_size)
+   && !within(addr, mod->core_layout.base,
+  mod->core_layout.ro_size))
+   mod = NULL;
+   if (!within(addr, mod->init_layout.base,
+   mod->init_layout.ro_after_init_size)
+   && !within(addr, mod->core_layout.base,
+  mod->core_layout.ro_after_init_size))
+   mod = NULL;
+   }
+   return mod;
+}
+EXPORT_SYMBOL_GPL(__module_ro_address);
+
 /* Don't grab lock, we're oopsing. */
 void print_modules(void)
 {
--
2.11.1

[PATCH v2 2/3] extable: verify address is read-only

[Eddie Kovsky]

Provide a mechanism to check if the address of a variable is
const or ro_after_init. It mimics the existing functions that test if an
address is inside the kernel's text section.

Signed-off-by: Eddie Kovsky 
---
 include/linux/kernel.h |  2 ++
 kernel/extable.c   | 29 +
 2 files changed, 31 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..51beea39e6c4 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -444,6 +444,8 @@ extern int core_kernel_data(unsigned long addr);
 extern int __kernel_text_address(unsigned long addr);
 extern int kernel_text_address(unsigned long addr);
 extern int func_ptr_is_kernel_text(void *ptr);
+extern int core_kernel_ro_data(unsigned long addr);
+extern int kernel_ro_address(unsigned long addr);

 unsigned long int_sqrt(unsigned long);

diff --git a/kernel/extable.c b/kernel/extable.c
index 6b0d09051efb..e9608f129730 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -149,3 +149,32 @@ int func_ptr_is_kernel_text(void *ptr)
return 1;
return is_module_text_address(addr);
 }
+
+/**
+ * core_kernel_ro_data - Verify address points to read-only section
+ * @addr: address to test
+ *
+ */
+int core_kernel_ro_data(unsigned long addr)
+{
+   if (addr >= (unsigned long)__start_rodata &&
+   addr < (unsigned long)__end_rodata)
+   return 1;
+
+   if (addr >= (unsigned long)__start_data_ro_after_init &&
+   addr < (unsigned long)__end_data_ro_after_init)
+   return 1;
+
+   return 0;
+}
+
+/* Verify that address is const or ro_after_init. */
+int kernel_ro_address(unsigned long addr)
+{
+   if (core_kernel_ro_data(addr))
+   return 1;
+   if (is_module_ro_address(addr))
+   return 1;
+
+   return 0;
+}
--
2.11.1

[x86] a75a3f6fc9 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Fengguang Wu]

x4c/0x67
[3.190028]  [] ? console_unlock+0x2ed/0x320
[3.190028]  [] panic+0xbc/0x1f6
[3.190028]  [] find_child_reaper+0xa3/0xb0
[3.190028]  [] forget_original_parent+0x3c/0x1e0
[3.190028]  [] exit_notify+0x38/0x1a0
[3.190028]  [] do_exit+0x2a9/0x400
[3.190028]  [] do_group_exit+0x87/0xc0
[3.190028]  [] get_signal+0x33e/0x3a0
[3.190028]  [] ? printk+0x41/0x43
[3.190028]  [] do_signal+0x1b/0xd0
[3.190028]  [] ? do_sched_rt_period_timer+0x190/0x2b0
[3.190028]  [] ? printk+0x41/0x43
[3.190028]  [] ? vtime_account_user+0x93/0xb0
[3.190028]  [] exit_to_usermode_loop+0x4a/0x85
[3.190028]  [] prepare_exit_to_usermode+0x27/0x40
[3.190028]  [] ? enter_from_user_mode+0x45/0x50
[3.190028]  [] retint_user+0x8/0x10
[3.190028] Kernel Offset: disabled

Elapsed time: 10

git bisect start v4.4 v4.3 --
git bisect  bad cd6caf550a2adc763c6301ecc0be01f422fb2aea  # 08:07  0- 
29  Merge tag 'for-linus-4.4' of git://git.code.sf.net/p/openipmi/linux-ipmi
git bisect  bad 713009809681e5a7871e96e6992692c805b4480b  # 08:07  0- 
26  Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect  bad ccf21b69a83afaee4d5499e0d03eacf23946e08c  # 08:07  0- 
26  Merge branch 'for-4.4/reservations' of git://git.kernel.dk/linux-block
git bisect good b831ef2cad979912850e34f82415c0c5d59de8cb  # 08:07 43+  
0  Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad ccc9d4a6d640cbde05d519edeb727881646cf71b  # 08:07  0- 
28  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad f323c49b300baf89e2cb4050b0def1856c0b1852  # 08:07  0- 
28  Merge branch 'x86-cpu-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad a75a3f6fc92888e4119744d8594ffdf748c3d444  # 08:07  0- 
31  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 53528695ff6d8b77011bc818407c13e30914a946  # 08:07 43+  
0  Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d2bea739f8b41d620c235d81e00289d01169dc3c  # 08:07 44+  
0  Merge branch 'x86-apic-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 034042cc1e2837a584cda0a5e4fc2b0a96b74543  # 08:42 39+ 
50  x86/entry/syscalls: Move syscall table declarations into asm/syscalls.h
git bisect good 460d12453e1afe20416ce9536cfecb31d17a9abd  # 09:07 38+ 
21  x86/entry: Make irqs_disabled checks in exit code depend on lockdep
git bisect good f5e6a9753ac2965564a14e6285a06f44043ed9c8  # 09:31 39+ 
26  x86/entry: Split and inline syscall_return_slowpath()
git bisect good af22aa7c766d50712b9afeca53e9e4208ce6284c  # 09:47 40+ 
23  x86/asm: Remove the xyz_cfi macros from dwarf2.h
git bisect good 657c1eea0019e80685a84cbb1919794243a187c9  # 10:10 39+ 
20  x86/entry/32: Fix entry_INT80_32() to expect interrupts to be on
git bisect good 3bd29515d1cad26fa85a1a9b442de8816c1f5c54  # 10:24 39+ 
21  x86/entry/32: Fix FS and GS restore in opportunistic SYSEXIT
# first bad commit: [a75a3f6fc92888e4119744d8594ffdf748c3d444] Merge branch 
'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d2bea739f8b41d620c235d81e00289d01169dc3c  # 10:36114+  
1  Merge branch 'x86-apic-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 3bd29515d1cad26fa85a1a9b442de8816c1f5c54  # 11:12115+ 
89  x86/entry/32: Fix FS and GS restore in opportunistic SYSEXIT
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad a75a3f6fc92888e4119744d8594ffdf748c3d444  # 11:21  0-  
8  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# extra tests on HEAD of linus/master
git bisect  bad 0722f57bfae9abbc673b9dbe495c7da2f64676ea  # 11:21  0- 
73  Merge tag 'drm-fixes-for-v4.10-final' of 
git://people.freedesktop.org/~airlied/linux
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 11:21  0- 
67  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 11:21  0- 
67  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linux-next/master
git bisect good 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 11:40121+
255  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-yocto-vp-48:20170218024722:x86_64-randconfig-w0-02171423:4.3.0-01035-ga75a3f6:2.gz
Description: application/gzip
#
# Automatica

[x86] a75a3f6fc9 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Fengguang Wu]

panic+0xbc/0x1f6
[3.190028]  [] find_child_reaper+0xa3/0xb0
[3.190028]  [] forget_original_parent+0x3c/0x1e0
[3.190028]  [] exit_notify+0x38/0x1a0
[3.190028]  [] do_exit+0x2a9/0x400
[3.190028]  [] do_group_exit+0x87/0xc0
[3.190028]  [] get_signal+0x33e/0x3a0
[3.190028]  [] ? printk+0x41/0x43
[3.190028]  [] do_signal+0x1b/0xd0
[3.190028]  [] ? do_sched_rt_period_timer+0x190/0x2b0
[3.190028]  [] ? printk+0x41/0x43
[3.190028]  [] ? vtime_account_user+0x93/0xb0
[3.190028]  [] exit_to_usermode_loop+0x4a/0x85
[3.190028]  [] prepare_exit_to_usermode+0x27/0x40
[3.190028]  [] ? enter_from_user_mode+0x45/0x50
[3.190028]  [] retint_user+0x8/0x10
[3.190028] Kernel Offset: disabled

Elapsed time: 10

git bisect start v4.4 v4.3 --
git bisect  bad cd6caf550a2adc763c6301ecc0be01f422fb2aea  # 08:07  0- 
29  Merge tag 'for-linus-4.4' of git://git.code.sf.net/p/openipmi/linux-ipmi
git bisect  bad 713009809681e5a7871e96e6992692c805b4480b  # 08:07  0- 
26  Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect  bad ccf21b69a83afaee4d5499e0d03eacf23946e08c  # 08:07  0- 
26  Merge branch 'for-4.4/reservations' of git://git.kernel.dk/linux-block
git bisect good b831ef2cad979912850e34f82415c0c5d59de8cb  # 08:07 43+  
0  Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad ccc9d4a6d640cbde05d519edeb727881646cf71b  # 08:07  0- 
28  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad f323c49b300baf89e2cb4050b0def1856c0b1852  # 08:07  0- 
28  Merge branch 'x86-cpu-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad a75a3f6fc92888e4119744d8594ffdf748c3d444  # 08:07  0- 
31  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 53528695ff6d8b77011bc818407c13e30914a946  # 08:07 43+  
0  Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d2bea739f8b41d620c235d81e00289d01169dc3c  # 08:07 44+  
0  Merge branch 'x86-apic-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 034042cc1e2837a584cda0a5e4fc2b0a96b74543  # 08:42 39+ 
50  x86/entry/syscalls: Move syscall table declarations into asm/syscalls.h
git bisect good 460d12453e1afe20416ce9536cfecb31d17a9abd  # 09:07 38+ 
21  x86/entry: Make irqs_disabled checks in exit code depend on lockdep
git bisect good f5e6a9753ac2965564a14e6285a06f44043ed9c8  # 09:31 39+ 
26  x86/entry: Split and inline syscall_return_slowpath()
git bisect good af22aa7c766d50712b9afeca53e9e4208ce6284c  # 09:47 40+ 
23  x86/asm: Remove the xyz_cfi macros from dwarf2.h
git bisect good 657c1eea0019e80685a84cbb1919794243a187c9  # 10:10 39+ 
20  x86/entry/32: Fix entry_INT80_32() to expect interrupts to be on
git bisect good 3bd29515d1cad26fa85a1a9b442de8816c1f5c54  # 10:24 39+ 
21  x86/entry/32: Fix FS and GS restore in opportunistic SYSEXIT
# first bad commit: [a75a3f6fc92888e4119744d8594ffdf748c3d444] Merge branch 
'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d2bea739f8b41d620c235d81e00289d01169dc3c  # 10:36114+  
1  Merge branch 'x86-apic-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 3bd29515d1cad26fa85a1a9b442de8816c1f5c54  # 11:12115+ 
89  x86/entry/32: Fix FS and GS restore in opportunistic SYSEXIT
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad a75a3f6fc92888e4119744d8594ffdf748c3d444  # 11:21  0-  
8  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# extra tests on HEAD of linus/master
git bisect  bad 0722f57bfae9abbc673b9dbe495c7da2f64676ea  # 11:21  0- 
73  Merge tag 'drm-fixes-for-v4.10-final' of 
git://people.freedesktop.org/~airlied/linux
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 11:21  0- 
67  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 11:21  0- 
67  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linux-next/master
git bisect good 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 11:40121+
255  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-yocto-vp-48:20170218024722:x86_64-randconfig-w0-02171423:4.3.0-01035-ga75a3f6:2.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.3.0 Kernel Con

[x86/vsyscall] 3dc33bd30f Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Fengguang Wu]

Hi Kees,

It's an old patch, however the panic still happens in linux-next 20170217.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit 3dc33bd30f3e1c1bcaaafa3482737694debf0f0b
Author: Kees Cook <keesc...@chromium.org>
AuthorDate: Wed Aug 12 17:55:19 2015 -0700
Commit: Ingo Molnar <mi...@kernel.org>
CommitDate: Sun Sep 20 10:31:06 2015 +0200

 x86/entry/vsyscall: Add CONFIG to control default
 
 Most modern systems can run with vsyscall=none. In an effort to
 provide a way for build-time defaults to lack legacy settings,
 this adds a new CONFIG to select the type of vsyscall mapping to
 use, similar to the existing "vsyscall" command line parameter.
 
 Signed-off-by: Kees Cook <keesc...@chromium.org>
 Acked-by: Andy Lutomirski <l...@amacapital.net>
 Cc: Borislav Petkov <b...@alien8.de>
 Cc: Brian Gerst <brge...@gmail.com>
 Cc: Denys Vlasenko <dvlas...@redhat.com>
 Cc: H. Peter Anvin <h...@zytor.com>
 Cc: Josh Triplett <j...@joshtriplett.org>
 Cc: Linus Torvalds <torva...@linux-foundation.org>
 Cc: Peter Zijlstra <pet...@infradead.org>
 Cc: Thomas Gleixner <t...@linutronix.de>
 Link: http://lkml.kernel.org/r/20150813005519.ga11...@www.outflux.net
 Signed-off-by: Ingo Molnar <mi...@kernel.org>

+---+++---+
|   | c25be94f28 | 
3dc33bd30f | v4.10-rc8 |
+---+++---+
| boot_successes| 252| 32   
  | 25|
| boot_failures | 0  | 56   
  | 31|
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0  | 54   
  | 28|
| BUG:kernel_reboot-without-warning_in_boot_stage   | 0  | 2
  |   |
| BUG:kernel_hang_in_test_stage | 0  | 0
  | 2 |
| BUG:kernel_reboot-without-warning_in_test_stage   | 0  | 0
  | 1 |
+---+++---+

[   12.110061] floppy: error -5 while reading block 0
[   12.130066] floppy: error -5 while reading block 0
[   12.198488] gfs2: path_lookup on rootfs returned error -2
[   12.203718] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[   12.203718] 
[   12.206760] CPU: 0 PID: 1 Comm: init Not tainted 4.3.0-rc1-00133-g3dc33bd #1
[   12.208393] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   12.210006]   88001e8cfca8 8133b2e0 
88001e8cfd28
[   12.210006]  810dd97a 0010 88001e8cfd38 
88001e8cfcd0
[   12.210006]  88001e8d8000 000b 88001e8e4010 
0001
[   12.210006] Call Trace:
[   12.210006]  [] dump_stack+0x19/0x1b
[   12.210006]  [] panic+0xb5/0x1db
[   12.210006]  [] do_exit+0x3fa/0x7d9
[   12.210006]  [] do_group_exit+0x39/0xa1
[   12.210006]  [] get_signal+0x4a0/0x4e1
[   12.210006]  [] do_signal+0x23/0x440
[   12.210006]  [] ? ___ratelimit+0xc8/0xe2
[   12.210006]  [] ? __printk_ratelimit+0x13/0x15
[   12.210006]  [] ? warn_bad_vsyscall+0x2e/0x83
[   12.210006]  [] ? bad_area_nosemaphore+0xe/0x10
[   12.210006]  [] ? __do_page_fault+0x15e/0x345
[   12.210006]  [] prepare_exit_to_usermode+0x74/0x9d
[   12.210006]  [] retint_user+0x8/0x10
[   12.210006] Kernel Offset: disabled

Elapsed time: 20

git bisect start v4.4 v4.3 --
git bisect  bad cd6caf550a2adc763c6301ecc0be01f422fb2aea  # 02:16  7-  
9  Merge tag 'for-linus-4.4' of git://git.code.sf.net/p/openipmi/linux-ipmi
git bisect  bad 713009809681e5a7871e96e6992692c805b4480b  # 02:30  0-  
2  Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect  bad ccf21b69a83afaee4d5499e0d03eacf23946e08c  # 02:41  0- 
12  Merge branch 'for-4.4/reservations' of git://git.kernel.dk/linux-block
git bisect good b831ef2cad979912850e34f82415c0c5d59de8cb  # 02:58 59+  
0  Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad ccc9d4a6d640cbde05d519edeb727881646cf71b  # 03:14 30-  
5  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad f323c49b300baf89e2cb4050b0def1856c0b1852  # 03:24  0- 
15  Merge branch 'x86-cpu-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad a75a3f6fc92888e4119744d8594ffdf748c3d444  # 03:35  0-  
6  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/li

[x86/vsyscall] 3dc33bd30f Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Fengguang Wu]

Hi Kees,

It's an old patch, however the panic still happens in linux-next 20170217.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit 3dc33bd30f3e1c1bcaaafa3482737694debf0f0b
Author: Kees Cook 
AuthorDate: Wed Aug 12 17:55:19 2015 -0700
Commit: Ingo Molnar 
CommitDate: Sun Sep 20 10:31:06 2015 +0200

 x86/entry/vsyscall: Add CONFIG to control default
 
 Most modern systems can run with vsyscall=none. In an effort to
 provide a way for build-time defaults to lack legacy settings,
 this adds a new CONFIG to select the type of vsyscall mapping to
 use, similar to the existing "vsyscall" command line parameter.
 
 Signed-off-by: Kees Cook 
 Acked-by: Andy Lutomirski 
 Cc: Borislav Petkov 
 Cc: Brian Gerst 
 Cc: Denys Vlasenko 
 Cc: H. Peter Anvin 
 Cc: Josh Triplett 
 Cc: Linus Torvalds 
 Cc: Peter Zijlstra 
 Cc: Thomas Gleixner 
 Link: http://lkml.kernel.org/r/20150813005519.ga11...@www.outflux.net
 Signed-off-by: Ingo Molnar 

+---+++---+
|   | c25be94f28 | 
3dc33bd30f | v4.10-rc8 |
+---+++---+
| boot_successes| 252| 32   
  | 25|
| boot_failures | 0  | 56   
  | 31|
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0  | 54   
  | 28|
| BUG:kernel_reboot-without-warning_in_boot_stage   | 0  | 2
  |   |
| BUG:kernel_hang_in_test_stage | 0  | 0
  | 2 |
| BUG:kernel_reboot-without-warning_in_test_stage   | 0  | 0
  | 1 |
+---+++---+

[   12.110061] floppy: error -5 while reading block 0
[   12.130066] floppy: error -5 while reading block 0
[   12.198488] gfs2: path_lookup on rootfs returned error -2
[   12.203718] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[   12.203718] 
[   12.206760] CPU: 0 PID: 1 Comm: init Not tainted 4.3.0-rc1-00133-g3dc33bd #1
[   12.208393] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   12.210006]   88001e8cfca8 8133b2e0 
88001e8cfd28
[   12.210006]  810dd97a 0010 88001e8cfd38 
88001e8cfcd0
[   12.210006]  88001e8d8000 000b 88001e8e4010 
0001
[   12.210006] Call Trace:
[   12.210006]  [] dump_stack+0x19/0x1b
[   12.210006]  [] panic+0xb5/0x1db
[   12.210006]  [] do_exit+0x3fa/0x7d9
[   12.210006]  [] do_group_exit+0x39/0xa1
[   12.210006]  [] get_signal+0x4a0/0x4e1
[   12.210006]  [] do_signal+0x23/0x440
[   12.210006]  [] ? ___ratelimit+0xc8/0xe2
[   12.210006]  [] ? __printk_ratelimit+0x13/0x15
[   12.210006]  [] ? warn_bad_vsyscall+0x2e/0x83
[   12.210006]  [] ? bad_area_nosemaphore+0xe/0x10
[   12.210006]  [] ? __do_page_fault+0x15e/0x345
[   12.210006]  [] prepare_exit_to_usermode+0x74/0x9d
[   12.210006]  [] retint_user+0x8/0x10
[   12.210006] Kernel Offset: disabled

Elapsed time: 20

git bisect start v4.4 v4.3 --
git bisect  bad cd6caf550a2adc763c6301ecc0be01f422fb2aea  # 02:16  7-  
9  Merge tag 'for-linus-4.4' of git://git.code.sf.net/p/openipmi/linux-ipmi
git bisect  bad 713009809681e5a7871e96e6992692c805b4480b  # 02:30  0-  
2  Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect  bad ccf21b69a83afaee4d5499e0d03eacf23946e08c  # 02:41  0- 
12  Merge branch 'for-4.4/reservations' of git://git.kernel.dk/linux-block
git bisect good b831ef2cad979912850e34f82415c0c5d59de8cb  # 02:58 59+  
0  Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad ccc9d4a6d640cbde05d519edeb727881646cf71b  # 03:14 30-  
5  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad f323c49b300baf89e2cb4050b0def1856c0b1852  # 03:24  0- 
15  Merge branch 'x86-cpu-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad a75a3f6fc92888e4119744d8594ffdf748c3d444  # 03:35  0-  
6  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 53528695ff6d8b77011bc818407c13e30914a946  # 03:56 81+  
0  Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d2bea739f8b41d620c235d81e00289d01169dc3c  # 04:13 82+  
0  Merge branch 'x86-apic-for-linus' of 
git://git.kernel.org/pub/scm/li

[GIT] Networking

[David Miller]

1) Fix leak in dpaa_eth error paths, from Dan Carpenter.

2) Use after free when using IPV6_RECVPKTINFO, from Andrey Konovalov.

3) fanout_release() cannot be invoked from atomic contexts, from
   Anoob Soman.

4) Fix bogus attempt at lockdep annotation in IRDA.

5) dev_fill_metadata_dst() can OOP on a NULL dst cache pointer, from
   Paolo Abeni.

Please pull, thanks a lot!

The following changes since commit 4695daefba8df8a11fa0b0edd595eedae9ea59ae:

  Merge tag 'media/v4.10-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2017-02-16 
10:22:41 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 4c03b862b12f980456f9de92db6d508a4999b788:

  irda: Fix lockdep annotations in hashbin_delete(). (2017-02-17 16:19:39 -0500)


Andrey Konovalov (1):
  dccp: fix freeing skb too early for IPV6_RECVPKTINFO

Anoob Soman (1):
  packet: Do not call fanout_release from atomic contexts

Dan Carpenter (1):
  dpaa_eth: small leak on error

David S. Miller (1):
  irda: Fix lockdep annotations in hashbin_delete().

Paolo Abeni (1):
  vxlan: fix oops in dev_fill_metadata_dst

 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c |  2 +-
 drivers/net/vxlan.c|  6 --
 net/dccp/input.c   |  3 ++-
 net/irda/irqueue.c | 34 
--
 net/packet/af_packet.c | 31 
++-
 5 files changed, 45 insertions(+), 31 deletions(-)

[GIT] Networking

[David Miller]

1) Fix leak in dpaa_eth error paths, from Dan Carpenter.

2) Use after free when using IPV6_RECVPKTINFO, from Andrey Konovalov.

3) fanout_release() cannot be invoked from atomic contexts, from
   Anoob Soman.

4) Fix bogus attempt at lockdep annotation in IRDA.

5) dev_fill_metadata_dst() can OOP on a NULL dst cache pointer, from
   Paolo Abeni.

Please pull, thanks a lot!

The following changes since commit 4695daefba8df8a11fa0b0edd595eedae9ea59ae:

  Merge tag 'media/v4.10-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2017-02-16 
10:22:41 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 4c03b862b12f980456f9de92db6d508a4999b788:

  irda: Fix lockdep annotations in hashbin_delete(). (2017-02-17 16:19:39 -0500)


Andrey Konovalov (1):
  dccp: fix freeing skb too early for IPV6_RECVPKTINFO

Anoob Soman (1):
  packet: Do not call fanout_release from atomic contexts

Dan Carpenter (1):
  dpaa_eth: small leak on error

David S. Miller (1):
  irda: Fix lockdep annotations in hashbin_delete().

Paolo Abeni (1):
  vxlan: fix oops in dev_fill_metadata_dst

 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c |  2 +-
 drivers/net/vxlan.c|  6 --
 net/dccp/input.c   |  3 ++-
 net/irda/irqueue.c | 34 
--
 net/packet/af_packet.c | 31 
++-
 5 files changed, 45 insertions(+), 31 deletions(-)

[drm] bea5b158ff BUG: unable to handle kernel NULL pointer dereference at 0000000000000748

[Fengguang Wu]

] bochs_init+0x17/0x19
[   11.781978]  [] do_one_initcall+0x89/0x11a
[   11.783233]  [] ? do_early_param+0x8f/0x8f
[   11.784497]  [] kernel_init_freeable+0x17f/0x215
[   11.785866]  [] kernel_init+0x9/0xf0
[   11.786990]  [] ret_from_fork+0x1f/0x40
[   11.788216]  [] ? rest_init+0xc0/0xc0
[   11.789367] Code: 85 93 07 00 00 48 c7 c1 5a 44 d7 81 48 c7 c2 2e 10 d7 81 
be 92 0c 00 00 48 c7 c7 20 84 d7 81 e8 94 0f fd ff e9 f1 08 00 00 89 f0 <49> 8b 
44 c6 08 48 85 c0 75 21 31 d2 4c 89 f7 44 89 45 d0 89 4d 
[   11.794799] RIP  [] __lock_acquire+0x93/0x9a0
[   11.796299]  RSP 
[   11.797093] CR2: 0748
[   11.797859] ---[ end trace 103f598e68dbf79f ]---
[   11.798934] Kernel panic - not syncing: Fatal exception

git bisect start v4.9 v4.8 --
git bisect  bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942  # 05:25  0-  
1  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad 5fa0eb0b4d4780fbd6d8a09850cc4fd539e9fe65  # 05:35  0-  
4  Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b  # 05:50  0-  
1  Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa
git bisect  bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c  # 06:14  0-  
1  Merge tag 'usb-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f  # 06:45 20+  
0  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 49deffe0b0e4c2030696c7a6fd680bacf4761069  # 07:35 20+  
0  Merge tag 'arc-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
git bisect good 597f03f9d133e9837d00965016170271d4f87dcf  # 08:15 20+  
0  Merge branch 'smp-hotplug-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad 9929780e86854833e649b39b290b5fe921eb1701  # 08:43  0-  
1  Merge tag 'driver-core-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
git bisect good 7a53eea1f7b527fd3b6d7ca992914840981afe99  # 08:57 21+  
1  Merge tag 'char-misc-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect  bad 775115c06091fcfa1189a50aca488fa596839617  # 09:29  0-  
2  drivers/base dmam_declare_coherent_memory leaks
git bisect  bad 426bc8e789f8ac84270b196191904d347586032f  # 09:40  0-  
3  base: soc: make it explicitly non-modular
git bisect  bad bea5b158ff0da9c7246ff391f754f5f38e34577a  # 09:53  0-  
2  driver core: add test of driver remove calls during probe
git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50  # 10:04 21+  
0  driver core: fix race between creating/querying glue dir and its cleanup
# first bad commit: [bea5b158ff0da9c7246ff391f754f5f38e34577a] driver core: add 
test of driver remove calls during probe
git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50  # 10:13 60+  
0  driver core: fix race between creating/querying glue dir and its cleanup
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad bea5b158ff0da9c7246ff391f754f5f38e34577a  # 10:25  0- 
12  driver core: add test of driver remove calls during probe
# extra tests on HEAD of linux-devel/devel-spot-201702160837
git bisect  bad b1ac88375913cf81c56dbf5a2c9b64863f188ee2  # 10:25  0- 
25  0day head guard for 'devel-spot-201702160837'
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 10:43  0-  
1  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 10:43  0-  
2  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linux-next/master
git bisect  bad 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 11:07  0-  
1  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-quantal-vp-95:20170218095527:x86_64-randconfig-ne0-02160954:4.8.0-rc4-3-gbea5b15:1.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CON

[drm] bea5b158ff BUG: unable to handle kernel NULL pointer dereference at 0000000000000748

[Fengguang Wu]

]  [] kernel_init+0x9/0xf0
[   11.786990]  [] ret_from_fork+0x1f/0x40
[   11.788216]  [] ? rest_init+0xc0/0xc0
[   11.789367] Code: 85 93 07 00 00 48 c7 c1 5a 44 d7 81 48 c7 c2 2e 10 d7 81 
be 92 0c 00 00 48 c7 c7 20 84 d7 81 e8 94 0f fd ff e9 f1 08 00 00 89 f0 <49> 8b 
44 c6 08 48 85 c0 75 21 31 d2 4c 89 f7 44 89 45 d0 89 4d 
[   11.794799] RIP  [] __lock_acquire+0x93/0x9a0
[   11.796299]  RSP 
[   11.797093] CR2: 0748
[   11.797859] ---[ end trace 103f598e68dbf79f ]---
[   11.798934] Kernel panic - not syncing: Fatal exception

git bisect start v4.9 v4.8 --
git bisect  bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942  # 05:25  0-  
1  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect  bad 5fa0eb0b4d4780fbd6d8a09850cc4fd539e9fe65  # 05:35  0-  
4  Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b  # 05:50  0-  
1  Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa
git bisect  bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c  # 06:14  0-  
1  Merge tag 'usb-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f  # 06:45 20+  
0  Merge branch 'x86-asm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 49deffe0b0e4c2030696c7a6fd680bacf4761069  # 07:35 20+  
0  Merge tag 'arc-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
git bisect good 597f03f9d133e9837d00965016170271d4f87dcf  # 08:15 20+  
0  Merge branch 'smp-hotplug-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad 9929780e86854833e649b39b290b5fe921eb1701  # 08:43  0-  
1  Merge tag 'driver-core-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
git bisect good 7a53eea1f7b527fd3b6d7ca992914840981afe99  # 08:57 21+  
1  Merge tag 'char-misc-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect  bad 775115c06091fcfa1189a50aca488fa596839617  # 09:29  0-  
2  drivers/base dmam_declare_coherent_memory leaks
git bisect  bad 426bc8e789f8ac84270b196191904d347586032f  # 09:40  0-  
3  base: soc: make it explicitly non-modular
git bisect  bad bea5b158ff0da9c7246ff391f754f5f38e34577a  # 09:53  0-  
2  driver core: add test of driver remove calls during probe
git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50  # 10:04 21+  
0  driver core: fix race between creating/querying glue dir and its cleanup
# first bad commit: [bea5b158ff0da9c7246ff391f754f5f38e34577a] driver core: add 
test of driver remove calls during probe
git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50  # 10:13 60+  
0  driver core: fix race between creating/querying glue dir and its cleanup
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad bea5b158ff0da9c7246ff391f754f5f38e34577a  # 10:25  0- 
12  driver core: add test of driver remove calls during probe
# extra tests on HEAD of linux-devel/devel-spot-201702160837
git bisect  bad b1ac88375913cf81c56dbf5a2c9b64863f188ee2  # 10:25  0- 
25  0day head guard for 'devel-spot-201702160837'
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 10:43  0-  
1  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linus/master
git bisect  bad 6dc39c50e4aeb769c8ae06edf2b1a732f3490913  # 10:43  0-  
2  Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linux-next/master
git bisect  bad 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 11:07  0-  
1  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-quantal-vp-95:20170218095527:x86_64-randconfig-ne0-02160954:4.8.0-rc4-3-gbea5b15:1.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_P

[x86/mm] e1a58320a3 WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page()

[Fengguang Wu]

] kernel_init+0x4f/0x1e7
[8.135000]  [] ret_from_kernel_thread+0x20/0x30
[8.135838]  [] ? rest_init+0x158/0x158
[8.136562] ---[ end trace 01b3950ee29e5eb2 ]---
[8.137417] x86/mm: Checked W+X mappings: FAILED, 6893 W+X pages found.

git bisect start v4.4 v4.3 --
git bisect  bad cd6caf550a2adc763c6301ecc0be01f422fb2aea  # 01:50  0-  
7  Merge tag 'for-linus-4.4' of git://git.code.sf.net/p/openipmi/linux-ipmi
git bisect  bad 713009809681e5a7871e96e6992692c805b4480b  # 02:01  0- 
21  Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect  bad ccf21b69a83afaee4d5499e0d03eacf23946e08c  # 02:08  0- 
10  Merge branch 'for-4.4/reservations' of git://git.kernel.dk/linux-block
git bisect good b831ef2cad979912850e34f82415c0c5d59de8cb  # 02:24 27+  
0  Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad ccc9d4a6d640cbde05d519edeb727881646cf71b  # 02:35  0-  
1  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect good f323c49b300baf89e2cb4050b0def1856c0b1852  # 02:48 28+  
0  Merge branch 'x86-cpu-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 4302d506d5f3419109abdd0d6e400ed6e8148209  # 03:05 27+  
0  Merge branch 'x86-headers-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2  # 03:17  0-  
8  Merge branch 'x86-mm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 34437e67a6727885bdf6cbfd8441b1ac43a1ee65  # 03:28 28+  
0  x86/mm: Fix slow_virt_to_phys() to handle large PAT bit
git bisect good d551aaa2f7e1387fa66093ce9914c2e91f283a50  # 03:44 28+  
0  x86/mm: Fix __split_large_page() to handle large PAT bit
git bisect good 38a413cbc2b2834683b21823d964bc2d2f0abb82  # 04:05 28+  
0  Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new 
changes
git bisect  bad e1a58320a38dfa72be48a0f1a3a92273663ba6db  # 04:11  0-  
2  x86/mm: Warn on W^X mappings
# first bad commit: [e1a58320a38dfa72be48a0f1a3a92273663ba6db] x86/mm: Warn on 
W^X mappings
git bisect good 38a413cbc2b2834683b21823d964bc2d2f0abb82  # 04:21 78+  
0  Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new 
changes
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad e1a58320a38dfa72be48a0f1a3a92273663ba6db  # 04:29  0-  
1  x86/mm: Warn on W^X mappings
# extra tests on HEAD of linux-devel/devel-catchup-201702172121
git bisect  bad 9cad9cbdbedc6cc3196cb840bdf3785d77a15c7a  # 04:29  0- 
27  0day head guard for 'devel-catchup-201702172121'
# extra tests on tree/branch linus/master
git bisect  bad 2fe1e8a7b2f4dcac3fcb07ff06b0ae7396201fd6  # 04:30  0-  
2  Merge tag 'powerpc-4.10-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
# extra tests on tree/branch linus/master
git bisect  bad 2fe1e8a7b2f4dcac3fcb07ff06b0ae7396201fd6  # 04:30  0-  
2  Merge tag 'powerpc-4.10-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
# extra tests on tree/branch linux-next/master
git bisect  bad 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 04:35  0- 
28  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-quantal-ivb41-143:20170218041522:i386-randconfig-s0-201707:4.3.0-rc3-00013-ge1a5832:119.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.3.0-rc3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXT

[x86/mm] e1a58320a3 WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page()

[Fengguang Wu]

://git.code.sf.net/p/openipmi/linux-ipmi
git bisect  bad 713009809681e5a7871e96e6992692c805b4480b  # 02:01  0- 
21  Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
git bisect  bad ccf21b69a83afaee4d5499e0d03eacf23946e08c  # 02:08  0- 
10  Merge branch 'for-4.4/reservations' of git://git.kernel.dk/linux-block
git bisect good b831ef2cad979912850e34f82415c0c5d59de8cb  # 02:24 27+  
0  Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad ccc9d4a6d640cbde05d519edeb727881646cf71b  # 02:35  0-  
1  Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect good f323c49b300baf89e2cb4050b0def1856c0b1852  # 02:48 28+  
0  Merge branch 'x86-cpu-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 4302d506d5f3419109abdd0d6e400ed6e8148209  # 03:05 27+  
0  Merge branch 'x86-headers-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect  bad 639ab3eb38c6e92e27e061551dddee6dd3bbb5d2  # 03:17  0-  
8  Merge branch 'x86-mm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 34437e67a6727885bdf6cbfd8441b1ac43a1ee65  # 03:28 28+  
0  x86/mm: Fix slow_virt_to_phys() to handle large PAT bit
git bisect good d551aaa2f7e1387fa66093ce9914c2e91f283a50  # 03:44 28+  
0  x86/mm: Fix __split_large_page() to handle large PAT bit
git bisect good 38a413cbc2b2834683b21823d964bc2d2f0abb82  # 04:05 28+  
0  Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new 
changes
git bisect  bad e1a58320a38dfa72be48a0f1a3a92273663ba6db  # 04:11  0-  
2  x86/mm: Warn on W^X mappings
# first bad commit: [e1a58320a38dfa72be48a0f1a3a92273663ba6db] x86/mm: Warn on 
W^X mappings
git bisect good 38a413cbc2b2834683b21823d964bc2d2f0abb82  # 04:21 78+  
0  Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new 
changes
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect  bad e1a58320a38dfa72be48a0f1a3a92273663ba6db  # 04:29  0-  
1  x86/mm: Warn on W^X mappings
# extra tests on HEAD of linux-devel/devel-catchup-201702172121
git bisect  bad 9cad9cbdbedc6cc3196cb840bdf3785d77a15c7a  # 04:29  0- 
27  0day head guard for 'devel-catchup-201702172121'
# extra tests on tree/branch linus/master
git bisect  bad 2fe1e8a7b2f4dcac3fcb07ff06b0ae7396201fd6  # 04:30  0-  
2  Merge tag 'powerpc-4.10-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
# extra tests on tree/branch linus/master
git bisect  bad 2fe1e8a7b2f4dcac3fcb07ff06b0ae7396201fd6  # 04:30  0-  
2  Merge tag 'powerpc-4.10-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
# extra tests on tree/branch linux-next/master
git bisect  bad 4ce4a759a3e221b5265ebd03c2fb69a7cf3e  # 04:35  0- 
28  Add linux-next specific files for 20170217


---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp  Intel Corporation


dmesg-quantal-ivb41-143:20170218041522:i386-randconfig-s0-201707:4.3.0-rc3-00013-ge1a5832:119.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.3.0-rc3 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is n

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

[Edward O'Callaghan]

On 02/18/2017 01:22 AM, Christian König wrote:
> Am 17.02.2017 um 08:11 schrieb Joe Perches:
>> To enable eventual removal of pr_warning
>>
>> This makes pr_warn use consistent for drivers/gpu
>>
>> Prior to this patch, there were 15 uses of pr_warning and
>> 20 uses of pr_warn in drivers/gpu
>>
>> Signed-off-by: Joe Perches 
> 
> Acked-by: Christian König .

Reviewed-by: Edward O'Callaghan 

> 
>> ---
>>   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  2 +-
>>   drivers/gpu/drm/amd/powerplay/inc/pp_debug.h |  2 +-
>>   drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |  4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 14
>> +++---
>>   drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |  4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |  4 ++--
>>   6 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index b1de9e8ccdbc..83266408634e 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -1535,7 +1535,7 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
>> *hwmgr)
>>   if (vddc >= 2000 || vddc == 0)
>>   return -EINVAL;
>>   } else {
>> -pr_warning("failed to retrieving EVV voltage!\n");
>> +pr_warn("failed to retrieving EVV voltage!\n");
>>   continue;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> index 072880130cfb..f3f9ebb631a5 100644
>> --- a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> +++ b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> @@ -37,7 +37,7 @@
>>   #define PP_ASSERT_WITH_CODE(cond, msg, code)\
>>   do {\
>>   if (!(cond)) {\
>> -pr_warning("%s\n", msg);\
>> +pr_warn("%s\n", msg);\
>>   code;\
>>   }\
>>   } while (0)
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> index 0f7a77b7312e..5450f5ef8e89 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> @@ -2131,7 +2131,7 @@ uint32_t fiji_get_offsetof(uint32_t type,
>> uint32_t member)
>>   return offsetof(SMU73_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>>   }
>>   }
>> -pr_warning("can't get the offset of type %x member %x\n", type,
>> member);
>> +pr_warn("can't get the offset of type %x member %x\n", type,
>> member);
>>   return 0;
>>   }
>>   @@ -2156,7 +2156,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
>>   return SMU73_MAX_LEVELS_MVDD;
>>   }
>>   -pr_warning("can't get the mac of %x\n", value);
>> +pr_warn("can't get the mac of %x\n", value);
>>   return 0;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> index ad82161df831..51adf04ab4b3 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> @@ -122,7 +122,7 @@ static void
>> iceland_initialize_power_tune_defaults(struct pp_hwmgr *hwmgr)
>>   break;
>>   default:
>>   smu_data->power_tune_defaults = _iceland;
>> -pr_warning("Unknown V.I. Device ID.\n");
>> +pr_warn("Unknown V.I. Device ID.\n");
>>   break;
>>   }
>>   return;
>> @@ -378,7 +378,7 @@ static int
>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>   return -EINVAL);
>> if (NULL == hwmgr->dyn_state.cac_leakage_table) {
>> -pr_warning("CAC Leakage Table does not exist, using vddc.\n");
>> +pr_warn("CAC Leakage Table does not exist, using vddc.\n");
>>   return 0;
>>   }
>>   @@ -394,7 +394,7 @@ static int
>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>   *lo =
>> hwmgr->dyn_state.cac_leakage_table->entries[v_index].Vddc *
>> VOLTAGE_SCALE;
>>   *hi =
>> (uint16_t)(hwmgr->dyn_state.cac_leakage_table->entries[v_index].Leakage *
>> VOLTAGE_SCALE);
>>   } else {
>> -pr_warning("Index from SCLK/VDDC Dependency Table
>> exceeds the CAC Leakage Table index, using maximum index from CAC
>> table.\n");
>> +pr_warn("Index from SCLK/VDDC Dependency Table
>> exceeds the CAC Leakage Table index, using maximum index from CAC
>> table.\n");
>>   *lo =
>> hwmgr->dyn_state.cac_leakage_table->entries[hwmgr->dyn_state.cac_leakage_table->count
>> - 1].Vddc * VOLTAGE_SCALE;
>>  

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

[Edward O'Callaghan]

On 02/18/2017 01:22 AM, Christian König wrote:
> Am 17.02.2017 um 08:11 schrieb Joe Perches:
>> To enable eventual removal of pr_warning
>>
>> This makes pr_warn use consistent for drivers/gpu
>>
>> Prior to this patch, there were 15 uses of pr_warning and
>> 20 uses of pr_warn in drivers/gpu
>>
>> Signed-off-by: Joe Perches 
> 
> Acked-by: Christian König .

Reviewed-by: Edward O'Callaghan 

> 
>> ---
>>   drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  2 +-
>>   drivers/gpu/drm/amd/powerplay/inc/pp_debug.h |  2 +-
>>   drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |  4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 14
>> +++---
>>   drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |  4 ++--
>>   drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |  4 ++--
>>   6 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index b1de9e8ccdbc..83266408634e 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -1535,7 +1535,7 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
>> *hwmgr)
>>   if (vddc >= 2000 || vddc == 0)
>>   return -EINVAL;
>>   } else {
>> -pr_warning("failed to retrieving EVV voltage!\n");
>> +pr_warn("failed to retrieving EVV voltage!\n");
>>   continue;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> index 072880130cfb..f3f9ebb631a5 100644
>> --- a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> +++ b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
>> @@ -37,7 +37,7 @@
>>   #define PP_ASSERT_WITH_CODE(cond, msg, code)\
>>   do {\
>>   if (!(cond)) {\
>> -pr_warning("%s\n", msg);\
>> +pr_warn("%s\n", msg);\
>>   code;\
>>   }\
>>   } while (0)
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> index 0f7a77b7312e..5450f5ef8e89 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
>> @@ -2131,7 +2131,7 @@ uint32_t fiji_get_offsetof(uint32_t type,
>> uint32_t member)
>>   return offsetof(SMU73_Discrete_DpmTable,
>> LowSclkInterruptThreshold);
>>   }
>>   }
>> -pr_warning("can't get the offset of type %x member %x\n", type,
>> member);
>> +pr_warn("can't get the offset of type %x member %x\n", type,
>> member);
>>   return 0;
>>   }
>>   @@ -2156,7 +2156,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
>>   return SMU73_MAX_LEVELS_MVDD;
>>   }
>>   -pr_warning("can't get the mac of %x\n", value);
>> +pr_warn("can't get the mac of %x\n", value);
>>   return 0;
>>   }
>>   diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> index ad82161df831..51adf04ab4b3 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
>> @@ -122,7 +122,7 @@ static void
>> iceland_initialize_power_tune_defaults(struct pp_hwmgr *hwmgr)
>>   break;
>>   default:
>>   smu_data->power_tune_defaults = _iceland;
>> -pr_warning("Unknown V.I. Device ID.\n");
>> +pr_warn("Unknown V.I. Device ID.\n");
>>   break;
>>   }
>>   return;
>> @@ -378,7 +378,7 @@ static int
>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>   return -EINVAL);
>> if (NULL == hwmgr->dyn_state.cac_leakage_table) {
>> -pr_warning("CAC Leakage Table does not exist, using vddc.\n");
>> +pr_warn("CAC Leakage Table does not exist, using vddc.\n");
>>   return 0;
>>   }
>>   @@ -394,7 +394,7 @@ static int
>> iceland_get_std_voltage_value_sidd(struct pp_hwmgr *hwmgr,
>>   *lo =
>> hwmgr->dyn_state.cac_leakage_table->entries[v_index].Vddc *
>> VOLTAGE_SCALE;
>>   *hi =
>> (uint16_t)(hwmgr->dyn_state.cac_leakage_table->entries[v_index].Leakage *
>> VOLTAGE_SCALE);
>>   } else {
>> -pr_warning("Index from SCLK/VDDC Dependency Table
>> exceeds the CAC Leakage Table index, using maximum index from CAC
>> table.\n");
>> +pr_warn("Index from SCLK/VDDC Dependency Table
>> exceeds the CAC Leakage Table index, using maximum index from CAC
>> table.\n");
>>   *lo =
>> hwmgr->dyn_state.cac_leakage_table->entries[hwmgr->dyn_state.cac_leakage_table->count
>> - 1].Vddc * VOLTAGE_SCALE;
>>   *hi =
>> 

[PATCH] tiny: remove a redundant semicolon in wait.h

[colyli]

In the end of macro wait_event_interruptible_lock_irq_timeout(), there is
a semicolon, and at the location where this macro is referenced by macro
wait_event_interruptible_lock_irq_timeout(), there is another semicolon,
then we have two semicolon at end of a line. 

Redundant semicolons here doesn't hurt, just remove it as a really tiny
fix.

Signed-off-by: Coly Li 
Cc: Jiri Kosina 
---
 include/linux/wait.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 1421132..7b318cd 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -938,7 +938,7 @@ do {
\
  TASK_INTERRUPTIBLE, 0, timeout,   \
  spin_unlock_irq();   \
  __ret = schedule_timeout(__ret);  \
- spin_lock_irq());
+ spin_lock_irq())
 
 /**
  * wait_event_interruptible_lock_irq_timeout - sleep until a condition gets
-- 
2.6.6

[PATCH] tiny: remove a redundant semicolon in wait.h

[colyli]

In the end of macro wait_event_interruptible_lock_irq_timeout(), there is
a semicolon, and at the location where this macro is referenced by macro
wait_event_interruptible_lock_irq_timeout(), there is another semicolon,
then we have two semicolon at end of a line. 

Redundant semicolons here doesn't hurt, just remove it as a really tiny
fix.

Signed-off-by: Coly Li 
Cc: Jiri Kosina 
---
 include/linux/wait.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 1421132..7b318cd 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -938,7 +938,7 @@ do {
\
  TASK_INTERRUPTIBLE, 0, timeout,   \
  spin_unlock_irq();   \
  __ret = schedule_timeout(__ret);  \
- spin_lock_irq());
+ spin_lock_irq())
 
 /**
  * wait_event_interruptible_lock_irq_timeout - sleep until a condition gets
-- 
2.6.6

Re: [PATCH] staging: rtl8192u: Fix warnings about endianness

[maomao]

On February 16, 2017 4:31:16 AM GMT+08:00, Dan Carpenter 
 wrote:
>On Wed, Feb 15, 2017 at 09:33:15AM +0100, Arnd Bergmann wrote:
>> I see the same warning was addressed very differently in 99277c1f9962
>> ("Staging: rtl8192e: Fix Sparse warning of cast to restricted __le16
>in
>>  rtllib_crypt_tkip.c"), which was for a close relative of that
>driver.
>> 
>> Only one of the two approaches (at most) can be correct, so we
>> regardless of your patch either rtl8192e or rtl8192u is broken on
>> big-endian machines.
>
>99277c1f9962 ("Staging: rtl8192e: Fix Sparse warning of cast to
>restricted __le16 in
>rtllib_crypt_tkip.c") is obviously broken.  Can you send a patch to
>change it back?
>
>regards,
>dan carpenter
yes,I have done.But I have receive nothing about this patch from lkml for days

-- 
Sent from Kaiten Mail. Please excuse my brevity.

Re: [PATCH] staging: rtl8192u: Fix warnings about endianness

[maomao]

On February 16, 2017 4:31:16 AM GMT+08:00, Dan Carpenter 
 wrote:
>On Wed, Feb 15, 2017 at 09:33:15AM +0100, Arnd Bergmann wrote:
>> I see the same warning was addressed very differently in 99277c1f9962
>> ("Staging: rtl8192e: Fix Sparse warning of cast to restricted __le16
>in
>>  rtllib_crypt_tkip.c"), which was for a close relative of that
>driver.
>> 
>> Only one of the two approaches (at most) can be correct, so we
>> regardless of your patch either rtl8192e or rtl8192u is broken on
>> big-endian machines.
>
>99277c1f9962 ("Staging: rtl8192e: Fix Sparse warning of cast to
>restricted __le16 in
>rtllib_crypt_tkip.c") is obviously broken.  Can you send a patch to
>change it back?
>
>regards,
>dan carpenter
yes,I have done.But I have receive nothing about this patch from lkml for days

-- 
Sent from Kaiten Mail. Please excuse my brevity.

[PATCH] bcm2048: Fix checkpatch checks

[Man Choy]

Fix following checks:

CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
+   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);

CHECK: spaces preferred around that '+' (ctx:VxV)
+   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
 ^

CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
+   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);

CHECK: spaces preferred around that '+' (ctx:VxV)
+   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
 ^
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 37bd439..d5ee279 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1534,7 +1534,7 @@ static int bcm2048_parse_rt_match_c(struct bcm2048_device 
*bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return 0;
 
-   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
+   WARN_ON((index + 2) >= BCM2048_MAX_RDS_RT);
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_C) {
@@ -1557,7 +1557,7 @@ static void bcm2048_parse_rt_match_d(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return;
 
-   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
+   WARN_ON((index + 4) >= BCM2048_MAX_RDS_RT);
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_D)
-- 
2.7.4

[PATCH] bcm2048: Fix checkpatch checks

[Man Choy]

Fix following checks:

CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
+   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);

CHECK: spaces preferred around that '+' (ctx:VxV)
+   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
 ^

CHECK: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
+   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);

CHECK: spaces preferred around that '+' (ctx:VxV)
+   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
 ^
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 37bd439..d5ee279 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1534,7 +1534,7 @@ static int bcm2048_parse_rt_match_c(struct bcm2048_device 
*bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return 0;
 
-   BUG_ON((index+2) >= BCM2048_MAX_RDS_RT);
+   WARN_ON((index + 2) >= BCM2048_MAX_RDS_RT);
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_C) {
@@ -1557,7 +1557,7 @@ static void bcm2048_parse_rt_match_d(struct 
bcm2048_device *bdev, int i,
if (crc == BCM2048_RDS_CRC_UNRECOVARABLE)
return;
 
-   BUG_ON((index+4) >= BCM2048_MAX_RDS_RT);
+   WARN_ON((index + 4) >= BCM2048_MAX_RDS_RT);
 
if ((bdev->rds_info.radio_text[i] & BCM2048_RDS_BLOCK_MASK) ==
BCM2048_RDS_BLOCK_D)
-- 
2.7.4

RFC: Getting rid of LTR in VMX

[Andy Lutomirski]

There's no code here because the patch is trivial, but I want to run
the idea by you all first to see if there are any issues.

VMX is silly and forces the TSS limit to the minimum on VM exits.  KVM
wastes lots of cycles bumping it back up to accomodate the io bitmap.

I propose that we rework this.  Add a percpu variable that indicates
whether the TSS limit needs to be refreshed.  On task switch, if the
new task has TIF_IO_BITMAP set, then check that flag and, if set,
refresh TR and clear the flag.  On VMX exit, set the flag.

The TSS limit is (phew!) invisible to userspace, so we don't have ABI
issues to worry about here.  We also shouldn't have security issues
because a too-low TSS limit just results in unprivileged IO operations
generating #GP, which is exactly what we want.

What do you all think?  I expect a speedup of a couple hundred cycles
on each VM exit.

RFC: Getting rid of LTR in VMX

[Andy Lutomirski]

There's no code here because the patch is trivial, but I want to run
the idea by you all first to see if there are any issues.

VMX is silly and forces the TSS limit to the minimum on VM exits.  KVM
wastes lots of cycles bumping it back up to accomodate the io bitmap.

I propose that we rework this.  Add a percpu variable that indicates
whether the TSS limit needs to be refreshed.  On task switch, if the
new task has TIF_IO_BITMAP set, then check that flag and, if set,
refresh TR and clear the flag.  On VMX exit, set the flag.

The TSS limit is (phew!) invisible to userspace, so we don't have ABI
issues to worry about here.  We also shouldn't have security issues
because a too-low TSS limit just results in unprivileged IO operations
generating #GP, which is exactly what we want.

What do you all think?  I expect a speedup of a couple hundred cycles
on each VM exit.

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

Hi,

On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> > AFAIK there is no mainline board using the DT except ours (and the upcoming
> > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove 
> > this
> > compatibility property. We don't need it for our devices.

$ cd linux.git/arch
$ git grep -l tsc2004
arm/boot/dts/imx6qdl-nit6xlite.dtsi
arm/boot/dts/imx7d-nitrogen7.dts
arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
arm/boot/dts/omap4-var-som-om44.dtsi
$ git grep -l tsc2005
arm/boot/dts/omap3-n900.dts
$ git grep -l tsc2007
arm/boot/dts/imx28-tx28.dts
arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
arm/boot/dts/imx53-tx53-x03x.dts
arm/boot/dts/imx6qdl-tx6.dtsi
arm/boot/dts/imx6ul-tx6ul.dtsi
arm/boot/dts/omap3-gta04.dtsi
sh/boards/mach-ecovec24/setup.c

> You seem to be treating DT data as something very fluid, which is wrong.
> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.
> 
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
> 
>  
> > That the function name is wrong is a second issue and this double negation 
> > might
> > confuse a litte.
> > 
> > Please test on a real device if the patched driver reports pressure now 
> > (unless
> > ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.
> So all my observations are from code and data sheets.
> 
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

As far as I can see all calculate Rtouch and ADS7846 reports
(Rmax - Rtouch), which looks sensible.

> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

I think tsc200x works, since usually userspace is Xorg and I think
it only cares for x/y coordinates + boolean pressure. Since
no-pressure is correctly reported as 0, everything works as
expected. I currently don't have X running on my N900 due some
omapdrm bug, so I can't test this, sorry.

I suggest to put the resistance vs pressure thing in its own patch,
that also fixes tsc200x-core and merge it to linux-next after the
merge window.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Sebastian Reichel]

Hi,

On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> > AFAIK there is no mainline board using the DT except ours (and the upcoming
> > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove 
> > this
> > compatibility property. We don't need it for our devices.

$ cd linux.git/arch
$ git grep -l tsc2004
arm/boot/dts/imx6qdl-nit6xlite.dtsi
arm/boot/dts/imx7d-nitrogen7.dts
arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
arm/boot/dts/omap4-var-som-om44.dtsi
$ git grep -l tsc2005
arm/boot/dts/omap3-n900.dts
$ git grep -l tsc2007
arm/boot/dts/imx28-tx28.dts
arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
arm/boot/dts/imx53-tx53-x03x.dts
arm/boot/dts/imx6qdl-tx6.dtsi
arm/boot/dts/imx6ul-tx6ul.dtsi
arm/boot/dts/omap3-gta04.dtsi
sh/boards/mach-ecovec24/setup.c

> You seem to be treating DT data as something very fluid, which is wrong.
> You need to treat it as a firmware, unlikely to change once device is
> shipped. Unlike legacy platform data, the fact that DTS files are not
> present in mainline does not mean that we can ignore such users and
> change behavior at will.
> 
> That said, if driver behavior is out of line from the subsystem
> expectations, we need to fix it.
> 
>  
> > That the function name is wrong is a second issue and this double negation 
> > might
> > confuse a litte.
> > 
> > Please test on a real device if the patched driver reports pressure now 
> > (unless
> > ti,report-resistance is specified).
> 
> I unfortunately can not test this driver as I do not have the hardware.
> So all my observations are from code and data sheets.
> 
> That said, what is the values emitted as ABS_PRESSURE when finger is not
> touching the device, barely touching the device, or pressing firmly?
> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
> confusion as to what is being reported.

As far as I can see all calculate Rtouch and ADS7846 reports
(Rmax - Rtouch), which looks sensible.

> I am adding a few more folks to the CC so we can try and soft this out.
> Sebastian, Pali, Pavel, any input here?

I think tsc200x works, since usually userspace is Xorg and I think
it only cares for x/y coordinates + boolean pressure. Since
no-pressure is correctly reported as 0, everything works as
expected. I currently don't have X running on my N900 due some
omapdrm bug, so I can't test this, sorry.

I suggest to put the resistance vs pressure thing in its own patch,
that also fixes tsc200x-core and merge it to linux-next after the
merge window.

-- Sebastian


signature.asc
Description: PGP signature

[net-next][PATCH v1] RDS: keep data type consistent in the user visible header

[Santosh Shilimkar]

rds.h is exported to /usr/include/rds.h,  so u8, u64 leads to
errors like below.

/usr/include/linux/rds.h:197: error: expected specifier-qualifier-list before 
'u8'
/usr/include/linux/rds.h:202: error: expected specifier-qualifier-list before 
'u8'

Fix it by following same types as rest of the user header.

Reported-by: Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
---
V1: Fixed the email id typo

 include/uapi/linux/rds.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index 3833113..a9e4c02 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -194,14 +194,14 @@ enum rds_message_rxpath_latency {
 };
 
 struct rds_rx_trace_so {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 struct rds_cmsg_rx_trace {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
-   u64 rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint64_t rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 /*
-- 
1.9.1

[net-next][PATCH v1] RDS: keep data type consistent in the user visible header

[Santosh Shilimkar]

rds.h is exported to /usr/include/rds.h,  so u8, u64 leads to
errors like below.

/usr/include/linux/rds.h:197: error: expected specifier-qualifier-list before 
'u8'
/usr/include/linux/rds.h:202: error: expected specifier-qualifier-list before 
'u8'

Fix it by following same types as rest of the user header.

Reported-by: Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
---
V1: Fixed the email id typo

 include/uapi/linux/rds.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index 3833113..a9e4c02 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -194,14 +194,14 @@ enum rds_message_rxpath_latency {
 };
 
 struct rds_rx_trace_so {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 struct rds_cmsg_rx_trace {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
-   u64 rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint64_t rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 /*
-- 
1.9.1

[net-next][PATCH] RDS: keep data type consistent in the user visible header

[Santosh Shilimkar]

From: Santosh Shilimkar 

rds.h is exported to /usr/include/rds.h,  so u8, u64 leads to
errors like below.

/usr/include/linux/rds.h:197: error: expected specifier-qualifier-list before 
'u8'
/usr/include/linux/rds.h:202: error: expected specifier-qualifier-list before 
'u8'

Fix it by following same types as rest of the user header.

Reported-by: Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
---
 include/uapi/linux/rds.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index 3833113..a9e4c02 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -194,14 +194,14 @@ enum rds_message_rxpath_latency {
 };
 
 struct rds_rx_trace_so {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 struct rds_cmsg_rx_trace {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
-   u64 rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint64_t rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 /*
-- 
1.9.1

[net-next][PATCH] RDS: keep data type consistent in the user visible header

[Santosh Shilimkar]

From: Santosh Shilimkar 

rds.h is exported to /usr/include/rds.h,  so u8, u64 leads to
errors like below.

/usr/include/linux/rds.h:197: error: expected specifier-qualifier-list before 
'u8'
/usr/include/linux/rds.h:202: error: expected specifier-qualifier-list before 
'u8'

Fix it by following same types as rest of the user header.

Reported-by: Sowmini Varadhan 
Signed-off-by: Santosh Shilimkar 
---
 include/uapi/linux/rds.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
index 3833113..a9e4c02 100644
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -194,14 +194,14 @@ enum rds_message_rxpath_latency {
 };
 
 struct rds_rx_trace_so {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 struct rds_cmsg_rx_trace {
-   u8 rx_traces;
-   u8 rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
-   u64 rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint8_t rx_traces;
+   uint8_t rx_trace_pos[RDS_MSG_RX_DGRAM_TRACE_MAX];
+   uint64_t rx_trace[RDS_MSG_RX_DGRAM_TRACE_MAX];
 };
 
 /*
-- 
1.9.1

Re: [PATCH] Staging: ks7010: ks_*: Braces should be used on all arms of these statements

[Joe Perches]

On Fri, 2017-02-17 at 14:50 -0800, Joe Perches wrote:
> On Fri, 2017-02-17 at 22:41 +0100, Shiva Kerdel wrote:
> > Braces should be used on all arms of these statements (CHECK)..
> 
> []
> > diff --git a/drivers/staging/ks7010/ks_hostif.c 
> > b/drivers/staging/ks7010/ks_hostif.c
> 
> []
> > @@ -2148,8 +2148,9 @@ void hostif_sme_mode_setup(struct ks_wlan_private 
> > *priv)
> > else
> > rate_octet[i] =
> > priv->reg.rate_set.body[i];
> > -   } else
> > +   } else {
> > break;
> > +   }
> 
> Generally, any time you see a form like this,
> the test should be reversed
> 
>   for/while/do {
>   if (foo) {
>   [bar...]
>   } else {
>   break;
>   }
>   
> should be:
> 
>   for/while/do {
>   if (!foo)
>   break;
>   [bar...]
>   }

btw: the code would read better using
 a temporary. Something like:

if (priv->reg.phy_type == D_11B_ONLY_MODE) {
for (i = 0; i < priv->reg.rate_set.size; i++) {
u8 rate = priv->reg.rate_set.body[i];

if (!IS_11B_RATE(rate))
break;
rate_octet[i] = ((rate & RATE_MASK) >= TX_RATE_5M)
? (rate & RATE_MASK) : rate;
}

Re: [PATCH] Staging: ks7010: ks_*: Braces should be used on all arms of these statements

[Joe Perches]

On Fri, 2017-02-17 at 14:50 -0800, Joe Perches wrote:
> On Fri, 2017-02-17 at 22:41 +0100, Shiva Kerdel wrote:
> > Braces should be used on all arms of these statements (CHECK)..
> 
> []
> > diff --git a/drivers/staging/ks7010/ks_hostif.c 
> > b/drivers/staging/ks7010/ks_hostif.c
> 
> []
> > @@ -2148,8 +2148,9 @@ void hostif_sme_mode_setup(struct ks_wlan_private 
> > *priv)
> > else
> > rate_octet[i] =
> > priv->reg.rate_set.body[i];
> > -   } else
> > +   } else {
> > break;
> > +   }
> 
> Generally, any time you see a form like this,
> the test should be reversed
> 
>   for/while/do {
>   if (foo) {
>   [bar...]
>   } else {
>   break;
>   }
>   
> should be:
> 
>   for/while/do {
>   if (!foo)
>   break;
>   [bar...]
>   }

btw: the code would read better using
 a temporary. Something like:

if (priv->reg.phy_type == D_11B_ONLY_MODE) {
for (i = 0; i < priv->reg.rate_set.size; i++) {
u8 rate = priv->reg.rate_set.body[i];

if (!IS_11B_RATE(rate))
break;
rate_octet[i] = ((rate & RATE_MASK) >= TX_RATE_5M)
? (rate & RATE_MASK) : rate;
}

Re: [RFC 7/8] fpga-region: add sysfs interface

[Moritz Fischer]

On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
> 
>   whatever solution we decide to go with has to work with other OS'es. The 
> last thing we want to do is to have wrappers that are Linux specific.

I do agree that we should make sure the format is reasonably well
documented. In my earlier email I pointed out several projects
successfully integrating libfdt.
There's nothing Linux specific about libfdt. FreeBSD uses it, U-Boot,
Qemu ...

I know nothing about how windows kernel development works, but I assume
however one goes about making FPGA programming work there, someone will
most likely have to write a kernel mode driver to take the job of the
fpga-mgr framework.
I assume this will be written in C or C++ or whatever people use these
days for kernel development so pulling in libfdt shouldn't be too hard
if we were to try that.

To be clear:
I did not suggest fdt to make it hard for other OSs, or because this is
my personal pet project. I think we're more likely to get it right by
reusing an existing format, with parsers that other people already
successfully use. It does not have to be fdt (I suggested that because
that was around), but  I do think we certainly can do better than
HTTP-eque plaintext headers.

Thanks,

Moritz

Re: [RFC 7/8] fpga-region: add sysfs interface

[Moritz Fischer]

On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
> 
>   whatever solution we decide to go with has to work with other OS'es. The 
> last thing we want to do is to have wrappers that are Linux specific.

I do agree that we should make sure the format is reasonably well
documented. In my earlier email I pointed out several projects
successfully integrating libfdt.
There's nothing Linux specific about libfdt. FreeBSD uses it, U-Boot,
Qemu ...

I know nothing about how windows kernel development works, but I assume
however one goes about making FPGA programming work there, someone will
most likely have to write a kernel mode driver to take the job of the
fpga-mgr framework.
I assume this will be written in C or C++ or whatever people use these
days for kernel development so pulling in libfdt shouldn't be too hard
if we were to try that.

To be clear:
I did not suggest fdt to make it hard for other OSs, or because this is
my personal pet project. I think we're more likely to get it right by
reusing an existing format, with parsers that other people already
successfully use. It does not have to be fdt (I suggested that because
that was around), but  I do think we certainly can do better than
HTTP-eque plaintext headers.

Thanks,

Moritz

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Adan Hawthorn]

Ok, I personally like that better anyhow.  Also, there was mention of
the line limit even exceeding 100 characters (130ish?) and that was
being tossed around at one point (if I remember correctly).

On Fri, Feb 17, 2017 at 8:38 PM, Joe Perches  wrote:
> On Fri, 2017-02-17 at 20:32 -0500, Adan Hawthorn wrote:
>> Thanks, Joe.
>>
>> Is this to say that scripts/checkpatch.pl should be updated to some
>> higher column limit?  I have made these cleanup changes before in a
>> like manner.
>
> Hard to say.
>
> There could be some sensitivity to long identifier
> name lengths added to checkpatch, but < 80 column
> line length is still currently "strongly preferred".
>
> I don't care much one way or another if it's 80
> or 100 or something else as long as it's context
> appropriate.
>
> Awhile ago, Linus Torvalds wrote:
>
> On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
>> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches  wrote:
>> > >
>> > > In fact, I thought we already upped the check-patch limit to 100?
>> >
>> > Nope, CodingStyle neither.
>> >
>> > Last time I tried was awhile ago.
>>
>> Ok, it must have been just talked about, and with the exceptions for
>> strings etc I may not have seen as many of the really annoying line
>> breaks lately.
>>
>> I don't mind a 80-column "soft limit" per se: if some code
>> consistently goes over 80 columns, there really is something seriously
>> wrong there. So 80 columns may well be the right limit for that kind
>> of check (or even less).
>>
>> But if we have just a couple of lines that are longer (in a file that
>> is 3k+ lines), I'd rather not break those.
>>
>> I tend use "git grep" a lot, and it's much easier to see function
>> argument use if it's all on one line.
>>
>> Of course, some function calls really are *so* long that they have to
>> be broken up, but that's where the "if it's a couple of lines that go
>> a bit over the 80 column limit..." exception basically comes in.
>>
>> Put another way: long lines definitely aren't good. But breaking long
>> lines has some downsides too, so there should be a balance between the
>> two, rather than some black-and-white limit.
>>
>> In fact, we've seldom had cases where black-and-white limits work well.
>>

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Adan Hawthorn]

Ok, I personally like that better anyhow.  Also, there was mention of
the line limit even exceeding 100 characters (130ish?) and that was
being tossed around at one point (if I remember correctly).

On Fri, Feb 17, 2017 at 8:38 PM, Joe Perches  wrote:
> On Fri, 2017-02-17 at 20:32 -0500, Adan Hawthorn wrote:
>> Thanks, Joe.
>>
>> Is this to say that scripts/checkpatch.pl should be updated to some
>> higher column limit?  I have made these cleanup changes before in a
>> like manner.
>
> Hard to say.
>
> There could be some sensitivity to long identifier
> name lengths added to checkpatch, but < 80 column
> line length is still currently "strongly preferred".
>
> I don't care much one way or another if it's 80
> or 100 or something else as long as it's context
> appropriate.
>
> Awhile ago, Linus Torvalds wrote:
>
> On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
>> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches  wrote:
>> > >
>> > > In fact, I thought we already upped the check-patch limit to 100?
>> >
>> > Nope, CodingStyle neither.
>> >
>> > Last time I tried was awhile ago.
>>
>> Ok, it must have been just talked about, and with the exceptions for
>> strings etc I may not have seen as many of the really annoying line
>> breaks lately.
>>
>> I don't mind a 80-column "soft limit" per se: if some code
>> consistently goes over 80 columns, there really is something seriously
>> wrong there. So 80 columns may well be the right limit for that kind
>> of check (or even less).
>>
>> But if we have just a couple of lines that are longer (in a file that
>> is 3k+ lines), I'd rather not break those.
>>
>> I tend use "git grep" a lot, and it's much easier to see function
>> argument use if it's all on one line.
>>
>> Of course, some function calls really are *so* long that they have to
>> be broken up, but that's where the "if it's a couple of lines that go
>> a bit over the 80 column limit..." exception basically comes in.
>>
>> Put another way: long lines definitely aren't good. But breaking long
>> lines has some downsides too, so there should be a balance between the
>> two, rather than some black-and-white limit.
>>
>> In fact, we've seldom had cases where black-and-white limits work well.
>>

Re: [PATCH] MAINTAINERS: cpufreq: add bmips-cpufreq.c

[Rafael J. Wysocki]

On Friday, February 17, 2017 05:26:59 PM Florian Fainelli wrote:
> 
> On 02/17/2017 05:20 PM, Rafael J. Wysocki wrote:
> > On Friday, February 17, 2017 11:24:56 AM Florian Fainelli wrote:
> >> On 02/17/2017 10:30 AM, Markus Mayer wrote:
> >>> From: Markus Mayer 
> >>>
> >>> Add maintainer information for bmips-cpufreq.c.
> >>>
> >>> Signed-off-by: Markus Mayer 
> >>
> >> Looks great, thanks for adding this, one nit below:
> >>
> >>> ---
> >>>
> >>> This is based on PM's linux-next from today (February 17).
> >>>
> >>> This patch could be squashed into patch 3/4 of the original series if that
> >>> is acceptable (see [1]) or it can remain separate.
> >>>
> >>> [1] https://lkml.org/lkml/2017/2/7/775
> >>>
> >>>  MAINTAINERS | 6 ++
> >>>  1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index 107c10e..db251c0 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -2692,6 +2692,12 @@ F: drivers/irqchip/irq-brcmstb*
> >>>  F:   include/linux/bcm963xx_nvram.h
> >>>  F:   include/linux/bcm963xx_tag.h
> >>>  
> >>> +BROADCOM BMIPS CPUFREQ DRIVER
> >>> +M:   Markus Mayer 
> >>> +L:   linux...@vger.kernel.org
> >>
> >> Please also include bcm-kernel-feedback-l...@broadcom.com here
> >>
> >> With that:
> >>
> >> Acked-by: Florian Fainelli 
> >>
> > 
> > Patch applied.
> 
> There was a v2 submitted shortly after.

I took the v2 actually, sorry for the confusion.

Thanks,
Rafael

Re: [PATCH] MAINTAINERS: cpufreq: add bmips-cpufreq.c

[Rafael J. Wysocki]

On Friday, February 17, 2017 05:26:59 PM Florian Fainelli wrote:
> 
> On 02/17/2017 05:20 PM, Rafael J. Wysocki wrote:
> > On Friday, February 17, 2017 11:24:56 AM Florian Fainelli wrote:
> >> On 02/17/2017 10:30 AM, Markus Mayer wrote:
> >>> From: Markus Mayer 
> >>>
> >>> Add maintainer information for bmips-cpufreq.c.
> >>>
> >>> Signed-off-by: Markus Mayer 
> >>
> >> Looks great, thanks for adding this, one nit below:
> >>
> >>> ---
> >>>
> >>> This is based on PM's linux-next from today (February 17).
> >>>
> >>> This patch could be squashed into patch 3/4 of the original series if that
> >>> is acceptable (see [1]) or it can remain separate.
> >>>
> >>> [1] https://lkml.org/lkml/2017/2/7/775
> >>>
> >>>  MAINTAINERS | 6 ++
> >>>  1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index 107c10e..db251c0 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -2692,6 +2692,12 @@ F: drivers/irqchip/irq-brcmstb*
> >>>  F:   include/linux/bcm963xx_nvram.h
> >>>  F:   include/linux/bcm963xx_tag.h
> >>>  
> >>> +BROADCOM BMIPS CPUFREQ DRIVER
> >>> +M:   Markus Mayer 
> >>> +L:   linux...@vger.kernel.org
> >>
> >> Please also include bcm-kernel-feedback-l...@broadcom.com here
> >>
> >> With that:
> >>
> >> Acked-by: Florian Fainelli 
> >>
> > 
> > Patch applied.
> 
> There was a v2 submitted shortly after.

I took the v2 actually, sorry for the confusion.

Thanks,
Rafael

[RFC][PATCH] cpufreq: User/admin documentation update and consolidation

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The user/admin documentation of cpufreq is badly outdated.  It
conains stale and/or inaccurate information along with things
that are not particularly useful.  Also, some of the important
pieces are missing from it.

For this reason, add a new user/admin document for cpufreq
containing current information to admin-guide and drop the old
outdated .txt documents it is replacing.

Since there will be more PM documents in admin-guide going forward,
create a separate directory for them and put the cpufreq document
in there right away.

Signed-off-by: Rafael J. Wysocki 
---

Something I've been working on for quite a while recently.

Comments welcome.  In particular, please check if the information in the new
doc is as accurate as it should be (please note that it documents the current
state, so new code changes under discussion are not reflected by it).

Thanks,
Rafael

---
 Documentation/admin-guide/index.rst  |1 
 Documentation/admin-guide/pm/cpufreq.rst |  699 +++
 Documentation/admin-guide/pm/index.rst   |   15 
 Documentation/cpu-freq/boost.txt |   93 
 Documentation/cpu-freq/governors.txt |  301 -
 Documentation/cpu-freq/user-guide.txt|  226 --
 6 files changed, 715 insertions(+), 620 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
===
--- /dev/null
+++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
@@ -0,0 +1,699 @@
+.. |struct| replace:: :c:type:`struct`
+
+===
+CPU Performance Scaling
+===
+
+::
+
+ Copyright (c) 2017 Intel Corp., Rafael J. Wysocki 
+
+The Concept of CPU Performance Scaling
+==
+
+The majority of modern processors are capable of operating in a number of
+different clock frequency and voltage configurations, often referred to as
+Operating Performance Points or P-states (in ACPI terminology).  As a rule,
+the higher the clock frequency and the higher the voltage, the more 
instructions
+can be retired by the CPU over a unit of time, but also the higher the clock
+frequency and the higher the voltage, the more energy is consumed over a unit 
of
+time (or the more power is drawn) by the CPU in the given P-state.  Therefore
+there is a natural tradeoff between the CPU capacity (the number of 
instructions
+that can be executed over a unit of time) and the power drawn by the CPU.
+
+In some situations it is desirable or even necessary to run the program as fast
+as possible and then there is no reason to use any P-states different from the
+highest one (i.e. the highest-performance frequency/voltage configuration
+available).  In some other cases, however, it may not be necessary to execute
+instructions so quickly and maintaining the highest available CPU capacity for 
a
+relatively long time without utilizing it entirely may be regarded as wasteful.
+It also may not be physically possible to maintain maximum CPU capacity for too
+long for thermal or power supply capacity reasons or similar.  To cover those
+cases, there are hardware interfaces allowing CPUs to be switched between
+different frequency/voltage configurations or (in the ACPI terminology) to be
+put into different P-states.
+
+Typically, they are used along with algorithms to estimate the required CPU
+capacity, so as to decide which P-states to put the CPUs into.  Of course, 
since
+the utilization of the system generally changes over time, that has to be done
+repeatedly on a regular basis.  The activity by which this happens is referred
+to as CPU performance scaling or CPU frequency scaling (because it involves
+adjusting the CPU clock frequency).
+
+
+CPU Performance Scaling in Linux
+
+
+The Linux kernel supports CPU performance scaling by means of the ``CPUFreq``
+(CPU Frequency scaling) subsystem that consists of three layers of code: the
+core, scaling governors and scaling drivers.
+
+The ``CPUFreq`` core provides the common code infrastructure and user space
+interfaces for all platforms that support CPU performance scaling.  It defines
+the basic framework in which the other components operate.
+
+Scaling governors implement algorithms to estimate the required CPU capacity.
+As a rule, each governor implements one, possibly parametrized, scaling
+algorithm.
+
+Scaling drivers talk to the hardware.  They provide scaling governors with
+information on the available P-states (or P-state ranges in some cases) and
+access platform-specific hardware interfaces to change CPU P-states as 
requested
+by scaling governors.
+
+In principle, all available scaling governors can be used with every scaling
+driver.  That design is based on the observation that the information used by
+performance scaling algorithms for P-state selection can be 

[RFC][PATCH] cpufreq: User/admin documentation update and consolidation

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The user/admin documentation of cpufreq is badly outdated.  It
conains stale and/or inaccurate information along with things
that are not particularly useful.  Also, some of the important
pieces are missing from it.

For this reason, add a new user/admin document for cpufreq
containing current information to admin-guide and drop the old
outdated .txt documents it is replacing.

Since there will be more PM documents in admin-guide going forward,
create a separate directory for them and put the cpufreq document
in there right away.

Signed-off-by: Rafael J. Wysocki 
---

Something I've been working on for quite a while recently.

Comments welcome.  In particular, please check if the information in the new
doc is as accurate as it should be (please note that it documents the current
state, so new code changes under discussion are not reflected by it).

Thanks,
Rafael

---
 Documentation/admin-guide/index.rst  |1 
 Documentation/admin-guide/pm/cpufreq.rst |  699 +++
 Documentation/admin-guide/pm/index.rst   |   15 
 Documentation/cpu-freq/boost.txt |   93 
 Documentation/cpu-freq/governors.txt |  301 -
 Documentation/cpu-freq/user-guide.txt|  226 --
 6 files changed, 715 insertions(+), 620 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
===
--- /dev/null
+++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
@@ -0,0 +1,699 @@
+.. |struct| replace:: :c:type:`struct`
+
+===
+CPU Performance Scaling
+===
+
+::
+
+ Copyright (c) 2017 Intel Corp., Rafael J. Wysocki 
+
+The Concept of CPU Performance Scaling
+==
+
+The majority of modern processors are capable of operating in a number of
+different clock frequency and voltage configurations, often referred to as
+Operating Performance Points or P-states (in ACPI terminology).  As a rule,
+the higher the clock frequency and the higher the voltage, the more 
instructions
+can be retired by the CPU over a unit of time, but also the higher the clock
+frequency and the higher the voltage, the more energy is consumed over a unit 
of
+time (or the more power is drawn) by the CPU in the given P-state.  Therefore
+there is a natural tradeoff between the CPU capacity (the number of 
instructions
+that can be executed over a unit of time) and the power drawn by the CPU.
+
+In some situations it is desirable or even necessary to run the program as fast
+as possible and then there is no reason to use any P-states different from the
+highest one (i.e. the highest-performance frequency/voltage configuration
+available).  In some other cases, however, it may not be necessary to execute
+instructions so quickly and maintaining the highest available CPU capacity for 
a
+relatively long time without utilizing it entirely may be regarded as wasteful.
+It also may not be physically possible to maintain maximum CPU capacity for too
+long for thermal or power supply capacity reasons or similar.  To cover those
+cases, there are hardware interfaces allowing CPUs to be switched between
+different frequency/voltage configurations or (in the ACPI terminology) to be
+put into different P-states.
+
+Typically, they are used along with algorithms to estimate the required CPU
+capacity, so as to decide which P-states to put the CPUs into.  Of course, 
since
+the utilization of the system generally changes over time, that has to be done
+repeatedly on a regular basis.  The activity by which this happens is referred
+to as CPU performance scaling or CPU frequency scaling (because it involves
+adjusting the CPU clock frequency).
+
+
+CPU Performance Scaling in Linux
+
+
+The Linux kernel supports CPU performance scaling by means of the ``CPUFreq``
+(CPU Frequency scaling) subsystem that consists of three layers of code: the
+core, scaling governors and scaling drivers.
+
+The ``CPUFreq`` core provides the common code infrastructure and user space
+interfaces for all platforms that support CPU performance scaling.  It defines
+the basic framework in which the other components operate.
+
+Scaling governors implement algorithms to estimate the required CPU capacity.
+As a rule, each governor implements one, possibly parametrized, scaling
+algorithm.
+
+Scaling drivers talk to the hardware.  They provide scaling governors with
+information on the available P-states (or P-state ranges in some cases) and
+access platform-specific hardware interfaces to change CPU P-states as 
requested
+by scaling governors.
+
+In principle, all available scaling governors can be used with every scaling
+driver.  That design is based on the observation that the information used by
+performance scaling algorithms for P-state selection can be represented in a
+platform-independent form in the majority of cases, so it should be 

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Adan Hawthorn]

Thanks, Joe.

Is this to say that scripts/checkpatch.pl should be updated to some
higher column limit?  I have made these cleanup changes before in a
like manner.

On Fri, Feb 17, 2017 at 8:17 PM, Joe Perches  wrote:
> On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
>> Fix checkpatch.pl warning of the form "WARNING: line over 80 characters."
> []
>> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
>> b/drivers/staging/bcm2835-audio/bcm2835.h
> []
>> @@ -163,8 +163,10 @@ int bcm2835_audio_write(struct bcm2835_alsa_stream 
>> *alsa_stream,
>>   unsigned int count,
>>   void *src);
>>  void bcm2835_playback_fifo(struct bcm2835_alsa_stream *alsa_stream);
>> -unsigned int bcm2835_audio_retrieve_buffers(struct bcm2835_alsa_stream 
>> *alsa_stream);
>> +unsigned int bcm2835_audio_retrieve_buffers(
>> + struct bcm2835_alsa_stream *alsa_stream);
>
> This is not a good change.
>
> This line exceeds 80 columns only because
> it uses very long identifiers (30+ chars).
>
> Anything that uses these very long names
> is going to be silly looking when forced
> to use 80 column line length maximums.
>
> Basically, it's OK as it is and if you
> really want to change it for any reason
> the other style to use is to have the
> return value on a separate line like:
>
> unsigned int
> bcm2836_audio_retrieve_buffers(struct bcm2835_also_stream *alsa_stream);
>
> Even so, that's not a good change either.

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Adan Hawthorn]

Thanks, Joe.

Is this to say that scripts/checkpatch.pl should be updated to some
higher column limit?  I have made these cleanup changes before in a
like manner.

On Fri, Feb 17, 2017 at 8:17 PM, Joe Perches  wrote:
> On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
>> Fix checkpatch.pl warning of the form "WARNING: line over 80 characters."
> []
>> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
>> b/drivers/staging/bcm2835-audio/bcm2835.h
> []
>> @@ -163,8 +163,10 @@ int bcm2835_audio_write(struct bcm2835_alsa_stream 
>> *alsa_stream,
>>   unsigned int count,
>>   void *src);
>>  void bcm2835_playback_fifo(struct bcm2835_alsa_stream *alsa_stream);
>> -unsigned int bcm2835_audio_retrieve_buffers(struct bcm2835_alsa_stream 
>> *alsa_stream);
>> +unsigned int bcm2835_audio_retrieve_buffers(
>> + struct bcm2835_alsa_stream *alsa_stream);
>
> This is not a good change.
>
> This line exceeds 80 columns only because
> it uses very long identifiers (30+ chars).
>
> Anything that uses these very long names
> is going to be silly looking when forced
> to use 80 column line length maximums.
>
> Basically, it's OK as it is and if you
> really want to change it for any reason
> the other style to use is to have the
> return value on a separate line like:
>
> unsigned int
> bcm2836_audio_retrieve_buffers(struct bcm2835_also_stream *alsa_stream);
>
> Even so, that's not a good change either.

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Joe Perches]

On Fri, 2017-02-17 at 20:32 -0500, Adan Hawthorn wrote:
> Thanks, Joe.
> 
> Is this to say that scripts/checkpatch.pl should be updated to some
> higher column limit?  I have made these cleanup changes before in a
> like manner.

Hard to say.

There could be some sensitivity to long identifier
name lengths added to checkpatch, but < 80 column
line length is still currently "strongly preferred".

I don't care much one way or another if it's 80
or 100 or something else as long as it's context
appropriate.

Awhile ago, Linus Torvalds wrote:

On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches  wrote:
> > > 
> > > In fact, I thought we already upped the check-patch limit to 100?
> > 
> > Nope, CodingStyle neither.
> > 
> > Last time I tried was awhile ago.
> 
> Ok, it must have been just talked about, and with the exceptions for
> strings etc I may not have seen as many of the really annoying line
> breaks lately.
> 
> I don't mind a 80-column "soft limit" per se: if some code
> consistently goes over 80 columns, there really is something seriously
> wrong there. So 80 columns may well be the right limit for that kind
> of check (or even less).
> 
> But if we have just a couple of lines that are longer (in a file that
> is 3k+ lines), I'd rather not break those.
> 
> I tend use "git grep" a lot, and it's much easier to see function
> argument use if it's all on one line.
> 
> Of course, some function calls really are *so* long that they have to
> be broken up, but that's where the "if it's a couple of lines that go
> a bit over the 80 column limit..." exception basically comes in.
> 
> Put another way: long lines definitely aren't good. But breaking long
> lines has some downsides too, so there should be a balance between the
> two, rather than some black-and-white limit.
> 
> In fact, we've seldom had cases where black-and-white limits work well.
> 

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Joe Perches]

On Fri, 2017-02-17 at 20:32 -0500, Adan Hawthorn wrote:
> Thanks, Joe.
> 
> Is this to say that scripts/checkpatch.pl should be updated to some
> higher column limit?  I have made these cleanup changes before in a
> like manner.

Hard to say.

There could be some sensitivity to long identifier
name lengths added to checkpatch, but < 80 column
line length is still currently "strongly preferred".

I don't care much one way or another if it's 80
or 100 or something else as long as it's context
appropriate.

Awhile ago, Linus Torvalds wrote:

On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches  wrote:
> > > 
> > > In fact, I thought we already upped the check-patch limit to 100?
> > 
> > Nope, CodingStyle neither.
> > 
> > Last time I tried was awhile ago.
> 
> Ok, it must have been just talked about, and with the exceptions for
> strings etc I may not have seen as many of the really annoying line
> breaks lately.
> 
> I don't mind a 80-column "soft limit" per se: if some code
> consistently goes over 80 columns, there really is something seriously
> wrong there. So 80 columns may well be the right limit for that kind
> of check (or even less).
> 
> But if we have just a couple of lines that are longer (in a file that
> is 3k+ lines), I'd rather not break those.
> 
> I tend use "git grep" a lot, and it's much easier to see function
> argument use if it's all on one line.
> 
> Of course, some function calls really are *so* long that they have to
> be broken up, but that's where the "if it's a couple of lines that go
> a bit over the 80 column limit..." exception basically comes in.
> 
> Put another way: long lines definitely aren't good. But breaking long
> lines has some downsides too, so there should be a balance between the
> two, rather than some black-and-white limit.
> 
> In fact, we've seldom had cases where black-and-white limits work well.
> 

Re: [PATCH] PM / QoS: Fix memory leak on resume_latency.notifiers

[Rafael J. Wysocki]

On Thursday, February 16, 2017 05:21:50 PM John Keeping wrote:
> Since commit 2d984ad132a8 ("PM / QoS: Introcuce latency tolerance device
> PM QoS type") we reassign "c" to point at qos->latency_tolerance before
> freeing c->notifiers, but the notifiers field of latency_tolerance is
> never used.
> 
> Restore the original behaviour of freeing the notifiers pointer on
> qos->resume_latency, which is used, and fix the following kmemleak
> warning.
> 
> unreferenced object 0xed9dba00 (size 64):
>   comm "kworker/0:1", pid 36, jiffies 4294670128 (age 15202.983s)
>   hex dump (first 32 bytes):
> 00 00 00 00 04 ba 9d ed 04 ba 9d ed 00 00 00 00  
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [] kmemleak_alloc+0x74/0xb8
> [] kmem_cache_alloc_trace+0x170/0x25c
> [] dev_pm_qos_constraints_allocate+0x3c/0xe4
> [] __dev_pm_qos_add_request+0x84/0x1a0
> [] dev_pm_qos_add_request+0x3c/0x54
> [] usb_hub_create_port_device+0x110/0x2b8
> [] hub_probe+0xadc/0xc80
> [] usb_probe_interface+0x1b4/0x260
> [] driver_probe_device+0x198/0x40c
> [] __device_attach_driver+0x8c/0x98
> [] bus_for_each_drv+0x8c/0x9c
> [] __device_attach+0x98/0x138
> [] device_initial_probe+0x14/0x18
> [] bus_probe_device+0x30/0x88
> [] device_add+0x430/0x554
> [] usb_set_configuration+0x660/0x6fc
> 
> Fixes: 2d984ad132a8 ("PM / QoS: Introcuce latency tolerance device PM QoS 
> type")
> Signed-off-by: John Keeping 

Applied.

Thanks,
Rafael

Re: [PATCH] MAINTAINERS: cpufreq: add bmips-cpufreq.c

[Florian Fainelli]

On 02/17/2017 05:20 PM, Rafael J. Wysocki wrote:
> On Friday, February 17, 2017 11:24:56 AM Florian Fainelli wrote:
>> On 02/17/2017 10:30 AM, Markus Mayer wrote:
>>> From: Markus Mayer 
>>>
>>> Add maintainer information for bmips-cpufreq.c.
>>>
>>> Signed-off-by: Markus Mayer 
>>
>> Looks great, thanks for adding this, one nit below:
>>
>>> ---
>>>
>>> This is based on PM's linux-next from today (February 17).
>>>
>>> This patch could be squashed into patch 3/4 of the original series if that
>>> is acceptable (see [1]) or it can remain separate.
>>>
>>> [1] https://lkml.org/lkml/2017/2/7/775
>>>
>>>  MAINTAINERS | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 107c10e..db251c0 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2692,6 +2692,12 @@ F:   drivers/irqchip/irq-brcmstb*
>>>  F: include/linux/bcm963xx_nvram.h
>>>  F: include/linux/bcm963xx_tag.h
>>>  
>>> +BROADCOM BMIPS CPUFREQ DRIVER
>>> +M: Markus Mayer 
>>> +L: linux...@vger.kernel.org
>>
>> Please also include bcm-kernel-feedback-l...@broadcom.com here
>>
>> With that:
>>
>> Acked-by: Florian Fainelli 
>>
> 
> Patch applied.

There was a v2 submitted shortly after.
-- 
Florian

Re: [PATCH] PM / QoS: Fix memory leak on resume_latency.notifiers

[Rafael J. Wysocki]

On Thursday, February 16, 2017 05:21:50 PM John Keeping wrote:
> Since commit 2d984ad132a8 ("PM / QoS: Introcuce latency tolerance device
> PM QoS type") we reassign "c" to point at qos->latency_tolerance before
> freeing c->notifiers, but the notifiers field of latency_tolerance is
> never used.
> 
> Restore the original behaviour of freeing the notifiers pointer on
> qos->resume_latency, which is used, and fix the following kmemleak
> warning.
> 
> unreferenced object 0xed9dba00 (size 64):
>   comm "kworker/0:1", pid 36, jiffies 4294670128 (age 15202.983s)
>   hex dump (first 32 bytes):
> 00 00 00 00 04 ba 9d ed 04 ba 9d ed 00 00 00 00  
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [] kmemleak_alloc+0x74/0xb8
> [] kmem_cache_alloc_trace+0x170/0x25c
> [] dev_pm_qos_constraints_allocate+0x3c/0xe4
> [] __dev_pm_qos_add_request+0x84/0x1a0
> [] dev_pm_qos_add_request+0x3c/0x54
> [] usb_hub_create_port_device+0x110/0x2b8
> [] hub_probe+0xadc/0xc80
> [] usb_probe_interface+0x1b4/0x260
> [] driver_probe_device+0x198/0x40c
> [] __device_attach_driver+0x8c/0x98
> [] bus_for_each_drv+0x8c/0x9c
> [] __device_attach+0x98/0x138
> [] device_initial_probe+0x14/0x18
> [] bus_probe_device+0x30/0x88
> [] device_add+0x430/0x554
> [] usb_set_configuration+0x660/0x6fc
> 
> Fixes: 2d984ad132a8 ("PM / QoS: Introcuce latency tolerance device PM QoS 
> type")
> Signed-off-by: John Keeping 

Applied.

Thanks,
Rafael

Re: [PATCH] MAINTAINERS: cpufreq: add bmips-cpufreq.c

[Florian Fainelli]

On 02/17/2017 05:20 PM, Rafael J. Wysocki wrote:
> On Friday, February 17, 2017 11:24:56 AM Florian Fainelli wrote:
>> On 02/17/2017 10:30 AM, Markus Mayer wrote:
>>> From: Markus Mayer 
>>>
>>> Add maintainer information for bmips-cpufreq.c.
>>>
>>> Signed-off-by: Markus Mayer 
>>
>> Looks great, thanks for adding this, one nit below:
>>
>>> ---
>>>
>>> This is based on PM's linux-next from today (February 17).
>>>
>>> This patch could be squashed into patch 3/4 of the original series if that
>>> is acceptable (see [1]) or it can remain separate.
>>>
>>> [1] https://lkml.org/lkml/2017/2/7/775
>>>
>>>  MAINTAINERS | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 107c10e..db251c0 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2692,6 +2692,12 @@ F:   drivers/irqchip/irq-brcmstb*
>>>  F: include/linux/bcm963xx_nvram.h
>>>  F: include/linux/bcm963xx_tag.h
>>>  
>>> +BROADCOM BMIPS CPUFREQ DRIVER
>>> +M: Markus Mayer 
>>> +L: linux...@vger.kernel.org
>>
>> Please also include bcm-kernel-feedback-l...@broadcom.com here
>>
>> With that:
>>
>> Acked-by: Florian Fainelli 
>>
> 
> Patch applied.

There was a v2 submitted shortly after.
-- 
Florian

Re: [PATCH] PM / sleep: Fix test_suspend after sleep state rework

[Rafael J. Wysocki]

On Friday, February 17, 2017 02:18:44 PM Geert Uytterhoeven wrote:
> When passing "test_suspend=mem" to the kernel:
> 
> PM: can't test 'mem' suspend state
> 
> and the suspend test is not run.
> 
> Commit 406e79385f3223d8 ("PM / sleep: System sleep state selection
> interface rework") changed pm_labels[] from a contiguous NULL-terminated
> array to a sparse array (with the first element unpopulated), breaking
> the assumptions of the iterator in setup_test_suspend().
> 
> Iterate from PM_SUSPEND_MIN to PM_SUSPEND_MAX - 1 to fix this.
> 
> Fixes: 406e79385f3223d8 ("PM / sleep: System sleep state selection interface 
> rework")
> Signed-off-by: Geert Uytterhoeven 

Applied.

Thanks,
Rafael

Re: [PATCH trivial 4/4] PM / Documentation: Spelling s/wrtie/write/

[Rafael J. Wysocki]

On Friday, February 17, 2017 04:36:39 PM Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> Cc: Rafael J. Wysocki 
> Cc: linux...@vger.kernel.org
> ---
>  Documentation/power/states.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt
> index 008ecb588317bc1d..bc4548245a243134 100644
> --- a/Documentation/power/states.txt
> +++ b/Documentation/power/states.txt
> @@ -25,7 +25,7 @@ to be used subsequently to change to the one represented by 
> that string.
>  Consequently, there are two ways to cause the system to go into the
>  Suspend-To-Idle sleep state.  The first one is to write "freeze" directly to
>  /sys/power/state.  The second one is to write "s2idle" to 
> /sys/power/mem_sleep
> -and then to wrtie "mem" to /sys/power/state.  Similarly, there are two ways
> +and then to write "mem" to /sys/power/state.  Similarly, there are two ways
>  to cause the system to go into the Power-On Suspend sleep state (the strings 
> to
>  write to the control files in that case are "standby" or "shallow" and "mem",
>  respectively) if that state is supported by the platform.  In turn, there is
> 

Applied.

Thanks,
Rafael

Re: [PATCH] MAINTAINERS: cpufreq: add bmips-cpufreq.c

[Rafael J. Wysocki]

On Friday, February 17, 2017 11:24:56 AM Florian Fainelli wrote:
> On 02/17/2017 10:30 AM, Markus Mayer wrote:
> > From: Markus Mayer 
> > 
> > Add maintainer information for bmips-cpufreq.c.
> > 
> > Signed-off-by: Markus Mayer 
> 
> Looks great, thanks for adding this, one nit below:
> 
> > ---
> > 
> > This is based on PM's linux-next from today (February 17).
> > 
> > This patch could be squashed into patch 3/4 of the original series if that
> > is acceptable (see [1]) or it can remain separate.
> > 
> > [1] https://lkml.org/lkml/2017/2/7/775
> > 
> >  MAINTAINERS | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 107c10e..db251c0 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2692,6 +2692,12 @@ F:   drivers/irqchip/irq-brcmstb*
> >  F: include/linux/bcm963xx_nvram.h
> >  F: include/linux/bcm963xx_tag.h
> >  
> > +BROADCOM BMIPS CPUFREQ DRIVER
> > +M: Markus Mayer 
> > +L: linux...@vger.kernel.org
> 
> Please also include bcm-kernel-feedback-l...@broadcom.com here
> 
> With that:
> 
> Acked-by: Florian Fainelli 
> 

Patch applied.

Thanks,
Rafael

Re: [PATCH] PM / sleep: Fix test_suspend after sleep state rework

[Rafael J. Wysocki]

On Friday, February 17, 2017 02:18:44 PM Geert Uytterhoeven wrote:
> When passing "test_suspend=mem" to the kernel:
> 
> PM: can't test 'mem' suspend state
> 
> and the suspend test is not run.
> 
> Commit 406e79385f3223d8 ("PM / sleep: System sleep state selection
> interface rework") changed pm_labels[] from a contiguous NULL-terminated
> array to a sparse array (with the first element unpopulated), breaking
> the assumptions of the iterator in setup_test_suspend().
> 
> Iterate from PM_SUSPEND_MIN to PM_SUSPEND_MAX - 1 to fix this.
> 
> Fixes: 406e79385f3223d8 ("PM / sleep: System sleep state selection interface 
> rework")
> Signed-off-by: Geert Uytterhoeven 

Applied.

Thanks,
Rafael

Re: [PATCH trivial 4/4] PM / Documentation: Spelling s/wrtie/write/

[Rafael J. Wysocki]

On Friday, February 17, 2017 04:36:39 PM Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> Cc: Rafael J. Wysocki 
> Cc: linux...@vger.kernel.org
> ---
>  Documentation/power/states.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt
> index 008ecb588317bc1d..bc4548245a243134 100644
> --- a/Documentation/power/states.txt
> +++ b/Documentation/power/states.txt
> @@ -25,7 +25,7 @@ to be used subsequently to change to the one represented by 
> that string.
>  Consequently, there are two ways to cause the system to go into the
>  Suspend-To-Idle sleep state.  The first one is to write "freeze" directly to
>  /sys/power/state.  The second one is to write "s2idle" to 
> /sys/power/mem_sleep
> -and then to wrtie "mem" to /sys/power/state.  Similarly, there are two ways
> +and then to write "mem" to /sys/power/state.  Similarly, there are two ways
>  to cause the system to go into the Power-On Suspend sleep state (the strings 
> to
>  write to the control files in that case are "standby" or "shallow" and "mem",
>  respectively) if that state is supported by the platform.  In turn, there is
> 

Applied.

Thanks,
Rafael

Re: [PATCH] MAINTAINERS: cpufreq: add bmips-cpufreq.c

[Rafael J. Wysocki]

On Friday, February 17, 2017 11:24:56 AM Florian Fainelli wrote:
> On 02/17/2017 10:30 AM, Markus Mayer wrote:
> > From: Markus Mayer 
> > 
> > Add maintainer information for bmips-cpufreq.c.
> > 
> > Signed-off-by: Markus Mayer 
> 
> Looks great, thanks for adding this, one nit below:
> 
> > ---
> > 
> > This is based on PM's linux-next from today (February 17).
> > 
> > This patch could be squashed into patch 3/4 of the original series if that
> > is acceptable (see [1]) or it can remain separate.
> > 
> > [1] https://lkml.org/lkml/2017/2/7/775
> > 
> >  MAINTAINERS | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 107c10e..db251c0 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2692,6 +2692,12 @@ F:   drivers/irqchip/irq-brcmstb*
> >  F: include/linux/bcm963xx_nvram.h
> >  F: include/linux/bcm963xx_tag.h
> >  
> > +BROADCOM BMIPS CPUFREQ DRIVER
> > +M: Markus Mayer 
> > +L: linux...@vger.kernel.org
> 
> Please also include bcm-kernel-feedback-l...@broadcom.com here
> 
> With that:
> 
> Acked-by: Florian Fainelli 
> 

Patch applied.

Thanks,
Rafael

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Joe Perches]

On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
> Fix checkpatch.pl warning of the form "WARNING: line over 80 characters."
[]
> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
> b/drivers/staging/bcm2835-audio/bcm2835.h
[]
> @@ -163,8 +163,10 @@ int bcm2835_audio_write(struct bcm2835_alsa_stream 
> *alsa_stream,
>   unsigned int count,
>   void *src);
>  void bcm2835_playback_fifo(struct bcm2835_alsa_stream *alsa_stream);
> -unsigned int bcm2835_audio_retrieve_buffers(struct bcm2835_alsa_stream 
> *alsa_stream);
> +unsigned int bcm2835_audio_retrieve_buffers(
> + struct bcm2835_alsa_stream *alsa_stream);

This is not a good change.

This line exceeds 80 columns only because
it uses very long identifiers (30+ chars).

Anything that uses these very long names
is going to be silly looking when forced
to use 80 column line length maximums.

Basically, it's OK as it is and if you
really want to change it for any reason
the other style to use is to have the
return value on a separate line like:

unsigned int
bcm2836_audio_retrieve_buffers(struct bcm2835_also_stream *alsa_stream);

Even so, that's not a good change either.

Re: [PATCH 5/5] staging: bcm2835-audio: bcm2835.h: fix line length coding style issue

[Joe Perches]

On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
> Fix checkpatch.pl warning of the form "WARNING: line over 80 characters."
[]
> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
> b/drivers/staging/bcm2835-audio/bcm2835.h
[]
> @@ -163,8 +163,10 @@ int bcm2835_audio_write(struct bcm2835_alsa_stream 
> *alsa_stream,
>   unsigned int count,
>   void *src);
>  void bcm2835_playback_fifo(struct bcm2835_alsa_stream *alsa_stream);
> -unsigned int bcm2835_audio_retrieve_buffers(struct bcm2835_alsa_stream 
> *alsa_stream);
> +unsigned int bcm2835_audio_retrieve_buffers(
> + struct bcm2835_alsa_stream *alsa_stream);

This is not a good change.

This line exceeds 80 columns only because
it uses very long identifiers (30+ chars).

Anything that uses these very long names
is going to be silly looking when forced
to use 80 column line length maximums.

Basically, it's OK as it is and if you
really want to change it for any reason
the other style to use is to have the
return value on a separate line like:

unsigned int
bcm2836_audio_retrieve_buffers(struct bcm2835_also_stream *alsa_stream);

Even so, that's not a good change either.

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/15/2017 06:19 PM, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.

Add support at MIPI CSI2 level for handling this part of the
negotiation.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 



Hi Russell,

I signed-off on this but after more review I'm not sure this is right.

The CSI-2 receiver really has no control over frame rate. It's output
frame rate is the same as the rate that is delivered to it.

So this subdev should either not implement these ops, or it should
refer them to the attached source subdev.

Steve


---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 23dca80..c62f14e 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -34,6 +34,7 @@ struct csi2_dev {
struct v4l2_subdev  sd;
struct media_pad   pad[CSI2_NUM_PADS];
struct v4l2_mbus_framefmt format_mbus;
+   struct v4l2_fract  frame_interval;
struct clk *dphy_clk;
struct clk *cfg_clk;
struct clk *pix_clk; /* what is this? */
@@ -397,6 +398,30 @@ static int csi2_set_fmt(struct v4l2_subdev *sd,
return 0;
 }

+static int csi2_g_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   fi->interval = csi2->frame_interval;
+
+   return 0;
+}
+
+static int csi2_s_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad != CSI2_SINK_PAD)
+   fi->interval = csi2->frame_interval;
+
+   csi2->frame_interval = fi->interval;
+
+   return 0;
+}
+
 /*
  * retrieve our pads parsed from the OF graph by the media device
  */
@@ -430,6 +455,8 @@ static struct v4l2_subdev_core_ops csi2_core_ops = {

 static struct v4l2_subdev_video_ops csi2_video_ops = {
.s_stream = csi2_s_stream,
+   .g_frame_interval = csi2_g_frame_interval,
+   .s_frame_interval = csi2_s_frame_interval,
 };

 static struct v4l2_subdev_pad_ops csi2_pad_ops = {



--
Steve Longerbeam | Senior Embedded Engineer, ESD Services
Mentor Embedded(tm) | 46871 Bayside Parkway, Fremont, CA 94538
P 510.354.5838 | M 408.410.2735

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/15/2017 06:19 PM, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.

Add support at MIPI CSI2 level for handling this part of the
negotiation.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 



Hi Russell,

I signed-off on this but after more review I'm not sure this is right.

The CSI-2 receiver really has no control over frame rate. It's output
frame rate is the same as the rate that is delivered to it.

So this subdev should either not implement these ops, or it should
refer them to the attached source subdev.

Steve


---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 23dca80..c62f14e 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -34,6 +34,7 @@ struct csi2_dev {
struct v4l2_subdev  sd;
struct media_pad   pad[CSI2_NUM_PADS];
struct v4l2_mbus_framefmt format_mbus;
+   struct v4l2_fract  frame_interval;
struct clk *dphy_clk;
struct clk *cfg_clk;
struct clk *pix_clk; /* what is this? */
@@ -397,6 +398,30 @@ static int csi2_set_fmt(struct v4l2_subdev *sd,
return 0;
 }

+static int csi2_g_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   fi->interval = csi2->frame_interval;
+
+   return 0;
+}
+
+static int csi2_s_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad != CSI2_SINK_PAD)
+   fi->interval = csi2->frame_interval;
+
+   csi2->frame_interval = fi->interval;
+
+   return 0;
+}
+
 /*
  * retrieve our pads parsed from the OF graph by the media device
  */
@@ -430,6 +455,8 @@ static struct v4l2_subdev_core_ops csi2_core_ops = {

 static struct v4l2_subdev_video_ops csi2_video_ops = {
.s_stream = csi2_s_stream,
+   .g_frame_interval = csi2_g_frame_interval,
+   .s_frame_interval = csi2_s_frame_interval,
 };

 static struct v4l2_subdev_pad_ops csi2_pad_ops = {



--
Steve Longerbeam | Senior Embedded Engineer, ESD Services
Mentor Embedded(tm) | 46871 Bayside Parkway, Fremont, CA 94538
P 510.354.5838 | M 408.410.2735

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/15/2017 06:19 PM, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.

Add support at MIPI CSI2 level for handling this part of the
negotiation.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 



Hi Russell,

I signed-off on this but after more review I'm not sure this is right.

The CSI-2 receiver really has no control over frame rate. It's output
frame rate is the same as the rate that is delivered to it.

So this subdev should either not implement these ops, or it should
refer them to the attached source subdev.

Steve


---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 23dca80..c62f14e 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -34,6 +34,7 @@ struct csi2_dev {
struct v4l2_subdev  sd;
struct media_pad   pad[CSI2_NUM_PADS];
struct v4l2_mbus_framefmt format_mbus;
+   struct v4l2_fract  frame_interval;
struct clk *dphy_clk;
struct clk *cfg_clk;
struct clk *pix_clk; /* what is this? */
@@ -397,6 +398,30 @@ static int csi2_set_fmt(struct v4l2_subdev *sd,
return 0;
 }

+static int csi2_g_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   fi->interval = csi2->frame_interval;
+
+   return 0;
+}
+
+static int csi2_s_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad != CSI2_SINK_PAD)
+   fi->interval = csi2->frame_interval;
+
+   csi2->frame_interval = fi->interval;
+
+   return 0;
+}
+
 /*
  * retrieve our pads parsed from the OF graph by the media device
  */
@@ -430,6 +455,8 @@ static struct v4l2_subdev_core_ops csi2_core_ops = {

 static struct v4l2_subdev_video_ops csi2_video_ops = {
.s_stream = csi2_s_stream,
+   .g_frame_interval = csi2_g_frame_interval,
+   .s_frame_interval = csi2_s_frame_interval,
 };

 static struct v4l2_subdev_pad_ops csi2_pad_ops = {



--
Steve Longerbeam | Senior Embedded Engineer, ESD Services
Mentor Embedded(tm) | 46871 Bayside Parkway, Fremont, CA 94538
P 510.354.5838 | M 408.410.2735

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/15/2017 06:19 PM, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.

Add support at MIPI CSI2 level for handling this part of the
negotiation.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 



Hi Russell,

I signed-off on this but after more review I'm not sure this is right.

The CSI-2 receiver really has no control over frame rate. It's output
frame rate is the same as the rate that is delivered to it.

So this subdev should either not implement these ops, or it should
refer them to the attached source subdev.

Steve


---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 23dca80..c62f14e 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -34,6 +34,7 @@ struct csi2_dev {
struct v4l2_subdev  sd;
struct media_pad   pad[CSI2_NUM_PADS];
struct v4l2_mbus_framefmt format_mbus;
+   struct v4l2_fract  frame_interval;
struct clk *dphy_clk;
struct clk *cfg_clk;
struct clk *pix_clk; /* what is this? */
@@ -397,6 +398,30 @@ static int csi2_set_fmt(struct v4l2_subdev *sd,
return 0;
 }

+static int csi2_g_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   fi->interval = csi2->frame_interval;
+
+   return 0;
+}
+
+static int csi2_s_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad != CSI2_SINK_PAD)
+   fi->interval = csi2->frame_interval;
+
+   csi2->frame_interval = fi->interval;
+
+   return 0;
+}
+
 /*
  * retrieve our pads parsed from the OF graph by the media device
  */
@@ -430,6 +455,8 @@ static struct v4l2_subdev_core_ops csi2_core_ops = {

 static struct v4l2_subdev_video_ops csi2_video_ops = {
.s_stream = csi2_s_stream,
+   .g_frame_interval = csi2_g_frame_interval,
+   .s_frame_interval = csi2_s_frame_interval,
 };

 static struct v4l2_subdev_pad_ops csi2_pad_ops = {



--
Steve Longerbeam | Senior Embedded Engineer, ESD Services
Mentor Embedded(tm) | 46871 Bayside Parkway, Fremont, CA 94538
P 510.354.5838 | M 408.410.2735

Re: [PATCH 4/5] staging: bcm2835-audio: bcm2835.h: fix volatile coding style issue

[Adan Hawthorn]

Thank you, Joe.

Please remove this patch at this time; it was sent in error.

On Fri, Feb 17, 2017 at 6:04 PM, Joe Perches  wrote:
> On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
>> Fix checkpatch.pl warning of the form "WARNING: Use of volatile is
>> usually wrong: see Documentation/process/volatile-considered-harmful.rst."
>
> Why are you sure the volatile use is not necessary?
>
>> Signed-off-by: Nathan Howard 
>> ---
>>  drivers/staging/bcm2835-audio/bcm2835.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
>> b/drivers/staging/bcm2835-audio/bcm2835.h
>> index 2f9d1c9..08f7ad6 100644
>> --- a/drivers/staging/bcm2835-audio/bcm2835.h
>> +++ b/drivers/staging/bcm2835-audio/bcm2835.h
>> @@ -125,8 +125,8 @@ struct bcm2835_alsa_stream {
>>   struct semaphore buffers_update_sem;
>>   struct semaphore control_sem;
>>   spinlock_t lock;
>> - volatile unsigned int control;
>> - volatile unsigned int status;
>> + unsigned int control;
>> + unsigned int status;
>>
>>   int open;
>>   int running;

Re: [PATCH 4/5] staging: bcm2835-audio: bcm2835.h: fix volatile coding style issue

[Adan Hawthorn]

Thank you, Joe.

Please remove this patch at this time; it was sent in error.

On Fri, Feb 17, 2017 at 6:04 PM, Joe Perches  wrote:
> On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
>> Fix checkpatch.pl warning of the form "WARNING: Use of volatile is
>> usually wrong: see Documentation/process/volatile-considered-harmful.rst."
>
> Why are you sure the volatile use is not necessary?
>
>> Signed-off-by: Nathan Howard 
>> ---
>>  drivers/staging/bcm2835-audio/bcm2835.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
>> b/drivers/staging/bcm2835-audio/bcm2835.h
>> index 2f9d1c9..08f7ad6 100644
>> --- a/drivers/staging/bcm2835-audio/bcm2835.h
>> +++ b/drivers/staging/bcm2835-audio/bcm2835.h
>> @@ -125,8 +125,8 @@ struct bcm2835_alsa_stream {
>>   struct semaphore buffers_update_sem;
>>   struct semaphore control_sem;
>>   spinlock_t lock;
>> - volatile unsigned int control;
>> - volatile unsigned int status;
>> + unsigned int control;
>> + unsigned int status;
>>
>>   int open;
>>   int running;

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Joe Perches]

On Fri, 2017-02-17 at 15:57 -0800, Nicolin Chen wrote:
> On Fri, Feb 17, 2017 at 11:48:54PM +, Mark Brown wrote:
> > On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> > > On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > > > To enable eventual removal of pr_warning
> > > > 
> > > > This makes pr_warn use consistent for sound/soc
> > > > 
> > > > Prior to this patch, there were 5 uses of pr_warning and
> > > > 10 uses of pr_warn in sound/soc
> > > > 
> > > > Signed-off-by: Joe Perches 
> > > 
> > > For imx-audmux.c,
> > 
> > I don't have this patch, perhaps it got caught in a spam filter or
> > perhaps it got deleted because as ever you're not using subject lines
> > reflecting the style for the subsystem.
> 
> My bad that I didn't pay attention to the subject.
> 
> Joe, please fix it in v2. Thanks.
> 
> ASoC: Convert remaining uses of pr_warning to pr_warn

This is a treewide scripted patch which is
basically just a sed.

If or when you apply it, you should
fix it up to suit.

$ git log -1000 --pretty=oneline --no-merges sound/soc | \
  cut -f2- -d" " | cut -f1 -d":" |sort | uniq
ALSA
AsoC
ASoc
ASoC
ASOC
ASoC fix up SND_SOC_WM8985 dependency
drm/i915/dp
kthread
lib/vsprintf.c
scripts/spelling.txt
sgtl5000
SoC
sound/soc
treewide

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Joe Perches]

On Fri, 2017-02-17 at 15:57 -0800, Nicolin Chen wrote:
> On Fri, Feb 17, 2017 at 11:48:54PM +, Mark Brown wrote:
> > On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> > > On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > > > To enable eventual removal of pr_warning
> > > > 
> > > > This makes pr_warn use consistent for sound/soc
> > > > 
> > > > Prior to this patch, there were 5 uses of pr_warning and
> > > > 10 uses of pr_warn in sound/soc
> > > > 
> > > > Signed-off-by: Joe Perches 
> > > 
> > > For imx-audmux.c,
> > 
> > I don't have this patch, perhaps it got caught in a spam filter or
> > perhaps it got deleted because as ever you're not using subject lines
> > reflecting the style for the subsystem.
> 
> My bad that I didn't pay attention to the subject.
> 
> Joe, please fix it in v2. Thanks.
> 
> ASoC: Convert remaining uses of pr_warning to pr_warn

This is a treewide scripted patch which is
basically just a sed.

If or when you apply it, you should
fix it up to suit.

$ git log -1000 --pretty=oneline --no-merges sound/soc | \
  cut -f2- -d" " | cut -f1 -d":" |sort | uniq
ALSA
AsoC
ASoc
ASoC
ASOC
ASoC fix up SND_SOC_WM8985 dependency
drm/i915/dp
kthread
lib/vsprintf.c
scripts/spelling.txt
sgtl5000
SoC
sound/soc
treewide

Re: [Suggestion/Problems] perf annoate: Some problems related to the source code view and Improvement of it with line numbers

[Taeung Song]

On 02/17/2017 10:29 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Feb 17, 2017 at 11:33:29AM +0900, Taeung Song escreveu:

Hi, Arnaldo :)

Regarding perf annotate:

1) Problem : wrong line numbers on perf-annotate (both stdio and TUI)
2) Problem : wrong sum of overhead(percent) matching source lines
3) Suggestion : new option showing only source code per function
with overhead info (to be more readable :) )

I'll send the patchset for them, maybe it'll a bit take time.
But I won't be long..


Concentrate on the first, send the patch, while waiting for review, work
on the second, and so on :-)

- Arnaldo



Understood!
I appreciate your concern :)

Thanks,
Taeung

Re: [Suggestion/Problems] perf annoate: Some problems related to the source code view and Improvement of it with line numbers

[Taeung Song]

On 02/17/2017 10:29 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Feb 17, 2017 at 11:33:29AM +0900, Taeung Song escreveu:

Hi, Arnaldo :)

Regarding perf annotate:

1) Problem : wrong line numbers on perf-annotate (both stdio and TUI)
2) Problem : wrong sum of overhead(percent) matching source lines
3) Suggestion : new option showing only source code per function
with overhead info (to be more readable :) )

I'll send the patchset for them, maybe it'll a bit take time.
But I won't be long..


Concentrate on the first, send the patch, while waiting for review, work
on the second, and so on :-)

- Arnaldo



Understood!
I appreciate your concern :)

Thanks,
Taeung

Re: [PATCH V2 4/6] PM / domain: Register for PM QOS performance notifier

[Kevin Hilman]

Viresh Kumar  writes:

> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> This patch registers the power domain framework for PM QOS performance
> notifier in order to manage performance state of power domains.

It seems to me it doesm't just register, but actually keeps track of the
performance_state by always tracking the max.

> This also allows the power domain drivers to implement a
> ->set_performance_state() callback, which will be called by the power
> domain core from the notifier routine.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/base/power/domain.c | 98 
> -
>  include/linux/pm_domain.h   |  5 +++
>  2 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index a73d79670a64..1158a07f92de 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -367,6 +367,88 @@ static int genpd_dev_pm_qos_notifier(struct 
> notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> +static void update_domain_performance_state(struct generic_pm_domain *genpd,
> + int depth)
> +{
> + struct generic_pm_domain_data *pd_data;
> + struct generic_pm_domain *subdomain;
> + struct pm_domain_data *pdd;
> + unsigned int state = 0;
> + struct gpd_link *link;
> +
> + /* Traverse all devices within the domain */
> + list_for_each_entry(pdd, >dev_list, list_node) {
> + pd_data = to_gpd_data(pdd);
> +
> + if (pd_data->performance_state > state)
> + state = pd_data->performance_state;
> + }

This seems to only update the state if it's bigger.  Maybe I'm missing
something here, but it seems like won't be able to lower the
performance_state after it's been raised?

> + /* Traverse all subdomains within the domain */
> + list_for_each_entry(link, >master_links, master_node) {
> + subdomain = link->slave;
> +
> + if (subdomain->performance_state > state)
> + state = subdomain->performance_state;
> + }

So subdomains are always assumed to influence the performance_state of
the parent domains?  Is that always the case?  I suspect this should be
probably be a reasonable default assumption, but maybe controlled with a
flag.

> + if (genpd->performance_state == state)
> + return;
> +
> + genpd->performance_state = state;
> +
> + if (genpd->set_performance_state) {
> + genpd->set_performance_state(genpd, state);
> + return;
> + }

So is zero not a valid performance_state?  That doesn't seem quite right
to me, but either way, it should be documented.

> + /* Propagate only if this domain has a single parent */

Why?  This limitation should be explained in the cover letter and
changelog.  I would also expect some sort of WARN here since this could
otherwise be a rather silent failures.

[...]

Kevin

Re: [PATCH V2 4/6] PM / domain: Register for PM QOS performance notifier

[Kevin Hilman]

Viresh Kumar  writes:

> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> This patch registers the power domain framework for PM QOS performance
> notifier in order to manage performance state of power domains.

It seems to me it doesm't just register, but actually keeps track of the
performance_state by always tracking the max.

> This also allows the power domain drivers to implement a
> ->set_performance_state() callback, which will be called by the power
> domain core from the notifier routine.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/base/power/domain.c | 98 
> -
>  include/linux/pm_domain.h   |  5 +++
>  2 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index a73d79670a64..1158a07f92de 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -367,6 +367,88 @@ static int genpd_dev_pm_qos_notifier(struct 
> notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> +static void update_domain_performance_state(struct generic_pm_domain *genpd,
> + int depth)
> +{
> + struct generic_pm_domain_data *pd_data;
> + struct generic_pm_domain *subdomain;
> + struct pm_domain_data *pdd;
> + unsigned int state = 0;
> + struct gpd_link *link;
> +
> + /* Traverse all devices within the domain */
> + list_for_each_entry(pdd, >dev_list, list_node) {
> + pd_data = to_gpd_data(pdd);
> +
> + if (pd_data->performance_state > state)
> + state = pd_data->performance_state;
> + }

This seems to only update the state if it's bigger.  Maybe I'm missing
something here, but it seems like won't be able to lower the
performance_state after it's been raised?

> + /* Traverse all subdomains within the domain */
> + list_for_each_entry(link, >master_links, master_node) {
> + subdomain = link->slave;
> +
> + if (subdomain->performance_state > state)
> + state = subdomain->performance_state;
> + }

So subdomains are always assumed to influence the performance_state of
the parent domains?  Is that always the case?  I suspect this should be
probably be a reasonable default assumption, but maybe controlled with a
flag.

> + if (genpd->performance_state == state)
> + return;
> +
> + genpd->performance_state = state;
> +
> + if (genpd->set_performance_state) {
> + genpd->set_performance_state(genpd, state);
> + return;
> + }

So is zero not a valid performance_state?  That doesn't seem quite right
to me, but either way, it should be documented.

> + /* Propagate only if this domain has a single parent */

Why?  This limitation should be explained in the cover letter and
changelog.  I would also expect some sort of WARN here since this could
otherwise be a rather silent failures.

[...]

Kevin

Re: [RFT 3/4] regulator: max14577: Remove support for platform data

[Mark Brown]

On Fri, Feb 17, 2017 at 10:01:59PM +0200, Krzysztof Kozlowski wrote:
> max14577 family of drivers are used only on Exynos-based ARMv7 boards
> which all were converted to DeviceTree long time ago.  Remove the
> support for platform data to simplify the driver.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

Re: [RFT 3/4] regulator: max14577: Remove support for platform data

[Mark Brown]

On Fri, Feb 17, 2017 at 10:01:59PM +0200, Krzysztof Kozlowski wrote:
> max14577 family of drivers are used only on Exynos-based ARMv7 boards
> which all were converted to DeviceTree long time ago.  Remove the
> support for platform data to simplify the driver.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

Re: [PATCH V2 5/6] PM / domain: Save/restore performance state at runtime suspend/resume

[Kevin Hilman]

Viresh Kumar  writes:

> With runtime PM, the devices get suspended while the system is up and
> running in order to save power. At such times, it is important to
> re-evaluate the required performance state of the domain, in order to
> choose a lower state if possible.
>
> This patch updates the genpd suspend/resume callbacks to do that.
>
> Signed-off-by: Viresh Kumar 

Doesn't this assume that a device in the domain would need to change
performance state while runtime suspended.  How would that happen?

Rather than adding this here, I would think that drivers would instead
remove any QoS requests before going into runtime suspend, which would
trigger an update before runtime suspending.

Kevin

Re: [PATCH V2 5/6] PM / domain: Save/restore performance state at runtime suspend/resume

[Kevin Hilman]

Viresh Kumar  writes:

> With runtime PM, the devices get suspended while the system is up and
> running in order to save power. At such times, it is important to
> re-evaluate the required performance state of the domain, in order to
> choose a lower state if possible.
>
> This patch updates the genpd suspend/resume callbacks to do that.
>
> Signed-off-by: Viresh Kumar 

Doesn't this assume that a device in the domain would need to change
performance state while runtime suspended.  How would that happen?

Rather than adding this here, I would think that drivers would instead
remove any QoS requests before going into runtime suspend, which would
trigger an update before runtime suspending.

Kevin

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Nicolin Chen]

On Fri, Feb 17, 2017 at 11:48:54PM +, Mark Brown wrote:
> On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> > On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > > To enable eventual removal of pr_warning
> > > 
> > > This makes pr_warn use consistent for sound/soc
> > > 
> > > Prior to this patch, there were 5 uses of pr_warning and
> > > 10 uses of pr_warn in sound/soc
> > > 
> > > Signed-off-by: Joe Perches 
> > 
> > For imx-audmux.c,
> 
> I don't have this patch, perhaps it got caught in a spam filter or
> perhaps it got deleted because as ever you're not using subject lines
> reflecting the style for the subsystem.

My bad that I didn't pay attention to the subject.

Joe, please fix it in v2. Thanks.

ASoC: Convert remaining uses of pr_warning to pr_warn

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Nicolin Chen]

On Fri, Feb 17, 2017 at 11:48:54PM +, Mark Brown wrote:
> On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> > On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > > To enable eventual removal of pr_warning
> > > 
> > > This makes pr_warn use consistent for sound/soc
> > > 
> > > Prior to this patch, there were 5 uses of pr_warning and
> > > 10 uses of pr_warn in sound/soc
> > > 
> > > Signed-off-by: Joe Perches 
> > 
> > For imx-audmux.c,
> 
> I don't have this patch, perhaps it got caught in a spam filter or
> perhaps it got deleted because as ever you're not using subject lines
> reflecting the style for the subsystem.

My bad that I didn't pay attention to the subject.

Joe, please fix it in v2. Thanks.

ASoC: Convert remaining uses of pr_warning to pr_warn

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 18.02.2017 00:44, Cong Wang wrote:

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C  wrote:


My card seems to use the e1000e driver which is buit-in..

Anyway here an objdump -x :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt



Found disable_hardirq() but not disable_irq().

Are you sure the kernel warning was emitted by this binary rather than
some old one?



Yes , I use an clean build , remove any other files in /boot && /lib/modules 
before installing the new build kernel.

I've asked Thomas before I send this to lkml and to you and he said :

..


It's a real issue. netconsole calls disable_irq() which might sleep from an
interrupt and preemption disabled context.

> [85362.132801]  __might_sleep+0x6b/0x80
> [85362.132803]  synchronize_irq+0x33/0x90
> [85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
> [85362.132807]  ? __disable_irq_nosync+0x4e/0x60
> [85362.132808]  disable_irq+0x17/0x20
> [85362.132810]  e1000_netpoll+0x3d/0x110

Though, what's weird is that the e1000_netpoll() does not longer call
disable_irq(). It calls disable_hardirq().

That got changed in commit 3111912971251 which got into Linus tree during
the 4.10 merge window. So it is in 4.10-rc8.

Confused.

...

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 18.02.2017 00:44, Cong Wang wrote:

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C  wrote:


My card seems to use the e1000e driver which is buit-in..

Anyway here an objdump -x :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt



Found disable_hardirq() but not disable_irq().

Are you sure the kernel warning was emitted by this binary rather than
some old one?



Yes , I use an clean build , remove any other files in /boot && /lib/modules 
before installing the new build kernel.

I've asked Thomas before I send this to lkml and to you and he said :

..


It's a real issue. netconsole calls disable_irq() which might sleep from an
interrupt and preemption disabled context.

> [85362.132801]  __might_sleep+0x6b/0x80
> [85362.132803]  synchronize_irq+0x33/0x90
> [85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
> [85362.132807]  ? __disable_irq_nosync+0x4e/0x60
> [85362.132808]  disable_irq+0x17/0x20
> [85362.132810]  e1000_netpoll+0x3d/0x110

Though, what's weird is that the e1000_netpoll() does not longer call
disable_irq(). It calls disable_hardirq().

That got changed in commit 3111912971251 which got into Linus tree during
the 4.10 merge window. So it is in 4.10-rc8.

Confused.

...

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Mark Brown]

On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > To enable eventual removal of pr_warning
> > 
> > This makes pr_warn use consistent for sound/soc
> > 
> > Prior to this patch, there were 5 uses of pr_warning and
> > 10 uses of pr_warn in sound/soc
> > 
> > Signed-off-by: Joe Perches 
> 
> For imx-audmux.c,

I don't have this patch, perhaps it got caught in a spam filter or
perhaps it got deleted because as ever you're not using subject lines
reflecting the style for the subsystem.


signature.asc
Description: PGP signature

Re: [PATCH 35/35] sound/soc: Convert remaining uses of pr_warning to pr_warn

[Mark Brown]

On Fri, Feb 17, 2017 at 12:28:44PM -0800, Nicolin Chen wrote:
> On Thu, Feb 16, 2017 at 11:11:48PM -0800, Joe Perches wrote:
> > To enable eventual removal of pr_warning
> > 
> > This makes pr_warn use consistent for sound/soc
> > 
> > Prior to this patch, there were 5 uses of pr_warning and
> > 10 uses of pr_warn in sound/soc
> > 
> > Signed-off-by: Joe Perches 
> 
> For imx-audmux.c,

I don't have this patch, perhaps it got caught in a spam filter or
perhaps it got deleted because as ever you're not using subject lines
reflecting the style for the subsystem.


signature.asc
Description: PGP signature