[RFC PATCH 0/9] soc: samsung: Add support of suspend-to-RAM on Exynos5433

[Chanwoo Choi]

In the mainline, there is no case to support the suspend-to-RAM for Samsung
Exynos SoC. This patchset support the suspend-to-RAM for 64bit Exynos SoC.

For 32bit, arch/arm/mach-exynos/* directoy contains the suspend-related
codes such as suspend.c/exynos.c. But, 64bit Exynos should contain
the suspend-related codes in the drivers/soc/samsung/*. So, this patchset
develop the patch4/5 for drivers/soc/samsung/exynos-pm.c. to support suspend
64bit Exynos SoC.

But, I'm not sure what is proper approach for both 32/64bit Exynos.
- Approach1 : Split out the supend-related codes between 32/64bit.
  : arch/arm/mach-exynos/* contains the suspend-related codes for 32bit.
  : drivers/soc/samsung/* contains the suspend-related codes for 64bit.
- Approach2 : Consolidate the all suspend-related codes to drivers/soc/samsung/.

Please let us know your opinion.

The patch1/2/3 and 6/7/8/9 is just general patch. So, I add 'RFC' prefix to
only cover-letter, patch4/5. If you want to add the 'RFC' prefix to all
patches, I'll add 'RFC' prefix on v2.

Based on:
- git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git (branch: 
for-next)

Need to discuss patch4/5:
- patch4: soc: samsung: Add generic power-management driver for Exynos
- patch5: soc: samsung: pm: Add support for suspend-to-ram of Exynos5433

[Remaining Issues]
- The hang-out happen when disabling the MMC clocks on dw_mmc.c.
  I reported to Jaehoon Chung. He is checking this issue. To test the
  suspend-to-ram temporarily, you need to add CLK_IS_CRITICAL flag to
  'aclk_mmc2/aclk_mmc0/sclk_mmc2/sclk_mmc0'.
- I enabled the at least kernel configuration in order to test
  the suspend-to-RAM. So, I need to test it more time with DRM/Multimedia
  and other. But, the suspend-to-RAM of cpu is successful.
- Exynos5433 SoC has two EXYNOS5433_EINT_WAKEUP_MASKx registers. The
  pinctr-exynos.c need to handle the extra EINT_WAKEUP_MASKx for Exynos5433.
  The suspend-to-ram test is failed on first time and then next tryout is ok.
  I'm developing it.

Chanwoo Choi (9):
  clk: samsung: exynos5433: Add clock flag to support suspend-to-ram
  soc: samsung: pmu: Add powerup_conf callback
  soc: samsung: pmu: Add the PMU data of exynos5433 to support low-power state
  soc: samsung: Add generic power-management driver for Exynos
  soc: samsung: pm: Add support for suspend-to-ram of Exynos5433
  arm64: dts: exynos: Add iRAM device-tree node for Exynos5433
  arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board
  arm64: dts: exynos: Add cpu_suspend property of PSCI for exynos5433
  arm64: dts: exynos: Add cpu topology information for Exynos5433 SoC

 arch/arm/mach-exynos/common.h  |   3 -
 arch/arm/mach-exynos/exynos.c  |  23 +-
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi |   1 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  47 
 drivers/clk/samsung/clk-exynos5433.c   |  22 +-
 drivers/soc/samsung/Makefile   |   5 +-
 drivers/soc/samsung/exynos-pm.c| 214 +++
 drivers/soc/samsung/exynos-pmu.c   |   9 +
 drivers/soc/samsung/exynos-pmu.h   |   3 +
 drivers/soc/samsung/exynos5433-pmu.c   | 286 +
 include/linux/soc/samsung/exynos-pm.h  |  21 ++
 include/linux/soc/samsung/exynos-pmu.h |   1 +
 include/linux/soc/samsung/exynos-regs-pmu.h| 148 +++
 13 files changed, 745 insertions(+), 38 deletions(-)
 create mode 100644 drivers/soc/samsung/exynos-pm.c
 create mode 100644 drivers/soc/samsung/exynos5433-pmu.c
 create mode 100644 include/linux/soc/samsung/exynos-pm.h

--
1.9.1

[RFC PATCH 0/9] soc: samsung: Add support of suspend-to-RAM on Exynos5433

[Chanwoo Choi]

In the mainline, there is no case to support the suspend-to-RAM for Samsung
Exynos SoC. This patchset support the suspend-to-RAM for 64bit Exynos SoC.

For 32bit, arch/arm/mach-exynos/* directoy contains the suspend-related
codes such as suspend.c/exynos.c. But, 64bit Exynos should contain
the suspend-related codes in the drivers/soc/samsung/*. So, this patchset
develop the patch4/5 for drivers/soc/samsung/exynos-pm.c. to support suspend
64bit Exynos SoC.

But, I'm not sure what is proper approach for both 32/64bit Exynos.
- Approach1 : Split out the supend-related codes between 32/64bit.
  : arch/arm/mach-exynos/* contains the suspend-related codes for 32bit.
  : drivers/soc/samsung/* contains the suspend-related codes for 64bit.
- Approach2 : Consolidate the all suspend-related codes to drivers/soc/samsung/.

Please let us know your opinion.

The patch1/2/3 and 6/7/8/9 is just general patch. So, I add 'RFC' prefix to
only cover-letter, patch4/5. If you want to add the 'RFC' prefix to all
patches, I'll add 'RFC' prefix on v2.

Based on:
- git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git (branch: 
for-next)

Need to discuss patch4/5:
- patch4: soc: samsung: Add generic power-management driver for Exynos
- patch5: soc: samsung: pm: Add support for suspend-to-ram of Exynos5433

[Remaining Issues]
- The hang-out happen when disabling the MMC clocks on dw_mmc.c.
  I reported to Jaehoon Chung. He is checking this issue. To test the
  suspend-to-ram temporarily, you need to add CLK_IS_CRITICAL flag to
  'aclk_mmc2/aclk_mmc0/sclk_mmc2/sclk_mmc0'.
- I enabled the at least kernel configuration in order to test
  the suspend-to-RAM. So, I need to test it more time with DRM/Multimedia
  and other. But, the suspend-to-RAM of cpu is successful.
- Exynos5433 SoC has two EXYNOS5433_EINT_WAKEUP_MASKx registers. The
  pinctr-exynos.c need to handle the extra EINT_WAKEUP_MASKx for Exynos5433.
  The suspend-to-ram test is failed on first time and then next tryout is ok.
  I'm developing it.

Chanwoo Choi (9):
  clk: samsung: exynos5433: Add clock flag to support suspend-to-ram
  soc: samsung: pmu: Add powerup_conf callback
  soc: samsung: pmu: Add the PMU data of exynos5433 to support low-power state
  soc: samsung: Add generic power-management driver for Exynos
  soc: samsung: pm: Add support for suspend-to-ram of Exynos5433
  arm64: dts: exynos: Add iRAM device-tree node for Exynos5433
  arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board
  arm64: dts: exynos: Add cpu_suspend property of PSCI for exynos5433
  arm64: dts: exynos: Add cpu topology information for Exynos5433 SoC

 arch/arm/mach-exynos/common.h  |   3 -
 arch/arm/mach-exynos/exynos.c  |  23 +-
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi |   1 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi |  47 
 drivers/clk/samsung/clk-exynos5433.c   |  22 +-
 drivers/soc/samsung/Makefile   |   5 +-
 drivers/soc/samsung/exynos-pm.c| 214 +++
 drivers/soc/samsung/exynos-pmu.c   |   9 +
 drivers/soc/samsung/exynos-pmu.h   |   3 +
 drivers/soc/samsung/exynos5433-pmu.c   | 286 +
 include/linux/soc/samsung/exynos-pm.h  |  21 ++
 include/linux/soc/samsung/exynos-pmu.h |   1 +
 include/linux/soc/samsung/exynos-regs-pmu.h| 148 +++
 13 files changed, 745 insertions(+), 38 deletions(-)
 create mode 100644 drivers/soc/samsung/exynos-pm.c
 create mode 100644 drivers/soc/samsung/exynos5433-pmu.c
 create mode 100644 include/linux/soc/samsung/exynos-pm.h

--
1.9.1

[PATCH 7/9] arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board

[Chanwoo Choi]

This patch uses the power-key as a wakeup source from suspend/freeze state.

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a77462da4a36..26de0add1254 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -60,6 +60,7 @@
linux,code = ;
label = "power key";
debounce-interval = <10>;
+   wakeup-source;
};
 
volume-up-key {
-- 
1.9.1

[PATCH 7/9] arm64: dts: exynos: Use power key as a wakeup source on TM2/TM2E board

[Chanwoo Choi]

This patch uses the power-key as a wakeup source from suspend/freeze state.

Signed-off-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a77462da4a36..26de0add1254 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -60,6 +60,7 @@
linux,code = ;
label = "power key";
debounce-interval = <10>;
+   wakeup-source;
};
 
volume-up-key {
-- 
1.9.1

Re: [lkp-robot] [sched/fair] a4c3c04974: unixbench.score -4.3% regression

[Vincent Guittot]

Hi,

On 8 January 2018 at 10:34, Vincent Guittot  wrote:
> Hi Xiaolong,
>
> On 25 December 2017 at 07:07, kernel test robot  wrote:
>>
>> Greeting,
>>
>> FYI, we noticed a -4.3% regression of unixbench.score due to commit:
>>
>>
>> commit: a4c3c04974d648ee6e1a09ef4131eb32a02ab494 ("sched/fair: Update and 
>> fix the runnable propagation rule")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>
>> in testcase: unixbench
>> on test machine: 8 threads Ivy Bridge with 16G memory
>> with following parameters:
>>
>> runtime: 300s
>> nr_task: 100%
>> test: shell1
>> cpufreq_governor: performance
>>
>> test-description: UnixBench is the original BYTE UNIX benchmark suite aims 
>> to test performance of Unix-like system.
>> test-url: https://github.com/kdlucas/byte-unixbench
>>
>
> I don't have the machine described above so i have tried to reproduce
> the problem on my 8 cores cortex A53 platform but I don't have
> performance regression.
> I have also tried with a VM on a Intel(R) Core(TM) i7-4810MQ and
> haven't seen regression too.
>
> Have you seen the regression on other platform ?

I have been able to run the test on a 12 cores Intel(R) Xeon(R) CPU
E5-2630 and haven't seen any regression as well
I have changed the command to ./Run Shell1 -c 12 -i 30 instead of
./Run Shell1 -c 8 -i 30 as there were more cores

Regards,
Vincent

>
> Regards,
> Vincent
>
>>
>> Details are as below:
>> -->
>>
>>
>> To reproduce:
>>
>> git clone https://github.com/intel/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml  # job file is attached in this email
>> bin/lkp run job.yaml
>>
>> =
>> compiler/cpufreq_governor/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>>   
>> gcc-7/performance/x86_64-rhel-7.2/100%/debian-x86_64-2016-08-31.cgz/300s/lkp-ivb-d01/shell1/unixbench
>>
>> commit:
>>   c6b9d9a330 ("sched/wait: Fix add_wait_queue() behavioral change")
>>   a4c3c04974 ("sched/fair: Update and fix the runnable propagation rule")
>>
>> c6b9d9a330290144 a4c3c04974d648ee6e1a09ef41
>>  --
>>  %stddev %change %stddev
>>  \  |\
>>  13264-4.3%  12694unixbench.score
>>   10619292   -11.7%9374917
>> unixbench.time.involuntary_context_switches
>>  4.829e+08-4.3%   4.62e+08
>> unixbench.time.minor_page_faults
>>   1126-3.6%   1086unixbench.time.system_time
>>   2645-3.0%   2566unixbench.time.user_time
>>   15855720-6.2%   14878247
>> unixbench.time.voluntary_context_switches
>>   0.00 ą 56%  -0.00.00 ą 57%  mpstat.cpu.iowait%
>>  79517-5.7%  74990vmstat.system.cs
>>  16361-3.3%  15822vmstat.system.in
>>  1.814e+08   -24.0%  1.379e+08cpuidle.C1.time
>>3436399   -20.6%2728227cpuidle.C1.usage
>>7772815-9.9%7001076cpuidle.C1E.usage
>>  1.479e+08   +66.1%  2.456e+08cpuidle.C3.time
>>1437889   +38.7%1994073cpuidle.C3.usage
>>  18147   +13.9%  20676cpuidle.POLL.usage
>>3436173   -20.6%2727580turbostat.C1
>>   3.54-0.82.73turbostat.C1%
>>7772758-9.9%7001012turbostat.C1E
>>1437858   +38.7%1994034turbostat.C3
>>   2.88+2.04.86turbostat.C3%
>>  18.50   +10.8%  20.50turbostat.CPU%c1
>>   0.54 ą  2%+179.6%   1.51turbostat.CPU%c3
>>   2.32e+12-4.3%   2.22e+12perf-stat.branch-instructions
>>  6.126e+10-4.9%  5.823e+10perf-stat.branch-misses
>>   8.64 ą  4%  +0.69.25perf-stat.cache-miss-rate%
>>  1.662e+11-4.3%   1.59e+11perf-stat.cache-references
>>   51040611-7.0%   47473754perf-stat.context-switches
>>  1.416e+13-3.6%  1.365e+13perf-stat.cpu-cycles
>>8396968-3.9%8065835perf-stat.cpu-migrations
>>  2.919e+12-4.3%  2.793e+12perf-stat.dTLB-loads
>>   1.89e+12-4.3%  1.809e+12perf-stat.dTLB-stores
>>  67.97+1.1   69.03perf-stat.iTLB-load-miss-rate%
>>  4.767e+09-1.3%  4.704e+09perf-stat.iTLB-load-misses
>>  2.247e+09-6.0%  2.111e+09perf-stat.iTLB-loads
>>   1.14e+13-4.3%  1.091e+13perf-stat.instructions
>>   2391  

Re: [lkp-robot] [sched/fair] a4c3c04974: unixbench.score -4.3% regression

[Vincent Guittot]

Hi,

On 8 January 2018 at 10:34, Vincent Guittot  wrote:
> Hi Xiaolong,
>
> On 25 December 2017 at 07:07, kernel test robot  wrote:
>>
>> Greeting,
>>
>> FYI, we noticed a -4.3% regression of unixbench.score due to commit:
>>
>>
>> commit: a4c3c04974d648ee6e1a09ef4131eb32a02ab494 ("sched/fair: Update and 
>> fix the runnable propagation rule")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>
>> in testcase: unixbench
>> on test machine: 8 threads Ivy Bridge with 16G memory
>> with following parameters:
>>
>> runtime: 300s
>> nr_task: 100%
>> test: shell1
>> cpufreq_governor: performance
>>
>> test-description: UnixBench is the original BYTE UNIX benchmark suite aims 
>> to test performance of Unix-like system.
>> test-url: https://github.com/kdlucas/byte-unixbench
>>
>
> I don't have the machine described above so i have tried to reproduce
> the problem on my 8 cores cortex A53 platform but I don't have
> performance regression.
> I have also tried with a VM on a Intel(R) Core(TM) i7-4810MQ and
> haven't seen regression too.
>
> Have you seen the regression on other platform ?

I have been able to run the test on a 12 cores Intel(R) Xeon(R) CPU
E5-2630 and haven't seen any regression as well
I have changed the command to ./Run Shell1 -c 12 -i 30 instead of
./Run Shell1 -c 8 -i 30 as there were more cores

Regards,
Vincent

>
> Regards,
> Vincent
>
>>
>> Details are as below:
>> -->
>>
>>
>> To reproduce:
>>
>> git clone https://github.com/intel/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml  # job file is attached in this email
>> bin/lkp run job.yaml
>>
>> =
>> compiler/cpufreq_governor/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase:
>>   
>> gcc-7/performance/x86_64-rhel-7.2/100%/debian-x86_64-2016-08-31.cgz/300s/lkp-ivb-d01/shell1/unixbench
>>
>> commit:
>>   c6b9d9a330 ("sched/wait: Fix add_wait_queue() behavioral change")
>>   a4c3c04974 ("sched/fair: Update and fix the runnable propagation rule")
>>
>> c6b9d9a330290144 a4c3c04974d648ee6e1a09ef41
>>  --
>>  %stddev %change %stddev
>>  \  |\
>>  13264-4.3%  12694unixbench.score
>>   10619292   -11.7%9374917
>> unixbench.time.involuntary_context_switches
>>  4.829e+08-4.3%   4.62e+08
>> unixbench.time.minor_page_faults
>>   1126-3.6%   1086unixbench.time.system_time
>>   2645-3.0%   2566unixbench.time.user_time
>>   15855720-6.2%   14878247
>> unixbench.time.voluntary_context_switches
>>   0.00 ą 56%  -0.00.00 ą 57%  mpstat.cpu.iowait%
>>  79517-5.7%  74990vmstat.system.cs
>>  16361-3.3%  15822vmstat.system.in
>>  1.814e+08   -24.0%  1.379e+08cpuidle.C1.time
>>3436399   -20.6%2728227cpuidle.C1.usage
>>7772815-9.9%7001076cpuidle.C1E.usage
>>  1.479e+08   +66.1%  2.456e+08cpuidle.C3.time
>>1437889   +38.7%1994073cpuidle.C3.usage
>>  18147   +13.9%  20676cpuidle.POLL.usage
>>3436173   -20.6%2727580turbostat.C1
>>   3.54-0.82.73turbostat.C1%
>>7772758-9.9%7001012turbostat.C1E
>>1437858   +38.7%1994034turbostat.C3
>>   2.88+2.04.86turbostat.C3%
>>  18.50   +10.8%  20.50turbostat.CPU%c1
>>   0.54 ą  2%+179.6%   1.51turbostat.CPU%c3
>>   2.32e+12-4.3%   2.22e+12perf-stat.branch-instructions
>>  6.126e+10-4.9%  5.823e+10perf-stat.branch-misses
>>   8.64 ą  4%  +0.69.25perf-stat.cache-miss-rate%
>>  1.662e+11-4.3%   1.59e+11perf-stat.cache-references
>>   51040611-7.0%   47473754perf-stat.context-switches
>>  1.416e+13-3.6%  1.365e+13perf-stat.cpu-cycles
>>8396968-3.9%8065835perf-stat.cpu-migrations
>>  2.919e+12-4.3%  2.793e+12perf-stat.dTLB-loads
>>   1.89e+12-4.3%  1.809e+12perf-stat.dTLB-stores
>>  67.97+1.1   69.03perf-stat.iTLB-load-miss-rate%
>>  4.767e+09-1.3%  4.704e+09perf-stat.iTLB-load-misses
>>  2.247e+09-6.0%  2.111e+09perf-stat.iTLB-loads
>>   1.14e+13-4.3%  1.091e+13perf-stat.instructions
>>   2391-3.0%   2319
>> 

[mkp-scsi:for-next 237/263] drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol 'sas_destruct_ports' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
head:   f7c3d0667404295422c9a5d71fd87ca20c770f49
commit: 99cfdc04c12ea1bc5719bff15f24dae8b5b90da9 [237/263] scsi: libsas: direct 
call probe and destruct
reproduce:
# apt-get install sparse
git checkout 99cfdc04c12ea1bc5719bff15f24dae8b5b90da9
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol 
>> 'sas_destruct_ports' was not declared. Should it be

Please review and possibly fold the followup patch.

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

[mkp-scsi:for-next 237/263] drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol 'sas_destruct_ports' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
head:   f7c3d0667404295422c9a5d71fd87ca20c770f49
commit: 99cfdc04c12ea1bc5719bff15f24dae8b5b90da9 [237/263] scsi: libsas: direct 
call probe and destruct
reproduce:
# apt-get install sparse
git checkout 99cfdc04c12ea1bc5719bff15f24dae8b5b90da9
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol 
>> 'sas_destruct_ports' was not declared. Should it be

Please review and possibly fold the followup patch.

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

[RFC PATCH mkp-scsi] scsi: libsas: sas_destruct_ports() can be static

[kbuild test robot]

Fixes: 99cfdc04c12e ("scsi: libsas: direct call probe and destruct")
Signed-off-by: Fengguang Wu 
---
 sas_discover.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 190108e..e4fd078 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -361,7 +361,7 @@ void sas_destruct_devices(struct asd_sas_port *port)
}
 }
 
-void sas_destruct_ports(struct asd_sas_port *port)
+static void sas_destruct_ports(struct asd_sas_port *port)
 {
struct sas_port *sas_port, *p;
 

[RFC PATCH mkp-scsi] scsi: libsas: sas_destruct_ports() can be static

[kbuild test robot]

Fixes: 99cfdc04c12e ("scsi: libsas: direct call probe and destruct")
Signed-off-by: Fengguang Wu 
---
 sas_discover.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 190108e..e4fd078 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -361,7 +361,7 @@ void sas_destruct_devices(struct asd_sas_port *port)
}
 }
 
-void sas_destruct_ports(struct asd_sas_port *port)
+static void sas_destruct_ports(struct asd_sas_port *port)
 {
struct sas_port *sas_port, *p;
 

Re: [PATCH v6 2/3] fs: fat: Add volume label entry method function

[OGAWA Hirofumi]

ChenGuanqiao  writes:

> +static int fat_get_volume_label_entry(struct inode *dir, loff_t *pos,
> +struct buffer_head **bh,
> +struct msdos_dir_entry **de)
> +{
> + while (fat_get_entry(dir, pos, bh, de) >= 0) {
> + if (((*de)->attr & ATTR_VOLUME) && (*de)->attr != ATTR_EXT)

It should check IS_FREE().

> + return 0;
> + }
> + return -ENOENT;
> +}
> +
> +int fat_scan_volume_label(struct inode *dir, struct buffer_head **bh,
> +   struct msdos_dir_entry **de)
> +{
> + loff_t offset = 0;
> +
> + if (dir->i_ino != MSDOS_ROOT_INO)
> + return -EINVAL;
> +
> + *bh = NULL;
> + *de = NULL;
> + while (fat_get_volume_label_entry(dir, , bh, de) >= 0)
> + return 0;
> +
> + return -ENOENT;
> +}
> +EXPORT_SYMBOL_GPL(fat_scan_volume_label);

No need this wrapper? Looks like better to merge into
fat_get_volume_label_entry().

> +int fat_add_volume_label_entry(struct inode *dir, const unsigned char *name,
> +struct timespec *ts)
> +{
> + struct msdos_sb_info *sbi = MSDOS_SB(dir->i_sb);
> + struct msdos_dir_entry de;
> + struct fat_slot_info sinfo;
> + __le16 time, date;
> + int err;
> +
> + if (dir->i_ino != MSDOS_ROOT_INO)
> + return -EINVAL;
> +
> + memcpy(de.name, name, MSDOS_NAME);
> + de.attr = ATTR_VOLUME;
> + de.lcase = 0;
> + fat_time_unix2fat(sbi, ts, , , NULL);
> + de.cdate = de.adate = 0;
> + de.ctime = 0;
> + de.ctime_cs = 0;
> + de.time = time;
> + de.date = date;
> + fat_set_start(, 0);
> + de.size = 0;
> +
> + err = fat_add_entries(dir, , 1, );
> + if (err)
> + return err;

Missing call of brelse(sinfo.bh)

> + dir->i_ctime = dir->i_mtime = *ts;

Probably, we should not update this for labal.

> + return fat_sync_inode(dir);

No inode for root.
-- 
OGAWA Hirofumi 

Re: [PATCH v6 2/3] fs: fat: Add volume label entry method function

[OGAWA Hirofumi]

ChenGuanqiao  writes:

> +static int fat_get_volume_label_entry(struct inode *dir, loff_t *pos,
> +struct buffer_head **bh,
> +struct msdos_dir_entry **de)
> +{
> + while (fat_get_entry(dir, pos, bh, de) >= 0) {
> + if (((*de)->attr & ATTR_VOLUME) && (*de)->attr != ATTR_EXT)

It should check IS_FREE().

> + return 0;
> + }
> + return -ENOENT;
> +}
> +
> +int fat_scan_volume_label(struct inode *dir, struct buffer_head **bh,
> +   struct msdos_dir_entry **de)
> +{
> + loff_t offset = 0;
> +
> + if (dir->i_ino != MSDOS_ROOT_INO)
> + return -EINVAL;
> +
> + *bh = NULL;
> + *de = NULL;
> + while (fat_get_volume_label_entry(dir, , bh, de) >= 0)
> + return 0;
> +
> + return -ENOENT;
> +}
> +EXPORT_SYMBOL_GPL(fat_scan_volume_label);

No need this wrapper? Looks like better to merge into
fat_get_volume_label_entry().

> +int fat_add_volume_label_entry(struct inode *dir, const unsigned char *name,
> +struct timespec *ts)
> +{
> + struct msdos_sb_info *sbi = MSDOS_SB(dir->i_sb);
> + struct msdos_dir_entry de;
> + struct fat_slot_info sinfo;
> + __le16 time, date;
> + int err;
> +
> + if (dir->i_ino != MSDOS_ROOT_INO)
> + return -EINVAL;
> +
> + memcpy(de.name, name, MSDOS_NAME);
> + de.attr = ATTR_VOLUME;
> + de.lcase = 0;
> + fat_time_unix2fat(sbi, ts, , , NULL);
> + de.cdate = de.adate = 0;
> + de.ctime = 0;
> + de.ctime_cs = 0;
> + de.time = time;
> + de.date = date;
> + fat_set_start(, 0);
> + de.size = 0;
> +
> + err = fat_add_entries(dir, , 1, );
> + if (err)
> + return err;

Missing call of brelse(sinfo.bh)

> + dir->i_ctime = dir->i_mtime = *ts;

Probably, we should not update this for labal.

> + return fat_sync_inode(dir);

No inode for root.
-- 
OGAWA Hirofumi 

HELLO

[Mr. Hamza Kabore]

-- 
Hello Dear Friend,

Greetings and how are you doing?
I want to know if you are keen to be my partner in claiming the
fortune $12.8 Million USD left by a late client. If you're
interested Revert for more details.

Awaiting your reply

Hamza Kabore

HELLO

[Mr. Hamza Kabore]

-- 
Hello Dear Friend,

Greetings and how are you doing?
I want to know if you are keen to be my partner in claiming the
fortune $12.8 Million USD left by a late client. If you're
interested Revert for more details.

Awaiting your reply

Hamza Kabore

Re: [PATCH v3 24/27] staging: ccree: use a consistent file naming convention

[Gilad Ben-Yossef]

On Mon, Jan 8, 2018 at 5:28 PM, Greg Kroah-Hartman
 wrote:
> On Sun, Jan 07, 2018 at 12:14:35PM +, Gilad Ben-Yossef wrote:
>> The ccree driver source files were using an inconsistent
>> naming convention stemming from what the company was called
>> when they were added.
>>
>> Move to a single consistent naming convention for better
>> code readability.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>> ---
>>  drivers/staging/ccree/Makefile   |6 +-
>>  drivers/staging/ccree/cc_aead.c  | 2709 
>> ++
>>  drivers/staging/ccree/cc_aead.h  |  109 ++
>>  drivers/staging/ccree/cc_buffer_mgr.c| 1657 ++
>>  drivers/staging/ccree/cc_buffer_mgr.h|   74 +
>>  drivers/staging/ccree/cc_cipher.c| 1171 +
>>  drivers/staging/ccree/cc_cipher.h|   74 +
>>  drivers/staging/ccree/cc_debugfs.c   |2 +-
>>  drivers/staging/ccree/cc_driver.c|  508 ++
>>  drivers/staging/ccree/cc_driver.h|  194 +++
>>  drivers/staging/ccree/cc_fips.c  |  112 ++
>>  drivers/staging/ccree/cc_fips.h  |   37 +
>>  drivers/staging/ccree/cc_hash.c  | 2299 +
>>  drivers/staging/ccree/cc_hash.h  |  114 ++
>>  drivers/staging/ccree/cc_host_regs.h |  142 ++
>>  drivers/staging/ccree/cc_hw_queue_defs.h |2 +-
>>  drivers/staging/ccree/cc_ivgen.c |  281 
>>  drivers/staging/ccree/cc_ivgen.h |   55 +
>>  drivers/staging/ccree/cc_kernel_regs.h   |  167 ++
>>  drivers/staging/ccree/cc_pm.c|  125 ++
>>  drivers/staging/ccree/cc_pm.h|   57 +
>>  drivers/staging/ccree/cc_request_mgr.c   |  719 
>>  drivers/staging/ccree/cc_request_mgr.h   |   51 +
>>  drivers/staging/ccree/cc_sram_mgr.c  |  107 ++
>>  drivers/staging/ccree/cc_sram_mgr.h  |   65 +
>>  drivers/staging/ccree/dx_crys_kernel.h   |  167 --
>>  drivers/staging/ccree/dx_host.h  |  142 --
>>  drivers/staging/ccree/ssi_aead.c | 2709 
>> --
>>  drivers/staging/ccree/ssi_aead.h |  109 --
>>  drivers/staging/ccree/ssi_buffer_mgr.c   | 1657 --
>>  drivers/staging/ccree/ssi_buffer_mgr.h   |   74 -
>>  drivers/staging/ccree/ssi_cipher.c   | 1171 -
>>  drivers/staging/ccree/ssi_cipher.h   |   74 -
>>  drivers/staging/ccree/ssi_driver.c   |  508 --
>>  drivers/staging/ccree/ssi_driver.h   |  194 ---
>>  drivers/staging/ccree/ssi_fips.c |  112 --
>>  drivers/staging/ccree/ssi_fips.h |   37 -
>>  drivers/staging/ccree/ssi_hash.c | 2299 -
>>  drivers/staging/ccree/ssi_hash.h |  114 --
>>  drivers/staging/ccree/ssi_ivgen.c|  281 
>>  drivers/staging/ccree/ssi_ivgen.h|   55 -
>>  drivers/staging/ccree/ssi_pm.c   |  125 --
>>  drivers/staging/ccree/ssi_pm.h   |   57 -
>>  drivers/staging/ccree/ssi_request_mgr.c  |  719 
>>  drivers/staging/ccree/ssi_request_mgr.h  |   51 -
>>  drivers/staging/ccree/ssi_sram_mgr.c |  107 --
>>  drivers/staging/ccree/ssi_sram_mgr.h |   65 -
>>  47 files changed, 10832 insertions(+), 10832 deletions(-)
>>  create mode 100644 drivers/staging/ccree/cc_aead.c
>>  create mode 100644 drivers/staging/ccree/cc_aead.h
>>  create mode 100644 drivers/staging/ccree/cc_buffer_mgr.c
>>  create mode 100644 drivers/staging/ccree/cc_buffer_mgr.h
>>  create mode 100644 drivers/staging/ccree/cc_cipher.c
>>  create mode 100644 drivers/staging/ccree/cc_cipher.h
>>  create mode 100644 drivers/staging/ccree/cc_driver.c
>>  create mode 100644 drivers/staging/ccree/cc_driver.h
>>  create mode 100644 drivers/staging/ccree/cc_fips.c
>>  create mode 100644 drivers/staging/ccree/cc_fips.h
>>  create mode 100644 drivers/staging/ccree/cc_hash.c
>>  create mode 100644 drivers/staging/ccree/cc_hash.h
>>  create mode 100644 drivers/staging/ccree/cc_host_regs.h
>>  create mode 100644 drivers/staging/ccree/cc_ivgen.c
>>  create mode 100644 drivers/staging/ccree/cc_ivgen.h
>>  create mode 100644 drivers/staging/ccree/cc_kernel_regs.h
>>  create mode 100644 drivers/staging/ccree/cc_pm.c
>>  create mode 100644 drivers/staging/ccree/cc_pm.h
>>  create mode 100644 drivers/staging/ccree/cc_request_mgr.c
>>  create mode 100644 drivers/staging/ccree/cc_request_mgr.h
>>  create mode 100644 drivers/staging/ccree/cc_sram_mgr.c
>>  create mode 100644 drivers/staging/ccree/cc_sram_mgr.h
>>  delete mode 100644 drivers/staging/ccree/dx_crys_kernel.h
>>  delete mode 100644 drivers/staging/ccree/dx_host.h
>>  delete mode 100644 drivers/staging/ccree/ssi_aead.c
>>  delete mode 100644 drivers/staging/ccree/ssi_aead.h
>>  delete mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c
>>  delete mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h
>>  delete mode 100644 drivers/staging/ccree/ssi_cipher.c
>>  delete mode 100644 

Re: [PATCH v3 24/27] staging: ccree: use a consistent file naming convention

[Gilad Ben-Yossef]

On Mon, Jan 8, 2018 at 5:28 PM, Greg Kroah-Hartman
 wrote:
> On Sun, Jan 07, 2018 at 12:14:35PM +, Gilad Ben-Yossef wrote:
>> The ccree driver source files were using an inconsistent
>> naming convention stemming from what the company was called
>> when they were added.
>>
>> Move to a single consistent naming convention for better
>> code readability.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>> ---
>>  drivers/staging/ccree/Makefile   |6 +-
>>  drivers/staging/ccree/cc_aead.c  | 2709 
>> ++
>>  drivers/staging/ccree/cc_aead.h  |  109 ++
>>  drivers/staging/ccree/cc_buffer_mgr.c| 1657 ++
>>  drivers/staging/ccree/cc_buffer_mgr.h|   74 +
>>  drivers/staging/ccree/cc_cipher.c| 1171 +
>>  drivers/staging/ccree/cc_cipher.h|   74 +
>>  drivers/staging/ccree/cc_debugfs.c   |2 +-
>>  drivers/staging/ccree/cc_driver.c|  508 ++
>>  drivers/staging/ccree/cc_driver.h|  194 +++
>>  drivers/staging/ccree/cc_fips.c  |  112 ++
>>  drivers/staging/ccree/cc_fips.h  |   37 +
>>  drivers/staging/ccree/cc_hash.c  | 2299 +
>>  drivers/staging/ccree/cc_hash.h  |  114 ++
>>  drivers/staging/ccree/cc_host_regs.h |  142 ++
>>  drivers/staging/ccree/cc_hw_queue_defs.h |2 +-
>>  drivers/staging/ccree/cc_ivgen.c |  281 
>>  drivers/staging/ccree/cc_ivgen.h |   55 +
>>  drivers/staging/ccree/cc_kernel_regs.h   |  167 ++
>>  drivers/staging/ccree/cc_pm.c|  125 ++
>>  drivers/staging/ccree/cc_pm.h|   57 +
>>  drivers/staging/ccree/cc_request_mgr.c   |  719 
>>  drivers/staging/ccree/cc_request_mgr.h   |   51 +
>>  drivers/staging/ccree/cc_sram_mgr.c  |  107 ++
>>  drivers/staging/ccree/cc_sram_mgr.h  |   65 +
>>  drivers/staging/ccree/dx_crys_kernel.h   |  167 --
>>  drivers/staging/ccree/dx_host.h  |  142 --
>>  drivers/staging/ccree/ssi_aead.c | 2709 
>> --
>>  drivers/staging/ccree/ssi_aead.h |  109 --
>>  drivers/staging/ccree/ssi_buffer_mgr.c   | 1657 --
>>  drivers/staging/ccree/ssi_buffer_mgr.h   |   74 -
>>  drivers/staging/ccree/ssi_cipher.c   | 1171 -
>>  drivers/staging/ccree/ssi_cipher.h   |   74 -
>>  drivers/staging/ccree/ssi_driver.c   |  508 --
>>  drivers/staging/ccree/ssi_driver.h   |  194 ---
>>  drivers/staging/ccree/ssi_fips.c |  112 --
>>  drivers/staging/ccree/ssi_fips.h |   37 -
>>  drivers/staging/ccree/ssi_hash.c | 2299 -
>>  drivers/staging/ccree/ssi_hash.h |  114 --
>>  drivers/staging/ccree/ssi_ivgen.c|  281 
>>  drivers/staging/ccree/ssi_ivgen.h|   55 -
>>  drivers/staging/ccree/ssi_pm.c   |  125 --
>>  drivers/staging/ccree/ssi_pm.h   |   57 -
>>  drivers/staging/ccree/ssi_request_mgr.c  |  719 
>>  drivers/staging/ccree/ssi_request_mgr.h  |   51 -
>>  drivers/staging/ccree/ssi_sram_mgr.c |  107 --
>>  drivers/staging/ccree/ssi_sram_mgr.h |   65 -
>>  47 files changed, 10832 insertions(+), 10832 deletions(-)
>>  create mode 100644 drivers/staging/ccree/cc_aead.c
>>  create mode 100644 drivers/staging/ccree/cc_aead.h
>>  create mode 100644 drivers/staging/ccree/cc_buffer_mgr.c
>>  create mode 100644 drivers/staging/ccree/cc_buffer_mgr.h
>>  create mode 100644 drivers/staging/ccree/cc_cipher.c
>>  create mode 100644 drivers/staging/ccree/cc_cipher.h
>>  create mode 100644 drivers/staging/ccree/cc_driver.c
>>  create mode 100644 drivers/staging/ccree/cc_driver.h
>>  create mode 100644 drivers/staging/ccree/cc_fips.c
>>  create mode 100644 drivers/staging/ccree/cc_fips.h
>>  create mode 100644 drivers/staging/ccree/cc_hash.c
>>  create mode 100644 drivers/staging/ccree/cc_hash.h
>>  create mode 100644 drivers/staging/ccree/cc_host_regs.h
>>  create mode 100644 drivers/staging/ccree/cc_ivgen.c
>>  create mode 100644 drivers/staging/ccree/cc_ivgen.h
>>  create mode 100644 drivers/staging/ccree/cc_kernel_regs.h
>>  create mode 100644 drivers/staging/ccree/cc_pm.c
>>  create mode 100644 drivers/staging/ccree/cc_pm.h
>>  create mode 100644 drivers/staging/ccree/cc_request_mgr.c
>>  create mode 100644 drivers/staging/ccree/cc_request_mgr.h
>>  create mode 100644 drivers/staging/ccree/cc_sram_mgr.c
>>  create mode 100644 drivers/staging/ccree/cc_sram_mgr.h
>>  delete mode 100644 drivers/staging/ccree/dx_crys_kernel.h
>>  delete mode 100644 drivers/staging/ccree/dx_host.h
>>  delete mode 100644 drivers/staging/ccree/ssi_aead.c
>>  delete mode 100644 drivers/staging/ccree/ssi_aead.h
>>  delete mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c
>>  delete mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h
>>  delete mode 100644 drivers/staging/ccree/ssi_cipher.c
>>  delete mode 100644 drivers/staging/ccree/ssi_cipher.h
>>  delete mode 100644 

Re: [PATCH] crypto: clear htmldocs build warnings for crypto/hash

[Herbert Xu]

On Mon, Jan 08, 2018 at 05:43:18PM +0100, Kamil Konieczny wrote:

> Is it mandatory for both async hash and shash ?
> 
> in crypto/ahash.c in function
> 
> static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
> 
> there is:
> 
>   hash->export = ahash_no_export;
>   hash->import = ahash_no_import;
> 
> and later in the same function:
> 
>   if (alg->export)
>   hash->export = alg->export;
>   if (alg->import)
>   hash->import = alg->import;

That's just a leftover from the old days before we started requiring
them.  These should be removed so that the registration fails if
they're not provided.

The requirement has been in place for a while now and we have been
failing any algorithms with a zero statesize which is only used by
import/export.

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

Re: [PATCH] crypto: clear htmldocs build warnings for crypto/hash

[Herbert Xu]

On Mon, Jan 08, 2018 at 05:43:18PM +0100, Kamil Konieczny wrote:

> Is it mandatory for both async hash and shash ?
> 
> in crypto/ahash.c in function
> 
> static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
> 
> there is:
> 
>   hash->export = ahash_no_export;
>   hash->import = ahash_no_import;
> 
> and later in the same function:
> 
>   if (alg->export)
>   hash->export = alg->export;
>   if (alg->import)
>   hash->import = alg->import;

That's just a leftover from the old days before we started requiring
them.  These should be removed so that the registration fails if
they're not provided.

The requirement has been in place for a while now and we have been
failing any algorithms with a zero statesize which is only used by
import/export.

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

RE: [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly

[Appana Durga Kedareswara Rao]

Hi,

Thanks for the review... 

>On Tue, Jan 09, 2018 at 04:48:10AM +, Appana Durga Kedareswara Rao
>wrote:
>> Hi,
>>
>> >On Mon, Jan 08, 2018 at 05:25:01PM +, Appana Durga Kedareswara
>> >Rao
>> >wrote:
>> >> Hi,
>> >>
>> >> 
>> >> >> >> +   xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> >> >> >> +   xdev->common.src_addr_widths = BIT(addr_width / 8);
>> >> >> >
>> >> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
>> >> >> >What is value of addr_width here typically? Usually controllers
>> >> >> >can support different widths and this is a surprise that you
>> >> >> >support only one value
>> >> >>
>> >> >> Controller supports address width of 32 and 64.
>> >> >
>> >> >Then this should have both 32 and 64 values here
>> >>
>> >> Address width is configurable parameter at the h/w level.
>> >> Since this IP is a soft IP user can create a design with either
>> >> 32-bit or 64-bit address configuration.
>> >
>> >and not both right?
>>
>> Yes not both at the same time...
>> Axi dma controller can be configured for either 32-bit or 64-bit address...
>
>So my suspicion was correct.  I would suggest you to read up on the
>documentation again. The src/dst_addr_widths has _nothing_ to do with 32/64
>bit addresses used.
>
>It is the capability of the dma controller to do transfers with data width as 
>8bits,
>16 bits, so on. iKey is "data width" and not address type.
>This typically translates to DMA FIFO configuration of the controller!

Thanks for the detailed explanation... 
I have gone through the spec again controller does supports 1 byte, 2 byte, 4 
byte up to 128 byte transfers.
In order to do variable length transfers user needs to drive a valid value to 
the tkeep strobe signal at the h/w level.
And user needs to configure the below parameters c_m_axis_mm2s_tdata_width or 
c_m_axis_s2mm_tdata_width
With desired configuration at the h/w level.
Controller supports data width of 8, 16, 32, 64, 128, 256, 512 and 1,024 bits 
(i.e. c_m_axis_mm2s_tdata_width/ c_m_axis_s2mm_tdata_width parameters range)

At the s/w level currently we are getting c_m_axis_mm2s_tdata_width/ 
c_m_axis_s2mm_tdata_width
Configuration as xlnx,datawidth property in the device-tree.

So proper values for the src/dst_addr width fields should be, datawidth 
property in bytes.
Please correct me if I am wrong... 

Changes looks like below...
Here width is in bytes based on the h/w configuration... 

--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2411,6 +2411,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device 
*xdev,
chan->direction = DMA_MEM_TO_DEV;
chan->id = chan_id;
chan->tdest = chan_id;
+   xdev->common.directions = BIT(DMA_MEM_TO_DEV);
+   xdev->common.src_addr_widths = BIT(width);
 
chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2428,6 +2430,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device 
*xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+   xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
+   xdev->common.dst_addr_widths = BIT(width);
 
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {


Regards,
Kedar.

>
>--
>~Vinod

RE: [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly

[Appana Durga Kedareswara Rao]

Hi,

Thanks for the review... 

>On Tue, Jan 09, 2018 at 04:48:10AM +, Appana Durga Kedareswara Rao
>wrote:
>> Hi,
>>
>> >On Mon, Jan 08, 2018 at 05:25:01PM +, Appana Durga Kedareswara
>> >Rao
>> >wrote:
>> >> Hi,
>> >>
>> >> 
>> >> >> >> +   xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> >> >> >> +   xdev->common.src_addr_widths = BIT(addr_width / 8);
>> >> >> >
>> >> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
>> >> >> >What is value of addr_width here typically? Usually controllers
>> >> >> >can support different widths and this is a surprise that you
>> >> >> >support only one value
>> >> >>
>> >> >> Controller supports address width of 32 and 64.
>> >> >
>> >> >Then this should have both 32 and 64 values here
>> >>
>> >> Address width is configurable parameter at the h/w level.
>> >> Since this IP is a soft IP user can create a design with either
>> >> 32-bit or 64-bit address configuration.
>> >
>> >and not both right?
>>
>> Yes not both at the same time...
>> Axi dma controller can be configured for either 32-bit or 64-bit address...
>
>So my suspicion was correct.  I would suggest you to read up on the
>documentation again. The src/dst_addr_widths has _nothing_ to do with 32/64
>bit addresses used.
>
>It is the capability of the dma controller to do transfers with data width as 
>8bits,
>16 bits, so on. iKey is "data width" and not address type.
>This typically translates to DMA FIFO configuration of the controller!

Thanks for the detailed explanation... 
I have gone through the spec again controller does supports 1 byte, 2 byte, 4 
byte up to 128 byte transfers.
In order to do variable length transfers user needs to drive a valid value to 
the tkeep strobe signal at the h/w level.
And user needs to configure the below parameters c_m_axis_mm2s_tdata_width or 
c_m_axis_s2mm_tdata_width
With desired configuration at the h/w level.
Controller supports data width of 8, 16, 32, 64, 128, 256, 512 and 1,024 bits 
(i.e. c_m_axis_mm2s_tdata_width/ c_m_axis_s2mm_tdata_width parameters range)

At the s/w level currently we are getting c_m_axis_mm2s_tdata_width/ 
c_m_axis_s2mm_tdata_width
Configuration as xlnx,datawidth property in the device-tree.

So proper values for the src/dst_addr width fields should be, datawidth 
property in bytes.
Please correct me if I am wrong... 

Changes looks like below...
Here width is in bytes based on the h/w configuration... 

--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2411,6 +2411,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device 
*xdev,
chan->direction = DMA_MEM_TO_DEV;
chan->id = chan_id;
chan->tdest = chan_id;
+   xdev->common.directions = BIT(DMA_MEM_TO_DEV);
+   xdev->common.src_addr_widths = BIT(width);
 
chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2428,6 +2430,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device 
*xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+   xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
+   xdev->common.dst_addr_widths = BIT(width);
 
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {


Regards,
Kedar.

>
>--
>~Vinod

Re: [PATCH v2] v4l: doc: Clarify v4l2_mbus_fmt height definition

[Hans Verkuil]

On 01/08/2018 06:55 PM, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
> 
> Clarify this using the same text as is provided for the v4l2_pix_format
> which is explicit on the matter, and by matching the terminology of
> 'image height' rather than the misleading 'frame height'.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
> v2:
>  - Duplicated explicit text from v4l2_pix_format rather than
>referencing it.
> 
>  Documentation/media/uapi/v4l/subdev-formats.rst | 8 ++--
>  include/uapi/linux/v4l2-mediabus.h  | 4 ++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
> b/Documentation/media/uapi/v4l/subdev-formats.rst
> index b1eea44550e1..9fcabe7f9367 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -16,10 +16,14 @@ Media Bus Formats
>  
>  * - __u32
>- ``width``
> -  - Image width, in pixels.
> +  - Image width in pixels.
>  * - __u32
>- ``height``
> -  - Image height, in pixels.
> +  - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
> + ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
> + refers to the number of lines in the field, otherwise it refers to
> + the number of lines in the frame (which is twice the field height
> + for interlaced formats).
>  * - __u32
>- ``code``
>- Format code, from enum
> diff --git a/include/uapi/linux/v4l2-mediabus.h 
> b/include/uapi/linux/v4l2-mediabus.h
> index 6e20de63ec59..123a231001a8 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -18,8 +18,8 @@
>  
>  /**
>   * struct v4l2_mbus_framefmt - frame format on the media bus
> - * @width:   frame width
> - * @height:  frame height
> + * @width:   image width
> + * @height:  image height
>   * @code:data format code (from enum v4l2_mbus_pixelcode)
>   * @field:   used interlacing type (from enum v4l2_field)
>   * @colorspace:  colorspace of the data (from enum v4l2_colorspace)
> 

Re: [PATCH v2] v4l: doc: Clarify v4l2_mbus_fmt height definition

[Hans Verkuil]

On 01/08/2018 06:55 PM, Kieran Bingham wrote:
> The v4l2_mbus_fmt width and height corresponds directly with the
> v4l2_pix_format definitions, yet the differences in documentation make
> it ambiguous what to do in the event of field heights.
> 
> Clarify this using the same text as is provided for the v4l2_pix_format
> which is explicit on the matter, and by matching the terminology of
> 'image height' rather than the misleading 'frame height'.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
> v2:
>  - Duplicated explicit text from v4l2_pix_format rather than
>referencing it.
> 
>  Documentation/media/uapi/v4l/subdev-formats.rst | 8 ++--
>  include/uapi/linux/v4l2-mediabus.h  | 4 ++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
> b/Documentation/media/uapi/v4l/subdev-formats.rst
> index b1eea44550e1..9fcabe7f9367 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -16,10 +16,14 @@ Media Bus Formats
>  
>  * - __u32
>- ``width``
> -  - Image width, in pixels.
> +  - Image width in pixels.
>  * - __u32
>- ``height``
> -  - Image height, in pixels.
> +  - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``,
> + ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height
> + refers to the number of lines in the field, otherwise it refers to
> + the number of lines in the frame (which is twice the field height
> + for interlaced formats).
>  * - __u32
>- ``code``
>- Format code, from enum
> diff --git a/include/uapi/linux/v4l2-mediabus.h 
> b/include/uapi/linux/v4l2-mediabus.h
> index 6e20de63ec59..123a231001a8 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -18,8 +18,8 @@
>  
>  /**
>   * struct v4l2_mbus_framefmt - frame format on the media bus
> - * @width:   frame width
> - * @height:  frame height
> + * @width:   image width
> + * @height:  image height
>   * @code:data format code (from enum v4l2_mbus_pixelcode)
>   * @field:   used interlacing type (from enum v4l2_field)
>   * @colorspace:  colorspace of the data (from enum v4l2_colorspace)
> 

Re: [PATCH] ath9k: add a quirk to set use_msi automatically

[Kalle Valo]

AceLan Kao  writes:

> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
> for WLAN device. So adding a quirk to list those machines and set
> use_msi automatically.
> Adding the following platforms to the quirk.
>Dell Inspiron 24-3460
>Dell Inspiron 3472
>Dell Inspiron 14-3473
>Dell Vostro 3262
>Dell Vostro 15-3572
>
> Signed-off-by: AceLan Kao 

[...]

> @@ -96,6 +97,56 @@ static const struct ieee80211_tpt_blink ath9k_tpt_blink[] 
> = {
>  };
>  #endif
>  
> +static int __init set_use_msi(const struct dmi_system_id *dmi)
> +{
> + ath9k_use_msi = 1;
> + return 1;
> +}
> +
> +static const struct dmi_system_id ath9k_quirks[] __initconst = {
> + {
> + .callback = set_use_msi,
> + .ident = "Dell Inspiron 24-3460",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
> + },
> + },

Larry, didn't rtlwifi have similar situation that with certain laptops
users were required to enable a module parameter to get the device
working? I think rtlwifi should do the same as AceLan does here as then
the user would not need to manually set the module parameter.

-- 
Kalle Valo

Re: [PATCH] ath9k: add a quirk to set use_msi automatically

[Kalle Valo]

AceLan Kao  writes:

> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
> for WLAN device. So adding a quirk to list those machines and set
> use_msi automatically.
> Adding the following platforms to the quirk.
>Dell Inspiron 24-3460
>Dell Inspiron 3472
>Dell Inspiron 14-3473
>Dell Vostro 3262
>Dell Vostro 15-3572
>
> Signed-off-by: AceLan Kao 

[...]

> @@ -96,6 +97,56 @@ static const struct ieee80211_tpt_blink ath9k_tpt_blink[] 
> = {
>  };
>  #endif
>  
> +static int __init set_use_msi(const struct dmi_system_id *dmi)
> +{
> + ath9k_use_msi = 1;
> + return 1;
> +}
> +
> +static const struct dmi_system_id ath9k_quirks[] __initconst = {
> + {
> + .callback = set_use_msi,
> + .ident = "Dell Inspiron 24-3460",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
> + },
> + },

Larry, didn't rtlwifi have similar situation that with certain laptops
users were required to enable a module parameter to get the device
working? I think rtlwifi should do the same as AceLan does here as then
the user would not need to manually set the module parameter.

-- 
Kalle Valo

Re: [PATCH v2] media: i2c: adv748x: fix HDMI field heights

[Hans Verkuil]

On 01/08/2018 07:14 PM, Kieran Bingham wrote:
> The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
> types.  The correct specification for the height on the mbus is the
> image height, in this instance, the field height.
> 
> The AFE component already correctly adjusts the height on the mbus, but
> the HDMI component got left behind.
> 
> Adjust the mbus height to correctly describe the image height of the
> fields when processing interlaced video for HDMI pipelines.
> 
> Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
> Reviewed-by: Niklas Söderlund 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
> v2:
>  - switch conditional to check the fmt->field, removing the need for
>the comment.
> 
>  drivers/media/i2c/adv748x/adv748x-hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> index 4da4253553fc..10d229a4f088 100644
> --- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> @@ -105,6 +105,9 @@ static void adv748x_hdmi_fill_format(struct adv748x_hdmi 
> *hdmi,
>  
>   fmt->width = hdmi->timings.bt.width;
>   fmt->height = hdmi->timings.bt.height;
> +
> + if (fmt->field == V4L2_FIELD_ALTERNATE)
> + fmt->height /= 2;
>  }
>  
>  static void adv748x_fill_optional_dv_timings(struct v4l2_dv_timings *timings)
> 

Re: [PATCH v2] media: i2c: adv748x: fix HDMI field heights

[Hans Verkuil]

On 01/08/2018 07:14 PM, Kieran Bingham wrote:
> The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
> types.  The correct specification for the height on the mbus is the
> image height, in this instance, the field height.
> 
> The AFE component already correctly adjusts the height on the mbus, but
> the HDMI component got left behind.
> 
> Adjust the mbus height to correctly describe the image height of the
> fields when processing interlaced video for HDMI pipelines.
> 
> Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
> Reviewed-by: Niklas Söderlund 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
> v2:
>  - switch conditional to check the fmt->field, removing the need for
>the comment.
> 
>  drivers/media/i2c/adv748x/adv748x-hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> index 4da4253553fc..10d229a4f088 100644
> --- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> @@ -105,6 +105,9 @@ static void adv748x_hdmi_fill_format(struct adv748x_hdmi 
> *hdmi,
>  
>   fmt->width = hdmi->timings.bt.width;
>   fmt->height = hdmi->timings.bt.height;
> +
> + if (fmt->field == V4L2_FIELD_ALTERNATE)
> + fmt->height /= 2;
>  }
>  
>  static void adv748x_fill_optional_dv_timings(struct v4l2_dv_timings *timings)
> 

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Dave Young]

On 01/09/18 at 01:41pm, Baoquan He wrote:
> On 01/09/18 at 09:09am, Dave Young wrote:
> > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote:
> > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote:
> > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote:
> > > > > 
> > > > > hi Kirill,
> > > > > 
> > > > > As Mike reported it below, your 5-level paging related upstream 
> > > > > commit 
> > > > > 83e3c48729d9 and all its followup fixes:
> > > > > 
> > > > >  83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for 
> > > > > CONFIG_SPARSEMEM_EXTREME=y
> > > > >  629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when 
> > > > > CONFIG_SPARSEMEM_EXTREME=y
> > > > >  d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section
> > > > > 
> > > > > ... still breaks kexec - and that now regresses -stable as well.
> > > > > 
> > > > > Given that 5-level paging now syntactically depends on having this 
> > > > > commit, if we 
> > > > > fully revert this then we'll have to disable 5-level paging as well.
> > > 
> > > This *should* help.
> > > 
> > > Mike, could you test this? (On top of the rest of the fixes.)
> > > 
> > > Sorry for the mess.
> > > 
> > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001
> > > From: "Kirill A. Shutemov" 
> > > Date: Tue, 9 Jan 2018 02:55:47 +0300
> > > Subject: [PATCH] kdump: Write a correct address of mem_section into 
> > > vmcoreinfo
> > > 
> > > Depending on configuration mem_section can now be an array or a pointer
> > > to an array allocated dynamically. In most cases, we can continue to refer
> > > to it as 'mem_section' regardless of what it is.
> > > 
> > > But there's one exception: '_section' means "address of the array" if
> > > mem_section is an array, but if mem_section is a pointer, it would mean
> > > "address of the pointer".
> > > 
> > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section)
> > > writes down address of pointer into vmcoreinfo, not array as we wanted.
> > > 
> > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation
> > > correctly for both cases.
> > > 
> > > Signed-off-by: Kirill A. Shutemov 
> > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for 
> > > CONFIG_SPARSEMEM_EXTREME=y")
> > > ---
> > >  include/linux/crash_core.h | 2 ++
> > >  kernel/crash_core.c| 2 +-
> > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> > > index 06097ef30449..83ae04950269 100644
> > > --- a/include/linux/crash_core.h
> > > +++ b/include/linux/crash_core.h
> > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
> > >   vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
> > >  #define VMCOREINFO_SYMBOL(name) \
> > >   vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long))
> > > +#define VMCOREINFO_ARRAY(name) \
> > 
> > Thanks for the patch, I have a similar patch but makedumpfile maintainer
> > is looking at a userspace fix instead.
> 
> Seems we should add lkml to CC next time so that people can watch it.

Yes, agreed.

> 
> > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better.
> 
> I still think using vmcoreinfo_append_str is better. Unless we replace
> all array variables with the newly added macro.
> 
> vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n",
> (unsigned long)mem_section);

I have no strong opinion, either change all array uses or just introduce
the macro and start to use it from now on if we have similar array
symbols.

> > 
> > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name)
> > >  #define VMCOREINFO_SIZE(name) \
> > >   vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
> > > (unsigned long)sizeof(name))
> > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > > index b3663896278e..d4122a837477 100644
> > > --- a/kernel/crash_core.c
> > > +++ b/kernel/crash_core.c
> > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void)
> > >   VMCOREINFO_SYMBOL(contig_page_data);
> > >  #endif
> > >  #ifdef CONFIG_SPARSEMEM
> > > - VMCOREINFO_SYMBOL(mem_section);
> > > + VMCOREINFO_ARRAY(mem_section);
> > >   VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
> > >   VMCOREINFO_STRUCT_SIZE(mem_section);
> > >   VMCOREINFO_OFFSET(mem_section, section_mem_map);
> > > -- 
> > >  Kirill A. Shutemov
> > 
> > Thanks
> > Dave

Thanks
Dave

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

[Dave Young]

On 01/09/18 at 01:41pm, Baoquan He wrote:
> On 01/09/18 at 09:09am, Dave Young wrote:
> > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote:
> > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote:
> > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote:
> > > > > 
> > > > > hi Kirill,
> > > > > 
> > > > > As Mike reported it below, your 5-level paging related upstream 
> > > > > commit 
> > > > > 83e3c48729d9 and all its followup fixes:
> > > > > 
> > > > >  83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for 
> > > > > CONFIG_SPARSEMEM_EXTREME=y
> > > > >  629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when 
> > > > > CONFIG_SPARSEMEM_EXTREME=y
> > > > >  d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section
> > > > > 
> > > > > ... still breaks kexec - and that now regresses -stable as well.
> > > > > 
> > > > > Given that 5-level paging now syntactically depends on having this 
> > > > > commit, if we 
> > > > > fully revert this then we'll have to disable 5-level paging as well.
> > > 
> > > This *should* help.
> > > 
> > > Mike, could you test this? (On top of the rest of the fixes.)
> > > 
> > > Sorry for the mess.
> > > 
> > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001
> > > From: "Kirill A. Shutemov" 
> > > Date: Tue, 9 Jan 2018 02:55:47 +0300
> > > Subject: [PATCH] kdump: Write a correct address of mem_section into 
> > > vmcoreinfo
> > > 
> > > Depending on configuration mem_section can now be an array or a pointer
> > > to an array allocated dynamically. In most cases, we can continue to refer
> > > to it as 'mem_section' regardless of what it is.
> > > 
> > > But there's one exception: '_section' means "address of the array" if
> > > mem_section is an array, but if mem_section is a pointer, it would mean
> > > "address of the pointer".
> > > 
> > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section)
> > > writes down address of pointer into vmcoreinfo, not array as we wanted.
> > > 
> > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation
> > > correctly for both cases.
> > > 
> > > Signed-off-by: Kirill A. Shutemov 
> > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for 
> > > CONFIG_SPARSEMEM_EXTREME=y")
> > > ---
> > >  include/linux/crash_core.h | 2 ++
> > >  kernel/crash_core.c| 2 +-
> > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> > > index 06097ef30449..83ae04950269 100644
> > > --- a/include/linux/crash_core.h
> > > +++ b/include/linux/crash_core.h
> > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
> > >   vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
> > >  #define VMCOREINFO_SYMBOL(name) \
> > >   vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long))
> > > +#define VMCOREINFO_ARRAY(name) \
> > 
> > Thanks for the patch, I have a similar patch but makedumpfile maintainer
> > is looking at a userspace fix instead.
> 
> Seems we should add lkml to CC next time so that people can watch it.

Yes, agreed.

> 
> > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better.
> 
> I still think using vmcoreinfo_append_str is better. Unless we replace
> all array variables with the newly added macro.
> 
> vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n",
> (unsigned long)mem_section);

I have no strong opinion, either change all array uses or just introduce
the macro and start to use it from now on if we have similar array
symbols.

> > 
> > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name)
> > >  #define VMCOREINFO_SIZE(name) \
> > >   vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
> > > (unsigned long)sizeof(name))
> > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > > index b3663896278e..d4122a837477 100644
> > > --- a/kernel/crash_core.c
> > > +++ b/kernel/crash_core.c
> > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void)
> > >   VMCOREINFO_SYMBOL(contig_page_data);
> > >  #endif
> > >  #ifdef CONFIG_SPARSEMEM
> > > - VMCOREINFO_SYMBOL(mem_section);
> > > + VMCOREINFO_ARRAY(mem_section);
> > >   VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
> > >   VMCOREINFO_STRUCT_SIZE(mem_section);
> > >   VMCOREINFO_OFFSET(mem_section, section_mem_map);
> > > -- 
> > >  Kirill A. Shutemov
> > 
> > Thanks
> > Dave

Thanks
Dave

Re: [lkp-robot] [mm/cma] 2b0f904a5a: fio.read_bw_MBps -16.1% regression

[Joonsoo Kim]

On Sat, Jan 06, 2018 at 05:26:31PM +0800, Ye Xiaolong wrote:
> Hi,
> 
> On 01/03, Joonsoo Kim wrote:
> >Hello!
> >
> >On Tue, Jan 02, 2018 at 02:35:28PM +0800, kernel test robot wrote:
> >> 
> >> Greeting,
> >> 
> >> FYI, we noticed a -16.1% regression of fio.read_bw_MBps due to commit:
> >> 
> >> 
> >> commit: 2b0f904a5a8781498417d67226fd12c5e56053ae ("mm/cma: manage the 
> >> memory of the CMA area by using the ZONE_MOVABLE")
> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >> 
> >> in testcase: fio-basic
> >> on test machine: 56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 
> >> 256G memory
> >> with following parameters:
> >> 
> >>disk: 2pmem
> >>fs: ext4
> >>runtime: 200s
> >>nr_task: 50%
> >>time_based: tb
> >>rw: randread
> >>bs: 2M
> >>ioengine: mmap
> >>test_size: 200G
> >>cpufreq_governor: performance
> >> 
> >> test-description: Fio is a tool that will spawn a number of threads or 
> >> processes doing a particular type of I/O action as specified by the user.
> >> test-url: https://github.com/axboe/fio
> >> 
> >> 
> >> 
> >> Details are as below:
> >> -->
> >> 
> >> 
> >> To reproduce:
> >> 
> >> git clone https://github.com/intel/lkp-tests.git
> >> cd lkp-tests
> >> bin/lkp install job.yaml  # job file is attached in this email
> >> bin/lkp run job.yaml
> >> 
> >> =
> >> bs/compiler/cpufreq_governor/disk/fs/ioengine/kconfig/nr_task/rootfs/runtime/rw/tbox_group/test_size/testcase/time_based:
> >>   
> >> 2M/gcc-7/performance/2pmem/ext4/mmap/x86_64-rhel-7.2/50%/debian-x86_64-2016-08-31.cgz/200s/randread/lkp-hsw-ep6/200G/fio-basic/tb
> >> 
> >> commit: 
> >>   f6572f9cd2 ("mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE 
> >> request")
> >>   2b0f904a5a ("mm/cma: manage the memory of the CMA area by using the 
> >> ZONE_MOVABLE")
> >> 
> >> f6572f9cd248df2c 2b0f904a5a8781498417d67226 
> >>  -- 
> >>  %stddev %change %stddev
> >>  \  |\  
> >>  11451   -16.1%   9605fio.read_bw_MBps
> >>   0.29 ±  5%  +0.10.40 ±  3%  fio.latency_1000us%
> >>  19.35 ±  5%  -4.7   14.69 ±  3%  fio.latency_10ms%
> >>   7.92 ±  3% +12.2   20.15fio.latency_20ms%
> >>   0.05 ± 11%  +0.00.09 ±  8%  fio.latency_2ms%
> >>  70.22-8.9   61.36fio.latency_4ms%
> >>   0.29 ± 13%  +0.00.33 ±  3%  fio.latency_500us%
> >>   0.45 ± 29%  +1.01.45 ±  4%  fio.latency_50ms%
> >>   1.37+0.11.44fio.latency_750us%
> >>   9792   +31.7%  12896fio.read_clat_90%_us
> >>  10560   +33.0%  14048fio.read_clat_95%_us
> >>  15376 ± 10% +46.9%  22592fio.read_clat_99%_us
> >>   4885   +19.2%   5825fio.read_clat_mean_us
> >>   5725   -16.1%   4802fio.read_iops
> >>  4.598e+09   -16.4%  3.845e+09fio.time.file_system_inputs
> >> 453153-8.4% 415215
> >> fio.time.involuntary_context_switches
> >>  5.748e+08   -16.4%  4.806e+08fio.time.major_page_faults
> >>1822257   +23.7%2254706
> >> fio.time.maximum_resident_set_size
> >>   5089+1.6%   5172fio.time.system_time
> >> 514.50   -16.3% 430.48fio.time.user_time
> >
> >System time is increased and user time is decreased. On the below, there is 
> >a clue.
> >
> >>  24569 ±  2%  +9.6%  26917 ±  2%  
> >> fio.time.voluntary_context_switches
> >>   54443725   -14.9%   46353339
> >> interrupts.CAL:Function_call_interrupts
> >>   0.00 ± 79%  -0.00.00 ± 17%  mpstat.cpu.iowait%
> >>   4.45-0.73.71mpstat.cpu.usr%
> >>1467516   +21.3%1779543 ±  3%  meminfo.Active
> >>1276031   +23.7%1578443 ±  4%  meminfo.Active(file)
> >>  25789 ±  3% -76.7%   6013 ±  4%  meminfo.CmaFree
> >>  1.296e+08   -12.6%  1.133e+08turbostat.IRQ
> >>  41.89-3.4%  40.47turbostat.RAMWatt
> >>  17444 ±  2% -13.5%  15092 ±  3%  turbostat.SMI
> >>   10896428   -16.4%9111830vmstat.io.bi
> >>   6010-6.2%   5637vmstat.system.cs
> >> 317438   -12.1% 278980vmstat.system.in
> >>1072892 ±  3% +21.5%1303487numa-meminfo.node0.Active
> >> 978318   +21.6%1189809 ±  2%  
> >> numa-meminfo.node0.Active(file)
> >> 222968   -25.2% 166818

Re: [lkp-robot] [mm/cma] 2b0f904a5a: fio.read_bw_MBps -16.1% regression

[Joonsoo Kim]

On Sat, Jan 06, 2018 at 05:26:31PM +0800, Ye Xiaolong wrote:
> Hi,
> 
> On 01/03, Joonsoo Kim wrote:
> >Hello!
> >
> >On Tue, Jan 02, 2018 at 02:35:28PM +0800, kernel test robot wrote:
> >> 
> >> Greeting,
> >> 
> >> FYI, we noticed a -16.1% regression of fio.read_bw_MBps due to commit:
> >> 
> >> 
> >> commit: 2b0f904a5a8781498417d67226fd12c5e56053ae ("mm/cma: manage the 
> >> memory of the CMA area by using the ZONE_MOVABLE")
> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >> 
> >> in testcase: fio-basic
> >> on test machine: 56 threads Intel(R) Xeon(R) CPU E5-2695 v3 @ 2.30GHz with 
> >> 256G memory
> >> with following parameters:
> >> 
> >>disk: 2pmem
> >>fs: ext4
> >>runtime: 200s
> >>nr_task: 50%
> >>time_based: tb
> >>rw: randread
> >>bs: 2M
> >>ioengine: mmap
> >>test_size: 200G
> >>cpufreq_governor: performance
> >> 
> >> test-description: Fio is a tool that will spawn a number of threads or 
> >> processes doing a particular type of I/O action as specified by the user.
> >> test-url: https://github.com/axboe/fio
> >> 
> >> 
> >> 
> >> Details are as below:
> >> -->
> >> 
> >> 
> >> To reproduce:
> >> 
> >> git clone https://github.com/intel/lkp-tests.git
> >> cd lkp-tests
> >> bin/lkp install job.yaml  # job file is attached in this email
> >> bin/lkp run job.yaml
> >> 
> >> =
> >> bs/compiler/cpufreq_governor/disk/fs/ioengine/kconfig/nr_task/rootfs/runtime/rw/tbox_group/test_size/testcase/time_based:
> >>   
> >> 2M/gcc-7/performance/2pmem/ext4/mmap/x86_64-rhel-7.2/50%/debian-x86_64-2016-08-31.cgz/200s/randread/lkp-hsw-ep6/200G/fio-basic/tb
> >> 
> >> commit: 
> >>   f6572f9cd2 ("mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE 
> >> request")
> >>   2b0f904a5a ("mm/cma: manage the memory of the CMA area by using the 
> >> ZONE_MOVABLE")
> >> 
> >> f6572f9cd248df2c 2b0f904a5a8781498417d67226 
> >>  -- 
> >>  %stddev %change %stddev
> >>  \  |\  
> >>  11451   -16.1%   9605fio.read_bw_MBps
> >>   0.29 ±  5%  +0.10.40 ±  3%  fio.latency_1000us%
> >>  19.35 ±  5%  -4.7   14.69 ±  3%  fio.latency_10ms%
> >>   7.92 ±  3% +12.2   20.15fio.latency_20ms%
> >>   0.05 ± 11%  +0.00.09 ±  8%  fio.latency_2ms%
> >>  70.22-8.9   61.36fio.latency_4ms%
> >>   0.29 ± 13%  +0.00.33 ±  3%  fio.latency_500us%
> >>   0.45 ± 29%  +1.01.45 ±  4%  fio.latency_50ms%
> >>   1.37+0.11.44fio.latency_750us%
> >>   9792   +31.7%  12896fio.read_clat_90%_us
> >>  10560   +33.0%  14048fio.read_clat_95%_us
> >>  15376 ± 10% +46.9%  22592fio.read_clat_99%_us
> >>   4885   +19.2%   5825fio.read_clat_mean_us
> >>   5725   -16.1%   4802fio.read_iops
> >>  4.598e+09   -16.4%  3.845e+09fio.time.file_system_inputs
> >> 453153-8.4% 415215
> >> fio.time.involuntary_context_switches
> >>  5.748e+08   -16.4%  4.806e+08fio.time.major_page_faults
> >>1822257   +23.7%2254706
> >> fio.time.maximum_resident_set_size
> >>   5089+1.6%   5172fio.time.system_time
> >> 514.50   -16.3% 430.48fio.time.user_time
> >
> >System time is increased and user time is decreased. On the below, there is 
> >a clue.
> >
> >>  24569 ±  2%  +9.6%  26917 ±  2%  
> >> fio.time.voluntary_context_switches
> >>   54443725   -14.9%   46353339
> >> interrupts.CAL:Function_call_interrupts
> >>   0.00 ± 79%  -0.00.00 ± 17%  mpstat.cpu.iowait%
> >>   4.45-0.73.71mpstat.cpu.usr%
> >>1467516   +21.3%1779543 ±  3%  meminfo.Active
> >>1276031   +23.7%1578443 ±  4%  meminfo.Active(file)
> >>  25789 ±  3% -76.7%   6013 ±  4%  meminfo.CmaFree
> >>  1.296e+08   -12.6%  1.133e+08turbostat.IRQ
> >>  41.89-3.4%  40.47turbostat.RAMWatt
> >>  17444 ±  2% -13.5%  15092 ±  3%  turbostat.SMI
> >>   10896428   -16.4%9111830vmstat.io.bi
> >>   6010-6.2%   5637vmstat.system.cs
> >> 317438   -12.1% 278980vmstat.system.in
> >>1072892 ±  3% +21.5%1303487numa-meminfo.node0.Active
> >> 978318   +21.6%1189809 ±  2%  
> >> numa-meminfo.node0.Active(file)
> >> 222968   -25.2% 166818

Re: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

[Namhyung Kim]

Hi,

On Thu, Jan 04, 2018 at 02:00:03PM +, Liang, Kan wrote:
> > Hi Kan,
> > 
> > On Wed, Jan 03, 2018 at 02:15:38PM +, Liang, Kan wrote:
> > > > Hello,
> > > >
> > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote:
> > > > > From: Kan Liang 
> > > > >
> > > > > The direction of overwrite mode is backward. The last
> > mmap__read_event
> > > > > will set tail to map->prev. Need to correct the map->prev to head
> > > > > which is the end of next read.
> > > >
> > > > Why do you update the map->prev needlessly then?  I think we don't
> > need it
> > > > for overwrite/backward mode, right?
> > >
> > > The map->prev is needless only when the overwrite does really happen in
> > ringbuffer.
> > > In a light load system or with big ringbuffer, the unprocessed data will 
> > > not
> > be
> > > overwritten. So it's necessary to keep an pointer to indicate the last
> > position.
> > >
> > > Overwrite mode is backward, but the event processing is always forward.
> > > So map->prev has to be updated in __read_done().
> > 
> > Yep, I meant that updating map->prev in every perf_mmap__read_event()
> > is unnecessary for the overwrite mode.  It only needs to be set in
> > perf_mmap__read_done(), right?
> 
> Right, for overwrite, only updating the map->prev in perf_mmap__read_done()
> is enough.
> 
> But for non-overwrite, we have to update map->prev.
> It will be used by perf_mmap__consume() later to write the ring buffer tail.
> So I specially handle the non-overwrite as below in patch 5/12.

Oh I can see it in the patch 5, thanks.


> + event = perf_mmap__read(map, start, end);
> +
> + if (!overwrite)
> + map->prev = *start;
> 
> > >
> > > >
> > > > Also I guess the current code might miss some events since the head can
> > be
> > > > different between _read_init() and _read_done(), no?
> > > >
> > >
> > > The overwrite mode requires the ring buffer to be paused during
> > processing.
> > > The head is unchanged between __read_init() and __read_done().
> > 
> > Ah, ok then.  Maybe we could read the head once, and use it during
> > processing.
> 
> Yes, it only needs to read head once for overwrite mode.
> But for non-overwrite, we have to read the head in every
> perf_mmap__read_event(). Because the head is floating.
> The non-overwrite is specially handled in patch 5/12 as well.

Right, I understand it for the non-overwrite mode.

But, for the overwrite mode, my concern was that it might be possible
that it reads a stale head in __read_init() (even after it paused the
ring buffer) and reads an update head in __read_done().  Then it's
gonna miss some records.  I'm not sure whether it reads the same head
in __read_init() and __read_done() by the pause.

Thanks,
Namhyung


> + /* non-overwirte doesn't pause the ringbuffer */
> + if (!overwrite)
> + end = perf_mmap__read_head(map);

