RE: [PATCH v3 0/7] Add RSS to DPAA 1.x Ethernet driver

[Madalin-cristian Bucur]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Subject: Re: [PATCH v3 0/7] Add RSS to DPAA 1.x Ethernet driver
> 
> From: David Miller 
> Date: Thu, 24 Aug 2017 09:42:20 -0700 (PDT)
> 
> > From: Madalin Bucur 
> > Date: Thu, 24 Aug 2017 10:28:21 +0300
> >
> >> This patch set introduces Receive Side Scaling for the DPAA Ethernet
> >> driver. Documentation is updated with details related to the new
> >> feature and limitations that apply.
> >> Added also a small fix.
> >>
> >> v2: removed a C++ style comment
> >> v3: move struct fman to header file to avoid exporting a function
> >
> > Series applied, thanks.
> 
> Actually I'm reverting, this doesn't even compile.

Hi,

Sorry for this blunder, I've only tested on PPC, where it works.
Will come back with a proper patch set.

Madalin

RE: [PATCH v3 0/7] Add RSS to DPAA 1.x Ethernet driver

[Madalin-cristian Bucur]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Subject: Re: [PATCH v3 0/7] Add RSS to DPAA 1.x Ethernet driver
> 
> From: David Miller 
> Date: Thu, 24 Aug 2017 09:42:20 -0700 (PDT)
> 
> > From: Madalin Bucur 
> > Date: Thu, 24 Aug 2017 10:28:21 +0300
> >
> >> This patch set introduces Receive Side Scaling for the DPAA Ethernet
> >> driver. Documentation is updated with details related to the new
> >> feature and limitations that apply.
> >> Added also a small fix.
> >>
> >> v2: removed a C++ style comment
> >> v3: move struct fman to header file to avoid exporting a function
> >
> > Series applied, thanks.
> 
> Actually I'm reverting, this doesn't even compile.

Hi,

Sorry for this blunder, I've only tested on PPC, where it works.
Will come back with a proper patch set.

Madalin

[PATCH] trace-cmd report: Fix hash.key in option -w

[Ziqian SUN (Zamir)]

From: "Ziqian SUN (Zamir)" 

In add_wakeup function the hash list is created with hash.key = value.
This makes add_sched function will never find a match with the key which
results in trace-cmd report will never show the average latency with the
following command:
trace-cmd report -w -F 'sched_switch,sched_wakeup'
With this patch, the command will show average latency as it used to be
in v2.4.2 like

Average wakeup latency: 28.460 usecs
Maximum Latency: 669.268 usecs at timestamp: 16337.629767
Minimum Latency: 2.153 usecs at timestamp: 16337.533735

RT task timings:

Average wakeup latency: 23.106 usecs
Maximum Latency: 57.482 usecs at timestamp: 16337.187531
Minimum Latency: 4.127 usecs at timestamp: 16336.945209

Reported-by: Joe Mario 
Signed-off-by: Ziqian SUN (Zamir) 
---
 trace-read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/trace-read.c b/trace-read.c
index ebb2368..350a843 100644
--- a/trace-read.c
+++ b/trace-read.c
@@ -610,7 +610,7 @@ static void add_wakeup(unsigned int val, unsigned long long 
start)
info = malloc(sizeof(*info));
if (!info)
die("Failed to allocate wakeup info");
-   info->hash.key = val;
+   info->hash.key = key;
info->start = start;
trace_hash_add(_hash, >hash);
 }
-- 
1.8.3.1

[PATCH] trace-cmd report: Fix hash.key in option -w

[Ziqian SUN (Zamir)]

From: "Ziqian SUN (Zamir)" 

In add_wakeup function the hash list is created with hash.key = value.
This makes add_sched function will never find a match with the key which
results in trace-cmd report will never show the average latency with the
following command:
trace-cmd report -w -F 'sched_switch,sched_wakeup'
With this patch, the command will show average latency as it used to be
in v2.4.2 like

Average wakeup latency: 28.460 usecs
Maximum Latency: 669.268 usecs at timestamp: 16337.629767
Minimum Latency: 2.153 usecs at timestamp: 16337.533735

RT task timings:

Average wakeup latency: 23.106 usecs
Maximum Latency: 57.482 usecs at timestamp: 16337.187531
Minimum Latency: 4.127 usecs at timestamp: 16336.945209

Reported-by: Joe Mario 
Signed-off-by: Ziqian SUN (Zamir) 
---
 trace-read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/trace-read.c b/trace-read.c
index ebb2368..350a843 100644
--- a/trace-read.c
+++ b/trace-read.c
@@ -610,7 +610,7 @@ static void add_wakeup(unsigned int val, unsigned long long 
start)
info = malloc(sizeof(*info));
if (!info)
die("Failed to allocate wakeup info");
-   info->hash.key = val;
+   info->hash.key = key;
info->start = start;
trace_hash_add(_hash, >hash);
 }
-- 
1.8.3.1

Re: [PATCH 05/14] kexec_file: factor out crashdump elf header function from x86

[Dave Young]

On 08/24/17 at 05:18pm, AKASHI Takahiro wrote:
> prepare_elf_headers() can also be useful for other architectures,
> including arm64. So let it factored out.
> 
> Signed-off-by: AKASHI Takahiro 
> Cc: Dave Young 
> Cc: Vivek Goyal 
> Cc: Baoquan He 
> ---
>  arch/x86/kernel/crash.c | 324 --
>  include/linux/kexec.h   |  19 +++
>  kernel/crash_core.c | 333 
> 

It looks better to add these to kexec_file.c instead.

Thanks
Dave

Re: [PATCH 05/14] kexec_file: factor out crashdump elf header function from x86

[Dave Young]

On 08/24/17 at 05:18pm, AKASHI Takahiro wrote:
> prepare_elf_headers() can also be useful for other architectures,
> including arm64. So let it factored out.
> 
> Signed-off-by: AKASHI Takahiro 
> Cc: Dave Young 
> Cc: Vivek Goyal 
> Cc: Baoquan He 
> ---
>  arch/x86/kernel/crash.c | 324 --
>  include/linux/kexec.h   |  19 +++
>  kernel/crash_core.c | 333 
> 

It looks better to add these to kexec_file.c instead.

Thanks
Dave

[PATCH] net: sxgbe: check memory allocation failure

[Christophe JAILLET]

Check memory allocation failure and return -ENOMEM in such a case, as
already done few lines below for another memory allocation.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
index 73427e29df2a..fbd00cb0cb7d 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
@@ -47,6 +47,8 @@ static int sxgbe_probe_config_dt(struct platform_device *pdev,
plat->mdio_bus_data = devm_kzalloc(>dev,
   sizeof(*plat->mdio_bus_data),
   GFP_KERNEL);
+   if (!plat->mdio_bus_data)
+   return -ENOMEM;
 
dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg), GFP_KERNEL);
if (!dma_cfg)
-- 
2.11.0

[PATCH] net: sxgbe: check memory allocation failure

[Christophe JAILLET]

Check memory allocation failure and return -ENOMEM in such a case, as
already done few lines below for another memory allocation.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
index 73427e29df2a..fbd00cb0cb7d 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c
@@ -47,6 +47,8 @@ static int sxgbe_probe_config_dt(struct platform_device *pdev,
plat->mdio_bus_data = devm_kzalloc(>dev,
   sizeof(*plat->mdio_bus_data),
   GFP_KERNEL);
+   if (!plat->mdio_bus_data)
+   return -ENOMEM;
 
dma_cfg = devm_kzalloc(>dev, sizeof(*dma_cfg), GFP_KERNEL);
if (!dma_cfg)
-- 
2.11.0

Re: [PATCH] zram: add zstd to the supported algorithms list

[Minchan Kim]

On Fri, Aug 25, 2017 at 02:06:44PM +0900, Sergey Senozhatsky wrote:

< snip >

> > Off-topic:
> > 
> > In all ways, zstd beats deflate. Nick, Right?
> > 
> > With zstd, I doubt we should show "deflate" to user. Many options just
> > make user confused.
> > The inflate have been there for representing high comp ratio but slower
> > speed. However, zstd is better unconditionally compared to deflate
> > so how about replacing deflate with zstd?
> > 
> > Sergey, what do you think about it?
> 
> hmmm... frankly, I don't think it would confuse anyone. the code is
> there - compiled - anyway, and the module is visible in /proc/crypto
> etc. if we will make it unavailable in zram then this can be confusing,
> probably... if anyone ever pays any attention at all. my guess is that
> people look what's in /sys/block/zram0/comp_algorithm just once, then
> they set up a create-zram script/systemd unit file/etc. and forget
> about it.

Although we don't show "deflate", zram still supports it so is it okay
for the user forgotten about it? and zram still doesn't show all of 
compression algorithm in system.

If I misunderstood your point, please, clarify.

Again, my point is that I want to show limited representative compression
(high speed/low comp, low speed/high comp, mid/mid) algorithm via
/sys/block/zram0/comp_algorithm rather than adding new entry whenever
new algorithm is added on. If others want something else algorithms
by some reason, he still can do it. We didn't prevent it.

Re: [PATCH] zram: add zstd to the supported algorithms list

[Minchan Kim]

On Fri, Aug 25, 2017 at 02:06:44PM +0900, Sergey Senozhatsky wrote:

< snip >

> > Off-topic:
> > 
> > In all ways, zstd beats deflate. Nick, Right?
> > 
> > With zstd, I doubt we should show "deflate" to user. Many options just
> > make user confused.
> > The inflate have been there for representing high comp ratio but slower
> > speed. However, zstd is better unconditionally compared to deflate
> > so how about replacing deflate with zstd?
> > 
> > Sergey, what do you think about it?
> 
> hmmm... frankly, I don't think it would confuse anyone. the code is
> there - compiled - anyway, and the module is visible in /proc/crypto
> etc. if we will make it unavailable in zram then this can be confusing,
> probably... if anyone ever pays any attention at all. my guess is that
> people look what's in /sys/block/zram0/comp_algorithm just once, then
> they set up a create-zram script/systemd unit file/etc. and forget
> about it.

Although we don't show "deflate", zram still supports it so is it okay
for the user forgotten about it? and zram still doesn't show all of 
compression algorithm in system.

If I misunderstood your point, please, clarify.

Again, my point is that I want to show limited representative compression
(high speed/low comp, low speed/high comp, mid/mid) algorithm via
/sys/block/zram0/comp_algorithm rather than adding new entry whenever
new algorithm is added on. If others want something else algorithms
by some reason, he still can do it. We didn't prevent it.

Re: [PATCH 1/2] xfs: cache dax_device lookup result

[Darrick J. Wong]

On Thu, Aug 24, 2017 at 05:35:48PM -0700, Dan Williams wrote:
> The ->iomap_begin() operation is a hot path, so cache the
> fs_dax_get_by_host() result to avoid the incurring the hash lookup
> overhead.

Just out of curiosity (and sorry if this has already been discussed to
death and I'm merely ignorant) but I was wondering why the daxdev isn't
simply attached to the block_device?  Is it not a 1:1 mapping?

--D

> 
> Cc: "Darrick J. Wong" 
> Reported-by: Christoph Hellwig 
> Signed-off-by: Dan Williams 
> ---
>  fs/xfs/xfs_aops.c  |   24 
>  fs/xfs/xfs_aops.h  |1 +
>  fs/xfs/xfs_buf.h   |1 +
>  fs/xfs/xfs_iomap.c |9 +
>  4 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 6bf120bb1a17..d16e013e1b8c 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -80,6 +80,30 @@ xfs_find_bdev_for_inode(
>   return mp->m_ddev_targp->bt_bdev;
>  }
>  
> +struct dax_device *
> +xfs_find_daxdev_for_inode(
> + struct inode*inode)
> +{
> + struct xfs_inode*ip = XFS_I(inode);
> + struct xfs_mount*mp = ip->i_mount;
> + struct block_device *bdev;
> + xfs_buftarg_t   *bt;
> +
> + if (XFS_IS_REALTIME_INODE(ip))
> + bt = mp->m_rtdev_targp;
> + else
> + bt = mp->m_ddev_targp;
> +
> + bdev = bt->bt_bdev;
> + if (!blk_queue_dax(bdev->bd_queue))
> + return NULL;
> +
> + if (!bt->bt_daxdev)
> + bt->bt_daxdev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
> +
> + return bt->bt_daxdev;
> +}
> +
>  /*
>   * We're now finished for good with this page.  Update the page state via the
>   * associated buffer_heads, paying attention to the start and end offsets 
> that
> diff --git a/fs/xfs/xfs_aops.h b/fs/xfs/xfs_aops.h
> index cc174ec6c2fd..88c85ea63da0 100644
> --- a/fs/xfs/xfs_aops.h
> +++ b/fs/xfs/xfs_aops.h
> @@ -59,5 +59,6 @@ int xfs_setfilesize(struct xfs_inode *ip, xfs_off_t offset, 
> size_t size);
>  
>  extern void xfs_count_page_state(struct page *, int *, int *);
>  extern struct block_device *xfs_find_bdev_for_inode(struct inode *);
> +extern struct dax_device *xfs_find_daxdev_for_inode(struct inode *);
>  
>  #endif /* __XFS_AOPS_H__ */
> diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
> index 20721261dae5..fc95a02f272a 100644
> --- a/fs/xfs/xfs_buf.h
> +++ b/fs/xfs/xfs_buf.h
> @@ -108,6 +108,7 @@ typedef unsigned int xfs_buf_flags_t;
>  typedef struct xfs_buftarg {
>   dev_t   bt_dev;
>   struct block_device *bt_bdev;
> + struct dax_device   *bt_daxdev;
>   struct xfs_mount*bt_mount;
>   unsigned intbt_meta_sectorsize;
>   size_t  bt_meta_sectormask;
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 813394c62849..3e8b9ec9e802 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -69,6 +69,7 @@ xfs_bmbt_to_iomap(
>   iomap->offset = XFS_FSB_TO_B(mp, imap->br_startoff);
>   iomap->length = XFS_FSB_TO_B(mp, imap->br_blockcount);
>   iomap->bdev = xfs_find_bdev_for_inode(VFS_I(ip));
> + iomap->dax_dev = xfs_find_daxdev_for_inode(VFS_I(ip));
>  }
>  
>  xfs_extlen_t
> @@ -976,7 +977,6 @@ xfs_file_iomap_begin(
>   int nimaps = 1, error = 0;
>   boolshared = false, trimmed = false;
>   unsignedlockmode;
> - struct block_device *bdev;
>  
>   if (XFS_FORCED_SHUTDOWN(mp))
>   return -EIO;
> @@ -1087,13 +1087,6 @@ xfs_file_iomap_begin(
>  
>   xfs_bmbt_to_iomap(ip, iomap, );
>  
> - /* optionally associate a dax device with the iomap bdev */
> - bdev = iomap->bdev;
> - if (blk_queue_dax(bdev->bd_queue))
> - iomap->dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
> - else
> - iomap->dax_dev = NULL;
> -
>   if (shared)
>   iomap->flags |= IOMAP_F_SHARED;
>   return 0;
> 

Re: [PATCH 1/2] xfs: cache dax_device lookup result

[Darrick J. Wong]

On Thu, Aug 24, 2017 at 05:35:48PM -0700, Dan Williams wrote:
> The ->iomap_begin() operation is a hot path, so cache the
> fs_dax_get_by_host() result to avoid the incurring the hash lookup
> overhead.

Just out of curiosity (and sorry if this has already been discussed to
death and I'm merely ignorant) but I was wondering why the daxdev isn't
simply attached to the block_device?  Is it not a 1:1 mapping?

--D

> 
> Cc: "Darrick J. Wong" 
> Reported-by: Christoph Hellwig 
> Signed-off-by: Dan Williams 
> ---
>  fs/xfs/xfs_aops.c  |   24 
>  fs/xfs/xfs_aops.h  |1 +
>  fs/xfs/xfs_buf.h   |1 +
>  fs/xfs/xfs_iomap.c |9 +
>  4 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 6bf120bb1a17..d16e013e1b8c 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -80,6 +80,30 @@ xfs_find_bdev_for_inode(
>   return mp->m_ddev_targp->bt_bdev;
>  }
>  
> +struct dax_device *
> +xfs_find_daxdev_for_inode(
> + struct inode*inode)
> +{
> + struct xfs_inode*ip = XFS_I(inode);
> + struct xfs_mount*mp = ip->i_mount;
> + struct block_device *bdev;
> + xfs_buftarg_t   *bt;
> +
> + if (XFS_IS_REALTIME_INODE(ip))
> + bt = mp->m_rtdev_targp;
> + else
> + bt = mp->m_ddev_targp;
> +
> + bdev = bt->bt_bdev;
> + if (!blk_queue_dax(bdev->bd_queue))
> + return NULL;
> +
> + if (!bt->bt_daxdev)
> + bt->bt_daxdev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
> +
> + return bt->bt_daxdev;
> +}
> +
>  /*
>   * We're now finished for good with this page.  Update the page state via the
>   * associated buffer_heads, paying attention to the start and end offsets 
> that
> diff --git a/fs/xfs/xfs_aops.h b/fs/xfs/xfs_aops.h
> index cc174ec6c2fd..88c85ea63da0 100644
> --- a/fs/xfs/xfs_aops.h
> +++ b/fs/xfs/xfs_aops.h
> @@ -59,5 +59,6 @@ int xfs_setfilesize(struct xfs_inode *ip, xfs_off_t offset, 
> size_t size);
>  
>  extern void xfs_count_page_state(struct page *, int *, int *);
>  extern struct block_device *xfs_find_bdev_for_inode(struct inode *);
> +extern struct dax_device *xfs_find_daxdev_for_inode(struct inode *);
>  
>  #endif /* __XFS_AOPS_H__ */
> diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
> index 20721261dae5..fc95a02f272a 100644
> --- a/fs/xfs/xfs_buf.h
> +++ b/fs/xfs/xfs_buf.h
> @@ -108,6 +108,7 @@ typedef unsigned int xfs_buf_flags_t;
>  typedef struct xfs_buftarg {
>   dev_t   bt_dev;
>   struct block_device *bt_bdev;
> + struct dax_device   *bt_daxdev;
>   struct xfs_mount*bt_mount;
>   unsigned intbt_meta_sectorsize;
>   size_t  bt_meta_sectormask;
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 813394c62849..3e8b9ec9e802 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -69,6 +69,7 @@ xfs_bmbt_to_iomap(
>   iomap->offset = XFS_FSB_TO_B(mp, imap->br_startoff);
>   iomap->length = XFS_FSB_TO_B(mp, imap->br_blockcount);
>   iomap->bdev = xfs_find_bdev_for_inode(VFS_I(ip));
> + iomap->dax_dev = xfs_find_daxdev_for_inode(VFS_I(ip));
>  }
>  
>  xfs_extlen_t
> @@ -976,7 +977,6 @@ xfs_file_iomap_begin(
>   int nimaps = 1, error = 0;
>   boolshared = false, trimmed = false;
>   unsignedlockmode;
> - struct block_device *bdev;
>  
>   if (XFS_FORCED_SHUTDOWN(mp))
>   return -EIO;
> @@ -1087,13 +1087,6 @@ xfs_file_iomap_begin(
>  
>   xfs_bmbt_to_iomap(ip, iomap, );
>  
> - /* optionally associate a dax device with the iomap bdev */
> - bdev = iomap->bdev;
> - if (blk_queue_dax(bdev->bd_queue))
> - iomap->dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
> - else
> - iomap->dax_dev = NULL;
> -
>   if (shared)
>   iomap->flags |= IOMAP_F_SHARED;
>   return 0;
> 

[PATCH manpages] stat.2: correct AT_NO_AUTOMOUNT text and general revisions.

[NeilBrown]

Expand on the relationship between fstatat() and the other
three functions, and improve the description of AT_NO_AUTOMOUNT.
Specifically, both  stat() and lstat() act the same way
with respect to automounts, and that behavior matches
fstatat with the AT_NO_AUTOMOUNT flag.

The text in the NOTES is removed and places with the text for
AT_NO_AUTOMOUNT to improve cohesion.

New text for a difference to be introduced in 4.14.

Cc: Ian Kent 
Signed-off-by: NeilBrown 
---

Thanks Ian and Michael.  I considered your input and read
through the whole again, and came up with this which is
quite different to what I suggested before.

If this patch is applied, the result probably shouldn't be released
until the relevant patch actually lands in Linus's tree.

NeilBrown


 man2/stat.2 | 37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/man2/stat.2 b/man2/stat.2
index d8a9e76b3d9f..c6dddfe0d3a7 100644
--- a/man2/stat.2
+++ b/man2/stat.2
@@ -260,9 +260,12 @@ For further information on the above fields, see
 .SS fstatat()
 The
 .BR fstatat ()
-system call operates in exactly the same way as
+system call is a more general interface for accessing file information
+which can still provide exactly the behavior of each of
 .BR stat (),
-except for the differences described here.
+.BR lstat (),
+and
+.BR fstat ().
 .PP
 If the pathname given in
 .I pathname
@@ -272,6 +275,8 @@ referred to by the file descriptor
 (rather than relative to the current working directory of
 the calling process, as is done by
 .BR stat ()
+and
+.BR lstat ()
 for a relative pathname).
 .PP
 If
@@ -284,7 +289,9 @@ then
 .I pathname
 is interpreted relative to the current working
 directory of the calling process (like
-.BR stat ()).
+.BR stat ()
+and
+.BR lstat ()).
 .PP
 If
 .I pathname
@@ -307,7 +314,11 @@ is an empty string, operate on the file referred to by
 flag).
 In this case,
 .I dirfd
-can refer to any type of file, not just a directory.
+can refer to any type of file, not just a directory, and
+the behavior of
+.BR fstatat ()
+is similar to that of
+.BR fstat ().
 If
 .I dirfd
 is
@@ -324,6 +335,8 @@ Don't automount the terminal ("basename") component of
 if it is a directory that is an automount point.
 This allows the caller to gather attributes of an automount point
 (rather than the location it would mount).
+Since Linux 4.14, also don't instantiate a non-existent name in an
+on-demand directory such as used for automounter indirect maps.
 This flag can be used in tools that scan directories
 to prevent mass-automounting of a directory of automount points.
 The
@@ -333,6 +346,13 @@ This flag is Linux-specific; define
 .B _GNU_SOURCE
 .\" Before glibc 2.16, defining _ATFILE_SOURCE sufficed
 to obtain its definition.
+Both
+.BR stat ()
+and
+.BR lstat ()
+act as though
+.B AT_NO_AUTOMOUNT
+was set.
 .TP
 .B AT_SYMLINK_NOFOLLOW
 If
@@ -474,15 +494,6 @@ fields may be less portable.
 The interpretation differs between systems,
 and possibly on a single system when NFS mounts are involved.)
 .SH NOTES
-On Linux,
-.BR lstat ()
-will generally not trigger automounter action, whereas
-.BR stat ()
-will (but see the description of the
-.BR fstatat ()
-.B AT_NO_AUTOMOUNT
-fag, above).
-.\"
 .SS Timestamp fields
 Older kernels and older standards did not support nanosecond timestamp
 fields.
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

[PATCH manpages] stat.2: correct AT_NO_AUTOMOUNT text and general revisions.

[NeilBrown]

Expand on the relationship between fstatat() and the other
three functions, and improve the description of AT_NO_AUTOMOUNT.
Specifically, both  stat() and lstat() act the same way
with respect to automounts, and that behavior matches
fstatat with the AT_NO_AUTOMOUNT flag.

The text in the NOTES is removed and places with the text for
AT_NO_AUTOMOUNT to improve cohesion.

New text for a difference to be introduced in 4.14.

Cc: Ian Kent 
Signed-off-by: NeilBrown 
---

Thanks Ian and Michael.  I considered your input and read
through the whole again, and came up with this which is
quite different to what I suggested before.

If this patch is applied, the result probably shouldn't be released
until the relevant patch actually lands in Linus's tree.

NeilBrown


 man2/stat.2 | 37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/man2/stat.2 b/man2/stat.2
index d8a9e76b3d9f..c6dddfe0d3a7 100644
--- a/man2/stat.2
+++ b/man2/stat.2
@@ -260,9 +260,12 @@ For further information on the above fields, see
 .SS fstatat()
 The
 .BR fstatat ()
-system call operates in exactly the same way as
+system call is a more general interface for accessing file information
+which can still provide exactly the behavior of each of
 .BR stat (),
-except for the differences described here.
+.BR lstat (),
+and
+.BR fstat ().
 .PP
 If the pathname given in
 .I pathname
@@ -272,6 +275,8 @@ referred to by the file descriptor
 (rather than relative to the current working directory of
 the calling process, as is done by
 .BR stat ()
+and
+.BR lstat ()
 for a relative pathname).
 .PP
 If
@@ -284,7 +289,9 @@ then
 .I pathname
 is interpreted relative to the current working
 directory of the calling process (like
-.BR stat ()).
+.BR stat ()
+and
+.BR lstat ()).
 .PP
 If
 .I pathname
@@ -307,7 +314,11 @@ is an empty string, operate on the file referred to by
 flag).
 In this case,
 .I dirfd
-can refer to any type of file, not just a directory.
+can refer to any type of file, not just a directory, and
+the behavior of
+.BR fstatat ()
+is similar to that of
+.BR fstat ().
 If
 .I dirfd
 is
@@ -324,6 +335,8 @@ Don't automount the terminal ("basename") component of
 if it is a directory that is an automount point.
 This allows the caller to gather attributes of an automount point
 (rather than the location it would mount).
+Since Linux 4.14, also don't instantiate a non-existent name in an
+on-demand directory such as used for automounter indirect maps.
 This flag can be used in tools that scan directories
 to prevent mass-automounting of a directory of automount points.
 The
@@ -333,6 +346,13 @@ This flag is Linux-specific; define
 .B _GNU_SOURCE
 .\" Before glibc 2.16, defining _ATFILE_SOURCE sufficed
 to obtain its definition.
+Both
+.BR stat ()
+and
+.BR lstat ()
+act as though
+.B AT_NO_AUTOMOUNT
+was set.
 .TP
 .B AT_SYMLINK_NOFOLLOW
 If
@@ -474,15 +494,6 @@ fields may be less portable.
 The interpretation differs between systems,
 and possibly on a single system when NFS mounts are involved.)
 .SH NOTES
-On Linux,
-.BR lstat ()
-will generally not trigger automounter action, whereas
-.BR stat ()
-will (but see the description of the
-.BR fstatat ()
-.B AT_NO_AUTOMOUNT
-fag, above).
-.\"
 .SS Timestamp fields
 Older kernels and older standards did not support nanosecond timestamp
 fields.
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 14:06), Sergey Senozhatsky wrote:
> > Off-topic:
> > 
> > In all ways, zstd beats deflate. Nick, Right?
> > 
> > With zstd, I doubt we should show "deflate" to user. Many options just
> > make user confused.
> > The inflate have been there for representing high comp ratio but slower
> > speed. However, zstd is better unconditionally compared to deflate
> > so how about replacing deflate with zstd?
> > 
> > Sergey, what do you think about it?
> 
> hmmm... frankly, I don't think it would confuse anyone. the code is
> there - compiled - anyway, and the module is visible in /proc/crypto
> etc. if we will make it unavailable in zram then this can be confusing,
> probably... if anyone ever pays any attention at all. my guess is that
> people look what's in /sys/block/zram0/comp_algorithm just once, then
> they set up a create-zram script/systemd unit file/etc. and forget
> about it.
> 
> cryto API is just a wrapper and it calls lib/comp_foo to do the actual
> work, and that lib/comp_foo *may be* can be implemented as a H/W (not
> S/W) compressing backend. well, who knows.

but I can remove deflate, if you insist. sure.

-ss

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 14:06), Sergey Senozhatsky wrote:
> > Off-topic:
> > 
> > In all ways, zstd beats deflate. Nick, Right?
> > 
> > With zstd, I doubt we should show "deflate" to user. Many options just
> > make user confused.
> > The inflate have been there for representing high comp ratio but slower
> > speed. However, zstd is better unconditionally compared to deflate
> > so how about replacing deflate with zstd?
> > 
> > Sergey, what do you think about it?
> 
> hmmm... frankly, I don't think it would confuse anyone. the code is
> there - compiled - anyway, and the module is visible in /proc/crypto
> etc. if we will make it unavailable in zram then this can be confusing,
> probably... if anyone ever pays any attention at all. my guess is that
> people look what's in /sys/block/zram0/comp_algorithm just once, then
> they set up a create-zram script/systemd unit file/etc. and forget
> about it.
> 
> cryto API is just a wrapper and it calls lib/comp_foo to do the actual
> work, and that lib/comp_foo *may be* can be implemented as a H/W (not
> S/W) compressing backend. well, who knows.

but I can remove deflate, if you insist. sure.

-ss

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 02:46), Nick Terrell wrote:
> On 8/24/17, 7:21 PM, "Sergey Senozhatsky"  
> wrote:
> > not really familiar either... I was thinking about having "zstd" and
> > "zstd_dict" crypto_alg structs - one would be !dict, the other one would
> > allocate dict and pass it to compress/decompress zstd callbacks. "zstd"
> > vecrsion would invoke zstd_params() passing zeros as compress and dict
> > sizes to ZSTD_getParams(), while "zstd_dict" would invoke, lets say,
> > zstd_params_dict() passing PAGE_SIZE-s. hm... (0, PAGE_SIZE)?  to
> > ZSTD_getParams(). just a rough idea...
> 
> The way zstd dictionaries work is the user provides some data which gets
> "prepended" to the data that is about to be compressed, without actually
> writing it to output. That way zstd can find matches in the dictionary and
> represent them for "free". That means the user has to pass the same data to
> both the compressor and decompressor.

