Re: [PATCHv12 2/3] usb: USB Type-C connector class

On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote: > On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote: > > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote: > The Type-C specification states (in 4.5.2.2.11): > > "Note: if both Try.SRC and Try.SNK mechanisms are

Re: [PATCHv12 2/3] usb: USB Type-C connector class

On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote: > On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote: > > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote: > The Type-C specification states (in 4.5.2.2.11): > > "Note: if both Try.SRC and Try.SNK mechanisms are

Re: [PATCH v2 04/12] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION

On Mon, Nov 28, 2016 at 03:21:54PM +0100, Michal Hocko wrote: > On Tue 08-11-16 08:31:49, Naoya Horiguchi wrote: > > Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration > > functionality to x86_64, which should be safer at the first step. > > Please make sure to describe why this

Re: [PATCH v2 04/12] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION

On Mon, Nov 28, 2016 at 03:21:54PM +0100, Michal Hocko wrote: > On Tue 08-11-16 08:31:49, Naoya Horiguchi wrote: > > Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration > > functionality to x86_64, which should be safer at the first step. > > Please make sure to describe why this

Re: [RFC PATCH] crypto: Add IV generation algorithms

On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote: > > No one is using it as of now. It was just a thought to pass context > information, instead of making it part of the context which is shared > among dm-crypt and geniv. OK in that case we should just get rid of it until it's

Re: [RFC PATCH] crypto: Add IV generation algorithms

On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote: > > No one is using it as of now. It was just a thought to pass context > information, instead of making it part of the context which is shared > among dm-crypt and geniv. OK in that case we should just get rid of it until it's

Re: [PATCH] lockdep: fix report formatting

On 29/11/16 01:24, Dmitry Vyukov wrote: Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") printk() requires KERN_CONT to continue log messages. Lots of printk() in lockdep.c and print_ip_sym() don't have it. As the result lockdep reports are completely

Re: [PATCH] lockdep: fix report formatting

On 29/11/16 01:24, Dmitry Vyukov wrote: Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") printk() requires KERN_CONT to continue log messages. Lots of printk() in lockdep.c and print_ip_sym() don't have it. As the result lockdep reports are completely

Re: [PATCH] video: imxfb: remove the macros for initializing the DMACR

On Mon, Nov 28, 2016 at 11:43:09PM +0100, Martin Kaiser wrote: > The current definitions of DMACR_HM() and DMACR_TM() are correct only > for imx1, they're wrong for imx21. > > The macros are meant for legacy board files only, they're not applicable > for boards using device tree. > > At the

Re: [PATCH] video: imxfb: remove the macros for initializing the DMACR

On Mon, Nov 28, 2016 at 11:43:09PM +0100, Martin Kaiser wrote: > The current definitions of DMACR_HM() and DMACR_TM() are correct only > for imx1, they're wrong for imx21. > > The macros are meant for legacy board files only, they're not applicable > for boards using device tree. > > At the

Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC

On 29 November 2016 at 03:53, Ziji Hu wrote: > Hi Ulf, > > On 2016/11/28 23:16, Ulf Hansson wrote: >> On 28 November 2016 at 12:38, Ziji Hu wrote: >>> Hi Ulf, >>> >>> On 2016/11/28 19:13, Ulf Hansson wrote: > > As you suggest, I replace

Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC

On 29 November 2016 at 03:53, Ziji Hu wrote: > Hi Ulf, > > On 2016/11/28 23:16, Ulf Hansson wrote: >> On 28 November 2016 at 12:38, Ziji Hu wrote: >>> Hi Ulf, >>> >>> On 2016/11/28 19:13, Ulf Hansson wrote: > > As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(),

Re: [RFC PATCH] crypto: Add IV generation algorithms

Hi Herbert, On 29 November 2016 at 12:58, Herbert Xu wrote: > But that begs the question, who is supposed to use crypto_geniv_set_ctx? > I thought it was dm-crypt but your patch doesn't contain any uses > of it at all. No one is using it as of now. It was just a

Re: [RFC PATCH] crypto: Add IV generation algorithms

