* [PATCH] BUG: atmel_serial: Interrupts not disabled on close
From: Nicolas Ferre @ 2016-09-12 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912133441.14597-1-richard.genoud@gmail.com>
Le 12/09/2016 ? 15:34, Richard Genoud a ?crit :
> Since commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
> provided mctrl-gpio"), interrupts from GPIOs are not disabled any more
> when the serial port is closed, leading to an oops when the one of the
> input pin is toggled (CTS/DSR/DCD/RNG).
>
> This is only the case if those pins are used as GPIOs, i.e. declared
> like that:
> usart1: serial at f8020000 {
> /* CTS and DTS will be handled by GPIO */
> status = "okay";
> rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>;
> cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>;
> dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>;
> dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
> rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>;
> dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>;
> };
>
> That's because modem interrupts used to be freed in atmel_shutdown().
> After commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
> provided mctrl-gpio"), this code was just removed.
> Calling atmel_disable_ms() disables the interrupts and everything works
> fine again.
>
> Tested on at91sam9g35-cm
>
> (This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will
> be sent after this one is applied.)
>
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> Fixes: 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio")
I thinks it's a bit late for "4.8-fixes".
Greg, tell me if you want that I add the Cc: stable tag to this patch
(as advised by Uwe) and re-send?
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Richard!
Best regards,
> ---
> drivers/tty/serial/atmel_serial.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 2eaa18ddef61..8bbde52db376 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1929,6 +1929,9 @@ static void atmel_shutdown(struct uart_port *port)
> {
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>
> + /* Disable modem control lines interrupts */
> + atmel_disable_ms(port);
> +
> /* Disable interrupts at device level */
> atmel_uart_writel(port, ATMEL_US_IDR, -1);
>
> @@ -1979,8 +1982,6 @@ static void atmel_shutdown(struct uart_port *port)
> */
> free_irq(port->irq, port);
>
> - atmel_port->ms_irq_enabled = false;
> -
> atmel_flush_buffer(port);
> }
>
>
--
Nicolas Ferre
^ permalink raw reply
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Dave Martin @ 2016-09-12 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1acabcd8-a259-4129-cee3-100401074c9d@redhat.com>
On Mon, Sep 12, 2016 at 02:49:20PM +0200, Florian Weimer wrote:
> On 09/12/2016 01:17 PM, Dave Martin wrote:
>
> >>>If the stack isn't large enough, we'll still have to SEGV the task
> >>>though.
> >>
> >>You could skip copying the data and not install a pointer to it in the
> >>existing signal context.
> >
> >We could, but then we'd corrupt the task state in sigreturn, since
> >we wouldn't have been able to save/restore part of the state.
>
> Ah, I wasn't aware that the kernel doesn't have a copy of the state. Could
> the kernel reserve space for it when sigaltstack is called?
Signals can be nested without limit.
If you record some state in the kernel, it's also hard to track when it
can be freed if userspace leaves the signal handler by other means than
sigreturn() (say, longjmp() or setcontext()).
> >The least-wrong thing I can think of to do is:
> >
> >* deprecate but continue to support the existing sigaltstack API/ABI
> >with today's {,MIN}SIGSTKSZ definitions
>
> There is also PTHREAD_STACK_MIN. The glibc default for that (which is
> overriden by some architectures) is 16 KiB. It is also quite small; see the
> sequence of events mentioned here:
>
> <https://sourceware.org/bugzilla/show_bug.cgi?id=20249>
It's a related issue, though this doesn't look to me like a bug. Why
should something like vfprintf() fit in PTHREAD_STACK_MIN bytes of stack?
> >* guarantee (as much as possible) that software using this ABI continues
> >to work (by saving/restoring only data that _must_ be saved/restored at
> >each signal, which may be small enough to fit)
> >
> >* providing a clean failure mode (fatal signal) when this proves
> >impossible at signal delivery/return time;
> >
> >* define a new interface for runtime-querying the required signal stack
> >size;
> >
> >* define a new syscall or new stack_t.ss_flags flags (say, SS_STRICT)
> >that permits the kernel to enforce a runtime-determined minimum greater
> >than MINSIGSTKSZ when calling sigaltstack().
> >
> >
> >Another option would be:
> >
> >* define a new interface for runtime-querying the required signal stack
> >size, and
> >
> >* support the current API/ABI, but make a call to sigaltstack() SEGV or
> >SIGILL the caller if it specifies ss_stack >= MINSIGSTKSZ but smaller
> >than the actual runtime minimum.
> >
> >(this would cause old software to break immediately in an obvious way on
> >new systems, forcing people to fix their software -- which they might or
> >might not actually bother to do).
>
> The second option looks a bit problematic from a support perspective.
Well, indeed :(
> Do you think it would be possible to block access to hardware features that
> cause signal stack bloat on a per-process basis? Then we could bump the
> kernel requirement enforced by sigaltstack directly for the default, and
> define a compatibility personality that minimizes the signal stack size for
> old applications. (A way to query the required alternative signal stack
> size would still come in handy, though.)
This can be done, in general, but it blocks current software from using
libraries that make internal use of a new arch feature, even if those
libraries' exported ABIs don't depend on the feature.
This would make the new feature unusable until/unless you rebuild the
world.
There's no perfect solution; rather I want to arrive at something
pragmatic that doesn't break existing software unnecessarily.
I designed the extra_context mechnism gets added only if something is
allocated to the signal frame at runtime, so software running on
hardware that doesn't have the new extension, and processes that never
make use of the new extension (even in libraries) would be unaffected.
Programs that are unaware of the extension, but use sigaltstack() _and_
also use libraries that use the extension may get SEGV'd due to failed
signal delivery.
If this is still not good enough, I may have to rethink...
We _could_ save some state in the kernel, but that will add a lot of
complexity in the kernel, and probably still won't cover all
cases.
Cheers
---Dave
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Brendan Jackman @ 2016-09-12 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160902201605.GA1705@linaro.org>
Hi Lina,
Sorry for the delay here, Sudeep and I were both been on holiday last week.
On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote:
> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote:
[...]
>>This version is *not very descriptive*. Also the discussion we had on v3
>>version has not yet concluded IMO. So can I take that we agreed on what
>>was proposed there or not ?
>>
> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi
> for the new changes in the following patches. Let me know if that makes
> sense.
The not-yet-concluded discussion Sudeep is referring to is at [1].
In that thread we initially proposed the idea of, instead of splitting
state phandles between cpu-idle-states and domain-idle-states, putting
CPUs in their own domains and using domain-idle-states for _all_
phandles, deprecating cpu-idle-states. I've brought this up in other
threads [2] but discussion keeps petering out, and neither this example
nor the 8916 dtsi in this patch series reflect the idea.
It would be great if we could go back to the thread at [1] where Sudeep
has posted examples and come to a clear consensus on the binding design
before reviewing implementation patches. Ideally with input from Ulf,
Rob and Kevin.
[1] https://patchwork.kernel.org/patch/9264507
[2] http://www.spinics.net/lists/devicetree/msg141024.html
>
> Thanks,
> Lina
>
>>We could have better example above *really* based on the discussions we
>>had so far. This example always makes me think it's well crafted to
>>avoid any sort of discussions. We need to consider different use-cases
>>e.g. what about CPU level states ?
>>
>>IMO, we need to discuss this DT binding in detail and arrive at someq
>>conclusion before you take all the troubles to respin the series.
>>Also it's better to keep the DT binding separate until we have some
>>conclusion instead of posting the implementation for each version.
>>That's just my opinion(I would be least bothered about implementation
>>until I know it will be accepted before I can peek into the code, others
>>may differ.
>>
>>--
>>Regards,
>>Sudeep
Cheers,
Brendan
^ permalink raw reply
* [PATCH][V3] dma-mapping: add in missing white space in error message text
From: Colin King @ 2016-09-12 15:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
A dev_warn message spans two lines and the literal string is missing
a white space between words. Add the white space and reformat the
literal string to not span multiple lines.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/arm/common/dmabounce.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 3012816..aef19d9 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -547,8 +547,7 @@ void dmabounce_unregister_dev(struct device *dev)
if (!device_info) {
dev_warn(dev,
- "Never registered with dmabounce but attempting"
- "to unregister!\n");
+ "Never registered with dmabounce but attempting to unregister!\n");
return;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/3] clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK
From: Fabio Estevam @ 2016-09-12 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACrMeVA8CdL-Fqa4NwmBUPvzBXsi=o8bpB_tY2-Z0-xCoMX3xA@mail.gmail.com>
Hi Akshay and Charles,
On Mon, Sep 12, 2016 at 12:09 PM, Akshay Bhat <akshay.bhat@timesys.com> wrote:
> Hi Fabio, Shawn,
>
> Advantech tested the v5 patch series on imx6q-b450v3 board (with 4.7
> kernel) and confirmed the patch fixes the lvds blank display issue
> being seen on some imx6q-b450v3 boards.
>
> Details below:
> With the patch applied:
> Board # 1: 100 times power on/off, no LVDS display failure
> Board # 2: 100 times power on/off, no LVDS display failure
>
> Without the patch:
> Board # 1: LVDS display failure (blank display output) at 4th time power on/off.
> Board # 2: LVDS display failure (blank display output) at 3rd time power on/off.
>
> Tested-by: Charles Kang <Charles.Kang@advantech.com.tw>
Thanks for testing it.
> Since the patch has been reviewed and confirmed to fix display
> failures on 2 different boards (imx6q-evi and imx6q-b450v3), can it be
> applied?
Yes, I think this series is in a good shape now.
Shawn,
Are you happy with it?
Thanks
^ permalink raw reply
* [PATCH v3 3/9] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: Andrew Lunn @ 2016-09-12 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912150125.GA15570@Red>
> Hello
>
> Since the MDIO bus is a part of the sun8i-emac, does I really need
> to create such a mdio node ?
It is good practice. Part of the issue is that there are no written
guidelines, so different drivers do different things. I'm trying to
push all new drivers to have an MDIO node.
> Anyway I try the following patch to solve your comments, but it
> breaks the PHY finding(Could not attach to PHY).
> --- a/drivers/net/ethernet/allwinner/sun8i-emac.c
> +++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
> @@ -2122,7 +2122,7 @@ static int sun8i_emac_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - priv->phy_node = of_parse_phandle(node, "phy", 0);
> + priv->phy_node = of_parse_phandle(node, "phy-handle", 0);
> if (!priv->phy_node) {
> netdev_err(ndev, "No associated PHY\n");
> return -ENODEV;
>
>
> &crypto {
>
I don't see a change here for of_mdiobus_register(). You need to pass
the mdio node.
Andrew
^ permalink raw reply
* [PATCH] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Ard Biesheuvel @ 2016-09-12 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912145931.GB14165@leverpostej>
On 12 September 2016 at 15:59, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Ard,
>
> On Mon, Sep 12, 2016 at 03:16:24PM +0100, Ard Biesheuvel wrote:
>> static inline void cpu_set_reserved_ttbr0(void)
>> {
>> - unsigned long ttbr = virt_to_phys(empty_zero_page);
>> -
>> - asm(
>> - " msr ttbr0_el1, %0 // set TTBR0\n"
>> - " isb"
>> - :
>> - : "r" (ttbr));
>> + /*
>> + * The zero page is located right before swapper_pg_dir, whose
>> + * physical address we can easily fetch from TTBR1_EL1.
>> + */
>> + write_sysreg(read_sysreg(ttbr1_el1) - PAGE_SIZE, ttbr0_el1);
>> + isb();
>> }
>
> As a heads-up, in arm64 for-next/core this is a write_sysreg() and an
> isb() thanks to [1,2]. This will need a rebase to avoid conflict.
>
OK, I will rebase onto for-next/core for v3, if needed.
>> /*
>> @@ -109,7 +108,8 @@ static inline void cpu_uninstall_idmap(void)
>> {
>> struct mm_struct *mm = current->active_mm;
>>
>> - cpu_set_reserved_ttbr0();
>> + write_sysreg(virt_to_phys(empty_zero_page), ttbr0_el1);
>> + isb();
>> local_flush_tlb_all();
>> cpu_set_default_tcr_t0sz();
>>
>> @@ -119,7 +119,8 @@ static inline void cpu_uninstall_idmap(void)
>>
>> static inline void cpu_install_idmap(void)
>> {
>> - cpu_set_reserved_ttbr0();
>> + write_sysreg(virt_to_phys(empty_zero_page), ttbr0_el1);
>> + isb();
>> local_flush_tlb_all();
>> cpu_set_idmap_tcr_t0sz();
>
> It would be worth a comment as to why we have to open-code these, so as
> to avoid "obvious" / "trivial cleanup" patches to this later. e.g.
> expand the comment in cpu_set_reserved_ttbr0 with:
>
> * In some cases (e.g. where cpu_replace_ttbr1 is used), TTBR1 may not
> * point at swapper_pg_dir, and this helper cannot be used.
>
> ... and add /* see cpu_set_reserved_ttbr0 */ to both of these above the
> write_sysreg().
>
Ack.
>> diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
>> index 4e7e7067afdb..44e94e234ba0 100644
>> --- a/arch/arm64/include/asm/sections.h
>> +++ b/arch/arm64/include/asm/sections.h
>> @@ -26,5 +26,6 @@ extern char __hyp_text_start[], __hyp_text_end[];
>> extern char __idmap_text_start[], __idmap_text_end[];
>> extern char __irqentry_text_start[], __irqentry_text_end[];
>> extern char __mmuoff_data_start[], __mmuoff_data_end[];
>> +extern char __robss_start[], __robss_end[];
>>
>> #endif /* __ASM_SECTIONS_H */
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 5ce9b2929e0d..eae5036dc725 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -209,9 +209,19 @@ SECTIONS
>>
>> BSS_SECTION(0, 0, 0)
>>
>> - . = ALIGN(PAGE_SIZE);
>> + . = ALIGN(SEGMENT_ALIGN);
>> + __robss_start = .;
>> idmap_pg_dir = .;
>> - . += IDMAP_DIR_SIZE;
>> + . = ALIGN(. + IDMAP_DIR_SIZE + PAGE_SIZE, SEGMENT_ALIGN);
>> + __robss_end = .;
>
> Is it really worth aligning this beyond PAGE_SIZE?
>
> We shouldn't be poking these very often, the padding is always larger
> than the number of used pages, and the swapper dir is relegated to page
> mappings regardless.
>
The segment alignment is intended to take advantage of PTE_CONT
mappings (support for which still hasn't landed, afaict). I don't care
deeply either way ...
>> + /*
>> + * Put the zero page right before swapper_pg_dir so we can easily
>> + * obtain its physical address by subtracting PAGE_SIZE from the
>> + * contents of TTBR1_EL1.
>> + */
>> + empty_zero_page = __robss_end - PAGE_SIZE;
>
> Further to the above, I think this would be clearer if defined in-line
> as with the idmap and swapper pgdirs (with page alignment).
>
Perhaps it is best to simply do
empty_zero_page = swapper_pg_dir - PAGE_SIZE;
since that is the relation we're after.
>> /*
>> - * Map the linear alias of the [_text, __init_begin) interval as
>> - * read-only/non-executable. This makes the contents of the
>> - * region accessible to subsystems such as hibernate, but
>> - * protects it from inadvertent modification or execution.
>> + * Map the linear alias of the intervals [_text, __init_begin) and
>> + * [robss_start, robss_end) as read-only/non-executable. This makes
>> + * the contents of these regions accessible to subsystems such
>> + * as hibernate, but protects them from inadvertent modification or
>> + * execution.
>
> For completeness, it may also be worth stating that we're mapping the
> gap between those as usual, since this will be freed.
>
> Then again, maybe not. ;)
>
Well, there is a tacit assumption here that a memblock that covers any
part of the kernel covers all of it, but I think this is reasonable,
given that the memblock layer merges adjacent entries, and we could
not have holes.
Re freeing, I don't get your point: all of these mappings are permanent.
> [...]
>
>> @@ -436,13 +442,19 @@ static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
>> */
>> static void __init map_kernel(pgd_t *pgd)
>> {
>> - static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init, vmlinux_data;
>> + static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init,
>> + vmlinux_data, vmlinux_robss, vmlinux_tail;
>>
>> map_kernel_segment(pgd, _text, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
>> map_kernel_segment(pgd, __start_rodata, __init_begin, PAGE_KERNEL, &vmlinux_rodata);
>> map_kernel_segment(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
>> &vmlinux_init);
>> - map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
>> + map_kernel_segment(pgd, _data, __robss_start, PAGE_KERNEL,
>> + &vmlinux_data);
>> + map_kernel_segment(pgd, __robss_start, __robss_end, PAGE_KERNEL_RO,
>> + &vmlinux_robss);
>> + map_kernel_segment(pgd, __robss_end, _end, PAGE_KERNEL,
>> + &vmlinux_tail);
>
> Perhaps s/tail/swapper/ or s/tail/pgdir/ to make this clearer?
>
Sure.
> Modulo the above, this looks good to me.
>
Thanks.
^ permalink raw reply
* [PATCH 1/8] devicetree: binding: R-car Gen3 CMT0 and CMT1 bindings
From: Bui Duc Phuc @ 2016-09-12 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVAuyWUid6GEJXNoyw4bH3h=QWmo7eMLyiCayc5UQaoFA@mail.gmail.com>
Dear Geert,
> I think the plan was to get rid of the renesas,cmt-48-* bindings, as they do
> not allow to differentiate between CMT0 and CMT1, which have different feature
> sets.
>
> Cfr. Magnus' series "clocksource: sh_cmt: DT binding rework V4"
> (https://lkml.org/lkml/2016/3/14/433).
>
> Magnus: What's the status of your series?
Thank for your comments. I will update in V2.
I am still waiting for Magnus's comments, but from my point of
view,Magnus's patches seem
support 32 bit counter only, they are not suitable for 48bit counter.
According to hardware manual, there has to be registers ( CMCSRH,
CMCNTH,CMCORH) set for 48 bit counter,
but I do not see the registers ( CMCSRH, CMCNTH,CMCORH) in Magnus's patches.
--
Regards,
Bui Duc Phuc
^ permalink raw reply
* [PATCH v2 1/7] arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
From: Mark Rutland @ 2016-09-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912145219.GC2492@e104818-lin.cambridge.arm.com>
On Mon, Sep 12, 2016 at 03:52:19PM +0100, Catalin Marinas wrote:
> On Mon, Sep 05, 2016 at 04:38:28PM +0100, Mark Rutland wrote:
> > On Fri, Sep 02, 2016 at 04:02:07PM +0100, Catalin Marinas wrote:
> > > /*
> > > + * User access enabling/disabling.
> > > + */
> > > +#define uaccess_disable(alt) \
> > > +do { \
> > > + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt, \
> > > + CONFIG_ARM64_PAN)); \
> > > +} while (0)
> > > +
> > > +#define uaccess_enable(alt) \
> > > +do { \
> > > + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
> > > + CONFIG_ARM64_PAN)); \
> > > +} while (0)
> >
> > Passing the alternative down is somewhat confusing. e.g. in the futex
> > case it looks like we're only doing something when PAN is present,
> > whereas we'll manipulate TTBR0 in the absence of PAN.
>
> I agree it's confusing (I got it wrong first time as well and used the
> wrong alternative for futex).
>
> > If I've understood correctly, we need this to distinguish regular
> > load/store uaccess sequences (eg. the futex code) from potentially
> > patched unprivileged load/store sequences (e.g. {get,put}_user) when
> > poking PSTATE.PAN.
> >
> > So perhaps we could ahve something like:
> >
> > * privileged_uaccess_{enable,disable}()
> > Which toggle TTBR0, or PAN (always).
> > These would handle cases like the futex/swp code.
> >
> > * (unprivileged_)uaccess_{enable,disable}()
> > Which toggle TTBR0, or PAN (in the absence of UAO).
> > These would handle cases like the {get,put}_user sequences.
> >
> > Though perhaps that is just as confusing. ;)
>
> I find it more confusing.
Fair enough. :)
> In the non-UAO case, get_user etc. would
> normally have to use privileged_uaccess_enable() since ldr is not
> replaced with ldtr. Maybe uaccess_enable_for_exclusives() but it doesn't
> look any better.
I strongly prefer uaccess_enable_exclusives(), or something of that sort
to both of the above. ;)
> I think adding some comments to the code (uaccess_enable macro) would
> work better, clarifying what the alternative is for.
That will make things smoewhat clearer, though only after one reads the
comments. In contrast, uaccess_enable_exclusives() would be
self-documenting w.r.t. the intented use-case.
Do we ever want to use the 8.1 atomics for futexes? If so, perhaps
uaccess_enable_atomics()?
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5 3/3] clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK
From: Akshay Bhat @ 2016-09-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CPM9YfVqfpuyLmhGn9jC7p73Ocnc7LxE9=xA9ouawNQQ@mail.gmail.com>
On Tue, Jul 19, 2016 at 7:13 AM, Fabio Estevam <festevam@gmail.com> wrote:
>
> Great news! It is good to know you are able to confirm this series
> fixes the LVDS issue on your board.
>
> Still interested to know if Novena LVDS still work with this series applied.
>
> Sean,Marek,
>
> Any chances of testing this series on Novena's board?
>
> Thanks
Hi Fabio, Shawn,
Advantech tested the v5 patch series on imx6q-b450v3 board (with 4.7
kernel) and confirmed the patch fixes the lvds blank display issue
being seen on some imx6q-b450v3 boards.
Details below:
With the patch applied:
Board # 1: 100 times power on/off, no LVDS display failure
Board # 2: 100 times power on/off, no LVDS display failure
Without the patch:
Board # 1: LVDS display failure (blank display output) at 4th time power on/off.
Board # 2: LVDS display failure (blank display output) at 3rd time power on/off.
Tested-by: Charles Kang <Charles.Kang@advantech.com.tw>
Since the patch has been reviewed and confirmed to fix display
failures on 2 different boards (imx6q-evi and imx6q-b450v3), can it be
applied?
Thanks,
Akshay
^ permalink raw reply
* [PATCH v5 2/3] mfd: add support for Allwinner SoCs ADC
From: Lee Jones @ 2016-09-12 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912143548.GL9449@lukather>
On Mon, 12 Sep 2016, Maxime Ripard wrote:
> On Mon, Sep 12, 2016 at 02:56:55PM +0100, Lee Jones wrote:
> > > >>> Then use .data = <defined model ID> and set up a switch() in .probe().
> > > >>
> > > >> Uh? Why? It just adds a non-standard indirection, while using
> > > >> of_match_device is very standard, and used extensively in Linux.
> > > >
> > > > You still use of_match_device() to obtain the ID.
> > > >
> > > > The "don't mix DT with the MFD API" is there to prevent some of the
> > > > nasty hacks I've seen previously. This particular example doesn't
> > > > seem so bad, but it's a gateway to ridiculous hackery!
> > >
> > > How am I supposed to get the .data without of_match_node then?
> > > What's more hackish in using .data field for specific data for each
> > > compatible than in using a random ID in .data and switching on it? The
> > > result is exactly the same, the switching case being more verbose and
> > > adding complexity to something that can be done in a straightforward manner.
> >
> > I've already agreed that your implementation isn't terrible, but I'd
> > still like to remain strict on the rules.
> >
> > Better still, can you can dynamically test which platform you're on,
> > via a version register or similar?
> >
> > Failing that, see how everyone else does it:
> >
> > `git grep "\.data" -- drivers/mfd/`
>
> Just to make sure, you prefer something like
>
> static struct my_struct data = {
> };
>
> static struct my_struct data2 = {
> };
>
> struct of_device_id matches[] = {
> { compatible = "...", data = <ID> },
> { compatible = "...", data = <ID2> },
> };
>
> of_id = of_match_device (dev, matches);
> switch (of_id->data) {
> case <ID>:
> function(data);
> case <ID2>:
> function(data2);
> };
>
> over
>
> static struct my_struct data = {
> };
>
> static struct my_struct data2 = {
> };
>
> struct of_device_id matches[] = {
> { compatible = "...", data = data },
> { compatible = "...", data = data2 },
> };
>
> of_id = of_match_device (dev, matches);
> function(of_id->data);
>
> ?
>
> This is the *only* time this is going to be used in that driver. I can
> understand the need for a version if you need to apply quirks in
> several functions, but here it clearly looks suboptimal.
>
> And we are indeed using this construct in the AXP MFD, and it just
> doesn't scale either and become quite difficult to maintain when you
> have a significant number of variants, and then you have to patch
> *all* the switch instances to get something done.
static struct my_struct data = {
};
static struct my_struct data2 = {
};
struct of_device_id matches[] = {
{ compatible = "...", data = <ID> },
{ compatible = "...", data = <ID2> },
};
int probe()
{
struct mfd_cell *cell;
of_id = of_match_device (dev, matches);
switch (of_id->data) {
case <ID>:
cell = data;
case <ID2>:
cell = data2;
};
mfd_add_devices(..., cell, ...)
};
It's an extra few lines, but worth it to unbind MFD from DT.
Is there really no way to obtain this information dynamically?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 3/9] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: LABBE Corentin @ 2016-09-12 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909140413.GD30871@lunn.ch>
On Fri, Sep 09, 2016 at 04:04:13PM +0200, Andrew Lunn wrote:
> > +The device node referenced by "phy" or "phy-handle" should be a child node
> > +of this node. See phy.txt for the generic PHY bindings.
>
> I've not looked at the code yet, but is this really true? Generally
> there is not this limitation. You can point to any Ethernet phy
> anyway, so long as it is on am MDIO bus.
>
> > +
> > +Optional properties:
> > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
> > +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
> > +
> > +The TX/RX clock delay chain settings are board specific.
> > +
> > +Optional properties for "allwinner,sun8i-h3-emac":
> > +- allwinner,leds-active-low: EPHY LEDs are active low
> > +
> > +Example:
> > +
> > +emac: ethernet at 01c0b000 {
> > + compatible = "allwinner,sun8i-h3-emac";
> > + syscon = <&syscon>;
> > + reg = <0x01c0b000 0x104>;
> > + reg-names = "emac";
> > + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> > + resets = <&ccu RST_BUS_EMAC>, <<&ccu RST_BUS_EPHY>;
> > + reset-names = "ahb", "ephy";
> > + clocks = <&ccu CLK_BUS_EMAC>, <&ccu CLK_BUS_EPHY>;
> > + clock-names = "ahb", "ephy";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + phy = <&phy1>;
>
> ethernet.txt say:
>
> - phy: the same as "phy-handle" property, not recommended for new bindings.
>
> This is a new binding, please don't support it.
>
> > + phy-mode = "mii";
> > + allwinner,leds-active-low;
> > +
> > + phy1: ethernet-phy at 1 {
> > + reg = <1>;
> > + };
>
> It is normal to place these phy nodes inside an container node called
> mdio.
>
Hello
Since the MDIO bus is a part of the sun8i-emac, does I really need to create such a mdio node ?
All example I found are mdio bus with separate driver. (others driver have the phy directly in [eg]mac node.
Anyway I try the following patch to solve your comments, but it breaks the PHY finding(Could not attach to PHY).
Regards
-->8--
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -166,14 +166,18 @@
status = "okay";
};
+&mdio {
+ reg = <1>;
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+};
+
&emac {
- phy = <&phy1>;
+ phy-handle = <&phy1>;
phy-mode = "mii";
allwinner,leds-active-low;
status = "okay";
- phy1: ethernet-phy at 1 {
- reg = <1>;
- };
};/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -474,6 +474,11 @@
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
+
+ mdio: mdio at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
crypto: crypto at 1c15000 {
--- a/drivers/net/ethernet/allwinner/sun8i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
@@ -2122,7 +2122,7 @@ static int sun8i_emac_probe(struct platform_device *pdev)
return -EINVAL;
}
- priv->phy_node = of_parse_phandle(node, "phy", 0);
+ priv->phy_node = of_parse_phandle(node, "phy-handle", 0);
if (!priv->phy_node) {
netdev_err(ndev, "No associated PHY\n");
return -ENODEV;
&crypto {
^ permalink raw reply
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Szabolcs Nagy @ 2016-09-12 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912111749.GB3958@e103592.cambridge.arm.com>
On 12/09/16 12:17, Dave Martin wrote:
> On Fri, Sep 09, 2016 at 07:01:12PM +0200, Florian Weimer wrote:
>> On 09/09/2016 05:21 PM, Dave Martin wrote:
>>
>>>> Do you add this extra information only if the stack is sufficiently large?
>>>>
>>>> x86_64 adds the new information even for small stacks set up with
>>>> sigaltstack, leading to memory corruption on bleeding-edge hardware:
>>>>
>>>> <https://bugzilla.kernel.org/show_bug.cgi?id=153531>
>>>
>>> Hmmm, not yet. We already check that the whole frame is writable user
>>> memory, but this isn't sufficient to avoid user corruption in the case
>>> of alternate signal stacks. I'll fix this -- thanks for flagging it.
>>>
>>> If the stack isn't large enough, we'll still have to SEGV the task
>>> though.
>>
>> You could skip copying the data and not install a pointer to it in the
>> existing signal context.
>
> We could, but then we'd corrupt the task state in sigreturn, since
> we wouldn't have been able to save/restore part of the state.
>
>>> We can (and should) bump up the SIG{,MIN}STKSZ constants when adding
>>> the SVE support proper to the kernel,
>>
>> That's a userspace ABI change (libraries use these constants to size struct
>> members), and not a good idea. You might get away with at this stage, but
>> you can't do this every time you add some new process state you want to add
>> to signal handlers.
>
> For internal interfaces within a single component that's tolerable,
> since a single value would be used for each of these constants
> throughout the build of that component.
>
> A quick search on sources.debian.org suggests that the total number of
> packages that expose {,MIN}SIGSTKSZ dependent definitions in their
> public interfaces is small (I couldn't find any after paging through
> dozens of pages of results -- so the total is maybe in the range 0-10)
> -- hopefully few enough to eyeball.
>
>
>>> I wonder whether we should make the signal stack size runtime
>>> discoverable through sysconf() instead...
>
> I will likely suggest this for the future, but of course it doesn't help
> for current binaries.
>
>
> Note that MINSIGSTKSZ stared life wrong for arm64, and has since gone
> through a few ABI breaking changes. I don't condone this, but we have
> form in this area :/
>
> sigaltstack() already fails with ENOMEM for software that passes
> ss_size = MINSIGSTKSZ, and is built against glibc<2.22 [1], [2], running
> on linux>=4.3 [3], which is an ABI break in case where sigaltstack() is
> otherwise guaranteed to succeed.
>
yes, this was abi breaking change.
if glibc does not care about existing binaries
that use sigaltstack with MINSIGSTKSZ then it can
increase the size, but i think the kernel should
not change the abi (there are other libcs and libc
independent runtime systems on linux for aarch64
with their own sigaltstack setup, not all of them
may care about SVE).
i assume the kernel can avoid saving SVE regs when
they are not used by the process.
>
> The bottom line here is that the sigaltstack() API is broken with regard
> to extensibility, so we cannot extend the amount of signal state without
> breaking something.
>
extending signal state can break things independently
of sigaltstack.
binaries with strict guarantees about worst case stack
usage can change behaviour.
fortunately glibc PTHREAD_STACK_MIN is huge on aarch64
so applications using it are unlikely to break because
of the increased signal state.
(this also means it's impossible to have threads with
tiny stacks on glibc, so large amount of threads means
large amount of commit charge.)
>
> The least-wrong thing I can think of to do is:
>
> * deprecate but continue to support the existing sigaltstack API/ABI
> with today's {,MIN}SIGSTKSZ definitions
>
> * guarantee (as much as possible) that software using this ABI continues
> to work (by saving/restoring only data that _must_ be saved/restored at
> each signal, which may be small enough to fit)
>
> * providing a clean failure mode (fatal signal) when this proves
> impossible at signal delivery/return time;
>
> * define a new interface for runtime-querying the required signal stack
> size;
>
> * define a new syscall or new stack_t.ss_flags flags (say, SS_STRICT)
> that permits the kernel to enforce a runtime-determined minimum greater
> than MINSIGSTKSZ when calling sigaltstack().
>
>
> Another option would be:
>
> * define a new interface for runtime-querying the required signal stack
> size, and
>
> * support the current API/ABI, but make a call to sigaltstack() SEGV or
> SIGILL the caller if it specifies ss_stack >= MINSIGSTKSZ but smaller
> than the actual runtime minimum.
>
> (this would cause old software to break immediately in an obvious way on
> new systems, forcing people to fix their software -- which they might or
> might not actually bother to do).
>
>
> Thoughts?
>
> Cheers
> ---Dave
>
>
> [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b763f6ae859ecea70a5dacb8ad45c71d5f667e2e
>
> [2] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bits/sigstack.h;h=e143034ce24dc383016b4882b89cfebc7a6a62d7;hb=b8079dd0d360648e4e8de48656c5c38972621072
>
> [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c9692657c0321fec7bcb3ca8c6db56c08c640ace
>
^ permalink raw reply
* [PATCH 5/8] clk: renesas: r8a7796: Add CMT clocks
From: Bui Duc Phuc @ 2016-09-12 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWLtcHHw+nmKKN3j4yqkncsh3YwDu-yGEwqg3Du4-kncg@mail.gmail.com>
Dear Geert
Thank you for your review.
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> (will queue in clk-renesas-for-v4.9)
Thank you for helping me.
> BTW, I've dropped the spaces before the TABs (also in the r8a7795 patch).
>
>
--
Regards,
Bui Duc Phuc
^ permalink raw reply
* [PATCH] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Mark Rutland @ 2016-09-12 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473689784-29745-1-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On Mon, Sep 12, 2016 at 03:16:24PM +0100, Ard Biesheuvel wrote:
> static inline void cpu_set_reserved_ttbr0(void)
> {
> - unsigned long ttbr = virt_to_phys(empty_zero_page);
> -
> - asm(
> - " msr ttbr0_el1, %0 // set TTBR0\n"
> - " isb"
> - :
> - : "r" (ttbr));
> + /*
> + * The zero page is located right before swapper_pg_dir, whose
> + * physical address we can easily fetch from TTBR1_EL1.
> + */
> + write_sysreg(read_sysreg(ttbr1_el1) - PAGE_SIZE, ttbr0_el1);
> + isb();
> }
As a heads-up, in arm64 for-next/core this is a write_sysreg() and an
isb() thanks to [1,2]. This will need a rebase to avoid conflict.
> /*
> @@ -109,7 +108,8 @@ static inline void cpu_uninstall_idmap(void)
> {
> struct mm_struct *mm = current->active_mm;
>
> - cpu_set_reserved_ttbr0();
> + write_sysreg(virt_to_phys(empty_zero_page), ttbr0_el1);
> + isb();
> local_flush_tlb_all();
> cpu_set_default_tcr_t0sz();
>
> @@ -119,7 +119,8 @@ static inline void cpu_uninstall_idmap(void)
>
> static inline void cpu_install_idmap(void)
> {
> - cpu_set_reserved_ttbr0();
> + write_sysreg(virt_to_phys(empty_zero_page), ttbr0_el1);
> + isb();
> local_flush_tlb_all();
> cpu_set_idmap_tcr_t0sz();
It would be worth a comment as to why we have to open-code these, so as
to avoid "obvious" / "trivial cleanup" patches to this later. e.g.
expand the comment in cpu_set_reserved_ttbr0 with:
* In some cases (e.g. where cpu_replace_ttbr1 is used), TTBR1 may not
* point at swapper_pg_dir, and this helper cannot be used.
... and add /* see cpu_set_reserved_ttbr0 */ to both of these above the
write_sysreg().
> diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
> index 4e7e7067afdb..44e94e234ba0 100644
> --- a/arch/arm64/include/asm/sections.h
> +++ b/arch/arm64/include/asm/sections.h
> @@ -26,5 +26,6 @@ extern char __hyp_text_start[], __hyp_text_end[];
> extern char __idmap_text_start[], __idmap_text_end[];
> extern char __irqentry_text_start[], __irqentry_text_end[];
> extern char __mmuoff_data_start[], __mmuoff_data_end[];
> +extern char __robss_start[], __robss_end[];
>
> #endif /* __ASM_SECTIONS_H */
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 5ce9b2929e0d..eae5036dc725 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -209,9 +209,19 @@ SECTIONS
>
> BSS_SECTION(0, 0, 0)
>
> - . = ALIGN(PAGE_SIZE);
> + . = ALIGN(SEGMENT_ALIGN);
> + __robss_start = .;
> idmap_pg_dir = .;
> - . += IDMAP_DIR_SIZE;
> + . = ALIGN(. + IDMAP_DIR_SIZE + PAGE_SIZE, SEGMENT_ALIGN);
> + __robss_end = .;
Is it really worth aligning this beyond PAGE_SIZE?
We shouldn't be poking these very often, the padding is always larger
than the number of used pages, and the swapper dir is relegated to page
mappings regardless.
> + /*
> + * Put the zero page right before swapper_pg_dir so we can easily
> + * obtain its physical address by subtracting PAGE_SIZE from the
> + * contents of TTBR1_EL1.
> + */
> + empty_zero_page = __robss_end - PAGE_SIZE;
Further to the above, I think this would be clearer if defined in-line
as with the idmap and swapper pgdirs (with page alignment).
[...]
> /*
> - * Map the linear alias of the [_text, __init_begin) interval as
> - * read-only/non-executable. This makes the contents of the
> - * region accessible to subsystems such as hibernate, but
> - * protects it from inadvertent modification or execution.
> + * Map the linear alias of the intervals [_text, __init_begin) and
> + * [robss_start, robss_end) as read-only/non-executable. This makes
> + * the contents of these regions accessible to subsystems such
> + * as hibernate, but protects them from inadvertent modification or
> + * execution.
For completeness, it may also be worth stating that we're mapping the
gap between those as usual, since this will be freed.
Then again, maybe not. ;)
[...]
> @@ -436,13 +442,19 @@ static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> */
> static void __init map_kernel(pgd_t *pgd)
> {
> - static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init, vmlinux_data;
> + static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init,
> + vmlinux_data, vmlinux_robss, vmlinux_tail;
>
> map_kernel_segment(pgd, _text, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
> map_kernel_segment(pgd, __start_rodata, __init_begin, PAGE_KERNEL, &vmlinux_rodata);
> map_kernel_segment(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
> &vmlinux_init);
> - map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
> + map_kernel_segment(pgd, _data, __robss_start, PAGE_KERNEL,
> + &vmlinux_data);
> + map_kernel_segment(pgd, __robss_start, __robss_end, PAGE_KERNEL_RO,
> + &vmlinux_robss);
> + map_kernel_segment(pgd, __robss_end, _end, PAGE_KERNEL,
> + &vmlinux_tail);
Perhaps s/tail/swapper/ or s/tail/pgdir/ to make this clearer?
Modulo the above, this looks good to me.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/455284.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/455290.html
^ permalink raw reply
* [PATCH 4/8] clk: renesas: r8a7795: Add CMT clocks
From: Bui Duc Phuc @ 2016-09-12 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWkxL9ZSZx0NFk9W-MD7p1v73h0qKJG9Dmz4Av0JuWHjw@mail.gmail.com>
Dear Geert
Thank you for your review.
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> (will queue in clk-renesas-for-v4.9)
>
--
Regards,
Bui Duc Phuc
^ permalink raw reply
* [PATCH v2 1/7] arm64: Factor out PAN enabling/disabling into separate uaccess_* macros
From: Catalin Marinas @ 2016-09-12 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160905153828.GA27305@leverpostej>
On Mon, Sep 05, 2016 at 04:38:28PM +0100, Mark Rutland wrote:
> On Fri, Sep 02, 2016 at 04:02:07PM +0100, Catalin Marinas wrote:
> > /*
> > + * User access enabling/disabling.
> > + */
> > +#define uaccess_disable(alt) \
> > +do { \
> > + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt, \
> > + CONFIG_ARM64_PAN)); \
> > +} while (0)
> > +
> > +#define uaccess_enable(alt) \
> > +do { \
> > + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
> > + CONFIG_ARM64_PAN)); \
> > +} while (0)
>
> Passing the alternative down is somewhat confusing. e.g. in the futex
> case it looks like we're only doing something when PAN is present,
> whereas we'll manipulate TTBR0 in the absence of PAN.
I agree it's confusing (I got it wrong first time as well and used the
wrong alternative for futex).
> If I've understood correctly, we need this to distinguish regular
> load/store uaccess sequences (eg. the futex code) from potentially
> patched unprivileged load/store sequences (e.g. {get,put}_user) when
> poking PSTATE.PAN.
>
> So perhaps we could ahve something like:
>
> * privileged_uaccess_{enable,disable}()
> Which toggle TTBR0, or PAN (always).
> These would handle cases like the futex/swp code.
>
> * (unprivileged_)uaccess_{enable,disable}()
> Which toggle TTBR0, or PAN (in the absence of UAO).
> These would handle cases like the {get,put}_user sequences.
>
> Though perhaps that is just as confusing. ;)
I find it more confusing. In the non-UAO case, get_user etc. would
normally have to use privileged_uaccess_enable() since ldr is not
replaced with ldtr. Maybe uaccess_enable_for_exclusives() but it doesn't
look any better. I think adding some comments to the code
(uaccess_enable macro) would work better, clarifying what the
alternative is for.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: dma-mapping: add in missing white space in error message text
From: Colin Ian King @ 2016-09-12 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912143322.GW1041@n2100.armlinux.org.uk>
On 12/09/16 15:33, Russell King - ARM Linux wrote:
> On Mon, Sep 12, 2016 at 02:06:09PM +0100, Robin Murphy wrote:
>> On 12/09/16 13:52, Colin King wrote:
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> A dev_warn message spans two lines and the literal string is missing
>>> a white space between words. Add the white space.
>>>
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>> ---
>>> arch/arm/common/dmabounce.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
>>> index 3012816..f47767b 100644
>>> --- a/arch/arm/common/dmabounce.c
>>> +++ b/arch/arm/common/dmabounce.c
>>> @@ -547,7 +547,7 @@ void dmabounce_unregister_dev(struct device *dev)
>>>
>>> if (!device_info) {
>>> dev_warn(dev,
>>> - "Never registered with dmabounce but attempting"
>>> + "Never registered with dmabounce but attempting "
>>> "to unregister!\n");
>>
>> Per Documentation/CodingStyle, better to put the whole thing onto one
>> line so that, say, "git grep 'attempting to unregister'" doesn't leave
>> one scratching ones head in confusion.
>>
>> Of course, even better would be to get rid of the whole thing and
>> convert ARM to use SWIOTLB, but hey, one thing at a time ;)
>
> I doubt that can happen - dmabounce does a little more than swiotlb
> because it copes with DMA masks that are _not_ a number of zeros
> followed by one bits. It was written to support things like SA1111
> DMA, where the device has a bug in that it can't drive certain
> SDRAM address bits correctly.
>
> It also gets used for ITE8512 PCI controllers and IXP4xx platforms,
> although these should probably be converted to SWIOTLB. However,
> without having test systems, I'd recommend leaving them as-is.
>
OK, nevermind this patch, drop it into /dev/null
Colin
^ permalink raw reply
* [PATCH v4 10/10] ARM: KVM: Support vgic-v3
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
This patch allows to build and use vgic-v3 in 32-bit mode.
Unfortunately, it can not be split in several steps without extra
stubs to keep patches independent and bisectable. For instance,
virt/kvm/arm/vgic/vgic-v3.c uses function from vgic-v3-sr.c, handling
access to GICv3 cpu interface from the guest requires vgic_v3.vgic_sre
to be already defined.
It is how support has been done:
* handle SGI requests from the guest
* report configured SRE on access to GICv3 cpu interface from the guest
* required vgic-v3 macros are provided via uapi.h
* static keys are used to select GIC backend
* to make vgic-v3 build KVM_ARM_VGIC_V3 guard is removed along with
the static inlines
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/kvm_asm.h | 3 ++
arch/arm/include/asm/kvm_host.h | 5 ++++
arch/arm/include/asm/kvm_hyp.h | 3 ++
arch/arm/include/uapi/asm/kvm.h | 7 +++++
arch/arm/kvm/Makefile | 2 ++
arch/arm/kvm/coproc.c | 35 +++++++++++++++++++++++
arch/arm/kvm/hyp/Makefile | 1 +
arch/arm/kvm/hyp/switch.c | 12 ++++++--
arch/arm64/kvm/Kconfig | 4 ---
include/kvm/arm_vgic.h | 8 ------
virt/kvm/arm/vgic/vgic-kvm-device.c | 8 ------
virt/kvm/arm/vgic/vgic-mmio.c | 2 --
virt/kvm/arm/vgic/vgic-mmio.h | 2 --
virt/kvm/arm/vgic/vgic.h | 54 -----------------------------------
14 files changed, 66 insertions(+), 80 deletions(-)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 58faff5..dfccf94 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -68,6 +68,9 @@ extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
extern void __init_stage2_translation(void);
extern void __kvm_hyp_reset(unsigned long);
+
+extern u64 __vgic_v3_get_ich_vtr_el2(void);
+extern void __vgic_v3_init_lrs(void);
#endif
#endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index de338d9..c2c40a7 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -39,7 +39,12 @@
#include <kvm/arm_vgic.h>
+
+#ifdef CONFIG_ARM_GIC_V3
+#define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
+#else
#define KVM_MAX_VCPUS VGIC_V2_MAX_CPUS
+#endif
#define KVM_REQ_VCPU_EXIT 8
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index e604ad68..343135e 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -106,6 +106,9 @@ void __vgic_v2_restore_state(struct kvm_vcpu *vcpu);
void __sysreg_save_state(struct kvm_cpu_context *ctxt);
void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
+void __vgic_v3_save_state(struct kvm_vcpu *vcpu);
+void __vgic_v3_restore_state(struct kvm_vcpu *vcpu);
+
void asmlinkage __vfp_save_state(struct vfp_hard_struct *vfp);
void asmlinkage __vfp_restore_state(struct vfp_hard_struct *vfp);
static inline bool __vfp_enabled(void)
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index a2b3eb3..b38c10c 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -84,6 +84,13 @@ struct kvm_regs {
#define KVM_VGIC_V2_DIST_SIZE 0x1000
#define KVM_VGIC_V2_CPU_SIZE 0x2000
+/* Supported VGICv3 address types */
+#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
+
+#define KVM_VGIC_V3_DIST_SIZE SZ_64K
+#define KVM_VGIC_V3_REDIST_SIZE (2 * SZ_64K)
+
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index 10d77a6..043d817f 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -26,8 +26,10 @@ obj-y += $(KVM)/arm/vgic/vgic.o
obj-y += $(KVM)/arm/vgic/vgic-init.o
obj-y += $(KVM)/arm/vgic/vgic-irqfd.o
obj-y += $(KVM)/arm/vgic/vgic-v2.o
+obj-y += $(KVM)/arm/vgic/vgic-v3.o
obj-y += $(KVM)/arm/vgic/vgic-mmio.o
obj-y += $(KVM)/arm/vgic/vgic-mmio-v2.o
+obj-y += $(KVM)/arm/vgic/vgic-mmio-v3.o
obj-y += $(KVM)/arm/vgic/vgic-kvm-device.o
obj-y += $(KVM)/irqchip.o
obj-y += $(KVM)/arm/arch_timer.o
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 1bb2b79..3e5e419 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -228,6 +228,35 @@ bool access_vm_reg(struct kvm_vcpu *vcpu,
return true;
}
+static bool access_gic_sgi(struct kvm_vcpu *vcpu,
+ const struct coproc_params *p,
+ const struct coproc_reg *r)
+{
+ u64 reg;
+
+ if (!p->is_write)
+ return read_from_write_only(vcpu, p);
+
+ reg = (u64)*vcpu_reg(vcpu, p->Rt2) << 32;
+ reg |= *vcpu_reg(vcpu, p->Rt1) ;
+
+ vgic_v3_dispatch_sgi(vcpu, reg);
+
+ return true;
+}
+
+static bool access_gic_sre(struct kvm_vcpu *vcpu,
+ const struct coproc_params *p,
+ const struct coproc_reg *r)
+{
+ if (p->is_write)
+ return ignore_write(vcpu, p);
+
+ *vcpu_reg(vcpu, p->Rt1) = vcpu->arch.vgic_cpu.vgic_v3.vgic_sre;
+
+ return true;
+}
+
/*
* We could trap ID_DFR0 and tell the guest we don't support performance
* monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
@@ -361,10 +390,16 @@ static const struct coproc_reg cp15_regs[] = {
{ CRn(10), CRm( 3), Op1( 0), Op2( 1), is32,
access_vm_reg, reset_unknown, c10_AMAIR1},
+ /* ICC_SGI1R */
+ { CRm64(12), Op1( 0), is64, access_gic_sgi},
+
/* VBAR: swapped by interrupt.S. */
{ CRn(12), CRm( 0), Op1( 0), Op2( 0), is32,
NULL, reset_val, c12_VBAR, 0x00000000 },
+ /* ICC_SRE */
+ { CRn(12), CRm(12), Op1( 0), Op2(5), is32, access_gic_sre },
+
/* CONTEXTIDR/TPIDRURW/TPIDRURO/TPIDRPRW: swapped by interrupt.S. */
{ CRn(13), CRm( 0), Op1( 0), Op2( 1), is32,
access_vm_reg, reset_val, c13_CID, 0x00000000 },
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 8dfa5f7..3023bb5 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -5,6 +5,7 @@
KVM=../../../../virt/kvm
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v2-sr.o
+obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/vgic-v3-sr.o
obj-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/hyp/timer-sr.o
obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
index b13caa9..5c65a0b 100644
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -14,6 +14,7 @@
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/jump_label.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_hyp.h>
@@ -74,14 +75,21 @@ static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
write_sysreg(read_sysreg(MIDR), VPIDR);
}
+
static void __hyp_text __vgic_save_state(struct kvm_vcpu *vcpu)
{
- __vgic_v2_save_state(vcpu);
+ if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
+ __vgic_v3_save_state(vcpu);
+ else
+ __vgic_v2_save_state(vcpu);
}
static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
{
- __vgic_v2_restore_state(vcpu);
+ if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
+ __vgic_v3_restore_state(vcpu);
+ else
+ __vgic_v2_restore_state(vcpu);
}
static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 7ba9164..6eaf12c 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -19,9 +19,6 @@ if VIRTUALIZATION
config KVM_ARM_VGIC_V3_ITS
bool
-config KVM_ARM_VGIC_V3
- bool
-
config KVM
bool "Kernel-based Virtual Machine (KVM) support"
depends on OF
@@ -37,7 +34,6 @@ config KVM
select KVM_VFIO
select HAVE_KVM_EVENTFD
select HAVE_KVM_IRQFD
- select KVM_ARM_VGIC_V3
select KVM_ARM_VGIC_V3_ITS
select KVM_ARM_PMU if HW_PERF_EVENTS
select HAVE_KVM_MSI
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 994665a..843e286 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -221,7 +221,6 @@ struct vgic_v2_cpu_if {
};
struct vgic_v3_cpu_if {
-#ifdef CONFIG_KVM_ARM_VGIC_V3
u32 vgic_hcr;
u32 vgic_vmcr;
u32 vgic_sre; /* Restored only, change ignored */
@@ -231,7 +230,6 @@ struct vgic_v3_cpu_if {
u32 vgic_ap0r[4];
u32 vgic_ap1r[4];
u64 vgic_lr[VGIC_V3_MAX_LRS];
-#endif
};
struct vgic_cpu {
@@ -298,13 +296,7 @@ bool kvm_vcpu_has_pending_irqs(struct kvm_vcpu *vcpu);
void kvm_vgic_sync_hwstate(struct kvm_vcpu *vcpu);
void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu);
-#ifdef CONFIG_KVM_ARM_VGIC_V3
void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg);
-#else
-static inline void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg)
-{
-}
-#endif
/**
* kvm_vgic_get_max_vcpus - Get the maximum number of VCPUs allowed by HW
diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
index f3811b3..4dc026a 100644
--- a/virt/kvm/arm/vgic/vgic-kvm-device.c
+++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
@@ -71,7 +71,6 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 *addr, bool write)
addr_ptr = &vgic->vgic_cpu_base;
alignment = SZ_4K;
break;
-#ifdef CONFIG_KVM_ARM_VGIC_V3
case KVM_VGIC_V3_ADDR_TYPE_DIST:
type_needed = KVM_DEV_TYPE_ARM_VGIC_V3;
addr_ptr = &vgic->vgic_dist_base;
@@ -82,7 +81,6 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 *addr, bool write)
addr_ptr = &vgic->vgic_redist_base;
alignment = SZ_64K;
break;
-#endif
default:
r = -ENODEV;
goto out;
@@ -219,7 +217,6 @@ int kvm_register_vgic_device(unsigned long type)
ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
KVM_DEV_TYPE_ARM_VGIC_V2);
break;
-#ifdef CONFIG_KVM_ARM_VGIC_V3
case KVM_DEV_TYPE_ARM_VGIC_V3:
ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops,
KVM_DEV_TYPE_ARM_VGIC_V3);
@@ -230,7 +227,6 @@ int kvm_register_vgic_device(unsigned long type)
ret = kvm_vgic_register_its_device();
#endif
break;
-#endif
}
return ret;
@@ -392,8 +388,6 @@ struct kvm_device_ops kvm_arm_vgic_v2_ops = {
/* V3 ops */
-#ifdef CONFIG_KVM_ARM_VGIC_V3
-
static int vgic_v3_set_attr(struct kvm_device *dev,
struct kvm_device_attr *attr)
{
@@ -436,5 +430,3 @@ struct kvm_device_ops kvm_arm_vgic_v3_ops = {
.get_attr = vgic_v3_get_attr,
.has_attr = vgic_v3_has_attr,
};
-
-#endif /* CONFIG_KVM_ARM_VGIC_V3 */
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index 3bad3c5..e18b30d 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -550,11 +550,9 @@ int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address,
case VGIC_V2:
len = vgic_v2_init_dist_iodev(io_device);
break;
-#ifdef CONFIG_KVM_ARM_VGIC_V3
case VGIC_V3:
len = vgic_v3_init_dist_iodev(io_device);
break;
-#endif
default:
BUG_ON(1);
}
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 80f92ce..4c34d39 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -162,12 +162,10 @@ unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
unsigned int vgic_v3_init_dist_iodev(struct vgic_io_device *dev);
-#ifdef CONFIG_KVM_ARM_VGIC_V3
u64 vgic_sanitise_outer_cacheability(u64 reg);
u64 vgic_sanitise_inner_cacheability(u64 reg);
u64 vgic_sanitise_shareability(u64 reg);
u64 vgic_sanitise_field(u64 reg, u64 field_mask, int field_shift,
u64 (*sanitise_fn)(u64));
-#endif
#endif
diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
index 100045f..9d9e014 100644
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@ -72,7 +72,6 @@ static inline void vgic_get_irq_kref(struct vgic_irq *irq)
kref_get(&irq->refcount);
}
-#ifdef CONFIG_KVM_ARM_VGIC_V3
void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu);
void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu);
void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr);
@@ -91,60 +90,7 @@ bool vgic_has_its(struct kvm *kvm);
int kvm_vgic_register_its_device(void);
void vgic_enable_lpis(struct kvm_vcpu *vcpu);
int vgic_its_inject_msi(struct kvm *kvm, struct kvm_msi *msi);
-#endif
-
#else
-static inline void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu)
-{
-}
-
-static inline void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
-{
-}
-
-static inline void vgic_v3_populate_lr(struct kvm_vcpu *vcpu,
- struct vgic_irq *irq, int lr)
-{
-}
-
-static inline void vgic_v3_clear_lr(struct kvm_vcpu *vcpu, int lr)
-{
-}
-
-static inline void vgic_v3_set_underflow(struct kvm_vcpu *vcpu)
-{
-}
-
-static inline
-void vgic_v3_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
-{
-}
-
-static inline
-void vgic_v3_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
-{
-}
-
-static inline void vgic_v3_enable(struct kvm_vcpu *vcpu)
-{
-}
-
-static inline int vgic_v3_probe(const struct gic_kvm_info *info)
-{
- return -ENODEV;
-}
-
-static inline int vgic_v3_map_resources(struct kvm *kvm)
-{
- return -ENODEV;
-}
-
-static inline int vgic_register_redist_iodevs(struct kvm *kvm,
- gpa_t dist_base_address)
-{
- return -ENODEV;
-}
-
static inline int vgic_register_its_iodevs(struct kvm *kvm)
{
return -ENODEV;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 09/10] ARM: gic-v3: Introduce 32-to-64-bit mappings for GICv3 cpu registers
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
vgic-v3 save/restore routines are written in such way that they map
arm64 system register naming nicely, but it does not fit to arm
world. To keep virt/kvm/arm/hyp/vgic-v3-sr.c untouched we create a
mapping with a function for each register mapping the 32-bit to the
64-bit accessors.
Please, note that 64-bit wide ICH_LR is split in two 32-bit halves
(ICH_LR and ICH_LRC) accessed independently.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/arch_gicv3.h | 64 +++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/include/asm/arch_gicv3.h b/arch/arm/include/asm/arch_gicv3.h
index af25c32..996848e 100644
--- a/arch/arm/include/asm/arch_gicv3.h
+++ b/arch/arm/include/asm/arch_gicv3.h
@@ -96,6 +96,70 @@
#define ICH_AP1R2 __AP1Rx(2)
#define ICH_AP1R3 __AP1Rx(3)
+/* A32-to-A64 mappings used by VGIC save/restore */
+
+#define CPUIF_MAP(a32, a64) \
+static inline void write_ ## a64(u32 val) \
+{ \
+ write_sysreg(val, a32); \
+} \
+static inline u32 read_ ## a64(void) \
+{ \
+ return read_sysreg(a32); \
+} \
+
+#define CPUIF_MAP_LO_HI(a32lo, a32hi, a64) \
+static inline void write_ ## a64(u64 val) \
+{ \
+ write_sysreg(lower_32_bits(val), a32lo);\
+ write_sysreg(upper_32_bits(val), a32hi);\
+} \
+static inline u64 read_ ## a64(void) \
+{ \
+ u64 val = read_sysreg(a32lo); \
+ \
+ val |= (u64)read_sysreg(a32hi) << 32; \
+ \
+ return val; \
+}
+
+CPUIF_MAP(ICH_HCR, ICH_HCR_EL2)
+CPUIF_MAP(ICH_VTR, ICH_VTR_EL2)
+CPUIF_MAP(ICH_MISR, ICH_MISR_EL2)
+CPUIF_MAP(ICH_EISR, ICH_EISR_EL2)
+CPUIF_MAP(ICH_ELSR, ICH_ELSR_EL2)
+CPUIF_MAP(ICH_VMCR, ICH_VMCR_EL2)
+CPUIF_MAP(ICH_AP0R3, ICH_AP0R3_EL2)
+CPUIF_MAP(ICH_AP0R2, ICH_AP0R2_EL2)
+CPUIF_MAP(ICH_AP0R1, ICH_AP0R1_EL2)
+CPUIF_MAP(ICH_AP0R0, ICH_AP0R0_EL2)
+CPUIF_MAP(ICH_AP1R3, ICH_AP1R3_EL2)
+CPUIF_MAP(ICH_AP1R2, ICH_AP1R2_EL2)
+CPUIF_MAP(ICH_AP1R1, ICH_AP1R1_EL2)
+CPUIF_MAP(ICH_AP1R0, ICH_AP1R0_EL2)
+CPUIF_MAP(ICC_HSRE, ICC_SRE_EL2)
+CPUIF_MAP(ICC_SRE, ICC_SRE_EL1)
+
+CPUIF_MAP_LO_HI(ICH_LR15, ICH_LRC15, ICH_LR15_EL2)
+CPUIF_MAP_LO_HI(ICH_LR14, ICH_LRC14, ICH_LR14_EL2)
+CPUIF_MAP_LO_HI(ICH_LR13, ICH_LRC13, ICH_LR13_EL2)
+CPUIF_MAP_LO_HI(ICH_LR12, ICH_LRC12, ICH_LR12_EL2)
+CPUIF_MAP_LO_HI(ICH_LR11, ICH_LRC11, ICH_LR11_EL2)
+CPUIF_MAP_LO_HI(ICH_LR10, ICH_LRC10, ICH_LR10_EL2)
+CPUIF_MAP_LO_HI(ICH_LR9, ICH_LRC9, ICH_LR9_EL2)
+CPUIF_MAP_LO_HI(ICH_LR8, ICH_LRC8, ICH_LR8_EL2)
+CPUIF_MAP_LO_HI(ICH_LR7, ICH_LRC7, ICH_LR7_EL2)
+CPUIF_MAP_LO_HI(ICH_LR6, ICH_LRC6, ICH_LR6_EL2)
+CPUIF_MAP_LO_HI(ICH_LR5, ICH_LRC5, ICH_LR5_EL2)
+CPUIF_MAP_LO_HI(ICH_LR4, ICH_LRC4, ICH_LR4_EL2)
+CPUIF_MAP_LO_HI(ICH_LR3, ICH_LRC3, ICH_LR3_EL2)
+CPUIF_MAP_LO_HI(ICH_LR2, ICH_LRC2, ICH_LR2_EL2)
+CPUIF_MAP_LO_HI(ICH_LR1, ICH_LRC1, ICH_LR1_EL2)
+CPUIF_MAP_LO_HI(ICH_LR0, ICH_LRC0, ICH_LR0_EL2)
+
+#define read_gicreg(r) read_##r()
+#define write_gicreg(v, r) write_##r(v)
+
/* Low-level accessors */
static inline void gic_write_eoir(u32 irq)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 08/10] ARM: Move system register accessors to asm/cp15.h
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
Headers linux/irqchip/arm-gic.v3.h and arch/arm/include/asm/kvm_hyp.h
are included in virt/kvm/arm/hyp/vgic-v3-sr.c and both define macros
called __ACCESS_CP15 and __ACCESS_CP15_64 which obviously creates a
conflict. These macros were introduced independently for GIC and KVM
and, in fact, do the same thing.
As an option we could add prefixes to KVM and GIC version of macros so
they won't clash, but it'd introduce code duplication. Alternatively,
we could keep macro in, say, GIC header and include it in KVM one (or
vice versa), but such dependency would not look nicer.
So we follow arm64 way (it handles this via sysreg.h) and move only
single set of macros to asm/cp15.h
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/arch_gicv3.h | 27 +++++++++++----------------
arch/arm/include/asm/cp15.h | 15 +++++++++++++++
arch/arm/include/asm/kvm_hyp.h | 15 +--------------
3 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/arch/arm/include/asm/arch_gicv3.h b/arch/arm/include/asm/arch_gicv3.h
index e08d151..af25c32 100644
--- a/arch/arm/include/asm/arch_gicv3.h
+++ b/arch/arm/include/asm/arch_gicv3.h
@@ -22,9 +22,7 @@
#include <linux/io.h>
#include <asm/barrier.h>
-
-#define __ACCESS_CP15(CRn, Op1, CRm, Op2) p15, Op1, %0, CRn, CRm, Op2
-#define __ACCESS_CP15_64(Op1, CRm) p15, Op1, %Q0, %R0, CRm
+#include <asm/cp15.h>
#define ICC_EOIR1 __ACCESS_CP15(c12, 0, c12, 1)
#define ICC_DIR __ACCESS_CP15(c12, 0, c11, 1)
@@ -102,58 +100,55 @@
static inline void gic_write_eoir(u32 irq)
{
- asm volatile("mcr " __stringify(ICC_EOIR1) : : "r" (irq));
+ write_sysreg(irq, ICC_EOIR1);
isb();
}
static inline void gic_write_dir(u32 val)
{
- asm volatile("mcr " __stringify(ICC_DIR) : : "r" (val));
+ write_sysreg(val, ICC_DIR);
isb();
}
static inline u32 gic_read_iar(void)
{
- u32 irqstat;
+ u32 irqstat = read_sysreg(ICC_IAR1);
- asm volatile("mrc " __stringify(ICC_IAR1) : "=r" (irqstat));
dsb(sy);
+
return irqstat;
}
static inline void gic_write_pmr(u32 val)
{
- asm volatile("mcr " __stringify(ICC_PMR) : : "r" (val));
+ write_sysreg(val, ICC_PMR);
}
static inline void gic_write_ctlr(u32 val)
{
- asm volatile("mcr " __stringify(ICC_CTLR) : : "r" (val));
+ write_sysreg(val, ICC_CTLR);
isb();
}
static inline void gic_write_grpen1(u32 val)
{
- asm volatile("mcr " __stringify(ICC_IGRPEN1) : : "r" (val));
+ write_sysreg(val, ICC_IGRPEN1);
isb();
}
static inline void gic_write_sgi1r(u64 val)
{
- asm volatile("mcrr " __stringify(ICC_SGI1R) : : "r" (val));
+ write_sysreg(val, ICC_SGI1R);
}
static inline u32 gic_read_sre(void)
{
- u32 val;
-
- asm volatile("mrc " __stringify(ICC_SRE) : "=r" (val));
- return val;
+ return read_sysreg(ICC_SRE);
}
static inline void gic_write_sre(u32 val)
{
- asm volatile("mcr " __stringify(ICC_SRE) : : "r" (val));
+ write_sysreg(val, ICC_SRE);
isb();
}
diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
index c3f1152..dbdbce1 100644
--- a/arch/arm/include/asm/cp15.h
+++ b/arch/arm/include/asm/cp15.h
@@ -49,6 +49,21 @@
#ifdef CONFIG_CPU_CP15
+#define __ACCESS_CP15(CRn, Op1, CRm, Op2) \
+ "mrc", "mcr", __stringify(p15, Op1, %0, CRn, CRm, Op2), u32
+#define __ACCESS_CP15_64(Op1, CRm) \
+ "mrrc", "mcrr", __stringify(p15, Op1, %Q0, %R0, CRm), u64
+
+#define __read_sysreg(r, w, c, t) ({ \
+ t __val; \
+ asm volatile(r " " c : "=r" (__val)); \
+ __val; \
+})
+#define read_sysreg(...) __read_sysreg(__VA_ARGS__)
+
+#define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v)))
+#define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__)
+
extern unsigned long cr_alignment; /* defined in entry-armv.S */
static inline unsigned long get_cr(void)
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 6eaff28..e604ad68 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -20,28 +20,15 @@
#include <linux/compiler.h>
#include <linux/kvm_host.h>
+#include <asm/cp15.h>
#include <asm/kvm_mmu.h>
#include <asm/vfp.h>
#define __hyp_text __section(.hyp.text) notrace
-#define __ACCESS_CP15(CRn, Op1, CRm, Op2) \
- "mrc", "mcr", __stringify(p15, Op1, %0, CRn, CRm, Op2), u32
-#define __ACCESS_CP15_64(Op1, CRm) \
- "mrrc", "mcrr", __stringify(p15, Op1, %Q0, %R0, CRm), u64
#define __ACCESS_VFP(CRn) \
"mrc", "mcr", __stringify(p10, 7, %0, CRn, cr0, 0), u32
-#define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v)))
-#define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__)
-
-#define __read_sysreg(r, w, c, t) ({ \
- t __val; \
- asm volatile(r " " c : "=r" (__val)); \
- __val; \
-})
-#define read_sysreg(...) __read_sysreg(__VA_ARGS__)
-
#define write_special(v, r) \
asm volatile("msr " __stringify(r) ", %0" : : "r" (v))
#define read_special(r) ({ \
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 07/10] ARM: Introduce MPIDR_LEVEL_SHIFT macro
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
vgic-v3 driver uses architecture specific MPIDR_LEVEL_SHIFT macro to
encode the affinity in a form compatible with ICC_SGI* registers.
Unfortunately, that macro is missing on ARM, so let's add it.
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/cputype.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 1ee94c7..e2d94c1 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -55,6 +55,7 @@
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
+#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * level)
#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
((mpidr >> (MPIDR_LEVEL_BITS * level)) & MPIDR_LEVEL_MASK)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 06/10] KVM: arm: vgic: Support 64-bit data manipulation on 32-bit host systems
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
We have couple of 64-bit registers defined in GICv3 architecture, so
unsigned long accesses to these registers will only access a single
32-bit part of that regitser. On the other hand these registers can't
be accessed as 64-bit with a single instruction like ldrd/strd or
ldmia/stmia if we run a 32-bit host because KVM does not support
access to MMIO space done by these instructions.
It means that a 32-bit guest accesses these registers in 32-bit
chunks, so the only thing we need to do is to ensure that
extract_bytes() always takes 64-bit data.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
virt/kvm/arm/vgic/vgic-mmio-v3.c | 2 +-
virt/kvm/arm/vgic/vgic-mmio.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index 6385ed5..0d3c76a 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -23,7 +23,7 @@
#include "vgic-mmio.h"
/* extract @num bytes at @offset bytes offset in data */
-unsigned long extract_bytes(unsigned long data, unsigned int offset,
+unsigned long extract_bytes(u64 data, unsigned int offset,
unsigned int num)
{
return (data >> (offset * 8)) & GENMASK_ULL(num * 8 - 1, 0);
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 0b3ecf9..80f92ce 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -96,7 +96,7 @@ unsigned long vgic_data_mmio_bus_to_host(const void *val, unsigned int len);
void vgic_data_host_to_mmio_bus(void *buf, unsigned int len,
unsigned long data);
-unsigned long extract_bytes(unsigned long data, unsigned int offset,
+unsigned long extract_bytes(u64 data, unsigned int offset,
unsigned int num);
u64 update_64bit_reg(u64 reg, unsigned int offset, unsigned int len,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 05/10] KVM: arm: vgic: Fix compiler warnings when built for 32-bit
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
Well, this patch is looking ahead of time, but we'll get following
compiler warnings as soon as we introduce vgic-v3 to 32-bit world
CC arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.o
arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c: In function 'vgic_mmio_read_v3r_typer':
arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c:184:35: warning: left shift count >= width of type [-Wshift-count-overflow]
value = (mpidr & GENMASK(23, 0)) << 32;
^
In file included from ./include/linux/kernel.h:10:0,
from ./include/asm-generic/bug.h:13,
from ./arch/arm/include/asm/bug.h:59,
from ./include/linux/bug.h:4,
from ./include/linux/io.h:23,
from ./arch/arm/include/asm/arch_gicv3.h:23,
from ./include/linux/irqchip/arm-gic-v3.h:411,
from arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c:14:
arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c: In function 'vgic_v3_dispatch_sgi':
./include/linux/bitops.h:6:24: warning: left shift count >= width of type [-Wshift-count-overflow]
#define BIT(nr) (1UL << (nr))
^
arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c:614:20: note: in expansion of macro 'BIT'
broadcast = reg & BIT(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
^
Let's fix them now.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
virt/kvm/arm/vgic/vgic-mmio-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index acbe691..6385ed5 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -181,7 +181,7 @@ static unsigned long vgic_mmio_read_v3r_typer(struct kvm_vcpu *vcpu,
int target_vcpu_id = vcpu->vcpu_id;
u64 value;
- value = (mpidr & GENMASK(23, 0)) << 32;
+ value = (u64)(mpidr & GENMASK(23, 0)) << 32;
value |= ((target_vcpu_id & 0xffff) << 8);
if (target_vcpu_id == atomic_read(&vcpu->kvm->online_vcpus) - 1)
value |= GICR_TYPER_LAST;
@@ -611,7 +611,7 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg)
bool broadcast;
sgi = (reg & ICC_SGI1R_SGI_ID_MASK) >> ICC_SGI1R_SGI_ID_SHIFT;
- broadcast = reg & BIT(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
+ broadcast = reg & BIT_ULL(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
target_cpus = (reg & ICC_SGI1R_TARGET_LIST_MASK) >> ICC_SGI1R_TARGET_LIST_SHIFT;
mpidr = SGI_AFFINITY_LEVEL(reg, 3);
mpidr |= SGI_AFFINITY_LEVEL(reg, 2);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 04/10] KVM: arm64: vgic-its: Introduce config option to guard ITS specific code
From: Vladimir Murzin @ 2016-09-12 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473691764-29424-1-git-send-email-vladimir.murzin@arm.com>
By now ITS code guarded with KVM_ARM_VGIC_V3 config option which was
introduced to hide everything specific to vgic-v3 from 32-bit world.
We are going to support vgic-v3 in 32-bit world and KVM_ARM_VGIC_V3
will gone, but we don't have support for ITS there yet and we need to
continue keeping ITS away.
Introduce the new config option to prevent ITS code being build in
32-bit mode when support for vgic-v3 is done.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/Kconfig | 4 ++++
virt/kvm/arm/vgic/vgic-kvm-device.c | 3 +++
virt/kvm/arm/vgic/vgic-mmio-v3.c | 2 ++
virt/kvm/arm/vgic/vgic.h | 4 ++++
4 files changed, 13 insertions(+)
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 9c9edc9..7ba9164 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -16,6 +16,9 @@ menuconfig VIRTUALIZATION
if VIRTUALIZATION
+config KVM_ARM_VGIC_V3_ITS
+ bool
+
config KVM_ARM_VGIC_V3
bool
@@ -35,6 +38,7 @@ config KVM
select HAVE_KVM_EVENTFD
select HAVE_KVM_IRQFD
select KVM_ARM_VGIC_V3
+ select KVM_ARM_VGIC_V3_ITS
select KVM_ARM_PMU if HW_PERF_EVENTS
select HAVE_KVM_MSI
select HAVE_KVM_IRQCHIP
diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
index 1813f93..f3811b3 100644
--- a/virt/kvm/arm/vgic/vgic-kvm-device.c
+++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
@@ -223,9 +223,12 @@ int kvm_register_vgic_device(unsigned long type)
case KVM_DEV_TYPE_ARM_VGIC_V3:
ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops,
KVM_DEV_TYPE_ARM_VGIC_V3);
+
+#ifdef CONFIG_KVM_ARM_VGIC_V3_ITS
if (ret)
break;
ret = kvm_vgic_register_its_device();
+#endif
break;
#endif
}
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index 90d8181..acbe691 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -42,6 +42,7 @@ u64 update_64bit_reg(u64 reg, unsigned int offset, unsigned int len,
return reg | ((u64)val << lower);
}
+#ifdef CONFIG_KVM_ARM_VGIC_V3_ITS
bool vgic_has_its(struct kvm *kvm)
{
struct vgic_dist *dist = &kvm->arch.vgic;
@@ -51,6 +52,7 @@ bool vgic_has_its(struct kvm *kvm)
return dist->has_its;
}
+#endif
static unsigned long vgic_mmio_read_v3_misc(struct kvm_vcpu *vcpu,
gpa_t addr, unsigned int len)
diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
index 6c4625c..100045f 100644
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@ -84,11 +84,15 @@ void vgic_v3_enable(struct kvm_vcpu *vcpu);
int vgic_v3_probe(const struct gic_kvm_info *info);
int vgic_v3_map_resources(struct kvm *kvm);
int vgic_register_redist_iodevs(struct kvm *kvm, gpa_t dist_base_address);
+
+#ifdef CONFIG_KVM_ARM_VGIC_V3_ITS
int vgic_register_its_iodevs(struct kvm *kvm);
bool vgic_has_its(struct kvm *kvm);
int kvm_vgic_register_its_device(void);
void vgic_enable_lpis(struct kvm_vcpu *vcpu);
int vgic_its_inject_msi(struct kvm *kvm, struct kvm_msi *msi);
+#endif
+
#else
static inline void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu)
{
--
1.7.9.5
^ permalink raw reply related
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