Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints

[Michal Hocko]

On Fri 30-12-16 09:11:17, Mel Gorman wrote:
> On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote:
> > Hi,
> > while debugging [1] I've realized that there is some room for
> > improvements in the tracepoints set we offer currently. I had hard times
> > to make any conclusion from the existing ones. The resulting problem
> > turned out to be active list aging [2] and we are missing at least two
> > tracepoints to debug such a problem.
> > 
> > Some existing tracepoints could export more information to see _why_ the
> > reclaim progress cannot be made not only _how much_ we could reclaim.
> > The later could be seen quite reasonably from the vmstat counters
> > already. It can be argued that we are showing too many implementation
> > details in those tracepoints but I consider them way too lowlevel
> > already to be usable by any kernel independent userspace. I would be
> > _really_ surprised if anything but debugging tools have used them.
> > 
> > Any feedback is highly appreciated.
> > 
> 
> There is some minor overhead introduced in some paths regardless of
> whether the tracepoints are active or not but I suspect it's negligible
> in the context of the overhead of reclaim in general so;

I will work on improving some of them. E.g. I've dropped the change to
free_hot_cold_page_list because that is indeed a hot path but other than
that there shouldn't be any even medium hot path which should see any
overhead I can see. If you are aware of any, please let me know and I
will think about how to improve it.
 
> Acked-by: Mel Gorman 

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints

[Michal Hocko]

On Fri 30-12-16 09:11:17, Mel Gorman wrote:
> On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote:
> > Hi,
> > while debugging [1] I've realized that there is some room for
> > improvements in the tracepoints set we offer currently. I had hard times
> > to make any conclusion from the existing ones. The resulting problem
> > turned out to be active list aging [2] and we are missing at least two
> > tracepoints to debug such a problem.
> > 
> > Some existing tracepoints could export more information to see _why_ the
> > reclaim progress cannot be made not only _how much_ we could reclaim.
> > The later could be seen quite reasonably from the vmstat counters
> > already. It can be argued that we are showing too many implementation
> > details in those tracepoints but I consider them way too lowlevel
> > already to be usable by any kernel independent userspace. I would be
> > _really_ surprised if anything but debugging tools have used them.
> > 
> > Any feedback is highly appreciated.
> > 
> 
> There is some minor overhead introduced in some paths regardless of
> whether the tracepoints are active or not but I suspect it's negligible
> in the context of the overhead of reclaim in general so;

I will work on improving some of them. E.g. I've dropped the change to
free_hot_cold_page_list because that is indeed a hot path but other than
that there shouldn't be any even medium hot path which should see any
overhead I can see. If you are aware of any, please let me know and I
will think about how to improve it.
 
> Acked-by: Mel Gorman 

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> Hi lists,
> 
> Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks
> on linux-next tree, now on Linus tree.
> 
> In "normal", rwtest01 subcase ends in a few minutes, now it keeps
> running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c
> can interrupt it.

Test programme is waiting for a memcpy call to return.

>From sysrq output, kernel code is not blocking on somewhere,
it just wont return.

> 
> It is always reproducible, blocking following tests.
> 
> It does not happen when mounting without dax option.
> It does not happen on v4.9.
> 
> Bisect point to:
> 
> commit 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
> Author: Jan Kara 
> Date:   Wed Dec 14 15:07:53 2016 -0800
> 
> dax: clear dirty entry tags on cache flush
> 
> 
> Reverting this commit on top of Linus tree "fixes" this issue.
> 
> Reproducer:
> 
> sh-4.2# cat rwt
> rwtest01 export LTPROOT; rwtest -N rwtest01 -c -q -i 60s  -f sync 
> 10%25000:$TMPDIR/rw-sync-$$
> sh-4.2# 
> mkfs.xfs /dev/pmem0p1
> mount -o dax /dev/pmem0p1 /daxmnt && \
> /opt/ltp/runltp -q -d /daxmnt -f rwt -p -b /dev/pmem0p2 -B xfs
> umount /daxmnt
> 
> Bisect log is attached.
> 
> Thanks,
> Xiong

> git bisect start
> # bad: [50f6584e4c626b8fa39edb66f33fec27bab3996c] Merge tag 
> 'leds_for_4.10_email_update' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
> git bisect bad 50f6584e4c626b8fa39edb66f33fec27bab3996c
> # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
> git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> # good: [5266e70335dac35c35b5ca9cea4251c1389d4a68] Merge tag 'tty-4.10-rc1' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> git bisect good 5266e70335dac35c35b5ca9cea4251c1389d4a68
> # bad: [6df8b74b1720db1133ace0861cb6721bfe57819a] Merge tag 
> 'devicetree-for-4.10' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> git bisect bad 6df8b74b1720db1133ace0861cb6721bfe57819a
> # good: [f4000cd99750065d5177555c0a805c97174d1b9f] Merge tag 'arm64-upstream' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect good f4000cd99750065d5177555c0a805c97174d1b9f
> # bad: [e1e14ab8411df344a17687821f8f78f0a1e73cbb] radix tree test suite: 
> delete unused rcupdate.c
> git bisect bad e1e14ab8411df344a17687821f8f78f0a1e73cbb
> # good: [f5b893c947151d424a4ab55ea3a8544b81974b31] scsi: qla4xxx: switch to 
> pci_alloc_irq_vectors
> git bisect good f5b893c947151d424a4ab55ea3a8544b81974b31
> # good: [b9f98bd4034a3196ff068eb0fa376c5f41077480] Merge tag 'mmc-v4.10-2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
> git bisect good b9f98bd4034a3196ff068eb0fa376c5f41077480
> # good: [4d1f0fb096aedea7bb5489af93498a82e467c480] kernel/watchdog: use nmi 
> registers snapshot in hardlockup handler
> git bisect good 4d1f0fb096aedea7bb5489af93498a82e467c480
> # good: [5b56d49fc31dbb0487e14ead790fc81ca9fb2c99] mm: add locked parameter 
> to get_user_pages_remote()
> git bisect good 5b56d49fc31dbb0487e14ead790fc81ca9fb2c99
> # bad: [cfa40bcfd6fed7010b1633bf127ed8571d3b607e] radix tree test suite: 
> benchmark for iterator
> git bisect bad cfa40bcfd6fed7010b1633bf127ed8571d3b607e
> # good: [a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54] mm: use vmf->page during 
> WP faults
> git bisect good a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54
> # bad: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear dirty entry tags 
> on cache flush
> git bisect bad 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
> # good: [a19e25536ed3a20845f642ce531e10c27fb2add5] mm: change return values 
> of finish_mkwrite_fault()
> git bisect good a19e25536ed3a20845f642ce531e10c27fb2add5
> # good: [a6abc2c0e77b16480f4d2c1eb7925e5287ae1526] dax: make cache flushing 
> protected by entry lock
> git bisect good a6abc2c0e77b16480f4d2c1eb7925e5287ae1526
> # good: [2f89dc12a25ddf995b9acd7b6543fe892e3473d6] dax: protect PTE 
> modification on WP fault by radix tree entry lock
> git bisect good 2f89dc12a25ddf995b9acd7b6543fe892e3473d6
> # first bad commit: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear 
> dirty entry tags on cache flush

> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: LTP rwtest01 blocks on DAX mountpoint

[Xiong Zhou]

On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote:
> Hi lists,
> 
> Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks
> on linux-next tree, now on Linus tree.
> 
> In "normal", rwtest01 subcase ends in a few minutes, now it keeps
> running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c
> can interrupt it.

Test programme is waiting for a memcpy call to return.

>From sysrq output, kernel code is not blocking on somewhere,
it just wont return.

> 
> It is always reproducible, blocking following tests.
> 
> It does not happen when mounting without dax option.
> It does not happen on v4.9.
> 
> Bisect point to:
> 
> commit 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
> Author: Jan Kara 
> Date:   Wed Dec 14 15:07:53 2016 -0800
> 
> dax: clear dirty entry tags on cache flush
> 
> 
> Reverting this commit on top of Linus tree "fixes" this issue.
> 
> Reproducer:
> 
> sh-4.2# cat rwt
> rwtest01 export LTPROOT; rwtest -N rwtest01 -c -q -i 60s  -f sync 
> 10%25000:$TMPDIR/rw-sync-$$
> sh-4.2# 
> mkfs.xfs /dev/pmem0p1
> mount -o dax /dev/pmem0p1 /daxmnt && \
> /opt/ltp/runltp -q -d /daxmnt -f rwt -p -b /dev/pmem0p2 -B xfs
> umount /daxmnt
> 
> Bisect log is attached.
> 
> Thanks,
> Xiong

> git bisect start
> # bad: [50f6584e4c626b8fa39edb66f33fec27bab3996c] Merge tag 
> 'leds_for_4.10_email_update' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
> git bisect bad 50f6584e4c626b8fa39edb66f33fec27bab3996c
> # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
> git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> # good: [5266e70335dac35c35b5ca9cea4251c1389d4a68] Merge tag 'tty-4.10-rc1' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> git bisect good 5266e70335dac35c35b5ca9cea4251c1389d4a68
> # bad: [6df8b74b1720db1133ace0861cb6721bfe57819a] Merge tag 
> 'devicetree-for-4.10' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
> git bisect bad 6df8b74b1720db1133ace0861cb6721bfe57819a
> # good: [f4000cd99750065d5177555c0a805c97174d1b9f] Merge tag 'arm64-upstream' 
> of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect good f4000cd99750065d5177555c0a805c97174d1b9f
> # bad: [e1e14ab8411df344a17687821f8f78f0a1e73cbb] radix tree test suite: 
> delete unused rcupdate.c
> git bisect bad e1e14ab8411df344a17687821f8f78f0a1e73cbb
> # good: [f5b893c947151d424a4ab55ea3a8544b81974b31] scsi: qla4xxx: switch to 
> pci_alloc_irq_vectors
> git bisect good f5b893c947151d424a4ab55ea3a8544b81974b31
> # good: [b9f98bd4034a3196ff068eb0fa376c5f41077480] Merge tag 'mmc-v4.10-2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
> git bisect good b9f98bd4034a3196ff068eb0fa376c5f41077480
> # good: [4d1f0fb096aedea7bb5489af93498a82e467c480] kernel/watchdog: use nmi 
> registers snapshot in hardlockup handler
> git bisect good 4d1f0fb096aedea7bb5489af93498a82e467c480
> # good: [5b56d49fc31dbb0487e14ead790fc81ca9fb2c99] mm: add locked parameter 
> to get_user_pages_remote()
> git bisect good 5b56d49fc31dbb0487e14ead790fc81ca9fb2c99
> # bad: [cfa40bcfd6fed7010b1633bf127ed8571d3b607e] radix tree test suite: 
> benchmark for iterator
> git bisect bad cfa40bcfd6fed7010b1633bf127ed8571d3b607e
> # good: [a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54] mm: use vmf->page during 
> WP faults
> git bisect good a41b70d6dfc28b9e1a17c2a9f3181c2b614bfd54
> # bad: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear dirty entry tags 
> on cache flush
> git bisect bad 4b4bb46d00b386e1c972890dc5785a7966eaa9c0
> # good: [a19e25536ed3a20845f642ce531e10c27fb2add5] mm: change return values 
> of finish_mkwrite_fault()
> git bisect good a19e25536ed3a20845f642ce531e10c27fb2add5
> # good: [a6abc2c0e77b16480f4d2c1eb7925e5287ae1526] dax: make cache flushing 
> protected by entry lock
> git bisect good a6abc2c0e77b16480f4d2c1eb7925e5287ae1526
> # good: [2f89dc12a25ddf995b9acd7b6543fe892e3473d6] dax: protect PTE 
> modification on WP fault by radix tree entry lock
> git bisect good 2f89dc12a25ddf995b9acd7b6543fe892e3473d6
> # first bad commit: [4b4bb46d00b386e1c972890dc5785a7966eaa9c0] dax: clear 
> dirty entry tags on cache flush

> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

[Michal Hocko]

