[PATCH 09/12] mm, page_alloc: Delete the zonelist_cache

2015-08-24 Thread Mel Gorman
The zonelist cache (zlc) was introduced to skip over zones that were
recently known to be full. This avoided expensive operations such as the
cpuset checks, watermark calculations and zone_reclaim. The situation
today is different and the complexity of zlc is harder to justify.

1) The cpuset checks are no-ops unless a cpuset is active and in general are
   a lot cheaper.

2) zone_reclaim is now disabled by default and I suspect that was a large
   source of the cost that zlc wanted to avoid. When it is enabled, it's
   known to be a major source of stalling when nodes fill up and it's
   unwise to hit every other user with the overhead.

3) Watermark checks are expensive to calculate for high-order
   allocation requests. Later patches in this series will reduce the cost
   of the watermark checking.

4) The most important issue is that in the current implementation it
   is possible for a failed THP allocation to mark a zone full for order-0
   allocations and cause a fallback to remote nodes.

The last issue could be addressed with additional complexity but as the
benefit of zlc is questionable, it is better to remove it.  If stalls
due to zone_reclaim are ever reported then an alternative would be to
introduce deferring logic based on a timeout inside zone_reclaim itself
and leave the page allocator fast paths alone.

The impact on page-allocator microbenchmarks is negligible as they don't
hit the paths where the zlc comes into play. Most page-reclaim related
workloads showed no noticable difference as a result of the removal.

The impact was noticeable in a workload called stutter. One part uses a
lot of anonymous memory, a second measures mmap latency and a third copies
a large file. In an ideal world the latency application would not notice
the mmap latency.  On a 2-node machine the results of this patch are

2-node machine stutter
 4.2.0-rc7 4.2.0-rc7
   vanillanozlc-v3r8
Min mmap 21.2266 (  0.00%) 21.0431 (  0.86%)
1st-qrtle   mmap 24.3096 (  0.00%) 28.6013 (-17.65%)
2nd-qrtle   mmap 28.5789 (  0.00%) 29.2909 ( -2.49%)
3rd-qrtle   mmap 29.1970 (  0.00%) 29.9426 ( -2.55%)
Max-90% mmap 33.6982 (  0.00%) 34.0195 ( -0.95%)
Max-93% mmap 34.1751 (  0.00%) 34.3753 ( -0.59%)
Max-95% mmap 38.7323 (  0.00%) 35.0257 (  9.57%)
Max-99% mmap 93.7964 (  0.00%) 89.8644 (  4.19%)
Max mmap 494274.6891 (  0.00%)  47520.4050 ( 90.39%)
Meanmmap 48.2708 (  0.00%) 46.5963 (  3.47%)
Best99%Mean mmap 29.0087 (  0.00%) 30.2834 ( -4.39%)
Best95%Mean mmap 27.3926 (  0.00%) 29.2582 ( -6.81%)
Best90%Mean mmap 27.0060 (  0.00%) 28.9746 ( -7.29%)
Best50%Mean mmap 24.9743 (  0.00%) 27.8092 (-11.35%)
Best10%Mean mmap 22.9546 (  0.00%) 24.7627 ( -7.88%)
Best5%Mean  mmap 21.9682 (  0.00%) 23.3681 ( -6.37%)
Best1%Mean  mmap 21.3082 (  0.00%) 21.2479 (  0.28%)

Note that the maximum stall latency went from 494 seconds to 47 seconds
which is still awful but an improvement. The milage here varies considerably
as a 4-node machine that tested an earlier version of this patch went from
a worst case stall time of 6 seconds to 67ms. The nature of the benchmark
is inherently unpredictable as it is hammering the system and the milage
will vary between machines.

There is a secondary impact with potentially more direct reclaim because
zones are now being considered instead of being skipped by zlc. In this
particular test run it did not occur so will not be described. However,
in at least one test the following was observed

1. Direct reclaim rates were higher. This was likely due to direct reclaim
  being entered instead of the zlc disabling a zone and busy looping.
  Busy looping may have the effect of allowing kswapd to make more
  progress and in some cases may be better overall. If this is found then
  the correct action is to put direct reclaimers to sleep on a waitqueue
  and allow kswapd make forward progress. Busy looping on the zlc is even
  worse than when the allocator used to blindly call congestion_wait().

2. There was higher swap activity as direct reclaim was active.

3. Direct reclaim efficiency was lower. This is related to 1 as more
  scanning activity also encountered more pages that could not be
  immediately reclaimed

In that case, the direct page scan and reclaim rates are noticeable but
it is not considered a problem for a few reasons

1. The test is primarily concerned with latency. The mmap attempts are also
   faulted which means there are THP allocation requests. The ZLC could
   cause zones to be disabled causing the process to busy loop instead
   of reclaiming.  This looks like elevated direct reclaim activity but
   it's the correct action to take based on what processes requested.

2. The test hammers reclaim and compaction heavily. The number of successful
   THP 

[PATCH 01/12] mm, page_alloc: Remove unnecessary parameter from zone_watermark_ok_safe

2015-08-24 Thread Mel Gorman
No user of zone_watermark_ok_safe() specifies alloc_flags. This patch
removes the unnecessary parameter.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
Acked-by: David Rientjes rient...@google.com
Acked-by: Vlastimil Babka vba...@suse.cz
Acked-by: Michal Hocko mho...@suse.com
Reviewed-by: Christoph Lameter c...@linux.com
---
 include/linux/mmzone.h | 2 +-
 mm/page_alloc.c| 5 +++--
 mm/vmscan.c| 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 754c25966a0a..99cf4209cd45 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -802,7 +802,7 @@ void wakeup_kswapd(struct zone *zone, int order, enum 
zone_type classzone_idx);
 bool zone_watermark_ok(struct zone *z, unsigned int order,
unsigned long mark, int classzone_idx, int alloc_flags);
 bool zone_watermark_ok_safe(struct zone *z, unsigned int order,
-   unsigned long mark, int classzone_idx, int alloc_flags);
+   unsigned long mark, int classzone_idx);
 enum memmap_context {
MEMMAP_EARLY,
MEMMAP_HOTPLUG,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index df959b7d6085..9b6bae688db8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2224,6 +2224,7 @@ static bool __zone_watermark_ok(struct zone *z, unsigned 
int order,
min -= min / 2;
if (alloc_flags  ALLOC_HARDER)
min -= min / 4;
+
 #ifdef CONFIG_CMA
/* If allocation can't use CMA areas don't use free CMA pages */
if (!(alloc_flags  ALLOC_CMA))
@@ -2253,14 +2254,14 @@ bool zone_watermark_ok(struct zone *z, unsigned int 
order, unsigned long mark,
 }
 
 bool zone_watermark_ok_safe(struct zone *z, unsigned int order,
-   unsigned long mark, int classzone_idx, int alloc_flags)
+   unsigned long mark, int classzone_idx)
 {
long free_pages = zone_page_state(z, NR_FREE_PAGES);
 
if (z-percpu_drift_mark  free_pages  z-percpu_drift_mark)
free_pages = zone_page_state_snapshot(z, NR_FREE_PAGES);
 
-   return __zone_watermark_ok(z, order, mark, classzone_idx, alloc_flags,
+   return __zone_watermark_ok(z, order, mark, classzone_idx, 0,
free_pages);
 }
 
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8286938c70de..e950134c4b9a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2450,7 +2450,7 @@ static inline bool compaction_ready(struct zone *zone, 
int order)
balance_gap = min(low_wmark_pages(zone), DIV_ROUND_UP(
zone-managed_pages, KSWAPD_ZONE_BALANCE_GAP_RATIO));
watermark = high_wmark_pages(zone) + balance_gap + (2UL  order);
-   watermark_ok = zone_watermark_ok_safe(zone, 0, watermark, 0, 0);
+   watermark_ok = zone_watermark_ok_safe(zone, 0, watermark, 0);
 
/*
 * If compaction is deferred, reclaim up to a point where
@@ -2933,7 +2933,7 @@ static bool zone_balanced(struct zone *zone, int order,
  unsigned long balance_gap, int classzone_idx)
 {
if (!zone_watermark_ok_safe(zone, order, high_wmark_pages(zone) +
-   balance_gap, classzone_idx, 0))
+   balance_gap, classzone_idx))
return false;
 
if (IS_ENABLED(CONFIG_COMPACTION)  order  compaction_suitable(zone,
-- 
2.4.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/


[PATCH 08/12] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM

2015-08-24 Thread Mel Gorman
__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep.  Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep. The latter should clear
__GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing __GFP_WAIT
behaves differently, there is a risk that people will clear the wrong
flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly indicate
what it does -- setting it allows all reclaim activity, clearing them
prevents it.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
Acked-by: Michal Hocko mho...@suse.com
---
 block/blk-mq.c   |  2 +-
 block/scsi_ioctl.c   |  6 +++---
 drivers/block/drbd/drbd_bitmap.c |  2 +-
 drivers/block/mtip32xx/mtip32xx.c|  2 +-
 drivers/block/nvme-core.c|  4 ++--
 drivers/block/paride/pd.c|  2 +-
 drivers/block/pktcdvd.c  |  4 ++--
 drivers/gpu/drm/i915/i915_gem.c  |  2 +-
 drivers/ide/ide-atapi.c  |  2 +-
 drivers/ide/ide-cd.c |  2 +-
 drivers/ide/ide-cd_ioctl.c   |  2 +-
 drivers/ide/ide-devsets.c|  2 +-
 drivers/ide/ide-disk.c   |  2 +-
 drivers/ide/ide-ioctls.c |  4 ++--
 drivers/ide/ide-park.c   |  2 +-
 drivers/ide/ide-pm.c |  4 ++--
 drivers/ide/ide-tape.c   |  4 ++--
 drivers/ide/ide-taskfile.c   |  4 ++--
 drivers/infiniband/hw/ipath/ipath_file_ops.c |  2 +-
 drivers/infiniband/hw/qib/qib_init.c |  2 +-
 drivers/misc/vmw_balloon.c   |  2 +-
 drivers/scsi/scsi_error.c|  2 +-
 drivers/scsi/scsi_lib.c  |  4 ++--
 fs/cachefiles/internal.h |  2 +-
 fs/direct-io.c   |  2 +-
 fs/nilfs2/mdt.h  |  2 +-
 include/linux/gfp.h  | 16 
 kernel/power/swap.c  | 14 +++---
 lib/percpu_ida.c |  2 +-
 mm/failslab.c|  8 
 mm/filemap.c |  2 +-
 mm/huge_memory.c |  2 +-
 mm/migrate.c |  2 +-
 mm/page_alloc.c  | 10 +-
 security/integrity/ima/ima_crypto.c  |  2 +-
 35 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 7d80379d7a38..16feffc93489 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1221,7 +1221,7 @@ static struct request *blk_mq_map_request(struct 
request_queue *q,
ctx = blk_mq_get_ctx(q);
hctx = q-mq_ops-map_queue(q, ctx-cpu);
blk_mq_set_alloc_data(alloc_data, q,
-   __GFP_WAIT|__GFP_HIGH, false, ctx, hctx);
+   __GFP_RECLAIM|__GFP_HIGH, false, ctx, hctx);
rq = __blk_mq_alloc_request(alloc_data, rw);
ctx = alloc_data.ctx;
hctx = alloc_data.hctx;
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index dda653ce7b24..0774799942e0 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -444,7 +444,7 @@ int sg_scsi_ioctl(struct request_queue *q, struct gendisk 
*disk, fmode_t mode,
 
}
 
-   rq = blk_get_request(q, in_len ? WRITE : READ, __GFP_WAIT);
+   rq = blk_get_request(q, in_len ? WRITE : READ, __GFP_RECLAIM);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto error_free_buffer;
@@ -495,7 +495,7 @@ int sg_scsi_ioctl(struct request_queue *q, struct gendisk 
*disk, fmode_t mode,
break;
}
 
-   if (bytes  blk_rq_map_kern(q, rq, buffer, bytes, __GFP_WAIT)) {
+   if (bytes  blk_rq_map_kern(q, rq, buffer, bytes, __GFP_RECLAIM)) {
err = DRIVER_ERROR  24;
goto error;
}
@@ -536,7 +536,7 @@ static int __blk_send_generic(struct request_queue *q, 
struct gendisk *bd_disk,
struct request *rq;
int err;
 
-   rq = blk_get_request(q, WRITE, __GFP_WAIT);
+   rq = blk_get_request(q, WRITE, __GFP_RECLAIM);
if (IS_ERR(rq))
return PTR_ERR(rq);
blk_rq_set_block_pc(rq);
diff --git a/drivers/block/drbd/drbd_bitmap.c b/drivers/block/drbd/drbd_bitmap.c
index 434c77dcc99e..2940da0011e0 100644
--- a/drivers/block/drbd/drbd_bitmap.c
+++ b/drivers/block/drbd/drbd_bitmap.c
@@ -1016,7 +1016,7 @@ static void bm_page_io_async(struct drbd_bm_aio_ctx *ctx, 
int page_nr) __must_ho
bm_set_page_unchanged(b-bm_pages[page_nr]);
 
if (ctx-flags  BM_AIO_COPY_PAGES) {
-   page = mempool_alloc(drbd_md_io_page_pool, 
__GFP_HIGHMEM|__GFP_WAIT);
+   page = 

[PATCH 06/12] mm, page_alloc: Use masks and shifts when converting GFP flags to migrate types

2015-08-24 Thread Mel Gorman
This patch redefines which GFP bits are used for specifying mobility and
the order of the migrate types. Once redefined it's possible to convert
GFP flags to a migrate type with a simple mask and shift. The only downside
is that readers of OOM kill messages and allocation failures may have been
used to the existing values but scripts/gfp-translate will help.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
---
 include/linux/gfp.h| 12 +++-
 include/linux/mmzone.h |  2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index ad35f300b9a4..a10347ca5053 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -14,7 +14,7 @@ struct vm_area_struct;
 #define ___GFP_HIGHMEM 0x02u
 #define ___GFP_DMA32   0x04u
 #define ___GFP_MOVABLE 0x08u
-#define ___GFP_WAIT0x10u
+#define ___GFP_RECLAIMABLE 0x10u
 #define ___GFP_HIGH0x20u
 #define ___GFP_IO  0x40u
 #define ___GFP_FS  0x80u
@@ -29,7 +29,7 @@ struct vm_area_struct;
 #define ___GFP_NOMEMALLOC  0x1u
 #define ___GFP_HARDWALL0x2u
 #define ___GFP_THISNODE0x4u
-#define ___GFP_RECLAIMABLE 0x8u
+#define ___GFP_WAIT0x8u
 #define ___GFP_NOACCOUNT   0x10u
 #define ___GFP_NOTRACK 0x20u
 #define ___GFP_NO_KSWAPD   0x40u
@@ -123,6 +123,7 @@ struct vm_area_struct;
 
 /* This mask makes up all the page movable related flags */
 #define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
+#define GFP_MOVABLE_SHIFT 3
 
 /* Control page allocator reclaim behavior */
 #define GFP_RECLAIM_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|\
@@ -149,14 +150,15 @@ struct vm_area_struct;
 /* Convert GFP flags to their corresponding migrate type */
 static inline int gfpflags_to_migratetype(const gfp_t gfp_flags)
 {
-   WARN_ON((gfp_flags  GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
+   VM_WARN_ON((gfp_flags  GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
+   BUILD_BUG_ON((1UL  GFP_MOVABLE_SHIFT) != ___GFP_MOVABLE);
+   BUILD_BUG_ON((___GFP_MOVABLE  GFP_MOVABLE_SHIFT) != MIGRATE_MOVABLE);
 
if (unlikely(page_group_by_mobility_disabled))
return MIGRATE_UNMOVABLE;
 
/* Group based on mobility */
-   return (((gfp_flags  __GFP_MOVABLE) != 0)  1) |
-   ((gfp_flags  __GFP_RECLAIMABLE) != 0);
+   return (gfp_flags  GFP_MOVABLE_MASK)  GFP_MOVABLE_SHIFT;
 }
 
 #ifdef CONFIG_HIGHMEM
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 99cf4209cd45..fc0457d005f8 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -37,8 +37,8 @@
 
 enum {
MIGRATE_UNMOVABLE,
-   MIGRATE_RECLAIMABLE,
MIGRATE_MOVABLE,
+   MIGRATE_RECLAIMABLE,
MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
MIGRATE_RESERVE = MIGRATE_PCPTYPES,
 #ifdef CONFIG_CMA
-- 
2.4.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/


[PATCH] gpio: gpiolib: use devm_* API to simplify driver code

2015-08-24 Thread Peng Fan
Use devm_* API to simplify driver code.

Signed-off-by: Peng Fan van.free...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
---
 drivers/gpio/gpiolib.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..f9470b0 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -243,7 +243,8 @@ int gpiochip_add(struct gpio_chip *chip)
int base = chip-base;
struct gpio_desc *descs;
 
-   descs = kcalloc(chip-ngpio, sizeof(descs[0]), GFP_KERNEL);
+   descs = devm_kcalloc(chip-dev, chip-ngpio, sizeof(descs[0]),
+GFP_KERNEL);
if (!descs)
return -ENOMEM;
 
@@ -254,7 +255,7 @@ int gpiochip_add(struct gpio_chip *chip)
if (base  0) {
status = base;
spin_unlock_irqrestore(gpio_lock, flags);
-   goto err_free_descs;
+   goto err_descs;
}
chip-base = base;
}
@@ -262,7 +263,7 @@ int gpiochip_add(struct gpio_chip *chip)
status = gpiochip_add_to_list(chip);
if (status) {
spin_unlock_irqrestore(gpio_lock, flags);
-   goto err_free_descs;
+   goto err_descs;
}
 
for (id = 0; id  chip-ngpio; id++) {
@@ -308,9 +309,7 @@ err_remove_chip:
list_del(chip-list);
spin_unlock_irqrestore(gpio_lock, flags);
chip-desc = NULL;
-err_free_descs:
-   kfree(descs);
-
+err_descs:
/* failures here can mean systems won't boot... */
pr_err(%s: GPIOs %d..%d (%s) failed to register\n, __func__,
chip-base, chip-base + chip-ngpio - 1,
-- 
1.8.4.5

--
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 5/6] i2c: Replace I2C_CROS_EC_TUNNEL dependency

2015-08-24 Thread Wolfram Sang
On Wed, Aug 19, 2015 at 01:19:57PM +0200, Javier Martinez Canillas wrote:
 The ChromeOS EC tunnel I2C bus driver depend on CROS_EC_PROTO but
 MFD_CROS_EC select CROS_EC_PROTO instead. Mixing select and depends
 on is bad practice as it may lead to circular Kconfig dependencies.
 
 Since the platform device that is matched with the I2C bus driver
 is registered by the ChromeOS EC mfd driver, I2C_CROS_EC_TUNNEL
 really depends on MFD_CROS_EC. And because this config option
 selects CROS_EC_PROTO, that dependency is met as well. So make the
 driver to depend on MFD_CROS_EC instead of CROS_EC_PROTO.
 
 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 

Applied to for-next, thanks!



signature.asc
Description: Digital signature


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

2015-08-24 Thread Eric W. Biederman


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.


Eric

E.g. Writting two bytes (1\0) to
/proc/sys/net/ipv4/conf/eth0/rp_filter.
write(fd, 1\0, 2) return EINVAL.

Signed-off-by: Sean Fu fxinr...@gmail.com
---
 kernel/sysctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 19b62b5..c2b0594 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2004,7 +2004,7 @@ static int do_proc_dointvec_conv(bool *negp,
unsigned long *lvalp,
return 0;
 }

-static const char proc_wspace_sep[] = { ' ', '\t', '\n' };
+static const char proc_wspace_sep[] = { ' ', '\t', '\n', '\0' };

 static int __do_proc_dointvec(void *tbl_data, struct ctl_table *table,
  int write, void __user *buffer,

--
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/


[char-misc 1/2] mei: Fix debugfs filename in error output

2015-08-24 Thread Tomas Winkler
From: Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com

Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
---
 drivers/misc/mei/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index 4b469cf9e60f..c157f0ba575c 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -213,7 +213,7 @@ int mei_dbgfs_register(struct mei_device *dev, const char 
*name)
f = debugfs_create_file(active, S_IRUSR, dir,
dev, mei_dbgfs_fops_active);
if (!f) {
-   dev_err(dev-dev, meclients: registration failed\n);
+   dev_err(dev-dev, active: registration failed\n);
goto err;
}
f = debugfs_create_file(devstate, S_IRUSR, dir,
-- 
2.4.3

--
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 04/12] mm, page_alloc: Only check cpusets when one exists that can be mem-controlled

2015-08-24 Thread Vlastimil Babka

On 08/24/2015 02:09 PM, Mel Gorman wrote:

David Rientjes correctly pointed out that the root cpuset may not exclude
mems on the system so, even if mounted, there's no need to check or be
worried about concurrent change when there is only one cpuset.

The three checks for cpusets_enabled() care whether a cpuset exists that
can limit memory, not that cpuset is enabled as such. This patch replaces
cpusets_enabled() with cpusets_mems_enabled() which checks if at least one
cpuset exists that can limit memory and updates the appropriate call sites.

Signed-off-by: Mel Gorman mgor...@suse.de
---
  include/linux/cpuset.h | 16 +---
  mm/page_alloc.c|  2 +-
  2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 6eb27cb480b7..1e823870987e 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -17,10 +17,6 @@
  #ifdef CONFIG_CPUSETS

  extern struct static_key cpusets_enabled_key;
-static inline bool cpusets_enabled(void)
-{
-   return static_key_false(cpusets_enabled_key);
-}

  static inline int nr_cpusets(void)
  {
@@ -28,6 +24,12 @@ static inline int nr_cpusets(void)
return static_key_count(cpusets_enabled_key) + 1;
  }

+/* Returns true if a cpuset exists that can set cpuset.mems */
+static inline bool cpusets_mems_enabled(void)
+{
+   return nr_cpusets()  1;
+}
+


Hm, but this loses the benefits of static key branches?
How about something like:

  if (static_key_false(cpusets_enabled_key))
return nr_cpusets()  1
  else
return false;




  static inline void cpuset_inc(void)
  {
static_key_slow_inc(cpusets_enabled_key);
@@ -104,7 +106,7 @@ extern void cpuset_print_task_mems_allowed(struct 
task_struct *p);
   */
  static inline unsigned int read_mems_allowed_begin(void)
  {
-   if (!cpusets_enabled())
+   if (!cpusets_mems_enabled())
return 0;

return read_seqcount_begin(current-mems_allowed_seq);
@@ -118,7 +120,7 @@ static inline unsigned int read_mems_allowed_begin(void)
   */
  static inline bool read_mems_allowed_retry(unsigned int seq)
  {
-   if (!cpusets_enabled())
+   if (!cpusets_mems_enabled())
return false;


Actually I doubt it's much of benefit for these usages, even if the 
static key benefits are restored. If there's a single root cpuset, we 
would check the seqlock prior to this patch, now we'll check static key 
value (which should have the same cost?). With 1 cpusets, we would 
check seqlock prior to this patch, now we'll check static key value 
*and* the seqlock...




return read_seqcount_retry(current-mems_allowed_seq, seq);
@@ -139,7 +141,7 @@ static inline void set_mems_allowed(nodemask_t nodemask)

  #else /* !CONFIG_CPUSETS */

-static inline bool cpusets_enabled(void) { return false; }
+static inline bool cpusets_mems_enabled(void) { return false; }

  static inline int cpuset_init(void) { return 0; }
  static inline void cpuset_init_smp(void) {}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 62ae28d8ae8d..2c1c3bf54d15 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2470,7 +2470,7 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int 
order, int alloc_flags,
if (IS_ENABLED(CONFIG_NUMA)  zlc_active 
!zlc_zone_worth_trying(zonelist, z, allowednodes))
continue;
-   if (cpusets_enabled() 
+   if (cpusets_mems_enabled() 
(alloc_flags  ALLOC_CPUSET) 
!cpuset_zone_allowed(zone, gfp_mask))
continue;


Here the benefits are less clear. I guess cpuset_zone_allowed() is 
potentially costly...


Heck, shouldn't we just start the static key on -1 (if possible), so 
that it's enabled only when there's 2+ cpusets?

--
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/10] irqchip: irq-mips-gic: export gic_send_ipi

2015-08-24 Thread Thomas Gleixner
On Mon, 24 Aug 2015, Qais Yousef wrote:

 Some drivers might require to send ipi to other cores. So export it.

Which IPIs do you need to send from a driver which are not exposed by
the SMP functions already?

 This will be used later by AXD driver.

That smells fishy and it wants a proper explanation WHY and not just a
sloppy statement that it will be used later. I can figure that out
myself as exporting a function without using it does not make any sense.

Thanks,

tglx
--
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 linux-next v4 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller

2015-08-24 Thread Russell King - ARM Linux
On Mon, Aug 24, 2015 at 01:03:51PM +0200, Marek Vasut wrote:
 These are functions, not macros :)
 
 btw is there any reason for these ? I'd say, just put the read*() and
 write*() functions directly into the code and be done with it, it is
 much less confusing.
 
 Also, why do you use the _relaxed() versions of the functions ?

Now that the _relaxed() accessors are available throughout the kernel,
everyone should be using the _relaxed() versions unless they need the
properties of the non-relaxed versions.  Remember that the non-relaxed
versions are rather expensive on ARM due to the need to go all the way
out to the L2 cache - it at least doubles the number of accesses for
every read*/write*().

-- 
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 v3 06/14] Documentation: drm/bridge: add document for analogix_dp

2015-08-24 Thread Russell King - ARM Linux
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
 On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
  +   -analogix,color-depth:
  +   number of bits per colour component.
  +   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
 
 This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
 drop the vendor prefix.

Please think about this some more.  What does color-depth mean?  Does it
mean the number of bits per colour _component_, or does it mean the total
number of bits to represent a particular colour.  It's confusing as it
stands.

  +Optional properties for dp-controller:
  +   -analogix,hpd-gpio:
  +   Hotplug detect GPIO.
  +   Indicates which GPIO should be used for hotplug
  +   detection
 
 We should align with hpd-gpios used by HDMI connector binding. Or do
 we need a DP connector binding that this should be defined in?
 Probably so.
 
 The DRM related bindings are such a cluster f*ck with everyone picking
 their own way to do things. Just grep hpd in bindings for starters.
 That is just the tip.

I'm not surprised one iota that DRM bindings are a mess.  There's no one
overlooking the adoption of DRM bindings, so surprise surprise, everyone
does their own thing.  This is exactly what happens every time in that
scenario.  It's not a new problem.

When we adopted the graph bindings for iMX DRM, I thought exactly at that
time it would be nice if this could become the standard for binding DRM
components together but I don't have the authority from either the DT
perspective or the DRM perspective to mandate that.  Neither does anyone
else.  That's the _real_ problem here.

I've seen several DRM bindings go by which don't use the of-graph stuff,
which means that they'll never be compatible with generic components
which do use the of-graph stuff.

Like you say, it's a mess, but it's a mess of our own making, because no
one has the authority to regulate this.

-- 
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 RESEND] sched/nohz: Affine unpinned timers to housekeepers

2015-08-24 Thread Frederic Weisbecker
On Mon, Aug 24, 2015 at 08:44:12AM +0200, Ingo Molnar wrote:
 2)
 
 What happens if the boot CPU is offlined? (under 
 CONFIG_BOOTPARAM_HOTPLUG_CPU0=y)
 
 I don't see CPU hotplug callbacks fixing up the housekeeping_mask if the boot 
 CPU 
 is offlined.

We have tick_nohz_cpu_down_callback() which makes sure that the timekeeper, 
which
is the boot CPU in nohz full, never gets offlined.

 
 Thanks,
 
   Ingo
--
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 v2 5/5] arm64: add KASan support

2015-08-24 Thread Linus Walleij
On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Tue, Jul 21, 2015 at 11:27:56PM +0200, Linus Walleij wrote:
 On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin a.ryabi...@samsung.com 
 wrote:

  I used vexpress. Anyway, it doesn't matter now, since I have an update
  with a lot of stuff fixed, and it works on hardware.
  I still need to do some work on it and tomorrow, probably, I will share.

 Ah awesome. I have a stash of ARM boards so I can test it on a
 range of hardware once you feel it's ready.

 Sorry for pulling stuff out of your hands, people are excited about
 KASan ARM32 as it turns out.

 People may be excited about it because it's a new feature, but we really
 need to consider whether gobbling up 512MB of userspace for it is a good
 idea or not.  There are programs around which like to map large amounts
 of memory into their process space, and the more we steal from them, the
 more likely these programs are to fail.

I looked at some different approaches over the last weeks for this
when playing around with KASan.

It seems since KASan was developed on 64bit systems, this was
not much of an issue for them as they could take their shadow
memory from the vmalloc space.

I think it is possible to actually just steal as much memory as is
needed to cover the kernel, and not 1/8 of the entire addressable
32bit space. So instead of covering all from 0x0-0x
at least just MODULES_VADDR thru 0x should be enough.
So if that is 0xbf00-0x in most cases, 0x4100
bytes, then 1/8 of that, 0x820, 130MB should be enough.
(Andrey need to say if this is possible.)

That will probably miss some usecases I'm not familiar with, where
the kernel is actually executing something below 0xbf00...

I looked at taking memory from vmalloc instead, but ran into
problems since this is subject to the highmem split and KASan
need to have it's address offset at compile time. On
Ux500 I managed to remove all the static maps and steal memory
from the top of the vmalloc area instead of the beginning, but
that is probably not generally feasible.

I suspect you have better ideas than what I can come up
with though.

Yours,
Linus Walleij
--
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/7] drm/vc4: Add devicetree bindings for VC4.

2015-08-24 Thread Rob Herring
On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt e...@anholt.net wrote:
 Stephen Warren swar...@wwwdotorg.org writes:

 On 08/12/2015 06:56 PM, Eric Anholt wrote:
 Signed-off-by: Eric Anholt e...@anholt.net

 This one definitely needs a patch description, since someone might not
 know what a VC4 is, and git log won't show the text from the binding
 doc itself. I'd suggest adding the initial paragraph of the binding doc
 as the patch description, or more.

 diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
 b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

 +- hvss: List of references to HVS video scalers
 +- encoders: List of references to output encoders (HDMI, SDTV)

 Would it make sense to make all those nodes child node of the vc4
 object. That way, there's no need to have these lists of objects; they
 can be automatically built up as the DT is enumerated. I know that e.g.
 the NVIDIA Tegra host1x binding works this way, and I think it may have
 been inspired by other similar cases.

 I've looked at tegra, and the component system used by msm appears to be
 nicer than it.  To follow tegra's model, it looks like I need to build
 this extra bus thing corresponding to host1x that is effectively the
 drivers/base/component.c code, so that I can get at vc4's structure from
 the component drivers.

 Of course, this is only appropriate if the HW modules really are
 logically children of the VC4 HW module. Perhaps they aren't. If they
 aren't though, I wonder what this vc4 module actually represents in HW?

 It's the subsystem, same as we use a subsystem node for msm, sti,
 rockchip, imx, and exynos.  This appears to be the common model of how
 the collection of graphics-related components is represented in the DT.

I think most of these bindings are wrong. They are grouped together
because that is what DRM wants not because that reflects the h/w. So
convince me this is one block, not that it is what other people do.

Rob
--
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] Docs: dt: add generic MSI bindings

2015-08-24 Thread Mark Rutland
On Mon, Aug 24, 2015 at 02:37:59PM +0100, Rob Herring wrote:
 On Mon, Aug 24, 2015 at 5:17 AM, Mark Rutland mark.rutl...@arm.com wrote:
  On Wed, Aug 05, 2015 at 05:51:20PM +0100, Mark Rutland wrote:
  Rob,
 
  Do you have any objections to this, or are you happy to take this patch?
 
  There's a user of this binding (the GICv3 ITS) queued for v4.3 already in
  the tip tree, so either we either need to be ok with this binding or we
  need to rework that before v4.3.
 
  Sorry to ping, but are you happy to take this? Marc's replied and
  provided his ack.
 
 Sorry. Looks fine to me, so I'll apply.

Cheers!

 What about patch 2 and 3? I can't find patch 3 in my mail.

Those should wait for now.

We don't yet have a user and there's ongoing discussion w.r.t. the PCI
parts that I expect will pick up again as people return from LPC.

Thanks,
Mark.
--
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 RESEND] sched/nohz: Affine unpinned timers to housekeepers

2015-08-24 Thread Paul E. McKenney
On Mon, Aug 24, 2015 at 08:44:12AM +0200, Ingo Molnar wrote:
 
 * Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
 
   here it's fully set - triggering the bug I'm worried about. So what am I 
   missing, what prevents CONFIG_NO_HZ_FULL_ALL from crashing?
  
  The boot CPU is excluded from tick_nohz_full_mask in tick_nohz_init(), 
  which is 
  called from tick_init() which is called from start_kernel() shortly after 
  rcu_init():
  
  cpu = smp_processor_id();
  
  if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {
  pr_warning(NO_HZ: Clearing %d from nohz_full range for 
  timekeeping\n, cpu);
  cpumask_clear_cpu(cpu, tick_nohz_full_mask);
  }
  
  This happens after the call to tick_nohz_init_all() that does the 
  cpumask_setall() that you called out above.
 
 Ah, indeed - I somehow missed that.
 
 This brings up two other questions:
 
 1)
 
 the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full 
 mask to 
 it (housekeeping_mask - a variable mask to begin with) and recover the 
 housekeeping CPU via:
 
 +   return cpumask_any_and(housekeeping_mask, cpu_online_mask);
 
 which can be pretty expensive, and which gets executed in two hotpaths:
 
 kernel/time/hrtimer.c:  return per_cpu(hrtimer_bases, 
 get_nohz_timer_target());
 kernel/time/timer.c:return per_cpu_ptr(tvec_bases, 
 get_nohz_timer_target());
 
 ... why not just use a single housekeeping_cpu which would be way faster to 
 pass 
 down to the timer code?

The housekeeping_cpu came later, but that does seem like a good optimization.

 2)
 
 What happens if the boot CPU is offlined? (under 
 CONFIG_BOOTPARAM_HOTPLUG_CPU0=y)
 
 I don't see CPU hotplug callbacks fixing up the housekeeping_mask if the boot 
 CPU 
 is offlined.

The tick_nohz_cpu_down_callback() function does this, though in a less
than obvious way.  The tick_do_timer_cpu variable is the housekeeping
CPU that is currently handling timing, and it is not permitted to go
offline.

Thanx, Paul

--
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 4/8] jbd, jbd2: Do not fail journal because of frozen_buffer allocation failure

2015-08-24 Thread Michal Hocko
Hi Ted,

On Sat 15-08-15 09:54:22, Theodore Ts'o wrote:
 On Wed, Aug 12, 2015 at 11:14:11AM +0200, Michal Hocko wrote:
   Is this if (!committed_data) { check now dead code?
   
   I also see other similar suspected dead sites in the rest of the series.
  
  You are absolutely right. I have updated the patches.
 
 Have you sent out an updated version of these patches?  Maybe I missed
 it, but I don't think I saw them.

would you be interested in these two patches sent with rephrased
changelog to not depend on the patch which allows GFP_NOFS to fail? The
way this has been handled for btrfs...
-- 
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/


Re: [PATCH v3 1/1] USB:option:add ZTE PIDs

2015-08-24 Thread Johan Hovold
On Mon, Aug 24, 2015 at 09:51:33AM +0200, Bjørn Mork wrote:
 Johan Hovold jo...@kernel.org writes:
  On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
  
   #define BENQ_VENDOR_ID0x04a5
   #define BENQ_PRODUCT_H10  0x4068
  @@ -544,6 +548,14 @@ static const struct option_blacklist_info 
  zte_mc2716_z_blacklist = {
 .sendsetup = BIT(1) | BIT(2) | BIT(3),
   };
   
  +static const struct option_blacklist_info 
  zte_me3620andzm8620_xl_blacklist = {
  +  .reserved = BIT(3) | BIT(4) | BIT(5),
  +};
 
  Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
  even if they reserve the same ports.
 
 Why?

To avoid including every device family in the symbol name (and we
already have duplicate blacklist definitions).

 Wouldn't it be better to merge all identical lists and give them
 structured names describing their contents instead?

It certainly would.

 E.g.
 
  static const struct option_blacklist_info bi_s0001_r = {
 .sendsetup = BIT(0) | BIT(1),
  };
 
  static const struct option_blacklist_info bi_s0001_r04 = {
 .sendsetup = BIT(0) | BIT(1),
 .reserved = BIT(4),
  };
 
  static const struct option_blacklist_info bi_s_r030405 =  {
   .reserved = BIT(3) | BIT(4) | BIT(5),
  };
 
 
 etc.  Or some other naming scheme.

Perhaps bi_ssetup_mask_rreserved_mask (e.g. bi_s3_r0, bi_s3_r10, and
bi_s0_r38 for the above) would be too compact?

 I don't see the point of having lots of identical structs just to be
 able to name them after some rarely meaningful marketing name.  Many
 vendors recycle their pids, making this completely futile.

I agree. Let's just decide on a naming scheme first.

Johan
--
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 v2] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-24 Thread Wolfram Sang
On Mon, Aug 17, 2015 at 11:52:51PM -0700, Dmitry Torokhov wrote:
 Instead of having each i2c driver individually parse device tree data in
 case it or platform supports separate wakeup interrupt, and handle
 enabling and disabling wakeup interrupts in their power management
 routines, let's have i2c core do that for us.
 
 Platforms wishing to specify separate wakeup interrupt for the device
 should use named interrupt syntax in their DTSes:
 
   interrupt-parent = intc1;
   interrupts = 5 0, 6 0;
   interrupt-names = irq, wakeup;
 
 This patch is inspired by work done by Vignesh R vigne...@ti.com for
 pixcir_i2c_ts driver.
 
 Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com

Applied to for-next, thanks!



signature.asc
Description: Digital signature


[GIT PULL] Move cert handling to certs/ directory

2015-08-24 Thread David Howells
Hi James,

Sorry for the late request, but can you pull this please?  It's a set of
commits that puts a bit of polish on the previous module signing patches.
It moves the certificate handling to its own directory rather than sharing
in the kernel/ directory.  It then moves key generation into the certs/
directory rather than doing it in the root.

This allows us to simplify the kernel/Makefile and slightly simplify the
new certs/Makefile.  It also keeps the various generated files in the same
place to make them easier to find and clean up.

David
---
The following changes since commit 0e38c35815f50e5a347977d76fb5eb4c3bf020b5:

  Merge branch 'smack-for-4.3' of https://github.com/cschaufler/smack-next into 
next (2015-08-14 17:35:10 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
tags/modsign-pkcs7-20150814

for you to fetch changes up to 3ee550f12c1529a023f71c9b5becb3351911047b:

  modsign: Handle signing key in source tree (2015-08-14 16:32:52 +0100)


Module signing with PKCS#7


David Howells (1):
  Move certificate handling to its own directory

David Woodhouse (2):
  modsign: Use if_changed rule for extracting cert from module signing key
  modsign: Handle signing key in source tree

 Documentation/module-signing.txt|  18 ++--
 MAINTAINERS |   9 ++
 Makefile|   9 +-
 certs/Kconfig   |  42 ++
 certs/Makefile  |  94 +
 {kernel = certs}/system_certificates.S |   4 +-
 {kernel = certs}/system_keyring.c  |   0
 crypto/Kconfig  |   1 +
 init/Kconfig|  39 -
 kernel/Makefile | 143 
 scripts/Kbuild.include  |  51 
 11 files changed, 212 insertions(+), 198 deletions(-)
 create mode 100644 certs/Kconfig
 create mode 100644 certs/Makefile
 rename {kernel = certs}/system_certificates.S (86%)
 rename {kernel = certs}/system_keyring.c (100%)
--
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 RESEND 1/2] ovl: free stack of paths in ovl_fill_super

2015-08-24 Thread Konstantin Khlebnikov
This fixes small memory leak after mount.

Kmemleak report:

unreferenced object 0x88003683fe00 (size 16):
  comm mount, pid 2029, jiffies 4294909563 (age 33.380s)
  hex dump (first 16 bytes):
20 27 1f bb 00 88 ff ff 40 4b 0f 36 02 88 ff ff   '..@K.6
  backtrace:
[811f8cd4] create_object+0x124/0x2c0
[817a059b] kmemleak_alloc+0x7b/0xc0
[811dffe6] __kmalloc+0x106/0x340
[a01b7a29] ovl_fill_super+0x389/0x9a0 [overlay]
[81200ac4] mount_nodev+0x54/0xa0
[a01b7118] ovl_mount+0x18/0x20 [overlay]
[81201ab3] mount_fs+0x43/0x170
[81220d34] vfs_kern_mount+0x74/0x170
[812233ad] do_mount+0x22d/0xdf0
[812242cb] SyS_mount+0x7b/0xc0
[817b6bee] entry_SYSCALL_64_fastpath+0x12/0x76
[] 0x

Signed-off-by: Konstantin Khlebnikov khlebni...@yandex-team.ru
Fixes: a78d9f0d5d5c (ovl: support multiple lower layers)
Cc: sta...@vger.kernel.org # v4.0
---
 fs/overlayfs/super.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 7466ff339c66..3f90c43c3c4a 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -1048,6 +1048,7 @@ static int ovl_fill_super(struct super_block *sb, void 
*data, int silent)
oe-lowerstack[i].dentry = stack[i].dentry;
oe-lowerstack[i].mnt = ufs-lower_mnt[i];
}
+   kfree(stack);
 
root_dentry-d_fsdata = oe;
 

--
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 RESEND 2/2] ovl: free lower_mnt array in ovl_put_super

2015-08-24 Thread Konstantin Khlebnikov
This fixes memory leak after umount.

Kmemleak report:

unreferenced object 0x8800ba791010 (size 8):
  comm mount, pid 2394, jiffies 4294996294 (age 53.920s)
  hex dump (first 8 bytes):
20 1c 13 02 00 88 ff ff   ...
  backtrace:
[811f8cd4] create_object+0x124/0x2c0
[817a059b] kmemleak_alloc+0x7b/0xc0
[811dffe6] __kmalloc+0x106/0x340
[a0152bfc] ovl_fill_super+0x55c/0x9b0 [overlay]
[81200ac4] mount_nodev+0x54/0xa0
[a0152118] ovl_mount+0x18/0x20 [overlay]
[81201ab3] mount_fs+0x43/0x170
[81220d34] vfs_kern_mount+0x74/0x170
[812233ad] do_mount+0x22d/0xdf0
[812242cb] SyS_mount+0x7b/0xc0
[817b6bee] entry_SYSCALL_64_fastpath+0x12/0x76
[] 0x

Signed-off-by: Konstantin Khlebnikov khlebni...@yandex-team.ru
Fixes: dd662667e6d3 (ovl: add mutli-layer infrastructure)
Cc: sta...@vger.kernel.org # v4.0
---
 fs/overlayfs/super.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 3f90c43c3c4a..8d04b86e0680 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -544,6 +544,7 @@ static void ovl_put_super(struct super_block *sb)
mntput(ufs-upper_mnt);
for (i = 0; i  ufs-numlower; i++)
mntput(ufs-lower_mnt[i]);
+   kfree(ufs-lower_mnt);
 
kfree(ufs-config.lowerdir);
kfree(ufs-config.upperdir);

--
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/2] mfd: devicetree: bindings: 88pm800: Add DT property for dual phase enable

2015-08-24 Thread Lee Jones
On Mon, 24 Aug 2015, Vaibhav Hiremath wrote:

 88PM860 family of device supports dual phase mode on BUCK1 supply
 providing total 6A capacity.
 Note that by default they operate independently with 3A capacity.
 
 This patch updates the devicetree binding with DT property
 to enable dual-phase mode on BUCK1.
 
 Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
 ---
  Documentation/devicetree/bindings/mfd/88pm800.txt | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt 
 b/Documentation/devicetree/bindings/mfd/88pm800.txt
 index dec842f..2c82fcb 100644
 --- a/Documentation/devicetree/bindings/mfd/88pm800.txt
 +++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
 @@ -9,6 +9,12 @@ Required parent device properties:
  - #interrupt-cells   : should be 1.
 The cell is the 88pm80x local IRQ number
  
 +Optional properties :
 +- marvell,88pm860-buck1-dualphase-en  : If set, enable dual phase on BUCK1,
 +  providing 6A capacity.
 +  Without this both BUCK1A and BUCK1B operates independently with 3A 
 capacity.
 +  (This property is only applicable to 88PM860)

This will require a Regulator Ack.

My suggestion would be to remove the 'buck' number, as the same
property could be used on any Buck, and remove the '-en' part, as
this is implied.

  88pm80x family of devices consists of varied group of sub-devices:
  
  Device   Supply Names Description

-- 
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 5/9] x86/intel_rdt: Add new cgroup and Class of service management

2015-08-24 Thread Marcelo Tosatti
On Sun, Aug 23, 2015 at 11:47:49AM -0700, Vikas Shivappa wrote:
 
 
 On Fri, 21 Aug 2015, Marcelo Tosatti wrote:
 
 On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
 
 
 On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
 
 Vikas, Tejun,
 
 This is an updated interface. It addresses all comments made
 so far and also covers all use-cases the cgroup interface
 covers.
 
 Let me know what you think. I'll proceed to writing
 the test applications.
 
 Usage model:
 
 
 This document details how CAT technology is
 exposed to userspace.
 
 Each task has a list of task cache reservation entries (TCRE list).
 
 The init process is created with empty TCRE list.
 
 There is a system-wide unique ID space, each TCRE is assigned
 an ID from this space. ID's can be reused (but no two TCREs
 have the same ID at one time).
 
 The interface accomodates transient and independent cache allocation
 adjustments from applications, as well as static cache partitioning
 schemes.
 
 Allocation:
 Usage of the system calls require CAP_SYS_CACHE_RESERVATION capability.
 
 A configurable percentage is reserved to tasks with empty TCRE list.
 
 Hi Vikas,
 
 And how do you think you will do this without a system controlled
 mechanism ?
 Everytime in your proposal you include these caveats
 which actually mean to include a system controlled interface in the
 background ,
 and your below interfaces make no mention of this really ! Why do we
 want to confuse ourselves like this ?
 syscall only interface does not seem to work on its own for the
 cache allocation scenario. This can only be a nice to have interface
 on top of a system controlled mechanism like cgroup interface. Sure
 you can do all the things you did with cgroup with the same with
 syscall interface but the point is what are the use cases that cant
 be done with this syscall only interface. (ex: to deal with cases
 you brought up earlier like when an app does cache intensive work
 for some time and later changes - it could use the syscall interface
 to quickly reqlinquish the cache lines or change a clos associated
 with it)
 
 All use cases can be covered with the syscall interface.
 
 * How to convert from cgroups interface to syscall interface:
 Cgroup: Partition cache in cgroups, add tasks to cgroups.
 Syscall: Partition cache in TCRE, add TCREs to tasks.
 
 You build the same structure (task -- CBM) either via syscall
 or via cgroups.
 
 Please be more specific, can't really see any problem.
 
 Well at first you mentioned that the cgroup does not support
 specifying size in bytes and percentage and then you eventually
 agreed to my explanation that you can easily write a bash script to
 do the same with cgroup bitmasks. (although i had to go through the
 pain of reading all the proposals you sent without giving a chance
 to explain how it can be used or so). 

Yes we could write the (bytes --to-- cacheways) convertion in
userspace. But since we are going for a different interface, can also
fix that problem as well in the kernel.

 Then you had a confusion in
 how I explained the co mounting of the cpuset and intel_rdt and
 instead of asking a question or pointing out issue, you go ahead and
 write a whole proposal and in the end even say will cook a patch
 before I even try to explain you.

The syscall interface is more flexible.

Why not use a more flexible interface if possible?

 And then you send proposals after proposals 
 which varied from
 modifying the cgroup interface itself to slightly modifying cgroups

Yes, trying to solve the problems our customers will be facing in the field.
So, this proposals are not coming out of thin air.

 and adding syscalls and then also automatically controlling the
 cache alloc (with all your extend mask capabilities) without
 understanding what the framework is meant to do or just asking or
 specifically pointing out any issues in the patch. 

There is a practical problem the extension of mask capabilities is 
solving. Check item 6 of the attached text document.

 You had been
 reviewing the cgroup pathes for many versions unlike others who
 accepted they need time to think about it or accepted that they
 maynot understand the feature yet.
 So what is that changed in the patches that is not acceptable now ?

Tejun proposed a syscall interface. He is a right, a syscall interface
is much more flexible. Blame him.

 Many things have been bought up multiple times even after you agreed
 to a solution already proposed. I was only suggesting that this can
 be better and less confusing if you point out the exact issue in the
 patch just like how Thomas or all of the reviewers have been doing.

 With the rest of the reviewers I either fix the issue or point out a
 flaw in the review.
 If you dont like cgroup interface now , 
 would be best to indicate or
 discuss the specifics of the shortcommings clearly before sending
 new proposals. 
 That way we can come up with an interface which does
 better and works better in 

Re: [PATCH] nfs:Fix error handling in the function nfs_vm_page_mkwrite

2015-08-24 Thread Trond Myklebust
On Sat, Aug 22, 2015 at 6:34 PM, Nicholas Krause xerofo...@gmail.com wrote:
 This fixes error handling in the function nfs_vm_page_mkwrite to
 properly check if the function wait_on_bit_action returned something
 other then zero as if so return to the caller of nfs_vm_page_mkwrite
 to signal that a internal failure has occurred when calling this
 function and should be handled by the caller.

 Signed-off-by: Nicholas Krause xerofo...@gmail.com
 ---
  fs/nfs/file.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/fs/nfs/file.c b/fs/nfs/file.c
 index cc4fa1e..698851a 100644
 --- a/fs/nfs/file.c
 +++ b/fs/nfs/file.c
 @@ -612,8 +612,10 @@ static int nfs_vm_page_mkwrite(struct vm_area_struct 
 *vma, struct vm_fault *vmf)
 /* make sure the cache has finished storing the page */
 nfs_fscache_wait_on_page_write(NFS_I(inode), page);

 -   wait_on_bit_action(NFS_I(inode)-flags, NFS_INO_INVALIDATING,
 -   nfs_wait_bit_killable, TASK_KILLABLE);
 +   ret = wait_on_bit_action(NFS_I(inode)-flags, NFS_INO_INVALIDATING,
 +nfs_wait_bit_killable, TASK_KILLABLE);
 +   if (ret)
 +   goto out;

 lock_page(page);
 mapping = page_file_mapping(page);
 --
 2.1.4


nfs_vm_page_mkwrite() is only allowed to return the value '0' or one
or more of the VM_FAULT_* flags. It may not return kernel error
values.

Trond
--
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

2015-08-24 Thread Jon Hunter

On 24/08/15 10:22, Vinod Koul wrote:
 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

I see what you are saying. I did some testing with ftrace today to trace
rpm and suspend/resume calls. If the dma controller is runtime suspended
and I do not call pm_runtime_get_sync() above then I do not see any
runtime resume of the dma controller prior to suspend. Now I was hoping
that this would cause a complete kernel crash but it did not and so the
DMA clock did not appear to be needed here (at least on the one board I
tested). However, I would not go as far as to remove this and prefer to
keep as above.

Furthermore, other drivers do similar things, including the sirf dma
controller (see sirf-dma.c).

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/


[PATCH v4 07/13] usb: otg: add OTG core

2015-08-24 Thread Roger Quadros
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.

It provides APIs for the following tasks

- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine

Signed-off-by: Roger Quadros rog...@ti.com
---
 MAINTAINERS  |4 +-
 drivers/usb/Kconfig  |2 +-
 drivers/usb/Makefile |1 +
 drivers/usb/common/Makefile  |3 +-
 drivers/usb/common/usb-otg.c | 1061 ++
 drivers/usb/common/usb-otg.h |   71 +++
 drivers/usb/core/Kconfig |   11 +-
 include/linux/usb/otg.h  |  189 +++-
 8 files changed, 1321 insertions(+), 21 deletions(-)
 create mode 100644 drivers/usb/common/usb-otg.c
 create mode 100644 drivers/usb/common/usb-otg.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a9ae6c1..4bc1279 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10667,12 +10667,14 @@ S:Maintained
 F: Documentation/usb/ohci.txt
 F: drivers/usb/host/ohci*
 
-USB OTG FSM (Finite State Machine)
+USB OTG/DRD core and FSM (Finite State Machine)
 M: Peter Chen peter.c...@freescale.com
+M: Roger Quadros rog...@ti.com
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
 L: linux-...@vger.kernel.org
 S: Maintained
 F: drivers/usb/common/usb-otg-fsm.c
+F: drivers/usb/common/usb-otg.c
 
 USB OVER IP DRIVER
 M: Valentina Manea valentina.mane...@gmail.com
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8ed451d..5b625e2 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -32,7 +32,7 @@ if USB_SUPPORT
 config USB_COMMON
tristate
default y
-   depends on USB || USB_GADGET
+   depends on USB || USB_GADGET || USB_OTG
 
 config USB_ARCH_HAS_HCD
def_bool y
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index d8926c6..769d13b 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,5 +60,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS)   += renesas_usbhs/
 obj-$(CONFIG_USB_GADGET)   += gadget/
 
 obj-$(CONFIG_USB_COMMON)   += common/
+obj-$(CONFIG_USB_OTG)  += common/
 
 obj-$(CONFIG_USBIP_CORE)   += usbip/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 6bbb3ec..730d928 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_USB_COMMON)  += usb-common.o
 usb-common-y += common.o
 usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
-obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+usbotg-y   := usb-otg.o usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG)  += usbotg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..930c2fe
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,1061 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/list.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/usb/otg.h
+#include linux/usb/phy.h /* enum usb_otg_state */
+#include linux/usb/gadget.h
+#include linux/workqueue.h
+
+#include usb-otg.h
+
+struct otg_gcd {
+   struct usb_gadget *gadget;
+   struct otg_gadget_ops *ops;
+};
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/* Hosts and Gadgets waiting for OTG controller */
+struct otg_wait_data {
+   struct device *dev; /* OTG controller device */
+
+   struct otg_hcd primary_hcd;
+   struct otg_hcd shared_hcd;
+   struct otg_gcd gcd;
+   struct list_head list;
+};
+
+LIST_HEAD(wait_list);
+static DEFINE_MUTEX(wait_list_mutex);
+
+static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
+{
+   if (!hcd-primary_hcd)
+   return 1;
+   return hcd == hcd-primary_hcd;
+}
+
+/**
+ * Check if the OTG device is in our wait list and return
+ * otg_wait_data, else NULL.
+ *
+ * wait_list_mutex must be held.
+ */
+static struct otg_wait_data *usb_otg_get_wait(struct device *otg_dev)
+{
+   struct otg_wait_data *wait;
+
+   if (!otg_dev)
+   return NULL;
+
+   /* is there an entry for this otg_dev ?*/
+   

RE: [PATCH v4 3/6] power: Add support for DA9150 Fuel-Gauge

2015-08-24 Thread Opensource [Adam Thomson]
On August 04, 2015 17:17, Adam Thomson wrote:

 This adds power supply driver support for the Fuel-Gauge part of
 the DA9150 combined Charger and Fuel-Gauge device.
 
 Signed-off-by: Adam Thomson adam.thomson.opensou...@diasemi.com
 ---

Hi Sebastian,

Just wondered when you might be able to review the power-supply parts of this
patch? Lee has Acked the MFD patches, so it's just these left.

Thanks
Adam
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH v4 13/13] usb: otg: Add dual-role device (DRD) support

2015-08-24 Thread Roger Quadros
DRD mode is a reduced functionality OTG mode. In this mode
we don't support SRP, HNP and dynamic role-swap.

In DRD operation, the controller mode (Host or Peripheral)
is decided based on the ID pin status. Once a cable plug (Type-A
or Type-B) is attached the controller selects the state
and doesn't change till the cable in unplugged and a different
cable type is inserted.

As we don't need most of the complex OTG states and OTG timers
we implement a lean DRD state machine in usb-otg.c.
The DRD state machine is only interested in 2 hardware inputs
'id' and 'b_sess_vld'.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/common/usb-otg.c | 178 +--
 include/linux/usb/otg-fsm.h  |   5 ++
 include/linux/usb/otg.h  |   2 +
 3 files changed, 177 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 930c2fe..44b5577 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -519,14 +519,165 @@ int usb_otg_start_gadget(struct otg_fsm *fsm, int on)
 }
 EXPORT_SYMBOL_GPL(usb_otg_start_gadget);
 