ah... I thought zstd would construct the dictionary for us based on the
data it compresses; and we just need to provide the buffer.

> We could build a dictionary, say every 20 minutes, by sampling 512 B chunks
> of the RAM and constructing a 16 KB dictionary. Then recompress all the
> compressed RAM with the new dictionary. This is just a simple example of a
> dictionary construction algorithm. You could imagine grouping pages by
> application, and building a dictionary per application, since those pages
> would likely be more similar.
> 
> Regarding the crypto API, I think it would be possible to experiment by
> creating functions like
> `zstd_comp_add_dictionary(void *ctx, void *data, size_t size)'
> and `zstd_decomp_add_dictionary(void *ctx, void *data, size_t size)'
> in the crypto zstd implementation and declare them in `zcomp.c'. If the
> experiments prove that using zstd dictionaries (or LZ4 dictionaries) is
> worthwhile, then we can figure out how we can make it work for real.

-ss

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 02:46), Nick Terrell wrote:
> On 8/24/17, 7:21 PM, "Sergey Senozhatsky"  
> wrote:
> > not really familiar either... I was thinking about having "zstd" and
> > "zstd_dict" crypto_alg structs - one would be !dict, the other one would
> > allocate dict and pass it to compress/decompress zstd callbacks. "zstd"
> > vecrsion would invoke zstd_params() passing zeros as compress and dict
> > sizes to ZSTD_getParams(), while "zstd_dict" would invoke, lets say,
> > zstd_params_dict() passing PAGE_SIZE-s. hm... (0, PAGE_SIZE)?  to
> > ZSTD_getParams(). just a rough idea...
> 
> The way zstd dictionaries work is the user provides some data which gets
> "prepended" to the data that is about to be compressed, without actually
> writing it to output. That way zstd can find matches in the dictionary and
> represent them for "free". That means the user has to pass the same data to
> both the compressor and decompressor.

ah... I thought zstd would construct the dictionary for us based on the
data it compresses; and we just need to provide the buffer.

> We could build a dictionary, say every 20 minutes, by sampling 512 B chunks
> of the RAM and constructing a 16 KB dictionary. Then recompress all the
> compressed RAM with the new dictionary. This is just a simple example of a
> dictionary construction algorithm. You could imagine grouping pages by
> application, and building a dictionary per application, since those pages
> would likely be more similar.
> 
> Regarding the crypto API, I think it would be possible to experiment by
> creating functions like
> `zstd_comp_add_dictionary(void *ctx, void *data, size_t size)'
> and `zstd_decomp_add_dictionary(void *ctx, void *data, size_t size)'
> in the crypto zstd implementation and declare them in `zcomp.c'. If the
> experiments prove that using zstd dictionaries (or LZ4 dictionaries) is
> worthwhile, then we can figure out how we can make it work for real.

-ss

[PATCH] usb: chipidea: usb2: check memory allocation failure

[Christophe JAILLET]

Check memory allocation failure and return -ENOMEM in such a case, as
already done few lines below for another memory allocation.

Signed-off-by: Christophe JAILLET 
---
 drivers/usb/chipidea/ci_hdrc_usb2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
b/drivers/usb/chipidea/ci_hdrc_usb2.c
index d162cc0bb8ce..99425db9ba62 100644
--- a/drivers/usb/chipidea/ci_hdrc_usb2.c
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -52,6 +52,8 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev)
 
if (!ci_pdata) {
ci_pdata = devm_kmalloc(dev, sizeof(*ci_pdata), GFP_KERNEL);
+   if (!ci_pdata)
+   return -ENOMEM;
*ci_pdata = ci_default_pdata;   /* struct copy */
}
 
-- 
2.11.0

[PATCH] usb: chipidea: usb2: check memory allocation failure

[Christophe JAILLET]

Check memory allocation failure and return -ENOMEM in such a case, as
already done few lines below for another memory allocation.

Signed-off-by: Christophe JAILLET 
---
 drivers/usb/chipidea/ci_hdrc_usb2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
b/drivers/usb/chipidea/ci_hdrc_usb2.c
index d162cc0bb8ce..99425db9ba62 100644
--- a/drivers/usb/chipidea/ci_hdrc_usb2.c
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -52,6 +52,8 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev)
 
if (!ci_pdata) {
ci_pdata = devm_kmalloc(dev, sizeof(*ci_pdata), GFP_KERNEL);
+   if (!ci_pdata)
+   return -ENOMEM;
*ci_pdata = ci_default_pdata;   /* struct copy */
}
 
-- 
2.11.0

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

[zhong jiang]

On 2017/6/29 6:13, Thomas Gleixner wrote:
> On Wed, 28 Jun 2017, zhong jiang wrote:
>> On 2017/6/22 0:40, Ingo Molnar wrote:
>>> * zhong jiang  wrote:
>>>
 when shift expoment is negative, left shift alway zero. therefore, we
 modify the logic to avoid the warining.

 Signed-off-by: zhong jiang 
 ---
  arch/x86/include/asm/futex.h | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
 index b4c1f54..2425fca 100644
 --- a/arch/x86/include/asm/futex.h
 +++ b/arch/x86/include/asm/futex.h
 @@ -49,8 +49,12 @@ static inline int futex_atomic_op_inuser(int 
 encoded_op, u32 __user *uaddr)
int cmparg = (encoded_op << 20) >> 20;
int oldval = 0, ret, tem;
  
 -  if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
 -  oparg = 1 << oparg;
 +  if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
 +  if (oparg >= 0)
 +  oparg = 1 << oparg;
 +  else
 +  oparg = 0;
 +  }
>>> Could we avoid all these complications by using an unsigned type?
>>   I think it is not feasible.  a negative shift exponent is likely
>>   existence and reasonable.
> What is reasonable about a negative shift value?
>
>> as the above case, oparg is a negative is common.
> That's simply wrong. If oparg is negative and the SHIFT bit is set then the
> result is undefined today and there is no way that this can be used at
> all.
>
> On x86:
>
>1 << -1= 0x8000
>1 << -2048 = 0x0001
>1 << -2047 = 0x0002
>
> Anything using a shift value < 0 or > 31 will get crap as a
> result. Rightfully so because it's just undefined.
>
> Yes I know that the insanity of user space is unlimited, but anything
> attempting this is so broken that we cannot break it further by making that
> shift arg unsigned and actually limit it to 0-31
>
> Thanks,
>
>   tglx
>
>
>
> .
>
 >From df9e2a5a3f1f401943aeb2718d5876b854dea3a3 Mon Sep 17 00:00:00 2001
From: zhong jiang 
Date: Fri, 25 Aug 2017 12:05:56 +0800
Subject: [PATCH v2] futex: avoid undefined behaviour when shift exponent is
 negative

when futex syscall is called from userspace, we find the following
warning by ubsan detection.

[   63.237803] UBSAN: Undefined behaviour in 
/root/rpmbuild/BUILDROOT/kernel-3.10.0-327.49.58.52.x86_64/usr/src/linux-3.10.0-327.49.58.52.x86_64/arch/x86/include/asm/futex.h:53:13
[   63.237803] shift exponent -16 is negative
[   63.237803] CPU: 0 PID: 67 Comm: driver Not tainted 3.10.0 #1
[   63.237803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
[   63.237803]  fff0 9ad70fde 8802fa08 
81ef0d6f
[   63.237803]  8802fa20 81ef0e2c 828f2540 
8802fb90
[   63.237803]  81ef1ad0 8141cc88 11005f48 
41b58ab3
[   63.237803] Call Trace:
[   63.237803]  [] dump_stack+0x1e/0x20
[   63.237803]  [] ubsan_epilogue+0x12/0x55
[   63.237803]  [] 
__ubsan_handle_shift_out_of_bounds+0x237/0x29c
[   63.237803]  [] ? kasan_alloc_pages+0x38/0x40
[   63.237803]  [] ? 
__ubsan_handle_load_invalid_value+0x162/0x162
[   63.237803]  [] ? get_futex_key+0x361/0x6c0
[   63.237803]  [] ? get_futex_key_refs+0xb0/0xb0
[   63.237803]  [] futex_wake_op+0xb48/0xc70
[   63.237803]  [] ? futex_wake_op+0xb48/0xc70
[   63.237803]  [] ? futex_wake+0x380/0x380
[   63.237803]  [] do_futex+0x2cc/0xb60
[   63.237803]  [] ? exit_robust_list+0x350/0x350
[   63.237803]  [] ? __fsnotify_inode_delete+0x20/0x20
[   63.237803]  [] ? n_tty_flush_buffer+0x80/0x80
[   63.237803]  [] ? __fsnotify_parent+0x53/0x210
[   63.237803]  [] SyS_futex+0x147/0x300
[   63.237803]  [] ? do_futex+0xb60/0xb60
[   63.237803]  [] ? do_page_fault+0x44/0xa0
[   63.237803]  [] system_call_fastpath+0x16/0x1b

using a shift value < 0 or > 31 will get crap as a result. because
it's just undefined. The issue still disturb me, so I try to fix
it again by excluding the especially condition.

Signed-off-by: zhong jiang 
---
 arch/x86/include/asm/futex.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index b4c1f54..c414d76 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -49,9 +49,11 @@ static inline int futex_atomic_op_inuser(int encoded_op, u32 
__user *uaddr)
int cmparg = (encoded_op << 20) >> 20;
int oldval = 0, ret, tem;

-   if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
+   if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
+   if (oparg < 0 || oparg > 31)
+   return -EINVAL;
oparg = 1 << oparg;
-
+   }
if (!access_ok(VERIFY_WRITE, uaddr, 

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

[zhong jiang]

On 2017/6/29 6:13, Thomas Gleixner wrote:
> On Wed, 28 Jun 2017, zhong jiang wrote:
>> On 2017/6/22 0:40, Ingo Molnar wrote:
>>> * zhong jiang  wrote:
>>>
 when shift expoment is negative, left shift alway zero. therefore, we
 modify the logic to avoid the warining.

 Signed-off-by: zhong jiang 
 ---
  arch/x86/include/asm/futex.h | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
 index b4c1f54..2425fca 100644
 --- a/arch/x86/include/asm/futex.h
 +++ b/arch/x86/include/asm/futex.h
 @@ -49,8 +49,12 @@ static inline int futex_atomic_op_inuser(int 
 encoded_op, u32 __user *uaddr)
int cmparg = (encoded_op << 20) >> 20;
int oldval = 0, ret, tem;
  
 -  if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
 -  oparg = 1 << oparg;
 +  if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
 +  if (oparg >= 0)
 +  oparg = 1 << oparg;
 +  else
 +  oparg = 0;
 +  }
>>> Could we avoid all these complications by using an unsigned type?
>>   I think it is not feasible.  a negative shift exponent is likely
>>   existence and reasonable.
> What is reasonable about a negative shift value?
>
>> as the above case, oparg is a negative is common.
> That's simply wrong. If oparg is negative and the SHIFT bit is set then the
> result is undefined today and there is no way that this can be used at
> all.
>
> On x86:
>
>1 << -1= 0x8000
>1 << -2048 = 0x0001
>1 << -2047 = 0x0002
>
> Anything using a shift value < 0 or > 31 will get crap as a
> result. Rightfully so because it's just undefined.
>
> Yes I know that the insanity of user space is unlimited, but anything
> attempting this is so broken that we cannot break it further by making that
> shift arg unsigned and actually limit it to 0-31
>
> Thanks,
>
>   tglx
>
>
>
> .
>
 >From df9e2a5a3f1f401943aeb2718d5876b854dea3a3 Mon Sep 17 00:00:00 2001
From: zhong jiang 
Date: Fri, 25 Aug 2017 12:05:56 +0800
Subject: [PATCH v2] futex: avoid undefined behaviour when shift exponent is
 negative

when futex syscall is called from userspace, we find the following
warning by ubsan detection.

[   63.237803] UBSAN: Undefined behaviour in 
/root/rpmbuild/BUILDROOT/kernel-3.10.0-327.49.58.52.x86_64/usr/src/linux-3.10.0-327.49.58.52.x86_64/arch/x86/include/asm/futex.h:53:13
[   63.237803] shift exponent -16 is negative
[   63.237803] CPU: 0 PID: 67 Comm: driver Not tainted 3.10.0 #1
[   63.237803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
[   63.237803]  fff0 9ad70fde 8802fa08 
81ef0d6f
[   63.237803]  8802fa20 81ef0e2c 828f2540 
8802fb90
[   63.237803]  81ef1ad0 8141cc88 11005f48 
41b58ab3
[   63.237803] Call Trace:
[   63.237803]  [] dump_stack+0x1e/0x20
[   63.237803]  [] ubsan_epilogue+0x12/0x55
[   63.237803]  [] 
__ubsan_handle_shift_out_of_bounds+0x237/0x29c
[   63.237803]  [] ? kasan_alloc_pages+0x38/0x40
[   63.237803]  [] ? 
__ubsan_handle_load_invalid_value+0x162/0x162
[   63.237803]  [] ? get_futex_key+0x361/0x6c0
[   63.237803]  [] ? get_futex_key_refs+0xb0/0xb0
[   63.237803]  [] futex_wake_op+0xb48/0xc70
[   63.237803]  [] ? futex_wake_op+0xb48/0xc70
[   63.237803]  [] ? futex_wake+0x380/0x380
[   63.237803]  [] do_futex+0x2cc/0xb60
[   63.237803]  [] ? exit_robust_list+0x350/0x350
[   63.237803]  [] ? __fsnotify_inode_delete+0x20/0x20
[   63.237803]  [] ? n_tty_flush_buffer+0x80/0x80
[   63.237803]  [] ? __fsnotify_parent+0x53/0x210
[   63.237803]  [] SyS_futex+0x147/0x300
[   63.237803]  [] ? do_futex+0xb60/0xb60
[   63.237803]  [] ? do_page_fault+0x44/0xa0
[   63.237803]  [] system_call_fastpath+0x16/0x1b

using a shift value < 0 or > 31 will get crap as a result. because
it's just undefined. The issue still disturb me, so I try to fix
it again by excluding the especially condition.

Signed-off-by: zhong jiang 
---
 arch/x86/include/asm/futex.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/futex.h b/arch/x86/include/asm/futex.h
index b4c1f54..c414d76 100644
--- a/arch/x86/include/asm/futex.h
+++ b/arch/x86/include/asm/futex.h
@@ -49,9 +49,11 @@ static inline int futex_atomic_op_inuser(int encoded_op, u32 
__user *uaddr)
int cmparg = (encoded_op << 20) >> 20;
int oldval = 0, ret, tem;

-   if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
+   if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
+   if (oparg < 0 || oparg > 31)
+   return -EINVAL;
oparg = 1 << oparg;
-
+   }
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;

Re: [PATCH] zram: add zstd to the supported algorithms list

[Minchan Kim]

Hi Nick,

On Fri, Aug 25, 2017 at 01:35:35AM +, Nick Terrell wrote:
> On 8/24/17, 5:49 PM, "Joonsoo Kim"  wrote:
> > On Thu, Aug 24, 2017 at 09:33:54PM +, Nick Terrell wrote:
> > > On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote:
> > > > Add ZSTD to the list of supported compression algorithms.
> > > > 
> > > > Official benchmarks [1]:
> > > 
> > > Awesome! Let me know if you need anything from me.
> > > 
> > Hello, Nick.
> > 
> > Awesome work!!!
> > 
> > Let me ask a question.
> > Zram compress and decompress a small data (a page) and your github
> > site says that using predefined dictionary would be helpful in this
> > situation. However, it seems that compression crypto API for zstd
> > doesn't use ZSTD_compress_usingDict(). Is there any plan to support
> > it?
> 
> I think using dictionaries in zram could be very interesting. We could for
> example, take a random sample of the RAM and use that as the dictionary
> for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> dictionary (sizes may vary).

For static option, could we create the dictionary with data in zram
and dump the dictionary into file. And then, rebuiling zram or kernel
includes the dictionary into images.

For it, we would need some knob like

cat /sys/block/zram/zstd_dict > dict.data

CONFIG_ZSTD_DICT_DIR=
CONFIG_ZSTD_DICT_FILE= 

For dynamic option, could we make the dictionary with data
in zram dynamically? So, upcoming pages will use the newly
created dictionary but old compressed pages will use own dictionary.

I'm not sure it's possible, anyway, if predefined dict can help
comp ratio a lot in 4K data, I really love the feature and will support
to have it. ;)

> 
> I'm not sure how you would pass a dictionary into the crypto compression
> API, but I'm sure we can make something work if dictionary compression
> proves to be beneficial enough.

Yes, it would be better to integrate the feature crypto but Please, don't tie to
crypto API. If it's hard to support with current cypto API in short time,
I really want to support it with zcomp_zstd.c.

Please look at old zcomp model.
http://elixir.free-electrons.com/linux/v4.7/source/drivers/block/zram/zcomp_lz4.c

> 
> What data have you, or anyone, used for benchmarking compression ratio and 
> speed for RAM? Since it is such a specialized application, the standard
> compression benchmarks aren't very applicable.

I have used my image dumped from desktop swap device.
Of course, it doesn't cover all of cases in the world but it would be better
to use IO benchmark buffer, IMHO. :)

Thanks.

Re: [PATCH] zram: add zstd to the supported algorithms list

[Minchan Kim]

Hi Nick,

On Fri, Aug 25, 2017 at 01:35:35AM +, Nick Terrell wrote:
> On 8/24/17, 5:49 PM, "Joonsoo Kim"  wrote:
> > On Thu, Aug 24, 2017 at 09:33:54PM +, Nick Terrell wrote:
> > > On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote:
> > > > Add ZSTD to the list of supported compression algorithms.
> > > > 
> > > > Official benchmarks [1]:
> > > 
> > > Awesome! Let me know if you need anything from me.
> > > 
> > Hello, Nick.
> > 
> > Awesome work!!!
> > 
> > Let me ask a question.
> > Zram compress and decompress a small data (a page) and your github
> > site says that using predefined dictionary would be helpful in this
> > situation. However, it seems that compression crypto API for zstd
> > doesn't use ZSTD_compress_usingDict(). Is there any plan to support
> > it?
> 
> I think using dictionaries in zram could be very interesting. We could for
> example, take a random sample of the RAM and use that as the dictionary
> for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> dictionary (sizes may vary).

