Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 04/04/2017 03:13 PM, Radim Krčmář wrote: 2017-04-04 14:51+0200, Alexander Graf: On 04/04/2017 02:39 PM, Radim Krčmář wrote: 2017-04-03 12:04+0200, Alexander Graf: So coming back to the original patch, is there anything that should keep us from exposing MWAIT straight into the guest at all

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 04/04/2017 02:39 PM, Radim Krčmář wrote: 2017-04-03 12:04+0200, Alexander Graf: On 03/29/2017 02:11 PM, Radim Krčmář wrote: 2017-03-28 13:35-0700, Jim Mattson: On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář <rkrc...@redhat.com> wrote: 2017-03-27 15:34+0200, Alexander Graf: On 15/0

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 04/04/2017 02:39 PM, Radim Krčmář wrote: 2017-04-03 12:04+0200, Alexander Graf: On 03/29/2017 02:11 PM, Radim Krčmář wrote: 2017-03-28 13:35-0700, Jim Mattson: On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář wrote: 2017-03-27 15:34+0200, Alexander Graf: On 15/03/2017 22:22, Michael S

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 03/29/2017 02:11 PM, Radim Krčmář wrote: 2017-03-28 13:35-0700, Jim Mattson: On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář <rkrc...@redhat.com> wrote: 2017-03-27 15:34+0200, Alexander Graf: On 15/03/2017 22:22, Michael S. Tsirkin wrote: Guests running Mac OS 5, 6, and 7 (Leopard t

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 03/29/2017 02:11 PM, Radim Krčmář wrote: 2017-03-28 13:35-0700, Jim Mattson: On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář wrote: 2017-03-27 15:34+0200, Alexander Graf: On 15/03/2017 22:22, Michael S. Tsirkin wrote: Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 15/03/2017 22:22, Michael S. Tsirkin wrote: Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem: unless explicitly provided with kernel command line argument "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability, without checking CPUID. We currently

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

On 15/03/2017 22:22, Michael S. Tsirkin wrote: Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem: unless explicitly provided with kernel command line argument "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability, without checking CPUID. We currently

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 15/02/2017 12:35, zhichang.yuan wrote: Hi, Alex, On 2017/2/14 21:29, Alexander Graf wrote: On 13/02/2017 15:39, zhichang.yuan wrote: Hi, Alex, Thanks for your review! John had replied most of your comments, I only mentioned those which haven't made clear. On 2017/1/31 4:08

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 15/02/2017 12:35, zhichang.yuan wrote: Hi, Alex, On 2017/2/14 21:29, Alexander Graf wrote: On 13/02/2017 15:39, zhichang.yuan wrote: Hi, Alex, Thanks for your review! John had replied most of your comments, I only mentioned those which haven't made clear. On 2017/1/31 4:08

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 13/02/2017 15:39, zhichang.yuan wrote: Hi, Alex, Thanks for your review! John had replied most of your comments, I only mentioned those which haven't made clear. On 2017/1/31 4:08, Alexander Graf wrote: On 24/01/2017 08:05, zhichang.yuan wrote: The low-pin-count(LPC) interface

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 13/02/2017 15:39, zhichang.yuan wrote: Hi, Alex, Thanks for your review! John had replied most of your comments, I only mentioned those which haven't made clear. On 2017/1/31 4:08, Alexander Graf wrote: On 24/01/2017 08:05, zhichang.yuan wrote: The low-pin-count(LPC) interface

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 13/02/2017 15:17, zhichang.yuan wrote: Hi, Alex, On 2017/2/1 3:37, Alexander Graf wrote: On 31/01/2017 14:32, John Garry wrote: On 30/01/2017 17:12, Alexander Graf wrote: On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 13/02/2017 15:17, zhichang.yuan wrote: Hi, Alex, On 2017/2/1 3:37, Alexander Graf wrote: On 31/01/2017 14:32, John Garry wrote: On 30/01/2017 17:12, Alexander Graf wrote: On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

, and I have no more to supplement, so... But when I started the work on V7, met somethings need to clarify with you. Please kindly check the below. On 2017/1/31 1:12, Alexander Graf wrote: On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

, and I have no more to supplement, so... But when I started the work on V7, met somethings need to clarify with you. Please kindly check the below. On 2017/1/31 1:12, Alexander Graf wrote: On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs

Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler

atch moves the crc detection to the assembler. Suggested-by: Alexander Graf <ag...@suse.de> Signed-off-by: Matthias Brugger <mbrug...@suse.com> --- arch/arm64/crypto/Makefile | 2 -- arch/arm64/crypto/crc32-arm64.c | 3 +++ 2 files changed, 3 insertions(+), 2 deletions(-)

Re: [PATCH] crypto: arm64/crc32 - detect crc32 support in assembler

not be able to detect the crc32 extended cpu type. What do you mean 'detect'? Could you describe the failure in more detail please? Anyway only inline assembler code is used, which gets passed to the assembler. This patch moves the crc detection to the assembler. Suggested-by: Alexander Graf Signed

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 31/01/2017 14:32, John Garry wrote: On 30/01/2017 17:12, Alexander Graf wrote: On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses to those peripherals under LPC make use of I/O ports rather than the memory mapped I/O. To drive

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 31/01/2017 14:32, John Garry wrote: On 30/01/2017 17:12, Alexander Graf wrote: On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses to those peripherals under LPC make use of I/O ports rather than the memory mapped I/O. To drive

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 31/01/2017 11:07, John Garry wrote: On 30/01/2017 20:08, Alexander Graf wrote: Alex, Thanks for checking. On 24/01/2017 08:05, zhichang.yuan wrote: The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in I/O port addresses. This patch implements the LPC host

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 31/01/2017 11:07, John Garry wrote: On 30/01/2017 20:08, Alexander Graf wrote: Alex, Thanks for checking. On 24/01/2017 08:05, zhichang.yuan wrote: The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in I/O port addresses. This patch implements the LPC host

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 24/01/2017 08:05, zhichang.yuan wrote: The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in I/O port addresses. This patch implements the LPC host controller driver which perform the I/O operations on the underlying hardware. We don't want to touch those existing

Re: [PATCH V6 4/5] LPC: Support the device-tree LPC host on Hip06/Hip07

On 24/01/2017 08:05, zhichang.yuan wrote: The low-pin-count(LPC) interface of Hip06/Hip07 accesses the peripherals in I/O port addresses. This patch implements the LPC host controller driver which perform the I/O operations on the underlying hardware. We don't want to touch those existing

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses to those peripherals under LPC make use of I/O ports rather than the memory mapped I/O. To drive these devices, this patch introduces a method named indirect-IO. In this method the

Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

On 01/24/2017 08:05 AM, zhichang.yuan wrote: Low-pin-count interface is integrated into some SoCs. The accesses to those peripherals under LPC make use of I/O ports rather than the memory mapped I/O. To drive these devices, this patch introduces a method named indirect-IO. In this method the

[PATCH] arm64: Fix swiotlb fallback allocation

that if we decide not to initialize the swiotlb framework. Fixes: b67a8b29df ("arm64: mm: only initialize swiotlb when necessary") Signed-off-by: Alexander Graf <ag...@suse.de> CC: Catalin Marinas <catalin.mari...@arm.com> CC: Jisheng Zhang <jszh...@marvell.com> CC: Ge

[PATCH] arm64: Fix swiotlb fallback allocation

that if we decide not to initialize the swiotlb framework. Fixes: b67a8b29df ("arm64: mm: only initialize swiotlb when necessary") Signed-off-by: Alexander Graf CC: Catalin Marinas CC: Jisheng Zhang CC: Geert Uytterhoeven CC: Konrad Rzeszutek Wilk --- arch/arm64/mm/init.c | 2

Re: linux-next: possible removal of the kvm-ppc tree

Hi Stephen, > Am 05.12.2016 um 01:39 schrieb Stephen Rothwell : > > Hi Alexander, > > I noticed that the kvm-ppc tree > (git://github.com/agraf/linux-2.6.git#kvm-ppc-next) has not been > updated for over a year. I was wondering if I should remove it from > linux-next? >

Re: linux-next: possible removal of the kvm-ppc tree

Hi Stephen, > Am 05.12.2016 um 01:39 schrieb Stephen Rothwell : > > Hi Alexander, > > I noticed that the kvm-ppc tree > (git://github.com/agraf/linux-2.6.git#kvm-ppc-next) has not been > updated for over a year. I was wondering if I should remove it from > linux-next? > > If so, I will rename

Re: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio

On 10/26/2016 04:35 AM, Stuart Yoder wrote: -Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Monday, October 24, 2016 9:34 AM To: Stuart Yoder <stuart.yo...@nxp.com>; gre...@linuxfoundation.org Cc: German Rivera <german.riv...@nxp.com>; de...@driverde

Re: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio

On 10/26/2016 04:35 AM, Stuart Yoder wrote: -Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Monday, October 24, 2016 9:34 AM To: Stuart Yoder ; gre...@linuxfoundation.org Cc: German Rivera ; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; a...@arndb.de

Re: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio

Hi Stuart, On 10/21/2016 04:01 PM, Stuart Yoder wrote: This patch series: A) addresses the final item in the staging TODO list for the fsl-mc bus driver-- adding a functional driver on top of the bus driver, and B) requests that the fsl-mc bus driver be moved out of staging. Awesome, it's

Re: [PATCH 0/9] staging: fsl-mc: move bus driver out of staging, add dpio

Hi Stuart, On 10/21/2016 04:01 PM, Stuart Yoder wrote: This patch series: A) addresses the final item in the staging TODO list for the fsl-mc bus driver-- adding a functional driver on top of the bus driver, and B) requests that the fsl-mc bus driver be moved out of staging. Awesome, it's