+/* Change USB protocol when there is a protocol change */
+static int drd_set_protocol(struct otg_fsm *fsm, int protocol)
+{
+   struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
+   int ret = 0;
+
+   if (fsm-protocol != protocol) {
+   dev_dbg(otgd-dev, otg: changing role fsm-protocol= %d; new 
protocol= %d\n,
+   fsm-protocol, protocol);
+   /* stop old protocol */
+   if (fsm-protocol == PROTO_HOST)
+   ret = otg_start_host(fsm, 0);
+   else if (fsm-protocol == PROTO_GADGET)
+   ret = otg_start_gadget(fsm, 0);
+   if (ret)
+   return ret;
+
+   /* start new protocol */
+   if (protocol == PROTO_HOST)
+   ret = otg_start_host(fsm, 1);
+   else if (protocol == PROTO_GADGET)
+   ret = otg_start_gadget(fsm, 1);
+   if (ret)
+   return ret;
+
+   fsm-protocol = protocol;
+   return 0;
+   }
+
+   return 0;
+}
+
+/* Called when entering a DRD state */
+static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
+{
+   struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
+
+   if (fsm-otg-state == new_state)
+   return;
+
+   fsm-state_changed = 1;
+   dev_dbg(otgd-dev, otg: set state: %s\n,
+   usb_otg_state_string(new_state));
+   switch (new_state) {
+   case OTG_STATE_B_IDLE:
+   drd_set_protocol(fsm, PROTO_UNDEF);
+   break;
+   case OTG_STATE_B_PERIPHERAL:
+   drd_set_protocol(fsm, PROTO_GADGET);
+   break;
+   case OTG_STATE_A_HOST:
+   drd_set_protocol(fsm, PROTO_HOST);
+   break;
+   case OTG_STATE_UNDEFINED:
+   case OTG_STATE_B_SRP_INIT:
+   case OTG_STATE_B_WAIT_ACON:
+   case OTG_STATE_B_HOST:
+   case OTG_STATE_A_IDLE:
+   case OTG_STATE_A_WAIT_VRISE:
+   case OTG_STATE_A_WAIT_BCON:
+   case OTG_STATE_A_SUSPEND:
+   case OTG_STATE_A_PERIPHERAL:
+   case OTG_STATE_A_WAIT_VFALL:
+   case OTG_STATE_A_VBUS_ERR:
+   default:
+   dev_warn(otgd-dev, %s: otg: invalid state: %s\n,
+__func__, usb_otg_state_string(new_state));
+   break;
+   }
+
+   fsm-otg-state = new_state;
+}
+
 /**
- * OTG FSM work function
+ * DRD state change judgement
+ *
+ * For DRD we're only interested in some of the OTG states
+ * i.e. OTG_STATE_B_IDLE: both peripheral and host are stopped
+ * OTG_STATE_B_PERIPHERAL: peripheral active
+ * OTG_STATE_A_HOST: host active
+ * we're only interested in the following inputs
+ * fsm-id, fsm-b_sess_vld
+ */
+static int drd_statemachine(struct otg_fsm *fsm)
+{
+   struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
+   enum usb_otg_state state;
+
+   mutex_lock(fsm-lock);
+
+   state = fsm-otg-state;
+
+   switch (state) {
+   case OTG_STATE_UNDEFINED:
+   if (!fsm-id)
+   drd_set_state(fsm, OTG_STATE_A_HOST);
+   else if (fsm-id  fsm-b_sess_vld)
+   drd_set_state(fsm, OTG_STATE_B_PERIPHERAL);
+   else
+   drd_set_state(fsm, OTG_STATE_B_IDLE);
+   break;
+   case OTG_STATE_B_IDLE:
+   if (!fsm-id)
+   drd_set_state(fsm, OTG_STATE_A_HOST);
+   else if (fsm-b_sess_vld)
+   drd_set_state(fsm, OTG_STATE_B_PERIPHERAL);
+   break;
+   case OTG_STATE_B_PERIPHERAL:
+   if (!fsm-id)
+   drd_set_state(fsm, OTG_STATE_A_HOST);
+   else if (!fsm-b_sess_vld)
+ 

[PATCH v4 06/13] usb: gadget.h: Add OTG to gadget interface

2015-08-24 Thread Roger Quadros
The OTG core will use struct otg_gadget_ops to
start/stop the gadget controller.

The main purpose of this interface is to avoid directly
calling usb_gadget_start/stop() from the OTG core as they
wouldn't be defined in the built-in symbol table if
CONFIG_USB_GADGET is m.

Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Peter Chen peter.c...@freescale.com
---
 include/linux/usb/gadget.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index c14a69b..c019242 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1052,6 +1052,20 @@ struct usb_gadget_driver {
 };
 
 
+/*-*/
+
+/**
+ * struct otg_gadget_ops - Interface between OTG core and gadget
+ *
+ * Provided by the gadget core to allow the OTG core to start/stop the gadget
+ *
+ * @start: function to start the gadget
+ * @stop: function to stop the gadget
+ */
+struct otg_gadget_ops {
+   int (*start)(struct usb_gadget *gadget);
+   int (*stop)(struct usb_gadget *gadget);
+};
 
 /*-*/
 
-- 
2.1.4

--
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] clockevents/drivers/mtk: Fix spurious interrupt leading to crash

2015-08-24 Thread Daniel Lezcano
After analysis done by Yingjoe Chen, the timer appears to have a pending
interrupt when it is enabled.

Fix this by acknowledging the pending interrupt when enabling the timer
interrupt.

Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
 drivers/clocksource/mtk_timer.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 4cd16fb..13543a8 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -156,14 +156,6 @@ static irqreturn_t mtk_timer_interrupt(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
-static void mtk_timer_global_reset(struct mtk_clock_event_device *evt)
-{
-   /* Disable all interrupts */
-   writel(0x0, evt-gpt_base + GPT_IRQ_EN_REG);
-   /* Acknowledge all interrupts */
-   writel(0x3f, evt-gpt_base + GPT_IRQ_ACK_REG);
-}
-
 static void
 mtk_timer_setup(struct mtk_clock_event_device *evt, u8 timer, u8 option)
 {
@@ -183,6 +175,9 @@ static void mtk_timer_enable_irq(struct 
mtk_clock_event_device *evt, u8 timer)
 {
u32 val;
 
+/* Acknowledge all spurious pending interrupts */
+writel(0x3f, evt-gpt_base + GPT_IRQ_ACK_REG);
+
val = readl(evt-gpt_base + GPT_IRQ_EN_REG);
writel(val | GPT_IRQ_ENABLE(timer),
evt-gpt_base + GPT_IRQ_EN_REG);
@@ -232,8 +227,6 @@ static void __init mtk_timer_init(struct device_node *node)
}
rate = clk_get_rate(clk);
 
-   mtk_timer_global_reset(evt);
-
if (request_irq(evt-dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, mtk_timer, evt)) {
pr_warn(failed to setup irq %d\n, evt-dev.irq);
-- 
1.9.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 v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-24 Thread Vlastimil Babka

On 08/24/2015 12:17 PM, Konstantin Khlebnikov wrote:


I am in the middle of implementing lock on fault this way, but I cannot
see how we will hanlde mremap of a lock on fault region.  Say we have
the following:

 addr = mmap(len, MAP_ANONYMOUS, ...);
 mlock(addr, len, MLOCK_ONFAULT);
 ...
 mremap(addr, len, 2 * len, ...)

There is no way for mremap to know that the area being remapped was lock
on fault so it will be locked and prefaulted by remap.  How can we avoid
this without tracking per vma if it was locked with lock or lock on
fault?


remap can count filled ptes and prefault only completely populated areas.


Does (and should) mremap really prefault non-present pages? Shouldn't it 
just prepare the page tables and that's it?



There might be a problem after failed populate: remap will handle them
as lock on fault. In this case we can fill ptes with swap-like non-present
entries to remember that fact and count them as should-be-locked pages.


I don't think we should strive to have mremap try to fix the inherent 
unreliability of mmap (MAP_POPULATE)?

--
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] fbdev/riva:change to use generice function to implement reverse_order()

2015-08-24 Thread Afzal Mohammed
Hi,

On Mon, Aug 24, 2015 at 04:31:13PM +0800, yalin wang wrote:
 
 i only submit the bit reverse patch for arm / arm64 arch,

yes, saw later git blaming it on you :)

  Not for this case, but once measured on ARM, iirc, a 32-bit asm bit
  reversal as compared to doing it in C was taking 1 cycle as opposed to
  ~225 cycles!, of course writing optimized C could have made it fare
  better, but still would reach no-way near asm bit reversal.

The above measurement was done not in Linux, rather on a baremetal
code, but seeing the efficient Kernel C implementation, realized that
the gain would not be that much, it would be good to know if there are
measurements for Kernel bitreversal in C  asm (on supported arch)

Regards
afzal
--
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] DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd

2015-08-24 Thread Jerome Glisse
On Fri, Aug 21, 2015 at 02:16:12PM -0400, cp...@redhat.com wrote:
 From: Stephen Chandler Paul cp...@redhat.com
 
 Most of the time this isn't an issue since hotplugging an adaptor will
 trigger a crtc mode change which in turn, causes the driver to probe
 every DisplayPort for a dpcd. However, in cases where hotplugging
 doesn't cause a mode change (specifically when one unplugs a monitor
 from a DisplayPort connector, then plugs that same monitor back in
 seconds later on the same port without any other monitors connected), we
 never probe for the dpcd before starting the initial link training. What
 happens from there looks like this:
 
   - GPU has only one monitor connected. It's connected via
 DisplayPort, and does not go through an adaptor of any sort.
 
   - User unplugs DisplayPort connector from GPU.
 
   - Change in HPD is detected by the driver, we probe every
 DisplayPort for a possible connection.
 
   - Probe the port the user originally had the monitor connected
 on for it's dpcd. This fails, and we clear the first (and only
 the first) byte of the dpcd to indicate we no longer have a
 dpcd for this port.
 
   - User plugs the previously disconnected monitor back into the
 same DisplayPort.
 
   - radeon_connector_hotplug() is called before everyone else,
 and tries to handle the link training. Since only the first
 byte of the dpcd is zeroed, the driver is able to complete
 link training but does so against the wrong dpcd, causing it
 to initialize the link with the wrong settings.
 
   - Display stays blank (usually), dpcd is probed after the
 initial link training, and the driver prints no obvious
 messages to the log.
 
 In theory, since only one byte of the dpcd is chopped off (specifically,
 the byte that contains the revision information for DisplayPort), it's
 not entirely impossible that this bug may not show on certain monitors.
 For instance, the only reason this bug was visible on my ASUS PB238
 monitor was due to the fact that this monitor using the enhanced framing
 symbol sequence, the flag for which is ignored if the radeon driver
 thinks that the DisplayPort version is below 1.1.
 
 Signed-off-by: Stephen Chandler Paul cp...@redhat.com
 Reviewed-by: Jerome Glisse jgli...@redhat.com

This should be added to stable

cc: sta...@vger.kernel.org



 ---
  drivers/gpu/drm/radeon/radeon_connectors.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
 b/drivers/gpu/drm/radeon/radeon_connectors.c
 index 94b21ae..5a2cafb 100644
 --- a/drivers/gpu/drm/radeon/radeon_connectors.c
 +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
 @@ -95,6 +95,11 @@ void radeon_connector_hotplug(struct drm_connector 
 *connector)
   if (!radeon_hpd_sense(rdev, radeon_connector-hpd.hpd)) 
 {
   drm_helper_connector_dpms(connector, 
 DRM_MODE_DPMS_OFF);
   } else if 
 (radeon_dp_needs_link_train(radeon_connector)) {
 + /* Don't try to start link training before we
 +  * have the dpcd */
 + if (!radeon_dp_getdpcd(radeon_connector))
 + return;
 +
   /* set it to OFF so that 
 drm_helper_connector_dpms()
* won't return immediately since the current 
 state
* is ON at this point.
 -- 
 2.4.3
--
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/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation

2015-08-24 Thread Lars-Peter Clausen
On 08/06/2015 05:19 AM, Punnaiah Choudary Kalluri wrote:
[...]
 +Optional properties:
 +- xlnx,include-sg: Indicates the controller to operate in simple or scatter
 +gather dma mode
 +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
 +  source AXI transaction
 +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
 +- xlnx,src-issue: Number of AXI outstanding transactions on source side
 +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
 + descriptor read are marked Non-coherent
 +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
 + source descriptor payload are marked Non-coherent
 +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
 + dst descriptor payload are marked Non-coherent
 +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
 +- xlnx,src-axi-qos: AXI QOS bits to be used for data read
 +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
 +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
 +- xlnx,desc-axi-cache: AXI cache bits to be used for data read
 +- xlnx,desc-axi-cache: AXI cache bits to be used for data write
 +- xlnx,src-burst-len: AXI length for data read. Support only power of 2 
 values
 +   i.e 1,2,4,8 and 16
 +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 
 values
 +   i.e 1,2,4,8 and 16

None of these really belong into the devicetree. This is all runtime
configuration data.

- Lars
--
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 10/12] mm, page_alloc: Remove MIGRATE_RESERVE

2015-08-24 Thread Mel Gorman
MIGRATE_RESERVE preserves an old property of the buddy allocator that existed
prior to fragmentation avoidance -- min_free_kbytes worth of pages tended to
remain contiguous until the only alternative was to fail the allocation. At the
time it was discovered that high-order atomic allocations relied on this
property so MIGRATE_RESERVE was introduced. A later patch will introduce
an alternative MIGRATE_HIGHATOMIC so this patch deletes MIGRATE_RESERVE
and supporting code so it'll be easier to review. Note that this patch
in isolation may look like a false regression if someone was bisecting
high-order atomic allocation failures.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
Acked-by: Vlastimil Babka vba...@suse.cz
---
 include/linux/mmzone.h |  10 +---
 mm/huge_memory.c   |   2 +-
 mm/page_alloc.c| 148 +++--
 mm/vmstat.c|   1 -
 4 files changed, 11 insertions(+), 150 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index aef62cc11c80..cf643539d640 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -39,8 +39,6 @@ enum {
MIGRATE_UNMOVABLE,
MIGRATE_MOVABLE,
MIGRATE_RECLAIMABLE,
-   MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
-   MIGRATE_RESERVE = MIGRATE_PCPTYPES,
 #ifdef CONFIG_CMA
/*
 * MIGRATE_CMA migration type is designed to mimic the way
@@ -63,6 +61,8 @@ enum {
MIGRATE_TYPES
 };
 
+#define MIGRATE_PCPTYPES (MIGRATE_RECLAIMABLE+1)
+
 #ifdef CONFIG_CMA
 #  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
 #else
@@ -425,12 +425,6 @@ struct zone {
 
const char  *name;
 
-   /*
-* Number of MIGRATE_RESERVE page block. To maintain for just
-* optimization. Protected by zone-lock.
-*/
-   int nr_migrate_reserve_block;
-
 #ifdef CONFIG_MEMORY_ISOLATION
/*
 * Number of isolated pageblock. It is used to solve incorrect
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 36efda9ff8f1..56cfb17169d2 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -113,7 +113,7 @@ static int set_recommended_min_free_kbytes(void)
for_each_populated_zone(zone)
nr_zones++;
 
-   /* Make sure at least 2 hugepages are free for MIGRATE_RESERVE */
+   /* Ensure 2 pageblocks are free to assist fragmentation avoidance */
recommended_min = pageblock_nr_pages * nr_zones * 2;
 
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index aa52a91a7d44..d5ce050ebe4f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -792,7 +792,6 @@ static void free_pcppages_bulk(struct zone *zone, int count,
if (unlikely(has_isolate_pageblock(zone)))
mt = get_pageblock_migratetype(page);
 
-   /* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
__free_one_page(page, page_to_pfn(page), zone, 0, mt);
trace_mm_page_pcpu_drain(page, 0, mt);
} while (--to_free  --batch_free  !list_empty(list));
@@ -1390,15 +1389,14 @@ struct page *__rmqueue_smallest(struct zone *zone, 
unsigned int order,
  * the free lists for the desirable migrate type are depleted
  */
 static int fallbacks[MIGRATE_TYPES][4] = {
-   [MIGRATE_UNMOVABLE]   = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, 
MIGRATE_RESERVE },
-   [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE, 
MIGRATE_RESERVE },
-   [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,   
MIGRATE_RESERVE },
+   [MIGRATE_UNMOVABLE]   = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,   
MIGRATE_TYPES },
+   [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE,   
MIGRATE_TYPES },
+   [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, 
MIGRATE_TYPES },
 #ifdef CONFIG_CMA
-   [MIGRATE_CMA] = { MIGRATE_RESERVE }, /* Never used */
+   [MIGRATE_CMA] = { MIGRATE_TYPES }, /* Never used */
 #endif
-   [MIGRATE_RESERVE] = { MIGRATE_RESERVE }, /* Never used */
 #ifdef CONFIG_MEMORY_ISOLATION
-   [MIGRATE_ISOLATE] = { MIGRATE_RESERVE }, /* Never used */
+   [MIGRATE_ISOLATE] = { MIGRATE_TYPES }, /* Never used */
 #endif
 };
 