For static option, could we create the dictionary with data in zram
and dump the dictionary into file. And then, rebuiling zram or kernel
includes the dictionary into images.

For it, we would need some knob like

cat /sys/block/zram/zstd_dict > dict.data

CONFIG_ZSTD_DICT_DIR=
CONFIG_ZSTD_DICT_FILE= 

For dynamic option, could we make the dictionary with data
in zram dynamically? So, upcoming pages will use the newly
created dictionary but old compressed pages will use own dictionary.

I'm not sure it's possible, anyway, if predefined dict can help
comp ratio a lot in 4K data, I really love the feature and will support
to have it. ;)

> 
> I'm not sure how you would pass a dictionary into the crypto compression
> API, but I'm sure we can make something work if dictionary compression
> proves to be beneficial enough.

Yes, it would be better to integrate the feature crypto but Please, don't tie to
crypto API. If it's hard to support with current cypto API in short time,
I really want to support it with zcomp_zstd.c.

Please look at old zcomp model.
http://elixir.free-electrons.com/linux/v4.7/source/drivers/block/zram/zcomp_lz4.c

> 
> What data have you, or anyone, used for benchmarking compression ratio and 
> speed for RAM? Since it is such a specialized application, the standard
> compression benchmarks aren't very applicable.

I have used my image dumped from desktop swap device.
Of course, it doesn't cover all of cases in the world but it would be better
to use IO benchmark buffer, IMHO. :)

Thanks.

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 13:50), Minchan Kim wrote:
[..]
> Thanks for the testing.
> Could you resend the patch with this test result with my acked-by?

ok.

> Acked-by: Minchan Kim 

thanks.

> Off-topic:
> 
> In all ways, zstd beats deflate. Nick, Right?
> 
> With zstd, I doubt we should show "deflate" to user. Many options just
> make user confused.
> The inflate have been there for representing high comp ratio but slower
> speed. However, zstd is better unconditionally compared to deflate
> so how about replacing deflate with zstd?
> 
> Sergey, what do you think about it?

hmmm... frankly, I don't think it would confuse anyone. the code is
there - compiled - anyway, and the module is visible in /proc/crypto
etc. if we will make it unavailable in zram then this can be confusing,
probably... if anyone ever pays any attention at all. my guess is that
people look what's in /sys/block/zram0/comp_algorithm just once, then
they set up a create-zram script/systemd unit file/etc. and forget
about it.

cryto API is just a wrapper and it calls lib/comp_foo to do the actual
work, and that lib/comp_foo *may be* can be implemented as a H/W (not
S/W) compressing backend. well, who knows.

-ss

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 13:50), Minchan Kim wrote:
[..]
> Thanks for the testing.
> Could you resend the patch with this test result with my acked-by?

ok.

> Acked-by: Minchan Kim 

thanks.

> Off-topic:
> 
> In all ways, zstd beats deflate. Nick, Right?
> 
> With zstd, I doubt we should show "deflate" to user. Many options just
> make user confused.
> The inflate have been there for representing high comp ratio but slower
> speed. However, zstd is better unconditionally compared to deflate
> so how about replacing deflate with zstd?
> 
> Sergey, what do you think about it?

hmmm... frankly, I don't think it would confuse anyone. the code is
there - compiled - anyway, and the module is visible in /proc/crypto
etc. if we will make it unavailable in zram then this can be confusing,
probably... if anyone ever pays any attention at all. my guess is that
people look what's in /sys/block/zram0/comp_algorithm just once, then
they set up a create-zram script/systemd unit file/etc. and forget
about it.

cryto API is just a wrapper and it calls lib/comp_foo to do the actual
work, and that lib/comp_foo *may be* can be implemented as a H/W (not
S/W) compressing backend. well, who knows.

-ss

Re: [PATCH] strparser: initialize all callbacks

[David Miller]

From: Eric Biggers 
Date: Thu, 24 Aug 2017 14:38:51 -0700

> From: Eric Biggers 
> 
> commit bbb03029a899 ("strparser: Generalize strparser") added more
> function pointers to 'struct strp_callbacks'; however, kcm_attach() was
> not updated to initialize them.  This could cause the ->lock() and/or
> ->unlock() function pointers to be set to garbage values, causing a
> crash in strp_work().
> 
> Fix the bug by moving the callback structs into static memory, so
> unspecified members are zeroed.  Also constify them while we're at it.
> 
> This bug was found by syzkaller, which encountered the following splat:
 ...
> Fixes: bbb03029a899 ("strparser: Generalize strparser")
> Signed-off-by: Eric Biggers 

This commit is only in net-next, so that is where I am applying
this patch.

Thanks.

Re: [PATCH] strparser: initialize all callbacks

[David Miller]

From: Eric Biggers 
Date: Thu, 24 Aug 2017 14:38:51 -0700

> From: Eric Biggers 
> 
> commit bbb03029a899 ("strparser: Generalize strparser") added more
> function pointers to 'struct strp_callbacks'; however, kcm_attach() was
> not updated to initialize them.  This could cause the ->lock() and/or
> ->unlock() function pointers to be set to garbage values, causing a
> crash in strp_work().
> 
> Fix the bug by moving the callback structs into static memory, so
> unspecified members are zeroed.  Also constify them while we're at it.
> 
> This bug was found by syzkaller, which encountered the following splat:
 ...
> Fixes: bbb03029a899 ("strparser: Generalize strparser")
> Signed-off-by: Eric Biggers 

This commit is only in net-next, so that is where I am applying
this patch.

Thanks.

Re: [PATCH net-next] hv_netvsc: Fix rndis_filter_close error during netvsc_remove

[David Miller]

From: Haiyang Zhang 
Date: Thu, 24 Aug 2017 11:50:02 -0700

> From: Haiyang Zhang 
> 
> We now remove rndis filter before unregister_netdev(), which calls
> device close. It involves closing rndis filter already removed.
> 
> This patch fixes this error.
> 
> Signed-off-by: Haiyang Zhang 

Applied.

Re: [PATCH net-next] hv_netvsc: Fix rndis_filter_close error during netvsc_remove

[David Miller]

From: Haiyang Zhang 
Date: Thu, 24 Aug 2017 11:50:02 -0700

> From: Haiyang Zhang 
> 
> We now remove rndis filter before unregister_netdev(), which calls
> device close. It involves closing rndis filter already removed.
> 
> This patch fixes this error.
> 
> Signed-off-by: Haiyang Zhang 

Applied.

linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/esr.h

between commit:

  1f9b8936f36f ("arm64: Decode information from ESR upon mem faults")

from the arm64 tree and commit:

  c5511c3c068c ("KVM: arm/arm64: Fix guest external abort matching")

from the kvm-arm tree.

I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/include/asm/esr.h

between commit:

  1f9b8936f36f ("arm64: Decode information from ESR upon mem faults")

from the arm64 tree and commit:

  c5511c3c068c ("KVM: arm/arm64: Fix guest external abort matching")

from the kvm-arm tree.

I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v6] mtd: sharpslpart: Add sharpslpart partition parser

[Brian Norris]

On Thu, Aug 24, 2017 at 01:27:10PM +0200, Boris Brezillon wrote:
> On Thu, 24 Aug 2017 12:30:02 +0200
> Andrea Adami  wrote:
> 
> > On Thu, Aug 24, 2017 at 12:04 PM, Boris Brezillon
> >  wrote:
> > > On Thu, 24 Aug 2017 11:19:56 +0200
> > > Andrea Adami  wrote:

...

> > >> >> + /* create physical-logical table */
> > >> >> + for (block_num = 0; block_num < phymax; block_num++) {
> > >> >> + block_adr = block_num * mtd->erasesize;
> > >> >> +
> > >> >> + if (mtd_block_isbad(mtd, block_adr))
> > >> >> + continue;
> > >> >> +
> > >> >> + if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, 
> > >> >> oob))
> > >> >> + continue;
> > >> >> +
> > >> >> + /* get logical block */
> > >> >> + log_num = sharpsl_nand_get_logical_num(oob);
> > >> >> +
> > >> >> + /* FTL is not used? Exit here if the oob fingerprint is 
> > >> >> wrong */
> > >> >> + if (log_num == UINT_MAX) {
> > >> >> + pr_info("sharpslpart: Sharp SL FTL not 
> > >> >> found.\n");
> > >> >> + ret = -EINVAL;
> > >> >> + goto exit;
> > >> >> + }  
> > >
> > > Okay, I overlooked that part. Why do you exit if there's a fingerprint
> > > mismatch? Can't you just ignore this physical block and continue
> > > scanning the remaining ones?  
> > 
> > Norris asked to quit immediately in this case.
> > https://patchwork.kernel.org/patch/9758361/

I didn't specifically ask for you to quit in *that* case. Quoting myself
here, as you did:

> > "I wouldn't expect people to want to use this parser, but if we have a
> > quick way to say "this doesn't match, skip me", then that would be
> > helpful."
> > "We don't want to waste too much time scanning for this partition
> > table if possible."

That means, is there something (not necessarily writting in the
"original code" that you're massaging) that could be used to reliably
detect that this is/isn't a valid "Sharp FTL"? I don't think the check
you wrote is a good one. Particularly, you *don't* want to just abort
completely because there's one corrupt block. This check is a
reliability check (so you can possibly ignore old/bad copies and skip
onto better blocks), not a validity check. It is counter-productive to
abort here, IIUC.

> Actually, you don't save much by exiting on "bad OOB fingerprint". If
> you look at the code you'll see that the only thing you check is
> whether some oob portions are equal or not, and most of the time the
> OOB area is left untouched by the upper layer, which means all free
> bytes will be left to 0xff, which in turn means the "is fingerprint
> good?" test will pass.

Agreed.

I'd drop this "abort early" check and just admit that it's not possible
to do what I asked.

> > Now we are quitting ever before checking for parity erors ...
> 
> Honestly, I'd recommend not using this parser for anything but SHARPSL
> platforms, so I don't think we care much about the "scan all blocks"
> overhead.

Sounds about right.

> Moreover, the sharpsl parser is the last one in the
> part_parsers list, so it should be quite fast if the user specifies a
> valid mtdparts= on the cmdline or valid partitions in the DT.

Brian

P.S. I alluded to it earlier, but I figured I should write it down
properly here sometime, as food for thought; you don't actually need any
of this parser at all if you're willing to contruct an initramfs that
will do the parsing in user space (e.g., some scripting and 'nanddump';
or link to libmtd) and then add partitions yourself (e.g., with
'mtdpart add ...', or calling the BLKPG ioctls directly). This would
just require you have a kernel with CONFIG_MTD_PARTITIONED_MASTER=y.

Re: [PATCH v6] mtd: sharpslpart: Add sharpslpart partition parser

[Brian Norris]

On Thu, Aug 24, 2017 at 01:27:10PM +0200, Boris Brezillon wrote:
> On Thu, 24 Aug 2017 12:30:02 +0200
> Andrea Adami  wrote:
> 
> > On Thu, Aug 24, 2017 at 12:04 PM, Boris Brezillon
> >  wrote:
> > > On Thu, 24 Aug 2017 11:19:56 +0200
> > > Andrea Adami  wrote:

...

> > >> >> + /* create physical-logical table */
> > >> >> + for (block_num = 0; block_num < phymax; block_num++) {
> > >> >> + block_adr = block_num * mtd->erasesize;
> > >> >> +
> > >> >> + if (mtd_block_isbad(mtd, block_adr))
> > >> >> + continue;
> > >> >> +
> > >> >> + if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, 
> > >> >> oob))
> > >> >> + continue;
> > >> >> +
> > >> >> + /* get logical block */
> > >> >> + log_num = sharpsl_nand_get_logical_num(oob);
> > >> >> +
> > >> >> + /* FTL is not used? Exit here if the oob fingerprint is 
> > >> >> wrong */
> > >> >> + if (log_num == UINT_MAX) {
> > >> >> + pr_info("sharpslpart: Sharp SL FTL not 
> > >> >> found.\n");
> > >> >> + ret = -EINVAL;
> > >> >> + goto exit;
> > >> >> + }  
> > >
> > > Okay, I overlooked that part. Why do you exit if there's a fingerprint
> > > mismatch? Can't you just ignore this physical block and continue
> > > scanning the remaining ones?  
> > 
> > Norris asked to quit immediately in this case.
> > https://patchwork.kernel.org/patch/9758361/

I didn't specifically ask for you to quit in *that* case. Quoting myself
here, as you did:

> > "I wouldn't expect people to want to use this parser, but if we have a
> > quick way to say "this doesn't match, skip me", then that would be
> > helpful."
> > "We don't want to waste too much time scanning for this partition
> > table if possible."

That means, is there something (not necessarily writting in the
"original code" that you're massaging) that could be used to reliably
detect that this is/isn't a valid "Sharp FTL"? I don't think the check
you wrote is a good one. Particularly, you *don't* want to just abort
completely because there's one corrupt block. This check is a
reliability check (so you can possibly ignore old/bad copies and skip
onto better blocks), not a validity check. It is counter-productive to
abort here, IIUC.

> Actually, you don't save much by exiting on "bad OOB fingerprint". If
> you look at the code you'll see that the only thing you check is
> whether some oob portions are equal or not, and most of the time the
> OOB area is left untouched by the upper layer, which means all free
> bytes will be left to 0xff, which in turn means the "is fingerprint
> good?" test will pass.

Agreed.

I'd drop this "abort early" check and just admit that it's not possible
to do what I asked.

> > Now we are quitting ever before checking for parity erors ...
> 
> Honestly, I'd recommend not using this parser for anything but SHARPSL
> platforms, so I don't think we care much about the "scan all blocks"
> overhead.

Sounds about right.

> Moreover, the sharpsl parser is the last one in the
> part_parsers list, so it should be quite fast if the user specifies a
> valid mtdparts= on the cmdline or valid partitions in the DT.

Brian

P.S. I alluded to it earlier, but I figured I should write it down
properly here sometime, as food for thought; you don't actually need any
of this parser at all if you're willing to contruct an initramfs that
will do the parsing in user space (e.g., some scripting and 'nanddump';
or link to libmtd) and then add partitions yourself (e.g., with
'mtdpart add ...', or calling the BLKPG ioctls directly). This would
just require you have a kernel with CONFIG_MTD_PARTITIONED_MASTER=y.

Re: [PATCH 2/2 v8] printk: Add monotonic, boottime, and realtime timestamps

[Sergey Senozhatsky]

On (08/24/17 09:42), Prarit Bhargava wrote:
[..]
> +config PRINTK_TIME_DEBUG
> + bool "Allow runtime reselection of any timebase on printks"
> + depends on PRINTK
> + default N
> + help
> +   Selecting this option causes time stamps of the printk()
> +   messages to be changed freely at runtime on the output of
> +   the syslog() system call and at the console. Without this
> +   option, one can only enable or disable the configuration
> +   selected timebase.
> +
> +   Runtime adjustment can be set via
> +   /sys/module/printk/paramters/time as follows with a string:

s/paramters/parameters/

> +   0/N/n/disable, 1/Y/y/local, b/boot, m/monotonic, r/realtime.
> +   eg: echo local >/sys/module/printk/parameters/time
> +   echo realtime >/sys/module/printk/parameters/time

-ss

Re: [PATCH 2/2 v8] printk: Add monotonic, boottime, and realtime timestamps

[Sergey Senozhatsky]

On (08/24/17 09:42), Prarit Bhargava wrote:
[..]
> +config PRINTK_TIME_DEBUG
> + bool "Allow runtime reselection of any timebase on printks"
> + depends on PRINTK
> + default N
> + help
> +   Selecting this option causes time stamps of the printk()
> +   messages to be changed freely at runtime on the output of
> +   the syslog() system call and at the console. Without this
> +   option, one can only enable or disable the configuration
> +   selected timebase.
> +
> +   Runtime adjustment can be set via
> +   /sys/module/printk/paramters/time as follows with a string:

s/paramters/parameters/

> +   0/N/n/disable, 1/Y/y/local, b/boot, m/monotonic, r/realtime.
> +   eg: echo local >/sys/module/printk/parameters/time
> +   echo realtime >/sys/module/printk/parameters/time

-ss

Re: [PATCH] zram: add zstd to the supported algorithms list

[Minchan Kim]

Hi Sergey,

On Thu, Aug 24, 2017 at 11:04:40PM +0900, Sergey Senozhatsky wrote:
> Hi,
> 
> On (08/24/17 13:30), Minchan Kim wrote:
> > Hello Sergey,
> > 
> > On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote:
> > > Add ZSTD to the list of supported compression algorithms.
> > > 
> > > Official benchmarks [1]:
> > 
> > First of all, thanks for the work!
> > 
> > I want to ask one thing.
> > 
> > Could you add some benchmark(e.g.,) result(comp ratio and speed)
> > compared to (inflate, lzo, lz4)?
> > 
> > I want to see how much it's good for small data that ours is 4K.
> 
> 
> so on my syntetic fio test (with a static buffer):
> 
> 
>  LZO DEFLATE ZSTD
> 
> #jobs1
> WRITE:  (2180MB/s) (77.2MB/s)  (1429MB/s)
> WRITE:  (1617MB/s) (77.7MB/s)  (1202MB/s)
> READ:(426MB/s) (595MB/s)   (1181MB/s)
> READ:(422MB/s) (572MB/s)   (1020MB/s)
> READ:(318MB/s) (67.8MB/s)  (563MB/s) 
> WRITE:   (318MB/s) (67.9MB/s)  (564MB/s) 
> READ:(336MB/s) (68.3MB/s)  (583MB/s) 
> WRITE:   (335MB/s) (68.2MB/s)  (582MB/s) 
> #jobs2
> WRITE:  (3441MB/s) (152MB/s)   (2141MB/s)
> WRITE:  (2507MB/s) (147MB/s)   (1888MB/s)
> READ:(801MB/s) (1146MB/s)  (1890MB/s)
> READ:(767MB/s) (1096MB/s)  (2073MB/s)
> READ:(621MB/s) (126MB/s)   (1009MB/s)
> WRITE:   (621MB/s) (126MB/s)   (1009MB/s)
> READ:(656MB/s) (125MB/s)   (1075MB/s)
> WRITE:   (657MB/s) (126MB/s)   (1077MB/s)
> #jobs3
> WRITE:  (4772MB/s) (225MB/s)   (3394MB/s)
> WRITE:  (3905MB/s) (211MB/s)   (2939MB/s)
> READ:   (1216MB/s) (1608MB/s)  (3218MB/s)
> READ:   (1159MB/s) (1431MB/s)  (2981MB/s)
> READ:(906MB/s) (156MB/s)   (1457MB/s)
> WRITE:   (907MB/s) (156MB/s)   (1458MB/s)
> READ:(953MB/s) (158MB/s)   (1595MB/s)
> WRITE:   (952MB/s) (157MB/s)   (1593MB/s)
> #jobs4
> WRITE:  (6036MB/s) (265MB/s)   (4469MB/s)
> WRITE:  (5059MB/s) (263MB/s)   (3951MB/s)
> READ:   (1618MB/s) (2066MB/s)  (4276MB/s)
> READ:   (1573MB/s) (1942MB/s)  (3830MB/s)
> READ:   (1202MB/s) (227MB/s)   (1971MB/s)
> WRITE:  (1200MB/s) (227MB/s)   (1968MB/s)
> READ:   (1265MB/s) (226MB/s)   (2116MB/s)
> WRITE:  (1264MB/s) (226MB/s)   (2114MB/s)
> #jobs5
> WRITE:  (5339MB/s) (233MB/s)   (3781MB/s)
> WRITE:  (4298MB/s) (234MB/s)   (3276MB/s)
> READ:   (1626MB/s) (2048MB/s)  (4081MB/s)
> READ:   (1567MB/s) (1929MB/s)  (3758MB/s)
> READ:   (1174MB/s) (205MB/s)   (1747MB/s)
> WRITE:  (1173MB/s) (204MB/s)   (1746MB/s)
> READ:   (1214MB/s) (208MB/s)   (1890MB/s)
> WRITE:  (1215MB/s) (208MB/s)   (1892MB/s)
> #jobs6
> WRITE:  (5666MB/s) (270MB/s)   (4338MB/s)
> WRITE:  (4828MB/s) (267MB/s)   (3772MB/s)
> READ:   (1803MB/s) (2058MB/s)  (4946MB/s)
> READ:   (1805MB/s) (2156MB/s)  (4711MB/s)
> READ:   (1334MB/s) (235MB/s)   (2135MB/s)
> WRITE:  (1335MB/s) (235MB/s)   (2137MB/s)
> READ:   (1364MB/s) (236MB/s)   (2268MB/s)
> WRITE:  (1365MB/s) (237MB/s)   (2270MB/s)
> #jobs7
> WRITE:  (5474MB/s) (270MB/s)   (4300MB/s)
> WRITE:  (4666MB/s) (266MB/s)   (3817MB/s)
> READ:   (2022MB/s) (2319MB/s)  (5472MB/s)
> READ:   (1924MB/s) 

Re: [PATCH] zram: add zstd to the supported algorithms list

[Minchan Kim]

Hi Sergey,

On Thu, Aug 24, 2017 at 11:04:40PM +0900, Sergey Senozhatsky wrote:
> Hi,
> 
> On (08/24/17 13:30), Minchan Kim wrote:
> > Hello Sergey,
> > 
> > On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote:
> > > Add ZSTD to the list of supported compression algorithms.
> > > 
> > > Official benchmarks [1]:
> > 
> > First of all, thanks for the work!
> > 
> > I want to ask one thing.
> > 
> > Could you add some benchmark(e.g.,) result(comp ratio and speed)
> > compared to (inflate, lzo, lz4)?
> > 
> > I want to see how much it's good for small data that ours is 4K.
> 
> 
> so on my syntetic fio test (with a static buffer):
> 
> 
>  LZO DEFLATE ZSTD
> 
> #jobs1
> WRITE:  (2180MB/s) (77.2MB/s)  (1429MB/s)
> WRITE:  (1617MB/s) (77.7MB/s)  (1202MB/s)
> READ:(426MB/s) (595MB/s)   (1181MB/s)
> READ:(422MB/s) (572MB/s)   (1020MB/s)
> READ:(318MB/s) (67.8MB/s)  (563MB/s) 
> WRITE:   (318MB/s) (67.9MB/s)  (564MB/s) 
> READ:(336MB/s) (68.3MB/s)  (583MB/s) 
> WRITE:   (335MB/s) (68.2MB/s)  (582MB/s) 
> #jobs2
> WRITE:  (3441MB/s) (152MB/s)   (2141MB/s)
> WRITE:  (2507MB/s) (147MB/s)   (1888MB/s)
> READ:(801MB/s) (1146MB/s)  (1890MB/s)
> READ:(767MB/s) (1096MB/s)  (2073MB/s)
> READ:(621MB/s) (126MB/s)   (1009MB/s)
> WRITE:   (621MB/s) (126MB/s)   (1009MB/s)
> READ:(656MB/s) (125MB/s)   (1075MB/s)
> WRITE:   (657MB/s) (126MB/s)   (1077MB/s)
> #jobs3
> WRITE:  (4772MB/s) (225MB/s)   (3394MB/s)
> WRITE:  (3905MB/s) (211MB/s)   (2939MB/s)
> READ:   (1216MB/s) (1608MB/s)  (3218MB/s)
> READ:   (1159MB/s) (1431MB/s)  (2981MB/s)
> READ:(906MB/s) (156MB/s)   (1457MB/s)
> WRITE:   (907MB/s) (156MB/s)   (1458MB/s)
> READ:(953MB/s) (158MB/s)   (1595MB/s)
> WRITE:   (952MB/s) (157MB/s)   (1593MB/s)
> #jobs4
> WRITE:  (6036MB/s) (265MB/s)   (4469MB/s)
> WRITE:  (5059MB/s) (263MB/s)   (3951MB/s)
> READ:   (1618MB/s) (2066MB/s)  (4276MB/s)
> READ:   (1573MB/s) (1942MB/s)  (3830MB/s)
> READ:   (1202MB/s) (227MB/s)   (1971MB/s)
> WRITE:  (1200MB/s) (227MB/s)   (1968MB/s)
> READ:   (1265MB/s) (226MB/s)   (2116MB/s)
> WRITE:  (1264MB/s) (226MB/s)   (2114MB/s)
> #jobs5
> WRITE:  (5339MB/s) (233MB/s)   (3781MB/s)
> WRITE:  (4298MB/s) (234MB/s)   (3276MB/s)
> READ:   (1626MB/s) (2048MB/s)  (4081MB/s)
> READ:   (1567MB/s) (1929MB/s)  (3758MB/s)
> READ:   (1174MB/s) (205MB/s)   (1747MB/s)
> WRITE:  (1173MB/s) (204MB/s)   (1746MB/s)
> READ:   (1214MB/s) (208MB/s)   (1890MB/s)
> WRITE:  (1215MB/s) (208MB/s)   (1892MB/s)
> #jobs6
> WRITE:  (5666MB/s) (270MB/s)   (4338MB/s)
> WRITE:  (4828MB/s) (267MB/s)   (3772MB/s)
> READ:   (1803MB/s) (2058MB/s)  (4946MB/s)
> READ:   (1805MB/s) (2156MB/s)  (4711MB/s)
> READ:   (1334MB/s) (235MB/s)   (2135MB/s)
> WRITE:  (1335MB/s) (235MB/s)   (2137MB/s)
> READ:   (1364MB/s) (236MB/s)   (2268MB/s)
> WRITE:  (1365MB/s) (237MB/s)   (2270MB/s)
> #jobs7
> WRITE:  (5474MB/s) (270MB/s)   (4300MB/s)
> WRITE:  (4666MB/s) (266MB/s)   (3817MB/s)
> READ:   (2022MB/s) (2319MB/s)  (5472MB/s)
> READ:   (1924MB/s) 

Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic

[David Miller]

From: Antoine Tenart 
Date: Thu, 24 Aug 2017 11:46:54 +0200

> The MAC address retrieval logic was broken and when using the PPv2
> driver on PPv2.2 engines I ended up using the same mac address on all
> ports. This series of patches fixes this, and also tackle a possible bug
> when defining the mac address in the device tree.
> 
> To fix this in a nice way I ended up using a dedicated function to
> handle the mac retrieval logic. This can be hard to backport into stable
> kernels. This is why I also made a quick fix which is easy to backport
> (patch 1/14), to tackle down the PPv2.2 mac retrieval bug. Let me know
> if this approach is the proper way to handle this or if I should do
> something else.

This patch series doesn't apply to any of my trees, that is the first
thing.

Secondly, this is a bug fix, and the bug exists in the 'net' tree.
Therefore this patch series should target the 'net' tree.

Please always target legitimate bug fixes at the 'net' tree, rather
than 'net-next'.

Thank you.

Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic

[David Miller]

From: Antoine Tenart 
Date: Thu, 24 Aug 2017 11:46:54 +0200

> The MAC address retrieval logic was broken and when using the PPv2
> driver on PPv2.2 engines I ended up using the same mac address on all
> ports. This series of patches fixes this, and also tackle a possible bug
> when defining the mac address in the device tree.
> 
> To fix this in a nice way I ended up using a dedicated function to
> handle the mac retrieval logic. This can be hard to backport into stable
> kernels. This is why I also made a quick fix which is easy to backport
> (patch 1/14), to tackle down the PPv2.2 mac retrieval bug. Let me know
> if this approach is the proper way to handle this or if I should do
> something else.

This patch series doesn't apply to any of my trees, that is the first
thing.

Secondly, this is a bug fix, and the bug exists in the 'net' tree.
Therefore this patch series should target the 'net' tree.

Please always target legitimate bug fixes at the 'net' tree, rather
than 'net-next'.

Thank you.

linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/mmu.h

between commit:

  d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")

from the tip tree and commit:

  d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical 
address width.")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/mmu.h
index 3cc725590ab9,e2999f57bfc4..
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@@ -48,7 -49,10 +49,10 @@@
  
  static inline u64 rsvd_bits(int s, int e)
  {
+   if (e < s)
+   return 0;
+ 
 -  return ((1ULL << (e - s + 1)) - 1) << s;
 +  return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
  }
  
  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);

linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/mmu.h

between commit:

  d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM")

from the tip tree and commit:

  d1cd3ce90044 ("KVM: MMU: check guest CR3 reserved bits based on its physical 
address width.")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/mmu.h
index 3cc725590ab9,e2999f57bfc4..
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@@ -48,7 -49,10 +49,10 @@@
  
  static inline u64 rsvd_bits(int s, int e)
  {
+   if (e < s)
+   return 0;
+ 
 -  return ((1ULL << (e - s + 1)) - 1) << s;
 +  return __sme_clr(((1ULL << (e - s + 1)) - 1) << s);
  }
  
  void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value);

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

[Byungchul Park]

On Thu, Aug 24, 2017 at 04:02:40PM +0200, Peter Zijlstra wrote:
> > > + if (c == XHLOCK_PROC) {

I found this now. Are you trying to invalidate it w/o checking force?
No, we _should not_ do this. It's worse than work-around code.

No reason to do this here. Please communicate with me more or understand
how this code works before applying it.

> > > + /* verified the former, ensure the latter */
> > > + WARN_ON_ONCE(!force && cur->lockdep_depth);
> > > + invalidate_xhlock((cur->xhlock_idx));
> > >   }

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

[Byungchul Park]

On Thu, Aug 24, 2017 at 04:02:40PM +0200, Peter Zijlstra wrote:
> > > + if (c == XHLOCK_PROC) {

I found this now. Are you trying to invalidate it w/o checking force?
No, we _should not_ do this. It's worse than work-around code.

No reason to do this here. Please communicate with me more or understand
how this code works before applying it.

> > > + /* verified the former, ensure the latter */
> > > + WARN_ON_ONCE(!force && cur->lockdep_depth);
> > > + invalidate_xhlock((cur->xhlock_idx));
> > >   }

Re: [PATCH net-next v2] net: mv643xx_eth: Be drop monitor friendly

[Eric Dumazet]

On Thu, 2017-08-24 at 20:55 -0700, Florian Fainelli wrote:
> txq_reclaim() does the normal transmit queue reclamation and
> rxq_deinit() does the RX ring cleanup, none of these are packet drops,
> so use dev_consume_skb() for both locations.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index fb2d533ae4ef..81c1fac00d33 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -1121,7 +1121,7 @@ static int txq_reclaim(struct tx_queue *txq, int 
> budget, int force)
>   struct sk_buff *skb = __skb_dequeue(>tx_skb);
>  
>   if (!WARN_ON(!skb))
> - dev_kfree_skb(skb);
> + dev_consume_skb_any(skb);
>   }
>  
>   if (cmd_sts & ERROR_SUMMARY) {
> @@ -2024,7 +2024,7 @@ static void rxq_deinit(struct rx_queue *rxq)
>  
>   for (i = 0; i < rxq->rx_ring_size; i++) {
>   if (rxq->rx_skb[i]) {
> - dev_kfree_skb(rxq->rx_skb[i]);
> + dev_consume_skb_any(rxq->rx_skb[i]);
>   rxq->rx_desc_count--;
>   }
>   }


I do not believe this patch is needed.

dev_kfree_skb() is an alias of consume_skb(), which is already drop
monitor ready ;)

Re: [PATCH net-next v2] net: mv643xx_eth: Be drop monitor friendly

[Eric Dumazet]

On Thu, 2017-08-24 at 20:55 -0700, Florian Fainelli wrote:
> txq_reclaim() does the normal transmit queue reclamation and
> rxq_deinit() does the RX ring cleanup, none of these are packet drops,
> so use dev_consume_skb() for both locations.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index fb2d533ae4ef..81c1fac00d33 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -1121,7 +1121,7 @@ static int txq_reclaim(struct tx_queue *txq, int 
> budget, int force)
>   struct sk_buff *skb = __skb_dequeue(>tx_skb);
>  
>   if (!WARN_ON(!skb))
> - dev_kfree_skb(skb);
> + dev_consume_skb_any(skb);
>   }
>  
>   if (cmd_sts & ERROR_SUMMARY) {
> @@ -2024,7 +2024,7 @@ static void rxq_deinit(struct rx_queue *rxq)
>  
>   for (i = 0; i < rxq->rx_ring_size; i++) {
>   if (rxq->rx_skb[i]) {
> - dev_kfree_skb(rxq->rx_skb[i]);
> + dev_consume_skb_any(rxq->rx_skb[i]);
>   rxq->rx_desc_count--;
>   }
>   }


I do not believe this patch is needed.

dev_kfree_skb() is an alias of consume_skb(), which is already drop
monitor ready ;)

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/include/asm/cpufeatures.h

