Re: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

Hi Andrew, On mer., janv. 25 2017, Andrew Lunn wrote: >> +[MV88E6341] = { >> +.prod_num = PORT_SWITCH_ID_PROD_NUM_6341, >> +.family = MV88E6XXX_FAMILY_6341, >> +.name = "Marvell 88E6341", >> +.num_databases = 4096, >> +

Re: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

Hi Andrew, On mer., janv. 25 2017, Andrew Lunn wrote: >> +[MV88E6341] = { >> +.prod_num = PORT_SWITCH_ID_PROD_NUM_6341, >> +.family = MV88E6XXX_FAMILY_6341, >> +.name = "Marvell 88E6341", >> +.num_databases = 4096, >> +.num_ports

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote: > Hi Richard, > > On 24 January 2017 at 19:18, Richard Genoud wrote: >> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"), >> the USB ports on odroid-XU4 don't work anymore.

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote: > Hi Richard, > > On 24 January 2017 at 19:18, Richard Genoud wrote: >> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"), >> the USB ports on odroid-XU4 don't work anymore. >> >> Inserting an usb key (USB2.0) on the USB3.0

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

SF Markus Elfring wrote: > A local variable was set to an error code in two cases before a concrete > error situation was detected. And why would that be a problem? http://yarchive.net/comp/linux/error_jumps.html > - ret = -EBUSY; > - if (state.busy) > + if (state.busy) { > +

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

SF Markus Elfring wrote: > A local variable was set to an error code in two cases before a concrete > error situation was detected. And why would that be a problem? http://yarchive.net/comp/linux/error_jumps.html > - ret = -EBUSY; > - if (state.busy) > + if (state.busy) { > +

Re: linux-next: manual merge of the kselftest tree with the net-next tree

On 01/25/2017 05:03 AM, Stephen Rothwell wrote: Hi Shuah, Today's linux-next merge of the kselftest tree got a conflict in: tools/testing/selftests/bpf/Makefile between commit: 62b64660262a ("bpf: add prog tag test case to bpf selftests") from the net-next tree and commit:

Re: linux-next: manual merge of the kselftest tree with the net-next tree

On 01/25/2017 05:03 AM, Stephen Rothwell wrote: Hi Shuah, Today's linux-next merge of the kselftest tree got a conflict in: tools/testing/selftests/bpf/Makefile between commit: 62b64660262a ("bpf: add prog tag test case to bpf selftests") from the net-next tree and commit:

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

Hi Jon, hi Daniel ! Am 25.01.2017 um 07:37 schrieb Daniel Vetter : >> Again, quick comments... >> >> - I would *much* rather evolve our existing Sphinx extension in the >> direction we want it to go than to just replace it wholesale. >> Replacement is the wrong approach for

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

Hi Jon, hi Daniel ! Am 25.01.2017 um 07:37 schrieb Daniel Vetter : >> Again, quick comments... >> >> - I would *much* rather evolve our existing Sphinx extension in the >> direction we want it to go than to just replace it wholesale. >> Replacement is the wrong approach for a few reasons,

Re: [PATCH] x86/gpu: GLK uses the same GMS values as SKL

* Paulo Zanoni wrote: > So don't forget to reserve its stolen memory bits. > > Cc: Ingo Molnar > Cc: H. Peter Anvin > Cc: Ander Conselvan de Oliveira > Cc: x...@kernel.org > Reviewed-by: Ander

Re: [PATCH] x86/gpu: GLK uses the same GMS values as SKL

* Paulo Zanoni wrote: > So don't forget to reserve its stolen memory bits. > > Cc: Ingo Molnar > Cc: H. Peter Anvin > Cc: Ander Conselvan de Oliveira > Cc: x...@kernel.org > Reviewed-by: Ander Conselvan de Oliveira > > Signed-off-by: Paulo Zanoni > --- > arch/x86/kernel/early-quirks.c |

Re: [PATCH 2/2] perf tools: Introduce regs_query_register_offset() for arm64

hi 在 2017/1/25 3:09, Arnaldo Carvalho de Melo 写道: Em Tue, Jan 24, 2017 at 06:25:18PM +, Will Deacon escreveu: On Tue, Jan 24, 2017 at 10:30:15AM +, He Kuang wrote: Since HAVE_KPROBES can be enabled in arm64, this patch introduces regs_query_register_offset() to convert register name

Re: [PATCH 2/2] perf tools: Introduce regs_query_register_offset() for arm64

hi 在 2017/1/25 3:09, Arnaldo Carvalho de Melo 写道: Em Tue, Jan 24, 2017 at 06:25:18PM +, Will Deacon escreveu: On Tue, Jan 24, 2017 at 10:30:15AM +, He Kuang wrote: Since HAVE_KPROBES can be enabled in arm64, this patch introduces regs_query_register_offset() to convert register name

[PATCH 2/2 v2] perf tools: Enable bpf prologue for arm64

Since HAVE_KPROBES can be enabled in arm64, this patch introduces regs_query_register_offset() to convert register name to offset for arm64, so the BPF prologue feature is ready to use. This patch also changes the 'dwarfnum' to 'offset' in register table, so the related functions are consistent

[PATCH 2/2 v2] perf tools: Enable bpf prologue for arm64

Since HAVE_KPROBES can be enabled in arm64, this patch introduces regs_query_register_offset() to convert register name to offset for arm64, so the BPF prologue feature is ready to use. This patch also changes the 'dwarfnum' to 'offset' in register table, so the related functions are consistent

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, On 25 January 2017 at 14:46, Fu Wei wrote: > Hi Mark, > > On 25 January 2017 at 01:24, Mark Rutland wrote: >> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote: >>> From: Fu Wei >>> >>> The counter frequency

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, On 25 January 2017 at 14:46, Fu Wei wrote: > Hi Mark, > > On 25 January 2017 at 01:24, Mark Rutland wrote: >> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote: >>> From: Fu Wei >>> >>> The counter frequency detection call(arch_timer_detect_rate) combines two >>> ways

Re: [patch] {1620} net: hns3: add dcb cap flag in init sequence

it is misoperation, please ignore. sorry to interrupt you! On 2017/1/25 15:26, Kejian Yan wrote: > If enable DCB feature, we need to add the capacity, and the current > procedure cannot setting the dcb because of no capacity flag and every > ops interface will implement by the capicity flag is

Re: [patch] {1620} net: hns3: add dcb cap flag in init sequence

it is misoperation, please ignore. sorry to interrupt you! On 2017/1/25 15:26, Kejian Yan wrote: > If enable DCB feature, we need to add the capacity, and the current > procedure cannot setting the dcb because of no capacity flag and every > ops interface will implement by the capicity flag is

[patch] {1620} net: hns3: add dcb cap flag in init sequence

If enable DCB feature, we need to add the capacity, and the current procedure cannot setting the dcb because of no capacity flag and every ops interface will implement by the capicity flag is enable. Signed-off-by: Kejian Yan ---

[patch] {1620} net: hns3: add dcb cap flag in init sequence

If enable DCB feature, we need to add the capacity, and the current procedure cannot setting the dcb because of no capacity flag and every ops interface will implement by the capicity flag is enable. Signed-off-by: Kejian Yan --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 6

Re: [RFC PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

hi, sorry to disturb, I will send another version to make a minor change about page_lock checking in scan_movable_pages. On 2017/1/25 11:25, Yisheng Xie wrote: > We had considered all of the non-lru pages as unmovable before > commit bda807d44454 ("mm: migrate: support non-lru movable page >

Re: [RFC PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

hi, sorry to disturb, I will send another version to make a minor change about page_lock checking in scan_movable_pages. On 2017/1/25 11:25, Yisheng Xie wrote: > We had considered all of the non-lru pages as unmovable before > commit bda807d44454 ("mm: migrate: support non-lru movable page >

[RFC v2 PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

We had considered all of the non-lru pages as unmovable before commit bda807d44454 ("mm: migrate: support non-lru movable page migration"). But now some of non-lru pages like zsmalloc, virtio-balloon pages also become movable. So we can offline such blocks by using non-lru page migration. This

[RFC v2 PATCH] mm/hotplug: enable memory hotplug for non-lru movable pages

We had considered all of the non-lru pages as unmovable before commit bda807d44454 ("mm: migrate: support non-lru movable page migration"). But now some of non-lru pages like zsmalloc, virtio-balloon pages also become movable. So we can offline such blocks by using non-lru page migration. This

Re: [PATCH 2/3] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Tuesday, January 24, 2017 8:41 PM Michal Hocko wrote: > On Fri 20-01-17 16:33:36, Hillf Danton wrote: > > > > On Tuesday, December 20, 2016 9:49 PM Michal Hocko wrote: > > > > > > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc) > > >* make sure exclude 0 mask - all other

Re: [PATCH 2/3] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Tuesday, January 24, 2017 8:41 PM Michal Hocko wrote: > On Fri 20-01-17 16:33:36, Hillf Danton wrote: > > > > On Tuesday, December 20, 2016 9:49 PM Michal Hocko wrote: > > > > > > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc) > > >* make sure exclude 0 mask - all other

Re: [PATCH] memory: tegra: Add a missing 'of_node_put()' call

On Wed, Jan 04, 2017 at 08:13:24AM +0100, Christophe JAILLET wrote: > If 'of_find_device_by_node()' fails, an 'of_node_put()' call is missing in > the error handling path. > Fix it by reordering the code. > > While at it, remove some empty lines in a more or less similar construction > a few

Re: [PATCH] memory: tegra: Add a missing 'of_node_put()' call

On Wed, Jan 04, 2017 at 08:13:24AM +0100, Christophe JAILLET wrote: > If 'of_find_device_by_node()' fails, an 'of_node_put()' call is missing in > the error handling path. > Fix it by reordering the code. > > While at it, remove some empty lines in a more or less similar construction > a few

Re: [RESEND PATCH 0/6] apalis-tk1: updates for v1.1 hw

On Tue, Jan 03, 2017 at 01:20:48PM +, Marcel Ziswiler wrote: > On Thu, 2016-11-24 at 02:04 +0100, mar...@ziswiler.com wrote: > > From: Marcel Ziswiler > > > > > > This series updates the device tree for the upcoming V1.1 HW samples. > > All changes are purely

Re: [RESEND PATCH 0/6] apalis-tk1: updates for v1.1 hw

On Tue, Jan 03, 2017 at 01:20:48PM +, Marcel Ziswiler wrote: > On Thu, 2016-11-24 at 02:04 +0100, mar...@ziswiler.com wrote: > > From: Marcel Ziswiler > > > > > > This series updates the device tree for the upcoming V1.1 HW samples. > > All changes are purely opportunistic meaning they fix

Re: [PATCH] drm: tegra: shut up harmless warning on NOMMU

On Thu, Jan 19, 2017 at 04:09:47PM +0100, Arnd Bergmann wrote: > On Thursday, January 19, 2017 12:00:58 PM CET Thierry Reding wrote: > > On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote: > > > The tegra DRM driver is almost ok without an MMU, but there > > > is one small warning that

Re: [PATCH] drm: tegra: shut up harmless warning on NOMMU

On Thu, Jan 19, 2017 at 04:09:47PM +0100, Arnd Bergmann wrote: > On Thursday, January 19, 2017 12:00:58 PM CET Thierry Reding wrote: > > On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote: > > > The tegra DRM driver is almost ok without an MMU, but there > > > is one small warning that

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

Hi Dave, On Wednesday 25 January 2017 11:59 AM, Dave Young wrote: Hi Pratyush On 01/25/17 at 10:14am, Pratyush Anand wrote: Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is not true and could be misleading, since 0 is a valid physical address. I do not know the history

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

Hi Dave, On Wednesday 25 January 2017 11:59 AM, Dave Young wrote: Hi Pratyush On 01/25/17 at 10:14am, Pratyush Anand wrote: Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is not true and could be misleading, since 0 is a valid physical address. I do not know the history

Re: [PATCH] nvdimm: constify device_type structures

On Tue, 24 Jan 2017, Joe Perches wrote: > On Tue, 2017-01-24 at 18:40 -0800, Dan Williams wrote: > > On Tue, Jan 24, 2017 at 6:37 PM, Joe Perches wrote: > > > On Wed, 2017-01-25 at 00:54 +0530, Bhumika Goyal wrote: > > > > Declare device_type structure as const as it is only

Re: [PATCH] nvdimm: constify device_type structures

On Tue, 24 Jan 2017, Joe Perches wrote: > On Tue, 2017-01-24 at 18:40 -0800, Dan Williams wrote: > > On Tue, Jan 24, 2017 at 6:37 PM, Joe Perches wrote: > > > On Wed, 2017-01-25 at 00:54 +0530, Bhumika Goyal wrote: > > > > Declare device_type structure as const as it is only stored in the > >

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

Hi Gideon, [auto build test ERROR on m68k/for-next] [also build test ERROR on v4.10-rc5 next-20170124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gideon-Israel-Dsouza/compiler-gcc-h-Added

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

Hi Gideon, [auto build test ERROR on m68k/for-next] [also build test ERROR on v4.10-rc5 next-20170124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gideon-Israel-Dsouza/compiler-gcc-h-Added

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, On 25 January 2017 at 01:24, Mark Rutland wrote: > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote: >> From: Fu Wei >> >> The counter frequency detection call(arch_timer_detect_rate) combines two >> ways to get counter

[GIT PULL] extcon next for v4.11

Dear Greg, This is extcon-next pull request for v4.11. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08

Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.

Hi Mark, On 25 January 2017 at 01:24, Mark Rutland wrote: > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote: >> From: Fu Wei >> >> The counter frequency detection call(arch_timer_detect_rate) combines two >> ways to get counter frequency: system coprocessor register and MMIO

[GIT PULL] extcon next for v4.11

Dear Greg, This is extcon-next pull request for v4.11. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8: Linux 4.10-rc3 (2017-01-08

Re: [1/6] apalis-tk1: remove spurious new lines

On Tue, Nov 22, 2016 at 01:14:02AM +0100, Marcel Ziswiler wrote: > Remove some spurious new lines. > > Signed-off-by: Marcel Ziswiler > --- For some reason I can't find any trace of this series in my inbox. It's not even been classified as spam, it's just not there.

Re: [1/6] apalis-tk1: remove spurious new lines

On Tue, Nov 22, 2016 at 01:14:02AM +0100, Marcel Ziswiler wrote: > Remove some spurious new lines. > > Signed-off-by: Marcel Ziswiler > --- For some reason I can't find any trace of this series in my inbox. It's not even been classified as spam, it's just not there. So I had to pull this from

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

AKA it should be this fix that removes the need for your dumpable setting. bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission checks") I will check, though from what I recall that patch doesn't fix the ptrace_may_access checks. Not to mention it won't help if the

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

AKA it should be this fix that removes the need for your dumpable setting. bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace permission checks") I will check, though from what I recall that patch doesn't fix the ptrace_may_access checks. Not to mention it won't help if the

Re: [RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

On Tue, Jan 24, 2017 at 08:52:41PM +0100, Markus Heiser wrote: > this patch adds a command to lint kernel-doc comments.:: > > scripts/kerneldoc-lint --help > > The lint check include (only) kernel-doc rules described at [1]. It > does not check against reST (sphinx-doc) markup used in the

Re: [RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

On Tue, Jan 24, 2017 at 08:52:41PM +0100, Markus Heiser wrote: > this patch adds a command to lint kernel-doc comments.:: > > scripts/kerneldoc-lint --help > > The lint check include (only) kernel-doc rules described at [1]. It > does not check against reST (sphinx-doc) markup used in the

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

On Tue, Jan 24, 2017 at 05:13:14PM -0700, Jonathan Corbet wrote: > On Tue, 24 Jan 2017 20:52:40 +0100 > Markus Heiser wrote: > > > This patch is the initial merge of a pure python implementation > > to parse kernel-doc comments and generate reST from. > > > > It

Re: [RFC PATCH v1 2/6] kernel-doc: replace kernel-doc perl parser with a pure python one (WIP)

On Tue, Jan 24, 2017 at 05:13:14PM -0700, Jonathan Corbet wrote: > On Tue, 24 Jan 2017 20:52:40 +0100 > Markus Heiser wrote: > > > This patch is the initial merge of a pure python implementation > > to parse kernel-doc comments and generate reST from. > > > > It consist mainly of to parts, the

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

Hi Pratyush On 01/25/17 at 10:14am, Pratyush Anand wrote: > Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is > not true and could be misleading, since 0 is a valid physical address. I do not know the history of /proc/kcore, so a question is why the p_addr was set as 0, if

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

Hi Pratyush On 01/25/17 at 10:14am, Pratyush Anand wrote: > Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is > not true and could be misleading, since 0 is a valid physical address. I do not know the history of /proc/kcore, so a question is why the p_addr was set as 0, if

Re: [PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

On Sat, Jan 14, 2017 at 11:05:54AM +0530, Kedareswara rao Appana wrote: > When VDMA is configured for more than one frame in the h/w. > For example h/w is configured for n number of frames, user > Submits n number of frames and triggered the DMA using issue_pending API. > > In the current driver

Re: [PATCH v6 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

On Sat, Jan 14, 2017 at 11:05:54AM +0530, Kedareswara rao Appana wrote: > When VDMA is configured for more than one frame in the h/w. > For example h/w is configured for n number of frames, user > Submits n number of frames and triggered the DMA using issue_pending API. > > In the current driver

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

Hi Richard, On 24 January 2017 at 19:18, Richard Genoud wrote: > Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"), > the USB ports on odroid-XU4 don't work anymore. > > Inserting an usb key (USB2.0) on the USB3.0 port result in: > [ 64.488264]

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

Hi Richard, On 24 January 2017 at 19:18, Richard Genoud wrote: > Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"), > the USB ports on odroid-XU4 don't work anymore. > > Inserting an usb key (USB2.0) on the USB3.0 port result in: > [ 64.488264] xhci-hcd xhci-hcd.2.auto:

linux-next: Tree for Jan 25

Hi all, There will be no linux-next release until Monday (next-20170130). Changes since 20170124: New tree: extable The drm tree still had its build failure so I used the version from next-20170123. The userns tree gained a conflict against the selinux tree. The kselftest tree gained

linux-next: Tree for Jan 25

Hi all, There will be no linux-next release until Monday (next-20170130). Changes since 20170124: New tree: extable The drm tree still had its build failure so I used the version from next-20170123. The userns tree gained a conflict against the selinux tree. The kselftest tree gained

IOAT 4.0 driver not supported on Intel 5000 chipset

Hello Vinod/Dave, I have an old X86 system with 'Intel(R) Xeon(R) CPU X5450' which has '5000 Series Chipset'. The latest mainline IOAT driver does not work on it. Dont see /sys/class/dma getting filled up with channel details even if I manually load both dca.ko followed by ioatdma.ko drivers

IOAT 4.0 driver not supported on Intel 5000 chipset

Hello Vinod/Dave, I have an old X86 system with 'Intel(R) Xeon(R) CPU X5450' which has '5000 Series Chipset'. The latest mainline IOAT driver does not work on it. Dont see /sys/class/dma getting filled up with channel details even if I manually load both dca.ko followed by ioatdma.ko drivers

Re: [PATCH] mm: extend zero pages to same element pages for zram

On Wed, Jan 25, 2017 at 02:38:49PM +0900, Sergey Senozhatsky wrote: > On (01/25/17 13:51), Minchan Kim wrote: > [..] > > > Minchan, zhouxianrong, I was completely wrong. we can't > > > do memset(). d'oh, I did not know it truncates 4 bytes to > > > one byte only (doesn't make too much sense to

Re: [PATCH] mm: extend zero pages to same element pages for zram

On Wed, Jan 25, 2017 at 02:38:49PM +0900, Sergey Senozhatsky wrote: > On (01/25/17 13:51), Minchan Kim wrote: > [..] > > > Minchan, zhouxianrong, I was completely wrong. we can't > > > do memset(). d'oh, I did not know it truncates 4 bytes to > > > one byte only (doesn't make too much sense to

Re: [PATCH 31/37] misc: Add host side pci driver for pci test function device

Hi, On Tuesday 24 January 2017 09:32 PM, Christoph Hellwig wrote: > On Thu, Jan 12, 2017 at 03:56:20PM +0530, Kishon Vijay Abraham I wrote: >> Add PCI endpoint test driver that can verify base address >> register, legacy interrupt/MSI interrupt and read/write/copy >> buffers between host and

Re: [PATCH 31/37] misc: Add host side pci driver for pci test function device

Hi, On Tuesday 24 January 2017 09:32 PM, Christoph Hellwig wrote: > On Thu, Jan 12, 2017 at 03:56:20PM +0530, Kishon Vijay Abraham I wrote: >> Add PCI endpoint test driver that can verify base address >> register, legacy interrupt/MSI interrupt and read/write/copy >> buffers between host and

[PATCH net-next] r8152: fix the wrong spelling

Replace rumtime with runtime. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f3b48ad..d59d773 100644 --- a/drivers/net/usb/r8152.c +++

[PATCH net-next] r8152: fix the wrong spelling

Replace rumtime with runtime. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f3b48ad..d59d773 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c

Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings

On 25/01/2017 04:38, Guochun Mao wrote: > Add "mediatek,mt2701-nor" for nor flash node's compatible. > > Signed-off-by: Guochun Mao > --- > .../devicetree/bindings/mtd/mtk-quadspi.txt|8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff

Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings

On 25/01/2017 04:38, Guochun Mao wrote: > Add "mediatek,mt2701-nor" for nor flash node's compatible. > > Signed-off-by: Guochun Mao > --- > .../devicetree/bindings/mtd/mtk-quadspi.txt|8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH] mm: extend zero pages to same element pages for zram

On (01/25/17 13:51), Minchan Kim wrote: [..] > > Minchan, zhouxianrong, I was completely wrong. we can't > > do memset(). d'oh, I did not know it truncates 4 bytes to > > one byte only (doesn't make too much sense to me). > > Now, I read Matthew's comment and understood. Thanks. > It means

Re: [PATCH] mm: extend zero pages to same element pages for zram

On (01/25/17 13:51), Minchan Kim wrote: [..] > > Minchan, zhouxianrong, I was completely wrong. we can't > > do memset(). d'oh, I did not know it truncates 4 bytes to > > one byte only (doesn't make too much sense to me). > > Now, I read Matthew's comment and understood. Thanks. > It means

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

On Tue, 2017-01-24 at 21:07 -0200, Fabio Estevam wrote: > On Tue, Jan 24, 2017 at 8:46 PM, Pavel Machek wrote: > > > > > It is an ugly regression and it is -rc5 time. Actually not your > > problem, but Fabio Estevam or Zhang Rui has to deal with it soon. > I have already sent the

Re: v4.10-rc4 to v4.10-rc5: battery regression on Nokia N900

On Tue, 2017-01-24 at 21:07 -0200, Fabio Estevam wrote: > On Tue, Jan 24, 2017 at 8:46 PM, Pavel Machek wrote: > > > > > It is an ugly regression and it is -rc5 time. Actually not your > > problem, but Fabio Estevam or Zhang Rui has to deal with it soon. > I have already sent the revert and it

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, On 01/24/2017 04:20 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Hi Ingo, >> >> On 01/22/2017 05:04 PM, Ingo Molnar wrote: >>> * Lu Baolu wrote: >>> >> +static void xdbc_runtime_delay(unsigned long count) >> +{ >> +

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, On 01/24/2017 04:20 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Hi Ingo, >> >> On 01/22/2017 05:04 PM, Ingo Molnar wrote: >>> * Lu Baolu wrote: >>> >> +static void xdbc_runtime_delay(unsigned long count) >> +{ >> +udelay(count); >> +} >> +static void

[PATCH] ARM: dts: imx53-qsb-common: fix FEC pinmux config

From: Patrick Bruenn The pinmux configuration in device tree was different from manual muxing in /board/freescale/mx53loco/mx53loco.c All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us. But recently

[PATCH] ARM: dts: imx53-qsb-common: fix FEC pinmux config

From: Patrick Bruenn The pinmux configuration in device tree was different from manual muxing in /board/freescale/mx53loco/mx53loco.c All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us. But recently u-boot is migrating to

linux-next: manual merge of the akpm-current tree with the userns tree

Hi all, Today's linux-next merge of the akpm-current tree got a conflict in: fs/proc/base.c between commit: 68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user namespaces") from the userns tree and commit: d15d29b5352f ("procfs: change the owner of

linux-next: manual merge of the akpm-current tree with the userns tree

Hi all, Today's linux-next merge of the akpm-current tree got a conflict in: fs/proc/base.c between commit: 68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user namespaces") from the userns tree and commit: d15d29b5352f ("procfs: change the owner of

Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

On Wed, 25 Jan 2017 10:50:51 +0800 Hayes Wang wrote: > Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() > from calling napi_schedule() directly during runtime suspend. > > After calling napi_disable() or clearing the flag of WORK_ENABLE, >

Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

On Wed, 25 Jan 2017 10:50:51 +0800 Hayes Wang wrote: > Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() > from calling napi_schedule() directly during runtime suspend. > > After calling napi_disable() or clearing the flag of WORK_ENABLE, > scheduling the napi is

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

Hi Lee, After merging the mfd tree, today's linux-next build (powerpc allyesconfig) produced this warning: drivers/pwm/pwm-stm32.c: In function 'stm32_pwm_apply': drivers/pwm/pwm-stm32.c:204:33: warning: 'curstate.polarity' may be used uninitialized in this function [-Wmaybe-uninitialized] if

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

Hi Lee, After merging the mfd tree, today's linux-next build (powerpc allyesconfig) produced this warning: drivers/pwm/pwm-stm32.c: In function 'stm32_pwm_apply': drivers/pwm/pwm-stm32.c:204:33: warning: 'curstate.polarity' may be used uninitialized in this function [-Wmaybe-uninitialized] if

Re: [PATCH] mm: extend zero pages to same element pages for zram

On Wed, Jan 25, 2017 at 01:18:58PM +0900, Sergey Senozhatsky wrote: > On (01/24/17 18:48), Matthew Wilcox wrote: > > On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote: > > > Hello, > > > > > > On (01/25/17 10:29), Minchan Kim wrote: > > > [..] > > > > > the result as listed

Re: [PATCH] mm: extend zero pages to same element pages for zram

On Wed, Jan 25, 2017 at 01:18:58PM +0900, Sergey Senozhatsky wrote: > On (01/24/17 18:48), Matthew Wilcox wrote: > > On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote: > > > Hello, > > > > > > On (01/25/17 10:29), Minchan Kim wrote: > > > [..] > > > > > the result as listed

Re: [PATCH 1/2] compiler-gcc.h: Added new macro for gcc attribute

>#define __mode(x) __attribute__((mode(x))) Well that's embarrassing. I so sorry for the trouble guys :( I'll resend this. On Wed, Jan 25, 2017 at 7:20 AM, Joe Perches wrote: > On Tue, 2017-01-24 at 17:44 +0530, Gideon Israel Dsouza wrote: >> Added __mode(x) into

Re: [PATCH 1/2] compiler-gcc.h: Added new macro for gcc attribute

>#define __mode(x) __attribute__((mode(x))) Well that's embarrassing. I so sorry for the trouble guys :( I'll resend this. On Wed, Jan 25, 2017 at 7:20 AM, Joe Perches wrote: > On Tue, 2017-01-24 at 17:44 +0530, Gideon Israel Dsouza wrote: >> Added __mode(x) into compiler-gcc.h as part of

[PATCH] /proc/kcore: Update physical address for kcore ram and text

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is not true and could be misleading, since 0 is a valid physical address. User space tools like makedumpfile needs to know physical address for PT_LOAD segments of direct mapped regions. Therefore this patch updates paddr for

[PATCH] /proc/kcore: Update physical address for kcore ram and text

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is not true and could be misleading, since 0 is a valid physical address. User space tools like makedumpfile needs to know physical address for PT_LOAD segments of direct mapped regions. Therefore this patch updates paddr for

[PATCH] nsproxy: Reuse already available put_nsproxy helper function.

This patch makes use of already available put_nsproxy() helper function which already perform atomic check and conditional free. It also remove braces in put_nsproxy() for single line conditional statement. Minor fixes for trailing white space, 80 characters etc warnings reported by checkpatch.pl.

[PATCH] nsproxy: Reuse already available put_nsproxy helper function.

This patch makes use of already available put_nsproxy() helper function which already perform atomic check and conditional free. It also remove braces in put_nsproxy() for single line conditional statement. Minor fixes for trailing white space, 80 characters etc warnings reported by checkpatch.pl.

[Bug fix]mips 64bits checksum error -- csum_tcpudp_nofold

If the input parameters as saddr = 0xc0a8fd60,daddr = 0xc0a8fda1,len = 80, proto = 17, sum =0x7eae049d. The correct result should be 1, but original function return 0. Attached the correction patch. 0001-Fixed-the-mips-64bits-checksum-error-csum_tcpudp_nof.patch Description: Binary data

[Bug fix]mips 64bits checksum error -- csum_tcpudp_nofold

If the input parameters as saddr = 0xc0a8fd60,daddr = 0xc0a8fda1,len = 80, proto = 17, sum =0x7eae049d. The correct result should be 1, but original function return 0. Attached the correction patch. 0001-Fixed-the-mips-64bits-checksum-error-csum_tcpudp_nof.patch Description: Binary data

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

On 01/24, Michal Hocko wrote: >On Mon 23-01-17 09:26:44, kernel test robot wrote: >> >> Greeting, >> >> FYI, we noticed a -11.1% regression of fsmark.files_per_sec due to commit: >> >> >> commit: 5e56dfbd837421b7fa3c6c06018c6701e2704917 ("mm, vmscan: consider >> eligible zones in

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

On 01/24, Michal Hocko wrote: >On Mon 23-01-17 09:26:44, kernel test robot wrote: >> >> Greeting, >> >> FYI, we noticed a -11.1% regression of fsmark.files_per_sec due to commit: >> >> >> commit: 5e56dfbd837421b7fa3c6c06018c6701e2704917 ("mm, vmscan: consider >> eligible zones in

Re: [PATCH] mm: extend zero pages to same element pages for zram

On (01/24/17 18:48), Matthew Wilcox wrote: > On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote: > > Hello, > > > > On (01/25/17 10:29), Minchan Kim wrote: > > [..] > > > > the result as listed below: > > > > > > > > zeropattern_char pattern_short pattern_int

Re: [PATCH] mm: extend zero pages to same element pages for zram

On (01/24/17 18:48), Matthew Wilcox wrote: > On Wed, Jan 25, 2017 at 10:32:44AM +0900, Sergey Senozhatsky wrote: > > Hello, > > > > On (01/25/17 10:29), Minchan Kim wrote: > > [..] > > > > the result as listed below: > > > > > > > > zeropattern_char pattern_short pattern_int

linux-next: manual merge of the userns tree with the selinux tree

Hi Eric, Today's linux-next merge of the userns tree got a conflict in: security/selinux/hooks.c between commit: be0554c9bf9f ("selinux: clean up cred usage and simplify") from the selinux tree and commit: 9227dd2a84a7 ("exec: Remove LSM_UNSAFE_PTRACE_CAP") from the userns tree. I

linux-next: manual merge of the userns tree with the selinux tree

Hi Eric, Today's linux-next merge of the userns tree got a conflict in: security/selinux/hooks.c between commit: be0554c9bf9f ("selinux: clean up cred usage and simplify") from the selinux tree and commit: 9227dd2a84a7 ("exec: Remove LSM_UNSAFE_PTRACE_CAP") from the userns tree. I

  1   2   3   4   5   6   7   8   9   10   >