Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote: > On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote: > >> We had been using unwinder for over a decade in SUSE but it stopped > >> working for assembly recently (for obvious reasons). So having a working > >> and reliable unwinder again is

Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote: > On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote: > >> We had been using unwinder for over a decade in SUSE but it stopped > >> working for assembly recently (for obvious reasons). So having a working > >> and reliable unwinder again is

Re: [PATCH] x86 / hibernate: Fix 64-bit code passing control to image kernel

On Mon, Jun 13, 2016 at 6:42 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Logan Gunthorpe reports that hibernation stopped working reliably for > him after commit ab76f7b4ab23 (x86/mm: Set NX on gap between __ex_table > and rodata).

Re: [PATCH] x86 / hibernate: Fix 64-bit code passing control to image kernel

On Mon, Jun 13, 2016 at 6:42 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Logan Gunthorpe reports that hibernation stopped working reliably for > him after commit ab76f7b4ab23 (x86/mm: Set NX on gap between __ex_table > and rodata). Most likely, what happens is that the page

Re: [RFC] serial: 8250: fix regression in 8250 uart driver

On 06/13/2016 01:13 PM, Dinh Nguyen wrote: > Hi Andy, > > I saw that you have discovered that commit ec5a11a91eec ("serial: 8250: > Validate dmaengine rx chan meets requirements") introduced a regression > in the 8250 uart driver. For SoCFPGA platform, I am seeing this error: > > [5.541751]

Re: [RFC] serial: 8250: fix regression in 8250 uart driver

On 06/13/2016 01:13 PM, Dinh Nguyen wrote: > Hi Andy, > > I saw that you have discovered that commit ec5a11a91eec ("serial: 8250: > Validate dmaengine rx chan meets requirements") introduced a regression > in the 8250 uart driver. For SoCFPGA platform, I am seeing this error: > > [5.541751]

Re: [PATCH 1/2] powercap/rapl: add support for skx

On Monday, June 13, 2016 11:32:10 PM Rafael J. Wysocki wrote: > On Monday, May 23, 2016 09:45:42 AM Jacob Pan wrote: > > SKX RAPL interface is similar to HSX/BDX. > > > > Signed-off-by: Jacob Pan > > --- > > drivers/powercap/intel_rapl.c | 1 + > > 1 file changed,

Re: [PATCH 1/2] powercap/rapl: add support for skx

On Monday, June 13, 2016 11:32:10 PM Rafael J. Wysocki wrote: > On Monday, May 23, 2016 09:45:42 AM Jacob Pan wrote: > > SKX RAPL interface is similar to HSX/BDX. > > > > Signed-off-by: Jacob Pan > > --- > > drivers/powercap/intel_rapl.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff

Re: [PATCH v6 10/11] cpuidle/powernv: Add support for POWER ISA v3 idle states

On Wed, 2016-06-08 at 11:54 -0500, Shreyas B. Prabhu wrote: > >  /* >   * States for dedicated partition case. >   */ > @@ -167,6 +183,8 @@ static int powernv_add_idle_states(void) >   int nr_idle_states = 1; /* Snooze */ >   int dt_idle_states; >   u32 *latency_ns, *residency_ns,

Re: [RFC 01/18] capabilities: track actually used capabilities

On 06/13/16 21:12, Andy Lutomirski wrote: > On Mon, Jun 13, 2016 at 1:45 PM, Topi Miettinen wrote: >> On 06/13/16 20:32, Andy Lutomirski wrote: >>> On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: Track what capabilities are actually used and

Re: [PATCH v6 10/11] cpuidle/powernv: Add support for POWER ISA v3 idle states

On Wed, 2016-06-08 at 11:54 -0500, Shreyas B. Prabhu wrote: > >  /* >   * States for dedicated partition case. >   */ > @@ -167,6 +183,8 @@ static int powernv_add_idle_states(void) >   int nr_idle_states = 1; /* Snooze */ >   int dt_idle_states; >   u32 *latency_ns, *residency_ns,

Re: [RFC 01/18] capabilities: track actually used capabilities

On 06/13/16 21:12, Andy Lutomirski wrote: > On Mon, Jun 13, 2016 at 1:45 PM, Topi Miettinen wrote: >> On 06/13/16 20:32, Andy Lutomirski wrote: >>> On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: Track what capabilities are actually used and present the current situation in