between commit:

  5442c2699552 ("x86/cpufeature, kvm/svm: Rename (shorten) the new "virtualized 
VMSAVE/VMLOAD" CPUID flag")

from Linus' tree and commit:

  d837312dfd5b ("KVM: SVM: Add Virtual GIF feature definition")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/cpufeatures.h
index 42bbbf0f173d,0e25e7a8ab03..
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -287,7 -286,8 +287,8 @@@
  #define X86_FEATURE_PAUSEFILTER (15*32+10) /* filtered pause intercept */
  #define X86_FEATURE_PFTHRESHOLD (15*32+12) /* pause filter threshold */
  #define X86_FEATURE_AVIC  (15*32+13) /* Virtual Interrupt Controller */
 -#define X86_FEATURE_VIRTUAL_VMLOAD_VMSAVE (15*32+15) /* Virtual VMLOAD VMSAVE 
*/
 +#define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* Virtual VMSAVE VMLOAD */
+ #define X86_FEATURE_VGIF  (15*32+16) /* Virtual GIF */
  
  /* Intel-defined CPU features, CPUID level 0x0007:0 (ecx), word 16 */
  #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation 
instructions*/

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/include/asm/cpufeatures.h

between commit:

  5442c2699552 ("x86/cpufeature, kvm/svm: Rename (shorten) the new "virtualized 
VMSAVE/VMLOAD" CPUID flag")

from Linus' tree and commit:

  d837312dfd5b ("KVM: SVM: Add Virtual GIF feature definition")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/cpufeatures.h
index 42bbbf0f173d,0e25e7a8ab03..
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@@ -287,7 -286,8 +287,8 @@@
  #define X86_FEATURE_PAUSEFILTER (15*32+10) /* filtered pause intercept */
  #define X86_FEATURE_PFTHRESHOLD (15*32+12) /* pause filter threshold */
  #define X86_FEATURE_AVIC  (15*32+13) /* Virtual Interrupt Controller */
 -#define X86_FEATURE_VIRTUAL_VMLOAD_VMSAVE (15*32+15) /* Virtual VMLOAD VMSAVE 
*/
 +#define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* Virtual VMSAVE VMLOAD */
+ #define X86_FEATURE_VGIF  (15*32+16) /* Virtual GIF */
  
  /* Intel-defined CPU features, CPUID level 0x0007:0 (ecx), word 16 */
  #define X86_FEATURE_AVX512VBMI  (16*32+ 1) /* AVX512 Vector Bit Manipulation 
instructions*/

Re: [PATCH net-next v2] e1000e: Be drop monitor friendly

[David Miller]

From: Florian Fainelli 
Date: Thu, 24 Aug 2017 20:58:24 -0700

> e1000_put_txbuf() cleans up the successfully transmitted TX packets,
> e1000e_tx_hwtstamp_work() also does the successfully completes the
> timestamped TX packets, e1000_clean_rx_ring() cleans up the RX ring and
> e1000_remove() cleans up the timestampted packets. None of these
> functions should be reporting dropped packets, so make them use
> dev_consume_skb_any() to be drop monitor friendly.
> 
> Signed-off-by: Florian Fainelli 

I'll let the Intel folks pick this up.

Re: [PATCH net-next v2] e1000e: Be drop monitor friendly

[David Miller]

From: Florian Fainelli 
Date: Thu, 24 Aug 2017 20:58:24 -0700

> e1000_put_txbuf() cleans up the successfully transmitted TX packets,
> e1000e_tx_hwtstamp_work() also does the successfully completes the
> timestamped TX packets, e1000_clean_rx_ring() cleans up the RX ring and
> e1000_remove() cleans up the timestampted packets. None of these
> functions should be reporting dropped packets, so make them use
> dev_consume_skb_any() to be drop monitor friendly.
> 
> Signed-off-by: Florian Fainelli 

I'll let the Intel folks pick this up.

Re: [PATCH net-next v2] net: mv643xx_eth: Be drop monitor friendly

[David Miller]

From: Florian Fainelli 
Date: Thu, 24 Aug 2017 20:55:40 -0700

> txq_reclaim() does the normal transmit queue reclamation and
> rxq_deinit() does the RX ring cleanup, none of these are packet drops,
> so use dev_consume_skb() for both locations.
> 
> Signed-off-by: Florian Fainelli 

Applied.

Re: [PATCH net-next v2] net: mv643xx_eth: Be drop monitor friendly

[David Miller]

From: Florian Fainelli 
Date: Thu, 24 Aug 2017 20:55:40 -0700

> txq_reclaim() does the normal transmit queue reclamation and
> rxq_deinit() does the RX ring cleanup, none of these are packet drops,
> so use dev_consume_skb() for both locations.
> 
> Signed-off-by: Florian Fainelli 

Applied.

[git pull] drm fixes for 4.13-rc7

[Dave Airlie]

Hi Linus,

Fixes for rc7, nothing too crazy, some core, i915, and sunxi fixes,
Intel CI has been responsible for some of these fixes being required.

Dave.

The following changes since commit 14ccee78fc82f5512908f4424f541549a5705b89:

  Linux 4.13-rc6 (2017-08-20 14:13:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc7

for you to fetch changes up to da6119797705c2270f17b287660a1e7bd782a1eb:

  Merge tag 'drm-misc-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-08-25
09:29:38 +1000)


drm fixes for 4.13-rc7, i915, core, imx and sun4i


Andy Shevchenko (1):
  drm/i915/bxt: use NULL for GPIO connection ID

Arnd Bergmann (1):
  gpu: ipu-v3: add DRM dependency

Balasubramaniam, Hari Chand (1):
  drm/i915: Initialize 'data' in intel_dsi_dcs_backlight.c

Chris Wilson (2):
  drm/i915: Clear lost context-switch interrupts across reset
  drm: Release driver tracking before making the object available again

Dave Airlie (5):
  Merge tag 'sunxi-drm-fixes-for-4.13' of
https://git.kernel.org/.../mripard/linux into drm-fixes
  Merge tag 'imx-drm-fixes-2017-08-18' of
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-18' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Jani Nikula (2):
  drm/i915/vbt: ignore extraneous child devices for a port
  Merge tag 'gvt-fixes-2017-08-23' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Jeffy Chen (1):
  drm/rockchip: Fix suspend crash when drm is not bound

Jonathan Liu (1):
  drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Maarten Lankhorst (2):
  drm/atomic: Handle -EDEADLK with out-fences correctly
  drm/atomic: If the atomic check fails, return its value first

Nikhil Mahale (1):
  drm: Fix framebuffer leak

Philipp Zabel (1):
  drm/imx: ipuv3-plane: fix YUV framebuffer scanout on the base plane

Rodrigo Vivi (1):
  drm/i915/cnl: Fix LSPCON support.

Sean Paul (1):
  Merge origin/master into drm-misc-fixes

fred gao (1):
  drm/i915/gvt: Fix the kernel null pointer error

 drivers/gpu/drm/drm_atomic.c   | 11 ---
 drivers/gpu/drm/drm_gem.c  |  6 +++---
 drivers/gpu/drm/drm_plane.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  | 15 +--
 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c |  2 +-
 drivers/gpu/drm/i915/intel_dsi_vbt.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 23 ++-
 drivers/gpu/drm/i915/intel_lspcon.c|  4 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c  |  6 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 12 ++--
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  8 
 drivers/gpu/ipu-v3/Kconfig |  1 +
 13 files changed, 69 insertions(+), 24 deletions(-)

[git pull] drm fixes for 4.13-rc7

[Dave Airlie]

Hi Linus,

Fixes for rc7, nothing too crazy, some core, i915, and sunxi fixes,
Intel CI has been responsible for some of these fixes being required.

Dave.

The following changes since commit 14ccee78fc82f5512908f4424f541549a5705b89:

  Linux 4.13-rc6 (2017-08-20 14:13:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc7

for you to fetch changes up to da6119797705c2270f17b287660a1e7bd782a1eb:

  Merge tag 'drm-misc-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-08-25
09:29:38 +1000)


drm fixes for 4.13-rc7, i915, core, imx and sun4i


Andy Shevchenko (1):
  drm/i915/bxt: use NULL for GPIO connection ID

Arnd Bergmann (1):
  gpu: ipu-v3: add DRM dependency

Balasubramaniam, Hari Chand (1):
  drm/i915: Initialize 'data' in intel_dsi_dcs_backlight.c

Chris Wilson (2):
  drm/i915: Clear lost context-switch interrupts across reset
  drm: Release driver tracking before making the object available again

Dave Airlie (5):
  Merge tag 'sunxi-drm-fixes-for-4.13' of
https://git.kernel.org/.../mripard/linux into drm-fixes
  Merge tag 'imx-drm-fixes-2017-08-18' of
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-18' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2017-08-24' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Jani Nikula (2):
  drm/i915/vbt: ignore extraneous child devices for a port
  Merge tag 'gvt-fixes-2017-08-23' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Jeffy Chen (1):
  drm/rockchip: Fix suspend crash when drm is not bound

Jonathan Liu (1):
  drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Maarten Lankhorst (2):
  drm/atomic: Handle -EDEADLK with out-fences correctly
  drm/atomic: If the atomic check fails, return its value first

Nikhil Mahale (1):
  drm: Fix framebuffer leak

Philipp Zabel (1):
  drm/imx: ipuv3-plane: fix YUV framebuffer scanout on the base plane

Rodrigo Vivi (1):
  drm/i915/cnl: Fix LSPCON support.

Sean Paul (1):
  Merge origin/master into drm-misc-fixes

fred gao (1):
  drm/i915/gvt: Fix the kernel null pointer error

 drivers/gpu/drm/drm_atomic.c   | 11 ---
 drivers/gpu/drm/drm_gem.c  |  6 +++---
 drivers/gpu/drm/drm_plane.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  | 15 +--
 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c |  2 +-
 drivers/gpu/drm/i915/intel_dsi_vbt.c   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 23 ++-
 drivers/gpu/drm/i915/intel_lspcon.c|  4 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c  |  6 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 12 ++--
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  8 
 drivers/gpu/ipu-v3/Kconfig |  1 +
 13 files changed, 69 insertions(+), 24 deletions(-)

Re: [PATCH] xfs: Drop setting redundant PF_KSWAPD in kswapd context

[Anshuman Khandual]

On 08/25/2017 05:31 AM, Dave Chinner wrote:
> On Thu, Aug 24, 2017 at 12:56:35PM +0200, Michal Hocko wrote:
>> On Thu 24-08-17 16:12:47, Anshuman Khandual wrote:
>>> xfs_btree_split() calls xfs_btree_split_worker() with args.kswapd set
>>> if current->flags alrady has PF_KSWAPD. Hence we should not again add
>>> PF_KSWAPD into the current flags inside kswapd context. So drop this
>>> redundant flag addition.
>>
>> I am not familiar with the code but your change seems incorect. The
>> whole point of args->kswapd is to convey the kswapd context to the
>> worker which is obviously running in a different context. So this patch
>> loses the kswapd context.
> 
> Yup. That's what the code does, and removing the PF_KSWAPD from it
> will break it.

The worker thread need to inherit these flags. Thanks for pointing out.

Re: [PATCH] xfs: Drop setting redundant PF_KSWAPD in kswapd context

[Anshuman Khandual]

On 08/25/2017 05:31 AM, Dave Chinner wrote:
> On Thu, Aug 24, 2017 at 12:56:35PM +0200, Michal Hocko wrote:
>> On Thu 24-08-17 16:12:47, Anshuman Khandual wrote:
>>> xfs_btree_split() calls xfs_btree_split_worker() with args.kswapd set
>>> if current->flags alrady has PF_KSWAPD. Hence we should not again add
>>> PF_KSWAPD into the current flags inside kswapd context. So drop this
>>> redundant flag addition.
>>
>> I am not familiar with the code but your change seems incorect. The
>> whole point of args->kswapd is to convey the kswapd context to the
>> worker which is obviously running in a different context. So this patch
>> loses the kswapd context.
> 
> Yup. That's what the code does, and removing the PF_KSWAPD from it
> will break it.

The worker thread need to inherit these flags. Thanks for pointing out.

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Florian Fainelli]

On 08/24/2017 08:41 PM, Chen-Yu Tsai wrote:
> On Fri, Aug 25, 2017 at 11:05 AM, Florian Fainelli  
> wrote:
>>
>>
>> On 08/24/2017 07:54 PM, Chen-Yu Tsai wrote:
>>> On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  
>>> wrote:
 On 08/24/2017 01:21 AM, Corentin Labbe wrote:
> On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
>> On 08/23/2017 12:49 AM, Maxime Ripard wrote:
>>> Hi Florian,
>>>
>>> On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
>>> So I think what you are saying is either impossible or 
>>> engineering-wise
>>> a very stupid design, like using an external MAC with a discrete PHY
>>> connected to the internal MAC's MDIO bus, while using the internal 
>>> MAC
>>> with the internal PHY.
>>>
>>> Now can we please decide on something? We're a week and a half from
>>> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
>>> nodes (internal-mdio & external-mdio).
>>
>> I really don't see a need for a mdio-mux in the first place, just 
>> have
>> one MDIO controller (current state) sub-node which describes the
>> built-in STMMAC MDIO controller and declare the internal PHY as a 
>> child
>> node (along with 'phy-is-integrated'). If a different configuration 
>> is
>> used, then just put the external PHY as a child node there.
>>
>> If fixed-link is required, the mdio node becomes unused anyway.
>>
>> Works for everyone?
>
> If we put an external PHY with reg=1 as a child of internal MDIO,
> il will be merged with internal PHY node and get
> phy-is-integrated.

 Then have the .dtsi file contain just the mdio node, but no internal or
 external PHY and push all the internal and external PHY node definition
 (in its entirety) to the per-board DTS file, does not that work?
>>>
>>> If possible, I'd really like to have the internal PHY in the
>>> DTSI. It's always there in hardware anyway, and duplicating the PHY,
>>> with its clock, reset line, and whatever info we might need in the
>>> future in each and every board DTS that uses it will be very error
>>> prone and we will have the usual bunch of issues that come up with
>>> duplication.
>>
>> OK, then what if you put the internal PHY in the DTSI, mark it with a
>> status = "disabled" property, and have the per-board DTS put a status =
>> "okay" property along with a "phy-is-integrated" boolean property? Would
>> that work?
>
> No, I tested and for example with sun8i-h3-orangepi-plus.dts, the 
> external PHY (ethernet-phy@1) is still merged.

 Is not there is a mistake in the unit address not matching the "reg"
 property, or am I not looking at the right tree?

  {
 ext_rgmii_phy: ethernet-phy@1 {
 compatible = "ethernet-phy-ieee802.3-c22";
 reg = <0>;
 };
 };

 If the PHY is really at MDIO address 0, then it should be
 ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
 merging?
