* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Adam Ford @ 2018-05-14 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aba13450-1e8f-4aed-6248-16b71abcc0dd@ti.com>
On Mon, May 14, 2018 at 12:29 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> Hi Adam,
>
> On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
>> When using the board files the LCD works, but not with the DT.
>> This adds enables the original da850-evm to work with the same
>> LCD in device tree mode.
>>
>> The EVM has a gpio for the regulator and a gpio enable. The LCD and
>> the vpif display pins are mutually exclusive, so if using the LCD,
>> do not load the vpif driver.
>
> Its not sufficient just note this in patch description.
>
> a) Disable (status = "disabled") the VPIF node which clashes for pins
> with LCD.
> b) Add a comment on top of the status = "disabled" giving information on
> how user can enable it (disable lcdc node and then change to status =
> "okay").
>
>>
>> Signed-off-by: Adam Ford <aford173@gmail.com>
>> ---
>> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
>> backlight which better matches the schematic. Updated the description to explain
>> that it cannot be used at the same time as the vpif driver.
>>
>> V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
>>
>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>> index 2e817da37fdb..3f1c8be07efe 100644
>> --- a/arch/arm/boot/dts/da850-evm.dts
>> +++ b/arch/arm/boot/dts/da850-evm.dts
>> @@ -27,6 +27,50 @@
>> spi0 = &spi1;
>> };
>>
>> + backlight {
>> + compatible = "gpio-backlight";
>> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
>
> The gpio-backlight binding does not describe a property called
> enable-gpios. It should just be gpios.
I will fix that.
>
> a) Are you using gpio-backlight because you are not able to get the PWM
> to work?
>
Yes, You told me not to worry about doing a PWM backlight because the
legacy board does not PWM either.
> b) What is GP0[7] connected to in the schematic you have? In the
> schematic I have I see LCD_PWM0 is connected to
> SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
I have schematic 1016572 dated Wednesday, August 18, 2010. According
to it, AXR15 / EPWMN0_TZ[0] / ECAP2_APWM2 / GPIO0[7] connects to U25,
Pin 46 to generate M_LCD_PWM0. You might have one of the early,
pre-release versions.
>
> c) The /* GP0[7] */ comment is not really useful on its own as it can be
> computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
> Same for other places like this below.
I can do that.
>
>> @@ -35,6 +79,16 @@
>> regulator-boot-on;
>> };
>>
>> + backlight_reg: backlight-regulator {
>> + compatible = "regulator-fixed";
>> + regulator-name = "lcd_backlight_pwr";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
>> + regulator-always-on;
>
> Why should this regulator never be disabled?
The gpio-backlight does not have a way that I can see to associate the
regulator to it. I read through the bindings, but I didn't see an
option to associate a regulator it. I use this regulator to drive
lcd_backlight_pwr and the backlight driver to write lcd_pwm0. Without
this option, the system disables lcd_backlight_pwr and the screen is
blank
adam
>
> Thanks,
> Sekhar
^ permalink raw reply
* Difference between IOVA and bus address when SMMU is enabled
From: Russell King - ARM Linux @ 2018-05-14 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4fe00a3-33b1-7cd4-f613-768dee06ef6b@gmail.com>
On Sat, May 12, 2018 at 06:25:13PM +0530, valmiki wrote:
> Hi All,
>
> What is the difference between IOVA address and bus address
> when SMMU is enabled ?
>
> Is IOVA address term used only when hypervisor is present ?
IOVA = IO virtual address. IOVA is the term normally used to describe
the address used on the _device_ side of an IOMMU.
For any general setup:
RAM ----- MMU ----- DEVICE
^ ^
physical virtual
address address
where "device" can be an IO device or a CPU, the terms still apply.
If you have something like this:
RAM ----- PCI bridge ----- MMU ----- DEVICE
^ ^ ^
physical bus virtual
address address address
You could also have (eg, in the case of a system MMU):
RAM ----- MMU ----- PCI bridge ----- DEVICE
^ ^ ^
physical virtual bus
address address address
(this can also be
considered a bus
address!)
In both of the above two cases, the PCI bridge may perform some address
translation, meaning that the bus address is different from the address
seen on the other side of the bridge.
So, the terms used depend exactly on the overall bus topology.
In the case of a system MMU, where the system MMU sits between peripheral
devices and RAM, then the bus addresses are the same as the
_IOVA of the system MMU_.
--
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 v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-05-14 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-7-radu.pirea@microchip.com>
Hi,
On 11/05/2018 12:38, Radu Pirea wrote:
> This patch modifies the place where resources and device tree properties
> are searched.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> drivers/tty/serial/Kconfig | 1 +
> drivers/tty/serial/atmel_serial.c | 29 +++++++++++++++--------------
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 3682fd3e960c..25e55332f8b1 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -119,6 +119,7 @@ config SERIAL_ATMEL
> depends on ARCH_AT91 || COMPILE_TEST
> select SERIAL_CORE
> select SERIAL_MCTRL_GPIO if GPIOLIB
> + select MFD_AT91_USART
> help
> This enables the driver for the on-chip UARTs of the Atmel
> AT91 processors.
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index df46a9e88c34..6b4494352853 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -193,8 +193,8 @@ static struct console atmel_console;
>
> #if defined(CONFIG_OF)
> static const struct of_device_id atmel_serial_dt_ids[] = {
> - { .compatible = "atmel,at91rm9200-usart" },
> - { .compatible = "atmel,at91sam9260-usart" },
> + { .compatible = "atmel,at91rm9200-usart-serial" },
> + { .compatible = "atmel,at91sam9260-usart-serial" },
> { /* sentinel */ }
> };
> #endif
> @@ -1631,7 +1631,7 @@ static void atmel_tasklet_tx_func(unsigned long data)
> static void atmel_init_property(struct atmel_uart_port *atmel_port,
> struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.parent->of_node;
>
> /* DMA/PDC usage specification */
> if (of_property_read_bool(np, "atmel,use-dma-rx")) {
> @@ -2223,7 +2223,8 @@ static const char *atmel_type(struct uart_port *port)
> static void atmel_release_port(struct uart_port *port)
> {
> struct platform_device *pdev = to_platform_device(port->dev);
> - int size = pdev->resource[0].end - pdev->resource[0].start + 1;
> + int size = to_platform_device(pdev->dev.parent)->resource[0].end -
> + to_platform_device(pdev->dev.parent)->resource[0].start + 1;
I think it may be simpler with something like:
+ struct platform_device *mfd_pdev = to_platform_device(port->dev->parent);
+ int size = mfd_pdev->resource[0].end - mfd_pdev->resource[0].start + 1;
>
> release_mem_region(port->mapbase, size);
>
> @@ -2239,7 +2240,8 @@ static void atmel_release_port(struct uart_port *port)
> static int atmel_request_port(struct uart_port *port)
> {
> struct platform_device *pdev = to_platform_device(port->dev);
> - int size = pdev->resource[0].end - pdev->resource[0].start + 1;
> + int size = to_platform_device(pdev->dev.parent)->resource[0].end -
> + to_platform_device(pdev->dev.parent)->resource[0].start + 1;
>
ditto
> if (!request_mem_region(port->mapbase, size, "atmel_serial"))
> return -EBUSY;
> @@ -2345,23 +2347,23 @@ static int atmel_init_port(struct atmel_uart_port *atmel_port,
Here, we could also add:
+ struct device *mfd_dev = pdev->dev.parent;
+ struct platform_device *mfd_pdev = to_platform_device(mfd_dev);
> atmel_init_property(atmel_port, pdev);
> atmel_set_ops(port);
>
> - uart_get_rs485_mode(&pdev->dev, &port->rs485);
> + uart_get_rs485_mode(pdev->dev.parent, &port->rs485);
...and use them here
>
> port->iotype = UPIO_MEM;
> port->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
> port->ops = &atmel_pops;
> port->fifosize = 1;
> port->dev = &pdev->dev;
> - port->mapbase = pdev->resource[0].start;
> - port->irq = pdev->resource[1].start;
> + port->mapbase = to_platform_device(pdev->dev.parent)->resource[0].start;
> + port->irq = to_platform_device(pdev->dev.parent)->resource[1].start;
and here
I think it would be easier to read.
> port->rs485_config = atmel_config_rs485;
> - port->membase = NULL;
> + port->membase = NULL;
>
> memset(&atmel_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
>
> /* for console, the clock could already be configured */
> if (!atmel_port->clk) {
> - atmel_port->clk = clk_get(&pdev->dev, "usart");
> + atmel_port->clk = clk_get(pdev->dev.parent, "usart");
and here
> if (IS_ERR(atmel_port->clk)) {
> ret = PTR_ERR(atmel_port->clk);
> atmel_port->clk = NULL;
> @@ -2656,7 +2658,7 @@ static void atmel_serial_probe_fifos(struct atmel_uart_port *atmel_port,
> atmel_port->rts_low = 0;
> atmel_port->rts_high = 0;
>
> - if (of_property_read_u32(pdev->dev.of_node,
> + if (of_property_read_u32(pdev->dev.parent->of_node,
> "atmel,fifo-size",
> &atmel_port->fifo_size))
> return;
> @@ -2694,11 +2696,10 @@ static void atmel_serial_probe_fifos(struct atmel_uart_port *atmel_port,
> static int atmel_serial_probe(struct platform_device *pdev)
> {
> struct atmel_uart_port *atmel_port;
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.parent->of_node;
> void *data;
> int ret = -ENODEV;
> bool rs485_enabled;
> -
I think this line feed wasn't so bad.
> BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
>
> ret = of_alias_get_id(np, "serial");
> @@ -2845,7 +2846,7 @@ static struct platform_driver atmel_serial_driver = {
> .suspend = atmel_serial_suspend,
> .resume = atmel_serial_resume,
> .driver = {
> - .name = "atmel_usart",
> + .name = "atmel_usart_serial",
> .of_match_table = of_match_ptr(atmel_serial_dt_ids),
> },
> };
>
After your patch, the DMA is not selected anymore:
atmel_usart_serial atmel_usart_serial.0.auto: TX channel not available, switch to pio
instead of:
atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
And the kernel doesn't log anymore on the serial console, despite the loglevel=8
(after reverting this series, the kernel logs reappears on the serial console)
(tests done on sam9g35)
regards,
Richard
^ permalink raw reply
* [PATCH 1/2][stable-4.4] arm64: introduce mov_q macro to move a constant into a 64-bit register
From: Suzuki K Poulose @ 2018-05-14 11:01 UTC (permalink / raw)
To: linux-arm-kernel
commit 30b5ba5cf333cc650e474eaf2cc1ae91bc7cf89f upstream
Implement a macro mov_q that can be used to move an immediate constant
into a 64-bit register, using between 2 and 4 movz/movk instructions
(depending on the operand)
Cc: stable at vger.kernel.org # v4.4
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Cherry picked for backport of
"commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream"
---
arch/arm64/include/asm/assembler.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 12eff92..83e2309 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -204,4 +204,24 @@ lr .req x30 // link register
.size __pi_##x, . - x; \
ENDPROC(x)
+ /*
+ * mov_q - move an immediate constant into a 64-bit register using
+ * between 2 and 4 movz/movk instructions (depending on the
+ * magnitude and sign of the operand)
+ */
+ .macro mov_q, reg, val
+ .if (((\val) >> 31) == 0 || ((\val) >> 31) == 0x1ffffffff)
+ movz \reg, :abs_g1_s:\val
+ .else
+ .if (((\val) >> 47) == 0 || ((\val) >> 47) == 0x1ffff)
+ movz \reg, :abs_g2_s:\val
+ .else
+ movz \reg, :abs_g3:\val
+ movk \reg, :abs_g2_nc:\val
+ .endif
+ movk \reg, :abs_g1_nc:\val
+ .endif
+ movk \reg, :abs_g0_nc:\val
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] [stable 4.4] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Suzuki K Poulose @ 2018-05-14 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526295664-22187-1-git-send-email-suzuki.poulose@arm.com>
commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to disable the hardware DBM feature
on the affected cores. The hardware Access Flag management features
is not affected.
The hardware DBM feature is a non-conflicting capability, i.e, the
kernel could handle cores using the feature and those without having
the features running at the same time. So this work around is detected
at early boot time, rather than delaying it until the CPUs are brought
up into the kernel with MMU turned on. This also avoids other complexities
with late CPUs turning online, with or without the hardware DBM features.
Cc: stable at vger.kernel.org # v4.4
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Note: The upstream commit is on top of a reworked capability
infrastructure for arm64 heterogeneous systems, which allows
delaying the CPU model checks. This backport is based on the
original version of the patch [0], which checks the affected
CPU models during the early boot.
[0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
---
arch/arm64/Kconfig | 14 +++++++++++++
arch/arm64/include/asm/assembler.h | 40 ++++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/cputype.h | 11 +++++++++++
arch/arm64/mm/proc.S | 5 +++++
4 files changed, 70 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 02c0867..5b47218 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -375,6 +375,20 @@ config ARM64_ERRATUM_843419
If unsure, say Y.
+config ARM64_ERRATUM_1024718
+ bool "Cortex-A55: 1024718: Update of DBM/AP bits without break before make might result in incorrect update"
+ default y
+ help
+ This option adds work around for Arm Cortex-A55 Erratum 1024718.
+
+ Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause incorrect
+ update of the hardware dirty bit when the DBM/AP bits are updated
+ without a break-before-make. The work around is to disable the usage
+ of hardware DBM locally on the affected cores. CPUs not affected by
+ erratum will continue to use the feature.
+
+ If unsure, say Y.
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 83e2309..f68abb1 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -23,6 +23,7 @@
#ifndef __ASM_ASSEMBLER_H
#define __ASM_ASSEMBLER_H
+#include <asm/cputype.h>
#include <asm/ptrace.h>
#include <asm/thread_info.h>
@@ -224,4 +225,43 @@ lr .req x30 // link register
movk \reg, :abs_g0_nc:\val
.endm
+/*
+ * Check the MIDR_EL1 of the current CPU for a given model and a range of
+ * variant/revision. See asm/cputype.h for the macros used below.
+ *
+ * model: MIDR_CPU_PART of CPU
+ * rv_min: Minimum of MIDR_CPU_VAR_REV()
+ * rv_max: Maximum of MIDR_CPU_VAR_REV()
+ * res: Result register.
+ * tmp1, tmp2, tmp3: Temporary registers
+ *
+ * Corrupts: res, tmp1, tmp2, tmp3
+ * Returns: 0, if the CPU id doesn't match. Non-zero otherwise
+ */
+ .macro cpu_midr_match model, rv_min, rv_max, res, tmp1, tmp2, tmp3
+ mrs \res, midr_el1
+ mov_q \tmp1, (MIDR_REVISION_MASK | MIDR_VARIANT_MASK)
+ mov_q \tmp2, MIDR_CPU_PART_MASK
+ and \tmp3, \res, \tmp2 // Extract model
+ and \tmp1, \res, \tmp1 // rev & variant
+ mov_q \tmp2, \model
+ cmp \tmp3, \tmp2
+ cset \res, eq
+ cbz \res, .Ldone\@ // Model matches ?
+
+ .if (\rv_min != 0) // Skip min check if rv_min == 0
+ mov_q \tmp3, \rv_min
+ cmp \tmp1, \tmp3
+ cset \res, ge
+ .endif // \rv_min != 0
+ /* Skip rv_max check if rv_min == rv_max && rv_min != 0 */
+ .if ((\rv_min != \rv_max) || \rv_min == 0)
+ mov_q \tmp2, \rv_max
+ cmp \tmp1, \tmp2
+ cset \tmp2, le
+ and \res, \res, \tmp2
+ .endif
+.Ldone\@:
+ .endm
+
#endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1a59493..f43e10c 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -57,6 +57,14 @@
#define MIDR_IMPLEMENTOR(midr) \
(((midr) & MIDR_IMPLEMENTOR_MASK) >> MIDR_IMPLEMENTOR_SHIFT)
+#define MIDR_CPU_VAR_REV(var, rev) \
+ (((var) << MIDR_VARIANT_SHIFT) | (rev))
+
+#define MIDR_CPU_PART_MASK \
+ (MIDR_IMPLEMENTOR_MASK | \
+ MIDR_ARCHITECTURE_MASK | \
+ MIDR_PARTNUM_MASK)
+
#define MIDR_CPU_PART(imp, partnum) \
(((imp) << MIDR_IMPLEMENTOR_SHIFT) | \
(0xf << MIDR_ARCHITECTURE_SHIFT) | \
@@ -70,11 +78,14 @@
#define ARM_CPU_PART_FOUNDATION 0xD00
#define ARM_CPU_PART_CORTEX_A57 0xD07
#define ARM_CPU_PART_CORTEX_A53 0xD03
+#define ARM_CPU_PART_CORTEX_A55 0xD05
#define APM_CPU_PART_POTENZA 0x000
#define CAVIUM_CPU_PART_THUNDERX 0x0A1
+#define MIDR_CORTEX_A55 MIDR_CPU_PART(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A55)
+
#ifndef __ASSEMBLY__
/*
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 18201e9..f096367 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -221,6 +221,11 @@ ENTRY(__cpu_setup)
cbz x9, 2f
cmp x9, #2
b.lt 1f
+#ifdef CONFIG_ARM64_ERRATUM_1024718
+ /* Disable hardware DBM on Cortex-A55 r0p0, r0p1 & r1p0 */
+ cpu_midr_match MIDR_CORTEX_A55, MIDR_CPU_VAR_REV(0, 0), MIDR_CPU_VAR_REV(1, 0), x1, x2, x3, x4
+ cbnz x1, 1f
+#endif
orr x10, x10, #TCR_HD // hardware Dirty flag update
1: orr x10, x10, #TCR_HA // hardware Access flag update
2:
--
2.7.4
^ permalink raw reply related
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Dave Martin @ 2018-05-14 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-7-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:28AM +0100, Mark Rutland wrote:
> In subsequent patches, we'll want to make use of sve_user_enable() and
> sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
> <asm/fpsimd.h> where we can make use of them.
>
> To avoid ifdeffery in sequences like:
>
> if (system_supports_sve() && some_condition
> sve_user_disable();
>
> ... empty stubs are provided when support for SVE is not enabled.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/fpsimd.h | 17 ++++++++++++++++-
> arch/arm64/kernel/fpsimd.c | 11 -----------
> 2 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index aa7162ae93e3..7377d7593c06 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -16,11 +16,13 @@
> #ifndef __ASM_FP_H
> #define __ASM_FP_H
>
> -#include <asm/ptrace.h>
> #include <asm/errno.h>
> +#include <asm/ptrace.h>
> +#include <asm/sysreg.h>
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/build_bug.h>
> #include <linux/cache.h>
> #include <linux/init.h>
> #include <linux/stddef.h>
> @@ -81,6 +83,16 @@ extern int sve_set_vector_length(struct task_struct *task,
> extern int sve_set_current_vl(unsigned long arg);
> extern int sve_get_current_vl(void);
>
> +static inline void sve_user_disable(void)
> +{
> + sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
> +}
> +
> +static inline void sve_user_enable(void)
> +{
> + sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
> +}
> +
> /*
> * Probing and setup functions.
> * Calls to these functions must be serialised with one another.
> @@ -107,6 +119,9 @@ static inline int sve_get_current_vl(void)
> return -EINVAL;
> }
>
> +static inline void sve_user_disable(void) { }
> +static inline void sve_user_enable(void) { }
> +
Alternatively, just move the full definitions outside the #ifdef
CONFIG_ARM64_SVE.
All calls to these should be shadowed by an if
(system_supports_sve()) in any case, and setting/clearing ZEN_EL0EN
in the CPACR_EL1 ought to be harmless now that the meaning of these
bits architecturally committed.
Ideally we would have a BUG_ON(!system_supports_sve()) in those
functions, but we won't won't to pay the cost in a production kernel.
> static inline void sve_init_vq_map(void) { }
> static inline void sve_update_vq_map(void) { }
> static inline int sve_verify_vq_map(void) { return 0; }
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 088940387a4d..79a81c7d85c6 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> __sve_free(task);
> }
>
> -
Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
trivial).
[...]
Cheers
---Dave
[1]
[PATCH v7 10/16] arm64/sve: Switch sve_pffr() argument from task to thread
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576601.html
[PATCH v7 11/16] arm64/sve: Move sve_pffr() to fpsimd.h and make inline
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576606.html
^ permalink raw reply
* [PATCH 07/18] arm64: remove sigreturn wrappers
From: Dave Martin @ 2018-05-14 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-8-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:29AM +0100, Mark Rutland wrote:
> The arm64 sigreturn* syscall handlers are non-standard. Rather than
> taking a number of user parameters in registers as per the AAPCS,
> they expect the pt_regs as their sole argument.
>
> To make this work, we override the syscall definitions to invoke
> wrappers written in assembly, which mov the SP into x0, and branch to
> their respective C functions.
>
> On other architectures (such as x86), the sigreturn* functions take no
> argument and instead use current_pt_regs() to acquire the user
> registers. This requires less boilerplate code, and allows for other
> features such as interposing C code in this path.
Hmmm, I always wondered why rt_sigreturn() et al. were handled
specially.
If there's effectively no underlying reason for that, it makes sense
to regularise the interface to these syscalls.
Tentatively-reviewed-by: Dave Martin <Dave.Martin@arm.com>
>
> This patch takes the same approach for arm64.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/unistd32.h | 4 ++--
> arch/arm64/kernel/entry.S | 8 --------
> arch/arm64/kernel/entry32.S | 10 ----------
> arch/arm64/kernel/signal.c | 3 ++-
> arch/arm64/kernel/signal32.c | 6 ++++--
> arch/arm64/kernel/sys.c | 3 +--
> arch/arm64/kernel/sys32.c | 4 ++--
> 7 files changed, 11 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h
> index ef292160748c..ab95554b1734 100644
> --- a/arch/arm64/include/asm/unistd32.h
> +++ b/arch/arm64/include/asm/unistd32.h
> @@ -260,7 +260,7 @@ __SYSCALL(117, sys_ni_syscall)
> #define __NR_fsync 118
> __SYSCALL(__NR_fsync, sys_fsync)
> #define __NR_sigreturn 119
> -__SYSCALL(__NR_sigreturn, compat_sys_sigreturn_wrapper)
> +__SYSCALL(__NR_sigreturn, compat_sys_sigreturn)
> #define __NR_clone 120
> __SYSCALL(__NR_clone, sys_clone)
> #define __NR_setdomainname 121
> @@ -368,7 +368,7 @@ __SYSCALL(__NR_getresgid, sys_getresgid16)
> #define __NR_prctl 172
> __SYSCALL(__NR_prctl, sys_prctl)
> #define __NR_rt_sigreturn 173
> -__SYSCALL(__NR_rt_sigreturn, compat_sys_rt_sigreturn_wrapper)
> +__SYSCALL(__NR_rt_sigreturn, compat_sys_rt_sigreturn)
> #define __NR_rt_sigaction 174
> __SYSCALL(__NR_rt_sigaction, compat_sys_rt_sigaction)
> #define __NR_rt_sigprocmask 175
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index ec2ee720e33e..08ea3cbfb08f 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -1108,14 +1108,6 @@ __entry_tramp_data_start:
> #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>
> /*
> - * Special system call wrappers.
> - */
> -ENTRY(sys_rt_sigreturn_wrapper)
> - mov x0, sp
> - b sys_rt_sigreturn
> -ENDPROC(sys_rt_sigreturn_wrapper)
> -
> -/*
> * Register switch for AArch64. The callee-saved registers need to be saved
> * and restored. On entry:
> * x0 = previous task_struct (must be preserved across the switch)
> diff --git a/arch/arm64/kernel/entry32.S b/arch/arm64/kernel/entry32.S
> index f332d5d1f6b4..f9461696dde4 100644
> --- a/arch/arm64/kernel/entry32.S
> +++ b/arch/arm64/kernel/entry32.S
> @@ -30,16 +30,6 @@
> * System call wrappers for the AArch32 compatibility layer.
> */
>
> -ENTRY(compat_sys_sigreturn_wrapper)
> - mov x0, sp
> - b compat_sys_sigreturn
> -ENDPROC(compat_sys_sigreturn_wrapper)
> -
> -ENTRY(compat_sys_rt_sigreturn_wrapper)
> - mov x0, sp
> - b compat_sys_rt_sigreturn
> -ENDPROC(compat_sys_rt_sigreturn_wrapper)
> -
> ENTRY(compat_sys_statfs64_wrapper)
> mov w3, #84
> cmp w1, #88
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 8e624fec4707..caa7a68cf2d2 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -538,8 +538,9 @@ static int restore_sigframe(struct pt_regs *regs,
> return err;
> }
>
> -asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
> +asmlinkage long sys_rt_sigreturn(void)
> {
> + struct pt_regs *regs = current_pt_regs();
> struct rt_sigframe __user *frame;
>
> /* Always make any pending restarted system calls return -EINTR */
> diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
> index 77b91f478995..cb10588a7cb2 100644
> --- a/arch/arm64/kernel/signal32.c
> +++ b/arch/arm64/kernel/signal32.c
> @@ -282,8 +282,9 @@ static int compat_restore_sigframe(struct pt_regs *regs,
> return err;
> }
>
> -asmlinkage int compat_sys_sigreturn(struct pt_regs *regs)
> +asmlinkage int compat_sys_sigreturn(void)
> {
> + struct pt_regs *regs = current_pt_regs();
> struct compat_sigframe __user *frame;
>
> /* Always make any pending restarted system calls return -EINTR */
> @@ -312,8 +313,9 @@ asmlinkage int compat_sys_sigreturn(struct pt_regs *regs)
> return 0;
> }
>
> -asmlinkage int compat_sys_rt_sigreturn(struct pt_regs *regs)
> +asmlinkage int compat_sys_rt_sigreturn(void)
> {
> + struct pt_regs *regs = current_pt_regs();
> struct compat_rt_sigframe __user *frame;
>
> /* Always make any pending restarted system calls return -EINTR */
> diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
> index 72981bae10eb..31045f3fed92 100644
> --- a/arch/arm64/kernel/sys.c
> +++ b/arch/arm64/kernel/sys.c
> @@ -48,8 +48,7 @@ SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
> /*
> * Wrappers to pass the pt_regs argument.
> */
> -asmlinkage long sys_rt_sigreturn_wrapper(void);
> -#define sys_rt_sigreturn sys_rt_sigreturn_wrapper
> +asmlinkage long sys_rt_sigreturn(void);
> #define sys_personality sys_arm64_personality
>
> #undef __SYSCALL
> diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
> index a40b1343b819..1ef103c95410 100644
> --- a/arch/arm64/kernel/sys32.c
> +++ b/arch/arm64/kernel/sys32.c
> @@ -25,8 +25,8 @@
> #include <linux/compiler.h>
> #include <linux/syscalls.h>
>
> -asmlinkage long compat_sys_sigreturn_wrapper(void);
> -asmlinkage long compat_sys_rt_sigreturn_wrapper(void);
> +asmlinkage long compat_sys_sigreturn(void);
> +asmlinkage long compat_sys_rt_sigreturn(void);
> asmlinkage long compat_sys_statfs64_wrapper(void);
> asmlinkage long compat_sys_fstatfs64_wrapper(void);
> asmlinkage long compat_sys_pread64_wrapper(void);
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Dave Martin @ 2018-05-14 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-9-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:30AM +0100, Mark Rutland wrote:
> As a first step towards invoking syscalls with a pt_regs argument,
> convert the raw syscall invocation logic to C. We end up with a bit more
> register shuffling, but the unified invocation logic means we can unify
> the tracing paths, too.
>
> This only converts the invocation of the syscall. The rest of the
> syscall triage and tracing is left in assembly for now, and will be
> converted in subsequent patches.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/Makefile | 3 ++-
> arch/arm64/kernel/entry.S | 36 ++++++++++--------------------------
> arch/arm64/kernel/syscall.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 41 insertions(+), 27 deletions(-)
> create mode 100644 arch/arm64/kernel/syscall.c
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index bf825f38d206..c22e8ace5ea3 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -18,7 +18,8 @@ arm64-obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
> hyp-stub.o psci.o cpu_ops.o insn.o \
> return_address.o cpuinfo.o cpu_errata.o \
> cpufeature.o alternative.o cacheinfo.o \
> - smp.o smp_spin_table.o topology.o smccc-call.o
> + smp.o smp_spin_table.o topology.o smccc-call.o \
> + syscall.o
>
> extra-$(CONFIG_EFI) := efi-entry.o
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 08ea3cbfb08f..d6e057500eaf 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -873,7 +873,6 @@ ENDPROC(el0_error)
> */
> ret_fast_syscall:
> disable_daif
> - str x0, [sp, #S_X0] // returned x0
> ldr x1, [tsk, #TSK_TI_FLAGS] // re-check for syscall tracing
> and x2, x1, #_TIF_SYSCALL_WORK
> cbnz x2, ret_fast_syscall_trace
> @@ -946,15 +945,11 @@ el0_svc_naked: // compat entry point
>
> tst x16, #_TIF_SYSCALL_WORK // check for syscall hooks
> b.ne __sys_trace
> - cmp wscno, wsc_nr // check upper syscall limit
> - b.hs ni_sys
> - mask_nospec64 xscno, xsc_nr, x19 // enforce bounds for syscall number
> - ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
> - blr x16 // call sys_* routine
> - b ret_fast_syscall
> -ni_sys:
> mov x0, sp
> - bl do_ni_syscall
> + mov w1, wscno
> + mov w2, wsc_nr
> + mov x3, stbl
> + bl invoke_syscall
> b ret_fast_syscall
> ENDPROC(el0_svc)
>
> @@ -971,29 +966,18 @@ __sys_trace:
> bl syscall_trace_enter
> cmp w0, #NO_SYSCALL // skip the syscall?
> b.eq __sys_trace_return_skipped
> - mov wscno, w0 // syscall number (possibly new)
> - mov x1, sp // pointer to regs
> - cmp wscno, wsc_nr // check upper syscall limit
> - b.hs __ni_sys_trace
> - ldp x0, x1, [sp] // restore the syscall args
> - ldp x2, x3, [sp, #S_X2]
> - ldp x4, x5, [sp, #S_X4]
> - ldp x6, x7, [sp, #S_X6]
> - ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
> - blr x16 // call sys_* routine
>
> -__sys_trace_return:
> - str x0, [sp, #S_X0] // save returned x0
> + mov x0, sp
> + mov w1, wscno
> + mov w2, wsc_nr
> + mov x3, stbl
> + bl invoke_syscall
> +
> __sys_trace_return_skipped:
> mov x0, sp
> bl syscall_trace_exit
> b ret_to_user
>
> -__ni_sys_trace:
> - mov x0, sp
> - bl do_ni_syscall
> - b __sys_trace_return
> -
Can you explain why ni_syscall is special here, why __sys_trace_return
existed, and why its disappearance doesn't break anything?
Not saying there's a bug, just that I'm a little confuse -- I see no
real reason for ni_syscall being special, and this may be a good
opportunity to decruft it. (See also comments below.)
> .popsection // .entry.text
>
> #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> new file mode 100644
> index 000000000000..58d7569f47df
> --- /dev/null
> +++ b/arch/arm64/kernel/syscall.c
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/nospec.h>
> +#include <linux/ptrace.h>
> +
> +long do_ni_syscall(struct pt_regs *regs);
> +
> +typedef long (*syscall_fn_t)(unsigned long, unsigned long,
> + unsigned long, unsigned long,
> + unsigned long, unsigned long);
> +
> +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> +{
> + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> + regs->regs[2], regs->regs[3],
> + regs->regs[4], regs->regs[5]);
> +}
> +
> +asmlinkage void invoke_syscall(struct pt_regs *regs, int scno, int sc_nr,
> + syscall_fn_t syscall_table[])
> +{
> + if (scno < sc_nr) {
What if (int)scno < 0? Should those args both by unsigned ints?
"sc_nr" sounds too much like "syscall number" to me. Might
"syscall_table_size" might be clearer? Similarly, we could have
"stbl_size" or similar in the asm. This is purely cosmetic,
though.
> + syscall_fn_t syscall_fn;
> + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> + __invoke_syscall(regs, syscall_fn);
> + } else {
> + regs->regs[0] = do_ni_syscall(regs);
Can we make __invoke_syscall() the universal syscall wrapper, and give
do_ni_syscall() the same interface as any other syscall body?
Then you could factor this as
static syscall_fn_t syscall_fn(syscall_fn_t const syscall_table[],
(unsigned) int scno, (unsigned) int sc_nr)
{
if (sc_no >= sc_nr)
return sys_ni_syscall;
return syscall_table[array_index_nospec(scno, sc_nr)];
}
...
__invoke_syscall(regs, syscall_fn(syscall_table, scno, sc_nr);
This is cosmetic too, of course.
do_ni_syscall() should be given a pt_regs-based wrapper like all the
rest.
This is still cosmetic, but reduces unnecessary special-case-ness
for ni_syscall.
Cheers
---Dave
^ permalink raw reply
* [PATCH 10/18] arm64: convert native/compat syscall entry to C
From: Dave Martin @ 2018-05-14 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-11-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:32AM +0100, Mark Rutland wrote:
> Now that the syscall invocation logic is in C, we can migrate the rest
> of the syscall entry logic over, so that the entry assembly needn't look
> at the register values at all.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/entry.S | 42 ++++--------------------------------------
> arch/arm64/kernel/syscall.c | 40 ++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 42 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 5c60369b52fc..13afefbf608f 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -690,14 +690,9 @@ el0_sync_compat:
> b.ge el0_dbg
> b el0_inv
> el0_svc_compat:
> - /*
> - * AArch32 syscall handling
> - */
> - ldr x16, [tsk, #TSK_TI_FLAGS] // load thread flags
> - adrp stbl, compat_sys_call_table // load compat syscall table pointer
> - mov wscno, w7 // syscall number in w7 (r7)
> - mov wsc_nr, #__NR_compat_syscalls
> - b el0_svc_naked
> + mov x0, sp
> + bl el0_svc_compat_handler
> + b ret_to_user
>
> .align 6
> el0_irq_compat:
> @@ -895,37 +890,8 @@ ENDPROC(ret_to_user)
> */
> .align 6
> el0_svc:
> - ldr x16, [tsk, #TSK_TI_FLAGS] // load thread flags
> - adrp stbl, sys_call_table // load syscall table pointer
> - mov wscno, w8 // syscall number in w8
> - mov wsc_nr, #__NR_syscalls
> -
> -#ifdef CONFIG_ARM64_SVE
> -alternative_if_not ARM64_SVE
> - b el0_svc_naked
> -alternative_else_nop_endif
> - tbz x16, #TIF_SVE, el0_svc_naked // Skip unless TIF_SVE set:
> - bic x16, x16, #_TIF_SVE // discard SVE state
> - str x16, [tsk, #TSK_TI_FLAGS]
> -
> - /*
> - * task_fpsimd_load() won't be called to update CPACR_EL1 in
> - * ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
> - * happens if a context switch or kernel_neon_begin() or context
> - * modification (sigreturn, ptrace) intervenes.
> - * So, ensure that CPACR_EL1 is already correct for the fast-path case:
> - */
> - mrs x9, cpacr_el1
> - bic x9, x9, #CPACR_EL1_ZEN_EL0EN // disable SVE for el0
> - msr cpacr_el1, x9 // synchronised by eret to el0
> -#endif
> -
> -el0_svc_naked: // compat entry point
> mov x0, sp
> - mov w1, wscno
> - mov w2, wsc_nr
> - mov x3, stbl
> - bl el0_svc_common
> + bl el0_svc_handler
> b ret_to_user
> ENDPROC(el0_svc)
>
> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> index 5df857e32b48..4706f841e758 100644
> --- a/arch/arm64/kernel/syscall.c
> +++ b/arch/arm64/kernel/syscall.c
> @@ -6,7 +6,9 @@
> #include <linux/ptrace.h>
>
> #include <asm/daifflags.h>
> +#include <asm/fpsimd.h>
> #include <asm/thread_info.h>
> +#include <asm/unistd.h>
>
> long do_ni_syscall(struct pt_regs *regs);
>
> @@ -41,8 +43,8 @@ static inline bool has_syscall_work(unsigned long flags)
> int syscall_trace_enter(struct pt_regs *regs);
> void syscall_trace_exit(struct pt_regs *regs);
>
> -asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> - syscall_fn_t syscall_table[])
> +static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> + syscall_fn_t syscall_table[])
> {
> unsigned long flags = current_thread_info()->flags;
>
> @@ -79,3 +81,37 @@ asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> trace_exit:
> syscall_trace_exit(regs);
> }
> +
> +static inline void sve_user_reset(void)
Static function with no caller...
> +{
> + if (!system_supports_sve())
> + return;
> +
> + /*
> + * task_fpsimd_load() won't be called to update CPACR_EL1 in
> + * ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
> + * happens if a context switch or kernel_neon_begin() or context
> + * modification (sigreturn, ptrace) intervenes.
> + * So, ensure that CPACR_EL1 is already correct for the fast-path case.
> + */
> + if (test_and_clear_thread_flag(TIF_SVE))
> + sve_user_disable();
sve_user_disable() is already inline, and incorporates the if()
internally via sysreg_clear_set().
So, should this just be
clear_thread_flag(TIF_SVE);
sve_user_disable();
> +}
> +
> +extern syscall_fn_t sys_call_table[];
> +
> +asmlinkage void el0_svc_handler(struct pt_regs *regs)
> +{
if (system_supports_sve()) ?
> + sve_user_disable();
Or should this be replaced by a call to sve_user_reset()?
I suspect the latter, since we do want to be clearing TIF_SVE here too.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 11/18] arm64: zero GPRs upon entry from EL0
From: Dave Martin @ 2018-05-14 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-12-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:33AM +0100, Mark Rutland wrote:
> We can zero GPRs x0 - x29 upon entry from EL0 to make it harder for
> userspace to control values consumed by speculative gadgets.
>
> We don't blat x30, since this is stashed much later, and we'll blat it
> before invoking C code.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/entry.S | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 13afefbf608f..4dd529fd03fd 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -62,6 +62,12 @@
> #endif
> .endm
>
> + .macro clear_gp_regs
> + .irp n,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29
> + mov x\n, xzr
> + .endr
> + .endm
> +
Looks OK, but consider moving _for from fpsimdmacros.h to assembler.h
and just writing
_for n, 0, 29, mov x\n, xzr
(could even omit the wrapper macro, since this is a one-liner).
The implementation of _for is a bit gross, but since we already have it,
we might as well use it.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 12/18] kernel: add ksys_personality()
From: Dave Martin @ 2018-05-14 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514094640.27569-13-mark.rutland@arm.com>
On Mon, May 14, 2018 at 10:46:34AM +0100, Mark Rutland wrote:
> Using this helper allows us to avoid the in-kernel call to the
> sys_personality() syscall. The ksys_ prefix denotes that this function
> is meant as a drop-in replacement for the syscall. In particular, it
> uses the same calling convention as sys_personality().
>
> This is necessary to enable conversion of arm64's syscall handling to
> use pt_regs wrappers.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
> ---
> include/linux/syscalls.h | 1 +
> kernel/exec_domain.c | 7 ++++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 70fcda1a9049..6723ea51ec99 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -1148,6 +1148,7 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,
> unsigned long prot, unsigned long flags,
> unsigned long fd, unsigned long pgoff);
> ssize_t ksys_readahead(int fd, loff_t offset, size_t count);
> +unsigned int ksys_personality(unsigned int personality);
>
> /*
> * The following kernel syscall equivalents are just wrappers to fs-internal
> diff --git a/kernel/exec_domain.c b/kernel/exec_domain.c
> index a5697119290e..4ba2b404cba2 100644
> --- a/kernel/exec_domain.c
> +++ b/kernel/exec_domain.c
> @@ -47,7 +47,7 @@ static int __init proc_execdomains_init(void)
> module_init(proc_execdomains_init);
> #endif
>
> -SYSCALL_DEFINE1(personality, unsigned int, personality)
> +unsigned int ksys_personality(unsigned int personality)
> {
> unsigned int old = current->personality;
>
> @@ -56,3 +56,8 @@ SYSCALL_DEFINE1(personality, unsigned int, personality)
>
> return old;
> }
> +
> +SYSCALL_DEFINE1(personality, unsigned int, personality)
> +{
> + return ksys_personality(personality);
> +}
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Allwinner A64: Issue on external rtc clock to wifi chip
From: Maxime Ripard @ 2018-05-14 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZCAWBHtemeeWcgLy5PoYLn10MwxpHdirqpsxFY3BA7=4g@mail.gmail.com>
On Mon, May 14, 2018 at 03:12:49PM +0530, Jagan Teki wrote:
> On Mon, May 14, 2018 at 2:36 PM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > On Mon, May 14, 2018 at 02:34:22PM +0530, Jagan Teki wrote:
> >> On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
> >> <maxime.ripard@bootlin.com> wrote:
> >> > On Mon, May 14, 2018 at 01:34:56PM +0530, Jagan Teki wrote:
> >> >> On Mon, May 14, 2018 at 1:27 PM, Maxime Ripard
> >> >> <maxime.ripard@bootlin.com> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
> >> >> >> Hi Maxime and All,
> >> >> >>
> >> >> >> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
> >> >> >> to have an external rtc clock has driven from wifi chip.
> >> >> >>
> >> >> >> So the devicetree is configured according to this as below.
> >> >> >>
> >> >> >> / {
> >> >> >> wifi_pwrseq: wifi-pwrseq {
> >> >> >> compatible = "mmc-pwrseq-simple";
> >> >> >> clocks = <&rtc 1>;
> >> >> >> clock-names = "ext_clock";
> >> >> >> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> >> >> >> post-power-on-delay-ms = <400>;
> >> >> >> };
> >> >> >> };
> >> >> >>
> >> >> >> &rtc {
> >> >> >> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> >> >> >> clocks = <&osc32k>;
> >> >> >> #clock-cells = <1>;
> >> >> >> };
> >> >> >>
> >> >> >> &mmc1 {
> >> >> >> pinctrl-names = "default";
> >> >> >> pinctrl-0 = <&mmc1_pins>;
> >> >> >> vmmc-supply = <®_dcdc1>;
> >> >> >> vqmmc-supply = <®_eldo1>;
> >> >> >> mmc-pwrseq = <&wifi_pwrseq>;
> >> >> >> bus-width = <4>;
> >> >> >> non-removable;
> >> >> >> status = "okay";
> >> >> >>
> >> >> >> brcmf: wifi at 1 {
> >> >> >> reg = <1>;
> >> >> >> compatible = "brcm,bcm4329-fmac";
> >> >> >> interrupt-parent = <&r_pio>;
> >> >> >> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
> >> >> >> interrupt-names = "host-wake";
> >> >> >> };
> >> >> >> };
> >> >> >>
> >> >> >> And observed rtc-osc32k-out clock is never enabled[1] and the value of
> >> >> >> LOSC_OUT_GATING is 0x0 which eventually not enabling
> >> >> >> LOSC_OUT_GATING_EN
> >> >> >>
> >> >> >> Pls. let us know if we miss anything here?
> >> >> >>
> >> >> >> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
> >> >> >
> >> >> > Could you paste your config and the logs from a boot to?
> >> >>
> >> >> .config
> >> >> https://paste.ubuntu.com/p/w9w2KB7RFc/
> >> >>
> >> >> dmesg
> >> >> https://paste.ubuntu.com/p/mrZGk5bWRR/
> >> >
> >> > This is kind of weird. Have you tested with a 4.17 kernel? We have
> >> > runtime_pm changes lined up in next, so that might be a regression
> >> > there, even though we tested it with Quentin at some point.
> >>
> >> This is 4.17-rc4 do you want to try it on 4.16 ?
> >
> > No, this is next-20180503. Please try with 4.17-rc4
>
> Couldn't find any different in behaviour [2]
>
> [2] https://paste.ubuntu.com/p/m3PGBwrv6W/
It's hard to tell without the board, but have you looked at the return
value of devm_clk_get in the pwrseq code?
Enabling the clk ftrace events would also help.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/4e65385a/attachment.sig>
^ permalink raw reply
* [PATCH V4] ARM: dts: da850-evm: Enable LCD and Backlight
From: Adam Ford @ 2018-05-14 11:19 UTC (permalink / raw)
To: linux-arm-kernel
When using the board files the LCD works, but not with the DT.
This adds enables the original da850-evm to work with the same
LCD in device tree mode.
The EVM has a gpios for the lcd_panel_pwr, lcd_backlight_pwr,
and lcd_pwm0. Both lcd_backlight_pwr and lcd_pwm0 must be driven
to enable the backlight, so a gpio-regulator is used to drive
lcd_backlight_prw.
The LCD and the vpif display pins are mutually exclusive, so if
using the LCD, disable the vpif. If using the vpif, disable panel.
Extra code comments are inserted to further explain this
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V4: Add comments into the code explaining the LCD and VPIF are mutually
exclusive with instructions on how to enable/disable each. Rename
GPIO pins based on schematic net name. Fix gpio enable in backlight
V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be
more explict to backlight which better matches the schematic.
Updated the description to explain that it cannot be used at the
same time as the vpif driver.
V2: Add regulator and GPIO enable pins. Remove PWM backlight and
replace with GPIO
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 2e817da37fdb..f6a5497d9c97 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,53 @@
spi0 = &spi1;
};
+ backlight {
+ compatible = "gpio-backlight";
+ gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* lcd_pwm0 */
+ };
+
+ panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ /* The vpif and the LCD are mutually exclusive.
+ * To enable VPIF, change the status below to 'disabled' then
+ * then change the status of the vpif below to 'okay' */
+ status = "okay";
+ enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 480x272 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <3>;
+ hback-porch = <2>;
+ hsync-len = <42>;
+ vback-porch = <3>;
+ vfront-porch = <4>;
+ vsync-len = <11>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -35,6 +82,16 @@
regulator-boot-on;
};
+ backlight_reg: backlight-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_backlight_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* lcd_backlight_pwr */
+ regulator-always-on;
+ enable-active-high;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "DA850/OMAP-L138 EVM";
@@ -109,6 +166,10 @@
status = "okay";
};
+&lcdc {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
clock-frequency = <100000>;
@@ -339,5 +400,8 @@
&vpif {
pinctrl-names = "default";
pinctrl-0 = <&vpif_capture_pins>, <&vpif_display_pins>;
- status = "okay";
+ /* The vpif and the LCD are mutually exclusive.
+ * To enable VPIF, disable the ti,tilcdc,panel then
+ * changed the status below to 'okay' */
+ status = "disabled";
};
--
2.17.0
^ permalink raw reply related
* [PATCH 02/18] arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
From: Dave Martin @ 2018-05-14 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514100858.4xjp5d3axbyy74ap@lakrids.cambridge.arm.com>
On Mon, May 14, 2018 at 11:08:59AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 11:00:53AM +0100, Dave Martin wrote:
> > On Mon, May 14, 2018 at 10:46:24AM +0100, Mark Rutland wrote:
> > > -/* Check all the bits are accounted for */
> > > -#define SCTLR_EL2_BUILD_BUG_ON_MISSING_BITS BUILD_BUG_ON((SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != ~0)
> > > -
> > > +#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xffffffff
> > > +#error "Inconsistent SCTLR_EL2 set/clear bits"
> > > +#endif
> >
> > Can we have a comment on the != 0xffffffff versus != ~0 here?
> >
> > The subtle differences in evaluation semantics between #if and
> > other contexts here may well trip people up during maintenance...
>
> Do you have any suggestion as to the wording?
>
> I'm happy to add a comment, but I don't really know what to say.
How about the following?
/* Watch out for #if evaluation rules: ~0 is not ~(int)0! */
Cheers
---Dave
^ permalink raw reply
* [GIT PULL] defconfig updates for v4.18
From: Matthias Brugger @ 2018-05-14 11:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof and Arnd,
Please merge the following patch for defconfig.
Thanks,
Matthias
---
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v4.17-next-defconfig
for you to fetch changes up to 1e31927aa64545ee97a2a41db9984c9931afc50a:
arm64: defconfig: Enable CONFIG_PINCTRL_MT7622 by default (2018-04-27 11:48:37
+0200)
----------------------------------------------------------------
enable mt7622 pinctrl to fix boot issue
----------------------------------------------------------------
Sean Wang (1):
arm64: defconfig: Enable CONFIG_PINCTRL_MT7622 by default
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Greg KH @ 2018-05-14 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525069641-8523-6-git-send-email-nipun.gupta@nxp.com>
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
I can't take patches without any changelog text at all, sorry. Please
fix up and resend.
greg k-h
^ permalink raw reply
* [GIT PULL] ARM: mediatek: updates of dts32 for v4.18
From: Matthias Brugger @ 2018-05-14 11:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Hi Olof,
please have a look on the following updates for 32-bit DTS files.
Thanks,
Matthias
---
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v4.17-next-dts32
for you to fetch changes up to dd0dcf003dd86caba7726cc1e2ef268f1cf11aae:
arm: dts: mt7623: add MT7623N reference board with eMMC (2018-05-11 17:52:28
+0200)
----------------------------------------------------------------
convert to SPDX IDs
mt7623:
- add audio, bluetooth, highspees DMA and SPI-NOR nodes
- fix invalid memory nodes by not using skeleton64.dtsi
- fix memory size for bananapi-r2
- fix dtc warnings
- refactor dts and dtsi to aviod code duplication
- add mt7623n and mt7623a reference boards
----------------------------------------------------------------
Ryder Lee (1):
arm: dts: mediatek: modify audio related nodes for both MT2701 and MT7623
Sean Wang (10):
arm: dts: mediatek: converted to using SPDX identifiers
arm: dts: mt7623: fix invalid memory node being generated
arm: dts: mt7623: fix available memory size on bananapi-r2
arm: dts: mt7623: fix all Warnings (unit_address_vs_reg)
arm: dts: mt7623: add BTIF, HSDMA and SPI-NOR device nodes
arm: dts: mt6323: move node mt6323 leds to mt6323.dtsi
arm: dts: mt7623: extend common file reused by all boards with MT7623 SoCs
arm: dts: mt7623: add MT7623A SoC level DTS
arm: dts: mt7623: add MT7623A reference boards
arm: dts: mt7623: add MT7623N reference board with eMMC
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/mt2701-evb.dts | 9 +-
arch/arm/boot/dts/mt2701.dtsi | 197 +++++-----
arch/arm/boot/dts/mt6323.dtsi | 17 +-
arch/arm/boot/dts/mt6580-evbp1.dts | 9 +-
arch/arm/boot/dts/mt6580.dtsi | 9 +-
arch/arm/boot/dts/mt6589-aquaris5.dts | 10 +-
arch/arm/boot/dts/mt6589.dtsi | 12 +-
arch/arm/boot/dts/mt6592-evb.dts | 9 +-
arch/arm/boot/dts/mt6592.dtsi | 9 +-
arch/arm/boot/dts/mt7623.dtsi | 537 ++++++++++++++++++++------
arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 291 ++++++++++++++
arch/arm/boot/dts/mt7623a-rfb-nand.dts | 337 ++++++++++++++++
arch/arm/boot/dts/mt7623a.dtsi | 44 +++
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 279 ++-----------
arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 326 ++++++++++++++++
arch/arm/boot/dts/mt7623n-rfb-nand.dts | 40 +-
arch/arm/boot/dts/mt7623n-rfb.dtsi | 12 +-
arch/arm/boot/dts/mt8127-moose.dts | 9 +-
arch/arm/boot/dts/mt8127.dtsi | 9 +-
arch/arm/boot/dts/mt8135-evbp1.dts | 9 +-
arch/arm/boot/dts/mt8135.dtsi | 9 +-
22 files changed, 1573 insertions(+), 613 deletions(-)
create mode 100644 arch/arm/boot/dts/mt7623a-rfb-emmc.dts
create mode 100644 arch/arm/boot/dts/mt7623a-rfb-nand.dts
create mode 100644 arch/arm/boot/dts/mt7623a.dtsi
create mode 100644 arch/arm/boot/dts/mt7623n-rfb-emmc.dts
^ permalink raw reply
* [GIT PULL] ARM: mediatek: dts64 updates for v4.18
From: Matthias Brugger @ 2018-05-14 11:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi you two,
Please take into account the following commit to 64-bit DTS.
Thanks a lot,
Matthias
---
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v4.17-next-dts64
for you to fetch changes up to f1e0d0d8cf454202d21140aace184cc5512a9fdd:
arm64: dts: mt7622: add audio related device nodes (2018-05-11 18:42:20 +0200)
----------------------------------------------------------------
- add clock and pinctrl nodes for mt2712e
- add High-Speed DMA and audio nodes for mt7622
----------------------------------------------------------------
Ryder Lee (1):
arm64: dts: mt7622: add audio related device nodes
Sean Wang (1):
arm64: dts: mt7622: add High-Speed DMA device nodes
Zhiyong Tao (2):
arm64: dts: mt2712: add pintcrl file
arm64: dts: mt2712: add pintcrl device node.
weiyi.lu at mediatek.com (1):
arm64: dts: add clock device nodes of MT2712
arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 +++++++++++++++++++++++++
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 46 +
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 11 +-
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 99 +++
4 files changed, 1277 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
^ permalink raw reply
* [GIT PULL] ARM: mediatek: soc driver updates for v4.18
From: Matthias Brugger @ 2018-05-14 11:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Below the commits for mediatek soc drivers.
Please beware that we need the regmap-ktime-fix [1] from Mark Browns static tag.
I merged that into my branch, but I wanted to let you know, so that you don't
hit any breakage when pulling in my branch.
Regards,
Matthias
[1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
tags/regmap-ktime-fix
---
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v4.17-next-soc
for you to fetch changes up to 0afd32c6bb59e41b6692dec4473efaffffcad67b:
Merge commit 'f15cd6d99198e9c15229aefec639a34a6e8174c6' into
v.4.17-next/soc-test (2018-05-14 12:22:03 +0200)
----------------------------------------------------------------
- use timeout helpers for scpsys and infracfg drivers
- use of_device_get_match_data in pmic wrapper and scpsys
----------------------------------------------------------------
Matthias Brugger (1):
Merge commit 'f15cd6d99198e9c15229aefec639a34a6e8174c6' into
v.4.17-next/soc-test
Ryder Lee (1):
soc: mediatek: use of_device_get_match_data()
Sean Wang (6):
soc: mediatek: reuse read[l,x]_poll_timeout helpers
regmap: include <linux/ktime.h> from include/linux/regmap.h
soc: mediatek: reuse regmap_read_poll_timeout helpers
soc: mediatek: introduce a CAPS flag for scp_domain_data
soc: mediatek: add a fixed wait for SRAM stable
soc: mediatek: remove unneeded semicolon
drivers/soc/mediatek/mtk-infracfg.c | 46 +++-------
drivers/soc/mediatek/mtk-pmic-wrap.c | 13 +--
drivers/soc/mediatek/mtk-scpsys.c | 167 ++++++++++++++---------------------
include/linux/regmap.h | 1 +
4 files changed, 83 insertions(+), 144 deletions(-)
^ permalink raw reply
* [PATCH 00/12] introduce support for early platform drivers
From: Bartosz Golaszewski @ 2018-05-14 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL3CWFSpKEGoGwQDxCQ04g4uT1hiDTxXzjz4XTjPbfsoQ@mail.gmail.com>
2018-05-11 22:13 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> This series is a follow-up to the RFC[1] posted a couple days ago.
>>
>> NOTE: this series applies on top of my recent patches[2] that move the previous
>> implementation of early platform devices to arch/sh.
>>
>> Problem:
>>
>> Certain class of devices, such as timers, certain clock drivers and irq chip
>> drivers need to be probed early in the boot sequence. The currently preferred
>> approach is using one of the OF_DECLARE() macros. This however does not create
>> a platform device which has many drawbacks - such as not being able to use
>> devres routines, dev_ log functions or no way of deferring the init OF function
>> if some other resources are missing.
>
> I skimmed though this and it doesn't look horrible (how's that for
> positive feedback? ;) ). But before going into the details, I think
> first there needs to be agreement this is the right direction.
>
> The question does remain though as to whether this class of devices
> should be platform drivers. They can't be modules. They can't be
> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
>
The main (but not the only) advantage for drivers that can both be
platform drivers and OF_DECLARE drivers is that we get a single entry
point and can reuse code without resorting to checking if (!dev). It
results in more consistent code base. Another big advantage is
consolidation of device tree and machine code for SoC drivers used in
different boards of which some are still using board files and others
are defined in DT (see: DaVinci).
> I assume that the clock maintainers had some reason to move clocks to
> be platform drivers. It's just not clear to me what that was.
>
>> For drivers that use both platform drivers and OF_DECLARE the situation is even
>> more complicated as the code needs to take into account that there can possibly
>> be no struct device present. For a specific use case that we're having problems
>> with, please refer to the recent DaVinci common-clock conversion patches and
>> the nasty workaround that this problem implies[3].
>
> So devm_kzalloc will work with this solution? Why did we need
> devm_kzalloc in the first place? The clocks can never be removed and
> cleaning up on error paths is kind of pointless. The system would be
> hosed, right?
>
It depends - not all clocks are necessary for system to boot.
>> We also used to have an early platform drivers implementation but they were not
>> integrated with the linux device model at all - they merely used the same data
>> structures. The users could not use devres, defer probe and the early devices
>> never became actual platform devices later on.
>>
>> Proposed solution:
>>
>> This series aims at solving this problem by (re-)introducing the concept of
>> early platform drivers and devices - this time however in a way that seamlessly
>> integrates with the existing platform drivers and also offers device-tree
>> support.
>>
>> The idea is to provide a way for users to probe devices early, while already
>> being able to use devres, devices resources and properties and also deferred
>> probing.
>>
>> New structures are introduced: the early platform driver contains the
>> early_probe callback which has the same signature as regular platform_device
>> probe. This callback is called early on. The user can have both the early and
>> regular probe speficied or only one of them and they both receive the same
>> platform device object as argument. Any device data allocated early will be
>> carried over to the normal probe.
>>
>> The architecture code is responsible for calling early_platform_start() in
>> which the early drivers will be registered and devices populated from DT.
>
> Can we really do this in one spot for different devices (clk, timers,
> irq). The sequence is all very carefully crafted. Platform specific
> hooks is another thing to consider.
>
This is why I added support for early probe deferral - so that we can
stop caring for the order as long as the drivers are aware of other
resources they need and we call early_platform_start() the moment the
earliest of the early devices is needed.
>> Once the device and kobject mechanisms are ready, all early drivers and devices
>> will be converted into real platform drivers and devices. Also: if any of the
>> early platform registration functions will be called once early initialization
>> is done, these functions will work like regular platform_device/driver ones.
>
> This could leave devices in a weird state. They've successfully probed
> early, but then are on the deferred list for normal probe for example.
>
It's not really a weird state - once we're past the 'early' stage, the
drivers' "earlyness" no longer plays any role. An early deferred
device wouldn't be any different from other deferred devices. It's
possible that we enabled some crucial resources in the early stage and
then failed to fully probe the device later. I don't see a problem
with that.
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH v3 2/3] platform: move the early platform device support to arch/sh
From: Greg Kroah-Hartman @ 2018-05-14 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504132731.14574-3-brgl@bgdev.pl>
On Fri, May 04, 2018 at 03:27:30PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> SuperH is the only user of the current implementation of early platform
> device support. We want to introduce a more robust approach to early
> probing. As the first step - move all the current early platform code
> to arch/sh.
>
> In order not to export internal drivers/base functions to arch code for
> this temporary solution - copy the two needed routines for driver
> matching from drivers/base/platform.c to arch/sh/drivers/platform_early.c.
>
> Also: call early_platform_cleanup() from subsys_initcall() so that it's
> called after all early devices are probed.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH 08/18] arm64: convert raw syscall invocation to C
From: Mark Rutland @ 2018-05-14 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514110717.GE7753@e103592.cambridge.arm.com>
On Mon, May 14, 2018 at 12:07:18PM +0100, Dave Martin wrote:
> On Mon, May 14, 2018 at 10:46:30AM +0100, Mark Rutland wrote:
> > As a first step towards invoking syscalls with a pt_regs argument,
> > convert the raw syscall invocation logic to C. We end up with a bit more
> > register shuffling, but the unified invocation logic means we can unify
> > the tracing paths, too.
> >
> > This only converts the invocation of the syscall. The rest of the
> > syscall triage and tracing is left in assembly for now, and will be
> > converted in subsequent patches.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/kernel/Makefile | 3 ++-
> > arch/arm64/kernel/entry.S | 36 ++++++++++--------------------------
> > arch/arm64/kernel/syscall.c | 29 +++++++++++++++++++++++++++++
> > 3 files changed, 41 insertions(+), 27 deletions(-)
> > create mode 100644 arch/arm64/kernel/syscall.c
> >
> > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > index bf825f38d206..c22e8ace5ea3 100644
> > --- a/arch/arm64/kernel/Makefile
> > +++ b/arch/arm64/kernel/Makefile
> > @@ -18,7 +18,8 @@ arm64-obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
> > hyp-stub.o psci.o cpu_ops.o insn.o \
> > return_address.o cpuinfo.o cpu_errata.o \
> > cpufeature.o alternative.o cacheinfo.o \
> > - smp.o smp_spin_table.o topology.o smccc-call.o
> > + smp.o smp_spin_table.o topology.o smccc-call.o \
> > + syscall.o
> >
> > extra-$(CONFIG_EFI) := efi-entry.o
> >
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 08ea3cbfb08f..d6e057500eaf 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -873,7 +873,6 @@ ENDPROC(el0_error)
> > */
> > ret_fast_syscall:
> > disable_daif
> > - str x0, [sp, #S_X0] // returned x0
> > ldr x1, [tsk, #TSK_TI_FLAGS] // re-check for syscall tracing
> > and x2, x1, #_TIF_SYSCALL_WORK
> > cbnz x2, ret_fast_syscall_trace
> > @@ -946,15 +945,11 @@ el0_svc_naked: // compat entry point
> >
> > tst x16, #_TIF_SYSCALL_WORK // check for syscall hooks
> > b.ne __sys_trace
> > - cmp wscno, wsc_nr // check upper syscall limit
> > - b.hs ni_sys
> > - mask_nospec64 xscno, xsc_nr, x19 // enforce bounds for syscall number
> > - ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
> > - blr x16 // call sys_* routine
> > - b ret_fast_syscall
> > -ni_sys:
> > mov x0, sp
> > - bl do_ni_syscall
> > + mov w1, wscno
> > + mov w2, wsc_nr
> > + mov x3, stbl
> > + bl invoke_syscall
> > b ret_fast_syscall
> > ENDPROC(el0_svc)
> >
> > @@ -971,29 +966,18 @@ __sys_trace:
> > bl syscall_trace_enter
> > cmp w0, #NO_SYSCALL // skip the syscall?
> > b.eq __sys_trace_return_skipped
> > - mov wscno, w0 // syscall number (possibly new)
> > - mov x1, sp // pointer to regs
> > - cmp wscno, wsc_nr // check upper syscall limit
> > - b.hs __ni_sys_trace
> > - ldp x0, x1, [sp] // restore the syscall args
> > - ldp x2, x3, [sp, #S_X2]
> > - ldp x4, x5, [sp, #S_X4]
> > - ldp x6, x7, [sp, #S_X6]
> > - ldr x16, [stbl, xscno, lsl #3] // address in the syscall table
> > - blr x16 // call sys_* routine
> >
> > -__sys_trace_return:
> > - str x0, [sp, #S_X0] // save returned x0
> > + mov x0, sp
> > + mov w1, wscno
> > + mov w2, wsc_nr
> > + mov x3, stbl
> > + bl invoke_syscall
> > +
> > __sys_trace_return_skipped:
> > mov x0, sp
> > bl syscall_trace_exit
> > b ret_to_user
> >
> > -__ni_sys_trace:
> > - mov x0, sp
> > - bl do_ni_syscall
> > - b __sys_trace_return
> > -
>
> Can you explain why ni_syscall is special here,
This is for out-of-range syscall numbers, instances of ni_syscall in the
syscall table are handled by the regular path. When the syscall number
is out-of-range, we can't index the syscall table, and have to call
ni_sys directly.
The c invoke_syscall() wrapper handles that case internally so that we
don't have to open-code it everywhere.
> why __sys_trace_return existed,
The __sys_trace_return label existed so that the special __ni_sys_trace
path could return into a common tracing return path.
> and why its disappearance doesn't break anything?
Now that invoke_syscall() handles out-of-range syscall numbers, and we
can remove the __ni_sys_trace path, nothing branches to
__sys_trace_return.
Only the label has been removed, not the usual return path.
> Not saying there's a bug, just that I'm a little confuse -- I see no
> real reason for ni_syscall being special, and this may be a good
> opportunity to decruft it. (See also comments below.)
Hopefully the above clarifies things?
I've updated the commit message with a description.
[...]
> > +asmlinkage void invoke_syscall(struct pt_regs *regs, int scno, int sc_nr,
> > + syscall_fn_t syscall_table[])
> > +{
> > + if (scno < sc_nr) {
>
> What if (int)scno < 0? Should those args both by unsigned ints?
Yes, they should -- I've fixed that up locally.
That is a *very* good point, thanks!
> "sc_nr" sounds too much like "syscall number" to me. Might
> "syscall_table_size" might be clearer? Similarly, we could have
> "stbl_size" or similar in the asm. This is purely cosmetic,
> though.
I'd tried to stick to the naming used in assembly to keep the conversion
clearer for those familiar with the asm.
I agree the names aren't great.
> > + syscall_fn_t syscall_fn;
> > + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> > + __invoke_syscall(regs, syscall_fn);
> > + } else {
> > + regs->regs[0] = do_ni_syscall(regs);
>
> Can we make __invoke_syscall() the universal syscall wrapper, and give
> do_ni_syscall() the same interface as any other syscall body?
Not at this point in time, since the prototype (in core code) differs.
I agree that would be nicer, but there are a number of complications;
more details below.
> Then you could factor this as
>
> static syscall_fn_t syscall_fn(syscall_fn_t const syscall_table[],
> (unsigned) int scno, (unsigned) int sc_nr)
> {
> if (sc_no >= sc_nr)
> return sys_ni_syscall;
>
> return syscall_table[array_index_nospec(scno, sc_nr)];
> }
>
> ...
> __invoke_syscall(regs, syscall_fn(syscall_table, scno, sc_nr);
>
>
>
> This is cosmetic too, of course.
>
> do_ni_syscall() should be given a pt_regs-based wrapper like all the
> rest.
I agree it would be nicer if it had a wrapper that took a pt_regs, even
if it does nothing with it.
We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
need a ksys_ni_syscall() for our traps.c logic, and adding this
uniformly would involve some arch-specific rework for x86, too, so I
decided it was not worth the effort.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 0/4] arm64: SMCCC conduit cleanup
From: Lorenzo Pieralisi @ 2018-05-14 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503170330.5591-1-mark.rutland@arm.com>
On Thu, May 03, 2018 at 06:03:26PM +0100, Mark Rutland wrote:
> Currently, the cpu errata code goes digging into PSCI internals to
> discover the SMCCC conduit, using the (arguably misnamed) PSCI_CONDUIT_*
> definitions. This lack of abstraction is somewhat unfortunate.
>
> Further, the SDEI code has an almost identical set of CONDUIT_*
> definitions, and the duplication is rather unfortunate.
>
> Let's unify things behind a common set of SMCCC_CONDUIT_* definitions,
> and expose the SMCCCv1.1 conduit via a new helper that hides the PSCI
> driver internals.
>
> Mark.
>
> Mark Rutland (4):
> arm/arm64: smccc/psci: add arm_smccc_get_conduit()
> arm64: errata: use arm_smccc_get_conduit()
> firmware/psci: use common SMCCC_CONDUIT_*
> firmware: arm_sdei: use common SMCCC_CONDUIT_*
>
> arch/arm64/kernel/cpu_errata.c | 11 +++--------
> arch/arm64/kernel/sdei.c | 3 ++-
> drivers/firmware/arm_sdei.c | 12 ++++++------
> drivers/firmware/psci.c | 24 ++++++++++++++++--------
> include/linux/arm-smccc.h | 16 ++++++++++++++++
> include/linux/arm_sdei.h | 6 ------
> include/linux/psci.h | 9 ++-------
> 7 files changed, 45 insertions(+), 36 deletions(-)
For the series:
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
^ permalink raw reply
* [PATCH 1/2] pinctrl: mvebu: update use "nand" function for "rb" pin
From: Gregory CLEMENT @ 2018-05-14 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504030638.31521-1-chris.packham@alliedtelesis.co.nz>
Hi Chris,
On ven., mai 04 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
> The Armada 98dx3236 SoCs don't have a different MPP sel value for nand
> specific pins so "dev" was technically correct. But all the other Armada
> SoCs use "nand" in their dts and the pin is specific to the nand
> interface so use "nand" for the function name.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Thanks,
Gregory
> ---
> drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
> index b854f1ee5de5..28b199796fae 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
> @@ -431,7 +431,7 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
> MPP_MODE(19,
> MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
> MPP_VAR_FUNCTION(0x3, "uart1", "rxd", V_98DX3236_PLUS),
> - MPP_VAR_FUNCTION(0x4, "dev", "rb", V_98DX3236_PLUS)),
> + MPP_VAR_FUNCTION(0x4, "nand", "rb", V_98DX3236_PLUS)),
> MPP_MODE(20,
> MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
> MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
> --
> 2.17.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* [PATCH 2/2] ARM: dts: armada-xp-98dx: Add NAND pinctrl information
From: Gregory CLEMENT @ 2018-05-14 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504030638.31521-2-chris.packham@alliedtelesis.co.nz>
Hi Chris,
On ven., mai 04 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
> Add pin control information for the NAND interface on the Armada
> 98DX3236 and variants.
>
Applied on mvebu/dt
Thanks,
Gregory
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> index 9a589abd0379..099dc2520082 100644
> --- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> @@ -312,6 +312,19 @@
> &pinctrl {
> compatible = "marvell,98dx3236-pinctrl";
>
> + nand_pins: nand-pins {
> + marvell,pins = "mpp20", "mpp21", "mpp22",
> + "mpp23", "mpp24", "mpp25",
> + "mpp26", "mpp27", "mpp28",
> + "mpp29", "mpp30";
> + marvell,function = "dev";
> + };
> +
> + nand_rb: nand-rb {
> + marvell,pins = "mpp19";
> + marvell,function = "nand";
> + };
> +
> spi0_pins: spi0-pins {
> marvell,pins = "mpp0", "mpp1",
> "mpp2", "mpp3";
> --
> 2.17.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.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