Re: [PATCH v4 2/6] dt-bindings: power: Add qcom rpm power domain driver bindings

On 03-07-18, 16:35, Rob Herring wrote: > > +qcom,level values specified in the OPP tables for RPMh power domains > > +should use the RPMH_REGULATOR_LEVEL_* constants from > > + > > + > > + rpmhpd: power-controller { > > + compatible = "qcom,sdm845-rpmhpd"; > > +

Re: [PATCH v4 2/6] dt-bindings: power: Add qcom rpm power domain driver bindings

On 03-07-18, 16:35, Rob Herring wrote: > > +qcom,level values specified in the OPP tables for RPMh power domains > > +should use the RPMH_REGULATOR_LEVEL_* constants from > > + > > + > > + rpmhpd: power-controller { > > + compatible = "qcom,sdm845-rpmhpd"; > > +

linux-next: Tree for Jul 4

Hi all, Changes since 20180703: The net-next tree lost its build failure. The akpm-current tree lost its build failure. Non-merge commits (relative to Linus' tree): 3555 3796 files changed, 134005 insertions(+), 74047 deletions

linux-next: Tree for Jul 4

Hi all, Changes since 20180703: The net-next tree lost its build failure. The akpm-current tree lost its build failure. Non-merge commits (relative to Linus' tree): 3555 3796 files changed, 134005 insertions(+), 74047 deletions

[PATCH v2 1/3] nds32: To implement these icache invalidation APIs since nds32 cores don't snoop data cache. This issue is found by Guo Ren. Based on the Documentation/core-api/cachetlb.rst and it says

"Any necessary cache flushing or other coherency operations that need to occur should happen here. If the processor's instruction cache does not snoop cpu stores, it is very likely that you will need to flush the instruction cache for copy_to_user_page()." "If the icache does not snoop stores

[PATCH v2 1/3] nds32: To implement these icache invalidation APIs since nds32 cores don't snoop data cache. This issue is found by Guo Ren. Based on the Documentation/core-api/cachetlb.rst and it says

"Any necessary cache flushing or other coherency operations that need to occur should happen here. If the processor's instruction cache does not snoop cpu stores, it is very likely that you will need to flush the instruction cache for copy_to_user_page()." "If the icache does not snoop stores

[PATCH v2 2/3] nds32: Fix the dts pointer is not passed correctly issue.

We found that the original implementation will only use the built-in dtb pointer instead of the pointer pass from bootloader. This bug is fixed by this patch. Signed-off-by: Greentime Hu --- arch/nds32/kernel/setup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 01/11] hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h

asm-generic/hugetlb.h proposes generic implementations of hugetlb related functions: use __HAVE_ARCH_HUGE* defines in order to make arch specific implementations of hugetlb functions consistent with pgtable.h scheme. Signed-off-by: Alexandre Ghiti --- arch/arm64/include/asm/hugetlb.h | 2 +-

[PATCH v2 2/3] nds32: Fix the dts pointer is not passed correctly issue.

We found that the original implementation will only use the built-in dtb pointer instead of the pointer pass from bootloader. This bug is fixed by this patch. Signed-off-by: Greentime Hu --- arch/nds32/kernel/setup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 01/11] hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h

asm-generic/hugetlb.h proposes generic implementations of hugetlb related functions: use __HAVE_ARCH_HUGE* defines in order to make arch specific implementations of hugetlb functions consistent with pgtable.h scheme. Signed-off-by: Alexandre Ghiti --- arch/arm64/include/asm/hugetlb.h | 2 +-

[PATCH v2 3/3] nds32: To simplify the implementation of update_mmu_cache()

The checking code is done in kmap_atomic() so that we don't need to check it in update_mmu_cache() again. There is no need to implement it for cache aliasing or cache non-aliasing versions. We can just implement one version for both. Signed-off-by: Greentime Hu --- arch/nds32/mm/cacheflush.c |

[PATCH v2 3/3] nds32: To simplify the implementation of update_mmu_cache()

The checking code is done in kmap_atomic() so that we don't need to check it in update_mmu_cache() again. There is no need to implement it for cache aliasing or cache non-aliasing versions. We can just implement one version for both. Signed-off-by: Greentime Hu --- arch/nds32/mm/cacheflush.c |

Re: [PATCH v7] add param that allows bootline control of hardened usercopy

On Tue, Jul 3, 2018 at 12:43 PM, Chris von Recklinghausen wrote: > Enabling HARDENED_USERCOPY causes measurable regressions in > networking performance, up to 8% under UDP flood. > > I'm running an a small packet UDP flood using pktgen vs. a host b2b > connected. On the receiver side the UDP

Re: [PATCH v7] add param that allows bootline control of hardened usercopy

On Tue, Jul 3, 2018 at 12:43 PM, Chris von Recklinghausen wrote: > Enabling HARDENED_USERCOPY causes measurable regressions in > networking performance, up to 8% under UDP flood. > > I'm running an a small packet UDP flood using pktgen vs. a host b2b > connected. On the receiver side the UDP

Re: [PATCH v5 07/12] PM / devfreq: export devfreq_class

Hi, I didn't see any framework which exporting the class instance. It is very dangerous. Unknown device drivers is able to reset the 'devfreq_class' instance. I can't agree this approach. Regards, Chanwoo Choi On 2018년 07월 04일 08:47, Matthias Kaehlcke wrote: > Exporting the device class allows

Re: [PATCH v5 07/12] PM / devfreq: export devfreq_class

Hi, I didn't see any framework which exporting the class instance. It is very dangerous. Unknown device drivers is able to reset the 'devfreq_class' instance. I can't agree this approach. Regards, Chanwoo Choi On 2018년 07월 04일 08:47, Matthias Kaehlcke wrote: > Exporting the device class allows

Re: [PATCH V2 19/19] irqchip: add C-SKY irqchip drivers

On Tue, Jul 03, 2018 at 11:28:03AM +0200, Thomas Gleixner wrote: > -EEMPTYCHANGELOG Ok, I'll seperate this patchset's changelog from cover-letter in next version patch. > > +#ifdef CONFIG_CSKY_VECIRQ_LEGENCY > > I assume you meant _LEGACY Yes. > > +#include > > +#endif > > Also why making the

Re: [PATCH V2 19/19] irqchip: add C-SKY irqchip drivers

On Tue, Jul 03, 2018 at 11:28:03AM +0200, Thomas Gleixner wrote: > -EEMPTYCHANGELOG Ok, I'll seperate this patchset's changelog from cover-letter in next version patch. > > +#ifdef CONFIG_CSKY_VECIRQ_LEGENCY > > I assume you meant _LEGACY Yes. > > +#include > > +#endif > > Also why making the

Re: [PATCH v2 0/5] Improve Broadcom PAXC support

Hi Lorenzo, A friendly reminder: Have you had a chance to help to review the patch series below? Thanks, Ray On 6/21/2018 11:22 AM, Ray Jui wrote: Hi Lorenzo, On 6/21/2018 9:48 AM, Lorenzo Pieralisi wrote: On Wed, Jun 20, 2018 at 10:26:28AM -0700, Ray Jui wrote: Hi Lorenzo/Bjorn, Could

Re: [PATCH v2 0/5] Improve Broadcom PAXC support

Hi Lorenzo, A friendly reminder: Have you had a chance to help to review the patch series below? Thanks, Ray On 6/21/2018 11:22 AM, Ray Jui wrote: Hi Lorenzo, On 6/21/2018 9:48 AM, Lorenzo Pieralisi wrote: On Wed, Jun 20, 2018 at 10:26:28AM -0700, Ray Jui wrote: Hi Lorenzo/Bjorn, Could

Re: Build regressions/improvements in v4.18-rc3

Helge Deller writes: > On 03.07.2018 03:09, Michael Ellerman wrote: >> Helge Deller writes: >> >>> On 02.07.2018 16:09, Geert Uytterhoeven wrote: On Mon, Jul 2, 2018 at 4:01 PM Geert Uytterhoeven wrote: > JFYI, when comparing v4.18-rc3[1] to v4.18-rc2[3], the summaries are:

Re: Build regressions/improvements in v4.18-rc3

Helge Deller writes: > On 03.07.2018 03:09, Michael Ellerman wrote: >> Helge Deller writes: >> >>> On 02.07.2018 16:09, Geert Uytterhoeven wrote: On Mon, Jul 2, 2018 at 4:01 PM Geert Uytterhoeven wrote: > JFYI, when comparing v4.18-rc3[1] to v4.18-rc2[3], the summaries are:

Re: Build regressions/improvements in v4.18-rc3

John David Anglin writes: > On 2018-07-02 9:09 PM, Michael Ellerman wrote: >> It's GCC 4.6.3. Are you saying that's not supported anymore? > See for supported releases. Thanks, but I mean "supported by the parisc Linux port". Allegedly the kernel builds with GCC 3.2:

Re: Build regressions/improvements in v4.18-rc3

John David Anglin writes: > On 2018-07-02 9:09 PM, Michael Ellerman wrote: >> It's GCC 4.6.3. Are you saying that's not supported anymore? > See for supported releases. Thanks, but I mean "supported by the parisc Linux port". Allegedly the kernel builds with GCC 3.2:

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

Hi Greg, On Wed, Jul 04, 2018 at 02:39:05PM +1000, Greg Ungerer wrote: > Hi Mike, > > On 04/07/18 14:22, Mike Rapoport wrote: > >On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote: > >>On 04/07/18 11:39, Greg Ungerer wrote: > >>>On 03/07/18 20:29, Mike Rapoport wrote: > In m68k the

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

Hi Greg, On Wed, Jul 04, 2018 at 02:39:05PM +1000, Greg Ungerer wrote: > Hi Mike, > > On 04/07/18 14:22, Mike Rapoport wrote: > >On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote: > >>On 04/07/18 11:39, Greg Ungerer wrote: > >>>On 03/07/18 20:29, Mike Rapoport wrote: > In m68k the

[PATCH v3 0/4] Add devicetree functionality to w1 busses and ds2760

This patch set contains four patches that bring devicetree functionality to w1 bus masters and slaves in general. As an example, the ds2760 driver is made aware of devicetree probing. Other drivers can easily be ported later. W1 masters scan their bus in order to discover slave devices. Once one

[PATCH v3 0/4] Add devicetree functionality to w1 busses and ds2760

This patch set contains four patches that bring devicetree functionality to w1 bus masters and slaves in general. As an example, the ds2760 driver is made aware of devicetree probing. Other drivers can easily be ported later. W1 masters scan their bus in order to discover slave devices. Once one

[PATCH v3 2/4] w1: core: match sub-nodes of bus masters in devicetree

Once a new slave device is detected, match it against all sub-nodes of the master bus controller. If a match is found, set the slave device's of_node pointer. Signed-off-by: Daniel Mack --- drivers/w1/w1.c| 3 +++ include/linux/w1.h | 2 ++ 2 files changed, 5 insertions(+) diff --git

[PATCH v3 2/4] w1: core: match sub-nodes of bus masters in devicetree

Once a new slave device is detected, match it against all sub-nodes of the master bus controller. If a match is found, set the slave device's of_node pointer. Signed-off-by: Daniel Mack --- drivers/w1/w1.c| 3 +++ include/linux/w1.h | 2 ++ 2 files changed, 5 insertions(+) diff --git

[PATCH v3 1/4] dt-bindings: w1: document generic onewire and DS2760 bindings

This patch adds a generic w1 bindings document that merely describes how slave deviceses are grouped under master nodes. It also adds a specific binding for the ds2760 battery monitor. Signed-off-by: Daniel Mack --- .../bindings/power/supply/maxim,ds2760.txt| 29 +++

[PATCH v3 4/4] power: supply: ds2760_battery: add devicetree probing

Add a matching table for devicetree probing, and optionally set the module parameter variables from DT properties. Signed-off-by: Daniel Mack --- drivers/power/supply/ds2760_battery.c | 32 ++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git

[PATCH v3 3/4] power: supply: ds2760_battery: merge ds2760 supply driver with its w1 slave companion

This patch removes the w1 slave driver that used to register the w1 family and instanciate a platform device at runtime. The code now lives in the supply driver instead to avoid that level of indirection. The old device name "ds2760-battery.0" is preserved, so userspace applications can access

[PATCH v3 1/4] dt-bindings: w1: document generic onewire and DS2760 bindings

This patch adds a generic w1 bindings document that merely describes how slave deviceses are grouped under master nodes. It also adds a specific binding for the ds2760 battery monitor. Signed-off-by: Daniel Mack --- .../bindings/power/supply/maxim,ds2760.txt| 29 +++

[PATCH v3 4/4] power: supply: ds2760_battery: add devicetree probing

Add a matching table for devicetree probing, and optionally set the module parameter variables from DT properties. Signed-off-by: Daniel Mack --- drivers/power/supply/ds2760_battery.c | 32 ++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git

[PATCH v3 3/4] power: supply: ds2760_battery: merge ds2760 supply driver with its w1 slave companion

This patch removes the w1 slave driver that used to register the w1 family and instanciate a platform device at runtime. The code now lives in the supply driver instead to avoid that level of indirection. The old device name "ds2760-battery.0" is preserved, so userspace applications can access

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

Hi Mike, On 04/07/18 14:22, Mike Rapoport wrote: On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote: On 04/07/18 11:39, Greg Ungerer wrote: On 03/07/18 20:29, Mike Rapoport wrote: In m68k the physical memory is described by [memory_start, memory_end] for !MMU variant and by

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

Hi Mike, On 04/07/18 14:22, Mike Rapoport wrote: On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote: On 04/07/18 11:39, Greg Ungerer wrote: On 03/07/18 20:29, Mike Rapoport wrote: In m68k the physical memory is described by [memory_start, memory_end] for !MMU variant and by

Re: [PATCH 0/5] thunderbolt: Add support for runtime PM

On Mon, Jun 18, 2018 at 02:07:26PM +0300, Mika Westerberg wrote: > Hi all, > > In recent PCs such as Lenovo X1 Carbon 6th generation the Thunderbolt > controller is in RTD3 mode (Runtime D3). This is different from the > previous modes because now the controller is present most of the time (it >

Re: [PATCH 0/5] thunderbolt: Add support for runtime PM

On Mon, Jun 18, 2018 at 02:07:26PM +0300, Mika Westerberg wrote: > Hi all, > > In recent PCs such as Lenovo X1 Carbon 6th generation the Thunderbolt > controller is in RTD3 mode (Runtime D3). This is different from the > previous modes because now the controller is present most of the time (it >

[PATCH] mfd: ti_am335x_tscadc: Fix struct clk memory leak

Use devm_elk_get() to let Linux manage struct clk memory to avoid the following memory leakage report: unreferenced object 0xdd75efc0 (size 64): comm "systemd-udevd", pid 186, jiffies 4294945126 (age 1195.750s) hex dump (first 32 bytes): 61 64 63 5f 74 73 63 5f 66 63 6b 00 00 00 00 00

[PATCH] mfd: ti_am335x_tscadc: Fix struct clk memory leak

Use devm_elk_get() to let Linux manage struct clk memory to avoid the following memory leakage report: unreferenced object 0xdd75efc0 (size 64): comm "systemd-udevd", pid 186, jiffies 4294945126 (age 1195.750s) hex dump (first 32 bytes): 61 64 63 5f 74 73 63 5f 66 63 6b 00 00 00 00 00

Re: [PATCH v12 09/13] x86/sgx: EPC page allocation routines

On Tue, Jul 03, 2018 at 10:41:14PM +0200, Thomas Gleixner wrote: > On Tue, 3 Jul 2018, Jarkko Sakkinen wrote: > > > > +#define SGX_NR_TO_SCAN 16 > > +#define SGX_NR_LOW_PAGES 32 > > +#define SGX_NR_HIGH_PAGES 64 > > + > > bool sgx_enabled __ro_after_init; > > EXPORT_SYMBOL(sgx_enabled); >

Re: [PATCH v12 09/13] x86/sgx: EPC page allocation routines

On Tue, Jul 03, 2018 at 10:41:14PM +0200, Thomas Gleixner wrote: > On Tue, 3 Jul 2018, Jarkko Sakkinen wrote: > > > > +#define SGX_NR_TO_SCAN 16 > > +#define SGX_NR_LOW_PAGES 32 > > +#define SGX_NR_HIGH_PAGES 64 > > + > > bool sgx_enabled __ro_after_init; > > EXPORT_SYMBOL(sgx_enabled); >

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote: > Hi Mike, > > On 04/07/18 11:39, Greg Ungerer wrote: > >On 03/07/18 20:29, Mike Rapoport wrote: > >>In m68k the physical memory is described by [memory_start, memory_end] for > >>!MMU variant and by m68k_memory array of memory ranges

Re: [PATCH 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote: > Hi Mike, > > On 04/07/18 11:39, Greg Ungerer wrote: > >On 03/07/18 20:29, Mike Rapoport wrote: > >>In m68k the physical memory is described by [memory_start, memory_end] for > >>!MMU variant and by m68k_memory array of memory ranges

Re: linux-next: build warning after merge of the slave-dma tree

Hi Stephen, On 04-07-18, 13:30, Stephen Rothwell wrote: > > After merging the slave-dma tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-edma-common.o Thanks for the report, I have fixed it by adding

Re: linux-next: build warning after merge of the slave-dma tree

Hi Stephen, On 04-07-18, 13:30, Stephen Rothwell wrote: > > After merging the slave-dma tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-edma-common.o Thanks for the report, I have fixed it by adding

kernel BUG at mm/gup.c:LINE!

Hello, syzbot found the following crash on: HEAD commit:d3bc0e67f852 Merge tag 'for-4.18-rc2-tag' of git://git.ker.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=177c40 kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370

kernel BUG at mm/gup.c:LINE!

Hello, syzbot found the following crash on: HEAD commit:d3bc0e67f852 Merge tag 'for-4.18-rc2-tag' of git://git.ker.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=177c40 kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370

Re: [build-check] scripts: add check_build script

On July 3, 2018 5:21:20 PM PDT, Stephen Rothwell wrote: >Hi all, > >On Tue, 3 Jul 2018 16:27:06 -0700 Randy Dunlap >wrote: >> >> On 07/03/2018 03:49 PM, Andrew Morton wrote: >> > On Tue, 3 Jul 2018 15:12:10 +0200 Norbert Manthey > wrote: >> >> +build () >> >> +{ >> >> + local -r LOG_FILE="$1"

Re: [build-check] scripts: add check_build script

On July 3, 2018 5:21:20 PM PDT, Stephen Rothwell wrote: >Hi all, > >On Tue, 3 Jul 2018 16:27:06 -0700 Randy Dunlap >wrote: >> >> On 07/03/2018 03:49 PM, Andrew Morton wrote: >> > On Tue, 3 Jul 2018 15:12:10 +0200 Norbert Manthey > wrote: >> >> +build () >> >> +{ >> >> + local -r LOG_FILE="$1"

Re: [PATCH] userfaultfd: hugetlbfs: Fix userfaultfd_huge_must_wait pte access

Hello, On Wed, Jun 27, 2018 at 10:47:44AM +0200, Janosch Frank wrote: > On 26.06.2018 19:00, Mike Kravetz wrote: > > On 06/26/2018 06:24 AM, Janosch Frank wrote: > >> Use huge_ptep_get to translate huge ptes to normal ptes so we can > >> check them with the huge_pte_* functions. Otherwise some

Re: [PATCHv5 0/4] Salted build ids via ELF notes

Hi. 2018-07-04 8:21 GMT+09:00 Laura Abbott : > > Hi, > > This is v5 of the series to allow unique build ids in the kernel. As a > reminder of the context: > "" > In Fedora, the debug information is packaged separately (foo-debuginfo) and > can be installed separately. There's been a long

Re: [PATCH] userfaultfd: hugetlbfs: Fix userfaultfd_huge_must_wait pte access

Hello, On Wed, Jun 27, 2018 at 10:47:44AM +0200, Janosch Frank wrote: > On 26.06.2018 19:00, Mike Kravetz wrote: > > On 06/26/2018 06:24 AM, Janosch Frank wrote: > >> Use huge_ptep_get to translate huge ptes to normal ptes so we can > >> check them with the huge_pte_* functions. Otherwise some

Re: [PATCHv5 0/4] Salted build ids via ELF notes

Hi. 2018-07-04 8:21 GMT+09:00 Laura Abbott : > > Hi, > > This is v5 of the series to allow unique build ids in the kernel. As a > reminder of the context: > "" > In Fedora, the debug information is packaged separately (foo-debuginfo) and > can be installed separately. There's been a long

RE: [RFC PATCH 1/2] fpga: fpga-mgr: Add readback support

Hi Alan, Thanks for the review... Please find comments inline... > > Hi Appana, > > > Inorder to debug issues with fpga's users would like to read the fpga > > configuration information. > > This patch adds readback support for fpga configuration data in the > > framework through

RE: [RFC PATCH 1/2] fpga: fpga-mgr: Add readback support

Hi Alan, Thanks for the review... Please find comments inline... > > Hi Appana, > > > Inorder to debug issues with fpga's users would like to read the fpga > > configuration information. > > This patch adds readback support for fpga configuration data in the > > framework through

Re: [RFC PATCH] ACPI: bus: match of_device_id using acpi device

Hi Sudeep, Andy, Yes, This patch is to get of_device_id and then fetch data pointer. To add ACPI support in multiple drivers which are device-tree based and has list of of_device_ids, by using this function very minimal changes and can avoid acpi_device_id list in the driver. I will send driver

Re: [RFC PATCH] ACPI: bus: match of_device_id using acpi device

Hi Sudeep, Andy, Yes, This patch is to get of_device_id and then fetch data pointer. To add ACPI support in multiple drivers which are device-tree based and has list of of_device_ids, by using this function very minimal changes and can avoid acpi_device_id list in the driver. I will send driver

linux-next: build warning after merge of the slave-dma tree

Hi Vinod, After merging the slave-dma tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-edma-common.o Introduced by commit 6ad069123f03 ("dmaengine: fsl-edma: extract common fsl-edma code (no changes in

linux-next: build warning after merge of the slave-dma tree

Hi Vinod, After merging the slave-dma tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-edma-common.o Introduced by commit 6ad069123f03 ("dmaengine: fsl-edma: extract common fsl-edma code (no changes in

[PATCH v2] tg: show the sum wait time of an task group

Although we can rely on cpuacct to present the cpu usage of task group, it is hard to tell how intense the competition is between these groups on cpu resources. Monitoring the wait time of each process or sched_debug could cost too much, and there is no good way to accurately represent the

[PATCH v2] tg: show the sum wait time of an task group

Although we can rely on cpuacct to present the cpu usage of task group, it is hard to tell how intense the competition is between these groups on cpu resources. Monitoring the wait time of each process or sched_debug could cost too much, and there is no good way to accurately represent the

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

On Tue, Jul 03, 2018 at 05:21:50PM +0300, Kirill A. Shutemov wrote: > I don't know how to solve it. As far as I know we don't support compiling > kernel with LTO in mainline. > > Any suggestions? > > Benjamin, do you change LDFLAGS or CFLAGS when compiling the kernel? We're using the standard

Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"

On Tue, Jul 03, 2018 at 05:21:50PM +0300, Kirill A. Shutemov wrote: > I don't know how to solve it. As far as I know we don't support compiling > kernel with LTO in mainline. > > Any suggestions? > > Benjamin, do you change LDFLAGS or CFLAGS when compiling the kernel? We're using the standard

Re: [PATCH V2 5/7] mmc: sdhci: add CMD23 support for v4 mode

On 23 June 2018 at 03:40, Adrian Hunter wrote: > On 06/15/2018 05:04 AM, Chunyan Zhang wrote: >> Host Driver Version 4.10 adds a new bit in Host Control 2 Register >> for selecting Auto CMD23 or Auto CMD12 for ADMA3 data transfer. > > We don't support ADMA3. It would require changes to the block

Re: [PATCH V2 3/7] mmc: sdhci: add ADMA2 64-bit addressing support for V4 mode

On 21 June 2018 at 21:20, Adrian Hunter wrote: > On 15/06/18 05:04, Chunyan Zhang wrote: >> ADMA2 64-bit addressing support is divided into V3 mode and V4 mode. >> So there are two kinds of descriptors for ADMA2 64-bit addressing >> i.e. 96-bit Descriptor for V3 mode, and 128-bit Descriptor for

Re: [PATCH V2 5/7] mmc: sdhci: add CMD23 support for v4 mode

On 23 June 2018 at 03:40, Adrian Hunter wrote: > On 06/15/2018 05:04 AM, Chunyan Zhang wrote: >> Host Driver Version 4.10 adds a new bit in Host Control 2 Register >> for selecting Auto CMD23 or Auto CMD12 for ADMA3 data transfer. > > We don't support ADMA3. It would require changes to the block

Re: [PATCH V2 3/7] mmc: sdhci: add ADMA2 64-bit addressing support for V4 mode

On 21 June 2018 at 21:20, Adrian Hunter wrote: > On 15/06/18 05:04, Chunyan Zhang wrote: >> ADMA2 64-bit addressing support is divided into V3 mode and V4 mode. >> So there are two kinds of descriptors for ADMA2 64-bit addressing >> i.e. 96-bit Descriptor for V3 mode, and 128-bit Descriptor for

Re: [PATCH V2 1/7] mmc: sdhci: add sd host v4 mode

On 21 June 2018 at 21:15, Adrian Hunter wrote: > On 21/06/18 14:14, Chunyan Zhang wrote: >> On 21 June 2018 at 18:49, Adrian Hunter wrote: >>> On 15/06/18 05:04, Chunyan Zhang wrote: For SD host controller version 4.00 or later ones, there're two modes of implementation - Version 3.00

Re: [PATCH V2 1/7] mmc: sdhci: add sd host v4 mode

On 21 June 2018 at 21:15, Adrian Hunter wrote: > On 21/06/18 14:14, Chunyan Zhang wrote: >> On 21 June 2018 at 18:49, Adrian Hunter wrote: >>> On 15/06/18 05:04, Chunyan Zhang wrote: For SD host controller version 4.00 or later ones, there're two modes of implementation - Version 3.00

Re: [PATCH V2 2/7] mmc: sdhci: made changes for System Address register of SDMA

On 21 June 2018 at 19:22, Adrian Hunter wrote: > On 15/06/18 05:04, Chunyan Zhang wrote: >> According to the SD host controller specification version 4.10, when >> Host Version 4 is enabled, SDMA uses ADMA System Address register >> (05Fh-058h) instead of using SDMA System Address register to >>

Re: [PATCH V2 2/7] mmc: sdhci: made changes for System Address register of SDMA

On 21 June 2018 at 19:22, Adrian Hunter wrote: > On 15/06/18 05:04, Chunyan Zhang wrote: >> According to the SD host controller specification version 4.10, when >> Host Version 4 is enabled, SDMA uses ADMA System Address register >> (05Fh-058h) instead of using SDMA System Address register to >>

Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece

Sergey Senozhatsky writes: > On (07/04/18 10:20), Huang, Ying wrote: >> > On (06/27/18 21:51), Andrew Morton wrote: >> >> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" >> >> wrote: >> >> >> >> > This is the final step of THP (Transparent Huge Page) swap >> >> > optimization. After the

Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece

Sergey Senozhatsky writes: > On (07/04/18 10:20), Huang, Ying wrote: >> > On (06/27/18 21:51), Andrew Morton wrote: >> >> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" >> >> wrote: >> >> >> >> > This is the final step of THP (Transparent Huge Page) swap >> >> > optimization. After the

Re: [PATCH v5 04/12] PM / devfreq: Add struct devfreq_policy

Hi, On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote: > Move variables related with devfreq policy changes from struct devfreq > to the new struct devfreq_policy and add a policy field to struct devfreq. > > The following variables are moved: > > df->min/max_freq =>

Re: [PATCH v5 04/12] PM / devfreq: Add struct devfreq_policy

Hi, On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote: > Move variables related with devfreq policy changes from struct devfreq > to the new struct devfreq_policy and add a policy field to struct devfreq. > > The following variables are moved: > > df->min/max_freq =>

Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs

> -Original Mail- > Sender: Borislav Petkov [mailto:b...@alien8.de] > Time: 2018年6月26日 22:30 > Receiver: David Wang > CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de; > h...@zytor.com; x...@kernel.org; linux-kernel@vger.kernel.org; > linux-e...@vger.kernel.org;

Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs

> -Original Mail- > Sender: Borislav Petkov [mailto:b...@alien8.de] > Time: 2018年6月26日 22:30 > Receiver: David Wang > CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de; > h...@zytor.com; x...@kernel.org; linux-kernel@vger.kernel.org; > linux-e...@vger.kernel.org;

Re: [PATCH v2] leds: ledtrig-morse: send out morse code

On Tue, Jul 03, 2018 at 09:43:06PM +0300, Andy Shevchenko wrote: > > +struct morse_char { > > + charc; > > + char*z; > > +}; > > + > > > +static struct morse_char morse_table[] = { > > const ? > > > + {'a', ".-"}, > > + {'b', "-..."}, > > + {'c', "-.-."}, >

Re: [PATCH v2] leds: ledtrig-morse: send out morse code

On Tue, Jul 03, 2018 at 09:43:06PM +0300, Andy Shevchenko wrote: > > +struct morse_char { > > + charc; > > + char*z; > > +}; > > + > > > +static struct morse_char morse_table[] = { > > const ? > > > + {'a', ".-"}, > > + {'b', "-..."}, > > + {'c', "-.-."}, >

Re: [PATCH v22 4/4] soc: mediatek: Add Mediatek CMDQ helper

Hi, Houlong: On Wed, 2018-07-04 at 08:47 +0800, houlong wei wrote: > On Fri, 2018-06-29 at 17:22 +0800, CK Hu wrote: > > Hi, Houlong: > > > > On Fri, 2018-06-29 at 07:32 +0800, houlong wei wrote: > > > On Thu, 2018-06-28 at 18:41 +0800, CK Hu wrote: > > > > Hi, Houlong: > > > > > > > > Some

Re: [PATCH v22 4/4] soc: mediatek: Add Mediatek CMDQ helper

Hi, Houlong: On Wed, 2018-07-04 at 08:47 +0800, houlong wei wrote: > On Fri, 2018-06-29 at 17:22 +0800, CK Hu wrote: > > Hi, Houlong: > > > > On Fri, 2018-06-29 at 07:32 +0800, houlong wei wrote: > > > On Thu, 2018-06-28 at 18:41 +0800, CK Hu wrote: > > > > Hi, Houlong: > > > > > > > > Some

Re: [PATCH v5 03/12] PM / devfreq: Don't adjust to user limits in governors

Hi Matthias, On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote: > Several governors use the user space limits df->min/max_freq to adjust > the target frequency. This is not necessary, since update_devfreq() > already takes care of this. Instead the governor can request the available > min/max

Re: [PATCH v5 03/12] PM / devfreq: Don't adjust to user limits in governors

Hi Matthias, On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote: > Several governors use the user space limits df->min/max_freq to adjust > the target frequency. This is not necessary, since update_devfreq() > already takes care of this. Instead the governor can request the available > min/max

Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece

On (07/04/18 10:20), Huang, Ying wrote: > > On (06/27/18 21:51), Andrew Morton wrote: > >> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" > >> wrote: > >> > >> > This is the final step of THP (Transparent Huge Page) swap > >> > optimization. After the first and second step, the splitting

Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece

On (07/04/18 10:20), Huang, Ying wrote: > > On (06/27/18 21:51), Andrew Morton wrote: > >> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" > >> wrote: > >> > >> > This is the final step of THP (Transparent Huge Page) swap > >> > optimization. After the first and second step, the splitting

Re: [patch v3] mm, oom: fix unnecessary killing of additional processes

David Rientjes wrote: > Ping? > > This can be something that can easily be removed if it becomes obsoleted > because the oom reaper is always able to free memory to the extent of > exit_mmap(). I argue that it cannot, because it cannot do free_pgtables() > for large amounts of virtual memory,

Re: [patch v3] mm, oom: fix unnecessary killing of additional processes

David Rientjes wrote: > Ping? > > This can be something that can easily be removed if it becomes obsoleted > because the oom reaper is always able to free memory to the extent of > exit_mmap(). I argue that it cannot, because it cannot do free_pgtables() > for large amounts of virtual memory,

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Andy The const char array need to be used by the new func mem_cgroup_print_oom_context and some funcs in oom_kill.c in the second patch. Thanks > > On Sat, Jun 30, 2018 at 7:38 PM, wrote: > > From: yuzhoujian > > > > The current system wide oom report prints information about the victim >

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

Hi Andy The const char array need to be used by the new func mem_cgroup_print_oom_context and some funcs in oom_kill.c in the second patch. Thanks > > On Sat, Jun 30, 2018 at 7:38 PM, wrote: > > From: yuzhoujian > > > > The current system wide oom report prints information about the victim >

Re: [PATCH -mm -v4 08/21] mm, THP, swap: Support to read a huge swap cluster for swapin a THP

Daniel Jordan writes: > On Fri, Jun 22, 2018 at 11:51:38AM +0800, Huang, Ying wrote: >> @@ -411,14 +414,32 @@ struct page *__read_swap_cache_async(swp_entry_t >> entry, gfp_t gfp_mask, > ... >> +if (thp_swap_supported() && huge_cluster) { >> +

Re: [PATCH -mm -v4 08/21] mm, THP, swap: Support to read a huge swap cluster for swapin a THP

Daniel Jordan writes: > On Fri, Jun 22, 2018 at 11:51:38AM +0800, Huang, Ying wrote: >> @@ -411,14 +414,32 @@ struct page *__read_swap_cache_async(swp_entry_t >> entry, gfp_t gfp_mask, > ... >> +if (thp_swap_supported() && huge_cluster) { >> +

RE: [PATCH v5 01/12] PM / devfreq: Init user limits from OPP limits, not viceversa

>Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding >the devfreq device") introduced the initialization of the user >limits min/max_freq from the lowest/highest available OPPs. Later >commit f1d981eaecf8 ("PM / devfreq: Use the available min/max >frequency") added

RE: [PATCH v5 01/12] PM / devfreq: Init user limits from OPP limits, not viceversa

>Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding >the devfreq device") introduced the initialization of the user >limits min/max_freq from the lowest/highest available OPPs. Later >commit f1d981eaecf8 ("PM / devfreq: Use the available min/max >frequency") added

Re: [PATCH v5 02/12] PM / devfreq: Fix handling of min/max_freq == 0

Hi Matthias, On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote: > Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the > devfreq device") initializes df->min/max_freq with the min/max OPP when > the device is added. Later commit f1d981eaecf8 ("PM / devfreq: Use the > available

Re: [PATCH v5 02/12] PM / devfreq: Fix handling of min/max_freq == 0

Hi Matthias, On 2018년 07월 04일 08:46, Matthias Kaehlcke wrote: > Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the > devfreq device") initializes df->min/max_freq with the min/max OPP when > the device is added. Later commit f1d981eaecf8 ("PM / devfreq: Use the > available

Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece

Sergey Senozhatsky writes: > On (06/27/18 21:51), Andrew Morton wrote: >> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" >> wrote: >> >> > This is the final step of THP (Transparent Huge Page) swap >> > optimization. After the first and second step, the splitting huge >> > page is delayed

Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece

Sergey Senozhatsky writes: > On (06/27/18 21:51), Andrew Morton wrote: >> On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" >> wrote: >> >> > This is the final step of THP (Transparent Huge Page) swap >> > optimization. After the first and second step, the splitting huge >> > page is delayed

  1   2   3   4   5   6   7   8   9   10   >