>>>
>>> That is wrong. The board described in the example likely has a Realtek
>>> RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
>>> so it still works, but is the wrong representation.
>>>


> So that adding a 'status = "disabled"' does not bring anything.
>
>>
>> What I really don't think is necessary is:
>>
>> - duplicating the "mdio" controller node for external vs. internal PHY,
>> because this is not accurate, there is just one MDIO controller, but
>> there may be different kinds of MDIO/PHY devices attached
>
> For me, if we want to represent the reality, we need two MDIO:
> - since two PHY at the same address could co-exists
> - since they are isolated so not on the same MDIO bus

 Is that really true? It might be, but from experience with e.g:
 bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
 bus, which is convenient, except when you have an address conflict.
>>>
>>> There's a mux in the hardware: either the internal MDIO+MII lines
>>> from the internal PHY are connected to the MAC, or the external
>>> MDIO+MII lines from the pin controller are connected. I believe
>>> this was already mentioned?
>>
>> There is obviously a mux for the data lines and clock to switch between
>> internal PHY and external PHYs, that does not mean there is one for MDIO
>> and MDC lines, which is what is being suggested to be used here, does
>> the mux also takes care of these lines?
>>
>>>

>
>> - having the STMMAC driver MDIO probing code having to deal with a
>> "mdio" sub-node or an "internal-mdio" sub-node because 

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Florian Fainelli]

On 08/24/2017 08:41 PM, Chen-Yu Tsai wrote:
> On Fri, Aug 25, 2017 at 11:05 AM, Florian Fainelli  
> wrote:
>>
>>
>> On 08/24/2017 07:54 PM, Chen-Yu Tsai wrote:
>>> On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  
>>> wrote:
 On 08/24/2017 01:21 AM, Corentin Labbe wrote:
> On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
>> On 08/23/2017 12:49 AM, Maxime Ripard wrote:
>>> Hi Florian,
>>>
>>> On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
>>> So I think what you are saying is either impossible or 
>>> engineering-wise
>>> a very stupid design, like using an external MAC with a discrete PHY
>>> connected to the internal MAC's MDIO bus, while using the internal 
>>> MAC
>>> with the internal PHY.
>>>
>>> Now can we please decide on something? We're a week and a half from
>>> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
>>> nodes (internal-mdio & external-mdio).
>>
>> I really don't see a need for a mdio-mux in the first place, just 
>> have
>> one MDIO controller (current state) sub-node which describes the
>> built-in STMMAC MDIO controller and declare the internal PHY as a 
>> child
>> node (along with 'phy-is-integrated'). If a different configuration 
>> is
>> used, then just put the external PHY as a child node there.
>>
>> If fixed-link is required, the mdio node becomes unused anyway.
>>
>> Works for everyone?
>
> If we put an external PHY with reg=1 as a child of internal MDIO,
> il will be merged with internal PHY node and get
> phy-is-integrated.

 Then have the .dtsi file contain just the mdio node, but no internal or
 external PHY and push all the internal and external PHY node definition
 (in its entirety) to the per-board DTS file, does not that work?
>>>
>>> If possible, I'd really like to have the internal PHY in the
>>> DTSI. It's always there in hardware anyway, and duplicating the PHY,
>>> with its clock, reset line, and whatever info we might need in the
>>> future in each and every board DTS that uses it will be very error
>>> prone and we will have the usual bunch of issues that come up with
>>> duplication.
>>
>> OK, then what if you put the internal PHY in the DTSI, mark it with a
>> status = "disabled" property, and have the per-board DTS put a status =
>> "okay" property along with a "phy-is-integrated" boolean property? Would
>> that work?
>
> No, I tested and for example with sun8i-h3-orangepi-plus.dts, the 
> external PHY (ethernet-phy@1) is still merged.

 Is not there is a mistake in the unit address not matching the "reg"
 property, or am I not looking at the right tree?

  {
 ext_rgmii_phy: ethernet-phy@1 {
 compatible = "ethernet-phy-ieee802.3-c22";
 reg = <0>;
 };
 };

 If the PHY is really at MDIO address 0, then it should be
 ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
 merging?
>>>
>>> That is wrong. The board described in the example likely has a Realtek
>>> RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
>>> so it still works, but is the wrong representation.
>>>


> So that adding a 'status = "disabled"' does not bring anything.
>
>>
>> What I really don't think is necessary is:
>>
>> - duplicating the "mdio" controller node for external vs. internal PHY,
>> because this is not accurate, there is just one MDIO controller, but
>> there may be different kinds of MDIO/PHY devices attached
>
> For me, if we want to represent the reality, we need two MDIO:
> - since two PHY at the same address could co-exists
> - since they are isolated so not on the same MDIO bus

 Is that really true? It might be, but from experience with e.g:
 bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
 bus, which is convenient, except when you have an address conflict.
>>>
>>> There's a mux in the hardware: either the internal MDIO+MII lines
>>> from the internal PHY are connected to the MAC, or the external
>>> MDIO+MII lines from the pin controller are connected. I believe
>>> this was already mentioned?
>>
>> There is obviously a mux for the data lines and clock to switch between
>> internal PHY and external PHYs, that does not mean there is one for MDIO
>> and MDC lines, which is what is being suggested to be used here, does
>> the mux also takes care of these lines?
>>
>>>

>
>> - having the STMMAC driver MDIO probing code having to deal with a
>> "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
>> and requiring more 

[PATCH net-next v2] e1000e: Be drop monitor friendly

[Florian Fainelli]

e1000_put_txbuf() cleans up the successfully transmitted TX packets,
e1000e_tx_hwtstamp_work() also does the successfully completes the
timestamped TX packets, e1000_clean_rx_ring() cleans up the RX ring and
e1000_remove() cleans up the timestampted packets. None of these
functions should be reporting dropped packets, so make them use
dev_consume_skb_any() to be drop monitor friendly.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 327dfe5bedc0..a90e459c5b8a 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1085,7 +1085,7 @@ static void e1000_put_txbuf(struct e1000_ring *tx_ring,
buffer_info->dma = 0;
}
if (buffer_info->skb) {
-   dev_kfree_skb_any(buffer_info->skb);
+   dev_consume_skb_any(buffer_info->skb);
buffer_info->skb = NULL;
}
buffer_info->time_stamp = 0;
@@ -1199,7 +1199,7 @@ static void e1000e_tx_hwtstamp_work(struct work_struct 
*work)
wmb(); /* force write prior to skb_tstamp_tx */
 
skb_tstamp_tx(skb, );
-   dev_kfree_skb_any(skb);
+   dev_consume_skb_any(skb);
} else if (time_after(jiffies, adapter->tx_hwtstamp_start
  + adapter->tx_timeout_factor * HZ)) {
dev_kfree_skb_any(adapter->tx_hwtstamp_skb);
@@ -1716,7 +1716,7 @@ static void e1000_clean_rx_ring(struct e1000_ring 
*rx_ring)
}
 
if (buffer_info->skb) {
-   dev_kfree_skb(buffer_info->skb);
+   dev_consume_skb_any(buffer_info->skb);
buffer_info->skb = NULL;
}
 
@@ -1734,7 +1734,7 @@ static void e1000_clean_rx_ring(struct e1000_ring 
*rx_ring)
 
/* there also may be some cached data from a chained receive */
if (rx_ring->rx_skb_top) {
-   dev_kfree_skb(rx_ring->rx_skb_top);
+   dev_consume_skb_any(rx_ring->rx_skb_top);
rx_ring->rx_skb_top = NULL;
}
 
@@ -7411,7 +7411,7 @@ static void e1000_remove(struct pci_dev *pdev)
if (adapter->flags & FLAG_HAS_HW_TIMESTAMP) {
cancel_work_sync(>tx_hwtstamp_work);
if (adapter->tx_hwtstamp_skb) {
-   dev_kfree_skb_any(adapter->tx_hwtstamp_skb);
+   dev_consume_skb_any(adapter->tx_hwtstamp_skb);
adapter->tx_hwtstamp_skb = NULL;
}
}
-- 
2.11.0

[PATCH net-next v2] e1000e: Be drop monitor friendly

[Florian Fainelli]

e1000_put_txbuf() cleans up the successfully transmitted TX packets,
e1000e_tx_hwtstamp_work() also does the successfully completes the
timestamped TX packets, e1000_clean_rx_ring() cleans up the RX ring and
e1000_remove() cleans up the timestampted packets. None of these
functions should be reporting dropped packets, so make them use
dev_consume_skb_any() to be drop monitor friendly.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 327dfe5bedc0..a90e459c5b8a 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1085,7 +1085,7 @@ static void e1000_put_txbuf(struct e1000_ring *tx_ring,
buffer_info->dma = 0;
}
if (buffer_info->skb) {
-   dev_kfree_skb_any(buffer_info->skb);
+   dev_consume_skb_any(buffer_info->skb);
buffer_info->skb = NULL;
}
buffer_info->time_stamp = 0;
@@ -1199,7 +1199,7 @@ static void e1000e_tx_hwtstamp_work(struct work_struct 
*work)
wmb(); /* force write prior to skb_tstamp_tx */
 
skb_tstamp_tx(skb, );
-   dev_kfree_skb_any(skb);
+   dev_consume_skb_any(skb);
} else if (time_after(jiffies, adapter->tx_hwtstamp_start
  + adapter->tx_timeout_factor * HZ)) {
dev_kfree_skb_any(adapter->tx_hwtstamp_skb);
@@ -1716,7 +1716,7 @@ static void e1000_clean_rx_ring(struct e1000_ring 
*rx_ring)
}
 
if (buffer_info->skb) {
-   dev_kfree_skb(buffer_info->skb);
+   dev_consume_skb_any(buffer_info->skb);
buffer_info->skb = NULL;
}
 
@@ -1734,7 +1734,7 @@ static void e1000_clean_rx_ring(struct e1000_ring 
*rx_ring)
 
/* there also may be some cached data from a chained receive */
if (rx_ring->rx_skb_top) {
-   dev_kfree_skb(rx_ring->rx_skb_top);
+   dev_consume_skb_any(rx_ring->rx_skb_top);
rx_ring->rx_skb_top = NULL;
}
 
@@ -7411,7 +7411,7 @@ static void e1000_remove(struct pci_dev *pdev)
if (adapter->flags & FLAG_HAS_HW_TIMESTAMP) {
cancel_work_sync(>tx_hwtstamp_work);
if (adapter->tx_hwtstamp_skb) {
-   dev_kfree_skb_any(adapter->tx_hwtstamp_skb);
+   dev_consume_skb_any(adapter->tx_hwtstamp_skb);
adapter->tx_hwtstamp_skb = NULL;
}
}
-- 
2.11.0

[PATCH net-next v2] net: mv643xx_eth: Be drop monitor friendly

[Florian Fainelli]

txq_reclaim() does the normal transmit queue reclamation and
rxq_deinit() does the RX ring cleanup, none of these are packet drops,
so use dev_consume_skb() for both locations.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/marvell/mv643xx_eth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index fb2d533ae4ef..81c1fac00d33 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -1121,7 +1121,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, 
int force)
struct sk_buff *skb = __skb_dequeue(>tx_skb);
 
if (!WARN_ON(!skb))
-   dev_kfree_skb(skb);
+   dev_consume_skb_any(skb);
}
 
if (cmd_sts & ERROR_SUMMARY) {
@@ -2024,7 +2024,7 @@ static void rxq_deinit(struct rx_queue *rxq)
 
for (i = 0; i < rxq->rx_ring_size; i++) {
if (rxq->rx_skb[i]) {
-   dev_kfree_skb(rxq->rx_skb[i]);
+   dev_consume_skb_any(rxq->rx_skb[i]);
rxq->rx_desc_count--;
}
}
-- 
2.11.0

[PATCH net-next v2] net: mv643xx_eth: Be drop monitor friendly

[Florian Fainelli]

txq_reclaim() does the normal transmit queue reclamation and
rxq_deinit() does the RX ring cleanup, none of these are packet drops,
so use dev_consume_skb() for both locations.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/marvell/mv643xx_eth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index fb2d533ae4ef..81c1fac00d33 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -1121,7 +1121,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, 
int force)
struct sk_buff *skb = __skb_dequeue(>tx_skb);
 
if (!WARN_ON(!skb))
-   dev_kfree_skb(skb);
+   dev_consume_skb_any(skb);
}
 
if (cmd_sts & ERROR_SUMMARY) {
@@ -2024,7 +2024,7 @@ static void rxq_deinit(struct rx_queue *rxq)
 
for (i = 0; i < rxq->rx_ring_size; i++) {
if (rxq->rx_skb[i]) {
-   dev_kfree_skb(rxq->rx_skb[i]);
+   dev_consume_skb_any(rxq->rx_skb[i]);
rxq->rx_desc_count--;
}
}
-- 
2.11.0

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Chen-Yu Tsai]

On Fri, Aug 25, 2017 at 11:05 AM, Florian Fainelli  wrote:
>
>
> On 08/24/2017 07:54 PM, Chen-Yu Tsai wrote:
>> On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  
>> wrote:
>>> On 08/24/2017 01:21 AM, Corentin Labbe wrote:
 On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
> On 08/23/2017 12:49 AM, Maxime Ripard wrote:
>> Hi Florian,
>>
>> On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
>> So I think what you are saying is either impossible or 
>> engineering-wise
>> a very stupid design, like using an external MAC with a discrete PHY
>> connected to the internal MAC's MDIO bus, while using the internal 
>> MAC
>> with the internal PHY.
>>
>> Now can we please decide on something? We're a week and a half from
>> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
>> nodes (internal-mdio & external-mdio).
>
> I really don't see a need for a mdio-mux in the first place, just have
> one MDIO controller (current state) sub-node which describes the
> built-in STMMAC MDIO controller and declare the internal PHY as a 
> child
> node (along with 'phy-is-integrated'). If a different configuration is
> used, then just put the external PHY as a child node there.
>
> If fixed-link is required, the mdio node becomes unused anyway.
>
> Works for everyone?

 If we put an external PHY with reg=1 as a child of internal MDIO,
 il will be merged with internal PHY node and get
 phy-is-integrated.
>>>
>>> Then have the .dtsi file contain just the mdio node, but no internal or
>>> external PHY and push all the internal and external PHY node definition
>>> (in its entirety) to the per-board DTS file, does not that work?
>>
>> If possible, I'd really like to have the internal PHY in the
>> DTSI. It's always there in hardware anyway, and duplicating the PHY,
>> with its clock, reset line, and whatever info we might need in the
>> future in each and every board DTS that uses it will be very error
>> prone and we will have the usual bunch of issues that come up with
>> duplication.
>
> OK, then what if you put the internal PHY in the DTSI, mark it with a
> status = "disabled" property, and have the per-board DTS put a status =
> "okay" property along with a "phy-is-integrated" boolean property? Would
> that work?

 No, I tested and for example with sun8i-h3-orangepi-plus.dts, the external 
 PHY (ethernet-phy@1) is still merged.
>>>
>>> Is not there is a mistake in the unit address not matching the "reg"
>>> property, or am I not looking at the right tree?
>>>
>>>  {
>>> ext_rgmii_phy: ethernet-phy@1 {
>>> compatible = "ethernet-phy-ieee802.3-c22";
>>> reg = <0>;
>>> };
>>> };
>>>
>>> If the PHY is really at MDIO address 0, then it should be
>>> ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
>>> merging?
>>
>> That is wrong. The board described in the example likely has a Realtek
>> RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
>> so it still works, but is the wrong representation.
>>
>>>
>>>
 So that adding a 'status = "disabled"' does not bring anything.

>
> What I really don't think is necessary is:
>
> - duplicating the "mdio" controller node for external vs. internal PHY,
> because this is not accurate, there is just one MDIO controller, but
> there may be different kinds of MDIO/PHY devices attached

 For me, if we want to represent the reality, we need two MDIO:
 - since two PHY at the same address could co-exists
 - since they are isolated so not on the same MDIO bus
>>>
>>> Is that really true? It might be, but from experience with e.g:
>>> bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
>>> bus, which is convenient, except when you have an address conflict.
>>
>> There's a mux in the hardware: either the internal MDIO+MII lines
>> from the internal PHY are connected to the MAC, or the external
>> MDIO+MII lines from the pin controller are connected. I believe
>> this was already mentioned?
>
> There is obviously a mux for the data lines and clock to switch between
> internal PHY and external PHYs, that does not mean there is one for MDIO
> and MDC lines, which is what is being suggested to be used here, does
> the mux also takes care of these lines?
>
>>
>>>

> - having the STMMAC driver MDIO probing code having to deal with a
> "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
> and requiring more driver-level changes that are error prone

 My patch for stmmac is really small, only the name of my variable 
 

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Chen-Yu Tsai]

On Fri, Aug 25, 2017 at 11:05 AM, Florian Fainelli  wrote:
>
>
> On 08/24/2017 07:54 PM, Chen-Yu Tsai wrote:
>> On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  
>> wrote:
>>> On 08/24/2017 01:21 AM, Corentin Labbe wrote:
 On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
> On 08/23/2017 12:49 AM, Maxime Ripard wrote:
>> Hi Florian,
>>
>> On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
>> So I think what you are saying is either impossible or 
>> engineering-wise
>> a very stupid design, like using an external MAC with a discrete PHY
>> connected to the internal MAC's MDIO bus, while using the internal 
>> MAC
>> with the internal PHY.
>>
>> Now can we please decide on something? We're a week and a half from
>> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
>> nodes (internal-mdio & external-mdio).
>
> I really don't see a need for a mdio-mux in the first place, just have
> one MDIO controller (current state) sub-node which describes the
> built-in STMMAC MDIO controller and declare the internal PHY as a 
> child
> node (along with 'phy-is-integrated'). If a different configuration is
> used, then just put the external PHY as a child node there.
>
> If fixed-link is required, the mdio node becomes unused anyway.
>
> Works for everyone?

 If we put an external PHY with reg=1 as a child of internal MDIO,
 il will be merged with internal PHY node and get
 phy-is-integrated.
>>>
>>> Then have the .dtsi file contain just the mdio node, but no internal or
>>> external PHY and push all the internal and external PHY node definition
>>> (in its entirety) to the per-board DTS file, does not that work?
>>
>> If possible, I'd really like to have the internal PHY in the
>> DTSI. It's always there in hardware anyway, and duplicating the PHY,
>> with its clock, reset line, and whatever info we might need in the
>> future in each and every board DTS that uses it will be very error
>> prone and we will have the usual bunch of issues that come up with
>> duplication.
>
> OK, then what if you put the internal PHY in the DTSI, mark it with a
> status = "disabled" property, and have the per-board DTS put a status =
> "okay" property along with a "phy-is-integrated" boolean property? Would
> that work?

 No, I tested and for example with sun8i-h3-orangepi-plus.dts, the external 
 PHY (ethernet-phy@1) is still merged.
>>>
>>> Is not there is a mistake in the unit address not matching the "reg"
>>> property, or am I not looking at the right tree?
>>>
>>>  {
>>> ext_rgmii_phy: ethernet-phy@1 {
>>> compatible = "ethernet-phy-ieee802.3-c22";
>>> reg = <0>;
>>> };
>>> };
>>>
>>> If the PHY is really at MDIO address 0, then it should be
>>> ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
>>> merging?
>>
>> That is wrong. The board described in the example likely has a Realtek
>> RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
>> so it still works, but is the wrong representation.
>>
>>>
>>>
 So that adding a 'status = "disabled"' does not bring anything.

>
> What I really don't think is necessary is:
>
> - duplicating the "mdio" controller node for external vs. internal PHY,
> because this is not accurate, there is just one MDIO controller, but
> there may be different kinds of MDIO/PHY devices attached

 For me, if we want to represent the reality, we need two MDIO:
 - since two PHY at the same address could co-exists
 - since they are isolated so not on the same MDIO bus
>>>
>>> Is that really true? It might be, but from experience with e.g:
>>> bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
>>> bus, which is convenient, except when you have an address conflict.
>>
>> There's a mux in the hardware: either the internal MDIO+MII lines
>> from the internal PHY are connected to the MAC, or the external
>> MDIO+MII lines from the pin controller are connected. I believe
>> this was already mentioned?
>
> There is obviously a mux for the data lines and clock to switch between
> internal PHY and external PHYs, that does not mean there is one for MDIO
> and MDC lines, which is what is being suggested to be used here, does
> the mux also takes care of these lines?
>
>>
>>>

> - having the STMMAC driver MDIO probing code having to deal with a
> "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
> and requiring more driver-level changes that are error prone

 My patch for stmmac is really small, only the name of my variable 
 ("need_mdio_mux_ids")
 have to be changed to something 

Re: [PATCH v7 04/12] powerpc/vas: Define helpers to access MMIO regions

[Michael Ellerman]

Hi Suka,

Comments inline.

Sukadev Bhattiprolu  writes:
> diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
> b/arch/powerpc/platforms/powernv/vas-window.c
> index 6156fbe..a3a705a 100644
> --- a/arch/powerpc/platforms/powernv/vas-window.c
> +++ b/arch/powerpc/platforms/powernv/vas-window.c
> @@ -9,9 +9,182 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "vas.h"
>  
> +/*
> + * Compute the paste address region for the window @window using the
> + * ->paste_base_addr and ->paste_win_id_shift we got from device tree.
> + */
> +void compute_paste_address(struct vas_window *window, uint64_t *addr, int 
> *len)
> +{
> + uint64_t base, shift;

Please use the kernel types, so u64 here.

> + int winid;
> +
> + base = window->vinst->paste_base_addr;
> + shift = window->vinst->paste_win_id_shift;
> + winid = window->winid;
> +
> + *addr  = base + (winid << shift);
> + if (len)
> + *len = PAGE_SIZE;

Having multiple output parameters makes for a pretty awkward API. Is it
really necesssary given len is a constant PAGE_SIZE anyway.

If you didn't return len, then you could just make the function return
the addr, and you wouldn't need any output parameters.

One of the callers that passes len is unmap_paste_region(), but that
is a bit odd. It would be more natural I think if once a window is
mapped it knows its size. Or if the mapping will always just be one page
then we can just know that.

> +
> + pr_debug("Txwin #%d: Paste addr 0x%llx\n", winid, *addr);
> +}
> +
> +static inline void get_hvwc_mmio_bar(struct vas_window *window,
> + uint64_t *start, int *len)
> +{
> + uint64_t pbaddr;
> +
> + pbaddr = window->vinst->hvwc_bar_start;
> + *start = pbaddr + window->winid * VAS_HVWC_SIZE;
> + *len = VAS_HVWC_SIZE;

This is:

#define VAS_HVWC_SIZE   512

But then we map it, which will round up to a page anyway. So again I
don't see the point of having the len returned form this helper.

> +}
> +
> +static inline void get_uwc_mmio_bar(struct vas_window *window,
> + uint64_t *start, int *len)
> +{
> + uint64_t pbaddr;
> +
> + pbaddr = window->vinst->uwc_bar_start;
> + *start = pbaddr + window->winid * VAS_UWC_SIZE;
> + *len = VAS_UWC_SIZE;
> +}
> +
> +/*
> + * Map the paste bus address of the given send window into kernel address
> + * space. Unlike MMIO regions (map_mmio_region() below), paste region must
> + * be mapped cache-able and is only applicable to send windows.
> + */
> +void *map_paste_region(struct vas_window *txwin)
> +{
> + int rc, len;
> + void *map;
> + char *name;
> + uint64_t start;
> +
> + rc = -ENOMEM;

You don't need that.

> + name = kasprintf(GFP_KERNEL, "window-v%d-w%d", txwin->vinst->vas_id,
> + txwin->winid);
> + if (!name)
> + return ERR_PTR(rc);

That can goto free_name;

> +
> + txwin->paste_addr_name = name;
> + compute_paste_address(txwin, , );
> +
> + if (!request_mem_region(start, len, name)) {
> + pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n",
> + __func__, start, len);
> + goto free_name;
> + }
> +
> + map = ioremap_cache(start, len);
> + if (!map) {
> + pr_devel("%s(): ioremap_cache(0x%llx, %d) failed\n", __func__,
> + start, len);
> + goto free_name;
> + }
> +
> + pr_devel("VAS: mapped paste addr 0x%llx to kaddr 0x%p\n", start, map);
> + return map;
> +
> +free_name:
> + kfree(name);

