Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

[Mike Rapoport]

Hi John,

Thanks for having documentation as a part of the patch. Some kernel-doc
nits below.

On Mon, Dec 03, 2018 at 04:17:19PM -0800, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> Introduces put_user_page(), which simply calls put_page().
> This provides a way to update all get_user_pages*() callers,
> so that they call put_user_page(), instead of put_page().
> 
> Also introduces put_user_pages(), and a few dirty/locked variations,
> as a replacement for release_pages(), and also as a replacement
> for open-coded loops that release multiple pages.
> These may be used for subsequent performance improvements,
> via batching of pages to be released.
> 
> This is the first step of fixing the problem described in [1]. The steps
> are:
> 
> 1) (This patch): provide put_user_page*() routines, intended to be used
>for releasing pages that were pinned via get_user_pages*().
> 
> 2) Convert all of the call sites for get_user_pages*(), to
>invoke put_user_page*(), instead of put_page(). This involves dozens of
>call sites, and will take some time.
> 
> 3) After (2) is complete, use get_user_pages*() and put_user_page*() to
>implement tracking of these pages. This tracking will be separate from
>the existing struct page refcounting.
> 
> 4) Use the tracking and identification of these pages, to implement
>special handling (especially in writeback paths) when the pages are
>backed by a filesystem. Again, [1] provides details as to why that is
>desirable.
> 
> [1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"
> 
> Reviewed-by: Jan Kara 
> 
> Cc: Matthew Wilcox 
> Cc: Michal Hocko 
> Cc: Christopher Lameter 
> Cc: Jason Gunthorpe 
> Cc: Dan Williams 
> Cc: Jan Kara 
> Cc: Al Viro 
> Cc: Jerome Glisse 
> Cc: Christoph Hellwig 
> Cc: Ralph Campbell 
> Signed-off-by: John Hubbard 
> ---
>  include/linux/mm.h | 20 
>  mm/swap.c  | 80 ++
>  2 files changed, 100 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5411de93a363..09fbb2c81aba 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -963,6 +963,26 @@ static inline void put_page(struct page *page)
>   __put_page(page);
>  }
> 
> +/*
> + * put_user_page() - release a page that had previously been acquired via
> + * a call to one of the get_user_pages*() functions.

Please add @page parameter description, otherwise kernel-doc is unhappy

> + *
> + * Pages that were pinned via get_user_pages*() must be released via
> + * either put_user_page(), or one of the put_user_pages*() routines
> + * below. This is so that eventually, pages that are pinned via
> + * get_user_pages*() can be separately tracked and uniquely handled. In
> + * particular, interactions with RDMA and filesystems need special
> + * handling.
> + */
> +static inline void put_user_page(struct page *page)
> +{
> + put_page(page);
> +}
> +
> +void put_user_pages_dirty(struct page **pages, unsigned long npages);
> +void put_user_pages_dirty_lock(struct page **pages, unsigned long npages);
> +void put_user_pages(struct page **pages, unsigned long npages);
> +
>  #if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
>  #define SECTION_IN_PAGE_FLAGS
>  #endif
> diff --git a/mm/swap.c b/mm/swap.c
> index aa483719922e..bb8c32595e5f 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -133,6 +133,86 @@ void put_pages_list(struct list_head *pages)
>  }
>  EXPORT_SYMBOL(put_pages_list);
> 
> +typedef int (*set_dirty_func)(struct page *page);
> +
> +static void __put_user_pages_dirty(struct page **pages,
> +unsigned long npages,
> +set_dirty_func sdf)
> +{
> + unsigned long index;
> +
> + for (index = 0; index < npages; index++) {
> + struct page *page = compound_head(pages[index]);
> +
> + if (!PageDirty(page))
> + sdf(page);
> +
> + put_user_page(page);
> + }
> +}
> +
> +/*
> + * put_user_pages_dirty() - for each page in the @pages array, make
> + * that page (or its head page, if a compound page) dirty, if it was
> + * previously listed as clean. Then, release the page using
> + * put_user_page().
> + *
> + * Please see the put_user_page() documentation for details.
> + *
> + * set_page_dirty(), which does not lock the page, is used here.
> + * Therefore, it is the caller's responsibility to ensure that this is
> + * safe. If not, then put_user_pages_dirty_lock() should be called instead.
> + *
> + * @pages:  array of pages to be marked dirty and released.
> + * @npages: number of pages in the @pages array.

Please put the parameters description next to the brief function
description, as described in [1]

[1] 
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation


> + *
> + */
> +void put_user_pages_dirty(struct page **pages, unsigned long npages)
> +{
> 

RE: rcu_preempt caused oom

[He, Bo]

Hi, Paul:
the enclosed is the log trigger the 120s hung_task_panic without other debug 
patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall 
can't detect the scenario:
echo 1 > /proc/sys/kernel/panic_on_rcu_stall
echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout


-Original Message-
From: Paul E. McKenney  
Sent: Monday, December 3, 2018 9:57 PM
To: He, Bo 
Cc: Steven Rostedt ; linux-kernel@vger.kernel.org; 
j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; 
Zhang, Jun ; Xiao, Jin ; Zhang, Yanmin 

Subject: Re: rcu_preempt caused oom

On Mon, Dec 03, 2018 at 07:44:03AM +, He, Bo wrote:
> Thanks, we have run the test for the whole weekend and not reproduce the 
> issue,  so we confirm the CONFIG_RCU_BOOST can fix the issue.

Very good, that is encouraging.  Perhaps I should think about making 
CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for 
architectures for which rt_mutexes are implemented.

> We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on 
> rcu stall and will see if we can see the panic, will keep you posed with the 
> test results.
> echo 1 > /proc/sys/kernel/panic_on_rcu_stall

Looking forward to seeing what is going on!  Of course, to reproduce, you will 
need to again build with CONFIG_RCU_BOOST=n.

Thanx, Paul

> -Original Message-
> From: Paul E. McKenney 
> Sent: Saturday, December 1, 2018 12:49 AM
> To: He, Bo 
> Cc: Steven Rostedt ; 
> linux-kernel@vger.kernel.org; j...@joshtriplett.org; 
> mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; Zhang, Jun 
> ; Xiao, Jin ; Zhang, Yanmin 
> 
> Subject: Re: rcu_preempt caused oom
> 
> On Fri, Nov 30, 2018 at 03:18:58PM +, He, Bo wrote:
> > Here is the kernel cmdline:
> 
> Thank you!
> 
> > Kernel command line: androidboot.acpio_idx=0
> > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_0
> > 3- userdebug androidboot.diskbus=00.0 
> > androidboot.verifiedbootstate=green
> > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb
> > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves 
> > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti 
> > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt
> > loglevel=4 androidboot.hardware=gordon_peak 
> > firmware_class.path=/vendor/firmware relative_sleep_states=1
> > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 
> > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/pro
> > pe rties/android/ pstore.backend=ramoops memmap=0x140$0x5000
> > ramoops.mem_address=0x5000 ramoops.mem_size=0x140
> > ramoops.record_size=0x4000 ramoops.console_size=0x100
> > ramoops.ftrace_size=0x1 ramoops.dump_oops=1 vga=current
> > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 
> > drm.vblankoffdelay=
> 
> And no sign of any suppression of RCU CPU stall warnings.  Hmmm...
> It does take more than 21 seconds to OOM?  Or do things happen faster than 
> that?  If they do happen faster than that, then on approach would be to add 
> something like this to the kernel command line:
> 
>   rcupdate.rcu_cpu_stall_timeout=7
> 
> This would set the stall timeout to seven seconds.  Note that timeouts less 
> than three seconds are silently interpreted as three seconds.
> 
>   Thanx, Paul
> 
> > -Original Message-
> > From: Steven Rostedt 
> > Sent: Friday, November 30, 2018 11:17 PM
> > To: Paul E. McKenney 
> > Cc: He, Bo ; linux-kernel@vger.kernel.org; 
> > j...@joshtriplett.org; mathieu.desnoy...@efficios.com; 
> > jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin 
> > ; Zhang, Yanmin 
> > Subject: Re: rcu_preempt caused oom
> > 
> > On Fri, 30 Nov 2018 06:43:17 -0800
> > "Paul E. McKenney"  wrote:
> > 
> > > Could you please send me your list of kernel boot parameters?  
> > > They usually appear near the start of your console output.
> > 
> > Or just: cat /proc/cmdline
> > 
> > -- Steve
> > 
> 



apanic_console
Description: apanic_console

Re: [PATCH 3/9] tools/lib/traceevent: Install trace-seq.h API header file

[Namhyung Kim]

On Fri, Nov 30, 2018 at 10:44:06AM -0500, Steven Rostedt wrote:
> From: Tzvetomir Stoyanov 
> 
> This patch installs trace-seq.h header file on "make install".
> 
> Signed-off-by: Tzvetomir Stoyanov 
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  tools/lib/traceevent/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
> index adb16f845ab3..67fe5d7ef190 100644
> --- a/tools/lib/traceevent/Makefile
> +++ b/tools/lib/traceevent/Makefile
> @@ -285,7 +285,7 @@ define do_install_pkgconfig_file
>   fi
>  endef
>  
> -install_lib: all_cmd install_plugins install_pkgconfig
> +install_lib: all_cmd install_plugins install_headers install_pkgconfig
>   $(call QUIET_INSTALL, $(LIB_TARGET)) \
>   $(call do_install_mkdir,$(libdir_SQ)); \
>   cp -fpR $(LIB_INSTALL) $(DESTDIR)$(libdir_SQ)
> @@ -302,6 +302,7 @@ install_headers:
>   $(call QUIET_INSTALL, headers) \
>   $(call 
> do_install,event-parse.h,$(prefix)/include/traceevent,644); \
>   $(call 
> do_install,event-utils.h,$(prefix)/include/traceevent,644); \
> + $(call 
> do_install,trace-seq.h,$(prefix)/include/traceevent,644); \
>   $(call do_install,kbuffer.h,$(prefix)/include/traceevent,644)

Do you still wanna have 'traceevent' directory prefix?  I just
sometimes feel a bit annoying to type it. ;-)

Or you can rename it something like 'tep' or 'libtep' - and hopefully
having only single header file to include..

Thanks,
Namhyung


>  
>  install: install_lib
> -- 
> 2.19.1
> 
> 

Re: [RFC PATCH 00/14] Heterogeneous Memory System (HMS) and hbind()

[Aneesh Kumar K.V]

On 12/4/18 5:04 AM, jgli...@redhat.com wrote:

From: Jérôme Glisse 

Heterogeneous memory system are becoming more and more the norm, in
those system there is not only the main system memory for each node,
but also device memory and|or memory hierarchy to consider. Device
memory can comes from a device like GPU, FPGA, ... or from a memory
only device (persistent memory, or high density memory device).

Memory hierarchy is when you not only have the main memory but also
other type of memory like HBM (High Bandwidth Memory often stack up
on CPU die or GPU die), peristent memory or high density memory (ie
something slower then regular DDR DIMM but much bigger).

On top of this diversity of memories you also have to account for the
system bus topology ie how all CPUs and devices are connected to each
others. Userspace do not care about the exact physical topology but
care about topology from behavior point of view ie what are all the
paths between an initiator (anything that can initiate memory access
like CPU, GPU, FGPA, network controller ...) and a target memory and
what are all the properties of each of those path (bandwidth, latency,
granularity, ...).

This means that it is no longer sufficient to consider a flat view
for each node in a system but for maximum performance we need to
account for all of this new memory but also for system topology.
This is why this proposal is unlike the HMAT proposal [1] which
tries to extend the existing NUMA for new type of memory. Here we
are tackling a much more profound change that depart from NUMA.


One of the reasons for radical change is the advance of accelerator
like GPU or FPGA means that CPU is no longer the only piece where
computation happens. It is becoming more and more common for an
application to use a mix and match of different accelerator to
perform its computation. So we can no longer satisfy our self with
a CPU centric and flat view of a system like NUMA and NUMA distance.


This patchset is a proposal to tackle this problems through three
aspects:
 1 - Expose complex system topology and various kind of memory
 to user space so that application have a standard way and
 single place to get all the information it cares about.
 2 - A new API for user space to bind/provide hint to kernel on
 which memory to use for range of virtual address (a new
 mbind() syscall).
 3 - Kernel side changes for vm policy to handle this changes

This patchset is not and end to end solution but it provides enough
pieces to be useful against nouveau (upstream open source driver for
NVidia GPU). It is intended as a starting point for discussion so
that we can figure out what to do. To avoid having too much topics
to discuss i am not considering memory cgroup for now but it is
definitely something we will want to integrate with.

The rest of this emails is splits in 3 sections, the first section
talks about complex system topology: what it is, how it is use today
and how to describe it tomorrow. The second sections talks about
new API to bind/provide hint to kernel for range of virtual address.
The third section talks about new mechanism to track bind/hint
provided by user space or device driver inside the kernel.


1) Complex system topology and representing them


Inside a node you can have a complex topology of memory, for instance
you can have multiple HBM memory in a node, each HBM memory tie to a
set of CPUs (all of which are in the same node). This means that you
have a hierarchy of memory for CPUs. The local fast HBM but which is
expected to be relatively small compare to main memory and then the
main memory. New memory technology might also deepen this hierarchy
with another level of yet slower memory but gigantic in size (some
persistent memory technology might fall into that category). Another
example is device memory, and device themself can have a hierarchy
like HBM on top of device core and main device memory.

On top of that you can have multiple path to access each memory and
each path can have different properties (latency, bandwidth, ...).
Also there is not always symmetry ie some memory might only be
accessible by some device or CPU ie not accessible by everyone.

So a flat hierarchy for each node is not capable of representing this
kind of complexity. To simplify discussion and because we do not want
to single out CPU from device, from here on out we will use initiator
to refer to either CPU or device. An initiator is any kind of CPU or
device that can access memory (ie initiate memory access).

At this point a example of such system might help:
 - 2 nodes and for each node:
 - 1 CPU per node with 2 complex of CPUs cores per CPU
 - one HBM memory for each complex of CPUs cores (200GB/s)
 - CPUs cores complex are linked to each other (100GB/s)
 - main memory is (90GB/s)
 - 4 GPUs each with:
 - HBM memory for eac

Re: linux-next: manual merge of the char-misc tree with the char-misc.current tree

[Greg KH]

