Re: [PATCH] sparc64: fix fall-through annotation

2018-10-07 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Tue, 2 Oct 2018 12:19:54 +0200

> Replace "fallthru" with a proper "fall through" annotation.
> 
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH] sparc64: fix fall-through annotation

2018-10-07 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Tue, 2 Oct 2018 12:19:54 +0200

> Replace "fallthru" with a proper "fall through" annotation.
> 
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH] sparc: vdso: clean-up vdso Makefile

2018-10-07 Thread David Miller
From: Masahiro Yamada 
Date: Wed, 12 Sep 2018 12:39:13 +0900

> arch/sparc/vdso/Makefile is a replica of arch/x86/entry/vdso/Makefile.
> 
> Clean-up the Makefile in the same way as I did for x86:
> 
>  - Remove unnecessary export
>  - Put the generated linker script to $(obj)/ instead of $(src)/
>  - Simplify cmd_vdso2c
> 
> The corresponding x86 commits are:
> 
>  - 61615faf0a89 ("x86/build/vdso: Remove unnecessary export in Makefile")
>  - 1742ed2088cc ("x86/build/vdso: Put generated linker scripts to $(obj)/")
>  - c5fcdbf15523 ("x86/build/vdso: Simplify 'cmd_vdso2c'")
> 
> Signed-off-by: Masahiro Yamada 

Applied.


Re: [PATCH] sparc: vdso: clean-up vdso Makefile

2018-10-07 Thread David Miller
From: Masahiro Yamada 
Date: Wed, 12 Sep 2018 12:39:13 +0900

> arch/sparc/vdso/Makefile is a replica of arch/x86/entry/vdso/Makefile.
> 
> Clean-up the Makefile in the same way as I did for x86:
> 
>  - Remove unnecessary export
>  - Put the generated linker script to $(obj)/ instead of $(src)/
>  - Simplify cmd_vdso2c
> 
> The corresponding x86 commits are:
> 
>  - 61615faf0a89 ("x86/build/vdso: Remove unnecessary export in Makefile")
>  - 1742ed2088cc ("x86/build/vdso: Put generated linker scripts to $(obj)/")
>  - c5fcdbf15523 ("x86/build/vdso: Simplify 'cmd_vdso2c'")
> 
> Signed-off-by: Masahiro Yamada 

Applied.


Re: [PATCH] sparc32: fix fall-through annotation

2018-10-07 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Tue, 2 Oct 2018 12:15:17 +0200

> Replace "fallthru" with a proper "fall through" annotation.
> 
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH] sparc32: fix fall-through annotation

2018-10-07 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Tue, 2 Oct 2018 12:15:17 +0200

> Replace "fallthru" with a proper "fall through" annotation.
> 
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.


Re: [PATCH] oradax: remove redundant null check before kfree

2018-10-07 Thread David Miller
From: Colin King 
Date: Fri,  7 Sep 2018 11:35:00 +0100

> From: Colin Ian King 
> 
> A null check before a kfree is redundant, so remove it.
> 
> Signed-off-by: Colin Ian King 

Applied.


Re: [PATCH] sparc64: viohs: Remove VLA usage

2018-10-07 Thread David Miller
From: Kees Cook 
Date: Wed, 5 Sep 2018 15:03:51 -0700

> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates a fixed size array for the maximum number of cookies and
> adds a runtime sanity check.
> 
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1
> rq...@mail.gmail.com
> 
> Signed-off-by: Kees Cook 

Applied.


Re: [PATCH] oradax: remove redundant null check before kfree

2018-10-07 Thread David Miller
From: Colin King 
Date: Fri,  7 Sep 2018 11:35:00 +0100

> From: Colin Ian King 
> 
> A null check before a kfree is redundant, so remove it.
> 
> Signed-off-by: Colin Ian King 

Applied.


Re: [PATCH] sparc64: viohs: Remove VLA usage

2018-10-07 Thread David Miller
From: Kees Cook 
Date: Wed, 5 Sep 2018 15:03:51 -0700

> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates a fixed size array for the maximum number of cookies and
> adds a runtime sanity check.
> 
> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1
> rq...@mail.gmail.com
> 
> Signed-off-by: Kees Cook 

Applied.


Re: [PATCH v2] sparc: Convert to using %pOFn instead of device_node.name

2018-10-07 Thread David Miller
From: Rob Herring 
Date: Tue, 28 Aug 2018 10:44:32 -0500

> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
> v2:
> - snprint -> snprintf typo fix

Applied.


Re: [PATCH] sbus: Use of_get_child_by_name helper

2018-10-07 Thread David Miller
From: Rob Herring 
Date: Wed, 29 Aug 2018 15:03:37 -0500

> Use the of_get_child_by_name() helper instead of open coding searching
> for the '/options' node. This removes directly accessing the name
> pointer as well.
> 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Rob Herring 

Applied.


Re: [PATCH v2] sparc: Convert to using %pOFn instead of device_node.name

2018-10-07 Thread David Miller
From: Rob Herring 
Date: Tue, 28 Aug 2018 10:44:32 -0500

> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
> v2:
> - snprint -> snprintf typo fix

Applied.


Re: [PATCH] sbus: Use of_get_child_by_name helper

2018-10-07 Thread David Miller
From: Rob Herring 
Date: Wed, 29 Aug 2018 15:03:37 -0500

> Use the of_get_child_by_name() helper instead of open coding searching
> for the '/options' node. This removes directly accessing the name
> pointer as well.
> 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Rob Herring 

Applied.


