RE: [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

Hi Bjorn, > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Thursday, September 22, 2016 6:38 AM > To: Po Liu > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Roy Zang;

RE: [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

Hi Bjorn, > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Thursday, September 22, 2016 6:38 AM > To: Po Liu > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Roy Zang;

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7d1e042314619115153a0f6f06e4552c09a50e13 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7d1e042314619115153a0f6f06e4552c09a50e13 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez wrote: > On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote: >> From: Daniel Wagner >> >> The lock is also used to generate warnings when a direct >> firmware load is requested too early.

Re: [PATCH v5 1/5] firmware: document user mode helper lock usage

On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez wrote: > On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote: >> From: Daniel Wagner >> >> The lock is also used to generate warnings when a direct >> firmware load is requested too early. > > I've determined the firmware cache lets us

[PATCH net-next v2 2/3] net: ethernet: mediatek: add support for GMAC0 connecting with external PHY through TRGMII

From: Sean Wang Changing dynamically source clock, TX/RX delay and interface mode used by TRGMII hardware module inside PHY capability polling routine for adapting to the various speed of RGMII used by external PHY for GMAC0. Signed-off-by: Sean Wang

[PATCH net-next v2 2/3] net: ethernet: mediatek: add support for GMAC0 connecting with external PHY through TRGMII

From: Sean Wang Changing dynamically source clock, TX/RX delay and interface mode used by TRGMII hardware module inside PHY capability polling routine for adapting to the various speed of RGMII used by external PHY for GMAC0. Signed-off-by: Sean Wang ---

[PATCH net-next v2 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII

From: Sean Wang adds PHY-mode "trgmii" as an extension for the operation mode of the PHY interface for PHY_INTERFACE_MODE_TRGMII. and adds a variable trgmii inside mtk_mac as the indication to make the difference between the MAC connected to internal switch or connected

[PATCH net-next v2 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0

From: Sean Wang Add the dts property for the capability if TRGMII supported on GAMC0 Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/net/mediatek-net.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH net-next v2 1/3] net: ethernet: mediatek: add extension of phy-mode for TRGMII

From: Sean Wang adds PHY-mode "trgmii" as an extension for the operation mode of the PHY interface for PHY_INTERFACE_MODE_TRGMII. and adds a variable trgmii inside mtk_mac as the indication to make the difference between the MAC connected to internal switch or connected to external PHY by the

[PATCH net-next v2 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0

From: Sean Wang Add the dts property for the capability if TRGMII supported on GAMC0 Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/net/mediatek-net.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module

From: Sean Wang By default, GMAC0 is connected to built-in switch called MT7530 through the proprietary interface called Turbo RGMII (TRGMII). TRGMII also supports well for RGMII as generic external PHY uses but requires some slight changes to the setup of TRGMII and

[PATCH net-next v2 0/3] add support for RGMII on GMAC0 through TRGMII hardware module

From: Sean Wang By default, GMAC0 is connected to built-in switch called MT7530 through the proprietary interface called Turbo RGMII (TRGMII). TRGMII also supports well for RGMII as generic external PHY uses but requires some slight changes to the setup of TRGMII and doesn't have well support

Re: + softirq-fix-tasklet_kill-and-its-users.patch added to -mm tree

On 9/21/2016 5:42 PM, Sergey Senozhatsky wrote: Hello, On (09/21/16 10:23), Santosh Shilimkar wrote: [...] Am assuming one of the driver in your test is using the DECLARE_TASKLET to init the tasklet and killed by tasklet_kill() which leaves that tasklet to be still scheduled by tasklet

Re: + softirq-fix-tasklet_kill-and-its-users.patch added to -mm tree

On 9/21/2016 5:42 PM, Sergey Senozhatsky wrote: Hello, On (09/21/16 10:23), Santosh Shilimkar wrote: [...] Am assuming one of the driver in your test is using the DECLARE_TASKLET to init the tasklet and killed by tasklet_kill() which leaves that tasklet to be still scheduled by tasklet

Re: [BUG] perf report --pid not reporting correctly

On Wed, Sep 21, 2016 at 6:34 PM, Namhyung Kim wrote: > On Wed, Sep 21, 2016 at 01:18:52PM -0700, Stephane Eranian wrote: >> On Wed, Sep 21, 2016 at 9:34 AM, Jiri Olsa wrote: >> > On Wed, Sep 21, 2016 at 12:37:53PM -0300, Arnaldo Carvalho de Melo wrote: >>

Re: [BUG] perf report --pid not reporting correctly

On Wed, Sep 21, 2016 at 6:34 PM, Namhyung Kim wrote: > On Wed, Sep 21, 2016 at 01:18:52PM -0700, Stephane Eranian wrote: >> On Wed, Sep 21, 2016 at 9:34 AM, Jiri Olsa wrote: >> > On Wed, Sep 21, 2016 at 12:37:53PM -0300, Arnaldo Carvalho de Melo wrote: >> >> Em Tue, Sep 20, 2016 at 06:29:59PM

Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi, 河合英宏 Thanks for the patch log update, it looks good to me. Acked-by: Dave Young On 09/20/16 at 11:22am, 河合英宏 / KAWAI，HIDEHIRO wrote: > Here is the revised commit description reflecting Dave's > comment. Cc list was copied from -mm version. > > From: Hidehiro Kawai

Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi, 河合英宏 Thanks for the patch log update, it looks good to me. Acked-by: Dave Young On 09/20/16 at 11:22am, 河合英宏 / KAWAI，HIDEHIRO wrote: > Here is the revised commit description reflecting Dave's > comment. Cc list was copied from -mm version. > > From: Hidehiro Kawai > Subject: x86/panic:

Re: pull-request: wireless-drivers 2016-09-20

From: Kalle Valo Date: Tue, 20 Sep 2016 13:20:46 +0300 > last pull request for 4.8, unless something really drastic comes up. And > a small one even, just a small fix to iwlwifi to avoid a firmware crash. > > Please let me know if there are any problems. Pulled, thanks.

Re: pull-request: wireless-drivers 2016-09-20

From: Kalle Valo Date: Tue, 20 Sep 2016 13:20:46 +0300 > last pull request for 4.8, unless something really drastic comes up. And > a small one even, just a small fix to iwlwifi to avoid a firmware crash. > > Please let me know if there are any problems. Pulled, thanks.

[PATCH] usb: dwc2: add USBTrdTim to initial value

After dwc2_core_reset，register is to the initial value, and the USBTrdTim vale is 0x5. If hsotg->phyif = GUSBCFG_PHYIF8, after the dwc2_writel,the value is 0xd.So we need to set the USBTrdTim to 0. Signed-off-by: Pengcheng Li --- drivers/usb/dwc2/gadget.c | 4 ++-- 1 file

[PATCH] usb: dwc2: add USBTrdTim to initial value

After dwc2_core_reset，register is to the initial value, and the USBTrdTim vale is 0x5. If hsotg->phyif = GUSBCFG_PHYIF8, after the dwc2_writel,the value is 0xd.So we need to set the USBTrdTim to 0. Signed-off-by: Pengcheng Li --- drivers/usb/dwc2/gadget.c | 4 ++-- 1 file changed, 2

Re: [RFC PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

On 09/21/2016 12:23 PM, zijun_hu wrote: > From: zijun_hu > > correct a few logic error for __insert_vmap_area() since the else > if condition is always true and meaningless > > in order to fix this issue, if vmap_area inserted is lower than one > on rbtree then walk around

Re: [RFC PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

On 09/21/2016 12:23 PM, zijun_hu wrote: > From: zijun_hu > > correct a few logic error for __insert_vmap_area() since the else > if condition is always true and meaningless > > in order to fix this issue, if vmap_area inserted is lower than one > on rbtree then walk around left branch; if

Re: [BUG] perf report --pid not reporting correctly

On Wed, Sep 21, 2016 at 01:18:52PM -0700, Stephane Eranian wrote: > On Wed, Sep 21, 2016 at 9:34 AM, Jiri Olsa wrote: > > On Wed, Sep 21, 2016 at 12:37:53PM -0300, Arnaldo Carvalho de Melo wrote: > >> Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: > >> > Hi

Re: [BUG] perf report --pid not reporting correctly

On Wed, Sep 21, 2016 at 01:18:52PM -0700, Stephane Eranian wrote: > On Wed, Sep 21, 2016 at 9:34 AM, Jiri Olsa wrote: > > On Wed, Sep 21, 2016 at 12:37:53PM -0300, Arnaldo Carvalho de Melo wrote: > >> Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: > >> > Hi Arnaldo, > >> > >

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

On Wed, 2016-09-21 at 07:00 +0800, Ian Kent wrote: > On Wed, 2016-09-21 at 06:44 +0800, Ian Kent wrote: > > On Tue, 2016-09-20 at 11:50 -0500, Eric W. Biederman wrote: > > > Ian Kent writes: > > > > > > > On Sat, 2016-09-17 at 22:10 +0200, Mateusz Guzik wrote: > > > > > On Wed,

Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

On Wed, 2016-09-21 at 07:00 +0800, Ian Kent wrote: > On Wed, 2016-09-21 at 06:44 +0800, Ian Kent wrote: > > On Tue, 2016-09-20 at 11:50 -0500, Eric W. Biederman wrote: > > > Ian Kent writes: > > > > > > > On Sat, 2016-09-17 at 22:10 +0200, Mateusz Guzik wrote: > > > > > On Wed, Sep 14, 2016 at

Re: [PATCH] dmaengine: k3dma: fix off by one

On 2016年09月22日 04:16, Vincent Stehlé wrote: In k3_of_dma_simple_xlate(), the d->chans[] array has d->dma_requests elements so > should be >=. Fixes: 8e6152bc660e69f5 ("dmaengine: Add hisilicon k3 DMA engine driver") Signed-off-by: Vincent Stehlé Cc: Zhangfei Gao

Re: [PATCH] dmaengine: k3dma: fix off by one

On 2016年09月22日 04:16, Vincent Stehlé wrote: In k3_of_dma_simple_xlate(), the d->chans[] array has d->dma_requests elements so > should be >=. Fixes: 8e6152bc660e69f5 ("dmaengine: Add hisilicon k3 DMA engine driver") Signed-off-by: Vincent Stehlé Cc: Zhangfei Gao Cc: Vinod Koul Cc:

Re: [PATCH net-next 8/9] rxrpc: Reduce the number of PING ACKs sent

Hi David, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242 config: i386-randconfig-x009-201638 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce:

Re: [PATCH net-next 8/9] rxrpc: Reduce the number of PING ACKs sent

Hi David, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/David-Howells/rxrpc-Preparation-for-slow-start-algorithm/20160922-085242 config: i386-randconfig-x009-201638 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce:

Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On 09/22/2016 08:35 AM, David Rientjes wrote: > On Thu, 22 Sep 2016, zijun_hu wrote: > >> On 2016/9/22 5:21, David Rientjes wrote: >>> On Wed, 21 Sep 2016, zijun_hu wrote: >>> From: zijun_hu correct lazy_max_pages() return value if the number of online CPUs

Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On 09/22/2016 08:35 AM, David Rientjes wrote: > On Thu, 22 Sep 2016, zijun_hu wrote: > >> On 2016/9/22 5:21, David Rientjes wrote: >>> On Wed, 21 Sep 2016, zijun_hu wrote: >>> From: zijun_hu correct lazy_max_pages() return value if the number of online CPUs is power of 2

[PATCH] PCI: move cfg space size (256/4096) macros to pci_regs.h

This is a cleanup that moves PCI configuration space size macros (PCI_CFG_SPACE_SIZE and PCI_CFG_SPACE_EXP_SIZE) from drivers/pci/pci.h to include/uapi/linux/pci_regs.h So that the macros can be used by more drivers and eliminate potential duplicate definition. Signed-off-by: Wang Sheng-Hui

[PATCH] PCI: move cfg space size (256/4096) macros to pci_regs.h

This is a cleanup that moves PCI configuration space size macros (PCI_CFG_SPACE_SIZE and PCI_CFG_SPACE_EXP_SIZE) from drivers/pci/pci.h to include/uapi/linux/pci_regs.h So that the macros can be used by more drivers and eliminate potential duplicate definition. Signed-off-by: Wang Sheng-Hui ---

[PATCH v2 2/3] tools: move laptops dslm tool from Documentation

Move laptops dslm tool to tools/laptop/dslm and remove it from Documentation Makefile. Update location information for this tool. Create a new Makefile to build dslm. It can be built from top level directory or from laptops directory: Run make -C tools/laptop/dslm or cd tools/laptop/dslm; make

[PATCH v2 1/3] tools: move accounting tool from Documentation

Move accounting tool to tools and remove it from Documentation Makefile. Update location information for this tool. Create a new Makefile to build accounting. It can be built from top level directory or from accounting directory: Run make -C tools/accounting or cd tools/accounting; make

[PATCH v2 2/3] tools: move laptops dslm tool from Documentation

Move laptops dslm tool to tools/laptop/dslm and remove it from Documentation Makefile. Update location information for this tool. Create a new Makefile to build dslm. It can be built from top level directory or from laptops directory: Run make -C tools/laptop/dslm or cd tools/laptop/dslm; make

[PATCH v2 1/3] tools: move accounting tool from Documentation

Move accounting tool to tools and remove it from Documentation Makefile. Update location information for this tool. Create a new Makefile to build accounting. It can be built from top level directory or from accounting directory: Run make -C tools/accounting or cd tools/accounting; make

[PATCH v2 3/3] tools: move pcmcia crc32hash tool from Documentation

Move pcmcia crc32hash tool from Documentation to tools/pcmcia and remove it from Documentation Makefile. Update location information for this tool. Create a new Makefile to build pcmcia. It can be built from top level directory or from pcmcia directory: Run make -C tools/pcmcia or cd

[PATCH v2 3/3] tools: move pcmcia crc32hash tool from Documentation

Move pcmcia crc32hash tool from Documentation to tools/pcmcia and remove it from Documentation Makefile. Update location information for this tool. Create a new Makefile to build pcmcia. It can be built from top level directory or from pcmcia directory: Run make -C tools/pcmcia or cd

[PATCH v2 0/3] Move runnable tools from Documentation to tools

Move runnable tools from Documentation to tools. I moved just the tools code, and left documentation files as is. Based on the v1 series feedback, This v2 series moves accounting, laptops/dslm, and pcmcia to tools. If v2 patches look good, and if I get an okay, I will try to get these into

[PATCH v2 0/3] Move runnable tools from Documentation to tools

Move runnable tools from Documentation to tools. I moved just the tools code, and left documentation files as is. Based on the v1 series feedback, This v2 series moves accounting, laptops/dslm, and pcmcia to tools. If v2 patches look good, and if I get an okay, I will try to get these into

[PATCH net-next 8/9] rxrpc: Reduce the number of PING ACKs sent

We don't want to send a PING ACK for every new incoming call as that just adds to the network traffic. Instead, we send a PING ACK to the first three that we receive and then once per second thereafter. This could probably be made adjustable in future. Signed-off-by: David Howells

[PATCH net-next 8/9] rxrpc: Reduce the number of PING ACKs sent

We don't want to send a PING ACK for every new incoming call as that just adds to the network traffic. Instead, we send a PING ACK to the first three that we receive and then once per second thereafter. This could probably be made adjustable in future. Signed-off-by: David Howells ---

[PATCH net-next 7/9] rxrpc: Obtain RTT data by requesting ACKs on DATA packets

In addition to sending a PING ACK to gain RTT data, we can set the RXRPC_REQUEST_ACK flag on a DATA packet and get a REQUESTED-ACK ACK. The ACK packet contains the serial number of the packet it is in response to, so we can look through the Tx buffer for a matching DATA packet. This requires

[PATCH net-next 7/9] rxrpc: Obtain RTT data by requesting ACKs on DATA packets

In addition to sending a PING ACK to gain RTT data, we can set the RXRPC_REQUEST_ACK flag on a DATA packet and get a REQUESTED-ACK ACK. The ACK packet contains the serial number of the packet it is in response to, so we can look through the Tx buffer for a matching DATA packet. This requires

[PATCH net-next 6/9] rxrpc: Add ktime_sub_ms()

Add a ktime_sub_ms() to go with ktime_add_ms() and co. for use in AF_RXRPC RTT determination. Signed-off-by: David Howells --- include/linux/ktime.h |5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/ktime.h b/include/linux/ktime.h index

[PATCH net-next 6/9] rxrpc: Add ktime_sub_ms()

Add a ktime_sub_ms() to go with ktime_add_ms() and co. for use in AF_RXRPC RTT determination. Signed-off-by: David Howells --- include/linux/ktime.h |5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/ktime.h b/include/linux/ktime.h index 2b6a204bd8d4..aa118bad1407 100644

Re: [PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

Hello, On (09/21/16 20:08), Matt Fleming wrote: > On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote: > > > > I am not sure how the above call chain is realistic. But adding > > WARN_ON() into the scheduler paths is risky in general. > > It's not clear to me why this should be the case. WARN_ON()

Re: [PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

Hello, On (09/21/16 20:08), Matt Fleming wrote: > On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote: > > > > I am not sure how the above call chain is realistic. But adding > > WARN_ON() into the scheduler paths is risky in general. > > It's not clear to me why this should be the case. WARN_ON()

Re: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable generic "cache-references" and "cache-misses" events)

On 09/20/2016 03:56 PM, Vineet Gupta wrote: On 09/01/2016 01:33 AM, Peter Zijlstra wrote: - is that what perf event grouping is ? Again, nope. Perf event groups are single counter (so no implicit addition) that are co-scheduled on the PMU. I'm not sure I understand - does this require

Re: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable generic "cache-references" and "cache-misses" events)

On 09/20/2016 03:56 PM, Vineet Gupta wrote: On 09/01/2016 01:33 AM, Peter Zijlstra wrote: - is that what perf event grouping is ? Again, nope. Perf event groups are single counter (so no implicit addition) that are co-scheduled on the PMU. I'm not sure I understand - does this require

[PATCH net-next 4/9] rxrpc: Send pings to get RTT data

Send a PING ACK packet to the peer when we get a new incoming call from a peer we don't have a record for. The PING RESPONSE ACK packet will tell us the following about the peer: (1) its receive window size (2) its MTU sizes (3) its support for jumbo DATA packets (4) if it supports slow

Re: + softirq-fix-tasklet_kill-and-its-users.patch added to -mm tree

Hello, On (09/21/16 10:23), Santosh Shilimkar wrote: > > > > tasklet_init() == Init and Enable scheduling > > [..] > > > > @@ -559,7 +559,7 @@ void tasklet_init(struct tasklet_struct > > > > { > > > > t->next = NULL; > > > > t->state = 0; > > > > - atomic_set(>count, 0); >

[PATCH net-next 4/9] rxrpc: Send pings to get RTT data

Send a PING ACK packet to the peer when we get a new incoming call from a peer we don't have a record for. The PING RESPONSE ACK packet will tell us the following about the peer: (1) its receive window size (2) its MTU sizes (3) its support for jumbo DATA packets (4) if it supports slow

Re: + softirq-fix-tasklet_kill-and-its-users.patch added to -mm tree

Hello, On (09/21/16 10:23), Santosh Shilimkar wrote: > > > > tasklet_init() == Init and Enable scheduling > > [..] > > > > @@ -559,7 +559,7 @@ void tasklet_init(struct tasklet_struct > > > > { > > > > t->next = NULL; > > > > t->state = 0; > > > > - atomic_set(>count, 0); >

[PATCH net-next 5/9] rxrpc: Expedite ping response transmission

Expedite the transmission of a response to a PING ACK by sending it from sendmsg if one is pending. We're most likely to see a PING ACK during the client call Tx phase as the other side may use it to determine a number of parameters, such as the client's receive window size, the RTT and whether

[PATCH net-next 9/9] rxrpc: Reduce the number of ACK-Requests sent

Reduce the number of ACK-Requests we set on DATA packets that we're sending to reduce network traffic. We set the flag on odd-numbered DATA packets to start off the RTT cache until we have at least three entries in it and then probe once per second thereafter to keep it topped up. This could be

[PATCH net-next 5/9] rxrpc: Expedite ping response transmission

Expedite the transmission of a response to a PING ACK by sending it from sendmsg if one is pending. We're most likely to see a PING ACK during the client call Tx phase as the other side may use it to determine a number of parameters, such as the client's receive window size, the RTT and whether

[PATCH net-next 9/9] rxrpc: Reduce the number of ACK-Requests sent

Reduce the number of ACK-Requests we set on DATA packets that we're sending to reduce network traffic. We set the flag on odd-numbered DATA packets to start off the RTT cache until we have at least three entries in it and then probe once per second thereafter to keep it topped up. This could be

[PATCH net-next 1/9] rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs

Don't store the rxrpc protocol header in sk_buffs on the transmit queue, but rather generate it on the fly and pass it to kernel_sendmsg() as a separate iov. This reduces the amount of storage required. Note that the security header is still stored in the sk_buff as it may get encrypted along

[PATCH net-next 0/9] rxrpc: Preparation for slow-start algorithm

Here are some patches that prepare for improvements in ACK generation and for the implementation of the slow-start part of the protocol: (1) Stop storing the protocol header in the Tx socket buffers, but rather generate it on the fly. This potentially saves a little space and makes

[PATCH net-next 1/9] rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs

Don't store the rxrpc protocol header in sk_buffs on the transmit queue, but rather generate it on the fly and pass it to kernel_sendmsg() as a separate iov. This reduces the amount of storage required. Note that the security header is still stored in the sk_buff as it may get encrypted along

[PATCH net-next 0/9] rxrpc: Preparation for slow-start algorithm

Here are some patches that prepare for improvements in ACK generation and for the implementation of the slow-start part of the protocol: (1) Stop storing the protocol header in the Tx socket buffers, but rather generate it on the fly. This potentially saves a little space and makes

[PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker

Add a function to track the average RTT for a peer. Sources of RTT data will be added in subsequent patches. The RTT data will be useful in the future for determining resend timeouts and for handling the slow-start part of the Rx protocol. Also add a pair of tracepoints, one to log

[PATCH net-next 3/9] rxrpc: Add per-peer RTT tracker

Add a function to track the average RTT for a peer. Sources of RTT data will be added in subsequent patches. The RTT data will be useful in the future for determining resend timeouts and for handling the slow-start part of the Rx protocol. Also add a pair of tracepoints, one to log

[PATCH net-next 2/9] rxrpc: Add re-sent Tx annotation

Add a Tx-phase annotation for packet buffers to indicate that a buffer has already been retransmitted. This will be used by future congestion management. Re-retransmissions of a packet don't affect the congestion window managment in the same way as initial retransmissions. Signed-off-by: David

[PATCH net-next 2/9] rxrpc: Add re-sent Tx annotation

Add a Tx-phase annotation for packet buffers to indicate that a buffer has already been retransmitted. This will be used by future congestion management. Re-retransmissions of a packet don't affect the congestion window managment in the same way as initial retransmissions. Signed-off-by: David

Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On Thu, 22 Sep 2016, zijun_hu wrote: > On 2016/9/22 5:21, David Rientjes wrote: > > On Wed, 21 Sep 2016, zijun_hu wrote: > > > >> From: zijun_hu > >> > >> correct lazy_max_pages() return value if the number of online > >> CPUs is power of 2 > >> > >> Signed-off-by: zijun_hu

Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On Thu, 22 Sep 2016, zijun_hu wrote: > On 2016/9/22 5:21, David Rientjes wrote: > > On Wed, 21 Sep 2016, zijun_hu wrote: > > > >> From: zijun_hu > >> > >> correct lazy_max_pages() return value if the number of online > >> CPUs is power of 2 > >> > >> Signed-off-by: zijun_hu > >> --- > >>

Re: [BUG] perf report --pid not reporting correctly

Hi Arnaldo and Stephane, On Thu, Sep 22, 2016 at 12:37 AM, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: >> Hi Arnaldo, >> >> I ran into an issue trying to use the --pid filtering option of perf report. >> >> I do a

Re: [BUG] perf report --pid not reporting correctly

Hi Arnaldo and Stephane, On Thu, Sep 22, 2016 at 12:37 AM, Arnaldo Carvalho de Melo wrote: > Em Tue, Sep 20, 2016 at 06:29:59PM -0700, Stephane Eranian escreveu: >> Hi Arnaldo, >> >> I ran into an issue trying to use the --pid filtering option of perf report. >> >> I do a system-wide collection

Re: Locking rules for fscrypt_operations->set_context()

On Tue, Sep 20, 2016 at 04:30:06PM +0200, Richard Weinberger wrote: > Hi! > > To my understanding ->setxattr() is always being called with i_mutex held. > ->set_context() in ext4 stores the security context using ext4_xattr_set(), > but the fs crypto framework does not lock the inode itself. >

Re: Locking rules for fscrypt_operations->set_context()

On Tue, Sep 20, 2016 at 04:30:06PM +0200, Richard Weinberger wrote: > Hi! > > To my understanding ->setxattr() is always being called with i_mutex held. > ->set_context() in ext4 stores the security context using ext4_xattr_set(), > but the fs crypto framework does not lock the inode itself. >

Re: [PATCH v4 0/3] nvme power saving

On Fri, Sep 16, 2016 at 11:16 AM, Andy Lutomirski wrote: > Hi all- > > Here's v4 of the APST patch set. The biggest bikesheddable thing (I > think) is the scaling factor. I currently have it hardcoded so that > we wait 50x the total latency before entering a power saving state.

Re: [PATCH v4 0/3] nvme power saving

On Fri, Sep 16, 2016 at 11:16 AM, Andy Lutomirski wrote: > Hi all- > > Here's v4 of the APST patch set. The biggest bikesheddable thing (I > think) is the scaling factor. I currently have it hardcoded so that > we wait 50x the total latency before entering a power saving state. > On my Samsung

[PATCH] [media] tw5864: crop picture width to 704

Previously, width of 720 was used, but it gives 16-pixel wide black bar at right side of encoded picture. Signed-off-by: Andrey Utkin --- drivers/media/pci/tw5864/tw5864-reg.h | 8 drivers/media/pci/tw5864/tw5864-video.c | 13 +++-- 2 files

[PATCH] [media] tw5864: crop picture width to 704

Previously, width of 720 was used, but it gives 16-pixel wide black bar at right side of encoded picture. Signed-off-by: Andrey Utkin --- drivers/media/pci/tw5864/tw5864-reg.h | 8 drivers/media/pci/tw5864/tw5864-video.c | 13 +++-- 2 files changed, 19 insertions(+), 2

[PATCH] [media] solo6x10: avoid delayed register write

This fixes a lockup at device probing which happens on some solo6010 hardware samples. This is a regression introduced by commit e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers") The observed lockup happens in solo_set_motion_threshold() called from

[PATCH] [media] solo6x10: avoid delayed register write

This fixes a lockup at device probing which happens on some solo6010 hardware samples. This is a regression introduced by commit e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers") The observed lockup happens in solo_set_motion_threshold() called from

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

On 2016/9/22 7:15, David Rientjes wrote: > On Thu, 22 Sep 2016, zijun_hu wrote: > >>> We don't support inserting when va->va_start == tmp_va->va_end, plain and >>> simple. There's no reason to do so. NACK to the patch. >>> >> i am sorry i disagree with you because >> 1) in almost all context

Re: [PATCH 1/5] mm/vmalloc.c: correct a few logic error for __insert_vmap_area()

On 2016/9/22 7:15, David Rientjes wrote: > On Thu, 22 Sep 2016, zijun_hu wrote: > >>> We don't support inserting when va->va_start == tmp_va->va_end, plain and >>> simple. There's no reason to do so. NACK to the patch. >>> >> i am sorry i disagree with you because >> 1) in almost all context

Re: [PATCHv2] arm64: Correctly bounds check virt_addr_valid

On Wed, Sep 21, 2016 at 3:25 PM, Laura Abbott wrote: > > virt_addr_valid is supposed to return true if and only if virt_to_page > returns a valid page structure. The current macro does math on whatever > address is given and passes that to pfn_valid to verify. vmalloc and >

Re: [PATCHv2] arm64: Correctly bounds check virt_addr_valid

On Wed, Sep 21, 2016 at 3:25 PM, Laura Abbott wrote: > > virt_addr_valid is supposed to return true if and only if virt_to_page > returns a valid page structure. The current macro does math on whatever > address is given and passes that to pfn_valid to verify. vmalloc and > module addresses can

[PATCH v4] KVM: VMX: Enable MSR-BASED TPR shadow even if APICv is inactive

From: Wanpeng Li I observed that kvmvapic(to optimize flexpriority=N or AMD) is used to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case on my haswell desktop (w/ flexpriority, w/o APICv). Commit (8d14695f9542 x86, apicv: add virtual x2apic support)

[PATCH v4] KVM: VMX: Enable MSR-BASED TPR shadow even if APICv is inactive

From: Wanpeng Li I observed that kvmvapic(to optimize flexpriority=N or AMD) is used to boost TPR access when testing kvm-unit-test/eventinj.flat tpr case on my haswell desktop (w/ flexpriority, w/o APICv). Commit (8d14695f9542 x86, apicv: add virtual x2apic support) disable virtual x2apic

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On 09/21/2016 02:59 AM, Mike Galbraith wrote: On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote: This patch introduces a new futex implementation called throughput-optimized (TO) futexes. nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as shorthand for timeout in the

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On 09/21/2016 02:59 AM, Mike Galbraith wrote: On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote: This patch introduces a new futex implementation called throughput-optimized (TO) futexes. nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as shorthand for timeout in the

[PATCH v2] pinctrl: intel: Configure GPIO chip IRQ as wakeup interrupts

On some Intel BXT platform, wake-up from suspend-to-idle on pressing power-button is not working. Its noticed that gpio-keys driver marking the second level IRQ/power-button as wake capable but Intel pintctrl driver is missing to mark GPIO chip/controller IRQ which first level IRQ as wake cable if

[PATCH v2] pinctrl: intel: Configure GPIO chip IRQ as wakeup interrupts

On some Intel BXT platform, wake-up from suspend-to-idle on pressing power-button is not working. Its noticed that gpio-keys driver marking the second level IRQ/power-button as wake capable but Intel pintctrl driver is missing to mark GPIO chip/controller IRQ which first level IRQ as wake cable if

Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On 2016/9/22 5:21, David Rientjes wrote: > On Wed, 21 Sep 2016, zijun_hu wrote: > >> From: zijun_hu >> >> correct lazy_max_pages() return value if the number of online >> CPUs is power of 2 >> >> Signed-off-by: zijun_hu >> --- >> mm/vmalloc.c | 4 +++- >> 1

Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On 2016/9/22 5:21, David Rientjes wrote: > On Wed, 21 Sep 2016, zijun_hu wrote: > >> From: zijun_hu >> >> correct lazy_max_pages() return value if the number of online >> CPUs is power of 2 >> >> Signed-off-by: zijun_hu >> --- >> mm/vmalloc.c | 4 +++- >> 1 file changed, 3 insertions(+), 1

Re: [PATCH v2] rtc-cmos: Reject unsupported alarm values

On 02/09/2016 at 21:55:16 +0200, Gabriele Mazzotta wrote : > Some platforms allows to specify the month and day of the month in > which an alarm should go off, some others the day of the month and > some others just the time. > > Currently any given value is accepted by the driver and only the >

Re: [PATCH v2] rtc-cmos: Reject unsupported alarm values

On 02/09/2016 at 21:55:16 +0200, Gabriele Mazzotta wrote : > Some platforms allows to specify the month and day of the month in > which an alarm should go off, some others the day of the month and > some others just the time. > > Currently any given value is accepted by the driver and only the >

Re: [PATCH 2/5] mm/vmalloc.c: simplify /proc/vmallocinfo implementation

On 2016/9/22 5:16, David Rientjes wrote: > On Wed, 21 Sep 2016, zijun_hu wrote: > >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index cc6ecd6..a125ae8 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -2576,32 +2576,13 @@ void pcpu_free_vm_areas(struct vm_struct **vms, int >> nr_vms) >>

Re: [PATCH 2/5] mm/vmalloc.c: simplify /proc/vmallocinfo implementation

On 2016/9/22 5:16, David Rientjes wrote: > On Wed, 21 Sep 2016, zijun_hu wrote: > >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index cc6ecd6..a125ae8 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -2576,32 +2576,13 @@ void pcpu_free_vm_areas(struct vm_struct **vms, int >> nr_vms) >>

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