Re: [Patch v4 1/2] freezer: check OOM kill while being frozen

[Tejun Heo]

Hello, Michal.

On Mon, Sep 15, 2014 at 04:28:21PM +0200, Michal Hocko wrote:
> > Are we gonna introduce an alternate versions for all of them?
> 
> Are they intended for kernel threads in the first place? The primary

There's no restriction in using them and I'm pretty sure some of them
are used by kernel threads.

> objective seems to be to not wake up user tasks just to put them into
> the fridge when you know they are in a "deep" sleep currently. Kernel

That's one of the uses but not the only one.

> threads know they might freeze themselves when returning from schedule,
> no?

I'm not following.  Can you elaborate?

> freezable_schedule{_timeout} seem to be used only by user tasks AFAICS.
> freezable_schedule_unsafe seems to be more complicated due to nfs and
> cifs but both of them are checking for fatal signal pending and return
> ERESTARTSYS which looks like userspace stuff. So maybe we do not need
> any alternate version for kernel threads.
> 
> I haven't check the workqueue_freezable API.

That one is actually easy and should be fine.

> > What do we actually gain?
> 
> I thought we could easily document and add some rules to where
> try_to_freeze can be called from for userspace tasks. Kernel threads
> know when they are safe to get frozen but we should be more careful
> about user tasks. Whether that can be enforced by an API is a question.
> I do admit this much more complicated than I originally anticipated.
> 
> try_to_freeze should be a nice barrier where you know that waking into
> a new world is safe for the caller (there is no state crossing the

It isn't and I'm not sure it can ever be used as "world" barrier.  It
just doesn't mean that.

> freezing point). Whether a separate API makes this happen is an open
> question. I would hope for much higher bar for adding new freezing
> points for users tasks as those are more tricky to check.

Heh, as far as I can recall, freezer usage has always been a rather
large mess.  In the long term, I think the right thing to do is
merging userland freezing into job control stop so that it doesn't get
the special SIGKILL immunity.  We shouldn't have exposed this
unkillable state the beginning.  :(

Thanks.

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

[PATCH 4/4] NFS/SUNRPC: Remove other deadlock-avoidance mechanisms in nfs_release_page()

[NeilBrown]

Now that nfs_release_page() doesn't block indefinitely, other deadlock
avoidance mechanisms aren't needed.
 - it doesn't hurt for kswapd to block occasionally.  If it doesn't
   want to block it would clear __GFP_WAIT.  The current_is_kswapd()
   was only added to avoid deadlocks and we have a new approach for
   that.
 - memory allocation in the SUNRPC layer can very rarely try to
   ->releasepage() a page it is trying to handle.  The deadlock
   is removed as nfs_release_page() doesn't block indefinitely.

So we don't need to set PF_FSTRANS for sunrpc network operations any
more.

Signed-off-by: NeilBrown 
---
 fs/nfs/file.c   |   16 +++-
 net/sunrpc/sched.c  |2 --
 net/sunrpc/xprtrdma/transport.c |2 --
 net/sunrpc/xprtsock.c   |   10 --
 4 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 8d74983417af..5949ca37cd18 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -469,18 +469,16 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
dfprintk(PAGECACHE, "NFS: release_page(%p)\n", page);
 
/* Always try to initiate a 'commit' if relevant, but only
-* wait for it if __GFP_WAIT is set and the calling process is
-* allowed to block.  Even then, only wait 1 second.  Waiting
-* indefinitely can cause deadlocks when the NFS server is on
-* this machine, and there is no particular need to wait
-* extensively here.  A short wait has the benefit that
-* someone else can worry about the freezer.
+* wait for it if __GFP_WAIT is set.  Even then, only wait 1
+* second.  Waiting indefinitely can cause deadlocks when the
+* NFS server is on this machine, when a new TCP connection is
+* needed and in other rare cases.  There is no particular
+* need to wait extensively here.  A short wait has the
+* benefit that someone else can worry about the freezer.
 */
if (mapping) {
nfs_commit_inode(mapping->host, 0);
-   if ((gfp & __GFP_WAIT) &&
-   !current_is_kswapd() &&
-   !(current->flags & PF_FSTRANS))
+   if ((gfp & __GFP_WAIT))
wait_on_page_bit_killable_timeout(page, PG_private,
  HZ);
}
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 9358c79fd589..fe3441abdbe5 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -821,9 +821,7 @@ void rpc_execute(struct rpc_task *task)
 
 static void rpc_async_schedule(struct work_struct *work)
 {
-   current->flags |= PF_FSTRANS;
__rpc_execute(container_of(work, struct rpc_task, u.tk_work));
-   current->flags &= ~PF_FSTRANS;
 }
 
 /**
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 2faac4940563..6a4615dd0261 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -205,7 +205,6 @@ xprt_rdma_connect_worker(struct work_struct *work)
struct rpc_xprt *xprt = _xprt->xprt;
int rc = 0;
 
-   current->flags |= PF_FSTRANS;
xprt_clear_connected(xprt);
 
dprintk("RPC:   %s: %sconnect\n", __func__,
@@ -216,7 +215,6 @@ xprt_rdma_connect_worker(struct work_struct *work)
 
dprintk("RPC:   %s: exit\n", __func__);
xprt_clear_connecting(xprt);
-   current->flags &= ~PF_FSTRANS;
 }
 
 /*
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 43cd89eacfab..4707c0c8568b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1927,8 +1927,6 @@ static int xs_local_setup_socket(struct sock_xprt 
*transport)
struct socket *sock;
int status = -EIO;
 
-   current->flags |= PF_FSTRANS;
-
clear_bit(XPRT_CONNECTION_ABORT, >state);
status = __sock_create(xprt->xprt_net, AF_LOCAL,
SOCK_STREAM, 0, , 1);
@@ -1968,7 +1966,6 @@ static int xs_local_setup_socket(struct sock_xprt 
*transport)
 out:
xprt_clear_connecting(xprt);
xprt_wake_pending_tasks(xprt, status);
-   current->flags &= ~PF_FSTRANS;
return status;
 }
 
@@ -2071,8 +2068,6 @@ static void xs_udp_setup_socket(struct work_struct *work)
struct socket *sock = transport->sock;
int status = -EIO;
 
-   current->flags |= PF_FSTRANS;
-
/* Start by resetting any existing state */
xs_reset_transport(transport);
sock = xs_create_sock(xprt, transport,
@@ -2092,7 +2087,6 @@ static void xs_udp_setup_socket(struct work_struct *work)
 out:
xprt_clear_connecting(xprt);
xprt_wake_pending_tasks(xprt, status);
-   current->flags &= ~PF_FSTRANS;
 }
 
 /*
@@ -2229,8 +2223,6 @@ static void xs_tcp_setup_socket(struct work_struct *work)
struct rpc_xprt *xprt = >xprt;
int status = -EIO;
 
-   current->flags |= 

[PATCH 2/4] MM: export page_wakeup functions

[NeilBrown]

This will allow NFS to wait for PG_private to be cleared and,
particularly, to send a wake-up when it is.

Signed-off-by: NeilBrown 
---
 include/linux/pagemap.h |   10 --
 mm/filemap.c|8 ++--
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 87f9e4230d3a..2dca0cef3506 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -496,8 +496,8 @@ static inline int lock_page_or_retry(struct page *page, 
struct mm_struct *mm,
 }
 
 /*
- * This is exported only for wait_on_page_locked/wait_on_page_writeback.
- * Never use this directly!
+ * This is exported only for wait_on_page_locked/wait_on_page_writeback,
+ * and for filesystems which need to wait on PG_private.
  */
 extern void wait_on_page_bit(struct page *page, int bit_nr);
 
@@ -512,6 +512,12 @@ static inline int wait_on_page_locked_killable(struct page 
*page)
return 0;
 }
 
+extern wait_queue_head_t *page_waitqueue(struct page *page);
+static inline void wake_up_page(struct page *page, int bit)
+{
+   __wake_up_bit(page_waitqueue(page), >flags, bit);
+}
+
 /* 
  * Wait for a page to be unlocked.
  *
diff --git a/mm/filemap.c b/mm/filemap.c
index 4a19c084bdb1..c9ba09f2ad3c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -670,17 +670,13 @@ EXPORT_SYMBOL(__page_cache_alloc);
  * at a cost of "thundering herd" phenomena during rare hash
  * collisions.
  */
-static wait_queue_head_t *page_waitqueue(struct page *page)
+wait_queue_head_t *page_waitqueue(struct page *page)
 {
const struct zone *zone = page_zone(page);
 
return >wait_table[hash_ptr(page, zone->wait_table_bits)];
 }
-
-static inline void wake_up_page(struct page *page, int bit)
-{
-   __wake_up_bit(page_waitqueue(page), >flags, bit);
-}
+EXPORT_SYMBOL(page_waitqueue);
 
 void wait_on_page_bit(struct page *page, int bit_nr)
 {


--
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/4] SCHED: add some "wait..on_bit...timeout()" interfaces.

[NeilBrown]

In commit c1221321b7c25b53204447cff9949a6d5a7c
   sched: Allow wait_on_bit_action() functions to support a timeout

I suggested that a "wait_on_bit_timeout()" interface would not meet my
need.  This isn't true - I was just over-engineering.

Including a 'private' field in wait_bit_key instead of a focused
"timeout" field was just premature generalization.  If some other
use is ever found, it can be generalized or added later.

So this patch renames "private" to "timeout" with a meaning "stop
waiting when "jiffies" reaches or passes "timeout",
and adds two of the many possible wait..bit..timeout() interfaces:

wait_on_page_bit_killable_timeout(), which is the one I want to use,
and out_of_line_wait_on_bit_timeout() which is a reasonably general
example.  Others can be added as needed.