[PATCH v11 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads

2018-10-07 Thread Alexey Budankov


Currently in record mode the tool implements trace writing serially. 
The algorithm loops over mapped per-cpu data buffers and stores 
ready data chunks into a trace file using write() system call.

At some circumstances the kernel may lack free space in a buffer 
because the other buffer's half is not yet written to disk due to 
some other buffer's data writing by the tool at the moment.

Thus serial trace writing implementation may cause the kernel 
to loose profiling data and that is what observed when profiling 
highly parallel CPU bound workloads on machines with big number 
of cores.

Experiment with profiling matrix multiplication code executing 128 
threads on Intel Xeon Phi (KNM) with 272 cores, like below,
demonstrates data loss metrics value of 98%:

/usr/bin/time perf record -o /tmp/perf-ser.data -a -N -B -T -R -g \
--call-graph dwarf,1024 --user-regs=IP,SP,BP --switch-events \
-e cycles,instructions,ref-cycles,software/period=1,name=cs,config=0x3/Duk 
-- \
matrix.gcc

Data loss metrics is the ratio lost_time/elapsed_time where 
lost_time is the sum of time intervals containing PERF_RECORD_LOST 
records and elapsed_time is the elapsed application run time 
under profiling.

Applying asynchronous trace streaming thru Posix AIO API [1] lowers 
data loss metrics value providing 2x improvement (from 98% to ~1%)

Asynchronous trace streaming is currently limited to glibc linkage.
musl libc [5] also provides Posix AIO API implementation, however 
the patchkit is not tested with it. There may be other libc libraries 
linked by Perf tool that currently lack Posix AIO API support [2], 
[3], [4] so NO_AIO define may be used to limit Perf tool binary to 
serial streaming only.

---
 Alexey Budankov (3):
perf util: map data buffer for preserving collected data
perf record: enable asynchronous trace writing
perf record: extend trace writing to multi AIO

 tools/perf/Documentation/perf-record.txt |   6 +
 tools/perf/Makefile.config   |   5 +
 tools/perf/Makefile.perf |   7 +-
 tools/perf/builtin-record.c  | 210 +--
 tools/perf/perf.h|   3 +
 tools/perf/util/evlist.c |   8 +-
 tools/perf/util/evlist.h |   2 +-
 tools/perf/util/mmap.c   | 154 ++-
 tools/perf/util/mmap.h   |  17 +++
 9 files changed, 398 insertions(+), 14 deletions(-)

---
 Changes in v11:
 - replacing the both lseek() syscalls in every loop iteration by the only 
   two syscalls just before and after the loop at record__mmap_read_evlist() 
   and advancing *in-flight* off file pos value at perf_mmap__aio_push()
 Changes in v10:
 - moved specific code to perf_mmap__aio_mmap(), perf_mmap__aio_munmap();
 - adjusted error reporting by using %m
 - avoided lseek() setting file pos back in case of record__aio_write() failure
 - compacted code selecting between serial and AIO streaming
 - optimized call places of record__mmap_read_sync()
 - added description of aio-cblocks option into perf-record.txt
 Changes in v9:
 - enable AIO streaming only when --aio-cblocks option is specified explicitly
 - enable AIO based implementation when linking with glibc only
 - define NO_AIO to limit Perf binary to serial implementation
 Changes in v8:
 - run the whole thing thru checkpatch.pl and corrected found issues except
   lines longer than 80 symbols
 - corrected comments alignment and formatting
 - moved multi AIO implementation into 3rd patch in the series
 - implemented explicit cblocks array allocation
 - split AIO completion check into separate record__aio_complete()
 - set nr_cblocks default to 1 and max allowed value to 4
 Changes in v7:
 - implemented handling record.aio setting from perfconfig file
 Changes in v6:
 - adjusted setting of priorities for cblocks;
 - handled errno == EAGAIN case from aio_write() return;
 Changes in v5:
 - resolved livelock on perf record -e intel_pt// -- dd if=/dev/zero 
of=/dev/null count=10
 - data loss metrics decreased from 25% to 2x in trialed configuration;
 - reshaped layout of data structures;
 - implemented --aio option;
 - avoided nanosleep() prior calling aio_suspend();
 - switched to per-cpu aio multi buffer record__aio_sync();
 - record_mmap_read_sync() now does global sync just before 
   switching trace file or collection stop;
 Changes in v4:
 - converted mmap()/munmap() to malloc()/free() for mmap->data buffer management
 - converted void *bf to struct perf_mmap *md in signatures
 - written comment in perf_mmap__push() just before perf_mmap__get();
 - written comment in record__mmap_read_sync() on possible restarting 
   of aio_write() operation and releasing perf_mmap object after all;
 - added perf_mmap__put() for the cases of failed aio_write();
 Changes in v3:
 - written comments about nanosleep(0.5ms) call prior aio_suspend()
   to cope with intrusiveness of its implementation in glibc;
 

Re: [PATCH v2] cpufreq: dt-platdev: allow RK3399 to have separate tunables per cluster

2018-10-07 Thread Viresh Kumar
On 05-10-18, 12:00, Dmitry Torokhov wrote:
> RK3899 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> needing separate set of tunables. Let's enable this via
> "have_governor_per_policy" platform data.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> v2 changes: commit message updated.
> 
> Not tested, but we had a patch unconditionally enabling
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> based on RK3399 platform.
> 
>  drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57de6ca..040ec0f711f9 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = 
> {
>   { .compatible = "rockchip,rk3328", },
>   { .compatible = "rockchip,rk3366", },
>   { .compatible = "rockchip,rk3368", },
> - { .compatible = "rockchip,rk3399", },
> + { .compatible = "rockchip,rk3399",
> +   .data = &(struct cpufreq_dt_platform_data)
> + { .have_governor_per_policy = true, },
> + },
>  
>   { .compatible = "st-ericsson,u8500", },
>   { .compatible = "st-ericsson,u8540", },

Acked-by: Viresh Kumar 

-- 
viresh


[PATCH v11 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads

2018-10-07 Thread Alexey Budankov


Currently in record mode the tool implements trace writing serially. 
The algorithm loops over mapped per-cpu data buffers and stores 
ready data chunks into a trace file using write() system call.

At some circumstances the kernel may lack free space in a buffer 
because the other buffer's half is not yet written to disk due to 
some other buffer's data writing by the tool at the moment.

Thus serial trace writing implementation may cause the kernel 
to loose profiling data and that is what observed when profiling 
highly parallel CPU bound workloads on machines with big number 
of cores.

Experiment with profiling matrix multiplication code executing 128 
threads on Intel Xeon Phi (KNM) with 272 cores, like below,
demonstrates data loss metrics value of 98%:

/usr/bin/time perf record -o /tmp/perf-ser.data -a -N -B -T -R -g \
--call-graph dwarf,1024 --user-regs=IP,SP,BP --switch-events \
-e cycles,instructions,ref-cycles,software/period=1,name=cs,config=0x3/Duk 
-- \
matrix.gcc

Data loss metrics is the ratio lost_time/elapsed_time where 
lost_time is the sum of time intervals containing PERF_RECORD_LOST 
records and elapsed_time is the elapsed application run time 
under profiling.

Applying asynchronous trace streaming thru Posix AIO API [1] lowers 
data loss metrics value providing 2x improvement (from 98% to ~1%)

Asynchronous trace streaming is currently limited to glibc linkage.
musl libc [5] also provides Posix AIO API implementation, however 
the patchkit is not tested with it. There may be other libc libraries 
linked by Perf tool that currently lack Posix AIO API support [2], 
[3], [4] so NO_AIO define may be used to limit Perf tool binary to 
serial streaming only.

---
 Alexey Budankov (3):
perf util: map data buffer for preserving collected data
perf record: enable asynchronous trace writing
perf record: extend trace writing to multi AIO

 tools/perf/Documentation/perf-record.txt |   6 +
 tools/perf/Makefile.config   |   5 +
 tools/perf/Makefile.perf |   7 +-
 tools/perf/builtin-record.c  | 210 +--
 tools/perf/perf.h|   3 +
 tools/perf/util/evlist.c |   8 +-
 tools/perf/util/evlist.h |   2 +-
 tools/perf/util/mmap.c   | 154 ++-
 tools/perf/util/mmap.h   |  17 +++
 9 files changed, 398 insertions(+), 14 deletions(-)

---
 Changes in v11:
 - replacing the both lseek() syscalls in every loop iteration by the only 
   two syscalls just before and after the loop at record__mmap_read_evlist() 
   and advancing *in-flight* off file pos value at perf_mmap__aio_push()
 Changes in v10:
 - moved specific code to perf_mmap__aio_mmap(), perf_mmap__aio_munmap();
 - adjusted error reporting by using %m
 - avoided lseek() setting file pos back in case of record__aio_write() failure
 - compacted code selecting between serial and AIO streaming
 - optimized call places of record__mmap_read_sync()
 - added description of aio-cblocks option into perf-record.txt
 Changes in v9:
 - enable AIO streaming only when --aio-cblocks option is specified explicitly
 - enable AIO based implementation when linking with glibc only
 - define NO_AIO to limit Perf binary to serial implementation
 Changes in v8:
 - run the whole thing thru checkpatch.pl and corrected found issues except
   lines longer than 80 symbols
 - corrected comments alignment and formatting
 - moved multi AIO implementation into 3rd patch in the series
 - implemented explicit cblocks array allocation
 - split AIO completion check into separate record__aio_complete()
 - set nr_cblocks default to 1 and max allowed value to 4
 Changes in v7:
 - implemented handling record.aio setting from perfconfig file
 Changes in v6:
 - adjusted setting of priorities for cblocks;
 - handled errno == EAGAIN case from aio_write() return;
 Changes in v5:
 - resolved livelock on perf record -e intel_pt// -- dd if=/dev/zero 
of=/dev/null count=10
 - data loss metrics decreased from 25% to 2x in trialed configuration;
 - reshaped layout of data structures;
 - implemented --aio option;
 - avoided nanosleep() prior calling aio_suspend();
 - switched to per-cpu aio multi buffer record__aio_sync();
 - record_mmap_read_sync() now does global sync just before 
   switching trace file or collection stop;
 Changes in v4:
 - converted mmap()/munmap() to malloc()/free() for mmap->data buffer management
 - converted void *bf to struct perf_mmap *md in signatures
 - written comment in perf_mmap__push() just before perf_mmap__get();
 - written comment in record__mmap_read_sync() on possible restarting 
   of aio_write() operation and releasing perf_mmap object after all;
 - added perf_mmap__put() for the cases of failed aio_write();
 Changes in v3:
 - written comments about nanosleep(0.5ms) call prior aio_suspend()
   to cope with intrusiveness of its implementation in glibc;
 

Re: [PATCH v2] cpufreq: dt-platdev: allow RK3399 to have separate tunables per cluster

2018-10-07 Thread Viresh Kumar
On 05-10-18, 12:00, Dmitry Torokhov wrote:
> RK3899 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> needing separate set of tunables. Let's enable this via
> "have_governor_per_policy" platform data.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> v2 changes: commit message updated.
> 
> Not tested, but we had a patch unconditionally enabling
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> based on RK3399 platform.
> 
>  drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57de6ca..040ec0f711f9 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = 
> {
>   { .compatible = "rockchip,rk3328", },
>   { .compatible = "rockchip,rk3366", },
>   { .compatible = "rockchip,rk3368", },
> - { .compatible = "rockchip,rk3399", },
> + { .compatible = "rockchip,rk3399",
> +   .data = &(struct cpufreq_dt_platform_data)
> + { .have_governor_per_policy = true, },
> + },
>  
>   { .compatible = "st-ericsson,u8500", },
>   { .compatible = "st-ericsson,u8540", },

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH 01/13] clocksource: Convert to using %pOFn instead of device_node.name

2018-10-07 Thread Michal Simek
On 5.10.2018 16:35, Daniel Lezcano wrote:
> From: Rob Herring 
> 
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: Daniel Lezcano 
> Cc: Thomas Gleixner 
> Cc: Michal Simek 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Rob Herring 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/clocksource/asm9260_timer.c   | 2 +-
>  drivers/clocksource/cadence_ttc_timer.c   | 2 +-

Acked-by: Michal Simek 

Thanks,
Michal


Re: [PATCH 01/13] clocksource: Convert to using %pOFn instead of device_node.name

2018-10-07 Thread Michal Simek
On 5.10.2018 16:35, Daniel Lezcano wrote:
> From: Rob Herring 
> 
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: Daniel Lezcano 
> Cc: Thomas Gleixner 
> Cc: Michal Simek 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Rob Herring 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/clocksource/asm9260_timer.c   | 2 +-
>  drivers/clocksource/cadence_ttc_timer.c   | 2 +-

Acked-by: Michal Simek 

Thanks,
Michal


Re: linux-next: build failure after merge of the crypto tree

2018-10-07 Thread Herbert Xu
On Mon, Oct 08, 2018 at 12:03:30PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "crypto_fpu_exit" [arch/x86/crypto/aesni-intel.ko] undefined!
> ERROR: "crypto_fpu_init" [arch/x86/crypto/aesni-intel.ko] undefined!
> 
> Caused by commit
> 
>   944585a64f5e ("crypto: x86/aes-ni - remove special handling of AES in PCBC 
> mode")
> 
> I have used the version of the crypto tree from next-20181005 for today.

Thanks Stephen.  It should be fixed in cryptodev now by:

https://patchwork.kernel.org/patch/10628511/

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: linux-next: build failure after merge of the crypto tree

2018-10-07 Thread Herbert Xu
On Mon, Oct 08, 2018 at 12:03:30PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "crypto_fpu_exit" [arch/x86/crypto/aesni-intel.ko] undefined!
> ERROR: "crypto_fpu_init" [arch/x86/crypto/aesni-intel.ko] undefined!
> 
> Caused by commit
> 
>   944585a64f5e ("crypto: x86/aes-ni - remove special handling of AES in PCBC 
> mode")
> 
> I have used the version of the crypto tree from next-20181005 for today.

Thanks Stephen.  It should be fixed in cryptodev now by:

https://patchwork.kernel.org/patch/10628511/

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH v2 2/2] PCI: controller: dwc: add UniPhier PCIe host controller support

2018-10-07 Thread Kishon Vijay Abraham I
Hi Lorenzo,

On Friday 28 September 2018 09:13 PM, Lorenzo Pieralisi wrote:
> On Fri, Sep 28, 2018 at 02:17:16PM +0100, Marc Zyngier wrote:
>> On 28/09/18 12:06, Lorenzo Pieralisi wrote:
>>> [+Murali, Marc]
>>>
>>> On Thu, Sep 27, 2018 at 04:44:26PM +0900, Kunihiko Hayashi wrote:
 Hi Lorenzo, Gustavo,

 On Wed, 26 Sep 2018 21:31:36 +0900  wrote:

> Hi Lorenzo, Gustavo,
>
> Thank you for reviewing.
>
> On Tue, 25 Sep 2018 18:53:01 +0100
> Gustavo Pimentel  wrote:
>
>> On 25/09/2018 17:14, Lorenzo Pieralisi wrote:
>>> [+Gustavo, please have a look at INTX/MSI management]
>>>
>>> On Thu, Sep 06, 2018 at 06:40:32PM +0900, Kunihiko Hayashi wrote:
 This introduces specific glue layer for UniPhier platform to support
 PCIe host controller that is based on the DesignWare PCIe core, and
 this driver supports Root Complex (host) mode.
>>>
>>> Please read this thread and apply it to next versions:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlinux-2Dpci-26m-3D150905742808166-26w-3D2=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=bkWxpLoW-f-E3EdiDCCa0_h0PicsViasSlvIpzZvPxs=H8UNDDUGQnQnqfWr4CBios689dJcjxu4qeTTRGulLmU=CgcXc_2LThyOpW-4bCriJNo9H1lzROEdy_cG9p-Y5hU=
>
> I also found this thread in previous linux-pci, and I think it's helpful 
> for me.
> I'll check it carefully.

 [snip]

 +  ret = devm_request_irq(dev, pp->irq, uniphier_pcie_irq_handler,
 + IRQF_SHARED, "pcie", priv);
>>>
>>> This is wrong, you should set-up a chained IRQ for INTX.
>>>
>>> I *think* that
>>>
>>> ks_pcie_setup_interrupts()
>>>
>>> is a good example to start with but I wonder whether it is worth
>>> generalizing the INTX approach to designware as a whole as it was
>>> done for MSIs.
>>>
>>> Thoughts ?
>>
>> From what I understood this is for legacy IRQ, right?
>
> Yes. For legacy IRQ.
>
>> Like you (Lorenzo) said there is 2 drivers (pci-keystone-dw.c and 
>> pci-dra7xx.c)
>> that uses it and can be use as a template for handling this type of 
>> interrupts.
>>
>> We can try to pass some kind of generic INTX function to the DesignWare 
>> host
>> library to handling this, but this will require some help from keystone 
>> and
>> dra7xx maintainers, since my setup doesn't have legacy IRQ HW support.
>
> Now I think it's difficult to make a template for INTX function,
> and at first, I'll try to re-write this part with reference to 
> pci-keystone-dw.c.

 I understand that there are 2 types of interrupt and the drivers.

 One like pci-keystone-dw.c is:

  - there are 4 interrupts for legacy,
  - invoke handlers for each interrupt, and handle the interrupt,
  - call irq_set_chained_handler_and_data() to make a chain of the 
 interrupts
   when initializing

 The other like pci-dra7xx.c is:

  - there is 1 IRQ for legacy as a parent,
  - check an interrupt factor register, and handle the interrupt correspond
to the factor,
  - call request_irq() for the parent IRQ and irq_domain_add_linear() for
the factor when initializing

 The pcie-uniphier.c is the same type as the latter (like pci-dra7xx.c).

 However, in pci-dra7xx.c, MSI and legacy IRQ share the same interrupt 
 number,
 so the same handler is called and the handler divides these IRQs.
 (found in dra7xx_pcie_msi_irq_handler())

 In pcie-uniphier.c, MSI and legacy IRQ are independent.
 Therefore it's necessary to prepare the handler for the legacy IRQ.

 I think that it's difficult to apply the way of pci-keystone-dw.c, and
 uniphier_pcie_irq_handler() and calling devm_request_irq() are still
 necessary to handle legacy IRQ.
>>>
>>> I do not think it is difficult, the difference is that keystone has
>>> 1 GIC irq line allocated per legacy IRQ, your set-up has one for
>>> all INTX.
>>>
>>> *However*, I would like some clarifications from Murali on this code
>>> in drivers/pci/controller/dwc/pci-keystone.c:
>>>
>>> static void ks_pcie_legacy_irq_handler(struct irq_desc *desc)
>>> {
>>> unsigned int irq = irq_desc_get_irq(desc);
>>> struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc);
>>> struct dw_pcie *pci = ks_pcie->pci;
>>> struct device *dev = pci->dev;
>>> u32 irq_offset = irq - ks_pcie->legacy_host_irqs[0];
>>>
>>> Here the IRQ numbers are virtual IRQs, is it correct to consider
>>> the virq numbers as sequential values ? The "offset" is used to
>>> handle the PCI controller interrupt registers, so it must be a value
>>> between 0-3 IIUC.
>>
>> There is absolutely no reason why virtual interrupt numbers should be
>> contiguous. Shake the allocator hard enough, and you'll see gaps appearing.
>>
>> In general, the 

Re: [PATCH v2 2/2] PCI: controller: dwc: add UniPhier PCIe host controller support

2018-10-07 Thread Kishon Vijay Abraham I
Hi Lorenzo,

On Friday 28 September 2018 09:13 PM, Lorenzo Pieralisi wrote:
> On Fri, Sep 28, 2018 at 02:17:16PM +0100, Marc Zyngier wrote:
>> On 28/09/18 12:06, Lorenzo Pieralisi wrote:
>>> [+Murali, Marc]
>>>
>>> On Thu, Sep 27, 2018 at 04:44:26PM +0900, Kunihiko Hayashi wrote:
 Hi Lorenzo, Gustavo,

 On Wed, 26 Sep 2018 21:31:36 +0900  wrote:

> Hi Lorenzo, Gustavo,
>
> Thank you for reviewing.
>
> On Tue, 25 Sep 2018 18:53:01 +0100
> Gustavo Pimentel  wrote:
>
>> On 25/09/2018 17:14, Lorenzo Pieralisi wrote:
>>> [+Gustavo, please have a look at INTX/MSI management]
>>>
>>> On Thu, Sep 06, 2018 at 06:40:32PM +0900, Kunihiko Hayashi wrote:
 This introduces specific glue layer for UniPhier platform to support
 PCIe host controller that is based on the DesignWare PCIe core, and
 this driver supports Root Complex (host) mode.
>>>
>>> Please read this thread and apply it to next versions:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlinux-2Dpci-26m-3D150905742808166-26w-3D2=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=bkWxpLoW-f-E3EdiDCCa0_h0PicsViasSlvIpzZvPxs=H8UNDDUGQnQnqfWr4CBios689dJcjxu4qeTTRGulLmU=CgcXc_2LThyOpW-4bCriJNo9H1lzROEdy_cG9p-Y5hU=
>
> I also found this thread in previous linux-pci, and I think it's helpful 
> for me.
> I'll check it carefully.

 [snip]

 +  ret = devm_request_irq(dev, pp->irq, uniphier_pcie_irq_handler,
 + IRQF_SHARED, "pcie", priv);
>>>
>>> This is wrong, you should set-up a chained IRQ for INTX.
>>>
>>> I *think* that
>>>
>>> ks_pcie_setup_interrupts()
>>>
>>> is a good example to start with but I wonder whether it is worth
>>> generalizing the INTX approach to designware as a whole as it was
>>> done for MSIs.
>>>
>>> Thoughts ?
>>
>> From what I understood this is for legacy IRQ, right?
>
> Yes. For legacy IRQ.
>
>> Like you (Lorenzo) said there is 2 drivers (pci-keystone-dw.c and 
>> pci-dra7xx.c)
>> that uses it and can be use as a template for handling this type of 
>> interrupts.
>>
>> We can try to pass some kind of generic INTX function to the DesignWare 
>> host
>> library to handling this, but this will require some help from keystone 
>> and
>> dra7xx maintainers, since my setup doesn't have legacy IRQ HW support.
>
> Now I think it's difficult to make a template for INTX function,
> and at first, I'll try to re-write this part with reference to 
> pci-keystone-dw.c.

 I understand that there are 2 types of interrupt and the drivers.

 One like pci-keystone-dw.c is:

  - there are 4 interrupts for legacy,
  - invoke handlers for each interrupt, and handle the interrupt,
  - call irq_set_chained_handler_and_data() to make a chain of the 
 interrupts
   when initializing

 The other like pci-dra7xx.c is:

  - there is 1 IRQ for legacy as a parent,
  - check an interrupt factor register, and handle the interrupt correspond
to the factor,
  - call request_irq() for the parent IRQ and irq_domain_add_linear() for
the factor when initializing

 The pcie-uniphier.c is the same type as the latter (like pci-dra7xx.c).

 However, in pci-dra7xx.c, MSI and legacy IRQ share the same interrupt 
 number,
 so the same handler is called and the handler divides these IRQs.
 (found in dra7xx_pcie_msi_irq_handler())

 In pcie-uniphier.c, MSI and legacy IRQ are independent.
 Therefore it's necessary to prepare the handler for the legacy IRQ.

 I think that it's difficult to apply the way of pci-keystone-dw.c, and
 uniphier_pcie_irq_handler() and calling devm_request_irq() are still
 necessary to handle legacy IRQ.
>>>
>>> I do not think it is difficult, the difference is that keystone has
>>> 1 GIC irq line allocated per legacy IRQ, your set-up has one for
>>> all INTX.
>>>
>>> *However*, I would like some clarifications from Murali on this code
>>> in drivers/pci/controller/dwc/pci-keystone.c:
>>>
>>> static void ks_pcie_legacy_irq_handler(struct irq_desc *desc)
>>> {
>>> unsigned int irq = irq_desc_get_irq(desc);
>>> struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc);
>>> struct dw_pcie *pci = ks_pcie->pci;
>>> struct device *dev = pci->dev;
>>> u32 irq_offset = irq - ks_pcie->legacy_host_irqs[0];
>>>
>>> Here the IRQ numbers are virtual IRQs, is it correct to consider
>>> the virq numbers as sequential values ? The "offset" is used to
>>> handle the PCI controller interrupt registers, so it must be a value
>>> between 0-3 IIUC.
>>
>> There is absolutely no reason why virtual interrupt numbers should be
>> contiguous. Shake the allocator hard enough, and you'll see gaps appearing.
>>
>> In general, the 

linux-next: manual merge of the kspp tree with the tip tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  Documentation/x86/x86_64/mm.txt

between commits:

  5b1290406579 ("x86/mm/doc: Clean up the x86-64 virtual memory layout 
descriptions")
  32b89760ddf4 ("x86/mm/doc: Enhance the x86-64 virtual memory layout 
descriptions")

from the tip tree and commit:

  afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end 
of syscalls")

from the kspp tree.

I fixed it up (see below - could probably be done better) 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 Documentation/x86/x86_64/mm.txt
index 702898633b00,600bc2afa27d..
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@@ -1,124 -1,57 +1,126 @@@
 +
 +Complete virtual memory map with 4-level page tables
 +
  
 -Virtual memory map with 4 level page tables:
 -
 - - 7fff (=47 bits) user space, different per mm
 -hole caused by [47:63] sign extension
 -8000 - 87ff (=43 bits) guard hole, reserved for 
hypervisor
 -8800 - c7ff (=64 TB) direct mapping of all phys. 
memory
 -c800 - c8ff (=40 bits) hole
 -c900 - e8ff (=45 bits) vmalloc/ioremap space
 -e900 - e9ff (=40 bits) hole
 -ea00 - eaff (=40 bits) virtual memory map (1TB)
 -... unused hole ...
 -ec00 - fbff (=44 bits) kasan shadow memory (16TB)
 -... unused hole ...
 -  vaddr_end for KASLR
 -fe00 - fe7f (=39 bits) cpu_entry_area mapping
 -fe80 - feff (=39 bits) LDT remap for PTI
 -ff00 - ff7f (=39 bits) %esp fixup stacks
 -... unused hole ...
 -ffef - fffe (=64 GB) EFI region mapping space
 -... unused hole ...
 -8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
 -a000 - feff (1520 MB) module mapping space
 -[fixmap start]   - ff5f kernel-internal fixmap range
 -ff60 - ff600fff (=4 kB) legacy vsyscall ABI
 -ffe0 -  (=2 MB) unused hole
 +Notes:
 +
 + - Negative addresses such as "-23 TB" are absolute addresses in bytes, 
counted down
 +   from the top of the 64-bit address space. It's easier to understand the 
layout
 +   when seen both in absolute addresses and in distance-from-top notation.
 +
 +   For example 0xe900 == -23 TB, it's 23 TB lower than the top of 
the
 +   64-bit address space ().
 +
 +   Note that as we get closer to the top of the address space, the notation 
changes
 +   from TB to GB and then MB/KB.
 +
 + - "16M TB" might look weird at first sight, but it's an easier to visualize 
size
 +   notation than "16 EB", which few will recognize at first sight as 16 
exabytes.
 +   It also shows it nicely how incredibly large 64-bit address space is.
 +
 
+
 +Start addr|   Offset   | End addr |  Size   | VM area 
description
 
+
 +  ||  | |
 +  |0   | 7fff |  128 TB | user-space 
virtual memory, different per mm
 
+__||__|_|___
 +  ||  | |
 + 8000 | +128TB | 7fff | ~16M TB | ... huge, 
almost 64 bits wide hole of non-canonical
 +  ||  | | virtual 
memory addresses up to the -128 TB
 +  ||  | | starting 
offset of kernel mappings.
 
+__||__|_|___
 +|
 +| Kernel-space 
virtual memory, shared between all processes:
 
+|___
 +  ||  | |
 + 8000 | -128TB 

linux-next: manual merge of the kspp tree with the tip tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  Documentation/x86/x86_64/mm.txt

between commits:

  5b1290406579 ("x86/mm/doc: Clean up the x86-64 virtual memory layout 
descriptions")
  32b89760ddf4 ("x86/mm/doc: Enhance the x86-64 virtual memory layout 
descriptions")

from the tip tree and commit:

  afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end 
of syscalls")

from the kspp tree.

I fixed it up (see below - could probably be done better) 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 Documentation/x86/x86_64/mm.txt
index 702898633b00,600bc2afa27d..
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@@ -1,124 -1,57 +1,126 @@@
 +
 +Complete virtual memory map with 4-level page tables
 +
  
 -Virtual memory map with 4 level page tables:
 -
 - - 7fff (=47 bits) user space, different per mm
 -hole caused by [47:63] sign extension
 -8000 - 87ff (=43 bits) guard hole, reserved for 
hypervisor
 -8800 - c7ff (=64 TB) direct mapping of all phys. 
memory
 -c800 - c8ff (=40 bits) hole
 -c900 - e8ff (=45 bits) vmalloc/ioremap space
 -e900 - e9ff (=40 bits) hole
 -ea00 - eaff (=40 bits) virtual memory map (1TB)
 -... unused hole ...
 -ec00 - fbff (=44 bits) kasan shadow memory (16TB)
 -... unused hole ...
 -  vaddr_end for KASLR
 -fe00 - fe7f (=39 bits) cpu_entry_area mapping
 -fe80 - feff (=39 bits) LDT remap for PTI
 -ff00 - ff7f (=39 bits) %esp fixup stacks
 -... unused hole ...
 -ffef - fffe (=64 GB) EFI region mapping space
 -... unused hole ...
 -8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
 -a000 - feff (1520 MB) module mapping space
 -[fixmap start]   - ff5f kernel-internal fixmap range
 -ff60 - ff600fff (=4 kB) legacy vsyscall ABI
 -ffe0 -  (=2 MB) unused hole
 +Notes:
 +
 + - Negative addresses such as "-23 TB" are absolute addresses in bytes, 
counted down
 +   from the top of the 64-bit address space. It's easier to understand the 
layout
 +   when seen both in absolute addresses and in distance-from-top notation.
 +
 +   For example 0xe900 == -23 TB, it's 23 TB lower than the top of 
the
 +   64-bit address space ().
 +
 +   Note that as we get closer to the top of the address space, the notation 
changes
 +   from TB to GB and then MB/KB.
 +
 + - "16M TB" might look weird at first sight, but it's an easier to visualize 
size
 +   notation than "16 EB", which few will recognize at first sight as 16 
exabytes.
 +   It also shows it nicely how incredibly large 64-bit address space is.
 +
 
+
 +Start addr|   Offset   | End addr |  Size   | VM area 
description
 
+
 +  ||  | |
 +  |0   | 7fff |  128 TB | user-space 
virtual memory, different per mm
 
+__||__|_|___
 +  ||  | |
 + 8000 | +128TB | 7fff | ~16M TB | ... huge, 
almost 64 bits wide hole of non-canonical
 +  ||  | | virtual 
memory addresses up to the -128 TB
 +  ||  | | starting 
offset of kernel mappings.
 
+__||__|_|___
 +|
 +| Kernel-space 
virtual memory, shared between all processes:
 
+|___
 +  ||  | |
 + 8000 | -128TB 

Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread Borislav Petkov
On Mon, Oct 08, 2018 at 11:30:56AM +0800, lijiang wrote:
> Yes. As previously mentioned, the correct patch is this one:

No, that chunk is not needed and I removed it. But I'd leave it as
an exercise to you to figure out why... or to prove me wrong with a
.config.

:-)

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread Borislav Petkov
On Mon, Oct 08, 2018 at 11:30:56AM +0800, lijiang wrote:
> Yes. As previously mentioned, the correct patch is this one:

No, that chunk is not needed and I removed it. But I'd leave it as
an exercise to you to figure out why... or to prove me wrong with a
.config.

:-)

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [PATCH] s390/qeth: fix a missing-check bug

2018-10-07 Thread Heiko Carstens
On Sat, Oct 06, 2018 at 11:08:23AM -0500, Wenwen Wang wrote:
> In qeth_snmp_command(), the length of the user request is firstly copied
> from the user-space buffer 'udata' to the kernel variable 'req_len' and
> checked to see whether it is too large. If the check fails, an error code
> EINVAL is returned. Otherwise, the execution continues and the whole buffer
> is copied again from 'udata' and saved to the kernel buffer 'ureq'.
> However, after the second copy, no re-check is enforced on the newly-copied
> request length. Given that the buffer 'udata' is in the user space, a
> malicious user can race to change the request length between the two
> copies. In this way, the attacker can supply malicious data to the kernel
> and cause undefined behavior.
> 
> This patch adds a re-check on the request length after the second copy from
> the buffer 'udata'. If the newly-copied value is different from the value
> obtained in the first copy, i.e., 'req_len', an error code EINVAL will be
> returned after the buffer 'ureq' is freed.
> 
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/s390/net/qeth_core_main.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/s390/net/qeth_core_main.c 
> b/drivers/s390/net/qeth_core_main.c
> index de82824..6199743 100644
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -4613,6 +4613,10 @@ static int qeth_snmp_command(struct qeth_card *card, 
> char __user *udata)
>   QETH_CARD_TEXT(card, 2, "snmpnome");
>   return PTR_ERR(ureq);
>   }
> + if (ureq->hdr.req_len != req_len) {
> + kfree(ureq);
> + return -EINVAL;
> + }

ureq->hdr.req_len is not used anywhere in the code, so could you please
explain what the undefined behavior is?

You could argue that adding a second sanity check may help to avoid
potential future bugs, but currently the code looks sane to me.



Re: [PATCH] s390/qeth: fix a missing-check bug

2018-10-07 Thread Heiko Carstens
On Sat, Oct 06, 2018 at 11:08:23AM -0500, Wenwen Wang wrote:
> In qeth_snmp_command(), the length of the user request is firstly copied
> from the user-space buffer 'udata' to the kernel variable 'req_len' and
> checked to see whether it is too large. If the check fails, an error code
> EINVAL is returned. Otherwise, the execution continues and the whole buffer
> is copied again from 'udata' and saved to the kernel buffer 'ureq'.
> However, after the second copy, no re-check is enforced on the newly-copied
> request length. Given that the buffer 'udata' is in the user space, a
> malicious user can race to change the request length between the two
> copies. In this way, the attacker can supply malicious data to the kernel
> and cause undefined behavior.
> 
> This patch adds a re-check on the request length after the second copy from
> the buffer 'udata'. If the newly-copied value is different from the value
> obtained in the first copy, i.e., 'req_len', an error code EINVAL will be
> returned after the buffer 'ureq' is freed.
> 
> Signed-off-by: Wenwen Wang 
> ---
>  drivers/s390/net/qeth_core_main.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/s390/net/qeth_core_main.c 
> b/drivers/s390/net/qeth_core_main.c
> index de82824..6199743 100644
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -4613,6 +4613,10 @@ static int qeth_snmp_command(struct qeth_card *card, 
> char __user *udata)
>   QETH_CARD_TEXT(card, 2, "snmpnome");
>   return PTR_ERR(ureq);
>   }
> + if (ureq->hdr.req_len != req_len) {
> + kfree(ureq);
> + return -EINVAL;
> + }

ureq->hdr.req_len is not used anywhere in the code, so could you please
explain what the undefined behavior is?

You could argue that adding a second sanity check may help to avoid
potential future bugs, but currently the code looks sane to me.



linux-next: manual merge of the staging tree with the v4l-dvb tree

2018-10-07 Thread Stephen Rothwell
Hi Greg,

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

  drivers/staging/media/imx/imx-media-of.c

between commit:

  21711787045d ("media: staging/imx: of: Remove recursive graph walk")

from the v4l-dvb tree and commit:

  f93861c2d611 ("staging: Convert to using %pOFn instead of device_node.name")

from the staging 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 drivers/staging/media/imx/imx-media-of.c
index 1c9175433ba6,163437e421c5..
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@@ -20,13 -20,67 +20,13 @@@
  #include 
  #include "imx-media.h"
  
 -static int of_get_port_count(const struct device_node *np)
 +static int of_add_csi(struct imx_media_dev *imxmd, struct device_node *csi_np)
  {
 -  struct device_node *ports, *child;
 -  int num = 0;
 +  int ret;
  
 -  /* check if this node has a ports subnode */
 -  ports = of_get_child_by_name(np, "ports");
 -  if (ports)
 -  np = ports;
 -
 -  for_each_child_of_node(np, child)
 -  if (of_node_cmp(child->name, "port") == 0)
 -  num++;
 -
 -  of_node_put(ports);
 -  return num;
 -}
 -
 -/*
 - * find the remote device node given local endpoint node
 - */
 -static bool of_get_remote(struct device_node *epnode,
 -struct device_node **remote_node)
 -{
 -  struct device_node *rp, *rpp;
 -  struct device_node *remote;
 -  bool is_csi_port;
 -
 -  rp = of_graph_get_remote_port(epnode);
 -  rpp = of_graph_get_remote_port_parent(epnode);
 -
 -  if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
 -  /* the remote is one of the CSI ports */
 -  remote = rp;
 -  of_node_put(rpp);
 -  is_csi_port = true;
 -  } else {
 -  remote = rpp;
 -  of_node_put(rp);
 -  is_csi_port = false;
 -  }
 -
 -  if (!of_device_is_available(remote)) {
 -  of_node_put(remote);
 -  *remote_node = NULL;
 -  } else {
 -  *remote_node = remote;
 -  }
 -
 -  return is_csi_port;
 -}
 -
 -static int
 -of_parse_subdev(struct imx_media_dev *imxmd, struct device_node *sd_np,
 -  bool is_csi_port)
 -{
 -  int i, num_ports, ret;
 -
 -  if (!of_device_is_available(sd_np)) {
 +  if (!of_device_is_available(csi_np)) {
-   dev_dbg(imxmd->md.dev, "%s: %s not enabled\n", __func__,
-   csi_np->name);
+   dev_dbg(imxmd->md.dev, "%s: %pOFn not enabled\n", __func__,
 -  sd_np);
++  csi_np);
/* unavailable is not an error */
return 0;
}


pgpOaM9nKz71r.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the staging tree with the v4l-dvb tree

2018-10-07 Thread Stephen Rothwell
Hi Greg,

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

  drivers/staging/media/imx/imx-media-of.c

between commit:

  21711787045d ("media: staging/imx: of: Remove recursive graph walk")

from the v4l-dvb tree and commit:

  f93861c2d611 ("staging: Convert to using %pOFn instead of device_node.name")

from the staging 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 drivers/staging/media/imx/imx-media-of.c
index 1c9175433ba6,163437e421c5..
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@@ -20,13 -20,67 +20,13 @@@
  #include 
  #include "imx-media.h"
  
 -static int of_get_port_count(const struct device_node *np)
 +static int of_add_csi(struct imx_media_dev *imxmd, struct device_node *csi_np)
  {
 -  struct device_node *ports, *child;
 -  int num = 0;
 +  int ret;
  
 -  /* check if this node has a ports subnode */
 -  ports = of_get_child_by_name(np, "ports");
 -  if (ports)
 -  np = ports;
 -
 -  for_each_child_of_node(np, child)
 -  if (of_node_cmp(child->name, "port") == 0)
 -  num++;
 -
 -  of_node_put(ports);
 -  return num;
 -}
 -
 -/*
 - * find the remote device node given local endpoint node
 - */
 -static bool of_get_remote(struct device_node *epnode,
 -struct device_node **remote_node)
 -{
 -  struct device_node *rp, *rpp;
 -  struct device_node *remote;
 -  bool is_csi_port;
 -
 -  rp = of_graph_get_remote_port(epnode);
 -  rpp = of_graph_get_remote_port_parent(epnode);
 -
 -  if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
 -  /* the remote is one of the CSI ports */
 -  remote = rp;
 -  of_node_put(rpp);
 -  is_csi_port = true;
 -  } else {
 -  remote = rpp;
 -  of_node_put(rp);
 -  is_csi_port = false;
 -  }
 -
 -  if (!of_device_is_available(remote)) {
 -  of_node_put(remote);
 -  *remote_node = NULL;
 -  } else {
 -  *remote_node = remote;
 -  }
 -
 -  return is_csi_port;
 -}
 -
 -static int
 -of_parse_subdev(struct imx_media_dev *imxmd, struct device_node *sd_np,
 -  bool is_csi_port)
 -{
 -  int i, num_ports, ret;
 -
 -  if (!of_device_is_available(sd_np)) {
 +  if (!of_device_is_available(csi_np)) {
-   dev_dbg(imxmd->md.dev, "%s: %s not enabled\n", __func__,
-   csi_np->name);
+   dev_dbg(imxmd->md.dev, "%s: %pOFn not enabled\n", __func__,
 -  sd_np);
++  csi_np);
/* unavailable is not an error */
return 0;
}


pgpOaM9nKz71r.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the staging tree with the v4l-dvb tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/staging/media/imx/imx-media-dev.c

between commit:

  b803cd359833 ("media: staging/imx: Switch to 
v4l2_async_notifier_add_*_subdev")

from the v4l-dvb tree and commit:

  f93861c2d611 ("staging: Convert to using %pOFn instead of device_node.name")

from the staging 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 drivers/staging/media/imx/imx-media-dev.c
index 481840195071,3f48f5ceb6ea..
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@@ -47,34 -80,52 +47,43 @@@ int imx_media_add_async_subdev(struct i
struct imx_media_async_subdev *imxasd;
struct v4l2_async_subdev *asd;
const char *devname = NULL;
 -  int ret = 0;
 -
 -  mutex_lock(>mutex);
 +  int ret;
  
 -  if (pdev)
 +  if (fwnode) {
 +  asd = v4l2_async_notifier_add_fwnode_subdev(
 +  >notifier, fwnode, sizeof(*imxasd));
 +  } else {
devname = dev_name(>dev);
 -
 -  /* return -EEXIST if this asd already added */
 -  if (find_async_subdev(imxmd, fwnode, devname)) {
 -  if (np)
 -  dev_dbg(imxmd->md.dev, "%s: already added %pOFn\n",
 -  __func__, np);
 -  else
 -  dev_dbg(imxmd->md.dev, "%s: already added %s\n",
 -  __func__, devname);
 -  ret = -EEXIST;
 -  goto out;
 +  asd = v4l2_async_notifier_add_devname_subdev(
 +  >notifier, devname, sizeof(*imxasd));
}
  
 -  imxasd = devm_kzalloc(imxmd->md.dev, sizeof(*imxasd), GFP_KERNEL);
 -  if (!imxasd) {
 -  ret = -ENOMEM;
 -  goto out;
 +  if (IS_ERR(asd)) {
 +  ret = PTR_ERR(asd);
-   if (ret == -EEXIST)
-   dev_dbg(imxmd->md.dev, "%s: already added %s\n",
-   __func__, np ? np->name : devname);
++  if (ret == -EEXIST) {
++  if (np)
++  dev_dbg(imxmd->md.dev, "%s: already added 
%pOFn\n",
++  __func__, np);
++  else
++  dev_dbg(imxmd->md.dev, "%s: already added %s\n",
++  __func__, devname);
++  }
 +  return ret;
}
 -  asd = >asd;
  
 -  if (fwnode) {
 -  asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
 -  asd->match.fwnode = fwnode;
 +  imxasd = to_imx_media_asd(asd);
 +
 +  if (devname)
 +  imxasd->pdev = pdev;
 +
-   dev_dbg(imxmd->md.dev, "%s: added %s, match type %s\n",
-   __func__, np ? np->name : devname, np ? "FWNODE" : "DEVNAME");
++  if (fwnode)
+   dev_dbg(imxmd->md.dev, "%s: added %pOFn, match type FWNODE\n",
+   __func__, np);
 -  } else {
 -  asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
 -  asd->match.device_name = devname;
 -  imxasd->pdev = pdev;
++  else
+   dev_dbg(imxmd->md.dev, "%s: added %s, match type DEVNAME\n",
+   __func__, devname);
 -  }
 -
 -  list_add_tail(>list, >asd_list);
 -
 -  imxmd->subdev_notifier.num_subdevs++;
  
 -out:
 -  mutex_unlock(>mutex);
 -  return ret;
 +  return 0;
  }
  
  /*


pgpdcZlEw11x4.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the staging tree with the v4l-dvb tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/staging/media/imx/imx-media-dev.c

between commit:

  b803cd359833 ("media: staging/imx: Switch to 
v4l2_async_notifier_add_*_subdev")

from the v4l-dvb tree and commit:

  f93861c2d611 ("staging: Convert to using %pOFn instead of device_node.name")

from the staging 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 drivers/staging/media/imx/imx-media-dev.c
index 481840195071,3f48f5ceb6ea..
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@@ -47,34 -80,52 +47,43 @@@ int imx_media_add_async_subdev(struct i
struct imx_media_async_subdev *imxasd;
struct v4l2_async_subdev *asd;
const char *devname = NULL;
 -  int ret = 0;
 -
 -  mutex_lock(>mutex);
 +  int ret;
  
 -  if (pdev)
 +  if (fwnode) {
 +  asd = v4l2_async_notifier_add_fwnode_subdev(
 +  >notifier, fwnode, sizeof(*imxasd));
 +  } else {
devname = dev_name(>dev);
 -
 -  /* return -EEXIST if this asd already added */
 -  if (find_async_subdev(imxmd, fwnode, devname)) {
 -  if (np)
 -  dev_dbg(imxmd->md.dev, "%s: already added %pOFn\n",
 -  __func__, np);
 -  else
 -  dev_dbg(imxmd->md.dev, "%s: already added %s\n",
 -  __func__, devname);
 -  ret = -EEXIST;
 -  goto out;
 +  asd = v4l2_async_notifier_add_devname_subdev(
 +  >notifier, devname, sizeof(*imxasd));
}
  
 -  imxasd = devm_kzalloc(imxmd->md.dev, sizeof(*imxasd), GFP_KERNEL);
 -  if (!imxasd) {
 -  ret = -ENOMEM;
 -  goto out;
 +  if (IS_ERR(asd)) {
 +  ret = PTR_ERR(asd);
-   if (ret == -EEXIST)
-   dev_dbg(imxmd->md.dev, "%s: already added %s\n",
-   __func__, np ? np->name : devname);
++  if (ret == -EEXIST) {
++  if (np)
++  dev_dbg(imxmd->md.dev, "%s: already added 
%pOFn\n",
++  __func__, np);
++  else
++  dev_dbg(imxmd->md.dev, "%s: already added %s\n",
++  __func__, devname);
++  }
 +  return ret;
}
 -  asd = >asd;
  
 -  if (fwnode) {
 -  asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
 -  asd->match.fwnode = fwnode;
 +  imxasd = to_imx_media_asd(asd);
 +
 +  if (devname)
 +  imxasd->pdev = pdev;
 +
-   dev_dbg(imxmd->md.dev, "%s: added %s, match type %s\n",
-   __func__, np ? np->name : devname, np ? "FWNODE" : "DEVNAME");
++  if (fwnode)
+   dev_dbg(imxmd->md.dev, "%s: added %pOFn, match type FWNODE\n",
+   __func__, np);
 -  } else {
 -  asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
 -  asd->match.device_name = devname;
 -  imxasd->pdev = pdev;
++  else
+   dev_dbg(imxmd->md.dev, "%s: added %s, match type DEVNAME\n",
+   __func__, devname);
 -  }
 -
 -  list_add_tail(>list, >asd_list);
 -
 -  imxmd->subdev_notifier.num_subdevs++;
  
 -out:
 -  mutex_unlock(>mutex);
 -  return ret;
 +  return 0;
  }
  
  /*


pgpdcZlEw11x4.pgp
Description: OpenPGP digital signature


Re: [PATCH 2/2] clk: qcom: gcc: Add global clock controller driver for QCS404

2018-10-07 Thread Vinod
On 07-10-18, 19:38, Stephen Boyd wrote:
> Quoting Vinod (2018-10-02 23:21:03)
> > Hi Stephen,
> > 
> > Thanks for the comments,
> > 
> > On 01-10-18, 10:19, Stephen Boyd wrote:
> > > Quoting Vinod Koul (2018-09-21 11:59:36)
> > > > From: Shefali Jain 
> > > > 
> > > > Add the clocks supported in global clock controller which clock the
> > > > peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks
> > > > to the clock framework for the clients to be able to request for them.
> > > > 
> > > > Signed-off-by: Shefali Jain 
> > > > Signed-off-by: Taniya Das 
> > > > Co-developed-by: Taniya Das 
> > > > Signed-off-by: Anu Ramanathan 
> > > > [rebase and tidyup for upstream]
> > > 
> > > Who did the tidying?
> > 
> > both of us :)
> 
> OK, please add the username of both people per the kernel sign off
> standards.
> 
> > > > Signed-off-by: Bjorn Andersson 
> > > > Signed-off-by: Vinod Koul 

Sorry not sure I understand, Bjorn and me did cleanup and we signed-off
per process, did I miss something?

> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > 
> > > Please don't include this.
> > 
> > OK will check if this is required, any reason for not including this?
> 
> So we can easily split clk consumers and clk providers.

That was my thought, thanks for confirming :)

> > > > +static struct clk_branch gcc_pwm1_xo512_clk = {
> > > > +   .halt_reg = 0x49004,
> > > > +   .halt_check = BRANCH_HALT,
> > > > +   .clkr = {
> > > > +   .enable_reg = 0x49004,
> > > > +   .enable_mask = BIT(0),
> > > > +   .hw.init = &(struct clk_init_data){
> > > > +   .name = "gcc_pwm1_xo512_clk",
> > > > +   .ops = _branch2_ops,
> > > 
> > > Do these pwm clks have a parent clk of the XO?
> > 
> > Yes they do
> 
> Cool, we should add them or add a comment explaining why they don't have
> parents listed here.

ok

> > > > +   [GCC_USB_HS_PHY_CFG_AHB_CLK] = _usb_hs_phy_cfg_ahb_clk.clkr,
> > > > +   [GCC_USB_HS_SYSTEM_CLK] = _usb_hs_system_clk.clkr,
> > > > +   [GFX3D_CLK_SRC] = _clk_src.clkr,
> > > > +   [GP1_CLK_SRC] = _clk_src.clkr,
> > > 
> > > Why are some of these missing GCC_ prefix?
> > 
> > will add..
> 
> Thanks!

Btw Taniya also commented on this, do you want this as GCC_ or as per hw
documentation?

> > > > +   clk_prepare_enable(apss_ahb_clk_src.clkr.hw.clk);
> > > > +   clk_prepare_enable(gpll0_ao_out_main.clkr.hw.clk);
> > > 
> > > And these should be marked as critical clocks.
> > 
> > Okay and how do we go about doing that?
> 
> You mark the clk flags with CLK_IS_CRITICAL.

Thanks will do.


-- 
~Vinod


Re: [PATCH 2/2] clk: qcom: gcc: Add global clock controller driver for QCS404

2018-10-07 Thread Vinod
On 07-10-18, 19:38, Stephen Boyd wrote:
> Quoting Vinod (2018-10-02 23:21:03)
> > Hi Stephen,
> > 
> > Thanks for the comments,
> > 
> > On 01-10-18, 10:19, Stephen Boyd wrote:
> > > Quoting Vinod Koul (2018-09-21 11:59:36)
> > > > From: Shefali Jain 
> > > > 
> > > > Add the clocks supported in global clock controller which clock the
> > > > peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks
> > > > to the clock framework for the clients to be able to request for them.
> > > > 
> > > > Signed-off-by: Shefali Jain 
> > > > Signed-off-by: Taniya Das 
> > > > Co-developed-by: Taniya Das 
> > > > Signed-off-by: Anu Ramanathan 
> > > > [rebase and tidyup for upstream]
> > > 
> > > Who did the tidying?
> > 
> > both of us :)
> 
> OK, please add the username of both people per the kernel sign off
> standards.
> 
> > > > Signed-off-by: Bjorn Andersson 
> > > > Signed-off-by: Vinod Koul 

Sorry not sure I understand, Bjorn and me did cleanup and we signed-off
per process, did I miss something?

> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > 
> > > Please don't include this.
> > 
> > OK will check if this is required, any reason for not including this?
> 
> So we can easily split clk consumers and clk providers.

That was my thought, thanks for confirming :)

> > > > +static struct clk_branch gcc_pwm1_xo512_clk = {
> > > > +   .halt_reg = 0x49004,
> > > > +   .halt_check = BRANCH_HALT,
> > > > +   .clkr = {
> > > > +   .enable_reg = 0x49004,
> > > > +   .enable_mask = BIT(0),
> > > > +   .hw.init = &(struct clk_init_data){
> > > > +   .name = "gcc_pwm1_xo512_clk",
> > > > +   .ops = _branch2_ops,
> > > 
> > > Do these pwm clks have a parent clk of the XO?
> > 
> > Yes they do
> 
> Cool, we should add them or add a comment explaining why they don't have
> parents listed here.

ok

> > > > +   [GCC_USB_HS_PHY_CFG_AHB_CLK] = _usb_hs_phy_cfg_ahb_clk.clkr,
> > > > +   [GCC_USB_HS_SYSTEM_CLK] = _usb_hs_system_clk.clkr,
> > > > +   [GFX3D_CLK_SRC] = _clk_src.clkr,
> > > > +   [GP1_CLK_SRC] = _clk_src.clkr,
> > > 
> > > Why are some of these missing GCC_ prefix?
> > 
> > will add..
> 
> Thanks!

Btw Taniya also commented on this, do you want this as GCC_ or as per hw
documentation?

> > > > +   clk_prepare_enable(apss_ahb_clk_src.clkr.hw.clk);
> > > > +   clk_prepare_enable(gpll0_ao_out_main.clkr.hw.clk);
> > > 
> > > And these should be marked as critical clocks.
> > 
> > Okay and how do we go about doing that?
> 
> You mark the clk flags with CLK_IS_CRITICAL.

Thanks will do.


-- 
~Vinod


linux-next: manual merge of the drivers-x86 tree with the tip tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/platform/x86/intel_mid_powerbtn.c

between commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip tree and commit:

  a8b60e484f3d ("platform/x86: intel_mid_powerbtn: Get rid of custom ICPU() 
macro")

from the drivers-x86 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 drivers/platform/x86/intel_mid_powerbtn.c
index 5ad44204a9c3,a8c0fbb7f799..
--- a/drivers/platform/x86/intel_mid_powerbtn.c
+++ b/drivers/platform/x86/intel_mid_powerbtn.c
@@@ -121,12 -112,9 +112,9 @@@ static const struct mid_pb_ddata mrfld_
.setup  = mrfld_setup,
  };
  
- #define ICPU(model, ddata)\
-   { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (kernel_ulong_t) }
- 
  static const struct x86_cpu_id mid_pb_cpu_ids[] = {
-   ICPU(INTEL_FAM6_ATOM_SALTWELL_MID,  mfld_ddata),
-   ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,mrfld_ddata),
 -  INTEL_CPU_FAM6(ATOM_PENWELL,mfld_ddata),
 -  INTEL_CPU_FAM6(ATOM_MERRIFIELD, mrfld_ddata),
++  INTEL_CPU_FAM6(ATOM_SALTWELL_MID,   mfld_ddata),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, mrfld_ddata),
{}
  };
  


pgpIXUOxW5meZ.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the drivers-x86 tree with the tip tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/platform/x86/intel_mid_powerbtn.c

between commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip tree and commit:

  a8b60e484f3d ("platform/x86: intel_mid_powerbtn: Get rid of custom ICPU() 
macro")

from the drivers-x86 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 drivers/platform/x86/intel_mid_powerbtn.c
index 5ad44204a9c3,a8c0fbb7f799..
--- a/drivers/platform/x86/intel_mid_powerbtn.c
+++ b/drivers/platform/x86/intel_mid_powerbtn.c
@@@ -121,12 -112,9 +112,9 @@@ static const struct mid_pb_ddata mrfld_
.setup  = mrfld_setup,
  };
  
- #define ICPU(model, ddata)\
-   { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (kernel_ulong_t) }
- 
  static const struct x86_cpu_id mid_pb_cpu_ids[] = {
-   ICPU(INTEL_FAM6_ATOM_SALTWELL_MID,  mfld_ddata),
-   ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,mrfld_ddata),
 -  INTEL_CPU_FAM6(ATOM_PENWELL,mfld_ddata),
 -  INTEL_CPU_FAM6(ATOM_MERRIFIELD, mrfld_ddata),
++  INTEL_CPU_FAM6(ATOM_SALTWELL_MID,   mfld_ddata),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, mrfld_ddata),
{}
  };
  


pgpIXUOxW5meZ.pgp
Description: OpenPGP digital signature


[PATCH v26 2/2] soc: mediatek: Add Mediatek CMDQ helper

2018-10-07 Thread Houlong Wei
Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 drivers/soc/mediatek/Kconfig   |   12 ++
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c |  292 
 include/linux/soc/mediatek/mtk-cmdq.h  |  133 +++
 4 files changed, 438 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a7d0667..17bd759 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -4,6 +4,18 @@
 menu "MediaTek SoC drivers"
depends on ARCH_MEDIATEK || COMPILE_TEST
 
+config MTK_CMDQ
+   tristate "MediaTek CMDQ Support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select MAILBOX
+   select MTK_CMDQ_MBOX
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..64ce5ee 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
new file mode 100644
index 000..45aa0cf
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_ARG_A_WRITE_MASK  0x
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_EOC_IRQ_ENBIT(0)
+#define CMDQ_EOC_CMD   ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
+   << 32 | CMDQ_EOC_IRQ_EN)
+
+static void cmdq_client_timeout(struct timer_list *t)
+{
+   struct cmdq_client *client = from_timer(client, t, timer);
+
+   dev_err(client->client.dev, "cmdq timeout!\n");
+}
+
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32 
timeout)
+{
+   struct cmdq_client *client;
+
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client)
+   return (struct cmdq_client *)-ENOMEM;
+
+   client->timeout_ms = timeout;
+   if (timeout != CMDQ_NO_TIMEOUT) {
+   spin_lock_init(>lock);
+   timer_setup(>timer, cmdq_client_timeout, 0);
+   }
+   client->pkt_cnt = 0;
+   client->client.dev = dev;
+   client->client.tx_block = false;
+   client->chan = mbox_request_channel(>client, index);
+
+   if (IS_ERR(client->chan)) {
+   long err;
+
+   dev_err(dev, "failed to request channel\n");
+   err = PTR_ERR(client->chan);
+   kfree(client);
+
+   return ERR_PTR(err);
+   }
+
+   return client;
+}
+EXPORT_SYMBOL(cmdq_mbox_create);
+
+void cmdq_mbox_destroy(struct cmdq_client *client)
+{
+   if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
+   spin_lock(>lock);
+   del_timer_sync(>timer);
+   spin_unlock(>lock);
+   }
+   mbox_free_channel(client->chan);
+   kfree(client);
+}
+EXPORT_SYMBOL(cmdq_mbox_destroy);
+
+struct cmdq_pkt *cmdq_pkt_create(struct cmdq_client *client, size_t size)
+{
+   struct cmdq_pkt *pkt;
+   struct device *dev;
+   dma_addr_t dma_addr;
+
+   pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
+   if (!pkt)
+   return ERR_PTR(-ENOMEM);
+   pkt->va_base = kzalloc(size, GFP_KERNEL);
+   if (!pkt->va_base) {
+   kfree(pkt);
+   return ERR_PTR(-ENOMEM);
+   }
+   pkt->buf_size = size;
+   pkt->cl = (void *)client;
+
+   dev = client->chan->mbox->dev;
+   dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
+ DMA_TO_DEVICE);
+   if (dma_mapping_error(dev, dma_addr)) {
+   dev_err(dev, "dma map failed, size=%u\n", (u32)(u64)size);
+   kfree(pkt->va_base);
+   kfree(pkt);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   pkt->pa_base = dma_addr;
+
+   return pkt;
+}
+EXPORT_SYMBOL(cmdq_pkt_create);
+
+void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
+{
+   struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
+
+   dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
+

[PATCH v26 2/2] soc: mediatek: Add Mediatek CMDQ helper

2018-10-07 Thread Houlong Wei
Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 drivers/soc/mediatek/Kconfig   |   12 ++
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c |  292 
 include/linux/soc/mediatek/mtk-cmdq.h  |  133 +++
 4 files changed, 438 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a7d0667..17bd759 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -4,6 +4,18 @@
 menu "MediaTek SoC drivers"
depends on ARCH_MEDIATEK || COMPILE_TEST
 
+config MTK_CMDQ
+   tristate "MediaTek CMDQ Support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select MAILBOX
+   select MTK_CMDQ_MBOX
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..64ce5ee 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
new file mode 100644
index 000..45aa0cf
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2018 MediaTek Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_ARG_A_WRITE_MASK  0x
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_EOC_IRQ_ENBIT(0)
+#define CMDQ_EOC_CMD   ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
+   << 32 | CMDQ_EOC_IRQ_EN)
+
+static void cmdq_client_timeout(struct timer_list *t)
+{
+   struct cmdq_client *client = from_timer(client, t, timer);
+
+   dev_err(client->client.dev, "cmdq timeout!\n");
+}
+
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32 
timeout)
+{
+   struct cmdq_client *client;
+
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   if (!client)
+   return (struct cmdq_client *)-ENOMEM;
+
+   client->timeout_ms = timeout;
+   if (timeout != CMDQ_NO_TIMEOUT) {
+   spin_lock_init(>lock);
+   timer_setup(>timer, cmdq_client_timeout, 0);
+   }
+   client->pkt_cnt = 0;
+   client->client.dev = dev;
+   client->client.tx_block = false;
+   client->chan = mbox_request_channel(>client, index);
+
+   if (IS_ERR(client->chan)) {
+   long err;
+
+   dev_err(dev, "failed to request channel\n");
+   err = PTR_ERR(client->chan);
+   kfree(client);
+
+   return ERR_PTR(err);
+   }
+
+   return client;
+}
+EXPORT_SYMBOL(cmdq_mbox_create);
+
+void cmdq_mbox_destroy(struct cmdq_client *client)
+{
+   if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
+   spin_lock(>lock);
+   del_timer_sync(>timer);
+   spin_unlock(>lock);
+   }
+   mbox_free_channel(client->chan);
+   kfree(client);
+}
+EXPORT_SYMBOL(cmdq_mbox_destroy);
+
+struct cmdq_pkt *cmdq_pkt_create(struct cmdq_client *client, size_t size)
+{
+   struct cmdq_pkt *pkt;
+   struct device *dev;
+   dma_addr_t dma_addr;
+
+   pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
+   if (!pkt)
+   return ERR_PTR(-ENOMEM);
+   pkt->va_base = kzalloc(size, GFP_KERNEL);
+   if (!pkt->va_base) {
+   kfree(pkt);
+   return ERR_PTR(-ENOMEM);
+   }
+   pkt->buf_size = size;
+   pkt->cl = (void *)client;
+
+   dev = client->chan->mbox->dev;
+   dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
+ DMA_TO_DEVICE);
+   if (dma_mapping_error(dev, dma_addr)) {
+   dev_err(dev, "dma map failed, size=%u\n", (u32)(u64)size);
+   kfree(pkt->va_base);
+   kfree(pkt);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   pkt->pa_base = dma_addr;
+
+   return pkt;
+}
+EXPORT_SYMBOL(cmdq_pkt_create);
+
+void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
+{
+   struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
+
+   dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
+

[PATCH v26 0/2] MediaTek MT8173 CMDQ support

2018-10-07 Thread Houlong Wei
Hi,

This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.

Changes since v25:
 -Replace WARN_ON() with WARN_ONCE() and add debug information.
Changes since v24:
 -move WARN_ON() into cmdq_pkt_append_command() from outside
Changes since v23:
 -rebase on v4.19-rc1
 -revise return value of cmdq_mbox_create()
 -revise cmdq_pkt_create()
 -add MODULE_LICENSE() for mtk-cmdq-helper.c
 -adjust functions order in mtk-cmdq.h
Changes since v22:
 -remove properties 'timeout' and 'thread-num' from device tree
 -move timer from CMDQ driver to CMDQ helper
 -move dma unmap from CMDQ driver to CMDQ helper
 -config thread number in CMDQ match table
 -remove reallocate mechanism and let client specify the cmdq buffer size
 -let client specify the timeout time
Changes since v21:
 -rebase on v4.18-rc1
 -remove subsys code and event id definition from mtk-cmdq-helper.c
 -add mt8173-gce.h to define the subsys code and envent id
Changes since v20:
 -rebase on v4.15-rc1
 -move dma_map_single outside of spinlock
Changes since v19:
 -rebase to v4.10-rc2

Houlong Wei (2):
  arm64: dts: mt8173: Add GCE node
  soc: mediatek: Add Mediatek CMDQ helper

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   10 +
 drivers/soc/mediatek/Kconfig |   12 ++
 drivers/soc/mediatek/Makefile|1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c   |  292 ++
 include/linux/soc/mediatek/mtk-cmdq.h|  133 ++
 5 files changed, 448 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

-- 
1.7.9.5



linux-next: manual merge of the drivers-x86 tree with the tip tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/platform/x86/intel_int0002_vgpio.c

between commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip tree and commit:

  96402de65afc ("platform/x86: intel_int0002_vgpio: Enable the driver on Bay 
Trail platforms")

from the drivers-x86 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 drivers/platform/x86/intel_int0002_vgpio.c
index e89ad4964dc1,c958a628c375..
--- a/drivers/platform/x86/intel_int0002_vgpio.c
+++ b/drivers/platform/x86/intel_int0002_vgpio.c
@@@ -57,11 -54,7 +54,7 @@@
  #define ICPU(model)   { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
  
  static const struct x86_cpu_id int0002_cpu_ids[] = {
- /*
-  * Limit ourselves to Cherry Trail for now, until testing shows we
-  * need to handle the INT0002 device on Baytrail too.
-  *ICPU(INTEL_FAM6_ATOM_SILVERMONT),* Valleyview, Bay Trail *
-  */
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT1),  /* Valleyview, Bay Trail  */
++  ICPU(INTEL_FAM6_ATOM_SILVERMONT),   /* Valleyview, Bay Trail  */
ICPU(INTEL_FAM6_ATOM_AIRMONT),  /* Braswell, Cherry Trail */
{}
  };


pgpQaIEf5H84f.pgp
Description: OpenPGP digital signature


[PATCH v26 0/2] MediaTek MT8173 CMDQ support

2018-10-07 Thread Houlong Wei
Hi,

This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.

Changes since v25:
 -Replace WARN_ON() with WARN_ONCE() and add debug information.
Changes since v24:
 -move WARN_ON() into cmdq_pkt_append_command() from outside
Changes since v23:
 -rebase on v4.19-rc1
 -revise return value of cmdq_mbox_create()
 -revise cmdq_pkt_create()
 -add MODULE_LICENSE() for mtk-cmdq-helper.c
 -adjust functions order in mtk-cmdq.h
Changes since v22:
 -remove properties 'timeout' and 'thread-num' from device tree
 -move timer from CMDQ driver to CMDQ helper
 -move dma unmap from CMDQ driver to CMDQ helper
 -config thread number in CMDQ match table
 -remove reallocate mechanism and let client specify the cmdq buffer size
 -let client specify the timeout time
Changes since v21:
 -rebase on v4.18-rc1
 -remove subsys code and event id definition from mtk-cmdq-helper.c
 -add mt8173-gce.h to define the subsys code and envent id
Changes since v20:
 -rebase on v4.15-rc1
 -move dma_map_single outside of spinlock
Changes since v19:
 -rebase to v4.10-rc2

Houlong Wei (2):
  arm64: dts: mt8173: Add GCE node
  soc: mediatek: Add Mediatek CMDQ helper

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   10 +
 drivers/soc/mediatek/Kconfig |   12 ++
 drivers/soc/mediatek/Makefile|1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c   |  292 ++
 include/linux/soc/mediatek/mtk-cmdq.h|  133 ++
 5 files changed, 448 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

-- 
1.7.9.5



linux-next: manual merge of the drivers-x86 tree with the tip tree

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/platform/x86/intel_int0002_vgpio.c

between commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip tree and commit:

  96402de65afc ("platform/x86: intel_int0002_vgpio: Enable the driver on Bay 
Trail platforms")

from the drivers-x86 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 drivers/platform/x86/intel_int0002_vgpio.c
index e89ad4964dc1,c958a628c375..
--- a/drivers/platform/x86/intel_int0002_vgpio.c
+++ b/drivers/platform/x86/intel_int0002_vgpio.c
@@@ -57,11 -54,7 +54,7 @@@
  #define ICPU(model)   { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
  
  static const struct x86_cpu_id int0002_cpu_ids[] = {
- /*
-  * Limit ourselves to Cherry Trail for now, until testing shows we
-  * need to handle the INT0002 device on Baytrail too.
-  *ICPU(INTEL_FAM6_ATOM_SILVERMONT),* Valleyview, Bay Trail *
-  */
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT1),  /* Valleyview, Bay Trail  */
++  ICPU(INTEL_FAM6_ATOM_SILVERMONT),   /* Valleyview, Bay Trail  */
ICPU(INTEL_FAM6_ATOM_AIRMONT),  /* Braswell, Cherry Trail */
{}
  };


pgpQaIEf5H84f.pgp
Description: OpenPGP digital signature


[PATCH v26 1/2] arm64: dts: mt8173: Add GCE node

2018-10-07 Thread Houlong Wei
This patch adds the device node of the GCE hardware for CMDQ module.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index abd2f15..412ffd4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "mt8173-pinfunc.h"
 
 / {
@@ -521,6 +522,15 @@
status = "disabled";
};
 
+   gce: mailbox@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+   #mbox-cells = <3>;
+   };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
-- 
1.7.9.5



[PATCH v26 1/2] arm64: dts: mt8173: Add GCE node

2018-10-07 Thread Houlong Wei
This patch adds the device node of the GCE hardware for CMDQ module.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index abd2f15..412ffd4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "mt8173-pinfunc.h"
 
 / {
@@ -521,6 +522,15 @@
status = "disabled";
};
 
+   gce: mailbox@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+   #mbox-cells = <3>;
+   };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
-- 
1.7.9.5



Do You Need A Helping Hand?

2018-10-07 Thread Mavis Wanczyk







Do You Need A Helping Hand?

2018-10-07 Thread Mavis Wanczyk







Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread lijiang
在 2018年10月07日 16:47, Borislav Petkov 写道:
> On Sun, Oct 07, 2018 at 01:55:33PM +0800, lijiang wrote:
>> Here, it may be have a compile error.
> 
> Are you sure? The configs I tried worked fine but I'm open to being
> shown configs which fail the build.
> 

Yes. As previously mentioned, the correct patch is this one:

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 3e4ba9d753c8..84d8ddcb818e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -26,6 +26,19 @@ extern int remap_oldmem_pfn_range(struct vm_area_struct *vma,
 
 extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
+#if defined(CONFIG_AMD_MEM_ENCRYPT) || defined(CONFIG_X86_64)
+extern ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf,
+ size_t csize, unsigned long offset,
+ int userbuf);
+#else
+static inline
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+  unsigned long offset, int userbuf)
+{
+   return 0;
+}
+#endif
+

I used the patch above to test six compile cases. All of them passed, there
was no compile error.

I'm not sure whether the kernel options or compile environment are different.
Would you like to share your kernel options(.config)? I will use your kernel
options to compile, and check whether i might also reproduce your compile 
error. 

1. x86_64 (CONFIG_X86_64=y)
   a. 
  CONFIG_AMD_MEM_ENCRYPT=y
  CONFIG_CRASH_DUMP=y

   b.
  # CONFIG_AMD_MEM_ENCRYPT is not set
  # CONFIG_CRASH_DUMP is not set

   c. 
  # CONFIG_AMD_MEM_ENCRYPT is not set
  CONFIG_CRASH_DUMP=y

   d. 
  CONFIG_AMD_MEM_ENCRYPT=y
  # CONFIG_CRASH_DUMP is not set

Compile command:
#make clean
#make ARCH=x86_64 -j32

2. i386 (CONFIG_X86_32=y)
   a. 
   CONFIG_CRASH_DUMP=y

   b.
   # CONFIG_CRASH_DUMP is not set

Compile command:
#make clean
#make ARCH=i386 -j32

Thanks.
Lianbo


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread lijiang
在 2018年10月07日 16:47, Borislav Petkov 写道:
> On Sun, Oct 07, 2018 at 01:55:33PM +0800, lijiang wrote:
>> Here, it may be have a compile error.
> 
> Are you sure? The configs I tried worked fine but I'm open to being
> shown configs which fail the build.
> 

Yes. As previously mentioned, the correct patch is this one:

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 3e4ba9d753c8..84d8ddcb818e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -26,6 +26,19 @@ extern int remap_oldmem_pfn_range(struct vm_area_struct *vma,
 
 extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
+#if defined(CONFIG_AMD_MEM_ENCRYPT) || defined(CONFIG_X86_64)
+extern ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf,
+ size_t csize, unsigned long offset,
+ int userbuf);
+#else
+static inline
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+  unsigned long offset, int userbuf)
+{
+   return 0;
+}
+#endif
+

I used the patch above to test six compile cases. All of them passed, there
was no compile error.

I'm not sure whether the kernel options or compile environment are different.
Would you like to share your kernel options(.config)? I will use your kernel
options to compile, and check whether i might also reproduce your compile 
error. 

1. x86_64 (CONFIG_X86_64=y)
   a. 
  CONFIG_AMD_MEM_ENCRYPT=y
  CONFIG_CRASH_DUMP=y

   b.
  # CONFIG_AMD_MEM_ENCRYPT is not set
  # CONFIG_CRASH_DUMP is not set

   c. 
  # CONFIG_AMD_MEM_ENCRYPT is not set
  CONFIG_CRASH_DUMP=y

   d. 
  CONFIG_AMD_MEM_ENCRYPT=y
  # CONFIG_CRASH_DUMP is not set

Compile command:
#make clean
#make ARCH=x86_64 -j32

2. i386 (CONFIG_X86_32=y)
   a. 
   CONFIG_CRASH_DUMP=y

   b.
   # CONFIG_CRASH_DUMP is not set

Compile command:
#make clean
#make ARCH=i386 -j32

Thanks.
Lianbo


[PATCH v2] staging: iio: ad2s1210: fix 'assignment operator' style checks

2018-10-07 Thread Matheus Tavares
This patch fixes all "Assignment operator '=' should be on the previous
line" checks found in ad2s1210.c with checkpatch.pl.

Signed-off-by: Matheus Tavares 
---
Changes in v2: In v1, tabs were accidentally converted to whitespaces.
Now, tabs were preserved.

 drivers/staging/iio/resolver/ad2s1210.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s1210.c 
b/drivers/staging/iio/resolver/ad2s1210.c
index ac13b99bd9cb..d4b1c2c010f2 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -301,8 +301,8 @@ static ssize_t ad2s1210_store_control(struct device *dev,
"ad2s1210: write control register fail\n");
goto error_ret;
}
-   st->resolution
-   = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
+   st->resolution =
+   ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
if (st->pdata->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
@@ -363,8 +363,8 @@ static ssize_t ad2s1210_store_resolution(struct device *dev,
dev_err(dev, "ad2s1210: setting resolution fail\n");
goto error_ret;
}
-   st->resolution
-   = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
+   st->resolution =
+   ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
if (st->pdata->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
-- 
2.18.0



[PATCH v2] staging: iio: ad2s1210: fix 'assignment operator' style checks

2018-10-07 Thread Matheus Tavares
This patch fixes all "Assignment operator '=' should be on the previous
line" checks found in ad2s1210.c with checkpatch.pl.

Signed-off-by: Matheus Tavares 
---
Changes in v2: In v1, tabs were accidentally converted to whitespaces.
Now, tabs were preserved.

 drivers/staging/iio/resolver/ad2s1210.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s1210.c 
b/drivers/staging/iio/resolver/ad2s1210.c
index ac13b99bd9cb..d4b1c2c010f2 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -301,8 +301,8 @@ static ssize_t ad2s1210_store_control(struct device *dev,
"ad2s1210: write control register fail\n");
goto error_ret;
}
-   st->resolution
-   = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
+   st->resolution =
+   ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
if (st->pdata->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
@@ -363,8 +363,8 @@ static ssize_t ad2s1210_store_resolution(struct device *dev,
dev_err(dev, "ad2s1210: setting resolution fail\n");
goto error_ret;
}
-   st->resolution
-   = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
+   st->resolution =
+   ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
if (st->pdata->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
-- 
2.18.0



[PATCH v6 9/9] PCI: mediatek: Add loadable kernel module support

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

Implement remove callback function for Mediatek PCIe driver to add
loadable kernel module support.

Signed-off-by: Honghui Zhang 
Reviewed-by: Ryder Lee 
---
 drivers/pci/controller/Kconfig |  2 +-
 drivers/pci/controller/pcie-mediatek.c | 52 +-
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 028b287..465790f 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -231,7 +231,7 @@ config PCIE_ROCKCHIP_EP
  available to support GEN2 with 4 slots.
 
 config PCIE_MEDIATEK
-   bool "MediaTek PCIe controller"
+   tristate "MediaTek PCIe controller"
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on OF
depends on PCI_MSI_IRQ_DOMAIN
diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index daba78f..3327c75 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -532,6 +533,27 @@ static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
writel(val, port->base + PCIE_INT_MASK);
 }
 
+static void mtk_pcie_irq_teardown(struct mtk_pcie *pcie)
+{
+   struct mtk_pcie_port *port, *tmp;
+
+   list_for_each_entry_safe(port, tmp, >ports, list) {
+   irq_set_chained_handler_and_data(port->irq, NULL, NULL);
+
+   if (port->irq_domain)
+   irq_domain_remove(port->irq_domain);
+
+   if (IS_ENABLED(CONFIG_PCI_MSI)) {
+   if (port->msi_domain)
+   irq_domain_remove(port->msi_domain);
+   if (port->inner_domain)
+   irq_domain_remove(port->inner_domain);
+   }
+
+   irq_dispose_mapping(port->irq);
+   }
+}
+
 static int mtk_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
 irq_hw_number_t hwirq)
 {
@@ -1171,6 +1193,32 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
 }
 
+
+static void mtk_pcie_free_resources(struct mtk_pcie *pcie)
+{
+   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+   struct list_head *windows = >windows;
+
+   pci_unmap_iospace(>pio);
+   pci_free_resource_list(windows);
+}
+
+static int mtk_pcie_remove(struct platform_device *pdev)
+{
+   struct mtk_pcie *pcie = platform_get_drvdata(pdev);
+   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+
+   pci_stop_root_bus(host->bus);
+   pci_remove_root_bus(host->bus);
+   mtk_pcie_free_resources(pcie);
+
+   mtk_pcie_irq_teardown(pcie);
+
+   mtk_pcie_put_resources(pcie);
+
+   return 0;
+}
+
 static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
 {
struct mtk_pcie *pcie = dev_get_drvdata(dev);
@@ -1248,6 +1296,7 @@ static const struct of_device_id mtk_pcie_ids[] = {
 
 static struct platform_driver mtk_pcie_driver = {
.probe = mtk_pcie_probe,
+   .remove = mtk_pcie_remove,
.driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
@@ -1255,4 +1304,5 @@ static struct platform_driver mtk_pcie_driver = {
.pm = _pcie_pm_ops,
},
 };
-builtin_platform_driver(mtk_pcie_driver);
+module_platform_driver(mtk_pcie_driver);
+MODULE_LICENSE("GPL v2");
-- 
2.6.4



[PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

The PCIe controller of MT7622 has TYPE 1 configuration space type, but
the HW default class type values is invalid.

The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
type for MT7622") have set the class ID for MT7622 as
PCI_CLASS_BRIDGE_HOST, but it's not workable for MT7622:

In __pci_bus_assign_resources, the framework only setup bridge's
resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
will leave the subordinary PCIe device's MMIO window un-touched.

Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller
driver do.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 288b8e2..bcdac9b 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -432,7 +432,7 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
*port)
val = PCI_VENDOR_ID_MEDIATEK;
writew(val, port->base + PCIE_CONF_VEND_ID);
 
-   val = PCI_CLASS_BRIDGE_HOST;
+   val = PCI_CLASS_BRIDGE_PCI;
writew(val, port->base + PCIE_CONF_CLASS_ID);
}
 
-- 
2.6.4



[PATCH v6 9/9] PCI: mediatek: Add loadable kernel module support

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

Implement remove callback function for Mediatek PCIe driver to add
loadable kernel module support.

Signed-off-by: Honghui Zhang 
Reviewed-by: Ryder Lee 
---
 drivers/pci/controller/Kconfig |  2 +-
 drivers/pci/controller/pcie-mediatek.c | 52 +-
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 028b287..465790f 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -231,7 +231,7 @@ config PCIE_ROCKCHIP_EP
  available to support GEN2 with 4 slots.
 
 config PCIE_MEDIATEK
-   bool "MediaTek PCIe controller"
+   tristate "MediaTek PCIe controller"
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on OF
depends on PCI_MSI_IRQ_DOMAIN
diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index daba78f..3327c75 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -532,6 +533,27 @@ static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
writel(val, port->base + PCIE_INT_MASK);
 }
 
+static void mtk_pcie_irq_teardown(struct mtk_pcie *pcie)
+{
+   struct mtk_pcie_port *port, *tmp;
+
+   list_for_each_entry_safe(port, tmp, >ports, list) {
+   irq_set_chained_handler_and_data(port->irq, NULL, NULL);
+
+   if (port->irq_domain)
+   irq_domain_remove(port->irq_domain);
+
+   if (IS_ENABLED(CONFIG_PCI_MSI)) {
+   if (port->msi_domain)
+   irq_domain_remove(port->msi_domain);
+   if (port->inner_domain)
+   irq_domain_remove(port->inner_domain);
+   }
+
+   irq_dispose_mapping(port->irq);
+   }
+}
+
 static int mtk_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
 irq_hw_number_t hwirq)
 {
@@ -1171,6 +1193,32 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
 }
 
