* [PATCH v4 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v3:
* Fixup change log text and no code changes.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23343139/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v4
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.1.445.g3cdd5d1
^ permalink raw reply
* [PATCH v4 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Rongrong Zou @ 2016-10-18 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018074922.GZ20761@phenom.ffwll.local>
Hi Daniel,
Thanks for your review!
? 2016/10/18 15:49, Daniel Vetter ??:
> On Tue, Oct 18, 2016 at 12:01:18PM +0800, Rongrong Zou wrote:
>> Add support for fbdev and framebuffer.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 25 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 25 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 257 ++++++++++++++++++++++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 67 ++++++
>> 5 files changed, 375 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> index d5c40b8..810a37e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -1,5 +1,5 @@
>> ccflags-y := -Iinclude/drm
>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>>
>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>> #obj-y += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index e118f3b..8ddb763 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -66,11 +66,31 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + if (hidev->fbdev.initialized) {
>
> What do you need these checks for? This looks a bit fishy tbh ...
It is delivered from the bochs driver, and I will fix if there are
any problems, Thanks.
>
>> + console_lock();
>> + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 1);
>> + console_unlock();
>
> drm_fb_helper_set_suspend_unlocked is the new fancy one. Please use that
> one instead. Also, that has the check you might need already included,
> which means you can nuke this entire function here and just call it
> directly.
So it should be wrote as:
static int hibmc_pm_suspend(struct device *dev)
{
...
drm_kms_helper_poll_disable(drm_dev);
drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 1);
...
}
static int hibmc_pm_resume(struct device *dev)
{
...
drm_helper_resume_force_mode(drm_dev);
drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 0);
drm_kms_helper_poll_enable(drm_dev);
...
}, is it ?
Regards
Rongrong.
> -Daniel
>
>> + }
>> +
>> return 0;
>> }
>>
>> static int hibmc_pm_resume(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + if (hidev->fbdev.initialized) {
>> + console_lock();
>> + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 0);
>> + console_unlock();
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -170,6 +190,7 @@ static int hibmc_unload(struct drm_device *dev)
>> {
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> + hibmc_fbdev_fini(hidev);
>> hibmc_hw_fini(hidev);
>> dev->dev_private = NULL;
>> return 0;
>> @@ -194,6 +215,10 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
>> if (ret)
>> goto err;
>>
>> + ret = hibmc_fbdev_init(hidev);
>> + if (ret)
>> + goto err;
>> +
>> return 0;
>>
>> err:
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 00bb153..4f5887f 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -20,9 +20,23 @@
>> #define HIBMC_DRM_DRV_H
>>
>> #include <drm/drmP.h>
>> +#include <drm/drm_fb_helper.h>
>> #include <drm/ttm/ttm_bo_driver.h>
>> #include <drm/drm_gem.h>
>>
>> +struct hibmc_framebuffer {
>> + struct drm_framebuffer fb;
>> + struct drm_gem_object *obj;
>> + bool is_fbdev_fb;
>> +};
>> +
>> +struct hibmc_fbdev {
>> + struct drm_fb_helper helper;
>> + struct hibmc_framebuffer fb;
>> + int size;
>> + bool initialized;
>> +};
>> +
>> struct hibmc_drm_device {
>> /* hw */
>> void __iomem *mmio;
>> @@ -41,9 +55,13 @@ struct hibmc_drm_device {
>> bool initialized;
>> } ttm;
>>
>> + /* fbdev */
>> + struct hibmc_fbdev fbdev;
>> bool mm_inited;
>> };
>>
>> +#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
>> +
>> struct hibmc_bo {
>> struct ttm_buffer_object bo;
>> struct ttm_placement placement;
>> @@ -65,8 +83,15 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>>
>> #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
>>
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>> +
>> int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
>> struct drm_gem_object **obj);
>> +int hibmc_framebuffer_init(struct drm_device *dev,
>> + struct hibmc_framebuffer *gfb,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj);
>>
>> int hibmc_mm_init(struct hibmc_drm_device *hibmc);
>> int hibmc_bo_pin(struct hibmc_bo *bo, u32 pl_flag, u64 *gpu_addr);
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> new file mode 100644
>> index 0000000..ea2d86a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> @@ -0,0 +1,257 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include <drm/drm_crtc.h>
>> +#include <drm/drm_crtc_helper.h>
>> +#include <drm/drm_fb_helper.h>
>> +
>> +#include "hibmc_drm_drv.h"
>> +
>> +/* ---------------------------------------------------------------------- */
>> +
>> +static int hibmcfb_create_object(
>> + struct hibmc_drm_device *hidev,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object **gobj_p)
>> +{
>> + struct drm_gem_object *gobj;
>> + struct drm_device *dev = hidev->dev;
>> + u32 size;
>> + int ret = 0;
>> +
>> + size = mode_cmd->pitches[0] * mode_cmd->height;
>> + ret = hibmc_gem_create(dev, size, true, &gobj);
>> + if (ret)
>> + return ret;
>> +
>> + *gobj_p = gobj;
>> + return ret;
>> +}
>> +
>> +static struct fb_ops hibmc_drm_fb_ops = {
>> + .owner = THIS_MODULE,
>> + .fb_check_var = drm_fb_helper_check_var,
>> + .fb_set_par = drm_fb_helper_set_par,
>> + .fb_fillrect = drm_fb_helper_sys_fillrect,
>> + .fb_copyarea = drm_fb_helper_sys_copyarea,
>> + .fb_imageblit = drm_fb_helper_sys_imageblit,
>> + .fb_pan_display = drm_fb_helper_pan_display,
>> + .fb_blank = drm_fb_helper_blank,
>> + .fb_setcmap = drm_fb_helper_setcmap,
>> +};
>> +
>> +static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
>> + struct drm_fb_helper_surface_size *sizes)
>> +{
>> + struct hibmc_fbdev *gfbdev =
>> + container_of(helper, struct hibmc_fbdev, helper);
>> + struct hibmc_drm_device *hidev =
>> + container_of(helper, struct hibmc_drm_device, fbdev.helper);
>> + struct fb_info *info;
>> + struct drm_framebuffer *fb;
>> + struct drm_mode_fb_cmd2 mode_cmd;
>> + struct drm_gem_object *gobj = NULL;
>> + int ret = 0;
>> + size_t size;
>> + unsigned int bytes_per_pixel;
>> + struct hibmc_bo *bo = NULL;
>> +
>> + DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
>> + sizes->surface_width, sizes->surface_height,
>> + sizes->surface_bpp);
>> + sizes->surface_depth = 32;
>> +
>> + bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>> +
>> + mode_cmd.width = sizes->surface_width;
>> + mode_cmd.height = sizes->surface_height;
>> + mode_cmd.pitches[0] = mode_cmd.width * bytes_per_pixel;
>> + mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>> + sizes->surface_depth);
>> +
>> + size = roundup(mode_cmd.pitches[0] * mode_cmd.height, PAGE_SIZE);
>> +
>> + ret = hibmcfb_create_object(hidev, &mode_cmd, &gobj);
>> + if (ret) {
>> + DRM_ERROR("failed to create fbcon backing object %d\r\n", ret);
>> + return -ENOMEM;
>> + }
>> +
>> + bo = gem_to_hibmc_bo(gobj);
>> +
>> + ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
>> + if (ret)
>> + return ret;
>> +
>> + ret = hibmc_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
>> + if (ret) {
>> + DRM_ERROR("failed to pin fbcon\n");
>> + return ret;
>> + }
>> +
>> + ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
>> +
>> + if (ret) {
>> + DRM_ERROR("failed to kmap fbcon\n");
>> + ttm_bo_unreserve(&bo->bo);
>> + return ret;
>> + }
>> +
>> + ttm_bo_unreserve(&bo->bo);
>> +
>> + info = drm_fb_helper_alloc_fbi(helper);
>> + if (IS_ERR(info))
>> + ret = PTR_ERR(info);
>> +
>> + info->par = gfbdev;
>> +
>> + ret = hibmc_framebuffer_init(hidev->dev, &hidev->fbdev.fb,
>> + &mode_cmd, gobj);
>> + if (ret) {
>> + drm_fb_helper_release_fbi(helper);
>> + return ret;
>> + }
>> +
>> + hidev->fbdev.size = size;
>> + fb = &gfbdev->fb.fb;
>> + if (!fb) {
>> + DRM_INFO("fb is NULL\n");
>> + return -EINVAL;
>> + }
>> +
>> + gfbdev->helper.fb = fb;
>> +
>> + strcpy(info->fix.id, "hibmcdrmfb");
>> +
>> + info->flags = FBINFO_DEFAULT;
>> + info->fbops = &hibmc_drm_fb_ops;
>> +
>> + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
>> + drm_fb_helper_fill_var(info, &hidev->fbdev.helper, sizes->fb_width,
>> + sizes->fb_height);
>> +
>> + info->screen_base = bo->kmap.virtual;
>> + info->screen_size = size;
>> +
>> + info->fix.smem_start = bo->bo.mem.bus.offset + bo->bo.mem.bus.base;
>> + info->fix.smem_len = size;
>> +
>> + return 0;
>> +}
>> +
>> +static int hibmc_fbdev_destroy(struct drm_device *dev,
>> + struct hibmc_fbdev *fbdev)
>> +{
>> + struct hibmc_framebuffer *gfb = &fbdev->fb;
>> + struct drm_fb_helper *fbh = &fbdev->helper;
>> +
>> + DRM_DEBUG_DRIVER("hibmc_fbdev_destroy\n");
>> +
>> + drm_fb_helper_unregister_fbi(fbh);
>> + drm_fb_helper_release_fbi(fbh);
>> +
>> + if (gfb->obj) {
>> + drm_gem_object_unreference_unlocked(gfb->obj);
>> + gfb->obj = NULL;
>> + }
>> +
>> + drm_fb_helper_fini(fbh);
>> +
>> + drm_framebuffer_unregister_private(&gfb->fb);
>> + drm_framebuffer_cleanup(&gfb->fb);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct drm_fb_helper_funcs hibmc_fbdev_helper_funcs = {
>> + .fb_probe = hibmc_drm_fb_create,
>> +};
>> +
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev)
>> +{
>> + int ret;
>> + struct fb_var_screeninfo *var;
>> + struct fb_fix_screeninfo *fix;
>> +
>> + drm_fb_helper_prepare(hidev->dev, &hidev->fbdev.helper,
>> + &hibmc_fbdev_helper_funcs);
>> +
>> + /* Now just one crtc and one channel */
>> + ret = drm_fb_helper_init(hidev->dev,
>> + &hidev->fbdev.helper, 1, 1);
>> +
>> + if (ret)
>> + return ret;
>> +
>> + ret = drm_fb_helper_single_add_all_connectors(&hidev->fbdev.helper);
>> + if (ret)
>> + goto fini;
>> +
>> + ret = drm_fb_helper_initial_config(&hidev->fbdev.helper, 16);
>> + if (ret)
>> + goto fini;
>> +
>> + hidev->fbdev.initialized = true;
>> +
>> + var = &hidev->fbdev.helper.fbdev->var;
>> + fix = &hidev->fbdev.helper.fbdev->fix;
>> +
>> + DRM_DEBUG("Member of info->var is :\n"
>> + "xres=%d\n"
>> + "yres=%d\n"
>> + "xres_virtual=%d\n"
>> + "yres_virtual=%d\n"
>> + "xoffset=%d\n"
>> + "yoffset=%d\n"
>> + "bits_per_pixel=%d\n"
>> + "...\n", var->xres, var->yres, var->xres_virtual,
>> + var->yres_virtual, var->xoffset, var->yoffset,
>> + var->bits_per_pixel);
>> + DRM_DEBUG("Member of info->fix is :\n"
>> + "smem_start=%lx\n"
>> + "smem_len=%d\n"
>> + "type=%d\n"
>> + "type_aux=%d\n"
>> + "visual=%d\n"
>> + "xpanstep=%d\n"
>> + "ypanstep=%d\n"
>> + "ywrapstep=%d\n"
>> + "line_length=%d\n"
>> + "accel=%d\n"
>> + "capabilities=%d\n"
>> + "...\n", fix->smem_start, fix->smem_len, fix->type,
>> + fix->type_aux, fix->visual, fix->xpanstep,
>> + fix->ypanstep, fix->ywrapstep, fix->line_length,
>> + fix->accel, fix->capabilities);
>> +
>> + return 0;
>> +
>> +fini:
>> + drm_fb_helper_fini(&hidev->fbdev.helper);
>> + return ret;
>> +}
>> +
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev)
>> +{
>> + if (!hidev->fbdev.initialized)
>> + return;
>> +
>> + hibmc_fbdev_destroy(hidev->dev, &hidev->fbdev);
>> + hidev->fbdev.initialized = false;
>> +}
>> +
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> index 2dbef04..c8f7f6c 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> @@ -489,3 +489,70 @@ int hibmc_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
>> return 0;
>> }
>>
>> +/* ---------------------------------------------------------------------- */
>> +
>> +static void hibmc_user_framebuffer_destroy(struct drm_framebuffer *fb)
>> +{
>> + struct hibmc_framebuffer *hibmc_fb = to_hibmc_framebuffer(fb);
>> +
>> + drm_gem_object_unreference_unlocked(hibmc_fb->obj);
>> + drm_framebuffer_cleanup(fb);
>> + kfree(fb);
>> +}
>> +
>> +static const struct drm_framebuffer_funcs hibmc_fb_funcs = {
>> + .destroy = hibmc_user_framebuffer_destroy,
>> +};
>> +
>> +int hibmc_framebuffer_init(struct drm_device *dev,
>> + struct hibmc_framebuffer *gfb,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj)
>> +{
>> + int ret;
>> +
>> + drm_helper_mode_fill_fb_struct(&gfb->fb, mode_cmd);
>> + gfb->obj = obj;
>> + ret = drm_framebuffer_init(dev, &gfb->fb, &hibmc_fb_funcs);
>> + if (ret) {
>> + DRM_ERROR("drm_framebuffer_init failed: %d\n", ret);
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +
>> +static struct drm_framebuffer *
>> +hibmc_user_framebuffer_create(struct drm_device *dev,
>> + struct drm_file *filp,
>> + const struct drm_mode_fb_cmd2 *mode_cmd)
>> +{
>> + struct drm_gem_object *obj;
>> + struct hibmc_framebuffer *hibmc_fb;
>> + int ret;
>> +
>> + DRM_DEBUG_DRIVER("%dx%d, format %c%c%c%c\n",
>> + mode_cmd->width, mode_cmd->height,
>> + (mode_cmd->pixel_format) & 0xff,
>> + (mode_cmd->pixel_format >> 8) & 0xff,
>> + (mode_cmd->pixel_format >> 16) & 0xff,
>> + (mode_cmd->pixel_format >> 24) & 0xff);
>> +
>> + obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
>> + if (!obj)
>> + return ERR_PTR(-ENOENT);
>> +
>> + hibmc_fb = kzalloc(sizeof(*hibmc_fb), GFP_KERNEL);
>> + if (!hibmc_fb) {
>> + drm_gem_object_unreference_unlocked(obj);
>> + return ERR_PTR(-ENOMEM);
>> + }
>> +
>> + ret = hibmc_framebuffer_init(dev, hibmc_fb, mode_cmd, obj);
>> + if (ret) {
>> + drm_gem_object_unreference_unlocked(obj);
>> + kfree(hibmc_fb);
>> + return ERR_PTR(ret);
>> + }
>> + return &hibmc_fb->fb;
>> +}
>> +
>> --
>> 1.9.1
>>
>
^ permalink raw reply
* [PATCH] arm64: Cortex-A53 errata workaround: check for kernel addresses
From: Andre Przywara @ 2016-10-18 11:16 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an access_ok() check before executing the
instructions on behalf of userland, taking care of tagged pointers on
the way.
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Cc: <stable@vger.kernel.org> # 4.8.x
---
arch/arm64/include/asm/uaccess.h | 4 ++++
arch/arm64/kernel/traps.c | 32 ++++++++++++++++++++++++++++----
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bcaf6fb..f842b47 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -21,6 +21,7 @@
/*
* User space memory access functions
*/
+#include <linux/bitops.h>
#include <linux/kasan-checks.h>
#include <linux/string.h>
#include <linux/thread_info.h>
@@ -103,6 +104,9 @@ static inline void set_fs(mm_segment_t fs)
})
#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok_tagged(type, addr, size) access_ok(type, \
+ sign_extend64(addr, 55), \
+ size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f..04ea0d7 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -447,6 +447,30 @@ void cpu_enable_cache_maint_trap(void *__unused)
: "=r" (res) \
: "r" (address), "i" (-EFAULT) )
+enum {USER_CACHE_MAINT_DC_CIVAC, USER_CACHE_MAINT_IC_IVAU};
+
+static int do_user_cache_maint(int ins_type, unsigned long address)
+{
+ int ret;
+ unsigned long cl_size = cache_line_size();
+
+ if (!access_ok_tagged(VERIFY_READ,
+ round_down(address, cl_size),
+ cl_size))
+ return -EFAULT;
+
+ switch (ins_type) {
+ case USER_CACHE_MAINT_DC_CIVAC:
+ __user_cache_maint("dc civac", address, ret);
+ break;
+ case USER_CACHE_MAINT_IC_IVAU:
+ __user_cache_maint("ic ivau", address, ret);
+ break;
+ }
+
+ return ret;
+}
+
static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
{
unsigned long address;
@@ -458,16 +482,16 @@ static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
switch (crm) {
case ESR_ELx_SYS64_ISS_CRM_DC_CVAU: /* DC CVAU, gets promoted */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_DC_CVAC: /* DC CVAC, gets promoted */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_DC_CIVAC: /* DC CIVAC */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_IC_IVAU: /* IC IVAU */
- __user_cache_maint("ic ivau", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_IC_IVAU, address);
break;
default:
force_signal_inject(SIGILL, ILL_ILLOPC, regs, 0);
--
2.9.0
^ permalink raw reply related
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Daniel Golle @ 2016-10-18 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018090927.1990-1-narmstrong@baylibre.com>
Hi Neil,
great to see progress towards supporting OX820!
The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
looks very similar, see
https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
To me therefore this looks quite good, just one small question below.
Cheers
Daniel
On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> This is a simple memory mapped NAND controller with single chip select and
> software ECC.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
> drivers/mtd/nand/Kconfig | 5 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> 4 files changed, 174 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>
> diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> new file mode 100644
> index 0000000..83b684d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> @@ -0,0 +1,24 @@
> +* Oxford Semiconductor OXNAS NAND Controller
> +
> +Please refer to nand.txt for generic information regarding MTD NAND bindings.
> +
> +Required properties:
> + - compatible: "oxsemi,ox820-nand"
> + - reg: Base address and length for NAND mapped memory.
> +
> +Optional Properties:
> + - clocks: phandle to the NAND gate clock if needed.
> + - resets: phandle to the NAND reset control if needed.
> +
> +Example:
> +
> +nand: nand at 41000000 {
> + compatible = "oxsemi,ox820-nand";
> + reg = <0x41000000 0x100000>;
> + nand-ecc-mode = "soft";
> + clocks = <&stdclk CLK_820_NAND>;
> + resets = <&reset RESET_NAND>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + status = "disabled";
> +};
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 7b7a887..c023125 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -426,6 +426,11 @@ config MTD_NAND_ORION
> No board specific support is done by this driver, each board
> must advertise a platform_device for the driver to attach.
>
> +config MTD_NAND_OXNAS
> + tristate "NAND Flash support for Oxford Semiconductor SoC"
> + help
> + This enables the NAND flash controller on Oxford Semiconductor SoCs.
> +
> config MTD_NAND_FSL_ELBC
> tristate "NAND support for Freescale eLBC controllers"
> depends on FSL_SOC
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index cafde6f..05fc054 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o
> obj-$(CONFIG_MTD_NAND_PLATFORM) += plat_nand.o
> obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
> obj-$(CONFIG_MTD_NAND_ORION) += orion_nand.o
> +obj-$(CONFIG_MTD_NAND_OXNAS) += oxnas_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_ELBC) += fsl_elbc_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_IFC) += fsl_ifc_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_UPM) += fsl_upm.o
> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
> new file mode 100644
> index 0000000..ee402ab
> --- /dev/null
> +++ b/drivers/mtd/nand/oxnas_nand.c
> @@ -0,0 +1,144 @@
> +/*
> + * Oxford Semiconductor OXNAS NAND driver
> + *
> + * Heavily based on plat_nand.c :
> + * Author: Vitaly Wool <vitalywool@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mtd/partitions.h>
> +
> +/* nand commands */
> +#define NAND_CMD_ALE BIT(18)
> +#define NAND_CMD_CLE BIT(19)
> +#define NAND_CMD_CS 0
> +#define NAND_CMD_RESET 0xff
> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
> +#define NAND_DATA (NAND_CMD_CS)
> +
> +struct oxnas_nand_data {
> + struct nand_chip chip;
> + void __iomem *io_base;
Why do you redundantly keep io_base in platform data rather than
just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
> + struct clk *clk;
> +};
> +
> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
> + unsigned int ctrl)
> +{
> + struct nand_chip *this = mtd->priv;
> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
> +
> + if (ctrl & NAND_CTRL_CHANGE) {
> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
> + if (ctrl & NAND_CLE)
> + nandaddr |= NAND_CMD;
> + else if (ctrl & NAND_ALE)
> + nandaddr |= NAND_ADDR;
> + this->IO_ADDR_W = (void __iomem *) nandaddr;
> + }
> +
> + if (cmd != NAND_CMD_NONE)
> + writeb(cmd, (void __iomem *) nandaddr);
> +}
> +
> +/*
> + * Probe for the NAND device.
> + */
> +static int oxnas_nand_probe(struct platform_device *pdev)
> +{
> + struct oxnas_nand_data *data;
> + struct mtd_info *mtd;
> + struct resource *res;
> + int err = 0;
> +
> + /* Allocate memory for the device structure (and zero it) */
> + data = devm_kzalloc(&pdev->dev, sizeof(struct oxnas_nand_data),
> + GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->io_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->io_base))
> + return PTR_ERR(data->io_base);
> +
> + data->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(data->clk))
> + data->clk = NULL;
> +
> + nand_set_flash_node(&data->chip, pdev->dev.of_node);
> + mtd = nand_to_mtd(&data->chip);
> + mtd->dev.parent = &pdev->dev;
> + mtd->priv = &data->chip;
> +
> + data->chip.IO_ADDR_R = data->io_base;
> + data->chip.IO_ADDR_W = data->io_base;
> + data->chip.cmd_ctrl = oxnas_nand_cmd_ctrl;
> + data->chip.chip_delay = 30;
> + data->chip.ecc.mode = NAND_ECC_SOFT;
> + data->chip.ecc.algo = NAND_ECC_HAMMING;
> +
> + platform_set_drvdata(pdev, data);
> +
> + clk_prepare_enable(data->clk);
> + device_reset_optional(&pdev->dev);
> +
> + /* Scan to find existence of the device */
> + if (nand_scan(mtd, 1)) {
> + err = -ENXIO;
> + goto out;
> + }
> +
> + err = mtd_device_parse_register(mtd, NULL, NULL, NULL, 0);
> + if (!err)
> + return err;
> +
> + nand_release(mtd);
> +out:
> + return err;
> +}
> +
> +static int oxnas_nand_remove(struct platform_device *pdev)
> +{
> + struct oxnas_nand_data *data = platform_get_drvdata(pdev);
> +
> + nand_release(nand_to_mtd(&data->chip));
> +
> + return 0;
> +}
> +
> +static const struct of_device_id oxnas_nand_match[] = {
> + { .compatible = "oxsemi,ox820-nand" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, oxnas_nand_match);
> +
> +static struct platform_driver oxnas_nand_driver = {
> + .probe = oxnas_nand_probe,
> + .remove = oxnas_nand_remove,
> + .driver = {
> + .name = "oxnas_nand",
> + .of_match_table = oxnas_nand_match,
> + },
> +};
> +
> +module_platform_driver(oxnas_nand_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Vitaly Wool");
> +MODULE_DESCRIPTION("Oxnas NAND driver");
> +MODULE_ALIAS("platform:oxnas_nand");
> --
> 2.7.0
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Sudeep Holla @ 2016-10-18 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018104539.GB15639@leverpostej>
On 18/10/16 11:45, Mark Rutland wrote:
> On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
>>>> b. in arm64, if some platform has its own suspend flow, couldn't it
>>>> adopts arm/match-xxx to register its own global suspend method?
>>>
>>> No, PSCI is highly recommended.
>>
>> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
>> that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
>> for example) -- feel free to copy that code from arm32.
>
> Quite frankly, copying hundreds of lines of board-specific code
> (including assembly that won't compile) is unlikely to help.
>
> So far arm64 requires well-defined, standard, reusable interfaces (e.g.
> PSCI). That cleanly separates concerns (e.g. anyone can implement the
> backend without mandatory changes to the kernel), and keeps things
> maintainable.
>
> ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> can use and build atop of. It's open source (three-clause BSD with DCO),
> and accepts board ports. You can have a completely open stack,
> regardless of whether part of that stack is firmware.
>
I think you missed to add the link[1]
--
Regards,
Sudeep
[1] https://github.com/ARM-software/arm-trusted-firmware
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On 11 October 2016 at 19:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm. This is due
> to the fact that the key schedules are incompatible between generic AES and the
> arm64 Crypto Extensions implementation (but only when building for big endian)
> This is not a problem in practice, but it does mean that the AES-CCM and AES in
> EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
> one that is compatible with the generic AES key schedule generation code (which
> it currently no longer uses)
>
> In any case, please apply with cc to stable.
>
Ping?
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
>
> arch/arm/crypto/aes-ce-glue.c | 5 ++
> arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
> arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
> arch/arm64/crypto/aes-ce.S | 1 +
> arch/arm64/crypto/aes-modes.S | 3 +-
> arch/arm64/crypto/aes-neon.S | 25 +++++----
> arch/arm64/crypto/ghash-ce-core.S | 6 +--
> arch/arm64/crypto/sha1-ce-core.S | 4 +-
> arch/arm64/crypto/sha2-ce-core.S | 4 +-
> 9 files changed, 72 insertions(+), 54 deletions(-)
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 5/5] crypto: arm/sha2-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/sha2-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..df4dcef054ae 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -11,6 +11,7 @@
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
#include <crypto/sha256_base.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -100,8 +101,6 @@ static struct shash_alg algs[] = { {
static int __init sha2_ce_mod_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_SHA2))
- return -ENODEV;
return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
@@ -110,5 +109,5 @@ static void __exit sha2_ce_mod_fini(void)
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
-module_init(sha2_ce_mod_init);
+module_cpu_feature_match(SHA2, sha2_ce_mod_init);
module_exit(sha2_ce_mod_fini);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] crypto: arm/sha1-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/sha1-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/sha1-ce-glue.c b/arch/arm/crypto/sha1-ce-glue.c
index 80bc2fcd241a..555f72b5e659 100644
--- a/arch/arm/crypto/sha1-ce-glue.c
+++ b/arch/arm/crypto/sha1-ce-glue.c
@@ -11,6 +11,7 @@
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
#include <crypto/sha1_base.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -82,8 +83,6 @@ static struct shash_alg alg = {
static int __init sha1_ce_mod_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_SHA1))
- return -ENODEV;
return crypto_register_shash(&alg);
}
@@ -92,5 +91,5 @@ static void __exit sha1_ce_mod_fini(void)
crypto_unregister_shash(&alg);
}
-module_init(sha1_ce_mod_init);
+module_cpu_feature_match(SHA1, sha1_ce_mod_init);
module_exit(sha1_ce_mod_fini);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] crypto: arm/ghash-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/ghash-ce-glue.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index 7546b3c02466..6bac8bea9f1e 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -15,6 +15,7 @@
#include <crypto/cryptd.h>
#include <crypto/internal/hash.h>
#include <crypto/gf128mul.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -311,9 +312,6 @@ static int __init ghash_ce_mod_init(void)
{
int err;
- if (!(elf_hwcap2 & HWCAP2_PMULL))
- return -ENODEV;
-
err = crypto_register_shash(&ghash_alg);
if (err)
return err;
@@ -334,5 +332,5 @@ static void __exit ghash_ce_mod_exit(void)
crypto_unregister_shash(&ghash_alg);
}
-module_init(ghash_ce_mod_init);
+module_cpu_feature_match(PMULL, ghash_ce_mod_init);
module_exit(ghash_ce_mod_exit);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] crypto: arm/aes-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index aef022a87c53..5b1af6f8b2b5 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -14,6 +14,7 @@
#include <crypto/aes.h>
#include <crypto/ablk_helper.h>
#include <crypto/algapi.h>
+#include <linux/cpufeature.h>
#include <linux/module.h>
#include <crypto/xts.h>
@@ -515,8 +516,6 @@ static struct crypto_alg aes_algs[] = { {
static int __init aes_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_AES))
- return -ENODEV;
return crypto_register_algs(aes_algs, ARRAY_SIZE(aes_algs));
}
@@ -525,5 +524,5 @@ static void __exit aes_exit(void)
crypto_unregister_algs(aes_algs, ARRAY_SIZE(aes_algs));
}
-module_init(aes_init);
+module_cpu_feature_match(AES, aes_init);
module_exit(aes_exit);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..1a0c6a486a9c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -21,6 +21,7 @@ config ARM
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+ select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
new file mode 100644
index 000000000000..19c3dddd901a
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/hwcap.h>
+
+/*
+ * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
+ * of optional CPU features it defines, ARM's CPU capability bits have been
+ * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
+ * covers a subset of the available CPU features.
+ *
+ * Currently, only a few of those are suitable for automatic module loading
+ * (which is the primary use case of this facility) and those happen to be all
+ * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
+ */
+#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
+#define cpu_feature(x) ilog2(HWCAP2_ ## x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ return elf_hwcap2 & (1UL << num);
+}
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] ARM: add module autoloading support for crypto modules
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
This series wires up the crypto modules that use the ARM 32-bit versions of
the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
feature bits via the CPU modalias. This is very similar to the arm64
implementation, with the notable exception that ARM has its CPU feature
definitions split across HWCAP and HWCAP2.
Given that the crypto feature bits are all exposed via HWCAP2, and considering
that there are currently no features exposed via HWCAP that are relevant to
udev module autoloading, exposing HWCAP2 only should be sufficient, at least
for now.
Note to Herbert: patches #2 - #5 all depend on #1, which requires an ack from
Russell, so please don't pull anything until #1 has been acked and/or merged.
Ard Biesheuvel (5):
ARM: wire up HWCAP2 feature bits to the CPU modalias
crypto: arm/aes-ce - enable module autoloading based on CPU feature
bits
crypto: arm/ghash-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha1-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha2-ce - enable module autoloading based on CPU feature
bits
arch/arm/Kconfig | 1 +
arch/arm/crypto/aes-ce-glue.c | 5 ++-
arch/arm/crypto/ghash-ce-glue.c | 6 ++--
arch/arm/crypto/sha1-ce-glue.c | 5 ++-
arch/arm/crypto/sha2-ce-glue.c | 5 ++-
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
6 files changed, 41 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/include/asm/cpufeature.h
--
2.7.4
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-10-18 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
On 21 September 2016 at 08:57, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++++++
> drivers/clk/clk-qoriq.c | 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257 +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++----
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h | 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
> rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>
This looks good to me! I am not sure which tree you want this to be
picked up through, but unless no other volunteers I can take it
through my mmc tree.
Although, before considering to apply, I need an ack from Scott/Arnd
for the guts driver in patch 5/8 and I need an ack from Greg for patch
7/8, where the soc_device_match() interface is added (seems like you
didn't add him on cc/to).
Kind regards
Uffe
^ permalink raw reply
* [PATCH V2 3/4] ACPI,PCI,IRQ: separate ISA penalty calculation
From: Bjorn Helgaas @ 2016-10-18 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467188859-28188-4-git-send-email-okaya@codeaurora.org>
Hi Sinan,
On Wed, Jun 29, 2016 at 04:27:37AM -0400, Sinan Kaya wrote:
> Since commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> the penalty values are calculated on the fly rather than boot time.
>
> This works fine for PCI interrupts but not so well for the ISA interrupts.
> Whether an ISA interrupt is in use or not information is not available
> inside the pci_link.c file. This information gets sent externally via
> acpi_penalize_isa_irq function. If active is true, then the IRQ is in use
> by ISA. Otherwise, IRQ is in use by PCI.
>
> Since the current code relies on PCI Link object for determination of
> penalties, we are factoring in the PCI penalty twice after
> acpi_penalize_isa_irq function is called.
I know this patch has already been merged, but I'm confused.
Can you be a little more specific about how we factor in the PCI
penalty twice? I think that when we enumerate an enabled link device,
we call acpi_penalize_isa_irq(x) in this path:
pnpacpi_allocated_resource
pnpacpi_add_irqresource
pcibios_penalize_isa_irq
acpi_penalize_isa_irq
acpi_isa_irq_penalty[x] = PIRQ_PENALTY_ISA_USED
And I see that acpi_irq_penalty_init() also adds in some penalty
(either "PIRQ_PENALTY_PCI_POSSIBLE / possible_count" or
PIRQ_PENALTY_PCI_POSSIBLE). And when we call acpi_irq_get_penalty(x),
we add in PIRQ_PENALTY_PCI_USING.
It doesn't seem right to me that we're adding both
PIRQ_PENALTY_ISA_USED and PIRQ_PENALTY_PCI_USING. Is that the problem
you're referring to?
> This change is limiting the newly added functionality to just PCI
> interrupts so that old behavior is still maintained.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 714ba4d..8c08971 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -496,9 +496,6 @@ static int acpi_irq_get_penalty(int irq)
> {
> int penalty = 0;
>
> - if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> -
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> @@ -513,6 +510,9 @@ static int acpi_irq_get_penalty(int irq)
> penalty += PIRQ_PENALTY_PCI_USING;
> }
>
> + if (irq < ACPI_MAX_ISA_IRQS)
> + return penalty + acpi_isa_irq_penalty[irq];
> +
> penalty += acpi_irq_pci_sharing_penalty(irq);
> return penalty;
I don't understand what's going on here.
acpi_irq_pci_sharing_penalty(X) basically tells us how many link
devices are already using IRQ X. This change makes it so we don't
consider that information if X < ACPI_MAX_ISA_IRQS.
Let's say we have several link devices that are initially disabled,
e.g.,
LNKA (IRQs 9 10 11)
LNKB (IRQs 9 10 11)
LNKC (IRQs 9 10 11)
When we enable these, I think we'll choose the same IRQ for all of
them because we no longer look@the other links to see how they're
configured.
> }
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Mark Rutland @ 2016-10-18 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > >adopts arm/match-xxx to register its own global suspend method?
> >
> > No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
> that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
> for example) -- feel free to copy that code from arm32.
Quite frankly, copying hundreds of lines of board-specific code
(including assembly that won't compile) is unlikely to help.
So far arm64 requires well-defined, standard, reusable interfaces (e.g.
PSCI). That cleanly separates concerns (e.g. anyone can implement the
backend without mandatory changes to the kernel), and keeps things
maintainable.
ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
can use and build atop of. It's open source (three-clause BSD with DCO),
and accepts board ports. You can have a completely open stack,
regardless of whether part of that stack is firmware.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
From: Vladimir Murzin @ 2016-10-18 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b698799-6c7a-d20a-6e54-ddd9eb329369@arm.com>
On 17/10/16 17:51, Sudeep Holla wrote:
>
>
> On 17/10/16 12:47, Vladimir Murzin wrote:
>> Removale of skeleton.dtsi allows us also to fix the following
>> warning from the dts compiler:
>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>>
>> by adding proper unit addresses to the memory nodes.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>
> It's always better to cc device-tree list, anyways applied this to [1].
Thanks!
Vladimir
>
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* [PATCH] ARM: dts: realview: Extend PBX family memory description
From: Robin Murphy @ 2016-10-18 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018102550.GM1041@n2100.armlinux.org.uk>
On 18/10/16 11:25, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 10:21:13AM +0200, Linus Walleij wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> All three platforms sharing the later RealView Platform Baseboard memory
>> map - PBX-A9, PB-A8 and PB11MPCore, provide 512MB of DDR SDRAM on the
>> baseboard, of which the boot alias at 0x0 maps the first 256MB. Expand
>> the size of the default memory node to reflect that, and describe the
>> full memory regions in each board's DTS, but leave those commented by
>> default to avoid breaking existing bootloaders.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ARM SoC folks: I forgot to send this patch for ARM SoC earlier.
>> As it is a small change I suggest you just apply it to the ARM
>> SoC tree as I do not foresee any other RealView work in the near
>> future. If you think it can go into v4.9 then put it in as a fix,
>> else just push it to the next merge window.
>> Robin: sorry for screwing up :(
>
> Normally, memory nodes describe different regions of unique memory.
> This is not unique memory, but is an alias of some already-described
> memory.
Well, really, this is _the_ memory, and the 256MB at 0 is the alias, but
only the separate PB11MPCore DTS has the luxury of being correct from
the off, thanks to the precedent of the QEMU PB-A8 model being popular
and expecting to use the low alias.
> The problem with adding the aliased memory addresses is that we end
> up needing platform knowledge to reject the "other alias" from the
> memory description, which really isn't good.
>
> The only reason it works is that we reject memory nodes where the
> physical address < PHYS_OFFSET. That works provided the alias is
> below PHYS_OFFSET, but that isn't always the case.
Look again ;) It works perfectly because whilst the information is in
the DTS for completeness, as-is it's not in the DTB that the kernel
gets. And if someone _does_ adjust their kernel load address and
uncomment the .dts node accordingly, the "reg" property from the .dtsi
node gets overridden, not added to, so it's still fine.
Robin.
>
> So, I think it is completely wrong to describe the aliased memory
> regions in DT.
>
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Lorenzo Pieralisi @ 2016-10-18 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> Hi!
>
> > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > >adopts arm/match-xxx to register its own global suspend method?
> > >
> >
> > No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not
> repeat that mistake. arm32 has better powermanagement than x86 ever
> will (see Nokia N900 for example) -- feel free to copy that code from
> arm32.
Yes sure, feel free to copy my:
NACKed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
to all the resulting patches then. On ARM64 if he wants to implement
suspend-to-RAM his PSCI firmware will have to implement PSCI system
suspend method, end of this discussion.
By the way, why are you advising people on this subject ?
What do you know about the PSCI firmware interface to state what
you are saying above ?
Lorenzo
^ permalink raw reply
* [PATCH 3/3] arm64: suspend: Reconfigure PSTATE after resume from idle
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-1-git-send-email-james.morse@arm.com>
The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not
save/restore PSTATE. As a result of this cpufeatures that were detected
and have bits in PSTATE get lost when we resume from idle.
UAO gets set appropriately on the next context switch. PAN will be
re-enabled next time we return from user-space, but on a preemptible
kernel we may run work accessing user space before this point.
Add code to re-enable theses two features in __cpu_suspend_exit().
We re-use uao_thread_switch() passing current.
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
This patch applies to linux-stable v4.7.8, but with some fuzz...
but 'git am' rejects it.
asm/exec.h is my best guess at the appropriate header file. Contradictions
welcome.
arch/arm64/include/asm/exec.h | 3 +++
arch/arm64/kernel/process.c | 3 ++-
arch/arm64/kernel/suspend.c | 11 +++++++++++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/exec.h b/arch/arm64/include/asm/exec.h
index db0563c23482..f7865dd9d868 100644
--- a/arch/arm64/include/asm/exec.h
+++ b/arch/arm64/include/asm/exec.h
@@ -18,6 +18,9 @@
#ifndef __ASM_EXEC_H
#define __ASM_EXEC_H
+#include <linux/sched.h>
+
extern unsigned long arch_align_stack(unsigned long sp);
+void uao_thread_switch(struct task_struct *next);
#endif /* __ASM_EXEC_H */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 27b2f1387df4..4f186c56c5eb 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -49,6 +49,7 @@
#include <asm/alternative.h>
#include <asm/compat.h>
#include <asm/cacheflush.h>
+#include <asm/exec.h>
#include <asm/fpsimd.h>
#include <asm/mmu_context.h>
#include <asm/processor.h>
@@ -301,7 +302,7 @@ static void tls_thread_switch(struct task_struct *next)
}
/* Restore the UAO state depending on next's addr_limit */
-static void uao_thread_switch(struct task_struct *next)
+void uao_thread_switch(struct task_struct *next)
{
if (IS_ENABLED(CONFIG_ARM64_UAO)) {
if (task_thread_info(next)->addr_limit == KERNEL_DS)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index ad734142070d..bb0cd787a9d3 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -1,8 +1,11 @@
#include <linux/ftrace.h>
#include <linux/percpu.h>
#include <linux/slab.h>
+#include <asm/alternative.h>
#include <asm/cacheflush.h>
+#include <asm/cpufeature.h>
#include <asm/debug-monitors.h>
+#include <asm/exec.h>
#include <asm/pgtable.h>
#include <asm/memory.h>
#include <asm/mmu_context.h>
@@ -50,6 +53,14 @@ void notrace __cpu_suspend_exit(void)
set_my_cpu_offset(per_cpu_offset(cpu));
/*
+ * PSTATE was not saved over suspend/resume, re-enable any detected
+ * features that might not have been set correctly.
+ */
+ asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,
+ CONFIG_ARM64_PAN));
+ uao_thread_switch(current);
+
+ /*
* Restore HW breakpoint registers to sane values
* before debug exceptions are possibly reenabled
* through local_dbg_restore.
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH 2/3] arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-1-git-send-email-james.morse@arm.com>
Commit 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access
Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
This means the PSTATE.PAN bit won't be set until the next return to the
kernel from userspace. On a preemptible kernel we may schedule work that
accesses userspace on a CPU before it has done this.
Now that cpufeature enable() calls are scheduled via stop_machine(), we
can set PSTATE.PAN from the cpu_enable_pan() call.
Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
is not immediately discarded.
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
This patch depends on 'arm64: cpufeature: Schedule enable() calls instead
of calling them via IPI', which doesn't apply to linux-stable versions
before v4.8.
arch/arm64/mm/fault.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 3e9ff9b0c78d..f942ab6cc206 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -29,7 +29,9 @@
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/perf_event.h>
+#include <linux/preempt.h>
+#include <asm/bug.h>
#include <asm/cpufeature.h>
#include <asm/exception.h>
#include <asm/debug-monitors.h>
@@ -672,7 +674,14 @@ NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
int cpu_enable_pan(void *__unused)
{
+ /*
+ * We modify PSTATE. This won't work from irq context as the PSTATE
+ * is discared once we return from the exception.
+ */
+ WARN_ON_ONCE(in_interrupt());
+
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ asm(SET_PSTATE_PAN(1));
return 0;
}
#endif /* CONFIG_ARM64_PAN */
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH 1/3] arm64: cpufeature: Schedule enable() calls instead of calling them via IPI
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-1-git-send-email-james.morse@arm.com>
The enable() call for a cpufeature/errata is called using on_each_cpu().
This issues a cross-call IPI to get the work done. Implicitly, this
stashes the running PSTATE in SPSR when the CPU receives the IPI, and
restores it when we return. This means an enable() call can never modify
PSTATE.
To allow PAN to do this, change the on_each_cpu() call to use
stop_machine(). This schedules the work on each CPU which allows
us to modify PSTATE.
This involves changing the protype of all the enable() functions.
enable_cpu_capabilities() is called during boot and enables the feature
on all online CPUs. This path now uses stop_machine(). CPU features for
hotplug'd CPUs are enabled by verify_local_cpu_features() which only
acts on the local CPU, and can already modify the running PSTATE as it
is called from secondary_start_kernel().
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
---
The UAO enable call also suffers from this problem, but it is useless
and broken. After this patch it is merely useless, and will be removed,
by a later patch, (replaced with a comment describing what actually
happens).
This patch doesn't apply to linux-stable versions before v4.8 because
it conflicts with every feature introduced since v4.4. If you want this
in stable give me a kick and I will produce versions for v4.4.25 and
v4.7.8 (stable versions since v4.3 when PAN was introduced).
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/processor.h | 6 +++---
arch/arm64/kernel/cpu_errata.c | 3 ++-
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/traps.c | 3 ++-
arch/arm64/mm/fault.c | 6 ++++--
6 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 758d74fedfad..a27c3245ba21 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -94,7 +94,7 @@ struct arm64_cpu_capabilities {
u16 capability;
int def_scope; /* default scope */
bool (*matches)(const struct arm64_cpu_capabilities *caps, int scope);
- void (*enable)(void *); /* Called on all active CPUs */
+ int (*enable)(void *); /* Called on all active CPUs */
union {
struct { /* To be used for erratum handling only */
u32 midr_model;
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index df2e53d3a969..60e34824e18c 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -188,8 +188,8 @@ static inline void spin_lock_prefetch(const void *ptr)
#endif
-void cpu_enable_pan(void *__unused);
-void cpu_enable_uao(void *__unused);
-void cpu_enable_cache_maint_trap(void *__unused);
+int cpu_enable_pan(void *__unused);
+int cpu_enable_uao(void *__unused);
+int cpu_enable_cache_maint_trap(void *__unused);
#endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0150394f4cab..b75e917aac46 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -39,10 +39,11 @@ has_mismatched_cache_line_size(const struct arm64_cpu_capabilities *entry,
(arm64_ftr_reg_ctrel0.sys_val & arm64_ftr_reg_ctrel0.strict_mask);
}
-static void cpu_enable_trap_ctr_access(void *__unused)
+static int cpu_enable_trap_ctr_access(void *__unused)
{
/* Clear SCTLR_EL1.UCT */
config_sctlr_el1(SCTLR_EL1_UCT, 0);
+ return 0;
}
#define MIDR_RANGE(model, min, max) \
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d577f263cc4a..c02504ea304b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -19,7 +19,9 @@
#define pr_fmt(fmt) "CPU features: " fmt
#include <linux/bsearch.h>
+#include <linux/cpumask.h>
#include <linux/sort.h>
+#include <linux/stop_machine.h>
#include <linux/types.h>
#include <asm/cpu.h>
#include <asm/cpufeature.h>
@@ -941,7 +943,13 @@ void __init enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
{
for (; caps->matches; caps++)
if (caps->enable && cpus_have_cap(caps->capability))
- on_each_cpu(caps->enable, NULL, true);
+ /*
+ * Use stop_machine() as it schedules the work allowing
+ * us to modify PSTATE, instead of on_each_cpu() which
+ * uses an IPI, giving us a PSTATE that disappears when
+ * we return.
+ */
+ stop_machine(caps->enable, NULL, cpu_online_mask);
}
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f8fb7f..e3a9f8da16e5 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -428,9 +428,10 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
force_signal_inject(SIGILL, ILL_ILLOPC, regs, 0);
}
-void cpu_enable_cache_maint_trap(void *__unused)
+int cpu_enable_cache_maint_trap(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_UCI, 0);
+ return 0;
}
#define __user_cache_maint(insn, address, res) \
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 53d9159662fe..3e9ff9b0c78d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -670,9 +670,10 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
-void cpu_enable_pan(void *__unused)
+int cpu_enable_pan(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ return 0;
}
#endif /* CONFIG_ARM64_PAN */
@@ -683,8 +684,9 @@ void cpu_enable_pan(void *__unused)
* We need to enable the feature at runtime (instead of adding it to
* PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
*/
-void cpu_enable_uao(void *__unused)
+int cpu_enable_uao(void *__unused)
{
asm(SET_PSTATE_UAO(1));
+ return 0;
}
#endif /* CONFIG_ARM64_UAO */
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH 0/3] PAN Fixes
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This series fixes two issues for PAN discovered by Vladimir and Tony:
* Patch 2 changes the cpu_enable_pan() to not only enable the automatic
PAN setting when return to the kernel from userspace, but also turn
it on right now. This covers the case where a pre-empted task may be
migrated to a new CPU that hasn't yet done a return-to-user.
* Patch 1 is a prerequisite which fixes the enable() calls to not use
an IPI, (details in the patch). This means we can modify PSTATE from
an enable call, which is broken today, but we don't actually depend
on it...
Patch 3 fixes a third issue where we lose the PSTATE value over cpu-idle,
this will be a problem in the same pre-empted task migrated to a
'new' CPU case above, and if we return from idle to a user task, (which
I believe suspend-to-ram does).
Patch 1 changes the prototype of all the enable calls, so can't be
backported. I will produce separate backports for v4.4.25 and v4.7.8.
Based on v4.9-rc1, with [0] applied locally to fix cpuhotplug. This
series can be retrieved from:
Thanks,
James
[0] https://www.spinics.net/lists/kernel/msg2357812.html
James Morse (3):
arm64: cpufeature: Schedule enable() calls instead of calling them via
IPI
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
arm64: suspend: Reconfigure PSTATE after resume from idle
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/exec.h | 3 +++
arch/arm64/include/asm/processor.h | 6 +++---
arch/arm64/kernel/cpu_errata.c | 3 ++-
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/process.c | 3 ++-
arch/arm64/kernel/suspend.c | 11 +++++++++++
arch/arm64/kernel/traps.c | 3 ++-
arch/arm64/mm/fault.c | 15 +++++++++++++--
9 files changed, 46 insertions(+), 10 deletions(-)
--
2.8.0.rc3
^ permalink raw reply
* [PATCH 3/3] arm64: dts: Update Broadcom NS2 to generic IOMMU binding
From: Robin Murphy @ 2016-10-18 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <77abd968-f412-a118-5b19-5faf539f33be@gmail.com>
On 18/10/16 01:58, Florian Fainelli wrote:
> On 10/17/2016 05:13 AM, Robin Murphy wrote:
>> With the "mmu-masters" property now deprecated and optional, the
>> generic binding offers a more efficient way to specify no masters.
>>
>> CC: Ray Jui <rjui@broadcom.com>
>> CC: Scott Branden <sbranden@broadcom.com>
>> CC: Jon Mason <jonmason@broadcom.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> Applied, did you use get_maintainers.pl for this file? It did not land
> in bcm-kernel-feedback-list at broadcom.com and as such did not get picked
> by the patchwork instance behind..
Oops, sorry! I somehow managed to overlook that - I'll try paying closer
attention in future :)
Thanks,
Robin.
^ permalink raw reply
* [PATCH] ARM: dts: realview: Extend PBX family memory description
From: Russell King - ARM Linux @ 2016-10-18 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476778873-12210-1-git-send-email-linus.walleij@linaro.org>
On Tue, Oct 18, 2016 at 10:21:13AM +0200, Linus Walleij wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> All three platforms sharing the later RealView Platform Baseboard memory
> map - PBX-A9, PB-A8 and PB11MPCore, provide 512MB of DDR SDRAM on the
> baseboard, of which the boot alias at 0x0 maps the first 256MB. Expand
> the size of the default memory node to reflect that, and describe the
> full memory regions in each board's DTS, but leave those commented by
> default to avoid breaking existing bootloaders.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC folks: I forgot to send this patch for ARM SoC earlier.
> As it is a small change I suggest you just apply it to the ARM
> SoC tree as I do not foresee any other RealView work in the near
> future. If you think it can go into v4.9 then put it in as a fix,
> else just push it to the next merge window.
> Robin: sorry for screwing up :(
Normally, memory nodes describe different regions of unique memory.
This is not unique memory, but is an alias of some already-described
memory.
The problem with adding the aliased memory addresses is that we end
up needing platform knowledge to reject the "other alias" from the
memory description, which really isn't good.
The only reason it works is that we reject memory nodes where the
physical address < PHYS_OFFSET. That works provided the alias is
below PHYS_OFFSET, but that isn't always the case.
So, I think it is completely wrong to describe the aliased memory
regions in DT.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Hans de Goede @ 2016-10-18 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67iQikSHcwS15VmSC6fNMVG9Zya9fz6C6b5+wW43rPZfw@mail.gmail.com>
Hi,
On 18-10-16 07:25, Chen-Yu Tsai wrote:
> On Wed, Oct 5, 2016 at 11:51 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> The i2c subsys does not load modules by compatible, only by
>> i2c-id, with e.g. a modalias of: "i2c:axp209".
>>
>> Populate the axp20x_i2c_id[] table with supported ids, so that
>> module auto-loading will work.
>>
>> Reported-by: Dennis Gilmore <dennis@ausil.us>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> Even though axp20x-i2c seems to be the only "DT only" i2c client,
> would it make sense to add DT-based module autoloading to the i2c
> core?
If it is not too invasive, then yes that would be a sensible addition IMHO.
Regards,
Hans
^ 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