@@ -1572,7 +1570,7 @@ int find_suitable_fallback(struct free_area *area, 
unsigned int order,
*can_steal = false;
for (i = 0;; i++) {
fallback_mt = fallbacks[migratetype][i];
-   if (fallback_mt == MIGRATE_RESERVE)
+   if (fallback_mt == MIGRATE_TYPES)
break;
 
if (list_empty(area-free_list[fallback_mt]))
@@ -1651,25 +1649,13 @@ static struct page *__rmqueue(struct zone *zone, 
unsigned int order,
 {
struct page *page;
 
-retry_reserve:
page = __rmqueue_smallest(zone, order, migratetype);
-
-   

Re: [PATCH] irqchip, gicv3-its, numa: Workaround for Cavium ThunderX erratum 23144

2015-08-24 Thread Ganapatrao Kulkarni
Hi Marc,

thanks for the review comments.

On Mon, Aug 24, 2015 at 3:47 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 Hi Robert,

 Just came back from the Seattle madness, so picking up patches in
 reverse order... ;-)

 On 22/08/15 14:10, Robert Richter wrote:
 The patch below adds a workaround for gicv3 in a numa environment. It
 is on top of my recent gicv3 errata patch submission v4 and Ganapat's
 arm64 numa patches for devicetree v5.

 Please comment.

 Thanks,

 -Robert



 From c432820451a46b8d1e299b8bfbfcdcb3b75340e7 Mon Sep 17 00:00:00 2001
 From: Ganapatrao Kulkarni gkulka...@caviumnetworks.com
 Date: Wed, 19 Aug 2015 23:40:05 +0530
 Subject: [PATCH] irqchip, gicv3-its, numa: Workaround for Cavium ThunderX 
 erratum
  23144

 This implements a workaround for gicv3-its erratum 23144 applicable
 for Cavium's ThunderX multinode systems.

 The erratum fixes the hang of ITS SYNC command by avoiding inter node
 io and collections/cpu mapping. This fix is only applicable for
 Cavium's ThunderX dual-socket platforms.

 Can you please elaborate on this? I can't see any reference to the SYNC
 command there. Is that a case of an ITS not being able to route LPIs to
 cores on another socket?
we were seeing mapc command failing when we were mapping its of node0
with collections of node1(vice-versa).
we found sync was timing out, which is issued post mapc(also for mapvi
and movi).
Yes this errata limits the routing of inter-node LPIs.


 I really need more details to understand this patch (please use short
 sentences, I'm still in a different time zone).


 Signed-off-by: Ganapatrao Kulkarni gkulka...@caviumnetworks.com
 [ rric: Reworked errata code, added helper functions, updated commit
   message. ]

 Signed-off-by: Robert Richter rrich...@cavium.com
 ---
  arch/arm64/Kconfig   | 14 +++
  drivers/irqchip/irq-gic-common.c |  5 ++--
  drivers/irqchip/irq-gic-v3-its.c | 54 
 ++--
  3 files changed, 64 insertions(+), 9 deletions(-)

 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
 index 3809187ed653..b92b7b70b29b 100644
 --- a/arch/arm64/Kconfig
 +++ b/arch/arm64/Kconfig
 @@ -421,6 +421,20 @@ config ARM64_ERRATUM_845719

 If unsure, say Y.

 +config CAVIUM_ERRATUM_22375
 + bool Cavium erratum 22375, 24313
 + depends on NUMA
 + default y
 + help
 + Enable workaround for erratum 22375, 24313.
 +
 +config CAVIUM_ERRATUM_23144
 + bool Cavium erratum 23144
 + depends on NUMA
 + default y
 + help
 + Enable workaround for erratum 23144.
 +
  config CAVIUM_ERRATUM_23154
   bool Cavium erratum 23154: Access to ICC_IAR1_EL1 is not sync'ed
   depends on ARCH_THUNDER
 diff --git a/drivers/irqchip/irq-gic-common.c 
 b/drivers/irqchip/irq-gic-common.c
 index ee789b07f2d1..1dfce64dbdac 100644
 --- a/drivers/irqchip/irq-gic-common.c
 +++ b/drivers/irqchip/irq-gic-common.c
 @@ -24,11 +24,12 @@
  void gic_check_capabilities(u32 iidr, const struct gic_capabilities *cap,
   void *data)
  {
 - for (; cap-desc; cap++) {
 + for (; cap-init; cap++) {
   if (cap-iidr != (cap-mask  iidr))
   continue;
   cap-init(data);
 - pr_info(%s\n, cap-desc);
 + if (cap-desc)
 + pr_info(%s\n, cap-desc);

 No. I really want to see what errata are applied when I look at a kernel
 log.
sorry, did not understood your comment, it is still printed using cap-desc.

   }
  }

 diff --git a/drivers/irqchip/irq-gic-v3-its.c 
 b/drivers/irqchip/irq-gic-v3-its.c
 index 4bb135721e72..666be39f13a9 100644
 --- a/drivers/irqchip/irq-gic-v3-its.c
 +++ b/drivers/irqchip/irq-gic-v3-its.c
 @@ -43,7 +43,8 @@
  #include irqchip.h

  #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL  0)
 -#define ITS_FLAGS_CAVIUM_THUNDERX(1ULL  1)
 +#define ITS_WORKAROUND_CAVIUM_22375  (1ULL  1)
 +#define ITS_WORKAROUND_CAVIUM_23144  (1ULL  2)

  #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING  (1  0)

 @@ -76,6 +77,7 @@ struct its_node {
   struct list_headits_device_list;
   u64 flags;
   u32 ite_size;
 + int numa_node;
  };

  #define ITS_ITT_ALIGNSZ_256
 @@ -609,11 +611,18 @@ static void its_eoi_irq(struct irq_data *d)
  static int its_set_affinity(struct irq_data *d, const struct cpumask 
 *mask_val,
   bool force)
  {
 - unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
 + unsigned int cpu;
   struct its_device *its_dev = irq_data_get_irq_chip_data(d);
   struct its_collection *target_col;
   u32 id = its_get_event_id(d);

 + if (its_dev-its-flags  ITS_WORKAROUND_CAVIUM_23144) {
 + cpu = cpumask_any_and(mask_val,
 + cpumask_of_node(its_dev-its-numa_node));

 I suppose cpumask_of_node returns only 

[PATCH 11/12] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand

2015-08-24 Thread Mel Gorman
High-order watermark checking exists for two reasons --  kswapd high-order
awareness and protection for high-order atomic requests. Historically the
kernel depended on MIGRATE_RESERVE to preserve min_free_kbytes as high-order
free pages for as long as possible. This patch introduces MIGRATE_HIGHATOMIC
that reserves pageblocks for high-order atomic allocations on demand and
avoids using those blocks for order-0 allocations. This is more flexible
and reliable than MIGRATE_RESERVE was.

A MIGRATE_HIGHORDER pageblock is created when a high-order allocation
request steals a pageblock but limits the total number to 1% of the zone.
Callers that speculatively abuse atomic allocations for long-lived
high-order allocations to access the reserve will quickly fail. Note that
SLUB is currently not such an abuser as it reclaims at least once.  It is
possible that the pageblock stolen has few suitable high-order pages and
will need to steal again in the near future but there would need to be
strong justification to search all pageblocks for an ideal candidate.

The pageblocks are unreserved if an allocation fails after a direct
reclaim attempt.

The watermark checks account for the reserved pageblocks when the allocation
request is not a high-order atomic allocation.

The reserved pageblocks can not be used for order-0 allocations. This may
allow temporary wastage until a failed reclaim reassigns the pageblock. This
is deliberate as the intent of the reservation is to satisfy a limited
number of atomic high-order short-lived requests if the system requires them.

The stutter benchmark was used to evaluate this but while it was running
there was a systemtap script that randomly allocated between 1 high-order
page and 12.5% of memory's worth of order-3 pages using GFP_ATOMIC. This
is much larger than the potential reserve and it does not attempt to be
realistic.  It is intended to stress random high-order allocations from
an unknown source, show that there is a reduction in failures without
introducing an anomaly where atomic allocations are more reliable than
regular allocations.  The amount of memory reserved varied throughout the
workload as reserves were created and reclaimed under memory pressure. The
allocation failures once the workload warmed up were as follows;

4.2-rc5-vanilla 70%
4.2-rc5-atomic-reserve  56%

The failure rate was also measured while building multiple kernels. The
failure rate was 14% but is 6% with this patch applied.

Overall, this is a small reduction but the reserves are small relative to the
number of allocation requests. In early versions of the patch, the failure
rate reduced by a much larger amount but that required much larger reserves
and perversely made atomic allocations seem more reliable than regular 
allocations.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
---
 include/linux/mmzone.h |   6 ++-
 mm/page_alloc.c| 117 ++---
 mm/vmstat.c|   1 +
 3 files changed, 116 insertions(+), 8 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index cf643539d640..a9805a85940a 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -39,6 +39,8 @@ enum {
MIGRATE_UNMOVABLE,
MIGRATE_MOVABLE,
MIGRATE_RECLAIMABLE,
+   MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
+   MIGRATE_HIGHATOMIC = MIGRATE_PCPTYPES,
 #ifdef CONFIG_CMA
/*
 * MIGRATE_CMA migration type is designed to mimic the way
@@ -61,8 +63,6 @@ enum {
MIGRATE_TYPES
 };
 
-#define MIGRATE_PCPTYPES (MIGRATE_RECLAIMABLE+1)
-
 #ifdef CONFIG_CMA
 #  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
 #else
@@ -330,6 +330,8 @@ struct zone {
/* zone watermarks, access with *_wmark_pages(zone) macros */
unsigned long watermark[NR_WMARK];
 
+   unsigned long nr_reserved_highatomic;
+
/*
 * We don't know if the memory that we're going to allocate will be 
freeable
 * or/and it will be released eventually, so to avoid totally wasting 
several
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d5ce050ebe4f..2415f882b89c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1589,6 +1589,86 @@ int find_suitable_fallback(struct free_area *area, 
unsigned int order,
return -1;
 }
 
+/*
+ * Reserve a pageblock for exclusive use of high-order atomic allocations if
+ * there are no empty page blocks that contain a page with a suitable order
+ */
+static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
+   unsigned int alloc_order)
+{
+   int mt = get_pageblock_migratetype(page);
+   unsigned long max_managed, flags;
+
+   if (mt == MIGRATE_HIGHATOMIC)
+   return;
+
+   /*
+* Limit the number reserved to 1 pageblock or roughly 1% of a zone.
+* Check is race-prone but harmless.
+*/
+   

[PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations

2015-08-24 Thread Mel Gorman
The primary purpose of watermarks is to ensure that reclaim can always
make forward progress in PF_MEMALLOC context (kswapd and direct reclaim).
These assume that order-0 allocations are all that is necessary for
forward progress.

High-order watermarks serve a different purpose. Kswapd had no high-order
awareness before they were introduced (https://lkml.org/lkml/2004/9/5/9).
This was particularly important when there were high-order atomic requests.
The watermarks both gave kswapd awareness and made a reserve for those
atomic requests.

There are two important side-effects of this. The most important is that
a non-atomic high-order request can fail even though free pages are available
and the order-0 watermarks are ok. The second is that high-order watermark
checks are expensive as the free list counts up to the requested order must
be examined.

With the introduction of MIGRATE_HIGHATOMIC it is no longer necessary to
have high-order watermarks. Kswapd and compaction still need high-order
awareness which is handled by checking that at least one suitable high-order
page is free.

With the patch applied, there was little difference in the allocation
failure rates as the atomic reserves are small relative to the number of
allocation attempts. The expected impact is that there will never be an
allocation failure report that shows suitable pages on the free lists.

The one potential side-effect of this is that in a vanilla kernel, the
watermark checks may have kept a free page for an atomic allocation. Now,
we are 100% relying on the HighAtomic reserves and an early allocation to
have allocated them.  If the first high-order atomic allocation is after
the system is already heavily fragmented then it'll fail.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
---
 mm/page_alloc.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2415f882b89c..35dc578730d1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2280,8 +2280,10 @@ static inline bool should_fail_alloc_page(gfp_t 
gfp_mask, unsigned int order)
 #endif /* CONFIG_FAIL_PAGE_ALLOC */
 
 /*
- * Return true if free pages are above 'mark'. This takes into account the 
order
- * of the allocation.
+ * Return true if free base pages are above 'mark'. For high-order checks it
+ * will return true of the order-0 watermark is reached and there is at least
+ * one free page of a suitable size. Checking now avoids taking the zone lock
+ * to check in the allocation paths if no pages are free.
  */
 static bool __zone_watermark_ok(struct zone *z, unsigned int order,
unsigned long mark, int classzone_idx, int alloc_flags,
@@ -2289,7 +2291,7 @@ static bool __zone_watermark_ok(struct zone *z, unsigned 
int order,
 {
long min = mark;
int o;
-   long free_cma = 0;
+   const bool atomic = (alloc_flags  ALLOC_HARDER);
 
/* free_pages may go negative - that's OK */
free_pages -= (1  order) - 1;
@@ -2301,7 +2303,7 @@ static bool __zone_watermark_ok(struct zone *z, unsigned 
int order,
 * If the caller is not atomic then discount the reserves. This will
 * over-estimate how the atomic reserve but it avoids a search
 */
-   if (likely(!(alloc_flags  ALLOC_HARDER)))
+   if (likely(!atomic))
free_pages -= z-nr_reserved_highatomic;
else
min -= min / 4;
@@ -2309,22 +2311,30 @@ static bool __zone_watermark_ok(struct zone *z, 
unsigned int order,
 #ifdef CONFIG_CMA
/* If allocation can't use CMA areas don't use free CMA pages */
if (!(alloc_flags  ALLOC_CMA))
-   free_cma = zone_page_state(z, NR_FREE_CMA_PAGES);
+   free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);
 #endif
 
-   if (free_pages - free_cma = min + z-lowmem_reserve[classzone_idx])
+   if (free_pages = min + z-lowmem_reserve[classzone_idx])
return false;
-   for (o = 0; o  order; o++) {
-   /* At the next order, this order's pages become unavailable */
-   free_pages -= z-free_area[o].nr_free  o;
 
-   /* Require fewer higher order pages to be free */
-   min = 1;
+   /* order-0 watermarks are ok */
+   if (!order)
+   return true;
+
+   /* Check at least one high-order page is free */
+   for (o = order; o  MAX_ORDER; o++) {
+   struct free_area *area = z-free_area[o];
+   int mt;
+
+   if (atomic  area-nr_free)
+   return true;
 
-   if (free_pages = min)
-   return false;
+   for (mt = 0; mt  MIGRATE_PCPTYPES; mt++) {
+   if (!list_empty(area-free_list[mt]))
+   return true;
+   }
}
-   return true;
+   return false;
 }
 
 bool zone_watermark_ok(struct zone *z, 

[char-misc 2/2] mei: fix debugfs files leak on error path

2015-08-24 Thread Tomas Winkler
if dbgfs_dir is not set then debugfs_remove_recursive
is not called on the error path

Signed-off-by: Tomas Winkler tomas.wink...@intel.com
---
 drivers/misc/mei/debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index c157f0ba575c..a138d8a27ab5 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -204,6 +204,8 @@ int mei_dbgfs_register(struct mei_device *dev, const char 
*name)
if (!dir)
return -ENOMEM;
 
+   dev-dbgfs_dir = dir;
+
f = debugfs_create_file(meclients, S_IRUSR, dir,
dev, mei_dbgfs_fops_meclients);
if (!f) {
@@ -228,7 +230,6 @@ int mei_dbgfs_register(struct mei_device *dev, const char 
*name)
dev_err(dev-dev, allow_fixed_address: registration failed\n);
goto err;
}
-   dev-dbgfs_dir = dir;
return 0;
 err:
mei_dbgfs_deregister(dev);
-- 
2.4.3

--
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 1/2] mfd: devicetree: bindings: 88pm800: Add DT property for dual phase enable

2015-08-24 Thread Vaibhav Hiremath
88PM860 family of device supports dual phase mode on BUCK1 supply
providing total 6A capacity.
Note that by default they operate independently with 3A capacity.

This patch updates the devicetree binding with DT property
to enable dual-phase mode on BUCK1.

Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
 Documentation/devicetree/bindings/mfd/88pm800.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt 
b/Documentation/devicetree/bindings/mfd/88pm800.txt
index dec842f..2c82fcb 100644
--- a/Documentation/devicetree/bindings/mfd/88pm800.txt
+++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
@@ -9,6 +9,12 @@ Required parent device properties:
 - #interrupt-cells : should be 1.
  The cell is the 88pm80x local IRQ number
 
+Optional properties :
+- marvell,88pm860-buck1-dualphase-en  : If set, enable dual phase on BUCK1,
+  providing 6A capacity.
+  Without this both BUCK1A and BUCK1B operates independently with 3A capacity.
+  (This property is only applicable to 88PM860)
+
 88pm80x family of devices consists of varied group of sub-devices:
 
 Device Supply Names Description
-- 
1.9.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 v2] mm: use only per-device readahead limit

2015-08-24 Thread Konstantin Khlebnikov

On 24.08.2015 14:57, Roman Gushchin wrote:

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.


After second thought: this isn't important. V1 is fine.

page_cache_sync_readahead checks if (!ra-ra_pages) before and
never calls force_page_cache_readahead if readahead is disabled.

Anyway, this function doesn't return references to pages. All
users must be ready to handle non-present or non-uptodate pages.
But this probably never happened before so all callsites should
be reviewed: for example splice always re-lookups pages after
-readpage() (I guess page can be truncated here) while some
other users use the same page reference.



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

[PATCH 06/10] ALSA: axd: add basic files for sending/receiving axd cmds

2015-08-24 Thread Qais Yousef
These files do the important part of talking with AXD to send and
receive data buffers.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/img/axd/axd_cmds.c   |  102 +++
 sound/soc/img/axd/axd_cmds.h   |  532 ++
 sound/soc/img/axd/axd_cmds_pipes.c | 1387 
 3 files changed, 2021 insertions(+)
 create mode 100644 sound/soc/img/axd/axd_cmds.c
 create mode 100644 sound/soc/img/axd/axd_cmds.h
 create mode 100644 sound/soc/img/axd/axd_cmds_pipes.c

diff --git a/sound/soc/img/axd/axd_cmds.c b/sound/soc/img/axd/axd_cmds.c
new file mode 100644
index ..eb160f46489b
--- /dev/null
+++ b/sound/soc/img/axd/axd_cmds.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * AXD Commands API - generic setup functions.
+ */
+#include axd_api.h
+#include axd_cmds.h
+#include axd_cmds_internal.h
+#include axd_module.h
+
+static unsigned long __io_address;
+static unsigned long __phys_address;
+
+void axd_cmd_init(struct axd_cmd *cmd, unsigned long cmd_address,
+   unsigned long io_address, unsigned long phys_address)
+{
+   int i;
+
+   cmd-message = (struct axd_memory_map __iomem *)cmd_address;
+   mutex_init(cmd-cm_lock);
+   init_waitqueue_head(cmd-wait);
+   axd_set_flag(cmd-response_flg, 0);
+   axd_set_flag(cmd-fw_stopped_flg, 0);
+   for (i = 0; i  AXD_MAX_PIPES; i++) {
+   axd_cmd_inpipe_init(cmd, i);
+   axd_cmd_outpipe_init(cmd, i);
+   }
+   __io_address = io_address;
+   __phys_address = phys_address;
+   cmd-watchdogenabled = 1;
+   /*
+* By default, always discard any pending buffers if an output device is
+* closed before EOS is reached.
+* This behaviour can be changed through kcontrol. If discard is 
disabled,
+* then upon closing an output device before EOS is reached, it'll
+* resume from where it stopped.
+*/
+   axd_set_flag(cmd-discard_flg, 1);
+   axd_set_flag(cmd-ctrlbuf_active_flg, 0);
+}
+
+int axd_cmd_set_pc(struct axd_cmd *cmd, unsigned int thread, unsigned long pc)
+{
+   if (thread = THREAD_COUNT)
+   return -1;
+   iowrite32(pc, cmd-message-pc[thread]);
+   return 0;
+}
+
+unsigned long  axd_cmd_get_datain_address(struct axd_cmd *cmd)
+{
+   struct axd_dev *axd = container_of(cmd, struct axd_dev, cmd);
+
+   return (unsigned long) axd-buf_base_m;
+}
+
+unsigned long  axd_cmd_get_datain_size(struct axd_cmd *cmd)
+{
+   struct axd_dev *axd = container_of(cmd, struct axd_dev, cmd);
+
+   return axd-inbuf_size;
+}
+
+unsigned long  axd_cmd_get_dataout_address(struct axd_cmd *cmd)
+{
+   struct axd_dev *axd = container_of(cmd, struct axd_dev, cmd);
+
+   return ((unsigned long) axd-buf_base_m) + axd-inbuf_size;
+}
+
+unsigned long  axd_cmd_get_dataout_size(struct axd_cmd *cmd)
+{
+   struct axd_dev *axd = container_of(cmd, struct axd_dev, cmd);
+
+   return axd-outbuf_size;
+}
+
+/*
+ * The driver understands IO address, while f/w understands physical addresses.
+ * A couple of helper functions to aid in converting when exchanging buffers.
+ *
+ * NOTE:
+ * buf must NOT be NULL - we want this as fast as possible, so omit the check
+ * for NULLl
+ */
+inline char *axd_io_2_phys(const char *buf)
+{
+   return (char *)(buf - __io_address + __phys_address);
+}
+inline char *axd_phys_2_io(const char *buf)
+{
+   return (char *)(buf - __phys_address + __io_address);
+}
diff --git a/sound/soc/img/axd/axd_cmds.h b/sound/soc/img/axd/axd_cmds.h
new file mode 100644
index ..d8f3db29eea3
--- /dev/null
+++ b/sound/soc/img/axd/axd_cmds.h
@@ -0,0 +1,532 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * AXD API commands Helper functions.
+ */
+#ifndef AXD_CMDS_H_
+#define AXD_CMDS_H_
+
+#include 

[PATCH-v3 0/2] regulator: 88pm800: Add dual phase mode support on BUCK1

2015-08-24 Thread Vaibhav Hiremath
88PM860 device supports dual phase mode on BUCK1 output.
In normal usecase, BUCK1A and BUCK1B operates independently with 3A
capacity. And they both can work as a dual phase providing 6A capacity.

This patch series is subset of earlier patch-series
Link to earlier series - https://lkml.org/lkml/2015/7/16/722

Except PATCH[5/5], all other patches in the series are accepted and
queued up for next merge window.
And based on discussion on the list, creating DT property to enable
dual-phase mode on BUCK1.

Testing:
 - Tested on 88PM860 based platform
 - Boot tested 
 - Tested with  without DT property being set
 - Read register value before and after probe to make sure that
   value has been set.

V2 = V3:

 - Based on discussion on earlier patch-series,
   (comments from Krzysztof Kozlowski)
   Dynamically controlled current capacity and registration of BUCK1B,
   in case of BUCK1 dual phase mode enabled.
   Now, if BUCK1 dual phase is enabled, current capacity is set to 6A,
   and, BUCK1B will not be registered to regulator framework.

V1 = V2:

 - This is new patch-series, where, all accepted patches dropped.
   Upgraded Patch version, to ease review.
 - Based on Mark Brown's comment, we should use DT property of its own.
   using set_current_limit() is not right way here.
   So, created DT property for Dual phase mode enable.
 - Updated binding for new DT property


Vaibhav Hiremath (2):
  mfd: devicetree: bindings: 88pm800: Add DT property for dual phase
enable
  regulator: 88pm800: Add support for configuration of dual phase on
BUCK1

 Documentation/devicetree/bindings/mfd/88pm800.txt |  6 
 drivers/regulator/88pm800.c   | 40 +++
 include/linux/mfd/88pm80x.h   |  3 ++
 3 files changed, 49 insertions(+)

-- 
1.9.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/


[PATCH-v3 2/2] regulator: 88pm800: Add support for configuration of dual phase on BUCK1

2015-08-24 Thread Vaibhav Hiremath
88PM860 device supports dual phase mode on BUCK1 output.
In normal usecase, BUCK1A and BUCK1B operates independently with 3A
capacity. And they both can work as a dual phase providing 6A capacity.

This patch updates the regulator driver to read the respective
DT property and enable dual-phase mode on BUCK1.
Note that if dual phase mode is enabled, then BUCK1B will not be
registered to the regulator framework and the current capacity of
BUCK1(A) would be set to 6A [3A of BUCK1A + 3A of BUCK1B].

Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
 drivers/regulator/88pm800.c | 40 
 include/linux/mfd/88pm80x.h |  3 +++
 2 files changed, 43 insertions(+)

diff --git a/drivers/regulator/88pm800.c b/drivers/regulator/88pm800.c
index 365a154..7aca6d17 100644
--- a/drivers/regulator/88pm800.c
+++ b/drivers/regulator/88pm800.c
@@ -267,6 +267,37 @@ static struct pm800_regulator_info pm860_regulator_info[] 
= {
PM800_LDO(ldo20, LDO20, LDO_ENA1_3, 3, 1, ldo_volt_table2),
 };
 
+static int pm800_regulator_init(struct platform_device *pdev,
+   struct pm800_regulator_info *info)
+{
+   struct pm800_regulators *pm800_data = platform_get_drvdata(pdev);
+   struct pm80x_chip *chip = pm800_data-chip;
+   int ret = 0;
+
+   /* Currently only supported on 88pm860 device */
+   if (chip-type != CHIP_PM860)
+   return 0;
+
+   if (of_property_read_bool(pdev-dev.of_node,
+   marvell,88pm860-buck1-dualphase-en)) {
+   /* Update the constraint  to [3A (BUCK1A) + 3A (BUCK1B)] */
+   info[PM800_ID_BUCK1].max_ua = 600;
+   /* Remove BUCK1B from the list, as we are in dual phase mode */
+   memset(info[PM800_ID_BUCK1B], 0, sizeof(*info));
+   /* Enable dual phase mode */
+   ret = regmap_update_bits(chip-subchip-regmap_power,
+   PM860_BUCK1_MISC,
+   BUCK1_DUAL_PHASE_SEL,
+   BUCK1_DUAL_PHASE_SEL);
+   if (ret) {
+   dev_err(chip-dev, failed to set dual-pase mode %d\n, 
ret);
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
 static int pm800_regulator_probe(struct platform_device *pdev)
 {
struct pm80x_chip *chip = dev_get_drvdata(pdev-dev.parent);
@@ -311,11 +342,20 @@ static int pm800_regulator_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
+   ret = pm800_regulator_init(pdev, info);
+   if (ret) {
+   dev_err(pdev-dev, failed to init 88pm800 regulator 
device\n);
+   return ret;
+   }
+
config.dev = chip-dev;
config.regmap = pm800_data-map;
for (i = 0; i  PM800_ID_RG_MAX; i++) {
struct regulator_dev *regulator;
 
+   if (!info[i].desc.name)
+   continue;
+
if (pdata  pdata-num_regulators) {
init_data = pdata-regulators[i];
if (!init_data)
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index a92d173..122cfd2 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -295,6 +295,9 @@ enum {
 #define PM860_BUCK4_MISC2  (0x82)
 #define PM860_BUCK4_FULL_DRV   BIT(2)
 
+#define PM860_BUCK1_MISC   0x8E
+#define BUCK1_DUAL_PHASE_SEL   BIT(2)
+
 struct pm80x_rtc_pdata {
int vrtc;
int rtc_wakeup;
-- 
1.9.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/


[PATCH 10/10] ALSA: axd: add Makefile

2015-08-24 Thread Qais Yousef
Now all necessary files are added, allow axd to be selected through Kconfig and
compiled.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/Kconfig  |  1 +
 sound/soc/Makefile |  1 +
 sound/soc/img/Kconfig  | 11 +++
 sound/soc/img/Makefile |  1 +
 sound/soc/img/axd/Makefile | 13 +
 5 files changed, 27 insertions(+)
 create mode 100644 sound/soc/img/Kconfig
 create mode 100644 sound/soc/img/Makefile
 create mode 100644 sound/soc/img/axd/Makefile

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 2ae9619443d1..8f29af1d397e 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -44,6 +44,7 @@ source sound/soc/jz4740/Kconfig
 source sound/soc/nuc900/Kconfig
 source sound/soc/omap/Kconfig
 source sound/soc/kirkwood/Kconfig
+source sound/soc/img/Kconfig
 source sound/soc/intel/Kconfig
 source sound/soc/mediatek/Kconfig
 source sound/soc/mxs/Kconfig
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index e189903fabf4..c6a1c04b8e39 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SND_SOC) += davinci/
 obj-$(CONFIG_SND_SOC)  += dwc/
 obj-$(CONFIG_SND_SOC)  += fsl/
 obj-$(CONFIG_SND_SOC)  += jz4740/
+obj-$(CONFIG_SND_SOC)  += img/
 obj-$(CONFIG_SND_SOC)  += intel/
 obj-$(CONFIG_SND_SOC)  += mediatek/
 obj-$(CONFIG_SND_SOC)  += mxs/
diff --git a/sound/soc/img/Kconfig b/sound/soc/img/Kconfig
new file mode 100644
index ..5a089b7d4929
--- /dev/null
+++ b/sound/soc/img/Kconfig
@@ -0,0 +1,11 @@
+config SND_SOC_IMG_AXD
+   tristate Imagination AXD Audio Processing IP
+   depends on MIPS  COMMON_CLK  CMA
+   ---help---
+ Say Y or M here if you to add support for AXD Audio Processing IP.
+
+config SND_SOC_IMG_AXD_DEBUGFS
+   bool AXD debugfs support
+   depends on SND_SOC_IMG_AXD  DEBUG_FS
+   ---help---
+ Say Y if you want to create AXD debugfs nodes
diff --git a/sound/soc/img/Makefile b/sound/soc/img/Makefile
new file mode 100644
index ..189abf5d927c
--- /dev/null
+++ b/sound/soc/img/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SND_SOC_IMG_AXD) += axd/
diff --git a/sound/soc/img/axd/Makefile b/sound/soc/img/axd/Makefile
new file mode 100644
index ..cfa1f412bf19
--- /dev/null
+++ b/sound/soc/img/axd/Makefile
@@ -0,0 +1,13 @@
+obj-$(CONFIG_SND_SOC_IMG_AXD) := axd.o
+
+axd-objs = axd_alsa_ops.o \
+  axd_buffers.o \
+  axd_cmds.o \
+  axd_cmds_config.o \
+  axd_cmds_decoder_config.o \
+  axd_cmds_info.o \
+  axd_cmds_internal.o \
+  axd_cmds_pipes.o \
+  axd_hdr.o \
+  axd_module.o \
+  axd_platform_$(ARCH).o \
-- 
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/


kernel 3.13-61/62 /cpu1/cpufreq/stats

2015-08-24 Thread Ludwig Petrosyan
Hello

we have problem boot kernel 3.13-61/62 on the MTCA crate, some time it
boots some time no.
In the kernel log we found this problem:

[   16.168871] [ cut here ]
[   16.173513] WARNING: CPU: 0 PID: 4 at
/build/linux-lts-trusty-G19QHO/linux-lts-trusty-3.13.0/fs/sysfs/dir.c:486 
sysfs_warn_dup+0x91/0xb0()
[   16.185967] sysfs: cannot create duplicate filename
'/devices/system/cpu/cpu1/cpufreq/stats'

we found out thid peoblen is solved in the kernel 3.14 (file
linux/drivers/cpufreq/cpufreq.c), is there some way to solve it for
kernel 3.13-61/62
(some boot parameters ...) ?

The older kernel 3.13-55 runs fine on the same CPU.


with best regards

Ludwig Petrosyan
DESY

--
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/3] KVM: make halt_poll_ns per-VCPU

2015-08-24 Thread Wanpeng Li
Change halt_poll_ns into per-VCPU variable, seeded from module parameter,
to allow greater flexibility.

Signed-off-by: Wanpeng Li wanpeng...@hotmail.com
---
 include/linux/kvm_host.h | 1 +
 virt/kvm/kvm_main.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 81089cf..1bef9e2 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -242,6 +242,7 @@ struct kvm_vcpu {
int sigset_active;
sigset_t sigset;
struct kvm_vcpu_stat stat;
+   unsigned int halt_poll_ns;
 
 #ifdef CONFIG_HAS_IOMEM
int mmio_needed;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d8db2f8f..a122b52 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -217,6 +217,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, 
unsigned id)
vcpu-kvm = kvm;
vcpu-vcpu_id = id;
vcpu-pid = NULL;
+   vcpu-halt_poll_ns = halt_poll_ns;
init_waitqueue_head(vcpu-wq);
kvm_async_pf_vcpu_init(vcpu);
 
-- 
1.9.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/


[PATCH 3/3] KVM: trace kvm_halt_poll_ns grow/shrink

2015-08-24 Thread Wanpeng Li
Tracepoint for dynamic halt_pool_ns, fired on every potential change.

Signed-off-by: Wanpeng Li wanpeng...@hotmail.com
---
 include/trace/events/kvm.h | 30 ++
 virt/kvm/kvm_main.c|  8 
 2 files changed, 38 insertions(+)

diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index a44062d..75ddf80 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -356,6 +356,36 @@ TRACE_EVENT(
  __entry-address)
 );
 
+TRACE_EVENT(kvm_halt_poll_ns,
+   TP_PROTO(bool grow, unsigned int vcpu_id, int new, int old),
+   TP_ARGS(grow, vcpu_id, new, old),
+
+   TP_STRUCT__entry(
+   __field(bool, grow)
+   __field(unsigned int, vcpu_id)
+   __field(int, new)
+   __field(int, old)
+   ),
+
+   TP_fast_assign(
+   __entry-grow   = grow;
+   __entry-vcpu_id= vcpu_id;
+   __entry-new= new;
+   __entry-old= old;
+   ),
+
+   TP_printk(vcpu %u: halt_pool_ns %d (%s %d),
+   __entry-vcpu_id,
+   __entry-new,
+   __entry-grow ? grow : shrink,
+   __entry-old)
+);
+
+#define trace_kvm_halt_poll_ns_grow(vcpu_id, new, old) \
+   trace_kvm_halt_poll_ns(true, vcpu_id, new, old)
+#define trace_kvm_halt_poll_ns_shrink(vcpu_id, new, old) \
+   trace_kvm_halt_poll_ns(false, vcpu_id, new, old)
+
 #endif
 
 #endif /* _TRACE_KVM_MAIN_H */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index bcfbd35..65e3631 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1959,13 +1959,21 @@ static unsigned int __shrink_halt_poll_ns(int val, int 
modifier, int minimum)
 
 static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
 {
+   int old = vcpu-halt_poll_ns;
+
vcpu-halt_poll_ns = __grow_halt_poll_ns(vcpu-halt_poll_ns);
+
+   trace_kvm_halt_poll_ns_grow(vcpu-vcpu_id, vcpu-halt_poll_ns, old);
 }
 
 static void shrink_halt_poll_ns(struct kvm_vcpu *vcpu)
 {
+   int old = vcpu-halt_poll_ns;
+
vcpu-halt_poll_ns = __shrink_halt_poll_ns(vcpu-halt_poll_ns,
halt_poll_ns_shrink, halt_poll_ns);
+
+   trace_kvm_halt_poll_ns_shrink(vcpu-vcpu_id, vcpu-halt_poll_ns, old);
 }
 
 /*
-- 
1.9.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 v3 06/14] Documentation: drm/bridge: add document for analogix_dp

2015-08-24 Thread Heiko Stuebner
Hi Yakir,

Am Montag, 24. August 2015, 20:48:01 schrieb Yakir Yang:
 在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
  On 24.08.2015 11:42, Yakir Yang wrote:
  Hi Krzysztof,
  
  在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
  2015-08-24 8:23 GMT+09:00 Rob Herring robherri...@gmail.com:
  On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
  Analogix dp driver is split from exynos dp driver, so we just
  make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
  
  Beside update some exynos dtsi file with the latest change
  according to the devicetree binding documents.
  
  You can't just change the exynos bindings and break compatibility. Is
  there some agreement with exynos folks to do this?
  
  No, there is no agreement. This wasn't even sent to Exynos maintainers.
  
  Sorry about this one, actually I have add Exynos maintainers in version
  1  version 2,
  but lose some maintainers in version 3, I would fix it in bellow
  versions.
  
  Additionally the patchset did not look interesting to me because of
  misleading subject - Documentation instead of ARM: dts:.
  
  Yakir, please:
  1. Provide backward compatibility. Mark old properties as deprecated
  but still support them.
  
  Do you mean that I should keep the old properties declare in
  exynos-dp.txt,
  but just mark them as deprecated flag.
  
  That is one of ways how to do this. However more important is that
  driver should still support old bindings so such code:
  -   if (of_property_read_u32(dp_node, samsung,color-space,
  +   if (of_property_read_u32(dp_node, analogix,color-space,
  
  is probably wrong. Will the driver support old DTB in the same way as it
  was supporting before the change?
 
 Okay, I got your means. So document is not the focus, the most important
 is that
 driver should support the old dts prop. If so the new analogix dp driver
 should keep
 the samsung,color-space, rather then just mark it with [DEPRECATED] flag.
 
 But from your follow suggest, I think you agree to update driver code,
 and just mark
 old prop with deprecated flag. If so I think such code would not be wrong
 
 -   if (of_property_read_u32(dp_node, samsung,color-space,
 +  if (of_property_read_u32(dp_node, analogix,color-space,

In a generic driver, the property should have either none, or the analogix 
prefix. But DT-properties need to be backwards compatible, meaning an older 
Exynos devicetree should run unmodified with a newer kernel.

So the common course of action is to mark the old one as deprecated but still 
test for both, so something like:

   if (of_property_read_u32(dp_node, analogix,color-space,
 dp_video_config-color_space))
   if (of_property_read_u32(dp_node, samsung,color-space,
 dp_video_config-color_space)) {

dev_err(dev, failed to get color-space\n);
return ERR_PTR(-EINVAL);
}




--
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 v2 5/5] arm64: add KASan support

2015-08-24 Thread Linus Walleij
On Wed, Aug 19, 2015 at 4:51 PM, Andrey Ryabinin ryabinin@gmail.com wrote:
 On 08/19/2015 03:14 PM, Linus Walleij wrote:

 Integrator/AP (ARMv5):

 This one mounted with an ARMv5 ARM926 tile. It boots nicely
 (but takes forever) with KASan and run all test cases (!) just like
 for the other platforms but before reaching userspace this happens:

 THREAD_SIZE hardcoded in act_mm macro.

 This hack should help:

 diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
 index c671f34..b1765f2 100644
 --- a/arch/arm/mm/proc-macros.S
 +++ b/arch/arm/mm/proc-macros.S
 @@ -32,6 +32,9 @@
 .macro  act_mm, rd
 bic \rd, sp, #8128
 bic \rd, \rd, #63
 +#ifdef CONFIG_KASAN
 +   bic \rd, \rd, #8192
 +#endif
 ldr \rd, [\rd, #TI_TASK]
 ldr \rd, [\rd, #TSK_ACTIVE_MM]
 .endm

Yes this work, thanks! I now get to userspace.
Tested-by: Linus Walleij linus.wall...@linaro.org

I have compiled Trinity and running some stress on different boards.
The ARMv7 seems to rather die from random nasty stuff from the
syscall or OOM rather than any KASan-detected bugs, but I'll
keep hammering at it a big.

I have some odd patch I'll pass along.

Yours,
Linus Walleij
--
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/10] irqchip: irq-mips-gic: export gic_send_ipi

2015-08-24 Thread Qais Yousef

On 08/24/2015 01:49 PM, Thomas Gleixner wrote:

On Mon, 24 Aug 2015, Qais Yousef wrote:


Some drivers might require to send ipi to other cores. So export it.

Which IPIs do you need to send from a driver which are not exposed by
the SMP functions already?


It's not an SMP IPI. We use GIC to exchange interrupts between AXD and 
the host system since AXD is another MIPS core in the cluster.



This will be used later by AXD driver.

That smells fishy and it wants a proper explanation WHY and not just a
sloppy statement that it will be used later. I can figure that out
myself as exporting a function without using it does not make any sense.


Sorry for the terse explanation. As pointed above AXD uses GIC to send 
and receive interrupts to the host core. Without this change I can't 
compile the driver as a driver module because the symbol is not exported.


Does this make things clearer?

Thanks,
Qais



Thanks,

tglx


--
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 0/6] fix drivers/staging/android some coding style issues

2015-08-24 Thread Sudip Mukherjee
On Fri, Aug 21, 2015 at 02:13:51PM +0800, Peng Sun wrote:
 
 patches based on commit f0359ead9129821e4b3b5486e7837d3001a95574
 linux-next next-20150820
you have almost similar subject for all patches in the series and please
mention which coding style you have changed.

regards
sudip
--
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] usbnet: Fix two races between usbnet_stop() and the BH

2015-08-24 Thread Bjørn Mork
Eugene Shatokhin eugene.shatok...@rosalab.ru writes:

 19.08.2015 15:31, Bjørn Mork пишет:
 Eugene Shatokhin eugene.shatok...@rosalab.ru writes:

 The problem is not in the reordering but rather in the fact that
 dev-flags = 0 is not necessarily atomic
 w.r.t. clear_bit(EVENT_RX_KILL, dev-flags), and vice versa.

 So the following might be possible, although unlikely:

 CPU0 CPU1
   clear_bit: read dev-flags
   clear_bit: clear EVENT_RX_KILL in the read value

 dev-flags=0;

   clear_bit: write updated dev-flags

 As a result, dev-flags may become non-zero again.

 Ah, right.  Thanks for explaining.

 I cannot prove yet that this is an impossible situation. If anyone
 can, please explain. If so, this part of the patch will not be needed.

 I wonder if we could simply move the dev-flags = 0 down a few lines to
 fix both issues?  It doesn't seem to do anything useful except for
 resetting the flags to a sane initial state after the device is down.

 Stopping the tasklet rescheduling etc depends only on netif_running(),
 which will be false when usbnet_stop is called.  There is no need to
 touch dev-flags for this to happen.

 That was one of the first ideas we discussed here. Unfortunately, it
 is probably not so simple.

 Setting dev-flags to 0 makes some delayed operations do nothing and,
 among other things, not to reschedule usbnet_bh().

Yes, but I believe that is merely a side effect.  You should never need
to clear multiple flags to get the desired behaviour.

 As you can see in drivers/net/usb/usbnet.c, usbnet_bh() can be called
 as a tasklet function and as a timer function in a number of
 situations (look for the usage of dev-bh and dev-delay there).

 netif_running() is indeed false when usbnet_stop() runs, usbnet_stop()
 also disables Tx. This seems to be enough for many cases where
 usbnet_bh() is scheduled, but I am not so sure about the remaining
 ones, namely:

 1. A work function, usbnet_deferred_kevent(), may reschedule
 usbnet_bh(). Looks like the workqueue is only stopped in
 usbnet_disconnect(), so a work item might be processed while
 usbnet_stop() works. Setting dev-flags to 0 makes the work function
 do nothing, by the way. See also the comment in usbnet_stop() about
 this.

 A work item may be placed to this workqueue in a number of ways, by
 both usbnet module and the mini-drivers. It is not too easy to track
 all these situations.

That's an understatement :)



 2. rx_complete() and tx_complete() may schedule execution of
 usbnet_bh() as a tasklet or a timer function. These two are URB
 completion callbacks.

 It seems, new Rx and Tx URBs cannot be submitted when usbnet_stop()
 clears dev-flags, indeed. But it does not prevent the completion
 handlers for the previously submitted URBs from running concurrently
 with usbnet_stop(). The latter waits for them to complete (via
 usbnet_terminate_urbs(dev)) but only if FLAG_AVOID_UNLINK_URBS is not
 set in info-flags. rndis_wlan, however, sets this flag for a few
 hardware models. So - no guarantees here as well.

FLAG_AVOID_UNLINK_URBS looks like it should be replaced by the newer
ability to keep the status urb active. I believe that must have been the
real reason for adding it, based on the commit message and the effect
the flag will have:

 commit 1487cd5e76337555737cbc55d7d83f41460d198f
 Author: Jussi Kivilinna jussi.kivili...@mbnet.fi
 Date:   Thu Jul 30 19:41:20 2009 +0300

usbnet: allow minidriver to prevent urb unlinking on usbnet_stop

rndis_wlan devices freeze after running usbnet_stop several times. It 
appears
that firmware freezes in state where it does not respond to any RNDIS 
commands
and device have to be physically unplugged/replugged. This patch lets
minidrivers to disable unlink_urbs on usbnet_stop through new info flag.

Signed-off-by: Jussi Kivilinna jussi.kivili...@mbnet.fi
Cc: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: John W. Linville linvi...@tuxdriver.com



The rx urbs will not be resubmitted in any case, and there are of course
no tx urbs being submitted.  So the only effect of this flag is on the
status/interrupt urb, which I can imagine some RNDIS devices wants
active all the time. 

So FLAG_AVOID_UNLINK_URBS should probably be removed and replaced calls
to usbnet_status_start() and usbnet_status_stop().  This will require
testing on some of the devices with the original firmware problem
however.

In any case: I do not think this flag should be considered when trying
to make usbnet_stop behaviour saner.  It's only purpose is to
deliberately break usbnet_stop by not actually stopping.


 If someone could list the particular bits of dev-flags that should be
 cleared to make sure no deferred call could reschedule usbnet_bh(),
 etc... Well, it would be enough to clear these first and use
 dev-flags = 0 later, after tasklet_kill() and del_timer_sync(). I
 cannot point out these particular bits 

Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi

2015-08-24 Thread Marc Zyngier
On 24/08/15 14:02, Qais Yousef wrote:
 On 08/24/2015 01:49 PM, Thomas Gleixner wrote:
 On Mon, 24 Aug 2015, Qais Yousef wrote:

 Some drivers might require to send ipi to other cores. So export it.
 Which IPIs do you need to send from a driver which are not exposed by
 the SMP functions already?
 
 It's not an SMP IPI. We use GIC to exchange interrupts between AXD and 
 the host system since AXD is another MIPS core in the cluster.

So is this the case of another CPU in the system that is not under
control of Linux, but that you need to signal anyway? How do you agree
on the IPI number between the two systems?

 This will be used later by AXD driver.
 That smells fishy and it wants a proper explanation WHY and not just a
 sloppy statement that it will be used later. I can figure that out
 myself as exporting a function without using it does not make any sense.
 
 Sorry for the terse explanation. As pointed above AXD uses GIC to send 
 and receive interrupts to the host core. Without this change I can't 
 compile the driver as a driver module because the symbol is not exported.
 
 Does this make things clearer?

To me, it feels like this is yet another case of routing interrupts to
another agent in the system, which is not a CPU under the kernel's
control. There is at least two other platforms doing similar craziness
(a Freescale platform, and at least one Nvidia).

I'd rather see something more architected than this blind export, or
at least some level of filtering (the idea random drivers can access
such a low-level function doesn't make me feel very good).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
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 RFC] serial: 8250: Handle invalid UART state

2015-08-24 Thread Peter Hurley
On 08/19/2015 04:12 PM, california.l.sulli...@intel.com wrote:
 From: California Sullivan california.l.sulli...@intel.com
 
 The debug UART on the Bay Trail is buggy and will sometimes enter a
 state where there is a Character Timeout interrupt, but the Data
 Ready bit in the Line Status Register is not set, despite there
 being data available in the FIFO. It stays in this state until the
 Receive Buffer is read. Because the 8250 driver does not read the
 Receive Buffer without the Data Ready bit being set, the UART is
 never read once we reach this point, and thus the Character Timeout
 interrupt is never cleared. This makes the driver spin in a loop
 causing multiple too much work for irq errors and eventually
 locking up entirely.

LSR doesn't reflect the actual state of the fifo?
So kgdb (CONSOLE_POLL) won't work on these platforms either, right?

Does this happen with only a single byte in the fifo or is it any
number of bytes under the fifo trigger?


 This patch handles the invalid state by setting the Data Ready bit
 in the 'status' variable when the invalid state occurs. This allows
 the receive buffer to be read, which clears the interrupt
 identification register in the UART and brings us back to a correct
 state.
 
 After this patch was submitted for internal comment, a similar bug on
 the HSUARTs of the Bay Trail and Braswell platforms was pointed out.
 On those UARTs, the invalid state mentioned previously is reached for
 some amount of time, cauing the same too much work for irq messages,
 but not permanently locking up the UART. This patch has been confirmed
 to solve that issue as well.
 
 We considered solving this by adding a new UART_BUG_ define and
 detecting the buggy UART by either identifying the processor or by
 adding a new PNP device ID to firmware. However, this solution
 would be more complex and have zero performance benefits, as the
 ISR would require a similar 'if' condition to detect and handle the
 bug.
 
 Our main concern with this fix is whether it having a Character
 Timeout with no Data Ready is an invalid state for all UARTs or
 just some. If other UARTs have a Character Timeout without
 immediately flipping the Data Ready bit in the Line Status Register
 for a good reason, setting the Data Ready bit in the 'status'
 variable could have unintended consequences.

I think there is every likelihood of spurious RX timeout interrupts
tripping this patch, sorry.

Unfortunately, I think UART_BUG_ is the only viable possibility.
Or perhaps fixing the port type as PORT_8250 (thus disabling the fifos).

Regards,
Peter Hurley


 Signed-off-by: California Sullivan california.l.sulli...@intel.com
 ---
  drivers/tty/serial/8250/8250_core.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/drivers/tty/serial/8250/8250_core.c 
 b/drivers/tty/serial/8250/8250_core.c
 index ea1a8da..078b118 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -1604,6 +1604,14 @@ int serial8250_handle_irq(struct uart_port *port, 
 unsigned int iir)
  
   DEBUG_INTR(status = %x..., status);
  
 + /*
 +  * Workaround for when there is a character timeout interrupt
 +  * but the data ready bit is not set in the Line Status Register.
 +  */
 + if ((iir  UART_IIR_RX_TIMEOUT) 
 + !(status  (UART_LSR_DR | UART_LSR_BI)))
 + status |= UART_LSR_DR;
 +
   if (status  (UART_LSR_DR | UART_LSR_BI)) {
   if (up-dma)
   dma_err = up-dma-rx_dma(up, iir);
 

--
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: [RESEND][PATCH 4/4] ARM: dts: keystone: Add ti,keystone-spi for SPI

2015-08-24 Thread Franklin S Cooper Jr.
Hi Santosh,

All the patches except this one are in linux-next.

On 07/22/2015 11:17 AM, santosh shilimkar wrote:
 On 7/22/2015 5:32 AM, Franklin S Cooper Jr wrote:
 Add ti,keystone-spi to the compatible field for the SPI node. This new
 entry insures that the proper prescaler limit is used for keystone devices

 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 ---
 Once the binding and driver makes it, I can pick this up.
 Keep me posted. Thanks !!

 Regards,
 Santosh


--
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 RFC v1 0/4] perf: Introduce extended syscall error reporting

2015-08-24 Thread Alexander Shishkin
Ingo Molnar mi...@kernel.org writes:

 * Peter Zijlstra pet...@infradead.org wrote:

 On Fri, Jul 24, 2015 at 02:45:55PM +0300, Alexander Shishkin wrote:
  Hi Peter and Ingo and everybody,
  
  Here's my second stab at improving perf's error reporting by attaching
  arbitrary strings to the integer error codes. This is largely based
  off of the previous email thread [1].
  
  This time around, I employed a linker trick to convert the structures
  containing extended error information into integers, which are then
  made to look just like normal error codes so that IS_ERR_VALUE() and
  friends would still work correctly on them. So no extra pointers in
  the struct perf_event or anywhere else; the extended error codes are
  passed around like normal error codes. They only need to be converted
  in syscalls' topmost return statements. This is done in 1/4.
  
  Then, 2/4 illustrates how error sites can be extended to include more
  information such as file names and line numbers [1].
  
  The other two patches add perf_err() annotation to a few semi-randomly
  picked places in perf core (3/4) and x86 bits (4/4).
 
 Looks generally ok to me. Thanks for doing this.

 I like this too.

 Alexander, mind sending a finalized, signed off version?

Sure, I have everything ready, except for what about 2/4 (using
CONFIG_DEBUG_KERNEL to extend output with file name and line number)?
Should I leave it out or can we pick a more specific kconfig option or
add a new one?

Regards,
--
Alex
--
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 v7 3/6] mm: Introduce VM_LOCKONFAULT

2015-08-24 Thread Konstantin Khlebnikov
On Mon, Aug 24, 2015 at 4:30 PM, Vlastimil Babka vba...@suse.cz wrote:
 On 08/24/2015 12:17 PM, Konstantin Khlebnikov wrote:


 I am in the middle of implementing lock on fault this way, but I cannot
 see how we will hanlde mremap of a lock on fault region.  Say we have
 the following:

  addr = mmap(len, MAP_ANONYMOUS, ...);
  mlock(addr, len, MLOCK_ONFAULT);
  ...
  mremap(addr, len, 2 * len, ...)

 There is no way for mremap to know that the area being remapped was lock
 on fault so it will be locked and prefaulted by remap.  How can we avoid
 this without tracking per vma if it was locked with lock or lock on
 fault?


 remap can count filled ptes and prefault only completely populated areas.


 Does (and should) mremap really prefault non-present pages? Shouldn't it
 just prepare the page tables and that's it?

As I see mremap prefaults pages when it extends mlocked area.

Also quote from manpage
: If  the memory segment specified by old_address and old_size is locked
: (using mlock(2) or similar), then this lock is maintained when the segment is
: resized and/or relocated.  As a  consequence, the amount of memory locked
: by the process may change.


 There might be a problem after failed populate: remap will handle them
 as lock on fault. In this case we can fill ptes with swap-like non-present
 entries to remember that fact and count them as should-be-locked pages.


 I don't think we should strive to have mremap try to fix the inherent
 unreliability of mmap (MAP_POPULATE)?

I don't think so. MAP_POPULATE works only when mmap happens.
Flag MREMAP_POPULATE might be a good idea. Just for symmetry.
--
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: Fix warning while make xmldocs caused by skbuff.c

2015-08-24 Thread Masanari Iida
This patch fix following warnings.

.//net/core/skbuff.c:407: warning: No description found
for parameter 'len'
.//net/core/skbuff.c:407: warning: Excess function parameter
 'length' description in '__netdev_alloc_skb'
.//net/core/skbuff.c:476: warning: No description found
 for parameter 'len'
.//net/core/skbuff.c:476: warning: Excess function parameter
'length' description in '__napi_alloc_skb'

Signed-off-by: Masanari Iida standby2...@gmail.com
---
 net/core/skbuff.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7b84330..dad4dd3 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -392,7 +392,7 @@ EXPORT_SYMBOL(napi_alloc_frag);
 /**
  * __netdev_alloc_skb - allocate an skbuff for rx on a specific device
  * @dev: network device to receive on
- * @length: length to allocate
+ * @len: length to allocate
  * @gfp_mask: get_free_pages mask, passed to alloc_skb
  *
  * Allocate a new sk_buff and assign it a usage count of one. The
@@ -461,7 +461,7 @@ EXPORT_SYMBOL(__netdev_alloc_skb);
 /**
  * __napi_alloc_skb - allocate skbuff for rx in a specific NAPI instance
  * @napi: napi instance this buffer was allocated for
- * @length: length to allocate
+ * @len: length to allocate
  * @gfp_mask: get_free_pages mask, passed to alloc_skb and alloc_pages
  *
  * Allocate a new sk_buff for use in NAPI receive.  This buffer will
-- 
2.5.0.234.gefc8a62

--
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/7] drm/vc4: Add devicetree bindings for VC4.

2015-08-24 Thread Rob Herring
On Wed, Aug 12, 2015 at 7:56 PM, Eric Anholt e...@anholt.net wrote:
 Signed-off-by: Eric Anholt e...@anholt.net
 ---
  .../devicetree/bindings/gpu/brcm,bcm-vc4.txt   | 83 
 ++
  1 file changed, 83 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

 diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
 b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
 new file mode 100644
 index 000..2b13e61
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
 @@ -0,0 +1,83 @@
 +Broadcom VC4 GPU
 +
 +The VC4 device present on the Raspberry Pi includes a display system
 +with HDMI output and the HVS scaler for compositing display planes.
 +
 +Required properties for VC4:
 +- compatible:  Should be brcm,vc4
 +- crtcs:   List of references to pixelvalve scanout engines
 +- hvss:List of references to HVS video scalers
 +- encoders:List of references to output encoders (HDMI, SDTV)

Creating these links is what the OF graph binding is for. Please use
it. Plus this is a DRMism in the binding.

 +
 +Required properties for Pixel Valve:
 +- compatible:  Should be brcm,vc4-pixelvalve

There's only one version of IP and all chips have the same bugs? You
should have chip names in the compatible strings.

 +- reg: Physical base address and length of the PV's registers
 +- interrupts:  The interrupt number
 + See 
 bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
 +
 +Required properties for HVS:
 +- compatible:  Should be brcm,vc4-hvs
 +- reg: Physical base address and length of the HVS's registers
 +- interrupts:  The interrupt number
 + See 
 bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
 +
 +Required properties for HDMI
 +- compatible:  Should be brcm,vc4-hdmi
 +- reg: Physical base address and length of the two register ranges
 + (HDMI and HD)
 +- interrupts:  The interrupt numbers
 + See 
 bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
 +- ddc: phandle of the I2C controller used for DDC EDID probing
 +- crtc:phandle to the pixelvalve CRTC the HDMI encoder is 
 attached to

Same comment about OF graph.

 +
 +Optional properties for HDMI:
 +- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
 + as an interrupt/status bit in the HDMI controller
 + itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt

Use the hdmi-connector binding. This doesn't belong here. The clue is
your comment in parenthesis.

Rob
--
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 09/18] mfd: cros_ec: spi: Add OF match table

2015-08-24 Thread Lee Jones
On Thu, 20 Aug 2015, Javier Martinez Canillas wrote:

 The Documentation/devicetree/bindings/mfd/cros-ec.txt DT binding doc lists
 google,cros-ec-spi as a compatible string but the corresponding driver
 does not have an OF match table. Add the table to the driver so the SPI
 core can do an OF style match.
 
 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 ---
 
  drivers/mfd/cros_ec_spi.c | 7 +++
  1 file changed, 7 insertions(+)

Applied, thanks.

 diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
 index 16f228dc243f..30a296b4e748 100644
 --- a/drivers/mfd/cros_ec_spi.c
 +++ b/drivers/mfd/cros_ec_spi.c
 @@ -701,6 +701,12 @@ static int cros_ec_spi_resume(struct device *dev)
  static SIMPLE_DEV_PM_OPS(cros_ec_spi_pm_ops, cros_ec_spi_suspend,
cros_ec_spi_resume);
  
 +static const struct of_device_id cros_ec_spi_of_match[] = {
 + { .compatible = google,cros-ec-spi, },
 + { /* sentinel */ },
 +};
 +MODULE_DEVICE_TABLE(of, cros_ec_spi_of_match);
 +
  static const struct spi_device_id cros_ec_spi_id[] = {
   { cros-ec-spi, 0 },
   { }
 @@ -710,6 +716,7 @@ MODULE_DEVICE_TABLE(spi, cros_ec_spi_id);
  static struct spi_driver cros_ec_driver_spi = {
   .driver = {
   .name   = cros-ec-spi,
 + .of_match_table = of_match_ptr(cros_ec_spi_of_match),
   .owner  = THIS_MODULE,
   .pm = cros_ec_spi_pm_ops,
   },

-- 
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 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses

2015-08-24 Thread Cornelia Huck
On Mon, 24 Aug 2015 11:29:29 +0800
Jason Wang jasow...@redhat.com wrote:

 On 08/21/2015 05:29 PM, Cornelia Huck wrote:
  On Fri, 21 Aug 2015 16:03:52 +0800
  Jason Wang jasow...@redhat.com wrote:

  @@ -850,9 +845,15 @@ kvm_assign_ioeventfd(struct kvm *kvm, struct 
  kvm_ioeventfd *args)
  Unfortunately snipped by diff, but the check here is on !len  !PIO,
  which only does the desired thing as VIRTIO_CCW always uses len == 8.
  Should the check be for !len  MMIO instead?
 
 I think the answer depends on whether len == 0 is valid for ccw. If not
 we can fail the assign earlier. Since even without this patch, if
 userspace tries to register a dev with len equals to zero, it will also
 be registered to KVM_FAST_MMIO_BUS. If yes, we need check as you
 suggested here.

I don't think len != 8 makes much sense for the way ioeventfd is
defined for ccw (we handle hypercalls with a payload specifying the
device), but we currently don't actively fence it.

But regardless, I'd prefer to decide directly upon whether userspace
actually tried to register for the mmio bus.

 
 
 ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
   p-addr, 0, p-dev);
 if (ret  0)
  -  goto register_fail;
  +  goto unlock_fail;
  +  } else {
  +  ret = kvm_io_bus_register_dev(kvm, bus_idx, p-addr, p-length,
  +p-dev);
  +  if (ret  0)
  +  goto unlock_fail;
 }
  Hm... maybe the following would be more obvious:
 
  my_bus = (p-length == 0)  (bus_idx == KVM_MMIO_BUS) ? KVM_FAST_MMIO_BUS 
  : bus_idx;
  ret = kvm_io_bus_register_dev(kvm, my_bus, p-addr, p-length, pdev-dev); 
 
   
  +
 kvm-buses[bus_idx]-ioeventfd_count++;
 list_add_tail(p-list, kvm-ioeventfds);
  (...)
 
  @@ -900,10 +899,11 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct 
  kvm_ioeventfd *args)
 if (!p-wildcard  p-datamatch != args-datamatch)
 continue;
   
  -  kvm_io_bus_unregister_dev(kvm, bus_idx, p-dev);
 if (!p-length) {
 kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
   p-dev);
  +  } else {
  +  kvm_io_bus_unregister_dev(kvm, bus_idx, p-dev);
 }
  Similar comments here... do you want to check for bus_idx ==
  KVM_MMIO_BUS as well?
 
 Good catch. I think keep the original code as is will be also ok to
 solve this. (with changing the bus_idx to KVM_FAST_MMIO_BUS during
 registering if it was an wildcard mmio).

Do you need to handle the ioeventfd_count changes on the fast mmio bus
as well?

 
 
 kvm-buses[bus_idx]-ioeventfd_count--;
 ioeventfd_release(p);
 

--
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] HID: quirks: add QUIRK_NOGET for an other TPV touchscreen

2015-08-24 Thread Jiri Kosina
On Fri, 21 Aug 2015, Benjamin Tissoires wrote:

 Looks like 0x8882 needs the same quirk than 0x8883.
 Given that both devices claim they are TPV OpticalTouchScreen rename
 the 0x8883 to add its PID in the #define.
 
 Reported-by: Blaine Lee blaine.j@medtronic.com
 Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com

Applied to for-4.3/upstream. Thanks,

-- 
Jiri Kosina
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/


Re: [x86] copy_from{to}_user question

2015-08-24 Thread Jeff Epler
On Mon, Aug 24, 2015 at 03:52:11PM +0800, yalin wang wrote:
 i am not clear about what is STAC / SMAP ?
 could you give me a link for understanding ?

the first item I found by googling was
https://lwn.net/Articles/517251/

Jeff
--
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 02/12] mm, page_alloc: Remove unnecessary recalculations for dirty zone balancing

2015-08-24 Thread Mel Gorman
File-backed pages that will be immediately written are balanced between
zones.  This heuristic tries to avoid having a single zone filled with
recently dirtied pages but the checks are unnecessarily expensive. Move
consider_zone_balanced into the alloc_context instead of checking bitmaps
multiple times. The patch also gives the parameter a more meaningful name.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
Acked-by: David Rientjes rient...@google.com
Acked-by: Michal Hocko mho...@suse.com
Acked-by: Vlastimil Babka vba...@suse.cz
---
 mm/internal.h   |  1 +
 mm/page_alloc.c | 11 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index 36b23f1e2ca6..9331f802a067 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -129,6 +129,7 @@ struct alloc_context {
int classzone_idx;
int migratetype;
enum zone_type high_zoneidx;
+   bool spread_dirty_pages;
 };
 
 /*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9b6bae688db8..62ae28d8ae8d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2453,8 +2453,6 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int 
order, int alloc_flags,
nodemask_t *allowednodes = NULL;/* zonelist_cache approximation */
int zlc_active = 0; /* set if using zonelist_cache */
int did_zlc_setup = 0;  /* just call zlc_setup() one time */
-   bool consider_zone_dirty = (alloc_flags  ALLOC_WMARK_LOW) 
-   (gfp_mask  __GFP_WRITE);
int nr_fair_skipped = 0;
bool zonelist_rescan;
 
@@ -2509,14 +2507,14 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int 
order, int alloc_flags,
 *
 * XXX: For now, allow allocations to potentially
 * exceed the per-zone dirty limit in the slowpath
-* (ALLOC_WMARK_LOW unset) before going into reclaim,
+* (spread_dirty_pages unset) before going into reclaim,
 * which is important when on a NUMA setup the allowed
 * zones are together not big enough to reach the
 * global limit.  The proper fix for these situations
 * will require awareness of zones in the
 * dirty-throttling and the flusher threads.
 */
-   if (consider_zone_dirty  !zone_dirty_ok(zone))
+   if (ac-spread_dirty_pages  !zone_dirty_ok(zone))
continue;
 
mark = zone-watermark[alloc_flags  ALLOC_WMARK_MASK];
@@ -3202,6 +3200,10 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
order,
 
/* We set it here, as __alloc_pages_slowpath might have changed it */
ac.zonelist = zonelist;
+
+   /* Dirty zone balancing only done in the fast path */
+   ac.spread_dirty_pages = (gfp_mask  __GFP_WRITE);
+
/* The preferred zone is used for statistics later */
preferred_zoneref = first_zones_zonelist(ac.zonelist, ac.high_zoneidx,
ac.nodemask ? : cpuset_current_mems_allowed,
@@ -3220,6 +3222,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
 * complete.
 */
alloc_mask = memalloc_noio_flags(gfp_mask);
+   ac.spread_dirty_pages = false;
 
page = __alloc_pages_slowpath(alloc_mask, order, ac);
}
-- 
2.4.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/


[PATCH 00/12] Remove zonelist cache and high-order watermark checking v3

2015-08-24 Thread Mel Gorman
Changelog since V3
o Covered cases where __GFP_KSWAPD_RECLAIM is needed(vbabka)
o Cleaned up trailing references to zlc (vbabka)
o Fixed a subtle problem with GFP_TRANSHUGE checks  (vbabka)
o Split out an unrelated change to its own patch(vbabka)
o Reordered series to put GFP flag modifications at start   (mhocko)
o Added a number of clarifications on reclaim modifications (mhocko)
o Only check cpusets when one exists that can limit memory  (rientjes)
o Applied acks

Changelog since V2
o Improve cpusets checks as suggested   (rientjes)
o Add various acks and reviewed-bys
o Rebase to 4.2-rc6

Changelog since V1
o Rebase to 4.2-rc5
o Distinguish between high priority callers and callers that avoid sleep
o Remove jump label related damage patches

Overall, the intent of this series is to remove the zonelist cache which
was introduced to avoid high overhead in the page allocator. Once this is
done, it is necessary to reduce the cost of watermark checks.

The series starts with minor micro-optimisations.

Next it notes that GFP flags that affect watermark checks are
bused. __GFP_WAIT historically identified callers that could not sleep and
could access reserves. This was later abused to identify callers that simply
prefer to avoid sleeping and have other options. A patch distinguishes
between atomic callers, high-priority callers and those that simply wish
to avoid sleep.

The zonelist cache has been around for a long time but it is of dubious
merit with a lot of complexity and some issues that are explained.
The most important issue is that a failed THP allocation can cause a
zone to be treated as full. This potentially causes unnecessary stalls,
reclaim activity or remote fallbacks. The issues could be fixed but it's
not worth it. The series places a small number of other micro-optimisations
on top before examining GFP flags watermarks.

High-order watermarks enforcement can cause high-order allocations to fail
even though pages are free. The watermark checks both protect high-order
atomic allocations and make kswapd aware of high-order pages but there is
a much better way that can be handled using migrate types. This series uses
page grouping by mobility to reserve pageblocks for high-order allocations
with the size of the reservation depending on demand. kswapd awareness
is maintained by examining the free lists. By patch 12 in this series,
there are no high-order watermark checks while preserving the properties
that motivated the introduction of the watermark checks.

 Documentation/vm/balance   |  14 +-
 arch/arm/mm/dma-mapping.c  |   4 +-
 arch/arm/xen/mm.c  |   2 +-
 arch/arm64/mm/dma-mapping.c|   4 +-
 arch/x86/kernel/pci-dma.c  |   2 +-
 block/bio.c|  26 +-
 block/blk-core.c   |  16 +-
 block/blk-ioc.c|   2 +-
 block/blk-mq-tag.c |   2 +-
 block/blk-mq.c |   8 +-
 block/cfq-iosched.c|   4 +-
 block/scsi_ioctl.c |   6 +-
 drivers/block/drbd/drbd_bitmap.c   |   2 +-
 drivers/block/drbd/drbd_receiver.c |   3 +-
 drivers/block/mtip32xx/mtip32xx.c  |   2 +-
 drivers/block/nvme-core.c  |   4 +-
 drivers/block/osdblk.c |   2 +-
 drivers/block/paride/pd.c  |   2 +-
 drivers/block/pktcdvd.c|   4 +-
 drivers/connector/connector.c  |   3 +-
 drivers/firewire/core-cdev.c   |   2 +-
 drivers/gpu/drm/i915/i915_gem.c|   4 +-
 drivers/ide/ide-atapi.c|   2 +-
 drivers/ide/ide-cd.c   |   2 +-
 drivers/ide/ide-cd_ioctl.c |   2 +-
 drivers/ide/ide-devsets.c  |   2 +-
 drivers/ide/ide-disk.c |   2 +-
 drivers/ide/ide-ioctls.c   |   4 +-
 drivers/ide/ide-park.c |   2 +-
 drivers/ide/ide-pm.c   |   4 +-
 drivers/ide/ide-tape.c |   4 +-
 drivers/ide/ide-taskfile.c |   4 +-
 drivers/infiniband/core/sa_query.c |   2 +-
 drivers/infiniband/hw/ipath/ipath_file_ops.c   |   2 +-
 drivers/infiniband/hw/qib/qib_init.c   |   2 +-
 drivers/iommu/amd_iommu.c  |   2 +-
 drivers/iommu/intel-iommu.c|   2 +-
 drivers/md/dm-crypt.c  |   6 +-
 drivers/md/dm-kcopyd.c |   2 +-
 

[PATCH 07/12] mm, page_alloc: Distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

2015-08-24 Thread Mel Gorman
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than min which can be referred
to as the atomic reserve. __GFP_HIGH users get access to the first lower
watermark and can be called the high priority reserve.

Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and are
willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify callers
that want to wake kswapd for background reclaim. __GFP_WAIT is redefined
as a caller that is willing to enter direct reclaim and wake kswapd for
background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress use
  __GFP_DIRECT_RECLAIM. bio allocations fall into this category where
  kswapd will still be woken but atomic reserves are not used as there
  is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
---
 Documentation/vm/balance   | 14 ---
 arch/arm/mm/dma-mapping.c  |  4 +-
 arch/arm/xen/mm.c  |  2 +-
 arch/arm64/mm/dma-mapping.c|  4 +-
 arch/x86/kernel/pci-dma.c  |  2 +-
 block/bio.c| 26 ++--
 block/blk-core.c   | 16 
 block/blk-ioc.c|  2 +-
 block/blk-mq-tag.c |  2 +-
 block/blk-mq.c |  8 ++--
 block/cfq-iosched.c|  4 +-
 drivers/block/drbd/drbd_receiver.c |  3 +-
 drivers/block/osdblk.c |  2 +-
 drivers/connector/connector.c  |  3 +-
 drivers/firewire/core-cdev.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem.c|  2 +-
 drivers/infiniband/core/sa_query.c |  2 +-
 drivers/iommu/amd_iommu.c  |  2 +-
 drivers/iommu/intel-iommu.c|  2 +-
 drivers/md/dm-crypt.c  |  6 +--
 drivers/md/dm-kcopyd.c |  2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c |  2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2.c |  2 +-
 drivers/media/pci/tw68/tw68-video.c|  2 +-
 drivers/mtd/mtdcore.c  |  3 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c|  2 +-
 drivers/staging/android/ion/ion_system_heap.c  |  2 +-
 .../lustre/include/linux/libcfs/libcfs_private.h   |  2 +-
 drivers/usb/host/u132-hcd.c|  2 +-
 drivers/video/fbdev/vermilion/vermilion.c  |  2 +-
 fs/btrfs/disk-io.c |  2 +-
 fs/btrfs/extent_io.c   | 14 +++
 fs/btrfs/volumes.c |  4 +-
 fs/ext3/super.c|  2 +-
 fs/ext4/super.c|  2 +-
 fs/fscache/cookie.c|  2 +-
 fs/fscache/page.c  |  6 +--
 fs/jbd/transaction.c   |  4 +-
 fs/jbd2/transaction.c  |  4 +-
 fs/nfs/file.c  |  6 +--
 fs/xfs/xfs_qm.c   

[PATCH 04/12] mm, page_alloc: Only check cpusets when one exists that can be mem-controlled

2015-08-24 Thread Mel Gorman
David Rientjes correctly pointed out that the root cpuset may not exclude
mems on the system so, even if mounted, there's no need to check or be
worried about concurrent change when there is only one cpuset.

The three checks for cpusets_enabled() care whether a cpuset exists that
can limit memory, not that cpuset is enabled as such. This patch replaces
cpusets_enabled() with cpusets_mems_enabled() which checks if at least one
cpuset exists that can limit memory and updates the appropriate call sites.

Signed-off-by: Mel Gorman mgor...@suse.de
---
 include/linux/cpuset.h | 16 +---
 mm/page_alloc.c|  2 +-
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 6eb27cb480b7..1e823870987e 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -17,10 +17,6 @@
 #ifdef CONFIG_CPUSETS
 
 extern struct static_key cpusets_enabled_key;
-static inline bool cpusets_enabled(void)
-{
-   return static_key_false(cpusets_enabled_key);
-}
 
 static inline int nr_cpusets(void)
 {
@@ -28,6 +24,12 @@ static inline int nr_cpusets(void)
return static_key_count(cpusets_enabled_key) + 1;
 }
 
+/* Returns true if a cpuset exists that can set cpuset.mems */
+static inline bool cpusets_mems_enabled(void)
+{
+   return nr_cpusets()  1;
+}
+
 static inline void cpuset_inc(void)
 {
static_key_slow_inc(cpusets_enabled_key);
@@ -104,7 +106,7 @@ extern void cpuset_print_task_mems_allowed(struct 
task_struct *p);
  */
 static inline unsigned int read_mems_allowed_begin(void)
 {
-   if (!cpusets_enabled())
+   if (!cpusets_mems_enabled())
return 0;
 
return read_seqcount_begin(current-mems_allowed_seq);
@@ -118,7 +120,7 @@ static inline unsigned int read_mems_allowed_begin(void)
  */
 static inline bool read_mems_allowed_retry(unsigned int seq)
 {
-   if (!cpusets_enabled())
+   if (!cpusets_mems_enabled())
return false;
 
return read_seqcount_retry(current-mems_allowed_seq, seq);
@@ -139,7 +141,7 @@ static inline void set_mems_allowed(nodemask_t nodemask)
 
 #else /* !CONFIG_CPUSETS */
 
-static inline bool cpusets_enabled(void) { return false; }
+static inline bool cpusets_mems_enabled(void) { return false; }
 
 static inline int cpuset_init(void) { return 0; }
 static inline void cpuset_init_smp(void) {}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 62ae28d8ae8d..2c1c3bf54d15 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2470,7 +2470,7 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int 
order, int alloc_flags,
if (IS_ENABLED(CONFIG_NUMA)  zlc_active 
!zlc_zone_worth_trying(zonelist, z, allowednodes))
continue;
-   if (cpusets_enabled() 
+   if (cpusets_mems_enabled() 
(alloc_flags  ALLOC_CPUSET) 
!cpuset_zone_allowed(zone, gfp_mask))
continue;
-- 
2.4.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/


[PATCH 05/12] mm, page_alloc: Remove unecessary recheck of nodemask

2015-08-24 Thread Mel Gorman
An allocation request will either use the given nodemask or the cpuset
current tasks mems_allowed. A cpuset retry will recheck the callers nodemask
and while it's trivial overhead during an extremely rare operation, also
unnecessary. This patch fixes it.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
---
 mm/page_alloc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2c1c3bf54d15..32d1cec124bc 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3171,7 +3171,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
gfp_t alloc_mask; /* The gfp_t that was actually used for allocation */
struct alloc_context ac = {
.high_zoneidx = gfp_zone(gfp_mask),
-   .nodemask = nodemask,
+   .nodemask = nodemask ? : cpuset_current_mems_allowed,
.migratetype = gfpflags_to_migratetype(gfp_mask),
};
 
@@ -3206,8 +3206,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
 
/* The preferred zone is used for statistics later */
preferred_zoneref = first_zones_zonelist(ac.zonelist, ac.high_zoneidx,
-   ac.nodemask ? : cpuset_current_mems_allowed,
-   ac.preferred_zone);
+   ac.nodemask, ac.preferred_zone);
if (!ac.preferred_zone)
goto out;
ac.classzone_idx = zonelist_zone_idx(preferred_zoneref);
-- 
2.4.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/


[PATCH 00/10] Add support for img AXD audio hardware decoder

2015-08-24 Thread Qais Yousef
This patch series adds AXD Alsa Compress Offload SoC driver.

AXD is an audio hardware based on MIPS architecture that supports decoding,
encoding, GEQ, resampling, mixing and synchronisation. At the moment only
decoding support is added in hope to add the rest of the functionality on
top of that once this is accepted.

I divided the files into separate patches by functionality in hope it'll
make the reviewing process easier. Worth noting that a lot of the cmd interface
helper funtions in patch 7 are not used yet but will be as support for more
functionality is added later.

At the moment this code has been tested on Pistachio SoC using gstreamer patched
with the code in this link

https://bugzilla.gnome.org/show_bug.cgi?id=743192

Qais Yousef (10):
  irqchip: irq-mips-gic: export gic_send_ipi
  dt: add img,axd.txt device tree binding document
  ALSA: add AXD Audio Processing IP alsa driver
  ALSA: axd: add fw binary header manipulation files
  ALSA: axd: add buffers manipulation files
  ALSA: axd: add basic files for sending/receiving axd cmds
  ALSA: axd: add cmd interface helper functions
  ALSA: axd: add low level AXD platform setup files
  ALSA: axd: add alsa compress offload operations
  ALSA: axd: add Makefile

 .../devicetree/bindings/sound/img,axd.txt  |   34 +
 drivers/irqchip/irq-mips-gic.c |1 +
 sound/soc/Kconfig  |1 +
 sound/soc/Makefile |1 +
 sound/soc/img/Kconfig  |   11 +
 sound/soc/img/Makefile |1 +
 sound/soc/img/axd/Makefile |   13 +
 sound/soc/img/axd/axd_alsa_ops.c   |  211 ++
 sound/soc/img/axd/axd_api.h|  649 
 sound/soc/img/axd/axd_buffers.c|  243 ++
 sound/soc/img/axd/axd_buffers.h|   74 +
 sound/soc/img/axd/axd_cmds.c   |  102 +
 sound/soc/img/axd/axd_cmds.h   |  532 
 sound/soc/img/axd/axd_cmds_config.c| 1235 
 sound/soc/img/axd/axd_cmds_decoder_config.c|  422 +++
 sound/soc/img/axd/axd_cmds_info.c  | 1249 
 sound/soc/img/axd/axd_cmds_internal.c  | 3264 
 sound/soc/img/axd/axd_cmds_internal.h  |  317 ++
 sound/soc/img/axd/axd_cmds_pipes.c | 1387 +
 sound/soc/img/axd/axd_hdr.c|   64 +
 sound/soc/img/axd/axd_hdr.h|   24 +
 sound/soc/img/axd/axd_module.c |  742 +
 sound/soc/img/axd/axd_module.h |   83 +
 sound/soc/img/axd/axd_platform.h   |   35 +
 sound/soc/img/axd/axd_platform_mips.c  |  416 +++
 25 files changed, 1 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/img,axd.txt
 create mode 100644 sound/soc/img/Kconfig
 create mode 100644 sound/soc/img/Makefile
 create mode 100644 sound/soc/img/axd/Makefile
 create mode 100644 sound/soc/img/axd/axd_alsa_ops.c
 create mode 100644 sound/soc/img/axd/axd_api.h
 create mode 100644 sound/soc/img/axd/axd_buffers.c
 create mode 100644 sound/soc/img/axd/axd_buffers.h
 create mode 100644 sound/soc/img/axd/axd_cmds.c
 create mode 100644 sound/soc/img/axd/axd_cmds.h
 create mode 100644 sound/soc/img/axd/axd_cmds_config.c
 create mode 100644 sound/soc/img/axd/axd_cmds_decoder_config.c
 create mode 100644 sound/soc/img/axd/axd_cmds_info.c
 create mode 100644 sound/soc/img/axd/axd_cmds_internal.c
 create mode 100644 sound/soc/img/axd/axd_cmds_internal.h
 create mode 100644 sound/soc/img/axd/axd_cmds_pipes.c
 create mode 100644 sound/soc/img/axd/axd_hdr.c
 create mode 100644 sound/soc/img/axd/axd_hdr.h
 create mode 100644 sound/soc/img/axd/axd_module.c
 create mode 100644 sound/soc/img/axd/axd_module.h
 create mode 100644 sound/soc/img/axd/axd_platform.h
 create mode 100644 sound/soc/img/axd/axd_platform_mips.c

Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
-- 
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 02/10] dt: add img,axd.txt device tree binding document

2015-08-24 Thread Qais Yousef
Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 .../devicetree/bindings/sound/img,axd.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/img,axd.txt

diff --git a/Documentation/devicetree/bindings/sound/img,axd.txt 
b/Documentation/devicetree/bindings/sound/img,axd.txt
new file mode 100644
index ..6a8764a79d01
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/img,axd.txt
@@ -0,0 +1,34 @@
+* AXD Audio Processing IP Binding *
+
+Required properties:
+- compatible: img,axd
+- clocks: phandle for the clock that drives AXD.
+- interrupts: the GIC interrupt where AXD is connected
+- gic-irq: it takes two non-zero values, the first one is the host hwirq and
+   the second one is AXD's. Host's hwirq should match the value in
+   interrupts.
+
+Optional properties:
+- vpe: VPE number on which AXD should start. Must be provided if AXD is
+   running as a single VPE along Linux on the same core.
+   It can't be VPE0.
+   The VPE will be offlined before AXD is loaded.
+- inbuf-size: size of shared input buffers area. By default it's 0x7800 bytes.
+- outbuf-size: size of shared output buffers area. By default it's 0x3c000 
bytes.
+
+
+Example:
+
+   axdclk: axdclk@400M {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 4;
+   };
+
+   axd {
+   compatible = img,axd;
+   clocks = axdclk;
+   interrupts = 36 IRQ_TYPE_EDGE_RISING;
+   gic-irq = 36 37;
+   vpe = 1;
+   };
-- 
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 01/10] irqchip: irq-mips-gic: export gic_send_ipi

2015-08-24 Thread Qais Yousef
Some drivers might require to send ipi to other cores. So export it.
This will be used later by AXD driver.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
 drivers/irqchip/irq-mips-gic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index ff4be0515a0d..fc6fd506cd7e 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -227,6 +227,7 @@ void gic_send_ipi(unsigned int intr)
 {
gic_write(GIC_REG(SHARED, GIC_SH_WEDGE), GIC_SH_WEDGE_SET(intr));
 }
+EXPORT_SYMBOL(gic_send_ipi);
 
 int gic_get_c0_compare_int(void)
 {
-- 
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 v2] watchdog: sunxi: fix activation of system reset

2015-08-24 Thread Guenter Roeck

On 08/24/2015 02:25 AM, Chen-Yu Tsai wrote:

Hi,

On Mon, Jul 27, 2015 at 3:32 AM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:

On Sat, Jul 25, 2015 at 08:25:18AM +0200, Francesco Lavra wrote:

Commit f2147de33470 (watchdog: sunxi: support parameterized compatible
strings) introduced a regression in sunxi_wdt_start(), by which
the system reset function of the watchdog is not enabled upon
starting the watchdog. As a result, the system is not reset when the
watchdog expires. Fix it.

Signed-off-by: Francesco Lavra francescolavra...@gmail.com
Reviewed-by: Guenter Roeck li...@roeck-us.net
Fixes: f2147de33470 (watchdog: sunxi: support parameterized compatible 
strings)
Cc: sta...@vger.kernel.org


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


What tree should this go in through?
Guenter, are you still taking watchdog patches?



The patch is included in the pull request I sent to Wim last week [1].

Guenter

---
[1] http://www.spinics.net/lists/linux-watchdog/msg07219.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] staging: fbtft: Removed a space before comma

2015-08-24 Thread Sudip Mukherjee
On Thu, Aug 20, 2015 at 08:57:57PM +0530, Aparna Karuthodi wrote:
 Removed a space before coma to remove a coding style error detected by
 checkpatch.
 The error is given below:
 drivers/staging/fbtft/fb_ili9340.c:47: ERROR: space prohibited before
 that ',' (ctx:WxW)
 
 Signed-off-by: Aparna Karuthodi kdasapa...@gmail.com
 ---
I think you need to update your tree. This has already been done by:
43da0d92ab7d (staging: fbtft: fix space prohibited before that ',')

regards
sudip
--
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 v4 05/13] usb: hcd.h: Add OTG to HCD interface

2015-08-24 Thread Roger Quadros
The OTG core will use struct otg_hcd_ops to
add/remove the HCD controller.

The main purpose of this interface is to avoid directly
calling usb_add/remove_hcd() from the OTG core as they
wouldn't be defined in the built-in symbol table if
CONFIG_USB is m.

Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Peter Chen peter.c...@freescale.com
---
 include/linux/usb/hcd.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index d2784c1..27d78b1 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -386,6 +386,20 @@ struct hc_driver {
 
 };
 
+/**
+ * struct otg_hcd_ops - Interface between OTG core and HCD
+ *
+ * Provided by the HCD core to allow the OTG core to start/stop the HCD
+ *
+ * @add: function to add the HCD
+ * @remove: function to remove the HCD
+ */
+struct otg_hcd_ops {
+   int (*add)(struct usb_hcd *hcd,
+  unsigned int irqnum, unsigned long irqflags);
+   void (*remove)(struct usb_hcd *hcd);
+};
+
 static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
 {
return hcd-driver-flags  HCD_BH;
-- 
2.1.4

--
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 v4 02/13] usb: otg-fsm: support multiple instances

2015-08-24 Thread Roger Quadros
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/common/usb-otg-fsm.c | 10 --
 include/linux/usb/otg-fsm.h  |  1 +
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 61d538a..32862a4 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -61,8 +61,6 @@ static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
return 0;
 }
 
-static int state_changed;
-
 /* Called when leaving a state.  Do state clean up jobs here */
 static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state old_state)
 {
@@ -123,7 +121,6 @@ static void otg_leave_state(struct otg_fsm *fsm, enum 
usb_otg_state old_state)
 /* Called when entering a state */
 static int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
 {
-   state_changed = 1;
if (fsm-otg-state == new_state)
return 0;
VDBG(Set state: %s\n, usb_otg_state_string(new_state));
@@ -237,6 +234,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
}
 
fsm-otg-state = new_state;
+   fsm-state_changed = 1;
return 0;
 }
 
@@ -248,7 +246,7 @@ int otg_statemachine(struct otg_fsm *fsm)
mutex_lock(fsm-lock);
 
state = fsm-otg-state;
-   state_changed = 0;
+   fsm-state_changed = 0;
/* State machine state change judgement */
 
switch (state) {
@@ -361,7 +359,7 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
 
-   VDBG(quit statemachine, changed = %d\n, state_changed);
-   return state_changed;
+   VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+   return fsm-state_changed;
 }
 EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index fc5b4d9..20c8219 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -195,6 +195,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+   bool state_changed;
 };
 
 struct otg_fsm_ops {
-- 
2.1.4

--
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 v4 04/13] otg-fsm: move usb_bus_start_enum into otg-fsm-ops

2015-08-24 Thread Roger Quadros
This is to prevent missing symbol build error if OTG is
enabled (built-in) and HCD core (CONFIG_USB) is module.

Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/common/usb-otg-fsm.c | 6 --
 drivers/usb/phy/phy-fsl-usb.c| 2 ++
 include/linux/usb/otg-fsm.h  | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index a46f29a..6e56c8c 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -165,8 +165,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
otg_loc_conn(fsm, 0);
otg_loc_sof(fsm, 1);
otg_set_protocol(fsm, PROTO_HOST);
-   usb_bus_start_enum(fsm-otg-host,
-   fsm-otg-host-otg_port);
+   if (fsm-ops-start_enum) {
+   fsm-ops-start_enum(fsm-otg-host,
+fsm-otg-host-otg_port);
+   }
break;
case OTG_STATE_A_IDLE:
otg_drv_vbus(fsm, 0);
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index ee3f2c2..19541ed 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
 
.start_host = fsl_otg_start_host,
.start_gadget = fsl_otg_start_gadget,
+
+   .start_enum = usb_bus_start_enum,
 };
 
 /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 672551c..75e82cc 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -199,6 +199,7 @@ struct otg_fsm_ops {
void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
int (*start_host)(struct otg_fsm *fsm, int on);
int (*start_gadget)(struct otg_fsm *fsm, int on);
+   int (*start_enum)(struct usb_bus *bus, unsigned port_num);
 };
 
 
-- 
2.1.4

--
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 v4 03/13] usb: otg-fsm: Prevent build warning VDBG redefined

2015-08-24 Thread Roger Quadros
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].

Prevent that by using dev_vdbg() instead.

Also get rid of MPC_LOC which doesn't seem to be used
by anyone.

[1] - warning fixed by this patch:

   In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
   include/linux/usb/otg-fsm.h:30:1: warning: VDBG redefined
   In file included from drivers/usb/dwc3/ep0.c:31:
   include/linux/usb/composite.h:615:1: warning: this is the location
of the previous definition

Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/otg_fsm.c   |  1 +
 drivers/usb/common/usb-otg-fsm.c | 12 +++-
 drivers/usb/phy/phy-fsl-usb.c|  1 +
 include/linux/usb/otg-fsm.h  | 19 ---
 4 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 00ab59d..f644752 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -776,6 +776,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
ci-fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
ci-fsm.otg-state = OTG_STATE_UNDEFINED;
ci-fsm.ops = ci_otg_ops;
+   ci-fsm.dev = ci-dev;
 
mutex_init(ci-fsm.lock);
 
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 32862a4..a46f29a 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -36,8 +36,9 @@ static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
int ret = 0;
 
if (fsm-protocol != protocol) {
-   VDBG(Changing role fsm-protocol= %d; new protocol= %d\n,
-   fsm-protocol, protocol);
+   dev_vdbg(fsm-dev,
+Changing role fsm-protocol= %d; new protocol= %d\n,
+fsm-protocol, protocol);
/* stop old protocol */
if (fsm-protocol == PROTO_HOST)
ret = otg_start_host(fsm, 0);
@@ -123,7 +124,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
 {
if (fsm-otg-state == new_state)
return 0;
-   VDBG(Set state: %s\n, usb_otg_state_string(new_state));
+   dev_vdbg(fsm-dev, Set state: %s\n, usb_otg_state_string(new_state));
otg_leave_state(fsm, fsm-otg-state);
switch (new_state) {
case OTG_STATE_B_IDLE:
@@ -251,7 +252,7 @@ int otg_statemachine(struct otg_fsm *fsm)
 
switch (state) {
case OTG_STATE_UNDEFINED:
-   VDBG(fsm-id = %d\n, fsm-id);
+   dev_vdbg(fsm-dev, fsm-id = %d\n, fsm-id);
if (fsm-id)
otg_set_state(fsm, OTG_STATE_B_IDLE);
else
@@ -359,7 +360,8 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
 
-   VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+   dev_vdbg(fsm-dev, quit statemachine, changed = %d\n,
+fsm-state_changed);
return fsm-state_changed;
 }
 EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 94eb292..ee3f2c2 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -817,6 +817,7 @@ static int fsl_otg_conf(struct platform_device *pdev)
 
/* Set OTG state machine operations */
fsl_otg_tc-fsm.ops = fsl_otg_ops;
+   fsl_otg_tc-fsm.dev = pdev-dev;
 
/* initialize the otg structure */
fsl_otg_tc-phy.label = DRIVER_DESC;
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 20c8219..672551c 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -18,24 +18,10 @@
 #ifndef __LINUX_USB_OTG_FSM_H
 #define __LINUX_USB_OTG_FSM_H
 
+#include linux/device.h
 #include linux/mutex.h
 #include linux/errno.h
 
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug([%s]   fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk(Current Location [%s]:[%d]\n, __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
 #define PROTO_UNDEF(0)
 #define PROTO_HOST (1)
 #define PROTO_GADGET   (2)
@@ -196,6 +182,9 @@ struct otg_fsm {
int protocol;
struct mutex lock;
bool state_changed;
+
+   /* for debug prints */
+   struct device *dev;
 };
 
 struct otg_fsm_ops {
-- 
2.1.4

--
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 v4 00/13] USB: OTG/DRD Core functionality

2015-08-24 Thread Roger Quadros
Hi,

This series centralizes OTG/Dual-role functionality in the kernel.
As of now I've got Dual-role functionality working pretty reliably on
dra7-evm and am437x-gp-evm.

DWC3 controller and platform related patches will be sent separately.

Series is based on Greg's usb-next tree.

Changelog:
-
v4:
- Added DT support for tying otg-controller to host and gadget
 controllers. For DT we no longer have the constraint that
 OTG controller needs to be parent of host and gadget. They can be
 tied together using the otg-controller property.
- Relax the requirement for DT case that otg controller must register before
 host/gadget. We maintain a wait list of host/gadget devices
 waiting on the otg controller.
- Use a single struct usb_otg for otg data.
- Don't override host/gadget start/stop APIs. Let the controller
 drivers do what they want as they know best. Helper API is provided
 for controller start/stop that controller driver can use.
- Introduce struct usb_otg_config to pass the otg capabilities,
 otg ops and otg timer timeouts during otg controller registration.
- rebased on Greg's usb.git/usb-next

v3:
- all otg related definations now in otg.h
- single kernel config USB_OTG to enable OTG core and FSM.
- resolved symbol dependency issues.
- use dev_vdbg instead of VDBG() in usb-otg-fsm.c
- rebased on v4.2-rc1

v2:
- Use add/remove_hcd() instead of start/stop_hcd() to enable/disable
 the host controller
- added dual-role-device (DRD) state machine which is a much simpler
 mode of operation when compared to OTG. Here we don't support fancy
 OTG features like HNP, SRP, on the fly role-swap. The mode of operation
 is determined based on ID pin (cable type) and the role doesn't change
 till the cable type changes.

Why?:


Most of the OTG drivers have been dealing with the OTG state machine
themselves and there is a scope for code re-use. This has been
partly addressed by the usb/common/usb-otg-fsm.c but it still
leaves the instantiation of the state machine and OTG timers
to the controller drivers. We re-use usb-otg-fsm.c but
go one step further by instantiating the state machine and timers
thus making it easier for drivers to implement OTG functionality.

Newer OTG cores support standard host interface (e.g. xHCI) so
host and gadget functionality are no longer closely knit like older
cores. There needs to be a way to co-ordinate the operation of the
host and gadget in OTG mode. i.e. to stop and start them from a
central location. This central location should be the USB OTG core.

Host and gadget controllers might be sharing resources and can't
be always running. One has to be stopped for the other to run.
This can't be done as of now and can be done from the OTG core.

What?:
-

The OTG core instantiates the OTG/DRD Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.

It provides APIs for the following

- Registering an OTG capable controller
struct otg_fsm *usb_otg_register(struct device *dev,
 struct usb_otg_config *config);

int usb_otg_unregister(struct device *dev);

- Registering Host controllers to OTG core (used by hcd-core)
int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
 unsigned long irqflags, struct otg_hcd_ops *ops);
int usb_otg_unregister_hcd(struct usb_hcd *hcd);


- Registering Gadget controllers to OTG core (used by udc-core)
int usb_otg_register_gadget(struct usb_gadget *gadget,
struct otg_gadget_ops *ops);
int usb_otg_unregister_gadget(struct usb_gadget *gadget);


- Providing inputs to and kicking the OTG state machine
void usb_otg_sync_inputs(struct otg_fsm *fsm);
int usb_otg_kick_fsm(struct device *hcd_gcd_device);

- Getting controller device structure from OTG state machine instance
struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm);

'struct otg_fsm' is the interface to the OTG state machine.
It contains inputs to the fsm, status of the fsm and operations
for the OTG controller driver.

- Helper APIs for starting/stopping host/gadget controllers
int usb_otg_start_host(struct otg_fsm *fsm, int on);
int usb_otg_start_gadget(struct otg_fsm *fsm, int on);

Usage model:
---

- The OTG core needs to know what host and gadget controllers are
linked to the OTG controller. For DT boots we can provide that
information by adding otg-controller property to the host and
gadget controller nodes that points to the right otg controller.
For legacy boot we assume that OTG controller is the parent
of the host and gadget controllers. For DT if otg-controller
property is not present then parent child relationship constraint
applies.

- The OTG controller driver must call usb_otg_register() to register
itself with the OTG core. It must also provide the required
OTG configuration, fsm operations and timer timeouts (optional)
via struct usb_otg_config. The fsm operations will be called
depending 

[PATCH v4 01/13] usb: otg-fsm: Add documentation for struct otg_fsm

2015-08-24 Thread Roger Quadros
struct otg_fsm is the interface to the OTG state machine.

Document the input, output and internal state variables.
Definations are taken from Table 7-2 and Table 7-4 of
the USB OTG  EH Specification Rev.2.0

Re-arrange some of the members as per use case for more
clarity.

Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Peter Chen peter.c...@freescale.com
---
 include/linux/usb/otg-fsm.h | 90 +
 1 file changed, 83 insertions(+), 7 deletions(-)

diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index f728f18..fc5b4d9 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -59,37 +59,113 @@ enum otg_fsm_timer {
NUM_OTG_FSM_TIMERS,
 };
 
-/* OTG state machine according to the OTG spec */
+/**
+ * struct otg_fsm - OTG state machine according to the OTG spec
+ *
+ * OTG hardware Inputs
+ *
+ * Common inputs for A and B device
+ * @id:TRUE for B-device, FALSE for A-device.
+ * @adp_change: TRUE when current ADP measurement (n) value, compared to the
+ * ADP measurement taken at n-2, differs by more than CADP_THR
+ * @power_up:  TRUE when the OTG device first powers up its USB system and
+ * ADP measurement taken if ADP capable
+ *
+ * A-Device state inputs
+ * @a_srp_det: TRUE if the A-device detects SRP
+ * @a_vbus_vld:TRUE when VBUS voltage is in regulation
+ * @b_conn:TRUE if the A-device detects connection from the B-device
+ * @a_bus_resume: TRUE when the B-device detects that the A-device is signaling
+ *   a resume (K state)
+ * B-Device state inputs
+ * @a_bus_suspend: TRUE when the B-device detects that the A-device has put the
+ * bus into suspend
+ * @a_conn:TRUE if the B-device detects a connection from the A-device
+ * @b_se0_srp: TRUE when the line has been at SE0 for more than the minimum
+ * time before generating SRP
+ * @b_ssend_srp: TRUE when the VBUS has been below VOTG_SESS_VLD for more than
+ *  the minimum time before generating SRP
+ * @b_sess_vld:TRUE when the B-device detects that the voltage on VBUS 
is
+ * above VOTG_SESS_VLD
+ * @test_device: TRUE when the B-device switches to B-Host and detects an OTG
+ * test device. This must be set by host/hub driver
+ *
+ * Application inputs (A-Device)
+ * @a_bus_drop:TRUE when A-device application needs to power down the 
bus
+ * @a_bus_req: TRUE when A-device application wants to use the bus.
+ * FALSE to suspend the bus
+ *
+ * Application inputs (B-Device)
+ * @b_bus_req: TRUE during the time that the Application running on the
+ * B-device wants to use the bus
+ *
+ * Auxilary inputs (OTG v1.3 only. Obsolete now.)
+ * @a_sess_vld:TRUE if the A-device detects that VBUS is above 
VA_SESS_VLD
+ * @b_bus_suspend: TRUE when the A-device detects that the B-device has put
+ * the bus into suspend
+ * @b_bus_resume: TRUE when the A-device detects that the B-device is signaling
+ *  resume on the bus
+ *
+ * OTG Output status. Read only for users. Updated by OTG FSM helpers defined
+ * in this file
+ *
+ * Outputs for Both A and B device
+ * @drv_vbus:  TRUE when A-device is driving VBUS
+ * @loc_conn:  TRUE when the local device has signaled that it is connected
+ * to the bus
+ * @loc_sof:   TRUE when the local device is generating activity on the bus
+ * @adp_prb:   TRUE when the local device is in the process of doing
+ * ADP probing
+ *
+ * Outputs for B-device state
+ * @adp_sns:   TRUE when the B-device is in the process of carrying out
+ * ADP sensing
+ * @data_pulse: TRUE when the B-device is performing data line pulsing
+ *
+ * Internal Variables
+ *
+ * a_set_b_hnp_en: TRUE when the A-device has successfully set the
+ * b_hnp_enable bit in the B-device.
+ *Unused as OTG fsm uses otg-host-b_hnp_enable instead
+ * b_srp_done: TRUE when the B-device has completed initiating SRP
+ * b_hnp_enable: TRUE when the B-device has accepted the
+ * SetFeature(b_hnp_enable) B-device.
+ * Unused as OTG fsm uses otg-gadget-b_hnp_enable instead
+ * a_clr_err:  Asserted (by application ?) to clear a_vbus_err due to an
+ * overcurrent condition and causes the A-device to transition
+ * to a_wait_vfall
+ */
 struct otg_fsm {
/* Input */
int id;
int adp_change;
int power_up;
-   int test_device;
-   int a_bus_drop;
-   int a_bus_req;
int a_srp_det;
int a_vbus_vld;
int b_conn;
int a_bus_resume;
int a_bus_suspend;
int a_conn;
-   int b_bus_req;
int b_se0_srp;
int b_ssend_srp;
int b_sess_vld;
+   int test_device;
+   int a_bus_drop;
+   int a_bus_req;
+   int b_bus_req;
+
/* 

Re: [PATCH 1/1] of: to support binding numa node to root subnode(non-bus)

2015-08-24 Thread Rob Herring
+benh

On Mon, Aug 24, 2015 at 7:30 AM, Zhen Lei thunder.leiz...@huawei.com wrote:
 If use of_platform_populate to scan dt-nodes and add devices, the
 subnode of root(such as /smmu), when being scanned and invoke

You should have a bus as the sub-node of root rather than devices
directly off of root. You still have a problem though...

 of_device_add, the ofdev-dev.parent is always equal platform_bus. So
 that, function set_dev_node will not be called. And in device_add,
 dev_to_node(parent) always return NUMA_NO_NODE.

 Signed-off-by: Zhen Lei thunder.leiz...@huawei.com
 ---
  drivers/base/core.c | 2 +-
  drivers/of/device.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/base/core.c b/drivers/base/core.c
 index dafae6d..5df4f46b 100644
 --- a/drivers/base/core.c
 +++ b/drivers/base/core.c
 @@ -1017,7 +1017,7 @@ int device_add(struct device *dev)
 dev-kobj.parent = kobj;

 /* use parent numa_node */
 -   if (parent)
 +   if (parent  (parent != platform_bus))

This is only fixing one specific case, but I think things are broken
for any case where the NUMA associativity if not set at the top level
bus node. I think this should be something like:

if (parent  (dev_to_node(dev) != NO_NUMA_NODE))

Then the OF code can set the node however it wants.

 set_dev_node(dev, dev_to_node(parent));

 /* first, register with generic layer. */
 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 8b91ea2..96ebece 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -63,7 +63,7 @@ int of_device_add(struct platform_device *ofdev)
 /* device_add will assume that this device is on the same node as
  * the parent. If there is no parent defined, set the node
  * explicitly */
 -   if (!ofdev-dev.parent)
 +   if (!ofdev-dev.parent || (ofdev-dev.parent == platform_bus))

And then remove the if here.

 set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node));

 return device_add(ofdev-dev);
 --
 2.5.0


 --
 To unsubscribe from this list: send the line unsubscribe devicetree in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.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 3/3 v4] mm/vmalloc: Cache the vmalloc memory info

2015-08-24 Thread John Stoffel
 Ingo == Ingo Molnar mi...@kernel.org writes:

Ingo * George Spelvin li...@horizon.com wrote:

 First, an actual, albeit minor, bug: initializing both vmap_info_gen
 and vmap_info_cache_gen to 0 marks the cache as valid, which it's not.

Ingo Ha! :-) Fixed.

 vmap_info_gen should be initialized to 1 to force an initial
 cache update.

Blech, it should be initialized with a proper #define
VMAP_CACHE_NEEDS_UPDATE 1, instead of more magic numbers.


Ingo + */
Ingo +static DEFINE_SPINLOCK(vmap_info_lock);
Ingo +static int vmap_info_gen = 1;

   static int vmap_info_gen = VMAP_CACHE_NEEDS_UPDATE;

Ingo +static int vmap_info_cache_gen;
Ingo +static struct vmalloc_info vmap_info_cache;
Ingo +#endif


This will help keep bugs like this out in the future... I hope!
--
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: [RESEND PATCH] clk: rockchip: disable init state before mmc card initialization

2015-08-24 Thread Shawn Lin

On 2015/8/24 18:01, Heiko Stuebner wrote:

Hi Shawn,

Am Montag, 24. August 2015, 16:27:43 schrieb Shawn Lin:

mmc host controller's IO input/output timing is unpredictable if
bootloader execute tuning for HS200 mode. It might make kernel failed
to initialize mmc card in identification mode. The root cause is
tuning phase and degree setting for HS200 mode in bootloader aren't
applicable to that of identification mode in kernel stage. Anyway, we
can't force all bootloaders to disable tuning phase and degree setting
before into kernel. Simply disable it in rockchip_clk_register_mmc.

Signed-off-by: Shawn Lin shawn@rock-chips.com

---

  drivers/clk/rockchip/clk-mmc-phase.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/drivers/clk/rockchip/clk-mmc-phase.c
b/drivers/clk/rockchip/clk-mmc-phase.c index e9f8df32..ae21592 100644
--- a/drivers/clk/rockchip/clk-mmc-phase.c
+++ b/drivers/clk/rockchip/clk-mmc-phase.c
@@ -38,6 +38,9 @@ static unsigned long rockchip_mmc_recalc(struct clk_hw
*hw, #define ROCKCHIP_MMC_DEGREE_MASK 0x3
  #define ROCKCHIP_MMC_DELAYNUM_OFFSET 2
  #define ROCKCHIP_MMC_DELAYNUM_MASK (0xff  ROCKCHIP_MMC_DELAYNUM_OFFSET)
+#define ROCKCHIP_MMC_INIT_STATE_DISABLE (0x1)
+#define ROCKCHIP_MMC_INIT_STATE_SHIFT (1)
+#define ROCKCHIP_MMC_INIT_STATE_MASK  (0x1)


you don't need the () around primitive values. Also I don't think you need
the second MASK attribute, doing
writel(HIWORD_UPDATE(ROCKCHIP_MMC_INIT_STATE_DISABLE,
 ROCKCHIP_MMC_INIT_STATE_DISABLE,
 mmc_clock-shift),

should be enough. And thirdly I'm undecided about the naming of the constant.
The manual describes the init_state as Assert init_state to soft reset the
CLKGEN., so I guess I'd prefer

ROCKCHIP_MMC_INIT_STATE_RESET


Thanks, Heiko.

Actually, I'm either not so sure how to naming this bit since if we are 
used to calling a bit, reset bit, which I thought it should at least do 
some reset either to state machine or to register value. But obvious it 
doesn't. Moreover, Assert/Dis-assert seems like disable/enable from my 
point. Anyway, ROCKCHIP_MMC_INIT_STATE_RESET is okay for me, but I think 
I should add some comments for these code.




or so



  #define PSECS_PER_SEC 1LL

@@ -119,6 +122,21 @@ static const struct clk_ops rockchip_mmc_clk_ops = {
.set_phase  = rockchip_mmc_set_phase,
  };

+static void rockchip_clk_mmc_disable_init(struct rockchip_mmc_clock


I guess similar to the thoughts above, simply name this
rockchip_clk_mmc_reset()

or alternatively just do the reset in rockchip_clk_register_mmc directly:

if (mmc_clock-shift == ROCKCHIP_MMC_INIT_STATE_SHIFT))
writel(HIWORD_UPDATE(ROCKCHIP_MMC_INIT_STATE_DISABLE,
 ROCKCHIP_MMC_INIT_STATE_MASK,
 mmc_clock-shift),
   mmc_clock-reg);

as the pr_debug does not really serve a purpose.



Okay, rockchip_clk_mmc_reset is coming in v2 :)



Heiko


*mmc_clock) +{
+   if (mmc_clock-shift != ROCKCHIP_MMC_INIT_STATE_SHIFT)
+   return;
+
+   writel(HIWORD_UPDATE(ROCKCHIP_MMC_INIT_STATE_DISABLE,
+ROCKCHIP_MMC_INIT_STATE_MASK,
+mmc_clock-shift),
+  mmc_clock-reg);
+
+   pr_debug(%s: clear mmc init state to %d, __func__,
+(readl(mmc_clock-reg)  (mmc_clock-shift)) 
+ROCKCHIP_MMC_INIT_STATE_MASK);
+}
+
  struct clk *rockchip_clk_register_mmc(const char *name,
const char *const *parent_names, u8 num_parents,
void __iomem *reg, int shift)
@@ -139,6 +157,8 @@ struct clk *rockchip_clk_register_mmc(const char *name,
mmc_clock-reg = reg;
mmc_clock-shift = shift;

+   rockchip_clk_mmc_disable_init(mmc_clock);
+
if (name)
init.name = name;








--
Best Regards
Shawn Lin

--
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] arm: Handle starting up in secure mode

2015-08-24 Thread Christopher Covington
ARM Linux appears to have never been made aware of the ARMv7 security
extensions. When CONFIG_ARM_SEC_EXT=y, have it probe for its security
state by checking whether CNTFRQ is writeable and potentially make
mode changes based on the information. The most features are available
from hypervisor (HYP) mode, so switch to it possible. Failing that,
prefer non-secure supervisor (SVC) mode to secure supervisor mode.

Signed-off-by: Christopher Covington c...@codeaurora.org
---
 arch/arm/include/asm/sec.h |  27 +++
 arch/arm/include/uapi/asm/ptrace.h |   1 +
 arch/arm/kernel/Makefile   |   1 +
 arch/arm/kernel/head.S |   3 +
 arch/arm/kernel/mon-stub.S | 158 +
 arch/arm/mm/Kconfig|  20 -
 6 files changed, 206 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/sec.h
 create mode 100644 arch/arm/kernel/mon-stub.S

diff --git a/arch/arm/include/asm/sec.h b/arch/arm/include/asm/sec.h
new file mode 100644
index 000..4a9a573
--- /dev/null
+++ b/arch/arm/include/asm/sec.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef SEC_H
+#define SEC_H
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARM_SEC_EXT
+extern int __boot_cpu_secure;
+#else
+#define __boot_cpu_secure 0
+#endif
+
+#endif /* ! __ASSEMBLY__ */
+
+#endif /* SEC_H */
diff --git a/arch/arm/include/uapi/asm/ptrace.h 
b/arch/arm/include/uapi/asm/ptrace.h
index 5af0ed1..70ff6bf 100644
--- a/arch/arm/include/uapi/asm/ptrace.h
+++ b/arch/arm/include/uapi/asm/ptrace.h
@@ -53,6 +53,7 @@
 #endif
 #define FIQ_MODE   0x0011
 #define IRQ_MODE   0x0012
+#define MON_MODE   0x0016
 #define ABT_MODE   0x0017
 #define HYP_MODE   0x001a
 #define UND_MODE   0x001b
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index e69f7a1..a60a0f7 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -87,6 +87,7 @@ head-y:= head$(MMUEXT).o
 obj-$(CONFIG_DEBUG_LL) += debug.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
+obj-$(CONFIG_ARM_SEC_EXT)  += mon-stub.o
 obj-$(CONFIG_ARM_VIRT_EXT) += hyp-stub.o
 ifeq ($(CONFIG_ARM_PSCI),y)
 obj-y  += psci.o psci-call.o
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 29e2991..d137ba4 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -85,6 +85,9 @@ ENTRY(stext)
  THUMB(.thumb  )   @ switch to Thumb now.
  THUMB(1:  )
 
+#ifdef CONFIG_ARM_SEC_EXT
+   bl  __mon_stub_install
+#endif
 #ifdef CONFIG_ARM_VIRT_EXT
bl  __hyp_stub_install
 #endif
diff --git a/arch/arm/kernel/mon-stub.S b/arch/arm/kernel/mon-stub.S
new file mode 100644
index 000..ab1a361
--- /dev/null
+++ b/arch/arm/kernel/mon-stub.S
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/linkage.h
+#include asm/assembler.h
+#include asm/sec.h
+
+.data
+ENTRY(__boot_cpu_secure)
+   .long   0
+.text
+
+/*
+ * ARM Linux has the most features available in hypervisor mode and
+ * running in non-secure mode is recommended. Thus, try to get into
+ * hypervisor mode if we're not already there, or failing that, try
+ * to get into non-secure supervisor mode.
+ */
+ENTRY(__mon_stub_install)
+   /*
+* Store the mode field of the CPSR in r4 and return early if we're
+* already in hypervisor mode.
+*/
+   mrs r4, cpsr
+   and r4, r4, #MODE_MASK
+   cmp r4, #HYP_MODE
+   reteq   lr
+
+   /*
+* Save the link register in a non-banked register, r5, so that we
+* still have access to it after mode switches.
+*/
+   mov r5, lr
+
+   /*
+* Read ID_PFR1 and store the value in r6. This register indicates
+* the presence of the security and virtualization extensions. The
+* former is interesting because we must 

[PATCH 03/12] mm, page_alloc: Remove unnecessary taking of a seqlock when cpusets are disabled

2015-08-24 Thread Mel Gorman
There is a seqcounter that protects against spurious allocation failures
when a task is changing the allowed nodes in a cpuset. There is no need
to check the seqcounter until a cpuset exists.

Signed-off-by: Mel Gorman mgor...@techsingularity.net
Acked-by: Christoph Lameter c...@linux.com
Acked-by: David Rientjes rient...@google.com
Acked-by: Vlastimil Babka vba...@suse.cz
---
 include/linux/cpuset.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 1b357997cac5..6eb27cb480b7 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -104,6 +104,9 @@ extern void cpuset_print_task_mems_allowed(struct 
task_struct *p);
  */
 static inline unsigned int read_mems_allowed_begin(void)
 {
+   if (!cpusets_enabled())
+   return 0;
+
return read_seqcount_begin(current-mems_allowed_seq);
 }
 
@@ -115,6 +118,9 @@ static inline unsigned int read_mems_allowed_begin(void)
  */
 static inline bool read_mems_allowed_retry(unsigned int seq)
 {
+   if (!cpusets_enabled())
+   return false;
+
return read_seqcount_retry(current-mems_allowed_seq, seq);
 }
 
-- 
2.4.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/


[PATCH 1/1] of: to support binding numa node to root subnode(non-bus)

2015-08-24 Thread Zhen Lei
If use of_platform_populate to scan dt-nodes and add devices, the
subnode of root(such as /smmu), when being scanned and invoke
of_device_add, the ofdev-dev.parent is always equal platform_bus. So
that, function set_dev_node will not be called. And in device_add,
dev_to_node(parent) always return NUMA_NO_NODE.

Signed-off-by: Zhen Lei thunder.leiz...@huawei.com
---
 drivers/base/core.c | 2 +-
 drivers/of/device.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index dafae6d..5df4f46b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1017,7 +1017,7 @@ int device_add(struct device *dev)
dev-kobj.parent = kobj;

/* use parent numa_node */
-   if (parent)
+   if (parent  (parent != platform_bus))
set_dev_node(dev, dev_to_node(parent));

/* first, register with generic layer. */
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8b91ea2..96ebece 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -63,7 +63,7 @@ int of_device_add(struct platform_device *ofdev)
/* device_add will assume that this device is on the same node as
 * the parent. If there is no parent defined, set the node
 * explicitly */
-   if (!ofdev-dev.parent)
+   if (!ofdev-dev.parent || (ofdev-dev.parent == platform_bus))
set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node));

return device_add(ofdev-dev);
--
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] i2c: allow specifying separate wakeup interrupt in device tree