Signed-off-by: NeilBrown 
---
 include/linux/pagemap.h |2 ++
 include/linux/wait.h|5 -
 kernel/sched/wait.c |   36 
 mm/filemap.c|   13 +
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 3df8c7db7a4e..87f9e4230d3a 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -502,6 +502,8 @@ static inline int lock_page_or_retry(struct page *page, 
struct mm_struct *mm,
 extern void wait_on_page_bit(struct page *page, int bit_nr);
 
 extern int wait_on_page_bit_killable(struct page *page, int bit_nr);
+extern int wait_on_page_bit_killable_timeout(struct page *page,
+int bit_nr, unsigned long timeout);
 
 static inline int wait_on_page_locked_killable(struct page *page)
 {
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 6fb1ba5f9b2f..80115bf88671 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -25,7 +25,7 @@ struct wait_bit_key {
void*flags;
int bit_nr;
 #define WAIT_ATOMIC_T_BIT_NR   -1
-   unsigned long   private;
+   unsigned long   timeout;
 };
 
 struct wait_bit_queue {
@@ -154,6 +154,7 @@ int __wait_on_bit_lock(wait_queue_head_t *, struct 
wait_bit_queue *, wait_bit_ac
 void wake_up_bit(void *, int);
 void wake_up_atomic_t(atomic_t *);
 int out_of_line_wait_on_bit(void *, int, wait_bit_action_f *, unsigned);
+int out_of_line_wait_on_bit_timeout(void *, int, wait_bit_action_f *, 
unsigned, unsigned long);
 int out_of_line_wait_on_bit_lock(void *, int, wait_bit_action_f *, unsigned);
 int out_of_line_wait_on_atomic_t(atomic_t *, int (*)(atomic_t *), unsigned);
 wait_queue_head_t *bit_waitqueue(void *, int);
@@ -859,6 +860,8 @@ int wake_bit_function(wait_queue_t *wait, unsigned mode, 
int sync, void *key);
 
 extern int bit_wait(struct wait_bit_key *);
 extern int bit_wait_io(struct wait_bit_key *);
+extern int bit_wait_timeout(struct wait_bit_key *);
+extern int bit_wait_io_timeout(struct wait_bit_key *);
 
 /**
  * wait_on_bit - wait for a bit to be cleared
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index 15cab1a4f84e..380678b3cba4 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -343,6 +343,18 @@ int __sched out_of_line_wait_on_bit(void *word, int bit,
 }
 EXPORT_SYMBOL(out_of_line_wait_on_bit);
 
+int __sched out_of_line_wait_on_bit_timeout(
+   void *word, int bit, wait_bit_action_f *action,
+   unsigned mode, unsigned long timeout)
+{
+   wait_queue_head_t *wq = bit_waitqueue(word, bit);
+   DEFINE_WAIT_BIT(wait, word, bit);
+
+   wait.key.timeout = jiffies + timeout;
+   return __wait_on_bit(wq, , action, mode);
+}
+EXPORT_SYMBOL(out_of_line_wait_on_bit_timeout);
+
 int __sched
 __wait_on_bit_lock(wait_queue_head_t *wq, struct wait_bit_queue *q,
wait_bit_action_f *action, unsigned mode)
@@ -520,3 +532,27 @@ __sched int bit_wait_io(struct wait_bit_key *word)
return 0;
 }
 EXPORT_SYMBOL(bit_wait_io);
+
+__sched int bit_wait_timeout(struct wait_bit_key *word)
+{
+   unsigned long now = ACCESS_ONCE(jiffies);
+   if (signal_pending_state(current->state, current))
+   return 1;
+   if (time_after_eq(now, word->timeout))
+   return -EAGAIN;
+   schedule_timeout(word->timeout - now);
+   return 0;
+}
+EXPORT_SYMBOL(bit_wait_timeout);
+
+__sched int bit_wait_io_timeout(struct wait_bit_key *word)
+{
+   unsigned long now = ACCESS_ONCE(jiffies);
+   if (signal_pending_state(current->state, current))
+   return 1;
+   if (time_after_eq(now, word->timeout))
+   return -EAGAIN;
+   io_schedule_timeout(word->timeout - now);
+   return 0;
+}
+EXPORT_SYMBOL(bit_wait_io_timeout);
diff --git a/mm/filemap.c b/mm/filemap.c
index 90effcdf948d..4a19c084bdb1 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -703,6 +703,19 @@ int wait_on_page_bit_killable(struct page *page, int 
bit_nr)
 bit_wait_io, TASK_KILLABLE);
 }
 
+int 

[PATCH 3/4] NFS: avoid deadlocks with loop-back mounted NFS filesystems.

[NeilBrown]

Support for loop-back mounted NFS filesystems is useful when NFS is
used to access shared storage in a high-availability cluster.

If the node running the NFS server fails, some other node can mount the
filesystem and start providing NFS service.  If that node already had
the filesystem NFS mounted, it will now have it loop-back mounted.

nfsd can suffer a deadlock when allocating memory and entering direct
reclaim.
While direct reclaim does not write to the NFS filesystem it can send
and wait for a COMMIT through nfs_release_page().

This patch modifies nfs_release_page() to wait a limited time for the
commit to complete - one second.  If the commit doesn't complete
in this time, nfs_release_page() will fail.  This means it might now
fail in some cases where it wouldn't before.  These cases are only
when 'gfp' includes '__GFP_WAIT'.

nfs_release_page() is only called by try_to_release_page(), and that
can only be called on an NFS page with required 'gfp' flags from
 - page_cache_pipe_buf_steal() in splice.c
 - shrink_page_list() in vmscan.c
 - invalidate_inode_pages2_range() in truncate.c

The first two handle failure quite safely.  The last is only called
after ->launder_page() has been called, and that will have waited
for the commit to finish already.

So aborting if the commit takes longer than 1 second is perfectly safe.

1 second may be longer than is really necessary, but it is much
shorter than the current maximum wait, so this is not a regression.
Some waiting is needed to help slow down memory allocation to the
rate that we can complete writeout of pages.

In those rare cases where it is nfsd, or something that nfsd is
waiting for, that is calling nfs_release_page(), this delay will at
most cause a small hic-cough in places where it currently deadlocks.

Signed-off-by: NeilBrown 
---
 fs/nfs/file.c  |   24 ++--
 fs/nfs/write.c |2 ++
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 524dd80d1898..8d74983417af 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -468,17 +468,21 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
 
dfprintk(PAGECACHE, "NFS: release_page(%p)\n", page);
 
-   /* Only do I/O if gfp is a superset of GFP_KERNEL, and we're not
-* doing this memory reclaim for a fs-related allocation.
+   /* Always try to initiate a 'commit' if relevant, but only
+* wait for it if __GFP_WAIT is set and the calling process is
+* allowed to block.  Even then, only wait 1 second.  Waiting
+* indefinitely can cause deadlocks when the NFS server is on
+* this machine, and there is no particular need to wait
+* extensively here.  A short wait has the benefit that
+* someone else can worry about the freezer.
 */
-   if (mapping && (gfp & GFP_KERNEL) == GFP_KERNEL &&
-   !(current->flags & PF_FSTRANS)) {
-   int how = FLUSH_SYNC;
-
-   /* Don't let kswapd deadlock waiting for OOM RPC calls */
-   if (current_is_kswapd())
-   how = 0;
-   nfs_commit_inode(mapping->host, how);
+   if (mapping) {
+   nfs_commit_inode(mapping->host, 0);
+   if ((gfp & __GFP_WAIT) &&
+   !current_is_kswapd() &&
+   !(current->flags & PF_FSTRANS))
+   wait_on_page_bit_killable_timeout(page, PG_private,
+ HZ);
}
/* If PagePrivate() is set, then the page is not freeable */
if (PagePrivate(page))
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 175d5d073ccf..b5d83c7545d4 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -731,6 +731,8 @@ static void nfs_inode_remove_request(struct nfs_page *req)
if (likely(!PageSwapCache(head->wb_page))) {
set_page_private(head->wb_page, 0);
ClearPagePrivate(head->wb_page);
+   smp_mb__after_atomic();
+   wake_up_page(head->wb_page, PG_private);
clear_bit(PG_MAPPED, >wb_flags);
}
nfsi->npages--;


--
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/4] Remove possible deadlocks in nfs_release_page()

[NeilBrown]

Because nfs_release_page() submits a 'COMMIT' nfs request and waits
for it to complete, and does this during memory reclaim, it is
susceptible to deadlocks if memory allocation happens anywhere in
sending the COMMIT message.  If the NFS server is on the same host
(i.e. loop-back NFS), then any memory allocations in the NFS server
can also cause deadlocks.

nfs_release_page() already has some code to avoid deadlocks in some
circumstances, but these are not sufficient for loopback NFS.

This patch set changes the approach to deadlock avoidance.  Rather
than detecting cases that could deadlock and avoiding the COMMIT, it
always tries the COMMIT, but only waits a short time (1 second).
This avoid any deadlock possibility at the expense of not waiting
longer than 1 second even if no deadlock is pending.

nfs_release_page() does not *need* to wait longer - all callers that
matter handle a failure gracefully - they move on to other pages.

This set:
 - adds some "_timeout()" functions to "wait_on_bit".  Only a
   wait_on_page version is actually used.
 - exports page wake_up support.  NFS knows that the COMMIT is complete
   when PG_private is clear.  So nfs_release_page will use
   wait_on_page_bit_killable_timeout to wait for the bit to clear,
   and needs access to wake_up_page()
 - changes nfs_release_page() to use
wait_on_page_bit_killable_timeout()
 - removes the other deadlock avoidance mechanisms from
   nfs_release_page, so that PF_FSTRANS is again only used
   by XFS.

As such, it needs buy-in from sched people, mm people, and NFS people.
Assuming I get that buy-in, suggests for how these patches can flow
into mainline would be appreciated ... I daren't hope they can all go
in through one tree

Thanks,
NeilBrown


---

NeilBrown (4):
  SCHED: add some "wait..on_bit...timeout()" interfaces.
  MM: export page_wakeup functions
  NFS: avoid deadlocks with loop-back mounted NFS filesystems.
  NFS/SUNRPC: Remove other deadlock-avoidance mechanisms in 
nfs_release_page()


 fs/nfs/file.c   |   22 --
 fs/nfs/write.c  |2 ++
 include/linux/pagemap.h |   12 ++--
 include/linux/wait.h|5 -
 kernel/sched/wait.c |   36 
 mm/filemap.c|   21 +++--
 net/sunrpc/sched.c  |2 --
 net/sunrpc/xprtrdma/transport.c |2 --
 net/sunrpc/xprtsock.c   |   10 --
 9 files changed, 79 insertions(+), 33 deletions(-)

-- 
Signature

--
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 02/17] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Zheng, Lv]

Hi,

> From: Grant Likely [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely
> Sent: Thursday, September 11, 2014 5:52 AM
> 
> On Wed, 10 Sep 2014 13:33:52 +0100, Catalin Marinas  
> wrote:
> > On Wed, Sep 10, 2014 at 12:13:51PM +0100, Hanjun Guo wrote:
> > > On 2014/9/10 3:06, Jon Masters wrote:
> > > > On 09/09/2014 02:05 PM, Sudeep Holla wrote:
> > > >> On 09/09/14 18:50, Lorenzo Pieralisi wrote:
> > > >>> On Tue, Sep 09, 2014 at 06:15:41PM +0100, Mark Rutland wrote:
> > >  On Tue, Sep 09, 2014 at 05:41:51PM +0100, Jon Masters wrote:
> > > > On 09/09/2014 12:26 PM, Catalin Marinas wrote:
> > > >> On Mon, Sep 01, 2014 at 03:57:40PM +0100, Hanjun Guo wrote:
> > > >>> diff --git a/arch/arm64/include/asm/acenv.h 
> > > >>> b/arch/arm64/include/asm/acenv.h
> > > >>> new file mode 100644
> > > >>> index 000..3899ee6
> > > >>> --- /dev/null
> > > >>> +++ b/arch/arm64/include/asm/acenv.h
> > > >>> @@ -0,0 +1,18 @@
> > > >>> +/*
> > > >>> + * ARM64 specific ACPICA environments and implementation
> > > >>> + *
> > > >>> + * Copyright (C) 2014, Linaro Ltd.
> > > >>> + *   Author: Hanjun Guo 
> > > >>> + *   Author: Graeme Gregory 
> > > >>> + *
> > > >>> + * 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.
> > > >>> + */
> > > >>> +
> > > >>> +#ifndef _ASM_ACENV_H
> > > >>> +#define _ASM_ACENV_H
> > > >>> +
> > > >>> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently 
> > > >>> supported on ARM64")
> > > >>
> > > >> Does this mean that it will be supported at some point? Looking at 
> > > >> the
> > > >> places where this function is called, I don't really see how this 
> > > >> would
> > > >> ever work on ARM. Which means that we add such macro just to be 
> > > >> able to
> > > >> compile code that would never be used on arm64. I would rather see 
> > > >> the
> > > >> relevant ACPI files only compiled on x86/IA-64 rather than arm64.
> > > >
> > > > That specific cache behavior is a part of e.g. ACPI C3 state support
> > > > (e.g. ACPI5.1 8.1.4 Processor Power State C3).
> > > 
> > >  Per table 5-35, if neither WBINVD or WBINVD_FLUSH are set in the 
> > >  FADT,
> > >  we don't get S1, S2, or S3 states either.
> > > 
> > > > As you note, it's not going to work on 64-bit ARM as it does on x86,
> > > > but it's optional to implement C3 and early 64-bit ARM systems 
> > > > should
> > > > not report Wbindv flags in the FADT anyway.
> > > 
> > >  Unless the arm cache architecture changes, I wouldn't expect any 
> > >  64-bit
> > >  ARM system to set either of the WBINVD flags.
> > > 
> > > > They can also set FADT.P_LVL3_LAT > 1000, which has the effect of
> > > > disabling C3 support, while also allowing for use of _CST objects to
> > > > define more flexible C-States later on.
> > > 
> > >  It sounds like we should be sanity checking these in the arm64 ACPI 
> > >  code
> > >  for the moment. I don't want us to discover that current platforms
> > >  report the wrong thing only when new platforms come out that might
> > >  actually report things correctly.
> > > >>>
> > > >>> I think that the kernel must ignore most of the stuff mentioned above
> > > >>> in HW_REDUCED_ACPI mode. And to be frank I still think that the 
> > > >>> problem
> > > >>> is not even there. The problem is trying to compile code that 
> > > >>> basically
> > > >>> has no defined behaviour - ie it is unspecified - on ARM64, that's 
> > > >>> what
> > > >>> Catalin pointed out.
> > > >>>
> > > >>> I understand it is compiled in by default on x86, but that's not a 
> > > >>> reason
> > > >>> why we should add empty hooks all over the place to compile code that
> > > >>> does not stand a chance to be doing anything sensible apart from
> > > >>> returning an error code, in the best case scenario.
> > > >>>
> > > >>
> > > >> I had pointed out this earlier, even if we make it compile there's
> > > >> every possibility that it can blow up if some vendor adds S- states
> > > >> to their ACPI tables. One clear reason why it could blow up is:
> > > >>
> > > >> "
> > > >>   /* This violates the spec but is required for bug compatibility. 
> > > >> */
> > > >>   acpi_write_bit_register(ACPI_BITREG_SCI_ENABLE, 1);
> > > >> "
> > > >>
> > > >> I don't think this can ever work on ARM platforms. So better to fix it
> > > >> properly.
> >
> > Agree.
> >
> > > > How do you want to proceed? I'm not sure it should be !HW_REDUCED_MODE
> > > > for the cache behavior, because an embedded x86 box would still probably
> > > > define those, but removing the hooks on ARM may make sense.
> > >
> > > As Graeme said 

[PATCH v3] tty: serial: men_z135_uart: Fix driver for changes in hardware

[Johannes Thumshirn]

16z135 IP Core has changed so the driver needs to be updated to respect
these changes. The following changes have been made:

* Don't invert the 16z135 modem status register when reading.
* Add module parameter to configure the (baud rate dependent) RX timeout.
  Character timeout in seconds = (timeout_reg * baud_reg * 4)/freq_reg.
* Enable the handling of UART core's automatic flow control feature.
  When AFE is active disable generation of modem status IRQs.
* Rework the handling of IRQs to be conform with newer FPGA versions and
  take precautions not to miss an interrupt because of the destructive read
  of the IIR register.
* Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not
  stat_reg[7:0]

Signed-off-by: Johannes Thumshirn 
---
Changes to v1:
Incorporated comments of Jiri Slaby:

* Timeout value is documented in module parameter description
* rx_timeout variable is uint
* Changed IRQ handled variable to bool
* Changed if statement for RDA or CTI IRQ

Changes to v2:
Correct men_z135_handle_modem_status(), MSR is stat_reg[15:8] not stat_reg[7:0]


 drivers/tty/serial/men_z135_uart.c | 98 +++---
 1 file changed, 60 insertions(+), 38 deletions(-)

diff --git a/drivers/tty/serial/men_z135_uart.c 
b/drivers/tty/serial/men_z135_uart.c
index 30e9e60..29fee69 100644
--- a/drivers/tty/serial/men_z135_uart.c
+++ b/drivers/tty/serial/men_z135_uart.c
@@ -34,12 +34,11 @@
 #define MEN_Z135_CONF_REG  0x808
 #define MEN_Z135_UART_FREQ 0x80c
 #define MEN_Z135_BAUD_REG  0x810
-#define MENZ135_TIMEOUT0x814
+#define MEN_Z135_TIMEOUT   0x814

 #define MEN_Z135_MEM_SIZE  0x818

-#define IS_IRQ(x) ((x) & 1)
-#define IRQ_ID(x) (((x) >> 1) & 7)
+#define IRQ_ID(x) ((x) & 0x1f)

 #define MEN_Z135_IER_RXCIEN BIT(0) /* RX Space IRQ */
 #define MEN_Z135_IER_TXCIEN BIT(1) /* TX Space IRQ */
@@ -94,11 +93,11 @@
 #define MEN_Z135_LSR_TEXP BIT(6)
 #define MEN_Z135_LSR_RXFIFOERR BIT(7)

-#define MEN_Z135_IRQ_ID_MST 0
-#define MEN_Z135_IRQ_ID_TSA 1
-#define MEN_Z135_IRQ_ID_RDA 2
-#define MEN_Z135_IRQ_ID_RLS 3
-#define MEN_Z135_IRQ_ID_CTI 6
+#define MEN_Z135_IRQ_ID_RLS BIT(0)
+#define MEN_Z135_IRQ_ID_RDA BIT(1)
+#define MEN_Z135_IRQ_ID_CTI BIT(2)
+#define MEN_Z135_IRQ_ID_TSA BIT(3)
+#define MEN_Z135_IRQ_ID_MST BIT(4)

 #define LCR(x) (((x) >> MEN_Z135_LCR_SHIFT) & 0xff)

@@ -118,6 +117,11 @@ static int align;
 module_param(align, int, S_IRUGO);
 MODULE_PARM_DESC(align, "Keep hardware FIFO write pointer aligned, default 0");

+static uint rx_timeout;
+module_param(rx_timeout, uint, S_IRUGO);
+MODULE_PARM_DESC(rx_timeout, "RX timeout. "
+   "Timeout in seconds = (timeout_reg * baud_reg * 4) / freq_reg");
+
 struct men_z135_port {
struct uart_port port;
struct mcb_device *mdev;
@@ -180,12 +184,14 @@ static inline void men_z135_reg_clr(struct men_z135_port 
*uart,
  */
 static void men_z135_handle_modem_status(struct men_z135_port *uart)
 {
-   if (uart->stat_reg & MEN_Z135_MSR_DDCD)
+   u8 msr = (uart->stat_reg >> 8) & 0xff;
+
+   if (msr & MEN_Z135_MSR_DDCD)
uart_handle_dcd_change(>port,
-   uart->stat_reg & ~MEN_Z135_MSR_DCD);
-   if (uart->stat_reg & MEN_Z135_MSR_DCTS)
+   msr & ~MEN_Z135_MSR_DCD);
+   if (msr & MEN_Z135_MSR_DCTS)
uart_handle_cts_change(>port,
-   uart->stat_reg & ~MEN_Z135_MSR_CTS);
+   msr & ~MEN_Z135_MSR_CTS);
 }

 static void men_z135_handle_lsr(struct men_z135_port *uart)
@@ -373,43 +379,47 @@ out:
  * @irq: The IRQ number
  * @data: Pointer to UART port
  *
- * Check IIR register to see which tasklet to start.
+ * Check IIR register to find the cause of the interrupt and handle it.
+ * It is possible that multiple interrupts reason bits are set and reading
+ * the IIR is a destructive read, so we always need to check for all possible
+ * interrupts and handle them.
  */
 static irqreturn_t men_z135_intr(int irq, void *data)
 {
struct men_z135_port *uart = (struct men_z135_port *)data;
struct uart_port *port = >port;
+   bool handled = false;
int irq_id;

uart->stat_reg = ioread32(port->membase + MEN_Z135_STAT_REG);
-   /* IRQ pending is low active */
-   if (IS_IRQ(uart->stat_reg))
-   return IRQ_NONE;
-
irq_id = IRQ_ID(uart->stat_reg);
-   switch (irq_id) {
-   case MEN_Z135_IRQ_ID_MST:
-   men_z135_handle_modem_status(uart);
-   break;
-   case MEN_Z135_IRQ_ID_TSA:
-   men_z135_handle_tx(uart);
-   break;
-   case MEN_Z135_IRQ_ID_CTI:
-   dev_dbg(>mdev->dev, "Character Timeout Indication\n");
-   /* Fallthrough */
-   case MEN_Z135_IRQ_ID_RDA:
-   /* Reading data clears RX IRQ */
-   

[RFC resend] arm:change keep_initrd and free_initrd_mem into .init section

[Wang, Yalin]

this patch change keep_initrd to __initdata section,
and free_initrd_mem to __init section so that they can be freed by
free_initmem, free_initrd_mem is only called by free_initrd function,
so it's safe to free it after use.

Signed-off-by: Yalin Wang 
---
 arch/arm/mm/init.c   | 4 ++--
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..907dee1 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -631,9 +631,9 @@ void free_initmem(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
-static int keep_initrd;
+static int __initdata keep_initrd;
 
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..7268d57 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -330,9 +330,9 @@ void free_initmem(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
-static int keep_initrd;
+static int __initdata keep_initrd;
 
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd)
free_reserved_area((void *)start, (void *)end, 0, "initrd");
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 103/114] CIFS: Fix directory rename error

[Pavel Shilovsky]

2014-09-15 23:26 GMT+04:00 Greg Kroah-Hartman :
> 3.14-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Pavel Shilovsky 
>
> commit a07d322059db66b84c9eb4f98959df468e88b34b upstream.
>
> CIFS servers process nlink counts differently for files and directories.
> In cifs_rename() if we the request fails on the existing target, we
> try to remove it through cifs_unlink() but this is not what we want
> to do for directories. As the result the following sequence of commands
>
> mkdir {1,2}; mv -T 1 2; rmdir {1,2}; mkdir {1,2}; echo foo > 2/bar
>
> and XFS test generic/023 fail with -ENOENT error. That's why the second
> mkdir reuses the existing inode (target inode of the mv -T command) with
> S_DEAD flag.
>
> Fix this by checking whether the target is directory or not and
> calling cifs_rmdir() rather than cifs_unlink() for directories.
>
> Signed-off-by: Pavel Shilovsky 
> Signed-off-by: Steve French 
> Signed-off-by: Greg Kroah-Hartman 
>
> ---
>  fs/cifs/inode.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1706,7 +1706,10 @@ cifs_rename(struct inode *source_dir, st
>  unlink_target:
> /* Try unlinking the target dentry if it's not negative */
> if (target_dentry->d_inode && (rc == -EACCES || rc == -EEXIST)) {
> -   tmprc = cifs_unlink(target_dir, target_dentry);
> +   if (d_is_dir(target_dentry))
> +   tmprc = cifs_rmdir(target_dir, target_dentry);
> +   else
> +   tmprc = cifs_unlink(target_dir, target_dentry);
> if (tmprc)
> goto cifs_rename_exit;
> rc = cifs_do_rename(xid, source_dentry, from_name,
>
>

Does the next stable-3.14.y have d_is_dir()? v3.14.18 doesn't compile this one.

-- 
Best regards,
Pavel Shilovsky.
--
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] usb: gadget: udc_core: Use right kobj when calling sysfs_notify

[Felipe Balbi]

Hi,

On Tue, Sep 16, 2014 at 10:02:25AM +0800, Peter Chen wrote:
> On Mon, Sep 15, 2014 at 12:42:27PM +0200, Andreas Larsson wrote:
> > The state attribute is connected to the kobj of the udc, not the gadget.
> > 
> > Signed-off-by: Andreas Larsson 
> > ---
> >  drivers/usb/gadget/udc/udc-core.c |   14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/gadget/udc/udc-core.c 
> > b/drivers/usb/gadget/udc/udc-core.c
> > index b0d9817..37c129a 100644
> > --- a/drivers/usb/gadget/udc/udc-core.c
> > +++ b/drivers/usb/gadget/udc/udc-core.c
> > @@ -109,8 +109,20 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
> >  static void usb_gadget_state_work(struct work_struct *work)
> >  {
> > struct usb_gadget   *gadget = work_to_gadget(work);
> > +   struct usb_udc  *udc = NULL;
> > +
> > +   mutex_lock(_lock);
> > +   list_for_each_entry(udc, _list, list)
> > +   if (udc->gadget == gadget)
> > +   goto found;
> > +   mutex_unlock(_lock);
> > +
> > +   return;
> > +
> > +found:
> > +   mutex_unlock(_lock);
> >  
> > -   sysfs_notify(>dev.kobj, NULL, "state");
> > +   sysfs_notify(>dev.kobj, NULL, "state");
> >  }
> >  
> >  void usb_gadget_set_state(struct usb_gadget *gadget,
> 
> What's the user mode difference with and without this patch?

poll() will actually wakeup ?

-- 
balbi


signature.asc
Description: Digital signature

[RFC] change keep_initrd and free_initrd_mem into .init section

[Wang, Yalin]

this patch change keep_initrd to __initdata section,
and free_initrd_mem to __init section so that they can be freed by
free_initmem, free_initrd_mem is only called by free_initrd function,
so it's safe to free it after use.

Signed-off-by: Yalin Wang 
---
 arch/arm/mm/init.c   | 4 ++--
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..907dee1 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -631,9 +631,9 @@ void free_initmem(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
-static int keep_initrd;
+static int __initdata keep_initrd;
 
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..7268d57 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -330,9 +330,9 @@ void free_initmem(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
-static int keep_initrd;
+static int __initdata keep_initrd;
 
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd)
free_reserved_area((void *)start, (void *)end, 0, "initrd");
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] pci/probe: Enable CRS for root port if it is supported

[Rajat Jain]

Hi Bjorn,

On Mon, Sep 8, 2014 at 10:38 PM, Bjorn Helgaas  wrote:
> On Tue, Sep 02, 2014 at 04:26:00PM -0700, Rajat Jain wrote:
>>
>> As per the PCIe spec, an endpoint may return the configuration cycles
>> with CRS if it is not yet fully ready to be accessed. If the CRS visibility
>> is not enabled at the root port, the spec leaves the retry behaviour open
>> to implementation in such a case. The Intel root ports have chosen to retry
>> endlessly in this situation. Thus, the root controller may "hang" (repeatedly
>> retrying the configuration requests until it gets a status other than CRS) if
>> a device returns CRS for a long time. This can cause a broken endpoint to 
>> bring
>> down the whole PCI hierarchy.
>>
>> This was recently known to cause problems on Intel systems and
>> was discussed here:
>> http://marc.info/?t=14092629852=1=2
>>
>> Ref1:
>> https://www.pcisig.com/specifications/pciexpress/ECN_CRS_Software_Visibility_No27.pdf
>>
>> Ref2:
>> PCIe spec V3.0, pg119, pg127 for "Configuration Request Retry Status"
>>
>> Thus enable the CRS visibility for the root ports that support it. This
>> patch reverts the following commit, but enables CRS visibility only
>> when the root port supports it:
>>
>> ad7edfe04908 ("[PCI] Do not enable CRS Software Visibility by default")
>>
>> (Linus' response: http://marc.info/?l=linux-pci=140968622520192=2)
>>
>> Signed-off-by: Rajat Jain 
>> Signed-off-by: Rajat Jain 
>> Signed-off-by: Guenter Roeck 
>
> I put this and the "only look at Vendor ID" patch on a pci/enumeration
> branch [1].  I rewrote the changelogs to reflect my understanding of what's
> going on, so probably the real truth is somewhere between your original and
> mine.  Let me know what should be fixed.
>
> We should figure out an easy way for Josh to test these.  Ideally, he could
> test the second patch by itself first, then both together.

OK, Josh and I tested this over the last week on his HW (the HW that
had originally reported the problem). Somehow his hardware does not
show the problem in ANY case. I tried the following, and the original
issue (vendor id = 1) was never seen:

1) 3.17-rc2 (has CRS disabled)
2) 3.17-rc2 + Enable CRS
3) 3.17-rc2 + Enable CRS + Ignore Device ID

The Device always returned the correct Vendor ID and Device ID in all
cases. Thus even enabling CRS does not make his system fail in anyway.

Thanks,

Rajat


>
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/enumeration
>
>> ---
>> v2: Remove the white list, that was enabling the CRS for certain known Intel 
>> systems.
>> Rather now enable it for all systems that support this capability.
>> v1: Enable CRS for only some given Intel systems (maintain a whitelist)
>>
>>  drivers/pci/probe.c   |   13 +
>>  include/uapi/linux/pci_regs.h |1 +
>>  2 files changed, 14 insertions(+)
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index e3cf8a2..3c4c35c 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -740,6 +740,17 @@ struct pci_bus *pci_add_new_bus(struct pci_bus *parent, 
>> struct pci_dev *dev,
>>  }
>>  EXPORT_SYMBOL(pci_add_new_bus);
>>
>> +static void pci_enable_crs(struct pci_dev *pdev)
>> +{
>> + u16 root_cap = 0;
>> +
>> + /* Enable CRS Software visibility if supported */
>> + pcie_capability_read_word(pdev, PCI_EXP_RTCAP, _cap);
>> + if (root_cap & PCI_EXP_RTCAP_CRSVIS)
>> + pcie_capability_set_word(pdev, PCI_EXP_RTCTL,
>> +  PCI_EXP_RTCTL_CRSSVE);
>> +}
>> +
>>  /*
>>   * If it's a bridge, configure it and scan the bus behind it.
>>   * For CardBus bridges, we don't scan behind as the devices will
>> @@ -787,6 +798,8 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev 
>> *dev, int max, int pass)
>>   pci_write_config_word(dev, PCI_BRIDGE_CONTROL,
>> bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT);
>>
>> + pci_enable_crs(dev);
>> +
>>   if ((secondary || subordinate) && !pcibios_assign_all_busses() &&
>>   !is_cardbus && !broken) {
>>   unsigned int cmax;
>> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
>> index 30db069..a75106d 100644
>> --- a/include/uapi/linux/pci_regs.h
>> +++ b/include/uapi/linux/pci_regs.h
>> @@ -552,6 +552,7 @@
>>  #define  PCI_EXP_RTCTL_PMEIE 0x0008  /* PME Interrupt Enable */
>>  #define  PCI_EXP_RTCTL_CRSSVE0x0010  /* CRS Software Visibility 
>> Enable */
>>  #define PCI_EXP_RTCAP30  /* Root Capabilities */
>> +#define  PCI_EXP_RTCAP_CRSVIS0x0001  /* CRS software visibility 
>> capability */
>>  #define PCI_EXP_RTSTA32  /* Root Status */
>>  #define PCI_EXP_RTSTA_PME0x0001 /* PME status */
>>  #define PCI_EXP_RTSTA_PENDING0x0002 /* PME pending */
>> --
>> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH v2 0/7] mtd: denali: A collection of trivial coding style fixes

[Brian Norris]

Hi Masahiro,

On Tue, Sep 16, 2014 at 11:11:58AM +0900, Masahiro Yamada wrote:
> On Mon, 15 Sep 2014 17:36:20 -0700 Brian Norris  
> wrote:
> > On Tue, Sep 09, 2014 at 11:01:50AM +0900, Masahiro Yamada wrote:
> > > Changes in v2:
> > >   - Join quotes strings into a single line
> > > 
> > > Masahiro Yamada (7):
> > >   mtd: denali: fix the format of comment blocks
> > >   mtd: denali: remove unnecessary variable initializations
> > >   mtd: denali: remove unnecessary casts
> > >   mtd: denali: change the type of iterators to int
> > >   mtd: denali: remove a set-but-unused variable
> > >   mtd: denali: remove unnecessary parentheses
> > >   mtd: denali: fix indents and other trivial things
> > > 
> > >  drivers/mtd/nand/denali.c | 562 
> > > +-
> > >  1 file changed, 303 insertions(+), 259 deletions(-)
> > 
> > Pushed patches 1 to 5 to l2-mtd.git. Thanks!
> > 
> > Patch 6 has a conflict with another fix already in l2-mtd.git. Can you
> > rebase and resend?
> 
> Sorry for my ignorance, but where can I find l2-mtd.git?

git://git.infradead.org/l2-mtd.git

> In my understanding, the subsystem repositories should be documented
> in MAINTAINERS, so I looked for it but just found
> T:git git://git.infradead.org/linux-mtd.git.
> I do not think it is the one you mentioned.

Sorry, apparently l2-mtd.git is not in MAINTAINERS. It historically has
been a kind of queue for the official repo (linux-mtd.git), especially
when work was split up between two people. I handle most of it now.

I guess it should be in MAINTAINERS, though, since most people will need
to base patches on it. I just sent a patch to add it.

> > BTW, my automatic build tests show that there's at least one other
> > 'unused' warning left, in case you want to tackle it too:
> > 
> > drivers/mtd/nand/denali.c: In function ‘denali_read_page_raw’:
> > drivers/mtd/nand/denali.c:1221:11: warning: variable ‘irq_status’ set 
> > but not used [-Wunused-but-set-variable]
> >   uint32_t irq_status;
> > 
> 
> You are right.
> (What is odd enough is this warning was not displayed on my build test.
> I do not know why.)

I enabled extra warnings. I think you can get most of those with 'make
W=1'.

> Is there a chance for me to resend 5/7 to include this fix?
> Or is it too late?

Just send a new patch, please.

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

[PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

[Vivek Gautam]

Currently the DP_PHY_ENABLE register is mapped in the driver,
and accessed to control power to the PHY.
With mfd-syscon and regmap interface available at our disposal,
it's wise to use that instead of using a 'reg' property for the
controller and allocating a memory resource for that.

To facilitate this, we have added another compatible string
for Exynso5420 SoC to acquire driver data which contains
different DP-PHY-CONTROL register offset.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Cc: Kishon Vijay Abraham I 
---

Changes since v2:
 - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
   since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.

Changes since v1:
 - state->regs should have been "struct regmap *" instead of
   "void __iomem *". So corrected the same.

 .../devicetree/bindings/phy/samsung-phy.txt|7 +-
 drivers/phy/phy-exynos-dp-video.c  |   79 +---
 2 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 7a6feea..15e0f2c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
 -
 
 Required properties:
-- compatible : should be "samsung,exynos5250-dp-video-phy";
-- reg : offset and length of the Display Port PHY register set;
+- compatible : should be one of the following supported values:
+- "samsung,exynos5250-dp-video-phy"
+- "samsung,exynos5420-dp-video-phy"
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 0;
 
 Samsung S5P/EXYNOS SoC series USB PHY
diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index 8b3026e..53f44a0 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -13,44 +13,55 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
-/* DPTX_PHY_CONTROL register */
-#define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
+struct exynos_dp_video_phy_drvdata {
+   u32 phy_ctrl_offset;
+};
 
 struct exynos_dp_video_phy {
-   void __iomem *regs;
+   struct regmap *regs;
+   const struct exynos_dp_video_phy_drvdata *drvdata;
 };
 
-static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
+   unsigned int on)
 {
-   u32 reg;
+   unsigned int val;
+
+   if (IS_ERR(state->regs))
+   return;
 
-   reg = readl(state->regs);
-   if (on)
-   reg |= EXYNOS_DPTX_PHY_ENABLE;
-   else
-   reg &= ~EXYNOS_DPTX_PHY_ENABLE;
-   writel(reg, state->regs);
+   val = on ? 0 : EXYNOS5_PHY_ENABLE;
 
-   return 0;
+   regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
+  EXYNOS5_PHY_ENABLE, val);
 }
 
 static int exynos_dp_video_phy_power_on(struct phy *phy)
 {
struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
 
-   return __set_phy_state(state, 1);
+   /* Disable power isolation on DP-PHY */
+   exynos_dp_video_phy_pwr_isol(state, 0);
+
+   return 0;
 }
 
 static int exynos_dp_video_phy_power_off(struct phy *phy)
 {
struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
 
-   return __set_phy_state(state, 0);
+   /* Enable power isolation on DP-PHY */
+   exynos_dp_video_phy_pwr_isol(state, 1);
+
+   return 0;
 }
 
 static struct phy_ops exynos_dp_video_phy_ops = {
@@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
.owner  = THIS_MODULE,
 };
 
+static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
+   .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
+};
+
+static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
+   .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
+};
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+   {
+   .compatible = "samsung,exynos5250-dp-video-phy",
+   .data = _dp_video_phy,
+   }, {
+   .compatible = "samsung,exynos5420-dp-video-phy",
+   .data = _dp_video_phy,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
 static int exynos_dp_video_phy_probe(struct platform_device *pdev)
 {
struct exynos_dp_video_phy *state;
struct device *dev = >dev;
-   struct resource *res;
+   const struct of_device_id *match;
struct phy_provider *phy_provider;

[PATCH] MAINTAINERS: add l2-mtd.git, 'next' tree for MTD

[Brian Norris]

We've been semi-officially queueing patches here for a while, and it's
in linux-next, so let's advertise it in MAINTAINERS.

Signed-off-by: Brian Norris 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 809ecd680d88..55a61f242991 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5898,6 +5898,7 @@ L:linux-...@lists.infradead.org
 W: http://www.linux-mtd.infradead.org/
 Q: http://patchwork.ozlabs.org/project/linux-mtd/list/
 T: git git://git.infradead.org/linux-mtd.git
+T: git git://git.infradead.org/l2-mtd.git
 S: Maintained
 F: drivers/mtd/
 F: include/linux/mtd/
-- 
1.9.1

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

Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs

[Scott Wood]

On Mon, 2014-09-15 at 18:44 -0500, Kim Phillips wrote:
> On Thu, 11 Sep 2014 12:34:21 -0500
> "J. German Rivera"  wrote:
> 
> > +int mc_get_version(struct fsl_mc_io *mc_io, struct mc_version *mc_ver_info)
> > +{
> > +   struct mc_command cmd = { 0 };
> 
> we can save some cycles if this initialization is not absolutely
> necessary: is it?  i.e., does the h/w actually look at the params
> section when doing a get_version?  not sure to what other commands
> this comment would apply to...at least get_container_id, but maybe
> more - all of them?

Do you really want to open that can of worms, much less to speed up
something that doesn't look performance critical?  Have fun debugging it
if it turns out the hardware does look at something you didn't
initialize.

> > diff --git a/drivers/bus/fsl-mc/fsl_mc_sys.c 
> > b/drivers/bus/fsl-mc/fsl_mc_sys.c
> 
> > +/**
> > + * Map an MC portal in the kernel virtual address space
> > + */
> > +static int map_mc_portal(phys_addr_t mc_portal_phys_addr,
> > +uint32_t mc_portal_size,
> > +void __iomem **new_mc_portal_virt_addr)
> > +{
> > +   void __iomem *mc_portal_virt_addr = NULL;
> > +   struct resource *res = NULL;
> > +   int error = -EINVAL;
> > +
> > +   res =
> > +   request_mem_region(mc_portal_phys_addr, mc_portal_size,
> > +  "mc_portal");
> > +   if (res == NULL) {
> > +   pr_err("request_mem_region() failed for MC portal %#llx\n",
> > +  mc_portal_phys_addr);
> > +   error = -EBUSY;
> > +   goto error;
> > +   }
> > +
> > +   mc_portal_virt_addr = ioremap_nocache(mc_portal_phys_addr,
> > + mc_portal_size);
> > +   if (mc_portal_virt_addr == NULL) {
> > +   pr_err("ioremap_nocache() failed for MC portal %#llx\n",
> > +  mc_portal_phys_addr);
> > +   error = -EFAULT;
> > +   goto error;
> > +   }
> > +
> > +   *new_mc_portal_virt_addr = mc_portal_virt_addr;
> > +   return 0;
> > +error:
> > +   if (mc_portal_virt_addr != NULL)
> > +   iounmap(mc_portal_virt_addr);
> > +
> > +   if (res != NULL)
> > +   release_mem_region(mc_portal_phys_addr, mc_portal_size);
> > +
> > +   return error;
> > +}
> 
> unnecessary initializations, bad error codes (both should be
> -ENOMEM),

Why should the first one be -ENOMEM?  It's not allocating memory, but
rather reserving I/O space.

>  unnecessarily complicated error path, plus a simpler
> implementation can be made if fn can return the mapped address, like
> so:
> 
> static void __iomem *map_mc_portal(phys_addr_t mc_portal_phys_addr,
>uint32_t mc_portal_size)
> { 
> struct resource *res;
> void __iomem *mapped_addr;
> 
> res = request_mem_region(mc_portal_phys_addr, mc_portal_size, 
>  "mc_portal");
> if (!res) 
> return NULL;
> 
> mapped_addr = ioremap_nocache(mc_portal_phys_addr,
>   mc_portal_size);
> if (!mapped_addr)
> release_mem_region(mc_portal_phys_addr, mc_portal_size);
> 
> return mapped_addr;
> }
> 
> the callsite can return -ENOMEM to its caller if returned NULL.

-ENOMEM would only be appropriate for one of these errors.

> > +#define ioread64(_p)   readq(_p)
> > +#define iowrite64(_v, _p)   writeq(_v, _p)
> 
> these definitions have names that are too generic to belong in a FSL
> h/w header: conflicts will be introduced once the existing
> io{read,write}32 functions get promoted.  Either use readq/writeq
> directly, or, if you can justify it, patch a more generic io.h.
> 
> Also, is there a reason the 'relaxed' versions of the i/o accessors
> aren't being used?

Raw accessors should only be used in performance critical sections where
it's worth the effort to implement and verify manual synchronization.
My understanding is that the entire management complex is related to
setup, not on the I/O fast path.

-Scott


--
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] x86/pmc_atom: Fix warning when CONFIG_DEBUG_FS=n

[Martin Kelly]

When compiling with CONFIG_DEBUG_FS=n, gcc emits an unused variable
warning for pmc_atom.c because "ret" is used only within the
CONFIG_DEBUG_FS block. This patch fixes it up to eliminate "ret" when
CONFIG_DEBUG_FS=n.

Signed-off-by: Martin Kelly 
---
 arch/x86/kernel/pmc_atom.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/pmc_atom.c b/arch/x86/kernel/pmc_atom.c
index 0c424a6..66e7d88 100644
--- a/arch/x86/kernel/pmc_atom.c
+++ b/arch/x86/kernel/pmc_atom.c
@@ -240,7 +240,9 @@ err:
 static int pmc_setup_dev(struct pci_dev *pdev)
 {
struct pmc_dev *pmc = _device;
+#ifdef CONFIG_DEBUG_FS
int ret;
+#endif /* CONFIG_DEBUG_FS */
 
/* Obtain ACPI base address */
pci_read_config_dword(pdev, ACPI_BASE_ADDR_OFFSET, _base_addr);
-- 
2.1.0

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

[PATCH] context_tracking: Fix checkpatch warnings

[Martin Kelly]

checkpatch emits several warnings for context_tracking.c, which are
fixed in this patch:

- No space after "("
- Lines longer than 80 characters

Signed-off-by: Martin Kelly 
---
 kernel/context_tracking.c | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 5664985..bf29065 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -54,8 +54,8 @@ void context_tracking_user_enter(void)
/*
 * Repeat the user_enter() check here because some archs may be calling
 * this from asm and if no CPU needs context tracking, they shouldn't
-* go further. Repeat the check here until they support the inline 
static
-* key check.
+* go further. Repeat the check here until they support the inline
+* static key check.
 */
if (!context_tracking_is_enabled())
return;
@@ -75,31 +75,33 @@ void context_tracking_user_enter(void)
WARN_ON_ONCE(!current->mm);
 
local_irq_save(flags);
-   if ( __this_cpu_read(context_tracking.state) != IN_USER) {
+   if (__this_cpu_read(context_tracking.state) != IN_USER) {
if (__this_cpu_read(context_tracking.active)) {
trace_user_enter(0);
/*
-* At this stage, only low level arch entry code 
remains and
-* then we'll run in userspace. We can assume there 
won't be
-* any RCU read-side critical section until the next 
call to
-* user_exit() or rcu_irq_enter(). Let's remove RCU's 
dependency
-* on the tick.
+* At this stage, only low level arch entry code
+* remains and then we'll run in userspace. We can
+* assume there won't be any RCU read-side critical
+* section until the next call to user_exit() or
+* rcu_irq_enter(). Let's remove RCU's dependency on
+* the tick.
 */
vtime_user_enter(current);
rcu_user_enter();
}
/*
-* Even if context tracking is disabled on this CPU, because 
it's outside
-* the full dynticks mask for example, we still have to keep 
track of the
-* context transitions and states to prevent inconsistency on 
those of
-* other CPUs.
-* If a task triggers an exception in userspace, sleep on the 
exception
-* handler and then migrate to another CPU, that new CPU must 
know where
-* the exception returns by the time we call exception_exit().
-* This information can only be provided by the previous CPU 
when it called
-* exception_enter().
-* OTOH we can spare the calls to vtime and RCU when 
context_tracking.active
-* is false because we know that CPU is not tickless.
+* Even if context tracking is disabled on this CPU, because
+* it's outside the full dynticks mask for example, we still
+* have to keep track of the context transitions and states to
+* prevent inconsistency on those of other CPUs.  If a task
+* triggers an exception in userspace, sleep on the exception
+* handler and then migrate to another CPU, that new CPU must
+* know where the exception returns by the time we call
+* exception_exit().  This information can only be provided by
+* the previous CPU when it called exception_enter().  OTOH we
+* can spare the calls to vtime and RCU when
+* context_tracking.active is false because we know that CPU is
+* not tickless.
 */
__this_cpu_write(context_tracking.state, IN_USER);
}
-- 
2.1.0

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

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Dave Hansen]

On 09/15/2014 08:20 PM, Ren, Qiaowei wrote:
>> What are the semantics across execve() ?
>> 
> This will not impact on the semantics of execve(). One runtime
> library
> for MPX will be provided (or merged into Glibc), and when the
> application starts, this runtime will be called to initialize MPX
> runtime environment, including calling prctl() to notify the kernel to
> start managing the bounds directories. You can see the discussion
> about exec(): https://lkml.org/lkml/2014/1/26/199

I think he's asking what happens to the kernel value at execve() time.

The short answer is that it is zero'd along with the rest of a new mm.
It probably _shouldn't_ be, though.  It's actually valid to have a bound
directory at 0x0.  We probably need to initialize it to -1 instead, and
that means initializing to -1 at execve() time.
--
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] Staging/bcm: Fix whitespace/comments in Ioctl.h

[Martin Kelly]

Cleanup whitespace and comments in Ioctl.h in a few ways:
- > 80 character cleanup
- Comment clarification
- More consistent vertical alignment

Signed-off-by: Martin Kelly 
---
 drivers/staging/bcm/Ioctl.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/bcm/Ioctl.h b/drivers/staging/bcm/Ioctl.h
index 797f862..fa5f867 100644
--- a/drivers/staging/bcm/Ioctl.h
+++ b/drivers/staging/bcm/Ioctl.h
@@ -87,9 +87,9 @@ struct bcm_user_thread_req {
 #define IOCTL_BCM_FLASH2X_SECTION_WRITE_IOW(BCM_IOCTL, 0x866, 
int)
 #define IOCTL_BCM_GET_FLASH2X_SECTION_BITMAP   _IOR(BCM_IOCTL, 0x867, int)
 #define IOCTL_BCM_SET_ACTIVE_SECTION   _IOW(BCM_IOCTL, 0x868, int)
-#defineIOCTL_BCM_IDENTIFY_ACTIVE_SECTION   _IO(BCM_IOCTL, 0x869)
+#define IOCTL_BCM_IDENTIFY_ACTIVE_SECTION  _IO(BCM_IOCTL, 0x869)
 #define IOCTL_BCM_COPY_SECTION _IOW(BCM_IOCTL, 0x870, int)
-#defineIOCTL_BCM_GET_FLASH_CS_INFO _IOR(BCM_IOCTL, 0x871, 
int)
+#define IOCTL_BCM_GET_FLASH_CS_INFO_IOR(BCM_IOCTL, 0x871, int)
 #define IOCTL_BCM_SELECT_DSD   _IOW(BCM_IOCTL, 0x872, int)
 #define IOCTL_BCM_NVM_RAW_READ _IOR(BCM_IOCTL, 0x875, int)
 #define IOCTL_BCM_CNTRLMSG_MASK_IOW(BCM_IOCTL, 0x874, 
int)
@@ -130,7 +130,7 @@ struct bcm_bulk_wrm_buffer {
 };
 
 enum bcm_flash2x_section_val {
-   NO_SECTION_VAL = 0, /* no section is chosen when absolute offset is 
given for RD/WR */
+   NO_SECTION_VAL = 0, /* no section chosen when absolute offset is given 
for RD/WR */
ISO_IMAGE1,
ISO_IMAGE2,
DSD0,
@@ -152,11 +152,11 @@ enum bcm_flash2x_section_val {
  * Structure used for READ/WRITE Flash Map2.x
  */
 struct bcm_flash2x_readwrite {
-   enum bcm_flash2x_section_val Section; /* which section has to be 
read/written */
-   u32 offset;  /* Offset within Section. */
-   u32 numOfBytes;  /* NOB from the offset */
+   enum bcm_flash2x_section_val Section; /* section to be read/written */
+   u32 offset; /* offset within section. */
+   u32 numOfBytes; /* number of bytes from the offset */
u32 bVerify;
-   void __user *pDataBuff;  /* Buffer for reading/writing */
+   void __user *pDataBuff; /* buffer for reading/writing */
 };
 
 /*
@@ -207,20 +207,20 @@ struct bcm_time_elapsed {
 };
 
 enum {
-   WIMAX_IDX = 0,  /* To access WiMAX chip GPIO's for GPIO_MULTI_INFO or 
GPIO_MULTI_MODE */
-   HOST_IDX,   /* To access Host chip GPIO's for GPIO_MULTI_INFO or 
GPIO_MULTI_MODE */
+   WIMAX_IDX = 0, /* To access WiMAX chip GPIO's for GPIO_MULTI_INFO or 
GPIO_MULTI_MODE */
+   HOST_IDX, /* To access Host chip GPIO's for GPIO_MULTI_INFO or 
GPIO_MULTI_MODE */
MAX_IDX
 };
 
 struct bcm_gpio_multi_info {
unsigned int uiGPIOCommand; /* 1 for set and 0 for get */
-   unsigned int uiGPIOMask;/* set the correspondig bit to 1 to access 
GPIO */
-   unsigned int uiGPIOValue;   /* 0 or 1; value to be set when command is 
1. */
+   unsigned int uiGPIOMask; /* set the corresponding bit to 1 to access 
GPIO */
+   unsigned int uiGPIOValue; /* 0 or 1; value to be set when command is 1. 
*/
 } __packed;
 
 struct bcm_gpio_multi_mode {
-   unsigned int uiGPIOMode;/* 1 for OUT mode, 0 for IN mode */
-   unsigned int uiGPIOMask;/* GPIO mask to set mode */
+   unsigned int uiGPIOMode; /* 1 for OUT mode, 0 for IN mode */
+   unsigned int uiGPIOMask; /* GPIO mask to set mode */
 } __packed;
 
 #endif
-- 
2.1.0

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

Re: [PATCH] powerpc: Fix build failure

[Alistair Popple]

Thanks for fixing these!

Acked-by: Alistair Popple 

On Thu, 21 Aug 2014 09:04:31 Pranith Kumar wrote:
> Fix the following build failure
> 
> drivers/built-in.o: In function `nhi_init':
> nhi.c:(.init.text+0x63390): undefined reference to `ehci_init_driver'
> 
> by adding a dependency on USB_EHCI_HCD which supplies the
> ehci_init_driver().
> 
> Also we need to depend on USB_OHCI_HCD similarly
> 
> Signed-off-by: Pranith Kumar 
> ---
>  arch/powerpc/platforms/44x/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig index 4d88f6a..3e7deb2 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -216,8 +216,8 @@ config AKEBONO
>   select IBM_EMAC_EMAC4
>   select IBM_EMAC_RGMII_WOL
>   select USB
> - select USB_OHCI_HCD_PLATFORM
> - select USB_EHCI_HCD_PLATFORM
> + select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
> + select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
>   select MMC_SDHCI
>   select MMC_SDHCI_PLTFM
>   select MMC_SDHCI_OF_476GTR

--
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] powerpc: Fix build failure when CONFIG_USB=y

[Alistair Popple]

Thanks for fixing these!

Acked-by: Alistair Popple 

On Thu, 21 Aug 2014 09:16:04 Pranith Kumar wrote:
> We are enabling USB unconditionally which results in following build failure
> 
> drivers/built-in.o: In function `tb_drom_read':
> (.text+0x1b62b70): undefined reference to `usb_speed_string'
> make: *** [vmlinux] Error
> 
> Enable USB only if USB_SUPPORT is set to avoid such failures
> 
> Signed-off-by: Pranith Kumar 
> ---
>  arch/powerpc/platforms/44x/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig index 3e7deb2..82f2da2 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -215,7 +215,7 @@ config AKEBONO
>   select NET_VENDOR_IBM
>   select IBM_EMAC_EMAC4
>   select IBM_EMAC_RGMII_WOL
> - select USB
> + select USB if USB_SUPPORT
>   select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
>   select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
>   select MMC_SDHCI

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

[PATCH v2 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

[Vivek Gautam]

Currently the DP_PHY_ENABLE register is mapped in the driver,
and accessed to control power to the PHY.
With mfd-syscon and regmap interface available at our disposal,
it's wise to use that instead of using a 'reg' property for the
controller and allocating a memory resource for that.

To facilitate this, we have added another compatible string
for Exynso5420 SoC to acquire driver data which contains
different DP-PHY-CONTROL register offset.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Cc: Kishon Vijay Abraham I 
---

Changes since v1:
 - state->regs should have been "struct regmap *" instead of
   "void __iomem *". So corrected the same.

 .../devicetree/bindings/phy/samsung-phy.txt|7 +-
 drivers/phy/phy-exynos-dp-video.c  |   78 ++--
 2 files changed, 60 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 7a6feea..15e0f2c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
 -
 
 Required properties:
-- compatible : should be "samsung,exynos5250-dp-video-phy";
-- reg : offset and length of the Display Port PHY register set;
+- compatible : should be one of the following supported values:
+- "samsung,exynos5250-dp-video-phy"
+- "samsung,exynos5420-dp-video-phy"
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 0;
 
 Samsung S5P/EXYNOS SoC series USB PHY
diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index 8b3026e..881ddb5 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -13,44 +13,58 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /* DPTX_PHY_CONTROL register */
 #define EXYNOS_DPTX_PHY_ENABLE (1 << 0)
 
+struct exynos_dp_video_phy_drvdata {
+   u32 phy_ctrl_offset;
+};
+
 struct exynos_dp_video_phy {
-   void __iomem *regs;
+   struct regmap *regs;
+   const struct exynos_dp_video_phy_drvdata *drvdata;
 };
 
-static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
+   unsigned int on)
 {
-   u32 reg;
+   unsigned int val;
 
-   reg = readl(state->regs);
-   if (on)
-   reg |= EXYNOS_DPTX_PHY_ENABLE;
-   else
-   reg &= ~EXYNOS_DPTX_PHY_ENABLE;
-   writel(reg, state->regs);
+   if (IS_ERR(state->regs))
+   return;
 
-   return 0;
+   val = on ? 0 : EXYNOS_DPTX_PHY_ENABLE;
+
+   regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
+  EXYNOS_DPTX_PHY_ENABLE, val);
 }
 
 static int exynos_dp_video_phy_power_on(struct phy *phy)
 {
struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
 
-   return __set_phy_state(state, 1);
+   /* Disable power isolation on DP-PHY */
+   exynos_dp_video_phy_pwr_isol(state, 0);
+
+   return 0;
 }
 
 static int exynos_dp_video_phy_power_off(struct phy *phy)
 {
struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
 
-   return __set_phy_state(state, 0);
+   /* Enable power isolation on DP-PHY */
+   exynos_dp_video_phy_pwr_isol(state, 1);
+
+   return 0;
 }
 
 static struct phy_ops exynos_dp_video_phy_ops = {
@@ -59,11 +73,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
.owner  = THIS_MODULE,
 };
 
+static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
+   .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
+};
+
+static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
+   .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
+};
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+   {
+   .compatible = "samsung,exynos5250-dp-video-phy",
+   .data = _dp_video_phy,
+   }, {
+   .compatible = "samsung,exynos5420-dp-video-phy",
+   .data = _dp_video_phy,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
 static int exynos_dp_video_phy_probe(struct platform_device *pdev)
 {
struct exynos_dp_video_phy *state;
struct device *dev = >dev;
-   struct resource *res;
+   const struct of_device_id *match;
struct phy_provider *phy_provider;
struct phy *phy;
 
@@ -71,11 +105,15 @@ static int exynos_dp_video_phy_probe(struct 
platform_device *pdev)
if (!state)
return -ENOMEM;

Re: [f2fs-dev][PATCH 4/5] f2fs: fix to clean previous mount option when remount_fs

[Gu Zheng]

On 09/16/2014 11:05 AM, Chao Yu wrote:

> Hi Gu,
> 
>> -Original Message-
>> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
>> Sent: Tuesday, September 16, 2014 9:51 AM
>> To: Chao Yu
>> Cc: Jaegeuk Kim; Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [f2fs-dev][PATCH 4/5] f2fs: fix to clean previous mount option 
>> when remount_fs
>>
>> Hi Yu,
>> On 09/15/2014 06:04 PM, Chao Yu wrote:
>>
>>> In manual of mount, we descript remount as below:
>>>
>>> "mount -o remount,rw /dev/foo /dir
>>> After  this call all old mount options are replaced and arbitrary stuff from
>>> fstab is ignored, except the loop= option which is internally generated and
>>> maintained by the mount command."
>>>
>>> Previously f2fs do not clear up old mount options when remount_fs, so we 
>>> have no
>>> chance of disabling previous option (e.g. flush_merge). Fix it.
>>
>> Please don't.
>> "Remount" should just change what you specified and keep others unchanged.
> 
> Actually, there are two kinds of different 'remount', they are all specified 
> in
> manual of mount.
> 1) mount -o remount,rw /dev/foo /dir
> 2) mount -o remount,rw  /dir

