Re: [RFC PATCH 7/7] DMA: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

On 23/08/15 15:33, Vinod Koul wrote:
 On Tue, Aug 18, 2015 at 02:49:15PM +0100, Jon Hunter wrote:
 +#define AHUB_TO_MEMORY  2
 +#define MEMORY_TO_AHUB  4
 
 namespace this aptly as well
 
 +static void tegra_adma_stop(struct tegra_dma_channel *tdc)
 +{
 +u32 status;
 +
 +/* TODO: Do we need to disable interrupts here? */
 
 when?

Once everyone is happy with the RFC in general.

 +static void tegra_adma_start(struct tegra_dma_channel *tdc,
 +struct tegra_dma_sg_req *sg_req)
 +{
 +struct tegra_adma_chan_regs *ch_regs = sg_req-adma_ch_regs;
 +
 +/* Update transfer done count for position calculation */
 +tdc-adma_ch_regs.tc = ch_regs-tc;
 +tdc_write(tdc, ADMA_CH_TC, ch_regs-tc);
 +tdc_write(tdc, ADMA_CH_CTRL, ch_regs-ctrl);
 +tdc_write(tdc, ADMA_CH_LOWER_SOURCE_ADDR, ch_regs-src_ptr);
 +tdc_write(tdc, ADMA_CH_LOWER_TARGET_ADDR, ch_regs-tgt_ptr);
 +tdc_write(tdc, ADMA_CH_AHUB_FIFO_CTRL, ch_regs-ahub_fifo_ctrl);
 +tdc_write(tdc, ADMA_CH_CONFIG, ch_regs-config);
 empty line here please

Ok.

 +static int tegra_adma_get_xfer_params(struct tegra_dma_channel *tdc,
 +  struct tegra_adma_chan_regs *ch_regs,
 +  enum dma_transfer_direction direction)
 +{
 +u32 burst_size, ctrl, ctrl_mask, slave_id, fifo_mask, fifo_shift;
 +
 +ch_regs-ahub_fifo_ctrl = tdc_read(tdc, ADMA_CH_AHUB_FIFO_CTRL);
 +ch_regs-config = tdc_read(tdc, ADMA_CH_CONFIG);
 +ch_regs-ctrl = tdc_read(tdc, ADMA_CH_CTRL);
 +slave_id = tdc-dma_sconfig.slave_id;
 +
 +switch (direction) {
 +case DMA_MEM_TO_DEV:
 +burst_size = fls(tdc-dma_sconfig.dst_maxburst);
 +ctrl_mask = ADMA_CH_CTRL_TX_REQUEST_SELECT_MASK;
 +ctrl = MEMORY_TO_AHUB  ADMA_CH_CTRL_TRANSFER_DIRECTION_SHIFT;
 +ctrl |= slave_id  ADMA_CH_CTRL_TX_REQUEST_SELECT_SHIFT;
 +fifo_mask = ADMA_CH_AHUB_FIFO_CTRL_TX_FIFO_SIZE_MASK;
 +fifo_shift = ADMA_CH_AHUB_FIFO_CTRL_TX_FIFO_SIZE_SHIFT;
 +break;
 Empty line here pls

Ok, any reason why? Other dma drivers don't appear to do this.

 +case DMA_DEV_TO_MEM:
 +burst_size = fls(tdc-dma_sconfig.src_maxburst);
 +ctrl_mask = ADMA_CH_CTRL_RX_REQUEST_SELECT_MASK;
 +ctrl = AHUB_TO_MEMORY  ADMA_CH_CTRL_TRANSFER_DIRECTION_SHIFT;
 +ctrl |= slave_id  ADMA_CH_CTRL_RX_REQUEST_SELECT_SHIFT;
 +fifo_mask = ADMA_CH_AHUB_FIFO_CTRL_RX_FIFO_SIZE_MASK;
 +fifo_shift = ADMA_CH_AHUB_FIFO_CTRL_RX_FIFO_SIZE_SHIFT;
 +break;
 
 here too...
 
 +default:
 +dev_err(tdc2dev(tdc), Dma direction is not supported\n);
 +return -EINVAL;
 +}
 +
 +if (!burst_size || burst_size  ADMA_BURSTSIZE_16)
 +burst_size = ADMA_BURSTSIZE_16;
 +
 +ch_regs-ahub_fifo_ctrl = ~fifo_mask;
 +ch_regs-ahub_fifo_ctrl |= ADMA_FIFO_DEFAULT_SIZE  fifo_shift;
 +ch_regs-config = ~ADMA_CH_CONFIG_BURST_SIZE_MASK;
 +ch_regs-config |= burst_size  ADMA_CH_CONFIG_BURST_SIZE_SHIFT;
 +ch_regs-ctrl = ~(ctrl_mask | ADMA_CH_CTRL_TRANSFER_DIRECTION_MASK);
 +ch_regs-ctrl |= ctrl;
 +
 +return -EINVAL;
 ??

Thanks. That's an error. Will fix.

 +static int tegra_adma_pm_suspend(struct device *dev)
 +{
 +struct tegra_dma *tdma = dev_get_drvdata(dev);
 +int i;
 +int ret;
 +
 +ret = pm_runtime_get_sync(dev);
 why is this required :)

To ensure that the clocks are enabled before the registers are read.
This function saves the dma context before suspend, in case the hardware
state is lost.

 +static int tegra_adma_pm_resume(struct device *dev)
 +{
 +struct tegra_dma *tdma = dev_get_drvdata(dev);
 +int i;
 +int ret;
 +
 +ret = pm_runtime_get_sync(dev);
 and this

Same here.

Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes

[Dave Chinner]

On Mon, Aug 24, 2015 at 04:34:37PM +0800, Eryu Guan wrote:
 On Mon, Aug 24, 2015 at 04:24:25PM +1000, Dave Chinner wrote:
  On Mon, Aug 24, 2015 at 11:18:16AM +0800, Eryu Guan wrote:
   On Mon, Aug 24, 2015 at 11:11:23AM +1000, Dave Chinner wrote:

Eryu, can you change the way you run the event trace to be:

$ sudo trace-cmd options -o outfile location ./check test options

rather than running the trace as a background operation elsewhere?
Maybe that will give better results.
 [snip]
  Anyway, Eryum long and short of it is that you don't need to worry
  about testing all the different combinations - we now know that the
  completion events are occurring, so let's focus on whether the sync
  code is not waiting for them correctly. Can you trace the following
  events:
  
  xfs_log_force
  xfs_setfilesize
  writeback_queue
  writeback_exec
  writeback_start
  writeback_queue_io
  writeback_written
  writeback_pages_written
  
  basically I'm trying to see if we've got all the BDI events as we'd
  expect then to be queued and run for sync, and when the -sync_fs
  call occurs during the sync process before shutdown and unmount...
 
 I collected two versions of trace info with crc enabled.
 
 http://128.199.137.77/writeback-crc/
 
 This version traced the same events as previous runs.
 
 http://128.199.137.77/writeback-crc-v2/
 
 And this version only traced the events you listed above.

OK, I'll look into these later.

 And the results of other tests to check(all done with v4 xfs, with no
 tracepoints enabled):
 
  Other things to check (separately):
  - change godown to godown -f
 
 Passed 100 loops.

Yup, I expected that from the last set of traces - the -f flag
triggers a log force before shutdown, and that flushes out
transactions that sync missed.

  - add a sleep 5 before running godown after sync
 
 Failed, if you need the trace info please let me know.

Expected, still nothing to flush transactions before shutdown.

  - add a sleep 5; sync before running godown
 
 Passed 100 loops.

expected - sync flushed the transactions it missed on the first
pass.

Thanks for running these tests!

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 71/82] md/bitmap: return an error when bitmap superblock is corrupt.

[Jiri Slaby]

From: NeilBrown ne...@suse.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49 upstream
Use separate bitmaps for each nodes in the cluster

bitmap_read_sb() validates the bitmap superblock that it reads in.
If it finds an inconsistency like a bad magic number or out-of-range
version number, it prints an error and returns, but it incorrectly
returns zero, so the array is still assembled with the (invalid) bitmap.

This means it could try to use a bitmap with a new version number which
it therefore does not understand.

This bug was introduced in 3.5 and fix as part of a larger patch in 4.1.
So the patch is suitable for any -stable kernel in that range.

Fixes: 27581e5ae01f (md/bitmap: centralise allocation of bitmap file pages.)
Signed-off-by: NeilBrown ne...@suse.com
Reported-by: GuoQing Jiang gqji...@suse.com
---
 drivers/md/bitmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index 03b2edd35e19..64c4d0c2ca80 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -564,6 +564,8 @@ static int bitmap_read_sb(struct bitmap *bitmap)
if (err)
return err;
 
+   err = -EINVAL;
+
sb = kmap_atomic(sb_page);
 
chunksize = le32_to_cpu(sb-chunksize);
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 72/82] mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations

[Jiri Slaby]

From: Michal Hocko mho...@suse.cz

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit ecf5fc6e9654cd7a268c782a523f072b2f1959f9 upstream.

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: 883d7c9b0a30  CPU: 1   COMMAND: rsync
  #0 __schedule at 815ab152
  #1 schedule at 815ab76e
  #2 schedule_timeout at 815ae5e5
  #3 io_schedule_timeout at 815aad6a
  #4 bit_wait_io at 815abfc6
  #5 __wait_on_bit at 815abda5
  #6 wait_on_page_bit at 8111fd4f
  #7 shrink_page_list at 81135445
  #8 shrink_inactive_list at 81135845
  #9 shrink_lruvec at 81135ead
 #10 shrink_zone at 811360c3
 #11 shrink_zones at 81136eff
 #12 do_try_to_free_pages at 8113712f
 #13 try_to_free_mem_cgroup_pages at 811372be
 #14 try_charge at 81189423
 #15 mem_cgroup_try_charge at 8118c6f5
 #16 __add_to_page_cache_locked at 8112137d
 #17 add_to_page_cache_lru at 81121618
 #18 pagecache_get_page at 8112170b
 #19 grow_dev_page at 811c8297
 #20 __getblk_slow at 811c91d6
 #21 __getblk_gfp at 811c92c1
 #22 ext4_ext_grow_indepth at 8124565c
 #23 ext4_ext_create_new_leaf at 81246ca8
 #24 ext4_ext_insert_extent at 81246f09
 #25 ext4_ext_map_blocks at 8124a848
 #26 ext4_map_blocks at 8121a5b7
 #27 mpage_map_one_extent at 8121b1fa
 #28 mpage_map_and_submit_extent at 8121f07b
 #29 ext4_writepages at 8121f6d5
 #30 do_writepages at 8112c490
 #31 __filemap_fdatawrite_range at 81120199
 #32 filemap_flush at 8112041c
 #33 ext4_alloc_da_blocks at 81219da1
 #34 ext4_rename at 81229b91
 #35 ext4_rename2 at 81229e32
 #36 vfs_rename at 811a08a5
 #37 SYSC_renameat2 at 811a3ffc
 #38 sys_renameat2 at 811a408e
 #39 sys_rename at 8119e51e
 #40 system_call_fastpath at 815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384e9da8 (memcg: prevent OOM
with too many dirty pages) and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f44fcb0 (memcg:
further prevent OOM with too many dirty pages) which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

[ty...@mit.edu: corrected the control flow]
Fixes: c3b94f44fcb0 (memcg: further prevent OOM with too many dirty pages)
Reported-by: Nikolay Borisov ker...@kyup.com
Signed-off-by: Michal Hocko mho...@suse.cz
Signed-off-by: Hugh Dickins hu...@google.com
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 mm/vmscan.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index ee8363f73cab..04c33d5fb079 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -871,21 +871,17 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
 *
 * 2) Global reclaim encounters a page, memcg encounters a
 *page that is not marked for immediate reclaim or
-*the caller does not have __GFP_IO. In this case mark
+*the caller does not have __GFP_FS (or __GFP_IO if it's
+*simply going to swap, not to fs). In this case mark
 *the page 

[PATCH 3.12 70/82] path_openat(): fix double fput()

[Jiri Slaby]

From: Al Viro v...@zeniv.linux.org.uk

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit f15133df088ecadd141ea1907f2c96df67c729f0 upstream.

path_openat() jumps to the wrong place after do_tmpfile() - it has
already done path_cleanup() (as part of path_lookupat() called by
do_tmpfile()), so doing that again can lead to double fput().

Signed-off-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 fs/namei.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/namei.c b/fs/namei.c
index c0c78e193e2a..097bbeac8c66 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3202,7 +3202,7 @@ static struct file *path_openat(int dfd, struct filename 
*pathname,
 
if (unlikely(file-f_flags  __O_TMPFILE)) {
error = do_tmpfile(dfd, pathname, nd, flags, op, file, opened);
-   goto out;
+   goto out2;
}
 
error = path_init(dfd, pathname-name, flags | LOOKUP_PARENT, nd, 
base);
@@ -3240,6 +3240,7 @@ out:
path_put(nd-root);
if (base)
fput(base);
+out2:
if (!(opened  FILE_OPENED)) {
BUG_ON(!error);
put_filp(file);
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 61/82] rcu: Provide counterpart to rcu_dereference() for non-RCU situations

[Jiri Slaby]

From: Paul E. McKenney paul...@linux.vnet.ibm.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 54ef6df3f3f1353d99c80c437259d317b2cd1cbd upstream.

Although rcu_dereference() and friends can be used in situations where
object lifetimes are being managed by something other than RCU, the
resulting sparse and lockdep-RCU noise can be annoying.  This commit
therefore supplies a lockless_dereference(), which provides the
protection for dereferences without the RCU-related debugging noise.

Reported-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 include/linux/rcupdate.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index f1f1bc39346b..4912c953cab7 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -554,6 +554,20 @@ static inline void rcu_preempt_sleep_check(void)
(p) = (typeof(*v) __force space *)(v); \
} while (0)
 
+/**
+ * lockless_dereference() - safely load a pointer for later dereference
+ * @p: The pointer to load
+ *
+ * Similar to rcu_dereference(), but for situations where the pointed-to
+ * object's lifetime is managed by something other than RCU.  That
+ * something other might be reference counting or simple immortality.
+ */
+#define lockless_dereference(p) \
+({ \
+   typeof(p) _p1 = ACCESS_ONCE(p); \
+   smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
+   (_p1); \
+})
 
 /**
  * rcu_access_pointer() - fetch RCU pointer with no dereferencing
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 44/82] ipmi: fix timeout calculation when bmc is disconnected

[Jiri Slaby]

From: Xie XiuQi xiexi...@huawei.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit e21404dc0ac7ac971c1e36274b48bb460463f4e5 upstream.

Loading ipmi_si module while bmc is disconnected, we found the timeout
is longer than 5 secs.  Actually it takes about 3 mins and 20
secs.(HZ=250)

error message as below:
  Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
  Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
  [...]
  Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
  Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
  Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
  Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]

Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
usecs from timeout.

Reported-by: Hu Shiyuan hushiy...@huawei.com
Signed-off-by: Xie XiuQi xiexi...@huawei.com
Signed-off-by: Corey Minyard cminy...@mvista.com
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/char/ipmi/ipmi_si_intf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index e5bdd1a2f541..25ed69ffd8dd 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2783,7 +2783,7 @@ static int wait_for_msg_done(struct smi_info *smi_info)
smi_result == SI_SM_CALL_WITH_TICK_DELAY) {
schedule_timeout_uninterruptible(1);
smi_result = smi_info-handlers-event(
-   smi_info-si_sm, 100);
+   smi_info-si_sm, jiffies_to_usecs(1));
} else if (smi_result == SI_SM_CALL_WITHOUT_DELAY) {
smi_result = smi_info-handlers-event(
smi_info-si_sm, 0);
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 46/82] md: use kzalloc() when bitmap is disabled

[Jiri Slaby]

From: Benjamin Randazzo benja...@randazzo.fr

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit b6878d9e03043695dbf3fa1caa6dfc09db225b16 upstream.

In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
mdu_bitmap_file_t called file.

5769 file = kmalloc(sizeof(*file), GFP_NOIO);
5770 if (!file)
5771 return -ENOMEM;

This structure is copied to user space at the end of the function.

5786 if (err == 0 
5787 copy_to_user(arg, file, sizeof(*file)))
5788 err = -EFAULT

But if bitmap is disabled only the first byte of file is initialized
with zero, so it's possible to read some bytes (up to 4095) of kernel
space memory from user space. This is an information leak.

5775 /* bitmap disabled, zero the first byte and copy out */
5776 if (!mddev-bitmap_info.file)
5777 file-pathname[0] = '\0';

Signed-off-by: Benjamin Randazzo benja...@randazzo.fr
Signed-off-by: NeilBrown ne...@suse.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/md/md.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 2394b5bbeab9..1c512dc1f17f 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5642,8 +5642,7 @@ static int get_bitmap_file(struct mddev * mddev, void 
__user * arg)
char *ptr, *buf = NULL;
int err = -ENOMEM;
 
-   file = kmalloc(sizeof(*file), GFP_NOIO);
-
+   file = kzalloc(sizeof(*file), GFP_NOIO);
if (!file)
goto out;
 
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

[Leo Yan]

Hi Mark,

On Fri, Aug 21, 2015 at 07:40:59PM +0100, Mark Rutland wrote:
 On Wed, Aug 19, 2015 at 10:37:35AM +0100, Leo Yan wrote:
  On Hi6220, below memory regions in DDR have specific purpose:
  
0x05e0, - 0x05ef,: For MCU firmware using at runtime;
0x0740,f000 - 0x0740,: For MCU firmware's section;
0x06df,f000 - 0x06df,: For mailbox message data.
  
  This patch reserves these memory regions and add device node for
  mailbox in dts.
  
  Signed-off-by: Leo Yan leo@linaro.org
  ---
   arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +---
   arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  8 
   2 files changed, 25 insertions(+), 3 deletions(-)
  
  diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
  b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
  index e36a539..d5470d3 100644
  --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
  +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
  @@ -7,9 +7,6 @@
   
   /dts-v1/;
   
  -/*Reserved 1MB memory for MCU*/
  -/memreserve/ 0x05e0 0x0010;
  -
   #include hi6220.dtsi
   
   / {
  @@ -28,4 +25,21 @@
  device_type = memory;
  reg = 0x0 0x0 0x0 0x4000;
  };
  +
  +   reserved-memory {
  +   #address-cells = 2;
  +   #size-cells = 2;
  +   ranges;
  +
  +   mcu-buf@05e0 {
  +   no-map;
  +   reg = 0x0 0x05e0 0x0 0x0010,  /* MCU firmware 
  buffer */
  + 0x0 0x0740f000 0x0 0x1000;  /* MCU firmware 
  section */
  +   };
  +
  +   mbox-buf@06dff000 {
  +   no-map;
  +   reg = 0x0 0x06dff000 0x0 0x1000;  /* Mailbox 
  message buf */
  +   };
  +   };
 
 As far as I can see, it would be simpler to simply carve these out of the
 memory node.
 
 I don't see why you need reserved-memory here, given you're not referring to
 these regions by phandle anyway.

- Now we have enabled EFI_STUB, so the memory node will be removed in
  kernel:
efi_entry()
  \- allocate_new_fdt_and_exit_boot()
\- update_fdt();

  Finally in kernel it cannot use memory node to carve out reseved
  memory regions.

- On the other hand, DTS's the memory node is to describes the
  physical memory layout for the system; so it's better to use it only
  to describe the hardware info for memory. We can use reserved-memory
  to help manage the memory regions which are reserved from software
  perspective.

According to upper info, we still need to use reserved-memory node to
depict the reserved memory regions. i have no knowledge about EFI_STUB,
so please confirm or correct as needed.

Thanks,
Leo Yan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 56/82] md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies

[Jiri Slaby]

From: NeilBrown ne...@suse.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 423f04d63cf421ea436bcc5be02543d549ce4b28 upstream.

raid1_end_read_request() assumes that the In_sync bits are consistent
with the -degaded count.
raid1_spare_active updates the In_sync bit before the -degraded count
and so exposes an inconsistency, as does error()
So extend the spinlock in raid1_spare_active() and error() to hide those
inconsistencies.

This should probably be part of
  Commit: 34cab6f42003 (md/raid1: fix test for 'was read error from
  last working device'.)
as it addresses the same issue.  It fixes the same bug and should go
to -stable for same reasons.

Fixes: 76073054c95b (md/raid1: clean up read_balance.)
Signed-off-by: NeilBrown ne...@suse.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/md/raid1.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 14934ac112c3..1cb7642c1ba9 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1382,6 +1382,7 @@ static void error(struct mddev *mddev, struct md_rdev 
*rdev)
 {
char b[BDEVNAME_SIZE];
struct r1conf *conf = mddev-private;
+   unsigned long flags;
 
/*
 * If it is not operational, then we have already marked it as dead
@@ -1401,14 +1402,13 @@ static void error(struct mddev *mddev, struct md_rdev 
*rdev)
return;
}
set_bit(Blocked, rdev-flags);
+   spin_lock_irqsave(conf-device_lock, flags);
if (test_and_clear_bit(In_sync, rdev-flags)) {
-   unsigned long flags;
-   spin_lock_irqsave(conf-device_lock, flags);
mddev-degraded++;
set_bit(Faulty, rdev-flags);
-   spin_unlock_irqrestore(conf-device_lock, flags);
} else
set_bit(Faulty, rdev-flags);
+   spin_unlock_irqrestore(conf-device_lock, flags);
/*
 * if recovery is running, make sure it aborts.
 */
@@ -1466,7 +1466,10 @@ static int raid1_spare_active(struct mddev *mddev)
 * Find all failed disks within the RAID1 configuration 
 * and mark them readable.
 * Called under mddev lock, so rcu protection not needed.
+* device_lock used to avoid races with raid1_end_read_request
+* which expects 'In_sync' flags and -degraded to be consistent.
 */
+   spin_lock_irqsave(conf-device_lock, flags);
for (i = 0; i  conf-raid_disks; i++) {
struct md_rdev *rdev = conf-mirrors[i].rdev;
struct md_rdev *repl = conf-mirrors[conf-raid_disks + i].rdev;
@@ -1496,7 +1499,6 @@ static int raid1_spare_active(struct mddev *mddev)
sysfs_notify_dirent_safe(rdev-sysfs_state);
}
}
-   spin_lock_irqsave(conf-device_lock, flags);
mddev-degraded -= count;
spin_unlock_irqrestore(conf-device_lock, flags);
 
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 58/82] x86/nmi/64: Remove asm code that saves CR2

[Jiri Slaby]

From: Andy Lutomirski l...@kernel.org

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 0e181bb58143cb4a2e8f01c281b0816cd0e4798e upstream.

Now that do_nmi saves CR2, we don't need to save it in asm.

Signed-off-by: Andy Lutomirski l...@kernel.org
Reviewed-by: Steven Rostedt rost...@goodmis.org
Acked-by: Borislav Petkov b...@suse.de
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 arch/x86/kernel/entry_64.S | 18 --
 1 file changed, 18 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 7b22af265d12..fd27e5b86d7b 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1876,29 +1876,11 @@ end_repeat_nmi:
call save_paranoid
DEFAULT_FRAME 0
 
-   /*
-* Save off the CR2 register. If we take a page fault in the NMI then
-* it could corrupt the CR2 value. If the NMI preempts a page fault
-* handler before it was able to read the CR2 register, and then the
-* NMI itself takes a page fault, the page fault that was preempted
-* will read the information from the NMI page fault and not the
-* origin fault. Save it off and restore it if it changes.
-* Use the r12 callee-saved register.
-*/
-   movq %cr2, %r12
-
/* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
movq %rsp,%rdi
movq $-1,%rsi
call do_nmi
 
-   /* Did the NMI take a page fault? Restore cr2 if it did */
-   movq %cr2, %rcx
-   cmpq %rcx, %r12
-   je 1f
-   movq %r12, %cr2
-1:
-   
testl %ebx,%ebx /* swapgs needed? */
jnz nmi_restore
 nmi_swapgs:
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 54/82] ipc: modify message queue accounting to not take kernel data structures into account

[Jiri Slaby]

From: Marcus Gelderie redm...@gmail.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit de54b9ac253787c366bbfb28d901a31954eb3511 upstream.

A while back, the message queue implementation in the kernel was
improved to use btrees to speed up retrieval of messages, in commit
d6629859b36d (ipc/mqueue: improve performance of send/recv).

That patch introducing the improved kernel handling of message queues
(using btrees) has, as a by-product, changed the meaning of the QSIZE
field in the pseudo-file created for the queue.  Before, this field
reflected the size of the user-data in the queue.  Since, it also takes
kernel data structures into account.  For example, if 13 bytes of user
data are in the queue, on my machine the file reports a size of 61
bytes.