Because kfree(NULL) is fine.

> + return ERR_PTR(rc);

And that can just return ERR_PTR(-ENOMEM);

> +}

cheers

Re: [PATCH v7 04/12] powerpc/vas: Define helpers to access MMIO regions

[Michael Ellerman]

Hi Suka,

Comments inline.

Sukadev Bhattiprolu  writes:
> diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
> b/arch/powerpc/platforms/powernv/vas-window.c
> index 6156fbe..a3a705a 100644
> --- a/arch/powerpc/platforms/powernv/vas-window.c
> +++ b/arch/powerpc/platforms/powernv/vas-window.c
> @@ -9,9 +9,182 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "vas.h"
>  
> +/*
> + * Compute the paste address region for the window @window using the
> + * ->paste_base_addr and ->paste_win_id_shift we got from device tree.
> + */
> +void compute_paste_address(struct vas_window *window, uint64_t *addr, int 
> *len)
> +{
> + uint64_t base, shift;

Please use the kernel types, so u64 here.

> + int winid;
> +
> + base = window->vinst->paste_base_addr;
> + shift = window->vinst->paste_win_id_shift;
> + winid = window->winid;
> +
> + *addr  = base + (winid << shift);
> + if (len)
> + *len = PAGE_SIZE;

Having multiple output parameters makes for a pretty awkward API. Is it
really necesssary given len is a constant PAGE_SIZE anyway.

If you didn't return len, then you could just make the function return
the addr, and you wouldn't need any output parameters.

One of the callers that passes len is unmap_paste_region(), but that
is a bit odd. It would be more natural I think if once a window is
mapped it knows its size. Or if the mapping will always just be one page
then we can just know that.

> +
> + pr_debug("Txwin #%d: Paste addr 0x%llx\n", winid, *addr);
> +}
> +
> +static inline void get_hvwc_mmio_bar(struct vas_window *window,
> + uint64_t *start, int *len)
> +{
> + uint64_t pbaddr;
> +
> + pbaddr = window->vinst->hvwc_bar_start;
> + *start = pbaddr + window->winid * VAS_HVWC_SIZE;
> + *len = VAS_HVWC_SIZE;

This is:

#define VAS_HVWC_SIZE   512

But then we map it, which will round up to a page anyway. So again I
don't see the point of having the len returned form this helper.

> +}
> +
> +static inline void get_uwc_mmio_bar(struct vas_window *window,
> + uint64_t *start, int *len)
> +{
> + uint64_t pbaddr;
> +
> + pbaddr = window->vinst->uwc_bar_start;
> + *start = pbaddr + window->winid * VAS_UWC_SIZE;
> + *len = VAS_UWC_SIZE;
> +}
> +
> +/*
> + * Map the paste bus address of the given send window into kernel address
> + * space. Unlike MMIO regions (map_mmio_region() below), paste region must
> + * be mapped cache-able and is only applicable to send windows.
> + */
> +void *map_paste_region(struct vas_window *txwin)
> +{
> + int rc, len;
> + void *map;
> + char *name;
> + uint64_t start;
> +
> + rc = -ENOMEM;

You don't need that.

> + name = kasprintf(GFP_KERNEL, "window-v%d-w%d", txwin->vinst->vas_id,
> + txwin->winid);
> + if (!name)
> + return ERR_PTR(rc);

That can goto free_name;

> +
> + txwin->paste_addr_name = name;
> + compute_paste_address(txwin, , );
> +
> + if (!request_mem_region(start, len, name)) {
> + pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n",
> + __func__, start, len);
> + goto free_name;
> + }
> +
> + map = ioremap_cache(start, len);
> + if (!map) {
> + pr_devel("%s(): ioremap_cache(0x%llx, %d) failed\n", __func__,
> + start, len);
> + goto free_name;
> + }
> +
> + pr_devel("VAS: mapped paste addr 0x%llx to kaddr 0x%p\n", start, map);
> + return map;
> +
> +free_name:
> + kfree(name);

Because kfree(NULL) is fine.

> + return ERR_PTR(rc);

And that can just return ERR_PTR(-ENOMEM);

> +}

cheers

[v2] ARM: multi_v7_defconfig: make eSDHC driver built-in

[Yangbo Lu]

Sometimes root file system is deployed on SD card. It's
proper to build eSDHC driver into kernel.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added more reviewers (by get_maintainer.pl).
---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index cb1830bb7ce5..8071d483859c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -712,7 +712,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_OF_ARASAN=y
 CONFIG_MMC_SDHCI_OF_AT91=y
-CONFIG_MMC_SDHCI_OF_ESDHC=m
+CONFIG_MMC_SDHCI_OF_ESDHC=y
 CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_MMC_SDHCI_DOVE=y
 CONFIG_MMC_SDHCI_TEGRA=y
-- 
2.14.1

[v2] ARM: multi_v7_defconfig: make eSDHC driver built-in

[Yangbo Lu]

Sometimes root file system is deployed on SD card. It's
proper to build eSDHC driver into kernel.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Added more reviewers (by get_maintainer.pl).
---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index cb1830bb7ce5..8071d483859c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -712,7 +712,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_OF_ARASAN=y
 CONFIG_MMC_SDHCI_OF_AT91=y
-CONFIG_MMC_SDHCI_OF_ESDHC=m
+CONFIG_MMC_SDHCI_OF_ESDHC=y
 CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_MMC_SDHCI_DOVE=y
 CONFIG_MMC_SDHCI_TEGRA=y
-- 
2.14.1

RE: [PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

[Dexuan Cui]

> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, August 24, 2017 18:20
> > +#define VMBUS_PKT_TRAILER  (sizeof(u64))
>
> This is not the packet trailer, it's the size of the packet trailer.

Thanks! I'll change it to VMBUS_PKT_TRAILER_SIZE.

> > +   /* Have we sent the zero-length packet (FIN)? */
> > +   unsigned long fin_sent;
>
> Why does this need to be atomic?  Why can't a smaller simpler
It doesn't have to be. It was originally made for a quick workaround.
Thanks! I should do it in the right way now.

> mechanism be used to make sure hvs_shutdown() only performs
> hvs_send_data() call once on the channel?
I'll change "fin_sent" to bool, and avoid test_and_set_bit().
I'll add lock_sock/release_sock()  in hvs_shutdown() like this:

static int hvs_shutdown(struct vsock_sock *vsk, int mode)
{
 ...
   lock_sock(sk);

hvs = vsk->trans;
if (hvs->fin_sent)
goto out;

send_buf = (struct hvs_send_buf *)
(void)hvs_send_data(hvs->chan, send_buf, 0);

hvs->fin_sent = true;
out:
release_sock(sk);
return 0;
}

> > +static inline bool is_valid_srv_id(const uuid_le *id)
> > +{
> > +   return !memcmp(>b[4], _id_template.b[4], sizeof(uuid_le) -
> 4);
> > +}
>
> Do not use the inline function attribute in *.c code.  Let the
> compiler decide.

OK. Will remove all the inline usages.

> > +   *((u32 *)>vm_srv_id) = vsk->local_addr.svm_port;
> > +   *((u32 *)>host_srv_id) = vsk->remote_addr.svm_port;
>
> There has to be a better way to express this.
I may need to define a uinon here. Let me try it.

 > And if this is partially initializing vm_srv_id, at a minimum
> endianness needs to be taken into account.
I may need to use cpu_to_le32(). Let me check it.

RE: [PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

[Dexuan Cui]

> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, August 24, 2017 18:20
> > +#define VMBUS_PKT_TRAILER  (sizeof(u64))
>
> This is not the packet trailer, it's the size of the packet trailer.

Thanks! I'll change it to VMBUS_PKT_TRAILER_SIZE.

> > +   /* Have we sent the zero-length packet (FIN)? */
> > +   unsigned long fin_sent;
>
> Why does this need to be atomic?  Why can't a smaller simpler
It doesn't have to be. It was originally made for a quick workaround.
Thanks! I should do it in the right way now.

> mechanism be used to make sure hvs_shutdown() only performs
> hvs_send_data() call once on the channel?
I'll change "fin_sent" to bool, and avoid test_and_set_bit().
I'll add lock_sock/release_sock()  in hvs_shutdown() like this:

static int hvs_shutdown(struct vsock_sock *vsk, int mode)
{
 ...
   lock_sock(sk);

hvs = vsk->trans;
if (hvs->fin_sent)
goto out;

send_buf = (struct hvs_send_buf *)
(void)hvs_send_data(hvs->chan, send_buf, 0);

hvs->fin_sent = true;
out:
release_sock(sk);
return 0;
}

> > +static inline bool is_valid_srv_id(const uuid_le *id)
> > +{
> > +   return !memcmp(>b[4], _id_template.b[4], sizeof(uuid_le) -
> 4);
> > +}
>
> Do not use the inline function attribute in *.c code.  Let the
> compiler decide.

OK. Will remove all the inline usages.

> > +   *((u32 *)>vm_srv_id) = vsk->local_addr.svm_port;
> > +   *((u32 *)>host_srv_id) = vsk->remote_addr.svm_port;
>
> There has to be a better way to express this.
I may need to define a uinon here. Let me try it.

 > And if this is partially initializing vm_srv_id, at a minimum
> endianness needs to be taken into account.
I may need to use cpu_to_le32(). Let me check it.

Re: [PATCH net-next] e1000e: Be drop monitor friendly

[Florian Fainelli]

On 08/24/2017 06:36 PM, Florian Fainelli wrote:
> e1000_put_txbuf() cleans up the successfully transmitted TX packets,
> e1000e_tx_hwtstamp_work() also does the successfully completes the
> timestamped TX packets, e1000_clean_rx_ring() cleans up the RX ring and
> e1000_remove() cleans up the timestampted packets. None of these
> functions should be reporting dropped packets, so make them use
> dev_consume_skb*() to be drop monitor friendly.

This also won't compile, I marked it a Superseded in patchwork since
there is a v2 coming.

-- 
Florian

Re: [PATCH net-next] e1000e: Be drop monitor friendly

[Florian Fainelli]

On 08/24/2017 06:36 PM, Florian Fainelli wrote:
> e1000_put_txbuf() cleans up the successfully transmitted TX packets,
> e1000e_tx_hwtstamp_work() also does the successfully completes the
> timestamped TX packets, e1000_clean_rx_ring() cleans up the RX ring and
> e1000_remove() cleans up the timestampted packets. None of these
> functions should be reporting dropped packets, so make them use
> dev_consume_skb*() to be drop monitor friendly.

This also won't compile, I marked it a Superseded in patchwork since
there is a v2 coming.

-- 
Florian

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Florian Fainelli]

On 08/24/2017 07:54 PM, Chen-Yu Tsai wrote:
> On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  
> wrote:
>> On 08/24/2017 01:21 AM, Corentin Labbe wrote:
>>> On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
 On 08/23/2017 12:49 AM, Maxime Ripard wrote:
> Hi Florian,
>
> On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
> So I think what you are saying is either impossible or 
> engineering-wise
> a very stupid design, like using an external MAC with a discrete PHY
> connected to the internal MAC's MDIO bus, while using the internal MAC
> with the internal PHY.
>
> Now can we please decide on something? We're a week and a half from
> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
> nodes (internal-mdio & external-mdio).

 I really don't see a need for a mdio-mux in the first place, just have
 one MDIO controller (current state) sub-node which describes the
 built-in STMMAC MDIO controller and declare the internal PHY as a child
 node (along with 'phy-is-integrated'). If a different configuration is
 used, then just put the external PHY as a child node there.

 If fixed-link is required, the mdio node becomes unused anyway.

 Works for everyone?
>>>
>>> If we put an external PHY with reg=1 as a child of internal MDIO,
>>> il will be merged with internal PHY node and get
>>> phy-is-integrated.
>>
>> Then have the .dtsi file contain just the mdio node, but no internal or
>> external PHY and push all the internal and external PHY node definition
>> (in its entirety) to the per-board DTS file, does not that work?
>
> If possible, I'd really like to have the internal PHY in the
> DTSI. It's always there in hardware anyway, and duplicating the PHY,
> with its clock, reset line, and whatever info we might need in the
> future in each and every board DTS that uses it will be very error
> prone and we will have the usual bunch of issues that come up with
> duplication.

 OK, then what if you put the internal PHY in the DTSI, mark it with a
 status = "disabled" property, and have the per-board DTS put a status =
 "okay" property along with a "phy-is-integrated" boolean property? Would
 that work?
>>>
>>> No, I tested and for example with sun8i-h3-orangepi-plus.dts, the external 
>>> PHY (ethernet-phy@1) is still merged.
>>
>> Is not there is a mistake in the unit address not matching the "reg"
>> property, or am I not looking at the right tree?
>>
>>  {
>> ext_rgmii_phy: ethernet-phy@1 {
>> compatible = "ethernet-phy-ieee802.3-c22";
>> reg = <0>;
>> };
>> };
>>
>> If the PHY is really at MDIO address 0, then it should be
>> ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
>> merging?
> 
> That is wrong. The board described in the example likely has a Realtek
> RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
> so it still works, but is the wrong representation.
> 
>>
>>
>>> So that adding a 'status = "disabled"' does not bring anything.
>>>

 What I really don't think is necessary is:

 - duplicating the "mdio" controller node for external vs. internal PHY,
 because this is not accurate, there is just one MDIO controller, but
 there may be different kinds of MDIO/PHY devices attached
>>>
>>> For me, if we want to represent the reality, we need two MDIO:
>>> - since two PHY at the same address could co-exists
>>> - since they are isolated so not on the same MDIO bus
>>
>> Is that really true? It might be, but from experience with e.g:
>> bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
>> bus, which is convenient, except when you have an address conflict.
> 
> There's a mux in the hardware: either the internal MDIO+MII lines
> from the internal PHY are connected to the MAC, or the external
> MDIO+MII lines from the pin controller are connected. I believe
> this was already mentioned?

There is obviously a mux for the data lines and clock to switch between
internal PHY and external PHYs, that does not mean there is one for MDIO
and MDC lines, which is what is being suggested to be used here, does
the mux also takes care of these lines?

> 
>>
>>>
 - having the STMMAC driver MDIO probing code having to deal with a
 "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
 and requiring more driver-level changes that are error prone
>>>
>>> My patch for stmmac is really small, only the name of my variable 
>>> ("need_mdio_mux_ids")
>>> have to be changed to something like "register_parent_mdio"
>>>
>>>
>>> So I agree with Maxime, we need to avoid merging PHY nodes, and we can 
>>> avoid it only by having two separate MDIO nodes.
>>> 

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Florian Fainelli]

On 08/24/2017 07:54 PM, Chen-Yu Tsai wrote:
> On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  
> wrote:
>> On 08/24/2017 01:21 AM, Corentin Labbe wrote:
>>> On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
 On 08/23/2017 12:49 AM, Maxime Ripard wrote:
> Hi Florian,
>
> On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
> So I think what you are saying is either impossible or 
> engineering-wise
> a very stupid design, like using an external MAC with a discrete PHY
> connected to the internal MAC's MDIO bus, while using the internal MAC
> with the internal PHY.
>
> Now can we please decide on something? We're a week and a half from
> the 4.13 release. If mdio-mux is wrong, then we could have two mdio
> nodes (internal-mdio & external-mdio).

 I really don't see a need for a mdio-mux in the first place, just have
 one MDIO controller (current state) sub-node which describes the
 built-in STMMAC MDIO controller and declare the internal PHY as a child
 node (along with 'phy-is-integrated'). If a different configuration is
 used, then just put the external PHY as a child node there.

 If fixed-link is required, the mdio node becomes unused anyway.

 Works for everyone?
>>>
>>> If we put an external PHY with reg=1 as a child of internal MDIO,
>>> il will be merged with internal PHY node and get
>>> phy-is-integrated.
>>
>> Then have the .dtsi file contain just the mdio node, but no internal or
>> external PHY and push all the internal and external PHY node definition
>> (in its entirety) to the per-board DTS file, does not that work?
>
> If possible, I'd really like to have the internal PHY in the
> DTSI. It's always there in hardware anyway, and duplicating the PHY,
> with its clock, reset line, and whatever info we might need in the
> future in each and every board DTS that uses it will be very error
> prone and we will have the usual bunch of issues that come up with
> duplication.

 OK, then what if you put the internal PHY in the DTSI, mark it with a
 status = "disabled" property, and have the per-board DTS put a status =
 "okay" property along with a "phy-is-integrated" boolean property? Would
 that work?
>>>
>>> No, I tested and for example with sun8i-h3-orangepi-plus.dts, the external 
>>> PHY (ethernet-phy@1) is still merged.
>>
>> Is not there is a mistake in the unit address not matching the "reg"
>> property, or am I not looking at the right tree?
>>
>>  {
>> ext_rgmii_phy: ethernet-phy@1 {
>> compatible = "ethernet-phy-ieee802.3-c22";
>> reg = <0>;
>> };
>> };
>>
>> If the PHY is really at MDIO address 0, then it should be
>> ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
>> merging?
> 
> That is wrong. The board described in the example likely has a Realtek
> RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
> so it still works, but is the wrong representation.
> 
>>
>>
>>> So that adding a 'status = "disabled"' does not bring anything.
>>>

 What I really don't think is necessary is:

 - duplicating the "mdio" controller node for external vs. internal PHY,
 because this is not accurate, there is just one MDIO controller, but
 there may be different kinds of MDIO/PHY devices attached
>>>
>>> For me, if we want to represent the reality, we need two MDIO:
>>> - since two PHY at the same address could co-exists
>>> - since they are isolated so not on the same MDIO bus
>>
>> Is that really true? It might be, but from experience with e.g:
>> bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
>> bus, which is convenient, except when you have an address conflict.
> 
> There's a mux in the hardware: either the internal MDIO+MII lines
> from the internal PHY are connected to the MAC, or the external
> MDIO+MII lines from the pin controller are connected. I believe
> this was already mentioned?

There is obviously a mux for the data lines and clock to switch between
internal PHY and external PHYs, that does not mean there is one for MDIO
and MDC lines, which is what is being suggested to be used here, does
the mux also takes care of these lines?

> 
>>
>>>
 - having the STMMAC driver MDIO probing code having to deal with a
 "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
 and requiring more driver-level changes that are error prone
>>>
>>> My patch for stmmac is really small, only the name of my variable 
>>> ("need_mdio_mux_ids")
>>> have to be changed to something like "register_parent_mdio"
>>>
>>>
>>> So I agree with Maxime, we need to avoid merging PHY nodes, and we can 
>>> avoid it only by having two separate MDIO nodes.
>>> Furthermore, with only one 

linux-next: manual merge of the sound-asoc tree with the sound-current tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the sound-asoc tree got a conflict in:

  sound/soc/codecs/rt5677.c

between commit:

  9ce76511b67b ("ASoC: rt5677: Reintroduce I2C device IDs")

from the sound-current tree and commit:

  ddc9e69b9dc2 ("ASoC: rt5677: Hide platform data in the module sources")

from the sound-asoc tree.

I considered just using the latter version, but in the end did not.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc sound/soc/codecs/rt5677.c
index 6f629278d982,c735590c5a25..
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@@ -5019,9 -5010,6 +5010,7 @@@ static const struct regmap_config rt567
  };
  
  static const struct i2c_device_id rt5677_i2c_id[] = {
-   { "rt5677", RT5677 },
-   { "rt5676", RT5676 },
 +  { "RT5677CE:00", RT5677 },
{ }
  };
  MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);

linux-next: manual merge of the sound-asoc tree with the sound-current tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the sound-asoc tree got a conflict in:

  sound/soc/codecs/rt5677.c

between commit:

  9ce76511b67b ("ASoC: rt5677: Reintroduce I2C device IDs")

from the sound-current tree and commit:

  ddc9e69b9dc2 ("ASoC: rt5677: Hide platform data in the module sources")

from the sound-asoc tree.

I considered just using the latter version, but in the end did not.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc sound/soc/codecs/rt5677.c
index 6f629278d982,c735590c5a25..
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@@ -5019,9 -5010,6 +5010,7 @@@ static const struct regmap_config rt567
  };
  
  static const struct i2c_device_id rt5677_i2c_id[] = {
-   { "rt5677", RT5677 },
-   { "rt5676", RT5676 },
 +  { "RT5677CE:00", RT5677 },
{ }
  };
  MODULE_DEVICE_TABLE(i2c, rt5677_i2c_id);

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Chen-Yu Tsai]

On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  wrote:
> On 08/24/2017 01:21 AM, Corentin Labbe wrote:
>> On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
>>> On 08/23/2017 12:49 AM, Maxime Ripard wrote:
 Hi Florian,

 On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
 So I think what you are saying is either impossible or engineering-wise
 a very stupid design, like using an external MAC with a discrete PHY
 connected to the internal MAC's MDIO bus, while using the internal MAC
 with the internal PHY.

 Now can we please decide on something? We're a week and a half from
 the 4.13 release. If mdio-mux is wrong, then we could have two mdio
 nodes (internal-mdio & external-mdio).
>>>
>>> I really don't see a need for a mdio-mux in the first place, just have
>>> one MDIO controller (current state) sub-node which describes the
>>> built-in STMMAC MDIO controller and declare the internal PHY as a child
>>> node (along with 'phy-is-integrated'). If a different configuration is
>>> used, then just put the external PHY as a child node there.
>>>
>>> If fixed-link is required, the mdio node becomes unused anyway.
>>>
>>> Works for everyone?
>>
>> If we put an external PHY with reg=1 as a child of internal MDIO,
>> il will be merged with internal PHY node and get
>> phy-is-integrated.
>
> Then have the .dtsi file contain just the mdio node, but no internal or
> external PHY and push all the internal and external PHY node definition
> (in its entirety) to the per-board DTS file, does not that work?

 If possible, I'd really like to have the internal PHY in the
 DTSI. It's always there in hardware anyway, and duplicating the PHY,
 with its clock, reset line, and whatever info we might need in the
 future in each and every board DTS that uses it will be very error
 prone and we will have the usual bunch of issues that come up with
 duplication.
>>>
>>> OK, then what if you put the internal PHY in the DTSI, mark it with a
>>> status = "disabled" property, and have the per-board DTS put a status =
>>> "okay" property along with a "phy-is-integrated" boolean property? Would
>>> that work?
>>
>> No, I tested and for example with sun8i-h3-orangepi-plus.dts, the external 
>> PHY (ethernet-phy@1) is still merged.
>
> Is not there is a mistake in the unit address not matching the "reg"
> property, or am I not looking at the right tree?
>
>  {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <0>;
> };
> };
>
> If the PHY is really at MDIO address 0, then it should be
> ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
> merging?

That is wrong. The board described in the example likely has a Realtek
RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
so it still works, but is the wrong representation.