2015-08-24 Thread Wolfram Sang

  When reviewing V2, I wasn't comfortable with just guessing what the old
  code means. So, I did some digging and found:
 
  https://lkml.org/lkml/2008/8/10/204
 
  Quoting the interesting paragraph from David Brownell:
 
  ===
 
  Better would be to preserve any existing settings:
 
  if (!device_can_wakeup(client-dev))
  device_init_wakeup(...)
  That way the userspace policy setting is preserved unless the
  device itself gets removed ... instead of being clobbered by
  the simple act of (re)probing a driver.
 
   +   device_init_wakeup(client-dev, client-flags 
   I2C_CLIENT_WAKE);
 
  ===
 
  I have to admit that I am not familiar with device wakeup handling and
  especially its userspace policies. Can you double check that your V2
  meets the above intention?
 
 No it does not; it explicitly resets the wakeup flag. Note that the
 original code was not quite right in that regard either: it would
 preserve wakeup flag set by userspace upon driver rebinding; but it
 would re-arm the wakeup flag if it was disabled by userspace.
 
 I believe that resetting the flag upon re-binding the driver is proper
 behavior as the driver is responsible for setting up and handling
 wakeups.

Okay, that meets my idea of how this should work. I rephrased the above
paragraph slightly and added it to the commit message of V2.