On Tue, Dec 04, 2018 at 03:35:13PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got a conflict in:
> 
>   drivers/hv/channel_mgmt.c
> 
> between commit:
> 
>   37c2578c0c40 ("Drivers: hv: vmbus: Offload the handling of channels to two 
> workqueues")
> 
> from the char-misc.current tree and commit:
> 
>   4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API 
> vmbus_get_outgoing_channel()")
> 
> from the char-misc tree.
> 
> I fixed it up (I used the former version where they conflicted) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Yeah, this is a mess, I'll wait for the hyper-v developers to send me a
fixup patch for handling this merge issue, as they know it is happening
:(

thanks,

greg k-h

Re: [PATCH] ubi: fastmap: Check each mapping only once

[Greg Kroah-Hartman]

On Tue, Dec 04, 2018 at 08:39:16AM +0100, Martin Kepplinger wrote:
> On 02.12.18 16:02, Richard Weinberger wrote:
> > Sasha,
> > 
> > Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin:
> > > On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote:
> > > > > > Now queued up for 4.14.y, thanks.
> > > > > 
> > > > > can you *please* slow a little down?
> > > > 
> > > > True. It will really help if you can have some sort of fixed schedule
> > > > for stable release, like maybe stablerc is ready on Thursday or Friday
> > > > and release the stable on Monday. Having a weekend in stablerc will be
> > > > helpful for people like me who only get the time in weekends for
> > > > upstream or stable kernel.
> > > 
> > > Any sort of schedule will never work for everyone (for example, if it's
> > > part of your paid job - you don't necessarily want to review stuff over
> > > the weekend).
> > 
> > a schedule is not needed, but please give maintainers at least a chance
> > to react on stable inclusion request.
> > In this case Martin asked for inclusion on Monday and the patch was applied
> > two days later.
> 
> True, especially when the maintainer is asked a question as part of the
> patch.
> 
> I've already had the feeling that we'd need the other patch too, but in this
> case at least I should have searched for Fixes tags.
> 
> Greg, how about reminding people of Fixes tags in
> Documentation/process/stable-kernel-rules.rst ?

Reminding people how?  Patches to that file are always gladly accepted :)

thanks,

greg k-h

Re: Strange hang with gcc 8 of kprobe multiple_kprobes test

[Masami Hiramatsu]

Hi Steve,

On Mon, 3 Dec 2018 21:18:07 -0500
Steven Rostedt  wrote:

> Hi Masami,
> 
> I started testing some of my new code and the system got into a
> strange state. Debugging further, I found the cause came from the
> kprobe tests. It became stranger to me that I could reproduce it with
> older kernels. I went back as far as 4.16 and it triggered. I thought
> this very strange because I ran this test on all those kernels in the
> past.
> 
> After a bit of hair pulling, I figured out what changed. I upgraded to
> gcc 8.1 (and I reproduce it with 8.2 as well). I convert back to gcc 7
> and the tests pass without issue.

OK, let me see.

> The issue that I notice when the system gets into this strange state is
> that I can't log into the box. Nor can I reboot. Basically it's
> anything to do with systemd just doesn't work (insert your jokes here
> now, and then let's move on).
> 
> I was able to narrow down what the exact function was that caused the
> issues and it is: update_vsyscall()
> 
> gcc 7 looks like this:
> 
> 81004bf0 :
> 81004bf0:   e8 0b cc 9f 00  callq  81a01800 
> <__fentry__>
> 81004bf1: R_X86_64_PC32 __fentry__-0x4
> 81004bf5:   48 8b 07mov(%rdi),%rax
> 81004bf8:   8b 15 96 5f 34 01   mov0x1345f96(%rip),%edx   
>  # 8234ab94 
> 81004bfa: R_X86_64_PC32 vclocks_used-0x4
> 81004bfe:   83 05 7b 84 6f 01 01addl   $0x1,0x16f847b(%rip)   
>  # 826fd080 
> 81004c00: R_X86_64_PC32 vsyscall_gtod_data-0x5
> 81004c05:   8b 48 24mov0x24(%rax),%ecx
> 81004c08:   b8 01 00 00 00  mov$0x1,%eax
> 81004c0d:   d3 e0   shl%cl,%eax
> 
> And gcc 8 looks like this:
> 
> 81004c90 :
> 81004c90:   e8 6b cb 9f 00  callq  81a01800 
> <__fentry__>
> 81004c91: R_X86_64_PC32 __fentry__-0x4
> 81004c95:   48 8b 07mov(%rdi),%rax
> 81004c98:   83 05 e1 93 6f 01 01addl   $0x1,0x16f93e1(%rip)   
>  # 826fe080 

Hm this is a RIP relative instruction, it should be modified by kprobes.

> 81004c9a: R_X86_64_PC32 vsyscall_gtod_data-0x5
> 81004c9f:   8b 50 24mov0x24(%rax),%edx
> 81004ca2:   8b 05 ec 5e 34 01   mov0x1345eec(%rip),%eax   
>  # 8234ab94 
> 81004ca4: R_X86_64_PC32 vclocks_used-0x4
> 
> The test adds a kprobe (optimized) at udpate_vsyscall+5. And will
> insert a jump on the two instructions after fentry. The difference
> between v7 and v8 is that v7 is touching vclocks_used and v8 is
> touching vsyscall_gtod_data.
> 
> Is there some black magic going on with the vsyscall area with
> vsyscall_gtod_data that is causing havoc when a kprobe is added there?

I think it might miss something when preprocessing RIP relative instruction.
Could you disable jump optimization as below and test what happen on
update_vsyscall+5 AND update_vsyscall+8? (RIP relative preprocess must
happen even if the jump optimization is disabled)

# echo 0 > /proc/sys/debug/kprobes-optimization


> I can dig a little more into this, but I'm currently at my HQ office
> with a lot of other objectives that I must get done, and I can't work
> on this much more this week.

OK, let me try to reproduce it in my environment.

> 
> I included my config (for my virt machine, which I was also able to
> trigger it with).

Thanks, but I think it should not depend on the kconfig.

> 
> The test that triggers this bug is:
> 
>  tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> 
> It runs the test fine, but other things just start to act up after I
> run it.

Yeah, thank you for digging it down. It is now much easier to me.

> 
> I notice that when I get into the state, journald and the dbus_daemon
> are constantly running. Perhaps the userspace time keeping went bad?

Yeah, I think so. Maybe addl instruction becomes broken.

Thank you,

-- 
Masami Hiramatsu 

Re: [PATCH] ubi: fastmap: Check each mapping only once

[Martin Kepplinger]

On 02.12.18 16:02, Richard Weinberger wrote:

Sasha,

Am Sonntag, 2. Dezember 2018, 15:35:43 CET schrieb Sasha Levin:

On Sun, Dec 02, 2018 at 11:50:33AM +, Sudip Mukherjee wrote:

Now queued up for 4.14.y, thanks.


can you *please* slow a little down?


True. It will really help if you can have some sort of fixed schedule
for stable release, like maybe stablerc is ready on Thursday or Friday
and release the stable on Monday. Having a weekend in stablerc will be
helpful for people like me who only get the time in weekends for
upstream or stable kernel.


Any sort of schedule will never work for everyone (for example, if it's
part of your paid job - you don't necessarily want to review stuff over
the weekend).


a schedule is not needed, but please give maintainers at least a chance
to react on stable inclusion request.
In this case Martin asked for inclusion on Monday and the patch was applied
two days later.


True, especially when the maintainer is asked a question as part of the 
patch.


I've already had the feeling that we'd need the other patch too, but in 
this case at least I should have searched for Fixes tags.


Greg, how about reminding people of Fixes tags in 
Documentation/process/stable-kernel-rules.rst ?


  martin


smime.p7s
Description: S/MIME cryptographic signature

Re: [patch 0/2 for-4.20] mm, thp: fix remote access and allocation regressions

[Michal Hocko]

On Mon 03-12-18 15:50:18, David Rientjes wrote:
> This fixes a 13.9% of remote memory access regression and 40% remote
> memory allocation regression on Haswell when the local node is fragmented
> for hugepage sized pages and memory is being faulted with either the thp
> defrag setting of "always" or has been madvised with MADV_HUGEPAGE.
> 
> The usecase that initially identified this issue were binaries that mremap
> their .text segment to be backed by transparent hugepages on startup.
> They do mmap(), madvise(MADV_HUGEPAGE), memcpy(), and mremap().

Do you have something you can share with so that other people can play
and try to reproduce?

> This requires a full revert and partial revert of commits merged during
> the 4.20 rc cycle.  The full revert, of ac5b2c18911f ("mm: thp: relax
> __GFP_THISNODE for MADV_HUGEPAGE mappings"), was anticipated to fix large
> amounts of swap activity on the local zone when faulting hugepages by
> falling back to remote memory.  This remote allocation causes the access
> regression and, if fragmented, the allocation regression.

Have you tried to measure any of the workloads Mel and Andrea have
pointed out during the previous review discussion? In other words what
is the impact on the THP success rate and allocation latencies for other
usecases?
-- 
Michal Hocko
SUSE Labs

Re: [patch 1/2 for-4.20] mm, thp: restore node-local hugepage allocations

[Michal Hocko]

On Mon 03-12-18 15:50:24, David Rientjes wrote:
> This is a full revert of ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
> MADV_HUGEPAGE mappings") and a partial revert of 89c83fb539f9 ("mm, thp:
> consolidate THP gfp handling into alloc_hugepage_direct_gfpmask").
> 
> By not setting __GFP_THISNODE, applications can allocate remote hugepages
> when the local node is fragmented or low on memory when either the thp
> defrag setting is "always" or the vma has been madvised with
> MADV_HUGEPAGE.
> 
> Remote access to hugepages often has much higher latency than local pages
> of the native page size.  On Haswell, ac5b2c18911f was shown to have a
> 13.9% access regression after this commit for binaries that remap their
> text segment to be backed by transparent hugepages.
> 
> The intent of ac5b2c18911f is to address an issue where a local node is
> low on memory or fragmented such that a hugepage cannot be allocated.  In
> every scenario where this was described as a fix, there is abundant and
> unfragmented remote memory available to allocate from, even with a greater
> access latency.
> 
> If remote memory is also low or fragmented, not setting __GFP_THISNODE was
> also measured on Haswell to have a 40% regression in allocation latency.
> 
> Restore __GFP_THISNODE for thp allocations.
> 
> Fixes: ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE 
> mappings")
> Fixes: 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into 
> alloc_hugepage_direct_gfpmask")

At minimum do not remove the cleanup part which consolidates the gfp
hadnling to a single place. There is no real reason to have the
__GFP_THISNODE ugliness outside of alloc_hugepage_direct_gfpmask.

I still hate the __GFP_THISNODE part as mentioned before. It is an ugly
hack but I can learn to live with it if this is indeed the only option
for the short term workaround until we find a proper solution.

> Signed-off-by: David Rientjes 
> ---
>  include/linux/mempolicy.h |  2 --
>  mm/huge_memory.c  | 42 +++
>  mm/mempolicy.c|  7 ---
>  3 files changed, 20 insertions(+), 31 deletions(-)
> 
> diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -139,8 +139,6 @@ struct mempolicy *mpol_shared_policy_lookup(struct 
> shared_policy *sp,
>  struct mempolicy *get_task_policy(struct task_struct *p);
>  struct mempolicy *__get_vma_policy(struct vm_area_struct *vma,
>   unsigned long addr);
> -struct mempolicy *get_vma_policy(struct vm_area_struct *vma,
> - unsigned long addr);
>  bool vma_policy_mof(struct vm_area_struct *vma);
>  
>  extern void numa_default_policy(void);
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -632,37 +632,27 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct 
> vm_fault *vmf,
>  static inline gfp_t alloc_hugepage_direct_gfpmask(struct vm_area_struct 
> *vma, unsigned long addr)
>  {
>   const bool vma_madvised = !!(vma->vm_flags & VM_HUGEPAGE);
> - gfp_t this_node = 0;
> -
> -#ifdef CONFIG_NUMA
> - struct mempolicy *pol;
> - /*
> -  * __GFP_THISNODE is used only when __GFP_DIRECT_RECLAIM is not
> -  * specified, to express a general desire to stay on the current
> -  * node for optimistic allocation attempts. If the defrag mode
> -  * and/or madvise hint requires the direct reclaim then we prefer
> -  * to fallback to other node rather than node reclaim because that
> -  * can lead to excessive reclaim even though there is free memory
> -  * on other nodes. We expect that NUMA preferences are specified
> -  * by memory policies.
> -  */
> - pol = get_vma_policy(vma, addr);
> - if (pol->mode != MPOL_BIND)
> - this_node = __GFP_THISNODE;
> - mpol_cond_put(pol);
> -#endif
> + const gfp_t gfp_mask = GFP_TRANSHUGE_LIGHT | __GFP_THISNODE;
>  
> + /* Always do synchronous compaction */
>   if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, 
> &transparent_hugepage_flags))
> - return GFP_TRANSHUGE | (vma_madvised ? 0 : __GFP_NORETRY);
> + return GFP_TRANSHUGE | __GFP_THISNODE |
> +(vma_madvised ? 0 : __GFP_NORETRY);
> +
> + /* Kick kcompactd and fail quickly */
>   if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, 
> &transparent_hugepage_flags))
> - return GFP_TRANSHUGE_LIGHT | __GFP_KSWAPD_RECLAIM | this_node;
> + return gfp_mask | __GFP_KSWAPD_RECLAIM;
> +
> + /* Synchronous compaction if madvised, otherwise kick kcompactd */
>   if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, 
> &transparent_hugepage_flags))
> - return GFP_TRANSHUGE_LIGHT | (vma_madvised ? 
> __GFP_DIRECT_RECLAIM :
> -  
> __GFP_KSWAPD_REC

Re: ext4 file system corruption with v4.19.3 / v4.19.4

[Gunter Königsmann]

After upgrading my kernel to 4.19 I got a corruption on nearly every
reboot or resume from suspend on my Acer s7-391 [UEFI boot].

Going to my UEFI setup and changing IDE mode from IDE to ATA seems to
have resolved the issue for me.

Don't know, though, if that is a valid data point or if it was a mere
accident (tested only on one computer) or just avoids the Bad Timing by
a few nanoseconds

Re: [PATCH 2/9] tools/lib/traceevent: Added support for pkg-config

[Namhyung Kim]

Hi Steve,

On Fri, Nov 30, 2018 at 10:44:05AM -0500, Steven Rostedt wrote:
> From: Tzvetomir Stoyanov 
> 
> This patch implements integration with pkg-config framework.
> pkg-config can be used by the library users to determine
> required CFLAGS and LDFLAGS in order to use the library
> 
> Signed-off-by: Tzvetomir Stoyanov 
> Signed-off-by: Steven Rostedt (VMware) 
> ---

[SNIP]
> diff --git a/tools/lib/traceevent/libtraceevent.pc.template 
> b/tools/lib/traceevent/libtraceevent.pc.template
> new file mode 100644
> index ..42e4d6cb6b9e
> --- /dev/null
> +++ b/tools/lib/traceevent/libtraceevent.pc.template
> @@ -0,0 +1,10 @@
> +prefix=INSTALL_PREFIX
> +libdir=${prefix}/lib64

Don't we care 32-bit systems anymore? :)

Thanks,
Namhyung


> +includedir=${prefix}/include/traceevent
> +
> +Name: libtraceevent
> +URL: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> +Description: Linux kernel trace event library
> +Version: LIB_VERSION
> +Cflags: -I${includedir}
> +Libs: -L${libdir} -ltraceevent
> -- 
> 2.19.1
> 
> 

Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF

[Greg KH]

On Mon, Dec 03, 2018 at 11:22:46PM +0159, Thomas Backlund wrote:
> Den 2018-12-03 kl. 11:22, skrev Sasha Levin:
> 
> > 
> > This is a case where theory collides with the real world. Yes, our QA is
> > lacking, but we don't have the option of not doing the current process.
> > If we stop backporting until a future data where our QA problem is
> > solved we'll end up with what we had before: users stuck on ancient
> > kernels without a way to upgrade.
> > 
> 
> Sorry, but you seem to be living in a different "real world"...
> 
> People stay on "ancient kernels" that "just works" instead of updating
> to a newer one that "hopefully/maybe/... works"

That's not good as those "ancient kernels" really just are "kernels with
lots of known security bugs".

It's your systems, I can't tell you what to do, but I will tell you that
running older, unfixed kernels, is a known liability.

Good luck!

greg k-h

Re: [PATCH v7 05/16] tracing: Generalize hist trigger onmax and save action

[Namhyung Kim]

On Mon, Dec 03, 2018 at 04:22:02PM -0600, Tom Zanussi wrote:
> Hi Namhyung,
> 
> On Fri, 2018-11-23 at 11:50 +0900, Namhyung Kim wrote:
> > Hi Tom,
> > 
> > On Wed, Nov 14, 2018 at 02:18:02PM -0600, Tom Zanussi wrote:
> > > From: Tom Zanussi 
> > > 
> 
> [snip]
> 
> > > 
>  enum handler_id {
> > >   HANDLER_ONMATCH = 1,
> > >   HANDLER_ONMAX,
> > > @@ -349,14 +358,18 @@ struct action_data {
> > >  
> > >   struct {
> > >   char*var_str;
> > > - unsigned intmax_var_ref_idx;
> > > - struct hist_field   *max_var;
> > > - struct hist_field   *var;
> > > - } onmax;
> > > + struct hist_field   *var_ref;
> > > + unsigned intvar_ref_idx;
> > 
> > I have a question.  It's confusing for me there are many indexes for
> > a
> > variable (ref).  The hist_field already has var.idx, var_idx and
> > var_ref_idx in it.  But you also added an external var_ref_idx along
> > with the var_ref.  Also I see another var_ref_idx in the action data.
> > Is all that really needed?  Could you please add some comment then?
> > 
> 
> Below is a patch with some comments I'll merge into the next version
> that I hope will help make things more clear.  Basically, the
> hist_field.var_idx isn't used so I've removed it and therefore that

Thanks!


> source of confusion, while var.idx is the variable's unique 'handle' in
> the tracing_map, used when getting and setting the variable.  And then
> there are the several versions of var_ref_idx used for different
> purposes depending on the context, but all of them are indices into the
> array of variable values collected when a trigger is hit.  For example,

So IIUC field->var_ref_idx is an index to the val_ref_vals array,
right?  Then if we keep the all hist_fields we don't need to have a
separate var_ref_idx IMHO.


> the var_ref_idx defined inside track_data is the index that points to
> the tracked var value, which the action can use directly, and the

I guess the track_data.var_ref_idx is always same as the
track_data.track_var.var_ref_idx, no?  If so we can get rid of it.


> var_ref_idx alongside the synth fields in action_data is the index of
> the first param used when generating a synthetic event, and so on.

For synth event, we have hist_data->synth_var_refs[] but it's not
passed to trace_synth() so no way to know original var_ref_idx and I'm
ok with having action_data.var_ref_idx.

But I don't see where hist_data->synth_var_refs is used other than
find_var_ref().  And for that purpose, I guess it's more efficient to
use hist_data->var_refs[] so that we can remove synth_var_refs.


> 
> Tom 
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 818944391d97..5310ef73f023 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -39,6 +39,16 @@ enum field_op_id {
>   FIELD_OP_UNARY_MINUS,
>  };
>  
> +/*
> + * A hist_var (histogram variable) contains variable information for
> + * hist_fields having the HIST_FIELD_FL_VAR or HIST_FIELD_FL_VAR_REF
> + * flag set.  A hist_var has a variable name e.g. ts0, and is
> + * associated with a given histogram trigger, as specified by
> + * hist_data.  The hist_var idx is the unique index assigned to the
> + * variable by the hist trigger's tracing_map.  The idx is what is
> + * used to set a variable's value and, by a variable reference, to
> + * retrieve it.
> + */
>  struct hist_var {
>   char*name;
>   struct hist_trigger_data*hist_data;
> @@ -60,7 +70,15 @@ struct hist_field {
>   char*system;
>   char*event_name;
>   char*name;
> - unsigned intvar_idx;
> +
> + /*
> +  * When a histogram trigger is hit, if it has any references
> +  * to variables, the values of those variables are collected
> +  * into a var_ref_vals array by resolve_var_refs().  The
> +  * current value of each variable is read from the tracing_map
> +  * using the hist field's hist_var.idx and entered into the
> +  * var_ref_idx entry i.e. var_ref_vals[var_ref_idx].
> +  */
>   unsigned intvar_ref_idx;
>   boolread_once;
>  };
> @@ -350,6 +368,14 @@ struct action_data {
>   unsigned intn_params;
>   char*params[SYNTH_FIELDS_MAX];
>  
> + /*
> +  * When a histogram trigger is hit, the values of any
> +  * references to variables, including variables being passed
> +  * as parameters to synthetic events, are collected into a
> +  * var_ref_vals array.  This var_ref_idx is the index of the
> +  * first param in the array to be passed to the synthetic
> +  * event invocation.
> +  */
>   unsigned int

Re: [PATCH 2/3] mm/vmscan: Enable kswapd to reclaim low-protected memory

[Michal Hocko]

On Tue 04-12-18 10:40:29, Xunlei Pang wrote:
> On 2018/12/4 AM 1:22, Michal Hocko wrote:
> > On Mon 03-12-18 23:20:31, Xunlei Pang wrote:
> >> On 2018/12/3 下午7:56, Michal Hocko wrote:
> >>> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
>  There may be cgroup memory overcommitment, it will become
>  even common in the future.
> 
>  Let's enable kswapd to reclaim low-protected memory in case
>  of memory pressure, to mitigate the global direct reclaim
>  pressures which could cause jitters to the response time of
>  lantency-sensitive groups.
> >>>
> >>> Please be more descriptive about the problem you are trying to handle
> >>> here. I haven't actually read the patch but let me emphasise that the
> >>> low limit protection is important isolation tool. And allowing kswapd to
> >>> reclaim protected memcgs is going to break the semantic as it has been
> >>> introduced and designed.
> >>
> >> We have two types of memcgs: online groups(important business)
> >> and offline groups(unimportant business). Online groups are
> >> all configured with MAX low protection, while offline groups
> >> are not at all protected(with default 0 low).
> >>
> >> When offline groups are overcommitted, the global memory pressure
> >> suffers. This will cause the memory allocations from online groups
> >> constantly go to the slow global direct reclaim in order to reclaim
> >> online's page caches, as kswap is not able to reclaim low-protection
> >> memory. low is not hard limit, it's reasonable to be reclaimed by
> >> kswapd if there's no other reclaimable memory.
> > 
> > I am sorry I still do not follow. What role do offline cgroups play.
> > Those are certainly not low mem protected because mem_cgroup_css_offline
> > will reset them to 0.
> > 
> 
> Oh, I meant "offline groups" to be "offline-business groups", memcgs
> refered to here are all "online state" from kernel's perspective.

What is offline-business group? Please try to explain the actual problem
in much more details and do not let us guess.

-- 
Michal Hocko
SUSE Labs

[PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices

[Chunyan Zhang]

Some standard SD host controllers can support both external dma
controllers as well as ADMA/SDMA in which the SD host controller
acts as DMA master. TI's omap controller is the case as an example.

Currently the generic SDHCI code supports ADMA/SDMA integrated in
the host controller but does not have any support for external DMA
controllers implemented using dmaengine, meaning that custom code is
needed for any systems that use an external DMA controller with SDHCI.

Signed-off-by: Chunyan Zhang 
---
 drivers/mmc/host/Kconfig |   3 +
 drivers/mmc/host/sdhci.c | 185 ++-
 drivers/mmc/host/sdhci.h |   8 ++
 3 files changed, 195 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1b58739..3101da6 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -977,3 +977,6 @@ config MMC_SDHCI_OMAP
  If you have a controller with this interface, say Y or M here.
 
  If unsure, say N.
+
+config MMC_SDHCI_EXTERNAL_DMA
+bool
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 99bdae5..04b029c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host *host, 
struct mmc_request *mrq)
del_timer(&host->timer);
 }
 
+#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
+static int sdhci_external_dma_init(struct sdhci_host *host)
+{
+   int ret = 0;
+   struct mmc_host *mmc = host->mmc;
+
+   host->tx_chan = dma_request_chan(mmc->parent, "tx");
+   if (IS_ERR(host->tx_chan)) {
+   ret = PTR_ERR(host->tx_chan);
+   if (ret != -EPROBE_DEFER)
+   pr_warn("Failed to request TX DMA channel.\n");
+   host->tx_chan = NULL;
+   return ret;
+   }
+
+   host->rx_chan = dma_request_chan(mmc->parent, "rx");
+   if (IS_ERR(host->rx_chan)) {
+   if (host->tx_chan) {
+   dma_release_channel(host->tx_chan);
+   host->tx_chan = NULL;
+   }
+
+   ret = PTR_ERR(host->rx_chan);
+   if (ret != -EPROBE_DEFER)
+   pr_warn("Failed to request RX DMA channel.\n");
+   host->rx_chan = NULL;
+   }
+
+   return ret;
+}
+
+static inline struct dma_chan *
+sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
+{
+   return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
+}
+
+static int sdhci_external_dma_setup(struct sdhci_host *host,
+   struct mmc_command *cmd)
+{
+   int ret, i;
+   struct dma_async_tx_descriptor *desc;
+   struct mmc_data *data = cmd->data;
+   struct dma_chan *chan;
+   struct dma_slave_config cfg;
+   dma_cookie_t cookie;
+
+   if (!data)
+   return 0;
+
+   if (!host->mapbase)
+   return -EINVAL;
+
+   cfg.src_addr = host->mapbase + SDHCI_BUFFER;
+   cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
+   cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   cfg.src_maxburst = data->blksz / 4;
+   cfg.dst_maxburst = data->blksz / 4;
+
+   /* Sanity check: all the SG entries must be aligned by block size. */
+   for (i = 0; i < data->sg_len; i++) {
+   if ((data->sg + i)->length % data->blksz)
+   return -EINVAL;
+   }
+
+   chan = sdhci_external_dma_channel(host, data);
+
+   ret = dmaengine_slave_config(chan, &cfg);
+   if (ret)
+   return ret;
+
+   desc = dmaengine_prep_slave_sg(chan, data->sg, data->sg_len,
+  mmc_get_dma_dir(data),
+  DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!desc)
+   return -EINVAL;
+
+   desc->callback = NULL;
+   desc->callback_param = NULL;
+
+   cookie = dmaengine_submit(desc);
+   if (cookie < 0)
+   ret = cookie;
+
+   return ret;
+}
+
+static void sdhci_external_dma_release(struct sdhci_host *host)
+{
+   if (host->tx_chan) {
+   dma_release_channel(host->tx_chan);
+   host->tx_chan = NULL;
+   }
+
+   if (host->rx_chan) {
+   dma_release_channel(host->rx_chan);
+   host->rx_chan = NULL;
+   }
+
+   sdhci_switch_external_dma(host, false);
+}
+
+static void sdhci_external_dma_prepare_data(struct sdhci_host *host,
+   struct mmc_command *cmd)
+{
+   if (sdhci_external_dma_setup(host, cmd)) {
+   sdhci_external_dma_release(host);
+   pr_err("%s: Failed to setup external DMA, switch to the DMA/PIO 
which standard SDHCI provides.\n",
+ 

Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined

[Naoya Horiguchi]

On Mon, Dec 03, 2018 at 11:03:09AM +0100, Michal Hocko wrote:
> From: Michal Hocko 
> 
> We have received a bug report that an injected MCE about faulty memory
> prevents memory offline to succeed. The underlying reason is that the
> HWPoison page has an elevated reference count and the migration keeps
> failing. There are two problems with that. First of all it is dubious
> to migrate the poisoned page because we know that accessing that memory
> is possible to fail. Secondly it doesn't make any sense to migrate a
> potentially broken content and preserve the memory corruption over to a
> new location.
> 
> Oscar has found out that it is the elevated reference count from
> memory_failure that is confusing the offlining path. HWPoisoned pages
> are isolated from the LRU list but __offline_pages might still try to
> migrate them if there is any preceding migrateable pages in the pfn
> range. Such a migration would fail due to the reference count but
> the migration code would put it back on the LRU list. This is quite
> wrong in itself but it would also make scan_movable_pages stumble over
> it again without any way out.
> 
> This means that the hotremove with hwpoisoned pages has never really
> worked (without a luck). HWPoisoning really needs a larger surgery
> but an immediate and backportable fix is to skip over these pages during
> offlining. Even if they are still mapped for some reason then
> try_to_unmap should turn those mappings into hwpoison ptes and cause
> SIGBUS on access. Nobody should be really touching the content of the
> page so it should be safe to ignore them even when there is a pending
> reference count.
> 
> Debugged-by: Oscar Salvador 
> Cc: stable
> Signed-off-by: Michal Hocko 
> ---
> Hi,
> I am sending this as an RFC now because I am not fully sure I see all
> the consequences myself yet. This has passed a testing by Oscar but I
> would highly appreciate a review from Naoya about my assumptions about
> hwpoisoning. E.g. it is not entirely clear to me whether there is a
> potential case where the page might be still mapped.

One potential case is ksm page, for which we give up unmapping and leave
it unmapped. Rather than that I don't have any idea, but any new type of
page would be potentially categorized to this class.

> I have put
> try_to_unmap just to be sure. It would be really great if I could drop
> that part because then it is not really great which of the TTU flags to
> use to cover all potential cases.
> 
> I have marked the patch for stable but I have no idea how far back it
> should go. Probably everything that already has hotremove and hwpoison
> code.

Yes, maybe this could be ported to all active stable trees.

> 
> Thanks in advance!
> 
>  mm/memory_hotplug.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c6c42a7425e5..08c576d5a633 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -1366,6 +1367,17 @@ do_migrate_range(unsigned long start_pfn, unsigned 
> long end_pfn)
>   pfn = page_to_pfn(compound_head(page))
>   + hpage_nr_pages(page) - 1;
>  
> + /*
> +  * HWPoison pages have elevated reference counts so the 
> migration would
> +  * fail on them. It also doesn't make any sense to migrate them 
> in the
> +  * first place. Still try to unmap such a page in case it is 
> still mapped.
> +  */
> + if (PageHWPoison(page)) {
> + if (page_mapped(page))
> + try_to_unmap(page, TTU_IGNORE_MLOCK | 
> TTU_IGNORE_ACCESS);
> + continue;
> + }
> +

I think this looks OK (no better idea.)

Reviewed-by: Naoya Horiguchi 

I wondered why I didn't find this for long, and found that my testing only
covered the case where PageHWPoison is the first page of memory block.
scan_movable_pages() considers PageHWPoison as non-movable, so 
do_migrate_range()
started with pfn after the PageHWPoison and never tried to migrate it
(so effectively ignored every PageHWPoison as the above code does.)

Thanks,
Naoya Horiguchi

>   if (!get_page_unless_zero(page))
>   continue;
>   /*
> -- 
> 2.19.1
> 
> 

[PATCH V3 3/3] dt-bindings: sdhci-omap: Add example for using external dma

[Chunyan Zhang]

sdhci-omap can support both external dma controller via dmaengine
framework as well as ADMA which standard SD host controller
provides.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/mmc/sdhci-omap.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
index 393848c..c73fd47 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
@@ -12,6 +12,11 @@ Required properties:
 "ddr_1_8v-rev11", "ddr_1_8v" or "ddr_3_3v", "hs200_1_8v-rev11",
 "hs200_1_8v",
 - pinctrl- : Pinctrl states as described in 
bindings/pinctrl/pinctrl-bindings.txt
+- dmas:List of DMA specifiers with the controller specific 
format as described
+   in the generic DMA client binding. A tx and rx specifier is 
required.
+- dma-names:   List of DMA request names. These strings correspond 1:1 with the
+   DMA specifiers listed in dmas. The string naming is to be "rx"
+   and "tx" for RX and TX DMA requests, respectively.
 
 Example:
mmc1: mmc@4809c000 {
@@ -20,4 +25,6 @@ Example:
ti,hwmods = "mmc1";
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
+   dmas = <&sdma 61 &sdma 62>;
+   dma-names = "tx", "rx";
};
-- 
2.7.4

[PATCH V3 2/3] mmc: sdhci-omap: Add using external dma

[Chunyan Zhang]

sdhci-omap can support both external dma controller via dmaengine framework
as well as ADMA which standard SD host controller provides.

Signed-off-by: Chunyan Zhang 
---
 drivers/mmc/host/Kconfig  |  1 +
 drivers/mmc/host/sdhci-omap.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 3101da6..7846754 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
 config MMC_SDHCI_OMAP
tristate "TI SDHCI Controller Support"
depends on MMC_SDHCI_PLTFM && OF
+   select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
help
  This selects the Secure Digital Host Controller Interface (SDHCI)
  support present in TI's DRA7 SOCs. The controller supports
diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
index 88347ce..b164fcc 100644
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -896,6 +896,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
const struct of_device_id *match;
struct sdhci_omap_data *data;
const struct soc_device_attribute *soc;
+   struct resource *regs;
 
match = of_match_device(omap_sdhci_match, dev);
if (!match)
@@ -908,6 +909,10 @@ static int sdhci_omap_probe(struct platform_device *pdev)
}
offset = data->offset;
 
+   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!regs)
+   return -ENXIO;
+
host = sdhci_pltfm_init(pdev, &sdhci_omap_pdata,
sizeof(*omap_host));
if (IS_ERR(host)) {
@@ -924,6 +929,7 @@ static int sdhci_omap_probe(struct platform_device *pdev)
omap_host->timing = MMC_TIMING_LEGACY;
omap_host->flags = data->flags;
host->ioaddr += offset;
+   host->mapbase = regs->start;
 
mmc = host->mmc;
sdhci_get_of_property(pdev);
@@ -991,6 +997,10 @@ static int sdhci_omap_probe(struct platform_device *pdev)
host->mmc_host_ops.execute_tuning = sdhci_omap_execute_tuning;
host->mmc_host_ops.enable_sdio_irq = sdhci_omap_enable_sdio_irq;
 
+   /* Switch to external DMA only if there is the "dmas" property */
+   if (of_find_property(dev->of_node, "dmas", NULL))
+   sdhci_switch_external_dma(host, true);
+
ret = sdhci_setup_host(host);
if (ret)
goto err_put_sync;
-- 
2.7.4

Re: [PATCH] drm/sched: Fix a use-after-free when tracing the scheduler.

[Koenig, Christian]

Am 03.12.18 um 21:14 schrieb Eric Anholt:
> With DEBUG_SLAB (poisoning on free) enabled, I could quickly produce
> an oops when tracing V3D.

Good catch, but the solution is a clear NAK.

drm_sched_entity_add_dependency_cb() can result in setting 
entity->dependency to NULL. That in turn can lead to a memory leak 
because we call the _put with a NULL fence.

Instead we should rather call trace_drm_sched_job_wait_dep() before even 
calling drm_sched_entity_add_dependency_cb(). This is also cleaner 
because we want to trace which dependencies the driver gave to the 
scheduler and not which we actually needed to add a callback to.

Regards,
Christian.

>
> Signed-off-by: Eric Anholt 
> ---
>
> I think this patch is correct (though maybe a bigger refactor could
> avoid the extra get/put?), but I've still got this with "vblank_mode=0
> perf record -a -e v3d:.\* -e gpu_scheduler:.\* glxgears".  Any ideas?
>
> [  139.842191] Unable to handle kernel NULL pointer dereference at virtual 
> address 0020
> [  139.850413] pgd = eab7bb57
> [  139.854424] [0020] *pgd=8040004003, *pmd=
> [  139.860523] Internal error: Oops: 206 [#1] SMP ARM
> [  139.865340] Modules linked in:
> [  139.868404] CPU: 0 PID: 1161 Comm: v3d_render Not tainted 4.20.0-rc4+ #552
> [  139.875287] Hardware name: Broadcom STB (Flattened Device Tree)
> [  139.881228] PC is at perf_trace_drm_sched_job_wait_dep+0xa8/0xf4
> [  139.887243] LR is at 0xe9790274
> [  139.890388] pc : []lr : []psr: a0050013
> [  139.896662] sp : ed21dec0  ip : ed21dec0  fp : ed21df04
> [  139.901893] r10: ed267478  r9 :   r8 : ff7bde04
> [  139.907123] r7 :   r6 : 0063  r5 :   r4 : c1208448
> [  139.913659] r3 : c1265690  r2 : ff7bf660  r1 : 0034  r0 : ff7bf660
> [  139.920196] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [  139.927339] Control: 30c5383d  Table: 68fa3b40  DAC: fffd
> [  139.933095] Process v3d_render (pid: 1161, stack limit = 0xb3c84b1b)
> [  139.939457] Stack: (0xed21dec0 to 0xed21e000)
> [  139.943821] dec0: 20050013  eb9700cc  ec0e8e80  
> eb9700cc e9790274
> [  139.952009] dee0:  e2f59345 eb970078 eba8f680 c12ae00c c1208478 
>  e8c2b048
> [  139.960197] df00: eb9700cc c06e92e4 c06e8f04  80050013 ed267478 
> eb970078 
> [  139.968385] df20: ed267578 c0e45ae0 e9093080 c06e831c ed267630 c06e8120 
> c06e77d4 c1208448
> [  139.976573] df40: ee2e8acc 0001  ee2e8640 c0272ab4 ed21df54 
> ed21df54 e2f59345
> [  139.984762] df60: ed21c000 ed1b4800 ed2d7840  ed21c000 ed267478 
> c06e8084 ee935cb0
> [  139.992950] df80: ed1b4838 c0249b44 ed21c000 ed2d7840 c02499e4  
>  
> [  140.001138] dfa0:    c02010ac   
>  
> [  140.009326] dfc0:       
>  
> [  140.017514] dfe0:     0013  
>  
> [  140.025707] [] (perf_trace_drm_sched_job_wait_dep) from 
> [] (drm_sched_entity_pop_job+0x394/0x438)
> [  140.036332] [] (drm_sched_entity_pop_job) from [] 
> (drm_sched_main+0x9c/0x298)
> [  140.045221] [] (drm_sched_main) from [] 
> (kthread+0x160/0x168)
> [  140.052716] [] (kthread) from [] 
> (ret_from_fork+0x14/0x28)
>
>   drivers/gpu/drm/scheduler/sched_entity.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index 4463d3826ecb..0d4fc86089cb 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -440,13 +440,15 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct 
> drm_sched_entity *entity)
>   
>   while ((entity->dependency =
>   sched->ops->dependency(sched_job, entity))) {
> -
> + dma_fence_get(entity->dependency);
>   if (drm_sched_entity_add_dependency_cb(entity)) {
>   
>   trace_drm_sched_job_wait_dep(sched_job,
>entity->dependency);
> + dma_fence_put(entity->dependency);
>   return NULL;
>   }
> + dma_fence_put(entity->dependency);
>   }
>   
>   /* skip jobs from entity that marked guilty */

[PATCH V3 0/3] Add support for using external dma in SDHCI

[Chunyan Zhang]

Currently the generic SDHCI code in the Linux kernel supports the SD
standard DMA integrated into the host controller but does not have any
support for external DMA controllers implemented using dmaengine meaning
that custom code is needed for any systems that use a generic DMA
controller with SDHCI which in practice means any SDHCI controller that
doesn't have an integrated DMA controller so we should have this as a
generic feature.

There are already a number of controller specific drivers that have dmaengine
code, and some could use sdhci.c actually, but needed to implement 
mmc_ops->request()
in their specific driver for sending command with external dma using dmaengine
framework, with this patchset, them will take advantage of the generic support.
TI's omap controller is the case as an example.

Any comments are very appreciated.

Thanks,
Chunyan

Changes from v2 (https://lkml.org/lkml/2018/11/12/1936):
* Remove CONFIG_EXTERNAL_DMA prompt and help graph;
* Add checking for cmd->data;
* Select MMC_SDHCI_EXTERNAL_DMA for MMC_SDHCI_OMAP;
* Add checking if there's 'dmas' in device tree before decide using external 
dma.

Changes from v1 (https://lkml.org/lkml/2018/11/5/110):
(The code on patch 1/3 only was revised)
* Address comments from Arnd:
- Release channel when failed to request it unconditionally;
- Skip warning message if get EPROBE_DEFER;
* Address Andrian's comments:
- Replace extdma with external_dma;
- Add release dma resources in sdhci_cleanup_host() and sdhci_remove_host();
- Release dma resources once dmaengine_submit() failed.
- Put rx/tx_chan in struct sdhci_host, and removed unused structure.
* Fall back to the DMA/PIO which standard SDHCI supports, if 
sdhci_external_dma_setup()
  or sdhci_external_dma_init failed;

Chunyan Zhang (3):
  mmc: sdhci: add support for using external DMA devices
  mmc: sdhci-omap: Add using external dma
  dt-bindings: sdhci-omap: Add example for using external dma

 .../devicetree/bindings/mmc/sdhci-omap.txt |   7 +
 drivers/mmc/host/Kconfig   |   4 +
 drivers/mmc/host/sdhci-omap.c  |  10 ++
 drivers/mmc/host/sdhci.c   | 185 -
 drivers/mmc/host/sdhci.h   |   8 +
 5 files changed, 213 insertions(+), 1 deletion(-)

-- 
2.7.4

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Michal Hocko]

On Tue 04-12-18 11:05:57, Pingfan Liu wrote:
> During my test on some AMD machine, with kexec -l nr_cpus=x option, the
> kernel failed to bootup, because some node's data struct can not be allocated,
> e.g, on x86, initialized by init_cpu_to_node()->init_memory_less_node(). But
> device->numa_node info is used as preferred_nid param for
> __alloc_pages_nodemask(), which causes NULL reference
>   ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
> This patch tries to fix the issue by falling back to the first online node,
> when encountering such corner case.

We have seen similar issues already and the bug was usually that the
zonelists were not initialized yet or the node is completely bogus.
Zonelists should be initialized by build_all_zonelists quite early so I
am wondering whether the later is the case. What is the actual node
number the device is associated with?

Your patch is not correct btw, because we want to fallback into the node in
the distance order rather into the first online node.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Pingfan Liu]

On Tue, Dec 4, 2018 at 2:54 PM Wei Yang  wrote:
>
> On Tue, Dec 04, 2018 at 11:05:57AM +0800, Pingfan Liu wrote:
> >During my test on some AMD machine, with kexec -l nr_cpus=x option, the
> >kernel failed to bootup, because some node's data struct can not be 
> >allocated,
> >e.g, on x86, initialized by init_cpu_to_node()->init_memory_less_node(). But
> >device->numa_node info is used as preferred_nid param for
>
> could we fix the preferred_nid before passed to
> __alloc_pages_nodemask()?
>
Yes, we can doit too, but what is the gain?

> BTW, I don't catch the function call flow to this point. Would you mind
> giving me some hint?
>
You can track the code along slab_alloc() ->...->__alloc_pages_nodemask()

Thanks,
Pingfan

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Pingfan Liu]

On Tue, Dec 4, 2018 at 11:53 AM David Rientjes  wrote:
>
> On Tue, 4 Dec 2018, Pingfan Liu wrote:
>
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index 76f8db0..8324953 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -453,6 +453,8 @@ static inline int gfp_zonelist(gfp_t flags)
> >   */
> >  static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
> >  {
> > + if (unlikely(!node_online(nid)))
> > + nid = first_online_node;
> >   return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
> >  }
> >
>
> So we're passing the node id from dev_to_node() to kmalloc which
> interprets that as the preferred node and then does node_zonelist() to
> find the zonelist at allocation time.
>
> What happens if we fix this in alloc_dr()?  Does anything else cause
> problems?
>
I think it is better to fix it mm, since it can protect any new
similar bug in future. While fixing in alloc_dr() just work at present

> And rather than using first_online_node, would next_online_node() work?
>
What is the gain? Is it for memory pressure on node0?

Thanks,
Pingfan

> I'm thinking about this:
>
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -100,6 +100,8 @@ static __always_inline struct devres * 
> alloc_dr(dr_release_t release,
> &tot_size)))
> return NULL;
>
> +   if (unlikely(!node_online(nid)))
> +   nid = next_online_node(nid);
> dr = kmalloc_node_track_caller(tot_size, gfp, nid);
> if (unlikely(!dr))
> return NULL;

general protection fault in kvm_arch_vcpu_ioctl_run

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:4b78317679c4 Merge branch 'x86-pti-for-linus' of git://git..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e979f540
kernel config:  https://syzkaller.appspot.com/x/.config?x=4602730af4f872ef
dashboard link: https://syzkaller.appspot.com/bug?extid=39810e6c400efadfef71
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+39810e6c400efadfe...@syzkaller.appspotmail.com

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 14932 Comm: syz-executor0 Not tainted 4.20.0-rc4+ #138
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:kvm_apic_hw_enabled arch/x86/kvm/lapic.h:169 [inline]
RIP: 0010:vcpu_scan_ioapic arch/x86/kvm/x86.c:7449 [inline]
RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:7602 [inline]
RIP: 0010:vcpu_run arch/x86/kvm/x86.c:7874 [inline]
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x5296/0x7320 arch/x86/kvm/x86.c:8074
Code: 03 00 00 48 89 f8 48 c1 e8 03 42 80 3c 20 00 0f 85 b4 1e 00 00 49 8b  
9f e0 03 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00  
0f 85 8a 1e 00 00 48 8b 9b 88 00 00 00 48 8d bb d8

RSP: 0018:88818b0bf530 EFLAGS: 00010206
RAX: 0011 RBX:  RCX: c9001302b000
RDX: 00cf RSI: 81103a68 RDI: 0088
RBP: 88818b0bf8d0 R08: 8881bfe8e0c0 R09: 0008
R10: 0028 R11: 810feb0f R12: dc00
R13:  R14: c90007ddfdb8 R15: 888188a18400
FS:  7ff919977700() GS:8881dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fc94713c518 CR3: 0001cdea CR4: 001426f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 kvm_vcpu_ioctl+0x5c8/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2596
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:509 [inline]
 do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713
 __do_sys_ioctl fs/ioctl.c:720 [inline]
 __se_sys_ioctl fs/ioctl.c:718 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ff919976c78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0003 RCX: 00457569
RDX:  RSI: ae80 RDI: 0005
RBP: 0072bf00 R08:  R09: 
R10:  R11: 0246 R12: 7ff9199776d4
R13: 004c034e R14: 004d0d60 R15: 
Modules linked in:
kobject: 'loop5' (4f26f0d5): kobject_uevent_env
kobject: 'loop5' (4f26f0d5): fill_kobj_path: path  
= '/devices/virtual/block/loop5'

kobject: 'loop1' (10db8550): kobject_uevent_env
kobject: 'loop1' (10db8550): fill_kobj_path: path  
= '/devices/virtual/block/loop1'

kobject: 'loop3' (941a4e7a): kobject_uevent_env
kobject: 'loop3' (941a4e7a): fill_kobj_path: path  
= '/devices/virtual/block/loop3'

---[ end trace d7fab4e7c1a70214 ]---
RIP: 0010:kvm_apic_hw_enabled arch/x86/kvm/lapic.h:169 [inline]
RIP: 0010:vcpu_scan_ioapic arch/x86/kvm/x86.c:7449 [inline]
RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:7602 [inline]
RIP: 0010:vcpu_run arch/x86/kvm/x86.c:7874 [inline]
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x5296/0x7320 arch/x86/kvm/x86.c:8074
Code: 03 00 00 48 89 f8 48 c1 e8 03 42 80 3c 20 00 0f 85 b4 1e 00 00 49 8b  
9f e0 03 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00  
0f 85 8a 1e 00 00 48 8b 9b 88 00 00 00 48 8d bb d8

kobject: 'loop4' (4a89aba1): kobject_uevent_env
kobject: 'loop4' (4a89aba1): fill_kobj_path: path  
= '/devices/virtual/block/loop4'

kobject: 'loop2' (704d7e59): kobject_uevent_env
kobject: 'loop2' (704d7e59): fill_kobj_path: path  
= '/devices/virtual/block/loop2'

kobject: 'loop4' (4a89aba1): kobject_uevent_env
kobject: 'loop4' (4a89aba1): fill_kobj_path: path  
= '/devices/virtual/block/loop4'

kobject: 'loop2' (704d7e59): kobject_uevent_env
RSP: 0018:88818b0bf530 EFLAGS: 00010206
RAX: 0011 RBX:  RCX: c9001302b000
kobject: 'loop2' (704d7e59): fill_kobj_path: path  
= '/devices/virtual/block/loop2'

RDX: 00cf RSI: 81103a68 RDI: 0

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Wei Yang]

On Tue, Dec 04, 2018 at 11:05:57AM +0800, Pingfan Liu wrote:
>During my test on some AMD machine, with kexec -l nr_cpus=x option, the
>kernel failed to bootup, because some node's data struct can not be allocated,
>e.g, on x86, initialized by init_cpu_to_node()->init_memory_less_node(). But
>device->numa_node info is used as preferred_nid param for

could we fix the preferred_nid before passed to
__alloc_pages_nodemask()?

BTW, I don't catch the function call flow to this point. Would you mind
giving me some hint?

-- 
Wei Yang
Help you, Help me

linux-next: Tree for Dec 4

[Stephen Rothwell]

Hi all,

Changes since 20181203:

The rdma tree gained a build failure so I used the version from
next-20181203.

The bpf-next tree gained conflicts against the bpf tree.

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

The akpm tree lost its build failure but gained a conflict against the
pm tree.

Non-merge commits (relative to Linus' tree): 5958
 6050 files changed, 291311 insertions(+), 163581 deletions(-)



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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (0072a0c14d5b Merge tag 'media/v4.20-4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs)
Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2)
Merging arc-current/for-curr (10d443431dc2 ARC: io.h: Implement 
reads{x}()/writes{x}())
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false 
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (ea2412dc21cc ACPI/IORT: Fix 
iort_get_platform_device_domain() uninitialized pointer value)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (bf3d6afbb234 powerpc: Look for "stdout-path" when 
setting up legacy consoles)
Merging sparc/master (f3f950dba37b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (35b827b6d061 tun: forbid iface creation with rtnl ops)
Merging bpf/master (dcb40590e69e bpf: refactor bpf_test_run() to separate own 
failures and test program result)
Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on 
acquire)
Merging netfilter/master (d78a5ebd8b18 Merge branch '1GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore 
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (7bca603a69c0 RDMA/mlx5: Initialize return variable 
in case pagefault was skipped)
Merging sound-current/for-linus (5f8cf7125826 ALSA: usb-audio: Fix UAF 
decrement if card has no live interfaces in card.c)
Merging sound-asoc-fixes/for-linus (280ea4299e05 Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3)
Merging regulator-fixes/for-linus (fea4962497d8 Merge branch 'regulator-4.20' 
into regulator-linus)
Merging spi-fixes/for-linus (9ea83d4c2b9a Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (c74eadf881ad Merge remote-tracking branch 
'lorenzo/pci/controller-fixes' into for-linus)
Merging driver-core.current/driver-core-linus (2595646791c3 Linux 4.20-rc5)
Merging tty.current/tty-linus (2a48602615e0 tty: do not set TTY_IO_ERROR flag 
if console port)
Merging usb.current/usb-linus (2595646791c3 Linux 4.20-rc5)
Merging usb-gadget-fixes/fixes (069caf5950df USB: oma

[tip:locking/core] tools/memory-model: Make scripts take "-j" abbreviation for "--jobs"

[tip-bot for Paul E. McKenney]

Commit-ID:  a6f1de04276d036b61c4d1dbd0367e6b430d8783
Gitweb: https://git.kernel.org/tip/a6f1de04276d036b61c4d1dbd0367e6b430d8783
Author: Paul E. McKenney 
AuthorDate: Mon, 3 Dec 2018 15:04:51 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 4 Dec 2018 07:29:52 +0100

tools/memory-model: Make scripts take "-j" abbreviation for "--jobs"

The "--jobs" argument to the litmus-test scripts is similar to the "-jN"
argument to "make", so this commit allows the "-jN" form as well.  While
in the area, it also prohibits the various forms of "-j0".

Suggested-by: Alan Stern 
Signed-off-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: will.dea...@arm.com
Link: http://lkml.kernel.org/r/20181203230451.28921-3-paul...@linux.ibm.com
Signed-off-by: Ingo Molnar 
---
 tools/memory-model/scripts/parseargs.sh | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/memory-model/scripts/parseargs.sh 
b/tools/memory-model/scripts/parseargs.sh
index 96b307c8d64a..859e1d581e05 100644
--- a/tools/memory-model/scripts/parseargs.sh
+++ b/tools/memory-model/scripts/parseargs.sh
@@ -95,8 +95,18 @@ do
LKMM_HERD_OPTIONS="$2"
shift
;;
-   --jobs|--job)
-   checkarg --jobs "(number)" "$#" "$2" '^[0-9]\+$' '^--'
+   -j[1-9]*)
+   njobs="`echo $1 | sed -e 's/^-j//'`"
+   trailchars="`echo $njobs | sed -e 's/[0-9]\+\(.*\)$/\1/'`"
+   if test -n "$trailchars"
+   then
+   echo $1 trailing characters "'$trailchars'"
+   usagehelp
+   fi
+   LKMM_JOBS="`echo $njobs | sed -e 's/^\([0-9]\+\).*$/\1/'`"
+   ;;
+   --jobs|--job|-j)
+   checkarg --jobs "(number)" "$#" "$2" '^[1-9][0-9]\+$' '^--'
LKMM_JOBS="$2"
shift
;;

Re: [RFC PATCH V2 00/11] Intel EPT-Based Sub-page Protection Support

[Yi Zhang]

On 2018-12-03 at 05:56:13 +0200, Mihai Donțu wrote:
> Hi Paolo,
> 
> On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote:
> > On 30/11/18 08:52, Zhang Yi wrote:
> > > Here is a patch-series which adding EPT-Based Sub-page Write Protection 
> > > Support.
> > > 
> > > Introduction:
> > > 
> > > EPT-Based Sub-page Write Protection referred to as SPP, it is a 
> > > capability which
> > > allow Virtual Machine Monitors(VMM) to specify write-permission for guest
> > > physical memory at a sub-page(128 byte) granularity.  When this 
> > > capability is
> > > utilized, the CPU enforces write-access permissions for sub-page regions 
> > > of 4K
> > > pages as specified by the VMM. EPT-based sub-page permissions is intended 
> > > to
> > > enable fine-grained memory write enforcement by a VMM for security(guest 
> > > OS
> > > monitoring) and usages such as device virtualization and memory 
> > > check-point.
> > > 
> > > SPPT is active when the "sub-page write protection" VM-execution control 
> > > is 1.
> > > SPPT looks up the guest physical addresses to derive a 64 bit "sub-page
> > > permission" value containing sub-page write permissions. The lookup from
> > > guest-physical addresses to the sub-page region permissions is determined 
> > > by a
> > > set of SPPT paging structures.
> > > 
> > > When the "sub-page write protection" VM-execution control is 1, the SPPT 
> > > is used
> > > to lookup write permission bits for the 128 byte sub-page regions 
> > > containing in
> > > the 4KB guest physical page. EPT specifies the 4KB page level privileges 
> > > that
> > > software is allowed when accessing the guest physical address, whereas 
> > > SPPT
> > > defines the write permissions for software at the 128 byte granularity 
> > > regions
> > > within a 4KB page. Write accesses prevented due to sub-page permissions 
> > > looked
> > > up via SPPT are reported as EPT violation VM exits. Similar to EPT, a 
> > > logical
> > > processor uses SPPT to lookup sub-page region write permissions for
> > > guest-physical addresses only when those addresses are used to access 
> > > memory.
> > 
> > Hi,
> > 
> > I think the right thing to do here would be to first get VM
> > introspection in KVM, as SPP is mostly an introspection feature and it
> > should be controller by the introspector rather than the KVM userspace.
> > 
> > Mihai, if you resubmit, I promise that I will look at it promptly.
Thanks review, Paolo, What do u think we cook some user-cases for qemu or
some kvmtools? even with some other kernel hyper-calls?

SPP is not only an introspection depended features.
> 
> I'm currently traveling until Wednesday, but when I'll get into the
> office I will see about preparing a new patch set and send it to the
> list before Christmas.
Thanks Mihai, please include me in the new VMI patch set. 
> 
> Regards,
> 
> -- 
> Mihai Donțu
> 

[tip:locking/core] tools/memory-model: Model smp_mb__after_unlock_lock()

[tip-bot for Andrea Parri]

Commit-ID:  4607abbcf464ea2be14da444215d05c73025cf6e
Gitweb: https://git.kernel.org/tip/4607abbcf464ea2be14da444215d05c73025cf6e
Author: Andrea Parri 
AuthorDate: Mon, 3 Dec 2018 15:04:49 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 4 Dec 2018 07:29:51 +0100

tools/memory-model: Model smp_mb__after_unlock_lock()

The kernel documents smp_mb__after_unlock_lock() the following way:

  "Place this after a lock-acquisition primitive to guarantee that
   an UNLOCK+LOCK pair acts as a full barrier.  This guarantee applies
   if the UNLOCK and LOCK are executed by the same CPU or if the
   UNLOCK and LOCK operate on the same lock variable."

Formalize in LKMM the above guarantee by defining (new) mb-links according
to the law:

  ([M] ; po ; [UL] ; (co | po) ; [LKW] ;
fencerel(After-unlock-lock) ; [M])

where the component ([UL] ; co ; [LKW]) identifies "UNLOCK+LOCK pairs on
the same lock variable" and the component ([UL] ; po ; [LKW]) identifies
"UNLOCK+LOCK pairs executed by the same CPU".

In particular, the LKMM forbids the following two behaviors (the second
litmus test below is based on:

  Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html

c.f., Section "Tree RCU Grace Period Memory Ordering Building Blocks"):

C after-unlock-lock-same-cpu

(*
 * Result: Never
 *)

{}

P0(spinlock_t *s, spinlock_t *t, int *x, int *y)
{
int r0;

spin_lock(s);
WRITE_ONCE(*x, 1);
spin_unlock(s);
spin_lock(t);
smp_mb__after_unlock_lock();
r0 = READ_ONCE(*y);
spin_unlock(t);
}

P1(int *x, int *y)
{
int r0;

WRITE_ONCE(*y, 1);
smp_mb();
r0 = READ_ONCE(*x);
}

exists (0:r0=0 /\ 1:r0=0)

C after-unlock-lock-same-lock-variable

(*
 * Result: Never
 *)

{}

P0(spinlock_t *s, int *x, int *y)
{
int r0;

spin_lock(s);
WRITE_ONCE(*x, 1);
r0 = READ_ONCE(*y);
spin_unlock(s);
}

P1(spinlock_t *s, int *y, int *z)
{
int r0;

spin_lock(s);
smp_mb__after_unlock_lock();
WRITE_ONCE(*y, 1);
r0 = READ_ONCE(*z);
spin_unlock(s);
}

P2(int *z, int *x)
{
int r0;

WRITE_ONCE(*z, 1);
smp_mb();
r0 = READ_ONCE(*x);
}

exists (0:r0=0 /\ 1:r0=0 /\ 2:r0=0)

Signed-off-by: Andrea Parri 
Signed-off-by: Paul E. McKenney 
Cc: Akira Yokosawa 
Cc: Alan Stern 
Cc: Boqun Feng 
Cc: Daniel Lustig 
Cc: David Howells 
Cc: Jade Alglave 
Cc: Linus Torvalds 
Cc: Luc Maranget 
Cc: Nicholas Piggin 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-a...@vger.kernel.org
Cc: parri.and...@gmail.com
Link: http://lkml.kernel.org/r/20181203230451.28921-1-paul...@linux.ibm.com
Signed-off-by: Ingo Molnar 
---
 tools/memory-model/linux-kernel.bell | 3 ++-
 tools/memory-model/linux-kernel.cat  | 4 +++-
 tools/memory-model/linux-kernel.def  | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/memory-model/linux-kernel.bell 
b/tools/memory-model/linux-kernel.bell
index b84fb2f67109..796513362c05 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -29,7 +29,8 @@ enum Barriers = 'wmb (*smp_wmb*) ||
'sync-rcu (*synchronize_rcu*) ||
'before-atomic (*smp_mb__before_atomic*) ||
'after-atomic (*smp_mb__after_atomic*) ||
-   'after-spinlock (*smp_mb__after_spinlock*)
+   'after-spinlock (*smp_mb__after_spinlock*) ||
+   'after-unlock-lock (*smp_mb__after_unlock_lock*)
 instructions F[Barriers]
 
 (* Compute matching pairs of nested Rcu-lock and Rcu-unlock *)
diff --git a/tools/memory-model/linux-kernel.cat 
b/tools/memory-model/linux-kernel.cat
index 882fc33274ac..8f23c74a96fd 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -30,7 +30,9 @@ let wmb = [W] ; fencerel(Wmb) ; [W]
 let mb = ([M] ; fencerel(Mb) ; [M]) |
([M] ; fencerel(Before-atomic) ; [RMW] ; po? ; [M]) |
([M] ; po? ; [RMW] ; fencerel(After-atomic) ; [M]) |
-   ([M] ; po? ; [LKW] ; fencerel(After-spinlock) ; [M])
+   ([M] ; po? ; [LKW] ; fencerel(After-spinlock) ; [M]) |
+   ([M] ; po ; [UL] ; (co | po) ; [LKW] ;
+   fencerel(After-unlock-lock) ; [M])
 let gp = po ; [Sync-rcu] ; po?
 
 let strong-fence = mb | gp
diff --git a/tools/memory-model/linux-kernel.def 
b/tools/memory-model/linux-kernel.def
index 6fa3eb28d40b..b27911cc087d 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -23,6 +23,7 @@ smp_wmb() { __fence{wmb}; }
 smp_mb__before_atomic() { __fence{before-atomic}; }
 smp_mb__after_atomic() { __fence{after-atomic}; }
 smp_mb__after_spinlock() { __fence{after-spinlock}; }
+smp_mb__after_unlock_lock() { __fence{after-unlock-lock}; }
 
 // Exchange
 xchg(X,V)  __xchg{mb}(X,V)

[tip:locking/core] tools/memory-model: Add scripts to check github litmus tests

[tip-bot for Paul E. McKenney]

Commit-ID:  e188d24a382d609ec7ca6c1a00396202565b7831
Gitweb: https://git.kernel.org/tip/e188d24a382d609ec7ca6c1a00396202565b7831
Author: Paul E. McKenney 
AuthorDate: Mon, 3 Dec 2018 15:04:50 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 4 Dec 2018 07:29:52 +0100

tools/memory-model: Add scripts to check github litmus tests

The https://github.com/paulmckrcu/litmus repository contains a large
number of C-language litmus tests that include "Result:" comments
predicting the verification result.  This commit adds a number of scripts
that run tests on these litmus tests:

checkghlitmus.sh:
Runs all litmus tests in the https://github.com/paulmckrcu/litmus
archive that are C-language and that have "Result:" comment lines
documenting expected results, comparing the actual results to
those expected.  Clones the repository if it has not already
been cloned into the "tools/memory-model/litmus" directory.

initlitmushist.sh
Run all litmus tests having no more than the specified number
of processes given a specified timeout, recording the results in
.litmus.out files.  Clones the repository if it has not already
been cloned into the "tools/memory-model/litmus" directory.

newlitmushist.sh
For all new or updated litmus tests having no more than the
specified number of processes given a specified timeout, run
and record the results in .litmus.out files.

checklitmushist.sh
Run all litmus tests having .litmus.out files from previous
initlitmushist.sh or newlitmushist.sh runs, comparing the
herd output to that of the original runs.

The above scripts will run litmus tests concurrently, by default with
one job per available CPU.  Giving any of these scripts the --help
argument will cause them to print usage information.

This commit also adds a number of helper scripts that are not intended
to be invoked from the command line:

cmplitmushist.sh: Compare the output of two different runs of the same
litmus test.

judgelitmus.sh: Compare the output of a litmus test to its "Result:"
comment line.

parseargs.sh: Parse command-line arguments.

runlitmushist.sh: Run the litmus tests whose pathnames are provided one
per line on standard input.

While in the area, this commit also makes the existing checklitmus.sh
and checkalllitmus.sh scripts use parseargs.sh in order to provide a
bit of uniformity.  In addition, per-litmus-test status output is directed
to stdout, while end-of-test summary information is directed to stderr.
Finally, the error flag standardizes on "!!!" to assist those familiar
with rcutorture output.

The defaults for the parseargs.sh arguments may be overridden by using
environment variables: LKMM_DESTDIR for --destdir, LKMM_HERD_OPTIONS
for --herdoptions, LKMM_JOBS for --jobs, LKMM_PROCS for --procs, and
LKMM_TIMEOUT for --timeout.

[ paulmck: History-check summary-line changes per Alan Stern feedback. ]
Signed-off-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: aki...@gmail.com
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: parri.and...@gmail.com
Cc: st...@rowland.harvard.edu
Cc: will.dea...@arm.com
Link: http://lkml.kernel.org/r/20181203230451.28921-2-paul...@linux.ibm.com
Signed-off-by: Ingo Molnar 
---
 tools/memory-model/.gitignore |   1 +
 tools/memory-model/README |   2 +
 tools/memory-model/scripts/README |  70 ++
 tools/memory-model/scripts/checkalllitmus.sh  |  53 +--
 tools/memory-model/scripts/checkghlitmus.sh   |  65 +
 tools/memory-model/scripts/checklitmus.sh |  74 +++
 tools/memory-model/scripts/checklitmushist.sh |  60 
 tools/memory-model/scripts/cmplitmushist.sh   |  87 ++
 tools/memory-model/scripts/initlitmushist.sh  |  68 ++
 tools/memory-model/scripts/judgelitmus.sh |  78 
 tools/memory-model/scripts/newlitmushist.sh   |  61 +
 tools/memory-model/scripts/parseargs.sh   | 126 ++
 tools/memory-model/scripts/runlitmushist.sh   |  87 ++
 13 files changed, 739 insertions(+), 93 deletions(-)

diff --git a/tools/memory-model/.gitignore b/tools/memory-model/.gitignore
new file mode 100644
index ..b1d34c52f3c3
--- /dev/null
+++ b/tools/memory-model/.gitignore
@@ -0,0 +1 @@
+litmus
diff --git a/tools/memory-model/README b/tools/memory-model/README
index acf9077cffaa..0f2c366518c6 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -156,6 +156,8 @@ lock.cat
 README
This file.
 
+scriptsVarious scripts, see scripts/README.
+
 
 ===
 LIMITATIONS
diff --git a/tools/memory-model/scripts/README 
b/tools/memory-model/scripts/README
new file mod

[PATCH] spi: lpspi: Add cs-gpio support

[Clark Wang]

Add cs-gpio feature for LPSPI. Use fsl_lpspi_prepare_message() and
fsl_lpspi_unprepare_message() to enable and control cs line.
These two functions will be only called at the beginning and the ending
of a message transfer.

Still support using the mode without cs-gpio. It depends on if attribute
cs-gpio has been configured in dts file.

Signed-off-by: Clark Wang 
---
 drivers/spi/spi-fsl-lpspi.c | 79 -
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index a7d01b79827b..c6fe3f94de19 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,7 +17,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +31,10 @@
 
 #define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
 
+#define LPSPI_CS_ACTIVE1
+#define LPSPI_CS_INACTIVE  0
+#define LPSPI_CS_DELAY 100
+
 /* i.MX7ULP LPSPI registers */
 #define IMX7ULP_VERID  0x0
 #define IMX7ULP_PARAM  0x4
@@ -104,6 +111,8 @@ struct fsl_lpspi_data {
struct completion xfer_done;
 
bool slave_aborted;
+
+   int chipselect[0];
 };
 
 static const struct of_device_id fsl_lpspi_dt_ids[] = {
@@ -176,6 +185,48 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
return 0;
 }
 
+static void fsl_lpspi_chipselect(struct spi_device *spi, bool enable)
+{
+   struct fsl_lpspi_data *fsl_lpspi =
+   spi_controller_get_devdata(spi->controller);
+   int gpio = fsl_lpspi->chipselect[spi->chip_select];
+
+   enable = (!!(spi->mode & SPI_CS_HIGH) == enable);
+
+   if (!gpio_is_valid(gpio))
+   return;
+
+   gpio_set_value_cansleep(gpio, enable);
+}
+
+static int fsl_lpspi_prepare_message(struct spi_controller *controller,
+   struct spi_message *msg)
+{
+   struct fsl_lpspi_data *fsl_lpspi =
+   spi_controller_get_devdata(controller);
+   struct spi_device *spi = msg->spi;
+   int gpio = fsl_lpspi->chipselect[spi->chip_select];
+
+   if (gpio_is_valid(gpio)) {
+   gpio_direction_output(gpio,
+   fsl_lpspi->config.mode & SPI_CS_HIGH ? 0 : 1);
+   }
+
+   fsl_lpspi_chipselect(spi, LPSPI_CS_ACTIVE);
+
+   return 0;
+}
+
+static int fsl_lpspi_unprepare_message(struct spi_controller *controller,
+   struct spi_message *msg)
+{
+   struct spi_device *spi = msg->spi;
+
+   fsl_lpspi_chipselect(spi, LPSPI_CS_INACTIVE);
+
+   return 0;
+}
+
 static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data *fsl_lpspi)
 {
u8 txfifo_cnt;
@@ -512,10 +563,13 @@ static int fsl_lpspi_init_rpm(struct fsl_lpspi_data 
*fsl_lpspi)
 
 static int fsl_lpspi_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
struct fsl_lpspi_data *fsl_lpspi;
struct spi_controller *controller;
+   struct spi_imx_master *lpspi_platform_info =
+   dev_get_platdata(&pdev->dev);
struct resource *res;
-   int ret, irq;
+   int i, ret, irq;
u32 temp;
 
if (of_property_read_bool((&pdev->dev)->of_node, "spi-slave"))
@@ -539,6 +593,29 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->is_slave = of_property_read_bool((&pdev->dev)->of_node,
"spi-slave");
 
+   if (!fsl_lpspi->is_slave) {
+   for (i = 0; i < controller->num_chipselect; i++) {
+   int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
+
+   if (!gpio_is_valid(cs_gpio) && lpspi_platform_info)
+   cs_gpio = lpspi_platform_info->chipselect[i];
+
+   fsl_lpspi->chipselect[i] = cs_gpio;
+   if (!gpio_is_valid(cs_gpio))
+   continue;
+
+   ret = devm_gpio_request(&pdev->dev,
+   fsl_lpspi->chipselect[i], DRIVER_NAME);
+   if (ret) {
+   dev_err(&pdev->dev, "can't get cs gpios\n");
+   goto out_controller_put;
+   }
+   }
+
+   controller->prepare_message = fsl_lpspi_prepare_message;
+   controller->unprepare_message = fsl_lpspi_unprepare_message;
+   }
+
controller->transfer_one_message = fsl_lpspi_transfer_one_msg;
controller->prepare_transfer_hardware = lpspi_prepare_xfer_hardware;
controller->unprepare_transfer_hardware = lpspi_unprepare_xfer_hardware;
-- 
2.17.1

[PATCH v19 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Vivek Gautam]

qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements.
On msm8996, multiple cores, viz. mdss, video, etc. use this
smmu. On sdm845, this smmu is used with gpu.
Add bindings for the same.

Signed-off-by: Vivek Gautam 
Reviewed-by: Rob Herring 
Reviewed-by: Tomasz Figa 
Tested-by: Srinivas Kandagatla 
Reviewed-by: Robin Murphy 
---

Changes since v18:
 None.

 drivers/iommu/arm-smmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index b6b11642b3a9..ba18d89d4732 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -120,6 +120,7 @@ enum arm_smmu_implementation {
GENERIC_SMMU,
ARM_MMU500,
CAVIUM_SMMUV2,
+   QCOM_SMMUV2,
 };
 
 struct arm_smmu_s2cr {
@@ -2030,6 +2031,7 @@ ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, 
GENERIC_SMMU);
 ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
 ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
 ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
+ARM_SMMU_MATCH_DATA(qcom_smmuv2, ARM_SMMU_V2, QCOM_SMMUV2);
 
 static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 },
@@ -2038,6 +2040,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,mmu-401", .data = &arm_mmu401 },
{ .compatible = "arm,mmu-500", .data = &arm_mmu500 },
{ .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
+   { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v19 3/5] iommu/arm-smmu: Add the device_link between masters and smmu

[Vivek Gautam]

From: Sricharan R 

Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.

Signed-off-by: Sricharan R 
Signed-off-by: Vivek Gautam 
Reviewed-by: Tomasz Figa 
Tested-by: Srinivas Kandagatla 
Reviewed-by: Robin Murphy 
---

Changes since v18:
 None.

 drivers/iommu/arm-smmu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 1917d214c4d9..b6b11642b3a9 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1500,6 +1500,9 @@ static int arm_smmu_add_device(struct device *dev)
 
iommu_device_link(&smmu->iommu, dev);
 
+   device_link_add(dev, smmu->dev,
+   DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
+
return 0;
 
 out_cfg_free:
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH] spi: lpspi: Fix CLK pin becomes low before one transfer

[Clark Wang]

Remove Reset operation in fsl_lpspi_config(). This RST may cause both CLK
and CS pins go from high to low level under cs-gpio mode.
Add fsl_lpspi_reset() function after one message transfer to clear all
flags in use.

Signed-off-by: Clark Wang 
Reviewed-by: Fugang Duan 
---
 drivers/spi/spi-fsl-lpspi.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index f32a2e0d7ae1..a7d01b79827b 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -279,10 +279,6 @@ static int fsl_lpspi_config(struct fsl_lpspi_data 
*fsl_lpspi)
u32 temp;
int ret;
 
-   temp = CR_RST;
-   writel(temp, fsl_lpspi->base + IMX7ULP_CR);
-   writel(0, fsl_lpspi->base + IMX7ULP_CR);
-
if (!fsl_lpspi->is_slave) {
ret = fsl_lpspi_set_bitrate(fsl_lpspi);
if (ret)
@@ -373,6 +369,24 @@ static int fsl_lpspi_wait_for_completion(struct 
spi_controller *controller)
return 0;
 }
 
+static int fsl_lpspi_reset(struct fsl_lpspi_data *fsl_lpspi)
+{
+   u32 temp;
+
+   /* Disable all interrupt */
+   fsl_lpspi_intctrl(fsl_lpspi, 0);
+
+   /* W1C for all flags in SR */
+   temp = 0x3F << 8;
+   writel(temp, fsl_lpspi->base + IMX7ULP_SR);
+
+   /* Clear FIFO and disable module */
+   temp = CR_RRF | CR_RTF;
+   writel(temp, fsl_lpspi->base + IMX7ULP_CR);
+
+   return 0;
+}
+
 static int fsl_lpspi_transfer_one(struct spi_controller *controller,
  struct spi_device *spi,
  struct spi_transfer *t)
@@ -394,6 +408,8 @@ static int fsl_lpspi_transfer_one(struct spi_controller 
*controller,
if (ret)
return ret;
 
+   fsl_lpspi_reset(fsl_lpspi);
+
return 0;
 }
 
-- 
2.17.1

[PATCH] spi: lpspi: Improve the stability of lpspi data transmission

[Clark Wang]

Use SR_TDF to judge if need to send data, and SR_FCF is to judge if
transmission end and to replace the waiting after transmission end.
This waiting has no actual meaning, for module will set the FCF
flag at the real end.

The changes of interrupt flag and ISR function reduce the times of
calling ISR. The use of the FCF flag improves the stability of the
data transmission. These two points generally improve the data
transfer speed of lpspi, especially when it is set to slave mode
it can support higher transfer speed of the host.

After making these changes, there is no need to use
fsl_lpspi_txfifo_empty(), so remove it.

Signed-off-by: Clark Wang 
---
 drivers/spi/spi-fsl-lpspi.c | 61 -
 1 file changed, 20 insertions(+), 41 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 3e935db5ff02..f32a2e0d7ae1 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -53,9 +53,11 @@
 #define CR_RST BIT(1)
 #define CR_MEN BIT(0)
 #define SR_TCF BIT(10)
+#define SR_FCF BIT(9)
 #define SR_RDF BIT(1)
 #define SR_TDF BIT(0)
 #define IER_TCIE   BIT(10)
+#define IER_FCIE   BIT(9)
 #define IER_RDIE   BIT(1)
 #define IER_TDIE   BIT(0)
 #define CFGR1_PCSCFG   BIT(27)
@@ -174,28 +176,10 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
return 0;
 }
 
-static int fsl_lpspi_txfifo_empty(struct fsl_lpspi_data *fsl_lpspi)
-{
-   u32 txcnt;
-   unsigned long orig_jiffies = jiffies;
-
-   do {
-   txcnt = readl(fsl_lpspi->base + IMX7ULP_FSR) & 0xff;
-
-   if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
-   dev_dbg(fsl_lpspi->dev, "txfifo empty timeout\n");
-   return -ETIMEDOUT;
-   }
-   cond_resched();
-
-   } while (txcnt);
-
-   return 0;
-}
-
 static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data *fsl_lpspi)
 {
u8 txfifo_cnt;
+   u32 temp;
 
txfifo_cnt = readl(fsl_lpspi->base + IMX7ULP_FSR) & 0xff;
 
@@ -206,9 +190,15 @@ static void fsl_lpspi_write_tx_fifo(struct fsl_lpspi_data 
*fsl_lpspi)
txfifo_cnt++;
}
 
-   if (!fsl_lpspi->remain && (txfifo_cnt < fsl_lpspi->txfifosize))
-   writel(0, fsl_lpspi->base + IMX7ULP_TDR);
-   else
+   if (txfifo_cnt < fsl_lpspi->txfifosize) {
+   if (!fsl_lpspi->is_slave) {
+   temp = readl(fsl_lpspi->base + IMX7ULP_TCR);
+   temp &= ~TCR_CONTC;
+   writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
+   }
+
+   fsl_lpspi_intctrl(fsl_lpspi, IER_FCIE);
+   } else
fsl_lpspi_intctrl(fsl_lpspi, IER_TDIE);
 }
 