On Fri 30-12-16 10:56:25, Minchan Kim wrote:
> On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote:
> > On Thu 29-12-16 15:02:04, Minchan Kim wrote:
> > > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote:
> > > > From: Michal Hocko 
> > > > 
> > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate
> > > > from is file or anonymous but we do not know which LRU this is. It is
> > > > useful to know whether the list is file or anonymous as well. Change
> > > > the tracepoint to show symbolic names of the lru rather.
> > > > 
> > > > Signed-off-by: Michal Hocko 
> > > 
> > > Not exactly same with this but idea is almost same.
> > > I used almost same tracepoint to investigate agging(i.e., deactivating) 
> > > problem
> > > in 32b kernel with node-lru.
> > > It was enough. Namely, I didn't need tracepoint in shrink_active_list 
> > > like your
> > > first patch.
> > > Your first patch is more straightforwad and information. But as you 
> > > introduced
> > > this patch, I want to ask in here.
> > > Isn't it enough with this patch without your first one to find a such 
> > > problem?
> > 
> > I assume this should be a reply to
> > http://lkml.kernel.org/r/20161228153032.10821-8-mho...@kernel.org, right?
> 
> I don't know my browser says "No such Message-ID known"

Hmm, not sure why it didn't get archived at lkml.kernel.org.
I meant https://lkml.org/lkml/2016/12/28/167
 
> > And you are right that for the particular problem it was enough to have
> > a tracepoint inside inactive_list_is_low and shrink_active_list one
> > wasn't really needed. On the other hand aging issues are really hard to
> 
> What kinds of aging issue? What's the problem? How such tracepoint can help?
> Please describe.

If you do not see that active list is shrunk then you do not know why it
is not shrunk. It might be a active/inactive ratio or just a plan bug
like the 32b issue me and you were debugging.

> > debug as well and so I think that both are useful. The first one tell us
> > _why_ we do aging while the later _how_ we do that.
> 
> Solve reported problem first you already knew. It would be no doubt
> to merge and then send other patches about "it might be useful" with
> useful scenario.

I am not sure I understand. The point of tracepoints is to be
pro-actively helpful not only to add something that has been useful in
one-off cases. A particular debugging session might be really helpful to
tell us what we are missing and this was the case here to a large part.
Once I was looking there I just wanted to save the pain of adding more
debugging information in future and allow people to debug their issue
without forcing them to recompile the kernel. I believe this is one of
the strong usecases for tracepoints in the first place.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 4/7] mm, vmscan: show LRU name in mm_vmscan_lru_isolate tracepoint

[Michal Hocko]

On Fri 30-12-16 10:56:25, Minchan Kim wrote:
> On Thu, Dec 29, 2016 at 08:56:49AM +0100, Michal Hocko wrote:
> > On Thu 29-12-16 15:02:04, Minchan Kim wrote:
> > > On Wed, Dec 28, 2016 at 04:30:29PM +0100, Michal Hocko wrote:
> > > > From: Michal Hocko 
> > > > 
> > > > mm_vmscan_lru_isolate currently prints only whether the LRU we isolate
> > > > from is file or anonymous but we do not know which LRU this is. It is
> > > > useful to know whether the list is file or anonymous as well. Change
> > > > the tracepoint to show symbolic names of the lru rather.
> > > > 
> > > > Signed-off-by: Michal Hocko 
> > > 
> > > Not exactly same with this but idea is almost same.
> > > I used almost same tracepoint to investigate agging(i.e., deactivating) 
> > > problem
> > > in 32b kernel with node-lru.
> > > It was enough. Namely, I didn't need tracepoint in shrink_active_list 
> > > like your
> > > first patch.
> > > Your first patch is more straightforwad and information. But as you 
> > > introduced
> > > this patch, I want to ask in here.
> > > Isn't it enough with this patch without your first one to find a such 
> > > problem?
> > 
> > I assume this should be a reply to
> > http://lkml.kernel.org/r/20161228153032.10821-8-mho...@kernel.org, right?
> 
> I don't know my browser says "No such Message-ID known"

Hmm, not sure why it didn't get archived at lkml.kernel.org.
I meant https://lkml.org/lkml/2016/12/28/167
 
> > And you are right that for the particular problem it was enough to have
> > a tracepoint inside inactive_list_is_low and shrink_active_list one
> > wasn't really needed. On the other hand aging issues are really hard to
> 
> What kinds of aging issue? What's the problem? How such tracepoint can help?
> Please describe.

If you do not see that active list is shrunk then you do not know why it
is not shrunk. It might be a active/inactive ratio or just a plan bug
like the 32b issue me and you were debugging.

> > debug as well and so I think that both are useful. The first one tell us
> > _why_ we do aging while the later _how_ we do that.
> 
> Solve reported problem first you already knew. It would be no doubt
> to merge and then send other patches about "it might be useful" with
> useful scenario.

I am not sure I understand. The point of tracepoints is to be
pro-actively helpful not only to add something that has been useful in
one-off cases. A particular debugging session might be really helpful to
tell us what we are missing and this was the case here to a large part.
Once I was looking there I just wanted to save the pain of adding more
debugging information in future and allow people to debug their issue
without forcing them to recompile the kernel. I believe this is one of
the strong usecases for tracepoints in the first place.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint

[Michal Hocko]

On Fri 30-12-16 10:48:53, Minchan Kim wrote:
> On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote:
> > On Thu 29-12-16 14:33:59, Minchan Kim wrote:
> > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote:
[...]
> > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active,
> > > > +
> > > > +   TP_PROTO(int nid, unsigned long nr_scanned, unsigned long 
> > > > nr_freed,
> > > > +   unsigned long nr_unevictable, unsigned long 
> > > > nr_deactivated,
> > > > +   unsigned long nr_rotated, int priority, int file),
> > > > +
> > > > +   TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, 
> > > > nr_deactivated, nr_rotated, priority, file),
> > > 
> > > I agree it is helpful. And it was when I investigated aging problem of 
> > > 32bit
> > > when node-lru was introduced. However, the question is we really need all 
> > > those
> > > kinds of information? just enough with nr_taken, nr_deactivated, 
> > > priority, file?
> > 
> > Dunno. Is it harmful to add this information? I like it more when the
> > numbers just add up and you have a clear picture. You never know what
> > might be useful when debugging a weird behavior. 
> 
> Michal, I'm not huge fan of "might be useful" although it's a small piece of 
> code.

But these are tracepoints. One of their primary reasons to exist is
to help debug things.  And it is really hard to predict what might be
useful in advance. It is not like the patch would export numbers which
would be irrelevant to the reclaim.

> It adds just all of kinds overheads (memory footprint, runtime performance,
> maintainance) without any proved benefit.

Does it really add any measurable overhead or the maintenance burden? I
think the only place we could argue about is free_hot_cold_page_list
which is used in hot paths.

I think we can sacrifice it. The same for culled unevictable
pages. We wouldn't know what is the missing part
nr_taken-(nr_activate+nr_deactivate) because it could be either freed or
moved to the unevictable list but that could be handled in a separate
tracepoint in putback_lru_page which sounds like a useful thing I guess.
 
> If we allow such things, people would start adding more things with just "why 
> not,
> it might be useful. you never know the future" and it ends up making linux 
> fiction
> novel mess.

I agree with this concern in general, but is this the case in this
particular case?

> If it's necessary, someday, someone will catch up and will send or ask patch 
> with
> detailed description "why the stat is important and how it is good for us to 
> solve
> some problem".

I can certainly enhance the changelog. See below.

> From that, we can learn workload, way to solve the problem and git
> history has the valuable description so new comers can keep the community up 
> easily.
> So, finally, overheads are justified and get merged.
> 
> Please add must-have for your goal described.

My primary point is that tracepoints which do not give us a good picture
are quite useless and force us to add trace_printk or other means to
give us further information. Then I wonder why to have an incomplete
tracepoint at all.

Anyway, what do you think about this updated patch? I have kept Hillf's
A-b so please let me know if it is no longer valid.
--- 
>From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Tue, 27 Dec 2016 13:18:20 +0100
Subject: [PATCH] mm, vmscan: add active list aging tracepoint

Our reclaim process has several tracepoints to tell us more about how
things are progressing. We are, however, missing a tracepoint to track
active list aging. Introduce mm_vmscan_lru_shrink_active which reports
the number of
- nr_scanned, nr_taken pages to tell us the LRU isolation
  effectiveness.
- nr_rotated pages which tells us that we are hitting referenced
  pages which are deactivated. If this is a large part of the
  reported nr_deactivated pages then the active list is too small
- nr_activated pages which tells us how many pages are keept on the
  active list - mostly exec pages. A high number can indicate
  that we might be trashing on executables.

Changes since v1
- report nr_taken pages as per Minchan
- report nr_activated as per Minchan
- do not report nr_freed pages because that would add a tiny overhead to
  free_hot_cold_page_list which is a hot path
- do not report nr_unevictable because we can report this number via a
  different and more generic tracepoint in putback_lru_page
- fix move_active_pages_to_lru to report proper page count when we hit
  into large pages

Acked-by: Hillf Danton 
Signed-off-by: Michal Hocko 
---
 include/trace/events/vmscan.h | 38 ++
 mm/vmscan.c   | 18 ++
 2 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/vmscan.h 

Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint

[Michal Hocko]

On Fri 30-12-16 10:48:53, Minchan Kim wrote:
> On Thu, Dec 29, 2016 at 08:52:46AM +0100, Michal Hocko wrote:
> > On Thu 29-12-16 14:33:59, Minchan Kim wrote:
> > > On Wed, Dec 28, 2016 at 04:30:27PM +0100, Michal Hocko wrote:
[...]
> > > > +TRACE_EVENT(mm_vmscan_lru_shrink_active,
> > > > +
> > > > +   TP_PROTO(int nid, unsigned long nr_scanned, unsigned long 
> > > > nr_freed,
> > > > +   unsigned long nr_unevictable, unsigned long 
> > > > nr_deactivated,
> > > > +   unsigned long nr_rotated, int priority, int file),
> > > > +
> > > > +   TP_ARGS(nid, nr_scanned, nr_freed, nr_unevictable, 
> > > > nr_deactivated, nr_rotated, priority, file),
> > > 
> > > I agree it is helpful. And it was when I investigated aging problem of 
> > > 32bit
> > > when node-lru was introduced. However, the question is we really need all 
> > > those
> > > kinds of information? just enough with nr_taken, nr_deactivated, 
> > > priority, file?
> > 
> > Dunno. Is it harmful to add this information? I like it more when the
> > numbers just add up and you have a clear picture. You never know what
> > might be useful when debugging a weird behavior. 
> 
> Michal, I'm not huge fan of "might be useful" although it's a small piece of 
> code.

But these are tracepoints. One of their primary reasons to exist is
to help debug things.  And it is really hard to predict what might be
useful in advance. It is not like the patch would export numbers which
would be irrelevant to the reclaim.

> It adds just all of kinds overheads (memory footprint, runtime performance,
> maintainance) without any proved benefit.

Does it really add any measurable overhead or the maintenance burden? I
think the only place we could argue about is free_hot_cold_page_list
which is used in hot paths.

I think we can sacrifice it. The same for culled unevictable
pages. We wouldn't know what is the missing part
nr_taken-(nr_activate+nr_deactivate) because it could be either freed or
moved to the unevictable list but that could be handled in a separate
tracepoint in putback_lru_page which sounds like a useful thing I guess.
 
> If we allow such things, people would start adding more things with just "why 
> not,
> it might be useful. you never know the future" and it ends up making linux 
> fiction
> novel mess.

I agree with this concern in general, but is this the case in this
particular case?

> If it's necessary, someday, someone will catch up and will send or ask patch 
> with
> detailed description "why the stat is important and how it is good for us to 
> solve
> some problem".

I can certainly enhance the changelog. See below.

> From that, we can learn workload, way to solve the problem and git
> history has the valuable description so new comers can keep the community up 
> easily.
> So, finally, overheads are justified and get merged.
> 
> Please add must-have for your goal described.

My primary point is that tracepoints which do not give us a good picture
are quite useless and force us to add trace_printk or other means to
give us further information. Then I wonder why to have an incomplete
tracepoint at all.

Anyway, what do you think about this updated patch? I have kept Hillf's
A-b so please let me know if it is no longer valid.
--- 
>From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Tue, 27 Dec 2016 13:18:20 +0100
Subject: [PATCH] mm, vmscan: add active list aging tracepoint

Our reclaim process has several tracepoints to tell us more about how
things are progressing. We are, however, missing a tracepoint to track
active list aging. Introduce mm_vmscan_lru_shrink_active which reports
the number of
- nr_scanned, nr_taken pages to tell us the LRU isolation
  effectiveness.
- nr_rotated pages which tells us that we are hitting referenced
  pages which are deactivated. If this is a large part of the
  reported nr_deactivated pages then the active list is too small
- nr_activated pages which tells us how many pages are keept on the
  active list - mostly exec pages. A high number can indicate
  that we might be trashing on executables.

Changes since v1
- report nr_taken pages as per Minchan
- report nr_activated as per Minchan
- do not report nr_freed pages because that would add a tiny overhead to
  free_hot_cold_page_list which is a hot path
- do not report nr_unevictable because we can report this number via a
  different and more generic tracepoint in putback_lru_page
- fix move_active_pages_to_lru to report proper page count when we hit
  into large pages

Acked-by: Hillf Danton 
Signed-off-by: Michal Hocko 
---
 include/trace/events/vmscan.h | 38 ++
 mm/vmscan.c   | 18 ++
 2 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index 39bad8921ca1..f9ef242ece1b 100644
--- 

[PATCH] ide: palm_bk3710: add __initdata to palm_bk3710_port_info

[Bhumika Goyal]

The object palm_bk3710_port_info of type ide_port_info is never
referenced anywhere after initialization by palm_bk3710_probe. It is
also passed as a parameter to ide_host_add which is called from the init
function but this call doesn't store the object reference anywhere, and
it only dereferences the values of the fields. Therefore add __initdata
to its declaration.

Signed-off-by: Bhumika Goyal 
---

Compiled, but not tested

 drivers/ide/palm_bk3710.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/palm_bk3710.c b/drivers/ide/palm_bk3710.c
index 46427ea..157f2d1 100644
--- a/drivers/ide/palm_bk3710.c
+++ b/drivers/ide/palm_bk3710.c
@@ -300,7 +300,7 @@ static int palm_bk3710_init_dma(ide_hwif_t *hwif, const 
struct ide_port_info *d)
.cable_detect   = palm_bk3710_cable_detect,
 };
 
