* [GIT PULL] ARM: at91: drivers for 4.10
From: Arnd Bergmann @ 2016-11-25 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114184438.k5ysd6pgcadlo5vw@piout.net>
On Monday, November 14, 2016 7:44:38 PM CET Alexandre Belloni wrote:
> Drivers for 4.10:
>
> - few fixes for the memory drivers
> - minimal security module driver
> - support for the Secure SRAM
>
For reference, Olof pulled this into next/drivers on Nov 18.
Arnd
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Arnd Bergmann @ 2016-11-25 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110150930.GB19804@axis.com>
On Thursday, November 10, 2016 4:09:31 PM CET Jesper Nilsson wrote:
> Please pull the below signed tag for a trio of minor changes
> adding PCIe for the ARM ARTPEC SoC.
>
> Thanks!
>
> /Jesper
>
> The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
>
> Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git tags/artpec-for-4.10
>
> for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
>
> ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
>
> ----------------------------------------------------------------
> ARTPEC changes for 4.10
>
> ----------------------------------------------------------------
> Niklas Cassel (3):
> ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
> ARM: ARTPEC-6: add pcie related options
> ARM: dts: artpec: add pcie support
>
>
Hi Jesper and Niklas,
I just found the old pull request while going through my mail backlog.
A few things for you to remember for next time:
- please send pull requests "To: arm at kernel.org" so we know they
are destined for arm-soc
- please split up changes to the platform code from dts changes,
defconfig changes and driver changes. Each of them gets sent
to Linus in a separate arm-soc branch, so we have to pull them
in separately too
- For the signed tag, please put in a cleartext description of
the branch, just like you describe each commit in its changelog
text. The tag comment becomes the merge commit text.
- I've looked at the three patches individually and cherry-picked
the first into next/soc and the third into next/dt. The patch
"ARM: ARTPEC-6: add pcie related options" is no longer needed
after commit e13688f ("ARM: select PCI_DOMAINS config from
ARCH_MULTIPLATFORM"), so I dropped that.
Arnd
^ permalink raw reply
* [GIT PULL] arm64: dts: uniphier: UniPhier DT updates (64bit) for v4.10
From: Arnd Bergmann @ 2016-11-25 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNASgYKnhpRM4jj1oHagK=MvO71QnbnaSr=Gt+hkV+6vxXg@mail.gmail.com>
On Sunday, November 6, 2016 12:25:15 AM CET Masahiro Yamada wrote:
> UniPhier ARM64 SoC DT updates for v4.10
>
> - Switch CPU enable-method from spin-table to PSCI
> - Add OPP tables to support generic cpufreq driver
> - Misc fixes
>
>
I don't see an email from Olof about merging this one,
for reference I have verified that he put it into the next/dt64
branch on Nov 17.
Arnd
^ permalink raw reply
* [PATCH net-next 1/5] net: mvneta: Use cacheable memory to store the rx buffer virtual address
From: kbuild test robot @ 2016-11-25 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e6004f918d3fcde9ae71e7893d26b19086236a3.1480087510.git-series.gregory.clement@free-electrons.com>
Hi Gregory,
[auto build test ERROR on ]
url: https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/Support-Armada-37xx-SoC-ARMv8-64-bits-in-mvneta-driver/20161126-050621
base:
config: parisc-allmodconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
Note: the linux-review/Gregory-CLEMENT/Support-Armada-37xx-SoC-ARMv8-64-bits-in-mvneta-driver/20161126-050621 HEAD 5f44108a5c983ae4477f811485fdc4ee12294e72 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
vim +2745 drivers/net/ethernet/marvell/mvneta.c
2739 DMA_FROM_DEVICE);
2740 if (unlikely(dma_mapping_error(pp->dev->dev.parent, phys_addr))) {
2741 mvneta_frag_free(pp->frag_size, data);
2742 return -ENOMEM;
2743 }
2744
> 2745 phys_addr += pp->rx_offset_correction;
2746 rx_desc->buf_phys_addr = phys_addr;
2747 rx_desc->buf_cookie = (uintptr_t)data;
2748
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47218 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161126/8b9e6423/attachment-0001.gz>
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC DT updates for 4.10
From: Arnd Bergmann @ 2016-11-25 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <85ecb958-a6cb-bdd2-10db-873e1b894ad7@baylibre.com>
On Friday, November 4, 2016 11:26:30 AM CET Neil Armstrong wrote:
> - Add DTSI for Oxford Semiconductor OX820
> - Add DTS for Cloud Engines PogoPlug v3 board
> - Fix MAINTAINERS Oxnas entry for dts files
> from http://lkml.kernel.org/r/20161102141850.25164-1-narmstrong at baylibre.com
>
>
This one seemed to have gone missing after Olof asked for a respin
of the other oxnas branch. I've pulled it into next/dt now.
I'd probably have put the MAINTAINERS update into a different
branch (possibly even for v4.9), but it doesn't seem too important
since there was no change in the maintainers and it's unlikely
to cause conflicts.
Arnd
^ permalink raw reply
* [PATCH 1/2] drivers: psci: PSCI checker module
From: Arnd Bergmann @ 2016-11-25 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108175547.31146-1-lorenzo.pieralisi@arm.com>
On Tuesday, November 8, 2016 5:55:46 PM CET Lorenzo Pieralisi wrote:
> From: Kevin Brodsky <kevin.brodsky@arm.com>
>
> On arm and arm64, PSCI is one of the possible firmware interfaces
> used for power management. This includes both turning CPUs on and off,
> and suspending them (entering idle states).
>
> This patch adds a PSCI checker module that enables basic testing of
> PSCI operations during startup. There are two main tests: CPU
> hotplugging and suspending.
>
> In the hotplug tests, the hotplug API is used to turn off and on again
> all CPUs in the system, and then all CPUs in each cluster, checking
> the consistency of the return codes.
>
> In the suspend tests, a high-priority thread is created on each core
> and uses low-level cpuidle functionalities to enter suspend, in all
> the possible states and multiple times. This should allow a maximum
> number of CPUs to enter the same sleep state at the same or slightly
> different time.
>
> In essence, the suspend tests use a principle similar to that of the
> intel_powerclamp driver (drivers/thermal/intel_powerclamp.c), but the
> threads are only kept for the duration of the test (they are already
> gone when userspace is started) and it does not require to stop/start
> the tick.
>
> While in theory power management PSCI functions (CPU_{ON,OFF,SUSPEND})
> could be directly called, this proved too difficult as it would imply
> the duplication of all the logic used by the kernel to allow for a
> clean shutdown/bringup/suspend of the CPU (the deepest sleep states
> implying potentially the shutdown of the CPU).
>
> Note that this file cannot be compiled as a loadable module, since it
> uses a number of non-exported identifiers (essentially for
> PSCI-specific checks and direct use of cpuidle) and relies on the
> absence of userspace to avoid races when calling hotplug and cpuidle
> functions.
>
> For now at least, CONFIG_PSCI_CHECKER is mutually exclusive with
> CONFIG_TORTURE_TEST, because torture tests may also use hotplug and
> cause false positives in the hotplug tests.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> [torture test config]
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> [lpieralisi: added cpuidle locking, reworded commit log/kconfig entry]
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Applied both patches to the next/drivers tree in arm-soc now, sorry
for the delay,
Arnd
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Arnd Bergmann @ 2016-11-25 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512445.DtnT51NQqg@amdc3058>
On Monday, October 31, 2016 7:24:46 PM CET Bartlomiej Zolnierkiewicz wrote:
> On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote:
> > On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> > > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > I'd be fine with just getting a pull request with all the patches that
> > > > > had no negative feedback and that were not already applied (if any).
> > > >
> > > > Here it is (sorry for taking so long).
> > >
> > > I've just been digging in the dmesg logs from when I was using the
> > > Assabet+Neponset as my firewall, and it was having to use the IDE
> > > ide-cs driver rather than the pata pcmcia driver.
> > >
> > > I don't recall whether the pata pcmcia driver was a problem or not,
> > > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> > > think PATA tries to use the "highest" possible access size by
> > > default...
> >
> > It doesn't actually - it defaults to 16-bits for PIO data access and
> > you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
> > (pata_pcmcia doesn't set it so it should be okay). Also taskfile
> > registers are accessed using 8-bits access by default transport
> > functions (which are used by pata_pcmcia).
>
> Please also note that:
>
> - assebet_defconfig currently doesn't even enable ide-cs
> (CONFIG_BLK_DEV_IDECS) in the mainline kernel
>
> - neponset_defconfig doesn't even enable IDE (CONFIG_IDE)
> in the mainline kernel
>
> so there is no risk of breaking anything..
I noticed this older pull request in my todo folder, my interpretation
is that the concern was resolved and we simply missed it.
I've pulled it into next/defconfig for v4.10 now, with the above
in the merge commit text for reference.
Thanks,
Arnd
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Arnd Bergmann @ 2016-11-25 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87inrbqr16.fsf@belgarion.home>
On Friday, November 25, 2016 8:48:53 PM CET Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > The camera_supply_dummy_device definition is shared between a780 and a910,
> > but only provided when the first is enabled and fails to build for a
> > configuration with only a910:
> >
> > arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
> >
> > This moves the definition into its own section.
> >
> > Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Ah yes, I'll queue that up in pxa/fixes.
>
> This also means that you have a test robot which beats my Jenkins, as mine
> didn't complain. Do you have a specific defconfig or is it a randconfig which
> reveals that ?
>
It showed up in randconfig builds, two out of several hundred.
I'm not surprised that nobody else caught it.
Arnd
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Arnd Bergmann @ 2016-11-25 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017204919.GE3264@localhost>
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> > GICR for multiple CPU can be described with start address and stride,
> > or with multiple address. Current multiple address and stride are
> > both used. Fix it.
> >
> > vmalloc patch 727a7f5a9 triggered this bug:
> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > [ 0.097150] pgd = ffff000008602000
> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > [ 0.097170] Modules linked in:
> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20
> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
>
> A Fixes: tag would be useful on a patch like this, to tell what patch
> introduced the problem. Please consider using them in the future.
>
> I've applied this one to fixes now.
Hi Olof,
I happened to still have this one in my todo folder as I must have
missed your reply, and I stumbled over it while looking for things
that may have gone missing.
I don't see it in v4.9-rc6, did it get dropped accidentally?
Arnd
^ permalink raw reply
* [GIT PULL] STi defconfig fix for v4.9-rcs
From: Arnd Bergmann @ 2016-11-25 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0492803d-d136-618d-bf06-51f0001d039b@st.com>
On Wednesday, November 23, 2016 9:59:14 AM CET Patrice Chotard wrote:
> STi defconfig fix:
>
> Enable HVA (Hardware Video Accelerator) video encoder
> driver for STMicroelectronics SoC.
Defconfig changes like this don't seem particularly urgent. Unless
there is a good reason, I'd suggest putting this into v4.10 instead.
Arnd
^ permalink raw reply
* [GIT PULL] STi DT fix for v4.9-rcs round 2
From: Arnd Bergmann @ 2016-11-25 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d109e729-0d50-40ac-ceeb-16d88a7a3e74@st.com>
On Wednesday, November 23, 2016 9:59:16 AM CET Patrice Chotard wrote:
> STi DT fix:
>
> The I2C nodes are missing #address-cells and #size-cells.
> This is causing warning at device tree compilation when
> some I2C device sub-nodes are defined.
>
>
Pulled into fixes branch, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.9, take 2
From: Arnd Bergmann @ 2016-11-25 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122143134.wxinkyp3x6jjnk7e@lukather>
On Tuesday, November 22, 2016 3:31:34 PM CET Maxime Ripard wrote:
> Allwinner fixes for 4.9, second iteration
>
> A renaming of the GR8 DTSI and DTS to make it explicitly part of the sun5i
> family.
>
Pulled into the fixe branch, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-25 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125152047.oadxi2xbgm4kdd7q@lukather>
On Fri, 25 Nov 2016 16:20:47 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Nov 24, 2016 at 09:05:09PM +0100, Emmanuel Vadot wrote:
> > On Thu, 24 Nov 2016 20:55:17 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > > > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > > > others three only have 1.
> > > > Add the num-cs property to each node.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > >
> > > I don't think we have any code that uses it at the moment. What is the
> > > rationale behind this patch?
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > Hi Maxime,
> >
> > If num-cs isn't present nothing prevent to start a transfer with a
> > non-valid CS pin, resulting in an error.
> > num-cs are default property especially made for this and a SPI driver
> > should try to get the property at probe/attach time.
>
> Yes, but as far as I know, our driver doesn't. I'm all in for having
> support for that in our driver, but without it, that patch is kind of
> useless.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Yes the Linux driver doesn't use it but my upcoming one for FreeBSD
uses it. So it is not useless for downstream user of DTS.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Ard Biesheuvel @ 2016-11-25 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-14-git-send-email-Dave.Martin@arm.com>
On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on
> it to be configured together with Scalable Vector Extension support
> in the same kernel, this patch implements basic support for
> saving/restoring the SVE state around kernel_neon_begin()...
> kernel_neon_end().
>
> This patch is not optimal and will generally save more state than
> necessary, more often than necessary. Further optimisations can be
> implemented in future patches.
>
> This patch is not intended to allow general-purpose _SVE_ code to
> execute in the kernel safely. That functionality may also follow
> in later patches.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/Kconfig | 1 -
> arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
> 2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e8d04dd..7266761 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -880,7 +880,6 @@ endmenu
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> - depends on !KERNEL_MODE_NEON # until it works with SVE
> help
> The Scalable Vector Extension (SVE) is an extension to the AArch64
> execution state which complements and extends the SIMD functionality
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 81cfdb5..cb947dd 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> */
> void kernel_neon_begin_partial(u32 num_regs)
> {
> + preempt_disable();
> +
> + /*
> + * For now, we have no special storage for SVE registers in
> + * interrupt context, so always save the userland SVE state
> + * if there is any, even for interrupts.
> + */
> + if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
> + current->mm &&
> + !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
> + fpsimd_save_state(¤t->thread.fpsimd_state);
> + this_cpu_write(fpsimd_last_state, NULL);
> + }
> +
I am having trouble understanding why we need all of this if we don't
support SVE in the kernel. Could you elaborate?
> if (in_interrupt()) {
> struct fpsimd_partial_state *s = this_cpu_ptr(
> in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> -
> BUG_ON(num_regs > 32);
> +
> + /* Save partial state for interrupted kernel-mode NEON code: */
> fpsimd_save_partial_state(s, roundup(num_regs, 2));
> } else {
> /*
> @@ -295,7 +310,6 @@ void kernel_neon_begin_partial(u32 num_regs)
> * that there is no longer userland FPSIMD state in the
> * registers.
> */
> - preempt_disable();
> if (current->mm &&
> !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
> @@ -310,9 +324,9 @@ void kernel_neon_end(void)
> struct fpsimd_partial_state *s = this_cpu_ptr(
> in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> }
> +
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> --
> 2.1.4
>
^ permalink raw reply
* [RFC PATCH 06/29] arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON
From: Ard Biesheuvel @ 2016-11-25 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-7-git-send-email-Dave.Martin@arm.com>
On 25 November 2016 at 19:38, Dave Martin <Dave.Martin@arm.com> wrote:
> The EFI runtime services ABI permits calls to EFI to clobber
> certain FPSIMD/NEON registers, as per the AArch64 procedure call
> standard.
>
> Saving/restoring the clobbered registers around such calls needs
> KERNEL_MODE_NEON, but the dependency is missing from Kconfig.
>
> This patch adds the missing dependency.
>
> This will aid bisection of the patches implementing support for the
> ARM Scalable Vector Extension (SVE).
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 969ef88..d008bb6 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -963,6 +963,7 @@ config EFI_STUB
> config EFI
> bool "UEFI runtime support"
> depends on OF && !CPU_BIG_ENDIAN
> + depends on KERNEL_MODE_NEON
> select LIBFDT
> select UCS2_STRING
> select EFI_PARAMS_FROM_FDT
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Harald Welte @ 2016-11-25 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bdf159-93f2-5ed7-1e28-7fb80707d6c7@datenfreihafen.org>
Hi Stefan,
On Thu, Nov 24, 2016 at 11:10:09PM +0100, Stefan Schmidt wrote:
> Daniel, Harald, if one of you is still interested in these and what to
> pick up the work again, please speak up now. :)
I have no interest, motivtaion nor time to still work on ezx support. I
guess the number of people running a recent kernel on more than 10 year
old 2G-only phones is pretty low these days.
If anyone has a serious interest in taking this over, I think I still
have some A780 and A1200 units that I am happy to provide.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Robert Jarzmik @ 2016-11-25 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b97a129-bd10-b9be-616d-a3ea3b91b103@metafoo.de>
Lars-Peter Clausen <lars@metafoo.de> writes:
...
Ok Lars, let's do this : I integrate as many of your remarks as I can, and I
respin this serie, limited to patches 1, 2, 3, 4 and 5.
Then we'll iterate, that will enable me to settle the serie, as I was on
holidays and lost a bit my track. I'll send it hopefully next week once I've
gathered my thoughts.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata
From: Robert Jarzmik @ 2016-11-25 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123231320.fo3kilw5h7cctngc@earth>
Sebastian Reichel <sre@kernel.org> writes:
> Hi Robert,
>
> On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote:
>> As the power supply framework provides a way to store and retrieve
>> private supply data, use it.
>>
>> In the process, change the platform data for wm97xx_battery from a
>> container of a single struct wm97xx_batt_pdata to the direct point to wm97xx_batt_pdata.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> ---
>> drivers/input/touchscreen/wm97xx-core.c | 2 +-
>> drivers/power/supply/wm97xx_battery.c | 25 ++++++++++---------------
>> 2 files changed, 11 insertions(+), 16 deletions(-)
>
> I queued this into power-supply's for-next branch.
Thanks Sebastian.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Robert Jarzmik @ 2016-11-25 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bdf159-93f2-5ed7-1e28-7fb80707d6c7@datenfreihafen.org>
Stefan Schmidt <stefan@datenfreihafen.org> writes:
> Hello.
>
> On 24.11.2016 17:29, Arnd Bergmann wrote:
>> The camera_supply_dummy_device definition is shared between a780 and a910,
>> but only provided when the first is enabled and fails to build for a
>> configuration with only a910:
>>
>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>>
>> This moves the definition into its own section.
>>
>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
>
> I wonder what we should do with ezx.c.
>
> As far as I know neither Daniel nor Harald or myself are doing anything
> with this devices anymore. Besides a basic compile test having an ack or
> reviewed by from our side is a bit worthless. :/
>
> I should still have some of these phones around in a box somewhere. If
> there is someone with a good motivation and time to take over on this
> platform we will find a way to get the person this devices.
>
> Any takers? Robert? I guess you are already overloaded but you might
> also have an interest. Worth asking :)
Oh yes, I'm very interested in your box. Besides I really like old platforms
:)
> In the case nobody wants to pick up here what would you consider the
> bets way forward? I could send a patch removing ezx platform support
> from the kernel (basically ezx.c plus build support) or I can send a
> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>
> Daniel, Harald, if one of you is still interested in these and what to
> pick up the work again, please speak up now. :)
Unless another maintainer steps in, you can submit a patch to transfer the
maintainance onto me, and we'll see off mailing lists how we could arange the
boards transfer.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Robert Jarzmik @ 2016-11-25 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124162955.3887066-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The camera_supply_dummy_device definition is shared between a780 and a910,
> but only provided when the first is enabled and fails to build for a
> configuration with only a910:
>
> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>
> This moves the definition into its own section.
>
> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ah yes, I'll queue that up in pxa/fixes.
This also means that you have a test robot which beats my Jenkins, as mine
didn't complain. Do you have a specific defconfig or is it a randconfig which
reveals that ?
Cheers.
--
Robert
^ permalink raw reply
* [RFC PATCH 29/29] arm64/sve: Limit vector length to 512 bits by default
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
As a transitional workaround for userspace incompatibilities caused
by enlargement of the signal frame, this patch adds a new config
option CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH, which default to n.
Unless this option is set to y, the vector length for SVE will be
limited to 512 bits. This leaves a bit of free space for other
architecture extensions just in case we need it.
This option will be removed and replaced with a user/kernel control
interface in the future.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/Kconfig | 35 +++++++++++++++++++++++++++++++++++
arch/arm64/mm/proc.S | 5 +++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bf9915cb..7cd9812 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -887,6 +887,41 @@ config ARM64_SVE
To enable use of this extension on CPUs that implement it, say Y.
+if ARM64_SVE
+
+config ARM64_SVE_FULL_VECTOR_LENGTH
+ bool "Enable full hardware vector length for userspace"
+ default n
+ help
+ SVE vector lengths greater than 512 bits impact the size of signal
+ frames and therefore the size requirements for any userspace stack
+ onto which a signal may be delivered. Using larger vector lengths
+ may therefore cause problems for some software. For this reason, the
+ kernel currently limits the maximum vector length for userspace
+ software to 512 bits by default.
+
+ Enabling this option removes the limit, so that the full vector
+ length implemented by the hardware is made available to userspace.
+
+ Be aware: in general, software that (a) does not use SVE (including
+ via libraries), or (b) does not handle signals, or (c) uses default
+ process/thread stack sizes and does not use sigaltstack(2) should be
+ unaffected by enabling larger vectors. Software that does not meet
+ these criteria or that relies on certain legacy uses of the ucontext
+ API may be affected however.
+
+ This is a transitional compatibility option only and will be replaced
+ by a userspace ABI extension in the future. Do not assume that this
+ option will be available with compatible effect in future Linux
+ releases.
+
+ If you are developing software that uses SVE and understand the
+ implications, you can consider saying Y here.
+
+ If unsure, say N.
+
+endif
+
config ARM64_MODULE_CMODEL_LARGE
bool
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 1da8160..a2839e6 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -198,6 +198,11 @@ ENTRY(__cpu_setup)
mrs_s x5, ZIDR_EL1 // SVE: Enable full vector len
and x5, x5, #ZCR_EL1_LEN_MASK // initially
+#ifndef CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH
+ mov x6, #(512 / 128 - 1) // Clamp VL to 512 bits
+ cmp x5, x6
+ csel x5, x5, x6, lo
+#endif
msr_s ZCR_EL1, x5
b 2f
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 28/29] arm64: KVM: Treat SVE use by guests as undefined instruction execution
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
We don't currently support context-switching of Scalable Vector
Extension context between vcpus, and the SVE access exception is
thus left masked by default at EL2 when running a vcpu.
However, there's nothing to stop a guest trying to use SVE. If it
does, we'll get an SVE access exception to EL2 which will cause KVM
to panic since this exception isn't yet recognised.
This patch adds knowledge to KVM about the SVE access exception,
translating it into an undefined instruction exception injected to
the vcpu.
This prevents a malicious guest from panicking the host by
attempted SVE use.
SVE-enabled guests will still not work properly for now, but they
won't take the host down.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kvm/handle_exit.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index a204adf..f43b6d0 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -125,6 +125,14 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
return ret;
}
+static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ /* Until SVE is supported for guests: */
+ kvm_inject_undefined(vcpu);
+
+ return 1;
+}
+
static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_WFx] = kvm_handle_wfx,
[ESR_ELx_EC_CP15_32] = kvm_handle_cp15_32,
@@ -137,6 +145,7 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_HVC64] = handle_hvc,
[ESR_ELx_EC_SMC64] = handle_smc,
[ESR_ELx_EC_SYS64] = kvm_handle_sys_reg,
+ [ESR_ELx_EC_SVE] = handle_sve,
[ESR_ELx_EC_IABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_DABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 27/29] arm64/sve: ptrace support
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
From: Alan Hayward <alan.hayward@arm.com>
This patch adds support for accessing a task's SVE registers via
ptrace.
Some additional helpers are added in order to support the SVE/
FPSIMD register view synchronisation operations that are required
in order to make the NT_PRFPREG and NT_ARM_SVE regsets interact
correctly.
fpr_set()/fpr_get() are refactored into backend/frontend functions,
so that the core can be reused by sve_set()/sve_get() for the case
where no SVE registers are stored for a thread.
Signed-off-by: Alan Hayward <alan.hayward@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/fpsimd.h | 20 +++
arch/arm64/include/uapi/asm/ptrace.h | 125 +++++++++++++++
arch/arm64/include/uapi/asm/sigcontext.h | 4 +
arch/arm64/kernel/fpsimd.c | 42 +++++
arch/arm64/kernel/ptrace.c | 254 ++++++++++++++++++++++++++++++-
include/uapi/linux/elf.h | 1 +
6 files changed, 440 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index e39066a..88bcf69 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -35,6 +35,10 @@ struct fpsimd_state {
__uint128_t vregs[32];
u32 fpsr;
u32 fpcr;
+ /*
+ * For ptrace compatibility, pad to next 128-bit
+ * boundary here if extending this struct.
+ */
};
};
/* the id of the last cpu to have restored this state */
@@ -98,6 +102,22 @@ extern void sve_save_state(void *state, u32 *pfpsr);
extern void sve_load_state(void const *state, u32 const *pfpsr);
extern unsigned int sve_get_vl(void);
+/*
+ * FPSIMD/SVE synchronisation helpers for ptrace:
+ * For use on stopped tasks only
+ */
+
+extern void fpsimd_sync_to_sve(struct task_struct *task);
+
+#ifdef CONFIG_ARM64_SVE
+extern void fpsimd_sync_to_fpsimd(struct task_struct *task);
+extern void fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task);
+#else /* !CONFIG_ARM64_SVE */
+static void __maybe_unused fpsimd_sync_to_fpsimd(struct task_struct *task) { }
+static void __maybe_unused fpsimd_sync_from_fpsimd_zeropad(
+ struct task_struct *task) { }
+#endif /* !CONFIG_ARM64_SVE */
+
#endif
#endif
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index b5c3933..48b57a0 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -22,6 +22,7 @@
#include <linux/types.h>
#include <asm/hwcap.h>
+#include <asm/sigcontext.h>
/*
@@ -77,6 +78,7 @@ struct user_fpsimd_state {
__uint128_t vregs[32];
__u32 fpsr;
__u32 fpcr;
+ /* Pad to next 128-bit boundary here if extending this struct */
};
struct user_hwdebug_state {
@@ -89,6 +91,129 @@ struct user_hwdebug_state {
} dbg_regs[16];
};
+/* SVE/FP/SIMD state (NT_ARM_SVE) */
+
+struct user_sve_header {
+ __u32 size; /* total meaningful regset content in bytes */
+ __u32 max_size; /* maxmium possible size for this thread */
+ __u16 vl; /* current vector length */
+ __u16 max_vl; /* maximum possible vector length */
+ __u16 flags;
+ __u16 __reserved;
+};
+
+/* Definitions for user_sve_header.flags: */
+#define SVE_PT_REGS_MASK (1 << 0)
+
+#define SVE_PT_REGS_FPSIMD 0
+#define SVE_PT_REGS_SVE SVE_PT_REGS_MASK
+
+
+/*
+ * The remainder of the SVE state follows struct user_sve_header. The
+ * total size of the SVE state (including header) depends on the
+ * metadata in the header: SVE_PT_SIZE(vq, flags) gives the total size
+ * of the state in bytes, including the header.
+ *
+ * Refer to <asm/sigcontext.h> for details of how to pass the correct
+ * "vq" argument to these macros.
+ */
+
+/* Offset from the start of struct user_sve_header to the register data */
+#define SVE_PT_REGS_OFFSET ((sizeof(struct sve_context) + 15) / 16 * 16)
+
+/*
+ * The register data content and layout depends on the value of the
+ * flags field.
+ */
+
+/*
+ * (flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD case:
+ *
+ * The payload starts at offset SVE_PT_FPSIMD_OFFSET, and is of type
+ * struct user_fpsimd_state. Additional data might be appended in the
+ * future: use SVE_PT_FPSIMD_SIZE(vq, flags) to compute the total size.
+ * SVE_PT_FPSIMD_SIZE(vq, flags) will never be less than
+ * sizeof(struct user_fpsimd_state).
+ */
+
+#define SVE_PT_FPSIMD_OFFSET SVE_PT_REGS_OFFSET
+
+#define SVE_PT_FPSIMD_SIZE(vq, flags) (sizeof(struct user_fpsimd_state))
+
+/*
+ * (flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE case:
+ *
+ * The payload starts at offset SVE_PT_SVE_OFFSET, and is of size
+ * SVE_PT_SVE_SIZE(vq, flags).
+ *
+ * Additional macros describe the contents and layout of the payload.
+ * For each, SVE_PT_SVE_x_OFFSET(args) is the start offset relative to
+ * the start of struct user_sve_header, and SVE_PT_SVE_x_SIZE(args) is
+ * the size in bytes:
+ *
+ * x type description
+ * - ---- -----------
+ * ZREGS \
+ * ZREG |
+ * PREGS | refer to <asm/sigcontext.h>
+ * PREG |
+ * FFR /
+ *
+ * FPSR uint32_t FPSR
+ * FPCR uint32_t FPCR
+ *
+ * Additional data might be appended in the future.
+ */
+
+#define SVE_PT_SVE_ZREG_SIZE(vq) SVE_SIG_ZREG_SIZE(vq)
+#define SVE_PT_SVE_PREG_SIZE(vq) SVE_SIG_PREG_SIZE(vq)
+#define SVE_PT_SVE_FFR_SIZE(vq) SVE_SIG_FFR_SIZE(vq)
+#define SVE_PT_SVE_FPSR_SIZE sizeof(__u32)
+#define SVE_PT_SVE_FPCR_SIZE sizeof(__u32)
+
+#define __SVE_SIG_TO_PT(offset) \
+ ((offset) - SVE_SIG_REGS_OFFSET + SVE_PT_REGS_OFFSET)
+
+#define SVE_PT_SVE_OFFSET SVE_PT_REGS_OFFSET
+
+#define SVE_PT_SVE_ZREGS_OFFSET \
+ __SVE_SIG_TO_PT(SVE_SIG_ZREGS_OFFSET)
+#define SVE_PT_SVE_ZREG_OFFSET(vq, n) \
+ __SVE_SIG_TO_PT(SVE_SIG_ZREG_OFFSET(vq, n))
+#define SVE_PT_SVE_ZREGS_SIZE(vq) \
+ (SVE_PT_SVE_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_PT_SVE_ZREGS_OFFSET)
+
+#define SVE_PT_SVE_PREGS_OFFSET(vq) \
+ __SVE_SIG_TO_PT(SVE_SIG_PREGS_OFFSET(vq))
+#define SVE_PT_SVE_PREG_OFFSET(vq, n) \
+ __SVE_SIG_TO_PT(SVE_SIG_PREG_OFFSET(vq, n))
+#define SVE_PT_SVE_PREGS_SIZE(vq) \
+ (SVE_PT_SVE_PREG_OFFSET(vq, SVE_NUM_PREGS) - \
+ SVE_PT_SVE_PREGS_OFFSET(vq))
+
+#define SVE_PT_SVE_FFR_OFFSET(vq) \
+ __SVE_SIG_TO_PT(SVE_SIG_FFR_OFFSET(vq))
+
+#define SVE_PT_SVE_FPSR_OFFSET(vq) \
+ ((SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq) + 15) / 16 * 16)
+#define SVE_PT_SVE_FPCR_OFFSET(vq) \
+ (SVE_PT_SVE_FPSR_OFFSET(vq) + SVE_PT_SVE_FPSR_SIZE)
+
+/*
+ * Any future extension appended after FPCR must be aligned to the next
+ * 128-bit boundary.
+ */
+
+#define SVE_PT_SVE_SIZE(vq, flags) \
+ ((SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE - \
+ SVE_PT_SVE_OFFSET + 15) / 16 * 16)
+
+#define SVE_PT_SIZE(vq, flags) \
+ (((flags) & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE ? \
+ SVE_PT_SVE_OFFSET + SVE_PT_SVE_SIZE(vq, flags) \
+ : SVE_PT_FPSIMD_OFFSET + SVE_PT_FPSIMD_SIZE(vq, flags))
+
#endif /* __ASSEMBLY__ */
#endif /* _UAPI__ASM_PTRACE_H */
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index 11c915d..91e55de 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -16,6 +16,8 @@
#ifndef _UAPI__ASM_SIGCONTEXT_H
#define _UAPI__ASM_SIGCONTEXT_H
+#ifndef __ASSEMBLY__
+
#include <linux/types.h>
/*
@@ -96,6 +98,8 @@ struct sve_context {
__u16 __reserved[3];
};
+#endif /* !__ASSEMBLY__ */
+
/*
* The SVE architecture leaves space for future expansion of the
* vector length beyond its initial architectural limit of 2048 bits
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 1750301..6a5e725 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -417,6 +417,48 @@ void fpsimd_flush_task_state(struct task_struct *t)
t->thread.fpsimd_state.cpu = NR_CPUS;
}
+#ifdef CONFIG_ARM64_SVE
+
+/* FPSIMD/SVE synchronisation helpers for ptrace */
+
+void fpsimd_sync_to_sve(struct task_struct *task)
+{
+ if (!test_tsk_thread_flag(task, TIF_SVE))
+ task_fpsimd_to_sve(task);
+}
+
+void fpsimd_sync_to_fpsimd(struct task_struct *task)
+{
+ if (test_tsk_thread_flag(task, TIF_SVE))
+ task_sve_to_fpsimd(task);
+}
+
+static void __fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task,
+ unsigned int vq)
+{
+ struct sve_struct fpsimd_sve_state(vq) *sst =
+ __task_sve_state(task);
+ struct fpsimd_state *fst = &task->thread.fpsimd_state;
+ unsigned int i;
+
+ if (!test_tsk_thread_flag(task, TIF_SVE))
+ return;
+
+ memset(sst->zregs, 0, sizeof(sst->zregs));
+
+ for (i = 0; i < 32; ++i)
+ sst->zregs[i][0] = fst->vregs[i];
+}
+
+void fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task)
+{
+ unsigned int vl = sve_get_vl();
+
+ __fpsimd_sync_from_fpsimd_zeropad(task, sve_vq_from_vl(vl));
+}
+
+#endif /* CONFIG_ARM64_SVE */
+
#ifdef CONFIG_KERNEL_MODE_NEON
static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index e0c81da..bdd2ad3 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -30,7 +30,9 @@
#include <linux/seccomp.h>
#include <linux/security.h>
#include <linux/init.h>
+#include <linux/sched.h>
#include <linux/signal.h>
+#include <linux/string.h>
#include <linux/uaccess.h>
#include <linux/perf_event.h>
#include <linux/hw_breakpoint.h>
@@ -611,13 +613,46 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
/*
* TODO: update fp accessors for lazy context switching (sync/flush hwstate)
*/
+static int __fpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf, unsigned int start_pos)
+{
+ struct user_fpsimd_state *uregs;
+
+ fpsimd_sync_to_fpsimd(target);
+
+ uregs = &target->thread.fpsimd_state.user_fpsimd;
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, uregs,
+ start_pos, start_pos + sizeof(*uregs));
+}
+
static int fpr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
- struct user_fpsimd_state *uregs;
- uregs = &target->thread.fpsimd_state.user_fpsimd;
- return user_regset_copyout(&pos, &count, &kbuf, &ubuf, uregs, 0, -1);
+ return __fpr_get(target, regset, pos, count, kbuf, ubuf, 0);
+}
+
+static int __fpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf,
+ unsigned int start_pos)
+{
+ int ret;
+ struct user_fpsimd_state newstate;
+
+ fpsimd_sync_to_fpsimd(target);
+
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &newstate,
+ start_pos, start_pos + sizeof(newstate));
+ if (ret)
+ return ret;
+
+ target->thread.fpsimd_state.user_fpsimd = newstate;
+
+ return ret;
}
static int fpr_set(struct task_struct *target, const struct user_regset *regset,
@@ -625,14 +660,14 @@ static int fpr_set(struct task_struct *target, const struct user_regset *regset,
const void *kbuf, const void __user *ubuf)
{
int ret;
- struct user_fpsimd_state newstate;
- ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &newstate, 0, -1);
+ ret = __fpr_set(target, regset, pos, count, kbuf, ubuf, 0);
if (ret)
return ret;
- target->thread.fpsimd_state.user_fpsimd = newstate;
+ fpsimd_sync_from_fpsimd_zeropad(target);
fpsimd_flush_task_state(target);
+
return ret;
}
@@ -685,6 +720,204 @@ static int system_call_set(struct task_struct *target,
return ret;
}
+#ifdef CONFIG_ARM64_SVE
+
+static int sve_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+ struct user_sve_header header;
+ unsigned int vq;
+ unsigned long start, end;
+
+ /* Header */
+ memset(&header, 0, sizeof(header));
+
+ header.vl = sve_get_vl();
+
+ BUG_ON(!sve_vl_valid(header.vl));
+ vq = sve_vq_from_vl(header.vl);
+
+ /* Until runtime or per-task vector length changing is supported: */
+ header.max_vl = header.vl;
+
+ header.flags = test_tsk_thread_flag(target, TIF_SVE) ?
+ SVE_PT_REGS_SVE : SVE_PT_REGS_FPSIMD;
+
+ header.size = SVE_PT_SIZE(vq, header.flags);
+ header.max_size = SVE_PT_SIZE(vq, SVE_PT_REGS_SVE);
+
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &header,
+ 0, sizeof(header));
+ if (ret)
+ return ret;
+
+ /* Registers: FPSIMD-only case */
+
+ BUILD_BUG_ON(SVE_PT_FPSIMD_OFFSET != sizeof(header));
+
+ if ((header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD)
+ return __fpr_get(target, regset, pos, count, kbuf, ubuf,
+ SVE_PT_FPSIMD_OFFSET);
+
+ /* Otherwise: full SVE case */
+
+ BUILD_BUG_ON(SVE_PT_SVE_OFFSET != sizeof(header));
+
+ start = SVE_PT_SVE_OFFSET;
+ end = SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq);
+
+ BUG_ON((char *)__task_sve_state(target) < (char *)target);
+ BUG_ON(end < start);
+ BUG_ON(arch_task_struct_size < end - start);
+ BUG_ON((char *)__task_sve_state(target) - (char *)target >
+ arch_task_struct_size - (end - start));
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ __task_sve_state(target),
+ start, end);
+ if (ret)
+ return ret;
+
+ start = end;
+ end = SVE_PT_SVE_FPSR_OFFSET(vq);
+
+ BUG_ON(end < start);
+ ret = user_regset_copyout_zero(&pos, &count, &kbuf, &ubuf,
+ start, end);
+ if (ret)
+ return ret;
+
+ start = end;
+ end = SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE;
+
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) <
+ (char *)&target->thread.fpsimd_state.fpsr);
+ BUG_ON(end < start);
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) -
+ (char *)&target->thread.fpsimd_state.fpsr !=
+ end - start);
+
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpsimd_state.fpsr,
+ start, end);
+ if (ret)
+ return ret;
+
+ start = end;
+ end = (SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE) + 15) / 16 * 16;
+ BUG_ON(end < start);
+
+ return user_regset_copyout_zero(&pos, &count, &kbuf, &ubuf,
+ start, end);
+}
+
+static int sve_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+ struct user_sve_header header;
+ unsigned int vq;
+ unsigned long start, end;
+
+ /* Header */
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &header,
+ 0, sizeof(header));
+ if (ret)
+ goto out;
+
+ if (header.vl != sve_get_vl())
+ return -EINVAL;
+
+ BUG_ON(!sve_vl_valid(header.vl));
+ vq = sve_vq_from_vl(header.vl);
+
+ if (header.flags & ~SVE_PT_REGS_MASK)
+ return -EINVAL;
+
+ /* Registers: FPSIMD-only case */
+
+ BUILD_BUG_ON(SVE_PT_FPSIMD_OFFSET != sizeof(header));
+
+ if ((header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD) {
+ ret = __fpr_set(target, regset, pos, count, kbuf, ubuf,
+ SVE_PT_FPSIMD_OFFSET);
+ clear_tsk_thread_flag(target, TIF_SVE);
+ goto out;
+ }
+
+ /* Otherwise: full SVE case */
+
+ fpsimd_sync_to_sve(target);
+ set_tsk_thread_flag(target, TIF_SVE);
+
+ BUILD_BUG_ON(SVE_PT_SVE_OFFSET != sizeof(header));
+
+ start = SVE_PT_SVE_OFFSET;
+ end = SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq);
+
+ BUG_ON((char *)__task_sve_state(target) < (char *)target);
+ BUG_ON(end < start);
+ BUG_ON(arch_task_struct_size < end - start);
+ BUG_ON((char *)__task_sve_state(target) - (char *)target >
+ arch_task_struct_size - (end - start));
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ __task_sve_state(target),
+ start, end);
+ if (ret)
+ goto out;
+
+ start = end;
+ end = SVE_PT_SVE_FPSR_OFFSET(vq);
+
+ BUG_ON(end < start);
+ ret = user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
+ start, end);
+ if (ret)
+ goto out;
+
+ start = end;
+ end = SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE;
+
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) <
+ (char *)&target->thread.fpsimd_state.fpsr);
+ BUG_ON(end < start);
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) -
+ (char *)&target->thread.fpsimd_state.fpsr !=
+ end - start);
+
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpsimd_state.fpsr,
+ start, end);
+
+out:
+ fpsimd_flush_task_state(target);
+ return ret;
+}
+
+#else /* !CONFIG_ARM64_SVE */
+
+static int sve_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ return -EINVAL;
+}
+
+static int sve_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ return -EINVAL;
+}
+
+#endif /* !CONFIG_ARM64_SVE */
+
enum aarch64_regset {
REGSET_GPR,
REGSET_FPR,
@@ -694,6 +927,7 @@ enum aarch64_regset {
REGSET_HW_WATCH,
#endif
REGSET_SYSTEM_CALL,
+ REGSET_SVE,
};
static const struct user_regset aarch64_regsets[] = {
@@ -751,6 +985,14 @@ static const struct user_regset aarch64_regsets[] = {
.get = system_call_get,
.set = system_call_set,
},
+ [REGSET_SVE] = { /* Scalable Vector Extension */
+ .core_note_type = NT_ARM_SVE,
+ .n = (SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE) + 15) / 16,
+ .size = 16,
+ .align = 16,
+ .get = sve_get,
+ .set = sve_set,
+ },
};
static const struct user_regset_view user_aarch64_view = {
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index b59ee07..23c6585 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -414,6 +414,7 @@ typedef struct elf64_shdr {
#define NT_ARM_HW_BREAK 0x402 /* ARM hardware breakpoint registers */
#define NT_ARM_HW_WATCH 0x403 /* ARM hardware watchpoint registers */
#define NT_ARM_SYSTEM_CALL 0x404 /* ARM system call number */
+#define NT_ARM_SVE 0x405 /* ARM Scalable Vector Extension registers */
#define NT_METAG_CBUF 0x500 /* Metag catch buffer registers */
#define NT_METAG_RPIPE 0x501 /* Metag read pipeline state */
#define NT_METAG_TLS 0x502 /* Metag TLS pointer */
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 26/29] arm64/sve: Avoid stale user register state after SVE access exception
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
Currently, when an SVE access exception is taken from userspace,
the FPSIMD state in the task_struct is converted to SVE state and
reloaded as SVE state.
Unfortunately, since we've been executing in userspace there's no
guarantee that the FPSIMD state saved will actually be up to date
with respect to the registers, so updates may be lost.
This patch saves the FPSIMD state back to the task_struct first, to
ensure that the task_struct copy of the data is up to date.
Also, the CPACR handling logic is removed since task_fpsimd_load()
handles it anyway.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/fpsimd.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 2e1056e..1750301 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -103,22 +103,18 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
static void task_fpsimd_to_sve(struct task_struct *task);
static void task_fpsimd_load(struct task_struct *task);
+static void task_fpsimd_save(struct task_struct *task);
void do_sve_acc(unsigned int esr, struct pt_regs *regs)
{
- if (test_and_set_thread_flag(TIF_SVE)) {
- unsigned long tmp;
-
- asm ("mrs %0, cpacr_el1" : "=r" (tmp));
-
- printk(KERN_INFO "%s: Strange, ZEN=%u\n",
- __func__, (unsigned int)((tmp >> 16) & 3));
- BUG();
- }
-
BUG_ON(is_compat_task());
+ task_fpsimd_save(current);
+
task_fpsimd_to_sve(current);
+ if (test_and_set_thread_flag(TIF_SVE))
+ BUG(); /* We shouldn't trap if SVE was already enabled! */
+
task_fpsimd_load(current);
}
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 25/29] arm64/sve: Avoid preempt_disable() during sigreturn
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
Currently the sigreturn implementation for SVE relies on
preempt_disable() to avoid an intervening context switch from
corrupting the SVE state in the task_struct.
Unforunately, __get_user() and friends are not safe under
preempt_disable().
As an alternative, this patch removes preempt_disable() and sets
TIF_FOREIGN_FPSTATE instead: this will inform the context switch
code that the current CPU registers don't contain the SVE/FPSIMD
state of the current task, preventing writeback to the task_struct
during context switch.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/signal.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 2528ec1..942d66f 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -256,10 +256,8 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
if (vl != sve_get_vl())
return -EINVAL;
- preempt_disable();
-
set_thread_flag(TIF_FOREIGN_FPSTATE);
- set_thread_flag(TIF_SVE);
+ barrier();
BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
@@ -270,7 +268,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
SVE_SIG_REGS_OFFSET,
SVE_SIG_REGS_SIZE(vq));
if (err)
- goto out_preempt;
+ return err;
/* copy the FP and status/control registers */
/* restore_sigframe() already checked that user->fpsimd != NULL. */
@@ -279,13 +277,13 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
__get_user_error(fpsimd.fpsr, &user->fpsimd->fpsr, err);
__get_user_error(fpsimd.fpcr, &user->fpsimd->fpcr, err);
+ barrier();
+ set_thread_flag(TIF_SVE);
+
/* load the hardware registers from the fpsimd_state structure */
if (!err)
fpsimd_update_current_state(&fpsimd);
-out_preempt:
- preempt_enable();
-
return err;
}
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox