Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Thu, Jun 16, 2016 at 01:38:13PM +0800, Huang Rui wrote: > On Wed, Jun 15, 2016 at 09:13:59PM -0400, Vince Weaver wrote: > > > > 2. Unless I'm misunderstanding things, the code seems to be accumulating > > Power. (see chunk below) Power is an instantaneous measurement, it > > makes

Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Thu, Jun 16, 2016 at 01:38:13PM +0800, Huang Rui wrote: > On Wed, Jun 15, 2016 at 09:13:59PM -0400, Vince Weaver wrote: > > > > 2. Unless I'm misunderstanding things, the code seems to be accumulating > > Power. (see chunk below) Power is an instantaneous measurement, it > > makes

linux-next: Tree for Jun 16

Hi all, Changes since 20160615: New tree: mali-dp The vhost tree gained a conflict against the net-next tree. The akpm-current tree regained a build failure for which I applied the previous fix patch. Non-merge commits (relative to Linus' tree): 3589 3588 files changed, 165565 insertions

linux-next: Tree for Jun 16

Hi all, Changes since 20160615: New tree: mali-dp The vhost tree gained a conflict against the net-next tree. The akpm-current tree regained a build failure for which I applied the previous fix patch. Non-merge commits (relative to Linus' tree): 3589 3588 files changed, 165565 insertions

Re: [PATCH v2 0/9] kexec_file_load implementation for PowerPC

On Tue, 2016-06-14 at 11:59 -0300, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements the kexec_file_load system call on PowerPC. Can you tell me what this syscall does and why I would want it? cheers

Re: [PATCH v2 0/9] kexec_file_load implementation for PowerPC

On Tue, 2016-06-14 at 11:59 -0300, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements the kexec_file_load system call on PowerPC. Can you tell me what this syscall does and why I would want it? cheers

linux-next: build failure after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc allyesconfig) failed like this: In file included from include/linux/mm.h:400:0, from mm/huge_memory.c:10: include/linux/huge_mm.h:53:22: error: initializer element is not constant #define

linux-next: build failure after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc allyesconfig) failed like this: In file included from include/linux/mm.h:400:0, from mm/huge_memory.c:10: include/linux/huge_mm.h:53:22: error: initializer element is not constant #define

Re: [PATCH 3/3] ARM: dts: imx7: add Toradex Colibri iMX7S/iMX7D support

On 2016-06-11 19:31, Shawn Guo wrote: > On Tue, Jun 07, 2016 at 07:37:09PM -0700, Stefan Agner wrote: >> + { >> +status = "okay"; >> +display = <>; > > Please put 'status' at the bottom of property list. > >> + >> +display0: lcd-display { >> +bits-per-pixel = <16>; >> +

Re: [PATCH 3/3] ARM: dts: imx7: add Toradex Colibri iMX7S/iMX7D support

On 2016-06-11 19:31, Shawn Guo wrote: > On Tue, Jun 07, 2016 at 07:37:09PM -0700, Stefan Agner wrote: >> + { >> +status = "okay"; >> +display = <>; > > Please put 'status' at the bottom of property list. > >> + >> +display0: lcd-display { >> +bits-per-pixel = <16>; >> +

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote: > On 06/16/2016 05:56 AM, Minchan Kim wrote: > > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: > >> On 06/15/2016 08:02 AM, Minchan Kim wrote: > >>> Hi, > >>> > >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530,

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote: > On 06/16/2016 05:56 AM, Minchan Kim wrote: > > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: > >> On 06/15/2016 08:02 AM, Minchan Kim wrote: > >>> Hi, > >>> > >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530,

[PATCH RFC] Revert "cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2"

This is not an actual request for revert, but rather for comments about the observed behavior since I am not really familiar with cpufreq. I am observing a serious performance regression on Jetson TK1 since 4.7-rc1: namely, moving windows under X would become unsufferably slow, and graphical

[PATCH RFC] Revert "cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2"

This is not an actual request for revert, but rather for comments about the observed behavior since I am not really familiar with cpufreq. I am observing a serious performance regression on Jetson TK1 since 4.7-rc1: namely, moving windows under X would become unsufferably slow, and graphical

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

On Jun 15, 2016 9:32 PM, "Mika Penttilä" wrote: > > Hi, > > > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c > > index 5643fd0b1a7d..fbf036ae72ac 100644 > > --- a/arch/x86/mm/tlb.c > > +++ b/arch/x86/mm/tlb.c > > @@ -77,10 +77,25 @@ void switch_mm_irqs_off(struct

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

On Jun 15, 2016 9:32 PM, "Mika Penttilä" wrote: > > Hi, > > > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c > > index 5643fd0b1a7d..fbf036ae72ac 100644 > > --- a/arch/x86/mm/tlb.c > > +++ b/arch/x86/mm/tlb.c > > @@ -77,10 +77,25 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct > >

Re: [PATCH net-next 0/8] rxrpc: Rework endpoint record handling

og/?h=rxrpc-rewrite > > Tagged thusly: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-rewrite-20160615 Pulled, thanks David.

Re: [PATCH net-next 0/8] rxrpc: Rework endpoint record handling

gt; Tagged thusly: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-rewrite-20160615 Pulled, thanks David.

Re: [PATCH v7 00/12] Support non-lru page migration

h processor mfd_core sch_fq_codel sd_mod hid_generic usb > > kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted > > 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491 > > kernel: 8801124c73f8 814d69b0 ea0004076e00 > > kern

Re: [PATCH v7 00/12] Support non-lru page migration

h processor mfd_core sch_fq_codel sd_mod hid_generic usb > > kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted > > 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491 > > kernel: 8801124c73f8 814d69b0 ea0004076e00 > > kern

Re: [PATCH 0/4] net-next: mediatek: IRQ cleanups, fixes and grouping

From: John Crispin Date: Wed, 15 Jun 2016 16:58:46 +0200 > This series contains 2 small code cleanups that are leftovers from the > MIPS support. There is also a small fix that adds proper locking to the > code accessing the IRQ registers. Without this fix we saw deadlocks

Re: [PATCH 0/4] net-next: mediatek: IRQ cleanups, fixes and grouping

From: John Crispin Date: Wed, 15 Jun 2016 16:58:46 +0200 > This series contains 2 small code cleanups that are leftovers from the > MIPS support. There is also a small fix that adds proper locking to the > code accessing the IRQ registers. Without this fix we saw deadlocks caused > by the last

Re: [PATCH] net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG

From: "Jason A. Donenfeld" Date: Wed, 15 Jun 2016 11:14:53 +0200 > The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG > case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for > CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to

Re: [PATCH] net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG

From: "Jason A. Donenfeld" Date: Wed, 15 Jun 2016 11:14:53 +0200 > The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG > case was added with 2c94b5373 ("net: Implement net_dbg_ratelimited() for > CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the > usual

Re: [PATCH v2 09/11] net: skfb: remove obsolete -I cflag

From: Arnd Bergmann Date: Wed, 15 Jun 2016 17:45:51 +0200 > The skfp driver has been moved to drivers/net/fddi/skfp a long time > ago, but we still attempt to include headers from the old location, > which causes a warning when building with W=1: > > cc1: error:

Re: [PATCH v2 09/11] net: skfb: remove obsolete -I cflag

From: Arnd Bergmann Date: Wed, 15 Jun 2016 17:45:51 +0200 > The skfp driver has been moved to drivers/net/fddi/skfp a long time > ago, but we still attempt to include headers from the old location, > which causes a warning when building with W=1: > > cc1: error: /git/arm-soc/drivers/net/skfp:

Re: [PATCH v2] drivers/idle: make intel_idle.c driver more explicitly non-modular

Applied, thanks! Len Brown, Intel Open Source Technology Center

Re: [PATCH v2] drivers/idle: make intel_idle.c driver more explicitly non-modular

Applied, thanks! Len Brown, Intel Open Source Technology Center

[GIT PULL] extcon fixes for 4.7-rc4

Dear Greg, This is extcon-fixes pull request for v4.7-rc4 I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05

[GIT PULL] extcon fixes for 4.7-rc4

Dear Greg, This is extcon-fixes pull request for v4.7-rc4 I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05

Re: [PATCH v7 00/12] Support non-lru page migration

bisect it? > kernel: flags: 0x8000() > kernel: page dumped because: nonzero mapcount > kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon > crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii > snd_hda_intel snd_hda_codec snd_hda_core ac

Re: [PATCH v7 00/12] Support non-lru page migration

bisect it? > kernel: flags: 0x8000() > kernel: page dumped because: nonzero mapcount > kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon > crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii > snd_hda_intel snd_hda_codec snd_hda_core ac

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

Arnd Bergmann writes: > I'd start by copying the relevant nodes from > arch/arm/boot/dts/arm-realview-pb11mp.dts, which is the closest > I can think of. I've put together something completely untested > below. Thanks. I will try to handle that. 3+ weeks, unfortunately. Now, what

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

Arnd Bergmann writes: > I'd start by copying the relevant nodes from > arch/arm/boot/dts/arm-realview-pb11mp.dts, which is the closest > I can think of. I've put together something completely untested > below. Thanks. I will try to handle that. 3+ weeks, unfortunately. Now, what do we do with

[PATCH V2 resend] libata:fix kernel panic when hotplug

In normal condition,if we use sas protocol and hotplug a sata disk on a port,the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug it,then plug a new sata disk,this operation may cause a kernel panic like this: [

[PATCH V2 resend] libata:fix kernel panic when hotplug

In normal condition,if we use sas protocol and hotplug a sata disk on a port,the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug it,then plug a new sata disk,this operation may cause a kernel panic like this: [

[PATCH v2] iommu/amd: Add proper error check in two functions

From: Wan Zongshun This patch is to do the following: 1. Add error check for caller of iommu_device_create. 2. Add error check for caller of iommu_device_link and move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of iommuv2 capability condition that make

[PATCH v2] iommu/amd: Add proper error check in two functions

From: Wan Zongshun This patch is to do the following: 1. Add error check for caller of iommu_device_create. 2. Add error check for caller of iommu_device_link and move 'iommu = amd_iommu_rlookup_table[dev_data->devid]' out of iommuv2 capability condition that make iommu_device_link also use

linux-next: build warning after merge of the gpio tree

Hi Linus, After merging the gpio tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from drivers/gpio/gpiolib.c:25:0: drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread': include/linux/kfifo.h:403:39: warning: 'ge.id' may be used uninitialized in

linux-next: build warning after merge of the gpio tree

Hi Linus, After merging the gpio tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from drivers/gpio/gpiolib.c:25:0: drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread': include/linux/kfifo.h:403:39: warning: 'ge.id' may be used uninitialized in

Re: [PATCH v7 00/12] Support non-lru page migration

count kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb kernel: CPU:

Re: [PATCH v7 00/12] Support non-lru page migration

count kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb kernel: CPU:

Re: [PATCH v1 0/3] per-process reclaim

On 6/15/2016 6:27 AM, Minchan Kim wrote: > > Yeb, I read Johannes's thread which suggests one-cgroup-per-app model. > It does make sense to me. It is worth to try although I guess it's not > easy to control memory usage on demand, not proactively. > If we can do, maybe we don't need per-process

Re: [PATCH v1 0/3] per-process reclaim

On 6/15/2016 6:27 AM, Minchan Kim wrote: > > Yeb, I read Johannes's thread which suggests one-cgroup-per-app model. > It does make sense to me. It is worth to try although I guess it's not > easy to control memory usage on demand, not proactively. > If we can do, maybe we don't need per-process

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

Hi Michael, Today's linux-next merge of the vhost tree got a conflict in: tools/virtio/ringtest/Makefile between commit: 9fb6bc5b4a78 ("ptr_ring: ring test") from the net-next tree and commit: 139ab4d4e68b ("tools/virtio: add noring tool") from the vhost tree. I fixed it up (see

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

Hi Michael, Today's linux-next merge of the vhost tree got a conflict in: tools/virtio/ringtest/Makefile between commit: 9fb6bc5b4a78 ("ptr_ring: ring test") from the net-next tree and commit: 139ab4d4e68b ("tools/virtio: add noring tool") from the vhost tree. I fixed it up (see

[PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

The two members min_scan_time and max_scan_time of structure "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values are assigned directtly from firmware without endian conversion handling. So, wrong datas will get saved in big-endian systems. This patch converts the values into

[PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

The two members min_scan_time and max_scan_time of structure "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values are assigned directtly from firmware without endian conversion handling. So, wrong datas will get saved in big-endian systems. This patch converts the values into

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

Hi, On 06/16/2016 03:28 AM, Andy Lutomirski wrote: > This allows x86_64 kernels to enable vmapped stacks. There are a > couple of interesting bits. > > First, x86 lazily faults in top-level paging entries for the vmalloc > area. This won't work if we get a page fault while trying to access >

Re: [PATCH 12/13] x86/mm/64: Enable vmapped stacks

Hi, On 06/16/2016 03:28 AM, Andy Lutomirski wrote: > This allows x86_64 kernels to enable vmapped stacks. There are a > couple of interesting bits. > > First, x86 lazily faults in top-level paging entries for the vmalloc > area. This won't work if we get a page fault while trying to access >

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

On 四, 2016-06-16 at 11:27 +0800, Zhang Rui wrote: > On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote: > > > > This patch moves the passive attribute to tz->device.groups. Moving > > the > > passive attribute also requires a .is_visible() callback > > implementation > > for its attribute

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

On 四, 2016-06-16 at 11:27 +0800, Zhang Rui wrote: > On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote: > > > > This patch moves the passive attribute to tz->device.groups. Moving > > the > > passive attribute also requires a .is_visible() callback > > implementation > > for its attribute

Re: [PATCH] mdio: mux: avoid 'maybe-uninitialized' warning

From: Arnd Bergmann Date: Tue, 14 Jun 2016 12:03:17 +0200 > The latest changes to the MDIO code introduced a false-positive > warning with gcc-6 (possibly others): > > drivers/net/phy/mdio-mux.c: In function 'mdio_mux_init': > drivers/net/phy/mdio-mux.c:188:3: error:

Re: [PATCH] mdio: mux: avoid 'maybe-uninitialized' warning

From: Arnd Bergmann Date: Tue, 14 Jun 2016 12:03:17 +0200 > The latest changes to the MDIO code introduced a false-positive > warning with gcc-6 (possibly others): > > drivers/net/phy/mdio-mux.c: In function 'mdio_mux_init': > drivers/net/phy/mdio-mux.c:188:3: error: 'parent_bus_node' may be

[git pull] drm fixes for rc4

Hi Linus, Main drm fixes pull for rc4, one regression fix in the connector refcounting, and an MST fix. There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes, mostly regression or black screen fixes. Dave. The following changes since commit

[git pull] drm fixes for rc4

Hi Linus, Main drm fixes pull for rc4, one regression fix in the connector refcounting, and an MST fix. There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes, mostly regression or black screen fixes. Dave. The following changes since commit

[PATCH] mm: memcontrol: fix cgroup creation failure after many small jobs

The memory controller has quite a bit of state that usually outlives the cgroup and pins its CSS until said state disappears. At the same time it imposes a 16-bit limit on the CSS ID space to economically store IDs in the wild. Consequently, when we use cgroups to contain frequent but small and

[PATCH] mm: memcontrol: fix cgroup creation failure after many small jobs

The memory controller has quite a bit of state that usually outlives the cgroup and pins its CSS until said state disappears. At the same time it imposes a 16-bit limit on the CSS ID space to economically store IDs in the wild. Consequently, when we use cgroups to contain frequent but small and

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

On 06/16/2016 05:56 AM, Minchan Kim wrote: > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: >> On 06/15/2016 08:02 AM, Minchan Kim wrote: >>> Hi, >>> >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > On 05/31/2016 05:31 AM, Minchan Kim wrote: >>>

Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

On 06/16/2016 05:56 AM, Minchan Kim wrote: > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: >> On 06/15/2016 08:02 AM, Minchan Kim wrote: >>> Hi, >>> >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > On 05/31/2016 05:31 AM, Minchan Kim wrote: >>>

Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing

On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote: > Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT > machines on tip/sched/core? load.weight has a higher resolution than > runnable_load_avg (and so the values in the rq->cpu_load[] array). > Theoretically because

Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing

On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote: > Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT > machines on tip/sched/core? load.weight has a higher resolution than > runnable_load_avg (and so the values in the rq->cpu_load[] array). > Theoretically because

Re: [PATCH V2] libata:fix kernel panic when hotplug

Hi, [auto build test ERROR on tj-libata/for-next] [also build test ERROR on v4.7-rc3 next-20160615] [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/DingXiang/libata-fix-kernel-panic-when-hotplug

Re: [PATCH V2] libata:fix kernel panic when hotplug

Hi, [auto build test ERROR on tj-libata/for-next] [also build test ERROR on v4.7-rc3 next-20160615] [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/DingXiang/libata-fix-kernel-panic-when-hotplug

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote: > This patch moves the passive attribute to tz->device.groups. Moving > the > passive attribute also requires a .is_visible() callback > implementation > for its attribute group. > > The logic behind the visibility of passive attribute is

Re: [PATCHv4 07/48] thermal: core: move passive attr to tz->device.groups

On 一, 2016-05-30 at 23:18 -0700, Eduardo Valentin wrote: > This patch moves the passive attribute to tz->device.groups. Moving > the > passive attribute also requires a .is_visible() callback > implementation > for its attribute group. > > The logic behind the visibility of passive attribute is

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote: > First patch describe problem about 0xe045 code. Second and third are just > cosmetic and last rework code which processing WMI events. It should be > properly tested on more Dell machines, to check that everything is still > working

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote: > First patch describe problem about 0xe045 code. Second and third are just > cosmetic and last rework code which processing WMI events. It should be > properly tested on more Dell machines, to check that everything is still > working

Re: [PATCH v3] sched: fix first task of a task group is attached twice

On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote: > The cfs_rq->avg.last_update_time is initialize to 0 with the main effect > that the 1st sched_entity that will be attached, will keep its > last_update_time set to 0 and will attached once again during the > enqueue. > Initialize

Re: [PATCH v3] sched: fix first task of a task group is attached twice

On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote: > The cfs_rq->avg.last_update_time is initialize to 0 with the main effect > that the 1st sched_entity that will be attached, will keep its > last_update_time set to 0 and will attached once again during the > enqueue. > Initialize

Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

On Thu, Jun 16, 2016 at 4:52 AM, Maxime Ripard wrote: > Hi Chen-Yu, > > On Mon, Jun 13, 2016 at 11:01:53AM +0800, Chen-Yu Tsai wrote: >> On Fri, Jun 10, 2016 at 5:38 PM, Maxime Ripard >> wrote: >> > On Thu, Jun 02, 2016 at

Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

On Thu, Jun 16, 2016 at 4:52 AM, Maxime Ripard wrote: > Hi Chen-Yu, > > On Mon, Jun 13, 2016 at 11:01:53AM +0800, Chen-Yu Tsai wrote: >> On Fri, Jun 10, 2016 at 5:38 PM, Maxime Ripard >> wrote: >> > On Thu, Jun 02, 2016 at 11:15:55AM +0200, Bernhard Nortmann wrote: >> >> Am 02.06.2016 um 10:16

Re: [PATCH 1/2] drm/mediatek: Add gamma correction

Hi, Daniel, Thank you for your suggestion, I will modify that to use the atomic color management. Bibby On Tue, 2016-06-14 at 07:43 +0200, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote: > > Apply gamma function to correct brightness values. > > It applies

Re: [PATCH 1/2] drm/mediatek: Add gamma correction

Hi, Daniel, Thank you for your suggestion, I will modify that to use the atomic color management. Bibby On Tue, 2016-06-14 at 07:43 +0200, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote: > > Apply gamma function to correct brightness values. > > It applies

[PATCH v5 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

Add support for the JDI LT070ME05000 WUXGA DSI panel used in Nexus 7 2013 devices. Programming sequence for the panel is was originally found in the android-msm-flo-3.4-lollipop-release branch from: https://android.googlesource.com/kernel/msm.git And video mode setting is from

[PATCH v5 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

Add support for the JDI LT070ME05000 WUXGA DSI panel used in Nexus 7 2013 devices. Programming sequence for the panel is was originally found in the android-msm-flo-3.4-lollipop-release branch from: https://android.googlesource.com/kernel/msm.git And video mode setting is from

[PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

Provide a small convenience wrapper that set/get the display brightness value Cc: John Stultz Cc: Sumit Semwal Cc: Archit Taneja Cc: Rob Clark Cc: Jani Nikula Cc:

[PATCH v2 1/2] drm/dsi: Implement dcs set/get display brightness

Provide a small convenience wrapper that set/get the display brightness value Cc: John Stultz Cc: Sumit Semwal Cc: Archit Taneja Cc: Rob Clark Cc: Jani Nikula Cc: Thierry Reding Signed-off-by: Vinay Simha BN --- v1: *tested in nexus7 2nd gen. v2: * implemented jani review comments

[PATCH net 3/3] r8152: correct the rx early size

The rx early size should be (agg_buf_sz - packet size) / 8 Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f5bc351..4e257b8

[PATCH net 2/3] r8152: reset the bmu

Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected data remains in the hw. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c

[GIT PULL] platform-drivers-x86 for 4.7-2

Hi Linus, The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05 14:31:26 -0700) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.7-2 for you to fetch

[PATCH net 3/3] r8152: correct the rx early size

The rx early size should be (agg_buf_sz - packet size) / 8 Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f5bc351..4e257b8 100644 ---

[PATCH net 2/3] r8152: reset the bmu

Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected data remains in the hw. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 89dc752..f5bc351

[GIT PULL] platform-drivers-x86 for 4.7-2

Hi Linus, The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05 14:31:26 -0700) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v4.7-2 for you to fetch

Re: [PATCH v7 00/12] Support non-lru page migration

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user > > > memory access > > > [ 315.146546] general

Re: [PATCH v7 00/12] Support non-lru page migration

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user > > > memory access > > > [ 315.146546] general

[PATCH net 1/3] r8152: disable MAC clock speed down

Disable MAC clock speed down. It may casue the first control transfer to contain the wrong data, when the power state change from U1 to U0. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff

[PATCH net 1/3] r8152: disable MAC clock speed down

Disable MAC clock speed down. It may casue the first control transfer to contain the wrong data, when the power state change from U1 to U0. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git

[PATCH net 0/3] r8152: fix known issues

These patches fix some known issues. Hayes Wang (3): r8152: disable MAC clock speed down r8152: reset the bmu r8152: correct the rx early size drivers/net/usb/r8152.c | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) -- 2.4.11

[PATCH net 0/3] r8152: fix known issues

These patches fix some known issues. Hayes Wang (3): r8152: disable MAC clock speed down r8152: reset the bmu r8152: correct the rx early size drivers/net/usb/r8152.c | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) -- 2.4.11

[PATCH V2] libata:fix kernel panic when hotplug

From: Ding Xiang In normal condition,if we use sas protocol and hotplug a sata disk on a port,the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug it,then plug a new sata disk,this operation

[PATCH V2] libata:fix kernel panic when hotplug

From: Ding Xiang In normal condition,if we use sas protocol and hotplug a sata disk on a port,the sas driver will send event "PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed". But if a sata disk is run io and unplug it,then plug a new sata disk,this operation may cause a kernel panic

Re: [PATCH v7 00/12] Support non-lru page migration

freq snd lpc_ich soundcore mfd_core processor sch_fq_codel sd_mod hid_generic usbhid hid ahci libahci ehci_pci libata ehci_hcd usbcore scsi_mod usb_common [ 319.363895] CPU: 0 PID: 45 Comm: kswapd0 Not tainted 4.7.0-rc3-next-20160615-dbg-4-g550dc8a-dirty #490 [ 319.363950] task: 8800bfb93d80

Re: [PATCH v7 00/12] Support non-lru page migration

odec_generic r8169 mii i2c_i801 snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer acpi_cpufreq snd lpc_ich soundcore mfd_core processor sch_fq_codel sd_mod hid_generic usbhid hid ahci libahci ehci_pci libata ehci_hcd usbcore scsi_mod usb_common [ 319.363895] CPU: 0 PID: 45 Comm: kswapd0

[PATCH v3] mm/compaction: remove unnecessary order check in direct compact path

In direct compact path, both __alloc_pages_direct_compact and try_to_compact_pages check (order == 0). This patch removes the check in __alloc_pages_direct_compact() and move the modifying of current->flags to the entry point of direct page compaction where we really do the compaction.

[PATCH v3] mm/compaction: remove unnecessary order check in direct compact path

In direct compact path, both __alloc_pages_direct_compact and try_to_compact_pages check (order == 0). This patch removes the check in __alloc_pages_direct_compact() and move the modifying of current->flags to the entry point of direct page compaction where we really do the compaction.

Re: [alsa-devel] [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU Boards

On Wed, Jun 15, 2016 at 5:44 AM, Rob Herring wrote: > On Wed, Jun 15, 2016 at 4:53 AM, Mark Brown wrote: >> On Tue, Jun 14, 2016 at 05:38:10PM -0500, Rob Herring wrote: >>> On Mon, Jun 13, 2016 at 04:42:18PM +0800, Xing Zheng wrote: >> >>> > +sound { >>> > +

Re: [alsa-devel] [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU Boards

On Wed, Jun 15, 2016 at 5:44 AM, Rob Herring wrote: > On Wed, Jun 15, 2016 at 4:53 AM, Mark Brown wrote: >> On Tue, Jun 14, 2016 at 05:38:10PM -0500, Rob Herring wrote: >>> On Mon, Jun 13, 2016 at 04:42:18PM +0800, Xing Zheng wrote: >> >>> > +sound { >>> > + compatible =

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote: > On 06/15/2016 04:04 AM, Boqun Feng wrote: > > Hi Waiman, > > > > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote: > > > The osq_lock() and osq_unlock() function may not provide the necessary > > > acquire and release

Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

On Wed, Jun 15, 2016 at 03:01:19PM -0400, Waiman Long wrote: > On 06/15/2016 04:04 AM, Boqun Feng wrote: > > Hi Waiman, > > > > On Tue, Jun 14, 2016 at 06:48:04PM -0400, Waiman Long wrote: > > > The osq_lock() and osq_unlock() function may not provide the necessary > > > acquire and release

  1   2   3   4   5   6   7   8   9   10   >