Applied "ASoC: Intel: boards: Add bdw-rt5677 machine driver" to the asoc tree

The patch ASoC: Intel: boards: Add bdw-rt5677 machine driver has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: Intel: boards: Add bdw-rt5677 machine driver" to the asoc tree

The patch ASoC: Intel: boards: Add bdw-rt5677 machine driver has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: rt5677: Add ACPI support" to the asoc tree

The patch ASoC: rt5677: Add ACPI support has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Applied "ASoC: rt5677: Add ACPI support" to the asoc tree

The patch ASoC: rt5677: Add ACPI support has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

[PATCH 3/3] megaraid_sas: clean function declarations in megaraid_sas_base.c up

We get 8 warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_fusion.c:281:1: warning: no previous prototype for 'megasas_free_cmds_fusion' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_fusion.c:714:1: warning: no previous prototype for 'megasas_ioc_init_fusion'

[PATCH 3/3] megaraid_sas: clean function declarations in megaraid_sas_base.c up

We get 8 warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_fusion.c:281:1: warning: no previous prototype for 'megasas_free_cmds_fusion' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_fusion.c:714:1: warning: no previous prototype for 'megasas_ioc_init_fusion'

[PATCH 2/3] megaraid_sas: clean function declarations in megaraid_sas_fusion.c up

We get 10 warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_base.c:226:21: warning: no previous prototype for 'megasas_get_cmd' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_base.c:252:1: warning: no previous declaration for 'megasas_return_cmd'

[PATCH 2/3] megaraid_sas: clean function declarations in megaraid_sas_fusion.c up

We get 10 warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_base.c:226:21: warning: no previous prototype for 'megasas_get_cmd' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_base.c:252:1: warning: no previous declaration for 'megasas_return_cmd'

[PATCH 1/3] megaraid_sas: mark symbols static where possible

We get a few warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no previous prototype for 'mega_mod64' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no previous prototype for 'mega_div64_32' [-Wmissing-prototypes]

[PATCH 1/3] megaraid_sas: mark symbols static where possible

We get a few warnings when building kernel with W=1: drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no previous prototype for 'mega_mod64' [-Wmissing-prototypes] drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no previous prototype for 'mega_div64_32' [-Wmissing-prototypes]

[PATCH] [SCSI] mvsas: mark symbols static where possible

We get a few warnings when building kernel with W=1: drivers/scsi/mvsas/mv_sas.c:77:18: warning: no previous prototype for 'mvs_find_dev_mvi' [-Wmissing-prototypes] drivers/scsi/mvsas/mv_sas.c:105:5: warning: no previous prototype for 'mvs_find_dev_phyno' [-Wmissing-prototypes]

[PATCH] [SCSI] mvsas: mark symbols static where possible

We get a few warnings when building kernel with W=1: drivers/scsi/mvsas/mv_sas.c:77:18: warning: no previous prototype for 'mvs_find_dev_mvi' [-Wmissing-prototypes] drivers/scsi/mvsas/mv_sas.c:105:5: warning: no previous prototype for 'mvs_find_dev_phyno' [-Wmissing-prototypes]

[PATCH] lpfc: mark symbols static where possible

We get a few warnings when building kernel with W=1: drivers/scsi/lpfc/lpfc_sli.c:5693:1: warning: no previous prototype for 'lpfc_set_features' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_sli.c:8972:1: warning: no previous prototype for 'lpfc_sli_calc_ring' [-Wmissing-prototypes]

[PATCH] lpfc: mark symbols static where possible

We get a few warnings when building kernel with W=1: drivers/scsi/lpfc/lpfc_sli.c:5693:1: warning: no previous prototype for 'lpfc_set_features' [-Wmissing-prototypes] drivers/scsi/lpfc/lpfc_sli.c:8972:1: warning: no previous prototype for 'lpfc_sli_calc_ring' [-Wmissing-prototypes]