-static struct ide_port_info palm_bk3710_port_info = {
+static struct ide_port_info palm_bk3710_port_info __initdata = {
.init_dma   = palm_bk3710_init_dma,
.port_ops   = _bk3710_ports_ops,
.dma_ops= _dma_ops,
-- 
1.9.1

[PATCH] ide: palm_bk3710: add __initdata to palm_bk3710_port_info

[Bhumika Goyal]

The object palm_bk3710_port_info of type ide_port_info is never
referenced anywhere after initialization by palm_bk3710_probe. It is
also passed as a parameter to ide_host_add which is called from the init
function but this call doesn't store the object reference anywhere, and
it only dereferences the values of the fields. Therefore add __initdata
to its declaration.

Signed-off-by: Bhumika Goyal 
---

Compiled, but not tested

 drivers/ide/palm_bk3710.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/palm_bk3710.c b/drivers/ide/palm_bk3710.c
index 46427ea..157f2d1 100644
--- a/drivers/ide/palm_bk3710.c
+++ b/drivers/ide/palm_bk3710.c
@@ -300,7 +300,7 @@ static int palm_bk3710_init_dma(ide_hwif_t *hwif, const 
struct ide_port_info *d)
.cable_detect   = palm_bk3710_cable_detect,
 };
 
-static struct ide_port_info palm_bk3710_port_info = {
+static struct ide_port_info palm_bk3710_port_info __initdata = {
.init_dma   = palm_bk3710_init_dma,
.port_ops   = _bk3710_ports_ops,
.dma_ops= _dma_ops,
-- 
1.9.1

Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints

[Mel Gorman]

On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote:
> Hi,
> while debugging [1] I've realized that there is some room for
> improvements in the tracepoints set we offer currently. I had hard times
> to make any conclusion from the existing ones. The resulting problem
> turned out to be active list aging [2] and we are missing at least two
> tracepoints to debug such a problem.
> 
> Some existing tracepoints could export more information to see _why_ the
> reclaim progress cannot be made not only _how much_ we could reclaim.
> The later could be seen quite reasonably from the vmstat counters
> already. It can be argued that we are showing too many implementation
> details in those tracepoints but I consider them way too lowlevel
> already to be usable by any kernel independent userspace. I would be
> _really_ surprised if anything but debugging tools have used them.
> 
> Any feedback is highly appreciated.
> 

There is some minor overhead introduced in some paths regardless of
whether the tracepoints are active or not but I suspect it's negligible
in the context of the overhead of reclaim in general so;

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 0/7] vm, vmscan: enahance vmscan tracepoints

[Mel Gorman]

On Wed, Dec 28, 2016 at 04:30:25PM +0100, Michal Hocko wrote:
> Hi,
> while debugging [1] I've realized that there is some room for
> improvements in the tracepoints set we offer currently. I had hard times
> to make any conclusion from the existing ones. The resulting problem
> turned out to be active list aging [2] and we are missing at least two
> tracepoints to debug such a problem.
> 
> Some existing tracepoints could export more information to see _why_ the
> reclaim progress cannot be made not only _how much_ we could reclaim.
> The later could be seen quite reasonably from the vmstat counters
> already. It can be argued that we are showing too many implementation
> details in those tracepoints but I consider them way too lowlevel
> already to be usable by any kernel independent userspace. I would be
> _really_ surprised if anything but debugging tools have used them.
> 
> Any feedback is highly appreciated.
> 

There is some minor overhead introduced in some paths regardless of
whether the tracepoints are active or not but I suspect it's negligible
in the context of the overhead of reclaim in general so;

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

[Linus Walleij]

On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
 wrote:
> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-König :
>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>> @@ -337,6 +350,16 @@
>>>   slew-rate = <2>;
>>>   };
>>>   };
>>> +
>>> + i2c1_pins_b: i2c1@0 {
>>> + pins1 {
>>> + pinmux = 
>>> ;
>>> + drive-open-drain;
>>> + };
>>> + pins2 {
>>> + pinmux = 
>>> ;
>>> + };
>>
>> the second doesn't need the open-drain property? Why?
>
> I thought that open-drain was only needed for SDA line.
> But after double-checking I2C specification, it seems that SDA and SCL
> lines need open-drain or open-collector to perform the wired-AND
> function.

I think I2C SDA/SCL must be open drain by definition.

It also requires pull-up resistors, I guess you have these mounted on the board
so you do not need pull-up from the pin controller?

Yours,
Linus Walleij

Re: [PATCH v5 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

iort_node_get_id() has two output, one is the mapped ids,
the other is the referenced parent node which is returned
from the function.

For now we need a API just return its parent node for
single mapping, so just update this function slightly then
reuse it later.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Marc Zyngier 
---
  drivers/acpi/arm64/iort.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index ab7bae7..bc68d93 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -347,7 +347,8 @@ struct acpi_iort_node *iort_node_get_id(struct 
acpi_iort_node *node,
if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
-   *id_out = map[index].output_base;
+   if (id_out)
+   *id_out = map[index].output_base;
return parent;
}
}

Tested-by:  Xinwei Kong 

Re: [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC

[Linus Walleij]

On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
 wrote:
> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-König :
>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>> @@ -337,6 +350,16 @@
>>>   slew-rate = <2>;
>>>   };
>>>   };
>>> +
>>> + i2c1_pins_b: i2c1@0 {
>>> + pins1 {
>>> + pinmux = 
>>> ;
>>> + drive-open-drain;
>>> + };
>>> + pins2 {
>>> + pinmux = 
>>> ;
>>> + };
>>
>> the second doesn't need the open-drain property? Why?
>
> I thought that open-drain was only needed for SDA line.
> But after double-checking I2C specification, it seems that SDA and SCL
> lines need open-drain or open-collector to perform the wired-AND
> function.

I think I2C SDA/SCL must be open drain by definition.

It also requires pull-up resistors, I guess you have these mounted on the board
so you do not need pull-up from the pin controller?

Yours,
Linus Walleij

Re: [PATCH v5 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

iort_node_get_id() has two output, one is the mapped ids,
the other is the referenced parent node which is returned
from the function.

For now we need a API just return its parent node for
single mapping, so just update this function slightly then
reuse it later.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Marc Zyngier 
---
  drivers/acpi/arm64/iort.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index ab7bae7..bc68d93 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -347,7 +347,8 @@ struct acpi_iort_node *iort_node_get_id(struct 
acpi_iort_node *node,
if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
-   *id_out = map[index].output_base;
+   if (id_out)
+   *id_out = map[index].output_base;
return parent;
}
}

Tested-by:  Xinwei Kong 

Re: [PATCH v5 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

The head file is strictly in alphabetic order now, so let's
be the rule breaker. As acpi_iort.h includes acpi.h so remove
the duplidate acpi.h inclusion as well.

Signed-off-by: Hanjun Guo 
Cc: Marc Zyngier 
Cc: Tomasz Nowicki 
---
  drivers/irqchip/irq-gic-v3-its.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 69b040f..f471939 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -15,14 +15,13 @@
   * along with this program.  If not, see .
   */
  
-#include 

+#include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 

Tested-by:  Xinwei Kong 

Re: [PATCH v5 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

The head file is strictly in alphabetic order now, so let's
be the rule breaker. As acpi_iort.h includes acpi.h so remove
the duplidate acpi.h inclusion as well.

Signed-off-by: Hanjun Guo 
Cc: Marc Zyngier 
Cc: Tomasz Nowicki 
---
  drivers/irqchip/irq-gic-v3-its.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 69b040f..f471939 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -15,14 +15,13 @@
   * along with this program.  If not, see .
   */
  
-#include 

+#include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 

Tested-by:  Xinwei Kong 

Re: [PATCH 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Linus Walleij]

On Thu, Dec 22, 2016 at 5:13 AM, Chris Packham
 wrote:

> From: Kalyan Kinthada 
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada 
> Signed-off-by: Chris Packham 

Looks good to me, Sebastian and/or Thomas P can you ACK this patch?

Yours,
Linus Walleij

Re: [PATCH 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Linus Walleij]

On Thu, Dec 22, 2016 at 5:13 AM, Chris Packham
 wrote:

> From: Kalyan Kinthada 
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada 
> Signed-off-by: Chris Packham 

Looks good to me, Sebastian and/or Thomas P can you ACK this patch?

Yours,
Linus Walleij

Re: [PATCH v5 14/14] irqchip: mbigen: Add ACPI support

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

With the preparation of platform msi support and interrupt producer
in DSDT, we can add mbigen ACPI support now.

We are using _PRS methd to indicate number of irq pins instead
of num_pins in DT to avoid _DSD usage in this case.

For mbi-gen,
 Device(MBI0) {
   Name(_HID, "HISI0152")
   Name(_UID, Zero)
   Name(_CRS, ResourceTemplate() {
   Memory32Fixed(ReadWrite, 0xa008, 0x1)
   })

   Name (_PRS, ResourceTemplate() {
  Interrupt(ResourceProducer,...) {12,14,}
   })
 }

For devices,

Device(COM0) {
   Name(_HID, "ACPIIDxx")
   Name(_UID, Zero)
   Name(_CRS, ResourceTemplate() {
  Memory32Fixed(ReadWrite, 0xb003, 0x1)
 Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
   })
 }

With the helpe of platform msi and interrupt producer, then devices
will get the virq from mbi-gen's irqdomain.

Signed-off-by: Hanjun Guo 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Ma Jun 
---
  drivers/irqchip/irq-mbigen.c | 70 ++--
  1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4e11da5..17d35fa 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -16,6 +16,7 @@
   * along with this program.  If not, see .
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
unsigned long *hwirq,
unsigned int *type)
  {
-   if (is_of_node(fwspec->fwnode)) {
+   if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
if (fwspec->param_count != 2)
return -EINVAL;
  
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,

return 0;
  }
  
+#ifdef CONFIG_ACPI

+static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
+void *context)
+{
+   struct acpi_resource_extended_irq *ext_irq;
+   u32 *num_irqs = context;
+
+   switch (ares->type) {
+   case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+   ext_irq = >data.extended_irq;
+   *num_irqs += ext_irq->interrupt_count;
+   break;
+   default:
+   break;
+   }
+
+   return AE_OK;
+}
+
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+struct mbigen_device *mgn_chip)
+{
+   struct irq_domain *domain;
+   u32 num_msis = 0;
+   acpi_status status;
+
+   status = acpi_walk_resources(ACPI_HANDLE(>dev), METHOD_NAME__PRS,
+mbigen_acpi_process_resource, _msis);
+if (ACPI_FAILURE(status) || num_msis == 0)
+   return -EINVAL;
+
+   domain = platform_msi_create_device_domain(>dev, num_msis,
+  mbigen_write_msg,
+  _domain_ops,
+  mgn_chip);
+   if (!domain)
+   return -ENOMEM;
+
+   return 0;
+}
+#else
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+struct mbigen_device *mgn_chip)
+{
+   return -ENODEV;
+}
+#endif
+
  static int mbigen_device_probe(struct platform_device *pdev)
  {
struct mbigen_device *mgn_chip;
@@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
  
-	err = mbigen_of_create_domain(pdev, mgn_chip);

-   if (err)
+   if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+   err = mbigen_of_create_domain(pdev, mgn_chip);
+   else if (ACPI_COMPANION(>dev))
+   err = mbigen_acpi_create_domain(pdev, mgn_chip);
+   else
+   err = -EINVAL;
+
+   if (err) {
+   dev_err(>dev, "Failed to create mbi-gen@%p irqdomain", 
mgn_chip->base);
return err;
+   }
  
  	platform_set_drvdata(pdev, mgn_chip);

return 0;
@@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
  };
  MODULE_DEVICE_TABLE(of, mbigen_of_match);
  
