Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 10/20/2017 01:24 PM, Jon Masters wrote: > 1). The first thing people do when they get an Arm server is to cat > /proc/cpuinfo. They then come complaining that it's not like x86. They > can't get the output their looking for and this results in bug filing, > and countless hours on

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

Hi Mark, On 10/20/2017 12:10 PM, Mark Rutland wrote: > On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote: >> Obviously, you'll have to see the patches to >> properly answer that, but what I'm playing with at present is placing >> this info in new entries in /sys/devices/cpu and/or

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

Hi Mark, On 10/20/2017 12:10 PM, Mark Rutland wrote: > On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote: >> Obviously, you'll have to see the patches to >> properly answer that, but what I'm playing with at present is placing >> this info in new entries in /sys/devices/cpu and/or

Re: [RFC PATCH 0/2] Missing READ_ONCE in core and arch-specific pgtable code leading to crashes

On 09/29/2017 04:56 AM, Will Deacon wrote: > The full fix isn't just cosmetic; it's also addressing the wider problem > of unannotated racing page table accesses outside of the specific failure > case we've run into. Let us know if there are additional tests we should be running on the Red Hat

Re: [RFC PATCH 0/2] Missing READ_ONCE in core and arch-specific pgtable code leading to crashes

On 09/29/2017 04:56 AM, Will Deacon wrote: > The full fix isn't just cosmetic; it's also addressing the wider problem > of unannotated racing page table accesses outside of the specific failure > case we've run into. Let us know if there are additional tests we should be running on the Red Hat

Re: [PATCH] tee: ACPI support for optee driver

On 09/22/2017 05:37 AM, Lorenzo Pieralisi wrote: > On Thu, Sep 21, 2017 at 03:45:28PM +0800, Hanjun Guo wrote: >> On 2017/9/21 15:12, Mayuresh Chitale wrote: >>> This patch modifies the optee driver to add support for parsing >>> the conduit method from an ACPI node. >> >> Sorry I didn't involve

Re: [PATCH] tee: ACPI support for optee driver

On 09/22/2017 05:37 AM, Lorenzo Pieralisi wrote: > On Thu, Sep 21, 2017 at 03:45:28PM +0800, Hanjun Guo wrote: >> On 2017/9/21 15:12, Mayuresh Chitale wrote: >>> This patch modifies the optee driver to add support for parsing >>> the conduit method from an ACPI node. >> >> Sorry I didn't involve

Re: [RFC PATCH 0/2] Missing READ_ONCE in core and arch-specific pgtable code leading to crashes

On 09/27/2017 11:49 AM, Will Deacon wrote: > The moral of the story is that read-after-read (same address) ordering *only* > applies if READ_ONCE is used consistently. This means we need to fix page > table dereferences in the core code as well as the arch code to avoid this > problem. The two

Re: [RFC PATCH 0/2] Missing READ_ONCE in core and arch-specific pgtable code leading to crashes

On 09/27/2017 11:49 AM, Will Deacon wrote: > The moral of the story is that read-after-read (same address) ordering *only* > applies if READ_ONCE is used consistently. This means we need to fix page > table dereferences in the core code as well as the arch code to avoid this > problem. The two

