* [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3
From: LABBE Corentin @ 2016-10-19 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005122130.8cc229ff5d4990149956b49c@free.fr>
On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> On Wed, 5 Oct 2016 11:48:24 +0200
> Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> > This patch add support for the sunxi-sid driver to the device tree for sun8i-h3.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 9f58bb4..abfd29c 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -211,6 +211,11 @@
> > #size-cells = <0>;
> > };
> >
> > + sid: eeprom at 01c14200 {
> > + compatible = "allwinner,sun7i-a20-sid";
> > + reg = <0x01c14200 0x200>;
>
> The datasheet says 1Kb starting at 0x01c14000.
> Is there any reason to reduce the area and to shift the offset?
>
According to http://linux-sunxi.org/SID_Register_Guide "For Allwinner A83T and H3 the SID address space starts at 0x01c14000, and the e-fuses are at offset 0x200".
So I use this offset, since the sunxi_sid driver need the base address of e-fuses.
The easiest solution is to use 0x01c14200 since the other part of sid is not used and not known (A83T/H3 user manual doesnt give any information on all sid space, worse for A64 which reference SID only in memory map).
So probably for H3/A64/A83T, there will never any usage of the rest of the SID address space.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH] ARM: integrator: drop EBI access use syscon
From: Linus Walleij @ 2016-10-19 7:43 UTC (permalink / raw)
To: linux-arm-kernel
The EBI lookup is not longer in use: this has been moved to the
NAND chip driver. The syscon node is better accessed indirectly
using the regmap like the NAND chip driver does, so let's use
the syscon to set the modem control signals RTS/CTS through the
dedicated syscon register.
We also migrate the decoder status "SC_DEC" register that
enumerate the logic modules using syscon.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/integrator_ap.c | 54 ++++++++++++++++++--------------
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index 23b98fd414bf..a1af634f8709 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -27,6 +27,8 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/termios.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -37,11 +39,8 @@
#include "pci_v3.h"
#include "lm.h"
-/* Base address to the AP system controller */
-void __iomem *ap_syscon_base;
-/* Base address to the external bus interface */
-static void __iomem *ebi_base;
-
+/* Regmap to the AP system controller */
+static struct regmap *ap_syscon_map;
/*
* All IO addresses are mapped onto VA 0xFFFx.xxxx, where x.xxxx
@@ -125,6 +124,7 @@ static void integrator_uart_set_mctrl(struct amba_device *dev,
{
unsigned int ctrls = 0, ctrlc = 0, rts_mask, dtr_mask;
u32 phybase = dev->res.start;
+ int ret;
if (phybase == INTEGRATOR_UART0_BASE) {
/* UART0 */
@@ -146,8 +146,17 @@ static void integrator_uart_set_mctrl(struct amba_device *dev,
else
ctrls |= dtr_mask;
- __raw_writel(ctrls, ap_syscon_base + INTEGRATOR_SC_CTRLS_OFFSET);
- __raw_writel(ctrlc, ap_syscon_base + INTEGRATOR_SC_CTRLC_OFFSET);
+ ret = regmap_write(ap_syscon_map,
+ INTEGRATOR_SC_CTRLS_OFFSET,
+ ctrls);
+ if (ret)
+ pr_err("MODEM: unable to write PL010 UART CTRLS\n");
+
+ ret = regmap_write(ap_syscon_map,
+ INTEGRATOR_SC_CTRLC_OFFSET,
+ ctrlc);
+ if (ret)
+ pr_err("MODEM: unable to write PL010 UART CRTLC\n");
}
struct amba_pl010_data ap_uart_data = {
@@ -178,35 +187,32 @@ static const struct of_device_id ap_syscon_match[] = {
{ },
};
-static const struct of_device_id ebi_match[] = {
- { .compatible = "arm,external-bus-interface"},
- { },
-};
-
static void __init ap_init_of(void)
{
- unsigned long sc_dec;
+ u32 sc_dec;
struct device_node *syscon;
- struct device_node *ebi;
+ int ret;
int i;
+ of_platform_default_populate(NULL, ap_auxdata_lookup, NULL);
+
syscon = of_find_matching_node(NULL, ap_syscon_match);
if (!syscon)
return;
- ebi = of_find_matching_node(NULL, ebi_match);
- if (!ebi)
+ ap_syscon_map = syscon_node_to_regmap(syscon);
+ if (IS_ERR(ap_syscon_map)) {
+ pr_crit("could not find Integrator/AP system controller\n");
return;
+ }
- ap_syscon_base = of_iomap(syscon, 0);
- if (!ap_syscon_base)
- return;
- ebi_base = of_iomap(ebi, 0);
- if (!ebi_base)
+ ret = regmap_read(ap_syscon_map,
+ INTEGRATOR_SC_DEC_OFFSET,
+ &sc_dec);
+ if (ret) {
+ pr_crit("could not read from Integrator/AP syscon\n");
return;
+ }
- of_platform_default_populate(NULL, ap_auxdata_lookup, NULL);
-
- sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
for (i = 0; i < 4; i++) {
struct lm_device *lmdev;
--
2.7.4
^ permalink raw reply related
* [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags
From: Jan Kara @ 2016-10-19 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013002020.3062-7-lstoakes@gmail.com>
On Thu 13-10-16 01:20:16, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_user_pages() and
> replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit
> in callers as use of this flag can result in surprising behaviour (and hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
The patch looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> arch/cris/arch-v32/drivers/cryptocop.c | 4 +---
> arch/ia64/kernel/err_inject.c | 2 +-
> arch/x86/mm/mpx.c | 5 ++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++++--
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++-
> drivers/gpu/drm/via/via_dmablit.c | 4 ++--
> drivers/infiniband/core/umem.c | 6 +++++-
> drivers/infiniband/hw/mthca/mthca_memfree.c | 2 +-
> drivers/infiniband/hw/qib/qib_user_pages.c | 3 ++-
> drivers/infiniband/hw/usnic/usnic_uiom.c | 5 ++++-
> drivers/media/v4l2-core/videobuf-dma-sg.c | 7 +++++--
> drivers/misc/mic/scif/scif_rma.c | 3 +--
> drivers/misc/sgi-gru/grufault.c | 2 +-
> drivers/platform/goldfish/goldfish_pipe.c | 3 ++-
> drivers/rapidio/devices/rio_mport_cdev.c | 3 ++-
> .../vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 +--
> .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 +--
> drivers/virt/fsl_hypervisor.c | 4 ++--
> include/linux/mm.h | 2 +-
> mm/gup.c | 12 +++---------
> mm/mempolicy.c | 2 +-
> mm/nommu.c | 18 ++++--------------
> 22 files changed, 49 insertions(+), 54 deletions(-)
>
> diff --git a/arch/cris/arch-v32/drivers/cryptocop.c b/arch/cris/arch-v32/drivers/cryptocop.c
> index b5698c8..099e170 100644
> --- a/arch/cris/arch-v32/drivers/cryptocop.c
> +++ b/arch/cris/arch-v32/drivers/cryptocop.c
> @@ -2722,7 +2722,6 @@ static int cryptocop_ioctl_process(struct inode *inode, struct file *filp, unsig
> err = get_user_pages((unsigned long int)(oper.indata + prev_ix),
> noinpages,
> 0, /* read access only for in data */
> - 0, /* no force */
> inpages,
> NULL);
>
> @@ -2736,8 +2735,7 @@ static int cryptocop_ioctl_process(struct inode *inode, struct file *filp, unsig
> if (oper.do_cipher){
> err = get_user_pages((unsigned long int)oper.cipher_outdata,
> nooutpages,
> - 1, /* write access for out data */
> - 0, /* no force */
> + FOLL_WRITE, /* write access for out data */
> outpages,
> NULL);
> up_read(¤t->mm->mmap_sem);
> diff --git a/arch/ia64/kernel/err_inject.c b/arch/ia64/kernel/err_inject.c
> index 09f8457..5ed0ea9 100644
> --- a/arch/ia64/kernel/err_inject.c
> +++ b/arch/ia64/kernel/err_inject.c
> @@ -142,7 +142,7 @@ store_virtual_to_phys(struct device *dev, struct device_attribute *attr,
> u64 virt_addr=simple_strtoull(buf, NULL, 16);
> int ret;
>
> - ret = get_user_pages(virt_addr, 1, VM_READ, 0, NULL, NULL);
> + ret = get_user_pages(virt_addr, 1, FOLL_WRITE, NULL, NULL);
> if (ret<=0) {
> #ifdef ERR_INJ_DEBUG
> printk("Virtual address %lx is not existing.\n",virt_addr);
> diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> index 8047687..e4f8009 100644
> --- a/arch/x86/mm/mpx.c
> +++ b/arch/x86/mm/mpx.c
> @@ -544,10 +544,9 @@ static int mpx_resolve_fault(long __user *addr, int write)
> {
> long gup_ret;
> int nr_pages = 1;
> - int force = 0;
>
> - gup_ret = get_user_pages((unsigned long)addr, nr_pages, write,
> - force, NULL, NULL);
> + gup_ret = get_user_pages((unsigned long)addr, nr_pages,
> + write ? FOLL_WRITE : 0, NULL, NULL);
> /*
> * get_user_pages() returns number of pages gotten.
> * 0 means we failed to fault in and get anything,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 887483b..dcaf691 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -555,10 +555,13 @@ struct amdgpu_ttm_tt {
> int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
> {
> struct amdgpu_ttm_tt *gtt = (void *)ttm;
> - int write = !(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY);
> + unsigned int flags = 0;
> unsigned pinned = 0;
> int r;
>
> + if (!(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY))
> + flags |= FOLL_WRITE;
> +
> if (gtt->userflags & AMDGPU_GEM_USERPTR_ANONONLY) {
> /* check that we only use anonymous memory
> to prevent problems with writeback */
> @@ -581,7 +584,7 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
> list_add(&guptask.list, >t->guptasks);
> spin_unlock(>t->guptasklock);
>
> - r = get_user_pages(userptr, num_pages, write, 0, p, NULL);
> + r = get_user_pages(userptr, num_pages, flags, p, NULL);
>
> spin_lock(>t->guptasklock);
> list_del(&guptask.list);
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 4552682..3de5e6e 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -566,7 +566,8 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
> uint64_t userptr = gtt->userptr + pinned * PAGE_SIZE;
> struct page **pages = ttm->pages + pinned;
>
> - r = get_user_pages(userptr, num_pages, write, 0, pages, NULL);
> + r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0,
> + pages, NULL);
> if (r < 0)
> goto release_pages;
>
> diff --git a/drivers/gpu/drm/via/via_dmablit.c b/drivers/gpu/drm/via/via_dmablit.c
> index 7e2a12c..1a3ad76 100644
> --- a/drivers/gpu/drm/via/via_dmablit.c
> +++ b/drivers/gpu/drm/via/via_dmablit.c
> @@ -241,8 +241,8 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg, drm_via_dmablit_t *xfer)
> down_read(¤t->mm->mmap_sem);
> ret = get_user_pages((unsigned long)xfer->mem_addr,
> vsg->num_pages,
> - (vsg->direction == DMA_FROM_DEVICE),
> - 0, vsg->pages, NULL);
> + (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0,
> + vsg->pages, NULL);
>
> up_read(¤t->mm->mmap_sem);
> if (ret != vsg->num_pages) {
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index c68746c..224ad27 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -94,6 +94,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> unsigned long dma_attrs = 0;
> struct scatterlist *sg, *sg_list_start;
> int need_release = 0;
> + unsigned int gup_flags = FOLL_WRITE;
>
> if (dmasync)
> dma_attrs |= DMA_ATTR_WRITE_BARRIER;
> @@ -183,6 +184,9 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> if (ret)
> goto out;
>
> + if (!umem->writable)
> + gup_flags |= FOLL_FORCE;
> +
> need_release = 1;
> sg_list_start = umem->sg_head.sgl;
>
> @@ -190,7 +194,7 @@ struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> ret = get_user_pages(cur_base,
> min_t(unsigned long, npages,
> PAGE_SIZE / sizeof (struct page *)),
> - 1, !umem->writable, page_list, vma_list);
> + gup_flags, page_list, vma_list);
>
> if (ret < 0)
> goto out;
> diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c b/drivers/infiniband/hw/mthca/mthca_memfree.c
> index 6c00d04..c6fe89d 100644
> --- a/drivers/infiniband/hw/mthca/mthca_memfree.c
> +++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
> @@ -472,7 +472,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct mthca_uar *uar,
> goto out;
> }
>
> - ret = get_user_pages(uaddr & PAGE_MASK, 1, 1, 0, pages, NULL);
> + ret = get_user_pages(uaddr & PAGE_MASK, 1, FOLL_WRITE, pages, NULL);
> if (ret < 0)
> goto out;
>
> diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c
> index 2d2b94f..75f0862 100644
> --- a/drivers/infiniband/hw/qib/qib_user_pages.c
> +++ b/drivers/infiniband/hw/qib/qib_user_pages.c
> @@ -67,7 +67,8 @@ static int __qib_get_user_pages(unsigned long start_page, size_t num_pages,
>
> for (got = 0; got < num_pages; got += ret) {
> ret = get_user_pages(start_page + got * PAGE_SIZE,
> - num_pages - got, 1, 1,
> + num_pages - got,
> + FOLL_WRITE | FOLL_FORCE,
> p + got, NULL);
> if (ret < 0)
> goto bail_release;
> diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c b/drivers/infiniband/hw/usnic/usnic_uiom.c
> index a0b6ebe..1ccee6e 100644
> --- a/drivers/infiniband/hw/usnic/usnic_uiom.c
> +++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
> @@ -111,6 +111,7 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable,
> int i;
> int flags;
> dma_addr_t pa;
> + unsigned int gup_flags;
>
> if (!can_do_mlock())
> return -EPERM;
> @@ -135,6 +136,8 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable,
>
> flags = IOMMU_READ | IOMMU_CACHE;
> flags |= (writable) ? IOMMU_WRITE : 0;
> + gup_flags = FOLL_WRITE;
> + gup_flags |= (writable) ? 0 : FOLL_FORCE;
> cur_base = addr & PAGE_MASK;
> ret = 0;
>
> @@ -142,7 +145,7 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t size, int writable,
> ret = get_user_pages(cur_base,
> min_t(unsigned long, npages,
> PAGE_SIZE / sizeof(struct page *)),
> - 1, !writable, page_list, NULL);
> + gup_flags, page_list, NULL);
>
> if (ret < 0)
> goto out;
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index f300f06..1db0af6 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -156,6 +156,7 @@ static int videobuf_dma_init_user_locked(struct videobuf_dmabuf *dma,
> {
> unsigned long first, last;
> int err, rw = 0;
> + unsigned int flags = FOLL_FORCE;
>
> dma->direction = direction;
> switch (dma->direction) {
> @@ -178,12 +179,14 @@ static int videobuf_dma_init_user_locked(struct videobuf_dmabuf *dma,
> if (NULL == dma->pages)
> return -ENOMEM;
>
> + if (rw == READ)
> + flags |= FOLL_WRITE;
> +
> dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
> data, size, dma->nr_pages);
>
> err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
> - rw == READ, 1, /* force */
> - dma->pages, NULL);
> + flags, dma->pages, NULL);
>
> if (err != dma->nr_pages) {
> dma->nr_pages = (err >= 0) ? err : 0;
> diff --git a/drivers/misc/mic/scif/scif_rma.c b/drivers/misc/mic/scif/scif_rma.c
> index e0203b1..f806a44 100644
> --- a/drivers/misc/mic/scif/scif_rma.c
> +++ b/drivers/misc/mic/scif/scif_rma.c
> @@ -1396,8 +1396,7 @@ int __scif_pin_pages(void *addr, size_t len, int *out_prot,
> pinned_pages->nr_pages = get_user_pages(
> (u64)addr,
> nr_pages,
> - !!(prot & SCIF_PROT_WRITE),
> - 0,
> + (prot & SCIF_PROT_WRITE) ? FOLL_WRITE : 0,
> pinned_pages->pages,
> NULL);
> up_write(&mm->mmap_sem);
> diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
> index a2d97b9..6fb773d 100644
> --- a/drivers/misc/sgi-gru/grufault.c
> +++ b/drivers/misc/sgi-gru/grufault.c
> @@ -198,7 +198,7 @@ static int non_atomic_pte_lookup(struct vm_area_struct *vma,
> #else
> *pageshift = PAGE_SHIFT;
> #endif
> - if (get_user_pages(vaddr, 1, write, 0, &page, NULL) <= 0)
> + if (get_user_pages(vaddr, 1, write ? FOLL_WRITE : 0, &page, NULL) <= 0)
> return -EFAULT;
> *paddr = page_to_phys(page);
> put_page(page);
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c b/drivers/platform/goldfish/goldfish_pipe.c
> index 07462d7..1aba2c7 100644
> --- a/drivers/platform/goldfish/goldfish_pipe.c
> +++ b/drivers/platform/goldfish/goldfish_pipe.c
> @@ -309,7 +309,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp, char __user *buffer,
> * much memory to the process.
> */
> down_read(¤t->mm->mmap_sem);
> - ret = get_user_pages(address, 1, !is_write, 0, &page, NULL);
> + ret = get_user_pages(address, 1, is_write ? 0 : FOLL_WRITE,
> + &page, NULL);
> up_read(¤t->mm->mmap_sem);
> if (ret < 0)
> break;
> diff --git a/drivers/rapidio/devices/rio_mport_cdev.c b/drivers/rapidio/devices/rio_mport_cdev.c
> index 436dfe8..9013a58 100644
> --- a/drivers/rapidio/devices/rio_mport_cdev.c
> +++ b/drivers/rapidio/devices/rio_mport_cdev.c
> @@ -892,7 +892,8 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
> down_read(¤t->mm->mmap_sem);
> pinned = get_user_pages(
> (unsigned long)xfer->loc_addr & PAGE_MASK,
> - nr_pages, dir == DMA_FROM_DEVICE, 0,
> + nr_pages,
> + dir == DMA_FROM_DEVICE ? FOLL_WRITE : 0,
> page_list, NULL);
> up_read(¤t->mm->mmap_sem);
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index c29040f..1091b9f 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -423,8 +423,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
> actual_pages = get_user_pages(task, task->mm,
> (unsigned long)buf & ~(PAGE_SIZE - 1),
> num_pages,
> - (type == PAGELIST_READ) /*Write */ ,
> - 0 /*Force */ ,
> + (type == PAGELIST_READ) ? FOLL_WRITE : 0,
> pages,
> NULL /*vmas */);
> up_read(&task->mm->mmap_sem);
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index e11c0e0..7b6cd4d 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -1477,8 +1477,7 @@ dump_phys_mem(void *virt_addr, uint32_t num_bytes)
> current->mm, /* mm */
> (unsigned long)virt_addr, /* start */
> num_pages, /* len */
> - 0, /* write */
> - 0, /* force */
> + 0, /* gup_flags */
> pages, /* pages (array of page pointers) */
> NULL); /* vmas */
> up_read(¤t->mm->mmap_sem);
> diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
> index 60bdad3..150ce2a 100644
> --- a/drivers/virt/fsl_hypervisor.c
> +++ b/drivers/virt/fsl_hypervisor.c
> @@ -245,8 +245,8 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
> /* Get the physical addresses of the source buffer */
> down_read(¤t->mm->mmap_sem);
> num_pinned = get_user_pages(param.local_vaddr - lb_offset,
> - num_pages, (param.source == -1) ? READ : WRITE,
> - 0, pages, NULL);
> + num_pages, (param.source == -1) ? 0 : FOLL_WRITE,
> + pages, NULL);
> up_read(¤t->mm->mmap_sem);
>
> if (num_pinned != num_pages) {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5ff084f6..686a477 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1279,7 +1279,7 @@ long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> int write, int force, struct page **pages,
> struct vm_area_struct **vmas);
> long get_user_pages(unsigned long start, unsigned long nr_pages,
> - int write, int force, struct page **pages,
> + unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas);
> long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages, int *locked);
> diff --git a/mm/gup.c b/mm/gup.c
> index 7a0d033..dc91303 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -977,18 +977,12 @@ EXPORT_SYMBOL(get_user_pages_remote);
> * obviously don't pass FOLL_REMOTE in here.
> */
> long get_user_pages(unsigned long start, unsigned long nr_pages,
> - int write, int force, struct page **pages,
> + unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas)
> {
> - unsigned int flags = FOLL_TOUCH;
> -
> - if (write)
> - flags |= FOLL_WRITE;
> - if (force)
> - flags |= FOLL_FORCE;
> -
> return __get_user_pages_locked(current, current->mm, start, nr_pages,
> - pages, vmas, NULL, false, flags);
> + pages, vmas, NULL, false,
> + gup_flags | FOLL_TOUCH);
> }
> EXPORT_SYMBOL(get_user_pages);
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index ad1c96a..0b859af 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -850,7 +850,7 @@ static int lookup_node(unsigned long addr)
> struct page *p;
> int err;
>
> - err = get_user_pages(addr & PAGE_MASK, 1, 0, 0, &p, NULL);
> + err = get_user_pages(addr & PAGE_MASK, 1, 0, &p, NULL);
> if (err >= 0) {
> err = page_to_nid(p);
> put_page(p);
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 842cfdd..70cb844 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -160,18 +160,11 @@ long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> * - don't permit access to VMAs that don't support it, such as I/O mappings
> */
> long get_user_pages(unsigned long start, unsigned long nr_pages,
> - int write, int force, struct page **pages,
> + unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas)
> {
> - int flags = 0;
> -
> - if (write)
> - flags |= FOLL_WRITE;
> - if (force)
> - flags |= FOLL_FORCE;
> -
> - return __get_user_pages(current, current->mm, start, nr_pages, flags,
> - pages, vmas, NULL);
> + return __get_user_pages(current, current->mm, start, nr_pages,
> + gup_flags, pages, vmas, NULL);
> }
> EXPORT_SYMBOL(get_user_pages);
>
> @@ -179,10 +172,7 @@ long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages,
> int *locked)
> {
> - int write = gup_flags & FOLL_WRITE;
> - int force = gup_flags & FOLL_FORCE;
> -
> - return get_user_pages(start, nr_pages, write, force, pages, NULL);
> + return get_user_pages(start, nr_pages, gup_flags, pages, NULL);
> }
> EXPORT_SYMBOL(get_user_pages_locked);
>
> --
> 2.10.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH 07/10] mm: replace get_user_pages_remote() write/force parameters with gup_flags
From: Jan Kara @ 2016-10-19 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013002020.3062-8-lstoakes@gmail.com>
On Thu 13-10-16 01:20:17, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_user_pages_remote()
> and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
> explicit in callers as use of this flag can result in surprising behaviour (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 +++++--
> drivers/gpu/drm/i915/i915_gem_userptr.c | 6 +++++-
> drivers/infiniband/core/umem_odp.c | 7 +++++--
> fs/exec.c | 9 +++++++--
> include/linux/mm.h | 2 +-
> kernel/events/uprobes.c | 6 ++++--
> mm/gup.c | 22 +++++++---------------
> mm/memory.c | 6 +++++-
> security/tomoyo/domain.c | 2 +-
> 9 files changed, 40 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 5ce3603..0370b84 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -748,19 +748,22 @@ static struct page **etnaviv_gem_userptr_do_get_pages(
> int ret = 0, pinned, npages = etnaviv_obj->base.size >> PAGE_SHIFT;
> struct page **pvec;
> uintptr_t ptr;
> + unsigned int flags = 0;
>
> pvec = drm_malloc_ab(npages, sizeof(struct page *));
> if (!pvec)
> return ERR_PTR(-ENOMEM);
>
> + if (!etnaviv_obj->userptr.ro)
> + flags |= FOLL_WRITE;
> +
> pinned = 0;
> ptr = etnaviv_obj->userptr.ptr;
>
> down_read(&mm->mmap_sem);
> while (pinned < npages) {
> ret = get_user_pages_remote(task, mm, ptr, npages - pinned,
> - !etnaviv_obj->userptr.ro, 0,
> - pvec + pinned, NULL);
> + flags, pvec + pinned, NULL);
> if (ret < 0)
> break;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index e537930..c6f780f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -508,6 +508,10 @@ __i915_gem_userptr_get_pages_worker(struct work_struct *_work)
> pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
> if (pvec != NULL) {
> struct mm_struct *mm = obj->userptr.mm->mm;
> + unsigned int flags = 0;
> +
> + if (!obj->userptr.read_only)
> + flags |= FOLL_WRITE;
>
> ret = -EFAULT;
> if (atomic_inc_not_zero(&mm->mm_users)) {
> @@ -517,7 +521,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct *_work)
> (work->task, mm,
> obj->userptr.ptr + pinned * PAGE_SIZE,
> npages - pinned,
> - !obj->userptr.read_only, 0,
> + flags,
> pvec + pinned, NULL);
> if (ret < 0)
> break;
> diff --git a/drivers/infiniband/core/umem_odp.c b/drivers/infiniband/core/umem_odp.c
> index 75077a0..1f0fe32 100644
> --- a/drivers/infiniband/core/umem_odp.c
> +++ b/drivers/infiniband/core/umem_odp.c
> @@ -527,6 +527,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem *umem, u64 user_virt, u64 bcnt,
> u64 off;
> int j, k, ret = 0, start_idx, npages = 0;
> u64 base_virt_addr;
> + unsigned int flags = 0;
>
> if (access_mask == 0)
> return -EINVAL;
> @@ -556,6 +557,9 @@ int ib_umem_odp_map_dma_pages(struct ib_umem *umem, u64 user_virt, u64 bcnt,
> goto out_put_task;
> }
>
> + if (access_mask & ODP_WRITE_ALLOWED_BIT)
> + flags |= FOLL_WRITE;
> +
> start_idx = (user_virt - ib_umem_start(umem)) >> PAGE_SHIFT;
> k = start_idx;
>
> @@ -574,8 +578,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem *umem, u64 user_virt, u64 bcnt,
> */
> npages = get_user_pages_remote(owning_process, owning_mm,
> user_virt, gup_num_pages,
> - access_mask & ODP_WRITE_ALLOWED_BIT,
> - 0, local_page_list, NULL);
> + flags, local_page_list, NULL);
> up_read(&owning_mm->mmap_sem);
>
> if (npages < 0)
> diff --git a/fs/exec.c b/fs/exec.c
> index 6fcfb3f..4e497b9 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -191,6 +191,7 @@ static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
> {
> struct page *page;
> int ret;
> + unsigned int gup_flags = FOLL_FORCE;
>
> #ifdef CONFIG_STACK_GROWSUP
> if (write) {
> @@ -199,12 +200,16 @@ static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
> return NULL;
> }
> #endif
> +
> + if (write)
> + gup_flags |= FOLL_WRITE;
> +
> /*
> * We are doing an exec(). 'current' is the process
> * doing the exec and bprm->mm is the new process's mm.
> */
> - ret = get_user_pages_remote(current, bprm->mm, pos, 1, write,
> - 1, &page, NULL);
> + ret = get_user_pages_remote(current, bprm->mm, pos, 1, gup_flags,
> + &page, NULL);
> if (ret <= 0)
> return NULL;
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 686a477..2a481d3 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1276,7 +1276,7 @@ long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> struct vm_area_struct **vmas, int *nonblocking);
> long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> unsigned long start, unsigned long nr_pages,
> - int write, int force, struct page **pages,
> + unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas);
> long get_user_pages(unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages,
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index d4129bb..f9ec9ad 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -300,7 +300,8 @@ int uprobe_write_opcode(struct mm_struct *mm, unsigned long vaddr,
>
> retry:
> /* Read the page with vaddr into memory */
> - ret = get_user_pages_remote(NULL, mm, vaddr, 1, 0, 1, &old_page, &vma);
> + ret = get_user_pages_remote(NULL, mm, vaddr, 1, FOLL_FORCE, &old_page,
> + &vma);
> if (ret <= 0)
> return ret;
>
> @@ -1710,7 +1711,8 @@ static int is_trap_at_addr(struct mm_struct *mm, unsigned long vaddr)
> * but we treat this as a 'remote' access since it is
> * essentially a kernel access to the memory.
> */
> - result = get_user_pages_remote(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> + result = get_user_pages_remote(NULL, mm, vaddr, 1, FOLL_FORCE, &page,
> + NULL);
> if (result < 0)
> return result;
>
> diff --git a/mm/gup.c b/mm/gup.c
> index dc91303..0deecf3 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -905,9 +905,7 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
> * @mm: mm_struct of target mm
> * @start: starting user address
> * @nr_pages: number of pages from start to pin
> - * @write: whether pages will be written to by the caller
> - * @force: whether to force access even when user mapping is currently
> - * protected (but never forces write access to shared mapping).
> + * @gup_flags: flags modifying lookup behaviour
> * @pages: array that receives pointers to the pages pinned.
> * Should be at least nr_pages long. Or NULL, if caller
> * only intends to ensure the pages are faulted in.
> @@ -936,9 +934,9 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
> * or similar operation cannot guarantee anything stronger anyway because
> * locks can't be held over the syscall boundary.
> *
> - * If write=0, the page must not be written to. If the page is written to,
> - * set_page_dirty (or set_page_dirty_lock, as appropriate) must be called
> - * after the page is finished with, and before put_page is called.
> + * If gup_flags & FOLL_WRITE == 0, the page must not be written to. If the page
> + * is written to, set_page_dirty (or set_page_dirty_lock, as appropriate) must
> + * be called after the page is finished with, and before put_page is called.
> *
> * get_user_pages is typically used for fewer-copy IO operations, to get a
> * handle on the memory by some means other than accesses via the user virtual
> @@ -955,18 +953,12 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
> */
> long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> unsigned long start, unsigned long nr_pages,
> - int write, int force, struct page **pages,
> + unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas)
> {
> - unsigned int flags = FOLL_TOUCH | FOLL_REMOTE;
> -
> - if (write)
> - flags |= FOLL_WRITE;
> - if (force)
> - flags |= FOLL_FORCE;
> -
> return __get_user_pages_locked(tsk, mm, start, nr_pages, pages, vmas,
> - NULL, false, flags);
> + NULL, false,
> + gup_flags | FOLL_TOUCH | FOLL_REMOTE);
> }
> EXPORT_SYMBOL(get_user_pages_remote);
>
> diff --git a/mm/memory.c b/mm/memory.c
> index fc1987d..20a9adb 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3873,6 +3873,10 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> {
> struct vm_area_struct *vma;
> void *old_buf = buf;
> + unsigned int flags = FOLL_FORCE;
> +
> + if (write)
> + flags |= FOLL_WRITE;
>
> down_read(&mm->mmap_sem);
> /* ignore errors, just check how much was successfully transferred */
> @@ -3882,7 +3886,7 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> struct page *page = NULL;
>
> ret = get_user_pages_remote(tsk, mm, addr, 1,
> - write, 1, &page, &vma);
> + flags, &page, &vma);
> if (ret <= 0) {
> #ifndef CONFIG_HAVE_IOREMAP_PROT
> break;
> diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
> index ade7c6c..682b73a 100644
> --- a/security/tomoyo/domain.c
> +++ b/security/tomoyo/domain.c
> @@ -881,7 +881,7 @@ bool tomoyo_dump_page(struct linux_binprm *bprm, unsigned long pos,
> * the execve().
> */
> if (get_user_pages_remote(current, bprm->mm, pos, 1,
> - 0, 1, &page, NULL) <= 0)
> + FOLL_FORCE, &page, NULL) <= 0)
> return false;
> #else
> page = bprm->page[pos / PAGE_SIZE];
> --
> 2.10.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH/RESEND] clocksource/arm_arch_timer: Map frame with of_io_request_and_map()
From: Marc Zyngier @ 2016-10-19 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018234514.6175-1-sboyd@codeaurora.org>
On 19/10/16 00:45, Stephen Boyd wrote:
> Let's use the of_io_request_and_map() API so that the frame
> region is protected and shows up in /proc/iomem.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487da6d2a..cbfa3bc5be75 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -964,7 +964,8 @@ static int __init arch_timer_mem_init(struct device_node *np)
> }
>
> ret= -ENXIO;
> - base = arch_counter_base = of_iomap(best_frame, 0);
> + base = arch_counter_base = of_io_request_and_map(best_frame, 0,
> + "arch_mem_timer");
> if (!base) {
> pr_err("arch_timer: Can't map frame's registers\n");
> goto out;
>
Careful here: of_io_request_and_map() returns an ERR_PTR() on failure,
while of_iomap just returns NULL. You want to change the error handling
if you're going down that road.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Jan Kara @ 2016-10-19 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013002020.3062-9-lstoakes@gmail.com>
On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> This patch removes the write parameter from __access_remote_vm() and replaces it
> with a gup_flags parameter as use of this function previously _implied_
> FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
>
> We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> (and hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
So I'm not convinced this (and the following two patches) is actually
helping much. By grepping for FOLL_FORCE we will easily see that any caller
of access_remote_vm() gets that semantics and can thus continue search
accordingly (it is much simpler than searching for all get_user_pages()
users and extracting from parameter lists what they actually pass as
'force' argument). Sure it makes somewhat more visible to callers of
access_remote_vm() that they get FOLL_FORCE semantics but OTOH it also
opens a space for issues where a caller of access_remote_vm() actually
wants FOLL_FORCE (and currently all of them want it) and just mistakenly
does not set it. All in all I'd prefer to keep access_remote_vm() and
friends as is...
Honza
> ---
> mm/memory.c | 23 +++++++++++++++--------
> mm/nommu.c | 9 ++++++---
> 2 files changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 20a9adb..79ebed3 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3869,14 +3869,11 @@ EXPORT_SYMBOL_GPL(generic_access_phys);
> * given task for page fault accounting.
> */
> static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> - unsigned long addr, void *buf, int len, int write)
> + unsigned long addr, void *buf, int len, unsigned int gup_flags)
> {
> struct vm_area_struct *vma;
> void *old_buf = buf;
> - unsigned int flags = FOLL_FORCE;
> -
> - if (write)
> - flags |= FOLL_WRITE;
> + int write = gup_flags & FOLL_WRITE;
>
> down_read(&mm->mmap_sem);
> /* ignore errors, just check how much was successfully transferred */
> @@ -3886,7 +3883,7 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> struct page *page = NULL;
>
> ret = get_user_pages_remote(tsk, mm, addr, 1,
> - flags, &page, &vma);
> + gup_flags, &page, &vma);
> if (ret <= 0) {
> #ifndef CONFIG_HAVE_IOREMAP_PROT
> break;
> @@ -3945,7 +3942,12 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> int access_remote_vm(struct mm_struct *mm, unsigned long addr,
> void *buf, int len, int write)
> {
> - return __access_remote_vm(NULL, mm, addr, buf, len, write);
> + unsigned int flags = FOLL_FORCE;
> +
> + if (write)
> + flags |= FOLL_WRITE;
> +
> + return __access_remote_vm(NULL, mm, addr, buf, len, flags);
> }
>
> /*
> @@ -3958,12 +3960,17 @@ int access_process_vm(struct task_struct *tsk, unsigned long addr,
> {
> struct mm_struct *mm;
> int ret;
> + unsigned int flags = FOLL_FORCE;
>
> mm = get_task_mm(tsk);
> if (!mm)
> return 0;
>
> - ret = __access_remote_vm(tsk, mm, addr, buf, len, write);
> + if (write)
> + flags |= FOLL_WRITE;
> +
> + ret = __access_remote_vm(tsk, mm, addr, buf, len, flags);
> +
> mmput(mm);
>
> return ret;
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 70cb844..bde7df3 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1809,9 +1809,10 @@ void filemap_map_pages(struct fault_env *fe,
> EXPORT_SYMBOL(filemap_map_pages);
>
> static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> - unsigned long addr, void *buf, int len, int write)
> + unsigned long addr, void *buf, int len, unsigned int gup_flags)
> {
> struct vm_area_struct *vma;
> + int write = gup_flags & FOLL_WRITE;
>
> down_read(&mm->mmap_sem);
>
> @@ -1853,7 +1854,8 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
> int access_remote_vm(struct mm_struct *mm, unsigned long addr,
> void *buf, int len, int write)
> {
> - return __access_remote_vm(NULL, mm, addr, buf, len, write);
> + return __access_remote_vm(NULL, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
> }
>
> /*
> @@ -1871,7 +1873,8 @@ int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, in
> if (!mm)
> return 0;
>
> - len = __access_remote_vm(tsk, mm, addr, buf, len, write);
> + len = __access_remote_vm(tsk, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
>
> mmput(mm);
> return len;
> --
> 2.10.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Peter Chen @ 2016-10-19 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147684198705.24897.12451889548508263144@sboyd-linaro>
On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-18 18:15:35)
> > On Mon, Oct 17, 2016 at 06:56:24PM -0700, Stephen Boyd wrote:
> > > In the case of an extcon-usb-gpio device being used with the
> > > chipidea driver we'll sometimes miss the BSVIS event in the OTGSC
> > > register. Consider the case where we don't have a cable attached
> > > and the id pin is indicating "host" mode. When we plug in the usb
> > > cable for "device" mode a gpio goes high and indicates that we
> > > should do the role switch and that vbus is high. When we're in
> > > "host" mode the OTGSC register doesn't have BSVIE set.
> >
> > I have some questions for your description:
> >
> > - Do you have any pending or related patches what this patch set
> > is based on? Afaik, the extcon-usb-gpio has no vbus event supported.
>
> If you're asking if I've made modifications to extcon-usb-gpio, then the
> answer is no. The branch on linaro.org git server from the cover-letter
> is the branch I've used to test this with. This patch is specifically to
> fix issues with that design on the db410c board that has only one pin
> for ID and vbus detection. It's the schematic that we've discussed in
> another thread.
>
> extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> events.
>
Hmm, in fact, your ID event is the same with vbus event, you take
external vbus event as ID event for extcon-usb-gpio handling. Yes,
it can work due to it sends EXTCON_USB_HOST event first.
Where you change the USB_SW_SEL_PM pin?
> > - When the ID from 0->1, the chipidea driver will do role switch, and
> > set BSVIE, why it does not occur for your case?
>
> Right, that happens with this line in the sequence I describe below:
>
> hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE, OTGSC_BSVIS | OTGSC_BSVIE);
>
> but that happens much later than when the extcon event happens so we
> miss the interrupt. Technically, the driver isn't expecting the BSVIS
> interrupt to happen until BSVIE is set, but the extcon can come whenever
> it wants regardless of how the registers are configured in the
> controller. So we have to do some sort of 'caching' here to remember
> that the vbus event happened and replay it when BSVIE is set. At least I
> imagine this is how the hardware would work? Or if vbus goes high before
> we enable the interrupt would it just be missed? It seems like polling
> the BSV bit and then enabling BSVIE is sort of racy there.
>
> Plus, we poll the BSV bit when we role switch, but in my case id bit
> toggles and vbus goes high at exactly the same time because that is all
> happening from a single cable being connected, so it's not possible for
> BSV to go low and see it after the id pin from 0 to 1.
Now, I understand your case, but your changes are a little complicated.
Would you try if below patch can fix your issue?
>From 8b8baf31dcaca53612d0fd91068c84fe09d66f6c Mon Sep 17 00:00:00 2001
From: Peter Chen <peter.chen@nxp.com>
Date: Wed, 19 Oct 2016 15:32:58 +0800
Subject: [PATCH 1/1] usb: chipidea: vbus event may exist before starting
gadget
At some situations, the vbus may already be there before starting
gadget. So we need to check vbus event after switch to gadget in
order to handle missing vbus event. The typical use cases are plugging
vbus cable before driver load or the vbus has already been there
after stopping host but before starting gadget.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
drivers/usb/chipidea/core.c | 4 ----
drivers/usb/chipidea/otg.c | 10 ++++++----
drivers/usb/chipidea/udc.c | 2 ++
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index b814d91..a7d2c68 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -992,10 +992,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
}
if (!ci_otg_is_fsm_mode(ci)) {
- /* only update vbus status for peripheral */
- if (ci->role == CI_ROLE_GADGET)
- ci_handle_vbus_change(ci);
-
ret = ci_role_start(ci, ci->role);
if (ret) {
dev_err(dev, "can't start %s role\n",
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 695f3fe..99c0709 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -134,9 +134,9 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
if (!ci->is_otg)
return;
- if (hw_read_otgsc(ci, OTGSC_BSV))
+ if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
usb_gadget_vbus_connect(&ci->gadget);
- else
+ else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
usb_gadget_vbus_disconnect(&ci->gadget);
}
@@ -175,10 +175,12 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
ci_role_stop(ci);
- if (role == CI_ROLE_GADGET)
+ if (role == CI_ROLE_GADGET &&
+ IS_ERR(ci->platdata->vbus_extcon.edev))
/*
* wait vbus lower than OTGSC_BSV before connecting
- * to host
+ * to host. And if vbus's status is an external
+ * connector, it doesn't need to wait here.
*/
hw_wait_vbus_lower_bsv(ci);
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 001c2fa..184ffba 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
/* Clear and enable BSV irq */
hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
OTGSC_BSVIS | OTGSC_BSVIE);
+ /* vbus change may has already been occurred */
+ ci_handle_vbus_change(ci);
return 0;
}
--
2.7.4
--
Best Regards,
Peter Chen
^ permalink raw reply related
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-10-19 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1560471.cOCZ4VcGTh@wuerfel>
Hi Arnd,
On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 4, 2016 11:09:27 AM CEST Geert Uytterhoeven wrote:
>> Identify the SoC type and revision, and register this information with
>> the SoC bus, so it is available under /sys/devices/soc0/, and can be
>> checked where needed using soc_device_match().
>>
>> In addition, on SoCs that support it, the product ID is read from a
>> hardware register and validated, to catch accidental use of a DTB for a
>> different SoC.
>>
>> Example:
>>
>> Detected Renesas r8a7791 ES1.0
>> ...
>> # cat /sys/devices/soc0/{family,machine,soc_id,revision}
>> R-Car Gen2
>> Koelsch
>> r8a7791
>> ES1.0
>>
>
> Seems all reasonable.
>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> This patch does NOT add a call to
>>
>> of_platform_default_populate(NULL, NULL,
>> soc_device_to_device(soc_dev));
>>
>> Contrary to suggested by commit 74d1d82cdaaec727 ("drivers/base: add bus
>> for System-on-Chip devices), doing so would not only move on-SoC devices
>> from /sys/devices/platform/ to /sys/devices/soc0/, but also all other
>> board (off-SoC) devices specified in the DTB.
>
> Right, we have moved away from that a while ago, and now just
> use the device for identification, not to model the device
> hierarchy.
OK.
>> diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
>> new file mode 100644
>> index 0000000000000000..74b72e4112b8889e
>> --- /dev/null
>> +++ b/drivers/soc/renesas/renesas-soc.c
>> @@ -0,0 +1,266 @@
>> +/*
>> + * Renesas SoC Identification
>> + *
>> + * Copyright (C) 2014-2016 Glider bvba
>> + *
>> + * 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; version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/string.h>
>> +#include <linux/sys_soc.h>
>> +
>> +
>> +struct renesas_family {
>> + const char name[16];
>> + u32 reg; /* CCCR, PVR, or PRR */
>> +};
>> +
>> +static const struct renesas_family fam_emev2 __initconst = {
>> + .name = "Emma Mobile EV2",
>> +};
>
> As this is not related to the others and doesn't have the respective
> register, I'd leave the platform out of this, and possibly have
> a separate driver for it.
OK. Emma Mobile is special, as it doesn't share any drivers with the
other SoCs (NEC vs. Hitachi origin).
>> +static const struct renesas_family fam_rza __initconst = {
>> + .name = "RZ/A",
>> +};
>
> I'm not sure about the relationship between this one and the others,
> maybe it should be treated in the same way as emev2 and left out from
> this driver?
While RZ/A doesn't have a version registers (AFAIK), it shares several
drivers with the other SoCs (SH/R-Mobile, R-Car).
Hence I'd like to keep it, so we can match for it in these drivers when
needed. It has e.g. a different variant of the serial port (SCIF), more
closely to the one on SH2 rather than SH4.
>> +static const struct renesas_family fam_rmobile __initconst = {
>> + .name = "R-Mobile",
>> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
>> +};
>> +
>> +static const struct renesas_family fam_rcar_gen1 __initconst = {
>> + .name = "R-Car Gen1",
>> + .reg = 0xff000044, /* PRR (Product Register) */
>> +};
>> +
>> +static const struct renesas_family fam_rcar_gen2 __initconst = {
>> + .name = "R-Car Gen2",
>> + .reg = 0xff000044, /* PRR (Product Register) */
>> +};
>> +
>> +static const struct renesas_family fam_rcar_gen3 __initconst = {
>> + .name = "R-Car Gen3",
>> + .reg = 0xfff00044, /* PRR (Product Register) */
>> +};
>> +
>> +static const struct renesas_family fam_rzg __initconst = {
>> + .name = "RZ/G",
>> + .reg = 0xff000044, /* PRR (Product Register) */
>> +};
>> +
>> +static const struct renesas_family fam_shmobile __initconst = {
>> + .name = "SH-Mobile",
>> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
>> +};
>
> These seem to fall into two distinct categories, maybe there is a
> better way to group them. What device contain the two kinds of
> registers (PRR, CCCR)?
Actually there are three (notice the extra "f" on R-Car Gen3 ;-)
Some SoCs have only CCCR, others have only PRR, some have both.
On some SoCs one of them can be accessed from the RealTime CPU
core (SH) only.
On some SoCs the register is not documented, but present.
If the PRR exists, it's a better choice, as it contains additional information
in the high order bits (representing the presence of each big (CA15/CA57),
little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
information, though.
Grouping them in some other way means we would loose the family name,
which is exposed through soc_dev_attr->family.
The usefulness of family names is debatable though, as this is more an
issue of marketing business.
> Hardcoding the register address seems rather ugly here, so maybe
> there is a way to have two separate probe methods based on the
> surrounding register range, and then bind to that?
There's no simple relation between CCCR/PRR and other register blocks.
I prefer not to add these to DT, as that would add one more worm to the
backwards compatibility can.
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_EMEV2
>> + { .compatible = "renesas,emev2", .data = &soc_emev2 },
>> +#endif
>> +#ifdef CONFIG_ARCH_R7S72100
>> + { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A73A4
>
> I think the #ifdefs here will result in warnings for unused symbols
> when the Kconfig symbols are disabled.
Originally I had __maybe_unused, but it didn't seem to be needed.
Do you know which compiler needs it, so I can check?
Thanks for your comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option
From: Arnd Bergmann @ 2016-10-19 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1f5e1f8-b661-9559-ca67-29386d2e992b@broadcom.com>
On Tuesday, October 18, 2016 3:23:26 PM CEST Scott Branden wrote:
> I have be.config and le.config that allow you to switch the defconfig
> between big and little endian. Does this make sense to upstream to
> arm/configs if you have accepted dram_0x00000000.config?
Yes, they clearly fall into the same category, let's merge those as well.
> Would you also accept this to arm64/configs? We actually use
> big and little endian on the same SoC more on arm64 platforms. But, in
> order to boot big endian we need to maintain this outside the kernel
> right now.
I'm in favor of that, but let's see what the arm64 maintainers think.
Arnd
^ permalink raw reply
* [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-10-19 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6327808.hNezbnImkk@wuerfel>
Hi Arnd,
On Mon, Oct 10, 2016 at 4:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 4, 2016 11:09:23 AM CEST Geert Uytterhoeven wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0). This needs to
>> be catered for by drivers and/or platform code. The recently proposed
>> soc_device_match() API seems like a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 4 patches:
>> - Patch 1 avoids a crash when SoC revision information is needed and
>> provided early,
>> - Patch 2 (from Arnd) introduces the soc_device_match() API.
>> I don't know if, when, and through which channel this patch is
>> planned to go upstream,
>> - Patch 3 fixes a bug in soc_device_match(), causing a crash when
>> trying to match on an SoC attribute that is not provided (seen on
>> EMEV2, RZ/A, and R-Car M1A, which lack revision information),
>> - Patch 4 identifies Renesas SoCs and registers them with the SoC bus.
>>
>> Tested on (family, machine, soc_id, optional revision):
>>
>> Emma Mobile EV2, EMEV2 KZM9D Board, emev2
>> RZ/A, Genmai, r7s72100
>> R-Mobile, APE6EVM, r8a73a4, ES1.0
>> R-Mobile, armadillo 800 eva, r8a7740, ES2.0
>> R-Car Gen1, bockw, r8a7778
>> R-Car Gen1, marzen, r8a7779, ES1.0
>> R-Car Gen2, Lager, r8a7790, ES1.0
>> R-Car Gen2, Koelsch, r8a7791, ES1.0
>> R-Car Gen2, Gose, r8a7793, ES1.0
>> R-Car Gen2, Alt, r8a7794, ES1.0
>> R-Car Gen3, Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> R-Car Gen3, Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> SH-Mobile, KZM-A9-GT, sh73a0, ES2.0
>
> As mentioned in the comment for the driver patch, I think this makes
> a lot of sense for the machines that have a revision register, in
> particular when the interpretation of that register is always done
> the same way, but I'm a bit skeptical about doing it in the same driver
> for machines that don't have the register.
>
> Matching by a device rather than the SoC platform also has the advantage
> that there is no need to maintain a list of compatible numbers in the
> driver.
Currently we (usually) use:
- SoC-specific compatible values, to handle known differences within the
same family now, and handle future unknown differences,
- Family-specific compatible values, which we define ourselves.
Usually drivers match on the latter.
Every time a new SoC is introduced, we have to update lots of DT binding
docs, to add the new SoC-specific compatible values.
Two-phase matching (driver code matches against "renesas,<foo>",
driver matches against SoC using soc_device_match()) would allow to
remove the burden of updating DT documentation all the time.
The drivers would need updates, though.
Another advantage would be that we can reuse .dtsi snippets for SoCs in
the same family, which we currently can't easily do due to the SoC-specific
compatible values.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Michal Hocko @ 2016-10-19 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019075903.GP29967@quack2.suse.cz>
On Wed 19-10-16 09:59:03, Jan Kara wrote:
> On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > This patch removes the write parameter from __access_remote_vm() and replaces it
> > with a gup_flags parameter as use of this function previously _implied_
> > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> >
> > We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> > (and hence bugs) within the mm subsystem.
> >
> > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
>
> So I'm not convinced this (and the following two patches) is actually
> helping much. By grepping for FOLL_FORCE we will easily see that any caller
> of access_remote_vm() gets that semantics and can thus continue search
I am really wondering. Is there anything inherent that would require
FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
non-trivial thing. It doesn't obey vma permissions so we should really
minimize its usage. Do all of those users really need FOLL_FORCE?
Anyway I would rather see the flag explicit and used at more places than
hidden behind a helper function.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v3 04/11] ARM: dts: r8a7743: initial SoC device tree
From: Geert Uytterhoeven @ 2016-10-19 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2883940.Oo8sg10L7m@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:38 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
> CPG, and the required clock descriptions.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 11/11] ARM: dts: sk-rzg1m: add Ether support
From: Geert Uytterhoeven @ 2016-10-19 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1764267.cmIUehPqzi@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:48 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the SK-RZG1M board dependent part of the Ether device node.
> Enable DHCP and NFS root for the kernel booting.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] reset: uniphier: rename MIO reset to SD reset for Pro5, PXs2, LD20 SoCs
From: Masahiro Yamada @ 2016-10-19 8:23 UTC (permalink / raw)
To: linux-arm-kernel
I made a mistake as for naming for this block. The MIO block is not
implemented for these 3 SoCs in the first place. The current naming
will be a trouble if an SoC with both MIO and SD-ctrl blocks appear
in the future.
This driver has just been merged in the previous merge window.
Rename it before the release.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Philipp,
If you do not mind, may I include this in my PR
along with the "select ARCH_HAS_RESET_CONTROLLER" patches?
.../devicetree/bindings/reset/uniphier-reset.txt | 22 +++++++++++-----------
drivers/reset/reset-uniphier.c | 16 ++++++++--------
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
index e6bbfcc..78cd735 100644
--- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
+++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
@@ -19,12 +19,12 @@ Required properties:
Example:
sysctrl at 61840000 {
- compatible = "socionext,uniphier-ld20-sysctrl",
+ compatible = "socionext,uniphier-ld11-sysctrl",
"simple-mfd", "syscon";
reg = <0x61840000 0x4000>;
reset {
- compatible = "socionext,uniphier-ld20-reset";
+ compatible = "socionext,uniphier-ld11-reset";
#reset-cells = <1>;
};
@@ -32,8 +32,8 @@ Example:
};
-Media I/O (MIO) reset
----------------------
+Media I/O (MIO) reset, SD reset
+-------------------------------
Required properties:
- compatible: should be one of the following:
@@ -41,21 +41,21 @@ Required properties:
"socionext,uniphier-ld4-mio-reset" - for PH1-LD4 SoC.
"socionext,uniphier-pro4-mio-reset" - for PH1-Pro4 SoC.
"socionext,uniphier-sld8-mio-reset" - for PH1-sLD8 SoC.
- "socionext,uniphier-pro5-mio-reset" - for PH1-Pro5 SoC.
- "socionext,uniphier-pxs2-mio-reset" - for ProXstream2/PH1-LD6b SoC.
+ "socionext,uniphier-pro5-sd-reset" - for PH1-Pro5 SoC.
+ "socionext,uniphier-pxs2-sd-reset" - for ProXstream2/PH1-LD6b SoC.
"socionext,uniphier-ld11-mio-reset" - for PH1-LD11 SoC.
- "socionext,uniphier-ld20-mio-reset" - for PH1-LD20 SoC.
+ "socionext,uniphier-ld20-sd-reset" - for PH1-LD20 SoC.
- #reset-cells: should be 1.
Example:
mioctrl at 59810000 {
- compatible = "socionext,uniphier-ld20-mioctrl",
+ compatible = "socionext,uniphier-ld11-mioctrl",
"simple-mfd", "syscon";
reg = <0x59810000 0x800>;
reset {
- compatible = "socionext,uniphier-ld20-mio-reset";
+ compatible = "socionext,uniphier-ld11-mio-reset";
#reset-cells = <1>;
};
@@ -80,12 +80,12 @@ Required properties:
Example:
perictrl at 59820000 {
- compatible = "socionext,uniphier-ld20-perictrl",
+ compatible = "socionext,uniphier-ld11-perictrl",
"simple-mfd", "syscon";
reg = <0x59820000 0x200>;
reset {
- compatible = "socionext,uniphier-ld20-peri-reset";
+ compatible = "socionext,uniphier-ld11-peri-reset";
#reset-cells = <1>;
};
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 8b2558e..968c3ae 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -154,7 +154,7 @@ struct uniphier_reset_data {
UNIPHIER_RESET_END,
};
-const struct uniphier_reset_data uniphier_pro5_mio_reset_data[] = {
+const struct uniphier_reset_data uniphier_pro5_sd_reset_data[] = {
UNIPHIER_MIO_RESET_SD(0, 0),
UNIPHIER_MIO_RESET_SD(1, 1),
UNIPHIER_MIO_RESET_EMMC_HW_RESET(6, 1),
@@ -360,7 +360,7 @@ static int uniphier_reset_probe(struct platform_device *pdev)
.compatible = "socionext,uniphier-ld20-reset",
.data = uniphier_ld20_sys_reset_data,
},
- /* Media I/O reset */
+ /* Media I/O reset, SD reset */
{
.compatible = "socionext,uniphier-sld3-mio-reset",
.data = uniphier_sld3_mio_reset_data,
@@ -378,20 +378,20 @@ static int uniphier_reset_probe(struct platform_device *pdev)
.data = uniphier_sld3_mio_reset_data,
},
{
- .compatible = "socionext,uniphier-pro5-mio-reset",
- .data = uniphier_pro5_mio_reset_data,
+ .compatible = "socionext,uniphier-pro5-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
},
{
- .compatible = "socionext,uniphier-pxs2-mio-reset",
- .data = uniphier_pro5_mio_reset_data,
+ .compatible = "socionext,uniphier-pxs2-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
},
{
.compatible = "socionext,uniphier-ld11-mio-reset",
.data = uniphier_sld3_mio_reset_data,
},
{
- .compatible = "socionext,uniphier-ld20-mio-reset",
- .data = uniphier_pro5_mio_reset_data,
+ .compatible = "socionext,uniphier-ld20-sd-reset",
+ .data = uniphier_pro5_sd_reset_data,
},
/* Peripheral reset */
{
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] base: soc: Introduce soc_device_match() interface
From: Greg Kroah-Hartman @ 2016-10-19 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-3-git-send-email-geert+renesas@glider.be>
On Tue, Oct 04, 2016 at 11:09:25AM +0200, Geert Uytterhoeven wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> We keep running into cases where device drivers want to know the exact
> version of the a SoC they are currently running on. In the past, this has
> usually been done through a vendor specific API that can be called by a
> driver, or by directly accessing some kind of version register that is
> not part of the device itself but that belongs to a global register area
> of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data about
> on-chip devices, but just announces their presence using boot-time
> platform devices, and the machine code itself does not care about the
> revision.
>
> - There is existing firmware or boot loaders with existing DT binaries
> with generic compatible strings that do not identify the particular
> revision of each device, but the driver knows which SoC revisions
> include which part.
>
> - A prerelease version of a chip has some quirks and we are using the same
> version of the bootloader and the DT blob on both the prerelease and the
> final version. An update of the DT binding seems inappropriate because
> that would involve maintaining multiple copies of the dts and/or
> bootloader.
>
> This patch introduces the soc_device_match() interface that is meant to
> work like of_match_node() but instead of identifying the version of a
> device, it identifies the SoC itself using a vendor-agnostic interface.
>
> Unlike of_match_node(), we do not do an exact string compare but instead
> use glob_match() to allow wildcards in strings.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/sys_soc.h | 3 +++
> 3 files changed, 70 insertions(+)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH 3/4] base: soc: Check for NULL SoC device attributes
From: Greg Kroah-Hartman @ 2016-10-19 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475572167-29581-4-git-send-email-geert+renesas@glider.be>
On Tue, Oct 04, 2016 at 11:09:26AM +0200, Geert Uytterhoeven wrote:
> If soc_device_match() is used to check the value of a specific
> attribute that is not present for the current SoC, the kernel crashes
> with a NULL pointer dereference.
>
> Fix this by explicitly checking for the absence of a needed property,
> and considering this a non-match.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Bartosz Golaszewski @ 2016-10-19 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4369153.vCOQzI7OET@avalon>
2016-10-18 22:49 GMT+02:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
>> Create the driver for the da8xx System Configuration and implement
>> support for writing to the three Master Priority registers.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[snip]
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,da850-syscfg"
>
> Don't you need a reg property ?
>
Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>> +Optional properties:
>> +
>> +The below properties are used to specify the priority of master
>> peripherals.
>> +They must be between 0-7 where 0 is the highest priority and 7 is the
>> lowest.
>> +
>> +- ti,pri-arm-i: ARM_I port priority.
>> +
>> +- ti,pri-arm-d: ARM_D port priority.
>> +
>> +- ti,pri-upp: uPP port priority.
>> +
>> +- ti,pri-sata: SATA port priority.
>> +
>> +- ti,pri-pru0: PRU0 port priority.
>> +
>> +- ti,pri-pru1: PRU1 port priority.
>> +
>> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
>> +
>> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
>> +
>> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
>> +
>> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
>> +
>> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
>> +
>> +- ti,pri-emac: EMAC port priority.
>> +
>> +- ti,pri-usb0cfg: USB0 CFG port priority.
>> +
>> +- ti,pri-usb0cdma: USB0 CDMA port priority.
>> +
>> +- ti,pri-uhpi: HPI port priority.
>> +
>> +- ti,pri-usb1: USB1 port priority.
>> +
>> +- ti,pri-lcdc: LCDC port priority.
>
> I'm afraid this looks more like system configuration than hardware description
> to me.
>
While you're certainly right, this approach is already implemented in
several other memory and bus drivers and it was also suggested by
Sekhar in one of the tilcdc rev1 threads. There's also no real
alternative that I know of.
> There was a BoF session about how to support this kind of performance knobs at
> ELCE last week: https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-performance-framework-michael-turquette-baylibre :-)
>
I know, I was there. ;)
Unfortunately it was just a discussion about potential approaches -
there's no code yet.
Thanks,
Bartosz
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: gregkh at linuxfoundation.org @ 2016-10-19 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0401MB2529BA70C6E7AF7C71631A47F8D20@AM5PR0401MB2529.eurprd04.prod.outlook.com>
On Wed, Oct 19, 2016 at 02:47:07AM +0000, Y.B. Lu wrote:
> + Greg
>
> Hi Greg,
>
> I submitted this patchset for a MMC bug fix, and introduce the below patch which needs your ACK.
> > > Arnd Bergmann (1):
> > > base: soc: introduce soc_device_match() interface
> https://patchwork.kernel.org/patch/9342913/
>
> Could you help to review it and give some comments or ACK.
> Thank you very much.
Now acked.
^ permalink raw reply
* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Masahiro Yamada @ 2016-10-19 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112548.GA11471@vireshk-i7>
Hi Viresh,
2016-10-18 20:25 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> On 16-10-16, 23:59, Masahiro Yamada wrote:
>> + cluster0_opp: opp_table {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + opp at 245000000 {
>> + opp-hz = /bits/ 64 <245000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 250000000 {
>> + opp-hz = /bits/ 64 <250000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 490000000 {
>> + opp-hz = /bits/ 64 <490000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 500000000 {
>> + opp-hz = /bits/ 64 <500000000>;
>> + clock-latency-ns = <300>;
>> + };
>> + opp at 653333333 {
>
> Why isn't ^^ matching with below values ? Same in next patch as well.
When I try to update /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq,
it did not work as I had expected.
scaling_max_freq is specified by kHz unit,
on the other hand, clock frequency in the clk driver is specified by Hz.
If the operating point is 653333kHz, the cpufreq requests
the clk driver to set 653333000, but it is lower than
the exact clock, 653333333.
So, the next lower frequency, 500000000 is selected.
As a result, the operating point 653333kHz is never enabled.
So, the operating point must be equal or a little bit bigger.
Do you know a better way to solve this distortion?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v2 0/6] STM32F4 Add RTC & QSPI clocks
From: Gabriel Fernandez @ 2016-10-19 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018235108.GP8871@codeaurora.org>
Hi Stephen,
On 10/19/2016 01:51 AM, Stephen Boyd wrote:
> On 10/14, gabriel.fernandez at st.com wrote:
>> Gabriel Fernandez (6):
>> clk: stm32f4: Add LSI & LSE clocks
>> ARM: dts: stm32f429: add LSI and LSE clocks
>> arm: stmf32: Enable SYSCON
>> clk: stm32f4: Add RTC clock
>> clk: stm32f469: Add QSPI clock
>> ARM: dts: stm32f429: Add QSPI clock
> Can the clk patches be picked without causing problems for
> existing dt changes? Do you want an ack from clk maintainers
> instead of us picking the clk patches up? The series has
> intermingled clk and dts changes so I'm confused.
>
Thanks for reviewing.
Normally DT patches will be taken by STM32 maintainer, but yes there is
a dependency between patch 1 & 2, so if you push the patch 1 into
clk-next tree you have to take also patch 2.
You have to be synchronized with Alexandre Torgue.
Best Regards
Gabriel
^ permalink raw reply
* [PATCH v3 06/11] ARM: dts: r8a7743: add [H]SCIF{A|B} support
From: Geert Uytterhoeven @ 2016-10-19 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14213508.lp3q5ZvmbF@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:41 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe [H]SCIF[AB] ports in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
With the modifications indicated below:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -162,6 +162,267 @@
> #dma-cells = <1>;
> dma-channels = <15>;
> };
> +
> + scifa0: serial at e6c40000 {
> + compatible = "renesas,scifa-r8a7743",
> + "renesas,rzg-scifa", "renesas,scifa";
Please use "renesas,rcar-gen2-scifa" instead of "renesas,rzg-scifa".
> + scifb0: serial at e6c20000 {
> + compatible = "renesas,scifb-r8a7743",
> + "renesas,rzg-scifb", "renesas,scifb";
"renesas,rcar-gen2-scifb"
> + scif0: serial at e6e60000 {
> + compatible = "renesas,scif-r8a7743", "renesas,rzg-scif",
"renesas,rcar-gen2-scif"
> + hscif0: serial at e62c0000 {
> + compatible = "renesas,hscif-r8a7743",
> + "renesas,rzg-hscif", "renesas,hscif";
"renesas,rcar-gen2-hscif"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Lorenzo Pieralisi @ 2016-10-19 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d228f5f-8fb8-91f4-4572-4aeda679d36e@arm.com>
On Mon, Oct 17, 2016 at 06:31:58PM +0100, Sudeep Holla wrote:
>
>
> On 23/09/16 15:03, Lorenzo Pieralisi wrote:
> >On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
> >>Current vexpress smp init code detects whether to override the
> >>default smp ops with MCPM smp ops by matching the "cci-400"
> >>compatible string, in that MCPM requires control over CCI ports
> >>to manage low-power states entry/exit.
> >>
> >>The "cci-400" compatible string check is a necessary but not
> >>sufficient condition for MCPM to work, because the cci-400
> >>can be made visible to the kernel, but firmware can nonetheless
> >>disable non-secure CCI ports control, while still allowing PMU
> >>access; if booted in non-secure world, the kernel would still
> >>blindly override smp operations with MCPM operations, resulting
> >>in kernel faults when the CCI ports programming interface is
> >>accessed from non-secure world.
> >>
> >>This means that the "cci-400" compatible string check would
> >>result in a false positive in systems that eg boot in HYP mode,
> >>where CCI ports non-secure access is explicitly not allowed,
> >>and it is reported in the respective device tree nodes with
> >>CCI ports marked as disabled.
> >>
> >>Refactor the smp operations initialization to make sure that
> >>the kernel is actually allowed to take control over CCI ports
> >>(by enabling MCPM smp operations) before overriding default
> >>vexpress smp operations.
> >>
> >>Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>Cc: Liviu Dudau <liviu.dudau@arm.com>
> >>Cc: Sudeep Holla <sudeep.holla@arm.com>
> >>Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> >>Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>---
> >> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
> >> 1 file changed, 24 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> >>index 8b8d072..6cfd782 100644
> >>--- a/arch/arm/mach-vexpress/platsmp.c
> >>+++ b/arch/arm/mach-vexpress/platsmp.c
> >>@@ -26,17 +26,34 @@
> >> bool __init vexpress_smp_init_ops(void)
> >> {
> >> #ifdef CONFIG_MCPM
> >>+ int cpu;
> >>+ struct device_node *cpu_node, *cci_node;
> >>+
> >> /*
> >>- * The best way to detect a multi-cluster configuration at the moment
> >>- * is to look for the presence of a CCI in the system.
> >>+ * The best way to detect a multi-cluster configuration
> >>+ * is to detect if the kernel can take over CCI ports
> >>+ * control. Loop over possible CPUs and check if CCI
> >>+ * port control is available.
> >> * Override the default vexpress_smp_ops if so.
> >> */
> >>- struct device_node *node;
> >>- node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
> >>- if (node && of_device_is_available(node)) {
> >>- mcpm_smp_set_ops();
> >>- return true;
> >>+ for_each_possible_cpu(cpu) {
> >>+ bool available;
> >>+
> >>+ cpu_node = of_get_cpu_node(cpu, NULL);
> >>+ if (WARN(!cpu_node, "Missing cpu device node!"))
> >>+ return false;
> >>+
> >>+ cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
> >>+ available = cci_node && of_device_is_available(cci_node);
> >>+ of_node_put(cci_node);
> >>+ of_node_put(cpu_node);
> >>+
> >>+ if (!available)
> >>+ return false;
> >> }
> >>+
> >>+ mcpm_smp_set_ops();
> >>+ return true;
> >> #endif
> >> return false;
> >
> >For the records, while moving the code around I missed I was ending
> >up with this idiotic double return, I have already reworked the patch
> >and will squash changes in the final version if we agree on the bulk of
> >the code.
> >
>
> I applied both patches to [1] with the fix for the above issue. Let me
> know if that's fine. I have tested both hyp mode boot and SVC mode +
> MCPM boot with latest u-boot by just fliping a bit in the firmware
> (board.txt) without recompiling the kernel.
I updated the patch to remove the double return will send an updated
patch today.
Thanks !
Lorenzo
>
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress/for-next
>
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Lorenzo Stoakes @ 2016-10-19 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019081352.GB7562@dhcp22.suse.cz>
On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > This patch removes the write parameter from __access_remote_vm() and replaces it
> > > with a gup_flags parameter as use of this function previously _implied_
> > > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> > >
> > > We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> > > (and hence bugs) within the mm subsystem.
> > >
> > > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> >
> > So I'm not convinced this (and the following two patches) is actually
> > helping much. By grepping for FOLL_FORCE we will easily see that any caller
> > of access_remote_vm() gets that semantics and can thus continue search
>
> I am really wondering. Is there anything inherent that would require
> FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
> non-trivial thing. It doesn't obey vma permissions so we should really
> minimize its usage. Do all of those users really need FOLL_FORCE?
I wonder about this also, for example by accessing /proc/self/mem you trigger
access_remote_vm() and consequently get_user_pages_remote() meaning FOLL_FORCE
is implied and you can use /proc/self/mem to override any VMA permissions. I
wonder if this is desirable behaviour or whether this ought to be limited to
ptrace system calls. Regardless, by making the flag more visible it makes it
easier to see that this is happening.
Note that this /proc/self/mem behaviour is what triggered the bug that brought
about this discussion in the first place -
https://marc.info/?l=linux-mm&m=147363447105059 - as using /proc/self/mem this
way on PROT_NONE memory broke some assumptions.
On the other hand I see your point Jan in that you know any caller of these
functions will have FOLL_FORCE implied, and you have to decide to stop passing
the flag at _some_ point in the stack, however it seems fairly sane to have that
stopping point exist outside of exported gup functions so the gup interface
forces explicitness but callers can wrap things as they need.
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Will Deacon @ 2016-10-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019030333.GA1269@gondor.apana.org.au>
On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel 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.
> > >
> > > I think for future reference, the Fixes tag should denote the commit
> > > that introduced the issue. An explicit Cc: stable tag would state how
> > > far back it should be applied.
> > >
> >
> > OK, that sounds reasonable.
> >
> > >> 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
> > >
> > > The changes look fine to me but I can't claim I fully understand these
> > > algorithms. FWIW:
> > >
> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > (Will may pick them up for 4.9-rcX)
> >
> > Thanks, although I was kind of expecting Herbert to pick these up,
> > given that #8 affects ARM not arm64.
> >
> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
> > can drop #8 into rmk's patch database.
>
> I was planning merging these for 4.10. But I'm fine with them
> going through the arm tree. Let me know what you guys want to
> do.
I assumed you'd take them through crypto, as per usual, so I didn't
queue anything in the arm64 tree.
Ard -- were you planning to get these in for 4.9?
Will
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-19 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019084607.GB9193@arm.com>
On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
>> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
>> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel 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.
>> > >
>> > > I think for future reference, the Fixes tag should denote the commit
>> > > that introduced the issue. An explicit Cc: stable tag would state how
>> > > far back it should be applied.
>> > >
>> >
>> > OK, that sounds reasonable.
>> >
>> > >> 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
>> > >
>> > > The changes look fine to me but I can't claim I fully understand these
>> > > algorithms. FWIW:
>> > >
>> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> > >
>> > > (Will may pick them up for 4.9-rcX)
>> >
>> > Thanks, although I was kind of expecting Herbert to pick these up,
>> > given that #8 affects ARM not arm64.
>> >
>> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
>> > can drop #8 into rmk's patch database.
>>
>> I was planning merging these for 4.10. But I'm fine with them
>> going through the arm tree. Let me know what you guys want to
>> do.
>
> I assumed you'd take them through crypto, as per usual, so I didn't
> queue anything in the arm64 tree.
>
> Ard -- were you planning to get these in for 4.9?
>
These are arguably bug fixes, but I spotted them by accident, they
weren't reported to me or anything. But it seems strange to add a cc
stable and then hold off until the next merge window.
In any case, I don't care deeply either way, as long as they get
merged in the end. I think it makes sense to keep them together (arm64
+ ARM), so Herbert's tree is a more natural route for them to take. I
will leave it up to Herbert whether they are sent onward as fixes or
as part of v4.10
Thanks,
Ard.
^ 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