+
+static void mtk_pcie_free_resources(struct mtk_pcie *pcie)
+{
+   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+   struct list_head *windows = >windows;
+
+   pci_unmap_iospace(>pio);
+   pci_free_resource_list(windows);
+}
+
+static int mtk_pcie_remove(struct platform_device *pdev)
+{
+   struct mtk_pcie *pcie = platform_get_drvdata(pdev);
+   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+
+   pci_stop_root_bus(host->bus);
+   pci_remove_root_bus(host->bus);
+   mtk_pcie_free_resources(pcie);
+
+   mtk_pcie_irq_teardown(pcie);
+
+   mtk_pcie_put_resources(pcie);
+
+   return 0;
+}
+
 static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
 {
struct mtk_pcie *pcie = dev_get_drvdata(dev);
@@ -1248,6 +1296,7 @@ static const struct of_device_id mtk_pcie_ids[] = {
 
 static struct platform_driver mtk_pcie_driver = {
.probe = mtk_pcie_probe,
+   .remove = mtk_pcie_remove,
.driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
@@ -1255,4 +1304,5 @@ static struct platform_driver mtk_pcie_driver = {
.pm = _pcie_pm_ops,
},
 };
-builtin_platform_driver(mtk_pcie_driver);
+module_platform_driver(mtk_pcie_driver);
+MODULE_LICENSE("GPL v2");
-- 
2.6.4



[PATCH v6 2/9] PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

The PCIe controller of MT7622 has TYPE 1 configuration space type, but
the HW default class type values is invalid.

The commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class
type for MT7622") have set the class ID for MT7622 as
PCI_CLASS_BRIDGE_HOST, but it's not workable for MT7622:

In __pci_bus_assign_resources, the framework only setup bridge's
resource window only if class type is PCI_CLASS_BRIDGE_PCI. Or it
will leave the subordinary PCIe device's MMIO window un-touched.

Fixup the class type to PCI_CLASS_BRIDGE_PCI as most of the controller
driver do.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 288b8e2..bcdac9b 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -432,7 +432,7 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
*port)
val = PCI_VENDOR_ID_MEDIATEK;
writew(val, port->base + PCIE_CONF_VEND_ID);
 
-   val = PCI_CLASS_BRIDGE_HOST;
+   val = PCI_CLASS_BRIDGE_PCI;
writew(val, port->base + PCIE_CONF_CLASS_ID);
}
 
