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;
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;
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
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
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
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
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
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
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"
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.
> -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
> -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
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
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
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.
>
>
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
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
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
>
>
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
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,
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
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
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
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
>
> > 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?
> > 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?
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) )
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:
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
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
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
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
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
> @@
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
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:
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:
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
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
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,
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,
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
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
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
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
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
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
> 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
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
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?
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
>
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
>
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
>
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 +++-
>
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
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
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 +++-
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
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
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
Colin,
> Trivial fix to spelling mistake in module parameter description text
Mangled patch. Applied by hand.
--
Martin K. Petersen Oracle Linux Engineering
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
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
Colin,
> Trivial fix to spelling mistake in module parameter description text
Mangled patch. Applied by hand.
--
Martin K. Petersen Oracle Linux Engineering
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
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
Colin,
> Trivial fix to spelling mistake in module description text
Applied to 4.18/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
Colin,
> Trivial fix to spelling mistake in module description text
Applied to 4.18/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
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.
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.
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
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.
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
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
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
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
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
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
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
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 - 100 of 1566 matches
Mail list logo