* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Guenter Roeck @ 2017-01-11 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a45ed205-7c1b-a298-50c0-fc8b80a846c5@sigmadesigns.com>
On 01/11/2017 04:31 AM, Marc Gonzalez wrote:
> On 11/01/2017 11:52, Guenter Roeck wrote:
>
>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>>
>>>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>>>> err = clk_prepare_enable(dev->clk);
>>>> if (err)
>>>> return err;
>>>> + err = devm_add_action_or_reset(&pdev->dev,
>>>> + (void(*)(void *))clk_disable_unprepare,
>>>> + dev->clk);
>>>> + if (err)
>>>> + return err;
>>>
>>> Hello Guenter,
>>>
>>> I would rather avoid the function pointer cast.
>>> How about defining an auxiliary function for the cleanup action?
>>>
>>> clk_disable_unprepare() is static inline, so gcc will have to
>>> define an auxiliary function either way. What do you think?
>>
>> Not really. It would just make it more complicated to replace the
>> call with devm_clk_prepare_enable(), should it ever find its way
>> into the light of day.
>
> More complicated, because the cleanup function will have to be deleted later?
> The compiler will warn if someone forgets to do that.
>
> In my opinion, it's not a good idea to rely on the fact that casting
> void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected
> on most platforms. (It has undefined behavior, strictly speaking.)
>
I do hear that you object to this code.
However, I must admit that you completely lost me here. It is a cast from
one function pointer to another, passed as argument to another function,
with a secondary cast of its argument from a typed pointer to a void pointer.
I don't think C permits for "undefined behavior, strictly speaking".
Besides, that same mechanism is already used elsewhere, which is how I
got the idea. Are you claiming that there are situations where it won't
work ?
> Do you really dislike the portable solution I suggested? :-(
>
It is not more portable than the above. It is more expensive and adds more
code.
Thanks,
Guenter
^ permalink raw reply
* [PATCH] firmware: ti_sci: fix strncat length check
From: Nishanth Menon @ 2017-01-11 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111133808.3757036-1-arnd@arndb.de>
On Wed, Jan 11, 2017 at 7:37 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-7 notices that the length we pass to strncat is wrong:
>
> drivers/firmware/ti_sci.c: In function 'ti_sci_probe':
> drivers/firmware/ti_sci.c:204:32: error: specified bound 50 equals the size of the destination [-Werror=stringop-overflow=]
>
> Instead of the total length, we must pass the length of the
> remaining space here.
>
> Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/firmware/ti_sci.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index 874ff32db366..00cfed3c3e1a 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -202,7 +202,8 @@ static int ti_sci_debugfs_create(struct platform_device *pdev,
> info->debug_buffer[info->debug_region_size] = 0;
>
> info->d = debugfs_create_file(strncat(debug_name, dev_name(dev),
> - sizeof(debug_name)),
> + sizeof(debug_name) -
> + sizeof("ti_sci_debug@")),
> 0444, NULL, info, &ti_sci_debug_fops);
> if (IS_ERR(info->d))
> return PTR_ERR(info->d);
Aargh.. thanks.... Santosh: if you could pick this up.. using
strlen(debug_name) might be an overkill here.
Acked-by: Nishanth Menon <nm@ti.com>
---
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 5/8] efi: Get the secure boot status [ver #6]
From: Matt Fleming @ 2017-01-11 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148120024570.5854.10638278395097394138.stgit@warthog.procyon.org.uk>
On Thu, 08 Dec, at 12:30:45PM, David Howells wrote:
> Get the firmware's secure-boot status in the kernel boot wrapper and stash
> it somewhere that the main kernel image can find.
>
> The efi_get_secureboot() function is extracted from the arm stub and (a)
> generalised so that it can be called from x86 and (b) made to use
> efi_call_runtime() so that it can be run in mixed-mode.
>
> Suggested-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> Documentation/x86/zero-page.txt | 2 +
> arch/x86/boot/compressed/eboot.c | 2 +
> arch/x86/boot/compressed/head_32.S | 1
> arch/x86/boot/compressed/head_64.S | 1
> arch/x86/include/asm/bootparam_utils.h | 5 +-
> arch/x86/include/uapi/asm/bootparam.h | 3 +
> arch/x86/kernel/asm-offsets.c | 1
> drivers/firmware/efi/libstub/Makefile | 2 -
> drivers/firmware/efi/libstub/arm-stub.c | 63 +++--------------------------
> drivers/firmware/efi/libstub/secureboot.c | 63 +++++++++++++++++++++++++++++
> include/linux/efi.h | 8 ++++
> 11 files changed, 90 insertions(+), 61 deletions(-)
> create mode 100644 drivers/firmware/efi/libstub/secureboot.c
[...]
> diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
> index d85b9625e836..c635f7e32f5c 100644
> --- a/arch/x86/boot/compressed/head_32.S
> +++ b/arch/x86/boot/compressed/head_32.S
> @@ -61,6 +61,7 @@
>
> __HEAD
> ENTRY(startup_32)
> + movb $0, BP_secure_boot(%esi)
> #ifdef CONFIG_EFI_STUB
> jmp preferred_addr
>
> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
> index beab8322f72a..ccd2c7461b7f 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -244,6 +244,7 @@ ENTRY(startup_64)
> * that maps our entire kernel(text+data+bss+brk), zero page
> * and command line.
> */
> + movb $0, BP_secure_boot(%rsi)
> #ifdef CONFIG_EFI_STUB
> /*
> * The entry point for the PE/COFF executable is efi_pe_entry, so
Is clearing ::secure_boot really necessary? Any code path that goes
via efi_main() will set it correctly and all other code paths should
get it cleared in sanitize_boot_params(), no?
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index c7904556d7a8..92e23f03045e 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1477,6 +1477,14 @@ efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
> bool efi_runtime_disabled(void);
> extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
>
> +enum efi_secureboot_mode {
> + efi_secureboot_mode_unset,
> + efi_secureboot_mode_unknown,
> + efi_secureboot_mode_disabled,
> + efi_secureboot_mode_enabled,
> +};
> +enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table);
> +
> /*
> * Arch code can implement the following three template macros, avoiding
> * reptition for the void/non-void return cases of {__,}efi_call_virt():
>
What's the distinction between the unset and unknown enums?
^ permalink raw reply
* [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Linus Walleij @ 2017-01-11 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB5304992095753B761E66A9A87640@AM3PR04MB530.eurprd04.prod.outlook.com>
On Mon, Jan 9, 2017 at 3:32 AM, Jacky Bai <ping.bai@nxp.com> wrote:
> I have look into the above commit on using generic binding. But I think the generic pinconf
> is not very easy to add in imx pinctrl Driver. imx pinctrl use a different way to parse the pin configure.
OK atleast I need an indication from one of the i.MX maintainers how they
want to proceed.
> Each fsl,pin entry looks like <PIN_FUNC_ID CONFIG> in dts, the CONFIG is the pad setting value like
> pull-up, open-drain, drive strength etc. The above config bit definition is specific to each SOC in the PAD CTL register.
>
> If we want set the pin config to enable hysteresis, 47KOhm Pull Up, 50Mhz speed, 80Ohm driver strength
> and Fast Slew Rate, then the CONFIG value should be 0x17059( ORs corresponding bit definition).
Hysteresis is an input property and does not make sense on something
that need drive
strength and slew rate configuration which are output properties.
(I guess you mean 80mA drive strength.)
Actually such oxymoronic settings is a good reason to migrate to
generic bindings
because when you describe stuff with generic strings you see better
what is going
on, and we can add sanity checks to cases like this in the generic code where it
would indeed be valid to ask why this combination of settings is being made.
> This value will be set in
> PAD CTL register to config the corresponding pin.
Yes? That is common. It looks like that in DT:
{
input-schmitt-enable;
bias-pull-up = <47000>;
slew-rate = <50000000>;
drive-strength = <80000>;
};
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei.Pistirica at microchip.com @ 2017-01-11 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103111447.GA26488@localhost.localdomain>
> On Tue, Jan 03, 2017 at 10:47:56AM +0000, Rafal Ozieblo wrote:
> > We could use only descriptor approach but there are many Atmel's cores
> on the market which support only event registers.
>
> As I said in my other reply in this thread, the Atmel cores cannot possibly be
> made to work correctly.
>
> Sad, but true.
In conscience, I will make a patch containing only the common code (just to benefit from this effort) and then Rafal can add the driver for the GXL version on top of it.
Everybody agrees with this?
Best regards,
Andrei
>
> Thanks,
> Richard
^ permalink raw reply
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-11 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks5JP14SzprzE90-ST8b3URJECgpJ=dxw5XKvaxYEF3UCw@mail.gmail.com>
On 11/01/17 13:17, Benjamin Gaignard wrote:
> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>> Hi,
>>
>> It seem that addition of cache support for M-class cpus uncovered
>> latent bug in DMA usage. NOMMU memory model has been treated as being
>> always consistent; however, for R/M classes of cpu memory can be
>> covered by MPU which in turn might configure RAM as Normal
>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>> friends, since data can stuck in caches now or be buffered.
>>
>> This patch set is trying to address the issue by providing region of
>> memory suitable for consistent DMA operations. It is supposed that
>> such region is marked by MPU as non-cacheable. Robin suggested to
>> advertise such memory as reserved shared-dma-pool, rather then using
>> homebrew command line option, and extend dma-coherent to provide
>> default DMA area in the similar way as it is done for CMA (PATCH
>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>> framework, and it is seems that it might be reused by other
>> architectures like c6x and blackfin.
>>
>> Dedicated DMA region is required for cases other than:
>> - MMU/MPU is off
>> - cpu is v7m w/o cache support
>> - device is coherent
>>
>> In case one of the above conditions is true dma operations are forced
>> to be coherent and wired with dma_noop_ops.
>>
>> To make life easier NOMMU dma operations are kept in separate
>> compilation unit.
>>
>> Since the issue was reported in the same time as Benjamin sent his
>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>> series (PATCH 1/5 and PATCH 3/5).
>>
>> Thanks!
>
> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
> it doesn't work with my drm/kms driver.
I guess the same is for fbmem, but would be better to have confirmation since
amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
> I haven't any errors but nothing is displayed unlike what I have when
> using current dma-mapping
> code.
> I guess the issue is coming from dma-noop where __get_free_pages() is
> used instead of alloc_pages()
> in dma-mapping.
Unless I've missed something bellow is a call stack for both
#1
__alloc_simple_buffer
__dma_alloc_buffer
alloc_pages
split_page
__dma_clear_buffer
memset
page_address
#2
__get_free_pages
alloc_pages
page_address
So the difference is that nommu case in dma-mapping.c memzeros memory, handles
DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
Is something from above critical for your driver?
>
> Since my hardware doesn't have cache or MPU (and so use dma-noop) I
> haven't reserved specific memory region.
> Buffer addresses and vma parameters look correct... What could I have
> miss here ?
No ideas, sorry...
Cheers
Vladimir
>
> Benjamin
>
>>
>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>
>> Vladimir Murzin (5):
>> dma: Add simple dma_noop_mmap
>> drivers: dma-coherent: Introduce default DMA pool
>> ARM: NOMMU: Introduce dma operations for noMMU
>> ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>> ARM: dma-mapping: Remove traces of NOMMU code
>>
>> .../bindings/reserved-memory/reserved-memory.txt | 3 +
>> arch/arm/include/asm/dma-mapping.h | 3 +-
>> arch/arm/mm/Kconfig | 2 +-
>> arch/arm/mm/Makefile | 5 +-
>> arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++
>> arch/arm/mm/dma-mapping.c | 26 +--
>> drivers/base/dma-coherent.c | 59 ++++-
>> lib/dma-noop.c | 21 ++
>> 8 files changed, 335 insertions(+), 36 deletions(-)
>> create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>
>> --
>> 2.0.0
>>
>
>
>
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Uwe Kleine-König @ 2017-01-11 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a45ed205-7c1b-a298-50c0-fc8b80a846c5@sigmadesigns.com>
On Wed, Jan 11, 2017 at 01:31:47PM +0100, Marc Gonzalez wrote:
> On 11/01/2017 11:52, Guenter Roeck wrote:
>
> > On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
> >
> >>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
> >>> err = clk_prepare_enable(dev->clk);
> >>> if (err)
> >>> return err;
> >>> + err = devm_add_action_or_reset(&pdev->dev,
> >>> + (void(*)(void *))clk_disable_unprepare,
> >>> + dev->clk);
> >>> + if (err)
> >>> + return err;
This looks wrong. There is no clk_unprepare_disable when
devm_add_action_or_reset fails.
> >>
> >> Hello Guenter,
> >>
> >> I would rather avoid the function pointer cast.
> >> How about defining an auxiliary function for the cleanup action?
> >>
> >> clk_disable_unprepare() is static inline, so gcc will have to
> >> define an auxiliary function either way. What do you think?
> >
> > Not really. It would just make it more complicated to replace the
> > call with devm_clk_prepare_enable(), should it ever find its way
> > into the light of day.
>
> More complicated, because the cleanup function will have to be deleted later?
> The compiler will warn if someone forgets to do that.
>
> In my opinion, it's not a good idea to rely on the fact that casting
> void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected
> on most platforms. (It has undefined behavior, strictly speaking.)
I would expect it to work on all (Linux) platforms. Anyhow, I wonder if
there couldn't be found a better solution.
If in the end it looks like the following that would be good I think:
clk = devm_clk_get(...);
if (IS_ERR(clk))
...
ret = devm_clk_prepare_enable(clk)
if (ret)
return ret;
...
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: Linus Walleij @ 2017-01-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109111630.pcsjmc5l4v7vi2rm@lukather>
On Mon, Jan 9, 2017 at 12:16 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Jan 06, 2017 at 01:17:21AM +0000, Andr? Przywara wrote:
>> > On Wed, Jan 04, 2017 at 02:16:23AM +0000, Andr? Przywara wrote:
>> >> So can I ask that we start taking this seriously and stop doing things
>> >> which prevent Allwinner boards from being supported properly?
>> >> Which would first involve dropping this very patch?
>> >
>> > The driver still supports the old binding.
>>
>> Yes, a _current_ version of the driver supports both bindings, but older
>> versions *require* the older binding and bail out if various
>> allwinner,xxx properties are missing - as in those proposed new DTs:
>>
>> 4.9 kernel with sunxi/for-next .dtb:
>> sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
>> node uart0
>> sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
>> node mmc0
>> sunxi-mmc: probe of 1c0f000.mmc failed with error -22
>
> This is seriously getting out of control. We already come to great
> length (and sometimes a painful amount of hacks) to satisfy a few
> individuals with a theorical interest in backward compatibility (and
> apparently, we're even the only one doing so, even more platforms
> choosing to not support that as we speak), there's seriously no reason
> to support forward compatibility as well. This has *never* been a
> thing, never has been documented nor advertised, I don't know why it
> should be one more thing to carry on our shoulders.
I agree.
We have too much standardization burden to maintain already as it is.
And AFAICT the Allwinner support is a hacker/community/enthusiast
effort without vendor backing.
We should be aware that the strong push toward DT standardization
was due to mess in the vendor trees, and as for the ambition to ship
DTBs with products, that is for people producing products to do,
not for the community. Community support can very well use attached
DTB files on the kernel from my point of view, I don't see why
ArchLinuxARM and others should have to standardize and support
DTB file in flash images, very ambitious if they do but definately
not their problem.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 1/5] arm64: Define Falkor v1 CPU
From: Christopher Covington @ 2017-01-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Shanker Donthineni <shankerd@codeaurora.org>
Define the MIDR implementer and part number field values for the Qualcomm
Datacenter Technologies Falkor processor version 1 in the usual manner.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68dd..ee60561 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -71,6 +71,7 @@
#define ARM_CPU_IMP_APM 0x50
#define ARM_CPU_IMP_CAVIUM 0x43
#define ARM_CPU_IMP_BRCM 0x42
+#define ARM_CPU_IMP_QCOM 0x51
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
@@ -84,10 +85,13 @@
#define BRCM_CPU_PART_VULCAN 0x516
+#define QCOM_CPU_PART_FALKOR_V1 0x800
+
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
#ifndef __ASSEMBLY__
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2017-01-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111144118.17062-1-cov@codeaurora.org>
From: Shanker Donthineni <shankerd@codeaurora.org>
On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
separately using a reserved ASID will ensure that there are no TLB entries
with incorrect ASID after changing the the ASID.
Pseudo code:
write TTBRx_EL1[ASID] to a reserved value
ISB
write TTBRx_EL1[BADDR] to a desired value
ISB
write TTBRx_EL1[ASID] to a desired value
ISB
EL2 and EL3 code changing the EL1&0 ASID is not subject to this erratum
because hardware is prohibited from performing translations from an
out-of-context translation regime.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
Documentation/arm64/silicon-errata.txt | 43 +++++++++++++++++-----------------
arch/arm64/Kconfig | 11 +++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/mmu_context.h | 8 ++++++-
arch/arm64/kernel/cpu_errata.c | 7 ++++++
arch/arm64/mm/context.c | 10 ++++++++
arch/arm64/mm/proc.S | 13 ++++++++++
7 files changed, 72 insertions(+), 23 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11..7151aed 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -42,24 +42,25 @@ file acts as a registry of software workarounds in the Linux Kernel and
will be updated when new workarounds are committed and backported to
stable kernels.
-| Implementor | Component | Erratum ID | Kconfig |
-+----------------+-----------------+-----------------+-------------------------+
-| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
-| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
-| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
-| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
-| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
-| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
-| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
-| ARM | Cortex-A57 | #852523 | N/A |
-| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
-| ARM | Cortex-A72 | #853709 | N/A |
-| ARM | MMU-500 | #841119,#826419 | N/A |
-| | | | |
-| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
-| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
-| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
-| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
-| Cavium | ThunderX SMMUv2 | #27704 | N/A |
-| | | | |
-| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Implementor | Component | Erratum ID | Kconfig |
++---------------+-----------------+-----------------+--------------------------+
+| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
+| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
+| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
+| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
+| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
+| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
+| ARM | Cortex-A57 | #852523 | N/A |
+| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
+| ARM | Cortex-A72 | #853709 | N/A |
+| ARM | MMU-500 | #841119,#826419 | N/A |
+| | | | |
+| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
+| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
+| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
+| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+| | | | |
+| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..2a80ac9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -479,6 +479,17 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_1003
+ bool "Falkor E1003: Incorrect translation due to ASID change"
+ default y
+ help
+ An incorrect translation TLBI entry may be created while changing the
+ ASID and translation table address together for TTBR0_EL1. The
+ workaround for this issue is to use a reserved ASID in
+ cpu_do_switch_mm() before switching to the target ASID.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 4174f09..5aaf7ee 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -35,7 +35,8 @@
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
#define ARM64_HAS_NO_FPSIMD 16
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 17
-#define ARM64_NCAPS 17
+#define ARM64_NCAPS 18
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 0363fe8..9632b05 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -19,6 +19,10 @@
#ifndef __ASM_MMU_CONTEXT_H
#define __ASM_MMU_CONTEXT_H
+#define FALKOR_RESERVED_ASID 1
+
+#ifndef __ASSEMBLY__
+
#include <linux/compiler.h>
#include <linux/sched.h>
@@ -220,4 +224,6 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
void verify_cpu_asid_bits(void);
-#endif
+#endif /* !__ASSEMBLY__ */
+
+#endif /* !__ASM_MMU_CONTEXT_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917..787b542 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -130,6 +130,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.def_scope = SCOPE_LOCAL_CPU,
.enable = cpu_enable_trap_ctr_access,
},
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+ {
+ .desc = "Qualcomm Falkor erratum 1003",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 4c63cb1..5a0a82a 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -87,6 +87,11 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
+ /* Reserve ASID for Falkor erratum 1003 */
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(FALKOR_RESERVED_ASID, asid_map);
+
/*
* Ensure the generation bump is observed before we xchg the
* active_asids.
@@ -244,6 +249,11 @@ static int asids_init(void)
panic("Failed to allocate bitmap for %lu ASIDs\n",
NUM_USER_ASIDS);
+ /* Reserve ASID for Falkor erratum 1003 */
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(FALKOR_RESERVED_ASID, asid_map);
+
pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
return 0;
}
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 32682be..9ee46df 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -23,6 +23,7 @@
#include <asm/assembler.h>
#include <asm/asm-offsets.h>
#include <asm/hwcap.h>
+#include <asm/mmu_context.h>
#include <asm/pgtable.h>
#include <asm/pgtable-hwdef.h>
#include <asm/cpufeature.h>
@@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
ENTRY(cpu_do_switch_mm)
mmid x1, x1 // get mm->context.id
bfi x0, x1, #48, #16 // set the ASID
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
+ mrs x2, ttbr0_el1
+ mov x3, #FALKOR_RESERVED_ASID
+ bfi x2, x3, #48, #16 // reserved ASID + old BADDR
+ msr ttbr0_el1, x2
+ isb
+ bfi x2, x0, #0, #48 // reserved ASID + new BADDR
+ msr ttbr0_el1, x2
+ isb
+alternative_else_nop_endif
+#endif
msr ttbr0_el1, x0 // set TTBR0
isb
post_ttbr0_update_workaround
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v3 3/5] arm64: Create and use __tlbi_dsb() macros
From: Christopher Covington @ 2017-01-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111144118.17062-1-cov@codeaurora.org>
This refactoring will allow an errata workaround that repeats tlbi dsb
sequences to only change one location. This is not intended to change the
generated assembly and comparison of before and after preprocessor output
of arch/arm64/mm/mmu.c and vmlinux objdump shows no functional changes.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/include/asm/tlbflush.h | 104 +++++++++++++++++++++++++-------------
1 file changed, 69 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index deab523..f28813c 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -25,22 +25,69 @@
#include <asm/cputype.h>
/*
- * Raw TLBI operations.
+ * Raw TLBI, DSB operations
*
- * Where necessary, use the __tlbi() macro to avoid asm()
- * boilerplate. Drivers and most kernel code should use the TLB
- * management routines in preference to the macro below.
+ * Where necessary, use __tlbi_*dsb() macros to avoid asm() boilerplate.
+ * Drivers and most kernel code should use the TLB management routines in
+ * preference to the macros below.
*
- * The macro can be used as __tlbi(op) or __tlbi(op, arg), depending
- * on whether a particular TLBI operation takes an argument or
- * not. The macros handles invoking the asm with or without the
- * register argument as appropriate.
+ * The __tlbi_dsb() macro handles invoking the asm without any register
+ * argument, with a single register argument, and with start (included)
+ * and end (excluded) range of register arguments. For example:
+ *
+ * __tlbi_dsb(op, attr)
+ *
+ * tlbi op
+ * dsb attr
+ *
+ * __tlbi_dsb(op, attr, addr)
+ *
+ * mov %[addr], =addr
+ * tlbi op, %[addr]
+ * dsb attr
+ *
+ * __tlbi_range_dsb(op, attr, start, end)
+ *
+ * mov %[arg], =start
+ * mov %[end], =end
+ * for:
+ * tlbi op, %[addr]
+ * add %[addr], %[addr], #(1 << (PAGE_SHIFT - 12))
+ * cmp %[addr], %[end]
+ * b.ne for
+ * dsb attr
*/
-#define __TLBI_0(op, arg) asm ("tlbi " #op)
-#define __TLBI_1(op, arg) asm ("tlbi " #op ", %0" : : "r" (arg))
-#define __TLBI_N(op, arg, n, ...) __TLBI_##n(op, arg)
-#define __tlbi(op, ...) __TLBI_N(op, ##__VA_ARGS__, 1, 0)
+#define __TLBI_FOR_0(ig0, ig1, ig2)
+#define __TLBI_INSTR_0(op, ig1, ig2) "tlbi " #op
+#define __TLBI_IO_0(ig0, ig1, ig2) : :
+
+#define __TLBI_FOR_1(ig0, ig1, ig2)
+#define __TLBI_INSTR_1(op, ig0, ig1) "tlbi " #op ", %0"
+#define __TLBI_IO_1(ig0, arg, ig1) : : "r" (arg)
+
+#define __TLBI_FOR_2(ig0, start, ig1) unsigned long addr; \
+ for (addr = start; addr < end; \
+ addr += 1 << (PAGE_SHIFT - 12))
+#define __TLBI_INSTR_2(op, ig0, ig1) "tlbi " #op ", %0"
+#define __TLBI_IO_2(ig0, ig1, ig2) : : "r" (addr)
+
+#define __TLBI_FOR_N(op, a1, a2, n, ...) __TLBI_FOR_##n(op, a1, a2)
+#define __TLBI_INSTR_N(op, a1, a2, n, ...) __TLBI_INSTR_##n(op, a1, a2)
+#define __TLBI_IO_N(op, a1, a2, n, ...) __TLBI_IO_##n(op, a1, a2)
+
+#define __TLBI_FOR(op, ...) __TLBI_FOR_N(op, ##__VA_ARGS__, 2, 1, 0)
+#define __TLBI_INSTR(op, ...) __TLBI_INSTR_N(op, ##__VA_ARGS__, 2, 1, 0)
+#define __TLBI_IO(op, ...) __TLBI_IO_N(op, ##__VA_ARGS__, 2, 1, 0)
+
+#define __tlbi_asm_dsb(as, op, attr, ...) do { \
+ __TLBI_FOR(op, ##__VA_ARGS__) \
+ asm (__TLBI_INSTR(op, ##__VA_ARGS__) \
+ __TLBI_IO(op, ##__VA_ARGS__)); \
+ asm volatile ( as "\ndsb " #attr "\n" \
+ : : : "memory"); } while (0)
+
+#define __tlbi_dsb(...) __tlbi_asm_dsb("", ##__VA_ARGS__)
/*
* TLB Management
@@ -84,16 +131,14 @@
static inline void local_flush_tlb_all(void)
{
dsb(nshst);
- __tlbi(vmalle1);
- dsb(nsh);
+ __tlbi_dsb(vmalle1, nsh);
isb();
}
static inline void flush_tlb_all(void)
{
dsb(ishst);
- __tlbi(vmalle1is);
- dsb(ish);
+ __tlbi_dsb(vmalle1is, ish);
isb();
}
@@ -102,8 +147,7 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
unsigned long asid = ASID(mm) << 48;
dsb(ishst);
- __tlbi(aside1is, asid);
- dsb(ish);
+ __tlbi_dsb(aside1is, ish, asid);
}
static inline void flush_tlb_page(struct vm_area_struct *vma,
@@ -112,8 +156,7 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long addr = uaddr >> 12 | (ASID(vma->vm_mm) << 48);
dsb(ishst);
- __tlbi(vale1is, addr);
- dsb(ish);
+ __tlbi_dsb(vale1is, ish, addr);
}
/*
@@ -127,7 +170,6 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
bool last_level)
{
unsigned long asid = ASID(vma->vm_mm) << 48;
- unsigned long addr;
if ((end - start) > MAX_TLB_RANGE) {
flush_tlb_mm(vma->vm_mm);
@@ -138,13 +180,10 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
end = asid | (end >> 12);
dsb(ishst);
- for (addr = start; addr < end; addr += 1 << (PAGE_SHIFT - 12)) {
- if (last_level)
- __tlbi(vale1is, addr);
- else
- __tlbi(vae1is, addr);
- }
- dsb(ish);
+ if (last_level)
+ __tlbi_dsb(vale1is, ish, start, end);
+ else
+ __tlbi_dsb(vae1is, ish, start, end);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
@@ -155,8 +194,6 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end)
{
- unsigned long addr;
-
if ((end - start) > MAX_TLB_RANGE) {
flush_tlb_all();
return;
@@ -166,9 +203,7 @@ static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end
end >>= 12;
dsb(ishst);
- for (addr = start; addr < end; addr += 1 << (PAGE_SHIFT - 12))
- __tlbi(vaae1is, addr);
- dsb(ish);
+ __tlbi_dsb(vaae1is, ish, start, end);
isb();
}
@@ -181,8 +216,7 @@ static inline void __flush_tlb_pgtable(struct mm_struct *mm,
{
unsigned long addr = uaddr >> 12 | (ASID(mm) << 48);
- __tlbi(vae1is, addr);
- dsb(ish);
+ __tlbi_dsb(vae1is, ish, addr);
}
#endif
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v3 4/5] arm64: Use __tlbi_dsb() macros in KVM code
From: Christopher Covington @ 2017-01-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111144118.17062-1-cov@codeaurora.org>
Refactor the KVM code to use the newly introduced __tlbi_dsb macros, which
will allow an errata workaround that repeats tlbi dsb sequences to only
change one location. This is not intended to change the generated assembly
and comparing before and after vmlinux objdump shows no functional changes.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/kvm/hyp/tlb.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 88e2f2b..9669e4b 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -16,6 +16,7 @@
*/
#include <asm/kvm_hyp.h>
+#include <asm/tlbflush.h>
void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
{
@@ -30,19 +31,15 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* We could do so much better if we had the VA as well.
* Instead, we invalidate Stage-2 for this IPA, and the
* whole of Stage-1. Weep...
+ *
+ * We have to ensure completion of the invalidation at Stage-2 with a
+ * DSB, since a table walk on another CPU could refill a TLB with a
+ * complete (S1 + S2) walk based on the old Stage-2 mapping if the
+ * Stage-1 invalidation happened first.
*/
ipa >>= 12;
- asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
-
- /*
- * We have to ensure completion of the invalidation at Stage-2,
- * since a table walk on another CPU could refill a TLB with a
- * complete (S1 + S2) walk based on the old Stage-2 mapping if
- * the Stage-1 invalidation happened first.
- */
- dsb(ish);
- asm volatile("tlbi vmalle1is" : : );
- dsb(ish);
+ __tlbi_dsb(ipas2e1is, ish, ipa);
+ __tlbi_dsb(vmalle1is, ish);
isb();
write_sysreg(0, vttbr_el2);
@@ -57,8 +54,7 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(kvm->arch.vttbr, vttbr_el2);
isb();
- asm volatile("tlbi vmalls12e1is" : : );
- dsb(ish);
+ __tlbi_dsb(vmalls12e1is, ish);
isb();
write_sysreg(0, vttbr_el2);
@@ -72,8 +68,7 @@ void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
write_sysreg(kvm->arch.vttbr, vttbr_el2);
isb();
- asm volatile("tlbi vmalle1" : : );
- dsb(nsh);
+ __tlbi_dsb(vmalle1, nsh);
isb();
write_sysreg(0, vttbr_el2);
@@ -82,7 +77,5 @@ void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
- asm volatile("tlbi alle1is \n"
- "ic ialluis ": : );
- dsb(ish);
+ __tlbi_asm_dsb("ic ialluis", alle1is, ish);
}
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v3 5/5] arm64: Work around Falkor erratum 1009
From: Christopher Covington @ 2017-01-11 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111144118.17062-1-cov@codeaurora.org>
During a TLB invalidate sequence targeting the inner shareable
domain, Falkor may prematurely complete the DSB before all loads
and stores using the old translation are observed; instruction
fetches are not subject to the conditions of this erratum.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 10 ++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/tlbflush.h | 5 ++++-
arch/arm64/kernel/cpu_errata.c | 7 +++++++
5 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 7151aed..98bef2a 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -64,3 +64,4 @@ stable kernels.
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+| Qualcomm | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2a80ac9..d13e903 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -490,6 +490,16 @@ config QCOM_FALKOR_ERRATUM_1003
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_1009
+ bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
+ default y
+ help
+ Falkor CPU may prematurely complete a DSB following a TLBI xxIS
+ invalidate maintenance operations. Repeat the TLBI operation one
+ more time to fix the issue.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 5aaf7ee..55bcd02 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -36,7 +36,8 @@
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
#define ARM64_HAS_NO_FPSIMD 16
#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 17
+#define ARM64_WORKAROUND_REPEAT_TLBI 18
-#define ARM64_NCAPS 18
+#define ARM64_NCAPS 19
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index f28813c..7313cd3 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -85,7 +85,10 @@
asm (__TLBI_INSTR(op, ##__VA_ARGS__) \
__TLBI_IO(op, ##__VA_ARGS__)); \
asm volatile ( as "\ndsb " #attr "\n" \
- : : : "memory"); } while (0)
+ ALTERNATIVE("nop" "\nnop" "\n", \
+ __TLBI_INSTR(op, ##__VA_ARGS__) "\ndsb " #attr "\n", \
+ ARM64_WORKAROUND_REPEAT_TLBI) \
+ __TLBI_IO(op, ##__VA_ARGS__) : "memory"); } while (0)
#define __tlbi_dsb(...) __tlbi_asm_dsb("", ##__VA_ARGS__)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 787b542..e644364 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -137,6 +137,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
},
#endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1009
+ {
+ .desc = "Qualcomm Falkor erratum 1009",
+ .capability = ARM64_WORKAROUND_REPEAT_TLBI,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Måns Rullgård @ 2017-01-11 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a61eb838-4167-3032-bde8-3a8845b780f8@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> On 01/11/2017 04:31 AM, Marc Gonzalez wrote:
>> On 11/01/2017 11:52, Guenter Roeck wrote:
>>
>>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>>>
>>>>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>>>>> err = clk_prepare_enable(dev->clk);
>>>>> if (err)
>>>>> return err;
>>>>> + err = devm_add_action_or_reset(&pdev->dev,
>>>>> + (void(*)(void *))clk_disable_unprepare,
>>>>> + dev->clk);
>>>>> + if (err)
>>>>> + return err;
>>>>
>>>> Hello Guenter,
>>>>
>>>> I would rather avoid the function pointer cast.
>>>> How about defining an auxiliary function for the cleanup action?
>>>>
>>>> clk_disable_unprepare() is static inline, so gcc will have to
>>>> define an auxiliary function either way. What do you think?
>>>
>>> Not really. It would just make it more complicated to replace the
>>> call with devm_clk_prepare_enable(), should it ever find its way
>>> into the light of day.
>>
>> More complicated, because the cleanup function will have to be deleted later?
>> The compiler will warn if someone forgets to do that.
>>
>> In my opinion, it's not a good idea to rely on the fact that casting
>> void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected
>> on most platforms. (It has undefined behavior, strictly speaking.)
>>
> I do hear that you object to this code.
>
> However, I must admit that you completely lost me here. It is a cast from
> one function pointer to another, passed as argument to another function,
> with a secondary cast of its argument from a typed pointer to a void pointer.
> I don't think C permits for "undefined behavior, strictly speaking".
> Besides, that same mechanism is already used elsewhere, which is how I
> got the idea. Are you claiming that there are situations where it won't
> work ?
A pointer to void is interchangeable with any other pointer type. That
doesn't necessarily imply that pointers to functions taking arguments of
different pointer types (as we have here) are always compatible. I'd
have to read the C standard carefully to see if there's any such
promise, and I have other things to do right now. I am, however, not
aware of any ABI (certainly none used by Linux) where it would pose a
problem.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Linus Walleij @ 2017-01-11 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106041517.9589-4-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
I am waiting for an ACK or comment from the maintainers on
this patch. Sebastian?
Yours,
Linus Walleij
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Catalin Marinas @ 2017-01-11 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110121423.GF19960@e104818-lin.cambridge.arm.com>
On Tue, Jan 10, 2017 at 12:14:23PM +0000, Catalin Marinas wrote:
> On Mon, Jan 09, 2017 at 07:06:19PM +0100, Bas van Tiel wrote:
> > > I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run
> > > fine, though I'll leave it longer/overnight (on a Juno board). With the
> > > 4K signal stack it was crashing shortly after start.
> >
> > I tried the STACKSIZE of 16384 for both the RPI3 and the PINEA64 board
> > and still see the same behaviour of crashing. Sometimes the process
> > is also blocked for a long time before it crashes.
> >
> > Setting the interval to 200 usec [5 Khz] will help to crash it faster.
> >
> > To further isolate the issue I will create a kernel module (based on a
> > hrtimer) that will sent a periodic signal to the registered process
> > and execute the same sighandler logic to check if the problem is still
> > there.
>
> I lowered the interval to 100us (it was 100ms in the original file) and
> I can indeed trigger segfault easily on Juno. But it doesn't fail in the
> same way every time, I sometimes get permission fault, other times bad
> frame.
With 100us interval, it segfaults on x86 fairly quickly as well, so I
don't think it's a kernel issue.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: avoid increasing DMA masks above what hardware supports
From: Robin Murphy @ 2017-01-11 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09cac197-9e57-5d3e-e742-f29c00051813@cogentembedded.com>
On 11/01/17 13:41, Nikita Yushchenko wrote:
>> Yes, I think that ought to work, although the __iommu_setup_dma_ops()
>> call will still want a real size reflecting the default mask
>
> I see iommu_dma_ops do not define set_dma_mask.
>
> So what if setup was done for size reflecting one mask and then driver
> changes mask? Will things still operate correctly?
We've overridden dma_set_mask() at the function level, so it should
always apply regardless. Besides, none of the arm64 ops implement
.set_dma_mask anyway, so we could possibly drop the references to it
altogether.
Conversely, I suppose we could just implement said callback for
swiotlb_dma_ops and iommu_dma_ops with the parent_dma_mask-checking
function and drop the HAVE_ARCH_DMA_SET_MASK override instead. I'm not
sure which approach is preferable - the latter seems arguably cleaner in
isolation, but would also be less consistent with how the coherent mask
has to be handled. Ho hum.
Robin.
^ permalink raw reply
* [PATCH] rtc: armada38x: hide maybe-uninitialized warning
From: Arnd Bergmann @ 2017-01-11 14:50 UTC (permalink / raw)
To: linux-arm-kernel
The function is too complicated for gcc to realize that this variable
does eventually get initialized, causing a harmless warning:
drivers/rtc/rtc-armada38x.c: In function 'read_rtc_register_wa':
drivers/rtc/rtc-armada38x.c:131:25: warning: 'index_max' may be used uninitialized in this function [-Wmaybe-uninitialized]
This adds an explicit initializion at the start of the function.
I generally try to avoid that, but it seems appropriate here,
as we start out with max=0 as well.
Fixes: 61cffa2438e3 ("rtc: armada38x: Follow the new recommendation for errata implementation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/rtc/rtc-armada38x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
index 6c9a2cbdc1a9..65e16965af7e 100644
--- a/drivers/rtc/rtc-armada38x.c
+++ b/drivers/rtc/rtc-armada38x.c
@@ -90,7 +90,7 @@ static void rtc_update_mbus_timing_params(struct armada38x_rtc *rtc)
static u32 read_rtc_register_wa(struct armada38x_rtc *rtc, u8 rtc_reg)
{
- int i, index_max, max = 0;
+ int i, index_max = 0, max = 0;
for (i = 0; i < SAMPLE_NR; i++) {
rtc->val_to_freq[i].value = readl(rtc->regs + rtc_reg);
--
2.9.0
^ permalink raw reply related
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Vladimir Zapolskiy @ 2017-01-11 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111143917.hedhyfu6m5dopag7@pengutronix.de>
Hello Uwe,
On 01/11/2017 04:39 PM, Uwe Kleine-K?nig wrote:
> On Wed, Jan 11, 2017 at 01:31:47PM +0100, Marc Gonzalez wrote:
>> On 11/01/2017 11:52, Guenter Roeck wrote:
>>
>>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>>>
>>>>> @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev)
>>>>> err = clk_prepare_enable(dev->clk);
>>>>> if (err)
>>>>> return err;
>>>>> + err = devm_add_action_or_reset(&pdev->dev,
>>>>> + (void(*)(void *))clk_disable_unprepare,
>>>>> + dev->clk);
>>>>> + if (err)
>>>>> + return err;
>
> This looks wrong. There is no clk_unprepare_disable when
> devm_add_action_or_reset fails.
actually there is a call to clk_disable_unprepare() on error path, you may
take a look at devm_add_action_or_reset() implementation.
Your comment is valid for devm_add_action() function though, but it's not
the case here.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]
From: Matt Fleming @ 2017-01-11 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148120026820.5854.13036556358308461345.stgit@warthog.procyon.org.uk>
On Thu, 08 Dec, at 12:31:08PM, David Howells wrote:
> From: Josh Boyer <jwboyer@fedoraproject.org>
>
> UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit
> that can be passed to efi_enabled() to find out whether secure boot is
> enabled.
>
> This will be used by the SysRq+x handler, registered by the x86 arch, to find
> out whether secure boot mode is enabled so that it can be disabled.
>
> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> arch/x86/kernel/setup.c | 15 +++++++++++++++
> include/linux/efi.h | 1 +
> 2 files changed, 16 insertions(+)
Before we add more efi.flags bits I'd like this series to include the
patch that makes use of EFI_SECURE_BOOT. Alternatively, you move this
last patch to a new series.
^ permalink raw reply
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Ard Biesheuvel @ 2017-01-11 14:54 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
modules and the core kernel may exceed 4 GB, putting symbols exported
by the core kernel out of the reach of the ordinary adrp/add instruction
pairs used to generate relative symbol references. So make the adr_l
macro emit a movz/movk sequence instead when executing in module context.
While at it, remove the pointless special case for the stack pointer.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/assembler.h | 36 +++++++++++++++-----
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 446f6c46d4b1..3a4301163e04 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -164,22 +164,25 @@ lr .req x30 // link register
/*
* Pseudo-ops for PC-relative adr/ldr/str <reg>, <symbol> where
- * <symbol> is within the range +/- 4 GB of the PC.
+ * <symbol> is within the range +/- 4 GB of the PC when running
+ * in core kernel context. In module context, a movz/movk sequence
+ * is used, since modules may be loaded far away from the kernel
+ * when KASLR is in effect.
*/
/*
* @dst: destination register (64 bit wide)
* @sym: name of the symbol
- * @tmp: optional scratch register to be used if <dst> == sp, which
- * is not allowed in an adrp instruction
*/
- .macro adr_l, dst, sym, tmp=
- .ifb \tmp
+ .macro adr_l, dst, sym
+#ifndef MODULE
adrp \dst, \sym
add \dst, \dst, :lo12:\sym
- .else
- adrp \tmp, \sym
- add \dst, \tmp, :lo12:\sym
- .endif
+#else
+ movz \dst, #:abs_g3:\sym
+ movk \dst, #:abs_g2_nc:\sym
+ movk \dst, #:abs_g1_nc:\sym
+ movk \dst, #:abs_g0_nc:\sym
+#endif
.endm
/*
@@ -190,6 +193,7 @@ lr .req x30 // link register
* the address
*/
.macro ldr_l, dst, sym, tmp=
+#ifndef MODULE
.ifb \tmp
adrp \dst, \sym
ldr \dst, [\dst, :lo12:\sym]
@@ -197,6 +201,15 @@ lr .req x30 // link register
adrp \tmp, \sym
ldr \dst, [\tmp, :lo12:\sym]
.endif
+#else
+ .ifb \tmp
+ adr_l \dst, \sym
+ ldr \dst, [\dst]
+ .else
+ adr_l \tmp, \sym
+ ldr \dst, [\tmp]
+ .endif
+#endif
.endm
/*
@@ -206,8 +219,13 @@ lr .req x30 // link register
* while <src> needs to be preserved.
*/
.macro str_l, src, sym, tmp
+#ifndef MODULE
adrp \tmp, \sym
str \src, [\tmp, :lo12:\sym]
+#else
+ adr_l \tmp, \sym
+ str \src, [\tmp]
+#endif
.endm
/*
--
2.7.4
^ permalink raw reply related
* [PATCH 0/8] efi: Pass secure boot mode to kernel [ver #6]
From: Matt Fleming @ 2017-01-11 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148120020832.5854.5448601415491330495.stgit@warthog.procyon.org.uk>
On Thu, 08 Dec, at 12:30:08PM, David Howells wrote:
>
> Here's a set of patches that can determine the secure boot state of the
> UEFI BIOS and pass that along to the main kernel image. This involves
> generalising ARM's efi_get_secureboot() function and making it mixed-mode
> safe.
This version looks OK to me apart from the couple of comments I made.
Ard, did you take a look? In particular some boot testing on ARM/arm64
would be useful. x86 boots fine in both regular and mixed mode but
I've only tested without Secure Boot enabled.
^ permalink raw reply
* [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: David Miller @ 2017-01-11 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cR5bt-0000O8-1T@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 10 Jan 2017 23:13:45 +0000
> When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
> fiber page is used for the SGMII host-side connection. The PHY driver
> notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
> for the link status, and ends up reading the MAC-side status instead of
> the outgoing (copper) link. This leads to incorrect results reported
> via ethtool.
>
> If the PHY is connected via SGMII to the host, ignore the fiber page.
> However, continue to allow the existing power management code to
> suspend and resume the fiber page.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied, thanks Russell.
^ permalink raw reply
* [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: David Miller @ 2017-01-11 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61950d83-cbe1-6e1b-4afc-bc471b386ff3@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 15:24:11 -0800
> Fixes: 6cfb3bcc0641 ("Marvell phy: check link status in case of fiber
> link.")
Thanks, I added this to Russell's commit message.
^ permalink raw reply
* [PATCH 0/8] efi: Pass secure boot mode to kernel [ver #6]
From: Ard Biesheuvel @ 2017-01-11 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111150150.GC29649@codeblueprint.co.uk>
On 11 January 2017 at 15:01, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Thu, 08 Dec, at 12:30:08PM, David Howells wrote:
>>
>> Here's a set of patches that can determine the secure boot state of the
>> UEFI BIOS and pass that along to the main kernel image. This involves
>> generalising ARM's efi_get_secureboot() function and making it mixed-mode
>> safe.
>
> This version looks OK to me apart from the couple of comments I made.
>
> Ard, did you take a look? In particular some boot testing on ARM/arm64
> would be useful. x86 boots fine in both regular and mixed mode but
> I've only tested without Secure Boot enabled.
I did take a look at these patches (and commented on them) as they
were coming in, but I haven't yet gone through them as thoroughly as I
should. I will test them on ARM/arm64 as well.
^ 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