[PATCH 5/7] staging: rtl8723bs: Fix pointer style

Fix "(foo*)" should be "(foo *)" Fix "foo * bar" should be "foo *bar" Signed-off-by: Justin Vreeland --- drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c

[PATCH 5/7] staging: rtl8723bs: Fix pointer style

Fix "(foo*)" should be "(foo *)" Fix "foo * bar" should be "foo *bar" Signed-off-by: Justin Vreeland --- drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c

[PATCH 0/7] staging: rtl8732: Various checkpatch fixes

Justin Vreeland (7): staging: rtl8723bs: Fix initialization of static variables staging: rtl8723bs: Wrap multi-line macros in do-while loop staging: rtl8723bs: Macros with complex values should be enclosed in parentheses staging: rtl8723bs: Move braces to same line as conditional

[PATCH 0/7] staging: rtl8732: Various checkpatch fixes

Justin Vreeland (7): staging: rtl8723bs: Fix initialization of static variables staging: rtl8723bs: Wrap multi-line macros in do-while loop staging: rtl8723bs: Macros with complex values should be enclosed in parentheses staging: rtl8723bs: Move braces to same line as conditional

Re: [PATCH 2/7] staging: rtl8723bs: Wrap multi-line macros in do-while loop

On 04/27/2017 07:09 PM, Justin Vreeland wrote: Signed-off-by: Justin Vreeland --- The patch is OK, but most maintainers require a non-blank commit message. Larry drivers/staging/rtl8723bs/hal/odm_debug.h | 80 +-- 1 file changed, 44

Re: [PATCH 2/7] staging: rtl8723bs: Wrap multi-line macros in do-while loop

On 04/27/2017 07:09 PM, Justin Vreeland wrote: Signed-off-by: Justin Vreeland --- The patch is OK, but most maintainers require a non-blank commit message. Larry drivers/staging/rtl8723bs/hal/odm_debug.h | 80 +-- 1 file changed, 44 insertions(+), 36

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

Hi Dmitry, On Thu, Apr 27, 2017 at 04:56:45PM -0700, Dmitry Torokhov wrote: > On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote: > > On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote: > > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote: > > > > +static

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

Hi Dmitry, On Thu, Apr 27, 2017 at 04:56:45PM -0700, Dmitry Torokhov wrote: > On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote: > > On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote: > > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote: > > > > +static

Re: [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

On 27/04/17 23:49, Sakari Ailus wrote: > Hi Kieran, > > On Thu, Apr 27, 2017 at 11:13:50PM +0100, Kieran Bingham wrote: >> Hi Sakari, >> >> Thanks for taking a look > > Sure! :-) > >> >> On 27/04/17 22:43, Sakari Ailus wrote: >>> Hi Kieran, >>> >>> Could I ask you to rebase your patches on top

