Re: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

[Gregory CLEMENT]

Hi Andrew,
 
 On mer., janv. 25 2017, Andrew Lunn  wrote:

>> +[MV88E6341] = {
>> +.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
>> +.family = MV88E6XXX_FAMILY_6341,
>> +.name = "Marvell 88E6341",
>> +.num_databases = 4096,
>> +.num_ports = 6,
>> +.port_base_addr = 0x10,
>> +.global1_addr = 0x1b,
>> +.age_time_coeff = 15000,
>
> Hi Gregory
>
> Please could you check this timer in the datasheet. There is currently
> a bug in the mv88e6390 support code. I also set it to 15s. But in fact
> it is 3.75 seconds. The 6341 might also use 3.75 seconds.

When I read your series I also thought about it and indeed it is 3.75
seconds. I will fix it.

Thanks,

Gregory


>
>Thanks
>   Andrew

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

[Gregory CLEMENT]

Hi Andrew,
 
 On mer., janv. 25 2017, Andrew Lunn  wrote:

>> +[MV88E6341] = {
>> +.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
>> +.family = MV88E6XXX_FAMILY_6341,
>> +.name = "Marvell 88E6341",
>> +.num_databases = 4096,
>> +.num_ports = 6,
>> +.port_base_addr = 0x10,
>> +.global1_addr = 0x1b,
>> +.age_time_coeff = 15000,
>
> Hi Gregory
>
> Please could you check this timer in the datasheet. There is currently
> a bug in the mv88e6390 support code. I also set it to 15s. But in fact
> it is 3.75 seconds. The 6341 might also use 3.75 seconds.

When I read your series I also thought about it and indeed it is 3.75
seconds. I will fix it.

Thanks,

Gregory


>
>Thanks
>   Andrew

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon  wrote:
> Hi Richard,
>
> On 24 January 2017 at 19:18, Richard Genoud  wrote:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the USB ports on odroid-XU4 don't work anymore.
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2 
>> msec, port status = 0xc400fe3
>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop 
>> endpoint command.
>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting 
>> host.
>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [   74.606276] usb 3-1: USB disconnect, device number 2
>> [   74.613565] usb 4-1: USB disconnect, device number 2
>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 
>> device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek 
>> RTL8153 chip.
>>
>> If the lines:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> are commented out, the USB3.0 start working.
>>
>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>
>> Felipe suggested that suspend should be disabled temporarily while
>> what's wrong with DCW3 is figured out.
>>
>> Tested on Odroid XU4
>>
>> Suggested-by: Felipe Balbi 
>> Tested-by: Richard Genoud 
>> Signed-off-by: Richard Genoud 
>> Cc: sta...@vger.kernel.org # 4.4+
>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..f62dbd9b5ad3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,15 @@
>> status = "okay";
>>  };
>>
>> +_dwc3_0 {
>> +   /*
>> +* without that, usb devices are not recognized when
>> +* they are plugged.
>> +* cf: https://lkml.org/lkml/2017/1/18/678
>> +*/
>> +   snps,dis_u3_susphy_quirk;
>> +};
>> +
>>  _dwc3_1 {
>> dr_mode = "host";
>>  };
>> --
>
> Thanks for this patch.
> But could you consider moving this changes as below.
>
> https://lkml.org/lkml/2015/3/18/400

The patch above (and other DTS patches from the set) was not even sent
to linux-samsung-soc nor to me... It is sad how easily one's work can
disappear. Also, it is really worthless to solve the same problem
twice.

Cc Marek and Bartlomiej,
Guys, do you want to continue with Robert's patch (linked above by
Anand)? If yes, please take the ownership (Robert's address is not
valid anymore). If not, I will take Richard's patch after
resubmission.

Best regards,
Krzysztof

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon  wrote:
> Hi Richard,
>
> On 24 January 2017 at 19:18, Richard Genoud  wrote:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the USB ports on odroid-XU4 don't work anymore.
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2 
>> msec, port status = 0xc400fe3
>> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop 
>> endpoint command.
>> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting 
>> host.
>> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [   74.606276] usb 3-1: USB disconnect, device number 2
>> [   74.613565] usb 4-1: USB disconnect, device number 2
>> [   74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 
>> device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek 
>> RTL8153 chip.
>>
>> If the lines:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> are commented out, the USB3.0 start working.
>>
>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>
>> Felipe suggested that suspend should be disabled temporarily while
>> what's wrong with DCW3 is figured out.
>>
>> Tested on Odroid XU4
>>
>> Suggested-by: Felipe Balbi 
>> Tested-by: Richard Genoud 
>> Signed-off-by: Richard Genoud 
>> Cc: sta...@vger.kernel.org # 4.4+
>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..f62dbd9b5ad3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,15 @@
>> status = "okay";
>>  };
>>
>> +_dwc3_0 {
>> +   /*
>> +* without that, usb devices are not recognized when
>> +* they are plugged.
>> +* cf: https://lkml.org/lkml/2017/1/18/678
>> +*/
>> +   snps,dis_u3_susphy_quirk;
>> +};
>> +
>>  _dwc3_1 {
>> dr_mode = "host";
>>  };
>> --
>
> Thanks for this patch.
> But could you consider moving this changes as below.
>
> https://lkml.org/lkml/2015/3/18/400

The patch above (and other DTS patches from the set) was not even sent
to linux-samsung-soc nor to me... It is sad how easily one's work can
disappear. Also, it is really worthless to solve the same problem
twice.

Cc Marek and Bartlomiej,
Guys, do you want to continue with Robert's patch (linked above by
Anand)? If yes, please take the ownership (Robert's address is not
valid anymore). If not, I will take Richard's patch after
resubmission.

Best regards,
Krzysztof

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

[Clemens Ladisch]

SF Markus Elfring wrote:
> A local variable was set to an error code in two cases before a concrete
> error situation was detected.

And why would that be a problem?

http://yarchive.net/comp/linux/error_jumps.html

> - ret = -EBUSY;
> - if (state.busy)
> + if (state.busy) {
> + ret = -EBUSY;
>   goto out;
> + }


Regards,
Clemens

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

[Clemens Ladisch]

SF Markus Elfring wrote:
> A local variable was set to an error code in two cases before a concrete
> error situation was detected.

And why would that be a problem?

http://yarchive.net/comp/linux/error_jumps.html

> - ret = -EBUSY;
> - if (state.busy)
> + if (state.busy) {
> + ret = -EBUSY;
>   goto out;
> + }


Regards,
Clemens

Re: linux-next: manual merge of the kselftest tree with the net-next tree

[Daniel Borkmann]

On 01/25/2017 05:03 AM, Stephen Rothwell wrote:

Hi Shuah,

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

   tools/testing/selftests/bpf/Makefile

between commit:

   62b64660262a ("bpf: add prog tag test case to bpf selftests")

from the net-next tree and commit:

   88baa78d1f31 ("selftests: remove duplicated all and clean target")

from the kselftest tree.

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


Looks good to me, thanks!

Re: linux-next: manual merge of the kselftest tree with the net-next tree

[Daniel Borkmann]

On 01/25/2017 05:03 AM, Stephen Rothwell wrote:

Hi Shuah,

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

   tools/testing/selftests/bpf/Makefile

between commit:

   62b64660262a ("bpf: add prog tag test case to bpf selftests")

from the net-next tree and commit:

   88baa78d1f31 ("selftests: remove duplicated all and clean target")

from the kselftest tree.

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


Looks good to me, thanks!

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

[Markus Heiser]

Hi Jon, hi Daniel !

Am 25.01.2017 um 07:37 schrieb Daniel Vetter :

>> Again, quick comments...
>> 
>> - I would *much* rather evolve our existing Sphinx extension in the
>>   direction we want it to go than to just replace it wholesale.
>>   Replacement is the wrong approach for a few reasons, including the need
>>   to minimize change and preserve credit for Jani's work.  Can we work on
>>   that basis, please?

Sure. But I fear I haven't understood you right  last post was:

> Markus, would you consider sending out a new patch set for review?  What I
> would like to do see is something adding the new script for the Sphinx
> toolchain, while leaving the DocBook build unchanged, using the old
> script.  We could then delete it once the last template file has moved
> over. 

talking about DocBook and now I read ...

>>   Ideally at the time of merging, we would be able to build the docs with
>>   *either* kerneldoc.

Now I'am totally confused ... it's no about you, but I do not understand
you clearly ... can you help a conceptual man?

> Seconded, I think renaming the extension string like this is just fairly
> pointless busy-work.

Hi Daniel, please help me, what did you mean with "renaming" the extension
string and "busy-work"?

There is a renaming of module's name but there should no work outside this
patch ... 

> Kernel-doc isn't interacting perfectly with rst, but
> now we already have a sizeable amount of stuff converted and going through
> all that once more needs imo som really clear benefits.

from authors POV nothing has changed.

> I think bug-for-bug compatibility would be much better. Later on we could do
> changes, on a change-by-change basis.

Both sphinx-extensions (the one we have and the one in the series) are
adapter to a "parser backend". 

1. Documentation/sphinx/kerneldoc.py<--> scripts/kerneldoc -rst
2. Documentation/sphinx/rstKernelDoc.py <--> import module 
Documentation/sphinx/kernel_doc.py

Maintain two adapters for the two backends is possible. But one adapter
for two complete different backends .. is this what you mean?

>> - I'll have to try it out to see how noisy it is.  I'm not opposed to
>>   stricter checks; indeed, they could be a good thing.  But we might want
>>   to have an option so we can cut back on the noise by default.

As said, I'am willing to go communities way, it seems just a communication
problem (on my side) to understand what this way would be.

I try to sum what I guess ... e.g. to build output as usual with (1.)

  $ make htmldocs

to build with the py-parser and its sphinx-extension (see 2. above)::

  $ USE_PY_PARSER=1 make htmldocs

this should be easy and I can realize it in v2, but is this what you want?

Please give me some more hints / Thanks a lot!

--Markus--

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

[Markus Heiser]

Hi Jon, hi Daniel !

Am 25.01.2017 um 07:37 schrieb Daniel Vetter :

>> Again, quick comments...
>> 
>> - I would *much* rather evolve our existing Sphinx extension in the
>>   direction we want it to go than to just replace it wholesale.
>>   Replacement is the wrong approach for a few reasons, including the need
>>   to minimize change and preserve credit for Jani's work.  Can we work on
>>   that basis, please?

Sure. But I fear I haven't understood you right  last post was:

> Markus, would you consider sending out a new patch set for review?  What I
> would like to do see is something adding the new script for the Sphinx
> toolchain, while leaving the DocBook build unchanged, using the old
> script.  We could then delete it once the last template file has moved
> over. 

talking about DocBook and now I read ...

>>   Ideally at the time of merging, we would be able to build the docs with
>>   *either* kerneldoc.

Now I'am totally confused ... it's no about you, but I do not understand
you clearly ... can you help a conceptual man?

> Seconded, I think renaming the extension string like this is just fairly
> pointless busy-work.

Hi Daniel, please help me, what did you mean with "renaming" the extension
string and "busy-work"?

There is a renaming of module's name but there should no work outside this
patch ... 

> Kernel-doc isn't interacting perfectly with rst, but
> now we already have a sizeable amount of stuff converted and going through
> all that once more needs imo som really clear benefits.

from authors POV nothing has changed.

> I think bug-for-bug compatibility would be much better. Later on we could do
> changes, on a change-by-change basis.

Both sphinx-extensions (the one we have and the one in the series) are
adapter to a "parser backend". 

1. Documentation/sphinx/kerneldoc.py<--> scripts/kerneldoc -rst
2. Documentation/sphinx/rstKernelDoc.py <--> import module 
Documentation/sphinx/kernel_doc.py

Maintain two adapters for the two backends is possible. But one adapter
for two complete different backends .. is this what you mean?

>> - I'll have to try it out to see how noisy it is.  I'm not opposed to
>>   stricter checks; indeed, they could be a good thing.  But we might want
>>   to have an option so we can cut back on the noise by default.

As said, I'am willing to go communities way, it seems just a communication
problem (on my side) to understand what this way would be.

I try to sum what I guess ... e.g. to build output as usual with (1.)

  $ make htmldocs

to build with the py-parser and its sphinx-extension (see 2. above)::

  $ USE_PY_PARSER=1 make htmldocs

this should be easy and I can realize it in v2, but is this what you want?

Please give me some more hints / Thanks a lot!

--Markus--

Re: [PATCH] x86/gpu: GLK uses the same GMS values as SKL

[Ingo Molnar]

* Paulo Zanoni  wrote:

> So don't forget to reserve its stolen memory bits.
> 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: Ander Conselvan de Oliveira 
> Cc: x...@kernel.org
> Reviewed-by: Ander Conselvan de Oliveira 
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  arch/x86/kernel/early-quirks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> Found by code inspection. This is completely untested since I don't have
> GLK hardware.
> 
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 6a08e25..23c4f1c 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -526,6 +526,7 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_SKL_IDS(_early_ops),
>   INTEL_BXT_IDS(_early_ops),
>   INTEL_KBL_IDS(_early_ops),
> + INTEL_GLK_IDS(_early_ops),
>  };

There's no INTEL_GLK_IDS() upstream - is there any dependency here on other 
changes to the i915 GPU driver?

Thanks,

Ingo

Re: [PATCH] x86/gpu: GLK uses the same GMS values as SKL

[Ingo Molnar]

* Paulo Zanoni  wrote:

> So don't forget to reserve its stolen memory bits.
> 
> Cc: Ingo Molnar 
> Cc: H. Peter Anvin 
> Cc: Ander Conselvan de Oliveira 
> Cc: x...@kernel.org
> Reviewed-by: Ander Conselvan de Oliveira 
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  arch/x86/kernel/early-quirks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> Found by code inspection. This is completely untested since I don't have
> GLK hardware.
> 
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 6a08e25..23c4f1c 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -526,6 +526,7 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_SKL_IDS(_early_ops),
>   INTEL_BXT_IDS(_early_ops),
>   INTEL_KBL_IDS(_early_ops),
> + INTEL_GLK_IDS(_early_ops),
>  };

There's no INTEL_GLK_IDS() upstream - is there any dependency here on other 
changes to the i915 GPU driver?

Thanks,

Ingo

Re: [PATCH 2/2] perf tools: Introduce regs_query_register_offset() for arm64

[Hekuang]

hi

在 2017/1/25 3:09, Arnaldo Carvalho de Melo 写道:

Em Tue, Jan 24, 2017 at 06:25:18PM +, Will Deacon escreveu:

On Tue, Jan 24, 2017 at 10:30:15AM +, He Kuang wrote:

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

This patch also changes the 'dwarfnum' to 'offset' in register table,
so the related functions are consistent with x86.

Signed-off-by: He Kuang 
  

It would've been nice to have been cc'd on this. In future, please at least
cc linux-arm-kernel for patches directly changing arm/arm64 code.
  

+   GPR_OFFSET_NAME(30),
+   {.name = "lr", .offset = offsetof(struct user_pt_regs, regs[30])},
+   REG_OFFSET_NAME(sp),
  

Don't sp and lr need the leading '%'?
  

+   REG_OFFSET_NAME(pc),
+   REG_OFFSET_NAME(pstate),
  

The AArch64 DWARF spec says that DWARF register 32 is "RESERVED" and
register 33 is the ELR, so these pc/pstate entries are wrong.
  

However, with those changes, I think this patch can simply be ignored and
mainline is doing the right thing.

Ok, thanks for checking, dropping this patch then.

- Arnaldo



The purpose of this patch is mainly on enable bpf prologue on arm64,
a new v2 version is sent and fix the problem mentioned by Will, thank
you for reviewing this.

Re: [PATCH 2/2] perf tools: Introduce regs_query_register_offset() for arm64

[Hekuang]

hi

在 2017/1/25 3:09, Arnaldo Carvalho de Melo 写道:

Em Tue, Jan 24, 2017 at 06:25:18PM +, Will Deacon escreveu:

On Tue, Jan 24, 2017 at 10:30:15AM +, He Kuang wrote:

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

This patch also changes the 'dwarfnum' to 'offset' in register table,
so the related functions are consistent with x86.

Signed-off-by: He Kuang 
  

It would've been nice to have been cc'd on this. In future, please at least
cc linux-arm-kernel for patches directly changing arm/arm64 code.
  

+   GPR_OFFSET_NAME(30),
+   {.name = "lr", .offset = offsetof(struct user_pt_regs, regs[30])},
+   REG_OFFSET_NAME(sp),
  

Don't sp and lr need the leading '%'?
  

+   REG_OFFSET_NAME(pc),
+   REG_OFFSET_NAME(pstate),
  

The AArch64 DWARF spec says that DWARF register 32 is "RESERVED" and
register 33 is the ELR, so these pc/pstate entries are wrong.
  

However, with those changes, I think this patch can simply be ignored and
mainline is doing the right thing.

Ok, thanks for checking, dropping this patch then.

- Arnaldo



The purpose of this patch is mainly on enable bpf prologue on arm64,
a new v2 version is sent and fix the problem mentioned by Will, thank
you for reviewing this.

[PATCH 2/2 v2] perf tools: Enable bpf prologue for arm64

[He Kuang]

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

This patch also changes the 'dwarfnum' to 'offset' in register table,
so the related functions are consistent with x86.

Signed-off-by: He Kuang 
---
 tools/perf/arch/arm64/Makefile  |   1 +
 tools/perf/arch/arm64/util/dwarf-regs.c | 124 ++--
 2 files changed, 72 insertions(+), 53 deletions(-)

diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 18b1351..eebe1ec 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -2,3 +2,4 @@ ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
 PERF_HAVE_JITDUMP := 1
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c 
b/tools/perf/arch/arm64/util/dwarf-regs.c
index d49efeb..5ec62a4 100644
--- a/tools/perf/arch/arm64/util/dwarf-regs.c
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -9,72 +9,90 @@
  */
 
 #include 
+#include  /* for struct user_pt_regs */
+#include  /* for EINVAL */
+#include  /* for strcmp */
+#include  /* for struct user_pt_regs */
 #include 
 
-struct pt_regs_dwarfnum {
+struct pt_regs_offset {
const char *name;
-   unsigned int dwarfnum;
+   int offset;
 };
 
-#define STR(s) #s
-#define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
-#define GPR_DWARFNUM_NAME(num) \
-   {.name = STR(%x##num), .dwarfnum = num}
-#define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
-
 /*
  * Reference:
  * 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0057b/IHI0057B_aadwarf64.pdf
  */
-static const struct pt_regs_dwarfnum regdwarfnum_table[] = {
-   GPR_DWARFNUM_NAME(0),
-   GPR_DWARFNUM_NAME(1),
-   GPR_DWARFNUM_NAME(2),
-   GPR_DWARFNUM_NAME(3),
-   GPR_DWARFNUM_NAME(4),
-   GPR_DWARFNUM_NAME(5),
-   GPR_DWARFNUM_NAME(6),
-   GPR_DWARFNUM_NAME(7),
-   GPR_DWARFNUM_NAME(8),
-   GPR_DWARFNUM_NAME(9),
-   GPR_DWARFNUM_NAME(10),
-   GPR_DWARFNUM_NAME(11),
-   GPR_DWARFNUM_NAME(12),
-   GPR_DWARFNUM_NAME(13),
-   GPR_DWARFNUM_NAME(14),
-   GPR_DWARFNUM_NAME(15),
-   GPR_DWARFNUM_NAME(16),
-   GPR_DWARFNUM_NAME(17),
-   GPR_DWARFNUM_NAME(18),
-   GPR_DWARFNUM_NAME(19),
-   GPR_DWARFNUM_NAME(20),
-   GPR_DWARFNUM_NAME(21),
-   GPR_DWARFNUM_NAME(22),
-   GPR_DWARFNUM_NAME(23),
-   GPR_DWARFNUM_NAME(24),
-   GPR_DWARFNUM_NAME(25),
-   GPR_DWARFNUM_NAME(26),
-   GPR_DWARFNUM_NAME(27),
-   GPR_DWARFNUM_NAME(28),
-   GPR_DWARFNUM_NAME(29),
-   REG_DWARFNUM_NAME("%lr", 30),
-   REG_DWARFNUM_NAME("%sp", 31),
-   REG_DWARFNUM_END,
+#define REG_OFFSET_NAME(r, num) {.name = "%" #r,   \
+   .offset = offsetof(struct user_pt_regs, regs[num])}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#define GPR_OFFSET_NAME(r) \
+   {.name = "%x" #r, .offset = offsetof(struct user_pt_regs, regs[r])}
+
+/* This table is for reverse searching for the offset or register
+ * names in aarch64_regstr_tbl[].
+ */
+static const struct pt_regs_offset regoffset_table[] = {
+   GPR_OFFSET_NAME(0),
+   GPR_OFFSET_NAME(1),
+   GPR_OFFSET_NAME(2),
+   GPR_OFFSET_NAME(3),
+   GPR_OFFSET_NAME(4),
+   GPR_OFFSET_NAME(5),
+   GPR_OFFSET_NAME(6),
+   GPR_OFFSET_NAME(7),
+   GPR_OFFSET_NAME(8),
+   GPR_OFFSET_NAME(9),
+   GPR_OFFSET_NAME(10),
+   GPR_OFFSET_NAME(11),
+   GPR_OFFSET_NAME(12),
+   GPR_OFFSET_NAME(13),
+   GPR_OFFSET_NAME(14),
+   GPR_OFFSET_NAME(15),
+   GPR_OFFSET_NAME(16),
+   GPR_OFFSET_NAME(17),
+   GPR_OFFSET_NAME(18),
+   GPR_OFFSET_NAME(19),
+   GPR_OFFSET_NAME(20),
+   GPR_OFFSET_NAME(21),
+   GPR_OFFSET_NAME(22),
+   GPR_OFFSET_NAME(23),
+   GPR_OFFSET_NAME(24),
+   GPR_OFFSET_NAME(25),
+   GPR_OFFSET_NAME(26),
+   GPR_OFFSET_NAME(27),
+   GPR_OFFSET_NAME(28),
+   GPR_OFFSET_NAME(29),
+   REG_OFFSET_NAME(lr, 30),
+   REG_OFFSET_NAME(sp, 31),
+   REG_OFFSET_END,
 };
 
+/* Minus 1 for the ending REG_OFFSET_END */
+#define ARCH_MAX_REGS ((sizeof(regoffset_table) /  \
+   sizeof(regoffset_table[0])) - 1)
+
+/* Return architecture dependent register string (for kprobe-tracer) */
+const char *get_arch_regstr(unsigned int n)
+{
+   return (n < ARCH_MAX_REGS) ? regoffset_table[n].name : NULL;
+}
+
+/* Reuse code from arch/arm64/kernel/ptrace.c */
 /**
- * get_arch_regstr() - lookup register name from it's DWARF register number
- * @n: the DWARF register number
+ * regs_query_register_offset() - query register offset from its name
+ * @name:  the name of a register
  *
- * get_arch_regstr() returns the name of the register in struct
- * regdwarfnum_table from it's DWARF 

[PATCH 2/2 v2] perf tools: Enable bpf prologue for arm64

[He Kuang]

Since HAVE_KPROBES can be enabled in arm64, this patch introduces
regs_query_register_offset() to convert register name to offset for
arm64, so the BPF prologue feature is ready to use.

This patch also changes the 'dwarfnum' to 'offset' in register table,
so the related functions are consistent with x86.

Signed-off-by: He Kuang 
---
 tools/perf/arch/arm64/Makefile  |   1 +
 tools/perf/arch/arm64/util/dwarf-regs.c | 124 ++--
 2 files changed, 72 insertions(+), 53 deletions(-)

diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 18b1351..eebe1ec 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -2,3 +2,4 @@ ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
 PERF_HAVE_JITDUMP := 1
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c 
b/tools/perf/arch/arm64/util/dwarf-regs.c
index d49efeb..5ec62a4 100644
--- a/tools/perf/arch/arm64/util/dwarf-regs.c
+++ b/tools/perf/arch/arm64/util/dwarf-regs.c
@@ -9,72 +9,90 @@
  */
 
 #include 
+#include  /* for struct user_pt_regs */
+#include  /* for EINVAL */
+#include  /* for strcmp */
+#include  /* for struct user_pt_regs */
 #include 
 
-struct pt_regs_dwarfnum {
+struct pt_regs_offset {
const char *name;
-   unsigned int dwarfnum;
+   int offset;
 };
 
-#define STR(s) #s
-#define REG_DWARFNUM_NAME(r, num) {.name = r, .dwarfnum = num}
-#define GPR_DWARFNUM_NAME(num) \
-   {.name = STR(%x##num), .dwarfnum = num}
-#define REG_DWARFNUM_END {.name = NULL, .dwarfnum = 0}
-
 /*
  * Reference:
  * 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0057b/IHI0057B_aadwarf64.pdf
  */
-static const struct pt_regs_dwarfnum regdwarfnum_table[] = {
-   GPR_DWARFNUM_NAME(0),
-   GPR_DWARFNUM_NAME(1),
-   GPR_DWARFNUM_NAME(2),
-   GPR_DWARFNUM_NAME(3),
-   GPR_DWARFNUM_NAME(4),
-   GPR_DWARFNUM_NAME(5),
-   GPR_DWARFNUM_NAME(6),
-   GPR_DWARFNUM_NAME(7),
-   GPR_DWARFNUM_NAME(8),
-   GPR_DWARFNUM_NAME(9),
-   GPR_DWARFNUM_NAME(10),
-   GPR_DWARFNUM_NAME(11),
-   GPR_DWARFNUM_NAME(12),
-   GPR_DWARFNUM_NAME(13),
-   GPR_DWARFNUM_NAME(14),
-   GPR_DWARFNUM_NAME(15),
-   GPR_DWARFNUM_NAME(16),
-   GPR_DWARFNUM_NAME(17),
-   GPR_DWARFNUM_NAME(18),
-   GPR_DWARFNUM_NAME(19),
-   GPR_DWARFNUM_NAME(20),
-   GPR_DWARFNUM_NAME(21),
-   GPR_DWARFNUM_NAME(22),
-   GPR_DWARFNUM_NAME(23),
-   GPR_DWARFNUM_NAME(24),
-   GPR_DWARFNUM_NAME(25),
-   GPR_DWARFNUM_NAME(26),
-   GPR_DWARFNUM_NAME(27),
-   GPR_DWARFNUM_NAME(28),
-   GPR_DWARFNUM_NAME(29),
-   REG_DWARFNUM_NAME("%lr", 30),
-   REG_DWARFNUM_NAME("%sp", 31),
-   REG_DWARFNUM_END,
+#define REG_OFFSET_NAME(r, num) {.name = "%" #r,   \
+   .offset = offsetof(struct user_pt_regs, regs[num])}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#define GPR_OFFSET_NAME(r) \
+   {.name = "%x" #r, .offset = offsetof(struct user_pt_regs, regs[r])}
+
+/* This table is for reverse searching for the offset or register
+ * names in aarch64_regstr_tbl[].
+ */
+static const struct pt_regs_offset regoffset_table[] = {
+   GPR_OFFSET_NAME(0),
+   GPR_OFFSET_NAME(1),
+   GPR_OFFSET_NAME(2),
+   GPR_OFFSET_NAME(3),
+   GPR_OFFSET_NAME(4),
+   GPR_OFFSET_NAME(5),
+   GPR_OFFSET_NAME(6),
+   GPR_OFFSET_NAME(7),
+   GPR_OFFSET_NAME(8),
+   GPR_OFFSET_NAME(9),
+   GPR_OFFSET_NAME(10),
+   GPR_OFFSET_NAME(11),
+   GPR_OFFSET_NAME(12),
+   GPR_OFFSET_NAME(13),
+   GPR_OFFSET_NAME(14),
+   GPR_OFFSET_NAME(15),
+   GPR_OFFSET_NAME(16),
+   GPR_OFFSET_NAME(17),
+   GPR_OFFSET_NAME(18),
+   GPR_OFFSET_NAME(19),
+   GPR_OFFSET_NAME(20),
+   GPR_OFFSET_NAME(21),
+   GPR_OFFSET_NAME(22),
+   GPR_OFFSET_NAME(23),
+   GPR_OFFSET_NAME(24),
+   GPR_OFFSET_NAME(25),
+   GPR_OFFSET_NAME(26),
+   GPR_OFFSET_NAME(27),
+   GPR_OFFSET_NAME(28),
+   GPR_OFFSET_NAME(29),
+   REG_OFFSET_NAME(lr, 30),
+   REG_OFFSET_NAME(sp, 31),
+   REG_OFFSET_END,
 };
 
+/* Minus 1 for the ending REG_OFFSET_END */
+#define ARCH_MAX_REGS ((sizeof(regoffset_table) /  \
+   sizeof(regoffset_table[0])) - 1)
+
+/* Return architecture dependent register string (for kprobe-tracer) */
+const char *get_arch_regstr(unsigned int n)
+{
+   return (n < ARCH_MAX_REGS) ? regoffset_table[n].name : NULL;
+}
+
+/* Reuse code from arch/arm64/kernel/ptrace.c */
 /**
- * get_arch_regstr() - lookup register name from it's DWARF register number
- * @n: the DWARF register number
+ * regs_query_register_offset() - query register offset from its name
+ * @name:  the name of a register
  *
- * get_arch_regstr() returns the name of the register in struct
- * regdwarfnum_table from it's DWARF register number. If the 

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark,

On 25 January 2017 at 14:46, Fu Wei  wrote:
> Hi Mark,
>
> On 25 January 2017 at 01:24, Mark Rutland  wrote:
>> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>>> From: Fu Wei 
>>>
>>> The counter frequency detection call(arch_timer_detect_rate) combines two
>>> ways to get counter frequency: system coprocessor register and MMIO timer.
>>> But in a specific timer init code, we only need one way to try:
>>> getting frequency from MMIO timer register will be needed only when we
>>> init MMIO timer; getting frequency from system coprocessor register will
>>> be needed only when we init arch timer.
>>
>> When I mentioned this splitting before, I had mean that we'd completely
>> separate the two, with separate mmio_rate and sysreg_rate variables.
>
> sorry for misunderstanding.
>
> Are you saying :
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 663a57a..eec92f6 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -65,7 +65,8 @@ struct arch_timer {
>
>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
>
> -static u32 arch_timer_rate;
> +static u32 arch_timer_sysreg_rate ;
> +static u32 arch_timer_mmio_rate;
>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
>
>  static struct clock_event_device __percpu *arch_timer_evt;
>
>
> But what have I learned From ARMv8 ARM is
> AArch64 System register CNTFRQ_EL0 is provided so that software can
> discover the frequency of the system counter.
> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
> discover the frequency of the system counter.
> The bit assignments of the registers are identical in the System
> register interface and in the memory-mapped system level interface.
> So I think they both contain the same value : the frequency of the
> system counter, just in different view, and can be accessed in
> different ways.
>
> So do we really need to separate mmio_rate and sysreg_rate variables?
>
> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
> Linux kernel (EL1),
> Because ARMv8 ARM says:
> In a system that implements both Secure and Non-secure states, this
> register is only accessible by Secure accesses.
> That means we still need to get the frequency of the system counter
> from CNTFRQ_EL0 in MMIO timer code.
> This have been proved when I tested this driver on foundation model, I
> got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)
>
> So I guess the logic of the original code is
>  static u32 arch_timer_rate keeps the frequency of the system counter,
>  no matter where the value comes from.
> Because  they should be the same value. if we have got the frequency
> of the system counter(arch_timer_rate != 0), then we don't need to get
> it again, even in anther way.

*IF*  the above is right,
For ARM32, boot with dtb,  the original logic and this patch work well.
For ARM64, boot with dtb,  if MMIO timer is probed first, and there is
not "clock-frequency" in the node. MMIO timer can't get  the
frequency. Because we will get "0" when we access CNTFRQ from Linux
kernel (Non-secure EL1), that means the original logic and this patch
won't work. To fix this issue, we need to get  the frequency  from
sysreg CNTFRQ_EL0.
For ARM64, boot with ACPI, the original logic and this patch work
well, because we always probe arch_timer first.

So *IF* I understand it correctly, May I suggest that we only get  the
frequency from sysreg CNTFRQ_EL0 in this driver?
I think that can simplify the code and avoid the issue when we boot
ARM64 with dtb.

Again,  please correct me if I misunderstand something.  :-)  Great
thanks for your help!

>
> But  the above is just my thought, and I believe you're the expert of
> ARM. So please correct me if I misunderstand something.  :-)
>
> Thanks!
>>
>> The probing logic relying on this is complicated and fragile, and I
>> think these patches are complicating that further (though I appreciate
>> that's far from the intent).
>>
>> I believe we need to split the MMIO and sysreg timer code apart
>> entirely. I've had a look at that today, though it's been fairly painful
>> so far. It appears some platforms may inadvertently be relying on the
>> order and manner in which the rates are probed, which is a major
>> headache.
>>
>> I will try to attack that some more tomorrow.
>>
>>> This patch separates paths to determine frequency:
>>> Separate out the MMIO frequency and the sysreg frequency detection call,
>>> and use the appropriate one for the counter.
>>>
>>> Signed-off-by: Fu Wei 
>>> ---
>>>  drivers/clocksource/arm_arch_timer.c | 40 
>>> ++--
>>>  1 file changed, 25 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>>> b/drivers/clocksource/arm_arch_timer.c
>>> index 6484f84..9482481 100644
>>> 

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark,

On 25 January 2017 at 14:46, Fu Wei  wrote:
> Hi Mark,
>
> On 25 January 2017 at 01:24, Mark Rutland  wrote:
>> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>>> From: Fu Wei 
>>>
>>> The counter frequency detection call(arch_timer_detect_rate) combines two
>>> ways to get counter frequency: system coprocessor register and MMIO timer.
>>> But in a specific timer init code, we only need one way to try:
>>> getting frequency from MMIO timer register will be needed only when we
>>> init MMIO timer; getting frequency from system coprocessor register will
>>> be needed only when we init arch timer.
>>
>> When I mentioned this splitting before, I had mean that we'd completely
>> separate the two, with separate mmio_rate and sysreg_rate variables.
>
> sorry for misunderstanding.
>
> Are you saying :
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 663a57a..eec92f6 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -65,7 +65,8 @@ struct arch_timer {
>
>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
>
> -static u32 arch_timer_rate;
> +static u32 arch_timer_sysreg_rate ;
> +static u32 arch_timer_mmio_rate;
>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
>
>  static struct clock_event_device __percpu *arch_timer_evt;
>
>
> But what have I learned From ARMv8 ARM is
> AArch64 System register CNTFRQ_EL0 is provided so that software can
> discover the frequency of the system counter.
> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
> discover the frequency of the system counter.
> The bit assignments of the registers are identical in the System
> register interface and in the memory-mapped system level interface.
> So I think they both contain the same value : the frequency of the
> system counter, just in different view, and can be accessed in
> different ways.
>
> So do we really need to separate mmio_rate and sysreg_rate variables?
>
> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
> Linux kernel (EL1),
> Because ARMv8 ARM says:
> In a system that implements both Secure and Non-secure states, this
> register is only accessible by Secure accesses.
> That means we still need to get the frequency of the system counter
> from CNTFRQ_EL0 in MMIO timer code.
> This have been proved when I tested this driver on foundation model, I
> got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)
>
> So I guess the logic of the original code is
>  static u32 arch_timer_rate keeps the frequency of the system counter,
>  no matter where the value comes from.
> Because  they should be the same value. if we have got the frequency
> of the system counter(arch_timer_rate != 0), then we don't need to get
> it again, even in anther way.

*IF*  the above is right,
For ARM32, boot with dtb,  the original logic and this patch work well.
For ARM64, boot with dtb,  if MMIO timer is probed first, and there is
not "clock-frequency" in the node. MMIO timer can't get  the
frequency. Because we will get "0" when we access CNTFRQ from Linux
kernel (Non-secure EL1), that means the original logic and this patch
won't work. To fix this issue, we need to get  the frequency  from
sysreg CNTFRQ_EL0.
For ARM64, boot with ACPI, the original logic and this patch work
well, because we always probe arch_timer first.

So *IF* I understand it correctly, May I suggest that we only get  the
frequency from sysreg CNTFRQ_EL0 in this driver?
I think that can simplify the code and avoid the issue when we boot
ARM64 with dtb.

Again,  please correct me if I misunderstand something.  :-)  Great
thanks for your help!

>
> But  the above is just my thought, and I believe you're the expert of
> ARM. So please correct me if I misunderstand something.  :-)
>
> Thanks!
>>
>> The probing logic relying on this is complicated and fragile, and I
>> think these patches are complicating that further (though I appreciate
>> that's far from the intent).
>>
>> I believe we need to split the MMIO and sysreg timer code apart
>> entirely. I've had a look at that today, though it's been fairly painful
>> so far. It appears some platforms may inadvertently be relying on the
>> order and manner in which the rates are probed, which is a major
>> headache.
>>
>> I will try to attack that some more tomorrow.
>>
>>> This patch separates paths to determine frequency:
>>> Separate out the MMIO frequency and the sysreg frequency detection call,
>>> and use the appropriate one for the counter.
>>>
>>> Signed-off-by: Fu Wei 
>>> ---
>>>  drivers/clocksource/arm_arch_timer.c | 40 
>>> ++--
>>>  1 file changed, 25 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>>> b/drivers/clocksource/arm_arch_timer.c
>>> index 6484f84..9482481 100644
>>> --- a/drivers/clocksource/arm_arch_timer.c
>>> +++ 

Re: [patch] {1620} net: hns3: add dcb cap flag in init sequence

[Yankejian (Hackim Yim)]

it is misoperation, please ignore. sorry to interrupt you!


On 2017/1/25 15:26, Kejian Yan wrote:
> If enable DCB feature, we need to add the capacity, and the current
> procedure cannot setting the dcb because of no capacity flag and every
> ops interface will implement by the capicity flag is enable.
>
> Signed-off-by: Kejian Yan 
> ---
>  drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 --
>  drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c   | 5 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index 26b9b46..fffe781 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -314,12 +314,14 @@ static int hclge_configure(struct hclge_dev *hdev)
>   hdev->tx_sch_mode = HCLGE_FLAG_TC_BASE_SCH_MODE;
>  #ifdef CONFIG_HNS3_DCB
>   hdev->dcbx_cap = DCB_CAP_DCBX_VER_CEE |
> - DCB_CAP_DCBX_VER_IEEE;
> + DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
> + hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
>  #endif /* #ifdef CONFIG_HNS3_DCB */
>   } else {
>   hdev->tx_sch_mode = HCLGE_FLAG_VNET_BASE_SCH_MODE;
>  #ifdef CONFIG_HNS3_DCB
> - hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE;
> + hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
> + hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
>  #endif /* #ifdef CONFIG_HNS3_DCB */
>   }
>  
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c 
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> index 903c413..6b00982 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> @@ -687,6 +687,11 @@ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
>   hdev->dcb_info_tmp.num_tc = hdev->dcb_info.num_tc;
>   memcpy(hdev->dcb_info_tmp.tc_info, hdev->dcb_info.tc_info,
>  HNAE3_MAX_TC * sizeof(*hdev->dcb_info.tc_info));
> +
> + if (hdev->dcb_info.num_tc > 1)
> + hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
> + else
> + hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
>  }
>  
>  static void hclge_tm_pg_info_init(struct hclge_dev *hdev)


-- 
MBR,
Yankejian (Hackim Yim)

Re: [patch] {1620} net: hns3: add dcb cap flag in init sequence

[Yankejian (Hackim Yim)]

it is misoperation, please ignore. sorry to interrupt you!


On 2017/1/25 15:26, Kejian Yan wrote:
> If enable DCB feature, we need to add the capacity, and the current
> procedure cannot setting the dcb because of no capacity flag and every
> ops interface will implement by the capicity flag is enable.
>
> Signed-off-by: Kejian Yan 
> ---
>  drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 --
>  drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c   | 5 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index 26b9b46..fffe781 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -314,12 +314,14 @@ static int hclge_configure(struct hclge_dev *hdev)
>   hdev->tx_sch_mode = HCLGE_FLAG_TC_BASE_SCH_MODE;
>  #ifdef CONFIG_HNS3_DCB
>   hdev->dcbx_cap = DCB_CAP_DCBX_VER_CEE |
> - DCB_CAP_DCBX_VER_IEEE;
> + DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
> + hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
>  #endif /* #ifdef CONFIG_HNS3_DCB */
>   } else {
>   hdev->tx_sch_mode = HCLGE_FLAG_VNET_BASE_SCH_MODE;
>  #ifdef CONFIG_HNS3_DCB
> - hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE;
> + hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
> + hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
>  #endif /* #ifdef CONFIG_HNS3_DCB */
>   }
>  
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c 
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> index 903c413..6b00982 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
> @@ -687,6 +687,11 @@ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
>   hdev->dcb_info_tmp.num_tc = hdev->dcb_info.num_tc;
>   memcpy(hdev->dcb_info_tmp.tc_info, hdev->dcb_info.tc_info,
>  HNAE3_MAX_TC * sizeof(*hdev->dcb_info.tc_info));
> +
> + if (hdev->dcb_info.num_tc > 1)
> + hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
> + else
> + hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
>  }
>  
>  static void hclge_tm_pg_info_init(struct hclge_dev *hdev)


-- 
MBR,
Yankejian (Hackim Yim)

[patch] {1620} net: hns3: add dcb cap flag in init sequence

[Kejian Yan]

If enable DCB feature, we need to add the capacity, and the current
procedure cannot setting the dcb because of no capacity flag and every
ops interface will implement by the capicity flag is enable.

Signed-off-by: Kejian Yan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 --
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c   | 5 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 26b9b46..fffe781 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -314,12 +314,14 @@ static int hclge_configure(struct hclge_dev *hdev)
hdev->tx_sch_mode = HCLGE_FLAG_TC_BASE_SCH_MODE;
 #ifdef CONFIG_HNS3_DCB
hdev->dcbx_cap = DCB_CAP_DCBX_VER_CEE |
-   DCB_CAP_DCBX_VER_IEEE;
+   DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
+   hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
 #endif /* #ifdef CONFIG_HNS3_DCB */
} else {
hdev->tx_sch_mode = HCLGE_FLAG_VNET_BASE_SCH_MODE;
 #ifdef CONFIG_HNS3_DCB
-   hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE;
+   hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
+   hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
 #endif /* #ifdef CONFIG_HNS3_DCB */
}
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index 903c413..6b00982 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -687,6 +687,11 @@ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
hdev->dcb_info_tmp.num_tc = hdev->dcb_info.num_tc;
memcpy(hdev->dcb_info_tmp.tc_info, hdev->dcb_info.tc_info,
   HNAE3_MAX_TC * sizeof(*hdev->dcb_info.tc_info));
+
+   if (hdev->dcb_info.num_tc > 1)
+   hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
+   else
+   hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
 }
 
 static void hclge_tm_pg_info_init(struct hclge_dev *hdev)
-- 
1.9.1

[patch] {1620} net: hns3: add dcb cap flag in init sequence

[Kejian Yan]

If enable DCB feature, we need to add the capacity, and the current
procedure cannot setting the dcb because of no capacity flag and every
ops interface will implement by the capicity flag is enable.

Signed-off-by: Kejian Yan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6 --
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c   | 5 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 26b9b46..fffe781 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -314,12 +314,14 @@ static int hclge_configure(struct hclge_dev *hdev)
hdev->tx_sch_mode = HCLGE_FLAG_TC_BASE_SCH_MODE;
 #ifdef CONFIG_HNS3_DCB
hdev->dcbx_cap = DCB_CAP_DCBX_VER_CEE |
-   DCB_CAP_DCBX_VER_IEEE;
+   DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
+   hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
 #endif /* #ifdef CONFIG_HNS3_DCB */
} else {
hdev->tx_sch_mode = HCLGE_FLAG_VNET_BASE_SCH_MODE;
 #ifdef CONFIG_HNS3_DCB
-   hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE;
+   hdev->dcbx_cap = DCB_CAP_DCBX_VER_IEEE | DCB_CAP_DCBX_HOST;
+   hdev->flag |= HCLGE_FLAG_DCB_CAPABLE;
 #endif /* #ifdef CONFIG_HNS3_DCB */
}
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index 903c413..6b00982 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -687,6 +687,11 @@ static void hclge_tm_tc_info_init(struct hclge_dev *hdev)
hdev->dcb_info_tmp.num_tc = hdev->dcb_info.num_tc;
memcpy(hdev->dcb_info_tmp.tc_info, hdev->dcb_info.tc_info,
   HNAE3_MAX_TC * sizeof(*hdev->dcb_info.tc_info));
+
+   if (hdev->dcb_info.num_tc > 1)
+   hdev->flag |= HCLGE_FLAG_DCB_ENABLE;
+   else
+   hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
 }
 
 static void hclge_tm_pg_info_init(struct hclge_dev *hdev)
-- 
1.9.1

