* next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)
From: Sudeep Holla @ 2018-06-19 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619141324.GD11230@sirena.org.uk>
On 19/06/18 15:13, Mark Brown wrote:
> On Tue, Jun 19, 2018 at 07:00:13AM -0700, kernelci.org bot wrote:
>
> Today and yesterday's -next is failing to boot on rk3399-firefly in two
> configs:
>
>> defconfig:
>> rk3399-firefly:
>> lab-baylibre-seattle: failing since 1 day (last pass: next-20180615 - first fail: next-20180618)
>
>> defconfig+CONFIG_RANDOMIZE_BASE=y:
>> rk3399-firefly:
>> lab-baylibre-seattle: failing since 1 day (last pass: next-20180615 - first fail: next-20180618)
>
> The log ends with:
>
> [ 2.629278] SWITCH_REG2: supplied by vcc3v3_sys
> [ 2.633030] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
> [ 2.633723] fan53555-reg: supplied by vcc_sys
> [ 2.6353|] Internal error: undefined instruction: 0 [#1] PREEMPT SMP
>
> which is rather entertaining.
>
Based on the logs from successful boots, I see it's CPUFreq that gets
probed after fan53555-reg. I also see that it warns about unlisted OPPs
in the successful boots. I guess, the undefined instruction could occur
if there's issue with CPU DVFS(under voltage or frequency that's not
supported). I don't have much knowledge on the platform, I am just
guessing on the possible cause here.
--
Regards,
Sudeep
^ permalink raw reply
* [linux-sunxi] [PATCH v3 4/4] arm64: dts: allwinner: a64: add SRAM controller device tree node
From: Icenowy Zheng @ 2018-06-19 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZCsPXh7Fhmhtd7UjTmJ9id+NeaZDVqkix1iQz7-fDqoUw@mail.gmail.com>
? 2018?6?19? GMT+08:00 ??3:36:19, Jagan Teki <jagan@amarulasolutions.com> ??:
>On Fri, Jun 15, 2018 at 4:39 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>
>>
>> ? 2018?6?15? GMT+08:00 ??1:27:21, "Jernej ?krabec"
><jernej.skrabec@gmail.com> ??:
>>>Dne ?etrtek, 14. junij 2018 ob 19:09:56 CEST je Jagan Teki
>napisal(a):
>>>> On Thu, Jun 14, 2018 at 9:05 PM, Chen-Yu Tsai <wens@csie.org>
>wrote:
>>>> > From: Icenowy Zheng <icenowy@aosc.io>
>>>> >
>>>> > Allwinner A64 has a SRAM controller, and in the device tree
>>>currently
>>>> > we have a syscon node to enable EMAC driver to access the EMAC
>>>clock
>>>> > register. As SRAM controller driver can now export regmap for
>this
>>>> > register, replace the syscon node to the SRAM controller device
>>>node,
>>>> > and let EMAC driver to acquire its EMAC clock regmap.
>>>> >
>>>> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> > [wens at csie.org: Updated compatible string]
>>>> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>>> > ---
>>>> >
>>>> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19
>>>+++++++++++++++++--
>>>> > 1 file changed, 17 insertions(+), 2 deletions(-)
>>>> >
>>>> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
>>>> > 1b2ef28c42bd..87968dafe1dc 100644
>>>> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> > @@ -169,9 +169,24 @@
>>>> >
>>>> > ranges;
>>>> >
>>>> > syscon: syscon at 1c00000 {
>>>> >
>>>> > - compatible =
>>>> > "allwinner,sun50i-a64-system-controller", -
>>>
>>>> > "syscon";
>>>> > + compatible =
>>>> > "allwinner,sun50i-a64-system-control";
>>>> >
>>>> > reg = <0x01c00000 0x1000>;
>>>> >
>>>> > + #address-cells = <1>;
>>>> > + #size-cells = <1>;
>>>> > + ranges;
>>>> > +
>>>> > + sram_c: sram at 18000 {
>>>> > + compatible = "mmio-sram";
>>>> > + reg = <0x00018000 0x28000>;
>>>> > + #address-cells = <1>;
>>>> > + #size-cells = <1>;
>>>> > + ranges = <0 0x00018000 0x28000>;
>>>> > +
>>>> > + de2_sram: sram-section at 0 {
>>>>
>>>> So, this can attach to display-engine node through allwinner,sram
>and
>>>> add support to claim the sram on sun4i/sun4i_drv.c, correct?
>>>
>>>Actually, it has to be added to display_clocks node and claimed in
>>>drivers/
>>>clk/sunxi-ng/ccu-sun8i-de2.c
>>
>> Sorry it's old practice.
>>
>> My new way is to add a bus driver which claims the SRAM.
>
>Are you pointing this driver[1] ? if yes do we have recent version
>patches for these changes so-that I can import.
I'll resend it when this patchset is ready.
>
>[1] https://patchwork.kernel.org/patch/10290399/
^ permalink raw reply
* [PATCHv3 09/19] arm64: convert syscall trace logic to C
From: Catalin Marinas @ 2018-06-19 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-10-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:00PM +0100, Mark Rutland wrote:
> +asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> + syscall_fn_t syscall_table[])
> +{
> + unsigned long flags = current_thread_info()->flags;
> +
> + regs->orig_x0 = regs->regs[0];
> + regs->syscallno = scno;
> +
> + local_daif_restore(DAIF_PROCCTX);
> + user_exit();
> +
> + if (has_syscall_work(flags)) {
> + /* set default errno for user-issued syscall(-1) */
> + if (scno == NO_SYSCALL)
> + regs->regs[0] = -ENOSYS;
> + scno = syscall_trace_enter(regs);
> + if (scno == NO_SYSCALL)
> + goto trace_exit;
> + }
> +
> + invoke_syscall(regs, scno, sc_nr, syscall_table);
> +
> + /*
> + * The tracing status may have changed under our feet, so we have to
> + * check again. However, if we were tracing entry, then we always trace
> + * exit regardless, as the old entry assembly did.
> + */
> + if (!has_syscall_work(flags)) {
> + local_daif_mask();
> + flags = current_thread_info()->flags;
> + if (!has_syscall_work(flags))
> + return;
> + local_daif_restore(DAIF_PROCCTX);
> + }
IIUC the above 'if' block replaces ret_fast_syscall in entry.S with the
work_pending handled via ret_to_user (we used to check _TIF_WORK_MASK in
two places).
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)
From: Mark Brown @ 2018-06-19 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <69c0adb9-b784-4f73-fcc9-ff1a01ce27c5@arm.com>
On Tue, Jun 19, 2018 at 03:22:47PM +0100, Sudeep Holla wrote:
> Based on the logs from successful boots, I see it's CPUFreq that gets
> probed after fan53555-reg. I also see that it warns about unlisted OPPs
> in the successful boots. I guess, the undefined instruction could occur
> if there's issue with CPU DVFS(under voltage or frequency that's not
> supported). I don't have much knowledge on the platform, I am just
> guessing on the possible cause here.
Yeah, that was my guess - either an out of spec voltage/frequency was
selected or the regulator isn't able to keep up with the voltage
transition or a load spike and the power browns out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/cd40b399/attachment.sig>
^ permalink raw reply
* [PATCH v3] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
From: Marc Zyngier @ 2018-06-19 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F37935@G01JPEXMBKW03>
Hi Lei,
On Tue, 19 Jun 2018 15:14:27 +0100,
"Zhang, Lei" <zhang.lei@jp.fujitsu.com> wrote:
>
> Hi shankerd, Marc
>
> I have one question.
>
> Does it means after GICR_CTLR.EnableLPI has been written to 1,
> if the bit GICR_CTLR.EnableLPI becomes RES1, we can't use LPIs?
> Because its_cpu_init_lpis and its_cpu_init_collections will not be called.
There are two issues:
- If EnableLPI is already set to 1, your redistributors are already
potentially corrupting the memory by writing to the pending
tables. Your system is now potentially unstable (single bit
corruption, depending on what the ITS outputs).
- If EnableLPI has become RES1, you cannot even turn it off to
reprogram things so that the property and pending tables are under
your control.
At that stage, your system is in a very bad shape, and LPIs are the
least of your problems.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCHv3 08/19] arm64: convert raw syscall invocation to C
From: Mark Rutland @ 2018-06-19 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619142125.esqcbknxd2pqeotb@localhost>
On Tue, Jun 19, 2018 at 03:21:25PM +0100, Catalin Marinas wrote:
> On Mon, Jun 18, 2018 at 01:02:59PM +0100, Mark Rutland wrote:
> > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > new file mode 100644
> > index 000000000000..b463b962d597
> > --- /dev/null
> > +++ b/arch/arm64/kernel/syscall.c
> > @@ -0,0 +1,30 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <linux/nospec.h>
> > +#include <linux/ptrace.h>
> > +
> > +long do_ni_syscall(struct pt_regs *regs);
> > +
> > +typedef long (*syscall_fn_t)(unsigned long, unsigned long,
> > + unsigned long, unsigned long,
> > + unsigned long, unsigned long);
> > +
> > +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> > +{
> > + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> > + regs->regs[2], regs->regs[3],
> > + regs->regs[4], regs->regs[5]);
> > +}
> > +
> > +asmlinkage void invoke_syscall(struct pt_regs *regs, unsigned int scno,
> > + unsigned int sc_nr,
> > + syscall_fn_t syscall_table[])
> > +{
> > + if (scno < sc_nr) {
> > + syscall_fn_t syscall_fn;
> > + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> > + __invoke_syscall(regs, syscall_fn);
> > + } else {
> > + regs->regs[0] = do_ni_syscall(regs);
> > + }
> > +}
>
> While reviewing the subsequent patch, it crossed my mind that we no
> longer have any callers to do_ni_syscall() outside this file. Can we not
> more it here and have a similar implementation to __invoke_syscall() for
> consistency, i.e. set regs->regs[0].
I think so, though it complicates the logic in do_ni_syscall(), since
there are two places we may return a value.
Would you be happy if instead I made __invoke_syscall() return the
result, and have invoke_syscall() place the result in regs->regs[0] in
either case, e.g. as below?
Thanks,
Mark.
---->8----
// SPDX-License-Identifier: GPL-2.0
#include <linux/errno.h>
#include <linux/nospec.h>
#include <linux/ptrace.h>
#include <linux/syscalls.h>
#include <asm/compat.h>
long compat_arm_syscall(struct pt_regs *regs);
static long do_ni_syscall(struct pt_regs *regs)
{
#ifdef CONFIG_COMPAT
long ret;
if (is_compat_task()) {
ret = compat_arm_syscall(regs);
if (ret != -ENOSYS)
return ret;
}
#endif
return sys_ni_syscall();
}
typedef long (*syscall_fn_t)(unsigned long, unsigned long,
unsigned long, unsigned long,
unsigned long, unsigned long);
static long __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
{
return syscall_fn(regs->regs[0], regs->regs[1], regs->regs[2],
regs->regs[3], regs->regs[4], regs->regs[5]);
}
asmlinkage void invoke_syscall(struct pt_regs *regs, unsigned int scno,
unsigned int sc_nr,
syscall_fn_t syscall_table[])
{
long ret;
if (scno < sc_nr) {
syscall_fn_t syscall_fn;
syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
ret = __invoke_syscall(regs, syscall_fn);
} else {
ret = do_ni_syscall(regs);
}
regs->regs[0] = ret;
}
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Punit Agrawal @ 2018-06-19 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619140818.GA16927@e107981-ln.cambridge.arm.com>
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> writes:
> On Tue, Jun 19, 2018 at 01:52:16PM +0100, Punit Agrawal wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>>
>> > On Tue 19-06-18 20:03:07, Xie XiuQi wrote:
>> > [...]
>> >> I tested on a arm board with 128 cores 4 numa nodes, but I set CONFIG_NR_CPUS=72.
>> >> Then node 3 is not be created, because node 3 has no memory, and no cpu.
>> >> But some pci device may related to node 3, which be set in ACPI table.
>> >
>> > Could you double check that zonelists for node 3 are generated
>> > correctly?
>>
>> The cpus in node 3 aren't onlined and there's no memory attached - I
>> suspect that no zonelists are built for this node.
>>
>> We skip creating a node, if the number of SRAT entries parsed exceeds
>> NR_CPUS[0]. This in turn prevents onlining the numa node and so no
>> zonelists will be created for it.
>>
>> I think the problem will go away if the cpus are restricted via the
>> kernel command line by setting nr_cpus.
>>
>> Xie, can you try the below patch on top of the one enabling memoryless
>> nodes? I'm not sure this is the right solution but at least it'll
>> confirm the problem.
>
> This issue looks familiar (or at least related):
>
> git log d3bd058826aa
Indeed. Thanks for digging into this.
>
> The reason why the NR_CPUS guard is there is to avoid overflowing
> the early_node_cpu_hwid array.
Ah right... I missed that. The below patch is definitely not what we
want.
> IA64 does something different in
> that respect compared to x86, we have to have a look into this.
>
> Regardless, AFAICS the proximity domains to nodes mappings should not
> depend on CONFIG_NR_CPUS, it seems that there is something wrong in that
> in ARM64 ACPI SRAT parsing.
Not only SRAT parsing but it looks like there is a similar restriction
while parsing the ACPI MADT in acpi_map_gic_cpu_interface().
The incomplete parsing introduces a dependency on the ordering of
entries being aligned between SRAT and MADT when NR_CPUS is
restricted. We want to parse the entire table in both cases so that the
code is robust to reordering of entries.
In terms of $SUBJECT, I wonder if it's worth taking the original patch
as a temporary fix (it'll also be easier to backport) while we work on
fixing these other issues and enabling memoryless nodes.
^ permalink raw reply
* [PATCH 5/5] RFC: ARM64: dts: Add Low-Speed Connector to ZCU100
From: Rob Herring @ 2018-06-19 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-6-linus.walleij@linaro.org>
+David G
On Mon, Jun 18, 2018 at 1:45 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This adds the low-speed connector to the ZCU100 rev C device
> tree (also known as the Ultra96 board).
>
> This is a proof-of-concept only, showing how it is possible
> to populate a Secure96 board using the other patches in the
> series.
>
> If you comment out or delete the board {} node, you can
> populate/depopulate the board from sysfs instead.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../boot/dts/xilinx/zynqmp-zcu100-revC.dts | 27 +++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> index d62276e0e0a9..fc30497f248d 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> @@ -110,6 +110,28 @@
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&gpio 7 GPIO_ACTIVE_LOW>; /* WIFI_EN */
> };
> +
> + lscon: connector {
> + compatible = "96boards,low-speed-connector";
> + i2c0 = <&i2csw_0>;
> + i2c1 = <&i2csw_1>;
> + spi = <&spi0>;
David had suggested having an aliases node here for mapping things
like SPI and I2C. That actually seems like a good use for aliases
compared to the usual abuse to make Linux provide fixed numbering.
> + gpios = <&gpio 36 GPIO_ACTIVE_HIGH>, /* GPIO-A */
Why aren't you using gpio-map? This is what it was defined for.
> + <&gpio 37 GPIO_ACTIVE_HIGH>, /* GPIO-B */
> + <&gpio 39 GPIO_ACTIVE_HIGH>, /* GPIO-C */
> + <&gpio 40 GPIO_ACTIVE_HIGH>, /* GPIO-D */
> + <&gpio 44 GPIO_ACTIVE_HIGH>, /* GPIO-E */
> + <&gpio 45 GPIO_ACTIVE_HIGH>, /* GPIO-F */
> + <&gpio 78 GPIO_ACTIVE_HIGH>, /* GPIO-G */
> + <&gpio 79 GPIO_ACTIVE_HIGH>, /* GPIO-H */
> + <&gpio 80 GPIO_ACTIVE_HIGH>, /* GPIO-I */
> + <&gpio 81 GPIO_ACTIVE_HIGH>, /* GPIO-J */
> + <&gpio 82 GPIO_ACTIVE_HIGH>, /* GPIO-K */
> + <&gpio 83 GPIO_ACTIVE_HIGH>; /* GPIO-L */
> + board {
> + compatible = "96boards,secure96";
I'm all for putting things in the kernel/drivers for things we can't
nail down bindings for, but it really seems like you are punting all
the problems. Plus if we fully define how to handle the different
bindings, we'll likely end up with something different and
incompatible with what you have here.
Rob
^ permalink raw reply
* [PATCHv3 08/19] arm64: convert raw syscall invocation to C
From: Catalin Marinas @ 2018-06-19 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619144845.22mgd4req5cnp5tv@lakrids.cambridge.arm.com>
On Tue, Jun 19, 2018 at 03:48:45PM +0100, Mark Rutland wrote:
> On Tue, Jun 19, 2018 at 03:21:25PM +0100, Catalin Marinas wrote:
> > On Mon, Jun 18, 2018 at 01:02:59PM +0100, Mark Rutland wrote:
> > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > > new file mode 100644
> > > index 000000000000..b463b962d597
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/syscall.c
> > > @@ -0,0 +1,30 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +#include <linux/nospec.h>
> > > +#include <linux/ptrace.h>
> > > +
> > > +long do_ni_syscall(struct pt_regs *regs);
> > > +
> > > +typedef long (*syscall_fn_t)(unsigned long, unsigned long,
> > > + unsigned long, unsigned long,
> > > + unsigned long, unsigned long);
> > > +
> > > +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> > > +{
> > > + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> > > + regs->regs[2], regs->regs[3],
> > > + regs->regs[4], regs->regs[5]);
> > > +}
> > > +
> > > +asmlinkage void invoke_syscall(struct pt_regs *regs, unsigned int scno,
> > > + unsigned int sc_nr,
> > > + syscall_fn_t syscall_table[])
> > > +{
> > > + if (scno < sc_nr) {
> > > + syscall_fn_t syscall_fn;
> > > + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> > > + __invoke_syscall(regs, syscall_fn);
> > > + } else {
> > > + regs->regs[0] = do_ni_syscall(regs);
> > > + }
> > > +}
> >
> > While reviewing the subsequent patch, it crossed my mind that we no
> > longer have any callers to do_ni_syscall() outside this file. Can we not
> > more it here and have a similar implementation to __invoke_syscall() for
> > consistency, i.e. set regs->regs[0].
>
> I think so, though it complicates the logic in do_ni_syscall(), since
> there are two places we may return a value.
>
> Would you be happy if instead I made __invoke_syscall() return the
> result, and have invoke_syscall() place the result in regs->regs[0] in
> either case, e.g. as below?
It looks fine. Feel free to keep the original reviewed-by tag.
--
Catalin
^ permalink raw reply
* [PATCH 15/20] dts: arm: imx7{d,s}: Update coresight binding for hardware ports
From: Mathieu Poirier @ 2018-06-19 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619021218.GV16091@dragon>
On Mon, 18 Jun 2018 at 20:13, Shawn Guo <shawnguo@kernel.org> wrote:
>
> Hi Stefan,
>
> Can you take a look at the patch? Thanks.
>
These bindings are still being discussed and patches related to them
shouldn't be merged. The next iteration of this patchset will not
included individual modifications to device tree files, that will be
left for a later time when bindings have been agreed upon.
Thanks,
Mathieu
> Shawn
>
> On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
> > Switch to the updated coresight bindings.
> >
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > ---
> > arch/arm/boot/dts/imx7d.dtsi | 5 ++++-
> > arch/arm/boot/dts/imx7s.dtsi | 41 ++++++++++++++++++++++++++++++-----------
> > 2 files changed, 34 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> > index 200714e..5faff17 100644
> > --- a/arch/arm/boot/dts/imx7d.dtsi
> > +++ b/arch/arm/boot/dts/imx7d.dtsi
> > @@ -87,7 +87,9 @@
> >
> > port {
> > etm1_out_port: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&ca_funnel_in_port1>;
> > + coresight,hwid = <0>;
> > };
> > };
> > };
> > @@ -174,8 +176,9 @@
> > port at 1 {
> > reg = <1>;
> > ca_funnel_in_port1: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&etm1_out_port>;
> > + coresight,hwid = <1>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> > index 4d42335..8e90915 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -151,23 +151,28 @@
> > port at 0 {
> > reg = <0>;
> > replicator_out_port0: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&tpiu_in_port>;
> > + coresight,hwid = <0>;
> > };
> > };
> >
> > port at 1 {
> > reg = <1>;
> > replicator_out_port1: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&etr_in_port>;
> > + coresight,hwid = <1>;
> > };
> > };
> >
> > /* replicator input port */
> > port at 2 {
> > - reg = <0>;
> > + reg = <2>;
> > replicator_in_port0: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&etf_out_port>;
> > + coresight,hwid = <0>;
> > };
> > };
> > };
> > @@ -203,16 +208,19 @@
> > port at 0 {
> > reg = <0>;
> > ca_funnel_in_port0: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&etm0_out_port>;
> > + coresight,hwid = <0>;
> > };
> > };
> >
> > /* funnel output port */
> > port at 2 {
> > - reg = <0>;
> > + reg = <2>;
> > ca_funnel_out_port0: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&hugo_funnel_in_port0>;
> > + coresight,hwid = <0>;
> > };
> > };
> >
> > @@ -229,7 +237,9 @@
> >
> > port {
> > etm0_out_port: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&ca_funnel_in_port0>;
> > + coresight,hwid = <0>;
> > };
> > };
> > };
> > @@ -248,22 +258,26 @@
> > port at 0 {
> > reg = <0>;
> > hugo_funnel_in_port0: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&ca_funnel_out_port0>;
> > + coresight,hwid = <0>;
> > };
> > };
> >
> > port at 1 {
> > reg = <1>;
> > hugo_funnel_in_port1: endpoint {
> > - slave-mode; /* M4 input */
> > + direction = <0>; /* M4 input */
> > + coresight,hwid = <1>;
> > };
> > };
> >
> > port at 2 {
> > - reg = <0>;
> > + reg = <2>;
> > hugo_funnel_out_port0: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&etf_in_port>;
> > + coresight,hwid = <0>;
> > };
> > };
> >
> > @@ -284,15 +298,18 @@
> > port at 0 {
> > reg = <0>;
> > etf_in_port: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&hugo_funnel_out_port0>;
> > + coresight,hwid = <0>;
> > };
> > };
> >
> > port at 1 {
> > - reg = <0>;
> > + reg = <1>;
> > etf_out_port: endpoint {
> > + direction = <1>;
> > remote-endpoint = <&replicator_in_port0>;
> > + coresight,hwid = <0>;
> > };
> > };
> > };
> > @@ -306,8 +323,9 @@
> >
> > port {
> > etr_in_port: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&replicator_out_port1>;
> > + coresight,hwid = <0>;
> > };
> > };
> > };
> > @@ -320,8 +338,9 @@
> >
> > port {
> > tpiu_in_port: endpoint {
> > - slave-mode;
> > + direction = <0>;
> > remote-endpoint = <&replicator_out_port1>;
> > + coresight,hwid = <0>;
> > };
> > };
> > };
> > --
> > 2.7.4
> >
^ permalink raw reply
* next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)
From: Heiko Stübner @ 2018-06-19 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619144143.GE11230@sirena.org.uk>
> > On Tue, Jun 19, 2018 at 07:00:13AM -0700, kernelci.org bot wrote:
> >
> > Today and yesterday's -next is failing to boot on rk3399-firefly in two
> >
> > configs:
> >> defconfig:
> >> rk3399-firefly:
> >> lab-baylibre-seattle: failing since 1 day (last pass:
> >> next-20180615 - first fail: next-20180618)>>
> >> defconfig+CONFIG_RANDOMIZE_BASE=y:
> >> rk3399-firefly:
> >> lab-baylibre-seattle: failing since 1 day (last pass:
> >> next-20180615 - first fail: next-20180618)>
> > The log ends with:
> >
> > [ 2.629278] SWITCH_REG2: supplied by vcc3v3_sys
> > [ 2.633030] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1]
> > Detected! [ 2.633723] fan53555-reg: supplied by vcc_sys
> > [ 2.6353|] Internal error: undefined instruction: 0 [#1] PREEMPT SMP
> >
> > which is rather entertaining.
> Am Dienstag, 19. Juni 2018, 16:41:43 CEST schrieb Mark Brown:
> On Tue, Jun 19, 2018 at 03:22:47PM +0100, Sudeep Holla wrote:
> > Based on the logs from successful boots, I see it's CPUFreq that gets
> > probed after fan53555-reg. I also see that it warns about unlisted OPPs
> > in the successful boots. I guess, the undefined instruction could occur
> > if there's issue with CPU DVFS(under voltage or frequency that's not
> > supported). I don't have much knowledge on the platform, I am just
> > guessing on the possible cause here.
>
> Yeah, that was my guess - either an out of spec voltage/frequency was
> selected or the regulator isn't able to keep up with the voltage
> transition or a load spike and the power browns out.
I guess this is related to
arm64: dts: rockchip: correct voltage selector Firefly-RK3399 [0]
which is in so far interesting as the patch seems to fix a similar issue
to the above with the opposite "fcs,suspend-voltage-selector" value.
And also claims to be in line with the vendor kernel.
>From looking at the schematics, we might have a discrepancy between the
fcs,suspend-voltage-selector and vsel input-pin leading to a gpio
[likely depending on what the bootloader set this pin up for].
I'll drop the patch for now and get in contact with the patch submitter.
Heiko
[0] https://patchwork.kernel.org/patch/10447075/
^ permalink raw reply
* [PATCHv3 08/19] arm64: convert raw syscall invocation to C
From: Mark Rutland @ 2018-06-19 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619145541.xi3yybejmbfenrum@armageddon.cambridge.arm.com>
On Tue, Jun 19, 2018 at 03:55:42PM +0100, Catalin Marinas wrote:
> On Tue, Jun 19, 2018 at 03:48:45PM +0100, Mark Rutland wrote:
> > On Tue, Jun 19, 2018 at 03:21:25PM +0100, Catalin Marinas wrote:
> > > On Mon, Jun 18, 2018 at 01:02:59PM +0100, Mark Rutland wrote:
> > > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > > > new file mode 100644
> > > > index 000000000000..b463b962d597
> > > > --- /dev/null
> > > > +++ b/arch/arm64/kernel/syscall.c
> > > > @@ -0,0 +1,30 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +#include <linux/nospec.h>
> > > > +#include <linux/ptrace.h>
> > > > +
> > > > +long do_ni_syscall(struct pt_regs *regs);
> > > > +
> > > > +typedef long (*syscall_fn_t)(unsigned long, unsigned long,
> > > > + unsigned long, unsigned long,
> > > > + unsigned long, unsigned long);
> > > > +
> > > > +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> > > > +{
> > > > + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> > > > + regs->regs[2], regs->regs[3],
> > > > + regs->regs[4], regs->regs[5]);
> > > > +}
> > > > +
> > > > +asmlinkage void invoke_syscall(struct pt_regs *regs, unsigned int scno,
> > > > + unsigned int sc_nr,
> > > > + syscall_fn_t syscall_table[])
> > > > +{
> > > > + if (scno < sc_nr) {
> > > > + syscall_fn_t syscall_fn;
> > > > + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> > > > + __invoke_syscall(regs, syscall_fn);
> > > > + } else {
> > > > + regs->regs[0] = do_ni_syscall(regs);
> > > > + }
> > > > +}
> > >
> > > While reviewing the subsequent patch, it crossed my mind that we no
> > > longer have any callers to do_ni_syscall() outside this file. Can we not
> > > more it here and have a similar implementation to __invoke_syscall() for
> > > consistency, i.e. set regs->regs[0].
> >
> > I think so, though it complicates the logic in do_ni_syscall(), since
> > there are two places we may return a value.
> >
> > Would you be happy if instead I made __invoke_syscall() return the
> > result, and have invoke_syscall() place the result in regs->regs[0] in
> > either case, e.g. as below?
>
> It looks fine. Feel free to keep the original reviewed-by tag.
Will do; cheers!
Mark.
^ permalink raw reply
* [PATCH v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem
From: James Morse @ 2018-06-19 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <72307608-90e0-4842-edc1-d3b284782940@oracle.com>
Hi Dave,
On 19/06/18 14:37, Dave Kleikamp wrote:
> On 06/19/2018 01:44 AM, AKASHI Takahiro wrote:
>> +static int __init reserve_memblock_reserved_regions(void)
>> +{
>> + phys_addr_t start, end, roundup_end = 0;
>> + struct resource *mem, *res;
>> + u64 i;
>> +
>> + for_each_reserved_mem_region(i, &start, &end) {
>> + if (end <= roundup_end)
>> + continue; /* done already */
>> +
>> + start = __pfn_to_phys(PFN_DOWN(start));
>> + end = __pfn_to_phys(PFN_UP(end)) - 1;
>> + roundup_end = end;
>> +
>> + res = kzalloc(sizeof(*res), GFP_ATOMIC);
>> + if (WARN_ON(!res))
>> + return -ENOMEM;
>> + res->start = start;
>> + res->end = end;
>> + res->name = "reserved";
>> + res->flags = IORESOURCE_MEM;
>> +
>> + mem = request_resource_conflict(&iomem_resource, res);
>> + /*
>> + * We expected memblock_reserve() regions to conflict with
>> + * memory created by request_standard_resources().
>> + */
>> + if (WARN_ON_ONCE(!mem))
>> + continue;
>> + kfree(res);
>
> Why is kfree() after the conditional continue? This is a memory leak.
request_resource_conflict() inserts res into the iomem_resource tree, or returns
the conflict if there is already something at this address.
We expect something at this address: a 'System RAM' section added by
request_resource(). This code wants the conflicting 'System RAM' entry so that
reserve_region_with_split() can fill in the gaps below it with 'reserved'. See
the commit-message for an example.
If there was no conflict, it means the memory map doesn't look like we expect,
we can't pass NULL to reserve_region_with_split(), and we just inserted the
'reserved' at the top level. Freeing res at this point would be a use-after-free
hanging from /proc/iomem.
This code generates a WARN_ON_ONCE() and leaves the 'reserved' description where
it is.
Trying to cleanup here is pointless, we can remove the resource entry and free
it ... but we still want to report it as reserved, which is what just happened,
just not quite how we we wanted it.
If you ever see this warning, it means some RAM stopped being nomap between
request_resources() and reserve_memblock_reserved_regions(). I can't find any
case where that ever happens.
If all that makes sense: how can I improve the comment above the WARN_ON_ONCE()
to make it clearer?
Thanks,
James
>> +
>> + reserve_region_with_split(mem, start, end, "reserved");
>> + }
>> +
>> + return 0;
>> +}
>> +arch_initcall(reserve_memblock_reserved_regions);
>> +
>> u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
>>
>> void __init setup_arch(char **cmdline_p)
>>
^ permalink raw reply
* [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation
From: Russell King - ARM Linux @ 2018-06-19 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-T8Fx3Nry7pUdOoOeRU-Ns89w3oo4itmu1q4FzYF5Rag@mail.gmail.com>
On Tue, Jun 19, 2018 at 03:35:07PM +0200, Ard Biesheuvel wrote:
> On 19 June 2018 at 15:29, Guenter Roeck <linux@roeck-us.net> wrote:
> > Hi Ard,
> >
> >
> > On 06/19/2018 12:48 AM, Ard Biesheuvel wrote:
> >>
> >> On 19 June 2018 at 07:07, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>
> >>> Modern assemblers may take the ISA into account when resolving local
> >>> symbols. This can result in bad address calculations when using badr
> >>> in the wrong location since the offset + 1 may be added twice, resulting
> >>> in an even address target for THUMB instructions. This in turn results
> >>> in an exception at (destination address + 2).
> >>>
> >>> Unhandled exception: IPSR = 00000006 LR = fffffff1
> >>> CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
> >>> Hardware name: MPS2 (Device Tree Support)
> >>> PC is at ret_fast_syscall+0x2/0x58
> >>> LR is at tty_ioctl+0x2a5/0x528
> >>> pc : [<21009002>] lr : [<210d1535>] psr: 4000000b
> >>> sp : 21825fa8 ip : 0000001c fp : 21a95892
> >>> r10: 00000000 r9 : 21824000 r8 : 210091c0
> >>> r7 : 00000036 r6 : 21ae1ee0 r5 : 00000000 r4 : 21ae1f3c
> >>> r3 : 00000000 r2 : 3d9adc25 r1 : 00000000 r0 : 00000000
> >>> xPSR: 4000000b
> >>> CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
> >>> Hardware name: MPS2 (Device Tree Support)
> >>> [<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc)
> >>> [<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c)
> >>>
> >>> Fix the problem by using a logical or instead of an addition. This is
> >>> less efficient but guaranteed to work.
> >>>
> >>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> >>> ---
> >>> RFC: I don't really like this, but my ARM assembler knowledge is quite
> >>> limited. Just dropping the "+ 1" from badr doesn't work because some
> >>> other code needs it (the image hangs completely if I try that).
> >>> Ultimately I don't even know if the invoke_syscall macro should just
> >>> have used adr instead of badr (but then how did this ever work ?).
> >>>
> >>> Seen with various toolchains based on gcc 7.x and binutils 2.30 when
> >>> building and testing MPS2 images.
> >>>
> >>
> >> Hello Guenter,
> >>
> >> This issue has been discussed before. It appears the binutils people
> >> suddenly started caring about the thumb annotation of local function
> >> symbols, resulting in behavior that is not backwards compatible.
> >>
> >> https://marc.info/?l=linux-arm-kernel&m=151143776213636&w=2
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=21458
> >>
> >> Can you try the fix below please?
> >>
> >>> arch/arm/include/asm/assembler.h | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/include/asm/assembler.h
> >>> b/arch/arm/include/asm/assembler.h
> >>> index 0cd4dccbae78..24c87ff2060f 100644
> >>> --- a/arch/arm/include/asm/assembler.h
> >>> +++ b/arch/arm/include/asm/assembler.h
> >>> @@ -195,7 +195,8 @@
> >>> .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> >>> .macro badr\c, rd, sym
> >>> #ifdef CONFIG_THUMB2_KERNEL
> >>> - adr\c \rd, \sym + 1
> >>> + adr\c \rd, \sym
> >>> + orr \rd, #1
> >>> #else
> >>> adr\c \rd, \sym
> >>> #endif
> >>> --
> >>> 2.7.4
> >>
> >>
> >> ----------8<------------
> >> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Date: Tue, 16 Jan 2018 12:12:45 +0000
> >> Subject: [PATCH] ARM: assembler: prevent ADR from setting the Thumb bit
> >> twice
> >>
> >> To work around recent issues where ADR references to Thumb function
> >> symbols may or may not have the Thumb bit set already when they are
> >> resolved by GAS, reference the symbol indirectly via a local symbol
> >> typed as 'object', stripping the ARM/Thumb annotation.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>
> >> diff --git a/arch/arm/include/asm/assembler.h
> >> b/arch/arm/include/asm/assembler.h
> >> index 6ae42ad29518..dd2ff94ad90b 100644
> >> --- a/arch/arm/include/asm/assembler.h
> >> +++ b/arch/arm/include/asm/assembler.h
> >> @@ -195,13 +195,19 @@
> >> .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> >> .macro badr\c, rd, sym
> >> #ifdef CONFIG_THUMB2_KERNEL
> >> - adr\c \rd, \sym + 1
> >> + __badr \c, \rd, \sym
> >> #else
> >> adr\c \rd, \sym
> >> #endif
> >> .endm
> >> .endr
> >>
> >> + /* this needs to be a separate macro or \@ does not work correctly
> >> */
> >> + .macro __badr, c, rd, sym
> >> + .eqv .Lsym\@, \sym
> >> + adr\c \rd, .Lsym\@ + 1
> >
> >
> > Wild shot, but the following works for me.
> >
> > .eqv .Lsym\@, \sym + 1
> > adr\c \rd, .Lsym\@
> >
> > Does it make sense ?
> >
>
> Interesting. Do you mean this works with your 2.30 binutils that
> triggers the original issue?
>
> If so, then yes, it makes sense, although it still seems fragile,
> since we are relying on \sym being resolved without the Thumb bit in
> the context of the .eqv pseudo op. But if this works across all
> implementations we care about, I would be fine with it.
>
> Russell?
Apart from my thoughts about the toolchain changing behaviour after
many years...
It seems that the .eqv solution works on my assembler for the files
I've tested it with, which is great. However...
I'm left wondering how long it will be before the toolchain people
decide to propagate the thumb bit through the .eqv - is the behaviour
there explicitly documented that it won't, or is the above relying on
observed behaviour with a particular assembler version. It could
also be that there's versions out there that do this already.
I think it's really up to _toolchain people_ to tell us how to solve
the problem _they've_ created, rather than us floundering around in
the dark using undocumented behaviour that could well change in the
future.
So, I'm going to continue sitting on the fence on this, and basically
take the attitude that it's better that people don't use the new
binutils until binutils people can provide us with an officially
sanctioned solution that's going to work for both older and future
assemblers.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Michal Hocko @ 2018-06-19 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wouu3jz1.fsf@e105922-lin.cambridge.arm.com>
On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
[...]
> In terms of $SUBJECT, I wonder if it's worth taking the original patch
> as a temporary fix (it'll also be easier to backport) while we work on
> fixing these other issues and enabling memoryless nodes.
Well, x86 already does that but copying this antipatern is not really
nice. So it is good as a quick fix but it would be definitely much
better to have a robust fix. Who knows how many other places might hit
this. You certainly do not want to add a hack like this all over...
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCHv3 09/19] arm64: convert syscall trace logic to C
From: Mark Rutland @ 2018-06-19 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619143245.pjkcutm5hupfunla@localhost>
On Tue, Jun 19, 2018 at 03:32:45PM +0100, Catalin Marinas wrote:
> On Mon, Jun 18, 2018 at 01:03:00PM +0100, Mark Rutland wrote:
> > +asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> > + syscall_fn_t syscall_table[])
> > +{
> > + unsigned long flags = current_thread_info()->flags;
> > +
> > + regs->orig_x0 = regs->regs[0];
> > + regs->syscallno = scno;
> > +
> > + local_daif_restore(DAIF_PROCCTX);
> > + user_exit();
> > +
> > + if (has_syscall_work(flags)) {
> > + /* set default errno for user-issued syscall(-1) */
> > + if (scno == NO_SYSCALL)
> > + regs->regs[0] = -ENOSYS;
> > + scno = syscall_trace_enter(regs);
> > + if (scno == NO_SYSCALL)
> > + goto trace_exit;
> > + }
> > +
> > + invoke_syscall(regs, scno, sc_nr, syscall_table);
> > +
> > + /*
> > + * The tracing status may have changed under our feet, so we have to
> > + * check again. However, if we were tracing entry, then we always trace
> > + * exit regardless, as the old entry assembly did.
> > + */
> > + if (!has_syscall_work(flags)) {
> > + local_daif_mask();
> > + flags = current_thread_info()->flags;
> > + if (!has_syscall_work(flags))
> > + return;
> > + local_daif_restore(DAIF_PROCCTX);
> > + }
>
> IIUC the above 'if' block replaces ret_fast_syscall in entry.S with the
> work_pending handled via ret_to_user (we used to check _TIF_WORK_MASK in
> two places).
Yes. This replaces the _TIF_SYSCALL_WORK check from ret_fast_syscall,
leaving the _TIF_WORK_MASK check to the usual ret_to_user path.
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks!
Mark.
^ permalink raw reply
* [RFC PATCH 1/2] spi: Add QuadSPI driver for Atmel SAMA5D2
From: Mark Brown @ 2018-06-19 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618162124.21749-2-bugalski.piotr@gmail.com>
On Mon, Jun 18, 2018 at 06:21:23PM +0200, Piotr Bugalski wrote:
> +static int atmel_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
> +{
> + return 0;
> +}
If this can be empty should we adjust the callers to allow it to just be
omitted?
> +static int atmel_qspi_remove(struct platform_device *pdev)
> +{
> + struct spi_controller *ctrl = platform_get_drvdata(pdev);
> + struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
> +
> + qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIDIS);
> + clk_disable_unprepare(aq->clk);
> +
> + spi_unregister_controller(ctrl);
> +
> + return 0;
> +}
You should unregister the controller before disabling the hardware,
otherwise something could come in and try to start an operation on the
controller (or already be running one) while the hardware is disabled
which might blow up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/0ebd21f0/attachment.sig>
^ permalink raw reply
* [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control
From: Chen-Yu Tsai @ 2018-06-19 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618073425.ce2dkipuvrtbqela@flea>
On Mon, Jun 18, 2018 at 3:34 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Mon, Jun 18, 2018 at 10:11:20AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Jun 15, 2018 at 5:14 PM, Maxime Ripard
>> <maxime.ripard@bootlin.com> wrote:
>> > On Thu, Jun 14, 2018 at 11:35:44PM +0800, Chen-Yu Tsai wrote:
>> >> Hi,
>> >>
>> >> This series is the remaining A64 syscon changes from the R40 DWMAC
>> >> series. The series aligns how the A64 system control exports a regmap
>> >> for the sun8i DWMAC driver to access with what we've done for the R40.
>> >>
>> >> Originally the A64 used the generic syscon for this bit of hardware.
>> >> But this block also contains mapping bits for the onboard SRAM, used
>> >> by various peripherals, and other vendor specific bits we may use in
>> >> the future. It is by no means generic. And we already have a device
>> >> tree binding and driver for the SRAM part.
>> >>
>> >> The first patch make the SRAM control device export a regmap, exposing
>> >> a single EMAC control register, for the DWMAC driver to consume.
>> >>
>> >> The second and third patches rename the A64 compatible string to read
>> >> "system control", which is what the block is named in the user manual.
>> >>
>> >> The last patch fixes up the device node, and also adds the lone mappable
>> >> SRAM block, which is needed by the Display Engine.
>> >
>> > For the serie:
>> > Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>
>> Cool. I'll apply them once you've rebased and pushed out any patches you
>> queued up during the merge window.
>
> All should be pushed now, feel free to apply them :)
Applied. Thanks.
ChenYu
^ permalink raw reply
* [PATCHv3 10/19] arm64: convert native/compat syscall entry to C
From: Catalin Marinas @ 2018-06-19 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-11-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:01PM +0100, Mark Rutland wrote:
> Now that the syscall invocation logic is in C, we can migrate the rest
> of the syscall entry logic over, so that the entry assembly needn't look
> at the register values at all.
>
> The SVE reset across syscall logic now unconditionally clears TIF_SVE,
> but sve_user_disable() will only write back to CPACR_EL1 when SVE is
> actually enabled.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Other than Dave's comments, it looks fine to me.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Will Deacon @ 2018-06-19 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Zc7eQbG-Ww51GXUCEmhe2J03vbq5vVdyaKra-s13KrA@mail.gmail.com>
Hi Ard,
Sorry, I forgot to reply to this.
On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
> >> To protect against KSMA(Kernel Space Mirroring Attack), make
> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
> >> carefully constructed PGD entry into the translation table.
> >> The type of this entry is block, which maps the kernel text
> >> and its access permissions bits are 01. The user process can
> >> then modify kernel text directly through this mapping. In this
> >> way, an arbitrary write can be converted to multiple arbitrary
> >> writes.
> >>
> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
> >> ---
> >> arch/arm64/mm/mmu.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> >> prot, pgd_pgtable_alloc, 0);
> >>
> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
> >> + (unsigned long)tramp_pg_dir,
> >> + PGD_SIZE, PAGE_KERNEL_RO);
> >
> > Hmm, I like the idea but is there a risk that the page table has been mapped
> > as part of a block entry, which we can't safely split at this point (i.e.
> > we'll run into one of the BUG_ONs in the mapping code)?
> >
>
> We'd need to create a separate segment for it initially so the mapping
> is already at the right granularity.
Why do you think that's the case? I can't see anything that guarantees this
for the page table itself.
Will
^ permalink raw reply
* [PATCH v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem
From: Dave Kleikamp @ 2018-06-19 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ca9e5d9d-e090-f9e0-bc10-3297c9e3b7e1@arm.com>
On 06/19/2018 10:00 AM, James Morse wrote:
> Hi Dave,
>
> On 19/06/18 14:37, Dave Kleikamp wrote:
>> On 06/19/2018 01:44 AM, AKASHI Takahiro wrote:
>>> +static int __init reserve_memblock_reserved_regions(void)
>>> +{
>>> + phys_addr_t start, end, roundup_end = 0;
>>> + struct resource *mem, *res;
>>> + u64 i;
>>> +
>>> + for_each_reserved_mem_region(i, &start, &end) {
>>> + if (end <= roundup_end)
>>> + continue; /* done already */
>>> +
>>> + start = __pfn_to_phys(PFN_DOWN(start));
>>> + end = __pfn_to_phys(PFN_UP(end)) - 1;
>>> + roundup_end = end;
>>> +
>>> + res = kzalloc(sizeof(*res), GFP_ATOMIC);
>>> + if (WARN_ON(!res))
>>> + return -ENOMEM;
>>> + res->start = start;
>>> + res->end = end;
>>> + res->name = "reserved";
>>> + res->flags = IORESOURCE_MEM;
>>> +
>>> + mem = request_resource_conflict(&iomem_resource, res);
>>> + /*
>>> + * We expected memblock_reserve() regions to conflict with
>>> + * memory created by request_standard_resources().
>>> + */
>>> + if (WARN_ON_ONCE(!mem))
>>> + continue;
>>> + kfree(res);
>>
>> Why is kfree() after the conditional continue? This is a memory leak.
>
> request_resource_conflict() inserts res into the iomem_resource tree, or returns
> the conflict if there is already something at this address.
>
> We expect something at this address: a 'System RAM' section added by
> request_resource(). This code wants the conflicting 'System RAM' entry so that
> reserve_region_with_split() can fill in the gaps below it with 'reserved'. See
> the commit-message for an example.
>
> If there was no conflict, it means the memory map doesn't look like we expect,
> we can't pass NULL to reserve_region_with_split(), and we just inserted the
> 'reserved' at the top level. Freeing res at this point would be a use-after-free
> hanging from /proc/iomem.
> This code generates a WARN_ON_ONCE() and leaves the 'reserved' description where
> it is.
Okay. I get it.
> Trying to cleanup here is pointless, we can remove the resource entry and free
> it ... but we still want to report it as reserved, which is what just happened,
> just not quite how we we wanted it.
>
> If you ever see this warning, it means some RAM stopped being nomap between
> request_resources() and reserve_memblock_reserved_regions(). I can't find any
> case where that ever happens.
>
>
> If all that makes sense: how can I improve the comment above the WARN_ON_ONCE()
> to make it clearer?
I guess something like you described above.
/*
* We expect a 'System RAM' section at this address. In the unexpected
* case where one is not found, request_resource_conflict() will insert
* res into the iomem_resource tree.
*/
Do you think this is clearer?
>
>
> Thanks,
>
> James
>
>
>>> +
>>> + reserve_region_with_split(mem, start, end, "reserved");
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +arch_initcall(reserve_memblock_reserved_regions);
>>> +
>>> u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
>>>
>>> void __init setup_arch(char **cmdline_p)
>>>
>
^ permalink raw reply
* [PATCHv3 11/19] arm64: don't reload GPRs after apply_ssbd
From: Catalin Marinas @ 2018-06-19 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-12-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:02PM +0100, Mark Rutland wrote:
> Now that all of the syscall logic works on the saved pt_regs, apply_ssbd
> can safely corrupt x0-x3 in the entry paths, and we no longer need to
> restore them. So let's remove the logic doing so.
>
> With that logic gone, we can fold the branch target into the macro, so
> that callers need not deal with this. GAS provides \@, which provides a
> unique value per macro invocation, which we can use to create a unique
> label.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: Ard Biesheuvel @ 2018-06-19 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619152035.GM13984@arm.com>
On 19 June 2018 at 17:20, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ard,
>
> Sorry, I forgot to reply to this.
>
> On Wed, May 30, 2018 at 11:53:20AM +0200, Ard Biesheuvel wrote:
>> On 30 May 2018 at 11:14, Will Deacon <will.deacon@arm.com> wrote:
>> > On Wed, May 30, 2018 at 12:48:06PM +0800, YaoJun wrote:
>> >> To protect against KSMA(Kernel Space Mirroring Attack), make
>> >> tramp_pg_dir read-only. The principle of KSMA is to insert a
>> >> carefully constructed PGD entry into the translation table.
>> >> The type of this entry is block, which maps the kernel text
>> >> and its access permissions bits are 01. The user process can
>> >> then modify kernel text directly through this mapping. In this
>> >> way, an arbitrary write can be converted to multiple arbitrary
>> >> writes.
>> >>
>> >> Signed-off-by: YaoJun <yaojun8558363@gmail.com>
>> >> ---
>> >> arch/arm64/mm/mmu.c | 4 ++++
>> >> 1 file changed, 4 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> >> index 2dbb2c9f1ec1..ac4b22c7e435 100644
>> >> --- a/arch/arm64/mm/mmu.c
>> >> +++ b/arch/arm64/mm/mmu.c
>> >> @@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
>> >> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
>> >> prot, pgd_pgtable_alloc, 0);
>> >>
>> >> + update_mapping_prot(__pa_symbol(tramp_pg_dir),
>> >> + (unsigned long)tramp_pg_dir,
>> >> + PGD_SIZE, PAGE_KERNEL_RO);
>> >
>> > Hmm, I like the idea but is there a risk that the page table has been mapped
>> > as part of a block entry, which we can't safely split at this point (i.e.
>> > we'll run into one of the BUG_ONs in the mapping code)?
>> >
>>
>> We'd need to create a separate segment for it initially so the mapping
>> is already at the right granularity.
>
> Why do you think that's the case? I can't see anything that guarantees this
> for the page table itself.
>
We'd need to pass NO_BLOCK_MAPPINGS to map_kernel_segment(),
obviously, but that shouldn't hurt since that segment is relatively
tiny anyway.
^ permalink raw reply
* [PATCHv3 12/19] arm64: zero GPRs upon entry from EL0
From: Catalin Marinas @ 2018-06-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-13-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:03PM +0100, Mark Rutland wrote:
> We can zero GPRs x0 - x29 upon entry from EL0 to make it harder for
> userspace to control values consumed by speculative gadgets.
>
> We don't blat x30, since this is stashed much later, and we'll blat it
> before invoking C code.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Ard Biesheuvel @ 2018-06-19 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuUZTG0q4f2T=+HjEijUCLb7KNXok9RJHOXOKNs2iap5p7m5Q@mail.gmail.com>
On 19 June 2018 at 17:14, Yang Zhang <yang.zhang@96boards.org> wrote:
>
>
> On 18 June 2018 at 14:22, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>
>> On 18 June 2018 at 14:21, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Mon, Jun 18, 2018 at 9:45 AM, Linus Walleij
>> > <linus.walleij@linaro.org> wrote:
>> >> This is a proposal for how to handle the non-discoverable
>> >> 96boards plug-in expansion boards called "mezzanines" in the
>> >> Linux kernel. It is a working RFC series meant for discussion
>> >> at the moment.
>> >>
>> >> The RFC was done on the brand new Ultra96 board from Xilinx
>> >> with a Secure96 mezzanine expansion board. The main part
>> >> is in patch 4, the rest is enabling and examples.
>> >>
>> >> The code can be obtained from here:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>> >>
>> >> You can for example probably augment the DTS file for any
>> >> upstream-supported 96board and get the Secure96 going with
>> >> it with minor efforts.
>> >
>> > Hi Linus,
>> >
>> > Thanks for your work on solving this long-standing problem. I've just
>> > read through your patches briefly and have a few thoughts:
>> >
>> > - I really like the idea of having C code deal with the mezzanine
>> > connector itself, acting as an intermediate to tie a number of
>> > boards to a number of add-on cards, this seems much simpler than
>> > trying to do everything with overlays or one of the other more
>> > generic mechanisms.
>> >
>> > - I don't like the idea of having the bus driver contain a list of
>> > possible
>> > add-ons, this seems to go against our usual driver model. What
>> > I think we want instead is to make the connector itself a proper
>> > bus_type, to allow drivers to register against it as loadable modules,
>> > and devices (maybe limited to one device) being created as probed
>> > from DT or some other method as you describe.
>> >
>> > - You export symbols in the mezzanine_* namespace, which I think
>> > is a bit too generic and should perhaps contain something related
>> > to 96boards in its name to make it less ambiguous. I suspect we
>> > would add a number of further connectors for hats, capes, lures etc,
>> > which could all be described as mezzanines. One open question
>> > is how we structure the commonality between the various
>> > connectors, but we can defer that until we have more than one
>> > or two of them.
>> >
>>
>> Hello all,
>>
>> We should also consider firmware use of the mezzanines. For instance,
>> the Secure96 has a RNG which UEFI may want to use so the early boot
>> code can access is for KASLR. It also has a TPM, which should not be
>> reset/reinitialized/etc by the OS if we want to make meaningful use of
>> it.
>>
>> Also, given that we can (and do) already describe topologies involving
>> mezzanines by ignoring the connector altogether (which is not entirely
>> unreasonable given the fact that we [as Linaro/96boards] dropped the
>> ball on this one and did not mandate discoverability for mezzanines).
>
>
> The design guideline has been reviewed by many inside/outside linaro through
> the mezzanine at lists.96boards.org and 96b-spec-sig
> <96b-spec-sig@96boards.org> published as recommended/strongly recommended
> item from day one. 'dropping the ball' is a strong conclusion.
>
Apologies for using a term that you seem to take issue with. Are you
saying the spec currently recommends it?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox