* [PATCH v9 01/11] arm/arm64: vgic: Implement support for userspace access
From: Christoffer Dall @ 2016-11-28 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479906118-15832-2-git-send-email-vijay.kilari@gmail.com>
On Wed, Nov 23, 2016 at 06:31:48PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> Read and write of some registers like ISPENDR and ICPENDR
> from userspace requires special handling when compared to
> guest access for these registers.
>
> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> for handling of ISPENDR, ICPENDR registers handling.
>
> Add infrastructure to support guest and userspace read
> and write for the required registers
> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 102 ++++++++++++++++++++++++++++++++-------
> virt/kvm/arm/vgic/vgic-mmio.c | 78 +++++++++++++++++++++++++++---
> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
> 4 files changed, 175 insertions(+), 49 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> index b44b359..0b32f40 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> return -ENXIO;
> }
>
> -/*
> - * When userland tries to access the VGIC register handlers, we need to
> - * create a usable struct vgic_io_device to be passed to the handlers and we
> - * have to set up a buffer similar to what would have happened if a guest MMIO
> - * access occurred, including doing endian conversions on BE systems.
> - */
> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> - bool is_write, int offset, u32 *val)
> -{
> - unsigned int len = 4;
> - u8 buf[4];
> - int ret;
> -
> - if (is_write) {
> - vgic_data_host_to_mmio_bus(buf, len, *val);
> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
> - } else {
> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
> - if (!ret)
> - *val = vgic_data_mmio_bus_to_host(buf, len);
> - }
> -
> - return ret;
> -}
> -
> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> int offset, u32 *val)
> {
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index 50f42f0..8e76d04 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -207,6 +207,66 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
> return 0;
> }
>
> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> + gpa_t addr, unsigned int len)
> +{
> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> + u32 value = 0;
> + int i;
> +
> + /*
> + * A level triggerred interrupt pending state is latched in both
> + * "soft_pending" and "line_level" variables. Userspace will save
> + * and restore soft_pending and line_level separately.
> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> + * handling of ISPENDR and ICPENDR.
> + */
> + for (i = 0; i < len * 8; i++) {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> +
> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
> + value |= (1U << i);
> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
> + value |= (1U << i);
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +
> + return value;
> +}
> +
> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
> + gpa_t addr, unsigned int len,
> + unsigned long val)
> +{
> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> + int i;
> +
> + for (i = 0; i < len * 8; i++) {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> +
> + spin_lock(&irq->irq_lock);
> + if (test_bit(i, &val)) {
> + /* soft_pending is set irrespective of irq type
> + * (level or edge) to avoid dependency that VM should
> + * restore irq config before pending info.
> + */
nit: kernel commenting style
> + irq->pending = true;
> + irq->soft_pending = true;
> + vgic_queue_irq_unlock(vcpu->kvm, irq);
> + } else {
> + irq->soft_pending = false;
> + if (irq->config == VGIC_CONFIG_EDGE ||
> + (irq->config == VGIC_CONFIG_LEVEL &&
> + !irq->line_level))
> + irq->pending = false;
> + spin_unlock(&irq->irq_lock);
> + }
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +}
> +
> /* We want to avoid outer shareable. */
> u64 vgic_sanitise_shareability(u64 field)
> {
> @@ -356,7 +416,7 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> * We take some special care here to fix the calculation of the register
> * offset.
> */
> -#define REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(off, rd, wr, bpi, acc) \
> +#define REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(off, rd, wr, ur, uw, bpi, acc) \
> { \
> .reg_offset = off, \
> .bits_per_irq = bpi, \
> @@ -371,6 +431,8 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> .access_flags = acc, \
> .read = rd, \
> .write = wr, \
> + .uaccess_read = ur, \
> + .uaccess_write = uw, \
> }
>
> static const struct vgic_register_region vgic_v3_dist_registers[] = {
> @@ -378,40 +440,42 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> vgic_mmio_read_v3_misc, vgic_mmio_write_v3_misc, 16,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGROUPR,
> - vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
> + vgic_mmio_read_rao, vgic_mmio_write_wi, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISENABLER,
> - vgic_mmio_read_enable, vgic_mmio_write_senable, 1,
> + vgic_mmio_read_enable, vgic_mmio_write_senable, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICENABLER,
> - vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
> + vgic_mmio_read_enable, vgic_mmio_write_cenable, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISPENDR,
> - vgic_mmio_read_pending, vgic_mmio_write_spending, 1,
> + vgic_mmio_read_pending, vgic_mmio_write_spending,
> + vgic_v3_uaccess_read_pending, vgic_v3_uaccess_write_pending, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICPENDR,
> - vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
> + vgic_mmio_read_pending, vgic_mmio_write_cpending,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISACTIVER,
> - vgic_mmio_read_active, vgic_mmio_write_sactive, 1,
> + vgic_mmio_read_active, vgic_mmio_write_sactive, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICACTIVER,
> - vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
> + vgic_mmio_read_active, vgic_mmio_write_cactive, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IPRIORITYR,
> - vgic_mmio_read_priority, vgic_mmio_write_priority, 8,
> - VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
> + vgic_mmio_read_priority, vgic_mmio_write_priority, NULL, NULL,
> + 8, VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ITARGETSR,
> - vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 8,
> VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICFGR,
> - vgic_mmio_read_config, vgic_mmio_write_config, 2,
> + vgic_mmio_read_config, vgic_mmio_write_config, NULL, NULL, 2,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGRPMODR,
> - vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IROUTER,
> - vgic_mmio_read_irouter, vgic_mmio_write_irouter, 64,
> + vgic_mmio_read_irouter, vgic_mmio_write_irouter, NULL, NULL, 64,
> VGIC_ACCESS_64bit | VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICD_IDREGS,
> vgic_mmio_read_v3_idregs, vgic_mmio_write_wi, 48,
> @@ -449,11 +513,13 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> REGISTER_DESC_WITH_LENGTH(GICR_ICENABLER0,
> vgic_mmio_read_enable, vgic_mmio_write_cenable, 4,
> VGIC_ACCESS_32bit),
> - REGISTER_DESC_WITH_LENGTH(GICR_ISPENDR0,
> - vgic_mmio_read_pending, vgic_mmio_write_spending, 4,
> + REGISTER_DESC_WITH_LENGTH_UACCESS(GICR_ISPENDR0,
> + vgic_mmio_read_pending, vgic_mmio_write_spending,
> + vgic_v3_uaccess_read_pending, vgic_v3_uaccess_write_pending, 4,
> VGIC_ACCESS_32bit),
> - REGISTER_DESC_WITH_LENGTH(GICR_ICPENDR0,
> - vgic_mmio_read_pending, vgic_mmio_write_cpending, 4,
> + REGISTER_DESC_WITH_LENGTH_UACCESS(GICR_ICPENDR0,
> + vgic_mmio_read_pending, vgic_mmio_write_cpending,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICR_ISACTIVER0,
> vgic_mmio_read_active, vgic_mmio_write_sactive, 4,
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index ebe1b9f..d5f3ee2 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -484,6 +484,74 @@ static bool check_region(const struct kvm *kvm,
> return false;
> }
>
> +static const struct vgic_register_region *
> +vgic_get_mmio_region(struct kvm_vcpu *vcpu, struct vgic_io_device *iodev,
> + gpa_t addr, int len)
> +{
> + const struct vgic_register_region *region;
> +
> + region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
> + addr - iodev->base_addr);
> + if (!region || !check_region(vcpu->kvm, region, addr, len))
> + return NULL;
> +
> + return region;
> +}
> +
> +static int vgic_uaccess_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> + gpa_t addr, u32 *val)
> +{
> + struct vgic_io_device *iodev = kvm_to_vgic_iodev(dev);
> + const struct vgic_register_region *region;
> + struct kvm_vcpu *r_vcpu;
> +
> + region = vgic_get_mmio_region(vcpu, iodev, addr, sizeof(u32));
> + if (!region) {
> + *val = 0;
> + return 0;
> + }
> +
> + r_vcpu = iodev->redist_vcpu ? iodev->redist_vcpu : vcpu;
> + if (region->uaccess_read)
> + *val = region->uaccess_read(r_vcpu, addr, sizeof(u32));
> + else
> + *val = region->read(r_vcpu, addr, sizeof(u32));
> +
> + return 0;
> +}
> +
> +static int vgic_uaccess_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> + gpa_t addr, const u32 *val)
> +{
> + struct vgic_io_device *iodev = kvm_to_vgic_iodev(dev);
> + const struct vgic_register_region *region;
> + struct kvm_vcpu *r_vcpu;
> +
> + region = vgic_get_mmio_region(vcpu, iodev, addr, sizeof(u32));
> + if (!region)
> + return 0;
> +
> + r_vcpu = iodev->redist_vcpu ? iodev->redist_vcpu : vcpu;
> + if (region->uaccess_write)
> + region->uaccess_write(r_vcpu, addr, sizeof(u32), *val);
> + else
> + region->write(r_vcpu, addr, sizeof(u32), *val);
> +
> + return 0;
> +}
> +
> +/*
> + * Userland access to VGIC registers.
> + */
> +int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> + bool is_write, int offset, u32 *val)
> +{
> + if (is_write)
> + return vgic_uaccess_write(vcpu, &dev->dev, offset, val);
> + else
> + return vgic_uaccess_read(vcpu, &dev->dev, offset, val);
> +}
> +
> static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> gpa_t addr, int len, void *val)
> {
> @@ -491,9 +559,8 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> const struct vgic_register_region *region;
> unsigned long data = 0;
>
> - region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
> - addr - iodev->base_addr);
> - if (!region || !check_region(vcpu->kvm, region, addr, len)) {
> + region = vgic_get_mmio_region(vcpu, iodev, addr, len);
> + if (!region) {
> memset(val, 0, len);
> return 0;
> }
> @@ -524,9 +591,8 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> const struct vgic_register_region *region;
> unsigned long data = vgic_data_mmio_bus_to_host(val, len);
>
> - region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
> - addr - iodev->base_addr);
> - if (!region || !check_region(vcpu->kvm, region, addr, len))
> + region = vgic_get_mmio_region(vcpu, iodev, addr, len);
> + if (!region)
> return 0;
>
> switch (iodev->iodev_type) {
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
> index 84961b4..7b30296 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.h
> +++ b/virt/kvm/arm/vgic/vgic-mmio.h
> @@ -34,6 +34,10 @@ struct vgic_register_region {
> gpa_t addr, unsigned int len,
> unsigned long val);
> };
> + unsigned long (*uaccess_read)(struct kvm_vcpu *vcpu, gpa_t addr,
> + unsigned int len);
> + void (*uaccess_write)(struct kvm_vcpu *vcpu, gpa_t addr,
> + unsigned int len, unsigned long val);
> };
>
> extern struct kvm_io_device_ops kvm_io_gic_ops;
> @@ -86,6 +90,18 @@ struct vgic_register_region {
> .write = wr, \
> }
>
> +#define REGISTER_DESC_WITH_LENGTH_UACCESS(off, rd, wr, urd, uwr, length, acc) \
> + { \
> + .reg_offset = off, \
> + .bits_per_irq = 0, \
> + .len = length, \
> + .access_flags = acc, \
> + .read = rd, \
> + .write = wr, \
> + .uaccess_read = urd, \
> + .uaccess_write = uwr, \
> + }
> +
> int kvm_vgic_register_mmio_region(struct kvm *kvm, struct kvm_vcpu *vcpu,
> struct vgic_register_region *reg_desc,
> struct vgic_io_device *region,
> @@ -158,6 +174,9 @@ void vgic_mmio_write_config(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val);
>
> +int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> + bool is_write, int offset, u32 *val);
> +
> unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
>
> unsigned int vgic_v3_init_dist_iodev(struct vgic_io_device *dev);
> --
> 1.9.1
>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Arnd Bergmann @ 2016-11-28 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128123331.GO19016@axis.com>
On Monday, November 28, 2016 1:33:31 PM CET Jesper Nilsson wrote:
> > 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
>
> Ok, should we add that in the MAINTAINERS file so we can
> get it automatically from get_maintainer?
No, we don't want to get every single patch that people submit to
platform maintainers, only the consolidated pull requests that you
send.
Arnd
^ permalink raw reply
* [PATCH net-next v3 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-28 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9709dd57-e536-9281-6b56-5ff5f9e8035c@suse.de>
On Mon, 2016-11-28 at 13:31 +0100, Andreas F?rber wrote:
> Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > ?arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16
> > ++++++++++++++++
> > ?1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index e6e3491d48a5..5624714d2b16 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -46,6 +46,7 @@
> > ?
> > ?#include "meson-gxbb.dtsi"
> > ?#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/net/mdio.h>
> > ?
> > ?/ {
> > ? compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
> > @@ -98,3 +99,18 @@
> > ? pinctrl-0 = <&i2c_a_pins>;
> > ? pinctrl-names = "default";
> > ?};
> > +
> > +ðmac {
> > + phy-handle = <ð_phy0>;
> > +
> > + mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + eth_phy0: ethernet-phy at 0 {
> > + reg = <0>;
> > + eee-broken-modes = <MDIO_EEE_1000T>;
> > + };
> > + };
> > +};
>
6I've tested this hand-applied because it applies to neither amlogic
> v4.10/integ nor linux-next.git and will conflict if applied through
> the
> net-next tree.
I've rebased on net-next this morning. I just checked again and now
there is a conflict indeed. Something got applied between in the last 6
ours which conflict with patch 4.
>
> Note that there already is an ðmac node that you should be
> extending
> rather than duplicating:
>
> ðmac {
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> pinctrl-names = "default";
> };
>
> If you or your colleagues could please fix the sort order of the
> nodes
> to be alphabetical again (ethmac after i2c_A here; between uart_A and
> ir
> in-tree) this wouldn't happen so easily again.
OK
>
> I therefore suggest to not apply this patch 4/4 through net-next but
> through the amlogic tree instead.
Agreed. The change is provided here so people can test.
If the other patches get accepted, I'll submit the dts change through
the amlogic tree.
>
> Thanks,
> Andreas
>
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Ming Lei @ 2016-11-28 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128105254.GB1485@arm.com>
Hi Will,
On Mon, Nov 28, 2016 at 6:52 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ming,
>
> On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
>> When I run stress-ng via the following steps on one ARM64 dual
>> socket system(Cavium Thunder), the kernel oops[1] can often be
>> triggered after running the stress test for several hours(sometimes
>> it may take longer):
>>
>> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
>> - apply the attachment patch which just makes the posix file
>> lock stress test more aggressive
>> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>>
>>
>> From the oops log, looks one garbage file_lock node is got
>> from the linked list of 'ctx->flc_posix' when the issue happens.
>>
>> BTW, the issue isn't observed on single socket Cavium Thunder yet,
>> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
>> too.
>
> I've seen issues with the LSE atomics on the Thunder platform -- can you
> try disabling those (CONFIG_ARM64_LSE_ATOMICS) and see if the problem
> persists, please?
>
Ubuntu Xenial doesn't enable CONFIG_ARM64_LSE_ATOMICS, which
is disabled in my v4.8 kernel config too, please see that in the attachement.
Thanks,
Ming
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-v4.8.tar.gz
Type: application/x-gzip
Size: 40134 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/32583ef0/attachment-0001.bin>
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 3
From: Patrice Chotard @ 2016-11-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider this third round of multi_v7_defconfig updates for v4.10 :
The following changes since commit 57dae748959d0abae2b382ccee68621a82f827c8:
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol (2016-10-21 17:05:54 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-defconfig-for-4.10-round3
for you to fetch changes up to 88d7658bf31f17296b8792e62268825d066d23c4:
ARM: multi_v7_defconfig: enable STMicroelectronics HVA driver (2016-11-28 13:02:14 +0100)
----------------------------------------------------------------
STi defconfig fix:
Enable HVA (Hardware Video Accelerator) video encoder
driver for STMicroelectronics SoC.
----------------------------------------------------------------
Patrice Chotard (1):
ARM: multi_v7_defconfig: enable STMicroelectronics HVA driver
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Jesper Nilsson @ 2016-11-28 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5317474.MXurzNW7Do@wuerfel>
On Sat, Nov 26, 2016 at 12:16:20AM +0100, Arnd Bergmann wrote:
> 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
Ok, should we add that in the MAINTAINERS file so we can
get it automatically from get_maintainer?
> - 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.
Ok, will do both in the future.
> - 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.
Thanks!
> Arnd
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH net-next v3 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Andreas Färber @ 2016-11-28 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-5-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index e6e3491d48a5..5624714d2b16 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -46,6 +46,7 @@
>
> #include "meson-gxbb.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/net/mdio.h>
>
> / {
> compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
> @@ -98,3 +99,18 @@
> pinctrl-0 = <&i2c_a_pins>;
> pinctrl-names = "default";
> };
> +
> +ðmac {
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy at 0 {
> + reg = <0>;
> + eee-broken-modes = <MDIO_EEE_1000T>;
> + };
> + };
> +};
I've tested this hand-applied because it applies to neither amlogic
v4.10/integ nor linux-next.git and will conflict if applied through the
net-next tree.
Note that there already is an ðmac node that you should be extending
rather than duplicating:
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
};
If you or your colleagues could please fix the sort order of the nodes
to be alphabetical again (ethmac after i2c_A here; between uart_A and ir
in-tree) this wouldn't happen so easily again.
I therefore suggest to not apply this patch 4/4 through net-next but
through the amlogic tree instead.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Dave Martin @ 2016-11-28 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128120623.GA17125@e104818-lin.cambridge.arm.com>
On Mon, Nov 28, 2016 at 12:06:24PM +0000, Catalin Marinas wrote:
> On Mon, Nov 28, 2016 at 11:47:26AM +0000, Dave P Martin wrote:
> > On Sat, Nov 26, 2016 at 11:30:42AM +0000, Catalin Marinas wrote:
> > > On Fri, Nov 25, 2016 at 08:45:02PM +0000, Ard Biesheuvel wrote:
> > > > On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> > > > > --- 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?
> > >
> > > Dave knows all the details but a reason is that touching a Neon register
> > > zeros the upper SVE state in the same vector register. So we can't
> > > safely save/restore just the Neon part without corrupting the SVE state.
> >
> > This is right -- this also means that EFI services can trash the upper
> > bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).
> >
> > It's overkill to save/restore absolutely everything -- I ignore num_regs
> > for example -- but I wanted to keep things as simple as possible
> > initially.
>
> Without looking at your patches in detail, could we mandate in the ABI
> that the SVE state is lost on the user/kernel syscall boundary? I guess
> even for the PCS, the SVE state is caller-saved, so there shouldn't be
> an additional cost to user. On interrupts, however, we'd have to
> preserve the SVE state but if we do this on entry/exit points, the
> kernel_neon_*() functions would not have to deal with any SVE state (and
> even ignore it completely if in interrupt).
See [RFC PATCH 24/29] arm64/sve: Discard SVE state on system call.
Currently, kernel_neon_begin_partial() doesn't take advandage of this --
discarding the state is deferred until sched-out, and anyway I don't
check for TIF_SVE in kernel_neon_begin_partial(). There's definitely
some room for improvement.
> the requirements for syscall and sigcontext modifications.
Agreed -- I wanted to get this series posted so skipped that for now,
but I plan to include a Documentation patch alongside the final series.
Cheers
---Dave
^ permalink raw reply
* [PATCH net-next v3 3/4] dt: bindings: add ethernet phy eee-broken-modes option documentation
From: Andreas Färber @ 2016-11-28 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-4-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Andreas F?rber <afaerber@suse.de>
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH net-next v3 2/4] dt-bindings: net: add EEE capability constants
From: Andreas Färber @ 2016-11-28 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-3-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
Tested-by: Andreas F?rber <afaerber@suse.de>
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH net-next v3 1/4] net: phy: add an option to disable EEE advertisement
From: Andreas Färber @ 2016-11-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-2-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
Tested-by: Andreas F?rber <afaerber@suse.de>
With this and the corresponding .dts change, Odroid-C2 survived a
317-package zypper update for me.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] arm64: Remove I-cache invalidation from flush_cache_range()
From: Catalin Marinas @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
The flush_cache_range() function (similarly for flush_cache_page()) is
called when the kernel is changing an existing VA->PA mapping range to
either a new PA or to different attributes. Since ARMv8 has PIPT-like
D-caches, this function does not need to perform any D-cache
maintenance. The I-cache maintenance is already handled via set_pte_at()
and flush_cache_range() cannot anyway guarantee that there are no cache
lines left after invalidation due to the speculative loads.
This patch makes flush_cache_range() a no-op.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
Cc'ing Russell as well, I think we can remove the __flush_icache_all()
call in arch/arm for the VIPT (both aliasing and non-aliasing) caches
since we already handle the I-cache in __sync_icache_dcache(). Any
opinion?
arch/arm64/include/asm/cacheflush.h | 6 +++++-
arch/arm64/mm/flush.c | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index e9f64ecb75ce..5a2a6ee65f65 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -65,7 +65,6 @@
* - kaddr - page address
* - size - region size
*/
-extern void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end);
extern void flush_icache_range(unsigned long start, unsigned long end);
extern void __flush_dcache_area(void *addr, size_t len);
extern void __clean_dcache_area_poc(void *addr, size_t len);
@@ -82,6 +81,11 @@ static inline void flush_cache_page(struct vm_area_struct *vma,
{
}
+static inline void flush_cache_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+}
+
/*
* Cache maintenance functions used by the DMA API. No to be used directly.
*/
diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
index 2d78d5a9b89f..554a2558c12e 100644
--- a/arch/arm64/mm/flush.c
+++ b/arch/arm64/mm/flush.c
@@ -25,13 +25,6 @@
#include <asm/cachetype.h>
#include <asm/tlbflush.h>
-void flush_cache_range(struct vm_area_struct *vma, unsigned long start,
- unsigned long end)
-{
- if (vma->vm_flags & VM_EXEC)
- __flush_icache_all();
-}
-
void sync_icache_aliases(void *kaddr, unsigned long len)
{
unsigned long addr = (unsigned long)kaddr;
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480335328-4010-1-git-send-email-bgolaszewski@baylibre.com>
Due to memory throughput constraints any display mode for which the
pixel clock rate exceeds the recommended value of 37500 KHz must be
filtered out.
Specify the max-pixelclock property for the display node for
da850-lcdk.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index d864f11..1283263 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -285,6 +285,7 @@
&display {
status = "okay";
+ max-pixelclock = <37500>;
};
&display_out {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480335328-4010-1-git-send-email-bgolaszewski@baylibre.com>
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 711b9ad..d864f11 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -50,6 +50,53 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga_bridge {
+ compatible = "dumb-vga-dac";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&display_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -235,3 +282,14 @@
&memctrl {
status = "okay";
};
+
+&display {
+ status = "okay";
+};
+
+&display_out {
+ display_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4070619..5f4ba2e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -454,6 +454,23 @@
reg = <0x213000 0x1000>;
interrupts = <52>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ display_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
};
};
aemif: aemif at 68000000 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/2] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
Bartosz Golaszewski (2):
ARM: dts: da850-lcdk: add the dumb-vga-dac node
ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
arch/arm/boot/dts/da850-lcdk.dts | 59 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 76 insertions(+)
--
2.9.3
^ permalink raw reply
* [GIT PULL] STi defconfig fix for v4.9-rcs
From: Patrice Chotard @ 2016-11-28 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6441620.Ib6HJmGOKY@wuerfel>
On 11/25/2016 10:40 PM, Arnd Bergmann wrote:
> 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.
>
Hi Arnd
> Defconfig changes like this don't seem particularly urgent. Unless
> there is a good reason, I'd suggest putting this into v4.10 instead.
You are right, it's not a urgent update for STi.
I will send a pull request dedicated for v4.10.
Thanks
Patrice
>
> Arnd
>
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Catalin Marinas @ 2016-11-28 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114723.GG1574@e103592.cambridge.arm.com>
On Mon, Nov 28, 2016 at 11:47:26AM +0000, Dave P Martin wrote:
> On Sat, Nov 26, 2016 at 11:30:42AM +0000, Catalin Marinas wrote:
> > On Fri, Nov 25, 2016 at 08:45:02PM +0000, Ard Biesheuvel wrote:
> > > On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> > > > --- 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?
> >
> > Dave knows all the details but a reason is that touching a Neon register
> > zeros the upper SVE state in the same vector register. So we can't
> > safely save/restore just the Neon part without corrupting the SVE state.
>
> This is right -- this also means that EFI services can trash the upper
> bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).
>
> It's overkill to save/restore absolutely everything -- I ignore num_regs
> for example -- but I wanted to keep things as simple as possible
> initially.
Without looking at your patches in detail, could we mandate in the ABI
that the SVE state is lost on the user/kernel syscall boundary? I guess
even for the PCS, the SVE state is caller-saved, so there shouldn't be
an additional cost to user. On interrupts, however, we'd have to
preserve the SVE state but if we do this on entry/exit points, the
kernel_neon_*() functions would not have to deal with any SVE state (and
even ignore it completely if in interrupt).
BTW, we will need an SVE ABI document in Documentation/arm64/ to specify
the requirements for syscall and sigcontext modifications.
--
Catalin
^ permalink raw reply
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Will Deacon @ 2016-11-28 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479642121-17912-1-git-send-email-ard.biesheuvel@linaro.org>
On Sun, Nov 20, 2016 at 11:42:01AM +0000, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
> | SHA256-scalar | SHA256-NEON* | SHA512 |
> ------------+-----------------+--------------+----------+
> Cortex-A53 | 1.63x | 1.63x | 2.34x |
> Cortex-A57 | 1.43x | 1.59x | 1.95x |
> Cortex-A73 | 1.26x | 1.56x | ? |
>
> The core crypto code was authored by Andy Polyakov of the OpenSSL
> project, in collaboration with whom the upstream code was adapted so
> that this module can be built from the same version of sha512-armv8.pl.
>
> The version in this patch was taken from OpenSSL commit 32bbb62ea634
> ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.")
>
> * The core SHA algorithm is fundamentally sequential, but there is a
> secondary transformation involved, called the schedule update, which
> can be performed independently. The NEON version of SHA-224/SHA-256
> only implements this part of the algorithm using NEON instructions,
> the sequential part is always done using scalar instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/crypto/Kconfig | 8 +
> arch/arm64/crypto/Makefile | 17 +
> arch/arm64/crypto/sha256-core.S_shipped | 2061 ++++++++++++++++++++
> arch/arm64/crypto/sha256-glue.c | 185 ++
> arch/arm64/crypto/sha512-armv8.pl | 778 ++++++++
> arch/arm64/crypto/sha512-core.S_shipped | 1085 +++++++++++
> arch/arm64/crypto/sha512-glue.c | 94 +
> 7 files changed, 4228 insertions(+)
If I build a kernel with this applied and CRYPTO_SHA{256,512}_ARM64=y,
then I end up with untracked .S files according to git:
$ git status
Untracked files:
arch/arm64/crypto/sha256-core.S
arch/arm64/crypto/sha512-core.S
Will
^ permalink raw reply
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Herbert Xu @ 2016-11-28 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9RVFQ4SNzbHbNCFSXy01b+_dCeRc4bXgZagovGy9BYtQ@mail.gmail.com>
On Mon, Nov 28, 2016 at 09:50:33AM +0000, Ard Biesheuvel wrote:
>
> Assuming that everyone is happy now (Will?), could we get this one
> queued for v4.10? The CRC stuff I sent over the past week can wait for
> v4.11 (and I should probably do a v2 roundup with everything
> combined), but this patch is good to go IMO
Sorry, I overlooked it because it wasn't in patchwork. I have
applied it now and will push it out soon.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA9JUOHnJL59EuhQ_dEWjt+YjEcu8LGiJ3CSk_7R4J5Efg@mail.gmail.com>
On Mon, Nov 28, 2016 at 11:14:48AM +0000, Peter Maydell wrote:
> On 28 November 2016 at 11:12, Alex Benn?e <alex.bennee@linaro.org> wrote:
> >
> > Andrew Jones <drjones@redhat.com> writes:
> >> I've skimmed over everything looking at it from a framwork/sytle
> >> perspective. I didn't dig in trying to understand the tests though.
> >> One general comment, I see many tests introduce MAX_CPUS 8. Why do
> >> that? Why not allow all cpus by using NR_CPUS for the array sizes?
> >
> > Yeah - I can fix those. I wonder what the maximum is with GIC V3?
>
> So large that you don't want to hardcode it as an array size...
255 with the gic series, not yet merged. Even if you have a dozen arrays
with that as the size, then unless your array element size is huge (on
the order multiple pages), then it probably doesn't matter. Using the
default memory allocation of a QEMU guest, 128 MB, unit tests have plenty
of memory at their disposal. The framework itself only allocates a handful
of pages.
Of course the framework also supports dynamic memory allocation, so you
could do malloc(nr_cpus * element_size), to avoid excess.
Thanks,
drew
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Dave Martin @ 2016-11-28 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126113038.GA86651@MBP.local>
On Sat, Nov 26, 2016 at 11:30:42AM +0000, Catalin Marinas wrote:
> On Fri, Nov 25, 2016 at 08:45:02PM +0000, Ard Biesheuvel wrote:
> > 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?
>
> Dave knows all the details but a reason is that touching a Neon register
> zeros the upper SVE state in the same vector register. So we can't
> safely save/restore just the Neon part without corrupting the SVE state.
This is right -- this also means that EFI services can trash the upper
bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).
It's overkill to save/restore absolutely everything -- I ignore num_regs
for example -- but I wanted to keep things as simple as possible
initially.
Cheers
---Dave
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Adrian Hunter @ 2016-11-28 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66751ab5-59a4-ec30-07cd-44ca03694723@laposte.net>
On 28/11/16 13:20, Sebastian Frias wrote:
> Hi Adrian,
>
> On 28/11/16 11:30, Adrian Hunter wrote:
>> On 28/11/16 09:32, Michal Simek wrote:
>>> +Sai for Xilinx perspective.
>>>
>>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>>> Hi,
>>>>
>>>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>>>> "Hardware initialized registers"
>>>>
>>>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>>>> AHB Host Controller", revision 6.0 document)
>>>>
>>>> In some platforms those signals are connected to registers that need to
>>>> be programmed at some point for proper driver/HW initialisation.
>>>>
>>>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>>>> that is called from within 'sdhci_pltfm_init', and that seems a good
>>>> candidate for a place to program those registers (*).
>>>>
>>>> Do you agree?
>>
>> We already killed .platform_init
>
> I just saw that, yet it was the perfect place for the HW initialisation I'm
> talking about.
> Any way we can restore it?
It doesn't serve any purpose I am aware of.
>
>>
>> What is wrong with sdhci_arasan_probe()?
>
> Well, in 4.7 sdhci_arasan_probe() did not call of_match_device(), so I had
> put a call to it just before sdhci_pltfm_init(), something like:
>
> +static const struct of_device_id sdhci_arasan_of_match[] = {
> + {
> + .compatible = "arasan,sdhci-8.9a",
> + .data = &sdhci_arasan_ops,
> + },
> + {
> + .compatible = "arasan,sdhci-5.1",
> + .data = &sdhci_arasan_ops,
> + },
> + {
> + .compatible = "arasan,sdhci-4.9a",
> + .data = &sdhci_arasan_ops,
> + },
> + {
> + .compatible = "sigma,smp8734-sdio",
> + .data = &sdhci_arasan_tango4_ops,
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
>
> ...
>
> + const struct of_device_id *match;
> +
> + match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
> + if (match)
> + sdhci_arasan_pdata.ops = match->data;
>
> where 'sdhci_arasan_tango4_ops' contained a pointer to a .platform_init
> callback.
>
> However, as I stated earlier, an upstream commit:
>
> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
> Author: Douglas Anderson <dianders@chromium.org>
> Date: Mon Jun 20 10:56:47 2016 -0700
>
> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>
> changed struct 'sdhci_arasan_of_match' to convey different data, which
> means that instead of having a generic way of accessing such data (such
> as 'of_match_device()' and ".data" field), one must also check for
> specific "compatible" strings to make sense of the ".data" field, such as
> "rockchip,rk3399-sdhci-5.1"
>
> With the current code:
> - there's no 'of_match_device()' before 'sdhci_pltfm_init()'
> - the sdhci_pltfm_init() call is made with a static 'sdhci_arasan_pdata'
> struct (so it cannot be made dependent on the "compatible" string).
> - since 'sdhci_arasan_pdata' is the same for all compatible devices, even
> for those that require special handling, more "compatible" matching code is
> required
> - leading to spread "compatible" matching code; IMHO it would be cleaner if
> the 'sdhci_arasan_probe()' code was generic, with just a generic "compatible"
> matching, which then proceeded with specific initialisation and generic
> initialisation.
>
> In a nutshell, IMHO it would be better if adding support for more SoCs only
> involved changing just 'sdhci_arasan_of_match' without the need to change
> 'sdhci_arasan_probe()'.
> That would clearly separate the generic and "SoC"-specific code, thus allowing
> better maintenance.
>
> Does that makes sense to you guys?
If you want to do that, then why not define your match data with your own
callbacks. e.g. something like
struct sdhci_arasan_of_data {
struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
void (*platform_init)(struct sdhci_arasan_data *sdhci_arasan);
};
struct sdhci_arasan_of_data *data;
data = match->data;
sdhci_arasan->soc_ctl_map = data->soc_ctl_map;
if (data->platform_init)
platform_init(sdhci_arasan);
>
> Best regards,
>
> Sebastian
>
>>
>>>>
>>>> Best regards,
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> (*): This has been prototyped on 4.7 as working properly.
>>>> However, upstream commit:
>>>>
>>>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>>>> Author: Douglas Anderson <dianders@chromium.org>
>>>> Date: Mon Jun 20 10:56:47 2016 -0700
>>>>
>>>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>>>> ...
>>>>
>>>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>>>> struct is used after that commit.
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* [GIT PULL 4/4] DaVinci defconfig updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit a652baa06413a4beacc09425883e518c5f1ed100:
ARM: davinci_all_defconfig: add missing options for systemd (2016-11-15 15:44:52 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/defconfig-3
for you to fetch changes up to 213971e7571e27f47b4e926904a9adf794925c51:
ARM: davinci_all_defconfig: Enable OHCI as module (2016-11-22 20:50:46 +0530)
----------------------------------------------------------------
A patch enabling USB OHCI support in davinci
defconfig.
----------------------------------------------------------------
Axel Haslam (1):
ARM: davinci_all_defconfig: Enable OHCI as module
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL 3/4] DaVinci DT updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 83de086cc89410a8d4e0b6345e8a1116797ea703:
ARM: dts: da850-lcdk: Enable the usb otg device node (2016-11-20 17:02:18 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/dt-3
for you to fetch changes up to 878e908ad95637dc6567a9b5f6876a580ae90dfa:
ARM: dts: da850: enable memctrl and mstpri nodes per board (2016-11-28 15:51:29 +0530)
----------------------------------------------------------------
Some fixes for device-tree patches already queued.
- Fix SD card detect polarity
- Prevent Ethernet from picking a random mac address
- Fix error messages on platforms which dont use
bus master and emif priority settings.
----------------------------------------------------------------
Axel Haslam (1):
ARM: dts: da850-lcdk: fix mmc card detect polarity
Bartosz Golaszewski (1):
ARM: dts: da850: enable memctrl and mstpri nodes per board
Fabien Parent (1):
ARM: dts: da850-lcdk: Add ethernet0 alias to DT
arch/arm/boot/dts/da850-lcdk.dts | 11 ++++++++++-
arch/arm/boot/dts/da850.dtsi | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 7e431af8fa0b9ed9d74378c99514856211cb9db8:
ARM: davinci: PM: support da8xx DT platforms (2016-11-16 14:45:07 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/soc-3
for you to fetch changes up to b5e1438cf98a1c588726b0f861178f9aa5a96caf:
ARM: davinci: da830-evm: use gpio descriptor for mmc pins (2016-11-28 14:01:17 +0530)
----------------------------------------------------------------
mach-davinci SoC support updates to adjust
USB ohci device name to that used by drivers
and update of various board files to use gpio
descriptor API used by MMC subsystem for card
detect and write-protect detection.
----------------------------------------------------------------
Axel Haslam (4):
ARM: davinci: da8xx: Fix ohci device name
ARM: davinci: hawk: use gpio descriptor for mmc pins
ARM: davinci: da850-evm: use gpio descriptor for mmc pins
ARM: davinci: da830-evm: use gpio descriptor for mmc pins
arch/arm/mach-davinci/board-da830-evm.c | 41 ++++++++--------------------
arch/arm/mach-davinci/board-da850-evm.c | 35 +++++++-----------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 42 ++++++++---------------------
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 4 +--
7 files changed, 37 insertions(+), 91 deletions(-)
^ 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