[PATCH] watchdog: imx2_wdt: adds big endianness support.

[Xiubo Li]

This watchdog driver will be working on IMX2+, Vybrid, LS1, LS2+
platforms, and will be in different endianness mode in those SoCs:

SoCs CPU endian mode  WDT endian mode

IMX2+LELE
Vybird   LELE
LS1  LEBE
LS2  LELE

Signed-off-by: Xiubo Li 
---
 drivers/watchdog/imx2_wdt.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 9d4874f..68c3d37 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -190,10 +191,12 @@ static struct regmap_config imx2_wdt_regmap_config = {
 
 static int __init imx2_wdt_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
struct imx2_wdt_device *wdev;
struct watchdog_device *wdog;
struct resource *res;
void __iomem *base;
+   bool big_endian;
int ret;
u32 val;
 
@@ -201,6 +204,10 @@ static int __init imx2_wdt_probe(struct platform_device 
*pdev)
if (!wdev)
return -ENOMEM;
 
+   big_endian = of_property_read_bool(np, "big-endian");
+   if (big_endian)
+   imx2_wdt_regmap_config.val_format_endian = REGMAP_ENDIAN_BIG;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(base))
-- 
1.8.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 1/3] memory-failure: Send right signal code to correct thread

[Naoya Horiguchi]

From: Tony Luck 