>
>
>> So that adding a 'status = "disabled"' does not bring anything.
>>
>>>
>>> What I really don't think is necessary is:
>>>
>>> - duplicating the "mdio" controller node for external vs. internal PHY,
>>> because this is not accurate, there is just one MDIO controller, but
>>> there may be different kinds of MDIO/PHY devices attached
>>
>> For me, if we want to represent the reality, we need two MDIO:
>> - since two PHY at the same address could co-exists
>> - since they are isolated so not on the same MDIO bus
>
> Is that really true? It might be, but from experience with e.g:
> bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
> bus, which is convenient, except when you have an address conflict.

There's a mux in the hardware: either the internal MDIO+MII lines
from the internal PHY are connected to the MAC, or the external
MDIO+MII lines from the pin controller are connected. I believe
this was already mentioned?

>
>>
>>> - having the STMMAC driver MDIO probing code having to deal with a
>>> "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
>>> and requiring more driver-level changes that are error prone
>>
>> My patch for stmmac is really small, only the name of my variable 
>> ("need_mdio_mux_ids")
>> have to be changed to something like "register_parent_mdio"
>>
>>
>> So I agree with Maxime, we need to avoid merging PHY nodes, and we can avoid 
>> it only by having two separate MDIO nodes.
>> Furthermore, with only one MDIO, we will face with lots of small patch for 
>> adding phy-is-integrated, with two we do not need to change any board DT, 
>> all is simply clean.
>> Really having two MDIO seems cleaner.
>
> The only valid thing that you have provided so far is this merging
> problem. Anything else ranging from "we will face with lots of small
> patch for adding phy-is-integrated" to "Really having two MDIO seems
> 

Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac

[Chen-Yu Tsai]

On Fri, Aug 25, 2017 at 3:59 AM, Florian Fainelli  wrote:
> On 08/24/2017 01:21 AM, Corentin Labbe wrote:
>> On Wed, Aug 23, 2017 at 09:31:53AM -0700, Florian Fainelli wrote:
>>> On 08/23/2017 12:49 AM, Maxime Ripard wrote:
 Hi Florian,

 On Tue, Aug 22, 2017 at 11:35:01AM -0700, Florian Fainelli wrote:
 So I think what you are saying is either impossible or engineering-wise
 a very stupid design, like using an external MAC with a discrete PHY
 connected to the internal MAC's MDIO bus, while using the internal MAC
 with the internal PHY.

 Now can we please decide on something? We're a week and a half from
 the 4.13 release. If mdio-mux is wrong, then we could have two mdio
 nodes (internal-mdio & external-mdio).
>>>
>>> I really don't see a need for a mdio-mux in the first place, just have
>>> one MDIO controller (current state) sub-node which describes the
>>> built-in STMMAC MDIO controller and declare the internal PHY as a child
>>> node (along with 'phy-is-integrated'). If a different configuration is
>>> used, then just put the external PHY as a child node there.
>>>
>>> If fixed-link is required, the mdio node becomes unused anyway.
>>>
>>> Works for everyone?
>>
>> If we put an external PHY with reg=1 as a child of internal MDIO,
>> il will be merged with internal PHY node and get
>> phy-is-integrated.
>
> Then have the .dtsi file contain just the mdio node, but no internal or
> external PHY and push all the internal and external PHY node definition
> (in its entirety) to the per-board DTS file, does not that work?

 If possible, I'd really like to have the internal PHY in the
 DTSI. It's always there in hardware anyway, and duplicating the PHY,
 with its clock, reset line, and whatever info we might need in the
 future in each and every board DTS that uses it will be very error
 prone and we will have the usual bunch of issues that come up with
 duplication.
>>>
>>> OK, then what if you put the internal PHY in the DTSI, mark it with a
>>> status = "disabled" property, and have the per-board DTS put a status =
>>> "okay" property along with a "phy-is-integrated" boolean property? Would
>>> that work?
>>
>> No, I tested and for example with sun8i-h3-orangepi-plus.dts, the external 
>> PHY (ethernet-phy@1) is still merged.
>
> Is not there is a mistake in the unit address not matching the "reg"
> property, or am I not looking at the right tree?
>
>  {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <0>;
> };
> };
>
> If the PHY is really at MDIO address 0, then it should be
> ethernet-phy@0, and not ethernet-phy@1, and then no problem with the
> merging?

That is wrong. The board described in the example likely has a Realtek
RTL8211E @ address 0x1. Address 0 for this PHY is a broadcast address,
so it still works, but is the wrong representation.

>
>
>> So that adding a 'status = "disabled"' does not bring anything.
>>
>>>
>>> What I really don't think is necessary is:
>>>
>>> - duplicating the "mdio" controller node for external vs. internal PHY,
>>> because this is not accurate, there is just one MDIO controller, but
>>> there may be different kinds of MDIO/PHY devices attached
>>
>> For me, if we want to represent the reality, we need two MDIO:
>> - since two PHY at the same address could co-exists
>> - since they are isolated so not on the same MDIO bus
>
> Is that really true? It might be, but from experience with e.g:
> bcmgenet, the integrated PHY and the external PHYs are on the same MDIO
> bus, which is convenient, except when you have an address conflict.

There's a mux in the hardware: either the internal MDIO+MII lines
from the internal PHY are connected to the MAC, or the external
MDIO+MII lines from the pin controller are connected. I believe
this was already mentioned?

>
>>
>>> - having the STMMAC driver MDIO probing code having to deal with a
>>> "mdio" sub-node or an "internal-mdio" sub-node because this is confusing
>>> and requiring more driver-level changes that are error prone
>>
>> My patch for stmmac is really small, only the name of my variable 
>> ("need_mdio_mux_ids")
>> have to be changed to something like "register_parent_mdio"
>>
>>
>> So I agree with Maxime, we need to avoid merging PHY nodes, and we can avoid 
>> it only by having two separate MDIO nodes.
>> Furthermore, with only one MDIO, we will face with lots of small patch for 
>> adding phy-is-integrated, with two we do not need to change any board DT, 
>> all is simply clean.
>> Really having two MDIO seems cleaner.
>
> The only valid thing that you have provided so far is this merging
> problem. Anything else ranging from "we will face with lots of small
> patch for adding phy-is-integrated" to "Really having two MDIO seems
> cleaner." are hard to 

Re: [PATCH] zram: add zstd to the supported algorithms list

[Nick Terrell]

On 8/24/17, 7:21 PM, "Sergey Senozhatsky"  
wrote:
> not really familiar either... I was thinking about having "zstd" and
> "zstd_dict" crypto_alg structs - one would be !dict, the other one would
> allocate dict and pass it to compress/decompress zstd callbacks. "zstd"
> vecrsion would invoke zstd_params() passing zeros as compress and dict
> sizes to ZSTD_getParams(), while "zstd_dict" would invoke, lets say,
> zstd_params_dict() passing PAGE_SIZE-s. hm... (0, PAGE_SIZE)?  to
> ZSTD_getParams(). just a rough idea...

The way zstd dictionaries work is the user provides some data which gets
"prepended" to the data that is about to be compressed, without actually
writing it to output. That way zstd can find matches in the dictionary and
represent them for "free". That means the user has to pass the same data to
both the compressor and decompressor.

We could build a dictionary, say every 20 minutes, by sampling 512 B chunks
of the RAM and constructing a 16 KB dictionary. Then recompress all the
compressed RAM with the new dictionary. This is just a simple example of a
dictionary construction algorithm. You could imagine grouping pages by
application, and building a dictionary per application, since those pages
would likely be more similar.

Regarding the crypto API, I think it would be possible to experiment by
creating functions like
`zstd_comp_add_dictionary(void *ctx, void *data, size_t size)'
and `zstd_decomp_add_dictionary(void *ctx, void *data, size_t size)'
in the crypto zstd implementation and declare them in `zcomp.c'. If the
experiments prove that using zstd dictionaries (or LZ4 dictionaries) is
worthwhile, then we can figure out how we can make it work for real.

Re: [PATCH] zram: add zstd to the supported algorithms list

[Nick Terrell]

On 8/24/17, 7:21 PM, "Sergey Senozhatsky"  
wrote:
> not really familiar either... I was thinking about having "zstd" and
> "zstd_dict" crypto_alg structs - one would be !dict, the other one would
> allocate dict and pass it to compress/decompress zstd callbacks. "zstd"
> vecrsion would invoke zstd_params() passing zeros as compress and dict
> sizes to ZSTD_getParams(), while "zstd_dict" would invoke, lets say,
> zstd_params_dict() passing PAGE_SIZE-s. hm... (0, PAGE_SIZE)?  to
> ZSTD_getParams(). just a rough idea...

The way zstd dictionaries work is the user provides some data which gets
"prepended" to the data that is about to be compressed, without actually
writing it to output. That way zstd can find matches in the dictionary and
represent them for "free". That means the user has to pass the same data to
both the compressor and decompressor.

We could build a dictionary, say every 20 minutes, by sampling 512 B chunks
of the RAM and constructing a 16 KB dictionary. Then recompress all the
compressed RAM with the new dictionary. This is just a simple example of a
dictionary construction algorithm. You could imagine grouping pages by
application, and building a dictionary per application, since those pages
would likely be more similar.

Regarding the crypto API, I think it would be possible to experiment by
creating functions like
`zstd_comp_add_dictionary(void *ctx, void *data, size_t size)'
and `zstd_decomp_add_dictionary(void *ctx, void *data, size_t size)'
in the crypto zstd implementation and declare them in `zcomp.c'. If the
experiments prove that using zstd dictionaries (or LZ4 dictionaries) is
worthwhile, then we can figure out how we can make it work for real.

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

[Sai Praneeth Prakhya]