Re: [RFC PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

[Yisheng Xie]

hi,
sorry to disturb, I will send another version to make a minor change
about page_lock checking in scan_movable_pages.

On 2017/1/25 11:25, Yisheng Xie wrote:
> We had considered all of the non-lru pages as unmovable before
> commit bda807d44454 ("mm: migrate: support non-lru movable page
> migration"). But now some of non-lru pages like zsmalloc,
> virtio-balloon pages also become movable. So we can offline such
> blocks by using non-lru page migration.
> 
> This patch straightforwardly add non-lru migration code, which
> means adding non-lru related code to the functions which scan
> over pfn and collect pages to be migrated and isolate them before
> migration.
> 
> Signed-off-by: Yisheng Xie 
> ---
>  mm/memory_hotplug.c | 32 +---
>  mm/page_alloc.c |  8 ++--
>  2 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e43142c1..fbdbffc 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1510,15 +1510,16 @@ int test_pages_in_a_zone(unsigned long start_pfn, 
> unsigned long end_pfn)
>  }
>  
>  /*
> - * Scan pfn range [start,end) to find movable/migratable pages (LRU pages
> - * and hugepages). We scan pfn because it's much easier than scanning over
> - * linked list. This function returns the pfn of the first found movable
> - * page if it's found, otherwise 0.
> + * Scan pfn range [start,end) to find movable/migratable pages (LRU pages,
> + * non-lru movable pages and hugepages). We scan pfn because it's much
> + * easier than scanning over linked list. This function returns the pfn
> + * of the first found movable page if it's found, otherwise 0.
>   */
>  static unsigned long scan_movable_pages(unsigned long start, unsigned long 
> end)
>  {
>   unsigned long pfn;
>   struct page *page;
> + bool movable;
>   for (pfn = start; pfn < end; pfn++) {
>   if (pfn_valid(pfn)) {
>   page = pfn_to_page(pfn);
> @@ -1531,6 +1532,11 @@ static unsigned long scan_movable_pages(unsigned long 
> start, unsigned long end)
>   pfn = round_up(pfn + 1,
>   1 << compound_order(page)) - 1;
>   }
> + lock_page(page);
> + movable = __PageMovable(page);
> + unlock_page(page);
> + if (movable)
> + return pfn;
>   }
>   }
>   return 0;
> @@ -1600,21 +1606,25 @@ static struct page *new_node_page(struct page *page, 
> unsigned long private,
>   if (!get_page_unless_zero(page))
>   continue;
>   /*
> -  * We can skip free pages. And we can only deal with pages on
> -  * LRU.
> +  * We can skip free pages. And we can deal with pages on
> +  * LRU and non-lru movable pages.
>*/
> - ret = isolate_lru_page(page);
> + if (PageLRU(page))
> + ret = isolate_lru_page(page);
> + else
> + ret = !isolate_movable_page(page, ISOLATE_UNEVICTABLE);
>   if (!ret) { /* Success */
>   put_page(page);
>   list_add_tail(>lru, );
>   move_pages--;
> - inc_node_page_state(page, NR_ISOLATED_ANON +
> - page_is_file_cache(page));
> + if (!__PageMovable(page))
> + inc_node_page_state(page, NR_ISOLATED_ANON +
> + page_is_file_cache(page));
>  
>   } else {
>  #ifdef CONFIG_DEBUG_VM
> - pr_alert("removing pfn %lx from LRU failed\n", pfn);
> - dump_page(page, "failed to remove from LRU");
> + pr_alert("failed to isolate pfn %lx\n", pfn);
> + dump_page(page, "isolation failed");
>  #endif
>   put_page(page);
>   /* Because we don't have big zone->lock. we should
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d604d25..52d3067 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7055,8 +7055,9 @@ void *__init alloc_large_system_hash(const char 
> *tablename,
>   * If @count is not zero, it is okay to include less @count unmovable pages
>   *
>   * PageLRU check without isolation or lru_lock could race so that
> - * MIGRATE_MOVABLE block might include unmovable pages. It means you can't
> - * expect this function should be exact.
> + * MIGRATE_MOVABLE block might include unmovable pages. And __PageMovable
> + * check without lock_page also may miss some movable non-lru pages at
> + * race condition. So you can't expect this function should be exact.
>   */
>  bool has_unmovable_pages(struct zone *zone, 

Re: [RFC PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

[Yisheng Xie]

hi,
sorry to disturb, I will send another version to make a minor change
about page_lock checking in scan_movable_pages.

On 2017/1/25 11:25, Yisheng Xie wrote:
> We had considered all of the non-lru pages as unmovable before
> commit bda807d44454 ("mm: migrate: support non-lru movable page
> migration"). But now some of non-lru pages like zsmalloc,
> virtio-balloon pages also become movable. So we can offline such
> blocks by using non-lru page migration.
> 
> This patch straightforwardly add non-lru migration code, which
> means adding non-lru related code to the functions which scan
> over pfn and collect pages to be migrated and isolate them before
> migration.
> 
> Signed-off-by: Yisheng Xie 
> ---
>  mm/memory_hotplug.c | 32 +---
>  mm/page_alloc.c |  8 ++--
>  2 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e43142c1..fbdbffc 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1510,15 +1510,16 @@ int test_pages_in_a_zone(unsigned long start_pfn, 
> unsigned long end_pfn)
>  }
>  
>  /*
> - * Scan pfn range [start,end) to find movable/migratable pages (LRU pages
> - * and hugepages). We scan pfn because it's much easier than scanning over
> - * linked list. This function returns the pfn of the first found movable
> - * page if it's found, otherwise 0.
> + * Scan pfn range [start,end) to find movable/migratable pages (LRU pages,
> + * non-lru movable pages and hugepages). We scan pfn because it's much
> + * easier than scanning over linked list. This function returns the pfn
> + * of the first found movable page if it's found, otherwise 0.
>   */
>  static unsigned long scan_movable_pages(unsigned long start, unsigned long 
> end)
>  {
>   unsigned long pfn;
>   struct page *page;
> + bool movable;
>   for (pfn = start; pfn < end; pfn++) {
>   if (pfn_valid(pfn)) {
>   page = pfn_to_page(pfn);
> @@ -1531,6 +1532,11 @@ static unsigned long scan_movable_pages(unsigned long 
> start, unsigned long end)
>   pfn = round_up(pfn + 1,
>   1 << compound_order(page)) - 1;
>   }
> + lock_page(page);
> + movable = __PageMovable(page);
> + unlock_page(page);
> + if (movable)
> + return pfn;
>   }
>   }
>   return 0;
> @@ -1600,21 +1606,25 @@ static struct page *new_node_page(struct page *page, 
> unsigned long private,
>   if (!get_page_unless_zero(page))
>   continue;
>   /*
> -  * We can skip free pages. And we can only deal with pages on
> -  * LRU.
> +  * We can skip free pages. And we can deal with pages on
> +  * LRU and non-lru movable pages.
>*/
> - ret = isolate_lru_page(page);
> + if (PageLRU(page))
> + ret = isolate_lru_page(page);
> + else
> + ret = !isolate_movable_page(page, ISOLATE_UNEVICTABLE);
>   if (!ret) { /* Success */
>   put_page(page);
>   list_add_tail(>lru, );
>   move_pages--;
> - inc_node_page_state(page, NR_ISOLATED_ANON +
> - page_is_file_cache(page));
> + if (!__PageMovable(page))
> + inc_node_page_state(page, NR_ISOLATED_ANON +
> + page_is_file_cache(page));
>  
>   } else {
>  #ifdef CONFIG_DEBUG_VM
> - pr_alert("removing pfn %lx from LRU failed\n", pfn);
> - dump_page(page, "failed to remove from LRU");
> + pr_alert("failed to isolate pfn %lx\n", pfn);
> + dump_page(page, "isolation failed");
>  #endif
>   put_page(page);
>   /* Because we don't have big zone->lock. we should
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d604d25..52d3067 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7055,8 +7055,9 @@ void *__init alloc_large_system_hash(const char 
> *tablename,
>   * If @count is not zero, it is okay to include less @count unmovable pages
>   *
>   * PageLRU check without isolation or lru_lock could race so that
> - * MIGRATE_MOVABLE block might include unmovable pages. It means you can't
> - * expect this function should be exact.
> + * MIGRATE_MOVABLE block might include unmovable pages. And __PageMovable
> + * check without lock_page also may miss some movable non-lru pages at
> + * race condition. So you can't expect this function should be exact.
>   */
>  bool has_unmovable_pages(struct zone *zone, struct page *page, int 

[RFC v2 PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

[Yisheng Xie]

We had considered all of the non-lru pages as unmovable before
commit bda807d44454 ("mm: migrate: support non-lru movable page
migration"). But now some of non-lru pages like zsmalloc,
virtio-balloon pages also become movable. So we can offline such
blocks by using non-lru page migration.

This patch straightforwardly add non-lru migration code, which
means adding non-lru related code to the functions which scan
over pfn and collect pages to be migrated and isolate them before
migration.

Signed-off-by: Yisheng Xie 
---
v2
 make a minor change about lock_page logic in function scan_movable_pages.

 mm/memory_hotplug.c | 36 +---
 mm/page_alloc.c |  8 ++--
 2 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e43142c1..5559175 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1510,10 +1510,10 @@ int test_pages_in_a_zone(unsigned long start_pfn, 
unsigned long end_pfn)
 }
 
 /*
- * Scan pfn range [start,end) to find movable/migratable pages (LRU pages
- * and hugepages). We scan pfn because it's much easier than scanning over
- * linked list. This function returns the pfn of the first found movable
- * page if it's found, otherwise 0.
+ * Scan pfn range [start,end) to find movable/migratable pages (LRU pages,
+ * non-lru movable pages and hugepages). We scan pfn because it's much
+ * easier than scanning over linked list. This function returns the pfn
+ * of the first found movable page if it's found, otherwise 0.
  */
 static unsigned long scan_movable_pages(unsigned long start, unsigned long end)
 {
@@ -1531,6 +1531,16 @@ static unsigned long scan_movable_pages(unsigned long 
start, unsigned long end)
pfn = round_up(pfn + 1,
1 << compound_order(page)) - 1;
}
+   /*
+* check __PageMovable in lock_page to avoid miss some
+* non-lru movable pages at race condition.
+*/
+   lock_page(page);
+   if (__PageMovable(page)) {
+   unlock_page(page);
+   return pfn;
+   }
+   unlock_page(page);
}
}
return 0;
@@ -1600,21 +1610,25 @@ static struct page *new_node_page(struct page *page, 
unsigned long private,
if (!get_page_unless_zero(page))
continue;
/*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
+* We can skip free pages. And we can deal with pages on
+* LRU and non-lru movable pages.
 */
-   ret = isolate_lru_page(page);
+   if (PageLRU(page))
+   ret = isolate_lru_page(page);
+   else
+   ret = !isolate_movable_page(page, ISOLATE_UNEVICTABLE);
if (!ret) { /* Success */
put_page(page);
list_add_tail(>lru, );
move_pages--;
-   inc_node_page_state(page, NR_ISOLATED_ANON +
-   page_is_file_cache(page));
+   if (!__PageMovable(page))
+   inc_node_page_state(page, NR_ISOLATED_ANON +
+   page_is_file_cache(page));
 
} else {
 #ifdef CONFIG_DEBUG_VM
-   pr_alert("removing pfn %lx from LRU failed\n", pfn);
-   dump_page(page, "failed to remove from LRU");
+   pr_alert("failed to isolate pfn %lx\n", pfn);
+   dump_page(page, "isolation failed");
 #endif
put_page(page);
/* Because we don't have big zone->lock. we should
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d604d25..52d3067 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7055,8 +7055,9 @@ void *__init alloc_large_system_hash(const char 
*tablename,
  * If @count is not zero, it is okay to include less @count unmovable pages
  *
  * PageLRU check without isolation or lru_lock could race so that
- * MIGRATE_MOVABLE block might include unmovable pages. It means you can't
- * expect this function should be exact.
+ * MIGRATE_MOVABLE block might include unmovable pages. And __PageMovable
+ * check without lock_page also may miss some movable non-lru pages at
+ * race condition. So you can't expect this function should be exact.
  */
 bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
 bool skip_hwpoisoned_pages)
@@ -7112,6 +7113,9 @@ bool has_unmovable_pages(struct zone *zone, struct page 
*page, int 

[RFC v2 PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

[Yisheng Xie]

We had considered all of the non-lru pages as unmovable before
commit bda807d44454 ("mm: migrate: support non-lru movable page
migration"). But now some of non-lru pages like zsmalloc,
virtio-balloon pages also become movable. So we can offline such
blocks by using non-lru page migration.

This patch straightforwardly add non-lru migration code, which
means adding non-lru related code to the functions which scan
over pfn and collect pages to be migrated and isolate them before
migration.

Signed-off-by: Yisheng Xie 
---
v2
 make a minor change about lock_page logic in function scan_movable_pages.

 mm/memory_hotplug.c | 36 +---
 mm/page_alloc.c |  8 ++--
 2 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e43142c1..5559175 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1510,10 +1510,10 @@ int test_pages_in_a_zone(unsigned long start_pfn, 
unsigned long end_pfn)
 }
 
 /*
- * Scan pfn range [start,end) to find movable/migratable pages (LRU pages
- * and hugepages). We scan pfn because it's much easier than scanning over
- * linked list. This function returns the pfn of the first found movable
- * page if it's found, otherwise 0.
+ * Scan pfn range [start,end) to find movable/migratable pages (LRU pages,
+ * non-lru movable pages and hugepages). We scan pfn because it's much
+ * easier than scanning over linked list. This function returns the pfn
+ * of the first found movable page if it's found, otherwise 0.
  */
 static unsigned long scan_movable_pages(unsigned long start, unsigned long end)
 {
@@ -1531,6 +1531,16 @@ static unsigned long scan_movable_pages(unsigned long 
start, unsigned long end)
pfn = round_up(pfn + 1,
1 << compound_order(page)) - 1;
}
+   /*
+* check __PageMovable in lock_page to avoid miss some
+* non-lru movable pages at race condition.
+*/
+   lock_page(page);
+   if (__PageMovable(page)) {
+   unlock_page(page);
+   return pfn;
+   }
+   unlock_page(page);
}
}
return 0;
@@ -1600,21 +1610,25 @@ static struct page *new_node_page(struct page *page, 
unsigned long private,
if (!get_page_unless_zero(page))
continue;
/*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
+* We can skip free pages. And we can deal with pages on
+* LRU and non-lru movable pages.
 */
-   ret = isolate_lru_page(page);
+   if (PageLRU(page))
+   ret = isolate_lru_page(page);
+   else
+   ret = !isolate_movable_page(page, ISOLATE_UNEVICTABLE);
if (!ret) { /* Success */
put_page(page);
list_add_tail(>lru, );
move_pages--;
-   inc_node_page_state(page, NR_ISOLATED_ANON +
-   page_is_file_cache(page));
+   if (!__PageMovable(page))
+   inc_node_page_state(page, NR_ISOLATED_ANON +
+   page_is_file_cache(page));
 
} else {
 #ifdef CONFIG_DEBUG_VM
-   pr_alert("removing pfn %lx from LRU failed\n", pfn);
-   dump_page(page, "failed to remove from LRU");
+   pr_alert("failed to isolate pfn %lx\n", pfn);
+   dump_page(page, "isolation failed");
 #endif
put_page(page);
/* Because we don't have big zone->lock. we should
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d604d25..52d3067 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7055,8 +7055,9 @@ void *__init alloc_large_system_hash(const char 
*tablename,
  * If @count is not zero, it is okay to include less @count unmovable pages
  *
  * PageLRU check without isolation or lru_lock could race so that
- * MIGRATE_MOVABLE block might include unmovable pages. It means you can't
- * expect this function should be exact.
+ * MIGRATE_MOVABLE block might include unmovable pages. And __PageMovable
+ * check without lock_page also may miss some movable non-lru pages at
+ * race condition. So you can't expect this function should be exact.
  */
 bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
 bool skip_hwpoisoned_pages)
@@ -7112,6 +7113,9 @@ bool has_unmovable_pages(struct zone *zone, struct page 
*page, int count,

Re: [PATCH 2/3] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

[Hillf Danton]

On Tuesday, January 24, 2017 8:41 PM Michal Hocko wrote: 
> On Fri 20-01-17 16:33:36, Hillf Danton wrote:
> >
> > On Tuesday, December 20, 2016 9:49 PM Michal Hocko wrote:
> > >
> > > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc)
> > >* make sure exclude 0 mask - all other users should have at least
> > >* ___GFP_DIRECT_RECLAIM to get here.
> > >*/
> > > - if (oc->gfp_mask && !(oc->gfp_mask & (__GFP_FS|__GFP_NOFAIL)))
> > > + if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
> > >   return true;
> > >
> > As to GFP_NOFS|__GFP_NOFAIL request, can we check gfp mask
> > one bit after another?
> >
> > if (oc->gfp_mask) {
> > if (!(oc->gfp_mask & __GFP_FS))
> > return false;
> >
> > /* No service for request that can handle fail result itself */
> > if (!(oc->gfp_mask & __GFP_NOFAIL))
> > return false;
> > }
> 
> I really do not understand this request. 

It's a request of both NOFS and NOFAIL, and I think we can keep it from
hitting oom killer by shuffling the current gfp checks.
I hope it can make nit sense to your work.

> This patch is removing the __GFP_NOFAIL part... 

Yes, and I don't stick to handling NOFAIL requests inside oom.
 
> Besides that why should they return false?

It's feedback to page allocator that no kill is issued, and 
extra attention is needed.

thanks
Hillf

Re: [PATCH 2/3] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

[Hillf Danton]

On Tuesday, January 24, 2017 8:41 PM Michal Hocko wrote: 
> On Fri 20-01-17 16:33:36, Hillf Danton wrote:
> >
> > On Tuesday, December 20, 2016 9:49 PM Michal Hocko wrote:
> > >
> > > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc)
> > >* make sure exclude 0 mask - all other users should have at least
> > >* ___GFP_DIRECT_RECLAIM to get here.
> > >*/
> > > - if (oc->gfp_mask && !(oc->gfp_mask & (__GFP_FS|__GFP_NOFAIL)))
> > > + if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
> > >   return true;
> > >
> > As to GFP_NOFS|__GFP_NOFAIL request, can we check gfp mask
> > one bit after another?
> >
> > if (oc->gfp_mask) {
> > if (!(oc->gfp_mask & __GFP_FS))
> > return false;
> >
> > /* No service for request that can handle fail result itself */
> > if (!(oc->gfp_mask & __GFP_NOFAIL))
> > return false;
> > }
> 
> I really do not understand this request. 

It's a request of both NOFS and NOFAIL, and I think we can keep it from
hitting oom killer by shuffling the current gfp checks.
I hope it can make nit sense to your work.

> This patch is removing the __GFP_NOFAIL part... 

Yes, and I don't stick to handling NOFAIL requests inside oom.
 
> Besides that why should they return false?

It's feedback to page allocator that no kill is issued, and 
extra attention is needed.

thanks
Hillf

Re: [PATCH] memory: tegra: Add a missing 'of_node_put()' call

[Thierry Reding]

On Wed, Jan 04, 2017 at 08:13:24AM +0100, Christophe JAILLET wrote:
> If 'of_find_device_by_node()' fails, an 'of_node_put()' call is missing in
> the error handling path.
> Fix it by reordering the code.
> 
> While at it, remove some empty lines in a more or less similar construction
> a few lines below.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/memory/tegra/tegra124-emc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] memory: tegra: Add a missing 'of_node_put()' call

[Thierry Reding]

On Wed, Jan 04, 2017 at 08:13:24AM +0100, Christophe JAILLET wrote:
> If 'of_find_device_by_node()' fails, an 'of_node_put()' call is missing in
> the error handling path.
> Fix it by reordering the code.
> 
> While at it, remove some empty lines in a more or less similar construction
> a few lines below.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/memory/tegra/tegra124-emc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [RESEND PATCH 0/6] apalis-tk1: updates for v1.1 hw

[Thierry Reding]

On Tue, Jan 03, 2017 at 01:20:48PM +, Marcel Ziswiler wrote:
> On Thu, 2016-11-24 at 02:04 +0100, mar...@ziswiler.com wrote:
> > From: Marcel Ziswiler 
> > 
> > 
> > This series updates the device tree for the upcoming V1.1 HW samples.
> > All changes are purely opportunistic meaning they fix stuff which on
> > older HW was anyway broken so there should be no backwards
> > compatibility issues.
> > 
> > 
> > Marcel Ziswiler (6):
> >   apalis-tk1: remove spurious new lines
> >   apalis-tk1: temp alert pull-up
> >   apalis-tk1: optional displayport hot-plug detect
> >   apalis-tk1: adjust pin muxing for v1.1 hw
> >   apalis-tk1: working sd card detect on v1.1 hw
> >   apalis-tk1: update compatibility comment
> > 
> >  arch/arm/boot/dts/tegra124-apalis-eval.dts | 11 +
> >  arch/arm/boot/dts/tegra124-apalis.dtsi | 73 +++-
> > --
> >  2 files changed, 29 insertions(+), 55 deletions(-)

Applied all but the first, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [RESEND PATCH 0/6] apalis-tk1: updates for v1.1 hw

[Thierry Reding]

On Tue, Jan 03, 2017 at 01:20:48PM +, Marcel Ziswiler wrote:
> On Thu, 2016-11-24 at 02:04 +0100, mar...@ziswiler.com wrote:
> > From: Marcel Ziswiler 
> > 
> > 
> > This series updates the device tree for the upcoming V1.1 HW samples.
> > All changes are purely opportunistic meaning they fix stuff which on
> > older HW was anyway broken so there should be no backwards
> > compatibility issues.
> > 
> > 
> > Marcel Ziswiler (6):
> >   apalis-tk1: remove spurious new lines
> >   apalis-tk1: temp alert pull-up
> >   apalis-tk1: optional displayport hot-plug detect
> >   apalis-tk1: adjust pin muxing for v1.1 hw
> >   apalis-tk1: working sd card detect on v1.1 hw
> >   apalis-tk1: update compatibility comment
> > 
> >  arch/arm/boot/dts/tegra124-apalis-eval.dts | 11 +
> >  arch/arm/boot/dts/tegra124-apalis.dtsi | 73 +++-
> > --
> >  2 files changed, 29 insertions(+), 55 deletions(-)

Applied all but the first, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] drm: tegra: shut up harmless warning on NOMMU

[Thierry Reding]

On Thu, Jan 19, 2017 at 04:09:47PM +0100, Arnd Bergmann wrote:
> On Thursday, January 19, 2017 12:00:58 PM CET Thierry Reding wrote:
> > On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote:
> > > The tegra DRM driver is almost ok without an MMU, but there
> > > is one small warning that I get:
> > > 
> > > drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
> > > drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'
> > > 
> > > This marks the variable as __maybe_unused instead.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > ---
> > >  drivers/gpu/drm/tegra/gem.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> > > index 7d853e6b5ff0..63f14b7a59a0 100644
> > > --- a/drivers/gpu/drm/tegra/gem.c
> > > +++ b/drivers/gpu/drm/tegra/gem.c
> > > @@ -505,7 +505,7 @@ int tegra_drm_mmap(struct file *file, struct 
> > > vm_area_struct *vma)
> > >  
> > >   vma->vm_pgoff = vm_pgoff;
> > >   } else {
> > > - pgprot_t prot = vm_get_page_prot(vma->vm_flags);
> > > + pgprot_t prot __maybe_unused = vm_get_page_prot(vma->vm_flags);
> > 
> > This seems to me like a suboptimal solution. The reason why this fails
> > is because pgprot_writecombine(prot) for NOMMU translates to __pgprot(0)
> > via a macro. This also means that we need to potentially add a
> > __maybe_unused annotation to every local variable that stores a value
> > that gets passed to pgprot_writecombine().
> > 
> > There fortunately aren't very many of those cases, but I still think
> > that a better solution would be to turn pgprot_writecombine() into a
> > static inline function, so that the parameter would get silently
> > ignored. Or perhaps if it must remain a macro, then doing the following
> > should still avoid the need to modify every call site:
> > 
> > #define pgprot_writecombine(prot) ({ (void)prot; __pgprot(0); })
> > 
> > Thierry
> > 
> 
> Makes sense. How about this version?
> 
>   Arnd
> ---
> From 83af6bc74423c90be7f580a827268b89f94b5c6b Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann 
> Date: Thu, 19 Jan 2017 16:05:29 +0100
> Subject: [PATCH] ARM: improve NOMMU definition of pgprot_*()
> 
> The tegra DRM driver produces a harmless warning when built for NOMMU:
> 
> drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
> drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'
> 
> This is because pgprot_writecombine() on ARM returns a constant and
> ignores its argument. The version in asm-generic doesn't have that
> problem, so let's use that one instead. We don't actually care
> about the value on NOMMU, and this is consistent with what some
> other architectures do.
> 
> Signed-off-by: Arnd Bergmann 
> 
> diff --git a/arch/arm/include/asm/pgtable-nommu.h 
> b/arch/arm/include/asm/pgtable-nommu.h
> index add094d09e3e..302240c19a5a 100644
> --- a/arch/arm/include/asm/pgtable-nommu.h
> +++ b/arch/arm/include/asm/pgtable-nommu.h
> @@ -63,9 +63,9 @@ typedef pte_t *pte_addr_t;
>  /*
>   * Mark the prot value as uncacheable and unbufferable.
>   */
> -#define pgprot_noncached(prot)   __pgprot(0)
> -#define pgprot_writecombine(prot) __pgprot(0)
> -#define pgprot_dmacoherent(prot) __pgprot(0)
> +#define pgprot_noncached(prot)   (prot)
> +#define pgprot_writecombine(prot) (prot)
> +#define pgprot_dmacoherent(prot) (prot)
>  
>  
>  /*
> 

I remember writing a reply to this, but it seems like I never sent it
out. The above looks good to me:

Acked-by: Thierry Reding 



signature.asc
Description: PGP signature

Re: [PATCH] drm: tegra: shut up harmless warning on NOMMU

[Thierry Reding]

On Thu, Jan 19, 2017 at 04:09:47PM +0100, Arnd Bergmann wrote:
> On Thursday, January 19, 2017 12:00:58 PM CET Thierry Reding wrote:
> > On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote:
> > > The tegra DRM driver is almost ok without an MMU, but there
> > > is one small warning that I get:
> > > 
> > > drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
> > > drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'
> > > 
> > > This marks the variable as __maybe_unused instead.
> > > 
> > > Signed-off-by: Arnd Bergmann 
> > > ---
> > >  drivers/gpu/drm/tegra/gem.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> > > index 7d853e6b5ff0..63f14b7a59a0 100644
> > > --- a/drivers/gpu/drm/tegra/gem.c
> > > +++ b/drivers/gpu/drm/tegra/gem.c
> > > @@ -505,7 +505,7 @@ int tegra_drm_mmap(struct file *file, struct 
> > > vm_area_struct *vma)
> > >  
> > >   vma->vm_pgoff = vm_pgoff;
> > >   } else {
> > > - pgprot_t prot = vm_get_page_prot(vma->vm_flags);
> > > + pgprot_t prot __maybe_unused = vm_get_page_prot(vma->vm_flags);
> > 
> > This seems to me like a suboptimal solution. The reason why this fails
> > is because pgprot_writecombine(prot) for NOMMU translates to __pgprot(0)
> > via a macro. This also means that we need to potentially add a
> > __maybe_unused annotation to every local variable that stores a value
> > that gets passed to pgprot_writecombine().
> > 
> > There fortunately aren't very many of those cases, but I still think
> > that a better solution would be to turn pgprot_writecombine() into a
> > static inline function, so that the parameter would get silently
> > ignored. Or perhaps if it must remain a macro, then doing the following
> > should still avoid the need to modify every call site:
> > 
> > #define pgprot_writecombine(prot) ({ (void)prot; __pgprot(0); })
> > 
> > Thierry
> > 
> 
> Makes sense. How about this version?
> 
>   Arnd
> ---
> From 83af6bc74423c90be7f580a827268b89f94b5c6b Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann 
> Date: Thu, 19 Jan 2017 16:05:29 +0100
> Subject: [PATCH] ARM: improve NOMMU definition of pgprot_*()
> 
> The tegra DRM driver produces a harmless warning when built for NOMMU:
> 
> drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
> drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'
> 
> This is because pgprot_writecombine() on ARM returns a constant and
> ignores its argument. The version in asm-generic doesn't have that
> problem, so let's use that one instead. We don't actually care
> about the value on NOMMU, and this is consistent with what some
> other architectures do.
> 
> Signed-off-by: Arnd Bergmann 
> 
> diff --git a/arch/arm/include/asm/pgtable-nommu.h 
> b/arch/arm/include/asm/pgtable-nommu.h
> index add094d09e3e..302240c19a5a 100644
> --- a/arch/arm/include/asm/pgtable-nommu.h
> +++ b/arch/arm/include/asm/pgtable-nommu.h
> @@ -63,9 +63,9 @@ typedef pte_t *pte_addr_t;
>  /*
>   * Mark the prot value as uncacheable and unbufferable.
>   */
> -#define pgprot_noncached(prot)   __pgprot(0)
> -#define pgprot_writecombine(prot) __pgprot(0)
> -#define pgprot_dmacoherent(prot) __pgprot(0)
> +#define pgprot_noncached(prot)   (prot)
> +#define pgprot_writecombine(prot) (prot)
> +#define pgprot_dmacoherent(prot) (prot)
>  
>  
>  /*
> 

I remember writing a reply to this, but it seems like I never sent it
out. The above looks good to me:

Acked-by: Thierry Reding 



signature.asc
Description: PGP signature

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

[Pratyush Anand]

Hi Dave,

On Wednesday 25 January 2017 11:59 AM, Dave Young wrote:

Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
not true and could be misleading, since 0 is a valid physical address.

I do not know the history of /proc/kcore, so a question is why the
p_addr was set as 0, if there were some reasons and if this could cause
some risk or breakage.



I do not know why it was 0, which is a valid physical address. But 
certainly, it might break some user space tools, and those need to be 
fixed. For example, see following code from kexec-tools


kexec/kexec-elf.c:build_mem_phdrs()

435 if ((phdr->p_paddr + phdr->p_memsz) < phdr->p_paddr) {
436 /* The memory address wraps */
437 if (probe_debug) {
438 fprintf(stderr, "ELF address wrap 
around\n");

439 }
440 return -1;
441 }

We do not need to perform above check for an invalid physical address.

I think, kexec-tools and makedumpfile will need fixup. I already have 
those fixup which will be sent upstream once this patch makes through.
Pro with this approach is that, it will help to calculate variable like 
page_offset, phys_base from PT_LOAD even when they are randomized and 
therefore will reduce many variable and version specific values in user 
space tools.


~Pratyush

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

[Pratyush Anand]

Hi Dave,

On Wednesday 25 January 2017 11:59 AM, Dave Young wrote:

Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
not true and could be misleading, since 0 is a valid physical address.

I do not know the history of /proc/kcore, so a question is why the
p_addr was set as 0, if there were some reasons and if this could cause
some risk or breakage.



I do not know why it was 0, which is a valid physical address. But 
certainly, it might break some user space tools, and those need to be 
fixed. For example, see following code from kexec-tools


kexec/kexec-elf.c:build_mem_phdrs()

435 if ((phdr->p_paddr + phdr->p_memsz) < phdr->p_paddr) {
436 /* The memory address wraps */
437 if (probe_debug) {
438 fprintf(stderr, "ELF address wrap 
around\n");

439 }
440 return -1;
441 }

We do not need to perform above check for an invalid physical address.

I think, kexec-tools and makedumpfile will need fixup. I already have 
those fixup which will be sent upstream once this patch makes through.
Pro with this approach is that, it will help to calculate variable like 
page_offset, phys_base from PT_LOAD even when they are randomized and 
therefore will reduce many variable and version specific values in user 
space tools.


~Pratyush

Re: [PATCH] nvdimm: constify device_type structures

[Julia Lawall]

On Tue, 24 Jan 2017, Joe Perches wrote:

> On Tue, 2017-01-24 at 18:40 -0800, Dan Williams wrote:
> > On Tue, Jan 24, 2017 at 6:37 PM, Joe Perches  wrote:
> > > On Wed, 2017-01-25 at 00:54 +0530, Bhumika Goyal wrote:
> > > > Declare device_type structure as const as it is only stored in the
> > > > type field of a device structure. This field is of type const, so add
> > > > const to declaration of device_type structure.
> > > >
> > > > File size before:
> > > >   text   data bss dec hex filename
> > > >   19278  3199  16   2249357dd nvdimm/namespace_devs.o
> > > >
> > > > File size after:
> > > >   text   data bss dec hex filename
> > > >   19929  3160  16   231055a41 nvdimm/namespace_devs.o
> > >
> > > Fine, but are you sure about the sizes?
> > >
> > > It seems odd the text went up 651 bytes
> > > while the data went down just 39 bytes.
> > >
> >
> > Right, the size data wasn't why I applied it. It was the general rule
> > of "make function pointer data read-only whenever possible to
> > eliminate a kernel attack vector".
>
> Exactly the correct reason it's a fine patch and one
> that should be applied.
>
> > Bhumika, you might want to mention
> > this as the motivating reason to apply the patch if you do more of
> > these changes.
>
> Regardless, the object sizes are still odd.
>
> The config should be mentioned because actually,
> the commonly compiles sizes reported are not correct.
>
> with an x86-64 defconfig I get:
>
> $ size drivers/nvdimm/namespace_devs.o*
>    text      data bss dec hex filename
>   14615   519  16   15150    3b2e 
> drivers/nvdimm/namespace_devs.o.new
>   14439   695  16   15150    3b2e 
> drivers/nvdimm/namespace_devs.o.old

What does the data column actually represent?  I tried size on the .o file
generated from:

commit a65f0161f4d69d6738d4821e649448312cd818e2
Author: Stephen Rothwell 
Date:   Tue Jan 17 15:22:28 2017 +1100

with CONFIG_X86_64=y and I get:

   textdata bss dec hex filename
  197263480  16   232225ab6 drivers/nvdimm/namespace_devs.o

but when I run objdump -sh drivers/nvdimm/namespace_devs.o, I find a .data
segment of size 1008 and a .data.unlikely segment of size 8, which don't
match up with the results of size.

julia

Re: [PATCH] nvdimm: constify device_type structures

[Julia Lawall]

On Tue, 24 Jan 2017, Joe Perches wrote:

> On Tue, 2017-01-24 at 18:40 -0800, Dan Williams wrote:
> > On Tue, Jan 24, 2017 at 6:37 PM, Joe Perches  wrote:
> > > On Wed, 2017-01-25 at 00:54 +0530, Bhumika Goyal wrote:
> > > > Declare device_type structure as const as it is only stored in the
> > > > type field of a device structure. This field is of type const, so add
> > > > const to declaration of device_type structure.
> > > >
> > > > File size before:
> > > >   text   data bss dec hex filename
> > > >   19278  3199  16   2249357dd nvdimm/namespace_devs.o
> > > >
> > > > File size after:
> > > >   text   data bss dec hex filename
> > > >   19929  3160  16   231055a41 nvdimm/namespace_devs.o
> > >
> > > Fine, but are you sure about the sizes?
> > >
> > > It seems odd the text went up 651 bytes
> > > while the data went down just 39 bytes.
> > >
> >
> > Right, the size data wasn't why I applied it. It was the general rule
> > of "make function pointer data read-only whenever possible to
> > eliminate a kernel attack vector".
>
> Exactly the correct reason it's a fine patch and one
> that should be applied.
>
> > Bhumika, you might want to mention
> > this as the motivating reason to apply the patch if you do more of
> > these changes.
>
> Regardless, the object sizes are still odd.
>
> The config should be mentioned because actually,
> the commonly compiles sizes reported are not correct.
>
> with an x86-64 defconfig I get:
>
> $ size drivers/nvdimm/namespace_devs.o*
>    text      data bss dec hex filename
>   14615   519  16   15150    3b2e 
> drivers/nvdimm/namespace_devs.o.new
>   14439   695  16   15150    3b2e 
> drivers/nvdimm/namespace_devs.o.old

What does the data column actually represent?  I tried size on the .o file
generated from:

commit a65f0161f4d69d6738d4821e649448312cd818e2
Author: Stephen Rothwell 
Date:   Tue Jan 17 15:22:28 2017 +1100

with CONFIG_X86_64=y and I get:

   textdata bss dec hex filename
  197263480  16   232225ab6 drivers/nvdimm/namespace_devs.o

but when I run objdump -sh drivers/nvdimm/namespace_devs.o, I find a .data
segment of size 1008 and a .data.unlikely segment of size 8, which don't
match up with the results of size.

julia

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

[kbuild test robot]

Hi Gideon,

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

url:
https://github.com/0day-ci/linux/commits/Gideon-Israel-Dsouza/compiler-gcc-h-Added-new-macro-for-gcc-attribute/20170125-025425
base:   https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git 
for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All error/warnings (new ones prefixed by >>):

 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:146:36: error: parameter '__param_str_major_num' 
is initialized
 param_check_##type(name, &(value));   \
   ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:49: error: storage class specified for 
parameter '__param_major_num'
 static struct kernel_param __moduleparam_const __param_##name \
^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:16: error: parameter '__param_major_num' is 
initialized
 static struct kernel_param __moduleparam_const __param_##name \
   ^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:16: warning: '__used__' attribute ignored 
[-Wattributes]
 static struct kernel_param __moduleparam_const __param_##name \
   ^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:49: error: section attribute not allowed for 
'__param_major_num'
 static struct kernel_param __moduleparam_const __param_##name \
^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:49: error: alignment may not be specified 
for '__param_major_num'
 static struct kernel_param __moduleparam_const __param_##name \
^
   include/linux/moduleparam.h:1

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

[kbuild test robot]

Hi Gideon,

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

url:
https://github.com/0day-ci/linux/commits/Gideon-Israel-Dsouza/compiler-gcc-h-Added-new-macro-for-gcc-attribute/20170125-025425
base:   https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git 
for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All error/warnings (new ones prefixed by >>):

 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:146:36: error: parameter '__param_str_major_num' 
is initialized
 param_check_##type(name, &(value));   \
   ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:49: error: storage class specified for 
parameter '__param_major_num'
 static struct kernel_param __moduleparam_const __param_##name \
^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:16: error: parameter '__param_major_num' is 
initialized
 static struct kernel_param __moduleparam_const __param_##name \
   ^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:16: warning: '__used__' attribute ignored 
[-Wattributes]
 static struct kernel_param __moduleparam_const __param_##name \
   ^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:49: error: section attribute not allowed for 
'__param_major_num'
 static struct kernel_param __moduleparam_const __param_##name \
^
   include/linux/moduleparam.h:167:2: note: in expansion of macro 
'__module_param_call'
 __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1, 0)
 ^
   include/linux/moduleparam.h:147:2: note: in expansion of macro 
'module_param_cb'
 module_param_cb(name, _ops_##type, , perm); \
 ^
   include/linux/moduleparam.h:126:2: note: in expansion of macro 
'module_param_named'
 module_param_named(name, name, type, perm)
 ^
   arch/m68k/emu/nfblock.c:51:1: note: in expansion of macro 'module_param'
module_param(major_num, int, 0);
^
   include/linux/moduleparam.h:221:49: error: alignment may not be specified 
for '__param_major_num'
 static struct kernel_param __moduleparam_const __param_##name \
^
   include/linux/moduleparam.h:1

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark,

On 25 January 2017 at 01:24, Mark Rutland  wrote:
> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>> From: Fu Wei 
>>
>> The counter frequency detection call(arch_timer_detect_rate) combines two
>> ways to get counter frequency: system coprocessor register and MMIO timer.
>> But in a specific timer init code, we only need one way to try:
>> getting frequency from MMIO timer register will be needed only when we
>> init MMIO timer; getting frequency from system coprocessor register will
>> be needed only when we init arch timer.
>
> When I mentioned this splitting before, I had mean that we'd completely
> separate the two, with separate mmio_rate and sysreg_rate variables.

sorry for misunderstanding.

Are you saying :

diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 663a57a..eec92f6 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -65,7 +65,8 @@ struct arch_timer {

 #define to_arch_timer(e) container_of(e, struct arch_timer, evt)

-static u32 arch_timer_rate;
+static u32 arch_timer_sysreg_rate ;
+static u32 arch_timer_mmio_rate;
 static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];

 static struct clock_event_device __percpu *arch_timer_evt;


But what have I learned From ARMv8 ARM is
AArch64 System register CNTFRQ_EL0 is provided so that software can
discover the frequency of the system counter.
CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
discover the frequency of the system counter.
The bit assignments of the registers are identical in the System
register interface and in the memory-mapped system level interface.
So I think they both contain the same value : the frequency of the
system counter, just in different view, and can be accessed in
different ways.

So do we really need to separate mmio_rate and sysreg_rate variables?

And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
Linux kernel (EL1),
Because ARMv8 ARM says:
In a system that implements both Secure and Non-secure states, this
register is only accessible by Secure accesses.
That means we still need to get the frequency of the system counter
from CNTFRQ_EL0 in MMIO timer code.
This have been proved when I tested this driver on foundation model, I
got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)

So I guess the logic of the original code is
 static u32 arch_timer_rate keeps the frequency of the system counter,
 no matter where the value comes from.
Because  they should be the same value. if we have got the frequency
of the system counter(arch_timer_rate != 0), then we don't need to get
it again, even in anther way.

But  the above is just my thought, and I believe you're the expert of
ARM. So please correct me if I misunderstand something.  :-)

Thanks!
>
> The probing logic relying on this is complicated and fragile, and I
> think these patches are complicating that further (though I appreciate
> that's far from the intent).
>
> I believe we need to split the MMIO and sysreg timer code apart
> entirely. I've had a look at that today, though it's been fairly painful
> so far. It appears some platforms may inadvertently be relying on the
> order and manner in which the rates are probed, which is a major
> headache.
>
> I will try to attack that some more tomorrow.
>
>> This patch separates paths to determine frequency:
>> Separate out the MMIO frequency and the sysreg frequency detection call,
>> and use the appropriate one for the counter.
>>
>> Signed-off-by: Fu Wei 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 40 
>> ++--
>>  1 file changed, 25 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>> b/drivers/clocksource/arm_arch_timer.c
>> index 6484f84..9482481 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -488,23 +488,33 @@ static int arch_timer_starting_cpu(unsigned int cpu)
>>   return 0;
>>  }
>>
>> -static void arch_timer_detect_rate(void __iomem *cntbase)
>> +static void __arch_timer_determine_rate(u32 rate)
>>  {
>> - /* Who has more than one independent system counter? */
>> - if (arch_timer_rate)
>> - return;
>> + /* Check the timer frequency. */
>> + if (!arch_timer_rate) {
>> + if (rate)
>> + arch_timer_rate = rate;
>> + else
>> + pr_warn("frequency not available\n");
>> + } else if (rate && arch_timer_rate != rate) {
>> + pr_warn("got different frequency, keep original.\n");
>> + }
>> +}
>
> This function should be killed off entirely. We need to be able to fail
> the probe if we cannot determine the rate, and that means we need error
> handling in the ACPI and DT cases anyway.
>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red 

[GIT PULL] extcon next for v4.11

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.11. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.11

for you to fetch changes up to 567ab5a81ba569b823b51f4af74f26c437e98b56:

  extcon: palmas: Use dev_dbg macro for the debug messages (2017-01-25 15:03:54 
+0900)


Update extcon for 4.11

Detailed description for this pull request:
1. Add the new extcon driver.
- Intel INT3496 ACPI USB id detection driver detects whether
  EXTCON_USB_HOST is attached or detached. (extcon-intel-int3496.c)

2. Add the new type of external connector.
- EXTCON_CHG_USB_PD (USB Power Delivery) provides the increased
  power more than 7.5W to device with larger power demand.

3. Add the description for EXTCON_CHG_USB_(SDP|ACA|SLOW|FAST)
- EXTCON_CHG_USB_SDP should always appear together with EXTCON_USB
- EXTCON_CHG_USB_ACA would normally appear with EXTCON_USB_HOST.
- EXTCON_CHG_USB_SLOW can provide at least 500mA of current at 5V
- EXTCON_CHG_USB_FAST can provide at least 1A of current at 5V.

4. Modify the connector name of EXTCON_USB_HOST
- "USB_HOST" -> "USB-HOST"

5. Update the extcon core
- Move the private extcon structure into driver/extcon directory.
  The 'struct extcon_dev' should be only handled by extcon core
  to prevent the direct access and to maintain the integrity of it.
- Remove the ambigous operation of extcon_register_notifier()
  in case of the 'extcon_dev' instance is NULL. The user of
  extcon_register_notifier() have to specify the correct instance
  of the provider extcon driver.

6. Update the extcon drivers and fix the minor issues
- Update the extcon-axp288 driver to remove the unncessary code.
- Add pinctrl operation during suspend mode to extcon-usb-gpio driver.
- Clean up the extcon-arizona/adc-jack driver.
- Use the dev_dbg() for debug messsage on extcon-palmas driver.
- Return the error code on failure of extcon_sync()


Baolin Wang (3):
  extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*
  extcon: axp288: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
  extcon: Add documentation for EXTCON_CHG_USB_SLOW/FAST

Chanwoo Choi (5):
  extcon: Remove potential problem when calling extcon_register_notifier()
  extcon: adc-jack: Use the internal data instead of using struct extcon_dev
  extcon: Move defintion of struct extcon_dev to driver/extcon directory
  extcon: Add new EXTCON_CHG_USB_PD type for USB Power Delivery
  extcon: Modify the name of EXTCON_USB_HOST connector

Charles Keepax (1):
  extcon: arizona: Simplify micd_pol_gpio handling

David Cohen (1):
  extcon: int3496: Add Intel INT3496 ACPI device extcon driver

Hans de Goede (7):
  extcon: axp288: Remove dependency on non-existing platform_data
  extcon: axp288: Remove usb_phy notification code
  extcon: axp288: Simplify axp288_handle_chrg_det_event
  extcon: axp288: Fix possibly reporting 2 cables in state true
  extcon: axp288: Use vbus-valid instead of -present to determine cable 
presence
  extcon: axp288: Remove unnecessary irq?_en register writes
  extcon: axp288: Fix the module not auto-loading

Pan Bian (1):
  extcon: Return error code on failure

Peter Chen (1):
  extcon: usb-gpio: Add pinctrl operation during system PM

Peter Foley (1):
  extcon: adc-jack: Fix incompatible pointer type warning

Roger Quadros (2):
  extcon: palmas: Check the parent instance to prevent the NULL
  extcon: palmas: Use dev_dbg macro for the debug messages

Srikant Ritolia (1):
  extcon: Restructure multi-line comments to follow codingstyle

 Documentation/extcon/intel-int3496.txt |  22 
 drivers/extcon/Kconfig |  10 ++
 drivers/extcon/Makefile|   1 +
 drivers/extcon/devres.c|   2 +-
 drivers/extcon/extcon-adc-jack.c   |   2 +-
 drivers/extcon/extcon-arizona.c|  20 ++--
 drivers/extcon/extcon-axp288.c | 110 
 drivers/extcon/extcon-intel-int3496.c  | 179 +
 drivers/extcon/extcon-max14577.c   |   6 +-
 drivers/extcon/extcon-max77693.c   |  12 ++-
 drivers/extcon/extcon-max77843.c   |  24 +++--
 drivers/extcon/extcon-palmas.c |  21 ++--
 drivers/extcon/extcon-rt8973a.c|   6 +-
 drivers/extcon/extcon-sm5502.c |   6 +-
 drivers/extcon/extcon-usb-gpio.c   |   7 ++
 drivers/extcon/extcon.c|  45 +++--
 drivers/extcon/extcon.h|  62 
 include/linux/extcon.h |  71 

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

[Fu Wei]

Hi Mark,

On 25 January 2017 at 01:24, Mark Rutland  wrote:
> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
>> From: Fu Wei 
>>
>> The counter frequency detection call(arch_timer_detect_rate) combines two
>> ways to get counter frequency: system coprocessor register and MMIO timer.
>> But in a specific timer init code, we only need one way to try:
>> getting frequency from MMIO timer register will be needed only when we
>> init MMIO timer; getting frequency from system coprocessor register will
>> be needed only when we init arch timer.
>
> When I mentioned this splitting before, I had mean that we'd completely
> separate the two, with separate mmio_rate and sysreg_rate variables.

sorry for misunderstanding.

Are you saying :

diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 663a57a..eec92f6 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -65,7 +65,8 @@ struct arch_timer {

 #define to_arch_timer(e) container_of(e, struct arch_timer, evt)

-static u32 arch_timer_rate;
+static u32 arch_timer_sysreg_rate ;
+static u32 arch_timer_mmio_rate;
 static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];

 static struct clock_event_device __percpu *arch_timer_evt;


But what have I learned From ARMv8 ARM is
AArch64 System register CNTFRQ_EL0 is provided so that software can
discover the frequency of the system counter.
CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
discover the frequency of the system counter.
The bit assignments of the registers are identical in the System
register interface and in the memory-mapped system level interface.
So I think they both contain the same value : the frequency of the
system counter, just in different view, and can be accessed in
different ways.

So do we really need to separate mmio_rate and sysreg_rate variables?

And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
Linux kernel (EL1),
Because ARMv8 ARM says:
In a system that implements both Secure and Non-secure states, this
register is only accessible by Secure accesses.
That means we still need to get the frequency of the system counter
from CNTFRQ_EL0 in MMIO timer code.
This have been proved when I tested this driver on foundation model, I
got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)

So I guess the logic of the original code is
 static u32 arch_timer_rate keeps the frequency of the system counter,
 no matter where the value comes from.
Because  they should be the same value. if we have got the frequency
of the system counter(arch_timer_rate != 0), then we don't need to get
it again, even in anther way.

But  the above is just my thought, and I believe you're the expert of
ARM. So please correct me if I misunderstand something.  :-)

Thanks!
>
> The probing logic relying on this is complicated and fragile, and I
> think these patches are complicating that further (though I appreciate
> that's far from the intent).
>
> I believe we need to split the MMIO and sysreg timer code apart
> entirely. I've had a look at that today, though it's been fairly painful
> so far. It appears some platforms may inadvertently be relying on the
> order and manner in which the rates are probed, which is a major
> headache.
>
> I will try to attack that some more tomorrow.
>
>> This patch separates paths to determine frequency:
>> Separate out the MMIO frequency and the sysreg frequency detection call,
>> and use the appropriate one for the counter.
>>
>> Signed-off-by: Fu Wei 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 40 
>> ++--
>>  1 file changed, 25 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>> b/drivers/clocksource/arm_arch_timer.c
>> index 6484f84..9482481 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -488,23 +488,33 @@ static int arch_timer_starting_cpu(unsigned int cpu)
>>   return 0;
>>  }
>>
>> -static void arch_timer_detect_rate(void __iomem *cntbase)
>> +static void __arch_timer_determine_rate(u32 rate)
>>  {
>> - /* Who has more than one independent system counter? */
>> - if (arch_timer_rate)
>> - return;
>> + /* Check the timer frequency. */
>> + if (!arch_timer_rate) {
>> + if (rate)
>> + arch_timer_rate = rate;
>> + else
>> + pr_warn("frequency not available\n");
>> + } else if (rate && arch_timer_rate != rate) {
>> + pr_warn("got different frequency, keep original.\n");
>> + }
>> +}
>
> This function should be killed off entirely. We need to be able to fail
> the probe if we cannot determine the rate, and that means we need error
> handling in the ACPI and DT cases anyway.
>
> Thanks,
> Mark.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

[GIT PULL] extcon next for v4.11

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.11. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.11

for you to fetch changes up to 567ab5a81ba569b823b51f4af74f26c437e98b56:

  extcon: palmas: Use dev_dbg macro for the debug messages (2017-01-25 15:03:54 
+0900)


Update extcon for 4.11

Detailed description for this pull request:
1. Add the new extcon driver.
- Intel INT3496 ACPI USB id detection driver detects whether
  EXTCON_USB_HOST is attached or detached. (extcon-intel-int3496.c)

2. Add the new type of external connector.
- EXTCON_CHG_USB_PD (USB Power Delivery) provides the increased
  power more than 7.5W to device with larger power demand.

3. Add the description for EXTCON_CHG_USB_(SDP|ACA|SLOW|FAST)
- EXTCON_CHG_USB_SDP should always appear together with EXTCON_USB
- EXTCON_CHG_USB_ACA would normally appear with EXTCON_USB_HOST.
- EXTCON_CHG_USB_SLOW can provide at least 500mA of current at 5V
- EXTCON_CHG_USB_FAST can provide at least 1A of current at 5V.

4. Modify the connector name of EXTCON_USB_HOST
- "USB_HOST" -> "USB-HOST"

5. Update the extcon core
- Move the private extcon structure into driver/extcon directory.
  The 'struct extcon_dev' should be only handled by extcon core
  to prevent the direct access and to maintain the integrity of it.
- Remove the ambigous operation of extcon_register_notifier()
  in case of the 'extcon_dev' instance is NULL. The user of
  extcon_register_notifier() have to specify the correct instance
  of the provider extcon driver.

6. Update the extcon drivers and fix the minor issues
- Update the extcon-axp288 driver to remove the unncessary code.
- Add pinctrl operation during suspend mode to extcon-usb-gpio driver.
- Clean up the extcon-arizona/adc-jack driver.
- Use the dev_dbg() for debug messsage on extcon-palmas driver.
- Return the error code on failure of extcon_sync()


Baolin Wang (3):
  extcon: Add documentation for EXTCON_CHG_USB_* and EXTCON_USB_*
  extcon: axp288: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
  extcon: Add documentation for EXTCON_CHG_USB_SLOW/FAST

Chanwoo Choi (5):
  extcon: Remove potential problem when calling extcon_register_notifier()
  extcon: adc-jack: Use the internal data instead of using struct extcon_dev
  extcon: Move defintion of struct extcon_dev to driver/extcon directory
  extcon: Add new EXTCON_CHG_USB_PD type for USB Power Delivery
  extcon: Modify the name of EXTCON_USB_HOST connector

Charles Keepax (1):
  extcon: arizona: Simplify micd_pol_gpio handling

David Cohen (1):
  extcon: int3496: Add Intel INT3496 ACPI device extcon driver

Hans de Goede (7):
  extcon: axp288: Remove dependency on non-existing platform_data
  extcon: axp288: Remove usb_phy notification code
  extcon: axp288: Simplify axp288_handle_chrg_det_event
  extcon: axp288: Fix possibly reporting 2 cables in state true
  extcon: axp288: Use vbus-valid instead of -present to determine cable 
presence
  extcon: axp288: Remove unnecessary irq?_en register writes
  extcon: axp288: Fix the module not auto-loading

Pan Bian (1):
  extcon: Return error code on failure

Peter Chen (1):
  extcon: usb-gpio: Add pinctrl operation during system PM

Peter Foley (1):
  extcon: adc-jack: Fix incompatible pointer type warning

Roger Quadros (2):
  extcon: palmas: Check the parent instance to prevent the NULL
  extcon: palmas: Use dev_dbg macro for the debug messages

Srikant Ritolia (1):
  extcon: Restructure multi-line comments to follow codingstyle

 Documentation/extcon/intel-int3496.txt |  22 
 drivers/extcon/Kconfig |  10 ++
 drivers/extcon/Makefile|   1 +
 drivers/extcon/devres.c|   2 +-
 drivers/extcon/extcon-adc-jack.c   |   2 +-
 drivers/extcon/extcon-arizona.c|  20 ++--
 drivers/extcon/extcon-axp288.c | 110 
 drivers/extcon/extcon-intel-int3496.c  | 179 +
 drivers/extcon/extcon-max14577.c   |   6 +-
 drivers/extcon/extcon-max77693.c   |  12 ++-
 drivers/extcon/extcon-max77843.c   |  24 +++--
 drivers/extcon/extcon-palmas.c |  21 ++--
 drivers/extcon/extcon-rt8973a.c|   6 +-
 drivers/extcon/extcon-sm5502.c |   6 +-
 drivers/extcon/extcon-usb-gpio.c   |   7 ++
 drivers/extcon/extcon.c|  45 +++--
 drivers/extcon/extcon.h|  62 
 include/linux/extcon.h |  71 

Re: [1/6] apalis-tk1: remove spurious new lines

[Thierry Reding]

On Tue, Nov 22, 2016 at 01:14:02AM +0100, Marcel Ziswiler wrote:
> Remove some spurious new lines.
> 
> Signed-off-by: Marcel Ziswiler 
> ---

For some reason I can't find any trace of this series in my inbox. It's
not even been classified as spam, it's just not there. So I had to pull
this from patchwork in order to reply.

>  arch/arm/boot/dts/tegra124-apalis-eval.dts |  1 -
>  arch/arm/boot/dts/tegra124-apalis.dtsi | 12 
>  2 files changed, 13 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts 
> b/arch/arm/boot/dts/tegra124-apalis-eval.dts
> index 653044a..2b5a0f3 100644
> --- a/arch/arm/boot/dts/tegra124-apalis-eval.dts
> +++ b/arch/arm/boot/dts/tegra124-apalis-eval.dts
> @@ -232,7 +232,6 @@
>  
>   backlight: backlight {
>   compatible = "pwm-backlight";
> -
>   /* BKL1_PWM */
>   pwms = < 3 500>;
>   brightness-levels = <255 231 223 207 191 159 127 0>;

These newlines were introduced to separate standard properties from the
not so standard properties for readability, I'd prefer to keep them.

Same for the ones below.

Thierry


signature.asc
Description: PGP signature

Re: [1/6] apalis-tk1: remove spurious new lines

[Thierry Reding]

On Tue, Nov 22, 2016 at 01:14:02AM +0100, Marcel Ziswiler wrote:
> Remove some spurious new lines.
> 
> Signed-off-by: Marcel Ziswiler 
> ---

For some reason I can't find any trace of this series in my inbox. It's
not even been classified as spam, it's just not there. So I had to pull
this from patchwork in order to reply.

>  arch/arm/boot/dts/tegra124-apalis-eval.dts |  1 -
>  arch/arm/boot/dts/tegra124-apalis.dtsi | 12 
>  2 files changed, 13 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts 
> b/arch/arm/boot/dts/tegra124-apalis-eval.dts
> index 653044a..2b5a0f3 100644
> --- a/arch/arm/boot/dts/tegra124-apalis-eval.dts
> +++ b/arch/arm/boot/dts/tegra124-apalis-eval.dts
> @@ -232,7 +232,6 @@
>  
>   backlight: backlight {
>   compatible = "pwm-backlight";
> -
>   /* BKL1_PWM */
>   pwms = < 3 500>;
>   brightness-levels = <255 231 223 207 191 159 127 0>;

These newlines were introduced to separate standard properties from the
not so standard properties for readability, I'd prefer to keep them.

Same for the ones below.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

[Aleksa Sarai]

AKA it should be this fix that removes the need for your dumpable setting.
bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission 
checks")


I will check, though from what I recall that patch doesn't fix the
ptrace_may_access checks. Not to mention it won't help if the
container doesn't have it's own user namespace.


That change very much is to the ptrace_may_access checks.


Sorry, you're right. I misremembered the patch.


You are not playing with setgroups if you don't have your own user
namespace.  So I don't see how the other cases are relevant.


There's also oom_score_adj and a few others. User namespaces were just 
the first example that I hit.



What I think I would do in the situation you describe is to
join what you are going to join.  Limit yourself to creating pid
namespaces with unshare.

If you are joining a user namespace set undumpable.
If you are creating a user namespace create it and then set undumpable.


I just tried to implement this, and it works _okay_. Except that 
oom_scoore_adj also is no longer writeable if the process is not 
dumpable -- and the "create container" and "modify process" stages in 
runC are very separate and there's no easy way of reconciling the two.


Ultimately this only affects rootless containers, where security is 
simply not a major concern. However it is a bit frustrating that a 
process which is not dumpable cannot even modify _its own_ 
/proc/self/... files.


My current fix is to just not set dumpable for rootless containers, as 
it seems there's no proper way of setting dumpable in this context. It 
appears as though the only way that dumpable works is by just using 
CAP_DAC_OVERRIDE and completely ignoring the dumpable restrictions.



Clearing dumpable is to help not leak things
into a container when you call setns on a user namespace.


It is also to help not leak things into a container when you join
other namespaces. Most notably the PID namespace.


Except that you don't strictly join a PID namespace.  You set a context
for children to run in a different PID namespace.  So you are safe
from PID namespaces as long as you don't call fork.


But you need to fork eventually if you want to set settings on the 
process which will eventually be the container process (PID 1 in the new 
container). You can't exec before then, you need to fork first.



+   if (mode != (S_IFDIR|S_IRUGO|S_IXUGO)) {


I'd just like to draw your attention to this special case -- why is
this special cased? What was the original reasoning behind it? Does it
make sense for a non-dumpable process to allow someone to change the
mode of some random /proc/[pid]/ directories?


This has nothing at all to do with changing modes and is all about
what uid/gid are set on the proc inode.   Usually it is the uid/gid
of the process in question but occassionally for undumpable processes
it is root/root to prevent people from accessing the files in question.


My question was "why are o+rx directories set to the process's e[ug]id 
but other inodes are set to the root [ug]id?". And it's the other way 
around -- only for two directories on my system is it the case that the 
process has /proc/pid/... inodes owned by the process's e[ug]id (the 
rest are owned by root).


And it is about modes, because once you're the owner of a file you can 
change its mode (allowing other processes to access the inodes). I'm not 
sure what other purpose changing the ownership *of a directory* serves 
-- you cannot create new files (or unlink files) under /proc/self/... 
directories so u+w permissions aren't actually "useful" (as far as I can 
tell).




I get the feeling that some of this logic is a bit iffy.


It looks like I forgot to carry forward the comment that explains that
case in my patch.  Something I need to fix before I merge it.

/*
 * Before the /proc/pid/status file was created the only way to read
 * the effective uid of a /process was to stat /proc/pid.  Reading
 * /proc/pid/status is slow enough that procps and other packages
 * kept stating /proc/pid.  To keep the rules in /proc simple I have
 * made this apply to all per process world readable and executable
 * directories.
 */

Or in short.  I broke ps when I removed all of the special cases, and to
fix ps I added the existing special case.  Not that the uid or gid of a
directory that the whole world can access matters.


Okay, but why is it being applied to _all_ subdirectories of /proc/pid? 
Why not make it *only* set the owner of /proc/pid and nothing else? 
Looks like that was not intended given the reasons you just provided.


--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

[Aleksa Sarai]

AKA it should be this fix that removes the need for your dumpable setting.
bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission 
checks")


I will check, though from what I recall that patch doesn't fix the
ptrace_may_access checks. Not to mention it won't help if the
container doesn't have it's own user namespace.


That change very much is to the ptrace_may_access checks.


Sorry, you're right. I misremembered the patch.


You are not playing with setgroups if you don't have your own user
namespace.  So I don't see how the other cases are relevant.


There's also oom_score_adj and a few others. User namespaces were just 
the first example that I hit.



What I think I would do in the situation you describe is to
join what you are going to join.  Limit yourself to creating pid
namespaces with unshare.

If you are joining a user namespace set undumpable.
If you are creating a user namespace create it and then set undumpable.


I just tried to implement this, and it works _okay_. Except that 
oom_scoore_adj also is no longer writeable if the process is not 
dumpable -- and the "create container" and "modify process" stages in 
runC are very separate and there's no easy way of reconciling the two.


Ultimately this only affects rootless containers, where security is 
simply not a major concern. However it is a bit frustrating that a 
process which is not dumpable cannot even modify _its own_ 
/proc/self/... files.


My current fix is to just not set dumpable for rootless containers, as 
it seems there's no proper way of setting dumpable in this context. It 
appears as though the only way that dumpable works is by just using 
CAP_DAC_OVERRIDE and completely ignoring the dumpable restrictions.



Clearing dumpable is to help not leak things
into a container when you call setns on a user namespace.


It is also to help not leak things into a container when you join
other namespaces. Most notably the PID namespace.


Except that you don't strictly join a PID namespace.  You set a context
for children to run in a different PID namespace.  So you are safe
from PID namespaces as long as you don't call fork.


But you need to fork eventually if you want to set settings on the 
process which will eventually be the container process (PID 1 in the new 
container). You can't exec before then, you need to fork first.



+   if (mode != (S_IFDIR|S_IRUGO|S_IXUGO)) {


I'd just like to draw your attention to this special case -- why is
this special cased? What was the original reasoning behind it? Does it
make sense for a non-dumpable process to allow someone to change the
mode of some random /proc/[pid]/ directories?


This has nothing at all to do with changing modes and is all about
what uid/gid are set on the proc inode.   Usually it is the uid/gid
of the process in question but occassionally for undumpable processes
it is root/root to prevent people from accessing the files in question.


My question was "why are o+rx directories set to the process's e[ug]id 
but other inodes are set to the root [ug]id?". And it's the other way 
around -- only for two directories on my system is it the case that the 
process has /proc/pid/... inodes owned by the process's e[ug]id (the 
rest are owned by root).


And it is about modes, because once you're the owner of a file you can 
change its mode (allowing other processes to access the inodes). I'm not 
sure what other purpose changing the ownership *of a directory* serves 
-- you cannot create new files (or unlink files) under /proc/self/... 
directories so u+w permissions aren't actually "useful" (as far as I can 
tell).




I get the feeling that some of this logic is a bit iffy.


It looks like I forgot to carry forward the comment that explains that
case in my patch.  Something I need to fix before I merge it.

/*
 * Before the /proc/pid/status file was created the only way to read
 * the effective uid of a /process was to stat /proc/pid.  Reading
 * /proc/pid/status is slow enough that procps and other packages
 * kept stating /proc/pid.  To keep the rules in /proc simple I have
 * made this apply to all per process world readable and executable
 * directories.
 */

Or in short.  I broke ps when I removed all of the special cases, and to
fix ps I added the existing special case.  Not that the uid or gid of a
directory that the whole world can access matters.


Okay, but why is it being applied to _all_ subdirectories of /proc/pid? 
Why not make it *only* set the owner of /proc/pid and nothing else? 
Looks like that was not intended given the reasons you just provided.


--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

Re: [RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

[Daniel Vetter]

On Tue, Jan 24, 2017 at 08:52:41PM +0100, Markus Heiser wrote:
> this patch adds a command to lint kernel-doc comments.::
> 
>   scripts/kerneldoc-lint --help
> 
> The lint check include (only) kernel-doc rules described at [1]. It
> does not check against reST (sphinx-doc) markup used in the kernel-doc
> comments.  Since reST markups could include depencies to the build-
> context (e.g. open/closed refs) only a sphinx-doc build can check the
> reST markup in the context of the document it builds.
> 
> With 'kerneldoc-lint' command you can check a single file or a whole
> folder, e.g:
> 
>   scripts/kerneldoc-lint include/drm
>   ...
>   scripts/kerneldoc-lint include/media/media-device.h
> 
> The lint-implementation is a part of the parser module (kernel_doc.py).
> The comandline implementation consist only of a argument parser ('opts')
> which calls the kernel-doc parser with a 'NullTranslator'.::
> 
>parser = kerneldoc.Parser(opts, kerneldoc.NullTranslator())
> 
> Latter is also a small example of how-to implement kernel-doc
> applications with the kernel-doc parser architecture.
> 
> [1] 
> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#writing-kernel-doc-comments
> 
> Signed-off-by: Markus Heiser 

Didn't we have a patch from Jani to gives us a make target doing this? I
think that'd be even neater ...
-Daniel

> ---
>  Documentation/sphinx/lint.py | 121 
> +++
>  scripts/kerneldoc-lint   |  11 
>  2 files changed, 132 insertions(+)
>  create mode 100755 Documentation/sphinx/lint.py
>  create mode 100755 scripts/kerneldoc-lint
> 
> diff --git a/Documentation/sphinx/lint.py b/Documentation/sphinx/lint.py
> new file mode 100755
> index 000..5a0128f
> --- /dev/null
> +++ b/Documentation/sphinx/lint.py
> @@ -0,0 +1,121 @@
> +#!/usr/bin/env python3
> +# -*- coding: utf-8; mode: python -*-
> +# pylint: disable=C0103
> +
> +u"""
> +lint
> +
> +
> +Implementation of the ``kerneldoc-lint`` command.
> +
> +:copyright:  Copyright (C) 2016  Markus Heiser
> +:license:GPL Version 2, June 1991 see Linux/COPYING for details.
> +
> +The ``kernel-doclint`` command *lints* documentation from Linux kernel's
> +source code comments, see ``--help``::
> +
> +$ kernel-lintdoc --help
> +
> +.. note::
> +
> +   The kernel-lintdoc command is under construction, no stable release
> +   yet. The command-line arguments might be changed/extended in the near
> +   future."""
> +
> +# 
> --
> +# imports
> +# 
> --
> +
> +import sys
> +import argparse
> +
> +#import six
> +
> +from fspath import FSPath
> +import kernel_doc as kerneldoc
> +
> +# 
> --
> +# config
> +# 
> --
> +
> +MSG= lambda msg: sys.__stderr__.write("INFO : %s\n" % msg)
> +ERR= lambda msg: sys.__stderr__.write("ERROR: %s\n" % msg)
> +FATAL  = lambda msg: sys.__stderr__.write("FATAL: %s\n" % msg)
> +
> +epilog = u"""This implementation of uses the kernel-doc parser
> +from the linuxdoc extension, for detail informations read
> +http://return42.github.io/sphkerneldoc/books/kernel-doc-HOWTO"";
> +
> +# 
> --
> +def main():
> +# 
> --
> +
> +CLI = argparse.ArgumentParser(
> +description = ("Lint *kernel-doc* comments from source code")
> +, epilog = epilog
> +, formatter_class=argparse.ArgumentDefaultsHelpFormatter)
> +
> +CLI.add_argument(
> +"srctree"
> +, help= "File or folder of source code."
> +, type= lambda x: FSPath(x).ABSPATH)
> +
> +CLI.add_argument(
> +"--sloppy"
> +, action  = "store_true"
> +, help= "Sloppy linting, reports only severe errors.")
> +
> +CLI.add_argument(
> +"--markup"
> +, choices = ["reST", "kernel-doc"]
> +, default = "reST"
> +, help= (
> +"Markup of the comments. Change this option only if you know"
> +" what you do. New comments must be marked up with reST!"))
> +
> +CLI.add_argument(
> +"--verbose", "-v"
> +, action  = "store_true"
> +, help= "verbose output with log messages to stderr" )
> +
> +CLI.add_argument(
> +"--debug"
> +, action  = "store_true"
> +, help= "debug messages to stderr" )
> +
> +CMD = CLI.parse_args()
> +kerneldoc.DEBUG = CMD.debug
> +kerneldoc.VERBOSE = CMD.verbose
> +
> +if not CMD.srctree.EXISTS:
> +ERR("%s does not exists or is not a folder" % CMD.srctree)

Re: [RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

[Daniel Vetter]

On Tue, Jan 24, 2017 at 08:52:41PM +0100, Markus Heiser wrote:
> this patch adds a command to lint kernel-doc comments.::
> 
>   scripts/kerneldoc-lint --help
> 
> The lint check include (only) kernel-doc rules described at [1]. It
> does not check against reST (sphinx-doc) markup used in the kernel-doc
> comments.  Since reST markups could include depencies to the build-
> context (e.g. open/closed refs) only a sphinx-doc build can check the
> reST markup in the context of the document it builds.
> 
> With 'kerneldoc-lint' command you can check a single file or a whole
> folder, e.g:
> 
>   scripts/kerneldoc-lint include/drm
>   ...
>   scripts/kerneldoc-lint include/media/media-device.h
> 
> The lint-implementation is a part of the parser module (kernel_doc.py).
> The comandline implementation consist only of a argument parser ('opts')
> which calls the kernel-doc parser with a 'NullTranslator'.::
> 
>parser = kerneldoc.Parser(opts, kerneldoc.NullTranslator())
> 
> Latter is also a small example of how-to implement kernel-doc
> applications with the kernel-doc parser architecture.
> 
> [1] 
> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#writing-kernel-doc-comments
> 
> Signed-off-by: Markus Heiser 

Didn't we have a patch from Jani to gives us a make target doing this? I
think that'd be even neater ...
-Daniel

> ---
>  Documentation/sphinx/lint.py | 121 
> +++
>  scripts/kerneldoc-lint   |  11 
>  2 files changed, 132 insertions(+)
>  create mode 100755 Documentation/sphinx/lint.py
>  create mode 100755 scripts/kerneldoc-lint
> 
> diff --git a/Documentation/sphinx/lint.py b/Documentation/sphinx/lint.py
> new file mode 100755
> index 000..5a0128f
> --- /dev/null
> +++ b/Documentation/sphinx/lint.py
> @@ -0,0 +1,121 @@
> +#!/usr/bin/env python3
> +# -*- coding: utf-8; mode: python -*-
> +# pylint: disable=C0103
> +
> +u"""
> +lint
> +
> +
> +Implementation of the ``kerneldoc-lint`` command.
> +
> +:copyright:  Copyright (C) 2016  Markus Heiser
> +:license:GPL Version 2, June 1991 see Linux/COPYING for details.
> +
> +The ``kernel-doclint`` command *lints* documentation from Linux kernel's
> +source code comments, see ``--help``::
> +
> +$ kernel-lintdoc --help
> +
> +.. note::
> +
> +   The kernel-lintdoc command is under construction, no stable release
> +   yet. The command-line arguments might be changed/extended in the near
> +   future."""
> +
> +# 
> --
> +# imports
> +# 
> --
> +
> +import sys
> +import argparse
> +
> +#import six
> +
> +from fspath import FSPath
> +import kernel_doc as kerneldoc
> +
> +# 
> --
> +# config
> +# 
> --
> +
> +MSG= lambda msg: sys.__stderr__.write("INFO : %s\n" % msg)
> +ERR= lambda msg: sys.__stderr__.write("ERROR: %s\n" % msg)
> +FATAL  = lambda msg: sys.__stderr__.write("FATAL: %s\n" % msg)
> +
> +epilog = u"""This implementation of uses the kernel-doc parser
> +from the linuxdoc extension, for detail informations read
> +http://return42.github.io/sphkerneldoc/books/kernel-doc-HOWTO"";
> +
> +# 
> --
> +def main():
> +# 
> --
> +
> +CLI = argparse.ArgumentParser(
> +description = ("Lint *kernel-doc* comments from source code")
> +, epilog = epilog
> +, formatter_class=argparse.ArgumentDefaultsHelpFormatter)
> +
> +CLI.add_argument(
> +"srctree"
> +, help= "File or folder of source code."
> +, type= lambda x: FSPath(x).ABSPATH)
> +
> +CLI.add_argument(
> +"--sloppy"
> +, action  = "store_true"
> +, help= "Sloppy linting, reports only severe errors.")
> +
> +CLI.add_argument(
> +"--markup"
> +, choices = ["reST", "kernel-doc"]
> +, default = "reST"
> +, help= (
> +"Markup of the comments. Change this option only if you know"
> +" what you do. New comments must be marked up with reST!"))
> +
> +CLI.add_argument(
> +"--verbose", "-v"
> +, action  = "store_true"
> +, help= "verbose output with log messages to stderr" )
> +
> +CLI.add_argument(
> +"--debug"
> +, action  = "store_true"
> +, help= "debug messages to stderr" )
> +
> +CMD = CLI.parse_args()
> +kerneldoc.DEBUG = CMD.debug
> +kerneldoc.VERBOSE = CMD.verbose
> +
> +if not CMD.srctree.EXISTS:
> +ERR("%s does not exists or is not a folder" % CMD.srctree)
> +sys.exit(42)
> 

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

[Daniel Vetter]

On Tue, Jan 24, 2017 at 05:13:14PM -0700, Jonathan Corbet wrote:
> On Tue, 24 Jan 2017 20:52:40 +0100
> Markus Heiser  wrote:
> 
> > This patch is the initial merge of a pure python implementation
> > to parse kernel-doc comments and generate reST from.
> > 
> > It consist mainly of to parts, the parser module (kerneldoc.py) and the
> > sphinx-doc extension (rstKernelDoc.py). For the command line, there is
> > also a 'scripts/kerneldoc' added.::
> > 
> >scripts/kerneldoc --help
> > 
> > The main two parts are merged 1:1 from
> > 
> >   https://github.com/return42/linuxdoc  commit 3991d3c
> > 
> > Take this as a starting point, there is a lot of work to do (WIP).
> > Since it is merged 1:1, you will also notice it's CodingStyle is (ATM)
> > not kernel compliant and it lacks a user doc ('Documentation/doc-guide').
> > 
> > I will send patches for this when the community agreed about
> > functionalities. I guess there are a lot of topics we have to agree
> > about. E.g. the py-implementation is more strict the perl one.  When you
> > build doc with the py-module you will see a lot of additional errors and
> > warnings compared to the sloppy perl one.
> 
> Again, quick comments...
> 
>  - I would *much* rather evolve our existing Sphinx extension in the
>direction we want it to go than to just replace it wholesale.
>Replacement is the wrong approach for a few reasons, including the need
>to minimize change and preserve credit for Jani's work.  Can we work on
>that basis, please?
> 
>Ideally at the time of merging, we would be able to build the docs with
>*either* kerneldoc.

Seconded, I think renaming the extension string like this is just fairly
pointless busy-work. Kernel-doc isn't interacting perfectly with rst, but
now we already have a sizeable amount of stuff converted and going through
all that once more needs imo som really clear benefits. I think
bug-for-bug compatibility would be much better. Later on we could do
changes, on a change-by-change basis.
-Daniel


>  - I'll have to try it out to see how noisy it is.  I'm not opposed to
>stricter checks; indeed, they could be a good thing.  But we might want
>to have an option so we can cut back on the noise by default.


> 
> Thanks,
> 
> jon

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

[Daniel Vetter]

On Tue, Jan 24, 2017 at 05:13:14PM -0700, Jonathan Corbet wrote:
> On Tue, 24 Jan 2017 20:52:40 +0100
> Markus Heiser  wrote:
> 
> > This patch is the initial merge of a pure python implementation
> > to parse kernel-doc comments and generate reST from.
> > 
> > It consist mainly of to parts, the parser module (kerneldoc.py) and the
> > sphinx-doc extension (rstKernelDoc.py). For the command line, there is
> > also a 'scripts/kerneldoc' added.::
> > 
> >scripts/kerneldoc --help
> > 
> > The main two parts are merged 1:1 from
> > 
> >   https://github.com/return42/linuxdoc  commit 3991d3c
> > 
> > Take this as a starting point, there is a lot of work to do (WIP).
> > Since it is merged 1:1, you will also notice it's CodingStyle is (ATM)
> > not kernel compliant and it lacks a user doc ('Documentation/doc-guide').
> > 
> > I will send patches for this when the community agreed about
> > functionalities. I guess there are a lot of topics we have to agree
> > about. E.g. the py-implementation is more strict the perl one.  When you
> > build doc with the py-module you will see a lot of additional errors and
> > warnings compared to the sloppy perl one.
> 
> Again, quick comments...
> 
>  - I would *much* rather evolve our existing Sphinx extension in the
>direction we want it to go than to just replace it wholesale.
>Replacement is the wrong approach for a few reasons, including the need
>to minimize change and preserve credit for Jani's work.  Can we work on
>that basis, please?
> 
>Ideally at the time of merging, we would be able to build the docs with
>*either* kerneldoc.

Seconded, I think renaming the extension string like this is just fairly
pointless busy-work. Kernel-doc isn't interacting perfectly with rst, but
now we already have a sizeable amount of stuff converted and going through
all that once more needs imo som really clear benefits. I think
bug-for-bug compatibility would be much better. Later on we could do
changes, on a change-by-change basis.
-Daniel


>  - I'll have to try it out to see how noisy it is.  I'm not opposed to
>stricter checks; indeed, they could be a good thing.  But we might want
>to have an option so we can cut back on the noise by default.


> 
> Thanks,
> 
> jon

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

[Dave Young]

Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:
> Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
> not true and could be misleading, since 0 is a valid physical address.

I do not know the history of /proc/kcore, so a question is why the
p_addr was set as 0, if there were some reasons and if this could cause
some risk or breakage.

> 
> User space tools like makedumpfile needs to know physical address for
> PT_LOAD segments of direct mapped regions. Therefore this patch updates
> paddr for such regions. It also sets an invalid paddr (-1) for other
> regions, so that user space tool can know whether a physical address
> provided in PT_LOAD is correct or not.
> 
> Signed-off-by: Pratyush Anand 
> ---
>  fs/proc/kcore.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> index 0b80ad87b4d6..ea9f3d1ae830 100644
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -373,7 +373,10 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, 
> int dataoff)
>   phdr->p_flags   = PF_R|PF_W|PF_X;
>   phdr->p_offset  = kc_vaddr_to_offset(m->addr) + dataoff;
>   phdr->p_vaddr   = (size_t)m->addr;
> - phdr->p_paddr   = 0;
> + if (m->type == KCORE_RAM || m->type == KCORE_TEXT)
> + phdr->p_paddr   = __pa(m->addr);
> + else
> + phdr->p_paddr   = (elf_addr_t)-1;
>   phdr->p_filesz  = phdr->p_memsz = m->size;
>   phdr->p_align   = PAGE_SIZE;
>   }
> -- 
> 2.9.3
> 

Thanks
Dave

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

[Dave Young]

Hi Pratyush
On 01/25/17 at 10:14am, Pratyush Anand wrote:
> Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
> not true and could be misleading, since 0 is a valid physical address.

I do not know the history of /proc/kcore, so a question is why the
p_addr was set as 0, if there were some reasons and if this could cause
some risk or breakage.

> 
> User space tools like makedumpfile needs to know physical address for
> PT_LOAD segments of direct mapped regions. Therefore this patch updates
> paddr for such regions. It also sets an invalid paddr (-1) for other
> regions, so that user space tool can know whether a physical address
> provided in PT_LOAD is correct or not.
> 
> Signed-off-by: Pratyush Anand 
> ---
>  fs/proc/kcore.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> index 0b80ad87b4d6..ea9f3d1ae830 100644
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -373,7 +373,10 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, 
> int dataoff)
>   phdr->p_flags   = PF_R|PF_W|PF_X;
>   phdr->p_offset  = kc_vaddr_to_offset(m->addr) + dataoff;
>   phdr->p_vaddr   = (size_t)m->addr;
> - phdr->p_paddr   = 0;
> + if (m->type == KCORE_RAM || m->type == KCORE_TEXT)
> + phdr->p_paddr   = __pa(m->addr);
> + else
> + phdr->p_paddr   = (elf_addr_t)-1;
>   phdr->p_filesz  = phdr->p_memsz = m->size;
>   phdr->p_align   = PAGE_SIZE;
>   }
> -- 
> 2.9.3
> 