Re: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

[Namhyung Kim]

Hi,

On Thu, Jan 04, 2018 at 02:00:03PM +, Liang, Kan wrote:
> > Hi Kan,
> > 
> > On Wed, Jan 03, 2018 at 02:15:38PM +, Liang, Kan wrote:
> > > > Hello,
> > > >
> > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote:
> > > > > From: Kan Liang 
> > > > >
> > > > > The direction of overwrite mode is backward. The last
> > mmap__read_event
> > > > > will set tail to map->prev. Need to correct the map->prev to head
> > > > > which is the end of next read.
> > > >
> > > > Why do you update the map->prev needlessly then?  I think we don't
> > need it
> > > > for overwrite/backward mode, right?
> > >
> > > The map->prev is needless only when the overwrite does really happen in
> > ringbuffer.
> > > In a light load system or with big ringbuffer, the unprocessed data will 
> > > not
> > be
> > > overwritten. So it's necessary to keep an pointer to indicate the last
> > position.
> > >
> > > Overwrite mode is backward, but the event processing is always forward.
> > > So map->prev has to be updated in __read_done().
> > 
> > Yep, I meant that updating map->prev in every perf_mmap__read_event()
> > is unnecessary for the overwrite mode.  It only needs to be set in
> > perf_mmap__read_done(), right?
> 
> Right, for overwrite, only updating the map->prev in perf_mmap__read_done()
> is enough.
> 
> But for non-overwrite, we have to update map->prev.
> It will be used by perf_mmap__consume() later to write the ring buffer tail.
> So I specially handle the non-overwrite as below in patch 5/12.

Oh I can see it in the patch 5, thanks.


> + event = perf_mmap__read(map, start, end);
> +
> + if (!overwrite)
> + map->prev = *start;
> 
> > >
> > > >
> > > > Also I guess the current code might miss some events since the head can
> > be
> > > > different between _read_init() and _read_done(), no?
> > > >
> > >
> > > The overwrite mode requires the ring buffer to be paused during
> > processing.
> > > The head is unchanged between __read_init() and __read_done().
> > 
> > Ah, ok then.  Maybe we could read the head once, and use it during
> > processing.
> 
> Yes, it only needs to read head once for overwrite mode.
> But for non-overwrite, we have to read the head in every
> perf_mmap__read_event(). Because the head is floating.
> The non-overwrite is specially handled in patch 5/12 as well.

Right, I understand it for the non-overwrite mode.

But, for the overwrite mode, my concern was that it might be possible
that it reads a stale head in __read_init() (even after it paused the
ring buffer) and reads an update head in __read_done().  Then it's
gonna miss some records.  I'm not sure whether it reads the same head
in __read_init() and __read_done() by the pause.

Thanks,
Namhyung


> + /* non-overwirte doesn't pause the ringbuffer */
> + if (!overwrite)
> + end = perf_mmap__read_head(map);

Re: Feedback on 4.9 performance after PTI fixes

[Willy Tarreau]

Hi again,

updating the table after Yves-Alexis' comment on PCID. Rerunning the test
with -cpu=Haswell to enable PCID gave me much better numbers :

On Sun, Jan 07, 2018 at 11:18:56AM +0100, Willy Tarreau wrote:
> Hi,
> 
> I managed to take a bit of time to run some more tests on PTI both
> native and hosted in KVM, on stable versions built with
> CONFIG_PAGE_TABLE_ISOLATION=y. Here it's 4.9.75, used both on the
> host and the VM. I could compare pti=on/off both in the host and the
> VM. A single CPU was exposed in the VM.
> 
> It was running on my laptop (core i7 3320M at 2.6 GHz, 3.3 GHz single
> core turbo).
> 
> The test was run on haproxy's ability to forward connections. The
> results are below :
> 
>Host  |  Guest  | conn/s  | ratio_to_host |  ratio_to_VM | Notes
> -+-+-+---+--+
>  pti=off |   - |  27400  | 100.0%|  -   | host reference
>  pti=off | pti=off |  24200  |  88.3%|100.0%| VM reference 
>  pti=off | pti=on  |  13300  |  48.5%| 55.0%|
>  pti=on  |   - |  23800  |  86.9%|  -   | protected host
>  pti=on  | pti=off |  23100  |  84.3%| 95.5%|
>  pti=on  | pti=on  |  13300  |  48.5%| 55.0%|

New run :

Host  |  Guest  | conn/s  | ratio  | Notes
 -+-+-++
  pti=off | pti=off |  23100  | 100.0% | VM reference without PTI
  pti=off | pti=on  |  19700  |  85.2% | VM with PTI and PCID
  pti=off | pti=on  |  12700  |  55.0% | VM with PTI without PCID

So the performance cut in half was indeed caused by the lack of PCID
here. With it the impact is much less, though still important.

Willy

Re: Feedback on 4.9 performance after PTI fixes

[Willy Tarreau]

Hi again,

updating the table after Yves-Alexis' comment on PCID. Rerunning the test
with -cpu=Haswell to enable PCID gave me much better numbers :

On Sun, Jan 07, 2018 at 11:18:56AM +0100, Willy Tarreau wrote:
> Hi,
> 
> I managed to take a bit of time to run some more tests on PTI both
> native and hosted in KVM, on stable versions built with
> CONFIG_PAGE_TABLE_ISOLATION=y. Here it's 4.9.75, used both on the
> host and the VM. I could compare pti=on/off both in the host and the
> VM. A single CPU was exposed in the VM.
> 
> It was running on my laptop (core i7 3320M at 2.6 GHz, 3.3 GHz single
> core turbo).
> 
> The test was run on haproxy's ability to forward connections. The
> results are below :
> 
>Host  |  Guest  | conn/s  | ratio_to_host |  ratio_to_VM | Notes
> -+-+-+---+--+
>  pti=off |   - |  27400  | 100.0%|  -   | host reference
>  pti=off | pti=off |  24200  |  88.3%|100.0%| VM reference 
>  pti=off | pti=on  |  13300  |  48.5%| 55.0%|
>  pti=on  |   - |  23800  |  86.9%|  -   | protected host
>  pti=on  | pti=off |  23100  |  84.3%| 95.5%|
>  pti=on  | pti=on  |  13300  |  48.5%| 55.0%|

New run :

Host  |  Guest  | conn/s  | ratio  | Notes
 -+-+-++
  pti=off | pti=off |  23100  | 100.0% | VM reference without PTI
  pti=off | pti=on  |  19700  |  85.2% | VM with PTI and PCID
  pti=off | pti=on  |  12700  |  55.0% | VM with PTI without PCID

So the performance cut in half was indeed caused by the lack of PCID
here. With it the impact is much less, though still important.

Willy

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

[Hannes Reinecke]

On 01/08/2018 08:15 PM, Tejun Heo wrote:
> Currently, blk-mq protects only the issue path with RCU.  This patch
> puts the completion path under the same RCU protection.  This will be
> used to synchronize issue/completion against timeout by later patches,
> which will also add the comments.
> 
> Signed-off-by: Tejun Heo 
> ---
>  block/blk-mq.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index ddc9261..6741c3e 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -584,11 +584,16 @@ static void hctx_lock(struct blk_mq_hw_ctx *hctx, int 
> *srcu_idx)
>  void blk_mq_complete_request(struct request *rq)
>  {
>   struct request_queue *q = rq->q;
> + struct blk_mq_hw_ctx *hctx = blk_mq_map_queue(q, rq->mq_ctx->cpu);
> + int srcu_idx;
>  
>   if (unlikely(blk_should_fake_timeout(q)))
>   return;
> +
> + hctx_lock(hctx, _idx);
>   if (!blk_mark_rq_complete(rq))
>   __blk_mq_complete_request(rq);
> + hctx_unlock(hctx, srcu_idx);
>  }
>  EXPORT_SYMBOL(blk_mq_complete_request);
>  
> 
Hmm. Why do we need to call blk_mq_map_queue() here?
Is there a chance that we end up with a _different_ hctx on completion
than that one used for submission?
If not, why can't we just keep a pointer to the hctx in struct request?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 2/8] blk-mq: protect completion path with RCU

[Hannes Reinecke]

On 01/08/2018 08:15 PM, Tejun Heo wrote:
> Currently, blk-mq protects only the issue path with RCU.  This patch
> puts the completion path under the same RCU protection.  This will be
> used to synchronize issue/completion against timeout by later patches,
> which will also add the comments.
> 
> Signed-off-by: Tejun Heo 
> ---
>  block/blk-mq.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index ddc9261..6741c3e 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -584,11 +584,16 @@ static void hctx_lock(struct blk_mq_hw_ctx *hctx, int 
> *srcu_idx)
>  void blk_mq_complete_request(struct request *rq)
>  {
>   struct request_queue *q = rq->q;
> + struct blk_mq_hw_ctx *hctx = blk_mq_map_queue(q, rq->mq_ctx->cpu);
> + int srcu_idx;
>  
>   if (unlikely(blk_should_fake_timeout(q)))
>   return;
> +
> + hctx_lock(hctx, _idx);
>   if (!blk_mark_rq_complete(rq))
>   __blk_mq_complete_request(rq);
> + hctx_unlock(hctx, srcu_idx);
>  }
>  EXPORT_SYMBOL(blk_mq_complete_request);
>  
> 
Hmm. Why do we need to call blk_mq_map_queue() here?
Is there a chance that we end up with a _different_ hctx on completion
than that one used for submission?
If not, why can't we just keep a pointer to the hctx in struct request?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 07/11] powerpc/64s: Add support for RFI flush of L1-D cache

[Joel Stanley]

On Mon, Jan 8, 2018 at 8:54 AM, Michael Ellerman  wrote:
> On some CPUs we can prevent the Meltdown vulnerability by flushing the
> L1-D cache on exit from kernel to user mode, and from hypervisor to
> guest.

Super minor nitpicks below. Don't let this hold up your work.

> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -1449,6 +1449,88 @@ masked_##_H##interrupt:
>   \
> b   .;  \
> MASKED_DEC_HANDLER(_H)
>
> +TRAMP_REAL_BEGIN(rfi_flush_fallback)
> +   SET_SCRATCH0(r13);
> +   GET_PACA(r13);
> +   std r9,PACA_EXRFI+EX_R9(r13)
> +   std r10,PACA_EXRFI+EX_R10(r13)
> +   std r11,PACA_EXRFI+EX_R11(r13)
> +   std r12,PACA_EXRFI+EX_R12(r13)
> +   std r8,PACA_EXRFI+EX_R13(r13)
> +   mfctr   r9
> +   ld  r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
> +   ld  r11,PACA_L1D_FLUSH_SETS(r13)
> +   ld  r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
> +   /*
> +* The load adresses are at staggered offsets within cachelines,
> +* which suits some pipelines better (on others it should not
> +* hurt.

Nit: missing ) on the last line.

> +*/
> +   addir12,r12,8
> +   mtctr   r11
> +   DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
> +

