Hi Marcin,
Many thanks for your thoughtful, heartfelt response, and I don't
disagree with your sentiments.
The truth is that we have a messy situation. As a collective community
of people who are passionate about the success of Arm in general
purpose systems, I know many who would share my person
On 3/22/21 2:34 PM, Jon Masters wrote:
Hi Nicolas,
On 11/7/19 4:56 AM, Nicolas Saenz Julienne wrote:
With the introduction of ZONE_DMA in arm64 we moved the default CMA and
crashkernel reservation into that area. This caused a regression on big
machines that need big CMA and crashkernel
Hi Nicolas,
On 11/7/19 4:56 AM, Nicolas Saenz Julienne wrote:
With the introduction of ZONE_DMA in arm64 we moved the default CMA and
crashkernel reservation into that area. This caused a regression on big
machines that need big CMA and crashkernel reservations. Note that
ZONE_DMA is only 1GB bi
On 1/7/21 1:09 PM, Florian Fainelli wrote:
On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
Hi Greg and Konrad,
This change is intended to be non-arch specific. Any arch that lacks DMA access
control and has devices not behind an IOM
Hi will, everyone,
On 1/7/21 1:14 PM, Will Deacon wrote:
On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply a firmware abstraction. The ARM PCI
On 11/11/20 12:43 AM, Ben Widawsky wrote:
+ case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
+ dev_dbg(&cxlm->pdev->dev,
+ "found UNSUPPORTED Secondary Mailbox
capability\n");
Per spec, the secondary mailbox is intended for u
On 10/1/20 12:15 PM, Alan Stern wrote:
On Wed, Sep 30, 2020 at 09:51:16PM -0700, Paul E. McKenney wrote:
Hello!
Al Viro posted the following query:
fun question regarding barriers, if you have time for that
V->
On 9/14/20 1:23 AM, Valmiki wrote:
Hi All,
How does "dma-coherent" property will work for PCIe as RC on an
ARM SOC ?
Because the end point device drivers are the one which will request dma
buffers and Root port driver doesn't involve in data path of end point
except for handling interrupts.
H
On 9/10/19 12:21 AM, Ahmed S. Darwish wrote:
> Can this even be considered a user-space breakage? I'm honestly not
> sure. On my modern RDRAND-capable x86, just running rng-tools rngd(8)
> early-on fixes the problem. I'm not sure about the status of older
> CPUs though.
Tangent: I asked aloud on
On 9/10/19 12:21 AM, Ahmed S. Darwish wrote:
> Can this even be considered a user-space breakage? I'm honestly not
> sure. On my modern RDRAND-capable x86, just running rng-tools rngd(8)
> early-on fixes the problem. I'm not sure about the status of older
> CPUs though.
Tangent: I asked aloud on
On 6/17/19 4:22 PM, Jon Masters wrote:
>> + For kernel code that has been identified where data pointers could
>> + potentially be influenced for Spectre attacks, new "nospec" accessor
>> + macros are used to prevent speculative loading of data.
>
> Mayb
Hi Tim,
Nice writeup. A few suggestions inline.
On 6/17/19 3:11 PM, Tim Chen wrote:
> +In Spectre variant 2 attacks, the attacker can steer speculative indirect
> +branches in the victim to gadget code by poisoning the branch target
> +buffer of a CPU used for predicting indirect branch addresse
On 3/20/19 2:28 AM, Greg KH wrote:
> On Wed, Mar 20, 2019 at 02:14:09AM -0400, Jon Masters wrote:
>> On 3/20/19 1:06 AM, Greg KH wrote:
>>> On Tue, Mar 19, 2019 at 11:46:09PM -0400, Jon Masters wrote:
>>>> On 2/13/19 2:52 PM, Greg KH wrote:
>>>>> On
On 3/20/19 1:06 AM, Greg KH wrote:
> On Tue, Mar 19, 2019 at 11:46:09PM -0400, Jon Masters wrote:
>> On 2/13/19 2:52 PM, Greg KH wrote:
>>> On Wed, Feb 13, 2019 at 02:25:12PM -0500, Sasha Levin wrote:
>>
>>>> So really, it sounds like a low hanging fruit: we
On 2/13/19 2:52 PM, Greg KH wrote:
> On Wed, Feb 13, 2019 at 02:25:12PM -0500, Sasha Levin wrote:
>> So really, it sounds like a low hanging fruit: we don't really need to
>> write much more testing code code nor do we have to refactor existing
>> test suites. We just need to make sure the right t
On 10/5/18 4:55 PM, Moger, Babu wrote:
> The public specification for this feature is available at
> https://www.amd.com/system/files/TechDocs/56375_Quality_of_Service_Extensions.pdf
404 error
On 9/7/18 5:34 AM, Jirka Hladky wrote:
> We would also be more than happy to test the new patches for the
> performance - please let us know if you are interested. We have a
> pool of 1 NUMA up to 8 NUMA boxes for that, both AMD and Intel,
> covering different CPU generations from Sandy Bridge ti
On 9/7/18 5:39 PM, Jan H. Schönherr wrote:
> The collective context switch from one coscheduled set of tasks to another
> -- while fast -- is not atomic. If a use-case needs the absolute guarantee
> that all tasks of the previous set have stopped executing before any task
> of the next set starts
Quick reply: I agree, I'm just supporting this :)
--
Computer Architect
> On Oct 2, 2018, at 11:43, Jiri Kosina wrote:
>
> On Tue, 2 Oct 2018, Jon Masters wrote:
>
>>> This patch provides an application property based spectre_v2
>>> protection with STIBP a
On 9/19/18 5:35 PM, Tim Chen wrote:
> This patch provides an application property based spectre_v2
> protection with STIBP against attack from another app from
> a sibling hyper-thread. For security sensitive non-dumpable
> app, STIBP will be turned on before switching to it for Intel
> processors
Tnx
--
Computer Architect
> On Sep 13, 2018, at 11:52, Will Deacon wrote:
>
>> On Fri, Sep 07, 2018 at 02:36:08AM -0400, Jon Masters wrote:
>>> On 09/05/2018 08:28 AM, Will Deacon wrote:
>>>> On Tue, Sep 04, 2018 at 02:38:02PM -0400, Jon Masters wrote:
&
On 09/05/2018 08:28 AM, Will Deacon wrote:
> On Tue, Sep 04, 2018 at 02:38:02PM -0400, Jon Masters wrote:
>> On 08/24/2018 11:52 AM, Will Deacon wrote:
>>
>>> I hacked up this RFC on the back of the recent changes to the mmu_gather
>>> stuff in mainline. It&#x
On 08/24/2018 11:52 AM, Will Deacon wrote:
> I hacked up this RFC on the back of the recent changes to the mmu_gather
> stuff in mainline. It's had a bit of testing and it looks pretty good so
> far.
I will request the server folks go and test this. You'll probably
remember a couple of parts we'v
On 03/13/2018 08:36 PM, Daniel Kurtz wrote:
> AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a special
> earlycon setup handler to configure its input clock in order to compute
> baud rate divisor registers.
> Detect them by examining the OEMID field in the SPCR header, and pass
> t
Hi Bjorn,
It looks like the AER driver won’t do a device FLR but instead will default to
progressively bigger hammers. Am I missing something?
Jon.
--
Computer Architect | Sent from my 64-bit #ARM Powered phone
On 02/14/2018 11:16 AM, Timur Tabi wrote:
> On Wed, Feb 14, 2018 at 7:53 AM, wrote:
>>
>> This is a note to let you know that I've just added the patch titled
>>
>> [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for
>> Falkor
>>
>> to the 4.14-stable tree which can be fou
On 02/12/2018 07:17 PM, Florian Fainelli wrote:
> On 02/12/2018 04:10 PM, Timur Tabi wrote:
>> On 02/12/2018 05:57 PM, Florian Fainelli wrote:
>>> That is debatable, is there a good publicly available table of what the
>>> typical L1 cache line size is on ARMv8 platforms?
With a server hat on...
On 02/16/2018 07:10 AM, David Woodhouse wrote:
> On Fri, 2018-02-16 at 12:04 +0100, Paolo Bonzini wrote:
>> On 16/02/2018 11:21, David Woodhouse wrote:
>>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the
>>> (now emulated) MSR on every kernel entry/exit, that's *still* going t
On 02/02/2018 07:12 AM, Wang, Dongsheng wrote:
> Hey, Hanjun,
>
> On 2018/2/2 19:54:24, "Hanjun Guo" wrote:
>
>> On 2018/2/2 18:25, Yang Shunyong wrote:
>>> Loading IORT table from initrd is used to fix firmware IORT defects.
>>
>> I don't think this fix "firmware defects", it just for debug pur
Hi Bjorn, Rafael, others,
On 02/15/2018 06:39 PM, Bjorn Helgaas wrote:
> On Thu, Feb 15, 2018 at 10:57:25PM +0100, Rafael J. Wysocki wrote:
>> On Wednesday, February 14, 2018 9:16:53 PM CET Bjorn Helgaas wrote:
>>> On Wed, Feb 14, 2018 at 04:58:08PM +0530, George Cherian wrote:
On 02/13/2018
Hi Marc, all,
On 02/06/2018 12:56 PM, Marc Zyngier wrote:
> ARM has recently published a SMC Calling Convention (SMCCC)
> specification update[1] that provides an optimised calling convention
> and optional, discoverable support for mitigating CVE-2017-5715. ARM
> Trusted Firmware (ATF) has alread
Hi Peter, David, all,
First a quick note on David's earlier comment, about this optimization
being still up for debate. The problem with this optimization as-is is
that it doesn't protect userspace-to-userspace unless applications are
rebuilt and we get the infrastructure to handle that (ELF, what
On 01/07/2018 04:48 PM, Thomas Gleixner wrote:
> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t
On 01/22/2018 06:33 AM, Will Deacon wrote:
> On Fri, Jan 19, 2018 at 04:22:47AM -0800, Jayachandran C wrote:
>> Use PSCI based mitigation for speculative execution attacks targeting
>> the branch predictor. We use the same mechanism as the one used for
>> Cortex-A CPUs, we expect the PSCI version c
On 01/22/2018 06:41 AM, Will Deacon wrote:
> On Fri, Jan 19, 2018 at 04:22:48AM -0800, Jayachandran C wrote:
>> Whitelist Broadcom Vulcan/Cavium ThunderX2 processors in
>> unmap_kernel_at_el0(). These CPUs are not vulnerable to
>> CVE-2017-5754 and do not need KPTI when KASLR is off.
>>
>> Signed-o
On 01/19/2018 07:22 AM, Jayachandran C wrote:
> Use PSCI based mitigation for speculative execution attacks targeting
> the branch predictor. We use the same mechanism as the one used for
> Cortex-A CPUs, we expect the PSCI version call to have a side effect
> of clearing the BTBs.
>
> Signed-off-
Hi JC, Will,
On 01/18/2018 06:28 PM, Jayachandran C wrote:
> On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote:
>> On 01/18/2018 12:56 PM, Jayachandran C wrote:
>>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote:
>>> I think in this case we have
On 01/09/2018 05:00 AM, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote:
>> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote:
>>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote:
On Mon, Jan 08, 2018 at 09:20:09AM +, Marc Zyngie
On 01/18/2018 12:56 PM, Jayachandran C wrote:
> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote:
>> Hi JC,
>>
>> On Tue, Jan 16, 2018 at 03:45:54PM -0800, Jayachandran C wrote:
>>> On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote:
>>>&
On 01/16/2018 06:45 PM, Jayachandran C wrote:
> On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote:
>> On 01/09/2018 07:47 AM, Jayachandran C wrote:
>>
>>> Use PSCI based mitigation for speculative execution attacks targeting
>>> the branch predictor. T
On 01/17/2018 07:41 AM, Jiri Kosina wrote:
> On Wed, 17 Jan 2018, Martin Schwidefsky wrote:
>
>> Implement nospec_load() and nospec_ptr() for s390 with the new
>> gmb() barrier between the boundary condition and the load that
>> may not be done speculatively.
Thanks for the patches, Martin et al.
On 01/09/2018 07:47 AM, Jayachandran C wrote:
> Use PSCI based mitigation for speculative execution attacks targeting
> the branch predictor. The approach is similar to the one used for
> Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
> test if the firmware supports the capabil
On 01/09/2018 07:47 AM, Jayachandran C wrote:
> Use PSCI based mitigation for speculative execution attacks targeting
> the branch predictor. The approach is similar to the one used for
> Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
> test if the firmware supports the capabili
On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote:
> On Fri, 12 Jan 2018, Andi Kleen wrote:
>>> Skylake still loses if it takes an SMI, right?
>>
>> SMMs are usually rare, especially on servers, and are usually
>> not very predictible, and even if you have
>
> FWIW, a data point: SMIs can
On 01/09/2018 03:05 AM, Greg KH wrote:
> On Tue, Jan 09, 2018 at 01:06:23AM -0500, Jon Masters wrote:
>> Knowing that the IBM team was going to post with this sysfs interface,
>> our trees contain the rfi_flush file. I mentioned it to some folks on
>> this end (because we know
On 01/08/2018 05:09 PM, Michael Ellerman wrote:
> Thomas Gleixner writes:
>
>> On Tue, 9 Jan 2018, Michael Ellerman wrote:
>>
>> Sorry, I wasn't aware about your efforts and did not cc you. I've just
>> queued a more generic sysfs interface for this whole mess:
>
> No worries.
>
>> https://lkml
On 01/05/2018 08:12 AM, Will Deacon wrote:
> Aliasing attacks against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
>
> This patch adds initial skeleton code behind a new Kconfig o
On 01/04/2018 07:54 PM, Thomas Gleixner wrote:
> On Thu, 4 Jan 2018, Jon Masters wrote:
>> P.S. I've an internal document where I've been tracking "nice to haves"
>> for later, and one of them is whether it makes sense to tag binaries as
>> "trusted&q
On 01/04/2018 02:57 PM, Jon Masters wrote:
> + Jeff Law, Nick Clifton
>
> On 01/04/2018 03:20 AM, Woodhouse, David wrote:
>> On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote:
>>> On 04/01/2018 02:59, Alan Cox wrote:
>>>>> But then, exactly because
On 01/04/2018 01:33 PM, Linus Torvalds wrote:
> On Thu, Jan 4, 2018 at 3:26 AM, Pavel Machek wrote:
>> On Wed 2018-01-03 15:51:35, Linus Torvalds wrote:
>>>
>>> A *competent* CPU engineer would fix this by making sure speculation
>>> doesn't happen across protection domains. Maybe even a L1 I$ tha
+ Jeff Law, Nick Clifton
On 01/04/2018 03:20 AM, Woodhouse, David wrote:
> On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote:
>> On 04/01/2018 02:59, Alan Cox wrote:
But then, exactly because the retpoline approach adds quite some cruft
and leaves something to be desired, why even b
On 12/08/2017 09:29 AM, Prarit Bhargava wrote:
> If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR
> configured:
>
> [root@prarit-lab ~]# dmesg | grep SPCR
> [0.00] ACPI: SPCR 0x69031000 50 (v01
> )
>
> AFAICT the SPCR is always e
f-by: Tom Lendacky
Tested-by: Jon Masters
--
Computer Architect | Sent from my Fedora powered laptop
On 10/31/2017 02:30 PM, Mark Salyzyn wrote:
> Take an effort to recode the arm64 vdso code from assembler to C
> previously submitted by Andrew Pinski , rework
> it for use in both arm and arm64, overlapping any optimizations
> for each architecture. But instead of landing it in arm64, land the
> r
On 10/12/2017 03:48 PM, Jeremy Linton wrote:
> ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
> used to describe the processor and cache topology. Ideally it is
> used to extend/override information provided by the hardware, but
> right now ARM64 is entirely dependent on fi
On 10/17/2017 02:58 AM, Christoph Hellwig wrote:
> On Tue, Oct 10, 2017 at 10:37:51PM -0700, Radha Mohan Chintakuntla wrote:
>> From: Radha Mohan Chintakuntla
>>
>> This patch adds support for Cavium's fifth generation SATA controller.
>> It is an on-chip controller and complies with AHCI 1.3.1. A
On 10/06/2017 12:39 PM, Ard Biesheuvel wrote:
> Some implementations of the Synopsys DesignWare PCIe controller implement
> a so-called ECAM shift mode, which allows a static memory window to be
> configured that covers the configuration space of the entire bus range.
Side note that we gave a pres
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 countles
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 /sys/de
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 en
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 th
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 RFC
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 pan
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 05:17:3
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
z.
--
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.
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)
> ===
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 pho
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 sett
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 dma_sync_single_for_device(
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 strin
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 differen
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.
>
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 (
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 ThunderX2
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.
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
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
rm that a 4.11 machine
previously experiencing an issue has stable VMs with these.
Tested-by: Jon Masters
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 o
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 shouldn&
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.
>>
>> Signe
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. Curren
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 user
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 be
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 Ryz
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
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 suppo
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
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 structure
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 i
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. Likewi
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
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 b
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 12
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
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 devic
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
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"
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 comp
1 - 100 of 417 matches
Mail list logo