Thanks,

   Wolfram



signature.asc
Description: Digital signature


[PATCH 03/10] ALSA: add AXD Audio Processing IP alsa driver

2015-08-24 Thread Qais Yousef
AXD is Audio Processing IP by Imagination Technologies that can
decode multiple file formats and play them back.
We use alsa compress offload API to represent our audio driver.

This patch adds defs and initialisation files.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/img/axd/axd_api.h| 649 +++
 sound/soc/img/axd/axd_module.c | 742 +
 sound/soc/img/axd/axd_module.h |  83 +
 3 files changed, 1474 insertions(+)
 create mode 100644 sound/soc/img/axd/axd_api.h
 create mode 100644 sound/soc/img/axd/axd_module.c
 create mode 100644 sound/soc/img/axd/axd_module.h

diff --git a/sound/soc/img/axd/axd_api.h b/sound/soc/img/axd/axd_api.h
new file mode 100644
index ..316b7bcf8626
--- /dev/null
+++ b/sound/soc/img/axd/axd_api.h
@@ -0,0 +1,649 @@
+/*
+ *  Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Main API to the AXD for access from the host.
+ */
+#ifndef AXD_API_H_
+#define AXD_API_H_
+
+#include linux/types.h
+
+
+#define THREAD_COUNT 4
+#define AXD_MAX_PIPES 3
+
+
+#define AXD_DESCRIPTOR_READY_BIT   0x8000
+#define AXD_DESCRIPTOR_INUSE_BIT   0x4000
+#define AXD_DESCRIPTOR_EOS_BIT 0x2000
+#define AXD_DESCRIPTOR_SIZE_MASK   0x
+
+struct axd_buffer_desc {
+   uint32_t status_size;
+   uint32_t data_ptr;
+   uint32_t pts_high;
+   uint32_t pts_low;
+};
+
+#define AXD_INPUT_DESCRIPTORS 10
+struct axd_input {
+   struct axd_buffer_desc descriptors[AXD_INPUT_DESCRIPTORS];
+};
+
+#define AXD_OUTPUT_DESCRIPTORS 10
+struct axd_output {
+   struct axd_buffer_desc descriptors[AXD_OUTPUT_DESCRIPTORS];
+};
+
+struct axd_ctrlbuf_item {
+   uint32_t reg;
+   uint32_t val;
+};
+
+/**
+ * struct axd_memory_map - axd memory mapped region
+ * @kick:  kick register holds the type of kick to process
+ * @int_status:interrupt status register
+ * @int_mask:  interrupt mask register
+ * @in_kick_count: array of number of input kicks to process
+ * @in_int_count:  array of number of input interrupts to process
+ * @out_kick_count:array of number of output kicks to process
+ * @out_int_count: array of number of output interrupts to process
+ * @control_command:   this register contains the command type to process
+ * @control_data:  this register contains the command data to process
+ * @pc:starting pc value of each hardware thread
+ * @error: last error value
+ * @gic_irq:   which gic irqs to use for host and axd in this format:
+ * host_gic_irq[31:16]:axd_gic_irq[15:0]
+ * @freq:  count/compare clock frequency in MHz
+ * @input: array of struct axd_input which holds the descriptors
+ * @output:array of struct axd_output which holds the descriptors
+ * @ctrlbuf_size:  size of control buffer used to group multiple
+ * configurations changes into a single request
+ * @ctrlbuf_ctrl:  position of ctrlbuf requests
+ * @ctrlbuf:   the actual control buffer used to group requests
+ * size of which is defined by the firmware
+ */
+struct axd_memory_map {
+   uint32_t kick;
+   uint32_t int_status;
+   uint32_t int_mask;
+   uint32_t in_kick_count[AXD_MAX_PIPES];
+   uint32_t in_int_count[AXD_MAX_PIPES];
+   uint32_t out_kick_count[AXD_MAX_PIPES];
+   uint32_t out_int_count[AXD_MAX_PIPES];
+   uint32_t control_command;
+   uint32_t control_data;
+   uint32_t pc[THREAD_COUNT];
+   uint32_t error;
+   uint32_t gic_irq;
+   uint32_t freq;
+   uint32_t reserved01[0x04];
+   struct axd_input input[AXD_MAX_PIPES];
+   struct axd_output output[AXD_MAX_PIPES];
+   uint32_t reserved02[40];
+   uint32_t reserved03[12];
+   uint32_t ctrlbuf_size;
+   uint32_t ctrlbuf_ctrl;
+   struct axd_ctrlbuf_item ctrlbuf[];
+};
+
+#define AXD_ANY_KICK_BIT   0x8000
+#define AXD_KICK_MASK  0x000F
+#define AXD_KICK_CTRL_BIT  0x0001
+#define AXD_KICK_DATA_IN_BIT   0x0002
+#define AXD_KICK_DATA_OUT_BIT  0x0004
+
+#define AXD_INT_KICK_DONE  0x0001
+#define AXD_INT_DATAIN 0x0002
+#define AXD_INT_DATAOUT