@@ -404,12 +394,6 @@ static int fsl_lpspi_transfer_one(struct spi_controller 
*controller,
if (ret)
return ret;
 
-   ret = fsl_lpspi_txfifo_empty(fsl_lpspi);
-   if (ret)
-   return ret;
-
-   fsl_lpspi_read_rx_fifo(fsl_lpspi);
-
return 0;
 }
 
@@ -421,7 +405,6 @@ static int fsl_lpspi_transfer_one_msg(struct spi_controller 
*controller,
struct spi_device *spi = msg->spi;
struct spi_transfer *xfer;
bool is_first_xfer = true;
-   u32 temp;
int ret = 0;
 
msg->status = 0;
@@ -441,13 +424,6 @@ static int fsl_lpspi_transfer_one_msg(struct 
spi_controller *controller,
}
 
 complete:
-   if (!fsl_lpspi->is_slave) {
-   /* de-assert SS, then finalize current message */
-   temp = readl(fsl_lpspi->base + IMX7ULP_TCR);
-   temp &= ~TCR_CONTC;
-   writel(temp, fsl_lpspi->base + IMX7ULP_TCR);
-   }
-
msg->status = ret;
spi_finalize_current_message(controller);
 
@@ -456,20 +432,23 @@ static int fsl_lpspi_transfer_one_msg(struct 
spi_controller *controller,
 
 static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
 {
+   u32 temp_SR, temp_IER;
struct fsl_lpspi_data *fsl_lpspi = dev_id;
-   u32 temp;
 
+   temp_IER = readl(fsl_lpspi->base + IMX7ULP_IER);
fsl_lpspi_intctrl(fsl_lpspi, 0);
-   temp = readl(fsl_lpspi->base + IMX7ULP_SR);
+   temp_SR = readl(fsl_lpspi->base + IMX7ULP_SR);
 
fsl_lpspi_read_rx_fifo(fsl_lpspi);
 
-   if (temp & SR_TDF) {
+   if ((temp_SR & SR_TDF) && (temp_IER & IER_TDIE)) {
fsl_lpspi_write_tx_fifo(fsl_lpspi);
+   return IRQ_HANDLED;
+   }
 
-   if (!fsl_lpspi->remain)
+   if (temp_SR & SR_FCF && (temp_IER & IER_FCIE)) {
+   writel(SR_FCF, fsl_lpspi->base + IMX7ULP_SR);
complete(&fsl_lpspi->xfer_done);
-
return IRQ_HANDLED;
}
 
-- 
2.17.1

[PATCH] spi: lpspi: enable runtime pm for lpspi

[Clark Wang]

From: Han Xu 

Enable the runtime power management for lpspi module.

Signed-off-by: Han Xu 
Reviewed-by: Frank Li 
---
 drivers/spi/spi-fsl-lpspi.c | 117 
 1 file changed, 92 insertions(+), 25 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 5802f188051b..3e935db5ff02 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -16,7 +16,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +26,8 @@
 
 #define DRIVER_NAME "fsl_lpspi"
 
+#define FSL_LPSPI_RPM_TIMEOUT 50 /* 50ms */
+
 /* i.MX7ULP LPSPI registers */
 #define IMX7ULP_VERID  0x0
 #define IMX7ULP_PARAM  0x4
@@ -150,13 +154,9 @@ static int lpspi_prepare_xfer_hardware(struct 
spi_controller *controller)
spi_controller_get_devdata(controller);
int ret;
 
-   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
-   if (ret)
-   return ret;
-
-   ret = clk_prepare_enable(fsl_lpspi->clk_per);
-   if (ret) {
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   ret = pm_runtime_get_sync(fsl_lpspi->dev);
+   if (ret < 0) {
+   dev_err(fsl_lpspi->dev, "failed to enable clock\n");
return ret;
}
 
@@ -168,8 +168,8 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
-   clk_disable_unprepare(fsl_lpspi->clk_per);
+   pm_runtime_mark_last_busy(fsl_lpspi->dev);
+   pm_runtime_put_autosuspend(fsl_lpspi->dev);
 
return 0;
 }
@@ -476,6 +476,45 @@ static irqreturn_t fsl_lpspi_isr(int irq, void *dev_id)
return IRQ_NONE;
 }
 
+int fsl_lpspi_runtime_resume(struct device *dev)
+{
+   struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_per);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+   if (ret) {
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   return ret;
+   }
+
+   return 0;
+}
+
+int fsl_lpspi_runtime_suspend(struct device *dev)
+{
+   struct fsl_lpspi_data *fsl_lpspi = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+
+   return 0;
+}
+
+static int fsl_lpspi_init_rpm(struct fsl_lpspi_data *fsl_lpspi)
+{
+   struct device *dev = fsl_lpspi->dev;
+
+   pm_runtime_enable(dev);
+   pm_runtime_set_autosuspend_delay(dev, FSL_LPSPI_RPM_TIMEOUT);
+   pm_runtime_use_autosuspend(dev);
+
+   return 0;
+}
+
 static int fsl_lpspi_probe(struct platform_device *pdev)
 {
struct fsl_lpspi_data *fsl_lpspi;
@@ -501,6 +540,7 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
 
fsl_lpspi = spi_controller_get_devdata(controller);
fsl_lpspi->dev = &pdev->dev;
+   dev_set_drvdata(&pdev->dev, fsl_lpspi);
fsl_lpspi->is_slave = of_property_read_bool((&pdev->dev)->of_node,
"spi-slave");
 
@@ -547,28 +587,21 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
 
-   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "can't enable lpspi ipg clock, ret=%d\n", ret);
+   /* enable the clock */
+   ret = fsl_lpspi_init_rpm(fsl_lpspi);
+   if (ret)
goto out_controller_put;
-   }
 
-   ret = clk_prepare_enable(fsl_lpspi->clk_per);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "can't enable lpspi per clock, ret=%d\n", ret);
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
-   goto out_controller_put;
+   ret = pm_runtime_get_sync(fsl_lpspi->dev);
+   if (ret < 0) {
+   dev_err(fsl_lpspi->dev, "failed to enable clock\n");
+   return ret;
}
 