+static const struct acpi_device_id mbigen_acpi_match[] = {

+{ "HISI0152", 0 },
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
+
  static struct platform_driver mbigen_platform_driver = {
.driver = {
.name   = "Hisilicon MBIGEN-V2",

Re: [PATCH v5 14/14] irqchip: mbigen: Add ACPI support

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

With the preparation of platform msi support and interrupt producer
in DSDT, we can add mbigen ACPI support now.

We are using _PRS methd to indicate number of irq pins instead
of num_pins in DT to avoid _DSD usage in this case.

For mbi-gen,
 Device(MBI0) {
   Name(_HID, "HISI0152")
   Name(_UID, Zero)
   Name(_CRS, ResourceTemplate() {
   Memory32Fixed(ReadWrite, 0xa008, 0x1)
   })

   Name (_PRS, ResourceTemplate() {
  Interrupt(ResourceProducer,...) {12,14,}
   })
 }

For devices,

Device(COM0) {
   Name(_HID, "ACPIIDxx")
   Name(_UID, Zero)
   Name(_CRS, ResourceTemplate() {
  Memory32Fixed(ReadWrite, 0xb003, 0x1)
 Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
   })
 }

With the helpe of platform msi and interrupt producer, then devices
will get the virq from mbi-gen's irqdomain.

Signed-off-by: Hanjun Guo 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Ma Jun 
---
  drivers/irqchip/irq-mbigen.c | 70 ++--
  1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4e11da5..17d35fa 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -16,6 +16,7 @@
   * along with this program.  If not, see .
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
unsigned long *hwirq,
unsigned int *type)
  {
-   if (is_of_node(fwspec->fwnode)) {
+   if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
if (fwspec->param_count != 2)
return -EINVAL;
  
@@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,

return 0;
  }
  
+#ifdef CONFIG_ACPI

+static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
+void *context)
+{
+   struct acpi_resource_extended_irq *ext_irq;
+   u32 *num_irqs = context;
+
+   switch (ares->type) {
+   case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+   ext_irq = >data.extended_irq;
+   *num_irqs += ext_irq->interrupt_count;
+   break;
+   default:
+   break;
+   }
+
+   return AE_OK;
+}
+
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+struct mbigen_device *mgn_chip)
+{
+   struct irq_domain *domain;
+   u32 num_msis = 0;
+   acpi_status status;
+
+   status = acpi_walk_resources(ACPI_HANDLE(>dev), METHOD_NAME__PRS,
+mbigen_acpi_process_resource, _msis);
+if (ACPI_FAILURE(status) || num_msis == 0)
+   return -EINVAL;
+
+   domain = platform_msi_create_device_domain(>dev, num_msis,
+  mbigen_write_msg,
+  _domain_ops,
+  mgn_chip);
+   if (!domain)
+   return -ENOMEM;
+
+   return 0;
+}
+#else
+static int mbigen_acpi_create_domain(struct platform_device *pdev,
+struct mbigen_device *mgn_chip)
+{
+   return -ENODEV;
+}
+#endif
+
  static int mbigen_device_probe(struct platform_device *pdev)
  {
struct mbigen_device *mgn_chip;
@@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
  
-	err = mbigen_of_create_domain(pdev, mgn_chip);

-   if (err)
+   if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
+   err = mbigen_of_create_domain(pdev, mgn_chip);
+   else if (ACPI_COMPANION(>dev))
+   err = mbigen_acpi_create_domain(pdev, mgn_chip);
+   else
+   err = -EINVAL;
+
+   if (err) {
+   dev_err(>dev, "Failed to create mbi-gen@%p irqdomain", 
mgn_chip->base);
return err;
+   }
  
  	platform_set_drvdata(pdev, mgn_chip);

return 0;
@@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
  };
  MODULE_DEVICE_TABLE(of, mbigen_of_match);
  
+static const struct acpi_device_id mbigen_acpi_match[] = {

+{ "HISI0152", 0 },
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
+
  static struct platform_driver mbigen_platform_driver = {
.driver = {
.name   = "Hisilicon MBIGEN-V2",
.of_match_table = mbigen_of_match,
+   .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
},

Re: [PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

iort_node_get_id() for now only support NC(named componant)->SMMU
or NC->ITS cases, we also have other device topology such NC->
SMMU->ITS, so rework iort_node_get_id() for those cases.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
---
  drivers/acpi/arm64/iort.c | 59 ++-
  1 file changed, 33 insertions(+), 26 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b72fcb..9b3f268 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
return status;
  }
  
-static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,

-  u32 *rid_out)
+static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
+ u32 *rid_out)
  {
/* Single mapping does not care for input id */
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
-   *rid_out = map->output_base;
+   if (rid_out)
+   *rid_out = map->output_base;
return 0;
}
  
  		pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",

map, type);
-   return -ENXIO;
}
  
+	return -ENXIO;

+}
+
+static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
+  u32 *rid_out)
+{
if (rid_in < map->input_base ||
(rid_in >= map->input_base + map->id_count))
return -ENXIO;
@@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct 
acpi_iort_node *node,
struct acpi_iort_node *parent;
struct acpi_iort_id_mapping *map;
  
-	if (!node->mapping_offset || !node->mapping_count ||

-index >= node->mapping_count)
-   return NULL;
-
-   map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
-  node->mapping_offset);
+   while (node) {
+   if (!node->mapping_offset || !node->mapping_count ||
+index >= node->mapping_count)
+   return NULL;
  
-	/* Firmware bug! */

-   if (!map->output_reference) {
-   pr_err(FW_BUG "[node %p type %d] ID map has NULL parent 
reference\n",
-  node, node->type);
-   return NULL;
-   }
+   map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
+  node->mapping_offset);
  
-	parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,

-  map->output_reference);
+   /* Firmware bug! */
+   if (!map->output_reference) {
+   pr_err(FW_BUG "[node %p type %d] ID map has NULL parent 
reference\n",
+  node, node->type);
+   return NULL;
+   }
  
-	if (!(IORT_TYPE_MASK(parent->type) & type_mask))

-   return NULL;
+   parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
  
-	if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {

-   if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
-   node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
-   if (id_out)
-   *id_out = map[index].output_base;
-   return parent;
+   /* go upstream to find its parent */
+   if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
+   node = parent;
+   continue;
}
+
+   if (iort_id_single_map([index], node->type, id_out))
+   break;
+
+   return parent;
}
  
  	return NULL;

Tested-by:  Xinwei Kong 

Re: [PATCH v5 12/14] irqchip: mbigen: drop module owner

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Kefeng Wang 

Module owner will be set by driver core, so drop it.

Signed-off-by: Kefeng Wang 
Signed-off-by: Hanjun Guo 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Ma Jun 
---
  drivers/irqchip/irq-mbigen.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 03b79b0..c01ab41 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)
  static struct platform_driver mbigen_platform_driver = {
.driver = {
.name   = "Hisilicon MBIGEN-V2",
-   .owner  = THIS_MODULE,
.of_match_table = mbigen_of_match,
},
.probe  = mbigen_device_probe,

Tested-by:  Xinwei Kong 

Re: [PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

iort_node_get_id() for now only support NC(named componant)->SMMU
or NC->ITS cases, we also have other device topology such NC->
SMMU->ITS, so rework iort_node_get_id() for those cases.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
---
  drivers/acpi/arm64/iort.c | 59 ++-
  1 file changed, 33 insertions(+), 26 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b72fcb..9b3f268 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
return status;
  }
  
-static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,

-  u32 *rid_out)
+static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
+ u32 *rid_out)
  {
/* Single mapping does not care for input id */
if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
-   *rid_out = map->output_base;
+   if (rid_out)
+   *rid_out = map->output_base;
return 0;
}
  
  		pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",

map, type);
-   return -ENXIO;
}
  
+	return -ENXIO;

+}
+
+static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
+  u32 *rid_out)
+{
if (rid_in < map->input_base ||
(rid_in >= map->input_base + map->id_count))
return -ENXIO;
@@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct 
acpi_iort_node *node,
struct acpi_iort_node *parent;
struct acpi_iort_id_mapping *map;
  
-	if (!node->mapping_offset || !node->mapping_count ||

-index >= node->mapping_count)
-   return NULL;
-
-   map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
-  node->mapping_offset);
+   while (node) {
+   if (!node->mapping_offset || !node->mapping_count ||
+index >= node->mapping_count)
+   return NULL;
  
-	/* Firmware bug! */

-   if (!map->output_reference) {
-   pr_err(FW_BUG "[node %p type %d] ID map has NULL parent 
reference\n",
-  node, node->type);
-   return NULL;
-   }
+   map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
+  node->mapping_offset);
  
-	parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,

-  map->output_reference);
+   /* Firmware bug! */
+   if (!map->output_reference) {
+   pr_err(FW_BUG "[node %p type %d] ID map has NULL parent 
reference\n",
+  node, node->type);
+   return NULL;
+   }
  
-	if (!(IORT_TYPE_MASK(parent->type) & type_mask))

-   return NULL;
+   parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
  
-	if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {

-   if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
-   node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
-   if (id_out)
-   *id_out = map[index].output_base;
-   return parent;
+   /* go upstream to find its parent */
+   if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
+   node = parent;
+   continue;
}
+
+   if (iort_id_single_map([index], node->type, id_out))
+   break;
+
+   return parent;
}
  
  	return NULL;

Tested-by:  Xinwei Kong 

Re: [PATCH v5 12/14] irqchip: mbigen: drop module owner

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Kefeng Wang 

Module owner will be set by driver core, so drop it.

Signed-off-by: Kefeng Wang 
Signed-off-by: Hanjun Guo 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Cc: Ma Jun 
---
  drivers/irqchip/irq-mbigen.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 03b79b0..c01ab41 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)
  static struct platform_driver mbigen_platform_driver = {
.driver = {
.name   = "Hisilicon MBIGEN-V2",
-   .owner  = THIS_MODULE,
.of_match_table = mbigen_of_match,
},
.probe  = mbigen_device_probe,

Tested-by:  Xinwei Kong 

Re: [PATCH v5 07/14] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

With the introduction of its_pmsi_init_one(), we can add some code
on top for ACPI support of platform MSI.

We are scanning the MADT table to get the ITS entry(ies), then use
the information to create the platform msi domain for devices connect
to it, just like the PCI MSI for ITS did.

Signed-off-by: Hanjun Guo 
Tested-by: Sinan Kaya 
Cc: Marc Zyngier 
Cc: Tomasz Nowicki 
Cc: Thomas Gleixner 
---
  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 36 +++
  1 file changed, 36 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index ff72704..0be0437 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -105,6 +105,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle 
*fwnode,
return 0;
  }
  