-- 
2.6.4



[PATCH v6 7/9] PCI: mediatek: Add system pm support for MT2712 and MT7622

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

In order to reduce the PCIe power consuming while system suspend,
the physical layer should be gated. And the PCIe link should be
re-established and the related control register values should be
re-initialized after system resume.

Register suspend_noirq & resume_noirq callback functions to allow
PCIe to come up after resume from RAM.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index d3f4694..42cf2a4 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1168,6 +1168,55 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
 }
 
+static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
+{
+   struct mtk_pcie *pcie = dev_get_drvdata(dev);
+   struct mtk_pcie_port *port;
+
+   if (list_empty(>ports))
+   return 0;
+
+   list_for_each_entry(port, >ports, list) {
+   clk_disable_unprepare(port->pipe_ck);
+   clk_disable_unprepare(port->obff_ck);
+   clk_disable_unprepare(port->axi_ck);
+   clk_disable_unprepare(port->aux_ck);
+   clk_disable_unprepare(port->ahb_ck);
+   clk_disable_unprepare(port->sys_ck);
+   phy_power_off(port->phy);
+   phy_exit(port->phy);
+   }
+
+   clk_disable_unprepare(pcie->free_ck);
+
+   return 0;
+}
+
+static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
+{
+   struct mtk_pcie *pcie = dev_get_drvdata(dev);
+   struct mtk_pcie_port *port, *tmp;
+
+   if (list_empty(>ports))
+   return 0;
+
+   clk_prepare_enable(pcie->free_ck);
+
+   list_for_each_entry_safe(port, tmp, >ports, list)
+   mtk_pcie_enable_port(port);
+
+   /* In case of EP was removed while system suspend. */
+   if (list_empty(>ports))
+   clk_disable_unprepare(pcie->free_ck);
+
+   return 0;
+}
+
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
 static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = _pcie_ops,