[PATCH 09/10] ALSA: axd: add alsa compress offload operations

2015-08-24 Thread Qais Yousef
Add implementation of alsa compress offload operations.
At the moment we only support playback only.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/img/axd/axd_alsa_ops.c | 211 +++
 1 file changed, 211 insertions(+)
 create mode 100644 sound/soc/img/axd/axd_alsa_ops.c

diff --git a/sound/soc/img/axd/axd_alsa_ops.c b/sound/soc/img/axd/axd_alsa_ops.c
new file mode 100644
index ..91e17119b306
--- /dev/null
+++ b/sound/soc/img/axd/axd_alsa_ops.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (C) 2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * AXD ALSA Compressed ops
+ */
+#include sound/compress_driver.h
+#include sound/soc.h
+
+#include axd_cmds.h
+#include axd_module.h
+
+static struct axd_dev *get_axd_from_cstream(struct snd_compr_stream *cstream)
+{
+   struct snd_soc_pcm_runtime *rtd = cstream-private_data;
+   return snd_soc_platform_get_drvdata(rtd-platform);
+}
+
+static int copied_total;
+
+static int axd_compr_open(struct snd_compr_stream *cstream)
+{
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+
+   axd_cmd_output_set_sink(axd-cmd, 0, 1);
+   return axd_cmd_inpipe_start(axd-cmd, 0);
+}
+
+static int axd_compr_free(struct snd_compr_stream *cstream)
+{
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+
+   axd_cmd_inpipe_stop(axd-cmd, 0);
+   copied_total = 0;
+
+   return 0;
+}
+
+static int axd_compr_set_params(struct snd_compr_stream *cstream,
+   struct snd_compr_params *params)
+{
+   int ret;
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+
+   ret = axd_cmd_input_set_decoder_params(axd-cmd, 0, params-codec);
+   if (ret)
+   return -EINVAL;
+   return 0;
+}
+
+static int axd_compr_get_params(struct snd_compr_stream *cstream,
+   struct snd_codec *params)
+{
+   int ret;
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+
+   ret = axd_cmd_input_get_decoder_params(axd-cmd, 0, params);
+   if (ret)
+   return -EIO;
+   return 0;
+}
+
+static int axd_compr_trigger(struct snd_compr_stream *cstream, int cmd)
+{
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+
+   if (cmd == SND_COMPR_TRIGGER_PARTIAL_DRAIN ||
+   cmd == SND_COMPR_TRIGGER_DRAIN) {
+   /* stop to send EOS which will cause the stream to be drained */
+   axd_cmd_inpipe_stop(axd-cmd, 0);
+
+   /*
+* start again, repeating if EAGAIN is returned meaning we're
+* being drained
+*/
+   while (axd_cmd_inpipe_start(axd-cmd, 0) == -EAGAIN)
+   cpu_relax();
+
+   copied_total = 0;
+   }
+   return 0;
+}
+
+static int axd_compr_pointer(struct snd_compr_stream *cstream,
+struct snd_compr_tstamp *tstamp)
+{
+   tstamp-copied_total = copied_total;
+   return 0;
+}
+
+static int axd_compr_copy(struct snd_compr_stream *cstream, char __user *buf,
+ size_t count)
+{
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+   int ret;
+
+   ret = axd_cmd_send_buffer(axd-cmd, 0, buf, count);
+   if (ret  0) {
+   dev_err(axd-dev, failed to write buffer %d\n, ret);
+   return ret;
+   }
+   copied_total += ret;
+
+   return ret;
+}
+
+static int axd_compr_get_caps(struct snd_compr_stream *cstream,
+ struct snd_compr_caps *caps)
+{
+   struct axd_dev *axd = get_axd_from_cstream(cstream);
+
+   caps-min_fragment_size = 1024*2;
+   caps-max_fragment_size = 1024*2;
+   caps-min_fragments= 1;
+   caps-max_fragments= 5;
+
+   axd_cmd_get_decoders(axd-cmd, caps);
+
+   return 0;
+}
+
+static int axd_compr_get_codec_caps(struct snd_compr_stream *cstream,
+   struct snd_compr_codec_caps *codec)
+{
+   switch (codec-codec) {
+   case SND_AUDIOCODEC_PCM:
+   codec-num_descriptors = 1;
+   codec-descriptor[0].max_ch = 2;
+   codec-descriptor[0].sample_rates[0] = 96000;
+   codec-descriptor[0].sample_rates[1] = 64000;
+   codec-descriptor[0].sample_rates[2] = 48000;
+   

[PATCH 04/10] ALSA: axd: add fw binary header manipulation files

2015-08-24 Thread Qais Yousef
These files provide functions to get information from the fw binary
header.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/img/axd/axd_hdr.c | 64 +
 sound/soc/img/axd/axd_hdr.h | 24 +
 2 files changed, 88 insertions(+)
 create mode 100644 sound/soc/img/axd/axd_hdr.c
 create mode 100644 sound/soc/img/axd/axd_hdr.h

diff --git a/sound/soc/img/axd/axd_hdr.c b/sound/soc/img/axd/axd_hdr.c
new file mode 100644
index ..7be3d11df120
--- /dev/null
+++ b/sound/soc/img/axd/axd_hdr.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Helper functions to parse AXD Header in the firmware binary.
+ */
+#include linux/kernel.h
+
+#include axd_api.h
+#include axd_hdr.h
+
+static struct axd_hdr *hdr;
+
+static void dump_hdr(void)
+{
+   unsigned int offset = 0;
+   unsigned long address = (unsigned long)hdr;
+
+   pr_debug(header 0x%08lX:\n, address);
+   while (offset = sizeof(*hdr)) {
+   pr_debug(0x%08X\t, *(unsigned int *)(address+offset));
+   offset += 4;
+   if ((offset % (4*4)) == 0)
+   pr_debug(\n);
+   }
+   pr_debug(\n);
+}
+
+void axd_hdr_init(unsigned long address)
+{
+   hdr = (struct axd_hdr *)address;
+   dump_hdr();
+}
+
+unsigned long axd_hdr_get_pc(unsigned int thread)
+{
+   if (thread = THREAD_COUNT)
+   return -1;
+   return hdr-thread_pc[thread];
+}
+
+unsigned long axd_hdr_get_cmdblock_offset(void)
+{
+   pr_debug(cmdblock_offset = 0x%08X\n, hdr-cmd_block_offset);
+   return hdr-cmd_block_offset;
+}
+
+char *axd_hdr_get_build_str(void)
+{
+   return hdr-build_str;
+}
+
+unsigned long axd_hdr_get_log_offset(void)
+{
+   return hdr-log_offset;
+}
diff --git a/sound/soc/img/axd/axd_hdr.h b/sound/soc/img/axd/axd_hdr.h
new file mode 100644
index ..dc0b1e3be5a2
--- /dev/null
+++ b/sound/soc/img/axd/axd_hdr.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Helper functions to parse AXD Header in the firmware binary
+ */
+#ifndef AXD_HDR_H_
+#define AXD_HDR_H_
+
+void axd_hdr_init(unsigned long address);
+unsigned long axd_hdr_get_pc(unsigned int thread);
+unsigned long axd_hdr_get_cmdblock_offset(void);
+char *axd_hdr_get_build_str(void);
+unsigned long axd_hdr_get_log_offset(void);
+
+#endif /* AXD_HDR_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 08/10] ALSA: axd: add low level AXD platform setup files

2015-08-24 Thread Qais Yousef
At the moment AXD runs on MIPS cores only. These files provide
basic functionality to prepare AXD f/w to bootstrap itself and
do low level interrupt/kick when being initialised from a mips
core.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/img/axd/axd_platform.h  |  35 +++
 sound/soc/img/axd/axd_platform_mips.c | 416 ++
 2 files changed, 451 insertions(+)
 create mode 100644 sound/soc/img/axd/axd_platform.h
 create mode 100644 sound/soc/img/axd/axd_platform_mips.c

diff --git a/sound/soc/img/axd/axd_platform.h b/sound/soc/img/axd/axd_platform.h
new file mode 100644
index ..f9cc3c308a4a
--- /dev/null
+++ b/sound/soc/img/axd/axd_platform.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Platform Specific helper functions.
+ */
+#ifndef AXD_PLATFORM_H_
+#define AXD_PLATFORM_H_
+#include axd_module.h
+
+void axd_platform_init(struct axd_dev *axd);
+void axd_platform_set_pc(unsigned long pc);
+int axd_platform_start(void);
+void axd_platform_stop(void);
+unsigned int axd_platform_num_threads(void);
+void axd_platform_kick(void);
+void axd_platform_irq_ack(void);
+void axd_platform_print_regs(void);
+
+/*
+ * protect against simultaneous access to shared memory mapped registers area
+ * between axd and the host
+ */
+unsigned long axd_platform_lock(void);
+void axd_platform_unlock(unsigned long flags);
+
+#endif /* AXD_PLATFORM_H_ */
diff --git a/sound/soc/img/axd/axd_platform_mips.c 
b/sound/soc/img/axd/axd_platform_mips.c
new file mode 100644
index ..ac1cf5eb8a64
--- /dev/null
+++ b/sound/soc/img/axd/axd_platform_mips.c
@@ -0,0 +1,416 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * This file implements running AXD as a single VPE along side linux on the 
same
+ * core.
+ */
+#include linux/cpu.h
+#include linux/device.h
+#include linux/io.h
+#include linux/irqchip/mips-gic.h
+#include linux/spinlock.h
+
+#include asm/cpu-features.h
+#include asm/hazards.h
+#include asm/mipsregs.h
+#include asm/mipsmtregs.h
+#include asm/tlbmisc.h
+
+#include axd_module.h
+#include axd_platform.h
+
+
+static unsigned int axd_irqnum;
+static unsigned int axd_irq;
+static unsigned int axd_vpe;
+static spinlock_t lock;
+static unsigned long smpirqflags;
+
+
+static void _axd_platform_init(void *info)
+{
+   unsigned int val;
+   unsigned long irqflags;
+   unsigned long mtflags;
+
+   /*
+* make sure nothing else on this vpe or another vpe can try to modify
+* any of the shared registers below
+*/
+   local_irq_save(irqflags);
+   mtflags = dvpe();
+
+   /* EVP = 0, VPC = 1 */
+   val = read_c0_mvpcontrol();
+   val = ~MVPCONTROL_EVP;
+   val |= MVPCONTROL_VPC;
+   write_c0_mvpcontrol(val);
+   instruction_hazard();
+
+   /* prepare TC for setting up */
+   settc(axd_vpe);
+   write_tc_c0_tchalt(1);
+
+   /* make sure no interrupts are pending and exceptions bits are clear */
+   write_vpe_c0_cause(0);
+   write_vpe_c0_status(0);
+
+   /* bind TC to VPE */
+   val = read_tc_c0_tcbind();
+   val |= (axd_vpe  TCBIND_CURTC_SHIFT) | (axd_vpe  
TCBIND_CURVPE_SHIFT);
+   write_tc_c0_tcbind(val);
+
+   /* VPA = 1, MVP = 1 */
+   val = read_vpe_c0_vpeconf0();
+   val |= VPECONF0_MVP;
+   val |= VPECONF0_VPA;
+   write_vpe_c0_vpeconf0(val);
+
+   /* A = 1, IXMT = 0 */
+   val = read_tc_c0_tcstatus();
+   val = ~TCSTATUS_IXMT;
+   val |= TCSTATUS_A;
+   write_tc_c0_tcstatus(val);
+
+   /* TE = 1 */
+   val = read_vpe_c0_vpecontrol();
+   val |= VPECONTROL_TE;
+   write_vpe_c0_vpecontrol(val);
+
+   /* EVP = 1, VPC = 0 */
+   val = read_c0_mvpcontrol();
+   val |= MVPCONTROL_EVP;
+   val = ~MVPCONTROL_VPC;
+   write_c0_mvpcontrol(val);
+   instruction_hazard();
+

[PATCH 05/10] ALSA: axd: add buffers manipulation files

2015-08-24 Thread Qais Yousef
These files support initilising and managing access to the shared
buffers area in memory that is used to exchange data between AXD
and linux.

Signed-off-by: Qais Yousef qais.you...@imgtec.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Mark Brown broo...@kernel.org
Cc: Jaroslav Kysela pe...@perex.cz
Cc: Takashi Iwai ti...@suse.com
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/img/axd/axd_buffers.c | 243 
 sound/soc/img/axd/axd_buffers.h |  74 
 2 files changed, 317 insertions(+)
 create mode 100644 sound/soc/img/axd/axd_buffers.c
 create mode 100644 sound/soc/img/axd/axd_buffers.h

diff --git a/sound/soc/img/axd/axd_buffers.c b/sound/soc/img/axd/axd_buffers.c
new file mode 100644
index ..891344a806f6
--- /dev/null
+++ b/sound/soc/img/axd/axd_buffers.c
@@ -0,0 +1,243 @@
+/*
+ * Copyright (C) 2011-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * AXD generic buffer management API.
+ */
+#include linux/err.h
+#include linux/slab.h
+
+#include axd_buffers.h
+
+/**
+ * axd_buffer_init - sets up axd buffer as a pool of fixed sized buffers.
+ * @address: starting address of the buffer as set up in the system
+ * @total_size: total size of available buffer
+ * @element_size: size of each buffer element
+ *
+ * axd_buffer_t *buffer is a memory pool of size @element_size and starting at
+ * address @address and of @total_size size.
+ */
+static int bufferq_init(struct axd_bufferq *bufferq, const char *name,
+   char *address, unsigned int num_elements,
+   unsigned int element_size, unsigned int nonblock)
+{
+   int i;
+   char **queue;
+   unsigned int *size;
+
+   strncpy(bufferq-name, name, 16);
+   bufferq-stride = element_size;
+   bufferq-max = num_elements;
+   bufferq-rd_idx = 0;
+   bufferq-wr_idx = 0;
+   bufferq-nonblock = nonblock;
+   queue = kcalloc(num_elements, sizeof(char *), GFP_KERNEL);
+   if (!queue)
+   return -ENOMEM;
+   bufferq-queue = queue;
+   size = kcalloc(num_elements, sizeof(unsigned int), GFP_KERNEL);
+   if (!size) {
+   kfree(queue);
+   bufferq-queue = NULL;
+   return -ENOMEM;
+   }
+   bufferq-size = size;
+   /*
+* setup the queue with all available buffer addresses if the base
+* address is passed. Set it up as emptry if base address is NULL.
+*/
+   if (address) {
+   for (i = 0; i  num_elements; i++) {
+   queue[i] = address + (element_size * i);
+   size[i] = element_size;
+   }
+   sema_init(bufferq-rd_sem, num_elements);
+   sema_init(bufferq-wr_sem, 0);
+   } else {
+   for (i = 0; i  num_elements; i++) {
+   queue[i] = NULL;
+   size[i] = element_size;
+   }
+   sema_init(bufferq-rd_sem, 0);
+   sema_init(bufferq-wr_sem, num_elements);
+   }
+   spin_lock_init(bufferq-q_rdlock);
+   spin_lock_init(bufferq-q_wrlock);
+   pr_debug(Initialized %s of %d elements of size %d bytes\n,
+   name, num_elements, element_size);
+   pr_debug(Address of %s: 0x%08X\n, name, (unsigned int)bufferq);
+   return 0;
+}
+
+int axd_bufferq_init(struct axd_bufferq *bufferq, const char *name,
+   char *address, unsigned int num_elements,
+   unsigned int element_size, unsigned int nonblock)
+{
+   return bufferq_init(bufferq,
+   name, address, num_elements, element_size, nonblock);
+}
+
+int axd_bufferq_init_empty(struct axd_bufferq *bufferq, const char *name,
+   unsigned int num_elements, unsigned int element_size,
+   unsigned int nonblock)
+{
+   return bufferq_init(bufferq,
+   name, NULL, num_elements, element_size, nonblock);
+}
+
+void axd_bufferq_clear(struct axd_bufferq *bufferq)
+{
+   kfree(bufferq-queue);
+   kfree(bufferq-size);
+   bufferq-queue = NULL;
+   bufferq-size = NULL;
+}
+
+/**
+ * axd_buffer_take - returns a valid buffer pointer
+ * @buffer: the buffers pool to be accessed
+ *
+ * This function will go into interruptible sleep if the pool is empty.
+ */
+char *axd_bufferq_take(struct axd_bufferq *bufferq, int *buf_size)
+{
+   char *buf;
+   int ret;
+
+   if (!bufferq-queue)
+   return 

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

2015-08-24 Thread Yakir Yang

Hi Jingoo,

在 08/24/2015 03:40 PM, Jingoo Han 写道:

On 2015. 8. 24., at AM 9:43, Krzysztof Kozlowski k.kozlow...@samsung.com 
wrote:

2015-08-24 8:23 GMT+09:00 Rob Herring robherri...@gmail.com:

On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?

No, there is no agreement. This wasn't even sent to Exynos maintainers.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of ARM: dts:.

Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
2. Separate all DTS changes to a separate patch, unless bisectability
would be hurt. Anyway you should prepare it in a such way that
separation would be possible without breaking bisectability.
3. Use proper subject for the patch changing DTS. This is not
documentation change!
4. Please use script get_maintainers to obtain list of valid
maintainers and CC-them with at least cover letter and patches
requiring their attention.

To Yakir Yang,

Please be careful when you CC people.

I don't find the reason why you CC'ed the following people. Of course, they
look to be one of the talented developers. However, they look to be
unrelated to your patchset.

  Takashi Iwai
  Vincent Palatin
  Fabio Estevam
  Philipp Zabel


Yeah, actually I just got those people from patman tools. Thanks for your
remind, I would pay more attention in next version :-)



Also, please add Exynos Architecture maintainers to CC list. I don't understand
why you removed them from CC list.
  Kukjin Kim
  Krzysztof Kozlowski

Without their Ack, you will not change the codes of ARM Exynos Architecture.


Wow, thanks a lot, it's a serious mistaken  ;)

Thanks,
- Yakir


Best regards,
Jingoo Han


Best regards,
Krzysztof





Signed-off-by: Yakir Yang y...@rock-chips.com
---
Changes in v3:
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol  colorimetry properies
  from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

.../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 ++
.../devicetree/bindings/video/exynos_dp.txt| 50 ++--
arch/arm/boot/dts/exynos5250-arndale.dts   | 10 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts  | 10 ++--
arch/arm/boot/dts/exynos5250-snow.dts  | 12 ++--
arch/arm/boot/dts/exynos5250-spring.dts| 12 ++--
arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
arch/arm/boot/dts/exynos5420-smdk5420.dts  | 10 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
9 files changed, 119 insertions(+), 79 deletions(-)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
new file mode 100644
index 000..6127018
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -0,0 +1,70 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+   -compatible:
+   platform specific such as:
+* samsung,exynos5-dp
+* rockchip,rk3288-dp
+   -reg:
+   physical base address of the controller and length
+   of memory mapped region.
+   -interrupts:
+   interrupt combiner values.
+   -clocks:
+   from common clock binding: handle to dp clock.
+   -clock-names:
+   from common clock binding: Shall be dp.
+   -interrupt-parent:
+   phandle to Interrupt combiner node.
+   -phys:
+   from general PHY binding: the phandle for the PHY device.
+   -phy-names:
+   from general PHY binding: Should be dp.
+   -analogix,color-space:
+   input video data format.
+   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+   -analogix,color-depth:
+   number of bits per colour component.
+   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3

This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
drop the vendor prefix.


+   -analogix,link-rate:
+   max link rate supported by the eDP controller.
+   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
+   LINK_RATE_5_40GBPS = 0x14

Same here. I'd rather see something like link-rate-mbps and use the
actual rate.


+   

Re: [PATCH 3/3 v5] mm/vmalloc: Cache the vmalloc memory info

2015-08-24 Thread George Spelvin
(I hope I'm not annoying you by bikeshedding this too much, although I
think this is improving.)

You've sort of re-invented spinlocks, but after thinking a bit,
it all works.

Rather than using a single word, which is incremented to an odd number
at the start of an update and an even number at the end, there are
two.  An update is in progress when they're unequal.

vmap_info_gen is incremented early, when the cache needs updating, and
read late (after the cache is copied).

vmap_info_cache_gen is incremented after the cache is updated, and read
early (before the cache is copied).


This is logically equivalent to my complicated scheme with atomic updates
to various bits in a single generation word, but greatly simplified by
having two separate words.  In particular, there's no longer a need to
distinguish vmap has updated list from calc_vmalloc_info in progress.

I particularly like the gen - vmap_info_cache_gen  0 test.
You *must* test for inequality to prevent tearing of a valid cache
(...grr...English heteronyms...), and given that, might as well
require it be fresher.


Anyway, suggested changes for v6 (sigh...):

First: you do a second read of vmap_info_gen to optimize out the copy
of vmalloc_info if it's easily seen as pointless, but given how small
vmalloc_info is (two words!), i'd be inclined to omit that optimization.

Copy always, *then* see if it's worth keeping.  Smaller code, faster
fast path, and is barely noticeable on the slow path.


Second, and this is up to you, I'd be inclined to go fully non-blocking and
only spin_trylock().  If that fails, just skip the cache update.


Third, ANSI C rules allow a compiler to assume that signed integer
overflow does not occur.  That means that gcc is allowed to optimize
if (x - y  0) to if (x  y).

Given that gcc has annoyed us by using this optimization in other
contexts, It might be safer to make them unsigned (which is required to
wrap properly) and cast to integer after subtraction.


Basically, the following (untested, but pretty damn simple):

+/*
+ * Return a consistent snapshot of the current vmalloc allocation
+ * statistics, for /proc/meminfo:
+ */
+void get_vmalloc_info(struct vmalloc_info *vmi)
+{
+   unsigned gen, cache_gen = READ_ONCE(vmap_info_cache_gen);
+
+   /*
+* The two read barriers make sure that we read
+* 'cache_gen', 'vmap_info_cache' and 'gen' in
+* precisely that order:
+*/
+   smp_rmb();
+   *vmi = vmap_info_cache;
+
+   smp_rmb();
+   gen = READ_ONCE(vmap_info_gen);
+
+   /*
+* If the generation counter of the cache matches that of
+* the vmalloc generation counter then return the cache:
+*/
+   if (gen == cache_gen)
+   return;
+
+   /* Make sure 'gen' is read before the vmalloc info */
+   smp_rmb();
+   calc_vmalloc_info(vmi);
+
+   /*
+* All updates to vmap_info_cache_gen go through this spinlock,
+* so when the cache got invalidated, we'll only mark it valid
+* again if we first fully write the new vmap_info_cache.
+*
+* This ensures that partial results won't be used.
+*/
+   if (spin_trylock(vmap_info_lock)) {
+   if ((int)(gen - vmap_info_cache_gen)  0) {
+   vmap_info_cache = *vmi;
+   /*
+* Make sure the new cached data is visible before
+* the generation counter update:
+*/
+   smp_wmb();
+   WRITE_ONCE(vmap_info_cache_gen, gen);
+   }
+   spin_unlock(vmap_info_lock);
+   }
+}
+
+#endif /* CONFIG_PROC_FS */

The only remaining *very small* nit is that this function is a mix of
return early and wrap it in an if() style.  If you want to make that
if (!spin_trylock(...)) return;, I leave that you your esthetic judgement.
--
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 02/10] dt: add img,axd.txt device tree binding document

2015-08-24 Thread Mark Rutland
On Mon, Aug 24, 2015 at 01:39:11PM +0100, Qais Yousef wrote:
 Signed-off-by: Qais Yousef qais.you...@imgtec.com
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: Kumar Gala ga...@codeaurora.org
 Cc: devicet...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 ---
  .../devicetree/bindings/sound/img,axd.txt  | 34 
 ++
  1 file changed, 34 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/sound/img,axd.txt
 
 diff --git a/Documentation/devicetree/bindings/sound/img,axd.txt 
 b/Documentation/devicetree/bindings/sound/img,axd.txt
 new file mode 100644
 index ..6a8764a79d01
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/sound/img,axd.txt
 @@ -0,0 +1,34 @@
 +* AXD Audio Processing IP Binding *
 +
 +Required properties:
 +- compatible: img,axd

This sounds awfully generic. Is there not a more complete name?

 +- clocks: phandle for the clock that drives AXD.
 +- interrupts: the GIC interrupt where AXD is connected
 +- gic-irq: it takes two non-zero values, the first one is the host hwirq and
 +   the second one is AXD's. Host's hwirq should match the value in
 +   interrupts.

I don't understand what this gic-irq property is for; and it generally
doesn't look right.

Could you please describe what this is and why you thing it is
necessary?

 +
 +Optional properties:
 +- vpe: VPE number on which AXD should start. Must be provided if AXD is
 +   running as a single VPE along Linux on the same core.
 +   It can't be VPE0.
 +   The VPE will be offlined before AXD is loaded.

Likewise could you please elaborate on this is?

What is a VPE number? What does it mean to start at that number?

 +- inbuf-size: size of shared input buffers area. By default it's 0x7800 
 bytes.
 +- outbuf-size: size of shared output buffers area. By default it's 0x3c000 
 bytes.

Is this something the kernel dynamically allocates? Why does this need
to be in the DT?

Thanks,
Mark.

 +
 +
 +Example:
 +
 + axdclk: axdclk@400M {
 + #clock-cells = 0;
 + compatible = fixed-clock;
 + clock-frequency = 4;
 + };
 +
 + axd {
 + compatible = img,axd;
 + clocks = axdclk;
 + interrupts = 36 IRQ_TYPE_EDGE_RISING;
 + gic-irq = 36 37;
 + vpe = 1;
 + };
 -- 
 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] irqchip, gicv3-its, numa: Workaround for Cavium ThunderX erratum 23144

2015-08-24 Thread Ganapatrao Kulkarni
On Mon, Aug 24, 2015 at 6:15 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 On 24/08/15 13:30, Ganapatrao Kulkarni wrote:
 Hi Marc,

 thanks for the review comments.

 On Mon, Aug 24, 2015 at 3:47 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 Hi Robert,

 Just came back from the Seattle madness, so picking up patches in
 reverse order... ;-)

 On 22/08/15 14:10, Robert Richter wrote:
 The patch below adds a workaround for gicv3 in a numa environment. It
 is on top of my recent gicv3 errata patch submission v4 and Ganapat's
 arm64 numa patches for devicetree v5.

 Please comment.

 Thanks,

 -Robert



 From c432820451a46b8d1e299b8bfbfcdcb3b75340e7 Mon Sep 17 00:00:00 2001
 From: Ganapatrao Kulkarni gkulka...@caviumnetworks.com
 Date: Wed, 19 Aug 2015 23:40:05 +0530
 Subject: [PATCH] irqchip, gicv3-its, numa: Workaround for Cavium ThunderX 
 erratum
  23144

 This implements a workaround for gicv3-its erratum 23144 applicable
 for Cavium's ThunderX multinode systems.

 The erratum fixes the hang of ITS SYNC command by avoiding inter node
 io and collections/cpu mapping. This fix is only applicable for
 Cavium's ThunderX dual-socket platforms.

 Can you please elaborate on this? I can't see any reference to the SYNC
 command there. Is that a case of an ITS not being able to route LPIs to
 cores on another socket?
 we were seeing mapc command failing when we were mapping its of node0
 with collections of node1(vice-versa).

 There is no such thing as collection of node1. There are collections
 mapped to redistributors.