+#ifdef CONFIG_ACPI

+static int __init
+its_pmsi_parse_madt(struct acpi_subtable_header *header,
+   const unsigned long end)
+{
+   struct acpi_madt_generic_translator *its_entry;
+   struct fwnode_handle *domain_handle;
+   const char *node_name;
+   int err = -ENXIO;
+
+   its_entry = (struct acpi_madt_generic_translator *)header;
+   node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
+ (long)its_entry->base_address);
+   domain_handle = iort_find_domain_token(its_entry->translation_id);
+   if (!domain_handle) {
+   pr_err("%s: Unable to locate ITS domain handle\n", node_name);
+   goto out;
+   }
+
+   err = its_pmsi_init_one(domain_handle, node_name);
+
+out:
+   kfree(node_name);
+   return err;
+}
+
+static void __init its_acpi_pmsi_init(void)
+{
+   acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+ its_pmsi_parse_madt, 0);
+}
+#else
+static inline void its_acpi_pmsi_init(void) { }
+#endif
+
  static void __init its_pmsi_of_init(void)
  {
struct device_node *np;
@@ -121,6 +156,7 @@ static void __init its_pmsi_of_init(void)
  static int __init its_pmsi_init(void)
  {
its_pmsi_of_init();
+   its_acpi_pmsi_init();
return 0;
  }
  early_initcall(its_pmsi_init);

Tested-by:  Xinwei Kong 

Re: [PATCH v5 07/14] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

With the introduction of its_pmsi_init_one(), we can add some code
on top for ACPI support of platform MSI.

We are scanning the MADT table to get the ITS entry(ies), then use
the information to create the platform msi domain for devices connect
to it, just like the PCI MSI for ITS did.

Signed-off-by: Hanjun Guo 
Tested-by: Sinan Kaya 
Cc: Marc Zyngier 
Cc: Tomasz Nowicki 
Cc: Thomas Gleixner 
---
  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 36 +++
  1 file changed, 36 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index ff72704..0be0437 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -105,6 +105,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle 
*fwnode,
return 0;
  }
  
+#ifdef CONFIG_ACPI

+static int __init
+its_pmsi_parse_madt(struct acpi_subtable_header *header,
+   const unsigned long end)
+{
+   struct acpi_madt_generic_translator *its_entry;
+   struct fwnode_handle *domain_handle;
+   const char *node_name;
+   int err = -ENXIO;
+
+   its_entry = (struct acpi_madt_generic_translator *)header;
+   node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
+ (long)its_entry->base_address);
+   domain_handle = iort_find_domain_token(its_entry->translation_id);
+   if (!domain_handle) {
+   pr_err("%s: Unable to locate ITS domain handle\n", node_name);
+   goto out;
+   }
+
+   err = its_pmsi_init_one(domain_handle, node_name);
+
+out:
+   kfree(node_name);
+   return err;
+}
+
+static void __init its_acpi_pmsi_init(void)
+{
+   acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+ its_pmsi_parse_madt, 0);
+}
+#else
+static inline void its_acpi_pmsi_init(void) { }
+#endif
+
  static void __init its_pmsi_of_init(void)
  {
struct device_node *np;
@@ -121,6 +156,7 @@ static void __init its_pmsi_of_init(void)
  static int __init its_pmsi_init(void)
  {
its_pmsi_of_init();
+   its_acpi_pmsi_init();
return 0;
  }
  early_initcall(its_pmsi_init);

Tested-by:  Xinwei Kong 

Re: [PATCH v5 05/14] ACPI: platform-msi: retrieve dev id from IORT

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

For devices connecting to ITS, it needs dev id to identify
itself, and this dev id is represented in the IORT table in
named componant node [1] for platform devices, so in this
patch we will scan the IORT to retrieve device's dev id.

Introduce iort_pmsi_get_dev_id() with pointer dev passed
in for that purpose.

[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

Signed-off-by: Hanjun Guo 
Tested-by: Sinan Kaya 
Cc: Marc Zyngier 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
Cc: Thomas Gleixner 
---
  drivers/acpi/arm64/iort.c | 26 ++
  drivers/irqchip/irq-gic-v3-its-platform-msi.c |  4 +++-
  include/linux/acpi_iort.h |  8 
  3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 174e983..ab7bae7 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
  }
  
  /**

+ * iort_pmsi_get_dev_id() - Get the device id for a device
+ * @dev: The device for which the mapping is to be done.
+ * @dev_id: The device ID found.
+ *
+ * Returns: 0 for successful find a dev id, errors otherwise
+ */
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+   struct acpi_iort_node *node;
+
+   if (!iort_table)
+   return -ENODEV;
+
+   node = iort_find_dev_node(dev);
+   if (!node) {
+   dev_err(dev, "can't find related IORT node\n");
+   return -ENODEV;
+   }
+
+   if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
+   return -ENODEV;
+
+   return 0;
+}
+
+/**
   * iort_dev_find_its_id() - Find the ITS identifier for a device
   * @dev: The device.
   * @req_id: Device's Requster ID
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 3c94278..16587a9 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -15,6 +15,7 @@
   * along with this program.  If not, see .
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct 
device *dev,
  
  	msi_info = msi_get_domain_info(domain->parent);
  
-	ret = of_pmsi_get_dev_id(domain, dev, _id);

+   ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, _id) :
+   iort_pmsi_get_dev_id(dev, _id);
if (ret)
return ret;
  
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h

index 77e0809..ef99fd52 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -33,6 +33,7 @@
  void acpi_iort_init(void);
  bool iort_node_match(u8 type);
  u32 iort_msi_map_rid(struct device *dev, u32 req_id);
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
  struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
  /* IOMMU interface */
  void iort_set_dma_mask(struct device *dev);
@@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
  static inline bool iort_node_match(u8 type) { return false; }
  static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
  { return req_id; }
+
  static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
  { return NULL; }
+
+static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+   return -ENODEV;
+}
+
  /* IOMMU interface */
  static inline void iort_set_dma_mask(struct device *dev) { }
  static inline

Tested-by:  Xinwei Kong 

Re: [PATCH v5 04/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

Adding ACPI support for platform MSI, we need to retrieve the
dev id in ACPI way instead of device tree, we already have
a well formed function its_pmsi_prepare() to get the dev id
but it's OF dependent, so collect OF related code and put them
into a single function to make its_pmsi_prepare() more friendly
to ACPI later.

Signed-off-by: Hanjun Guo 
Tested-by: Sinan Kaya 
Cc: Marc Zyngier 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
Cc: Thomas Gleixner 
---
  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 470b4aa..3c94278 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -24,15 +24,11 @@
.name   = "ITS-pMSI",
  };
  
-static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,

-   int nvec, msi_alloc_info_t *info)
+static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
+ u32 *dev_id)
  {
-   struct msi_domain_info *msi_info;
-   u32 dev_id;
int ret, index = 0;
  
-	msi_info = msi_get_domain_info(domain->parent);

-
/* Suck the DeviceID out of the msi-parent property */
do {
struct of_phandle_args args;
@@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, 
struct device *dev,
if (args.np == irq_domain_get_of_node(domain)) {
if (WARN_ON(args.args_count != 1))
return -EINVAL;
-   dev_id = args.args[0];
+   *dev_id = args.args[0];
break;
}
} while (!ret);
  
+	return ret;

+}
+
+static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
+   int nvec, msi_alloc_info_t *info)
+{
+   struct msi_domain_info *msi_info;
+   u32 dev_id;
+   int ret;
+
+   msi_info = msi_get_domain_info(domain->parent);
+
+   ret = of_pmsi_get_dev_id(domain, dev, _id);
if (ret)
return ret;
  

Tested-by:  Xinwei Kong 

Re: [PATCH v5 05/14] ACPI: platform-msi: retrieve dev id from IORT

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

For devices connecting to ITS, it needs dev id to identify
itself, and this dev id is represented in the IORT table in
named componant node [1] for platform devices, so in this
patch we will scan the IORT to retrieve device's dev id.

Introduce iort_pmsi_get_dev_id() with pointer dev passed
in for that purpose.

[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

Signed-off-by: Hanjun Guo 
Tested-by: Sinan Kaya 
Cc: Marc Zyngier 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
Cc: Thomas Gleixner 
---
  drivers/acpi/arm64/iort.c | 26 ++
  drivers/irqchip/irq-gic-v3-its-platform-msi.c |  4 +++-
  include/linux/acpi_iort.h |  8 
  3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 174e983..ab7bae7 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
  }
  
  /**

+ * iort_pmsi_get_dev_id() - Get the device id for a device
+ * @dev: The device for which the mapping is to be done.
+ * @dev_id: The device ID found.
+ *
+ * Returns: 0 for successful find a dev id, errors otherwise
+ */
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+   struct acpi_iort_node *node;
+
+   if (!iort_table)
+   return -ENODEV;
+
+   node = iort_find_dev_node(dev);
+   if (!node) {
+   dev_err(dev, "can't find related IORT node\n");
+   return -ENODEV;
+   }
+
+   if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
+   return -ENODEV;
+
+   return 0;
+}
+
+/**
   * iort_dev_find_its_id() - Find the ITS identifier for a device
   * @dev: The device.
   * @req_id: Device's Requster ID
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 3c94278..16587a9 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -15,6 +15,7 @@
   * along with this program.  If not, see .
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct 
device *dev,
  
  	msi_info = msi_get_domain_info(domain->parent);
  
-	ret = of_pmsi_get_dev_id(domain, dev, _id);

+   ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, _id) :
+   iort_pmsi_get_dev_id(dev, _id);
if (ret)
return ret;
  
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h

index 77e0809..ef99fd52 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -33,6 +33,7 @@
  void acpi_iort_init(void);
  bool iort_node_match(u8 type);
  u32 iort_msi_map_rid(struct device *dev, u32 req_id);
+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
  struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
  /* IOMMU interface */
  void iort_set_dma_mask(struct device *dev);
@@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
  static inline bool iort_node_match(u8 type) { return false; }
  static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
  { return req_id; }
+
  static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
  { return NULL; }
+
+static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
+{
+   return -ENODEV;
+}
+
  /* IOMMU interface */
  static inline void iort_set_dma_mask(struct device *dev) { }
  static inline

Tested-by:  Xinwei Kong 

Re: [PATCH v5 04/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

Adding ACPI support for platform MSI, we need to retrieve the
dev id in ACPI way instead of device tree, we already have
a well formed function its_pmsi_prepare() to get the dev id
but it's OF dependent, so collect OF related code and put them
into a single function to make its_pmsi_prepare() more friendly
to ACPI later.

Signed-off-by: Hanjun Guo 
Tested-by: Sinan Kaya 
Cc: Marc Zyngier 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
Cc: Thomas Gleixner 
---
  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 470b4aa..3c94278 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -24,15 +24,11 @@
.name   = "ITS-pMSI",
  };
  
-static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,