There was some discussion on this topic before (for example
https://lkml.org/lkml/2014/10/1/115).  Commenting on a th lkml, Michael
Kerrisk gave the following background
(https://lkml.org/lkml/2015/6/16/74):

The pseudofiles in the mqueue filesystem (usually mounted at
/dev/mqueue) expose fields with metadata describing a message
queue. One of these fields, QSIZE, as originally implemented,
showed the total number of bytes of user data in all messages in
the message queue, and this feature was documented from the
beginning in the mq_overview(7) page. In 3.5, some other (useful)
work happened to break the user-space API in a couple of places,
including the value exposed via QSIZE, which now includes a measure
of kernel overhead bytes for the queue, a figure that renders QSIZE
useless for its original purpose, since there's no way to deduce
the number of overhead bytes consumed by the implementation.
(The other user-space breakage was subsequently fixed.)

This patch removes the accounting of kernel data structures in the
queue.  Reporting the size of these data-structures in the QSIZE field
was a breaking change (see Michael's comment above).  Without the QSIZE
field reporting the total size of user-data in the queue, there is no
way to deduce this number.

It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
against the worst-case size of the queue (in both the old and the new
implementation).  Therefore, the kernel overhead accounting in QSIZE is
not necessary to help the user understand the limitations RLIMIT imposes
on the processes.

Signed-off-by: Marcus Gelderie redm...@gmail.com
Acked-by: Doug Ledford dledf...@redhat.com
Acked-by: Michael Kerrisk mtk.manpa...@gmail.com
Acked-by: Davidlohr Bueso dbu...@suse.de
Cc: David Howells dhowe...@redhat.com
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: John Duffy jb_du...@btinternet.com
Cc: Arto Bendiken a...@bendiken.net
Cc: Manfred Spraul manf...@colorfullife.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 ipc/mqueue.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index bb0248fc5187..82bb5e81ef57 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -143,7 +143,6 @@ static int msg_insert(struct msg_msg *msg, struct 
mqueue_inode_info *info)
if (!leaf)
return -ENOMEM;
INIT_LIST_HEAD(leaf-msg_list);
-   info-qsize += sizeof(*leaf);
}
leaf-priority = msg-m_type;
rb_link_node(leaf-rb_node, parent, p);
@@ -188,7 +187,6 @@ try_again:
 lazy leaf delete!\n);
rb_erase(leaf-rb_node, info-msg_tree);
if (info-node_cache) {
-   info-qsize -= sizeof(*leaf);
kfree(leaf);
} else {
info-node_cache = leaf;
@@ -201,7 +199,6 @@ try_again:
if (list_empty(leaf-msg_list)) {
rb_erase(leaf-rb_node, info-msg_tree);
if (info-node_cache) {
-   info-qsize -= sizeof(*leaf);
kfree(leaf);
} else {
info-node_cache = leaf;
@@ -1026,7 +1023,6 @@ SYSCALL_DEFINE5(mq_timedsend, mqd_t, mqdes, const char 
__user *, u_msg_ptr,
/* Save our speculative allocation into the cache */
INIT_LIST_HEAD(new_leaf-msg_list);
info-node_cache = new_leaf;
-   info-qsize += sizeof(*new_leaf);
new_leaf = NULL;
} else {
kfree(new_leaf);
@@ -1133,7 +1129,6 @@ SYSCALL_DEFINE5(mq_timedreceive, mqd_t, mqdes, char 
__user *, u_msg_ptr,
/* Save our speculative allocation into the cache */
INIT_LIST_HEAD(new_leaf-msg_list);
info-node_cache = new_leaf;
-   info-qsize += sizeof(*new_leaf);
} else {
kfree(new_leaf);
}

[PATCH 3.12 55/82] ocfs2: fix BUG in ocfs2_downconvert_thread_do_work()

[Jiri Slaby]

From: Joseph Qi joseph...@huawei.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 209f7512d007980fd111a74a064d70a3656079cf upstream.

The BUG_ON(list_empty(osb-blocked_lock_list)) in
ocfs2_downconvert_thread_do_work can be triggered in the following case:

ocfs2dc has firstly saved osb-blocked_lock_count to local varibale
processed, and then processes the dentry lockres.  During the dentry
put, it calls iput and then deletes rw, inode and open lockres from
blocked list in ocfs2_mark_lockres_freeing.  And this causes the
variable `processed' to not reflect the number of blocked lockres to be
processed, which triggers the BUG.

Signed-off-by: Joseph Qi joseph...@huawei.com
Cc: Mark Fasheh mfas...@suse.com
Cc: Joel Becker jl...@evilplan.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 fs/ocfs2/dlmglue.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 3988d0aeb72c..416a2ab68ac1 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -4009,9 +4009,13 @@ static void ocfs2_downconvert_thread_do_work(struct 
ocfs2_super *osb)
osb-dc_work_sequence = osb-dc_wake_sequence;
 
processed = osb-blocked_lock_count;
-   while (processed) {
-   BUG_ON(list_empty(osb-blocked_lock_list));
-
+   /*
+* blocked lock processing in this loop might call iput which can
+* remove items off osb-blocked_lock_list. Downconvert up to
+* 'processed' number of locks, but stop short if we had some
+* removed in ocfs2_mark_lockres_freeing when downconverting.
+*/
+   while (processed  !list_empty(osb-blocked_lock_list)) {
lockres = list_entry(osb-blocked_lock_list.next,
 struct ocfs2_lock_res, l_blocked_list);
list_del_init(lockres-l_blocked_list);
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage

[Vinod Koul]

On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote:
 
 On 23/08/15 15:17, Vinod Koul wrote:
  On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote:
  
  @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
 int ret;
   
 /* Enable clock before accessing register */
  -  ret = tegra_dma_runtime_resume(dev);
  +  ret = pm_runtime_get_sync(dev);
  
  why is this required ?
 
 Because the clock could be disabled when this function is called. This
 function saves the DMA context so that if the context is lost during
 suspend, it can be restored.

Have you verified this? Coz my understanding is that when PM does suspend it
will esnure you are runtime resume if runtime suspended and then will do
suspend.
So you do not need to do above

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 51/82] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

[Jiri Slaby]

From: Roger Quadros rog...@ti.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 9a258afa928b45e6dd2efcac46ccf7eea705d35a upstream.

For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
_find_mpu_rt_port(oh) will return NULL thus preventing ready state check
on those modules after the module is enabled.

This can potentially cause a bus access error if the module is accessed
before the module is ready.

Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
_init(). Do ioremap only if we need SYSC access.

Eventhough _wait_target_ready() check doesn't really need MPU RT port but
just the PRCM registers, we still mandate that the hwmod must have an
MPU RT port if ready state check needs to be done. Else it would mean that
the module is not accessible by MPU so there is no point in waiting
for target to be ready.

e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.

[   16.672978] [ cut here ]
[   16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x234/0x35c()
[   16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 
(Read): Data Access in User mode during Functional access
[   16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core 
ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio 
c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts 
c_can dc
[   16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 
3.14.26-02561-gf733aa036398 #180
[   16.739747] Backtrace:
[   16.742336] [c0011108] (dump_backtrace) from [c00112a4] 
(show_stack+0x18/0x1c)
[   16.750285]  r6:0093 r5:0009 r4:eab5b8a8 r3:
[   16.756252] [c001128c] (show_stack) from [c05a4418] 
(dump_stack+0x20/0x28)
[   16.763870] [c05a43f8] (dump_stack) from [c0037120] 
(warn_slowpath_common+0x6c/0x8c)
[   16.772408] [c00370b4] (warn_slowpath_common) from [c00371e4] 
(warn_slowpath_fmt+0x38/0x40)
[   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
[   16.788626] [c00371b0] (warn_slowpath_fmt) from [c027fa94] 
(l3_interrupt_handler+0x234/0x35c)
[   16.797968]  r3:ed0cd480 r2:c0730508
[   16.801747] [c027f860] (l3_interrupt_handler) from [c0063758] 
(handle_irq_event_percpu+0x54/0x1bc)
[   16.811533]  r10:ed005600 r9:c084855b r8:002a r7: r6: 
r5:002a
[   16.819780]  r4:ed0e6d80
[   16.822453] [c0063704] (handle_irq_event_percpu) from [c00638f0] 
(handle_irq_event+0x30/0x40)
[   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: 
r5:002a
[   16.840052]  r4:ed005600
[   16.842744] [c00638c0] (handle_irq_event) from [c00661d8] 
(handle_fasteoi_irq+0x74/0x128)
[   16.851702]  r4:ed005600 r3:
[   16.855479] [c0066164] (handle_fasteoi_irq) from [c0063068] 
(generic_handle_irq+0x28/0x38)
[   16.864523]  r4:002a r3:c0066164
[   16.868294] [c0063040] (generic_handle_irq) from [c000ef60] 
(handle_IRQ+0x38/0x8c)
[   16.876612]  r4:c081c640 r3:0202
[   16.880380] [c000ef28] (handle_IRQ) from [c00084f0] 
(gic_handle_irq+0x30/0x5c)
[   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100
[   16.894303] [c00084c0] (gic_handle_irq) from [c05a8d80] 
(__irq_svc+0x40/0x50)
[   16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
[   16.907499] ba20:   
 0006
[   16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 
bf011420 eb2b6960
[   16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 
600f0013 
[   16.933317]  r7:eab5ba6c r6: r5:600f0013 r4:bf07702c
[   16.939317] [bf077000] (c_can_plat_read_reg_aligned_to_16bit 
[c_can_platform]) from [bf035220] (c_can_get_berr_counter+0x38/0x64 [c_can])
[   16.952696] [bf0351e8] (c_can_get_berr_counter [c_can]) from [bf010294] 
(can_fill_info+0x124/0x15c [can_dev])
[   16.963480]  r5:ec8c9740 r4:ed3d3000
[   16.967253] [bf010170] (can_fill_info [can_dev]) from [c0502fa8] 
(rtnl_fill_ifinfo+0x58c/0x8fc)
[   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
[   16.981613] [c0502a1c] (rtnl_fill_ifinfo) from [c0503408] 
(rtnl_dump_ifinfo+0xf0/0x1dc)
[   16.990401]  r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 
r5:ed3d3000
[   16.998671]  r4:
[   17.001342] [c0503318] (rtnl_dump_ifinfo) from [c050e6e4] 
(netlink_dump+0xa8/0x1e0)
[   17.009772]  r10: r9: r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 
r5:ec8c9740
[   17.018050]  r4:ebd4d000
[   17.020714] [c050e63c] (netlink_dump) from [c050ec10] 
(__netlink_dump_start+0x104/0x154)
[   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
[   17.034454] [c050eb0c] (__netlink_dump_start) from [c0505604] 
(rtnetlink_rcv_msg+0x110/0x1f4)
[   17.043778]  r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0
[   17.049743] [c05054f4] (rtnetlink_rcv_msg) from [c05108e8] 
(netlink_rcv_skb+0xb4/0xc8)
[   

Re: [RFC PATCH 7/7] DMA: tegra-adma: Add support for Tegra210 ADMA

[Vinod Koul]

On Mon, Aug 24, 2015 at 09:55:03AM +0100, Jon Hunter wrote:
  +static int tegra_adma_get_xfer_params(struct tegra_dma_channel *tdc,
  +struct tegra_adma_chan_regs *ch_regs,
  +enum dma_transfer_direction direction)
  +{
  +  u32 burst_size, ctrl, ctrl_mask, slave_id, fifo_mask, fifo_shift;
  +
  +  ch_regs-ahub_fifo_ctrl = tdc_read(tdc, ADMA_CH_AHUB_FIFO_CTRL);
  +  ch_regs-config = tdc_read(tdc, ADMA_CH_CONFIG);
  +  ch_regs-ctrl = tdc_read(tdc, ADMA_CH_CTRL);
  +  slave_id = tdc-dma_sconfig.slave_id;
  +
  +  switch (direction) {
  +  case DMA_MEM_TO_DEV:
  +  burst_size = fls(tdc-dma_sconfig.dst_maxburst);
  +  ctrl_mask = ADMA_CH_CTRL_TX_REQUEST_SELECT_MASK;
  +  ctrl = MEMORY_TO_AHUB  ADMA_CH_CTRL_TRANSFER_DIRECTION_SHIFT;
  +  ctrl |= slave_id  ADMA_CH_CTRL_TX_REQUEST_SELECT_SHIFT;
  +  fifo_mask = ADMA_CH_AHUB_FIFO_CTRL_TX_FIFO_SIZE_MASK;
  +  fifo_shift = ADMA_CH_AHUB_FIFO_CTRL_TX_FIFO_SIZE_SHIFT;
  +  break;
  Empty line here pls
 
 Ok, any reason why? Other dma drivers don't appear to do this.

This improves readablity. It is a good idea to sprinkle empty lines between
logial blocks

  +static int tegra_adma_pm_suspend(struct device *dev)
  +{
  +  struct tegra_dma *tdma = dev_get_drvdata(dev);
  +  int i;
  +  int ret;
  +
  +  ret = pm_runtime_get_sync(dev);
  why is this required :)
 
 To ensure that the clocks are enabled before the registers are read.
 This function saves the dma context before suspend, in case the hardware
 state is lost.
I think same reason here too, so based on my other argument, this may not be
required!

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 48/82] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

[Jiri Slaby]

From: Andy Lutomirski l...@kernel.org

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski l...@kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: David Vrabel dvra...@cantab.net
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-de...@lists.xen.org
Link: 
http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 arch/x86/xen/enlighten.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index fa6ade76ef3f..2cbc2f2cf43e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -480,6 +480,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte_t pte;
unsigned long pfn;
struct page *page;
+   unsigned char dummy;
 
ptep = lookup_address((unsigned long)v, level);
BUG_ON(ptep == NULL);
@@ -489,6 +490,32 @@ static void set_aliased_prot(void *v, pgprot_t prot)
 
pte = pfn_pte(pfn, prot);
 
+   /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables.  We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space.  In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall.  We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution, this uses __get_user() to fault
+* in the target address just in case there's some obscure case
+* in which the target address isn't readable.
+*/
+
+   preempt_disable();
+
+   pagefault_disable();/* Avoid warnings due to being atomic. */
+   __get_user(dummy, (unsigned char __user __force *)v);
+   pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
 
@@ -500,6 +527,8 @@ static void set_aliased_prot(void *v, pgprot_t prot)
BUG();
} else
kmap_flush_unused();
+
+   preempt_enable();
 }
 
 static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -507,6 +536,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, 
unsigned entries)
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
 
+   /*
+* We need to mark the all aliases of the LDT pages RO.  We
+* don't need to call vm_flush_aliases(), though, since that's
+* only responsible for flushing aliases out the TLBs, not the
+* page tables, and Xen will flush the TLB for us if needed.
+*
+* To avoid confusing future readers: none of this is necessary
+* to load the LDT.  The hypervisor only checks this when the
+* LDT is faulted in due to subsequent descriptor access.
+*/
+
for(i = 0; i  entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL_RO);
 }
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] memhp: Add hot-added memory ranges to memblock before allocate node_data for a node.

[Xishi Qiu]

On 2015/8/24 1:06, Tang Chen wrote:

 The commit below adds hot-added memory range to memblock, after
 creating pgdat for new node.
 
 commit f9126ab9241f66562debf69c2c9d8fee32ddcc53
 Author: Xishi Qiu qiuxi...@huawei.com
 Date:   Fri Aug 14 15:35:16 2015 -0700
 
 memory-hotplug: fix wrong edge when hot add a new node
 
 But there is a problem:
 
 add_memory()
 |-- hotadd_new_pgdat()
  |-- free_area_init_node()
   |-- get_pfn_range_for_nid()
|-- find start_pfn and end_pfn in memblock
 |-- ..
 |-- memblock_add_node(start, size, nid)Here, just too late.
 
 get_pfn_range_for_nid() will find that start_pfn and end_pfn are both 0.
 As a result, when adding memory, dmesg will give the following wrong message.
 
 [ 2007.577000] Initmem setup node 5 [mem 
 0x-0x]
 [ 2007.584000] On node 5 totalpages: 0
 [ 2007.585000] Built 5 zonelists in Node order, mobility grouping on.  Total 
 pages: 32588823
 [ 2007.594000] Policy zone: Normal
 [ 2007.598000] init_memory_mapping: [mem 0x600-0x607]
 
 The solution is simple, just add the memory range to memblock a little 
 earlier,
 before hotadd_new_pgdat().
 
 Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
 ---
  mm/memory_hotplug.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
 index 6da82bc..9b78aff 100644
 --- a/mm/memory_hotplug.c
 +++ b/mm/memory_hotplug.c
 @@ -1248,6 +1248,14 @@ int __ref add_memory(int nid, u64 start, u64 size)
  
   mem_hotplug_begin();
  
 + /*
 +  * Add new range to memblock so that when hotadd_new_pgdat() is called 
 to
 +  * allocate new pgdat, get_pfn_range_for_nid() will be able to find this
 +  * new range and calculate total pages correctly. The range will be 
 remove
 +  * at hot-remove time.
 +  */
 + memblock_add_node(start, size, nid);
 +

Hi Tang,

Looks fine to me.

If we add memblock_add_node() here, we should reset the managed pages and 
present pages,
so please revert my patch which Andrew has already merged into mm-tree.
[PATCH 2/2] memory-hotplug: remove reset_node_managed_pages() and 
reset_node_managed_pages() in hotadd_new_pgdat()

Thanks,
Xishi Qiu

   new_node = !node_online(nid);
   if (new_node) {
   pgdat = hotadd_new_pgdat(nid, start);
 @@ -1277,7 +1285,6 @@ int __ref add_memory(int nid, u64 start, u64 size)
  
   /* create new memmap entry */
   firmware_map_add_hotplug(start, start + size, System RAM);
 - memblock_add_node(start, size, nid);
  
   goto out;
  
 @@ -1286,6 +1293,7 @@ error:
   if (new_pgdat)
   rollback_node_hotadd(nid, pgdat);
   release_memory_resource(res);
 + memblock_remove(start, size);
  
  out:
   mem_hotplug_done();



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] dmaengine: hdmac: Add memset capabilities

[Maxime Ripard]

Just like for the XDMAC, the SoCs that embed the HDMAC don't have any kind
of GPU, and need to accelerate a few framebuffer-related operations through
their DMA controller.

However, unlike the XDMAC, the HDMAC doesn't have the memset capability
built-in. That can be easily emulated though, by doing a transfer with a
fixed address on the variable that holds the value we want to set.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com

---
Changes from v2:
  - Rebased on top Cyril's patch

Changes from v1:
  - Replaced the dma_alloc_coherent calls by a dma_pool
---
 drivers/dma/at_hdmac.c  | 121 ++--
 drivers/dma/at_hdmac_regs.h |   6 +++
 2 files changed, 124 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 1459c9f3165f..58d406230d89 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -448,6 +448,7 @@ static void
 atc_chain_complete(struct at_dma_chan *atchan, struct at_desc *desc)
 {
struct dma_async_tx_descriptor  *txd = desc-txd;
+   struct at_dma   *atdma = 
to_at_dma(atchan-chan_common.device);
 
dev_vdbg(chan2dev(atchan-chan_common),
descriptor %u complete\n, txd-cookie);
@@ -456,6 +457,13 @@ atc_chain_complete(struct at_dma_chan *atchan, struct 
at_desc *desc)
if (!atc_chan_is_cyclic(atchan))
dma_cookie_complete(txd);
 
+   /* If the transfer was a memset, free our temporary buffer */
+   if (desc-memset) {
+   dma_pool_free(atdma-memset_pool, desc-memset_vaddr,
+ desc-memset_paddr);
+   desc-memset = false;
+   }
+
/* move children to free_list */
list_splice_init(desc-tx_list, atchan-free_list);
/* move myself to free_list */
@@ -873,6 +881,93 @@ err_desc_get:
return NULL;
 }
 
+/**
+ * atc_prep_dma_memset - prepare a memcpy operation
+ * @chan: the channel to prepare operation on
+ * @dest: operation virtual destination address
+ * @value: value to set memory buffer to
+ * @len: operation length
+ * @flags: tx descriptor status flags
+ */
+static struct dma_async_tx_descriptor *
+atc_prep_dma_memset(struct dma_chan *chan, dma_addr_t dest, int value,
+   size_t len, unsigned long flags)
+{
+   struct at_dma_chan  *atchan = to_at_dma_chan(chan);
+   struct at_dma   *atdma = to_at_dma(chan-device);
+   struct at_desc  *desc = NULL;
+   size_t  xfer_count;
+   u32 ctrla;
+   u32 ctrlb;
+
+   dev_vdbg(chan2dev(chan), %s: d0x%x v0x%x l0x%zx f0x%lx\n, __func__,
+   dest, value, len, flags);
+
+   if (unlikely(!len)) {
+   dev_dbg(chan2dev(chan), %s: length is zero!\n, __func__);
+   return NULL;
+   }
+
+   if (!is_dma_fill_aligned(chan-device, dest, 0, len)) {
+   dev_dbg(chan2dev(chan), %s: buffer is not aligned\n,
+   __func__);
+   return NULL;
+   }
+
+   xfer_count = len  2;
+   if (xfer_count  ATC_BTSIZE_MAX) {
+   dev_err(chan2dev(chan), %s: buffer is too big\n,
+   __func__);
+   return NULL;
+   }
+
+   ctrlb =   ATC_DEFAULT_CTRLB | ATC_IEN
+   | ATC_SRC_ADDR_MODE_FIXED
+   | ATC_DST_ADDR_MODE_INCR
+   | ATC_FC_MEM2MEM;
+
+   ctrla = ATC_SRC_WIDTH(2) |
+   ATC_DST_WIDTH(2);
+
+   desc = atc_desc_get(atchan);
+   if (!desc) {
+   dev_err(chan2dev(chan), %s: can't get a descriptor\n,
+   __func__);
+   return NULL;
+   }
+
+   desc-memset_vaddr = dma_pool_alloc(atdma-memset_pool, GFP_ATOMIC,
+   desc-memset_paddr);
+   if (!desc-memset_vaddr) {
+   dev_err(chan2dev(chan), %s: couldn't allocate buffer\n,
+   __func__);
+   goto err_put_desc;
+   }
+
+   *desc-memset_vaddr = value;
+   desc-memset = true;
+
+   desc-lli.saddr = desc-memset_paddr;
+   desc-lli.daddr = dest;
+   desc-lli.ctrla = ctrla | xfer_count;
+   desc-lli.ctrlb = ctrlb;
+
+   desc-txd.cookie = -EBUSY;
+   desc-len = len;
+   desc-total_len = len;
+
+   /* set end-of-link on the descriptor */
+   set_desc_eol(desc);
+
+   desc-txd.flags = flags;
+
+   return desc-txd;
+
+err_put_desc:
+   atc_desc_put(atchan, desc);
+   return NULL;
+}
+
 
 /**
  * atc_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
@@ -1755,6 +1850,8 @@ static int __init at_dma_probe(struct platform_device 
*pdev)
dma_cap_set(DMA_SG, at91sam9rl_config.cap_mask);
dma_cap_set(DMA_INTERLEAVE, at91sam9g45_config.cap_mask);
dma_cap_set(DMA_MEMCPY, at91sam9g45_config.cap_mask);
+   dma_cap_set(DMA_MEMSET, 

[PATCH 3.12 49/82] xen/gntdevt: Fix race condition in gntdev_release()

[Jiri Slaby]

From: Marek Marczykowski-Górecki marma...@invisiblethingslab.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

While gntdev_release() is called the MMU notifier is still registered
and can traverse priv-maps list even if no pages are mapped (which is
the case -- gntdev_release() is called after all). But
gntdev_release() will clear that list, so make sure that only one of
those things happens at the same time.

Signed-off-by: Marek Marczykowski-Górecki marma...@invisiblethingslab.com
Signed-off-by: David Vrabel david.vra...@citrix.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/xen/gntdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index e41c79c986ea..f2ca8d0af55f 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -529,12 +529,14 @@ static int gntdev_release(struct inode *inode, struct 
file *flip)
 
pr_debug(priv %p\n, priv);
 
+   mutex_lock(priv-lock);
while (!list_empty(priv-maps)) {
map = list_entry(priv-maps.next, struct grant_map, next);
list_del(map-next);
gntdev_put_map(NULL /* already removed */, map);
}
WARN_ON(!list_empty(priv-freeable_maps));
+   mutex_unlock(priv-lock);
 
if (use_ptemod)
mmu_notifier_unregister(priv-mn, priv-mm);
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 52/82] iscsi-target: Fix iscsit_start_kthreads failure OOPs

[Jiri Slaby]

From: Nicholas Bellinger n...@linux-iscsi.org

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit e54198657b65625085834847ab6271087323ffea upstream.

This patch fixes a regression introduced with the following commit
in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers
a NULL pointer dereference OOPs:

commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
Author: Nicholas Bellinger n...@linux-iscsi.org
Date:   Thu Feb 26 22:19:15 2015 -0800

iscsi-target: Convert iscsi_thread_set usage to kthread.h

To address this bug, move iscsit_start_kthreads() immediately
preceeding the transmit of last login response, before signaling
a successful transition into full-feature-phase within existing
iscsi_target_do_tx_login_io() logic.

This ensures that no target-side resource allocation failures can
occur after the final login response has been successfully sent.

Also, it adds a iscsi_conn-rx_login_comp to allow the RX thread
to sleep to prevent other socket related failures until the final
iscsi_post_login_handler() call is able to complete.

Cc: Sagi Grimberg sa...@mellanox.com
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Signed-off-by: Nicholas Bellinger n...@daterainc.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/target/iscsi/iscsi_target.c   | 18 ++---
 drivers/target/iscsi/iscsi_target_core.h  |  1 +
 drivers/target/iscsi/iscsi_target_login.c | 43 ---
 drivers/target/iscsi/iscsi_target_login.h |  3 ++-
 drivers/target/iscsi/iscsi_target_nego.c  | 34 +++-
 5 files changed, 67 insertions(+), 32 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target.c 
b/drivers/target/iscsi/iscsi_target.c
index 60e06fb049ef..6f3aa50699f1 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -3933,7 +3933,13 @@ get_immediate:
}
 
 transport_err:
-   iscsit_take_action_for_connection_exit(conn);
+   /*
+* Avoid the normal connection failure code-path if this connection
+* is still within LOGIN mode, and iscsi_np process context is
+* responsible for cleaning up the early connection failure.
+*/
+   if (conn-conn_state != TARG_CONN_STATE_IN_LOGIN)
+   iscsit_take_action_for_connection_exit(conn);
 out:
return 0;
 }
@@ -4019,7 +4025,7 @@ reject:
 
 int iscsi_target_rx_thread(void *arg)
 {
-   int ret;
+   int ret, rc;
u8 buffer[ISCSI_HDR_LEN], opcode;
u32 checksum = 0, digest = 0;
struct iscsi_conn *conn = arg;
@@ -4029,10 +4035,16 @@ int iscsi_target_rx_thread(void *arg)
 * connection recovery / failure event can be triggered externally.
 */
allow_signal(SIGINT);
+   /*
+* Wait for iscsi_post_login_handler() to complete before allowing
+* incoming iscsi/tcp socket I/O, and/or failing the connection.
+*/
+   rc = wait_for_completion_interruptible(conn-rx_login_comp);
+   if (rc  0)
+   return 0;
 
if (conn-conn_transport-transport_type == ISCSI_INFINIBAND) {
struct completion comp;
-   int rc;
 
init_completion(comp);
rc = wait_for_completion_interruptible(comp);
diff --git a/drivers/target/iscsi/iscsi_target_core.h 
b/drivers/target/iscsi/iscsi_target_core.h
index 1c232c509dae..cc0cb60eb7bd 100644
--- a/drivers/target/iscsi/iscsi_target_core.h
+++ b/drivers/target/iscsi/iscsi_target_core.h
@@ -604,6 +604,7 @@ struct iscsi_conn {
int bitmap_id;
int rx_thread_active;
struct task_struct  *rx_thread;
+   struct completion   rx_login_comp;
int tx_thread_active;
struct task_struct  *tx_thread;
/* list_head for session connection list */
diff --git a/drivers/target/iscsi/iscsi_target_login.c 
b/drivers/target/iscsi/iscsi_target_login.c
index 9d5762011413..899b756fe290 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -83,6 +83,7 @@ static struct iscsi_login *iscsi_login_init_conn(struct 
iscsi_conn *conn)
init_completion(conn-conn_logout_comp);
init_completion(conn-rx_half_close_comp);
init_completion(conn-tx_half_close_comp);
+   init_completion(conn-rx_login_comp);
spin_lock_init(conn-cmd_lock);
spin_lock_init(conn-conn_usage_lock);
spin_lock_init(conn-immed_queue_lock);
@@ -717,6 +718,7 @@ int iscsit_start_kthreads(struct iscsi_conn *conn)
 
return 0;
 out_tx:
+   send_sig(SIGINT, conn-tx_thread, 1);
kthread_stop(conn-tx_thread);
conn-tx_thread_active = false;
 out_bitmap:
@@ -727,7 +729,7 @@ out_bitmap:
return ret;
 }
 
-int iscsi_post_login_handler(
+void iscsi_post_login_handler(
struct iscsi_np *np,
struct 

[PATCH 3.12 07/82] ARC: make sure instruction_pointer() returns unsigned value

[Jiri Slaby]

From: Alexey Brodkin abrod...@synopsys.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit f51e2f1911122879eefefa4c592dea8bf794b39c upstream.

Currently instruction_pointer() returns pt_regs-ret and so return value
is of type long, which implicitly stands for signed long.

While that's perfectly fine when dealing with 32-bit values if return
value of instruction_pointer() gets assigned to 64-bit variable sign
extension may happen.

And at least in one real use-case it happens already.
In perf_prepare_sample() return value of perf_instruction_pointer()
(which is an alias to instruction_pointer() in case of ARC) is assigned
to (struct perf_sample_data)-ip (which type is u64).

And what we see if instuction pointer points to user-space application
that in case of ARC lays below 0x8000_ ip gets set properly with
leading 32 zeros. But if instruction pointer points to kernel address
space that starts from 0x8000_ then ip is set with 32 leadig
f-s. I.e. id instruction_pointer() returns 0x8100_, ip will be
assigned with 0x___8100_. Which is obviously wrong.

In particular that issuse broke output of perf, because perf was unable
to associate addresses like 0x___8100_ with anything from
/proc/kallsyms.

That's what we used to see:
 ---8--
  6.27%  ls   [unknown][k] 0x8046c5cc
  2.96%  ls   libuClibc-0.9.34-git.so  [.] memcpy
  2.25%  ls   libuClibc-0.9.34-git.so  [.] memset
  1.66%  ls   [unknown][k] 0x80666536
  1.54%  ls   libuClibc-0.9.34-git.so  [.] 0x000224d6
  1.18%  ls   libuClibc-0.9.34-git.so  [.] 0x00022472
 ---8--

With that change perf output looks much better now:
 ---8--
  8.21%  ls   [kernel.kallsyms][k] memset
  3.52%  ls   libuClibc-0.9.34-git.so  [.] memcpy
  2.11%  ls   libuClibc-0.9.34-git.so  [.] malloc
  1.88%  ls   libuClibc-0.9.34-git.so  [.] memset
  1.64%  ls   [kernel.kallsyms][k] _raw_spin_unlock_irqrestore
  1.41%  ls   [kernel.kallsyms][k] __d_lookup_rcu
 ---8--

Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: arc-linux-...@synopsys.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta vgu...@synopsys.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 arch/arc/include/asm/ptrace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 1bfeec2c0558..2a58af7a2e3a 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -63,7 +63,7 @@ struct callee_regs {
long r25, r24, r23, r22, r21, r20, r19, r18, r17, r16, r15, r14, r13;
 };
 
-#define instruction_pointer(regs)  ((regs)-ret)
+#define instruction_pointer(regs)  (unsigned long)((regs)-ret)
 #define profile_pc(regs)   instruction_pointer(regs)
 
 /* return 1 if user mode or 0 if kernel mode */
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 32/82] ARM: realview: fix sparsemem build

[Jiri Slaby]

From: Arnd Bergmann a...@arndb.de

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit dd94d3558947756b102b1487911acd925224a38c upstream.

Commit b713aa0b15 ARM: fix asm/memory.h build error broke some
configurations on mach-realview with sparsemem enabled, which
is missing a definition of PHYS_OFFSET:

arch/arm/include/asm/memory.h:268:42: error: 'PHYS_OFFSET' undeclared (first 
use in this function)
 #define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET  PAGE_SHIFT))
arch/arm/include/asm/dma-mapping.h:104:9: note: in expansion of macro 
'PHYS_PFN_OFFSET'
  return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev-dma_mask);

An easy workaround is for realview to define PHYS_OFFSET itself,
in the same way we define it for platforms that don't have a private
__virt_to_phys function.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Russell King li...@arm.linux.org.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Guenter Roeck li...@roeck-us.net
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 arch/arm/mach-realview/include/mach/memory.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-realview/include/mach/memory.h 
b/arch/arm/mach-realview/include/mach/memory.h
index 2022e092f0ca..db09170e3832 100644
--- a/arch/arm/mach-realview/include/mach/memory.h
+++ b/arch/arm/mach-realview/include/mach/memory.h
@@ -56,6 +56,8 @@
 #define PAGE_OFFSET1   (PAGE_OFFSET + 0x1000)
 #define PAGE_OFFSET2   (PAGE_OFFSET + 0x3000)
 
+#define PHYS_OFFSET PLAT_PHYS_OFFSET
+
 #define __phys_to_virt(phys)   \
((phys) = 0x8000 ? (phys) - 0x8000 + PAGE_OFFSET2 :\
 (phys) = 0x2000 ? (phys) - 0x2000 + PAGE_OFFSET1 :\
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 37/82] ipr: Fix locking for unit attention handling

[Jiri Slaby]

From: Brian King brk...@linux.vnet.ibm.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 36b8e180e1e929e00b351c3b72aab3147fc14116 upstream.

Make sure we have the host lock held when calling scsi_report_bus_reset. Fixes
a crash seen as the __devices list in the scsi host was changing as we were
iterating through it.

Reviewed-by: Wen Xiong wenxi...@linux.vnet.ibm.com
Reviewed-by: Gabriel Krisman Bertazi kris...@linux.vnet.ibm.com
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
Reviewed-by: Martin K. Petersen martin.peter...@oracle.com
Signed-off-by: James Bottomley jbottom...@odin.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/scsi/ipr.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 5f841652886e..5f06ca46e187 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -6179,21 +6179,23 @@ static void ipr_scsi_done(struct ipr_cmnd *ipr_cmd)
struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
struct scsi_cmnd *scsi_cmd = ipr_cmd-scsi_cmd;
u32 ioasc = be32_to_cpu(ipr_cmd-s.ioasa.hdr.ioasc);
-   unsigned long hrrq_flags;
+   unsigned long lock_flags;
 
scsi_set_resid(scsi_cmd, 
be32_to_cpu(ipr_cmd-s.ioasa.hdr.residual_data_len));
 
if (likely(IPR_IOASC_SENSE_KEY(ioasc) == 0)) {
scsi_dma_unmap(scsi_cmd);
 
-   spin_lock_irqsave(ipr_cmd-hrrq-lock, hrrq_flags);
+   spin_lock_irqsave(ipr_cmd-hrrq-lock, lock_flags);
list_add_tail(ipr_cmd-queue, ipr_cmd-hrrq-hrrq_free_q);
scsi_cmd-scsi_done(scsi_cmd);
-   spin_unlock_irqrestore(ipr_cmd-hrrq-lock, hrrq_flags);
+   spin_unlock_irqrestore(ipr_cmd-hrrq-lock, lock_flags);
} else {
-   spin_lock_irqsave(ipr_cmd-hrrq-lock, hrrq_flags);
+   spin_lock_irqsave(ioa_cfg-host-host_lock, lock_flags);
+   spin_lock(ipr_cmd-hrrq-_lock);
ipr_erp_start(ioa_cfg, ipr_cmd);
-   spin_unlock_irqrestore(ipr_cmd-hrrq-lock, hrrq_flags);
+   spin_unlock(ipr_cmd-hrrq-_lock);
+   spin_unlock_irqrestore(ioa_cfg-host-host_lock, lock_flags);
}
 }
 
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 36/82] drm/radeon/combios: add some validation of lvds values

[Jiri Slaby]

From: Alex Deucher alexander.deuc...@amd.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 0a90a0cff9f429f886f423967ae053150dce9259 upstream.

Fixes a broken hsync start value uncovered by:
abc0b1447d4974963548777a5ba4a4457c82c426
(drm: Perform basic sanity checks on probed modes)

The driver handled the bad hsync start elsewhere, but
the above commit prevented it from getting added.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91401

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/gpu/drm/radeon/radeon_combios.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 68ce36056019..8cac69819054 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1271,10 +1271,15 @@ struct radeon_encoder_lvds 
*radeon_combios_get_lvds_info(struct radeon_encoder
 
if ((RBIOS16(tmp) == lvds-native_mode.hdisplay) 
(RBIOS16(tmp + 2) == lvds-native_mode.vdisplay)) {
+   u32 hss = (RBIOS16(tmp + 21) - RBIOS16(tmp + 
19) - 1) * 8;
+
+   if (hss  lvds-native_mode.hdisplay)
+   hss = (10 - 1) * 8;
+
lvds-native_mode.htotal = 
lvds-native_mode.hdisplay +
(RBIOS16(tmp + 17) - RBIOS16(tmp + 19)) 
* 8;
lvds-native_mode.hsync_start = 
lvds-native_mode.hdisplay +
-   (RBIOS16(tmp + 21) - RBIOS16(tmp + 19) 
- 1) * 8;
+   hss;
lvds-native_mode.hsync_end = 
lvds-native_mode.hsync_start +
(RBIOS8(tmp + 23) * 8);
 
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 35/82] fsnotify: fix oops in fsnotify_clear_marks_by_group_flags()

[Jiri Slaby]

From: Jan Kara j...@suse.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 8f2f3eb59dff4ec538de55f2e0592fec85966aab upstream.

fsnotify_clear_marks_by_group_flags() can race with
fsnotify_destroy_marks() so that when fsnotify_destroy_mark_locked()
drops mark_mutex, a mark from the list iterated by
fsnotify_clear_marks_by_group_flags() can be freed and thus the next
entry pointer we have cached may become stale and we dereference free
memory.

Fix the problem by first moving marks to free to a special private list
and then always free the first entry in the special list.  This method
is safe even when entries from the list can disappear once we drop the
lock.

Signed-off-by: Jan Kara j...@suse.com
Reported-by: Ashish Sangwan a.sang...@samsung.com
Reviewed-by: Ashish Sangwan a.sang...@samsung.com
Cc: Lino Sanfilippo linosanfili...@gmx.de
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 fs/notify/mark.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/fs/notify/mark.c b/fs/notify/mark.c
index 923fe4a5f503..6bffc3331df6 100644
--- a/fs/notify/mark.c
+++ b/fs/notify/mark.c
@@ -293,16 +293,36 @@ void fsnotify_clear_marks_by_group_flags(struct 
fsnotify_group *group,
 unsigned int flags)
 {
struct fsnotify_mark *lmark, *mark;
+   LIST_HEAD(to_free);
 
+   /*
+* We have to be really careful here. Anytime we drop mark_mutex, e.g.
+* fsnotify_clear_marks_by_inode() can come and free marks. Even in our
+* to_free list so we have to use mark_mutex even when accessing that
+* list. And freeing mark requires us to drop mark_mutex. So we can
+* reliably free only the first mark in the list. That's why we first
+* move marks to free to to_free list in one go and then free marks in
+* to_free list one by one.
+*/
mutex_lock_nested(group-mark_mutex, SINGLE_DEPTH_NESTING);
list_for_each_entry_safe(mark, lmark, group-marks_list, g_list) {
-   if (mark-flags  flags) {
-   fsnotify_get_mark(mark);
-   fsnotify_destroy_mark_locked(mark, group);
-   fsnotify_put_mark(mark);
-   }
+   if (mark-flags  flags)
+   list_move(mark-g_list, to_free);
}
mutex_unlock(group-mark_mutex);
+
+   while (1) {
+   mutex_lock_nested(group-mark_mutex, SINGLE_DEPTH_NESTING);
+   if (list_empty(to_free)) {
+   mutex_unlock(group-mark_mutex);
+   break;
+   }
+   mark = list_first_entry(to_free, struct fsnotify_mark, g_list);
+   fsnotify_get_mark(mark);
+   fsnotify_destroy_mark_locked(mark, group);
+   mutex_unlock(group-mark_mutex);
+   fsnotify_put_mark(mark);
+   }
 }
 
 /*
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 38/82] ipr: Fix incorrect trace indexing

[Jiri Slaby]

From: Brian King brk...@linux.vnet.ibm.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit bb7c54339e6a10ecce5c4961adf5e75b3cf0af30 upstream.

When ipr's internal driver trace was changed to an atomic, a signed/unsigned
bug slipped in which results in us indexing backwards in our memory buffer
writing on memory that does not belong to us. This patch fixes this by removing
the modulo and instead just mask off the low bits.

Tested-by: Wen Xiong wenxi...@linux.vnet.ibm.com
Reviewed-by: Wen Xiong wenxi...@linux.vnet.ibm.com
Reviewed-by: Gabriel Krisman Bertazi kris...@linux.vnet.ibm.com
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
Reviewed-by: Martin K. Petersen martin.peter...@oracle.com
Signed-off-by: James Bottomley jbottom...@odin.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/scsi/ipr.c | 5 +++--
 drivers/scsi/ipr.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 5f06ca46e187..fa55ad47cf65 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -592,9 +592,10 @@ static void ipr_trc_hook(struct ipr_cmnd *ipr_cmd,
 {
struct ipr_trace_entry *trace_entry;
struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
+   unsigned int trace_index;
 
-   trace_entry = ioa_cfg-trace[atomic_add_return
-   (1, ioa_cfg-trace_index)%IPR_NUM_TRACE_ENTRIES];
+   trace_index = atomic_add_return(1, ioa_cfg-trace_index)  
IPR_TRACE_INDEX_MASK;
+   trace_entry = ioa_cfg-trace[trace_index];
trace_entry-time = jiffies;
trace_entry-op_code = ipr_cmd-ioarcb.cmd_pkt.cdb[0];
trace_entry-type = type;
diff --git a/drivers/scsi/ipr.h b/drivers/scsi/ipr.h
index f6d379725a00..06b3b4bb2911 100644
--- a/drivers/scsi/ipr.h
+++ b/drivers/scsi/ipr.h
@@ -1462,6 +1462,7 @@ struct ipr_ioa_cfg {
 
 #define IPR_NUM_TRACE_INDEX_BITS   8
 #define IPR_NUM_TRACE_ENTRIES  (1  IPR_NUM_TRACE_INDEX_BITS)
+#define IPR_TRACE_INDEX_MASK   (IPR_NUM_TRACE_ENTRIES - 1)
 #define IPR_TRACE_SIZE (sizeof(struct ipr_trace_entry) * IPR_NUM_TRACE_ENTRIES)
char trace_start[8];
 #define IPR_TRACE_START_LABEL  trace
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 26/82] rds: rds_ib_device.refcount overflow

[Jiri Slaby]

From: Wengang Wang wen.gang.w...@oracle.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 4fabb59449aa44a585b3603ffdadd4c5f4d0c033 upstream.

Fixes: 3e0249f9c05c (RDS/IB: add refcount tracking to struct rds_ib_device)

There lacks a dropping on rds_ib_device.refcount in case rds_ib_alloc_fmr
failed(mr pool running out). this lead to the refcount overflow.

A complain in line 117(see following) is seen. From vmcore:
s_ib_rdma_mr_pool_depleted is 2147485544 and rds_ibdev-refcount is -2147475448.
That is the evidence the mr pool is used up. so rds_ib_alloc_fmr is very likely
to return ERR_PTR(-EAGAIN).

115 void rds_ib_dev_put(struct rds_ib_device *rds_ibdev)
116 {
117 BUG_ON(atomic_read(rds_ibdev-refcount) = 0);
118 if (atomic_dec_and_test(rds_ibdev-refcount))
119 queue_work(rds_wq, rds_ibdev-free_work);
120 }

fix is to drop refcount when rds_ib_alloc_fmr failed.

Signed-off-by: Wengang Wang wen.gang.w...@oracle.com
Reviewed-by: Haggai Eran hagg...@mellanox.com
Signed-off-by: Doug Ledford dledf...@redhat.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 net/rds/ib_rdma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index e8fdb172adbb..a985158d95d5 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -759,8 +759,10 @@ void *rds_ib_get_mr(struct scatterlist *sg, unsigned long 
nents,
}
 
ibmr = rds_ib_alloc_fmr(rds_ibdev);
-   if (IS_ERR(ibmr))
+   if (IS_ERR(ibmr)) {
+   rds_ib_dev_put(rds_ibdev);
return ibmr;
+   }
 
ret = rds_ib_map_fmr(rds_ibdev, ibmr, sg, nents);
if (ret == 0)
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 22/82] xhci: Calculate old endpoints correctly on device reset

[Jiri Slaby]

From: Brian Campbell ba...@z273.org.uk

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 upstream.

When resetting a device the number of active TTs may need to be
corrected by xhci_update_tt_active_eps, but the number of old active
endpoints supplied to it was always zero, so the number of TTs and the
bandwidth reserved for them was not updated, and could rise
unnecessarily.

This affected systems using Intel's Patherpoint chipset, which rely on
software bandwidth checking.  For example, a Lenovo X230 would lose the
ability to use ports on the docking station after enough suspend/resume
cycles because the bandwidth calculated would rise with every cycle when
a suitable device is attached.

The correct number of active endpoints is calculated in the same way as
in xhci_reserve_bandwidth.

Signed-off-by: Brian Campbell ba...@z273.org.uk
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/usb/host/xhci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e0ccc95c91e2..00686a8c4fa0 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3423,6 +3423,9 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, 
struct usb_device *udev)
return -EINVAL;
}
 
+   if (virt_dev-tt_info)
+   old_active_eps = virt_dev-tt_info-active_eps;
+
if (virt_dev-udev != udev) {
/* If the virt_dev and the udev does not match, this virt_dev
 * may belong to another udev.
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 09/82] ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4

[Jiri Slaby]

From: Dominic Sacré dominic.sa...@gmx.de

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 0689a86ae814f39af94a9736a0a5426dd82eb107 upstream.

The Steinberg MI2 and MI4 interfaces are compatible with the USB class
audio spec, but the MIDI part of the devices is reported as a vendor
specific interface.

This patch adds entries to quirks-table.h to recognize the MIDI
endpoints. Audio functionality was already working and is unaffected by
this change.

Signed-off-by: Dominic Sacré dominic.sa...@gmx.de
Signed-off-by: Albert Huitsing alb...@huitsing.nl
Acked-by: Clemens Ladisch clem...@ladisch.de
Signed-off-by: Takashi Iwai ti...@suse.de
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 sound/usb/quirks-table.h | 68 
 1 file changed, 68 insertions(+)

diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 5293b5ac8b9d..7c24088bcaa4 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2516,6 +2516,74 @@ YAMAHA_DEVICE(0x7010, UB99),
}
 },
 
+/* Steinberg devices */
+{
+   /* Steinberg MI2 */
+   USB_DEVICE_VENDOR_SPEC(0x0a4e, 0x2040),
+   .driver_info = (unsigned long)  (const struct snd_usb_audio_quirk) {
+   .ifnum = QUIRK_ANY_INTERFACE,
+   .type = QUIRK_COMPOSITE,
+   .data =  (const struct snd_usb_audio_quirk[]) {
+   {
+   .ifnum = 0,
+   .type = QUIRK_AUDIO_STANDARD_INTERFACE
+   },
+   {
+   .ifnum = 1,
+   .type = QUIRK_AUDIO_STANDARD_INTERFACE
+   },
+   {
+   .ifnum = 2,
+   .type = QUIRK_AUDIO_STANDARD_INTERFACE
+   },
+   {
+   .ifnum = 3,
+   .type = QUIRK_MIDI_FIXED_ENDPOINT,
+   .data = (const struct 
snd_usb_midi_endpoint_info) {
+   .out_cables = 0x0001,
+   .in_cables  = 0x0001
+   }
+   },
+   {
+   .ifnum = -1
+   }
+   }
+   }
+},
+{
+   /* Steinberg MI4 */
+   USB_DEVICE_VENDOR_SPEC(0x0a4e, 0x4040),
+   .driver_info = (unsigned long)  (const struct snd_usb_audio_quirk) {
+   .ifnum = QUIRK_ANY_INTERFACE,
+   .type = QUIRK_COMPOSITE,
+   .data =  (const struct snd_usb_audio_quirk[]) {
+   {
+   .ifnum = 0,
+   .type = QUIRK_AUDIO_STANDARD_INTERFACE
+   },
+   {
+   .ifnum = 1,
+   .type = QUIRK_AUDIO_STANDARD_INTERFACE
+   },
+   {
+   .ifnum = 2,
+   .type = QUIRK_AUDIO_STANDARD_INTERFACE
+   },
+   {
+   .ifnum = 3,
+   .type = QUIRK_MIDI_FIXED_ENDPOINT,
+   .data = (const struct 
snd_usb_midi_endpoint_info) {
+   .out_cables = 0x0001,
+   .in_cables  = 0x0001
+   }
+   },
+   {
+   .ifnum = -1
+   }
+   }
+   }
+},
+
 /* TerraTec devices */
 {
USB_DEVICE_VENDOR_SPEC(0x0ccd, 0x0012),
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 28/82] iscsi-target: Fix use-after-free during TPG session shutdown

[Jiri Slaby]

From: Nicholas Bellinger n...@linux-iscsi.org

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 417c20a9bdd1e876384127cf096d8ae8b559066c upstream.

This patch fixes a use-after-free bug in iscsit_release_sessions_for_tpg()
where se_portal_group-session_lock was incorrectly released/re-acquired
while walking the active se_portal_group-tpg_sess_list.

The can result in a NULL pointer dereference when iscsit_close_session()
shutdown happens in the normal path asynchronously to this code, causing
a bogus dereference of an already freed list entry to occur.

To address this bug, walk the session list checking for the same state
as before, but move entries to a local list to avoid dropping the lock
while walking the active list.

As before, signal using iscsi_session-session_restatement=1 for those
list entries to be released locally by iscsit_free_session() code.

Reported-by: Sunilkumar Nadumuttlu s...@datera.io
Cc: Sunilkumar Nadumuttlu s...@datera.io
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/target/iscsi/iscsi_target.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target.c 
b/drivers/target/iscsi/iscsi_target.c
index 8ac1800eef06..13af385fc859 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4707,6 +4707,7 @@ int iscsit_release_sessions_for_tpg(struct 
iscsi_portal_group *tpg, int force)
struct iscsi_session *sess;
struct se_portal_group *se_tpg = tpg-tpg_se_tpg;
struct se_session *se_sess, *se_sess_tmp;
+   LIST_HEAD(free_list);
int session_count = 0;
 
spin_lock_bh(se_tpg-session_lock);
@@ -4728,14 +4729,17 @@ int iscsit_release_sessions_for_tpg(struct 
iscsi_portal_group *tpg, int force)
}
atomic_set(sess-session_reinstatement, 1);
spin_unlock(sess-conn_lock);
-   spin_unlock_bh(se_tpg-session_lock);
 
-   iscsit_free_session(sess);
-   spin_lock_bh(se_tpg-session_lock);
+   list_move_tail(se_sess-sess_list, free_list);
+   }
+   spin_unlock_bh(se_tpg-session_lock);
 
+   list_for_each_entry_safe(se_sess, se_sess_tmp, free_list, sess_list) {
+   sess = (struct iscsi_session *)se_sess-fabric_sess_ptr;
+
+   iscsit_free_session(sess);
session_count++;
}
-   spin_unlock_bh(se_tpg-session_lock);
 
pr_debug(Released %d iSCSI Session(s) from Target Portal
 Group: %hu\n, session_count, tpg-tpgt);
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 25/82] xhci: do not report PLC when link is in internal resume state

[Jiri Slaby]

From: Zhuang Jin Can jin.can.zhu...@intel.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream.

Port link change with port in resume state should not be
reported to usbcore, as this is an internal state to be
handled by xhci driver. Reporting PLC to usbcore may
cause usbcore clearing PLC first and port change event irq
won't be generated.

Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/usb/host/xhci-hub.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 4adc1be24b4a..55b3aa33bc06 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -586,7 +586,14 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd,
status |= USB_PORT_STAT_C_RESET  16;
/* USB3.0 only */
if (hcd-speed == HCD_USB3) {
-   if ((raw_port_status  PORT_PLC))
+   /* Port link change with port in resume state should not be
+* reported to usbcore, as this is an internal state to be
+* handled by xhci driver. Reporting PLC to usbcore may
+* cause usbcore clearing PLC first and port change event
+* irq won't be generated.
+*/
+   if ((raw_port_status  PORT_PLC) 
+   (raw_port_status  PORT_PLS_MASK) != XDEV_RESUME)
status |= USB_PORT_STAT_C_LINK_STATE  16;
if ((raw_port_status  PORT_WRC))
status |= USB_PORT_STAT_C_BH_RESET  16;
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 23/82] xhci: report U3 when link is in resume state

[Jiri Slaby]

From: Zhuang Jin Can jin.can.zhu...@intel.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 243292a2ad3dc365849b820a64868927168894ac upstream.

xhci_hub_report_usb3_link_state() returns pls as U0 when the link
is in resume state, and this causes usb core to think the link is in
U0 while actually it's in resume state. When usb core transfers
control request on the link, it fails with TRB error as the link
is not ready for transfer.

To fix the issue, report U3 when the link is in resume state, thus
usb core knows the link it's not ready for transfer.

Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/usb/host/xhci-hub.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index abb36165515a..86cebec3c5d6 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -480,10 +480,13 @@ static void xhci_hub_report_usb3_link_state(struct 
xhci_hcd *xhci,
u32 pls = status_reg  PORT_PLS_MASK;
 
/* resume state is a xHCI internal state.
-* Do not report it to usb core.
+* Do not report it to usb core, instead, pretend to be U3,
+* thus usb core knows it's not ready for transfer
 */
-   if (pls == XDEV_RESUME)
+   if (pls == XDEV_RESUME) {
+   *status |= USB_SS_PORT_LS_U3;
return;
+   }
 
/* When the CAS bit is set then warm reset
 * should be performed on port
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3.12 24/82] xhci: prevent bus_suspend if SS port resuming in phase 1

[Jiri Slaby]

From: Zhuang Jin Can jin.can.zhu...@intel.com

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit fac4271d1126c45ceaceb7f4a336317b771eb121 upstream.

When the link is just waken, it's in Resume state, and driver sets PLS to
U0. This refers to Phase 1. Phase 2 refers to when the link has completed
the transition from Resume state to U0.

With the fix of xhci: report U3 when link is in resume state, it also
exposes an issue that usb3 roothub and controller can suspend right
after phase 1, and this causes a hard hang in controller.

To fix the issue, we need to prevent usb3 bus suspend if any port is
resuming in phase 1.

[merge separate USB2 and USB3 port resume checking to one -Mathias]
Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
 drivers/usb/host/xhci-hub.c  | 6 +++---
 drivers/usb/host/xhci-ring.c | 3 +++
 drivers/usb/host/xhci.h  | 1 +
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 86cebec3c5d6..4adc1be24b4a 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1120,10 +1120,10 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
spin_lock_irqsave(xhci-lock, flags);
 
if (hcd-self.root_hub-do_remote_wakeup) {
-   if (bus_state-resuming_ports) {
+   if (bus_state-resuming_ports ||/* USB2 */
+   bus_state-port_remote_wakeup) {/* USB3 */
spin_unlock_irqrestore(xhci-lock, flags);
-   xhci_dbg(xhci, suspend failed because 
-   a port is resuming\n);
+   xhci_dbg(xhci, suspend failed because a port is 
resuming\n);
return -EBUSY;
}
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 07aafa50f453..b16404723fc2 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1707,6 +1707,9 @@ static void handle_port_status(struct xhci_hcd *xhci,
usb_hcd_resume_root_hub(hcd);
}
 
+   if (hcd-speed == HCD_USB3  (temp  PORT_PLS_MASK) == XDEV_INACTIVE)
+   bus_state-port_remote_wakeup = ~(1  faked_port_index);
+
if ((temp  PORT_PLC)  (temp  PORT_PLS_MASK) == XDEV_RESUME) {
xhci_dbg(xhci, port resume event for port %d\n, port_id);
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 510e9c0efd18..8686a06d83d4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -285,6 +285,7 @@ struct xhci_op_regs {
 #define XDEV_U0(0x0  5)
 #define XDEV_U2(0x2  5)
 #define XDEV_U3(0x3  5)
+#define XDEV_INACTIVE  (0x6  5)
 #define XDEV_RESUME(0xf  5)
 /* true: port has power (see HCC_PPC) */
 #define PORT_POWER (1  9)
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/6] powerpc: move the cpu_has_feature to a separate file

[Kevin Hao]

We plan to use jump label for cpu_has_feature. In order to implement
this we need to include the linux/jump_label.h in asm/cputable.h.
But it seems that asm/cputable.h is so basic header file for ppc that
it is almost included by all the other header files. The including of
the linux/jump_label.h will introduces various recursive inclusion.
And it is very hard to fix that. So we choose to move the function
cpu_has_feature to a separate header file before using the jump label
for it. No functional change.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.

 arch/powerpc/include/asm/cacheflush.h   |  1 +
 arch/powerpc/include/asm/cpufeatures.h  | 14 ++
 arch/powerpc/include/asm/cputable.h |  8 
 arch/powerpc/include/asm/cputime.h  |  1 +
 arch/powerpc/include/asm/dbell.h|  1 +
 arch/powerpc/include/asm/dcr-native.h   |  1 +
 arch/powerpc/include/asm/mman.h |  1 +
 arch/powerpc/include/asm/time.h |  1 +
 arch/powerpc/include/asm/xor.h  |  1 +
 arch/powerpc/kernel/align.c |  1 +
 arch/powerpc/kernel/irq.c   |  1 +
 arch/powerpc/kernel/process.c   |  1 +
 arch/powerpc/kernel/setup-common.c  |  1 +
 arch/powerpc/kernel/setup_32.c  |  1 +
 arch/powerpc/kernel/smp.c   |  1 +
 arch/powerpc/platforms/cell/pervasive.c |  1 +
 arch/powerpc/xmon/ppc-dis.c |  1 +
 17 files changed, 29 insertions(+), 8 deletions(-)
 create mode 100644 arch/powerpc/include/asm/cpufeatures.h

diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index 6229e6b6037b..3bdcd9231852 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -11,6 +11,7 @@
 
 #include linux/mm.h
 #include asm/cputable.h
+#include asm/cpufeatures.h
 
 /*
  * No cache flushing is required when address mappings are changed,
diff --git a/arch/powerpc/include/asm/cpufeatures.h 
b/arch/powerpc/include/asm/cpufeatures.h
new file mode 100644
index ..37650db5044f
--- /dev/null
+++ b/arch/powerpc/include/asm/cpufeatures.h
@@ -0,0 +1,14 @@
+#ifndef __ASM_POWERPC_CPUFEATURES_H
+#define __ASM_POWERPC_CPUFEATURES_H
+
+#include asm/cputable.h
+
+static inline int cpu_has_feature(unsigned long feature)
+{
+   return (CPU_FTRS_ALWAYS  feature) ||
+  (CPU_FTRS_POSSIBLE
+cur_cpu_spec-cpu_features
+feature);
+}
+
+#endif /* __ASM_POWERPC_CPUFEATURE_H */
diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index b118072670fb..ae4b6ef341cd 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -556,14 +556,6 @@ enum {
 };
 #endif /* __powerpc64__ */
 
-static inline int cpu_has_feature(unsigned long feature)
-{
-   return (CPU_FTRS_ALWAYS  feature) ||
-  (CPU_FTRS_POSSIBLE
-cur_cpu_spec-cpu_features
-feature);
-}
-
 #define HBP_NUM 1
 
 #endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h
index e2452550bcb1..b91837865c0e 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -28,6 +28,7 @@ static inline void setup_cputime_one_jiffy(void) { }
 #include asm/div64.h
 #include asm/time.h
 #include asm/param.h
+#include asm/cpufeatures.h
 
 typedef u64 __nocast cputime_t;
 typedef u64 __nocast cputime64_t;
diff --git a/arch/powerpc/include/asm/dbell.h b/arch/powerpc/include/asm/dbell.h
index 5fa6b20eba10..2d9eae338f70 100644
--- a/arch/powerpc/include/asm/dbell.h
+++ b/arch/powerpc/include/asm/dbell.h
@@ -16,6 +16,7 @@
 #include linux/threads.h
 
 #include asm/ppc-opcode.h
+#include asm/cpufeatures.h
 
 #define PPC_DBELL_MSG_BRDCAST  (0x0400)
 #define PPC_DBELL_TYPE(x)  (((x)  0xf)  (63-36))
diff --git a/arch/powerpc/include/asm/dcr-native.h 
b/arch/powerpc/include/asm/dcr-native.h
index 4efc11dacb98..0186ba05bfe1 100644
--- a/arch/powerpc/include/asm/dcr-native.h
+++ b/arch/powerpc/include/asm/dcr-native.h
@@ -24,6 +24,7 @@
 
 #include linux/spinlock.h
 #include asm/cputable.h
+#include asm/cpufeatures.h
 
 typedef struct {
unsigned int base;
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index 8565c254151a..74922ad05e6c 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -13,6 +13,7 @@
 
 #include asm/cputable.h
 #include linux/mm.h
+#include asm/cpufeatures.h
 
 /*
  * This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 6f69828458fb..fa63005f827f 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -18,6 +18,7 @@
 #include linux/percpu.h
 
 #include asm/processor.h
+#include asm/cpufeatures.h
 
 /* time.c */
 extern unsigned long tb_ticks_per_jiffy;
diff --git 

[PATCH v2 3/6] powerpc: kill mfvtb()

[Kevin Hao]

This function is only used by get_vtb(). They are almost the same
except the reading from the real register. Move the mfspr() to
get_vtb() and kill the function mfvtb(). With this, we can eliminate
the use of cpu_has_feature() in very core header file like reg.h.
This is a preparation for the use of jump label for cpu_has_feature().

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.

 arch/powerpc/include/asm/reg.h  | 9 -
 arch/powerpc/include/asm/time.h | 2 +-
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index aa1cc5f015ee..d0b5f4b63776 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1207,15 +1207,6 @@
 : r ((unsigned long)(v)) \
 : memory)
 
-static inline unsigned long mfvtb (void)
-{
-#ifdef CONFIG_PPC_BOOK3S_64
-   if (cpu_has_feature(CPU_FTR_ARCH_207S))
-   return mfspr(SPRN_VTB);
-#endif
-   return 0;
-}
-
 #ifdef __powerpc64__
 #if defined(CONFIG_PPC_CELL) || defined(CONFIG_PPC_FSL_BOOK3E)
 #define mftb() ({unsigned long rval;   \
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 10fc784a2ad4..6f69828458fb 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -106,7 +106,7 @@ static inline u64 get_vtb(void)
 {
 #ifdef CONFIG_PPC_BOOK3S_64
if (cpu_has_feature(CPU_FTR_ARCH_207S))
-   return mfvtb();
+   return mfspr(SPRN_VTB);
 #endif
return 0;
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/6] powerpc: use jump label for {cpu,mmu}_has_feature()

[Kevin Hao]

Hi,

v2:
Drop the following two patches as suggested by Ingo and Peter:
jump_label: no need to acquire the jump_label_mutex in jump_lable_init()
jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros

v1:
I have tried to change the {cpu,mmu}_has_feature() to use jump label two yeas
ago [1]. But that codes seem a bit ugly. This is a reimplementation by moving 
the
jump_label_init() much earlier so the jump label can be used in a very earlier
stage. Boot test on p4080ds, t2080rdb and powermac (qemu). This patch series
is against linux-next.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111026.html

Kevin Hao (6):
  jump_label: make it possible for the archs to invoke jump_label_init()
much earlier
  powerpc: invoke jump_label_init() in a much earlier stage
  powerpc: kill mfvtb()
  powerpc: move the cpu_has_feature to a separate file
  powerpc: use the jump label for cpu_has_feature
  powerpc: use jump label for mmu_has_feature

 arch/powerpc/include/asm/cacheflush.h   |  1 +
 arch/powerpc/include/asm/cpufeatures.h  | 34 ++
 arch/powerpc/include/asm/cputable.h | 16 +++---
 arch/powerpc/include/asm/cputime.h  |  1 +
 arch/powerpc/include/asm/dbell.h|  1 +
 arch/powerpc/include/asm/dcr-native.h   |  1 +
 arch/powerpc/include/asm/mman.h |  1 +
 arch/powerpc/include/asm/mmu.h  | 29 ++
 arch/powerpc/include/asm/reg.h  |  9 
 arch/powerpc/include/asm/time.h |  3 ++-
 arch/powerpc/include/asm/xor.h  |  1 +
 arch/powerpc/kernel/align.c |  1 +
 arch/powerpc/kernel/cputable.c  | 37 +
 arch/powerpc/kernel/irq.c   |  1 +
 arch/powerpc/kernel/process.c   |  1 +
 arch/powerpc/kernel/setup-common.c  |  1 +
 arch/powerpc/kernel/setup_32.c  |  5 +
 arch/powerpc/kernel/setup_64.c  |  4 
 arch/powerpc/kernel/smp.c   |  1 +
 arch/powerpc/platforms/cell/pervasive.c |  1 +
 arch/powerpc/xmon/ppc-dis.c |  1 +
 kernel/jump_label.c |  3 +++
 22 files changed, 135 insertions(+), 18 deletions(-)
 create mode 100644 arch/powerpc/include/asm/cpufeatures.h

-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/6] powerpc: use the jump label for cpu_has_feature

[Kevin Hao]

The cpu features are fixed once the probe of cpu features are done.
And the function cpu_has_feature() does be used in some hot path.
The checking of the cpu features for each time of invoking of
cpu_has_feature() seems suboptimal. This tries to reduce this
overhead of this check by using jump label.

The generated assemble code of the following c program:
if (cpu_has_feature(CPU_FTR_XXX))
xxx()

Before:
lis r9,-16230
lwz r9,12324(r9)
lwz r9,12(r9)
andi.   r10,r9,512
beqlr-

After:
nop if CPU_FTR_XXX is enabled
b xxx   if CPU_FTR_XXX is not enabled

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: Use the open-coded definition and initialization for cpu_feat_keys[].

 arch/powerpc/include/asm/cpufeatures.h | 20 
 arch/powerpc/include/asm/cputable.h|  8 
 arch/powerpc/kernel/cputable.c | 20 
 arch/powerpc/kernel/setup_32.c |  1 +
 arch/powerpc/kernel/setup_64.c |  1 +
 5 files changed, 50 insertions(+)

diff --git a/arch/powerpc/include/asm/cpufeatures.h 
b/arch/powerpc/include/asm/cpufeatures.h
index 37650db5044f..405a97fe6ef9 100644
--- a/arch/powerpc/include/asm/cpufeatures.h
+++ b/arch/powerpc/include/asm/cpufeatures.h
@@ -3,6 +3,25 @@
 
 #include asm/cputable.h
 
+#ifdef CONFIG_JUMP_LABEL
+#include linux/jump_label.h
+
+extern struct static_key_true cpu_feat_keys[MAX_CPU_FEATURES];
+
+static inline int cpu_has_feature(unsigned long feature)
+{
+   int i;
+
+   if (CPU_FTRS_ALWAYS  feature)
+   return 1;
+
+   if (!(CPU_FTRS_POSSIBLE  feature))
+   return 0;
+
+   i = __builtin_ctzl(feature);
+   return static_branch_likely(cpu_feat_keys[i]);
+}
+#else
 static inline int cpu_has_feature(unsigned long feature)
 {
return (CPU_FTRS_ALWAYS  feature) ||
@@ -10,5 +29,6 @@ static inline int cpu_has_feature(unsigned long feature)
 cur_cpu_spec-cpu_features
 feature);
 }
+#endif
 
 #endif /* __ASM_POWERPC_CPUFEATURE_H */
diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index ae4b6ef341cd..2ebee2894102 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -114,6 +114,12 @@ extern void do_feature_fixups(unsigned long value, void 
*fixup_start,
 
 extern const char *powerpc_base_platform;
 
+#ifdef CONFIG_JUMP_LABEL
+extern void cpu_feat_keys_init(void);
+#else
+static inline void cpu_feat_keys_init(void) { }
+#endif
+
 /* TLB flush actions. Used as argument to cpu_spec.flush_tlb() hook */
 enum {
TLB_INVAL_SCOPE_GLOBAL = 0, /* invalidate all TLBs */
@@ -124,6 +130,8 @@ enum {
 
 /* CPU kernel features */
 
+#define MAX_CPU_FEATURES   (8 * sizeof(((struct cpu_spec 
*)0)-cpu_features))
+
 /* Retain the 32b definitions all use bottom half of word */
 #define CPU_FTR_COHERENT_ICACHEASM_CONST(0x0001)
 #define CPU_FTR_L2CR   ASM_CONST(0x0002)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 7d80bfdfb15e..ea94931c5e70 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -15,6 +15,7 @@
 #include linux/threads.h
 #include linux/init.h
 #include linux/export.h
+#include linux/jump_label.h
 
 #include asm/oprofile_impl.h
 #include asm/cputable.h
@@ -2195,3 +2196,22 @@ struct cpu_spec * __init identify_cpu(unsigned long 
offset, unsigned int pvr)
 
return NULL;
 }
+
+#ifdef CONFIG_JUMP_LABEL
+struct static_key_true cpu_feat_keys[MAX_CPU_FEATURES] = {
+   [0 ... MAX_CPU_FEATURES - 1] = STATIC_KEY_TRUE_INIT
+};
+EXPORT_SYMBOL_GPL(cpu_feat_keys);
+
+void __init cpu_feat_keys_init(void)
+{
+   int i;
+
+   for (i = 0; i  MAX_CPU_FEATURES; i++) {
+   unsigned long f = 1ul  i;
+
+   if (!(cur_cpu_spec-cpu_features  f))
+   static_branch_disable(cpu_feat_keys[i]);
+   }
+}
+#endif
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index f0868f510b3b..93756175a13c 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -115,6 +115,7 @@ notrace void __init machine_init(u64 dt_ptr)
lockdep_init();
 
jump_label_init();
+   cpu_feat_keys_init();
 
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f0802a0b4a20..4cf3894d91fa 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -251,6 +251,7 @@ void __init early_setup(unsigned long dt_ptr)
lockdep_init();
 
jump_label_init();
+   cpu_feat_keys_init();
 
/*  printk is now safe to use --- */
 
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a 

[PATCH v2 2/6] powerpc: invoke jump_label_init() in a much earlier stage

[Kevin Hao]

So we can use static_key for cpu_has_feature() and mmu_has_feature().

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.

 arch/powerpc/kernel/setup_32.c | 2 ++
 arch/powerpc/kernel/setup_64.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index bb02e9f6944e..35980a2785ba 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,8 @@ notrace void __init machine_init(u64 dt_ptr)
 {
lockdep_init();
 
+   jump_label_init();
+
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
 
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index bdcbb716f4d6..f0802a0b4a20 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -250,6 +250,8 @@ void __init early_setup(unsigned long dt_ptr)
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
 
+   jump_label_init();
+
/*  printk is now safe to use --- */
 
/* Enable early debugging if any specified (see udbg.h) */
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 6/6] powerpc: use jump label for mmu_has_feature

[Kevin Hao]

The mmu features are fixed once the probe of mmu features are done.
And the function mmu_has_feature() does be used in some hot path.
The checking of the mmu features for each time of invoking of
mmu_has_feature() seems suboptimal. This tries to reduce this
overhead of this check by using jump label.

The generated assemble code of the following c program:
if (mmu_has_feature(MMU_FTR_XXX))
xxx()
Before:
lis r9,-16230
lwz r9,12324(r9)
lwz r9,24(r9)
andi.   r10,r9,16
beqlr+

After:
nop if MMU_FTR_XXX is enabled
b xxx   if MMU_FTR_XXX is not enabled

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: Use the open-coded definition and initialization for mmu_feat_keys[].

 arch/powerpc/include/asm/mmu.h | 29 +
 arch/powerpc/kernel/cputable.c | 17 +
 arch/powerpc/kernel/setup_32.c |  1 +
 arch/powerpc/kernel/setup_64.c |  1 +
 4 files changed, 48 insertions(+)

diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 3d5abfe6ba67..e091de352a75 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -109,6 +109,34 @@
 DECLARE_PER_CPU(int, next_tlbcam_idx);
 #endif
 
+#ifdef CONFIG_JUMP_LABEL
+#include linux/jump_label.h
+
+#define MAX_MMU_FEATURES   (8 * sizeof(((struct cpu_spec 
*)0)-mmu_features))
+
+extern struct static_key_true mmu_feat_keys[MAX_MMU_FEATURES];
+
+extern void mmu_feat_keys_init(void);
+
+static inline int mmu_has_feature(unsigned long feature)
+{
+   int i;
+
+   i = __builtin_ctzl(feature);
+   return static_branch_likely(mmu_feat_keys[i]);
+}
+
+static inline void mmu_clear_feature(unsigned long feature)
+{
+   int i;
+
+   i = __builtin_ctzl(feature);
+   cur_cpu_spec-mmu_features = ~feature;
+   static_branch_disable(mmu_feat_keys[i]);
+}
+#else
+static inline void mmu_feat_keys_init(void) { }
+
 static inline int mmu_has_feature(unsigned long feature)
 {
return (cur_cpu_spec-mmu_features  feature);
@@ -118,6 +146,7 @@ static inline void mmu_clear_feature(unsigned long feature)
 {
cur_cpu_spec-mmu_features = ~feature;
 }
+#endif
 
 extern unsigned int __start___mmu_ftr_fixup, __stop___mmu_ftr_fixup;
 
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index ea94931c5e70..6b505c98520b 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2214,4 +2214,21 @@ void __init cpu_feat_keys_init(void)
static_branch_disable(cpu_feat_keys[i]);
}
 }
+
+struct static_key_true mmu_feat_keys[MAX_MMU_FEATURES] = {
+   [0 ... MAX_MMU_FEATURES - 1] = STATIC_KEY_TRUE_INIT
+};
+EXPORT_SYMBOL_GPL(mmu_feat_keys);
+
+void __init mmu_feat_keys_init(void)
+{
+   int i;
+
+   for (i = 0; i  MAX_MMU_FEATURES; i++) {
+   unsigned long f = 1ul  i;
+
+   if (!(cur_cpu_spec-mmu_features  f))
+   static_branch_disable(mmu_feat_keys[i]);
+   }
+}
 #endif
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 93756175a13c..8acff5a4bc3e 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -116,6 +116,7 @@ notrace void __init machine_init(u64 dt_ptr)
 
jump_label_init();
cpu_feat_keys_init();
+   mmu_feat_keys_init();
 
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4cf3894d91fa..df6f98f1c46c 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -252,6 +252,7 @@ void __init early_setup(unsigned long dt_ptr)
 
jump_label_init();
cpu_feat_keys_init();
+   mmu_feat_keys_init();
 
/*  printk is now safe to use --- */
 
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/6] jump_label: make it possible for the archs to invoke jump_label_init() much earlier

[Kevin Hao]

For some archs (such as powerpc) would want to invoke jump_label_init()
in a much earlier stage. So check static_key_initialized in order to
make sure this function run only once.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.

 kernel/jump_label.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index f7dd15d537f9..cfc7d7b65432 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -205,6 +205,9 @@ void __init jump_label_init(void)
struct static_key *key = NULL;
struct jump_entry *iter;
 
+   if (static_key_initialized)
+   return;
+
jump_label_lock();
jump_label_sort_entries(iter_start, iter_stop);
 
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] memory-hotplug: remove reset_node_managed_pages() and reset_node_managed_pages() in hotadd_new_pgdat()

[Xishi Qiu]

On 2015/8/24 17:39, Tang Chen wrote:

 
 On 08/24/2015 05:17 PM, Xishi Qiu wrote:
 On 2015/8/23 18:28, Tang Chen wrote:

 Hi Shi,

 Sorry for the late reply. I hope it won't be too late.

 NON-ACK by me, I think.

 I noticed that your first has been merged. But it won't fix the problem
 these code intended to fix.

 After your patch 1, zone's spanned/present won't be set to 0 because:

 free_area_init_node()
   |-- get_pfn_range_for_nid(start_pfn, end_pfn)
   |-- calculate_node_totalpages(pgdat, start_pfn, end_pfn, ...)
   | -- zone_spanned_pages_in_node()
| -- if (!node_start_pfn  !node_end_pfn) return 0;
 false, won't return 0
   | -- zone_absent_pages_in_node()
| -- if (!node_start_pfn  !node_end_pfn) return 0;
 false, won't return 0

 Hi Tang,

 Thank you for your reply. When we add a new node, it is not included in the
 memblock, I have no idea why zone_spanned_pages_in_node() and 
 zone_absent_pages_in_node()
 won't return 0. Do you add some debug code and print it?
 
 Sorry, I didn't say it clearly since I was in a hurry.
 
 If we move memblock_add_node() forward before hotadd_new_pgdat(),
 then node_start_pfn and node_end_pfn won't be 0. And
 zone_spanned_pages_in_node() and zone_absent_pages_in_node() won't
 return 0.
 
 In your patch, they will return 0. And that leads to the print problem.
 

 This is caused by a little bug in your patch 1.

 You should put memblock_add_node(start, size, nid) before hotadd_new_pgdat()
 because:

 My patch is just add an empty node first, later __add_zone() will update the 
 size.
 But it is all right put here, and it can fix the print bug.
 
 Yes. I just found this bug in the log.
 

 hotadd_new_pgdat()
   | -- free_area_init_node()
| -- get_pfn_range_for_nid()
 | -- find memory ranges in memblock.

 | -- memblock_add_node(start, size, nid) ---if you add 
 it here, it doesn't work.

 The result will be like below if we hotadd node 5.
 [ 2007.577000] Initmem setup node 5 [mem 
 0x-0x]
 pr_info(Initmem setup node %d [mem %#018Lx-%#018Lx]\n, nid,
 (u64)start_pfn  PAGE_SHIFT, ((u64)end_pfn  PAGE_SHIFT) - 1);
 start_pfn and end_pfn are both 0, and 0-1 - 0x, right?
 
 Yes.
 

 [ 2007.584000] On node 5 totalpages: 0
 [ 2007.585000] Built 5 zonelists in Node order, mobility grouping on.  
 Total pages: 32588823
 [ 2007.594000] Policy zone: Normal
 [ 2007.598000] init_memory_mapping: [mem 0x600-0x607]


 And also, if we merge this patch, /sys/devices/system/node/nodeX/meminfo 
 will break.

 trigger call trace?
 
 No. There is no error output. But if you see 
 /sys/devices/system/node/nodeX/meminfo,
 memory size will double because totalpages is calculated once here, and one 
 more time
 when onlining memory.
 

Hi Tang,

Do you mean si_meminfo_node() - val-totalram = managed_pages; will be added 
double?
But my patch will keep it 0 in hotadd_new_pgdat(), so it will not be double, 
right?

Thanks,
Xishi Qiu

 I think reset it to 0 in add_memory() is just a temporary solution. Will 
 improve it in the
 future.
 
 Thanks.
 

 Since this patch is not merged, I think let's just drop it.

 And about the little bug in your patch 1, since I'm in a hurry, I have 
 already send a patch to fix it.


 Thanks. :)


 On 08/11/2015 03:33 PM, Xishi Qiu wrote:
 After hotadd_new_pgdat()-free_area_init_node(), the pgdat and zone's 
 spanned/present
 are both 0, so remove reset_node_managed_pages() and 
 reset_node_managed_pages().

 Signed-off-by: Xishi Qiu qiuxi...@huawei.com
 ---
mm/memory_hotplug.c | 25 -
1 file changed, 25 deletions(-)

 diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
 index 11f26cc..997dfad 100644
 --- a/mm/memory_hotplug.c
 +++ b/mm/memory_hotplug.c
 @@ -1065,16 +1065,6 @@ int __ref online_pages(unsigned long pfn, unsigned 
 long nr_pages, int online_typ
}
#endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
-static void reset_node_present_pages(pg_data_t *pgdat)
 -{
 -struct zone *z;
 -
 -for (z = pgdat-node_zones; z  pgdat-node_zones + MAX_NR_ZONES; z++)
 -z-present_pages = 0;
 -
 -pgdat-node_present_pages = 0;
 -}
 -
/* we are OK calling __meminit stuff here - we have 
 CONFIG_MEMORY_HOTPLUG */
static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 start)
{
 @@ -1109,21 +1099,6 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, 
 u64 start)
build_all_zonelists(pgdat, NULL);
mutex_unlock(zonelists_mutex);
-/*
 - * zone-managed_pages is set to an approximate value in
 - * free_area_init_core(), which will cause
 - * /sys/device/system/node/nodeX/meminfo has wrong data.
 - * So reset it to 0 before any memory is onlined.
 - */
 -reset_node_managed_pages(pgdat);
 -
 -/*
 - * When memory is hot-added, all the memory is in 

Re: [PATCH] mm: mmap: Check all failures before set values

[Michal Hocko]

On Mon 24-08-15 00:59:39, gang.chen.5...@qq.com wrote:
 From: Chen Gang gang.chen.5...@gmail.com
 
 When failure occurs and return, vma-vm_pgoff is already set, which is
 not a good idea.

Why? The vma is not inserted anywhere and the failure path is supposed
to simply free the vma.

 Signed-off-by: Chen Gang gang.chen.5...@gmail.com
 ---
  mm/mmap.c | 13 +++--
  1 file changed, 7 insertions(+), 6 deletions(-)
 
 diff --git a/mm/mmap.c b/mm/mmap.c
 index 8e0366e..b5a6f09 100644
 --- a/mm/mmap.c
 +++ b/mm/mmap.c
 @@ -2878,6 +2878,13 @@ int insert_vm_struct(struct mm_struct *mm, struct 
 vm_area_struct *vma)
   struct vm_area_struct *prev;
   struct rb_node **rb_link, *rb_parent;
  
 + if (find_vma_links(mm, vma-vm_start, vma-vm_end,
 +prev, rb_link, rb_parent))
 + return -ENOMEM;
 + if ((vma-vm_flags  VM_ACCOUNT) 
 +  security_vm_enough_memory_mm(mm, vma_pages(vma)))
 + return -ENOMEM;
 +
   /*
* The vm_pgoff of a purely anonymous vma should be irrelevant
* until its first write fault, when page's anon_vma and index
 @@ -2894,12 +2901,6 @@ int insert_vm_struct(struct mm_struct *mm, struct 
 vm_area_struct *vma)
   BUG_ON(vma-anon_vma);
   vma-vm_pgoff = vma-vm_start  PAGE_SHIFT;
   }
 - if (find_vma_links(mm, vma-vm_start, vma-vm_end,
 -prev, rb_link, rb_parent))
 - return -ENOMEM;
 - if ((vma-vm_flags  VM_ACCOUNT) 
 -  security_vm_enough_memory_mm(mm, vma_pages(vma)))
 - return -ENOMEM;
  
   vma_link(mm, vma, prev, rb_link, rb_parent);
   return 0;
 -- 
 1.9.3

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] x86/calling.h: remove unused SAVE_ALL/RESTORE_ALL macros for !CONFIG_x86_64

[Alexander Kuleshov]

SAVE_ALL and RESTORE_ALL macros for !CONFIG_X86_64 were introduced in the
1a338ac32 commit (sched, x86: Optimize the preempt_schedule() call) and
were used in the ___preempt_schedule and ___preempt_schedule_context from
the  arch/x86/kernel/preempt.S. But the arch/x86/kernel/preempt.S was
removed in the 0ad6e3c5 commit (x86: Speed up ___preempt_schedule*() by
using THUNK helpers) and ___preempt_schedule/___preempt_schedule_context
are reimplemeted and not used SAVE_ALL/RESTORE_ALL anymore.

These macros have no users anymore, so we can remove it.

Changelog:

v2: Check of the CONFIG_x86_64 returned as calling.h provides
functionality only for the x86_64.

Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
 arch/x86/entry/calling.h | 33 -
 1 file changed, 33 deletions(-)

diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index f4e6308..c009cee 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -207,37 +207,4 @@ For 32-bit we have the following conventions - kernel is 
built with
.macro icebp
.byte 0xf1
.endm
-
-#else /* CONFIG_X86_64 */
-
-/*
- * For 32bit only simplified versions of SAVE_ALL/RESTORE_ALL. These
- * are different from the entry_32.S versions in not changing the segment
- * registers. So only suitable for in kernel use, not when transitioning
- * from or to user space. The resulting stack frame is not a standard
- * pt_regs frame. The main use case is calling C code from assembler
- * when all the registers need to be preserved.
- */
-
-   .macro SAVE_ALL
-   pushl %eax
-   pushl %ebp
-   pushl %edi
-   pushl %esi
-   pushl %edx
-   pushl %ecx
-   pushl %ebx
-   .endm
-
-   .macro RESTORE_ALL
-   popl %ebx
-   popl %ecx
-   popl %edx
-   popl %esi
-   popl %edi
-   popl %ebp
-   popl %eax
-   .endm
-
 #endif /* CONFIG_X86_64 */
-
-- 
2.5.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] IGMP: Inhibit reports for local multicast groups

[Philip Downey]

The range of addresses between 224.0.0.0 and 224.0.0.255 inclusive, is
reserved for the use of routing protocols and other low-level topology
discovery or maintenance protocols, such as gateway discovery and
group membership reporting.  Multicast routers should not forward any
multicast datagram with destination addresses in this range,
regardless of its TTL.

Currently, IGMP reports are generated for this reserved range of
addresses even though a router will ignore this information since it
has no purpose.  However, the presence of reserved group addresses in
an IGMP membership report uses up network bandwidth and can also
obscure addresses of interest when inspecting membership reports using
packet inspection or debug messages.

Although the RFCs for the various version of IGMP (e.g.RFC 3376 for
v3) do not specify that the reserved addresses be excluded from
membership reports, it should do no harm in doing so.  In particular
there should be no adverse effect in any IGMP snooping functionality
since 224.0.0.x is specifically excluded as per RFC 4541 (IGMP and MLD
Snooping Switches Considerations) section 2.1.2. Data Forwarding
Rules:

2) Packets with a destination IP (DIP) address in the 224.0.0.X
   range which are not IGMP must be forwarded on all ports.

IGMP reports for local multicast groups can now be optionally
inhibited by means of a system control variable (by setting the value
to zero) e.g.:
echo 0  /proc/sys/net/ipv4/igmp_link_local_reports

To retain backwards compatibility the previous behaviour is retained
by default on system boot or reverted by setting the value back to
non-zero e.g.:
echo 1   /proc/sys/net/ipv4/igmp_link_local_reports

Signed-off-by: Philip Downey pdow...@brocade.com
---
 include/linux/igmp.h   |1 +
 net/ipv4/igmp.c|   29 -
 net/ipv4/sysctl_net_ipv4.c |7 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index 193ad48..e3e0dae 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -37,6 +37,7 @@ static inline struct igmpv3_query *
return (struct igmpv3_query *)skb_transport_header(skb);
 }
 
+extern int sysctl_igmp_link_local_reports;
 extern int sysctl_igmp_max_memberships;
 extern int sysctl_igmp_max_msf;
 extern int sysctl_igmp_qrv;
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 9fdfd9d..a3df89d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -110,6 +110,15 @@
 #define IP_MAX_MEMBERSHIPS 20
 #define IP_MAX_MSF 10
 
+/* IGMP reports for link-local multicast groups are enabled by default */
+#define IGMP_ENABLE_LLM 1
+
+int sysctl_igmp_link_local_reports __read_mostly = IGMP_ENABLE_LLM;
+
+#define IGMP_INHIBIT_LINK_LOCAL_REPORTS(_ipaddr) \
+   (ipv4_is_local_multicast(_ipaddr)  \
+(sysctl_igmp_link_local_reports == 0))
+
 #ifdef CONFIG_IP_MULTICAST
 /* Parameter names and values are taken from igmp-v2-06 draft */
 
@@ -437,6 +446,8 @@ static struct sk_buff *add_grec(struct sk_buff *skb, struct 
ip_mc_list *pmc,
 
if (pmc-multiaddr == IGMP_ALL_HOSTS)
return skb;
+   if (IGMP_INHIBIT_LINK_LOCAL_REPORTS(pmc-multiaddr))
+   return skb;
 
isquery = type == IGMPV3_MODE_IS_INCLUDE ||
  type == IGMPV3_MODE_IS_EXCLUDE;
@@ -545,6 +556,8 @@ static int igmpv3_send_report(struct in_device *in_dev, 
struct ip_mc_list *pmc)
for_each_pmc_rcu(in_dev, pmc) {
if (pmc-multiaddr == IGMP_ALL_HOSTS)
continue;
+   if (IGMP_INHIBIT_LINK_LOCAL_REPORTS(pmc-multiaddr))
+   continue;
spin_lock_bh(pmc-lock);
if (pmc-sfcount[MCAST_EXCLUDE])
type = IGMPV3_MODE_IS_EXCLUDE;
@@ -678,7 +691,11 @@ static int igmp_send_report(struct in_device *in_dev, 
struct ip_mc_list *pmc,
 
if (type == IGMPV3_HOST_MEMBERSHIP_REPORT)
return igmpv3_send_report(in_dev, pmc);
-   else if (type == IGMP_HOST_LEAVE_MESSAGE)
+
+   if (IGMP_INHIBIT_LINK_LOCAL_REPORTS(group))
+   return 0;
+
+   if (type == IGMP_HOST_LEAVE_MESSAGE)
dst = IGMP_ALL_ROUTER;
else
dst = group;
@@ -851,6 +868,8 @@ static bool igmp_heard_report(struct in_device *in_dev, 
__be32 group)
 
if (group == IGMP_ALL_HOSTS)
return false;
+   if (IGMP_INHIBIT_LINK_LOCAL_REPORTS(group))
+   return false;
 
rcu_read_lock();
for_each_pmc_rcu(in_dev, im) {
@@ -957,6 +976,8 @@ static bool igmp_heard_query(struct in_device *in_dev, 
struct sk_buff *skb,
continue;
if (im-multiaddr == IGMP_ALL_HOSTS)
continue;
+   if (IGMP_INHIBIT_LINK_LOCAL_REPORTS(im-multiaddr))
+   continue;

Re: [PATCH/RFC v6 01/36] leds: Add brightness_set_blocking op

[Pavel Machek]

On Thu 2015-08-20 16:43:31, Jacek Anaszewski wrote:
 This patch adds a new brightness_set_blocking op to the LED subsystem.
 The op is intended for drivers that set brightness in a blocking way,
 i.e. they either can sleep or use delays while setting brightness.
 
 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Cc: Andrew Lunn and...@lunn.ch
 Cc: Sakari Ailus sakari.ai...@linux.intel.com

Acked-by: Pavel Machek pa...@ucw.cz

Thanks!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler

[Wolfram Sang]

 Do we want to insist on a much larger change (conversion to regmap)
 when if this in place, a simple single functional call change will do the
 job?

I'd assume that regmap conversion will happen later quite likely anyhow.
Most of those devices will have I2C/SPI dual interfaces; or people will
find out that caching registers can reduce the bus load, etc...

That being said, I'll keep Irina's patches for the next merge window.
But we should keep an eye how/if the new function is used. Kernel
growth is an issue at times...

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH v4 4/4] mfd: max77686: Split out regulator part from the DT binding

[Lee Jones]

On Mon, 24 Aug 2015, Javier Martinez Canillas wrote:

 The Maxim MAX77686 PMIC is a multi-function device with regulators,
 clocks and a RTC. The DT bindings for the clocks are in a separate
 file but the bindings for the regulators are inside the mfd part.
 
 To make it consistent with the clocks portion of the binding and
 because is more natural to look for regulator bindings under the
 bindings/regulator sub-directory, split the regulator portion of
 the DT binding and add it as a separate file.
 
 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 
 ---
 
 Changes in v4: None
 Changes in v3:
 - Add Krzysztof Kozlowski Reviewed-by tag to patch #4.
 - Add Lee Jones Acked-by tag to patch #4.
 
 Changes in v2:
 - Use a generic name for the max77686 node in the regulator example.
 
  Documentation/devicetree/bindings/mfd/max77686.txt | 60 ++
  .../devicetree/bindings/regulator/max77686.txt | 71 
 ++
  2 files changed, 75 insertions(+), 56 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/regulator/max77686.txt

Applied, thanks.

 diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
 b/Documentation/devicetree/bindings/mfd/max77686.txt
 index d2ed3c20a5c3..741e76688cf2 100644
 --- a/Documentation/devicetree/bindings/mfd/max77686.txt
 +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
 @@ -7,8 +7,9 @@ different i2c slave address,presently for which we are 
 statically creating i2c
  client while probing.This document describes the binding for mfd device and
  PMIC submodule.
  
 -Binding for the built-in 32k clock generator block is defined separately
 -in bindings/clk/maxim,max77686.txt file.
 +Bindings for the built-in 32k clock generator block and
 +regulators are defined in ../clk/maxim,max77686.txt and
 +../regulator/max77686.txt respectively.
  
  Required properties:
  - compatible : Must be maxim,max77686;
 @@ -16,36 +17,6 @@ Required properties:
  - interrupts : This i2c device has an IRQ line connected to the main SoC.
  - interrupt-parent : The parent interrupt controller.
  
 -Optional node:
 -- voltage-regulators : The regulators of max77686 have to be instantiated
 -  under subnode named voltage-regulators using the following format.
 -
 - regulator_name {
 - regulator-compatible = LDOn/BUCKn
 - standard regulator constraints
 - };
 - refer Documentation/devicetree/bindings/regulator/regulator.txt
 -
 -  The regulator node's name should be initialized with a string
 -to get matched with their hardware counterparts as follow:
 -
 - -LDOn   :   for LDOs, where n can lie in range 1 to 26.
 - example: LDO1, LDO2, LDO26.
 - -BUCKn  :   for BUCKs, where n can lie in range 1 to 9.
 - example: BUCK1, BUCK5, BUCK9.
 -
 -  Regulators which can be turned off during system suspend:
 - -LDOn   :   2, 6-8, 10-12, 14-16,
 - -BUCKn  :   1-4.
 -  Use standard regulator bindings for it ('regulator-off-in-suspend').
 -
 -  LDO20, LDO21, LDO22, BUCK8 and BUCK9 can be configured to GPIO enable
 -  control. To turn this feature on this property must be added to the 
 regulator
 -  sub-node:
 - - maxim,ena-gpios : one GPIO specifier enable control (the gpio
 - flags are actually ignored and always
 - ACTIVE_HIGH is used)
 -
  Example:
  
   max77686: pmic@09 {
 @@ -53,27 +24,4 @@ Example:
   interrupt-parent = wakeup_eint;
   interrupts = 26 0;
   reg = 0x09;
 -
 - voltage-regulators {
 - ldo11_reg: LDO11 {
 - regulator-name = vdd_ldo11;
 - regulator-min-microvolt = 190;
 - regulator-max-microvolt = 190;
 - regulator-always-on;
 - };
 -
 - buck1_reg: BUCK1 {
 - regulator-name = vdd_mif;
 - regulator-min-microvolt = 95;
 - regulator-max-microvolt = 130;
 - regulator-always-on;
 - regulator-boot-on;
 - };
 -
 - buck9_reg: BUCK9 {
 - regulator-name = CAM_ISP_CORE_1.2V;
 - regulator-min-microvolt = 100;
 - regulator-max-microvolt = 120;
 - maxim,ena-gpios = gpm0 3 GPIO_ACTIVE_HIGH;
 - };
 - }
 + };
 diff --git a/Documentation/devicetree/bindings/regulator/max77686.txt 
 b/Documentation/devicetree/bindings/regulator/max77686.txt
 new file mode 100644
 index ..0dded64d89d3
 --- /dev/null
 +++ 

Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node

[Leif Lindholm]

On Mon, Aug 24, 2015 at 06:19:56PM +0800, Haojian Zhuang wrote:
  If your EFI memory map describes the memory as mappable, it is wrong.
 
 When kernel is working, kernel will create its own page table based on
 UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll
 be moved to reserved memblock. Why is it wrong?
 
 In the second, UEFI is firmware. When it's stable, nobody should change
 it without any reason.

Much like the memory map.

 These reserved memory are used in mailbox driver.
 Look. It's driver, so it could be changed at any time.

No, it is a set of regions of memory set aside for use by a different
master in the system as well as communications with that master.

The fact that there is a driver somewhere that is aware of this is
entirely beside the point. All agents in the system must adher to this
protocol.

 Why do you want
 to UEFI knowing this memory range? Do you hope UEFI to change when
 mailbox driver is changed?

Yes.

UEFI is a runtime environment. Having random magic areas not to be
touched will cause random pieces of software running under it to break
horribly or break other things horribly.
Unless you mark them as reserved in the UEFI memory map.
At which point the Linux kernel will automatically ignore them, and
the proposed patch is redundant.

So, yes, if you want a system that can boot reliably, run testsuites
(like SCT or FWTS), run applications (like fastboot ... or the EFI
stub kernel itself), then any memory regions that is reserved for
mailbox communication (or other masters in the system) _must_ be
marked in the EFI memory map.

/
Leif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property

[Lee Jones]

On Mon, 24 Aug 2015, Javier Martinez Canillas wrote:

 The regulator-compatible property from the regulator DT binding was
 deprecated. But the max77686 DT binding doc still suggest to use it
 instead of the regulator node name's which is the correct approach.
 
 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 
 ---
 
 Changes in v4:
 - Add Lee Jones Acked-by tag to patch #1.
 
 Changes in v3: None
 Changes in v2:
 - Add Krzysztof Kozlowski Reviewed-by tag to patch #1.
 
  Documentation/devicetree/bindings/mfd/max77686.txt | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)

Applied, thanks.

 diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
 b/Documentation/devicetree/bindings/mfd/max77686.txt
 index 163bd81a4607..8221102d3fc2 100644
 --- a/Documentation/devicetree/bindings/mfd/max77686.txt
 +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
 @@ -26,7 +26,7 @@ Optional node:
   };
   refer Documentation/devicetree/bindings/regulator/regulator.txt
  
 -  The regulator-compatible property of regulator should initialized with 
 string
 +  The regulator node's name should be initialized with a string
  to get matched with their hardware counterparts as follow:
  
   -LDOn   :   for LDOs, where n can lie in range 1 to 26.
 @@ -55,16 +55,14 @@ Example:
   reg = 0x09;
  
   voltage-regulators {
 - ldo11_reg {
 - regulator-compatible = LDO11;
 + ldo11_reg: LDO11 {
   regulator-name = vdd_ldo11;
   regulator-min-microvolt = 190;
   regulator-max-microvolt = 190;
   regulator-always-on;
   };
  
 - buck1_reg {
 - regulator-compatible = BUCK1;
 + buck1_reg: BUCK1 {
   regulator-name = vdd_mif;
   regulator-min-microvolt = 95;
   regulator-max-microvolt = 130;
 @@ -72,8 +70,7 @@ Example:
   regulator-boot-on;
   };
  
 - buck9_reg {
 - regulator-compatible = BUCK9;
 + buck9_reg: BUCK9 {
   regulator-name = CAM_ISP_CORE_1.2V;
   regulator-min-microvolt = 100;
   regulator-max-microvolt = 120;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/4] mfd: max77686: Use a generic name for the PMIC node in the example

[Lee Jones]

On Mon, 24 Aug 2015, Javier Martinez Canillas wrote:

 The ePAPR standard says that: the name of a node should be somewhat
 generic, reflecting the function of the device and not its precise
 programming model.
 
 So, change the max77686 binding document example to use a generic
 node name instead of using the chip's name.
 
 Suggested-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 
 ---
 
 Changes in v4:
 - Add Lee Jones Acked-by tag to patch #2.
 
 Changes in v3:
 - Fix typo in ePAPR document name. Suggested by Sergei Shtylyov
 
 Changes in v2: None
 
  Documentation/devicetree/bindings/mfd/max77686.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

 diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt 
 b/Documentation/devicetree/bindings/mfd/max77686.txt
 index 8221102d3fc2..d2ed3c20a5c3 100644
 --- a/Documentation/devicetree/bindings/mfd/max77686.txt
 +++ b/Documentation/devicetree/bindings/mfd/max77686.txt
 @@ -48,7 +48,7 @@ to get matched with their hardware counterparts as follow:
  
  Example:
  
 - max77686@09 {
 + max77686: pmic@09 {
   compatible = maxim,max77686;
   interrupt-parent = wakeup_eint;
   interrupts = 26 0;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/4] mfd: Add DT binding for Maxim MAX77802 IC

[Lee Jones]

On Mon, 24 Aug 2015, Javier Martinez Canillas wrote:

 The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
 a RTC and an I2C interface to program the individual components.
 
 The are already DT bindings for the regulators and clocks and
 these reference to a bindings/mfd/max77802.txt file, that didn't
 exist, for the details about the PMIC.
 
 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 
 ---
 
 Changes in v4:
 - Reword section about max77802 clock and regulator DT binding docs.
   Suggested by Lee Jones.
 - Align max77802 mfd required properties. Suggested by Lee Jones.
 
 Changes in v3:
 - Add Krzysztof Kozlowski Reviewed-by tag to patch #3.
 - Capitalise all acronyms. Suggested by Lee Jones.
 - Use relative path to refer other bindings. Suggested by Lee Jones.
 - Use IRQ_TYPE_NONE instead of 0 in example. Suggested by Lee Jones.
 
 Changes in v2:
 - Use the correct maxim,max77802 compatible string.
   Suggested by Krzysztof Kozlowski
 - Use a pmic generic node name for the max77802 node example.
   Suggested by Sergei Shtylyov.
 
  Documentation/devicetree/bindings/mfd/max77802.txt | 26 
 ++
  1 file changed, 26 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt

Applied, thanks.

 diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt 
 b/Documentation/devicetree/bindings/mfd/max77802.txt
 new file mode 100644
 index ..51fc1a60caa5
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mfd/max77802.txt
 @@ -0,0 +1,26 @@
 +Maxim MAX77802 multi-function device
 +
 +The Maxim MAX77802 is a Power Management IC (PMIC) that contains 10 high
 +efficiency Buck regulators, 32 Low-DropOut (LDO) regulators used to power
 +up application processors and peripherals, a 2-channel 32kHz clock outputs,
 +a Real-Time-Clock (RTC) and a I2C interface to program the individual
 +regulators, clocks outputs and the RTC.
 +
 +Bindings for the built-in 32k clock generator block and
 +regulators are defined in ../clk/maxim,max77802.txt and
 +../regulator/max77802.txt respectively.
 +
 +Required properties:
 +- compatible : Must be maxim,max77802
 +- reg: Specifies the I2C slave address of PMIC block.
 +- interrupts : I2C device IRQ line connected to the main SoC.
 +- interrupt-parent   : The parent interrupt controller.
 +
 +Example:
 +
 + max77802: pmic@09 {
 + compatible = maxim,max77802;
 + interrupt-parent = intc;
 + interrupts = 26 IRQ_TYPE_NONE;
 + reg = 0x09;
 + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Aug 24

[Stephen Rothwell]

Hi all,

Changes since 20150821:

New tree: rockchip

The arm-soc tree gained a conflict against Linus' tree.

The powerpc tree lost its build failure.

The xtensa tree gained a conflict againste the arm64 and tip trees.

The btrfs tree lost its build failure.

The nfs tree still had its build failure for which I disabled a staging
driver.

The net-next tree gained a build failure so I used the verison from
next-20150821.

The block tree gained conflicts against the btrfs tree.

The spi tree lost its build failure.

The kvm-ppc tree gained a conflict against the tip tree.

The tty tree still had its build failure for which I reverted part of
a commit.

The char-misc tree gained a conflict against the tip tree.

The akpm-current tree gained a conflict against the omap_dss2 tree.

Non-merge commits (relative to Linus' tree): 9385
 8226 files changed, 502992 insertions(+), 198015 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one.  You should use git fetch and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 225 trees (counting Linus' and 33 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (eb63b34bdfbd Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (3939f3345050 ARM: 8418/1: add boot image 
dependencies to not generate invalid images)
Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg())
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (f7644cbfcdf0 Linux 4.2-rc6)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (c953e23936f9 netlink: mmap: fix tx type check)
Merging ipsec/master (158cd4af8ded packet: missing dev_put() in 
packet_do_bind())
Merging sound-current/for-linus (f6b28e4ded45 ALSA: hda - Shutdown CX20722 on 
reboot/free to avoid spurious noises)
Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses 
on PA-RISC)
Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module 
parameter for MSI interrupts)
Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4)
Merging tty.current/tty-linus (cbfe8fa6cd67 Linux 4.2-rc4)
Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() 
call to error pathway)
Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 
LTE/EV-DO/HSPA+ Gobi 4G Module)
Merging staging.current/staging-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6)
Merging input-current/for-linus (1ae5ddb6f883 Input: gpio_keys_polled - request 
GPIO pin as input.)
Merging crypto-current/master (b310c178e6d8 crypto: caam - fix memory 
corruption in ahash_final_ctx)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (d65d31f17b5b module: Fix locking in 

[PATCH v2] mm: use only per-device readahead limit

[Roman Gushchin]

Maximal readahead size is limited now by two values:
1) by global 2Mb constant (MAX_READAHEAD in max_sane_readahead())
2) by configurable per-device value* (bdi-ra_pages)

There are devices, which require custom readahead limit.
For instance, for RAIDs it's calculated as number of devices
multiplied by chunk size times 2.

Readahead size can never be larger than bdi-ra_pages * 2 value
(POSIX_FADV_SEQUNTIAL doubles readahead size).

If so, why do we need two limits?
I suggest to completely remove this max_sane_readahead() stuff and
use per-device readahead limit everywhere.

Also, using right readahead size for RAID disks can significantly
increase i/o performance:

before:
dd if=/dev/md2 of=/dev/null bs=100M count=100
100+0 records in
100+0 records out
1048576 bytes (10 GB) copied, 12.9741 s, 808 MB/s

after:
$ dd if=/dev/md2 of=/dev/null bs=100M count=100
100+0 records in
100+0 records out
1048576 bytes (10 GB) copied, 8.91317 s, 1.2 GB/s

(It's an 8-disks RAID5 storage).

This patch doesn't change sys_readahead and madvise(MADV_WILLNEED)
behavior introduced by commit
6d2be915e589b58cb11418cbe1f22ff90732b6ac (mm/readahead.c: fix
readahead failure for memoryless NUMA nodes and limit readahead pages).

V2:
Konstantin Khlebnikov noticed, that if readahead is completely
disabled, force_page_cache_readahead() will not read anything.
This function is used for sync reads (if FMODE_RANDOM flag is set).
So, to guarantee read progress it's necessary to read at least 1 page.

Signed-off-by: Roman Gushchin kl...@yandex-team.ru
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Raghavendra K T raghavendra...@linux.vnet.ibm.com
Cc: Jan Kara j...@suse.cz
Cc: Wu Fengguang fengguang...@intel.com
Cc: David Rientjes rient...@google.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Konstantin Khlebnikov khlebni...@yandex-team.ru
---
 include/linux/mm.h |  2 --
 mm/filemap.c   |  8 +++-
 mm/readahead.c | 18 ++
 3 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2e872f9..a62abdd 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1942,8 +1942,6 @@ void page_cache_async_readahead(struct address_space 
*mapping,
pgoff_t offset,
unsigned long size);
 
-unsigned long max_sane_readahead(unsigned long nr);
-
 /* Generic expand stack which grows the stack according to GROWS{UP,DOWN} */
 extern int expand_stack(struct vm_area_struct *vma, unsigned long address);
 
diff --git a/mm/filemap.c b/mm/filemap.c
index 1283fc8..0e1ebef 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1807,7 +1807,6 @@ static void do_sync_mmap_readahead(struct vm_area_struct 
*vma,
   struct file *file,
   pgoff_t offset)
 {
-   unsigned long ra_pages;
struct address_space *mapping = file-f_mapping;
 
/* If we don't want any read-ahead, don't bother */
@@ -1836,10 +1835,9 @@ static void do_sync_mmap_readahead(struct vm_area_struct 
*vma,
/*
 * mmap read-around
 */
-   ra_pages = max_sane_readahead(ra-ra_pages);
-   ra-start = max_t(long, 0, offset - ra_pages / 2);
-   ra-size = ra_pages;
-   ra-async_size = ra_pages / 4;
+   ra-start = max_t(long, 0, offset - ra-ra_pages / 2);
+   ra-size = ra-ra_pages;
+   ra-async_size = ra-ra_pages / 4;
ra_submit(ra, mapping, file);
 }
 
diff --git a/mm/readahead.c b/mm/readahead.c
index 60cd846..7eb844c 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -213,7 +213,11 @@ int force_page_cache_readahead(struct address_space 
*mapping, struct file *filp,
if (unlikely(!mapping-a_ops-readpage  !mapping-a_ops-readpages))
return -EINVAL;
 
-   nr_to_read = max_sane_readahead(nr_to_read);
+   /*
+* Read at least 1 page, even if readahead is completely disabled.
+*/
+   nr_to_read = min(nr_to_read, max(inode_to_bdi(mapping-host)-ra_pages,
+1ul));
while (nr_to_read) {
int err;
 
@@ -232,16 +236,6 @@ int force_page_cache_readahead(struct address_space 
*mapping, struct file *filp,
return 0;
 }
 
-#define MAX_READAHEAD   ((512*4096)/PAGE_CACHE_SIZE)
-/*
- * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
- * sensible upper limit.
- */
-unsigned long max_sane_readahead(unsigned long nr)
-{
-   return min(nr, MAX_READAHEAD);
-}
-
 /*
  * Set the initial window size, round to next power of 2 and square
  * for small size, x 4 for medium, and x 2 for large
@@ -380,7 +374,7 @@ ondemand_readahead(struct address_space *mapping,
   bool hit_readahead_marker, pgoff_t offset,
   unsigned long req_size)
 {
-   unsigned long max = max_sane_readahead(ra-ra_pages);
+   unsigned long max = ra-ra_pages;
pgoff_t prev_offset;
 
/*
-- 
2.4.3

Re: [PATCH] Input: edt-ft5x06 - Switch to newer gpio framework

[Dmitry Torokhov]

On Fri, Aug 21, 2015 at 02:08:32PM -0500, Franklin S Cooper Jr wrote:
 The current/old gpio framework used doesn't properly listen to
 ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
 account these flags when setting gpio values.
 
 Also use gpiod_set_value_cansleep since wake and reset pins can be
 provided by bus based io expanders.
 
 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 ---
  .../bindings/input/touchscreen/edt-ft5x06.txt  |   4 +-
  drivers/input/touchscreen/edt-ft5x06.c | 115 
 +++--
  include/linux/input/edt-ft5x06.h   |   4 +-
  3 files changed, 43 insertions(+), 80 deletions(-)
 
 diff --git 
 a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
 b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
 index 76db967..9330d4d 100644
 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
 +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
 @@ -50,6 +50,6 @@ Example:
   pinctrl-0 = edt_ft5x06_pins;
   interrupt-parent = gpio2;
   interrupts = 5 0;
 - reset-gpios = gpio2 6 1;
 - wake-gpios = gpio4 9 0;
 + reset-gpios = gpio2 6 GPIO_ACTIVE_LOW;
 + wake-gpios = gpio4 9 GPIO_ACTIVE_HIGH;
   };
 diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
 b/drivers/input/touchscreen/edt-ft5x06.c
 index 394b1de..6b128b3 100644
 --- a/drivers/input/touchscreen/edt-ft5x06.c
 +++ b/drivers/input/touchscreen/edt-ft5x06.c
 @@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
   u16 num_x;
   u16 num_y;
  
 - int reset_pin;
 - int irq_pin;
 - int wake_pin;
 + struct gpio_desc *reset_pin;
 + struct gpio_desc *wake_pin;
 + struct gpio_desc *irq_pin;
  
  #if defined(CONFIG_DEBUG_FS)
   struct dentry *debug_dir;
 @@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct 
 edt_ft5x06_ts_data *tsdata)
  static int edt_ft5x06_ts_reset(struct i2c_client *client,
   struct edt_ft5x06_ts_data *tsdata)
  {
 - int error;
 -
 - if (gpio_is_valid(tsdata-wake_pin)) {
 - error = devm_gpio_request_one(client-dev,
 - tsdata-wake_pin, GPIOF_OUT_INIT_LOW,
 - edt-ft5x06 wake);
 - if (error) {
 - dev_err(client-dev,
 - Failed to request GPIO %d as wake pin, error 
 %d\n,
 - tsdata-wake_pin, error);
 - return error;
 - }
 -
 + if (tsdata-wake_pin) {
   msleep(5);
 - gpio_set_value(tsdata-wake_pin, 1);
 + gpiod_set_value_cansleep(tsdata-wake_pin, 1);
   }
 - if (gpio_is_valid(tsdata-reset_pin)) {
 - /* this pulls reset down, enabling the low active reset */
 - error = devm_gpio_request_one(client-dev,
 - tsdata-reset_pin, GPIOF_OUT_INIT_LOW,
 - edt-ft5x06 reset);
 - if (error) {
 - dev_err(client-dev,
 - Failed to request GPIO %d as reset pin, error 
 %d\n,
 - tsdata-reset_pin, error);
 - return error;
 - }
  
 + if (tsdata-reset_pin) {
   msleep(5);
 - gpio_set_value(tsdata-reset_pin, 1);
 + gpiod_set_value_cansleep(tsdata-reset_pin, 1);

So this leaves the reset pin active. How exactly was this tested?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V8 10/25] perf tools: Add example call-graph script

[Arnaldo Carvalho de Melo]

Em Mon, Aug 24, 2015 at 10:00:17AM +0300, Adrian Hunter escreveu:
 On 21/08/15 18:28, Arnaldo Carvalho de Melo wrote:
  Em Fri, Aug 21, 2015 at 12:21:25PM -0300, Arnaldo Carvalho de Melo escreveu:
  Em Fri, Aug 21, 2015 at 12:11:33PM -0300, Arnaldo Carvalho de Melo 
  escreveu:
  [acme@zoo ~]$ perf script -s 
  ~/libexec/perf-core/scripts/python/export-to-postgresql.py bts_example 
  branches calls
  2015-08-21 12:10:00.504126 Creating database...
  QSqlDatabase: QPSQL driver not loaded
  QSqlDatabase: available drivers: QSQLITE
  QSqlDatabase: an instance of QCoreApplication is required for loading 
  driver plugins
  QSqlQuery::exec: database not open
  Traceback (most recent call last):
File 
  /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py, 
  line 87, in module
  do_query(query, 'CREATE DATABASE ' + dbname)
File 
  /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py, 
  line 78, in do_query
  raise Exception(Query failed:  + q.lastError().text())
  Exception: Query failed: Driver not loaded Driver not loaded
  Error running python script 
  /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py
  [acme@zoo ~]$ 
 
  A-ha, this was missing:
 
  [root@zoo ~]# rpm -ql qt-postgresql 
  /usr/lib64/qt4/plugins/sqldrivers/libqsqlpsql.so
  [root@zoo ~]#
 
  [acme@zoo ~]$ perf script -s 
  ~/libexec/perf-core/scripts/python/export-to-postgresql.py bts_example 
  branches calls
  2015-08-21 12:20:01.841677 Creating database...
  2015-08-21 12:20:02.556853 Writing to intermediate files...
  2015-08-21 12:20:03.262814 Copying to database...
  2015-08-21 12:20:03.783109 Removing intermediate files...
  2015-08-21 12:20:03.790282 Adding primary keys
  2015-08-21 12:20:04.294342 Adding foreign keys
  2015-08-21 12:20:04.718238 Done
  [acme@zoo ~]$ 
 
  Now to the next steps... Lets see how this looks like with BTS...
  
  So, after running:
  
[acme@zoo linux]$ python
tools/perf/scripts/python/call-graph-from-postgresql.py bts_example
  
  I got a GUI and after expanding some callchains I took this screenshot:
  
http://vger.kernel.org/~acme/perf/call_graph_example_intel_bts.png
  
  Cool stuff! But it seems the COMM got messed up? I.e. that 1380:1380
  first level after ls.
 
 That is, in fact, correct.  The top-level is the process (comm).  The next
 level is the threads (pid/tid) for that process.  Currently, each thread is
 reported separately.

Ok, understood.

 For the future, there ought to be an option to combine the data for all
 threads of a process, or all processes with the same comm.  Also presently
 it is not tracking if a thread sets it's own comm (e.g. some multi-threaded
 applications name each thread).

And in that case it would be nice to have both the comms and pid/tid.

- Arnaldo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/sysctl.c: If count including the terminating byte '\0' the write system call should retrun success.

[Andrew Morton]

On Mon, 24 Aug 2015 23:33:58 +0800 Sean Fu fxinr...@gmail.com wrote:

 On Mon, Aug 24, 2015 at 8:27 PM, Eric W. Biederman
 ebied...@xmission.com wrote:
 
 
  On August 24, 2015 1:56:13 AM PDT, Sean Fu fxinr...@gmail.com wrote:
 when the input argument count including the terminating byte \0,
 The write system call return EINVAL on proc file.
 But it return success on regular file.
 
  Nonsense.  It will write the '\0' to a regular file because it is just data.
 
  Integers in proc are more than data.
 
  So I see no justification for this change.
 In fact, write(fd, 1\0, 2) on Integers proc file return success on
 2.6 kernel. I already tested it on 2.6.6.60 kernel.
 
 So, The latest behavior of write(fd, 1\0, 2) is different from old
 kernel(2.6).
 This maybe impact the compatibility of some user space program.

2.6 was a long time ago.  If this behaviour change has happened in the
last 1-2 kernel releases then there would be a case to consider making
changes.  But if the kernel has been this way for two years then it's
too late to bother switching back to the old (and strange) behaviour.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf: fix confusing messages when not able to read trace events files

[Jiri Olsa]

On Thu, Aug 20, 2015 at 02:52:01PM +0100, Matt Fleming wrote:

SNIP

  The err variable doesn't go down to the add_tracepoint_multi_event()
  call. It actually stops in parse_events_parse() where
  parse_events_add_tracepoint is being called using only the idx part of
  data (util/parse-events.y:389). I think it would be possible to pass
  the whole data variable (struct parse_events_evlist) down those
  variables to still have access to err, but it would imply quite a lot
  of changes in there. I'm up to it though, if it seems that's the right
  thing to do! What is your take on
 
 You bring up a good point. Perf would benefit greatly from easy access
 to a struct parse_events_error variable, so that it isn't required to
 pass it as an argument to every function.
 
 Now, I know that generally global variables are frowned upon but I
 think an exception can be made for error handling, because, assuming
 errors are fatal (and if they're not they're called warnings), you
 should never have multiple things writing to it at the same time, and
 you should only ever execute error paths once you've written to it.
 
 And if you really, really don't like naked accesses to global
 variables you can always use a wrapper function.
 
 With global access to error data it becomes trivial to improve the
 error handling of other functions in a piecemeal way, without
 requiring changes to every function in the callstack. No one likes
 reviewing large patches ;-)
 
 I would suggest setting up a global struct parse_events_error object,
 and making changes to parse_events_print_error() to handle non-parse
 related errors, such as ENOMEM, ENOENT, etc, etc.

hum, I haven't digested all of this thread yet, but I happened
to actually work on this recently - the tracepoint parsing
error propagation ... I did some initial patchset not ready
to be posted but working, please check it in:
  https://git.kernel.org/cgit/linux/kernel/git/jolsa/perf.git/log/?h=perf/tp_5

tracefs and debugfs just give location for accessing tracepoint,
the tracing_events_path is currently initialized to one of them

we could somehow prettyfy it, like unify all the related
interface to make it clear, like the debugfs__strerror_open
shouldn't be 'debugfs' specific and take tracefs into account
as in my patchset

jirka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Tejun Heo]

Hello,

On Mon, Aug 24, 2015 at 01:54:08PM -0700, Paul Turner wrote:
  That alone doesn't require hierarchical resource distribution tho.
  Setting nice levels reasonably is likely to alleviate most of the
  problem.
 
 Nice is not sufficient here.  There could be arbitrarily many threads
 within the hypervisor that are not actually hosting guest CPU threads.
 The only way to have this competition occur at a reasonably fixed
 ratio is a sub-hierarchy.

I get that having hierarchy of threads would be nicer but am having a
bit of difficulty seeing why adjusting priorities of threads wouldn't
be sufficient.  It's not like threads of the same process competing
with each other is a new problem.  People have been dealing with it
for ages.  Hierarchical management can be a nice plus but we want the
problem and proposed solution to be justifiable.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT PATCH] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Russell King - ARM Linux]

On Tue, Aug 18, 2015 at 03:40:01PM +0530, Keerthy wrote:
 Currently apart from dra7, omap5 and amx3 all the other SoCs
 are identified using cpu_is_* functions which is not right since
 they are all SoCs(System on Chips). Hence changing the SoC
 identificätion code to use soc_is instead of cpu_is and keeping
   ^
typo

 defines for cpu_is where needed. This allows us to replace the
 rest of cpu_is usage along with other fixes as needed.

Good to see this change to a more sensible naming of these, despite
the obvious churn.

Acked-by: Russell King rmk+ker...@arm.linux.org.uk

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/sysctl.c: If count including the terminating byte '\0' the write system call should retrun success.

[Heinrich Schuchardt]

This seems to be the relevant patch:

https://lkml.org/lkml/2010/5/5/104
Amerigo Wang amw...@redhat.com  2010-05-05 02:26:45
00b7c3395aec3df43de5bd02a3c5a099ca51169f
+static const char proc_wspace_sep[] = { ' ', '\t', '\n' };

So since 2010 we have the current behavior.

Best regards

Heinrich Schuchardt

On 24.08.2015 22:44, Andrew Morton wrote:
 On Mon, 24 Aug 2015 23:33:58 +0800 Sean Fu fxinr...@gmail.com wrote:
 
 On Mon, Aug 24, 2015 at 8:27 PM, Eric W. Biederman
 ebied...@xmission.com wrote:


 On August 24, 2015 1:56:13 AM PDT, Sean Fu fxinr...@gmail.com wrote:
 when the input argument count including the terminating byte \0,
 The write system call return EINVAL on proc file.
 But it return success on regular file.

 Nonsense.  It will write the '\0' to a regular file because it is just data.

 Integers in proc are more than data.

 So I see no justification for this change.
 In fact, write(fd, 1\0, 2) on Integers proc file return success on
 2.6 kernel. I already tested it on 2.6.6.60 kernel.

 So, The latest behavior of write(fd, 1\0, 2) is different from old
 kernel(2.6).
 This maybe impact the compatibility of some user space program.
 
 2.6 was a long time ago.  If this behaviour change has happened in the
 last 1-2 kernel releases then there would be a case to consider making
 changes.  But if the kernel has been this way for two years then it's
 too late to bother switching back to the old (and strange) behaviour.
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] MAINTAINERS: update vmxnet3 driver maintainer

[Shrikrishna Khare]

Shreyas Bhatewara would no longer maintain the vmxnet3 driver. Taking over
the role of vmxnet3 maintainer.

Signed-off-by: Shrikrishna Khare skh...@vmware.com
Signed off-by: Shreyas Bhatewara sbhatew...@vmware.com
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4e6dcb6..2963a89 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11053,7 +11053,7 @@ F:  drivers/input/mouse/vmmouse.c
 F: drivers/input/mouse/vmmouse.h
 
 VMWARE VMXNET3 ETHERNET DRIVER
-M: Shreyas Bhatewara sbhatew...@vmware.com
+M: Shrikrishna Khare skh...@vmware.com
 M: VMware, Inc. pv-driv...@vmware.com
 L: net...@vger.kernel.org
 S: Maintained
-- 
1.8.5.6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 4/4] Use 2GB memory block size on large-memory x86-64 systems

[Yinghai Lu]

On Mon, Aug 24, 2015 at 1:41 PM, Tony Luck tony.l...@gmail.com wrote:
 On Mon, Aug 24, 2015 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
 Then, what does the E820 look like?

 See attached serial console log of the latest crash

Can you boot with debug ignore_loglevel so we can see following print out
for vmemmap?

[0.352486]  [ea00-ea0001ff] PMD -
[88007de0-88007fdf] on node 0
[0.358758]  [ea000400-ea0005ff] PMD -
[88017d60-88017f5f] on node 1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

[Olof Johansson]

On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote:
 Easiest of all would probably be to get the sub-arch patches into one
 release, then switch the prototypes and function definitions in the
 next. If you switch prototypes first you'll get a bunch of warnings,
 right?

 Wrong way around. :)

 If you change the sub-arches to declare the smp operations as const,
 and try and pass them into a function which doesn't take a const-pointer,
 you'll get a warning.  The core bits need to go in first before the
 sub-arch patches.

Ah yes, my bad.

 I think the series has limited value - it allows us to (a) check that a
 small quantity of code doesn't write to these things, and (b) allows us
 to move the SMP operations structure from __initdata to __initconstdata.
 It's still going to end up in the init region which is read/write in any
 case, and still gets thrown away.

 Given where we are, I don't think we need to rush this in during the
 last week before the merge window opens, even though it's trivial.

Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] ARM: uniphier: add outer cache support

[Arnd Bergmann]

On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote:
 diff --git 
 a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt 
 b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
 new file mode 100644
 index 000..6428289
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
 @@ -0,0 +1,30 @@
 +UniPhier outer cache controller
 +
 +UniPhier SoCs are integrated with a level 2 cache controller that resides
 +outside of the ARM cores, some of them also have a level 3 cache controller.
 +
 +Required properties:
 +- compatible: should be one of the followings:
 +   socionext,uniphier-l2-cache   (L2 cache)
 +   socionext,uniphier-l3-cache   (L3 cache)
 +- reg: offsets and lengths of the register sets for the device.  It should
 +  contain 3 regions: control registers, revision registers, operation
 +  registers, in this order.
 +
 +The L2 cache must exist to use the L3 cache; adding only an L3 cache device
 +node to the device tree causes the initialization failure of the whole outer
 +cache system.
 

How much does this outer cache have in common with the l2x0/pl310 cache
controller model? Would it make sense to at least share the
common entry point at l2x0_of_init() so you don't need to call it from
the platform file?

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lib: scatterlist: add sg splitting function

[Jens Axboe]

On 08/08/2015 02:44 AM, Robert Jarzmik wrote:

Sometimes a scatter-gather has to be split into several chunks, or sub
scatter lists. This happens for example if a scatter list will be
handled by multiple DMA channels, each one filling a part of it.

A concrete example comes with the media V4L2 API, where the scatter list
is allocated from userspace to hold an image, regardless of the
knowledge of how many DMAs will fill it :
  - in a simple RGB565 case, one DMA will pump data from the camera ISP
to memory
  - in the trickier YUV422 case, 3 DMAs will pump data from the camera
ISP pipes, one for pipe Y, one for pipe U and one for pipe V

For these cases, it is necessary to split the original scatter list into
multiple scatter lists, which is the purpose of this patch.

The guarantees that are required for this patch are :
  - the intersection of spans of any couple of resulting scatter lists is
empty.
  - the union of spans of all resulting scatter lists is a subrange of
the span of the original scatter list.
  - streaming DMA API operations (mapping, unmapping) should not happen
both on both the resulting and the original scatter list. It's either
the first or the later ones.
  - the caller is reponsible to call kfree() on the resulting
scatterlists.

Signed-off-by: Robert Jarzmik robert.jarz...@free.fr


I think this looks fine. But do we really need the Kconfig option? It's 
not a lot of code, and it seems silly to put the onus on the driver for 
having to enable something that is a subset of the SG api.


--
Jens Axboe

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared

[Eugene Shatokhin]

It is needed to check EVENT_NO_RUNTIME_PM bit of dev-flags in
usbnet_stop(), but its value should be read before it is cleared
when dev-flags is set to 0.

The problem was spotted and the fix was provided by
Oliver Neukum oneu...@suse.de.

Signed-off-by: Eugene Shatokhin eugene.shatok...@rosalab.ru
---
 drivers/net/usb/usbnet.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 3c86b10..e049857 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -778,7 +778,7 @@ int usbnet_stop (struct net_device *net)
 {
struct usbnet   *dev = netdev_priv(net);
struct driver_info  *info = dev-driver_info;
-   int retval, pm;
+   int retval, pm, mpn;
 
clear_bit(EVENT_DEV_OPEN, dev-flags);
netif_stop_queue (net);
@@ -809,6 +809,8 @@ int usbnet_stop (struct net_device *net)
 
usbnet_purge_paused_rxq(dev);
 
+   mpn = !test_and_clear_bit(EVENT_NO_RUNTIME_PM, dev-flags);
+
/* deferred work (task, timer, softirq) must also stop.
 * can't flush_scheduled_work() until we drop rtnl (later),
 * else workers could deadlock; so make workers a NOP.
@@ -819,8 +821,7 @@ int usbnet_stop (struct net_device *net)
if (!pm)
usb_autopm_put_interface(dev-intf);
 
-   if (info-manage_power 
-   !test_and_clear_bit(EVENT_NO_RUNTIME_PM, dev-flags))
+   if (info-manage_power  mpn)
info-manage_power(dev, 0);
else
usb_autopm_put_interface(dev-intf);
-- 
2.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pci: acpi: Generic function for setting up PCI device DMA coherency

[Bjorn Helgaas]

On Mon, Aug 24, 2015 at 12:09 PM, Suravee Suthikulpanit
suravee.suthikulpa...@amd.com wrote:

 commit 84cfb2213cd400fef227ec0d7829ec4e12895da9
 Author: Bjorn Helgaas bhelg...@google.com
 Date:   Thu Aug 13 19:49:52 2015 -0500

  ACPI / scan: Rename acpi_check_dma() to acpi_dma_is_coherent()

  The name acpi_check_dma() doesn't give any much indication about
 what
  exactly it checks.  The function also returns information both as a
 normal
  return value and as the bool *coherent return parameter.  But
 *coherent
  doesn't actually give any extra information: it is unchanged when
 returning
  false and set to true when returning true.

  Rename acpi_check_dma() to acpi_dma_is_coherent() so the callers
 read more
  naturally.  Drop the return parameter and just use the function
 return
  value.

  Signed-off-by: Bjorn Helgaas bhelg...@google.com


 This was because, at one point, we wanted to be able to differentiate
 between the case _CCA=0 and missing _CCA in ARM64, where we would support
 DMA (using arch-specific cache maintenance) if _CCA=0, and disable DMA when
 missing _CCA on ARM64.

 It seems like the logic is now required (please see
 https://www.mail-archive.com/linux-usb@vger.kernel.org/msg62735.html). So,
 we would need the true/false return, and the coherent variable to be able to
 differentiate between the two cases.

 Please let me know what you think.

It's hard for me to comment without seeing the actual patches.  I
think returning two values (_CCA-seen and coherent) is a confusing
interface.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Tejun Heo]

Hello, Austin.

On Mon, Aug 24, 2015 at 04:00:49PM -0400, Austin S Hemmelgarn wrote:
 That alone doesn't require hierarchical resource distribution tho.
 Setting nice levels reasonably is likely to alleviate most of the
 problem.

 In the cases I've dealt with this myself, nice levels didn't cut it, and I
 had to resort to SCHED_RR with particular care to avoid priority inversions.

I wonder why.  The difference between -20 and 20 is around 2500x in
terms of weight.  That should have been enough for expressing whatever
precedence the vcpus should have over other threads.

 I don't know.  Someone running one or two VM's on a laptop under
 QEMU doesn't really sound like the use case which absolutely requires
 hierarchical cpu cycle distribution.

 It depends on the use case.  I never have more than 2 VM's running on my
 laptop (always under QEMU, setting up Xen is kind of pointless ona quad core
 system with only 8G of RAM), and I take extensive advantage of the cpu
 cgroup to partition resources among various services on the host.

Hmmm... I'm trying to understand the usecases where having hierarchy
inside a process are actually required so that we don't end up doing
something complex unnecessarily.  So far, it looks like an easy
alternative for qemu would be teaching it to manage priorities of its
threads given that the threads are mostly static - vcpus going up and
down are explicit operations which can trigger priority adjustments if
necessary, which is unlikely to begin with.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Paul Turner]

On Mon, Aug 24, 2015 at 10:04 AM, Tejun Heo t...@kernel.org wrote:
 Hello, Austin.

 On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote:
 Just to learn more, what sort of hypervisor support threads are we
 talking about?  They would have to consume considerable amount of cpu
 cycles for problems like this to be relevant and be dynamic in numbers
 in a way which letting them competing against vcpus makes sense.  Do
 IO helpers meet these criteria?
 
 Depending on the configuration, yes they can.  VirtualBox has some rather
 CPU intensive threads that aren't vCPU threads (their emulated APIC thread
 immediately comes to mind), and so does QEMU depending on the emulated

 And the number of those threads fluctuate widely and dynamically?

 hardware configuration (it gets more noticeable when the disk images are
 stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is
 pretty typical usage for large virtualization deployments).  I've seen cases
 first hand where the vCPU's can make no reasonable progress because they are
 constantly getting crowded out by other threads.

 That alone doesn't require hierarchical resource distribution tho.
 Setting nice levels reasonably is likely to alleviate most of the
 problem.

Nice is not sufficient here.  There could be arbitrarily many threads
within the hypervisor that are not actually hosting guest CPU threads.
The only way to have this competition occur at a reasonably fixed
ratio is a sub-hierarchy.


 The use of the term 'hypervisor support threads' for this is probably not
 the best way of describing the contention, as it's almost always a full
 system virtualization issue, and the contending threads are usually storage
 back-end access threads.

 I would argue that there are better ways to deal properly with this (Isolate
 the non vCPU threads on separate physical CPU's from the hardware emulation
 threads), but such methods require large systems to be practical at any
 scale, and many people don't have the budget for such large systems, and
 this way of doing things is much more flexible for small scale use cases
 (for example, someone running one or two VM's on a laptop under QEMU or
 VirtualBox).

 I don't know.  Someone running one or two VM's on a laptop under
 QEMU doesn't really sound like the use case which absolutely requires
 hierarchical cpu cycle distribution.


We run more than 'one or two' VMs using this configuration.  :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Proposal for finishing the 64-bit x86 syscall cleanup

[Andy Lutomirski]

Hi all-

I want to (try to) mostly or fully get rid of the messy bits (as
opposed to the hardware-bs-forced bits) of the 64-bit syscall asm.
There are two major conceptual things that are in the way.

Thing 1: partial pt_regs

64-bit fast path syscalls don't fully initialize pt_regs: bx, bp, and
r12-r15 are uninitialized.  Some syscalls require them to be
initialized, and they have special awful stubs to do it.  The entry
and exit tracing code (except for phase1 tracing) also need them
initialized, and they have their own messy initialization.  Compat
syscalls are their own private little mess here.

This gets in the way of all kinds of cleanups, because C code can't
switch between the full and partial pt_regs states.

I can see two ways out.  We could remove the optimization entirely,
which consists of pushing and popping six more registers and adds
about ten cycles to fast path syscalls on Sandy Bridge.  It also
simplifies and presumably speeds up the slow paths.

We could also annotate with syscalls need full regs and jump to the
slow path for them.  This would leave the fast path unchanged (we
could duplicate the sys call table so that regs-requiring syscalls
would turn into some asm that switches to the slow path).  We'd make
the syscall table say something like:

59  64  execve  sys_execve:regs

The fast path would have exactly identical performance and the slow
path would presumably speed up.  The down side would be additional
complexity.

Thing 2: vdso compilation with binutils that doesn't support .cfi directives

Userspace debuggers really like having the vdso properly
CFI-annotated, and the 32-bit fast syscall entries are annotatied
manually in hexidecimal.  AFAIK Jan Beulich is the only person who
understands it.

I want to be able to change the entries a little bit to clean them up
(and possibly rework the SYSCALL32 and SYSENTER register tricks, which
currently suck), but it's really, really messy right now because of
the hex CFI stuff.  Could we just drop the CFI annotations if the
binutils version is too old or even just require new enough binutils
to build 32-bit and compat kernels?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] convert null test to IS_ERR test

[Julia Lawall]

Since commit 323de9efdf3e (pinctrl: make pinctrl_register() return proper
error code), pinctrl_register returns an error code rather than NULL on
failure.  Most drivers were updated at that time.  Update some drivers that
were introduced more recently.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] pinctrl: digicolor: convert null test to IS_ERR test

[Julia Lawall]

Since commit 323de9efdf3e (pinctrl: make pinctrl_register() return proper
error code), pinctrl_register returns an error code rather than NULL on
failure.  Update a driver that was introduced more recently.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// smpl
@@
expression e,e1,e2;
@@

e = pinctrl_register(...)
... when != e = e1
if (
-   e == NULL
+   IS_ERR(e)
   ) {
 ...
 return
-  e2
+  PTR_ERR(e)
 ;
 }
// /smpl

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
 drivers/pinctrl/pinctrl-digicolor.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-digicolor.c 
b/drivers/pinctrl/pinctrl-digicolor.c
index 461fffc..11f8b83 100644
--- a/drivers/pinctrl/pinctrl-digicolor.c
+++ b/drivers/pinctrl/pinctrl-digicolor.c
@@ -337,9 +337,9 @@ static int dc_pinctrl_probe(struct platform_device *pdev)
pmap-dev = pdev-dev;
 
pmap-pctl = pinctrl_register(pctl_desc, pdev-dev, pmap);
-   if (!pmap-pctl) {
+   if (IS_ERR(pmap-pctl)) {
dev_err(pdev-dev, pinctrl driver registration failed\n);
-   return -EINVAL;
+   return PTR_ERR(pmap-pctl);
}
 
ret = dc_gpiochip_add(pmap, pdev-dev.of_node);

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] pinctrl: qcom: ssbi: convert null test to IS_ERR test

[Julia Lawall]

Since commit 323de9efdf3e (pinctrl: make pinctrl_register() return proper
error code), pinctrl_register returns an error code rather than NULL on
failure.  Update some drivers that were introduced more recently.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// smpl
@@
expression e,e1,e2;
@@

e = pinctrl_register(...)
... when != e = e1
if (
-   e == NULL
+   IS_ERR(e)
   ) {
 ...
 return
-  e2
+  PTR_ERR(e)
 ;
 }
// /smpl

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
 drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c |4 ++--
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c  |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
index c978b31..e1a3721 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
@@ -723,9 +723,9 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
 #endif
 
pctrl-pctrl = pinctrl_register(pctrl-desc, pdev-dev, pctrl);
-   if (!pctrl-pctrl) {
+   if (IS_ERR(pctrl-pctrl)) {
dev_err(pdev-dev, couldn't register pm8xxx gpio driver\n);
-   return -ENODEV;
+   return PTR_ERR(pctrl-pctrl);
}
 
pctrl-chip = pm8xxx_gpio_template;
diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c 
b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
index 2d1b69f..6652b8d 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
@@ -814,9 +814,9 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
 #endif
 
pctrl-pctrl = pinctrl_register(pctrl-desc, pdev-dev, pctrl);
-   if (!pctrl-pctrl) {
+   if (IS_ERR(pctrl-pctrl)) {
dev_err(pdev-dev, couldn't register pm8xxx mpp driver\n);
-   return -ENODEV;
+   return PTR_ERR(pctrl-pctrl);
}
 
pctrl-chip = pm8xxx_mpp_template;

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Next round: revised futex(2) man page for review

[Darren Hart]

On Sat, Aug 08, 2015 at 08:57:35AM +0200, Michael Kerrisk (man-pages) wrote:

...

  .\ FIXME = End of adapted Hart/Guniguntala text =
 
 
 
  .\ FIXME We need some explanation in the following paragraph of *why*
  .\   it is important to note that the kernel will update the
  .\   futex word's value prior
 It is important to note to returning to user space . Can someone
 explain?   that  the  kernel  will  update the futex word's value
 prior to returning to user space.  Unlike the other futex  opera‐
 tions  described  above, the PI futex operations are designed for
 the implementation of very specific IPC mechanisms.
  
  If the kernel didn't perform the update prior to returning to userspace,
  we could end up in an invalid state. Such as having an owner, but the
  value being 0. Or having waiters, but not having FUTEX_WAITERS set.
 
 So I've now reworked this passage to read:
 
It  is  important  to  note that the kernel will update the futex
word's value prior to returning to user  space.   (This  prevents
the possibility of the futex word's value ending up in an invalid
state, such as having an owner but the value being 0,  or  having
waiters but not having the FUTEX_WAITERS bit set.)
 
 Okay?

Yes.

 
  .\
  .\ FIXME XXX In discussing errors for FUTEX_CMP_REQUEUE_PI, Darren Hart
  .\   made the observation that EINVAL is returned if the non-pi 
  .\   to pi or op pairing semantics are violated.
  .\   Probably there needs to be a general statement about this
  .\   requirement, probably located at about this point in the page.
  .\   Darren (or someone else), care to take a shot at this?
  
  We can probably borrow from either the futex.c comments or the
  futex-requeue-pi.txt in Documentation. Also, it is important to note
  that the PI requeue operations require two distinct uadders (although
  that is implied by requiring non-pi to pi as a futex cannot be both.
  
  Or... perhaps something like:
  
  Due to the kernel imposed futex word value policy, PI futex
  operations have additional usage requirements:
  
  FUTEX_WAIT_REQUEUE_PI must be paired with FUTEX_CMP_REQUEUE_PI
  and be performed from a non-pi futex to a distinct pi futex.
  Failing to do so will return EINVAL. 
 
 For which operation does the EINVAL occur: FUTEX_WAIT_REQUEUE_PI or 
 FUTEX_CMP_REQUEUE_PI?

FUTEX_WAIT_REQUEUE_PI can return -EINVAL if called with invalid parameters, such
as uaddr==uaddr2, or (in the case of SHARED futexes), the associated keys match
(meaning it's the same futex word - shared memory, inode, etc.). This can't
happen if the stated policy of requeueing from non-pi to pi is followed as the
same word cannot be both non-pi and pi at the same time, requiring them to be
unique futex words.

FUTEX_CMP_REQUEUE_PI will fail similarly if uaddr and uaddr2 are the same futex
word. Also, if nr_wake != 1.

But, to the point I was making above, FUTEX_CMP_REQUEUE_PI must reque uaddr to
same uaddr2 specified in the previous FUTEX_WAIT_REQUEUE_PI call.
FUTEX_WAIT_REQUEUE_PI sets up the operation, FUTEX_CMP_REQUEUE_PI completes it,
and they must agree on uaddr and uaddr2.

...

  And their PRIVATE counterparts of course (which is assumed as it is a
  flag to the opcode).
 
 Yes. But I don't think that needs to be called out explicitly here (?).


Agreed.

 
  .\ FIXME XXX = Start of adapted Hart/Guniguntala text =
  .\   The following text is drawn from the Hart/Guniguntala paper
  .\   (listed in SEE ALSO), but I have reworded some pieces
  .\   significantly. Please check it.
 
 The PI futex operations described below  differ  from  the  other
 futex  operations  in  that  they impose policy on the use of the
 value of the futex word:
 
 *  If the lock is not acquired, the futex word's value  shall  be
0.
 
 *  If  the  lock is acquired, the futex word's value shall be the
thread ID (TID; see gettid(2)) of the owning thread.
 
 *  If the lock is owned and there are threads contending for  the
lock,  then  the  FUTEX_WAITERS  bit shall be set in the futex
word's value; in other words, this value is:
 
FUTEX_WAITERS | TID
 
 
 Note that a PI futex word never just has the value FUTEX_WAITERS,
 which is a permissible state for non-PI futexes.
  
  The second clause is inappropriate. I don't know if that was yours or
  mine, but non-PI futexes do not have a kernel defined value policy, so
  ==FUTEX_WAITERS cannot be a permissible state as any value is
  permissible for non-PI futexes, and none have a kernel defined state.
  
  Perhaps include a Note under the third bullet as:
  
Note: It is invalid for a PI futex word to have no owner and
  FUTEX_WAITERS set.
 
 Done.
 
 With this policy in place, a user-space 

Re: [PATCH RFC 2/2] staging: fbtft: fix 9-bit SPI support detection

[Noralf Trønnes]

Den 24.08.2015 20:33, skrev Stefan Wahren:

Since bits_per_word isn't usually checked during SPI setup the 9-bit
support must be checked manually.

Signed-off-by: Stefan Wahren stefan.wah...@i2se.com
---
  drivers/staging/fbtft/fbtft-core.c |7 +++
  drivers/staging/fbtft/flexfb.c |7 +++
  2 files changed, 14 insertions(+)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 3638554..bd71487 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1438,6 +1438,13 @@ int fbtft_probe_common(struct fbtft_display *display,
if (par-spi  display-buswidth == 9) {
par-spi-bits_per_word = 9;
ret = spi_setup(par-spi);
+   if (!ret) {
+   struct spi_master *ma = par-spi-master;
+
+   if (!(ma-bits_per_word_mask  SPI_BPW_MASK(9)))
+   ret = -EINVAL;
+   }
+
if (ret) {


There's no point in calling spi_setup() when it doesn't check bits_per_word.
Apparently this changed with the commit:
spi: convert drivers to use bits_per_word_mask.
This has not been detected earlier, because FBTFT was previously mostly
used on the Raspberry Pi which had a downstream SPI driver that did this 
check.


How about this:

-par-spi-bits_per_word = 9;
-ret = par-spi-master-setup(par-spi);
+if (par-spi-master-bits_per_word_mask  
SPI_BPW_MASK(9)) {

+par-spi-bits_per_word = 9;
-if (ret) {
+} else {
 dev_warn(par-spi-dev,
 9-bit SPI not available, emulating 
using 8-bit.\n);

-par-spi-bits_per_word = 8;
-ret = par-spi-master-setup(par-spi);
-if (ret)
-goto out_release;
 /* allocate buffer with room for dc bits */
 par-extra = devm_kzalloc(par-info-device,

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/18] ARM: qcom: use const and __initconst for smp_operations

[Andy Gross]

On Mon, Aug 24, 2015 at 01:36:11PM +0900, Masahiro Yamada wrote:
 The smp_operations structure is not over-written, so add const
 qualifier and replace __initdata with __initconst.
 
 Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
 ---

Thanks!

Reviewed-by: Andy Gross agr...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Austin S Hemmelgarn]

On 2015-08-24 13:04, Tejun Heo wrote:

Hello, Austin.

On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote:

Just to learn more, what sort of hypervisor support threads are we
talking about?  They would have to consume considerable amount of cpu
cycles for problems like this to be relevant and be dynamic in numbers
in a way which letting them competing against vcpus makes sense.  Do
IO helpers meet these criteria?


Depending on the configuration, yes they can.  VirtualBox has some rather
CPU intensive threads that aren't vCPU threads (their emulated APIC thread
immediately comes to mind), and so does QEMU depending on the emulated


And the number of those threads fluctuate widely and dynamically?
It depends, usually there isn't dynamic fluctuation unless there is a 
lot of hot[un]plugging of virtual devices going on (which can be the 
case for situations with tight host/guest integration), but the number 
of threads can vary widely between configurations (most of the VM's I 
run under QEMU have about 16 threads on average, but I've seen instances 
with more than 100 threads).  The most likely case to cause wide and 
dynamic fluctuations of threads would be systems set up to dynamically 
hot[un]plug vCPU's based on system load (such systems have other issues 
to contend with also, but they do exist).

hardware configuration (it gets more noticeable when the disk images are
stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is
pretty typical usage for large virtualization deployments).  I've seen cases
first hand where the vCPU's can make no reasonable progress because they are
constantly getting crowded out by other threads.


That alone doesn't require hierarchical resource distribution tho.
Setting nice levels reasonably is likely to alleviate most of the
problem.
In the cases I've dealt with this myself, nice levels didn't cut it, and 
I had to resort to SCHED_RR with particular care to avoid priority 
inversions.

The use of the term 'hypervisor support threads' for this is probably not
the best way of describing the contention, as it's almost always a full
system virtualization issue, and the contending threads are usually storage
back-end access threads.

I would argue that there are better ways to deal properly with this (Isolate
the non vCPU threads on separate physical CPU's from the hardware emulation
threads), but such methods require large systems to be practical at any
scale, and many people don't have the budget for such large systems, and
this way of doing things is much more flexible for small scale use cases
(for example, someone running one or two VM's on a laptop under QEMU or
VirtualBox).


I don't know.  Someone running one or two VM's on a laptop under
QEMU doesn't really sound like the use case which absolutely requires
hierarchical cpu cycle distribution.
It depends on the use case.  I never have more than 2 VM's running on my 
laptop (always under QEMU, setting up Xen is kind of pointless ona quad 
core system with only 8G of RAM), and I take extensive advantage of the 
cpu cgroup to partition resources among various services on the host.





smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH 5/5] [resend] gxt4500: enable panning

[Ondrej Zary]

The driver implements pan_display but the corresponding flags are not set.

Add FBINFO_HWACCEL_XPAN and FBINFO_HWACCEL_YPAN to flags to allow HW
accelerated panning (for fast scrolling).

Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
 drivers/video/fbdev/gxt4500.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index e0d1550..88a3cf6 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -685,7 +685,8 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 #endif
 
info-fbops = gxt4500_ops;
-   info-flags = FBINFO_FLAG_DEFAULT;
+   info-flags = FBINFO_FLAG_DEFAULT | FBINFO_HWACCEL_XPAN |
+   FBINFO_HWACCEL_YPAN;
 
err = fb_alloc_cmap(info-cmap, 256, 0);
if (err) {
-- 
Ondrej Zary

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] [resend] gxt4500: enable on non-PPC architectures

[Ondrej Zary]

These chips can be present at least on x86 too - Fire GL2 AGP has GXT6000P but
this driver is currently limited to PPC.
Enable it for all architectures and add chip configuration for little-endian.

Tested on x86 with Fire GL2 AGP.

Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
 drivers/video/fbdev/Kconfig   |5 +++--
 drivers/video/fbdev/gxt4500.c |7 +++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d98de5..78335bd 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2132,7 +2132,7 @@ config FB_UDL
 
 config FB_IBM_GXT4500
tristate Framebuffer support for IBM GXT4000P/4500P/6000P/6500P 
adaptors
-   depends on FB  PPC
+   depends on FB
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2140,7 +2140,8 @@ config FB_IBM_GXT4500
  Say Y here to enable support for the IBM GXT4000P/6000P and
  GXT4500P/6500P display adaptor based on Raster Engine RC1000,
  found on some IBM System P (pSeries) machines. This driver
- doesn't use Geometry Engine GT1000.
+ doesn't use Geometry Engine GT1000. This driver also supports
+ AGP Fire GL2/3/4 cards on x86.
 
 config FB_PS3
tristate PS3 GPU framebuffer driver
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..1bf9894 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -670,8 +670,15 @@ static int gxt4500_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
pci_set_drvdata(pdev, info);
 
+#ifdef __BIG_ENDIAN
/* Set byte-swapping for DFA aperture for all pixel sizes */
pci_write_config_dword(pdev, CFG_ENDIAN0, 0x00);
+#else /* __LITTLE_ENDIAN */
+   /* not sure what this means but fgl23 driver does that */
+   pci_write_config_dword(pdev, CFG_ENDIAN0, 0x2300);
+/* pci_write_config_dword(pdev, CFG_ENDIAN0 + 4, 0x40);*/
+   pci_write_config_dword(pdev, CFG_ENDIAN0 + 8, 0x9853);
+#endif
 
info-fbops = gxt4500_ops;
info-flags = FBINFO_FLAG_DEFAULT;
-- 
Ondrej Zary

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] [resend] gxt4500: Make usable on x86 and fix some bugs

[Ondrej Zary]

Fire GL2 AGP has GXT6000P and is a x86 card but the gxt4500 driver is
currently limited to PPC.

This patch series makes the driver work on x86 and fixes some color problems.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] [resend] gxt4500: Use write-combining for framebuffer

[Ondrej Zary]

Use write-combining for framebuffer to greatly improve performance on x86.

Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
 drivers/video/fbdev/gxt4500.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 442b07c..e0d1550 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -142,7 +142,7 @@ static const unsigned char watfmt[] = {
 
 struct gxt4500_par {
void __iomem *regs;
-
+   int wc_cookie;
int pixfmt; /* pixel format, see DFA_PIX_* values */
 
/* PLL parameters */
@@ -663,7 +663,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
info-fix.smem_start = fb_phys;
info-fix.smem_len = pci_resource_len(pdev, 1);
-   info-screen_base = pci_ioremap_bar(pdev, 1);
+   info-screen_base = ioremap_wc(fb_phys, info-fix.smem_len);
if (!info-screen_base) {
dev_err(pdev-dev, gxt4500: cannot map framebuffer\n);
goto err_unmap_regs;
@@ -671,6 +671,9 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
pci_set_drvdata(pdev, info);
 
+   par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
+
 #ifdef __BIG_ENDIAN
/* Set byte-swapping for DFA aperture for all pixel sizes */
pci_write_config_dword(pdev, CFG_ENDIAN0, 0x00);
@@ -735,6 +738,7 @@ static void gxt4500_remove(struct pci_dev *pdev)
return;
par = info-par;
unregister_framebuffer(info);
+   arch_phys_wc_del(par-wc_cookie);
fb_dealloc_cmap(info-cmap);
iounmap(par-regs);
iounmap(info-screen_base);
-- 
Ondrej Zary

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 3/4] Add support for driver cross-timestamp to PTP_SYS_OFFSET ioctl

[Hall, Christopher S]

 -Original Message-
 From: Richard Cochran [mailto:richardcoch...@gmail.com]
 Sent: Sunday, August 23, 2015 4:26 AM
 To: Thomas Gleixner
 Cc: Hall, Christopher S; Kirsher, Jeffrey T; h...@zytor.com;
 mi...@redhat.com; john.stu...@linaro.org; x...@kernel.org; linux-
 ker...@vger.kernel.org; net...@vger.kernel.org; intel-wired-
 l...@lists.osuosl.org; pet...@infradead.org
 Subject: Re: [PATCH v3 3/4] Add support for driver cross-timestamp to
 PTP_SYS_OFFSET ioctl
 
 On Sun, Aug 23, 2015 at 10:15:00AM +0200, Thomas Gleixner wrote:
  So why can't you take N samples from the synced hardware? It does not
  make any sense to me to switch to the imprecise mode if nsamples  1.
 
 Ok, then I prefer to leave this imprecise method in place and ...
 
  You can also provide a new IOCTL PTP_SYS_OFFSET_PRECISE which returns
  -ENOSYS if hardware timestamping is not available and avoid the whole
  nsamples dance for the case where we can get precise timestamps.
 
 have this for the new way.
 
 By keeping the imprecise method, we will be able to run both methods
 on the new hardware.  That will help to quantify how imprecise the old
 method is.

This means: remove code changes from the PTP_SYS_OFFSET ioctl and call 
getsynctime64() from a new ioctl PTP_SYS_OFFSET_PRECISE.  Right?

And use the same type (struct ptp_sys_offset) for the new ioctl?  Or should a 
new simplified struct be used? Such as:

struct precise_ptp_sys_offset {
struct ptp_clock_time device;
struct ptp_clock_time system;
};

Does it make sense to keep the cross-timestamp capabilities flag as-is?

 
 Thanks,
 Richard

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] [resend] gxt4500: fix 16bpp 565 mode

[Ondrej Zary]

Fix wrong colors in 16bpp 565 mode.

Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
 drivers/video/fbdev/gxt4500.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 1bf9894..1f2fd5b 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -525,7 +525,7 @@ static int gxt4500_setcolreg(unsigned int reg, unsigned int 
red,
u32 val = reg;
switch (par-pixfmt) {
case DFA_PIX_16BIT_565:
-   val |= (reg  11) | (reg  6);
+   val |= (reg  11) | (reg  5);
break;
case DFA_PIX_16BIT_1555:
val |= (reg  10) | (reg  5);
-- 
Ondrej Zary

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/18] ARM: add const qualifier to the argument of smp_set_ops()

[Stephen Boyd]

On 08/24, Masahiro Yamada wrote:
 This function just copies '*ops' to 'smp_ops', so the given
 structure '*ops' is not modified at all.
 
 Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
 ---

Acked-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] usbnet: Fix a race between usbnet_stop() and the BH

[Bjørn Mork]

Eugene Shatokhin eugene.shatok...@rosalab.ru writes:

 The race may happen when a device (e.g. YOTA 4G LTE Modem) is
 unplugged while the system is downloading a large file from the Net.

 Hardware breakpoints and Kprobes with delays were used to confirm that
 the race does actually happen.

 The race is on skb_queue ('next' pointer) between usbnet_stop()
 and rx_complete(), which, in turn, calls usbnet_bh().

 Here is a part of the call stack with the code where the changes to the
 queue happen. The line numbers are for the kernel 4.1.0:

 *0 __skb_unlink (skbuff.h:1517)
 prev-next = next;
 *1 defer_bh (usbnet.c:430)
 spin_lock_irqsave(list-lock, flags);
 old_state = entry-state;
 entry-state = state;
 __skb_unlink(skb, list);
 spin_unlock(list-lock);
 spin_lock(dev-done.lock);
 __skb_queue_tail(dev-done, skb);
 if (dev-done.qlen == 1)
 tasklet_schedule(dev-bh);
 spin_unlock_irqrestore(dev-done.lock, flags);
 *2 rx_complete (usbnet.c:640)
 state = defer_bh(dev, skb, dev-rxq, state);

 At the same time, the following code repeatedly checks if the queue is
 empty and reads these values concurrently with the above changes:

 *0  usbnet_terminate_urbs (usbnet.c:765)
 /* maybe wait for deletions to finish. */
 while (!skb_queue_empty(dev-rxq)
  !skb_queue_empty(dev-txq)
  !skb_queue_empty(dev-done)) {
 schedule_timeout(msecs_to_jiffies(UNLINK_TIMEOUT_MS));
 set_current_state(TASK_UNINTERRUPTIBLE);
 netif_dbg(dev, ifdown, dev-net,
   waited for %d urb completions\n, temp);
 }
 *1  usbnet_stop (usbnet.c:806)
 if (!(info-flags  FLAG_AVOID_UNLINK_URBS))
 usbnet_terminate_urbs(dev);

 As a result, it is possible, for example, that the skb is removed from
 dev-rxq by __skb_unlink() before the check
 !skb_queue_empty(dev-rxq) in usbnet_terminate_urbs() is made. It is
 also possible in this case that the skb is added to dev-done queue
 after !skb_queue_empty(dev-done) is checked. So
 usbnet_terminate_urbs() may stop waiting and return while dev-done
 queue still has an item.

Exactly what problem will that result in?  The tasklet_kill() will wait
for the processing of the single element done queue, and everything will
be fine.  Or?


Bjørn

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Paul Turner]

On Mon, Aug 24, 2015 at 1:25 PM, Tejun Heo t...@kernel.org wrote:
 Hello, Austin.

 On Mon, Aug 24, 2015 at 04:00:49PM -0400, Austin S Hemmelgarn wrote:
 That alone doesn't require hierarchical resource distribution tho.
 Setting nice levels reasonably is likely to alleviate most of the
 problem.

 In the cases I've dealt with this myself, nice levels didn't cut it, and I
 had to resort to SCHED_RR with particular care to avoid priority inversions.

 I wonder why.  The difference between -20 and 20 is around 2500x in
 terms of weight.  That should have been enough for expressing whatever
 precedence the vcpus should have over other threads.

This strongly perturbs the load-balancer which performs busiest cpu
selection by weight.

Note that also we do not necessarily want total dominance by vCPU
threads, the hypervisor threads are almost always doing work on their
behalf and we want to provision them with _some_ time.  A
sub-hierarchy allows this to be performed in a way that is independent
of how many vCPUs or support threads that are present.


 I don't know.  Someone running one or two VM's on a laptop under
 QEMU doesn't really sound like the use case which absolutely requires
 hierarchical cpu cycle distribution.

 It depends on the use case.  I never have more than 2 VM's running on my
 laptop (always under QEMU, setting up Xen is kind of pointless ona quad core
 system with only 8G of RAM), and I take extensive advantage of the cpu
 cgroup to partition resources among various services on the host.

 Hmmm... I'm trying to understand the usecases where having hierarchy
 inside a process are actually required so that we don't end up doing
 something complex unnecessarily.  So far, it looks like an easy
 alternative for qemu would be teaching it to manage priorities of its
 threads given that the threads are mostly static - vcpus going up and
 down are explicit operations which can trigger priority adjustments if
 necessary, which is unlikely to begin with.

What you're proposing is both unnecessarily complex and imprecise.
Arbitrating competition between groups of threads is exactly why we
support sub-hierarchies within cpu.


 Thanks.

 --
 tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch -mm] mm, oom: add global access to memory reserves on livelock

[David Rientjes]

On Fri, 21 Aug 2015, Tetsuo Handa wrote:

 Why can't we think about choosing more OOM victims instead of granting access
 to memory reserves?
 

We have no indication of which thread is holding a mutex that would need 
to be killed, so we'd be randomly killing processes waiting for forward 
progress.  A worst-case scenario would be the thread is OOM_DISABLE and we 
kill every process on the system needlessly.  This problem obviously 
occurs often enough that killing all userspace isnt going to be a viable 
solution.

 Also, SysRq might not be usable under OOM because workqueues can get stuck.
 The panic_on_oom_timeout was first proposed using a workqueue but was
 updated to use a timer because there is no guarantee that workqueues work
 as expected under OOM.
 

I don't know anything about a panic_on_oom_timeout, but panicking would 
only be a reasonable action if memory reserves were fully depleted.  That 
could easily be dealt with in the page allocator so there's no timeout 
involved.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Paul Turner]

On Mon, Aug 24, 2015 at 2:02 PM, Tejun Heo t...@kernel.org wrote:
 Hello,

 On Mon, Aug 24, 2015 at 01:54:08PM -0700, Paul Turner wrote:
  That alone doesn't require hierarchical resource distribution tho.
  Setting nice levels reasonably is likely to alleviate most of the
  problem.

 Nice is not sufficient here.  There could be arbitrarily many threads
 within the hypervisor that are not actually hosting guest CPU threads.
 The only way to have this competition occur at a reasonably fixed
 ratio is a sub-hierarchy.

 I get that having hierarchy of threads would be nicer but am having a
 bit of difficulty seeing why adjusting priorities of threads wouldn't
 be sufficient.  It's not like threads of the same process competing
 with each other is a new problem.  People have been dealing with it
 for ages.  Hierarchical management can be a nice plus but we want the
 problem and proposed solution to be justifiable.

Consider what happens with load asymmetry:

Suppose that we have 10 vcpu threads and 100 support threads.
Suppose that we want the support threads to receive up to 10% of the
time available to the VM as a whole on that machine.

If I have one particular support thread that is busy, I want it to
receive that entire 10% (maybe a guest is pounding on scsi for
example, or in the thread-pool case, I've passed a single expensive
computation).  Conversely, suppose the guest is doing lots of
different things and several support threads are active, I want the
time to be shared between them.

There is no way to implement this with nice.  Either a single thread
can consume 10%, and the group can dominate, or the group cannot
dominate and the single thread can be starved.


 Thanks.

 --
 tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] [resend #2] tridentfb: Add DDC support

[Ondrej Zary]

Add DDC support for Trident cards.

Tested on TGUI9440, TGUI9680, 3DImage 9750, Blade3D 9880 and Blade XP.

Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
 drivers/video/fbdev/Kconfig |9 ++
 drivers/video/fbdev/tridentfb.c |  192 ++-
 2 files changed, 196 insertions(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d98de5..e2531b8 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1680,6 +1680,15 @@ config FB_TRIDENT
  To compile this driver as a module, choose M here: the
  module will be called tridentfb.
 
+config FB_TRIDENT_DDC
+   bool DDC for Trident support
+   depends on FB_TRIDENT
+   select FB_DDC
+   select FB_MODE_HELPERS
+   default y
+   help
+ Say Y here if you want DDC support for your Trident graphics card.
+
 config FB_ARK
tristate ARK 2000PV support
depends on FB  PCI
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 01b43e9..59471a0 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -25,6 +25,9 @@
 #include video/vga.h
 #include video/trident.h
 
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+
 struct tridentfb_par {
void __iomem *io_virt;  /* iospace virtual memory address */
u32 pseudo_pal[16];
@@ -40,6 +43,11 @@ struct tridentfb_par {
(struct tridentfb_par *par, const char*,
 u32, u32, u32, u32, u32, u32);
unsigned char eng_oper; /* engine operation... */
+#ifdef CONFIG_FB_TRIDENT_DDC
+   bool ddc_registered;
+   struct i2c_adapter ddc_adapter;
+   struct i2c_algo_bit_data ddc_algo;
+#endif
 };
 
 static struct fb_fix_screeninfo tridentfb_fix = {
@@ -53,7 +61,7 @@ static struct fb_fix_screeninfo tridentfb_fix = {
 /* defaults which are normally overriden by user values */
 
 /* video mode */
-static char *mode_option = 640x480-8@60;
+static char *mode_option;
 static int bpp = 8;
 
 static int noaccel;
@@ -174,6 +182,124 @@ static inline u32 readmmr(struct tridentfb_par *par, u16 
r)
return fb_readl(par-io_virt + r);
 }
 
+#ifdef CONFIG_FB_TRIDENT_DDC
+
+#define DDC_SDA_TGUI   BIT(0)
+#define DDC_SCL_TGUI   BIT(1)
+#define DDC_SCL_DRIVE_TGUI BIT(2)
+#define DDC_SDA_DRIVE_TGUI BIT(3)
+#define DDC_MASK_TGUI  (DDC_SCL_DRIVE_TGUI | DDC_SDA_DRIVE_TGUI)
+
+static void tridentfb_ddc_setscl_tgui(void *data, int val)
+{
+   struct tridentfb_par *par = data;
+   u8 reg = vga_mm_rcrt(par-io_virt, I2C)  DDC_MASK_TGUI;
+
+   if (val)
+   reg = ~DDC_SCL_DRIVE_TGUI; /* disable drive - don't drive hi */
+   else
+   reg |= DDC_SCL_DRIVE_TGUI; /* drive low */
+
+   vga_mm_wcrt(par-io_virt, I2C, reg);
+}
+
+static void tridentfb_ddc_setsda_tgui(void *data, int val)
+{
+   struct tridentfb_par *par = data;
+   u8 reg = vga_mm_rcrt(par-io_virt, I2C)  DDC_MASK_TGUI;
+
+   if (val)
+   reg = ~DDC_SDA_DRIVE_TGUI; /* disable drive - don't drive hi */
+   else
+   reg |= DDC_SDA_DRIVE_TGUI; /* drive low */
+
+   vga_mm_wcrt(par-io_virt, I2C, reg);
+}
+
+static int tridentfb_ddc_getsda_tgui(void *data)
+{
+   struct tridentfb_par *par = data;
+
+   return !!(vga_mm_rcrt(par-io_virt, I2C)  DDC_SDA_TGUI);
+}
+
+#define DDC_SDA_IN BIT(0)
+#define DDC_SCL_OUTBIT(1)
+#define DDC_SDA_OUTBIT(3)
+#define DDC_SCL_IN BIT(6)
+#define DDC_MASK   (DDC_SCL_OUT | DDC_SDA_OUT)
+
+static void tridentfb_ddc_setscl(void *data, int val)
+{
+   struct tridentfb_par *par = data;
+   unsigned char reg;
+
+   reg = vga_mm_rcrt(par-io_virt, I2C)  DDC_MASK;
+   if (val)
+   reg |= DDC_SCL_OUT;
+   else
+   reg = ~DDC_SCL_OUT;
+   vga_mm_wcrt(par-io_virt, I2C, reg);
+}
+
+static void tridentfb_ddc_setsda(void *data, int val)
+{
+   struct tridentfb_par *par = data;
+   unsigned char reg;
+
+   reg = vga_mm_rcrt(par-io_virt, I2C)  DDC_MASK;
+   if (!val)
+   reg |= DDC_SDA_OUT;
+   else
+   reg = ~DDC_SDA_OUT;
+   vga_mm_wcrt(par-io_virt, I2C, reg);
+}
+
+static int tridentfb_ddc_getscl(void *data)
+{
+   struct tridentfb_par *par = data;
+
+   return !!(vga_mm_rcrt(par-io_virt, I2C)  DDC_SCL_IN);
+}
+
+static int tridentfb_ddc_getsda(void *data)
+{
+   struct tridentfb_par *par = data;
+
+   return !!(vga_mm_rcrt(par-io_virt, I2C)  DDC_SDA_IN);
+}
+
+static int tridentfb_setup_ddc_bus(struct fb_info *info)
+{
+   struct tridentfb_par *par = info-par;
+
+   strlcpy(par-ddc_adapter.name, info-fix.id,
+   sizeof(par-ddc_adapter.name));
+   par-ddc_adapter.owner  = THIS_MODULE;
+   par-ddc_adapter.class  = I2C_CLASS_DDC;
+   par-ddc_adapter.algo_data  = par-ddc_algo;
+   

RE: [PATCH v9 1/1] irqchip: imx-gpcv2: IMX GPCv2 driver for wakeup sources

[Shenwei Wang]

Thank you, Thomas!

Shenwei

 -Original Message-
 From: Thomas Gleixner [mailto:t...@linutronix.de]
 Sent: 2015年8月24日 14:30
 To: Wang Shenwei-B38339
 Cc: shawn@linaro.org; ja...@lakedaemon.net;
 linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Huang
 Yongcai-B20788
 Subject: RE: [PATCH v9 1/1] irqchip: imx-gpcv2: IMX GPCv2 driver for wakeup
 sources
 
 On Mon, 24 Aug 2015, Shenwei Wang wrote:
   Ok, last question. How is Anson related to this? He did not convey
   your patch and in the first posted versions his SOB was never there.
 
  This patch was based on his internal version of GPCv2 driver. I reused
  some of his implementation and ported it to latest linux kernel.
  Adding his name here to give the credits to him.
 
 So the proper way to express this is:
 
 Based-on-a-patch-by: Anson
 Signed-off-by: You
 
 The way you did it suggests that you wrote it and Anson conveyed it, which is 
 not
 the case.
 
 I'll change it that way then.
 
 Thanks,
 
   tglx

[tip:irq/core] irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources

[tip-bot for Shenwei Wang]

Commit-ID:  e324c4dc4a5991d5b1171f434884a4026345e4b4
Gitweb: http://git.kernel.org/tip/e324c4dc4a5991d5b1171f434884a4026345e4b4
Author: Shenwei Wang shenwei.w...@freescale.com
AuthorDate: Mon, 24 Aug 2015 14:04:15 -0500
Committer:  Thomas Gleixner t...@linutronix.de
CommitDate: Mon, 24 Aug 2015 21:49:34 +0200

irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources

IMX7D contains a new version of GPC IP block (GPCv2). It has two major
functions: power management and wakeup source management.

When the system is in WFI (wait for interrupt) mode, the GPC block
will be the first block on the platform to be activated and signaled.

In normal wait mode during cpu idle, the system can be woken up by any
enabled interrupts. In standby or suspend mode, the system can only be
wokem up by the pre-defined wakeup sources.

Based-on-patch-by: Anson Huang b20...@freescale.com
Signed-off-by: Shenwei Wang shenwei.w...@freescale.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: shawn@linaro.org
Cc: ja...@lakedaemon.net
Link: 
http://lkml.kernel.org/r/1440443055-7291-1-git-send-email-shenwei.w...@freescale.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
 drivers/irqchip/Kconfig |   6 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-imx-gpcv2.c | 278 
 3 files changed, 285 insertions(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 5b85371..27b52c8 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -181,3 +181,9 @@ config RENESAS_H8300H_INTC
 config RENESAS_H8S_INTC
 bool
select IRQ_DOMAIN
+
+config IMX_GPCV2
+   bool
+   select IRQ_DOMAIN
+   help
+ Enables the wakeup IRQs for IMX platforms with GPCv2 block
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e5e0069..bb3048f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -54,3 +54,4 @@ obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
 obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
 obj-$(CONFIG_ARCH_SA1100)  += irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)  += irq-ingenic.o
+obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
new file mode 100644
index 000..e48d330
--- /dev/null
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/slab.h
+#include linux/irqchip.h
+#include linux/syscore_ops.h
+
+#define IMR_NUM4
+#define GPC_MAX_IRQS(IMR_NUM * 32)
+
+#define GPC_IMR1_CORE0 0x30
+#define GPC_IMR1_CORE1 0x40
+
+struct gpcv2_irqchip_data {
+   struct raw_spinlock rlock;
+   void __iomem*gpc_base;
+   u32 wakeup_sources[IMR_NUM];
+   u32 saved_irq_mask[IMR_NUM];
+   u32 cpu2wakeup;
+};
+
+static struct gpcv2_irqchip_data *imx_gpcv2_instance;
+
+/*
+ * Interface for the low level wakeup code.
+ */
+u32 imx_gpcv2_get_wakeup_source(u32 **sources)
+{
+   if (!imx_gpcv2_instance)
+   return 0;
+
+   if (sources)
+   *sources = imx_gpcv2_instance-wakeup_sources;
+
+   return IMR_NUM;
+}
+
+static int gpcv2_wakeup_source_save(void)
+{
+   struct gpcv2_irqchip_data *cd;
+   void __iomem *reg;
+   int i;
+
+   cd = imx_gpcv2_instance;
+   if (!cd)
+   return 0;
+
+   for (i = 0; i  IMR_NUM; i++) {
+   reg = cd-gpc_base + cd-cpu2wakeup + i * 4;
+   cd-saved_irq_mask[i] = readl_relaxed(reg);
+   writel_relaxed(cd-wakeup_sources[i], reg);
+   }
+
+   return 0;
+}
+
+static void gpcv2_wakeup_source_restore(void)
+{
+   struct gpcv2_irqchip_data *cd;
+   void __iomem *reg;
+   int i;
+
+   cd = imx_gpcv2_instance;
+   if (!cd)
+   return;
+
+   for (i = 0; i  IMR_NUM; i++) {
+   reg = cd-gpc_base + cd-cpu2wakeup + i * 4;
+   writel_relaxed(cd-saved_irq_mask[i], reg);
+   }
+}
+
+static struct syscore_ops imx_gpcv2_syscore_ops = {
+   .suspend= gpcv2_wakeup_source_save,
+   .resume = gpcv2_wakeup_source_restore,
+};
+
+static int imx_gpcv2_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+   struct gpcv2_irqchip_data *cd = d-chip_data;
+   unsigned int idx = d-hwirq / 32;
+   unsigned long flags;
+   void __iomem *reg;
+   u32 mask, val;
+
+   raw_spin_lock_irqsave(cd-rlock, flags);
+   reg = cd-gpc_base + cd-cpu2wakeup + idx * 4;
+   mask = 1  

Re: Build failure due to Intel PT

[Arnaldo Carvalho de Melo]

Em Mon, Aug 24, 2015 at 11:51:31AM -0700, Sukadev Bhattiprolu escreveu:
 
 I am trying to build perf tool on Powerpc and get this:
 
 util/intel-pt-decoder/intel-pt-insn-decoder.c: In function 
 ‘intel_pt_insn_decoder’:
 util/intel-pt-decoder/intel-pt-insn-decoder.c:138:3: error: switch missing 
 default case [-Werror=switch-default]
switch (insn-immediate.nbytes) {
^
 cc1: all warnings being treated as errors

 Besides adding a 'default' case, can this file be skipped when building on
 non-x86 architectures?

Not sure, what about processing a perf.data file generated on a x86
system using a PowerPC workstation?

Adrian, I am assuming this is only used when postprocessing, is that
right?

- Arnaldo
 
 I am on the perf/core branch, with HEAD pointing to:
 
   commit c0b4dffbc529244d3e4e3bd392f2bffa2d8531a7
   Author: Arnaldo Carvalho de Melo a...@redhat.com
   Date:   Mon Aug 24 13:33:14 2015 -0300
 
   perf annotate: Reset the dso find_symbol cache when removing symbols
 
 Sukadev
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] [resend] gxt4500: fix color order

[Ondrej Zary]

The color order in truecolor modes is wrong. This does not affect console but
is visible e.g. in X11 which has wrong colors.

Swap blue and red colors to fix the problem.
Fixes https://forums.gentoo.org/viewtopic-t-692740-start-0.html

Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
 drivers/video/fbdev/gxt4500.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 1f2fd5b..442b07c 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -347,11 +347,12 @@ static void gxt4500_unpack_pixfmt(struct 
fb_var_screeninfo *var,
break;
}
if (pixfmt != DFA_PIX_8BIT) {
-   var-green.offset = var-red.length;
-   var-blue.offset = var-green.offset + var-green.length;
+   var-blue.offset = 0;
+   var-green.offset = var-blue.length;
+   var-red.offset = var-green.offset + var-green.length;
if (var-transp.length)
var-transp.offset =
-   var-blue.offset + var-blue.length;
+   var-red.offset + var-red.length;
}
 }
 
-- 
Ondrej Zary

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lib: scatterlist: add sg splitting function

[Andrew Morton]

On Mon, 24 Aug 2015 14:15:08 -0600 Jens Axboe ax...@kernel.dk wrote:

 On 08/08/2015 02:44 AM, Robert Jarzmik wrote:
  Sometimes a scatter-gather has to be split into several chunks, or sub
  scatter lists. This happens for example if a scatter list will be
  handled by multiple DMA channels, each one filling a part of it.
 
  A concrete example comes with the media V4L2 API, where the scatter list
  is allocated from userspace to hold an image, regardless of the
  knowledge of how many DMAs will fill it :
- in a simple RGB565 case, one DMA will pump data from the camera ISP
  to memory
- in the trickier YUV422 case, 3 DMAs will pump data from the camera
  ISP pipes, one for pipe Y, one for pipe U and one for pipe V
 
  For these cases, it is necessary to split the original scatter list into
  multiple scatter lists, which is the purpose of this patch.
 
  The guarantees that are required for this patch are :
- the intersection of spans of any couple of resulting scatter lists is
  empty.
- the union of spans of all resulting scatter lists is a subrange of
  the span of the original scatter list.
- streaming DMA API operations (mapping, unmapping) should not happen
  both on both the resulting and the original scatter list. It's either
  the first or the later ones.
- the caller is reponsible to call kfree() on the resulting
  scatterlists.
 
  Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
 
 I think this looks fine. But do we really need the Kconfig option? It's 
 not a lot of code, and it seems silly to put the onus on the driver for 
 having to enable something that is a subset of the SG api.

Blame me for that.  It's so that all kernels don't need to carry a lump
of code which only a small number of media drivers actually use.

The tradeoff is a bit of once-off build-time effort versus a permanent
runtime gain for many systems.  That's a good tradeoff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 1/1] misc: sram: add dev_pm_ops to support module power gate

[Shenwei Wang]

Hi GregKH,

Can you please take a look at this patch? 

Thanks,
Shenwei

 -Original Message-
 From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org] 
 On
 Behalf Of Shenwei Wang
 Sent: 2015年7月30日 11:11
 To: gre...@linuxfoundation.org; a...@arndb.de
 Cc: Huang Yongcai-B20788; linux-arm-ker...@lists.infradead.org
 Subject: [PATCH v3 1/1] misc: sram: add dev_pm_ops to support module power
 gate
 
 When system goes into low power states like SUSPEND_MEM and HIBERNATION,
 the hardware IP block may be powered off to reduce the power consumption.
 This power down will lost all the data inside the ram. This patch added the
 dev_pm_ops and implemented two callbacks: suspend_noirq and resume_noirq,
 which will save the data in the on-chip-ram right before power down and 
 restore
 it after system resumes.
 
 A new property string named can-power-gate is added to the devicetree
 bindings too.
 
 Signed-off-by: Shenwei Wang shenwei.w...@freescale.com
 Signed-off-by: Anson Huang b20...@freescale.com
 ---
 Change log:
 
 PATCH v3
   Removed the unnecessary clk_enable/clk_disable.
 
 PATCH v2
   Use vmalloc to allocate the SRAM backup memory.
   Code clean up.
 
  Documentation/devicetree/bindings/misc/sram.txt |  2 ++
  drivers/misc/sram.c | 42
 +
  2 files changed, 44 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/misc/sram.txt
 b/Documentation/devicetree/bindings/misc/sram.txt
 index 36cbe5a..1170086 100644
 --- a/Documentation/devicetree/bindings/misc/sram.txt
 +++ b/Documentation/devicetree/bindings/misc/sram.txt
 @@ -33,6 +33,8 @@ Optional properties in the area nodes:
 
  - compatible : standard definition, should contain a vendor specific string
 in the form vendor,[device-]usage
 +- can-power-gate: a property to tell the driver that the sram can support
 + power gate
 
  Example:
 
 diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c index 15c33cc..db9f1fa
 100644
 --- a/drivers/misc/sram.c
 +++ b/drivers/misc/sram.c
 @@ -30,7 +30,9 @@
 
  struct sram_dev {
   struct device *dev;
 + void *power_off_save;
   void __iomem *virt_base;
 + u32 size;
 
   struct gen_pool *pool;
   struct clk *clk;
 @@ -156,6 +158,33 @@ static int sram_reserve_regions(struct sram_dev
 *sram, struct resource *res)
   return ret;
  }
 
 +static int sram_suspend_noirq(struct device *dev) {
 + struct platform_device *pdev = to_platform_device(dev);
 + struct sram_dev *sram = platform_get_drvdata(pdev);
 +
 + if (!sram-power_off_save)
 + return 0;
 +
 + /* Save necessary regs */
 + memcpy(sram-power_off_save, sram-virt_base, sram-size);
 +
 + return 0;
 +}
 +
 +static int sram_resume_noirq(struct device *dev) {
 + struct platform_device *pdev = to_platform_device(dev);
 + struct sram_dev *sram = platform_get_drvdata(pdev);
 +
 + if (!sram-power_off_save)
 + return 0;
 +
 + memcpy(sram-virt_base, sram-power_off_save, sram-size);
 +
 + return 0;
 +}
 +
  static int sram_probe(struct platform_device *pdev)  {
   struct sram_dev *sram;
 @@ -176,6 +205,7 @@ static int sram_probe(struct platform_device *pdev)
   }
 
   size = resource_size(res);
 + sram-size = size;
 
   if (!devm_request_mem_region(sram-dev, res-start, size, pdev-name)) {
   dev_err(sram-dev, could not request region for resource\n); 
 @@
 -203,6 +233,9 @@ static int sram_probe(struct platform_device *pdev)
 
   platform_set_drvdata(pdev, sram);
 
 + if (of_property_read_bool(pdev-dev.of_node, can-power-gate))
 + sram-power_off_save = vmalloc(size);
 +
   dev_dbg(sram-dev, SRAM pool: %zu KiB @ 0x%p\n,
   gen_pool_size(sram-pool) / 1024, sram-virt_base);
 
 @@ -219,6 +252,9 @@ static int sram_remove(struct platform_device *pdev)
   if (sram-clk)
   clk_disable_unprepare(sram-clk);
 
 + if (sram-power_off_save)
 + vfree(sram-power_off_save);
 +
   return 0;
  }
 
 @@ -229,10 +265,16 @@ static const struct of_device_id sram_dt_ids[] = {  };
 #endif
 
 +static const struct dev_pm_ops sram_pm_ops = {
 + .suspend_noirq = sram_suspend_noirq,
 + .resume_noirq = sram_resume_noirq,
 +};
 +
  static struct platform_driver sram_driver = {
   .driver = {
   .name = sram,
   .of_match_table = of_match_ptr(sram_dt_ids),
 + .pm = sram_pm_ops,
   },
   .probe = sram_probe,
   .remove = sram_remove,
 --
 2.5.0.rc2
 
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] Input: edt-ft5x06 - Switch to newer gpio framework

[Dmitry Torokhov]

On Mon, Aug 24, 2015 at 03:23:43PM -0500, Franklin S Cooper Jr. wrote:
 
 
 On 08/24/2015 03:16 PM, Franklin S Cooper Jr. wrote:
 
  On 08/24/2015 03:01 PM, Dmitry Torokhov wrote:
  On Mon, Aug 24, 2015 at 02:48:36PM -0500, Franklin S Cooper Jr. wrote:
  On 08/24/2015 02:41 PM, Dmitry Torokhov wrote:
  On Fri, Aug 21, 2015 at 02:08:32PM -0500, Franklin S Cooper Jr wrote:
  The current/old gpio framework used doesn't properly listen to
  ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
  account these flags when setting gpio values.
 
  Also use gpiod_set_value_cansleep since wake and reset pins can be
  provided by bus based io expanders.
 
  Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
  ---
   .../bindings/input/touchscreen/edt-ft5x06.txt  |   4 +-
   drivers/input/touchscreen/edt-ft5x06.c | 115 
  +++--
   include/linux/input/edt-ft5x06.h   |   4 +-
   3 files changed, 43 insertions(+), 80 deletions(-)
 
  diff --git 
  a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
  b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
  index 76db967..9330d4d 100644
  --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
  +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
  @@ -50,6 +50,6 @@ Example:
  pinctrl-0 = edt_ft5x06_pins;
  interrupt-parent = gpio2;
  interrupts = 5 0;
  -   reset-gpios = gpio2 6 1;
  -   wake-gpios = gpio4 9 0;
  +   reset-gpios = gpio2 6 GPIO_ACTIVE_LOW;
  +   wake-gpios = gpio4 9 GPIO_ACTIVE_HIGH;
  };
  diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
  b/drivers/input/touchscreen/edt-ft5x06.c
  index 394b1de..6b128b3 100644
  --- a/drivers/input/touchscreen/edt-ft5x06.c
  +++ b/drivers/input/touchscreen/edt-ft5x06.c
  @@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
  u16 num_x;
  u16 num_y;
   
  -   int reset_pin;
  -   int irq_pin;
  -   int wake_pin;
  +   struct gpio_desc *reset_pin;
  +   struct gpio_desc *wake_pin;
  +   struct gpio_desc *irq_pin;
   
   #if defined(CONFIG_DEBUG_FS)
  struct dentry *debug_dir;
  @@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct 
  edt_ft5x06_ts_data *tsdata)
   static int edt_ft5x06_ts_reset(struct i2c_client *client,
  struct edt_ft5x06_ts_data *tsdata)
   {
  -   int error;
  -
  -   if (gpio_is_valid(tsdata-wake_pin)) {
  -   error = devm_gpio_request_one(client-dev,
  -   tsdata-wake_pin, 
  GPIOF_OUT_INIT_LOW,
  -   edt-ft5x06 wake);
  -   if (error) {
  -   dev_err(client-dev,
  -   Failed to request GPIO %d as wake pin, 
  error %d\n,
  -   tsdata-wake_pin, error);
  -   return error;
  -   }
  -
  +   if (tsdata-wake_pin) {
  msleep(5);
  -   gpio_set_value(tsdata-wake_pin, 1);
  +   gpiod_set_value_cansleep(tsdata-wake_pin, 1);
  }
  -   if (gpio_is_valid(tsdata-reset_pin)) {
  -   /* this pulls reset down, enabling the low active reset 
  */
  -   error = devm_gpio_request_one(client-dev,
  -   tsdata-reset_pin, 
  GPIOF_OUT_INIT_LOW,
  -   edt-ft5x06 reset);
  -   if (error) {
  -   dev_err(client-dev,
  -   Failed to request GPIO %d as reset 
  pin, error %d\n,
  -   tsdata-reset_pin, error);
  -   return error;
  -   }
   
  +   if (tsdata-reset_pin) {
  msleep(5);
  -   gpio_set_value(tsdata-reset_pin, 1);
  +   gpiod_set_value_cansleep(tsdata-reset_pin, 1);
  So this leaves the reset pin active. How exactly was this tested?
  Normally if the output gpio connected to the reset pin is ACTIVE_HIGH 
  then this will take the tsc out of reset since
  the reset pin is active low. However, I have a board that has an inverter 
  between the gpio and reset pin. So if I leave
  the gpio as ACTIVE_HIGH then the inverter would cause the reset pin to go 
  low which will keep it in reset. So instead
  I set the gpio to ACTIVE_LOW which gives me the expected result.
  I do not really care about particular board. Assuming that polarity of
  the GPIO in DTS is specified correctly the effect of:
 
 gpiod_set_value_cansleep(tsdata-reset_pin, 1);
 
  is reset pin being _active_, i.e. the chip is staying in reset state.
  Setting the reset pin to 1/high will take the tsc out of reset. Setting the 
  pin to 0/low will put the tsc into reset mode.

It seems you are not quite getting gpiod API. 

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Tejun Heo]

Hello,

On Mon, Aug 24, 2015 at 02:10:17PM -0700, Paul Turner wrote:
 Suppose that we have 10 vcpu threads and 100 support threads.
 Suppose that we want the support threads to receive up to 10% of the
 time available to the VM as a whole on that machine.
 
 If I have one particular support thread that is busy, I want it to
 receive that entire 10% (maybe a guest is pounding on scsi for
 example, or in the thread-pool case, I've passed a single expensive
 computation).  Conversely, suppose the guest is doing lots of
 different things and several support threads are active, I want the
 time to be shared between them.
 
 There is no way to implement this with nice.  Either a single thread
 can consume 10%, and the group can dominate, or the group cannot
 dominate and the single thread can be starved.

Would it be possible for you to give realistic and concrete examples?
I'm not trying to play down the use cases but concrete examples are
usually helpful at putting things in perspective.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: Add missing header for 'bool' definition to clk-conf.h

[Stephen Boyd]

On 08/18, Chen-Yu Tsai wrote:
 of_clk_set_defaults uses the type 'bool', but clk-conf.h does not
 include its definition.
 
 This results in a compile error when only clk-conf.h is used.
 
 Signed-off-by: Chen-Yu Tsai w...@csie.org
 Cc: sta...@vger.kernel.org

Why is stable Cc-ed? Is there some sort of compilation failure on
stable kernels?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/10] x86/vdso32: Define PGTABLE_LEVELS to 32bit VDSO

[Toshi Kani]

On Thu, 2015-08-20 at 17:04 -0600, Toshi Kani wrote:
 On 8/20/2015 1:46 PM, Thomas Gleixner wrote:
  On Wed, 5 Aug 2015, Toshi Kani wrote:
  
   In case of CONFIG_X86_64, vdso32/vclock_gettime.c fakes a 32bit
   kernel configuration by re-defining it to CONFIG_X86_32.  However,
   it does not re-define CONFIG_PGTABLE_LEVELS leaving it as 4 levels.
   Fix it by re-defining CONFIG_PGTABLE_LEVELS to 2 as X86_PAE is not
   set.
  You fail to explain WHY this is required. I have not yet spotted any
  code in vclock_gettime.c which is affected by this.
 
 Sorry about that.  Without this patch 01, applying patch 02  03 causes 
 the following compile errors in vclock_gettime.c.  This is because it 
 includes pgtable_type.h (see blow), which now requires PUD_SHIFT and 
 PMD_SHIFT defined properly.  In case of X86_32, pgtable_type.h includes 
 pgtable_nopud.h and pgtable-nopmd.h, which define these SHIFTs when 
 CONFIG_PGTABLE_LEVEL is set to 2 (or 3 if PAE is also defined).
  :

Attached is patch 01/10 with updated descriptions.  The rest of the patchset
still applies cleanly.

Please let me know if you have any further comments.
Thanks,
-Toshi


Subject: [PATCH v3 UPDATE 1/10] x86/vdso32: Define PGTABLE_LEVELS to 32bit
VDSO

In case of CONFIG_X86_64, vdso32/vclock_gettime.c fakes a 32-bit
non-PAE kernel configuration by re-defining it to CONFIG_X86_32.
However, it does not re-define CONFIG_PGTABLE_LEVELS leaving it
as 4 levels.

This mismatch leads asm/pgtable_type.h to NOT include asm-generic/
pgtable-nopud.h and asm-generic/pgtable-nopmd.h, which will cause
compile errors when a later patch enhances asm/pgtable_type.h to
use PUD_SHIFT and PMD_SHIFT.  These -nopud  -nopmd headers define
these SHIFTs for the 32-bit non-PAE kernel.

Fix it by re-defining CONFIG_PGTABLE_LEVELS to 2 levels.

Signed-off-by: Toshi Kani toshi.k...@hp.com
Cc: Juergen Gross jgr...@suse.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@redhat.com
Cc: Borislav Petkov b...@alien8.de
---
 arch/x86/entry/vdso/vdso32/vclock_gettime.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
index 175cc72..87a86e0 100644
--- a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
@@ -14,11 +14,13 @@
  */
 #undef CONFIG_64BIT
 #undef CONFIG_X86_64
+#undef CONFIG_PGTABLE_LEVELS
 #undef CONFIG_ILLEGAL_POINTER_VALUE
 #undef CONFIG_SPARSEMEM_VMEMMAP
 #undef CONFIG_NR_CPUS
 
 #define CONFIG_X86_32 1
+#define CONFIG_PGTABLE_LEVELS 2
 #define CONFIG_PAGE_OFFSET 0
 #define CONFIG_ILLEGAL_POINTER_VALUE 0
 #define CONFIG_NR_CPUS 1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/