* [RFC][PATCH] arm64: update iomem_resource.end
From: Nicolin Chen @ 2018-05-10 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cfb81f55-f917-431f-0afd-c97e7641a2f8@arm.com>
Thanks for the comments, Robin.
On Thu, May 10, 2018 at 06:45:59PM +0100, Robin Murphy wrote:
> On 09/05/18 23:58, Nicolin Chen wrote:
> >The iomem_resource.end is -1 by default and should be updated in
> >arch-level code.
> >
> >ARM64 so far hasn't updated it while core kernel code (mm/hmm.c)
> >started to use iomem_resource.end for boundary check. So it'd be
> >better to assign iomem_resource.end using a valid value, the end
> >of physical address space for example because iomem_resource.end
> >in theory should reflect that.
> >
> >However, VA_BITS might be smaller than PA_BITS in ARM64. So using
> >the end of physical address space doesn't make a lot of sense in
> >this case, or could be even harmful since virtual address cannot
> >reach that memory region.
>
> Why? There's plenty of stuff in the physical address space that will
> only ever be accessed via ioremap/memremap. There's no reason you
> shouldn't be able to run a VA_BITS < 48 kernel on a Cavium ThunderX
I'm running VA_BITS_39 and PA_BITS_48 on Tegra 210. There had
not been any problem of it, however with hmm.....
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/hmm.c#n1144
This hmm_devmem_add() requests a region with PFNs being outside
of the linear region in ARM64 case which takes MAX_PHYSMEM_BITS
(48 bits) over iomem_resource.end without this patch. Then when
dealing with page structures in vmemmap region from a given PFN
directly (CONFIG_SPARSEMEM_VMEMMAP=y), and the given PFN is the
last one based on physical region (48 bits), the address of its
page structure will go beyond vmemmap region. Does this sound a
problem?
> where *all* the I/O is in the top half of the PA space. We already
> constrain RAM in this very function to those regions which fit into
> the linear map, and if you're accessing anything other than RAM
> through the linear map you're probably doing something wrong.
If I understand this part correctly, since ARM64 has applied the
memory limit already, does it mean that probably we should fix
something in the region_intersects() or add an extra check in the
hmm_devmem_add(), instead of limiting the iomem_resource?
> Furthermore, the physical region covered by the linear map doesn't
> necessarily start at physical address 0 anyway - see PHYS_OFFSET.
Hmm...okay...but there still should be a protection somewhere if
it happens to access a page structure via pfn_to_page() while the
PFN is not covered by the vmemmap linear mapping, right?
Thanks!
^ permalink raw reply
* [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability
From: Brian Norris @ 2018-05-10 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WZ+2MNbe341M7OQD11+RxaJuzdM6zMnXYB4dka74K1hQ@mail.gmail.com>
+ irqchip maintainers
[ irqchip is weird -- it's all over drivers/{pinctrl,gpio,irqchip}/ :D ]
Hi Doug,
On Tue, May 08, 2018 at 10:18:18PM -0700, Doug Anderson wrote:
> On Tue, May 8, 2018 at 7:21 PM, JeffyChen <jeffy.chen@rock-chips.com> wrote:
> > On 05/09/2018 03:46 AM, Doug Anderson wrote:
> >> One note is that in the case Brian points at (where we need to
> >> simulate EDGE_BOTH by swapping edges) we purposely ignored the TRM and
> >> we needed to do that to avoid losing interrupts. For details, see
> >> commit 53b1bfc76df2 ("pinctrl: rockchip: Avoid losing interrupts when
> >> supporting both edges"). We did this because:
> >>
> >> 1. We believed that the IP block in Rockchip SoCs has nearly the same
> >> logic as "gpio-dwapb.c" and that's what "gpio-dwapb.c" did.
> >>
> >
> > hmm, but i saw the gpio-dwapb.c actually toggle trigger after handle irq,
> > which might avoid the race Brian mentioned:
> > + generic_handle_irq(gpio_irq);
> > + irq_status &= ~BIT(hwirq);
> > +
> > + if ((irq_get_trigger_type(gpio_irq) & IRQ_TYPE_SENSE_MASK)
> > + == IRQ_TYPE_EDGE_BOTH)
> > + dwapb_toggle_trigger(gpio, hwirq);
>
> The code you point at in dwapb_toggle_trigger() specifically is an
> example of toggling the polarity _without_ disabling the interrupt in
> between. We took this as "working" code and as proof that it was OK
> to change polarity without disabling the interrupt in-between.
There's a crucial ordering difference though: gpio-dwapb performs its
polarity adjustments *after* calling generic_handle_irq(), which among
other things calls ->irq_ack(). This means that it's re-ensuring that
the polarity is correct *after* the point at which it last ack'ed the
interrupt. So there's no chance of it clearing a second interrupt
without appropriately reconfiguring the polarity.
> > and i also saw ./qcom/pinctrl-msm.c do the
> > toggle(msm_gpio_update_dual_edge_pos) at the end of msm_gpio_irq_set_type
> > and msm_gpio_irq_ack, that seems can avoid the polarity races too.
> >
> >> 2. We were actually losing real interrupts and this was the only way
> >> we could figure out how to fix it.
> >>
> >> When I tested that back in the day I was fairly convinced that we
> >> weren't losing any interrupts in the EDGE_BOTH case after my fix, but
> >> I certainly could have messed up.
> >>
> >>
> >> For the EDGE_BOTH case it was important not to lose an interrupt
> >> because, as you guys are talking about, we could end up configured the
> >> wrong way. I think in your case where you're just picking one
> >> polarity losing an interrupt shouldn't matter since it's undefined
> >> exactly if an edge happens while you're in the middle of executing
> >> rockchip_irq_set_type(). Is that right?
> >
> >
> > right, so we now have 2 cases: rockchip_irq_demux/ rockchip_irq_set_type
> >
> > if i'm right about the spurious irq(only happen when set rising for a high
> > gpio, or set falling for a low gpio), then:
> >
> > 1/ rockchip_irq_demux
> > it's important to not losing irqs in this case, maybe we can
> >
> > a) ack irq
> > b) update polarity for edge both irq
> >
> > we don't need to disable irq in b), since we would not hit the spurious irq
> > cases here(always check gpio level to toggle it)
>
> Unless you have some sort of proof that rockchip_irq_demux(), I would
> take it as an example of something that works. I remember stress
> testing the heck out of it. Do you have some evidence that it's not
> working? I think Brian was simply speculating that there might be a
> race here, but I don't think anyone has shown it have they? Looking
> back at my notes, the thing I really made sure to stress was that we
> never got into a situation where we were losing an edge (AKA we were
> never configured to look for a falling edge when the line was already
> low). I'm not sure I confirmed that we never got an extra interrupt.
I'll agree wholeheartedly that I'm only at the speculation stage right
now :) I can try to poke at it sometime if I get some cycles. I'd
definitely want to get better test results to prove this before changing
this part.
This is really just a side tangent anyway, because apparently the
existing code is working well enough for rockchip_irq_demux(), and for
$subject, we're really only working on improving set_type().
> I'm at home right now and I can't add prints and poke at things, but
> as I understand it for edge interrupts the usual flow to make sure
> interrupts aren't ever lost is:
>
> 1. See that the interrupt went off
> 2. Ack it (clear it)
> 3. Call the interrupt handler
>
> ...presumably in this case rockchip_irq_demux() is called after step
> #2 (but I don't know if it's called before or after step #3). If the
One thing to note here is that we're talking about a 2-level (chained)
interrupt system. We've got the GIC, which does all of 1, 2, 3 at its
level, and as part of #3 for the GIC, it runs the 2nd-level handler --
rockchip_irq_demux() -- which has to perform all of 1, 2, 3 at its level.
1 -> this is looping over GPIO_INT_STATUS in rockchip_irq_demux()
2 -> this happens when writing to GPIO_PORTS_EOI, which only is called
by ->irq_ack() (irq_gc_ack_set_bit()) ... which happens from:
rockchip_irq_demux()
-> generic_handle_irq()
-> handle_edge_irq()
-> desc->irq_data.chip->irq_ack() = irq_gc_ack_set_bit()
3 -> same callpath as 2, except it's
-> handle_edge_irq()
-> handle_irq_event()
Those all happen in the correct order.
But the problem is that you left out the part about "change polarity for
emulating EDGE_BOTH"; in your example (gpio-dwapb.c), polarity
adjustment happens *after* 2; in Rockchip's driver, we have it before.
I'm pretty sure dwapb is correct, and we are not.
> line is toggling like crazy while the 3 steps are going on, it's OK if
> the interrupt handler is called more than once. In general this could
> be considered expected. That's why you Ack before handling--any extra
> edges that come in any time after the interrupt handler starts (even
> after the very first instruction) need to cause the interrupt handler
> to get called again.
>
> This is different than Brian's understanding since he seemed to think
> the Ack was happening later. If you're in front of something where
> you can add printouts, maybe you can tell us. I tried to look through
> the code and it was too twisted for me to be sure.
I'm not sure your understanding of my understanding is accurate :)
Hopefully the above clarifies what I'm thinking?
> > 2/ rockchip_irq_set_type
> > it's important to not having spurious irqs
> >
> > so we can disable irq during changing polarity only in these case:
> > ((rising && gpio is heigh) || (falling && gpio is low))
> >
> > i'm still confirming the spurious irq with IC guys.
>
> Hmmm, thinking about all this more, I'm curious how callers expect
> this to work. Certainly things are undefined if you have the
> following situation:
>
> Start: rising edge trigger, line is actually high
> Request: change to falling edge trigger
> Line falls during the request
>
> In that case it's OK to throw the interrupt away because it can be
> argued that the line could have fallen before the request actually
> took place. ...but it seems like there could be situations where the
> user wouldn't expect interrupts to be thrown away by a call to
> irq_set_type(). In other words:
>
> Start: rising edge trigger, line is actually high
> Request: change to falling edge trigger
> Line falls, rises, and falls during the request
>
> ...in that case you'd expect that some sort of interrupt would have
> gone off and not be thrown away. No matter what instant in time the
> request actually took place it should have caught an edge, right?
>
>
> Said another way: As a client of irq_set_type() I'd expect it to not
> throw away interrupts, but I'd expect that the change in type would be
> atomic. That is: if the interrupt came in before the type change in
> type applied then it should trigger with the old rules. If the
> interrupt came in after the type change then it should trigger with
> the new rules.
I'm not sure it's totally possible to differentiate these, but that
seems about right I think.
> I would be tempted to confirm your testing and just clear the spurious
> interrupts that you're aware of. AKA: if there's no interrupt pending
> and you change the type to "IRQ_TYPE_EDGE_RISING" or
> "IRQ_TYPE_EDGE_FALLING" then you should clear the interrupt. It's
> still racy, but I guess it's the best you can do unless IC guys come
> up with something better.
Thanks! Yeah, clearing (rather than temporarily disabling) seems to make
more sense.
> Anyway, it's past my bedtime. Hopefully some of the above made sense.
> I'm sure you'll tell me if it didn't or if I said something
> stupid/wrong. :-P
Brian
^ permalink raw reply
* [PATCH v3 6/8] arm64: module-plts: Extend veneer to address 52-bit VAs
From: Ard Biesheuvel @ 2018-05-10 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510162347.3858-7-steve.capper@arm.com>
On 10 May 2018 at 18:23, Steve Capper <steve.capper@arm.com> wrote:
> From: Ard Bieusheuval <ard.biesheuvel@linaro.org>
>
> In preparation for 52-bit VA support in the Linux kernel, we extend the
> plts veneer to support 52-bit addresses via an extra movk instruction.
>
> [Steve: code from Ard off-list, changed the #ifdef logic to inequality]
> Signed-off-by: Steve Capper <steve.capper@arm.com>
>
> ---
>
> New in V3 of the series.
>
> I'm not sure if this is strictly necessary as the VAs of the module
> space will fit within 48-bits of addressing even when a 52-bit VA space
> is enabled.
What about the kernel text itself? Is that also guaranteed to have
bits [51:48] of its VAs equal 0xf, even under randomization?
If so, I agree we don't need the patch.
> However, this may act to future-proof the 52-bit VA support
> should any future adjustments be made to the VA space.
> ---
> arch/arm64/include/asm/module.h | 13 ++++++++++++-
> arch/arm64/kernel/module-plts.c | 12 ++++++++++++
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
> index 97d0ef12e2ff..30b8ca95d19a 100644
> --- a/arch/arm64/include/asm/module.h
> +++ b/arch/arm64/include/asm/module.h
> @@ -59,6 +59,9 @@ struct plt_entry {
> __le32 mov0; /* movn x16, #0x.... */
> __le32 mov1; /* movk x16, #0x...., lsl #16 */
> __le32 mov2; /* movk x16, #0x...., lsl #32 */
> +#if CONFIG_ARM64_VA_BITS > 48
> + __le32 mov3; /* movk x16, #0x...., lsl #48 */
> +#endif
> __le32 br; /* br x16 */
> };
>
> @@ -71,7 +74,8 @@ static inline struct plt_entry get_plt_entry(u64 val)
> * +--------+------------+--------+-----------+-------------+---------+
> *
> * Rd := 0x10 (x16)
> - * hw := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32)
> + * hw := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32),
> + * 0b11 (lsl #48)
> * opc := 0b11 (MOVK), 0b00 (MOVN), 0b10 (MOVZ)
> * sf := 1 (64-bit variant)
> */
> @@ -79,6 +83,9 @@ static inline struct plt_entry get_plt_entry(u64 val)
> cpu_to_le32(0x92800010 | (((~val ) & 0xffff)) << 5),
> cpu_to_le32(0xf2a00010 | ((( val >> 16) & 0xffff)) << 5),
> cpu_to_le32(0xf2c00010 | ((( val >> 32) & 0xffff)) << 5),
> +#if CONFIG_ARM64_VA_BITS > 48
> + cpu_to_le32(0xf2e00010 | ((( val >> 48) & 0xffff)) << 5),
> +#endif
> cpu_to_le32(0xd61f0200)
> };
> }
> @@ -86,6 +93,10 @@ static inline struct plt_entry get_plt_entry(u64 val)
> static inline bool plt_entries_equal(const struct plt_entry *a,
> const struct plt_entry *b)
> {
> +#if CONFIG_ARM64_VA_BITS > 48
> + if (a->mov3 != b->mov3)
> + return false;
> +#endif
> return a->mov0 == b->mov0 &&
> a->mov1 == b->mov1 &&
> a->mov2 == b->mov2;
> diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
> index f0690c2ca3e0..4d5617e09943 100644
> --- a/arch/arm64/kernel/module-plts.c
> +++ b/arch/arm64/kernel/module-plts.c
> @@ -50,6 +50,9 @@ u64 module_emit_veneer_for_adrp(struct module *mod, void *loc, u64 val)
> struct plt_entry *plt = (struct plt_entry *)pltsec->plt->sh_addr;
> int i = pltsec->plt_num_entries++;
> u32 mov0, mov1, mov2, br;
> +#if CONFIG_ARM64_VA_BITS > 48
> + u32 mov3;
> +#endif
> int rd;
>
> if (WARN_ON(pltsec->plt_num_entries > pltsec->plt_max_entries))
> @@ -69,6 +72,12 @@ u64 module_emit_veneer_for_adrp(struct module *mod, void *loc, u64 val)
> mov2 = aarch64_insn_gen_movewide(rd, (u16)(val >> 32), 32,
> AARCH64_INSN_VARIANT_64BIT,
> AARCH64_INSN_MOVEWIDE_KEEP);
> +#if CONFIG_ARM64_VA_BITS > 48
> + mov3 = aarch64_insn_gen_movewide(rd, (u16)(val >> 48), 48,
> + AARCH64_INSN_VARIANT_64BIT,
> + AARCH64_INSN_MOVEWIDE_KEEP);
> +#endif
> +
> br = aarch64_insn_gen_branch_imm((u64)&plt[i].br, (u64)loc + 4,
> AARCH64_INSN_BRANCH_NOLINK);
>
> @@ -76,6 +85,9 @@ u64 module_emit_veneer_for_adrp(struct module *mod, void *loc, u64 val)
> cpu_to_le32(mov0),
> cpu_to_le32(mov1),
> cpu_to_le32(mov2),
> +#if CONFIG_ARM64_VA_BITS > 48
> + cpu_to_le32(mov3),
> +#endif
> cpu_to_le32(br)
> };
>
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: Switch D-Link DIR-885L to the new partitions syntax
From: Rafał Miłecki @ 2018-05-10 21:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafa? Mi?ecki <rafal@milecki.pl>
This new syntax is slightly better designed & uses "compatible" string.
For details see Documentation/devicetree/bindings/mtd/partition.txt .
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 494dbd39658c..d173bcd93b91 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -26,9 +26,15 @@
nand: nand at 18028000 {
nandcs at 0 {
- partition at 0 {
- label = "firmware";
- reg = <0x00000000 0x08000000>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "firmware";
+ reg = <0x00000000 0x08000000>;
+ };
};
};
};
--
2.13.6
^ permalink raw reply related
* [PATCH] arm64: dts: stratix10: Add QSPI support for Stratix10
From: thor.thayer at linux.intel.com @ 2018-05-10 20:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <thor.thayer@linux.intel.com>
Add qspi_clock
The qspi_clk frequency is updated by U-Boot before starting Linux.
Add QSPI interface node.
Add QSPI flash memory child node.
Setup the QSPI memory in 2 partitions.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 22 +++++++++++++++
.../boot/dts/altera/socfpga_stratix10_socdk.dts | 31 ++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index e6b059378dc0..ed47dfce3ba6 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -119,6 +119,12 @@
#clock-cells = <0>;
compatible = "fixed-clock";
};
+
+ qspi_clk: qspi_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <200000000>;
+ };
};
gmac0: ethernet at ff800000 {
@@ -466,5 +472,21 @@
interrupts = <16 4>, <48 4>;
};
};
+
+ qspi: spi at ff8d2000 {
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff8d2000 0x100>,
+ <0xff900000 0x100000>;
+ interrupts = <0 3 4>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ clocks = <&qspi_clk>;
+ bus-num = <1>;
+
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
index f9b1ef12db48..60251462067a 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
@@ -147,3 +147,34 @@
reg = <0x68>;
};
};
+
+&qspi {
+ flash0: n25q00 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q00aa";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+
+ m25p,fast-read;
+ cdns,page-size = <256>;
+ cdns,block-size = <16>;
+ cdns,read-delay = <1>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+
+ partition at qspi-boot {
+ label = "Boot and fpga data";
+ /* 64MB for boot and FPGA data */
+ reg = <0x0 0x4000000>;
+ };
+
+ partition at qspi-rootfs {
+ label = "Root Filesystem - JFFS2";
+ /* 64MB for Linux jffs2 */
+ reg = <0x4000000 0x4000000>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/2] drivers: soc: Add LLCC driver
From: Evan Green @ 2018-05-10 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525810921-15878-3-git-send-email-rishabhb@codeaurora.org>
Hi Rishabh,
On Tue, May 8, 2018 at 1:23 PM Rishabh Bhatnagar <rishabhb@codeaurora.org>
wrote:
> LLCC (Last Level Cache Controller) provides additional cache memory
> in the system. LLCC is partitioned into multiple slices and each
> slice gets its own priority, size, ID and other config parameters.
> LLCC driver programs these parameters for each slice. Clients that
> are assigned to use LLCC need to get information such size & ID of the
> slice they get and activate or deactivate the slice as needed. LLCC driver
> provides API for the clients to perform these operations.
> Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
> ---
> drivers/soc/qcom/Kconfig | 17 ++
> drivers/soc/qcom/Makefile | 2 +
> drivers/soc/qcom/llcc-sdm845.c | 106 ++++++++++++
> drivers/soc/qcom/llcc-slice.c | 335
+++++++++++++++++++++++++++++++++++++
> include/linux/soc/qcom/llcc-qcom.h | 162 ++++++++++++++++++
> 5 files changed, 622 insertions(+)
> create mode 100644 drivers/soc/qcom/llcc-sdm845.c
> create mode 100644 drivers/soc/qcom/llcc-slice.c
> create mode 100644 include/linux/soc/qcom/llcc-qcom.h
...
> diff --git a/drivers/soc/qcom/llcc-sdm845.c
b/drivers/soc/qcom/llcc-sdm845.c
> new file mode 100644
> index 0000000..e5e792c
> --- /dev/null
> +++ b/drivers/soc/qcom/llcc-sdm845.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/soc/qcom/llcc-qcom.h>
> +
> +/*
> + * SCT(System Cache Table) entry contains of the following members:
> + * usecase_id: Unique id for the client's use case
> + * slice_id: llcc slice id for each client
> + * max_cap: The maximum capacity of the cache slice provided in KB
> + * priority: Priority of the client used to select victim line for
replacement
> + * fixed_size: Boolean indicating if the slice has a fixed capacity
> + * bonus_ways: Bonus ways are additional ways to be used for any slice,
> + * if client ends up using more than reserved cache ways.
Bonus
> + * ways are allocated only if they are not reserved for some
> + * other client.
> + * res_ways: Reserved ways for the cache slice, the reserved ways cannot
> + * be used by any other client than the one its assigned to.
> + * cache_mode: Each slice operates as a cache, this controls the mode of
the
> + * slice: normal or TCM(Tightly Coupled Memory)
> + * probe_target_ways: Determines what ways to probe for access hit. When
> + * configured to 1 only bonus and reserved ways are
probed.
> + * When configured to 0 all ways in llcc are probed.
> + * dis_cap_alloc: Disable capacity based allocation for a client
> + * retain_on_pc: If this bit is set and client has maintained active vote
> + * then the ways assigned to this client are not flushed
on power
> + * collapse.
> + * activate_on_init: Activate the slice immediately after the SCT is
programmed
> + */
> +#define SCT_ENTRY(uid, sid, mc, p, fs, bway, rway, cmod, ptw, dca, rp,
a) \
> + { \
> + .usecase_id = uid, \
> + .slice_id = sid, \
> + .max_cap = mc, \
> + .priority = p, \
> + .fixed_size = fs, \
> + .bonus_ways = bway, \
> + .res_ways = rway, \
> + .cache_mode = cmod, \
> + .probe_target_ways = ptw, \
> + .dis_cap_alloc = dca, \
> + .retain_on_pc = rp, \
> + .activate_on_init = a, \
> + }
> +
> +static struct llcc_slice_config sdm845_data[] = {
> + SCT_ENTRY(1, 1, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 1),
> + SCT_ENTRY(2, 2, 512, 2, 1, 0x0, 0x0f0, 0, 0, 1, 1, 0),
> + SCT_ENTRY(3, 3, 512, 2, 1, 0x0, 0x0f0, 0, 0, 1, 1, 0),
> + SCT_ENTRY(4, 4, 563, 2, 1, 0x0, 0x00e, 2, 0, 1, 1, 0),
> + SCT_ENTRY(5, 5, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(6, 6, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(7, 7, 1024, 2, 0, 0xfc, 0xf00, 0, 0, 1, 1, 0),
> + SCT_ENTRY(8, 8, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(10, 10, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(11, 11, 512, 1, 1, 0xc, 0x0, 0, 0, 1, 1, 0),
> + SCT_ENTRY(12, 12, 2304, 1, 0, 0xff0, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(13, 13, 256, 2, 0, 0x0, 0x1, 0, 0, 1, 0, 1),
> + SCT_ENTRY(15, 15, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(16, 16, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(17, 17, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1, 1, 0),
> + SCT_ENTRY(20, 20, 1024, 2, 1, 0x0, 0xf00, 0, 0, 1, 1, 0),
> + SCT_ENTRY(21, 21, 1024, 0, 1, 0x1e, 0x0, 0, 0, 1, 1, 0),
> + SCT_ENTRY(22, 22, 1024, 1, 1, 0xffc, 0x2, 0, 0, 1, 1, 0),
> +};
Now that drivers are hardcoding IDs when calling llcc_slice_getd, should we
add #defines in llcc-qcom.h for each of the usecase IDs? Then this would
change the entries to look like:
SCT_ENTRY(QCOM_LLCC_CPUSS, 1, 2816, 1, 0, 0xffc, 0x2, 0, 0, 1,
1, 1),
and drivers using it would call llcc_slice_getd(QCOM_LLCC_CPUSS), rather
than llcc_slice_getd(1).
> diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
> new file mode 100644
> index 0000000..209df55
> --- /dev/null
> +++ b/drivers/soc/qcom/llcc-slice.c
> @@ -0,0 +1,335 @@
...
> +
> +/**
> + * llcc_slice_activate - Activate the llcc slice
> + * @desc: Pointer to llcc slice descriptor
> + *
> + * A value of zero will be returned on success and a negative errno will
> + * be returned in error cases
> + */
> +int llcc_slice_activate(struct llcc_slice_desc *desc)
> +{
> + int ret;
> + u32 act_ctrl_val;
> +
> + mutex_lock(&drv_data->lock);
> + if (test_bit(desc->slice_id, drv_data->bitmap)) {
> + mutex_unlock(&drv_data->lock);
> + return 0;
> + }
> +
> + act_ctrl_val = ACT_CTRL_OPCODE_ACTIVATE << ACT_CTRL_OPCODE_SHIFT;
> +
> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
> + DEACTIVATE);
> + if (ret)
> + return ret;
I had asked for this in the last revision, and thank you for putting that
in so that the bitmap matches reality. Unfortunately this introduces
another error, which is that you never unlock the mutex :(
> +
> + __set_bit(desc->slice_id, drv_data->bitmap);
> + mutex_unlock(&drv_data->lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(llcc_slice_activate);
> +
> +/**
> + * llcc_slice_deactivate - Deactivate the llcc slice
> + * @desc: Pointer to llcc slice descriptor
> + *
> + * A value of zero will be returned on success and a negative errno will
> + * be returned in error cases
> + */
> +int llcc_slice_deactivate(struct llcc_slice_desc *desc)
> +{
> + u32 act_ctrl_val;
> + int ret;
> +
> + mutex_lock(&drv_data->lock);
> + if (!test_bit(desc->slice_id, drv_data->bitmap)) {
> + mutex_unlock(&drv_data->lock);
> + return 0;
> + }
> + act_ctrl_val = ACT_CTRL_OPCODE_DEACTIVATE <<
ACT_CTRL_OPCODE_SHIFT;
> +
> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
> + ACTIVATE);
> + if (ret)
> + return ret;
Same here, mutex left locked.
> +
> + __clear_bit(desc->slice_id, drv_data->bitmap);
> + mutex_unlock(&drv_data->lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(llcc_slice_deactivate);
> +
> +/**
> + * llcc_get_slice_id - return the slice id
> + * @desc: Pointer to llcc slice descriptor
> + */
> +int llcc_get_slice_id(struct llcc_slice_desc *desc)
> +{
> + return desc->slice_id;
> +}
> +EXPORT_SYMBOL_GPL(llcc_get_slice_id);
> +
> +/**
> + * llcc_get_slice_size - return the slice id
> + * @desc: Pointer to llcc slice descriptor
> + */
> +size_t llcc_get_slice_size(struct llcc_slice_desc *desc)
> +{
> + return desc->slice_size;
> +}
> +EXPORT_SYMBOL_GPL(llcc_get_slice_size);
> +
> +static int qcom_llcc_cfg_program(struct platform_device *pdev)
> +{
> + int i;
> + u32 attr1_cfg;
> + u32 attr0_cfg;
> + u32 attr1_val;
> + u32 attr0_val;
> + u32 max_cap_cacheline;
> + u32 sz;
> + int ret = 0;
> + const struct llcc_slice_config *llcc_table;
> + struct llcc_slice_desc desc;
> + u32 bcast_off = drv_data->bcast_off;
> +
> + sz = drv_data->cfg_size;
> + llcc_table = drv_data->cfg;
> +
> + for (i = 0; i < sz; i++) {
> + attr1_cfg = bcast_off +
> +
LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
> + attr0_cfg = bcast_off +
> +
LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
> +
> + attr1_val = llcc_table[i].cache_mode;
> + attr1_val |= llcc_table[i].probe_target_ways <<
> + ATTR1_PROBE_TARGET_WAYS_SHIFT;
> + attr1_val |= llcc_table[i].fixed_size <<
> + ATTR1_FIXED_SIZE_SHIFT;
> + attr1_val |= llcc_table[i].priority <<
ATTR1_PRIORITY_SHIFT;
> +
> + max_cap_cacheline =
MAX_CAP_TO_BYTES(llcc_table[i].max_cap);
> +
> + /* LLCC instances can vary for each target.
> + * The SW writes to broadcast register which gets
propagated
> + * to each llcc instace (llcc0,.. llccN).
> + * Since the size of the memory is divided equally
amongst the
> + * llcc instances, we need to configure the max cap
accordingly.
> + */
> + max_cap_cacheline = max_cap_cacheline /
drv_data->num_banks;
> + max_cap_cacheline >>= CACHE_LINE_SIZE_SHIFT;
> + attr1_val |= max_cap_cacheline << ATTR1_MAX_CAP_SHIFT;
> +
> + attr0_val = llcc_table[i].res_ways & ATTR0_RES_WAYS_MASK;
> + attr0_val |= llcc_table[i].bonus_ways <<
ATTR0_BONUS_WAYS_SHIFT;
> +
> + ret = regmap_write(drv_data->regmap, attr1_cfg,
attr1_val);
> + if (ret)
> + return ret;
> + ret = regmap_write(drv_data->regmap, attr0_cfg,
attr0_val);
> + if (ret)
> + return ret;
> + if (llcc_table[i].activate_on_init) {
> + desc.slice_id = llcc_table[i].slice_id;
> + ret = llcc_slice_activate(&desc);
> + }
> + }
> + return ret;
> +}
> +
> +int qcom_llcc_probe(struct platform_device *pdev,
> + const struct llcc_slice_config *llcc_cfg, u32 sz)
> +{
> +
> + u32 num_banks = 0;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + void __iomem *base;
> + int ret = 0;
> + int i;
> +
> + drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
> + if (!drv_data)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + drv_data->regmap = devm_regmap_init_mmio(dev, base,
> + &llcc_regmap_config);
> + if (IS_ERR(drv_data->regmap))
> + return PTR_ERR(drv_data->regmap);
> +
> + ret = regmap_read(drv_data->regmap, LLCC_COMMON_STATUS0,
> + &num_banks);
> + if (ret)
> + return ret;
> +
> + num_banks &= LLCC_LB_CNT_MASK;
> + num_banks >>= LLCC_LB_CNT_SHIFT;
> + drv_data->num_banks = num_banks;
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "max-slices",
> + &drv_data->max_slices);
> + if (ret)
> + return ret;
> +
The way this driver is written, there is only one sane value for
max-slices, and it can be derived by finding the max slice_id in llcc_cfg.
You only use "max-slices" to size the bitmap, but then use the slice_id
everywhere when indexing into the bitmap, so as far as I can tell this DT
property is not needed. Can we remove it from the binding and just derive
the value by iterating over llcc_cfg to find the max slice_id?
-Evan
^ permalink raw reply
* [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
From: Russell King - ARM Linux @ 2018-05-10 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkwaNmZCUjwJXK0X1ia+RnzumfbpB8EvZJ-HDtOHj8rafQ@mail.gmail.com>
On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote:
> Hi Russell,
>
> On 10 May 2018 at 02:40, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> > This does not leak information from other namespaces because of the
> > uniqueness of the global PID. However, what it does leak is the value
> > of the global PID which is meaningless in the namespace. So, before
> > the event stream is delivered to userspace, this value needs to be
> > re-written to the namespace's PID value.
>
> Unfortunately that can't be done. The trace stream is compressed and
> needs to be decompressed using an external library. I think the only
> option is to return an error if a user is trying to use this feature
> from a namespace.
That sounds like a sensible approach, and that should get rid of the
vpid stuff too.
Eric, would this solve all your concerns?
--
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 2/4] pid: Export find_task_by_vpid for use in external modules
From: Mathieu Poirier @ 2018-05-10 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510084057.GT16141@n2100.armlinux.org.uk>
On 10 May 2018 at 02:40, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Wed, May 09, 2018 at 09:35:07PM -0500, Eric W. Biederman wrote:
>> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>>
>> > On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote:
>> >> Kim Phillips <kim.phillips@arm.com> writes:
>> >>
>> >> > This patch is in the context of allowing the Coresight h/w
>> >> > trace driver suite to be loaded as modules. Coresight uses
>> >> > find_task_by_vpid when running in direct capture mode (via sysfs)
>> >> > when getting/setting the context ID comparator to trigger on
>> >> > (/sys/bus/coresight/devices/<x>.etm/ctxid_pid).
>> >>
>> >> Aside from my objection about how bad an interface a pid in sysfs is.
>> >> The implementation of coresight_vpid_to_pid is horrible.
>> >>
>> >> The code should be just:
>> >>
>> >> static inline pid_t coresight_vpid_to_pid(pid_t vpid)
>> >> {
>> >> rcu_read_lock();
>> >> pid = pid_nr(find_vpid(vpid));
>> >> rcu_read_unlock();
>> >>
>> >> return pid;
>> >> }
>> >> Which takes find_task_by_vpid out of the picture.
>> >
>> > Many thanks for pointing out the right way to do this. When Chunyan added
>> > this feature she broadly published her work and find_task_by_vpid() is the
>> > function she was asked to used.
>>
>> Clearly no one was thinking through the implications of a sysfs file
>> which does not have pid namespace support on namespacing. I am quite
>> upset at this mess of an API. It is not a maintainable way to do things.
>>
>> >> But reading further I am seeing code writing a pid to hardware. That is
>> >> broken. That is a layering violation of the first order. Giving
>> >> implementation details like that to hardware.
>> >
>> > This is how the feature works - as Robin pointed out tracers are designed to
>> > match pid values with the CPU's contextID register. The input value has no
>> > other effect than triggering trace collection, which has absolutely no baring on
>> > the CPU.
>>
>> So please tell me how we make the tracer pid namespace aware. Or is it
>> guaranteed that only the global root user will use this functionality?
>>
>> As you are taking a vpid it looks like users with lesser privileges are
>> able to request this. From the other reply it appears this is the
>> value the tracer returns to put in logs. Perhaps I missed it but I
>> didn't see anything that translated from the global pid to something
>> else. Which would make using this feature in a pid namespace confusing
>> and a problematic information leak if I have understood what has been
>> said so far.
>
Hi Russell,
> Let's look to see what's placed into the context ID register - this is
> done by arch/arm/mm/context.c::contextidr_notifier():
>
> pid = task_pid_nr(thread->task) << ASID_BITS;
>
> This is documented in linux/sched.h as:
>
> * task_xid_nr() : global id, i.e. the id seen from the init namespace;
>
> So, what ends up in the context ID register is the _global_ PID, not a
> namespace specific PID. This means the hardware deals with global PID
> values.
Correct.
>
> It seems quite logical to use the global PID value for the hardware,
> because that is a globally unique value - especially as the hardware
> uses this for filtering events. So asking for a namespace's pid 1
> gets mapped to the global pid value, which won't match some other
> namespace's pid 1.
>
> The problem comes _if_ the event stream delivered to userspace contains
> the global PID values and the event stream is being looked at from
> within a namespace.
Correct.
>
> This does not leak information from other namespaces because of the
> uniqueness of the global PID. However, what it does leak is the value
> of the global PID which is meaningless in the namespace. So, before
> the event stream is delivered to userspace, this value needs to be
> re-written to the namespace's PID value.
Unfortunately that can't be done. The trace stream is compressed and
needs to be decompressed using an external library. I think the only
option is to return an error if a user is trying to use this feature
from a namespace.
>
> Things get more yucky with this when you look at the ctxid_masks stuff
> - which looks to me like it implements a mask on the PID value. Masks
> on the pid value are irrelevant from within a namespace, because the
> mask is applied to the global PID value, not the namespace's PID value.
> You can't really define how a set of namespace PIDs will map to global
> PIDs, so masking the context ID PID value in the presence of namespaces
> is pretty useless - and potentially ends up being an information leak.
Also correct. Since there is no point in trying to use contextID
tracing from a namespace (see above) there is also no point in trying
to apply a mask to the contextIDs. Once again I think it is best to
return an error when using from a namespace.
Thanks,
Mathieu
>
> As for the sysfs file thing, I think the simple solution to that is
> the sysfs file should accept a PID value in the current namespace,
> and translate that to the global namespace - and the global PID value
> should be stored. When reading, the global PID value should be
> translated back to the current namespace, or an error/empty given if
> the PID doesn't exist in that namespace. The current solution to
> store the vpid and simply return it irrespective of the namespace is
> just nonsense.
>
> --
> 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 2/2] i2c: exynos5: remove pointless initializers
From: Peter Rosin @ 2018-05-10 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b69f6656-3831-86ea-5f13-fc805d86b288@samsung.com>
On 2018-05-10 10:44, Andrzej Hajda wrote:
> On 09.05.2018 21:45, Peter Rosin wrote:
>> The variables are always assigned before use anyway.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> drivers/i2c/busses/i2c-exynos5.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
>> index a2cbc779c33a..185fba37e830 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -707,7 +707,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
>> struct i2c_msg *msgs, int num)
>> {
>> struct exynos5_i2c *i2c = adap->algo_data;
>> - int i = 0, ret = 0, stop = 0;
>> + int i, ret, stop;
>
> I hope gcc is smart enough to not complain in case of ret.
I think any compiler is smart enough to see that; you must have missed
this line:
ret = clk_enable(i2c->clk);
which is the first to touch ret in the function.
> I think you can merge both patches into one.
I could, but I wanted to make the patches totally obvious and easy to
review. The patches do independent things, so I prefer not to squash.
Cheers,
Peter
>
> Regards
> Andrzej
>
>>
>> if (i2c->suspended) {
>> dev_err(i2c->dev, "HS-I2C is not initialized.\n");
>
>
^ permalink raw reply
* [PATCH 1/2] i2c: exynos5: remove some dead code
From: Peter Rosin @ 2018-05-10 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3915e40-895f-2a72-27a2-dcffe504456d@samsung.com>
On 2018-05-10 10:36, Andrzej Hajda wrote:
> On 09.05.2018 21:45, Peter Rosin wrote:
>> The else branch cannot be taken as i will always equal num.
>> Get rid of the whole construct.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> drivers/i2c/busses/i2c-exynos5.c | 12 +-----------
>> 1 file changed, 1 insertion(+), 11 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
>> index 12ec8484e653..a2cbc779c33a 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -727,17 +727,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
>> goto out;
>> }
>>
>> - if (i == num) {
>> - ret = num;
>> - } else {
>> - /* Only one message, cannot access the device */
>> - if (i == 1)
>> - ret = -EREMOTEIO;
>> - else
>> - ret = i;
>> -
>> - dev_warn(i2c->dev, "xfer message failed\n");
>> - }
>> + ret = num;
>>
>> out:
>> clk_disable(i2c->clk);
>
> You can go further and remove "out:" label, use break instead, and at
> the end use "return (i == num) ? num : ret;" or sth similar.
>
> With this change you can add:
>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
But then the patch wouldn't be so obviously safe. If I would write
a function equivalent to the original function, I think I'd write
something like:
static int exynos5_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
{
struct exynos5_i2c *i2c = adap->algo_data;
int i, ret;
if (i2c->suspended) {
dev_err(i2c->dev, "HS-I2C is not initialized.\n");
return -EIO;
}
ret = clk_enable(i2c->clk);
if (ret)
return ret;
for (i = 0; !ret && i < num; i++)
ret = exynos5_i2c_xfer_msg(i2c, msgs + i, i == num - 1);
clk_disable(i2c->clk);
return ret ?: num;
}
And I think that is safe because I don't see any possibility for
exynos_i2c_xfer_msg to return anything but zero success or negative
errors. Since I can only compile-test, so I do not feel all that
good about going further than I did.
But if you or anyone can test the above function, feel free to make
a patch out of it. I don't care enough to make a bunch of iterations
on these trivialities. I just spotted dead code and dumb initializers
while looking for other things. So, take it or leave it. I.e. it was
just a couple of drive-by patches.
Cheers,
Peter
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: initial V3HSK board device tree
From: Sergei Shtylyov @ 2018-05-10 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3923fc5f-103c-94c9-57ba-cb29e8c55d05@cogentembedded.com>
Add the initial device tree for the V3H Starter Kit board.
The board has 1 debug serial port (SCIF0); include support for it,
so that the serial console can work.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/Makefile | 2
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 60 +++++++++++++++++++++++++
2 files changed, 61 insertions(+), 1 deletion(-)
Index: renesas/arch/arm64/boot/dts/renesas/Makefile
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/Makefile
+++ renesas/arch/arm64/boot/dts/renesas/Makefile
@@ -9,6 +9,6 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3
dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
-dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb
+dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the V3H Starter Kit board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ * Copyright (C) 2018 Cogent Embedded, Inc.
+ */
+
+/dts-v1/;
+#include "r8a77980.dtsi"
+
+/ {
+ model = "Renesas V3H Starter Kit board";
+ compatible = "renesas,v3hsk", "renesas,r8a77980";
+
+ aliases {
+ serial0 = &scif0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0 0x48000000 0 0x78000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <16666666>;
+};
+
+&extalr_clk {
+ clock-frequency = <32768>;
+};
+
+&pfc {
+ scif0_pins: scif0 {
+ groups = "scif0_data";
+ function = "scif0";
+ };
+
+ scif_clk_pins: scif_clk {
+ groups = "scif_clk_b";
+ function = "scif_clk";
+ };
+};
+
+&scif0 {
+ pinctrl-0 = <&scif0_pins>, <&scif_clk_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+};
^ permalink raw reply
* [PATCH 0/2] Add V3H Starter Kit board support
From: Sergei Shtylyov @ 2018-05-10 18:07 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180509-v4.17-rc4' tag. I'm adding the device tree support
for the R8A77980-based V3H Starter Kit board; only serial console is supported
for now, NFS support will require more work (it won't use EtherAVB but GEther)
and will be posted later...
[1/2] dt-bindings: arm: document Renesas V3HSK board bindings
[2/2] arm64: dts: renesas: initial V3HSK board device tree
WBR, Sergei
^ permalink raw reply
* [PATCH] ARM: keystone: fix platform_domain_notifier array overrun
From: Santosh Shilimkar @ 2018-05-10 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fGlYS-0001CN-Sd@rmk-PC.armlinux.org.uk>
On 5/10/2018 6:24 AM, Russell King wrote:
> platform_domain_notifier contains a variable sized array, which the
> pm_clk_notify() notifier treats as a NULL terminated array:
>
> for (con_id = clknb->con_ids; *con_id; con_id++)
> pm_clk_add(dev, *con_id);
>
> Omitting the initialiser for con_ids means that the array is zero
> sized, and there is no NULL terminator. This leads to pm_clk_notify()
> overrunning into what ever structure follows, which may not be NULL.
> This leads to an oops:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000008c
> pgd = c0003000
> [0000008c] *pgd=80000800004003c, *pmd=00000000c
> Internal error: Oops: 206 [#1] PREEMPT SMP ARM
> Modules linked in:c
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0+ #9
> Hardware name: Keystone
> PC is at strlen+0x0/0x34
> LR is at kstrdup+0x18/0x54
> pc : [<c0623340>] lr : [<c0111d6c>] psr: 20000013
> sp : eec73dc0 ip : eed780c0 fp : 00000001
> r10: 00000000 r9 : 00000000 r8 : eed71e10
> r7 : 0000008c r6 : 0000008c r5 : 014000c0 r4 : c03a6ff4
> r3 : c09445d0 r2 : 00000000 r1 : 014000c0 r0 : 0000008c
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5387d Table: 00003000 DAC: fffffffd
> Process swapper/0 (pid: 1, stack limit = 0xeec72210)
> Stack: (0xeec73dc0 to 0xeec74000)
> ...
> [<c0623340>] (strlen) from [<c0111d6c>] (kstrdup+0x18/0x54)
> [<c0111d6c>] (kstrdup) from [<c03a6ff4>] (__pm_clk_add+0x58/0x120)
> [<c03a6ff4>] (__pm_clk_add) from [<c03a731c>] (pm_clk_notify+0x64/0xa8)
> [<c03a731c>] (pm_clk_notify) from [<c004614c>] (notifier_call_chain+0x44/0x84)
> [<c004614c>] (notifier_call_chain) from [<c0046320>] (__blocking_notifier_call_chain+0x48/0x60)
> [<c0046320>] (__blocking_notifier_call_chain) from [<c0046350>] (blocking_notifier_call_chain+0x18/0x20)
> [<c0046350>] (blocking_notifier_call_chain) from [<c0390234>] (device_add+0x36c/0x534)
> [<c0390234>] (device_add) from [<c047fc00>] (of_platform_device_create_pdata+0x70/0xa4)
> [<c047fc00>] (of_platform_device_create_pdata) from [<c047fea0>] (of_platform_bus_create+0xf0/0x1ec)
> [<c047fea0>] (of_platform_bus_create) from [<c047fff8>] (of_platform_populate+0x5c/0xac)
> [<c047fff8>] (of_platform_populate) from [<c08b1f04>] (of_platform_default_populate_init+0x8c/0xa8)
> [<c08b1f04>] (of_platform_default_populate_init) from [<c000a78c>] (do_one_initcall+0x3c/0x164)
> [<c000a78c>] (do_one_initcall) from [<c087bd9c>] (kernel_init_freeable+0x10c/0x1d0)
> [<c087bd9c>] (kernel_init_freeable) from [<c0628db0>] (kernel_init+0x8/0xf0)
> [<c0628db0>] (kernel_init) from [<c00090d8>] (ret_from_fork+0x14/0x3c)
> Exception stack(0xeec73fb0 to 0xeec73ff8)
> 3fa0: 00000000 00000000 00000000 00000000
> 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: e3520000 1afffff7 e12fff1e c0801730 (e5d02000)
> ---[ end trace cafa8f148e262e80 ]---
>
> Fix this by adding the necessary initialiser.
>
> Fixes: fc20ffe1213b ("ARM: keystone: add PM domain support for clock management")
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
Looks good. Thanks Russell !!
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Arnd, olof,
Could you please pick this up for the fixes branch ?
^ permalink raw reply
* [RFC][PATCH] arm64: update iomem_resource.end
From: Robin Murphy @ 2018-05-10 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525906703-28481-1-git-send-email-nicoleotsuka@gmail.com>
On 09/05/18 23:58, Nicolin Chen wrote:
> The iomem_resource.end is -1 by default and should be updated in
> arch-level code.
>
> ARM64 so far hasn't updated it while core kernel code (mm/hmm.c)
> started to use iomem_resource.end for boundary check. So it'd be
> better to assign iomem_resource.end using a valid value, the end
> of physical address space for example because iomem_resource.end
> in theory should reflect that.
>
> However, VA_BITS might be smaller than PA_BITS in ARM64. So using
> the end of physical address space doesn't make a lot of sense in
> this case, or could be even harmful since virtual address cannot
> reach that memory region.
Why? There's plenty of stuff in the physical address space that will
only ever be accessed via ioremap/memremap. There's no reason you
shouldn't be able to run a VA_BITS < 48 kernel on a Cavium ThunderX
where *all* the I/O is in the top half of the PA space. We already
constrain RAM in this very function to those regions which fit into the
linear map, and if you're accessing anything other than RAM through the
linear map you're probably doing something wrong.
Furthermore, the physical region covered by the linear map doesn't
necessarily start@physical address 0 anyway - see PHYS_OFFSET.
Robin.
> Furthermore, the linear region size of
> ARM64 only has the half of Virtual Memory size -- "VA_BITS - 1".
>
> So this patch updates the iomem_resource.end by using the end of
> physical address space or the end of linear mapping region when
> (VA_BITS - 1) is smaller than PA_BITS.
>
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> ---
> arch/arm64/mm/init.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f48b194..22015af 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -377,6 +377,12 @@ void __init arm64_memblock_init(void)
> BUILD_BUG_ON(linear_region_size != BIT(VA_BITS - 1));
>
> /*
> + * Update iomem_resource.end based on size of physical address space,
> + * or linear region size when (VA_BITS - 1) is smaller than PA_BITS.
> + */
> + iomem_resource.end = BIT(min(PHYS_MASK_SHIFT, VA_BITS - 1)) - 1;
> +
> + /*
> * Select a suitable value for the base of physical memory.
> */
> memstart_addr = round_down(memblock_start_of_DRAM(),
>
^ permalink raw reply
* [patch v19 4/4] Documentation: jtag: Add ABI documentation
From: Randy Dunlap @ 2018-05-10 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525967064-10760-5-git-send-email-oleksandrs@mellanox.com>
On 05/10/2018 08:44 AM, Oleksandr Shamray wrote:
> Added document that describe the ABI for JTAG class drivrer
>
> Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v18-v19
> Pavel Machek <pavel@ucw.cz>
> - Added JTAG doccumentation to Documentation/jtag
>
> v17->v18
> v16->v17
> v15->v16
> v14->v15
> v13->v14
> v12->v13
> v11->v12
> Tobias Klauser <tklauser@distanz.ch>
> - rename /Documentation/ABI/testing/jatg-dev -> jtag-dev
> - Typo: s/interfase/interface
> v10->v11
> v9->v10
> Fixes added by Oleksandr:
> - change jtag-cdev to jtag-dev in documentation
> - update Kernel Version and Date in jtag-dev documentation;
> v8->v9
> v7->v8
> v6->v7
> Comments pointed by Pavel Machek <pavel@ucw.cz>
> - Added jtag-cdev documentation to Documentation/ABI/testing folder
> ---
> Documentation/ABI/testing/jtag-dev | 27 +++++++++
> Documentation/jtag/overview | 31 ++++++++++
> Documentation/jtag/transactions | 108 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 166 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/ABI/testing/jtag-dev
> create mode 100644 Documentation/jtag/overview
> create mode 100644 Documentation/jtag/transactions
> diff --git a/Documentation/jtag/overview b/Documentation/jtag/overview
> new file mode 100644
> index 0000000..e35afc0
> --- /dev/null
> +++ b/Documentation/jtag/overview
> @@ -0,0 +1,31 @@
> +Linux kernel JTAG support
> +=========================
> +
> +The JTAG (Joint Test Action Group) is an industry standard for hardware
just: JTAG
drop the "The"
maybe: for verifying
hardware designs
(although that's not quite what wikipedia says)
> +verifying designs and testing printed circuit boards after manufacture.
> +JTAG provides access to many logic signals of a complex integrated circuit,
> +including the device pins
pins.
Oh. Just drop the 2 lines above since they are repeated below.
> +
> +JTAG provides access to many logic signals of a complex integrated circuit,
> +including the device pins.
> +
> +A JTAG interface is a special interface added to a chip.
> +Depending on the version of JTAG, two, four, or five pins are added.
> +
> +The connector pins are:
> + TDI (Test Data In)
> + TDO (Test Data Out)
> + TCK (Test Clock)
> + TMS (Test Mode Select)
> + TRST (Test Reset) optional.
> +
> +JTAG interface is supposed to have two parts - basic core driver and
is designed
> +hardware specific driver.
> +The basic driver introduces general interface which is not dependent of specific
introduces a general interface
> +hardware. It provides communication between user space and hardware specific
and a hardware specific
> +driver.
> +Each JTAG device is represented as char device from (jtag0, jtag1, ...).
as a char device
> +Access to JTAG device is performed through IOCTL call.
Access to a JTAG device is performed through IOCTL calls.
> +
> +Call flow example:
User: open /dev/jtagX
> +User (IOCTL) -> /dev/jtagX -> JTAG core driver -> JTAG hw specific driver
User: close /dev/jtagX
> diff --git a/Documentation/jtag/transactions b/Documentation/jtag/transactions
> new file mode 100644
> index 0000000..91f7f92
> --- /dev/null
> +++ b/Documentation/jtag/transactions
> @@ -0,0 +1,108 @@
> +The JTAG API
> +=============
> +
> +JTAG master devices can be accessed through a character misc-device.
> +Each JTAG master interface can be accessed by using /dev/jtagN
> +
> +JTAG system calls set:
> +- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
Why is SIR for Data Register?
> +- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
Why is SDR for Instruction Register?
> +- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
> +number of clocks.
> +
> +open(), close()
> +-------
> +open() opens JTAG device. Only one open operation per JTAG device
> +can be performed. Twice and more open for one device will return error
Two or more opens for one device will return errors.
> +
> +Open/Close device:
> +- open('/dev/jtag0', O_RDWR);
open("/dev/jtag0", O_RDWR);
> +- close(jtag_fd');
close(jtag_fd);
> +
> +ioctl()
> +-------
> +All access operations to JTAG device performed trougth ioctl interface.
devices are performed through the ioctl interface.
> +It support another requests:
The IOCTL interface supports these requests:
> + JTAG_IOCRUNTEST - Force JTAG state machine to RUN_TEST/IDLE state
> + JTAG_SIOCFREQ - Set JTAG TCK frequency
> + JTAG_GIOCFREQ - GET JTAG TCK frequency
> + JTAG_IOCXFER - send JTAG data Xfer
> + JTAG_GIOCSTATUS - get current JTAG TAP status
> + JTAG_SIOCMODE - set JTAG mode flags.
> +
> +JTAG_SIOCFREQ, JTAG_GIOCFREQ
> +------
> +Set/Get JTAG clock speed:
> +
unsigned int frq;
> + ioctl(jtag_fd, JTAG_SIOCFREQ, &frq);
> + ioctl(jtag_fd, JTAG_GIOCFREQ, &frq);
> +
> +JTAG_IOCRUNTEST
> +------
> +Force JTAG state machine to RUN_TEST/IDLE state
> +
> +struct jtag_run_test_idle {
> + __u8 reset;
> + __u8 endstate;
> + __u8 tck;
> +};
> +
> +reset: 0 - run IDLE/PAUSE from current state
> + 1 - go through TEST_LOGIC/RESET state before IDLE/PAUSE
> +end: completion flag
endstate:
> +tck: clock counter
> +
> +Example:
> + struct jtag_run_test_idle runtest;
> +
> + runtest.endstate = JTAG_STATE_IDLE;
> + runtest.reset = 0;
> + runtest.tck = data_p->tck;
> + usleep(25 * 1000);
> + ioctl(jtag_fd, JTAG_IOCRUNTEST, &runtest);
> +
> +JTAG_IOCXFER
> +------
> +Send SDR/SIR transaction
> +
> +struct jtag_xfer {
> + __u8 type;
> + __u8 direction;
> + __u8 endstate;
> + __u8 padding;
> + __u32 length;
> + __u64 tdio;
> +};
> +
> +type: transfer type - JTAG_SIR_XFER/JTAG_SDR_XFER
> +direction: xfer direction - JTAG_SIR_XFER/JTAG_SDR_XFER,
> +length: xfer data len in bits
> +tdio : xfer data array
> +endir: xfer end state after transaction finish
endstate:
> + can be: JTAG_STATE_IDLE/JTAG_STATE_PAUSEIR/JTAG_STATE_PAUSEDR
> +
> +Example:
> + struct jtag_xfer xfer;
> + static char buf[64];
> + static unsigned int buf_len = 0;
> + [...]
> + xfer.type = JTAG_SDR_XFER;
> + xfer.tdio = (__u64)buf;
> + xfer.length = buf_len;
> + xfer.endstate = JTAG_STATE_IDLE;
> +
> + if (is_read)
> + xfer.direction = JTAG_READ_XFER;
> + else
> + xfer.direction = JTAG_WRITE_XFER;
> +
> + ioctl(jtag_fd, JTAG_IOCXFER, &xfer);
> +
> +JTAG_SIOCMODE
> +------
> +If hw driver can support different running modes you can change it.
> +
> +Example:
> + int mode;
+#define JTAG_SIOCMODE _IOW(__JTAG_IOCTL_MAGIC, 5, unsigned int)
so:
unsigned int mode;
> + mode = JTAG_XFER_HW_MODE;
> + ioctl(jtag_fd, JTAG_SIOCMODE, &mode);
>
--
~Randy
^ permalink raw reply
* [PATCH v3 1/8] arm/arm64: KVM: Formalise end of direct linear map
From: Marc Zyngier @ 2018-05-10 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510162347.3858-2-steve.capper@arm.com>
[+Christoffer]
Hi Steve,
On 10/05/18 17:23, Steve Capper wrote:
> We assume that the direct linear map ends at ~0 in the KVM HYP map
> intersection checking code. This assumption will become invalid later on
> for arm64 when the address space of the kernel is re-arranged.
>
> This patch introduces a new constant PAGE_OFFSET_END for both arm and
> arm64 and defines it to be ~0UL
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm/include/asm/memory.h | 1 +
> arch/arm64/include/asm/memory.h | 1 +
> virt/kvm/arm/mmu.c | 4 ++--
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ed8fd0d19a3e..45c211fd50da 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -24,6 +24,7 @@
>
> /* PAGE_OFFSET - the virtual address of the start of the kernel image */
> #define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
> +#define PAGE_OFFSET_END (~0UL)
>
> #ifdef CONFIG_MMU
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 49d99214f43c..c5617cbbf1ff 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -61,6 +61,7 @@
> (UL(1) << VA_BITS) + 1)
> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> (UL(1) << (VA_BITS - 1)) + 1)
> +#define PAGE_OFFSET_END (~0UL)
> #define KIMAGE_VADDR (MODULES_END)
> #define MODULES_END (MODULES_VADDR + MODULES_VSIZE)
> #define MODULES_VADDR (VA_START + KASAN_SHADOW_SIZE)
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 7f6a944db23d..22af347d65f1 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -1927,10 +1927,10 @@ int kvm_mmu_init(void)
> kvm_debug("IDMAP page: %lx\n", hyp_idmap_start);
> kvm_debug("HYP VA range: %lx:%lx\n",
> kern_hyp_va(PAGE_OFFSET),
> - kern_hyp_va((unsigned long)high_memory - 1));
> + kern_hyp_va(PAGE_OFFSET_END));
>
> if (hyp_idmap_start >= kern_hyp_va(PAGE_OFFSET) &&
> - hyp_idmap_start < kern_hyp_va((unsigned long)high_memory - 1) &&
> + hyp_idmap_start < kern_hyp_va(PAGE_OFFSET_END) &&
This doesn't feel right to me now that we have the HYP randomization
code merged. The way kern_hyp_va works now is only valid for addresses
between VA(memblock_start_of_DRAM()) and high_memory.
I fear that you could trigger the failing condition below as you
evaluate the idmap address against something that is now not a HYP VA.
> hyp_idmap_start != (unsigned long)__hyp_idmap_text_start) {
> /*
> * The idmap page is intersecting with the VA space,
>
I'd appreciate if you could keep me cc'd on this series.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 308/918] drivers/usb/dwc3/host.c:24:6: error: redefinition of 'dwc3_host_wakeup_capable'
From: kbuild test robot @ 2018-05-10 17:10 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 944a760cdb1098e23096c923aef70488fdbd501b
commit: c46d066e5633e178b138742850c37ed262a9af6d [308/918] dwc3: Add support for clock disabling during suspend
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c46d066e5633e178b138742850c37ed262a9af6d
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
>> drivers/usb/dwc3/host.c:24:6: error: redefinition of 'dwc3_host_wakeup_capable'
void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/usb/dwc3/host.c:20:0:
include/linux/usb/xhci_pdriver.h:25:6: note: previous definition of 'dwc3_host_wakeup_capable' was here
void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
^~~~~~~~~~~~~~~~~~~~~~~~
vim +/dwc3_host_wakeup_capable +24 drivers/usb/dwc3/host.c
23
> 24 void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
25 {
26 dwc3_simple_wakeup_capable(dev, wakeup);
27 }
28
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 49013 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/4a0c175f/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2] tty: pl011: Avoid spuriously stuck-off interrupts
From: Dave Martin @ 2018-05-10 17:08 UTC (permalink / raw)
To: linux-arm-kernel
Commit 9b96fbacda34 ("serial: PL011: clear pending interrupts")
clears the RX and receive timeout interrupts on pl011 startup, to
avoid a screaming-interrupt scenario that can occur when the
firmware or bootloader leaves these interrupts asserted.
This has been noted as an issue when running Linux on qemu [1].
Unfortunately, the above fix seems to lead to potential
misbehaviour if the RX FIFO interrupt is asserted _non_ spuriously
on driver startup, if the RX FIFO is also already full to the
trigger level.
Clearing the RX FIFO interrupt does not change the FIFO fill level.
In this scenario, because the interrupt is now clear and because
the FIFO is already full to the trigger level, no new assertion of
the RX FIFO interrupt can occur unless the FIFO is drained back
below the trigger level. This never occurs because the pl011
driver is waiting for an RX FIFO interrupt to tell it that there is
something to read, and does not read the FIFO at all until that
interrupt occurs.
Thus, simply clearing "spurious" interrupts on startup may be
misguided, since there is no way to be sure that the interrupts are
truly spurious, and things can go wrong if they are not.
This patch instead clears the interrupt condition by draining the
RX FIFO during UART startup, after clearing any potentially
spurious interrupt. This should ensure that an interrupt will
definitely be asserted if the RX FIFO subsequently becomes
sufficiently full.
The drain is done at the point of enabling interrupts only. This
means that it will occur any time the UART is newly opened through
the tty layer. It will not apply to polled-mode use of the UART by
kgdboc: since that scenario cannot use interrupts by design, this
should not matter. kgdboc will interact badly with "normal" use of
the UART in any case: this patch makes no attempt to paper over
such issues.
This patch does not attempt to address the case where the RX FIFO
fills faster than it can be drained: that is a pathological
hardware design problem that is beyond the scope of the driver to
work around. As a failsafe, the number of poll iterations for
draining the FIFO is limited to twice the FIFO size. This will
ensure that the kernel at least boots even if it is impossible to
drain the FIFO for some reason.
[1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo
before enabled the interruption
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html
Reported-by: Wei Xu <xuwei5@hisilicon.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
Fixes: 9b96fbacda34 ("serial: PL011: clear pending interrupts")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
Changes since v1 [1]
* Deleted Andrew Jones' Reviewed/Tested-bys due to the following
change.
If you can please retest that the updated patch fixes your
issue that would be appreciated.
Suggested by Russell King:
* Only drain 2 * FIFO size, to avoid going into an infinite spin
if something does wrong. If the FIFO still couldn't be drained
sufficiently then pl011 RX won't work properly, but the kernel
will at least boot.
[1] [PATCH] tty: pl011: Avoid spuriously stuck-off interrupts
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/574362.html
---
drivers/tty/serial/amba-pl011.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 4b40a5b..ebd33c0 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1727,10 +1727,26 @@ static int pl011_allocate_irq(struct uart_amba_port *uap)
*/
static void pl011_enable_interrupts(struct uart_amba_port *uap)
{
+ unsigned int i;
+
spin_lock_irq(&uap->port.lock);
/* Clear out any spuriously appearing RX interrupts */
pl011_write(UART011_RTIS | UART011_RXIS, uap, REG_ICR);
+
+ /*
+ * RXIS is asserted only when the RX FIFO transitions from below
+ * to above the trigger threshold. If the RX FIFO is already
+ * full to the threshold this can't happen and RXIS will now be
+ * stuck off. Drain the RX FIFO explicitly to fix this:
+ */
+ for (i = 0; i < uap->fifosize * 2; ++i) {
+ if (pl011_read(uap, REG_FR) & UART01x_FR_RXFE)
+ break;
+
+ pl011_read(uap, REG_DR);
+ }
+
uap->im = UART011_RTIM;
if (!pl011_dma_rx_running(uap))
uap->im |= UART011_RXIM;
--
2.1.4
^ permalink raw reply related
* [xlnx:xlnx_rebase_v4.14 132/918] drivers/misc/jesd204b/xilinx_jesd204b.c:29:17: error: field 'hw' has incomplete type
From: kbuild test robot @ 2018-05-10 16:56 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 944a760cdb1098e23096c923aef70488fdbd501b
commit: 5d774267f2dcee0cd5158b9ebe3bb58a0fd984e1 [132/918] jesd204b: move the current driver to a folder
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5d774267f2dcee0cd5158b9ebe3bb58a0fd984e1
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
>> drivers/misc/jesd204b/xilinx_jesd204b.c:29:17: error: field 'hw' has incomplete type
struct clk_hw hw;
^~
In file included from include/linux/err.h:5:0,
from include/linux/clk.h:15,
from drivers/misc/jesd204b/xilinx_jesd204b.c:11:
drivers/misc/jesd204b/xilinx_jesd204b.c: In function 'jesd204b_clk_enable':
>> include/linux/kernel.h:929:32: error: dereferencing pointer to incomplete type 'struct clk_hw'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~~~
include/linux/compiler.h:554:19: note: in definition of macro '__compiletime_assert'
bool __cond = !(condition); \
^~~~~~~~~
include/linux/compiler.h:577:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:47:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/kernel.h:929:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~~~~~~~~~~~~~
include/linux/kernel.h:929:20: note: in expansion of macro '__same_type'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:35:26: note: in expansion of macro 'container_of'
#define to_clk_priv(_hw) container_of(_hw, struct child_clk, hw)
^~~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:215:2: note: in expansion of macro 'to_clk_priv'
to_clk_priv(hw)->enabled = true;
^~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c: At top level:
>> drivers/misc/jesd204b/xilinx_jesd204b.c:230:21: error: variable 'clkout_ops' has initializer but incomplete type
static const struct clk_ops clkout_ops = {
^~~~~~~
>> drivers/misc/jesd204b/xilinx_jesd204b.c:231:3: error: 'const struct clk_ops' has no member named 'recalc_rate'
.recalc_rate = jesd204b_clk_recalc_rate,
^~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:231:17: warning: excess elements in struct initializer
.recalc_rate = jesd204b_clk_recalc_rate,
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:231:17: note: (near initialization for 'clkout_ops')
>> drivers/misc/jesd204b/xilinx_jesd204b.c:232:3: error: 'const struct clk_ops' has no member named 'enable'
.enable = jesd204b_clk_enable,
^~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:232:12: warning: excess elements in struct initializer
.enable = jesd204b_clk_enable,
^~~~~~~~~~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:232:12: note: (near initialization for 'clkout_ops')
>> drivers/misc/jesd204b/xilinx_jesd204b.c:233:3: error: 'const struct clk_ops' has no member named 'disable'
.disable = jesd204b_clk_disable,
^~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:233:13: warning: excess elements in struct initializer
.disable = jesd204b_clk_disable,
^~~~~~~~~~~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:233:13: note: (near initialization for 'clkout_ops')
>> drivers/misc/jesd204b/xilinx_jesd204b.c:234:3: error: 'const struct clk_ops' has no member named 'is_enabled'
.is_enabled = jesd204b_clk_is_enabled,
^~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:234:16: warning: excess elements in struct initializer
.is_enabled = jesd204b_clk_is_enabled,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:234:16: note: (near initialization for 'clkout_ops')
drivers/misc/jesd204b/xilinx_jesd204b.c: In function 'jesd204b_probe':
>> drivers/misc/jesd204b/xilinx_jesd204b.c:252:23: error: storage size of 'init' isn't known
struct clk_init_data init;
^~~~
drivers/misc/jesd204b/xilinx_jesd204b.c:252:23: warning: unused variable 'init' [-Wunused-variable]
drivers/misc/jesd204b/xilinx_jesd204b.c: At top level:
>> drivers/misc/jesd204b/xilinx_jesd204b.c:230:29: error: storage size of 'clkout_ops' isn't known
static const struct clk_ops clkout_ops = {
^~~~~~~~~~
vim +/hw +29 drivers/misc/jesd204b/xilinx_jesd204b.c
26
27
28 struct child_clk {
> 29 struct clk_hw hw;
30 struct jesd204b_state *st;
31 unsigned long rate;
32 bool enabled;
33 };
34
> 35 #define to_clk_priv(_hw) container_of(_hw, struct child_clk, hw)
36
37 static inline void jesd204b_write(struct jesd204b_state *st,
38 unsigned reg, unsigned val)
39 {
40 iowrite32(val, st->regs + reg);
41 }
42
43 static inline unsigned int jesd204b_read(struct jesd204b_state *st,
44 unsigned reg)
45 {
46 return ioread32(st->regs + reg);
47 }
48
49 static ssize_t jesd204b_laneinfo_read(struct device *dev,
50 struct device_attribute *attr,
51 char *buf, unsigned lane)
52 {
53 struct jesd204b_state *st = dev_get_drvdata(dev);
54 int ret;
55 unsigned val1, val2, val3;
56
57 val1 = jesd204b_read(st, XLNX_JESD204_REG_ID_L(lane));
58 val2 = jesd204b_read(st, XLNX_JESD204_REG_LANE_F(lane));
59 val3 = jesd204b_read(st, XLNX_JESD204_REG_SCR_S_HD_CF(lane));
60 ret = sprintf(buf,
61 "DID: %d, BID: %d, LID: %d, L: %d, SCR: %d, F: %d\n",
62 XLNX_JESD204_LANE_DID(val1),
63 XLNX_JESD204_LANE_BID(val1),
64 XLNX_JESD204_LANE_LID(val1),
65 XLNX_JESD204_LANE_L(val1),
66 XLNX_JESD204_LANE_SCR(val3),
67 XLNX_JESD204_LANE_F(val2));
68
69 val1 = jesd204b_read(st, XLNX_JESD204_REG_LANE_K(lane));
70 val2 = jesd204b_read(st, XLNX_JESD204_REG_M_N_ND_CS(lane));
71
72 ret += sprintf(buf + ret,
73 "K: %d, M: %d, N: %d, CS: %d, S: %d, N': %d, HD: %d\n",
74 XLNX_JESD204_LANE_K(val1),
75 XLNX_JESD204_LANE_M(val2),
76 XLNX_JESD204_LANE_N(val2),
77 XLNX_JESD204_LANE_CS(val2),
78 XLNX_JESD204_LANE_S(val3),
79 XLNX_JESD204_LANE_ND(val2),
80 XLNX_JESD204_LANE_HD(val3));
81
82 val1 = jesd204b_read(st, XLNX_JESD204_REG_FCHK(lane));
83 ret += sprintf(buf + ret, "FCHK: 0x%X, CF: %d\n",
84 XLNX_JESD204_LANE_FCHK(val1),
85 XLNX_JESD204_LANE_CF(val3));
86
87 val1 = jesd204b_read(st, XLNX_JESD204_REG_SC2_ADJ_CTRL(lane));
88 val2 = jesd204b_read(st, XLNX_JESD204_REG_LANE_VERSION(lane));
89 ret += sprintf(buf + ret,
90 "ADJCNT: %d, PHYADJ: %d, ADJDIR: %d, JESDV: %d, SUBCLASS: %d\n",
91 XLNX_JESD204_LANE_ADJ_CNT(val1),
92 XLNX_JESD204_LANE_PHASE_ADJ_REQ(val1),
93 XLNX_JESD204_LANE_ADJ_CNT_DIR(val1),
94 XLNX_JESD204_LANE_JESDV(val2),
95 XLNX_JESD204_LANE_SUBCLASS(val2));
96
97 ret += sprintf(buf + ret, "MFCNT : 0x%X\n",
98 jesd204b_read(st, XLNX_JESD204_REG_TM_MFC_CNT(lane)));
99 ret += sprintf(buf + ret, "ILACNT: 0x%X\n",
100 jesd204b_read(st, XLNX_JESD204_REG_TM_ILA_CNT(lane)));
101 ret += sprintf(buf + ret, "ERRCNT: 0x%X\n",
102 jesd204b_read(st, XLNX_JESD204_REG_TM_ERR_CNT(lane)));
103 ret += sprintf(buf + ret, "BUFCNT: 0x%X\n",
104 jesd204b_read(st, XLNX_JESD204_REG_TM_BUF_ADJ(lane)));
105 ret += sprintf(buf + ret, "LECNT: 0x%X\n",
106 jesd204b_read(st,
107 XLNX_JESD204_REG_TM_LINK_ERR_CNT(lane)));
108
109 ret += sprintf(buf + ret, "FC: %lu\n", st->rate);
110
111 return ret;
112 }
113
114 #define JESD_LANE(_x) \
115 static ssize_t jesd204b_lane##_x##_info_read(struct device *dev, \
116 struct device_attribute *attr, \
117 char *buf) \
118 { \
119 return jesd204b_laneinfo_read(dev, attr, buf, _x); \
120 } \
121 static DEVICE_ATTR(lane##_x##_info, S_IRUSR, jesd204b_lane##_x##_info_read, \
122 NULL)
123
124 JESD_LANE(0);
125 JESD_LANE(1);
126 JESD_LANE(2);
127 JESD_LANE(3);
128 JESD_LANE(4);
129 JESD_LANE(5);
130 JESD_LANE(6);
131 JESD_LANE(7);
132
133 static ssize_t jesd204b_lane_syscstat_read(struct device *dev,
134 struct device_attribute *attr,
135 char *buf, unsigned lane)
136 {
137 struct jesd204b_state *st = dev_get_drvdata(dev);
138 unsigned stat;
139
140 stat = jesd204b_read(st, XLNX_JESD204_REG_SYNC_ERR_STAT);
141
142 return sprintf(buf,
143 "NOT_IN_TAB: %d, DISPARITY: %d, UNEXPECTED_K: %d\n",
144 stat & XLNX_JESD204_SYNC_ERR_NOT_IN_TAB(lane),
145 stat & XLNX_JESD204_SYNC_ERR_DISPARITY(lane),
146 stat & XLNX_JESD204_SYNC_ERR_UNEXPECTED_K(lane));
147 }
148
149 #define JESD_SYNCSTAT_LANE(_x) \
150 static ssize_t jesd204b_lane##_x##_syncstat_read(struct device *dev, \
151 struct device_attribute *attr,\
152 char *buf) \
153 { \
154 return jesd204b_lane_syscstat_read(dev, attr, buf, _x); \
155 } \
156 static DEVICE_ATTR(lane##_x##_syncstat, S_IRUSR, \
157 jesd204b_lane##_x##_syncstat_read, NULL)
158
159 JESD_SYNCSTAT_LANE(0);
160 JESD_SYNCSTAT_LANE(1);
161 JESD_SYNCSTAT_LANE(2);
162 JESD_SYNCSTAT_LANE(3);
163 JESD_SYNCSTAT_LANE(4);
164 JESD_SYNCSTAT_LANE(5);
165 JESD_SYNCSTAT_LANE(6);
166 JESD_SYNCSTAT_LANE(7);
167
168 static ssize_t jesd204b_reg_write(struct device *dev,
169 struct device_attribute *attr,
170 const char *buf, size_t count)
171 {
172 struct jesd204b_state *st = dev_get_drvdata(dev);
173 unsigned val;
174 int ret;
175
176 ret = sscanf(buf, "%i %i", &st->addr, &val);
177 if (ret == 2)
178 jesd204b_write(st, st->addr, val);
179
180 return count;
181 }
182
183 static ssize_t jesd204b_reg_read(struct device *dev,
184 struct device_attribute *attr,
185 char *buf)
186 {
187 struct jesd204b_state *st = dev_get_drvdata(dev);
188
189 return sprintf(buf, "0x%X\n", jesd204b_read(st, st->addr));
190 }
191
192 static DEVICE_ATTR(reg_access, S_IWUSR | S_IRUSR, jesd204b_reg_read,
193 jesd204b_reg_write);
194
195 static ssize_t jesd204b_syncreg_read(struct device *dev,
196 struct device_attribute *attr,
197 char *buf)
198 {
199 struct jesd204b_state *st = dev_get_drvdata(dev);
200
201 return sprintf(buf, "0x%X\n", jesd204b_read(st,
202 XLNX_JESD204_REG_SYNC_STATUS));
203 }
204
205 static DEVICE_ATTR(sync_status, S_IRUSR, jesd204b_syncreg_read, NULL);
206
207 static unsigned long jesd204b_clk_recalc_rate(struct clk_hw *hw,
208 unsigned long parent_rate)
209 {
210 return parent_rate;
211 }
212
213 static int jesd204b_clk_enable(struct clk_hw *hw)
214 {
> 215 to_clk_priv(hw)->enabled = true;
216
217 return 0;
218 }
219
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 48869 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180511/a7bfeef0/attachment-0001.gz>
^ permalink raw reply
* [PATCH v7 13/16] KVM: arm64: Remove eager host SVE state saving
From: Catalin Marinas @ 2018-05-10 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-14-git-send-email-Dave.Martin@arm.com>
On Wed, May 09, 2018 at 05:13:02PM +0100, Dave P Martin wrote:
> Now that the host SVE context can be saved on demand from Hyp,
> there is no longer any need to save this state in advance before
> entering the guest.
>
> This patch removes the relevant call to
> kvm_fpsimd_flush_cpu_state().
>
> Since the problem that function was intended to solve now no longer
> exists, the function and its dependencies are also deleted.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v7 12/16] KVM: arm64: Save host SVE context as appropriate
From: Catalin Marinas @ 2018-05-10 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-13-git-send-email-Dave.Martin@arm.com>
On Wed, May 09, 2018 at 05:13:01PM +0100, Dave P Martin wrote:
> This patch adds SVE context saving to the hyp FPSIMD context switch
> path. This means that it is no longer necessary to save the host
> SVE state in advance of entering the guest, when in use.
>
> In order to avoid adding pointless complexity to the code, VHE is
> assumed if SVE is in use. VHE is an architectural prerequisite for
> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> kernels that support both SVE and KVM.
>
> Historically, software models exist that can expose the
> architecturally invalid configuration of SVE without VHE, so if
> this situation is detected at kvm_init() time then KVM will be
> disabled.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/Kconfig | 7 +++++++
> arch/arm64/kvm/fpsimd.c | 1 -
> arch/arm64/kvm/hyp/switch.c | 20 +++++++++++++++++++-
> virt/kvm/arm/arm.c | 18 ++++++++++++++++++
> 4 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index eb2cf49..b0d3820 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1130,6 +1130,7 @@ endmenu
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> + depends on !KVM || ARM64_VHE
> help
> The Scalable Vector Extension (SVE) is an extension to the AArch64
> execution state which complements and extends the SIMD functionality
> @@ -1155,6 +1156,12 @@ config ARM64_SVE
> booting the kernel. If unsure and you are not observing these
> symptoms, you should assume that it is safe to say Y.
>
> + CPUs that support SVE are architecturally required to support the
> + Virtualization Host Extensions (VHE), so the kernel makes no
> + provision for supporting SVE alongside KVM without VHE enabled.
> + Thus, you will need to enable CONFIG_ARM64_VHE if you want to support
> + KVM in the same kernel image.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v7 08/16] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
From: Catalin Marinas @ 2018-05-10 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-9-git-send-email-Dave.Martin@arm.com>
On Wed, May 09, 2018 at 05:12:57PM +0100, Dave P Martin wrote:
> This patch refactors KVM to align the host and guest FPSIMD
> save/restore logic with each other for arm64. This reduces the
> number of redundant save/restore operations that must occur, and
> reduces the common-case IRQ blackout time during guest exit storms
> by saving the host state lazily and optimising away the need to
> restore the host state before returning to the run loop.
>
> Four hooks are defined in order to enable this:
>
> * kvm_arch_vcpu_run_map_fp():
> Called on PID change to map necessary bits of current to Hyp.
>
> * kvm_arch_vcpu_load_fp():
> Set up FP/SIMD for entering the KVM run loop (parse as
> "vcpu_load fp").
>
> * kvm_arch_vcpu_ctxsync_fp():
> Get FP/SIMD into a safe state for re-enabling interrupts after a
> guest exit back to the run loop.
>
> For arm64 specifically, this involves updating the host kernel's
> FPSIMD context tracking metadata so that kernel-mode NEON use
> will cause the vcpu's FPSIMD state to be saved back correctly
> into the vcpu struct. This must be done before re-enabling
> interrupts because kernel-mode NEON may be used by softirqs.
>
> * kvm_arch_vcpu_put_fp():
> Save guest FP/SIMD state back to memory and dissociate from the
> CPU ("vcpu_put fp").
>
> Also, the arm64 FPSIMD context switch code is updated to enable it
> to save back FPSIMD state for a vcpu, not just current. A few
> helpers drive this:
>
> * fpsimd_bind_state_to_cpu(struct user_fpsimd_state *fp):
> mark this CPU as having context fp (which may belong to a vcpu)
> currently loaded in its registers. This is the non-task
> equivalent of the static function fpsimd_bind_to_cpu() in
> fpsimd.c.
>
> * task_fpsimd_save():
> exported to allow KVM to save the guest's FPSIMD state back to
> memory on exit from the run loop.
>
> * fpsimd_flush_state():
> invalidate any context's FPSIMD state that is currently loaded.
> Used to disassociate the vcpu from the CPU regs on run loop exit.
>
> These changes allow the run loop to enable interrupts (and thus
> softirqs that may use kernel-mode NEON) without having to save the
> guest's FPSIMD state eagerly.
>
> Some new vcpu_arch fields are added to make all this work. Because
> host FPSIMD state can now be saved back directly into current's
> thread_struct as appropriate, host_cpu_context is no longer used
> for preserving the FPSIMD state. However, it is still needed for
> preserving other things such as the host's system registers. To
> avoid ABI churn, the redundant storage space in host_cpu_context is
> not removed for now.
>
> arch/arm is not addressed by this patch and continues to use its
> current save/restore logic. It could provide implementations of
> the helpers later if desired.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77970: add SMP support
From: Sergei Shtylyov @ 2018-05-10 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509190517.ho5og3grbuzf4wz4@verge.net.au>
Hello!
On 05/09/2018 10:05 PM, Simon Horman wrote:
>>>> Add the device node for the second Cortex-A53 CPU core.
>>>>
>>>> Based on the original (and large) patch by Daisuke Matsushita
>>>> <daisuke.matsushita.ns@hitachi.com>.
>>>>
>>>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>
>>> Dupe of https://patchwork.kernel.org/patch/10032875/
>>
>> Sorry!
>> Not an exact dupe, though -- mine has clock/power #define's used,
>> yours -- only bare #s. :-)
>>
>>> From series "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
>>> (https://www.spinics.net/lists/linux-renesas-soc/msg19681.html)
>>
>> Hmm... what's the fate of this series?
>
> There is now a v2 of Geert's series which incorporates your enhancements.
I suggested to respin it. :-)
> I will apply that.
Thank you.
For the record, I had better luck than Geert testing SMP on Eagle: only CPU0
couldn't be offlined (and I was unable to find a workaround), others could be on/
offlined w/o issues. As for suspend/resume -- it did work but I could only test
s2idle (/sys/power/mem_sleep had no other variants)...
MBR, Sergei
^ permalink raw reply
* [PATCH] kvm: Change return type to vm_fault_t
From: Paolo Bonzini @ 2018-05-10 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180418191958.GA25806@jordon-HP-15-Notebook-PC>
On 18/04/2018 21:19, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
> ---
> arch/mips/kvm/mips.c | 2 +-
> arch/powerpc/kvm/powerpc.c | 2 +-
> arch/s390/kvm/kvm-s390.c | 2 +-
> arch/x86/kvm/x86.c | 2 +-
> include/linux/kvm_host.h | 2 +-
> virt/kvm/arm/arm.c | 2 +-
> virt/kvm/kvm_main.c | 2 +-
> 7 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 2549fdd..03e0e0f 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -1076,7 +1076,7 @@ int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
> return -ENOIOCTLCMD;
> }
>
> -int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> +vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> {
> return VM_FAULT_SIGBUS;
> }
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 403e642..3099dee 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1825,7 +1825,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> return r;
> }
>
> -int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> +vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> {
> return VM_FAULT_SIGBUS;
> }
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index ba4c709..24af487 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3941,7 +3941,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> return r;
> }
>
> -int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> +vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> {
> #ifdef CONFIG_KVM_S390_UCONTROL
> if ((vmf->pgoff == KVM_S390_SIE_PAGE_OFFSET)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c8a0b54..95d8102 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3827,7 +3827,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> return r;
> }
>
> -int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> +vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> {
> return VM_FAULT_SIGBUS;
> }
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index ac0062b..8eeb062 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -736,7 +736,7 @@ long kvm_arch_dev_ioctl(struct file *filp,
> unsigned int ioctl, unsigned long arg);
> long kvm_arch_vcpu_ioctl(struct file *filp,
> unsigned int ioctl, unsigned long arg);
> -int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf);
> +vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf);
>
> int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext);
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 86941f6..6c8cc31 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -163,7 +163,7 @@ int kvm_arch_create_vcpu_debugfs(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> -int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> +vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
> {
> return VM_FAULT_SIGBUS;
> }
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 4501e65..45eb54b 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2341,7 +2341,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool yield_to_kernel_mode)
> }
> EXPORT_SYMBOL_GPL(kvm_vcpu_on_spin);
>
> -static int kvm_vcpu_fault(struct vm_fault *vmf)
> +static vm_fault_t kvm_vcpu_fault(struct vm_fault *vmf)
> {
> struct kvm_vcpu *vcpu = vmf->vma->vm_file->private_data;
> struct page *page;
> --
> 1.9.1
>
Applied, thanks.
Paolo
^ permalink raw reply
* [PATCH v7 06/16] arm64/sve: Refactor user SVE trap maintenance for external use
From: Catalin Marinas @ 2018-05-10 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525882385-29181-7-git-send-email-Dave.Martin@arm.com>
On Wed, May 09, 2018 at 05:12:55PM +0100, Dave P Martin wrote:
> In preparation for optimising the way KVM manages switching the
> guest and host FPSIMD state, it is necessary to provide a means for
> code outside arch/arm64/kernel/fpsimd.c to restore the user trap
> configuration for SVE correctly for the current task.
>
> Rather than requiring external code to duplicate the maintenance
> explicitly, this patch wraps moves the trap maintenenace to
> fpsimd_bind_to_cpu(), since it is logically part of the work of
> associating the current task with the cpu.
>
> Because fpsimd_bind_to_cpu() is rather a cryptic name to publish
> alongside fpsimd_bind_state_to_cpu(), the former function is
> renamed to fpsimd_bind_task_to_cpu() to make its purpose more
> explicit.
>
> This patch makes appropriate changes to ensure that
> fpsimd_bind_task_to_cpu() is always called alongside
> task_fpsimd_load(), so that the trap maintenance continues to be
> done in every situation where it was done prior to this patch.
>
> As a side-effect, the metadata updates done by
> fpsimd_bind_task_to_cpu() now change from conditional to
> unconditional in the "already bound" case of sigreturn. This is
> harmless, and a couple of extra stores on this slow path will not
> impact performance. I consider this a reasonable price to pay for
> a slightly cleaner interface.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ 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