0);
> +
> + if (cpu_cache == l2_cache)
> + cpumask_set_cpu(i, _l2->cluster_cpus);
You need to of_node_put() these device_node pointers once you're done with them.
> + }
> +
> + if (cpumask_empty(_l2->cluster_cpus)) {
> + dev_err(dev, "CPU mask is empty for this L2 cache\n");
> + ret = -EINVAL;
> + goto err;
> + }
> +
> + ret = edac_device_add_device(edac_dev);
> + if (ret) {
> + dev_err(dev, "Failed to add L2 edac device\n");
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + edac_device_free_ctl_info(edac_dev);
> +
> + return ret;
> +}
With the of_node_put()ing:
Reviewed-by: James Morse
Thanks,
James
Hi Jiping,
(CC: +linux-arm-kernel)
On 31/07/2019 11:57, Steven Rostedt wrote:
> On Wed, 31 Jul 2019 17:04:37 +0800
> Jiping Ma wrote:
> Note, the subject is not properly written, as it is missing the
> subsystem. In this case, it should start with "tracing: "
>
>
>> The PC of one the frame
y.
>
> While other arch(s) like s390 and x86_64 already use this macro to
> initialize kexec_buf.mem with, arm64 uses an equivalent value of 0.
> Replace it with KEXEC_BUF_MEM_UNKNOWN, to keep the convention of
> initializing 'kxec_buf.mem' consistent across various archs.
Reviewed-by: James Morse
Thanks,
James
_alloc_ctl_info(0, (char *)dev_name(dev), 1, "L",
> + 1, 1, NULL, 0,
> + edac_device_alloc_index());
> + if (IS_ERR(edac_dev))
edac_device_alloc_ctl_info() returns NULL, or dev_ctl, which comes from
kzalloc(). I think
you need to check for NULL here, IS_ERR() only catches the -errno range. (there
is an
IS_ERR_OR_NULL() if you really needed both)
> + return -ENOMEM;
With the header-includes and edac_device_alloc_ctl_info() NULL check:
Reviewed-by: James Morse
Thanks,
James
Hi Chris,
On 12/07/2019 04:48, Chris Packham wrote:
> I still seem to be struggling to get this on anyone's radar.
Whose radar does it need to cross?
> The Reviews/Acks have been given so this should be good to go in via the ARM
> tree as planned.
>
>
width /= 2;
So the hardware's SDRAM_CONFIG_BUS_WIDTH value is wrong? Yuck.
Is it too late for the DTs on these two systems to provide a DT version of the
'bus_width'
to override the hardware's mis-advertised value?
This way you don't need to grow this list.
Acked-by: James Morse
Thanks,
James
Hi Pavel,
On 17/07/2019 20:13, Pavel Tatashin wrote:
>> After a quick skim:
>>
>> This will map 'nomap' regions of memory with cacheable attributes. This is a
>> non-starter.
>> These regions were described by firmware as having content that was/is
>> written with
>> different attributes. The
hild, "altr,sdram-edac-a10"))
> of_platform_populate(pdev->dev.of_node,
>altr_sdram_ctrl_of_match,
>NULL, >dev);
Acked-by: James Morse
Thanks,
James
the rest of the file is for the prefix format string to be
separate. i.e:
| "%s""aer_uncor_status: ..."
Could it be the same for consistency?
> +pfx, aer->uncor_status, aer->uncor_mask);
> + printk("%saer_uncor_severity: 0x%08x\n&q
Hi,
On 22/07/2019 08:48, Masami Hiramatsu wrote:
> Make debug exceptions visible from RCU so that synchronize_rcu()
> correctly track the debug exception handler.
>
> This also introduces sanity checks for user-mode exceptions as same
> as x86's ist_enter()/ist_exit().
>
> The debug exception
Hi,
On 22/07/2019 08:48, Masami Hiramatsu wrote:
> Prohibit probing on return_address() and subroutines which
> is called from return_address(), since the it is invoked from
> trace_hardirqs_off() which is also kprobe blacklisted.
(Nits: "which are called" and "since it is")
> diff --git
BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT)
We should probably move this to daifflags.h. Its going to be useful to other
series too.
Patch looks good!
Reviewed-by: James Morse
Tested-by: James Morse
(I haven't tried to test the nested kprobes case...)
Thanks,
James
Hi!
On 18/07/2019 06:43, Masami Hiramatsu wrote:
> On arm64, if a nested kprobes hit, it can crash the kernel with below
> error message.
>
> [ 152.118921] Unexpected kernel single-step exception at EL1
>
> This is because commit 7419333fa15e ("arm64: kprobe: Always clear
> pstate.D in
Hi,
On 7/18/19 3:31 PM, Masami Hiramatsu wrote:
On Thu, 18 Jul 2019 10:20:23 +0100
Mark Rutland wrote:
On Wed, Jul 17, 2019 at 11:22:15PM -0700, Paul E. McKenney wrote:
On Thu, Jul 18, 2019 at 02:43:58PM +0900, Masami Hiramatsu wrote:
Remove rcu_read_lock()/rcu_read_unlock() from debug
Hi Tyler,
On 11/07/2019 05:14, Tyler Baicar OS wrote:
> On Tue, Jul 9, 2019 at 8:52 PM Tyler Baicar OS
> wrote:
>> On Mon, Jul 8, 2019 at 10:10 AM James Morse wrote:
>>> On 02/07/2019 17:51, Tyler Baicar OS wrote:
>>>> @@ -632,6 +633,8 @@ static int do_sea
Hi,
On 08/07/2019 15:11, Anders Roxell wrote:
> argh... resending, with plaintext... Sorry =/
>
> I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
> CONFIG_KPROBES_SANITY_TEST=y
>
> I get the following Call trace, any ideas?
> I've tried tags back to next-20190525 and they also
Hey Tyler,
On 02/07/2019 17:51, Tyler Baicar OS wrote:
> On systems that support the ARM RAS extension, synchronous external
> abort syndrome information could be captured in the core's RAS extension
> system registers. So, when handling SEAs check the RAS system registers
> for error syndrome
Hi,
On 04/07/2019 00:59, Yi Wang wrote:
> From: Junhua Huang
>
> We should free the reserved memblock in an aligned manner
> because the initrd reserves the memblock in an aligned manner
> in arm64_memblock_init().
> Otherwise there are some fragments in memblock_reserved regions. e.g.:
>
Hi,
(CC: +devicetree list:
memreserving the initrd, which linux then frees causes a zombie memreserve in
all future
kexec'd kernels)
On 03/07/2019 12:42, huang.jun...@zte.com.cn wrote:
On 02/07/2019 11:34, Yi Wang wrote:
> From: Junhua Huang
> The 'commit 50d7ba36b916 ("arm64:
gt; Line 841: source dram_ecc_errc_int
> Line 843: source dram_ecc_errd_int
> Line 839: source dram_ecc_errc_int and dram_ecc_errd_int
>
> Two straightforward possibilities for implementing ecc counts for ce/ue:
> 1. We chose to use the single source line. 2. It's possible to
Hi,
On 03/07/2019 10:16, huang.jun...@zte.com.cn wrote:
>> On 02/07/2019 11:34, Yi Wang wrote:
>>> From: Junhua Huang
>>> The 'commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
>>> /proc/iomem")'
>>> show the reserved memblock in /proc/iomem. But the initrd's reserved
>>>
devm_free_irq(>dev, irq_id, mci);
> + }
> + edac_mc_del_mc(>dev);
> +err_free_mc:
> + edac_mc_free(mci);
> +
> + return ret;
> +}
> +
[...]
> +static const struct of_device_id dmc520_edac_driver_id[] = {
> + { .compatible = "brcm,dmc-520", },
> + { .compatible = "arm,dmc-520", },
You should only need the "arm,dmc-520" entry here. The additional compatible
values are
for quirking the driver when integration issues are discovered.
The 'brcm' version should be in the DT from day-one, but the kernel only needs
to pick it
up when it needs to treat the brcm version differently.
> + { /* end of table */ }
> +};
With the bool/enum and interrupt-disabling things fixed:
Reviewed-by: James Morse
Thanks,
James
[0]
https://static.docs.arm.com/10/0200/corelink_dmc520_trm_10_0200_01_en.pdf
Hello,
On 02/07/2019 11:34, Yi Wang wrote:
> From: Junhua Huang
>
> The 'commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
> /proc/iomem")'
> show the reserved memblock in /proc/iomem. But the initrd's reserved memblock
> will be freed in free_initrd_mem(), which executes
nce to msecs_to_jiffies().
Reviewed-by: James Morse
Thanks,
James
Hi Robert,
On 20/06/2019 07:55, Robert Richter wrote:
> On 19.06.19 18:22:32, James Morse wrote:
>>> In any case, this patch cleans up code as old API's counter code is
>>> isolated and moved to common code. Making the counter's work for ghes
>>> is actually a
On 24/06/2019 16:09, Robert Richter wrote:
> James Morse: "I'm all for removing/warning-its-broken it when
> ghes_edac is in use."
Thanks for taking that out of context. The very next word was 'but':
http://lore.kernel.org/r/c08290d8-3690-efa9-3bc7-37f8b1fdb...@arm.com
fol
ependency, move the cacheinfo
work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN
work runs.
Fixes: 2264d9c74dda1 ("x86/intel_rdt: Build structures for each resource based
on cache topology")
Cc:
Cc: Fenghua Yu
Cc: Reinette Chatre
Signed-off-by: James Morse
---
goto err;
> + }
> +
> + mci->pdev = dev;
> + mci->mtype_cap = MEM_FLAG_DDR4 | MEM_FLAG_RDDR4 |
> + MEM_FLAG_LRDDR4 | MEM_FLAG_NVDIMM;
> + mci->edac_ctl_cap = EDAC_FLAG_SECDED;
> +
> + mci->mod_name = DRIVER_NAME;
> + mci->ctl_name = "BlueField_Memory_Controller";
> + mci->dev_name = dev_name(dev);
> + mci->edac_check = bluefield_edac_check;
> +
> + /* Initialize mci with the actual populated DIMM information. */
> + bluefield_edac_init_dimms(mci);
> +
> + platform_set_drvdata(pdev, mci);
> +
> + /* Register with EDAC core */
> + rc = edac_mc_add_mc(mci);
> + if (rc) {
> + dev_err(dev, "failed to register with EDAC core\n");
> + ret = rc;
> + goto err;
> + }
> +
> + /* Only POLL mode supported so far. */
> + edac_op_state = EDAC_OPSTATE_POLL;
> + return 0;
> +
> +err:
> + edac_mc_free(mci);
> +
> + return ret;
> +
> +}
With the MLXBF_EDAC_MAX_DIMM_PER_MC check and offset_in_page()/~PAGE_MASK:
Reviewed-by: James Morse
Thanks,
James
[0]
https://static.docs.arm.com/den0028/b/ARM_DEN0028B_SMC_Calling_Convention.pdf
Hi Hawa,
On 17/06/2019 14:00, Hawa, Hanna wrote:
>> I don't think it can, on a second reading, it looks to be even more
>> complicated than I
>> thought! That bit is described as disabling forwarding of uncorrected data,
>> but it looks
>> like the uncorrected data never actually reaches the
Hi Robert,
On 12/06/2019 19:41, Robert Richter wrote:
> On 29.05.19 16:13:02, James Morse wrote:
>> On 29/05/2019 09:44, Robert Richter wrote:
>>> The ghes driver is not able yet to count legacy API counters in sysfs,
>>> e.g.:
>>>
>>> /sys/devices
Hi Zenghui,
On 13/06/2019 12:28, Zenghui Yu wrote:
> On 2019/6/12 20:49, James Morse wrote:
>> On 12/06/2019 10:08, Zenghui Yu wrote:
>>> Currently, we use trace_kvm_exit() to report exception type (e.g.,
>>> "IRQ", "TRAP") and exception class (E
ded.
To the maintainer's scripts its going to look like this:
https://lore.kernel.org/lkml/byapr21mb131946e0b469e74d6054c33390...@byapr21mb1319.namprd21.prod.outlook.com/raw
> -Original Message-
> From: James Morse
> On 16/05/2019 03:55, Lei Wang wrote:
>> New dri
Hi Hawa,
On 13/06/2019 18:05, James Morse wrote:
> On 11/06/2019 20:56, Hawa, Hanna wrote:
>> James Morse wrote:
>>> Hawa, Hanna wrote:
>>>> + if (cluster != last_cluster) {
>>>> + smp_call_function_single(cpu, al_a57_edac_l2merrsr,
Hi Hawa,
On 11/06/2019 20:56, Hawa, Hanna wrote:
> James Morse wrote:
>> Hawa, Hanna wrote:
>>> + edac_device_handle_ce(edac_dev, 0, 0, "L2 Error");
>>
>> How do we know this was corrected?
>>
>> 6.4.8 "Error Correction Code" has &q
Hi Chen Zhou,
On 13/06/2019 12:27, Chen Zhou wrote:
> On 2019/6/6 0:32, James Morse wrote:
>> On 07/05/2019 04:50, Chen Zhou wrote:
>>> We use crashkernel=X to reserve crashkernel below 4G, which will fail
>>> when there is no enough memory. Currently, crashkernel=Y@X
Commit-ID: 87d3aa28f345bea77c396855fa5d5fec4c24461f
Gitweb: https://git.kernel.org/tip/87d3aa28f345bea77c396855fa5d5fec4c24461f
Author: James Morse
AuthorDate: Mon, 3 Jun 2019 18:25:31 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 12 Jun 2019 10:31:50 +0200
x86/resctrl: Don't stop
Hi guys,
On 06/06/2019 12:37, Shenhar, Talel wrote:
>>> Disagree. The various drivers don't depend on each other.
>>> I think we should keep the drivers separated as they are distinct and
>>> independent IP
>>> blocks.
>> But they don't exist in isolation, they both depend on the
>>
Hi Bhupesh,
(sorry for the delay on this)
On 04/05/2019 13:53, Bhupesh Sharma wrote:
> On 04/03/2019 11:24 PM, Bhupesh Sharma wrote:
>> On 04/02/2019 10:56 PM, James Morse wrote:
>>> Yes the kernel code is going to move around, this is why the information we
>>> expo
Hi,
On 06/06/2019 14:08, Sasha Levin wrote:
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: dfe9674b04ff x86/intel_rdt: Enable entering of
> pseudo-locksetup mode.
>
> The bot has tested the following trees: v5.1.7, v5.0.21, v4.19.48.
> v5.1.7: Failed to
this I wrongly assumed ct_user_exit() should be run with
interrupts
masked, but that isn't what you're saying).
Reviewed-by: James Morse
Thanks,
James
Hi George,
On 05/06/2019 15:12, George Hung wrote:
> Add device tree documentation for Nuvoton BMC ECC
(Nit: The DT folk prefer patches adding bindings to come first in the series,
before the
driver that uses them).
> diff --git a/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
Hi George,
On 05/06/2019 15:12, George Hung wrote:
> Add support for the Nuvoton NPCM7xx SoC EDAC driver
Could you say something about what the NPCM7xx SoC is, and what errors its
memory
controller can detect?
The commit message is for describing what/why this code was added.
Is this Cadence
Hi Hawa,
On 06/06/2019 08:53, Hawa, Hanna wrote:
> On 5/31/2019 8:14 AM, Borislav Petkov wrote:
>> On Fri, May 31, 2019 at 01:15:33AM +, Herrenschmidt, Benjamin wrote:
>>> This isn't terribly helpful, there's nothing telling anybody which of
>>> those files corresponds to an ARM SoC :-)
>>
>>
Hi Hana,
On 30/05/2019 11:15, Hanna Hawa wrote:
> Add support for error detection and correction for Amazon's Annapurna
> Labs SoCs for L1/L2 caches.
>
> Amazon's Annapurna Labs SoCs based on ARM CA57 and CA72, the driver
> support both cortex based on compatible string.
> diff --git
Hi guys,
On 31/05/2019 06:14, Borislav Petkov wrote:
> On Fri, May 31, 2019 at 01:15:33AM +, Herrenschmidt, Benjamin wrote:
>> This isn't terribly helpful, there's nothing telling anybody which of
>> those files corresponds to an ARM SoC :-)
>
> drivers/edac/altera_edac.c is one example.
>
Hi Thor,
(CC: +Mark, Lorenzo and Sudeep for PSCI.
How should SYSTEM_RESET2 be used for a vendor-specific reset?
The original patch is:
lore.kernel.org/r/1559594269-10077-1-git-send-email-thor.tha...@linux.intel.com
)
On 03/06/2019 21:37, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
Hi Robert,
On 03/06/2019 14:10, Robert Richter wrote:
> On 29.05.19 16:12:38, James Morse wrote:
>> On 29/05/2019 09:44, Robert Richter wrote:
>>> Almost duplicate code, remove it.
>>
>>> Note: there is a difference in the calculation of the grain_bits,
>
Hi Junhan,
On 30/05/2019 19:48, Junhan Zhou wrote:
>> -Original Message-
>> From: James Morse
>> Sent: Thursday, May 23, 2019 1:30 PM
>> To: Junhan Zhou
>>> +union mlxbf_emi_dram_additional_info_0 {
>>> + struct {
>>> +
while the resource group is in 'pseudo-locksetup'
mode." When we find a pseudo_locksetup group, its configuration is
expected to be overwritten, we can skip it.
Fixes: dfe9674b04ff6 ("x86/intel_rdt: Enable entering of pseudo-locksetup mode")
Cc:
Acked-by: Reinette Chatre
Signed
ependency, move the cacheinfo
work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN
work runs.
Cc: Fenghua Yu
Cc: Reinette Chatre
Signed-off-by: James Morse
---
I haven't seen any problems because of this. If someone thinks it should
go to stable:
Cc: #4.10.x
The particu
while the resource group is in 'pseudo-locksetup'
mode." When we find a pseudo_locksetup group, its configuration is
expected to be overwritten, we can skip it.
Fixes: dfe9674b04ff6 ("x86/intel_rdt: Enable entering of pseudo-locksetup mode")
Signed-off-by: James Morse
---
arch/x8
Hi Robert,
On 29/05/2019 09:44, Robert Richter wrote:
> In a later patch we want to have one mc device per node. This patch
> extracts the numa node information for each dimm. This is done by
> collecting the physical address ranges from the DMI table (Memory
> Array Mapped Address - Type 19 of
Hi Robert,
On 29/05/2019 09:44, Robert Richter wrote:
> Use standard macros for page calculations.
Reviewed-by: James Morse
Thanks,
James
ayer = -1;
> e->mid_layer = -1;
> e->low_layer = -1;
> - *pvt->other_detail = '\0';
> + e->msg = pvt->msg;
> + e->other_detail = pvt->other_detail;
> +
> *pvt->msg = '\0';
> + *pvt->other_detail = '\0';
... so no change? Could you drop this hunk?
Regardless,
Reviewed-by: James Morse
Thanks,
James
Hi Robert,
On 29/05/2019 09:44, Robert Richter wrote:
> The ghes driver is not able yet to count legacy API counters in sysfs,
> e.g.:
>
> /sys/devices/system/edac/mc/mc0/csrow2/ce_count
> /sys/devices/system/edac/mc/mc0/csrow2/ch0_ce_count
>
Hi Robert,
On 29/05/2019 09:44, Robert Richter wrote:
> Almost duplicate code, remove it.
almost?
> Note: there is a difference in the calculation of the grain_bits,
> using the edac_mc's version here.
But is it the right thing to do?
Is this an off-by-one bug being papered over as some
Hi Robert,
On 29/05/2019 09:44, Robert Richter wrote:
> In a later patch we want add more information about the memory
> hierarchy (NUMA topology, DIMM label information). Rework memory
> hierarchy detection to make the code extendable for this.
>
> The general approach is roughly like:
>
>
Hi Junhan,
On 21/03/2019 14:31, Junhan Zhou wrote:
> Add ECC support for Mellanox BlueField SoC DDR controller.
> This requires SMC to the running Arm Trusted Firmware to report
> what is the current memory configuration.
Sorry for the delay on this, it slipped through the cracks. (Please don't
Hi Lei,
(CC: +Rui Zhao)
On 16/05/2019 03:55, Lei Wang wrote:
> New driver supports error detection and correction on the devices with ARM
> DMC-520 memory controller.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7d1246b..23894ac 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5573,6
-520", "arm,dmc-520";
> + reg = <0x20 0x8>;
> + interrupts = <0x0 0x349 0x4>, <0x0 0x34B 0x4>;
> + interrupt-config = <0x4>, <0x8>;
> +};
>
For what its worth:
Acked-by: James Morse
Thanks,
James
Still fine by me:
Reviewed-by: James Morse
(...this patch already has my reviewed-by on it...)
I commented that it couldn't be merged in pieces here:
https://lore.kernel.org/lkml/4072c812-d3bf-9ad5-2b30-6b2a5060b...@arm.com/T/#u
which is what Yash is replying to.
Thanks,
James
Hi!
On 16/05/2019 17:48, Hsin-Yi Wang wrote:
> On Thu, May 16, 2019 at 11:32 PM Rob Herring wrote:
>> Doesn't kexec operate on a copy because it already does modifications.
It does!
> This patch is to assist "[PATCH v3 3/3] fdt: add support for rng-seed"
>
Hi André,
On 14/05/2019 20:40, André Przywara wrote:
> On 14/05/2019 18:20, James Morse wrote:
>> On 10/05/2019 18:39, Andre Przywara wrote:
>>> On Sat, 9 Feb 2019 18:50:39 -0800
>>> Fenghua Yu wrote:
>>>> From: Babu Moger
>>>>
>>>&g
Hi Fenghua,
On 10/05/2019 20:20, Yu, Fenghua wrote:
>> On Friday, May 10, 2019 10:36 AM
>> Andre Przywara [mailto:andre.przyw...@arm.com] wrote:
>> On Sat, 9 Feb 2019 18:50:29 -0800
>> Fenghua Yu wrote:
>>> With more and more resctrl features are being added by Intel, AMD and
>>> ARM, a test
Hi Andre,
(thanks for digging into this!)
On 10/05/2019 18:39, Andre Przywara wrote:
> On Sat, 9 Feb 2019 18:50:39 -0800
> Fenghua Yu wrote:
>> From: Babu Moger
>>
>> RESCTRL feature is supported both on Intel and AMD now. Some features
>> are implemented differently. Add vendor detection
e_register_simple(DRVNAME, 0, NULL, 0);
> + if (IS_ERR(sifive_pdev))
> + return PTR_ERR(sifive_pdev);
> +
> + ret = ecc_register(sifive_pdev);
> + if (ret)
> + platform_device_unregister(sifive_pdev);
> +
> + return ret;
> +}
> +
> +static void __exit sifive_edac_exit(void)
> +{
> + ecc_unregister(sifive_pdev);
> + platform_device_unregister(sifive_pdev);
> +}
Looks good to me. I think this patch should go with its two dependencies, I'm
not sure why
it got split off...
Reviewed-by: James Morse
Thanks,
James
ei_smccc_hvc);
>
> int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *normal_cb,
> sdei_event_callback *critical_cb)
Thanks for making this more robust!
Reviewed-by: James Morse
Thanks,
James
[0]
http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
Hi Xiongfeng Wang,
On 12/04/2019 13:04, Xiongfeng Wang wrote:
> When we monitor a sdei_event callback using 'kprobe', the singlestep
> handler can not be called because dbg is masked in sdei_handler.
For a good reason: the debug hardware may be in use single-stepping the kernel,
or worse:
in
Hi Xiongfeng Wang,
On 12/04/2019 13:04, Xiongfeng Wang wrote:
> When I use kprobe to monitor a sdei event handler,
Don't do this! SDEI is like an NMI, it isn't safe to kprobe it as it can
interrupt the
kprobe code, causing it become re-entrant.
> the CPU will hang. It's
> because when I probe
Hi Roy,
On 01/04/2019 20:09, Roy Pledge wrote:
> I'm trying to understand if memory reserved in the device tree via the
> "reserved-memory" facility is preserved during a kexec system call,
> i.e., is the memory at the same location with the contents undisturbed
> when the new kernel starts?
If
Hi Rob,
On 29/03/2019 14:11, Rob Herring wrote:
> On Thu, Mar 28, 2019 at 1:47 PM James Morse wrote:
>> On 28/03/2019 13:16, Rob Herring wrote:
>>> On Tue, Mar 12, 2019 at 02:51:00PM +0530, Yash Shah wrote:
>>>> DT documentation for L2 cache controller added.
&
Hi Rob, Yash,
On 28/03/2019 13:16, Rob Herring wrote:
> On Tue, Mar 12, 2019 at 02:51:00PM +0530, Yash Shah wrote:
>> DT documentation for L2 cache controller added.
>> diff --git a/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt
>>
Hi Rui,
On 07/03/2019 01:24, Rui Zhao wrote:
> From: Rui Zhao
> New driver supports error detection and correction on
> the devices with ARM DMC-520 memory controller.
> diff --git a/drivers/edac/dmc520_edac.c b/drivers/edac/dmc520_edac.c
> new file mode 100644
> index 000..c70ce4e
> ---
Hi guys,
On 23/03/2019 09:23, Borislav Petkov wrote:
> On Thu, Mar 07, 2019 at 01:24:01AM +, Rui Zhao wrote:
>> From: Rui Zhao
>>
>> New driver supports error detection and correction on
>> the devices with ARM DMC-520 memory controller.
A question/suggestion on the direction...
Could we
Hi Rui,
On 07/03/2019 01:24, Rui Zhao wrote:
> From: Rui Zhao
> dt-bindings for new EDAC driver dmc520_edac.c.
(minor nit, the DT folk prefer the binding to come first in the series, this
makes it
easier to review)
> diff --git a/Documentation/devicetree/bindings/edac/arm-dmc520.txt
>
-off-by: James Morse
Tested-by: zhang.lei
---
(and since posted inline: removed the stray ; on
MIDR_FUJITSU_ERRATUM_010001_MASK)
Changes since [v4]
* Generated MIDR value/mask for __cpu_setup(),
* removed spurious-fault handler,
* always disabled the NFDx bits on affected CPUs
Changes since
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> According to userspace settings, ptrauth key registers are conditionally
> present in guest system register list based on user specified flag
> KVM_ARM_VCPU_PTRAUTH.
>
> Reset routines still sets these registers to default values but
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> This feature will allow the KVM guest to allow the handling of
> pointer authentication instructions or to treat them as undefined
> if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
> supply this parameter instead of
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
>
> Pointer
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> This patch series adds pointer authentication support for KVM guest and
> is based on top of Linux 5.0-rc6. The basic patches in this series was
> originally posted by Mark Rutland earlier[1,2] and contains some history
> of this work.
>
Hi Amit,
On 25/02/2019 17:39, James Morse wrote:
> On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
>> From: Mark Rutland
>> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
>> is a constant value. This works today, as the host HCR_EL2 value
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will get in the way of supporting
Hi Zhang,
On 23/02/2019 13:06, Zhang, Lei wrote:
> Zhang, Lei wrote:
>> I think you mean it may be a problem to modify the KPTI trampoline because
>> some patches about KPTI will be merged to mainline in the near future.
>> I understood that.
>> I should discuss with my colleagues whether we can
Hi!
On 18/02/2019 13:59, Will Deacon wrote:
> [+James, who knows how to decode these things]
Decode is a strong term!
This stuff is printed by Cavium's secure-world software. All I'm doing is
spotting the
bits that vary between the out we've seen!
> On Mon, Feb 18, 2019 at 02:56:47PM +0100,
erratum 010001
On the Fujitsu-A64FX cores ver(1.0, 1.1), memory access may cause
an undefined fault (Data abort, DFSC=0b11). This fault occurs under
a specific hardware condition when a load/store instruction performs an
address translation. Any load/store instruction, except non-fault acce
Hi Rui,
On 23/01/2019 22:08, Rui Zhao wrote:
> On Wednesday, January 23, 2019 10:36 AM, James Morse wrote:
>>> If firmware enables it, they're suppose to handle the interrupt.
>> Ah, so you still have resident firmware!
>> How come your firmware trusts linux not to turn o
Hi Boris,
On 23/01/2019 18:46, Borislav Petkov wrote:
> On Wed, Jan 23, 2019 at 06:36:23PM +0000, James Morse wrote:
>>> Would like to know what's the impact if this error happens, and how to fit
>>> it
>>> with current reporting in EDAC core.
>>
>&
Hi guys,
On 05/02/2019 08:38, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Add James to the list of reviewers of the firmware-assisted RAS glue.
Fine by me,
Acked-by: James Morse
Thanks,
James
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
>
> Pointer authentication feature is
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> This feature will allow the KVM guest to allow the handling of
> pointer authentication instructions or to treat them as undefined
> if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
> supply this parameter instead of
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will get in the way of supporting extensions
> that require HCR_EL2
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> The keys can be switched either inside an assembly or such
> functions which do not have pointer authentication checks, so a GCC
> attribute is added to enable it.
>
> A function ptrauth_keys_store is added which is similar to existing
>
Hi Amit,
On 09/01/2019 10:13, Amit Daniel Kachhap wrote:
> On Sat, Jan 5, 2019 at 12:05 AM James Morse wrote:
>> On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
>>> This feature will allow the KVM guest to allow the handling of
>>> pointer authentication in
Hi!
On 01/29/2019 12:29 PM, Zhang, Lei wrote:
On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1),
memory accesses may cause undefined fault (Data abort, DFSC=0b11).
This problem will be fixed by next version of Fujitsu-A64FX.
This fault occurs under a specific hardware condition
Hi guys,
On 01/29/2019 06:10 PM, Catalin Marinas wrote:
Could you please copy the whole description from the cover letter to the
actual patch and only send one email (full description as in here
together with the patch)? If we commit this to the kernel, it would be
useful to have the
f necessary when returning to the interrupted context.
Yes please. This would not have been fun to debug!
Reviewed-by: James Morse
I was looking for why we need core code to do this, instead of updating the
arch's call sites. Your 'irqdesc: Add domain handlers for NMIs' patch (pointed
to from the
Hi Rui,
On 23/01/2019 00:42, Rui Zhao wrote:
> On Monday, January 21, 2019 9:09 AM, James Morse wrote:
>> It would be good if we can make this generic, so it works on all platforms
>> with
>> a DMC520, possibly along with other components. (e.g. the a15 L2 driver
Hello,
On 22/01/2019 02:05, Zhang, Lei wrote:
> Mark Rutland wrote:
>> * How often does this fault occur?
> In my test, this fault occurs once every several times
> in the OS boot sequence, and after the completion of OS boot,
> this fault have never occurred.
> In my opinion, this fault rarely
Hi Boris,
On 21/01/2019 12:39, Borislav Petkov wrote:
> From: Borislav Petkov
>
> With the growing amount of ARM[,64] EDAC enablement happening, add James
> as a reviewer for the ARM bits.
Sure,
> Signed-off-by: Borislav Petkov
Acked-by: James Morse
Thanks,
James
Hi Sasha, Rui,
On 18/01/2019 16:23, Sasha Levin wrote:
> From: Rui Zhao
> New driver supports DRAM error detection and correction on DMC520
> controller.
> Validated on actual hardware: DRAM errors showed up once the DDR core
> voltage was lowered down by 200+mV using test tool.
That's quite
201 - 300 of 1082 matches
Mail list logo