When a thread in a multi-threaded application hits a machine
check because of an uncorrectable error in memory - we want to
send the SIGBUS with si.si_code = BUS_MCEERR_AR to that thread.
Currently we fail to do that if the active thread is not the
primary thread in the process. collect_procs() just finds primary
threads and this test:
if ((flags & MF_ACTION_REQUIRED) && t == current) {
will see that the thread we found isn't the current thread
and so send a si.si_code = BUS_MCEERR_AO to the primary
(and nothing to the active thread at this time).

We can fix this by checking whether "current" shares the same
mm with the process that collect_procs() said owned the page.
If so, we send the SIGBUS to current (with code BUS_MCEERR_AR).

Reported-by: Otto Bruggeman 
Signed-off-by: Tony Luck 
Cc: Andi Kleen 
Cc: Borislav Petkov 
Cc: Chen Gong 
Acked-by: Naoya Horiguchi 
---
 mm/memory-failure.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git mmotm-2014-05-21-16-57.orig/mm/memory-failure.c 
mmotm-2014-05-21-16-57/mm/memory-failure.c
index e3154d99b87f..b73098ee91e6 100644
--- mmotm-2014-05-21-16-57.orig/mm/memory-failure.c
+++ mmotm-2014-05-21-16-57/mm/memory-failure.c
@@ -204,9 +204,9 @@ static int kill_proc(struct task_struct *t, unsigned long 
addr, int trapno,
 #endif
si.si_addr_lsb = page_size_order(page) + PAGE_SHIFT;
 
-   if ((flags & MF_ACTION_REQUIRED) && t == current) {
+   if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
si.si_code = BUS_MCEERR_AR;
-   ret = force_sig_info(SIGBUS, &si, t);
+   ret = force_sig_info(SIGBUS, &si, current);
} else {
/*
 * Don't use force here, it's convenient if the signal
-- 
1.9.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 2/3] memory-failure: Don't let collect_procs() skip over processes for MF_ACTION_REQUIRED

[Naoya Horiguchi]

From: Tony Luck 

When Linux sees an "action optional" machine check (where h/w has
reported an error that is not in the current execution path) we
generally do not want to signal a process, since most processes
do not have a SIGBUS handler - we'd just prematurely terminate the
process for a problem that they might never actually see.

task_early_kill() decides whether to consider a process - and it
checks whether this specific process has been marked for early signals
with "prctl", or if the system administrator has requested early
signals for all processes using /proc/sys/vm/memory_failure_early_kill.

But for MF_ACTION_REQUIRED case we must not defer. The error is in
the execution path of the current thread so we must send the SIGBUS
immediatley.

Fix by passing a flag argument through collect_procs*() to
task_early_kill() so it knows whether we can defer or must
take action.

Signed-off-by: Tony Luck 
Cc: Andi Kleen 
Cc: Borislav Petkov 
Cc: Chen Gong 
Acked-by: Naoya Horiguchi 
---
 mm/memory-failure.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git mmotm-2014-05-21-16-57.orig/mm/memory-failure.c 
mmotm-2014-05-21-16-57/mm/memory-failure.c
index b73098ee91e6..fbcdb1d54c55 100644
--- mmotm-2014-05-21-16-57.orig/mm/memory-failure.c
+++ mmotm-2014-05-21-16-57/mm/memory-failure.c
@@ -380,10 +380,12 @@ static void kill_procs(struct list_head *to_kill, int 
forcekill, int trapno,
}
 }
 
-static int task_early_kill(struct task_struct *tsk)
+static int task_early_kill(struct task_struct *tsk, int force_early)
 {
if (!tsk->mm)
return 0;
+   if (force_early)
+   return 1;
if (tsk->flags & PF_MCE_PROCESS)
return !!(tsk->flags & PF_MCE_EARLY);
return sysctl_memory_failure_early_kill;
@@ -393,7 +395,7 @@ static int task_early_kill(struct task_struct *tsk)
  * Collect processes when the error hit an anonymous page.
  */
 static void collect_procs_anon(struct page *page, struct list_head *to_kill,
- struct to_kill **tkc)
+ struct to_kill **tkc, int force_early)
 {
struct vm_area_struct *vma;
struct task_struct *tsk;
@@ -409,7 +411,7 @@ static void collect_procs_anon(struct page *page, struct 
list_head *to_kill,
for_each_process (tsk) {
struct anon_vma_chain *vmac;
 
-   if (!task_early_kill(tsk))
+   if (!task_early_kill(tsk, force_early))
continue;
anon_vma_interval_tree_foreach(vmac, &av->rb_root,
   pgoff, pgoff) {
@@ -428,7 +430,7 @@ static void collect_procs_anon(struct page *page, struct 
list_head *to_kill,
  * Collect processes when the error hit a file mapped page.
  */
 static void collect_procs_file(struct page *page, struct list_head *to_kill,
- struct to_kill **tkc)
+ struct to_kill **tkc, int force_early)
 {
struct vm_area_struct *vma;
struct task_struct *tsk;
@@ -439,7 +441,7 @@ static void collect_procs_file(struct page *page, struct 
list_head *to_kill,
for_each_process(tsk) {
pgoff_t pgoff = page_pgoff(page);
 
-   if (!task_early_kill(tsk))
+   if (!task_early_kill(tsk, force_early))
continue;
 
vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff,
@@ -465,7 +467,8 @@ static void collect_procs_file(struct page *page, struct 
list_head *to_kill,
  * First preallocate one tokill structure outside the spin locks,
  * so that we can kill at least one process reasonably reliable.
  */
-static void collect_procs(struct page *page, struct list_head *tokill)
+static void collect_procs(struct page *page, struct list_head *tokill,
+   int force_early)
 {
struct to_kill *tk;
 
@@ -476,9 +479,9 @@ static void collect_procs(struct page *page, struct 
list_head *tokill)
if (!tk)
return;
if (PageAnon(page))
-   collect_procs_anon(page, tokill, &tk);
+   collect_procs_anon(page, tokill, &tk, force_early);
else
-   collect_procs_file(page, tokill, &tk);
+   collect_procs_file(page, tokill, &tk, force_early);
kfree(tk);
 }
 
@@ -963,7 +966,7 @@ static int hwpoison_user_mappings(struct page *p, unsigned 
long pfn,
 * there's nothing that can be done.
 */
if (kill)
-   collect_procs(ppage, &tokill);
+   collect_procs(ppage, &tokill, flags & MF_ACTION_REQUIRED);
 
ret = try_to_unmap(ppage, ttu);
if (ret != SWAP_SUCCESS)
-- 
1.9.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  

[PATCH 3/3] mm/memory-failure.c: support dedicated thread to handle SIGBUS(BUS_MCEERR_AO)

[Naoya Horiguchi]

Currently memory error handler handles action optional errors in the deferred
manner by default. And if a recovery aware application wants to handle it
immediately, it can do it by setting PF_MCE_EARLY flag. However, such signal
can be sent only to the main thread, so it's problematic if the application
wants to have a dedicated thread to handler such signals.

So this patch adds dedicated thread support to memory error handler. We have
PF_MCE_EARLY flags for each thread separately, so with this patch AO signal
is sent to the thread with PF_MCE_EARLY flag set, not the main thread. If
you want to implement a dedicated thread, you call prctl() to set PF_MCE_EARLY
on the thread.

Memory error handler collects processes to be killed, so this patch lets it
check PF_MCE_EARLY flag on each thread in the collecting routines.

No behavioral change for all non-early kill cases.

ChangeLog:
- document more specifically
- add parenthesis in find_early_kill_thread()
- move position of find_early_kill_thread() and task_early_kill()

Signed-off-by: Naoya Horiguchi 
Reviewed-by: Tony Luck 
Cc: Kamil Iskra 
Cc: Andi Kleen 
Cc: Borislav Petkov 
Cc: Chen Gong 
---
 Documentation/vm/hwpoison.txt |  5 
 mm/memory-failure.c   | 58 ---
 2 files changed, 48 insertions(+), 15 deletions(-)

diff --git mmotm-2014-05-21-16-57.orig/Documentation/vm/hwpoison.txt 
mmotm-2014-05-21-16-57/Documentation/vm/hwpoison.txt
index 550068466605..6ae89a9edf2a 100644
--- mmotm-2014-05-21-16-57.orig/Documentation/vm/hwpoison.txt
+++ mmotm-2014-05-21-16-57/Documentation/vm/hwpoison.txt
@@ -84,6 +84,11 @@ PR_MCE_KILL
PR_MCE_KILL_EARLY: Early kill
PR_MCE_KILL_LATE:  Late kill
PR_MCE_KILL_DEFAULT: Use system global default
+   Note that if you want to have a dedicated thread which handles
+   the SIGBUS(BUS_MCEERR_AO) on behalf of the process, you should
+   call prctl(PR_MCE_KILL_EARLY) on the designated thread. Otherwise,
+   the SIGBUS is sent to the main thread.
+
 PR_MCE_KILL_GET
return current mode
 
diff --git mmotm-2014-05-21-16-57.orig/mm/memory-failure.c 
mmotm-2014-05-21-16-57/mm/memory-failure.c
index fbcdb1d54c55..9751e19ab13b 100644
--- mmotm-2014-05-21-16-57.orig/mm/memory-failure.c
+++ mmotm-2014-05-21-16-57/mm/memory-failure.c
@@ -380,15 +380,44 @@ static void kill_procs(struct list_head *to_kill, int 
forcekill, int trapno,
}
 }
 
-static int task_early_kill(struct task_struct *tsk, int force_early)
+/*
+ * Find a dedicated thread which is supposed to handle SIGBUS(BUS_MCEERR_AO)
+ * on behalf of the thread group. Return task_struct of the (first found)
+ * dedicated thread if found, and return NULL otherwise.
+ */
+static struct task_struct *find_early_kill_thread(struct task_struct *tsk)
+{
+   struct task_struct *t;
+   rcu_read_lock();
+   for_each_thread(tsk, t)
+   if ((t->flags & PF_MCE_PROCESS) && (t->flags & PF_MCE_EARLY))
+   goto found;
+   t = NULL;
+found:
+   rcu_read_unlock();
+   return t;
+}
+
+/*
+ * Determine whether a given process is "early kill" process which expects
+ * to be signaled when some page under the process is hwpoisoned.
+ * Return task_struct of the dedicated thread (main thread unless explicitly
+ * specified) if the process is "early kill," and otherwise returns NULL.
+ */
+static struct task_struct *task_early_kill(struct task_struct *tsk,
+  int force_early)
 {
+   struct task_struct *t;
if (!tsk->mm)
-   return 0;
+   return NULL;
if (force_early)
-   return 1;
-   if (tsk->flags & PF_MCE_PROCESS)
-   return !!(tsk->flags & PF_MCE_EARLY);
-   return sysctl_memory_failure_early_kill;
+   return tsk;
+   t = find_early_kill_thread(tsk);
+   if (t)
+   return t;
+   if (sysctl_memory_failure_early_kill)
+   return tsk;
+   return NULL;
 }
 
 /*
@@ -410,16 +439,16 @@ static void collect_procs_anon(struct page *page, struct 
list_head *to_kill,
read_lock(&tasklist_lock);
for_each_process (tsk) {
struct anon_vma_chain *vmac;
-
-   if (!task_early_kill(tsk, force_early))
+   struct task_struct *t = task_early_kill(tsk, force_early);
+   if (!t)
continue;
anon_vma_interval_tree_foreach(vmac, &av->rb_root,
   pgoff, pgoff) {
vma = vmac->vma;
if (!page_mapped_in_vma(page, vma))
continue;
-   if (vma->vm_mm == tsk->mm)
-   add_to_kill(tsk, page, vma, to_kill, tkc);
+   if (vma->vm_mm == t->mm)
+   add_to_kill(t, page, vma, to_kill, tkc)

[PATCH 0/3] HWPOISON: improve memory error handling for multithread process

[Naoya Horiguchi]

This patchset is the summary of recent discussion about memory error handling
on multithread application. Patch 1 and 2 is for action required errors, and
patch 3 is for action optional errors.

This patchset is based on mmotm-2014-05-21-16-57.

Patches are also available on the following tree/branch.
  g...@github.com:Naoya-Horiguchi/linux.git hwpoison/master

Thanks,
Naoya Horiguchi
---
Summary:

Naoya Horiguchi (1):
  mm/memory-failure.c: support dedicated thread to handle 
SIGBUS(BUS_MCEERR_AO)

Tony Luck (2):
  memory-failure: Send right signal code to correct thread
  memory-failure: Don't let collect_procs() skip over processes for 
MF_ACTION_REQUIRED

 Documentation/vm/hwpoison.txt |  5 +++
 mm/memory-failure.c   | 75 ++-
 2 files changed, 58 insertions(+), 22 deletions(-)
--
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] drm/gk20a/fb: use dma_alloc_coherent() for VRAM

[Alexandre Courbot]

GK20A's RAM driver was using CMA functions in order to allocate VRAM.
This is wrong because these functions are not exported, which causes
compilation to fail when CMA is enabled and Nouveau is built as a
module. On top of that the driver was leaking (or rather bleeding)
memory.

dma_alloc_coherent() will also use CMA when needed but has the
advantage of being properly exported. It creates a permanent kernel
mapping, but experiment revealed that the lowmem mapping is actually
reused, and this mapping can also be taken advantage of to implement
faster instmem. We lose the ability to allocate memory at finer
granularity, but that's what CMA is here for and it also simplifies the
driver.

This driver is to be replaced by an IOMMU-based one in the future ;
until then, its current form will allow it to do its job.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c | 97 ++-
 1 file changed, 42 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c 
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
index 7effd1a63458..10cdcf8b8a7f 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
@@ -24,32 +24,32 @@
 
 #include 
 
-#include 
 #include 
-#include 
+#include 
+#include 
+
+struct gk20a_mem {
+   struct nouveau_mem base;
+   void *cpuaddr;
+   dma_addr_t handle;
+};
+#define to_gk20a_mem(m) container_of(m, struct gk20a_mem, base)
 
 static void
 gk20a_ram_put(struct nouveau_fb *pfb, struct nouveau_mem **pmem)
 {
struct device *dev = nv_device_base(nv_device(pfb));
-   struct nouveau_mem *mem = *pmem;
-   int i;
+   struct gk20a_mem *mem = to_gk20a_mem(*pmem);
 
*pmem = NULL;
if (unlikely(mem == NULL))
return;
 
-   for (i = 0; i < mem->size; i++) {
-   struct page *page;
-
-   if (mem->pages[i] == 0)
-   break;
+   if (likely(mem->cpuaddr))
+   dma_free_coherent(dev, mem->base.size << PAGE_SHIFT,
+ mem->cpuaddr, mem->handle);
 
-   page = pfn_to_page(mem->pages[i] >> PAGE_SHIFT);
-   dma_release_from_contiguous(dev, page, 1);
-   }
-
-   kfree(mem->pages);
+   kfree(mem->base.pages);
kfree(mem);
 }
 
@@ -58,11 +58,9 @@ gk20a_ram_get(struct nouveau_fb *pfb, u64 size, u32 align, 
u32 ncmin,
 u32 memtype, struct nouveau_mem **pmem)
 {
struct device *dev = nv_device_base(nv_device(pfb));
-   struct nouveau_mem *mem;
-   int type = memtype & 0xff;
-   dma_addr_t dma_addr;
-   int npages;
-   int order;
+   struct gk20a_mem *mem;
+   u32 type = memtype & 0xff;
+   u32 npages, order;
int i;
 
nv_debug(pfb, "%s: size: %llx align: %x, ncmin: %x\n", __func__, size,
@@ -80,59 +78,48 @@ gk20a_ram_get(struct nouveau_fb *pfb, u64 size, u32 align, 
u32 ncmin,
order = fls(align);
if ((align & (align - 1)) == 0)
order--;
+   align = BIT(order);
 
-   ncmin >>= PAGE_SHIFT;
-   /*
-* allocate pages by chunks of "align" size, otherwise we may leave
-* holes in the contiguous memory area.
-*/
-   if (ncmin == 0)
-   ncmin = npages;
-   else if (align > ncmin)
-   ncmin = align;
+   /* ensure returned address is correctly aligned */
+   npages = max(align, npages);
 
mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return -ENOMEM;
 
-   mem->size = npages;
-   mem->memtype = type;
+   mem->base.size = npages;
+   mem->base.memtype = type;
 
-   mem->pages = kzalloc(sizeof(dma_addr_t) * npages, GFP_KERNEL);
-   if (!mem) {
+   mem->base.pages = kzalloc(sizeof(dma_addr_t) * npages, GFP_KERNEL);
+   if (!mem->base.pages) {
kfree(mem);
return -ENOMEM;
}
 
-   while (npages) {
-   struct page *pages;
-   int pos = 0;
-
-   /* don't overflow in case size is not a multiple of ncmin */
-   if (ncmin > npages)
-   ncmin = npages;
-
-   pages = dma_alloc_from_contiguous(dev, ncmin, order);
-   if (!pages) {
-   gk20a_ram_put(pfb, &mem);
-   return -ENOMEM;
-   }
+   *pmem = &mem->base;
 
-   dma_addr = (dma_addr_t)(page_to_pfn(pages) << PAGE_SHIFT);
+   mem->cpuaddr = dma_alloc_coherent(dev, npages << PAGE_SHIFT,
+ &mem->handle, GFP_KERNEL);
+   if (!mem->cpuaddr) {
+   nv_error(pfb, "%s: cannot allocate memory!\n", __func__);
+   gk20a_ram_put(pfb, pmem);
+   return -ENOMEM;
+   }
 
-   nv_debug(pfb, "  alloc count: %x, order: %x, addr: %pad\n"

Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

[Al Viro]

On Thu, May 29, 2014 at 10:00:49PM -0700, Linus Torvalds wrote:

> Yeah, I think that would be good. Except I think you should create a
> "dentry_is_dead()" helper function that then has that "if you hold the
> dentry or parent lock, this is safe" comment, because for lockref in
> general you do need to have the lock in the lockref itself. The fact
> that dentries have more locking is very much dentry-specific.

With how many callers?  There literally are only two places where we look
at that bit; one of them very tempting to convert to ->d_lockref.count != 0,
since reactions to positive and negative are very similar.  We also have
that bogus BUG_ON() you've mentioned (that one simply should die) and only
one place where we check it for being negative - autofs4_lookup_active().
And that one is better dealt with by taking removal from their active
list from ->d_release() to ->d_prune() (if not turning their ->d_release()
into ->d_prune() wholesale) and making ->d_prune() called for hashed and
unhashed alike (the only instance *already* checks for d_unhashed() and does
nothing in that case; no need to check that in fs/dcache.c).  With that done,
the check will be gone - all it does is filtering out the ones that are
already on the way out, but still hadn't reached ->d_release()).

IOW, it's not a widely used functionality and it's really not something
that should be ever needed outside of fs/dcache.c.  And in fs/dcache.c
we have one call site, so I'm not sure if even mentioning __lockref_not_dead()
would make much sense - (int)child->d_lockref.count < 0 might be better,
along with a comment about ->d_parent->d_lock serializing it against
lockref_mark_dead() in __dentry_kill() just as well as ->d_lock would...

Note that the only reason why autofs is playing those games is that they
keep references to dentries that do not contribute to refcount, rip them
out when dentry is killed and do that in the wrong method, which opens the
window when ->d_lock is already dropped and ->d_release() is inevitable
but yet to be called.  Solution: rip those references out before dropping
->d_lock, which is what ->d_prune() gives us.  To be fair, that code
predates ->d_prune() by several years (Jul 2008 and Oct 2011, resp.)

And "vfs: call d_op->d_prune() before unhashing dentry" has added very
odd checks for !d_unhashed(), despite ceph ->d_prune() being an explicit
no-op in other cases...

While we are at it, what the devil is d_prune_aliases() doing?  OK, we
grab ->d_lock and see that refcount is 0.  Then we call ->d_prune(),
bump refcount to 1, forcibly unhash the sucker, drop ->d_lock and ->i_lock
and call dput().  Which seems to be far too convoluted...  AFAICS, what we
want to do is
spin_lock(&dentry->d_lock);
if (!dentry->d_lockref.count) {
parent = lock_parent(dentry);
if (likely(!dentry->d_lockref.count)) {
__dentry_kill(dentry);
goto restart;
}
if (parent)
spin_unlock(&parent->d_lock);
}
spin_unlock(&dentry->d_lock);
(which means that pulling ->i_lock trylock into __dentry_kill() is
probably not a good plan, more's the pity...)  And there goes this second
call site of ->d_prune() - after that it would be called exactly in one place,
right after __dentry_kill() has done lockref_mark_dead().  The whole reason
for calling it there was that forcible unhash used to force dput() to kill
the sucker has a side effect of messing ceph ->d_prune()...
--
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 11/11] sched: replace capacity by activity

[Peter Zijlstra]

On Thu, May 29, 2014 at 09:56:24PM +0200, Vincent Guittot wrote:
> On 29 May 2014 16:02, Peter Zijlstra  wrote:
> > On Fri, May 23, 2014 at 05:53:05PM +0200, Vincent Guittot wrote:
> >> @@ -6052,8 +6006,8 @@ static inline void update_sd_lb_stats(struct lb_env 
> >> *env, struct sd_lb_stats *sd
> >>* with a large weight task outweighs the tasks on the 
> >> system).
> >>*/
> >>   if (prefer_sibling && sds->local &&
> >> - sds->local_stat.group_has_capacity)
> >> - sgs->group_capacity = min(sgs->group_capacity, 1U);
> >> + sds->local_stat.group_capacity > 0)
> >> + sgs->group_capacity = min(sgs->group_capacity, 1L);
> >>
> >>   if (update_sd_pick_busiest(env, sds, sg, sgs)) {
> >>   sds->busiest = sg;
> >> @@ -6228,7 +6182,7 @@ static inline void calculate_imbalance(struct lb_env 
> >> *env, struct sd_lb_stats *s
> >>* have to drop below capacity to reach cpu-load equilibrium.
> >>*/
> >>   load_above_capacity =
> >> - (busiest->sum_nr_running - busiest->group_capacity);
> >> + (busiest->sum_nr_running - busiest->group_weight);
> >>
> >>   load_above_capacity *= (SCHED_LOAD_SCALE * 
> >> SCHED_POWER_SCALE);
> >>   load_above_capacity /= busiest->group_power;
> >
> > I think you just broke PREFER_SIBLING here..
> 
> you mean by replacing the capacity which was reflecting the number of
> core for SMT by the group_weight ?

Right to in the first hunk we lower group_capacity to 1 when prefer_sibling,
then in the second hunk, you replace that group_capacity usage with
group_weight.

With the end result that prefer_sibling is now ineffective.

That said, I fudged the prefer_sibling usage into the capacity logic,
mostly because I could and it was already how the SMT stuff was working.
But there is no reason we should continue to intertwine these two
things.

So I think it would be good to have a patch that implements
prefer_sibling on nr_running separate from the existing capacity bits,
and then convert the remaining capacity bits to utilization (or activity
or whatever you did call it, see Morton's comments etc.).




pgp7yqFy4Tpsi.pgp
Description: PGP signature

Re: [PATCH V4 2/8] opp: call of_node_{get|put}() from of_init_opp_table()

[Sachin Kamat]

Hi Viresh,

On 27 May 2014 17:20, Viresh Kumar  wrote:
> All callers of of_init_opp_table() are required to take reference of
> dev->of_node, by initiating calls to of_node_{get|put}(), before and after
> calling of_init_opp_table().
>
> Its better to call these from within of_init_opp_table(), no fun adding
> redundant code to every caller.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/base/power/opp.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index faae9cf..2b615b9 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -622,6 +622,9 @@ int of_init_opp_table(struct device *dev)
> const __be32 *val;
> int nr;
>
> +   if (!of_node_get(dev->of_node))
> +   return -ENODEV;
> +
> prop = of_find_property(dev->of_node, "operating-points", NULL);
> if (!prop)
> return -ENODEV;

What about of_node_put before returning here and other places in this function?

-- 
With warm regards,
Sachin
--
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 -tip/urgent ] [BUGFIX] perf/probe: Fix a segfault if asked for variable it doesn't find

[Masami Hiramatsu]

(2014/05/30 15:03), Namhyung Kim wrote:
> Hi Masami,
> 
> On Thu, 29 May 2014 19:52:32 +0900, Masami Hiramatsu wrote:
>> Fix a segfault bug by asking for variable it doesn't find.
>> Since the convert_variable() didn't handle error code returned
>> from convert_variable_location(), it just passed an incomplete
>> variable field and then a segfault was occured when formatting
>> the field.
>>
>> This fixes that bug by handling success code correctly in
>> convert_variable(). Other callers of convert_variable_location()
>> are correctly checking the return code.
>>
>> This bug was introduced by following commit. But another hidden
>> erroneous error handling has been there previuosly (-ENOMEM case).
> 
> And -ERANGE too.. :)

Right, Anyway, I've added ret==0 sanity check. That error should be
handled too. :-)

Thank you,

> 
> Thanks,
> Namhyung
> 
>>
>>  commit 3d918a12a1b3088ac16ff37fa52760639d6e2403
>>
>> Signed-off-by: Masami Hiramatsu 
>> Reported-by: Arnaldo Carvalho de Melo 
>> Cc: Peter Zijlstra 
>> Cc: Paul Mackerras 
>> Cc: Ingo Molnar 
>> Cc: Namhyung Kim 
>> Cc: Jiri Olsa 
>> ---
>>  tools/perf/util/probe-finder.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
>> index 5627621..9d8eb26 100644
>> --- a/tools/perf/util/probe-finder.c
>> +++ b/tools/perf/util/probe-finder.c
>> @@ -511,12 +511,12 @@ static int convert_variable(Dwarf_Die *vr_die, struct 
>> probe_finder *pf)
>>  
>>  ret = convert_variable_location(vr_die, pf->addr, pf->fb_ops,
>>  &pf->sp_die, pf->tvar);
>> -if (ret == -ENOENT)
>> +if (ret == -ENOENT || ret == -EINVAL)
>>  pr_err("Failed to find the location of %s at this address.\n"
>> " Perhaps, it has been optimized out.\n", pf->pvar->var);
>>  else if (ret == -ENOTSUP)
>>  pr_err("Sorry, we don't support this variable location yet.\n");
>> -else if (pf->pvar->field) {
>> +else if (ret == 0 && pf->pvar->field) {
>>  ret = convert_variable_fields(vr_die, pf->pvar->var,
>>pf->pvar->field, &pf->tvar->ref,
>>&die_mem);
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH v2 10/11] sched: move cfs task on a CPU with higher capacity

[Peter Zijlstra]

On Thu, May 29, 2014 at 09:37:39PM +0200, Vincent Guittot wrote:
> On 29 May 2014 11:50, Peter Zijlstra  wrote:
> > On Fri, May 23, 2014 at 05:53:04PM +0200, Vincent Guittot wrote:
> >> If the CPU is used for handling lot of IRQs, trig a load balance to check 
> >> if
> >> it's worth moving its tasks on another CPU that has more capacity
> >>
> >> Signed-off-by: Vincent Guittot 
> >> ---
> >>  kernel/sched/fair.c | 13 +
> >>  1 file changed, 13 insertions(+)
> >>
> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> index e8a30f9..2501e49 100644
> >> --- a/kernel/sched/fair.c
> >> +++ b/kernel/sched/fair.c
> >> @@ -5948,6 +5948,13 @@ static bool update_sd_pick_busiest(struct lb_env 
> >> *env,
> >>   if (sgs->sum_nr_running > sgs->group_capacity)
> >>   return true;
> >>
> >> + /*
> >> +  * The group capacity is reduced probably because of activity from 
> >> other
> >> +  * sched class or interrupts which use part of the available capacity
> >> +  */
> >> + if ((sg->sgp->power_orig * 100) > (sgs->group_power * 
> >> env->sd->imbalance_pct))
> >> + return true;
> >> +
> >>   if (sgs->group_imb)
> >>   return true;
> >>
> >
> > But we should already do this because the load numbers are scaled with
> > the power/capacity figures. If one CPU gets significant less time to run
> > fair tasks, its effective load would spike and it'd get to be selected
> > here anyway.
> >
> > Or am I missing something?
> 
> The CPU could have been picked when the capacity becomes null (which
> occurred when the cpu_power goes below half the default
> SCHED_POWER_SCALE). And even after that, there were some conditions in
> find_busiest_group that was bypassing this busiest group

Could you detail those conditions? FWIW those make excellent Changelog
material.


pgpBypS82X_XH.pgp
Description: PGP signature

Re: [RFC][PATCH] tracing: Print nasty banner when trace_printk() is in use

[Olaf Titz]

>   *
>   ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE**

Is it really that bad to warrant this kind of warning? Not knowing
about the issue at all, I read from the original description that the
wastage is four pages of memory times number of CPU cores, which
shouldn't matter much except for small embedded systems.

Or does this something much scarier, like considerably slowing down
fast paths?

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

[RFC v2] Bluetooth: Keep master role when SCO or eSCO is active

[Kiran Kumar Raparthy]

From: "hyungseoung.yoo" 

Preserve the master role when SCO or eSCO is active
as this improves compatability with lots of
headset and chipset combinations.

This is one of the number of patches from the Android AOSP
common.git tree, which is used on almost all Android devices.
It looks like it would improve support for compatibility with
lot of headset,so I wanted to submit it for review to see
if it should go upstream.

v2: Fixed formatting issues pointed by Sergei

Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: "David S. Miller" 
Cc: linux-blueto...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Android Kernel Team 
Cc: John Stultz 
Signed-off-by: hyungseoung.yoo 
Signed-off-by: Jaikumar Ganesh 
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy 
---
 net/bluetooth/hci_event.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 15010a2..48bc772 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1915,6 +1915,14 @@ unlock:
hci_conn_check_pending(hdev);
 }
 
+static inline bool is_sco_active(struct hci_dev *hdev)
+{
+   if (hci_conn_hash_lookup_state(hdev, SCO_LINK, BT_CONNECTED) ||
+   hci_conn_hash_lookup_state(hdev, ESCO_LINK, BT_CONNECTED))
+   return true;
+   return false;
+}
+
 static void hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
 {
struct hci_ev_conn_request *ev = (void *) skb->data;
@@ -1961,7 +1969,9 @@ static void hci_conn_request_evt(struct hci_dev *hdev, 
struct sk_buff *skb)
 
bacpy(&cp.bdaddr, &ev->bdaddr);
 
-   if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
+   if (lmp_rswitch_capable(hdev) &&
+   ((mask & HCI_LM_MASTER) ||
+   is_sco_active(hdev)))
cp.role = 0x00; /* Become master */
else
cp.role = 0x01; /* Remain slave */
-- 
1.8.2.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] ahci: Add Device ID for HighPoint RocketRaid 642L

[Jérôme Carretero]

This device normally comes with a proprietary driver, using a web GUI
to configure RAID:
 http://www.highpoint-tech.com/USA_new/series_rr600-download.htm
But thankfully it also works out of the box with the AHCI driver,
being just a Marvell 88SE9235.

Devices 640L, 644L, 644LS should also be supported but not tested here.

Signed-off-by: Jérôme Carretero 
---
 drivers/ata/ahci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6070781..ff5543f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -449,6 +449,8 @@ static const struct pci_device_id ahci_pci_tbl[] = {
  .driver_data = board_ahci_yes_fbs },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9230),
  .driver_data = board_ahci_yes_fbs },
+   { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642,
+ .driver_data = board_ahci_yes_fbs },
 
/* Promise */
{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci },   /* PDC42819 */
-- 
1.9.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 v2 04/05] staging: board: Initial board staging support

[Magnus Damm]

On Thu, May 29, 2014 at 11:03 PM, Paul Bolle  wrote:
> On Thu, 2014-05-29 at 22:53 +0900, Magnus Damm wrote:
>> --- 0011/drivers/staging/board/Kconfig
>> +++ work/drivers/staging/board/Kconfig2014-05-29 22:32:39.0 +0900
>> @@ -1,5 +1,6 @@
>>  config STAGING_BOARD
>>  boolean "Staging Board Support"
>> +depends on OF && OF_ADDRESS
>
> I have no idea what this is all about, but wouldn't just OF_ADDRESS be
> enough here (as OF_ADDRESS depends on OF)?

Yeah, that makes sense. I am also considering stubbing in the missing
function prototypes in the header files to be able to get rid of this
dependency.

Cheers,

/ magnus
--
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 2/2] x86_64: expand kernel stack to 16K

[Minchan Kim]

On Thu, May 29, 2014 at 06:24:02PM -0700, Linus Torvalds wrote:
> On Thu, May 29, 2014 at 5:50 PM, Minchan Kim  wrote:
> >>
> >> You could also try Dave's patch, and _not_ do my mm/vmscan.c part.
> >
> > Sure. While I write this, Rusty's test was crached so I will try Dave's 
> > patch,
> > them yours except vmscan.c part.
> 
> Looking more at Dave's patch (well, description), I don't think there
> is any way in hell we can ever apply it. If I read it right, it will
> cause all IO that overflows the max request count to go through the
> scheduler to get it flushed. Maybe I misread it, but that's definitely
> not acceptable. Maybe it's not noticeable with a slow rotational
> device, but modern ssd hardware? No way.
> 
> I'd *much* rather slow down the swap side. Not "real IO". So I think
> my mm/vmscan.c patch is preferable (but yes, it might require some
> work to make kswapd do better).
> 
> So you can try Dave's patch just to see what it does for stack depth,
> but other than that it looks unacceptable unless I misread things.
> 
>  Linus

I tested below patch and the result is endless OOM although there are
lots of anon pages and empty space of swap.

I guess __alloc_pages_direct_reclaim couldn't proceed due to anon pages
once VM drop most of file-backed pages, then go to OOM.

---
 mm/backing-dev.c | 25 +++--
 mm/vmscan.c  |  4 +---
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index ce682f7a4f29..2762b16404bd 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static atomic_long_t bdi_seq = ATOMIC_LONG_INIT(0);
 
@@ -565,6 +566,18 @@ void set_bdi_congested(struct backing_dev_info *bdi, int 
sync)
 }
 EXPORT_SYMBOL(set_bdi_congested);
 
+static long congestion_timeout(int sync, long timeout)
+{
+   long ret;
+   DEFINE_WAIT(wait);
+
+   wait_queue_head_t *wqh = &congestion_wqh[sync];
+   prepare_to_wait(wqh, &wait, TASK_UNINTERRUPTIBLE);
+   ret = schedule_timeout(timeout);
+   finish_wait(wqh, &wait);
+   return ret;
+}
+
 /**
  * congestion_wait - wait for a backing_dev to become uncongested
  * @sync: SYNC or ASYNC IO
@@ -578,12 +591,8 @@ long congestion_wait(int sync, long timeout)
 {
long ret;
unsigned long start = jiffies;
-   DEFINE_WAIT(wait);
-   wait_queue_head_t *wqh = &congestion_wqh[sync];
 
-   prepare_to_wait(wqh, &wait, TASK_UNINTERRUPTIBLE);
-   ret = io_schedule_timeout(timeout);
-   finish_wait(wqh, &wait);
+   ret = congestion_timeout(sync,timeout);
 
trace_writeback_congestion_wait(jiffies_to_usecs(timeout),
jiffies_to_usecs(jiffies - start));
@@ -614,8 +623,6 @@ long wait_iff_congested(struct zone *zone, int sync, long 
timeout)
 {
long ret;
unsigned long start = jiffies;
-   DEFINE_WAIT(wait);
-   wait_queue_head_t *wqh = &congestion_wqh[sync];
 
/*
 * If there is no congestion, or heavy congestion is not being
@@ -635,9 +642,7 @@ long wait_iff_congested(struct zone *zone, int sync, long 
timeout)
}
 
/* Sleep until uncongested or a write happens */
-   prepare_to_wait(wqh, &wait, TASK_UNINTERRUPTIBLE);
-   ret = io_schedule_timeout(timeout);
-   finish_wait(wqh, &wait);
+   ret = congestion_timeout(sync, timeout);
 
 out:
trace_writeback_wait_iff_congested(jiffies_to_usecs(timeout),
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a9c74b409681..e4ad7cd1885b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -975,9 +975,7 @@ static unsigned long shrink_page_list(struct list_head 
*page_list,
 * avoid risk of stack overflow but only writeback
 * if many dirty pages have been encountered.
 */
-   if (page_is_file_cache(page) &&
-   (!current_is_kswapd() ||
-!zone_is_reclaim_dirty(zone))) {
+   if (!current_is_kswapd() || 
!zone_is_reclaim_dirty(zone)) {
/*
 * Immediately reclaim when written back.
 * Similar in principal to deactivate_page()
-- 
1.9.2

-- 
Kind regards,
Minchan Kim
--
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 V8 0/2] serial/uart/8250: Introduce tunable RX trigger I/F

[Yoshihiro YUNOMAE]

Hi Greg,

This patch set introduces tunable RX interrupt trigger I/F for 8250 serials.
I just split V7's patch up into 2 patches, and all functions are not changed
from previous version. V6 patch was reviewed by Stephen Warren and acked, 
but I removed the 'Reviewed-by' for this patch set just in case.

Thanks!



Changed in V2:
 - Use _IOW for TIOCSFIFORTRIG definition
 - Pass the interrupt trigger value itself

Changes in V3:
 - Change I/F from ioctl(2) to sysfs(rx_int_trig)

Changes in V4:
 - Introduce fifo_bug flag in uart_8250_port structure
   This is enabled only when parity is enabled and UART_BUG_PARITY is enabled
   for up->bugs. If this flag is enabled, user cannot set RX trigger.
 - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and
   at convert_val2rxtrig()
 - Set the nearest lower RX trigger when users input a meaningless value at
   convert_val2rxtrig()
 - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos()
 - Set fcr = up->fcr in the begging of serial8250_do_set_termios()

Changes in V5:
 - Support Tegra, 16650V2, 16654, and 16750
 - Store default FCR value to up->fcr when the port is first created
 - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[]
   in convert_fcr2val() and convert_val2rxtrig()

Changes in V5.1:
 - Fix FCR_RX_TRIG_MAX_STATE definition

Changes in V6:
 - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h,
   rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to
   UART_FCR_R_TRIG_BITS()
 - Change following function names:
convert_fcr2val() => fcr_get_rxtrig_bytes()
convert_val2rxtrig() => bytes_to_fcr_rxtrig()
 - Fix typo in serial8250_do_set_termios()
 - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig()
 - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables
   (but UI remains rx_int_trig)
 - Change the meaningless variable name 'val' to 'bytes' following functions:
fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(),
do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig()
 - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in
   fcr_get_rxtrig_bytes()
 - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check
   in register_dev_spec_attr_grp()
 - Delete the checking whether a user changed FCR or not when minimum buffer
   is needed in serial8250_do_set_termios()

Changes in V7:
 - Add Documentation
 - Change I/F name from rx_int_trig to rx_trig_bytes because the name
   rx_int_trig is hard to understand how users specify the value

Changes in V8:
 - Split V7's patch up into 2 patches

---

Yoshihiro YUNOMAE (2):
  serial/uart: Introduce device specific attribute group to uart_port 
structure
  serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers


 Documentation/ABI/testing/sysfs-tty |   16 +++
 drivers/tty/serial/8250/8250.h  |2 
 drivers/tty/serial/8250/8250_core.c |  173 ---
 drivers/tty/serial/serial_core.c|   18 ++--
 include/linux/serial_8250.h |2 
 include/linux/serial_core.h |4 +
 include/uapi/linux/serial_reg.h |5 +
 7 files changed, 198 insertions(+), 22 deletions(-)

-- 
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]x86 efi: do not export efi runtime map in case old map

[Dave Young]

On 05/30/14 at 03:08pm, Simon Horman wrote:
> On Fri, May 30, 2014 at 01:54:47PM +0800, Dave Young wrote:
> > Ccing Simon.
> > 
> > Simon, appologize for not ccing you about this kernel patch. I see you have
> > applied the userspace patch for checking sysfs runtime existance.
> > 
> > The userspace patch depends on this patch but it is not harmful even without
> > this kernel patch. So applying the userspace patch before this one is still
> > safe.
> 
> Thanks, I understand.
> 
> If the kernel side ends up being rejected or modified please
> send an update for kexec-tools accordingly.

Sure, will do

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

Re: [PATCH 2/2] serial: imx: disable the receiver ready interrupt for imx_stop_rx

[Huang Shijie]

On Fri, May 30, 2014 at 07:52:25AM +0200, Dirk Behme wrote:
> On 23.05.2014 06:32, Huang Shijie wrote:
> >This patch disables the receiver ready interrupt for imx_stop_rx.
> >It reduces the interrupt numbers when the uart is going to close
> >or suspend.
> >
> >Signed-off-by: Huang Shijie 
> >---
> >  drivers/tty/serial/imx.c |4 
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> >diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> >index ed6cdf7..6026101 100644
> >--- a/drivers/tty/serial/imx.c
> >+++ b/drivers/tty/serial/imx.c
> >@@ -440,6 +440,10 @@ static void imx_stop_rx(struct uart_port *port)
> >
> > temp = readl(sport->port.membase + UCR2);
> > writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
> >+
> >+/* disable the `Receiver Ready Interrrupt` */
> >+temp = readl(sport->port.membase + UCR1);
> >+writel(temp & ~UCR1_RRDYEN, sport->port.membase + UCR1);
> 
> Will this change cause a loss or a processing delay of RX characters
> pending in the RX FIFO ?
> 
> It is not clear whether disabling the receiver will clear the RX
> FIFO. My guess is that the contents of the RX FIFO will remain
> intact when the receiver is disabled. The RX interrupt has an
> opportunity to mop up these pending characters in the RX FIFO but
> disabling the RX interrupt has potential to leave those characters
> in the RX FIFO. Does it matter ?
When the @stop_rx() is called, the system(or the application) is closing
or suspending, and it has decided to abandon the RX data. 

So i think it do not matter the RX FIFO has some left data.
We will reset the RX FIFO when the UART port is re-started again.

thanks
Huang Shijie
--
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 V8 1/2] serial/uart: Introduce device specific attribute group to uart_port structure

[Yoshihiro YUNOMAE]

Current serial device driver has the common sysfs I/F for all serial
devices, but it does not have device specific sysfs I/F. To make device
specific sysfs I/F, this patch introduces device specific attribute group to
uart_port structure.

Changes in V8:
 - Divide this patch from V7's patch based on Greg's comment

Signed-off-by: Yoshihiro YUNOMAE 
---
 drivers/tty/serial/serial_core.c |   18 +++---
 include/linux/serial_core.h  |4 
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index b68550d..524cb49 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2552,15 +2552,16 @@ static struct attribute *tty_dev_attrs[] = {
NULL,
};
 
-static const struct attribute_group tty_dev_attr_group = {
+static struct attribute_group tty_dev_attr_group = {
.attrs = tty_dev_attrs,
};
 
-static const struct attribute_group *tty_dev_attr_groups[] = {
-   &tty_dev_attr_group,
-   NULL
-   };
-
+static void make_uport_attr_grps(struct uart_port *uport)
+{
+   uport->attr_grps[0] = &tty_dev_attr_group;
+   if (uport->dev_spec_attr_group)
+   uport->attr_grps[1] = uport->dev_spec_attr_group;
+}
 
 /**
  * uart_add_one_port - attach a driver-defined port structure
@@ -2611,12 +2612,15 @@ int uart_add_one_port(struct uart_driver *drv, struct 
uart_port *uport)
 
uart_configure_port(drv, state, uport);
 
+   make_uport_attr_grps(uport);
+
/*
 * Register the port whether it's detected or not.  This allows
 * setserial to be used to alter this port's parameters.
 */
tty_dev = tty_port_register_device_attr(port, drv->tty_driver,
-   uport->line, uport->dev, port, tty_dev_attr_groups);
+   uport->line, uport->dev, port,
+   (const struct attribute_group **)uport->attr_grps);
if (likely(!IS_ERR(tty_dev))) {
device_set_wakeup_capable(tty_dev, 1);
} else {
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index f729be9..7e3122f 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -113,6 +113,8 @@ struct uart_icount {
 
 typedef unsigned int __bitwise__ upf_t;
 
+#define MAX_ATTR_GRPS  3
+
 struct uart_port {
spinlock_t  lock;   /* port lock */
unsigned long   iobase; /* in/out[bwl] */
@@ -195,6 +197,8 @@ struct uart_port {
unsigned intline;   /* port index */
resource_size_t mapbase;/* for ioremap */
struct device   *dev;   /* parent device */
+   struct attribute_group  *dev_spec_attr_group;   /* specific attribute */
+   struct attribute_group  *attr_grps[MAX_ATTR_GRPS];/* all attr. groups */
unsigned char   hub6;   /* this should be in 
the 8250 driver */
unsigned char   suspended;
unsigned char   irq_wake;

--
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 V8 2/2] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers

[Yoshihiro YUNOMAE]

Add tunable RX interrupt trigger I/F of FIFO buffers.

Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user applications want to receive data unit as soon as
possible for real-time tendency. If we have a sensor which sends a 1 byte data
each time and must control a device based on the sensor feedback, the RX
interrupt should be triggered for each data.

According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.

This patch makes some devices change RX interrupt trigger from userland.


- Read current setting
 # cat /sys/class/tty/ttyS0/rx_trig_bytes
 8

- Write user setting
 # echo 1 > /sys/class/tty/ttyS0/rx_trig_bytes
 # cat /sys/class/tty/ttyS0/rx_trig_bytes
 1


- 16550A and Tegra (1, 4, 8, or 14 bytes)
- 16650V2 (8, 16, 24, or 28 bytes)
- 16654 (8, 16, 56, or 60 bytes)
- 16750 (1, 16, 32, or 56 bytes)

Changed in V2:
 - Use _IOW for TIOCSFIFORTRIG definition
 - Pass the interrupt trigger value itself

Changes in V3:
 - Change I/F from ioctl(2) to sysfs(rx_int_trig)

Changes in V4:
 - Introduce fifo_bug flag in uart_8250_port structure
   This is enabled only when parity is enabled and UART_BUG_PARITY is enabled
   for up->bugs. If this flag is enabled, user cannot set RX trigger.
 - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and
   at convert_val2rxtrig()
 - Set the nearest lower RX trigger when users input a meaningless value at
   convert_val2rxtrig()
 - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos()
 - Set fcr = up->fcr in the begging of serial8250_do_set_termios()

Changes in V5:
 - Support Tegra, 16650V2, 16654, and 16750
 - Store default FCR value to up->fcr when the port is first created
 - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[]
   in convert_fcr2val() and convert_val2rxtrig()

Changes in V5.1:
 - Fix FCR_RX_TRIG_MAX_STATE definition

Changes in V6:
 - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h,
   rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to
   UART_FCR_R_TRIG_BITS()
 - Change following function names:
convert_fcr2val() => fcr_get_rxtrig_bytes()
convert_val2rxtrig() => bytes_to_fcr_rxtrig()
 - Fix typo in serial8250_do_set_termios()
 - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig()
 - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables
   (but UI remains rx_int_trig)
 - Change the meaningless variable name 'val' to 'bytes' following functions:
fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(),
do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig()
 - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in
   fcr_get_rxtrig_bytes()
 - Use conf_type->rxtrig_bytes[0] instead of switch statement for support check
   in register_dev_spec_attr_grp()
 - Delete the checking whether a user changed FCR or not when minimum buffer
   is needed in serial8250_do_set_termios()

Changes in V7:
 - Add Documentation
 - Change I/F name from rx_int_trig to rx_trig_bytes because the name
   rx_int_trig is hard to understand how users specify the value

Changes in V8:
 - Divide this patch from V7's patch based on Greg's comment

Signed-off-by: Yoshihiro YUNOMAE 
---
 Documentation/ABI/testing/sysfs-tty |   16 +++
 drivers/tty/serial/8250/8250.h  |2 
 drivers/tty/serial/8250/8250_core.c |  173 ---
 include/linux/serial_8250.h |2 
 include/uapi/linux/serial_reg.h |5 +
 5 files changed, 183 insertions(+), 15 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-tty 
b/Documentation/ABI/testing/sysfs-tty
index ad22fb0..9eb3c2b 100644
--- a/Documentation/ABI/testing/sysfs-tty
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -138,3 +138,19 @@ Description:
 
 These sysfs values expose the TIOCGSERIAL interface via
 sysfs rather than via ioctls.
+
+What:  /sys/class/tty/ttyS0/rx_trig_bytes
+Date:  May 2014
+Contact:   Yoshihiro YUNOMAE 
+Description:
+Shows current RX interrupt trigger bytes or sets the
+user specified value to change it for the FIFO buffer.
+Users can show or set this value regardless of opening the
+serial device file or not.
+
+The RX trigger can be set one of four kinds of values for UART
+serials. When users input a meaning less value to this I/F,
+the RX trigger is changed to the nearest lower value for the
+device specification. For example, when user sets 7bytes on
+16550A, which has 1/4/8/14

Re: [RFC 2/2] x86_64: expand kernel stack to 16K

[Minchan Kim]

Final result,

I tested the machine below patch (Dave suggested + some part I modified)
and I couldn't see the problem any more(tested 4hr, I will queue it into
the machine during weekend for long running test if I don't get more
enhanced version before leaving the office today) but as I reported
interim result, still VM's stack usage is high.

Anyway, it's another issue we should really diet of VM functions
(ex, uninlining slow path part from __alloc_pages_nodemask and
alloc_info idea from Linus and more).

Looking forwad to seeing blk_plug_start_async way.
Thanks, Dave!

---
 block/blk-core.c| 2 +-
 block/blk-mq.c  | 2 +-
 kernel/sched/core.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index bfe16d5af9f9..0c81aacec75b 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1585,7 +1585,7 @@ get_rq:
trace_block_plug(q);
else {
if (request_count >= BLK_MAX_REQUEST_COUNT) {
-   blk_flush_plug_list(plug, false);
+   blk_flush_plug_list(plug, true);
trace_block_plug(q);
}
}
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 883f72089015..6e72e700d11e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -897,7 +897,7 @@ static void blk_mq_make_request(struct request_queue *q, 
struct bio *bio)
if (list_empty(&plug->mq_list))
trace_block_plug(q);
else if (request_count >= BLK_MAX_REQUEST_COUNT) {
-   blk_flush_plug_list(plug, false);
+   blk_flush_plug_list(plug, true);
trace_block_plug(q);
}
list_add_tail(&rq->queuelist, &plug->mq_list);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f5c6635b806c..ebca9e1f200f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4244,7 +4244,7 @@ void __sched io_schedule(void)
 
delayacct_blkio_start();
atomic_inc(&rq->nr_iowait);
-   blk_flush_plug(current);
+   blk_schedule_flush_plug(current);
current->in_iowait = 1;
schedule();
current->in_iowait = 0;
@@ -4260,7 +4260,7 @@ long __sched io_schedule_timeout(long timeout)
 
delayacct_blkio_start();
atomic_inc(&rq->nr_iowait);
-   blk_flush_plug(current);
+   blk_schedule_flush_plug(current);
current->in_iowait = 1;
ret = schedule_timeout(timeout);
current->in_iowait = 0;
-- 
1.9.2


On Fri, May 30, 2014 at 11:12:47AM +0900, Minchan Kim wrote:
> On Fri, May 30, 2014 at 10:15:58AM +1000, Dave Chinner wrote:
> > On Fri, May 30, 2014 at 08:36:38AM +0900, Minchan Kim wrote:
> > > Hello Dave,
> > > 
> > > On Thu, May 29, 2014 at 11:58:30AM +1000, Dave Chinner wrote:
> > > > On Thu, May 29, 2014 at 11:30:07AM +1000, Dave Chinner wrote:
> > > > > On Wed, May 28, 2014 at 03:41:11PM -0700, Linus Torvalds wrote:
> > > > > commit a237c1c5bc5dc5c76a21be922dca4826f3eca8ca
> > > > > Author: Jens Axboe 
> > > > > Date:   Sat Apr 16 13:27:55 2011 +0200
> > > > > 
> > > > > block: let io_schedule() flush the plug inline
> > > > > 
> > > > > Linus correctly observes that the most important dispatch cases
> > > > > are now done from kblockd, this isn't ideal for latency reasons.
> > > > > The original reason for switching dispatches out-of-line was to
> > > > > avoid too deep a stack, so by _only_ letting the "accidental"
> > > > > flush directly in schedule() be guarded by offload to kblockd,
> > > > > we should be able to get the best of both worlds.
> > > > > 
> > > > > So add a blk_schedule_flush_plug() that offloads to kblockd,
> > > > > and only use that from the schedule() path.
> > > > > 
> > > > > Signed-off-by: Jens Axboe 
> > > > > 
> > > > > And now we have too deep a stack due to unplugging from 
> > > > > io_schedule()...
> > > > 
> > > > So, if we make io_schedule() push the plug list off to the kblockd
> > > > like is done for schedule()
> > 
> > > I did below hacky test to apply your idea and the result is overflow 
> > > again.
> > > So, again it would second stack expansion. Otherwise, we should prevent
> > > swapout in direct reclaim.
> > > 
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index f5c6635b806c..95f169e85dbe 100644
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -4241,10 +4241,13 @@ EXPORT_SYMBOL_GPL(yield_to);
> > >  void __sched io_schedule(void)
> > >  {
> > >   struct rq *rq = raw_rq();
> > > + struct blk_plug *plug = current->plug;
> > >  
> > >   delayacct_blkio_start();
> > >   atomic_inc(&rq->nr_iowait);
> > > - blk_flush_plug(current);
> > > + if (plug)
> > > + blk_flush_plug_list(plug, true);
> > > +
> >

linux-next: build failure after merge of the pinctrl tree

[Stephen Rothwell]

Hi Linus,

After merging the pinctrl tree, today's linux-next build (arm 
multi_v7_defconfig)
failed like this:

drivers/pinctrl/sirf/pinctrl-sirf.c: In function 'sirfsoc_gpio_handle_irq':
drivers/pinctrl/sirf/pinctrl-sirf.c:578:11: error: 'sgpio_chip' undeclared 
(first use in this function)


Caused by commit 294d1351ff47 ("pinctrl: sirf: switch to using
allocated state container").

I have used the pinctrl tree from next-20140529 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH]x86 efi: do not export efi runtime map in case old map

[Simon Horman]

On Fri, May 30, 2014 at 01:54:47PM +0800, Dave Young wrote:
> Ccing Simon.
> 
> Simon, appologize for not ccing you about this kernel patch. I see you have
> applied the userspace patch for checking sysfs runtime existance.
> 
> The userspace patch depends on this patch but it is not harmful even without
> this kernel patch. So applying the userspace patch before this one is still
> safe.

Thanks, I understand.

If the kernel side ends up being rejected or modified please
send an update for kexec-tools accordingly.

> 
> On 05/30/14 at 11:20am, Dave Young wrote:
> > 
> > For ioremapped efi memory aka old_map the virt addresses are not persistant
> > across kexec reboot. kexec-tools will read the runtime maps from sysfs then
> > pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause
> > kexec boot failure.
> > 
> > To address this issue do not export runtime maps in case efi old_map so
> > userspace can use no efi boot instead.
> > 
> > Signed-off-by: Dave Young 
> > ---
> >  arch/x86/platform/efi/efi.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 3781dd3..4d36932 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -919,6 +919,9 @@ static void __init save_runtime_map(void)
> > void *tmp, *p, *q = NULL;
> > int count = 0;
> >  
> > +   if (efi_enabled(EFI_OLD_MEMMAP))
> > +   return;
> > +
> > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> > md = p;
> >  
> > -- 
> > 1.8.3.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/
> 
--
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] CMA: correct unlock target

[Marek Szyprowski]

Hello,

On 2014-05-29 16:56, Laura Abbott wrote:

On 5/29/2014 12:34 AM, Marek Szyprowski wrote:
> Hello,
>
> On 2014-05-29 08:29, Joonsoo Kim wrote:
>> 'cma: Remove potential deadlock situation' introduces per cma area mutex
>> for bitmap management. It is good, but there is one mistake. When we
>> can't find appropriate area in bitmap, we release cma_mutex global lock
>> rather than cma->lock and this is a bug. So fix it.
>>
>> Signed-off-by: Joonsoo Kim 
>
> Thanks for spotting this issue. I've added it to my tree.
>
>> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
>> index 6f6bffc..83969f8 100644
>> --- a/drivers/base/dma-contiguous.c
>> +++ b/drivers/base/dma-contiguous.c
>> @@ -331,7 +331,7 @@ struct page *dma_alloc_from_contiguous(struct device 
*dev, int count,
>>   pageno = bitmap_find_next_zero_area(cma->bitmap, cma->count,
>>   start, count, mask);
>>   if (pageno >= cma->count) {
>> -mutex_unlock(&cma_mutex);
>> +mutex_unlock(&cma->lock);
>>   break;
>>   }
>>   bitmap_set(cma->bitmap, pageno, count);
>
> Best regards

Acked-by: Laura Abbott 

Who actually ended up picking up that patch? I sent it out but didn't realize 
it had been
picked up.


I've taken it to my dma-mapping tree some time ago, I think that
I've replied to the original mail with information about taking it.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
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] arm64: kernel: initialize broadcast hrtimer based clock event device

[Preeti U Murthy]

On 05/29/2014 10:46 PM, Lorenzo Pieralisi wrote:
> On platforms implementing CPU power management, the CPUidle subsystem
> can allow CPUs to enter idle states where local timers logic is lost on power
> down. To keep the software timers functional the kernel relies on an
> always-on broadcast timer to be present in the platform to relay the
> interrupt signalling the timer expiries.
> 
> For platforms implementing CPU core gating that do not implement an always-on
> HW timer or implement it in a broken way, this patch adds code to initialize
> the kernel hrtimer based clock event device upon boot (which can be chosen as
> tick broadcast device by the kernel).
> It relies on a dynamically chosen CPU to be always powered-up. This CPU then
> relays the timer interrupt to CPUs in deep-idle states through its HW local
> timer device.
> 
> Having a CPU always-on has implications on power management platform
> capabilities and makes CPUidle suboptimal, since at least a CPU is kept
> always in a shallow idle state by the kernel to relay timer interrupts,
> but at least leaves the kernel with a functional system with some working
> power management capabilities.
> 
> The hrtimer based clock event device is unconditionally registered, but
> has the lowest possible rating such that any broadcast-capable HW clock
> event device present will be chosen in preference as the tick broadcast
> device.
> 
> Cc: Preeti U Murthy 
> Acked-by: Will Deacon 
> Acked-by: Mark Rutland 
> Signed-off-by: Lorenzo Pieralisi 
> ---
> changes in v2:
> 
> - Reworded the commit log according to reviews
> 
> It should be ready to go.
> 
> Thanks,
> Lorenzo
> 
>  arch/arm64/kernel/time.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index 6815987..1a7125c 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -18,6 +18,7 @@
>   * along with this program.  If not, see .
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -69,6 +70,8 @@ void __init time_init(void)
>   of_clk_init(NULL);
>   clocksource_of_init();
>  
> + tick_setup_hrtimer_broadcast();
> +
>   arch_timer_rate = arch_timer_get_rate();
>   if (!arch_timer_rate)
>   panic("Unable to initialise architected timer.\n");
> 
Reviewed-by: Preeti U Murthy 

--
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 -tip/urgent ] [BUGFIX] perf/probe: Fix a segfault if asked for variable it doesn't find

[Namhyung Kim]

Hi Masami,

On Thu, 29 May 2014 19:52:32 +0900, Masami Hiramatsu wrote:
> Fix a segfault bug by asking for variable it doesn't find.
> Since the convert_variable() didn't handle error code returned
> from convert_variable_location(), it just passed an incomplete
> variable field and then a segfault was occured when formatting
> the field.
>
> This fixes that bug by handling success code correctly in
> convert_variable(). Other callers of convert_variable_location()
> are correctly checking the return code.
>
> This bug was introduced by following commit. But another hidden
> erroneous error handling has been there previuosly (-ENOMEM case).

And -ERANGE too.. :)

Thanks,
Namhyung

>
>  commit 3d918a12a1b3088ac16ff37fa52760639d6e2403
>
> Signed-off-by: Masami Hiramatsu 
> Reported-by: Arnaldo Carvalho de Melo 
> Cc: Peter Zijlstra 
> Cc: Paul Mackerras 
> Cc: Ingo Molnar 
> Cc: Namhyung Kim 
> Cc: Jiri Olsa 
> ---
>  tools/perf/util/probe-finder.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
> index 5627621..9d8eb26 100644
> --- a/tools/perf/util/probe-finder.c
> +++ b/tools/perf/util/probe-finder.c
> @@ -511,12 +511,12 @@ static int convert_variable(Dwarf_Die *vr_die, struct 
> probe_finder *pf)
>  
>   ret = convert_variable_location(vr_die, pf->addr, pf->fb_ops,
>   &pf->sp_die, pf->tvar);
> - if (ret == -ENOENT)
> + if (ret == -ENOENT || ret == -EINVAL)
>   pr_err("Failed to find the location of %s at this address.\n"
>  " Perhaps, it has been optimized out.\n", pf->pvar->var);
>   else if (ret == -ENOTSUP)
>   pr_err("Sorry, we don't support this variable location yet.\n");
> - else if (pf->pvar->field) {
> + else if (ret == 0 && pf->pvar->field) {
>   ret = convert_variable_fields(vr_die, pf->pvar->var,
> pf->pvar->field, &pf->tvar->ref,
> &die_mem);
--
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 4/4] virtio_ring: unify direct/indirect code paths.

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> On Thu, May 29, 2014 at 04:56:45PM +0930, Rusty Russell wrote:
>> virtqueue_add() populates the virtqueue descriptor table from the sgs
>> given.  If it uses an indirect descriptor table, then it puts a single
>> descriptor in the descriptor table pointing to the kmalloc'ed indirect
>> table where the sg is populated.
>> +for (i = 0; i < total_sg; i++)
>> +desc[i].next = i+1;
>> +return desc;
>
> Hmm we are doing an extra walk over descriptors here.
> This might hurt performance esp for big descriptors.

Yes, this needs to be benchmarked; since it's cache hot my gut feel is
that it's a NOOP, but on modern machines my gut feel is always wrong.

>> +if (vq->indirect && total_sg > 1 && vq->vq.num_free)
>> +desc = alloc_indirect(total_sg, gfp);
>
> else desc = NULL will be a bit clearer won't it?

Agreed.

>>  /* Update free pointer */
>> -vq->free_head = i;
>> +if (desc == vq->vring.desc)
>> +vq->free_head = i;
>> +else
>> +vq->free_head = vq->vring.desc[head].next;
>
> This one is slightly ugly isn't it?

Yes, but it avoided another variable, and I was originally aiming
at stack conservation.  Turns out adding 'bool indirect' adds 32 bytes
more stack for gcc 4.6.4 :(

virtio_ring: minor neating

Before:
gcc 4.8.2: virtio_blk: stack used = 408
gcc 4.6.4: virtio_blk: stack used = 432

After:
gcc 4.8.2: virtio_blk: stack used = 408
gcc 4.6.4: virtio_blk: stack used = 464

Signed-off-by: Rusty Russell 

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 3adf5978b92b..7a7849bc26af 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -141,9 +141,10 @@ static inline int virtqueue_add(struct virtqueue *_vq,
 {
struct vring_virtqueue *vq = to_vvq(_vq);
struct scatterlist *sg;
-   struct vring_desc *desc = NULL;
+   struct vring_desc *desc;
unsigned int i, n, avail, uninitialized_var(prev);
int head;
+   bool indirect;
 
START_USE(vq);
 
@@ -176,21 +177,25 @@ static inline int virtqueue_add(struct virtqueue *_vq,
 * buffers, then go indirect. FIXME: tune this threshold */
if (vq->indirect && total_sg > 1 && vq->vq.num_free)
desc = alloc_indirect(total_sg, gfp);
+   else
+   desc = NULL;
 
if (desc) {
/* Use a single buffer which doesn't continue */
vq->vring.desc[head].flags = VRING_DESC_F_INDIRECT;
vq->vring.desc[head].addr = virt_to_phys(desc);
-   /* avoid kmemleak false positive (tis hidden by virt_to_phys) */
+   /* avoid kmemleak false positive (hidden by virt_to_phys) */
kmemleak_ignore(desc);
vq->vring.desc[head].len = total_sg * sizeof(struct vring_desc);
 
/* Set up rest to use this indirect table. */
i = 0;
total_sg = 1;
+   indirect = true;
} else {
desc = vq->vring.desc;
i = head;
+   indirect = false;
}
 
if (vq->vq.num_free < total_sg) {
@@ -230,10 +235,10 @@ static inline int virtqueue_add(struct virtqueue *_vq,
desc[prev].flags &= ~VRING_DESC_F_NEXT;
 
/* Update free pointer */
-   if (desc == vq->vring.desc)
-   vq->free_head = i;
-   else
+   if (indirect)
vq->free_head = vq->vring.desc[head].next;
+   else
+   vq->free_head = i;
 
/* Set token. */
vq->data[head] = data;
--
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 0/5] I2C ACPI operation region handler

[Lan Tianyu]

On 05/20/2014 08:59 PM, Lan Tianyu wrote:

ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation
region. It allows ACPI aml code able to access such kind of devices to
implement some ACPI standard method.

On the Asus T100TA, Bios use GenericSerialBus operation region to access
i2c device to get battery info. So battery function depends on the I2C
operation region support. Here is the bug link.
https://bugzilla.kernel.org/show_bug.cgi?id=69011



Hi Wolfram:
Since this version resolved all comments, it's ok for you?


Change since V2:
 Drop patchs of adding I2C smbus quick read/write and word/block
process call functions because not find machines supporting such protocols
so far and can't test these functions.
 Merge patchs of "I2C ACPI related code clear up" and "Add 
CONFIG_I2C_ACPI
config"
Patch 2: Add acpi_bus_detach_private_data() function to detach data from
ACPI handle and replace ACPI_ERROR() with acpi_handle_debug() to avoid some 
redundant
error log.

Change since V1:
Fix some code style issues. Change prefix i2c_acpi to acpi_i2c.
Move ACPI related code in the i2c core to i2c-acpi.c. Add CONFIG_I2C_ACPI
and make i2c core built-in when it's set to avoid i2c ACPI operation region
being removed.

Lan Tianyu (5):
   ACPICA: Export acpi_buffer_to_resource symbol
   ACPI: Add acpi_bus_attach_private_data() to facilitate to attach data
 to ACPI handle
   ACPI/Thermal: Use acpi_bus_attach_private_data() to attach private
 data
   I2C/ACPI: Add i2c ACPI operation region support
   I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI config

  drivers/acpi/acpica/rscreate.c |   1 +
  drivers/acpi/bus.c |  28 +++-
  drivers/acpi/thermal.c |  11 +-
  drivers/i2c/Kconfig|  18 +-
  drivers/i2c/Makefile   |   5 +-
  drivers/i2c/i2c-acpi.c | 362 +
  drivers/i2c/i2c-core.c |  97 +--
  include/acpi/acpi_bus.h|   2 +
  include/linux/acpi.h   |  11 ++
  include/linux/i2c.h|  12 ++
  10 files changed, 439 insertions(+), 108 deletions(-)
  create mode 100644 drivers/i2c/i2c-acpi.c



--
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] arm64: kernel: initialize broadcast hrtimer based clock event device

[Preeti U Murthy]

On 05/29/2014 06:09 PM, Mark Rutland wrote:
> Hi Preeti,
> 
> On Thu, May 29, 2014 at 12:04:36PM +0100, Preeti U Murthy wrote:
>> Hi Lorenzo,
>>
>> On 05/29/2014 02:53 PM, Lorenzo Pieralisi wrote:
>>> On platforms implementing CPU power management, the CPUidle subsystem
>>> can allow CPUs to enter idle states where local timers logic is lost on 
>>> power
>>> down. To keep the software timers functional the kernel relies on an
>>> always-on broadcast timer to be present in the platform to relay the
>>> interrupt signalling the timer expiries.
>>>
>>> For platforms implementing CPU core gating that do not implement an 
>>> always-on
>>> HW timer or implement it in a broken way, this patch adds code to initialize
>>> the kernel software broadcast hrtimer upon boot. It relies on a dynamically
>>
>> It would be best to use the term "hrtimer based broadcast device"
>> throughout the changelog for uniformity and to avoid confusion instead
>> of mixing it with "software broadcast".
>>
>>> chosen CPU to be always powered-up. This CPU then relays the timer interrupt
>>> to CPUs in deep-idle states through its HW local timer device.
>>>
>>> On systems with power management capabilities but no functional HW broadcast
>>> tick device, the hrtimer based clock event device allows the kernel to
>>> enter high-resolution timer mode, which improves system latencies and saves
>>> dynamic power.
>>
>> Sorry but I do not understand the above paragraph. What do you mean by
>> "allows the kernel to enter high resolution timer mode" ? And how does
>> it improve system latency? I understand that the hrtimer based
>> clockevent device saves dynamic power since it provides a mechanism in
>> which cpus can enter deeper idle states.
> 
> When there's no oneshot-capable broadcast device and the CPU-local
> clock_event_device has the CLK_EVT_FEAT_C3STOP flag,
> tick_is_oneshot_available will return false. Thus
> tick_check_oneshot_change will return false, and hrtimer_switch_to_hres
> will never switch to high resolution mode (and we can also never enter
> NOHZ mode), leaving us stuck in periodic mode.
> 
> In periodic mode ticks occur at fixed intervals, and any timer wakeup
> will occur after the tick following the requested wakeup time, adding
> some amount of latency over what would be possible with high resolution
> mode. Additionally, as we can only wake up at said ticks and not between
> them, it's possible that several timers for intervals shorter than that
> tick interval will fire at once upon a timer tick. Any tasks which
> requested these wakeups will fight for CPU time, and some will see
> additional latency because of this.

Ah ok I see now. Thanks for the explanation :)

> 
>>>
>>> The side effect of having a CPU always-on has implications on power 
>>> management
>>> platform capabilities and makes CPUidle suboptimal, since at least a CPU is
>>> kept always in a shallow idle state by the kernel to relay timer interrupts,
>>> but at least leaves the kernel with a functional system with some working 
>>> power
>>> management capabilities.
>>>
>>> The hrtimer based clock event device has lowest possible rating so that,
>>> if a platform contains a functional HW clock event device with broadcast
>>> capabilities, that device is always chosen as a tick broadcast device 
>>> instead
>>> of the software based one, now present by default.
>>
>> I think this statement "instead of the software based one, now present
>> by default" is incorrect. The hrtimer based clock event device will come
>> into picture only when the arch calls tick_setup_hrtimer_broadcast()
>> explicitly. Otherwise either the arch should register a real clock
>> device which does broadcast or should disable deep idle states where the
>> local timers stop. So I would suggest skipping the last paragraph as it
>> is not conveying anything in specific. The fact that a clock device with
>> the highest rating will be chosen is already known and need not be
>> mentioned explicitly IMHO.
> 
> I think it is worth keeping the paragraph to allay anyone's fear that
> the hrtimer based broadcast device might be selected in preference to a
> real suitable clock. I would otherwise not be aware that the hrtimer
> based broadcast device had the lowest rating (and would have to go and
> look that up separately).
> 
> As the arch code has delegated timer registration to
> clocksoruce_of_init, it doesn't know whether any of the real devices
> that may have been registered are suitable as a broadcast source for
> oneshot events. So we can't conditionally register the hrtimer based
> broadcast device.
> 
> Perhaps we could replace "now present by default" with "which is
> unconditionally registered in case no suitable hardware device is
> present"?

Yes I would say "which gets registered in case no suitable hardware
devices is present." This would make it clearer.

Regards
Preeti U Murthy
> 
> Cheers,
> Mark.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-k

Re: [PATCH] block: virtio_blk: don't hold spin lock during world switch

[Ming Lei]

On Fri, May 30, 2014 at 11:35 AM, Jens Axboe  wrote:
> On 2014-05-29 21:34, Ming Lei wrote:
>>
>> On Fri, May 30, 2014 at 11:19 AM, Jens Axboe  wrote:
>>>
>>> On 2014-05-29 20:49, Ming Lei wrote:


 Firstly, it isn't necessary to hold lock of vblk->vq_lock
 when notifying hypervisor about queued I/O.

 Secondly, virtqueue_notify() will cause world switch and
 it may take long time on some hypervisors(such as, qemu-arm),
 so it isn't good to hold the lock and block other vCPUs.

 On arm64 quad core VM(qemu-kvm), the patch can increase I/O
 performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
  - without the patch: 14K IOPS
  - with the patch: 34K IOPS
>>>
>>>
>>>
>>> Patch looks good to me. I don't see a hit on my qemu-kvm testing, but it
>>> definitely makes sense and I can see it hurting in other places.
>>
>>
>> It isn't easy to observe the improvement on x86 VM, especially
>> with few vCPUs, because qemu-system-x86_64 only takes
>> several microseconds to handle the notification, but on arm64, it
>> may take hundreds of microseconds, so the improvement is
>> obvious on arm VM.
>>
>> I hope this patch can be merged, at least arm VM can benefit
>> from it.
>
>
> If Rusty agrees, I'd like to add it for 3.16 with a stable marker.

Interesting, even on x86, I still can observe the improvement
when the numjobs is set as 2 in the fio script(see commit log), but
when numjobs is set as 4, 8, 12, the difference isn't obvious between
patched kernel and non-patched kernel.

1, environment
- host: 2sockets, each CPU(4cores, 2 threads), total 16 logical cores
- guest: 16cores, 8GB ram
- guest kernel: 3.15-rc7-next with patch[1]
- fio: the script in commit log with numjobs set as 2

2, result
- without the patch: ~104K IOPS
- with the patch: ~140K IOPS


Rusty, considered the same trick has been applied in virt-scsi,
do you agree to take the same approach in virt-blk too?


[1], http://marc.info/?l=linux-kernel&m=140135041423441&w=2

Thanks,
--
Ming Lei
--
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: android: fix Missing a blank line after declarations warnings

[Scott Weir]

On Wed, May 28, 2014 at 02:30:27PM -0700, Greg KH wrote:
> On Wed, May 28, 2014 at 06:52:51PM +1000, Scott Weir wrote:
> > This patch corrects coding style issue:
> > WARNING: Missing a black line after declarations
> > 
> > Signed-off-by: Scott Weir 
> > ---
> >  drivers/staging/android/sync_debug.c | 4 
> 
> This file isn't in my tree.  Always work against linux-next, not Linus's
> tree for new patches.
> 
> thanks,
> 
> greg k-h

This patch was made against linux-next. Is it better to use your staging tree?

thanks
--
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]x86 efi: do not export efi runtime map in case old map

[Dave Young]

Ccing Simon.

Simon, appologize for not ccing you about this kernel patch. I see you have
applied the userspace patch for checking sysfs runtime existance.

The userspace patch depends on this patch but it is not harmful even without
this kernel patch. So applying the userspace patch before this one is still
safe.

On 05/30/14 at 11:20am, Dave Young wrote:
> 
> For ioremapped efi memory aka old_map the virt addresses are not persistant
> across kexec reboot. kexec-tools will read the runtime maps from sysfs then
> pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause
> kexec boot failure.
> 
> To address this issue do not export runtime maps in case efi old_map so
> userspace can use no efi boot instead.
> 
> Signed-off-by: Dave Young 
> ---
>  arch/x86/platform/efi/efi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 3781dd3..4d36932 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -919,6 +919,9 @@ static void __init save_runtime_map(void)
>   void *tmp, *p, *q = NULL;
>   int count = 0;
>  
> + if (efi_enabled(EFI_OLD_MEMMAP))
> + return;
> +
>   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
>   md = p;
>  
> -- 
> 1.8.3.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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] serial: imx: disable the receiver ready interrupt for imx_stop_rx

[Dirk Behme]

On 23.05.2014 06:32, Huang Shijie wrote:

This patch disables the receiver ready interrupt for imx_stop_rx.
It reduces the interrupt numbers when the uart is going to close
or suspend.

Signed-off-by: Huang Shijie 
---
  drivers/tty/serial/imx.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index ed6cdf7..6026101 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -440,6 +440,10 @@ static void imx_stop_rx(struct uart_port *port)

temp = readl(sport->port.membase + UCR2);
writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
+
+   /* disable the `Receiver Ready Interrrupt` */
+   temp = readl(sport->port.membase + UCR1);
+   writel(temp & ~UCR1_RRDYEN, sport->port.membase + UCR1);


Will this change cause a loss or a processing delay of RX characters 
pending in the RX FIFO ?


It is not clear whether disabling the receiver will clear the RX FIFO. 
My guess is that the contents of the RX FIFO will remain intact when 
the receiver is disabled. The RX interrupt has an opportunity to mop 
up these pending characters in the RX FIFO but disabling the RX 
interrupt has potential to leave those characters in the RX FIFO. Does 
it matter ?


Thanks

Dirk

--
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 0/2] perf tools: Factor sort elide

[Namhyung Kim]

On Fri, 23 May 2014 17:15:45 +0200, Jiri Olsa wrote:
> hi,
> factoring the elide code to make perf_hpp__should_skip
> function cheap call/check again.

Both look good to me!

Acked-by: Namhyung Kim 


>
> Also I was wondering.. do we want to get rid of sort_entry
> structs in favor of perf_hpp__* stuff? Any plans?

Probably.. but there's no plan for me currently. :)

Thanks,
Namhyung
--
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/2] x86,vdso: vdso build fixes and improvements

[Stephen Rothwell]

Hi Andy,

On Thu, 29 May 2014 15:49:52 -0700 Andy Lutomirski  wrote:
>
> On Thu, May 29, 2014 at 3:41 PM, Paul Gortmaker
>  wrote:
> > On 14-05-29 05:57 PM, Andy Lutomirski wrote:
> >> Patch 1 causes make;make to behave similarly to make if vdso2c fails.
> >> Patch 2 hopefully fixes x86 crossbuilds on big-endian machines.  I don't
> >> have a big-endian machine to test on, though.
> >
> > Since the x86 builds are unconditionally failing as-is now in
> > linux-next, perhaps Stephen [Cc'd] can layer these on the top of
> > the tree he'll be making within the next couple of hours to give
> > them a big-endian test.

I added them just after the merge of the tip tree today and will keep
them there until they (or somo other solution) turn up some other way.

> Stephen, if you do this, could you also send me some of the build outputs:
> 
> arch/x86/vdso/*.so.dbg
> arch/x86/vdso/*-image-*.c
> 
> I'd like to verify that the output is correct.  It would be
> unfortunate if the cross-built kernel had some subtle error.

OK, I will send them in a separate email.

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


signature.asc
Description: PGP signature

[PATCH 3/3] lib: crc32: Add some additional __pure annotations

[George Spelvin]

In case they help the compiler.

Signed-off-by: George Spelvin 
---
As long as I'm messing with it.  I also have a large patch to do this
to a number of lib/ headers if anyone wants.

Redundant "extern" removed to keep things within 80 columns.

 include/linux/crc32.h | 6 +++---
 lib/crc32.c   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/crc32.h b/include/linux/crc32.h
index bcb8e9d3..25e57f3a 100644
--- a/include/linux/crc32.h
+++ b/include/linux/crc32.h
@@ -8,8 +8,8 @@
 #include 
 #include 
 
-extern u32  crc32_le(u32 crc, unsigned char const *p, size_t len);
-extern u32  crc32_be(u32 crc, unsigned char const *p, size_t len);
+u32  crc32_le(u32 crc, unsigned char const *p, size_t len) __pure;
+u32  crc32_be(u32 crc, unsigned char const *p, size_t len) __pure;
 
 /**
  * crc32_le_combine - Combine two crc32 check values into one. For two
@@ -35,7 +35,7 @@ static inline u32  crc32_le_combine(u32 crc1, u32 crc2, 
size_t len2)
return crc32_le_shift(crc1, len2) ^ crc2;
 }
 
-extern u32  __crc32c_le(u32 crc, unsigned char const *p, size_t len);
+u32  __crc32c_le(u32 crc, unsigned char const *p, size_t len) __pure;
 
 /**
  * __crc32c_le_combine - Combine two crc32c check values into one. For two
diff --git a/lib/crc32.c b/lib/crc32.c
index 977167d6..cf0c8e08 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -54,7 +54,7 @@ MODULE_LICENSE("GPL");
 #if CRC_LE_BITS > 8 || CRC_BE_BITS > 8
 
 /* implements slicing-by-4 or slicing-by-8 algorithm */
-static inline u32
+static inline u32 __pure
 crc32_body(u32 crc, unsigned char const *buf, size_t len, const u32 
(*tab)[256])
 {
 # ifdef __LITTLE_ENDIAN
-- 
1.9.2

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

[PATCH 2/3] lib: crc32: mark test data __initconst

[George Spelvin]

>From 1ecab5281e3cfc8c2a61648410c8b25ba2654fcb Mon Sep 17 00:00:00 2001
From: George Spelvin 
Date: Thu, 29 May 2014 00:08:03 -0400
Subject: [PATCH 2/3] lib: crc32: mark test data __initconst

So it gets discarded after the selftest.

Signed-off-by: George Spelvin 
---
This is the patch I started with, when I was looking for lib/ self-test
code to emulate for my still-pending glob.c code.  But curiosity about
the combine code led me notice problems with it, and to study the
arch/x86/crypto code, where I also have a proposed patch.

Aren't tangents fun?

 lib/crc32.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/crc32.c b/lib/crc32.c
index a4a576f3..977167d6 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -341,7 +341,7 @@ EXPORT_SYMBOL(crc32_be);
 #ifdef CONFIG_CRC32_SELFTEST
 
 /* 4096 random bytes */
-static u8 __attribute__((__aligned__(8))) test_buf[] =
+static u8 const __aligned(8) test_buf[] __initconst =
 {
0x5b, 0x85, 0x21, 0xcb, 0x09, 0x68, 0x7d, 0x30,
0xc7, 0x69, 0xd7, 0x30, 0x92, 0xde, 0x59, 0xe4,
@@ -865,7 +865,7 @@ static struct crc_test {
u32 crc_le; /* expected crc32_le result */
u32 crc_be; /* expected crc32_be result */
u32 crc32c_le;  /* expected crc32c_le result */
-} test[] =
+} const test[] __initconst =
 {
{0x674bf11d, 0x0038, 0x0542, 0x0af6d466, 0xd8b6e4c1, 
0xf6e93d6c},
{0x35c672c6, 0x003a, 0x01aa, 0xc6d3dfba, 0x28aaf3ad, 
0x0fe92aca},
-- 
1.9.2

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

[PATCH 1/3] lib: crc32: Greatly shrink CRC combining code

[George Spelvin]

There's no need for a full 32x32 matrix, when rows before the last are
just shifted copies of the rows after them.

There's still room for improvement (especially on X86 processors with
CRC32 and PCLMUL instructions), but this is a large step in the
right direction.

The internal primitive is now called crc32_generic_shift and takes one
less argument; the XOR with crc2 is done in inline wrappers.

Signed-off-by: George Spelvin 
---
This is the significant patch; there other two patches are minor
cleanups that I did while in the area.

Tested extensively in user-space (the "power" variable is identical
to the last row of the current even/odd matrix in the previous code)
and with CONFIG_CRC32_SELFTEST:

[0.587152] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[0.587186] crc32: self tests passed, processed 225944 bytes in 115727 nsec
[0.587341] crc32c: CRC_LE_BITS = 64
[0.587373] crc32c: self tests passed, processed 225944 bytes in 59505 nsec
[0.596827] crc32_combine: 8373 self tests passed
[0.606259] crc32c_combine: 8373 self tests passed

Code shrunk; comments increased to match.
Pulling 2x32x32 bits = 256 bytes off the stack is a nice bonus.

 include/linux/crc32.h |  12 -
 lib/crc32.c   | 142 +++---
 2 files changed, 76 insertions(+), 78 deletions(-)

diff --git a/include/linux/crc32.h b/include/linux/crc32.h
index 7d275c4f..bcb8e9d3 100644
--- a/include/linux/crc32.h
+++ b/include/linux/crc32.h
@@ -29,7 +29,11 @@ extern u32  crc32_be(u32 crc, unsigned char const *p, size_t 
len);
  *with the same initializer as crc1, and crc2 seed was 0. See
  *also crc32_combine_test().
  */
-extern u32  crc32_le_combine(u32 crc1, u32 crc2, size_t len2);
+u32  crc32_le_shift(u32 crc, size_t len) __attribute_const__;
+static inline u32  crc32_le_combine(u32 crc1, u32 crc2, size_t len2)
+{
+   return crc32_le_shift(crc1, len2) ^ crc2;
+}
 
 extern u32  __crc32c_le(u32 crc, unsigned char const *p, size_t len);
 
@@ -51,7 +55,11 @@ extern u32  __crc32c_le(u32 crc, unsigned char const *p, 
size_t len);
  *seeded with the same initializer as crc1, and crc2 seed
  *was 0. See also crc32c_combine_test().
  */
-extern u32  __crc32c_le_combine(u32 crc1, u32 crc2, size_t len2);
+u32  __crc32c_le_shift(u32 crc, size_t len) __attribute_const__;
+static inline u32  __crc32c_le_combine(u32 crc1, u32 crc2, size_t len2)
+{
+   return __crc32c_le_shift(crc1, len2) ^ crc2;
+}
 
 #define crc32(seed, data, length)  crc32_le(seed, (unsigned char const 
*)(data), length)
 
diff --git a/lib/crc32.c b/lib/crc32.c
index 70f00ca5..a4a576f3 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -50,29 +50,6 @@ MODULE_AUTHOR("Matt Domsch ");
 MODULE_DESCRIPTION("Various CRC32 calculations");
 MODULE_LICENSE("GPL");
 
-#define GF2_DIM32
-
-static u32 gf2_matrix_times(u32 *mat, u32 vec)
-{
-   u32 sum = 0;
-
-   while (vec) {
-   if (vec & 1)
-   sum ^= *mat;
-   vec >>= 1;
-   mat++;
-   }
-
-   return sum;
-}
-
-static void gf2_matrix_square(u32 *square, u32 *mat)
-{
-   int i;
-
-   for (i = 0; i < GF2_DIM; i++)
-   square[i] = gf2_matrix_times(mat, mat[i]);
-}
 
 #if CRC_LE_BITS > 8 || CRC_BE_BITS > 8
 
@@ -155,51 +132,6 @@ crc32_body(u32 crc, unsigned char const *buf, size_t len, 
const u32 (*tab)[256])
 }
 #endif
 
-/* For conditions of distribution and use, see copyright notice in zlib.h */
-static u32 crc32_generic_combine(u32 crc1, u32 crc2, size_t len2,
-u32 polynomial)
-{
-   u32 even[GF2_DIM]; /* Even-power-of-two zeros operator */
-   u32 odd[GF2_DIM];  /* Odd-power-of-two zeros operator  */
-   u32 row;
-   int i;
-
-   if (len2 <= 0)
-   return crc1;
-
-   /* Put operator for one zero bit in odd */
-   odd[0] = polynomial;
-   row = 1;
-   for (i = 1; i < GF2_DIM; i++) {
-   odd[i] = row;
-   row <<= 1;
-   }
-
-   gf2_matrix_square(even, odd); /* Put operator for two zero bits in even 
*/
-   gf2_matrix_square(odd, even); /* Put operator for four zero bits in odd 
*/
-
-   /* Apply len2 zeros to crc1 (first square will put the operator for one
-* zero byte, eight zero bits, in even).
-*/
-   do {
-   /* Apply zeros operator for this bit of len2 */
-   gf2_matrix_square(even, odd);
-   if (len2 & 1)
-   crc1 = gf2_matrix_times(even, crc1);
-   len2 >>= 1;
-   /* If no more bits set, then done */
-   if (len2 == 0)
-   break;
-   /* Another iteration of the loop with odd and even swapped */
-   gf2_matrix_square(odd, even);
-   if (len2 & 1)
-   crc1 = gf2_matrix_times(odd, crc1);
-   len2 >>= 1;
-   } while

Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox

[Jassi Brar]

On Thu, May 29, 2014 at 9:13 PM, Matt Porter  wrote:
> On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
>> On 15 May 2014 19:57, Arnd Bergmann  wrote:
>> > On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:
>
> ...
>
>> >> +struct mbox_controller {
>> >> + struct device *dev;
>> >> + struct mbox_chan_ops *ops;
>> >> + struct mbox_chan *chans;
>> >> + int num_chans;
>> >> + bool txdone_irq;
>> >> + bool txdone_poll;
>> >> + unsigned txpoll_period;
>> >> + struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
>> >> + const struct of_phandle_args *sp);
>> >> + /*
>> >> +  * If the controller supports only TXDONE_BY_POLL,
>> >> +  * this timer polls all the links for txdone.
>> >> +  */
>> >> + struct timer_list poll;
>> >> + unsigned period;
>> >> + /* Hook to add to the global controller list */
>> >> + struct list_head node;
>> >> +} __aligned(32);
>> >
>> > What is the __aligned(32) for?
>> >
>> Attempt to align access to mailbox?
>>
>> I am still open to opinion about whether the mailbox ownership should
>> be exclusive or shared among clients. Need to handle async messages
>> from remote is one reason one might want more than one client to own a
>> channel. Allowing for RX via notifiers might be one option but that
>> breaks semantics of 'ownership' of a mailbox channel.
>
> This is the case we have on a new family of Broadcom SoCs. One mailbox
> channel is the "system" channel and is shared amongst many clients for
> reception of unsolicited events from the coprocessor. The same channel
> is also used commonly in drivers for debug/inspection of the M0 state.
> Functionality for clock, pmu, pinmux, and cpu idle/suspend is implemented
> via IPC with the M0 so all of those drivers need to share one mailbox.
>
OK, so you have a single mailbox channel used for communication with
the remote master.

> There's a lot of common code necessary to construct/parse IPCs for
> each of the drivers. I suppose this IPC driver/api could be the
> sole owner of that system channel. However, we'd need to develop some
> binding to represent IPC resources that devices need to operate. Coming
> into this late...I wonder if I missed something about where these vendor
> specific IPC layers should live and how, if it makes sense, they should
> be represented in DT. In our case, the IPC is an integral part of the
> hardware as it's loaded from ROM.
>
Like other platforms, the IPC protocol is going to be very specific to
Broadcom, even if the mailbox controller is some popular third party
IP like PL320. So you/Broadcom have to implement parser code for IPC
(client) above the mailbox common api and the controller driver below
it. Any resource/feature specific to your client and your controller
should be passed via some Broadcom specific DT bindings. The common
mailbox api DT bindings provide only for channel-client mapping.

 Being more specific to your platform, I think you need some server
code (mailbox's client) that every driver (like clock, pmu, pinmux
etc) registers with to send messages to remote and receive commands
from remote ... perhaps by registering some filter to sort out
messages for each driver.

-Jassi
--
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 03/18] PCI: designware: Configuration space should be specified in 'reg'

[Kishon Vijay Abraham I]

Hi,

On Thursday 29 May 2014 10:02 PM, Murali Karicheri wrote:
> On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
>> The configuration address space has so far been specified in *ranges*,
>> however it should be specified in *reg* making it a platform MEM resource.
>> Hence used 'platform_get_resource_*' API to get configuration address
>> space in the designware driver.
>>
>> Cc: Jason Gunthorpe 
>> Cc: Bjorn Helgaas 
>> Cc: Mohit Kumar 
>> Cc: Jingoo Han 
>> Cc: Marek Vasut 
>> Cc: Arnd Bergmann 
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>   .../devicetree/bindings/pci/designware-pcie.txt|1 +
>>   drivers/pci/host/pcie-designware.c |   17 +++--
>>   2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> index d6fae13..8314360 100644
>> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> @@ -6,6 +6,7 @@ Required properties:
>>   as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
>>   - reg: base addresses and lengths of the pcie controller,
>>   the phy controller, additional register for the phy controller.
>> +The configuration address space should also be specified here.
> Kishon,
> 
> I am working on the Keystone PCI driver for which v1 is already posted. Want 
> to
> clarify
> following.
> 1. Original text for reg states "base addresses and lengths of the pcie
> controller,
> the phy controller, additional register for the phy controller" and 
> you
> added
> "The configuration address space should also be specified here"
> 
>and the code below added resource name "config"
> 
> Does PCI designware follow some convention? Does it mean after applying this 
> patch
> config name is mandatory or optional? Below code you are not returning error.
> Can you
> or author of PCI designware clarify what is expected to be present as 
> mandatory
> and
> what is optional.

>From whatever I could make out from the comments for my previous version,
'config' is mandatory for all new platforms adding support for PCIe DW. However
since there already exists platforms that use 'ranges', I'm not returning
error. Once all the platforms that use DW is modified to use 'reg', will return
error.
> 
> Does config refers to RC's config space or EP's config space or both? The code
> below divide

In the case of DRA7, it's the space from where you read the configuration space
contents of the EP (we have separate address space for the configuration space
of RC denoted by *rc_dbics* in this patch series). But there are other
platforms where RC does not have a separate configuration address space.
> the size by 2. So it appears to be RC's + EP's config space. Please clarify.

No. divide by 2 is for cfg1 and cfg1 is used by PCIe bridges.
> 
>>   - interrupts: interrupt values for level interrupt,
>>   pulse interrupt, special interrupt.
>>   - clocks: from common clock binding: handle to pci clock.
>> diff --git a/drivers/pci/host/pcie-designware.c
>> b/drivers/pci/host/pcie-designware.c
>> index c4e3732..603b386 100644
>> --- a/drivers/pci/host/pcie-designware.c
>> +++ b/drivers/pci/host/pcie-designware.c
>> @@ -20,6 +20,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>> #include "pcie-designware.h"
>> @@ -392,11 +393,23 @@ static const struct irq_domain_ops msi_domain_ops = {
>>   int __init dw_pcie_host_init(struct pcie_port *pp)
>>   {
>>   struct device_node *np = pp->dev->of_node;
>> +struct platform_device *pdev = to_platform_device(pp->dev);
>>   struct of_pci_range range;
>>   struct of_pci_range_parser parser;
>> +struct resource *cfg_res;
>>   u32 val;
>>   int i;
>>   +cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
>> "config");
>> +if (cfg_res) {
>> +pp->config.cfg0_size = resource_size(cfg_res)/2;
>> +pp->config.cfg1_size = resource_size(cfg_res)/2;
>> +pp->cfg0_base = cfg_res->start;
>> +pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
>> +} else {
>> +dev_err(pp->dev, "missing *config* reg space\n");
> This should return error -EINVAL.

ah.. it'll break for other platforms. It should be part of a different patch
once we convert all users to 8reg*.
> 
>> +}
>> +
>>   if (of_pci_range_parser_init(&parser, np)) {
>>   dev_err(pp->dev, "missing ranges property\n");
>>   return -EINVAL;
>> @@ -429,6 +442,8 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
>>   of_pci_range_to_resource(&range, np, &pp->cfg);
>>   pp->config.cfg0_size = resource_size(&pp->cfg)/2;
>>   pp->config.cfg1_size = resource_size(&pp->cfg)/2;
>> +pp->cfg0_base = pp->cfg.start;
>> +pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
>

Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems

[Andrew Cooks]

On Thu, May 29, 2014 at 4:29 AM, Bjorn Helgaas  wrote:
> On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote:
>> For testing, this version can be found in my git tree:
>>
>> git://github.com/awilliam/linux-vfio.git dma-alias-v4
>>
>> Please report any issues.
>>
>> v4:
>>  - Change dma_func_alias to dma_alias_devfn, holding a single
>>devfn to alias, thereby supporting aliases to the wrong slot.
>>The DMA alias iterator is easily changed, but IOMMU grouping
>>requires significant rework.  This is now done in IOMMU code
>>rather than PCI code.
>>
>>  - AMD-Vi - try to incorporate IVRS aliases dynamically into
>>PCI alias quirks to make sure that our grouping remains the
>>same.  Potentially this could end up reporting BIOS aliases
>>that we can add to our list of quirks.
>>
>> v3:
>>  - Found several instances where I had PCI_SLOT when I meant
>>PCI_FUNC.  Thanks to Andrew for spotting this.  This should
>>fix the problem he was having with Ricoh quirks.  We also
>>pruned down the func0 quirks to only those that we know are
>>needed.  We can always add them back later.
>>
>>  - Found a case in intel-iommu of using dev_is_pci() where I
>>really wanted !dev_is_pci().  Fixed.
>>
>> v2:
>>  - Several new Marvell controllers added to quirks.  There's been
>>a lot of success reported with this series in
>>https://bugzilla.kernel.org/show_bug.cgi?id=42679
>>
>>  - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do
>>not expose a PCIe capability.  These have been shown to use
>>the standard PCIe-to-PCI bridge requester ID.
>>
>>  - Fix copy/paste duplicate Ricoh quirk ID
>>
>>  - Fixed AMD IOMMU for the "ghost" function case where the DMA
>>alias is for an absent device.  The iommu rlookup table and
>>data fields need to be initializes.
>>
>>  - Fixed Intel interrupt remapping, I wasn't passing the target
>>bus number, only the alias bus number.
>>
>> These patches are split across PCI and IOMMU, but I've front-loaded
>> all of the PCI infrastructure so that the first 7 patches can be
>> applied to PCI-core, the IOMMU maintainers can pickup their patches,
>> then we can finish with dead code removal.  Bjorn might also be
>> willing to carry the IOMMU changes if the maintainers want to ack
>> them.
>
> I put 1-7 on a pci/iommu branch for v3.16.  I'm happy to include the rest,
> too, given acks from Joerg and David.  Or if they prefer to take them all,
> which might be easier than coordinating two trees, especially since there's
> PCI stuff at the beginning and end, here's my ack for the PCI bits (patches
> 1-7 and 15-16):
>
> Acked-by: Bjorn Helgaas 
>
> If you want to send me updated changelogs for patches 5 & 6, I'll drop
> those in.
>
> Didn't you have more testing reports?  I see George's, but I thought there
> were some others, too.
>
Tested-by: Andrew Cooks 

I've reviewed parts of this patch set, over multiple iterations, if
that's worth anything.

>> Original description:
>>
>> This series attempts to fix a couple issues we've had outstanding in
>> the PCI/IOMMU code for a while.  The first issue is with devices that
>> use the wrong requester ID for DMA transactions.  We already have a
>> sort of half-baked attempt to fix this for several Ricoh devices, but
>> the fix only helps them be useful through IOMMU groups, not the
>> general DMA case.  There are also several Marvell devices which use
>> use a different wrong requester ID and don't even fit into the DMA
>> source idea.  This series creates a DMA alias iterator that will
>> step through each possible alias of a device, allowing IOMMUs to
>> insert mappings for both the device and its aliases.
>>
>> Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge()
>> function, which is known to blowup when it finds itself suddenly at
>> a PCIe device without crossing a PCIe-to-PCI bridge (as identified by
>> the PCIe capability).  It also likes to make the invalid assumption
>> that a PCIe device never has its requester ID masked by any usptream
>> bus.  We can fix this using the above new DMA alias iterator, since
>> that's effectively what this function was meant to do.
>>
>> Finally, with all these helpers, it makes sense to consolidate code
>> for determining IOMMU groups.  The first step in finding the root
>> of a group is finding the final upstream DMA alias for the device,
>> then applying additional ACS rules and incorporating device specific
>> aliases.  As this is all common to PCI, create a single implementation
>> and remove piles of code from the individual IOMMU drivers.
>>
>> This series allows devices like the Marvell 88SE9123 to finally work
>> on Linux with either AMD-Vi or VT-d enabled on the box.  I've
>> collected device IDs from various bugs to support as many SKUs of
>> these devices as possible, but I'm sure there are others that I've
>> missed.
>>
>> This should also enable motherboards with an onboard ASmedia
>> ASM1083/1

Re: [RFC PATCH] crypto: crc32c-pclmul - Use pmovzxdq to shrink K_table

[George Spelvin]

Olay, recompiled with the acpi-cpufreq driver, so the performance governor
actually works, pegging the frequency at 3900 MHz.

Existing (old) code:
[  455.641397] 
[  455.641397] testing speed of crc32c
[  455.641403] test  0 (   16 byte blocks,   16 bytes per update,   1 updates): 
73 cycles/operation,4 cycles/byte
[  455.641406] test  1 (   64 byte blocks,   16 bytes per update,   4 updates): 
   418 cycles/operation,6 cycles/byte
[  455.641409] test  2 (   64 byte blocks,   64 bytes per update,   1 updates): 
89 cycles/operation,1 cycles/byte
[  455.641411] test  3 (  256 byte blocks,   16 bytes per update,  16 updates): 
  1330 cycles/operation,5 cycles/byte
[  455.641417] test  4 (  256 byte blocks,   64 bytes per update,   4 updates): 
   502 cycles/operation,1 cycles/byte
[  455.641420] test  5 (  256 byte blocks,  256 bytes per update,   1 updates): 
   170 cycles/operation,0 cycles/byte
[  455.641422] test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates): 
  4971 cycles/operation,4 cycles/byte
[  455.641440] test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates): 
   805 cycles/operation,0 cycles/byte
[  455.641445] test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates): 
   371 cycles/operation,0 cycles/byte
[  455.641448] test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates): 
  9839 cycles/operation,4 cycles/byte
[  455.641484] test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates): 
  1436 cycles/operation,0 cycles/byte
[  455.641490] test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates): 
   824 cycles/operation,0 cycles/byte
[  455.641494] test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates): 
   494 cycles/operation,0 cycles/byte
[  455.641498] test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates): 
 19561 cycles/operation,4 cycles/byte
[  455.641568] test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates): 
  2757 cycles/operation,0 cycles/byte