Re: [PATCH][V2] mlxsw: spectrum: remove redundant check if err is zero

On Sat, Sep 24, 2016 at 06:03:38PM -0700, Colin King wrote: > From: Colin Ian King > > There is an earlier check and return if err is non-zero, so > the check to see if it is zero is redundant in every iteration > of the loop and hence the check can be removed. > >

Re: [PATCH][V2] mlxsw: spectrum: remove redundant check if err is zero

On Sat, Sep 24, 2016 at 06:03:38PM -0700, Colin King wrote: > From: Colin Ian King > > There is an earlier check and return if err is non-zero, so > the check to see if it is zero is redundant in every iteration > of the loop and hence the check can be removed. > > Signed-off-by: Colin Ian King

Re: [v6,2/2] QE: remove PPCisms for QE

On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote: > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote: > > QE was supported on PowerPC, and dependent on PPC, > > Now it is supported on other platforms. so remove PPCisms. > > > > Signed-off-by: Zhao Qiang >

Re: [v6,2/2] QE: remove PPCisms for QE

On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote: > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote: > > QE was supported on PowerPC, and dependent on PPC, > > Now it is supported on other platforms. so remove PPCisms. > > > > Signed-off-by: Zhao Qiang > > --- > > Changes

Re: [v6,2/2] QE: remove PPCisms for QE

On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote: > QE was supported on PowerPC, and dependent on PPC, > Now it is supported on other platforms. so remove PPCisms. > > Signed-off-by: Zhao Qiang > --- > Changes for v2: > - na > Changes for v3: > - add

Re: [v6,2/2] QE: remove PPCisms for QE

On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote: > QE was supported on PowerPC, and dependent on PPC, > Now it is supported on other platforms. so remove PPCisms. > > Signed-off-by: Zhao Qiang > --- > Changes for v2: > - na > Changes for v3: > - add NO_IRQ > Changes for

[PATCH][v11] PM / hibernate: Verify the consistent of e820 memory map by md5 digest

On some platforms, there is occasional panic triggered when trying to resume from hibernation, a typical panic looks like: "BUG: unable to handle kernel paging request at 880085894000 IP: [] load_image_lzo+0x8c2/0xe70" Investigation carried out by Lee Chun-Yi shows that this is because e820

[PATCH][v11] PM / hibernate: Verify the consistent of e820 memory map by md5 digest

On some platforms, there is occasional panic triggered when trying to resume from hibernation, a typical panic looks like: "BUG: unable to handle kernel paging request at 880085894000 IP: [] load_image_lzo+0x8c2/0xe70" Investigation carried out by Lee Chun-Yi shows that this is because e820

Re: RK3288 USB Issues

On 09/25/2016 04:10 AM, Norbert Lange wrote: Hello, did you try without your patches, to see if you can reproduce the problem? I can fix my issues if I disable usb autosuspend To narrow down the causes I can think of: *) Some hardware issue only on my side -> please try to reproduce it with

Re: RK3288 USB Issues

On 09/25/2016 04:10 AM, Norbert Lange wrote: Hello, did you try without your patches, to see if you can reproduce the problem? I can fix my issues if I disable usb autosuspend To narrow down the causes I can think of: *) Some hardware issue only on my side -> please try to reproduce it with

Re: undefined reference to `printk'

On Sun, 2016-09-25 at 11:40 +0800, kbuild test robot wrote: > Hi Joe, Hey Fengguang > It's probably a bug fix that unveils the link errors. I think all of these reports about compiler-gcc integrations are bogons. > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >

Re: undefined reference to `printk'

On Sun, 2016-09-25 at 11:40 +0800, kbuild test robot wrote: > Hi Joe, Hey Fengguang > It's probably a bug fix that unveils the link errors. I think all of these reports about compiler-gcc integrations are bogons. > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >

RE: [PATCH][v10] PM / hibernate: Verify the consistent of e820 memory map by md5 digest

