Re: [REVIEW][PATCH 09/22] signal/nds32: Use force_sig_fault where appropriate

2018-04-25 23:57 GMT+08:00 Eric W. Biederman : > Vincent Chen writes: > >> 2018-04-20 22:37 GMT+08:00 Eric W. Biederman : >>> Filling in struct siginfo before calling force_sig_info a tedious and >>> error prone process, where

Re: [REVIEW][PATCH 09/22] signal/nds32: Use force_sig_fault where appropriate

2018-04-25 23:57 GMT+08:00 Eric W. Biederman : > Vincent Chen writes: > >> 2018-04-20 22:37 GMT+08:00 Eric W. Biederman : >>> Filling in struct siginfo before calling force_sig_info a tedious and >>> error prone process, where once in a great while the wrong fields >>> are filled out, and siginfo

Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

On 04/25/2018 06:14 PM, Bjorn Andersson wrote: > On Wed 25 Apr 08:18 PDT 2018, Alex Elder wrote: > >> Create function qcom_smem_virt_to_phys(), which returns the physical >> address corresponding to a given SMEM item's virtual address. This >> feature is required for a driver that will soon be

Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

On 04/25/2018 06:14 PM, Bjorn Andersson wrote: > On Wed 25 Apr 08:18 PDT 2018, Alex Elder wrote: > >> Create function qcom_smem_virt_to_phys(), which returns the physical >> address corresponding to a given SMEM item's virtual address. This >> feature is required for a driver that will soon be

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

On Wed, Apr 25, 2018 at 5:43 PM, Eric Dumazet wrote: > syzbot reported a lockdep issue caused by tcp mmap() support. > > I implemented Andy Lutomirski nice suggestions to resolve the > issue and increase scalability as well. > > First patch is adding a new setsockopt()

Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

On Wed, Apr 25, 2018 at 5:43 PM, Eric Dumazet wrote: > syzbot reported a lockdep issue caused by tcp mmap() support. > > I implemented Andy Lutomirski nice suggestions to resolve the > issue and increase scalability as well. > > First patch is adding a new setsockopt() operation and changes

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

On Thu, Apr 19, 2018 at 08:18:46AM +0800, Baoquan He wrote: >The struct resource uses singly linked list to link siblings. It's not >easy to do reverse iteration on sibling list. So replace it with list_head. > Hi, Baoquan Besides changing the data structure, I have another proposal to do the

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

On Thu, Apr 19, 2018 at 08:18:46AM +0800, Baoquan He wrote: >The struct resource uses singly linked list to link siblings. It's not >easy to do reverse iteration on sibling list. So replace it with list_head. > Hi, Baoquan Besides changing the data structure, I have another proposal to do the

Re: [RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

Hi, On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski >

Re: [RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

Hi, On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski > --- >

RE: [PATCH 4/5] cifs: smbd: depend on INFINIBAND_ADDR_TRANS

> Subject: [PATCH 4/5] cifs: smbd: depend on INFINIBAND_ADDR_TRANS > > CIFS_SMB_DIRECT code depends on INFINIBAND_ADDR_TRANS provided > symbols. > So declare the kconfig dependency. This is necessary to allow for enabling > INFINIBAND without INFINIBAND_ADDR_TRANS. > > Signed-off-by: Greg

RE: [PATCH 4/5] cifs: smbd: depend on INFINIBAND_ADDR_TRANS

> Subject: [PATCH 4/5] cifs: smbd: depend on INFINIBAND_ADDR_TRANS > > CIFS_SMB_DIRECT code depends on INFINIBAND_ADDR_TRANS provided > symbols. > So declare the kconfig dependency. This is necessary to allow for enabling > INFINIBAND without INFINIBAND_ADDR_TRANS. > > Signed-off-by: Greg

Re: [PATCH v6 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

On Thu, Apr 19, 2018 at 04:16:35PM -0600, Lina Iyer wrote: > Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated > TCS for active mode request, but drivers may still want to make active > requests from these RSCs. In such cases re-purpose the wake TCS to send > active state

Re: [PATCH v6 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

On Thu, Apr 19, 2018 at 04:16:35PM -0600, Lina Iyer wrote: > Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated > TCS for active mode request, but drivers may still want to make active > requests from these RSCs. In such cases re-purpose the wake TCS to send > active state

linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

Hi all, Today's linux-next merge of the wireless-drivers-next tree got a conflict in: drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c between commit: 77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if needed") from the wireless-drivers tree and commits: 9c4f7d512740 ("iwlwifi:

linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

Hi all, Today's linux-next merge of the wireless-drivers-next tree got a conflict in: drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c between commit: 77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if needed") from the wireless-drivers tree and commits: 9c4f7d512740 ("iwlwifi:

Re: [RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

Hi Krzysztof, On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski

Re: [RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

Hi Krzysztof, On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski > --- >

Re: [RFC 04/10] clk: samsung: Remove support for Exynos5440

Hi Krzysztof, On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski

Re: [RFC 04/10] clk: samsung: Remove support for Exynos5440

Hi Krzysztof, On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski > --- >

linux-next: manual merge of the bpf-next tree with the bpf tree

Hi all, Today's linux-next merge of the bpf-next tree got a conflict in: samples/sockmap/Makefile between commit: 4dfe1bb95235 ("bpf: sockmap sample use clang flag, -target bpf") from the bpf tree and commit: 2e04eb1dd1ca ("bpf: sockmap, remove samples program") from the bpf-next

linux-next: manual merge of the bpf-next tree with the bpf tree

Hi all, Today's linux-next merge of the bpf-next tree got a conflict in: samples/sockmap/Makefile between commit: 4dfe1bb95235 ("bpf: sockmap sample use clang flag, -target bpf") from the bpf tree and commit: 2e04eb1dd1ca ("bpf: sockmap, remove samples program") from the bpf-next

linux-next: manual merge of the bpf-next tree with the net-next tree

Hi all, Today's linux-next merge of the bpf-next tree got a conflict in: tools/testing/selftests/bpf/.gitignore between commit: 0abf854d7cbb ("selftests: bpf: update .gitignore with missing generated files") from the net-next tree and commit: b6fd9cf796e6 ("selftests: bpf: update

linux-next: manual merge of the bpf-next tree with the net-next tree

Hi all, Today's linux-next merge of the bpf-next tree got a conflict in: tools/testing/selftests/bpf/.gitignore between commit: 0abf854d7cbb ("selftests: bpf: update .gitignore with missing generated files") from the net-next tree and commit: b6fd9cf796e6 ("selftests: bpf: update

Re: [PATCH] of: overlay: Stop leaking resources on overlay removal

On 04/25/18 17:32, Frank Rowand wrote: > Hi Jan, > > On 04/24/18 13:58, Frank Rowand wrote: >> On 04/24/18 10:50, Jan Kiszka wrote: >>> On 2018-04-24 19:44, Frank Rowand wrote: On 04/24/18 09:19, Jan Kiszka wrote: > Only the overlay notifier callbacks have a chance to potentially get

Re: [PATCH] of: overlay: Stop leaking resources on overlay removal

On 04/25/18 17:32, Frank Rowand wrote: > Hi Jan, > > On 04/24/18 13:58, Frank Rowand wrote: >> On 04/24/18 10:50, Jan Kiszka wrote: >>> On 2018-04-24 19:44, Frank Rowand wrote: On 04/24/18 09:19, Jan Kiszka wrote: > Only the overlay notifier callbacks have a chance to potentially get

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski wrote: > commit 90841047a01b452cc8c3f9b990698b264143334a upstream > > This linksys dongle by default comes up in cdc_ether mode. > This patch allows r8152 to claim the device: >Bus 002 Device 002: ID 13b1:0041 Linksys > >

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski wrote: > commit 90841047a01b452cc8c3f9b990698b264143334a upstream > > This linksys dongle by default comes up in cdc_ether mode. > This patch allows r8152 to claim the device: >Bus 002 Device 002: ID 13b1:0041 Linksys > > Signed-off-by:

[PATCH][v6] tools/power turbostat: if --iterations, print for specific count of iterations

There's a use case during test to only print specific round of iterations if --iterations is specified, for example, with this patch applied: turbostat -i 5 -r 4 will capture 4 samples with 5 seconds interval. Cc: Len Brown Cc: Rafael J. Wysocki Cc: Artem

[PATCH][v6] tools/power turbostat: if --iterations, print for specific count of iterations

There's a use case during test to only print specific round of iterations if --iterations is specified, for example, with this patch applied: turbostat -i 5 -r 4 will capture 4 samples with 5 seconds interval. Cc: Len Brown Cc: Rafael J. Wysocki Cc: Artem Bityutskiy Cc: Doug Smythies Cc:

Re: [PATCH] of: overlay: Stop leaking resources on overlay removal

Hi Jan, On 04/24/18 13:58, Frank Rowand wrote: > On 04/24/18 10:50, Jan Kiszka wrote: >> On 2018-04-24 19:44, Frank Rowand wrote: >>> On 04/24/18 09:19, Jan Kiszka wrote: Only the overlay notifier callbacks have a chance to potentially get hold of references to those two resources, but

Re: [PATCH] of: overlay: Stop leaking resources on overlay removal

Hi Jan, On 04/24/18 13:58, Frank Rowand wrote: > On 04/24/18 10:50, Jan Kiszka wrote: >> On 2018-04-24 19:44, Frank Rowand wrote: >>> On 04/24/18 09:19, Jan Kiszka wrote: Only the overlay notifier callbacks have a chance to potentially get hold of references to those two resources, but

[PATCH v8 01/13] drivers: base: cacheinfo: move cache_setup_of_node()

In preparation for the next patch, and to aid in review of that patch, lets move cache_setup_of_node further down in the module without any changes. Signed-off-by: Jeremy Linton Reviewed-by: Sudeep Holla --- drivers/base/cacheinfo.c | 80

[PATCH v8 01/13] drivers: base: cacheinfo: move cache_setup_of_node()

In preparation for the next patch, and to aid in review of that patch, lets move cache_setup_of_node further down in the module without any changes. Signed-off-by: Jeremy Linton Reviewed-by: Sudeep Holla --- drivers/base/cacheinfo.c | 80 1 file

[PATCH v8 05/13] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v8 05/13] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v8 06/13] ACPI: Enable PPTT support on ARM64

Now that we have a PPTT parser, in preparation for its use on arm64, lets build it. Signed-off-by: Jeremy Linton Reviewed-by: Sudeep Holla --- arch/arm64/Kconfig| 1 + drivers/acpi/Kconfig | 3 +++ drivers/acpi/Makefile | 1 + 3 files changed,

[PATCH v8 06/13] ACPI: Enable PPTT support on ARM64

Now that we have a PPTT parser, in preparation for its use on arm64, lets build it. Signed-off-by: Jeremy Linton Reviewed-by: Sudeep Holla --- arch/arm64/Kconfig| 1 + drivers/acpi/Kconfig | 3 +++ drivers/acpi/Makefile | 1 + 3 files changed, 5 insertions(+) diff --git

[PATCH v8 04/13] arm64/acpi: Create arch specific cpu to acpi id helper

Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/acpi.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/include/asm/acpi.h

[PATCH v8 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables

Call ACPI cache parsing routines from base cacheinfo code if ACPI is enable. Also stub out cache_setup_acpi() so that individual architectures can enable ACPI topology parsing. Signed-off-by: Jeremy Linton --- drivers/base/cacheinfo.c | 14 ++

[PATCH v8 04/13] arm64/acpi: Create arch specific cpu to acpi id helper

Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/acpi.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/include/asm/acpi.h

[PATCH v8 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables

Call ACPI cache parsing routines from base cacheinfo code if ACPI is enable. Also stub out cache_setup_acpi() so that individual architectures can enable ACPI topology parsing. Signed-off-by: Jeremy Linton --- drivers/base/cacheinfo.c | 14 ++ include/linux/cacheinfo.h | 10

[PATCH v8 08/13] arm64: Add support for ACPI based firmware tables

The /sys cache entries should support ACPI/PPTT generated cache topology information. Lets detect ACPI systems and call an arch specific cache_setup_acpi() routine to update the hardware probed cache topology. For arm64, if ACPI is enabled, determine the max number of cache levels and populate

[PATCH v8 08/13] arm64: Add support for ACPI based firmware tables

The /sys cache entries should support ACPI/PPTT generated cache topology information. Lets detect ACPI systems and call an arch specific cache_setup_acpi() routine to update the hardware probed cache topology. For arm64, if ACPI is enabled, determine the max number of cache levels and populate

[PATCH v8 12/13] ACPI: Add PPTT to injectable table list

Add ACPI_SIG_PPTT to the table so initrd's can override the system topology. Signed-off-by: Geoffrey Blake Signed-off-by: Jeremy Linton --- drivers/acpi/tables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v8 12/13] ACPI: Add PPTT to injectable table list

Add ACPI_SIG_PPTT to the table so initrd's can override the system topology. Signed-off-by: Geoffrey Blake Signed-off-by: Jeremy Linton --- drivers/acpi/tables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index

[PATCH v8 02/13] drivers: base: cacheinfo: setup DT cache properties early

The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the hardware and then cache_shared_cpu_map_setup() and cache_override_properties() would provide firmware help to extend/expand upon what was probed. Arm64 was really the only architecture that

[PATCH v8 10/13] arm64: topology: rename cluster_id

Lets match the name of the arm64 topology field to the kernel macro that uses it. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/topology.h | 4 ++-- arch/arm64/kernel/topology.c | 26 +- 2 files changed, 15 insertions(+), 15

[PATCH v8 02/13] drivers: base: cacheinfo: setup DT cache properties early

The original intent in cacheinfo was that an architecture specific populate_cache_leaves() would probe the hardware and then cache_shared_cpu_map_setup() and cache_override_properties() would provide firmware help to extend/expand upon what was probed. Arm64 was really the only architecture that

[PATCH v8 10/13] arm64: topology: rename cluster_id

Lets match the name of the arm64 topology field to the kernel macro that uses it. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/topology.h | 4 ++-- arch/arm64/kernel/topology.c | 26 +- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git

[PATCH v8 11/13] arm64: topology: enable ACPI/PPTT based CPU topology

Propagate the topology information from the PPTT tree to the cpu_topology array. We can get the thread id and core_id by assuming certain levels of the PPTT tree correspond to those concepts. The package_id is flagged in the tree and can be found by calling find_acpi_cpu_topology_package() which

[PATCH v8 11/13] arm64: topology: enable ACPI/PPTT based CPU topology

Propagate the topology information from the PPTT tree to the cpu_topology array. We can get the thread id and core_id by assuming certain levels of the PPTT tree correspond to those concepts. The package_id is flagged in the tree and can be found by calling find_acpi_cpu_topology_package() which

[PATCH v8 13/13] arm64: topology: divorce MC scheduling domain from core_siblings

Now that we have an accurate view of the physical topology we need to represent it correctly to the scheduler. Generally MC should equal the LLC in the system, but there are a number of special cases that need to be dealt with. In the case of NUMA in socket, we need to assure that the sched

[PATCH v8 09/13] ACPI/PPTT: Add topology parsing code

The PPTT can be used to determine the groupings of CPU's at given levels in the system. Lets add a few routines to the PPTT parsing code to return a unique id for each unique level in the processor hierarchy. This can then be matched to build thread/core/cluster/die/package/etc mappings for each

[PATCH v8 13/13] arm64: topology: divorce MC scheduling domain from core_siblings

Now that we have an accurate view of the physical topology we need to represent it correctly to the scheduler. Generally MC should equal the LLC in the system, but there are a number of special cases that need to be dealt with. In the case of NUMA in socket, we need to assure that the sched

[PATCH v8 09/13] ACPI/PPTT: Add topology parsing code

The PPTT can be used to determine the groupings of CPU's at given levels in the system. Lets add a few routines to the PPTT parsing code to return a unique id for each unique level in the processor hierarchy. This can then be matched to build thread/core/cluster/die/package/etc mappings for each

[PATCH v8 00/13] Support PPTT for ARM64

ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is used to describe the processor and cache topology. Ideally it is used to extend/override information provided by the hardware, but right now ARM64 is entirely dependent on firmware provided tables. This patch parses the table

[PATCH v8 03/13] cacheinfo: rename of_node to fw_token

Rename and change the type of of_node to indicate it is a generic pointer which is generally only used for comparison purposes. In a later patch we will put an ACPI/PPTT token pointer in fw_token so that the code which builds the shared cpu masks can be reused. Signed-off-by: Jeremy Linton

[PATCH v8 00/13] Support PPTT for ARM64

ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is used to describe the processor and cache topology. Ideally it is used to extend/override information provided by the hardware, but right now ARM64 is entirely dependent on firmware provided tables. This patch parses the table

[PATCH v8 03/13] cacheinfo: rename of_node to fw_token

Rename and change the type of of_node to indicate it is a generic pointer which is generally only used for comparison purposes. In a later patch we will put an ACPI/PPTT token pointer in fw_token so that the code which builds the shared cpu masks can be reused. Signed-off-by: Jeremy Linton

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Jan, Alan, On 04/25/18 13:07, Jan Kiszka wrote: > On 2018-04-25 20:40, Frank Rowand wrote: >> On 04/24/18 22:23, Jan Kiszka wrote: >>> On 2018-04-24 22:56, Frank Rowand wrote: Hi Alan, On 04/23/18 15:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Jan, Alan, On 04/25/18 13:07, Jan Kiszka wrote: > On 2018-04-25 20:40, Frank Rowand wrote: >> On 04/24/18 22:23, Jan Kiszka wrote: >>> On 2018-04-24 22:56, Frank Rowand wrote: Hi Alan, On 04/23/18 15:38, Frank Rowand wrote: > Hi Jan, > > + Alan Tull for fpga

[tip:x86/urgent 4/6] arch/x86/kernel/cpu/intel.c:839:31: error: expected '}' before string constant

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent head: 5a626a8dfb58a64a39f4351e3962e7320191f189 commit: 88ba3829dfd83219bb2b1954acb0c206a602ce83 [4/6] x86/cpu/intel: Add missing TLB cpuid values config: i386-tinyconfig (attached as .config) compiler: gcc-7 (Debian

[tip:x86/urgent 4/6] arch/x86/kernel/cpu/intel.c:839:31: error: expected '}' before string constant

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent head: 5a626a8dfb58a64a39f4351e3962e7320191f189 commit: 88ba3829dfd83219bb2b1954acb0c206a602ce83 [4/6] x86/cpu/intel: Add missing TLB cpuid values config: i386-tinyconfig (attached as .config) compiler: gcc-7 (Debian

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/25/18 17:07, Frank Rowand wrote: > Hi Alan, > > On 04/25/18 11:19, Alan Tull wrote: >> On Wed, Apr 25, 2018 at 12:41 PM, Frank Rowand >> wrote: >>> On 04/25/18 07:59, Alan Tull wrote: On Tue, Apr 24, 2018 at 3:56 PM, Frank Rowand

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/25/18 17:07, Frank Rowand wrote: > Hi Alan, > > On 04/25/18 11:19, Alan Tull wrote: >> On Wed, Apr 25, 2018 at 12:41 PM, Frank Rowand >> wrote: >>> On 04/25/18 07:59, Alan Tull wrote: On Tue, Apr 24, 2018 at 3:56 PM, Frank Rowand wrote: > Hi Alan, > > On 04/23/18

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Alan, On 04/25/18 11:19, Alan Tull wrote: > On Wed, Apr 25, 2018 at 12:41 PM, Frank Rowand wrote: >> On 04/25/18 07:59, Alan Tull wrote: >>> On Tue, Apr 24, 2018 at 3:56 PM, Frank Rowand >>> wrote: Hi Alan, On 04/23/18 15:38,

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

Hi Alan, On 04/25/18 11:19, Alan Tull wrote: > On Wed, Apr 25, 2018 at 12:41 PM, Frank Rowand wrote: >> On 04/25/18 07:59, Alan Tull wrote: >>> On Tue, Apr 24, 2018 at 3:56 PM, Frank Rowand >>> wrote: Hi Alan, On 04/23/18 15:38, Frank Rowand wrote: > Hi Jan, > > +

Re: [PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

On Mon, Apr 23, 2018 at 10:48:39AM +0200, Rafael J. Wysocki wrote: > On Saturday, April 14, 2018 6:10:55 AM CEST Yu Chen wrote: > > From: Chen Yu > > > > There's a use case during test to only print specific round of iterations > > if --iterations is specified, for example,

Re: [PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

On Mon, Apr 23, 2018 at 10:48:39AM +0200, Rafael J. Wysocki wrote: > On Saturday, April 14, 2018 6:10:55 AM CEST Yu Chen wrote: > > From: Chen Yu > > > > There's a use case during test to only print specific round of iterations > > if --iterations is specified, for example, with this patch

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/25/2018 01:17 PM, Oleg Nesterov wrote: >> On 04/25, Andrey Grodzovsky wrote: >>> here (drm_sched_entity_fini) is also a bad idea, but we still want to be >>> able to exit immediately >>> and not wait for GPU jobs completion when the

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/25/2018 01:17 PM, Oleg Nesterov wrote: >> On 04/25, Andrey Grodzovsky wrote: >>> here (drm_sched_entity_fini) is also a bad idea, but we still want to be >>> able to exit immediately >>> and not wait for GPU jobs completion when the reason for reaching this code

Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc2 next-20180424] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

[PATCH] trace: initcall: Ordered comparison of function pointers

Using initcall_t in the __field macro generates the follwing warning with clang version 6.0: include/trace/events/initcall.h:34:3: warning: ordered comparison of function pointers ('initcall_t' (aka 'int (*)(void)') and 'initcall_t') __field macro expands to __field_ext macro which does

[PATCH] trace: initcall: Ordered comparison of function pointers

Using initcall_t in the __field macro generates the follwing warning with clang version 6.0: include/trace/events/initcall.h:34:3: warning: ordered comparison of function pointers ('initcall_t' (aka 'int (*)(void)') and 'initcall_t') __field macro expands to __field_ext macro which does

Re: [PATCH v6 09/10] drivers: qcom: rpmh: add support for batch RPMH request

On Thu, Apr 19, 2018 at 04:16:34PM -0600, Lina Iyer wrote: > Platform drivers need make a lot of resource state requests at the same > time, say, at the start or end of an usecase. It can be quite > inefficient to send each request separately. Instead they can give the > RPMH library a batch of

Re: [PATCH v6 09/10] drivers: qcom: rpmh: add support for batch RPMH request

On Thu, Apr 19, 2018 at 04:16:34PM -0600, Lina Iyer wrote: > Platform drivers need make a lot of resource state requests at the same > time, say, at the start or end of an usecase. It can be quite > inefficient to send each request separately. Instead they can give the > RPMH library a batch of

[PATCH] PM / Sleep: only update last time for active wakeup sources

When wakelock support was added, the wakeup_source_add() function was updated to set the last_time value of the wakeup source. This has the unintended side effect of producing confusing output from pm_print_active_wakeup_sources() when a wakeup source is added prior to a sleep that is blocked by a

[PATCH] PM / Sleep: only update last time for active wakeup sources

When wakelock support was added, the wakeup_source_add() function was updated to set the last_time value of the wakeup source. This has the unintended side effect of producing confusing output from pm_print_active_wakeup_sources() when a wakeup source is added prior to a sleep that is blocked by a

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

Adding few other folks. Thanks Rohit From: Rohit Khanna Sent: Wednesday, April 25, 2018 4:08 PM To: catalin.mari...@arm.com; will.dea...@arm.com Cc: linux-kernel@vger.kernel.org; Rohit Khanna Subject: [PATCH] arm64: skip cpu nodes marked as disabled in DT

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

Adding few other folks. Thanks Rohit From: Rohit Khanna Sent: Wednesday, April 25, 2018 4:08 PM To: catalin.mari...@arm.com; will.dea...@arm.com Cc: linux-kernel@vger.kernel.org; Rohit Khanna Subject: [PATCH] arm64: skip cpu nodes marked as disabled in DT

Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

Hi Alex, Minor comment. On 4/25/2018 8:18 AM, Alex Elder wrote: Create function qcom_smem_virt_to_phys(), which returns the physical address corresponding to a given SMEM item's virtual address. This feature is required for a driver that will soon be out for review. Signed-off-by: Alex Elder

Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

Hi Alex, Minor comment. On 4/25/2018 8:18 AM, Alex Elder wrote: Create function qcom_smem_virt_to_phys(), which returns the physical address corresponding to a given SMEM item's virtual address. This feature is required for a driver that will soon be out for review. Signed-off-by: Alex Elder

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > On arm that doesn't work. The iommu api seems like a good fit, except > the dma-api tends to get in the way a bit (drm/msm apparently has > similar problems like tegra), and if you need contiguous memory > dma_alloc_coherent is the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > On arm that doesn't work. The iommu api seems like a good fit, except > the dma-api tends to get in the way a bit (drm/msm apparently has > similar problems like tegra), and if you need contiguous memory > dma_alloc_coherent is the

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > On Wed, 18 Apr 2018, Christopher Lameter wrote: > > > On Tue, 17 Apr 2018, Mikulas Patocka wrote: > > > > > I can make a slub-only patch with no extra flag (on a freshly booted > > > system it increases only the order of caches "TCPv6" and

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > On Wed, 18 Apr 2018, Christopher Lameter wrote: > > > On Tue, 17 Apr 2018, Mikulas Patocka wrote: > > > > > I can make a slub-only patch with no extra flag (on a freshly booted > > > system it increases only the order of caches "TCPv6" and

linux-next: build failure after merge of the clk-samsung tree

Hi Sylwester, After merging the clk-samsung tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from arch/arm/boot/dts/exynos5440-sd5v1.dts:10:0: arch/arm/boot/dts/exynos5440.dtsi:9:10: fatal error: dt-bindings/clock/exynos5440.h: No such file or directory

linux-next: build failure after merge of the clk-samsung tree

Hi Sylwester, After merging the clk-samsung tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from arch/arm/boot/dts/exynos5440-sd5v1.dts:10:0: arch/arm/boot/dts/exynos5440.dtsi:9:10: fatal error: dt-bindings/clock/exynos5440.h: No such file or directory

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

Hi Anusha, Can I ask if this is on anyone's radar as I'm concerned this patch will stall otherwise? I see that the significance of testing with the 4.14 kernel enabled the firmware to be included in the latest Chrome OS kernel (

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

Hi Anusha, Can I ask if this is on anyone's radar as I'm concerned this patch will stall otherwise? I see that the significance of testing with the 4.14 kernel enabled the firmware to be included in the latest Chrome OS kernel (

Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

On Wed 25 Apr 08:18 PDT 2018, Alex Elder wrote: > Create function qcom_smem_virt_to_phys(), which returns the physical > address corresponding to a given SMEM item's virtual address. This > feature is required for a driver that will soon be out for review. > It might be wise to turn the

Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

On Wed 25 Apr 08:18 PDT 2018, Alex Elder wrote: > Create function qcom_smem_virt_to_phys(), which returns the physical > address corresponding to a given SMEM item's virtual address. This > feature is required for a driver that will soon be out for review. > It might be wise to turn the

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

Hi Mathieu, On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers wrote: > - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote: > >> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney >> wrote: >> [..] > >

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

Hi Mathieu, On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers wrote: > - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote: > >> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney >> wrote: >> [..] > > Sounds good, thanks. > > Also I found the reason

#pragma once

Following up with negative LOC trend... 16171 files changed, 16197 insertions(+), 87671 deletions(-) Not all files can be blindly converted as some headers check for master header include guard (spinlock.h et al). include/uapi/ can be skipped probably out of fear of finding a C compiler

#pragma once

Following up with negative LOC trend... 16171 files changed, 16197 insertions(+), 87671 deletions(-) Not all files can be blindly converted as some headers check for master header include guard (spinlock.h et al). include/uapi/ can be skipped probably out of fear of finding a C compiler

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote: > > On Wed, 25 Apr 2018, James Bottomley wrote: > > > > > Do we really need the new config option?  This could just be > > > > manually  tunable via fault injection IIUC. > > >  > > > We do, because we want to enable it in RHEL and Fedora

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 2018-04-25 at 19:00 -0400, Mikulas Patocka wrote: > > On Wed, 25 Apr 2018, James Bottomley wrote: > > > > > Do we really need the new config option?  This could just be > > > > manually  tunable via fault injection IIUC. > > >  > > > We do, because we want to enable it in RHEL and Fedora

<    1   2   3   4   5   6   7   8   9   10   >