[PATCH 3/5] e1000e: Fix return value test

All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c

[PATCH 3/5] e1000e: Fix return value test

All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index

[PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun. This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status

[PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts

When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun. This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status

Re: [PATCH V2 2/3] iommu/rockchip: add multi irqs support

Am Freitag, 21. Juli 2017, 15:54:40 CEST schrieb xxm: > Hi Heiko, > > > On 07/21/2017 03:07 PM, Heiko Stuebner wrote: > > Am Freitag, 21. Juli 2017, 14:27:09 CEST schrieb Simon Xue: > >> From: Simon > >> > >> RK3368 vpu mmu have two irqs, this patch support multi irqs > >>

[PATCH 2/5] e1000e: Fix wrong comment related to link detection

Reading e1000e_check_for_copper_link() shows that get_link_status is set to false after link has been detected. Therefore, it stays TRUE until then. Signed-off-by: Benjamin Poirier --- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH 2/5] e1000e: Fix wrong comment related to link detection

Reading e1000e_check_for_copper_link() shows that get_link_status is set to false after link has been detected. Therefore, it stays TRUE until then. Signed-off-by: Benjamin Poirier --- drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

Re: [PATCH V2 2/3] iommu/rockchip: add multi irqs support

Am Freitag, 21. Juli 2017, 15:54:40 CEST schrieb xxm: > Hi Heiko, > > > On 07/21/2017 03:07 PM, Heiko Stuebner wrote: > > Am Freitag, 21. Juli 2017, 14:27:09 CEST schrieb Simon Xue: > >> From: Simon > >> > >> RK3368 vpu mmu have two irqs, this patch support multi irqs > >> > >> Signed-off-by:

[PATCH 4/5] e1000e: Separate signaling for link check/link up

Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */

[PATCH 4/5] e1000e: Separate signaling for link check/link up

Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */

[PATCH 1/5] e1000e: Fix error path in link detection

In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier --- drivers/net/ethernet/intel/e1000e/phy.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[PATCH 1/5] e1000e: Fix error path in link detection

In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier --- drivers/net/ethernet/intel/e1000e/phy.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[PATCH net-next 1/2] rxrpc: Expose UAPI definitions to userspace

Move UAPI definitions from the internal header and place them in a UAPI header file so that userspace can make use of them. Signed-off-by: David Howells --- include/linux/rxrpc.h | 79 --- include/uapi/linux/rxrpc.h | 80

[PATCH net-next 2/2] rxrpc: Move the packet.h include file into net/rxrpc/

Move the protocol description header file into net/rxrpc/ and rename it to protocol.h. It's no longer necessary to expose it as packets are no longer exposed to kernel services (such as AFS) that use the facility. The abort codes are transferred to the UAPI header instead as we pass these back

[PATCH net-next 1/2] rxrpc: Expose UAPI definitions to userspace

Move UAPI definitions from the internal header and place them in a UAPI header file so that userspace can make use of them. Signed-off-by: David Howells --- include/linux/rxrpc.h | 79 --- include/uapi/linux/rxrpc.h | 80

[PATCH net-next 2/2] rxrpc: Move the packet.h include file into net/rxrpc/

Move the protocol description header file into net/rxrpc/ and rename it to protocol.h. It's no longer necessary to expose it as packets are no longer exposed to kernel services (such as AFS) that use the facility. The abort codes are transferred to the UAPI header instead as we pass these back

[PATCH net-next 0/2] rxrpc: Rearrange headers

-rewrite-20170721 David --- David Howells (2): rxrpc: Expose UAPI definitions to userspace rxrpc: Move the packet.h include file into net/rxrpc/ fs/afs/misc.c |1 fs/afs/rxrpc.c |1 include/linux/rxrpc.h | 79 --- include/rxrpc

[PATCH net-next 0/2] rxrpc: Rearrange headers

-rewrite-20170721 David --- David Howells (2): rxrpc: Expose UAPI definitions to userspace rxrpc: Move the packet.h include file into net/rxrpc/ fs/afs/misc.c |1 fs/afs/rxrpc.c |1 include/linux/rxrpc.h | 79 --- include/rxrpc

[PATCH v6 0/1] acpi: apei: Bug fix to enable APEI support for ARMv8

v6: * Update the patch description v5: * Remove the patch set 1/2 as it was accepted * Fix the signed-off-by using Co-authored-by v4: * Update patch commit log for gsi.c patch * Make change to be 80 column aligned v3 * Change the title of the patch to reflect the patch * Completely dropped the

[PATCH v6 0/1] acpi: apei: Bug fix to enable APEI support for ARMv8

v6: * Update the patch description v5: * Remove the patch set 1/2 as it was accepted * Fix the signed-off-by using Co-authored-by v4: * Update patch commit log for gsi.c patch * Make change to be 80 column aligned v3 * Change the title of the patch to reflect the patch * Completely dropped the

[PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ

X-Gene platforms describe multiple GHES error sources with the same hardware error notification type (external interrupt) and interrupt number. Change the GHES interrupt request to support sharing the same IRQ. Co-authored-by: Tuan Phan Signed-off-by: Loc Ho ---

[PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ

X-Gene platforms describe multiple GHES error sources with the same hardware error notification type (external interrupt) and interrupt number. Change the GHES interrupt request to support sharing the same IRQ. Co-authored-by: Tuan Phan Signed-off-by: Loc Ho --- drivers/acpi/apei/ghes.c | 3

Re: [PATCH] xen/pvcalls: use WARN_ON(1) instead of __WARN()

On 07/21/2017 12:17 PM, Arnd Bergmann wrote: > __WARN() is an internal helper that is only available on > some architectures, but causes a build error e.g. on ARM64 > in some configurations: > > drivers/xen/pvcalls-back.c: In function 'set_backend_state': > drivers/xen/pvcalls-back.c:1097:5:

Re: [PATCH] xen/pvcalls: use WARN_ON(1) instead of __WARN()

On 07/21/2017 12:17 PM, Arnd Bergmann wrote: > __WARN() is an internal helper that is only available on > some architectures, but causes a build error e.g. on ARM64 > in some configurations: > > drivers/xen/pvcalls-back.c: In function 'set_backend_state': > drivers/xen/pvcalls-back.c:1097:5:

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Thu, Jul 20, 2017 at 09:59:22AM -0600, Ross Zwisler wrote: > On Thu, Jul 20, 2017 at 11:26:16AM -0400, Vivek Goyal wrote: <> > > Hi Ross, > > > > vm_insert_mixed_mkwrite() is same as vm_insert_mixed() except this sets > > write parameter to inser_pfn() true. Will it make sense to just add > >

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Thu, Jul 20, 2017 at 09:59:22AM -0600, Ross Zwisler wrote: > On Thu, Jul 20, 2017 at 11:26:16AM -0400, Vivek Goyal wrote: <> > > Hi Ross, > > > > vm_insert_mixed_mkwrite() is same as vm_insert_mixed() except this sets > > write parameter to inser_pfn() true. Will it make sense to just add > >

Re: [PATCH 0/3] livepatch: introduce atomic replace

On 07/21/2017 09:06 AM, Miroslav Benes wrote: On Wed, 19 Jul 2017, Jason Baron wrote: Hi, In testing livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion

Re: [PATCH 0/3] livepatch: introduce atomic replace

On 07/21/2017 09:06 AM, Miroslav Benes wrote: On Wed, 19 Jul 2017, Jason Baron wrote: Hi, In testing livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion

[PATCH] Documentation: add some docs for errseq_t

From: Jeff Layton ...and fix up a few comments in the code. Signed-off-by: Jeff Layton --- Documentation/errseq.rst | 149 +++ include/linux/errseq.h | 5 +- include/linux/fs.h | 2 - 3 files

[PATCH] Documentation: add some docs for errseq_t

From: Jeff Layton ...and fix up a few comments in the code. Signed-off-by: Jeff Layton --- Documentation/errseq.rst | 149 +++ include/linux/errseq.h | 5 +- include/linux/fs.h | 2 - 3 files changed, 152 insertions(+), 4 deletions(-)

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed, Jul 19, 2017 at 03:58:31PM -0600, Ross Zwisler wrote: > On Wed, Jul 19, 2017 at 11:51:12AM -0600, Ross Zwisler wrote: > > On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote: > > > On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > > > > To be able to use the common 4k zero page in DAX

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed, Jul 19, 2017 at 03:58:31PM -0600, Ross Zwisler wrote: > On Wed, Jul 19, 2017 at 11:51:12AM -0600, Ross Zwisler wrote: > > On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote: > > > On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > > > > To be able to use the common 4k zero page in DAX

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Fri, Jul 21, 2017 at 8:40 AM, Paul Moore wrote: > On Thu, Jul 20, 2017 at 4:42 PM, Paul Moore wrote: >> On Thu, Jul 20, 2017 at 1:06 PM, Kees Cook wrote: >>> On Thu, Jul 20, 2017 at 6:42 AM, Paul Moore

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Fri, Jul 21, 2017 at 8:40 AM, Paul Moore wrote: > On Thu, Jul 20, 2017 at 4:42 PM, Paul Moore wrote: >> On Thu, Jul 20, 2017 at 1:06 PM, Kees Cook wrote: >>> On Thu, Jul 20, 2017 at 6:42 AM, Paul Moore wrote: Alternatively, if you've got a fairly recent git repo with all the

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

* Baoquan He wrote: > > > +static inline bool process_efi_entries(unsigned long minimum, > > > +unsigned long image_size) > > > > ugly linebreak again ... > > The whole line is more than 80. I break the line and use tab and space > to make it

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

* Baoquan He wrote: > > > +static inline bool process_efi_entries(unsigned long minimum, > > > +unsigned long image_size) > > > > ugly linebreak again ... > > The whole line is more than 80. I break the line and use tab and space > to make it align with above

[GIT PULL] KVM fixes for v4.13-rc2

Linus, The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus for you to fetch changes up to

[GIT PULL] KVM fixes for v4.13-rc2

Linus, The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus for you to fetch changes up to

Re: [PATCH] docs: submitting-patches - change non-ascii character to ascii

On Thu, 20 Jul 2017 18:30:55 -0700 frowand.l...@gmail.com wrote: > Documentation/process/submitting-patches.rst contains a non-ascii > character. Change it to the ascii equivalent. You should know better than to tell somebody like me that a hyphen and an m-dash are equivalent! :) I don't have

Re: [PATCH] docs: submitting-patches - change non-ascii character to ascii

On Thu, 20 Jul 2017 18:30:55 -0700 frowand.l...@gmail.com wrote: > Documentation/process/submitting-patches.rst contains a non-ascii > character. Change it to the ascii equivalent. You should know better than to tell somebody like me that a hyphen and an m-dash are equivalent! :) I don't have

Re: [PATCH 01/11] arm64: docs: describe ELF hwcaps

On Wed, Jul 19, 2017 at 05:01:22PM +0100, Mark Rutland wrote: > We don't document our ELF hwcaps, leaving developers to interpret them > according to hearsay, guesswork, or (in exceptional cases) inspection of > the current kernel code. > > This is less than optimal, and it would be far better if

Re: [PATCH 01/11] arm64: docs: describe ELF hwcaps

On Wed, Jul 19, 2017 at 05:01:22PM +0100, Mark Rutland wrote: > We don't document our ELF hwcaps, leaving developers to interpret them > according to hearsay, guesswork, or (in exceptional cases) inspection of > the current kernel code. > > This is less than optimal, and it would be far better if

Re: [PATCH v1 4/6] phy: qcom-qusb2: Add support for runtime PM

On 07/21/2017 04:01 AM, Manu Gautam wrote: > Driver can turn off clocks during runtime suspend. > Also, runtime suspend is not as a result of host mode > selective suspend then PHY can be powered off as well. > > Signed-off-by: Manu Gautam > > diff --git

Re: [PATCH v1 4/6] phy: qcom-qusb2: Add support for runtime PM

On 07/21/2017 04:01 AM, Manu Gautam wrote: > Driver can turn off clocks during runtime suspend. > Also, runtime suspend is not as a result of host mode > selective suspend then PHY can be powered off as well. > > Signed-off-by: Manu Gautam > > diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c >

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

On Fri, Jul 21, 2017 at 02:01:31PM -0300, Mauro Carvalho Chehab wrote: > I see the value of having a threshold in BIOS, provided that it is > well documented, and whose value can be adjusted, if needed. > > One of the things I wanted to implement in ras-daemon were an > algorithm that would be

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

On Fri, Jul 21, 2017 at 02:01:31PM -0300, Mauro Carvalho Chehab wrote: > I see the value of having a threshold in BIOS, provided that it is > well documented, and whose value can be adjusted, if needed. > > One of the things I wanted to implement in ras-daemon were an > algorithm that would be

[PATCH 02/16] arm64: Add decoding macros for CP15_32 and CP15_64 traps

So far, we don't have anything to help decoding ESR_ELx when dealing with ESR_ELx_EC_CP15_{32,64}. As we're about to handle some of those, let's add some useful macros. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/esr.h | 52

[PATCH 02/16] arm64: Add decoding macros for CP15_32 and CP15_64 traps

So far, we don't have anything to help decoding ESR_ELx when dealing with ESR_ELx_EC_CP15_{32,64}. As we're about to handle some of those, let's add some useful macros. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/esr.h | 52 1 file

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

On Fri, 2017-07-21 at 14:01 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 16:40:20 + > "Kani, Toshimitsu" escreveu: > > > On Fri, 2017-07-21 at 12:44 -0300, Mauro Carvalho Chehab wrote: > > > Em Fri, 21 Jul 2017 15:34:50 + > > > "Kani, Toshimitsu"

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

On Fri, 2017-07-21 at 14:01 -0300, Mauro Carvalho Chehab wrote: > Em Fri, 21 Jul 2017 16:40:20 + > "Kani, Toshimitsu" escreveu: > > > On Fri, 2017-07-21 at 12:44 -0300, Mauro Carvalho Chehab wrote: > > > Em Fri, 21 Jul 2017 15:34:50 + > > > "Kani, Toshimitsu" escreveu: > > >    > > > >

Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver

On Fri, Jul 21, 2017 at 10:32:49AM +, Pierre Yves MORDRET wrote: > +static int stm32_mdma_set_xfer_param(struct stm32_mdma_chan *chan, > + enum dma_transfer_direction > direction, > + u32 *mdma_ccr,

Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver

On Fri, Jul 21, 2017 at 10:32:49AM +, Pierre Yves MORDRET wrote: > +static int stm32_mdma_set_xfer_param(struct stm32_mdma_chan *chan, > + enum dma_transfer_direction > direction, > + u32 *mdma_ccr,

[PATCH 01/16] arm64: Use arch_timer_get_rate when trapping CNTFRQ_EL0

In an ideal world, CNTFRQ_EL0 always contains the timer frequency for the kernel to use. Sadly, we get quite a few broken systems where the firmware authors cannot be bothered to program that register on all CPUs, and rely on DT to provide that frequency. So when trapping CNTFRQ_EL0, make sure to

[PATCH 01/16] arm64: Use arch_timer_get_rate when trapping CNTFRQ_EL0

In an ideal world, CNTFRQ_EL0 always contains the timer frequency for the kernel to use. Sadly, we get quite a few broken systems where the firmware authors cannot be bothered to program that register on all CPUs, and rely on DT to provide that frequency. So when trapping CNTFRQ_EL0, make sure to

[PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ

It is an unfortunate situation that CNTFRQ{,_EL0} is often misprogrammed from the firmware side, leaving it up to the kernel to work around it. This is usually done by providing an alternative frequency in the Device Tree. Unfortunately, CNTFRQ is accessible from EL0, giving userspace the wrong

[PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ

It is an unfortunate situation that CNTFRQ{,_EL0} is often misprogrammed from the firmware side, leaving it up to the kernel to work around it. This is usually done by providing an alternative frequency in the Device Tree. Unfortunately, CNTFRQ is accessible from EL0, giving userspace the wrong

[PATCH 05/16] arm64: compat: Add cp15_32 and cp15_64 handler arrays

We're now ready to start handling CP15 access. Let's add (empty) arrays for both 32 and 64bit accessors, and the code that deals with them. Signed-off-by: Marc Zyngier --- arch/arm64/kernel/traps.c | 29 + 1 file changed, 29 insertions(+) diff

[PATCH 05/16] arm64: compat: Add cp15_32 and cp15_64 handler arrays

We're now ready to start handling CP15 access. Let's add (empty) arrays for both 32 and 64bit accessors, and the code that deals with them. Signed-off-by: Marc Zyngier --- arch/arm64/kernel/traps.c | 29 + 1 file changed, 29 insertions(+) diff --git

[PATCH 04/16] arm64: compat: Add condition code checks and IT advance

Here's a /really nice/ part of the architecture: a CP15 access is allowed to trap even if it fails its condition check, and SW must handle it. This includes decoding the IT state if this happens in am IT block. As a consequence, SW must also deal with advancing the IT state machine.

[PATCH 04/16] arm64: compat: Add condition code checks and IT advance

Here's a /really nice/ part of the architecture: a CP15 access is allowed to trap even if it fails its condition check, and SW must handle it. This includes decoding the IT state if this happens in am IT block. As a consequence, SW must also deal with advancing the IT state machine.

[PATCH 02/16] arm64: Add decoding macros for CP15_32 and CP15_64 traps

So far, we don't have anything to help decoding ESR_ELx when dealing with ESR_ELx_EC_CP15_{32,64}. As we're about to handle some of those, let's add some useful macros. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/esr.h | 52

[PATCH 03/16] arm64: compat: Add separate CP15 trapping hook

Instead of directly generating an UNDEF when trapping a CP15 access, let's add a new entry point to that effect (which only generates an UNDEF for now). Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- arch/arm64/kernel/entry.S | 14

[PATCH 02/16] arm64: Add decoding macros for CP15_32 and CP15_64 traps

So far, we don't have anything to help decoding ESR_ELx when dealing with ESR_ELx_EC_CP15_{32,64}. As we're about to handle some of those, let's add some useful macros. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/esr.h | 52 1 file

[PATCH 03/16] arm64: compat: Add separate CP15 trapping hook

Instead of directly generating an UNDEF when trapping a CP15 access, let's add a new entry point to that effect (which only generates an UNDEF for now). Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- arch/arm64/kernel/entry.S | 14 -- arch/arm64/kernel/traps.c | 13

[PATCH 01/16] arm64: Use arch_timer_get_rate when trapping CNTFRQ_EL0

In an ideal world, CNTFRQ_EL0 always contains the timer frequency for the kernel to use. Sadly, we get quite a few broken systems where the firmware authors cannot be bothered to program that register on all CPUs, and rely on DT to provide that frequency. So when trapping CNTFRQ_EL0, make sure to

[PATCH 01/16] arm64: Use arch_timer_get_rate when trapping CNTFRQ_EL0

In an ideal world, CNTFRQ_EL0 always contains the timer frequency for the kernel to use. Sadly, we get quite a few broken systems where the firmware authors cannot be bothered to program that register on all CPUs, and rely on DT to provide that frequency. So when trapping CNTFRQ_EL0, make sure to

[PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ

It is an unfortunate situation that CNTFRQ{,_EL0} is often misprogrammed from the firmware side, leaving it up to the kernel to work around it. This is usually done by providing an alternative frequency in the Device Tree. Unfortunately, CNTFRQ is accessible from EL0, giving userspace the wrong

[PATCH 00/16] arm/arm64: Workaround misprogrammed CNTFRQ

It is an unfortunate situation that CNTFRQ{,_EL0} is often misprogrammed from the firmware side, leaving it up to the kernel to work around it. This is usually done by providing an alternative frequency in the Device Tree. Unfortunately, CNTFRQ is accessible from EL0, giving userspace the wrong

[PATCH 13/16] ARM: Handle trapping of CNTVCT from userspace

As we're about to enable trapping of some of the userspace-visible timer registers, let's add a handler for CNTVCT. Signed-off-by: Marc Zyngier --- arch/arm/kernel/traps.c | 29 + 1 file changed, 29 insertions(+) diff --git

[PATCH 12/16] ARM: Simplify condition checks in swp_handler

We now check the validity of the condition code before calling the UNDEF handlers, so we can simplify swp_handler by only checking for ARM_OPCODE_CONDTEST_UNCOND, which indicates that this is not a SWP instruction. Signed-off-by: Marc Zyngier ---

[PATCH 13/16] ARM: Handle trapping of CNTVCT from userspace

As we're about to enable trapping of some of the userspace-visible timer registers, let's add a handler for CNTVCT. Signed-off-by: Marc Zyngier --- arch/arm/kernel/traps.c | 29 + 1 file changed, 29 insertions(+) diff --git a/arch/arm/kernel/traps.c

[PATCH 12/16] ARM: Simplify condition checks in swp_handler

We now check the validity of the condition code before calling the UNDEF handlers, so we can simplify swp_handler by only checking for ARM_OPCODE_CONDTEST_UNCOND, which indicates that this is not a SWP instruction. Signed-off-by: Marc Zyngier --- arch/arm/kernel/swp_emulate.c | 15

[PATCH 14/16] ARM: Handle trapping of CNTFRQ from userspace

As we're about to enable trapping of some of the userspace-visible timer registers, let's add a handler for CNTFRQ. Signed-off-by: Marc Zyngier --- arch/arm/kernel/traps.c | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/kernel/traps.c

[PATCH 14/16] ARM: Handle trapping of CNTFRQ from userspace

As we're about to enable trapping of some of the userspace-visible timer registers, let's add a handler for CNTFRQ. Signed-off-by: Marc Zyngier --- arch/arm/kernel/traps.c | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c

[PATCH 16/16] clocksource/arm_arch_timer: Trap user access to CNT{VCT,FRQ} if CNTFRQ is invalid

If we end-up in a situation where any of the CPUs doesn't have its CNTFRQ register correctly programmed, we cannot reliably expose this register to userspace. It means that in this case, we have to trap it, and CNTVCT at the same time (since they are controlled by the same trapping bit). It also

[PATCH 16/16] clocksource/arm_arch_timer: Trap user access to CNT{VCT,FRQ} if CNTFRQ is invalid

If we end-up in a situation where any of the CPUs doesn't have its CNTFRQ register correctly programmed, we cannot reliably expose this register to userspace. It means that in this case, we have to trap it, and CNTVCT at the same time (since they are controlled by the same trapping bit). It also

[PATCH 11/16] ARM: Advance the IT state on successful emulation of an UNDEF

When trapping a conditional Thumb instruction, we need to advance the IT state accordingly, or we'll end-up corrupting the execution of a subsequent instruction. Let's add calls to arm_advance_itstate() in the relevant spots. Signed-off-by: Marc Zyngier ---

[PATCH 11/16] ARM: Advance the IT state on successful emulation of an UNDEF

When trapping a conditional Thumb instruction, we need to advance the IT state accordingly, or we'll end-up corrupting the execution of a subsequent instruction. Let's add calls to arm_advance_itstate() in the relevant spots. Signed-off-by: Marc Zyngier --- arch/arm/kernel/traps.c | 5 - 1

[PATCH 08/16] ARM: Let arm_check_condition work with Thumb

arm_check_condition indicates whether a trapped conditional instruction would have failed or passed its condition check. This works perfectly well for ARM code, but it ignores entirely the Thumb mode, where the condition code is not encoded in the intruction, but in the IT state contained in the

[PATCH 08/16] ARM: Let arm_check_condition work with Thumb

arm_check_condition indicates whether a trapped conditional instruction would have failed or passed its condition check. This works perfectly well for ARM code, but it ignores entirely the Thumb mode, where the condition code is not encoded in the intruction, but in the IT state contained in the

[PATCH 09/16] ARM: Check condition code before trying to handle an UNDEF

As indicated in the ARMv7 ARM in B1.9.2, an instruction that would cause an UNDEF can trap even if it fails its condition code. Yes, this is annoying. Add a arm_check_condition call before trying to handle an UNDEF, and move the PC by the right amount if the condition check fails. Signed-off-by:

[PATCH 09/16] ARM: Check condition code before trying to handle an UNDEF

As indicated in the ARMv7 ARM in B1.9.2, an instruction that would cause an UNDEF can trap even if it fails its condition code. Yes, this is annoying. Add a arm_check_condition call before trying to handle an UNDEF, and move the PC by the right amount if the condition check fails. Signed-off-by:

[PATCH 07/16] arm64: compat: Add CNTFRQ trap handler

Just like CNTVCT, we need to handle userspace trapping into the kernel if we're decided that the timer wasn't fit for purpose... 64bit userspace is already dealt with, but we're missing the equivalent compat handling. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier

[PATCH 06/16] arm64: compat: Add CNTVCT trap handler

Since people seem to make a point in breaking the userspace visible counter, we have no choice but to trap the access. We already do this for 64bit userspace, but this is lacking for compat. Let's provide the required handler. Acked-by: Mark Rutland Signed-off-by: Marc

[PATCH 07/16] arm64: compat: Add CNTFRQ trap handler

Just like CNTVCT, we need to handle userspace trapping into the kernel if we're decided that the timer wasn't fit for purpose... 64bit userspace is already dealt with, but we're missing the equivalent compat handling. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier ---

[PATCH 06/16] arm64: compat: Add CNTVCT trap handler

Since people seem to make a point in breaking the userspace visible counter, we have no choice but to trap the access. We already do this for 64bit userspace, but this is lacking for compat. Let's provide the required handler. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier ---

[PATCH 15/16] clocksource/arm_arch_timer: Add helper to disable VDSO fastpath

As we are going to add more paths where we have to disable the counter access in the VDSO, let's add a helper that does exactly that. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 28

[PATCH 15/16] clocksource/arm_arch_timer: Add helper to disable VDSO fastpath

As we are going to add more paths where we have to disable the counter access in the VDSO, let's add a helper that does exactly that. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 28 ++-- 1 file changed, 18 insertions(+),

[PATCH 10/16] ARM: Add arm_advance_itstate helper

In order to deal with conditional Thumb code, let's add a helper to advance the IT state when an instruction is either skipped or emulated. Signed-off-by: Marc Zyngier --- arch/arm/include/asm/opcodes.h | 2 ++ arch/arm/kernel/opcodes.c | 34

[PATCH 10/16] ARM: Add arm_advance_itstate helper

In order to deal with conditional Thumb code, let's add a helper to advance the IT state when an instruction is either skipped or emulated. Signed-off-by: Marc Zyngier --- arch/arm/include/asm/opcodes.h | 2 ++ arch/arm/kernel/opcodes.c | 34 ++ 2 files

Re: [PATCH 0/5] perf script python: Provide perf_sample dict to all handlers

Em Fri, Jul 21, 2017 at 09:51:31AM -0700, Arun Kalyanasundaram escreveu: > My apologies. Yes, I did make a couple of changes to the patch. I was > not sure if I should be sending a v2 since the previous one was a rfc. > Please ignore this patch, I will resend this highlighting the new > changes

Re: [PATCH 0/5] perf script python: Provide perf_sample dict to all handlers

Em Fri, Jul 21, 2017 at 09:51:31AM -0700, Arun Kalyanasundaram escreveu: > My apologies. Yes, I did make a couple of changes to the patch. I was > not sure if I should be sending a v2 since the previous one was a rfc. > Please ignore this patch, I will resend this highlighting the new > changes

Re: [PATCH v2 tip/perf/core 5/6] perf top: support lookup of symbols in other mount namespaces.

Em Wed, Jul 05, 2017 at 06:48:12PM -0700, Krister Johansen escreveu: > The perf top command needs to unshare its fs from the helper threads > in order to successfully setns(2) during its symbol lookup. It also > needs to impelement a force flag to ignore ownership of perf-.map > files. Thanks,

Re: [PATCH v2 tip/perf/core 5/6] perf top: support lookup of symbols in other mount namespaces.

Em Wed, Jul 05, 2017 at 06:48:12PM -0700, Krister Johansen escreveu: > The perf top command needs to unshare its fs from the helper threads > in order to successfully setns(2) during its symbol lookup. It also > needs to impelement a force flag to ignore ownership of perf-.map > files. Thanks,

Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Marcel, On 21/07/2017 18:52, Marcel Holtmann wrote: > Hi Quentin, > The Espressif ESP8089 WiFi chips can be often found in cheap tablets. There is one in A23 Polaroid tablets for example. The chip is often embedded as an eMMC SDIO device. The code was taken from

Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Marcel, On 21/07/2017 18:52, Marcel Holtmann wrote: > Hi Quentin, > The Espressif ESP8089 WiFi chips can be often found in cheap tablets. There is one in A23 Polaroid tablets for example. The chip is often embedded as an eMMC SDIO device. The code was taken from

Re: MAINTAINERS: F: file patterns without matches

On 07/21/2017 10:02 AM, Joe Perches wrote: > There are a number of file patterns in MAINTAINERS that > don't have an actual matching file in the kernel tree. > > Some of those are due to renames, some are typos, some > are added without a matching file being added at the > same time. > > There's

Re: MAINTAINERS: F: file patterns without matches

On 07/21/2017 10:02 AM, Joe Perches wrote: > There are a number of file patterns in MAINTAINERS that > don't have an actual matching file in the kernel tree. > > Some of those are due to renames, some are typos, some > are added without a matching file being added at the > same time. > > There's

Re: [PATCH v1 6/6] usb: dwc3: core: Notify USB3 PHY as well for DRD modes

On 07/21/2017 04:02 AM, Manu Gautam wrote: > Driver currently notifies only USB3 PHY for mode change. > Extend this to USB3 PHY so that driver based on the mode > can release system resources - clocks, regulators etc. > and can even turn off PHY during runtime suspend. > > Signed-off-by: Manu

Re: [PATCH v1 6/6] usb: dwc3: core: Notify USB3 PHY as well for DRD modes

On 07/21/2017 04:02 AM, Manu Gautam wrote: > Driver currently notifies only USB3 PHY for mode change. > Extend this to USB3 PHY so that driver based on the mode > can release system resources - clocks, regulators etc. > and can even turn off PHY during runtime suspend. > > Signed-off-by: Manu

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