Hi, Sorry for late response, I missed the thread in mailbox, > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Monday, September 19, 2016 7:46 PM > To: Chen, Yu C > Cc: Linux PM; the arch/x86 maintainers; Linux Kernel

RE: [PATCH][v10] PM / hibernate: Verify the consistent of e820 memory map by md5 digest

Hi, Sorry for late response, I missed the thread in mailbox, > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Monday, September 19, 2016 7:46 PM > To: Chen, Yu C > Cc: Linux PM; the arch/x86 maintainers; Linux Kernel

RE: [PATCH][v10] PM / hibernate: Verify the consistent of e820 memory map by md5 digest

Hi, Sorry for late response, I missed this thread in mailbox, > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Monday, September 19, 2016 7:46 PM > To: Chen, Yu C > Cc: Linux PM; the arch/x86 maintainers; Linux Kernel

RE: [PATCH][v10] PM / hibernate: Verify the consistent of e820 memory map by md5 digest

Hi, Sorry for late response, I missed this thread in mailbox, > -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Monday, September 19, 2016 7:46 PM > To: Chen, Yu C > Cc: Linux PM; the arch/x86 maintainers; Linux Kernel

undefined reference to `printk'

Hi Joe, 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: 9c0e28a7be656d737fb18998e2dcb0b8ce595643 commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various

undefined reference to `printk'

Hi Joe, 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: 9c0e28a7be656d737fb18998e2dcb0b8ce595643 commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various

[PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

From: Christophe TORDEUX With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and probably other Sentelic FSP touchpads are detected as a BYD touchpad and lose multitouch features. During the BYD handshake in the byd_detect function, the BYD driver mistakenly

[PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

From: Christophe TORDEUX With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and probably other Sentelic FSP touchpads are detected as a BYD touchpad and lose multitouch features. During the BYD handshake in the byd_detect function, the BYD driver mistakenly interprets a standard PS/2

Re: powerpc/32: Remove CLR_TOP32

On Fri, 2016-05-08 at 11:27:59 UTC, Christophe Leroy wrote: > CLR_TOP32() is defined as blank. Last useful instance of CLR_TOP32() > was removed by commit 40ef8cbc6d360 ("powerpc: Get 64-bit configs to > compile with ARCH=powerpc") > > Signed-off-by: Christophe Leroy

Re: powerpc/32: Remove CLR_TOP32

On Fri, 2016-05-08 at 11:27:59 UTC, Christophe Leroy wrote: > CLR_TOP32() is defined as blank. Last useful instance of CLR_TOP32() > was removed by commit 40ef8cbc6d360 ("powerpc: Get 64-bit configs to > compile with ARCH=powerpc") > > Signed-off-by: Christophe Leroy Applied to powerpc next,

Re: [v2] powerpc: fix usage of _PAGE_RO in hugepage

On Mon, 2016-19-09 at 10:58:54 UTC, Christophe Leroy wrote: > On some CPUs like the 8xx, _PAGE_RW hence _PAGE_WRITE is defined > as 0 and _PAGE_RO has to be set when a page is not writable > > _PAGE_RO is defined by default in pte-common.h, however BOOK3S/64 > doesn't include that file so

Re: [v2] powerpc: Clean up tm_abort duplication in hash_utils_64.c

On Fri, 2016-02-09 at 06:17:26 UTC, Rui Teng wrote: > The same logic appears twice and should probably be pulled out into a > function. > > Suggested-by: Michael Ellerman > Signed-off-by: Rui Teng Applied to powerpc next, thanks.

Re: [v2] powerpc: fix usage of _PAGE_RO in hugepage

On Mon, 2016-19-09 at 10:58:54 UTC, Christophe Leroy wrote: > On some CPUs like the 8xx, _PAGE_RW hence _PAGE_WRITE is defined > as 0 and _PAGE_RO has to be set when a page is not writable > > _PAGE_RO is defined by default in pte-common.h, however BOOK3S/64 > doesn't include that file so

Re: [v2] powerpc: Clean up tm_abort duplication in hash_utils_64.c

On Fri, 2016-02-09 at 06:17:26 UTC, Rui Teng wrote: > The same logic appears twice and should probably be pulled out into a > function. > > Suggested-by: Michael Ellerman > Signed-off-by: Rui Teng Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/f1a55ce0544251746d9b52fb85

[PATCH] PCI: enable extended tags support for PCIe endpoints

Each PCIe device can issue up to 32 transactions at a time by default. Each transaction is tracked by a tag number on the bus. 32 outstanding transactions is not enough for some performance critical applications especially when a lot of small sized frames are transmitted. Extended tags support

[PATCH] PCI: enable extended tags support for PCIe endpoints

Each PCIe device can issue up to 32 transactions at a time by default. Each transaction is tracked by a tag number on the bus. 32 outstanding transactions is not enough for some performance critical applications especially when a lot of small sized frames are transmitted. Extended tags support

[PATCH][V2] mlxsw: spectrum: remove redundant check if err is zero

From: Colin Ian King There is an earlier check and return if err is non-zero, so the check to see if it is zero is redundant in every iteration of the loop and hence the check can be removed. Signed-off-by: Colin Ian King ---

[PATCH][V2] mlxsw: spectrum: remove redundant check if err is zero

From: Colin Ian King There is an earlier check and return if err is non-zero, so the check to see if it is zero is redundant in every iteration of the loop and hence the check can be removed. Signed-off-by: Colin Ian King --- drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 10 +-

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 4:35 PM, Cedric Blancher wrote: >> >> void *entry = parent->slots[offset]; >> int siboff = entry - parent->slots; > > If entry is a pointer to void, how can you do pointer arithmetic with it? It's actually void **. (That said,

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 4:35 PM, Cedric Blancher wrote: >> >> void *entry = parent->slots[offset]; >> int siboff = entry - parent->slots; > > If entry is a pointer to void, how can you do pointer arithmetic with it? It's actually void **. (That said, gcc has an extension that

Re: [RFC] remove unnecessary condition in remove_inode_hugepages

On 09/23/2016 07:56 PM, zhong jiang wrote: > On 2016/9/24 1:19, Mike Kravetz wrote: >> On 09/22/2016 06:53 PM, zhong jiang wrote: >>> At present, we need to call hugetlb_fix_reserve_count when >>> hugetlb_unrserve_pages fails, >>> and PagePrivate will decide hugetlb reserves counts. >>> >>> we

Re: [RFC] remove unnecessary condition in remove_inode_hugepages

On 09/23/2016 07:56 PM, zhong jiang wrote: > On 2016/9/24 1:19, Mike Kravetz wrote: >> On 09/22/2016 06:53 PM, zhong jiang wrote: >>> At present, we need to call hugetlb_fix_reserve_count when >>> hugetlb_unrserve_pages fails, >>> and PagePrivate will decide hugetlb reserves counts. >>> >>> we

Re: [PATCH] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

From: Chris Roth Date: Sat, 24 Sep 2016 10:59:04 -0600 > Due to my lack of familiarity with the how git send-email works, I've > unintentionally had my name listed as the first 'from' whereas I > intended Allan Chou to be listed as the first 'from' in the patch. If > anyone

Re: [PATCH] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

From: Chris Roth Date: Sat, 24 Sep 2016 10:59:04 -0600 > Due to my lack of familiarity with the how git send-email works, I've > unintentionally had my name listed as the first 'from' whereas I > intended Allan Chou to be listed as the first 'from' in the patch. If > anyone can correct this on

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On 22 September 2016 at 20:53, Matthew Wilcox wrote: > From: Matthew Wilcox > > When compiling the radix tree with -O2, GCC thinks it can optimise: > > void *entry = parent->slots[offset]; > int siboff = entry - parent->slots;

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On 22 September 2016 at 20:53, Matthew Wilcox wrote: > From: Matthew Wilcox > > When compiling the radix tree with -O2, GCC thinks it can optimise: > > void *entry = parent->slots[offset]; > int siboff = entry - parent->slots; If entry is a pointer to void, how can you do

[PATCH net-next 4/8] rxrpc: Reinitialise the call ACK and timer state for client reply phase

Clear the ACK reason, ACK timer and resend timer when entering the client reply phase when the first DATA packet is received. New ACKs will be proposed once the data is queued. The resend timer is no longer relevant and we need to cancel ACKs scheduled to probe for a lost reply. Signed-off-by:

[PATCH net-next 3/8] rxrpc: Include the last reply DATA serial number in the final ACK

In a client call, include the serial number of the last DATA packet of the reply in the final ACK. Signed-off-by: David Howells --- net/rxrpc/recvmsg.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c

[PATCH net-next 6/8] rxrpc: Generate a summary of the ACK state for later use

Generate a summary of the Tx buffer packet state when an ACK is received for use in a later patch that does congestion management. Signed-off-by: David Howells --- net/rxrpc/ar-internal.h | 14 ++ net/rxrpc/input.c | 45

[PATCH net-next 8/8] rxrpc: Implement slow-start

Implement RxRPC slow-start, which is similar to RFC 5681 for TCP. A tracepoint is added to log the state of the congestion management algorithm and the decisions it makes. Notes: (1) Since we send fixed-size DATA packets (apart from the final packet in each phase), counters and

[PATCH net-next 6/8] rxrpc: Generate a summary of the ACK state for later use

Generate a summary of the Tx buffer packet state when an ACK is received for use in a later patch that does congestion management. Signed-off-by: David Howells --- net/rxrpc/ar-internal.h | 14 ++ net/rxrpc/input.c | 45 ++--- 2

[PATCH net-next 8/8] rxrpc: Implement slow-start

Implement RxRPC slow-start, which is similar to RFC 5681 for TCP. A tracepoint is added to log the state of the congestion management algorithm and the decisions it makes. Notes: (1) Since we send fixed-size DATA packets (apart from the final packet in each phase), counters and

[PATCH net-next 3/8] rxrpc: Include the last reply DATA serial number in the final ACK

In a client call, include the serial number of the last DATA packet of the reply in the final ACK. Signed-off-by: David Howells --- net/rxrpc/recvmsg.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c index

[PATCH net-next 4/8] rxrpc: Reinitialise the call ACK and timer state for client reply phase

Clear the ACK reason, ACK timer and resend timer when entering the client reply phase when the first DATA packet is received. New ACKs will be proposed once the data is queued. The resend timer is no longer relevant and we need to cancel ACKs scheduled to probe for a lost reply. Signed-off-by:

[PATCH net-next 7/8] rxrpc: Schedule an ACK if the reply to a client call appears overdue

If we've sent all the request data in a client call but haven't seen any sign of the reply data yet, schedule an ACK to be sent to the server to find out if the reply data got lost. If the server hasn't yet hard-ACK'd the request data, we send a PING ACK to demand a response to find out whether

[PATCH net-next 5/8] rxrpc: Delay the resend timer to allow for nsec->jiffies conv error

When determining the resend timer value, we have a value in nsec but the timer is in jiffies which may be a million or more times more coarse. nsecs_to_jiffies() rounds down - which means that the resend timeout expressed as jiffies is very likely earlier than the one expressed as nanoseconds from

[PATCH net-next 7/8] rxrpc: Schedule an ACK if the reply to a client call appears overdue

If we've sent all the request data in a client call but haven't seen any sign of the reply data yet, schedule an ACK to be sent to the server to find out if the reply data got lost. If the server hasn't yet hard-ACK'd the request data, we send a PING ACK to demand a response to find out whether

[PATCH net-next 5/8] rxrpc: Delay the resend timer to allow for nsec->jiffies conv error

When determining the resend timer value, we have a value in nsec but the timer is in jiffies which may be a million or more times more coarse. nsecs_to_jiffies() rounds down - which means that the resend timeout expressed as jiffies is very likely earlier than the one expressed as nanoseconds from

[PATCH net-next 2/8] rxrpc: Send an immediate ACK if we fill in a hole

Send an immediate ACK if we fill in a hole in the buffer left by an out-of-sequence packet. This may allow the congestion management in the peer to avoid a retransmission if packets got reordered on the wire. Signed-off-by: David Howells --- net/rxrpc/input.c | 10

[PATCH net-next 0/8] rxrpc: Implement slow-start and other bits

git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite Tagged thusly: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160924 David --- David Howells (8): rxrpc: Send an ACK after every few DATA packets we receive rxrpc: Send an immediate ACK if

[PATCH net-next 1/8] rxrpc: Send an ACK after every few DATA packets we receive

Send an ACK if we haven't sent one for the last two packets we've received. This keeps the other end apprised of where we've got to - which is important if they're doing slow-start. We do this in recvmsg so that we can dispatch a packet directly without the need to wake up the background thread.

[PATCH net-next 2/8] rxrpc: Send an immediate ACK if we fill in a hole

Send an immediate ACK if we fill in a hole in the buffer left by an out-of-sequence packet. This may allow the congestion management in the peer to avoid a retransmission if packets got reordered on the wire. Signed-off-by: David Howells --- net/rxrpc/input.c | 10 +- 1 file

[PATCH net-next 0/8] rxrpc: Implement slow-start and other bits

git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite Tagged thusly: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160924 David --- David Howells (8): rxrpc: Send an ACK after every few DATA packets we receive rxrpc: Send an immediate ACK if

[PATCH net-next 1/8] rxrpc: Send an ACK after every few DATA packets we receive

Send an ACK if we haven't sent one for the last two packets we've received. This keeps the other end apprised of where we've got to - which is important if they're doing slow-start. We do this in recvmsg so that we can dispatch a packet directly without the need to wake up the background thread.

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 2:04 PM, Kirill A. Shutemov wrote: > > Well, my ext4-with-huge-pages patchset[1] uses multi-order entries. > It also converts shmem-with-huge-pages and hugetlb to them. Ok, so that code actually has a chance of being used. I guess we'll

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 2:04 PM, Kirill A. Shutemov wrote: > > Well, my ext4-with-huge-pages patchset[1] uses multi-order entries. > It also converts shmem-with-huge-pages and hugetlb to them. Ok, so that code actually has a chance of being used. I guess we'll not remove it. But I *would* like

[PATCH] libnvdimm, region: fix flush hint table thinko

The definition of the flush hint table as: void __iomem *flush_wpq[0][0]; ...passed the unit test, but is broken as flush_wpq[0][1] and flush_wpq[1][0] refer to the same entry. Fix this to use a helper that calculates a slot in the table based on the geometry of flush hints in the

[PATCH] libnvdimm, region: fix flush hint table thinko

The definition of the flush hint table as: void __iomem *flush_wpq[0][0]; ...passed the unit test, but is broken as flush_wpq[0][1] and flush_wpq[1][0] refer to the same entry. Fix this to use a helper that calculates a slot in the table based on the geometry of flush hints in the

[PATCH] clk: at91: Fix a return value in case of error

If 'clk_hw_register()' fails, it is likely that we expect to return an error instead of a valid pointer (which would mean success). 'clk_hw_register()' returns a bool, so we don't have the detail of the error. Return -ENOMEM instead, as it seems to be the most common error returned by

[PATCH] clk: at91: Fix a return value in case of error

If 'clk_hw_register()' fails, it is likely that we expect to return an error instead of a valid pointer (which would mean success). 'clk_hw_register()' returns a bool, so we don't have the detail of the error. Return -ENOMEM instead, as it seems to be the most common error returned by

[PATCH] firewire: nosy: do not ignore errors in ioremap_nocache()

There is no check if ioremap_nocache() returns a valid pointer. Potentially it can lead to null pointer dereference. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/firewire/nosy.c | 7 +++ 1 file changed,

[PATCH] firewire: nosy: do not ignore errors in ioremap_nocache()

There is no check if ioremap_nocache() returns a valid pointer. Potentially it can lead to null pointer dereference. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/firewire/nosy.c | 7 +++ 1 file changed, 7 insertions(+) diff

Re: [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2

Krzysztof Kozlowski writes: > On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote: >> >> Krzysztof Kozlowski writes: >> >> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote: >> >> This allows to reboot the device into recovery mode and into the download >> >>

Re: [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2

Krzysztof Kozlowski writes: > On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote: >> >> Krzysztof Kozlowski writes: >> >> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote: >> >> This allows to reboot the device into recovery mode and into the download >> >>

Re: [PATCH] staging: sm750fb: rename getChipType to get_chip_type

On Fri, Sep 23, 2016 at 02:13:52PM +0200, Greg KH wrote: > On Thu, Sep 22, 2016 at 09:15:45PM +0300, Moshe Green wrote: > > Rename CamelCased function getChipType to get_chip_type. > > This issue was found by checkpatch.pl > > As this is a global function, can you rename it to something like >

Re: [PATCH] staging: sm750fb: rename getChipType to get_chip_type

On Fri, Sep 23, 2016 at 02:13:52PM +0200, Greg KH wrote: > On Thu, Sep 22, 2016 at 09:15:45PM +0300, Moshe Green wrote: > > Rename CamelCased function getChipType to get_chip_type. > > This issue was found by checkpatch.pl > > As this is a global function, can you rename it to something like >

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 01:21:36PM -0700, Linus Torvalds wrote: > On Fri, Sep 23, 2016 at 1:16 PM, Matthew Wilcox > wrote: > > > > #ifdef CONFIG_RADIX_TREE_MULTIORDER > > if (radix_tree_is_internal_node(entry)) { > > - unsigned long siboff =

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 01:21:36PM -0700, Linus Torvalds wrote: > On Fri, Sep 23, 2016 at 1:16 PM, Matthew Wilcox > wrote: > > > > #ifdef CONFIG_RADIX_TREE_MULTIORDER > > if (radix_tree_is_internal_node(entry)) { > > - unsigned long siboff = get_slot_offset(parent, entry);

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Saturday, September 24, 2016 4:14:15 PM CEST zhichang wrote: > > In V3, the outb is : > > void outb(u8 value, unsigned long addr) > { > if (!arm64_extio_ops || arm64_extio_ops->start > addr || > arm64_extio_ops->end < addr) > writeb(value,

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Saturday, September 24, 2016 4:14:15 PM CEST zhichang wrote: > > In V3, the outb is : > > void outb(u8 value, unsigned long addr) > { > if (!arm64_extio_ops || arm64_extio_ops->start > addr || > arm64_extio_ops->end < addr) > writeb(value,

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 1:21 PM, Linus Torvalds wrote: > > That said, if this code isn't even used, as Konstantin says (THP > selects it - doesn't THP use it?), then the fix really should be to > just remove the odd code instead of adding to it. > > Looking around

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Sat, Sep 24, 2016 at 1:21 PM, Linus Torvalds wrote: > > That said, if this code isn't even used, as Konstantin says (THP > selects it - doesn't THP use it?), then the fix really should be to > just remove the odd code instead of adding to it. > > Looking around for uses that set "order" to

[PATCH 1/2] brcmfmac: initialize fws(ignal) for BCDC protocol only

From: Rafał Miłecki There are two protocols used by Broadcom FullMAC devices: BCDC and msgbuf. They use different ways for (some part of) communication with the firmware. Firmware Signaling is required for the first one only (BCDC). So far we were always initializing fws and

[PATCH 2/2] brcmfmac: compile fws(ignal) code only with BCDC support enabled

From: Rafał Miłecki It's not needed by the other (msgbuf) protocol, so let's save some size and compile it conditionally. Signed-off-by: Rafał Miłecki --- .../wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 +- .../broadcom/brcm80211/brcmfmac/fwsignal.h

[PATCH 1/2] brcmfmac: initialize fws(ignal) for BCDC protocol only

From: Rafał Miłecki There are two protocols used by Broadcom FullMAC devices: BCDC and msgbuf. They use different ways for (some part of) communication with the firmware. Firmware Signaling is required for the first one only (BCDC). So far we were always initializing fws and always calling it's

[PATCH 2/2] brcmfmac: compile fws(ignal) code only with BCDC support enabled

From: Rafał Miłecki It's not needed by the other (msgbuf) protocol, so let's save some size and compile it conditionally. Signed-off-by: Rafał Miłecki --- .../wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 +- .../broadcom/brcm80211/brcmfmac/fwsignal.h | 59 ++

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

Joe Perches writes: > On Sat, 2016-09-24 at 14:06 -0500, Larry Finger wrote: >> On 09/24/2016 12:32 PM, Joe Perches wrote: > [] >> o Reindent all the switch/case blocks to a more normal >> kernel style (git diff -w would show no changes here) >> That sounds like busy work to

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

Joe Perches writes: > On Sat, 2016-09-24 at 14:06 -0500, Larry Finger wrote: >> On 09/24/2016 12:32 PM, Joe Perches wrote: > [] >> o Reindent all the switch/case blocks to a more normal >> kernel style (git diff -w would show no changes here) >> That sounds like busy work to me, but if you want

RE: [PATCH v6 1/9] rpmb: add Replay Protected Memory Block (RPMB) subsystem

> > > > > > Signed-off-by: Tomas Winkler > > Signed-off-by: Alexander Usyskin > Tested-by: Avri Altman > > - mmc - full functionality. One issue found that was fixed on V6: patch V6 > 2/9. > - ufs - read & read

RE: [PATCH v6 1/9] rpmb: add Replay Protected Memory Block (RPMB) subsystem

> > > > > > Signed-off-by: Tomas Winkler > > Signed-off-by: Alexander Usyskin > Tested-by: Avri Altman > > - mmc - full functionality. One issue found that was fixed on V6: patch V6 > 2/9. > - ufs - read & read counter only. Testing is still wip. > > > > +static int

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

On Sat, 2016-09-24 at 14:06 -0500, Larry Finger wrote: > On 09/24/2016 12:32 PM, Joe Perches wrote: [] > o Reindent all the switch/case blocks to a more normal > kernel style (git diff -w would show no changes here) > That sounds like busy work to me, but if you want to do it, go ahead. It's

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

On Sat, 2016-09-24 at 14:06 -0500, Larry Finger wrote: > On 09/24/2016 12:32 PM, Joe Perches wrote: [] > o Reindent all the switch/case blocks to a more normal > kernel style (git diff -w would show no changes here) > That sounds like busy work to me, but if you want to do it, go ahead. It's

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Fri, Sep 23, 2016 at 1:16 PM, Matthew Wilcox wrote: > > #ifdef CONFIG_RADIX_TREE_MULTIORDER > if (radix_tree_is_internal_node(entry)) { > - unsigned long siboff = get_slot_offset(parent, entry); > + unsigned long siboff =

Re: [PATCH 2/2] radix-tree: Fix optimisation problem

On Fri, Sep 23, 2016 at 1:16 PM, Matthew Wilcox wrote: > > #ifdef CONFIG_RADIX_TREE_MULTIORDER > if (radix_tree_is_internal_node(entry)) { > - unsigned long siboff = get_slot_offset(parent, entry); > + unsigned long siboff = get_slot_offset(parent, > +

  1   2   3   4   5   >