Re: [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports

On 09/12/2017 05:40 AM, Vadim Lomovtsev wrote: > Are there any updates on this ? > Comments/objections/acks/nacks ? Any more comments? Jon. > On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote: >> Using vfio-pci on a combination of cn8xxx and some PCI devices results in >> a kernel

Re: [v4,0/3] Workaround for bus/slot reset on Cavium cn8xxx root ports

On 09/12/2017 05:40 AM, Vadim Lomovtsev wrote: > Are there any updates on this ? > Comments/objections/acks/nacks ? Any more comments? Jon. > On Fri, Sep 08, 2017 at 10:10:30AM +0200, Jan Glauber wrote: >> Using vfio-pci on a combination of cn8xxx and some PCI devices results in >> a kernel

Re: [PATCH 0/2] PCI: Workaround for bus reset on Cavium cn8xxx root ports

Following up on this thread... On 05/23/2017 06:15 PM, Alex Williamson wrote: > On Tue, 23 May 2017 14:22:01 -0700 > David Daney wrote: > >> On 05/23/2017 02:04 PM, Alex Williamson wrote: >>> On Tue, 23 May 2017 15:47:50 -0500 >>> Bjorn Helgaas

Re: [PATCH 0/2] PCI: Workaround for bus reset on Cavium cn8xxx root ports

Following up on this thread... On 05/23/2017 06:15 PM, Alex Williamson wrote: > On Tue, 23 May 2017 14:22:01 -0700 > David Daney wrote: > >> On 05/23/2017 02:04 PM, Alex Williamson wrote: >>> On Tue, 23 May 2017 15:47:50 -0500 >>> Bjorn Helgaas wrote: >>> On Mon, May 15, 2017 at

Re: [PATCH 2/2] PCI: Avoid bus reset for Cavium cn8xxx root ports.

Hahahahahaha :) -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On May 17, 2017, at 03:08, Joe Perches wrote: > >> On Tue, 2017-05-16 at 13:29 -0700, David Daney wrote: >> We really need to improve the >> grammatical analysis capabilities of checkpatch.pl,

Re: [PATCH 2/2] PCI: Avoid bus reset for Cavium cn8xxx root ports.

Hahahahahaha :) -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On May 17, 2017, at 03:08, Joe Perches wrote: > >> On Tue, 2017-05-16 at 13:29 -0700, David Daney wrote: >> We really need to improve the >> grammatical analysis capabilities of checkpatch.pl, I think I will lay

Re: CFP: KVM Forum 2017

. -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On May 9, 2017, at 03:06, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > - Original Message - >> From: "Jon Masters" <j...@jonmasters.org> >> To: "Paolo Bonzini"

Re: CFP: KVM Forum 2017

. -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On May 9, 2017, at 03:06, Paolo Bonzini wrote: > > > > - Original Message ----- >> From: "Jon Masters" >> To: "Paolo Bonzini" , "KVM list" >> , linux-kernel@vger.kerne

Re: CFP: KVM Forum 2017

On 05/02/2017 06:41 AM, Paolo Bonzini wrote: > > KVM Forum 2017: Call For Participation > October 25-27, 2017 - Hilton Prague - Prague, Czech Republic > > (All submissions must be received before midnight June 15, 2017) >

Re: CFP: KVM Forum 2017

On 05/02/2017 06:41 AM, Paolo Bonzini wrote: > > KVM Forum 2017: Call For Participation > October 25-27, 2017 - Hilton Prague - Prague, Czech Republic > > (All submissions must be received before midnight June 15, 2017) >

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Sorry for top post. We would need to also need to handle other OEMs like HPE m400. The set is limited but we want to key off the right ID. You could also key off DMI data if it were later in boot. But probably too early at this point. -- Computer Architect | Sent from my 64-bit #ARM Powered

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Sorry for top post. We would need to also need to handle other OEMs like HPE m400. The set is limited but we want to key off the right ID. You could also key off DMI data if it were later in boot. But probably too early at this point. -- Computer Architect | Sent from my 64-bit #ARM Powered

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

On 05/08/2017 03:11 PM, Loc Ho wrote: > Hi Jon, > >>> The current SPCR code does not check the access width of the mmio, and >>> uses a default of 8bit register accesses. This prevents devices that >>> only do 16 or 32bit register accesses from working. By simply checking >>> this field and

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

On 05/08/2017 03:11 PM, Loc Ho wrote: > Hi Jon, > >>> The current SPCR code does not check the access width of the mmio, and >>> uses a default of 8bit register accesses. This prevents devices that >>> only do 16 or 32bit register accesses from working. By simply checking >>> this field and

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

On 05/09/2016 06:00 AM, Robin Murphy wrote: > On 09/05/16 10:37, Robin Murphy wrote: >> Hi Niklas, >> >> On 08/05/16 11:59, Niklas Söderlund wrote: >>> Hi, >>> >>> While using CONFIG_DMA_API_DEBUG i came across this warning which I >>> think is a false positive. As shown

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

On 05/09/2016 06:00 AM, Robin Murphy wrote: > On 09/05/16 10:37, Robin Murphy wrote: >> Hi Niklas, >> >> On 08/05/16 11:59, Niklas Söderlund wrote: >>> Hi, >>> >>> While using CONFIG_DMA_API_DEBUG i came across this warning which I >>> think is a false positive. As shown

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

On 05/04/2017 11:05 AM, Jon Mason wrote: > The current SPCR code does not check the access width of the mmio, and > uses a default of 8bit register accesses. This prevents devices that > only do 16 or 32bit register accesses from working. By simply checking > this field and setting the mmio

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

On 05/04/2017 11:05 AM, Jon Mason wrote: > The current SPCR code does not check the access width of the mmio, and > uses a default of 8bit register accesses. This prevents devices that > only do 16 or 32bit register accesses from working. By simply checking > this field and setting the mmio

Re: [PATCH 2/2] arm64:vdso: Remove ISB from gettimeofday.

again as plain text (I did not notice that before). > > On 5/6/2017 9:29 AM, Jon Masters wrote: >> On 04/23/2017 07:47 PM, Andrew Pinski wrote: >> ISB is normally required before mrs CNTVCT if we want the >> mrs to completed after the loads. In this case it is

Re: [PATCH 2/2] arm64:vdso: Remove ISB from gettimeofday.

ot notice that before). > > On 5/6/2017 9:29 AM, Jon Masters wrote: >> On 04/23/2017 07:47 PM, Andrew Pinski wrote: >> ISB is normally required before mrs CNTVCT if we want the >> mrs to completed after the loads. In this case it is not. >> As we are taking the differe

Re: [PATCH 2/2] arm64:vdso: Remove ISB from gettimeofday.

On 04/23/2017 07:47 PM, Andrew Pinski wrote: > ISB is normally required before mrs CNTVCT if we want the > mrs to completed after the loads. In this case it is not. > As we are taking the difference and if that difference > was going to be negative, we just use the last counter value > instead. >

Re: [PATCH 2/2] arm64:vdso: Remove ISB from gettimeofday.

On 04/23/2017 07:47 PM, Andrew Pinski wrote: > ISB is normally required before mrs CNTVCT if we want the > mrs to completed after the loads. In this case it is not. > As we are taking the difference and if that difference > was going to be negative, we just use the last counter value > instead. >

Re: [PATCH 1/1] arm64: Always provide "model name" in /proc/cpuinfo

On 05/02/2017 07:08 AM, Catalin Marinas wrote: > On Tue, May 02, 2017 at 12:39:13AM +0200, Heinrich Schuchardt wrote: >> There is no need to hide the model name in processes >> that are not PER_LINUX32. >> >> So let us always provide a model name that is easily readable. >> >> Fixes: e47b020a323d

Re: [PATCH 1/1] arm64: Always provide "model name" in /proc/cpuinfo

On 05/02/2017 07:08 AM, Catalin Marinas wrote: > On Tue, May 02, 2017 at 12:39:13AM +0200, Heinrich Schuchardt wrote: >> There is no need to hide the model name in processes >> that are not PER_LINUX32. >> >> So let us always provide a model name that is easily readable. >> >> Fixes: e47b020a323d

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

On 05/05/2017 10:58 AM, Will Deacon wrote: > On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote: >> On 05/05/2017 06:53 AM, Hanjun Guo wrote: >>> On 2017/5/5 20:08, Geetha sowjanya wrote: From: Linu Cherian +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