Thanks for your reminder, I confused them.

Regards,
Gu

> 
> I think 'remount' in your description is the second kind, being different 
> from the
> first kind in description of this patch, for the second kind remount, 'mount' 
> command
> can keep old options by loading them from mtab/fstab then merge them with new
> specified options.
> 
> Thanks,
> Yu
> 
>> The problem here is that we need to provide mount opts for disable/enable
>> some features, but we missed it. So the right way is adding these opts if
>> we really need them.
>>
>> Thanks,
>> Gu
>>
>>>
>>> Signed-off-by: Chao Yu 
>>> ---
>>>  fs/f2fs/super.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>>> index 5bb..90fcbe0 100644
>>> --- a/fs/f2fs/super.c
>>> +++ b/fs/f2fs/super.c
>>> @@ -616,6 +616,9 @@ static int f2fs_remount(struct super_block *sb, int 
>>> *flags, char *data)
>>> org_mount_opt = sbi->mount_opt;
>>> active_logs = sbi->active_logs;
>>>
>>> +   sbi->mount_opt.opt = 0;
>>> +   sbi->active_logs = NR_CURSEG_TYPE;
>>> +
>>> /* parse mount options */
>>> err = parse_options(sb, data);
>>> if (err)
> 
> 
> .
> 


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

Re: [PATCH v5] x86,cpu-hotplug: assign same CPU number to readded CPU

[Mike Galbraith]

On Mon, 2014-09-15 at 10:44 -0600, Toshi Kani wrote: 
> On Mon, 2014-09-15 at 06:25 +0200, Mike Galbraith wrote:
> > On Thu, 2014-09-11 at 16:21 +0900, Yasuaki Ishimatsu wrote: 
> > > There is no response for two months since posting v4.
> > > What can I do for pushing the patch to upstream?
> > 
> > Looks to me like we have two patches floating about for more or less the
> > same problem, this one, and...
> > 
> > https://lkml.org/lkml/2014/7/29/159
> > 
> > ..this one, which you reviewed, and HP both reviewed and tested.
> > 
> > We seem to kinda stuck with Boris having said don't diddle the
> > cpu_llc_shared_map, but HP/Intel saying that this map diddling fixes
> > their explosions.  If your alternative is preferred over diddling
> > cpu_llc_shared_map, perhaps HP/Intel can test/confirm that their
> > explosions stay gone? 
> 
> Well, Boris mentioned later in his email:
> https://lkml.org/lkml/2014/7/22/201
> 
> And I agree with his assessment that both patches make sense.  

Nonetheless, this just reeks of "department of redundancy department".
I have nothing against doing both really, but it does leave me wondering
if we would not then be merging the mask clearing "just because".

-Mike

--
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 firmware RESEND] rtl_nic: add firmware for RTL8168H and RTL8107E

[Hayes Wang]

File: rtl_nic/rtl8168h-1.fw
Version: 0.0.1

File: rtl_nic/rtl8168h-2.fw
Version: 0.0.1

File: rtl_nic/rtl8107e-1.fw
Version: 0.0.1

File: rtl_nic/rtl8107e-2.fw
Version: 0.0.1

Signed-off-by: Hayes Wang 
---
 WHENCE|  12 
 rtl_nic/rtl8107e-1.fw | Bin 0 -> 2496 bytes
 rtl_nic/rtl8107e-2.fw | Bin 0 -> 2464 bytes
 rtl_nic/rtl8168h-1.fw | Bin 0 -> 2496 bytes
 rtl_nic/rtl8168h-2.fw | Bin 0 -> 2464 bytes
 5 files changed, 12 insertions(+)
 create mode 100644 rtl_nic/rtl8107e-1.fw
 create mode 100644 rtl_nic/rtl8107e-2.fw
 create mode 100644 rtl_nic/rtl8168h-1.fw
 create mode 100644 rtl_nic/rtl8168h-2.fw

diff --git a/WHENCE b/WHENCE
index 26cabf4..3ffc68e 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2149,6 +2149,18 @@ Version: 0.0.1
 File: rtl_nic/rtl8168g-3.fw
 Version: 0.0.1
 
+File: rtl_nic/rtl8168h-1.fw
+Version: 0.0.1
+
+File: rtl_nic/rtl8168h-2.fw
+Version: 0.0.1
+
+File: rtl_nic/rtl8107e-1.fw
+Version: 0.0.1
+
+File: rtl_nic/rtl8107e-2.fw
+Version: 0.0.1
+
 Licence:
  * Copyright © 2011-2013, Realtek Semiconductor Corporation
  *