ok.

 we found sync was timing out, which is issued post mapc(also for mapvi
 and movi).
 Yes this errata limits the routing of inter-node LPIs.

 Please update the commit message to reflect the actual issue.
sure.



 I really need more details to understand this patch (please use short
 sentences, I'm still in a different time zone).


 Signed-off-by: Ganapatrao Kulkarni gkulka...@caviumnetworks.com
 [ rric: Reworked errata code, added helper functions, updated commit
   message. ]

 Signed-off-by: Robert Richter rrich...@cavium.com
 ---
  arch/arm64/Kconfig   | 14 +++
  drivers/irqchip/irq-gic-common.c |  5 ++--
  drivers/irqchip/irq-gic-v3-its.c | 54 
 ++--
  3 files changed, 64 insertions(+), 9 deletions(-)

 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
 index 3809187ed653..b92b7b70b29b 100644
 --- a/arch/arm64/Kconfig
 +++ b/arch/arm64/Kconfig
 @@ -421,6 +421,20 @@ config ARM64_ERRATUM_845719

 If unsure, say Y.

 +config CAVIUM_ERRATUM_22375
 + bool Cavium erratum 22375, 24313
 + depends on NUMA
 + default y
 + help
 + Enable workaround for erratum 22375, 24313.
 +
 +config CAVIUM_ERRATUM_23144
 + bool Cavium erratum 23144
 + depends on NUMA
 + default y
 + help
 + Enable workaround for erratum 23144.
 +
  config CAVIUM_ERRATUM_23154
   bool Cavium erratum 23154: Access to ICC_IAR1_EL1 is not sync'ed
   depends on ARCH_THUNDER
 diff --git a/drivers/irqchip/irq-gic-common.c 
 b/drivers/irqchip/irq-gic-common.c
 index ee789b07f2d1..1dfce64dbdac 100644
 --- a/drivers/irqchip/irq-gic-common.c
 +++ b/drivers/irqchip/irq-gic-common.c
 @@ -24,11 +24,12 @@
  void gic_check_capabilities(u32 iidr, const struct gic_capabilities *cap,
   void *data)
  {
 - for (; cap-desc; cap++) {
 + for (; cap-init; cap++) {
   if (cap-iidr != (cap-mask  iidr))
   continue;
   cap-init(data);
 - pr_info(%s\n, cap-desc);
 + if (cap-desc)
 + pr_info(%s\n, cap-desc);

 No. I really want to see what errata are applied when I look at a kernel
 log.
 sorry, did not understood your comment, it is still printed using cap-desc.

 Yes, but you are making desc optional, and I don't want it to be
 optional. I want the kernel to scream that we're using an erratum
 workaround so that we can understand what is happening when reading a
 kernel log.
sure, will add desc string.

   }
  }

 diff --git a/drivers/irqchip/irq-gic-v3-its.c 
 b/drivers/irqchip/irq-gic-v3-its.c
 index 4bb135721e72..666be39f13a9 100644
 --- a/drivers/irqchip/irq-gic-v3-its.c
 +++ b/drivers/irqchip/irq-gic-v3-its.c
 @@ -43,7 +43,8 @@
  #include irqchip.h

  #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL  0)
 -#define ITS_FLAGS_CAVIUM_THUNDERX(1ULL  1)
 +#define ITS_WORKAROUND_CAVIUM_22375  (1ULL  1)
 +#define ITS_WORKAROUND_CAVIUM_23144  (1ULL  2)

  #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING  (1  0)

 @@ -76,6 +77,7 @@ struct its_node {
   struct list_headits_device_list;
   u64 flags;
   u32 ite_size;
 + int numa_node;
  };

  #define ITS_ITT_ALIGNSZ_256
 @@ -609,11 +611,18 @@ static void its_eoi_irq(struct irq_data *d)
  static int its_set_affinity(struct 

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

2015-08-24 Thread Chen Gang
On 8/24/15 19:32, Michal Hocko wrote:
 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.


It can save several insns when failure occurs.

It is always a little better to let the external function suppose fewer
callers' behalf.

It can save the code readers' (especially new readers') time resource
to avoid to analyze why set 'vma-vm_pgoff' before checking '-ENOMEM'
(may it cause issue? or is 'vm_pgoff' related with the next checking?).


Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
  

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

2015-08-24 Thread Rob Herring
On Mon, Aug 24, 2015 at 5:17 AM, Mark Rutland mark.rutl...@arm.com wrote:
 On Wed, Aug 05, 2015 at 05:51:20PM +0100, Mark Rutland wrote:
 Rob,

 Do you have any objections to this, or are you happy to take this patch?

 There's a user of this binding (the GICv3 ITS) queued for v4.3 already in
 the tip tree, so either we either need to be ok with this binding or we
 need to rework that before v4.3.

 Sorry to ping, but are you happy to take this? Marc's replied and
 provided his ack.

Sorry. Looks fine to me, so I'll apply.

 I'm happy to resend if you prefer?

What about patch 2 and 3? I can't find patch 3 in my mail.

Rob


 Thanks,
 Mark.

 Marc, can I take it from your use of the binding that you are happy to
 provide your ack?

 Thanks,
 Mark.

 On Thu, Jul 23, 2015 at 05:52:43PM +0100, Mark Rutland wrote:
  Currently msi-parent is used in a couple of drivers despite being fairly
  underspecified. This patch adds a generic binding for MSIs (including
  the existing msi-parent property) enabling the description of platform
  devices capable of using MSIs.
 
  While MSIs are primarily distinguished by doorbell and payload, some MSI
  controllers (e.g. the GICv3 ITS) also use side-band information
  accompanying the write to identify the master which originated the MSI,
  to allow for sandboxing. This sideband information is non-probeable and
  needs to be described in the DT. Other MSI controllers may have
  additional configuration details which need to be described per-master.
 
  This patch adds a generic msi-parent binding document, extending the
  de-facto standard with a new (optional) #msi-cells which can be used to
  express any per-master configuration and/or sideband data. This is
  sufficient to describe non-hotpluggable devices.
 
  For busses where sideband data may be derived from some bus-specific
  master ID scheme, other properties will be required to describe the
  mapping.
 
  Signed-off-by: Mark Rutland mark.rutl...@arm.com
  ---
   .../bindings/interrupt-controller/msi.txt  | 135 
  +
   1 file changed, 135 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/interrupt-controller/msi.txt
 
  diff --git 
  a/Documentation/devicetree/bindings/interrupt-controller/msi.txt 
  b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
  new file mode 100644
  index 000..c60c034
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
  @@ -0,0 +1,135 @@
  +This document describes the generic device tree binding for MSI 
  controllers and
  +their master(s).
  +
  +Message Signaled Interrupts (MSIs) are a class of interrupts generated by 
  a
  +write to an MMIO address.
  +
  +MSIs were originally specified by PCI (and are used with PCIe), but may 
  also be
  +used with other busses, and hence a mechanism is required to relate 
  devices on
  +those busses to the MSI controllers which they are capable of using,
  +potentially including additional information.
  +
  +MSIs are distinguished by some combination of:
  +
  +- The doorbell (the MMIO address written to).
  +
  +  Devices may be configured by software to write to arbitrary doorbells 
  which
  +  they can address. An MSI controller may feature a number of doorbells.
  +
  +- The payload (the value written to the doorbell).
  +
  +  Devices may be configured to write an arbitrary payload chosen by 
  software.
  +  MSI controllers may have restrictions on permitted payloads.
  +
  +- Sideband information accompanying the write.
  +
  +  Typically this is neither configurable nor probeable, and depends on 
  the path
  +  taken through the memory system (i.e. it is a property of the 
  combination of
  +  MSI controller and device rather than a property of either in 
  isolation).
  +
  +
  +MSI controllers:
  +
  +
  +An MSI controller signals interrupts to a CPU when a write is made to an 
  MMIO
  +address by some master. An MSI controller may feature a number of 
  doorbells.
  +
  +Required properties:
  +
  +
  +- msi-controller: Identifies the node as an MSI controller.
  +
  +Optional properties:
  +
  +
  +- #msi-cells: The number of cells in an msi-specifier, required if not 
  zero.
  +
  +  Typically this will encode information related to sideband data, and 
  will
  +  not encode doorbells or payloads as these can be configured dynamically.
  +
  +  The meaning of the msi-specifier is defined by the device tree binding 
  of
  +  the specific MSI controller.
  +
  +
  +MSI clients
  +===
  +
  +MSI clients are devices which generate MSIs. For each MSI they wish to
  +generate, the doorbell and payload may be configured, though sideband
  +information may not be configurable.
  +
  +Required properties:
  +
  +
  +- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
  +  controller which the device is capable of using.
  +
  +  

  1   2   3   4   5   6   7   8   9   10   >