Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

Hi Michal, On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote: > The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over > 1MHz SPI bus takes way longer than that. Calculate the timeout from the > actual time the transfer is supposed to take and multiply by 2

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

Hi Michal, On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek wrote: > The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over > 1MHz SPI bus takes way longer than that. Calculate the timeout from the > actual time the transfer is supposed to take and multiply by 2 for good > measure.

Re: [GIT PULL] xfs: updates for 4.7-rc1

On Thu, May 26, 2016 at 5:13 PM, Dave Chinner wrote: > On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote: >> >> i'm ok with the late branches, it's not like xfs has been a problem spot. > > Still, I'll try to avoid them because it reduces testing time. Oh, 100%

Re: [GIT PULL] xfs: updates for 4.7-rc1

On Thu, May 26, 2016 at 5:13 PM, Dave Chinner wrote: > On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote: >> >> i'm ok with the late branches, it's not like xfs has been a problem spot. > > Still, I'll try to avoid them because it reduces testing time. Oh, 100% agreed. I'm just

[PATCH] serial: 8250_fintek: fix the mismatched IRQ mode

Some BIOS only use _OSI("Linux") to distinguish between Linux & Windows. Apply Level/Low to UART trigger mode if Windows, Edge/High mode otherwise. But since 2.6.23 the mainline kernel no longer returns true for _OSI(“Linux”). The default IRQ0~15 trigger mode in Linux is Edge/High mode without

[PATCH] serial: 8250_fintek: fix the mismatched IRQ mode

Some BIOS only use _OSI("Linux") to distinguish between Linux & Windows. Apply Level/Low to UART trigger mode if Windows, Edge/High mode otherwise. But since 2.6.23 the mainline kernel no longer returns true for _OSI(“Linux”). The default IRQ0~15 trigger mode in Linux is Edge/High mode without

Re: [PATCH v3 5/6] mm/cma: remove MIGRATE_CMA

Hi Joonsoo, On 2016/5/26 14:22, js1...@gmail.com wrote: > From: Joonsoo Kim > > Now, all reserved pages for CMA region are belong to the ZONE_CMA > and there is no other type of pages. Therefore, we don't need to > use MIGRATE_CMA to distinguish and handle differently

Re: [PATCH v3 5/6] mm/cma: remove MIGRATE_CMA

Hi Joonsoo, On 2016/5/26 14:22, js1...@gmail.com wrote: > From: Joonsoo Kim > > Now, all reserved pages for CMA region are belong to the ZONE_CMA > and there is no other type of pages. Therefore, we don't need to > use MIGRATE_CMA to distinguish and handle differently for CMA pages > and

[PATCH 1/2 v2] staging: dgnc: remove redundant NULL check for brd

the "brd" value cannot be NULL in dgnc_finalize_board_init(). Because "brd" as a parameter of this function was already checked for NULL. the dgnc_finalize_board_init() as a static function was called only from dgnc_found_board() function and brd->magic value was assigned once in

[PATCH 1/2 v2] staging: dgnc: remove redundant NULL check for brd

the "brd" value cannot be NULL in dgnc_finalize_board_init(). Because "brd" as a parameter of this function was already checked for NULL. the dgnc_finalize_board_init() as a static function was called only from dgnc_found_board() function and brd->magic value was assigned once in

[PATCH 2/2 V2] staging: dgnc: remove redundant null check in

the "brd" was already checked for NULL before calling dgnc_do_remap(). the dgnc_do_remap() function was called only from the dgnc_found_board() and the DGNC_BOARD_MAGIC value was assigned to "brd->magic" in dgcn_found_board(). So it doesn't need to check about magic value. Signed-off-by: Daeseok

[PATCH 2/2 V2] staging: dgnc: remove redundant null check in

the "brd" was already checked for NULL before calling dgnc_do_remap(). the dgnc_do_remap() function was called only from the dgnc_found_board() and the DGNC_BOARD_MAGIC value was assigned to "brd->magic" in dgcn_found_board(). So it doesn't need to check about magic value. Signed-off-by: Daeseok

[PATCH] usb: core: fix a double free in the usb driver

There is a double free problem in the usb driver. This is caused by delayed deregister for scsi device. <*> at Insert USB Storage - USB bus #1 register usb_create_hcd (primary-kref==1) * primary-bandwidth_mutex(alloc)) usb_get_hcd(primary-kref==2) - USB bus #2 register

[PATCH] usb: core: fix a double free in the usb driver

There is a double free problem in the usb driver. This is caused by delayed deregister for scsi device. <*> at Insert USB Storage - USB bus #1 register usb_create_hcd (primary-kref==1) * primary-bandwidth_mutex(alloc)) usb_get_hcd(primary-kref==2) - USB bus #2 register

Re: [PATCH] Use the correct size to set block max sectors

dOn Thu, 2016-05-26 at 17:08 -0700, Long Li wrote: > The block sector size should be in unit of 512 bytes, not in bytes. Thanks. The patch subject should use something like: [PATCH] sd: Use the correct size to set block max sectors to show what subsystem is being modified. > diff --git

Re: [PATCH] Use the correct size to set block max sectors

dOn Thu, 2016-05-26 at 17:08 -0700, Long Li wrote: > The block sector size should be in unit of 512 bytes, not in bytes. Thanks. The patch subject should use something like: [PATCH] sd: Use the correct size to set block max sectors to show what subsystem is being modified. > diff --git

Re: [PATCH 1/2] staging: dgnc: remove redundant NULL check for brd

2016-05-26 21:29 GMT+09:00 Luis de Bethencourt : > On 26/05/16 05:56, DaeSeok Youn wrote: >> 2016-05-26 6:48 GMT+09:00 Luis de Bethencourt : >>> On 20/05/16 10:51, Daeseok Youn wrote: the "brd" value cannot be NULL in dgnc_finalize_board_init().

Re: [PATCH 1/2] staging: dgnc: remove redundant NULL check for brd

2016-05-26 21:29 GMT+09:00 Luis de Bethencourt : > On 26/05/16 05:56, DaeSeok Youn wrote: >> 2016-05-26 6:48 GMT+09:00 Luis de Bethencourt : >>> On 20/05/16 10:51, Daeseok Youn wrote: the "brd" value cannot be NULL in dgnc_finalize_board_init(). Because "brd" as a parameter of this

RE: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces functional after rxvlan off

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jeff Kirsher > Sent: Wednesday, May 18, 2016 2:40 PM > To: Jarod Wilson ; linux-kernel@vger.kernel.org; > Avargil, Raanan > Cc: net...@vger.kernel.org;

RE: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces functional after rxvlan off

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jeff Kirsher > Sent: Wednesday, May 18, 2016 2:40 PM > To: Jarod Wilson ; linux-kernel@vger.kernel.org; > Avargil, Raanan > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org > Subject: Re:

[RFT v3] drm: use late_initcall() for amdkfd and radeon

To get KFD support in radeon we need the following initialization to happen in this order, their respective driver file that has its init routine listed next to it: 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c 1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c 2. AMD KFD:

[RFT v3] drm: use late_initcall() for amdkfd and radeon

To get KFD support in radeon we need the following initialization to happen in this order, their respective driver file that has its init routine listed next to it: 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c 1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c 2. AMD KFD:

Re: [PATCH v3 10/12] spi: add driver for J-Core SPI controller

On Wed, May 25, 2016 at 11:17:08AM +0100, Mark Brown wrote: > On Wed, May 25, 2016 at 05:43:03AM +, Rich Felker wrote: > > > changes based on ml discussion of the v2 patch. The chipselect change > > has not been made yet, except for rewriting the current logic to be > > more clear. If the

Re: [PATCH v3 10/12] spi: add driver for J-Core SPI controller

On Wed, May 25, 2016 at 11:17:08AM +0100, Mark Brown wrote: > On Wed, May 25, 2016 at 05:43:03AM +, Rich Felker wrote: > > > changes based on ml discussion of the v2 patch. The chipselect change > > has not been made yet, except for rewriting the current logic to be > > more clear. If the

Re: [RFC PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

Hi Shawn, On 05/26/2016 12:07 PM, Shawn Lin wrote: > dw_mci_get_cd have already dealed with these for > both of internal card-detect and gpio card-detect. s/dealed/dealt This patch looks good to me. Could you resend the patch? not RFC. Best Regards, Jaehoon Chung > > Signed-off-by: Shawn Lin

Re: [RFC PATCH 2/2] mmc: dw_mmc: check card present before starting request

Hi Shawn, On 05/26/2016 12:08 PM, Shawn Lin wrote: > The main reason to add this check is to avoid unnecessary > mmc_request if the card is removed. Although we have already > check this in dw_mci_handle_cd for runtime usage of sd card and > dw_mci_init_slot for noremovable devices, but there is

Re: [RFC PATCH 1/2] mmc: dw_mmc: remove redundant of set_bit and clear_bit

Hi Shawn, On 05/26/2016 12:07 PM, Shawn Lin wrote: > dw_mci_get_cd have already dealed with these for > both of internal card-detect and gpio card-detect. s/dealed/dealt This patch looks good to me. Could you resend the patch? not RFC. Best Regards, Jaehoon Chung > > Signed-off-by: Shawn Lin

Re: [RFC PATCH 2/2] mmc: dw_mmc: check card present before starting request

Hi Shawn, On 05/26/2016 12:08 PM, Shawn Lin wrote: > The main reason to add this check is to avoid unnecessary > mmc_request if the card is removed. Although we have already > check this in dw_mci_handle_cd for runtime usage of sd card and > dw_mci_init_slot for noremovable devices, but there is

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Mon, Apr 25, 2016 at 12:23:51PM +0200, Joerg Roedel wrote: > On Mon, Apr 18, 2016 at 02:03:50PM +0200, Luis R. Rodriguez wrote: > > You said that with my patch you saw AMD IOMMUv2 kick off first, > > that was intentional as I thought that's what you needed. Can > > someone please describe the

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Mon, Apr 25, 2016 at 12:23:51PM +0200, Joerg Roedel wrote: > On Mon, Apr 18, 2016 at 02:03:50PM +0200, Luis R. Rodriguez wrote: > > You said that with my patch you saw AMD IOMMUv2 kick off first, > > that was intentional as I thought that's what you needed. Can > > someone please describe the

Re: [PATCH] ACPI / Thermal / video: fix max_level incorrect value

On Thu, 2016-05-26 at 13:15 +0800, Aaron Lu wrote: > On 05/26/2016 09:49 AM, valdis.kletni...@vt.edu wrote: > > On Wed, 25 May 2016 13:15:26 +0800, Aaron Lu said: > >> Valdis, can you please give the patch a try? Thanks. > > > > Sorry, had a few days where actual work commitments and other > >

Re: [PATCH] ACPI / Thermal / video: fix max_level incorrect value

On Thu, 2016-05-26 at 13:15 +0800, Aaron Lu wrote: > On 05/26/2016 09:49 AM, valdis.kletni...@vt.edu wrote: > > On Wed, 25 May 2016 13:15:26 +0800, Aaron Lu said: > >> Valdis, can you please give the patch a try? Thanks. > > > > Sorry, had a few days where actual work commitments and other > >

Re: [PATCH] Use the correct size to set block max sectors

On Thu, 05/26 17:08, Long Li wrote: > The block sector size should be in unit of 512 bytes, not in bytes. > > Signed-off-by: Long Li > > --- > drivers/scsi/sd.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/sd.c

Re: [PATCH] Use the correct size to set block max sectors

On Thu, 05/26 17:08, Long Li wrote: > The block sector size should be in unit of 512 bytes, not in bytes. > > Signed-off-by: Long Li > > --- > drivers/scsi/sd.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Thu, May 26, 2016 at 11:29:45PM +0100, Catalin Marinas wrote: > On Thu, May 26, 2016 at 11:48:19PM +0300, Yury Norov wrote: > > On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > > > From: Arnd Bergmann > > > Date: Wed, 25 May 2016 23:01:06 +0200 > > > > > > > On

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Thu, May 26, 2016 at 11:29:45PM +0100, Catalin Marinas wrote: > On Thu, May 26, 2016 at 11:48:19PM +0300, Yury Norov wrote: > > On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > > > From: Arnd Bergmann > > > Date: Wed, 25 May 2016 23:01:06 +0200 > > > > > > > On Wednesday, May

[PATCH 2/4] f2fs: inject to produce some orphan inodes

Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 3 +++ fs/f2fs/inode.c | 5 + fs/f2fs/super.c | 1 + 3 files changed, 9 insertions(+) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 5daba19..c4697b7 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -45,6 +45,7 @@

[PATCH 2/4] f2fs: inject to produce some orphan inodes

Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 3 +++ fs/f2fs/inode.c | 5 + fs/f2fs/super.c | 1 + 3 files changed, 9 insertions(+) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 5daba19..c4697b7 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -45,6 +45,7 @@ enum {

[PATCH 4/4] f2fs: remove two steps to flush dirty data pages

If there is no cold page, we don't need to do a loop to flush dirty data pages. On /dev/pmem0, 1. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 conv=fsync Before : 1.1 GB/s After : 1.2 GB/s 2. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 Before : 2.2 GB/s After : 2.3

[PATCH 4/4] f2fs: remove two steps to flush dirty data pages

If there is no cold page, we don't need to do a loop to flush dirty data pages. On /dev/pmem0, 1. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 conv=fsync Before : 1.1 GB/s After : 1.2 GB/s 2. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 Before : 2.2 GB/s After : 2.3

[PATCH 3/4] f2fs: do not skip writing data pages

For data pages, let's try to flush as much as possible in background. On /dev/pmem0, 1. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 conv=fsync Before : 800 MB/s After : 1.1 GB/s 2. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 Before : 1.3 GB/s After : 2.2 GB/s

[PATCH 1/4] f2fs: propagate error given by f2fs_find_entry

If we get ENOMEM or EIO in f2fs_find_entry, we should stop right away. Otherwise, for example, we can get duplicate directory entry by ->chash and ->clevel. Signed-off-by: Jaegeuk Kim --- fs/f2fs/dir.c| 23 --- fs/f2fs/inline.c | 4 +++-

[PATCH 3/4] f2fs: do not skip writing data pages

For data pages, let's try to flush as much as possible in background. On /dev/pmem0, 1. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 conv=fsync Before : 800 MB/s After : 1.1 GB/s 2. dd if=/dev/zero of=/mnt/test/testfile bs=1M count=2048 Before : 1.3 GB/s After : 2.2 GB/s

[PATCH 1/4] f2fs: propagate error given by f2fs_find_entry

If we get ENOMEM or EIO in f2fs_find_entry, we should stop right away. Otherwise, for example, we can get duplicate directory entry by ->chash and ->clevel. Signed-off-by: Jaegeuk Kim --- fs/f2fs/dir.c| 23 --- fs/f2fs/inline.c | 4 +++- fs/f2fs/namei.c | 5 + 3

Re: [GIT PULL] xfs: updates for 4.7-rc1

On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote: > On Wed, May 25, 2016 at 11:13 PM, Dave Chinner wrote: > > > > Just yell if this is not OK and I'll drop those branches for this > > merge and resend the pull request > > i'm ok with the late branches, it's

Re: [GIT PULL] xfs: updates for 4.7-rc1

On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote: > On Wed, May 25, 2016 at 11:13 PM, Dave Chinner wrote: > > > > Just yell if this is not OK and I'll drop those branches for this > > merge and resend the pull request > > i'm ok with the late branches, it's not like xfs has

[PATCH 1/2] timer: Export destroy_hrtimer_on_stack()

hrtimer_init_on_stack() needs a matching call to destroy_hrtimer_on_stack(), so both need to be exported. Signed-off-by: Guenter Roeck --- kernel/time/hrtimer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index

[PATCH 2/2] net: pktgen: Call destroy_hrtimer_on_stack()

If CONFIG_DEBUG_OBJECTS_TIMERS=y, hrtimer_init_on_stack() requires a matching call to destroy_hrtimer_on_stack() to clean up timer debug objects. Signed-off-by: Guenter Roeck --- net/core/pktgen.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 1/2] timer: Export destroy_hrtimer_on_stack()

hrtimer_init_on_stack() needs a matching call to destroy_hrtimer_on_stack(), so both need to be exported. Signed-off-by: Guenter Roeck --- kernel/time/hrtimer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 8c7392c4fdbd..e99df0ff1d42

[PATCH 2/2] net: pktgen: Call destroy_hrtimer_on_stack()

If CONFIG_DEBUG_OBJECTS_TIMERS=y, hrtimer_init_on_stack() requires a matching call to destroy_hrtimer_on_stack() to clean up timer debug objects. Signed-off-by: Guenter Roeck --- net/core/pktgen.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/core/pktgen.c

Re: How should I use kernel-defined i2c structs in this driver

On 05/26/2016 04:59 PM, Andrey Utkin wrote: Could anybody please give a hint - which kernel-defined i2c objects, and how many of them, I need to define and use to substitute these driver-defined functions i2c_read(), i2c_write() ?

Re: How should I use kernel-defined i2c structs in this driver

On 05/26/2016 04:59 PM, Andrey Utkin wrote: Could anybody please give a hint - which kernel-defined i2c objects, and how many of them, I need to define and use to substitute these driver-defined functions i2c_read(), i2c_write() ?

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Tue, Apr 19, 2016 at 10:02:52AM +0800, Wan Zongshun wrote: > > You have to take carefully to arrange the calling sequence for > iommuv1, iommuv2, kfd module, and drm like the following sequence : > v1 ->v2->kfd, drm. > > iommuv1 -- rootfs_initcall(fn) > IOMMUV2 -- device_initcall(fn) > kfd

Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu

On Tue, Apr 19, 2016 at 10:02:52AM +0800, Wan Zongshun wrote: > > You have to take carefully to arrange the calling sequence for > iommuv1, iommuv2, kfd module, and drm like the following sequence : > v1 ->v2->kfd, drm. > > iommuv1 -- rootfs_initcall(fn) > IOMMUV2 -- device_initcall(fn) > kfd

[PATCH][RT] netpoll: Always take poll_lock when doing polling

[ Alison, can you try this patch ] This uses netpoll_poll_lock()/unlock() to synchronize netpoll and napi poll operations. Without this method, the synchronization is done by looping on NAPI_STATE_SCHED 'bitset'. This method works fine on a non-rt kernel because a softirq can not be preempted,

[PATCH][RT] netpoll: Always take poll_lock when doing polling

[ Alison, can you try this patch ] This uses netpoll_poll_lock()/unlock() to synchronize netpoll and napi poll operations. Without this method, the synchronization is done by looping on NAPI_STATE_SCHED 'bitset'. This method works fine on a non-rt kernel because a softirq can not be preempted,

[PATCH] Staging: comedi: ni_atmio: fixed spacing and comment style issues

Fixed coding style issues. Signed-off-by: Steven Laabs --- drivers/staging/comedi/drivers/ni_atmio.c | 180 +++--- 1 file changed, 91 insertions(+), 89 deletions(-) diff --git a/drivers/staging/comedi/drivers/ni_atmio.c

[PATCH] Staging: comedi: ni_atmio: fixed spacing and comment style issues

Fixed coding style issues. Signed-off-by: Steven Laabs --- drivers/staging/comedi/drivers/ni_atmio.c | 180 +++--- 1 file changed, 91 insertions(+), 89 deletions(-) diff --git a/drivers/staging/comedi/drivers/ni_atmio.c b/drivers/staging/comedi/drivers/ni_atmio.c index

Re: [PATCH] clk: rockchip: add a dummy clock for the watchdog pclk on rk3399

Am Mittwoch, 25. Mai 2016, 16:51:56 schrieb Xing Zheng: > Like rk3288, the pclk supplying the watchdog is controlled via the > SGRF register area. Additionally the SGRF isn't even writable in > every boot mode. > > But still the clock control is available and in the future someone > might want to

Re: [PATCH] clk: rockchip: add a dummy clock for the watchdog pclk on rk3399

Am Mittwoch, 25. Mai 2016, 16:51:56 schrieb Xing Zheng: > Like rk3288, the pclk supplying the watchdog is controlled via the > SGRF register area. Additionally the SGRF isn't even writable in > every boot mode. > > But still the clock control is available and in the future someone > might want to

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

On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: Per the discussion with Joonsoo Kim [1], we need check the return value of lookup_page_ext() for all call sites since it might return

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

On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: Per the discussion with Joonsoo Kim [1], we need check the return value of lookup_page_ext() for all call sites since it might return

[PATCH V4] brcmfmac: print errors if creating interface fails

This is helpful for debugging. Without this all I was getting from "iw" command on failed creating of P2P interface was: > command failed: Too many open files in system (-23) Signed-off-by: Rafał Miłecki --- V2: s/in/if/ in commit message V3: Add one more error message as

[PATCH V4] brcmfmac: print errors if creating interface fails

This is helpful for debugging. Without this all I was getting from "iw" command on failed creating of P2P interface was: > command failed: Too many open files in system (-23) Signed-off-by: Rafał Miłecki --- V2: s/in/if/ in commit message V3: Add one more error message as suggested by Arend V4:

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 02:04:50PM -0700, Kees Cook wrote: > One problem with seccomp was that ptrace could be used to change a > syscall after seccomp filtering had completed. This was a well documented > limitation, and it was recommended to block ptrace when defining a filter > to avoid this

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

On Thu, May 26, 2016 at 02:04:50PM -0700, Kees Cook wrote: > One problem with seccomp was that ptrace could be used to change a > syscall after seccomp filtering had completed. This was a well documented > limitation, and it was recommended to block ptrace when defining a filter > to avoid this

mmotm 2016-05-26-15-51 uploaded

The mm-of-the-moment snapshot 2016-05-26-15-51 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-05-26-15-51 uploaded

The mm-of-the-moment snapshot 2016-05-26-15-51 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: can't boot with reiserfs on linux-4.6.0+

On Thu, May 26, 2016 at 3:46 PM, Hillf Danton wrote: >> > See if this fixes your reproducer. >> > >> > diff --git a/fs/xattr.c b/fs/xattr.c >> > index b11945e..49b8eab 100644 >> > --- a/fs/xattr.c >> > +++ b/fs/xattr.c >> > @@ -667,6 +667,9 @@ xattr_resolve_name(const

Re: can't boot with reiserfs on linux-4.6.0+

On Thu, May 26, 2016 at 3:46 PM, Hillf Danton wrote: >> > See if this fixes your reproducer. >> > >> > diff --git a/fs/xattr.c b/fs/xattr.c >> > index b11945e..49b8eab 100644 >> > --- a/fs/xattr.c >> > +++ b/fs/xattr.c >> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler >> >

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

On 05/17/2016 10:30 AM, Al Stone wrote: > On 05/16/2016 05:44 PM, Alexey Klimov wrote: >> On Mon, May 2, 2016 at 09:19 PM, Al Stone wrote: >>> On 04/25/2016 03:21 PM, Al Stone wrote: The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel

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

On 05/17/2016 10:30 AM, Al Stone wrote: > On 05/16/2016 05:44 PM, Alexey Klimov wrote: >> On Mon, May 2, 2016 at 09:19 PM, Al Stone wrote: >>> On 04/25/2016 03:21 PM, Al Stone wrote: The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Thu, May 26, 2016 at 11:11:51AM +0100, Robin Murphy wrote: >On 25/05/16 22:43, Wei Yang wrote: >>On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >>>On 25/05/16 00:06, Wei Yang wrote: Hi, Joerg Not sure whether you think this calculation is correct. If I

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On Thu, May 26, 2016 at 11:11:51AM +0100, Robin Murphy wrote: >On 25/05/16 22:43, Wei Yang wrote: >>On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >>>On 25/05/16 00:06, Wei Yang wrote: Hi, Joerg Not sure whether you think this calculation is correct. If I

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Thu, May 26, 2016 at 11:48:19PM +0300, Yury Norov wrote: > On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > > From: Arnd Bergmann > > Date: Wed, 25 May 2016 23:01:06 +0200 > > > > > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > > >> From: Arnd

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Thu, May 26, 2016 at 11:48:19PM +0300, Yury Norov wrote: > On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > > From: Arnd Bergmann > > Date: Wed, 25 May 2016 23:01:06 +0200 > > > > > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > > >> From: Arnd Bergmann > >

[PATCH] Use the correct size to set block max sectors

The block sector size should be in unit of 512 bytes, not in bytes. Signed-off-by: Long Li --- drivers/scsi/sd.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 428c03e..4bce17e 100644 ---

[PATCH] Use the correct size to set block max sectors

The block sector size should be in unit of 512 bytes, not in bytes. Signed-off-by: Long Li --- drivers/scsi/sd.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 428c03e..4bce17e 100644 --- a/drivers/scsi/sd.c +++

Regression in i915 in kernel 4.6.0-git - bisected to f21a21983ef13a031

The latest mainline kernel (commit 3f59de0) shows a regression. The symptom is that as soon as the kernel is started, the display is blanked, and it is never turned on again. This problem was bisected to commit f21a21983ef13a031250c4c3f6018e29a549d0f1 ("drm/i915: Splitting intel_dp_detect").

Regression in i915 in kernel 4.6.0-git - bisected to f21a21983ef13a031

The latest mainline kernel (commit 3f59de0) shows a regression. The symptom is that as soon as the kernel is started, the display is blanked, and it is never turned on again. This problem was bisected to commit f21a21983ef13a031250c4c3f6018e29a549d0f1 ("drm/i915: Splitting intel_dp_detect").

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

On 22/05/2016 13:36, Pali Rohár wrote: > ACPI DSDT tables have defined other WMI codes, but does not contain any > description when those codes are emitted. Some other codes can be found in > logs on internet. In this patch are all which I saw, but lot of them are > not tested properly (e.g. for

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

On 22/05/2016 13:36, Pali Rohár wrote: > ACPI DSDT tables have defined other WMI codes, but does not contain any > description when those codes are emitted. Some other codes can be found in > logs on internet. In this patch are all which I saw, but lot of them are > not tested properly (e.g. for

RE: [PATCH V3 1/2] i2c: qup: Fix broken dma when CONFIG_DEBUG_SG is enabled

Hi, >> sg_set_buf expects that the buf parameter passed in should be from >> lowmem and a valid pageframe. This is not true for pages from >> dma_alloc_coherent which can be carveouts, hence the check fails. > >OK, given you mean dma_pool_alloc here, the check fails for the >pageframe because of

RE: [PATCH V3 1/2] i2c: qup: Fix broken dma when CONFIG_DEBUG_SG is enabled

Hi, >> sg_set_buf expects that the buf parameter passed in should be from >> lowmem and a valid pageframe. This is not true for pages from >> dma_alloc_coherent which can be carveouts, hence the check fails. > >OK, given you mean dma_pool_alloc here, the check fails for the >pageframe because of

Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/26/2016 12:55 PM, Boris Ostrovsky wrote: > On 05/26/2016 12:26 PM, Jan Beulich wrote: > Boris Ostrovsky 05/25/16 9:17 PM >>> >>> On 05/05/2016 12:58 AM, Lv Zheng wrote: +static u8 +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8

Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/26/2016 12:55 PM, Boris Ostrovsky wrote: > On 05/26/2016 12:26 PM, Jan Beulich wrote: > Boris Ostrovsky 05/25/16 9:17 PM >>> >>> On 05/05/2016 12:58 AM, Lv Zheng wrote: +static u8 +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 max_bit_width) +{

[PATCH v6r2 11/12] zsmalloc: page migration support

Follow up Sergey's review >From 2deede28c91910a9d3493feae30bed507e72f213 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Thu, 5 May 2016 00:01:03 +0900 Subject: [PATCH v6r2] zsmalloc: page migration support This patch introduces run-time migration feature for zspage. For

[PATCH v6r2 11/12] zsmalloc: page migration support

Follow up Sergey's review >From 2deede28c91910a9d3493feae30bed507e72f213 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Thu, 5 May 2016 00:01:03 +0900 Subject: [PATCH v6r2] zsmalloc: page migration support This patch introduces run-time migration feature for zspage. For migration, VM uses

Re: [PATCH] clk: rockchip: fix cclk error handing

Am Donnerstag, 26. Mai 2016, 21:49:08 schrieb Xing Zheng: > It maybe due to a copy-paste error the error handing should be > cclk not clk. > > Reported-by: Lin Huang > Signed-off-by: Xing Zheng applied to my clk-fixes branch after adapting

Re: [PATCH] clk: rockchip: fix cclk error handing

Am Donnerstag, 26. Mai 2016, 21:49:08 schrieb Xing Zheng: > It maybe due to a copy-paste error the error handing should be > cclk not clk. > > Reported-by: Lin Huang > Signed-off-by: Xing Zheng applied to my clk-fixes branch after adapting the commit message a bit. Thanks for catching that

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, 26 May 2016, Linus Torvalds wrote: > On Thu, May 26, 2016 at 11:31 AM, Linus Torvalds > wrote: > > > > Pulled and then immediately unpulled again. > > .. and having thought it over, I ended up re-pulling again, so now > it's going through my build test. >

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, 26 May 2016, Linus Torvalds wrote: > On Thu, May 26, 2016 at 11:31 AM, Linus Torvalds > wrote: > > > > Pulled and then immediately unpulled again. > > .. and having thought it over, I ended up re-pulling again, so now > it's going through my build test. > > Consider this discussion a

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

On 05/25/2016 06:04 PM, Rich Felker wrote: > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote: >> * What state should the CPU be in when it branches to the provided >> address? >> - Must the MMU be off? > > Current models are nommu. As far as I know, we're the first nommu SMP

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

On 05/25/2016 06:04 PM, Rich Felker wrote: > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote: >> * What state should the CPU be in when it branches to the provided >> address? >> - Must the MMU be off? > > Current models are nommu. As far as I know, we're the first nommu SMP

RE: [PATCH 2/7] crypto : async implementation for sha1-mb

> From: Dey, Megha > Sent: Thursday, May 19, 2016 5:43 PM > To: herb...@gondor.apana.org.au > Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux- > cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Dey, Megha > ; Yu, Fenghua ; Megha > Dey

RE: [PATCH 2/7] crypto : async implementation for sha1-mb

> From: Dey, Megha > Sent: Thursday, May 19, 2016 5:43 PM > To: herb...@gondor.apana.org.au > Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux- > cry...@vger.kernel.org; linux-kernel@vger.kernel.org; Dey, Megha > ; Yu, Fenghua ; Megha > Dey > Subject: [PATCH 2/7] crypto : async

Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 03:17 PM, Stephen Warren wrote: On 05/26/2016 09:40 AM, Thierry Reding wrote: From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that

Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 03:17 PM, Stephen Warren wrote: On 05/26/2016 09:40 AM, Thierry Reding wrote: From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that doesn't allow

[PATCH 1/5] lib/mpi: mpi_read_from_buffer(): return error code

mpi_read_from_buffer() reads a MPI from a buffer into a newly allocated MPI instance. It expects the buffer's leading two bytes to contain the number of bits, followed by the actual payload. On failure, it returns NULL and updates the in/out argument ret_nread somewhat inconsistently: - If the

[PATCH 1/5] lib/mpi: mpi_read_from_buffer(): return error code

mpi_read_from_buffer() reads a MPI from a buffer into a newly allocated MPI instance. It expects the buffer's leading two bytes to contain the number of bits, followed by the actual payload. On failure, it returns NULL and updates the in/out argument ret_nread somewhat inconsistently: - If the

<    1   2   3   4   5   6   7   8   9   >