Re: [PATCH V3 0/2] Add support for Tegra210 ADMA

On Fri, May 20, 2016 at 02:51:14PM -0400, Paul Gortmaker wrote: > On Fri, Oct 16, 2015 at 3:35 AM, Jon Hunter wrote: > > Add support for the Tegra210 Audio DMA (ADMA) controller. This was > > originally distributed as an RFC [0] based upon the existing tegra > > APB-DMA

Re: [PATCH V3 0/2] Add support for Tegra210 ADMA

On Fri, May 20, 2016 at 02:51:14PM -0400, Paul Gortmaker wrote: > On Fri, Oct 16, 2015 at 3:35 AM, Jon Hunter wrote: > > Add support for the Tegra210 Audio DMA (ADMA) controller. This was > > originally distributed as an RFC [0] based upon the existing tegra > > APB-DMA driver. Since then the

Re: [PATCH 3/3] ARM: configs: keystone: Enable PINCTRL_SINGLE Config

On Monday 23 May 2016 05:59 PM, Keerthy wrote: > keystone-k2l devices use pinmux and are compliant with PINCTRL_SINGLE. > Hence enable the config option. > > Signed-off-by: Keerthy A similar patch[1] is already posted. [1]https://patchwork.kernel.org/patch/8958091/ Thanks

Re: [PATCH 3/3] ARM: configs: keystone: Enable PINCTRL_SINGLE Config

On Monday 23 May 2016 05:59 PM, Keerthy wrote: > keystone-k2l devices use pinmux and are compliant with PINCTRL_SINGLE. > Hence enable the config option. > > Signed-off-by: Keerthy A similar patch[1] is already posted. [1]https://patchwork.kernel.org/patch/8958091/ Thanks and regards,

Re: [PATCH 2/3] arm: mach-keystone: Enable PINCTRL config

On Monday 23 May 2016 05:59 PM, Keerthy wrote: > keystone-k2l uses pinmux and is compliant with PINCTRL_SINGLE > which depends on PINCTRL. Hence enable PINCTRL. > > Signed-off-by: Keerthy > --- > arch/arm/mach-keystone/Kconfig | 1 + > 1 file changed, 1 insertion(+) > >

Re: [PATCH 2/3] arm: mach-keystone: Enable PINCTRL config

On Monday 23 May 2016 05:59 PM, Keerthy wrote: > keystone-k2l uses pinmux and is compliant with PINCTRL_SINGLE > which depends on PINCTRL. Hence enable PINCTRL. > > Signed-off-by: Keerthy > --- > arch/arm/mach-keystone/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git

bug report, DEBUG_LOCKS_WARN_ON at kernel/locking/lockdep.c:3646 check_flags

Hi Experts, With ARM , versatile-pb When I enable PROVE_LOCKING, DEBUG_LOCKDEP and KPROBES_SANITY_TEST, there will be a call trace like below: Kprobe smoke test: started [ cut here ] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3646 check_flags+0xdc/0x200

bug report, DEBUG_LOCKS_WARN_ON at kernel/locking/lockdep.c:3646 check_flags

Hi Experts, With ARM , versatile-pb When I enable PROVE_LOCKING, DEBUG_LOCKDEP and KPROBES_SANITY_TEST, there will be a call trace like below: Kprobe smoke test: started [ cut here ] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3646 check_flags+0xdc/0x200

Re: [PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

On Tue, 2016-05-24 at 10:39 +0800, Haishuang Yan wrote: > For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6). > > --- > Changes in v2: > - Place the "#if IS_ENABLED" block before the "} else if > (..) {" piece and the "#endif" before the closing brace and this > becomes much

Re: [PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

On Tue, 2016-05-24 at 10:39 +0800, Haishuang Yan wrote: > For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6). > > --- > Changes in v2: > - Place the "#if IS_ENABLED" block before the "} else if > (..) {" piece and the "#endif" before the closing brace and this > becomes much