[  455.641579] test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates): 
  1633 cycles/operation,0 cycles/byte
[  455.641586] test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates): 
   861 cycles/operation,0 cycles/byte
[  455.641590] test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates): 
 39015 cycles/operation,4 cycles/byte
[  455.641729] test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates): 
  5412 cycles/operation,0 cycles/byte
[  455.641749] test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates): 
  3106 cycles/operation,0 cycles/byte
[  455.641762] test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates): 
  1656 cycles/operation,0 cycles/byte
[  455.641769] test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates): 
  1639 cycles/operation,0 cycles/byte
[  480.885336] 
[  480.885336] testing speed of crc32c
[  480.885342] test  0 (   16 byte blocks,   16 bytes per update,   1 updates): 
81 cycles/operation,5 cycles/byte
[  480.885345] test  1 (   64 byte blocks,   16 bytes per update,   4 updates): 
   426 cycles/operation,6 cycles/byte
[  480.885348] test  2 (   64 byte blocks,   64 bytes per update,   1 updates): 
96 cycles/operation,1 cycles/byte
[  480.885350] test  3 (  256 byte blocks,   16 bytes per update,  16 updates): 
  1331 cycles/operation,5 cycles/byte
[  480.885356] test  4 (  256 byte blocks,   64 bytes per update,   4 updates): 
   497 cycles/operation,1 cycles/byte