diff --git a/rtl_nic/rtl8107e-1.fw b/rtl_nic/rtl8107e-1.fw
new file mode 100644
index 
..5ac3d62bcd6adb9a28bc84dcccbccd99a0dab290
GIT binary patch
literal 2496
zcmY+`aY$8J9tZH#8`lw6?5({q$7vb~2?^JE&%|{lUW`t4Bah?lY)?F8mg%wO)YiQ
z(?BEZXd=scHn5RqHqpXnw$Mr_RW}Zg$hd9(w7cpS|p3KLU?ml-
zqLS5Av4(1DNK;E4^)%4PI-1C`o(*iInN75?nJu)^##XkmogM6?oenzbqMP0Hu!mmy
z=w~nc*v|nD5*gqShdIJgjxop($2q}CPH~zuoMo61MmfiME^v`cT;>W_xyBgRxxqLS
zOmdScZgHDCOmmle+~)xgnc)$S$uY|uPk72Rp7Vm2yy7))c*{H9Gf()|{*y;O1r$<5
zF-b~DQA!!*tY9S-tfG?DRI!F?YDiN{9rZNO$U2(HvYriWq?t{$u$e8i(#BS{v7H_4
zq@4~r>7tw6^st9s`simb``FI`4iXvQ5QjO!QI0Xl5XU*eNltN^Gn{3Z5k@)3c`k5~
zOI+p(SGmR**SWzs6HIcGDQ9hEqh>PveyTpPEU0EBS4T<4S4=98`
zq`xTqELO#3F?6J2&6a(UxhrBNX3$2=k%r2yy{d;{?`RF~{DR>$HtD5)!UGO@ixDgT(5$QUPE3Jr#L`1|H
zCnBN=iHL{@35kd{A|fPOainn~A|fIpA|4_U5p6_7MA&|GnxXsNhu`dL@YFE`(H?%jl{=IE&
zYkU7c2fyoSZ|eJguzl^?wUys>|EsjBrhZjbebqPNr_r*xz6(M~PcHl_hLA%pdE`?-
zAxVnjM*dw*8aXXD
z$c=K7+{`*!SkDGp*+?6k*vuBT(m^L(bkoB|0S4L54tBDO-9(1i!(R5Wp936Z
zm_r=q2uC@_aZWJ8Nk%!vY0hw#bDZY_7rDe3m$||?6HIcIDXwvy8{Fg;x4FYz?s1<7
zJS4+3Gd$ukPk72Rp7Vm2yy7))c*`u|hY%8EkxdS{ZoTmYe>^TBTY23juzIlfmSxs#wIqig{^eZNf+Jpu#H~&=x2aIwzGqs
z>|!^OA@;DBeeCA|2N~uNhdIJgj`sPH~zuoaG$nxxhs(F~()CFwO*%TxE)D
zT;~Qixy5bnaF=`B=K)c+3-?@{H%a;3cnk%^Th_OBk~LWRXn{x#W>g0fi(f
zqL>nvu#{4kQO0u0SwRJrq^PEbTI#50HET%IKqE~wvyK+lvw>DN(#9q>vxTj6&`B5F
z^stRy`sinXLAJAlo$O*aksUVd4GSl`fgz|X1%Y8_cf^hUX+|4zrgr|BR9KSvL;xPLzl!mZ);`e8poB#LU
Q^}qRR1rzD{e|B-EW9{>OV

literal 0
HcmV?d1

diff --git a/rtl_nic/rtl8168h-1.fw b/rtl_nic/rtl8168h-1.fw
new file mode 100644
index 
..4bdd3825e3bdc9a15ddd87c199636bda4afb4169
GIT binary patch
literal 2496
zcmY+`aY$8J9tZH#8^;k>?2Wz5b=pQkLc+19<2tT{JlY5ei4cj1D8~^;LPSI_
z5z)935fKrtNJK;%5h2ltBaIUg(nLf^#6u(^qK$}%2zNhPyX@ZgKK#Dt+;`5o_ntrA
z4IzZS{_gtfy85oKs&}WW(pA-E>A$S2u31-I>)gW8Mr$I3p3u@<_jO&(?%r?vzw6pv
zldi5!SEs+J`mXc)vg+D~uhR{G{wDl1TD~ymV;Nc!LS}O5mobDq@+qK@Bt@hsj-P~(
zjeeJx4RL8U5kJr7#AVssxICK|S7h_!AF~DVi)>;1>^I~7R1{}_O2uEAieuu}k{Et2
zjdNjToXD=yF4JBeixcJY8o9#!YvoG0N>0bbR80)ywQ`+YFE_~R7bJ?_Rviaz4Xz~UiPt{0~{nWz#$HEgrgi|kRgt9f|H!$
zG-o)=Fe8j|j`LjLBA2+#6|QoPF|KoiaVD7LCR5zvHg}ljF88?410FKNBOa4wmN}mA
zlxIBW1uuEUYu@mdcf4nw@Iwd*a>yl*d26oX=GuDsz1~#|T|7PittE8E!44tBDOHrnZ+lP>nqO%J{F
z(a?v7ZARBr?Du4s(Q~9Al6nj*OoZ>WRILk02jB<|iT;L*?xXcx3dBtnq@RoPHXP)q*{U?W9^2n!v
zLXs4bqL>m;EOSWP)=s9-IXRFS5JTI#5$f%P;=4l3jkDetl8OBINhn$PPsj}XVc{Jj>9hEqh>PveyTpPET^Spn35nqj4=99B
z(|^tXGFHT8F|?;*)!4GQB&6a(Uzt3VNX4RI=k%r2oXS*8{;!c#T=I8))2Y~-O~uSo
z?SJsMRBSBKKPdm84y58tMJkqloGVvdVa^ibJ?F#k`@HY_JkNXH=a2J*
z5W>Jvf`plcKkS#6BlQ4<0qNC_|Hs!eE}r#XKPTh=nu}uM
z*WwudTM}o~ooBs$HtREEXlo&!
z%1v@JYiVH}>uF^JZER!{o7qAKopjMn4_oP_kA4OiWE
z4Aac;kVib`2~T;(b6)V0SG?v8vxNVIkRXd}a>yl*dvWd-Xp@UAk=%$CQ^wLK^0}Qf_?d)JD
zyNC?2n?3AhANx7LFb6rrVUBQ=V;pCM6O3|_Q=H}uXF11tE^v`CE^(Q0CYa<3Q(Wa5
z*SWz>ZgHDC+~pqkc|e9~W_ZXW9`l5!JmWbpc*!eX^M+Z%ko6~vY;wpYk9-O!BuNp)
zl(2-Ql(LL6mQ&6ODySqyH8s>yM?I@pO_~N8X`-36w6Ko#w6cLVHnNG$Y@vfry6C2d
zt@P4IKLZT1jqU7UC%cFYv70^YWgq)Fz%U0n#9@wblw%xcgcFQ%l2e@K3}-pVc`k5~
zF)neLaVD7L3R7I=8rQkOO>S|UJKW_S_jy2uX=ZrHBOddFr#$01FL=o-Uh{@o!cW$p
zEV9WVmpt+*ppYa*6jQq4$TqgKgPrUmGQ@87u$O)8=K#YTfMaH>6Q1
z=e*!0uXxQHW`COBE5z(LZNE^E$c^uX;<^8X^w5WMdx!#``R_!WZ-@Q`CY(E!w(#kY
z80qqYLik7O>)g*`d0Z41bS7ivm>QCC?p&!noJhvPkwwN!#-y56k&4OQ&@$Y&+
zPsWmW_h+kb7bauYyP9}cgZks5http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: imx6dl: disable dma support for spi on i.mx6dl

[Robin Gong]

On Mon, Sep 15, 2014 at 01:50:02PM +0200, Alexander Holler wrote:
> Am 10.09.2014 07:30, schrieb Robin Gong:
> >There is one weird data in rxfifo after one full rx/tx transfer
> >done sometimes. It looks a design issue and hard to workaround
> >totally, so disable dma functhion here. And will re-enable it
> >once the root cause found.
> 
> Hmm, I experience problems with DMA too but on uart3. I'm using the same
> workaround for the uart (I've just commented out the dma entries in the DT).
> The problem manifests itself here such, that brcm_patchram_plus
> hangs while uploading the firmware to a BCM4330 connected at uart3
> (reproducible).
> 
> So maybe there is a bug in the DMA-engine which not only effects
> SPI. Or both drivers contain the same error in handling DMA (maybe
> through c).
> But that's just specualtion from me, I haven't looked further into
> that problem.
> 
> Regards,
> 
> Alexander Holler
Thanks for your information share. But my issue should be caused by hardware,
since everything is ok if it runs on other i.mx6 chip. Is your board also based
on i.mx6 chip? If yes, hope you can raise your issue in freescale community or
contact with Andy whose mail address added in CC list fugang.d...@freescale.cm.
We have fix some bugs in UART DMA case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net] r8169: adjust __rtl8169_set_features

[Hayes Wang]

Remove the "changed" test in __rtl8169_set_features(). Instead, do
simple test in rtl8169_set_features().

Set the RxChkSum and RxVlan through __rtl8169_set_features() in
rtl_open().

Signed-off-by: Francois Romieu 
Signed-off-by: Hayes Wang 
---
 drivers/net/ethernet/realtek/r8169.c | 74 +---
 1 file changed, 34 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 7a7860a..ef2cee5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1783,33 +1783,31 @@ static void __rtl8169_set_features(struct net_device 
*dev,
   netdev_features_t features)
 {
struct rtl8169_private *tp = netdev_priv(dev);
-   netdev_features_t changed = features ^ dev->features;
void __iomem *ioaddr = tp->mmio_addr;
+   u32 rx_config;
 
-   if (!(changed & (NETIF_F_RXALL | NETIF_F_RXCSUM |
-NETIF_F_HW_VLAN_CTAG_RX)))
-   return;
+   rx_config = RTL_R32(RxConfig);
+   if (features & NETIF_F_RXALL)
+   rx_config |= (AcceptErr | AcceptRunt);
+   else
+   rx_config &= ~(AcceptErr | AcceptRunt);
 
-   if (changed & (NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_RX)) {
-   if (features & NETIF_F_RXCSUM)
-   tp->cp_cmd |= RxChkSum;
-   else
-   tp->cp_cmd &= ~RxChkSum;
+   RTL_W32(RxConfig, rx_config);
 
-   if (features & NETIF_F_HW_VLAN_CTAG_RX)
-   tp->cp_cmd |= RxVlan;
-   else
-   tp->cp_cmd &= ~RxVlan;
+   if (features & NETIF_F_RXCSUM)
+   tp->cp_cmd |= RxChkSum;
+   else
+   tp->cp_cmd &= ~RxChkSum;
 
-   RTL_W16(CPlusCmd, tp->cp_cmd);
-   RTL_R16(CPlusCmd);
-   }
-   if (changed & NETIF_F_RXALL) {
-   int tmp = (RTL_R32(RxConfig) & ~(AcceptErr | AcceptRunt));
-   if (features & NETIF_F_RXALL)
-   tmp |= (AcceptErr | AcceptRunt);
-   RTL_W32(RxConfig, tmp);
-   }
+   if (features & NETIF_F_HW_VLAN_CTAG_RX)
+   tp->cp_cmd |= RxVlan;
+   else
+   tp->cp_cmd &= ~RxVlan;
+
+   tp->cp_cmd |= RTL_R16(CPlusCmd) & ~(RxVlan | RxChkSum);
+
+   RTL_W16(CPlusCmd, tp->cp_cmd);
+   RTL_R16(CPlusCmd);
 }
 
 static int rtl8169_set_features(struct net_device *dev,
@@ -1817,8 +1815,11 @@ static int rtl8169_set_features(struct net_device *dev,
 {
struct rtl8169_private *tp = netdev_priv(dev);
 
+   features &= NETIF_F_RXALL | NETIF_F_RXCSUM | NETIF_F_HW_VLAN_CTAG_RX;
+
rtl_lock_work(tp);
-   __rtl8169_set_features(dev, features);
+   if (features ^ dev->features);
+   __rtl8169_set_features(dev, features);
rtl_unlock_work(tp);
 
return 0;
@@ -6707,12 +6708,7 @@ static int rtl_open(struct net_device *dev)
 
rtl8169_init_phy(dev, tp);
 
-   if (dev->features & NETIF_F_HW_VLAN_CTAG_RX)
-   tp->cp_cmd |= RxVlan;
-   else
-   tp->cp_cmd &= ~RxVlan;
-
-   RTL_W16(CPlusCmd, tp->cp_cmd);
+   __rtl8169_set_features(dev, dev->features);
 
rtl_pll_power_up(tp);
 
@@ -7123,8 +7119,7 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
}
 }
 
-static int
-rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
const unsigned int region = cfg->region;
@@ -7199,7 +7194,7 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
goto err_out_mwi_2;
}
 
-   tp->cp_cmd = RxChkSum;
+   tp->cp_cmd = 0;
 
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
@@ -7240,13 +7235,6 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
pci_set_master(pdev);
 
-   /*
-* Pretend we are using VLANs; This bypasses a nasty bug where
-* Interrupts stop flowing on high load on 8110SCd controllers.
-*/
-   if (tp->mac_version == RTL_GIGA_MAC_VER_05)
-   tp->cp_cmd |= RxVlan;
-
rtl_init_mdio_ops(tp);
rtl_init_pll_power_ops(tp);
rtl_init_jumbo_ops(tp);
@@ -7307,8 +7295,14 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO |
NETIF_F_HIGHDMA;
 
+   tp->cp_cmd |= RxChkSum | RxVlan;
+
+   /*
+* Pretend we are using VLANs; This bypasses a nasty bug where
+* Interrupts stop flowing on high load on 8110SCd controllers.
+*/
if (tp->mac_version == RTL_GIGA_MAC_VER_05)
-   /* 

Re: Request to include Mailbox tree in linux-next

[Jassi Brar]

On 8 August 2014 08:58, Stephen Rothwell  wrote:
> Hi Jassi,
>
> On Fri, 8 Aug 2014 20:40:47 +0530 Jassi Brar  
> wrote:
>>
>> On 8 August 2014 20:11, Russell King - ARM Linux  
>> wrote:
>> >> Upon Mark's suggestion (and the right thing to do) I wanted the patchset
>> >> to live the cycle in linux-next.
>> >
>> > Yes, that's the right thing to do, but you sent the request at an
>> > inappropriate time.  The correct time to send your request would be
>> > after 3.17-rc1 has been released, IOW after the current merge window
>> > is over.
>> >
>> > In general, kernel developers don't "remember" requests from one week
>> > to the next; instead, we much prefer people send their requests at the
>> > appropriate times in the development cycle.
>> >
>> OK, thanks for explaining.
>
> As Russell has said, if you remind me after -rc1 is out, I will add
> your tree then.  I will try to remember, but don't depend on it.
>
Hi Stephen, Could you please add now ?

Tree:   git://git.linaro.org/landing-teams/working/fujitsu/integration.git
Branch:   mailbox-for-next
Contact:  Jassi Brar 

Thanks,
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] ARM: dts: imx6dl: disable dma support for spi on i.mx6dl

[Robin Gong]

Hi Lucas,
  I understood your concern,but looks we have to break old DT. Our old DT
support SPI DMA on i.mx6q/dl(v2,b3810c3dc1bcbc6a), but the DMA support patch
for SPI driver is still in reviewing(v6). So the violation you mentioned comes
if someone use the DT during the time(from v2 to spi driver patch upstreamed).
  The different behaviors on different chips(only i.mxdl can't pass strength
test) are just found from last month, this is why I sent the patch for disable
SPI DMA support on i.mx6dl during I sent v6 patch for spi driver. I think that's
make sense, because DTs are also in development, new difference between 
different
chips maybe found in the future although they share the same IP
  Yes, I can check cpu type by looking at DT in spi driver, but it's not nice.
So I'm afraid that we have to break the old DTs in the gap between the two
levels patch accepted cycle.

On Mon, Sep 15, 2014 at 11:41:13AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 10.09.2014, 13:30 +0800 schrieb Robin Gong:
> > There is one weird data in rxfifo after one full rx/tx transfer
> > done sometimes. It looks a design issue and hard to workaround
> > totally, so disable dma functhion here. And will re-enable it
> > once the root cause found.
> > 
> Sorry, I'm late to this as Shawn seems to already have picked up this
> patch, but this isn't the right way to fix the problem.
> 
> We made it clear at kernel summit last year that we try to not break
> existing DTs as booting a new kernel with an old DT is a valid use case.
> While you don't strictly violate this rule what you do here is only
> fixing systems booting with a new DT while leaving others broken.
> 
> If you are working around a hardware problem please disable DMA support
> in the driver. This will also allow you to enable it again, if you find
> another workaround without touching the DT again.
> 
> So this patch gets a NAK from me.
> 
> > Signed-off-by: Robin Gong 
> > ---
> >  arch/arm/boot/dts/imx6q.dtsi   | 20 
> >  arch/arm/boot/dts/imx6qdl.dtsi |  8 
> >  2 files changed, 20 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> > index e9f3646..8d5d33b 100644
> > --- a/arch/arm/boot/dts/imx6q.dtsi
> > +++ b/arch/arm/boot/dts/imx6q.dtsi
> > @@ -291,6 +291,26 @@
> > };
> >  };
> >  
> > + {
> > +   dmas = < 3 7 1>, < 4 7 2>;
> > +   dma-names = "rx", "tx";
> > +};
> > +
> > + {
> > +   dmas = < 5 7 1>, < 6 7 2>;
> > +   dma-names = "rx", "tx";
> > +};
> > +
> > + {
> > +   dmas = < 7 7 1>, < 8 7 2>;
> > +   dma-names = "rx", "tx";
> > +};
> > +
> > + {
> > +   dmas = < 9 7 1>, < 10 7 2>;
> > +   dma-names = "rx", "tx";
> > +};
> > +
> >  _dsi {
> > port@2 {
> > reg = <2>;
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> > index 70d7207..f696546 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -210,8 +210,6 @@
> > clocks = < IMX6QDL_CLK_ECSPI1>,
> >  < IMX6QDL_CLK_ECSPI1>;
> > clock-names = "ipg", "per";
> > -   dmas = < 3 7 1>, < 4 7 2>;
> > -   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -224,8 +222,6 @@
> > clocks = < IMX6QDL_CLK_ECSPI2>,
> >  < IMX6QDL_CLK_ECSPI2>;
> > clock-names = "ipg", "per";
> > -   dmas = < 5 7 1>, < 6 7 2>;
> > -   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -238,8 +234,6 @@
> > clocks = < IMX6QDL_CLK_ECSPI3>,
> >  < IMX6QDL_CLK_ECSPI3>;
> > clock-names = "ipg", "per";
> > -   dmas = < 7 7 1>, < 8 7 2>;
> > -   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -252,8 +246,6 @@
> > clocks = < IMX6QDL_CLK_ECSPI4>,
> >  < IMX6QDL_CLK_ECSPI4>;
> > clock-names = "ipg", "per";
> > -   dmas = < 9 7 1>, < 10 7 2>;
> > -   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> 
> -- 
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions   | http://www.pengutronix.de/  |
> 
--
To 

[PATCH] staging: dgap: use schedule_timeout_interruptible() instead of dgap_ms_sleep()

[Daeseok Youn]

Using schedule_timeout_interruptible() is exactly same as
setting a status of current process and calling  schedule_timeout().

Removes dgap_ms_sleep(), because this function is used
only when closing tty channel on dgap_tty_close().
And also removes ch_close_delay that is always set to 250
on dgap_tty_init().

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgap/dgap.c |   36 ++--
 drivers/staging/dgap/dgap.h |3 ---
 2 files changed, 6 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 67da1d5..8aff0de 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -180,7 +180,6 @@ static char *dgap_create_config_string(struct board_t *bd, 
char *string);
 static uint dgap_config_get_useintr(struct board_t *bd);
 static uint dgap_config_get_altpin(struct board_t *bd);
 
-static int dgap_ms_sleep(ulong ms);
 static void dgap_do_bios_load(struct board_t *brd, const u8 *ubios, int len);
 static void dgap_do_fep_load(struct board_t *brd, const u8 *ufep, int len);
 #ifdef DIGI_CONCENTRATORS_SUPPORTED
@@ -1200,26 +1199,6 @@ static void dgap_init_globals(void)
 
 /
  *
- * Utility functions
- *
- /
-
-/*
- * dgap_ms_sleep()
- *
- * Put the driver to sleep for x ms's
- *
- * Returns 0 if timed out, !0 (showing signal) if interrupted by a signal.
- */
-static int dgap_ms_sleep(ulong ms)
-{
-   current->state = TASK_INTERRUPTIBLE;
-   schedule_timeout((ms * HZ) / 1000);
-   return signal_pending(current);
-}
-
-/
- *
  * TTY Initialization/Cleanup Functions
  *
  /
@@ -1462,9 +1441,6 @@ static int dgap_tty_init(struct board_t *brd)
ch->ch_tstart = 0;
ch->ch_rstart = 0;
 
-   /* .25 second delay */
-   ch->ch_close_delay = 250;
-
/*
 * Set queue water marks, interrupt mask,
 * and general tty parameters.
@@ -2297,12 +2273,12 @@ static void dgap_tty_close(struct tty_struct *tty, 
struct file *file)
 * Go to sleep to ensure RTS/DTR
 * have been dropped for modems to see it.
 */
-   if (ch->ch_close_delay) {
-   spin_unlock_irqrestore(>ch_lock,
-  lock_flags);
-   dgap_ms_sleep(ch->ch_close_delay);
-   spin_lock_irqsave(>ch_lock, lock_flags);
-   }
+   spin_unlock_irqrestore(>ch_lock,
+   lock_flags);
+   /* .25 second delay for dropping RTS/DTR */
+   schedule_timeout_interruptible(msecs_to_jiffies(250));
+   signal_pending(current);
+   spin_lock_irqsave(>ch_lock, lock_flags);
}
 
ch->pscan_state = 0;
diff --git a/drivers/staging/dgap/dgap.h b/drivers/staging/dgap/dgap.h
index a0307b9..ba05c65 100644
--- a/drivers/staging/dgap/dgap.h
+++ b/drivers/staging/dgap/dgap.h
@@ -982,9 +982,6 @@ struct channel_t {
u32 ch_open_count;  /* open count   */
u32 ch_flags;   /* Channel flags*/
 
-   u32 ch_close_delay; /* How long we should drop  */
-   /* RTS/DTR for  */
-
u32 ch_cpstime; /* Time for CPS calculations*/
 
tcflag_t ch_c_iflag;/* channel iflags   */
-- 
1.7.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] x86: Consider multiple nodes in a single socket to be "sane"

[Peter Zijlstra]

On Mon, Sep 15, 2014 at 03:26:41PM -0700, Dave Hansen wrote:
> 
> I'm getting the spew below when booting with Haswell (Xeon
> E5-2699) CPUs and the "Cluster-on-Die" (CoD) feature enabled in
> the BIOS. 

What is that cluster-on-die thing? I've heard it before but never could
find anything on it.

> This also fixes sysfs because CPUs with the same 'physical_package_id'
> in /sys/devices/system/cpu/cpu*/topology/ are not listed together
> in the same 'core_siblings_list'.  This violates a statement from
> Documentation/ABI/testing/sysfs-devices-system-cpu:
> 
>   core_siblings: internal kernel map of cpu#'s hardware threads
>   within the same physical_package_id.
> 
>   core_siblings_list: human-readable list of the logical CPU
>   numbers within the same physical_package_id as cpu#.

No that statement is wrong; it assumes physical_package_id is a good
identifier for nodes. Clearly this is no longer true.

The idea is that core_siblings (or rather cpu_core_mask) is a mask of
all cores on a node. 

> The sysfs effects here cause an issue with the hwloc tool where
> it gets confused and thinks there are more sockets than are
> physically present.

Meh, so then we need another mask.

The important bit you didn't show was the scheduler domain setup. I
suspect it all works by accident, not by design.

> diff -puN arch/x86/kernel/smpboot.c~hsw-cod-is-sane arch/x86/kernel/smpboot.c
> --- a/arch/x86/kernel/smpboot.c~hsw-cod-is-sane   2014-09-15 
> 14:56:20.012314468 -0700
> +++ b/arch/x86/kernel/smpboot.c   2014-09-15 14:58:58.837506644 -0700
> @@ -344,10 +344,13 @@ static bool match_llc(struct cpuinfo_x86
>  static bool match_mc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
>  {
>   if (c->phys_proc_id == o->phys_proc_id) {
> - if (cpu_has(c, X86_FEATURE_AMD_DCM))
> - return true;
> -
> - return topology_sane(c, o, "mc");
> + /*
> +  * We used to enforce that 'c' and 'o' be on the
> +  * same node, but AMD's DCM and Intel's Cluster-
> +  * on-Die (CoD) support both have physical
> +  * processors that span NUMA nodes.
> +  */
> + return true;
>   }
>   return false;
>  }

This is wrong (and I suppose the AMD case was already wrong). That
function is supposed to match a multi-core group which is very much
supposed to be smaller-or-equal to a node, not spanning nodes.

The scheduler assumes: SMT <= LLC <= MC <= NODE and if setting the MC
mask to cover multiple nodes works, its by accident.
--
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 net 1/2] r8169: fix the default setting of rx vlan

[Hayes Wang]

 From: Francois Romieu [mailto:rom...@fr.zoreil.com] 
> Sent: Tuesday, September 16, 2014 8:03 AM
[...]
> However it's getting messy and the code stomps CPlusCmd in 
> rtl_open right
> before it's given a chance to be read in hw_start. Something like the
> untested patch below should avoid it and keep related things together.

You are right. Your patch is more reasonable. I would sent the patch.
Thanks.
 
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] checkpatch: check for subject uniqueness in git repository.

[Joe Perches]

On Mon, 2014-09-15 at 20:43 +0200, Fabian Frederick wrote:
> Adding patch subject uniqueness check in checkpatch --strict mode.
> See Documentation/SubmittingPatches/globally-unique identifier.

Perhaps something like this?
---
 scripts/checkpatch.pl | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0c520f7..e19c40b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -622,6 +622,27 @@ sub git_commit_info {
return ($id, $desc);
 }
 
+my @git_commits = ();
+my @previous_subjects = ();
+
+sub check_subject_duplication {
+   my ($subject) = @_;
+
+   if ($check && $#git_commits < 1 && which("git") && -e ".git") {
+   my $output = `git log --no-color --format='%H %s' 2>&1`;
+   $output =~ s/^\s*//gm;
+   @git_commits = split("\n", $output);
+   }
+
+   return 1 if (grep(/^[a-f0-9]{40,40} $subject$/, @git_commits));
+
+   return 2 if (grep(/^$subject$/, @previous_subjects));
+
+   push(@previous_subjects, $subject);
+
+   return 0;
+}
+
 $chk_signoff = 0 if ($file);
 
 my @rawlines = ();
@@ -1264,6 +1285,20 @@ sub raw_line {
return $line;
 }
 
+sub get_complete_header {
+   my ($linenr) = @_;
+
+   my $offset = $linenr - 1;
+
+   my $line = $rawlines[$offset++];
+   while (defined $rawlines[$offset] &&
+  $rawlines[$offset] =~ /\s(\S.*)$/) {
+   $line .= $rawlines[$offset++];
+   }
+
+   return $line;
+}
+
 sub cat_vet {
my ($vet) = @_;
my ($res, $coded);
@@ -2047,6 +2082,23 @@ sub process {
}
}
 
+# Check git commit and patch subject duplication
+   if ($in_header_lines && $line =~ /^Subject:/) {
+   my $subject = get_complete_header($linenr);
+   if ($subject =~ /^Subject:\s*(?:\[[^\]]*\])?\s*(.*)$/) {
+   $subject = $1;
+   }
+
+   my $subject_dup = check_subject_duplication($subject);
+   if ($subject_dup == 1) {
+   CHK("NOT_UNIQUE_SUBJECT",
+   "Identical git commit subject found\n" . 
$herecurr);
+   } elsif ($subject_dup == 2) {
+   CHK("NOT_UNIQUE_SUBJECT",
+   "Identical patch commit subject found\n" . 
$herecurr);
+   }
+   }
+
 # Check the patch for a signoff:
if ($line =~ /^\s*signed-off-by:/i) {
$signoff++;


--
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: Status of 'cris' architecture support in Linux kernel

[Guenter Roeck]

On Mon, Sep 15, 2014 at 11:30:07AM -0700, Guenter Roeck wrote:
> On Mon, Sep 15, 2014 at 05:49:49PM +0200, Hans-Peter Nilsson wrote:
> > Following up on Jesper's reply...
> > 
> > > From: Jesper Nilsson 
> > > Date: Mon, 15 Sep 2014 16:52:03 +0200
> > 
> > > > Toolchain
> > > > 
> > > > Creating a toolchain from upstream sources required a number of patches.
> > 
> > > > - gcc 4.7.4
> > > >   Requires a backport from upstream gcc to compile.
> > > >   Later versions of gcc (4.8.3, 4.9.1) fail with internal compiler 
> > > > errors
> > > >   even after patching.
> > 
> > This sounds like PR61737 (fixed; use 4.9.2 not released yet),
> > but of course with the above sentence serving as your complete
> > bug-report (or did I miss one?) that will only be a guess.
> > 
> Confirmed; gcc 4.9.1 for crisv32 builds after applying the patch fixing
> PR61737 (and the patch to fic config.gcc) on top of gcc 4.9.1.
> 
Not-so-good update: I got the toolchain with gcc 4.9.1 to build,
but the resulting image hangs early during boot. This does not happen
if I use the toolchain with gcc 4.7.4. Guess I'll stick with that.

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

RE: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Ren, Qiaowei]

On 2014-09-15, One Thousand Gnomes wrote:
>> The base of the bounds directory is set into mm_struct during
>> PR_MPX_REGISTER command execution. This member can be used to check
>> whether one application is mpx enabled.
> 
> Not really because by the time you ask the question another thread
> might have decided to unregister it.
> 
> 
>> +int mpx_register(struct task_struct *tsk) {
>> +struct mm_struct *mm = tsk->mm;
>> +
>> +if (!cpu_has_mpx)
>> +return -EINVAL;
>> +
>> +/*
>> + * runtime in the userspace will be responsible for allocation of
>> + * the bounds directory. Then, it will save the base of the bounds
>> + * directory into XSAVE/XRSTOR Save Area and enable MPX through
>> + * XRSTOR instruction.
>> + *
>> + * fpu_xsave() is expected to be very expensive. In order to do
>> + * performance optimization, here we get the base of the bounds
>> + * directory and then save it into mm_struct to be used in future.
>> + */
>> +mm->bd_addr = task_get_bounds_dir(tsk);
>> +if (!mm->bd_addr)
>> +return -EINVAL;
> 
> What stops two threads calling this in parallel ?
>> +
>> +return 0;
>> +}
>> +
>> +int mpx_unregister(struct task_struct *tsk) {
>> +struct mm_struct *mm = current->mm;
>> +
>> +if (!cpu_has_mpx)
>> +return -EINVAL;
>> +
>> +mm->bd_addr = NULL;
> 
> or indeed calling this in parallel
> 
> What are the semantics across execve() ?
> 
This will not impact on the semantics of execve(). One runtime library for MPX 
will be provided (or merged into Glibc), and when the application starts, this 
runtime will be called to initialize MPX runtime environment, including calling 
prctl() to notify the kernel to start managing the bounds directories. You can 
see the discussion about exec(): https://lkml.org/lkml/2014/1/26/199 

It would be extremely unusual for an application to have some MPX and some 
non-MPX threads, since they would share the same address space and the non-MPX 
threads would mess up the bounds. That is to say, it looks like be unusual for 
one of these threads to call prctl() to enable or disable MPX. I guess we need 
to add some rules into documentation.

Thanks,
Qiaowei

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

Re: [PATCH v5 11/12] sched: replace capacity_factor by utilization

[Peter Zijlstra]

On Mon, Sep 15, 2014 at 03:07:44PM -0400, Nicolas Pitre wrote:
> On Mon, 15 Sep 2014, Peter Zijlstra wrote:

> Let's suppose a task running on a 1GHz CPU producing a load of 100.
> 
> The same task on a 100MHz CPU would produce a load of 1000 because that 
> CPU is 10x slower.  So to properly evaluate the load of a task when 
> moving it around, we want to normalize its load based on the CPU 
> performance.  In this case the correction factor would be 0.1.
> 
> Given those normalized loads, we need to scale CPU capacity as well.  If 
> the 1GHz CPU can handle 50 of those tasks it has a capacity of 5000.
> 
> In theory the 100MHz CPU could handle only 5 of those tasks, meaning it 
> has a normalized capacity of 500, but only if the load metric is already 
> normalized as well.
> 
> Or am I completely missing the point here?

So I was thinking of the usage as per the next patch; where we decide if
a cpu is 'full' or not based on the utilization measure. For this
measure we're not interested in inter CPU relations at all, and any use
of capacity scaling simply doesn't make sense.

But I think you asking this question shows a 'bigger' problem in that
the Changelogs are entirely failing at describing the actual problem and
proposed solution. Because if that were clear, I don't think we would be
having this particular discussion.
--
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: [f2fs-dev][PATCH 4/5] f2fs: fix to clean previous mount option when remount_fs

[Chao Yu]

Hi Gu,

> -Original Message-
> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> Sent: Tuesday, September 16, 2014 9:51 AM
> To: Chao Yu
> Cc: Jaegeuk Kim; Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev][PATCH 4/5] f2fs: fix to clean previous mount option 
> when remount_fs
> 
> Hi Yu,
> On 09/15/2014 06:04 PM, Chao Yu wrote:
> 
> > In manual of mount, we descript remount as below:
> >
> > "mount -o remount,rw /dev/foo /dir
> > After  this call all old mount options are replaced and arbitrary stuff from
> > fstab is ignored, except the loop= option which is internally generated and
> > maintained by the mount command."
> >
> > Previously f2fs do not clear up old mount options when remount_fs, so we 
> > have no
> > chance of disabling previous option (e.g. flush_merge). Fix it.
> 
> Please don't.
> "Remount" should just change what you specified and keep others unchanged.

Actually, there are two kinds of different 'remount', they are all specified in
manual of mount.
1) mount -o remount,rw /dev/foo /dir
2) mount -o remount,rw  /dir

I think 'remount' in your description is the second kind, being different from 
the
first kind in description of this patch, for the second kind remount, 'mount' 
command
can keep old options by loading them from mtab/fstab then merge them with new
specified options.

Thanks,
Yu

> The problem here is that we need to provide mount opts for disable/enable
> some features, but we missed it. So the right way is adding these opts if
> we really need them.
> 
> Thanks,
> Gu
> 
> >
> > Signed-off-by: Chao Yu 
> > ---
> >  fs/f2fs/super.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 5bb..90fcbe0 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -616,6 +616,9 @@ static int f2fs_remount(struct super_block *sb, int 
> > *flags, char *data)
> > org_mount_opt = sbi->mount_opt;
> > active_logs = sbi->active_logs;
> >
> > +   sbi->mount_opt.opt = 0;
> > +   sbi->active_logs = NR_CURSEG_TYPE;
> > +
> > /* parse mount options */
> > err = parse_options(sb, data);
> > if (err)


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

[PATCH v2 RESEND/RFC] timer: make deferrable cpu unbound timers really not bound to a cpu

[Joonwoo Park]

When a deferrable work (INIT_DEFERRABLE_WORK, etc.) is queued via
queue_delayed_work() it's probably intended to run the work item on any
CPU that isn't idle. However, we queue the work to run at a later time
by starting a deferrable timer that binds to whatever CPU the work is
queued on which is same with queue_delayed_work_on(smp_processor_id())
effectively.

As a result WORK_CPU_UNBOUND work items aren't really cpu unbound now.
In fact this is perfectly fine with UP kernel and also won't affect much a
system without dyntick with SMP kernel too as every cpus run timers
periodically.  But on SMP systems with dyntick current implementation leads
deferrable timers not very scalable because the timer's base which has
queued the deferrable timer won't wake up till next non-deferrable timer
expires even though there are possible other non idle cpus are running
which are able to run expired deferrable timers.

The deferrable work is a good example of the current implementation's
victim like below.

INIT_DEFERRABLE_WORK(, fn);
CPU 0 CPU 1
queue_delayed_work(wq, , HZ);
queue_delayed_work_on(WORK_CPU_UNBOUND);
...
__mod_timer() -> queues timer to the
 current cpu's timer
 base.
...
tick_nohz_idle_enter() -> cpu enters idle.
A second later
cpu 0 is now in idle. cpu 1 exits idle or wasn't in idle so
  now it's in active but won't
cpu 0 won't wake up till next handle cpu unbound deferrable timer
non-deferrable timer expires. as it's in cpu 0's timer base.

To make all cpu unbound deferrable timers are scalable, introduce a common
timer base which is only for cpu unbound deferrable timers to make those
are indeed cpu unbound so that can be scheduled by any of non idle cpus.
This common timer fixes scalability issue of delayed work and all other cpu
unbound deferrable timer using implementations.

CC: Thomas Gleixner 
CC: John Stultz 
CC: Tejun Heo 
Signed-off-by: Joonwoo Park 
---
 Changes in v2:
 * Use kzalloc_node()/kzalloc()

 kernel/time/timer.c | 106 +++-
 1 file changed, 80 insertions(+), 26 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index aca5dfe..5313cb0 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -93,6 +93,9 @@ struct tvec_base {
 struct tvec_base boot_tvec_bases;
 EXPORT_SYMBOL(boot_tvec_bases);
 static DEFINE_PER_CPU(struct tvec_base *, tvec_bases) = _tvec_bases;
+#ifdef CONFIG_SMP
+static struct tvec_base *tvec_base_deferral = _tvec_bases;
+#endif
 
 /* Functions below help us manage 'deferrable' flag */
 static inline unsigned int tbase_get_deferrable(struct tvec_base *base)
@@ -655,7 +658,14 @@ static inline void debug_assert_init(struct timer_list 
*timer)
 static void do_init_timer(struct timer_list *timer, unsigned int flags,
  const char *name, struct lock_class_key *key)
 {
-   struct tvec_base *base = __raw_get_cpu_var(tvec_bases);
+   struct tvec_base *base;
+
+#ifdef CONFIG_SMP
+   if (flags & TIMER_DEFERRABLE)
+   base = tvec_base_deferral;
+   else
+#endif
+   base = __raw_get_cpu_var(tvec_bases);
 
timer->entry.next = NULL;
timer->base = (void *)((unsigned long)base | flags);
@@ -777,26 +787,32 @@ __mod_timer(struct timer_list *timer, unsigned long 
expires,
 
debug_activate(timer, expires);
 
-   cpu = get_nohz_timer_target(pinned);
-   new_base = per_cpu(tvec_bases, cpu);
+#ifdef CONFIG_SMP
+   if (base != tvec_base_deferral) {
+#endif
+   cpu = get_nohz_timer_target(pinned);
+   new_base = per_cpu(tvec_bases, cpu);
 
-   if (base != new_base) {
-   /*
-* We are trying to schedule the timer on the local CPU.
-* However we can't change timer's base while it is running,
-* otherwise del_timer_sync() can't detect that the timer's
-* handler yet has not finished. This also guarantees that
-* the timer is serialized wrt itself.
-*/
-   if (likely(base->running_timer != timer)) {
-   /* See the comment in lock_timer_base() */
-   timer_set_base(timer, NULL);
-   spin_unlock(>lock);
-   base = new_base;
-   spin_lock(>lock);
-   timer_set_base(timer, base);
+   if (base != new_base) {
+   /*
+* We are trying to schedule the timer on the local CPU.
+* However we can't change timer's base while it is
+* running, otherwise del_timer_sync() can't detect that
+* the timer's handler yet has not finished. This also
+* guarantees 

[RFC PATCH for AMD Seattle 0/4] Drivers for AMD-Seatlle to boot from ACPI

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

As a follow up of the email thread:

[PATCH v3 00/17] Introduce ACPI for ARM64 based on ACPI 5.1
https://lkml.org/lkml/2014/9/1/446

Besides Hanjun Guo's patches above, these are the additional patches required
to boot AMD Seattle platform with full ACPI support:

[PATCH] efi/arm64: efistub: don't abort if base of DRAM is occupied
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/272274.html

[PATCH v2] efi/arm64: fix fdt-related memory reservation
https://lkml.org/lkml/2014/9/8/483

[PATCH] ata: ahci_platform: Add ACPI support for AMD Seattle SATA controller
https://lkml.org/lkml/2014/9/9/834

[RFC PATCH for Juno 2/2] tty: SBSA compatible UART
https://lkml.org/lkml/2014/9/1/448
(NOTE: This is not meant to be submitted upstream, but required to enable
 ACPI support for UART SBSA driver.)

These patches are rebased from the linux-3.17-rc4 upstream kernel, and 
compatible with the AMD Seattle Firmware version ROD0070C.
The full kernel boot log can be found here:

http://people.linaro.org/~al.stone/seattle-boot-acpi-dmesg.txt

Suravee / Al

Ard Biesheuvel (1):
  arm64/efi: efistub: don't abort if base of DRAM is occupied

Grame Gregory (1):
  [RFC PATCH for Juno 2/2] tty: SBSA compatible UART

Mark Salter (1):
  efi/arm64: fix fdt-related memory reservation

Suravee Suthikulpanit (1):
  ata: ahci_platform: Add ACPI support for AMD Seattle SATA controller

 arch/arm64/kernel/efi-stub.c   |  16 +-
 arch/arm64/mm/init.c   |   3 +-
 drivers/ata/Kconfig|   2 +-
 drivers/ata/ahci_platform.c|  13 ++
 drivers/firmware/efi/libstub/fdt.c |  10 +-
 drivers/tty/Kconfig|   6 +
 drivers/tty/Makefile   |   1 +
 drivers/tty/sbsauart.c | 328 +
 8 files changed, 365 insertions(+), 14 deletions(-)
 create mode 100644 drivers/tty/sbsauart.c

-- 
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 16/17] arcmsr: support new adapter ARC12x4 series

[Ching Huang]

On Mon, 2014-09-15 at 10:05 -0700, Christoph Hellwig wrote:
> On Mon, Sep 15, 2014 at 03:23:36PM +0200, Tomas Henzl wrote:
> > Christoph,
> > 
> > you may add my 'reviewed-by' to the arcmsr series
> > http://git.infradead.org/users/hch/scsi-queue.git/tree/arcmsr-for-3.18:/drivers/scsi/arcmsr
> > with the '[PATCH v5 2/2] arcmsr: simplify of updating doneq_index and 
> > postq_index'
> > ( https://lkml.org/lkml/2014/9/15/177 ) on top of the series
> > that last patch fixes the 16/17 from your git.
> > I hope the series is an iteration in the right direction.
> > Skip the the '[PATCH v4 1/2] arcmsr: simplify ioctl data read/write', Ching 
> > will repost it later.
> 
> Thanks a lot Tomas for all the review, and thanks Ching for the patches
> and updates.  I'll merge the branch and the additional patch today.
> 

Christoph,

The [PATCH v5 2/2] was depend on [PATCH v4 1/2].
If you skip patch 1/2, then patch 2/2 may cause line number mismatch.
How should I do? Please advise.



--
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] zsmalloc: simplify init_zspage free obj linking

[Minchan Kim]

On Mon, Sep 15, 2014 at 04:58:50PM -0400, Dan Streetman wrote:
> Change zsmalloc init_zspage() logic to iterate through each object on
> each of its pages, checking the offset to verify the object is on the
> current page before linking it into the zspage.
> 
> The current zsmalloc init_zspage free object linking code has logic
> that relies on there only being one page per zspage when PAGE_SIZE
> is a multiple of class->size.  It calculates the number of objects
> for the current page, and iterates through all of them plus one,
> to account for the assumed partial object at the end of the page.
> While this currently works, the logic can be simplified to just
> link the object at each successive offset until the offset is larger
> than PAGE_SIZE, which does not rely on PAGE_SIZE being a multiple of
> class->size.
> 
> Signed-off-by: Dan Streetman 
> Cc: Minchan Kim 
Acked-by: Minchan Kim 

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

Re: [PATCH v3] ARM: apq8064: Add pinmux and i2c pinctrl nodes

[Andy Gross]

On Tue, Aug 26, 2014 at 05:00:45PM +0530, Kiran Padwal wrote:
> This patch adds pinmux and i2c pinctrl DT node for IFC6410 board.
> It also adds necessary DT support for i2c eeprom which is present on
> IFC6410.
> 
> Tested on IFC6410 board.

Looks fine

> 
> Signed-off-by: Kiran Padwal 
> ---
> Changes since v2:
>  - Renamed pinmux i2c subnode "i2c1_pinmux" to "i2c1".
>  - Removed labes of node.
>  - Used canonical value as "okay" instead of "ok".
>  - Used macros.
> 
> Changes since v1:
>  - Renamed pinmux phandle "qcom_pinmux" to "tlmm_pinmux".
>  - Updated pinmux interrupt.
> 
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   27 ++
>  arch/arm/boot/dts/qcom-apq8064.dtsi|   53 
> 
>  2 files changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 7c2441d..ef0857e 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -5,6 +5,24 @@
>   compatible = "qcom,apq8064-ifc6410", "qcom,apq8064";
>  
>   soc {
> + gsbi@1244 {
> + status = "okay";
> + qcom,mode = ;
> +
> + i2c@1246 {
> + status = "okay";
> + clock-frequency = <20>;
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + eeprom: eeprom@52 {
> + compatible = "atmel,24c128";
> + reg = <0x52>;
> + pagesize = <32>;
> + };

don't need read only here.  the eeprom is not being used by anything
thankfully.

> + };
> + };
> +
>   gsbi@1660 {
>   status = "ok";
>   qcom,mode = ;
> @@ -12,5 +30,14 @@
>   status = "ok";
>   };
>   };
> +
> + pinmux@80 {
> + i2c1_pins: i2c1 {
> + mux {
> + pins = "gpio20", "gpio21";
> + function = "gsbi1";
> + };
> + };
> + };
>   };
>  };
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 92bf793..5dddbf3 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -89,6 +89,17 @@
>   cpu-offset = <0x8>;
>   };
>  
> + tlmm_pinmux: pinmux@80 {
> + compatible = "qcom,apq8064-pinctrl";
> + reg = <0x80 0x4000>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <0 16 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
>   acc0: clock-controller@2088000 {
>   compatible = "qcom,kpss-acc-v1";
>   reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
> @@ -133,6 +144,48 @@
>   regulator;
>   };
>  
> + gsbi1: gsbi@1244 {
> + status = "disabled";
> + compatible = "qcom,gsbi-v1.0.0";
> + reg = <0x1244 0x100>;
> + clocks = < GSBI1_H_CLK>;
> + clock-names = "iface";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + i2c1: i2c@1246 {
> + compatible = "qcom,i2c-qup-v1.1.1";
> + reg = <0x1246 0x1000>;
> + interrupts = <0 194 IRQ_TYPE_NONE>;
> + clocks = < GSBI1_QUP_CLK>, < 
> GSBI1_H_CLK>;
> + clock-names = "core", "iface";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + gsbi2: gsbi@1248 {
> + status = "disabled";
> + compatible = "qcom,gsbi-v1.0.0";
> + reg = <0x1248 0x100>;
> + clocks = < GSBI2_H_CLK>;
> + clock-names = "iface";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + i2c2: i2c@124a {
> + compatible = "qcom,i2c-qup-v1.1.1";
> + reg = <0x124a 0x1000>;
> +  

[PULL] virtio fixes

[Rusty Russell]

The following changes since commit 7ec62d421bdf29cb31101ae2689f7f3a9906289a:

  Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2014-09-10 
14:04:17 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git 
tags/fixes-for-linus

for you to fetch changes up to f49819560f53b7f3a596a8ea2e6764dc86695b62:

  virtio-rng: skip reading when we start to remove the device (2014-09-11 
22:28:38 +0930)


virtio-rng corner case fixes, with cc:stable.
Survived a few days in linux-next.


Amos Kong (2):
  virtio-rng: fix stuck of hot-unplugging busy device
  virtio-rng: skip reading when we start to remove the device

 drivers/char/hw_random/virtio-rng.c | 7 +++
 1 file changed, 7 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] virtio_net: pass well-formed sgs to virtqueue_add_*()

[Rusty Russell]

David Miller  writes:
> From: Rusty Russell 
> Date: Sat, 13 Sep 2014 15:10:03 +0930
>
>> David Miller  writes:
>>> Do you guys want me to take this series directly into net-next?
>> 
>> Actually, yes.  Since I'm going to be travelling, that makes it much
>> easier for me.  And no other patches I have depend on it.
>
> Series applied, but can you be more careful when you hand edit patches
> or whatever you are doing that puts space characters at the beginning
> of lines before TAB characters?
>
> GIT flags this immediately, so even if you are hella lazy just feeding
> your patches into "git am" will show this.

Hmm, that was weird, thanks for the warning.  This patch is pretty old,
so maybe I did hand-hack it at one stage.

Cheers,
Rusty.
--
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/4] efi/arm64: fix fdt-related memory reservation

[suravee.suthikulpanit]

From: Mark Salter 

Commit 86c8b27a01cf:
 "arm64: ignore DT memreserve entries when booting in UEFI mode

prevents early_init_fdt_scan_reserved_mem() from being called for
arm64 kernels booting via UEFI. This was done because the kernel
will use the UEFI memory map to determine reserved memory regions.
That approach has problems in that early_init_fdt_scan_reserved_mem()
also reserves the FDT itself and any node-specific reserved memory.
By chance of some kernel configs, the FDT may be overwritten before
it can be unflattened and the kernel will fail to boot. More subtle
problems will result if the FDT has node specific reserved memory
which is not really reserved.

This patch has the UEFI stub remove the memory reserve map entries
from the FDT as it does with the memory nodes. This allows
early_init_fdt_scan_reserved_mem() to be called unconditionally
so that the other needed reservations are made.

Signed-off-by: Mark Salter 
---
 arch/arm64/mm/init.c   |  3 +--
 drivers/firmware/efi/libstub/fdt.c | 10 +-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..a83061f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -149,8 +149,7 @@ void __init arm64_memblock_init(void)
memblock_reserve(__virt_to_phys(initrd_start), initrd_end - 
initrd_start);
 #endif
 
-   if (!efi_enabled(EFI_MEMMAP))
-   early_init_fdt_scan_reserved_mem();
+   early_init_fdt_scan_reserved_mem();
 
/* 4GB maximum for 32-bit only capable devices */
if (IS_ENABLED(CONFIG_ZONE_DMA))
diff --git a/drivers/firmware/efi/libstub/fdt.c 
b/drivers/firmware/efi/libstub/fdt.c
index a56bb35..c846a96 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -22,7 +22,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void 
*orig_fdt,
unsigned long map_size, unsigned long desc_size,
u32 desc_ver)
 {
-   int node, prev;
+   int node, prev, num_rsv;
int status;
u32 fdt_val32;
u64 fdt_val64;
@@ -73,6 +73,14 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void 
*orig_fdt,
prev = node;
}
 
+   /*
+* Delete all memory reserve map entries. When booting via UEFI,
+* kernel will use the UEFI memory map to find reserved regions.
+*/
+   num_rsv = fdt_num_mem_rsv(fdt);
+   while (num_rsv-- > 0)
+   fdt_del_mem_rsv(fdt, num_rsv);
+
node = fdt_subnode_offset(fdt, 0, "chosen");
if (node < 0) {
node = fdt_add_subnode(fdt, 0, "chosen");
-- 
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/4] arm64/efi: efistub: don't abort if base of DRAM is occupied

[suravee.suthikulpanit]

From: Ard Biesheuvel 

If we cannot relocate the kernel Image to its preferred offset of base of DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
proceed normally otherwise.

Acked-by: Mark Salter 
Acked-by: Mark Rutland 
Acked-by: Leif Lindholm 
Tested-by: Leif Lindholm 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
---
 arch/arm64/kernel/efi-stub.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
index 1317fef..d27dd98 100644
--- a/arch/arm64/kernel/efi-stub.c
+++ b/arch/arm64/kernel/efi-stub.c
@@ -28,20 +28,16 @@ efi_status_t handle_kernel_image(efi_system_table_t 
*sys_table,
kernel_size = _edata - _text;
if (*image_addr != (dram_base + TEXT_OFFSET)) {
kernel_memsize = kernel_size + (_end - _edata);
-   status = efi_relocate_kernel(sys_table, image_addr,
-kernel_size, kernel_memsize,
-dram_base + TEXT_OFFSET,
-PAGE_SIZE);
+   status = efi_low_alloc(sys_table, kernel_memsize + TEXT_OFFSET,
+  SZ_2M, reserve_addr);
if (status != EFI_SUCCESS) {
pr_efi_err(sys_table, "Failed to relocate kernel\n");
return status;
}
-   if (*image_addr != (dram_base + TEXT_OFFSET)) {
-   pr_efi_err(sys_table, "Failed to alloc kernel 
memory\n");
-   efi_free(sys_table, kernel_memsize, *image_addr);
-   return EFI_LOAD_ERROR;
-   }
-   *image_size = kernel_memsize;
+   memcpy((void *)*reserve_addr + TEXT_OFFSET, (void *)*image_addr,
+  kernel_size);
+   *image_addr = *reserve_addr + TEXT_OFFSET;
+   *reserve_size = kernel_memsize + TEXT_OFFSET;
}
 
 
-- 
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 4/4] [RFC PATCH for Juno 2/2] tty: SBSA compatible UART

[suravee.suthikulpanit]

From: Grame Gregory 

This is a subset of pl011 UART which does not supprt DMA or baud rate
changing.

It is specified in the Server Base System Architecture document from
ARM.

Signed-off-by: Graeme Gregory 
---
 drivers/tty/Kconfig|   6 +
 drivers/tty/Makefile   |   1 +
 drivers/tty/sbsauart.c | 328 +
 3 files changed, 335 insertions(+)
 create mode 100644 drivers/tty/sbsauart.c

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b24aa01..50fe279 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -419,4 +419,10 @@ config DA_CONSOLE
help
  This enables a console on a Dash channel.
 
+config SBSAUART_TTY
+   tristate "SBSA UART TTY Driver"
+   help
+ Console and system TTY driver for the SBSA UART which is defined
+ in the Server Base System Architecure document for ARM64 servers.
+
 endif # TTY
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 58ad1c0..c3211c0 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_SYNCLINK)+= synclink.o
 obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
 obj-$(CONFIG_GOLDFISH_TTY) += goldfish.o
 obj-$(CONFIG_DA_TTY)   += metag_da.o
+obj-$(CONFIG_SBSAUART_TTY) += sbsauart.o
 
 obj-y += ipwireless/
diff --git a/drivers/tty/sbsauart.c b/drivers/tty/sbsauart.c
new file mode 100644
index 000..c9bf923
--- /dev/null
+++ b/drivers/tty/sbsauart.c
@@ -0,0 +1,328 @@
+/*
+ * SBSA (Server Base System Architecture) Compatible UART driver
+ *
+ * Copyright (C) 2014 Linaro Ltd
+ *
+ * Author: Graeme Gregory 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sbsa_tty {
+   struct tty_port port;
+   spinlock_t lock;
+   void __iomem *base;
+   u32 irq;
+   int opencount;
+   struct console console;
+};
+
+static struct tty_driver *sbsa_tty_driver;
+static struct sbsa_tty *sbsa_tty;
+
+#define SBSAUART_CHAR_MASK 0xFF
+
+static void sbsa_tty_do_write(const char *buf, unsigned count)
+{
+   unsigned long irq_flags;
+   struct sbsa_tty *qtty = sbsa_tty;
+   void __iomem *base = qtty->base;
+   unsigned n;
+
+   spin_lock_irqsave(>lock, irq_flags);
+   for (n = 0; n < count; n++) {
+   while (readw(base + UART01x_FR) & UART01x_FR_TXFF)
+   mdelay(10);
+   writew(buf[n], base + UART01x_DR);
+   }
+   spin_unlock_irqrestore(>lock, irq_flags);
+}
+
+static void sbsauart_fifo_to_tty(struct sbsa_tty *qtty)
+{
+   void __iomem *base = qtty->base;
+   unsigned int flag, max_count = 32;
+   u16 status, ch;
+
+   while (max_count--) {
+   status = readw(base + UART01x_FR);
+   if (status & UART01x_FR_RXFE)
+   break;
+
+   /* Take chars from the FIFO and update status */
+   ch = readw(base + UART01x_DR);
+   flag = TTY_NORMAL;
+
+   if (ch & UART011_DR_BE)
+   flag = TTY_BREAK;
+   else if (ch & UART011_DR_PE)
+   flag = TTY_PARITY;
+   else if (ch & UART011_DR_FE)
+   flag = TTY_FRAME;
+   else if (ch & UART011_DR_OE)
+   flag = TTY_OVERRUN;
+
+   ch &= SBSAUART_CHAR_MASK;
+
+   tty_insert_flip_char(>port, ch, flag);
+   }
+
+   tty_schedule_flip(>port);
+
+   /* Clear the RX IRQ */
+   writew(UART011_RXIC | UART011_RXIC, base + UART011_ICR);
+}
+
+static irqreturn_t sbsa_tty_interrupt(int irq, void *dev_id)
+{
+   struct sbsa_tty *qtty = sbsa_tty;
+   unsigned long irq_flags;
+
+   spin_lock_irqsave(>lock, irq_flags);
+   sbsauart_fifo_to_tty(qtty);
+   spin_unlock_irqrestore(>lock, irq_flags);
+
+   return IRQ_HANDLED;
+}
+
+static int sbsa_tty_open(struct tty_struct *tty, struct file *filp)
+{
+   struct sbsa_tty *qtty = sbsa_tty;
+
+   return tty_port_open(>port, tty, filp);
+}
+
+static void sbsa_tty_close(struct tty_struct *tty, struct file *filp)
+{
+   tty_port_close(tty->port, tty, filp);
+}
+
+static void sbsa_tty_hangup(struct tty_struct *tty)
+{
+   tty_port_hangup(tty->port);
+}
+
+static int sbsa_tty_write(struct tty_struct *tty, const unsigned char *buf,
+   int count)
+{
+   

[PATCH 1/4] ata: ahci_platform: Add ACPI support for AMD Seattle SATA controller

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

This patch adds ACPI match table in ahci_platform. The table includes
the acpi_device_id to match AMD Seattle SATA controller with following
asl structure in DSDT:

Device (SATA0)
{
  Name(_HID, "AMDI0600")// Seattle AHSATA
  Name (_CCA, 1)// Cache-coherent controller
  Name (_CRS, ResourceTemplate ()
  {
Memory32Fixed (ReadWrite, 0xE030, 0x0001)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,,,) { 387 }
  })
}

Also, since ATA driver should not require PCI support for ATA_ACPI,
this patch removes dependency in the driver/ata/Kconfig.
---
 drivers/ata/Kconfig |  2 +-
 drivers/ata/ahci_platform.c | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index e1b9278..f2e6c9e 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -48,7 +48,7 @@ config ATA_VERBOSE_ERROR
 
 config ATA_ACPI
bool "ATA ACPI Support"
-   depends on ACPI && PCI
+   depends on ACPI
default y
help
  This option adds support for ATA-related ACPI objects.
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index f61ddb9..3499bab 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -20,6 +20,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_ATA_ACPI
+#include 
+#endif
 #include "ahci.h"
 
 static const struct ata_port_info ahci_port_info = {
@@ -87,6 +90,13 @@ static const struct of_device_id ahci_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
 
+#ifdef CONFIG_ATA_ACPI
+static const struct acpi_device_id ahci_acpi_match[] = {
+   { "AMDI0600", 0 }, /* AMD Seattle AHCI */
+   { },
+};
+#endif
+
 static struct platform_driver ahci_driver = {
.probe = ahci_probe,
.remove = ata_platform_remove_one,
@@ -94,6 +104,9 @@ static struct platform_driver ahci_driver = {
.name = "ahci",
.owner = THIS_MODULE,
.of_match_table = ahci_of_match,
+#ifdef CONFIG_ATA_ACPI
+   .acpi_match_table = ACPI_PTR(ahci_acpi_match),
+#endif
.pm = _pm_ops,
},
 };
-- 
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 0/4] drivers/bus: Freescale Management Complex bus driver patch series

[Kim Phillips]

On Thu, 11 Sep 2014 12:34:20 -0500
"J. German Rivera"  wrote:

> This patch series introduces Linux support for the Freescale
> Management Complex (fsl-mc) hardware.

here are the results of using some tools to check this patchseries:

make C=1 CF="-D__CHECK_ENDIAN__":

drivers/bus/fsl-mc/fsl_mc_sys.c:235:9: warning: context imbalance in 
'mc_send_command' - different lock contexts for basic block
drivers/bus/fsl-mc/fsl_mc_dprc.c: In function 'dprc_add_new_devices':
drivers/bus/fsl-mc/fsl_mc_dprc.c:173:6: warning: format '%lu' expects argument 
of type 'long unsigned int', but argument 3 has type 'uint32_t' [-Wformat=]
  region_desc.size);
  ^

When built as a module (CONFIG_FSL_MC_BUS=m):

ERROR: ".dprc_get_obj" [drivers/bus/fsl-mc/fsl_mc_dprc.ko] undefined!
ERROR: ".dprc_get_obj_count" [drivers/bus/fsl-mc/fsl_mc_dprc.ko] undefined!
ERROR: ".dprc_close" [drivers/bus/fsl-mc/fsl_mc_dprc.ko] undefined!
ERROR: ".dprc_open" [drivers/bus/fsl-mc/fsl_mc_dprc.ko] undefined!
ERROR: ".dprc_get_obj_region" [drivers/bus/fsl-mc/fsl_mc_dprc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

checkpatch:

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?

WARNING: DT compatible string "fsl,qoriq-mc" appears un-documented -- check 
./Documentation/devicetree/bindings/
#690: FILE: drivers/bus/fsl-mc/fsl_mc_bus.c:528:
+   {.compatible = "fsl,qoriq-mc",},

For the former warning, I'd suggest moving patch 4/4's contents up
in the series.

For the latter warning, googling for the property shows an upstream
effort, so it might be ok, but it'd be nice to provide a
cross-reference to the status of the latest post, to make it easier
for reviewer consumption.

Also, I think you'd get more recipient coverage by using
scripts/get_maintainer.pl.

Thanks,

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/

Re: [PATCH 0/6] KEYS: Miscellaneous fixes

[James Morris]

On Mon, 15 Sep 2014, David Howells wrote:

> Hi James,
> 
> Thanks for pushing the first patch.  Any thoughts on what to do with the
> remaining patches?  #5 and #6 at least ought to go upstream as there's a
> potential memory leak fixed and #2 because the keyutils testsuite is failing
> without it.  From what Mimi says, I think she's withdrawn her objection to #2.

Can you split your pull requests into different branches -- one which is 
for current upstream, and one which is for next?


-- 
James Morris


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

[PATCH V4] ASoC: fsl_ssi: refine ipg clock usage in this module

[Shengjiu Wang]

Check if ipg clock is in clock-names property, then we can move the
ipg clock enable and disable operation to startup and shutdown, that
is only enable ipg clock when ssi is working and keep clock is disabled
when ssi is in idle.
But when the checking is failed, remain the clock control as before.

Tested-by: Markus Pargmann 
Signed-off-by: Shengjiu Wang 
---
v4 change log:
fix the code indent issue.

 sound/soc/fsl/fsl_ssi.c |   53 ---
 1 file changed, 45 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 2fc3e66..16a1361 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -169,6 +169,7 @@ struct fsl_ssi_private {
u8 i2s_mode;
bool use_dma;
bool use_dual_fifo;
+   bool has_ipg_clk_name;
unsigned int fifo_depth;
struct fsl_ssi_rxtx_reg_val rxtx_reg_val;
 
@@ -530,6 +531,11 @@ static int fsl_ssi_startup(struct snd_pcm_substream 
*substream,
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct fsl_ssi_private *ssi_private =
snd_soc_dai_get_drvdata(rtd->cpu_dai);
+   int ret;
+
+   ret = clk_prepare_enable(ssi_private->clk);
+   if (ret)
+   return ret;
 
/* When using dual fifo mode, it is safer to ensure an even period
 * size. If appearing to an odd number while DMA always starts its
@@ -544,6 +550,21 @@ static int fsl_ssi_startup(struct snd_pcm_substream 
*substream,
 }
 
 /**
+ * fsl_ssi_shutdown: shutdown the SSI
+ *
+ */
+static void fsl_ssi_shutdown(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct fsl_ssi_private *ssi_private =
+   snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+   clk_disable_unprepare(ssi_private->clk);
+
+}
+
+/**
  * fsl_ssi_set_bclk - configure Digital Audio Interface bit clock
  *
  * Note: This function can be only called when using SSI as DAI master
@@ -1043,6 +1064,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
 
 static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
.startup= fsl_ssi_startup,
+   .shutdown   = fsl_ssi_shutdown,
.hw_params  = fsl_ssi_hw_params,
.hw_free= fsl_ssi_hw_free,
.set_fmt= fsl_ssi_set_dai_fmt,
@@ -1168,17 +1190,22 @@ static int fsl_ssi_imx_probe(struct platform_device 
*pdev,
u32 dmas[4];
int ret;
 
-   ssi_private->clk = devm_clk_get(>dev, NULL);
+   if (ssi_private->has_ipg_clk_name)
+   ssi_private->clk = devm_clk_get(>dev, "ipg");
+   else
+   ssi_private->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(ssi_private->clk)) {
ret = PTR_ERR(ssi_private->clk);
dev_err(>dev, "could not get clock: %d\n", ret);
return ret;
}
 
-   ret = clk_prepare_enable(ssi_private->clk);
-   if (ret) {
-   dev_err(>dev, "clk_prepare_enable failed: %d\n", ret);
-   return ret;
+   if (!ssi_private->has_ipg_clk_name) {
+   ret = clk_prepare_enable(ssi_private->clk);
+   if (ret) {
+   dev_err(>dev, "clk_prepare_enable failed: %d\n", 
ret);
+   return ret;
+   }
}
 
/* For those SLAVE implementations, we ingore non-baudclk cases
@@ -1236,8 +1263,9 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
return 0;
 
 error_pcm:
-   clk_disable_unprepare(ssi_private->clk);
 
+   if (!ssi_private->has_ipg_clk_name)
+   clk_disable_unprepare(ssi_private->clk);
return ret;
 }
 
@@ -1246,7 +1274,8 @@ static void fsl_ssi_imx_clean(struct platform_device 
*pdev,
 {
if (!ssi_private->use_dma)
imx_pcm_fiq_exit(pdev);
-   clk_disable_unprepare(ssi_private->clk);
+   if (!ssi_private->has_ipg_clk_name)
+   clk_disable_unprepare(ssi_private->clk);
 }
 
 static int fsl_ssi_probe(struct platform_device *pdev)
@@ -1321,8 +1350,16 @@ static int fsl_ssi_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   ssi_private->regs = devm_regmap_init_mmio(>dev, iomem,
+   ret = of_property_match_string(np, "clock-names", "ipg");
+   if (ret < 0) {
+   ssi_private->has_ipg_clk_name = false;
+   ssi_private->regs = devm_regmap_init_mmio(>dev, iomem,
_ssi_regconfig);
+   } else {
+   ssi_private->has_ipg_clk_name = true;
+   ssi_private->regs = devm_regmap_init_mmio_clk(>dev,
+   "ipg", iomem, _ssi_regconfig);
+   }
if (IS_ERR(ssi_private->regs)) {
dev_err(>dev, "Failed to init register map\n");
return PTR_ERR(ssi_private->regs);
-- 
1.7.9.5

--
To 

Re: [PATCH v2 0/7] mtd: denali: A collection of trivial coding style fixes

[Masahiro Yamada]

Hi Brian,




On Mon, 15 Sep 2014 17:36:20 -0700
Brian Norris  wrote:

> On Tue, Sep 09, 2014 at 11:01:50AM +0900, Masahiro Yamada wrote:
> > Changes in v2:
> >   - Join quotes strings into a single line
> > 
> > Masahiro Yamada (7):
> >   mtd: denali: fix the format of comment blocks
> >   mtd: denali: remove unnecessary variable initializations
> >   mtd: denali: remove unnecessary casts
> >   mtd: denali: change the type of iterators to int
> >   mtd: denali: remove a set-but-unused variable
> >   mtd: denali: remove unnecessary parentheses
> >   mtd: denali: fix indents and other trivial things
> > 
> >  drivers/mtd/nand/denali.c | 562 
> > +-
> >  1 file changed, 303 insertions(+), 259 deletions(-)
> 
> Pushed patches 1 to 5 to l2-mtd.git. Thanks!
> 
> Patch 6 has a conflict with another fix already in l2-mtd.git. Can you
> rebase and resend?


Sorry for my ignorance, but where can I find l2-mtd.git?

In my understanding, the subsystem repositories should be documented
in MAINTAINERS, so I looked for it but just found
T:git git://git.infradead.org/linux-mtd.git.
I do not think it is the one you mentioned.



> BTW, my automatic build tests show that there's at least one other
> 'unused' warning left, in case you want to tackle it too:
> 
> drivers/mtd/nand/denali.c: In function ‘denali_read_page_raw’:
> drivers/mtd/nand/denali.c:1221:11: warning: variable ‘irq_status’ set but 
> not used [-Wunused-but-set-variable]
>   uint32_t irq_status;
> 

You are right.
(What is odd enough is this warning was not displayed on my build test.
I do not know why.)

Is there a chance for me to resend 5/7 to include this fix?
Or is it too late?


Best Regards
Masahiro Yamada

--
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] ahci-platform: Bump max number of clocks to 5

[Kumar Gala]

On Sep 9, 2014, at 8:36 AM, Kumar Gala  wrote:

> Qualcomm IPQ806x SoCs with SATA controllers need 5 clocks to be enabled.
> 
> Signed-off-by: Kumar Gala 
> ---
> (reposted with Hans on list)
> 
> v4:
> * Updated to upstream changes
> 
> drivers/ata/ahci.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

Any updates on these patches?

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
The Linux Foundation

--
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/8] arm: mach-imx: Convert pr_warning to pr_warn

[Shawn Guo]

On Sat, Sep 13, 2014 at 11:31:15AM -0700, Joe Perches wrote:
> Use the more common pr_warn.
> 
> Signed-off-by: Joe Perches 

Applied, 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: [f2fs-dev][PATCH 4/5] f2fs: fix to clean previous mount option when remount_fs

[Gu Zheng]

Hi Yu,
On 09/15/2014 06:04 PM, Chao Yu wrote:

> In manual of mount, we descript remount as below:
> 
> "mount -o remount,rw /dev/foo /dir
> After  this call all old mount options are replaced and arbitrary stuff from
> fstab is ignored, except the loop= option which is internally generated and
> maintained by the mount command."
> 
> Previously f2fs do not clear up old mount options when remount_fs, so we have 
> no
> chance of disabling previous option (e.g. flush_merge). Fix it.

Please don't.
"Remount" should just change what you specified and keep others unchanged.
The problem here is that we need to provide mount opts for disable/enable
some features, but we missed it. So the right way is adding these opts if
we really need them.

Thanks,
Gu

> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/super.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 5bb..90fcbe0 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -616,6 +616,9 @@ static int f2fs_remount(struct super_block *sb, int 
> *flags, char *data)
>   org_mount_opt = sbi->mount_opt;
>   active_logs = sbi->active_logs;
>  
> + sbi->mount_opt.opt = 0;
> + sbi->active_logs = NR_CURSEG_TYPE;
> +
>   /* parse mount options */
>   err = parse_options(sb, data);
>   if (err)


--
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] usb: gadget: udc_core: Use right kobj when calling sysfs_notify

[Peter Chen]

On Mon, Sep 15, 2014 at 12:42:27PM +0200, Andreas Larsson wrote:
> The state attribute is connected to the kobj of the udc, not the gadget.
> 
> Signed-off-by: Andreas Larsson 
> ---
>  drivers/usb/gadget/udc/udc-core.c |   14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/udc/udc-core.c 
> b/drivers/usb/gadget/udc/udc-core.c
> index b0d9817..37c129a 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -109,8 +109,20 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
>  static void usb_gadget_state_work(struct work_struct *work)
>  {
>   struct usb_gadget   *gadget = work_to_gadget(work);
> + struct usb_udc  *udc = NULL;
> +
> + mutex_lock(_lock);
> + list_for_each_entry(udc, _list, list)
> + if (udc->gadget == gadget)
> + goto found;
> + mutex_unlock(_lock);
> +
> + return;
> +
> +found:
> + mutex_unlock(_lock);
>  
> - sysfs_notify(>dev.kobj, NULL, "state");
> + sysfs_notify(>dev.kobj, NULL, "state");
>  }
>  
>  void usb_gadget_set_state(struct usb_gadget *gadget,

What's the user mode difference with and without this patch?

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

Re: [PATCH 3.16 000/158] 3.16.3-stable review

[Guenter Roeck]

On 09/15/2014 12:23 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.16.3 release.
There are 158 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 17 19:25:26 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 136 pass: 136 fail: 0

Qemu test results:
total: 24 pass: 24 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

Re: [PATCH 3.14 000/114] 3.14.19-stable review

[Guenter Roeck]

On 09/15/2014 12:25 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.14.19 release.
There are 114 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 17 19:26:26 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0

Qemu test results:
total: 24 pass: 24 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

Re: [PATCH 3.10 00/71] 3.10.55-stable review

[Guenter Roeck]

On 09/15/2014 12:25 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.10.55 release.
There are 71 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 17 19:26:27 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0

Qemu test results:
total: 21 pass: 21 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

--
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:free_initrd_mem should also free the memblock

[Wang, Yalin]

Hi

The reason that a want merge this patch is that
It confuse me when I debug memory issue by 
/sys/kernel/debug/memblock/reserved  debug file,
It show lots of un-correct reserved memory.
In fact, I also send a patch to cma driver part
For this issue too:
http://ozlabs.org/~akpm/mmots/broken-out/free-the-reserved-memblock-when-free-cma-pages.patch

I want to remove these un-correct memblock parts as much as possible,
so that I can see more correct info from /sys/kernel/debug/memblock/reserved
debug file .

Thanks



-Original Message-

On Mon, Sep 15, 2014 at 07:40:23PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 15, 2014 at 07:33:34PM +0100, Will Deacon wrote:
> > On Fri, Sep 12, 2014 at 11:17:18AM +0100, Wang, Yalin wrote:
> > > this patch fix the memblock statics for memblock in file 
> > > /sys/kernel/debug/memblock/reserved
> > > if we don't call memblock_free the initrd will still be marked as 
> > > reserved, even they are freed.
> > > 
> > > Signed-off-by: Yalin Wang 
> > > ---
> > >  arch/arm64/mm/init.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 
> > > 5472c24..34605c8 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -334,8 +334,10 @@ static int keep_initrd;
> > >  
> > >  void free_initrd_mem(unsigned long start, unsigned long end)  {
> > > - if (!keep_initrd)
> > > + if (!keep_initrd) {
> > >   free_reserved_area((void *)start, (void *)end, 0, "initrd");
> > > + memblock_free(__pa(start), end - start);
> > > + }
> > 
> > I don't think it makes any technical difference, but doing the 
> > memblock_free before the free_reserved_area makes more sense to me.
> 
> A better question is... should we even be doing this.  The memblock 
> information is used as a method to bring up the kernel and provide 
> early allocation.  Once the memory is handed over from memblock to the 
> normal kernel page allocators, we no longer care what happens to 
> memblock.
> 
> There is no need to free the initrd memory back into memblock.  In 
> fact, seeing the initrd location in 
> /sys/kernel/debug/memblock/reserved
> can be useful debug information in itself.

That's a fair point. Yang: do you have a specific use-case in mind for this?

I wondered if it might interact with our pfn_valid implementation, which uses 
memblock_is_memory, however memblock_free only deals with the reserved regions, 
so I now I can't see why this change is required either.

Will
--
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: [3.13.y.z extended stable] Linux 3.13.11.7 stable review

[Tim Gardner]

On 09/15/2014 06:03 PM, Greg KH wrote:
> On Mon, Sep 15, 2014 at 03:06:50PM -0700, Kamal Mostafa wrote:
>> This is the start of the review cycle for the Linux 3.13.11.7 stable kernel.
>>
>> This version contains 187 new patches, summarized below.  The new patches are
>> posted as replies to this message and also available in this git branch:
>>
>> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=linux-3.13.y-review;a=shortlog
>>
>> git://kernel.ubuntu.com/ubuntu/linux.git  linux-3.13.y-review
>>
>> The review period for version 3.13.11.7 will be open for the next three days.
>> To report a problem, please reply to the relevant follow-up patch message.
> 
> As I asked before, please change the name to not be x.y, it is confusing
> for lots of people.
> 
> Use the "normal" way of naming kernel releases, pick a few character
> naming scheme please.
> 

I think what Kamal said is that he would consider your request. I,
however, don't think it wise to change version schemes mid-stream in an
established series.

Can you provide hard evidence that this version scheme is confusing lots
of people ? I'm only aware of one complaint voiced by Peter Anvin at the
kernel summit (http://lwn.net/Articles/608917/).

rtg
-- 
Tim Gardner tim.gard...@canonical.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: [alsa-devel] [PATCH v2 2/4] ARM: dts: pbab01: enable I2S audio on phyFLEX-i.MX6 boards

[Shawn Guo]

On Mon, Sep 15, 2014 at 03:07:02PM +0300, Dmitry Lavnikevich wrote:
> On 12/09/14 19:40, Fabio Estevam wrote:
> >On Fri, Sep 12, 2014 at 1:26 PM, Alexander Shiyan  wrote:
> >>Fri, 12 Sep 2014 19:04:30 +0300 от Dmitry Lavnikevich 
> >>:
> >>>Audio on phyFLEX boards is presented by tlv320aic3007 codec connected
> >>>over SSI interface.
> >>>
> >>>Signed-off-by: Dmitry Lavnikevich 
> >>>---
> >>...
> >>>+ {
> >>>+ fsl,mode = "i2s-slave";
> >>>+ status = "okay";
> >>>+ #sound-dai-cells = <0>;
> >>>+};
> >>I have already sent patch to add "#sound-dai-cells" into all i.MX DT-files.
> >>Shawn, can you point us to this tree/commit?
> >https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=36c7e8826cf32dd4dd34c71b526653b800414355
> So should I base my next patchset on for-next branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> ?

Yes, please.

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

[PATCH v2] arm:extend __init_end to a page align address

[Wang, Yalin]

this patch change the __init_end address to a
page align address, so that free_initmem() can
free the whole .init section, because if the end
address is not page aligned, it will round down to
a page align address, then the tail unligned page
will not be freed.

Signed-off-by: wang 
---
 arch/arm/kernel/vmlinux.lds.S | 2 +-
 arch/arm64/kernel/vmlinux.lds.S   | 2 +-
 include/asm-generic/vmlinux.lds.h | 2 ++
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 6f57cb9..8e95aa4 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -219,8 +219,8 @@ SECTIONS
__data_loc = ALIGN(4);  /* location in binary */
. = PAGE_OFFSET + TEXT_OFFSET;
 #else
-   __init_end = .;
. = ALIGN(THREAD_SIZE);
+   __init_end = .;
__data_loc = .;
 #endif
 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 97f0c04..edf8715 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -97,9 +97,9 @@ SECTIONS
 
PERCPU_SECTION(64)
 
+   . = ALIGN(PAGE_SIZE);
__init_end = .;
 
-   . = ALIGN(PAGE_SIZE);
_data = .;
_sdata = .;
RW_DATA_SECTION(64, PAGE_SIZE, THREAD_SIZE)
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 5ba0360..aa70cbd 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -40,6 +40,8 @@
  * }
  *
  * [__init_begin, __init_end] is the init section that may be freed after init
+ * // __init_begin and __init_end should be page aligned, so that we can
+ * // free the whole .init memory
  * [_stext, _etext] is the text section
  * [_sdata, _edata] is the data section
  *
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: imx6dl: disable dma support for spi on i.mx6dl

[Shawn Guo]

On Mon, Sep 15, 2014 at 11:41:13AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 10.09.2014, 13:30 +0800 schrieb Robin Gong:
> > There is one weird data in rxfifo after one full rx/tx transfer
> > done sometimes. It looks a design issue and hard to workaround
> > totally, so disable dma functhion here. And will re-enable it
> > once the root cause found.
> > 
> Sorry, I'm late to this as Shawn seems to already have picked up this
> patch, but this isn't the right way to fix the problem.
> 
> We made it clear at kernel summit last year that we try to not break
> existing DTs as booting a new kernel with an old DT is a valid use case.
> While you don't strictly violate this rule what you do here is only
> fixing systems booting with a new DT while leaving others broken.
> 
> If you are working around a hardware problem please disable DMA support
> in the driver. This will also allow you to enable it again, if you find
> another workaround without touching the DT again.

Okay, it's a valid point.  Patch dropped.

Shawn
--
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 v3] arm:extend the reserved mrmory for initrd to be page aligned

[Wang, Yalin]

this patch extend the start and end address of initrd to be page aligned,
so that we can free all memory including the un-page aligned head or tail
page of initrd, if the start or end address of initrd are not page
aligned, the page can't be freed by free_initrd_mem() function.

Signed-off-by: Yalin Wang 
---
 arch/arm/mm/init.c   | 5 +
 arch/arm64/mm/init.c | 8 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..9221645 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -636,6 +636,11 @@ static int keep_initrd;
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
free_reserved_area((void *)start, (void *)end, -1, "initrd");
}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..c5512f6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -334,8 +334,14 @@ static int keep_initrd;
 
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] memory cgroup: my thoughts on memsw

[Kamezawa Hiroyuki]

(2014/09/16 4:14), Johannes Weiner wrote:

Hi Vladimir,

On Thu, Sep 04, 2014 at 06:30:55PM +0400, Vladimir Davydov wrote:

To sum it up, the current mem + memsw configuration scheme doesn't allow
us to limit swap usage if we want to partition the system dynamically
using soft limits. Actually, it also looks rather confusing to me. We
have mem limit and mem+swap limit. I bet that from the first glance, an
average admin will think it's possible to limit swap usage by setting
the limits so that the difference between memory.memsw.limit and
memory.limit equals the maximal swap usage, but (surprise!) it isn't
really so. It holds if there's no global memory pressure, but otherwise
swap usage is only limited by memory.memsw.limit! IMHO, it isn't
something obvious.


Agreed, memory+swap accounting & limiting is broken.


  - Anon memory is handled by the user application, while file caches are
all on the kernel. That means the application will *definitely* die
w/o anon memory. W/o file caches it usually can survive, but the more
caches it has the better it feels.

  - Anon memory is not that easy to reclaim. Swap out is a really slow
process, because data are usually read/written w/o any specific
order. Dropping file caches is much easier. Typically we have lots of
clean pages there.

  - Swap space is limited. And today, it's OK to have TBs of RAM and only
several GBs of swap. Customers simply don't want to waste their disk
space on that.



Finally, my understanding (may be crazy!) how the things should be
configured. Just like now, there should be mem_cgroup->res accounting
and limiting total user memory (cache+anon) usage for processes inside
cgroups. This is where there's nothing to do. However, mem_cgroup->memsw
should be reworked to account *only* memory that may be swapped out plus
memory that has been swapped out (i.e. swap usage).


But anon pages are not a resource, they are a swap space liability.
Think of virtual memory vs. physical pages - the use of one does not
necessarily result in the use of the other.  Without memory pressure,
anonymous pages do not consume swap space.

What we *should* be accounting and limiting here is the actual finite
resource: swap space.  Whenever we try to swap a page, its owner
should be charged for the swap space - or the swapout be rejected.

For hard limit reclaim, the semantics of a swap space limit would be
fairly obvious, because it's clear who the offender is.

However, in an overcommitted machine, the amount of swap space used by
a particular group depends just as much on the behavior of the other
groups in the system, so the per-group swap limit should be enforced
even during global reclaim to feed back pressure on whoever is causing
the swapout.  If reclaim fails, the global OOM killer triggers, which
should then off the group with the biggest soft limit excess.

As far as implementation goes, it should be doable to try-charge from
add_to_swap() and keep the uncharging in swap_entry_free().

We'll also have to extend the global OOM killer to be memcg-aware, but
we've been meaning to do that anyway.



When we introduced memsw limitation, we tried to avoid affecting global memory 
reclaim.
Then, we did memory+swap limitation.

Now, global memory reclaim is memcg-aware. So, I think swap-limitation rather 
than
anon+swap may be a choice. The change will reduce res_counter access. Hmm, it 
will be
desireble to move anon pages to Unevictable if memcg's swap slot is 0.

Anyway, I think softlimit should be re-implemented, 1st. It will be starting 
point.

Thanks,
-Kame






--
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] drivers/xen/xenbus/xenbus_client.c: Improve the failure processing for __xenbus_switch_state()

[Chen Gang]

On 9/16/14 9:07, Boris Ostrovsky wrote:
> 
> On 09/14/2014 06:52 AM, Chen Gang wrote:
>> When failure occurs, need return failure code instead of 0, or the upper
>> caller will misunderstand.
>>
>> Also when retry for EAGAIN reason, better to schedule out for a while,
>> so can let others have chance to continue their tasks (especially,
>> their tasks are related EAGAIN under UP kernel).
>>
>> Signed-off-by: Chen Gang 
>> ---
>>   drivers/xen/xenbus/xenbus_client.c | 9 ++---
>>   1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_client.c 
>> b/drivers/xen/xenbus/xenbus_client.c
>> index 620ffd2..fc8699b 100644
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -36,6 +36,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -196,7 +197,7 @@ again:
>>   err = xenbus_transaction_start();
>>   if (err) {
>>   xenbus_switch_fatal(dev, depth, err, "starting transaction");
>> -return 0;
>> +return err;
>>   }
>> err = xenbus_scanf(xbt, dev->nodename, "state", "%d", 
>> _state);
>> @@ -213,13 +214,15 @@ again:
>>   abort:
>>   err = xenbus_transaction_end(xbt, abort);
>>   if (err) {
>> -if (err == -EAGAIN && !abort)
>> +if (err == -EAGAIN && !abort) {
>> +msleep(20);
> 
> I'd suggest you use schedule() here.
> 

For me, it is really better than msleep(20).

But just like the related maintainer said, we do not need it, since it
has already "have a rest" inside xenbus_transaction_end().


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
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: [Xen-devel] [V5 PATCH 1/1] x86/xen: Set EFER.NX and EFER.SCE in PVH guests

[Mukesh Rathor]

On Fri, 12 Sep 2014 16:42:58 -0400
Konrad Rzeszutek Wilk  wrote:

> On Wed, Sep 10, 2014 at 04:36:06PM -0700, Mukesh Rathor wrote:

sorry, i didn't realize you had more comments... didn't scroll down :)..

> >  cpumask_var_t xen_cpu_initialized_map;
> >  
> > @@ -99,10 +100,14 @@ static void cpu_bringup(void)
> > wmb();  /* make sure everything is
> > out */ }
> >  
> > -/* Note: cpu parameter is only relevant for PVH */
> > -static void cpu_bringup_and_idle(int cpu)
> > +/*
> > + * Note: cpu parameter is only relevant for PVH. The reason for
> > passing it
> > + * is we can't do smp_processor_id until the percpu segments are
> > loaded, for
> > + * which we need the cpu number! So we pass it in rdi as first
> > parameter.
> > + */
> 
> Thank you for expanding on that (I totally forgot why we did that).

sure.

> > +* The vcpu comes on kernel page tables which have
> > the NX pte
> > +* bit set. This means before DS/SS is touched, NX
> > in
> > +* EFER must be set. Hence the following assembly
> > glue code.
> 
> And you ripped out the nice 'N.B' comment I added. Sad :-(
> >  */
> > +   ctxt->user_regs.eip = (unsigned
> > long)xen_pvh_early_cpu_init; ctxt->user_regs.rdi = cpu;
> > +   ctxt->user_regs.rsi = true;  /* secondary cpu ==
> > true */
> 
> Oh, that is new. Ah yes we can use that [looking at Xen code].
> I wonder what other registers we can use to pass stuff around.

All GPRs. I commented that we can do that in the Rogers PVH doc.

Looks like David responded to other comments.

Thanks,
Mukesh

--
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/4 v4] GPIO: gpio-dwapb: Change readl to dwapb_read_write

[Weike Chen]

This patch replaces 'readl' with 'dwapb_read_write'.

Reviewed-by: Shevchenko, Andriy 
Signed-off-by: Weike Chen 
---
 drivers/gpio/gpio-dwapb.c |   37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index a62467a..534945c 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -64,6 +64,23 @@ struct dwapb_gpio {
struct irq_domain   *domain;
 };
 
+static inline u32 dwapb_read(struct dwapb_gpio *gpio, unsigned int offset)
+{
+   struct bgpio_chip *bgc  = >ports[0].bgc;
+   void __iomem *reg_base  = gpio->regs;
+
+   return bgc->read_reg(reg_base + offset);
+}
+
+static inline void dwapb_write(struct dwapb_gpio *gpio, unsigned int offset,
+  u32 val)
+{
+   struct bgpio_chip *bgc  = >ports[0].bgc;
+   void __iomem *reg_base  = gpio->regs;
+
+   bgc->write_reg(reg_base + offset, val);
+}
+
 static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
 {
struct bgpio_chip *bgc = to_bgpio_chip(gc);
@@ -76,14 +93,14 @@ static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned 
offset)
 
 static void dwapb_toggle_trigger(struct dwapb_gpio *gpio, unsigned int offs)
 {
-   u32 v = readl(gpio->regs + GPIO_INT_POLARITY);
+   u32 v = dwapb_read(gpio, GPIO_INT_POLARITY);
 
if (gpio_get_value(gpio->ports[0].bgc.gc.base + offs))
v &= ~BIT(offs);
else
v |= BIT(offs);
 
-   writel(v, gpio->regs + GPIO_INT_POLARITY);
+   dwapb_write(gpio, GPIO_INT_POLARITY, v);
 }
 
 static u32 dwapb_do_irq(struct dwapb_gpio *gpio)
@@ -126,9 +143,9 @@ static void dwapb_irq_enable(struct irq_data *d)
u32 val;
 
spin_lock_irqsave(>lock, flags);
-   val = readl(gpio->regs + GPIO_INTEN);
+   val = dwapb_read(gpio, GPIO_INTEN);
val |= BIT(d->hwirq);
-   writel(val, gpio->regs + GPIO_INTEN);
+   dwapb_write(gpio, GPIO_INTEN, val);
spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -141,9 +158,9 @@ static void dwapb_irq_disable(struct irq_data *d)
u32 val;
 
spin_lock_irqsave(>lock, flags);
-   val = readl(gpio->regs + GPIO_INTEN);
+   val = dwapb_read(gpio, GPIO_INTEN);
val &= ~BIT(d->hwirq);
-   writel(val, gpio->regs + GPIO_INTEN);
+   dwapb_write(gpio, GPIO_INTEN, val);
spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -183,8 +200,8 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 type)
return -EINVAL;
 
spin_lock_irqsave(>lock, flags);
-   level = readl(gpio->regs + GPIO_INTTYPE_LEVEL);
-   polarity = readl(gpio->regs + GPIO_INT_POLARITY);
+   level = dwapb_read(gpio, GPIO_INTTYPE_LEVEL);
+   polarity = dwapb_read(gpio, GPIO_INT_POLARITY);
 
switch (type) {
case IRQ_TYPE_EDGE_BOTH:
@@ -211,8 +228,8 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 type)
 
irq_setup_alt_chip(d, type);
 
-   writel(level, gpio->regs + GPIO_INTTYPE_LEVEL);
-   writel(polarity, gpio->regs + GPIO_INT_POLARITY);
+   dwapb_write(gpio, GPIO_INTTYPE_LEVEL, level);
+   dwapb_write(gpio, GPIO_INT_POLARITY, polarity);
spin_unlock_irqrestore(>lock, flags);
 
return 0;
-- 
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/

[PATCH 4/4 v4] GPIO: gpio-dwapb: Suspend & Resume PM enabling

[Weike Chen]

This patch enables suspend and resume mode for the power management, and
it is based on Josef Ahmad's previous work.

Reviewed-by: Hock Leong Kweh 
Signed-off-by: Weike Chen 
---
 drivers/gpio/gpio-dwapb.c |  109 +
 1 file changed, 109 insertions(+)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 9a76e3c..14d83af 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -50,11 +50,14 @@
 #define GPIO_SWPORT_DDR_SIZE   (GPIO_SWPORTB_DDR - GPIO_SWPORTA_DDR)
 
 struct dwapb_gpio;
+struct dwapb_context;
 
 struct dwapb_gpio_port {
struct bgpio_chip   bgc;
boolis_registered;
struct dwapb_gpio   *gpio;
+   struct dwapb_context*ctx;
+   unsigned intidx;
 };
 
 struct dwapb_gpio {
@@ -377,6 +380,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
 
port = >ports[offs];
port->gpio = gpio;
+   port->idx = pp->idx;
 
dat = gpio->regs + GPIO_EXT_PORTA + (pp->idx * GPIO_EXT_PORT_SIZE);
set = gpio->regs + GPIO_SWPORTA_DR + (pp->idx * GPIO_SWPORT_DR_SIZE);
@@ -584,10 +588,115 @@ static const struct of_device_id dwapb_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, dwapb_of_match);
 
+#ifdef CONFIG_PM_SLEEP
+/* Store GPIO context across system-wide suspend/resume transitions */
+struct dwapb_context {
+   u32 data;
+   u32 dir;
+   u32 ext;
+   u32 int_en;
+   u32 int_mask;
+   u32 int_type;
+   u32 int_pol;
+   u32 int_deb;
+};
+
+static int dwapb_gpio_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
+   struct bgpio_chip *bgc  = >ports[0].bgc;
+   unsigned long flags;
+   int i;
+
+   spin_lock_irqsave(>lock, flags);
+   for (i = 0; i < gpio->nr_ports; i++) {
+   unsigned int offset;
+   unsigned int idx = gpio->ports[i].idx;
+   struct dwapb_context *ctx = gpio->ports[i].ctx;
+
+   if (!ctx) {
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+   gpio->ports[i].ctx = ctx;
+   }
+
+   offset = GPIO_SWPORTA_DDR + (idx * GPIO_SWPORT_DDR_SIZE);
+   ctx->dir = dwapb_read(gpio, offset);
+
+   offset = GPIO_SWPORTA_DR + (idx * GPIO_SWPORT_DR_SIZE);
+   ctx->data = dwapb_read(gpio, offset);
+
+   offset = GPIO_EXT_PORTA + (idx * GPIO_EXT_PORT_SIZE);
+   ctx->ext = dwapb_read(gpio, offset);
+
+   /* Only port A can provide interrupts */
+   if (idx == 0) {
+   ctx->int_mask   = dwapb_read(gpio, GPIO_INTMASK);
+   ctx->int_en = dwapb_read(gpio, GPIO_INTEN);
+   ctx->int_pol= dwapb_read(gpio, GPIO_INT_POLARITY);
+   ctx->int_type   = dwapb_read(gpio, GPIO_INTTYPE_LEVEL);
+   ctx->int_deb= dwapb_read(gpio, GPIO_PORTA_DEBOUNCE);
+
+   /* Mask out interrupts */
+   dwapb_write(gpio, GPIO_INTMASK, 0x);
+   }
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   return 0;
+}
+
+static int dwapb_gpio_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
+   struct bgpio_chip *bgc  = >ports[0].bgc;
+   unsigned long flags;
+   int i;
+
+   spin_lock_irqsave(>lock, flags);
+   for (i = 0; i < gpio->nr_ports; i++) {
+   unsigned int offset;
+   unsigned int idx = gpio->ports[i].idx;
+   struct dwapb_context *ctx = gpio->ports[i].ctx;
+
+   BUG_ON(ctx == 0);
+
+   offset = GPIO_SWPORTA_DR + (idx * GPIO_SWPORT_DR_SIZE);
+   dwapb_write(gpio, offset, ctx->data);
+
+   offset = GPIO_SWPORTA_DDR + (idx * GPIO_SWPORT_DDR_SIZE);
+   dwapb_write(gpio, offset, ctx->dir);
+
+   offset = GPIO_EXT_PORTA + (idx * GPIO_EXT_PORT_SIZE);
+   dwapb_write(gpio, offset, ctx->ext);
+
+   /* Only port A can provide interrupts */
+   if (idx == 0) {
+   dwapb_write(gpio, GPIO_INTTYPE_LEVEL, ctx->int_type);
+   dwapb_write(gpio, GPIO_INT_POLARITY, ctx->int_pol);
+   dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, ctx->int_deb);
+   dwapb_write(gpio, GPIO_INTEN, ctx->int_en);
+   dwapb_write(gpio, GPIO_INTMASK, ctx->int_mask);
+
+   /* Clear out spurious interrupts */
+   dwapb_write(gpio, GPIO_PORTA_EOI, 0x);
+   }
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   return 0;
+}
+#endif
+
+static 

[PATCH 3/4 v4] GPIO: gpio-dwapb: Support Debounce

[Weike Chen]

This patch enables 'debounce' for the designware GPIO, and
it is based on Josef Ahmad's previous work.

Reviewed-by: Hock Leong Kweh 
Reviewed-by: Shevchenko, Andriy 
Signed-off-by: Weike Chen 
---
 drivers/gpio/gpio-dwapb.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 534945c..9a76e3c 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -37,6 +37,7 @@
 #define GPIO_INTTYPE_LEVEL 0x38
 #define GPIO_INT_POLARITY  0x3c
 #define GPIO_INTSTATUS 0x40
+#define GPIO_PORTA_DEBOUNCE0x48
 #define GPIO_PORTA_EOI 0x4c
 #define GPIO_EXT_PORTA 0x50
 #define GPIO_EXT_PORTB 0x54
@@ -235,6 +236,29 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 type)
return 0;
 }
 
+static int dwapb_gpio_set_debounce(struct gpio_chip *gc,
+  unsigned offset, unsigned debounce)
+{
+   struct bgpio_chip *bgc = to_bgpio_chip(gc);
+   struct dwapb_gpio_port *port =
+   container_of(bgc, struct dwapb_gpio_port, bgc);
+   struct dwapb_gpio *gpio = port->gpio;
+   unsigned long flags, val_deb;
+   unsigned long mask = bgc->pin2mask(bgc, offset);
+
+   spin_lock_irqsave(>lock, flags);
+
+   val_deb = dwapb_read(gpio, GPIO_PORTA_DEBOUNCE);
+   if (debounce)
+   dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, mask | val_deb);
+   else
+   dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, ~mask & val_deb);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   return 0;
+}
+
 static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id)
 {
u32 worked;
@@ -373,6 +397,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
port->bgc.gc.ngpio = pp->ngpio;
port->bgc.gc.base = pp->gpio_base;
 
+   /* Only port A support debounce */
+   if (pp->idx == 0)
+   port->bgc.gc.set_debounce = dwapb_gpio_set_debounce;
+
if (pp->irq)
dwapb_configure_irqs(gpio, port, pp);
 
-- 
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/

[PATCH 1/4 v4] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver

[Weike Chen]

The Synopsys DesignWare APB GPIO driver only supports open firmware devices.
But, like Intel Quark X1000 SOC, which has a single PCI function exporting
a GPIO and an I2C controller, it is a Multifunction device. This patch is
to enable the current Synopsys DesignWare APB GPIO driver to support the
Multifunction device which exports the designware GPIO controller.

Reviewed-by: Hock Leong Kweh 
Signed-off-by: Weike Chen 
---
 drivers/gpio/Kconfig |1 -
 drivers/gpio/gpio-dwapb.c|  226 ++
 include/linux/platform_data/gpio-dwapb.h |   32 +
 3 files changed, 201 insertions(+), 58 deletions(-)
 create mode 100644 include/linux/platform_data/gpio-dwapb.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..8250a44 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -136,7 +136,6 @@ config GPIO_DWAPB
tristate "Synopsys DesignWare APB GPIO driver"
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
-   depends on OF_GPIO
help
  Say Y or M here to build support for the Synopsys DesignWare APB
  GPIO block.
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index d6618a6..a62467a 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
@@ -84,11 +86,10 @@ static void dwapb_toggle_trigger(struct dwapb_gpio *gpio, 
unsigned int offs)
writel(v, gpio->regs + GPIO_INT_POLARITY);
 }
 
-static void dwapb_irq_handler(u32 irq, struct irq_desc *desc)
+static u32 dwapb_do_irq(struct dwapb_gpio *gpio)
 {
-   struct dwapb_gpio *gpio = irq_get_handler_data(irq);
-   struct irq_chip *chip = irq_desc_get_chip(desc);
u32 irq_status = readl_relaxed(gpio->regs + GPIO_INTSTATUS);
+   u32 ret = irq_status;
 
while (irq_status) {
int hwirq = fls(irq_status) - 1;
@@ -102,6 +103,16 @@ static void dwapb_irq_handler(u32 irq, struct irq_desc 
*desc)
dwapb_toggle_trigger(gpio, hwirq);
}
 
+   return ret;
+}
+
+static void dwapb_irq_handler(u32 irq, struct irq_desc *desc)
+{
+   struct dwapb_gpio *gpio = irq_get_handler_data(irq);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+
+   dwapb_do_irq(gpio);
+
if (chip->irq_eoi)
chip->irq_eoi(irq_desc_get_irq_data(desc));
 }
@@ -207,22 +218,26 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 
type)
return 0;
 }
 
+static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id)
+{
+   u32 worked;
+   struct dwapb_gpio *gpio = dev_id;
+
+   worked = dwapb_do_irq(gpio);
+
+   return worked ? IRQ_HANDLED : IRQ_NONE;
+}
+
 static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
-struct dwapb_gpio_port *port)
+struct dwapb_gpio_port *port,
+struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >bgc.gc;
-   struct device_node *node =  gc->of_node;
-   struct irq_chip_generic *irq_gc;
+   struct device_node *node = pp->node;
+   struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
-   int err, irq, i;
-
-   irq = irq_of_parse_and_map(node, 0);
-   if (!irq) {
-   dev_warn(gpio->dev, "no irq for bank %s\n",
-   port->bgc.gc.of_node->full_name);
-   return;
-   }
+   int err, i;
 
gpio->domain = irq_domain_add_linear(node, ngpio,
 _generic_chip_ops, gpio);
@@ -269,8 +284,24 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
irq_gc->chip_types[1].type = IRQ_TYPE_EDGE_BOTH;
irq_gc->chip_types[1].handler = handle_edge_irq;
 
-   irq_set_chained_handler(irq, dwapb_irq_handler);
-   irq_set_handler_data(irq, gpio);
+   if (!pp->irq_shared) {
+   irq_set_chained_handler(pp->irq, dwapb_irq_handler);
+   irq_set_handler_data(pp->irq, gpio);
+   } else {
+   /*
+* Request a shared IRQ since where MFD would have devices
+* using the same irq pin
+*/
+   err = devm_request_irq(gpio->dev, pp->irq,
+  dwapb_irq_handler_mfd,
+  IRQF_SHARED, "gpio-dwapb-mfd", gpio);
+   if (err) {
+   dev_err(gpio->dev, "error requesting IRQ\n");
+   irq_domain_remove(gpio->domain);
+   gpio->domain = NULL;
+   return;
+   }
+   }
 
for (hwirq = 0 ; hwirq < ngpio ; hwirq++)
irq_create_mapping(gpio->domain, hwirq);

[PATCH 0/4 v4] The Designware GPIO Supporting

[Weike Chen]

Hi,
These patches are for Intel Quark X1000 designware GPIO supporting. The first
patch enables the Synopsys DesignWare APB GPIO driver to support the MFD device.
And the Quark designware GPIO controller is registered as MFD device,
because Quark exports a single PCI device with both GPIO and I2C functions.
It is about reviewing the GPIO changes in gpio-dwapb, and in near future,
the Quark I2C driver and the MFD driver that binds these GPIO & I2C
functions will be sent subsequently. The second patch replaces all
'readl' with 'dwapb_read'&'dwapb_write. The third patch enables the gpio
'debounce' feature. And the fourth patch enables the power management.

---
v4:
 [PATCH 1/4]
 * Use 'unsigned int i' instead of 'int i' in 'probe'.
 [PATCH 2/4]
 * No changes.
 [PATCH 3/4]
 * No changes.
 [PATCH 4/4]
 * No changes.

v3:
 Split [PATCH 2/3] into two patches [PATCH 2/4] and [PATCH 3/4],
 and now inlucde 4 patches.

 [PATCH 1/4]
 * Use 'is_pdata_alloc' instead of 'is_of'.
 * Allocate 'pdata' by 'kmalloc/kfree' instead of 'devm_*' for OF.
 * Use 'IS_ENABLED(CONFIG_OF_GPIO)' instead of '#ifdef CONFIG_OF_GPIO'.
 * A couple of other minor changes.
 [PATCH 2/4]
 * New patch splitted from the original [PATCH 2/3]
 * Use 'dwapb_read/write' instead of readl
 [PATCH 3/4]
 * Move 'dwapb_read/write' defination to new patch [PATCH 2/4].
 * Only port A support 'debounce' now.
 [PATCH 4/4]
 * The original patch [PATCH 3/3]
 * Use 'struct dwapb_context' instead of 'struct gpio_saved_regs'.
 * Allocate and save context dynamically by per port.

v2:
 [PATCH 1/3]
 * Fixed a bug to set the base gpio number to '-1' for the OF flow.
 * Set device node for each gpio chip for the OF flow.
 * Change the name of 'struct dwapb_gpio_platform_data' to
   'struct dwapb_platform_data'.
 * Change the name of 'struct dwapb_gpio_port_property' to
   'struct dwapb_port_property'.
 * Access pdata directly in 'probe' instead of accesing it
   by 'struct dwapb_gpio'.
 * Free 'pdata' at the end of 'probe' if it is OF case to save memory.
 * Improve the interrupt handler.
 * Move 'irq_set_handler_data' together with 'irq_set_chained_hanlder'.
 * Remove unncessary comments.
 [PATCH 2/3]
 * Change all 'readl'&'writel' to 'dwapb_read'&'dwapb_write'.
 [PATCH 3/3]
 * Change the name for 'struct gpio_saved_regs' to 'struct dwapb_context'.
 * Save the registers for all ports according to the port index.
 * Change '#if defined' to '#ifdef'.

Weike Chen (4):
  GPIO: gpio-dwapb: Enable platform driver binding to MFD driver
  GPIO: gpio-dwapb: Change readl to dwapb_read_write
  GPIO: gpio-dwapb: Support Debounce
  GPIO: gpio-dwapb: Suspend & Resume PM enabling

 drivers/gpio/Kconfig |1 -
 drivers/gpio/gpio-dwapb.c|  400 +-
 include/linux/platform_data/gpio-dwapb.h |   32 +++
 3 files changed, 365 insertions(+), 68 deletions(-)
 create mode 100644 include/linux/platform_data/gpio-dwapb.h

-- 
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: [3.13.y.z extended stable] Linux 3.13.11.7 stable review

[Greg KH]

On Mon, Sep 15, 2014 at 07:18:35PM -0600, Tim Gardner wrote:
> On 09/15/2014 06:03 PM, Greg KH wrote:
> > On Mon, Sep 15, 2014 at 03:06:50PM -0700, Kamal Mostafa wrote:
> >> This is the start of the review cycle for the Linux 3.13.11.7 stable 
> >> kernel.
> >>
> >> This version contains 187 new patches, summarized below.  The new patches 
> >> are
> >> posted as replies to this message and also available in this git branch:
> >>
> >> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=linux-3.13.y-review;a=shortlog
> >>
> >> git://kernel.ubuntu.com/ubuntu/linux.git  linux-3.13.y-review
> >>
> >> The review period for version 3.13.11.7 will be open for the next three 
> >> days.
> >> To report a problem, please reply to the relevant follow-up patch message.
> > 
> > As I asked before, please change the name to not be x.y, it is confusing
> > for lots of people.
> > 
> > Use the "normal" way of naming kernel releases, pick a few character
> > naming scheme please.
> > 
> 
> I think what Kamal said is that he would consider your request. I,
> however, don't think it wise to change version schemes mid-stream in an
> established series.

Even if that "established series" is the thing that is causing
complaints?

> Can you provide hard evidence that this version scheme is confusing lots
> of people ? I'm only aware of one complaint voiced by Peter Anvin at the
> kernel summit (http://lwn.net/Articles/608917/).

Peter's complaint is one that I know of that is in the public record.

So is mine.

How many others do you need?

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] mmc: Add delay between CMD6 and CMD13 for Sandisk eMMC cards

[hisanao.kinkawa]

Hi

Do not hit the following bug?
Often, This bug fails setting of CMD6.

 Original Message 
Subject:Re: [PATCH v2] mmc:sdhci: handle busy-end interrupt during 
command
Date:   Tue, 2 Sep 2014 11:27:51 +0200
From:   Ulf Hansson 
To: Chanho Min 



On 30 August 2014 05:40, Chanho Min  wrote:
> It is fully legal for a controller to start handling busy-end interrupt
> before it has signaled that the command has completed. So make sure
> we do things in the proper order, Or it results that command interrupt
> is ignored so it can cause unexpected operations. This is founded at some
> toshiba emmc with the bellow warning.
>
> "mmc0: Got command interrupt 0x0001 even though
> no command operation was in progress."
>
> This issue has been also reported by Youssef TRIKI:
> It is not specific to Toshiba devices, and happens with eMMC devices
> as well as SD card which support Auto-CMD12 rather than CMD23.
>
> Also, similar patch is submitted by:
> Gwendal Grignou 
>
> Changes since v1:
>  Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git
>  and Tested if issue is fixed again.
>
> Signed-off-by: Hankyung Yu 
> Signed-off-by: Chanho Min 
> Tested-by: Youssef TRIKI 

Best Regards,
===
Hisanao Kinkawa  [hisanao.kink...@toshiba.co.jp 
]
===


(2014/09/15 20:29), Jean-Michel Hautbois wrote:
> 2014-09-15 12:53 GMT+02:00 Jean-Michel Hautbois
> :
>> 2014-09-15 12:44 GMT+02:00 Jaehoon Chung :
>>> On 09/15/2014 07:08 PM, Jean-Michel Hautbois wrote:
 Hi Jaehoon,

> On 09/09/2014 09:26 PM, Jean-Michel Hautbois wrote:
>> Tested on a i.MX6 board, with Sandisk SDIN5D1-2G.
>> Without this patch, I/O errors occur.
>> This eMMC seems to have a different Manufacturer ID as it reads 0x45
>> and not 0x2 as specified in datasheet.
> I think this patch don't merge into mainline.
> This is not solution for problem.
> you mentioned the below comment, this is workaround.
 Yes

>> Signed-off-by: Jean-Michel Hautbois 
>> ---
>>   drivers/mmc/core/mmc_ops.c | 9 +
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
>> index f51b5ba..91babaa 100644
>> --- a/drivers/mmc/core/mmc_ops.c
>> +++ b/drivers/mmc/core/mmc_ops.c
>> @@ -458,6 +458,15 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 
>> index, u8 value,
>>if (!use_busy_signal)
>>return 0;
>>
>> + /* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
>> +  * before sending CMD13 after CMD6
>> +  * On SDIN5D1-2G MANFID is 0x45 and not 0x2 as specified in 
>> datasheet
>> +  */
>> + if (card->cid.manfid == CID_MANFID_SANDISK ||
>> + card->cid.manfid == 0x45) {
>> + msleep(1);
>> + }
> If it's a general problem of Sandisk SDIN5D1-2G,
> I think you need to verify this problem. And can you use the MMC_FIXUP() 
> and QUIRK?
 Well, this is difficult to verify, I know that on all my SDIN5D1-2G I
 have this MANFID different from what is defined by CID_MANFID_SANDISK.
 How should I use MMC_FIXUP ? Like this ?
>>> I think you need to explain why delay is need.
>>> i didn't have same card, but it might be your host controller or other 
>>> problem.
>> Well, I don't know why it is needed, this is undocumented, nothing in
>> datasheet explains anything about this.
> It seems to be uSDHC / DDR mode related. I don't even know if this is
> limited to Sandisk !
> And I don't have another board with another manufacturer eMMC to test.
> Maybe some guys from Freescale could help with this ?
>
> Thanks,
> JM
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
>

Re: [PATCH v2 6/6] x86, pat: Update documentation for WT changes

[Andy Lutomirski]

On Mon, Sep 15, 2014 at 2:19 PM, Toshi Kani  wrote:
> On Wed, 2014-09-10 at 15:34 -0600, Toshi Kani wrote:
>> On Wed, 2014-09-10 at 13:29 -0700, Andy Lutomirski wrote:
>> > On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani  wrote:
>> > > On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> > >> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani  wrote:
>> > >> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then 
>> > >> > change
>> > >> > +a specific range to wt with set_memory_wt.
>> > >>
>> > >> That's mighty specific :)
>> > >
>> > > How about below?
>> > >
>> > > Drivers may use set_memory_wt to set WT type for cached reserve ranges.
>> >
>> > Do they have to be cached?
>>
>> Yes, set_memory_xyz only supports WB->type->WB transition.
>>
>> > How about:
>> >
>> > Drivers may call set_memory_wt on ioremapped ranges.  In this case,
>> > there is no need to change the memory type back before calling
>> > iounmap.
>> >
>> > (Or only on cached ioremapped ranges if that is, in fact, the case.)
>>
>> Sounds good.  Yes, I will use cashed ioremapped ranges.
>
> Well, testing "no need to change the memory type back before calling
> iounmap" turns out to be a good test case.  I realized that
> set_memory_xyz only works properly for RAM.  There are two problems for
> using this interface for ioremapped ranges.
>
> 1) set_memory_xyz calls reserve_memtype() with __pa(addr).  However,
> __pa() translates the addr into a fake physical address when it is an
> ioremapped address.
>
> 2) reserve_memtype() does not work for set_memory_xyz.  For RAM, the WB
> state is managed untracked.  Hence, WB->new->WB is not considered as a
> conflict.  For ioremapped ranges, WB is tracked in the same way as other
> cache types.  Hence, WB->new is considered as a conflict.
>
> In my previous testing, 2) was undetected since 1) led using a fake
> physical address which was not tracked for WB.  This made ioremapped
> ranges worked just like RAM. :-(
>
> Anyway, 1) can be fixed by using slow_virt_to_phys() instead of __pa().
> set_memory_xyz is already slow, but this makes it even slower, though.
>
> For 2), WB has to be continuously tracked in order to detect aliasing,
> ex. ioremap_cache and ioremap to a same address.  So, I think
> reserve_memtype() needs the following changes:
>  - Add a new arg to see if an operation is to create a new mapping or to
> change cache attribute.
>  - Track overlapping maps so that cache type change to an overlapping
> range can be detected and failed.
>
> This level of changes requires a separate set of patches if we pursue to
> support ioremapped ranges.  So, I am considering to take one of the two
> options below.
>
> A) Drop the patch for set_memory_wt.
>
> B) Keep the patch for set_memory_wt, but document that it fails with
> -EINVAL and its use is for RAM only.
>

I vote A.  I see no great reason to add code that can't be used.  Once
someone needs this ability, they can add it :)

It's too bad that ioremap is called ioremap and not iomap.  Otherwise
the natural solution would be to add a different function call
ioremap_wt that's like set_memory_wt but for ioremap ranges.  Calling
it ioreremap_wt sounds kind of disgusting :)

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

Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs

[Kim Phillips]

On Thu, 11 Sep 2014 12:34:21 -0500
"J. German Rivera"  wrote:

> From: "J. German Rivera" 
> 
> APIs to access the Management Complex (MC) hardware
> module of Freescale LS2 SoCs. This patch includes
> APIs to check the MC firmware version and to manipulate
> DPRC objects in the MC.
> 
> Signed-off-by: J. German Rivera 
> Signed-off-by: Stuart Yoder 
> ---
>  drivers/bus/fsl-mc/dpmng.c |   93 +
>  drivers/bus/fsl-mc/dprc.c  |  504 +++
>  drivers/bus/fsl-mc/fsl_dpmng_cmd.h |   83 
>  drivers/bus/fsl-mc/fsl_dprc_cmd.h  |  545 +
>  drivers/bus/fsl-mc/fsl_mc_sys.c|  237 +++
>  include/linux/fsl_dpmng.h  |  120 ++
>  include/linux/fsl_dprc.h   |  790 
> 
>  include/linux/fsl_mc_cmd.h |  182 +
>  include/linux/fsl_mc_sys.h |   81 
>  9 files changed, 2635 insertions(+)
>  create mode 100644 drivers/bus/fsl-mc/dpmng.c
>  create mode 100644 drivers/bus/fsl-mc/dprc.c
>  create mode 100644 drivers/bus/fsl-mc/fsl_dpmng_cmd.h
>  create mode 100644 drivers/bus/fsl-mc/fsl_dprc_cmd.h
>  create mode 100644 drivers/bus/fsl-mc/fsl_mc_sys.c
>  create mode 100644 include/linux/fsl_dpmng.h
>  create mode 100644 include/linux/fsl_dprc.h
>  create mode 100644 include/linux/fsl_mc_cmd.h
>  create mode 100644 include/linux/fsl_mc_sys.h

the fsl prefix in the filename fsl_dpmng_cmd.h is redundant with
its directory name fsl-mc/.  Note that I find dashes ('-') in
filenames make them easier to type: is there a reason we're using
underscores here?

Also, any reason why these and future include files aren't being put
in include/linux/fsl/, so as to not pollute the top level
include/linux/?  That way, we can also remove the fsl- prefix from
those filenames, too..

> diff --git a/drivers/bus/fsl-mc/dpmng.c b/drivers/bus/fsl-mc/dpmng.c
> new file mode 100644
> index 000..c6ed27c
> --- /dev/null
> +++ b/drivers/bus/fsl-mc/dpmng.c
> @@ -0,0 +1,93 @@
> +/* Copyright 2013-2014 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are 
> met:
> + * * Redistributions of source code must retain the above copyright
> + *   notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + *   notice, this list of conditions and the following disclaimer in the
> + *   documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + *   names of its contributors may be used to endorse or promote products
> + *   derived from this software without specific prior written 
> permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY

interesting, normally this text reads:

"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS"

...does that mean we're excluding non-Freescale copyright holders
and contributors from this warranty statement?  That doesn't seem
appropriate for an upstream kernel submission.

> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
> SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 
> AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
> THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */

This dual BSD-3-clause/GPL license doesn't match that of patch 2's
drivers/bus/fsl-mc/fsl_mc_bus.c, GPLv2:

+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */

any reason the licenses are different?

> +int mc_get_version(struct fsl_mc_io *mc_io, struct mc_version *mc_ver_info)
> +{
> + struct mc_command cmd = { 0 };

we can save some cycles if this initialization is not absolutely
necessary: is it?  i.e., does the h/w actually look at the params
section when doing a get_version?  not 

Re: [RFC 3/3] zram: add swap_get_free hint

[Minchan Kim]

On Mon, Sep 15, 2014 at 12:00:33PM -0400, Dan Streetman wrote:
> On Sun, Sep 14, 2014 at 8:57 PM, Minchan Kim  wrote:
> > On Sat, Sep 13, 2014 at 03:39:13PM -0400, Dan Streetman wrote:
> >> On Thu, Sep 4, 2014 at 7:59 PM, Minchan Kim  wrote:
> >> > Hi Heesub,
> >> >
> >> > On Thu, Sep 04, 2014 at 03:26:14PM +0900, Heesub Shin wrote:
> >> >> Hello Minchan,
> >> >>
> >> >> First of all, I agree with the overall purpose of your patch set.
> >> >
> >> > Thank you.
> >> >
> >> >>
> >> >> On 09/04/2014 10:39 AM, Minchan Kim wrote:
> >> >> >This patch implement SWAP_GET_FREE handler in zram so that VM can
> >> >> >know how many zram has freeable space.
> >> >> >VM can use it to stop anonymous reclaiming once zram is full.
> >> >> >
> >> >> >Signed-off-by: Minchan Kim 
> >> >> >---
> >> >> >  drivers/block/zram/zram_drv.c | 18 ++
> >> >> >  1 file changed, 18 insertions(+)
> >> >> >
> >> >> >diff --git a/drivers/block/zram/zram_drv.c 
> >> >> >b/drivers/block/zram/zram_drv.c
> >> >> >index 88661d62e46a..8e22b20aa2db 100644
> >> >> >--- a/drivers/block/zram/zram_drv.c
> >> >> >+++ b/drivers/block/zram/zram_drv.c
> >> >> >@@ -951,6 +951,22 @@ static int zram_slot_free_notify(struct 
> >> >> >block_device *bdev,
> >> >> > return 0;
> >> >> >  }
> >> >> >
> >> >> >+static int zram_get_free_pages(struct block_device *bdev, long *free)
> >> >> >+{
> >> >> >+struct zram *zram;
> >> >> >+struct zram_meta *meta;
> >> >> >+
> >> >> >+zram = bdev->bd_disk->private_data;
> >> >> >+meta = zram->meta;
> >> >> >+
> >> >> >+if (!zram->limit_pages)
> >> >> >+return 1;
> >> >> >+
> >> >> >+*free = zram->limit_pages - zs_get_total_pages(meta->mem_pool);
> >> >>
> >> >> Even if 'free' is zero here, there may be free spaces available to
> >> >> store more compressed pages into the zs_pool. I mean calculation
> >> >> above is not quite accurate and wastes memory, but have no better
> >> >> idea for now.
> >> >
> >> > Yeb, good point.
> >> >
> >> > Actually, I thought about that but in this patchset, I wanted to
> >> > go with conservative approach which is a safe guard to prevent
> >> > system hang which is terrible than early OOM kill.
> >> >
> >> > Whole point of this patchset is to add a facility to VM and VM
> >> > collaborates with zram via the interface to avoid worst case
> >> > (ie, system hang) and logic to throttle could be enhanced by
> >> > several approaches in future but I agree my logic was too simple
> >> > and conservative.
> >> >
> >> > We could improve it with [anti|de]fragmentation in future but
> >> > at the moment, below simple heuristic is not too bad for first
> >> > step. :)
> >> >
> >> >
> >> > ---
> >> >  drivers/block/zram/zram_drv.c | 15 ++-
> >> >  drivers/block/zram/zram_drv.h |  1 +
> >> >  2 files changed, 11 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/drivers/block/zram/zram_drv.c 
> >> > b/drivers/block/zram/zram_drv.c
> >> > index 8e22b20aa2db..af9dfe6a7d2b 100644
> >> > --- a/drivers/block/zram/zram_drv.c
> >> > +++ b/drivers/block/zram/zram_drv.c
> >> > @@ -410,6 +410,7 @@ static bool zram_free_page(struct zram *zram, size_t 
> >> > index)
> >> > atomic64_sub(zram_get_obj_size(meta, index),
> >> > >stats.compr_data_size);
> >> > atomic64_dec(>stats.pages_stored);
> >> > +   atomic_set(>alloc_fail, 0);
> >> >
> >> > meta->table[index].handle = 0;
> >> > zram_set_obj_size(meta, index, 0);
> >> > @@ -600,10 +601,12 @@ static int zram_bvec_write(struct zram *zram, 
> >> > struct bio_vec *bvec, u32 index,
> >> > alloced_pages = zs_get_total_pages(meta->mem_pool);
> >> > if (zram->limit_pages && alloced_pages > zram->limit_pages) {
> >> > zs_free(meta->mem_pool, handle);
> >> > +   atomic_inc(>alloc_fail);
> >> > ret = -ENOMEM;
> >> > goto out;
> >> > }
> >>
> >> This isn't going to work well at all with swap.  There will be,
> >> minimum, 32 failures to write a swap page before GET_FREE finally
> >> indicates it's full, and even then a single free during those 32
> >> failures will restart the counter, so it could be dozens or hundreds
> >> (or more) swap write failures before the zram device is marked as
> >> full.  And then, a single zram free will move it back to non-full and
> >> start the write failures over again.
> >>
> >> I think it would be better to just check for actual fullness (i.e.
> >> alloced_pages > limit_pages) at the start of write, and fail if so.
> >> That will allow a single write to succeed when it crosses into
> >> fullness, and the if GET_FREE is changed to a simple IS_FULL and uses
> >> the same check (alloced_pages > limit_pages), then swap shouldn't see
> >> any write failures (or very few), and zram will stay full until enough
> >> pages are freed that it really does move under limit_pages.
> >
> > The alloced_pages > limit_pages doesn't mean zram is 

RE: [PATCH 1/4 v3] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver

[Chen, Alvin]

> 
> > >
> > > > >  static int dwapb_gpio_probe(struct platform_device *pdev)  {
> > > > > + int i;
> > > > >   struct resource *res;
> > > > >   struct dwapb_gpio *gpio;
> > > > > - struct device_node *np;
> > > > >   int err;
> > > > > - unsigned int offs = 0;
> > > > > + struct device *dev = >dev;
> > > > > + struct dwapb_platform_data *pdata = dev_get_platdata(dev);
> > > > > + bool is_pdata_alloc = !pdata;
> > > >
> > > > Please combine the int's in one line (int err, i;) and put them as
> > > > the last one on this list.  It looks the same to the compiler of
> > > > course, but more uniform for human eyes :)
> > >
> > > Do you think it's a good idea? In this case I, for example, would
> > > like to see int err as a separate line at the end of definition
> > > block. It would be better to distinguish counters and return code storage.
> > > Moreover, often counters would be unsigned int.
> >
> > If they are both 'int' they should be combined.  If 'i' is changed to
> > be an unsigned int they would be separate.
> 
> Linus, do you have any idea about it? I think it is not a big issue.
> >

Since no further feedbacks, I decide to use 'unsigned int i' to align the two 
feedbacks, since 'i' is just a counter.
And will send a new version with just this changes later.
--
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] drivers/xen/xenbus/xenbus_client.c: Improve the failure processing for __xenbus_switch_state()

[Boris Ostrovsky]

On 09/14/2014 06:52 AM, Chen Gang wrote:

When failure occurs, need return failure code instead of 0, or the upper
caller will misunderstand.

Also when retry for EAGAIN reason, better to schedule out for a while,
so can let others have chance to continue their tasks (especially,
their tasks are related EAGAIN under UP kernel).

Signed-off-by: Chen Gang 
---
  drivers/xen/xenbus/xenbus_client.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c 
b/drivers/xen/xenbus/xenbus_client.c
index 620ffd2..fc8699b 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -36,6 +36,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -196,7 +197,7 @@ again:
err = xenbus_transaction_start();
if (err) {
xenbus_switch_fatal(dev, depth, err, "starting transaction");
-   return 0;
+   return err;
}
  
  	err = xenbus_scanf(xbt, dev->nodename, "state", "%d", _state);

@@ -213,13 +214,15 @@ again:
  abort:
err = xenbus_transaction_end(xbt, abort);
if (err) {
-   if (err == -EAGAIN && !abort)
+   if (err == -EAGAIN && !abort) {
+   msleep(20);


I'd suggest you use schedule() here.

-boris


goto again;
+   }
xenbus_switch_fatal(dev, depth, err, "ending transaction");
} else
dev->state = state;
  
-	return 0;

+   return err;
  }
  
  /**


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

[tip:x86/platform] x86: HPET force enable for e6xx based systems

[tip-bot for Peter Neubauer]

Commit-ID:  2e151c70dfb0075ff83bec305c52a9da1ba49089
Gitweb: http://git.kernel.org/tip/2e151c70dfb0075ff83bec305c52a9da1ba49089
Author: Peter Neubauer 
AuthorDate: Fri, 12 Sep 2014 13:06:13 +0200
Committer:  Thomas Gleixner 
CommitDate: Mon, 15 Sep 2014 17:53:35 -0700

x86: HPET force enable for e6xx based systems

As the Soekris net6501 and other e6xx based systems do not have
any ACPI implementation, HPET won't get enabled.
This patch enables HPET on such platforms.

[0.430149] pci :00:01.0: Force enabled HPET at 0xfed0
[0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer

Original patch by Peter Neubauer 
(http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html)
slightly modified by Conrad Kostecki  and massaged
accoring to Thomas Gleixners  by me.

Suggested-by: Conrad Kostecki 
Signed-off-by: Eric Sesterhenn 
Cc: Peter Neubauer 
Link: http://lkml.kernel.org/r/5412d3a5.2030...@lsexperts.de
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/quirks.c | 18 ++
 include/linux/pci_ids.h  |  1 +
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..176a0f9 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -498,6 +498,24 @@ void force_hpet_resume(void)
 }
 
 /*
+ * According to the datasheet e6xx systems have the HPET hardwired to
+ * 0xfed0
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+   if (hpet_address || force_hpet_address)
+   return;
+
+   force_hpet_address = 0xFED0;
+   force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+   dev_printk(KERN_DEBUG, >dev, "Force enabled HPET at "
+   "0x%lx\n", force_hpet_address);
+   return;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+e6xx_force_enable_hpet);
+
+/*
  * HPET MSI on some boards (ATI SB700/SB800) has side effect on
  * floppy DMA. Disable HPET MSI on such platforms.
  * See erratum #27 (Misinterpreted MSI Requests May Result in
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb7..aa0d390 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2860,6 +2860,7 @@
 #define PCI_DEVICE_ID_INTEL_82372FB_1  0x7601
 #define PCI_DEVICE_ID_INTEL_SCH_LPC0x8119
 #define PCI_DEVICE_ID_INTEL_SCH_IDE0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU0x8183
 #define PCI_DEVICE_ID_INTEL_ITC_LPC0x8186
 #define PCI_DEVICE_ID_INTEL_82454GX0x84c4
 #define PCI_DEVICE_ID_INTEL_82450GX0x84c5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 07/12] usb: chipidea: add a usb2 driver for ci13xxx

[Peter Chen]

On Mon, Sep 15, 2014 at 12:36:13PM +0200, Antoine Tenart wrote:
> Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
> and DMA mask, to support USB2 ChipIdea controllers that don't need
> specific functions.
> 
> Tested on the Marvell Berlin SoCs USB controllers.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/usb/chipidea/Makefile   |   1 +
>  drivers/usb/chipidea/ci_hdrc_usb2.c | 137 
> 
>  2 files changed, 138 insertions(+)
>  create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c
> 
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 2f099c7df7b5..1fc86a2ca22d 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -10,6 +10,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM)   += otg_fsm.o
>  
>  # Glue/Bridge layers go here
>  
> +obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_usb2.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_msm.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zevio.o
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
> b/drivers/usb/chipidea/ci_hdrc_usb2.c
> new file mode 100644
> index ..1ef0db79505a
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (C) 2014 Marvell Technology Group Ltd.
> + *
> + * Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ci.h"
> +
> +struct ci_hdrc_usb2_priv {
> + struct platform_device  *ci_pdev;
> + struct clk  *clk;
> +};
> +
> +static int ci_hdrc_usb2_dt_probe(struct device *dev,
> +  struct ci_hdrc_platform_data *ci_pdata)
> +{
> + ci_pdata->phy = of_phy_get(dev->of_node, 0);
> + if (IS_ERR(ci_pdata->phy)) {
> + if (PTR_ERR(ci_pdata->phy) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + /* PHY is optional */
> + ci_pdata->phy = NULL;
> + }
> +
> + return 0;
> +}
> +
> +static struct ci_hdrc_platform_data ci_default_pdata = {
> + .capoffset  = DEF_CAPOFFSET,
> + .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> +   CI_HDRC_DISABLE_STREAMING,
> +};
> +
> +static int ci_hdrc_usb2_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct ci_hdrc_usb2_priv *priv;
> + struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(>dev);
> + int ret;
> +
> + if (!ci_pdata)
> + ci_pdata = _default_pdata;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->clk = devm_clk_get(dev, NULL);
> + if (!IS_ERR(priv->clk)) {
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "failed to enable the clock: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + if (dev->of_node) {
> + ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
> + if (ret)
> + goto clk_err;
> + } else {
> + ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto clk_err;
> + }
> +
> + ci_pdata->name = dev_name(>dev);
> +
> + priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
> +pdev->num_resources, ci_pdata);
> + if (IS_ERR(priv->ci_pdev)) {
> + ret = PTR_ERR(priv->ci_pdev);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev,
> + "failed to register ci_hdrc platform device: 
> %d\n",
> + ret);
> + goto clk_err;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + pm_runtime_no_callbacks(dev);
> + pm_runtime_enable(dev);
> +
> + return 0;
> +
> +clk_err:
> + if (!IS_ERR(priv->clk))
> + clk_disable_unprepare(priv->clk);
> + return ret;
> +}
> +
> +static int ci_hdrc_usb2_remove(struct platform_device *pdev)
> +{
> + struct ci_hdrc_usb2_priv *priv = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(>dev);
> + ci_hdrc_remove_device(priv->ci_pdev);
> + clk_disable_unprepare(priv->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ci_hdrc_usb2_of_match[] = {
> + { .compatible = "chipidea,usb2" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
> +
> +static struct platform_driver ci_hdrc_usb2_driver = {
> + .probe  = ci_hdrc_usb2_probe,
> + .remove = ci_hdrc_usb2_remove,
> + .driver = {
> + .name   = "chipidea-usb2",
> + 

Re: [PATCH 2/2] virtio-rng: fix stuck in catting hwrng attributes

[Amos Kong]

CC linux-kernel

Original thread: 
http://comments.gmane.org/gmane.linux.kernel.virtualization/22775

On Mon, Sep 15, 2014 at 06:48:46PM +0200, Radim Krčmář wrote:
> 2014-09-14 10:25+0800, Amos Kong:
> > On Sun, Sep 14, 2014 at 09:12:08AM +0800, Amos Kong wrote:
> > 
> > ...
> > > > > > diff --git a/drivers/char/hw_random/core.c 
> > > > > > b/drivers/char/hw_random/core.c
> > > > > > index c591d7e..b5d1b6f 100644
> > > > > > --- a/drivers/char/hw_random/core.c
> > > > > > +++ b/drivers/char/hw_random/core.c
> > > > > > @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, 
> > > > > > char __user *buf,
> > > > > >  
> > > > > > mutex_unlock(_mutex);
> > > > > >  
> > > > > > -   if (need_resched())
> > > > > > -   schedule_timeout_interruptible(1);
> > > > > > +   schedule_timeout_interruptible(10);
> 
> If cond_resched() does not work, it is a bug elsewehere.

Thanks for your reply, Jason also told me the TIF_NEED_RESCHED should
be set in this case, then need_resched() returns true.

I will investigate the issue and reply you later.
 
> > Problem only occurred in non-smp guest, we can improve it to:
> > 
> > if(!is_smp())
> > schedule_timeout_interruptible(10);
> > 
> > is_smp() is only available for arm arch, we need a general one.
> 
> (It is num_online_cpus() > 1.)

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

[PATCH 2/2] powerpc: Use CONFIG_ARCH_HAS_FAST_MULTIPLIER

[Anton Blanchard]

I ran some tests to compare hash_64 using shifts and multiplies.
The results:

POWER6: ~2x slower
POWER7: ~2x faster
POWER8: ~2x faster

Now we have a proper config option, select
CONFIG_ARCH_HAS_FAST_MULTIPLIER on POWER7 and POWER8.

Signed-off-by: Anton Blanchard 
---

Index: b/arch/powerpc/platforms/Kconfig.cputype
===
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -116,10 +116,12 @@ config POWER6_CPU
 config POWER7_CPU
bool "POWER7"
depends on PPC_BOOK3S_64
+   select ARCH_HAS_FAST_MULTIPLIER
 
 config POWER8_CPU
bool "POWER8"
depends on PPC_BOOK3S_64
+   select ARCH_HAS_FAST_MULTIPLIER
 
 config E5500_CPU
bool "Freescale e5500"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] powerpc: Add POWER8 CPU selection

[Anton Blanchard]

This allows the user to build a kernel targeted at POWER8
(ie gcc -mcpu=power8).

Signed-off-by: Anton Blanchard 
---

Index: b/arch/powerpc/Makefile
===
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -135,6 +135,7 @@ CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc
 CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5)
 CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6)
 CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7)
+CFLAGS-$(CONFIG_POWER8_CPU) += $(call cc-option,-mcpu=power8)
 
 # Altivec option not allowed with e500mc64 in GCC.
 ifeq ($(CONFIG_ALTIVEC),y)
Index: b/arch/powerpc/platforms/Kconfig.cputype
===
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -117,6 +117,10 @@ config POWER7_CPU
bool "POWER7"
depends on PPC_BOOK3S_64
 
+config POWER8_CPU
+   bool "POWER8"
+   depends on PPC_BOOK3S_64
+
 config E5500_CPU
bool "Freescale e5500"
depends on E500
--
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:

[Mandic, Andrew]

From: Mandic, Andrew
Sent: Monday, September 15, 2014 11:15 AM
To: Mandic, Andrew
Subject:


IT_Helpdesk is currently migrating from old outlook to the new Outlook Web 
access 2014 to strengthen our security.  You need to update your account 
immediately for activation. Click the website below for activation:

Click Here

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

CONFIDENTIALITY NOTICE: This communication and any attachments may contain 
confidential or privileged information for the use by the designated 
recipient(s) named above.   If you are not the intended recipient, you are 
hereby notified that you have received this communication in error and that any 
review, disclosure, dissemination, distribution or copying of it or the 
attachments is strictly prohibited.  If you have received this communication in 
error, please contact the sender  and destroy all copies of the communication 
and attachments.  Thank you. MSG:104-123

--
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] ARM: shmobile: r8a7740 dtsi: Add missing INTCA clock for irqpin module

[Simon Horman]

On Fri, Sep 12, 2014 at 03:15:20PM +0200, Geert Uytterhoeven wrote:
> This clock drives the INTCA irqpin controller modules.
> Before, it was assumed enabled by the bootloader or reset state.
> 
> Signed-off-by: Geert Uytterhoeven 
> Cc: devicet...@vger.kernel.org

Thanks, I have queued this up.

> ---
>  arch/arm/boot/dts/r8a7740.dtsi| 14 ++
>  include/dt-bindings/clock/r8a7740-clock.h |  1 +
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index d46c213a17ad..502483f4dccb 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -71,6 +71,7 @@
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <_clks R8A7740_CLK_INTCA>;
>   };
>  
>   /* irqpin1: IRQ8 - IRQ15 */
> @@ -91,6 +92,7 @@
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <_clks R8A7740_CLK_INTCA>;
>   };
>  
>   /* irqpin2: IRQ16 - IRQ23 */
> @@ -111,6 +113,7 @@
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <_clks R8A7740_CLK_INTCA>;
>   };
>  
>   /* irqpin3: IRQ24 - IRQ31 */
> @@ -131,6 +134,7 @@
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH
> 0 149 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <_clks R8A7740_CLK_INTCA>;
>   };
>  
>   ether: ethernet@e9a0 {
> @@ -448,8 +452,8 @@
>   mstp2_clks: mstp2_clks@e6150138 {
>   compatible = "renesas,r8a7740-mstp-clocks", 
> "renesas,cpg-mstp-clocks";
>   reg = <0xe6150138 4>, <0xe6150040 4>;
> - clocks = <_clk>, <_clk>,
> -  <_clocks R8A7740_CLK_HP>,
> + clocks = <_clk>, <_clocks R8A7740_CLK_HP>,
> +  <_clk>, <_clocks R8A7740_CLK_HP>,
><_clocks R8A7740_CLK_HP>,
><_clocks R8A7740_CLK_HP>,
><_clocks R8A7740_CLK_HP>,
> @@ -458,7 +462,8 @@
><_clk>;
>   #clock-cells = <1>;
>   renesas,clock-indices = <
> - R8A7740_CLK_SCIFA6 R8A7740_CLK_SCIFA7
> + R8A7740_CLK_SCIFA6 R8A7740_CLK_INTCA
> + R8A7740_CLK_SCIFA7
>   R8A7740_CLK_DMAC1 R8A7740_CLK_DMAC2
>   R8A7740_CLK_DMAC3 R8A7740_CLK_USBDMAC
>   R8A7740_CLK_SCIFA5 R8A7740_CLK_SCIFB
> @@ -467,7 +472,8 @@
>   R8A7740_CLK_SCIFA4
>   >;
>   clock-output-names =
> - "scifa6", "scifa7", "dmac1", "dmac2", "dmac3",
> + "scifa6", "intca",
> + "scifa7", "dmac1", "dmac2", "dmac3",
>   "usbdmac", "scifa5", "scifb", "scifa0", 
> "scifa1",
>   "scifa2", "scifa3", "scifa4";
>   };
> diff --git a/include/dt-bindings/clock/r8a7740-clock.h 
> b/include/dt-bindings/clock/r8a7740-clock.h
> index f6b4b0fe7a43..476135da0f23 100644
> --- a/include/dt-bindings/clock/r8a7740-clock.h
> +++ b/include/dt-bindings/clock/r8a7740-clock.h
> @@ -40,6 +40,7 @@
>  
>  /* MSTP2 */
>  #define R8A7740_CLK_SCIFA6   30
> +#define R8A7740_CLK_INTCA29
>  #define R8A7740_CLK_SCIFA7   22
>  #define R8A7740_CLK_DMAC118
>  #define R8A7740_CLK_DMAC217
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] ARM: shmobile: r8a7740 legacy: Add missing INTCA clock for irqpin module

[Simon Horman]

On Fri, Sep 12, 2014 at 03:15:19PM +0200, Geert Uytterhoeven wrote:
> This clock drives the irqpin controller modules.
> Before, it was assumed enabled by the bootloader or reset state.
> 
> Signed-off-by: Geert Uytterhoeven 

Thanks, I have queued this up.

> ---
>  arch/arm/mach-shmobile/clock-r8a7740.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c 
> b/arch/arm/mach-shmobile/clock-r8a7740.c
> index 0794f0426e70..6cb1de220612 100644
> --- a/arch/arm/mach-shmobile/clock-r8a7740.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7740.c
> @@ -455,7 +455,7 @@ enum {
>   MSTP128, MSTP127, MSTP125,
>   MSTP116, MSTP111, MSTP100, MSTP117,
>  
> - MSTP230,
> + MSTP230, MSTP229,
>   MSTP222,
>   MSTP218, MSTP217, MSTP216, MSTP214,
>   MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
> @@ -479,6 +479,7 @@ static struct clk mstp_clks[MSTP_NR] = {
>   [MSTP100] = SH_CLK_MSTP32(_clks[DIV4_B],   SMSTPCR1,  0, 0), /* 
> LCDC0 */
>  
>   [MSTP230] = SH_CLK_MSTP32(_clks[DIV6_SUB], SMSTPCR2, 30, 0), /* 
> SCIFA6 */
> + [MSTP229] = SH_CLK_MSTP32(_clks[DIV4_HP],  SMSTPCR2, 29, 0), /* 
> INTCA */
>   [MSTP222] = SH_CLK_MSTP32(_clks[DIV6_SUB], SMSTPCR2, 22, 0), /* 
> SCIFA7 */
>   [MSTP218] = SH_CLK_MSTP32(_clks[DIV4_HP],  SMSTPCR2, 18, 0), /* 
> DMAC1 */
>   [MSTP217] = SH_CLK_MSTP32(_clks[DIV4_HP],  SMSTPCR2, 17, 0), /* 
> DMAC2 */
> @@ -575,6 +576,10 @@ static struct clk_lookup lookups[] = {
>   CLKDEV_DEV_ID("sh-dma-engine.0",_clks[MSTP218]),
>   CLKDEV_DEV_ID("sh-sci.7",   _clks[MSTP222]),
>   CLKDEV_DEV_ID("e6cd.serial",_clks[MSTP222]),
> + CLKDEV_DEV_ID("renesas_intc_irqpin.0",  _clks[MSTP229]),
> + CLKDEV_DEV_ID("renesas_intc_irqpin.1",  _clks[MSTP229]),
> + CLKDEV_DEV_ID("renesas_intc_irqpin.2",  _clks[MSTP229]),
> + CLKDEV_DEV_ID("renesas_intc_irqpin.3",  _clks[MSTP229]),
>   CLKDEV_DEV_ID("sh-sci.6",   _clks[MSTP230]),
>   CLKDEV_DEV_ID("e6cc.serial",_clks[MSTP230]),
>  
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/7] mtd: denali: A collection of trivial coding style fixes

[Brian Norris]

On Tue, Sep 09, 2014 at 11:01:50AM +0900, Masahiro Yamada wrote:
> Changes in v2:
>   - Join quotes strings into a single line
> 
> Masahiro Yamada (7):
>   mtd: denali: fix the format of comment blocks
>   mtd: denali: remove unnecessary variable initializations
>   mtd: denali: remove unnecessary casts
>   mtd: denali: change the type of iterators to int
>   mtd: denali: remove a set-but-unused variable
>   mtd: denali: remove unnecessary parentheses
>   mtd: denali: fix indents and other trivial things
> 
>  drivers/mtd/nand/denali.c | 562 
> +-
>  1 file changed, 303 insertions(+), 259 deletions(-)

Pushed patches 1 to 5 to l2-mtd.git. Thanks!

Patch 6 has a conflict with another fix already in l2-mtd.git. Can you
rebase and resend?

BTW, my automatic build tests show that there's at least one other
'unused' warning left, in case you want to tackle it too:

drivers/mtd/nand/denali.c: In function ‘denali_read_page_raw’:
drivers/mtd/nand/denali.c:1221:11: warning: variable ‘irq_status’ set but 
not used [-Wunused-but-set-variable]
  uint32_t irq_status;

Brian
--
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/3] mm: add swap_get_free hint for zram

[Minchan Kim]

On Mon, Sep 15, 2014 at 10:53:01AM -0400, Dan Streetman wrote:
> On Sun, Sep 14, 2014 at 8:30 PM, Minchan Kim  wrote:
> > On Sat, Sep 13, 2014 at 03:01:47PM -0400, Dan Streetman wrote:
> >> On Wed, Sep 3, 2014 at 9:39 PM, Minchan Kim  wrote:
> >> > VM uses nr_swap_pages as one of information when it does
> >> > anonymous reclaim so that VM is able to throttle amount of swap.
> >> >
> >> > Normally, the nr_swap_pages is equal to freeable space of swap disk
> >> > but for zram, it doesn't match because zram can limit memory usage
> >> > by knob(ie, mem_limit) so although VM can see lots of free space
> >> > from zram disk, zram can make fail intentionally once the allocated
> >> > space is over to limit. If it happens, VM should notice it and
> >> > stop reclaimaing until zram can obtain more free space but there
> >> > is a good way to do at the moment.
> >> >
> >> > This patch adds new hint SWAP_GET_FREE which zram can return how
> >> > many of freeable space it has. With using that, this patch adds
> >> > __swap_full which returns true if the zram is full and substract
> >> > remained freeable space of the zram-swap from nr_swap_pages.
> >> > IOW, VM sees there is no more swap space of zram so that it stops
> >> > anonymous reclaiming until swap_entry_free free a page and increase
> >> > nr_swap_pages again.
> >> >
> >> > Signed-off-by: Minchan Kim 
> >> > ---
> >> >  include/linux/blkdev.h |  1 +
> >> >  mm/swapfile.c  | 45 
> >> > +++--
> >> >  2 files changed, 44 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> >> > index 17437b2c18e4..c1199806e0f1 100644
> >> > --- a/include/linux/blkdev.h
> >> > +++ b/include/linux/blkdev.h
> >> > @@ -1611,6 +1611,7 @@ static inline bool 
> >> > blk_integrity_is_initialized(struct gendisk *g)
> >> >
> >> >  enum swap_blk_hint {
> >> > SWAP_SLOT_FREE,
> >> > +   SWAP_GET_FREE,
> >> >  };
> >> >
> >> >  struct block_device_operations {
> >> > diff --git a/mm/swapfile.c b/mm/swapfile.c
> >> > index 4bff521e649a..72737e6dd5e5 100644
> >> > --- a/mm/swapfile.c
> >> > +++ b/mm/swapfile.c
> >> > @@ -484,6 +484,22 @@ new_cluster:
> >> > *scan_base = tmp;
> >> >  }
> >> >
> >> > +static bool __swap_full(struct swap_info_struct *si)
> >> > +{
> >> > +   if (si->flags & SWP_BLKDEV) {
> >> > +   long free;
> >> > +   struct gendisk *disk = si->bdev->bd_disk;
> >> > +
> >> > +   if (disk->fops->swap_hint)
> >> > +   if (!disk->fops->swap_hint(si->bdev,
> >> > +   SWAP_GET_FREE,
> >> > +   ))
> >> > +   return free <= 0;
> >> > +   }
> >> > +
> >> > +   return si->inuse_pages == si->pages;
> >> > +}
> >> > +
> >> >  static unsigned long scan_swap_map(struct swap_info_struct *si,
> >> >unsigned char usage)
> >> >  {
> >> > @@ -583,11 +599,21 @@ checks:
> >> > if (offset == si->highest_bit)
> >> > si->highest_bit--;
> >> > si->inuse_pages++;
> >> > -   if (si->inuse_pages == si->pages) {
> >> > +   if (__swap_full(si)) {
> >>
> >> This check is done after an available offset has already been
> >> selected.  So if the variable-size blkdev is full at this point, then
> >> this is incorrect, as swap will try to store a page at the current
> >> selected offset.
> >
> > So the result is just fail of a write then what happens?
> > Page become redirty and keep it in memory so there is no harm.
> 
> Happening once, it's not a big deal.  But it's not as good as not
> happening at all.

With your suggestion, we should check full whevever we need new
swap slot. To me, it's more concern than just a write fail.

> 
> >
> >>
> >> > +   struct gendisk *disk = si->bdev->bd_disk;
> >> > +
> >> > si->lowest_bit = si->max;
> >> > si->highest_bit = 0;
> >> > spin_lock(_avail_lock);
> >> > plist_del(>avail_list, _avail_head);
> >> > +   /*
> >> > +* If zram is full, it decreases nr_swap_pages
> >> > +* for stopping anonymous page reclaim until
> >> > +* zram has free space. Look at swap_entry_free
> >> > +*/
> >> > +   if (disk->fops->swap_hint)
> >>
> >> Simply checking for the existence of swap_hint isn't enough to know
> >> we're using zram...
> >
> > Yes but acutally the hint have been used for only zram for several years.
> > If other user is coming in future, we would add more checks if we really
> > need it at that time.
> > Do you have another idea?
> 
> Well if this hint == zram just rename it zram.  Especially if it's now
> going to be explicitly used to mean it == zram.  But I don't think
> that is necessary.

I'd like to clarify your comment. So, are 

Re: [PATCH v2 1/3] virtio-rng cleanup: move some code out of mutex protection

[Amos Kong]

On Mon, Sep 15, 2014 at 06:13:20PM +0200, Michael Büsch wrote:
> On Tue, 16 Sep 2014 00:02:27 +0800
> Amos Kong  wrote:
> 
> > It doesn't save too much cpu time as expected, just a cleanup.
> > 
> > Signed-off-by: Amos Kong 
> > ---
> >  drivers/char/hw_random/core.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > index aa30a25..c591d7e 100644
> > --- a/drivers/char/hw_random/core.c
> > +++ b/drivers/char/hw_random/core.c
> > @@ -270,8 +270,8 @@ static ssize_t hwrng_attr_current_show(struct device 
> > *dev,
> > return -ERESTARTSYS;
> > if (current_rng)
> > name = current_rng->name;
> > -   ret = snprintf(buf, PAGE_SIZE, "%s\n", name);
> > mutex_unlock(_mutex);
> > +   ret = snprintf(buf, PAGE_SIZE, "%s\n", name);
> 
> I'm not sure this is safe.
> Name is just a pointer.
> What if the hwrng gets unregistered after unlock and just before the snprintf?

Oh, it points to protected current_rng->name, I will drop this
cleanup. Thanks.
 
> > return ret;
> >  }
> > @@ -284,19 +284,19 @@ static ssize_t hwrng_attr_available_show(struct 
> > device *dev,
> > ssize_t ret = 0;
> > struct hwrng *rng;
> >  
> > +   buf[0] = '\0';
> > err = mutex_lock_interruptible(_mutex);
> > if (err)
> > return -ERESTARTSYS;
> > -   buf[0] = '\0';
> > list_for_each_entry(rng, _list, list) {
> > strncat(buf, rng->name, PAGE_SIZE - ret - 1);
> > ret += strlen(rng->name);
> > strncat(buf, " ", PAGE_SIZE - ret - 1);
> > ret++;
> > }
> > +   mutex_unlock(_mutex);
> > strncat(buf, "\n", PAGE_SIZE - ret - 1);
> > ret++;
> > -   mutex_unlock(_mutex);
> >  
> > return ret;
> >  }
> 
> This looks ok.
> 
> -- 
> Michael

-- 
Amos.


pgpN_tV90Y3_t.pgp
Description: PGP signature

Re: [PATCH v2 3/3] hw_random: increase schedule timeout in rng_dev_read()

[Amos Kong]

On Mon, Sep 15, 2014 at 06:13:31PM +0200, Michael Büsch wrote:
> On Tue, 16 Sep 2014 00:02:29 +0800
> Amos Kong  wrote:
> 
> > This patch increases the schedule timeout to 10 jiffies, it's more
> > appropriate, then other takes can easy to hold the mutex lock.
> > 
> > Signed-off-by: Amos Kong 
> > ---
> >  drivers/char/hw_random/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > index 263a370..b5d1b6f 100644
> > --- a/drivers/char/hw_random/core.c
> > +++ b/drivers/char/hw_random/core.c
> > @@ -195,7 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char 
> > __user *buf,
> >  
> > mutex_unlock(_mutex);
> >  
> > -   schedule_timeout_interruptible(1);
> > +   schedule_timeout_interruptible(10);
> >  
> > if (signal_pending(current)) {
> > err = -ERESTARTSYS;
> 
> Does a schedule of 1 ms or 10 ms decrease the throughput?

In my test environment, 1 jiffe always works (100%), as suggested by
Amit 10 jiffes is more appropriate.

After applied current 3 patches, there is a throughput regression.

  1.2 M/s -> 6 K/s

We can only schedule in the end of loop (size == 0), and only for
non-smp guest. So smp guest won't be effected.

|   if (!size && num_online_cpus() == 1)
|   schedule_timeout_interruptible(timeout);


Set timeout to 1:
  non-smp guest with quick backend (1.2M/s) -> about 49K/s)

Set timeout to 10:
  non-smp guest with quick backend (1.2M/s) -> about 490K/s)

We might need other benchmark to test the performance, but we can
see the bug clearly caused a regression.

As we discussed in other thread, need_resched() should work in this
case, so those patches might be wrong fixing.

> I think we need some benchmarks.
> 
> -- 
> Michael



-- 
Amos.


pgpHIRzKgHNcE.pgp
Description: PGP signature

Re: [RESEND] x86: numa: setup_node_data(): drop dead code and rename function

[Luiz Capitulino]

00] Zone ranges:
> > [0.00]   DMA  [mem 0x1000-0x00ff]
> > [0.00]   DMA32[mem 0x0100-0x]
> > [0.00]   Normal   [mem 0x1-0x1081f]
> > [0.00] Movable zone start for each node
> > [0.00] Early memory node ranges
> > [0.00]   node   0: [mem 0x1000-0x0009efff]
> > [0.00]   node   0: [mem 0x0010-0x7ffe]
> > [0.00]   node   1: [mem 0x8020-0xf7ff]
> > [0.00]   node   1: [mem 0x1-0x1081f]
> > [0.00] Initmem setup node 0 [mem 0x1000-0x7ffe]
> > [0.00] On node 0 totalpages: 524174
> > [0.00]   DMA zone: 64 pages used for memmap
> > [0.00]   DMA zone: 21 pages reserved
> > [0.00]   DMA zone: 3998 pages, LIFO batch:0
> > [0.00]   DMA32 zone: 8128 pages used for memmap
> > [0.00]   DMA32 zone: 520176 pages, LIFO batch:31
> > [0.00] Initmem setup node 1 [mem 0x8020-0x1081f]
> > [0.00] On node 1 totalpages: 524288
> > [0.00]   DMA32 zone: 7672 pages used for memmap
> > [0.00]   DMA32 zone: 491008 pages, LIFO batch:31
> > [0.00]   Normal zone: 520 pages used for memmap
> > [0.00]   Normal zone: 33280 pages, LIFO batch:7
> > 
> > This commit was tested on a two node bare-metal NUMA machine and Linux as
> > a numa guest on hyperv and qemu/kvm.
> > 
> > PS: The wrong memory range reported by setup_node_data() seems to be
> > harmless in the current kernel because it's just not used.  However,
> > that bad range is used in kernel 2.6.32 to initialize the old boot
> > memory allocator, which causes a crash during boot.
> > 
> > Signed-off-by: Luiz Capitulino 
> > Cc: Yasuaki Ishimatsu 
> > Cc: Yinghai Lu 
> > Acked-by: Rik van Riel 
> > Cc: Andi Kleen 
> > Cc: David Rientjes 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: Thomas Gleixner 
> > Signed-off-by: Andrew Morton 
> > ---
> > 
> > I posted this patch more than two months ago. Andrew picked it up and it
> > rested in the -mm tree for a couple of weeks. Andrew dropped it from -mm
> > to move it forward, but looks like it hasn't been picked by anyone else
> > since then. Resending...
> > 
> 
> This is still in linux-next-20140915 and I doubt it's 3.17 material so I'd 
> wait for Andrew to take care of it.

Oh, I thought it had been forgotten because it was dropped from -mm some
weeks ago (dropped for inclusion in mainline, I guess). I'm not targeting
3.17 btw, I just don't want this patch to be forgotten.
--
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] clocksource: arch_timer: Allow the device tree to specify the physical timer

[Sonny Rao]

On Mon, Sep 15, 2014 at 3:51 PM, Christopher Covington
 wrote:
> Hi Sonny,
>
> On 09/15/2014 06:04 PM, Sonny Rao wrote:
>> On Mon, Sep 15, 2014 at 2:52 PM, Sonny Rao  wrote:
>>> On Mon, Sep 15, 2014 at 2:49 PM, Stephen Boyd  wrote:
 On 09/15/14 14:47, Sonny Rao wrote:
> On Mon, Sep 15, 2014 at 1:33 PM, Stephen Boyd  
> wrote:
>> On 09/15/14 04:10, Catalin Marinas wrote:
>>> On Fri, Sep 12, 2014 at 07:59:29PM +0100, Stephen Boyd wrote:
 On 09/12/14 05:14, Marc Zyngier wrote:
> We surely can handle the UNDEF and do something there. We just can't 
> do
> it the way Doug described it above.
 I suggested doing that for something else a while ago and Will and Dave
 we're not thrilled[1]. The suggestion back then was to use DT to
 indicate what mode the kernel is running in.

 [1]
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/105321.html
>>> I think the context was slightly different. As I re-read the thread, it
>>> seems that the discussion was around whether to use some SMC interface
>>> or not based on whether the kernel is running secure or non-secure. The
>>> argument made by Will was to actually specify the type of the firmware
>>> SMC interface in the DT and use it in the kernel (and probably assume
>>> the kernel is running in secure mode if no smc interface is specified in
>>> the DT; you could have both though, running in secure mode and also
>>> having firmware).
>>>
>>> In this arch timer case, we need to work around a firmware bug (or
>>> feature as 32-bit ARM kernels never required CNTVOFF initialisation by
>>> firmware, no matter how small such firmware is). We don't expect a
>>> specific SMC call to initialise CNTVOFF, so we can't describe it in the
>>> DT.
>> Agreed, we can't described SMC calls that don't exist. From my
>> perspective it's just another part of the cpu boot sequence that needs
>> to be handled in the kernel, so describing the requirement via the
>> cpu-boot method seems appropriate. It seems like we're making it harder
>> than it should be by handling the undef when we could have slightly
>> different SMP boot code (and suspend/resume code) depending on the boot
>> method property.
>
> +heiko
>
> So, for the case of rk3288, based on this discussion what I'm going to
> propose is to add code to rockchip.c which looks for a particular SMP
> enable method -- say something like "rockchip,rk3288-smp-secure-svc"
> which will then assume we have been booted in secure SVC mode and do
> the CNTVOFF fixup.  I believe, it will need to do this on the boot CPU
> as well, so I think it will need to scan the DT fairly early on the
> boot CPU and also perform the function there.
>
> I'll look into implementing this and post code.  Comments and
> suggestions appreciated, thanks.

 What goes wrong if we read the cntvoff from the boot CPU during
 smp_prepare_cpus() phase and use that to set the cntvoff on the other
 CPUs? That avoids needing to do anything very early by making the value
 the same. It does mean that cntvoff is some random out of reset value
 for CPU0, but at least it's consistent.
>>>
>>> I think we cannot read the value if we're not in hyp mode.
>>
>> Well, thinking about it a little more, I think you still have a good point.
>>
>> We don't need to do this early on, as long as we haven't started using
>> the arch timers yet.  If we are still able to do this at the point
>> where we're executing the code in arch/arm/mach-rockchip/platsmp.c
>> that finds the enable method then we can just handle it there.
>
> I've been playing around with the probe-based approach and while I need to do
> a lot more testing, it seems to be working for the first tens of instructions.
> I hope to be able to share a draft of that soon. Basically, I just read the
> current NSACR value and write it back (although maybe in the long term we
> would want to make sure a few of those bits are set or cleared). If that
> succeeds, we know we're in secure SVC and can proceed to set up MON and HYP.

Christopher, sounds promising, please do share, thanks!

Marc or Will, what do you guys think about this approach?


>
> Christopher
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by the Linux Foundation.
--
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: build failure after merge of the net tree

[Stephen Rothwell]

Hi all,

After merging the net tree, today's linux-next build
(powerpc ppc64_defconfig) failed like this:

warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 
440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 
440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects 
IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && 
NET_VENDOR_IBM)
warning: (SCSI_FC_ATTRS) selects SCSI_NETLINK which has unmet direct 
dependencies (NET)
warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 
460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet 
direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (SCSI_FC_ATTRS) selects SCSI_NETLINK which has unmet direct 
dependencies (NET)
warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 
440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 
440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects 
IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && 
NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 
460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet 
direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
drivers/built-in.o: In function `.scsi_nl_rcv_msg':
scsi_netlink.c:(.text+0x16455c): undefined reference to `.netlink_ack'
scsi_netlink.c:(.text+0x16456c): undefined reference to `.skb_pull'
scsi_netlink.c:(.text+0x1645e0): undefined reference to `.netlink_capable'
drivers/built-in.o: In function `.scsi_netlink_init':
(.text+0x16471c): undefined reference to `.__netlink_kernel_create'
drivers/built-in.o: In function `.scsi_netlink_exit':
(.text+0x16477c): undefined reference to `.netlink_kernel_release'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ac1c): undefined reference to `.__alloc_skb'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ac60): undefined reference to `.__nlmsg_put'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ace0): undefined reference to `.netlink_broadcast'
drivers/built-in.o: In function `.fc_host_post_event':
(.text+0x16ad24): undefined reference to `.kfree_skb'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16ae48): undefined reference to `.__alloc_skb'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16ae90): undefined reference to `.__nlmsg_put'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16af1c): undefined reference to `.netlink_broadcast'
drivers/built-in.o: In function `.fc_host_post_vendor_event':
(.text+0x16af84): undefined reference to `.kfree_skb'
drivers/built-in.o:(.toc+0x0): undefined reference to `init_net'

Presumably caused by commit 5d6be6a5d486 ("scsi_netlink : Make
SCSI_NETLINK dependent on NET instead of selecting NET").

I used the version of the net tree from next-20140915 (i.e. up to
commit 9e07a422383c ("Merge branch 'bridge_vlan_filtering'")) for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP completely

[Simon Horman]

On Tue, Sep 16, 2014 at 09:09:17AM +0900, Simon Horman wrote:
> On Fri, Sep 12, 2014 at 10:38:31AM +0200, Paul Bolle wrote:
> > The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit
> > 049d595a4db3 ("PM / OPP: Make OPP invisible to users in Kconfig")
> > removed the only dependency that used it. Setting it had no effect
> > anymore.
> > 
> > So commit 78c5e0bb145d ("PM / OPP: Remove ARCH_HAS_OPP") removed it. For
> > some reason that commit did not remove all select statements for that
> > symbol. These statements are useless. Remove them too.
> > 
> > Signed-off-by: Paul Bolle 
> > ---
> > Done on top of next-20140912. Tested with git grep only!
> 
> Hi Paul,
> 
> could you break the shmobile portion out into a separate patch
> for me to take through my renesas tree?
> 
> I am concerned that taking those changes via a different
> route will result in conflicts as arch/arm/mach-shmobile/Kconfig
> is often updated.

Of course the above comment is redundant if Rafael
has already taken this patch.

> 
> >  arch/arm/mach-omap2/Kconfig| 5 -
> >  arch/arm/mach-shmobile/Kconfig | 1 -
> >  drivers/devfreq/Kconfig| 1 -
> >  3 files changed, 7 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 5b103099626d..f138bd33a463 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -22,7 +22,6 @@ config ARCH_OMAP4
> > bool "TI OMAP4"
> > depends on ARCH_MULTI_V7
> > select ARCH_OMAP2PLUS
> > -   select ARCH_HAS_OPP
> > select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
> > select ARM_CPU_SUSPEND if PM
> > select ARM_ERRATA_720789
> > @@ -41,7 +40,6 @@ config SOC_OMAP5
> > bool "TI OMAP5"
> > depends on ARCH_MULTI_V7
> > select ARCH_OMAP2PLUS
> > -   select ARCH_HAS_OPP
> > select ARM_CPU_SUSPEND if PM
> > select ARM_GIC
> > select HAVE_ARM_SCU if SMP
> > @@ -53,14 +51,12 @@ config SOC_AM33XX
> > bool "TI AM33XX"
> > depends on ARCH_MULTI_V7
> > select ARCH_OMAP2PLUS
> > -   select ARCH_HAS_OPP
> > select ARM_CPU_SUSPEND if PM
> >  
> >  config SOC_AM43XX
> > bool "TI AM43x"
> > depends on ARCH_MULTI_V7
> > select ARCH_OMAP2PLUS
> > -   select ARCH_HAS_OPP
> > select ARM_GIC
> > select MACH_OMAP_GENERIC
> > select MIGHT_HAVE_CACHE_L2X0
> > @@ -69,7 +65,6 @@ config SOC_DRA7XX
> > bool "TI DRA7XX"
> > depends on ARCH_MULTI_V7
> > select ARCH_OMAP2PLUS
> > -   select ARCH_HAS_OPP
> > select ARM_CPU_SUSPEND if PM
> > select ARM_GIC
> > select HAVE_ARM_ARCH_TIMER
> > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> > index 21f457b56c01..f59019dd986e 100644
> > --- a/arch/arm/mach-shmobile/Kconfig
> > +++ b/arch/arm/mach-shmobile/Kconfig
> > @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI
> > select NO_IOPORT_MAP
> > select PINCTRL
> > select ARCH_REQUIRE_GPIOLIB
> > -   select ARCH_HAS_OPP
> >  
> >  if ARCH_SHMOBILE_MULTI
> >  
> > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> > index 3dced0a9eae3..2227e9bf3884 100644
> > --- a/drivers/devfreq/Kconfig
> > +++ b/drivers/devfreq/Kconfig
> > @@ -80,7 +80,6 @@ config ARM_EXYNOS4_BUS_DEVFREQ
> >  config ARM_EXYNOS5_BUS_DEVFREQ
> > bool "ARM Exynos5250 Bus DEVFREQ Driver"
> > depends on SOC_EXYNOS5250
> > -   select ARCH_HAS_OPP
> > select DEVFREQ_GOV_SIMPLE_ONDEMAND
> > select PM_OPP
> > help
> > -- 
> > 1.9.3
> > 
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] tty: serial: msm: Add earlycon support

[Stephen Boyd]

Add support for DT based and command line based early console on platforms
with the msm serial hardware.

Cc: Rob Herring 
Signed-off-by: Stephen Boyd 
---

Changes since v1:
 * Add kernel commandline support

 Documentation/kernel-parameters.txt | 12 ++
 drivers/tty/serial/Kconfig  |  1 +
 drivers/tty/serial/msm_serial.c | 74 +++--
 3 files changed, 75 insertions(+), 12 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 5ae8608ca9f5..22302931e9d4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -936,6 +936,18 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
must already be setup and configured. Options are not
yet supported.
 
+   msm_serial,
+   Start an early, polled-mode console on an msm serial
+   port at the specified address. The serial port
+   must already be setup and configured. Options are not
+   yet supported.
+
+   msm_serial_dm,
+   Start an early, polled-mode console on an msm serial
+   dm port at the specified address. The serial port
+   must already be setup and configured. Options are not
+   yet supported.
+
smh Use ARM semihosting calls for early console.
 
earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 81f6ee7d4223..d609d605f712 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1070,6 +1070,7 @@ config SERIAL_MSM_CONSOLE
bool "MSM serial console support"
depends on SERIAL_MSM=y
select SERIAL_CORE_CONSOLE
+   select SERIAL_EARLYCON
 
 config SERIAL_MSM_HS
tristate "MSM UART High Speed: Serial Driver"
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 4f9640d0b1bb..4b6c78331a64 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -845,22 +845,15 @@ static inline struct uart_port 
*get_port_from_line(unsigned int line)
 }
 
 #ifdef CONFIG_SERIAL_MSM_CONSOLE
-static void msm_console_write(struct console *co, const char *s,
- unsigned int count)
+static void __msm_console_write(struct uart_port *port, const char *s,
+   unsigned int count, bool is_uartdm)
 {
int i;
-   struct uart_port *port;
-   struct msm_port *msm_port;
int num_newlines = 0;
bool replaced = false;
void __iomem *tf;
 
-   BUG_ON(co->index < 0 || co->index >= UART_NR);
-
-   port = get_port_from_line(co->index);
-   msm_port = UART_TO_MSM(port);
-
-   if (msm_port->is_uartdm)
+   if (is_uartdm)
tf = port->membase + UARTDM_TF;
else
tf = port->membase + UART_TF;
@@ -872,7 +865,7 @@ static void msm_console_write(struct console *co, const 
char *s,
count += num_newlines;
 
spin_lock(>lock);
-   if (msm_port->is_uartdm)
+   if (is_uartdm)
reset_dm_count(port, count);
 
i = 0;
@@ -881,7 +874,7 @@ static void msm_console_write(struct console *co, const 
char *s,
unsigned int num_chars;
char buf[4] = { 0 };
 
-   if (msm_port->is_uartdm)
+   if (is_uartdm)
num_chars = min(count - i, (unsigned int)sizeof(buf));
else
num_chars = 1;
@@ -910,6 +903,20 @@ static void msm_console_write(struct console *co, const 
char *s,
spin_unlock(>lock);
 }
 
+static void msm_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+   struct uart_port *port;
+   struct msm_port *msm_port;
+
+   BUG_ON(co->index < 0 || co->index >= UART_NR);
+
+   port = get_port_from_line(co->index);
+   msm_port = UART_TO_MSM(port);
+
+   __msm_console_write(port, s, count, msm_port->is_uartdm);
+}
+
 static int __init msm_console_setup(struct console *co, char *options)
 {
struct uart_port *port;
@@ -952,6 +959,49 @@ static int __init msm_console_setup(struct console *co, 
char *options)
return uart_set_options(port, co, baud, parity, bits, flow);
 }
 
+static void
+msm_serial_early_write(struct console *con, const char *s, unsigned n)
+{
+   struct earlycon_device *dev = con->data;
+
+   __msm_console_write(>port, s, n, false);
+}
+
+static int __init
+msm_serial_early_console_setup(struct earlycon_device *device, const char *opt)
+{
+   if (!device->port.membase)
+   return -ENODEV;
+
+   device->con->write = msm_serial_early_write;
+   return 0;
+}
+EARLYCON_DECLARE(msm_serial, 

Implement lbr-as-callgraph v9

[Andi Kleen]

[Just a repost after a rebase]
[Even more review feedback and some bugs addressed.]
[Only port to changes in perf/core. No other changes.]
[Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport,
as an alternative way to present LBR information.

Current perf report does a histogram over the branch edges,
which is useful to look at basic blocks, but doesn't tell
you anything about the larger control flow behaviour.

This patchkit adds a new option --branch-history that
adds the branch paths to the callgraph history instead.

This allows to reason about individual branch paths leading
to specific samples.

Also available at
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/lbr-callgraph4

v2:
- rebased on perf/core
- fix various issues
- rename the option to --branch-history
- various fixes to display the information more concise
v3:
- White space changes
- Consolidate some patches
- Update some descriptions
v4:
- Fix various display problems
- Unknown srcline is now printed as symbol+offset
- Refactor some code to address review feedback
- Merge with latest tip
- Fix missing srcline display in stdio hist output.
v5:
- Rename functions
- Fix gtk build problem
- Fix crash without -g
- Improve error messages
- Improve srcline display in various ways
v6:
- Port to latest perf/core
v7:
- Really port to latest perf/core
v8:
- Rebased on 3.16-rc1
v9:
- Rebase on 3.17-rc* tip/perf/core


Example output:

% perf record -b -g ./tsrc/tcall
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.044 MB perf.data (~1923 samples) ]
% perf report --branch-history
...
54.91%  tcall.c:6  [.] f2  tcall
|
|--65.53%-- f2 tcall.c:5
|  |
|  |--70.83%-- f1 tcall.c:11
|  |  f1 tcall.c:10
|  |  main tcall.c:18
|  |  main tcall.c:18
|  |  main tcall.c:17
|  |  main tcall.c:17
|  |  f1 tcall.c:13
|  |  f1 tcall.c:13
|  |  f2 tcall.c:7
|  |  f2 tcall.c:5
|  |  f1 tcall.c:12
|  |  f1 tcall.c:12
|  |  f2 tcall.c:7
|  |  f2 tcall.c:5
|  |  f1 tcall.c:11


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