.startup = mtk_pcie_startup_port,
@@ -1200,6 +1249,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+   .pm = _pcie_pm_ops,
},
 };
 builtin_platform_driver(mtk_pcie_driver);
-- 
2.6.4



[PATCH v6 3/9] PCI: mediatek: Remove the redundant dev->pm_domain check

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

It's no needed to check whether device have pm_domain attached before
calling the pm_runtime_XXX interface, remove it.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index bcdac9b..59fdb60 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -225,10 +225,8 @@ static void mtk_pcie_subsys_powerdown(struct mtk_pcie 
*pcie)
 
clk_disable_unprepare(pcie->free_ck);
 
-   if (dev->pm_domain) {
-   pm_runtime_put_sync(dev);
-   pm_runtime_disable(dev);
-   }
+   pm_runtime_put_sync(dev);
+   pm_runtime_disable(dev);
 }
 
 static void mtk_pcie_port_free(struct mtk_pcie_port *port)
@@ -998,10 +996,8 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
pcie->free_ck = NULL;
}
 
-   if (dev->pm_domain) {
-   pm_runtime_enable(dev);
-   pm_runtime_get_sync(dev);
-   }
+   pm_runtime_enable(dev);
+   pm_runtime_get_sync(dev);
 
/* enable top level clock */
err = clk_prepare_enable(pcie->free_ck);
@@ -1013,10 +1009,8 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
return 0;
 
 err_free_ck:
-   if (dev->pm_domain) {
-   pm_runtime_put_sync(dev);
-   pm_runtime_disable(dev);
-   }
+   pm_runtime_put_sync(dev);
+   pm_runtime_disable(dev);
 
return err;
 }
-- 
2.6.4



[PATCH v6 4/9] PCI: mediatek: Convert to use pci_host_probe()

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

Part of mtk_pcie_register_host is an open-coded version of
pci_host_probe(). So instead of duplicating this code, use
pci_host_probe() directly and remove mtk_pcie_register_host.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 37 --
 1 file changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 59fdb60..ead6005 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1121,34 +1121,6 @@ static int mtk_pcie_request_resources(struct mtk_pcie 
*pcie)
return 0;
 }
 
-static int mtk_pcie_register_host(struct pci_host_bridge *host)
-{
-   struct mtk_pcie *pcie = pci_host_bridge_priv(host);
-   struct pci_bus *child;
-   int err;
-
-   host->busnr = pcie->busn.start;
-   host->dev.parent = pcie->dev;
-   host->ops = pcie->soc->ops;
-   host->map_irq = of_irq_parse_and_map_pci;
-   host->swizzle_irq = pci_common_swizzle;
-   host->sysdata = pcie;
-
-   err = pci_scan_root_bus_bridge(host);
-   if (err < 0)
-   return err;
-
-   pci_bus_size_bridges(host->bus);
-   pci_bus_assign_resources(host->bus);
-
-   list_for_each_entry(child, >bus->children, node)
-   pcie_bus_configure_settings(child);
-
-   pci_bus_add_devices(host->bus);
-
-   return 0;
-}
-
 static int mtk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1175,7 +1147,14 @@ static int mtk_pcie_probe(struct platform_device *pdev)
if (err)
goto put_resources;
 
-   err = mtk_pcie_register_host(host);
+   host->busnr = pcie->busn.start;
+   host->dev.parent = pcie->dev;
+   host->ops = pcie->soc->ops;
+   host->map_irq = of_irq_parse_and_map_pci;
+   host->swizzle_irq = pci_common_swizzle;
+   host->sysdata = pcie;
+
+   err = pci_host_probe(host);
if (err)
goto put_resources;
 
-- 
2.6.4



[PATCH v6 3/9] PCI: mediatek: Remove the redundant dev->pm_domain check

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

It's no needed to check whether device have pm_domain attached before
calling the pm_runtime_XXX interface, remove it.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index bcdac9b..59fdb60 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -225,10 +225,8 @@ static void mtk_pcie_subsys_powerdown(struct mtk_pcie 
*pcie)
 
clk_disable_unprepare(pcie->free_ck);
 
-   if (dev->pm_domain) {
-   pm_runtime_put_sync(dev);
-   pm_runtime_disable(dev);
-   }
+   pm_runtime_put_sync(dev);
+   pm_runtime_disable(dev);
 }
 
 static void mtk_pcie_port_free(struct mtk_pcie_port *port)
@@ -998,10 +996,8 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
pcie->free_ck = NULL;
}
 
-   if (dev->pm_domain) {
-   pm_runtime_enable(dev);
-   pm_runtime_get_sync(dev);
-   }
+   pm_runtime_enable(dev);
+   pm_runtime_get_sync(dev);
 
/* enable top level clock */
err = clk_prepare_enable(pcie->free_ck);
@@ -1013,10 +1009,8 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
return 0;
 
 err_free_ck:
-   if (dev->pm_domain) {
-   pm_runtime_put_sync(dev);
-   pm_runtime_disable(dev);
-   }
+   pm_runtime_put_sync(dev);
+   pm_runtime_disable(dev);
 
return err;
 }
-- 
2.6.4



[PATCH v6 4/9] PCI: mediatek: Convert to use pci_host_probe()

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

Part of mtk_pcie_register_host is an open-coded version of
pci_host_probe(). So instead of duplicating this code, use
pci_host_probe() directly and remove mtk_pcie_register_host.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 37 --
 1 file changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 59fdb60..ead6005 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1121,34 +1121,6 @@ static int mtk_pcie_request_resources(struct mtk_pcie 
*pcie)
return 0;
 }
 
-static int mtk_pcie_register_host(struct pci_host_bridge *host)
-{
-   struct mtk_pcie *pcie = pci_host_bridge_priv(host);
-   struct pci_bus *child;
-   int err;
-
-   host->busnr = pcie->busn.start;
-   host->dev.parent = pcie->dev;
-   host->ops = pcie->soc->ops;
-   host->map_irq = of_irq_parse_and_map_pci;
-   host->swizzle_irq = pci_common_swizzle;
-   host->sysdata = pcie;
-
-   err = pci_scan_root_bus_bridge(host);
-   if (err < 0)
-   return err;
-
-   pci_bus_size_bridges(host->bus);
-   pci_bus_assign_resources(host->bus);
-
-   list_for_each_entry(child, >bus->children, node)
-   pcie_bus_configure_settings(child);
-
-   pci_bus_add_devices(host->bus);
-
-   return 0;
-}
-
 static int mtk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1175,7 +1147,14 @@ static int mtk_pcie_probe(struct platform_device *pdev)
if (err)
goto put_resources;
 
-   err = mtk_pcie_register_host(host);
+   host->busnr = pcie->busn.start;
+   host->dev.parent = pcie->dev;
+   host->ops = pcie->soc->ops;
+   host->map_irq = of_irq_parse_and_map_pci;
+   host->swizzle_irq = pci_common_swizzle;
+   host->sysdata = pcie;
+
+   err = pci_host_probe(host);
if (err)
goto put_resources;
 
-- 
2.6.4



[PATCH v6 7/9] PCI: mediatek: Add system pm support for MT2712 and MT7622

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

In order to reduce the PCIe power consuming while system suspend,
the physical layer should be gated. And the PCIe link should be
re-established and the related control register values should be
re-initialized after system resume.

Register suspend_noirq & resume_noirq callback functions to allow
PCIe to come up after resume from RAM.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index d3f4694..42cf2a4 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1168,6 +1168,55 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
 }
 
+static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
+{
+   struct mtk_pcie *pcie = dev_get_drvdata(dev);
+   struct mtk_pcie_port *port;
+
+   if (list_empty(>ports))
+   return 0;
+
+   list_for_each_entry(port, >ports, list) {
+   clk_disable_unprepare(port->pipe_ck);
+   clk_disable_unprepare(port->obff_ck);
+   clk_disable_unprepare(port->axi_ck);
+   clk_disable_unprepare(port->aux_ck);
+   clk_disable_unprepare(port->ahb_ck);
+   clk_disable_unprepare(port->sys_ck);
+   phy_power_off(port->phy);
+   phy_exit(port->phy);
+   }
+
+   clk_disable_unprepare(pcie->free_ck);
+
+   return 0;
+}
+
+static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
+{
+   struct mtk_pcie *pcie = dev_get_drvdata(dev);
+   struct mtk_pcie_port *port, *tmp;
+
+   if (list_empty(>ports))
+   return 0;
+
+   clk_prepare_enable(pcie->free_ck);
+
+   list_for_each_entry_safe(port, tmp, >ports, list)
+   mtk_pcie_enable_port(port);
+
+   /* In case of EP was removed while system suspend. */
+   if (list_empty(>ports))
+   clk_disable_unprepare(pcie->free_ck);
+
+   return 0;
+}
+
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
 static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = _pcie_ops,
.startup = mtk_pcie_startup_port,
@@ -1200,6 +1249,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+   .pm = _pcie_pm_ops,
},
 };
 builtin_platform_driver(mtk_pcie_driver);
-- 
2.6.4



[PATCH v6 8/9] PCI: mediatek: Save the GIC IRQ in mtk_pcie_port

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

Need to save the PCIe's GIC IRQ for dispose_irq, this is a prepare
patch for add mediatek PCIe module support to tear down the IRQ, no
functional changed.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 42cf2a4..daba78f 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -162,6 +162,7 @@ struct mtk_pcie_soc {
  * @phy: pointer to PHY control block
  * @lane: lane count
  * @slot: port slot
+ * @irq: GIC irq
  * @irq_domain: legacy INTx IRQ domain
  * @inner_domain: inner IRQ domain
  * @msi_domain: MSI IRQ domain
@@ -182,6 +183,7 @@ struct mtk_pcie_port {
struct phy *phy;
u32 lane;
u32 slot;
+   int irq;
struct irq_domain *irq_domain;
struct irq_domain *inner_domain;
struct irq_domain *msi_domain;
@@ -620,7 +622,7 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
struct mtk_pcie *pcie = port->pcie;
struct device *dev = pcie->dev;
struct platform_device *pdev = to_platform_device(dev);
-   int err, irq;
+   int err;
 
err = mtk_pcie_init_irq_domain(port, node);
if (err) {
@@ -628,8 +630,9 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
return err;
}
 
-   irq = platform_get_irq(pdev, port->slot);
-   irq_set_chained_handler_and_data(irq, mtk_pcie_intr_handler, port);
+   port->irq = platform_get_irq(pdev, port->slot);
+   irq_set_chained_handler_and_data(port->irq,
+mtk_pcie_intr_handler, port);
 
return 0;
 }
-- 
2.6.4



[PATCH v6 8/9] PCI: mediatek: Save the GIC IRQ in mtk_pcie_port

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

Need to save the PCIe's GIC IRQ for dispose_irq, this is a prepare
patch for add mediatek PCIe module support to tear down the IRQ, no
functional changed.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 42cf2a4..daba78f 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -162,6 +162,7 @@ struct mtk_pcie_soc {
  * @phy: pointer to PHY control block
  * @lane: lane count
  * @slot: port slot
+ * @irq: GIC irq
  * @irq_domain: legacy INTx IRQ domain
  * @inner_domain: inner IRQ domain
  * @msi_domain: MSI IRQ domain
@@ -182,6 +183,7 @@ struct mtk_pcie_port {
struct phy *phy;
u32 lane;
u32 slot;
+   int irq;
struct irq_domain *irq_domain;
struct irq_domain *inner_domain;
struct irq_domain *msi_domain;
@@ -620,7 +622,7 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
struct mtk_pcie *pcie = port->pcie;
struct device *dev = pcie->dev;
struct platform_device *pdev = to_platform_device(dev);
-   int err, irq;
+   int err;
 
err = mtk_pcie_init_irq_domain(port, node);
if (err) {
@@ -628,8 +630,9 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
return err;
}
 
-   irq = platform_get_irq(pdev, port->slot);
-   irq_set_chained_handler_and_data(irq, mtk_pcie_intr_handler, port);
+   port->irq = platform_get_irq(pdev, port->slot);
+   irq_set_chained_handler_and_data(port->irq,
+mtk_pcie_intr_handler, port);
 
return 0;
 }
-- 
2.6.4



[PATCH v6 5/9] PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define after mtk_pcie_setup_irq

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

This is a prepare patch to fix enable MSI logic, move the function's
define later to avoid forward declaration of mtk_pcie_enable_msi in
the future. No functional changed.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 138 -
 1 file changed, 69 insertions(+), 69 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index ead6005..654a63e 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -392,75 +392,6 @@ static struct pci_ops mtk_pcie_ops_v2 = {
.write = mtk_pcie_config_write,
 };
 
-static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
-{
-   struct mtk_pcie *pcie = port->pcie;
-   struct resource *mem = >mem;
-   const struct mtk_pcie_soc *soc = port->pcie->soc;
-   u32 val;
-   size_t size;
-   int err;
-
-   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
-   if (pcie->base) {
-   val = readl(pcie->base + PCIE_SYS_CFG_V2);
-   val |= PCIE_CSR_LTSSM_EN(port->slot) |
-  PCIE_CSR_ASPM_L1_EN(port->slot);
-   writel(val, pcie->base + PCIE_SYS_CFG_V2);
-   }
-
-   /* Assert all reset signals */
-   writel(0, port->base + PCIE_RST_CTRL);
-
-   /*
-* Enable PCIe link down reset, if link status changed from link up to
-* link down, this will reset MAC control registers and configuration
-* space.
-*/
-   writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
-
-   /* De-assert PHY, PE, PIPE, MAC and configuration reset */
-   val = readl(port->base + PCIE_RST_CTRL);
-   val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
-  PCIE_MAC_SRSTB | PCIE_CRSTB;
-   writel(val, port->base + PCIE_RST_CTRL);
-
-   /* Set up vendor ID and class code */
-   if (soc->need_fix_class_id) {
-   val = PCI_VENDOR_ID_MEDIATEK;
-   writew(val, port->base + PCIE_CONF_VEND_ID);
-
-   val = PCI_CLASS_BRIDGE_PCI;
-   writew(val, port->base + PCIE_CONF_CLASS_ID);
-   }
-
-   /* 100ms timeout value should be enough for Gen1/2 training */
-   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
-!!(val & PCIE_PORT_LINKUP_V2), 20,
-100 * USEC_PER_MSEC);
-   if (err)
-   return -ETIMEDOUT;
-
-   /* Set INTx mask */
-   val = readl(port->base + PCIE_INT_MASK);
-   val &= ~INTX_MASK;
-   writel(val, port->base + PCIE_INT_MASK);
-
-   /* Set AHB to PCIe translation windows */
-   size = mem->end - mem->start;
-   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
-   writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
-
-   val = upper_32_bits(mem->start);
-   writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
-
-   /* Set PCIe to AXI translation memory space.*/
-   val = fls(0x) | WIN_ENABLE;
-   writel(val, port->base + PCIE_AXI_WINDOW0);
-
-   return 0;
-}
-
 static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
@@ -705,6 +636,75 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
return 0;
 }
 