[  480.885359] test  5 (  256 byte blocks,  256 bytes per update,   1 updates): 
   179 cycles/operation,0 cycles/byte
[  480.885361] test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates): 
  4961 cycles/operation,4 cycles/byte
[  480.885380] test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates): 
   795 cycles/operation,0 cycles/byte
[  480.885384] test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates): 
   366 cycles/operation,0 cycles/byte
[  480.885387] test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates): 
  9827 cycles/operation,4 cycles/byte
[  480.885423] test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates): 
  1445 cycles/operation,0 cycles/byte
[  480.885430] test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates): 
   834 cycles/operation,0 cycles/byte
[  480.885434] test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates): 
   495 cycles/operation,0 cycles/byte
[  480.885437] test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates): 
 19560 cycles/operation,4 cycles/byte
[  480.885507] test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates): 
  2767 cycles/operation,0 cycles/byte
[  480.885518] test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates): 
  1643 cycles/operation,0 cycles/byte
[  480.885525] test 16 ( 4096 byte blocks, 4096 bytes per update,  

Re: [PATCH v11 0/3] Exynos 5410 support

[Tomasz Figa]

Hi Andreas,

On 29.05.2014 20:00, Andreas Färber wrote:

[snip]

> Some of the low-hanging fruit like no heartbeat/SD LEDs, no RTC, no
> usb3503 and thus no network I'm already looking into myself. For now I'm
> putting everything into the SMDK .dts, but I guess we'll need to split
> off -odroidxu.dts and -pinctrl.dtsi at some point.

Odroid XU needs its own dts for sure. I think you can make a copy of
SMDK dts and name it -odroidxu straightaway and work further with it.

exynos5410-pinctrl.dtsi is used for generic SoC-wide pinctrl
definitions, such as pin banks and pin groups. There should be no
board-specific things defined in it. Instead respective board dts should
have them.

> 
> What about graphics? The 5410 is an oddball in using PowerVR rather than
> Mali GPU - should a framebuffer on HDMI or DisplayPort work if we add DT
> nodes, or will the GPU require larger code changes?

The 3D GPU is completely independent from display controllers, which are
standard Samsung IP blocks, so you should be able to get unaccelerated
output using VP+Mixer+HDMI or FIMD+DP using existing drivers.

Best regards,
Tomasz
--
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/5] sc_phy:SmartCard(SC) PHY interface to SC controller

[Satish Patel]

On 5/29/2014 9:21 PM, Greg KH wrote:

On Thu, May 29, 2014 at 02:26:55PM +0530, Satish Patel wrote:



On 5/29/2014 12:14 AM, Greg KH wrote:

On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:

+/**
+ * struct sc_phy - The basic smart card phy structure
+ *
+ * @dev: phy device
+ * @pdata: pointer to phy's private data structure
+ * @set_config: called to set phy's configuration
+ * @get_config: called to get phy's configuration
+ * @activate_card: perform smart card activation
+ * @deactivate_card: perform smart card de-activation
+ * @warm_reset: execute smart card warm reset sequence
+ * @register_card_activity_cb: register call back to phy device.
+ * This call back will be called on card insert or remove event
+ *
+ * smart card controller uses this interface to communicate with
+ * smart card via phy.Some smart card phy has multiple slots for
+ * cards. This inerface also enables controller to communicate with
+ * one or more smart card connected over phy.
+ */
+struct sc_phy {
+   /* phy's device pointer */
+   struct device *dev;


So this is the "parent", right?  Why not embed a struct device into this
structure as well, further streaching out the device tree.


Do you mean to use "dev->p" for pdata ?


No, use the device itself.


I have kept it outside, to give easeness/pragmatic focal for new phy driver
development. Driver can make this pointer null and use above pointer.


Ick, no, that's not how the driver model works.  Each device in the
system needs a struct device, don't try to "chain" off of an existing
device like this.  Make it a "real" one.


+
+   /* phy's private data */
+   void *pdata;


If you do the above, then this pointer is not needed.



+
+   /* notify data, passed by interface user as a part of
+* register_notify API. Data should be passed back when
+* notification raised to the interface user
+*/
+   void *notify_data;


What makes this different from the pdata?

pdata is phy's private data, while notify_data is something phy will send to
smart card controller on some event, like card remove/insert/timeout etc..


That doesn't make much sense to me, why not just put that in the notify
function callback itself?


Little correction over here..
Here is brief flow
USIM(Smart Card Controller) register notification callback to smarcard phy.

usim->phy->register_notify(, , );
notify_data : pass back when callback function will be called by PHY


Smartcard PHY -> USIM
blocking_notifier_call_chain(, action, );

action : card insert/remove/overheat etc..
notify data: USIM data passing back (supplied at the time of cb 
registration)




Please either use the existing phy layer of the kernel, or make a "real"
subsystem here, don't try to put a tiny shim on top of an existing
struct device for this driver, that's not how subsystems in Linux are
done.

Why I am not using exiting PHY framework ?

We will be more than happy to adapt generic phy if it
includes/add support for smart card requirements like

1) Some smart card phy (TDA8026-NxP) has multiple slots for smart
cards. This interface enables controller to communicate with specific
smart card inserted to the specific phy's slot.
2) Warm reset to smart card inserted to phy slot.
3) Bit banging of smart card pins to support vendor specific memory
cards.
4) Notification of card insert/remove/overheat etc.
5) synchronous and asynchronous modes for smart card transaction




thanks,

greg k-h


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

Re: [PATCH] clk: exynos5420: Keep aclk66_peric enabled during boot

[Tomasz Figa]

Hi,