> --- a/arch/powerpc/lib/feature-fixups.c
> +++ b/arch/powerpc/lib/feature-fixups.c
> @@ -116,6 +116,47 @@ void do_feature_fixups(unsigned long value, void 
> *fixup_start, void *fixup_end)
> }
>  }
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +void do_rfi_flush_fixups(enum l1d_flush_type types)
> +{
> +   unsigned int instrs[3], *dest;
> +   long *start, *end;
> +   int i;
> +
> +   start = PTRRELOC(&__start___rfi_flush_fixup),
> +   end = PTRRELOC(&__stop___rfi_flush_fixup);
> +
> +   instrs[0] = 0x6000; /* nop */
> +   instrs[1] = 0x6000; /* nop */
> +   instrs[2] = 0x6000; /* nop */
> +
> +   if (types & L1D_FLUSH_FALLBACK)

This looked a bit confusing on first read. Do we ever get
L1D_FLUSH_FALLBACK and the other types? If not, could it be made
clearer?

  if ( types & L1D_FLUSH_FALLBACK)
  /* stuff */
  else
/* other types */


> +   /* b .+16 to fallback flush */
> +   instrs[0] = 0x4810;
> +
> +   i = 0;
> +   if (types & L1D_FLUSH_ORI) {
> +   instrs[i++] = 0x63ff; /* ori 31,31,0 speculation barrier 
> */
> +   instrs[i++] = 0x63de; /* ori 30,30,0 L1d flush*/
> +   }
> +
> +   if (types & L1D_FLUSH_MTTRIG)
> +   instrs[i++] = 0x7c12dba6; /* mtspr TRIG2,r0 (SPR #882) */
> +
> +   for (i = 0; start < end; start++, i++) {
> +   dest = (void *)start + *start;
> +
> +   pr_devel("patching dest %lx\n", (unsigned long)dest);
> +
> +   patch_instruction(dest, instrs[0]);
> +   patch_instruction(dest + 1, instrs[1]);
> +   patch_instruction(dest + 2, instrs[2]);
> +   }
> +
> +   printk(KERN_DEBUG "rfi-flush: patched %d locations\n", i);
> +}
> +#endif /* CONFIG_PPC_BOOK3S_64 */
> +
>  void do_lwsync_fixups(unsigned long value, void *fixup_start, void 
> *fixup_end)
>  {
> long *start, *end;
> --
> 2.14.3
>

Re: [PATCH 07/11] powerpc/64s: Add support for RFI flush of L1-D cache

[Joel Stanley]

On Mon, Jan 8, 2018 at 8:54 AM, Michael Ellerman  wrote:
> On some CPUs we can prevent the Meltdown vulnerability by flushing the
> L1-D cache on exit from kernel to user mode, and from hypervisor to
> guest.

Super minor nitpicks below. Don't let this hold up your work.

> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -1449,6 +1449,88 @@ masked_##_H##interrupt:
>   \
> b   .;  \
> MASKED_DEC_HANDLER(_H)
>
> +TRAMP_REAL_BEGIN(rfi_flush_fallback)
> +   SET_SCRATCH0(r13);
> +   GET_PACA(r13);
> +   std r9,PACA_EXRFI+EX_R9(r13)
> +   std r10,PACA_EXRFI+EX_R10(r13)
> +   std r11,PACA_EXRFI+EX_R11(r13)
> +   std r12,PACA_EXRFI+EX_R12(r13)
> +   std r8,PACA_EXRFI+EX_R13(r13)
> +   mfctr   r9
> +   ld  r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
> +   ld  r11,PACA_L1D_FLUSH_SETS(r13)
> +   ld  r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
> +   /*
> +* The load adresses are at staggered offsets within cachelines,
> +* which suits some pipelines better (on others it should not
> +* hurt.

Nit: missing ) on the last line.

> +*/
> +   addir12,r12,8
> +   mtctr   r11
> +   DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
> +

> --- a/arch/powerpc/lib/feature-fixups.c
> +++ b/arch/powerpc/lib/feature-fixups.c
> @@ -116,6 +116,47 @@ void do_feature_fixups(unsigned long value, void 
> *fixup_start, void *fixup_end)
> }
>  }
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +void do_rfi_flush_fixups(enum l1d_flush_type types)
> +{
> +   unsigned int instrs[3], *dest;
> +   long *start, *end;
> +   int i;
> +
> +   start = PTRRELOC(&__start___rfi_flush_fixup),
> +   end = PTRRELOC(&__stop___rfi_flush_fixup);
> +
> +   instrs[0] = 0x6000; /* nop */
> +   instrs[1] = 0x6000; /* nop */
> +   instrs[2] = 0x6000; /* nop */
> +
> +   if (types & L1D_FLUSH_FALLBACK)

This looked a bit confusing on first read. Do we ever get
L1D_FLUSH_FALLBACK and the other types? If not, could it be made
clearer?

  if ( types & L1D_FLUSH_FALLBACK)
  /* stuff */
  else
/* other types */


> +   /* b .+16 to fallback flush */
> +   instrs[0] = 0x4810;
> +
> +   i = 0;
> +   if (types & L1D_FLUSH_ORI) {
> +   instrs[i++] = 0x63ff; /* ori 31,31,0 speculation barrier 
> */
> +   instrs[i++] = 0x63de; /* ori 30,30,0 L1d flush*/
> +   }
> +
> +   if (types & L1D_FLUSH_MTTRIG)
> +   instrs[i++] = 0x7c12dba6; /* mtspr TRIG2,r0 (SPR #882) */
> +
> +   for (i = 0; start < end; start++, i++) {
> +   dest = (void *)start + *start;
> +
> +   pr_devel("patching dest %lx\n", (unsigned long)dest);
> +
> +   patch_instruction(dest, instrs[0]);
> +   patch_instruction(dest + 1, instrs[1]);
> +   patch_instruction(dest + 2, instrs[2]);
> +   }
> +
> +   printk(KERN_DEBUG "rfi-flush: patched %d locations\n", i);
> +}
> +#endif /* CONFIG_PPC_BOOK3S_64 */
> +
>  void do_lwsync_fixups(unsigned long value, void *fixup_start, void 
> *fixup_end)
>  {
> long *start, *end;
> --
> 2.14.3
>

[PATCH] usb: f_fs: Prevent gadget unbind if it is already unbound

[Amit Pundir]

From: Hemant Kumar 

Upon usb composition switch there is possibility of ep0 file
release happening after gadget driver bind. In case of composition
switch from adb to a non-adb composition gadget will never gets
bound again resulting into failure of usb device enumeration. Fix
this issue by checking FFS_FL_BOUND flag and avoid extra
gadget driver unbind if it is already done as part of composition
switch.

This fixes adb reconnection error reported on Android running
v4.4 and above kernel versions. Verified on Hikey running vanilla
v4.15-rc7 + few out of tree Mali patches.

Reviewed-at: https://android-review.googlesource.com/#/c/582632/

Cc: Felipe Balbi 
Cc: Greg KH 
Cc: Michal Nazarewicz 
Cc: John Stultz 
Cc: Dmitry Shmidt 
Cc: Badhri 
Cc: Android Kernel Team 
Cc: sta...@vger.kernel.org
Signed-off-by: Hemant Kumar 
[AmitP: Cherry-picked it from android-4.14 and updated the commit log]
Signed-off-by: Amit Pundir 
---
 drivers/usb/gadget/function/f_fs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index b6cf5ab5a0a1..f9bd351637cd 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3700,7 +3700,8 @@ static void ffs_closed(struct ffs_data *ffs)
ci = opts->func_inst.group.cg_item.ci_parent->ci_parent;
ffs_dev_unlock();
 
-   unregister_gadget_item(ci);
+   if (test_bit(FFS_FL_BOUND, >flags))
+   unregister_gadget_item(ci);
return;
 done:
ffs_dev_unlock();
-- 
2.7.4

[PATCH] usb: f_fs: Prevent gadget unbind if it is already unbound

[Amit Pundir]

From: Hemant Kumar 

Upon usb composition switch there is possibility of ep0 file
release happening after gadget driver bind. In case of composition
switch from adb to a non-adb composition gadget will never gets
bound again resulting into failure of usb device enumeration. Fix
this issue by checking FFS_FL_BOUND flag and avoid extra
gadget driver unbind if it is already done as part of composition
switch.

This fixes adb reconnection error reported on Android running
v4.4 and above kernel versions. Verified on Hikey running vanilla
v4.15-rc7 + few out of tree Mali patches.

Reviewed-at: https://android-review.googlesource.com/#/c/582632/

Cc: Felipe Balbi 
Cc: Greg KH 
Cc: Michal Nazarewicz 
Cc: John Stultz 
Cc: Dmitry Shmidt 
Cc: Badhri 
Cc: Android Kernel Team 
Cc: sta...@vger.kernel.org
Signed-off-by: Hemant Kumar 
[AmitP: Cherry-picked it from android-4.14 and updated the commit log]
Signed-off-by: Amit Pundir 
---
 drivers/usb/gadget/function/f_fs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index b6cf5ab5a0a1..f9bd351637cd 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3700,7 +3700,8 @@ static void ffs_closed(struct ffs_data *ffs)
ci = opts->func_inst.group.cg_item.ci_parent->ci_parent;
ffs_dev_unlock();
 
-   unregister_gadget_item(ci);
+   if (test_bit(FFS_FL_BOUND, >flags))
+   unregister_gadget_item(ci);
return;
 done:
ffs_dev_unlock();
-- 
2.7.4

[PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

[Christophe Leroy]

Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst()
clobber memory, tell it what it clobbers:
* dcbz(), dcbi() and dcbf() clobbers one cacheline as output
* dcbf() and dcbst() clobbers one cacheline as input

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/cache.h | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index c1d257aa4c2d..fc8fe18acf8c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -82,22 +82,31 @@ extern void _set_L3CR(unsigned long);
 
 static inline void dcbz(void *addr)
 {
-   __asm__ __volatile__ ("dcbz 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbz 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
 }
 
 static inline void dcbi(void *addr)
 {
-   __asm__ __volatile__ ("dcbi 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbi 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
 }
 
 static inline void dcbf(void *addr)
 {
-   __asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbf 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+);
 }
 
 static inline void dcbst(void *addr)
 {
-   __asm__ __volatile__ ("dcbst 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbst 0, %0" : :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+);
 }
 #endif /* !__ASSEMBLY__ */
 #endif /* __KERNEL__ */
-- 
2.13.3

[PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

[Christophe Leroy]

Instead of just telling GCC that dcbz(), dcbi(), dcbf() and dcbst()
clobber memory, tell it what it clobbers:
* dcbz(), dcbi() and dcbf() clobbers one cacheline as output
* dcbf() and dcbst() clobbers one cacheline as input

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/cache.h | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index c1d257aa4c2d..fc8fe18acf8c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -82,22 +82,31 @@ extern void _set_L3CR(unsigned long);
 
 static inline void dcbz(void *addr)
 {
-   __asm__ __volatile__ ("dcbz 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbz 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
 }
 
 static inline void dcbi(void *addr)
 {
-   __asm__ __volatile__ ("dcbi 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbi 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr) :);
 }
 
 static inline void dcbf(void *addr)
 {
-   __asm__ __volatile__ ("dcbf 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbf 0, %1" :
+ "=m"(*(char (*)[L1_CACHE_BYTES])addr) :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+);
 }
 
 static inline void dcbst(void *addr)
 {
-   __asm__ __volatile__ ("dcbst 0, %0" : : "r"(addr) : "memory");
+   __asm__ __volatile__ ("dcbst 0, %0" : :
+ "r"(addr), "m"(*(char (*)[L1_CACHE_BYTES])addr) :
+);
 }
 #endif /* !__ASSEMBLY__ */
 #endif /* __KERNEL__ */
-- 
2.13.3

Re: Applied "ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update" to the asoc tree

[Takashi Sakamoto]

Hi Jiada,

On Jan 9 2018 14:42, Jiada Wang wrote:

Only the first patch in
https://www.spinics.net/lists/alsa-devel/msg71021.html
was applied, but the second patch "ASoC: rsnd: ssi: remove unnesessary 
period_pos"

was missed

Could you please have a look


I can see all of them were applied to Mark's for-next branch[1].

 - 33f801366bdf ('ASoC: rsnd: ssi: fix race condition in 
rsnd_ssi_pointer_update')[2]

 - 2e2d53da81af ('ASoC: rsnd: ssi: remove unnesessary period_pos')[3]

No worries to us.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/log/?h=for-next
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/sh?h=for-next=33f801366bdf3f8b67dfe325b84f4051a090d01e
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/sh?h=for-next=2e2d53da81af6bc6b4e025a5d01b37b4449b



Regards

Takashi Sakamoto

Re: Applied "ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update" to the asoc tree

[Takashi Sakamoto]

Hi Jiada,

On Jan 9 2018 14:42, Jiada Wang wrote:

Only the first patch in
https://www.spinics.net/lists/alsa-devel/msg71021.html
was applied, but the second patch "ASoC: rsnd: ssi: remove unnesessary 
period_pos"

was missed

Could you please have a look


I can see all of them were applied to Mark's for-next branch[1].

 - 33f801366bdf ('ASoC: rsnd: ssi: fix race condition in 
rsnd_ssi_pointer_update')[2]

 - 2e2d53da81af ('ASoC: rsnd: ssi: remove unnesessary period_pos')[3]

No worries to us.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/log/?h=for-next
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/sh?h=for-next=33f801366bdf3f8b67dfe325b84f4051a090d01e
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/sound/soc/sh?h=for-next=2e2d53da81af6bc6b4e025a5d01b37b4449b



Regards

Takashi Sakamoto

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

[Namhyung Kim]

Hi,

On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote:
> On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote:
> > Hi Olsa,
> > What about this fix now? Thanks!
> > 
> > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> > > From: Changbin Du 
> > > 
> > > The terminal character '\0' should take into account as size of the string
> > > buffer. Without this fix, the '--graph-funcs', '--nograph-funcs' and
> > > '--trace-funcs' options didn't work as expected when the  doesn't
> > > exist.
> > > 
> > > I didn't dive into kernel ftrace fops, but strace shows that if usersapce
> > > writes a non-terminated string, the kernel side will return success but
> > > no filter applied. After this fix in userspace, the kernel will return an
> > > error.
> > > 
> > > $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg
> > >  0)   0.140 us|  rcu_all_qs();
> > >  3)   0.304 us|  mutex_unlock();
> > >  0)   0.153 us|  find_vma();
> > >  3)   0.088 us|  __fsnotify_parent();
> > >  0)   6.145 us|  handle_mm_fault();
> > >  3)   0.089 us|  fsnotify();
> > >  3)   0.161 us|  __sb_end_write();
> > >  3)   0.710 us|  SyS_close();
> > >  3)   7.848 us|  exit_to_usermode_loop();
> > > 
> > > On above example, I specified function filter 'abcdefg' but all functions
> > > are enabled.
> 
> hum, haven't checked, but looks like the filter is not working at all now:
> 
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs 
> proc_sys_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs SyS_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs fsnotify
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument

Hmm.. it seems writing a whitespace alone caused the failure.

The filter files are handled little bit different in that they process
the given string when it find a whitespace or at the close() if not.
But the thing is that it's gonna lose the return value if handled at
close().

Anyway adding a NUL character at the end won't make different IMHO
since it's not a whitespace.  And I think it needs a separate function
to set filters with a whitespace.  But this will change the program
behavior on invalid filter inputs.

Thanks,
Namhyung

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

[Namhyung Kim]

Hi,

On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote:
> On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote:
> > Hi Olsa,
> > What about this fix now? Thanks!
> > 
> > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> > > From: Changbin Du 
> > > 
> > > The terminal character '\0' should take into account as size of the string
> > > buffer. Without this fix, the '--graph-funcs', '--nograph-funcs' and
> > > '--trace-funcs' options didn't work as expected when the  doesn't
> > > exist.
> > > 
> > > I didn't dive into kernel ftrace fops, but strace shows that if usersapce
> > > writes a non-terminated string, the kernel side will return success but
> > > no filter applied. After this fix in userspace, the kernel will return an
> > > error.
> > > 
> > > $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg
> > >  0)   0.140 us|  rcu_all_qs();
> > >  3)   0.304 us|  mutex_unlock();
> > >  0)   0.153 us|  find_vma();
> > >  3)   0.088 us|  __fsnotify_parent();
> > >  0)   6.145 us|  handle_mm_fault();
> > >  3)   0.089 us|  fsnotify();
> > >  3)   0.161 us|  __sb_end_write();
> > >  3)   0.710 us|  SyS_close();
> > >  3)   7.848 us|  exit_to_usermode_loop();
> > > 
> > > On above example, I specified function filter 'abcdefg' but all functions
> > > are enabled.
> 
> hum, haven't checked, but looks like the filter is not working at all now:
> 
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs 
> proc_sys_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs SyS_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs fsnotify
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument

Hmm.. it seems writing a whitespace alone caused the failure.

The filter files are handled little bit different in that they process
the given string when it find a whitespace or at the close() if not.
But the thing is that it's gonna lose the return value if handled at
close().

Anyway adding a NUL character at the end won't make different IMHO
since it's not a whitespace.  And I think it needs a separate function
to set filters with a whitespace.  But this will change the program
behavior on invalid filter inputs.

Thanks,
Namhyung

[PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

[Mike Rapoport]

Hi,

This patches introduces new process_vmsplice system call that combines
functionality of process_vm_read and vmsplice.

It allows to map the memory of another process into a pipe, similarly to
what vmsplice does for its own address space.

The patch 2/4 ("vm: add a syscall to map a process memory into a pipe")
actually adds the new system call and provides its elaborate description.

The patchset is against -mm tree.

v5: update changelog with more elaborate usecase description
v4: skip test when process_vmsplice syscall is not available
v3: minor refactoring to reduce code duplication
v2: move this syscall under CONFIG_CROSS_MEMORY_ATTACH
give correct flags to get_user_pages_remote()


Andrei Vagin (3):
  vm: add a syscall to map a process memory into a pipe
  x86: wire up the process_vmsplice syscall
  test: add a test for the process_vmsplice syscall

Mike Rapoport (1):
  fs/splice: introduce pages_to_pipe helper

 arch/x86/entry/syscalls/syscall_32.tbl |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl |   2 +
 fs/splice.c| 262 +++--
 include/linux/compat.h |   3 +
 include/linux/syscalls.h   |   4 +
 include/uapi/asm-generic/unistd.h  |   5 +-
 kernel/sys_ni.c|   2 +
 tools/testing/selftests/process_vmsplice/Makefile  |   5 +
 .../process_vmsplice/process_vmsplice_test.c   | 196 +++
 9 files changed, 458 insertions(+), 22 deletions(-)
 create mode 100644 tools/testing/selftests/process_vmsplice/Makefile
 create mode 100644 
tools/testing/selftests/process_vmsplice/process_vmsplice_test.c

-- 
2.7.4

[PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

[Mike Rapoport]

Hi,

This patches introduces new process_vmsplice system call that combines
functionality of process_vm_read and vmsplice.

It allows to map the memory of another process into a pipe, similarly to
what vmsplice does for its own address space.

The patch 2/4 ("vm: add a syscall to map a process memory into a pipe")
actually adds the new system call and provides its elaborate description.

The patchset is against -mm tree.

v5: update changelog with more elaborate usecase description
v4: skip test when process_vmsplice syscall is not available
v3: minor refactoring to reduce code duplication
v2: move this syscall under CONFIG_CROSS_MEMORY_ATTACH
give correct flags to get_user_pages_remote()


Andrei Vagin (3):
  vm: add a syscall to map a process memory into a pipe
  x86: wire up the process_vmsplice syscall
  test: add a test for the process_vmsplice syscall

Mike Rapoport (1):
  fs/splice: introduce pages_to_pipe helper

 arch/x86/entry/syscalls/syscall_32.tbl |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl |   2 +
 fs/splice.c| 262 +++--
 include/linux/compat.h |   3 +
 include/linux/syscalls.h   |   4 +
 include/uapi/asm-generic/unistd.h  |   5 +-
 kernel/sys_ni.c|   2 +
 tools/testing/selftests/process_vmsplice/Makefile  |   5 +
 .../process_vmsplice/process_vmsplice_test.c   | 196 +++
 9 files changed, 458 insertions(+), 22 deletions(-)
 create mode 100644 tools/testing/selftests/process_vmsplice/Makefile
 create mode 100644 
tools/testing/selftests/process_vmsplice/process_vmsplice_test.c

-- 
2.7.4

[PATCH v5 4/4] test: add a test for the process_vmsplice syscall

[Mike Rapoport]

From: Andrei Vagin 

This test checks that process_vmsplice() can splice pages from a remote
process and returns EFAULT, if process_vmsplice() tries to splice pages
by an unaccessiable address.

Signed-off-by: Andrei Vagin 
Signed-off-by: Mike Rapoport 
---
 tools/testing/selftests/process_vmsplice/Makefile  |   5 +
 .../process_vmsplice/process_vmsplice_test.c   | 196 +
 2 files changed, 201 insertions(+)
 create mode 100644 tools/testing/selftests/process_vmsplice/Makefile
 create mode 100644 
tools/testing/selftests/process_vmsplice/process_vmsplice_test.c

diff --git a/tools/testing/selftests/process_vmsplice/Makefile 
b/tools/testing/selftests/process_vmsplice/Makefile
new file mode 100644
index ..246d5a7dfed6
--- /dev/null
+++ b/tools/testing/selftests/process_vmsplice/Makefile
@@ -0,0 +1,5 @@
+CFLAGS += -I../../../../usr/include/
+
+TEST_GEN_PROGS := process_vmsplice_test
+
+include ../lib.mk
diff --git a/tools/testing/selftests/process_vmsplice/process_vmsplice_test.c 
b/tools/testing/selftests/process_vmsplice/process_vmsplice_test.c
new file mode 100644
index ..1682bdb32de3
--- /dev/null
+++ b/tools/testing/selftests/process_vmsplice/process_vmsplice_test.c
@@ -0,0 +1,196 @@
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../kselftest.h"
+
+#ifndef __NR_process_vmsplice
+#define __NR_process_vmsplice 333
+#endif
+
+#define pr_err(fmt, ...) \
+   ({ \
+   fprintf(stderr, "%s:%d:" fmt, \
+   __func__, __LINE__, ##__VA_ARGS__); \
+   KSFT_FAIL; \
+   })
+#define pr_perror(fmt, ...) pr_err(fmt ": %m\n", ##__VA_ARGS__)
+#define fail(fmt, ...) pr_err("FAIL:" fmt, ##__VA_ARGS__)
+
+static ssize_t process_vmsplice(pid_t pid, int fd, const struct iovec *iov,
+   unsigned long nr_segs, unsigned int flags)
+{
+   return syscall(__NR_process_vmsplice, pid, fd, iov, nr_segs, flags);
+
+}
+
+#define MEM_SIZE (4096 * 100)
+#define MEM_WRONLY_SIZE (4096 * 10)
+
+int main(int argc, char **argv)
+{
+   char *addr, *addr_wronly;
+   int p[2];
+   struct iovec iov[2];
+   char buf[4096];
+   int status, ret;
+   pid_t pid;
+
+   ksft_print_header();
+
+   if (process_vmsplice(0, 0, 0, 0, 0)) {
+   if (errno == ENOSYS) {
+   ksft_exit_skip("process_vmsplice is not supported\n");
+   return 0;
+   }
+   return pr_perror("Zero-length process_vmsplice failed");
+   }
+
+   addr = mmap(0, MEM_SIZE, PROT_READ | PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+   if (addr == MAP_FAILED)
+   return pr_perror("Unable to create a mapping");
+
+   addr_wronly = mmap(0, MEM_WRONLY_SIZE, PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+   if (addr_wronly == MAP_FAILED)
+   return pr_perror("Unable to create a write-only mapping");
+
+   if (pipe(p))
+   return pr_perror("Unable to create a pipe");
+
+   pid = fork();
+   if (pid < 0)
+   return pr_perror("Unable to fork");
+
+   if (pid == 0) {
+   addr[0] = 'C';
+   addr[4096 + 128] = 'A';
+   addr[4096 + 128 + 4096 - 1] = 'B';
+
+   if (prctl(PR_SET_PDEATHSIG, SIGKILL))
+   return pr_perror("Unable to set PR_SET_PDEATHSIG");
+   if (write(p[1], "c", 1) != 1)
+   return pr_perror("Unable to write data into pipe");
+
+   while (1)
+   sleep(1);
+   return 1;
+   }
+   if (read(p[0], buf, 1) != 1) {
+   pr_perror("Unable to read data from pipe");
+   kill(pid, SIGKILL);
+   wait();
+   return 1;
+   }
+
+   munmap(addr, MEM_SIZE);
+   munmap(addr_wronly, MEM_WRONLY_SIZE);
+
+   iov[0].iov_base = addr;
+   iov[0].iov_len = 1;
+
+   iov[1].iov_base = addr + 4096 + 128;
+   iov[1].iov_len = 4096;
+
+   /* check one iovec */
+   if (process_vmsplice(pid, p[1], iov, 1, SPLICE_F_GIFT) != 1)
+   return pr_perror("Unable to splice pages");
+
+   if (read(p[0], buf, 1) != 1)
+   return pr_perror("Unable to read from pipe");
+
+   if (buf[0] != 'C')
+   ksft_test_result_fail("Get wrong data\n");
+   else
+   ksft_test_result_pass("Check process_vmsplice with one vec\n");
+
+   /* check two iovec-s */
+   if (process_vmsplice(pid, p[1], iov, 2, SPLICE_F_GIFT) != 4097)
+   return pr_perror("Unable to spice pages\n");
+
+   if (read(p[0], buf, 1) != 1)
+   return pr_perror("Unable to read 

[PATCH v5 4/4] test: add a test for the process_vmsplice syscall

[Mike Rapoport]

From: Andrei Vagin 

This test checks that process_vmsplice() can splice pages from a remote
process and returns EFAULT, if process_vmsplice() tries to splice pages
by an unaccessiable address.

Signed-off-by: Andrei Vagin 
Signed-off-by: Mike Rapoport 
---
 tools/testing/selftests/process_vmsplice/Makefile  |   5 +
 .../process_vmsplice/process_vmsplice_test.c   | 196 +
 2 files changed, 201 insertions(+)
 create mode 100644 tools/testing/selftests/process_vmsplice/Makefile
 create mode 100644 
tools/testing/selftests/process_vmsplice/process_vmsplice_test.c

diff --git a/tools/testing/selftests/process_vmsplice/Makefile 
b/tools/testing/selftests/process_vmsplice/Makefile
new file mode 100644
index ..246d5a7dfed6
--- /dev/null
+++ b/tools/testing/selftests/process_vmsplice/Makefile
@@ -0,0 +1,5 @@
+CFLAGS += -I../../../../usr/include/
+
+TEST_GEN_PROGS := process_vmsplice_test
+
+include ../lib.mk
diff --git a/tools/testing/selftests/process_vmsplice/process_vmsplice_test.c 
b/tools/testing/selftests/process_vmsplice/process_vmsplice_test.c
new file mode 100644
index ..1682bdb32de3
--- /dev/null
+++ b/tools/testing/selftests/process_vmsplice/process_vmsplice_test.c
@@ -0,0 +1,196 @@
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../kselftest.h"
+
+#ifndef __NR_process_vmsplice
+#define __NR_process_vmsplice 333
+#endif
+
+#define pr_err(fmt, ...) \
+   ({ \
+   fprintf(stderr, "%s:%d:" fmt, \
+   __func__, __LINE__, ##__VA_ARGS__); \
+   KSFT_FAIL; \
+   })
+#define pr_perror(fmt, ...) pr_err(fmt ": %m\n", ##__VA_ARGS__)
+#define fail(fmt, ...) pr_err("FAIL:" fmt, ##__VA_ARGS__)
+
+static ssize_t process_vmsplice(pid_t pid, int fd, const struct iovec *iov,
+   unsigned long nr_segs, unsigned int flags)
+{
+   return syscall(__NR_process_vmsplice, pid, fd, iov, nr_segs, flags);
+
+}
+
+#define MEM_SIZE (4096 * 100)
+#define MEM_WRONLY_SIZE (4096 * 10)
+
+int main(int argc, char **argv)
+{
+   char *addr, *addr_wronly;
+   int p[2];
+   struct iovec iov[2];
+   char buf[4096];
+   int status, ret;
+   pid_t pid;
+
+   ksft_print_header();
+
+   if (process_vmsplice(0, 0, 0, 0, 0)) {
+   if (errno == ENOSYS) {
+   ksft_exit_skip("process_vmsplice is not supported\n");
+   return 0;
+   }
+   return pr_perror("Zero-length process_vmsplice failed");
+   }
+
+   addr = mmap(0, MEM_SIZE, PROT_READ | PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+   if (addr == MAP_FAILED)
+   return pr_perror("Unable to create a mapping");
+
+   addr_wronly = mmap(0, MEM_WRONLY_SIZE, PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+   if (addr_wronly == MAP_FAILED)
+   return pr_perror("Unable to create a write-only mapping");
+
+   if (pipe(p))
+   return pr_perror("Unable to create a pipe");
+
+   pid = fork();
+   if (pid < 0)
+   return pr_perror("Unable to fork");
+
+   if (pid == 0) {
+   addr[0] = 'C';
+   addr[4096 + 128] = 'A';
+   addr[4096 + 128 + 4096 - 1] = 'B';
+
+   if (prctl(PR_SET_PDEATHSIG, SIGKILL))
+   return pr_perror("Unable to set PR_SET_PDEATHSIG");
+   if (write(p[1], "c", 1) != 1)
+   return pr_perror("Unable to write data into pipe");
+
+   while (1)
+   sleep(1);
+   return 1;
+   }
+   if (read(p[0], buf, 1) != 1) {
+   pr_perror("Unable to read data from pipe");
+   kill(pid, SIGKILL);
+   wait();
+   return 1;
+   }
+
+   munmap(addr, MEM_SIZE);
+   munmap(addr_wronly, MEM_WRONLY_SIZE);
+
+   iov[0].iov_base = addr;
+   iov[0].iov_len = 1;
+
+   iov[1].iov_base = addr + 4096 + 128;
+   iov[1].iov_len = 4096;
+
+   /* check one iovec */
+   if (process_vmsplice(pid, p[1], iov, 1, SPLICE_F_GIFT) != 1)
+   return pr_perror("Unable to splice pages");
+
+   if (read(p[0], buf, 1) != 1)
+   return pr_perror("Unable to read from pipe");
+
+   if (buf[0] != 'C')
+   ksft_test_result_fail("Get wrong data\n");
+   else
+   ksft_test_result_pass("Check process_vmsplice with one vec\n");
+
+   /* check two iovec-s */
+   if (process_vmsplice(pid, p[1], iov, 2, SPLICE_F_GIFT) != 4097)
+   return pr_perror("Unable to spice pages\n");
+
+   if (read(p[0], buf, 1) != 1)
+   return pr_perror("Unable to read from pipe\n");
+
+   if (buf[0] != 'C')
+   

[PATCH v5 1/4] fs/splice: introduce pages_to_pipe helper

[Mike Rapoport]

Signed-off-by: Mike Rapoport 
---
 fs/splice.c | 57 -
 1 file changed, 36 insertions(+), 21 deletions(-)

diff --git a/fs/splice.c b/fs/splice.c
index 39e2dc01ac12..7f1ffc50ff1d 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1185,6 +1185,36 @@ static long do_splice(struct file *in, loff_t __user 
*off_in,
return -EINVAL;
 }
 
+static int pages_to_pipe(struct page **pages, struct pipe_inode_info *pipe,
+struct pipe_buffer *buf, size_t *total,
+ssize_t copied, size_t start)
+{
+   bool failed = false;
+   size_t len = 0;
+   int ret = 0;
+   int n;
+
+   for (n = 0; copied; n++, start = 0) {
+   int size = min_t(int, copied, PAGE_SIZE - start);
+   if (!failed) {
+   buf->page = pages[n];
+   buf->offset = start;
+   buf->len = size;
+   ret = add_to_pipe(pipe, buf);
+   if (unlikely(ret < 0))
+   failed = true;
+   else
+   len += ret;
+   } else {
+   put_page(pages[n]);
+   }
+   copied -= size;
+   }
+
+   *total += len;
+   return failed ? ret : len;
+}
+
 static int iter_to_pipe(struct iov_iter *from,
struct pipe_inode_info *pipe,
unsigned flags)
@@ -1195,13 +1225,11 @@ static int iter_to_pipe(struct iov_iter *from,
};
size_t total = 0;
int ret = 0;
-   bool failed = false;
 
-   while (iov_iter_count(from) && !failed) {
+   while (iov_iter_count(from)) {
struct page *pages[16];
ssize_t copied;
size_t start;
-   int n;
 
copied = iov_iter_get_pages(from, pages, ~0UL, 16, );
if (copied <= 0) {
@@ -1209,24 +1237,11 @@ static int iter_to_pipe(struct iov_iter *from,
break;
}
 
-   for (n = 0; copied; n++, start = 0) {
-   int size = min_t(int, copied, PAGE_SIZE - start);
-   if (!failed) {
-   buf.page = pages[n];
-   buf.offset = start;
-   buf.len = size;
-   ret = add_to_pipe(pipe, );
-   if (unlikely(ret < 0)) {
-   failed = true;
-   } else {
-   iov_iter_advance(from, ret);
-   total += ret;
-   }
-   } else {
-   put_page(pages[n]);
-   }
-   copied -= size;
-   }
+   ret = pages_to_pipe(pages, pipe, , , copied, start);
+   if (unlikely(ret < 0))
+   break;
+
+   iov_iter_advance(from, ret);
}
return total ? total : ret;
 }
-- 
2.7.4

[PATCH v5 1/4] fs/splice: introduce pages_to_pipe helper

[Mike Rapoport]

Signed-off-by: Mike Rapoport 
---
 fs/splice.c | 57 -
 1 file changed, 36 insertions(+), 21 deletions(-)

diff --git a/fs/splice.c b/fs/splice.c
index 39e2dc01ac12..7f1ffc50ff1d 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1185,6 +1185,36 @@ static long do_splice(struct file *in, loff_t __user 
*off_in,
return -EINVAL;
 }
 
+static int pages_to_pipe(struct page **pages, struct pipe_inode_info *pipe,
+struct pipe_buffer *buf, size_t *total,
+ssize_t copied, size_t start)
+{
+   bool failed = false;
+   size_t len = 0;
+   int ret = 0;
+   int n;
+
+   for (n = 0; copied; n++, start = 0) {
+   int size = min_t(int, copied, PAGE_SIZE - start);
+   if (!failed) {
+   buf->page = pages[n];
+   buf->offset = start;
+   buf->len = size;
+   ret = add_to_pipe(pipe, buf);
+   if (unlikely(ret < 0))
+   failed = true;
+   else
+   len += ret;
+   } else {
+   put_page(pages[n]);
+   }
+   copied -= size;
+   }
+
+   *total += len;
+   return failed ? ret : len;
+}
+
 static int iter_to_pipe(struct iov_iter *from,
struct pipe_inode_info *pipe,
unsigned flags)
@@ -1195,13 +1225,11 @@ static int iter_to_pipe(struct iov_iter *from,
};
size_t total = 0;
int ret = 0;
-   bool failed = false;
 
-   while (iov_iter_count(from) && !failed) {
+   while (iov_iter_count(from)) {
struct page *pages[16];
ssize_t copied;
size_t start;
-   int n;
 
copied = iov_iter_get_pages(from, pages, ~0UL, 16, );
if (copied <= 0) {
@@ -1209,24 +1237,11 @@ static int iter_to_pipe(struct iov_iter *from,
break;
}
 
-   for (n = 0; copied; n++, start = 0) {
-   int size = min_t(int, copied, PAGE_SIZE - start);
-   if (!failed) {
-   buf.page = pages[n];
-   buf.offset = start;
-   buf.len = size;
-   ret = add_to_pipe(pipe, );
-   if (unlikely(ret < 0)) {
-   failed = true;
-   } else {
-   iov_iter_advance(from, ret);
-   total += ret;
-   }
-   } else {
-   put_page(pages[n]);
-   }
-   copied -= size;
-   }
+   ret = pages_to_pipe(pages, pipe, , , copied, start);
+   if (unlikely(ret < 0))
+   break;
+
+   iov_iter_advance(from, ret);
}
return total ? total : ret;
 }
-- 
2.7.4

[PATCH v5 3/4] x86: wire up the process_vmsplice syscall

[Mike Rapoport]

From: Andrei Vagin 

Signed-off-by: Andrei Vagin 
---
 arch/x86/entry/syscalls/syscall_32.tbl | 1 +
 arch/x86/entry/syscalls/syscall_64.tbl | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 448ac2161112..dc64bf577b17 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -391,3 +391,4 @@
 382i386pkey_free   sys_pkey_free
 383i386statx   sys_statx
 384i386arch_prctl  sys_arch_prctl  
compat_sys_arch_prctl
+385i386process_vmsplicesys_process_vmsplice
compat_sys_process_vmsplice
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
b/arch/x86/entry/syscalls/syscall_64.tbl
index 5aef183e2f85..d2f916c0309a 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -339,6 +339,7 @@
 330common  pkey_alloc  sys_pkey_alloc
 331common  pkey_free   sys_pkey_free
 332common  statx   sys_statx
+33364  process_vmsplicesys_process_vmsplice
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
@@ -380,3 +381,4 @@
 545x32 execveatcompat_sys_execveat/ptregs
 546x32 preadv2 compat_sys_preadv64v2
 547x32 pwritev2compat_sys_pwritev64v2
+548x32 process_vmsplicecompat_sys_process_vmsplice
-- 
2.7.4

[PATCH v5 2/4] vm: add a syscall to map a process memory into a pipe

[Mike Rapoport]

From: Andrei Vagin 

It is a hybrid of process_vm_readv() and vmsplice().

vmsplice can map memory from a current address space into a pipe.
process_vm_readv can read memory of another process.

A new system call can map memory of another process into a pipe.

ssize_t process_vmsplice(pid_t pid, int fd, const struct iovec *iov,
unsigned long nr_segs, unsigned int flags)

All arguments are identical with vmsplice except pid which specifies a
target process.

Currently if we want to dump a process memory to a file or to a socket,
we can use process_vm_readv() + write(), but it works slow, because data
are copied into a temporary user-space buffer.

A second way is to use vmsplice() + splice(). It is more effective,
because data are not copied into a temporary buffer, but here is another
problem. vmsplice works with the currect address space, so it can be
used only if we inject our code into a target process.

The second way suffers from a few other issues:
* a process has to be stopped to run a parasite code
* a number of pipes is limited, so it may be impossible to dump all
  memory in one iteration, and we have to stop process and inject our
  code a few times.
* pages in pipes are unreclaimable, so it isn't good to hold a lot of
  memory in pipes.

The introduced syscall allows to use a second way without injecting any
code into a target process.

My experiments shows that process_vmsplice() + splice() works two time
faster than process_vm_readv() + write().

It is particularly useful for iterative migration. In those cases we enable
a memory tracker, and then we are dumping  a process memory while a process
continues to work. On the first iteration we are dumping all memory, and
then we are dumpung only memory that was modified from the previous
iteration.  After a few pre-dump operations, a process is stopped and
dumped finally. The pre-dump operations allow to significantly decrease a
process downtime, when a process is migrated to another host.

The primary disadvantage of the process_vm_readv() + write() approach for
the iterative migration usecase is the need to stop the processes with, e.g.
ptrace, and inject parasite code. And, since the the number of pipes and
their size is limited, we either have to limit the dump size to about 1.5GB
or to keep the target processes stopped. The process_vmsplice system call
allows splicing memory without the parasite code and even without stopping
target processes.

This system call maybe usefult for debuggers. For example, a debugger can
use it to generate a core file, it can splice memory of a process into a
pipe and then splice it from the pipe to a file. This method works much
faster than using PTRACE_PEEK* commands.

Debuggers may also use process_vmsplice() to observe memory changes in a
process page. process_vmsplice() attaches a real process page to a pipe, so
we can splice it once and observe how it is being changed over time.

The process_vmsplice syscall might be of interest for users of
process_vm_readv(), in case if they read memory to send it to somewhere
else.

Signed-off-by: Andrei Vagin 
Signed-off-by: Mike Rapoport 
---
 fs/splice.c   | 205 ++
 include/linux/compat.h|   3 +
 include/linux/syscalls.h  |   4 +
 include/uapi/asm-generic/unistd.h |   5 +-
 kernel/sys_ni.c   |   2 +
 5 files changed, 218 insertions(+), 1 deletion(-)

diff --git a/fs/splice.c b/fs/splice.c
index 7f1ffc50ff1d..72397d2a59b9 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -1373,6 +1374,210 @@ SYSCALL_DEFINE4(vmsplice, int, fd, const struct iovec 
__user *, iov,
return error;
 }
 
+#ifdef CONFIG_CROSS_MEMORY_ATTACH
+/*
+ * Map pages from a specified task into a pipe
+ */
+static int remote_single_vec_to_pipe(struct task_struct *task,
+   struct mm_struct *mm,
+   const struct iovec *rvec,
+   struct pipe_inode_info *pipe,
+   unsigned int flags,
+   size_t *total)
+{
+   struct pipe_buffer buf = {
+   .ops = _page_pipe_buf_ops,
+   .flags = flags
+   };
+   unsigned long addr = (unsigned long) rvec->iov_base;
+   unsigned long pa = addr & PAGE_MASK;
+   unsigned long start_offset = addr - pa;
+   unsigned long nr_pages;
+   ssize_t len = rvec->iov_len;
+   struct page *process_pages[16];
+   bool failed = false;
+   int ret = 0;
+
+   nr_pages = (addr + len - 1) / PAGE_SIZE - addr / PAGE_SIZE + 1;
+   while (nr_pages) {
+   long pages = min(nr_pages, 16UL);
+   int locked = 1;
+   ssize_t copied;
+
+   /*
+* Get the pages we're interested in.  We must
+ 

[PATCH v5 3/4] x86: wire up the process_vmsplice syscall

[Mike Rapoport]

From: Andrei Vagin 

Signed-off-by: Andrei Vagin 
---
 arch/x86/entry/syscalls/syscall_32.tbl | 1 +
 arch/x86/entry/syscalls/syscall_64.tbl | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 448ac2161112..dc64bf577b17 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -391,3 +391,4 @@
 382i386pkey_free   sys_pkey_free
 383i386statx   sys_statx
 384i386arch_prctl  sys_arch_prctl  
compat_sys_arch_prctl
+385i386process_vmsplicesys_process_vmsplice
compat_sys_process_vmsplice
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
b/arch/x86/entry/syscalls/syscall_64.tbl
index 5aef183e2f85..d2f916c0309a 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -339,6 +339,7 @@
 330common  pkey_alloc  sys_pkey_alloc
 331common  pkey_free   sys_pkey_free
 332common  statx   sys_statx
+33364  process_vmsplicesys_process_vmsplice
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
@@ -380,3 +381,4 @@
 545x32 execveatcompat_sys_execveat/ptregs
 546x32 preadv2 compat_sys_preadv64v2
 547x32 pwritev2compat_sys_pwritev64v2
+548x32 process_vmsplicecompat_sys_process_vmsplice
-- 
2.7.4

[PATCH v5 2/4] vm: add a syscall to map a process memory into a pipe

[Mike Rapoport]

From: Andrei Vagin 

It is a hybrid of process_vm_readv() and vmsplice().

vmsplice can map memory from a current address space into a pipe.
process_vm_readv can read memory of another process.

A new system call can map memory of another process into a pipe.

ssize_t process_vmsplice(pid_t pid, int fd, const struct iovec *iov,
unsigned long nr_segs, unsigned int flags)

All arguments are identical with vmsplice except pid which specifies a
target process.

Currently if we want to dump a process memory to a file or to a socket,
we can use process_vm_readv() + write(), but it works slow, because data
are copied into a temporary user-space buffer.

A second way is to use vmsplice() + splice(). It is more effective,
because data are not copied into a temporary buffer, but here is another
problem. vmsplice works with the currect address space, so it can be
used only if we inject our code into a target process.

The second way suffers from a few other issues:
* a process has to be stopped to run a parasite code
* a number of pipes is limited, so it may be impossible to dump all
  memory in one iteration, and we have to stop process and inject our
  code a few times.
* pages in pipes are unreclaimable, so it isn't good to hold a lot of
  memory in pipes.

The introduced syscall allows to use a second way without injecting any
code into a target process.

My experiments shows that process_vmsplice() + splice() works two time
faster than process_vm_readv() + write().

It is particularly useful for iterative migration. In those cases we enable
a memory tracker, and then we are dumping  a process memory while a process
continues to work. On the first iteration we are dumping all memory, and
then we are dumpung only memory that was modified from the previous
iteration.  After a few pre-dump operations, a process is stopped and
dumped finally. The pre-dump operations allow to significantly decrease a
process downtime, when a process is migrated to another host.

The primary disadvantage of the process_vm_readv() + write() approach for
the iterative migration usecase is the need to stop the processes with, e.g.
ptrace, and inject parasite code. And, since the the number of pipes and
their size is limited, we either have to limit the dump size to about 1.5GB
or to keep the target processes stopped. The process_vmsplice system call
allows splicing memory without the parasite code and even without stopping
target processes.

This system call maybe usefult for debuggers. For example, a debugger can
use it to generate a core file, it can splice memory of a process into a
pipe and then splice it from the pipe to a file. This method works much
faster than using PTRACE_PEEK* commands.

Debuggers may also use process_vmsplice() to observe memory changes in a
process page. process_vmsplice() attaches a real process page to a pipe, so
we can splice it once and observe how it is being changed over time.

The process_vmsplice syscall might be of interest for users of
process_vm_readv(), in case if they read memory to send it to somewhere
else.

Signed-off-by: Andrei Vagin 
Signed-off-by: Mike Rapoport 
---
 fs/splice.c   | 205 ++
 include/linux/compat.h|   3 +
 include/linux/syscalls.h  |   4 +
 include/uapi/asm-generic/unistd.h |   5 +-
 kernel/sys_ni.c   |   2 +
 5 files changed, 218 insertions(+), 1 deletion(-)

diff --git a/fs/splice.c b/fs/splice.c
index 7f1ffc50ff1d..72397d2a59b9 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -1373,6 +1374,210 @@ SYSCALL_DEFINE4(vmsplice, int, fd, const struct iovec 
__user *, iov,
return error;
 }
 
+#ifdef CONFIG_CROSS_MEMORY_ATTACH
+/*
+ * Map pages from a specified task into a pipe
+ */
+static int remote_single_vec_to_pipe(struct task_struct *task,
+   struct mm_struct *mm,
+   const struct iovec *rvec,
+   struct pipe_inode_info *pipe,
+   unsigned int flags,
+   size_t *total)
+{
+   struct pipe_buffer buf = {
+   .ops = _page_pipe_buf_ops,
+   .flags = flags
+   };
+   unsigned long addr = (unsigned long) rvec->iov_base;
+   unsigned long pa = addr & PAGE_MASK;
+   unsigned long start_offset = addr - pa;
+   unsigned long nr_pages;
+   ssize_t len = rvec->iov_len;
+   struct page *process_pages[16];
+   bool failed = false;
+   int ret = 0;
+
+   nr_pages = (addr + len - 1) / PAGE_SIZE - addr / PAGE_SIZE + 1;
+   while (nr_pages) {
+   long pages = min(nr_pages, 16UL);
+   int locked = 1;
+   ssize_t copied;
+
+   /*
+* Get the pages we're interested in.  We must
+* access remotely because task/mm might not
+* 

[PATCH v7 5/9] dmtimer: Add timer ops to the platform data structure

[Keerthy]

Add timer ops to the platform data structure

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 include/linux/platform_data/dmtimer-omap.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/linux/platform_data/dmtimer-omap.h 
b/include/linux/platform_data/dmtimer-omap.h
index a19b78d..a3e1794 100644
--- a/include/linux/platform_data/dmtimer-omap.h
+++ b/include/linux/platform_data/dmtimer-omap.h
@@ -20,12 +20,50 @@
 #ifndef __PLATFORM_DATA_DMTIMER_OMAP_H__
 #define __PLATFORM_DATA_DMTIMER_OMAP_H__
 
+struct omap_dm_timer_ops {
+   struct omap_dm_timer *(*request_by_node)(struct device_node *np);
+   struct omap_dm_timer *(*request_specific)(int timer_id);
+   struct omap_dm_timer *(*request)(void);
+
+   int (*free)(struct omap_dm_timer *timer);
+
+   void(*enable)(struct omap_dm_timer *timer);
+   void(*disable)(struct omap_dm_timer *timer);
+
+   int (*get_irq)(struct omap_dm_timer *timer);
+   int (*set_int_enable)(struct omap_dm_timer *timer,
+ unsigned int value);
+   int (*set_int_disable)(struct omap_dm_timer *timer, u32 mask);
+
+   struct clk *(*get_fclk)(struct omap_dm_timer *timer);
+
+   int (*start)(struct omap_dm_timer *timer);
+   int (*stop)(struct omap_dm_timer *timer);
+   int (*set_source)(struct omap_dm_timer *timer, int source);
+
+   int (*set_load)(struct omap_dm_timer *timer, int autoreload,
+   unsigned int value);
+   int (*set_match)(struct omap_dm_timer *timer, int enable,
+unsigned int match);
+   int (*set_pwm)(struct omap_dm_timer *timer, int def_on,
+  int toggle, int trigger);
+   int (*set_prescaler)(struct omap_dm_timer *timer, int prescaler);
+
+   unsigned int (*read_counter)(struct omap_dm_timer *timer);
+   int (*write_counter)(struct omap_dm_timer *timer,
+unsigned int value);
+   unsigned int (*read_status)(struct omap_dm_timer *timer);
+   int (*write_status)(struct omap_dm_timer *timer,
+   unsigned int value);
+};
+
 struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
u32 timer_errata;
int (*get_context_loss_count)(struct device *);
+   struct omap_dm_timer_ops *timer_ops;
 };
 
 #endif /* __PLATFORM_DATA_DMTIMER_OMAP_H__ */
-- 
1.9.1

[PATCH v7 5/9] dmtimer: Add timer ops to the platform data structure

[Keerthy]

Add timer ops to the platform data structure

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 include/linux/platform_data/dmtimer-omap.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/linux/platform_data/dmtimer-omap.h 
b/include/linux/platform_data/dmtimer-omap.h
index a19b78d..a3e1794 100644
--- a/include/linux/platform_data/dmtimer-omap.h
+++ b/include/linux/platform_data/dmtimer-omap.h
@@ -20,12 +20,50 @@
 #ifndef __PLATFORM_DATA_DMTIMER_OMAP_H__
 #define __PLATFORM_DATA_DMTIMER_OMAP_H__
 
+struct omap_dm_timer_ops {
+   struct omap_dm_timer *(*request_by_node)(struct device_node *np);
+   struct omap_dm_timer *(*request_specific)(int timer_id);
+   struct omap_dm_timer *(*request)(void);
+
+   int (*free)(struct omap_dm_timer *timer);
+
+   void(*enable)(struct omap_dm_timer *timer);
+   void(*disable)(struct omap_dm_timer *timer);
+
+   int (*get_irq)(struct omap_dm_timer *timer);
+   int (*set_int_enable)(struct omap_dm_timer *timer,
+ unsigned int value);
+   int (*set_int_disable)(struct omap_dm_timer *timer, u32 mask);
+
+   struct clk *(*get_fclk)(struct omap_dm_timer *timer);
+
+   int (*start)(struct omap_dm_timer *timer);
+   int (*stop)(struct omap_dm_timer *timer);
+   int (*set_source)(struct omap_dm_timer *timer, int source);
+
+   int (*set_load)(struct omap_dm_timer *timer, int autoreload,
+   unsigned int value);
+   int (*set_match)(struct omap_dm_timer *timer, int enable,
+unsigned int match);
+   int (*set_pwm)(struct omap_dm_timer *timer, int def_on,
+  int toggle, int trigger);
+   int (*set_prescaler)(struct omap_dm_timer *timer, int prescaler);
+
+   unsigned int (*read_counter)(struct omap_dm_timer *timer);
+   int (*write_counter)(struct omap_dm_timer *timer,
+unsigned int value);
+   unsigned int (*read_status)(struct omap_dm_timer *timer);
+   int (*write_status)(struct omap_dm_timer *timer,
+   unsigned int value);
+};
+
 struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
u32 timer_errata;
int (*get_context_loss_count)(struct device *);
+   struct omap_dm_timer_ops *timer_ops;
 };
 
 #endif /* __PLATFORM_DATA_DMTIMER_OMAP_H__ */
-- 
1.9.1

[PATCH v7 4/9] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

[Keerthy]

Move the dmtimer driver out of plat-omap to clocksource.
So that non-omap devices also could use this.

No Code changes done to the driver file only renamed to timer-dm.c.
Also removed the config dependencies for OMAP_DM_TIMER.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/plat-omap/Kconfig | 6 --
 arch/arm/plat-omap/Makefile| 1 -
 drivers/clocksource/Kconfig| 3 +++
 drivers/clocksource/Makefile   | 1 +
 arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c | 0
 5 files changed, 4 insertions(+), 7 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (100%)

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 7276afe..afc1a1d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -106,12 +106,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
help
  PPA routine service ID for setting L2 auxiliary control register.
 
-config OMAP_DM_TIMER
-   bool "Use dual-mode timer"
-   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
-   help
-Select this option if you want to use OMAP Dual-Mode timers.
-
 config OMAP_SERIAL_WAKE
bool "Enable wake-up events for serial ports"
depends on ARCH_OMAP1 && OMAP_MUX
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 47e1867..7215ada 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -9,5 +9,4 @@ obj-y := sram.o dma.o counter_32k.o
 
 # omap_device support (OMAP2+ only at the moment)
 
-obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
 obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index c729a88..3f799b2 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -21,6 +21,9 @@ config CLKEVT_I8253
 config I8253_LOCK
bool
 
+config OMAP_DM_TIMER
+   bool
+
 config CLKBLD_I8253
def_bool y if CLKSRC_I8253 || CLKEVT_I8253 || I8253_LOCK
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 72711f1..27b5497 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_EM_TIMER_STI)+= em_sti.o
 obj-$(CONFIG_CLKBLD_I8253) += i8253.o
 obj-$(CONFIG_CLKSRC_MMIO)  += mmio.o
 obj-$(CONFIG_DIGICOLOR_TIMER)  += timer-digicolor.o
+obj-$(CONFIG_OMAP_DM_TIMER)+= timer-dm.o
 obj-$(CONFIG_DW_APB_TIMER) += dw_apb_timer.o
 obj-$(CONFIG_DW_APB_TIMER_OF)  += dw_apb_timer_of.o
 obj-$(CONFIG_FTTMR010_TIMER)   += timer-fttmr010.o
diff --git a/arch/arm/plat-omap/dmtimer.c b/drivers/clocksource/timer-dm.c
similarity index 100%
rename from arch/arm/plat-omap/dmtimer.c
rename to drivers/clocksource/timer-dm.c
-- 
1.9.1

[PATCH v7 4/9] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource

[Keerthy]

Move the dmtimer driver out of plat-omap to clocksource.
So that non-omap devices also could use this.

No Code changes done to the driver file only renamed to timer-dm.c.
Also removed the config dependencies for OMAP_DM_TIMER.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/plat-omap/Kconfig | 6 --
 arch/arm/plat-omap/Makefile| 1 -
 drivers/clocksource/Kconfig| 3 +++
 drivers/clocksource/Makefile   | 1 +
 arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c | 0
 5 files changed, 4 insertions(+), 7 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (100%)

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 7276afe..afc1a1d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -106,12 +106,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
help
  PPA routine service ID for setting L2 auxiliary control register.
 
-config OMAP_DM_TIMER
-   bool "Use dual-mode timer"
-   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
-   help
-Select this option if you want to use OMAP Dual-Mode timers.
-
 config OMAP_SERIAL_WAKE
bool "Enable wake-up events for serial ports"
depends on ARCH_OMAP1 && OMAP_MUX
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 47e1867..7215ada 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -9,5 +9,4 @@ obj-y := sram.o dma.o counter_32k.o
 
 # omap_device support (OMAP2+ only at the moment)
 
-obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
 obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index c729a88..3f799b2 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -21,6 +21,9 @@ config CLKEVT_I8253
 config I8253_LOCK
bool
 
+config OMAP_DM_TIMER
+   bool
+
 config CLKBLD_I8253
def_bool y if CLKSRC_I8253 || CLKEVT_I8253 || I8253_LOCK
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 72711f1..27b5497 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_EM_TIMER_STI)+= em_sti.o
 obj-$(CONFIG_CLKBLD_I8253) += i8253.o
 obj-$(CONFIG_CLKSRC_MMIO)  += mmio.o
 obj-$(CONFIG_DIGICOLOR_TIMER)  += timer-digicolor.o
+obj-$(CONFIG_OMAP_DM_TIMER)+= timer-dm.o
 obj-$(CONFIG_DW_APB_TIMER) += dw_apb_timer.o
 obj-$(CONFIG_DW_APB_TIMER_OF)  += dw_apb_timer_of.o
 obj-$(CONFIG_FTTMR010_TIMER)   += timer-fttmr010.o
diff --git a/arch/arm/plat-omap/dmtimer.c b/drivers/clocksource/timer-dm.c
similarity index 100%
rename from arch/arm/plat-omap/dmtimer.c
rename to drivers/clocksource/timer-dm.c
-- 
1.9.1

[PATCH v7 6/9] clocksource: dmtimer: Populate the timer ops to the pdata

[Keerthy]

Add the timer ops to the platform data

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 drivers/clocksource/timer-dm.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index afe1dc9..1cbd954 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -922,8 +922,33 @@ static int omap_dm_timer_remove(struct platform_device 
*pdev)
return ret;
 }
 
+static struct omap_dm_timer_ops dmtimer_ops = {
+   .request_by_node = omap_dm_timer_request_by_node,
+   .request_specific = omap_dm_timer_request_specific,
+   .request = omap_dm_timer_request,
+   .set_source = omap_dm_timer_set_source,
+   .get_irq = omap_dm_timer_get_irq,
+   .set_int_enable = omap_dm_timer_set_int_enable,
+   .set_int_disable = omap_dm_timer_set_int_disable,
+   .free = omap_dm_timer_free,
+   .enable = omap_dm_timer_enable,
+   .disable = omap_dm_timer_disable,
+   .get_fclk = omap_dm_timer_get_fclk,
+   .start = omap_dm_timer_start,
+   .stop = omap_dm_timer_stop,
+   .set_load = omap_dm_timer_set_load,
+   .set_match = omap_dm_timer_set_match,
+   .set_pwm = omap_dm_timer_set_pwm,
+   .set_prescaler = omap_dm_timer_set_prescaler,
+   .read_counter = omap_dm_timer_read_counter,
+   .write_counter = omap_dm_timer_write_counter,
+   .read_status = omap_dm_timer_read_status,
+   .write_status = omap_dm_timer_write_status,
+};
+
 static const struct dmtimer_platform_data omap3plus_pdata = {
.timer_errata = OMAP_TIMER_ERRATA_I103_I767,
+   .timer_ops = _ops,
 };
 
 static const struct of_device_id omap_timer_match[] = {
-- 
1.9.1

[PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

[Keerthy]

The header file is currently under plat-omap directory
under arch/omap. Move this out to an accessible place.

No Code changes done to the header file.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/mach-omap1/pm.c   | 2 +-
 arch/arm/mach-omap1/timer.c| 2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 2 +-
 arch/arm/mach-omap2/timer.c| 2 +-
 arch/arm/plat-omap/dmtimer.c   | 2 +-
 {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h | 0
 14 files changed, 13 insertions(+), 13 deletions(-)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h 
(100%)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index f1135bf..a07d47cf 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 8fb1ec6..7c057ab 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "soc.h"
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 0afb014..0a8b95f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 013b26b..16e3d8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 4b094cb..8a65f70 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -11,7 +11,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 1a2f224..b030137 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -25,7 +25,7 @@
 #include "l4_3xxx.h"
 #include 
 #include 
-#include 
+#include 
 
 #include "soc.h"
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index a1901c2..51c7d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 988e7ea..530334e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 4c2a05b..2452649 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 84f1182..94f3bb1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 #include "cm81xx.h"
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 6b433fc..ad9df86 100644
--- 

[PATCH v7 6/9] clocksource: dmtimer: Populate the timer ops to the pdata

[Keerthy]

Add the timer ops to the platform data

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 drivers/clocksource/timer-dm.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index afe1dc9..1cbd954 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -922,8 +922,33 @@ static int omap_dm_timer_remove(struct platform_device 
*pdev)
return ret;
 }
 
+static struct omap_dm_timer_ops dmtimer_ops = {
+   .request_by_node = omap_dm_timer_request_by_node,
+   .request_specific = omap_dm_timer_request_specific,
+   .request = omap_dm_timer_request,
+   .set_source = omap_dm_timer_set_source,
+   .get_irq = omap_dm_timer_get_irq,
+   .set_int_enable = omap_dm_timer_set_int_enable,
+   .set_int_disable = omap_dm_timer_set_int_disable,
+   .free = omap_dm_timer_free,
+   .enable = omap_dm_timer_enable,
+   .disable = omap_dm_timer_disable,
+   .get_fclk = omap_dm_timer_get_fclk,
+   .start = omap_dm_timer_start,
+   .stop = omap_dm_timer_stop,
+   .set_load = omap_dm_timer_set_load,
+   .set_match = omap_dm_timer_set_match,
+   .set_pwm = omap_dm_timer_set_pwm,
+   .set_prescaler = omap_dm_timer_set_prescaler,
+   .read_counter = omap_dm_timer_read_counter,
+   .write_counter = omap_dm_timer_write_counter,
+   .read_status = omap_dm_timer_read_status,
+   .write_status = omap_dm_timer_write_status,
+};
+
 static const struct dmtimer_platform_data omap3plus_pdata = {
.timer_errata = OMAP_TIMER_ERRATA_I103_I767,
+   .timer_ops = _ops,
 };
 
 static const struct of_device_id omap_timer_match[] = {
-- 
1.9.1

[PATCH v7 3/9] arm: omap: Move dmtimer.h out of plat-omap

[Keerthy]

The header file is currently under plat-omap directory
under arch/omap. Move this out to an accessible place.

No Code changes done to the header file.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/mach-omap1/pm.c   | 2 +-
 arch/arm/mach-omap1/timer.c| 2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 2 +-
 arch/arm/mach-omap2/timer.c| 2 +-
 arch/arm/plat-omap/dmtimer.c   | 2 +-
 {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h | 0
 14 files changed, 13 insertions(+), 13 deletions(-)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h 
(100%)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index f1135bf..a07d47cf 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 8fb1ec6..7c057ab 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "soc.h"
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 0afb014..0a8b95f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 013b26b..16e3d8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "l3_2xxx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 4b094cb..8a65f70 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -11,7 +11,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 1a2f224..b030137 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -25,7 +25,7 @@
 #include "l4_3xxx.h"
 #include 
 #include 
-#include 
+#include 
 
 #include "soc.h"
 #include "omap_hwmod.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index a1901c2..51c7d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 988e7ea..530334e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 4c2a05b..2452649 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod.h"
 #include "omap_hwmod_common_data.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 84f1182..94f3bb1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 #include "cm81xx.h"
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 6b433fc..ad9df86 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ 

[PATCH v7 9/9] arm: omap: pdata-quirks: Remove unused timer pdata

[Keerthy]

Remove unused timer pdata.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/mach-omap2/pdata-quirks.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ad9df86..e7d7fc7 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,10 +24,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 #include "common.h"
 #include "common-board-devices.h"
@@ -477,33 +475,6 @@ void omap_auxdata_legacy_init(struct device *dev)
dev->platform_data = _gpio_auxdata;
 }
 
-/* Dual mode timer PWM callbacks platdata */
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
-   .request_by_node = omap_dm_timer_request_by_node,
-   .request_specific = omap_dm_timer_request_specific,
-   .request = omap_dm_timer_request,
-   .set_source = omap_dm_timer_set_source,
-   .get_irq = omap_dm_timer_get_irq,
-   .set_int_enable = omap_dm_timer_set_int_enable,
-   .set_int_disable = omap_dm_timer_set_int_disable,
-   .free = omap_dm_timer_free,
-   .enable = omap_dm_timer_enable,
-   .disable = omap_dm_timer_disable,
-   .get_fclk = omap_dm_timer_get_fclk,
-   .start = omap_dm_timer_start,
-   .stop = omap_dm_timer_stop,
-   .set_load = omap_dm_timer_set_load,
-   .set_match = omap_dm_timer_set_match,
-   .set_pwm = omap_dm_timer_set_pwm,
-   .set_prescaler = omap_dm_timer_set_prescaler,
-   .read_counter = omap_dm_timer_read_counter,
-   .write_counter = omap_dm_timer_write_counter,
-   .read_status = omap_dm_timer_read_status,
-   .write_status = omap_dm_timer_write_status,
-};
-#endif
-
 static struct ir_rx51_platform_data __maybe_unused rx51_ir_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
 };
@@ -572,9 +543,6 @@ static void __init omap3_mcbsp_init(void) {}
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
   _m3_data),
 #endif
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-   OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, _dmtimer_pdata),
-#endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
   _iommu_pdata),
-- 
1.9.1

[PATCH v7 8/9] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

[Keerthy]

Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.

Signed-off-by: Keerthy 
Acked-by: Neil Armstrong 
Reviewed-by: Claudiu Beznea 
---
 drivers/pwm/pwm-omap-dmtimer.c | 68 ++
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 5ad42f3..cc485d9 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,7 @@ struct pwm_omap_dmtimer_chip {
struct pwm_chip chip;
struct mutex mutex;
pwm_omap_dmtimer *dm_timer;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct omap_dm_timer_ops *pdata;
struct platform_device *dm_timer_pdev;
 };
 
@@ -242,19 +243,35 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
 {
struct device_node *np = pdev->dev.of_node;
struct device_node *timer;
+   struct platform_device *timer_pdev;
struct pwm_omap_dmtimer_chip *omap;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct dmtimer_platform_data *timer_pdata;
+   struct omap_dm_timer_ops *pdata;
pwm_omap_dmtimer *dm_timer;
u32 v;
-   int status;
+   int status, ret;
 
-   pdata = dev_get_platdata(>dev);
-   if (!pdata) {
-   dev_err(>dev, "Missing dmtimer platform data\n");
-   return -EINVAL;
+   timer = of_parse_phandle(np, "ti,timers", 0);
+   if (!timer)
+   return -ENODEV;
+
+   timer_pdev = of_find_device_by_node(timer);
+   if (!timer_pdev) {
+   dev_err(>dev, "Unable to find Timer pdev\n");
+   ret = -ENODEV;
+   goto put;
}
 
-   if (!pdata->request_by_node ||
+   timer_pdata = dev_get_platdata(_pdev->dev);
+   if (!timer_pdata) {
+   dev_err(>dev, "dmtimer pdata structure NULL\n");
+   ret = -EINVAL;
+   goto put;
+   }
+
+   pdata = timer_pdata->timer_ops;
+
+   if (!pdata || !pdata->request_by_node ||
!pdata->free ||
!pdata->enable ||
!pdata->disable ||
@@ -267,37 +284,32 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
!pdata->set_prescaler ||
!pdata->write_counter) {
dev_err(>dev, "Incomplete dmtimer pdata structure\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put;
}
 
-   timer = of_parse_phandle(np, "ti,timers", 0);
-   if (!timer)
-   return -ENODEV;
-
if (!of_get_property(timer, "ti,timer-pwm", NULL)) {
dev_err(>dev, "Missing ti,timer-pwm capability\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto put;
}
 
dm_timer = pdata->request_by_node(timer);
-   if (!dm_timer)
-   return -EPROBE_DEFER;
+   if (!dm_timer) {
+   ret = -EPROBE_DEFER;
+   goto put;
+   }
 
omap = devm_kzalloc(>dev, sizeof(*omap), GFP_KERNEL);
if (!omap) {
pdata->free(dm_timer);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto put;
}
 
omap->pdata = pdata;
omap->dm_timer = dm_timer;
-
-   omap->dm_timer_pdev = of_find_device_by_node(timer);
-   if (!omap->dm_timer_pdev) {
-   dev_err(>dev, "Unable to find timer pdev\n");
-   omap->pdata->free(dm_timer);
-   return -EINVAL;
-   }
+   omap->dm_timer_pdev = timer_pdev;
 
/*
 * Ensure that the timer is stopped before we allow PWM core to call
@@ -326,12 +338,18 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
if (status < 0) {
dev_err(>dev, "failed to register PWM\n");
omap->pdata->free(omap->dm_timer);
-   return status;
+   ret = status;
+   goto put;
}
 
platform_set_drvdata(pdev, omap);
 
return 0;
+
+put:
+   of_node_put(timer);
+
+   return ret;
 }
 
 static int pwm_omap_dmtimer_remove(struct platform_device *pdev)
-- 
1.9.1

[PATCH v7 9/9] arm: omap: pdata-quirks: Remove unused timer pdata

[Keerthy]

Remove unused timer pdata.

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/mach-omap2/pdata-quirks.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ad9df86..e7d7fc7 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,10 +24,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 #include "common.h"
 #include "common-board-devices.h"
@@ -477,33 +475,6 @@ void omap_auxdata_legacy_init(struct device *dev)
dev->platform_data = _gpio_auxdata;
 }
 
-/* Dual mode timer PWM callbacks platdata */
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
-   .request_by_node = omap_dm_timer_request_by_node,
-   .request_specific = omap_dm_timer_request_specific,
-   .request = omap_dm_timer_request,
-   .set_source = omap_dm_timer_set_source,
-   .get_irq = omap_dm_timer_get_irq,
-   .set_int_enable = omap_dm_timer_set_int_enable,
-   .set_int_disable = omap_dm_timer_set_int_disable,
-   .free = omap_dm_timer_free,
-   .enable = omap_dm_timer_enable,
-   .disable = omap_dm_timer_disable,
-   .get_fclk = omap_dm_timer_get_fclk,
-   .start = omap_dm_timer_start,
-   .stop = omap_dm_timer_stop,
-   .set_load = omap_dm_timer_set_load,
-   .set_match = omap_dm_timer_set_match,
-   .set_pwm = omap_dm_timer_set_pwm,
-   .set_prescaler = omap_dm_timer_set_prescaler,
-   .read_counter = omap_dm_timer_read_counter,
-   .write_counter = omap_dm_timer_write_counter,
-   .read_status = omap_dm_timer_read_status,
-   .write_status = omap_dm_timer_write_status,
-};
-#endif
-
 static struct ir_rx51_platform_data __maybe_unused rx51_ir_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
 };
@@ -572,9 +543,6 @@ static void __init omap3_mcbsp_init(void) {}
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
   _m3_data),
 #endif
-#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-   OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, _dmtimer_pdata),
-#endif
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
   _iommu_pdata),
-- 
1.9.1

[PATCH v7 8/9] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops

[Keerthy]

Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.

Signed-off-by: Keerthy 
Acked-by: Neil Armstrong 
Reviewed-by: Claudiu Beznea 
---
 drivers/pwm/pwm-omap-dmtimer.c | 68 ++
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 5ad42f3..cc485d9 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,7 +38,7 @@ struct pwm_omap_dmtimer_chip {
struct pwm_chip chip;
struct mutex mutex;
pwm_omap_dmtimer *dm_timer;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct omap_dm_timer_ops *pdata;
struct platform_device *dm_timer_pdev;
 };
 
@@ -242,19 +243,35 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
 {
struct device_node *np = pdev->dev.of_node;
struct device_node *timer;
+   struct platform_device *timer_pdev;
struct pwm_omap_dmtimer_chip *omap;
-   struct pwm_omap_dmtimer_pdata *pdata;
+   struct dmtimer_platform_data *timer_pdata;
+   struct omap_dm_timer_ops *pdata;
pwm_omap_dmtimer *dm_timer;
u32 v;
-   int status;
+   int status, ret;
 
-   pdata = dev_get_platdata(>dev);
-   if (!pdata) {
-   dev_err(>dev, "Missing dmtimer platform data\n");
-   return -EINVAL;
+   timer = of_parse_phandle(np, "ti,timers", 0);
+   if (!timer)
+   return -ENODEV;
+
+   timer_pdev = of_find_device_by_node(timer);
+   if (!timer_pdev) {
+   dev_err(>dev, "Unable to find Timer pdev\n");
+   ret = -ENODEV;
+   goto put;
}
 
-   if (!pdata->request_by_node ||
+   timer_pdata = dev_get_platdata(_pdev->dev);
+   if (!timer_pdata) {
+   dev_err(>dev, "dmtimer pdata structure NULL\n");
+   ret = -EINVAL;
+   goto put;
+   }
+
+   pdata = timer_pdata->timer_ops;
+
+   if (!pdata || !pdata->request_by_node ||
!pdata->free ||
!pdata->enable ||
!pdata->disable ||
@@ -267,37 +284,32 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
!pdata->set_prescaler ||
!pdata->write_counter) {
dev_err(>dev, "Incomplete dmtimer pdata structure\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put;
}
 
-   timer = of_parse_phandle(np, "ti,timers", 0);
-   if (!timer)
-   return -ENODEV;
-
if (!of_get_property(timer, "ti,timer-pwm", NULL)) {
dev_err(>dev, "Missing ti,timer-pwm capability\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto put;
}
 
dm_timer = pdata->request_by_node(timer);
-   if (!dm_timer)
-   return -EPROBE_DEFER;
+   if (!dm_timer) {
+   ret = -EPROBE_DEFER;
+   goto put;
+   }
 
omap = devm_kzalloc(>dev, sizeof(*omap), GFP_KERNEL);
if (!omap) {
pdata->free(dm_timer);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto put;
}
 
omap->pdata = pdata;
omap->dm_timer = dm_timer;
-
-   omap->dm_timer_pdev = of_find_device_by_node(timer);
-   if (!omap->dm_timer_pdev) {
-   dev_err(>dev, "Unable to find timer pdev\n");
-   omap->pdata->free(dm_timer);
-   return -EINVAL;
-   }
+   omap->dm_timer_pdev = timer_pdev;
 
/*
 * Ensure that the timer is stopped before we allow PWM core to call
@@ -326,12 +338,18 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
*pdev)
if (status < 0) {
dev_err(>dev, "failed to register PWM\n");
omap->pdata->free(omap->dm_timer);
-   return status;
+   ret = status;
+   goto put;
}
 
platform_set_drvdata(pdev, omap);
 
return 0;
+
+put:
+   of_node_put(timer);
+
+   return ret;
 }
 
 static int pwm_omap_dmtimer_remove(struct platform_device *pdev)
-- 
1.9.1

[PATCH v7 0/9] omap: dmtimer: Move driver out of plat-omap

[Keerthy]

The series moves dmtimer out of plat-omap to drivers/clocksource.
The series also does a bunch of changes to pwm-omap-dmtimer code
to adapt to the driver migration and clean up plat specific
pdata-quirks and use the dmtimer platform data.

Boot tested on DRA7-EVM and AM437X-GP-EVM.
Compile tested omap1_defconfig.

This is based on top of linux-next branch.

This is tested on on IGEPv2 (OMAP3430 based) by Ladis.

Changes from V6:

  * Fixed error checking for pwm driver patch.
  * Removed one of the fixes from Ladis as per request.

Changes from V5:

  * Added couple of fixes from Ladis for  pwm-dmtimer.

Changes from v4:

  * Made OMAP_DM_TIMER config option silent.
  * Changed the driver name to timer-dm.c

Changes from v3:

  * Reverted to v2 approach of using dev_get_platdata to fetch dmtimer ops.

Changes from V2:

  * Wrapped the inline functions in header file under OMAP2PLUS
  * Added a new of helper function to fetch plat_data from of node. 

Keerthy (8):
  clocksource: dmtimer: Remove all the exports
  arm: omap: timer: Wrap the inline functions under OMAP2PLUS define
  arm: omap: Move dmtimer.h out of plat-omap
  arm: OMAP: Move dmtimer driver out of plat-omap to drivers under
clocksource
  dmtimer: Add timer ops to the platform data structure
  clocksource: dmtimer: Populate the timer ops to the pdata
  pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
  arm: omap: pdata-quirks: Remove unused timer pdata

Ladislav Michl (1):
  clocksource: timer-dm: Hook device platform data if not already
assigned

 arch/arm/mach-omap1/pm.c   |  2 +-
 arch/arm/mach-omap1/timer.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 32 --
 arch/arm/mach-omap2/timer.c|  2 +-
 arch/arm/plat-omap/Kconfig |  6 --
 arch/arm/plat-omap/Makefile|  1 -
 drivers/clocksource/Kconfig|  3 +
 drivers/clocksource/Makefile   |  1 +
 .../dmtimer.c => drivers/clocksource/timer-dm.c| 64 ++--
 drivers/pwm/pwm-omap-dmtimer.c | 68 +-
 .../include/plat => include/clocksource}/dmtimer.h |  8 ++-
 include/linux/platform_data/dmtimer-omap.h | 38 
 20 files changed, 134 insertions(+), 109 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (94%)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h (97%)

-- 
1.9.1

[PATCH v7 1/9] clocksource: dmtimer: Remove all the exports

[Keerthy]

Remove all the unwanted exports from the driver

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/plat-omap/dmtimer.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d443e48..72565fc 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
 {
return _omap_dm_timer_request(REQUEST_ANY, NULL);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request);
 
 struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 {
@@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 
return _omap_dm_timer_request(REQUEST_BY_ID, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
 
 /**
  * omap_dm_timer_request_by_cap - Request a timer by capability
@@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
 {
return _omap_dm_timer_request(REQUEST_BY_CAP, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
 
 /**
  * omap_dm_timer_request_by_node - Request a timer by device-tree node
@@ -346,7 +343,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_node(struct 
device_node *np)
 
return _omap_dm_timer_request(REQUEST_BY_NODE, np);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
 
 int omap_dm_timer_free(struct omap_dm_timer *timer)
 {
@@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
timer->reserved = 0;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_free);
 
 void omap_dm_timer_enable(struct omap_dm_timer *timer)
 {
@@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
}
}
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
 
 void omap_dm_timer_disable(struct omap_dm_timer *timer)
 {
pm_runtime_put_sync(>pdev->dev);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
 
 int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
 {
@@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
return timer->irq;
return -EINVAL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
 
 #if defined(CONFIG_ARCH_OMAP1)
 #include 
@@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return inputmask;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #else
 
@@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
*timer)
return timer->fclk;
return NULL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
 
 __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 {
@@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #endif
 
@@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
 
 int omap_dm_timer_start(struct omap_dm_timer *timer)
 {
@@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
timer->context.tclr = l;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_start);
 
 int omap_dm_timer_stop(struct omap_dm_timer *timer)
 {
@@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
 
 int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
 {
@@ -569,7 +555,6 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
 
 int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
unsigned int load)
@@ -595,7 +580,6 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int 
autoreload,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load);
 
 /* Optimized set_load which removes costly spin wait in timer_start */
 int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
@@ -625,7 +609,6 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer 
*timer, int autoreload,
timer->context.tcrr = load;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load_start);
 
 int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
 unsigned int match)
@@ -650,7 +633,6 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, 
int enable,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_match);
 
 int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
   int toggle, int trigger)
@@ -676,7 +658,6 @@ int omap_dm_timer_set_pwm(struct 

[PATCH v7 2/9] arm: omap: timer: Wrap the inline functions under OMAP2PLUS define

[Keerthy]

Wrap the inline functions under OMAP2PLUS/OMAP1 defines.

Signed-off-by: Keerthy 
Tested-by: Ladislav Michl 
---
 arch/arm/plat-omap/include/plat/dmtimer.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index dd79f30..862ad62 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -276,6 +276,12 @@ struct omap_dm_timer {
 #define OMAP_TIMER_TICK_INT_MASK_COUNT_REG \
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR << WPSHIFT))
 
+/*
+ * The below are inlined to optimize code size for system timers. Other code
+ * should not need these at all, see
+ * include/linux/platform_data/pwm_omap_dmtimer.h
+ */
+#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2PLUS)
 static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg,
int posted)
 {
@@ -414,5 +420,5 @@ static inline void __omap_dm_timer_write_status(struct 
omap_dm_timer *timer,
 {
writel_relaxed(value, timer->irq_stat);
 }
-
+#endif /* CONFIG_ARCH_OMAP1 || CONFIG_ARCH_OMAP2PLUS */
 #endif /* __ASM_ARCH_DMTIMER_H */
-- 
1.9.1

[PATCH v7 1/9] clocksource: dmtimer: Remove all the exports

[Keerthy]

Remove all the unwanted exports from the driver

Signed-off-by: Keerthy 
Reviewed-by: Sebastian Reichel 
Tested-by: Ladislav Michl 
---
 arch/arm/plat-omap/dmtimer.c | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d443e48..72565fc 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -302,7 +302,6 @@ struct omap_dm_timer *omap_dm_timer_request(void)
 {
return _omap_dm_timer_request(REQUEST_ANY, NULL);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request);
 
 struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 {
@@ -315,7 +314,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
 
return _omap_dm_timer_request(REQUEST_BY_ID, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
 
 /**
  * omap_dm_timer_request_by_cap - Request a timer by capability
@@ -330,7 +328,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
 {
return _omap_dm_timer_request(REQUEST_BY_CAP, );
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
 
 /**
  * omap_dm_timer_request_by_node - Request a timer by device-tree node
@@ -346,7 +343,6 @@ struct omap_dm_timer *omap_dm_timer_request_by_node(struct 
device_node *np)
 
return _omap_dm_timer_request(REQUEST_BY_NODE, np);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_node);
 
 int omap_dm_timer_free(struct omap_dm_timer *timer)
 {
@@ -359,7 +355,6 @@ int omap_dm_timer_free(struct omap_dm_timer *timer)
timer->reserved = 0;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_free);
 
 void omap_dm_timer_enable(struct omap_dm_timer *timer)
 {
@@ -379,13 +374,11 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer)
}
}
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
 
 void omap_dm_timer_disable(struct omap_dm_timer *timer)
 {
pm_runtime_put_sync(>pdev->dev);
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
 
 int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
 {
@@ -393,7 +386,6 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
return timer->irq;
return -EINVAL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
 
 #if defined(CONFIG_ARCH_OMAP1)
 #include 
@@ -429,7 +421,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return inputmask;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #else
 
@@ -439,7 +430,6 @@ struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer 
*timer)
return timer->fclk;
return NULL;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
 
 __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 {
@@ -447,7 +437,6 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
 
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
 
 #endif
 
@@ -461,7 +450,6 @@ int omap_dm_timer_trigger(struct omap_dm_timer *timer)
omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
 
 int omap_dm_timer_start(struct omap_dm_timer *timer)
 {
@@ -482,7 +470,6 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
timer->context.tclr = l;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_start);
 
 int omap_dm_timer_stop(struct omap_dm_timer *timer)
 {
@@ -506,7 +493,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
 
 int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
 {
@@ -569,7 +555,6 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_source);
 
 int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
unsigned int load)
@@ -595,7 +580,6 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int 
autoreload,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load);
 
 /* Optimized set_load which removes costly spin wait in timer_start */
 int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
@@ -625,7 +609,6 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer 
*timer, int autoreload,
timer->context.tcrr = load;
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_load_start);
 
 int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
 unsigned int match)
@@ -650,7 +633,6 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, 
int enable,
omap_dm_timer_disable(timer);
return 0;
 }
-EXPORT_SYMBOL_GPL(omap_dm_timer_set_match);
 
 int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
   int toggle, int trigger)
@@ -676,7 +658,6 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int 
def_on,
omap_dm_timer_disable(timer);

[PATCH v7 0/9] omap: dmtimer: Move driver out of plat-omap

[Keerthy]

The series moves dmtimer out of plat-omap to drivers/clocksource.
The series also does a bunch of changes to pwm-omap-dmtimer code
to adapt to the driver migration and clean up plat specific
pdata-quirks and use the dmtimer platform data.

Boot tested on DRA7-EVM and AM437X-GP-EVM.
Compile tested omap1_defconfig.

This is based on top of linux-next branch.

This is tested on on IGEPv2 (OMAP3430 based) by Ladis.

Changes from V6:

  * Fixed error checking for pwm driver patch.
  * Removed one of the fixes from Ladis as per request.

Changes from V5:

  * Added couple of fixes from Ladis for  pwm-dmtimer.

Changes from v4:

  * Made OMAP_DM_TIMER config option silent.
  * Changed the driver name to timer-dm.c

Changes from v3:

  * Reverted to v2 approach of using dev_get_platdata to fetch dmtimer ops.

Changes from V2:

  * Wrapped the inline functions in header file under OMAP2PLUS
  * Added a new of helper function to fetch plat_data from of node. 

Keerthy (8):
  clocksource: dmtimer: Remove all the exports
  arm: omap: timer: Wrap the inline functions under OMAP2PLUS define
  arm: omap: Move dmtimer.h out of plat-omap
  arm: OMAP: Move dmtimer driver out of plat-omap to drivers under
clocksource
  dmtimer: Add timer ops to the platform data structure
  clocksource: dmtimer: Populate the timer ops to the pdata
  pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
  arm: omap: pdata-quirks: Remove unused timer pdata

Ladislav Michl (1):
  clocksource: timer-dm: Hook device platform data if not already
assigned

 arch/arm/mach-omap1/pm.c   |  2 +-
 arch/arm/mach-omap1/timer.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  2 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  2 +-
 arch/arm/mach-omap2/pdata-quirks.c | 32 --
 arch/arm/mach-omap2/timer.c|  2 +-
 arch/arm/plat-omap/Kconfig |  6 --
 arch/arm/plat-omap/Makefile|  1 -
 drivers/clocksource/Kconfig|  3 +
 drivers/clocksource/Makefile   |  1 +
 .../dmtimer.c => drivers/clocksource/timer-dm.c| 64 ++--
 drivers/pwm/pwm-omap-dmtimer.c | 68 +-
 .../include/plat => include/clocksource}/dmtimer.h |  8 ++-
 include/linux/platform_data/dmtimer-omap.h | 38 
 20 files changed, 134 insertions(+), 109 deletions(-)
 rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (94%)
 rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h (97%)

-- 
1.9.1

[PATCH v7 2/9] arm: omap: timer: Wrap the inline functions under OMAP2PLUS define

[Keerthy]

Wrap the inline functions under OMAP2PLUS/OMAP1 defines.

Signed-off-by: Keerthy 
Tested-by: Ladislav Michl 
---
 arch/arm/plat-omap/include/plat/dmtimer.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index dd79f30..862ad62 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -276,6 +276,12 @@ struct omap_dm_timer {
 #define OMAP_TIMER_TICK_INT_MASK_COUNT_REG \
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR << WPSHIFT))
 
+/*
+ * The below are inlined to optimize code size for system timers. Other code
+ * should not need these at all, see
+ * include/linux/platform_data/pwm_omap_dmtimer.h
+ */
+#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2PLUS)
 static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg,
int posted)
 {
@@ -414,5 +420,5 @@ static inline void __omap_dm_timer_write_status(struct 
omap_dm_timer *timer,
 {
writel_relaxed(value, timer->irq_stat);
 }
-
+#endif /* CONFIG_ARCH_OMAP1 || CONFIG_ARCH_OMAP2PLUS */
 #endif /* __ASM_ARCH_DMTIMER_H */
-- 
1.9.1

[PATCH v7 7/9] clocksource: timer-dm: Hook device platform data if not already assigned

[Keerthy]

From: Ladislav Michl 

In the case of device tree boot the device platform data is usually
NULL so hook the platform data obtained from the match.
As part of un-constify the platform_data pointer.

Signed-off-by: Ladislav Michl 
Signed-off-by: Keerthy 
---
 drivers/clocksource/timer-dm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index 1cbd954..60db173 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -806,14 +806,16 @@ static int omap_dm_timer_probe(struct platform_device 
*pdev)
struct omap_dm_timer *timer;
struct resource *mem, *irq;
struct device *dev = >dev;
-   const struct of_device_id *match;
const struct dmtimer_platform_data *pdata;
int ret;
 
-   match = of_match_device(of_match_ptr(omap_timer_match), dev);
-   pdata = match ? match->data : dev->platform_data;
+   pdata = of_device_get_match_data(dev);
+   if (!pdata)
+   pdata = dev_get_platdata(dev);
+   else
+   dev->platform_data = (void *)pdata;
 
-   if (!pdata && !dev->of_node) {
+   if (!pdata) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
-- 
1.9.1

[PATCH v7 7/9] clocksource: timer-dm: Hook device platform data if not already assigned

[Keerthy]

From: Ladislav Michl 

In the case of device tree boot the device platform data is usually
NULL so hook the platform data obtained from the match.
As part of un-constify the platform_data pointer.

Signed-off-by: Ladislav Michl 
Signed-off-by: Keerthy 
---
 drivers/clocksource/timer-dm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index 1cbd954..60db173 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -806,14 +806,16 @@ static int omap_dm_timer_probe(struct platform_device 
*pdev)
struct omap_dm_timer *timer;
struct resource *mem, *irq;
struct device *dev = >dev;
-   const struct of_device_id *match;
const struct dmtimer_platform_data *pdata;
int ret;
 
-   match = of_match_device(of_match_ptr(omap_timer_match), dev);
-   pdata = match ? match->data : dev->platform_data;
+   pdata = of_device_get_match_data(dev);
+   if (!pdata)
+   pdata = dev_get_platdata(dev);
+   else
+   dev->platform_data = (void *)pdata;
 
-   if (!pdata && !dev->of_node) {
+   if (!pdata) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
-- 
1.9.1

[PATCH net-next 1/2] Revert "net: hns3: Add packet statistics of netdev"

[Peng Li]

This reverts commit 8491000754796c838a0081c267f9dd54ad2ccba3.

It is duplicate to add statistics of netdev for ethtool -S.

Signed-off-by: Peng Li 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 80 +-
 1 file changed, 1 insertion(+), 79 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 1e8fac3..d3cb3ec 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -59,41 +59,6 @@ struct hns3_stats {
 
 #define HNS3_TQP_STATS_COUNT (HNS3_TXQ_STATS_COUNT + HNS3_RXQ_STATS_COUNT)
 
-/* netdev stats */
-#define HNS3_NETDEV_STAT(_string, _member) {   \
-   .stats_string = _string,\
-   .stats_offset = offsetof(struct rtnl_link_stats64, _member) \
-}
-
-static const struct hns3_stats hns3_netdev_stats[] = {
-   /* Rx per-queue statistics */
-   HNS3_NETDEV_STAT("rx_packets", rx_packets),
-   HNS3_NETDEV_STAT("tx_packets", tx_packets),
-   HNS3_NETDEV_STAT("rx_bytes", rx_bytes),
-   HNS3_NETDEV_STAT("tx_bytes", tx_bytes),
-   HNS3_NETDEV_STAT("rx_errors", rx_errors),
-   HNS3_NETDEV_STAT("tx_errors", tx_errors),
-   HNS3_NETDEV_STAT("rx_dropped", rx_dropped),
-   HNS3_NETDEV_STAT("tx_dropped", tx_dropped),
-   HNS3_NETDEV_STAT("multicast", multicast),
-   HNS3_NETDEV_STAT("collisions", collisions),
-   HNS3_NETDEV_STAT("rx_length_errors", rx_length_errors),
-   HNS3_NETDEV_STAT("rx_over_errors", rx_over_errors),
-   HNS3_NETDEV_STAT("rx_crc_errors", rx_crc_errors),
-   HNS3_NETDEV_STAT("rx_frame_errors", rx_frame_errors),
-   HNS3_NETDEV_STAT("rx_fifo_errors", rx_fifo_errors),
-   HNS3_NETDEV_STAT("rx_missed_errors", rx_missed_errors),
-   HNS3_NETDEV_STAT("tx_aborted_errors", tx_aborted_errors),
-   HNS3_NETDEV_STAT("tx_carrier_errors", tx_carrier_errors),
-   HNS3_NETDEV_STAT("tx_fifo_errors", tx_fifo_errors),
-   HNS3_NETDEV_STAT("tx_heartbeat_errors", tx_heartbeat_errors),
-   HNS3_NETDEV_STAT("tx_window_errors", tx_window_errors),
-   HNS3_NETDEV_STAT("rx_compressed", rx_compressed),
-   HNS3_NETDEV_STAT("tx_compressed", tx_compressed),
-};
-
-#define HNS3_NETDEV_STATS_COUNT ARRAY_SIZE(hns3_netdev_stats)
-
 #define HNS3_SELF_TEST_TPYE_NUM1
 #define HNS3_NIC_LB_TEST_PKT_NUM   1
 #define HNS3_NIC_LB_TEST_RING_ID   0
@@ -466,27 +431,6 @@ static u8 *hns3_get_strings_tqps(struct hnae3_handle 
*handle, u8 *data)
return data;
 }
 
-static u8 *hns3_netdev_stats_get_strings(u8 *data)
-{
-   int i;
-
-   /* get strings for netdev */
-   for (i = 0; i < HNS3_NETDEV_STATS_COUNT; i++) {
-   snprintf(data, ETH_GSTRING_LEN,
-hns3_netdev_stats[i].stats_string);
-   data += ETH_GSTRING_LEN;
-   }
-
-   snprintf(data, ETH_GSTRING_LEN, "netdev_rx_dropped");
-   data += ETH_GSTRING_LEN;
-   snprintf(data, ETH_GSTRING_LEN, "netdev_tx_dropped");
-   data += ETH_GSTRING_LEN;
-   snprintf(data, ETH_GSTRING_LEN, "netdev_tx_timeout");
-   data += ETH_GSTRING_LEN;
-
-   return data;
-}
-
 static void hns3_get_strings(struct net_device *netdev, u32 stringset, u8 
*data)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -498,7 +442,6 @@ static void hns3_get_strings(struct net_device *netdev, u32 
stringset, u8 *data)
 
switch (stringset) {
case ETH_SS_STATS:
-   buff = hns3_netdev_stats_get_strings(buff);
buff = hns3_get_strings_tqps(h, buff);
h->ae_algo->ops->get_strings(h, stringset, (u8 *)buff);
break;
@@ -537,27 +480,6 @@ static u64 *hns3_get_stats_tqps(struct hnae3_handle 
*handle, u64 *data)
return data;
 }
 
-static u64 *hns3_get_netdev_stats(struct net_device *netdev, u64 *data)
-{
-   struct hns3_nic_priv *priv = netdev_priv(netdev);
-   const struct rtnl_link_stats64 *net_stats;
-   struct rtnl_link_stats64 temp;
-   u8 *stat;
-   int i;
-
-   net_stats = dev_get_stats(netdev, );
-   for (i = 0; i < HNS3_NETDEV_STATS_COUNT; i++) {
-   stat = (u8 *)net_stats + hns3_netdev_stats[i].stats_offset;
-   *data++ = *(u64 *)stat;
-   }
-
-   *data++ = netdev->rx_dropped.counter;
-   *data++ = netdev->tx_dropped.counter;
-   *data++ = priv->tx_timeout_count;
-
-   return data;
-}
-
 /* hns3_get_stats - get detail statistics.
  * @netdev: net device
  * @stats: statistics info.
@@ -574,7 +496,7 @@ static void hns3_get_stats(struct net_device *netdev,
return;
}
 
-   p = hns3_get_netdev_stats(netdev, p);
+   h->ae_algo->ops->update_stats(h, >stats);
 
/* get per-queue stats */
p = hns3_get_stats_tqps(h, p);
-- 
1.9.1

[PATCH net-next 2/2] net: hns3: report the function type the same line with hns3_nic_get_stats64

[Peng Li]

The function type should be on the same line with the function
name, or it may cause display error if a patch edit the
function. There is am example following:
https://www.spinics.net/lists/netdev/msg476141.html

Signed-off-by: Peng Li 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index b23107d..14c7625 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1126,8 +1126,8 @@ static int hns3_nic_set_features(struct net_device 
*netdev,
return 0;
 }
 
-static void
-hns3_nic_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 
*stats)
+static void hns3_nic_get_stats64(struct net_device *netdev,
+struct rtnl_link_stats64 *stats)
 {
struct hns3_nic_priv *priv = netdev_priv(netdev);
int queue_num = priv->ae_handle->kinfo.num_tqps;
-- 
1.9.1

[PATCH net-next 1/2] Revert "net: hns3: Add packet statistics of netdev"

[Peng Li]

This reverts commit 8491000754796c838a0081c267f9dd54ad2ccba3.

It is duplicate to add statistics of netdev for ethtool -S.

Signed-off-by: Peng Li 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 80 +-
 1 file changed, 1 insertion(+), 79 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 1e8fac3..d3cb3ec 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -59,41 +59,6 @@ struct hns3_stats {
 
 #define HNS3_TQP_STATS_COUNT (HNS3_TXQ_STATS_COUNT + HNS3_RXQ_STATS_COUNT)
 
-/* netdev stats */
-#define HNS3_NETDEV_STAT(_string, _member) {   \
-   .stats_string = _string,\
-   .stats_offset = offsetof(struct rtnl_link_stats64, _member) \
-}
-
-static const struct hns3_stats hns3_netdev_stats[] = {
-   /* Rx per-queue statistics */
-   HNS3_NETDEV_STAT("rx_packets", rx_packets),
-   HNS3_NETDEV_STAT("tx_packets", tx_packets),
-   HNS3_NETDEV_STAT("rx_bytes", rx_bytes),
-   HNS3_NETDEV_STAT("tx_bytes", tx_bytes),
-   HNS3_NETDEV_STAT("rx_errors", rx_errors),
-   HNS3_NETDEV_STAT("tx_errors", tx_errors),
-   HNS3_NETDEV_STAT("rx_dropped", rx_dropped),
-   HNS3_NETDEV_STAT("tx_dropped", tx_dropped),
-   HNS3_NETDEV_STAT("multicast", multicast),
-   HNS3_NETDEV_STAT("collisions", collisions),
-   HNS3_NETDEV_STAT("rx_length_errors", rx_length_errors),
-   HNS3_NETDEV_STAT("rx_over_errors", rx_over_errors),
-   HNS3_NETDEV_STAT("rx_crc_errors", rx_crc_errors),
-   HNS3_NETDEV_STAT("rx_frame_errors", rx_frame_errors),
-   HNS3_NETDEV_STAT("rx_fifo_errors", rx_fifo_errors),
-   HNS3_NETDEV_STAT("rx_missed_errors", rx_missed_errors),
-   HNS3_NETDEV_STAT("tx_aborted_errors", tx_aborted_errors),
-   HNS3_NETDEV_STAT("tx_carrier_errors", tx_carrier_errors),
-   HNS3_NETDEV_STAT("tx_fifo_errors", tx_fifo_errors),
-   HNS3_NETDEV_STAT("tx_heartbeat_errors", tx_heartbeat_errors),
-   HNS3_NETDEV_STAT("tx_window_errors", tx_window_errors),
-   HNS3_NETDEV_STAT("rx_compressed", rx_compressed),
-   HNS3_NETDEV_STAT("tx_compressed", tx_compressed),
-};
-
-#define HNS3_NETDEV_STATS_COUNT ARRAY_SIZE(hns3_netdev_stats)
-
 #define HNS3_SELF_TEST_TPYE_NUM1
 #define HNS3_NIC_LB_TEST_PKT_NUM   1
 #define HNS3_NIC_LB_TEST_RING_ID   0
@@ -466,27 +431,6 @@ static u8 *hns3_get_strings_tqps(struct hnae3_handle 
*handle, u8 *data)
return data;
 }
 
-static u8 *hns3_netdev_stats_get_strings(u8 *data)
-{
-   int i;
-
-   /* get strings for netdev */
-   for (i = 0; i < HNS3_NETDEV_STATS_COUNT; i++) {
-   snprintf(data, ETH_GSTRING_LEN,
-hns3_netdev_stats[i].stats_string);
-   data += ETH_GSTRING_LEN;
-   }
-
-   snprintf(data, ETH_GSTRING_LEN, "netdev_rx_dropped");
-   data += ETH_GSTRING_LEN;
-   snprintf(data, ETH_GSTRING_LEN, "netdev_tx_dropped");
-   data += ETH_GSTRING_LEN;
-   snprintf(data, ETH_GSTRING_LEN, "netdev_tx_timeout");
-   data += ETH_GSTRING_LEN;
-
-   return data;
-}
-
 static void hns3_get_strings(struct net_device *netdev, u32 stringset, u8 
*data)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -498,7 +442,6 @@ static void hns3_get_strings(struct net_device *netdev, u32 
stringset, u8 *data)
 
switch (stringset) {
case ETH_SS_STATS:
-   buff = hns3_netdev_stats_get_strings(buff);
buff = hns3_get_strings_tqps(h, buff);
h->ae_algo->ops->get_strings(h, stringset, (u8 *)buff);
break;
@@ -537,27 +480,6 @@ static u64 *hns3_get_stats_tqps(struct hnae3_handle 
*handle, u64 *data)
return data;
 }
 
-static u64 *hns3_get_netdev_stats(struct net_device *netdev, u64 *data)
-{
-   struct hns3_nic_priv *priv = netdev_priv(netdev);
-   const struct rtnl_link_stats64 *net_stats;
-   struct rtnl_link_stats64 temp;
-   u8 *stat;
-   int i;
-
-   net_stats = dev_get_stats(netdev, );
-   for (i = 0; i < HNS3_NETDEV_STATS_COUNT; i++) {
-   stat = (u8 *)net_stats + hns3_netdev_stats[i].stats_offset;
-   *data++ = *(u64 *)stat;
-   }
-
-   *data++ = netdev->rx_dropped.counter;
-   *data++ = netdev->tx_dropped.counter;
-   *data++ = priv->tx_timeout_count;
-
-   return data;
-}
-
 /* hns3_get_stats - get detail statistics.
  * @netdev: net device
  * @stats: statistics info.
@@ -574,7 +496,7 @@ static void hns3_get_stats(struct net_device *netdev,
return;
}
 
-   p = hns3_get_netdev_stats(netdev, p);
+   h->ae_algo->ops->update_stats(h, >stats);
 
/* get per-queue stats */
p = hns3_get_stats_tqps(h, p);
-- 
1.9.1

[PATCH net-next 2/2] net: hns3: report the function type the same line with hns3_nic_get_stats64

[Peng Li]

The function type should be on the same line with the function
name, or it may cause display error if a patch edit the
function. There is am example following:
https://www.spinics.net/lists/netdev/msg476141.html

Signed-off-by: Peng Li 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index b23107d..14c7625 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1126,8 +1126,8 @@ static int hns3_nic_set_features(struct net_device 
*netdev,
return 0;
 }
 
-static void
-hns3_nic_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 
*stats)
+static void hns3_nic_get_stats64(struct net_device *netdev,
+struct rtnl_link_stats64 *stats)
 {
struct hns3_nic_priv *priv = netdev_priv(netdev);
int queue_num = priv->ae_handle->kinfo.num_tqps;
-- 
1.9.1

[PATCH net-next 0/2] code improvements in HNS3 driver

[Peng Li]

This patchset fixes 2 comments for community review.
[patch 1/2] reverts "net: hns3: Add packet statistics of netdev"
reported by Jakub Kicinski and David Miller.
[patch 2/2] reports the function type the same line with
hns3_nic_get_stats64, reported by Andrew Lunn.

Peng Li (2):
  Revert "net: hns3: Add packet statistics of netdev"
  net: hns3: report the function type the same line with
hns3_nic_get_stats64

 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  4 +-
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 80 +-
 2 files changed, 3 insertions(+), 81 deletions(-)

-- 
1.9.1

[PATCH net-next 0/2] code improvements in HNS3 driver

[Peng Li]

This patchset fixes 2 comments for community review.
[patch 1/2] reverts "net: hns3: Add packet statistics of netdev"
reported by Jakub Kicinski and David Miller.
[patch 2/2] reports the function type the same line with
hns3_nic_get_stats64, reported by Andrew Lunn.

Peng Li (2):
  Revert "net: hns3: Add packet statistics of netdev"
  net: hns3: report the function type the same line with
hns3_nic_get_stats64

 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  4 +-
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 80 +-
 2 files changed, 3 insertions(+), 81 deletions(-)

-- 
1.9.1

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[Randy Dunlap]

On 01/08/18 19:13, shufan_lee(李書帆) wrote:
> From: ShuFan Lee 
> 
> Richtek RT1711H Type-C chip driver that works with
> Type-C Port Controller Manager to provide USB PD and
> USB Type-C functionalities.
> 
> Signed-off-by: ShuFan Lee 
> ---​
> 
> Documentation/devicetree/bindings/usb/richtek,rt1711h.txt |   38
> arch/arm64/boot/dts/hisilicon/rt1711h.dtsi|   11
> drivers/usb/typec/Kconfig |2
> drivers/usb/typec/Makefile|1
> drivers/usb/typec/rt1711h/Kconfig |7
> drivers/usb/typec/rt1711h/Makefile|2
> drivers/usb/typec/rt1711h/rt1711h.c   | 2241 ++
> drivers/usb/typec/rt1711h/rt1711h.h   |  300 +
> 8 files changed, 2602 insertions(+)

Hi,
It looks like your mail client or your mail server (or something else)
ate all of the tabs that would make this patch look normal.

When you have that fixed, I guess that you should also Cc: the linux-usb
mailing list with the patch.

Thanks.

> * Email Confidentiality Notice 
> 
> The information contained in this e-mail message (including any attachments) 
> may be confidential, proprietary, privileged, or otherwise exempt from 
> disclosure under applicable laws. It is intended to be conveyed only to the 
> designated recipient(s). Any use, dissemination, distribution, printing, 
> retaining or copying of this e-mail (including its attachments) by unintended 
> recipient(s) is strictly prohibited and may be unlawful. If you are not an 
> intended recipient of this e-mail, or believe that you have received this 
> e-mail in error, please notify the sender immediately (by replying to this 
> e-mail), delete any and all copies of this e-mail (including any attachments) 
> from your system, and do not disclose the content of this e-mail to any other 
> person. Thank you!
> 


-- 
~Randy

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

[Baoquan He]

On 01/06/18 at 02:00am, Jiri Bohac wrote:
> Hi Baoquan,
> 
> thank you very much for your review!
> 
> On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote:
> > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it
> > > > will ignore the ram we need dump.
> > > 
> > > yes, instead of crashing the machine (because GART may be initialized in 
> > > the
> > > 2nd kernel, overlapping the 1st kernel memory, which the 2nd kernel with 
> > > its
> > > fake e820 map sees as unused).
> > > 
> > > I'd say this is an improvement.
> > 
> > I don't get what you said. If 'iommu=off' only specified in 1st kernel,
> > kdump kernel will think the memory which GART bar pointed as a hole.
> > This is incorrect. I don't see the improvement.
> 
> Without the patch, the kernel will crash/hang the machine, as it
> will (correctly) try to dump the first kernel's memory that is
> now mapped by the GART.
> 
> With the patch it will produce a dump with the data missing.
> But this is just a corner case, I don't see why someone would
> specify iommu=off in the first kernel and not the second.
> 
> So instead of crashing and producing no dump at all, we get a
> dump with some data possibly missing.
> 
> > I understand you could get a bug report from other people, and have to
> > fix it as an assignee. And this fix is located in aperture_64.c only,
> > I am fine it's done like this. Maybe you can try the way I suggested
> > that only removing the region from io resource, but not touching anything
> > else, if you have interest.
> > 
> > So if have to, could you add some code comments around your fix to notice
> > people why these code are introduced? Commit log can help to understand
> > added code, while sometime file moving may make this checking very hard.
> 
> Sure, the full patch with comments added is below. Do the
> comments make sense? Do you want me to re-post it as v3?:
> 
> ---
> On machines where the GART aperture is mapped over physical RAM
> /proc/vmcore contains the remapped range and reading it may
> cause hangs or reboots. 
> 
> In the past, the GART region was added into the resource map, implemented by
> commit 56dd669a138c ("[PATCH] Insert GART region into resource map")
> 
> However, inserting the iomem_resource from the early GART code caused
> resource conflicts with some AGP drivers (bko#72201), which got avoided by
> reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART
> region into resource map"). This revert introduced the /proc/vmcore bug.
> 
> The vmcore ELF header is either prepared by the kernel (when using the
> kexec_file_load syscall) or by the kexec userspace (when using the kexec_load
> syscall). Since we no longer have the GART iomem resource, the userspace
> kexec has no way of knowing which region to exclude from the ELF header.
> 
> Changes from v1 of this patch:
> Instead of excluding the aperture from the ELF header, this patch
> makes /proc/vmcore return zeroes in the second kernel when attempting to
> read the aperture region. This is done by reusing the
> gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN
> balooned memory. This works for both, the kexec_file_load and kexec_load
> syscalls.
> 
> [Note that the GART region is the same in the first and second kernels:
> regardless whether the first kernel fixed up the northbridge/bios setting
> and mapped the aperture over physical memory, the second kernel finds the
> northbridge properly configured by the first kernel and the aperture
> never overlaps with e820 memory because the second kernel has a fake e820
> map created from the crashkernel memory regions. Thus, the second kernel
> keeps the aperture address/size as configured by the first kernel.]
> 
> register_oldmem_pfn_is_ram can only register one callback and returns an error
> if the callback has been registered already. Since XEN used to be the only 
> user
> of this function, it never checks the return value. Now that we have more than
> one user, I added a WARN_ON just in case agp, XEN, or any other future user of
> register_oldmem_pfn_is_ram were to step on each other's toes.
> 
> 
> Signed-off-by: Jiri Bohac 
> Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")

I am fine. There's no git branch for kdump since changes related
usually scatter in all components. For this one, you can post a new one
and send to Joerg since he maintains iommu code. And Andrew, he usually
helps to pick kdump kernel changes to his akpm tree.

Thanks
Baoquan

> 
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index f5d92bc3b884..2c4d5ece7456 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Using 512M as goal, in case kexec will load kernel_big
> @@ -56,6 +57,33 @@ int fallback_aper_force __initdata;
>  
>  int fix_aperture __initdata = 1;
> 

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[Randy Dunlap]

On 01/08/18 19:13, shufan_lee(李書帆) wrote:
> From: ShuFan Lee 
> 
> Richtek RT1711H Type-C chip driver that works with
> Type-C Port Controller Manager to provide USB PD and
> USB Type-C functionalities.
> 
> Signed-off-by: ShuFan Lee 
> ---​
> 
> Documentation/devicetree/bindings/usb/richtek,rt1711h.txt |   38
> arch/arm64/boot/dts/hisilicon/rt1711h.dtsi|   11
> drivers/usb/typec/Kconfig |2
> drivers/usb/typec/Makefile|1
> drivers/usb/typec/rt1711h/Kconfig |7
> drivers/usb/typec/rt1711h/Makefile|2
> drivers/usb/typec/rt1711h/rt1711h.c   | 2241 ++
> drivers/usb/typec/rt1711h/rt1711h.h   |  300 +
> 8 files changed, 2602 insertions(+)

Hi,
It looks like your mail client or your mail server (or something else)
ate all of the tabs that would make this patch look normal.

When you have that fixed, I guess that you should also Cc: the linux-usb
mailing list with the patch.

Thanks.

> * Email Confidentiality Notice 
> 
> The information contained in this e-mail message (including any attachments) 
> may be confidential, proprietary, privileged, or otherwise exempt from 
> disclosure under applicable laws. It is intended to be conveyed only to the 
> designated recipient(s). Any use, dissemination, distribution, printing, 
> retaining or copying of this e-mail (including its attachments) by unintended 
> recipient(s) is strictly prohibited and may be unlawful. If you are not an 
> intended recipient of this e-mail, or believe that you have received this 
> e-mail in error, please notify the sender immediately (by replying to this 
> e-mail), delete any and all copies of this e-mail (including any attachments) 
> from your system, and do not disclose the content of this e-mail to any other 
> person. Thank you!
> 


-- 
~Randy

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

[Baoquan He]

On 01/06/18 at 02:00am, Jiri Bohac wrote:
> Hi Baoquan,
> 
> thank you very much for your review!
> 
> On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote:
> > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it
> > > > will ignore the ram we need dump.
> > > 
> > > yes, instead of crashing the machine (because GART may be initialized in 
> > > the
> > > 2nd kernel, overlapping the 1st kernel memory, which the 2nd kernel with 
> > > its
> > > fake e820 map sees as unused).
> > > 
> > > I'd say this is an improvement.
> > 
> > I don't get what you said. If 'iommu=off' only specified in 1st kernel,
> > kdump kernel will think the memory which GART bar pointed as a hole.
> > This is incorrect. I don't see the improvement.
> 
> Without the patch, the kernel will crash/hang the machine, as it
> will (correctly) try to dump the first kernel's memory that is
> now mapped by the GART.
> 
> With the patch it will produce a dump with the data missing.
> But this is just a corner case, I don't see why someone would
> specify iommu=off in the first kernel and not the second.
> 
> So instead of crashing and producing no dump at all, we get a
> dump with some data possibly missing.
> 
> > I understand you could get a bug report from other people, and have to
> > fix it as an assignee. And this fix is located in aperture_64.c only,
> > I am fine it's done like this. Maybe you can try the way I suggested
> > that only removing the region from io resource, but not touching anything
> > else, if you have interest.
> > 
> > So if have to, could you add some code comments around your fix to notice
> > people why these code are introduced? Commit log can help to understand
> > added code, while sometime file moving may make this checking very hard.
> 
> Sure, the full patch with comments added is below. Do the
> comments make sense? Do you want me to re-post it as v3?:
> 
> ---
> On machines where the GART aperture is mapped over physical RAM
> /proc/vmcore contains the remapped range and reading it may
> cause hangs or reboots. 
> 
> In the past, the GART region was added into the resource map, implemented by
> commit 56dd669a138c ("[PATCH] Insert GART region into resource map")
> 
> However, inserting the iomem_resource from the early GART code caused
> resource conflicts with some AGP drivers (bko#72201), which got avoided by
> reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART
> region into resource map"). This revert introduced the /proc/vmcore bug.
> 
> The vmcore ELF header is either prepared by the kernel (when using the
> kexec_file_load syscall) or by the kexec userspace (when using the kexec_load
> syscall). Since we no longer have the GART iomem resource, the userspace
> kexec has no way of knowing which region to exclude from the ELF header.
> 
> Changes from v1 of this patch:
> Instead of excluding the aperture from the ELF header, this patch
> makes /proc/vmcore return zeroes in the second kernel when attempting to
> read the aperture region. This is done by reusing the
> gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN
> balooned memory. This works for both, the kexec_file_load and kexec_load
> syscalls.
> 
> [Note that the GART region is the same in the first and second kernels:
> regardless whether the first kernel fixed up the northbridge/bios setting
> and mapped the aperture over physical memory, the second kernel finds the
> northbridge properly configured by the first kernel and the aperture
> never overlaps with e820 memory because the second kernel has a fake e820
> map created from the crashkernel memory regions. Thus, the second kernel
> keeps the aperture address/size as configured by the first kernel.]
> 
> register_oldmem_pfn_is_ram can only register one callback and returns an error
> if the callback has been registered already. Since XEN used to be the only 
> user
> of this function, it never checks the return value. Now that we have more than
> one user, I added a WARN_ON just in case agp, XEN, or any other future user of
> register_oldmem_pfn_is_ram were to step on each other's toes.
> 
> 
> Signed-off-by: Jiri Bohac 
> Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")

I am fine. There's no git branch for kdump since changes related
usually scatter in all components. For this one, you can post a new one
and send to Joerg since he maintains iommu code. And Andrew, he usually
helps to pick kdump kernel changes to his akpm tree.

Thanks
Baoquan

> 
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index f5d92bc3b884..2c4d5ece7456 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Using 512M as goal, in case kexec will load kernel_big
> @@ -56,6 +57,33 @@ int fallback_aper_force __initdata;
>  
>  int fix_aperture __initdata = 1;
>  
> +#ifdef 

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

[Du, Changbin]

On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote:
> On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote:
> > Hi Olsa,
> > What about this fix now? Thanks!
> > 
> > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> > > From: Changbin Du 
> > > 
> > > The terminal character '\0' should take into account as size of the string
> > > buffer. Without this fix, the '--graph-funcs', '--nograph-funcs' and
> > > '--trace-funcs' options didn't work as expected when the  doesn't
> > > exist.
> > > 
> > > I didn't dive into kernel ftrace fops, but strace shows that if usersapce
> > > writes a non-terminated string, the kernel side will return success but
> > > no filter applied. After this fix in userspace, the kernel will return an
> > > error.
> > > 
> > > $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg
> > >  0)   0.140 us|  rcu_all_qs();
> > >  3)   0.304 us|  mutex_unlock();
> > >  0)   0.153 us|  find_vma();
> > >  3)   0.088 us|  __fsnotify_parent();
> > >  0)   6.145 us|  handle_mm_fault();
> > >  3)   0.089 us|  fsnotify();
> > >  3)   0.161 us|  __sb_end_write();
> > >  3)   0.710 us|  SyS_close();
> > >  3)   7.848 us|  exit_to_usermode_loop();
> > > 
> > > On above example, I specified function filter 'abcdefg' but all functions
> > > are enabled.
> 
> hum, haven't checked, but looks like the filter is not working at all now:
> 
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs 
> proc_sys_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs SyS_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs fsnotify
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
>
Thanks for your test. I forgot to test normal case and thought the err is 
expected...

This time I dived into kernel side, and found 3 issues (if I am all right) at 
the
kernel function trace_get_user(). This function has problems to process both 
complete
C string or not.

I will send the kernel patches and Cc you guys. And I still think it is better
let perf write a complete C string.

Thanks!
Changbin Du

> jirka
>
[...] 

Re: [PATCH] perf ftrace: Fix the buffer size in __write_tracing_file

[Du, Changbin]

On Mon, Jan 08, 2018 at 03:34:57PM +0100, Jiri Olsa wrote:
> On Mon, Jan 08, 2018 at 11:05:12AM +0800, Du, Changbin wrote:
> > Hi Olsa,
> > What about this fix now? Thanks!
> > 
> > On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> > > From: Changbin Du 
> > > 
> > > The terminal character '\0' should take into account as size of the string
> > > buffer. Without this fix, the '--graph-funcs', '--nograph-funcs' and
> > > '--trace-funcs' options didn't work as expected when the  doesn't
> > > exist.
> > > 
> > > I didn't dive into kernel ftrace fops, but strace shows that if usersapce
> > > writes a non-terminated string, the kernel side will return success but
> > > no filter applied. After this fix in userspace, the kernel will return an
> > > error.
> > > 
> > > $ sudo ./perf ftrace -a --graph-depth 1 --graph-funcs abcdefg
> > >  0)   0.140 us|  rcu_all_qs();
> > >  3)   0.304 us|  mutex_unlock();
> > >  0)   0.153 us|  find_vma();
> > >  3)   0.088 us|  __fsnotify_parent();
> > >  0)   6.145 us|  handle_mm_fault();
> > >  3)   0.089 us|  fsnotify();
> > >  3)   0.161 us|  __sb_end_write();
> > >  3)   0.710 us|  SyS_close();
> > >  3)   7.848 us|  exit_to_usermode_loop();
> > > 
> > > On above example, I specified function filter 'abcdefg' but all functions
> > > are enabled.
> 
> hum, haven't checked, but looks like the filter is not working at all now:
> 
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs 
> proc_sys_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs SyS_read
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
> [root@krava perf]# ./perf ftrace -vv -a --graph-depth 1 --graph-funcs fsnotify
> write ' ' to tracing/set_ftrace_pid failed: Invalid argument
>
Thanks for your test. I forgot to test normal case and thought the err is 
expected...