-   int nvec, msi_alloc_info_t *info)
+static int of_pmsi_get_dev_id(struct irq_domain *domain, struct device *dev,
+ u32 *dev_id)
  {
-   struct msi_domain_info *msi_info;
-   u32 dev_id;
int ret, index = 0;
  
-	msi_info = msi_get_domain_info(domain->parent);

-
/* Suck the DeviceID out of the msi-parent property */
do {
struct of_phandle_args args;
@@ -43,11 +39,24 @@ static int its_pmsi_prepare(struct irq_domain *domain, 
struct device *dev,
if (args.np == irq_domain_get_of_node(domain)) {
if (WARN_ON(args.args_count != 1))
return -EINVAL;
-   dev_id = args.args[0];
+   *dev_id = args.args[0];
break;
}
} while (!ret);
  
+	return ret;

+}
+
+static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
+   int nvec, msi_alloc_info_t *info)
+{
+   struct msi_domain_info *msi_info;
+   u32 dev_id;
+   int ret;
+
+   msi_info = msi_get_domain_info(domain->parent);
+
+   ret = of_pmsi_get_dev_id(domain, dev, _id);
if (ret)
return ret;
  

Tested-by:  Xinwei Kong 

Re: [PATCH v5 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

We are missing req_id's comment for iort_dev_find_its_id(),
add it back.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
---
  drivers/acpi/arm64/iort.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 46e2d82..174e983 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -446,6 +446,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
  /**
   * iort_dev_find_its_id() - Find the ITS identifier for a device
   * @dev: The device.
+ * @req_id: Device's Requster ID
   * @idx: Index of the ITS identifier list.
   * @its_id: ITS identifier.
   *

Tested-by:  Xinwei Kong 

Re: [PATCH v5 01/14] ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

Cleanup iort_match_node_callback() a little bit to reduce
some lines of code, aslo fix the indentation in iort_scan_node().

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Marc Zyngier 
Cc: Tomasz Nowicki 
---
  drivers/acpi/arm64/iort.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..46e2d82 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -225,7 +225,7 @@ static struct acpi_iort_node *iort_scan_node(enum 
acpi_iort_node_type type,
  
  		if (iort_node->type == type &&

ACPI_SUCCESS(callback(iort_node, context)))
-   return iort_node;
+   return iort_node;
  
  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,

 iort_node->length);
@@ -253,17 +253,15 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
void *context)
  {
struct device *dev = context;
-   acpi_status status;
+   acpi_status status = AE_NOT_FOUND;
  
  	if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {

struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
struct acpi_iort_named_component *ncomp;
  
-		if (!adev) {

-   status = AE_NOT_FOUND;
+   if (!adev)
goto out;
-   }
  
  		status = acpi_get_name(adev->handle, ACPI_FULL_PATHNAME, );

if (ACPI_FAILURE(status)) {
@@ -289,8 +287,6 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
 */
status = pci_rc->pci_segment_number == pci_domain_nr(bus) ?
AE_OK : AE_NOT_FOUND;
-   } else {
-   status = AE_NOT_FOUND;
}
  out:
return status;

Tested-by:  Xinwei Kong 

Re: [PATCH v5 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

We are missing req_id's comment for iort_dev_find_its_id(),
add it back.

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Tomasz Nowicki 
---
  drivers/acpi/arm64/iort.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 46e2d82..174e983 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -446,6 +446,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
  /**
   * iort_dev_find_its_id() - Find the ITS identifier for a device
   * @dev: The device.
+ * @req_id: Device's Requster ID
   * @idx: Index of the ITS identifier list.
   * @its_id: ITS identifier.
   *

Tested-by:  Xinwei Kong 

Re: [PATCH v5 01/14] ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()

[Xinwei Kong]

On 2016/12/22 13:35, Hanjun Guo wrote:

From: Hanjun Guo 

Cleanup iort_match_node_callback() a little bit to reduce
some lines of code, aslo fix the indentation in iort_scan_node().

Signed-off-by: Hanjun Guo 
Cc: Lorenzo Pieralisi 
Cc: Marc Zyngier 
Cc: Tomasz Nowicki 
---
  drivers/acpi/arm64/iort.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..46e2d82 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -225,7 +225,7 @@ static struct acpi_iort_node *iort_scan_node(enum 
acpi_iort_node_type type,
  
  		if (iort_node->type == type &&

ACPI_SUCCESS(callback(iort_node, context)))
-   return iort_node;
+   return iort_node;
  
  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,

 iort_node->length);
@@ -253,17 +253,15 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
void *context)
  {
struct device *dev = context;
-   acpi_status status;
+   acpi_status status = AE_NOT_FOUND;
  
  	if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {

struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
struct acpi_iort_named_component *ncomp;
  
-		if (!adev) {

-   status = AE_NOT_FOUND;
+   if (!adev)
goto out;
-   }
  
  		status = acpi_get_name(adev->handle, ACPI_FULL_PATHNAME, );

if (ACPI_FAILURE(status)) {
@@ -289,8 +287,6 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
 */
status = pci_rc->pci_segment_number == pci_domain_nr(bus) ?
AE_OK : AE_NOT_FOUND;
-   } else {
-   status = AE_NOT_FOUND;
}
  out:
return status;

Tested-by:  Xinwei Kong 

Re: [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)

[Neil Armstrong]

On 12/29/2016 10:18 PM, Heinrich Schuchardt wrote:
> On 12/29/2016 10:07 AM, Neil Armstrong wrote:
>> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>>> translation fault below.
>>>
>>> The following mail thread relates this kind of problem to TLB (translation
>>> lookaside buffer) broadcasting.
>>>
>>> https://lkml.org/lkml/2014/4/15/207
>>>
>>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 
>>> 0x0160, esr 0x8206
>>> [ 3163.017287] pgd = 80007bf86000
>>> [ 3163.020589] [0160] *pgd=7a8a3003
>>> [ 3163.024733] , *pud=7be9c003
>>> [ 3163.028095] , *pmd=
>>>
>>>
>>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 
>>> 4.9.0-next-20161212-r022-arm64 #1
>>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>>> [ 3163.045698] task: 80007bc6d780 task.stack: 80007c524000
>>> [ 3163.051563] PC is at 0x160
>>> [ 3163.054231] LR is at 0x9a9fbc98
>>> [ 3163.057686] pc : [<0160>] lr : [<9a9fbc98>] pstate: 
>>> 4000
>>> [ 3163.065022] sp : d7180130
>>> [ 3163.068281] x29: d7180130 x28: d7180288 
>>> [ 3163.073538] x27: 9aa94000 x26: 0001 
>>> [ 3163.078798] x25:  x24: d7180410 
>>> [ 3163.084060] x23: 0e0c2190 x22: 0e0ca5c0 
>>> [ 3163.089322] x21: 9ac35000 x20: 00454fa9 
>>> [ 3163.094583] x19: 00454fa8 x18: 0e0b5938 
>>> [ 3163.099843] x17: 9a3f2988 x16: 9ac36aa0 
>>> [ 3163.105105] x15:  x14:  
>>> [ 3163.110367] x13: 6d00640064007300 x12: 08000500 
>>> [ 3163.115627] x11: 0400 x10: a000 
>>> [ 3163.120889] x9 : 3fff x8 :  
>>> [ 3163.126150] x7 : 0e0cb520 x6 : 00454fc0 
>>> [ 3163.131412] x5 : d717ffd8 x4 : 0e0cb510 
>>> [ 3163.136680] x3 : 0004 x2 : f2f9022b551b3900 
>>> [ 3163.141935] x1 : 0160 x0 : 0e0ca5c0 
>>>
>>> Best regards
>>>
>>> Heinrich Schuchardt
>>
>> Hi Heinrich,
>>
>> I personally never had this issue even while loading huge applications loke 
>> LibreOffice and Gnome environment.
>>
>> I will have a look and try to reproduce this issue, can you provide us your 
>> configuration and user-space complete use case ?
>>
>> Neil
>>
> 
> Hello Neil,
> 
> the kernel is build with
> https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
> 
> Especially look at the patch directory and config/config-next-20161212.
> 
> The userland is Debian Stretch with this package:
> https://packages.debian.org/stretch/sddm
> 
> The link
> https://www.spinics.net/lists/arm-kernel/msg550204.html
> that you mention in a separate mail just links to this very thread due
> to linux-arm-ker...@lists.infradead.org being in copy.
> 
> Best regards
> 
> Heinrich Schuchardt
> 

Hi,

Thanks for the details, but why do you use the next-20161212 tag ? does it work 
with 4.10-rc1 or previous next tags ?

Neil

Re: [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)

[Neil Armstrong]

On 12/29/2016 10:18 PM, Heinrich Schuchardt wrote:
> On 12/29/2016 10:07 AM, Neil Armstrong wrote:
>> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>>> translation fault below.
>>>
>>> The following mail thread relates this kind of problem to TLB (translation
>>> lookaside buffer) broadcasting.
>>>
>>> https://lkml.org/lkml/2014/4/15/207
>>>
>>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 
>>> 0x0160, esr 0x8206
>>> [ 3163.017287] pgd = 80007bf86000
>>> [ 3163.020589] [0160] *pgd=7a8a3003
>>> [ 3163.024733] , *pud=7be9c003
>>> [ 3163.028095] , *pmd=
>>>
>>>
>>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 
>>> 4.9.0-next-20161212-r022-arm64 #1
>>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>>> [ 3163.045698] task: 80007bc6d780 task.stack: 80007c524000
>>> [ 3163.051563] PC is at 0x160
>>> [ 3163.054231] LR is at 0x9a9fbc98
>>> [ 3163.057686] pc : [<0160>] lr : [<9a9fbc98>] pstate: 
>>> 4000
>>> [ 3163.065022] sp : d7180130
>>> [ 3163.068281] x29: d7180130 x28: d7180288 
>>> [ 3163.073538] x27: 9aa94000 x26: 0001 
>>> [ 3163.078798] x25:  x24: d7180410 
>>> [ 3163.084060] x23: 0e0c2190 x22: 0e0ca5c0 
>>> [ 3163.089322] x21: 9ac35000 x20: 00454fa9 
>>> [ 3163.094583] x19: 00454fa8 x18: 0e0b5938 
>>> [ 3163.099843] x17: 9a3f2988 x16: 9ac36aa0 
>>> [ 3163.105105] x15:  x14:  
>>> [ 3163.110367] x13: 6d00640064007300 x12: 08000500 
>>> [ 3163.115627] x11: 0400 x10: a000 
>>> [ 3163.120889] x9 : 3fff x8 :  
>>> [ 3163.126150] x7 : 0e0cb520 x6 : 00454fc0 
>>> [ 3163.131412] x5 : d717ffd8 x4 : 0e0cb510 
>>> [ 3163.136680] x3 : 0004 x2 : f2f9022b551b3900 
>>> [ 3163.141935] x1 : 0160 x0 : 0e0ca5c0 
>>>
>>> Best regards
>>>
>>> Heinrich Schuchardt
>>
>> Hi Heinrich,
>>
>> I personally never had this issue even while loading huge applications loke 
>> LibreOffice and Gnome environment.
>>
>> I will have a look and try to reproduce this issue, can you provide us your 
>> configuration and user-space complete use case ?
>>
>> Neil
>>
> 
> Hello Neil,
> 
> the kernel is build with
> https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
> 
> Especially look at the patch directory and config/config-next-20161212.
> 
> The userland is Debian Stretch with this package:
> https://packages.debian.org/stretch/sddm
> 
> The link
> https://www.spinics.net/lists/arm-kernel/msg550204.html
> that you mention in a separate mail just links to this very thread due
> to linux-arm-ker...@lists.infradead.org being in copy.
> 
> Best regards
> 
> Heinrich Schuchardt
> 

Hi,

Thanks for the details, but why do you use the next-20161212 tag ? does it work 
with 4.10-rc1 or previous next tags ?

Neil

Re: [PATCH v2] usb: chipdata: Replace the extcon API

[Chanwoo Choi]

Hi Peter,

Please ignore this patch. After posting this patch, I got that this patch was 
already merged by you. I'm sorry to make the confusion.

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:15, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> 
> Cc: Peter Chen 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Rebase these patches based on v4.10-rc1.
> - Drop the phy/power-supply/dwc3/omap patches.
> 
>  drivers/usb/chipidea/core.c | 30 ++
>  1 file changed, 6 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 3dbb4a21ab44..5c35f25e9bce 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_vbus;
>  
>   if (!IS_ERR(ext_vbus)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
> + ret = extcon_get_state(cable->edev, EXTCON_USB);
>   if (ret)
>   cable->state = true;
>   else
> @@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_id;
>  
>   if (!IS_ERR(ext_id)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
> + ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
>   if (ret)
>   cable->state = false;
>   else
> @@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   id = >platdata->id_extcon;
>   id->ci = ci;
>   if (!IS_ERR(id->edev)) {
> - ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
> ->nb);
> + ret = devm_extcon_register_notifier(ci->dev, id->edev,
> + EXTCON_USB_HOST, >nb);
>   if (ret < 0) {
>   dev_err(ci->dev, "register ID failed\n");
>   return ret;
> @@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   vbus = >platdata->vbus_extcon;
>   vbus->ci = ci;
>   if (!IS_ERR(vbus->edev)) {
> - ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
> ->nb);
> + ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
> + EXTCON_USB, >nb);
>   if (ret < 0) {
> - extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
> ->nb);
>   dev_err(ci->dev, "register VBUS failed\n");
>   return ret;
>   }
> @@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   return 0;
>  }
>  
> -static void ci_extcon_unregister(struct ci_hdrc *ci)
> -{
> - struct ci_hdrc_cable *cable;
> -
> - cable = >platdata->id_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
> ->nb);
> -
> - cable = >platdata->vbus_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB, >nb);
> -}
> -
>  static DEFINE_IDA(ci_ida);
>  
>  struct platform_device *ci_hdrc_add_device(struct device *dev,
> @@ -1054,7 +1038,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   if (!ret)
>   return 0;
>  
> - ci_extcon_unregister(ci);
>  stop:
>   ci_role_destroy(ci);
>  deinit_phy:
> @@ -1074,7 +1057,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
>   }
>  
>   dbg_remove_files(ci);
> - ci_extcon_unregister(ci);
>   ci_role_destroy(ci);
>   ci_hdrc_enter_lpm(ci, true);
>   ci_usb_phy_exit(ci);
> 

