Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure

> > I did fix an issue recently with that. See > > > > commit fbbeefdd21049fcf9437c809da3828b210577f36 > > Author: Andrew Lunn > > Date: Sun Jul 30 19:36:05 2017 +0200 > > > > net: fec: Allow reception of frames bigger than 1522 bytes > > > > The FEC Receive Control

Re: DSA mv88e6xxx RX frame errors and TCP/IP RX failure

> > I did fix an issue recently with that. See > > > > commit fbbeefdd21049fcf9437c809da3828b210577f36 > > Author: Andrew Lunn > > Date: Sun Jul 30 19:36:05 2017 +0200 > > > > net: fec: Allow reception of frames bigger than 1522 bytes > > > > The FEC Receive Control Register has a 14

Re: [PATCH 2/7] dt-bindings: PM / OPP: add clocks per OPP node support

On Thu, Aug 24, 2017 at 12:10:05AM +0800, Dong Aisheng wrote: > It's used for platforms where different OPPs may use different clocks. > With this extended binding, user could specify the correct clock for each > OPP node. > > Cc: Viresh Kumar > Cc: Nishanth Menon

Re: [PATCH 2/7] dt-bindings: PM / OPP: add clocks per OPP node support

On Thu, Aug 24, 2017 at 12:10:05AM +0800, Dong Aisheng wrote: > It's used for platforms where different OPPs may use different clocks. > With this extended binding, user could specify the correct clock for each > OPP node. > > Cc: Viresh Kumar > Cc: Nishanth Menon > Cc: Stephen Boyd > Cc:

Re: [PATCH 3/3 v8] ARC: hsdk: initial port for HSDK board

Hi Rob, On 07/17/2017 10:38 AM, Rob Herring wrote: On Wed, Jul 12, 2017 at 12:40:23PM +0300, Eugeniy Paltsev wrote: From: Alexey Brodkin This initial port adds support of ARC HS Development Kit board with some basic features such serial port, USB, SD/MMC and Ethernet. Essentially we run

Re: [PATCH 3/3 v8] ARC: hsdk: initial port for HSDK board

Hi Rob, On 07/17/2017 10:38 AM, Rob Herring wrote: On Wed, Jul 12, 2017 at 12:40:23PM +0300, Eugeniy Paltsev wrote: From: Alexey Brodkin This initial port adds support of ARC HS Development Kit board with some basic features such serial port, USB, SD/MMC and Ethernet. Essentially we run

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

On 08/31/17 09:36, Jani Nikula wrote: > On Thu, 31 Aug 2017, Jani Nikula wrote: >> On Thu, 31 Aug 2017, Randy Dunlap wrote: >>> On 08/31/17 07:17, Jonathan Corbet wrote: On Thu, 31 Aug 2017 10:56:26 -0300 Mauro Carvalho Chehab

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

On 08/31/17 09:36, Jani Nikula wrote: > On Thu, 31 Aug 2017, Jani Nikula wrote: >> On Thu, 31 Aug 2017, Randy Dunlap wrote: >>> On 08/31/17 07:17, Jonathan Corbet wrote: On Thu, 31 Aug 2017 10:56:26 -0300 Mauro Carvalho Chehab wrote: > It should have something to do with

Re: [PATCH 2/8] kbuild: Support for Symbols.list creation

On Thu, Aug 31, 2017 at 11:24:39AM -0400, Joe Lawrence wrote: > > +quiet_cmd_klp_map = LIVEPATCH Symbols.list > > nit: I don't think any other quiet_cmd invocations put a tab between the > label and file list. That said, "LIVEPATCH" is > 8 chars, so it's not > going to line up anyway.

Re: [PATCH 2/8] kbuild: Support for Symbols.list creation

On Thu, Aug 31, 2017 at 11:24:39AM -0400, Joe Lawrence wrote: > > +quiet_cmd_klp_map = LIVEPATCH Symbols.list > > nit: I don't think any other quiet_cmd invocations put a tab between the > label and file list. That said, "LIVEPATCH" is > 8 chars, so it's not > going to line up anyway.

Re: [PATCH] mm, uprobes: fix multiple free of ->uprobes_state.xol_area