temp = readl(fsl_lpspi->base + IMX7ULP_PARAM);
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
 
-   clk_disable_unprepare(fsl_lpspi->clk_per);
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
-
ret = devm_spi_register_controller(&pdev->dev, controller);
if (ret < 0) {
dev_err(&pdev->dev, "spi_register_controller error.\n");
@@ -589,16 +622,50 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk_per);
-   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   p

Re: [PATCH v2 3/5] devfreq: add devfreq_suspend/resume() functions

[Chanwoo Choi]

Hi Lukasz,

On 2018년 12월 03일 23:31, Lukasz Luba wrote:
> This patch adds implementation for global suspend/resume for
> devfreq framework. System suspend will next use these functions.
> 
> The patch is based on earlier work by Tobias Jakobi.

Please remove it from each patch description.

> 
> Suggested-by: Tobias Jakobi 
> Suggested-by: Chanwoo Choi 
> Signed-off-by: Lukasz Luba 
> ---
>  drivers/devfreq/devfreq.c | 42 ++
>  include/linux/devfreq.h   |  6 ++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 36bed24..7d60423 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -935,6 +935,48 @@ int devfreq_resume_device(struct devfreq *devfreq)
>  EXPORT_SYMBOL(devfreq_resume_device);
>  
>  /**
> + * devfreq_suspend() - Suspend devfreq governors and devices
> + *
> + * Called during system wide Suspend/Hibernate cycles for suspending 
> governors
> + * and devices preserving the state for resume. On some platforms the devfreq
> + * device must have precise state (frequency) after resume in order to 
> provide
> + * fully operating setup.
> + */
> +void devfreq_suspend(void)
> +{
> + struct devfreq *devfreq;
> + int ret;
> +
> + mutex_lock(&devfreq_list_lock);
> + list_for_each_entry(devfreq, &devfreq_list, node) {
> + ret = devfreq_suspend_device(devfreq);
> + if (ret)
> + dev_warn(&devfreq->dev, "device suspend failed\n");

When I checked the cpufreq_suspend(), cpufreq_suspend() prints message as 'err' 
level.
I think that dev_err is more proper than dev_warn.

I'm not sure what is more correct log.
But, 'devfreq->dev' device has the separate suspend/resume function.
So, I think that devfreq_suspend() should print error log containing
that it is error by devfreq framework.

"device suspend failed"
-> "failed to suspend devfreq device"

> + }
> + mutex_unlock(&devfreq_list_lock);
> +}
> +
> +/**
> + * devfreq_resume() - Resume devfreq governors and devices
> + *
> + * Called during system wide Suspend/Hibernate cycle for resuming governors 
> and
> + * devices that are suspended with devfreq_suspend().
> + */
> +void devfreq_resume(void)
> +{
> + struct devfreq *devfreq;
> + int ret;
> +
> + mutex_lock(&devfreq_list_lock);
> + list_for_each_entry(devfreq, &devfreq_list, node) {
> + ret = devfreq_resume_device(devfreq);
> + if (ret)
> + dev_warn(&devfreq->dev, "device resume failed\n");

ditto.

"device resume failed"
-> "failed to resume devfreq device"


> + }
> + mutex_unlock(&devfreq_list_lock);
> +}
> +
> +/**
>   * devfreq_add_governor() - Add devfreq governor
>   * @governor:the devfreq governor to be added
>   */
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index d985199..fbffa74 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -205,6 +205,9 @@ extern void devm_devfreq_remove_device(struct device *dev,
>  extern int devfreq_suspend_device(struct devfreq *devfreq);
>  extern int devfreq_resume_device(struct devfreq *devfreq);
>  
> +extern void devfreq_suspend(void);
> +extern void devfreq_resume(void);
> +
>  /**
>   * update_devfreq() - Reevaluate the device and configure frequency
>   * @devfreq: the devfreq device
> @@ -331,6 +334,9 @@ static inline int devfreq_resume_device(struct devfreq 
> *devfreq)
>   return 0;
>  }
>  
> +static inline void devfreq_suspend(void) {}
> +static inline void devfreq_resume(void) {}
> +
>  static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
>  unsigned long *freq, u32 flags)
>  {
> 

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops

[Andreas Kemnade]

On Mon, 3 Dec 2018 07:39:10 -0800
Tony Lindgren  wrote:

> * Stephen Boyd  [181130 23:52]:
> > Quoting Tony Lindgren (2018-11-30 07:37:29)  
> > > Hi,
> > > 
> > > * Tero Kristo  [181130 09:21]:  
> > > > On 30/11/2018 09:57, Stephen Boyd wrote:  
> > > > > No that is not preferred. Can the omap2_clk_deny_idle() function be
> > > > > integrated closer into the clk framework in some way that allows it to
> > > > > be part of the clk_ops structure? And then have that take a clk_hw
> > > > > structure instead of a struct clk? I haven't looked at this in any
> > > > > detail whatsoever so I may be way off right now.  
> > > > 
> > > > It could be added under the main clk_ops struct, however this would
> > > > introduce two new func pointers to it which are not used by anything 
> > > > else
> > > > but OMAP. Are you aware of any other platforms requiring similar 
> > > > feature?  
> > > 
> > > From consumer usage point of view, I'm still wondering about
> > > the relationship of clk_deny_idle() and clkdm_deny_idle().
> > > 
> > > It seems that we need to allow reset control drivers call
> > > clk_deny_idle() for the duration of reset. And it seems the
> > > clk_deny_idle() should propagate to also up to the related
> > > clock domain driver to do clkdm_deny_idle().
> > > 
> > > So maybe clk_deny_idle() is could just be something like:
> > > 
> > > dev = clk_get_device(clk);
> > > ...
> > > error = pm_runtime_get(dev);
> > > ...
> > > pm_runtime_put(dev);
> > > ...
> > > 
> > > And that way it would just propagate to the parent clock
> > > domain driver and the clock framework does not need to know
> > > about clockdomains. A clockdomain could be just a genpd
> > > domain.
> > > 
> > > Or do you guys have better ideas?
> > >   
> > 
> > Wouldn't the device link in clk framework patches do this for you if we
> > had the RUNTIME_PM flag passed in. If this is about keeping the clock
> > controller active when a consumer device is using it then I think it may
> > work.  
> 
> The consumer device stays active just fine with PM runtime
> calls. So yes, the problem is keeping a clock controller forced
> active for the period of consumer device reset. Other than
> that typically autoidle can be just kept enabled.
> 
Are we still talking about the same problem? Maybe I am losing track
here. Just to make sure. 
The patch series was about disabling autoidle for devices which cannot
work with it during normal operation. Not during reset or something
like that. 
Or is the keep-clock-active-during-reset just a requirement for bigger
restructuring ideas?

Regards,
Andreas


pgp45FsEyTWw6.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/5] devfreq: add support for suspend/resume of a devfreq device

[Chanwoo Choi]

Hi Lukasz,

I add the comment about 'suspend_count'.

On 2018년 12월 04일 14:43, Chanwoo Choi wrote:
> Hi,
> 
> On 2018년 12월 04일 14:36, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> Looks good to me. But, I add the some comments.
>> If you will fix it, feel free to add my tag:
>> Reviewed-by: Chanwoo choi 
> 
> Sorry. Fix typo 'choi' to 'Choi' as following.
> Reviewed-by: Chanwoo Choi 
> 
>>
>> On 2018년 12월 03일 23:31, Lukasz Luba wrote:
>>> The patch prepares devfreq device for handling suspend/resume
>>> functionality.  The new fields will store needed information during this
>>
>> nitpick. Remove unneeded space. There are two spaces between '.' and 'The 
>> new'. 
>>
>>> process.  Devfreq framework handles opp-suspend DT entry and there is no
>>
>> ditto.
>>
>>> need of modyfications in the drivers code.  It uses atomic variables to
>>
>> ditto.
>>
>>> make sure no race condition affects the process.
>>>
>>> The patch is based on earlier work by Tobias Jakobi.
>>
>> Please remove it from each patch description.
>>
>>>
>>> Suggested-by: Tobias Jakobi 
>>> Suggested-by: Chanwoo Choi 
>>> Signed-off-by: Lukasz Luba 
>>> ---
>>>  drivers/devfreq/devfreq.c | 51 
>>> +++
>>>  include/linux/devfreq.h   |  7 +++
>>>  2 files changed, 50 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index a9fd61b..36bed24 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -316,6 +316,10 @@ static int devfreq_set_target(struct devfreq *devfreq, 
>>> unsigned long new_freq,
>>> "Couldn't update frequency transition information.\n");
>>>  
>>> devfreq->previous_freq = new_freq;
>>> +
>>> +   if (devfreq->suspend_freq)
>>> +   devfreq->resume_freq = cur_freq;
>>> +
>>> return err;
>>>  }
>>>  
>>> @@ -667,6 +671,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>> }
>>> devfreq->max_freq = devfreq->scaling_max_freq;
>>>  
>>> +   devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
>>> +   atomic_set(&devfreq->suspend_count, 0);
>>> +
>>> dev_set_name(&devfreq->dev, "devfreq%d",
>>> atomic_inc_return(&devfreq_no));
>>> err = device_register(&devfreq->dev);
>>> @@ -867,14 +874,28 @@ EXPORT_SYMBOL(devm_devfreq_remove_device);
>>>   */
>>>  int devfreq_suspend_device(struct devfreq *devfreq)
>>>  {
>>> +   int ret;
>>> +
>>> if (!devfreq)
>>> return -EINVAL;
>>>  
>>> -   if (!devfreq->governor)
>>> -   return 0;
>>> +   if (devfreq->governor) {
>>> +   ret = devfreq->governor->event_handler(devfreq,
>>> +   DEVFREQ_GOV_SUSPEND, NULL);
>>> +   if (ret)
>>> +   return ret;
>>> +   }
>>> +
>>> +   if (devfreq->suspend_freq) {
>>> +   if (atomic_inc_return(&devfreq->suspend_count) > 1)
>>> +   return 0;
>>> +
>>> +   ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
>>> +   if (ret)
>>> +   return ret;
>>> +   }

In this patch, if some users call 'devfreq_suspend_device' twice,
'devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_SUSPEND, NULL)'
is called twice but devfreq_set_target() is called only one.
I knew that it is no problem for operation.

But,
I think that you better to use 'suspend_count' as the reference count
of devfreq_suspend/resume_device(). But, if you use 'suspend_count'
in order to check whether this devfreq is suspended or not,
we can reduce the unneeded redundant call when calling it twice.

clock and regulator used the 'reference count' method in order to
remove the redundant call.


>>>  
>>> -   return devfreq->governor->event_handler(devfreq,
>>> -   DEVFREQ_GOV_SUSPEND, NULL);
>>> +   return 0;
>>>  }
>>>  EXPORT_SYMBOL(devfreq_suspend_device);
>>>  
>>> @@ -888,14 +909,28 @@ EXPORT_SYMBOL(devfreq_suspend_device);
>>>   */
>>>  int devfreq_resume_device(struct devfreq *devfreq)
>>>  {
>>> +   int ret;
>>> +
>>> if (!devfreq)
>>> return -EINVAL;
>>>  
>>> -   if (!devfreq->governor)
>>> -   return 0;
>>> +   if (devfreq->resume_freq) {
>>> +   if (atomic_dec_return(&devfreq->suspend_count) >= 1)
>>> +   return 0;

ditto.

>>>  
>>> -   return devfreq->governor->event_handler(devfreq,
>>> -   DEVFREQ_GOV_RESUME, NULL);
>>> +   ret = devfreq_set_target(devfreq, devfreq->resume_freq, 0);
>>> +   if (ret)
>>> +   return ret;
>>> +   }
>>> +
>>> +   if (devfreq->governor) {
>>> +   ret = devfreq->governor->event_handler(devfreq,
>>> +   DEVFREQ_GOV_RESUME, NULL);
>>> +   if (ret)
>>> +   return ret;
>>> +   }
>>> +
>>> +   return 0;
>>>  }
>>>  EXPORT_SYMBOL(devfreq_resume_device);
>>>  
>>> diff --git a/include/linux/devfreq.h b/include/linux/

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

[Juergen Gross]

On 04/12/2018 06:49, H. Peter Anvin wrote:
> On 12/3/18 9:32 PM, Juergen Gross wrote:
>>
>> I'd like to send a followup patch doing that. And I'd like to not only
>> test sentinel for being non-zero, but all padding fields as well. This
>> should be 4.21 material, though.
>>
> 
> No, you can't do that.  That breaks backwards compatibility.

So you are speaking about paddings which are at places where there used
to be some information? Shouldn't those be named "_res*"?
Recycling such paddings with some useful information seems to be rather
dangerous then.

I'd like to have at least some idea which boot loader is not passing a
clean struct boot_params. So I think we should at least have some debug
or info messages telling us which paddings are not zero initially to be
able to either fix the boot loader or switch from _pad* to _res* naming.


Juergen

Re: [PATCH v2] signal: add procfd_signal() syscall

[Aleksa Sarai]

On 2018-12-03, Christian Brauner  wrote:
> > > As I pointed out in another mail my I is to make this work by using
> > > file descriptors for /proc//task/.  I don't want this in the
> > > initial patchset though.  I prefer to slowly add those features once
> > > we have gotten the basic functionality in.
> > 
> > Do you want to land all this in one kernel release?  I wonder how
> > applications are supposed to discover kernel support if functionality is
> > split across several kernel releases.  If you get EINVAL or EBADF, it
> > may not be obvious what is going on.
> 
> Sigh, I get that but I really don't want to have to land this in one big
> chunk. I want this syscall to go in in a as soon as we can to fulfill
> the most basic need: having a way that guarantees us that we signal the
> process that we intended to signal.
> 
> The thread case is easy to implement on top of it. But I suspect we will
> quibble about the exact semantics for a long time. Even now we have been
> on multiple - justified - detrous. That's all pefectly fine and
> expected. But if we have the basic functionality in we have time to do
> all of that. We might even land it in the same kernel release still. I
> really don't want to come of as tea-party-kernel-conservative here but I
> have time-and-time again seen that making something fancy and cover ever
> interesting feature in one patchset takes a very very long time.
> 
> If you care about userspace being able to detect that case I can return
> EOPNOTSUPP when a tid descriptor is passed.

Personally, I'm +1 on -EOPNOTSUPP so we can get an MVP merged, and add
new features in later patches.

> > What happens if you use the new interface with an O_PATH descriptor?
> 
> You get EINVAL. When an O_PATH file descriptor is created the kernel
> will set file->f_op = &empty_fops at which point the check I added 
> if (!proc_is_tgid_procfd(f.file))
> goto err;
> will fail. Imho this is correct behavior since technically signaling a
> struct pid is the equivalent of writing to a file and hence doesn't
> purely operate on the file descriptor level.

Not to mention that O_PATH file descriptors are a whole kettle of fish
when it comes to permission checking semantics.


-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

[Shawn Guo]

Hi Kishon,

On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On 27/11/18 3:37 PM, Shawn Guo wrote:
> > It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> > is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> 
> Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
> (with just changing tuning parameters)? If it could be used by other vendors
> then it would make sense to add this PHY driver in synopsys directory.

My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
@Sriharsha, correct me if I'm wrong.

Shawn

Re: [PATCH] Uprobes: Fix kernel oops with delayed_uprobe_remove()

[Steven Rostedt]

On Mon, 3 Dec 2018 11:52:41 +0530
Ravi Bangoria  wrote:

> Hi Steve,
> 
> Please pull this patch.
> 

Please send a v2 version of the patch with the updated change log. And
should it have a Fixes and be tagged for stable?

-- Steve

> Thanks.
> 
> On 11/15/18 6:13 PM, Oleg Nesterov wrote:
> > On 11/15, Ravi Bangoria wrote:  
> >>
> >> There could be a race between task exit and probe unregister:
> >>
> >>   exit_mm()
> >>   mmput()
> >>   __mmput() uprobe_unregister()
> >>   uprobe_clear_state()  put_uprobe()
> >>   delayed_uprobe_remove()   delayed_uprobe_remove()
> >>
> >> put_uprobe() is calling delayed_uprobe_remove() without taking
> >> delayed_uprobe_lock and thus the race sometimes results in a
> >> kernel crash. Fix this by taking delayed_uprobe_lock before
> >> calling delayed_uprobe_remove() from put_uprobe().
> >>
> >> Detailed crash log can be found at:
> >>   https://lkml.org/lkml/2018/11/1/1244  
> > 
> > Thanks, looks good,
> > 
> > Oleg.
> >   

linux-next: manual merge of the akpm tree with the pm tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  fs/exec.c

between commit:

  67fe1224adc5 ("Revert "exec: make de_thread() freezable"")

from the pm tree and patch:

  "fs/: remove caller signal_pending branch predictions"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/exec.c
index ea7d439cf79e,044e296f2381..
--- a/fs/exec.c
+++ b/fs/exec.c
@@@ -1086,8 -1087,8 +1086,8 @@@ static int de_thread(struct task_struc
while (sig->notify_count) {
__set_current_state(TASK_KILLABLE);
spin_unlock_irq(lock);
 -  freezable_schedule();
 +  schedule();
-   if (unlikely(__fatal_signal_pending(tsk)))
+   if (__fatal_signal_pending(tsk))
goto killed;
spin_lock_irq(lock);
}
@@@ -1114,8 -1115,8 +1114,8 @@@
__set_current_state(TASK_KILLABLE);
write_unlock_irq(&tasklist_lock);
cgroup_threadgroup_change_end(tsk);
 -  freezable_schedule();
 +  schedule();
-   if (unlikely(__fatal_signal_pending(tsk)))
+   if (__fatal_signal_pending(tsk))
goto killed;
}
  


pgpyJkxHzU7jW.pgp
Description: OpenPGP digital signature

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

[H. Peter Anvin]

On 12/3/18 9:32 PM, Juergen Gross wrote:
> 
> I'd like to send a followup patch doing that. And I'd like to not only
> test sentinel for being non-zero, but all padding fields as well. This
> should be 4.21 material, though.
> 

No, you can't do that.  That breaks backwards compatibility.

-hpa

Re: [PATCH 5/5] i2c: mediatek: Add i2c compatible for MediaTek MT8183

[Sean Wang]

 於 2018年12月3日 週一 上午5:34寫道：
>
> From: qii wang 
>
> Add i2c compatible for MT8183. Compare to 2712 i2c controller, MT8183 has
> different registers, offsets, clock, and multi-user function.
>
> Signed-off-by: qii wang 
> ---
>  drivers/i2c/busses/i2c-mt65xx.c |  136 
> +--
>  1 file changed, 130 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 428ac99..6b979ab 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -35,17 +35,23 @@
>  #include 
>
>  #define I2C_RS_TRANSFER(1 << 4)
> +#define I2C_ARB_LOST   (1 << 3)

it seems no one refers to the macro in the patch so it should be
better to be removed

>  #define I2C_HS_NACKERR (1 << 2)
>  #define I2C_ACKERR (1 << 1)
>  #define I2C_TRANSAC_COMP   (1 << 0)
>  #define I2C_TRANSAC_START  (1 << 0)
> +#define I2C_RESUME_ARBIT   (1 << 1)
>  #define I2C_RS_MUL_CNFG(1 << 15)
>  #define I2C_RS_MUL_TRIG(1 << 14)
> +#define I2C_HS_TIME_EN (1 << 7)
>  #define I2C_DCM_DISABLE0x
>  #define I2C_IO_CONFIG_OPEN_DRAIN   0x0003
>  #define I2C_IO_CONFIG_PUSH_PULL0x
>  #define I2C_SOFT_RST   0x0001
>  #define I2C_FIFO_ADDR_CLR  0x0001
> +#define I2C_FIFO_ADDR_CLRH 0x0002
> +#define I2C_FIFO_ADDR_CLR_MCH  0x0004
> +#define I2C_HFIFO_DATA 0x8208
>  #define I2C_DELAY_LEN  0x0002
>  #define I2C_ST_START_CON   0x8001
>  #define I2C_FS_START_CON   0x1800
> @@ -76,6 +82,8 @@
>  #define I2C_CONTROL_DIR_CHANGE  (0x1 << 4)
>  #define I2C_CONTROL_ACKERR_DET_EN   (0x1 << 5)
>  #define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
> +#define I2C_CONTROL_DMAACK_EN   (0x1 << 8)
> +#define I2C_CONTROL_ASYNC_MODE  (0x1 << 9)
>  #define I2C_CONTROL_WRAPPER (0x1 << 0)
>
>  #define I2C_DRV_NAME   "i2c-mt65xx"
> @@ -130,6 +138,15 @@ enum I2C_REGS_OFFSET {
> OFFSET_DEBUGCTRL,
> OFFSET_TRANSFER_LEN_AUX,
> OFFSET_CLOCK_DIV,
> +   /* MT8183 only regs */
> +   OFFSET_LTIMING,
> +   OFFSET_DATA_TIMING,
> +   OFFSET_MCU_INTR,
> +   OFFSET_HW_TIMEOUT,
> +   OFFSET_HFIFO_DATA,
> +   OFFSET_HFIFO_STAT,
> +   OFFSET_MULTI_DMA,
> +   OFFSET_ROLLBACK,
>  };
>
>  static const u16 mt_i2c_regs_v1[] = {
> @@ -159,6 +176,39 @@ enum I2C_REGS_OFFSET {
> [OFFSET_CLOCK_DIV] = 0x70,
>  };
>
> +static const u16 mt_i2c_regs_v2[] = {
> +   [OFFSET_DATA_PORT] = 0x0,
> +   [OFFSET_SLAVE_ADDR] = 0x4,
> +   [OFFSET_INTR_MASK] = 0x8,
> +   [OFFSET_INTR_STAT] = 0xc,
> +   [OFFSET_CONTROL] = 0x10,
> +   [OFFSET_TRANSFER_LEN] = 0x14,
> +   [OFFSET_TRANSAC_LEN] = 0x18,
> +   [OFFSET_DELAY_LEN] = 0x1c,
> +   [OFFSET_TIMING] = 0x20,
> +   [OFFSET_START] = 0x24,
> +   [OFFSET_EXT_CONF] = 0x28,
> +   [OFFSET_LTIMING] = 0x2c,
> +   [OFFSET_HS] = 0x30,
> +   [OFFSET_IO_CONFIG] = 0x34,
> +   [OFFSET_FIFO_ADDR_CLR] = 0x38,
> +   [OFFSET_DATA_TIMING] = 0x3c,
> +   [OFFSET_MCU_INTR] = 0x40,
> +   [OFFSET_TRANSFER_LEN_AUX] = 0x44,
> +   [OFFSET_CLOCK_DIV] = 0x48,
> +   [OFFSET_HW_TIMEOUT] = 0x4c,
> +   [OFFSET_SOFTRESET] = 0x50,
> +   [OFFSET_HFIFO_DATA] = 0x70,
> +   [OFFSET_DEBUGSTAT] = 0xe0,
> +   [OFFSET_DEBUGCTRL] = 0xe8,
> +   [OFFSET_FIFO_STAT] = 0xf4,
> +   [OFFSET_FIFO_THRESH] = 0xf8,
> +   [OFFSET_HFIFO_STAT] = 0xfc,
> +   [OFFSET_DCM_EN] = 0xf88,
> +   [OFFSET_MULTI_DMA] = 0xf8c,
> +   [OFFSET_ROLLBACK] = 0xf98,
> +};
> +
>  struct mtk_i2c_compatible {
> const struct i2c_adapter_quirks *quirks;
> const u16 *regs;
> @@ -168,6 +218,7 @@ struct mtk_i2c_compatible {
> unsigned char aux_len_reg: 1;
> unsigned char support_33bits: 1;
> unsigned char timing_adjust: 1;
> +   unsigned char dma_sync: 1;
>  };
>
>  struct mtk_i2c {
> @@ -181,8 +232,11 @@ struct mtk_i2c {
> struct clk *clk_main;   /* main clock for i2c bus */
> struct clk *clk_dma;/* DMA clock for i2c via DMA */
> struct clk *clk_pmic;   /* PMIC clock for i2c from PMIC */
> +   struct clk *clk_arb;/* Arbitrator clock for i2c */
> bool have_pmic; /* can use i2c pins from PMIC */
> bool use_push_pull; /* IO config push-pull mode */
> +   bool share_i3c; /* share i3c IP*/
> +   u32 ch_offset;  /* i2c multi-user channel offset */
>
> u16 irq_stat;   /* interrupt status */
> unsigned int clk_src_div;
> @@ -190,6 +244,7 @@ struct mtk_i2c {
> enum mtk_trans_o

Re: [PATCH 3/3] arm64: ftrace: add cond_resched() to func ftrace_make_(call|nop)

[Steven Rostedt]

On Mon, 3 Dec 2018 22:51:52 +0100
Arnd Bergmann  wrote:

> On Mon, Dec 3, 2018 at 8:22 PM Will Deacon  wrote:
> >
> > Hi Anders,
> >
> > On Fri, Nov 30, 2018 at 04:09:56PM +0100, Anders Roxell wrote:  
> > > Both of those functions end up calling ftrace_modify_code(), which is
> > > expensive because it changes the page tables and flush caches.
> > > Microseconds add up because this is called in a loop for each dyn_ftrace
> > > record, and this triggers the softlockup watchdog unless we let it sleep
> > > occasionally.
> > > Rework so that we call cond_resched() before going into the
> > > ftrace_modify_code() function.
> > >
> > > Co-developed-by: Arnd Bergmann 
> > > Signed-off-by: Arnd Bergmann 
> > > Signed-off-by: Anders Roxell 
> > > ---
> > >  arch/arm64/kernel/ftrace.c | 10 ++
> > >  1 file changed, 10 insertions(+)  
> >
> > It sounds like you're running into issues with the existing code, but I'd
> > like to understand a bit more about exactly what you're seeing. Which part
> > of the ftrace patching is proving to be expensive?
> >
> > The page table manipulation only happens once per module when using PLTs,
> > and the cache maintenance is just a single line per patch site without an
> > IPI.
> >
> > Is it the loop in ftrace_replace_code() that is causing the hassle?  
> 
> Yes: with an allmodconfig kernel, the ftrace selftest calls 
> ftrace_replace_code
> to look >4 through ftrace_make_call/ftrace_make_nop, and these
> end up calling
> 
> static int __kprobes __aarch64_insn_write(void *addr, __le32 insn)
> {
> void *waddr = addr;
> unsigned long flags = 0;
> int ret;
> 
> raw_spin_lock_irqsave(&patch_lock, flags);
> waddr = patch_map(addr, FIX_TEXT_POKE0);
> 
> ret = probe_kernel_write(waddr, &insn, AARCH64_INSN_SIZE);
> 
> patch_unmap(FIX_TEXT_POKE0);
> raw_spin_unlock_irqrestore(&patch_lock, flags);
> 
> return ret;
> }
> int __kprobes aarch64_insn_patch_text_nosync(void *addr, u32 insn)
> {
> u32 *tp = addr;
> int ret;
> 
> /* A64 instructions must be word aligned */
> if ((uintptr_t)tp & 0x3)
> return -EINVAL;
> 
> ret = aarch64_insn_write(tp, insn);
> if (ret == 0)
> __flush_icache_range((uintptr_t)tp,
>  (uintptr_t)tp + AARCH64_INSN_SIZE);
> 
> return ret;
> }
> 
> which seems to be where the main cost is. This is with inside of
> qemu, and with lots of debugging options (in particular
> kcov and ubsan) enabled, that make each function call
> more expensive.

I was thinking more about this. Would something like this work?

-- Steve

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 8ef9fc226037..42e89397778b 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2393,11 +2393,14 @@ void __weak ftrace_replace_code(int enable)
 {
struct dyn_ftrace *rec;
struct ftrace_page *pg;
+   bool schedulable;
int failed;
 
if (unlikely(ftrace_disabled))
return;
 
+   schedulable = !irqs_disabled() & !preempt_count();
+
do_for_each_ftrace_rec(pg, rec) {
 
if (rec->flags & FTRACE_FL_DISABLED)
@@ -2409,6 +2412,8 @@ void __weak ftrace_replace_code(int enable)
/* Stop processing */
return;
}
+   if (schedulable)
+   cond_resched();
} while_for_each_ftrace_rec();
 }
 

Re: [PATCH v2 2/5] devfreq: add support for suspend/resume of a devfreq device

[Chanwoo Choi]

Hi,

On 2018년 12월 04일 14:36, Chanwoo Choi wrote:
> Hi Lukasz,
> 
> Looks good to me. But, I add the some comments.
> If you will fix it, feel free to add my tag:
> Reviewed-by: Chanwoo choi 

Sorry. Fix typo 'choi' to 'Choi' as following.
Reviewed-by: Chanwoo Choi 

> 
> On 2018년 12월 03일 23:31, Lukasz Luba wrote:
>> The patch prepares devfreq device for handling suspend/resume
>> functionality.  The new fields will store needed information during this
> 
> nitpick. Remove unneeded space. There are two spaces between '.' and 'The 
> new'. 
> 
>> process.  Devfreq framework handles opp-suspend DT entry and there is no
> 
> ditto.
> 
>> need of modyfications in the drivers code.  It uses atomic variables to
> 
> ditto.
> 
>> make sure no race condition affects the process.
>>
>> The patch is based on earlier work by Tobias Jakobi.
> 
> Please remove it from each patch description.
> 
>>
>> Suggested-by: Tobias Jakobi 
>> Suggested-by: Chanwoo Choi 
>> Signed-off-by: Lukasz Luba 
>> ---
>>  drivers/devfreq/devfreq.c | 51 
>> +++
>>  include/linux/devfreq.h   |  7 +++
>>  2 files changed, 50 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index a9fd61b..36bed24 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -316,6 +316,10 @@ static int devfreq_set_target(struct devfreq *devfreq, 
>> unsigned long new_freq,
>>  "Couldn't update frequency transition information.\n");
>>  
>>  devfreq->previous_freq = new_freq;
>> +
>> +if (devfreq->suspend_freq)
>> +devfreq->resume_freq = cur_freq;
>> +
>>  return err;
>>  }
>>  
>> @@ -667,6 +671,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>  }
>>  devfreq->max_freq = devfreq->scaling_max_freq;
>>  
>> +devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
>> +atomic_set(&devfreq->suspend_count, 0);
>> +
>>  dev_set_name(&devfreq->dev, "devfreq%d",
>>  atomic_inc_return(&devfreq_no));
>>  err = device_register(&devfreq->dev);
>> @@ -867,14 +874,28 @@ EXPORT_SYMBOL(devm_devfreq_remove_device);
>>   */
>>  int devfreq_suspend_device(struct devfreq *devfreq)
>>  {
>> +int ret;
>> +
>>  if (!devfreq)
>>  return -EINVAL;
>>  
>> -if (!devfreq->governor)
>> -return 0;
>> +if (devfreq->governor) {
>> +ret = devfreq->governor->event_handler(devfreq,
>> +DEVFREQ_GOV_SUSPEND, NULL);
>> +if (ret)
>> +return ret;
>> +}
>> +
>> +if (devfreq->suspend_freq) {
>> +if (atomic_inc_return(&devfreq->suspend_count) > 1)
>> +return 0;
>> +
>> +ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
>> +if (ret)
>> +return ret;
>> +}
>>  
>> -return devfreq->governor->event_handler(devfreq,
>> -DEVFREQ_GOV_SUSPEND, NULL);
>> +return 0;
>>  }
>>  EXPORT_SYMBOL(devfreq_suspend_device);
>>  
>> @@ -888,14 +909,28 @@ EXPORT_SYMBOL(devfreq_suspend_device);
>>   */
>>  int devfreq_resume_device(struct devfreq *devfreq)
>>  {
>> +int ret;
>> +
>>  if (!devfreq)
>>  return -EINVAL;
>>  
>> -if (!devfreq->governor)
>> -return 0;
>> +if (devfreq->resume_freq) {
>> +if (atomic_dec_return(&devfreq->suspend_count) >= 1)
>> +return 0;
>>  
>> -return devfreq->governor->event_handler(devfreq,
>> -DEVFREQ_GOV_RESUME, NULL);
>> +ret = devfreq_set_target(devfreq, devfreq->resume_freq, 0);
>> +if (ret)
>> +return ret;
>> +}
>> +
>> +if (devfreq->governor) {
>> +ret = devfreq->governor->event_handler(devfreq,
>> +DEVFREQ_GOV_RESUME, NULL);
>> +if (ret)
>> +return ret;
>> +}
>> +
>> +return 0;
>>  }
>>  EXPORT_SYMBOL(devfreq_resume_device);
>>  
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index e4963b0..d985199 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -131,6 +131,9 @@ struct devfreq_dev_profile {
>>   * @scaling_min_freq:   Limit minimum frequency requested by OPP 
>> interface
>>   * @scaling_max_freq:   Limit maximum frequency requested by OPP 
>> interface
>>   * @stop_polling:devfreq polling status of a device.
>> + * @suspend_freq:frequency of a device set during suspend phase.
>> + * @resume_freq: frequency of a device set in resume phase.
>> + * @suspend_count:   suspend requests counter for a device.
>>   * @total_trans:Number of devfreq transitions
>>   * @trans_table:Statistics of devfreq transitions
>>   * @time_in_state:  Statistics of devfreq states
>> @@ -167,6 +170,10 @@ struc

Re: [PATCH v2 1/5] devfreq: refactor set_target frequency function

[Chanwoo Choi]

Hi,

On 2018년 12월 04일 13:39, Chanwoo Choi wrote:
> Hi Lukasz,
> 
> On 2018년 12월 03일 23:31, Lukasz Luba wrote:
>> The refactoring is needed for the new client in devfreq: suspend.
>> To avoid code duplication, move it to the new local function
>> devfreq_set_target.
>>
>> The patch is based on earlier work by Tobias Jakobi.
> 
> As I already commented, Please remove it. You already mentioned it on 
> cover-letter.
> If you want to contain the contribution history of Tobias, you might better
> to add 'Signed-off-by' or others.

If you will fix it, feel free to add my tag:
Reviewed-by: Chanwoo Choi 

> 
>>
>> Suggested-by: Tobias Jakobi 
>> Suggested-by: Chanwoo Choi 
>> Signed-off-by: Lukasz Luba 
>> ---
>>  drivers/devfreq/devfreq.c | 62 
>> +++
>>  1 file changed, 36 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 1414130..a9fd61b 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -285,6 +285,40 @@ static int devfreq_notify_transition(struct devfreq 
>> *devfreq,
>>  return 0;
>>  }
>>  
>> +static int devfreq_set_target(struct devfreq *devfreq, unsigned long 
>> new_freq,
>> +  u32 flags)
>> +{
>> +struct devfreq_freqs freqs;
>> +unsigned long cur_freq;
>> +int err = 0;
>> +
>> +if (devfreq->profile->get_cur_freq)
>> +devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
>> +else
>> +cur_freq = devfreq->previous_freq;
>> +
>> +freqs.old = cur_freq;
>> +freqs.new = new_freq;
>> +devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
>> +
>> +err = devfreq->profile->target(devfreq->dev.parent, &new_freq, flags);
>> +if (err) {
>> +freqs.new = cur_freq;
>> +devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
>> +return err;
>> +}
>> +
>> +freqs.new = new_freq;
>> +devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
>> +
>> +if (devfreq_update_status(devfreq, new_freq))
>> +dev_err(&devfreq->dev,
>> +"Couldn't update frequency transition information.\n");
>> +
>> +devfreq->previous_freq = new_freq;
>> +return err;
>> +}
>> +
>>  /* Load monitoring helper functions for governors use */
>>  
>>  /**
>> @@ -296,8 +330,7 @@ static int devfreq_notify_transition(struct devfreq 
>> *devfreq,
>>   */
>>  int update_devfreq(struct devfreq *devfreq)
>>  {
>> -struct devfreq_freqs freqs;
>> -unsigned long freq, cur_freq, min_freq, max_freq;
>> +unsigned long freq, min_freq, max_freq;
>>  int err = 0;
>>  u32 flags = 0;
>>  
>> @@ -333,31 +366,8 @@ int update_devfreq(struct devfreq *devfreq)
>>  flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
>>  }
>>  
>> -if (devfreq->profile->get_cur_freq)
>> -devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
>> -else
>> -cur_freq = devfreq->previous_freq;
>> -
>> -freqs.old = cur_freq;
>> -freqs.new = freq;
>> -devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
>> +return devfreq_set_target(devfreq, freq, flags);
>>  
>> -err = devfreq->profile->target(devfreq->dev.parent, &freq, flags);
>> -if (err) {
>> -freqs.new = cur_freq;
>> -devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
>> -return err;
>> -}
>> -
>> -freqs.new = freq;
>> -devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
>> -
>> -if (devfreq_update_status(devfreq, freq))
>> -dev_err(&devfreq->dev,
>> -"Couldn't update frequency transition information.\n");
>> -
>> -devfreq->previous_freq = freq;
>> -return err;
>>  }
>>  EXPORT_SYMBOL(update_devfreq);
>>  
>>
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH v3] panic: Avoid the extra noise dmesg

[Feng Tang]

When kernel panic happens, it will first print the panic call stack,
then the ending msg like:

[   35.743249] ---[ end Kernel panic - not syncing: Fatal exception
[   35.749975] [ cut here ]

The above message are very useful for debugging.

But if system is configured to not reboot on panic, say the "panic_timeout"
parameter equals 0, it will likely print out many noisy message like
WARN() call stack for each and every CPU except the panic one, messages
like below:

WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 
set_task_cpu+0x183/0x190
Call Trace:

try_to_wake_up
default_wake_function
autoremove_wake_function
__wake_up_common
__wake_up_common_lock
__wake_up
wake_up_klogd_work_func
irq_work_run_list
irq_work_tick
update_process_times
tick_sched_timer
__hrtimer_run_queues
hrtimer_interrupt
smp_apic_timer_interrupt
apic_timer_interrupt

For people working in console mode, the screen will first show the panic
call stack, but immediately overridded by these noisy extra messages, which
makes debugging much more difficult, as the original context gets lost on
screen.

Also these noisy messages will confuse some users, as I have seen many bug
reporters posted the noisy message into bugzilla, instead of the real panic
call stack and context.

Removing the "local_irq_enable" will avoid the noisy message.

The justification for the removing is: when code runs to this point, it
means user has chosed to not reboot, or do any special handling by using
the panic notifier method, no much point in re-enabling the interrupt.

Signed-off-by: Feng Tang 
Cc: Thomas Gleixner 
Cc: Kees Cook 
Cc: Borislav Petkov 
Cc: sta...@kernel.org
---
 kernel/panic.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index f6d549a..a616e55 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -295,7 +295,6 @@ void panic(const char *fmt, ...)
}
 #endif
pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
-   local_irq_enable();
for (i = 0; ; i += PANIC_TIMER_STEP) {
touch_softlockup_watchdog();
if (i >= i_next) {
-- 
2.7.4

Re: [PATCH v2 2/3] phy: sr-usb: Add stingray usb phy driver

[Kishon Vijay Abraham I]

Hi,

On 03/12/18 2:06 PM, Srinath Mannam wrote:
> This driver supports all versions of stingray SS and HS
> USB phys.
> In version 1 is combo phy contain both SS and HS phys
> in a common IO space.
> In version 2 a single HS phy.
> These phys support both xHCI host driver and
> BDC Broadcom device controller driver.
> 
> Signed-off-by: Srinath Mannam 
> Reviewed-by: Florian Fainelli 
> Reviewed-by: Scott Branden 
> ---
>  drivers/phy/broadcom/Kconfig  |  11 +
>  drivers/phy/broadcom/Makefile |   1 +
>  drivers/phy/broadcom/phy-bcm-sr-usb.c | 373 
> ++
>  3 files changed, 385 insertions(+)
>  create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
> 
> diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
> index 8786a96..c1e4dd5 100644
> --- a/drivers/phy/broadcom/Kconfig
> +++ b/drivers/phy/broadcom/Kconfig
> @@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
> Enable this to support the Broadcom Cygnus PCIe PHY.
> If unsure, say N.
>  
> +config PHY_BCM_SR_USB
> + tristate "Broadcom Stingray USB PHY driver"
> + depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
> + select GENERIC_PHY
> + default ARCH_BCM_IPROC
> + help
> +   Enable this to support the Broadcom Stingray USB PHY
> +   driver. It supports all versions of Superspeed and
> +   Highspeed PHYs.
> +   If unsure, say N.
> +
>  config BCM_KONA_USB2_PHY
>   tristate "Broadcom Kona USB2 PHY Driver"
>   depends on HAS_IOMEM
> diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
> index 0f60184..f453c7d 100644
> --- a/drivers/phy/broadcom/Makefile
> +++ b/drivers/phy/broadcom/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)  += phy-brcm-usb-dvr.o
>  phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
>  
>  obj-$(CONFIG_PHY_BCM_SR_PCIE)+= phy-bcm-sr-pcie.o
> +obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
> diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c 
> b/drivers/phy/broadcom/phy-bcm-sr-usb.c
> new file mode 100644
> index 000..52484b3
> --- /dev/null
> +++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
> @@ -0,0 +1,373 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016-2018 Broadcom
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum bcm_usb_phy_version {
> + BCM_USB_PHY_V1,
> + BCM_USB_PHY_V2,
> +};
> +
> +enum bcm_usb_phy_reg {
> + PLL_NDIV_FRAC,
> + PLL_NDIV_INT,
> + PLL_CTRL,
> + PHY_CTRL,
> + PHY_PLL_CTRL,
> +};
> +
> +/* USB PHY registers */
> +
> +static const u8 bcm_usb_u3phy_v1[] = {
> + [PLL_CTRL]  = 0x18,
> + [PHY_CTRL]  = 0x14,
> +};
> +
> +static const u8 bcm_usb_u2phy_v1[] = {
> + [PLL_NDIV_FRAC] = 0x04,
> + [PLL_NDIV_INT]  = 0x08,
> + [PLL_CTRL]  = 0x0c,
> + [PHY_CTRL]  = 0x10,
> +};
> +
> +#define HSPLL_NDIV_INT_VAL   0x13
> +#define HSPLL_NDIV_FRAC_VAL  0x1005
> +
> +static const u8 bcm_usb_u2phy_v2[] = {
> + [PLL_NDIV_FRAC] = 0x0,
> + [PLL_NDIV_INT]  = 0x4,
> + [PLL_CTRL]  = 0x8,
> + [PHY_CTRL]  = 0xc,
> +};
> +
> +enum pll_ctrl_bits {
> + PLL_RESETB,
> + SSPLL_SUSPEND_EN,
> + PLL_SEQ_START,
> + PLL_LOCK,
> + PLL_PDIV,
> +};
> +
> +static const u8 u3pll_ctrl[] = {
> + [PLL_RESETB]= 0,
> + [SSPLL_SUSPEND_EN]  = 1,
> + [PLL_SEQ_START] = 2,
> + [PLL_LOCK]  = 3,
> +};
> +
> +#define HSPLL_PDIV_MASK  0xF
> +#define HSPLL_PDIV_VAL   0x1
> +
> +static const u8 u2pll_ctrl[] = {
> + [PLL_PDIV]  = 1,
> + [PLL_RESETB]= 5,
> + [PLL_LOCK]  = 6,
> +};
> +
> +enum bcm_usb_phy_ctrl_bits {
> + CORERDY,
> + AFE_LDO_PWRDWNB,
> + AFE_PLL_PWRDWNB,
> + AFE_BG_PWRDWNB,
> + PHY_ISO,
> + PHY_RESETB,
> + PHY_PCTL,
> +};
> +
> +#define PHY_PCTL_MASK0x
> +/*
> + * 0x0806 of PCTL_VAL has below bits set
> + * BIT-8 : refclk divider 1
> + * BIT-3:2: device mode; mode is not effect
> + * BIT-1: soft reset active low
> + */
> +#define HSPHY_PCTL_VAL   0x0806
> +#define SSPHY_PCTL_VAL   0x0006
> +
> +static const u8 u3phy_ctrl[] = {
> + [PHY_RESETB]= 1,
> + [PHY_PCTL]  = 2,
> +};
> +
> +static const u8 u2phy_ctrl[] = {
> + [CORERDY]   = 0,
> + [AFE_LDO_PWRDWNB]   = 1,
> + [AFE_PLL_PWRDWNB]   = 2,
> + [AFE_BG_PWRDWNB]= 3,
> + [PHY_ISO]   = 4,
> + [PHY_RESETB]= 5,
> + [PHY_PCTL]  = 6,
> +};
> +
> +struct bcm_usb_phy_cfg {
> + uint32_t type;
> + uint32_t ver;
> + void __iomem *regs;
> + struct phy *phy;
> + const u8 *offset;
> +};
> +
> +#define PLL_LOCK_RETRY_COUNT 1000
> +
> +enum bcm_usb_phy_type {
> + USB_HS_PHY,
> + USB_SS_PHY,
> +};
> +
> +static inline void bcm_usb_reg32_clrbits(void __iomem *addr, 

Re: [PATCH v2 2/5] devfreq: add support for suspend/resume of a devfreq device

[Chanwoo Choi]

Hi Lukasz,

Looks good to me. But, I add the some comments.
If you will fix it, feel free to add my tag:
Reviewed-by: Chanwoo choi 

On 2018년 12월 03일 23:31, Lukasz Luba wrote:
> The patch prepares devfreq device for handling suspend/resume
> functionality.  The new fields will store needed information during this

nitpick. Remove unneeded space. There are two spaces between '.' and 'The new'. 

> process.  Devfreq framework handles opp-suspend DT entry and there is no

ditto.

> need of modyfications in the drivers code.  It uses atomic variables to

ditto.

> make sure no race condition affects the process.
> 
> The patch is based on earlier work by Tobias Jakobi.

Please remove it from each patch description.

> 
> Suggested-by: Tobias Jakobi 
> Suggested-by: Chanwoo Choi 
> Signed-off-by: Lukasz Luba 
> ---
>  drivers/devfreq/devfreq.c | 51 
> +++
>  include/linux/devfreq.h   |  7 +++
>  2 files changed, 50 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index a9fd61b..36bed24 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -316,6 +316,10 @@ static int devfreq_set_target(struct devfreq *devfreq, 
> unsigned long new_freq,
>   "Couldn't update frequency transition information.\n");
>  
>   devfreq->previous_freq = new_freq;
> +
> + if (devfreq->suspend_freq)
> + devfreq->resume_freq = cur_freq;
> +
>   return err;
>  }
>  
> @@ -667,6 +671,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   }
>   devfreq->max_freq = devfreq->scaling_max_freq;
>  
> + devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
> + atomic_set(&devfreq->suspend_count, 0);
> +
>   dev_set_name(&devfreq->dev, "devfreq%d",
>   atomic_inc_return(&devfreq_no));
>   err = device_register(&devfreq->dev);
> @@ -867,14 +874,28 @@ EXPORT_SYMBOL(devm_devfreq_remove_device);
>   */
>  int devfreq_suspend_device(struct devfreq *devfreq)
>  {
> + int ret;
> +
>   if (!devfreq)
>   return -EINVAL;
>  
> - if (!devfreq->governor)
> - return 0;
> + if (devfreq->governor) {
> + ret = devfreq->governor->event_handler(devfreq,
> + DEVFREQ_GOV_SUSPEND, NULL);
> + if (ret)
> + return ret;
> + }
> +
> + if (devfreq->suspend_freq) {
> + if (atomic_inc_return(&devfreq->suspend_count) > 1)
> + return 0;
> +
> + ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
> + if (ret)
> + return ret;
> + }
>  
> - return devfreq->governor->event_handler(devfreq,
> - DEVFREQ_GOV_SUSPEND, NULL);
> + return 0;
>  }
>  EXPORT_SYMBOL(devfreq_suspend_device);
>  
> @@ -888,14 +909,28 @@ EXPORT_SYMBOL(devfreq_suspend_device);
>   */
>  int devfreq_resume_device(struct devfreq *devfreq)
>  {
> + int ret;
> +
>   if (!devfreq)
>   return -EINVAL;
>  
> - if (!devfreq->governor)
> - return 0;
> + if (devfreq->resume_freq) {
> + if (atomic_dec_return(&devfreq->suspend_count) >= 1)
> + return 0;
>  
> - return devfreq->governor->event_handler(devfreq,
> - DEVFREQ_GOV_RESUME, NULL);
> + ret = devfreq_set_target(devfreq, devfreq->resume_freq, 0);
> + if (ret)
> + return ret;
> + }
> +
> + if (devfreq->governor) {
> + ret = devfreq->governor->event_handler(devfreq,
> + DEVFREQ_GOV_RESUME, NULL);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
>  }
>  EXPORT_SYMBOL(devfreq_resume_device);
>  
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index e4963b0..d985199 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -131,6 +131,9 @@ struct devfreq_dev_profile {
>   * @scaling_min_freq:Limit minimum frequency requested by OPP 
> interface
>   * @scaling_max_freq:Limit maximum frequency requested by OPP 
> interface
>   * @stop_polling: devfreq polling status of a device.
> + * @suspend_freq: frequency of a device set during suspend phase.
> + * @resume_freq:  frequency of a device set in resume phase.
> + * @suspend_count:suspend requests counter for a device.
>   * @total_trans: Number of devfreq transitions
>   * @trans_table: Statistics of devfreq transitions
>   * @time_in_state:   Statistics of devfreq states
> @@ -167,6 +170,10 @@ struct devfreq {
>   unsigned long scaling_max_freq;
>   bool stop_polling;
>  
> + unsigned long suspend_freq;
> + unsigned long resume_freq;
> + atomic_t suspend_count;
> +
>   /* information for device fr

[PATCH] spi: lpspi: Add i.MX8 boards support for lpspi

[Clark Wang]

Add both ipg and per clock for lpspi to support i.MX8QM/QXP boards.

Signed-off-by: Clark Wang 
---
 drivers/spi/spi-fsl-lpspi.c | 52 +
 1 file changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index 08dcc3c22e88..5802f188051b 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -80,7 +80,8 @@ struct lpspi_config {
 struct fsl_lpspi_data {
struct device *dev;
void __iomem *base;
-   struct clk *clk;
+   struct clk *clk_ipg;
+   struct clk *clk_per;
bool is_slave;
 
void *rx_buf;
@@ -147,8 +148,19 @@ static int lpspi_prepare_xfer_hardware(struct 
spi_controller *controller)
 {
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
+   int ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_per);
+   if (ret) {
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   return ret;
+   }
 
-   return clk_prepare_enable(fsl_lpspi->clk);
+   return 0;
 }
 
 static int lpspi_unprepare_xfer_hardware(struct spi_controller *controller)
@@ -156,7 +168,8 @@ static int lpspi_unprepare_xfer_hardware(struct 
spi_controller *controller)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
+   clk_disable_unprepare(fsl_lpspi->clk_per);
 
return 0;
 }
@@ -249,7 +262,7 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data 
*fsl_lpspi)
unsigned int perclk_rate, scldiv;
u8 prescale;
 
-   perclk_rate = clk_get_rate(fsl_lpspi->clk);
+   perclk_rate = clk_get_rate(fsl_lpspi->clk_per);
for (prescale = 0; prescale < 8; prescale++) {
scldiv = perclk_rate /
 (clkdivs[prescale] * config.speed_hz) - 2;
@@ -522,15 +535,30 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
goto out_controller_put;
}
 
-   fsl_lpspi->clk = devm_clk_get(&pdev->dev, "ipg");
-   if (IS_ERR(fsl_lpspi->clk)) {
-   ret = PTR_ERR(fsl_lpspi->clk);
+   fsl_lpspi->clk_per = devm_clk_get(&pdev->dev, "per");
+   if (IS_ERR(fsl_lpspi->clk_per)) {
+   ret = PTR_ERR(fsl_lpspi->clk_per);
+   goto out_controller_put;
+   }
+
+   fsl_lpspi->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+   if (IS_ERR(fsl_lpspi->clk_ipg)) {
+   ret = PTR_ERR(fsl_lpspi->clk_ipg);
+   goto out_controller_put;
+   }
+
+   ret = clk_prepare_enable(fsl_lpspi->clk_ipg);
+   if (ret) {
+   dev_err(&pdev->dev,
+   "can't enable lpspi ipg clock, ret=%d\n", ret);
goto out_controller_put;
}
 
-   ret = clk_prepare_enable(fsl_lpspi->clk);
+   ret = clk_prepare_enable(fsl_lpspi->clk_per);
if (ret) {
-   dev_err(&pdev->dev, "can't enable lpspi clock, ret=%d\n", ret);
+   dev_err(&pdev->dev,
+   "can't enable lpspi per clock, ret=%d\n", ret);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
goto out_controller_put;
}
 
@@ -538,7 +566,8 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
fsl_lpspi->txfifosize = 1 << (temp & 0x0f);
fsl_lpspi->rxfifosize = 1 << ((temp >> 8) & 0x0f);
 
-   clk_disable_unprepare(fsl_lpspi->clk);
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
 
ret = devm_spi_register_controller(&pdev->dev, controller);
if (ret < 0) {
@@ -560,7 +589,8 @@ static int fsl_lpspi_remove(struct platform_device *pdev)
struct fsl_lpspi_data *fsl_lpspi =
spi_controller_get_devdata(controller);
 
-   clk_disable_unprepare(fsl_lpspi->clk);
+   clk_disable_unprepare(fsl_lpspi->clk_per);
+   clk_disable_unprepare(fsl_lpspi->clk_ipg);
 
return 0;
 }
-- 
2.17.1

Re: [PATCH] x86/boot: clear rsdp address in boot_params for broken loaders

[Juergen Gross]

On 04/12/2018 00:07, h...@zytor.com wrote:
> On December 3, 2018 2:38:11 AM PST, Juergen Gross  wrote:
>> In case a broken boot loader doesn't clear its struct boot_params clear
>> rsdp_addr in sanitize_boot_params().
>>
>> This fixes commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP
>> address from boot params if available") e.g. for the case of a boot via
>> systemd-boot.
>>
>> Fixes: e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot
>> params if available")
>> Reported-by: Gunnar Krueger 
>> Tested-by: Gunnar Krueger 
>> Signed-off-by: Juergen Gross 
>> ---
>> arch/x86/include/asm/bootparam_utils.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/x86/include/asm/bootparam_utils.h
>> b/arch/x86/include/asm/bootparam_utils.h
>> index a07ffd23e4dd..f6f6ef436599 100644
>> --- a/arch/x86/include/asm/bootparam_utils.h
>> +++ b/arch/x86/include/asm/bootparam_utils.h
>> @@ -36,6 +36,7 @@ static void sanitize_boot_params(struct boot_params
>> *boot_params)
>>   */
>>  if (boot_params->sentinel) {
>>  /* fields in boot_params are left uninitialized, clear them */
>> +boot_params->acpi_rsdp_addr = 0;
>>  memset(&boot_params->ext_ramdisk_image, 0,
>> (char *)&boot_params->efi_info -
>>  (char *)&boot_params->ext_ramdisk_image);
> 
> Isn't this already covered by the memset()? If not, we should extend the 
> memset() to maximal coverage.

I'd like to send a followup patch doing that. And I'd like to not only
test sentinel for being non-zero, but all padding fields as well. This
should be 4.21 material, though.


Juergen

Re: [PATCH v5 8/8] soc: qcom: rpmhpd: Mark mx as a parent for cx

[Viresh Kumar]

On 04-12-18, 10:51, Rajendra Nayak wrote:
> Specify the active + sleep and active-only MX power domains as
> the parents of the corresponding CX power domains. This will ensure that
> performance state requests on CX automatically generate equivalent requests
> on MX power domains.
> 
> This is used to enforce a requirement that exists for various
> hardware blocks on SDM845 that MX performance state >= CX performance
> state for a given operating frequency.
> 
> Signed-off-by: Rajendra Nayak 
> ---
> This patch is dependent on the series from
> Viresh [1] which adds support to propogate performance states across the
> power domain hierarchy which is still being reviewed.
> 
> [1] https://lkml.org/lkml/2018/11/26/333
> 
>  drivers/soc/qcom/rpmhpd.c | 11 +++
>  1 file changed, 11 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v5 7/8] arm64: dts: sdm845: Add rpmh powercontroller node

[Viresh Kumar]

On 04-12-18, 10:51, Rajendra Nayak wrote:
> Add the DT node for the rpmhpd powercontroller.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 
>  1 file changed, 51 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH v5 1/8] dt-bindings: opp: Introduce qcom-opp bindings

[Rajendra Nayak]

On Qualcomm Technologies, Inc. platforms, an OPP node needs
to describe an additional level/corner value that is then communicated
to a remote microprocessor by the CPU, which then takes some
actions (like adjusting voltage values across various rails)
based on the value passed.

Describe these bindings in the qcom-opp bindings document.

Signed-off-by: Rajendra Nayak 
Acked-by: Viresh Kumar 
---
 .../devicetree/bindings/opp/qcom-opp.txt  | 25 +++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt

diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt 
b/Documentation/devicetree/bindings/opp/qcom-opp.txt
new file mode 100644
index ..db4d970c7ec7
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt
@@ -0,0 +1,25 @@
+Qualcomm OPP bindings to descibe OPP nodes with corner/level values
+
+OPP tables for devices on Qualcomm platforms require an additional
+platform specific corner/level value to be specified.
+This value is passed on to the RPM (Resource Power Manager) by
+the CPU, which then takes the necessary actions to set a voltage
+rail to an appropriate voltage based on the value passed.
+
+The bindings are based on top of the operating-points-v2 bindings
+described in Documentation/devicetree/bindings/opp/opp.txt
+Additional properties are described below.
+
+* OPP Table Node
+
+Required properties:
+- compatible: Allow OPPs to express their compatibility. It should be:
+  "operating-points-v2-qcom-level"
+
+* OPP Node
+
+Required properties:
+- qcom,level: On Qualcomm platforms an OPP node can describe a positive value
+representing a corner/level that's communicated with a remote microprocessor
+(usually called the RPM) which then translates it into a certain voltage on
+a voltage rail.
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] jbd2: clean up indentation issue, replace spaces with tab

[Theodore Y. Ts'o]

On Mon, Nov 26, 2018 at 02:56:32PM +0100, Jan Kara wrote:
> On Fri 23-11-18 16:40:53, Colin King wrote:
> > From: Colin Ian King 
> > 
> > There is a statement that is indented with spaces, replace it with
> > a tab.
> > 
> > Signed-off-by: Colin Ian King 
> 
> Looks good. You can add:
> 
> Reviewed-by: Jan Kara 

Thanks, applied.

- Ted

[PATCH v5 2/8] dt-bindings: power: Add qcom rpm power domain driver bindings

[Rajendra Nayak]

Add DT bindings to describe the rpm/rpmh power domains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPM/RPMh, which then translates it into corresponding voltage on a
PMIC rail.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson 
---
 .../devicetree/bindings/power/qcom,rpmpd.txt  | 146 ++
 include/dt-bindings/power/qcom-rpmpd.h|  39 +
 2 files changed, 185 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
 create mode 100644 include/dt-bindings/power/qcom-rpmpd.h

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt 
b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
new file mode 100644
index ..aa02f8573dd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -0,0 +1,146 @@
+Qualcomm RPM/RPMh Power domains
+
+For RPM/RPMh Power domains, we communicate a performance state to RPM/RPMh
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+   * qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+   * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
+ - power-domain-cells: number of cells in Power domain specifier
+   must be 1.
+ - operating-points-v2: Phandle to the OPP table for the Power domain.
+   Refer to Documentation/devicetree/bindings/power/power_domain.txt
+   and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Refer to  for the level values for
+various OPPs for different platforms as well as Power domain indexes
+
+Example: rpmh power domain controller and OPP table
+
+#include 
+
+qcom,level values specified in the OPP tables for RPMh power domains
+should use the RPMH_REGULATOR_LEVEL_* constants from
+
+
+   rpmhpd: power-controller {
+   compatible = "qcom,sdm845-rpmhpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmhpd_opp_table>;
+   };
+
+   rpmhpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmhpd_opp_ret: opp1 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_min_svs: opp2 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_low_svs: opp3 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_svs: opp4 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_svs_l1: opp5 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_nom: opp6 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_nom_l1: opp7 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_nom_l2: opp8 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_turbo: opp9 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_turbo_l1: opp10 {
+   qcom,level = ;
+   };
+   };
+
+Example: rpm power domain controller and OPP table
+
+   rpmpd: power-controller {
+   compatible = "qcom,msm8996-rpmpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmpd_opp_table>;
+   };
+
+   rpmpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmpd_opp_low: opp1 {
+   qcom,level = <1>;
+   };
+
+   rpmpd_opp_ret: opp2 {
+   qcom,level = <2>;
+   };
+
+   rpmpd_opp_svs: opp3 {
+   qcom,level = <3>;
+   };
+
+   rpmpd_opp_normal: opp4 {
+   qcom,level = <4>;
+   };
+
+   rpmpd_opp_high: opp5 {
+   qcom,level = <5>;
+   };
+
+   rpmpd_opp_turbo: opp6 {
+   qcom,level = <6>;
+   };
+   };
+
+Example: Client/Consumer device using OPP table
+
+   leaky-device0@1235 {
+   compatible = "foo,i-leak-current";
+   reg = <0x1235 0x1000>;
+   power-domains = <&rpmhpd SDM845_MX>;
+   operating-points-v2 = <&leaky_opp_table>;
+   };
+
+
+   leaky_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp1 {
+   opp-hz = /bits/ 64 <144000>;
+   required-opps = <&rpmhpd_opp_low>;
+   };
+
+   opp2 {
+   opp-hz = /bits/ 64 <40>;
+   required-opps = <&rpmhpd_opp_ret>;
+   };
+
+   opp3 {
+   opp-hz = /bits/ 64 <20

[PATCH v5 8/8] soc: qcom: rpmhpd: Mark mx as a parent for cx

[Rajendra Nayak]

Specify the active + sleep and active-only MX power domains as
the parents of the corresponding CX power domains. This will ensure that
performance state requests on CX automatically generate equivalent requests
on MX power domains.

This is used to enforce a requirement that exists for various
hardware blocks on SDM845 that MX performance state >= CX performance
state for a given operating frequency.

Signed-off-by: Rajendra Nayak 
---
This patch is dependent on the series from
Viresh [1] which adds support to propogate performance states across the
power domain hierarchy which is still being reviewed.

[1] https://lkml.org/lkml/2018/11/26/333

 drivers/soc/qcom/rpmhpd.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index 10b45b4f4588..6624c9c56b2e 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -104,12 +104,14 @@ static struct rpmhpd sdm845_cx_ao;
 static struct rpmhpd sdm845_cx = {
.pd = { .name = "cx", },
.peer = &sdm845_cx_ao,
+   .parent = &sdm845_mx.pd,
.res_name = "cx.lvl",
 };
 
 static struct rpmhpd sdm845_cx_ao = {
.pd = { .name = "cx_ao", },
.peer = &sdm845_cx,
+   .parent = &sdm845_mx_ao.pd,
.res_name = "cx.lvl",
 };
 
@@ -403,6 +405,15 @@ static int rpmhpd_probe(struct platform_device *pdev)
data->domains[i] = &rpmhpds[i]->pd;
}
 
+   /* Add subdomains */
+   for (i = 0; i < num_pds; i++) {
+   if (!rpmhpds[i])
+   continue;
+   if (rpmhpds[i]->parent)
+   pm_genpd_add_subdomain(rpmhpds[i]->parent,
+  &rpmhpds[i]->pd);
+   }
+
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
 }
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v5 6/8] soc: qcom: rpmhpd: Add RPMh Power domain driver