[RESEND PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

This is a resend only: Ping? Last ping was 26 May; there has been zero response since then. Already have one ACK from Lorenzo; another from an arm64 maintainer would be really helpful. The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel

[RESEND PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

This is a resend only: Ping? Last ping was 26 May; there has been zero response since then. Already have one ACK from Lorenzo; another from an arm64 maintainer would be really helpful. The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel

Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin

On Thu, 9 Jun 2016 14:51:45 -0700 Kees Cook wrote: > On Mon, May 30, 2016 at 4:31 PM, Emese Revfy wrote: > > - GCC_PLUGINS_CFLAGS := $(addprefix > > -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) > > + GCC_PLUGINS_CFLAGS := $(strip

[RESEND PATCH v5 1/1] ARM64: ACPI: Update documentation for latest specification version

The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel documentation for the use of ACPI was written for the 5.1 version of the spec. There were significant additions to the spec that had not yet been mentioned -- for example, the 6.0 mechanisms added to

Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin

On Thu, 9 Jun 2016 14:51:45 -0700 Kees Cook wrote: > On Mon, May 30, 2016 at 4:31 PM, Emese Revfy wrote: > > - GCC_PLUGINS_CFLAGS := $(addprefix > > -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) > > + GCC_PLUGINS_CFLAGS := $(strip $(addprefix > >

[RESEND PATCH v5 1/1] ARM64: ACPI: Update documentation for latest specification version

The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel documentation for the use of ACPI was written for the 5.1 version of the spec. There were significant additions to the spec that had not yet been mentioned -- for example, the 6.0 mechanisms added to

Re: [PATCH 2/3] Kbuild: don't add obj tree in additional includes

Hi, [auto build test ERROR on kbuild/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 2/3] Kbuild: don't add obj tree in additional includes

Hi, [auto build test ERROR on kbuild/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] pcmcia: m32r_pcc: make it explicitly non-modular

The Kconfig for this option is currently: config M32R_PCC bool "M32R PCMCIA I/F" ...meaning that it currently is not being built as a module by anyone. Lets remove the essentially orphaned module code, so that when reading the driver there is no doubt it is builtin-only. Since module_init

[PATCH] pcmcia: m32r_pcc: make it explicitly non-modular

The Kconfig for this option is currently: config M32R_PCC bool "M32R PCMCIA I/F" ...meaning that it currently is not being built as a module by anyone. Lets remove the essentially orphaned module code, so that when reading the driver there is no doubt it is builtin-only. Since module_init

Re: [RFC 02/18] cgroup_pids: track maximum pids

Hello, On Mon, Jun 13, 2016 at 09:29:32PM +, Topi Miettinen wrote: > I used fork callback as I don't want to lower the watermark in all cases > where the charge can be lowered, so I'd update the watermark only when > the fork really happens. I don't think that would make a noticeable

Re: [RFC 02/18] cgroup_pids: track maximum pids

Hello, On Mon, Jun 13, 2016 at 09:29:32PM +, Topi Miettinen wrote: > I used fork callback as I don't want to lower the watermark in all cases > where the charge can be lowered, so I'd update the watermark only when > the fork really happens. I don't think that would make a noticeable

Re: [RFC 02/18] cgroup_pids: track maximum pids

On 06/13/16 21:12, Tejun Heo wrote: > Hello, > > On Mon, Jun 13, 2016 at 10:44:09PM +0300, Topi Miettinen wrote: >> Track maximum pids in the cgroup, present it in cgroup pids.current_max. > > "max" is often used for maximum limits in cgroup. I think "watermark" > or "high_watermark" would be a

Re: [RFC 02/18] cgroup_pids: track maximum pids

On 06/13/16 21:12, Tejun Heo wrote: > Hello, > > On Mon, Jun 13, 2016 at 10:44:09PM +0300, Topi Miettinen wrote: >> Track maximum pids in the cgroup, present it in cgroup pids.current_max. > > "max" is often used for maximum limits in cgroup. I think "watermark" > or "high_watermark" would be a

Re: [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, Jun 13, 2016 at 09:50:15PM +0200, Julia Lawall wrote: > > > On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > > > On Fri, Jun 10, 2016 at 11:21:28PM +0200, Julia Lawall wrote: > > > > > > > > > On Fri, 10 Jun 2016, Luis R. Rodriguez wrote: > > > > > > > On Fri, Jun 10, 2016 at

Re: [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, Jun 13, 2016 at 09:50:15PM +0200, Julia Lawall wrote: > > > On Mon, 13 Jun 2016, Luis R. Rodriguez wrote: > > > On Fri, Jun 10, 2016 at 11:21:28PM +0200, Julia Lawall wrote: > > > > > > > > > On Fri, 10 Jun 2016, Luis R. Rodriguez wrote: > > > > > > > On Fri, Jun 10, 2016 at

Re: [PATCH 1/2] powercap/rapl: add support for skx

On Monday, May 23, 2016 09:45:42 AM Jacob Pan wrote: > SKX RAPL interface is similar to HSX/BDX. > > Signed-off-by: Jacob Pan > --- > drivers/powercap/intel_rapl.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/powercap/intel_rapl.c

Re: [PATCH 1/2] powercap/rapl: add support for skx

On Monday, May 23, 2016 09:45:42 AM Jacob Pan wrote: > SKX RAPL interface is similar to HSX/BDX. > > Signed-off-by: Jacob Pan > --- > drivers/powercap/intel_rapl.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c > index

Re: [PATCH] ARM: mm: fix location of _etext

On Mon, Jun 13, 2016 at 01:23:29PM -0700, Kees Cook wrote: > On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook wrote: > > The _etext position is defined to be the end of the kernel text code, > > and should not include any part of the data segments. This interferes > > with things

Re: [PATCH] ARM: mm: fix location of _etext

On Mon, Jun 13, 2016 at 01:23:29PM -0700, Kees Cook wrote: > On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook wrote: > > The _etext position is defined to be the end of the kernel text code, > > and should not include any part of the data segments. This interferes > > with things that might check memory

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, Jun 13, 2016 at 09:48:30PM +0200, Julia Lawall wrote: > > > On Mon, 13 Jun 2016, Wolfram Sang wrote: > > > > > > Is there another scripts/coccinelle/ file I can use to test against to > > > demo > > > against glimpse/idutils/gitgrep best? > > > > I'd think this one may be a

Re: [Cocci] [PATCH 4/4] coccicheck: add indexing enhancement options

On Mon, Jun 13, 2016 at 09:48:30PM +0200, Julia Lawall wrote: > > > On Mon, 13 Jun 2016, Wolfram Sang wrote: > > > > > > Is there another scripts/coccinelle/ file I can use to test against to > > > demo > > > against glimpse/idutils/gitgrep best? > > > > I'd think this one may be a

God dag,

God dag, Jeg er fru Rose Butler, den udøvende agent for en anerkendt legitim långivende selskab kaldet YesGrowth lån. Har du har en dårlig kredit, eller du har brug for penge til at betale dine regninger? vores rente er 3%. udfylde nedenstående formular hvis interesseret. Fulde navn:

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote: > On 13 June 2016 at 17:01, Pavel Machek wrote: > > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > >> On 13 June 2016 at 15:00, Pavel Machek wrote: > >> > Hi! > >> > > >> >> > João, that means you

God dag,

God dag, Jeg er fru Rose Butler, den udøvende agent for en anerkendt legitim långivende selskab kaldet YesGrowth lån. Har du har en dårlig kredit, eller du har brug for penge til at betale dine regninger? vores rente er 3%. udfylde nedenstående formular hvis interesseret. Fulde navn:

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote: > On 13 June 2016 at 17:01, Pavel Machek wrote: > > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > >> On 13 June 2016 at 15:00, Pavel Machek wrote: > >> > Hi! > >> > > >> >> > João, that means you should send a patch to add the

Re: [PATCH 2/3] dma-buf/sync_file: add sync_file_get_fence()

2016-06-10 Chris Wilson : > On Thu, Jun 09, 2016 at 12:05:29PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Creates a function that given an sync file descriptor returns a > > fence_collection containing all fences in

Re: [PATCH 2/3] dma-buf/sync_file: add sync_file_get_fence()

2016-06-10 Chris Wilson : > On Thu, Jun 09, 2016 at 12:05:29PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Creates a function that given an sync file descriptor returns a > > fence_collection containing all fences in the sync_file. > > > > If there is only one fence in the

[PATCH 3/3] Kbuild: avoid duplicate include path

arch/$(hdr-arch)/include/generated/uapi is included twice in the header search path, which is unnecessary, so this changes the top-level Makefile to drop the second instance by filtering out everything from USERINCLUDE that was already part of LINUXINCLUDE. This should have very little effect

[PATCH 1/3] Kbuild: don't add ../../ to include path

When we build with O=objdir and objdir is directly below the source tree, $(srctree) becomes '..'. When a Makefile adds a CFLAGS option like -Ipath/to/headers and we are building with a separate object directory, Kbuild tries to add two -I options, one for the source tree and one for the object

[PATCH 3/3] Kbuild: avoid duplicate include path

arch/$(hdr-arch)/include/generated/uapi is included twice in the header search path, which is unnecessary, so this changes the top-level Makefile to drop the second instance by filtering out everything from USERINCLUDE that was already part of LINUXINCLUDE. This should have very little effect

[PATCH 1/3] Kbuild: don't add ../../ to include path

When we build with O=objdir and objdir is directly below the source tree, $(srctree) becomes '..'. When a Makefile adds a CFLAGS option like -Ipath/to/headers and we are building with a separate object directory, Kbuild tries to add two -I options, one for the source tree and one for the object

[PATCH 2/3] Kbuild: don't add obj tree in additional includes

When building with separate object directories and driver specific Makefiles that add additional header include paths, Kbuild adjusts the gcc flags so that we include both the directory in the source tree and in the object tree. However, due to another bug I fixed earlier, this did not actually

[PATCH 2/3] Kbuild: don't add obj tree in additional includes

When building with separate object directories and driver specific Makefiles that add additional header include paths, Kbuild adjusts the gcc flags so that we include both the directory in the source tree and in the object tree. However, due to another bug I fixed earlier, this did not actually

Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max

On Mon, Jun 13, 2016 at 2:13 PM, Topi Miettinen wrote: > On 06/13/16 20:40, Andy Lutomirski wrote: >> On 06/13/2016 12:44 PM, Topi Miettinen wrote: >>> Track maximum number of files for the process, present current maximum >>> in /proc/self/limits. >> >> The core part should

Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max

On Mon, Jun 13, 2016 at 2:13 PM, Topi Miettinen wrote: > On 06/13/16 20:40, Andy Lutomirski wrote: >> On 06/13/2016 12:44 PM, Topi Miettinen wrote: >>> Track maximum number of files for the process, present current maximum >>> in /proc/self/limits. >> >> The core part should be its own patch. >>

Re: [patch] x86/ldt: silence a static checker warning

On Sun, Jun 12, 2016 at 11:57 PM, Dan Carpenter wrote: > It likely doesn't make a difference but my static checker complains > that we put an upper bound on "size" but not a lower bound. Let's just > make it unsigned. Shouldn't oldsize and newsize in write_ldt as well

Re: [patch] x86/ldt: silence a static checker warning

On Sun, Jun 12, 2016 at 11:57 PM, Dan Carpenter wrote: > It likely doesn't make a difference but my static checker complains > that we put an upper bound on "size" but not a lower bound. Let's just > make it unsigned. Shouldn't oldsize and newsize in write_ldt as well as the "size" member in

Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max

On 06/13/16 20:40, Andy Lutomirski wrote: > On 06/13/2016 12:44 PM, Topi Miettinen wrote: >> Track maximum number of files for the process, present current maximum >> in /proc/self/limits. > > The core part should be its own patch. > > Also, you have this weirdly named (and racy!) function

Re: [RFC 02/18] cgroup_pids: track maximum pids

Hello, On Mon, Jun 13, 2016 at 10:44:09PM +0300, Topi Miettinen wrote: > Track maximum pids in the cgroup, present it in cgroup pids.current_max. "max" is often used for maximum limits in cgroup. I think "watermark" or "high_watermark" would be a lot clearer. > @@ -236,6 +246,14 @@ static void

Re: [RFC 05/18] limits: track and present RLIMIT_NOFILE actual max

On 06/13/16 20:40, Andy Lutomirski wrote: > On 06/13/2016 12:44 PM, Topi Miettinen wrote: >> Track maximum number of files for the process, present current maximum >> in /proc/self/limits. > > The core part should be its own patch. > > Also, you have this weirdly named (and racy!) function

Re: [RFC 02/18] cgroup_pids: track maximum pids

Hello, On Mon, Jun 13, 2016 at 10:44:09PM +0300, Topi Miettinen wrote: > Track maximum pids in the cgroup, present it in cgroup pids.current_max. "max" is often used for maximum limits in cgroup. I think "watermark" or "high_watermark" would be a lot clearer. > @@ -236,6 +246,14 @@ static void

Re: [RFC 01/18] capabilities: track actually used capabilities

On Mon, Jun 13, 2016 at 1:45 PM, Topi Miettinen wrote: > On 06/13/16 20:32, Andy Lutomirski wrote: >> On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: >>> Track what capabilities are actually used and present the current >>> situation in

Re: [RFC 01/18] capabilities: track actually used capabilities

On Mon, Jun 13, 2016 at 1:45 PM, Topi Miettinen wrote: > On 06/13/16 20:32, Andy Lutomirski wrote: >> On Mon, Jun 13, 2016 at 12:44 PM, Topi Miettinen wrote: >>> Track what capabilities are actually used and present the current >>> situation in /proc/self/status. >> >> What for? > > >

[PATCH 0/2] pinctrl: convert palmas and as3722 to tristate

As part of a previous review[1], these two drivers (currently bool) were nominated by their author to be converted to tristate (vs. removing the existing modular references.) Upon detecting a non-modular driver making modular references, I don't immediately convert them to tristate, since it

Re: [PATCH 3.16 000/114] 3.16.36-rc1 review

On Monday 13 June 2016 07:36 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.16.36 release. There are 114 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses

[PATCH 0/2] pinctrl: convert palmas and as3722 to tristate

As part of a previous review[1], these two drivers (currently bool) were nominated by their author to be converted to tristate (vs. removing the existing modular references.) Upon detecting a non-modular driver making modular references, I don't immediately convert them to tristate, since it

Re: [PATCH 3.16 000/114] 3.16.36-rc1 review

On Monday 13 June 2016 07:36 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.16.36 release. There are 114 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses

[PATCH 2/2] pinctrl: as3722: convert PINCTRL_AS3722 from bool to tristate

The Kconfig currently controlling compilation of this code is: config PINCTRL_AS3722 bool "Pinctrl and GPIO driver for ams AS3722 PMIC" ...meaning that it currently is not being built as a module by anyone. During an audit for non-modular drivers using modular infrastructure this driver

[PATCH 2/2] pinctrl: as3722: convert PINCTRL_AS3722 from bool to tristate

The Kconfig currently controlling compilation of this code is: config PINCTRL_AS3722 bool "Pinctrl and GPIO driver for ams AS3722 PMIC" ...meaning that it currently is not being built as a module by anyone. During an audit for non-modular drivers using modular infrastructure this driver

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On 13 June 2016 at 17:01, Pavel Machek wrote: > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: >> On 13 June 2016 at 15:00, Pavel Machek wrote: >> > Hi! >> > >> >> > João, that means you should send a patch to add the ::rfkill suffix. >> >> > >> >> >> >> IMO

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On 13 June 2016 at 17:01, Pavel Machek wrote: > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: >> On 13 June 2016 at 15:00, Pavel Machek wrote: >> > Hi! >> > >> >> > João, that means you should send a patch to add the ::rfkill suffix. >> >> > >> >> >> >> IMO "airplane" (or maybe

[PATCH 1/2] pinctrl: palmas: convert PINCTRL_PALMAS from bool to tristate

The Kconfig currently controlling compilation of this code is: config PINCTRL_PALMAS bool "Pinctrl driver for the PALMAS Series MFD devices" ...meaning that it currently is not being built as a module by anyone. During an audit for non-modular drivers using modular infrastructure this

[PATCH 1/2] pinctrl: palmas: convert PINCTRL_PALMAS from bool to tristate

The Kconfig currently controlling compilation of this code is: config PINCTRL_PALMAS bool "Pinctrl driver for the PALMAS Series MFD devices" ...meaning that it currently is not being built as a module by anyone. During an audit for non-modular drivers using modular infrastructure this

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> -Original Message- From: Sinan Kaya [mailto:ok...@codeaurora.org] Sent: 13

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> -Original Message- From: Sinan Kaya [mailto:ok...@codeaurora.org] Sent: 13 June 2016 15:03

[PATCH] power_supply: fix return value of get_property

power_supply_get_property() should ideally return -EAGAIN if it is called while the power_supply is being registered. There was no way previously to determine if use_cnt == 0 meant that the power_supply wasn't fully registered yet, or if it had already been unregistered. Add a new boolean to the

[PATCH] power_supply: fix return value of get_property

power_supply_get_property() should ideally return -EAGAIN if it is called while the power_supply is being registered. There was no way previously to determine if use_cnt == 0 meant that the power_supply wasn't fully registered yet, or if it had already been unregistered. Add a new boolean to the

RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

On 09-06-16 17:42:00, Dave Hansen wrote: > Does your workload put large pages in and out of those pvecs, though? > If your system doesn't have any activity, then all we've shown is that > they're not a problem when not in use. But what about when we use them? It doesn't. To use them extensively

RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

On 09-06-16 17:42:00, Dave Hansen wrote: > Does your workload put large pages in and out of those pvecs, though? > If your system doesn't have any activity, then all we've shown is that > they're not a problem when not in use. But what about when we use them? It doesn't. To use them extensively

Re: [PATCH 2/5] asus-wmi: Create quirk for airplane_mode LED

On 25 May 2016 at 17:24, Darren Hart wrote: > (...) > I believe this is all still blocked on the underlying RFKILL support. João, > correct me if I'm mistaken. > That was true at the time of this message, but the RFKill infrastructure that I was planning to use here is

Re: [PATCH 2/5] asus-wmi: Create quirk for airplane_mode LED

On 25 May 2016 at 17:24, Darren Hart wrote: > (...) > I believe this is all still blocked on the underlying RFKILL support. João, > correct me if I'm mistaken. > That was true at the time of this message, but the RFKill infrastructure that I was planning to use here is not going to be merged.

Re: [PATCH v5 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On Friday, June 10, 2016 06:38:01 PM Sudeep Holla wrote: > Hi Rafael, Hi, > On 11/05/16 16:37, Sudeep Holla wrote: > > ACPI 6.0 introduced an optional object _LPI that provides an alternate > > method to describe Low Power Idle states. It defines the local power > > states for each node in a

[PATCH 1/7] asus-wireless: Toggle airplane mode LED

In the ASHS device we have the HSWC method, which calls either OWGD or OWGS, depending on its parameter: Device (ASHS) { Name (_HID, "ATK4002") // _HID: Hardware ID Method (HSWC, 1, Serialized) { If ((Arg0 <

[PATCH 3/7] asus-wmi: Add quirk_no_rfkill for the Asus N552VW

The Asus N552VW has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

Re: [PATCH] init, fix initcall blacklist for modules

On Mon, Jun 13 2016, Prarit Bhargava wrote: > Sorry ... forgot to cc everyone on the last email. > > P. > > 8< > > sprint_symbol_no_offset() returns the string "function_name [module_name]" > where [module_name] is not printed for built in kernel functions. This >

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > On 13 June 2016 at 15:00, Pavel Machek wrote: > > Hi! > > > >> > João, that means you should send a patch to add the ::rfkill suffix. > >> > > >> > >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it > >>

Re: [PATCH v5 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On Friday, June 10, 2016 06:38:01 PM Sudeep Holla wrote: > Hi Rafael, Hi, > On 11/05/16 16:37, Sudeep Holla wrote: > > ACPI 6.0 introduced an optional object _LPI that provides an alternate > > method to describe Low Power Idle states. It defines the local power > > states for each node in a

[PATCH 1/7] asus-wireless: Toggle airplane mode LED

In the ASHS device we have the HSWC method, which calls either OWGD or OWGS, depending on its parameter: Device (ASHS) { Name (_HID, "ATK4002") // _HID: Hardware ID Method (HSWC, 1, Serialized) { If ((Arg0 <

[PATCH 3/7] asus-wmi: Add quirk_no_rfkill for the Asus N552VW

The Asus N552VW has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

Re: [PATCH] init, fix initcall blacklist for modules

On Mon, Jun 13 2016, Prarit Bhargava wrote: > Sorry ... forgot to cc everyone on the last email. > > P. > > 8< > > sprint_symbol_no_offset() returns the string "function_name [module_name]" > where [module_name] is not printed for built in kernel functions. This > means that the

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > On 13 June 2016 at 15:00, Pavel Machek wrote: > > Hi! > > > >> > João, that means you should send a patch to add the ::rfkill suffix. > >> > > >> > >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it > >> reflects the

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington wrote: > Hi Dongdong, > > On 06/13/2016 09:02 AM, Dongdong Liu wrote: >> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c >> index d3c3e85..49612b3 100644 >> --- a/drivers/acpi/pci_mcfg.c >> +++

[GIT PULL] percpu fixes for v4.7-rc3

Hello, Linus. While adding GFP_ATOMIC support to the percpu allocator, synchronization for fast-path which doesn't require external allocations was separated into pcpu_lock; unfortunately, it incorrectly decoupled async paths and percpu chunks could get destroyed while still being operated on.

[PATCH 6/7] asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF

The Asus X456UF has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH 5/7] asus-wmi: Add quirk_no_rfkill for the Asus Z550MA

The Asus Z550MA has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH 0/7] asus-wireless: LED control

This series adds support for controlling the airplane-mode indicator LED present in some Asus laptops. It also creates a quirk in asus-wmi so it does not create RFKill devices for platforms that use asus-wireless and where there is a competition for the LED control (see "asus-wmi: Create quirk for

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington wrote: > Hi Dongdong, > > On 06/13/2016 09:02 AM, Dongdong Liu wrote: >> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c >> index d3c3e85..49612b3 100644 >> --- a/drivers/acpi/pci_mcfg.c >> +++ b/drivers/acpi/pci_mcfg.c >> @@

[GIT PULL] percpu fixes for v4.7-rc3

Hello, Linus. While adding GFP_ATOMIC support to the percpu allocator, synchronization for fast-path which doesn't require external allocations was separated into pcpu_lock; unfortunately, it incorrectly decoupled async paths and percpu chunks could get destroyed while still being operated on.

[PATCH 6/7] asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UF

The Asus X456UF has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH 5/7] asus-wmi: Add quirk_no_rfkill for the Asus Z550MA

The Asus Z550MA has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH 0/7] asus-wireless: LED control

This series adds support for controlling the airplane-mode indicator LED present in some Asus laptops. It also creates a quirk in asus-wmi so it does not create RFKill devices for platforms that use asus-wireless and where there is a competition for the LED control (see "asus-wmi: Create quirk for

[PATCH 2/7] asus-wmi: Create quirk for airplane_mode LED

Some Asus laptops that have an airplane-mode indicator LED, also have the WMI WLAN user bit set, and the following bits in their DSDT: Scope (_SB) { (...) Device (ATKD) { (...) Method (WMNB, 3, Serialized) { (...) If (LEqual (IIA0, 0x00010002)) { OWGD

[PATCH v8 3/5] skb_array: array based FIFO for skbs

A simple array based FIFO of pointers. Intended for net stack so uses skbs for type safety. Implemented as a set of wrappers around ptr_ring. Signed-off-by: Michael S. Tsirkin --- include/linux/skb_array.h | 144 ++ 1 file changed,

[PATCH 7/7] asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UA

The Asus X456UA has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

[PATCH 2/7] asus-wmi: Create quirk for airplane_mode LED

Some Asus laptops that have an airplane-mode indicator LED, also have the WMI WLAN user bit set, and the following bits in their DSDT: Scope (_SB) { (...) Device (ATKD) { (...) Method (WMNB, 3, Serialized) { (...) If (LEqual (IIA0, 0x00010002)) { OWGD

[PATCH v8 3/5] skb_array: array based FIFO for skbs

A simple array based FIFO of pointers. Intended for net stack so uses skbs for type safety. Implemented as a set of wrappers around ptr_ring. Signed-off-by: Michael S. Tsirkin --- include/linux/skb_array.h | 144 ++ 1 file changed, 144 insertions(+)

[PATCH 7/7] asus-wmi: Add quirk_no_rfkill_wapf4 for the Asus X456UA

The Asus X456UA has an airplane-mode indicator LED and the WMI WLAN user bit set, so asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, which has a side-effect of driving the airplane mode indicator LED in an inverted fashion. quirk_no_rfkill prevents asus-wmi from

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