+static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
+{
+   struct mtk_pcie *pcie = port->pcie;
+   struct resource *mem = >mem;
+   const struct mtk_pcie_soc *soc = port->pcie->soc;
+   u32 val;
+   size_t size;
+   int err;
+
+   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
+   if (pcie->base) {
+   val = readl(pcie->base + PCIE_SYS_CFG_V2);
+   val |= PCIE_CSR_LTSSM_EN(port->slot) |
+  PCIE_CSR_ASPM_L1_EN(port->slot);
+   writel(val, pcie->base + PCIE_SYS_CFG_V2);
+   }
+
+   /* Assert all reset signals */
+   writel(0, port->base + PCIE_RST_CTRL);
+
+   /*
+* Enable PCIe link down reset, if link status changed from link up to
+* link down, this will reset MAC control registers and configuration
+* space.
+*/
+   writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
+
+   /* De-assert PHY, PE, PIPE, MAC and configuration reset */
+   val = readl(port->base + PCIE_RST_CTRL);
+   val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
+  PCIE_MAC_SRSTB | PCIE_CRSTB;
+   writel(val, port->base + PCIE_RST_CTRL);
+
+   /* Set up vendor ID and class code */
+   if (soc->need_fix_class_id) {
+   val = PCI_VENDOR_ID_MEDIATEK;
+   writew(val, port->base + PCIE_CONF_VEND_ID);
+
+   val = PCI_CLASS_BRIDGE_PCI;
+   writew(val, port->base + 

[PATCH v6 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

The Mediatek's host controller has two slots, each with it's own control
registers. The host driver need to identify which slot was connected
in order to access the device's configuration space. There's problem
for current host driver to find out which slot was connected to for
a given EP device.

Assuming each slot have connect with one EP device as below:

host bridge
  bus 0 --> __|___
   |  |
   |  |
 slot 0 slot 1
  bus 1 -->|bus 2 --> |
   |  |
 EP 0   EP 1

During PCI enumeration, system software will scan all the PCI device
starting from devfn 0. So it will get the proper port for slot0 and
slot1 device when using PCI_SLOT(devfn) for match. But it will get
the wrong slot for EP1: The devfn will be start from 0 when scanning
EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
for port0's slot value. So the host driver should not using EP's devfn
but the slot's devfn(the slot which EP was connected to) for match.

This patch fix the mtk_pcie_find_port's logic by using the slot's
devfn for match if finding device connected to the subordinate bus.

Signed-off-by: Honghui Zhang 
---
 drivers/pci/controller/pcie-mediatek.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index dae..288b8e2 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -337,6 +337,17 @@ static struct mtk_pcie_port *mtk_pcie_find_port(struct 
pci_bus *bus,
 {
struct mtk_pcie *pcie = bus->sysdata;
struct mtk_pcie_port *port;
+   struct pci_dev *dev = NULL;
+
+   /*
+* Walk the bus hierarchy to get the devfn value
+* of the port in the root bus.
+*/
+   while (bus && bus->number) {
+   dev = bus->self;
+   bus = dev->bus;
+   devfn = dev->devfn;
+   }
 
list_for_each_entry(port, >ports, list)
if (port->slot == PCI_SLOT(devfn))
-- 
2.6.4



[PATCH v6 6/9] PCI: mediatek: Fixup enable msi logic by enable msi after clock enabled

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

The commit 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and
MT7622") added MSI support but enable MSI in wrong place, clocks was not
enabled when enable MSI. This patch fix this issue by calling
mtk_pcie_enable_msi in mtk_pcie_startup_port_v2 since the clock was all
enabled at that time.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 654a63e..d3f4694 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -568,8 +568,6 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
*port,
ret = mtk_pcie_allocate_msi_domains(port);
if (ret)
return ret;
-
-   mtk_pcie_enable_msi(port);
}
 
return 0;
@@ -690,6 +688,9 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
*port)
val &= ~INTX_MASK;
writel(val, port->base + PCIE_INT_MASK);
 
+   if (IS_ENABLED(CONFIG_PCI_MSI))
+   mtk_pcie_enable_msi(port);
+
/* Set AHB to PCIe translation windows */
size = mem->end - mem->start;
val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
-- 
2.6.4



[PATCH v6 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

This patchset includes misc patchs:

The patch 1 fixup the mtk_pcie_find_port logic which will cause system
could not touch the EP's configuration space that connected to PCIe slot 1.

The patch 2 fixup the class type for MT7622.
The patch 6 fixup the enable msi logic, the operation to enable msi
should be after system clock is enabled. Call mtk_pcie_enable_msi in
mtk_pcie_startup_port_v2 since the clock was all enabled at that time.

The patch 7 was rebased and refactor of the v4 patch[1], changes are:
 -Add PM support for MT7622.
 -Using mtk_pcie_enable_port to re-establish the link when resumed.
 -Rebased on this patchset.

The patch 9 add loadable kernel module support.

[1] https://patchwork.kernel.org/patch/10479079

Change since v5:
 - A bit improvement of mtk_pcie_find_port suggest by Lorenzo.
 - Add fixup tags of fix enable MSI logic in patch 6.
 - Add Acked-by tags from Ryder.

Change since v4:
 - Add patch 2 to fixup class type for MT7622.
 - Add patch 3 to remove the redundant dev->pm_domain check
 - Add patch 4 to covert to use pci_host_probe
 - Add patch 5 to re-arrange the function define, this is a prepare patch for
   fixup the enable_msi logic, no functional changed have been made by this one.
 - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for tear
   down the irq when remove the kernel module.
 - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
easier
   for the patch 1.
 - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was not
   supported, then those pm callbacks will never be executed for MT7622. So the
   .pm_support is not needed.

Change since v3:
 - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third patch.
 - Rebase to 4.19-rc1.

Change since v2:
 - Fix the list_for_each_entry_safe parameter error.
 - Add Ryder's Acked-by flag.

Change since v1:
 - A bit of code refact of the first patch suggested by Andy Shevchenko, and
   commit message updated.
 - Using __maybe_unused.
 - Remove the redundant list_empty check of the fourth patch.


Honghui Zhang (9):
  PCI: mediatek: Using slot's devfn for compare to fix
mtk_pcie_find_port logic
  PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI
  PCI: mediatek: Remove the redundant dev->pm_domain check
  PCI: mediatek: Convert to use pci_host_probe()
  PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
after mtk_pcie_setup_irq
  PCI: mediatek: Fixup enable msi logic by enable msi after clock
enabled
  PCI: mediatek: Add system pm support for MT2712 and MT7622
  PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
  PCI: mediatek: Add loadable kernel module support

 drivers/pci/controller/Kconfig |   2 +-
 drivers/pci/controller/pcie-mediatek.c | 320 +
 2 files changed, 205 insertions(+), 117 deletions(-)

-- 
2.6.4



[PATCH v6 5/9] PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define after mtk_pcie_setup_irq

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

This is a prepare patch to fix enable MSI logic, move the function's
define later to avoid forward declaration of mtk_pcie_enable_msi in
the future. No functional changed.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 138 -
 1 file changed, 69 insertions(+), 69 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index ead6005..654a63e 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -392,75 +392,6 @@ static struct pci_ops mtk_pcie_ops_v2 = {
.write = mtk_pcie_config_write,
 };
 
-static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
-{
-   struct mtk_pcie *pcie = port->pcie;
-   struct resource *mem = >mem;
-   const struct mtk_pcie_soc *soc = port->pcie->soc;
-   u32 val;
-   size_t size;
-   int err;
-
-   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
-   if (pcie->base) {
-   val = readl(pcie->base + PCIE_SYS_CFG_V2);
-   val |= PCIE_CSR_LTSSM_EN(port->slot) |
-  PCIE_CSR_ASPM_L1_EN(port->slot);
-   writel(val, pcie->base + PCIE_SYS_CFG_V2);
-   }
-
-   /* Assert all reset signals */
-   writel(0, port->base + PCIE_RST_CTRL);
-
-   /*
-* Enable PCIe link down reset, if link status changed from link up to
-* link down, this will reset MAC control registers and configuration
-* space.
-*/
-   writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
-
-   /* De-assert PHY, PE, PIPE, MAC and configuration reset */
-   val = readl(port->base + PCIE_RST_CTRL);
-   val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
-  PCIE_MAC_SRSTB | PCIE_CRSTB;
-   writel(val, port->base + PCIE_RST_CTRL);
-
-   /* Set up vendor ID and class code */
-   if (soc->need_fix_class_id) {
-   val = PCI_VENDOR_ID_MEDIATEK;
-   writew(val, port->base + PCIE_CONF_VEND_ID);
-
-   val = PCI_CLASS_BRIDGE_PCI;
-   writew(val, port->base + PCIE_CONF_CLASS_ID);
-   }
-
-   /* 100ms timeout value should be enough for Gen1/2 training */
-   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
-!!(val & PCIE_PORT_LINKUP_V2), 20,
-100 * USEC_PER_MSEC);
-   if (err)
-   return -ETIMEDOUT;
-
-   /* Set INTx mask */
-   val = readl(port->base + PCIE_INT_MASK);
-   val &= ~INTX_MASK;
-   writel(val, port->base + PCIE_INT_MASK);
-
-   /* Set AHB to PCIe translation windows */
-   size = mem->end - mem->start;
-   val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
-   writel(val, port->base + PCIE_AHB_TRANS_BASE0_L);
-
-   val = upper_32_bits(mem->start);
-   writel(val, port->base + PCIE_AHB_TRANS_BASE0_H);
-
-   /* Set PCIe to AXI translation memory space.*/
-   val = fls(0x) | WIN_ENABLE;
-   writel(val, port->base + PCIE_AXI_WINDOW0);
-
-   return 0;
-}
-
 static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
@@ -705,6 +636,75 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
return 0;
 }
 
+static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
+{
+   struct mtk_pcie *pcie = port->pcie;
+   struct resource *mem = >mem;
+   const struct mtk_pcie_soc *soc = port->pcie->soc;
+   u32 val;
+   size_t size;
+   int err;
+
+   /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
+   if (pcie->base) {
+   val = readl(pcie->base + PCIE_SYS_CFG_V2);
+   val |= PCIE_CSR_LTSSM_EN(port->slot) |
+  PCIE_CSR_ASPM_L1_EN(port->slot);
+   writel(val, pcie->base + PCIE_SYS_CFG_V2);
+   }
+
+   /* Assert all reset signals */
+   writel(0, port->base + PCIE_RST_CTRL);
+
+   /*
+* Enable PCIe link down reset, if link status changed from link up to
+* link down, this will reset MAC control registers and configuration
+* space.
+*/
+   writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
+
+   /* De-assert PHY, PE, PIPE, MAC and configuration reset */
+   val = readl(port->base + PCIE_RST_CTRL);
+   val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
+  PCIE_MAC_SRSTB | PCIE_CRSTB;
+   writel(val, port->base + PCIE_RST_CTRL);
+
+   /* Set up vendor ID and class code */
+   if (soc->need_fix_class_id) {
+   val = PCI_VENDOR_ID_MEDIATEK;
+   writew(val, port->base + PCIE_CONF_VEND_ID);
+
+   val = PCI_CLASS_BRIDGE_PCI;
+   writew(val, port->base + 

[PATCH v6 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

The Mediatek's host controller has two slots, each with it's own control
registers. The host driver need to identify which slot was connected
in order to access the device's configuration space. There's problem
for current host driver to find out which slot was connected to for
a given EP device.

Assuming each slot have connect with one EP device as below:

host bridge
  bus 0 --> __|___
   |  |
   |  |
 slot 0 slot 1
  bus 1 -->|bus 2 --> |
   |  |
 EP 0   EP 1

During PCI enumeration, system software will scan all the PCI device
starting from devfn 0. So it will get the proper port for slot0 and
slot1 device when using PCI_SLOT(devfn) for match. But it will get
the wrong slot for EP1: The devfn will be start from 0 when scanning
EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
for port0's slot value. So the host driver should not using EP's devfn
but the slot's devfn(the slot which EP was connected to) for match.

This patch fix the mtk_pcie_find_port's logic by using the slot's
devfn for match if finding device connected to the subordinate bus.

Signed-off-by: Honghui Zhang 
---
 drivers/pci/controller/pcie-mediatek.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index dae..288b8e2 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -337,6 +337,17 @@ static struct mtk_pcie_port *mtk_pcie_find_port(struct 
pci_bus *bus,
 {
struct mtk_pcie *pcie = bus->sysdata;
struct mtk_pcie_port *port;
+   struct pci_dev *dev = NULL;
+
+   /*
+* Walk the bus hierarchy to get the devfn value
+* of the port in the root bus.
+*/
+   while (bus && bus->number) {
+   dev = bus->self;
+   bus = dev->bus;
+   devfn = dev->devfn;
+   }
 
list_for_each_entry(port, >ports, list)
if (port->slot == PCI_SLOT(devfn))
-- 
2.6.4



[PATCH v6 6/9] PCI: mediatek: Fixup enable msi logic by enable msi after clock enabled

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

The commit 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and
MT7622") added MSI support but enable MSI in wrong place, clocks was not
enabled when enable MSI. This patch fix this issue by calling
mtk_pcie_enable_msi in mtk_pcie_startup_port_v2 since the clock was all
enabled at that time.

Signed-off-by: Honghui Zhang 
Acked-by: Ryder Lee 
---
 drivers/pci/controller/pcie-mediatek.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c 
b/drivers/pci/controller/pcie-mediatek.c
index 654a63e..d3f4694 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -568,8 +568,6 @@ static int mtk_pcie_init_irq_domain(struct mtk_pcie_port 
*port,
ret = mtk_pcie_allocate_msi_domains(port);
if (ret)
return ret;
-
-   mtk_pcie_enable_msi(port);
}
 
return 0;
@@ -690,6 +688,9 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
*port)
val &= ~INTX_MASK;
writel(val, port->base + PCIE_INT_MASK);
 
+   if (IS_ENABLED(CONFIG_PCI_MSI))
+   mtk_pcie_enable_msi(port);
+
/* Set AHB to PCIe translation windows */
size = mem->end - mem->start;
val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size));
-- 
2.6.4



[PATCH v6 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

2018-10-07 Thread honghui.zhang
From: Honghui Zhang 

This patchset includes misc patchs:

The patch 1 fixup the mtk_pcie_find_port logic which will cause system
could not touch the EP's configuration space that connected to PCIe slot 1.

The patch 2 fixup the class type for MT7622.
The patch 6 fixup the enable msi logic, the operation to enable msi
should be after system clock is enabled. Call mtk_pcie_enable_msi in
mtk_pcie_startup_port_v2 since the clock was all enabled at that time.

The patch 7 was rebased and refactor of the v4 patch[1], changes are:
 -Add PM support for MT7622.
 -Using mtk_pcie_enable_port to re-establish the link when resumed.
 -Rebased on this patchset.

The patch 9 add loadable kernel module support.

[1] https://patchwork.kernel.org/patch/10479079

Change since v5:
 - A bit improvement of mtk_pcie_find_port suggest by Lorenzo.
 - Add fixup tags of fix enable MSI logic in patch 6.
 - Add Acked-by tags from Ryder.

Change since v4:
 - Add patch 2 to fixup class type for MT7622.
 - Add patch 3 to remove the redundant dev->pm_domain check
 - Add patch 4 to covert to use pci_host_probe
 - Add patch 5 to re-arrange the function define, this is a prepare patch for
   fixup the enable_msi logic, no functional changed have been made by this one.
 - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for tear
   down the irq when remove the kernel module.
 - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
easier
   for the patch 1.
 - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was not
   supported, then those pm callbacks will never be executed for MT7622. So the
   .pm_support is not needed.

Change since v3:
 - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third patch.
 - Rebase to 4.19-rc1.

Change since v2:
 - Fix the list_for_each_entry_safe parameter error.
 - Add Ryder's Acked-by flag.

Change since v1:
 - A bit of code refact of the first patch suggested by Andy Shevchenko, and
   commit message updated.
 - Using __maybe_unused.
 - Remove the redundant list_empty check of the fourth patch.


Honghui Zhang (9):
  PCI: mediatek: Using slot's devfn for compare to fix
mtk_pcie_find_port logic
  PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI
  PCI: mediatek: Remove the redundant dev->pm_domain check
  PCI: mediatek: Convert to use pci_host_probe()
  PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
after mtk_pcie_setup_irq
  PCI: mediatek: Fixup enable msi logic by enable msi after clock
enabled
  PCI: mediatek: Add system pm support for MT2712 and MT7622
  PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
  PCI: mediatek: Add loadable kernel module support

 drivers/pci/controller/Kconfig |   2 +-
 drivers/pci/controller/pcie-mediatek.c | 320 +
 2 files changed, 205 insertions(+), 117 deletions(-)

-- 
2.6.4



[PATCH 4/4] dts/arm64/layerscape: Clean PCIe controller compatible strings

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.

Signed-off-by: Hou Zhiqiang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi |  8 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 12 
 6 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 68ac78c4564d..d3fe0771d3a0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -475,7 +475,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1012a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1012a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 6cc4c87614b6..1b61782df73e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -661,7 +661,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -686,7 +686,7 @@
};
 
pcie@350 {
-   compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -711,7 +711,7 @@
};
 
pcie@360 {
-   compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x50 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 3a2a14a8e187..71585aefe1ef 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -630,7 +630,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -655,7 +655,7 @@
};
 
pcie@350 {
-   compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -680,7 +680,7 @@
};
 
pcie@360 {
-   compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x50 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index a07f612ab56b..10b253c88a16 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -512,7 +512,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1088a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x20 0x 0x0 

[PATCH 4/4] dts/arm64/layerscape: Clean PCIe controller compatible strings

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.

Signed-off-by: Hou Zhiqiang 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi |  8 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 12 
 6 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 68ac78c4564d..d3fe0771d3a0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -475,7 +475,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1012a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1012a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 6cc4c87614b6..1b61782df73e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -661,7 +661,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -686,7 +686,7 @@
};
 
pcie@350 {
-   compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -711,7 +711,7 @@
};
 
pcie@360 {
-   compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x50 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 3a2a14a8e187..71585aefe1ef 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -630,7 +630,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -655,7 +655,7 @@
};
 
pcie@350 {
-   compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -680,7 +680,7 @@
};
 
pcie@360 {
-   compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x50 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index a07f612ab56b..10b253c88a16 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -512,7 +512,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1088a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x20 0x 0x0 

[PATCH 2/4] doc/layerscape-pci: removed unsuitable compatible string

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the compatible string "snps,dw-pcie", it is for the reference
platform driver for PCI RC IP Protoyping Kits based on the ARC SDP,
so it is not suitable for all platform with designware PCIe controller,
and platform vendors have themselves' drivers.

The compatible string "snsp,dw-pcie" was added by mistake and it's not
matched that time, but it is matched because pcie drivers has been
collected recently.

Signed-off-by: Hou Zhiqiang 
---
 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 5eb1c202932f..9b2b8d66d1f4 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -13,8 +13,8 @@ information.
 
 Required properties:
 - compatible: should contain the platform identifier such as:
-"fsl,ls1021a-pcie", "snps,dw-pcie"
-"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
+"fsl,ls1021a-pcie"
+"fsl,ls2080a-pcie", "fsl,ls2085a-pcie"
 "fsl,ls2088a-pcie"
 "fsl,ls1088a-pcie"
 "fsl,ls1046a-pcie"
@@ -36,7 +36,7 @@ Required properties:
 Example:
 
pcie@340 {
-   compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001   /* controller registers 
*/
   0x40 0x 0x0 0x2000>; /* configuration space 
*/
reg-names = "regs", "config";
-- 
2.17.1



[PATCH 3/4] dts/arm/ls1021a: Clean PCIe controller compatible strings

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.

Signed-off-by: Hou Zhiqiang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index f70025c2ab0f..13e91d577a26 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -716,7 +716,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -739,7 +739,7 @@
};
 
pcie@350 {
-   compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0350 0x0 0x0001   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-- 
2.17.1



[PATCH 2/4] doc/layerscape-pci: removed unsuitable compatible string

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the compatible string "snps,dw-pcie", it is for the reference
platform driver for PCI RC IP Protoyping Kits based on the ARC SDP,
so it is not suitable for all platform with designware PCIe controller,
and platform vendors have themselves' drivers.

The compatible string "snsp,dw-pcie" was added by mistake and it's not
matched that time, but it is matched because pcie drivers has been
collected recently.

Signed-off-by: Hou Zhiqiang 
---
 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 5eb1c202932f..9b2b8d66d1f4 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -13,8 +13,8 @@ information.
 
 Required properties:
 - compatible: should contain the platform identifier such as:
-"fsl,ls1021a-pcie", "snps,dw-pcie"
-"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
+"fsl,ls1021a-pcie"
+"fsl,ls2080a-pcie", "fsl,ls2085a-pcie"
 "fsl,ls2088a-pcie"
 "fsl,ls1088a-pcie"
 "fsl,ls1046a-pcie"
@@ -36,7 +36,7 @@ Required properties:
 Example:
 
pcie@340 {
-   compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001   /* controller registers 
*/
   0x40 0x 0x0 0x2000>; /* configuration space 
*/
reg-names = "regs", "config";
-- 
2.17.1



[PATCH 3/4] dts/arm/ls1021a: Clean PCIe controller compatible strings

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.

Signed-off-by: Hou Zhiqiang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index f70025c2ab0f..13e91d577a26 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -716,7 +716,7 @@
};
 
pcie@340 {
-   compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
@@ -739,7 +739,7 @@
};
 
pcie@350 {
-   compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+   compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0350 0x0 0x0001   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-- 
2.17.1



[PATCH 1/4] doc/layerscape-pci: update the PCIe compatible strings

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

The pcie compatible string for LS1043A was lost, so add it.

Signed-off-by: Hou Zhiqiang 
---
 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 66df1e81e0b8..5eb1c202932f 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -18,6 +18,7 @@ Required properties:
 "fsl,ls2088a-pcie"
 "fsl,ls1088a-pcie"
 "fsl,ls1046a-pcie"
+"fsl,ls1043a-pcie"
 "fsl,ls1012a-pcie"
 - reg: base addresses and lengths of the PCIe controller register blocks.
 - interrupts: A list of interrupt outputs of the controller. Must contain an
-- 
2.17.1



[PATCH 0/4] dts/layerscape-pci: removed unsuitable compatible string

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the compatible string "snps,dw-pcie" from FSL layerscape-pci compatible
string list.

Hou Zhiqiang (4):
  doc/layerscape-pci: update the PCIe compatible strings
  doc/layerscape-pci: removed unsuitable compatible string
  dts/arm/ls1021a: Clean PCIe controller compatible strings
  dts/arm64/layerscape: Clean PCIe controller compatible strings

 .../devicetree/bindings/pci/layerscape-pci.txt   |  7 ---
 arch/arm/boot/dts/ls1021a.dtsi   |  4 ++--
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi   |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi   |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi   |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi   |  8 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi   | 12 
 8 files changed, 24 insertions(+), 27 deletions(-)

-- 
2.17.1



[PATCH 1/4] doc/layerscape-pci: update the PCIe compatible strings

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

The pcie compatible string for LS1043A was lost, so add it.

Signed-off-by: Hou Zhiqiang 
---
 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 66df1e81e0b8..5eb1c202932f 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -18,6 +18,7 @@ Required properties:
 "fsl,ls2088a-pcie"
 "fsl,ls1088a-pcie"
 "fsl,ls1046a-pcie"
+"fsl,ls1043a-pcie"
 "fsl,ls1012a-pcie"
 - reg: base addresses and lengths of the PCIe controller register blocks.
 - interrupts: A list of interrupt outputs of the controller. Must contain an
-- 
2.17.1



[PATCH 0/4] dts/layerscape-pci: removed unsuitable compatible string

2018-10-07 Thread Zhiqiang Hou
From: Hou Zhiqiang 

Removed the compatible string "snps,dw-pcie" from FSL layerscape-pci compatible
string list.

Hou Zhiqiang (4):
  doc/layerscape-pci: update the PCIe compatible strings
  doc/layerscape-pci: removed unsuitable compatible string
  dts/arm/ls1021a: Clean PCIe controller compatible strings
  dts/arm64/layerscape: Clean PCIe controller compatible strings

 .../devicetree/bindings/pci/layerscape-pci.txt   |  7 ---
 arch/arm/boot/dts/ls1021a.dtsi   |  4 ++--
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi   |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi   |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi   |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi   |  6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi   |  8 
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi   | 12 
 8 files changed, 24 insertions(+), 27 deletions(-)

-- 
2.17.1



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

2018-10-07 Thread Stephen Rothwell
Hi Marc,

After merging the irqchip tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from drivers/irqchip/irq-madera.c:21:
include/linux/irqchip/irq-madera.h: In function 'madera_get_irq_mapping':
include/linux/irqchip/irq-madera.h:99:37: error: 'struct madera' has no member 
named 'irq_data'; did you mean 'irq_dev'?
  return regmap_irq_get_virq(madera->irq_data, irq);
 ^~~~
 irq_dev
drivers/irqchip/irq-madera.c: In function 'madera_irq_probe':
drivers/irqchip/irq-madera.c:217:34: error: 'struct madera' has no member named 
'irq_data'; did you mean 'irq_dev'?
   _irq_chip, >irq_data);
  ^~~~
  irq_dev
drivers/irqchip/irq-madera.c: In function 'madera_irq_remove':
drivers/irqchip/irq-madera.c:238:43: error: 'struct madera' has no member named 
'irq_data'; did you mean 'irq_dev'?
  regmap_del_irq_chip(madera->irq, madera->irq_data);
   ^~~~
   irq_dev

Caused by commit

  b817ff5c9509 ("irqchip: Add driver for Cirrus Logic Madera codecs")

I have used the irqchip tree from next-20181005 for today.

-- 
Cheers,
Stephen Rothwell


pgpWymCKW9y_T.pgp
Description: OpenPGP digital signature


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

2018-10-07 Thread Stephen Rothwell
Hi Marc,

After merging the irqchip tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from drivers/irqchip/irq-madera.c:21:
include/linux/irqchip/irq-madera.h: In function 'madera_get_irq_mapping':
include/linux/irqchip/irq-madera.h:99:37: error: 'struct madera' has no member 
named 'irq_data'; did you mean 'irq_dev'?
  return regmap_irq_get_virq(madera->irq_data, irq);
 ^~~~
 irq_dev
drivers/irqchip/irq-madera.c: In function 'madera_irq_probe':
drivers/irqchip/irq-madera.c:217:34: error: 'struct madera' has no member named 
'irq_data'; did you mean 'irq_dev'?
   _irq_chip, >irq_data);
  ^~~~
  irq_dev
drivers/irqchip/irq-madera.c: In function 'madera_irq_remove':
drivers/irqchip/irq-madera.c:238:43: error: 'struct madera' has no member named 
'irq_data'; did you mean 'irq_dev'?
  regmap_del_irq_chip(madera->irq, madera->irq_data);
   ^~~~
   irq_dev

Caused by commit

  b817ff5c9509 ("irqchip: Add driver for Cirrus Logic Madera codecs")

I have used the irqchip tree from next-20181005 for today.

-- 
Cheers,
Stephen Rothwell


pgpWymCKW9y_T.pgp
Description: OpenPGP digital signature


Re: [PATCH v5 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic

2018-10-07 Thread Honghui Zhang
On Tue, 2018-10-02 at 11:59 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 01, 2018 at 03:36:41PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Sep 28, 2018 at 06:04:32PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The Mediatek's host controller has two slots, each with it's own control
> > > registers. The host driver need to identify which slot was connected
> > > in order to access the device's configuration space. There's problem
> > > for current host driver to find out which slot was connected to for
> > > a given EP device.
> > > 
> > > Assuming each slot have connect with one EP device as below:
> > > 
> > > host bridge
> > >   bus 0 --> __|___
> > >|  |
> > >|  |
> > >  slot 0 slot 1
> > >   bus 1 -->|bus 2 --> |
> > >|  |
> > >  EP 0   EP 1
> > > 
> > > During PCI enumeration, system software will scan all the PCI device
> > > starting from devfn 0. So it will get the proper port for slot0 and
> > > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > > for port0's slot value. So the host driver should not using EP's devfn
> > > but the slot's devfn(the slot which EP was connected to) for match.
> > > 
> > > This patch fix the mtk_pcie_find_port's logic by using the slot's
> > > devfn for match if finding device connected to the subordinate bus.
> > > 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 17 -
> > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index dae..264e03f 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -337,10 +337,25 @@ static struct mtk_pcie_port 
> > > *mtk_pcie_find_port(struct pci_bus *bus,
> > >  {
> > >   struct mtk_pcie *pcie = bus->sysdata;
> > >   struct mtk_pcie_port *port;
> > > + struct pci_dev *dev = NULL;
> > > +
> > > + /*
> > > +  * Walk the bus hierarchy to get the devfn value
> > > +  * of the port in the root bus.
> > > +  */
> > > + while (bus && bus->number) {
> > > + dev = bus->self;
> > > + bus = dev->bus;
> > 
> > If you add:
> > 
> > devfn = dev->devfn;
> > 
> > here
> > 
> > > + }
> > > +
> > > + list_for_each_entry(port, >ports, list) {
> > > + /* Using slot's devfn to compare for subordinary bus. */
> > > + if (dev)
> > > + devfn = dev->devfn;
> > 
> > You can remove this ugly hunk altogether (and dev initialization
> > to NULL).
> 
> Hi Honghui,
> 
> if you can make this change I would merge this series, it has been
> been in the mailing lists for a while, I can make that change too
> just let me know please.
> 

Hi, Lorenzo, sorry for the late reply.

I tried your advise and it works fine.

I will send another version to fix this, as well as to add a fix tag in
the commit message of patch 6.

thanks

> Thanks,
> Lorenzo




Re: [PATCH v5 1/9] PCI: mediatek: Using slot's devfn for compare to fix mtk_pcie_find_port logic

2018-10-07 Thread Honghui Zhang
On Tue, 2018-10-02 at 11:59 +0100, Lorenzo Pieralisi wrote:
> On Mon, Oct 01, 2018 at 03:36:41PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Sep 28, 2018 at 06:04:32PM +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > The Mediatek's host controller has two slots, each with it's own control
> > > registers. The host driver need to identify which slot was connected
> > > in order to access the device's configuration space. There's problem
> > > for current host driver to find out which slot was connected to for
> > > a given EP device.
> > > 
> > > Assuming each slot have connect with one EP device as below:
> > > 
> > > host bridge
> > >   bus 0 --> __|___
> > >|  |
> > >|  |
> > >  slot 0 slot 1
> > >   bus 1 -->|bus 2 --> |
> > >|  |
> > >  EP 0   EP 1
> > > 
> > > During PCI enumeration, system software will scan all the PCI device
> > > starting from devfn 0. So it will get the proper port for slot0 and
> > > slot1 device when using PCI_SLOT(devfn) for match. But it will get
> > > the wrong slot for EP1: The devfn will be start from 0 when scanning
> > > EP1 behind slot1, it will get port0 since the PCI_SLOT(EP1) is match
> > > for port0's slot value. So the host driver should not using EP's devfn
> > > but the slot's devfn(the slot which EP was connected to) for match.
> > > 
> > > This patch fix the mtk_pcie_find_port's logic by using the slot's
> > > devfn for match if finding device connected to the subordinate bus.
> > > 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 17 -
> > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index dae..264e03f 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -337,10 +337,25 @@ static struct mtk_pcie_port 
> > > *mtk_pcie_find_port(struct pci_bus *bus,
> > >  {
> > >   struct mtk_pcie *pcie = bus->sysdata;
> > >   struct mtk_pcie_port *port;
> > > + struct pci_dev *dev = NULL;
> > > +
> > > + /*
> > > +  * Walk the bus hierarchy to get the devfn value
> > > +  * of the port in the root bus.
> > > +  */
> > > + while (bus && bus->number) {
> > > + dev = bus->self;
> > > + bus = dev->bus;
> > 
> > If you add:
> > 
> > devfn = dev->devfn;
> > 
> > here
> > 
> > > + }
> > > +
> > > + list_for_each_entry(port, >ports, list) {
> > > + /* Using slot's devfn to compare for subordinary bus. */
> > > + if (dev)
> > > + devfn = dev->devfn;
> > 
> > You can remove this ugly hunk altogether (and dev initialization
> > to NULL).
> 
> Hi Honghui,
> 
> if you can make this change I would merge this series, it has been
> been in the mailing lists for a while, I can make that change too
> just let me know please.
> 

Hi, Lorenzo, sorry for the late reply.

I tried your advise and it works fine.

I will send another version to fix this, as well as to add a fix tag in
the commit message of patch 6.

thanks

> Thanks,
> Lorenzo




Re: [PATCH] clk: keystone: add missing MODULE_LICENSE

2018-10-07 Thread Stephen Boyd
Quoting Arnd Bergmann (2018-10-05 09:11:15)
> A randconfig build showed that two clk modules have no license tag:
> 
> WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/gate.o
> see include/linux/module.h for more information
> WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/pll.o
> see include/linux/module.h for more information
> 
> Add the appropriate information from the comment at the start of the
> two files.
> 
> Signed-off-by: Arnd Bergmann 
> ---

Applied to clk-next



Re: [PATCH] clk: keystone: add missing MODULE_LICENSE

2018-10-07 Thread Stephen Boyd
Quoting Arnd Bergmann (2018-10-05 09:11:15)
> A randconfig build showed that two clk modules have no license tag:
> 
> WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/gate.o
> see include/linux/module.h for more information
> WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/pll.o
> see include/linux/module.h for more information
> 
> Add the appropriate information from the comment at the start of the
> two files.
> 
> Signed-off-by: Arnd Bergmann 
> ---

Applied to clk-next



Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm

2018-10-07 Thread Tetsuo Handa
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int 
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> +   int mm_users = 0;
> 
> task = get_proc_task(file_inode(file));
> if (!task)
> @@ -1092,7 +1093,8 @@ static int __set_oom_adj(struct file *file, int 
> oom_adj, bool legacy)
> struct task_struct *p = find_lock_task_mm(task);
> 
> if (p) {
> -   if (atomic_read(>mm->mm_users) > 1) {
> +   mm_users = atomic_read(>mm->mm_users);
> +   if ((mm_users > 1) && (mm_users != 
> get_nr_threads(p))) {

How can this work (even before this patch)? When clone(CLONE_VM without 
CLONE_THREAD/CLONE_SIGHAND)
is requested, copy_process() calls copy_signal() in order to copy 
sig->oom_score_adj and
sig->oom_score_adj_min before calling copy_mm() in order to increment 
mm->mm_users, doesn't it?
Then, we will get two different "struct signal_struct" with different 
oom_score_adj/oom_score_adj_min
but one "struct mm_struct" shared by two thread groups.

> mm = p->mm;
> atomic_inc(>mm_count);
> }



Re: [PATCH] mm, oom_adj: avoid meaningless loop to find processes sharing mm

2018-10-07 Thread Tetsuo Handa
On 2018/10/08 10:19, Yong-Taek Lee wrote:
> @@ -1056,6 +1056,7 @@ static int __set_oom_adj(struct file *file, int 
> oom_adj, bool legacy)
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> +   int mm_users = 0;
> 
> task = get_proc_task(file_inode(file));
> if (!task)
> @@ -1092,7 +1093,8 @@ static int __set_oom_adj(struct file *file, int 
> oom_adj, bool legacy)
> struct task_struct *p = find_lock_task_mm(task);
> 
> if (p) {
> -   if (atomic_read(>mm->mm_users) > 1) {
> +   mm_users = atomic_read(>mm->mm_users);
> +   if ((mm_users > 1) && (mm_users != 
> get_nr_threads(p))) {

How can this work (even before this patch)? When clone(CLONE_VM without 
CLONE_THREAD/CLONE_SIGHAND)
is requested, copy_process() calls copy_signal() in order to copy 
sig->oom_score_adj and
sig->oom_score_adj_min before calling copy_mm() in order to increment 
mm->mm_users, doesn't it?
Then, we will get two different "struct signal_struct" with different 
oom_score_adj/oom_score_adj_min
but one "struct mm_struct" shared by two thread groups.

> mm = p->mm;
> atomic_inc(>mm_count);
> }



Re: [PATCH v5 2/2] clk: qcom: Add lpass clock controller driver for SDM845

2018-10-07 Thread Stephen Boyd
Quoting Taniya Das (2018-10-04 05:01:27)
> 
> On 9/29/2018 12:21 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-09-18 03:25:38)
> >> @@ -3469,6 +3495,8 @@ enum {
> >>  [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
> >>  [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
> >>  [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = 
> >> _qspi_cnoc_periph_ahb_clk.clkr,
> >> +   [GCC_LPASS_Q6_AXI_CLK] = NULL,
> >> +   [GCC_LPASS_SWAY_CLK] = NULL,
> >>   };
> >>   
> >>   static const struct qcom_reset_map gcc_sdm845_resets[] = {
> >> @@ -3583,6 +3611,13 @@ static int gcc_sdm845_probe(struct platform_device 
> >> *pdev)
> >>  if (ret)
> >>  return ret;
> >>   
> >> +   if (of_property_read_bool(pdev->dev.of_node, 
> >> "qcom,lpass-protected")) {
> > 
> > Shouldn't this be negated? So that we only add the clks when lpass isn't
> > protected?
> >
> 
> I was of the opinion to add the flag only when LPASS clocks are 
> required. But I am fine negating it too.

It's stating that lpass clks are protected, so presumably we wouldn't
add the property on devices without the XPU configured. This means that
most configurations would have it protected and then this flag is needed
almost all the time. O well!



Re: [PATCH v5 2/2] clk: qcom: Add lpass clock controller driver for SDM845

2018-10-07 Thread Stephen Boyd
Quoting Taniya Das (2018-10-04 05:01:27)
> 
> On 9/29/2018 12:21 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-09-18 03:25:38)
> >> @@ -3469,6 +3495,8 @@ enum {
> >>  [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
> >>  [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
> >>  [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = 
> >> _qspi_cnoc_periph_ahb_clk.clkr,
> >> +   [GCC_LPASS_Q6_AXI_CLK] = NULL,
> >> +   [GCC_LPASS_SWAY_CLK] = NULL,
> >>   };
> >>   
> >>   static const struct qcom_reset_map gcc_sdm845_resets[] = {
> >> @@ -3583,6 +3611,13 @@ static int gcc_sdm845_probe(struct platform_device 
> >> *pdev)
> >>  if (ret)
> >>  return ret;
> >>   
> >> +   if (of_property_read_bool(pdev->dev.of_node, 
> >> "qcom,lpass-protected")) {
> > 
> > Shouldn't this be negated? So that we only add the clks when lpass isn't
> > protected?
> >
> 
> I was of the opinion to add the flag only when LPASS clocks are 
> required. But I am fine negating it too.

It's stating that lpass clks are protected, so presumably we wouldn't
add the property on devices without the XPU configured. This means that
most configurations would have it protected and then this flag is needed
almost all the time. O well!



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

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/powercap/intel_rapl.c

between commit:

  17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")

from the pm tree and commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip 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 drivers/powercap/intel_rapl.c
index bb92874b1175,8cbfcce57a06..
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
.compute_time_window = rapl_compute_time_window_atom,
  };
  
 -#define RAPL_CPU(_model, _ops) {  \
 -  .vendor = X86_VENDOR_INTEL, \
 -  .family = 6,\
 -  .model = _model,\
 -  .driver_data = (kernel_ulong_t)&_ops,   \
 -  }
 -
  static const struct x86_cpu_id rapl_ids[] __initconst = {
 -  RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,  rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_IVYBRIDGE,  rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_HASWELL_CORE,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_HASWELL_X,  rapl_defaults_hsw_server),
 -
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server),
 -
 -  RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_SKYLAKE_X,  rapl_defaults_hsw_server),
 -  RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE,  rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt),
 -  RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,   rapl_defaults_cht),
 -  RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng),
 -  RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID,   rapl_defaults_ann),
 -  RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,  rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,   rapl_defaults_hsw_server),
 -  RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM,   rapl_defaults_hsw_server),
 +  INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core),
 +  INTEL_CPU_FAM6(SANDYBRIDGE_X,   rapl_defaults_core),
 +
 +  INTEL_CPU_FAM6(IVYBRIDGE,   rapl_defaults_core),
 +  INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core),
 +
 +  INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core),
 +  INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core),
 +  INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core),
 +  INTEL_CPU_FAM6(HASWELL_X,   rapl_defaults_hsw_server),
 +
 +  INTEL_CPU_FAM6(BROADWELL_CORE,  rapl_defaults_core),
 +  INTEL_CPU_FAM6(BROADWELL_GT3E,  rapl_defaults_core),
 +  INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core),
 +  INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server),
 +
 +  INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core),
 +  INTEL_CPU_FAM6(SKYLAKE_MOBILE,  rapl_defaults_core),
 +  INTEL_CPU_FAM6(SKYLAKE_X,   rapl_defaults_hsw_server),
 +  INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core),
 +  INTEL_CPU_FAM6(KABYLAKE_DESKTOP,rapl_defaults_core),
 +  INTEL_CPU_FAM6(CANNONLAKE_MOBILE,   rapl_defaults_core),
 +
-   INTEL_CPU_FAM6(ATOM_SILVERMONT1,rapl_defaults_byt),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
 +  INTEL_CPU_FAM6(ATOM_AIRMONT,rapl_defaults_cht),
-   INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng),
-   INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
++  

Re: [PATCH v6] clk: qcom: Add lpass clock controller driver for SDM845

2018-10-07 Thread Stephen Boyd
Quoting Taniya Das (2018-10-04 05:02:26)
> Add support for the lpass clock controller found on SDM845 based devices.
> This would allow lpass peripheral loader drivers to control the clocks to
> bring the subsystem out of reset.
> LPASS clocks present on the global clock controller would be registered
> with the clock framework based on the device tree flag. Also do not gate
> these clocks if they are left unused.

Why not gate them? This statement states what the code is doing, not why
it's doing it which is the more crucial information that should be
described in the commit text. Also, please add a comment about it to the
code next to the flag.

I am concerned that it doesn't make any sense though, so probably it
shouldn't be marked as CLK_IGNORE_UNUSED and it's papering over some
other larger bug that needs to be fixed.

> 
> Signed-off-by: Taniya Das 
> ---
> diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
> index 08d593e..6379b8b 100644
> --- a/drivers/clk/qcom/gcc-sdm845.c
> +++ b/drivers/clk/qcom/gcc-sdm845.c
> @@ -3169,6 +3169,32 @@ enum {
> },
>  };
> 
> +static struct clk_branch gcc_lpass_q6_axi_clk = {
> +   .halt_reg = 0x47000,
> +   .halt_check = BRANCH_HALT,
> +   .clkr = {
> +   .enable_reg = 0x47000,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "gcc_lpass_q6_axi_clk",
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
> +static struct clk_branch gcc_lpass_sway_clk = {
> +   .halt_reg = 0x47008,
> +   .halt_check = BRANCH_HALT,
> +   .clkr = {
> +   .enable_reg = 0x47008,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "gcc_lpass_sway_clk",
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
>  static struct gdsc pcie_0_gdsc = {
> .gdscr = 0x6b004,
> .pd = {
> @@ -3469,6 +3495,8 @@ enum {
> [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
> [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
> [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
> +   [GCC_LPASS_Q6_AXI_CLK] = NULL,
> +   [GCC_LPASS_SWAY_CLK] = NULL,
>  };
> 
>  static const struct qcom_reset_map gcc_sdm845_resets[] = {
> @@ -3583,6 +3611,13 @@ static int gcc_sdm845_probe(struct platform_device 
> *pdev)
> if (ret)
> return ret;
> 
> +   if (!of_property_read_bool(pdev->dev.of_node, 
> "qcom,lpass-protected")) {
> +   gcc_sdm845_clocks[GCC_LPASS_Q6_AXI_CLK] =
> +   _lpass_q6_axi_clk.clkr;
> +   gcc_sdm845_clocks[GCC_LPASS_SWAY_CLK] =
> +   _lpass_sway_clk.clkr;
> +   }
> +
> return qcom_cc_really_probe(pdev, _sdm845_desc, regmap);
>  }
> 
> diff --git a/drivers/clk/qcom/lpasscc-sdm845.c 
> b/drivers/clk/qcom/lpasscc-sdm845.c
> new file mode 100644
> index 000..f7b9b0f
> --- /dev/null
> +++ b/drivers/clk/qcom/lpasscc-sdm845.c
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 

Is this needed?

> +/* CLK_OFF would not toggle until LPASS is not out of reset */
> +static struct clk_branch lpass_qdsp6ss_xo_clk = {
> +   .halt_reg = 0x38,
> +   .halt_check = BRANCH_HALT_SKIP,
> +   .clkr = {
> +   .enable_reg = 0x38,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "lpass_qdsp6ss_xo_clk",
> +   .flags = CLK_IGNORE_UNUSED,
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
> +/* CLK_OFF would not toggle until LPASS is not out of reset */

Move this comment next to BRANCH_HALT_SKIP please so we know what it
relates to.

> +static struct clk_branch lpass_qdsp6ss_sleep_clk = {
> +   .halt_reg = 0x3c,
> +   .halt_check = BRANCH_HALT_SKIP,
> +   .clkr = {
> +   .enable_reg = 0x3c,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "lpass_qdsp6ss_sleep_clk",
> +   .flags = CLK_IGNORE_UNUSED,
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
> +static int lpass_clocks_sdm845_probe(struct platform_device *pdev, int index,
> +const struct qcom_cc_desc *desc)
> +{
> +   struct regmap *regmap;
> +   struct resource *res;
> +   void __iomem *base;
> +
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> +   base = devm_ioremap_resource(>dev, res);
> +   if (IS_ERR(base))
> +   return PTR_ERR(base);
> +
> +   regmap = devm_regmap_init_mmio(>dev, base, 

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

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/powercap/intel_rapl.c

between commit:

  17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")

from the pm tree and commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip 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 drivers/powercap/intel_rapl.c
index bb92874b1175,8cbfcce57a06..
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
.compute_time_window = rapl_compute_time_window_atom,
  };
  
 -#define RAPL_CPU(_model, _ops) {  \
 -  .vendor = X86_VENDOR_INTEL, \
 -  .family = 6,\
 -  .model = _model,\
 -  .driver_data = (kernel_ulong_t)&_ops,   \
 -  }
 -
  static const struct x86_cpu_id rapl_ids[] __initconst = {
 -  RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,  rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_IVYBRIDGE,  rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_HASWELL_CORE,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_HASWELL_ULT,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_HASWELL_X,  rapl_defaults_hsw_server),
 -
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_CORE, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_BROADWELL_X,rapl_defaults_hsw_server),
 -
 -  RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_SKYLAKE_X,  rapl_defaults_hsw_server),
 -  RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,   rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE,  rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,rapl_defaults_byt),
 -  RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,   rapl_defaults_cht),
 -  RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,rapl_defaults_tng),
 -  RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID,   rapl_defaults_ann),
 -  RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,  rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core),
 -  RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,rapl_defaults_core),
 -
 -  RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,   rapl_defaults_hsw_server),
 -  RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM,   rapl_defaults_hsw_server),
 +  INTEL_CPU_FAM6(SANDYBRIDGE, rapl_defaults_core),
 +  INTEL_CPU_FAM6(SANDYBRIDGE_X,   rapl_defaults_core),
 +
 +  INTEL_CPU_FAM6(IVYBRIDGE,   rapl_defaults_core),
 +  INTEL_CPU_FAM6(IVYBRIDGE_X, rapl_defaults_core),
 +
 +  INTEL_CPU_FAM6(HASWELL_CORE,rapl_defaults_core),
 +  INTEL_CPU_FAM6(HASWELL_ULT, rapl_defaults_core),
 +  INTEL_CPU_FAM6(HASWELL_GT3E,rapl_defaults_core),
 +  INTEL_CPU_FAM6(HASWELL_X,   rapl_defaults_hsw_server),
 +
 +  INTEL_CPU_FAM6(BROADWELL_CORE,  rapl_defaults_core),
 +  INTEL_CPU_FAM6(BROADWELL_GT3E,  rapl_defaults_core),
 +  INTEL_CPU_FAM6(BROADWELL_XEON_D,rapl_defaults_core),
 +  INTEL_CPU_FAM6(BROADWELL_X, rapl_defaults_hsw_server),
 +
 +  INTEL_CPU_FAM6(SKYLAKE_DESKTOP, rapl_defaults_core),
 +  INTEL_CPU_FAM6(SKYLAKE_MOBILE,  rapl_defaults_core),
 +  INTEL_CPU_FAM6(SKYLAKE_X,   rapl_defaults_hsw_server),
 +  INTEL_CPU_FAM6(KABYLAKE_MOBILE, rapl_defaults_core),
 +  INTEL_CPU_FAM6(KABYLAKE_DESKTOP,rapl_defaults_core),
 +  INTEL_CPU_FAM6(CANNONLAKE_MOBILE,   rapl_defaults_core),
 +
-   INTEL_CPU_FAM6(ATOM_SILVERMONT1,rapl_defaults_byt),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT, rapl_defaults_byt),
 +  INTEL_CPU_FAM6(ATOM_AIRMONT,rapl_defaults_cht),
-   INTEL_CPU_FAM6(ATOM_MERRIFIELD, rapl_defaults_tng),
-   INTEL_CPU_FAM6(ATOM_MOOREFIELD, rapl_defaults_ann),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, rapl_defaults_tng),
++  

Re: [PATCH v6] clk: qcom: Add lpass clock controller driver for SDM845

2018-10-07 Thread Stephen Boyd
Quoting Taniya Das (2018-10-04 05:02:26)
> Add support for the lpass clock controller found on SDM845 based devices.
> This would allow lpass peripheral loader drivers to control the clocks to
> bring the subsystem out of reset.
> LPASS clocks present on the global clock controller would be registered
> with the clock framework based on the device tree flag. Also do not gate
> these clocks if they are left unused.

Why not gate them? This statement states what the code is doing, not why
it's doing it which is the more crucial information that should be
described in the commit text. Also, please add a comment about it to the
code next to the flag.

I am concerned that it doesn't make any sense though, so probably it
shouldn't be marked as CLK_IGNORE_UNUSED and it's papering over some
other larger bug that needs to be fixed.

> 
> Signed-off-by: Taniya Das 
> ---
> diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
> index 08d593e..6379b8b 100644
> --- a/drivers/clk/qcom/gcc-sdm845.c
> +++ b/drivers/clk/qcom/gcc-sdm845.c
> @@ -3169,6 +3169,32 @@ enum {
> },
>  };
> 
> +static struct clk_branch gcc_lpass_q6_axi_clk = {
> +   .halt_reg = 0x47000,
> +   .halt_check = BRANCH_HALT,
> +   .clkr = {
> +   .enable_reg = 0x47000,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "gcc_lpass_q6_axi_clk",
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
> +static struct clk_branch gcc_lpass_sway_clk = {
> +   .halt_reg = 0x47008,
> +   .halt_check = BRANCH_HALT,
> +   .clkr = {
> +   .enable_reg = 0x47008,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "gcc_lpass_sway_clk",
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
>  static struct gdsc pcie_0_gdsc = {
> .gdscr = 0x6b004,
> .pd = {
> @@ -3469,6 +3495,8 @@ enum {
> [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
> [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
> [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
> +   [GCC_LPASS_Q6_AXI_CLK] = NULL,
> +   [GCC_LPASS_SWAY_CLK] = NULL,
>  };
> 
>  static const struct qcom_reset_map gcc_sdm845_resets[] = {
> @@ -3583,6 +3611,13 @@ static int gcc_sdm845_probe(struct platform_device 
> *pdev)
> if (ret)
> return ret;
> 
> +   if (!of_property_read_bool(pdev->dev.of_node, 
> "qcom,lpass-protected")) {
> +   gcc_sdm845_clocks[GCC_LPASS_Q6_AXI_CLK] =
> +   _lpass_q6_axi_clk.clkr;
> +   gcc_sdm845_clocks[GCC_LPASS_SWAY_CLK] =
> +   _lpass_sway_clk.clkr;
> +   }
> +
> return qcom_cc_really_probe(pdev, _sdm845_desc, regmap);
>  }
> 
> diff --git a/drivers/clk/qcom/lpasscc-sdm845.c 
> b/drivers/clk/qcom/lpasscc-sdm845.c
> new file mode 100644
> index 000..f7b9b0f
> --- /dev/null
> +++ b/drivers/clk/qcom/lpasscc-sdm845.c
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 

Is this needed?

> +/* CLK_OFF would not toggle until LPASS is not out of reset */
> +static struct clk_branch lpass_qdsp6ss_xo_clk = {
> +   .halt_reg = 0x38,
> +   .halt_check = BRANCH_HALT_SKIP,
> +   .clkr = {
> +   .enable_reg = 0x38,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "lpass_qdsp6ss_xo_clk",
> +   .flags = CLK_IGNORE_UNUSED,
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
> +/* CLK_OFF would not toggle until LPASS is not out of reset */

Move this comment next to BRANCH_HALT_SKIP please so we know what it
relates to.

> +static struct clk_branch lpass_qdsp6ss_sleep_clk = {
> +   .halt_reg = 0x3c,
> +   .halt_check = BRANCH_HALT_SKIP,
> +   .clkr = {
> +   .enable_reg = 0x3c,
> +   .enable_mask = BIT(0),
> +   .hw.init = &(struct clk_init_data){
> +   .name = "lpass_qdsp6ss_sleep_clk",
> +   .flags = CLK_IGNORE_UNUSED,
> +   .ops = _branch2_ops,
> +   },
> +   },
> +};
> +
> +static int lpass_clocks_sdm845_probe(struct platform_device *pdev, int index,
> +const struct qcom_cc_desc *desc)
> +{
> +   struct regmap *regmap;
> +   struct resource *res;
> +   void __iomem *base;
> +
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, index);
> +   base = devm_ioremap_resource(>dev, res);
> +   if (IS_ERR(base))
> +   return PTR_ERR(base);
> +
> +   regmap = devm_regmap_init_mmio(>dev, base, 

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

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/idle/intel_idle.c

between commit:

  a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")

from the pm tree and commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip 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 drivers/idle/intel_idle.c
index 791b8a366e6e,c4bb67ed8da3..
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
.disable_promotion_to_c1e = true,
  };
  
 -#define ICPU(model, cpu) \
 -  { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) }
 -
  static const struct x86_cpu_id intel_idle_ids[] __initconst = {
 -  ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_NEHALEM_G,  idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_WESTMERE,   idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_ATOM_BONNELL,   idle_cpu_atom),
 -  ICPU(INTEL_FAM6_ATOM_BONNELL_MID,   idle_cpu_lincroft),
 -  ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb),
 -  ICPU(INTEL_FAM6_SANDYBRIDGE_X,  idle_cpu_snb),
 -  ICPU(INTEL_FAM6_ATOM_SALTWELL,  idle_cpu_atom),
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt),
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier),
 -  ICPU(INTEL_FAM6_ATOM_AIRMONT,   idle_cpu_cht),
 -  ICPU(INTEL_FAM6_IVYBRIDGE,  idle_cpu_ivb),
 -  ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt),
 -  ICPU(INTEL_FAM6_HASWELL_CORE,   idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_HASWELL_X,  idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_HASWELL_GT3E,   idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT_X,  idle_cpu_avn),
 -  ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_BROADWELL_XEON_D,   idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl),
 -  ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl),
 -  ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl),
 -  ICPU(INTEL_FAM6_KABYLAKE_DESKTOP,   idle_cpu_skl),
 -  ICPU(INTEL_FAM6_SKYLAKE_X,  idle_cpu_skx),
 -  ICPU(INTEL_FAM6_XEON_PHI_KNL,   idle_cpu_knl),
 -  ICPU(INTEL_FAM6_XEON_PHI_KNM,   idle_cpu_knl),
 -  ICPU(INTEL_FAM6_ATOM_GOLDMONT,  idle_cpu_bxt),
 -  ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
 -  ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv),
 +  INTEL_CPU_FAM6(NEHALEM_EP,  idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(NEHALEM_G,   idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(NEHALEM_EX,  idle_cpu_nehalem),
-   INTEL_CPU_FAM6(ATOM_PINEVIEW,   idle_cpu_atom),
-   INTEL_CPU_FAM6(ATOM_LINCROFT,   idle_cpu_lincroft),
++  INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom),
++  INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft),
 +  INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb),
 +  INTEL_CPU_FAM6(SANDYBRIDGE_X,   idle_cpu_snb),
-   INTEL_CPU_FAM6(ATOM_CEDARVIEW,  idle_cpu_atom),
-   INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt),
-   INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier),
++  INTEL_CPU_FAM6(ATOM_SALTWELL,   idle_cpu_atom),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier),
 +  INTEL_CPU_FAM6(ATOM_AIRMONT,idle_cpu_cht),
 +  INTEL_CPU_FAM6(IVYBRIDGE,   idle_cpu_ivb),
 +  INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt),
 +  INTEL_CPU_FAM6(HASWELL_CORE,idle_cpu_hsw),
 +  INTEL_CPU_FAM6(HASWELL_X,   

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

2018-10-07 Thread Stephen Rothwell
Hi all,

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

  drivers/idle/intel_idle.c

between commit:

  a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")

from the pm tree and commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip 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 drivers/idle/intel_idle.c
index 791b8a366e6e,c4bb67ed8da3..
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
.disable_promotion_to_c1e = true,
  };
  
 -#define ICPU(model, cpu) \
 -  { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long) }
 -
  static const struct x86_cpu_id intel_idle_ids[] __initconst = {
 -  ICPU(INTEL_FAM6_NEHALEM_EP, idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_NEHALEM,idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_NEHALEM_G,  idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_WESTMERE,   idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_WESTMERE_EP,idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_NEHALEM_EX, idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_ATOM_BONNELL,   idle_cpu_atom),
 -  ICPU(INTEL_FAM6_ATOM_BONNELL_MID,   idle_cpu_lincroft),
 -  ICPU(INTEL_FAM6_WESTMERE_EX,idle_cpu_nehalem),
 -  ICPU(INTEL_FAM6_SANDYBRIDGE,idle_cpu_snb),
 -  ICPU(INTEL_FAM6_SANDYBRIDGE_X,  idle_cpu_snb),
 -  ICPU(INTEL_FAM6_ATOM_SALTWELL,  idle_cpu_atom),
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT,idle_cpu_byt),
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,idle_cpu_tangier),
 -  ICPU(INTEL_FAM6_ATOM_AIRMONT,   idle_cpu_cht),
 -  ICPU(INTEL_FAM6_IVYBRIDGE,  idle_cpu_ivb),
 -  ICPU(INTEL_FAM6_IVYBRIDGE_X,idle_cpu_ivt),
 -  ICPU(INTEL_FAM6_HASWELL_CORE,   idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_HASWELL_X,  idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_HASWELL_ULT,idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_HASWELL_GT3E,   idle_cpu_hsw),
 -  ICPU(INTEL_FAM6_ATOM_SILVERMONT_X,  idle_cpu_avn),
 -  ICPU(INTEL_FAM6_BROADWELL_CORE, idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_BROADWELL_GT3E, idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_BROADWELL_X,idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_BROADWELL_XEON_D,   idle_cpu_bdw),
 -  ICPU(INTEL_FAM6_SKYLAKE_MOBILE, idle_cpu_skl),
 -  ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,idle_cpu_skl),
 -  ICPU(INTEL_FAM6_KABYLAKE_MOBILE,idle_cpu_skl),
 -  ICPU(INTEL_FAM6_KABYLAKE_DESKTOP,   idle_cpu_skl),
 -  ICPU(INTEL_FAM6_SKYLAKE_X,  idle_cpu_skx),
 -  ICPU(INTEL_FAM6_XEON_PHI_KNL,   idle_cpu_knl),
 -  ICPU(INTEL_FAM6_XEON_PHI_KNM,   idle_cpu_knl),
 -  ICPU(INTEL_FAM6_ATOM_GOLDMONT,  idle_cpu_bxt),
 -  ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
 -  ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,idle_cpu_dnv),
 +  INTEL_CPU_FAM6(NEHALEM_EP,  idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(NEHALEM_G,   idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(WESTMERE,idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(WESTMERE_EP, idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(NEHALEM_EX,  idle_cpu_nehalem),
-   INTEL_CPU_FAM6(ATOM_PINEVIEW,   idle_cpu_atom),
-   INTEL_CPU_FAM6(ATOM_LINCROFT,   idle_cpu_lincroft),
++  INTEL_CPU_FAM6(ATOM_BONNELL,idle_cpu_atom),
++  INTEL_CPU_FAM6(ATOM_BONNELL_MID,idle_cpu_lincroft),
 +  INTEL_CPU_FAM6(WESTMERE_EX, idle_cpu_nehalem),
 +  INTEL_CPU_FAM6(SANDYBRIDGE, idle_cpu_snb),
 +  INTEL_CPU_FAM6(SANDYBRIDGE_X,   idle_cpu_snb),
-   INTEL_CPU_FAM6(ATOM_CEDARVIEW,  idle_cpu_atom),
-   INTEL_CPU_FAM6(ATOM_SILVERMONT1,idle_cpu_byt),
-   INTEL_CPU_FAM6(ATOM_MERRIFIELD, idle_cpu_tangier),
++  INTEL_CPU_FAM6(ATOM_SALTWELL,   idle_cpu_atom),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT, idle_cpu_byt),
++  INTEL_CPU_FAM6(ATOM_SILVERMONT_MID, idle_cpu_tangier),
 +  INTEL_CPU_FAM6(ATOM_AIRMONT,idle_cpu_cht),
 +  INTEL_CPU_FAM6(IVYBRIDGE,   idle_cpu_ivb),
 +  INTEL_CPU_FAM6(IVYBRIDGE_X, idle_cpu_ivt),
 +  INTEL_CPU_FAM6(HASWELL_CORE,idle_cpu_hsw),
 +  INTEL_CPU_FAM6(HASWELL_X,   

[PATCH] tty: check name length in tty_find_polling_driver()

2018-10-07 Thread miles.chen
From: Miles Chen 

The issue is found by a fuzzing test.
If tty_find_polling_driver() recevies an incorrect input such as
',,' or '0b', the len becomes 0 and strncmp() always return 0.
In this case, a null p->ops->poll_init() is called and it causes a kernel
panic.

Fix this by checking name length against zero in tty_find_polling_driver().

$echo ,, > /sys/module/kgdboc/parameters/kgdboc
[   20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
uart_get_baud_rate+0xe8/0x190
[   20.804917] Modules linked in:
[   20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
[   20.805469] Hardware name: linux,dummy-virt (DT)
[   20.805732] pstate: 2005 (nzCv daif -PAN -UAO)
[   20.805895] pc : uart_get_baud_rate+0xe8/0x190
[   20.806042] lr : uart_get_baud_rate+0xc0/0x190
[   20.806476] sp : ffc06acff940
[   20.806676] x29: ffc06acff940 x28: 2580
[   20.806977] x27: 9600 x26: 9600
[   20.807231] x25: ffc06acffad0 x24: eff0
[   20.807576] x23: 0001 x22: 
[   20.807807] x21: 0001 x20: 
[   20.808049] x19: ffc06acffac8 x18: 
[   20.808277] x17:  x16: 
[   20.808520] x15:  x14: 
[   20.808757] x13:  x12: 0001
[   20.809011] x11: 0101010101010101 x10: ff880d59ff5f
[   20.809292] x9 : ff880d59ff5e x8 : ffc06acffaf3
[   20.809549] x7 :  x6 : ff880d59ff5f
[   20.809803] x5 : 80008001 x4 : 0003
[   20.810056] x3 : ff900853e6b4 x2 : df90
[   20.810693] x1 : ffc06acffad0 x0 : 0cb0
[   20.811005] Call trace:
[   20.811214]  uart_get_baud_rate+0xe8/0x190
[   20.811479]  serial8250_do_set_termios+0xe0/0x6f4
[   20.811719]  serial8250_set_termios+0x48/0x54
[   20.811928]  uart_set_options+0x138/0x1bc
[   20.812129]  uart_poll_init+0x114/0x16c
[   20.812330]  tty_find_polling_driver+0x158/0x200
[   20.812545]  configure_kgdboc+0xbc/0x1bc
[   20.812745]  param_set_kgdboc_var+0xb8/0x150
[   20.812960]  param_attr_store+0xbc/0x150
[   20.813160]  module_attr_store+0x40/0x58
[   20.813364]  sysfs_kf_write+0x8c/0xa8
[   20.813563]  kernfs_fop_write+0x154/0x290
[   20.813764]  vfs_write+0xf0/0x278
[   20.813951]  __arm64_sys_write+0x84/0xf4
[   20.814400]  el0_svc_common+0xf4/0x1dc
[   20.814616]  el0_svc_handler+0x98/0xbc
[   20.814804]  el0_svc+0x8/0xc
[   20.822005] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   20.826913] Mem abort info:
[   20.827103]   ESR = 0x8406
[   20.827352]   Exception class = IABT (current EL), IL = 16 bits
[   20.827655]   SET = 0, FnV = 0
[   20.827855]   EA = 0, S1PTW = 0
[   20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[   20.828484] [] pgd=aadee003, pud=aadee003, 
pmd=
[   20.829195] Internal error: Oops: 8406 [#1] SMP
[   20.829564] Modules linked in:
[   20.829890] CPU: 1 PID: 104 Comm: sh Tainted: GW 
4.19.0-rc7ajb #8
[   20.830545] Hardware name: linux,dummy-virt (DT)
[   20.830829] pstate: 6085 (nZCv daIf -PAN -UAO)
[   20.831174] pc :   (null)
[   20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
[   20.831727] sp : ffc06acff9b0
[   20.831936] x29: ffc06acff9b0 x28: ff9008d7c000
[   20.832267] x27: ff900969e16f x26: 
[   20.832589] x25: ff900969dfb0 x24: 
[   20.832906] x23: ffc06acffad0 x22: ff900969e160
[   20.833232] x21:  x20: ffc06acffac8
[   20.833559] x19: ff900969df90 x18: 
[   20.833878] x17:  x16: 
[   20.834491] x15:  x14: 
[   20.834821] x13:  x12: 0001
[   20.835143] x11: 0101010101010101 x10: ff880d59ff5f
[   20.835467] x9 : ff880d59ff5e x8 : ffc06acffaf3
[   20.835790] x7 :  x6 : ff880d59ff5f
[   20.836111] x5 : c06419717c314100 x4 : 0007
[   20.836419] x3 :  x2 : 
[   20.836732] x1 : 0001 x0 : ff900969df90
[   20.837100] Process sh (pid: 104, stack limit = 0x(ptrval))
[   20.837396] Call trace:
[   20.837566](null)
[   20.837816]  serial8250_set_termios+0x48/0x54
[   20.838089]  uart_set_options+0x138/0x1bc
[   20.838570]  uart_poll_init+0x114/0x16c
[   20.838834]  tty_find_polling_driver+0x158/0x200
[   20.839119]  configure_kgdboc+0xbc/0x1bc
[   20.839380]  param_set_kgdboc_var+0xb8/0x150
[   20.839658]  param_attr_store+0xbc/0x150
[   20.839920]  module_attr_store+0x40/0x58
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840440]  kernfs_fop_write+0x154/0x290
[   20.840702]  vfs_write+0xf0/0x278
[   20.840942]  __arm64_sys_write+0x84/0xf4
[   

[PATCH] tty: check name length in tty_find_polling_driver()

2018-10-07 Thread miles.chen
From: Miles Chen 

The issue is found by a fuzzing test.
If tty_find_polling_driver() recevies an incorrect input such as
',,' or '0b', the len becomes 0 and strncmp() always return 0.
In this case, a null p->ops->poll_init() is called and it causes a kernel
panic.

Fix this by checking name length against zero in tty_find_polling_driver().

$echo ,, > /sys/module/kgdboc/parameters/kgdboc
[   20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
uart_get_baud_rate+0xe8/0x190
[   20.804917] Modules linked in:
[   20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
[   20.805469] Hardware name: linux,dummy-virt (DT)
[   20.805732] pstate: 2005 (nzCv daif -PAN -UAO)
[   20.805895] pc : uart_get_baud_rate+0xe8/0x190
[   20.806042] lr : uart_get_baud_rate+0xc0/0x190
[   20.806476] sp : ffc06acff940
[   20.806676] x29: ffc06acff940 x28: 2580
[   20.806977] x27: 9600 x26: 9600
[   20.807231] x25: ffc06acffad0 x24: eff0
[   20.807576] x23: 0001 x22: 
[   20.807807] x21: 0001 x20: 
[   20.808049] x19: ffc06acffac8 x18: 
[   20.808277] x17:  x16: 
[   20.808520] x15:  x14: 
[   20.808757] x13:  x12: 0001
[   20.809011] x11: 0101010101010101 x10: ff880d59ff5f
[   20.809292] x9 : ff880d59ff5e x8 : ffc06acffaf3
[   20.809549] x7 :  x6 : ff880d59ff5f
[   20.809803] x5 : 80008001 x4 : 0003
[   20.810056] x3 : ff900853e6b4 x2 : df90
[   20.810693] x1 : ffc06acffad0 x0 : 0cb0
[   20.811005] Call trace:
[   20.811214]  uart_get_baud_rate+0xe8/0x190
[   20.811479]  serial8250_do_set_termios+0xe0/0x6f4
[   20.811719]  serial8250_set_termios+0x48/0x54
[   20.811928]  uart_set_options+0x138/0x1bc
[   20.812129]  uart_poll_init+0x114/0x16c
[   20.812330]  tty_find_polling_driver+0x158/0x200
[   20.812545]  configure_kgdboc+0xbc/0x1bc
[   20.812745]  param_set_kgdboc_var+0xb8/0x150
[   20.812960]  param_attr_store+0xbc/0x150
[   20.813160]  module_attr_store+0x40/0x58
[   20.813364]  sysfs_kf_write+0x8c/0xa8
[   20.813563]  kernfs_fop_write+0x154/0x290
[   20.813764]  vfs_write+0xf0/0x278
[   20.813951]  __arm64_sys_write+0x84/0xf4
[   20.814400]  el0_svc_common+0xf4/0x1dc
[   20.814616]  el0_svc_handler+0x98/0xbc
[   20.814804]  el0_svc+0x8/0xc
[   20.822005] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   20.826913] Mem abort info:
[   20.827103]   ESR = 0x8406
[   20.827352]   Exception class = IABT (current EL), IL = 16 bits
[   20.827655]   SET = 0, FnV = 0
[   20.827855]   EA = 0, S1PTW = 0
[   20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[   20.828484] [] pgd=aadee003, pud=aadee003, 
pmd=
[   20.829195] Internal error: Oops: 8406 [#1] SMP
[   20.829564] Modules linked in:
[   20.829890] CPU: 1 PID: 104 Comm: sh Tainted: GW 
4.19.0-rc7ajb #8
[   20.830545] Hardware name: linux,dummy-virt (DT)
[   20.830829] pstate: 6085 (nZCv daIf -PAN -UAO)
[   20.831174] pc :   (null)
[   20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
[   20.831727] sp : ffc06acff9b0
[   20.831936] x29: ffc06acff9b0 x28: ff9008d7c000
[   20.832267] x27: ff900969e16f x26: 
[   20.832589] x25: ff900969dfb0 x24: 
[   20.832906] x23: ffc06acffad0 x22: ff900969e160
[   20.833232] x21:  x20: ffc06acffac8
[   20.833559] x19: ff900969df90 x18: 
[   20.833878] x17:  x16: 
[   20.834491] x15:  x14: 
[   20.834821] x13:  x12: 0001
[   20.835143] x11: 0101010101010101 x10: ff880d59ff5f
[   20.835467] x9 : ff880d59ff5e x8 : ffc06acffaf3
[   20.835790] x7 :  x6 : ff880d59ff5f
[   20.836111] x5 : c06419717c314100 x4 : 0007
[   20.836419] x3 :  x2 : 
[   20.836732] x1 : 0001 x0 : ff900969df90
[   20.837100] Process sh (pid: 104, stack limit = 0x(ptrval))
[   20.837396] Call trace:
[   20.837566](null)
[   20.837816]  serial8250_set_termios+0x48/0x54
[   20.838089]  uart_set_options+0x138/0x1bc
[   20.838570]  uart_poll_init+0x114/0x16c
[   20.838834]  tty_find_polling_driver+0x158/0x200
[   20.839119]  configure_kgdboc+0xbc/0x1bc
[   20.839380]  param_set_kgdboc_var+0xb8/0x150
[   20.839658]  param_attr_store+0xbc/0x150
[   20.839920]  module_attr_store+0x40/0x58
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840183]  sysfs_kf_write+0x8c/0xa8
[   20.840440]  kernfs_fop_write+0x154/0x290
[   20.840702]  vfs_write+0xf0/0x278
[   20.840942]  __arm64_sys_write+0x84/0xf4
[   

  1   2   3   4   5   >