Hi Oleg, On Wed, Aug 30, 2017 at 06:37:14PM +0200, Oleg Nesterov wrote: > On 08/29, Eric Biggers wrote: > > > > --- a/kernel/events/uprobes.c > > +++ b/kernel/events/uprobes.c > > @@ -1262,8 +1262,6 @@ void uprobe_end_dup_mmap(void) > > > > void uprobe_dup_mmap(struct mm_struct *oldmm, struct

Re: [PATCH] mm, uprobes: fix multiple free of ->uprobes_state.xol_area

Hi Oleg, On Wed, Aug 30, 2017 at 06:37:14PM +0200, Oleg Nesterov wrote: > On 08/29, Eric Biggers wrote: > > > > --- a/kernel/events/uprobes.c > > +++ b/kernel/events/uprobes.c > > @@ -1262,8 +1262,6 @@ void uprobe_end_dup_mmap(void) > > > > void uprobe_dup_mmap(struct mm_struct *oldmm, struct

Re: [PATCH] wl1251: add a missing spin_lock_init()

From: Pavel Machek Date: Thu, 31 Aug 2017 16:47:43 +0200 > Dave, Linus -- can you still take the patch? Pavel, please do not bypass maintainers like this. It's really rude, and if you do things like that instead of trying to work properly with us, your relationship with these

Re: [PATCH] wl1251: add a missing spin_lock_init()

From: Pavel Machek Date: Thu, 31 Aug 2017 16:47:43 +0200 > Dave, Linus -- can you still take the patch? Pavel, please do not bypass maintainers like this. It's really rude, and if you do things like that instead of trying to work properly with us, your relationship with these maintainers will

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/3] three bfq fixes restoring service guarantees with random sync writes in bg

On Thu, 2017-08-31 at 19:12 +0200, Paolo Valente wrote: > > Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith ha > > scritto: > > > > On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote: > >> On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote: > >>> [SECOND TAKE,

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/3] three bfq fixes restoring service guarantees with random sync writes in bg

On Thu, 2017-08-31 at 19:12 +0200, Paolo Valente wrote: > > Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith ha > > scritto: > > > > On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote: > >> On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote: > >>> [SECOND TAKE, with just the

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Aug 31, 2017 at 12:25:42PM -0500, Josh Poimboeuf wrote: > 2) Put "sp" in the clobbers list instead of as an i/o constraint. This >mostly works for GCC, and doesn't break clang. However, it causes >GCC to insert a "lea -0x10(%rbp),%rsp" in the epilogue of every >affected

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Aug 31, 2017 at 12:25:42PM -0500, Josh Poimboeuf wrote: > 2) Put "sp" in the clobbers list instead of as an i/o constraint. This >mostly works for GCC, and doesn't break clang. However, it causes >GCC to insert a "lea -0x10(%rbp),%rsp" in the epilogue of every >affected

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

On Wed, Aug 30, 2017 at 9:28 PM, Greg Kroah-Hartman wrote: > Ok, exactly what git commit ids should I revert from the tree? But > really, a fix would be easier at this point :) I sent a fixup patch as a separate reply to this email. Please also apply [patch v3 6/6]

Re: [PATCH v3 1/6] android: binder: Refactor prev and next buffer into a helper function

On Wed, Aug 30, 2017 at 9:28 PM, Greg Kroah-Hartman wrote: > Ok, exactly what git commit ids should I revert from the tree? But > really, a fix would be easier at this point :) I sent a fixup patch as a separate reply to this email. Please also apply [patch v3 6/6] as it was not in v2, which

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Aug 31, 2017 at 09:11:54AM -0700, Linus Torvalds wrote: > On Thu, Aug 31, 2017 at 7:11 AM, Josh Poimboeuf wrote: > > > > Make the following changes: > > > > - Give alternative_io(), alternative_call(), and alternative_call_2() > > consistent interfaces. The

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Aug 31, 2017 at 09:11:54AM -0700, Linus Torvalds wrote: > On Thu, Aug 31, 2017 at 7:11 AM, Josh Poimboeuf wrote: > > > > Make the following changes: > > > > - Give alternative_io(), alternative_call(), and alternative_call_2() > > consistent interfaces. The constraints are provided by

[GIT PULL] irqchip updates for 4.14

Hi Thomas, Here's the pull request for the 4.14 irqchip updates. I'm guilty for the bulk of the noise, as this contains the bulk of the GICv4 irqchip patches (the KVM part is still in flight). The rest is fairly mundane (one new driver, and a collection of minor updates and fixes). Please pull.

[GIT PULL] irqchip updates for 4.14

Hi Thomas, Here's the pull request for the 4.14 irqchip updates. I'm guilty for the bulk of the noise, as this contains the bulk of the GICv4 irqchip patches (the KVM part is still in flight). The rest is fairly mundane (one new driver, and a collection of minor updates and fixes). Please pull.

[PATCH] android: binder: fixup crash introduced by moving buffer hdr

Fix crash introduced by 74310e06be4d74dcf67cd108366710dee5c576d5 (android: binder: Move buffer out of area shared with user space) when close is called after open without mmap in between. Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c | 2 +- 1 file changed,

[PATCH] android: binder: fixup crash introduced by moving buffer hdr

Fix crash introduced by 74310e06be4d74dcf67cd108366710dee5c576d5 (android: binder: Move buffer out of area shared with user space) when close is called after open without mmap in between. Signed-off-by: Sherry Yang --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 1/4] sysvipc: unteach ids->next_id for !CHECKPOINT_RESTORE

The next_id object-allocation functionality was introduced in 03f595668017f (ipc: add sysctl to specify desired next object id). Given that these new entries are _only_ exported under the CONFIG_CHECKPOINT_RESTORE option, there is no point for the common case to even know about ->next_id. As such

[PATCH 2/4] sysvipc: duplicate lock comments wrt ipc_addid()

The comment in msgqueues when using ipc_addid() is quite useful imo. Duplicate it for shm and semaphores. Signed-off-by: Davidlohr Bueso --- ipc/sem.c | 1 + ipc/shm.c | 1 + 2 files changed, 2 insertions(+) diff --git a/ipc/sem.c b/ipc/sem.c index 013c7981f3c7..29c6ab6badc2

[PATCH 1/4] sysvipc: unteach ids->next_id for !CHECKPOINT_RESTORE

The next_id object-allocation functionality was introduced in 03f595668017f (ipc: add sysctl to specify desired next object id). Given that these new entries are _only_ exported under the CONFIG_CHECKPOINT_RESTORE option, there is no point for the common case to even know about ->next_id. As such

[PATCH 2/4] sysvipc: duplicate lock comments wrt ipc_addid()

The comment in msgqueues when using ipc_addid() is quite useful imo. Duplicate it for shm and semaphores. Signed-off-by: Davidlohr Bueso --- ipc/sem.c | 1 + ipc/shm.c | 1 + 2 files changed, 2 insertions(+) diff --git a/ipc/sem.c b/ipc/sem.c index 013c7981f3c7..29c6ab6badc2 100644 ---

[PATCH 4/4] sysvipc: make get_maxid O(1) again

For a custom microbenchmark on a 3.30GHz Xeon SandyBridge, which calls IPC_STAT over and over, it was calculated that, on avg the cost of ipc_get_maxid() for increasing amounts of keys was: 10 keys: ~900 cycles 100 keys: ~15000 cycles 1000 keys: ~15 cycles 1 keys: ~210 cycles This is

[PATCH 4/4] sysvipc: make get_maxid O(1) again

For a custom microbenchmark on a 3.30GHz Xeon SandyBridge, which calls IPC_STAT over and over, it was calculated that, on avg the cost of ipc_get_maxid() for increasing amounts of keys was: 10 keys: ~900 cycles 100 keys: ~15000 cycles 1000 keys: ~15 cycles 1 keys: ~210 cycles This is

[PATCH 3/4] sysvipc: properly name ipc_addid() limit parameter

This is better understood as a limit, instead of size; exactly like the function comment indicates. Rename it. Signed-off-by: Davidlohr Bueso --- ipc/util.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ipc/util.c b/ipc/util.c index

[PATCH 3/4] sysvipc: properly name ipc_addid() limit parameter

This is better understood as a limit, instead of size; exactly like the function comment indicates. Rename it. Signed-off-by: Davidlohr Bueso --- ipc/util.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ipc/util.c b/ipc/util.c index fb69152705e6..d4091665f439

[PATCH -next 0/4] sysvipc: ipc-key management improvements

Hi, Here are a few improvements I spotted while eyeballing Guillaume's rhashtable implementation for ipc keys. The first and fourth patches are the interesting ones, the middle two are trivial. Applies against today's -next. Passes ltp ipc related testcases. Thanks! Davidlohr Bueso (4):

[PATCH -next 0/4] sysvipc: ipc-key management improvements