On 30.05.2014 00:29, Mike Turquette wrote:
> Quoting Doug Anderson (2014-05-29 14:21:36)
>> Right now if you've got earlyprintk enabled on exynos5420-peach-pit
>> then you'll get a hang on boot.  Here's why:
>>
>> 1. The i2c-s3c2410 driver will probe at subsys_initcall.  It will
>>enable its clock and disable it.  This is the clock "i2c2".
>> 2. The act of disabling "i2c2" will disable its parents.  In this case
>>the parent is "aclk66_peric".  There are no other children of
>>"aclk66_peric" officially enabled, so "aclk66_peric" will be turned
>>off (despite being CLK_IGNORE_UNUSED, but that's by design).
>> 3. The next time you try to earlyprintk you'll do so without the UART
>>clock enabled.  That's because the UART clocks are also children of
>>"aclk66_peric".  You'll hang.
>>
>> There's no good place to put a clock enable for earlyprintk, which is
>> handled by a bunch of assembly code.  The best we can do is to handle
>> this in the clock driver.
>>
>> Signed-off-by: Doug Anderson 
>> ---
>>  drivers/clk/samsung/clk-exynos5420.c | 24 
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 9d7d7ee..1e586be 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -1172,11 +1172,17 @@ static struct of_device_id ext_clk_match[] 
>> __initdata = {
>> { },
>>  };
>>  
>> +/* Keep these clocks on until late_initcall */
>> +static const char *boot_clocks[] __initconst = {
>> +   "aclk66_peric",
>> +};
>> +
>>  /* register exynos5420 clocks */
>>  static void __init exynos5x_clk_init(struct device_node *np,
>> enum exynos5x_soc soc)
>>  {
>> struct samsung_clk_provider *ctx;
>> +   int i;
>>  
>> if (np) {
>> reg_base = of_iomap(np, 0);
>> @@ -1226,6 +1232,12 @@ static void __init exynos5x_clk_init(struct 
>> device_node *np,
>> }
>>  
>> exynos5420_clk_sleep_init();
>> +
>> +   for (i = 0; i < ARRAY_SIZE(boot_clocks); i++) {
>> +   struct clk *to_enable = __clk_lookup(boot_clocks[i]);
> 
> How about replacing __clk_lookup with clk_get? You can keep the struct
> clk object hanging around for later...
> 

Mike, correct me if I'm wrong, but I thought you need clkdev look-up
entry for clk_get() to find a clock. Here, this clock apparently don't
have one and you don't even have a struct device * to pass to clk_get(),
so even if you had a look-up entry, it would need to be a wildcard entry
(with NULL device), which wouldn't be too elegant.

Doug, isn't a similar thing needed for PM debug as well? Maybe having
this clock always ungated whenever DEBUG_LL is enabled would be enough?

Best regards,
Tomasz
--
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/3] mfd: intel_soc_pmic: Core driver

[Zhu, Lejun]

On 5/29/2014 7:40 PM, Lee Jones wrote:
> [...]
> 
>> +static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>> +{
>> +struct gpio_desc *desc;
>> +int irq;
>> +
>> +desc = devm_gpiod_get_index(dev, KBUILD_MODNAME, 0);
> 
> What does "KBUILD_MODNAME" translate to?

It translates into "intel_soc_pmic".

> 
>> +if (IS_ERR(desc)) {
>> +dev_dbg(dev, "Not using GPIO as interrupt.\n");
> 
> You can't have a debug print, then return an err - use dev_err().

Actually returning ENOENT here is just a hardware difference. On some
boards the PMIC interrupt is from a GPIO line exposed by the CPU, on the
rest (e.g. Asus T100TA) it's not. When -ENOENT is returned, probe() will
simply use the IRQ provided by the I2C.

I will remove this line completely, and put a comment before the function.

> 
> [...]
> 
>> +static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>> +const struct i2c_device_id *id)
>> +{
>> +struct device *dev = &i2c->dev;
>> +struct intel_soc_pmic_config *config =
>> +(struct intel_soc_pmic_config *)id->driver_data;
>> +struct intel_soc_pmic *pmic;
>> +int ret;
>> +int irq;
>> +
>> +pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
>> +dev_set_drvdata(dev, pmic);
>> +
>> +pmic->regmap = devm_regmap_init_i2c(i2c, config->regmap_config);
>> +
>> +irq = intel_soc_pmic_find_gpio_irq(dev);
>> +if (irq < 0)
>> +pmic->irq = i2c->irq;
>> +else
>> +pmic->irq = irq;
> 
> pmic->irq = (irq < 0) ? i2c->irq : irq;

I'll fix it.

>> +ret = regmap_add_irq_chip(pmic->regmap, pmic->irq,
>> +  config->irq_flags | IRQF_ONESHOT,
>> +  0, config->irq_chip,
>> +  &pmic->irq_chip_data);
>> +if (ret)
>> +goto err;
> 
> Just return ret here and remove the 'err:' label.

I'll fix it.

> 
> [...]
> 
>> +static const struct i2c_device_id intel_soc_pmic_i2c_id[] = {
>> +{"INT33FD:00", (kernel_ulong_t)&intel_soc_pmic_config_crc},
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, intel_soc_pmic_i2c_id);
>> +
>> +static struct acpi_device_id intel_soc_pmic_acpi_match[] = {
>> +{"INT33FD", (kernel_ulong_t)&intel_soc_pmic_config_crc},
>> +{ },
>> +};
>> +MODULE_DEVICE_TABLE(acpi, intel_soc_pmic_acpi_match);
> 
> Does ACPI have a match function to extact it's .driver_data attribute?
> 
> If so, are you using it here? If not, why not?
> 

The ACPI table is used in i2c_device_match(), and the i2c table is used
in i2c_device_probe(), so the id in the i2c table is actually fed to
intel_soc_pmic_probe(). But I only found out now that having the i2c
table alone is enough, because i2c_device_match will fallback to the i2c
table if there's no ACPI table. So to keep it simple, I'll remove the
ACPI table completely.

By the way, the GPIO child driver got reviewed-by from Linus Walleij,
but can't be merged because it depends on intel_soc_pmic.h. May I
include it in next version of the patch set and have it merged along
with the MFD driver?

Best Regards
Lejun
--
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: [PATCHSET 00/27] perf tools: Add support to accumulate hist periods (v11)

[Namhyung Kim]

On Thu, 29 May 2014 15:59:00 +0200, Jiri Olsa wrote:
> On Thu, May 29, 2014 at 12:58:03PM +0900, Namhyung Kim wrote:
>> Hello,
>> 
>> This is a new attempt to implement cumulative hist period report.
>> This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
>> rewrote it from scratch.
>> 
>> This patchset basically adds period in a sample to every node in the
>> callchain.  A hist_entry now has an additional fields to keep the
>> cumulative period if --children option is given on perf report.
>> 
>> I changed the option as a separate --children and added a new
>> "Children" column (and renamed the default "Overhead" column into
>> "Self").  The output will be sorted by children (cumulative) overhead
>> for now.  It also adds 'overhead_children' field to -F/--fields option
>> to be selected by user and it'll show you "N/A" if the cumulation is
>> not supported (due to missing callchain).
>> 
>> I added Tested-by from Rodrigo Campos since this version is basically
>> rebase of previous series + bugfix.  But it still needs to be tested
>> more intensively IMHO.  Also note that, this will change default
>> behavior of perf report/top if callchain is recorded, so might confuse
>> old users.  Let's see how many of them come to shout. :)  I think we
>> need to merge Jiri's TUI column header patch at least.
>> 
>> 
>>  * changes in v11:
>>   - factor out hists__inc_nr_samples  (Jiri)
>>   - remove unrelated change  (Jiri)
>>   - disable accumulation on branch or mem mode
>>   - slightly refactor hist_iter code
>
> apart from that comment I sent, I think it's ready to go in

Thanks!  As I said, I've pushed v12 to korg with change you commented.

And I also found that the overhead in perf_hpp__should_skip() is
strangely high.. will check your patch.

Thanks,
Namhyung
--
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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

[Linus Torvalds]

On Thu, May 29, 2014 at 9:50 PM, Al Viro  wrote:
>
> BTW, how serious is the problem with __lockref_is_dead(&dentry->d_lockref)
> with only ->d_parent->d_lock held?  From my reading of lib/lockref.c it
> should be safe - we only do lockref_mark_dead() with ->d_parent->d_lock
> held, and it'll provide all the serialization and barriers we need.
>
> If I'm right, we could get rid of DCACHE_DENTRY_KILLED completely

Yeah, I think that would be good. Except I think you should create a
"dentry_is_dead()" helper function that then has that "if you hold the
dentry or parent lock, this is safe" comment, because for lockref in
general you do need to have the lock in the lockref itself. The fact
that dentries have more locking is very much dentry-specific.

But with that, go wild. I'd love to get rid of some of the redundant stuff.

For another example, the

BUG_ON((int)dentry->d_lockref.count > 0);

test makes very little sense any more with lockrefs and the whole dead
marker (that should make sure that it never gets incremented), but
exists due to the direct conversion.

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

Re: [PATCH v4 2/3] mfd: intel_soc_pmic: Crystal Cove support

[Zhu, Lejun]

On 5/29/2014 7:49 PM, Lee Jones wrote:
> On Thu, 29 May 2014, Zhu, Lejun wrote:
> 
>> This patch provides chip-specific support for Crystal Cove. Crystal
>> Cove is the PMIC in Baytrail-T platform.
(...)
>> +enum crystal_cove_irq {
>> +PWRSRC_IRQ = 0,
>> +THRM_IRQ,
>> +BCU_IRQ,
>> +ADC_IRQ,
>> +CHGR_IRQ,
>> +GPIO_IRQ,
>> +VHDMIOCP_IRQ
>> +};
> 
> I can't help thinking that these should be nice clear #defines
> 
> #define CRYSTAL_COVE_IRQ_PWSRC0
> ...
> #define CRYSTAL_COVE_IRQ_VHDMIOCP 6
> 

Sure. I'll fix it.

Best Regards
Lejun

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

Re: [PATCH v4 3/3] mfd: intel_soc_pmic: Build files

[Zhu, Lejun]

On 5/29/2014 7:43 PM, Lee Jones wrote:
>> This patch adds Intel SoC PMIC support to the build files.
> These changes shouldn't really be in a separate patch.
I'll move them into the first (core.c) patch.

Best Regards
Lejun


--
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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

[Al Viro]

On Thu, May 29, 2014 at 12:14:51PM -0700, Linus Torvalds wrote:
> Yeah, I don't think you can reproduce that, but I guess renaming
> directories into each other (two renames needed) could trigger an ABBA
> deadlock by changing the topological order of dentry/parent.
> 
> I suspect there's no way in hell that tiny race will ever happen in
> practice, but let's not risk it.
> 
> And your solution (to re-check after just taking the parent lock)
> seems sufficient and sane, since dentry_lock_for_move() will always
> take the parent lock(s) before we move a dentry.
> 
> So that looks good to me.

BTW, how serious is the problem with __lockref_is_dead(&dentry->d_lockref)
with only ->d_parent->d_lock held?  From my reading of lib/lockref.c it
should be safe - we only do lockref_mark_dead() with ->d_parent->d_lock
held, and it'll provide all the serialization and barriers we need.

If I'm right, we could get rid of DCACHE_DENTRY_KILLED completely and replace
checking for it with checking for negative ->d_lockref.count.  There are two
places where we check for it; in shrink_dentry_list() we definitely can go
that way (we are holding ->d_lock there) and it simplifies the code nicely.
In d_walk(), though (in the bit that used to be try_to_ascend() we only hold
->d_parent->d_lock.  It looks like that ought to be safe to replace
if (this_parent != child->d_parent ||  
 (child->d_flags & DCACHE_DENTRY_KILLED) ||
 need_seqretry(&rename_lock, seq)) {
with
if (this_parent != child->d_parent ||  
 __lockref_is_dead(&child->d_lockref) ||
 need_seqretry(&rename_lock, seq)) {
and remove DCACHE_DENTRY_KILLED completely...

The other user (in shrink_dentry_list()) simplifies to
if (dentry->d_lockref.count != 0) {
bool can_free = dentry->d_flags & DCACHE_MAY_FREE;
spin_unlock(&dentry->d_lock);
if (parent)
spin_unlock(&parent->d_lock);
if (can_free)
dentry_free(dentry);
continue;
}
taking care of both the DCACHE_DENTRY_KILLED case and simple "lazy dget"
one, and that one's definitely safe and worth doing.

Would be nice if we could switch d_walk() one as well and kill that flag off,
though...

Basically, we have
spin_lock(&A);
spin_lock(&R.lock);
V = 1;
lockref_mark_dead(&R);
...
as the only place where R goes dead and we want to replace
spin_lock(&A);
if (V)
...
with
spin_lock(&A);
if (__lockref_is_dead(&R))
...
Unless I'm missing something subtle in lockref.c, that should be safe...
Comments?
--
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 18/27] perf tools: Add callback function to hist_entry_iter

[Namhyung Kim]

On Thu, 29 May 2014 15:16:51 +0200, Jiri Olsa wrote:
> On Thu, May 29, 2014 at 12:58:21PM +0900, Namhyung Kim wrote:
>> +static int hist_iter__report_callback(struct hist_entry_iter *iter,
>> +  struct addr_location *al, void *arg)
>> +{
>> +int err = 0;
>> +struct hist_entry *he = iter->he;
>> +struct perf_evsel *evsel = iter->evsel;
>> +struct report *rep = arg;
>> +
>> +if (ui__has_annotation())
>> +err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
>
> if we put the annotation stats in here, shouldn't we remove all other
> instancies of above call from:
>
>   iter_finish_normal_entry
>   iter_add_single_cumulative_entry
>   iter_finish_mem_entry

Right, they were double counted..  :-/  I changed this as below and push
to perf/cumulate-v12.  Would you please check it again?

Thanks,
Namhyung


>From 0be9139edf446a5d6d753698f42809b2212dcf76 Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Tue, 7 Jan 2014 17:02:25 +0900
Subject: [PATCH] perf tools: Add callback function to hist_entry_iter

The new ->add_entry_cb() will be called after an entry was added to
the histogram.  It's used for code sharing between perf report and
perf top.  Note that ops->add_*_entry() should set iter->he properly
in order to call the ->add_entry_cb.

Also pass @arg to the callback function.  It'll be used by perf top
later.

Tested-by: Arun Sharma 
Tested-by: Rodrigo Campos 
Acked-by: Jiri Olsa 
Cc: Frederic Weisbecker 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-report.c | 61 -
 tools/perf/tests/hists_filter.c |  2 +-
 tools/perf/tests/hists_output.c |  2 +-
 tools/perf/util/hist.c  | 67 +++--
 tools/perf/util/hist.h  |  5 ++-
 5 files changed, 84 insertions(+), 53 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 6cac509212ee..21d830bafff3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -80,14 +80,59 @@ static int report__config(const char *var, const char 
*value, void *cb)
return perf_default_config(var, value, cb);
 }
 
-static void report__inc_stats(struct report *rep,
- struct hist_entry *he __maybe_unused)
+static void report__inc_stats(struct report *rep, struct hist_entry *he)
 {
/*
-* We cannot access @he at this time.  Just assume it's a new entry.
-* It'll be fixed once we have a callback mechanism in hist_iter.
+* The @he is either of a newly created one or an existing one
+* merging current sample.  We only want to count a new one so
+* checking ->nr_events being 1.
 */
-   rep->nr_entries++;
+   if (he->stat.nr_events == 1)
+   rep->nr_entries++;
+}
+
+static int hist_iter__report_callback(struct hist_entry_iter *iter,
+ struct addr_location *al, bool single,
+ void *arg)
+{
+   int err = 0;
+   struct report *rep = arg;
+   struct hist_entry *he = iter->he;
+   struct perf_evsel *evsel = iter->evsel;
+   struct mem_info *mi;
+   struct branch_info *bi;
+
+   report__inc_stats(rep, he);
+
+   if (!ui__has_annotation())
+   return 0;
+
+   if (sort__mode == SORT_MODE__BRANCH) {
+   bi = he->branch_info;
+   err = addr_map_symbol__inc_samples(&bi->from, evsel->idx);
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(&bi->to, evsel->idx);
+
+   } else if (rep->mem_mode) {
+   mi = he->mem_info;
+   err = addr_map_symbol__inc_samples(&mi->daddr, evsel->idx);
+   if (err)
+   goto out;
+
+   err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+
+   } else if (symbol_conf.cumulate_callchain) {
+   if (single)
+   err = hist_entry__inc_addr_samples(he, evsel->idx,
+  al->addr);
+   } else {
+   err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+   }
+
+out:
+   return err;
 }
 
 static int process_sample_event(struct perf_tool *tool,
@@ -100,6 +145,7 @@ static int process_sample_event(struct perf_tool *tool,
struct addr_location al;
struct hist_entry_iter iter = {
.hide_unresolved = rep->hide_unresolved,
+   .add_entry_cb = hist_iter__report_callback,
};
int ret;
 
@@ -127,9 +173,8 @@ static int process_sample_event(struct perf_tool *tool,
if (al.map != NULL)
al.map->dso->hit = 1;
 
-   report__inc_stats(rep, NULL);
-
-   ret = hist_entry_iter__add(&iter, &al, evsel, sample, rep->max_stack);
+   ret = hist_entry_iter__add(&iter, &al, evsel, sample, rep->max_stack,

Re: [RFC PATCH 3/3] clk: tegra: Implement Tegra124 shared/cbus clks

[Mike Turquette]

Quoting Nishanth Menon (2014-05-29 16:22:45)
> On 05/26/2014 08:07 AM, Thierry Reding wrote:
> > On Wed, May 14, 2014 at 12:35:18PM -0700, Mike Turquette wrote:
> >> Quoting Thierry Reding (2014-05-14 07:27:40)
> > [...]
> >>> As for shared clocks I'm only aware of one use-case, namely EMC scaling.
> >>> Using clocks for that doesn't seem like the best option to me. While it
> >>> can probably fix the immediate issue of choosing an appropriate
> >>> frequency for the EMC clock it isn't a complete solution for the problem
> >>> that we're trying to solve. From what I understand EMC scaling is one
> >>> part of ensuring quality of service. The current implementations of that
> >>> seems to abuse clocks (essentially one X.emc clock per X clock) to
> >>> signal the amount of memory bandwidth required by any given device. But
> >>> there are other parts to the puzzle. Latency allowance is one. The value
> >>> programmed to the latency allowance registers for example depends on the
> >>> EMC frequency.
> >>>
> >>> Has anyone ever looked into using a different framework to model all of
> >>> these requirements? PM QoS looks like it might fit, but if none of the
> >>> existing frameworks have what we need, perhaps something new can be
> >>> created.
> >>
> >> It has been discussed. Using a QoS throughput constraint could help
> >> scale frequency. But this deserves a wider discussion and starts to
> >> stray into both PM QoS territory and also into "should we have a DVFS
> >> framework" territory.
> > 
> > I've looked into this for a bit and it doesn't look like PM QoS is going
> > to be a good match after all. One of the issues I found was that PM QoS
> > deals with individual devices and there's no builtin way to collect the
> > requests from multiple devices to produce a global constraint. So if we
> > want to add something like that either the API would need to be extended
> > or it would need to be tacked on using the notifier mechanism and some
> > way of tracking (and filtering) the individual devices.
> > 
> > Looking at devfreq it seems to be the DVFS framework that you mentioned,
> > but from what I can tell it suffers from mostly the same problems. The
> > governor applies some frequency scaling policy to a single device and
> > does not allow multiple devices to register constraints against a single
> > (global) constraint so that the result can be accumulated.
> > 
> > For Tegra EMC scaling what we need is something more along the lines of
> > this: we have a resource (external memory) that is shared by multiple
> > devices in the system. Each of those devices requires a certain amount
> > of that resource (memory bandwidth). The resource driver will need to
> > accumulate all requests for the resource and apply the resulting
> > constraint so that all requests can be satisfied.
> > 
> > One solution I could imagine to make this work with PM QoS would be to
> > add the concept of a pm_qos_group to manage a set of pm_qos_requests,
> > but that will require a bunch of extra checks to make sure that requests
> > are of the correct type and so on. In other words it would still be
> > tacked on.
> 
> just a minor note from previous experience: We(at TI) had attempted in
> our product kernel[1] to use QoS constraint for certain SoCs for
> rather unspectacular results.
> 
> Our use case was similar: devices -> L3(core bus)->memory. We had the
> following intent:
> a) wanted to scale L3 based on QoS requests coming in from various
> device drivers. intent was to scale either to 133MHz or 266MHz (two
> OPPs we supported on our devices) based on performance needs -> So we
> asked drivers to report QoS requirements using an standard function -
> except drivers cannot always report it satisfactorily - example bursty
> transfer devices - ended up with consolidated requests > total
> bandwidth possible on the bus -> (and never in practise hitting the
> lower frequency).

My opinion on why L3 QoS failed on OMAP is that we only used it for
DVFS. The voltage domain corresponding to the L3 interconnect had only
two OPPs, which meant that drivers submitting their constraints only had
two options: slow vs fast in the best case, or non-functional vs
functional in the worst case (some IPs simply did not work at the lower
OPP).

But the big failure in my opinion was that we did not use any of the
traffic-shaping or priority handling features of the L3 NoC. OMAP4 used
the Arteris NoC[1] which has plenty of capabilities for setting
initiator priorities and bandwidth-throttling on a point-to-point basis,
which is exactly that QoS is for. If these had been exposed a bit more
in software then I imagine some of the constraints that always resulted
in running at the fast OPP might have instead resulted in running at the
slow OPP, but with a fine-grained mixture of varying bandwidth
allocations and access priorities.

All of the hardware in the world doesn't do any good if we don't have
software that uses it. Anyways, just my $0.02

[PATCH 6/6] staging: comedi: addi_apci_1564: cleanup v_ADDI_Interrupt()

[Chase Southwood]

Move the function apci1564_interrupt() from hwdrv_apci1564.c to
addi_apci_1564.c.  On moving, for now just strip out all of the
code for interrupts that the driver does not yet support at this
time.

Rename the variable ui_InterruptStatus_1564 to ctrl, and change the return
from IRQ_RETVAL(1) to IRQ_HANDLED.

We also check the device is asserting the shared interrupt line and check
that interrupts have been enabled.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---

Admittedly, I am not sure if what I have done in the interrupt handler is
quite sufficient.  Am I missing anything that should be there due to the
fact that the handler does not yet support all of the types of interrupt
that the board is capable of issuing (i.e. does the interrupt handler need
to clear the other interrupts just in case they get triggered, etc?)

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 130 -
 drivers/staging/comedi/drivers/addi_apci_1564.c|  34 +-
 2 files changed, 30 insertions(+), 134 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 41aa889..ebd763b 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -90,7 +90,6 @@
 #define APCI1564_TCW_WARN_TIMEBASE_REG(x)  (0x1c + ((x) * 0x20))
 
 /* Global variables */
-static unsigned int ui_InterruptStatus_1564;
 static unsigned int ui_InterruptData, ui_Type;
 
 struct apci1564_private {
@@ -367,132 +366,3 @@ static int apci1564_do_read(struct comedi_device *dev,
*data = ui_Type;
return insn->n;
 }
-
-/*
- * Interrupt handler for the interruptible digital inputs
- */
-static void apci1564_interrupt(int irq, void *d)
-{
-   struct comedi_device *dev = d;
-   struct apci1564_private *devpriv = dev->private;
-   unsigned int ui_DO, ui_DI;
-   unsigned int ui_Timer;
-   unsigned int ui_C1, ui_C2, ui_C3, ui_C4;
-   unsigned int ul_Command2 = 0;
-
-   ui_DI = inl(devpriv->amcc_iobase + APCI1564_DI_IRQ_REG) & 0x01;
-   ui_DO = inl(devpriv->amcc_iobase + APCI1564_DO_IRQ_REG) & 0x01;
-   ui_Timer = inl(devpriv->amcc_iobase + APCI1564_TIMER_IRQ_REG) & 0x01;
-   ui_C1 =
-   inl(dev->iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER1)) & 
0x1;
-   ui_C2 =
-   inl(dev->iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER2)) & 
0x1;
-   ui_C3 =
-   inl(dev->iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER3)) & 
0x1;
-   ui_C4 =
-   inl(dev->iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER4)) & 
0x1;
-   if (ui_DI == 0 && ui_DO == 0 && ui_Timer == 0 && ui_C1 == 0
-   && ui_C2 == 0 && ui_C3 == 0 && ui_C4 == 0) {
-   dev_err(dev->class_dev, "Interrupt from unknown source.\n");
-   }
-
-   if (ui_DI == 1) {
-   ui_DI = inl(devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
-   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
-   ui_InterruptStatus_1564 =
-   inl(devpriv->amcc_iobase + APCI1564_DI_INT_STATUS_REG);
-   ui_InterruptStatus_1564 = ui_InterruptStatus_1564 & 0X0000;
-   /* enable the interrupt */
-   outl(ui_DI, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
-   return;
-   }
-
-   if (ui_DO == 1) {
-   /* Check for Digital Output interrupt Type */
-   /* 1: VCC interrupt*/
-   /* 2: CC interrupt */
-   ui_Type = inl(devpriv->amcc_iobase + 
APCI1564_DO_INT_STATUS_REG) & 0x3;
-   /* Disable the  Interrupt */
-   outl(0x0, devpriv->amcc_iobase + APCI1564_DO_INT_CTRL_REG);
-
-   }
-
-   if (ui_Timer == 1) {
-   devpriv->timer_select_mode = ADDIDATA_TIMER;
-   if (devpriv->timer_select_mode) {
-
-   /*  Disable Timer Interrupt */
-   ul_Command2 = inl(devpriv->amcc_iobase + 
APCI1564_TIMER_CTRL_REG);
-   outl(0x0, devpriv->amcc_iobase + 
APCI1564_TIMER_CTRL_REG);
-
-   /*  Enable Timer Interrupt */
-
-   outl(ul_Command2, devpriv->amcc_iobase + 
APCI1564_TIMER_CTRL_REG);
-   }
-   }
-
-   if (ui_C1 == 1) {
-   devpriv->timer_select_mode = ADDIDATA_COUNTER;
-   if (devpriv->timer_select_mode) {
-
-   /*  Disable Counter Interrupt */
-   ul_Command2 =
-   inl(dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
-   outl(0x0,
-dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
-
-   /*  Enable Counter Interrupt */
-   outl(ul_Command2,

Re: Unionmount and overlayfs testsuite

[J. R. Okajima]

"J. R. Okajima":
> - readlink.test,
>   fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E 
> EINVAL}
>   It expects "$testdir/direct_dir_sym100". Does it mean UnionMount
>   converts the target path?
>   For example,
>   - /u = /rw + /ro
>   - /rw/symlinkA doesn't exist
>   - /ro/symlinkA points to /ro/fileA
>   Does readlink(2) return "/u/fileA" instead of "/u/fileA"?

Ouch!
I meant "Does ... instead of /ro/fileA?"


J. R. Okajima
--
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 5/6] staging: comedi: addi_apci_1564: hook-up the interrupt subdevice

[Chase Southwood]

The board supported by this driver can generate an interrupt based
on the state of input channels 0-15.

The apci1564_di_config() function is used to configure which
inputs are used to generate the interrupt. Currently this function
is broken since it does not follow the comedi API for insn_config
functions. Fix this function by implementing the config instruction
INSN_CONFIG_DIGITAL_TRIG.

Add the remaining subdevice operations necessary for the interrupt
subdevice to support async commands.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---

The structure of _much_ of this code was taken from/based on the similar
code found in addi_apci_1032.c.  As such, I would appreciate as much
review I can get to make sure what I've done here actually makes sense
for this driver :)

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  |  37 +---
 drivers/staging/comedi/drivers/addi_apci_1564.c| 228 +++--
 2 files changed, 210 insertions(+), 55 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 054e731..41aa889 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -95,45 +95,14 @@ static unsigned int ui_InterruptData, ui_Type;
 
 struct apci1564_private {
unsigned int amcc_iobase;   /* base of AMCC I/O registers */
+   unsigned int mode1; /* riding-edge/high level channels */
+   unsigned int mode2; /* falling-edge/low level channels */
+   unsigned int ctrl;  /* interrupt mode OR (edge) . AND 
(level) */
unsigned char timer_select_mode;
unsigned char mode_select_register;
 };
 
 /*
- * Configures the digital input Subdevice
- *
- * data[0] 1 = Enable interrupt, 0 = Disable interrupt
- * data[1] 0 = ADDIDATA Interrupt OR LOGIC, 1 = ADDIDATA Interrupt AND LOGIC
- * data[2] Interrupt mask for the mode 1
- * data[3] Interrupt mask for the mode 2
- */
-static int apci1564_di_config(struct comedi_device *dev,
- struct comedi_subdevice *s,
- struct comedi_insn *insn,
- unsigned int *data)
-{
-   struct apci1564_private *devpriv = dev->private;
-
-   /* Set the digital input logic */
-   if (data[0] == ADDIDATA_ENABLE) {
-   data[2] = data[2] << 4;
-   data[3] = data[3] << 4;
-   outl(data[2], devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
-   outl(data[3], devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
-   if (data[1] == ADDIDATA_OR)
-   outl(0x4, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
-   else
-   outl(0x6, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
-   } else {
-   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
-   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
-   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
-   }
-
-   return insn->n;
-}
-
-/*
  * Configures The Digital Output Subdevice.
  *
  * data[1] 0 = Disable VCC Interrupt, 1 = Enable VCC Interrupt
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 183fdc3..cf58f90 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -8,6 +8,42 @@
 
 #include "addi-data/hwdrv_apci1564.c"
 
+#define APCI1564_CTRL_INT_OR   (0 << 1)
+#define APCI1564_CTRL_INT_AND  (1 << 1)
+#define APCI1564_CTRL_INT_ENA  (1 << 2)
+
+static int apci1564_reset(struct comedi_device *dev)
+{
+   struct apci1564_private *devpriv = dev->private;
+
+   ui_Type = 0;
+
+   /* Disable the input interrupts and reset status register */
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
+   inl(devpriv->amcc_iobase + APCI1564_DI_INT_STATUS_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
+
+   /* Reset the output channels and disable interrupts */
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DO_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DO_INT_CTRL_REG);
+
+   /* Reset the watchdog registers */
+   addi_watchdog_reset(devpriv->amcc_iobase + APCI1564_WDOG_REG);
+
+   /* Reset the timer registers */
+   outl(0x0, devpriv->amcc_iobase + APCI1564_TIMER_CTRL_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_TIMER_RELOAD_REG);
+
+   /* Reset the counter registers */
+   outl(0x0, dev->iobase + APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
+   outl(0x0, dev->iobase + APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
+   outl(0x0, dev->iobase + APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
+   

[PATCH 3/6] staging: comedi: addi_apci_1564: introduce apci1564_private struct

[Chase Southwood]

The addi_private struct defined in addi-data/addi_common.h is very bloated
and contains many fields which addi_apci_1564 does not require.  In the
interest of eventually removing this driver's dependency on
addi_common.h, we can create a private data struct specifically for
addi_apci_1564 containing only the fields it will actually use.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 164 +++--
 drivers/staging/comedi/drivers/addi_apci_1564.c|  34 ++---
 2 files changed, 102 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index f974bd2..054e731 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -49,7 +49,7 @@
 #define APCI1564_COUNTER4  3
 
 /*
- * devpriv->i_IobaseAmcc Register Map
+ * devpriv->amcc_iobase Register Map
  */
 #define APCI1564_DI_REG0x04
 #define APCI1564_DI_INT_MODE1_REG  0x08
@@ -93,6 +93,12 @@
 static unsigned int ui_InterruptStatus_1564;
 static unsigned int ui_InterruptData, ui_Type;
 
+struct apci1564_private {
+   unsigned int amcc_iobase;   /* base of AMCC I/O registers */
+   unsigned char timer_select_mode;
+   unsigned char mode_select_register;
+};
+
 /*
  * Configures the digital input Subdevice
  *
@@ -106,22 +112,22 @@ static int apci1564_di_config(struct comedi_device *dev,
  struct comedi_insn *insn,
  unsigned int *data)
 {
-   struct addi_private *devpriv = dev->private;
+   struct apci1564_private *devpriv = dev->private;
 
/* Set the digital input logic */
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2] << 4;
data[3] = data[3] << 4;
-   outl(data[2], devpriv->i_IobaseAmcc + 
APCI1564_DI_INT_MODE1_REG);
-   outl(data[3], devpriv->i_IobaseAmcc + 
APCI1564_DI_INT_MODE2_REG);
+   outl(data[2], devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+   outl(data[3], devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
if (data[1] == ADDIDATA_OR)
-   outl(0x4, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+   outl(0x4, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
else
-   outl(0x6, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+   outl(0x6, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
} else {
-   outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_INT_MODE1_REG);
-   outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_INT_MODE2_REG);
-   outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
}
 
return insn->n;
@@ -138,7 +144,7 @@ static int apci1564_do_config(struct comedi_device *dev,
  struct comedi_insn *insn,
  unsigned int *data)
 {
-   struct addi_private *devpriv = dev->private;
+   struct apci1564_private *devpriv = dev->private;
unsigned int ul_Command = 0;
 
if ((data[0] != 0) && (data[0] != 1)) {
@@ -157,8 +163,8 @@ static int apci1564_do_config(struct comedi_device *dev,
else
ul_Command = ul_Command & 0xFFFD;
 
-   outl(ul_Command, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
-   ui_InterruptData = inl(devpriv->i_IobaseAmcc + 
APCI1564_DO_INT_CTRL_REG);
+   outl(ul_Command, devpriv->amcc_iobase + APCI1564_DO_INT_CTRL_REG);
+   ui_InterruptData = inl(devpriv->amcc_iobase + APCI1564_DO_INT_CTRL_REG);
return insn->n;
 }
 
@@ -178,30 +184,30 @@ static int apci1564_timer_config(struct comedi_device 
*dev,
 struct comedi_insn *insn,
 unsigned int *data)
 {
-   struct addi_private *devpriv = dev->private;
+   struct apci1564_private *devpriv = dev->private;
unsigned int ul_Command1 = 0;
 
if (data[0] == ADDIDATA_WATCHDOG) {
-   devpriv->b_TimerSelectMode = ADDIDATA_WATCHDOG;
+   devpriv->timer_select_mode = ADDIDATA_WATCHDOG;
 
/* Disable the watchdog */
-   outl(0x0, devpriv->i_IobaseAmcc + APCI1564_WDOG_CTRL_REG);
+   outl(0x0, devpriv->amcc_iobase + APCI1564_WDOG_CTRL_REG);
/* Loading the Reload value */
-   outl(data[3], devpriv->i_IobaseAmcc + APCI1564_WDOG_RELOAD_REG);
+   outl(data[3], devpriv->amcc_iobas

[PATCH 4/6] staging: comedi: addi_apci_1564: add a subdevice for Change-of-State interrupt support

[Chase Southwood]

This board supports an interrupt that can be generated by an AND/OR
combination of 16 of the input channels.

Create a separate subdevice to handle this interrupt.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 drivers/staging/comedi/drivers/addi_apci_1564.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 5901143..183fdc3 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -105,7 +105,7 @@ static int apci1564_auto_attach(struct comedi_device *dev,
dev->irq = pcidev->irq;
}
 
-   ret = comedi_alloc_subdevices(dev, 3);
+   ret = comedi_alloc_subdevices(dev, 4);
if (ret)
return ret;
 
@@ -144,6 +144,20 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->insn_read = apci1564_timer_read;
s->insn_config = apci1564_timer_config;
 
+   /* Change-Of-State (COS) interrupt subdevice */
+   s = &dev->subdevices[3];
+   if (dev->irq) {
+   dev->read_subdev = s;
+   s->type = COMEDI_SUBD_DI;
+   s->subdev_flags = SDF_READABLE | SDF_CMD_READ;
+   s->n_chan = 1;
+   s->maxdata = 1;
+   s->range_table = &range_digital;
+   s->len_chanlist = 1;
+   } else {
+   s->type = COMEDI_SUBD_UNUSED;
+   }
+
return 0;
 }
 
-- 
1.9.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 1/6] staging: comedi: addi_apci_1564: remove send_sig() use

[Chase Southwood]

The addi-data drivers use send_sig() to let the user know when an
interrupt has occurred. The "standard" way to do this in the comedi
subsystem is to have a subdevice that supports asynchronous commands
and use comedi_event() to signal the user.

Remove the send_sig() usage in this driver.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 23 --
 1 file changed, 23 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 0ba5385..be0e009 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -108,8 +108,6 @@ static int apci1564_di_config(struct comedi_device *dev,
 {
struct addi_private *devpriv = dev->private;
 
-   devpriv->tsk_Current = current;
-
/* Set the digital input logic */
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2] << 4;
@@ -166,7 +164,6 @@ static int apci1564_do_config(struct comedi_device *dev,
 
outl(ul_Command, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
ui_InterruptData = inl(devpriv->i_IobaseAmcc + 
APCI1564_DO_INT_CTRL_REG);
-   devpriv->tsk_Current = current;
return insn->n;
 }
 
@@ -189,7 +186,6 @@ static int apci1564_timer_config(struct comedi_device *dev,
struct addi_private *devpriv = dev->private;
unsigned int ul_Command1 = 0;
 
-   devpriv->tsk_Current = current;
if (data[0] == ADDIDATA_WATCHDOG) {
devpriv->b_TimerSelectMode = ADDIDATA_WATCHDOG;
 
@@ -436,8 +432,6 @@ static void apci1564_interrupt(int irq, void *d)
ui_InterruptStatus_1564 =
inl(devpriv->i_IobaseAmcc + APCI1564_DI_INT_STATUS_REG);
ui_InterruptStatus_1564 = ui_InterruptStatus_1564 & 0X0000;
-   /* send signal to the sample */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
/* enable the interrupt */
outl(ui_DI, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
return;
@@ -451,8 +445,6 @@ static void apci1564_interrupt(int irq, void *d)
/* Disable the  Interrupt */
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
 
-   /* Sends signal to user space */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
}
 
if (ui_Timer == 1) {
@@ -463,9 +455,6 @@ static void apci1564_interrupt(int irq, void *d)
ul_Command2 = inl(devpriv->i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
outl(0x0, devpriv->i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/*  Enable Timer Interrupt */
 
outl(ul_Command2, devpriv->i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
@@ -482,9 +471,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/*  Enable Counter Interrupt */
outl(ul_Command2,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
@@ -501,9 +487,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/*  Enable Counter Interrupt */
outl(ul_Command2,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
@@ -520,9 +503,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/*  Enable Counter Interrupt */
outl(ul_Command2,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
@@ -539,9 +519,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev->iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER4));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv->tsk_Current, 0);
-
   

[PATCH 2/6] staging: comedi: addi_apci_1564: remove use of devpriv->b_OutputMemoryStatus

[Chase Southwood]

This member of the private data struct is only set at one location in the
entire driver, and then never even used for anything.  Let's just remove
its use.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeeten 
---
 drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index be0e009..f974bd2 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -147,11 +147,6 @@ static int apci1564_do_config(struct comedi_device *dev,
return -EINVAL;
}
 
-   if (data[0])
-   devpriv->b_OutputMemoryStatus = ADDIDATA_ENABLE;
-   else
-   devpriv->b_OutputMemoryStatus = ADDIDATA_DISABLE;
-
if (data[1] == ADDIDATA_ENABLE)
ul_Command = ul_Command | 0x1;
else
-- 
1.9.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 0/6] staging: comedi: addi_apci_1564: fix Change-of-State interrupt functionality.

[Chase Southwood]

This patchset introduces a new private data struct for this driver, adds
all of the code required to support Change-of-State interrupts for the
digital input subsystem, and finally focuses and fixes
apci1564_interrupt() to service this type of interrupt correctly.

Chase Southwood (6):
  staging: comedi: addi_apci_1564: remove send_sig() use
  staging: comedi: addi_apci_1564: remove use of
devpriv->b_OutputMemoryStatus
  staging: comedi: addi_apci_1564: introduce apci1564_private struct
  staging: comedi: addi_apci_1564: add a subdevice for Change-of-State
interrupt support
  staging: comedi: addi_apci_1564: hook-up the interrupt subdevice
  staging: comedi: addi_apci_1564: cleanup v_ADDI_Interrupt()

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 295 -
 drivers/staging/comedi/drivers/addi_apci_1564.c| 294 +---
 2 files changed, 316 insertions(+), 273 deletions(-)

-- 
1.9.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: [RFC 2/2] x86_64: expand kernel stack to 16K

[Linus Torvalds]

On Thu, May 29, 2014 at 7:12 PM, Minchan Kim  wrote:
>
> Interim report,
>
> And result is as follows, It reduce about 800-byte compared to
> my first report but still stack usage seems to be high.
> Really needs diet of VM functions.

Yes. And in this case uninlining things might actually help, because
the it's not actually performing reclaim in the second case, so
inlining the reclaim code into that huge __alloc_pages_nodemask()
function means that it has the stack frame for all those cases even if
they don't actually get used.

That said, the way those functions are set up (with lots of arguments
passed from one to the other), not inlining will cause huge costs too
for the argument setup.

It really might be very good to create a "struct alloc_info" that
contains those shared arguments, and just pass a (const) pointer to
that around. Gcc would likely tend to be *much* better at generating
code for that, because it avoids a tons of temporaries being created
by function calls. Even when it's inlined, the argument itself ends up
being a new temporary internally, and I suspect one reason gcc
(especially your 4.6.3 version, apparently) generates those big spill
frames is because there's tons of these duplicate temporaries that
apparently don't get merged properly.

Ugh. I think I'll try looking at that tomorrow.

Linus
--
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: Unionmount and overlayfs testsuite

[Sedat Dilek]

On Fri, May 30, 2014 at 6:15 AM, Sedat Dilek  wrote:
> On Thu, May 29, 2014 at 10:59 PM, David Howells  wrote:
>> Sedat Dilek  wrote:
>>
>>> "Fixable" in your testsuite?
>>
>> Done and pushed.
>>
>
> Thanks.
>
> I still see lots of...
>
> umount: /mnt: not mounted
>
> ...and impermissible.test fails here...
>
[...]
> TEST104: Impermissible utimes
>  - fs_op_as_bin utimes /mnt/a/rootfile104 -E EACCES
> /mnt/a/rootfile104: Test file not on upper filesystem (line 130)
>

rootfile104 is really not on /upper/ ...

# find /mnt/ /upper/ /lower/ -name rootfile104
/mnt/a/rootfile104
/lower/a/rootfile104

- Sedat -
--
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/3] staging: comedi: addi_apci_1564: prepare for adding Change-of-State interrupt support

[Chase Southwood]

Hi Greg,

On Sat, May 24, 2014 at 5:23 PM, Chase Southwood
 wrote:
> This patchset adds the required subdevice for supporting DI COS interrupts,
> as well as introducing a driver-specific private data struct that will
> make the COS interrupt operations much more straightforward and clean.
>
> Chase Southwood (3):
>   staging: comedi: addi_apci_1564: add a subdevice for Change-of-State
> interrupt support
>   staging: comedi: addi_apci_1564: remove send_sig() use
>   staging: comedi: addi_apci_1564: introduce apci1564_private struct
>
>  .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 200 
> ++---
>  drivers/staging/comedi/drivers/addi_apci_1564.c|  54 +++---
>  2 files changed, 126 insertions(+), 128 deletions(-)

Please ignore this patchset completely, I am sending one out
momentarily that serves as its replacement.

Thanks,
Chase
--
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: Unionmount and overlayfs testsuite

[Sedat Dilek]

On Thu, May 29, 2014 at 10:59 PM, David Howells  wrote:
> Sedat Dilek  wrote:
>
>> "Fixable" in your testsuite?
>
> Done and pushed.
>

Thanks.

I still see lots of...

umount: /mnt: not mounted

...and impermissible.test fails here...

***
*** ./run.sh impermissible.test
***
umount: /mnt: not mounted
TEST100: Impermissible open O_TRUNC|O_WRONLY
 - open_file_as_bin -t -w /mnt/a/rootfile100 -E EACCES
 - open_file_as_bin -w /mnt/a/rootfile100 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile100 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile100 -R :xxx:yyy:zzz
 - open_file -w /mnt/a/rootfile100 -W shark
 - open_file -r /mnt/a/rootfile100 -R sharkyyy:zzz
 - open_file_as_bin -r /mnt/a/rootfile100 -R sharkyyy:zzz
TEST101: Impermissible open O_WRONLY
 - open_file_as_bin -w /mnt/a/rootfile101 -E EACCES
 - open_file_as_bin -w /mnt/a/rootfile101 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile101 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile101 -R :xxx:yyy:zzz
 - open_file -w /mnt/a/rootfile101 -W shark
 - open_file -r /mnt/a/rootfile101 -R sharkyyy:zzz
 - open_file_as_bin -r /mnt/a/rootfile101 -R sharkyyy:zzz
TEST102: Impermissible open O_APPEND
 - open_file_as_bin -a /mnt/a/rootfile102 -E EACCES
 - open_file_as_bin -a /mnt/a/rootfile102 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile102 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile102 -R :xxx:yyy:zzz
 - open_file -a /mnt/a/rootfile102 -W shark
 - open_file -r /mnt/a/rootfile102 -R :xxx:yyy:zzzshark
 - open_file_as_bin -r /mnt/a/rootfile102 -R :xxx:yyy:zzzshark
TEST103: Impermissible truncate
 - fs_op_as_bin truncate /mnt/a/rootfile103 4 -E EACCES
 - fs_op_as_bin truncate /mnt/a/rootfile103 4 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile103 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile103 -R :xxx:yyy:zzz
 - fs_op truncate /mnt/a/rootfile103 4
 - open_file -r /mnt/a/rootfile103 -R :xxx
 - open_file_as_bin -r /mnt/a/rootfile103 -R :xxx
TEST104: Impermissible utimes
 - fs_op_as_bin utimes /mnt/a/rootfile104 -E EACCES
/mnt/a/rootfile104: Test file not on upper filesystem (line 130)

Full log of run.sh is attached.

- Sedat -
***
*** ./run.sh open-plain.test
***
TEST100: Open O_RDONLY
 - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
TEST101: Open O_WRONLY
 - open_file -w /mnt/a/foo101 -W q
 - open_file -r /mnt/a/foo101 -R qxxx:yyy:zzz
 - open_file -w /mnt/a/foo101 -W p
 - open_file -r /mnt/a/foo101 -R pxxx:yyy:zzz
TEST102: Open O_APPEND|O_WRONLY
 - open_file -a /mnt/a/foo102 -W q
 - open_file -r /mnt/a/foo102 -R :xxx:yyy:zzzq
 - open_file -a /mnt/a/foo102 -W p
 - open_file -r /mnt/a/foo102 -R :xxx:yyy:zzzqp
TEST103: Open O_RDWR
 - open_file -r -w /mnt/a/foo103 -W q
 - open_file -r /mnt/a/foo103 -R qxxx:yyy:zzz
 - open_file -r -w /mnt/a/foo103 -W p
 - open_file -r /mnt/a/foo103 -R pxxx:yyy:zzz
TEST104: Open O_APPEND|O_RDWR
 - open_file -r -a /mnt/a/foo104 -W q
 - open_file -r /mnt/a/foo104 -R :xxx:yyy:zzzq
 - open_file -r -a /mnt/a/foo104 -W p
 - open_file -r /mnt/a/foo104 -R :xxx:yyy:zzzqp
***
*** ./run.sh open-trunc.test
***
umount: /mnt: not mounted
TEST100: Open O_TRUNC|O_RDONLY
 - open_file -t -r /mnt/a/foo100 -R 
 - open_file -t -r /mnt/a/foo100 -R 
TEST101: Open O_TRUNC|O_WRONLY
 - open_file -t -w /mnt/a/foo101 -W q
 - open_file -r /mnt/a/foo101 -R q
 - open_file -t -w /mnt/a/foo101 -W p
 - open_file -r /mnt/a/foo101 -R p
TEST102: Open O_TRUNC|O_APPEND|O_WRONLY
 - open_file -t -a /mnt/a/foo102 -W q
 - open_file -r /mnt/a/foo102 -R q
 - open_file -t -a /mnt/a/foo102 -W p
 - open_file -r /mnt/a/foo102 -R p
TEST103: Open O_TRUNC|O_RDWR
 - open_file -t -r -w /mnt/a/foo103 -W q
 - open_file -r /mnt/a/foo103 -R q
 - open_file -t -r -w /mnt/a/foo103 -W p
 - open_file -r /mnt/a/foo103 -R p
TEST104: Open O_TRUNC|O_APPEND|O_RDWR
 - open_file -t -r -a /mnt/a/foo104 -W q
 - open_file -r /mnt/a/foo104 -R q
 - open_file -t -r -a /mnt/a/foo104 -W p
 - open_file -r /mnt/a/foo104 -R p
***
*** ./run.sh open-creat.test
***
umount: /mnt: not mounted
TEST100: Open O_CREAT|O_RDONLY
 - open_file -c -r /mnt/a/foo100 -R :xxx:yyy:zzz
 - open_file -c -r /mnt/a/foo100 -R :xxx:yyy:zzz
TEST101: Open O_CREAT|O_WRONLY
 - open_file -c -w /mnt/a/foo101 -W q
 - open_file -c -r /mnt/a/foo101 -R qxxx:yyy:zzz
 - open_file -c -w /mnt/a/foo101 -W p
 - open_file -c -r /mnt/a/foo101 -R pxxx:yyy:zzz
TEST102: Open O_CREAT|O_APPEND|O_WRONLY
 - open_file -c -a /mnt/a/foo102 -W q
 - open_file -c -r /mnt/a/foo102 -R :xxx:yyy:zzzq
 - open_file -c -a /mnt/a/foo102 -W p
 - open_file -c -r /mnt/a/foo102 -R :xxx:yyy:zzzqp
TEST103: Open O_CREAT|O_RDWR
 - open_file -c -r -w /mnt/a/foo103 -W q
 - open_file -c -r /mnt/a/foo103 -R qxxx:yyy:zzz
 - open_file -c -r -w /mnt/a/foo103 -W p
 - open_file -c -r /mnt/a/foo103 -R pxxx:yyy:zzz
TEST104: Open O_CREAT|O_APPEND|O_RDWR
 - open_file -c -r -a /mnt/a/foo104 -W q
 - open_file -c -r /mnt/a/foo104 -R :xxx:yyy:zzzq
 - open_file -c -r -a /mnt/a/foo104 -W p
 - open_file -c -r /mnt/a/foo104 -R :xxx:yyy:zzzqp
***
*** ./run.sh ope

[PATCH 1/2] hugetlb: restrict hugepage_migration_support() to x86_64

[Naoya Horiguchi]

Curretly hugepage migration is available for all archs which support pmd-level
hugepage, but testing is done only for x86_64 and there're bugs for other archs.
So to avoid breaking such archs, this patch limits the availability strictly to
x86_64 until developers of other archs get interested in enabling this feature.

Simply disabling hugepage migration on non-x86_64 archs is not enough to fix
the reported problem where sys_move_pages() hits the BUG_ON() in
follow_page(FOLL_GET), so let's fix this by checking if hugepage migration is
supported in vma_migratable().

ChangeLog:
- add VM_HUGETLB check in vma_migratable()
- fix dependency in config ARCH_ENABLE_HUGEPAGE_MIGRATION
- remove comment on hugepage_migration_support()

Reported-by: Michael Ellerman 
Tested-by: Michael Ellerman 
Signed-off-by: Naoya Horiguchi 
Cc: sta...@vger.kernel.org # 3.12+
---
 arch/arm/mm/hugetlbpage.c |  5 -
 arch/arm64/mm/hugetlbpage.c   |  5 -
 arch/ia64/mm/hugetlbpage.c|  5 -
 arch/metag/mm/hugetlbpage.c   |  5 -
 arch/mips/mm/hugetlbpage.c|  5 -
 arch/powerpc/mm/hugetlbpage.c | 10 --
 arch/s390/mm/hugetlbpage.c|  5 -
 arch/sh/mm/hugetlbpage.c  |  5 -
 arch/sparc/mm/hugetlbpage.c   |  5 -
 arch/tile/mm/hugetlbpage.c|  5 -
 arch/x86/Kconfig  |  4 
 arch/x86/mm/hugetlbpage.c | 10 --
 include/linux/hugetlb.h   | 13 +
 include/linux/mempolicy.h |  6 ++
 mm/Kconfig|  3 +++
 15 files changed, 18 insertions(+), 73 deletions(-)

diff --git v3.15-rc5.orig/arch/arm/mm/hugetlbpage.c 
v3.15-rc5/arch/arm/mm/hugetlbpage.c
index 54ee6163c181..66781bf34077 100644
--- v3.15-rc5.orig/arch/arm/mm/hugetlbpage.c
+++ v3.15-rc5/arch/arm/mm/hugetlbpage.c
@@ -56,8 +56,3 @@ int pmd_huge(pmd_t pmd)
 {
return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
 }
-
-int pmd_huge_support(void)
-{
-   return 1;
-}
diff --git v3.15-rc5.orig/arch/arm64/mm/hugetlbpage.c 
v3.15-rc5/arch/arm64/mm/hugetlbpage.c
index 5e9aec358306..2fc8258bab2d 100644
--- v3.15-rc5.orig/arch/arm64/mm/hugetlbpage.c
+++ v3.15-rc5/arch/arm64/mm/hugetlbpage.c
@@ -54,11 +54,6 @@ int pud_huge(pud_t pud)
return !(pud_val(pud) & PUD_TABLE_BIT);
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 static __init int setup_hugepagesz(char *opt)
 {
unsigned long ps = memparse(opt, &opt);
diff --git v3.15-rc5.orig/arch/ia64/mm/hugetlbpage.c 
v3.15-rc5/arch/ia64/mm/hugetlbpage.c
index 68232db98baa..76069c18ee42 100644
--- v3.15-rc5.orig/arch/ia64/mm/hugetlbpage.c
+++ v3.15-rc5/arch/ia64/mm/hugetlbpage.c
@@ -114,11 +114,6 @@ int pud_huge(pud_t pud)
return 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 0;
-}
-
 struct page *
 follow_huge_pmd(struct mm_struct *mm, unsigned long address, pmd_t *pmd, int 
write)
 {
diff --git v3.15-rc5.orig/arch/metag/mm/hugetlbpage.c 
v3.15-rc5/arch/metag/mm/hugetlbpage.c
index 042431509b56..3c52fa6d0f8e 100644
--- v3.15-rc5.orig/arch/metag/mm/hugetlbpage.c
+++ v3.15-rc5/arch/metag/mm/hugetlbpage.c
@@ -110,11 +110,6 @@ int pud_huge(pud_t pud)
return 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
 pmd_t *pmd, int write)
 {
diff --git v3.15-rc5.orig/arch/mips/mm/hugetlbpage.c 
v3.15-rc5/arch/mips/mm/hugetlbpage.c
index 77e0ae036e7c..4ec8ee10d371 100644
--- v3.15-rc5.orig/arch/mips/mm/hugetlbpage.c
+++ v3.15-rc5/arch/mips/mm/hugetlbpage.c
@@ -84,11 +84,6 @@ int pud_huge(pud_t pud)
return (pud_val(pud) & _PAGE_HUGE) != 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 struct page *
 follow_huge_pmd(struct mm_struct *mm, unsigned long address,
pmd_t *pmd, int write)
diff --git v3.15-rc5.orig/arch/powerpc/mm/hugetlbpage.c 
v3.15-rc5/arch/powerpc/mm/hugetlbpage.c
index eb923654ba80..7e70ae968e5f 100644
--- v3.15-rc5.orig/arch/powerpc/mm/hugetlbpage.c
+++ v3.15-rc5/arch/powerpc/mm/hugetlbpage.c
@@ -86,11 +86,6 @@ int pgd_huge(pgd_t pgd)
 */
return ((pgd_val(pgd) & 0x3) != 0x0);
 }
-
-int pmd_huge_support(void)
-{
-   return 1;
-}
 #else
 int pmd_huge(pmd_t pmd)
 {
@@ -106,11 +101,6 @@ int pgd_huge(pgd_t pgd)
 {
return 0;
 }
-
-int pmd_huge_support(void)
-{
-   return 0;
-}
 #endif
 
 pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
diff --git v3.15-rc5.orig/arch/s390/mm/hugetlbpage.c 
v3.15-rc5/arch/s390/mm/hugetlbpage.c
index 0727a55d87d9..0ff66a7e29bb 100644
--- v3.15-rc5.orig/arch/s390/mm/hugetlbpage.c
+++ v3.15-rc5/arch/s390/mm/hugetlbpage.c
@@ -220,11 +220,6 @@ int pud_huge(pud_t pud)
return 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
 pmd_t *pmdp, int write)
 {
diff --git v3.15-rc5.orig/arch/sh/mm/hugetlbpage.c 
v3.15-rc5/arch/sh/mm/hugetlbpage.c

[PATCH 2/2] hugetlb: rename hugepage_migration_support() to ..._supported()

[Naoya Horiguchi]

We already have a function named hugepage_supported(), and the similar
name hugepage_migration_support() is a bit unconfortable, so let's rename
it hugepage_migration_supported().

Signed-off-by: Naoya Horiguchi 
---
 include/linux/hugetlb.h | 4 ++--
 mm/hugetlb.c| 2 +-
 mm/migrate.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git v3.15-rc5.orig/include/linux/hugetlb.h 
v3.15-rc5/include/linux/hugetlb.h
index c9de64cf288d..9d35e514312b 100644
--- v3.15-rc5.orig/include/linux/hugetlb.h
+++ v3.15-rc5/include/linux/hugetlb.h
@@ -385,7 +385,7 @@ static inline pgoff_t basepage_index(struct page *page)
 
 extern void dissolve_free_huge_pages(unsigned long start_pfn,
 unsigned long end_pfn);
-static inline int hugepage_migration_support(struct hstate *h)
+static inline int hugepage_migration_supported(struct hstate *h)
 {
 #ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
return huge_page_shift(h) == PMD_SHIFT;
@@ -441,7 +441,7 @@ static inline pgoff_t basepage_index(struct page *page)
return page->index;
 }
 #define dissolve_free_huge_pages(s, e) do {} while (0)
-#define hugepage_migration_support(h)  0
+#define hugepage_migration_supported(h)0
 
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
   struct mm_struct *mm, pte_t *pte)
diff --git v3.15-rc5.orig/mm/hugetlb.c v3.15-rc5/mm/hugetlb.c
index ea42b584661a..83d936d12c1d 100644
--- v3.15-rc5.orig/mm/hugetlb.c
+++ v3.15-rc5/mm/hugetlb.c
@@ -545,7 +545,7 @@ static struct page *dequeue_huge_page_node(struct hstate 
*h, int nid)
 /* Movability of hugepages depends on migration support. */
 static inline gfp_t htlb_alloc_mask(struct hstate *h)
 {
-   if (hugepages_treat_as_movable || hugepage_migration_support(h))
+   if (hugepages_treat_as_movable || hugepage_migration_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;
diff --git v3.15-rc5.orig/mm/migrate.c v3.15-rc5/mm/migrate.c
index bed48809e5d0..15b589ae6aaf 100644
--- v3.15-rc5.orig/mm/migrate.c
+++ v3.15-rc5/mm/migrate.c
@@ -1031,7 +1031,7 @@ static int unmap_and_move_huge_page(new_page_t 
get_new_page,
 * tables or check whether the hugepage is pmd-based or not before
 * kicking migration.
 */
-   if (!hugepage_migration_support(page_hstate(hpage))) {
+   if (!hugepage_migration_supported(page_hstate(hpage))) {
putback_active_hugepage(hpage);
return -ENOSYS;
}
-- 
1.9.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 v3 3/5] char: ti-usim: Add driver for USIM module on AM43xx

[Satish Patel]

On 5/29/2014 9:23 PM, Greg Kroah-Hartman wrote:

On Thu, May 29, 2014 at 03:35:37PM +0530, Satish Patel wrote:

+enum usim_card_mode {
+   USIM_CARD_MODE_ASYNC = 0,   /* asynchronous mode */
+   USIM_CARD_MODE_SYNC_TYPE1,  /* synchronous mode: Type 1 */
+   USIM_CARD_MODE_SYNC_TYPE2,  /* synchronous mode: Type 2 */
+   USIM_CARD_MODE_SYNC_OTHER,  /* Any other synchronous type */
+};
+struct usim_data {
+   int slot;
+   int rxexplen;
+   int txlen;
+   unsigned char apdu[256];
+};


You need to use the proper variable types for a structure that is going
to cross the user/kernel boundry in an ioctl :(
Do you mean to use __u32 instead int ? make use of types defined in 
types.h ? if yes, I will make that change :). Thanks for pointing out.



--
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/5] sc_phy:SmartCard(SC) PHY interface to SC controller

[Satish Patel]

On 5/29/2014 7:17 PM, Rob Herring wrote:

On Thu, May 29, 2014 at 3:34 AM, Satish Patel  wrote:



On 5/29/2014 12:23 AM, Greg KH wrote:


On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:


SmartCard controller uses this interface to communicate with
SmartCard via PHY

Some SmartCard PHY has multiple slots for cards.
This inerface also enables controller to communicate
with one or more SmartCard connected over phy.

interface structure includes following APIs
- set/get config
- activate/deactivate smart card
- warm reset
- register_notify (for card insert/remove/overheat)
- unregister_notify

Signed-off-by: Satish Patel 
---
   Documentation/sc_phy.txt |  171
++
   include/linux/sc_phy.h   |  136 
   2 files changed, 307 insertions(+)
   create mode 100644 Documentation/sc_phy.txt
   create mode 100644 include/linux/sc_phy.h



These are .h files, but where is the "api" functions that use
these structures defined at?


This is like template/wrappers, smart card phy driver will write API
functions. And smartcard controller will call these functions.
With proposed approach, smartcard controller can communicate with any smart
card phy (TI/NxP) without change in code. Using DT entry smartcard and PHY
will gets connected with each other.
Refer diagram given @Documentation/sc_phy.txt.



confused,


I believe the api Greg is wondering about is the notifier which as I
commented is not a good design.

There is now a phy subsystem. I don't know if it has what you need,
but you should look at it to determine if it will work or could be
extended to work.

I have given my comments on notifier, it is required to notify real time 
events like card insert/remove to the smart card controller. As this 
interrupts tied to phy (in case phy is present) not with controller.


Existing phy subsystem does not support generic operations for the phy. 
If at all it adds supports for these, in future I am ok to get align 
with it.



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 v11 0/3] Exynos 5410 support

[Tushar Behera]

On Thu, May 29, 2014 at 11:30 PM, Andreas Färber  wrote:
> Hi Tarek,
>
>
> And I reproducibly get failures for CPUs 1-3, resulting in only one CPU
> in /proc/cpuinfo (compared to 4 on downstream 3.14):
>
> [0.045778] CPU: Testing write buffer coherency: ok
> [0.045968] /cpus/cpu@0 missing clock-frequency property
> [0.045993] /cpus/cpu@1 missing clock-frequency property
> [0.046016] /cpus/cpu@2 missing clock-frequency property
> [0.046040] /cpus/cpu@3 missing clock-frequency property
> [0.046059] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [0.046135] Setting up static identity map for 0x403a8920 - 0x403a8978
> [2.075052] CPU1: failed to come online
> [4.085095] CPU2: failed to come online
> [6.095142] CPU3: failed to come online
> [6.095237] Brought up 1 CPUs
> [6.095269] SMP: Total of 1 processors activated.
> [6.095303] CPU: All CPU(s) started in HYP mode.
> [6.095336] CPU: Virtualization extensions available.
>
> I also notice another apparent device tree issue:
>
> [7.341814] of_get_named_gpiod_flags: can't parse gpios property of
> node '/soc/mmc@1222/slot@0[0]'
> [7.341850] of_get_named_gpiod_flags: can't parse gpios property of
> node '/soc/mmc@1222/slot@0[0]'
>
> Are any of those known issues and being worked on?
> (The CPU failures affected 5420 Arndale Octa as well iirc.)
>

Can you check after applying following two patches for Arndale-Octa
([1],[2])? In other words, a patch similar to [2] might be required
for this board too if it is booting under secure mode.

[1] http://www.spinics.net/lists/linux-samsung-soc/msg31776.html

[PATCH v2 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode

[2] http://www.spinics.net/lists/linux-samsung-soc/msg31777.html

[PATCH v2 Resend 2/2] ARM: dts: Add secure firmware support for Arndale-octa


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

linux-next: manual merge of the omap_dss2 tree with the arm-soc tree

[Stephen Rothwell]

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/boot/dts/am437x-gp-evm.dts between commit 99ffa6425f1b ("ARM:
dts: am437x-gp-evm: add support for parallel NAND flash") from the
arm-soc tree and commit 0186bec97131 ("ARM: dts: am437x-gp-evm: add LCD
data") from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc arch/arm/boot/dts/am437x-gp-evm.dts
index c25d15837ce9,3acccdf258e9..
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@@ -151,26 -193,46 +193,67 @@@
>;
};
  
 +  nand_flash_x8: nand_flash_x8 {
 +  pinctrl-single,pins = <
 +  0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
spi2_cs0.gpio/eMMCorNANDsel */
 +  0x0  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad0.gpmc_ad0 */
 +  0x4  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad1.gpmc_ad1 */
 +  0x8  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad2.gpmc_ad2 */
 +  0xc  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad3.gpmc_ad3 */
 +  0x10 (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad4.gpmc_ad4 */
 +  0x14 (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad5.gpmc_ad5 */
 +  0x18 (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad6.gpmc_ad6 */
 +  0x1c (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad7.gpmc_ad7 */
 +  0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
 +  0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/* 
gpmc_wpn.gpmc_wpn */
 +  0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0  */
 +  0x90 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_advn_ale.gpmc_advn_ale */
 +  0x94 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_oen_ren.gpmc_oen_ren */
 +  0x98 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_wen.gpmc_wen */
 +  0x9c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_be0n_cle.gpmc_be0n_cle */
 +  >;
 +  };
++
+   dss_pins: dss_pins {
+   pinctrl-single,pins = <
+   0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 8 -> 
DSS DATA 23 */
+   0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+   0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+   0x02c (PIN_OUTPUT_PULLUP | MUX_MODE1)
+   0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+   0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+   0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
+   0x03c (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 15 -> 
DSS DATA 16 */
+   0x0a0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 0 */
+   0x0a4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0a8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0ac (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0b0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0b4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0b8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0bc (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0c0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0c4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0c8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0cc (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0d0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0d4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0d8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
+   0x0dc (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 15 */
+   0x0e0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS VSYNC */
+   0x0e4 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS HSYNC */
+   0x0e8 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS PCLK */
+   0x0ec (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS AC BIAS EN 
*/
+ 
+   >;
+   };
+ 
+   lcd_pins: lcd_pins {
+   pinctrl-single,pins = <
+   /* GPIO 5_8 to select LCD / HDMI */
+   0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
+   >;
+   };
  };
  
  &i2c0 {
@@@ -273,89 -330,16 +356,103 @@@
phy-mode = "rgmii";
  };
  
 +&elm {
 +  status = "okay";
 +};
 +
 +&gpmc {
 +  status = "okay";
 +  pinctrl-names = "default";
 +  pinctrl-0 = <&nand_flash_x8>;
 +  ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
 +  nand@0,0 {
 +  reg = <0 0 4>;  /* device IO registers */
 +  ti,nand-ecc-opt = "bch8";
 +  ti,elm-id = <&elm>;
 +  nand-bus-width = <8>;
 +  gpmc,device-wi

Re: [PATCH] block: virtio_blk: don't hold spin lock during world switch

[Ming Lei]

On Fri, May 30, 2014 at 11:19 AM, Jens Axboe  wrote:
> On 2014-05-29 20:49, Ming Lei wrote:
>>
>> Firstly, it isn't necessary to hold lock of vblk->vq_lock
>> when notifying hypervisor about queued I/O.
>>
>> Secondly, virtqueue_notify() will cause world switch and
>> it may take long time on some hypervisors(such as, qemu-arm),
>> so it isn't good to hold the lock and block other vCPUs.
>>
>> On arm64 quad core VM(qemu-kvm), the patch can increase I/O
>> performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
>> - without the patch: 14K IOPS
>> - with the patch: 34K IOPS
>
>
> Patch looks good to me. I don't see a hit on my qemu-kvm testing, but it
> definitely makes sense and I can see it hurting in other places.

It isn't easy to observe the improvement on x86 VM, especially
with few vCPUs, because qemu-system-x86_64 only takes
several microseconds to handle the notification, but on arm64, it
may take hundreds of microseconds, so the improvement is
obvious on arm VM.

I hope this patch can be merged, at least arm VM can benefit
from it.


Thanks,
--
Ming Lei
--
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: Unionmount and overlayfs testsuite

[J. R. Okajima]

David Howells:
> http://git.infradead.org/users/dhowells/unionmount-testsuite.git

I've found some interesting cases.

- impermissible.test,
open_file_as_bin -t -w $file -E EACCES
  When $termslash is "/", a '/' is appended to the expanded $file, such
  as "/path/fileA/". If fileA is a regular file, that path is obviously
  wrong. Does UnionMount expect EACCES in this case too?
  Should it be ENOTDIR?
  It might be better to change
errcode=EACCES
test ! "$termslash" = "" && errcode=ENOTDIR
open_file_as_bin -t -w $file -E $errcode

- readlink.test,
fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E 
EINVAL}
  It expects "$testdir/direct_dir_sym100". Does it mean UnionMount
  converts the target path?
  For example,
  - /u = /rw + /ro
  - /rw/symlinkA doesn't exist
  - /ro/symlinkA points to /ro/fileA
  Does readlink(2) return "/u/fileA" instead of "/u/fileA"?

And all tests should be done by a superuser?


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

Re: [PATCH] block: virtio_blk: don't hold spin lock during world switch

[Jens Axboe]

On 2014-05-29 21:34, Ming Lei wrote:

On Fri, May 30, 2014 at 11:19 AM, Jens Axboe  wrote:

On 2014-05-29 20:49, Ming Lei wrote:


Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.

Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and block other vCPUs.

On arm64 quad core VM(qemu-kvm), the patch can increase I/O
performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
 - without the patch: 14K IOPS
 - with the patch: 34K IOPS



Patch looks good to me. I don't see a hit on my qemu-kvm testing, but it
definitely makes sense and I can see it hurting in other places.


It isn't easy to observe the improvement on x86 VM, especially
with few vCPUs, because qemu-system-x86_64 only takes
several microseconds to handle the notification, but on arm64, it
may take hundreds of microseconds, so the improvement is
obvious on arm VM.

I hope this patch can be merged, at least arm VM can benefit
from it.


If Rusty agrees, I'd like to add it for 3.16 with a stable marker.

--
Jens Axboe

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

Re: [PATCH 5/7 v6] trace, RAS: Add eMCA trace event interface

[Chen, Gong]

On Thu, May 29, 2014 at 09:12:51AM -0400, Steven Rostedt wrote:
> What do you think gets recorded in the ring buffer? The pointer to the
> string? No! You copy the entire string into the ring buffer, with
> markers and all. How big is that string? 60 chars? 80? I see you
> recording meta data there too:
I'm not the expert of trace. If I am wrong please fix me. So it looks
like all trace data shhould be pushed into the ring buffer as raw
material and when it is needed to be printed via TP_printk, these
raw data will be expanded(unzip them as you told) into another
temp buffer, maybe kernel printk buffer directly.

[...]
> > #define show_dimm_location(type)\
> > __print_symbolic(type,  \
> > { CPER_MEM_VALID_NODE,  "node" },   \
> > { CPER_MEM_VALID_CARD,  "card" },   \
> > { CPER_MEM_VALID_MODULE,"module" }, \
> > ...
> > 
> 
> I'm not sure you could use that, as you save an array of data. The
> print_symbolic() wont work with an array.
Just FWIW, call it again and again. But it looks too awkward I will
use other style.

> 
> You can still use the same code for both the tracepoint (perf and
> ftrace) and for dmesg. You need to write a packed array that is
> returned as well as a way to convert that array into a human readable
> string for later processing. The dmesg version would just have them
> both together where as the tracepoint records the packed version on the
> ring buffer and the TP_printk() will use the extraction.
> 
> That is, dmesg has the compress and extraction in one place where the
> tracepoint has them in two different places.
> 
> Understand?
Yes, I feel the same way. Zip/unzip is unavoidable.


signature.asc
Description: Digital signature

linux-next: build failure after merge of the mmc tree

[Stephen Rothwell]

Hi Chris,

After merging the mmc tree, today's linux-next build (arm multi_v7_defconfig)
failed like this:

drivers/mmc/host/sunxi-mmc.c:25:29: fatal error: linux/clk/sunxi.h: No such 
file or directory

Caused by commit 19b7f796c375 ("mmc: sunxi: Add driver for SD/MMC hosts
found on Allwinner sunxi SoCs").  Something has changed to turn on
CONFIG_ARCH_SUNXI in the arm multi_v7_defconfig build since yesterday.

linux/clk/sunxi.h is created by a commit in the clk tree
(git://git.linaro.org/people/mturquette/linux.git#clk-next) which I
don't include in linux-next until much later than the mmc tree.

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH]x86 efi: do not export efi runtime map in case old map

[Dave Young]

For ioremapped efi memory aka old_map the virt addresses are not persistant
across kexec reboot. kexec-tools will read the runtime maps from sysfs then
pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause
kexec boot failure.

To address this issue do not export runtime maps in case efi old_map so
userspace can use no efi boot instead.

Signed-off-by: Dave Young 
---
 arch/x86/platform/efi/efi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 3781dd3..4d36932 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -919,6 +919,9 @@ static void __init save_runtime_map(void)
void *tmp, *p, *q = NULL;
int count = 0;
 
+   if (efi_enabled(EFI_OLD_MEMMAP))
+   return;
+
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
 
-- 
1.8.3.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 2/5] clk: bcm281xx: implement prerequisite clocks

[Alex Elder]

On 05/23/2014 07:53 PM, Mike Turquette wrote:
> Quoting Alex Elder (2014-05-20 05:52:39)
>> @@ -743,11 +746,16 @@ struct clk *kona_clk_setup(struct kona_clk *bcm_clk)
>> clk = clk_register(NULL, &bcm_clk->hw);
>> if (IS_ERR(clk)) {
>> pr_err("%s: error registering clock %s (%ld)\n", __func__,
>> -   init_data->name, PTR_ERR(clk));
>> +   name, PTR_ERR(clk));
>> goto out_teardown;
>> }
>> BUG_ON(!clk);
>>  
>> +   /*  Make it so we can look the clock up using clk_find() */
> 
> s/clk_find/clk_get/ ?
> 
>> +   bcm_clk->cl.con_id = name;
>> +   bcm_clk->cl.clk = clk;
>> +   clkdev_add(&bcm_clk->cl);
> 
> This is not so nice. I'll explain more below.

OK, despite what I said before, I do need this, or
something like it, so I can look up clocks by name.
(Continued below.)

> 
>> +
>> return clk;
>>  out_teardown:
>> bcm_clk_teardown(bcm_clk);
>> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
>> index d8a7f38..fd070d6 100644
>> --- a/drivers/clk/bcm/clk-kona.c
>> +++ b/drivers/clk/bcm/clk-kona.c
>> @@ -1195,6 +1195,48 @@ static bool __peri_clk_init(struct kona_clk *bcm_clk)
>> return true;
>>  }
>>  
>> +static bool __kona_clk_init(struct kona_clk *bcm_clk);
>> +static bool __kona_prereq_init(struct kona_clk *bcm_clk)
>> +{
>> +   struct clk *clk;
>> +   struct clk_hw *hw;
>> +   struct kona_clk *prereq;
>> +
>> +   BUG_ON(clk_is_initialized(bcm_clk));
>> +
>> +   if (!bcm_clk->p.prereq)
>> +   return true;
>> +
>> +   clk = clk_get(NULL, bcm_clk->p.prereq);
> 
> The clkdev global namespace is getting polluted with all of these new
> prereq clocks. If there was an associated struct device *dev with them
> then it wouldn't be a problem, but you might get collisions with other
> clock drivers that also use NULL for the device.

Yes I recognize this.  Ideally a CCU would have a device struct
associated with it that I could use, because the name of a clock
is unique within that context.  But I have no such device available.
(Please correct me if I'm wrong.  I don't want to make one up, and
I would like to use it if it exists.)

> It would be a lot nicer for the clocks that require a prereq clock to
> just use clk_get(dev, "well_known_name"); in the same way that drivers
> use it, without considering it a special case.

I can do something like that if I can get a meaningful device
structure.  Do you have any suggestions?

Other than this issue, I've implemented all of the previous
initialization routines using ->prepare() instead, and it
works fine.  I'm going to send an updated series out tomorrow.
I want to look it over again after a good night's sleep...

-Alex

>> +   if (IS_ERR(clk)) {
>> +   pr_err("%s: unable to get prereq clock %s for %s\n",
>> +   __func__, bcm_clk->p.prereq, 
>> bcm_clk->init_data.name);
>> +   return false;
>> +   }
>> +   hw = __clk_get_hw(clk);
>> +   if (!hw) {
>> +   pr_err("%s: null hw pointer for clock %s\n", __func__,
>> +   bcm_clk->init_data.name);
>> +   return false;
>> +   }
>> +   prereq = to_kona_clk(hw);
>> +   if (prereq->ccu != bcm_clk->ccu) {
>> +   pr_err("%s: prereq clock %s CCU different for clock %s\n",
>> +   __func__, bcm_clk->p.prereq, 
>> bcm_clk->init_data.name);
>> +   return false;
>> +   }
>> +
>> +   /* Initialize the prerequisite clock first */
>> +   if (!__kona_clk_init(prereq)) {
>> +   pr_err("%s: failed to init prereq %s for clock %s\n",
>> +   __func__, bcm_clk->p.prereq, 
>> bcm_clk->init_data.name);
>> +   return false;
>> +   }
>> +   bcm_clk->p.prereq_clk = clk;
> 
> The above seems like a lot effort to go to. Why not skip all of this and
> just implement the prerequisite logic in the .enable & .disable
> callbacks? E.g. your kona clk .enable callback would look like:
> 
> diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
> index d603c4e..51f35b4 100644
> --- a/drivers/clk/bcm/clk-kona.c
> +++ b/drivers/clk/bcm/clk-kona.c
> @@ -987,6 +987,12 @@ static int kona_peri_clk_enable(struct clk_hw *hw)
>  {
>   struct kona_clk *bcm_clk = to_kona_clk(hw);
>   struct bcm_clk_gate *gate = &bcm_clk->u.peri->gate;
> + int ret;
> +
> + hw->prereq_bus_clk = clk_get(hw->ccu, hw->prereq);
> + ret = clk_enable(prereq_bus_clk);
> + if (ret)
> + return ret;
>  
>   return clk_gate(bcm_clk->ccu, bcm_clk->init_data.name, gate, true);
>  }
> @@ -997,6 +1003,9 @@ static void kona_peri_clk_disable(struct clk_hw *hw)
>   struct bcm_clk_gate *gate = &bcm_clk->u.peri->gate;
>  
>   (void)clk_gate(bcm_clk->ccu, bcm_clk->init_data.name, gate, false);
> +

Re: [PATCH] block: virtio_blk: don't hold spin lock during world switch

[Jens Axboe]

On 2014-05-29 20:49, Ming Lei wrote:

Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.

Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and block other vCPUs.

On arm64 quad core VM(qemu-kvm), the patch can increase I/O
performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
- without the patch: 14K IOPS
- with the patch: 34K IOPS


Patch looks good to me. I don't see a hit on my qemu-kvm testing, but it 
definitely makes sense and I can see it hurting in other places.


--
Jens Axboe

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

[RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

[Masami Hiramatsu]

On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizing its blacklist, it fails and reports many errors
as below.

  Failed to find blacklist 000101316830
  Failed to find blacklist 0001013000f0a000
  Failed to find blacklist 000101315f70a000
  Failed to find blacklist 000101324c80a000
  Failed to find blacklist 0001013063f0a000
  Failed to find blacklist 000101327800a000
  Failed to find blacklist 0001013277f0a000
  Failed to find blacklist 000101315a70a000
  Failed to find blacklist 0001013277e0a000
  Failed to find blacklist 000101305a20a000
  Failed to find blacklist 0001013277d0a000
  Failed to find blacklist 00010130bdc0a000
  Failed to find blacklist 00010130dc20a000
  Failed to find blacklist 000101309a00a000
  Failed to find blacklist 0001013277c0a000
  Failed to find blacklist 0001013277b0a000
  Failed to find blacklist 0001013277a0a000
  Failed to find blacklist 000101327790a000
  Failed to find blacklist 000101303140a000
  Failed to find blacklist 0001013a3280a000

To fix this bug, this introduces function_entry() macro to
retrieve the entry address from the given function pointer,
and uses for kallsyms_lookup_size_offset() while initializing
blacklist.

Changes in v3:
 - Fix a bug to get blacklist address based on function entry
   instead of function descriptor. (Suzuki's work, Thanks!)

Changes in V2:
 - Use function_entry() macro when lookin up symbols instead
   of storing it.
 - Update for the latest -next.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Suzuki K. Poulose 
Reported-by: Tony Luck 
Cc: Suzuki K. Poulose 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Ananth N Mavinakayanahalli 
Cc: Kevin Hao 
Cc: linux-i...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/ia64/include/asm/types.h|2 ++
 arch/powerpc/include/asm/types.h |   11 +++
 include/linux/types.h|4 
 kernel/kprobes.c |   11 +++
 4 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
index 4c351b1..95279dd 100644
--- a/arch/ia64/include/asm/types.h
+++ b/arch/ia64/include/asm/types.h
@@ -27,5 +27,7 @@ struct fnptr {
unsigned long gp;
 };
 
+#define function_entry(fn) (((struct fnptr *)(fn))->ip)
+
 #endif /* !__ASSEMBLY__ */
 #endif /* _ASM_IA64_TYPES_H */
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index bfb6ded..8b89d65 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -25,6 +25,17 @@ typedef struct {
unsigned long env;
 } func_descr_t;
 
+#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
+/*
+ * On PPC64 ABIv1 the function pointer actually points to the
+ * function's descriptor. The first entry in the descriptor is the
+ * address of the function text.
+ */
+#define function_entry(fn) (((func_descr_t *)(fn))->entry)
+#else
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_TYPES_H */
diff --git a/include/linux/types.h b/include/linux/types.h
index a0bb704..3b95369 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -213,5 +213,9 @@ struct callback_head {
 };
 #define rcu_head callback_head
 
+#ifndef function_entry
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
 #endif /*  __ASSEMBLY__ */
 #endif /* _LINUX_TYPES_H */
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2ac9f13..3f2d6d4 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -32,6 +32,7 @@
  *  added function-return probes.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2042,16 +2043,18 @@ static int __init populate_kprobe_blacklist(unsigned 
long *start,
unsigned long offset = 0, size = 0;
 
for (iter = start; iter < end; iter++) {
-   if (!kallsyms_lookup_size_offset(*iter, &size, &offset)) {
-   pr_err("Failed to find blacklist %p\n", (void *)*iter);
+   unsigned long entry = function_entry(*iter);
+   if (!kallsyms_lookup_size_offset(entry, &size, &offset)) {
+   pr_err("Failed to find blacklist at %p\n",
+  (void *)entry);
continue;
}
 
ent = kmalloc(sizeof(*ent), GFP_KERNEL);
if (!ent)
return -ENOMEM;
-   ent->start_addr = *iter;
-   ent->end_addr = *iter + size;
+   ent->start_addr = entry;
+   ent->end_addr = entry + size;
INIT_LIST_HEAD(&ent->list);
list_add_ta

Re: [PATCH V2 1/2] ftrace: Make saved_cmdlines use seq_read

[Steven Rostedt]

On Thu, 20 Feb 2014 17:44:31 +0900
Yoshihiro YUNOMAE  wrote:

> Current tracing_saved_cmdlines_read() implementation is naive;
> simply allocate a big buffer, construct output data on the
> buffer for each read operation, and then copy a portion of
> the buffer to the user space buffer.  This can cause a couple of
> issues such as a slow memory allocation, high cpu usage, and a
> corruption of the output data.
> 
> To address these issues, make saved_cmdlines use seq_read.

I changed the subject and change log to the following. The patch is
untouched:

tracing: Have saved_cmdlines use the seq_read infrastructure

Current tracing_saved_cmdlines_read() implementation is naive; It
allocates a large buffer, constructs output data to that buffer for
each read operation, and then copies a portion of the buffer to the
user space buffer. This has several issues such as slow memory
allocation, high CPU usage, and even corruption of the output data.

The seq_read infrastructure is made to handle this type of work.
By converting it to use seq_read() the code becomes smaller,
simplified, as well as correct.


-- Steve
--
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] hwmon: (iManager2) Add support for IT8516/18/28

[Guenter Roeck]

On 05/28/2014 10:57 PM, Wei-Chun Pan wrote:

 Advantech's new module comes equipped with "iManager" - an embedded 
controller (EC), providing embedded features for system integrators to increase 
reliability and simplify integration.
 This patch add the MFD driver for enabling Advantech iManager V2.0 
chipset. Available functions support HW Monitor base on ITE-IT85XX chip. These 
functions are tested on Advantech SOM-5892 board. All the embedded functions 
are configured by a utility. Advantech has done all the hard work for user with 
the release of a suite of Software APIs.
 These provide not only the underlying drivers required but also a rich set 
of user-friendly, intelligent and integrated interfaces, which speeds 
development, enhances security and offers add-on value for Advantech platforms.


Doesn't really follow SubmittingPatches guidelines; lines should be shorter.


Signed-off-by: Wei-Chun Pan Developer 


I assume 'Developer' is not part of your name ?


---
  drivers/hwmon/Kconfig |   7 +
  drivers/hwmon/Makefile|   1 +
  drivers/hwmon/imanager2_hwm.c | 635 ++
  drivers/hwmon/imanager2_hwm.h | 118 
  4 files changed, 761 insertions(+)
  mode change 100644 => 100755 drivers/hwmon/Kconfig
  mode change 100644 => 100755 drivers/hwmon/Makefile
  create mode 100755 drivers/hwmon/imanager2_hwm.c
  create mode 100755 drivers/hwmon/imanager2_hwm.h


Executable source files ? Note that checkpatch complains about this.


diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
old mode 100644
new mode 100755
index bc196f4..d4aeab6
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,13 @@ config HWMON_DEBUG_CHIP

  comment "Native drivers"

+config SENSORS_IMANAGER2
+   tristate "Support for Advantech iManager2 EC H.W. Monitor"
+   select MFD_CORE
+   select MFD_IMANAGER2


It is customary to express this as dependency. Should be
depends on MFD_IMANAGER2



+   help
+ Support for the Advantech iManager2 EC H.W. Monitor
+
  config SENSORS_AB8500
tristate "AB8500 thermal monitoring"
depends on AB8500_GPADC && AB8500_BM
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
old mode 100644
new mode 100755
index c48f987..a2c8f07
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
  obj-$(CONFIG_SENSORS_W83L786NG)   += w83l786ng.o
  obj-$(CONFIG_SENSORS_WM831X)  += wm831x-hwmon.o
  obj-$(CONFIG_SENSORS_WM8350)  += wm8350-hwmon.o
+obj-$(CONFIG_SENSORS_IMANAGER2)+= imanager2_hwm.o

  obj-$(CONFIG_PMBUS)   += pmbus/

diff --git a/drivers/hwmon/imanager2_hwm.c b/drivers/hwmon/imanager2_hwm.c
new file mode 100755
index 000..48fe3dd
--- /dev/null
+++ b/drivers/hwmon/imanager2_hwm.c
@@ -0,0 +1,635 @@
+/* imanager2_hwm.c - HW Monitoring interface for Advantech EC IT8516/18/28
+ * Copyright (C) 2014  Richard Vidal-Dorsch 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+

Not needed; see below.


+#include 
+#include 
+#include 
+#include 
+#include 
+#include "imanager2_hwm.h"
+
+#define DRV_NAME   CHIP_NAME "_hwm"


Note that "it85xx" as chip name is a bit too generic. You don't support all 
chips
starting with IT85, do you ? I would suggest to pick one of the supported chips 
as
driver name.


+#define DRV_VERSION"0.4.6"
+
+/* Voltage */
+static int ec_get_voltage_adc(struct it85xx *ec, int index,


Same applies to this structure, really.


+ u32 *volt_millivolt)
+{
+   int ret;
+   u8 portnum, tmp[2];
+
+   *volt_millivolt = 0;
+
+   spin_lock(&ec->lock);
+
+   if ((ec->flag & EC_F_MAILBOX) != 0) {


The "!= 0" in those comparisons is really unnecessary.
This is implied.


+   ret = ec_mailbox_read_buffer(ec, EC_CMD_MAILBOX_READ_HW_PIN,
+ec_volt_table[index].did, &tmp[0],
+2);
+   } else {
+   u8 pin = ec->table.pinnum[ec->table.devid2itemnum[
+   ec_volt_table[index].did]];
+
+   ret = ec_io_read(EC_CMD_ADC_INDEX, pin, &portnum, 1);
+   if (ret != 0)
+   go

Ask for help on the memory allocation for process shared mutex (resend with plain text)

[yang ben]

Dear experts,

I came across a memory/mutex issue. Would you kindly shed some light on it?

I use pthread_mutex_xxx API to protect processes in user space. Since
it should be process shared, I allocated a shared memory to store
pthread_mutex_t structure.

The shared memory is allocated using vmalloc_user() and mapped using
remap_vmalloc_range() in driver. However, get_futex_key() will always
return -EFAULT, because page_head->mapping==0.

futex.c (Linux-3.10.31)
 if (!page_head->mapping) {
 int shmem_swizzled = PageSwapCache(page_head);
 unlock_page(page_head);
 put_page(page_head);
 if (shmem_swizzled)
 goto again;
 return -EFAULT;
 }

Is there special requirement on the memory to store mutex? What's the
correct way to allocate such memory in driver?
Thanks in advance!

Regards,
Ben
--
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] block: virtio_blk: don't hold spin lock during world switch

[Ming Lei]

Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.

Secondly, virtqueue_notify() will cause world switch and
it may take long time on some hypervisors(such as, qemu-arm),
so it isn't good to hold the lock and block other vCPUs.

On arm64 quad core VM(qemu-kvm), the patch can increase I/O
performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
- without the patch: 14K IOPS
- with the patch: 34K IOPS

fio script:
[global]
direct=1
bsrange=4k-4k
timeout=10
numjobs=4
ioengine=libaio
iodepth=64

filename=/dev/vdc
group_reporting=1

[f1]
rw=randread

Cc: Rusty Russell 
Cc: "Michael S. Tsirkin" 
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Ming Lei 
---
 drivers/block/virtio_blk.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 9f340fa..a6f5424 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -162,6 +162,7 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, 
struct request *req)
unsigned int num;
const bool last = (req->cmd_flags & REQ_END) != 0;
int err;
+   bool notify = false;
 
BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems);
 
@@ -214,10 +215,12 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, 
struct request *req)
return BLK_MQ_RQ_QUEUE_ERROR;
}
 
-   if (last)
-   virtqueue_kick(vblk->vq);
-
+   if (last && virtqueue_kick_prepare(vblk->vq))
+   notify = true;
spin_unlock_irqrestore(&vblk->vq_lock, flags);
+
+   if (notify)
+   virtqueue_notify(vblk->vq);
return BLK_MQ_RQ_QUEUE_OK;
 }
 
-- 
1.7.9.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: [RFT PATCH -next v2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

[Masami Hiramatsu]

(2014/05/30 4:13), Suzuki K. Poulose wrote:
>> @@ -2042,7 +2043,8 @@ static int __init populate_kprobe_blacklist(unsigned 
>> long *start,
>>  unsigned long offset = 0, size = 0;
>>  
>>  for (iter = start; iter < end; iter++) {
>> -if (!kallsyms_lookup_size_offset(*iter, &size, &offset)) {
>> +if (!kallsyms_lookup_size_offset(function_entry(*iter),
>> + &size, &offset)) {
> 
> On powerpc we will be able to resolve the *iter to func_descr and won't
> get the below error with/without this patch. So we have to actually
> verify the kprobe_blacklist contents to make sure everything is alright.
> 
>>  pr_err("Failed to find blacklist %p\n", (void *)*iter);
>>  continue;
>>  }
>>
> 
> There is a bug here.
> You need to set the ent->start using the function_entry(*iter) and not
> *iter. Or else you just avoid the 'Warning' and still have an invalid
> black list. As shown below :
> 
> 2e:mon> ls kprobe_blacklist
> kprobe_blacklist: c104dad0
> 2e:mon> d c104dad0 10
> c104dad0: c003aff800a0 c003aff809a0
> 2e:mon> d c003aff800a0 20 (struct kprobe_blacklist *)
> c003aff800a0: c003aff800c0 c104dad0
> c003aff800b0: c10ef138 c10ef188
>   start ^^ end ^^
> 2e:mon> la c10ef138 (start)
> c10ef138: notify_die+0x0/0x10 <- still points to the
> function descriptor
> 2e:mon> la c10ef188 (end)
> c10ef188: __blocking_notifier_call_chain+0x0/0x10
> 
> 
> Following patch fixes the issue, with the patch :
> 
> 1:mon> ls kprobe_blacklist
> kprobe_blacklist: c104dad0
> 1:mon> d c104dad0 10
> c104dad0: c003ae1a00a0 c003ae1a09a0
> 1:mon> d c003ae1a00a0 20 (struct kprobe_blacklist *)
> c003ae1a00a0: c003ae1a00c0 c104dad0
> c003ae1a00b0: c00b14d0 c00b1520
>   start ^^ end ^^
> 1:mon> la c00b14d0
> c00b14d0: .notify_die+0x0/0x50
> 1:mon> la c00b1520
> c00b1520: .atomic_notifier_chain_register+0x0/0xa0
> 
> 1:mon> di c00b14d0 10 (.notify_die)
> c00b14d0  7c0802a6mflrr0
> c00b14d4  7c691b78mr  r9,r3
> 
> commit ed51674aca8e0496641f565421ab6691a873e80a
> Author: Suzuki K. Poulose 
> Date:   Fri May 30 00:23:01 2014 +0530
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3859c88..b81d626 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2043,7 +2043,8 @@ static int __init
> populate_kprobe_blacklist(unsigned long *start,
> unsigned long offset = 0, size = 0;
> 
> for (iter = start; iter < end; iter++) {
> -   if (!kallsyms_lookup_size_offset(function_entry(*iter),
> +   unsigned long entry = function_entry(*iter);
> +   if (!kallsyms_lookup_size_offset(entry,
>  &size, &offset)) {
> pr_err("Failed to find blacklist %p\n", (void
> *)*iter);
> continue;
> @@ -2052,8 +2053,8 @@ static int __init
> populate_kprobe_blacklist(unsigned long *start,
> ent = kmalloc(sizeof(*ent), GFP_KERNEL);
> if (!ent)
> return -ENOMEM;
> -   ent->start_addr = *iter;
> -   ent->end_addr = *iter + size;
> +   ent->start_addr = entry;
> +   ent->end_addr = entry + size;

Oops! right, I missed it :(
I'll update the patch including your fix and signed-off-by.

thank you!


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH v3] pinctrl: to avoid duplicated calling enable_pinmux_setting for a pin

[FanWu]

On 05/30/2014 03:19 AM, Stephen Warren wrote:

On 05/25/2014 08:43 PM, f...@marvell.com wrote:

From: Fan Wu 

What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
   calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.

...

This commit description is way too long for such a simple change. A much
shorter summary would be better.


Signed-off-by: Fan Wu 
Signed-off-by: Stephen Warren 


I'm pretty sure I never signed off on this patch. How come my s-o-b line
is there?

This patch still doesn't remove ops->disable from the struct pinmux_ops,
nor any of its implementations. Shouldn't it?



Dear Stephen,

For your comments 1: The reason why I want to put a lot of info into the 
patch comments is that the long term discussion about the topic and the 
patch is not that easy to understand for a patch reader, or maybe is not 
easy for us to understand in far future.


For your comments 2: I accepted your suggestion of inline code comments 
and some other suggestions from our discussion, so I added your signed 
off tailing in the patch comments.

If you think it is not fine, I can remove it in the new patch version.

For your comments 3:
I think I have made myself clear in the last mail:
1) If I remove the ops->disable from the struct pinmux_ops in this 
patch, the pinctrl-single user will got build error immediately.
2) Thus, I want to merge this patch first and then make other two 
patches later:

One is to remove the ops->disable registration in pinctrl-single driver.
And the other is to remove ops->disable in struct pinmux_ops.

Could you please give your final suggestion about this and then I will 
give new patch?


Great thanks about this! :)

Looking forward your reply !
--
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: Performance regression in v3.14

[Greg Kroah-Hartman]

On Wed, May 28, 2014 at 09:59:45AM +0200, Johan Hovold wrote:
> [ +CC: Greg, Doug, Stratos, Yuyang ]
> 
> On Wed, May 21, 2014 at 11:00:51AM +0200, Johan Hovold wrote:
> > On Wed, May 07, 2014 at 07:10:49AM -0700, Dirk Brandewie wrote:
> > > On 05/06/2014 10:40 PM, Viresh Kumar wrote:
> > > > Cc'ing Dirk who is taking care of intel-pstate driver.
> > > >
> > > 
> > > Thanks Viresh I had seen this thread.
> > > 
> > > I am looking into it
> > 
> > Any updates on this, Dirk? 3.14 is still basically unusable with the
> > intel_pstate driver.
> > 
> > Any fixes or workarounds posted elsewhere that I can apply in the
> > meantime?
> 
> Another week and still no reply, Dirk?
> 
> I tried applying your (rejected) patch "intel_pstate: Remove C0
> tracking" posted here:
> 
>   https://lkml.org/lkml/2014/5/8/574
> 
> to v3.14.4 and it fixes the problem as expected.
> 
> So we have a commit fcb6a15c2e7e ("intel_pstate: Take core C0 time into
> account for core busy calculation") that went into v3.14-rc2 (and was
> even marked for *stable*) that first broke Greg KH's system:
> 
>   https://lkml.org/lkml/2014/2/19/626
> 
> That was apparently fixed by e66c17683746 ("intel_pstate: Change
> busy calculation to use fixed point math."), but still left v3.14
> basically unusable for lower-intensity workloads such as my
> bash-completion example and other reported regressions:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=75121
> 
> Sure there may be issues with v3.13 not hitting the lowest frequencies
> but at least the system was *usable*.
> 
> In my opinion there's really no other option than to restore the 3.13
> behaviour by effectively reverting fcb6a15c2e7e ("intel_pstate: Take
> core C0 time into account for core busy calculation") until you have
> figured out a way to take C0 into account without breaking things too
> badly.

Dirk has posted some patches, do they fix the problem for you?

thanks,

greg k-h
--
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] export efi.flags to sysfs

[Dave Young]

On 05/29/14 at 08:45am, Vivek Goyal wrote:
> On Thu, May 29, 2014 at 10:08:37AM +0800, Dave Young wrote:
> > On 05/28/14 at 08:40am, Vivek Goyal wrote:
> > > On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > > > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > > > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> > > > > > 
> > > > > > For efi=old_map and any old_map quirks like SGI UV in current
> > > > > > tree kexec/kdump will fail because it depends on the new 1:1 
> > > > > > mapping.
> > > > > > 
> > > > > > Thus export the mapping method to sysfs so kexec tools can switch
> > > > > > to original way to boot.
> > > > > > 
> > > > > > Since we have efi.flags for all efi facilities so let's just export 
> > > > > > the
> > > > > > efi.flags itself, it maybe useful for other arches and use cases.
> > > > > > 
> > > > > 
> > > > > Does it require any documentation in Documentation/ABI/..
> > > > 
> > > > Yes, it's necessary. Will do in next version.
> > > > 
> > > > I'm still discussing with Matt, exporting efi.flags seems not a good way
> > > > because they are more internal interfaces. 
> > > > 
> > > > Probably I should export only a file 'old_map' instead.
> > > 
> > > How does /sys/firmware/efi/runtime-map/* look like with old mapping? Can't
> > > we look at it and figure out if it is 1:1 or not.
> > 
> > There's phys_addr and virt_addr, (virt_addr - phys_addr) will always be
> > -64G for 1:1 map, ioremapped addresses space is different.

Correct myself it's top to down (-4G - -64G) instead of down to top. 

> 
> I am curious that what's the meaning of 1:1 mapping here? So far I thought
> that means virt and physical addresses are same but that does not seem
> to be the case. So what does it mean?

while doing the mapping, we will iterate the memory ranges (md[])

Like below without considering alignment:
Virt addr   (down) <--> (top)
md0 (size0) <-> 
 (size0)
md1 (size1)<--->
(size1)
...

Boris can correct me if I'm wrong.

Thanks
Dave
--
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/5] mm: i_mmap_mutex to rwsem

[Davidlohr Bueso]

ping? Andrew any chance of getting this in -next?

On Thu, 2014-05-22 at 20:33 -0700, Davidlohr Bueso wrote:
> This patchset extends the work started by Ingo Molnar in late 2012,
> optimizing the anon-vma mutex lock, converting it from a exclusive mutex
> to a rwsem, and sharing the lock for read-only paths when walking the
> the vma-interval tree. More specifically commits 5a505085 and 4fc3f1d6.
> 
> The i_mmap_mutex has similar responsibilities with the anon-vma, protecting
> file backed pages. Therefore we can use similar locking techniques: covert
> the mutex to a rwsem and share the lock when possible.
> 
> With the new optimistic spinning property we have in rwsems, we no longer
> take a hit in performance when using this lock, and we can therefore
> safely do the conversion. Tests show no throughput regressions in aim7 or
> pgbench runs, and we can see gains from sharing the lock, in disk workloads
> ~+15% for over 1000 users on a 8-socket Westmere system.
> 
> This patchset applies on linux-next-20140522.
> 
> Thanks!
> 
> Davidlohr Bueso (5):
>   mm,fs: introduce helpers around i_mmap_mutex
>   mm: use new helper functions around the i_mmap_mutex
>   mm: convert i_mmap_mutex to rwsem
>   mm/rmap: share the i_mmap_rwsem
>   mm: rename leftover i_mmap_mutex
> 
>  fs/hugetlbfs/inode.c | 14 +++---
>  fs/inode.c   |  2 +-
>  include/linux/fs.h   | 23 ++-
>  include/linux/mmu_notifier.h |  2 +-
>  kernel/events/uprobes.c  |  6 +++---
>  kernel/fork.c|  4 ++--
>  mm/filemap.c | 10 +-
>  mm/filemap_xip.c |  4 ++--
>  mm/hugetlb.c | 22 +++---
>  mm/memory-failure.c  |  4 ++--
>  mm/memory.c  |  8 
>  mm/mmap.c| 22 +++---
>  mm/mremap.c  |  6 +++---
>  mm/nommu.c   | 14 +++---
>  mm/rmap.c| 10 +-
>  15 files changed, 86 insertions(+), 65 deletions(-)
> 


--
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 9/10] ACPI / scan: always register ACPI LPSS scan handler

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Prevent platform devices from being created for ACPI LPSS devices
if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan
handler's callbacks only in that case and still compiling its device
ID list in and registering the scan handler in either case.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 

---
drivers/acpi/Makefile|  2 +-
 drivers/acpi/Makefile|2 -
 drivers/acpi/acpi_lpss.c |   65 ---
 drivers/acpi/internal.h  |4 --
 3 files changed, 46 insertions(+), 25 deletions(-)

Index: linux-pm/drivers/acpi/Makefile
===
--- linux-pm.orig/drivers/acpi/Makefile
+++ linux-pm/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
+acpi-y += acpi_lpss.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-y += power.o
Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -25,6 +25,10 @@
 
 ACPI_MODULE_NAME("acpi_lpss");
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
+#define LPSS_PTR(desc) ((unsigned long)&desc)
+
 #define LPSS_CLK_SIZE  0x04
 #define LPSS_LTR_SIZE  0x18
 
@@ -168,40 +172,48 @@ static struct lpss_device_desc byt_i2c_d
.shared_clock = &i2c_clock,
 };
 
+#else
+
+#define LPSS_PTR(desc) (NULL)
+
+#endif /* CONFIG_X86_INTEL_LPSS */
+
 static const struct acpi_device_id acpi_lpss_device_ids[] = {
/* Generic LPSS devices */
-   { "INTL9C60", (unsigned long)&lpss_dma_desc },
+   { "INTL9C60", LPSS_PTR(lpss_dma_desc) },
 
/* Lynxpoint LPSS devices */
-   { "INT33C0", (unsigned long)&lpt_dev_desc },
-   { "INT33C1", (unsigned long)&lpt_dev_desc },
-   { "INT33C2", (unsigned long)&lpt_dev_desc },
-   { "INT33C3", (unsigned long)&lpt_dev_desc },
-   { "INT33C4", (unsigned long)&lpt_uart_dev_desc },
-   { "INT33C5", (unsigned long)&lpt_uart_dev_desc },
-   { "INT33C6", (unsigned long)&lpt_sdio_dev_desc },
+   { "INT33C0", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C1", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C2", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C3", LPSS_PTR(lpt_dev_desc) },
+   { "INT33C4", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT33C5", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT33C6", LPSS_PTR(lpt_sdio_dev_desc) },
{ "INT33C7", },
 
/* BayTrail LPSS devices */
-   { "80860F09", (unsigned long)&byt_pwm_dev_desc },
-   { "80860F0A", (unsigned long)&byt_uart_dev_desc },
-   { "80860F0E", (unsigned long)&byt_spi_dev_desc },
-   { "80860F14", (unsigned long)&byt_sdio_dev_desc },
-   { "80860F41", (unsigned long)&byt_i2c_dev_desc },
+   { "80860F09", LPSS_PTR(byt_pwm_dev_desc) },
+   { "80860F0A", LPSS_PTR(byt_uart_dev_desc) },
+   { "80860F0E", LPSS_PTR(byt_spi_dev_desc) },
+   { "80860F14", LPSS_PTR(byt_sdio_dev_desc) },
+   { "80860F41", LPSS_PTR(byt_i2c_dev_desc) },
{ "INT33B2", },
 
-   { "INT3430", (unsigned long)&lpt_dev_desc },
-   { "INT3431", (unsigned long)&lpt_dev_desc },
-   { "INT3432", (unsigned long)&lpt_dev_desc },
-   { "INT3433", (unsigned long)&lpt_dev_desc },
-   { "INT3434", (unsigned long)&lpt_uart_dev_desc },
-   { "INT3435", (unsigned long)&lpt_uart_dev_desc },
-   { "INT3436", (unsigned long)&lpt_sdio_dev_desc },
+   { "INT3430", LPSS_PTR(lpt_dev_desc) },
+   { "INT3431", LPSS_PTR(lpt_dev_desc) },
+   { "INT3432", LPSS_PTR(lpt_dev_desc) },
+   { "INT3433", LPSS_PTR(lpt_dev_desc) },
+   { "INT3434", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT3435", LPSS_PTR(lpt_uart_dev_desc) },
+   { "INT3436", LPSS_PTR(lpt_sdio_dev_desc) },
{ "INT3437", },
 
{ }
 };
 
+#ifdef CONFIG_X86_INTEL_LPSS
+
 static int is_memory(struct acpi_resource *res, void *not_used)
 {
struct resource r;
@@ -666,3 +678,16 @@ void __init acpi_lpss_init(void)
acpi_scan_add_handler(&lpss_handler);
}
 }
+
+#else
+
+static struct acpi_scan_handler lpss_handler = {
+   .ids = acpi_lpss_device_ids,
+};
+
+void __init acpi_lpss_init(void)
+{
+   acpi_scan_add_handler(&lpss_handler);
+}
+
+#endif /* CONFIG_X86_INTEL_LPSS */
Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -65,11 +65,7 @@ int acpi_debugfs_init(void);
 #else
 static inline void acpi_debugfs_init(void) { return; }
 #endif
-#

[PATCH 8/10] ACPI / scan: always register memory hotplug scan handler

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Prevent platform devices from being created for ACPI memory device
objects if CONFIG_ACPI_HOTPLUG_MEMORY is unset by compiling out the
memory hotplug scan handler's callbacks only in that case and still
compiling its device ID list in and registering the scan handler in
either case.

Also unset the memory hotplug scan handler's .attach() callback
if acpi_no_memhotplug is set, but still register the scan handler to
avoid creating platform devices for ACPI memory devices in that case
too.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 

---
drivers/acpi/Makefile  |  2 +-
 drivers/acpi/Makefile  |2 +-
 drivers/acpi/acpi_memhotplug.c |   31 ---
 drivers/acpi/internal.h|6 +-
 3 files changed, 26 insertions(+), 13 deletions(-)

Index: linux-pm/drivers/acpi/Makefile
===
--- linux-pm.orig/drivers/acpi/Makefile
+++ linux-pm/drivers/acpi/Makefile
@@ -66,7 +66,7 @@ obj-$(CONFIG_ACPI_PCI_SLOT)   += pci_slot.
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
 obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
-obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-y  += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
 obj-$(CONFIG_ACPI_SBS) += sbshc.o
 obj-$(CONFIG_ACPI_SBS) += sbs.o
Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -33,6 +33,7 @@ void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
 void acpi_container_init(void);
+void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
@@ -44,11 +45,6 @@ static inline void register_dock_depende
 static inline int dock_notify(struct acpi_device *adev, u32 event) { return 
-ENODEV; }
 static inline void acpi_dock_add(struct acpi_device *adev) {}
 #endif
-#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
-void acpi_memory_hotplug_init(void);
-#else
-static inline void acpi_memory_hotplug_init(void) {}
-#endif
 #ifdef CONFIG_X86
 void acpi_cmos_rtc_init(void);
 #else
Index: linux-pm/drivers/acpi/acpi_memhotplug.c
===
--- linux-pm.orig/drivers/acpi/acpi_memhotplug.c
+++ linux-pm/drivers/acpi/acpi_memhotplug.c
@@ -44,6 +44,13 @@
 
 ACPI_MODULE_NAME("acpi_memhotplug");
 
+static const struct acpi_device_id memory_device_ids[] = {
+   {ACPI_MEMORY_DEVICE_HID, 0},
+   {"", 0},
+};
+
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+
 /* Memory Device States */
 #define MEMORY_INVALID_STATE   0
 #define MEMORY_POWER_ON_STATE  1
@@ -53,11 +60,6 @@ static int acpi_memory_device_add(struct
  const struct acpi_device_id *not_used);
 static void acpi_memory_device_remove(struct acpi_device *device);
 
-static const struct acpi_device_id memory_device_ids[] = {
-   {ACPI_MEMORY_DEVICE_HID, 0},
-   {"", 0},
-};
-
 static struct acpi_scan_handler memory_device_handler = {
.ids = memory_device_ids,
.attach = acpi_memory_device_add,
@@ -364,9 +366,11 @@ static bool __initdata acpi_no_memhotplu
 
 void __init acpi_memory_hotplug_init(void)
 {
-   if (acpi_no_memhotplug)
+   if (acpi_no_memhotplug) {
+   memory_device_handler.attach = NULL;
+   acpi_scan_add_handler(&memory_device_handler);
return;
-
+   }
acpi_scan_add_handler_with_hotplug(&memory_device_handler, "memory");
 }
 
@@ -376,3 +380,16 @@ static int __init disable_acpi_memory_ho
return 1;
 }
 __setup("acpi_no_memhotplug", disable_acpi_memory_hotplug);
+
+#else
+
+static struct acpi_scan_handler memory_device_handler = {
+   .ids = memory_device_ids,
+};
+
+void __init acpi_memory_hotplug_init(void)
+{
+   acpi_scan_add_handler(&memory_device_handler);
+}
+
+#endif /* CONFIG_ACPI_HOTPLUG_MEMORY */

--
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/10] ACPI / scan: drop IDs that do not comply with the ACPI PNP ID rule

[Rafael J. Wysocki]

From: Zhang Rui 

The PNP ACPI scan handler device ID list includes all the IDs from
all of the struct pnp_device_id instances in the tree, but some of
them do not follow the ACPI PNP ID rule (3 letters + 4 hex digits).

For those IDs, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove them from the PNP ACPI ID list.

Signed-off-by: Zhang Rui 
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki 
---
drivers/acpi/acpi_pnp.c | 4 
 drivers/acpi/acpi_pnp.c |4 
 1 file changed, 4 deletions(-)

Index: linux-pm/drivers/acpi/acpi_pnp.c
===
--- linux-pm.orig/drivers/acpi/acpi_pnp.c
+++ linux-pm/drivers/acpi/acpi_pnp.c
@@ -34,10 +34,6 @@ static const struct acpi_device_id acpi_
/* ide   */
{"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
/* ns558 */
-   {"@P@0001"},/* ALS 100 */
-   {"@P@0020"},/* ALS 200 */
-   {"@P@1001"},/* ALS 100+ */
-   {"@P@2001"},/* ALS 120 */
{"ASB16fd"},/* AdLib NSC16 */
{"AZT3001"},/* AZT1008 */
{"CDC0001"},/* Opl3-SAx */

--
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 6/10] ACPI / scan: Change the meaning of missing .attach() in scan handlers

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Currently, some scan handlers can be compiled out entirely, which
leaves the device objects they normally attach to without a scan
handler.  This isn't a problem as long as we don't have any default
enumeration mechanism that applies to all devices without a scan
handler.  However, if such a default enumeration is added, it still
should not be applied to devices that are normally attached to by
scan handlers, because that may result in creating "physical" device
objects of a wrong type for them.

Since we are going to create platform device objects for all ACPI
device objects with pnp.type.platform_id set by default, clear
pnp.type.platform_id where there is a matching scan handler without
an .attach() callback and otherwise simply treat that scan handler
as though the .attach() callback was present but always returned 0.

This will allow us to compile out scan handler callbacks and leave
the device ID lists used by them so as to prevent creating platform
device objects for the matching ACPI devices.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/scan.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -84,7 +84,7 @@ EXPORT_SYMBOL_GPL(acpi_initialize_hp_con
 
 int acpi_scan_add_handler(struct acpi_scan_handler *handler)
 {
-   if (!handler || !handler->attach)
+   if (!handler)
return -EINVAL;
 
list_add_tail(&handler->list_node, &acpi_scan_handlers_list);
@@ -2081,6 +2081,10 @@ static int acpi_scan_attach_handler(stru
 
handler = acpi_scan_match_handler(hwid->id, &devid);
if (handler) {
+   if (!handler->attach) {
+   device->pnp.type.platform_id = 0;
+   continue;
+   }
device->handler = handler;
ret = handler->attach(device, devid);
if (ret > 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 4/10] ACPI / scan: drop unsupported serial IDs from PNP ACPI scan handler ID list

[Rafael J. Wysocki]

From: Zhang Rui 

The "serial" PNP driver supports some "unknown" PNP modems
(PNPCXXX/PNPDXXX) by matching magic strings in the PNP device name
or the PNP device card name.

ACPI enumerated PNP devices neither are PNP cards, nor have those
magic strings in device names, so this mechamism never actually works
for ACPI enumerated PNPCXXX/PNPDXXX devices.

Consequently, it is safe to remove those two IDs from the PNP ACPI scan
handler's device ID list.

Signed-off-by: Zhang Rui 
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki 
---
drivers/acpi/acpi_pnp.c | 2 --
 drivers/acpi/acpi_pnp.c |2 --
 1 file changed, 2 deletions(-)

Index: linux-pm/drivers/acpi/acpi_pnp.c
===
--- linux-pm.orig/drivers/acpi/acpi_pnp.c
+++ linux-pm/drivers/acpi/acpi_pnp.c
@@ -301,8 +301,6 @@ static const struct acpi_device_id acpi_
{"LTS0001"},/* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen 
(actually a FUJ02E6 in disguise) */
{"WCI0003"},/* Rockwell's (PORALiNK) 33600 INT PNP */
{"WEC1022"},/* Winbond CIR port, should not be probed. We 
should keep track of it to prevent the legacy serial driver from probing it */
-   {"PNPCXXX"},/* Unknown PnP modems */
-   {"PNPDXXX"},/* More unknown PnP modems */
/* scl200wdt */
{"NSC0800"},/* National Semiconductor PC87307/PC97307 
watchdog component */
/* mpu401 */

--
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 7/10] ACPI / scan: always register container scan handler

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Prevent platform devices from being created for ACPI containers
if CONFIG_ACPI_CONTAINER is unset by compiling out the container
scan handler's callbacks only in that case and still compiling
its device ID list in and registering the scan handler in either
case.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 

---
drivers/acpi/Makefile|  2 +-
 drivers/acpi/Makefile|2 +-
 drivers/acpi/container.c |   15 +++
 drivers/acpi/internal.h  |4 
 3 files changed, 16 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/acpi/Makefile
===
--- linux-pm.orig/drivers/acpi/Makefile
+++ linux-pm/drivers/acpi/Makefile
@@ -64,7 +64,7 @@ obj-$(CONFIG_ACPI_FAN)+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)   += video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)+= pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)   += processor.o
-obj-$(CONFIG_ACPI_CONTAINER)   += container.o
+obj-y  += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
Index: linux-pm/drivers/acpi/container.c
===
--- linux-pm.orig/drivers/acpi/container.c
+++ linux-pm/drivers/acpi/container.c
@@ -41,6 +41,8 @@ static const struct acpi_device_id conta
{"", 0},
 };
 
+#ifdef CONFIG_ACPI_CONTAINER
+
 static int acpi_container_offline(struct container_dev *cdev)
 {
struct acpi_device *adev = ACPI_COMPANION(&cdev->dev);
@@ -109,5 +111,18 @@ static struct acpi_scan_handler containe
 
 void __init acpi_container_init(void)
 {
+   acpi_scan_add_handler(&container_handler);
+}
+
+#else
+
+static struct acpi_scan_handler container_handler = {
+   .ids = container_device_ids,
+};
+
+void __init acpi_container_init(void)
+{
acpi_scan_add_handler_with_hotplug(&container_handler, "container");
 }
+
+#endif /* CONFIG_ACPI_CONTAINER */
Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -32,11 +32,7 @@ void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
 int acpi_sysfs_init(void);
-#ifdef CONFIG_ACPI_CONTAINER
 void acpi_container_init(void);
-#else
-static inline void acpi_container_init(void) {}
-#endif
 #ifdef CONFIG_ACPI_DOCK
 void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);

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

[PATCH 2/10] ACPI / PNP: use device ID list for PNPACPI device enumeration

[Rafael J. Wysocki]

From: Zhang Rui 

ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently.  Namely, if an ACPI device
object
 1. Has a _CRS method,
 2. Has an identification of
"three capital characters followed by four hex digits",
 3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it).  This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.

However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them).  As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices.  That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.

To address that problem it is better to enumerate _HID devices
as platform devices by default.  To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.

The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers.  Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.

Signed-off-by: Zhang Rui 
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/Makefile|1 
 drivers/acpi/acpi_cmos_rtc.c |2 
 drivers/acpi/acpi_pnp.c  |  401 +++
 drivers/acpi/internal.h  |1 
 drivers/acpi/scan.c  |1 
 drivers/pnp/pnpacpi/core.c   |   28 ---
 include/linux/acpi.h |2 
 7 files changed, 411 insertions(+), 25 deletions(-)
 create mode 100644 drivers/acpi/acpi_pnp.c

Index: linux-pm/drivers/acpi/Makefile
===
--- linux-pm.orig/drivers/acpi/Makefile
+++ linux-pm/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK)  += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
 acpi-y += power.o
 acpi-y += event.o
 acpi-y += sysfs.o
Index: linux-pm/drivers/acpi/acpi_cmos_rtc.c
===
--- linux-pm.orig/drivers/acpi/acpi_cmos_rtc.c
+++ linux-pm/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_h
return -ENODEV;
}
 
-   return 0;
+   return 1;
 }
 
 static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
Index: linux-pm/drivers/acpi/acpi_pnp.c
===
--- /dev/null
+++ linux-pm/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,401 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui 
+ *  Rafael J. Wysocki 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+   /* pata_isapnp */
+   {"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* floppy */
+   {"PNP0700"},
+   /* ipmi_si */
+   {"IPI0001"},
+   /* tpm_inf_pnp */
+   {"IFX0101"},/* Infineon TPMs */
+   {"IFX0102"},/* Infineon TPMs */
+   /*tpm_tis */
+   {"PNP0C31"},/* TPM */
+   {"ATM1200"},/* Atmel */
+   {"IFX0102"},/* Infineon */
+   {"BCM0101"},/* Broadcom */
+   {"BCM0102"},/* Broadcom */
+   {"NSC1200"},/* National */
+   {"ICO0102"},/* Intel */
+   /* ide   */
+   {"PNP0600"},/* Generic ESDI/IDE/ATA compatible hard disk 
controller */
+   /* ns558 */
+   {"@P@0001"},/* ALS 100 */
+   {"@P@0020"},/* ALS 200 */
+   {"@P@1001"},/* ALS 100+ */
+   {"@P@2001"},/* ALS 120 */
+   {"ASB16fd"},/* AdLib NSC16 */
+   {"AZT3001"},/* AZT1008 */
+   {"CDC0001"},/* Opl3-SAx */
+   {"CSC0001"},/* CS4232 */
+   {"CSC000f"},/* CS4236 

Re: [PATCH] gpio: Add support for Intel Crystal Cove PMIC

[Zhu, Lejun]

On 5/29/2014 9:51 PM, Linus Walleij wrote:
> On Thu, May 29, 2014 at 9:21 AM, Zhu, Lejun  wrote:
> 
>> Devices based on Intel SoC products such as Baytrail have a Power
>> Management IC. In the PMIC there are subsystems for voltage regulation,
>> A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is
>> called Crystal Cove.
>>
>> This patch adds support for the GPIO function in Crystal Cove.
>>
>> Signed-off-by: Yang, Bin 
>> Signed-off-by: Zhu, Lejun 
> 
> You have gotten several Reviewed-by and Acked-by tags for this
> driver have you not? Please collect them here so I don't have to
> do it.

I'll do it.

>> ---
>> v2:
>> - Use IRQ chip helper to provide irqdomain.
>> - Implement .remove and can now build as a module.
>> - Various fix for unreadable or ugly code pieces.
>> v3:
>> - More fix in irq_handler and probe.
>> v4:
>> - Minor fix of one return statement.
>> v5:
>> - intel_soc_pmic_readb/writeb/setb/clearb are removed from the MFD
>>   driver, so use regmap_* API here instead.
>> - Check for unsupported IRQ type and return -EINVAL.
>> - Create to_cg() and to_reg() inline functions to make the code
>>   readable.
> 
> Pretty cool eh? :-)
> 
>> +#include 
> 
> As you realize I cannot merge this patch until that
> header file exists, so the MFD core patch needs to go
> in first.
> 
>> +
>> +#define NUM_GPIO   16
> 
> Too generic name, say CRYSTAL_NUM_GPIO or something.
> 
>> +   gpiochip_irqchip_add(&cg->chip, &crystalcove_irqchip, 0,
>> +handle_simple_irq, IRQ_TYPE_NONE);
>> +
>> +   retval = request_threaded_irq(irq, NULL, 
>> crystalcove_gpio_irq_handler,
>> + IRQF_ONESHOT, KBUILD_MODNAME, cg);
>> +
>> +   if (retval) {
>> +   dev_warn(&pdev->dev, "request irq failed: %d\n", retval);
>> +   goto out;
>> +   }
>> +
>> +   retval = gpiochip_add(&cg->chip);
>> +   if (retval) {
>> +   dev_warn(&pdev->dev, "add gpio chip error: %d\n", retval);
>> +   goto out_free_irq;
>> +   }
> 
> As mentioned, swap these around.
> 
> But the driver is looking real good now, if you just fix the above
> you have my Reviewed-by so you can merge it along with the
> MFD patch in the MFD tree if you like.

Thank you. I will ask Lee Jones if he will do that.

Best Regards
Lejun

--
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 5/10] ACPI / scan: introduce platform_id device PNP type flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Only certain types of ACPI device objects can be enumerated as
platform devices, so in order to distinguish them from the others
introduce a new ACPI device PNP type flag, platform_id, and set it
for devices with a valid _HID to start with.

This change is based on a Zhang Rui's prototype.

Signed-off-by: Rafael J. Wysocki 

---
drivers/acpi/scan.c | 9 -
 drivers/acpi/scan.c |4 +++-
 include/acpi/acpi_bus.h |3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -1797,8 +1797,10 @@ static void acpi_set_pnp_ids(acpi_handle
return;
}
 
-   if (info->valid & ACPI_VALID_HID)
+   if (info->valid & ACPI_VALID_HID) {
acpi_add_id(pnp, info->hardware_id.string);
+   pnp->type.platform_id = 1;
+   }
if (info->valid & ACPI_VALID_CID) {
cid_list = &info->compatible_id_list;
for (i = 0; i < cid_list->count; i++)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -233,7 +233,8 @@ struct acpi_hardware_id {
 struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
-   u32 reserved:30;
+   u32 platform_id:1;
+   u32 reserved:29;
 };
 
 struct acpi_device_pnp {

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

[PATCH 0/10] ACPI enumeration rework (was: Re: [PATCH V7 00/11] ACPI: ACPI enumeration rework)

[Rafael J. Wysocki]

On Friday, May 23, 2014 02:02:22 AM Zhang Rui wrote:
> Hi, all,
> 
> Currently, PNP bus is used as the default bus for for enumerating ACPI
> devices with _HID/_CID.
> For a device that needs to be enumerated to platform bus, we need to add
> its id string to the platform scan handler white list explicitly.
> 
> This becomes a problem as more and more _HID devices need to be
> enumerated to platform bus nowadays, thus the list is continuously growing.
> 
> So, a solution that uses platform bus for _HID enumeration by default
> is preferred.
> 

OK, this has had several rounds of review already and we're really starting
to run out of time with it, so my version of this patchset follows.

It is mostly based on your patches, but reordered and with some major
changes.  Compiled only for now, so please let me know if there's any
breakage in it.  [The last patch will not apply without update of the
device list being removed, but generally this is on top of linux-next
material.]

Thanks,
Rafael

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