[Rajendra Nayak]

The RPMh Power domain driver aggregates the corner votes from various
consumers for the ARC resources and communicates it to RPMh.

With RPMh we use 2 different numbering space for corners, one used
by the clients to express their performance needs, and another used
to communicate to RPMh hardware.

The clients express their performance requirements using a sparse
numbering space which are mapped to meaningful levels like RET, SVS,
NOMINAL, TURBO etc which then get mapped to another number space
between 0 and 15 which is communicated to RPMh. The sparse number space,
also referred to as vlvl is mapped to the continuous number space of 0
to 15, also referred to as hlvl, using command DB.

Some power domain clients could request a performance state only while
the CPU is active, while some others could request for a certain
performance state all the time regardless of the state of the CPU.
We handle this by internally aggregating the votes from both type of
clients and then send the aggregated votes to RPMh.

There are also 3 different types of Votes that are comunicated to RPMh
for every resource.
1. ACTIVE_ONLY: This specifies the requirement for the resource when the
CPU is active
2. SLEEP: This specifies the requirement for the resource when the CPU
is going to sleep
3. WAKE_ONLY: This specifies the requirement for the resource when the
CPU is coming out of sleep to active state

We add data for all power domains on sdm845 SoC as part of the patch.
The driver can be extended to support other SoCs which support RPMh

