Re: [PATCH v3 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

Hi Heiko, On 19/04/17 10:02, Heiko Stuebner wrote: Am Mittwoch, 19. April 2017, 09:06:17 CEST schrieb Guillaume Tucker: diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt new file mode 100644 index

Re: [PATCH v3 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

Hi Heiko, On 19/04/17 10:02, Heiko Stuebner wrote: Am Mittwoch, 19. April 2017, 09:06:17 CEST schrieb Guillaume Tucker: diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt new file mode 100644 index

[PATCH V4 2/7] ARM: TI: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH 01/11] blk: remove bio_set arg from blk_queue_split()

blk_queue_split() is always called with the last arg being q->bio_split, where 'q' is the first arg. Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses q->bio_split. This is inconsistent and unnecessary. Remove the last arg and always use q->bio_split inside

[PATCH V4 2/7] ARM: TI: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

[PATCH 01/11] blk: remove bio_set arg from blk_queue_split()

blk_queue_split() is always called with the last arg being q->bio_split, where 'q' is the first arg. Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses q->bio_split. This is inconsistent and unnecessary. Remove the last arg and always use q->bio_split inside

[PATCH 02/11] blk: make the bioset rescue_workqueue optional.

This patch converts bioset_create() and bioset_create_nobvec() to not create a workqueue so alloctions will never trigger punt_bios_to_rescuer(). It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued() which preserve the old behaviour. All callers of bioset_create() and

[PATCH 02/11] blk: make the bioset rescue_workqueue optional.

This patch converts bioset_create() and bioset_create_nobvec() to not create a workqueue so alloctions will never trigger punt_bios_to_rescuer(). It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued() which preserve the old behaviour. All callers of bioset_create() and

[PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

[PATCH V4 3/7] ARM: exynos: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH V4 3/7] ARM: exynos: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

Re: [PATCH v3] axon_ram: add dax_operations support

Hi Dan, [auto build test WARNING on powerpc/next] [also build test WARNING on v4.11-rc7 next-20170419] [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/Dan-Williams/axon_ram-add-dax_operations

Re: [PATCH v3] axon_ram: add dax_operations support

Hi Dan, [auto build test WARNING on powerpc/next] [also build test WARNING on v4.11-rc7 next-20170419] [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/Dan-Williams/axon_ram-add-dax_operations

[PATCH 04/11] block: Improvements to bounce-buffer handling

Since commit 23688bf4f830 ("block: ensure to split after potentially bouncing a bio") blk_queue_bounce() is called *before* blk_queue_split(). This means that: 1/ the comments blk_queue_split() about bounce buffers are irrelevant, and 2/ a very large bio (more than BIO_MAX_PAGES) will no

[PATCH V4 6/7] ARM: uniphier: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH 04/11] block: Improvements to bounce-buffer handling

Since commit 23688bf4f830 ("block: ensure to split after potentially bouncing a bio") blk_queue_bounce() is called *before* blk_queue_split(). This means that: 1/ the comments blk_queue_split() about bounce buffers are irrelevant, and 2/ a very large bio (more than BIO_MAX_PAGES) will no

[PATCH V4 6/7] ARM: uniphier: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

[PATCH 07/11] pktcdvd: use bio_clone_fast() instead of bio_clone()

pktcdvd doesn't change the bi_io_vec of the clone bio, so it is more efficient to use bio_clone_fast(), and not clone the bi_io_vec. This requires providing a bio_set, and it is safest to provide a dedicated bio_set rather than sharing fs_bio_set, which filesytems use. This new bio_set,

[PATCH 07/11] pktcdvd: use bio_clone_fast() instead of bio_clone()

pktcdvd doesn't change the bi_io_vec of the clone bio, so it is more efficient to use bio_clone_fast(), and not clone the bi_io_vec. This requires providing a bio_set, and it is safest to provide a dedicated bio_set rather than sharing fs_bio_set, which filesytems use. This new bio_set,

[PATCH 03/11] blk: use non-rescuing bioset for q->bio_split.

A rescuing bioset is only useful if there might be bios from that same bioset on the bio_list_on_stack queue at a time when bio_alloc_bioset() is called. This never applies to q->bio_split. Allocations from q->bio_split are only ever made from blk_queue_split() which is only ever called early in

[PATCH 03/11] blk: use non-rescuing bioset for q->bio_split.

A rescuing bioset is only useful if there might be bios from that same bioset on the bio_list_on_stack queue at a time when bio_alloc_bioset() is called. This never applies to q->bio_split. Allocations from q->bio_split are only ever made from blk_queue_split() which is only ever called early in

[PATCH V4 4/7] ARM: pxa: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH V4 4/7] ARM: pxa: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

[PATCH 11/11] block: don't check for BIO_MAX_PAGES in blk_bio_segment_split()

blk_bio_segment_split() makes sure bios have no more than BIO_MAX_PAGES entries in the bi_io_vec. This was done because bio_clone_bioset() (when given a mempool bioset) could not handle larger io_vecs. No driver uses bio_clone_bioset() any more, they all use bio_clone_fast() if anything, and

[PATCH 10/11] block: remove bio_clone() and all references.

bio_clone() is no longer used. Only bio_clone_bioset() or bio_clone_fast(). This is for the best, as bio_clone() used fs_bio_set, and filesystems are unlikely to want to use bio_clone(). So remove bio_clone() and all references. This includes a fix to some incorrect documentation. Signed-off-by:

[PATCH 05/11] rbd: use bio_clone_fast() instead of bio_clone()

bio_clone() makes a copy of the bi_io_vec, but rbd never changes that, so there is no need for a copy. bio_clone_fast() can be used instead, which avoids making the copy. This requires that we provide a bio_set. bio_clone() uses fs_bio_set, but it isn't, in general, safe to use the same bio_set

[PATCH 11/11] block: don't check for BIO_MAX_PAGES in blk_bio_segment_split()

blk_bio_segment_split() makes sure bios have no more than BIO_MAX_PAGES entries in the bi_io_vec. This was done because bio_clone_bioset() (when given a mempool bioset) could not handle larger io_vecs. No driver uses bio_clone_bioset() any more, they all use bio_clone_fast() if anything, and

[PATCH 10/11] block: remove bio_clone() and all references.

bio_clone() is no longer used. Only bio_clone_bioset() or bio_clone_fast(). This is for the best, as bio_clone() used fs_bio_set, and filesystems are unlikely to want to use bio_clone(). So remove bio_clone() and all references. This includes a fix to some incorrect documentation. Signed-off-by:

[PATCH 05/11] rbd: use bio_clone_fast() instead of bio_clone()

bio_clone() makes a copy of the bi_io_vec, but rbd never changes that, so there is no need for a copy. bio_clone_fast() can be used instead, which avoids making the copy. This requires that we provide a bio_set. bio_clone() uses fs_bio_set, but it isn't, in general, safe to use the same bio_set

[PATCH 09/11] bcache: use kmalloc to allocate bio in bch_data_verify()

This function allocates a bio, then a collection of pages. It copes with failure. It currently uses a mempool() to allocate the bio, but alloc_page() to allocate the pages. These fail in different ways, so the usage is inconsistent. Change the bio_clone() to bio_clone_kmalloc() so that no pool

[PATCH V4 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH 09/11] bcache: use kmalloc to allocate bio in bch_data_verify()

This function allocates a bio, then a collection of pages. It copes with failure. It currently uses a mempool() to allocate the bio, but alloc_page() to allocate the pages. These fail in different ways, so the usage is inconsistent. Change the bio_clone() to bio_clone_kmalloc() so that no pool

[PATCH V4 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

[PATCH 06/11] drbd: use bio_clone_fast() instead of bio_clone()

drbd does not modify the bi_io_vec of the cloned bio, so there is no need to clone that part. So bio_clone_fast() is the better choice. For bio_clone_fast() we need to specify a bio_set. We could use fs_bio_set, which bio_clone() uses, or drbd_md_io_bio_set, which drbd uses for metadata, but it

[PATCH 06/11] drbd: use bio_clone_fast() instead of bio_clone()

drbd does not modify the bi_io_vec of the cloned bio, so there is no need to clone that part. So bio_clone_fast() is the better choice. For bio_clone_fast() we need to specify a bio_set. We could use fs_bio_set, which bio_clone() uses, or drbd_md_io_bio_set, which drbd uses for metadata, but it

[PATCH V4 1/7] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

Re: [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288

Hi Heiko, On 19/04/17 09:59, Heiko Stuebner wrote: Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker: Add Mali GPU device tree node for the rk3288 SoC, with devfreq opp table. Tested-by: Enric Balletbo i Serra Signed-off-by: Guillaume Tucker

[PATCH V4 1/7] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

Re: [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288

Hi Heiko, On 19/04/17 09:59, Heiko Stuebner wrote: Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker: Add Mali GPU device tree node for the rk3288 SoC, with devfreq opp table. Tested-by: Enric Balletbo i Serra Signed-off-by: Guillaume Tucker ---

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

Hi Paul, [Also reported by Michael elsewhere] After merging the rcu tree, today's linux-next build (powerpc pseries_le_defconfig) failed like this: arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages: arch/powerpc/kvm/book3s_hv_rmhandlers.S:587: Error: operand out of range

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

Hi Paul, [Also reported by Michael elsewhere] After merging the rcu tree, today's linux-next build (powerpc pseries_le_defconfig) failed like this: arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages: arch/powerpc/kvm/book3s_hv_rmhandlers.S:587: Error: operand out of range

[GIT PULL] Bugfixes for the Keys subsystem

Please pull these patches for the Keys subsystem, which fix: - CVE-2017-7472 - CVE-2017-6951 - CVE-2016-9604 The following changes since commit f61143c45077df4fa78e2f1ba455a00bbe1d5b8c: Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux (2017-04-19

[GIT PULL] Bugfixes for the Keys subsystem

Please pull these patches for the Keys subsystem, which fix: - CVE-2017-7472 - CVE-2017-6951 - CVE-2016-9604 The following changes since commit f61143c45077df4fa78e2f1ba455a00bbe1d5b8c: Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux (2017-04-19

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 19-04-17, 14:58, Sudeep Holla wrote: > On 19/04/17 12:47, Viresh Kumar wrote: > > On 18-04-17, 17:01, Sudeep Holla wrote: > >> Understood. I would incline towards reusing regulators we that's what is > > > > It can be just a regulator, but it can be anything else as well. That > > entity may

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 19-04-17, 14:58, Sudeep Holla wrote: > On 19/04/17 12:47, Viresh Kumar wrote: > > On 18-04-17, 17:01, Sudeep Holla wrote: > >> Understood. I would incline towards reusing regulators we that's what is > > > > It can be just a regulator, but it can be anything else as well. That > > entity may

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/2017 07:33 PM, Steven Rostedt wrote: > On Wed, 19 Apr 2017 16:27:10 -0700 > Tyrel Datwyler wrote: > >> # echo stacktrace > /sys/kernel/debug/tracing/trace_options >> # cat trace | grep -A6 "/pci@8002018" > > Just to let you know that there is now

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/2017 07:33 PM, Steven Rostedt wrote: > On Wed, 19 Apr 2017 16:27:10 -0700 > Tyrel Datwyler wrote: > >> # echo stacktrace > /sys/kernel/debug/tracing/trace_options >> # cat trace | grep -A6 "/pci@8002018" > > Just to let you know that there is now stacktrace event triggers,

Re: [PATCH 0/5] nvme APST fixes/improvements for 4.11

On Wed, Apr 19, 2017 at 09:52:17PM -0700, Andy Lutomirski wrote: > > I can make it so that force_apst=0 means no APST and force_apst=1 mean > > yes APST and we could try again with a quirk list for 4.12. There's a > > decent chance that a few more weeks with Ubuntu having APST on will > > shake

Re: [PATCH 0/5] nvme APST fixes/improvements for 4.11

On Wed, Apr 19, 2017 at 09:52:17PM -0700, Andy Lutomirski wrote: > > I can make it so that force_apst=0 means no APST and force_apst=1 mean > > yes APST and we could try again with a quirk list for 4.12. There's a > > decent chance that a few more weeks with Ubuntu having APST on will > > shake

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/17 21:43, Frank Rowand wrote: > On 04/19/17 16:27, Tyrel Datwyler wrote: >> On 04/18/2017 06:31 PM, Michael Ellerman wrote: < snip > >> >> To get that same info as far as I know is to add a dump_stack() after >> each pr_debug. > > Here is a patch that I have used. It is not as user

[PATCH] arm: Documentation: update a path name

the path in the example cmd is out of date, and the path for now is also mentioned in the same file Signed-off-by: Perr Zhang --- Documentation/arm/mem_alignment | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/arm/mem_alignment

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/17 21:43, Frank Rowand wrote: > On 04/19/17 16:27, Tyrel Datwyler wrote: >> On 04/18/2017 06:31 PM, Michael Ellerman wrote: < snip > >> >> To get that same info as far as I know is to add a dump_stack() after >> each pr_debug. > > Here is a patch that I have used. It is not as user

[PATCH] arm: Documentation: update a path name

the path in the example cmd is out of date, and the path for now is also mentioned in the same file Signed-off-by: Perr Zhang --- Documentation/arm/mem_alignment | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/arm/mem_alignment b/Documentation/arm/mem_alignment

[PATCH] arm: alignment: update comments on /proc/cpu/alignment

The path name in the comment is out of date, update it. Signed-off-by: Perr Zhang --- arch/arm/mm/alignment.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c index 2c96190..db9c2cf 100644

[PATCH] arm: alignment: update comments on /proc/cpu/alignment

The path name in the comment is out of date, update it. Signed-off-by: Perr Zhang --- arch/arm/mm/alignment.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c index 2c96190..db9c2cf 100644 ---

Re: [PATCH] fs:orangefs:orangefs-debug.h: Use ARRAY_SIZE kernel macro

Hi Karim, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170419] [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/Karim-Eshapa/fs-orangefs-orangefs-debug-h-Use

Re: [PATCH] fs:orangefs:orangefs-debug.h: Use ARRAY_SIZE kernel macro

Hi Karim, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170419] [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/Karim-Eshapa/fs-orangefs-orangefs-debug-h-Use

Re: [RFC] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

On 04/19/2017 12:12 PM, Anshuman Khandual wrote: > On 04/19/2017 11:50 AM, Aneesh Kumar K.V wrote: >> Anshuman Khandual writes: >> >>> Though migrating gigantic HugeTLB pages does not sound much like real >>> world use case, they can be affected by memory errors.

Re: [RFC] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

On 04/19/2017 12:12 PM, Anshuman Khandual wrote: > On 04/19/2017 11:50 AM, Aneesh Kumar K.V wrote: >> Anshuman Khandual writes: >> >>> Though migrating gigantic HugeTLB pages does not sound much like real >>> world use case, they can be affected by memory errors. Hence migration >>> at the PGD

Re: [PATCH 0/5] nvme APST fixes/improvements for 4.11

On Wed, Apr 19, 2017 at 8:55 PM, Andy Lutomirski wrote: > On Wed, Apr 19, 2017 at 8:10 PM, Jens Axboe wrote: >> On Wed, Apr 19 2017, Andy Lutomirski wrote: >>> Sorry for waiting so long for this. I was waiting for feedback from >>> Samsung, but they haven't

Re: [PATCH 0/5] nvme APST fixes/improvements for 4.11

On Wed, Apr 19, 2017 at 8:55 PM, Andy Lutomirski wrote: > On Wed, Apr 19, 2017 at 8:10 PM, Jens Axboe wrote: >> On Wed, Apr 19 2017, Andy Lutomirski wrote: >>> Sorry for waiting so long for this. I was waiting for feedback from >>> Samsung, but they haven't root-caused the issue yet, and I

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/17 19:33, Steven Rostedt wrote: > On Wed, 19 Apr 2017 16:27:10 -0700 > Tyrel Datwyler wrote: > >> # echo stacktrace > /sys/kernel/debug/tracing/trace_options >> # cat trace | grep -A6 "/pci@8002018" > > Just to let you know that there is now

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/17 19:33, Steven Rostedt wrote: > On Wed, 19 Apr 2017 16:27:10 -0700 > Tyrel Datwyler wrote: > >> # echo stacktrace > /sys/kernel/debug/tracing/trace_options >> # cat trace | grep -A6 "/pci@8002018" > > Just to let you know that there is now stacktrace event triggers, where >

[PATCH V5 7/9] PM / domain: Register for PM QOS performance notifier

Some platforms have the capability to configure the performance state of their Power Domains. The performance levels are identified by positive integer values, a lower value represents lower performance state. The power domain driver should be able to retrieve all information required to configure

[PATCH V5 7/9] PM / domain: Register for PM QOS performance notifier

Some platforms have the capability to configure the performance state of their Power Domains. The performance levels are identified by positive integer values, a lower value represents lower performance state. The power domain driver should be able to retrieve all information required to configure

[PATCH V5 4/9] PM / QOS: Add DEV_PM_QOS_PERFORMANCE request

Some platforms have the capability to configure the performance state of their Power Domains. The performance levels are identified by positive integer values, a lower value represents lower performance state. The power domain driver should be able to retrieve all information required to configure

[PATCH V5 4/9] PM / QOS: Add DEV_PM_QOS_PERFORMANCE request

Some platforms have the capability to configure the performance state of their Power Domains. The performance levels are identified by positive integer values, a lower value represents lower performance state. The power domain driver should be able to retrieve all information required to configure

[PATCH V5 3/9] PM / QOS: Keep common notifier list for genpd constraints

Only the resume_latency constraint uses the notifiers right now. In order to prepare for adding new constraint types with notifiers, move to a common notifier list. Update pm_qos_update_target() to pass a pointer to the constraint structure to the notifier callbacks. Also update the notifier

[PATCH V5 3/9] PM / QOS: Keep common notifier list for genpd constraints

Only the resume_latency constraint uses the notifiers right now. In order to prepare for adding new constraint types with notifiers, move to a common notifier list. Update pm_qos_update_target() to pass a pointer to the constraint structure to the notifier callbacks. Also update the notifier

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On 04/19/2017 07:53 PM, Serge E. Hallyn wrote: Quoting Matt Brown (m...@nmatt.com): On 04/19/2017 12:58 AM, Serge E. Hallyn wrote: On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity project in-kernel. This

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On 04/19/2017 07:53 PM, Serge E. Hallyn wrote: Quoting Matt Brown (m...@nmatt.com): On 04/19/2017 12:58 AM, Serge E. Hallyn wrote: On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity project in-kernel. This

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/17 16:27, Tyrel Datwyler wrote: > On 04/18/2017 06:31 PM, Michael Ellerman wrote: >> Frank Rowand writes: >> >>> On 04/17/17 17:32, Tyrel Datwyler wrote: This patch introduces event tracepoints for tracking a device_nodes reference cycle as well as

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/17 16:27, Tyrel Datwyler wrote: > On 04/18/2017 06:31 PM, Michael Ellerman wrote: >> Frank Rowand writes: >> >>> On 04/17/17 17:32, Tyrel Datwyler wrote: This patch introduces event tracepoints for tracking a device_nodes reference cycle as well as reconfig notifications

RE: [PATCH 4/5] nvme: Adjust the Samsung APST quirk

[Jens] Do we know for a fact that it only happens on those systems, and isn't > purely specific to the device? [Andy] I have decent evidence. All of the reports are from XPS 15 9550 or Precision 5510, and Dell confirmed that they're basically the same machine and run literally the same BIOS.

RE: [PATCH 4/5] nvme: Adjust the Samsung APST quirk

[Jens] Do we know for a fact that it only happens on those systems, and isn't > purely specific to the device? [Andy] I have decent evidence. All of the reports are from XPS 15 9550 or Precision 5510, and Dell confirmed that they're basically the same machine and run literally the same BIOS.

Re: [PATCH net-next] brcmfmac: fix build without CONFIG_BRCMFMAC_PROTO_BCDC

Arnd Bergmann writes: > With CONFIG_BRCMFMAC_PROTO_BCDC unset, we cannot build the fwsignal.c file: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c: In function > 'brcmf_fws_notify_credit_map': > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c:1590:31:

Re: [PATCH net-next] brcmfmac: fix build without CONFIG_BRCMFMAC_PROTO_BCDC

Arnd Bergmann writes: > With CONFIG_BRCMFMAC_PROTO_BCDC unset, we cannot build the fwsignal.c file: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c: In function > 'brcmf_fws_notify_credit_map': > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c:1590:31: error: >

Re: [PATCH V4 4/9] PM / QOS: Add DEV_PM_QOS_PERFORMANCE request

On 19-04-17, 16:07, Ulf Hansson wrote: > On 20 March 2017 at 10:32, Viresh Kumar wrote: > > @@ -571,6 +589,9 @@ static void __dev_pm_qos_drop_user_request(struct > > device *dev, > > req = dev->power.qos->flags_req; > >

Re: [PATCH V4 4/9] PM / QOS: Add DEV_PM_QOS_PERFORMANCE request

On 19-04-17, 16:07, Ulf Hansson wrote: > On 20 March 2017 at 10:32, Viresh Kumar wrote: > > @@ -571,6 +589,9 @@ static void __dev_pm_qos_drop_user_request(struct > > device *dev, > > req = dev->power.qos->flags_req; > > dev->power.qos->flags_req = NULL; > >

Re: [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed

On Mon, Apr 17, 2017 at 5:27 PM, wrote: > From: Sunil Goutham > > For software initiated address translation, when domain type is > IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior > i.e return the same IOVA as translated address. > >

Re: [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed

On Mon, Apr 17, 2017 at 5:27 PM, wrote: > From: Sunil Goutham > > For software initiated address translation, when domain type is > IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior > i.e return the same IOVA as translated address. > > This patch is an extension to Will Deacon's

Re: [PATCH v2] soc: brcmstb: enable drivers for ARM64 and BMIPS

Hi Markus, On Wed, Apr 19, 2017 at 03:50:40PM -0700, Markus Mayer wrote: > From: Markus Mayer > > We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and > BMIPS. > > Signed-off-by: Markus Mayer > --- > > I used (COMPILE_TEST & OF) as

Re: [PATCH v2] soc: brcmstb: enable drivers for ARM64 and BMIPS

Hi Markus, On Wed, Apr 19, 2017 at 03:50:40PM -0700, Markus Mayer wrote: > From: Markus Mayer > > We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and > BMIPS. > > Signed-off-by: Markus Mayer > --- > > I used (COMPILE_TEST & OF) as condition like Raspberry Pi, since we >

[PATCH v6 5/7] perf util: Create branch.c/.h for common branch functions

Create new util/branch.c and util/branch.h to contain the common branch functions. Such as: branch_type_count(): Count the numbers of branch types branch_type_name() : Return the name of branch type branch_type_stat_display(): Display branch type statistics info branch_type_str(): Construct the

[PATCH v6 4/7] perf report: Refactor the branch info printing code

The branch info such as predicted/cycles/... are printed at the callchain entries. For example: perf report --branch-history --no-children --stdio --1.07%--main div.c:39 (predicted:52.4% cycles:1 iterations:17) main div.c:44 (predicted:52.4% cycles:1) main

[PATCH v6 5/7] perf util: Create branch.c/.h for common branch functions

Create new util/branch.c and util/branch.h to contain the common branch functions. Such as: branch_type_count(): Count the numbers of branch types branch_type_name() : Return the name of branch type branch_type_stat_display(): Display branch type statistics info branch_type_str(): Construct the

[PATCH v6 4/7] perf report: Refactor the branch info printing code

The branch info such as predicted/cycles/... are printed at the callchain entries. For example: perf report --branch-history --no-children --stdio --1.07%--main div.c:39 (predicted:52.4% cycles:1 iterations:17) main div.c:44 (predicted:52.4% cycles:1) main

[PATCH v6 6/7] perf report: Show branch type statistics for stdio mode

Show the branch type statistics at the end of perf report --stdio. For example: perf report --stdio JCC forward: 27.6% JCC backward: 10.0% CROSS_4K: 0.0% CROSS_2M: 14.3% JCC: 37.6% JMP: 0.0% IND_JMP: 6.5% CALL: 26.6% IND_CALL: 0.0%

[PATCH v6 1/7] perf/core: Define the common branch type classification

It is often useful to know the branch types while analyzing branch data. For example, a call is very different from a conditional branch. Currently we have to look it up in binary while the binary may later not be available and even the binary is available but user has to take some time. It is

[PATCH v6 3/7] perf record: Create a new option save_type in --branch-filter

The option indicates the kernel to save branch type during sampling. One example: perf record -g --branch-filter any,save_type Change log -- v6: Not changed. v5: Not changed. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-record.txt | 1 +

[PATCH v6 6/7] perf report: Show branch type statistics for stdio mode

Show the branch type statistics at the end of perf report --stdio. For example: perf report --stdio JCC forward: 27.6% JCC backward: 10.0% CROSS_4K: 0.0% CROSS_2M: 14.3% JCC: 37.6% JMP: 0.0% IND_JMP: 6.5% CALL: 26.6% IND_CALL: 0.0%

[PATCH v6 1/7] perf/core: Define the common branch type classification

It is often useful to know the branch types while analyzing branch data. For example, a call is very different from a conditional branch. Currently we have to look it up in binary while the binary may later not be available and even the binary is available but user has to take some time. It is

[PATCH v6 3/7] perf record: Create a new option save_type in --branch-filter

The option indicates the kernel to save branch type during sampling. One example: perf record -g --branch-filter any,save_type Change log -- v6: Not changed. v5: Not changed. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-record.txt | 1 +

[PATCH v6 7/7] perf report: Show branch type in callchain entry

Show branch type in callchain entry. The branch type is printed with other LBR information (such as cycles/abort/...). For example: perf report --branch-history --stdio --no-children --24.21%--main div.c:42 (RET CROSS_2M cycles:2) compute_flag div.c:28 (cycles:2) compute_flag

[PATCH v6 7/7] perf report: Show branch type in callchain entry

Show branch type in callchain entry. The branch type is printed with other LBR information (such as cycles/abort/...). For example: perf report --branch-history --stdio --no-children --24.21%--main div.c:42 (RET CROSS_2M cycles:2) compute_flag div.c:28 (cycles:2) compute_flag

[PATCH v6 2/7] perf/x86/intel: Record branch type

Perf already has support for disassembling the branch instruction and using the branch type for filtering. The patch just records the branch type in perf_branch_entry. Before recording, the patch converts the x86 branch type to common branch type. Change log -- v6: Not changed. v5:

[PATCH v6 2/7] perf/x86/intel: Record branch type

Perf already has support for disassembling the branch instruction and using the branch type for filtering. The patch just records the branch type in perf_branch_entry. Before recording, the patch converts the x86 branch type to common branch type. Change log -- v6: Not changed. v5:

[PATCH v6 0/7] perf report: Show branch type

v6: Update according to the review comments from Jiri Olsa . Major modifications are: 1. Move that multiline conditional code inside {} brackets. 2. Move branch_type_stat_display() from builtin-report.c to branch.c. Move branch_type_str() from callchain.c to

[PATCH v6 0/7] perf report: Show branch type

v6: Update according to the review comments from Jiri Olsa . Major modifications are: 1. Move that multiline conditional code inside {} brackets. 2. Move branch_type_stat_display() from builtin-report.c to branch.c. Move branch_type_str() from callchain.c to branch.c.

  1   2   3   4   5   6   7   8   9   10   >