Thanks
Dave

Re: [PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Vinod Koul]

On Sat, Jan 14, 2017 at 11:05:54AM +0530, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w.
> For example h/w is configured for n number of frames, user
> Submits n number of frames and triggered the DMA using issue_pending API.
> 
> In the current driver flow we are submitting one frame at a time,
> But we should submit all the n number of frames at one time
> As the h/w is configured for n number of frames.

Is there a specific reason why you continue to start lines with Title cases, I
have already told you to not do that last time!

> 
> This patch fixes this issue.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Jose Abreu 
> Signed-off-by: Kedareswara rao Appana 
> ---
> Changes for v6:
> ---> Added Rob Acked-by
> ---> Updated commit message as suggested by Vinod.
> Changes for v5:
> ---> Updated xlnx,fstore-config property to xlnx,fstore-enable
>  and updated description as suggested by Rob.
> Changes for v4:
> ---> Add Check for framestore configuration on Transmit case as well
>  as suggested by Jose Abreu.
> ---> Modified the dev_dbg checks to dev_warn checks as suggested
>  by Jose Abreu.
> Changes for v3:
> ---> Added Checks for frame store configuration. If frame store
>  Configuration is not present at the h/w level and user
>  Submits less frames added debug prints in the driver as relevant.
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
>  as suggested by Laurent Pinchart.
> 
>  .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |  2 +
>  drivers/dma/xilinx/xilinx_dma.c| 78 
> +++---
>  2 files changed, 57 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..e951c09 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -66,6 +66,8 @@ Optional child node properties:
>  Optional child node properties for VDMA:
>  - xlnx,genlock-mode: Tells Genlock synchronization is
>   enabled/disabled in hardware.
> +- xlnx,fstore-enable: boolean; if defined, it indicates that controller
> + supports frame store configuration.
>  Optional child node properties for AXI DMA:
>  -dma-channels: Number of dma channels in child node.
>  
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 5eeea57..edb5b71 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -322,6 +322,7 @@ struct xilinx_dma_tx_descriptor {
>   * @genlock: Support genlock mode
>   * @err: Channel has errors
>   * @idle: Check for channel idle
> + * @has_fstoreen: Check for frame store configuration
>   * @tasklet: Cleanup work after irq
>   * @config: Device configuration info
>   * @flush_on_fsync: Flush on Frame sync
> @@ -353,6 +354,7 @@ struct xilinx_dma_chan {
>   bool genlock;
>   bool err;
>   bool idle;
> + bool has_fstoreen;
>   struct tasklet_struct tasklet;
>   struct xilinx_vdma_config config;
>   bool flush_on_fsync;
> @@ -990,6 +992,27 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   if (list_empty(>pending_list))
>   return;
>  
> + /*
> +  * Note: When VDMA is built with default h/w configuration
> +  * User should submit frames upto H/W configured.
> +  * If users submits less than h/w configured
> +  * VDMA engine tries to write to a invalid location
> +  * Results undefined behaviour/memory corruption.
> +  *
> +  * If user would like to submit frames less than h/w capable
> +  * On S2MM side please enable debug info 13 at the h/w level
> +  * On MM2S side please enable debug info 6 at the h/w level
> +  * It will allows the frame buffers numbers to be modified at runtime.
> +  */
> + if (!chan->has_fstoreen &&
> +  chan->desc_pendingcount < chan->num_frms) {
> + dev_warn(chan->dev, "Frame Store Configuration is not enabled 
> at the\n");
> + dev_warn(chan->dev, "H/w level enable Debug info 13 or 6 at the 
> h/w level\n");
> + dev_warn(chan->dev, "OR Submit the frames upto h/w 
> Capable\n\r");
> +
> + return;
> + }
> +
>   desc = list_first_entry(>pending_list,
>   struct xilinx_dma_tx_descriptor, node);
>   tail_desc = list_last_entry(>pending_list,
> @@ -1052,25 +1075,38 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   if (chan->has_sg) {
>   dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
>   tail_segment->phys);
> + list_splice_tail_init(>pending_list, 

Re: [PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Vinod Koul]

On Sat, Jan 14, 2017 at 11:05:54AM +0530, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w.
> For example h/w is configured for n number of frames, user
> Submits n number of frames and triggered the DMA using issue_pending API.
> 
> In the current driver flow we are submitting one frame at a time,
> But we should submit all the n number of frames at one time
> As the h/w is configured for n number of frames.

Is there a specific reason why you continue to start lines with Title cases, I
have already told you to not do that last time!

> 
> This patch fixes this issue.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Jose Abreu 
> Signed-off-by: Kedareswara rao Appana 
> ---
> Changes for v6:
> ---> Added Rob Acked-by
> ---> Updated commit message as suggested by Vinod.
> Changes for v5:
> ---> Updated xlnx,fstore-config property to xlnx,fstore-enable
>  and updated description as suggested by Rob.
> Changes for v4:
> ---> Add Check for framestore configuration on Transmit case as well
>  as suggested by Jose Abreu.
> ---> Modified the dev_dbg checks to dev_warn checks as suggested
>  by Jose Abreu.
> Changes for v3:
> ---> Added Checks for frame store configuration. If frame store
>  Configuration is not present at the h/w level and user
>  Submits less frames added debug prints in the driver as relevant.
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
>  as suggested by Laurent Pinchart.
> 
>  .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |  2 +
>  drivers/dma/xilinx/xilinx_dma.c| 78 
> +++---
>  2 files changed, 57 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..e951c09 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -66,6 +66,8 @@ Optional child node properties:
>  Optional child node properties for VDMA:
>  - xlnx,genlock-mode: Tells Genlock synchronization is
>   enabled/disabled in hardware.
> +- xlnx,fstore-enable: boolean; if defined, it indicates that controller
> + supports frame store configuration.
>  Optional child node properties for AXI DMA:
>  -dma-channels: Number of dma channels in child node.
>  
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 5eeea57..edb5b71 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -322,6 +322,7 @@ struct xilinx_dma_tx_descriptor {
>   * @genlock: Support genlock mode
>   * @err: Channel has errors
>   * @idle: Check for channel idle
> + * @has_fstoreen: Check for frame store configuration
>   * @tasklet: Cleanup work after irq
>   * @config: Device configuration info
>   * @flush_on_fsync: Flush on Frame sync
> @@ -353,6 +354,7 @@ struct xilinx_dma_chan {
>   bool genlock;
>   bool err;
>   bool idle;
> + bool has_fstoreen;
>   struct tasklet_struct tasklet;
>   struct xilinx_vdma_config config;
>   bool flush_on_fsync;
> @@ -990,6 +992,27 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   if (list_empty(>pending_list))
>   return;
>  
> + /*
> +  * Note: When VDMA is built with default h/w configuration
> +  * User should submit frames upto H/W configured.
> +  * If users submits less than h/w configured
> +  * VDMA engine tries to write to a invalid location
> +  * Results undefined behaviour/memory corruption.
> +  *
> +  * If user would like to submit frames less than h/w capable
> +  * On S2MM side please enable debug info 13 at the h/w level
> +  * On MM2S side please enable debug info 6 at the h/w level
> +  * It will allows the frame buffers numbers to be modified at runtime.
> +  */
> + if (!chan->has_fstoreen &&
> +  chan->desc_pendingcount < chan->num_frms) {
> + dev_warn(chan->dev, "Frame Store Configuration is not enabled 
> at the\n");
> + dev_warn(chan->dev, "H/w level enable Debug info 13 or 6 at the 
> h/w level\n");
> + dev_warn(chan->dev, "OR Submit the frames upto h/w 
> Capable\n\r");
> +
> + return;
> + }
> +
>   desc = list_first_entry(>pending_list,
>   struct xilinx_dma_tx_descriptor, node);
>   tail_desc = list_last_entry(>pending_list,
> @@ -1052,25 +1075,38 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   if (chan->has_sg) {
>   dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
>   tail_segment->phys);
> + list_splice_tail_init(>pending_list, >active_list);
> + chan->desc_pendingcount = 0;

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Anand Moon]

Hi Richard,

On 24 January 2017 at 19:18, Richard Genoud  wrote:
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the USB ports on odroid-XU4 don't work anymore.
>
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2 
> msec, port status = 0xc400fe3
> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop 
> endpoint command.
> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [   74.606276] usb 3-1: USB disconnect, device number 2
> [   74.613565] usb 4-1: USB disconnect, device number 2
> [   74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 
> device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek 
> RTL8153 chip.
>
> If the lines:
> if (dwc->revision > DWC3_REVISION_194A)
> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> are commented out, the USB3.0 start working.
>
> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>
> Felipe suggested that suspend should be disabled temporarily while
> what's wrong with DCW3 is figured out.
>
> Tested on Odroid XU4
>
> Suggested-by: Felipe Balbi 
> Tested-by: Richard Genoud 
> Signed-off-by: Richard Genoud 
> Cc: sta...@vger.kernel.org # 4.4+
> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..f62dbd9b5ad3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,15 @@
> status = "okay";
>  };
>
> +_dwc3_0 {
> +   /*
> +* without that, usb devices are not recognized when
> +* they are plugged.
> +* cf: https://lkml.org/lkml/2017/1/18/678
> +*/
> +   snps,dis_u3_susphy_quirk;
> +};
> +
>  _dwc3_1 {
> dr_mode = "host";
>  };
> --

Thanks for this patch.
But could you consider moving this changes as below.

https://lkml.org/lkml/2015/3/18/400

Best Regards
-Anand

> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Anand Moon]

Hi Richard,

On 24 January 2017 at 19:18, Richard Genoud  wrote:
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the USB ports on odroid-XU4 don't work anymore.
>
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2 
> msec, port status = 0xc400fe3
> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop 
> endpoint command.
> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [   74.606276] usb 3-1: USB disconnect, device number 2
> [   74.613565] usb 4-1: USB disconnect, device number 2
> [   74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 
> device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek 
> RTL8153 chip.
>
> If the lines:
> if (dwc->revision > DWC3_REVISION_194A)
> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> are commented out, the USB3.0 start working.
>
> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>
> Felipe suggested that suspend should be disabled temporarily while
> what's wrong with DCW3 is figured out.
>
> Tested on Odroid XU4
>
> Suggested-by: Felipe Balbi 
> Tested-by: Richard Genoud 
> Signed-off-by: Richard Genoud 
> Cc: sta...@vger.kernel.org # 4.4+
> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..f62dbd9b5ad3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,15 @@
> status = "okay";
>  };
>
> +_dwc3_0 {
> +   /*
> +* without that, usb devices are not recognized when
> +* they are plugged.
> +* cf: https://lkml.org/lkml/2017/1/18/678
> +*/
> +   snps,dis_u3_susphy_quirk;
> +};
> +
>  _dwc3_1 {
> dr_mode = "host";
>  };
> --

Thanks for this patch.
But could you consider moving this changes as below.

https://lkml.org/lkml/2015/3/18/400

Best Regards
-Anand

> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-next: Tree for Jan 25

[Stephen Rothwell]

Hi all,

There will be no linux-next release until Monday (next-20170130).

Changes since 20170124:

New tree: extable

The drm tree still had its build failure so I used the version from
next-20170123.

The userns tree gained a conflict against the selinux tree.

The kselftest tree gained a conflict against the net-next tree.

The akpm-current tree gained a conflict against the userns tree.

Non-merge commits (relative to Linus' tree): 5038
 5743 files changed, 197224 insertions(+), 106791 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (0263d4ebd94b Merge tag 'platform-drivers-x86-v4.10-4' of 
git://git.infradead.org/linux-platform-drivers-x86)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (7a308bb3016f Linux 4.10-rc5)
Merging arm-current/fixes (90f92c631b21 ARM: 8613/1: Fix the uaccess crash on 
PB11MPCore)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (178f358208ce powerpc: Ignore reserved field in 
DCSR and PVR reads and writes)
Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced 
panicing with panicking)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (ec221a17a638 Merge branch 'lwt-module-unload')
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (e5072053b096 netfilter: conntrack: refine gc worker 
heuristics, redux)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (bd19b5ab1da6 Merge tag 
'iwlwifi-for-kalle-2017-01-23' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (ea2a7fb12093 Revert "PCI: Add runtime PM support 
for PCIe ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (488dc164914f xhci: remove WARN_ON if dma mask is 
not set for platform devices)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (5d03a2fd2292 USB: serial: option: add 
device ID for HP lt2523 (Novatel E371))
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (9579c4dc2129 Merge tag 
'iio-fixes-for-4.10b' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)

linux-next: Tree for Jan 25

[Stephen Rothwell]

Hi all,

There will be no linux-next release until Monday (next-20170130).

Changes since 20170124:

New tree: extable

The drm tree still had its build failure so I used the version from
next-20170123.

The userns tree gained a conflict against the selinux tree.

The kselftest tree gained a conflict against the net-next tree.

The akpm-current tree gained a conflict against the userns tree.

Non-merge commits (relative to Linus' tree): 5038
 5743 files changed, 197224 insertions(+), 106791 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (0263d4ebd94b Merge tag 'platform-drivers-x86-v4.10-4' of 
git://git.infradead.org/linux-platform-drivers-x86)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (7a308bb3016f Linux 4.10-rc5)
Merging arm-current/fixes (90f92c631b21 ARM: 8613/1: Fix the uaccess crash on 
PB11MPCore)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (178f358208ce powerpc: Ignore reserved field in 
DCSR and PVR reads and writes)
Merging sparc/master (5d0e7705774d sparc: Fixed typo in sstate.c. Replaced 
panicing with panicking)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (ec221a17a638 Merge branch 'lwt-module-unload')
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (e5072053b096 netfilter: conntrack: refine gc worker 
heuristics, redux)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (bd19b5ab1da6 Merge tag 
'iwlwifi-for-kalle-2017-01-23' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (ea2a7fb12093 Revert "PCI: Add runtime PM support 
for PCIe ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (488dc164914f xhci: remove WARN_ON if dma mask is 
not set for platform devices)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (5d03a2fd2292 USB: serial: option: add 
device ID for HP lt2523 (Novatel E371))
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (9579c4dc2129 Merge tag 
'iio-fixes-for-4.10b' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)

IOAT 4.0 driver not supported on Intel 5000 chipset

[Anshuman Khandual]

Hello Vinod/Dave,

I have an old X86 system with 'Intel(R) Xeon(R) CPU X5450' which has
'5000 Series Chipset'. The latest mainline IOAT driver does not work
on it. Dont see /sys/class/dma getting filled up with channel details
even if I manually load both dca.ko followed by ioatdma.ko drivers
after the system boots. As it was working on a old distro kernel like
3.10, did a git bisect to figure out that the support was removed for
older IOAT HW around August 2015 with the following commits.

commit 85596a19478da5125f3471a0c474b3f05a78e390
Author: Dave Jiang 
Date:   Tue Aug 11 08:48:10 2015 -0700

dmaengine: ioatdma: remove ioat1 specific code

Cleaning up of ioat1 specific code as it is no longer supported

Signed-off-by: Dave Jiang 
Acked-by: Dan Williams 
Signed-off-by: Vinod Koul 

d73f277b329f46c13527c1090808421828671596 is the first bad commit
commit d73f277b329f46c13527c1090808421828671596
Author: Dave Jiang 
Date:   Tue Aug 11 08:48:04 2015 -0700

dmaengine: ioatdma: deprecating and removal of old ioatdma devices

Removal of any devices that are ioatdma pre-3.0. This is the first step
in attempting to clean up the ioatdma driver and remove hw no longer
supported.

Signed-off-by: Dave Jiang 
Acked-by: Dan Williams 
Signed-off-by: Vinod Koul 

I intend to use the HW with mainline kernel. Is there any work around
which can make it happen ?

Regards
Anshuman

IOAT 4.0 driver not supported on Intel 5000 chipset

[Anshuman Khandual]

Hello Vinod/Dave,

I have an old X86 system with 'Intel(R) Xeon(R) CPU X5450' which has
'5000 Series Chipset'. The latest mainline IOAT driver does not work
on it. Dont see /sys/class/dma getting filled up with channel details
even if I manually load both dca.ko followed by ioatdma.ko drivers
after the system boots. As it was working on a old distro kernel like
3.10, did a git bisect to figure out that the support was removed for
older IOAT HW around August 2015 with the following commits.

commit 85596a19478da5125f3471a0c474b3f05a78e390
Author: Dave Jiang 
Date:   Tue Aug 11 08:48:10 2015 -0700

dmaengine: ioatdma: remove ioat1 specific code

Cleaning up of ioat1 specific code as it is no longer supported

Signed-off-by: Dave Jiang 
Acked-by: Dan Williams 
Signed-off-by: Vinod Koul 

d73f277b329f46c13527c1090808421828671596 is the first bad commit
commit d73f277b329f46c13527c1090808421828671596
Author: Dave Jiang 
Date:   Tue Aug 11 08:48:04 2015 -0700

dmaengine: ioatdma: deprecating and removal of old ioatdma devices

Removal of any devices that are ioatdma pre-3.0. This is the first step
in attempting to clean up the ioatdma driver and remove hw no longer
supported.

Signed-off-by: Dave Jiang 
Acked-by: Dan Williams 
Signed-off-by: Vinod Koul 

I intend to use the HW with mainline kernel. Is there any work around
which can make it happen ?

Regards
Anshuman

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Minchan Kim]

On Wed, Jan 25, 2017 at 02:38:49PM +0900, Sergey Senozhatsky wrote:
> On (01/25/17 13:51), Minchan Kim wrote:
> [..]
> > > Minchan, zhouxianrong, I was completely wrong. we can't
> > > do memset(). d'oh, I did not know it truncates 4 bytes to
> > > one byte only (doesn't make too much sense to me).
> > 
> > Now, I read Matthew's comment and understood. Thanks.
> > It means zhouxianrong's patch I sent recently is okay?
> 
> this one looks OK to me
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1316290.html
> 
> 
> I'd agree with Joonsoo that doing forward prefetching is _probably_ better
> than backwards prefetching. not that it necessarily should confuse the CPU
> (need to google if ARM handles it normally), but still.

Okay, let's settle down.

zhouxianrong, please resend one Sergey pointed out with changing to
forward loop. though, sorry for a lot confusion!

> 
>   -ss
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Minchan Kim]

On Wed, Jan 25, 2017 at 02:38:49PM +0900, Sergey Senozhatsky wrote:
> On (01/25/17 13:51), Minchan Kim wrote:
> [..]
> > > Minchan, zhouxianrong, I was completely wrong. we can't
> > > do memset(). d'oh, I did not know it truncates 4 bytes to
> > > one byte only (doesn't make too much sense to me).
> > 
> > Now, I read Matthew's comment and understood. Thanks.
> > It means zhouxianrong's patch I sent recently is okay?
> 
> this one looks OK to me
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1316290.html
> 
> 
> I'd agree with Joonsoo that doing forward prefetching is _probably_ better
> than backwards prefetching. not that it necessarily should confuse the CPU
> (need to google if ARM handles it normally), but still.

Okay, let's settle down.

zhouxianrong, please resend one Sergey pointed out with changing to
forward loop. though, sorry for a lot confusion!

> 
>   -ss
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH 31/37] misc: Add host side pci driver for pci test function device

[Kishon Vijay Abraham I]

Hi,

On Tuesday 24 January 2017 09:32 PM, Christoph Hellwig wrote:
> On Thu, Jan 12, 2017 at 03:56:20PM +0530, Kishon Vijay Abraham I wrote:
>> Add PCI endpoint test driver that can verify base address
>> register, legacy interrupt/MSI interrupt and read/write/copy
>> buffers between host and device. The corresponding pci-epf-test
>> function driver should be used on the EP side.
> 
> Just curious:  what would you think of a text based (e.g. debugfs)
> interface to avoid the need for a userspace tool here?

I felt having a userspace tool gives the flexibility to add more tests
(iterations, sizes etc..) while the driver can just focus on performing simple
tests. Say we'd like to perform infinite read/write tests, it's better if the
userspace tool invokes read/write tests repeatedly instead of that being
implemented in the driver.
> 
>> +static const struct pci_device_id pci_endpoint_test_tbl[] = {
>> +{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_ANY_ID) },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
> 
> Also this looks really odd, and dangerous.  Probing for any
> TI device will bind to all kinds of legit devices.  It would
> be good if you could squeeze out a single id for this device

There is actually an id for the device, but I think we'll need an id for every
function right?

Having said that the id for the device is better than PCI_ANY_ID. Will fix it
in my next revision.

Thanks
Kishon

Re: [PATCH 31/37] misc: Add host side pci driver for pci test function device

[Kishon Vijay Abraham I]

Hi,

On Tuesday 24 January 2017 09:32 PM, Christoph Hellwig wrote:
> On Thu, Jan 12, 2017 at 03:56:20PM +0530, Kishon Vijay Abraham I wrote:
>> Add PCI endpoint test driver that can verify base address
>> register, legacy interrupt/MSI interrupt and read/write/copy
>> buffers between host and device. The corresponding pci-epf-test
>> function driver should be used on the EP side.
> 
> Just curious:  what would you think of a text based (e.g. debugfs)
> interface to avoid the need for a userspace tool here?

I felt having a userspace tool gives the flexibility to add more tests
(iterations, sizes etc..) while the driver can just focus on performing simple
tests. Say we'd like to perform infinite read/write tests, it's better if the
userspace tool invokes read/write tests repeatedly instead of that being
implemented in the driver.
> 
>> +static const struct pci_device_id pci_endpoint_test_tbl[] = {
>> +{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_ANY_ID) },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
> 
> Also this looks really odd, and dangerous.  Probing for any
> TI device will bind to all kinds of legit devices.  It would
> be good if you could squeeze out a single id for this device

There is actually an id for the device, but I think we'll need an id for every
function right?

Having said that the id for the device is better than PCI_ANY_ID. Will fix it
in my next revision.

Thanks
Kishon

[PATCH net-next] r8152: fix the wrong spelling

[Hayes Wang]

Replace rumtime with runtime.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..d59d773 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,7 +3576,7 @@ static bool delay_autosuspend(struct r8152 *tp)
return false;
 }
 
-static int rtl8152_rumtime_suspend(struct r8152 *tp)
+static int rtl8152_runtime_suspend(struct r8152 *tp)
 {
struct net_device *netdev = tp->netdev;
int ret = 0;
@@ -3653,7 +3653,7 @@ static int rtl8152_suspend(struct usb_interface *intf, 
pm_message_t message)
mutex_lock(>control);
 
if (PMSG_IS_AUTO(message))
-   ret = rtl8152_rumtime_suspend(tp);
+   ret = rtl8152_runtime_suspend(tp);
else
ret = rtl8152_system_suspend(tp);
 
-- 
2.7.4

[PATCH net-next] r8152: fix the wrong spelling

[Hayes Wang]

Replace rumtime with runtime.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..d59d773 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,7 +3576,7 @@ static bool delay_autosuspend(struct r8152 *tp)
return false;
 }
 
-static int rtl8152_rumtime_suspend(struct r8152 *tp)
+static int rtl8152_runtime_suspend(struct r8152 *tp)
 {
struct net_device *netdev = tp->netdev;
int ret = 0;
@@ -3653,7 +3653,7 @@ static int rtl8152_suspend(struct usb_interface *intf, 
pm_message_t message)
mutex_lock(>control);
 
if (PMSG_IS_AUTO(message))
-   ret = rtl8152_rumtime_suspend(tp);
+   ret = rtl8152_runtime_suspend(tp);
else
ret = rtl8152_system_suspend(tp);
 
-- 
2.7.4

Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings

[John Crispin]

On 25/01/2017 04:38, Guochun Mao wrote:
> Add "mediatek,mt2701-nor" for nor flash node's compatible.
> 
> Signed-off-by: Guochun Mao 
> ---
>  .../devicetree/bindings/mtd/mtk-quadspi.txt|8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt 
> b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> index fb314f0..5ded66a 100644
> --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> @@ -1,7 +1,13 @@
>  * Serial NOR flash controller for MTK MT81xx (and similar)
>  
>  Required properties:
> -- compatible:  should be "mediatek,mt8173-nor";
> +- compatible:  The possible values are:
> +   "mediatek,mt2701-nor"
> +   "mediatek,mt7623-nor"

Thanks !

Acked-by: John Crispin 


> +   "mediatek,mt8173-nor"
> +   For mt8173, compatible should be "mediatek,mt8173-nor".
> +   For every other SoC, should contain both the SoC-specific 
> compatible string
> +   and "mediatek,mt8173-nor".
>  - reg: physical base address and length of the controller's 
> register
>  - clocks:  the phandle of the clocks needed by the nor controller
>  - clock-names: the names of the clocks
> 

Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings

[John Crispin]

On 25/01/2017 04:38, Guochun Mao wrote:
> Add "mediatek,mt2701-nor" for nor flash node's compatible.
> 
> Signed-off-by: Guochun Mao 
> ---
>  .../devicetree/bindings/mtd/mtk-quadspi.txt|8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt 
> b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> index fb314f0..5ded66a 100644
> --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> @@ -1,7 +1,13 @@
>  * Serial NOR flash controller for MTK MT81xx (and similar)
>  
>  Required properties:
> -- compatible:  should be "mediatek,mt8173-nor";
> +- compatible:  The possible values are:
> +   "mediatek,mt2701-nor"
> +   "mediatek,mt7623-nor"

Thanks !

Acked-by: John Crispin 


> +   "mediatek,mt8173-nor"
> +   For mt8173, compatible should be "mediatek,mt8173-nor".
> +   For every other SoC, should contain both the SoC-specific 
> compatible string
> +   and "mediatek,mt8173-nor".
>  - reg: physical base address and length of the controller's 
> register
>  - clocks:  the phandle of the clocks needed by the nor controller
>  - clock-names: the names of the clocks
> 

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Sergey Senozhatsky]

On (01/25/17 13:51), Minchan Kim wrote:
[..]
> > Minchan, zhouxianrong, I was completely wrong. we can't
> > do memset(). d'oh, I did not know it truncates 4 bytes to
> > one byte only (doesn't make too much sense to me).
> 
> Now, I read Matthew's comment and understood. Thanks.
> It means zhouxianrong's patch I sent recently is okay?

this one looks OK to me
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1316290.html


I'd agree with Joonsoo that doing forward prefetching is _probably_ better
than backwards prefetching. not that it necessarily should confuse the CPU
(need to google if ARM handles it normally), but still.

-ss

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Sergey Senozhatsky]

On (01/25/17 13:51), Minchan Kim wrote:
[..]
> > Minchan, zhouxianrong, I was completely wrong. we can't
> > do memset(). d'oh, I did not know it truncates 4 bytes to
> > one byte only (doesn't make too much sense to me).
> 
> Now, I read Matthew's comment and understood. Thanks.
> It means zhouxianrong's patch I sent recently is okay?

this one looks OK to me
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1316290.html


I'd agree with Joonsoo that doing forward prefetching is _probably_ better
than backwards prefetching. not that it necessarily should confuse the CPU
(need to google if ARM handles it normally), but still.

-ss

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Zhang Rui]

On Tue, 2017-01-24 at 21:07 -0200, Fabio Estevam wrote:
> On Tue, Jan 24, 2017 at 8:46 PM, Pavel Machek  wrote:
> 
> > 
> > It is an ugly regression and it is -rc5 time. Actually not your
> > problem, but Fabio Estevam or Zhang Rui has to deal with it soon.
> I have already sent the revert and it was acked-by you and Guenter.

Revert patch has been applied and queued for next -rc.

thanks,
rui

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

[Zhang Rui]

On Tue, 2017-01-24 at 21:07 -0200, Fabio Estevam wrote:
> On Tue, Jan 24, 2017 at 8:46 PM, Pavel Machek  wrote:
> 
> > 
> > It is an ugly regression and it is -rc5 time. Actually not your
> > problem, but Fabio Estevam or Zhang Rui has to deal with it soon.
> I have already sent the revert and it was acked-by you and Guenter.

Revert patch has been applied and queued for next -rc.

thanks,
rui

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Ingo,

On 01/24/2017 04:20 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>> Hi Ingo,
>>
>> On 01/22/2017 05:04 PM, Ingo Molnar wrote:
>>> * Lu Baolu  wrote:
>>>
>> +static void xdbc_runtime_delay(unsigned long count)
>> +{
>> +udelay(count);
>> +}
>> +static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
> Is this udelay() complication really necessary? udelay() should work fine 
> even in 
> early code. It might not be precisely calibrated, but should be good 
> enough.
 I tried udelay() in the early code. It's not precise enough for the
 hardware handshaking.
>>> Possibly because on x86 early udelay() did not work at all - i.e. there's 
>>> no delay 
>>> whatsoever.
>> Yes.
>>
>>> Could you try it on top of this commit in tip:timers/core:
>>>
>>>   4c45c5167c95 x86/timer: Make delay() work during early bootup
>>>
>>> ?
>> I tried tip:timers/core. It's not precise enough for my context either.
>>
>> __const_udelay().
>>
>> 157 inline void __const_udelay(unsigned long xloops)
>> 158 {
>> 159 unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : 
>> loops_per_jiffy;
>> 160 int d0;
>> 161
>> 162 xloops *= 4;
>> 163 asm("mull %%edx"
>> 164 :"=d" (xloops), "=" (d0)
>> 165 :"1" (xloops), "0" (lpj * (HZ / 4)));
>> 166
>> 167 __delay(++xloops);
>> 168 }
>>
>>
>> In my early  code, loops_per_jiffy is not initialized yet. Hence "lpj" for 
>> the asm line
>> is 4096 (default value).
>>
>> The  cpu_info.loops_per_jiffy actually reads 8832000 after initialization. 
>> They are
>> about 2000 times different.
>>
>> I did a hacky test in kernel to check the difference between these two 
>> different
>> "lpj" values. (The hacky patch is attached.) Below is the output for 100ms 
>> delay.
>>
>> [2.494751] udelay_test uninitialized >start
>> [2.494820] udelay_test uninitialized >end
>> [2.494828] udelay_test initialized >start
>> [2.595234] udelay_test initialized >end
>>
>> For 100ms delay, udelay() with uninitialized loops_per_jiffy only gives a 
>> delay of
>> only 69us.
> Ok, then could we add some simple calibration to make udelay work much better 
> - or 
> perhaps move the udelay calibration up earlier?
>
> Hiding essentially an early udelay() implementation in an early-printk driver 
> is 
> ugly and counterproductive.

Sure. How about below change?

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index d3f0c84..940989e 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -587,6 +587,35 @@ static int xdbc_bulk_transfer(void *data, int size, bool 
read)
return size;
 }
 
+static void __init xdbc_udelay_calibration(void)
+{
+   unsigned long lpj = 0;
+   unsigned int tsc_khz, cpu_khz;
+
+   if (!boot_cpu_has(X86_FEATURE_TSC))
+   goto calibration_out;
+
+   cpu_khz = x86_platform.calibrate_cpu();
+   tsc_khz = x86_platform.calibrate_tsc();
+
+   if (tsc_khz == 0)
+   tsc_khz = cpu_khz;
+   else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
+   cpu_khz = tsc_khz;
+
+   if (!tsc_khz)
+   goto calibration_out;
+
+   lpj = tsc_khz * 1000;
+   do_div(lpj, HZ);
+
+calibration_out:
+   if (!lpj)
+   lpj = 1 << 22;
+
+   loops_per_jiffy = lpj;
+}
+
 static int __init xdbc_early_setup(void)
 {
int ret;
@@ -686,6 +715,8 @@ int __init early_xdbc_parse_parameter(char *s)
}
xdbc.xdbc_reg = (struct xdbc_regs __iomem *)(xdbc.xhci_base + offset);
 
+   xdbc_udelay_calibration();
+
return 0;
 }

Best regards,
Lu Baolu

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Ingo,

On 01/24/2017 04:20 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>> Hi Ingo,
>>
>> On 01/22/2017 05:04 PM, Ingo Molnar wrote:
>>> * Lu Baolu  wrote:
>>>
>> +static void xdbc_runtime_delay(unsigned long count)
>> +{
>> +udelay(count);
>> +}
>> +static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
> Is this udelay() complication really necessary? udelay() should work fine 
> even in 
> early code. It might not be precisely calibrated, but should be good 
> enough.
 I tried udelay() in the early code. It's not precise enough for the
 hardware handshaking.
>>> Possibly because on x86 early udelay() did not work at all - i.e. there's 
>>> no delay 
>>> whatsoever.
>> Yes.
>>
>>> Could you try it on top of this commit in tip:timers/core:
>>>
>>>   4c45c5167c95 x86/timer: Make delay() work during early bootup
>>>
>>> ?
>> I tried tip:timers/core. It's not precise enough for my context either.
>>
>> __const_udelay().
>>
>> 157 inline void __const_udelay(unsigned long xloops)
>> 158 {
>> 159 unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : 
>> loops_per_jiffy;
>> 160 int d0;
>> 161
>> 162 xloops *= 4;
>> 163 asm("mull %%edx"
>> 164 :"=d" (xloops), "=" (d0)
>> 165 :"1" (xloops), "0" (lpj * (HZ / 4)));
>> 166
>> 167 __delay(++xloops);
>> 168 }
>>
>>
>> In my early  code, loops_per_jiffy is not initialized yet. Hence "lpj" for 
>> the asm line
>> is 4096 (default value).
>>
>> The  cpu_info.loops_per_jiffy actually reads 8832000 after initialization. 
>> They are
>> about 2000 times different.
>>
>> I did a hacky test in kernel to check the difference between these two 
>> different
>> "lpj" values. (The hacky patch is attached.) Below is the output for 100ms 
>> delay.
>>
>> [2.494751] udelay_test uninitialized >start
>> [2.494820] udelay_test uninitialized >end
>> [2.494828] udelay_test initialized >start
>> [2.595234] udelay_test initialized >end
>>
>> For 100ms delay, udelay() with uninitialized loops_per_jiffy only gives a 
>> delay of
>> only 69us.
> Ok, then could we add some simple calibration to make udelay work much better 
> - or 
> perhaps move the udelay calibration up earlier?
>
> Hiding essentially an early udelay() implementation in an early-printk driver 
> is 
> ugly and counterproductive.

Sure. How about below change?

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index d3f0c84..940989e 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -587,6 +587,35 @@ static int xdbc_bulk_transfer(void *data, int size, bool 
read)
return size;
 }
 
+static void __init xdbc_udelay_calibration(void)
+{
+   unsigned long lpj = 0;
+   unsigned int tsc_khz, cpu_khz;
+
+   if (!boot_cpu_has(X86_FEATURE_TSC))
+   goto calibration_out;
+
+   cpu_khz = x86_platform.calibrate_cpu();
+   tsc_khz = x86_platform.calibrate_tsc();
+
+   if (tsc_khz == 0)
+   tsc_khz = cpu_khz;
+   else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
+   cpu_khz = tsc_khz;
+
+   if (!tsc_khz)
+   goto calibration_out;
+
+   lpj = tsc_khz * 1000;
+   do_div(lpj, HZ);
+
+calibration_out:
+   if (!lpj)
+   lpj = 1 << 22;
+
+   loops_per_jiffy = lpj;
+}
+
 static int __init xdbc_early_setup(void)
 {
int ret;
@@ -686,6 +715,8 @@ int __init early_xdbc_parse_parameter(char *s)
}
xdbc.xdbc_reg = (struct xdbc_regs __iomem *)(xdbc.xhci_base + offset);
 
+   xdbc_udelay_calibration();
+
return 0;
 }

Best regards,
Lu Baolu

[PATCH] ARM: dts: imx53-qsb-common: fix FEC pinmux config

[linux-kernel-dev]

From: Patrick Bruenn 

The pinmux configuration in device tree was different from manual
muxing in /board/freescale/mx53loco/mx53loco.c
All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the
bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the
kernel tree, so it seems to be better to have the correct pinmuxing in
our files, too.

Signed-off-by: Patrick Bruenn 
---
 arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi 
b/arch/arm/boot/dts/imx53-qsb-common.dtsi
index c05e7cfd0cbc..40b3e31935d0 100644
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
 
pinctrl_fec: fecgrp {
fsl,pins = <
-   MX53_PAD_FEC_MDC__FEC_MDC   
0x8000
-   MX53_PAD_FEC_MDIO__FEC_MDIO 
0x8000
-   MX53_PAD_FEC_REF_CLK__FEC_TX_CLK
0x8000
-   MX53_PAD_FEC_RX_ER__FEC_RX_ER   
0x8000
-   MX53_PAD_FEC_CRS_DV__FEC_RX_DV  
0x8000
-   MX53_PAD_FEC_RXD1__FEC_RDATA_1  
0x8000
-   MX53_PAD_FEC_RXD0__FEC_RDATA_0  
0x8000
-   MX53_PAD_FEC_TX_EN__FEC_TX_EN   
0x8000
-   MX53_PAD_FEC_TXD1__FEC_TDATA_1  
0x8000
-   MX53_PAD_FEC_TXD0__FEC_TDATA_0  
0x8000
+   MX53_PAD_FEC_MDC__FEC_MDC   0x4
+   MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
+   MX53_PAD_FEC_REF_CLK__FEC_TX_CLK0x180
+   MX53_PAD_FEC_RX_ER__FEC_RX_ER   0x180
+   MX53_PAD_FEC_CRS_DV__FEC_RX_DV  0x180
+   MX53_PAD_FEC_RXD1__FEC_RDATA_1  0x180
+   MX53_PAD_FEC_RXD0__FEC_RDATA_0  0x180
+   MX53_PAD_FEC_TX_EN__FEC_TX_EN   0x4
+   MX53_PAD_FEC_TXD1__FEC_TDATA_1  0x4
+   MX53_PAD_FEC_TXD0__FEC_TDATA_0  0x4
>;
};
 
-- 
2.11.0

[PATCH] ARM: dts: imx53-qsb-common: fix FEC pinmux config

[linux-kernel-dev]

From: Patrick Bruenn 

The pinmux configuration in device tree was different from manual
muxing in /board/freescale/mx53loco/mx53loco.c
All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the
bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the
kernel tree, so it seems to be better to have the correct pinmuxing in
our files, too.

Signed-off-by: Patrick Bruenn 
---
 arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi 
b/arch/arm/boot/dts/imx53-qsb-common.dtsi
index c05e7cfd0cbc..40b3e31935d0 100644
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
 
pinctrl_fec: fecgrp {
fsl,pins = <
-   MX53_PAD_FEC_MDC__FEC_MDC   
0x8000
-   MX53_PAD_FEC_MDIO__FEC_MDIO 
0x8000
-   MX53_PAD_FEC_REF_CLK__FEC_TX_CLK
0x8000
-   MX53_PAD_FEC_RX_ER__FEC_RX_ER   
0x8000
-   MX53_PAD_FEC_CRS_DV__FEC_RX_DV  
0x8000
-   MX53_PAD_FEC_RXD1__FEC_RDATA_1  
0x8000
-   MX53_PAD_FEC_RXD0__FEC_RDATA_0  
0x8000
-   MX53_PAD_FEC_TX_EN__FEC_TX_EN   
0x8000
-   MX53_PAD_FEC_TXD1__FEC_TDATA_1  
0x8000
-   MX53_PAD_FEC_TXD0__FEC_TDATA_0  
0x8000
+   MX53_PAD_FEC_MDC__FEC_MDC   0x4
+   MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
+   MX53_PAD_FEC_REF_CLK__FEC_TX_CLK0x180
+   MX53_PAD_FEC_RX_ER__FEC_RX_ER   0x180
+   MX53_PAD_FEC_CRS_DV__FEC_RX_DV  0x180
+   MX53_PAD_FEC_RXD1__FEC_RDATA_1  0x180
+   MX53_PAD_FEC_RXD0__FEC_RDATA_0  0x180
+   MX53_PAD_FEC_TX_EN__FEC_TX_EN   0x4
+   MX53_PAD_FEC_TXD1__FEC_TDATA_1  0x4
+   MX53_PAD_FEC_TXD0__FEC_TDATA_0  0x4
>;
};
 
-- 
2.11.0

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

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

  fs/proc/base.c

between commit:

  68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user 
namespaces")

from the userns tree and commit:

  d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files")

from the akpm-current tree.

I *think* that the former supercedes the latter?

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

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

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

  fs/proc/base.c

between commit:

  68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user 
namespaces")

from the userns tree and commit:

  d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files")

from the akpm-current tree.

I *think* that the former supercedes the latter?

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

-- 
Cheers,
Stephen Rothwell

Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

[Stephen Hemminger]

On Wed, 25 Jan 2017 10:50:51 +0800
Hayes Wang  wrote:

> Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
> from calling napi_schedule() directly during runtime suspend.
> 
> After calling napi_disable() or clearing the flag of WORK_ENABLE,
> scheduling the napi is useless.
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index e1466b4..27b0b44 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -3585,10 +3585,13 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
>   struct net_device *netdev = tp->netdev;
>   int ret = 0;
>  
> + set_bit(SELECTIVE_SUSPEND, >flags);
> +
>   if (netif_running(netdev) && test_bit(WORK_ENABLE, >flags)) {
>   u32 rcr = 0;
>  
>   if (delay_autosuspend(tp)) {
> + clear_bit(SELECTIVE_SUSPEND, >flags);
>   ret = -EBUSY;
>   goto out1;
>   }
> @@ -3605,6 +3608,7 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
>   if (!(ocp_data & RXFIFO_EMPTY)) {
>   rxdy_gated_en(tp, false);
>   ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
> + clear_bit(SELECTIVE_SUSPEND, >flags);
>   ret = -EBUSY;

If you are going to start using bit operations then you may need 
smp_mb_before/after_atomic.

Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

[Stephen Hemminger]

On Wed, 25 Jan 2017 10:50:51 +0800
Hayes Wang  wrote:

> Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
> from calling napi_schedule() directly during runtime suspend.
> 
> After calling napi_disable() or clearing the flag of WORK_ENABLE,
> scheduling the napi is useless.
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index e1466b4..27b0b44 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -3585,10 +3585,13 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
>   struct net_device *netdev = tp->netdev;
>   int ret = 0;
>  
> + set_bit(SELECTIVE_SUSPEND, >flags);
> +
>   if (netif_running(netdev) && test_bit(WORK_ENABLE, >flags)) {
>   u32 rcr = 0;
>  
>   if (delay_autosuspend(tp)) {
> + clear_bit(SELECTIVE_SUSPEND, >flags);
>   ret = -EBUSY;
>   goto out1;
>   }
> @@ -3605,6 +3608,7 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
>   if (!(ocp_data & RXFIFO_EMPTY)) {
>   rxdy_gated_en(tp, false);
>   ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
> + clear_bit(SELECTIVE_SUSPEND, >flags);
>   ret = -EBUSY;

If you are going to start using bit operations then you may need 
smp_mb_before/after_atomic.

linux-next: build warning after merge of the mfd tree

[Stephen Rothwell]

Hi Lee,

After merging the mfd tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

drivers/pwm/pwm-stm32.c: In function 'stm32_pwm_apply':
drivers/pwm/pwm-stm32.c:204:33: warning: 'curstate.polarity' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  if (state->polarity != curstate.polarity)
 ^

Introduced by commit

  bafffb6e7bd1 ("pwm: Add driver for STM32 plaftorm")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the mfd tree

[Stephen Rothwell]

Hi Lee,

After merging the mfd tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

drivers/pwm/pwm-stm32.c: In function 'stm32_pwm_apply':
drivers/pwm/pwm-stm32.c:204:33: warning: 'curstate.polarity' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  if (state->polarity != curstate.polarity)
 ^

Introduced by commit

  bafffb6e7bd1 ("pwm: Add driver for STM32 plaftorm")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Minchan Kim]

On Wed, Jan 25, 2017 at 01:18:58PM +0900, Sergey Senozhatsky wrote:
> On (01/24/17 18:48), Matthew Wilcox wrote:
> > On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote:
> > > Hello,
> > > 
> > > On (01/25/17 10:29), Minchan Kim wrote:
> > > [..]
> > > > > the result as listed below:
> > > > > 
> > > > > zeropattern_char   pattern_short   pattern_int   pattern_long   
> > > > > total  (unit)
> > > > > 162989  14454  353423516 2769   
> > > > > 3294399(page)
> > > > > 
> > > >
> > > > so, int covers 93%. As considering non-zero dedup hit ratio is low, I 
> > > > think *int* is
> > > > enough if memset is really fast. So, I'd like to go with 'int' if 
> > > > Sergey doesn't mind.
> > > 
> > > yep, 4 byte pattern matching and memset() sounds like a good plan to me
> > 
> > what?  memset ONLY HANDLES BYTES.
> > 
> > I pointed this out earlier, but you don't seem to be listening.  Let me
> > try it again.
> > 
> > MEMSET ONLY HANDLES BYTES.
> 
> dammit... how did that happen...
> 
> 
> Matthew, you are absolute right. and, yes, I missed out your previous
> mail, indeed. sorry. and thanks for "re-pointing" that out.
> 
> 
> Minchan, zhouxianrong, I was completely wrong. we can't
> do memset(). d'oh, I did not know it truncates 4 bytes to
> one byte only (doesn't make too much sense to me).

Now, I read Matthew's comment and understood. Thanks.
It means zhouxianrong's patch I sent recently is okay?

Thanks.

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Minchan Kim]

On Wed, Jan 25, 2017 at 01:18:58PM +0900, Sergey Senozhatsky wrote:
> On (01/24/17 18:48), Matthew Wilcox wrote:
> > On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote:
> > > Hello,
> > > 
> > > On (01/25/17 10:29), Minchan Kim wrote:
> > > [..]
> > > > > the result as listed below:
> > > > > 
> > > > > zeropattern_char   pattern_short   pattern_int   pattern_long   
> > > > > total  (unit)
> > > > > 162989  14454  353423516 2769   
> > > > > 3294399(page)
> > > > > 
> > > >
> > > > so, int covers 93%. As considering non-zero dedup hit ratio is low, I 
> > > > think *int* is
> > > > enough if memset is really fast. So, I'd like to go with 'int' if 
> > > > Sergey doesn't mind.
> > > 
> > > yep, 4 byte pattern matching and memset() sounds like a good plan to me
> > 
> > what?  memset ONLY HANDLES BYTES.
> > 
> > I pointed this out earlier, but you don't seem to be listening.  Let me
> > try it again.
> > 
> > MEMSET ONLY HANDLES BYTES.
> 
> dammit... how did that happen...
> 
> 
> Matthew, you are absolute right. and, yes, I missed out your previous
> mail, indeed. sorry. and thanks for "re-pointing" that out.
> 
> 
> Minchan, zhouxianrong, I was completely wrong. we can't
> do memset(). d'oh, I did not know it truncates 4 bytes to
> one byte only (doesn't make too much sense to me).

Now, I read Matthew's comment and understood. Thanks.
It means zhouxianrong's patch I sent recently is okay?

Thanks.

Re: [PATCH 1/2] compiler-gcc.h: Added new macro for gcc attribute

[Gideon D'souza]

>#define __mode(x)   __attribute__((mode(x)))
Well that's embarrassing. I so sorry for the trouble guys :( I'll resend this.

On Wed, Jan 25, 2017 at 7:20 AM, Joe Perches  wrote:
> On Tue, 2017-01-24 at 17:44 +0530, Gideon Israel Dsouza wrote:
>> Added __mode(x) into compiler-gcc.h as part of a cleanup task I've
>> taken up, to replace gcc specific attributes with macros.
>>
>> Last accepted patch I sent into linux-next for crypto: d8c34b949d8c:
>> crypto: Replaced gcc specific attributes with macros from compiler.h
>>
>> The last commit of this task that went through you: 52f5684c8e1ec
>> kernel: use macros from compiler.h instead of __attribute__((...))
>>
>> The next patch is for cleaning up the m68k subsystem and it requires
>> a new macro to wrap __attribute__ ((mode (...)))
> []
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> []
>> @@ -121,6 +121,7 @@
>>  #define __attribute_const__  __attribute__((__const__))
>>  #define __maybe_unused   __attribute__((unused))
>>  #define __always_unused  __attribute__((unused))
>> +#define __mode  __attribute__((mode(x)))
>
> Huh?
>
> Perhaps you meant
>
> #define __mode(x)   __attribute__((mode(x)))
>
> ?
>

Re: [PATCH 1/2] compiler-gcc.h: Added new macro for gcc attribute

[Gideon D'souza]

>#define __mode(x)   __attribute__((mode(x)))
Well that's embarrassing. I so sorry for the trouble guys :( I'll resend this.

On Wed, Jan 25, 2017 at 7:20 AM, Joe Perches  wrote:
> On Tue, 2017-01-24 at 17:44 +0530, Gideon Israel Dsouza wrote:
>> Added __mode(x) into compiler-gcc.h as part of a cleanup task I've
>> taken up, to replace gcc specific attributes with macros.
>>
>> Last accepted patch I sent into linux-next for crypto: d8c34b949d8c:
>> crypto: Replaced gcc specific attributes with macros from compiler.h
>>
>> The last commit of this task that went through you: 52f5684c8e1ec
>> kernel: use macros from compiler.h instead of __attribute__((...))
>>
>> The next patch is for cleaning up the m68k subsystem and it requires
>> a new macro to wrap __attribute__ ((mode (...)))
> []
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> []
>> @@ -121,6 +121,7 @@
>>  #define __attribute_const__  __attribute__((__const__))
>>  #define __maybe_unused   __attribute__((unused))
>>  #define __always_unused  __attribute__((unused))
>> +#define __mode  __attribute__((mode(x)))
>
> Huh?
>
> Perhaps you meant
>
> #define __mode(x)   __attribute__((mode(x)))
>
> ?
>

[PATCH] /proc/kcore: Update physical address for kcore ram and text

[Pratyush Anand]

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
not true and could be misleading, since 0 is a valid physical address.

User space tools like makedumpfile needs to know physical address for
PT_LOAD segments of direct mapped regions. Therefore this patch updates
paddr for such regions. It also sets an invalid paddr (-1) for other
regions, so that user space tool can know whether a physical address
provided in PT_LOAD is correct or not.

Signed-off-by: Pratyush Anand 
---
 fs/proc/kcore.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 0b80ad87b4d6..ea9f3d1ae830 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -373,7 +373,10 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, int 
dataoff)
phdr->p_flags   = PF_R|PF_W|PF_X;
phdr->p_offset  = kc_vaddr_to_offset(m->addr) + dataoff;
phdr->p_vaddr   = (size_t)m->addr;
-   phdr->p_paddr   = 0;
+   if (m->type == KCORE_RAM || m->type == KCORE_TEXT)
+   phdr->p_paddr   = __pa(m->addr);
+   else
+   phdr->p_paddr   = (elf_addr_t)-1;
phdr->p_filesz  = phdr->p_memsz = m->size;
phdr->p_align   = PAGE_SIZE;
}
-- 
2.9.3

[PATCH] /proc/kcore: Update physical address for kcore ram and text

[Pratyush Anand]

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is
not true and could be misleading, since 0 is a valid physical address.

User space tools like makedumpfile needs to know physical address for
PT_LOAD segments of direct mapped regions. Therefore this patch updates
paddr for such regions. It also sets an invalid paddr (-1) for other
regions, so that user space tool can know whether a physical address
provided in PT_LOAD is correct or not.

Signed-off-by: Pratyush Anand 
---
 fs/proc/kcore.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 0b80ad87b4d6..ea9f3d1ae830 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -373,7 +373,10 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, int 
dataoff)
phdr->p_flags   = PF_R|PF_W|PF_X;
phdr->p_offset  = kc_vaddr_to_offset(m->addr) + dataoff;
phdr->p_vaddr   = (size_t)m->addr;
-   phdr->p_paddr   = 0;
+   if (m->type == KCORE_RAM || m->type == KCORE_TEXT)
+   phdr->p_paddr   = __pa(m->addr);
+   else
+   phdr->p_paddr   = (elf_addr_t)-1;
phdr->p_filesz  = phdr->p_memsz = m->size;
phdr->p_align   = PAGE_SIZE;
}
-- 
2.9.3

[PATCH] nsproxy: Reuse already available put_nsproxy helper function.

[Parav Pandit]

This patch makes use of already available put_nsproxy() helper
function which already perform atomic check and conditional free.
It also remove braces in put_nsproxy() for single line conditional
statement.
Minor fixes for trailing white space, 80 characters etc warnings
reported by checkpatch.pl.

Signed-off-by: Parav Pandit 
---
 include/linux/nsproxy.h | 10 +-
 kernel/nsproxy.c| 12 +++-
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h
index ac0d65b..24556f4 100644
--- a/include/linux/nsproxy.h
+++ b/include/linux/nsproxy.h
@@ -33,7 +33,7 @@ struct nsproxy {
struct ipc_namespace *ipc_ns;
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns_for_children;
-   struct net   *net_ns;
+   struct net   *net_ns;
struct cgroup_namespace *cgroup_ns;
 };
 extern struct nsproxy init_nsproxy;
@@ -68,15 +68,15 @@ struct nsproxy {
 void exit_task_namespaces(struct task_struct *tsk);
 void switch_task_namespaces(struct task_struct *tsk, struct nsproxy *new);
 void free_nsproxy(struct nsproxy *ns);
-int unshare_nsproxy_namespaces(unsigned long, struct nsproxy **,
-   struct cred *, struct fs_struct *);
+int unshare_nsproxy_namespaces(unsigned long unshare_flags,
+   struct nsproxy **new_nsp, struct cred *new_cred,
+   struct fs_struct *new_fs);
 int __init nsproxy_cache_init(void);
 
 static inline void put_nsproxy(struct nsproxy *ns)
 {
-   if (atomic_dec_and_test(>count)) {
+   if (atomic_dec_and_test(>count))
free_nsproxy(ns);
-   }
 }
 
 static inline void get_nsproxy(struct nsproxy *ns)
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 782102e..f253655 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -71,7 +71,8 @@ static struct nsproxy *create_new_namespaces(unsigned long 
flags,
if (!new_nsp)
return ERR_PTR(-ENOMEM);
 
-   new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, user_ns, 
new_fs);
+   new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, user_ns,
+ new_fs);
if (IS_ERR(new_nsp->mnt_ns)) {
err = PTR_ERR(new_nsp->mnt_ns);
goto out_ns;
@@ -158,7 +159,7 @@ int copy_namespaces(unsigned long flags, struct task_struct 
*tsk)
 * it along with CLONE_NEWIPC.
 */
if ((flags & (CLONE_NEWIPC | CLONE_SYSVSEM)) ==
-   (CLONE_NEWIPC | CLONE_SYSVSEM)) 
+   (CLONE_NEWIPC | CLONE_SYSVSEM))
return -EINVAL;
 
new_ns = create_new_namespaces(flags, tsk, user_ns, tsk->fs);
@@ -189,7 +190,8 @@ void free_nsproxy(struct nsproxy *ns)
  * On success, returns the new nsproxy.
  */
 int unshare_nsproxy_namespaces(unsigned long unshare_flags,
-   struct nsproxy **new_nsp, struct cred *new_cred, struct fs_struct 
*new_fs)
+   struct nsproxy **new_nsp, struct cred *new_cred,
+   struct fs_struct *new_fs)
 {
struct user_namespace *user_ns;
int err = 0;
@@ -224,8 +226,8 @@ void switch_task_namespaces(struct task_struct *p, struct 
nsproxy *new)
p->nsproxy = new;
task_unlock(p);
 
-   if (ns && atomic_dec_and_test(>count))
-   free_nsproxy(ns);
+   if (ns)
+   put_nsproxy(ns);
 }
 
 void exit_task_namespaces(struct task_struct *p)
-- 
1.8.3.1

[PATCH] nsproxy: Reuse already available put_nsproxy helper function.

[Parav Pandit]

This patch makes use of already available put_nsproxy() helper
function which already perform atomic check and conditional free.
It also remove braces in put_nsproxy() for single line conditional
statement.
Minor fixes for trailing white space, 80 characters etc warnings
reported by checkpatch.pl.

Signed-off-by: Parav Pandit 
---
 include/linux/nsproxy.h | 10 +-
 kernel/nsproxy.c| 12 +++-
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h
index ac0d65b..24556f4 100644
--- a/include/linux/nsproxy.h
+++ b/include/linux/nsproxy.h
@@ -33,7 +33,7 @@ struct nsproxy {
struct ipc_namespace *ipc_ns;
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns_for_children;
-   struct net   *net_ns;
+   struct net   *net_ns;
struct cgroup_namespace *cgroup_ns;
 };
 extern struct nsproxy init_nsproxy;
@@ -68,15 +68,15 @@ struct nsproxy {
 void exit_task_namespaces(struct task_struct *tsk);
 void switch_task_namespaces(struct task_struct *tsk, struct nsproxy *new);
 void free_nsproxy(struct nsproxy *ns);
-int unshare_nsproxy_namespaces(unsigned long, struct nsproxy **,
-   struct cred *, struct fs_struct *);
+int unshare_nsproxy_namespaces(unsigned long unshare_flags,
+   struct nsproxy **new_nsp, struct cred *new_cred,
+   struct fs_struct *new_fs);
 int __init nsproxy_cache_init(void);
 
 static inline void put_nsproxy(struct nsproxy *ns)
 {
-   if (atomic_dec_and_test(>count)) {
+   if (atomic_dec_and_test(>count))
free_nsproxy(ns);
-   }
 }
 
 static inline void get_nsproxy(struct nsproxy *ns)
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 782102e..f253655 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -71,7 +71,8 @@ static struct nsproxy *create_new_namespaces(unsigned long 
flags,
if (!new_nsp)
return ERR_PTR(-ENOMEM);
 
-   new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, user_ns, 
new_fs);
+   new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, user_ns,
+ new_fs);
if (IS_ERR(new_nsp->mnt_ns)) {
err = PTR_ERR(new_nsp->mnt_ns);
goto out_ns;
@@ -158,7 +159,7 @@ int copy_namespaces(unsigned long flags, struct task_struct 
*tsk)
 * it along with CLONE_NEWIPC.
 */
if ((flags & (CLONE_NEWIPC | CLONE_SYSVSEM)) ==
-   (CLONE_NEWIPC | CLONE_SYSVSEM)) 
+   (CLONE_NEWIPC | CLONE_SYSVSEM))
return -EINVAL;
 
new_ns = create_new_namespaces(flags, tsk, user_ns, tsk->fs);
@@ -189,7 +190,8 @@ void free_nsproxy(struct nsproxy *ns)
  * On success, returns the new nsproxy.
  */
 int unshare_nsproxy_namespaces(unsigned long unshare_flags,
-   struct nsproxy **new_nsp, struct cred *new_cred, struct fs_struct 
*new_fs)
+   struct nsproxy **new_nsp, struct cred *new_cred,
+   struct fs_struct *new_fs)
 {
struct user_namespace *user_ns;
int err = 0;
@@ -224,8 +226,8 @@ void switch_task_namespaces(struct task_struct *p, struct 
nsproxy *new)
p->nsproxy = new;
task_unlock(p);
 
-   if (ns && atomic_dec_and_test(>count))
-   free_nsproxy(ns);
+   if (ns)
+   put_nsproxy(ns);
 }
 
 void exit_task_namespaces(struct task_struct *p)
-- 
1.8.3.1

[Bug fix]mips 64bits checksum error -- csum_tcpudp_nofold

[Mark Zhang]

If the input parameters as saddr = 0xc0a8fd60,daddr = 0xc0a8fda1,len =
80, proto = 17, sum =0x7eae049d.
The correct result should be 1, but original function return 0.

Attached the correction patch.


0001-Fixed-the-mips-64bits-checksum-error-csum_tcpudp_nof.patch
Description: Binary data

[Bug fix]mips 64bits checksum error -- csum_tcpudp_nofold

[Mark Zhang]

If the input parameters as saddr = 0xc0a8fd60,daddr = 0xc0a8fda1,len =
80, proto = 17, sum =0x7eae049d.
The correct result should be 1, but original function return 0.

Attached the correction patch.


0001-Fixed-the-mips-64bits-checksum-error-csum_tcpudp_nof.patch
Description: Binary data

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

[Ye Xiaolong]

On 01/24, Michal Hocko wrote:
>On Mon 23-01-17 09:26:44, kernel test robot wrote:
>> 
>> Greeting,
>> 
>> FYI, we noticed a -11.1% regression of fsmark.files_per_sec due to commit:
>> 
>> 
>> commit: 5e56dfbd837421b7fa3c6c06018c6701e2704917 ("mm, vmscan: consider 
>> eligible zones in get_scan_count")
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
>This is more than unexpected. This patch should be basically noop for
>anything but CONFIG_HIGHMEM systems. And your config says this is 64b
>kernel. Are those results reproducible? And could you try to compare

Yes, the results are well reproducible, both the commit in question and its
parent have ran for 4 times.

>perf profiles before and after the patch.

Here is the perf profiles, 

Before the patch:
 "perf-profile.children.cycles-pp.verify_cpu"=>[70.92],
 "perf-profile.children.cycles-pp.cpu_startup_entry"=>[70.92],
 "perf-profile.children.cycles-pp.do_idle"=>[70.69],
 "perf-profile.children.cycles-pp.call_cpuidle"=>[69.18],
 "perf-profile.children.cycles-pp.cpuidle_enter"=>[69.14],
 "perf-profile.children.cycles-pp.cpuidle_enter_state"=>[68.63],
 "perf-profile.children.cycles-pp.start_secondary"=>[66.52],
 "perf-profile.children.cycles-pp.intel_idle"=>[39.82],
 "perf-profile.children.cycles-pp.ret_from_fork"=>[19.28],
 "perf-profile.children.cycles-pp.kthread"=>[19.26],
 "perf-profile.children.cycles-pp.md_thread"=>[16.0],
 "perf-profile.children.cycles-pp.raid5d"=>[15.98],
 "perf-profile.children.cycles-pp.handle_active_stripes"=>[15.68],
 "perf-profile.children.cycles-pp.handle_stripe"=>[15.62],
 "perf-profile.children.cycles-pp.__irqentry_text_start"=>[14.61],
 "perf-profile.children.cycles-pp.smp_apic_timer_interrupt"=>[14.41],
 "perf-profile.children.cycles-pp.raid_run_ops"=>[11.22],
 "perf-profile.children.cycles-pp.poll_idle"=>[10.53],
 "perf-profile.children.cycles-pp._raw_spin_lock"=>[9.31],
 "perf-profile.children.cycles-pp.entry_SYSCALL_64_fastpath"=>[9.17],
 "perf-profile.children.cycles-pp.irq_enter"=>[9.16],
 "perf-profile.children.cycles-pp.tick_irq_enter"=>[8.88],
 "perf-profile.children.cycles-pp.sys_write"=>[8.36],
 "perf-profile.children.cycles-pp.vfs_write"=>[8.29],
 "perf-profile.children.cycles-pp.__vfs_write"=>[8.15],
 "perf-profile.children.cycles-pp.btrfs_file_write_iter"=>[8.04],
 "perf-profile.children.cycles-pp.__btrfs_buffered_write"=>[7.87],
 "perf-profile.children.cycles-pp.native_queued_spin_lock_slowpath"=>[7.42],
 "perf-profile.children.cycles-pp.async_copy_data"=>[7.02],
 "perf-profile.children.cycles-pp.tick_do_update_jiffies64"=>[6.86],
 "perf-profile.children.cycles-pp.irq_exit"=>[4.53],
 "perf-profile.children.cycles-pp.x86_64_start_kernel"=>[4.4],
 "perf-profile.children.cycles-pp.x86_64_start_reservations"=>[4.4],
 "perf-profile.children.cycles-pp.start_kernel"=>[4.4],
 "perf-profile.children.cycles-pp.rest_init"=>[4.4],
 "perf-profile.children.cycles-pp.generic_make_request"=>[3.87],
 "perf-profile.children.cycles-pp.memcpy_erms"=>[3.85],
 "perf-profile.children.cycles-pp.__softirqentry_text_start"=>[3.15],
 "perf-profile.children.cycles-pp.worker_thread"=>[3.01],
 "perf-profile.children.cycles-pp.btrfs_copy_from_user"=>[2.96],
 "perf-profile.children.cycles-pp.process_one_work"=>[2.89],
 "perf-profile.children.cycles-pp.local_apic_timer_interrupt"=>[2.87],
 "perf-profile.children.cycles-pp.copy_user_enhanced_fast_string"=>[2.82],
 "perf-profile.children.cycles-pp.hrtimer_interrupt"=>[2.67],
 "perf-profile.children.cycles-pp.ops_run_io"=>[2.54],
 "perf-profile.children.cycles-pp.ret_from_intr"=>[2.5],
 "perf-profile.children.cycles-pp.do_IRQ"=>[2.5],
 "perf-profile.children.cycles-pp.btrfs_scrubparity_helper"=>[2.47],
 "perf-profile.children.cycles-pp.btrfs_submit_helper"=>[2.27],
 "perf-profile.children.cycles-pp.pending_bios_fn"=>[2.27],
 "perf-profile.children.cycles-pp.run_scheduled_bios"=>[2.27],
 "perf-profile.children.cycles-pp.submit_bio"=>[2.27],
 "perf-profile.children.cycles-pp.md_make_request"=>[2.27],
 "perf-profile.children.cycles-pp.raid5_make_request"=>[2.21],
 "perf-profile.children.cycles-pp.blk_done_softirq"=>[2.19],
 "perf-profile.children.cycles-pp.scsi_softirq_done"=>[2.19],
 "perf-profile.children.cycles-pp.scsi_finish_command"=>[2.16],
 "perf-profile.children.cycles-pp.scsi_io_completion"=>[2.13],
 "perf-profile.children.cycles-pp.scsi_end_request"=>[2.13],
 "perf-profile.children.cycles-pp.irq_work_run"=>[1.97],
 "perf-profile.children.cycles-pp.irq_work_run_list"=>[1.97],
 "perf-profile.children.cycles-pp.irq_work_interrupt"=>[1.96],
 "perf-profile.children.cycles-pp.smp_irq_work_interrupt"=>[1.96],
 "perf-profile.children.cycles-pp.perf_duration_warn"=>[1.96],
 "perf-profile.children.cycles-pp.printk"=>[1.96],
 "perf-profile.children.cycles-pp.vprintk_default"=>[1.96],
 "perf-profile.children.cycles-pp.vprintk_emit"=>[1.96],
 "perf-profile.children.cycles-pp.console_unlock"=>[1.96],


After the patch:

 

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

[Ye Xiaolong]

On 01/24, Michal Hocko wrote:
>On Mon 23-01-17 09:26:44, kernel test robot wrote:
>> 
>> Greeting,
>> 
>> FYI, we noticed a -11.1% regression of fsmark.files_per_sec due to commit:
>> 
>> 
>> commit: 5e56dfbd837421b7fa3c6c06018c6701e2704917 ("mm, vmscan: consider 
>> eligible zones in get_scan_count")
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
>This is more than unexpected. This patch should be basically noop for
>anything but CONFIG_HIGHMEM systems. And your config says this is 64b
>kernel. Are those results reproducible? And could you try to compare

Yes, the results are well reproducible, both the commit in question and its
parent have ran for 4 times.

>perf profiles before and after the patch.

Here is the perf profiles, 

Before the patch:
 "perf-profile.children.cycles-pp.verify_cpu"=>[70.92],
 "perf-profile.children.cycles-pp.cpu_startup_entry"=>[70.92],
 "perf-profile.children.cycles-pp.do_idle"=>[70.69],
 "perf-profile.children.cycles-pp.call_cpuidle"=>[69.18],
 "perf-profile.children.cycles-pp.cpuidle_enter"=>[69.14],
 "perf-profile.children.cycles-pp.cpuidle_enter_state"=>[68.63],
 "perf-profile.children.cycles-pp.start_secondary"=>[66.52],
 "perf-profile.children.cycles-pp.intel_idle"=>[39.82],
 "perf-profile.children.cycles-pp.ret_from_fork"=>[19.28],
 "perf-profile.children.cycles-pp.kthread"=>[19.26],
 "perf-profile.children.cycles-pp.md_thread"=>[16.0],
 "perf-profile.children.cycles-pp.raid5d"=>[15.98],
 "perf-profile.children.cycles-pp.handle_active_stripes"=>[15.68],
 "perf-profile.children.cycles-pp.handle_stripe"=>[15.62],
 "perf-profile.children.cycles-pp.__irqentry_text_start"=>[14.61],
 "perf-profile.children.cycles-pp.smp_apic_timer_interrupt"=>[14.41],
 "perf-profile.children.cycles-pp.raid_run_ops"=>[11.22],
 "perf-profile.children.cycles-pp.poll_idle"=>[10.53],
 "perf-profile.children.cycles-pp._raw_spin_lock"=>[9.31],
 "perf-profile.children.cycles-pp.entry_SYSCALL_64_fastpath"=>[9.17],
 "perf-profile.children.cycles-pp.irq_enter"=>[9.16],
 "perf-profile.children.cycles-pp.tick_irq_enter"=>[8.88],
 "perf-profile.children.cycles-pp.sys_write"=>[8.36],
 "perf-profile.children.cycles-pp.vfs_write"=>[8.29],
 "perf-profile.children.cycles-pp.__vfs_write"=>[8.15],
 "perf-profile.children.cycles-pp.btrfs_file_write_iter"=>[8.04],
 "perf-profile.children.cycles-pp.__btrfs_buffered_write"=>[7.87],
 "perf-profile.children.cycles-pp.native_queued_spin_lock_slowpath"=>[7.42],
 "perf-profile.children.cycles-pp.async_copy_data"=>[7.02],
 "perf-profile.children.cycles-pp.tick_do_update_jiffies64"=>[6.86],
 "perf-profile.children.cycles-pp.irq_exit"=>[4.53],
 "perf-profile.children.cycles-pp.x86_64_start_kernel"=>[4.4],
 "perf-profile.children.cycles-pp.x86_64_start_reservations"=>[4.4],
 "perf-profile.children.cycles-pp.start_kernel"=>[4.4],
 "perf-profile.children.cycles-pp.rest_init"=>[4.4],
 "perf-profile.children.cycles-pp.generic_make_request"=>[3.87],
 "perf-profile.children.cycles-pp.memcpy_erms"=>[3.85],
 "perf-profile.children.cycles-pp.__softirqentry_text_start"=>[3.15],
 "perf-profile.children.cycles-pp.worker_thread"=>[3.01],
 "perf-profile.children.cycles-pp.btrfs_copy_from_user"=>[2.96],
 "perf-profile.children.cycles-pp.process_one_work"=>[2.89],
 "perf-profile.children.cycles-pp.local_apic_timer_interrupt"=>[2.87],
 "perf-profile.children.cycles-pp.copy_user_enhanced_fast_string"=>[2.82],
 "perf-profile.children.cycles-pp.hrtimer_interrupt"=>[2.67],
 "perf-profile.children.cycles-pp.ops_run_io"=>[2.54],
 "perf-profile.children.cycles-pp.ret_from_intr"=>[2.5],
 "perf-profile.children.cycles-pp.do_IRQ"=>[2.5],
 "perf-profile.children.cycles-pp.btrfs_scrubparity_helper"=>[2.47],
 "perf-profile.children.cycles-pp.btrfs_submit_helper"=>[2.27],
 "perf-profile.children.cycles-pp.pending_bios_fn"=>[2.27],
 "perf-profile.children.cycles-pp.run_scheduled_bios"=>[2.27],
 "perf-profile.children.cycles-pp.submit_bio"=>[2.27],
 "perf-profile.children.cycles-pp.md_make_request"=>[2.27],
 "perf-profile.children.cycles-pp.raid5_make_request"=>[2.21],
 "perf-profile.children.cycles-pp.blk_done_softirq"=>[2.19],
 "perf-profile.children.cycles-pp.scsi_softirq_done"=>[2.19],
 "perf-profile.children.cycles-pp.scsi_finish_command"=>[2.16],
 "perf-profile.children.cycles-pp.scsi_io_completion"=>[2.13],
 "perf-profile.children.cycles-pp.scsi_end_request"=>[2.13],
 "perf-profile.children.cycles-pp.irq_work_run"=>[1.97],
 "perf-profile.children.cycles-pp.irq_work_run_list"=>[1.97],
 "perf-profile.children.cycles-pp.irq_work_interrupt"=>[1.96],
 "perf-profile.children.cycles-pp.smp_irq_work_interrupt"=>[1.96],
 "perf-profile.children.cycles-pp.perf_duration_warn"=>[1.96],
 "perf-profile.children.cycles-pp.printk"=>[1.96],
 "perf-profile.children.cycles-pp.vprintk_default"=>[1.96],
 "perf-profile.children.cycles-pp.vprintk_emit"=>[1.96],
 "perf-profile.children.cycles-pp.console_unlock"=>[1.96],


After the patch:

 

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Sergey Senozhatsky]

On (01/24/17 18:48), Matthew Wilcox wrote:
> On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote:
> > Hello,
> > 
> > On (01/25/17 10:29), Minchan Kim wrote:
> > [..]
> > > > the result as listed below:
> > > > 
> > > > zeropattern_char   pattern_short   pattern_int   pattern_long   
> > > > total  (unit)
> > > > 162989  14454  353423516 2769   
> > > > 3294399(page)
> > > > 
> > >
> > > so, int covers 93%. As considering non-zero dedup hit ratio is low, I 
> > > think *int* is
> > > enough if memset is really fast. So, I'd like to go with 'int' if Sergey 
> > > doesn't mind.
> > 
> > yep, 4 byte pattern matching and memset() sounds like a good plan to me
> 
> what?  memset ONLY HANDLES BYTES.
> 
> I pointed this out earlier, but you don't seem to be listening.  Let me
> try it again.
> 
> MEMSET ONLY HANDLES BYTES.

dammit... how did that happen...


Matthew, you are absolute right. and, yes, I missed out your previous
mail, indeed. sorry. and thanks for "re-pointing" that out.


Minchan, zhouxianrong, I was completely wrong. we can't
do memset(). d'oh, I did not know it truncates 4 bytes to
one byte only (doesn't make too much sense to me).

my apologies.

-ss

Re: [PATCH] mm: extend zero pages to same element pages for zram

[Sergey Senozhatsky]

On (01/24/17 18:48), Matthew Wilcox wrote:
> On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote:
> > Hello,
> > 
> > On (01/25/17 10:29), Minchan Kim wrote:
> > [..]
> > > > the result as listed below:
> > > > 
> > > > zeropattern_char   pattern_short   pattern_int   pattern_long   
> > > > total  (unit)
> > > > 162989  14454  353423516 2769   
> > > > 3294399(page)
> > > > 
> > >
> > > so, int covers 93%. As considering non-zero dedup hit ratio is low, I 
> > > think *int* is
> > > enough if memset is really fast. So, I'd like to go with 'int' if Sergey 
> > > doesn't mind.
> > 
> > yep, 4 byte pattern matching and memset() sounds like a good plan to me
> 
> what?  memset ONLY HANDLES BYTES.
> 
> I pointed this out earlier, but you don't seem to be listening.  Let me
> try it again.
> 
> MEMSET ONLY HANDLES BYTES.

dammit... how did that happen...


Matthew, you are absolute right. and, yes, I missed out your previous
mail, indeed. sorry. and thanks for "re-pointing" that out.


Minchan, zhouxianrong, I was completely wrong. we can't
do memset(). d'oh, I did not know it truncates 4 bytes to
one byte only (doesn't make too much sense to me).

my apologies.

-ss

linux-next: manual merge of the userns tree with the selinux tree

[Stephen Rothwell]

Hi Eric,

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

  security/selinux/hooks.c

between commit:

  be0554c9bf9f ("selinux: clean up cred usage and simplify")

from the selinux tree and commit:

  9227dd2a84a7 ("exec: Remove LSM_UNSAFE_PTRACE_CAP")

from the userns tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc security/selinux/hooks.c
index 0d24eb2325d2,cece6fe55f02..
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@@ -2397,9 -2404,8 +2397,8 @@@ static int selinux_bprm_set_creds(struc
  
/* Make sure that anyone attempting to ptrace over a task that
 * changes its SID has the appropriate permit */
-   if (bprm->unsafe &
-   (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
+   if (bprm->unsafe & LSM_UNSAFE_PTRACE) {
 -  u32 ptsid = ptrace_parent_sid(current);
 +  u32 ptsid = ptrace_parent_sid();
if (ptsid != 0) {
rc = avc_has_perm(ptsid, new_tsec->sid,
  SECCLASS_PROCESS,

linux-next: manual merge of the userns tree with the selinux tree

[Stephen Rothwell]

Hi Eric,

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

  security/selinux/hooks.c

between commit:

  be0554c9bf9f ("selinux: clean up cred usage and simplify")

from the selinux tree and commit:

  9227dd2a84a7 ("exec: Remove LSM_UNSAFE_PTRACE_CAP")

from the userns tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc security/selinux/hooks.c
index 0d24eb2325d2,cece6fe55f02..
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@@ -2397,9 -2404,8 +2397,8 @@@ static int selinux_bprm_set_creds(struc
  
/* Make sure that anyone attempting to ptrace over a task that
 * changes its SID has the appropriate permit */
-   if (bprm->unsafe &
-   (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
+   if (bprm->unsafe & LSM_UNSAFE_PTRACE) {
 -  u32 ptsid = ptrace_parent_sid(current);
 +  u32 ptsid = ptrace_parent_sid();
if (ptsid != 0) {
rc = avc_has_perm(ptsid, new_tsec->sid,
  SECCLASS_PROCESS,