On 05/05/2017 10:58 AM, Will Deacon wrote: > On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote: >> On 05/05/2017 06:53 AM, Hanjun Guo wrote: >>> On 2017/5/5 20:08, Geetha sowjanya wrote: From: Linu Cherian +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x0002 /* Cavium

Re: [GIT pull] irq updates for 4.12

On 05/01/2017 06:39 AM, Thomas Gleixner wrote: > - ACPI support for ARM GICV3 (ACPI support for MSIs when using an ITS with GICv3) Jon.

Re: [GIT pull] irq updates for 4.12

On 05/01/2017 06:39 AM, Thomas Gleixner wrote: > - ACPI support for ARM GICV3 (ACPI support for MSIs when using an ITS with GICv3) Jon.

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On 05/03/2017 05:47 AM, Will Deacon wrote: > Hi Geetha, > > On Tue, May 02, 2017 at 12:01:15PM +0530, Geetha Akula wrote: >> SMMU_IIDR register is broken on T99, that the reason we are using MIDR. > > Urgh, that's unfortunate. In what way is it broken? > >> If using MIDR is not accepted, can we

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

On 05/03/2017 05:47 AM, Will Deacon wrote: > Hi Geetha, > > On Tue, May 02, 2017 at 12:01:15PM +0530, Geetha Akula wrote: >> SMMU_IIDR register is broken on T99, that the reason we are using MIDR. > > Urgh, that's unfortunate. In what way is it broken? > >> If using MIDR is not accepted, can we

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/28/2017 12:36 PM, Jon Masters wrote: > On 04/28/2017 01:11 AM, Jon Masters wrote: >> On 04/27/2017 08:54 PM, Khuong Dinh wrote: >>> From: Khuong Dinh <kd...@apm.com> >>> >>> This patch makes pci-xgene-msi driver ACPI-aware and provides >>

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/28/2017 12:36 PM, Jon Masters wrote: > On 04/28/2017 01:11 AM, Jon Masters wrote: >> On 04/27/2017 08:54 PM, Khuong Dinh wrote: >>> From: Khuong Dinh >>> >>> This patch makes pci-xgene-msi driver ACPI-aware and provides >>> MSI capability for

Re: [PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

n confirm that a 4.11 machine previously experiencing an issue has stable VMs with these. Tested-by: Jon Masters <j...@redhat.com>

Re: [PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

n confirm that a 4.11 machine previously experiencing an issue has stable VMs with these. Tested-by: Jon Masters

Re: [RFC/PATCH] perf: Add sizeof operator support

Hi Jeremy, On 06/14/2016 12:38 PM, Jeremy Linton wrote: > There are a fair number of tracepoints in the kernel making > use of the sizeof operator. Allow perf to understand some of > those cases, and report a more informative error message for > the ones it cannot understand. What's the status

Re: [RFC/PATCH] perf: Add sizeof operator support

Hi Jeremy, On 06/14/2016 12:38 PM, Jeremy Linton wrote: > There are a fair number of tracepoints in the kernel making > use of the sizeof operator. Allow perf to understand some of > those cases, and report a more informative error message for > the ones it cannot understand. What's the status

Re: [PATCH] SPCR: check bit width for the 16550 UART

On 12/13/2016 01:20 AM, Jon Masters wrote: > On 12/07/2016 10:23 AM, Mark Salter wrote: >> If you specify a baudrate with earlycon=, the driver tries to set that >> baudrate and if you have an 8250 with some non-standard baud clock, then >> it will fail. Perhaps SPCR shoul

Re: [PATCH] SPCR: check bit width for the 16550 UART

On 12/13/2016 01:20 AM, Jon Masters wrote: > On 12/07/2016 10:23 AM, Mark Salter wrote: >> If you specify a baudrate with earlycon=, the driver tries to set that >> baudrate and if you have an 8250 with some non-standard baud clock, then >> it will fail. Perhaps SPCR shoul

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/28/2017 01:11 AM, Jon Masters wrote: > On 04/27/2017 08:54 PM, Khuong Dinh wrote: >> From: Khuong Dinh <kd...@apm.com> >> >> This patch makes pci-xgene-msi driver ACPI-aware and provides >> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. >

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/28/2017 01:11 AM, Jon Masters wrote: > On 04/27/2017 08:54 PM, Khuong Dinh wrote: >> From: Khuong Dinh >> >> This patch makes pci-xgene-msi driver ACPI-aware and provides >> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. >> >> Si

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/27/2017 08:54 PM, Khuong Dinh wrote: > From: Khuong Dinh > > This patch makes pci-xgene-msi driver ACPI-aware and provides > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. > > Signed-off-by: Khuong Dinh > Signed-off-by: Duc Dang

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/27/2017 08:54 PM, Khuong Dinh wrote: > From: Khuong Dinh > > This patch makes pci-xgene-msi driver ACPI-aware and provides > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. > > Signed-off-by: Khuong Dinh > Signed-off-by: Duc Dang > Acked-by: Marc Zyngier Thanks.

Re: Generic DMA-capable streaming device driver looking for home

On 04/20/2017 06:10 PM, Alex Williams wrote: > Hi all, > > We're writing a device driver and having some difficulty matching a > subsystem to the driver/device properties. Can anyone help with > direction? > > These are some basic properties: > 1) Device is used to carry generic data to/from

Re: Generic DMA-capable streaming device driver looking for home

On 04/20/2017 06:10 PM, Alex Williams wrote: > Hi all, > > We're writing a device driver and having some difficulty matching a > subsystem to the driver/device properties. Can anyone help with > direction? > > These are some basic properties: > 1) Device is used to carry generic data to/from

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 06/03/2016 06:15 PM, Duc Dang wrote: > Do you have other suggestions? Otherwise, I will prepare a patch > following Lorenzo's approach. Duc has since left Applied for other pastures. I miss him, he's a great guy. He laid all the right groundwork for this, but the ACPI binding still needs to

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 06/03/2016 06:15 PM, Duc Dang wrote: > Do you have other suggestions? Otherwise, I will prepare a patch > following Lorenzo's approach. Duc has since left Applied for other pastures. I miss him, he's a great guy. He laid all the right groundwork for this, but the ACPI binding still needs to

Re: [BUG] x86: failed to boot a kernel on a Ryzen machine

On 04/24/2017 07:27 AM, Satoru Takeuchi wrote: > At Mon, 24 Apr 2017 15:58:05 +0900, > Satoru Takeuchi wrote: >> >> [1 ] >> Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it, >> it failed to boot >> with the following panic log. Side note - have forwarded to the AMD

Re: [BUG] x86: failed to boot a kernel on a Ryzen machine

On 04/24/2017 07:27 AM, Satoru Takeuchi wrote: > At Mon, 24 Apr 2017 15:58:05 +0900, > Satoru Takeuchi wrote: >> >> [1 ] >> Recently I bought a new Ryzen machine. When I tried to test v4.11-rc8 on it, >> it failed to boot >> with the following panic log. Side note - have forwarded to the AMD

Re: Question on the five-level page table support patches

On 04/24/2017 06:09 PM, David Miller wrote: > From: John Paul Adrian Glaubitz > Date: Mon, 24 Apr 2017 22:37:40 +0200 > >> Would be really nice to able to have a canonical solution for this issue, >> it's been biting us on SPARC for quite a while now due to the fact

Re: Question on the five-level page table support patches

On 04/24/2017 06:09 PM, David Miller wrote: > From: John Paul Adrian Glaubitz > Date: Mon, 24 Apr 2017 22:37:40 +0200 > >> Would be really nice to able to have a canonical solution for this issue, >> it's been biting us on SPARC for quite a while now due to the fact that >> virtual address space

Re: [HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

On 04/23/2017 08:39 PM, John Hubbard wrote: > Actually, MEMORY_DEVICE_PRIVATE / _PUBLIC seems like a good choice to > me, because the memory may not remain CPU-unaddressable in the future. > By that, I mean that I know of at least one company (ours) that is > working on products that will

Re: [HMM 03/15] mm/unaddressable-memory: new type of ZONE_DEVICE for unaddressable memory

On 04/23/2017 08:39 PM, John Hubbard wrote: > Actually, MEMORY_DEVICE_PRIVATE / _PUBLIC seems like a good choice to > me, because the memory may not remain CPU-unaddressable in the future. > By that, I mean that I know of at least one company (ours) that is > working on products that will

Re: [PATCH v2 2/2] module: Add module name to modinfo

Nevermind. Missread the patch as doing something different on first pass. -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On Apr 25, 2017, at 03:00, Jon Masters <j...@jonmasters.org> wrote: > >> On 04/21/2017 06:35 PM, Kees Cook wrote: >> >> Ac

Re: [PATCH v2 2/2] module: Add module name to modinfo

Nevermind. Missread the patch as doing something different on first pass. -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On Apr 25, 2017, at 03:00, Jon Masters wrote: > >> On 04/21/2017 06:35 PM, Kees Cook wrote: >> >> Accessing the mod structure (e

Re: [PATCH v2 2/2] module: Add module name to modinfo

On 04/21/2017 06:35 PM, Kees Cook wrote: > Accessing the mod structure (e.g. for mod->name) prior to having completed > check_modstruct_version() can result in writing garbage to the error logs > if the layout of the mod structure loaded from disk doesn't match the > running kernel's mod

Re: [PATCH v2 2/2] module: Add module name to modinfo

On 04/21/2017 06:35 PM, Kees Cook wrote: > Accessing the mod structure (e.g. for mod->name) prior to having completed > check_modstruct_version() can result in writing garbage to the error logs > if the layout of the mod structure loaded from disk doesn't match the > running kernel's mod

Re: Kernel lockup with Intel Iris graphics

On 04/20/2017 07:59 AM, Ulrich Windl wrote: > maybe someone has a idea on this: > https://bugzilla.opensuse.org/show_bug.cgi?id=1032832 I dunno if SuSE is still using the Intel Xorg driver but I had to preemptively switch (Fedora has now done this by default) to the modesetting driver from the

Re: Kernel lockup with Intel Iris graphics

On 04/20/2017 07:59 AM, Ulrich Windl wrote: > maybe someone has a idea on this: > https://bugzilla.opensuse.org/show_bug.cgi?id=1032832 I dunno if SuSE is still using the Intel Xorg driver but I had to preemptively switch (Fedora has now done this by default) to the modesetting driver from the

Re: [PATCH v4 00/21] PCI: fix config space memory mappings

On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI > configuration non-posted write transactions requirement, because it > provides a memory mapping that issues "bufferable" or, in PCI terms > "posted" write transactions.

Re: [PATCH v4 00/21] PCI: fix config space memory mappings

On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI > configuration non-posted write transactions requirement, because it > provides a memory mapping that issues "bufferable" or, in PCI terms > "posted" write transactions.

Re: Doubt on first access for PCIe device

On 04/11/2017 10:15 AM, abhijit wrote: > Here I am assuming, the completer ID will be device number and function > number that will eventually programmed in to device. In that case, my > question is, without first write, how read request(VENDOR ID read) is > serviced/routed? You'll want to

Re: Doubt on first access for PCIe device

On 04/11/2017 10:15 AM, abhijit wrote: > Here I am assuming, the completer ID will be device number and function > number that will eventually programmed in to device. In that case, my > question is, without first write, how read request(VENDOR ID read) is > serviced/routed? You'll want to

Re: [GIT PULL] arm64: fixes for -rc6

On 04/07/2017 12:02 PM, Will Deacon wrote: > Please pull these two arm64 fixes for -rc6. We've got a regression fix for > the signal raised when userspace makes an unsupported unaligned access and a > revert of the contiguous (hugepte) support for hugetlb, which has once again > been found to be

Re: [GIT PULL] arm64: fixes for -rc6

On 04/07/2017 12:02 PM, Will Deacon wrote: > Please pull these two arm64 fixes for -rc6. We've got a regression fix for > the signal raised when userspace makes an unsupported unaligned access and a > revert of the contiguous (hugepte) support for hugetlb, which has once again > been found to be

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 04/06/2017 11:58 AM, Catalin Marinas wrote: > The Cavium guys haven't shown any numbers (IIUC) to back the > L1_CACHE_BYTES performance improvement but I would not revert the > original commit since ARCH_DMA_MINALIGN definitely needs to cover the > maximum available cache line size, which is

Re: [PATCH] Revert "arm64: Increase the max granular size"

On 04/06/2017 11:58 AM, Catalin Marinas wrote: > The Cavium guys haven't shown any numbers (IIUC) to back the > L1_CACHE_BYTES performance improvement but I would not revert the > original commit since ARCH_DMA_MINALIGN definitely needs to cover the > maximum available cache line size, which is

Re: [PATCH 11/12] efi/libstub: arm/arm64: Disable debug prints on 'quiet' cmdline arg

On 04/04/2017 12:09 PM, Ard Biesheuvel wrote: > The EFI stub currently prints a number of diagnostic messages that do > not carry a lot of information. Since these prints are not controlled > by 'loglevel' or other command line parameters, and since they appear on > the EFI framebuffer as well (if

Re: [PATCH 11/12] efi/libstub: arm/arm64: Disable debug prints on 'quiet' cmdline arg

On 04/04/2017 12:09 PM, Ard Biesheuvel wrote: > The EFI stub currently prints a number of diagnostic messages that do > not carry a lot of information. Since these prints are not controlled > by 'loglevel' or other command line parameters, and since they appear on > the EFI framebuffer as well (if

Re: [PATCH v22 00/11] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Anyone got review comments for this series? On 03/21/2017 12:31 PM, fu@linaro.org wrote: > From: Fu Wei > > This patchset: > (1)Preparation for adding GTDT support in arm_arch_timer: > 1. Introduce a wrapper function to get the frequency from mmio. >

Re: [PATCH v22 00/11] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Anyone got review comments for this series? On 03/21/2017 12:31 PM, fu@linaro.org wrote: > From: Fu Wei > > This patchset: > (1)Preparation for adding GTDT support in arm_arch_timer: > 1. Introduce a wrapper function to get the frequency from mmio. > 2. separate out

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

Thanks :) :) :) -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On Mar 23, 2017, at 18:14, Bjorn Helgaas <helg...@kernel.org> wrote: > >> On Wed, Mar 22, 2017 at 11:34:00AM -0500, Bjorn Helgaas wrote: >>> On Wed, Mar 22, 2017 at 12:25:39PM -0400, Jo

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

Thanks :) :) :) -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On Mar 23, 2017, at 18:14, Bjorn Helgaas wrote: > >> On Wed, Mar 22, 2017 at 11:34:00AM -0500, Bjorn Helgaas wrote: >>> On Wed, Mar 22, 2017 at 12:25:39PM -0400, Jon Masters wrote: >&g

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

On 03/22/2017 10:48 AM, Bjorn Helgaas wrote: > On Wed, Mar 22, 2017 at 10:28:27AM -0400, Jon Masters wrote: >> On 03/21/2017 10:56 AM, David Daney wrote: > >>> Yes. After all this back and forth, Cavium has decided to deploy >>> firmware with "CAVxxx"

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

On 03/22/2017 10:48 AM, Bjorn Helgaas wrote: > On Wed, Mar 22, 2017 at 10:28:27AM -0400, Jon Masters wrote: >> On 03/21/2017 10:56 AM, David Daney wrote: > >>> Yes. After all this back and forth, Cavium has decided to deploy >>> firmware with "CAVxxx"

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

On 03/21/2017 10:56 AM, David Daney wrote: > On 03/21/2017 07:17 AM, Tomasz Nowicki wrote: >> On 21.03.2017 14:47, Bjorn Helgaas wrote: And for other folks following along with this thread: I'm not just picking on Cavium here. I'll be doing the same with *every* ARM server SoC

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

On 03/21/2017 10:56 AM, David Daney wrote: > On 03/21/2017 07:17 AM, Tomasz Nowicki wrote: >> On 21.03.2017 14:47, Bjorn Helgaas wrote: And for other folks following along with this thread: I'm not just picking on Cavium here. I'll be doing the same with *every* ARM server SoC

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

On 03/16/2017 12:25 PM, David Daney wrote: > On 03/16/2017 07:32 AM, Jon Masters wrote: >>> Yes, it is now contains "CAVxxx" as _HID for device config object. >> >> Which is different from the version that was merged into upstream. That >> should never have

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

On 03/16/2017 12:25 PM, David Daney wrote: > On 03/16/2017 07:32 AM, Jon Masters wrote: >>> Yes, it is now contains "CAVxxx" as _HID for device config object. >> >> Which is different from the version that was merged into upstream. That >> should never have

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

Hi Vadim, Thanks for your followup and attention to this matter. More below. On 03/15/2017 07:33 AM, Vadim Lomovtsev wrote: >> The upstream Linux kernel contains a quirk matching entry that looks for >> "THRX". Therefore, you have already agreed (as of at least January) that >> this is the

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

Hi Vadim, Thanks for your followup and attention to this matter. More below. On 03/15/2017 07:33 AM, Vadim Lomovtsev wrote: >> The upstream Linux kernel contains a quirk matching entry that looks for >> "THRX". Therefore, you have already agreed (as of at least January) that >> this is the

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

Hi Bjorn, Vadim, Following up to this old thread... On 02/01/2017 10:18 AM, Bjorn Helgaas wrote: > On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote: Because there is no such ACPI ID as "THRX0002" registered (http://www.uefi.org/acpi_id_list). There is still no "THRX"

Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization

Hi Bjorn, Vadim, Following up to this old thread... On 02/01/2017 10:18 AM, Bjorn Helgaas wrote: > On Wed, Feb 01, 2017 at 04:53:25AM -0800, Vadim Lomovtsev wrote: Because there is no such ACPI ID as "THRX0002" registered (http://www.uefi.org/acpi_id_list). There is still no "THRX"

Re: kexec on panic

Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: > After years of using kexec and recent unpleasant experience with modern > (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to > pass POST tests, > one question came up to me: > Is it possible anyhow to

Re: kexec on panic

Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: > After years of using kexec and recent unpleasant experience with modern > (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to > pass POST tests, > one question came up to me: > Is it possible anyhow to

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

ff : PCI ECAM a11000-a14fff : PCI Bus :00 a11000-a121ff : PCI Bus :01 a11000-a111ff : :01:00.0 a11000-a111ff : mlx4_core a11200-a121ff : :01:00.0 Thanks again, Bjorn. Looking forward to seeing this upstream. Tested-by: Jon M

Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

ff : PCI ECAM a11000-a14fff : PCI Bus :00 a11000-a121ff : PCI Bus :01 a11000-a111ff : :01:00.0 a11000-a111ff : mlx4_core a11200-a121ff : :01:00.0 Thanks again, Bjorn. Looking forward to seeing this upstream. Tested-by: Jon

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

On 11/29/2016 04:39 PM, Bjorn Helgaas wrote: > +New architectures should be able to use "Consumer" Extended Address Space > +descriptors in the PNP0A03 device for bridge registers, including ECAM, > +although a strict interpretation of [6] might prohibit this. Old x86 and > +ia64 kernels assume

Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

On 11/29/2016 04:39 PM, Bjorn Helgaas wrote: > +New architectures should be able to use "Consumer" Extended Address Space > +descriptors in the PNP0A03 device for bridge registers, including ECAM, > +although a strict interpretation of [6] might prohibit this. Old x86 and > +ia64 kernels assume

Re: [PATCH] SPCR: check bit width for the 16550 UART

On 12/07/2016 10:23 AM, Mark Salter wrote: > On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote: >> On 12/05/2016 10:55 PM, Duc Dang wrote: >>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <j...@redhat.com> wrote: >>>> HOWEVER while the consol

Re: [PATCH] SPCR: check bit width for the 16550 UART

On 12/07/2016 10:23 AM, Mark Salter wrote: > On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote: >> On 12/05/2016 10:55 PM, Duc Dang wrote: >>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters wrote: >>>> HOWEVER while the console does come up, the use of "

Re: [RFC v2 3/4] ACPI: DBG2: add 16550 UART with 32-bit access

Quick note - specifically, Rafael, this is not currently part of the SPCR specification and should not be considered for inclusion in Linux until that is decided. Once it is determined what the fix for SPCR is, that should then be driven into the component architecture and proposed here. --

<    1   2   3   4   5   6   7   8   9   >