Signed-off-by: Rajendra Nayak 
Reviewed-by: Ulf Hansson 
---
 drivers/soc/qcom/Kconfig  |   9 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/rpmhpd.c | 431 ++
 3 files changed, 441 insertions(+)
 create mode 100644 drivers/soc/qcom/rpmhpd.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index e9b60695f6e7..a51458022d21 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -103,6 +103,15 @@ config QCOM_RPMH
  of hardware components aggregate requests for these resources and
  help apply the aggregated state on the resource.
 
+config QCOM_RPMHPD
+   bool "Qualcomm RPMh Power domain driver"
+   depends on QCOM_RPMH && QCOM_COMMAND_DB
+   help
+ QCOM RPMh Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPMh which then translates it into corresponding voltage
+ for the voltage rail.
+
 config QCOM_RPMPD
bool "Qualcomm RPM Power domain driver"
depends on MFD_QCOM_RPM && QCOM_SMD_RPM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f1b25fdcf2ad..dd6ca92985ee 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_QCOM_APR) += apr.o
 obj-$(CONFIG_QCOM_LLCC) += llcc-slice.o
 obj-$(CONFIG_QCOM_SDM845_LLCC) += llcc-sdm845.o
 obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
+obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
new file mode 100644
index ..10b45b4f4588
--- /dev/null
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
+
+/*
+ * This is the number of bytes used for each command DB aux data entry of an
+ * ARC resource.
+ */
+#define RPMH_ARC_LEVEL_SIZE2
+#define RPMH_ARC_MAX_LEVELS16
+
+/**
+ * struct rpmhpd - top level RPMh power domain resource data structure
+ * @dev:   rpmh power domain controller device
+ * @pd:generic_pm_domain corrresponding to the power domain
+ * @peer:  A peer power domain in case Active only Voting is 
supported
+ * @active_only:   True if it represents an Active only peer
+ * @level: An array of level (vlvl) to corner (hlvl) mappings 
derived from cmd-db
+ * @level_count:   Number of levels supported by the power domain. max 
being 16 (0 - 15)
+ * @enabled:   true if the power domain is enabled
+ * @res_name:  Resource name used for cmd-db lookup
+ * @addr:  Resource address as looped up using resource name from 
cmd-db
+ */
+struct rpmhpd {
+   struct device   *dev;
+   struct generic_pm_domain pd;
+   struct generic_pm_domain *parent;
+   struct rpmhpd   *peer;
+   const bool  active_only;
+   unsigned intcorner;
+   unsigned intactive_corner;
+   u32 level[RPMH_ARC_MAX_LEVELS];
+   int level_count;
+   boolenabled;
+   const char  *res_name;
+   u32 addr;
+};
+
+st

[PATCH v5 3/8] soc: qcom: rpmpd: Add a Power domain driver to model corners

[Rajendra Nayak]

The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.

We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson 
Acked-by: Rob Herring 
---
 drivers/soc/qcom/Kconfig  |   9 ++
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/rpmpd.c  | 294 ++
 3 files changed, 304 insertions(+)
 create mode 100644 drivers/soc/qcom/rpmpd.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 684cb51694d1..e9b60695f6e7 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -103,6 +103,15 @@ config QCOM_RPMH
  of hardware components aggregate requests for these resources and
  help apply the aggregated state on the resource.
 
+config QCOM_RPMPD
+   bool "Qualcomm RPM Power domain driver"
+   depends on MFD_QCOM_RPM && QCOM_SMD_RPM
+   help
+ QCOM RPM Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPM which then translates it into corresponding voltage
+ for the voltage rail.
+
 config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f25b54cd6cf8..f1b25fdcf2ad 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
 obj-$(CONFIG_QCOM_APR) += apr.o
 obj-$(CONFIG_QCOM_LLCC) += llcc-slice.o
 obj-$(CONFIG_QCOM_SDM845_LLCC) += llcc-sdm845.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..a0b9f122d793
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER   0x636676   /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+   static struct rpmpd _platform##_##_active;  \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .peer = &_platform##_##_active, \
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   };  \
+   static struct rpmpd _platform##_##_active = {   \
+   .pd = { .name = #_active, },\
+   .peer = &_platform##_##_name,   \
+   .active_only = true,\
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = RPMPD_LDOA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)   \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = r_type, \
+   .res_id = r_id, \
+   .key = KEY_FLOOR_CORNER,\
+   }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)  \
+   DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+
+

[PATCH v5 4/8] soc: qcom: rpmpd: Add support for get/set performance state

[Rajendra Nayak]

Add support for the .set_performace_state() and .opp_to_performance_state()
callbacks in the rpmpd driver.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson 
---
 drivers/soc/qcom/rpmpd.c | 46 
 1 file changed, 46 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index a0b9f122d793..eb1cfa6a03d6 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -28,6 +29,8 @@
 #define KEY_ENABLE 0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER   0x636676   /* vfc */
 
+#define MAX_RPMPD_STATE6
+
 #define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
static struct rpmpd _platform##_##_active;  \
static struct rpmpd _platform##_##_name = { \
@@ -221,6 +224,47 @@ static int rpmpd_power_off(struct generic_pm_domain 
*domain)
return ret;
 }
 
+static int rpmpd_set_performance(struct generic_pm_domain *domain,
+unsigned int state)
+{
+   int ret = 0;
+   struct rpmpd *pd = domain_to_rpmpd(domain);
+
+   mutex_lock(&rpmpd_lock);
+
+   if (state > MAX_RPMPD_STATE)
+   goto out;
+
+   pd->corner = state;
+
+   if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))
+   goto out;
+
+   ret = rpmpd_aggregate_corner(pd);
+
+out:
+   mutex_unlock(&rpmpd_lock);
+
+   return ret;
+}
+
+static unsigned int rpmpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+   struct device_node *np;
+   unsigned int corner = 0;
+
+   np = dev_pm_opp_get_of_node(opp);
+   if (of_property_read_u32(np, "qcom,level", &corner)) {
+   pr_err("%s: missing 'qcom,level' property\n", __func__);
+   return 0;
+   }
+
+   of_node_put(np);
+
+   return corner;
+}
+
 static int rpmpd_probe(struct platform_device *pdev)
 {
int i;
@@ -261,6 +305,8 @@ static int rpmpd_probe(struct platform_device *pdev)
rpmpds[i]->rpm = rpm;
rpmpds[i]->pd.power_off = rpmpd_power_off;
rpmpds[i]->pd.power_on = rpmpd_power_on;
+   rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
+   rpmpds[i]->pd.opp_to_performance_state = rpmpd_get_performance;
pm_genpd_init(&rpmpds[i]->pd, NULL, true);
 
data->domains[i] = &rpmpds[i]->pd;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v5 7/8] arm64: dts: sdm845: Add rpmh powercontroller node

[Rajendra Nayak]

Add the DT node for the rpmhpd powercontroller.

Signed-off-by: Rajendra Nayak 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 51 
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b72bdb0a31a5..a6d0cd8d17b0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1324,6 +1325,56 @@
compatible = "qcom,sdm845-rpmh-clk";
#clock-cells = <1>;
};
+
+   rpmhpd: power-controller {
+   compatible = "qcom,sdm845-rpmhpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmhpd_opp_table>;
+   };
+
+   rpmhpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmhpd_opp_ret: opp1 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_min_svs: opp2 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_low_svs: opp3 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_svs: opp4 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_svs_l1: opp5 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_nom: opp6 {
+   qcom,level = ;
+   };
+
+   rpmhpd_opp_nom_l1: opp7 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_nom_l2: opp8 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_turbo: opp9 {
+   qcom,level = 
;
+   };
+
+   rpmhpd_opp_turbo_l1: opp10 {
+   qcom,level = 
;
+   };
+   };
};
 
intc: interrupt-controller@17a0 {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v5 5/8] arm64: dts: msm8996: Add rpmpd device node

[Rajendra Nayak]

Add rpmpd device node and its OPP table

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index b29fe80d7288..ed35f0ced699 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -306,6 +306,40 @@
#clock-cells = <1>;
};
 
+   rpmpd: power-controller {
+   compatible = "qcom,msm8996-rpmpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmpd_opp_table>;
+   };
+
+   rpmpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmpd_opp1: opp1 {
+   qcom,level = <1>;
+   };
+
+   rpmpd_opp2: opp2 {
+   qcom,level = <2>;
+   };
+
+   rpmpd_opp3: opp3 {
+   qcom,level = <3>;
+   };
+
+   rpmpd_opp4: opp4 {
+   qcom,level = <4>;
+   };
+
+   rpmpd_opp5: opp5 {
+   qcom,level = <5>;
+   };
+
+   rpmpd_opp6: opp6 {
+   qcom,level = <6>;
+   };
+   };
+
pm8994-regulators {
compatible = "qcom,rpm-pm8994-regulators";
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v5 0/8] Add power domain driver for corners on msm8996/sdm845

[Rajendra Nayak]

Hi Rob,

This series is mainly pending your review/ack for the DT parts.
Rest of the genpd parts are reviewed and acked by both Viresh
and Ulf.

Changes in v5:
* First 6 patches are unchanged
* Patch 7/8 adds the DT node for rpmh power-controller on sdm845 and the
corresponding OPP tables for it to describe the performance states
* Patch 8/8 adds a parent/child relationship across mx/cx and mx_ao/cx_ao
as needed on sdm845 platform. This patch is dependent on the series from
Viresh [1] which adds support to propogate performance states across the
power domain hierarchy which is still being reviewed

Changes in v4:
* Included the patch to add qcom-opp bindings (dropped accidentally in v3)
* merged the patches to add bindings for rpm and rpmh, added consumer binding 
example
* Made the drivers built in, removed .remove
* Added better description in changelog for PATCH 6/6
* Updated rpmhpd_aggregate_corner() based on Davids feedback
* rpmhpd_set_performance_state() returns max corner, in cases where its called
with an INT_MAX
* Dropped the patch to max vote on all corners at init, the patch did not
work anyway, and it shouldn't be needed now

Changes in v3:
* Bindings split into seperate patches
* Bindings updated to remove duplicate OPP table phandles
* DT headers defining macros for Power domain indexes and OPP levels
* Optimisations to use rpmh_write_async() whereever applicable
* Fixed up handling of ACTIVE_ONLY/WAKE_ONLY/SLEEP voting for RPMh
* Fixed the vlvl to hlvl conversions in set_performance
* Other minor fixes based on review of v2
* TODO: This series does not handle the case where all VDD_MX votes
should be higher than VDD_CX from APPs, as pointed out
by David Collins in v2. This needs support at genpd to propogate performance
state up the parents, if we model these as Parent/Child to handle the
interdependency.

Changes in v2:
* added a power domain driver for sdm845 which supports communicating to RPMh
* dropped the changes to sdhc driver to move over to using OPP
as there is active discussion on using OPP as the interface vs
handling all of it in clock drivers
* Other minor binding updates based on review of v1

With performance state support for genpd/OPP merged, this is an effort
to model a power domain driver to communicate corner/level
values for qualcomm platforms to RPM (Remote Power Manager) and RPMh.

[1] https://lkml.org/lkml/2018/11/26/333

Rajendra Nayak (8):
  dt-bindings: opp: Introduce qcom-opp bindings
  dt-bindings: power: Add qcom rpm power domain driver bindings
  soc: qcom: rpmpd: Add a Power domain driver to model corners
  soc: qcom: rpmpd: Add support for get/set performance state
  arm64: dts: msm8996: Add rpmpd device node
  soc: qcom: rpmhpd: Add RPMh Power domain driver
  arm64: dts: sdm845: Add rpmh powercontroller node
  soc: qcom: rpmhpd: Mark mx as a parent for cx

 .../devicetree/bindings/opp/qcom-opp.txt  |  25 +
 .../devicetree/bindings/power/qcom,rpmpd.txt  | 146 ++
 arch/arm64/boot/dts/qcom/msm8996.dtsi |  34 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  |  51 ++
 drivers/soc/qcom/Kconfig  |  18 +
 drivers/soc/qcom/Makefile |   2 +
 drivers/soc/qcom/rpmhpd.c | 442 ++
 drivers/soc/qcom/rpmpd.c  | 340 ++
 include/dt-bindings/power/qcom-rpmpd.h|  39 ++
 9 files changed, 1097 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/opp/qcom-opp.txt
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
 create mode 100644 drivers/soc/qcom/rpmhpd.c
 create mode 100644 drivers/soc/qcom/rpmpd.c
 create mode 100644 include/dt-bindings/power/qcom-rpmpd.h

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] ext4: clean up indentation issues, remove extraneous tabs

[Theodore Y. Ts'o]

On Tue, Nov 27, 2018 at 10:28:36AM +0100, Jan Kara wrote:
> On Fri 23-11-18 16:30:43, Colin King wrote:
> > From: Colin Ian King 
> > 
> > There are several lines that are indented too far, clean these
> > up by removing the tabs.
> > 
> > Signed-off-by: Colin Ian King 
> 
> The patch looks good. You can add:
> 
> Reviewed-by: Jan Kara 

Thanks, applied.

- Ted

Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

[Viresh Kumar]

Hi Taniya,

Sorry that I haven't been reviewing it much from last few iterations as I was
letting others get this into a better shape. Thanks for your efforts..

On 02-12-18, 09:25, Taniya Das wrote:
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c

> +struct cpufreq_qcom {
> + struct cpufreq_frequency_table *table;
> + void __iomem *perf_state_reg;
> + cpumask_t related_cpus;
> +};
> +
> +static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];

Now that the code is much more simplified, I am not sure if you need this
per-cpu structure at all. The only place where you are using it is in
qcom_cpufreq_hw_cpu_init() and probe(). Why not merge qcom_cpu_resources_init()
completely into qcom_cpufreq_hw_cpu_init() and get rid of this structure
entirely ?

-- 
viresh

Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

[Kishon Vijay Abraham I]

Hi,

On 27/11/18 3:37 PM, Shawn Guo wrote:
> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.

Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
(with just changing tuning parameters)? If it could be used by other vendors
then it would make sense to add this PHY driver in synopsys directory.

Thanks
Kishon
> 
> Signed-off-by: Shawn Guo 
> ---
>  drivers/phy/qualcomm/Kconfig  |  10 +
>  drivers/phy/qualcomm/Makefile |   1 +
>  .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c  | 529 ++
>  3 files changed, 540 insertions(+)
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> 
> diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
> index 32f7d34eb784..c7b5ee82895d 100644
> --- a/drivers/phy/qualcomm/Kconfig
> +++ b/drivers/phy/qualcomm/Kconfig
> @@ -82,3 +82,13 @@ config PHY_QCOM_USB_HSIC
>   select GENERIC_PHY
>   help
> Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
> +
> +config PHY_QCOM_USB_HS_SNPS_28NM
> + tristate "Qualcomm Synopsys 28nm USB HS PHY driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in
> + select GENERIC_PHY
> + help
> +   Enable this to support the Synopsys 28nm Femto USB PHY on Qualcomm
> +   chips. This driver supports the high-speed PHY which is usually
> +   paired with either the ChipIdea or Synopsys DWC3 USB IPs on MSM SOCs.
> diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
> index c56efd3af205..dc238d95b18c 100644
> --- a/drivers/phy/qualcomm/Makefile
> +++ b/drivers/phy/qualcomm/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_QCOM_UFS_14NM)   += 
> phy-qcom-ufs-qmp-14nm.o
>  obj-$(CONFIG_PHY_QCOM_UFS_20NM)  += phy-qcom-ufs-qmp-20nm.o
>  obj-$(CONFIG_PHY_QCOM_USB_HS)+= phy-qcom-usb-hs.o
>  obj-$(CONFIG_PHY_QCOM_USB_HSIC)  += phy-qcom-usb-hsic.o
> +obj-$(CONFIG_PHY_QCOM_USB_HS_SNPS_28NM)  += phy-qcom-usb-hs-snsp-28nm.o
> diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c 
> b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> new file mode 100644
> index ..1fa364417237
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2009-2018, Linux Foundation. All rights reserved.
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* PHY register and bit definitions */
> +#define PHY_CTRL_COMMON0 0x078
> +#define SIDDQBIT(2)
> +#define PHY_IRQ_CMD  0x0d0
> +#define PHY_INTR_MASK0   0x0d4
> +#define PHY_INTR_CLEAR0  0x0dc
> +#define DPDM_MASK0x1e
> +#define DP_1_0   BIT(4)
> +#define DP_0_1   BIT(3)
> +#define DM_1_0   BIT(2)
> +#define DM_0_1   BIT(1)
> +
> +enum hsphy_voltage {
> + VOL_NONE,
> + VOL_MIN,
> + VOL_MAX,
> + VOL_NUM,
> +};
> +
> +enum hsphy_vreg {
> + VDD,
> + VDDA_1P8,
> + VDDA_3P3,
> + VREG_NUM,
> +};
> +
> +struct hsphy_init_seq {
> + int offset;
> + int val;
> + int delay;
> +};
> +
> +struct hsphy_data {
> + const struct hsphy_init_seq *init_seq;
> + unsigned int init_seq_num;
> +};
> +
> +struct hsphy_priv {
> + void __iomem *base;
> + struct clk_bulk_data *clks;
> + int num_clks;
> + struct reset_control *phy_reset;
> + struct reset_control *por_reset;
> + struct regulator_bulk_data vregs[VREG_NUM];
> + unsigned int voltages[VREG_NUM][VOL_NUM];
> + const struct hsphy_data *data;
> + bool cable_connected;
> + struct extcon_dev *vbus_edev;
> + struct notifier_block vbus_notify;
> + enum phy_mode mode;
> +};
> +
> +static int qcom_snps_hsphy_config_regulators(struct hsphy_priv *priv, int 
> high)
> +{
> + int old_uV[VREG_NUM];
> + int min, ret, i;
> +
> + min = high ? 1 : 0; /* low or none? */
> +
> + for (i = 0; i < VREG_NUM; i++) {
> + old_uV[i] = regulator_get_voltage(priv->vregs[i].consumer);
> + ret = regulator_set_voltage(priv->vregs[i].consumer,
> + priv->voltages[i][min],
> + priv->voltages[i][VOL_MAX]);
> + if (ret)
> + goto roll_back;
> + }
> +
> + return 0;
> +
> +roll_back:
> + for (; i >= 0; i--)
> + regulator_set_voltage(priv->vregs[i].consumer,
> + 

RE,

[Ms Sharifah Ahmad Mustahfa]

--
Hello,

First of all i will like to apologies for my manner of communication 
because you do not know me personally, its due to the fact that i have a 
very important proposal for you.

Re: [PATCH v2 1/5] devfreq: refactor set_target frequency function

[Chanwoo Choi]

Hi Lukasz,

On 2018년 12월 03일 23:31, Lukasz Luba wrote:
> The refactoring is needed for the new client in devfreq: suspend.
> To avoid code duplication, move it to the new local function
> devfreq_set_target.
> 
> The patch is based on earlier work by Tobias Jakobi.

As I already commented, Please remove it. You already mentioned it on 
cover-letter.
If you want to contain the contribution history of Tobias, you might better
to add 'Signed-off-by' or others.

> 
> Suggested-by: Tobias Jakobi 
> Suggested-by: Chanwoo Choi 
> Signed-off-by: Lukasz Luba 
> ---
>  drivers/devfreq/devfreq.c | 62 
> +++
>  1 file changed, 36 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 1414130..a9fd61b 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -285,6 +285,40 @@ static int devfreq_notify_transition(struct devfreq 
> *devfreq,
>   return 0;
>  }
>  
> +static int devfreq_set_target(struct devfreq *devfreq, unsigned long 
> new_freq,
> +   u32 flags)
> +{
> + struct devfreq_freqs freqs;
> + unsigned long cur_freq;
> + int err = 0;
> +
> + if (devfreq->profile->get_cur_freq)
> + devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
> + else
> + cur_freq = devfreq->previous_freq;
> +
> + freqs.old = cur_freq;
> + freqs.new = new_freq;
> + devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
> +
> + err = devfreq->profile->target(devfreq->dev.parent, &new_freq, flags);
> + if (err) {
> + freqs.new = cur_freq;
> + devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> + return err;
> + }
> +
> + freqs.new = new_freq;
> + devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> +
> + if (devfreq_update_status(devfreq, new_freq))
> + dev_err(&devfreq->dev,
> + "Couldn't update frequency transition information.\n");
> +
> + devfreq->previous_freq = new_freq;
> + return err;
> +}
> +
>  /* Load monitoring helper functions for governors use */
>  
>  /**
> @@ -296,8 +330,7 @@ static int devfreq_notify_transition(struct devfreq 
> *devfreq,
>   */
>  int update_devfreq(struct devfreq *devfreq)
>  {
> - struct devfreq_freqs freqs;
> - unsigned long freq, cur_freq, min_freq, max_freq;
> + unsigned long freq, min_freq, max_freq;
>   int err = 0;
>   u32 flags = 0;
>  
> @@ -333,31 +366,8 @@ int update_devfreq(struct devfreq *devfreq)
>   flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
>   }
>  
> - if (devfreq->profile->get_cur_freq)
> - devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
> - else
> - cur_freq = devfreq->previous_freq;
> -
> - freqs.old = cur_freq;
> - freqs.new = freq;
> - devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
> + return devfreq_set_target(devfreq, freq, flags);
>  
> - err = devfreq->profile->target(devfreq->dev.parent, &freq, flags);
> - if (err) {
> - freqs.new = cur_freq;
> - devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> - return err;
> - }
> -
> - freqs.new = freq;
> - devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> -
> - if (devfreq_update_status(devfreq, freq))
> - dev_err(&devfreq->dev,
> - "Couldn't update frequency transition information.\n");
> -
> - devfreq->previous_freq = freq;
> - return err;
>  }
>  EXPORT_SYMBOL(update_devfreq);
>  
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

linux-next: manual merge of the char-misc tree with the char-misc.current tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/hv/channel_mgmt.c

between commit:

  37c2578c0c40 ("Drivers: hv: vmbus: Offload the handling of channels to two 
workqueues")

from the char-misc.current tree and commit:

  4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API 
vmbus_get_outgoing_channel()")

from the char-misc tree.

I fixed it up (I used the former version where they conflicted) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell


pgp0vh8f1ZmPD.pgp
Description: OpenPGP digital signature

Re: [PATCH] ext4: fix possible use after free in ext4_quota_enable

[Theodore Y. Ts'o]

On Tue, Nov 27, 2018 at 10:14:53AM +0100, Jan Kara wrote:
> On Mon 26-11-18 11:21:06, Pan Bian wrote:
> > The function frees qf_inode via iput but then pass qf_inode to
> > lockdep_set_quota_inode on the failure path. This may result in a
> > use-after-free bug. The patch frees df_inode only when it is never used.
> > 
> > Signed-off-by: Pan Bian 
> > Fixes: daf647d2dd5("ext4: add lockdep annotations for i_data_sem")
> 
> Thanks for the fix! The patch looks good. You can add:
> 
> Reviewed-by: Jan Kara 

Thanks, applied.

- Ted

RE,

[Ms Sharifah Ahmad Mustahfa]

--
Hello,

First of all i will like to apologies for my manner of communication 
because you do not know me personally, its due to the fact that i have a 
very important proposal for you.

Query regarding Spectre fixes for qemu-kvm...4.4 LTS Kernel.

[Arackal, Paulose Kuriakose (STSD)]

Hi,

I have few queries regarding qemu-kvm support of Spectre related fixes at 4.4.* 
LTS Kernel.

I see that in upstream kernels, svm_vcpu_run() calls  x86_spec_ctrl_set_guest() 
and  x86_spec_ctrl_restore_host().
And calling into x86_virt_spec_ctrl(), that sets IBRS/IBPB/SSBD bits 
accordingly for guest context.

Related commit IDs below:
commit 5cf687548705412da47c9cec342fd952d71ed3d5
commit ccbcd2674472a978b48c91c1fbfb66c0ff959f24

Looks like this change is not fully ported to 4.4 LTS yet. 
x86_spec_ctrl_set_guest() and  x86_spec_ctrl_restore_host() interfaces are 
available, however looks like  svm_vcpu_run() is not calling them.  
So qemu-kvm running on 4.4 kernels may not have SPEC_CTRL set properly in guest 
context.

Is there a plan to backport above changes fully into 4.4 LTS kernel?.

Thanks,
Paulose. 

Re: [PATCH 2/2] Input: omap-keypad: Fix idle configration to not block SoC idle states

[Dmitry Torokhov]

Hi Tony,

On Mon, Dec 03, 2018 at 03:12:51PM -0800, Tony Lindgren wrote:
> 
> With PM enabled, I noticed that pressing a key on the droid4 keyboard will
> block deeper idle states for the SoC. Looks like we can fix this by
> managing the idle register to gether with the interrupt similar to what
> we already do for the GPIO controller.

Can you show me where exactly we are doing this? I can't seem to find
the matching code.

Thanks!

> 
> And there's no need to keep enabling and disabling interrupts and
> wake-up events for normal use if we use IRQF_ONESHOT as suggested by
> Dmitry Torokhov  so let's do that too.
> 
> Cc: Axel Haslam 
> Cc: Illia Smyrnov 
> Cc: Marcel Partap 
> Cc: Merlijn Wajer 
> Cc: Michael Scott 
> Cc: NeKit 
> Cc: Pavel Machek 
> Cc: Sebastian Reichel 
> Reported-by: Pavel Machek 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/input/keyboard/omap4-keypad.c | 30 ++-
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c 
> b/drivers/input/keyboard/omap4-keypad.c
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -53,11 +53,12 @@
>  /* OMAP4 bit definitions */
>  #define OMAP4_DEF_IRQENABLE_EVENTEN  BIT(0)
>  #define OMAP4_DEF_IRQENABLE_LONGKEY  BIT(1)
> -#define OMAP4_DEF_WUP_EVENT_ENA  BIT(0)
> -#define OMAP4_DEF_WUP_LONG_KEY_ENA   BIT(1)
>  #define OMAP4_DEF_CTRL_NOSOFTMODEBIT(1)
>  #define OMAP4_DEF_CTRL_PTV_SHIFT 2
>  
> +#define OMAP4_KBD_IRQ_MASK   (OMAP4_DEF_IRQENABLE_LONGKEY | \
> +  OMAP4_DEF_IRQENABLE_EVENTEN)
> +
>  /* OMAP4 values */
>  #define OMAP4_VAL_IRQDISABLE 0x0
>  
> @@ -126,12 +127,8 @@ static irqreturn_t omap4_keypad_irq_handler(int irq, 
> void *dev_id)
>  {
>   struct omap4_keypad *keypad_data = dev_id;
>  
> - if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)) {
> - /* Disable interrupts */
> - kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
> -  OMAP4_VAL_IRQDISABLE);
> + if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS))
>   return IRQ_WAKE_THREAD;
> - }
>  
>   return IRQ_NONE;
>  }
> @@ -173,11 +170,6 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq, 
> void *dev_id)
>   kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
>kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
>  
> - /* enable interrupts */
> - kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
> - OMAP4_DEF_IRQENABLE_EVENTEN |
> - OMAP4_DEF_IRQENABLE_LONGKEY);
> -
>   return IRQ_HANDLED;
>  }
>  
> @@ -197,11 +189,10 @@ static int omap4_keypad_open(struct input_dev *input)
>   /* clear pending interrupts */
>   kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
>kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
> - kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
> - OMAP4_DEF_IRQENABLE_EVENTEN |
> - OMAP4_DEF_IRQENABLE_LONGKEY);
> - kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE,
> - OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA);
> +
> + /* enable interrupts and wake-up events */
> + kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE, OMAP4_KBD_IRQ_MASK);
> + kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE, OMAP4_KBD_IRQ_MASK);
>  
>   enable_irq(keypad_data->irq);
>  
> @@ -214,9 +205,10 @@ static void omap4_keypad_close(struct input_dev *input)
>  
>   disable_irq(keypad_data->irq);
>  
> - /* Disable interrupts */
> + /* Disable interrupts and wake-up events */
>   kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
>OMAP4_VAL_IRQDISABLE);
> + kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE, 0);
>  
>   /* clear pending interrupts */
>   kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
> @@ -365,7 +357,7 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>   }
>  
>   error = request_threaded_irq(keypad_data->irq, omap4_keypad_irq_handler,
> -  omap4_keypad_irq_thread_fn, 0,
> +  omap4_keypad_irq_thread_fn, IRQF_ONESHOT,
>"omap4-keypad", keypad_data);
>   if (error) {
>   dev_err(&pdev->dev, "failed to register interrupt\n");
> -- 
> 2.19.2

-- 
Dmitry

Re: [PATCH] platform/x86: convert to DEFINE_SHOW_ATTRIBUTE

[Frank Lee]

On Tue, Dec 4, 2018 at 3:09 AM Andy Shevchenko
 wrote:
>
> On Sat, Dec 1, 2018 at 5:52 PM Yangtao Li  wrote:
> >
> > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> By some reason it's not applicable.
> Please, rebase on top of our for-next branch, thanks!
For what reason?
 I thought that for-next branch has not changed much.

Yours,
Yangtao

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[David Rientjes]

On Tue, 4 Dec 2018, Pingfan Liu wrote:

> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 76f8db0..8324953 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -453,6 +453,8 @@ static inline int gfp_zonelist(gfp_t flags)
>   */
>  static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
>  {
> + if (unlikely(!node_online(nid)))
> + nid = first_online_node;
>   return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
>  }
>  

So we're passing the node id from dev_to_node() to kmalloc which 
interprets that as the preferred node and then does node_zonelist() to 
find the zonelist at allocation time.

What happens if we fix this in alloc_dr()?  Does anything else cause 
problems?

And rather than using first_online_node, would next_online_node() work?

I'm thinking about this:

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -100,6 +100,8 @@ static __always_inline struct devres * 
alloc_dr(dr_release_t release,
&tot_size)))
return NULL;
 
+   if (unlikely(!node_online(nid)))
+   nid = next_online_node(nid);
dr = kmalloc_node_track_caller(tot_size, gfp, nid);
if (unlikely(!dr))
return NULL;

[RFC PATCH] Add IPA clock support for clk-rpmh

[David Dai]

This patch extends the existing clk-rpmh driver to support a different
type of RPMh resource known as Bus Clock Manager(BCM) in order to scale
performance for the Qualcomm IP Accelerator(IPA) core clock.

David Dai (1):
  clk: qcom: clk-rpmh: Add IPA clock support

 drivers/clk/qcom/clk-rpmh.c   | 142 ++
 include/dt-bindings/clock/qcom,rpmh.h |   1 +
 2 files changed, 143 insertions(+)

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

[RFC PATCH] clk: qcom: clk-rpmh: Add IPA clock support

[David Dai]

Add IPA clock support by extending the current clk rpmh driver to support
clocks that are managed by a different type of RPMh resource known as
Bus Clock Manager(BCM).

Signed-off-by: David Dai 
---
 drivers/clk/qcom/clk-rpmh.c   | 142 ++
 include/dt-bindings/clock/qcom,rpmh.h |   1 +
 2 files changed, 143 insertions(+)

diff --git a/drivers/clk/qcom/clk-rpmh.c b/drivers/clk/qcom/clk-rpmh.c
index 9f4fc77..42e2cd2 100644
--- a/drivers/clk/qcom/clk-rpmh.c
+++ b/drivers/clk/qcom/clk-rpmh.c
@@ -18,6 +18,32 @@
 #define CLK_RPMH_ARC_EN_OFFSET 0
 #define CLK_RPMH_VRM_EN_OFFSET 4
 
+#define BCM_TCS_CMD_COMMIT_MASK0x4000
+#define BCM_TCS_CMD_VALID_SHIFT29
+#define BCM_TCS_CMD_VOTE_MASK  0x3fff
+#define BCM_TCS_CMD_VOTE_SHIFT 0
+
+#define BCM_TCS_CMD(valid, vote) \
+   (BCM_TCS_CMD_COMMIT_MASK |\
+   ((valid) << BCM_TCS_CMD_VALID_SHIFT) |\
+   ((cpu_to_le32(vote) &\
+   BCM_TCS_CMD_VOTE_MASK) << BCM_TCS_CMD_VOTE_SHIFT))
+
+/**
+ * struct bcm_db - Auxiliary data pertaining to each Bus Clock Manager(BCM)
+ * @unit: divisor used to convert Hz value to an RPMh msg
+ * @width: multiplier used to convert Hz value to an RPMh msg
+ * @vcd: virtual clock domain that this bcm belongs to
+ * @reserved: reserved to pad the struct
+ */
+
+struct bcm_db {
+   u32 unit;
+   u16 width;
+   u8 vcd;
+   u8 reserved;
+};
+
 /**
  * struct clk_rpmh - individual rpmh clock data structure
  * @hw:handle between common and hardware-specific 
interfaces
@@ -29,6 +55,7 @@
  * @aggr_state:rpmh clock aggregated state
  * @last_sent_aggr_state: rpmh clock last aggr state sent to RPMh
  * @valid_state_mask:  mask to determine the state of the rpmh clock
+ * @aux_data:  data specific to the bcm rpmh resource
  * @dev:   device to which it is attached
  * @peer:  pointer to the clock rpmh sibling
  */
@@ -42,6 +69,7 @@ struct clk_rpmh {
u32 aggr_state;
u32 last_sent_aggr_state;
u32 valid_state_mask;
+   struct bcm_db aux_data;
struct device *dev;
struct clk_rpmh *peer;
 };
@@ -98,6 +126,17 @@ struct clk_rpmh_desc {
__DEFINE_CLK_RPMH(_platform, _name, _name_active, _res_name,\
  CLK_RPMH_VRM_EN_OFFSET, 1, _div)
 
+#define DEFINE_CLK_RPMH_BCM(_platform, _name, _res_name)   \
+   static struct clk_rpmh _platform##_##_name = {  \
+   .res_name = _res_name,  \
+   .valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
+   .div = 1,   \
+   .hw.init = &(struct clk_init_data){ \
+   .ops = &clk_rpmh_bcm_ops,   \
+   .name = #_name, \
+   },  \
+   }
+
 static inline struct clk_rpmh *to_clk_rpmh(struct clk_hw *_hw)
 {
return container_of(_hw, struct clk_rpmh, hw);
@@ -210,6 +249,91 @@ static unsigned long clk_rpmh_recalc_rate(struct clk_hw 
*hw,
.recalc_rate= clk_rpmh_recalc_rate,
 };
 
+static int clk_rpmh_bcm_send_cmd(struct clk_rpmh *c, bool enable)
+{
+   struct tcs_cmd cmd = { 0 };
+   u32 cmd_state;
+   int ret;
+
+   cmd_state = enable ? (c->aggr_state ? c->aggr_state : 1) : 0;
+
+   if (c->last_sent_aggr_state == cmd_state)
+   return 0;
+
+   cmd.addr = c->res_addr;
+   cmd.data = BCM_TCS_CMD(enable, cmd_state);
+
+   ret = rpmh_write_async(c->dev, RPMH_ACTIVE_ONLY_STATE, &cmd, 1);
+   if (ret) {
+   dev_err(c->dev, "set active state of %s failed: (%d)\n",
+   c->res_name, ret);
+   return ret;
+   }
+
+   c->last_sent_aggr_state = cmd_state;
+
+   return 0;
+}
+
+static int clk_rpmh_bcm_prepare(struct clk_hw *hw)
+{
+   struct clk_rpmh *c = to_clk_rpmh(hw);
+   int ret = 0;
+
+   mutex_lock(&rpmh_clk_lock);
+   ret = clk_rpmh_bcm_send_cmd(c, true);
+   mutex_unlock(&rpmh_clk_lock);
+
+   return ret;
+};
+
+static void clk_rpmh_bcm_unprepare(struct clk_hw *hw)
+{
+   struct clk_rpmh *c = to_clk_rpmh(hw);
+
+   mutex_lock(&rpmh_clk_lock);
+   clk_rpmh_bcm_send_cmd(c, false);
+   mutex_unlock(&rpmh_clk_lock);
+};
+
+static int clk_rpmh_bcm_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long parent_rate)
+{
+   struct clk_rpmh *c = to_clk_rpmh(hw);
+
+   c->aggr_state = rate / (c->aux_data.unit * 1000);
+
+   if (clk_hw_is_prepared(hw)) {
+   mutex_lock(&rpmh_clk_lock);
+   clk_rpmh_bcm_send_cmd(c, true);
+   mutex_unlock(&rpmh_clk_lock);
+   }
+
+   return 0;
+};
+
+stat

[git pull] Input updates for v4.20-rc5

[Dmitry Torokhov]

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. Mostly new IDs for
Elan/Synaptics touchpads, plus a few small fixups.

Changelog:
-

Adam Wong (1):
  Input: elan_i2c - add support for ELAN0621 touchpad

Brian Norris (1):
  Input: cros_ec_keyb - fix button/switch capability reports

Cameron Gutman (1):
  Input: xpad - quirk all PDP Xbox One gamepads

Christian Hoff (1):
  Input: matrix_keypad - check for errors from of_get_named_gpio()

Colin Ian King (1):
  Input: atkbd - clean up indentation issue

Ding Tao (1):
  Input: dt-bindings - fix a typo in file input-reset.txt

Kuninori Morimoto (2):
  Input: migor_ts - convert to SPDX identifiers
  Input: st1232 - convert to SPDX identifiers

Lyude Paul (1):
  Input: synaptics - add PNP ID for ThinkPad P50 to SMBus

Noah Westervelt (1):
  Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR

Patrick Gaskin (1):
  Input: elan_i2c - add ELAN0620 to the ACPI table

Teika Kazura (1):
  Input: synaptics - enable SMBus for HP 15-ay000

Tony Lindgren (1):
  Input: omap-keypad - fix keyboard debounce configuration

Vitaly Kuznetsov (1):
  Input: hyper-v - fix wakeup from suspend-to-idle

Diffstat:


 .../devicetree/bindings/input/input-reset.txt  |  2 +-
 drivers/hid/hid-hyperv.c   |  2 +-
 drivers/input/joystick/xpad.c  | 16 ++-
 drivers/input/keyboard/atkbd.c |  2 +-
 drivers/input/keyboard/cros_ec_keyb.c  |  3 ++-
 drivers/input/keyboard/matrix_keypad.c | 23 +-
 drivers/input/keyboard/omap4-keypad.c  | 18 +
 drivers/input/mouse/elan_i2c_core.c|  3 +++
 drivers/input/mouse/synaptics.c|  2 ++
 drivers/input/serio/hyperv-keyboard.c  |  2 +-
 drivers/input/touchscreen/migor_ts.c   | 15 +-
 drivers/input/touchscreen/st1232.c | 12 ++-
 12 files changed, 48 insertions(+), 52 deletions(-)

Thanks.


-- 
Dmitry

RE: [PATCH] ARM: imx: update the cpu power up timing setting

[Anson Huang]

Hi, Fabio