Hi, Here are a few improvements I spotted while eyeballing Guillaume's rhashtable implementation for ipc keys. The first and fourth patches are the interesting ones, the middle two are trivial. Applies against today's -next. Passes ltp ipc related testcases. Thanks! Davidlohr Bueso (4):

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote: > > Oh! So it's gcc-version sensitive? That's alarming. Is this mapping correct: > > 4.8.5: WARN, eventual kernel hang > 6.3.1, 7.0.1: WARN, but continues working Yeah, that's correct.  I find that troubling, simply because this gcc version

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Thu, 2017-08-31 at 10:00 -0700, Kees Cook wrote: > > Oh! So it's gcc-version sensitive? That's alarming. Is this mapping correct: > > 4.8.5: WARN, eventual kernel hang > 6.3.1, 7.0.1: WARN, but continues working Yeah, that's correct.  I find that troubling, simply because this gcc version

[PATCH RESEND v2 2/3] tpm2-cmd: Use dynamic delay to wait for self test result

In order to avoid delaying the code longer than necessary while still giving the TPM enough time to execute the self tests asynchronously, start with a small delay between two polls and increase it each round. Signed-off-by: Alexander Steffen Reviewed-by: Jarkko

[PATCH RESEND v2 2/3] tpm2-cmd: Use dynamic delay to wait for self test result

In order to avoid delaying the code longer than necessary while still giving the TPM enough time to execute the self tests asynchronously, start with a small delay between two polls and increase it each round. Signed-off-by: Alexander Steffen Reviewed-by: Jarkko Sakkinen ---

[PATCH RESEND v2 3/3] tpm2-cmd: React correctly to RC_TESTING from self tests

The TPM can choose one of two ways to react to the TPM2_SelfTest command. It can either run all self tests synchronously and then return RC_SUCCESS once all tests were successful. Or it can choose to run the tests asynchronously and return RC_TESTING immediately while the self tests still execute

[PATCH RESEND v2 3/3] tpm2-cmd: React correctly to RC_TESTING from self tests

The TPM can choose one of two ways to react to the TPM2_SelfTest command. It can either run all self tests synchronously and then return RC_SUCCESS once all tests were successful. Or it can choose to run the tests asynchronously and return RC_TESTING immediately while the self tests still execute

[PATCH RESEND v2 1/3] tpm2-cmd: Trigger only missing self tests

tpm2_do_selftest is only used during initialization of the TPM to ensure that the device functions correctly. Therefore, it is sufficient to request only missing self tests (parameter full_test=0), not a reexecution of all self tests, as was done before. This allows for a faster execution of this

[PATCH RESEND v2 1/3] tpm2-cmd: Trigger only missing self tests

tpm2_do_selftest is only used during initialization of the TPM to ensure that the device functions correctly. Therefore, it is sufficient to request only missing self tests (parameter full_test=0), not a reexecution of all self tests, as was done before. This allows for a faster execution of this

[PATCH RESEND v2 0/3] tpm2-cmd: Improve self test execution

The self test logic for TPM 2.0 was probably based on the implementation for TPM 1.2, but did not correctly take into account some TPM 2.0 specifics. This patch series fixes those issues. v2: - Moved implementation description from comment to commit message. Alexander Steffen (3): tpm2-cmd:

[PATCH RESEND v2 0/3] tpm2-cmd: Improve self test execution

The self test logic for TPM 2.0 was probably based on the implementation for TPM 1.2, but did not correctly take into account some TPM 2.0 specifics. This patch series fixes those issues. v2: - Moved implementation description from comment to commit message. Alexander Steffen (3): tpm2-cmd:

[RFC][PATCH] perf: Rewrite enabled/running timekeeping

On Wed, Aug 23, 2017 at 11:54:15AM +0300, Alexey Budankov wrote: > On 22.08.2017 23:47, Peter Zijlstra wrote: > > On Thu, Aug 10, 2017 at 06:57:43PM +0300, Alexey Budankov wrote: > >> The key thing in the patch is explicit updating of tstamp fields for > >> INACTIVE events in update_event_times().

[RFC][PATCH] perf: Rewrite enabled/running timekeeping

On Wed, Aug 23, 2017 at 11:54:15AM +0300, Alexey Budankov wrote: > On 22.08.2017 23:47, Peter Zijlstra wrote: > > On Thu, Aug 10, 2017 at 06:57:43PM +0300, Alexey Budankov wrote: > >> The key thing in the patch is explicit updating of tstamp fields for > >> INACTIVE events in update_event_times().

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/3] three bfq fixes restoring service guarantees with random sync writes in bg

> Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith ha > scritto: > > On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote: >> On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote: >>> [SECOND TAKE, with just the name of one of the tester fixed] >>> >>> Hi, >>>

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/3] three bfq fixes restoring service guarantees with random sync writes in bg

> Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith ha > scritto: > > On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote: >> On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote: >>> [SECOND TAKE, with just the name of one of the tester fixed] >>> >>> Hi, >>> while testing the

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

On Wed, Aug 30, 2017 at 08:47:19PM -0400, Jerome Glisse wrote: > On Wed, Aug 30, 2017 at 04:25:54PM -0700, Nadav Amit wrote: > > For both CoW and KSM, the correctness is maintained by calling > > ptep_clear_flush_notify(). If you defer the secondary MMU invalidation > > (i.e., replacing

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

On Wed, Aug 30, 2017 at 08:47:19PM -0400, Jerome Glisse wrote: > On Wed, Aug 30, 2017 at 04:25:54PM -0700, Nadav Amit wrote: > > For both CoW and KSM, the correctness is maintained by calling > > ptep_clear_flush_notify(). If you defer the secondary MMU invalidation > > (i.e., replacing

[PATCH RESEND v3 0/2] tpm_tis_spi: Use DMA-safe memory

The documentation says that DMA-safe memory is required for SPI transfers. The I/O buffers passed in by the caller can be allocated anywhere, including on the stack, which is not DMA-safe. So the data needs to be copied to separate, DMA-safe buffers. We did not see any DMA-related issues on our

[PATCH RESEND v3 0/2] tpm_tis_spi: Use DMA-safe memory

The documentation says that DMA-safe memory is required for SPI transfers. The I/O buffers passed in by the caller can be allocated anywhere, including on the stack, which is not DMA-safe. So the data needs to be copied to separate, DMA-safe buffers. We did not see any DMA-related issues on our

[PATCH RESEND v3 1/2] tpm_tis_spi: Use DMA-safe memory for SPI transfers

The buffers used as tx_buf/rx_buf in a SPI transfer need to be DMA-safe. This cannot be guaranteed for the buffers passed to tpm_tis_spi_read_bytes and tpm_tis_spi_write_bytes. Therefore, we need to use our own DMA-safe buffer and copy the data to/from it. The buffer needs to be allocated

[PATCH RESEND v3 1/2] tpm_tis_spi: Use DMA-safe memory for SPI transfers

The buffers used as tx_buf/rx_buf in a SPI transfer need to be DMA-safe. This cannot be guaranteed for the buffers passed to tpm_tis_spi_read_bytes and tpm_tis_spi_write_bytes. Therefore, we need to use our own DMA-safe buffer and copy the data to/from it. The buffer needs to be allocated

[PATCH RESEND v3 2/2] tpm_tis_spi: Use a single buffer for SPI transfers

A single buffer is sufficient for both tx and rx, since bytes that have already been sent are not used anymore and can safely be overwritten with the received bytes. Signed-off-by: Alexander Steffen Reviewed-by: Jarkko Sakkinen

[PATCH RESEND v3 2/2] tpm_tis_spi: Use a single buffer for SPI transfers

A single buffer is sufficient for both tx and rx, since bytes that have already been sent are not used anymore and can safely be overwritten with the received bytes. Signed-off-by: Alexander Steffen Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm_tis_spi.c | 34

[PATCH][next] net/mlx4_core: fix incorrect size allocation for dev->caps.spec_qps

From: Colin Ian King The current allocation for dev->caps.spec_qps is for the size of the pointer and not the size of the actual mlx4_spec_qps structure. Fix this by using the correct size. Also splint allocation over a few lines to make it cppcheck clean on overly

[PATCH][next] net/mlx4_core: fix incorrect size allocation for dev->caps.spec_qps

From: Colin Ian King The current allocation for dev->caps.spec_qps is for the size of the pointer and not the size of the actual mlx4_spec_qps structure. Fix this by using the correct size. Also splint allocation over a few lines to make it cppcheck clean on overly wide lines. Detected by

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/3] three bfq fixes restoring service guarantees with random sync writes in bg

On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote: > On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote: > > [SECOND TAKE, with just the name of one of the tester fixed] > > > > Hi, > > while testing the read-write unfairness issues reported by Mel, I > > found BFQ failing to

Re: [PATCH BUGFIX/IMPROVEMENT V2 0/3] three bfq fixes restoring service guarantees with random sync writes in bg

On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote: > On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote: > > [SECOND TAKE, with just the name of one of the tester fixed] > > > > Hi, > > while testing the read-write unfairness issues reported by Mel, I > > found BFQ failing to

Re: [PATCH kernel] PCI: Disable IOV before pcibios_sriov_disable()

On Wed, Aug 30, 2017 at 02:02:06PM -0500, Bjorn Helgaas wrote: > On Fri, Aug 11, 2017 at 06:19:33PM +1000, Alexey Kardashevskiy wrote: > > From: Gavin Shan > > > > The PowerNV platform is the only user of pcibios_sriov_disable(). > > The IOV BAR could be shifted by

Re: [PATCH kernel] PCI: Disable IOV before pcibios_sriov_disable()

On Wed, Aug 30, 2017 at 02:02:06PM -0500, Bjorn Helgaas wrote: > On Fri, Aug 11, 2017 at 06:19:33PM +1000, Alexey Kardashevskiy wrote: > > From: Gavin Shan > > > > The PowerNV platform is the only user of pcibios_sriov_disable(). > > The IOV BAR could be shifted by pci_iov_update_resource(). The

virtio_net: ethtool supported link modes

Hello, Looking at the code in virtnet_set_link_ksettings, it seems the speed and duplex can be set to any valid value. The driver will "remember" them and report them back in virtnet_get_link_ksettings. However, the supported link modes (link_modes.supported in struct ethtool_link_ksettings) is

virtio_net: ethtool supported link modes

Hello, Looking at the code in virtnet_set_link_ksettings, it seems the speed and duplex can be set to any valid value. The driver will "remember" them and report them back in virtnet_get_link_ksettings. However, the supported link modes (link_modes.supported in struct ethtool_link_ksettings) is

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Thu, Aug 31, 2017 at 6:58 AM, Mike Galbraith wrote: > On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote: >> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook wrote: >> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith wrote: >> >> On Wed,

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

On Thu, Aug 31, 2017 at 6:58 AM, Mike Galbraith wrote: > On Wed, 2017-08-30 at 21:10 -0700, Kees Cook wrote: >> On Wed, Aug 30, 2017 at 9:01 PM, Kees Cook wrote: >> > On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith wrote: >> >> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote: >> >> >> >>>

Re: [PATCH v2] membarrier: provide register sync core cmd

On Mon, Aug 28, 2017 at 03:05:46AM +, Mathieu Desnoyers wrote: > - On Aug 27, 2017, at 3:53 PM, Andy Lutomirski l...@amacapital.net wrote: > > >> On Aug 27, 2017, at 1:50 PM, Mathieu Desnoyers > >> > >> wrote: > >> > >> Add a new

Re: [PATCH v2] membarrier: provide register sync core cmd

On Mon, Aug 28, 2017 at 03:05:46AM +, Mathieu Desnoyers wrote: > - On Aug 27, 2017, at 3:53 PM, Andy Lutomirski l...@amacapital.net wrote: > > >> On Aug 27, 2017, at 1:50 PM, Mathieu Desnoyers > >> > >> wrote: > >> > >> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the

Re: [PATCH 4.9 00/12] 4.9.47-stable review

On Thu, Aug 31, 2017 at 10:15:15PM +0530, Sumit Semwal wrote: > Hi Greg, > > On 31 August 2017 at 21:14, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.47 release. > > There are 12 patches in this series, all will be posted as

Re: [PATCH 4.9 00/12] 4.9.47-stable review

On Thu, Aug 31, 2017 at 10:15:15PM +0530, Sumit Semwal wrote: > Hi Greg, > > On 31 August 2017 at 21:14, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.47 release. > > There are 12 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH v6 0/3] PCI hotplug feature