Re: [PATCH v2] usb: chipdata: Replace the extcon API

[Chanwoo Choi]

Hi Peter,

Please ignore this patch. After posting this patch, I got that this patch was 
already merged by you. I'm sorry to make the confusion.

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:15, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> 
> Cc: Peter Chen 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Rebase these patches based on v4.10-rc1.
> - Drop the phy/power-supply/dwc3/omap patches.
> 
>  drivers/usb/chipidea/core.c | 30 ++
>  1 file changed, 6 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 3dbb4a21ab44..5c35f25e9bce 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_vbus;
>  
>   if (!IS_ERR(ext_vbus)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
> + ret = extcon_get_state(cable->edev, EXTCON_USB);
>   if (ret)
>   cable->state = true;
>   else
> @@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_id;
>  
>   if (!IS_ERR(ext_id)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
> + ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
>   if (ret)
>   cable->state = false;
>   else
> @@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   id = >platdata->id_extcon;
>   id->ci = ci;
>   if (!IS_ERR(id->edev)) {
> - ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
> ->nb);
> + ret = devm_extcon_register_notifier(ci->dev, id->edev,
> + EXTCON_USB_HOST, >nb);
>   if (ret < 0) {
>   dev_err(ci->dev, "register ID failed\n");
>   return ret;
> @@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   vbus = >platdata->vbus_extcon;
>   vbus->ci = ci;
>   if (!IS_ERR(vbus->edev)) {
> - ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
> ->nb);
> + ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
> + EXTCON_USB, >nb);
>   if (ret < 0) {
> - extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
> ->nb);
>   dev_err(ci->dev, "register VBUS failed\n");
>   return ret;
>   }
> @@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   return 0;
>  }
>  
> -static void ci_extcon_unregister(struct ci_hdrc *ci)
> -{
> - struct ci_hdrc_cable *cable;
> -
> - cable = >platdata->id_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
> ->nb);
> -
> - cable = >platdata->vbus_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB, >nb);
> -}
> -
>  static DEFINE_IDA(ci_ida);
>  
>  struct platform_device *ci_hdrc_add_device(struct device *dev,
> @@ -1054,7 +1038,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   if (!ret)
>   return 0;
>  
> - ci_extcon_unregister(ci);
>  stop:
>   ci_role_destroy(ci);
>  deinit_phy:
> @@ -1074,7 +1057,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
>   }
>  
>   dbg_remove_files(ci);
> - ci_extcon_unregister(ci);
>   ci_role_destroy(ci);
>   ci_hdrc_enter_lpm(ci, true);
>   ci_usb_phy_exit(ci);
> 

Re: [PATCH] gpio: update my email address

[Linus Walleij]

On Tue, Dec 20, 2016 at 7:57 PM, John Crispin  wrote:

> This patch updates my email address as I no longer have access to the old
> one.
>
> Signed-off-by: John Crispin 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] gpio: update my email address

[Linus Walleij]

On Tue, Dec 20, 2016 at 7:57 PM, John Crispin  wrote:

> This patch updates my email address as I no longer have access to the old
> one.
>
> Signed-off-by: John Crispin 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: update my email address

[Linus Walleij]

On Tue, Dec 20, 2016 at 7:55 PM, John Crispin  wrote:

> This patch updates my email address as I no longer have access to the old
> one.
>
> Signed-off-by: John Crispin 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: update my email address

[Linus Walleij]

On Tue, Dec 20, 2016 at 7:55 PM, John Crispin  wrote:

> This patch updates my email address as I no longer have access to the old
> one.
>
> Signed-off-by: John Crispin 

Patch applied.

Yours,
Linus Walleij

futex: Ahead futex_init from __initcall to core_initcall

[Yang Yang]

If configs UEVENT_HELPER_PATH [=/sbin/mdev](/sbin/mdev belongs to busybox),
the kernel may trigger oops and kill progress "mdev" when booting.

The reason is when the init progress is calling do_one_initcall(),devices
will be added and trigger /sbin/mdev to execute(in order to make device 
nodes automatically),then /sbin/mdev will call SyS_futex().But when 
SyS_futex() visit the global variable futex_queues,it maynot be 
initalized yet at this time.

Ahead futex_init from __initcall to core_initcall will make sure 
futex_queues is always initalized before the /sbin/mdev executes.

See oops below on arm CPU SABER.
The bug maynot occur due to different race conditions on different CPUs.
But it has a chance to occur by using QUME simulating x86 CPU with 
kernel linux-4.10-rc1.
   
Unable to handle kernel NULL pointer dereference at virtual 
address  pgd = ed10
[] *pgd=8e0b1831, *pte=, *ppte=
Internal error: Oops: 17 [#1] ARM
Modules linked in:
task: ed08b080 ti: ed0ea000 task.ti: ed0ea000
PC is at futex_wake+0x58/0x11c
LR is at futex_wake+0x48/0x11c
pc : []lr : []psr: a213
sp : ed0ebe98  ip : bec1  fp : ed0ebecc
r10:   r9 : 0001  r8 : 
r7 : c088e700  r6 :   r5 : 0001  r4 : 8114
r3 :   r2 : c088e700  r1 : 34a81583  r0 : fff4
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 12c53c7d  Table: 8e100059  DAC: 0015
Process mdev (pid: 225, stack limit = 0xed0ea1b0)
Backtrace:
[] (futex_wake+0x0/0x11c) from []
[] (do_futex+0x0/0x870) from [] 
[] (SyS_futex+0x0/0x16c) from []
Code: e1a07000 e5903000 e153 e243000c (e5934000)

Signed-off-by: Yang Yang 


---
 kernel/futex.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 0842c8c..cdf3650 100755
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3323,4 +3323,4 @@ static int __init futex_init(void)
 
return 0;
 }
-__initcall(futex_init);
+core_initcall(futex_init);
-- 
1.7.1

futex: Ahead futex_init from __initcall to core_initcall

[Yang Yang]

If configs UEVENT_HELPER_PATH [=/sbin/mdev](/sbin/mdev belongs to busybox),
the kernel may trigger oops and kill progress "mdev" when booting.

The reason is when the init progress is calling do_one_initcall(),devices
will be added and trigger /sbin/mdev to execute(in order to make device 
nodes automatically),then /sbin/mdev will call SyS_futex().But when 
SyS_futex() visit the global variable futex_queues,it maynot be 
initalized yet at this time.

Ahead futex_init from __initcall to core_initcall will make sure 
futex_queues is always initalized before the /sbin/mdev executes.

See oops below on arm CPU SABER.
The bug maynot occur due to different race conditions on different CPUs.
But it has a chance to occur by using QUME simulating x86 CPU with 
kernel linux-4.10-rc1.
   
Unable to handle kernel NULL pointer dereference at virtual 
address  pgd = ed10
[] *pgd=8e0b1831, *pte=, *ppte=
Internal error: Oops: 17 [#1] ARM
Modules linked in:
task: ed08b080 ti: ed0ea000 task.ti: ed0ea000
PC is at futex_wake+0x58/0x11c
LR is at futex_wake+0x48/0x11c
pc : []lr : []psr: a213
sp : ed0ebe98  ip : bec1  fp : ed0ebecc
r10:   r9 : 0001  r8 : 
r7 : c088e700  r6 :   r5 : 0001  r4 : 8114
r3 :   r2 : c088e700  r1 : 34a81583  r0 : fff4
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 12c53c7d  Table: 8e100059  DAC: 0015
Process mdev (pid: 225, stack limit = 0xed0ea1b0)
Backtrace:
[] (futex_wake+0x0/0x11c) from []
[] (do_futex+0x0/0x870) from [] 
[] (SyS_futex+0x0/0x16c) from []
Code: e1a07000 e5903000 e153 e243000c (e5934000)

Signed-off-by: Yang Yang 


---
 kernel/futex.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 0842c8c..cdf3650 100755
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3323,4 +3323,4 @@ static int __init futex_init(void)
 
return 0;
 }
-__initcall(futex_init);
+core_initcall(futex_init);
-- 
1.7.1

Re: [PATCH 2/2] pinctrl: sirf: atlas7: Improve code layout

[Linus Walleij]

On Tue, Dec 20, 2016 at 6:41 AM, Christophe JAILLET
 wrote:

> Add some tab in order to improve indentation.
>
> Signed-off-by: Christophe JAILLET 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 2/2] pinctrl: sirf: atlas7: Improve code layout

[Linus Walleij]

On Tue, Dec 20, 2016 at 6:41 AM, Christophe JAILLET
 wrote:

> Add some tab in order to improve indentation.
>
> Signed-off-by: Christophe JAILLET 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 1/2] pinctrl: sirf: atlas7: Add missing 'of_node_put()'

[Linus Walleij]

On Tue, Dec 20, 2016 at 6:40 AM, Christophe JAILLET
 wrote:

> Reference to 'sys2pci_np' should be dropped in all cases here, not only in
> error handling path.
>
> Signed-off-by: Christophe JAILLET 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 1/2] pinctrl: sirf: atlas7: Add missing 'of_node_put()'

[Linus Walleij]

On Tue, Dec 20, 2016 at 6:40 AM, Christophe JAILLET
 wrote:

> Reference to 'sys2pci_np' should be dropped in all cases here, not only in
> error handling path.
>
> Signed-off-by: Christophe JAILLET 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] gpio: Move freeing of GPIO hogs before numbing of the device

[Linus Walleij]

On Mon, Dec 19, 2016 at 6:29 PM, Geert Uytterhoeven
 wrote:

> When removing a gpiochip that uses GPIO hogging (e.g. by unloading the
> chip's DT overlay), a warning is printed:
>
> gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED
>
> This happens because gpiochip_free_hogs() is called after the gdev->chip
> pointer is reset to NULL. Hence __gpiod_free() cannot determine the
> chip in use, and cannot clear flags nor call the optional chip-specific
> .free() callback.
>
> Move the call to gpiochip_free_hogs() up to fix this.
>
> Signed-off-by: Geert Uytterhoeven 

Patch applied to fixes and tagged for stable.

Yours,
Linus Walleij

Re: [PATCH] gpio: Move freeing of GPIO hogs before numbing of the device

[Linus Walleij]

On Mon, Dec 19, 2016 at 6:29 PM, Geert Uytterhoeven
 wrote:

> When removing a gpiochip that uses GPIO hogging (e.g. by unloading the
> chip's DT overlay), a warning is printed:
>
> gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED
>
> This happens because gpiochip_free_hogs() is called after the gdev->chip
> pointer is reset to NULL. Hence __gpiod_free() cannot determine the
> chip in use, and cannot clear flags nor call the optional chip-specific
> .free() callback.
>
> Move the call to gpiochip_free_hogs() up to fix this.
>
> Signed-off-by: Geert Uytterhoeven 

Patch applied to fixes and tagged for stable.

Yours,
Linus Walleij

Re: [PATCH] mmc: use empty initializer list to zero-clear structures

[Linus Walleij]

On Mon, Dec 19, 2016 at 12:51 PM, Masahiro Yamada
 wrote:

> In the MMC subsystem, we see such initializers that only clears the
> first member explicitly.
>
> For example,
>
>   struct mmc_request mrq = {NULL};
>
> sets the first member (.sbc) to NULL explicitly.  However, this is
> an unstable form because we may insert a non-pointer member at the
> top of the struct mmc_request in the future. (if we do so, the
> compiler will spit warnings.)
>
> So, using a designated initializer is preferred coding style.  The
> expression above is equivalent to:
>
>   struct mmc_request mrq = { .sbc = NULL };
>
> Of course, this does not express our intention.  We want to fill
> all struct members with zeros.  Please note struct members are
> implicitly zero-cleared unless otherwise specified in the initializer.
>
> After all, the most reasonable (and stable) form is:
>
>   struct mmc_request mrq = {};
>
> Do likewise for mmc_command, mmc_data as well.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

Re: [PATCH] mmc: use empty initializer list to zero-clear structures

[Linus Walleij]

On Mon, Dec 19, 2016 at 12:51 PM, Masahiro Yamada
 wrote:

> In the MMC subsystem, we see such initializers that only clears the
> first member explicitly.
>
> For example,
>
>   struct mmc_request mrq = {NULL};
>
> sets the first member (.sbc) to NULL explicitly.  However, this is
> an unstable form because we may insert a non-pointer member at the
> top of the struct mmc_request in the future. (if we do so, the
> compiler will spit warnings.)
>
> So, using a designated initializer is preferred coding style.  The
> expression above is equivalent to:
>
>   struct mmc_request mrq = { .sbc = NULL };
>
> Of course, this does not express our intention.  We want to fill
> all struct members with zeros.  Please note struct members are
> implicitly zero-cleared unless otherwise specified in the initializer.
>
> After all, the most reasonable (and stable) form is:
>
>   struct mmc_request mrq = {};
>
> Do likewise for mmc_command, mmc_data as well.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

[PATCH] ARM: dts: am572x-idk: Add gpios property to control PCIE_RESETn

[Kishon Vijay Abraham I]

Add 'gpios' property to pcie1 dt node and populate it with
GPIO3_23 in order to drive PCIE_RESETn high.

This gets PCIe cards to be detected in AM572X IDK board.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am572x-idk.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index 27d9149..1540f7a 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -87,3 +87,7 @@
  {
load-gpios = < 19 GPIO_ACTIVE_LOW>;
 };
+
+ {
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+};
-- 
1.7.9.5

[PATCH] ARM: dts: am572x-idk: Add gpios property to control PCIE_RESETn

[Kishon Vijay Abraham I]

Add 'gpios' property to pcie1 dt node and populate it with
GPIO3_23 in order to drive PCIE_RESETn high.

This gets PCIe cards to be detected in AM572X IDK board.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am572x-idk.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index 27d9149..1540f7a 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -87,3 +87,7 @@
  {
load-gpios = < 19 GPIO_ACTIVE_LOW>;
 };
+
+ {
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+};
-- 
1.7.9.5

Re: [PATCH] pinctrl: stm32: activate strict mux mode

[Linus Walleij]

On Wed, Dec 14, 2016 at 3:24 PM,   wrote:

> From: Gabriel Fernandez 
>
> This activates strict mode muxing for the STM32 pin controllers,
> as these do not allow GPIO and functions to use the same pin
> simultaneously.
>
> Signed-off-by: Gabriel Fernandez 

Patch applied with Patrice's ACK.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: stm32: activate strict mux mode

[Linus Walleij]

On Wed, Dec 14, 2016 at 3:24 PM,   wrote:

> From: Gabriel Fernandez 
>
> This activates strict mode muxing for the STM32 pin controllers,
> as these do not allow GPIO and functions to use the same pin
> simultaneously.
>
> Signed-off-by: Gabriel Fernandez 

Patch applied with Patrice's ACK.

Yours,
Linus Walleij

[PATCH] Documentation: panel-dpi: fix path to display-timing.txt

[yegorslists]

From: Yegor Yefremov 

Signed-off-by: Yegor Yefremov 
---
 Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index b52ac52..d4add13 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -12,7 +12,7 @@ Optional properties:
 
 Required nodes:
 - "panel-timing" containing video timings
-  (Documentation/devicetree/bindings/display/display-timing.txt)
+  (Documentation/devicetree/bindings/display/panel/display-timing.txt)
 - Video port for DPI input
 
 Example
-- 
2.1.4

[PATCH] Documentation: panel-dpi: fix path to display-timing.txt

[yegorslists]

From: Yegor Yefremov 

Signed-off-by: Yegor Yefremov 
---
 Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index b52ac52..d4add13 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -12,7 +12,7 @@ Optional properties:
 
 Required nodes:
 - "panel-timing" containing video timings
-  (Documentation/devicetree/bindings/display/display-timing.txt)
+  (Documentation/devicetree/bindings/display/panel/display-timing.txt)
 - Video port for DPI input
 
 Example
-- 
2.1.4

Re: [PATCH] gpio: mxs: remove __init annotation

[Linus Walleij]

On Fri, Dec 16, 2016 at 10:08 AM, Arnd Bergmann  wrote:

> Building with an old toolchain, I ran into this warning:
>
> WARNING: vmlinux.o(.text+0x63eef0): Section mismatch in reference from the 
> function mxs_gpio_probe() to the function .init.text:mxs_gpio_init_gc()
>
> Clearly the annotation is wrong, since the function is called from the
> non-init probe, so let's remove it.
>
> Signed-off-by: Arnd Bergmann 

Patch applied for fixes.

Yours,
Linus Walleij

Re: [PATCH] gpio: mxs: remove __init annotation

[Linus Walleij]

On Fri, Dec 16, 2016 at 10:08 AM, Arnd Bergmann  wrote:

> Building with an old toolchain, I ran into this warning:
>
> WARNING: vmlinux.o(.text+0x63eef0): Section mismatch in reference from the 
> function mxs_gpio_probe() to the function .init.text:mxs_gpio_init_gc()
>
> Clearly the annotation is wrong, since the function is called from the
> non-init probe, so let's remove it.
>
> Signed-off-by: Arnd Bergmann 

Patch applied for fixes.

Yours,
Linus Walleij

[PATCH v3] net: ethernet: faraday: To support device tree usage.

[Greentime Hu]

Signed-off-by: Greentime Hu 
---
Changes in v3:
  - Nothing changed in this patch but I have committed andestech to 
vendor-prefixes.txt.

 drivers/net/ethernet/faraday/ftmac100.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftmac100.c 
b/drivers/net/ethernet/faraday/ftmac100.c
index dce5f7b..5d70ee9 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct 
platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id ftmac100_of_ids[] = {
+   { .compatible = "andestech,atmac100" },
+   { }
+};
+
 static struct platform_driver ftmac100_driver = {
.probe  = ftmac100_probe,
.remove = __exit_p(ftmac100_remove),
.driver = {
.name   = DRV_NAME,
+   .of_match_table = ftmac100_of_ids
},
 };
 
@@ -1200,3 +1206,4 @@ static void __exit ftmac100_exit(void)
 MODULE_AUTHOR("Po-Yu Chuang ");
 MODULE_DESCRIPTION("FTMAC100 driver");
 MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, ftmac100_of_ids);
-- 
1.7.9.5

[PATCH v3] net: ethernet: faraday: To support device tree usage.

[Greentime Hu]

Signed-off-by: Greentime Hu 
---
Changes in v3:
  - Nothing changed in this patch but I have committed andestech to 
vendor-prefixes.txt.

 drivers/net/ethernet/faraday/ftmac100.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftmac100.c 
b/drivers/net/ethernet/faraday/ftmac100.c
index dce5f7b..5d70ee9 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct 
platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id ftmac100_of_ids[] = {
+   { .compatible = "andestech,atmac100" },
+   { }
+};
+
 static struct platform_driver ftmac100_driver = {
.probe  = ftmac100_probe,
.remove = __exit_p(ftmac100_remove),
.driver = {
.name   = DRV_NAME,
+   .of_match_table = ftmac100_of_ids
},
 };
 
@@ -1200,3 +1206,4 @@ static void __exit ftmac100_exit(void)
 MODULE_AUTHOR("Po-Yu Chuang ");
 MODULE_DESCRIPTION("FTMAC100 driver");
 MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, ftmac100_of_ids);
-- 
1.7.9.5

Re: [PATCH 5/6] ARM: dts: TS-4600: add NBUS support

[Linus Walleij]

On Thu, Dec 15, 2016 at 12:12 AM, Sebastien Bourdelin
 wrote:

> This commit enables the NBUS on the TS-4600, using the ts-nbus driver.
>
> Signed-off-by: Sebastien Bourdelin 

> +   nbus {
> +   compatible = "technologic,ts-nbus", "simple-bus";
> +   pinctrl-0 = <_pins>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pwms = < 2 83>;
> +   data-gpios   = < 0 GPIO_ACTIVE_HIGH
> +1 GPIO_ACTIVE_HIGH
> +2 GPIO_ACTIVE_HIGH
> +3 GPIO_ACTIVE_HIGH
> +4 GPIO_ACTIVE_HIGH
> +5 GPIO_ACTIVE_HIGH
> +6 GPIO_ACTIVE_HIGH
> +7 GPIO_ACTIVE_HIGH>;
> +   csn-gpios= < 16 GPIO_ACTIVE_HIGH>;
> +   txrx-gpios   = < 24 GPIO_ACTIVE_HIGH>;
> +   strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
> +   ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
> +   rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;

devm_gpiod_get(>dev, "csn", GPIOD_OUT_HIGH); etc will get these
from the spawned
platform device.

Yours,
Linus Walleij

Re: [PATCH 5/6] ARM: dts: TS-4600: add NBUS support

[Linus Walleij]

On Thu, Dec 15, 2016 at 12:12 AM, Sebastien Bourdelin
 wrote:

> This commit enables the NBUS on the TS-4600, using the ts-nbus driver.
>
> Signed-off-by: Sebastien Bourdelin 

> +   nbus {
> +   compatible = "technologic,ts-nbus", "simple-bus";
> +   pinctrl-0 = <_pins>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pwms = < 2 83>;
> +   data-gpios   = < 0 GPIO_ACTIVE_HIGH
> +1 GPIO_ACTIVE_HIGH
> +2 GPIO_ACTIVE_HIGH
> +3 GPIO_ACTIVE_HIGH
> +4 GPIO_ACTIVE_HIGH
> +5 GPIO_ACTIVE_HIGH
> +6 GPIO_ACTIVE_HIGH
> +7 GPIO_ACTIVE_HIGH>;
> +   csn-gpios= < 16 GPIO_ACTIVE_HIGH>;
> +   txrx-gpios   = < 24 GPIO_ACTIVE_HIGH>;
> +   strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
> +   ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
> +   rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;

devm_gpiod_get(>dev, "csn", GPIOD_OUT_HIGH); etc will get these
from the spawned
platform device.

Yours,
Linus Walleij

[PATCH] Documentation: simple-card: add full path to widgets.txt

[yegorslists]

From: Yegor Yefremov 

Signed-off-by: Yegor Yefremov 
---
 Documentation/devicetree/bindings/sound/simple-card.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt 
b/Documentation/devicetree/bindings/sound/simple-card.txt
index c7a9393..4198fe5 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -10,7 +10,8 @@ Optional properties:
 
 - simple-audio-card,name   : User specified audio sound card name, 
one string
  property.
-- simple-audio-card,widgets: Please refer to widgets.txt.
+- simple-audio-card,widgets: Please refer to
+ 
Documentation/devicetree/bindings/sound/widgets.txt.
 - simple-audio-card,routing: A list of the connections between 
audio components.
  Each entry is a pair of strings, the 
first being the
  connection's sink, the second being 
the connection's
-- 
2.1.4

[PATCH] Documentation: simple-card: add full path to widgets.txt

[yegorslists]

From: Yegor Yefremov 

Signed-off-by: Yegor Yefremov 
---
 Documentation/devicetree/bindings/sound/simple-card.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt 
b/Documentation/devicetree/bindings/sound/simple-card.txt
index c7a9393..4198fe5 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -10,7 +10,8 @@ Optional properties:
 
 - simple-audio-card,name   : User specified audio sound card name, 
one string
  property.
-- simple-audio-card,widgets: Please refer to widgets.txt.
+- simple-audio-card,widgets: Please refer to
+ 
Documentation/devicetree/bindings/sound/widgets.txt.
 - simple-audio-card,routing: A list of the connections between 
audio components.
  Each entry is a pair of strings, the 
first being the
  connection's sink, the second being 
the connection's
-- 
2.1.4