Re: RTL8723BE performance regression

On Wed, 2018-05-02 at 05:44 +, Pkshih wrote: > > > -Original Message- > > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com] > > Sent: Wednesday, May 02, 2018 6:41 AM > > To: Larry Finger > > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; > > Chaoming_Li;

Re: RTL8723BE performance regression

On Wed, 2018-05-02 at 05:44 +, Pkshih wrote: > > > -Original Message- > > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com] > > Sent: Wednesday, May 02, 2018 6:41 AM > > To: Larry Finger > > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; > > Chaoming_Li;

[RFC PATCH] Add /proc//numa_vamaps for numa node information

For analysis purpose it is useful to have numa node information corresponding mapped address ranges of the process. Currently /proc//numa_maps provides list of numa nodes from where pages are allocated per VMA of the process. This is not useful if an user needs to determine which numa node the

[RFC PATCH] Add /proc//numa_vamaps for numa node information

For analysis purpose it is useful to have numa node information corresponding mapped address ranges of the process. Currently /proc//numa_maps provides list of numa nodes from where pages are allocated per VMA of the process. This is not useful if an user needs to determine which numa node the

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

Hi Song, On Wed, 2 May 2018 04:40:20 + Song Liu wrote: > > > - CHECK(build_id_matches < 1, "build id match", > > - "Didn't find expected build ID from the map\n"); > > + if (CHECK(build_id_matches < 1, "build id match", > > - "Didn't find

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

Hi Song, On Wed, 2 May 2018 04:40:20 + Song Liu wrote: > > > - CHECK(build_id_matches < 1, "build id match", > > - "Didn't find expected build ID from the map\n"); > > + if (CHECK(build_id_matches < 1, "build id match", > > - "Didn't find expected build ID from the

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 2 May 2018 at 13:23, Wolfram Sang wrote: > >> > We should maybe handle this in the core somewhen, though. Or? >> >> Thanks. Yes, It will more helpful if we can handle this in the i2c core. > > To understand the issue better: which kind of devices in your system > still send

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

On 2 May 2018 at 13:23, Wolfram Sang wrote: > >> > We should maybe handle this in the core somewhen, though. Or? >> >> Thanks. Yes, It will more helpful if we can handle this in the i2c core. > > To understand the issue better: which kind of devices in your system > still send I2C transfers when

Re: [PATCH] staging: wilc1000: fix infinite loop and out-of-bounds access

On Mon, 30 Apr 2018 18:23:21 +0300 Dan Carpenter wrote: > On Mon, Apr 30, 2018 at 07:59:16PM +0530, Ajay Singh wrote: > > Reviewed-by: Ajay Singh > > > > On Mon, 30 Apr 2018 07:50:40 -0500 > > "Gustavo A. R. Silva"

Re: [PATCH] staging: wilc1000: fix infinite loop and out-of-bounds access

On Mon, 30 Apr 2018 18:23:21 +0300 Dan Carpenter wrote: > On Mon, Apr 30, 2018 at 07:59:16PM +0530, Ajay Singh wrote: > > Reviewed-by: Ajay Singh > > > > On Mon, 30 Apr 2018 07:50:40 -0500 > > "Gustavo A. R. Silva" wrote: > > > > > If i < slot_id is initially true then it will remain true.

RE: RTL8723BE performance regression

> -Original Message- > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com] > Sent: Wednesday, May 02, 2018 6:41 AM > To: Larry Finger > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; > Chaoming_Li; Kalle Valo; > linux-wireless; Network Development; LKML; Daniel

RE: RTL8723BE performance regression

> -Original Message- > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com] > Sent: Wednesday, May 02, 2018 6:41 AM > To: Larry Finger > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; > Chaoming_Li; Kalle Valo; > linux-wireless; Network Development; LKML; Daniel

Re: [PATCH] hwtracing: intel_th: Change return type to vm_fault_t

Any comment for this patch ? On Tue, Apr 17, 2018 at 7:45 PM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are

Re: [PATCH] hwtracing: intel_th: Change return type to vm_fault_t

Any comment for this patch ? On Tue, Apr 17, 2018 at 7:45 PM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will

Re: [greybus-dev] [PATCH v2] staging: greybus: Use gpio_is_valid()

On 28-04-18, 10:05, Arvind Yadav wrote: > Replace the manual validity checks for the GPIO with the > gpio_is_valid(). > > Signed-off-by: Arvind Yadav > --- > chnage in v2 : > Returning invalid gpio as error instead of -ENODEV. > >

Re: [greybus-dev] [PATCH v2] staging: greybus: Use gpio_is_valid()

On 28-04-18, 10:05, Arvind Yadav wrote: > Replace the manual validity checks for the GPIO with the > gpio_is_valid(). > > Signed-off-by: Arvind Yadav > --- > chnage in v2 : > Returning invalid gpio as error instead of -ENODEV. > > drivers/staging/greybus/arche-platform.c | 6

Re: [PATCH 3/6] PCI: Introduce devm_of_pci_get_host_bridge_resources

On 2018-04-30 20:43, Sinan Kaya wrote: > On 4/30/2018 2:40 PM, Bjorn Helgaas wrote: >> On Sat, Apr 28, 2018 at 09:28:47AM +0200, Jan Kiszka wrote: >>> On 2018-04-28 00:24, Bjorn Helgaas wrote: On Tue, Apr 24, 2018 at 05:13:39PM +0200, Jan Kiszka wrote: > From: Jan Kiszka

Re: [PATCH 3/6] PCI: Introduce devm_of_pci_get_host_bridge_resources

On 2018-04-30 20:43, Sinan Kaya wrote: > On 4/30/2018 2:40 PM, Bjorn Helgaas wrote: >> On Sat, Apr 28, 2018 at 09:28:47AM +0200, Jan Kiszka wrote: >>> On 2018-04-28 00:24, Bjorn Helgaas wrote: On Tue, Apr 24, 2018 at 05:13:39PM +0200, Jan Kiszka wrote: > From: Jan Kiszka > >

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 9:14 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 9:00 PM Dan Williams > wrote: >> > >> > I have some dim memory of "rep movs doesn't work well for pmem", but > does >> > it *seriously* need unrolling to

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 9:14 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 9:00 PM Dan Williams > wrote: >> > >> > I have some dim memory of "rep movs doesn't work well for pmem", but > does >> > it *seriously* need unrolling to cacheline boundaries? And if it does, > who >> > designed it,

Re: [PATCH] cpufreq: s3c2440: fix spelling mistake: "divsiors" -> "divisors"

On 30-04-18, 15:48, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in s3c_freq_dbg debug message text. > > Signed-off-by: Colin Ian King > --- > drivers/cpufreq/s3c2440-cpufreq.c | 2 +- > 1 file changed, 1

Re: [PATCH] cpufreq: s3c2440: fix spelling mistake: "divsiors" -> "divisors"

On 30-04-18, 15:48, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in s3c_freq_dbg debug message text. > > Signed-off-by: Colin Ian King > --- > drivers/cpufreq/s3c2440-cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH] coresight: Remove %px for printing pcsr value

On Tue, May 1, 2018 at 10:00 PM, Leo Yan wrote: > The driver prints pcsr twice: the first time it uses specifier %px to > print hexadecimal pcsr value and the second time uses specifier %pS for > output kernel symbols. > > As suggested by Kees, using %pS should be sufficient

Re: [PATCH] coresight: Remove %px for printing pcsr value

On Tue, May 1, 2018 at 10:00 PM, Leo Yan wrote: > The driver prints pcsr twice: the first time it uses specifier %px to > print hexadecimal pcsr value and the second time uses specifier %pS for > output kernel symbols. > > As suggested by Kees, using %pS should be sufficient and %px isn't >

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

> > We should maybe handle this in the core somewhen, though. Or? > > Thanks. Yes, It will more helpful if we can handle this in the i2c core. To understand the issue better: which kind of devices in your system still send I2C transfers when the system is going to suspend? Do you know?

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

> > We should maybe handle this in the core somewhen, though. Or? > > Thanks. Yes, It will more helpful if we can handle this in the i2c core. To understand the issue better: which kind of devices in your system still send I2C transfers when the system is going to suspend? Do you know?

[PATCH] staging: lustre: o2iblnd: fix race at kiblnd_connect_peer

From: Doug Oucahrek cmid will be destroyed at OFED if kiblnd_cm_callback return error. if error happen before the end of kiblnd_connect_peer, it will touch destroyed cmid and fail as (o2iblnd_cb.c:1315:kiblnd_connect_peer()) ASSERTION( cmid->device != ((void *)0) )

[PATCH] staging: lustre: o2iblnd: fix race at kiblnd_connect_peer

From: Doug Oucahrek cmid will be destroyed at OFED if kiblnd_cm_callback return error. if error happen before the end of kiblnd_connect_peer, it will touch destroyed cmid and fail as (o2iblnd_cb.c:1315:kiblnd_connect_peer()) ASSERTION( cmid->device != ((void *)0) ) failed:

Re: [Xen-devel] [PATCH 2/6] xen-netfront: copy response out of shared buffer before accessing it

On 05/01/2018 12:01 AM, Marek Marczykowski-Górecki wrote: Make local copy of the response, otherwise backend might modify it while frontend is already processing it - leading to time of check / time of use issue. This is complementary to XSA155. Cc: sta...@vger.kernel.org Signed-off-by: Marek

Re: [Xen-devel] [PATCH 2/6] xen-netfront: copy response out of shared buffer before accessing it

On 05/01/2018 12:01 AM, Marek Marczykowski-Górecki wrote: Make local copy of the response, otherwise backend might modify it while frontend is already processing it - leading to time of check / time of use issue. This is complementary to XSA155. Cc: sta...@vger.kernel.org Signed-off-by: Marek

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

On 5/1/2018 6:49 PM, Peter Zijlstra wrote: On 5/1/2018 5:01 PM, Peter Zijlstra wrote: Let me ponder what the best solution is, it's a bit of a mess. So there's: - TASK_PARKED, which we can make a special state; this solves the problem because then wait_task_inactive() is guaranteed

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

On 5/1/2018 6:49 PM, Peter Zijlstra wrote: On 5/1/2018 5:01 PM, Peter Zijlstra wrote: Let me ponder what the best solution is, it's a bit of a mess. So there's: - TASK_PARKED, which we can make a special state; this solves the problem because then wait_task_inactive() is guaranteed

Re: [v2 PATCH 1/1] tg3: fix meaningless hw_stats reading after tg3_halt memset 0 hw_stats

On Tue, May 1, 2018 at 5:42 PM, Zumeng Chen wrote: > diff --git a/drivers/net/ethernet/broadcom/tg3.h > b/drivers/net/ethernet/broadcom/tg3.h > index 3b5e98e..c61d83c 100644 > --- a/drivers/net/ethernet/broadcom/tg3.h > +++ b/drivers/net/ethernet/broadcom/tg3.h > @@

Re: [v2 PATCH 1/1] tg3: fix meaningless hw_stats reading after tg3_halt memset 0 hw_stats

On Tue, May 1, 2018 at 5:42 PM, Zumeng Chen wrote: > diff --git a/drivers/net/ethernet/broadcom/tg3.h > b/drivers/net/ethernet/broadcom/tg3.h > index 3b5e98e..c61d83c 100644 > --- a/drivers/net/ethernet/broadcom/tg3.h > +++ b/drivers/net/ethernet/broadcom/tg3.h > @@ -3102,6 +3102,7 @@ enum

Re: [PATCH v9 24/27] dt-bindings: timer: new bindings for TI DaVinci timer

On Wednesday 02 May 2018 07:22 AM, David Lechner wrote: > Sekhar, > > On 04/27/2018 09:05 AM, Rob Herring wrote: >> On Thu, Apr 26, 2018 at 07:17:42PM -0500, David Lechner wrote: >>> This adds new device tree bindings for the timer IP block of TI >>> DaVinci-like SoCs. >>> >>> Signed-off-by:

Re: [PATCH v9 24/27] dt-bindings: timer: new bindings for TI DaVinci timer

On Wednesday 02 May 2018 07:22 AM, David Lechner wrote: > Sekhar, > > On 04/27/2018 09:05 AM, Rob Herring wrote: >> On Thu, Apr 26, 2018 at 07:17:42PM -0500, David Lechner wrote: >>> This adds new device tree bindings for the timer IP block of TI >>> DaVinci-like SoCs. >>> >>> Signed-off-by:

Re: [PATCH v2 2/2] usb: dwc2: fix isoc split in transfer with no data

Hi, On Tue, May 1, 2018 at 8:04 PM, William Wu wrote: > If isoc split in transfer with no data (the length of DATA0 > packet is zero), we can't simply return immediately. Because > the DATA0 can be the first transaction or the second transaction > for the isoc split in

Re: [PATCH v2 2/2] usb: dwc2: fix isoc split in transfer with no data

Hi, On Tue, May 1, 2018 at 8:04 PM, William Wu wrote: > If isoc split in transfer with no data (the length of DATA0 > packet is zero), we can't simply return immediately. Because > the DATA0 can be the first transaction or the second transaction > for the isoc split in transaction. If the DATA0

[PATCH] coresight: Remove %px for printing pcsr value

The driver prints pcsr twice: the first time it uses specifier %px to print hexadecimal pcsr value and the second time uses specifier %pS for output kernel symbols. As suggested by Kees, using %pS should be sufficient and %px isn't necessary; the reason is if the pcsr is a kernel space address,

[PATCH] coresight: Remove %px for printing pcsr value

The driver prints pcsr twice: the first time it uses specifier %px to print hexadecimal pcsr value and the second time uses specifier %pS for output kernel symbols. As suggested by Kees, using %pS should be sufficient and %px isn't necessary; the reason is if the pcsr is a kernel space address,

[PATCH] staging: lustre: o2iblnd: Fix FastReg map/unmap for MLX5

The FastReg support in ko2iblnd was not unmapping pool items causing the items to leak. In addition, the mapping code is not growing the pool like we do with FMR. This patch makes sure we are unmapping FastReg pool elements when we are done with them. It also makes sure the pool will grow when

[PATCH] staging: lustre: o2iblnd: Fix FastReg map/unmap for MLX5

The FastReg support in ko2iblnd was not unmapping pool items causing the items to leak. In addition, the mapping code is not growing the pool like we do with FMR. This patch makes sure we are unmapping FastReg pool elements when we are done with them. It also makes sure the pool will grow when

Re: [PATCH 9/9] iommu/vt-d: Clean up PASID talbe management for SVM

Hi, On 05/01/2018 05:24 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> The previous per iommu pasid table alloc/free interfaces >> are no longer used. Clean up the driver by removing it. > I think this patch major cleans

Re: [PATCH 9/9] iommu/vt-d: Clean up PASID talbe management for SVM

Hi, On 05/01/2018 05:24 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> The previous per iommu pasid table alloc/free interfaces >> are no longer used. Clean up the driver by removing it. > I think this patch major cleans

Re: [PATCH] memcg, hugetlb: pages allocated for hugetlb's overcommit will be charged to memcg

On 05/01/2018 06:19 PM, TSUKADA Koutaro wrote: > If nr_overcommit_hugepages is assumed to be infinite, allocating pages for > hugetlb's overcommit from buddy pool is all unlimited even if being limited > by memcg. The purpose of this patch is that if we allocate the hugetlb page > from the boddy

Re: [PATCH] memcg, hugetlb: pages allocated for hugetlb's overcommit will be charged to memcg

On 05/01/2018 06:19 PM, TSUKADA Koutaro wrote: > If nr_overcommit_hugepages is assumed to be infinite, allocating pages for > hugetlb's overcommit from buddy pool is all unlimited even if being limited > by memcg. The purpose of this patch is that if we allocate the hugetlb page > from the boddy

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

> On May 1, 2018, at 7:09 PM, Stephen Rothwell wrote: > > Hi all, > > Today's linux-next merge of the bpf-next tree got a conflict in: > > tools/testing/selftests/bpf/test_progs.c > > between commit: > > a4e21ff8d9a3 ("bpf: minor fix to selftest

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

> On May 1, 2018, at 7:09 PM, Stephen Rothwell wrote: > > Hi all, > > Today's linux-next merge of the bpf-next tree got a conflict in: > > tools/testing/selftests/bpf/test_progs.c > > between commit: > > a4e21ff8d9a3 ("bpf: minor fix to selftest test_stacktrace_build_id()") > > from the

Re: [PATCH 8/9] iommu/vt-d: Use per-domain pasid table

Hi, On 05/01/2018 05:23 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> This patch replaces current per iommu pasid table with >> the new added per domain pasid table. Each svm-capable >> PCI device will have its own pasid

Re: [PATCH 8/9] iommu/vt-d: Use per-domain pasid table

Hi, On 05/01/2018 05:23 PM, Liu, Yi L wrote: >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Tuesday, April 17, 2018 11:03 AM >> >> This patch replaces current per iommu pasid table with >> the new added per domain pasid table. Each svm-capable >> PCI device will have its own pasid

Re: [PATCH v2 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

Hi, On Tue, May 1, 2018 at 8:04 PM, William Wu wrote: > The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in > a more supported way") rips out a lot of code to simply the > allocation of aligned DMA. However, it also introduces a new > issue when use isoc

Re: [PATCH v2 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

Hi, On Tue, May 1, 2018 at 8:04 PM, William Wu wrote: > The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in > a more supported way") rips out a lot of code to simply the > allocation of aligned DMA. However, it also introduces a new > issue when use isoc split in transfer. > > In my

Re: [PATCH v3] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

On Sat, Apr 28, 2018 at 12:57:54PM -0700, Moritz Fischer wrote: > Request IRQ with IRQF_SHARED flag to enable setups with multiple > instances of the core sharing a single IRQ line. > This works out since the IRQ handler already checks if there is > an actual IRQ pending and returns IRQ_NONE

Re: [PATCH v3] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

On Sat, Apr 28, 2018 at 12:57:54PM -0700, Moritz Fischer wrote: > Request IRQ with IRQF_SHARED flag to enable setups with multiple > instances of the core sharing a single IRQ line. > This works out since the IRQ handler already checks if there is > an actual IRQ pending and returns IRQ_NONE

Re: bug-introducing patches

On Tue, May 01, 2018 at 10:02:30PM +, Sasha Levin wrote: > On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: > >Post -rc3 or -rc4, in my opinion bug fixes should wait until the next > >merge window before they get merged at all. (And certainly features > >bugs should be Right

Re: bug-introducing patches

On Tue, May 01, 2018 at 10:02:30PM +, Sasha Levin wrote: > On Tue, May 01, 2018 at 04:54:48PM -0400, Theodore Y. Ts'o wrote: > >Post -rc3 or -rc4, in my opinion bug fixes should wait until the next > >merge window before they get merged at all. (And certainly features > >bugs should be Right

Re: [PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Sat, Apr 28, 2018 at 05:50:58PM -0400, Frank Mori Hess wrote: > This reverts commit 88987d2c7534a0269f567fb101e6d71a08f0f01d. > > The pl330.c pause implementation violates the dmaengine requirement > for no data loss, since it relies on the DMAKILL > instruction. However, DMAKILL discards

Re: [PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

On Sat, Apr 28, 2018 at 05:50:58PM -0400, Frank Mori Hess wrote: > This reverts commit 88987d2c7534a0269f567fb101e6d71a08f0f01d. > > The pl330.c pause implementation violates the dmaengine requirement > for no data loss, since it relies on the DMAKILL > instruction. However, DMAKILL discards

Re: [PATCH][V2] dmaengine: stm32-mdma: fix spelling mistake: "avalaible" -> "available"

On Sat, Apr 28, 2018 at 11:03:52PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err error message text and make > channel plural. Applied, thanks -- ~Vinod

Re: [PATCH][V2] dmaengine: stm32-mdma: fix spelling mistake: "avalaible" -> "available"

On Sat, Apr 28, 2018 at 11:03:52PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err error message text and make > channel plural. Applied, thanks -- ~Vinod

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 9:00 PM Dan Williams wrote: > > > > I have some dim memory of "rep movs doesn't work well for pmem", but does > > it *seriously* need unrolling to cacheline boundaries? And if it does, who > > designed it, and why is anybody using it? > > > I

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 9:00 PM Dan Williams wrote: > > > > I have some dim memory of "rep movs doesn't work well for pmem", but does > > it *seriously* need unrolling to cacheline boundaries? And if it does, who > > designed it, and why is anybody using it? > > > I think this is an FAQ from the

[PATCH] staging: lustre: o2iblnd: Enable Multiple OPA Endpoints between Nodes

OPA driver optimizations are based on the MPI model where it is expected to have multiple endpoints between two given nodes. To enable this optimization for Lustre, we need to make it possible, via an LND-specific tuneable, to create multiple endpoints and to balance the traffic over them. Both

[PATCH] staging: lustre: o2iblnd: Enable Multiple OPA Endpoints between Nodes

OPA driver optimizations are based on the MPI model where it is expected to have multiple endpoints between two given nodes. To enable this optimization for Lustre, we need to make it possible, via an LND-specific tuneable, to create multiple endpoints and to balance the traffic over them. Both

[PATCH v3] soc: mediatek: add a fixed wait for SRAM stable

From: Sean Wang MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes stable, which is not like the behavior the other power domains should have. Therefore, it's necessary for such a power domain to have a fixed and well-predefined duration to wait

[PATCH v3] soc: mediatek: add a fixed wait for SRAM stable

From: Sean Wang MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes stable, which is not like the behavior the other power domains should have. Therefore, it's necessary for such a power domain to have a fixed and well-predefined duration to wait until its managed SRAM can

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:33 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:22 PM Dan Williams > wrote: > >> All that to say that having a typical RAM page covering poisoned pmem >> would complicate the 'clear badblocks'

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:33 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:22 PM Dan Williams > wrote: > >> All that to say that having a typical RAM page covering poisoned pmem >> would complicate the 'clear badblocks' implementation. > > Ugh, ok. > > I guess the good news is that your

Re: [PATCH v2 21/27] coresight: Convert driver messages to dev_dbg

On Tue, 1 May 2018 10:10:51 +0100 Suzuki K Poulose wrote: > Convert component enable/disable messages from dev_info to dev_dbg. > This is required to prevent LOCKDEP splats when operating in perf > mode where we could be called with locks held to enable a coresight Can

Re: [PATCH v2 21/27] coresight: Convert driver messages to dev_dbg

On Tue, 1 May 2018 10:10:51 +0100 Suzuki K Poulose wrote: > Convert component enable/disable messages from dev_info to dev_dbg. > This is required to prevent LOCKDEP splats when operating in perf > mode where we could be called with locks held to enable a coresight Can we see the splats?

Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

Hi Mathieu: this work looks very cool. See inline. On Mon, Apr 30, 2018 at 3:48 PM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > Hi, > Here is an updated RFC round of the Restartable Sequences patchset > based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing >

Re: [RFC PATCH for 4.18 00/14] Restartable Sequences

Hi Mathieu: this work looks very cool. See inline. On Mon, Apr 30, 2018 at 3:48 PM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > Hi, > Here is an updated RFC round of the Restartable Sequences patchset > based on kernel 4.17-rc3. Based on feedback from Linus, I'm introducing >

Re: [PATCH 2/2] arm64: dts: mt7622: add audio related device nodes

Hi, Matthias On Wed, 2018-05-02 at 11:41 +0800, sean.w...@mediatek.com wrote: > From: Ryder Lee > > Add audio device nodes and its proper setup for all used pins > > Signed-off-by: Ryder Lee > Signed-off-by: Sean Wang >

Re: [PATCH 2/2] arm64: dts: mt7622: add audio related device nodes

Hi, Matthias On Wed, 2018-05-02 at 11:41 +0800, sean.w...@mediatek.com wrote: > From: Ryder Lee > > Add audio device nodes and its proper setup for all used pins > > Signed-off-by: Ryder Lee > Signed-off-by: Sean Wang > --- > arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 11 +++- >

Re: [RFC v3 0/5] virtio: support packed ring

On 2018年04月25日 13:15, Tiwei Bie wrote: Hello everyone, This RFC implements packed ring support in virtio driver. Some simple functional tests have been done with Jason's packed ring implementation in vhost: https://lkml.org/lkml/2018/4/23/12 Both of ping and netperf worked as expected

Re: [RFC v3 0/5] virtio: support packed ring

On 2018年04月25日 13:15, Tiwei Bie wrote: Hello everyone, This RFC implements packed ring support in virtio driver. Some simple functional tests have been done with Jason's packed ring implementation in vhost: https://lkml.org/lkml/2018/4/23/12 Both of ping and netperf worked as expected

[PATCH 2/2] arm64: dts: mt7622: add audio related device nodes

From: Ryder Lee Add audio device nodes and its proper setup for all used pins Signed-off-by: Ryder Lee Signed-off-by: Sean Wang --- arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 11 +++-

[PATCH 2/2] arm64: dts: mt7622: add audio related device nodes

From: Ryder Lee Add audio device nodes and its proper setup for all used pins Signed-off-by: Ryder Lee Signed-off-by: Sean Wang --- arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 11 +++- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 89 2 files changed, 98

[PATCH 1/2] arm64: dts: mt7622: add High-Speed DMA device nodes

From: Sean Wang add High-Speed DMA (HSDMA) nodes Signed-off-by: Sean Wang --- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi

[PATCH 1/2] arm64: dts: mt7622: add High-Speed DMA device nodes

From: Sean Wang add High-Speed DMA (HSDMA) nodes Signed-off-by: Sean Wang --- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi index e9d5130..6bbabb6

Re: [PATCH] scsi: megaraid_sas: fix spelling mistake: "disbale" -> "disable"

Colin, > Trivial fix to spelling mistake in module parameter description text Mangled patch. Applied by hand. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: mpt3sas: fix spelling mistake: "disbale" -> "disable"

Colin, > Trivial fix to spelling mistake in module parameter description text Ditto. Also hand-applied to 4.18/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: mpt3sas: fix spelling mistake: "disbale" -> "disable"

Colin, > Trivial fix to spelling mistake in module parameter description text Ditto. Also hand-applied to 4.18/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: megaraid_sas: fix spelling mistake: "disbale" -> "disable"

Colin, > Trivial fix to spelling mistake in module parameter description text Mangled patch. Applied by hand. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:22 PM Dan Williams wrote: > All that to say that having a typical RAM page covering poisoned pmem > would complicate the 'clear badblocks' implementation. Ugh, ok. I guess the good news is that your patches aren't so big, and don't really

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:22 PM Dan Williams wrote: > All that to say that having a typical RAM page covering poisoned pmem > would complicate the 'clear badblocks' implementation. Ugh, ok. I guess the good news is that your patches aren't so big, and don't really affect anything else. But can

Re: [PATCH] scsi: esas2r: fix spelling mistake: "asynchromous" -> "asynchronous"

Colin, > Trivial fix to spelling mistake in module description text Applied to 4.18/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: esas2r: fix spelling mistake: "asynchromous" -> "asynchronous"

Colin, > Trivial fix to spelling mistake in module description text Applied to 4.18/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: isci: remove redundant check on in_connection_align_insertion_frequency

Colin, > The sanity check on u->in_connection_align_insertion_frequency is > being performed twice and hence the first check can be removed since > it is redundant. Cleans up cppcheck warning: > > drivers/scsi/ibmvscsi/ibmvscsi.c:1711: (warning) Identical inner 'if' > condition is always true.

Re: [PATCH] scsi: isci: remove redundant check on in_connection_align_insertion_frequency

Colin, > The sanity check on u->in_connection_align_insertion_frequency is > being performed twice and hence the first check can be removed since > it is redundant. Cleans up cppcheck warning: > > drivers/scsi/ibmvscsi/ibmvscsi.c:1711: (warning) Identical inner 'if' > condition is always true.

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Hi Wolfram, On 27 April 2018 at 20:14, Wolfram Sang wrote: > On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote: >> Add one flag to indicate if the i2c controller has been in suspend state, >> which can prevent i2c accesses after i2c controller is suspended following

Re: [PATCH 1/2] i2c: sprd: Prevent i2c accesses after suspend is called

Hi Wolfram, On 27 April 2018 at 20:14, Wolfram Sang wrote: > On Mon, Apr 09, 2018 at 02:40:54PM +0800, Baolin Wang wrote: >> Add one flag to indicate if the i2c controller has been in suspend state, >> which can prevent i2c accesses after i2c controller is suspended following >> system suspend.

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:20 PM, Dan Williams wrote: > On Tue, May 1, 2018 at 8:13 PM, Linus Torvalds > wrote: >> On Tue, May 1, 2018 at 8:03 PM Dan Williams >> wrote: >> >>> Because dax. There's no page cache

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:20 PM, Dan Williams wrote: > On Tue, May 1, 2018 at 8:13 PM, Linus Torvalds > wrote: >> On Tue, May 1, 2018 at 8:03 PM Dan Williams >> wrote: >> >>> Because dax. There's no page cache indirection games we can play here >>> to poison a page and map in another page. The

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:13 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:03 PM Dan Williams > wrote: > >> Because dax. There's no page cache indirection games we can play here >> to poison a page and map in another page. The mapped

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:13 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:03 PM Dan Williams > wrote: > >> Because dax. There's no page cache indirection games we can play here >> to poison a page and map in another page. The mapped page is 1:1 >> associated with the filesystem block and

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:03 PM Dan Williams wrote: > Because dax. There's no page cache indirection games we can play here > to poison a page and map in another page. The mapped page is 1:1 > associated with the filesystem block and physical memory address. I'm not

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:03 PM Dan Williams wrote: > Because dax. There's no page cache indirection games we can play here > to poison a page and map in another page. The mapped page is 1:1 > associated with the filesystem block and physical memory address. I'm not talking page cache

[PATCH v2 2/2] usb: dwc2: fix isoc split in transfer with no data

If isoc split in transfer with no data (the length of DATA0 packet is zero), we can't simply return immediately. Because the DATA0 can be the first transaction or the second transaction for the isoc split in transaction. If the DATA0 packet with no data is in the first transaction, we can return

[PATCH v2 2/2] usb: dwc2: fix isoc split in transfer with no data

If isoc split in transfer with no data (the length of DATA0 packet is zero), we can't simply return immediately. Because the DATA0 can be the first transaction or the second transaction for the isoc split in transaction. If the DATA0 packet with no data is in the first transaction, we can return

  1   2   3   4   5   6   7   8   9   10   >