Re: [PATCH v2 0/5] Thermal: Support for hardware-tracked trip points

On Mon, May 23, 2016 at 03:32:39PM +0800, Caesar Wang wrote: > Hello Eduardo & 'Zhang Rui' > > Do we have the chance to merge this series patches for next kernel? > I had picked them up in my github, and tested for a period of time with > rockchip inside kernel. > > Let me know if someone have

Re: [PATCH v2 0/5] Thermal: Support for hardware-tracked trip points

On Mon, May 23, 2016 at 03:32:39PM +0800, Caesar Wang wrote: > Hello Eduardo & 'Zhang Rui' > > Do we have the chance to merge this series patches for next kernel? > I had picked them up in my github, and tested for a period of time with > rockchip inside kernel. > > Let me know if someone have

Re: [PATCH v7 2/4] CMDQ: Mediatek CMDQ driver

Hi, HS: Some comments below. On Mon, 2016-05-23 at 20:23 +0800, HS Liao wrote: > This patch is first version of Mediatek Command Queue(CMDQ) driver. The > CMDQ is used to help read/write registers with critical time limitation, > such as updating display configuration during the vblank. It

Re: [PATCH v7 2/4] CMDQ: Mediatek CMDQ driver

Hi, HS: Some comments below. On Mon, 2016-05-23 at 20:23 +0800, HS Liao wrote: > This patch is first version of Mediatek Command Queue(CMDQ) driver. The > CMDQ is used to help read/write registers with critical time limitation, > such as updating display configuration during the vblank. It

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Mon, May 23, 2016 at 10:32:43PM -0400, Steven Rostedt wrote: > On Tue, 24 May 2016 11:16:31 +0900 > Namhyung Kim wrote: > > > > Why not checking "hist" file then? > > I guess that could be done too, but is there anything wrong with my > current solution? Or is it just

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Mon, May 23, 2016 at 10:32:43PM -0400, Steven Rostedt wrote: > On Tue, 24 May 2016 11:16:31 +0900 > Namhyung Kim wrote: > > > > Why not checking "hist" file then? > > I guess that could be done too, but is there anything wrong with my > current solution? Or is it just too hacky? How would

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

On Mon, May 23, 2016 at 01:36:51PM +0300, Roger Quadros wrote: > On 23/05/16 13:34, Jun Li wrote: > > Hi > > > >> -Original Message- > >> From: Roger Quadros [mailto:rog...@ti.com] > >> Sent: Monday, May 23, 2016 6:12 PM > >> To: Peter Chen > >> Cc: Jun Li

Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