On Tue, 2017-08-15 at 14:46 -0700, Andy Lutomirski wrote:
> On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya
>  wrote:
> > +/*
> > + * Makes the calling kernel thread switch to/from efi_mm context
> > + * Can be used from SetVirtualAddressMap() or during efi runtime calls
> > + * (Note: This routine is heavily inspired from use_mm)
> > + */
> > +void efi_switch_mm(struct mm_struct *mm)
> > +{
> > +   struct task_struct *tsk = current;
> > +
> > +   task_lock(tsk);
> > +   efi_scratch.prev_mm = tsk->active_mm;
> > +   if (efi_scratch.prev_mm != mm) {
> > +   mmgrab(mm);
> > +   tsk->active_mm = mm;
> > +   }
> > +   switch_mm(efi_scratch.prev_mm, mm, NULL);
> > +   task_unlock(tsk);
> > +
> > +   if (efi_scratch.prev_mm != mm)
> > +   mmdrop(efi_scratch.prev_mm);
> 
> I'm confused.  You're mmdropping an mm that you are still keeping a
> pointer to.  This is also a bit confusing in the case where you do
> efi_switch_mm(efi_scratch.prev_mm).
> 
> This whole manipulation seems fairly dangerous to me for another
> reason -- you're taking a user thread (I think) and swapping out its
> mm to something that the user in question should *not* have access to.
> What if a perf interrupt happens while you're in the alternate mm?
> What if you segfault and dump core?  Should we maybe just have a flag
> that says "this cpu is using a funny mm", assert that the flag is
> clear when scheduling, and teach perf, coredumps, etc not to touch
> user memory when the flag is set?
> 
> Admittedly, the latter problem may well have existed even before these 
> patches.

Hi All,

Could we please decouple the above issue from this patch set, so that we
could have common efi_mm between x86 and ARM and also improve
readability and maintainability for x86/efi.

As it seems that "Everything EFI as kthread" might solve the above issue
for real (which might take quite some time to implement, taking into
consideration the complexity involved and some special case with
pstore), do you think this patch set seems OK?

If so, I will send out a V2 addressing the mmdropping issue.

Regards,
Sai

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

[Sai Praneeth Prakhya]

On Tue, 2017-08-15 at 14:46 -0700, Andy Lutomirski wrote:
> On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya
>  wrote:
> > +/*
> > + * Makes the calling kernel thread switch to/from efi_mm context
> > + * Can be used from SetVirtualAddressMap() or during efi runtime calls
> > + * (Note: This routine is heavily inspired from use_mm)
> > + */
> > +void efi_switch_mm(struct mm_struct *mm)
> > +{
> > +   struct task_struct *tsk = current;
> > +
> > +   task_lock(tsk);
> > +   efi_scratch.prev_mm = tsk->active_mm;
> > +   if (efi_scratch.prev_mm != mm) {
> > +   mmgrab(mm);
> > +   tsk->active_mm = mm;
> > +   }
> > +   switch_mm(efi_scratch.prev_mm, mm, NULL);
> > +   task_unlock(tsk);
> > +
> > +   if (efi_scratch.prev_mm != mm)
> > +   mmdrop(efi_scratch.prev_mm);
> 
> I'm confused.  You're mmdropping an mm that you are still keeping a
> pointer to.  This is also a bit confusing in the case where you do
> efi_switch_mm(efi_scratch.prev_mm).
> 
> This whole manipulation seems fairly dangerous to me for another
> reason -- you're taking a user thread (I think) and swapping out its
> mm to something that the user in question should *not* have access to.
> What if a perf interrupt happens while you're in the alternate mm?
> What if you segfault and dump core?  Should we maybe just have a flag
> that says "this cpu is using a funny mm", assert that the flag is
> clear when scheduling, and teach perf, coredumps, etc not to touch
> user memory when the flag is set?
> 
> Admittedly, the latter problem may well have existed even before these 
> patches.

Hi All,

Could we please decouple the above issue from this patch set, so that we
could have common efi_mm between x86 and ARM and also improve
readability and maintainability for x86/efi.

As it seems that "Everything EFI as kthread" might solve the above issue
for real (which might take quite some time to implement, taking into
consideration the complexity involved and some special case with
pstore), do you think this patch set seems OK?

If so, I will send out a V2 addressing the mmdropping issue.

Regards,
Sai

Re: linux-next: Signed-off-by missing for commit in the nfsd tree

[J. Bruce Fields]

On Thu, Aug 24, 2017 at 10:21:41PM -0400, J. Bruce Fields wrote:
> On Fri, Aug 25, 2017 at 08:48:21AM +1000, Stephen Rothwell wrote:
> > Hi Bruce,
> > 
> > Commit
> > 
> >   1b7f1a85c0fa ("opdesc will be useful outside nfs4proc.c")
> > 
> > is missing a Signed-off-by from its author and committer.
> 
> Fixed, thanks.--b.

And, sorry, somehow I lost your other message, but: the compiler errors
should also have been fixed.  (As should be the testing error that let
them slip through--I thought I had CONFIG_NFSD_PNFS turned on in my
testing, but I didn't.)

--b.

Re: linux-next: Signed-off-by missing for commit in the nfsd tree

[J. Bruce Fields]

On Thu, Aug 24, 2017 at 10:21:41PM -0400, J. Bruce Fields wrote:
> On Fri, Aug 25, 2017 at 08:48:21AM +1000, Stephen Rothwell wrote:
> > Hi Bruce,
> > 
> > Commit
> > 
> >   1b7f1a85c0fa ("opdesc will be useful outside nfs4proc.c")
> > 
> > is missing a Signed-off-by from its author and committer.
> 
> Fixed, thanks.--b.

And, sorry, somehow I lost your other message, but: the compiler errors
should also have been fixed.  (As should be the testing error that let
them slip through--I thought I had CONFIG_NFSD_PNFS turned on in my
testing, but I didn't.)

--b.

Re: [PATCH v4 3/4] dt-bindings: PCI: rockchip: Add support for pcie wake irq

[Shawn Lin]

On 2017/8/25 10:11, Brian Norris wrote:

On Thu, Aug 24, 2017 at 11:53:54AM -0500, Bjorn Helgaas wrote:

On Tue, Aug 22, 2017 at 11:19:33AM +0800, Jeffy Chen wrote:

Signed-off-by: Jeffy Chen 



diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index 5678be82530d..9f6504129e80 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -20,10 +20,13 @@ Required properties:
  - msi-map: Maps a Requester ID to an MSI controller and associated
msi-specifier data. See ./pci-msi.txt
  - interrupts: Three interrupt entries must be specified.
-- interrupt-names: Must include the following names
-   - "sys"
-   - "legacy"
-   - "client"
+- interrupt-names: Include the following names
+   Required:
+   - "sys"
+   - "legacy"
+   - "client"
+   Optional:
+   - "wake"


Why is there no other PCI binding that includes "wake" as an
interrupt-name?  This feels like something that should be fairly
common across host controllers.  I don't want a Rockport-specific


s/port/chip/ :)


DT description if it could be made more general.


I'm not sure we can really answer that question ("why do no other PCI
bindings have this?"). But one guess would be that every other
controller uses only beacon wake.

It would be OK with me if we made a blanket statement that a controller
with a "wake" interrupt means PCI WAKE# (per the specification). It's
possible this could even be stuck into some generic PCI/DT code
eventually. (I don't think we have a really good place for this today.)


I guess we could register a pcie port service for dedicated WAKE# as it 
seems fairly parallel to pme code there, if we need a common place for

that?




Brian


  - resets: Must contain seven entries for each entry in reset-names.
   See ../reset/reset.txt for details.
  - reset-names: Must include the following names
@@ -87,10 +90,11 @@ pcie0: pcie@f800 {
clock-names = "aclk", "aclk-perf",
  "hclk", "pm";
bus-range = <0x0 0x1>;
-   interrupts = ,
-,
-;
-   interrupt-names = "sys", "legacy", "client";
+   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+ < 8 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "sys", "legacy", "client", "wake";
assigned-clocks = < SCLK_PCIEPHY_REF>;
assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
assigned-clock-rates = <1>;
--
2.11.0

Re: [PATCH v4 3/4] dt-bindings: PCI: rockchip: Add support for pcie wake irq

[Shawn Lin]

On 2017/8/25 10:11, Brian Norris wrote:

On Thu, Aug 24, 2017 at 11:53:54AM -0500, Bjorn Helgaas wrote:

On Tue, Aug 22, 2017 at 11:19:33AM +0800, Jeffy Chen wrote:

Signed-off-by: Jeffy Chen 



diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index 5678be82530d..9f6504129e80 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -20,10 +20,13 @@ Required properties:
  - msi-map: Maps a Requester ID to an MSI controller and associated
msi-specifier data. See ./pci-msi.txt
  - interrupts: Three interrupt entries must be specified.
-- interrupt-names: Must include the following names
-   - "sys"
-   - "legacy"
-   - "client"
+- interrupt-names: Include the following names
+   Required:
+   - "sys"
+   - "legacy"
+   - "client"
+   Optional:
+   - "wake"


Why is there no other PCI binding that includes "wake" as an
interrupt-name?  This feels like something that should be fairly
common across host controllers.  I don't want a Rockport-specific


s/port/chip/ :)


DT description if it could be made more general.


I'm not sure we can really answer that question ("why do no other PCI
bindings have this?"). But one guess would be that every other
controller uses only beacon wake.

It would be OK with me if we made a blanket statement that a controller
with a "wake" interrupt means PCI WAKE# (per the specification). It's
possible this could even be stuck into some generic PCI/DT code
eventually. (I don't think we have a really good place for this today.)


I guess we could register a pcie port service for dedicated WAKE# as it 
seems fairly parallel to pme code there, if we need a common place for

that?




Brian


  - resets: Must contain seven entries for each entry in reset-names.
   See ../reset/reset.txt for details.
  - reset-names: Must include the following names
@@ -87,10 +90,11 @@ pcie0: pcie@f800 {
clock-names = "aclk", "aclk-perf",
  "hclk", "pm";
bus-range = <0x0 0x1>;
-   interrupts = ,
-,
-;
-   interrupt-names = "sys", "legacy", "client";
+   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+ < 8 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "sys", "legacy", "client", "wake";
assigned-clocks = < SCLK_PCIEPHY_REF>;
assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
assigned-clock-rates = <1>;
--
2.11.0

Re: [PATCH] thermal: max77620: constify platform_device_id

[Zhang Rui]

On Sun, 2017-08-13 at 17:03 +0530, Arvind Yadav wrote:
> platform_device_id are not supposed to change at runtime. All
> functions
> working with platform_device_id provided by 
> work with const platform_device_id. So mark the non-const structs as
> const.
> 
> Signed-off-by: Arvind Yadav 

applied.

thanks,
rui
> ---
>  drivers/thermal/max77620_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/max77620_thermal.c
> b/drivers/thermal/max77620_thermal.c
> index 159bbce..3c74b91 100644
> --- a/drivers/thermal/max77620_thermal.c
> +++ b/drivers/thermal/max77620_thermal.c
> @@ -149,7 +149,7 @@ static int max77620_thermal_probe(struct
> platform_device *pdev)
>   return 0;
>  }
>  
> -static struct platform_device_id max77620_thermal_devtype[] = {
> +static const struct platform_device_id max77620_thermal_devtype[] =
> {
>   { .name = "max77620-thermal", },
>   {},
>  };

Re: [PATCH] thermal: max77620: constify platform_device_id

[Zhang Rui]

On Sun, 2017-08-13 at 17:03 +0530, Arvind Yadav wrote:
> platform_device_id are not supposed to change at runtime. All
> functions
> working with platform_device_id provided by 
> work with const platform_device_id. So mark the non-const structs as
> const.
> 
> Signed-off-by: Arvind Yadav 

applied.

thanks,
rui
> ---
>  drivers/thermal/max77620_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/max77620_thermal.c
> b/drivers/thermal/max77620_thermal.c
> index 159bbce..3c74b91 100644
> --- a/drivers/thermal/max77620_thermal.c
> +++ b/drivers/thermal/max77620_thermal.c
> @@ -149,7 +149,7 @@ static int max77620_thermal_probe(struct
> platform_device *pdev)
>   return 0;
>  }
>  
> -static struct platform_device_id max77620_thermal_devtype[] = {
> +static const struct platform_device_id max77620_thermal_devtype[] =
> {
>   { .name = "max77620-thermal", },
>   {},
>  };

Re: linux-next: Signed-off-by missing for commit in the nfsd tree

[J. Bruce Fields]

On Fri, Aug 25, 2017 at 08:48:21AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
> 
> Commit
> 
>   1b7f1a85c0fa ("opdesc will be useful outside nfs4proc.c")
> 
> is missing a Signed-off-by from its author and committer.

Fixed, thanks.--b.

Re: linux-next: Signed-off-by missing for commit in the nfsd tree

[J. Bruce Fields]

On Fri, Aug 25, 2017 at 08:48:21AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
> 
> Commit
> 
>   1b7f1a85c0fa ("opdesc will be useful outside nfs4proc.c")
> 
> is missing a Signed-off-by from its author and committer.

Fixed, thanks.--b.

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 02:09), Nick Terrell wrote:
[..]
> > > I think using dictionaries in zram could be very interesting. We could for
> > > example, take a random sample of the RAM and use that as the dictionary
> > > for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> > > dictionary (sizes may vary).
> > > 
> > > I'm not sure how you would pass a dictionary into the crypto compression
> > > API, but I'm sure we can make something work if dictionary compression
> > > proves to be beneficial enough.
> > 
> > a dictionaty pointer can be in `struct zstd_ctx'.
> 
> Sorry I'm not super familiar with the crypto API. How would the user
> initialize the dictionary in the `struct zstd_ctx'? I guess you could
> either expose the struct in some header, or provide a function that
> initializes it, but that isn't generic. Does the crypto library already
> have a standard way to provide extra information?

not really familiar either... I was thinking about having "zstd" and
"zstd_dict" crypto_alg structs - one would be !dict, the other one would
allocate dict and pass it to compress/decompress zstd callbacks. "zstd"
vecrsion would invoke zstd_params() passing zeros as compress and dict
sizes to ZSTD_getParams(), while "zstd_dict" would invoke, lets say,
zstd_params_dict() passing PAGE_SIZE-s. hm... (0, PAGE_SIZE)?  to
ZSTD_getParams(). just a rough idea...

-ss

Re: [PATCH] zram: add zstd to the supported algorithms list

[Sergey Senozhatsky]

On (08/25/17 02:09), Nick Terrell wrote:
[..]
> > > I think using dictionaries in zram could be very interesting. We could for
> > > example, take a random sample of the RAM and use that as the dictionary
> > > for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> > > dictionary (sizes may vary).
> > > 
> > > I'm not sure how you would pass a dictionary into the crypto compression
> > > API, but I'm sure we can make something work if dictionary compression
> > > proves to be beneficial enough.
> > 
> > a dictionaty pointer can be in `struct zstd_ctx'.
> 
> Sorry I'm not super familiar with the crypto API. How would the user
> initialize the dictionary in the `struct zstd_ctx'? I guess you could
> either expose the struct in some header, or provide a function that
> initializes it, but that isn't generic. Does the crypto library already
> have a standard way to provide extra information?

not really familiar either... I was thinking about having "zstd" and
"zstd_dict" crypto_alg structs - one would be !dict, the other one would
allocate dict and pass it to compress/decompress zstd callbacks. "zstd"
vecrsion would invoke zstd_params() passing zeros as compress and dict
sizes to ZSTD_getParams(), while "zstd_dict" would invoke, lets say,
zstd_params_dict() passing PAGE_SIZE-s. hm... (0, PAGE_SIZE)?  to
ZSTD_getParams(). just a rough idea...

-ss

Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem

[Zhang Rui]

On Wed, 2017-08-16 at 18:33 +0300, Leonard Crestez wrote:
> On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> > 
> > On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 12:38, Leonard Crestez wrote:
> > > > 
> > > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > > 
> > > > > On 08/08/17 08:21, Zhang Rui wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > I'm okay with the thermal change.
> > > > > > We still need ACK for the nvmem changes in this patch
> > > > > > series.
> > 
> > > 
> > > > 
> > > > > 
> > > > > NVMEM changes are already sent to Greg K H with other patches
> > > > > https://lkml.org/lkml/2017/8/8/436, should appear in next.
> > 
> > > 
> > > > 
> > > > These patches have a compile-time dependency on each other.
> > > > Wouldn't it make more sense for the whole series to go through
> > > > a single
> > > > maintainer tree, atomically? Most of the changes are in
> > > > driver/thermal.
> > 
> > > 
> > > I was expecting that the nvmem change go in as fix in a rc
> > > release
> > > so that you could apply the other patches after that.
> > > 
> > > Let me ping Greg about this!!
> > 

Srinivas,

Will you take patch 2/5?
Only after that, we can push the other changes.

thanks,
rui

> > As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch
> > 1/5,
> > 3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I
> > can
> > queue the full patch set for 4.14, with Srinivas' ACK.
> It's been a week since the last email and it seems that nothing
> happened. I can't find any of these patches in either torvalds/master
> or linux-next. It seems to me that the nvmem series linked above was
> not picked up after all?
> 
> It's not clear how to proceed. It's been more a month since the
> series
> was sent so maybe I should resend it but it's not clear who would
> pick
> it up.
> 
> --
> Regards,
> Leonard

Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem

[Zhang Rui]

On Wed, 2017-08-16 at 18:33 +0300, Leonard Crestez wrote:
> On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> > 
> > On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 12:38, Leonard Crestez wrote:
> > > > 
> > > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > > 
> > > > > On 08/08/17 08:21, Zhang Rui wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > I'm okay with the thermal change.
> > > > > > We still need ACK for the nvmem changes in this patch
> > > > > > series.
> > 
> > > 
> > > > 
> > > > > 
> > > > > NVMEM changes are already sent to Greg K H with other patches
> > > > > https://lkml.org/lkml/2017/8/8/436, should appear in next.
> > 
> > > 
> > > > 
> > > > These patches have a compile-time dependency on each other.
> > > > Wouldn't it make more sense for the whole series to go through
> > > > a single
> > > > maintainer tree, atomically? Most of the changes are in
> > > > driver/thermal.
> > 
> > > 
> > > I was expecting that the nvmem change go in as fix in a rc
> > > release
> > > so that you could apply the other patches after that.
> > > 
> > > Let me ping Greg about this!!
> > 

Srinivas,

Will you take patch 2/5?
Only after that, we can push the other changes.

thanks,
rui

> > As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch
> > 1/5,
> > 3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I
> > can
> > queue the full patch set for 4.14, with Srinivas' ACK.
> It's been a week since the last email and it seems that nothing
> happened. I can't find any of these patches in either torvalds/master
> or linux-next. It seems to me that the nvmem series linked above was
> not picked up after all?
> 
> It's not clear how to proceed. It's been more a month since the
> series
> was sent so maybe I should resend it but it's not clear who would
> pick
> it up.
> 
> --
> Regards,
> Leonard

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[Zhang Rui]

On Thu, 2017-08-17 at 13:12 +0530, kgu...@codeaurora.org wrote:
> On 2017-08-16 17:53, kgu...@codeaurora.org wrote:
> > 
> > On 2017-08-08 13:42, Zhang Rui wrote:
> > > 
> > > On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:
> > > > 
> > > > From: David Collins 
> > > > 
> > > > Add support for the TEMP_ALARM GEN2 PMIC peripheral
> > > > subtype.  The
> > > > GEN2 subtype defines an over temperature state with hysteresis
> > > > instead of stage in the status register.  There are two GEN2
> > > > states corresponding to stages 1 and 2.
> > > > 
> > > > Signed-off-by: David Collins 
> > > > Signed-off-by: Kiran Gunda 
> > > Ivan,
> > > 
> > > can you please review this patch and let me know your opinion?
> > > 
> > > thanks,
> > > rui
> > Ivan,
> > Could you please review this patch ?
> > 
> > Thanks,
> > Kiran
> Looks like Ivan is no more reviewing the patches for qcom.
> Adding Bjorn and Stephen Boyd for the review.
> 
Given this is a platform specific change, I will queue it for next
merge window, and let's see if there is any problem reported.

thanks,
rui
> Thanks,
> Kiran
> > 
> > > 
> > > > 
> > > > ---
> > > >  drivers/thermal/qcom-spmi-temp-alarm.c | 92
> > > > ++
> > > >  1 file changed, 71 insertions(+), 21 deletions(-)
> > > > 
> > > > diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > b/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > index f502419..a5e17ba 100644
> > > > --- a/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > +++ b/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > @@ -1,5 +1,5 @@
> > > >  /*
> > > > - * Copyright (c) 2011-2015, The Linux Foundation. All rights
> > > > reserved.
> > > > + * Copyright (c) 2011-2015, 2017, The Linux Foundation. All
> > > > rights
> > > > reserved.
> > > >   *
> > > >   * This program is free software; you can redistribute it
> > > > and/or
> > > > modify
> > > >   * it under the terms of the GNU General Public License
> > > > version 2
> > > > and
> > > > @@ -11,6 +11,7 @@
> > > >   * GNU General Public License for more details.
> > > >   */
> > > >  
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -29,13 +30,17 @@
> > > >  #define QPNP_TM_REG_ALARM_CTRL 0x46
> > > >  
> > > >  #define QPNP_TM_TYPE   0x09
> > > > -#define QPNP_TM_SUBTYPE0x08
> > > > +#define QPNP_TM_SUBTYPE_GEN1   0x08
> > > > +#define QPNP_TM_SUBTYPE_GEN2   0x09
> > > >  
> > > > -#define STATUS_STAGE_MASK  0x03
> > > > +#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
> > > > +#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
> > > > +#define STATUS_GEN2_STATE_SHIFT4
> > > >  
> > > > -#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
> > > > +#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
> > > > +#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
> > > >  
> > > > -#define ALARM_CTRL_FORCE_ENABLE0x80
> > > > +#define ALARM_CTRL_FORCE_ENABLEBIT(7)
> > > >  
> > > >  /*
> > > >   * Trip point values based on threshold control
> > > > @@ -58,6 +63,7 @@
> > > >  struct qpnp_tm_chip {
> > > >     struct regmap   *map;
> > > >     struct thermal_zone_device  *tz_dev;
> > > > +   unsigned intsubtype;
> > > >     longtemp;
> > > >     unsigned intthresh;
> > > >     unsigned intstage;
> > > > @@ -66,6 +72,9 @@ struct qpnp_tm_chip {
> > > >     struct iio_channel  *adc;
> > > >  };
> > > >  
> > > > +/* This array maps from GEN2 alarm state to GEN1 alarm stage
> > > > */
> > > > +static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2,
> > > > 3, 3,
> > > > 3};
> > > > +
> > > >  static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr,
> > > > u8
> > > > *data)
> > > >  {
> > > >     unsigned int val;
> > > > @@ -84,30 +93,59 @@ static int qpnp_tm_write(struct
> > > > qpnp_tm_chip
> > > > *chip, u16 addr, u8 data)
> > > >     return regmap_write(chip->map, chip->base + addr,
> > > > data);
> > > >  }
> > > >  
> > > > +/**
> > > > + * qpnp_tm_get_temp_stage() - return over-temperature stage
> > > > + * @chip:  Pointer to the qpnp_tm chip
> > > > + *
> > > > + * Return: stage (GEN1) or state (GEN2) on success, or errno
> > > > on
> > > > failure.
> > > > + */
> > > > +static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
> > > > +{
> > > > +   int ret;
> > > > +   u8 reg = 0;
> > > > +
> > > > +   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
> > > > +   if (ret < 0)
> > > > +   return ret;
> > > > +
> > > > +   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
> > > > +   ret = reg & STATUS_GEN1_STAGE_MASK;
> > > > +   else
> > > > +   ret = (reg & 

Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

[Zhang Rui]

On Thu, 2017-08-17 at 13:12 +0530, kgu...@codeaurora.org wrote:
> On 2017-08-16 17:53, kgu...@codeaurora.org wrote:
> > 
> > On 2017-08-08 13:42, Zhang Rui wrote:
> > > 
> > > On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:
> > > > 
> > > > From: David Collins 
> > > > 
> > > > Add support for the TEMP_ALARM GEN2 PMIC peripheral
> > > > subtype.  The
> > > > GEN2 subtype defines an over temperature state with hysteresis
> > > > instead of stage in the status register.  There are two GEN2
> > > > states corresponding to stages 1 and 2.
> > > > 
> > > > Signed-off-by: David Collins 
> > > > Signed-off-by: Kiran Gunda 
> > > Ivan,
> > > 
> > > can you please review this patch and let me know your opinion?
> > > 
> > > thanks,
> > > rui
> > Ivan,
> > Could you please review this patch ?
> > 
> > Thanks,
> > Kiran
> Looks like Ivan is no more reviewing the patches for qcom.
> Adding Bjorn and Stephen Boyd for the review.
> 
Given this is a platform specific change, I will queue it for next
merge window, and let's see if there is any problem reported.

thanks,
rui
> Thanks,
> Kiran
> > 
> > > 
> > > > 
> > > > ---
> > > >  drivers/thermal/qcom-spmi-temp-alarm.c | 92
> > > > ++
> > > >  1 file changed, 71 insertions(+), 21 deletions(-)
> > > > 
> > > > diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > b/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > index f502419..a5e17ba 100644
> > > > --- a/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > +++ b/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > @@ -1,5 +1,5 @@
> > > >  /*
> > > > - * Copyright (c) 2011-2015, The Linux Foundation. All rights
> > > > reserved.
> > > > + * Copyright (c) 2011-2015, 2017, The Linux Foundation. All
> > > > rights
> > > > reserved.
> > > >   *
> > > >   * This program is free software; you can redistribute it
> > > > and/or
> > > > modify
> > > >   * it under the terms of the GNU General Public License
> > > > version 2
> > > > and
> > > > @@ -11,6 +11,7 @@
> > > >   * GNU General Public License for more details.
> > > >   */
> > > >  
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -29,13 +30,17 @@
> > > >  #define QPNP_TM_REG_ALARM_CTRL 0x46
> > > >  
> > > >  #define QPNP_TM_TYPE   0x09
> > > > -#define QPNP_TM_SUBTYPE0x08
> > > > +#define QPNP_TM_SUBTYPE_GEN1   0x08
> > > > +#define QPNP_TM_SUBTYPE_GEN2   0x09
> > > >  
> > > > -#define STATUS_STAGE_MASK  0x03
> > > > +#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
> > > > +#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
> > > > +#define STATUS_GEN2_STATE_SHIFT4
> > > >  
> > > > -#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
> > > > +#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
> > > > +#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
> > > >  
> > > > -#define ALARM_CTRL_FORCE_ENABLE0x80
> > > > +#define ALARM_CTRL_FORCE_ENABLEBIT(7)
> > > >  
> > > >  /*
> > > >   * Trip point values based on threshold control
> > > > @@ -58,6 +63,7 @@
> > > >  struct qpnp_tm_chip {
> > > >     struct regmap   *map;
> > > >     struct thermal_zone_device  *tz_dev;
> > > > +   unsigned intsubtype;
> > > >     longtemp;
> > > >     unsigned intthresh;
> > > >     unsigned intstage;
> > > > @@ -66,6 +72,9 @@ struct qpnp_tm_chip {
> > > >     struct iio_channel  *adc;
> > > >  };
> > > >  
> > > > +/* This array maps from GEN2 alarm state to GEN1 alarm stage
> > > > */
> > > > +static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2,
> > > > 3, 3,
> > > > 3};
> > > > +
> > > >  static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr,
> > > > u8
> > > > *data)
> > > >  {
> > > >     unsigned int val;
> > > > @@ -84,30 +93,59 @@ static int qpnp_tm_write(struct
> > > > qpnp_tm_chip
> > > > *chip, u16 addr, u8 data)
> > > >     return regmap_write(chip->map, chip->base + addr,
> > > > data);
> > > >  }
> > > >  
> > > > +/**
> > > > + * qpnp_tm_get_temp_stage() - return over-temperature stage
> > > > + * @chip:  Pointer to the qpnp_tm chip
> > > > + *
> > > > + * Return: stage (GEN1) or state (GEN2) on success, or errno
> > > > on
> > > > failure.
> > > > + */
> > > > +static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
> > > > +{
> > > > +   int ret;
> > > > +   u8 reg = 0;
> > > > +
> > > > +   ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
> > > > +   if (ret < 0)
> > > > +   return ret;
> > > > +
> > > > +   if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
> > > > +   ret = reg & STATUS_GEN1_STAGE_MASK;
> > > > +   else
> > > > +   ret = (reg & STATUS_GEN2_STATE_MASK) >>
> > > > STATUS_GEN2_STATE_SHIFT;
> > > > +
> > > > +   return 

Re: [PATCH v4 3/4] dt-bindings: PCI: rockchip: Add support for pcie wake irq

[Brian Norris]

On Thu, Aug 24, 2017 at 11:53:54AM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 22, 2017 at 11:19:33AM +0800, Jeffy Chen wrote:
> > Signed-off-by: Jeffy Chen 

> > diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
> > b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > index 5678be82530d..9f6504129e80 100644
> > --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > @@ -20,10 +20,13 @@ Required properties:
> >  - msi-map: Maps a Requester ID to an MSI controller and associated
> > msi-specifier data. See ./pci-msi.txt
> >  - interrupts: Three interrupt entries must be specified.
> > -- interrupt-names: Must include the following names
> > -   - "sys"
> > -   - "legacy"
> > -   - "client"
> > +- interrupt-names: Include the following names
> > +   Required:
> > +   - "sys"
> > +   - "legacy"
> > +   - "client"
> > +   Optional:
> > +   - "wake"
> 
> Why is there no other PCI binding that includes "wake" as an
> interrupt-name?  This feels like something that should be fairly
> common across host controllers.  I don't want a Rockport-specific

s/port/chip/ :)

> DT description if it could be made more general.

I'm not sure we can really answer that question ("why do no other PCI
bindings have this?"). But one guess would be that every other
controller uses only beacon wake.

It would be OK with me if we made a blanket statement that a controller
with a "wake" interrupt means PCI WAKE# (per the specification). It's
possible this could even be stuck into some generic PCI/DT code
eventually. (I don't think we have a really good place for this today.)

Brian

> >  - resets: Must contain seven entries for each entry in reset-names.
> >See ../reset/reset.txt for details.
> >  - reset-names: Must include the following names
> > @@ -87,10 +90,11 @@ pcie0: pcie@f800 {
> > clock-names = "aclk", "aclk-perf",
> >   "hclk", "pm";
> > bus-range = <0x0 0x1>;
> > -   interrupts = ,
> > -,
> > -;
> > -   interrupt-names = "sys", "legacy", "client";
> > +   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
> > + < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
> > + < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
> > + < 8 IRQ_TYPE_LEVEL_LOW>;
> > +   interrupt-names = "sys", "legacy", "client", "wake";
> > assigned-clocks = < SCLK_PCIEPHY_REF>;
> > assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
> > assigned-clock-rates = <1>;
> > -- 
> > 2.11.0
> > 
> > 

Re: [PATCH v4 3/4] dt-bindings: PCI: rockchip: Add support for pcie wake irq

[Brian Norris]

On Thu, Aug 24, 2017 at 11:53:54AM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 22, 2017 at 11:19:33AM +0800, Jeffy Chen wrote:
> > Signed-off-by: Jeffy Chen 

> > diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
> > b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > index 5678be82530d..9f6504129e80 100644
> > --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > @@ -20,10 +20,13 @@ Required properties:
> >  - msi-map: Maps a Requester ID to an MSI controller and associated
> > msi-specifier data. See ./pci-msi.txt
> >  - interrupts: Three interrupt entries must be specified.
> > -- interrupt-names: Must include the following names
> > -   - "sys"
> > -   - "legacy"
> > -   - "client"
> > +- interrupt-names: Include the following names
> > +   Required:
> > +   - "sys"
> > +   - "legacy"
> > +   - "client"
> > +   Optional:
> > +   - "wake"
> 
> Why is there no other PCI binding that includes "wake" as an
> interrupt-name?  This feels like something that should be fairly
> common across host controllers.  I don't want a Rockport-specific

s/port/chip/ :)

> DT description if it could be made more general.

I'm not sure we can really answer that question ("why do no other PCI
bindings have this?"). But one guess would be that every other
controller uses only beacon wake.

It would be OK with me if we made a blanket statement that a controller
with a "wake" interrupt means PCI WAKE# (per the specification). It's
possible this could even be stuck into some generic PCI/DT code
eventually. (I don't think we have a really good place for this today.)

Brian

> >  - resets: Must contain seven entries for each entry in reset-names.
> >See ../reset/reset.txt for details.
> >  - reset-names: Must include the following names
> > @@ -87,10 +90,11 @@ pcie0: pcie@f800 {
> > clock-names = "aclk", "aclk-perf",
> >   "hclk", "pm";
> > bus-range = <0x0 0x1>;
> > -   interrupts = ,
> > -,
> > -;
> > -   interrupt-names = "sys", "legacy", "client";
> > +   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
> > + < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
> > + < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
> > + < 8 IRQ_TYPE_LEVEL_LOW>;
> > +   interrupt-names = "sys", "legacy", "client", "wake";
> > assigned-clocks = < SCLK_PCIEPHY_REF>;
> > assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
> > assigned-clock-rates = <1>;
> > -- 
> > 2.11.0
> > 
> > 

Re: [PATCH] zram: add zstd to the supported algorithms list

[Nick Terrell]

On 8/24/17, 6:53 PM, "Sergey Senozhatsky"  
wrote:
> On (08/25/17 01:35), Nick Terrell wrote:
> > On 8/24/17, 5:49 PM, "Joonsoo Kim"  wrote:
> > > On Thu, Aug 24, 2017 at 09:33:54PM +, Nick Terrell wrote:
> > > > On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote:
> > > > > Add ZSTD to the list of supported compression algorithms.
> > > > > 
> > > > > Official benchmarks [1]:
> > > > 
> > > > Awesome! Let me know if you need anything from me.
> > > > 
> > > Hello, Nick.
> > > 
> > > Awesome work!!!
> > > 
> > > Let me ask a question.
> > > Zram compress and decompress a small data (a page) and your github
> > > site says that using predefined dictionary would be helpful in this
> > > situation. However, it seems that compression crypto API for zstd
> > > doesn't use ZSTD_compress_usingDict(). Is there any plan to support
> > > it?
> 
> excellent question, Joonsoo.
> 
> > I think using dictionaries in zram could be very interesting. We could for
> > example, take a random sample of the RAM and use that as the dictionary
> > for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> > dictionary (sizes may vary).
> > 
> > I'm not sure how you would pass a dictionary into the crypto compression
> > API, but I'm sure we can make something work if dictionary compression
> > proves to be beneficial enough.
> 
> a dictionaty pointer can be in `struct zstd_ctx'.

Sorry I'm not super familiar with the crypto API. How would the user
initialize the dictionary in the `struct zstd_ctx'? I guess you could
either expose the struct in some header, or provide a function that
initializes it, but that isn't generic. Does the crypto library already
have a standard way to provide extra information?

> > What data have you, or anyone, used for benchmarking compression ratio and 
> > speed for RAM? Since it is such a specialized application, the standard
> > compression benchmarks aren't very applicable.
> 
> 
> yeah, I thought that zstd uses dicts unconditionally.
> 
> I used my own simple minded test script:
>   https://github.com/sergey-senozhatsky/zram-perf-test
> 
> it basically invokes fio with a 'static compression buffer', because
> we want to have the exactly same data to be compressed when I compare
> algorithms... I guess I need to improve it, somehow.

I'll check it out, thanks!

> 
>   -ss
> 

Re: [PATCH] zram: add zstd to the supported algorithms list

[Nick Terrell]

On 8/24/17, 6:53 PM, "Sergey Senozhatsky"  
wrote:
> On (08/25/17 01:35), Nick Terrell wrote:
> > On 8/24/17, 5:49 PM, "Joonsoo Kim"  wrote:
> > > On Thu, Aug 24, 2017 at 09:33:54PM +, Nick Terrell wrote:
> > > > On Thu, Aug 24, 2017 at 10:49:36AM +0900, Sergey Senozhatsky wrote:
> > > > > Add ZSTD to the list of supported compression algorithms.
> > > > > 
> > > > > Official benchmarks [1]:
> > > > 
> > > > Awesome! Let me know if you need anything from me.
> > > > 
> > > Hello, Nick.
> > > 
> > > Awesome work!!!
> > > 
> > > Let me ask a question.
> > > Zram compress and decompress a small data (a page) and your github
> > > site says that using predefined dictionary would be helpful in this
> > > situation. However, it seems that compression crypto API for zstd
> > > doesn't use ZSTD_compress_usingDict(). Is there any plan to support
> > > it?
> 
> excellent question, Joonsoo.
> 
> > I think using dictionaries in zram could be very interesting. We could for
> > example, take a random sample of the RAM and use that as the dictionary
> > for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> > dictionary (sizes may vary).
> > 
> > I'm not sure how you would pass a dictionary into the crypto compression
> > API, but I'm sure we can make something work if dictionary compression
> > proves to be beneficial enough.
> 
> a dictionaty pointer can be in `struct zstd_ctx'.

Sorry I'm not super familiar with the crypto API. How would the user
initialize the dictionary in the `struct zstd_ctx'? I guess you could
either expose the struct in some header, or provide a function that
initializes it, but that isn't generic. Does the crypto library already
have a standard way to provide extra information?

> > What data have you, or anyone, used for benchmarking compression ratio and 
> > speed for RAM? Since it is such a specialized application, the standard
> > compression benchmarks aren't very applicable.
> 
> 
> yeah, I thought that zstd uses dicts unconditionally.
> 
> I used my own simple minded test script:
>   https://github.com/sergey-senozhatsky/zram-perf-test
> 
> it basically invokes fio with a 'static compression buffer', because
> we want to have the exactly same data to be compressed when I compare
> algorithms... I guess I need to improve it, somehow.

I'll check it out, thanks!

> 
>   -ss
>