This time I dived into kernel side, and found 3 issues (if I am all right) at 
the
kernel function trace_get_user(). This function has problems to process both 
complete
C string or not.

I will send the kernel patches and Cc you guys. And I still think it is better
let perf write a complete C string.

Thanks!
Changbin Du

> jirka
>
[...] 

Re: [PATCH V2 1/5] bindings: regulator: added support for suspend states

[Chunyan Zhang]

On 8 January 2018 at 20:35, Mark Brown  wrote:
> On Mon, Jan 08, 2018 at 02:36:36PM +0800, Chunyan Zhang wrote:
>> On 6 January 2018 at 03:18, Mark Brown  wrote:
>
>> > No, it means that the software has permission to use those changes to
>> > those registers - we only want to be changing things if the user has
>> > permission to change them since some systems will have specific
>> > constraints, we don't know if it's safe without being explicitly told.
>> > You're right that we could infer this from a range being provided
>> > though, let's do that.
>
>> Ok, so we don't need this property IIUC, and instead we just need to check
>> if the regulator-suspend-min-microvolt and regulator-suspend-max-microvolt
>> are set to the same value, right?
>
> Yes.

Then, do we need a flag as well to give permission to change
'suspend_state->enabled'?

Or we just do keeping the regulator device enabled if any consumer of
it has set voltage for suspend mode with non-zero value, and do
switching it off if all consumers of it have set voltage for suspend
with zero.