On Mon, May 23, 2016 at 01:36:51PM +0300, Roger Quadros wrote: > On 23/05/16 13:34, Jun Li wrote: > > Hi > > > >> -Original Message- > >> From: Roger Quadros [mailto:rog...@ti.com] > >> Sent: Monday, May 23, 2016 6:12 PM > >> To: Peter Chen > >> Cc: Jun Li ; peter.c...@freescale.com;

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: > Per the discussion with Joonsoo Kim [1], we need check the return value of > lookup_page_ext() for all call sites since it might return NULL in some cases, > although it is unlikely, i.e. memory hotplug. > > Tested with ltp with

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: > Per the discussion with Joonsoo Kim [1], we need check the return value of > lookup_page_ext() for all call sites since it might return NULL in some cases, > although it is unlikely, i.e. memory hotplug. > > Tested with ltp with

Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/23/2016 07:18 PM, Al Viro wrote: On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote: The mainline kernels past 4.6.0 fail hang when logging in. There are no error messages, and the machine seems to be waiting for some event that never happens. The problem has been bisected to

Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/23/2016 07:18 PM, Al Viro wrote: On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote: The mainline kernels past 4.6.0 fail hang when logging in. There are no error messages, and the machine seems to be waiting for some event that never happens. The problem has been bisected to

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 2016/5/24 9:16, David Matlack wrote: On Mon, May 23, 2016 at 6:13 PM, Yang Zhang wrote: On 2016/5/24 2:04, David Matlack wrote: On Sun, May 22, 2016 at 6:26 PM, Yang Zhang wrote: On 2016/5/21 2:37, David Matlack wrote: It's not

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 2016/5/24 9:16, David Matlack wrote: On Mon, May 23, 2016 at 6:13 PM, Yang Zhang wrote: On 2016/5/24 2:04, David Matlack wrote: On Sun, May 22, 2016 at 6:26 PM, Yang Zhang wrote: On 2016/5/21 2:37, David Matlack wrote: It's not obvious to me why polling for a timer interrupt would

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-19 21:57 GMT+08:00 Paolo Bonzini : > > > On 19/05/2016 15:27, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If an emulated lapic timer will fire soon(in the scope of 10us the >> base of dynamic halt-polling, lower-end of message passing workload

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-19 21:57 GMT+08:00 Paolo Bonzini : > > > On 19/05/2016 15:27, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If an emulated lapic timer will fire soon(in the scope of 10us the >> base of dynamic halt-polling, lower-end of message passing workload >> latency TCP_RR's poll time < 10us) we can

linux-next: Tree for May 24

Hi all, Please do not add any v4.8 destined material to your linux-next included branches until after v4.7-rc1 has been released. Changes since 20160523: The drm-intel tree lost its build failure. Non-merge commits (relative to Linus' tree): 1334 1188 files changed, 42483 insertions(+), 14509

linux-next: Tree for May 24

Hi all, Please do not add any v4.8 destined material to your linux-next included branches until after v4.7-rc1 has been released. Changes since 20160523: The drm-intel tree lost its build failure. Non-merge commits (relative to Linus' tree): 1334 1188 files changed, 42483 insertions(+), 14509

[PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6). --- Changes in v2: - Place the "#if IS_ENABLED" block before the "} else if (..) {" piece and the "#endif" before the closing brace and this becomes much easier to look at. Signed-off-by: Haishuang Yan

Re: [PATCH v2 02/12] of: add J-Core cpu bindings

On Mon, May 23, 2016 at 06:29:48PM -0500, Rob Herring wrote: > >> > +- compatible: Must be "jcore,j2". > >> > >> Okay to have this, but you should have compatible strings for specific > >> core implementations. AIUI, J2 is just the ISA. > > > > There was some past discussion you probably missed on

[PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6). --- Changes in v2: - Place the "#if IS_ENABLED" block before the "} else if (..) {" piece and the "#endif" before the closing brace and this becomes much easier to look at. Signed-off-by: Haishuang Yan ---

Re: [PATCH v2 02/12] of: add J-Core cpu bindings

On Mon, May 23, 2016 at 06:29:48PM -0500, Rob Herring wrote: > >> > +- compatible: Must be "jcore,j2". > >> > >> Okay to have this, but you should have compatible strings for specific > >> core implementations. AIUI, J2 is just the ISA. > > > > There was some past discussion you probably missed on

[PATCH v4 3/7] perf tools: Enable overwrite settings

This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms

[PATCH v4 3/7] perf tools: Enable overwrite settings

This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms

Re: [PATCH 4/5] iommu/rockchip: add ARM64 cache flush operation for iommu

Catalin, Robin, On 2016年05月23日 21:35, Catalin Marinas wrote: On Mon, May 23, 2016 at 11:44:14AM +0100, Robin Murphy wrote: On 23/05/16 02:37, Shunqian Zheng wrote: From: Simon Signed-off-by: Simon --- drivers/iommu/rockchip-iommu.c | 4 1

Re: [PATCH 4/5] iommu/rockchip: add ARM64 cache flush operation for iommu

Catalin, Robin, On 2016年05月23日 21:35, Catalin Marinas wrote: On Mon, May 23, 2016 at 11:44:14AM +0100, Robin Murphy wrote: On 23/05/16 02:37, Shunqian Zheng wrote: From: Simon Signed-off-by: Simon --- drivers/iommu/rockchip-iommu.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v4 1/7] perf evlist: Introduce aux perf evlist

An auxiliary evlist is created by perf_evlist__new_aux() using an existing evlist as it parent. An auxiliary evlist can have its own 'struct perf_mmap', but can't have other data. User should use its parent instead when accessing other data. Auxiliary evlists are container of 'struct perf_mmap'.

[PATCH v4 1/7] perf evlist: Introduce aux perf evlist

An auxiliary evlist is created by perf_evlist__new_aux() using an existing evlist as it parent. An auxiliary evlist can have its own 'struct perf_mmap', but can't have other data. User should use its parent instead when accessing other data. Auxiliary evlists are container of 'struct perf_mmap'.

[PATCH v4 0/7] perf tools: Support overwritable ring buffer

This patch set enables daemonized perf recording by utilizing overwritable backward ring buffer. With this feature one can put perf background, and dump ring buffer records by a SIGUSR2 when he/she find something unusual. For example, following command record system calls, schedule events and

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Tue, 24 May 2016 11:16:31 +0900 Namhyung Kim wrote: > Why not checking "hist" file then? I guess that could be done too, but is there anything wrong with my current solution? Or is it just too hacky? How would one check if something exists in a file or not? Say, I want

[PATCH v4 0/7] perf tools: Support overwritable ring buffer

This patch set enables daemonized perf recording by utilizing overwritable backward ring buffer. With this feature one can put perf background, and dump ring buffer records by a SIGUSR2 when he/she find something unusual. For example, following command record system calls, schedule events and

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Tue, 24 May 2016 11:16:31 +0900 Namhyung Kim wrote: > Why not checking "hist" file then? I guess that could be done too, but is there anything wrong with my current solution? Or is it just too hacky? How would one check if something exists in a file or not? Say, I want to detect if

[PATCH v4 6/7] perf tools: Don't warn about out of order event if write_backward is used

If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if

[PATCH v4 4/7] perf record: Introduce rec->overwrite_evlist for overwritable events

Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's corresponding attributes, with these two evlists an event goes to either

[PATCH v4 7/7] perf tools: Check write_backward during evlist config

Before this patch, when using overwritable ring buffer on an old kernel, error message is misleading: # ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a Error: The raw_syscalls:sys_enter event is not supported. This patch output clear error message to tell user his/her kernel is too old:

[PATCH v4 6/7] perf tools: Don't warn about out of order event if write_backward is used

If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if

[PATCH v4 4/7] perf record: Introduce rec->overwrite_evlist for overwritable events

Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's corresponding attributes, with these two evlists an event goes to either

[PATCH v4 7/7] perf tools: Check write_backward during evlist config

Before this patch, when using overwritable ring buffer on an old kernel, error message is misleading: # ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a Error: The raw_syscalls:sys_enter event is not supported. This patch output clear error message to tell user his/her kernel is too old:

[PATCH v4 5/7] perf record: Toggle overwrite ring buffer for reading

overwrite_evt_state is introduced to reflect the state of overwritable ring buffers. It is a state machine with 3 states: RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY ^ ^ | | |___(disallow)___/| ||

[PATCH v4 5/7] perf record: Toggle overwrite ring buffer for reading

overwrite_evt_state is introduced to reflect the state of overwritable ring buffers. It is a state machine with 3 states: RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY ^ ^ | | |___(disallow)___/| ||

[PATCH v4 2/7] perf tools: Don't poll and mmap overwritable events

There's no need to receive events from overwritable ring buffer. Instead, perf should make them run background until something happen. This patch makes normal events from overwrite events ignored. Overwritable events must be mapped readonly and backward, so if evlist and evsel is not match

[PATCH v4 2/7] perf tools: Don't poll and mmap overwritable events

There's no need to receive events from overwritable ring buffer. Instead, perf should make them run background until something happen. This patch makes normal events from overwrite events ignored. Overwritable events must be mapped readonly and backward, so if evlist and evsel is not match

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Mon, May 23, 2016 at 02:34:56PM -0700, Andy Lutomirski wrote: > On Thu, May 19, 2016 at 4:15 PM, Josh Poimboeuf wrote: > > On Mon, May 02, 2016 at 08:52:41AM -0700, Andy Lutomirski wrote: > >> On Mon, May 2, 2016 at 6:52 AM, Josh Poimboeuf wrote: > >>

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Mon, May 23, 2016 at 02:34:56PM -0700, Andy Lutomirski wrote: > On Thu, May 19, 2016 at 4:15 PM, Josh Poimboeuf wrote: > > On Mon, May 02, 2016 at 08:52:41AM -0700, Andy Lutomirski wrote: > >> On Mon, May 2, 2016 at 6:52 AM, Josh Poimboeuf wrote: > >> > On Fri, Apr 29, 2016 at 05:08:50PM

Ahoj?

isem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi ucast. Odpoved na e-mailu nize v pripade zajmu. E-mail: pbrt...@gmail.com

Ahoj?

isem zastupujicí investicní zajem ze strany Dubaji, pro ktere hledáme vasi ucast. Odpoved na e-mailu nize v pripade zajmu. E-mail: pbrt...@gmail.com

Re: [PATCH v2 09/12] clocksource: add J-Core PIT/RTC driver

On Mon, May 23, 2016 at 10:32:35PM +0200, Daniel Lezcano wrote: > On Fri, May 20, 2016 at 11:15:16PM -0400, Rich Felker wrote: > > On Fri, May 20, 2016 at 04:01:56PM +0200, Daniel Lezcano wrote: > > > On Fri, May 20, 2016 at 02:53:04AM +, Rich Felker wrote: > > > > Signed-off-by: Rich Felker

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-24 10:19 GMT+08:00 Wanpeng Li : > 2016-05-24 2:01 GMT+08:00 David Matlack : >> On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: >>> From: Wanpeng Li >> >> I'm ok with this patch, but I'd like to

Re: [PATCH v2 09/12] clocksource: add J-Core PIT/RTC driver

On Mon, May 23, 2016 at 10:32:35PM +0200, Daniel Lezcano wrote: > On Fri, May 20, 2016 at 11:15:16PM -0400, Rich Felker wrote: > > On Fri, May 20, 2016 at 04:01:56PM +0200, Daniel Lezcano wrote: > > > On Fri, May 20, 2016 at 02:53:04AM +, Rich Felker wrote: > > > > Signed-off-by: Rich Felker

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-24 10:19 GMT+08:00 Wanpeng Li : > 2016-05-24 2:01 GMT+08:00 David Matlack : >> On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: >>> From: Wanpeng Li >> >> I'm ok with this patch, but I'd like to better understand the target >> workloads. What type of workloads do you expect to benefit

Re: [PATCH V5 5/6] vfio: platform: call _RST method when using ACPI

On 5/23/2016 11:21 AM, Eric Auger wrote: >> +acpi_ret = acpi_evaluate_integer(handle, "_RST", NULL, ); >> > + if (ACPI_FAILURE(acpi_ret)) >> > + return -EINVAL; > Can't you return something more explicit here? The error code will be > visible to the userspace. Difficult for him to

Re: [PATCH V5 5/6] vfio: platform: call _RST method when using ACPI

On 5/23/2016 11:21 AM, Eric Auger wrote: >> +acpi_ret = acpi_evaluate_integer(handle, "_RST", NULL, ); >> > + if (ACPI_FAILURE(acpi_ret)) >> > + return -EINVAL; > Can't you return something more explicit here? The error code will be > visible to the userspace. Difficult for him to

Re: [PATCH V5 5/6] vfio: platform: call _RST method when using ACPI

On 5/23/2016 10:41 AM, Eric Auger wrote: > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The device tree code checks for the presence of a reset driver and calls >> the of_reset function pointer by looking up the reset driver as a module. >> >> ACPI defines _RST method to perform device level

Re: [PATCH V5 5/6] vfio: platform: call _RST method when using ACPI

On 5/23/2016 10:41 AM, Eric Auger wrote: > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The device tree code checks for the presence of a reset driver and calls >> the of_reset function pointer by looking up the reset driver as a module. >> >> ACPI defines _RST method to perform device level

Re: [PATCH 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings

Yendapally Reddy Dhananjaya Reddy writes: > Document the bindings used by Northstar Plus(NSP) SoC random number > generator. > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > Acked-by: Eric Anholt

Re: [PATCH 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings

Yendapally Reddy Dhananjaya Reddy writes: > Document the bindings used by Northstar Plus(NSP) SoC random number > generator. > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > Acked-by: Eric Anholt signature.asc Description: PGP signature

Re: [PATCH 4/4] hwrng: bcm2835: Read as much data as available

Yendapally Reddy Dhananjaya Reddy writes: > Read the requested number of data from the fifo > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > > --- > drivers/char/hw_random/bcm2835-rng.c | 12 ++-- > 1 file changed, 10

Re: [PATCH 4/4] hwrng: bcm2835: Read as much data as available

Yendapally Reddy Dhananjaya Reddy writes: > Read the requested number of data from the fifo > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > > --- > drivers/char/hw_random/bcm2835-rng.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-24 2:01 GMT+08:00 David Matlack : > On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: >> From: Wanpeng Li > > I'm ok with this patch, but I'd like to better understand the target > workloads. What type of workloads do you

Re: [PATCH v3] KVM: halt-polling: poll if emulated lapic timer will fire soon

2016-05-24 2:01 GMT+08:00 David Matlack : > On Sun, May 22, 2016 at 5:42 PM, Wanpeng Li wrote: >> From: Wanpeng Li > > I'm ok with this patch, but I'd like to better understand the target > workloads. What type of workloads do you expect to benefit from this? dynticks guests I think is one of

Re: [PATCH V5 4/6] vfio: platform: add support for ACPI probe

On 5/23/2016 9:18 AM, Eric Auger wrote: > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The code is using the compatible DT string to associate a reset driver >> with the actual device itself. The compatible string does not exist on >> ACPI based systems. HID is the unique identifier for a device

Re: [PATCH V5 4/6] vfio: platform: add support for ACPI probe

On 5/23/2016 9:18 AM, Eric Auger wrote: > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The code is using the compatible DT string to associate a reset driver >> with the actual device itself. The compatible string does not exist on >> ACPI based systems. HID is the unique identifier for a device

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Mon, May 23, 2016 at 09:50:45PM -0400, Steven Rostedt wrote: > On Tue, 24 May 2016 08:54:38 +0900 > Namhyung Kim wrote: > > > Hi Steve, > > > > On Mon, May 23, 2016 at 03:15:38PM -0400, Steven Rostedt wrote: > > > > > > [ Folks, is this a proper work around? ] > > > >

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Mon, May 23, 2016 at 09:50:45PM -0400, Steven Rostedt wrote: > On Tue, 24 May 2016 08:54:38 +0900 > Namhyung Kim wrote: > > > Hi Steve, > > > > On Mon, May 23, 2016 at 03:15:38PM -0400, Steven Rostedt wrote: > > > > > > [ Folks, is this a proper work around? ] > > > > > > When histograms

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 7:09 PM, Andy Lutomirski wrote: > > What about this silly fix? (Pardon the probable whitespace damage.) That looks fine to me, and has a reason for it. That said, I'm not convinced about the preempt_enable/preempt_disable excuse: that would be

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 7:09 PM, Andy Lutomirski wrote: > > What about this silly fix? (Pardon the probable whitespace damage.) That looks fine to me, and has a reason for it. That said, I'm not convinced about the preempt_enable/preempt_disable excuse: that would be horribly buggy anyway, and

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:48 PM, Linus Torvalds wrote: > On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >>> >>> Or we could just let ksoftirqd do its thing and stop raising >>> HARDIRQ_COUNT. We could add a new preempt count field

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:48 PM, Linus Torvalds wrote: > On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >>> >>> Or we could just let ksoftirqd do its thing and stop raising >>> HARDIRQ_COUNT. We could add a new preempt count field just for IST >>> (yuck). We could try to hijack a

Re: [PATCH V5 2/6] vfio: platform: move reset call to a common function

On 5/23/2016 9:02 AM, Eric Auger wrote: > Hi Sinan, > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The reset call sequence seems to replicate itself multiple times >> across the file. Grouping them together for maintenance reasons. >> >> Signed-off-by: Sinan Kaya >> --- >>

Re: [PATCH V5 2/6] vfio: platform: move reset call to a common function

On 5/23/2016 9:02 AM, Eric Auger wrote: > Hi Sinan, > On 05/16/2016 04:13 AM, Sinan Kaya wrote: >> The reset call sequence seems to replicate itself multiple times >> across the file. Grouping them together for maintenance reasons. >> >> Signed-off-by: Sinan Kaya >> --- >>

Re: [PATCH 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng

Yendapally Reddy Dhananjaya Reddy writes: > This supports the random number generator available in NSP SoC. > Masks the rng interrupt for NSP. The interrupt reg is also present on the 2835. I would prefer for simplicity if you also initialized the register to the

Re: [PATCH 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng

Yendapally Reddy Dhananjaya Reddy writes: > This supports the random number generator available in NSP SoC. > Masks the rng interrupt for NSP. The interrupt reg is also present on the 2835. I would prefer for simplicity if you also initialized the register to the same value on the Pi, even

Re: [PATCH] staging: lustre: llite: drop acl from cache

2016-05-24 2:35 GMT+02:00 James Simmons : > Commit b8a7a3a6 change get_acl() for posix xattr to always cache > the ACL which increases the reference count. That reference count > can be reduced by have ll_get_acl() call forget_cached_acl() which > it wasn't. When an inode

Re: [PATCH] staging: lustre: llite: drop acl from cache

2016-05-24 2:35 GMT+02:00 James Simmons : > Commit b8a7a3a6 change get_acl() for posix xattr to always cache > the ACL which increases the reference count. That reference count > can be reduced by have ll_get_acl() call forget_cached_acl() which > it wasn't. When an inode gets deleted by Lustre

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

Additional: I would like to thank Ard for suggesting this approach. It turns out (apparently) that Mark Salter's initial X-Gene quirks internal to RH did it this way as well. You great minds think alike. If this works for folks then I hope it leads to upstream kernel support in F25 (we have a

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

Additional: I would like to thank Ard for suggesting this approach. It turns out (apparently) that Mark Salter's initial X-Gene quirks internal to RH did it this way as well. You great minds think alike. If this works for folks then I hope it leads to upstream kernel support in F25 (we have a

Re: [PATCH v5 5/5] mmc: sdhci-of-arasan: implement enhanced strobe callback

在 2016/5/24 5:00, Doug Anderson 写道: Shawn, On Sun, May 22, 2016 at 9:14 PM, Shawn Lin wrote: Currently sdhci-arasan 5.1 can support enhanced strobe function, and we now limit it just for "arasan,sdhci-5.1". Add mmc-hs400-enhanced-strobe in DT to enable the function

Re: [PATCH v5 5/5] mmc: sdhci-of-arasan: implement enhanced strobe callback

在 2016/5/24 5:00, Doug Anderson 写道: Shawn, On Sun, May 22, 2016 at 9:14 PM, Shawn Lin wrote: Currently sdhci-arasan 5.1 can support enhanced strobe function, and we now limit it just for "arasan,sdhci-5.1". Add mmc-hs400-enhanced-strobe in DT to enable the function if we're sure our

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >> >> Or we could just let ksoftirqd do its thing and stop raising >> HARDIRQ_COUNT. We could add a new preempt count field just for IST >> (yuck). We could try to hijack a different preempt count field >> (NMI?). But

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >> >> Or we could just let ksoftirqd do its thing and stop raising >> HARDIRQ_COUNT. We could add a new preempt count field just for IST >> (yuck). We could try to hijack a different preempt count field >> (NMI?). But I kind of like the

Re: [PATCH v5 4/5] mmc: debugfs: add HS400 enhanced strobe description

在 2016/5/24 4:56, Doug Anderson 写道: Shawn, On Sun, May 22, 2016 at 9:14 PM, Shawn Lin wrote: We introduce HS400 with enhanced strobe function, so we need to add it for debug show. Signed-off-by: Shawn Lin --- Changes in v5: None Changes

Re: [PATCH v5 4/5] mmc: debugfs: add HS400 enhanced strobe description

在 2016/5/24 4:56, Doug Anderson 写道: Shawn, On Sun, May 22, 2016 at 9:14 PM, Shawn Lin wrote: We introduce HS400 with enhanced strobe function, so we need to add it for debug show. Signed-off-by: Shawn Lin --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Tue, 24 May 2016 08:54:38 +0900 Namhyung Kim wrote: > Hi Steve, > > On Mon, May 23, 2016 at 03:15:38PM -0400, Steven Rostedt wrote: > > > > [ Folks, is this a proper work around? ] > > > > When histograms are not configured in the kernel, the ftracetest histogram > >

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Tue, 24 May 2016 08:54:38 +0900 Namhyung Kim wrote: > Hi Steve, > > On Mon, May 23, 2016 at 03:15:38PM -0400, Steven Rostedt wrote: > > > > [ Folks, is this a proper work around? ] > > > > When histograms are not configured in the kernel, the ftracetest histogram > > selftests should

Re: [PATCH 1/2] Documentation: add binding description of Rockchip PCIe controller

On 2016/5/24 3:53, Heiko Stuebner wrote: Am Samstag, 21. Mai 2016, 11:55:35 schrieb Shawn Lin: On 2016/5/20 19:20, Heiko Stuebner wrote: Hi Shawn, Am Freitag, 20. Mai 2016, 18:29:06 schrieb Shawn Lin: This patch add some required and optional properties for Rockchip PCIe controller. Also we

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Mon, May 23, 2016 at 4:02 PM, Jiri Kosina wrote: > On Fri, 20 May 2016, Andy Lutomirski wrote: > >> I think it would be negligible, at least for interrupts, since >> interrupts are already extremely expensive. But I don't love adding >> assembly code that makes them even

Re: [PATCH 1/2] Documentation: add binding description of Rockchip PCIe controller

On 2016/5/24 3:53, Heiko Stuebner wrote: Am Samstag, 21. Mai 2016, 11:55:35 schrieb Shawn Lin: On 2016/5/20 19:20, Heiko Stuebner wrote: Hi Shawn, Am Freitag, 20. Mai 2016, 18:29:06 schrieb Shawn Lin: This patch add some required and optional properties for Rockchip PCIe controller. Also we

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Mon, May 23, 2016 at 4:02 PM, Jiri Kosina wrote: > On Fri, 20 May 2016, Andy Lutomirski wrote: > >> I think it would be negligible, at least for interrupts, since >> interrupts are already extremely expensive. But I don't love adding >> assembly code that makes them even slower. The real

Re: [PATCH v2] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

Hi Heiko, On 2016年05月23日 22:51, Heiko Stuebner wrote: Hi Xing, Am Montag, 23. Mai 2016, 22:43:32 schrieb Xing Zheng: There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. --- Changes in v2: Signed-off-by: Xing Zheng

Re: [PATCH v2] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

Hi Heiko, On 2016年05月23日 22:51, Heiko Stuebner wrote: Hi Xing, Am Montag, 23. Mai 2016, 22:43:32 schrieb Xing Zheng: There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. --- Changes in v2: Signed-off-by: Xing Zheng something seems

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