On Thu, Aug 31, 2017 at 7:09 PM, Bjorn Helgaas wrote: > On Thu, Aug 31, 2017 at 10:20:26AM +0530, Oza Pawandeep wrote: >> These patches bring in PCI hotplug support for iproc family chipsets. >> >> It includes DT binding documentation and, the implementation in >> iproc pcie

Re: [PATCH v6 0/3] PCI hotplug feature

On Thu, Aug 31, 2017 at 7:09 PM, Bjorn Helgaas wrote: > On Thu, Aug 31, 2017 at 10:20:26AM +0530, Oza Pawandeep wrote: >> These patches bring in PCI hotplug support for iproc family chipsets. >> >> It includes DT binding documentation and, the implementation in >> iproc pcie RC driver. >> >>

Re: [PATCH] driver core: bus: Fix a potential double free

On Tue, Aug 29, 2017 at 09:23:49PM +0200, Christophe JAILLET wrote: > The .release function of driver_ktype is 'driver_release()'. > This function frees the container_of this kobject. > > So, this memory must not be freed explicitly in the error handling path of > 'bus_add_driver()'. Otherwise a

Re: [PATCH] driver core: bus: Fix a potential double free

On Tue, Aug 29, 2017 at 09:23:49PM +0200, Christophe JAILLET wrote: > The .release function of driver_ktype is 'driver_release()'. > This function frees the container_of this kobject. > > So, this memory must not be freed explicitly in the error handling path of > 'bus_add_driver()'. Otherwise a