+static int _regulator_set_suspend_voltage(struct regulator *regulator,
+ int min_uV, int max_uV,
+ suspend_state_t state)
+{
+   int ret;
+   struct regulator_dev *rdev = regulator->rdev;
+
+   /*
+* We assume users want to switch off the regulator device for
+* suspend state when setting min_uV and max_uV all with zero.
+*/
+   if (min_uV == 0 && max_uV == 0) {
+   regulator->voltage[state].min_uV = 0;
+   regulator->voltage[state].max_uV = 0;
+   return regulator_suspend_disable(rdev, state);
+   }
+
+   ret = regulator_suspend_enable(rdev, state);
+   if (ret < 0)
+   return ret;
+
+   return regulator_set_voltage_unlocked(regulator, min_uV, max_uV, state);
+}

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

[Ulf Hansson]

On 3 January 2018 at 12:06, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> One of the limitations of pm_runtime_force_suspend/resume() is that
> if a parent driver wants to use these functions, all of its child
> drivers have to do that too because of the parent usage counter
> manipulations necessary to get the correct state of the parent during
> system-wide transitions to the working state (system resume).

I understand your point, however this isn't describing the full story,
because there are a some more alternatives when
pm_runtime_force_suspend|resume() works well, when used for parent
devices. Let me clarify, just to make sure we get this correct.

1) If the child device isn't managed by runtime PM at all (it always
has runtime PM disabled), pm_runtime_force_suspend|resume() can be
used for the parent device. This works because the runtime PM status
if the child remains in the default status, RPM_SUSPENDED.

2) If, somehow, during system suspend/resume, the driver for the child
make sure to synchronize the runtime PM status of the child device,
according to the state of the HW, this should work too.

I leave it to you how to take this fact into consideration, if and how
to update the changelog.

> However, that limitation turns out to be artificial, so remove it.

Agree!

>
> Namely, pm_runtime_force_suspend() only needs to update the children
> counter of its parent (if there's is a parent) when the device can
> stay in suspend after the subsequent system resume transition, as
> that counter is correct already otherwise.  Now, if the parent's
> children counter is not updated, it is not necessary to increment
> the parent's usage counter in that case any more, as long as the
> children counters of devices are checked along with their usage
> counters in order to decide whether or not the devices may be left
> in suspend after the subsequent system resume transition.
>
> Accordingly, modify pm_runtime_force_suspend() to only call
> pm_runtime_set_suspended() for devices whose usage and children
> counters are at the "no references" level (the runtime PM status
> of the device needs to be updated to "suspended" anyway in case
> this function is called once again for the same device during the
> transition under way), drop the parent usage counter incrementation
> from it and update pm_runtime_force_resume() to compensate for these
> changes.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/base/power/runtime.c |   74 
> +++
>  1 file changed, 34 insertions(+), 40 deletions(-)
>
> Index: linux-pm/drivers/base/power/runtime.c
> ===
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -1613,17 +1613,28 @@ void pm_runtime_drop_link(struct device
> spin_unlock_irq(>power.lock);
>  }
>
> +static bool pm_runtime_need_not_resume(struct device *dev)
> +{
> +   return atomic_read(>power.usage_count) <= 1 &&
> +   atomic_read(>power.child_count) == 0;

We should take into account the ignore_children flag here, I think.
Something like this:

return atomic_read(>power.usage_count) <= 1 &&
(atomic_read(>power.child_count) == 0 ||
dev->power.ignore_children)

> +}
> +
>  /**
>   * pm_runtime_force_suspend - Force a device into suspend state if needed.
>   * @dev: Device to suspend.
>   *
>   * Disable runtime PM so we safely can check the device's runtime PM status 
> and
> - * if it is active, invoke it's .runtime_suspend callback to bring it into
> - * suspend state. Keep runtime PM disabled to preserve the state unless we
> - * encounter errors.
> + * if it is active, invoke its ->runtime_suspend callback to suspend it and
> + * change its runtime PM status field to RPM_SUSPENDED.  Also, if the 
> device's
> + * usage and children counters don't indicate that the device was in use 
> before
> + * the system-wide transition under way, decrement its parent's children 
> counter
> + * (if there is a parent).  Keep runtime PM disabled to preserve the state
> + * unless we encounter errors.
>   *
>   * Typically this function may be invoked from a system suspend callback to 
> make
> - * sure the device is put into low power state.
> + * sure the device is put into low power state and it should only be used 
> during
> + * system-wide PM transitions to sleep states.  It assumes that the analogous
> + * pm_runtime_force_resume() will be used to resume the device.
>   */
>  int pm_runtime_force_suspend(struct device *dev)
>  {
> @@ -1646,17 +1657,18 @@ int pm_runtime_force_suspend(struct devi
> goto err;
>
> /*
> -* Increase the runtime PM usage count for the device's parent, in 
> case
> -* when we find the device being used when system suspend was invoked.
> -* This informs pm_runtime_force_resume() to 

Re: [PATCH V2 1/5] bindings: regulator: added support for suspend states

[Chunyan Zhang]

On 8 January 2018 at 20:35, Mark Brown  wrote:
> On Mon, Jan 08, 2018 at 02:36:36PM +0800, Chunyan Zhang wrote:
>> On 6 January 2018 at 03:18, Mark Brown  wrote:
>
>> > No, it means that the software has permission to use those changes to
>> > those registers - we only want to be changing things if the user has
>> > permission to change them since some systems will have specific
>> > constraints, we don't know if it's safe without being explicitly told.
>> > You're right that we could infer this from a range being provided
>> > though, let's do that.
>
>> Ok, so we don't need this property IIUC, and instead we just need to check
>> if the regulator-suspend-min-microvolt and regulator-suspend-max-microvolt
>> are set to the same value, right?
>
> Yes.

Then, do we need a flag as well to give permission to change
'suspend_state->enabled'?

Or we just do keeping the regulator device enabled if any consumer of
it has set voltage for suspend mode with non-zero value, and do
switching it off if all consumers of it have set voltage for suspend
with zero.

+static int _regulator_set_suspend_voltage(struct regulator *regulator,
+ int min_uV, int max_uV,
+ suspend_state_t state)
+{
+   int ret;
+   struct regulator_dev *rdev = regulator->rdev;
+
+   /*
+* We assume users want to switch off the regulator device for
+* suspend state when setting min_uV and max_uV all with zero.
+*/
+   if (min_uV == 0 && max_uV == 0) {
+   regulator->voltage[state].min_uV = 0;
+   regulator->voltage[state].max_uV = 0;
+   return regulator_suspend_disable(rdev, state);
+   }
+
+   ret = regulator_suspend_enable(rdev, state);
+   if (ret < 0)
+   return ret;
+
+   return regulator_set_voltage_unlocked(regulator, min_uV, max_uV, state);
+}

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

[Ulf Hansson]

On 3 January 2018 at 12:06, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> One of the limitations of pm_runtime_force_suspend/resume() is that
> if a parent driver wants to use these functions, all of its child
> drivers have to do that too because of the parent usage counter
> manipulations necessary to get the correct state of the parent during
> system-wide transitions to the working state (system resume).

I understand your point, however this isn't describing the full story,
because there are a some more alternatives when
pm_runtime_force_suspend|resume() works well, when used for parent
devices. Let me clarify, just to make sure we get this correct.

1) If the child device isn't managed by runtime PM at all (it always
has runtime PM disabled), pm_runtime_force_suspend|resume() can be
used for the parent device. This works because the runtime PM status
if the child remains in the default status, RPM_SUSPENDED.

2) If, somehow, during system suspend/resume, the driver for the child
make sure to synchronize the runtime PM status of the child device,
according to the state of the HW, this should work too.

I leave it to you how to take this fact into consideration, if and how
to update the changelog.

> However, that limitation turns out to be artificial, so remove it.

Agree!

>
> Namely, pm_runtime_force_suspend() only needs to update the children
> counter of its parent (if there's is a parent) when the device can
> stay in suspend after the subsequent system resume transition, as
> that counter is correct already otherwise.  Now, if the parent's
> children counter is not updated, it is not necessary to increment
> the parent's usage counter in that case any more, as long as the
> children counters of devices are checked along with their usage
> counters in order to decide whether or not the devices may be left
> in suspend after the subsequent system resume transition.
>
> Accordingly, modify pm_runtime_force_suspend() to only call
> pm_runtime_set_suspended() for devices whose usage and children
> counters are at the "no references" level (the runtime PM status
> of the device needs to be updated to "suspended" anyway in case
> this function is called once again for the same device during the
> transition under way), drop the parent usage counter incrementation
> from it and update pm_runtime_force_resume() to compensate for these
> changes.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/base/power/runtime.c |   74 
> +++
>  1 file changed, 34 insertions(+), 40 deletions(-)
>
> Index: linux-pm/drivers/base/power/runtime.c
> ===
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -1613,17 +1613,28 @@ void pm_runtime_drop_link(struct device
> spin_unlock_irq(>power.lock);
>  }
>
> +static bool pm_runtime_need_not_resume(struct device *dev)
> +{
> +   return atomic_read(>power.usage_count) <= 1 &&
> +   atomic_read(>power.child_count) == 0;

We should take into account the ignore_children flag here, I think.
Something like this:

return atomic_read(>power.usage_count) <= 1 &&
(atomic_read(>power.child_count) == 0 ||
dev->power.ignore_children)

> +}
> +
>  /**
>   * pm_runtime_force_suspend - Force a device into suspend state if needed.
>   * @dev: Device to suspend.
>   *
>   * Disable runtime PM so we safely can check the device's runtime PM status 
> and
> - * if it is active, invoke it's .runtime_suspend callback to bring it into
> - * suspend state. Keep runtime PM disabled to preserve the state unless we
> - * encounter errors.
> + * if it is active, invoke its ->runtime_suspend callback to suspend it and
> + * change its runtime PM status field to RPM_SUSPENDED.  Also, if the 
> device's
> + * usage and children counters don't indicate that the device was in use 
> before
> + * the system-wide transition under way, decrement its parent's children 
> counter
> + * (if there is a parent).  Keep runtime PM disabled to preserve the state
> + * unless we encounter errors.
>   *
>   * Typically this function may be invoked from a system suspend callback to 
> make
> - * sure the device is put into low power state.
> + * sure the device is put into low power state and it should only be used 
> during
> + * system-wide PM transitions to sleep states.  It assumes that the analogous
> + * pm_runtime_force_resume() will be used to resume the device.
>   */
>  int pm_runtime_force_suspend(struct device *dev)
>  {
> @@ -1646,17 +1657,18 @@ int pm_runtime_force_suspend(struct devi
> goto err;
>
> /*
> -* Increase the runtime PM usage count for the device's parent, in 
> case
> -* when we find the device being used when system suspend was invoked.
> -* This informs pm_runtime_force_resume() to resume the parent
> -* immediately, which is needed to be able to resume 

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

[Jon Masters]

On 01/08/2018 05:09 PM, Michael Ellerman wrote:
> Thomas Gleixner  writes:
> 
>> On Tue, 9 Jan 2018, Michael Ellerman wrote:
>>
>> Sorry, I wasn't aware about your efforts and did not cc you. I've just
>> queued a more generic sysfs interface for this whole mess:
> 
> No worries.
> 
>> https://lkml.kernel.org/r/20180107214913.096657...@linutronix.de
>>
>> It should be simple to extend for write and it would be great if all
>> affected architectures could share it.
> 
> As you say this has all been a bit of a mess

Indeed. All of us wish this went very differently.

I've been testing various versions of these patches since before the
holidays. For those doing backports to older kernels, a note that the
IBM team added OOL (Out Of Line) exception handlers and reworked all of
that code over the years since older kernels (e.g. 3.10) so you might
get problems on those if you enable the debug entry. I've got notes on
how to backport the OOL exceptions to older kernels if anyone cares.

> and as a result we already have people running kernels with this patch,
> so we don't want to remove the 'rfi_flush' file.

Knowing that the IBM team was going to post with this sysfs interface,
our trees contain the rfi_flush file. I mentioned it to some folks on
this end (because we know we don't want to add things in sysfs
generally, debugfs is a good substitute, per Andrea, and I raised this
with him yesterday as a concern in the backport here) but in the end it
seemed reasonable to pull this in because it was what got posted, and as
Michael says, it's gone into other distro kernels beyond just ours.

> But we will certainly add support on powerpc for the files you have
> created, in addition to 'rfi_flush'.

Thanks,

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

[Jon Masters]

On 01/08/2018 05:09 PM, Michael Ellerman wrote:
> Thomas Gleixner  writes:
> 
>> On Tue, 9 Jan 2018, Michael Ellerman wrote:
>>
>> Sorry, I wasn't aware about your efforts and did not cc you. I've just
>> queued a more generic sysfs interface for this whole mess:
> 
> No worries.
> 
>> https://lkml.kernel.org/r/20180107214913.096657...@linutronix.de
>>
>> It should be simple to extend for write and it would be great if all
>> affected architectures could share it.
> 
> As you say this has all been a bit of a mess

Indeed. All of us wish this went very differently.

I've been testing various versions of these patches since before the
holidays. For those doing backports to older kernels, a note that the
IBM team added OOL (Out Of Line) exception handlers and reworked all of
that code over the years since older kernels (e.g. 3.10) so you might
get problems on those if you enable the debug entry. I've got notes on
how to backport the OOL exceptions to older kernels if anyone cares.

> and as a result we already have people running kernels with this patch,
> so we don't want to remove the 'rfi_flush' file.

Knowing that the IBM team was going to post with this sysfs interface,
our trees contain the rfi_flush file. I mentioned it to some folks on
this end (because we know we don't want to add things in sysfs
generally, debugfs is a good substitute, per Andrea, and I raised this
with him yesterday as a concern in the backport here) but in the end it
seemed reasonable to pull this in because it was what got posted, and as
Michael says, it's gone into other distro kernels beyond just ours.

> But we will certainly add support on powerpc for the files you have
> created, in addition to 'rfi_flush'.

Thanks,

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[RESEND PATCH] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.

[hao_zhang]

Pin function can not be match correctly when SUNXI_PIN describe with
mutiple variant and same function.

such as:
on pinctrl-sun4i-a10.c

SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION_VARIANT(0x2, "pwm",/* PWM0 */
PINCTRL_SUN4I_A10 |
PINCTRL_SUN7I_A20),
SUNXI_FUNCTION_VARIANT(0x3, "pwm",/* PWM0 */
PINCTRL_SUN8I_R40)),

it would always match to the first variant function
(PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)

so we should add variant compare on it.

Regards
Hao

Signed-off-by: hao_zhang 
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 4b6cb25..131adf7 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -83,7 +83,9 @@ sunxi_pinctrl_desc_find_function_by_name(struct sunxi_pinctrl 
*pctl,
struct sunxi_desc_function *func = pin->functions;
 
while (func->name) {
-   if (!strcmp(func->name, func_name))
+   if (!strcmp(func->name, func_name) &&
+   (!func->variant ||
+   func->variant & pctl->variant))
return func;
 
func++;
-- 
2.7.4

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

[jianchao.wang]

Hi tejun

Many thanks for your kindly response.

On 01/09/2018 11:37 AM, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 09, 2018 at 11:08:04AM +0800, jianchao.wang wrote:
>>> But what'd prevent the completion reinitializing the request and then
>>> the actual completion path coming in and completing the request again?
>>
>> blk_mark_rq_complete() will gate and ensure there will be only one 
>> __blk_mq_complete_request() to be invoked.
> 
> Yeah, but then the complete flag will be cleared once completion is
> done and the request is reinitialized.

Yes, it is. What I mean is not to reserve blk_mark_rq_complete and  
REQ_ATOM_COMPLETE
usages in blk-mq but the side-effect after blk_mq_complete_request cannot 
exclude with itself.
As you said, the scene is racy and should be modified. :)

Thanks
Jianchao 

[RESEND PATCH] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.

[hao_zhang]

Pin function can not be match correctly when SUNXI_PIN describe with
mutiple variant and same function.

such as:
on pinctrl-sun4i-a10.c

SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION_VARIANT(0x2, "pwm",/* PWM0 */
PINCTRL_SUN4I_A10 |
PINCTRL_SUN7I_A20),
SUNXI_FUNCTION_VARIANT(0x3, "pwm",/* PWM0 */
PINCTRL_SUN8I_R40)),

it would always match to the first variant function
(PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)

so we should add variant compare on it.

Regards
Hao

Signed-off-by: hao_zhang 
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 4b6cb25..131adf7 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -83,7 +83,9 @@ sunxi_pinctrl_desc_find_function_by_name(struct sunxi_pinctrl 
*pctl,
struct sunxi_desc_function *func = pin->functions;
 
while (func->name) {
-   if (!strcmp(func->name, func_name))
+   if (!strcmp(func->name, func_name) &&
+   (!func->variant ||
+   func->variant & pctl->variant))
return func;
 
func++;
-- 
2.7.4

Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq

[jianchao.wang]

Hi tejun

Many thanks for your kindly response.

On 01/09/2018 11:37 AM, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 09, 2018 at 11:08:04AM +0800, jianchao.wang wrote:
>>> But what'd prevent the completion reinitializing the request and then
>>> the actual completion path coming in and completing the request again?
>>
>> blk_mark_rq_complete() will gate and ensure there will be only one 
>> __blk_mq_complete_request() to be invoked.
> 
> Yeah, but then the complete flag will be cleared once completion is
> done and the request is reinitialized.

Yes, it is. What I mean is not to reserve blk_mark_rq_complete and  
REQ_ATOM_COMPLETE
usages in blk-mq but the side-effect after blk_mq_complete_request cannot 
exclude with itself.
As you said, the scene is racy and should be modified. :)

Thanks
Jianchao 

Re: WARNING: held lock freed!

[Xin Long]

On Mon, Jan 8, 2018 at 8:09 PM, Marcelo Ricardo Leitner
 wrote:
> On Mon, Jan 08, 2018 at 06:01:14PM +0800, Xin Long wrote:
>> On Mon, Jan 8, 2018 at 6:58 AM, syzbot
>>  wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 3219e264b984ec0a13923aa66385819c2e98d582
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > C reproducer is attached
>> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> > for information about syzkaller reproducers
>> >
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+ac6ea7baa4432811e...@syzkaller.appspotmail.com
>> > It will help syzbot understand when the bug is fixed. See footer for
>> > details.
>> > If you forward the report, please keep this part and the footer.
>> >
>> >
>> > =
>> > WARNING: held lock freed!
>> > 4.15.0-rc6+ #250 Not tainted
>> > -
>> > syzkaller065230/3505 is freeing memory 7fcba654-499fef26,
>> > with a lock still held there!
>> >  (sk_lock-AF_INET6){+.+.}, at: [] lock_sock
>> > include/net/sock.h:1461 [inline]
>> >  (sk_lock-AF_INET6){+.+.}, at: []
>> > sctp_wait_for_sndbuf+0x509/0x8d0 net/sctp/socket.c:8042
>> > 1 lock held by syzkaller065230/3505:
>> >  #0:  (sk_lock-AF_INET6){+.+.}, at: [] lock_sock
>> > include/net/sock.h:1461 [inline]
>> >  #0:  (sk_lock-AF_INET6){+.+.}, at: []
>> > sctp_wait_for_sndbuf+0x509/0x8d0 net/sctp/socket.c:8042
>> >
>> > stack backtrace:
>> > CPU: 0 PID: 3505 Comm: syzkaller065230 Not tainted 4.15.0-rc6+ #250
>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> > Google 01/01/2011
>> > Call Trace:
>> >  __dump_stack lib/dump_stack.c:17 [inline]
>> >  dump_stack+0x194/0x257 lib/dump_stack.c:53
>> >  print_freed_lock_bug kernel/locking/lockdep.c:4379 [inline]
>> >  debug_check_no_locks_freed+0x32f/0x3c0 kernel/locking/lockdep.c:4412
>> >  kmem_cache_free+0x68/0x2a0 mm/slab.c:3743
>> >  sk_prot_free net/core/sock.c:1504 [inline]
>> >  __sk_destruct+0x622/0x910 net/core/sock.c:1585
>> >  sk_destruct+0x47/0x80 net/core/sock.c:1593
>> >  __sk_free+0x57/0x230 net/core/sock.c:1601
>> >  sk_free+0x2a/0x40 net/core/sock.c:1612
>> >  sock_put include/net/sock.h:1656 [inline]
>> >  sctp_association_destroy net/sctp/associola.c:424 [inline]
>> >  sctp_association_put+0x14c/0x2f0 net/sctp/associola.c:883
>> >  sctp_wait_for_sndbuf+0x673/0x8d0 net/sctp/socket.c:8053
>> >  sctp_sendmsg+0x277d/0x3360 net/sctp/socket.c:1974
>> >  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
>> >  sock_sendmsg_nosec net/socket.c:636 [inline]
>> >  sock_sendmsg+0xca/0x110 net/socket.c:646
>> >  SYSC_sendto+0x361/0x5c0 net/socket.c:1727
>> >  SyS_sendto+0x40/0x50 net/socket.c:1695
>> >  entry_SYSCALL_64_fastpath+0x23/0x9a
>> > RIP: 0033:0x445db9
>> > RSP: 002b:7f2467415d98 EFLAGS: 0212 ORIG_RAX: 002c
>> > RAX: ffda RBX: 006dbc84 RCX: 00445db9
>> > RDX: 0001 RSI: 2010bf14 RDI: 0005
>> > RBP:  R08: 204d9000 R09: 001c
>> > R10:  R11: 0212 R12: 006dbc80
>> > R13: 209a9000 R14: 0100 R15: 0001
>> > ==
>> > BUG: KASAN: use-after-free in debug_spin_lock_before
>> > kernel/locking/spinlock_debug.c:83 [inline]
>> > BUG: KASAN: use-after-free in do_raw_spin_lock+0x1e0/0x220
>> > kernel/locking/spinlock_debug.c:112
>> > Read of size 4 at addr 8801c17ab08c by task syzkaller065230/3505
>>
>> It seems this commit is buggy:
>> commit cea0cc80a6777beb6eb643d4ad53690e1ad1d4ff
>> Author: Xin Long 
>> Date:   Wed Nov 15 16:57:26 2017 +0800
>>
>> sctp: use the right sk after waking up from wait_buf sleep
>>
>> I already had a patch to drop it and fix the old issue with a better way.
>
> Maybe you can quickly share it, so we have an idea what you are
> talking about?
Sure, in sctp_wait_for_sndbuf().

lock_sock(sk);
-   if (sk != asoc->base.sk) {
-   release_sock(sk);
-   sk = asoc->base.sk;
-   lock_sock(sk);
-   }
+   if (sk != asoc->base.sk)
+   goto do_error;

I had this patch when doing cleanup in sctp_sendmsg, it will also
make that cleanup easier.

Some comments for it:

After commit cea0cc80a677 ("sctp: use the right sk after waking up from
wait_buf sleep"), it may change to lock another sk if the asoc has been
peeled off in sctp_wait_for_sndbuf.

However, the asoc's new sk could be already 

Re: WARNING: held lock freed!

[Xin Long]

On Mon, Jan 8, 2018 at 8:09 PM, Marcelo Ricardo Leitner
 wrote:
> On Mon, Jan 08, 2018 at 06:01:14PM +0800, Xin Long wrote:
>> On Mon, Jan 8, 2018 at 6:58 AM, syzbot
>>  wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 3219e264b984ec0a13923aa66385819c2e98d582
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > C reproducer is attached
>> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> > for information about syzkaller reproducers
>> >
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+ac6ea7baa4432811e...@syzkaller.appspotmail.com
>> > It will help syzbot understand when the bug is fixed. See footer for
>> > details.
>> > If you forward the report, please keep this part and the footer.
>> >
>> >
>> > =
>> > WARNING: held lock freed!
>> > 4.15.0-rc6+ #250 Not tainted
>> > -
>> > syzkaller065230/3505 is freeing memory 7fcba654-499fef26,
>> > with a lock still held there!
>> >  (sk_lock-AF_INET6){+.+.}, at: [] lock_sock
>> > include/net/sock.h:1461 [inline]
>> >  (sk_lock-AF_INET6){+.+.}, at: []
>> > sctp_wait_for_sndbuf+0x509/0x8d0 net/sctp/socket.c:8042
>> > 1 lock held by syzkaller065230/3505:
>> >  #0:  (sk_lock-AF_INET6){+.+.}, at: [] lock_sock
>> > include/net/sock.h:1461 [inline]
>> >  #0:  (sk_lock-AF_INET6){+.+.}, at: []
>> > sctp_wait_for_sndbuf+0x509/0x8d0 net/sctp/socket.c:8042
>> >
>> > stack backtrace:
>> > CPU: 0 PID: 3505 Comm: syzkaller065230 Not tainted 4.15.0-rc6+ #250
>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> > Google 01/01/2011
>> > Call Trace:
>> >  __dump_stack lib/dump_stack.c:17 [inline]
>> >  dump_stack+0x194/0x257 lib/dump_stack.c:53
>> >  print_freed_lock_bug kernel/locking/lockdep.c:4379 [inline]
>> >  debug_check_no_locks_freed+0x32f/0x3c0 kernel/locking/lockdep.c:4412
>> >  kmem_cache_free+0x68/0x2a0 mm/slab.c:3743
>> >  sk_prot_free net/core/sock.c:1504 [inline]
>> >  __sk_destruct+0x622/0x910 net/core/sock.c:1585
>> >  sk_destruct+0x47/0x80 net/core/sock.c:1593
>> >  __sk_free+0x57/0x230 net/core/sock.c:1601
>> >  sk_free+0x2a/0x40 net/core/sock.c:1612
>> >  sock_put include/net/sock.h:1656 [inline]
>> >  sctp_association_destroy net/sctp/associola.c:424 [inline]
>> >  sctp_association_put+0x14c/0x2f0 net/sctp/associola.c:883
>> >  sctp_wait_for_sndbuf+0x673/0x8d0 net/sctp/socket.c:8053
>> >  sctp_sendmsg+0x277d/0x3360 net/sctp/socket.c:1974
>> >  inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
>> >  sock_sendmsg_nosec net/socket.c:636 [inline]
>> >  sock_sendmsg+0xca/0x110 net/socket.c:646
>> >  SYSC_sendto+0x361/0x5c0 net/socket.c:1727
>> >  SyS_sendto+0x40/0x50 net/socket.c:1695
>> >  entry_SYSCALL_64_fastpath+0x23/0x9a
>> > RIP: 0033:0x445db9
>> > RSP: 002b:7f2467415d98 EFLAGS: 0212 ORIG_RAX: 002c
>> > RAX: ffda RBX: 006dbc84 RCX: 00445db9
>> > RDX: 0001 RSI: 2010bf14 RDI: 0005
>> > RBP:  R08: 204d9000 R09: 001c
>> > R10:  R11: 0212 R12: 006dbc80
>> > R13: 209a9000 R14: 0100 R15: 0001
>> > ==
>> > BUG: KASAN: use-after-free in debug_spin_lock_before
>> > kernel/locking/spinlock_debug.c:83 [inline]
>> > BUG: KASAN: use-after-free in do_raw_spin_lock+0x1e0/0x220
>> > kernel/locking/spinlock_debug.c:112
>> > Read of size 4 at addr 8801c17ab08c by task syzkaller065230/3505
>>
>> It seems this commit is buggy:
>> commit cea0cc80a6777beb6eb643d4ad53690e1ad1d4ff
>> Author: Xin Long 
>> Date:   Wed Nov 15 16:57:26 2017 +0800
>>
>> sctp: use the right sk after waking up from wait_buf sleep
>>
>> I already had a patch to drop it and fix the old issue with a better way.
>
> Maybe you can quickly share it, so we have an idea what you are
> talking about?
Sure, in sctp_wait_for_sndbuf().

lock_sock(sk);
-   if (sk != asoc->base.sk) {
-   release_sock(sk);
-   sk = asoc->base.sk;
-   lock_sock(sk);
-   }
+   if (sk != asoc->base.sk)
+   goto do_error;

I had this patch when doing cleanup in sctp_sendmsg, it will also
make that cleanup easier.

Some comments for it:

After commit cea0cc80a677 ("sctp: use the right sk after waking up from
wait_buf sleep"), it may change to lock another sk if the asoc has been
peeled off in sctp_wait_for_sndbuf.

However, the asoc's new sk could be already closed elsewhere, as it's in
the sendmsg context of the old sk that can't avoid the new sk's closing.