Re: [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

On 27/04/17 23:49, Sakari Ailus wrote: > Hi Kieran, > > On Thu, Apr 27, 2017 at 11:13:50PM +0100, Kieran Bingham wrote: >> Hi Sakari, >> >> Thanks for taking a look > > Sure! :-) > >> >> On 27/04/17 22:43, Sakari Ailus wrote: >>> Hi Kieran, >>> >>> Could I ask you to rebase your patches on top

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote: > Hi Dmitry, > > On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote: > > > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote: > > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev) > > > +{ > > > +

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote: > Hi Dmitry, > > On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote: > > > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote: > > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev) > > > +{ > > > +

Re: [PATCH v3 0/4] Improved seccomp logging

On Thu, Apr 27, 2017 at 3:17 PM, Tyler Hicks wrote: > Quick update... I finished the move from the high-water mark > log_max_action sysctl to the bitmask based actions_logged sysctl. Awesome! > Unfortunately, I've just realized that SECCOMP_SET_LOGGING, or any >

Re: [PATCH v3 0/4] Improved seccomp logging

On Thu, Apr 27, 2017 at 3:17 PM, Tyler Hicks wrote: > Quick update... I finished the move from the high-water mark > log_max_action sysctl to the bitmask based actions_logged sysctl. Awesome! > Unfortunately, I've just realized that SECCOMP_SET_LOGGING, or any > process-wide logging

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

Hi Dmitry, On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote: > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote: > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev) > > +{ > > + struct stmfts_data *sdata = dev; > > + int ret; > > + > > +

Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen

Hi Dmitry, On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote: > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote: > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev) > > +{ > > + struct stmfts_data *sdata = dev; > > + int ret; > > + > > +

Re: Boot regression caused by kauditd

On Thu, Apr 27, 2017 at 3:38 PM, Paul Moore wrote: > On Thu, Apr 27, 2017 at 5:45 PM, Cong Wang wrote: >> On Thu, Apr 27, 2017 at 2:35 PM, Cong Wang wrote: >>> On Thu, Apr 27, 2017 at 1:31 PM, Cong Wang

Re: Boot regression caused by kauditd

On Thu, Apr 27, 2017 at 3:38 PM, Paul Moore wrote: > On Thu, Apr 27, 2017 at 5:45 PM, Cong Wang wrote: >> On Thu, Apr 27, 2017 at 2:35 PM, Cong Wang wrote: >>> On Thu, Apr 27, 2017 at 1:31 PM, Cong Wang wrote: On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore wrote: > Thanks for the

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 05:20 PM, Jason Gunthorpe wrote: > It seems the most robust: test for iomem, and jump to a slow path > copy, otherwise inline the kmap and memcpy > > Every place doing memcpy from sgl will need that pattern to be > correct. Ok, sounds like a good place to start to me. I'll see what

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 05:20 PM, Jason Gunthorpe wrote: > It seems the most robust: test for iomem, and jump to a slow path > copy, otherwise inline the kmap and memcpy > > Every place doing memcpy from sgl will need that pattern to be > correct. Ok, sounds like a good place to start to me. I'll see what

[PATCH] ion: Fixed initialization of static variable to 0

From: Fabrizio Signed-off-by: Fabrizio --- drivers/staging/android/ion/ion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index fb836c6..03d3a4f

[PATCH] ion: Fixed initialization of static variable to 0

From: Fabrizio Signed-off-by: Fabrizio --- drivers/staging/android/ion/ion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index fb836c6..03d3a4f 100644 --- a/drivers/staging/android/ion/ion.c +++

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote: > > > On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > > Well, that is in the current form, with more users it would make sense > > to optimize for the single page

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote: > > > On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > > Well, that is in the current form, with more users it would make sense > > to optimize for the single page

[PATCH] pstore: Solve lockdep warning by moving inode locks

Lockdep complains about a possible deadlock between mount and unlink (which is technically impossible), but fixing this improves possible future multiple-backend support, and keeps locking in the right order. The lockdep warning could be triggered by unlinking a file in the pstore filesystem:

[PATCH] pstore: Solve lockdep warning by moving inode locks

Lockdep complains about a possible deadlock between mount and unlink (which is technically impossible), but fixing this improves possible future multiple-backend support, and keeps locking in the right order. The lockdep warning could be triggered by unlinking a file in the pstore filesystem:

Re: [PATCH] block: hide badblocks attribute by default

On Thu, 2017-04-27 at 14:46 -0700, Dan Williams wrote: > Commit 99e6608c9e74 "block: Add badblock management for gendisks" > allowed for drivers like pmem and software-raid to advertise a list of > bad media areas. However, it inadvertently added a 'badblocks' to all > block devices. Lets clean

Re: [PATCH] block: hide badblocks attribute by default

On Thu, 2017-04-27 at 14:46 -0700, Dan Williams wrote: > Commit 99e6608c9e74 "block: Add badblock management for gendisks" > allowed for drivers like pmem and software-raid to advertise a list of > bad media areas. However, it inadvertently added a 'badblocks' to all > block devices. Lets clean

Re: [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs

On 17-04-27 02:23 PM, Jon Mason wrote: Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows the ns-thermal driver to be selected via menuconfig. Signed-off-by: Jon Mason --- arch/arm/mach-bcm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff

Re: [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs

On 17-04-27 02:23 PM, Jon Mason wrote: Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows the ns-thermal driver to be selected via menuconfig. Signed-off-by: Jon Mason --- arch/arm/mach-bcm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: 4.11-rc8 makes my Dell Inspiron 5558 crash

On Thu, Apr 27, 2017 at 7:56 PM, Diego Viola wrote: > Hello, > > For some reason 4.11-rc8 makes my Dell Inspiron 5558 crash. The > problem is very random and I don't know how to reproduce it. > > That said, this only started happening with 4.11-rc8 and I've been > using

Re: 4.11-rc8 makes my Dell Inspiron 5558 crash

On Thu, Apr 27, 2017 at 7:56 PM, Diego Viola wrote: > Hello, > > For some reason 4.11-rc8 makes my Dell Inspiron 5558 crash. The > problem is very random and I don't know how to reproduce it. > > That said, this only started happening with 4.11-rc8 and I've been > using 4.11 since rc3 and it

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > Well, that is in the current form, with more users it would make sense > to optimize for the single page case, eg by providing the existing > call, providing a faster

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > Well, that is in the current form, with more users it would make sense > to optimize for the single page case, eg by providing the existing > call, providing a faster

[PATCH] fs/block_dev: Add prototype and __printf verification to __vfs_msg

__vfs_msg currently has no prototype and takes a format and arguments. Add a prototype to include/linux/blkdev.h with __printf verification and fix fallout. Miscellanea: o Rename prefix argument to level as that's the common usage for KERN_ uses o Remove the unnecessary __vfs_msg call in the

[PATCH] fs/block_dev: Add prototype and __printf verification to __vfs_msg

__vfs_msg currently has no prototype and takes a format and arguments. Add a prototype to include/linux/blkdev.h with __printf verification and fix fallout. Miscellanea: o Rename prefix argument to level as that's the common usage for KERN_ uses o Remove the unnecessary __vfs_msg call in the

[PATCH] drivers: staging: lustre: lustre: llite: file.c - fixed sparse warning about different fmode_t type

fixed a couple of sparse warning complaining about type mismatch. Signed-off-by: Andrea della Porta --- drivers/staging/lustre/lustre/include/lustre_intent.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drivers: staging: lustre: lustre: llite: file.c - fixed sparse warning about different fmode_t type

fixed a couple of sparse warning complaining about type mismatch. Signed-off-by: Andrea della Porta --- drivers/staging/lustre/lustre/include/lustre_intent.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/include/lustre_intent.h

[PATCH 1/2] libnvdimm: fix clear length of nvdimm_forget_poison()

ND_CMD_CLEAR_ERROR command returns 'clear_err.cleared', the length of error actually cleared, which may be smaller than its requested 'len'. Change nvdimm_clear_poison() to call nvdimm_forget_poison() with 'clear_err.cleared' when this value is valid. Signed-off-by: Toshi Kani

[PATCH 1/2] libnvdimm: fix clear length of nvdimm_forget_poison()

ND_CMD_CLEAR_ERROR command returns 'clear_err.cleared', the length of error actually cleared, which may be smaller than its requested 'len'. Change nvdimm_clear_poison() to call nvdimm_forget_poison() with 'clear_err.cleared' when this value is valid. Signed-off-by: Toshi Kani Cc: Dan Williams

[PATCH 2/2] libnvdimm: clear region badblock in nvdimm_clear_poison()

Badblocks are tracked at both region and device levels. pmem_clear_poison() and nsio_rw_bytes() call nvdimm_clear_poison() and then badblocks_clear() to clear badblocks at the device level. However, it does not update badblocks at the region level, which makes them inconsistent. Change

[PATCH 2/2] libnvdimm: clear region badblock in nvdimm_clear_poison()

Badblocks are tracked at both region and device levels. pmem_clear_poison() and nsio_rw_bytes() call nvdimm_clear_poison() and then badblocks_clear() to clear badblocks at the device level. However, it does not update badblocks at the region level, which makes them inconsistent. Change

4.11-rc8 makes my Dell Inspiron 5558 crash

Hello, For some reason 4.11-rc8 makes my Dell Inspiron 5558 crash. The problem is very random and I don't know how to reproduce it. That said, this only started happening with 4.11-rc8 and I've been using 4.11 since rc3 and it didn't happen at all with the previous RCs. Not sure how I could

4.11-rc8 makes my Dell Inspiron 5558 crash

Hello, For some reason 4.11-rc8 makes my Dell Inspiron 5558 crash. The problem is very random and I don't know how to reproduce it. That said, this only started happening with 4.11-rc8 and I've been using 4.11 since rc3 and it didn't happen at all with the previous RCs. Not sure how I could

Re: [PATCH v2] arm64: Add ASM modifier for xN register operands

Hi Mark, Thanks for your comments. El Thu, Apr 27, 2017 at 12:02:56PM +0100 Mark Rutland ha dit: > Hi, > > On Wed, Apr 26, 2017 at 02:46:16PM -0700, Matthias Kaehlcke wrote: > > Many inline assembly statements don't include the 'x' modifier when > > using xN registers as operands. This is

Re: [PATCH v2] arm64: Add ASM modifier for xN register operands

Hi Mark, Thanks for your comments. El Thu, Apr 27, 2017 at 12:02:56PM +0100 Mark Rutland ha dit: > Hi, > > On Wed, Apr 26, 2017 at 02:46:16PM -0700, Matthias Kaehlcke wrote: > > Many inline assembly statements don't include the 'x' modifier when > > using xN registers as operands. This is

Re: [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

Hi Kieran, On Thu, Apr 27, 2017 at 11:13:50PM +0100, Kieran Bingham wrote: > Hi Sakari, > > Thanks for taking a look Sure! :-) > > On 27/04/17 22:43, Sakari Ailus wrote: > > Hi Kieran, > > > > Could I ask you to rebase your patches on top of my V4L2 fwnode patches > > here? > > > >

Re: [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

Hi Kieran, On Thu, Apr 27, 2017 at 11:13:50PM +0100, Kieran Bingham wrote: > Hi Sakari, > > Thanks for taking a look Sure! :-) > > On 27/04/17 22:43, Sakari Ailus wrote: > > Hi Kieran, > > > > Could I ask you to rebase your patches on top of my V4L2 fwnode patches > > here? > > > >

Re: [v6 PATCH 03/21] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

On Wed, 2017-04-26 at 10:05 +0200, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 07:04:20PM -0700, Ricardo Neri wrote: > > For the specific case of ModRM.mod being 0, I feel I need to clarify > > that REX.B is not decoded and if SIB.base is %r13 the base is also 0. > > Well, that all doesn't

Re: [v6 PATCH 03/21] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

On Wed, 2017-04-26 at 10:05 +0200, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 07:04:20PM -0700, Ricardo Neri wrote: > > For the specific case of ModRM.mod being 0, I feel I need to clarify > > that REX.B is not decoded and if SIB.base is %r13 the base is also 0. > > Well, that all doesn't

Re: [PATCH] um: Fix to call read_initrd after init_bootmem

Masami, Am 28.04.2017 um 00:40 schrieb Masami Hiramatsu: > Finally, git bisect shows that below commit caused this issue. > > b63236972e1344b247750451e2be0a06cd125f21 is the first bad commit > commit b63236972e1344b247750451e2be0a06cd125f21 > Author: Richard Weinberger Meh,

Re: [PATCH] um: Fix to call read_initrd after init_bootmem

Masami, Am 28.04.2017 um 00:40 schrieb Masami Hiramatsu: > Finally, git bisect shows that below commit caused this issue. > > b63236972e1344b247750451e2be0a06cd125f21 is the first bad commit > commit b63236972e1344b247750451e2be0a06cd125f21 > Author: Richard Weinberger Meh, it's always me. ;-)

Re: [PATCH] um: Fix to call read_initrd after init_bootmem

On Fri, 28 Apr 2017 07:04:14 +0900 Masami Hiramatsu wrote: > Hi Richard, > > On Thu, 27 Apr 2017 15:53:25 +0200 > Richard Weinberger wrote: > > > Masami, > > > > Am 27.04.2017 um 05:15 schrieb Masami Hiramatsu: > > > Since read_initrd() invokes

Re: [PATCH] um: Fix to call read_initrd after init_bootmem

On Fri, 28 Apr 2017 07:04:14 +0900 Masami Hiramatsu wrote: > Hi Richard, > > On Thu, 27 Apr 2017 15:53:25 +0200 > Richard Weinberger wrote: > > > Masami, > > > > Am 27.04.2017 um 05:15 schrieb Masami Hiramatsu: > > > Since read_initrd() invokes alloc_bootmem() for allocating > > > memory to

Re: Boot regression caused by kauditd

On Thu, Apr 27, 2017 at 5:45 PM, Cong Wang wrote: > On Thu, Apr 27, 2017 at 2:35 PM, Cong Wang wrote: >> On Thu, Apr 27, 2017 at 1:31 PM, Cong Wang wrote: >>> On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore

Re: Boot regression caused by kauditd

On Thu, Apr 27, 2017 at 5:45 PM, Cong Wang wrote: > On Thu, Apr 27, 2017 at 2:35 PM, Cong Wang wrote: >> On Thu, Apr 27, 2017 at 1:31 PM, Cong Wang wrote: >>> On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore wrote: Thanks for the report, this is the only one like it that I've seen. I'm

Re: [PATCH v2 2/2] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support.

On Thursday, April 27, 2017 04:22:50 PM Lv Zheng wrote: > This patch adds balanced acpi_get_table()/acpi_put_table() support for > sysfs table dumping code so that no need to call > acpi_get_validated_table(). > > Since ACPICA does not use all of the tables, this can help to reduce some > usless

Re: [PATCH v2 2/2] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support.

On Thursday, April 27, 2017 04:22:50 PM Lv Zheng wrote: > This patch adds balanced acpi_get_table()/acpi_put_table() support for > sysfs table dumping code so that no need to call > acpi_get_validated_table(). > > Since ACPICA does not use all of the tables, this can help to reduce some > usless

Re: [PATCH] ASoC: Intel: Skylake: use dev in dev_err rather than skl pointer

Hi, On Apr 28 2017 00:13, Colin King wrote: > From: Colin Ian King > > The dev_err message is dereferencing an uininitialized skl pointer > which should be avoided. Don't use skl, use dev instead. > > Detected by CoverityScan, CID#1432042 ("Uninitialized pointer

Re: [PATCH] ASoC: Intel: Skylake: use dev in dev_err rather than skl pointer

Hi, On Apr 28 2017 00:13, Colin King wrote: > From: Colin Ian King > > The dev_err message is dereferencing an uininitialized skl pointer > which should be avoided. Don't use skl, use dev instead. > > Detected by CoverityScan, CID#1432042 ("Uninitialized pointer read") > > Fixes:

Re: [PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

On Thursday, April 27, 2017 04:22:44 PM Lv Zheng wrote: > In the Linux kernel side, acpi_get_table() clones haven't been fully > balanced by acpi_put_table() invocations. In ACPICA side, due to the design > change, there are also unbalanced acpi_get_table_by_index() invocations > requiring special

Re: [PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

On Thursday, April 27, 2017 04:22:44 PM Lv Zheng wrote: > In the Linux kernel side, acpi_get_table() clones haven't been fully > balanced by acpi_put_table() invocations. In ACPICA side, due to the design > change, there are also unbalanced acpi_get_table_by_index() invocations > requiring special

Re: [PATCH 3/5] ACPI / sleep: EC-based wakeup from suspend-to-idle on Dell systems

On Thursday, April 27, 2017 02:47:59 PM mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > Sent: Wednesday, April 26, 2017 4:24 PM > > To: Linux PM > > Cc: Andy Shevchenko

Re: [PATCH 3/5] ACPI / sleep: EC-based wakeup from suspend-to-idle on Dell systems

On Thursday, April 27, 2017 02:47:59 PM mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > Sent: Wednesday, April 26, 2017 4:24 PM > > To: Linux PM > > Cc: Andy Shevchenko ; Darren Hart > > ; LKML ; Linux ACPI > > >

Re: ipsec doesn't route TCP with 4.11 kernel

On 26 April 2017 at 15:06, Joseph Salisbury wrote: > Hi Don, > > Can you see if this bug started happening in v4.11-rc3? Since your > running Ubuntu, a kernel is already available here: > http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc3/ It appears I was

Re: ipsec doesn't route TCP with 4.11 kernel

On 26 April 2017 at 15:06, Joseph Salisbury wrote: > Hi Don, > > Can you see if this bug started happening in v4.11-rc3? Since your > running Ubuntu, a kernel is already available here: > http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc3/ It appears I was incorrect about where this was

Re: [PATCH] libnvdimm, pmem: fix badblocks notification crash

On Thu, 2017-04-27 at 15:26 -0700, Dan Williams wrote: > On Thu, Apr 27, 2017 at 3:25 PM, Kani, Toshimitsu > wrote: > > On Thu, 2017-04-27 at 15:10 -0700, Dan Williams wrote: > > > The nd_pmem_notify() routine is called whenever an ARS > > > (address-range-scrub) completes to

Re: [PATCH] libnvdimm, pmem: fix badblocks notification crash

On Thu, 2017-04-27 at 15:26 -0700, Dan Williams wrote: > On Thu, Apr 27, 2017 at 3:25 PM, Kani, Toshimitsu > wrote: > > On Thu, 2017-04-27 at 15:10 -0700, Dan Williams wrote: > > > The nd_pmem_notify() routine is called whenever an ARS > > > (address-range-scrub) completes to communicate results

Re: [PATCH] libnvdimm, pmem: fix badblocks notification crash

On Thu, Apr 27, 2017 at 3:25 PM, Kani, Toshimitsu wrote: > On Thu, 2017-04-27 at 15:10 -0700, Dan Williams wrote: >> The nd_pmem_notify() routine is called whenever an ARS >> (address-range-scrub) completes to communicate results to the >> per-namespace badblocks instances. >>

Re: [PATCH] libnvdimm, pmem: fix badblocks notification crash

On Thu, Apr 27, 2017 at 3:25 PM, Kani, Toshimitsu wrote: > On Thu, 2017-04-27 at 15:10 -0700, Dan Williams wrote: >> The nd_pmem_notify() routine is called whenever an ARS >> (address-range-scrub) completes to communicate results to the >> per-namespace badblocks instances. >> >> When the

Re: [PATCH v4 2/2] of: Add unit tests for applying overlays

On Tue, Apr 25, 2017 at 05:09:54PM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Existing overlay unit tests examine individual pieces of the overlay > code. The new tests target the entire process of applying an overlay. > > Signed-off-by: Frank Rowand

Re: [PATCH v4 2/2] of: Add unit tests for applying overlays

On Tue, Apr 25, 2017 at 05:09:54PM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Existing overlay unit tests examine individual pieces of the overlay > code. The new tests target the entire process of applying an overlay. > > Signed-off-by: Frank Rowand > --- > > There are

Re: [PATCH] libnvdimm, pmem: fix badblocks notification crash

On Thu, 2017-04-27 at 15:10 -0700, Dan Williams wrote: > The nd_pmem_notify() routine is called whenever an ARS > (address-range-scrub) completes to communicate results to the > per-namespace badblocks instances. > > When the namespace is in btt mode we crash because we do not allocate > a struct

Re: [PATCH] libnvdimm, pmem: fix badblocks notification crash

On Thu, 2017-04-27 at 15:10 -0700, Dan Williams wrote: > The nd_pmem_notify() routine is called whenever an ARS > (address-range-scrub) completes to communicate results to the > per-namespace badblocks instances. > > When the namespace is in btt mode we crash because we do not allocate > a struct

Re: [PATCH v4 1/2] of: per-file dtc compiler flags

On Tue, Apr 25, 2017 at 05:09:53PM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The dtc compiler version that adds initial support was available > in 4.11-rc1. Add the ability to set an additional dtc compiler > flag is needed by overlays. > >

Re: [PATCH v4 1/2] of: per-file dtc compiler flags

On Tue, Apr 25, 2017 at 05:09:53PM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The dtc compiler version that adds initial support was available > in 4.11-rc1. Add the ability to set an additional dtc compiler > flag is needed by overlays. > > Signed-off-by: Frank Rowand >

[PATCH v5] libnvdimm, region: sysfs trigger for nvdimm_flush()

The nvdimm_flush() mechanism helps to reduce the impact of an ADR (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing platform WPQ (write-pending-queue) buffers when power is removed. The nvdimm_flush() mechanism performs that same function on-demand. When a pmem namespace is

[PATCH v5] libnvdimm, region: sysfs trigger for nvdimm_flush()

The nvdimm_flush() mechanism helps to reduce the impact of an ADR (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing platform WPQ (write-pending-queue) buffers when power is removed. The nvdimm_flush() mechanism performs that same function on-demand. When a pmem namespace is

Re: [PATCH v3 0/4] Improved seccomp logging

On 04/10/2017 10:59 PM, Kees Cook wrote: > On Fri, Apr 7, 2017 at 4:46 PM, Tyler Hicks wrote: >> On 04/07/2017 05:46 PM, Kees Cook wrote: >>> Does the app-controlled bitmask apply to the filter, the process, the >>> process tree, or something else? e.g. systemd launches an

Re: [PATCH v3 0/4] Improved seccomp logging

On 04/10/2017 10:59 PM, Kees Cook wrote: > On Fri, Apr 7, 2017 at 4:46 PM, Tyler Hicks wrote: >> On 04/07/2017 05:46 PM, Kees Cook wrote: >>> Does the app-controlled bitmask apply to the filter, the process, the >>> process tree, or something else? e.g. systemd launches an app with a >>> filter,

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

[PATCH] libnvdimm, pmem: fix badblocks notification crash

The nd_pmem_notify() routine is called whenever an ARS (address-range-scrub) completes to communicate results to the per-namespace badblocks instances. When the namespace is in btt mode we crash because we do not allocate a struct pmem_device instance in that case. Resulting in the following

[PATCH] libnvdimm, pmem: fix badblocks notification crash

The nd_pmem_notify() routine is called whenever an ARS (address-range-scrub) completes to communicate results to the per-namespace badblocks instances. When the namespace is in btt mode we crash because we do not allocate a struct pmem_device instance in that case. Resulting in the following

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly()

27.04.2017 19:08, Andy Lutomirski пишет: Those should probably be pgd_none(), not pgd_none_or_clear_bad(). But this whole function is just garbage. It mucks with page protections without even looking up the VMA. What happens if the pages are file-backed? How about chardevs? I'd like to

Re: ipsec doesn't route TCP with 4.11 kernel

On 27 April 2017 at 04:42, Steffen Klassert wrote: > On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote: >> (Cc'ing netdev and IPSec maintainers) >> >> On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman wrote: for 'esp' question, i have ' esp =

Re: ipsec doesn't route TCP with 4.11 kernel

On 27 April 2017 at 04:42, Steffen Klassert wrote: > On Wed, Apr 26, 2017 at 10:01:34PM -0700, Cong Wang wrote: >> (Cc'ing netdev and IPSec maintainers) >> >> On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman wrote: for 'esp' question, i have ' esp = aes256-sha256-modp1536!' is that what you mean?

Re: [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

Hi Sakari, Thanks for taking a look On 27/04/17 22:43, Sakari Ailus wrote: > Hi Kieran, > > Could I ask you to rebase your patches on top of my V4L2 fwnode patches > here? > > > > It depends on the fwnode graph patches,

Re: [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous subdevs

Hi Sakari, Thanks for taking a look On 27/04/17 22:43, Sakari Ailus wrote: > Hi Kieran, > > Could I ask you to rebase your patches on top of my V4L2 fwnode patches > here? > > https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi> > > It depends on the fwnode graph patches, merged

Re: [PATCH 6/6] ima: Support appended signatures for appraisal

> On Apr 27, 2017, at 5:41 PM, Thiago Jung Bauermann > wrote: > > Am Mittwoch, 26. April 2017, 18:18:34 BRT schrieb Mehmet Kayaalp: >>> On Apr 20, 2017, at 7:41 PM, Thiago Jung Bauermann >>> wrote: >>> >>> This patch introduces the

Re: [PATCH 6/6] ima: Support appended signatures for appraisal

> On Apr 27, 2017, at 5:41 PM, Thiago Jung Bauermann > wrote: > > Am Mittwoch, 26. April 2017, 18:18:34 BRT schrieb Mehmet Kayaalp: >>> On Apr 20, 2017, at 7:41 PM, Thiago Jung Bauermann >>> wrote: >>> >>> This patch introduces the appended_imasig keyword to the IMA policy syntax >>> to

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > > blkfront is one of the drivers I looked at, and it appears to only be > > memcpying with the bvec_data pointer, so I wonder why it does not use > > sg_copy_X_buffer instead.. > >

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > > blkfront is one of the drivers I looked at, and it appears to only be > > memcpying with the bvec_data pointer, so I wonder why it does not use > > sg_copy_X_buffer instead.. > >

[PATCH] perf report: distinguish between inliners in the same function

When different functions get inlined into the same function, we want to show them individually in the reports. But when we group by function, we would aggregate all IPs and would only keep the first one in that function. E.g. for C++ code like the following: ~ #include #include #include

[PATCH] perf report: distinguish between inliners in the same function

When different functions get inlined into the same function, we want to show them individually in the reports. But when we group by function, we would aggregate all IPs and would only keep the first one in that function. E.g. for C++ code like the following: ~ #include #include #include

Re: [PATCH] um: Fix to call read_initrd after init_bootmem

Hi Richard, On Thu, 27 Apr 2017 15:53:25 +0200 Richard Weinberger wrote: > Masami, > > Am 27.04.2017 um 05:15 schrieb Masami Hiramatsu: > > Since read_initrd() invokes alloc_bootmem() for allocating > > memory to load initrd image, it must be called after init_bootmem. > > > >

Re: [PATCH] um: Fix to call read_initrd after init_bootmem

Hi Richard, On Thu, 27 Apr 2017 15:53:25 +0200 Richard Weinberger wrote: > Masami, > > Am 27.04.2017 um 05:15 schrieb Masami Hiramatsu: > > Since read_initrd() invokes alloc_bootmem() for allocating > > memory to load initrd image, it must be called after init_bootmem. > > > > This makes

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

Am 24.04.2017 um 17:47 schrieb Richard Weinberger: >> So, if some flag should be implemented, who should do it? :) > > I'll not do it for you. ;) Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2 Thanks, //richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

Am 24.04.2017 um 17:47 schrieb Richard Weinberger: >> So, if some flag should be implemented, who should do it? :) > > I'll not do it for you. ;) Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2 Thanks, //richard

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