Hi Herbert, On 29 November 2016 at 12:58, Herbert Xu wrote: > But that begs the question, who is supposed to use crypto_geniv_set_ctx? > I thought it was dm-crypt but your patch doesn't contain any uses > of it at all. No one is using it as of now. It was just a thought to pass context

System Helpdesk

Erreichen Sie die Speichergrenze für Ihr Postfach. Bitte besuchen Sie den folgenden link, um die Wiederherstellung Ihrer E-Mail-Zugriff. http://www.emailcleanup001.tk/ System-Helpdesk

[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls

This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. On Qualcomm ARM64 platforms, the SMC call can return before it has completed. If this occurs, the call can be restarted, but it requires using the returned session ID value from the interrupted SMC call. The quirk stores off

System Helpdesk

Erreichen Sie die Speichergrenze für Ihr Postfach. Bitte besuchen Sie den folgenden link, um die Wiederherstellung Ihrer E-Mail-Zugriff. http://www.emailcleanup001.tk/ System-Helpdesk

[PATCH 2/2] firmware: qcom: scm: Fix interrupted SCM calls

This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. On Qualcomm ARM64 platforms, the SMC call can return before it has completed. If this occurs, the call can be restarted, but it requires using the returned session ID value from the interrupted SMC call. The quirk stores off

[PATCH 0/2] Support ARM SMCC SoC vendor quirks

At least one SoC vendor (Qualcomm) requires additional processing done during ARM SMCCC calls. As such, an additional parameter to the arm_smccc_smc is required to be able to handle SoC specific quirks. The Qualcomm quirk is necessary due to the fact that the scm call can be interrupted on

[PATCH 1/2] arm: kernel: Add SMC structure parameter

This patch adds a quirk parameter to the arm_smccc_smc call. The quirk structure allows for specialized SMC operations due to SoC specific requirements. This patch also fixes up all the current users of the arm_smccc_smc API. This patch and partial implementation was suggested by Will Deacon.

[PATCH 0/2] Support ARM SMCC SoC vendor quirks

At least one SoC vendor (Qualcomm) requires additional processing done during ARM SMCCC calls. As such, an additional parameter to the arm_smccc_smc is required to be able to handle SoC specific quirks. The Qualcomm quirk is necessary due to the fact that the scm call can be interrupted on

[PATCH 1/2] arm: kernel: Add SMC structure parameter

This patch adds a quirk parameter to the arm_smccc_smc call. The quirk structure allows for specialized SMC operations due to SoC specific requirements. This patch also fixes up all the current users of the arm_smccc_smc API. This patch and partial implementation was suggested by Will Deacon.

Re: RFC: documentation of the autogroup feature [v2]

Hi Peter, On 11/25/2016 10:49 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote: >> So, part of what I was struggling with was what you meant by cfs-cgroup. >> Do you mean the CFS bandwidth control features added in Linux 3.2? > > Nope, /me

Re: RFC: documentation of the autogroup feature [v2]

Hi Peter, On 11/25/2016 10:49 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote: >> So, part of what I was struggling with was what you meant by cfs-cgroup. >> Do you mean the CFS bandwidth control features added in Linux 3.2? > > Nope, /me

Re: [RFC PATCH] crypto: Add IV generation algorithms

On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote: > > Thank you for the reply. The dm-crypt changes are also included as > part of this patchset. It has been tested for functionality as well. > More information can be found in the cover letter including the test > procedure etc. > >

Re: [RFC PATCH] crypto: Add IV generation algorithms

On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote: > > Thank you for the reply. The dm-crypt changes are also included as > part of this patchset. It has been tested for functionality as well. > More information can be found in the cover letter including the test > procedure etc. > >

Re: [PATCH V4] i2c: mux: pca954x: Add ACPI support for pca954x

On 2016-11-29 08:04, Tin Huynh wrote: > This patch enables ACPI support for mux-pca954x driver. > > Signed-off-by: Tin Huynh > > Change from v1 : > -Don't shadow id variable. > -Include sorted header. > -Redefine acpi_device_id. > -Add CONFIG_ACPI. > --- >

Re: [PATCH V4] i2c: mux: pca954x: Add ACPI support for pca954x

On 2016-11-29 08:04, Tin Huynh wrote: > This patch enables ACPI support for mux-pca954x driver. > > Signed-off-by: Tin Huynh > > Change from v1 : > -Don't shadow id variable. > -Include sorted header. > -Redefine acpi_device_id. > -Add CONFIG_ACPI. > --- >

Re: [PATCH V3] i2c: mux: pca954x: Add ACPI support for pca954x

Hi! We're apparently misunderstanding each other, I meant only that last #ifdef in the v2 review... Sorry for not being clearer, new attempt below. Cheers, Peter On 2016-11-29 04:46, tnhu...@apm.com wrote: > From: Tin Huynh > > This patch enables ACPI support for mux-pca954x

Re: [PATCH V3] i2c: mux: pca954x: Add ACPI support for pca954x

Hi! We're apparently misunderstanding each other, I meant only that last #ifdef in the v2 review... Sorry for not being clearer, new attempt below. Cheers, Peter On 2016-11-29 04:46, tnhu...@apm.com wrote: > From: Tin Huynh > > This patch enables ACPI support for mux-pca954x driver. > >

Re: [PATCH 7/7] trace: Update documentation for mono, mono_raw and boot clock

* John Stultz wrote: > + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the > + fast monotonic clock, but also accounts for time spent in > + suspend. Since the clock access is designed for use in > + tracing in

Re: [PATCH 7/7] trace: Update documentation for mono, mono_raw and boot clock

* John Stultz wrote: > + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the > + fast monotonic clock, but also accounts for time spent in > + suspend. Since the clock access is designed for use in > + tracing in the suspend path, some

Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg

On Mon 28-11-16 12:19:07, Tejun Heo wrote: > Hello, > > On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote: > > > You'd certainly _hope_ that atomic allocations either have fallbacks > > > or are harmless if they fail, but I'd still rather see that > > > __GFP_NOWARN just to make

Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg

On Mon 28-11-16 12:19:07, Tejun Heo wrote: > Hello, > > On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote: > > > You'd certainly _hope_ that atomic allocations either have fallbacks > > > or are harmless if they fail, but I'd still rather see that > > > __GFP_NOWARN just to make

Re: [PATCH 4/7] time: alarmtimer: Add the tracepoints for alarmtimer

* John Stultz wrote: > From: Baolin Wang > > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the >

Re: [PATCH 4/7] time: alarmtimer: Add the tracepoints for alarmtimer

* John Stultz wrote: > From: Baolin Wang > > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. s/one alarm timer/an alarm

Re: [PATCH 2/7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

* John Stultz wrote: > From: Chen Yu > > Previously we encountered some memory overflow issues due to > the bogus sleep time brought by inconsistent rtc, which is > triggered when pm_trace is enabled, and we have fixed it > in recent kernel.

Re: [PATCH 2/7] timekeeping: Ignore the bogus sleep time if pm_trace is enabled

* John Stultz wrote: > From: Chen Yu > > Previously we encountered some memory overflow issues due to > the bogus sleep time brought by inconsistent rtc, which is > triggered when pm_trace is enabled, and we have fixed it > in recent kernel. However it's improper in the first place > to call

[tip:x86/urgent] tools/decode_stacktrace.sh: Fix address line detection on x86

Commit-ID: 8e8d8725d46d93ceffd3e708d905bc101a1905b5 Gitweb: http://git.kernel.org/tip/8e8d8725d46d93ceffd3e708d905bc101a1905b5 Author: Josh Poimboeuf AuthorDate: Mon, 28 Nov 2016 17:06:35 -0600 Committer: Ingo Molnar CommitDate: Tue, 29 Nov 2016

Re: [PATCH] tty: nozomi: avoid sprintf buffer overflow

On 11/28/2016, 10:04 PM, Arnd Bergmann wrote: > Testing with a gcc-7 snapshot produced an internal compiler error > for this file: > > drivers/tty/nozomi.c: In function 'receive_flow_control': > drivers/tty/nozomi.c:919:12: internal compiler error: in > get_substring_ranges_for_loc, at

[tip:x86/urgent] tools/decode_stacktrace.sh: Fix address line detection on x86

Commit-ID: 8e8d8725d46d93ceffd3e708d905bc101a1905b5 Gitweb: http://git.kernel.org/tip/8e8d8725d46d93ceffd3e708d905bc101a1905b5 Author: Josh Poimboeuf AuthorDate: Mon, 28 Nov 2016 17:06:35 -0600 Committer: Ingo Molnar CommitDate: Tue, 29 Nov 2016 08:10:05 +0100

Re: [PATCH] tty: nozomi: avoid sprintf buffer overflow

On 11/28/2016, 10:04 PM, Arnd Bergmann wrote: > Testing with a gcc-7 snapshot produced an internal compiler error > for this file: > > drivers/tty/nozomi.c: In function 'receive_flow_control': > drivers/tty/nozomi.c:919:12: internal compiler error: in > get_substring_ranges_for_loc, at

Re: [PATCH 4/4] thermal/intel_powerclamp: stop sched tick in forced idle

On Tue, 29 Nov 2016 07:21:14 +0800 kbuild test robot <l...@intel.com> wrote: > Hi Jacob, > > [auto build test ERROR on soc-thermal/next] > [also build test ERROR on v4.9-rc7 next-20161128] > [if your patch is applied to the wrong git tree, please drop us a > note to

Re: [PATCH 4/4] thermal/intel_powerclamp: stop sched tick in forced idle

On Tue, 29 Nov 2016 07:21:14 +0800 kbuild test robot wrote: > Hi Jacob, > > [auto build test ERROR on soc-thermal/next] > [also build test ERROR on v4.9-rc7 next-20161128] > [if your patch is applied to the wrong git tree, please drop us a > note to help improve the system

Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0

* Tim Chen wrote: > > + If unsure say Y here. > > > > If/when other architectures make use of this the Kconfig entry can be moved > > into  > > the scheduler Kconfig - but for the time being it can stay in arch/x86/. > > > > Another variant would be to eliminate

Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0

* Tim Chen wrote: > > + If unsure say Y here. > > > > If/when other architectures make use of this the Kconfig entry can be moved > > into  > > the scheduler Kconfig - but for the time being it can stay in arch/x86/. > > > > Another variant would be to eliminate the Kconfig option

Re: [PATCH v2 10/12] mm: mempolicy: mbind and migrate_pages support thp migration

On Fri, Nov 25, 2016 at 05:57:20PM +0530, Anshuman Khandual wrote: > On 11/08/2016 05:01 AM, Naoya Horiguchi wrote: ... > > @@ -497,30 +541,15 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned > > long addr, > > struct page *page; > > struct queue_pages *qp = walk->private; > >

Re: [PATCH v2 10/12] mm: mempolicy: mbind and migrate_pages support thp migration

On Fri, Nov 25, 2016 at 05:57:20PM +0530, Anshuman Khandual wrote: > On 11/08/2016 05:01 AM, Naoya Horiguchi wrote: ... > > @@ -497,30 +541,15 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned > > long addr, > > struct page *page; > > struct queue_pages *qp = walk->private; > >

Re: linux-next: build failure after merge of the crypto tree

t; Caused by commits > > da40e7a4ba4d ("crypto: aes-ce - Convert to skcipher") > 211f41af534a ("crypto: aesbs - Convert to skcipher") > > Missing dependencies? > > I have used the crypto tree from next-20161128 for today. Indeed. This patch should fix the

Re: linux-next: build failure after merge of the crypto tree

t; Caused by commits > > da40e7a4ba4d ("crypto: aes-ce - Convert to skcipher") > 211f41af534a ("crypto: aesbs - Convert to skcipher") > > Missing dependencies? > > I have used the crypto tree from next-20161128 for today. Indeed. This patch should fix the

[PATCH V4] i2c: mux: pca954x: Add ACPI support for pca954x

This patch enables ACPI support for mux-pca954x driver. Signed-off-by: Tin Huynh Change from v1 : -Don't shadow id variable. -Include sorted header. -Redefine acpi_device_id. -Add CONFIG_ACPI. --- drivers/i2c/muxes/i2c-mux-pca954x.c | 27 ++- 1

[PATCH V4] i2c: mux: pca954x: Add ACPI support for pca954x

This patch enables ACPI support for mux-pca954x driver. Signed-off-by: Tin Huynh Change from v1 : -Don't shadow id variable. -Include sorted header. -Redefine acpi_device_id. -Add CONFIG_ACPI. --- drivers/i2c/muxes/i2c-mux-pca954x.c | 27 ++- 1 files changed, 26

[PATCH v5 2/2] idle: add support for tasks that inject idle

From: Peter Zijlstra Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use realtime tasks to take control of CPU then inject idle. There are two issues with this approach: 1. Low efficiency: injected idle task is treated as busy so sched ticks do

AMD Bulldozer topology regression since 4.6

Hello Since Linux 4.6 (and still in 4.9-rc5 at least), both AMD Bulldozer cores of a single dual-core compute unit report the same core_id: $ cat /sys/devices/system/cpu/cpu{?,??}/topology/core_id 0 0 1 1 2 2 3 0 3 [...] Before 4.5 (and for a very long time), the kernel reported different

[PATCH v5 2/2] idle: add support for tasks that inject idle

From: Peter Zijlstra Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use realtime tasks to take control of CPU then inject idle. There are two issues with this approach: 1. Low efficiency: injected idle task is treated as busy so sched ticks do not stop during injected

AMD Bulldozer topology regression since 4.6

Hello Since Linux 4.6 (and still in 4.9-rc5 at least), both AMD Bulldozer cores of a single dual-core compute unit report the same core_id: $ cat /sys/devices/system/cpu/cpu{?,??}/topology/core_id 0 0 1 1 2 2 3 0 3 [...] Before 4.5 (and for a very long time), the kernel reported different

[PATCH v5 1/2] cpuidle: allow setting deepest idle

When idle injection is used to cap power, we need to override governor's choice of idle states. This patch allows caller to select the deepest idle state on a CPU therefore achieve the maximum potential power saving. Signed-off-by: Jacob Pan ---

[PATCH v5 1/2] cpuidle: allow setting deepest idle

When idle injection is used to cap power, we need to override governor's choice of idle states. This patch allows caller to select the deepest idle state on a CPU therefore achieve the maximum potential power saving. Signed-off-by: Jacob Pan --- drivers/cpuidle/cpuidle.c | 13 -

[PATCH v5 0/2] Stop sched tick in idle injection task

Changelog: v5: - Fix compile error in cpuidle patch reported by 0-day. - Reverse patch order for correct dependency. v4: - Misc comments from Ingo are addressed, including style fix, timeout handling, fork(). - Dropped powerclamp patch from this set, move to its

[PATCH v5 0/2] Stop sched tick in idle injection task

Changelog: v5: - Fix compile error in cpuidle patch reported by 0-day. - Reverse patch order for correct dependency. v4: - Misc comments from Ingo are addressed, including style fix, timeout handling, fork(). - Dropped powerclamp patch from this set, move to its

Re: Re: [PATCH] Input: joystick: adi - change msleep to usleep_range for small msecs

On Mon, Nov 28, 2016 at 01:49:31PM +, Aniroop Mathur wrote: > Hello Mr. Vojtech Pavlik, > > On 28 Nov 2016 17:23, "vojt...@ucw.cz" wrote: > > > > Hi. > > > > ADI_INIT_DELAY/ADI_DATA_DELAY doesn't have to be exact, and a longer > > sleep doesn't matter. In the

Re: Re: [PATCH] Input: joystick: adi - change msleep to usleep_range for small msecs

On Mon, Nov 28, 2016 at 01:49:31PM +, Aniroop Mathur wrote: > Hello Mr. Vojtech Pavlik, > > On 28 Nov 2016 17:23, "vojt...@ucw.cz" wrote: > > > > Hi. > > > > ADI_INIT_DELAY/ADI_DATA_DELAY doesn't have to be exact, and a longer > > sleep doesn't matter. In the initilization sequence -

[PATCH v1 2/4] perf report: Create a new option "--inline"

It takes some time to look for inline stack for callgraph addresses. So it provides a new option "--inline" to let user decide if enable this feature. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-report.txt | 4 tools/perf/builtin-report.c

Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding

On 28-11-16, 10:27, Stephen Boyd wrote: > On 11/23/2016 08:40 PM, Viresh Kumar wrote: > > But even in these cases we wouldn't be using the voltage values within the > > kernel as we will be giving only a performance state to the M3 core, right? > > Nope. In these cases we need to set a certain

[PATCH v1 2/4] perf report: Create a new option "--inline"

It takes some time to look for inline stack for callgraph addresses. So it provides a new option "--inline" to let user decide if enable this feature. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-report.txt | 4 tools/perf/builtin-report.c | 2 ++

Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding

On 28-11-16, 10:27, Stephen Boyd wrote: > On 11/23/2016 08:40 PM, Viresh Kumar wrote: > > But even in these cases we wouldn't be using the voltage values within the > > kernel as we will be giving only a performance state to the M3 core, right? > > Nope. In these cases we need to set a certain

[PATCH v1 3/4] perf report: Show inline stack in stdio mode

If the address belongs to an inlined function, the source information back to the first non-inlined function will be printed. For example: 0.05% test2test2 [.] main | ---/home/jinyao/perf-dev/test/test2.c:27 (inline) /home/jinyao/perf-dev/test/test2.c:35

[PATCH v1 3/4] perf report: Show inline stack in stdio mode

If the address belongs to an inlined function, the source information back to the first non-inlined function will be printed. For example: 0.05% test2test2 [.] main | ---/home/jinyao/perf-dev/test/test2.c:27 (inline) /home/jinyao/perf-dev/test/test2.c:35

[PATCH v1 4/4] perf report: Show inline stack in browser mode

For example: -0.05% test2test2 [.] main /home/jinyao/perf-dev/test/test2.c:27 (inline) /home/jinyao/perf-dev/test/test2.c:35 (inline) /home/jinyao/perf-dev/test/test2.c:45 (inline) /home/jinyao/perf-dev/test/test2.c:61 (inline) Signed-off-by: Jin Yao

[PATCH v1 4/4] perf report: Show inline stack in browser mode

For example: -0.05% test2test2 [.] main /home/jinyao/perf-dev/test/test2.c:27 (inline) /home/jinyao/perf-dev/test/test2.c:35 (inline) /home/jinyao/perf-dev/test/test2.c:45 (inline) /home/jinyao/perf-dev/test/test2.c:61 (inline) Signed-off-by: Jin Yao

[PATCH v1 0/4] perf report: Show inline stack

It would be useful for perf to support a mode to query the inline stack for callgraph addresses. This would simplify finding the right code in code that does a lot of inlining. For example, the c code: static inline void f3(void) { int i; for (i = 0; i < 1000;) {

[PATCH v1 1/4] perf report: Find the inline stack for a given address

It would be useful for perf to support a mode to query the inline stack for a given callgraph address. This would simplify finding the right code in code that does a lot of inlining. The srcline.c has contained the code which supports to translate the address to filename:line_nr. This patch just

[PATCH v1 0/4] perf report: Show inline stack

It would be useful for perf to support a mode to query the inline stack for callgraph addresses. This would simplify finding the right code in code that does a lot of inlining. For example, the c code: static inline void f3(void) { int i; for (i = 0; i < 1000;) {

[PATCH v1 1/4] perf report: Find the inline stack for a given address

It would be useful for perf to support a mode to query the inline stack for a given callgraph address. This would simplify finding the right code in code that does a lot of inlining. The srcline.c has contained the code which supports to translate the address to filename:line_nr. This patch just

Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE

On 11/29/2016 02:42 AM, Dave Hansen wrote: > On 11/22/2016 06:19 AM, Anshuman Khandual wrote: >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -3715,7 +3715,7 @@ struct page * >> .migratetype = gfpflags_to_migratetype(gfp_mask), >> }; >> >> -if (cpusets_enabled()) {

Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE

On 11/29/2016 02:42 AM, Dave Hansen wrote: > On 11/22/2016 06:19 AM, Anshuman Khandual wrote: >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -3715,7 +3715,7 @@ struct page * >> .migratetype = gfpflags_to_migratetype(gfp_mask), >> }; >> >> -if (cpusets_enabled()) {

Re: [PATCH] Input: joystick: gf2k - change msleep to usleep_range for small msecs

On Tue, Nov 29, 2016 at 01:11:49AM +0530, Aniroop Mathur wrote: > msleep(1~20) may not do what the caller intends, and will often sleep longer. > (~20 ms actual sleep for any value given in the 1~20ms range) > This is not the desired behaviour for many cases like device resume time, > device

Re: [PATCH] Input: joystick: gf2k - change msleep to usleep_range for small msecs

On Tue, Nov 29, 2016 at 01:11:49AM +0530, Aniroop Mathur wrote: > msleep(1~20) may not do what the caller intends, and will often sleep longer. > (~20 ms actual sleep for any value given in the 1~20ms range) > This is not the desired behaviour for many cases like device resume time, > device

[PATCH] Staging: comedi: cb_pcidda: fixed a comment style issue

Fixed a coding style issue Signed-off-by: Elias Carter --- drivers/staging/comedi/drivers/cb_pcidda.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/cb_pcidda.c b/drivers/staging/comedi/drivers/cb_pcidda.c index

[PATCH] Staging: comedi: cb_pcidda: fixed a comment style issue

Fixed a coding style issue Signed-off-by: Elias Carter --- drivers/staging/comedi/drivers/cb_pcidda.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/comedi/drivers/cb_pcidda.c b/drivers/staging/comedi/drivers/cb_pcidda.c index ccb37d1..9874147 100644

Re: [PATCH] Input: joystick: analog - change msleep to usleep_range for small msecs

On Tue, Nov 29, 2016 at 01:11:31AM +0530, Aniroop Mathur wrote: > msleep(1~20) may not do what the caller intends, and will often sleep longer. > (~20 ms actual sleep for any value given in the 1~20ms range) > This is not the desired behaviour for many cases like device resume time, > device

Re: [RFC][PATCH 2/5 v2] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()

Hi John, Thank you for the patch. On Monday 28 Nov 2016 21:04:41 John Stultz wrote: > In chasing down a previous issue with EDID probing from calling > drm_helper_hpd_irq_event() from irq context, Laurent noticed > that the DRM documentation suggests that > drm_kms_helper_hotplug_event() should

Re: [PATCH] Input: joystick: analog - change msleep to usleep_range for small msecs

On Tue, Nov 29, 2016 at 01:11:31AM +0530, Aniroop Mathur wrote: > msleep(1~20) may not do what the caller intends, and will often sleep longer. > (~20 ms actual sleep for any value given in the 1~20ms range) > This is not the desired behaviour for many cases like device resume time, > device

Re: [RFC][PATCH 2/5 v2] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()

Hi John, Thank you for the patch. On Monday 28 Nov 2016 21:04:41 John Stultz wrote: > In chasing down a previous issue with EDID probing from calling > drm_helper_hpd_irq_event() from irq context, Laurent noticed > that the DRM documentation suggests that > drm_kms_helper_hotplug_event() should

Re: [PATCH] Input: joystick: sidewinder - change msleep to usleep_range for small msecs

On Tue, Nov 29, 2016 at 01:08:22AM +0530, Aniroop Mathur wrote: > msleep(1~20) may not do what the caller intends, and will often sleep longer. > (~20 ms actual sleep for any value given in the 1~20ms range) > This is not the desired behaviour for many cases like device resume time, > device

Re: [PATCH] Input: joystick: sidewinder - change msleep to usleep_range for small msecs

On Tue, Nov 29, 2016 at 01:08:22AM +0530, Aniroop Mathur wrote: > msleep(1~20) may not do what the caller intends, and will often sleep longer. > (~20 ms actual sleep for any value given in the 1~20ms range) > This is not the desired behaviour for many cases like device resume time, > device

[PATCH] drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'

'vmw_cotable_alloc()' returns an error pointer on error, not NULL. Propagate the error code, instead of returning -ENOMEM unconditionally Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH] drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'

'vmw_cotable_alloc()' returns an error pointer on error, not NULL. Propagate the error code, instead of returning -ENOMEM unconditionally Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

RE: [PATCH v3] crypto: add virtio-crypto driver

> > > > > + > > > > +/* Note: kernel crypto API realization */ > > > > +static int virtio_crypto_ablkcipher_setkey(struct crypto_ablkcipher > > > > *tfm, > > > > +const uint8_t *key, > > > > +unsigned int keylen) > >

RE: [PATCH v3] crypto: add virtio-crypto driver

> > > > > + > > > > +/* Note: kernel crypto API realization */ > > > > +static int virtio_crypto_ablkcipher_setkey(struct crypto_ablkcipher > > > > *tfm, > > > > +const uint8_t *key, > > > > +unsigned int keylen) > >

Re: [PATCH v2 07/12] mm: thp: check pmd migration entry in common path

# sorry for late reply ... On Fri, Nov 18, 2016 at 02:56:24AM +0300, Kirill A. Shutemov wrote: > On Tue, Nov 08, 2016 at 08:31:52AM +0900, Naoya Horiguchi wrote: > > If one of callers of page migration starts to handle thp, memory management > > code > > start to see pmd migration entry, so we

Re: [PATCH v2 07/12] mm: thp: check pmd migration entry in common path

# sorry for late reply ... On Fri, Nov 18, 2016 at 02:56:24AM +0300, Kirill A. Shutemov wrote: > On Tue, Nov 08, 2016 at 08:31:52AM +0900, Naoya Horiguchi wrote: > > If one of callers of page migration starts to handle thp, memory management > > code > > start to see pmd migration entry, so we

Re: [RFC][PATCH 1/5 v2] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context

Hi John, Thank you for the patch. On Monday 28 Nov 2016 21:04:40 John Stultz wrote: > I was recently seeing issues with EDID probing, where > the logic to wait for the EDID read bit to be set by the > IRQ wasn't happening and the code would time out and fail. > > Digging deeper, I found this

Re: [RFC][PATCH 1/5 v2] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context

Hi John, Thank you for the patch. On Monday 28 Nov 2016 21:04:40 John Stultz wrote: > I was recently seeing issues with EDID probing, where > the logic to wait for the EDID read bit to be set by the > IRQ wasn't happening and the code would time out and fail. > > Digging deeper, I found this

[patch net v2] net: fec: cache statistics while device is down

Execution 'ethtool -S' on fec device that is down causes OOPS on Vybrid board: Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898200 pgd = ddecc000 [e0898200] *pgd=9e406811, *pte=400d1653, *ppte=400d1453 Internal error: : 1008 [#1] SMP ARM ... Reason of OOPS is that

[patch net v2] net: fec: cache statistics while device is down

Execution 'ethtool -S' on fec device that is down causes OOPS on Vybrid board: Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898200 pgd = ddecc000 [e0898200] *pgd=9e406811, *pte=400d1653, *ppte=400d1453 Internal error: : 1008 [#1] SMP ARM ... Reason of OOPS is that

[PATCH V5 06/10] PM / OPP: Add infrastructure to manage multiple regulators

This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar Tested-by: Dave

[PATCH V5 08/10] PM / OPP: Allow platform specific custom set_opp() callbacks

The generic set_opp() handler isn't sufficient for platforms with complex DVFS. For example, some TI platforms have multiple regulators for a CPU device. The order in which various supplies need to be programmed is only known to the platform code and its best to leave it to it. This patch

[PATCH V5 04/10] PM / OPP: Manage supply's voltage/current in a separate structure

This is a preparatory step for multiple regulator per device support. Move the voltage/current variables to a new structure. Signed-off-by: Viresh Kumar Tested-by: Dave Gerlach Reviewed-by: Stephen Boyd ---

[PATCH V5 08/10] PM / OPP: Allow platform specific custom set_opp() callbacks

The generic set_opp() handler isn't sufficient for platforms with complex DVFS. For example, some TI platforms have multiple regulators for a CPU device. The order in which various supplies need to be programmed is only known to the platform code and its best to leave it to it. This patch

  1   2   3   4   5   6   7   8   9   10   >