Hi John,
On 14/10/2019 16:18, John Garry wrote:
> I'm experimenting by trying to boot an allmodconfig arm64 kernel, as
> mentioned here:
Crumbs!
> One thing that I noticed - it's hard to miss actually - is the amount of
> complaining from
> KASAN about the EDAC/ghes code. Maybe this is someth
ful.
>
> Fixes: 82869ac57b5d ("arm64: kernel: Add support for
> hibernate/suspend-to-disk")
>
> Signed-off-by: Pavel Tatashin
> ---
Reviewed-by: James Morse
Thanks,
James
er-letter ascii art]
Signed-off-by: James Morse
---
The suspicious __sched annotation here is to stop this symbol from
appearing in wchan. I haven't managed to make this happen, but I
can't see what stops it.
Previous version:
https://lore.kernel.org/linux-arm-kernel/20191010163447.1360
Hi Will,
On 15/10/2019 21:07, Will Deacon wrote:
> Patch looks good apart from one thing...
>
> On Tue, Oct 15, 2019 at 06:25:44PM +0100, James Morse wrote:
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 2c2e56bd8913..67a1d86981a9 100644
>>
err(&pdev->dev,
> + "failed to register to irq %d (%d)\n",
> + al_pos->irq, ret);
> + goto err_remove_edac;
> + }
> + }
> +
> + return 0;
> +
> +err_remove_edac:
> + edac_device_del_device(edac_dev->dev);
> +err_free_edac:
> + edac_device_free_ctl_info(edac_dev);
> +
> + return ret;
> +}
With the edac_dev-leak fixed and the -/_ in MAINTAINERS:
Reviewed-by: James Morse
Thanks,
James
Hi Heyi,
On 09/10/2019 13:33, Guoheyi wrote:
> On 2019/10/2 1:19, James Morse wrote:
>> On 24/09/2019 16:20, Heyi Guo wrote:
>>> As more SMC/HVC usages emerge on arm64 platforms, like SDEI, it makes
>>> sense for kvm to have the capability of forwarding such calls to
Hi Lei,
On 18/10/2019 21:08, Lei Wang wrote:
> This thread hasn't got traction from DT owners.
It looks like your patches didn't make it to the mailing list:
https://lore.kernel.org/r/by5pr04mb6599eaa659a53b2331cb812586...@by5pr04mb6599.namprd04.prod.outlook.com
You can search on https://lore.ke
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 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.
>
> http://lists.infradead.org/pipermail/linux
device *dev = &pdev->dev;
> + int ret;
> +
> + edac_dev = edac_device_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
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
19 07:26:24 +
Subject: [PATCH] arm64: Add workaround for Fujitsu A64FX 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 perform
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 co
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
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 oc
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 information
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
when
Hi Peter,
On 14/01/2019 13:16, Peter Zijlstra wrote:
> On Fri, Jan 11, 2019 at 06:32:58PM +0000, James Morse wrote:
>> On 10/01/2019 20:12, Peter Zijlstra wrote:
>>> On Thu, Jan 10, 2019 at 06:25:57PM +, James Morse wrote:
>>> The thing is, everything non-maskable (
Hi guys,
On 14/01/2019 16:12, Julien Thierry wrote:
> On 14/01/2019 15:56, Catalin Marinas wrote:
>> On Tue, Jan 08, 2019 at 02:07:19PM +, Julien Thierry wrote:
>>> When using VHE, the host needs to clear HCR_EL2.TGE bit in order
>>> to interract with guest TLBs, switching from EL2&0 translati
is as its where do_debug_exception() lives, which kprobes
depends on for single-stepping.
Reviewed-by: James Morse
Thanks!
James
Hello,
On 15/01/2019 06:25, Masami Hiramatsu wrote:
> Use arch_populate_kprobe_blacklist() instead of
> arch_within_kprobe_blacklist() so that we can see the full
> blacklisted symbols under the debugfs.
> diff --git a/arch/arm64/kernel/probes/kprobes.c
> b/arch/arm64/kernel/probes/kprobes.c
> in
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
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
-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
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 +5
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 r
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 mech
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 to
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 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
>> b/Documentation/devicetree/bindings/edac/sifive-edac-
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.
&
> + int ret;
> +
> + sifive_pdev = platform_device_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
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 is
convention in 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_sever
mpatible(child, "altr,sdram-edac-a10"))
> of_platform_populate(pdev->dev.of_node,
>altr_sdram_ctrl_of_match,
>NULL, &pdev->dev);
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 at
cpu_cache = of_find_next_cache_node(cpu);
> + l2_cache = of_parse_phandle(dev->of_node, "l2-cache", 0);
> +
> + if (cpu_cache == l2_cache)
> + cpumask_set_cpu(i, &al_l2->cluster_cpus);
You need to of_node_put() these device_node pointers once you're done with them.
> + }
> +
> + if (cpumask_empty(&al_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
nt(type, e->msg, e->label, e->error_count,
> mci->mc_idx, e->top_layer, e->mid_layer, e->low_layer,
> (e->page_frame_number << PAGE_SHIFT) | e->offset_in_page,
> -grain_bits, e->syndrome, pvt->detail_l
ret <= 0 \) )
> {
> (
> -if (ret != -EPROBE_DEFER)
> -{ ...
> -dev_err(...);
> -... }
> |
> ...
> -dev_err(...);
> )
> ...
> }
> //
> While we're here, remove braces on if statements that only have one
> statement (manually).
Reviewed-by: James Morse
Thanks,
James
r);
> }
>
> /* Error grain */
>
After a shorter game of spot-the-difference:
Reviewed-by: James Morse
Previously here:
https://lore.kernel.org/linux-edac/e566fe1d-ed06-53bc-6827-f6dfa32ee...@arm.com/
Please pick up tags when posting a new version.
If you don't do this, its very difficult to convince people to spend time
reviewing your
series.
Thanks,
James
Hi Robert,
On 24/06/2019 16:09, 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 SM
e PSR_DAIF_MASK(PSR_D_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 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 a/arch
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 ca
n-kernel dependency, 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: J
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.
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 actua
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 afte
ered; ++intr_index) {
> + int irq_id = platform_get_irq(pdev, intr_index);
> + devm_free_irq(&pdev->dev, irq_id, mci);
> + }
> + edac_mc_del_mc(&pdev->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
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
>>> memb
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 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 D
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
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,
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 ap
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
>> integration-
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
to msecs_to_jiffies().
Reviewed-by: James Morse
Thanks,
James
terrupts may have
> different ways to be wired to physical interrupt lines. As in the above
> link, in this particular brcm implementation:
>
> 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_in
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: expo
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.:
> /sy
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 inf
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 fa
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 exce
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 breakpoi
Hi!
On 08/01/2019 02:39, Masami Hiramatsu wrote:
> On Thu, 3 Jan 2019 17:05:18 +
> James Morse wrote:
>> On 17/12/2018 06:40, Masami Hiramatsu wrote:
>>> Move extable address check into arch_prepare_kprobe() from
>>> arch_within_kprobe_blacklist().
>>
&
Hi Boris, Wladislav,
On 08/01/2019 10:42, Borislav Petkov wrote:
> + James and leaving in the rest for reference.
(thanks!)
> So the first thing to figure out here is how generic is this and if
> so, to make it a cortex_a15_edac.c driver which contains all the RAS
> functionality for A15. Defini
Hi Greg,
On 01/08/2019 06:12 PM, gre...@linuxfoundation.org wrote:
On Tue, Jan 08, 2019 at 05:57:24PM +, James Morse wrote:
diff --git a/drivers/edac/cortex_a15_l2_async_edac.c
b/drivers/edac/cortex_a15_l2_async_edac.c
new file mode 100644
index ..26252568e961
--- /dev/null
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, D
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
> b/Docu
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 av
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
> --- /d
Hi Longman, Zhenzhong,
On 10/01/2019 14:43, Waiman Long wrote:
> On 01/10/2019 03:02 AM, Zhenzhong Duan wrote:
>> There is a question confused me for days. Appreciate an answer.
>>
>> In below code, the comment says we never have more than 4 nested
>> contexts.
>>
>> What happen if debug and mce e
Hi Wladislav,
On 09/01/2019 14:44, Wiebe, Wladislav (Nokia - DE/Ulm) wrote:
>> From: James Morse
>> Sent: Tuesday, January 08, 2019 6:57 PM
>> On 08/01/2019 10:42, Borislav Petkov wrote:
>>> So the first thing to figure out here is how generic is this
Hi,
On 09/01/2019 02:05, Masami Hiramatsu wrote:
> On Tue, 8 Jan 2019 17:13:36 +
> James Morse wrote:
>> On 08/01/2019 02:39, Masami Hiramatsu wrote:
>>> On Thu, 3 Jan 2019 17:05:18 +
>>> James Morse wrote:
>>>> On 17/12/2018 06:40, Masami H
Hi Peter,
On 10/01/2019 20:12, Peter Zijlstra wrote:
> On Thu, Jan 10, 2019 at 06:25:57PM +0000, James Morse wrote:
>
>> On arm64 if all the RAS and psuedo-NMI patches land, our worst-case
>> interleaving
>> jumps to at least 7. The culprit is APEI using spinlocks to
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> The cpu_enable callback for VHE feature requires all alternatives to have
> been applied. This prevents applying VHE alternative separately from the
> rest.
>
> Use an alternative depending on VHE feature to know whether VHE
> alternatives hav
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> From: Daniel Thompson
>
> Currently alternatives are applied very late in the boot process (and
> a long time after we enable scheduling). Some alternative sequences,
> such as those that alter the way CPU context is stored, must be applied
>
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> Masking daif flags is done very early before returning to EL0.
>
> Only toggle the interrupt masking while in the vector entry and mask daif
> once in kernel_exit.
I had an earlier version that did this, but it showed up as a performance
prob
lude to that
in the commit message)
Either way,
Acked-by: James Morse
Hi Julien,
On 12/09/18 12:11, Julien Thierry wrote:
> On 12/09/18 11:32, James Morse wrote:
>> On 28/08/18 16:51, Julien Thierry wrote:
>>> For EL0 entries requiring bp_hardening, daif status is kept at
>>> DAIF_PROCCTX_NOIRQ until after hardening has been done. Then
"msrdaif, %0// local_daif_restore"
> - :
> - : "r" (flags)
> - : "memory");
> +
> + arch_local_irq_restore(flags);
And I thought this only messed with the I bit, which it clearly doesn't.
Thanks for fixing these!
Reviewed-by: James Morse
Hi Brice,
On 13/09/18 06:51, Brice Goglin wrote:
> Le 12/09/2018 à 11:49, Sudeep Holla a écrit :
>>> Yes. Without this change, we hit the lscpu error in the commit message,
>>> and get zero output about the system. We don't even get information
>>> about the caches which are architecturally spec
Hi Jun,
On 13/09/18 11:50, Jun Yao wrote:
> On Fri, Sep 07, 2018 at 10:58:22AM +0100, James Morse wrote:
>> On 22/08/18 10:54, Jun Yao wrote:
>>> WRITE_ONCE(*pmdp, pmd);
>>> dsb(ishst);
>>> }
>>> @@ -480,6 +511,19 @@ static inline phys_addr_
Hi Jun,
On 10/09/18 12:41, Jun Yao wrote:
> On Fri, Sep 07, 2018 at 10:58:22AM +0100, James Morse wrote:
>> On 22/08/18 10:54, Jun Yao wrote:
>>> WRITE_ONCE(*pmdp, pmd);
>>> dsb(ishst);
>>> }
>>> @@ -480,6 +511,19 @@ static inline phys_addr_
apper_pg_dir during paging_init().
Could you add v3's
| Add init_pg_dir to vmlinux.lds.S and boiler-plate
| clearing/cleaning/invalidating it in head.S.
too. This makes it obvious that 'init_pg_dir isn't used yet' is deliberate.
Reviewed-by: James Morse
Some boring nits:
>
Hi Jun,
(I'm a bit confused about which version of this series I should be looking at.
I have a v4, and two v4-resends, all of which are different. Please only mark
something as 'resend' if it is exactly the same!)
On 22/08/18 10:54, Jun Yao wrote:
> The set_init_mm_pgd() is reimplemented using
// load TTBR1
> isb
> @@ -791,7 +793,7 @@ ENDPROC(__enable_mmu)
>
> __no_granule_support:
> /* Indicate that this CPU can't boot and is stuck in the kernel */
> - update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x1, x2
> + u
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> As the initial page table is created in the init_pg_dir, we can set
> up the final page table directly in the swapper_pg_dir. And it only> contains
> the top level page table, so we can reduce it to a page
Reviewed-by: James Morse
Thanks,
James
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> Create the initial page table in the init_pg_dir. And before
> calling kasan_early_init(), we update the init_mm.pgd by
> introducing set_init_mm_pgd(). This will ensure that pgd_offset_k()
> works correctly. When the final page table is created, we redi
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete. In this way, w
Hi Mark,
On 24/09/18 17:36, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>> Since we will move the swapper_pg_dir to rodata section, we need a
>> way to update it. The fixmap can handle it. When the swapper_pg_dir
>> needs to be updated, we map it dynamically. The
Hi Mark,
On 01/10/18 11:41, James Morse wrote:
> On 24/09/18 17:36, Mark Rutland wrote:
>> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>>> Since we will move the swapper_pg_dir to rodata section, we need a
>>> way to update it. The fixmap can handle
Hi Mark,
On 24/09/18 14:34, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:30PM +0800, Jun Yao wrote:
>> Create the initial page table in the init_pg_dir. And update the
>> init_mm.pgd to make sure that pgd_offset_k() works correctly. When
>> the final page table is created, we redirect the i
| el0_svc_handler+0x7c/0x130
| el0_svc+0x8/0xc
| Code: 90007b60 f946e000 cb000273 b2400673 (f9000293)
| ---[ end trace 7bf2d2ffce498c7a ]---
| Kernel panic - not syncing: Fatal exception
The below patch fixes it: I'll post it properly shortly...
---%<-
swapper_pg_dir
during paging_init()[3].
For the series:
Reviewed-by: James Morse
Thanks,
James
Hi Fan,
On 30/08/18 15:40, wufan wrote:
>>> @@ -327,12 +349,20 @@ void ghes_edac_report_mem_error(int sev,
>> struct cper_sec_mem_err *mem_err)
>>> p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
>>> if (mem_err->validation_bits &
>> CPER_MEM_VALID_MODULE_HANDLE) {
>>>
Hi Boris,
On 30/08/18 11:43, Borislav Petkov wrote:
> On Wed, Aug 29, 2018 at 06:33:52PM +, Fan Wu wrote:
>> The current ghes_edac driver does not update per-dimm error
>> counters when reporting memory errors, because there is no
>> platform-independent way to find DIMMs based on the error
>>
Hi Zhengqiang,
On 29/08/18 19:33, Fan Wu wrote:
> The current ghes_edac driver does not update per-dimm error
> counters when reporting memory errors, because there is no
> platform-independent way to find DIMMs based on the error
> information provided by firmware. This patch offers a solution
>
Hi Fenghua,
On 27/08/18 15:22, Fenghua Yu wrote:
> On Fri, Aug 24, 2018 at 11:44:59AM +0100, James Morse wrote:
>> ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl
>> is the defacto ABI for this sort of thing, but it lives under arch/x86.
>>
>&g
301 - 400 of 707 matches
Mail list logo