Re: MAINTAINERS without commits in the last 3 years

> Am 24.08.2016 um 19:33 schrieb Joe Perches : > > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. > > Marking these sections appropriately or simply removing the > sections

Re: MAINTAINERS without commits in the last 3 years

> Am 24.08.2016 um 19:33 schrieb Joe Perches : > > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. > > Marking these sections appropriately or simply removing the > sections would make

Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64

> On 17 Aug 2016, at 13:46, Yury Norov wrote: > > This series enables aarch64 with ilp32 mode, and as supporting work, > introduces ARCH_32BIT_OFF_T configuration option that is enabled for > existing 32-bit architectures but disabled for new arches (so 64-bit > off_t

Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64

> On 17 Aug 2016, at 13:46, Yury Norov wrote: > > This series enables aarch64 with ilp32 mode, and as supporting work, > introduces ARCH_32BIT_OFF_T configuration option that is enabled for > existing 32-bit architectures but disabled for new arches (so 64-bit > off_t is is used by new

Re: [PATCH] arm64: Add config to limit user space to 47bits

> Am 14.07.2016 um 09:49 schrieb Zheng Xu : > > Sorry, I might misunderstand the issue. I thought there are still issues with > master. > > I saw that you've mentioned there are pointers to .rodata. And I only fixed > the heap. So I am just worried if there can be issues

Re: [PATCH] arm64: Add config to limit user space to 47bits

> Am 14.07.2016 um 09:49 schrieb Zheng Xu : > > Sorry, I might misunderstand the issue. I thought there are still issues with > master. > > I saw that you've mentioned there are pointers to .rodata. And I only fixed > the heap. So I am just worried if there can be issues with .rodata. If >

Re: [PATCH] arm64: Add config to limit user space to 47bits

On 14.07.16 09:03, Zheng Xu wrote: > LuaJIT also fix the 48VA issue by allocating heap memory below 47 bits. > > For mozjs issue, if there are pointers to .rodata, it can be a problem. Does > it happen on master and do we have any case to reproduce the issue so that I > can take a look? mozjs

Re: [PATCH] arm64: Add config to limit user space to 47bits

On 14.07.16 09:03, Zheng Xu wrote: > LuaJIT also fix the 48VA issue by allocating heap memory below 47 bits. > > For mozjs issue, if there are pointers to .rodata, it can be a problem. Does > it happen on master and do we have any case to reproduce the issue so that I > can take a look? mozjs

Re: [PATCH] arm64: Add config to limit user space to 47bits

> On 14 Jul 2016, at 03:08, Steve Capper <steve.cap...@arm.com> wrote: > > Hi Alex, > > Thanks for posting this. > > On Wed, Jul 13, 2016 at 06:14:11PM +0200, Alexander Graf wrote: >> On 07/13/2016 05:59 PM, Ard Biesheuvel wrote: >>> On 13 July 20

Re: [PATCH] arm64: Add config to limit user space to 47bits

> On 14 Jul 2016, at 03:08, Steve Capper wrote: > > Hi Alex, > > Thanks for posting this. > > On Wed, Jul 13, 2016 at 06:14:11PM +0200, Alexander Graf wrote: >> On 07/13/2016 05:59 PM, Ard Biesheuvel wrote: >>> On 13 July 2016 at 17:42, Alexander Graf wrot

Re: [PATCH] arm64: Add config to limit user space to 47bits

On 07/13/2016 05:59 PM, Ard Biesheuvel wrote: On 13 July 2016 at 17:42, Alexander Graf <ag...@suse.de> wrote: Some user space applications are known to break with 48 bits virtual known by whom? At least I wasn't aware of it, so could you please share some examples? Sure! Known to me

Re: [PATCH] arm64: Add config to limit user space to 47bits

On 07/13/2016 05:59 PM, Ard Biesheuvel wrote: On 13 July 2016 at 17:42, Alexander Graf wrote: Some user space applications are known to break with 48 bits virtual known by whom? At least I wasn't aware of it, so could you please share some examples? Sure! Known to me so far

[PATCH] arm64: Add config to limit user space to 47bits

Some user space applications are known to break with 48 bits virtual address space. As interim step until the world is healed and everyone embraces correct code, this patch allows to only expose 47 bits of virtual address space to user space. Signed-off-by: Alexander Graf <ag...@suse

[PATCH] arm64: Add config to limit user space to 47bits

Some user space applications are known to break with 48 bits virtual address space. As interim step until the world is healed and everyone embraces correct code, this patch allows to only expose 47 bits of virtual address space to user space. Signed-off-by: Alexander Graf --- arch/arm64/Kconfig

[PATCH] rtc: efi: Fail probing if RTC reads don't work

but only spills our kernel log with warnings. Signed-off-by: Alexander Graf <ag...@suse.de> --- drivers/rtc/rtc-efi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c index 96d3860..0130afd 100644 --- a/drivers/rtc/rtc-efi.c +++ b/drive

[PATCH] rtc: efi: Fail probing if RTC reads don't work

but only spills our kernel log with warnings. Signed-off-by: Alexander Graf --- drivers/rtc/rtc-efi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c index 96d3860..0130afd 100644 --- a/drivers/rtc/rtc-efi.c +++ b/drivers/rtc/rtc-efi.c

[PATCH] arm64: Allow for different DMA and CPU bus offsets

-by: Alexander Graf <ag...@suse.de> --- This patch may conflict with another patch titled "swiotlb: prefix dma_to_phys and phys_to_dma functions" which is in flight, but hasn't seen an update since March. Since this patch is very small and isolated to arm64, I'd prefer to keep them

[PATCH] arm64: Allow for different DMA and CPU bus offsets

-by: Alexander Graf --- This patch may conflict with another patch titled "swiotlb: prefix dma_to_phys and phys_to_dma functions" which is in flight, but hasn't seen an update since March. Since this patch is very small and isolated to arm64, I'd prefer to keep them separate rather th

Re: [PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

> Am 17.05.2016 um 22:40 schrieb Dan Murphy <dmur...@ti.com>: > >> On 05/17/2016 03:37 PM, Alexander Graf wrote: >> Hi David, >> >>> Am 17.05.2016 um 20:48 schrieb David Miller <da...@davemloft.net>: >>> >>> From: Dan Mu

Re: [PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

> Am 17.05.2016 um 22:40 schrieb Dan Murphy : > >> On 05/17/2016 03:37 PM, Alexander Graf wrote: >> Hi David, >> >>> Am 17.05.2016 um 20:48 schrieb David Miller : >>> >>> From: Dan Murphy >>> Date: Tue, 17 May 2016 13:34:34 -05

Re: [PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

Hi David, > Am 17.05.2016 um 20:48 schrieb David Miller <da...@davemloft.net>: > > From: Dan Murphy <dmur...@ti.com> > Date: Tue, 17 May 2016 13:34:34 -0500 > >> David >> >>> On 05/17/2016 01:22 PM, David Miller wrote: >>> From: Alexan

Re: [PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

Hi David, > Am 17.05.2016 um 20:48 schrieb David Miller : > > From: Dan Murphy > Date: Tue, 17 May 2016 13:34:34 -0500 > >> David >> >>> On 05/17/2016 01:22 PM, David Miller wrote: >>> From: Alexander Graf >>> Date: Mon, 16 May 2016 2

Re: [PATCH] kvm-pr: manage illegal instructions

On 05/17/2016 10:35 AM, Laurent Vivier wrote: On 12/05/2016 16:23, Laurent Vivier wrote: On 12/05/2016 11:27, Alexander Graf wrote: On 05/12/2016 11:10 AM, Laurent Vivier wrote: On 11/05/2016 13:49, Alexander Graf wrote: On 05/11/2016 01:14 PM, Laurent Vivier wrote: On 11/05/2016 12:35

Re: [PATCH] kvm-pr: manage illegal instructions

On 05/17/2016 10:35 AM, Laurent Vivier wrote: On 12/05/2016 16:23, Laurent Vivier wrote: On 12/05/2016 11:27, Alexander Graf wrote: On 05/12/2016 11:10 AM, Laurent Vivier wrote: On 11/05/2016 13:49, Alexander Graf wrote: On 05/11/2016 01:14 PM, Laurent Vivier wrote: On 11/05/2016 12:35

[PATCH v2 1/2] phy dp83867: Fix compilation with CONFIG_OF_MDIO=m

for both - module as well as compiled in code. Signed-off-by: Alexander Graf <ag...@suse.de> --- drivers/net/phy/dp83867.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index 2afa61b..94cc278 100644 --- a/drivers/n

[PATCH v2 1/2] phy dp83867: Fix compilation with CONFIG_OF_MDIO=m

for both - module as well as compiled in code. Signed-off-by: Alexander Graf --- drivers/net/phy/dp83867.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index 2afa61b..94cc278 100644 --- a/drivers/net/phy/dp83867.c +++ b

[PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

in the device tree, otherwise we fail to load the driver and don't even attach the generic phy driver to the interface anymore. To make things slightly more consistent, make the rgmii configuration properties optional and allow a user to omit them in their device tree. Signed-off-by: Alexander Graf <

[PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

in the device tree, otherwise we fail to load the driver and don't even attach the generic phy driver to the interface anymore. To make things slightly more consistent, make the rgmii configuration properties optional and allow a user to omit them in their device tree. Signed-off-by: Alexander Graf

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

On 16.05.16 14:44, Andrew Lunn wrote: > On Mon, May 16, 2016 at 01:28:15PM +0200, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal configuratio

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

On 16.05.16 14:44, Andrew Lunn wrote: > On Mon, May 16, 2016 at 01:28:15PM +0200, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal configuratio

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

Hi Dan, On 16.05.16 15:38, Dan Murphy wrote: > Alexander > > On 05/16/2016 06:28 AM, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal config

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

Hi Dan, On 16.05.16 15:38, Dan Murphy wrote: > Alexander > > On 05/16/2016 06:28 AM, Alexander Graf wrote: >> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >> enabled. >> It simply passes the device tree test, but leaves all internal config

[PATCH] phy dp83867: depend on CONFIG_OF_MDIO

that we only build the DP83867 phy code when CONFIG_OF_MDIO is set, to not run into that problem. Signed-off-by: Alexander Graf <ag...@suse.de> --- drivers/net/phy/Kconfig | 1 + drivers/net/phy/dp83867.c | 7 --- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/n

[PATCH] phy dp83867: depend on CONFIG_OF_MDIO

that we only build the DP83867 phy code when CONFIG_OF_MDIO is set, to not run into that problem. Signed-off-by: Alexander Graf --- drivers/net/phy/Kconfig | 1 + drivers/net/phy/dp83867.c | 7 --- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/net/phy/Kconfig b

Re: [PATCH] kvm-pr: manage illegal instructions

On 05/12/2016 11:10 AM, Laurent Vivier wrote: On 11/05/2016 13:49, Alexander Graf wrote: On 05/11/2016 01:14 PM, Laurent Vivier wrote: On 11/05/2016 12:35, Alexander Graf wrote: On 03/15/2016 09:18 PM, Laurent Vivier wrote: While writing some instruction tests for kvm-unit-tests for powerpc

Re: [PATCH] kvm-pr: manage illegal instructions

On 05/12/2016 11:10 AM, Laurent Vivier wrote: On 11/05/2016 13:49, Alexander Graf wrote: On 05/11/2016 01:14 PM, Laurent Vivier wrote: On 11/05/2016 12:35, Alexander Graf wrote: On 03/15/2016 09:18 PM, Laurent Vivier wrote: While writing some instruction tests for kvm-unit-tests for powerpc

Re: [PATCH] kvm-pr: manage illegal instructions

On 05/11/2016 01:14 PM, Laurent Vivier wrote: On 11/05/2016 12:35, Alexander Graf wrote: On 03/15/2016 09:18 PM, Laurent Vivier wrote: While writing some instruction tests for kvm-unit-tests for powerpc, I've found that illegal instructions are not managed correctly with kvm-pr, while

Re: [PATCH] kvm-pr: manage illegal instructions

On 05/11/2016 01:14 PM, Laurent Vivier wrote: On 11/05/2016 12:35, Alexander Graf wrote: On 03/15/2016 09:18 PM, Laurent Vivier wrote: While writing some instruction tests for kvm-unit-tests for powerpc, I've found that illegal instructions are not managed correctly with kvm-pr, while

Re: [PATCH] kvm-pr: manage illegal instructions

On 03/15/2016 09:18 PM, Laurent Vivier wrote: While writing some instruction tests for kvm-unit-tests for powerpc, I've found that illegal instructions are not managed correctly with kvm-pr, while it is fine with kvm-hv. When an illegal instruction (like ".long 0") is processed by kvm-pr, the

Re: [PATCH] kvm-pr: manage illegal instructions

On 03/15/2016 09:18 PM, Laurent Vivier wrote: While writing some instruction tests for kvm-unit-tests for powerpc, I've found that illegal instructions are not managed correctly with kvm-pr, while it is fine with kvm-hv. When an illegal instruction (like ".long 0") is processed by kvm-pr, the

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 23:52, Alexander Graf wrote: > > > On 29.04.16 23:37, Bjorn Helgaas wrote: > > Can you point me to the code that does "read[ing] the BARs"? So far my > impression was that we don't even try to read out the current BAR values > from pci config space,

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 23:52, Alexander Graf wrote: > > > On 29.04.16 23:37, Bjorn Helgaas wrote: > > Can you point me to the code that does "read[ing] the BARs"? So far my > impression was that we don't even try to read out the current BAR values > from pci config space,

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 23:37, Bjorn Helgaas wrote: > On Fri, Apr 29, 2016 at 10:51:34PM +0200, Alexander Graf wrote: >> >> >> On 29.04.16 22:25, Ard Biesheuvel wrote: >>> >>>> On 29 apr. 2016, at 22:06, Bjorn Helgaas <helg...@kernel.org> wrote: >>

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 23:37, Bjorn Helgaas wrote: > On Fri, Apr 29, 2016 at 10:51:34PM +0200, Alexander Graf wrote: >> >> >> On 29.04.16 22:25, Ard Biesheuvel wrote: >>> >>>> On 29 apr. 2016, at 22:06, Bjorn Helgaas wrote: >>>> >>>&g

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

g> wrote: >>>>> On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: >>>>> On 28.04.16 20:06, Bjorn Helgaas wrote: >> >>>>>> If firmware is giving us a bare address of something, that seems like >>>>>> a clue

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 29.04.16 22:25, Ard Biesheuvel wrote: > >> On 29 apr. 2016, at 22:06, Bjorn Helgaas wrote: >> >>> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: >>>> On 29 April 2016 at 15:41, Bjorn Helgaas wrote: >>>>> On Thu, Apr

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 28.04.16 20:06, Bjorn Helgaas wrote: > On Thu, Apr 28, 2016 at 06:41:42PM +0200, Alexander Graf wrote: >> On 04/28/2016 06:20 PM, Bjorn Helgaas wrote: >>> On Thu, Apr 28, 2016 at 12:22:24AM +0200, Alexander Graf wrote: >>>> When booting with efifb, we get

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 28.04.16 20:06, Bjorn Helgaas wrote: > On Thu, Apr 28, 2016 at 06:41:42PM +0200, Alexander Graf wrote: >> On 04/28/2016 06:20 PM, Bjorn Helgaas wrote: >>> On Thu, Apr 28, 2016 at 12:22:24AM +0200, Alexander Graf wrote: >>>> When booting with efifb, we get

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 04/28/2016 06:20 PM, Bjorn Helgaas wrote: On Thu, Apr 28, 2016 at 12:22:24AM +0200, Alexander Graf wrote: When booting with efifb, we get a frame buffer address passed into the system. This address can be backed by any device, including PCI devices. I guess we get the frame buffer address

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

On 04/28/2016 06:20 PM, Bjorn Helgaas wrote: On Thu, Apr 28, 2016 at 12:22:24AM +0200, Alexander Graf wrote: When booting with efifb, we get a frame buffer address passed into the system. This address can be backed by any device, including PCI devices. I guess we get the frame buffer address

[PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

time Linux (re)allocates a BAR. That way our arm64 efi code can check whether the frame buffer is inside the old map and adjust it to the new one. With this and the efifb patches applied, I can successfully see efifb output even after Linux remapped BARs. Signed-off-by: Alexander Graf <

[PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

time Linux (re)allocates a BAR. That way our arm64 efi code can check whether the frame buffer is inside the old map and adjust it to the new one. With this and the efifb patches applied, I can successfully see efifb output even after Linux remapped BARs. Signed-off-by: Alexander Graf --- arch

[PATCH] qeth: Default to allow promiscuous mode

. This patch sets the default to allow promiscuous enablement. That way all existing tools "just work", albeit only one port of an adapter can be in promiscuous mode at a given time. Signed-off-by: Alexander Graf <ag...@suse.de> --- drivers/s390/net/qeth_l2_sys.c | 4 1 file chang

[PATCH] qeth: Default to allow promiscuous mode

. This patch sets the default to allow promiscuous enablement. That way all existing tools "just work", albeit only one port of an adapter can be in promiscuous mode at a given time. Signed-off-by: Alexander Graf --- drivers/s390/net/qeth_l2_sys.c | 4 1 file changed, 4 insertions(+)

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On 18.03.16 16:49, Yury Norov wrote: > On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote: >> >> For the glibc part, I found that there are 11 patches of ilp32 in top, >> but the original 28 patches of ilp32 is not in the top, there are more >> than 900 patches between

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On 18.03.16 16:49, Yury Norov wrote: > On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote: >> >> For the glibc part, I found that there are 11 patches of ilp32 in top, >> but the original 28 patches of ilp32 is not in the top, there are more >> than 900 patches between

Re: [PATCH] qeth: Default to allow promiscuous mode

On 17.03.16 18:52, Evgeny Cherkashin wrote: > Hello all, > > -Alexander Graf <ag...@suse.de> wrote: - > >> To: linux-s...@vger.kernel.org >> From: Alexander Graf <ag...@suse.de> >> Date: 2016-03-17 20:01 >> Cc: Evgeny Cherkashin/Russia/I

Re: [PATCH] qeth: Default to allow promiscuous mode

On 17.03.16 18:52, Evgeny Cherkashin wrote: > Hello all, > > -Alexander Graf wrote: - > >> To: linux-s...@vger.kernel.org >> From: Alexander Graf >> Date: 2016-03-17 20:01 >> Cc: Evgeny Cherkashin/Russia/IBM@IBMRU, linux-kernel@vger.kernel.org, &g

Re: [PATCH] vfio: Enable VFIO device for powerpc

On 13.08.15 03:15, David Gibson wrote: > ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is > used to handle any necessary interactions between KVM and VFIO. > > Currently that device is built on x86 and ARM, but not powerpc, although > powerpc does support both KVM and

Re: Build regressions/improvements in v4.2-rc8

On 24.08.15 10:36, Geert Uytterhoeven wrote: > On Mon, Aug 24, 2015 at 10:34 AM, Geert Uytterhoeven > wrote: >> JFYI, when comparing v4.2-rc8[1] to v4.2-rc7[3], the summaries are: >> - build errors: +4/-7 > > 4 regressions: > + /home/kisskb/slave/src/include/linux/kvm_host.h: error: array

Re: Build regressions/improvements in v4.2-rc8

On 24.08.15 10:36, Geert Uytterhoeven wrote: On Mon, Aug 24, 2015 at 10:34 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: JFYI, when comparing v4.2-rc8[1] to v4.2-rc7[3], the summaries are: - build errors: +4/-7 4 regressions: + /home/kisskb/slave/src/include/linux/kvm_host.h:

Re: [PATCH] vfio: Enable VFIO device for powerpc

On 13.08.15 03:15, David Gibson wrote: ec53500f kvm: Add VFIO device added a special KVM pseudo-device which is used to handle any necessary interactions between KVM and VFIO. Currently that device is built on x86 and ARM, but not powerpc, although powerpc does support both KVM and VFIO.

Re: [PATCH v2 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property

> On 14.08.2015, at 09:43, Will Deacon wrote: > > On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote: >> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote: >>> When pci-host-generic looks for the probe-only property, it seems >>> to trust the DT to be correctly written,

Re: [PATCH v2 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property

On 14.08.2015, at 09:43, Will Deacon will.dea...@arm.com wrote: On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote: On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote: When pci-host-generic looks for the probe-only property, it seems to trust the DT to be correctly

Re: [PATCH] kvm:powerpc:Fix incorrect return statement in the function mpic_set_default_irq_routing

On 12.08.15 21:06, nick wrote: > > > On 2015-08-12 03:05 PM, Alexander Graf wrote: >> >> >> On 07.08.15 17:54, Nicholas Krause wrote: >>> This fixes the incorrect return statement in the function >>> mpic_set_default_irq_routing fro

Re: [PATCH] kvm:powerpc:Fix return statements for wrapper functions in the file book3s_64_mmu_hv.c

On 10.08.15 17:27, Nicholas Krause wrote: > This fixes the wrapper functions kvm_umap_hva_hv and the function > kvm_unmap_hav_range_hv to return the return value of the function > kvm_handle_hva or kvm_handle_hva_range that they are wrapped to > call internally rather then always making the

Re: [PATCH] kvm:powerpc:Fix incorrect return statement in the function mpic_set_default_irq_routing

On 07.08.15 17:54, Nicholas Krause wrote: > This fixes the incorrect return statement in the function > mpic_set_default_irq_routing from always returning zero > to signal success to this function's caller to instead > return the return value of kvm_set_irq_routing as this > function can fail

<    1   2   3   4   5   6   7   8   9   >