Re: [PATCH v3 00/15] net: thunderx: Add support for 81xx and 83xx

A gentle reminder to consider the patchset for either review or acceptance. Thanks, Sunil.

Re: [PATCH v3 00/15] net: thunderx: Add support for 81xx and 83xx

A gentle reminder to consider the patchset for either review or acceptance. Thanks, Sunil.

Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack LSM hook

On Tue, Jul 19, 2016 at 11:12 PM, James Morris wrote: > On Mon, 18 Jul 2016, John Stultz wrote: > >> As requested, this patch implements a task_settimerslack and >> task_gettimerslack LSM hooks so that the /proc//timerslack_ns >> interface can have finer grained security

Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack LSM hook

On Tue, Jul 19, 2016 at 11:12 PM, James Morris wrote: > On Mon, 18 Jul 2016, John Stultz wrote: > >> As requested, this patch implements a task_settimerslack and >> task_gettimerslack LSM hooks so that the /proc//timerslack_ns >> interface can have finer grained security policies applied to it.

Re: [PATCH 5/5] mm: consider per-zone inactive ratio to deactivate

Hi Mel, On Wed, Jul 20, 2016 at 04:21:51PM +0100, Mel Gorman wrote: > From: Minchan Kim > > Minchan Kim reported that with per-zone lru state it was possible to > identify that a normal zone with 8^M anonymous pages could trigger > OOM with non-atomic order-0 allocations as

Re: [PATCH 5/5] mm: consider per-zone inactive ratio to deactivate

Hi Mel, On Wed, Jul 20, 2016 at 04:21:51PM +0100, Mel Gorman wrote: > From: Minchan Kim > > Minchan Kim reported that with per-zone lru state it was possible to > identify that a normal zone with 8^M anonymous pages could trigger > OOM with non-atomic order-0 allocations as all pages in the

linux-next: build warnings after merge of the libata tree

Hi Tejun, After merging the libata tree, today's linux-next build (arm multi_v7_defconfig) produced these warning: drivers/ata/libata-scsi.c: In function 'ata_mselect_caching': drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]

linux-next: build warnings after merge of the libata tree

Hi Tejun, After merging the libata tree, today's linux-next build (arm multi_v7_defconfig) produced these warning: drivers/ata/libata-scsi.c: In function 'ata_mselect_caching': drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]

[PATCH v2 0/2] Fix issue with alternatives/paravirt patches

Hi, A few months ago, Chris Arges reported a bug involving alternatives/paravirt patching that was discussed here [1] and here [2]. To briefly summarize the bug, patch modules that contained .altinstructions or .parainstructions sections would break because these alternative/paravirt patches

[PATCH v2 0/2] Fix issue with alternatives/paravirt patches

Hi, A few months ago, Chris Arges reported a bug involving alternatives/paravirt patching that was discussed here [1] and here [2]. To briefly summarize the bug, patch modules that contained .altinstructions or .parainstructions sections would break because these alternative/paravirt patches

[PATCH v2 2/2] livepatch/x86: apply alternatives and paravirt patches after relocations

Implement arch_klp_init_object_loaded() for x86, which applies alternatives/paravirt patches. This fixes the order in which relocations and alternatives/paravirt patches are applied. Previously, if a patch module had alternatives or paravirt patches, these were applied first by the module loader

[PATCH v2 1/2] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks

Introduce arch_klp_init_object_loaded() to complete any additional arch-specific tasks during patching. Architecture code may override this function. Signed-off-by: Jessica Yu --- include/linux/livepatch.h | 3 +++ kernel/livepatch/core.c | 12 ++-- 2 files changed,

[PATCH v2 1/2] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks

Introduce arch_klp_init_object_loaded() to complete any additional arch-specific tasks during patching. Architecture code may override this function. Signed-off-by: Jessica Yu --- include/linux/livepatch.h | 3 +++ kernel/livepatch/core.c | 12 ++-- 2 files changed, 13 insertions(+),

[PATCH v2 2/2] livepatch/x86: apply alternatives and paravirt patches after relocations

Implement arch_klp_init_object_loaded() for x86, which applies alternatives/paravirt patches. This fixes the order in which relocations and alternatives/paravirt patches are applied. Previously, if a patch module had alternatives or paravirt patches, these were applied first by the module loader

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

On Wed, Jul 20, 2016 at 9:26 PM, zhangfei wrote: > > > On 07/21/2016 11:53 AM, John Stultz wrote: >> >> After lots of debugging on an occasional DMA ERR issue, I realized >> that the desc structures which we point the dma hardware are being >> allocated out of regular

[PATCH/V2] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

Boot the system without this entry generates following warning. fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver After apply this patch, no more conflict message. fb: switching to mgag200drmfb from EFI VGA Compile and tested on DL360 Gen9 and it works both console

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

On Wed, Jul 20, 2016 at 9:26 PM, zhangfei wrote: > > > On 07/21/2016 11:53 AM, John Stultz wrote: >> >> After lots of debugging on an occasional DMA ERR issue, I realized >> that the desc structures which we point the dma hardware are being >> allocated out of regular memory. This means when we

[PATCH/V2] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

Boot the system without this entry generates following warning. fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver After apply this patch, no more conflict message. fb: switching to mgag200drmfb from EFI VGA Compile and tested on DL360 Gen9 and it works both console

Re: [PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

I made mistake to type shane's e-mail address, so I will send version 2. Sorry for the noise. Masanari On Thu, Jul 21, 2016 at 2:12 PM, Masanari Iida wrote: > Boot the system without this entry generates following warning. > fb: conflicting fb hw usage mgag200drmfb vs EFI

Re: [PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

I made mistake to type shane's e-mail address, so I will send version 2. Sorry for the noise. Masanari On Thu, Jul 21, 2016 at 2:12 PM, Masanari Iida wrote: > Boot the system without this entry generates following warning. > fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic

Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned

On Wed, Jul 20, 2016 at 04:21:47PM +0100, Mel Gorman wrote: > Page reclaim determines whether a pgdat is unreclaimable by examining how > many pages have been scanned since a page was freed and comparing that > to the LRU sizes. Skipped pages are not considered reclaim candidates but > contribute

Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned

On Wed, Jul 20, 2016 at 04:21:47PM +0100, Mel Gorman wrote: > Page reclaim determines whether a pgdat is unreclaimable by examining how > many pages have been scanned since a page was freed and comparing that > to the LRU sizes. Skipped pages are not considered reclaim candidates but > contribute

[PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

Boot the system without this entry generates following warning. fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver After apply this patch, no more conflict message. fb: switching to mgag200drmfb from EFI VGA Compile and tested on DL360 Gen9 and it works both console

[PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9

Boot the system without this entry generates following warning. fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver After apply this patch, no more conflict message. fb: switching to mgag200drmfb from EFI VGA Compile and tested on DL360 Gen9 and it works both console

Re: Fix issue with alternatives/paravirt patches

+++ Miroslav Benes [12/07/16 14:06 +0200]: On Tue, 5 Jul 2016, Jessica Yu wrote: Hi, A few months ago, Chris Arges reported a bug involving alternatives/paravirt patching that was discussed here [1] and here [2]. To briefly summarize the bug, patch modules that contained .altinstructions or

Re: Fix issue with alternatives/paravirt patches

+++ Miroslav Benes [12/07/16 14:06 +0200]: On Tue, 5 Jul 2016, Jessica Yu wrote: Hi, A few months ago, Chris Arges reported a bug involving alternatives/paravirt patching that was discussed here [1] and here [2]. To briefly summarize the bug, patch modules that contained .altinstructions or

[PATCH] reset: return -ENOTSUPP if CONFIG_RESET_CONTROLLER is undefined

This has been inconsistent; some returns -EINVAL, some -ENOTSUPP. Make it consistent in this header, in favor of -ENOTSUPP. Signed-off-by: Masahiro Yamada --- include/linux/reset.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] reset: return -ENOTSUPP if CONFIG_RESET_CONTROLLER is undefined

This has been inconsistent; some returns -EINVAL, some -ENOTSUPP. Make it consistent in this header, in favor of -ENOTSUPP. Signed-off-by: Masahiro Yamada --- include/linux/reset.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/reset.h

[PATCH] reset: generate reset_control_get variants with macro expansion

The recent update in the reset subsystem requires all reset consumers to be explicit about the requested reset lines; _explicit or _shared. This effectively doubled the number of reset_control_get variants. Also, we already had _optional variants. We see some pattern in the reset_control_get

[PATCH] reset: generate reset_control_get variants with macro expansion

The recent update in the reset subsystem requires all reset consumers to be explicit about the requested reset lines; _explicit or _shared. This effectively doubled the number of reset_control_get variants. Also, we already had _optional variants. We see some pattern in the reset_control_get

[gcc-4.4] Re: arch/x86/events/intel/uncore_snbep.o: warning: objtool: snbep_uncore_msr_enable_event()+0x2e: function has unreachable instruction

On Thu, Jul 21, 2016 at 11:06:06AM +0800, Liang, Kan wrote: Hi Fengguang, I located the unreachable instruction which is ud2. This instruction will raise invalid opcode exception. So I think normally it should not be reached. Also ud2 should be generated by compiler, not our codes. It's

[gcc-4.4] Re: arch/x86/events/intel/uncore_snbep.o: warning: objtool: snbep_uncore_msr_enable_event()+0x2e: function has unreachable instruction

On Thu, Jul 21, 2016 at 11:06:06AM +0800, Liang, Kan wrote: Hi Fengguang, I located the unreachable instruction which is ud2. This instruction will raise invalid opcode exception. So I think normally it should not be reached. Also ud2 should be generated by compiler, not our codes. It's

linux-next: manual merge of the kvm tree with the powerpc tree

Hi all, Today's linux-next merge of the kvm tree got a conflict in: arch/powerpc/kernel/Makefile between commit: 27d114966735 ("powerpc/32: Remove RELOCATABLE_PPC32") from the powerpc tree and commit: fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI

linux-next: manual merge of the kvm tree with the powerpc tree

Hi all, Today's linux-next merge of the kvm tree got a conflict in: arch/powerpc/kernel/Makefile between commit: 27d114966735 ("powerpc/32: Remove RELOCATABLE_PPC32") from the powerpc tree and commit: fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

On 07/21/2016 11:53 AM, John Stultz wrote: After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

On 07/21/2016 11:53 AM, John Stultz wrote: After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed

Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

On Wed, Jul 20, 2016 at 06:37:07PM +0300, Thomas Backlund wrote: > > Yeah, but that patch seem to be heading to 4.8 only , so qat build > in upcoming 4.7 still breaks... > > and pulling that fix only to 4.7 breaks too, so I guess more fixes > would be needed for proper backport then... > > or

Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

On Wed, Jul 20, 2016 at 06:37:07PM +0300, Thomas Backlund wrote: > > Yeah, but that patch seem to be heading to 4.8 only , so qat build > in upcoming 4.7 still breaks... > > and pulling that fix only to 4.7 breaks too, so I guess more fixes > would be needed for proper backport then... > > or

Re: [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: rework EEPROM code

From: Vivien Didelot Date: Wed, 20 Jul 2016 18:18:33 -0400 > Some switches can access an optional external EEPROM via its registers. > > The 88E6352 family of switches have 8-bit address / 16-bit data access. > The new 88E6390 family has 16-bit address /

Re: [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: rework EEPROM code

From: Vivien Didelot Date: Wed, 20 Jul 2016 18:18:33 -0400 > Some switches can access an optional external EEPROM via its registers. > > The 88E6352 family of switches have 8-bit address / 16-bit data access. > The new 88E6390 family has 16-bit address / 8-bit data access. > > This patchset

Re: [PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

Hi, Bibby: On Thu, 2016-07-21 at 11:21 +0800, Bibby Hsieh wrote: > Hi, CK > > I'm appreciate your comments. > > [snip...] > > > > > > @@ -469,7 +484,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct > > > mtk_ddp_comp *ovl) > > > if (state->pending_config) { > > >

Re: [PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

Hi, Bibby: On Thu, 2016-07-21 at 11:21 +0800, Bibby Hsieh wrote: > Hi, CK > > I'm appreciate your comments. > > [snip...] > > > > > > @@ -469,7 +484,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct > > > mtk_ddp_comp *ovl) > > > if (state->pending_config) { > > >

[PATCH 4/7] k3dma: Add cyclic mode for audio

From: Andy Green Currently the k3dma driver doesn't offer the cyclic mode necessary for handling audio. This patch adds it. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard

[PATCH 3/7] k3dma: Fix "nobody cared" message seen on any error

From: Andy Green As it was before, as soon as the DMAC IP felt there was an error he would return IRQ_NONE since no actual transfer had completed. After spinning on that for 100K interrupts, Linux yanks the IRQ with a "nobody cared" error. This patch lets it handle the

[PATCH 2/7] k3dma: Fix dma err offsets

From: Andy Green The offsets for ERR1 and ERR2 are wrong actually. That's why you can never clear an error. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard

[PATCH 4/7] k3dma: Add cyclic mode for audio

From: Andy Green Currently the k3dma driver doesn't offer the cyclic mode necessary for handling audio. This patch adds it. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Acked-by: Zhangfei Gao

[PATCH 3/7] k3dma: Fix "nobody cared" message seen on any error

From: Andy Green As it was before, as soon as the DMAC IP felt there was an error he would return IRQ_NONE since no actual transfer had completed. After spinning on that for 100K interrupts, Linux yanks the IRQ with a "nobody cared" error. This patch lets it handle the interrupt and keep the

[PATCH 2/7] k3dma: Fix dma err offsets

From: Andy Green The offsets for ERR1 and ERR2 are wrong actually. That's why you can never clear an error. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Acked-by: Zhangfei Gao Signed-off-by: Andy

[PATCH 7/7] Kconfig: Allow k3dma driver to be selected for more then HISI3xx platforms

This allows the k3dma driver to be selected on HiKey via the ARCH_HISI dependency. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul

[PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed out to memory by the time we start the dma

[PATCH 5/7] k3dma: Fix memory handling with cyclic mode

With cyclic mode, the shared virt-dma logic doesn't actually manage the descriptor state, nor the calling of the descriptor free callback. This results in leaking a desc structure every time we start an audio transfer. Thus we must manage it ourselves. The k3dma driver already keeps track of the

[PATCH 0/7 v3] K3DMA fixes for HiKey HDMI audio

Per Mark's suggestion, I've split out the k3dma changes on their own as they are mostly fixes and the addition of cyclic mode. New in v3: * With inspiration from YongQin Liu, I figured out the reason we were seeing occasional DMA ERR issues: The desc structures were being allocated with kzalloc

[PATCH 1/7] k3dma: Fix hisi burst clipping

From: Andy Green Max burst len is a 4-bit field, but at the moment it's clipped with a 5-bit constant... reduce it to that which can be expressed Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski

[PATCH 5/7] k3dma: Fix memory handling with cyclic mode

With cyclic mode, the shared virt-dma logic doesn't actually manage the descriptor state, nor the calling of the descriptor free callback. This results in leaking a desc structure every time we start an audio transfer. Thus we must manage it ourselves. The k3dma driver already keeps track of the

[PATCH 0/7 v3] K3DMA fixes for HiKey HDMI audio

Per Mark's suggestion, I've split out the k3dma changes on their own as they are mostly fixes and the addition of cyclic mode. New in v3: * With inspiration from YongQin Liu, I figured out the reason we were seeing occasional DMA ERR issues: The desc structures were being allocated with kzalloc

[PATCH 1/7] k3dma: Fix hisi burst clipping

From: Andy Green Max burst len is a 4-bit field, but at the moment it's clipped with a 5-bit constant... reduce it to that which can be expressed Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green

[PATCH 7/7] Kconfig: Allow k3dma driver to be selected for more then HISI3xx platforms

This allows the k3dma driver to be selected on HiKey via the ARCH_HISI dependency. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Wei Xu Cc: Rob Herring

[PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed out to memory by the time we start the dma

Re: [PATCH v2] watchdog: ziirave_wdt: Add support to upload the firmware.

On 07/20/2016 03:31 AM, Enric Balletbo i Serra wrote: This patch adds and entry to the sysfs to start firmware upload process on the specified device with the requested firmware. The uploading of the firmware needs only to happen once per firmware upgrade, as the firmware is stored in

Re: [PATCH v2] watchdog: ziirave_wdt: Add support to upload the firmware.

On 07/20/2016 03:31 AM, Enric Balletbo i Serra wrote: This patch adds and entry to the sysfs to start firmware upload process on the specified device with the requested firmware. The uploading of the firmware needs only to happen once per firmware upgrade, as the firmware is stored in

[PATCH 1/3] f2fs: support an ioctl to move a range of data blocks

This patch implements moving a range of data blocks from source file to destination file. Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 9 fs/f2fs/file.c | 132 + 2 files changed, 141 insertions(+) diff --git

[PATCH 3/3] f2fs: handle error case with f2fs_bug_on

It's enough to show BUG or WARN by f2fs_bug_on for error case. Then, we don't need to remain corrupted filesystem. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index

[PATCH 2/3] f2fs: avoid data race when deciding checkpoin in f2fs_sync_file

When fs utilization is almost full, f2fs_sync_file should do checkpoint if there is not enough space for roll-forward later. (i.e. space_for_roll_forward) So, currently we have no lock for sbi->alloc_valid_block_count, resulting in race condition. In rare case, we can get -ENOSPC when doing

[PATCH 1/3] f2fs: support an ioctl to move a range of data blocks

This patch implements moving a range of data blocks from source file to destination file. Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 9 fs/f2fs/file.c | 132 + 2 files changed, 141 insertions(+) diff --git a/fs/f2fs/f2fs.h

[PATCH 3/3] f2fs: handle error case with f2fs_bug_on

It's enough to show BUG or WARN by f2fs_bug_on for error case. Then, we don't need to remain corrupted filesystem. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index 5d4461f..9e652d5 100644 ---

[PATCH 2/3] f2fs: avoid data race when deciding checkpoin in f2fs_sync_file

When fs utilization is almost full, f2fs_sync_file should do checkpoint if there is not enough space for roll-forward later. (i.e. space_for_roll_forward) So, currently we have no lock for sbi->alloc_valid_block_count, resulting in race condition. In rare case, we can get -ENOSPC when doing

Re: [PATCH v2] block: do not merge requests without consulting with io scheduler

On 07/07/2016 12:48 PM, Tahsin Erdogan wrote: Before merging a bio into an existing request, io scheduler is called to get its approval first. However, the requests that come from a plug flush may get merged by block layer without consulting with io scheduler. In case of CFQ, this can cause

Re: [PATCH v2] block: do not merge requests without consulting with io scheduler

On 07/07/2016 12:48 PM, Tahsin Erdogan wrote: Before merging a bio into an existing request, io scheduler is called to get its approval first. However, the requests that come from a plug flush may get merged by block layer without consulting with io scheduler. In case of CFQ, this can cause

linux-next: manual merge of the device-mapper tree with the block tree

Hi all, Today's linux-next merge of the device-mapper tree got a conflict in: drivers/md/dm.c between commit: 4cc96131afce ("dm: move request-based code out to dm-rq.[hc]") from the block tree and commit: 70246286e94c ("block: get rid of bio_rw and READA") from the device-mapper tree.

linux-next: manual merge of the device-mapper tree with the block tree

Hi all, Today's linux-next merge of the device-mapper tree got a conflict in: drivers/md/dm.c between commit: 4cc96131afce ("dm: move request-based code out to dm-rq.[hc]") from the block tree and commit: 70246286e94c ("block: get rid of bio_rw and READA") from the device-mapper tree.

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

Hi, CK I'm appreciate your comments. On Fri, 2016-07-15 at 17:11 +0800, CK Hu wrote: > Hi, Bibby: > > Some comments inline. > > On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote: > > Apply gamma function to correct brightness values. > > It applies arbitrary mapping curve to compensate the

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

Hi, CK I'm appreciate your comments. On Fri, 2016-07-15 at 17:11 +0800, CK Hu wrote: > Hi, Bibby: > > Some comments inline. > > On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote: > > Apply gamma function to correct brightness values. > > It applies arbitrary mapping curve to compensate the

Re: [PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

Hi, CK I'm appreciate your comments. On Mon, 2016-07-18 at 10:33 +0800, CK Hu wrote: > Hi, Bibby: > > Some comments inline. > > On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote: > > Some panels only accept bpc (bit per color) 6-bit. > > But, the default bpc in mt8173 display data path is

Re: [PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

Hi, CK I'm appreciate your comments. On Mon, 2016-07-18 at 10:33 +0800, CK Hu wrote: > Hi, Bibby: > > Some comments inline. > > On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote: > > Some panels only accept bpc (bit per color) 6-bit. > > But, the default bpc in mt8173 display data path is

[PATCH] s390/perf: fix 'start' address of module's map

At preset, when creating module's map, perf gets 'start' address by parsing '/proc/modules', but it's module base address, isn't the start address of '.text' section. In most archs, it's OK. But for s390, it places 'GOT' and 'PLT' relocations before '.text' section. So there exists an offset

[RFC PATCH V4]s390/perf:fix 'start' address of module's map

Change log: >From V3: 1.move fixup function to tools/perf/arch/s390/util/machine.c; 2. Add acked-by info from Jiri Olsa ; >From V2: 1. remove redundancy string 'module_name'; >From V1: 1.change func name from 'fix__arch_module_baseaddr' to 'fix__arch_module_text_start';

[PATCH] s390/perf: fix 'start' address of module's map

At preset, when creating module's map, perf gets 'start' address by parsing '/proc/modules', but it's module base address, isn't the start address of '.text' section. In most archs, it's OK. But for s390, it places 'GOT' and 'PLT' relocations before '.text' section. So there exists an offset

[RFC PATCH V4]s390/perf:fix 'start' address of module's map

Change log: >From V3: 1.move fixup function to tools/perf/arch/s390/util/machine.c; 2. Add acked-by info from Jiri Olsa ; >From V2: 1. remove redundancy string 'module_name'; >From V1: 1.change func name from 'fix__arch_module_baseaddr' to 'fix__arch_module_text_start'; 2.Parse '.text' start

linux-next: manual merge of the block tree with Linus' tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: block/blk-lib.c between commit: 05bd92dddc59 ("block: missing bio_put following submit_bio_wait") from Linus' tree and commit: 4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio") from the block

linux-next: manual merge of the block tree with Linus' tree

Hi Jens, Today's linux-next merge of the block tree got a conflict in: block/blk-lib.c between commit: 05bd92dddc59 ("block: missing bio_put following submit_bio_wait") from Linus' tree and commit: 4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio") from the block

Re: dm stripe: add DAX support

On 07/20/2016 06:01 PM, Mike Snitzer wrote: On Wed, Jul 13 2016 at 11:03am -0400, Kani, Toshimitsu wrote: On Tue, 2016-07-12 at 22:01 -0400, Mike Snitzer wrote: On Tue, Jul 12 2016 at 6:22pm -0400, Kani, Toshimitsu wrote: On Fri, 2016-06-24 at 14:29

Re: dm stripe: add DAX support

On 07/20/2016 06:01 PM, Mike Snitzer wrote: On Wed, Jul 13 2016 at 11:03am -0400, Kani, Toshimitsu wrote: On Tue, 2016-07-12 at 22:01 -0400, Mike Snitzer wrote: On Tue, Jul 12 2016 at 6:22pm -0400, Kani, Toshimitsu wrote: On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote: :

Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

Hi Doug, On 2016/7/21 5:33, Doug Anderson wrote: Hi, On Tue, Jul 19, 2016 at 12:28 AM, Frank Wang wrote: You need a patch description here, even for simple patches. All you have now is a subject. OK, I will describe it next version. Signed-off-by: Frank Wang

Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

Hi Doug, On 2016/7/21 5:33, Doug Anderson wrote: Hi, On Tue, Jul 19, 2016 at 12:28 AM, Frank Wang wrote: You need a patch description here, even for simple patches. All you have now is a subject. OK, I will describe it next version. Signed-off-by: Frank Wang ---

linux-next: manual merge of the kspp tree with the arm64 tree

Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: arch/arm64/include/asm/uaccess.h between commit: bffe1baff5d5 ("arm64: kasan: instrument user memory access API") from the arm64 tree and commit: aac380fe78b1 ("arm64/uaccess: Enable hardened usercopy") from the

linux-next: manual merge of the kspp tree with the arm64 tree

Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: arch/arm64/include/asm/uaccess.h between commit: bffe1baff5d5 ("arm64: kasan: instrument user memory access API") from the arm64 tree and commit: aac380fe78b1 ("arm64/uaccess: Enable hardened usercopy") from the

Re: [PATCH net-next] net: dsa: add CONFIG_NET_DSA_LEGACY

Le 20/07/2016 à 17:35, Andrew Lunn a écrit : > On Wed, Jul 20, 2016 at 06:26:41PM -0400, Vivien Didelot wrote: >> This patch simply moves the legacy DSA code from dsa.c to legacy.c, >> except the few shared symbols which remain in dsa.c. > > I think it is a bit early for this. Lets convert all in

Re: [PATCH net-next] net: dsa: add CONFIG_NET_DSA_LEGACY

Le 20/07/2016 à 17:35, Andrew Lunn a écrit : > On Wed, Jul 20, 2016 at 06:26:41PM -0400, Vivien Didelot wrote: >> This patch simply moves the legacy DSA code from dsa.c to legacy.c, >> except the few shared symbols which remain in dsa.c. > > I think it is a bit early for this. Lets convert all in

Re: [PATCH v13 00/12] support "task_isolation" mode

We are trying to test the patchset on x86 and are getting strange backtraces and aborts. It seems that the cpu before the cpu we are running on creates an irq_work event that causes a latency event on the next cpu. This is weird. Is there a new round robin IPI feature in the kernel that I am not

Re: [PATCH v13 00/12] support "task_isolation" mode

We are trying to test the patchset on x86 and are getting strange backtraces and aborts. It seems that the cpu before the cpu we are running on creates an irq_work event that causes a latency event on the next cpu. This is weird. Is there a new round robin IPI feature in the kernel that I am not

Re: [PATCH] make __section_nr more efficient

On 2016/7/21 5:36, Dave Hansen wrote: On 07/19/2016 09:18 PM, Zhou Chengming wrote: When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Does this actually *do* anything? It was a long time ago, but if I remember correctly, the

Re: [PATCH] make __section_nr more efficient

On 2016/7/21 5:36, Dave Hansen wrote: On 07/19/2016 09:18 PM, Zhou Chengming wrote: When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Does this actually *do* anything? It was a long time ago, but if I remember correctly, the

[PATCH v2 1/3] pmem: clarify a debug print in pmem_clear_poison

Prefix the sector number being cleared with a '0x' to make it clear that this is a hex value. Signed-off-by: Vishal Verma --- drivers/nvdimm/pmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index

[PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand

Normally, an ARS (Address Range Scrub) only happens at boot/initialization time. There can however arise situations where a bus-wide rescan is needed - notably, in the case of discovering a latent media error, we should do a full rescan to figure out what other sectors are bad, and thus

[PATCH v2 1/3] pmem: clarify a debug print in pmem_clear_poison

Prefix the sector number being cleared with a '0x' to make it clear that this is a hex value. Signed-off-by: Vishal Verma --- drivers/nvdimm/pmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 608fc44..08ac2cb 100644 ---

[PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand

Normally, an ARS (Address Range Scrub) only happens at boot/initialization time. There can however arise situations where a bus-wide rescan is needed - notably, in the case of discovering a latent media error, we should do a full rescan to figure out what other sectors are bad, and thus

[PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error

When a latent (unknown to 'badblocks') error is encountered, it will trigger a machine check exception. On a system with machine check recovery, this will only SIGBUS the process(es) which had the bad page mapped (as opposed to a kernel panic on platforms without machine check recovery features).

[PATCH v2 0/3] ARS rescanning triggered by latent errors or userspace

Changes in v2: - Rework the ars_done flag in nfit_spa to be ars_required, and reuse it for rescanning (Dan) - Rename the ars_rescan attribute to simply 'scrub', and move into the nfit group since only nfit buses have this capability (Dan) - Make the scrub attribute RW, and on reads return the

[PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error

When a latent (unknown to 'badblocks') error is encountered, it will trigger a machine check exception. On a system with machine check recovery, this will only SIGBUS the process(es) which had the bad page mapped (as opposed to a kernel panic on platforms without machine check recovery features).

[PATCH v2 0/3] ARS rescanning triggered by latent errors or userspace

Changes in v2: - Rework the ars_done flag in nfit_spa to be ars_required, and reuse it for rescanning (Dan) - Rename the ars_rescan attribute to simply 'scrub', and move into the nfit group since only nfit buses have this capability (Dan) - Make the scrub attribute RW, and on reads return the

  1   2   3   4   5   6   7   8   9   10   >