Best Regards!
Anson Huang

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年12月3日 20:03
> To: Anson Huang 
> Cc: Shawn Guo ; Sascha Hauer
> ; Sascha Hauer ; Fabio
> Estevam ; Russell King - ARM Linux
> ; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE ; linux-kernel
> ; dl-linux-imx 
> Subject: Re: [PATCH] ARM: imx: update the cpu power up timing setting
> 
> On Mon, Dec 3, 2018 at 9:42 AM Fabio Estevam 
> wrote:
> >
> > On Mon, Dec 3, 2018 at 12:45 AM Anson Huang 
> wrote:
> > >
> > > The sw2iso count should cover ARM LDO ramp-up time, the MAX ARM LDO
> > > ramp-up time may be up to more than 100us on some boards, this patch
> > > sets sw2iso to 0xf
> > > (~384us) which is the reset value, and it is much more safe to cover
> > > different boards, since we have observed that some customer boards
> > > failed with current setting of 0x2.
> > >
> > > Fixes: 05136f0897b5 ("ARM: imx: support arm power off in cpuidle for
> > > i.mx6sx")
> > > Signed-off-by: Anson Huang 
> >
> > Reviewed-by: Fabio Estevam 
> 
> Minor nit that maybe Shawn can fix while applying it: Subject should contain
> imx6sx as this change only affect this SoC.

I sent out the V2 patch to easy Shawn's work. Thanks.

Anson.

[PATCH V2] ARM: imx: update the cpu power up timing setting on i.mx6sx

[Anson Huang]

The sw2iso count should cover ARM LDO ramp-up time,
the MAX ARM LDO ramp-up time may be up to more than
100us on some boards, this patch sets sw2iso to 0xf
(~384us) which is the reset value, and it is much
more safe to cover different boards, since we have
observed that some customer boards failed with current
setting of 0x2.

Fixes: 05136f0897b5 ("ARM: imx: support arm power off in cpuidle for i.mx6sx")
Signed-off-by: Anson Huang 
Reviewed-by: Fabio Estevam 
---
 arch/arm/mach-imx/cpuidle-imx6sx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c 
b/arch/arm/mach-imx/cpuidle-imx6sx.c
index 243a108..fd0053e 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sx.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
@@ -110,7 +110,7 @@ int __init imx6sx_cpuidle_init(void)
 * except for power up sw2iso which need to be
 * larger than LDO ramp up time.
 */
-   imx_gpc_set_arm_power_up_timing(2, 1);
+   imx_gpc_set_arm_power_up_timing(0xf, 1);
imx_gpc_set_arm_power_down_timing(1, 1);
 
return cpuidle_register(&imx6sx_cpuidle_driver, NULL);
-- 
2.7.4

Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices

[Chunyan Zhang]

Hi Faiz,

On Mon, 3 Dec 2018 at 21:55, Faiz Abbas  wrote:
>
> Hi,
>
> On 03/12/18 5:45 PM, Faiz Abbas wrote:
> > Hi,
> >
> >> +static void sdhci_external_dma_prepare_data(struct sdhci_host *host,
> >> +struct mmc_command *cmd)
> >> +{
> >
> > Please add a condition for data == NULL here. This was already pointed
> > out by Adrian in v2.

The check for data is added in sdhci_external_dma_setup() .

> >
> > My test with an am335x-evm failed with these patches. Looks like the
> > very first SDIO commands failing.

I guess you didn't add 'dmas' in device tree, like patch 3 shows.

> >
> > https://pastebin.ubuntu.com/p/Y2RDjSKpgd/
> >
> > Currently am335x-evm is using omap_hsmmc driver. I added the following
> > patch to make it work with sdhci_omap.
> >
> > https://pastebin.ubuntu.com/p/VTGrCbJxY3/
> >
> > Will look deeper into this. Please ping if you need any more information.
> >
>
> So I disabled DMA in the driver altogether and still got the same
> messages on am335x-evm in PIO mode. Looks like something more is
> required for it to be supported.
>
> I instead shifted to a dra71-evm which supports both ADMA and external
> DMA. Here is the log:
>
> https://pastebin.ubuntu.com/p/mcJmgcjQsp/
>
> The interface fundamentally works but it complains with the following error:
>

Yes, it switched back to ADMA/PIO since sdhci couldn't find 'dmas'
property in devicetree.

> [3.111693] Failed to request TX DMA channel.

Ok, I will add a check in sdhci-omap.c before switching to external
dma, that should be able to avoid this error logs.

Thanks for the review and test!

Chunyan

[PATCH] mm/alloc: fallback to first node if the wanted node offline

[Pingfan Liu]

During my test on some AMD machine, with kexec -l nr_cpus=x option, the
kernel failed to bootup, because some node's data struct can not be allocated,
e.g, on x86, initialized by init_cpu_to_node()->init_memory_less_node(). But
device->numa_node info is used as preferred_nid param for
__alloc_pages_nodemask(), which causes NULL reference
  ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
This patch tries to fix the issue by falling back to the first online node,
when encountering such corner case.

Notes about the crashing info:
-1. kexec -l with nr_cpus=4
-2. system info
  NUMA node0 CPU(s): 0,8,16,24
  NUMA node1 CPU(s): 2,10,18,26
  NUMA node2 CPU(s): 4,12,20,28
  NUMA node3 CPU(s): 6,14,22,30
  NUMA node4 CPU(s): 1,9,17,25
  NUMA node5 CPU(s): 3,11,19,27
  NUMA node6 CPU(s): 5,13,21,29
  NUMA node7 CPU(s): 7,15,23,31
-3. panic stack
[...]
[5.721547] atomic64_test: passed for x86-64 platform with CX8 and with SSE
[5.729187] pcieport :00:01.1: Signaling PME with IRQ 34
[5.735187] pcieport :00:01.2: Signaling PME with IRQ 35
[5.741168] pcieport :00:01.3: Signaling PME with IRQ 36
[5.747189] pcieport :00:07.1: Signaling PME with IRQ 37
[5.754061] pcieport :00:08.1: Signaling PME with IRQ 39
[5.760727] pcieport :20:07.1: Signaling PME with IRQ 40
[5.766955] pcieport :20:08.1: Signaling PME with IRQ 42
[5.772742] BUG: unable to handle kernel paging request at 2088
[5.773618] PGD 0 P4D 0
[5.773618] Oops:  [#1] SMP NOPTI
[5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
[5.773618] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.4.3 
06/29/2018
[5.773618] RIP: 0010:__alloc_pages_nodemask+0xe2/0x2a0
[5.773618] Code: 00 00 44 89 ea 80 ca 80 41 83 f8 01 44 0f 44 ea 89 da c1 
ea 08 83 e2 01 88 54 24 20 48 8b 54 24 08 48 85 d2 0f 85 46 01 00 00 <3b> 77 08 
0f 82 3d 01 00 00 48 89 f8 44 89 ea 48 89
e1 44 89 e6 89
[5.773618] RSP: 0018:aa65fb20 EFLAGS: 00010246
[5.773618] RAX:  RBX: 006012c0 RCX: 
[5.773618] RDX:  RSI: 0002 RDI: 2080
[5.773618] RBP: 006012c0 R08:  R09: 0002
[5.773618] R10: 006080c0 R11: 0002 R12: 
[5.773618] R13: 0001 R14:  R15: 0002
[5.773618] FS:  () GS:8c69afe0() 
knlGS:
[5.773618] CS:  0010 DS:  ES:  CR0: 80050033
[5.773618] CR2: 2088 CR3: 00087e00a000 CR4: 003406e0
[5.773618] Call Trace:
[5.773618]  new_slab+0xa9/0x570
[5.773618]  ___slab_alloc+0x375/0x540
[5.773618]  ? pinctrl_bind_pins+0x2b/0x2a0
[5.773618]  __slab_alloc+0x1c/0x38
[5.773618]  __kmalloc_node_track_caller+0xc8/0x270
[5.773618]  ? pinctrl_bind_pins+0x2b/0x2a0
[5.773618]  devm_kmalloc+0x28/0x60
[5.773618]  pinctrl_bind_pins+0x2b/0x2a0
[5.773618]  really_probe+0x73/0x420
[5.773618]  driver_probe_device+0x115/0x130
[5.773618]  __driver_attach+0x103/0x110
[5.773618]  ? driver_probe_device+0x130/0x130
[5.773618]  bus_for_each_dev+0x67/0xc0
[5.773618]  ? klist_add_tail+0x3b/0x70
[5.773618]  bus_add_driver+0x41/0x260
[5.773618]  ? pcie_port_setup+0x4d/0x4d
[5.773618]  driver_register+0x5b/0xe0
[5.773618]  ? pcie_port_setup+0x4d/0x4d
[5.773618]  do_one_initcall+0x4e/0x1d4
[5.773618]  ? init_setup+0x25/0x28
[5.773618]  kernel_init_freeable+0x1c1/0x26e
[5.773618]  ? loglevel+0x5b/0x5b
[5.773618]  ? rest_init+0xb0/0xb0
[5.773618]  kernel_init+0xa/0x110
[5.773618]  ret_from_fork+0x22/0x40
[5.773618] Modules linked in:
[5.773618] CR2: 2088
[5.773618] ---[ end trace 1030c9120a03d081 ]---
[...]

Other notes about the reproduction of this bug:
After appling the following patch:
commit 0d76bcc960e6057750fcf556b65da13f8bbdfd2b
Author: Bjorn Helgaas 
Date:   Tue Nov 13 08:38:17 2018 -0600

Revert "ACPI/PCI: Pay attention to device-specific _PXM node values"

This bug is covered and not triggered on my test AMD machine.
But it should still exist since dev->numa_node info can be set by other
method on other archs when using nr_cpus param

Signed-off-by: Pingfan Liu 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
Cc: Mike Rapoport 
Cc: Bjorn Helgaas 
Cc: Jonathan Cameron 
---
 include/linux/gfp.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 76f8db0..8324953 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -453,6 +453,8 @@ static inline int gfp_zonelist(gfp_t flags)
  */
 static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
 {
+   if (unlikely(!node_online(nid)))
+   nid = first_online_node;
return NODE_DATA(nid)->node_zoneli

Re: [PATCH v2] memblock: Anonotate memblock_is_reserved() with __init_memblock.

[Wei Yang]

On Mon, Dec 03, 2018 at 04:00:08AM +, Yueyi Li wrote:
>Found warning:
>
>WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version 
>generation failed, symbol will not be versioned.
>WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the 
>function valid_phys_addr_range() to the function 
>.init.text:memblock_is_reserved()
>The function valid_phys_addr_range() references
>the function __init memblock_is_reserved().
>This is often because valid_phys_addr_range lacks a __init
>annotation or the annotation of memblock_is_reserved is wrong.
>
>Use __init_memblock instead of __init.

Not familiar with this error, the change looks good to me while have
some questions.

1. I don't see valid_phys_addr_range() reference memblock_is_reserved().
   This is in which file or arch?
2. In case a function reference memblock_is_reserved(), should it has
   the annotation of __init_memblock too? Or just __init is ok? If my
   understanding is correct, annotation __init is ok. Well, I don't see
   valid_phys_addr_range() has an annotation.
3. The only valid_phys_addr_range() reference some memblock function is
   the one in arch/arm64/mm/mmap.c. Do we suppose to add an annotation to
   this?

>
>Signed-off-by: liyueyi 
>---
>
> Changes v2: correct typo in 'warning'.
>
> mm/memblock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/mm/memblock.c b/mm/memblock.c
>index 9a2d5ae..81ae63c 100644
>--- a/mm/memblock.c
>+++ b/mm/memblock.c
>@@ -1727,7 +1727,7 @@ static int __init_memblock memblock_search(struct 
>memblock_type *type, phys_addr
>   return -1;
> }
> 
>-bool __init memblock_is_reserved(phys_addr_t addr)
>+bool __init_memblock memblock_is_reserved(phys_addr_t addr)
> {
>   return memblock_search(&memblock.reserved, addr) != -1;
> }
>-- 
>2.7.4

-- 
Wei Yang
Help you, Help me

Re: [PATCH v2 2/3] mmc: sdhci-omap: Add using external dma

[Chunyan Zhang]

Hi Faiz,

Thanks for the review and test!

On Mon, 3 Dec 2018 at 21:47, Faiz Abbas  wrote:
>
> Chunyan,
>
> On 12/11/18 12:56 PM, Chunyan Zhang wrote:
> > sdhci-omap can support both external dma controller via dmaengine framework
> > as well as ADMA which standard SD host controller provides.
> >
> > Signed-off-by: Chunyan Zhang 
> > ---
> >  drivers/mmc/host/sdhci-omap.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> > index 88347ce..ccc79f2 100644
> > --- a/drivers/mmc/host/sdhci-omap.c
> > +++ b/drivers/mmc/host/sdhci-omap.c
> > @@ -896,6 +896,7 @@ static int sdhci_omap_probe(struct platform_device 
> > *pdev)
> >   const struct of_device_id *match;
> >   struct sdhci_omap_data *data;
> >   const struct soc_device_attribute *soc;
> > + struct resource *regs;
> >
> >   match = of_match_device(omap_sdhci_match, dev);
> >   if (!match)
> > @@ -908,6 +909,10 @@ static int sdhci_omap_probe(struct platform_device 
> > *pdev)
> >   }
> >   offset = data->offset;
> >
> > + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!regs)
> > + return -ENXIO;
> > +
> >   host = sdhci_pltfm_init(pdev, &sdhci_omap_pdata,
> >   sizeof(*omap_host));
> >   if (IS_ERR(host)) {
> > @@ -924,6 +929,7 @@ static int sdhci_omap_probe(struct platform_device 
> > *pdev)
> >   omap_host->timing = MMC_TIMING_LEGACY;
> >   omap_host->flags = data->flags;
> >   host->ioaddr += offset;
> > + host->mapbase = regs->start;
> >
> >   mmc = host->mmc;
> >   sdhci_get_of_property(pdev);
> > @@ -991,6 +997,7 @@ static int sdhci_omap_probe(struct platform_device 
> > *pdev)
> >   host->mmc_host_ops.execute_tuning = sdhci_omap_execute_tuning;
> >   host->mmc_host_ops.enable_sdio_irq = sdhci_omap_enable_sdio_irq;
> >
> > + sdhci_switch_external_dma(host, true);
>
> You should give the user a choice based on a dt property whether to use
> ADMA or use external DMA. We might still want to use external DMA for
> some platforms and ADMA for other platforms.

With the current patchset, if users want to use external DMA, they
need to add 'dmas' in device tree, like patch 3 shows:
+ dmas = <&sdma 61 &sdma 62>;
+ dma-names = "tx", "rx";
Otherwise, sdhci.c will switch back to use the DMA/PIO integrated in
standard SDHCI.

But I think your suggestion makes sense, will add the below graph in
next version:

+ /* Switch to external DMA only if there is the "dmas" property */
+ if (of_find_property(dev->of_node, "dmas", NULL))
+ sdhci_switch_external_dma(host, true);

Thanks,
Chunyan

Re: [PATCH] printk: don't unconditionally shortcut print_time()

[Sergey Senozhatsky]

On (12/02/18 14:02), Tetsuo Handa wrote:
>  
> @@ -1541,11 +1545,13 @@ int do_syslog(int type, char __user *buf, int len, 
> int source)
>   } else {
>   u64 seq = syslog_seq;
>   u32 idx = syslog_idx;
> + bool f = syslog_partial ? syslog_time : printk_time;
^^

>   while (seq < log_next_seq) {
>   struct printk_log *msg = log_from_idx(idx);
>  
> - error += msg_print_text(msg, true, NULL, 0);
> + error += msg_print_text(msg, true, f, NULL, 0);


> + f = printk_time;
^^^

>   idx = log_next(idx);
>   seq++;

Can we please have something better than 'f'?

-ss

Re: [PATCH 3/3] mm/memcg: Avoid reclaiming below hard protection

[Xunlei Pang]

On 2018/12/3 PM 7:57, Michal Hocko wrote:
> On Mon 03-12-18 16:01:19, Xunlei Pang wrote:
>> When memcgs get reclaimed after its usage exceeds min, some
>> usages below the min may also be reclaimed in the current
>> implementation, the amount is considerably large during kswapd
>> reclaim according to my ftrace results.
> 
> And here again. Describe the setup and the behavior please?
> 

step 1
mkdir -p /sys/fs/cgroup/memory/online
cd /sys/fs/cgroup/memory/online
echo 512M > memory.max
echo 40960 > memory.min
echo $$ > tasks
dd if=/dev/sda of=/dev/null


while true; do sleep 1; cat memory.current ; cat memory.min; done


step 2
create global memory pressure by allocating annoymous and cached
pages to constantly trigger kswap: dd if=/dev/sdb of=/dev/null

step 3
Then observe "online" groups, hundreds of kbytes a little over
memory.min can cause tens of MiB to be reclaimed by kswapd.

Here is one of test results I got:
cat memory.current; cat memory.min; echo;
409485312   // current
40960   // min

385052672   // See current got over reclaimed for 23MB
40960   // min

Its corresponding ftrace output I monitored:
kswapd_0-281   [000]    304.706632: shrink_node_memcg:
min_excess=24, nr_reclaimed=6013, sc->nr_to_reclaim=147, exceeds
5989pages

Re: [PATCH 2/3] mm/vmscan: Enable kswapd to reclaim low-protected memory

[Xunlei Pang]

On 2018/12/4 AM 1:22, Michal Hocko wrote:
> On Mon 03-12-18 23:20:31, Xunlei Pang wrote:
>> On 2018/12/3 下午7:56, Michal Hocko wrote:
>>> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
 There may be cgroup memory overcommitment, it will become
 even common in the future.

 Let's enable kswapd to reclaim low-protected memory in case
 of memory pressure, to mitigate the global direct reclaim
 pressures which could cause jitters to the response time of
 lantency-sensitive groups.
>>>
>>> Please be more descriptive about the problem you are trying to handle
>>> here. I haven't actually read the patch but let me emphasise that the
>>> low limit protection is important isolation tool. And allowing kswapd to
>>> reclaim protected memcgs is going to break the semantic as it has been
>>> introduced and designed.
>>
>> We have two types of memcgs: online groups(important business)
>> and offline groups(unimportant business). Online groups are
>> all configured with MAX low protection, while offline groups
>> are not at all protected(with default 0 low).
>>
>> When offline groups are overcommitted, the global memory pressure
>> suffers. This will cause the memory allocations from online groups
>> constantly go to the slow global direct reclaim in order to reclaim
>> online's page caches, as kswap is not able to reclaim low-protection
>> memory. low is not hard limit, it's reasonable to be reclaimed by
>> kswapd if there's no other reclaimable memory.
> 
> I am sorry I still do not follow. What role do offline cgroups play.
> Those are certainly not low mem protected because mem_cgroup_css_offline
> will reset them to 0.
> 

Oh, I meant "offline groups" to be "offline-business groups", memcgs
refered to here are all "online state" from kernel's perspective.

Re: [PATCH v7 2/4] clk: meson: add DT documentation for emmc clock controller

[Jianxin Pan]

Hi Stephen,

On 2018/12/4 6:45, Stephen Boyd wrote:
> Quoting Jianxin Pan (2018-11-15 04:18:30)
>> diff --git a/include/dt-bindings/clock/amlogic,mmc-clkc.h 
>> b/include/dt-bindings/clock/amlogic,mmc-clkc.h
>> new file mode 100644
>> index 000..162b949
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/amlogic,mmc-clkc.h
>> @@ -0,0 +1,17 @@
>> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
>> +/*
>> + * Meson MMC sub clock tree IDs
>> + *
>> + * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
>> + * Author: Yixun Lan 
>> + */
>> +
>> +#ifndef __MMC_CLKC_H
>> +#define __MMC_CLKC_H
>> +
>> +#define CLKID_MMC_DIV  1
> 
> Why does the define numbering start with 1 instead of 0?
>
The Clock ID 0 is used by  CLKID_MMC_MUX.
CLKID_MMC_MUX is an internal clock which defined in 
drivers/clk/meson/mmc-clkc.c, and it's the parent of CLKID_MMC_DIV.
 
>> +#define CLKID_MMC_PHASE_CORE   2
>> +#define CLKID_MMC_PHASE_TX 3
>> +#define CLKID_MMC_PHASE_RX 4
>> +
> 
> .
> 

Re: [PATCH v9 2/4] seccomp: switch system call argument type to void *

[Tycho Andersen]

On Mon, Dec 03, 2018 at 07:17:26PM -0700, Tycho Andersen wrote:
> On Tue, Dec 04, 2018 at 10:07:38AM +0800, kbuild test robot wrote:
> > Hi Tycho,
> > 
> > I love your patch! Yet something to improve:
> > 
> > [auto build test ERROR on linus/master]
> > [also build test ERROR on v4.20-rc5 next-20181203]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Tycho-Andersen/seccomp-hoist-struct-seccomp_data-recalculation-higher/20181204-013450
> > config: i386-randconfig-x005-201848 (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >In file included from kernel/seccomp.c:28:0:
> > >> include/linux/syscalls.h:239:18: error: conflicting types for 
> > >> 'sys_seccomp'
> >  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> >  ^
> >include/linux/syscalls.h:225:2: note: in expansion of macro 
> > '__SYSCALL_DEFINEx'
> >  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
> >  ^
> >include/linux/syscalls.h:216:36: note: in expansion of macro 
> > 'SYSCALL_DEFINEx'
> > #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, 
> > __VA_ARGS__)
> >^~~
> >kernel/seccomp.c:946:1: note: in expansion of macro 'SYSCALL_DEFINE3'
> > SYSCALL_DEFINE3(seccomp, unsigned int, op, unsigned int, flags,
> > ^~~
> >In file included from kernel/seccomp.c:28:0:
> >include/linux/syscalls.h:881:17: note: previous declaration of 
> > 'sys_seccomp' was here
> > asmlinkage long sys_seccomp(unsigned int op, unsigned int flags,
> > ^~~
> 
> Huh, I have no idea why I don't see this, but even with the attached
> config it still doesn't cause a problem for me. Anyway, I'll fix it up
> and do some more investigating...

Oh, because it's "make ARCH=i386". Whoosh :)

Anyway, it's fixed for v10.

Tycho

Re: [PATCH -V7 RESEND 08/21] swap: Support to read a huge swap cluster for swapin a THP

[Huang, Ying]

Daniel Jordan  writes:

> On Sat, Dec 01, 2018 at 08:34:06AM +0800, Huang, Ying wrote:
>> Daniel Jordan  writes:
>> > What do you think?
>> 
>> I think that swapoff() which is the main user of try_to_unuse() isn't a
>> common operation in practical.  So it's not necessary to make it more
>> complex for this.
>
> Ok, probably not worth the surgery on try_to_unuse, even if swapoff can be
> expensive when it does happen.
>
>> In alloc_hugepage_direct_gfpmask(), the only information provided by vma
>> is: vma->flags & VM_HUGEPAGE.  Because we have no vma available, I think
>> it is OK to just assume that the flag is cleared.  That is, rely on
>> system-wide THP settings only.
>> 
>> What do you think about this proposal?
>
> Sounds like a good compromise.
>
> So alloc_hugepage_direct_gfpmask will learn to make 'vma' optional?  Slightly
> concerned that future callers that should be passing vma's might not and open 
> a
> way to ignore vma huge page hints, but probably not a big deal in practice.  

alloc_pages_vma() -> get_vma_policy() -> __get_vma_policy()

has done that already.  So I guess that's not a big issue.  The callers
should be careful.

Best Regards,
Huang, Ying

Re: [PATCH v9 2/4] seccomp: switch system call argument type to void *

[Tycho Andersen]

On Tue, Dec 04, 2018 at 10:07:38AM +0800, kbuild test robot wrote:
> Hi Tycho,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc5 next-20181203]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Tycho-Andersen/seccomp-hoist-struct-seccomp_data-recalculation-higher/20181204-013450
> config: i386-randconfig-x005-201848 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from kernel/seccomp.c:28:0:
> >> include/linux/syscalls.h:239:18: error: conflicting types for 'sys_seccomp'
>  asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>  ^
>include/linux/syscalls.h:225:2: note: in expansion of macro 
> '__SYSCALL_DEFINEx'
>  __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>  ^
>include/linux/syscalls.h:216:36: note: in expansion of macro 
> 'SYSCALL_DEFINEx'
> #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, 
> __VA_ARGS__)
>^~~
>kernel/seccomp.c:946:1: note: in expansion of macro 'SYSCALL_DEFINE3'
> SYSCALL_DEFINE3(seccomp, unsigned int, op, unsigned int, flags,
> ^~~
>In file included from kernel/seccomp.c:28:0:
>include/linux/syscalls.h:881:17: note: previous declaration of 
> 'sys_seccomp' was here
> asmlinkage long sys_seccomp(unsigned int op, unsigned int flags,
> ^~~

Huh, I have no idea why I don't see this, but even with the attached
config it still doesn't cause a problem for me. Anyway, I'll fix it up
and do some more investigating...

Tycho

Re: [PATCH] pinctrl: meson: fix G12A ao pull registers base address

[Xingyu Chen]

On 2018/12/3 18:36, Jerome Brunet wrote:

On Mon, 2018-12-03 at 11:27 +0100, Neil Armstrong wrote:

Hi Xingyu,


On 03/12/2018 04:05, Xingyu Chen wrote:

Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG
and AO_GPIO_O.

These bits of controlling output level are remapped to the new register
AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable.

These bits of controlling pull enable are remapped to the new register
AO_RTI_PULL_UP_EN_REG, and the AO_RTI_PULL_UP_REG support only controlling
pull type(up/down).

The new layout of ao gpio/pull registers is as follows:
- AO_GPIO_O_EN_N[offset: 0x9 << 2]
- AO_GPIO_I [offset: 0xa << 2]
- AO_RTI_PULL_UP_REG[offset: 0xb << 2]
- AO_RTI_PULL_UP_EN_REG [offset: 0xc << 2]
- AO_GPIO_O [offset: 0xd << 2]

 From above, we can see ao GPIO registers region has been separated by the
ao pull registers. In order to ensure the continuity of the region on
software, the ao GPIO and ao pull registers use the same base address, but
can be identified by the offset.

Fixes: 29ae0952e85f ("pinctrl: meson-g12a: add pinctrl driver support")
Signed-off-by: Xingyu Chen 
Signed-off-by: Jianxin Pan 
---
  drivers/pinctrl/meson/pinctrl-meson.c | 22 --
  1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
b/drivers/pinctrl/meson/pinctrl-meson.c
index 53d449076dee..7ff40cd7a0cb 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -31,6 +31,9 @@
   * In some cases the register ranges for pull enable and pull
   * direction are the same and thus there are only 3 register ranges.
   *
+ * Since Meson G12A SoC, the ao register ranges for gpio, pull enable
+ * and pull direction are the same, so there are only 2 register ranges.
+ *
   * For the pull and GPIO configuration every bank uses a contiguous
   * set of bits in the register sets described above; the same register
   * can be shared by more banks with different offsets.
@@ -487,23 +490,22 @@ static int meson_pinctrl_parse_dt(struct
meson_pinctrl *pc,
return PTR_ERR(pc->reg_mux);
}
  
-	pc->reg_pull = meson_map_resource(pc, gpio_np, "pull");

-   if (IS_ERR(pc->reg_pull)) {
-   dev_err(pc->dev, "pull registers not found\n");
-   return PTR_ERR(pc->reg_pull);
+   pc->reg_gpio = meson_map_resource(pc, gpio_np, "gpio");
+   if (IS_ERR(pc->reg_gpio)) {
+   dev_err(pc->dev, "gpio registers not found\n");
+   return PTR_ERR(pc->reg_gpio);
}
  
+	pc->reg_pull = meson_map_resource(pc, gpio_np, "pull");

+   /* Use gpio region if pull one is not present */
+   if (IS_ERR(pc->reg_pull))
+   pc->reg_pull = pc->reg_gpio;
+
pc->reg_pullen = meson_map_resource(pc, gpio_np, "pull-enable");
/* Use pull region if pull-enable one is not present */
if (IS_ERR(pc->reg_pullen))
pc->reg_pullen = pc->reg_pull;
  
-	pc->reg_gpio = meson_map_resource(pc, gpio_np, "gpio");

-   if (IS_ERR(pc->reg_gpio)) {
-   dev_err(pc->dev, "gpio registers not found\n");
-   return PTR_ERR(pc->reg_gpio);
-   }
-
return 0;
  }
  


Doesn't it need an update of the bindings ?


Going even further, shouldn't we stop trying make multiple regions out of
this, and have just one ?

On all the Amlogic SoC we have seen so far, all the regions a very (VERY)
close to each other. It seems very unlikely that there something unrelated to
GPIO in between.

It looks like everything is mostly there in the driver to deal with offset, so
change would be minimal.

Of course, for  DT stability we will need to carry the legacy, but for newer
SoC, such as the g12, does it really makes sense to have multiple regions ?


Hi, Jerome
the ee gpio, pull and pull-en register regions are discontinuous, some 
addresses are reserved between them and maybe used for other module. For 
example [G12A]:

range of gpio register address offset:(0x010 << 2) - (0x022 << 2)
range of pull register address offset:(0x03a << 2) - (0x03f << 2)
range of pull-en register address offset: (0x048 << 2) - (0x04d << 2)

keeping the multiple register regions seems to be more flexible and 
friendly for Meson Series SoCs at present.




Neil




.

Re: [PATCH v4 0/7] zram idle page writeback

[Sergey Senozhatsky]

On (12/03/18 11:40), Minchan Kim wrote:
> 
> Minchan Kim (7):
>   zram: fix lockdep warning of free block handling
>   zram: fix double free backing device
>   zram: refactoring flags and writeback stuff
>   zram: introduce ZRAM_IDLE flag
>   zram: support idle/huge page writeback
>   zram: add bd_stat statistics
>   zram: writeback throttle

Looks good to me.

Reviewed-by: Sergey Senozhatsky 

-ss

Re: [PATCH v9 2/4] seccomp: switch system call argument type to void *

[kbuild test robot]

Hi Tycho,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc5 next-20181203]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tycho-Andersen/seccomp-hoist-struct-seccomp_data-recalculation-higher/20181204-013450
config: i386-randconfig-x005-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from kernel/seccomp.c:28:0:
>> include/linux/syscalls.h:239:18: error: conflicting types for 'sys_seccomp'
 asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
 ^
   include/linux/syscalls.h:225:2: note: in expansion of macro 
'__SYSCALL_DEFINEx'
 __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
 ^
   include/linux/syscalls.h:216:36: note: in expansion of macro 
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
   ^~~
   kernel/seccomp.c:946:1: note: in expansion of macro 'SYSCALL_DEFINE3'
SYSCALL_DEFINE3(seccomp, unsigned int, op, unsigned int, flags,
^~~
   In file included from kernel/seccomp.c:28:0:
   include/linux/syscalls.h:881:17: note: previous declaration of 'sys_seccomp' 
was here
asmlinkage long sys_seccomp(unsigned int op, unsigned int flags,
^~~

vim +/sys_seccomp +239 include/linux/syscalls.h

1bd21c6c2 Dominik Brodowski   2018-04-05  228  
e145242ea Dominik Brodowski   2018-04-09  229  /*
e145242ea Dominik Brodowski   2018-04-09  230   * The asmlinkage stub is 
aliased to a function named __se_sys_*() which
e145242ea Dominik Brodowski   2018-04-09  231   * sign-extends 32-bit ints to 
longs whenever needed. The actual work is
e145242ea Dominik Brodowski   2018-04-09  232   * done within __do_sys_*().
e145242ea Dominik Brodowski   2018-04-09  233   */
1bd21c6c2 Dominik Brodowski   2018-04-05  234  #ifndef __SYSCALL_DEFINEx
bed1ffca0 Frederic Weisbecker 2009-03-13  235  #define __SYSCALL_DEFINEx(x, 
name, ...)  \
bee200317 Arnd Bergmann   2018-06-19  236   __diag_push();  
\
bee200317 Arnd Bergmann   2018-06-19  237   __diag_ignore(GCC, 8, 
"-Wattribute-alias",  \
bee200317 Arnd Bergmann   2018-06-19  238 "Type aliasing is 
used to sanitize syscall arguments");\
83460ec8d Andi Kleen  2013-11-12 @239   asmlinkage long 
sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))   \
e145242ea Dominik Brodowski   2018-04-09  240   
__attribute__((alias(__stringify(__se_sys##name;\
c9a211951 Howard McLauchlan   2018-03-21  241   
ALLOW_ERROR_INJECTION(sys##name, ERRNO);\
e145242ea Dominik Brodowski   2018-04-09  242   static inline long 
__do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
e145242ea Dominik Brodowski   2018-04-09  243   asmlinkage long 
__se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)); \
e145242ea Dominik Brodowski   2018-04-09  244   asmlinkage long 
__se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  \
1a94bc347 Heiko Carstens  2009-01-14  245   {   
\
e145242ea Dominik Brodowski   2018-04-09  246   long ret = 
__do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
07fe6e00f Al Viro 2013-01-21  247   
__MAP(x,__SC_TEST,__VA_ARGS__); \
2cf096668 Al Viro 2013-01-21  248   __PROTECT(x, 
ret,__MAP(x,__SC_ARGS,__VA_ARGS__));   \
2cf096668 Al Viro 2013-01-21  249   return ret; 
\
1a94bc347 Heiko Carstens  2009-01-14  250   }   
\
bee200317 Arnd Bergmann   2018-06-19  251   __diag_pop();   
\
e145242ea Dominik Brodowski   2018-04-09  252   static inline long 
__do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
1bd21c6c2 Dominik Brodowski   2018-04-05  253  #endif /* __SYSCALL_DEFINEx */
1a94bc347 Heiko Carstens  2009-01-14  254  

:: The code at line 239 was first introduced by commit
:: 83460ec8dcac14142e7860a01fa59c267ac4657c syscalls.h: use gcc alias 
instead of assembler aliases for syscalls

:: TO: Andi Kleen 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] squashfs: enable __GFP_FS in ->readpage to prevent hang in mem alloc

[Hou Tao]

There is no need to disable __GFP_FS in ->readpage:
* It's a read-only fs, so there will be no dirty/writeback page and
  there will be no deadlock against the caller's locked page
* It just allocates one page, so compaction will not be invoked
* It doesn't take any inode lock, so the reclamation of inode will be fine

And no __GFP_FS may lead to hang in __alloc_pages_slowpath() if a
squashfs page fault occurs in the context of a memory hogger, because
the hogger will not be killed due to the logic in __alloc_pages_may_oom().

Signed-off-by: Hou Tao 
---
 fs/squashfs/file.c  |  3 ++-
 fs/squashfs/file_direct.c   |  4 +++-
 fs/squashfs/squashfs_fs_f.h | 25 +
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 fs/squashfs/squashfs_fs_f.h

diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c
index f1c1430ae721..8603dda4a719 100644
--- a/fs/squashfs/file.c
+++ b/fs/squashfs/file.c
@@ -51,6 +51,7 @@
 #include "squashfs_fs.h"
 #include "squashfs_fs_sb.h"
 #include "squashfs_fs_i.h"
+#include "squashfs_fs_f.h"
 #include "squashfs.h"
 
 /*
@@ -414,7 +415,7 @@ void squashfs_copy_cache(struct page *page, struct 
squashfs_cache_entry *buffer,
TRACE("bytes %d, i %d, available_bytes %d\n", bytes, i, avail);
 
push_page = (i == page->index) ? page :
-   grab_cache_page_nowait(page->mapping, i);
+   squashfs_grab_cache_page_nowait(page->mapping, i);
 
if (!push_page)
continue;
diff --git a/fs/squashfs/file_direct.c b/fs/squashfs/file_direct.c
index 80db1b86a27c..a0fdd6215348 100644
--- a/fs/squashfs/file_direct.c
+++ b/fs/squashfs/file_direct.c
@@ -17,6 +17,7 @@
 #include "squashfs_fs.h"
 #include "squashfs_fs_sb.h"
 #include "squashfs_fs_i.h"
+#include "squashfs_fs_f.h"
 #include "squashfs.h"
 #include "page_actor.h"
 
@@ -60,7 +61,8 @@ int squashfs_readpage_block(struct page *target_page, u64 
block, int bsize,
/* Try to grab all the pages covered by the Squashfs block */
for (missing_pages = 0, i = 0, n = start_index; i < pages; i++, n++) {
page[i] = (n == target_page->index) ? target_page :
-   grab_cache_page_nowait(target_page->mapping, n);
+   squashfs_grab_cache_page_nowait(
+   target_page->mapping, n);
 
if (page[i] == NULL) {
missing_pages++;
diff --git a/fs/squashfs/squashfs_fs_f.h b/fs/squashfs/squashfs_fs_f.h
new file mode 100644
index ..fc5fb7aeb27d
--- /dev/null
+++ b/fs/squashfs/squashfs_fs_f.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef SQUASHFS_FS_F
+#define SQUASHFS_FS_F
+
+/*
+ * No need to use FGP_NOFS here:
+ * 1. It's a read-only fs, so there will be no dirty/writeback page and
+ *there will be no deadlock against the caller's locked page.
+ * 2. It just allocates one page, so compaction will not be invoked.
+ * 3. It doesn't take any inode lock, so the reclamation of inode
+ *will be fine.
+ *
+ * And GFP_NOFS may lead to infinite loop in __alloc_pages_slowpath() if a
+ * squashfs page fault occurs in the context of a memory hogger, because
+ * the hogger will not be killed due to the logic in __alloc_pages_may_oom().
+ */
+static inline struct page *
+squashfs_grab_cache_page_nowait(struct address_space *mapping, pgoff_t index)
+{
+   return pagecache_get_page(mapping, index,
+   FGP_LOCK|FGP_CREAT|FGP_NOWAIT,
+   mapping_gfp_mask(mapping));
+}
+#endif
+
-- 
2.16.2.dirty

Re: [PATCH] pinctrl: meson: fix G12A ao pull registers base address

[Xingyu Chen]

On 2018/12/3 18:27, Neil Armstrong wrote:

Hi Xingyu,


On 03/12/2018 04:05, Xingyu Chen wrote:

Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG
and AO_GPIO_O.

These bits of controlling output level are remapped to the new register
AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable.

These bits of controlling pull enable are remapped to the new register
AO_RTI_PULL_UP_EN_REG, and the AO_RTI_PULL_UP_REG support only controlling
pull type(up/down).

The new layout of ao gpio/pull registers is as follows:
- AO_GPIO_O_EN_N[offset: 0x9 << 2]
- AO_GPIO_I [offset: 0xa << 2]
- AO_RTI_PULL_UP_REG[offset: 0xb << 2]
- AO_RTI_PULL_UP_EN_REG [offset: 0xc << 2]
- AO_GPIO_O [offset: 0xd << 2]

 From above, we can see ao GPIO registers region has been separated by the
ao pull registers. In order to ensure the continuity of the region on
software, the ao GPIO and ao pull registers use the same base address, but
can be identified by the offset.

Fixes: 29ae0952e85f ("pinctrl: meson-g12a: add pinctrl driver support")
Signed-off-by: Xingyu Chen 
Signed-off-by: Jianxin Pan 
---
  drivers/pinctrl/meson/pinctrl-meson.c | 22 --
  1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
index 53d449076dee..7ff40cd7a0cb 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -31,6 +31,9 @@
   * In some cases the register ranges for pull enable and pull
   * direction are the same and thus there are only 3 register ranges.
   *
+ * Since Meson G12A SoC, the ao register ranges for gpio, pull enable
+ * and pull direction are the same, so there are only 2 register ranges.
+ *
   * For the pull and GPIO configuration every bank uses a contiguous
   * set of bits in the register sets described above; the same register
   * can be shared by more banks with different offsets.
@@ -487,23 +490,22 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl 
*pc,
return PTR_ERR(pc->reg_mux);
}
  
-	pc->reg_pull = meson_map_resource(pc, gpio_np, "pull");

-   if (IS_ERR(pc->reg_pull)) {
-   dev_err(pc->dev, "pull registers not found\n");
-   return PTR_ERR(pc->reg_pull);
+   pc->reg_gpio = meson_map_resource(pc, gpio_np, "gpio");
+   if (IS_ERR(pc->reg_gpio)) {
+   dev_err(pc->dev, "gpio registers not found\n");
+   return PTR_ERR(pc->reg_gpio);
}
  
+	pc->reg_pull = meson_map_resource(pc, gpio_np, "pull");

+   /* Use gpio region if pull one is not present */
+   if (IS_ERR(pc->reg_pull))
+   pc->reg_pull = pc->reg_gpio;
+
pc->reg_pullen = meson_map_resource(pc, gpio_np, "pull-enable");
/* Use pull region if pull-enable one is not present */
if (IS_ERR(pc->reg_pullen))
pc->reg_pullen = pc->reg_pull;
  
-	pc->reg_gpio = meson_map_resource(pc, gpio_np, "gpio");

-   if (IS_ERR(pc->reg_gpio)) {
-   dev_err(pc->dev, "gpio registers not found\n");
-   return PTR_ERR(pc->reg_gpio);
-   }
-
return 0;
  }
  


Doesn't it need an update of the bindings ?

Neil


Thanks, I will update it in next patch

.