[PATCH] drivers: staging: Add driver for Amplicon PCIe215

This is a small and simple driver for handling of external interrupt signal asserted on pins of Amplicon's PCIe215 board. There is already a Comedi driver subsystem in kernel which handles that (and more) board, but that framework while offering more flexibility brings also additional complexity

[PATCH] drivers: staging: Add driver for Amplicon PCIe215

This is a small and simple driver for handling of external interrupt signal asserted on pins of Amplicon's PCIe215 board. There is already a Comedi driver subsystem in kernel which handles that (and more) board, but that framework while offering more flexibility brings also additional complexity

Re: [PATCH] kernfs: checking for IS_ERR() instead of NULL

On Wed, Aug 30, 2017 at 05:04:56PM +0300, Dan Carpenter wrote: > The kernfs_get_inode() returns NULL on error, it never returns error > pointers. > > Fixes: aa8188253474 ("kernfs: add exportfs operations") > Signed-off-by: Dan Carpenter > Acked-by: Tejun Heo

Re: [PATCH] kernfs: checking for IS_ERR() instead of NULL

On Wed, Aug 30, 2017 at 05:04:56PM +0300, Dan Carpenter wrote: > The kernfs_get_inode() returns NULL on error, it never returns error > pointers. > > Fixes: aa8188253474 ("kernfs: add exportfs operations") > Signed-off-by: Dan Carpenter > Acked-by: Tejun Heo Hm, I don't know what tree

Re: [PATCH v4 3/5] ghes_edac: add platform check to enable ghes_edac

On Thu, Aug 31, 2017 at 04:17:07PM +, Kani, Toshimitsu wrote: > I followed in the footsteps of 'ghes_disable', which is also a kernel > boot option and uses 0. Ok, ghes_disable comment says that using module_param() is easier. ghes_edac is not a module but then __setup() is for "really core

Re: [PATCH v4 3/5] ghes_edac: add platform check to enable ghes_edac

On Thu, Aug 31, 2017 at 04:17:07PM +, Kani, Toshimitsu wrote: > I followed in the footsteps of 'ghes_disable', which is also a kernel > boot option and uses 0. Ok, ghes_disable comment says that using module_param() is easier. ghes_edac is not a module but then __setup() is for "really core

Re: [PATCH linux v6 0/3] Export 1-wire thermal sensors as hwmon device

On Wed, Aug 30, 2017 at 04:34:32PM -0700, Jaghathiswari Rankappagounder Natarajan wrote: > Hi Greg, > Please pull in this patchset into the tree. Thanks! Thanks for the reworks, all now queued up. greg k-h

Re: [PATCH linux v6 0/3] Export 1-wire thermal sensors as hwmon device

On Wed, Aug 30, 2017 at 04:34:32PM -0700, Jaghathiswari Rankappagounder Natarajan wrote: > Hi Greg, > Please pull in this patchset into the tree. Thanks! Thanks for the reworks, all now queued up. greg k-h

Re: [PATCH] staging: gdm724x: Rename variable for consistency

jonathan...@gctsemi.com, linux-kernel@vger.kernel.org Bcc: Subject: Re: [PATCH v2] staging : gdm724x: Rename variable for consistency Reply-To: In-Reply-To: <20170831162747.ga31...@kroah.com> Sorry for the confusion. This patch is a revision to an earlier patch I submitted that did not compile.

Re: [PATCH] staging: gdm724x: Rename variable for consistency

jonathan...@gctsemi.com, linux-kernel@vger.kernel.org Bcc: Subject: Re: [PATCH v2] staging : gdm724x: Rename variable for consistency Reply-To: In-Reply-To: <20170831162747.ga31...@kroah.com> Sorry for the confusion. This patch is a revision to an earlier patch I submitted that did not compile.

Re: [PATCH 4.9 00/12] 4.9.47-stable review

Hi Greg, On 31 August 2017 at 21:14, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.47 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being

Re: [PATCH 4.9 00/12] 4.9.47-stable review

Hi Greg, On 31 August 2017 at 21:14, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.47 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. >

Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor

On Mon, Aug 28, 2017 at 09:31:30AM -0700, Andrey Smirnov wrote: > +static int rave_sp_debugfs_create(struct rave_sp *sp) > +{ > + struct dentry *file; > + > + sp->debugfs = debugfs_create_dir("rave", NULL); > + if (!sp->debugfs) > + return -ENOMEM; Why do you care about

Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor

On Mon, Aug 28, 2017 at 09:31:30AM -0700, Andrey Smirnov wrote: > +static int rave_sp_debugfs_create(struct rave_sp *sp) > +{ > + struct dentry *file; > + > + sp->debugfs = debugfs_create_dir("rave", NULL); > + if (!sp->debugfs) > + return -ENOMEM; Why do you care about

Re: [PATCH V6] perf: Add PERF_SAMPLE_PHYS_ADDR

Em Wed, Aug 23, 2017 at 10:00:37AM -0700, Stephane Eranian escreveu: > On Wed, Aug 23, 2017 at 7:39 AM, Peter Zijlstra wrote: > > On Wed, Aug 23, 2017 at 04:33:08PM +0200, Peter Zijlstra wrote: > >> > @@ -6145,6 +6183,9 @@ void perf_prepare_sample(struct perf_event_header >

Re: [PATCH V6] perf: Add PERF_SAMPLE_PHYS_ADDR

Em Wed, Aug 23, 2017 at 10:00:37AM -0700, Stephane Eranian escreveu: > On Wed, Aug 23, 2017 at 7:39 AM, Peter Zijlstra wrote: > > On Wed, Aug 23, 2017 at 04:33:08PM +0200, Peter Zijlstra wrote: > >> > @@ -6145,6 +6183,9 @@ void perf_prepare_sample(struct perf_event_header > >> > *header, > >> >

[PATCH][next] phy: mvebu-cp110-comphy: fix -ve error return against a u32

From: Colin Ian King The check to see if the call to mvebu_comphy_get_mux failed is always false because mux is a u32 and can never be less than zero. Fix this by making mux an int and casting to u32 on shift later on. Detected by CoverityScan, CID#1455220 ("Unsigned

[PATCH][next] phy: mvebu-cp110-comphy: fix -ve error return against a u32

From: Colin Ian King The check to see if the call to mvebu_comphy_get_mux failed is always false because mux is a u32 and can never be less than zero. Fix this by making mux an int and casting to u32 on shift later on. Detected by CoverityScan, CID#1455220 ("Unsigned compared against 0")

Re: [PATCH V8] perf: Add PERF_SAMPLE_PHYS_ADDR

Em Tue, Aug 29, 2017 at 01:45:53PM +0200, Peter Zijlstra escreveu: > On Tue, Aug 29, 2017 at 05:05:15PM +0530, Madhavan Srinivasan wrote: > > > > > > On Tuesday 29 August 2017 06:22 AM, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > > > For understanding how the

Re: [PATCH V8] perf: Add PERF_SAMPLE_PHYS_ADDR

Em Tue, Aug 29, 2017 at 01:45:53PM +0200, Peter Zijlstra escreveu: > On Tue, Aug 29, 2017 at 05:05:15PM +0530, Madhavan Srinivasan wrote: > > > > > > On Tuesday 29 August 2017 06:22 AM, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > > > For understanding how the workload maps to

Re: [PATCH 4.9 01/12] p54: memset(0) whole array

On Thu, 2017-08-31 at 17:44 +0200, Greg Kroah-Hartman wrote: > 4.9-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Jiri Slaby > > commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream. > > gcc 7 complains: >

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

On 08/30/2017 06:09 PM, David Miller wrote: From: Khalid Aziz Date: Wed, 30 Aug 2017 17:23:37 -0600 That is an interesting idea. This would enable TSTATE_MCDE on all threads of a process as soon as one thread enables it. If we consider the case where the parent creates

Re: [PATCH 4.9 01/12] p54: memset(0) whole array

On Thu, 2017-08-31 at 17:44 +0200, Greg Kroah-Hartman wrote: > 4.9-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Jiri Slaby > > commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream. > > gcc 7 complains: >

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

On 08/30/2017 06:09 PM, David Miller wrote: From: Khalid Aziz Date: Wed, 30 Aug 2017 17:23:37 -0600 That is an interesting idea. This would enable TSTATE_MCDE on all threads of a process as soon as one thread enables it. If we consider the case where the parent creates a shared memory area

<    3   4   5   6   7   8   9   10   11   12   >