Re: [PATCH] ibmvfc: fix WARN_ON during event pool release

2019-07-24 Thread Martin K. Petersen


Tyrel,

> While removing an ibmvfc client adapter a WARN_ON like the following
> WARN_ON is seen in the kernel log:

Applied to 5.3/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] crypto: nx: nx-842-powernv: Add of_node_put() before return

2019-07-24 Thread Stewart Smith
Nishka Dasgupta  writes:
> Each iteration of for_each_child_of_node puts the previous node, but

This is for_each_compatible_node.

otherwise looks okay,

Acked-by: Stewart Smith 

-- 
Stewart Smith
OPAL Architect, IBM.


[PATCH v5 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define

2019-07-24 Thread Ran Wang
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.

Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.

Signed-off-by: Ran Wang 
Reviewed-by: Rob Herring 
---
Change in v5:
- Add 'Reviewed-by: Rob Herring ' to commit message.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
- Adjust indectation of 'ls1021a, ls1012a, ls1043a, ls1046a'.

Change in v3:
- None.

Change in v2:
- None.

 Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index e284e4e..5a33619 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -5,7 +5,7 @@ and power management.
 
 Required properites:
   - reg : Offset and length of the register set of the RCPM block.
-  - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
+  - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
fsl,rcpm-wakeup property.
   - compatible : Must contain a chip-specific RCPM block compatible string
and (if applicable) may contain a chassis-version RCPM compatible
@@ -20,6 +20,7 @@ Required properites:
* "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+   * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm
 
 All references to "1.0" and "2.0" refer to the QorIQ chassis version to
 which the chip complies.
@@ -27,14 +28,19 @@ Chassis Version Example Chips
 ------
 1.0p4080, p5020, p5040, p2041, p3041
 2.0t4240, b4860, b4420
-2.1t1040, ls1021
+2.1t1040,
+2.1+   ls1021a, ls1012a, ls1043a, ls1046a
+
+Optional properties:
+ - little-endian : RCPM register block is Little Endian. Without it RCPM
+   will be Big Endian (default case).
 
 Example:
 The RCPM node for T4240:
rcpm: global-utilities@e2000 {
compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
reg = <0xe2000 0x1000>;
-   fsl,#rcpm-wakeup-cells = <2>;
+   #fsl,rcpm-wakeup-cells = <2>;
};
 
 * Freescale RCPM Wakeup Source Device Tree Bindings
@@ -44,7 +50,7 @@ can be used as a wakeup source.
 
   - fsl,rcpm-wakeup: Consists of a phandle to the rcpm node and the IPPDEXPCR
register cells. The number of IPPDEXPCR register cells is defined in
-   "fsl,#rcpm-wakeup-cells" in the rcpm node. The first register cell is
+   "#fsl,rcpm-wakeup-cells" in the rcpm node. The first register cell is
the bit mask that should be set in IPPDEXPCR0, and the second register
cell is for IPPDEXPCR1, and so on.
 
-- 
2.7.4



[PATCH v5 3/3] soc: fsl: add RCPM driver

2019-07-24 Thread Ran Wang
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.

This driver depends on PM wakeup source framework which help to
collect wake information.

Signed-off-by: Ran Wang 
Acked-by: Pavel Machek 
---
Change in v5:
- Fix v4 regression of the return value of wakeup_source_get_next()
didn't pass to ws in while loop.
- Rename wakeup_source member 'attached_dev' to 'dev'.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
- Remove extra ',' in author line of rcpm.c
- Update usage of wakeup_source_get_next() to be less confusing to the
reader, code logic remain the same.

Change in v3:
- Some whitespace ajdustment.

Change in v2:
- Rebase Kconfig and Makefile update to latest mainline.

 drivers/soc/fsl/Kconfig  |   8 +++
 drivers/soc/fsl/Makefile |   1 +
 drivers/soc/fsl/rcpm.c   | 126 +++
 3 files changed, 135 insertions(+)
 create mode 100644 drivers/soc/fsl/rcpm.c

diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index f9ad8ad..4918856 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -40,4 +40,12 @@ config DPAA2_CONSOLE
  /dev/dpaa2_mc_console and /dev/dpaa2_aiop_console,
  which can be used to dump the Management Complex and AIOP
  firmware logs.
+
+config FSL_RCPM
+   bool "Freescale RCPM support"
+   depends on PM_SLEEP
+   help
+ The NXP QorIQ Processors based on ARM Core have RCPM module
+ (Run Control and Power Management), which performs all device-level
+ tasks associated with power management, such as wakeup source control.
 endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 71dee8d..906f1cd 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_FSL_DPAA) += qbman/
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_RCPM) += rcpm.o
 obj-$(CONFIG_FSL_GUTS) += guts.o
 obj-$(CONFIG_FSL_MC_DPIO)  += dpio/
 obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 000..02244a1
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// rcpm.c - Freescale QorIQ RCPM driver
+//
+// Copyright 2019 NXP
+//
+// Author: Ran Wang 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RCPM_WAKEUP_CELL_MAX_SIZE  7
+
+struct rcpm {
+   unsigned intwakeup_cells;
+   void __iomem*ippdexpcr_base;
+   boollittle_endian;
+};
+
+static int rcpm_pm_prepare(struct device *dev)
+{
+   struct device_node  *np = dev->of_node;
+   struct wakeup_source*ws;
+   struct rcpm *rcpm;
+   u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
+   int i, ret;
+
+   rcpm = dev_get_drvdata(dev);
+   if (!rcpm)
+   return -EINVAL;
+
+   /* Begin with first registered wakeup source */
+   ws = NULL;
+   while (ws = wakeup_source_get_next(ws)) {
+   /* skip object which is not attached to device */
+   if (!ws->dev)
+   continue;
+
+   ret = device_property_read_u32_array(ws->dev,
+   "fsl,rcpm-wakeup", value, rcpm->wakeup_cells + 
1);
+
+   /*  Wakeup source should refer to current rcpm device */
+   if (ret || (np->phandle != value[0])) {
+   dev_info(dev, "%s doesn't refer to this rcpm\n",
+   ws->name);
+   continue;
+   }
+
+   for (i = 0; i < rcpm->wakeup_cells; i++) {
+   /* We can only OR related bits */
+   if (value[i + 1]) {
+   if (rcpm->little_endian) {
+   tmp = ioread32(rcpm->ippdexpcr_base + i 
* 4);
+   tmp |= value[i + 1];
+   iowrite32(tmp, rcpm->ippdexpcr_base + i 
* 4);
+   } else {
+   tmp = ioread32be(rcpm->ippdexpcr_base + 
i * 4);
+   tmp |= value[i + 1];
+   iowrite32be(tmp, rcpm->ippdexpcr_base + 
i * 4);
+   }
+   }
+   }
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops rcpm_pm_ops = {
+   .prepare =  rcpm_pm_prepare,
+}

[PATCH v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

2019-07-24 Thread Ran Wang
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects on that list and return them one by one.

Signed-off-by: Ran Wang 
---
Change in v5:
- Update commit message, add decription of walk through all wakeup
source objects.
- Add SCU protection in function wakeup_source_get_next().
- Rename wakeup_source member 'attached_dev' to 'dev' and move it up
(before wakeirq).

Change in v4:
- None.

Change in v3:
- Adjust indentation of *attached_dev;.

Change in v2:
- None.

 drivers/base/power/wakeup.c | 24 
 include/linux/pm_wakeup.h   |  3 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index ee31d4f..2fba891 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -226,6 +227,28 @@ void wakeup_source_unregister(struct wakeup_source *ws)
}
 }
 EXPORT_SYMBOL_GPL(wakeup_source_unregister);
+/**
+ * wakeup_source_get_next - Get next wakeup source from the list
+ * @ws: Previous wakeup source object, null means caller want first one.
+ */
+struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
+{
+   struct list_head *ws_head = &wakeup_sources;
+   struct wakeup_source *next_ws = NULL;
+   int idx;
+
+   idx = srcu_read_lock(&wakeup_srcu);
+   if (ws)
+   next_ws = list_next_or_null_rcu(ws_head, &ws->entry,
+   struct wakeup_source, entry);
+   else
+   next_ws = list_entry_rcu(ws_head->next,
+   struct wakeup_source, entry);
+   srcu_read_unlock(&wakeup_srcu, idx);
+
+   return next_ws;
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_next);
 
 /**
  * device_wakeup_attach - Attach a wakeup source object to a device object.
@@ -242,6 +265,7 @@ static int device_wakeup_attach(struct device *dev, struct 
wakeup_source *ws)
return -EEXIST;
}
dev->power.wakeup = ws;
+   ws->dev = dev;
if (dev->power.wakeirq)
device_wakeup_attach_irq(dev, dev->power.wakeirq);
spin_unlock_irq(&dev->power.lock);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 9102760..fc23c1a 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -23,6 +23,7 @@ struct wake_irq;
  * @name: Name of the wakeup source
  * @entry: Wakeup source list entry
  * @lock: Wakeup source lock
+ * @dev: The device it attached to
  * @wakeirq: Optional device specific wakeirq
  * @timer: Wakeup timer list
  * @timer_expires: Wakeup timer expiration
@@ -42,6 +43,7 @@ struct wakeup_source {
const char  *name;
struct list_headentry;
spinlock_t  lock;
+   struct device   *dev;
struct wake_irq *wakeirq;
struct timer_list   timer;
unsigned long   timer_expires;
@@ -88,6 +90,7 @@ extern void wakeup_source_add(struct wakeup_source *ws);
 extern void wakeup_source_remove(struct wakeup_source *ws);
 extern struct wakeup_source *wakeup_source_register(const char *name);
 extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
 extern int device_wakeup_enable(struct device *dev);
 extern int device_wakeup_disable(struct device *dev);
 extern void device_set_wakeup_capable(struct device *dev, bool capable);
-- 
2.7.4



[PATCH v2] crypto: nx: nx-842-powernv: Add of_node_put() before return

2019-07-24 Thread Nishka Dasgupta
Each iteration of for_each_compatible_node puts the previous node, but
in the case of a return from the middle of the loop, there is no put,
thus causing a memory leak. Add an of_node_put before the return.
Issue found with Coccinelle.

Acked-by: Stewart Smith 
Signed-off-by: Nishka Dasgupta 

---
Changes in v2:
- Fixed commit message to match the loop in question.

 drivers/crypto/nx/nx-842-powernv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index e78ff5c65ed6..c037a2403b82 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -1020,6 +1020,7 @@ static __init int nx842_powernv_init(void)
ret = nx842_powernv_probe_vas(dn);
if (ret) {
nx842_delete_coprocs();
+   of_node_put(dn);
return ret;
}
}
-- 
2.19.1



[PATCH 1/5] powerpc/64s/radix: Fix memory hotplug section page table creation

2019-07-24 Thread Nicholas Piggin
create_physical_mapping expects physical addresses, but creating and
splitting these mappings after boot is supplying virtual (effective)
addresses. This can be irritated by booting with mem= to limit memory
then probing an unused physical memory range:

  echo  > /sys/devices/system/memory/probe

This mostly works by accident, firstly because __va(__va(x)) == __va(x)
so the virtual address does not get corrupted. Secondly because pfn_pte
masks out the upper bits of the pfn beyond the physical address limit,
so a pfn constructed with a 0xc000 virtual linear address
will be masked back to the correct physical address in the pte.

Cc: Reza Arbab 
Fixes: 6cc27341b21a8 ("powerpc/mm: add radix__create_section_mapping()")
Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c 
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index b4ca9e95e678..c5cc16ab1954 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -902,7 +902,7 @@ int __meminit radix__create_section_mapping(unsigned long 
start, unsigned long e
return -1;
}
 
-   return create_physical_mapping(start, end, nid);
+   return create_physical_mapping(__pa(start), __pa(end), nid);
 }
 
 int __meminit radix__remove_section_mapping(unsigned long start, unsigned long 
end)
-- 
2.22.0



[PATCH 2/5] powerpc/64s/radix: Fix memory hot-unplug page table split

2019-07-24 Thread Nicholas Piggin
create_physical_mapping expects physical addresses, but splitting
these mapping on hot unplug is supplying virtual (effective)
addresses.

[I'm not sure how to test this one]

Cc: Balbir Singh 
Fixes: 4dd5f8a99e791 ("powerpc/mm/radix: Split linear mapping on hot-unplug")
Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c 
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index c5cc16ab1954..2204d8eeb784 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -737,8 +737,8 @@ static int __meminit stop_machine_change_mapping(void *data)
 
spin_unlock(&init_mm.page_table_lock);
pte_clear(&init_mm, params->aligned_start, params->pte);
-   create_physical_mapping(params->aligned_start, params->start, -1);
-   create_physical_mapping(params->end, params->aligned_end, -1);
+   create_physical_mapping(__pa(params->aligned_start), 
__pa(params->start), -1);
+   create_physical_mapping(__pa(params->end), __pa(params->aligned_end), 
-1);
spin_lock(&init_mm.page_table_lock);
return 0;
 }
-- 
2.22.0



[PATCH 3/5] powerpc/perf: fix imc allocation failure handling

2019-07-24 Thread Nicholas Piggin
The alloc_pages_node return value should be tested for failure
before being passed to page_address.

Cc: Madhavan Srinivasan 
Tested-by: Anju T Sudhakar 
Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/perf/imc-pmu.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index dea243185ea4..cb50a9e1fd2d 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -577,6 +577,7 @@ static int core_imc_mem_init(int cpu, int size)
 {
int nid, rc = 0, core_id = (cpu / threads_per_core);
struct imc_mem_info *mem_info;
+   struct page *page;
 
/*
 * alloc_pages_node() will allocate memory for core in the
@@ -587,11 +588,12 @@ static int core_imc_mem_init(int cpu, int size)
mem_info->id = core_id;
 
/* We need only vbase for core counters */
-   mem_info->vbase = page_address(alloc_pages_node(nid,
- GFP_KERNEL | __GFP_ZERO | 
__GFP_THISNODE |
- __GFP_NOWARN, get_order(size)));
-   if (!mem_info->vbase)
+   page = alloc_pages_node(nid,
+   GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE |
+   __GFP_NOWARN, get_order(size));
+   if (!page)
return -ENOMEM;
+   mem_info->vbase = page_address(page);
 
/* Init the mutex */
core_imc_refc[core_id].id = core_id;
@@ -849,15 +851,17 @@ static int thread_imc_mem_alloc(int cpu_id, int size)
int nid = cpu_to_node(cpu_id);
 
if (!local_mem) {
+   struct page *page;
/*
 * This case could happen only once at start, since we dont
 * free the memory in cpu offline path.
 */
-   local_mem = page_address(alloc_pages_node(nid,
+   page = alloc_pages_node(nid,
  GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE |
- __GFP_NOWARN, get_order(size)));
-   if (!local_mem)
+ __GFP_NOWARN, get_order(size));
+   if (!page)
return -ENOMEM;
+   local_mem = page_address(page);
 
per_cpu(thread_imc_mem, cpu_id) = local_mem;
}
@@ -1095,11 +1099,14 @@ static int trace_imc_mem_alloc(int cpu_id, int size)
int core_id = (cpu_id / threads_per_core);
 
if (!local_mem) {
-   local_mem = page_address(alloc_pages_node(phys_id,
-   GFP_KERNEL | __GFP_ZERO | 
__GFP_THISNODE |
-   __GFP_NOWARN, get_order(size)));
-   if (!local_mem)
+   struct page *page;
+
+   page = alloc_pages_node(phys_id,
+   GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE |
+   __GFP_NOWARN, get_order(size));
+   if (!page)
return -ENOMEM;
+   local_mem = page_address(page);
per_cpu(trace_imc_mem, cpu_id) = local_mem;
 
/* Initialise the counters for trace mode */
-- 
2.22.0



[PATCH 4/5] powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses

2019-07-24 Thread Nicholas Piggin
Ensure __va is given a physical address below PAGE_OFFSET, and __pa is
given a virtual address above PAGE_OFFSET.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/page.h | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 0d52f57fca04..c8bb14ff4713 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -215,9 +215,19 @@ static inline bool pfn_valid(unsigned long pfn)
 /*
  * gcc miscompiles (unsigned long)(&static_var) - PAGE_OFFSET
  * with -mcmodel=medium, so we use & and | instead of - and + on 64-bit.
+ * This also results in better code generation.
  */
-#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET))
-#define __pa(x) ((unsigned long)(x) & 0x0fffUL)
+#define __va(x)
\
+({ \
+   VIRTUAL_BUG_ON((unsigned long)(x) >= PAGE_OFFSET);  \
+   (void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET);\
+})
+
+#define __pa(x)
\
+({ \
+   VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);   \
+   (unsigned long)(x) & 0x0fffUL;  \
+})
 
 #else /* 32-bit, non book E */
 #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + PAGE_OFFSET - 
MEMORY_START))
-- 
2.22.0



[PATCH 5/5] powerpc/64s/radix: Remove redundant pfn_pte bitop, add VM_BUG_ON

2019-07-24 Thread Nicholas Piggin
pfn_pte is never given a pte above the addressable physical memory
limit, so the masking is redundant. In case of a software bug, it
is not obviously better to silently truncate the pfn than to corrupt
the pte (either one will result in memory corruption or crashes),
so there is no reason to add this to the fast path.

Add VM_BUG_ON to catch cases where the pfn is invalid. These would
catch the create_section_mapping bug fixed by a previous commit.

  [16885.256466] [ cut here ]
  [16885.256492] kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612!
  cpu 0x0: Vector: 700 (Program Check) at [c000ee0a36d0]
  pc: c0080738: __map_kernel_page+0x248/0x6f0
  lr: c0080ac0: __map_kernel_page+0x5d0/0x6f0
  sp: c000ee0a3960
 msr: 90029033
current = 0xc000ec63b400
paca= 0xc17f   irqmask: 0x03   irq_happened: 0x01
  pid   = 85, comm = sh
  kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612!
  Linux version 5.3.0-rc1-1-g0fe93e5f3394
  enter ? for help
  [c000ee0a3a00] c0d37378 create_physical_mapping+0x260/0x360
  [c000ee0a3b10] c0d370bc create_section_mapping+0x1c/0x3c
  [c000ee0a3b30] c0071f54 arch_add_memory+0x74/0x130

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 8308f32e9782..8e47fb85dfa6 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -608,8 +608,10 @@ static inline bool pte_access_permitted(pte_t pte, bool 
write)
  */
 static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot)
 {
-   return __ptepte_basic_t)(pfn) << PAGE_SHIFT) & PTE_RPN_MASK) |
-pgprot_val(pgprot));
+   VM_BUG_ON(pfn >> (64 - PAGE_SHIFT));
+   VM_BUG_ON((pfn << PAGE_SHIFT) & ~PTE_RPN_MASK);
+
+   return __pte(((pte_basic_t)pfn << PAGE_SHIFT) | pgprot_val(pgprot));
 }
 
 static inline unsigned long pte_pfn(pte_t pte)
-- 
2.22.0



Re: [alsa-devel] [PATCH 05/10] ASoC: fsl_sai: Add support to enable multiple data lines

2019-07-24 Thread Daniel Baluta
On Mon, Jul 22, 2019 at 3:58 PM Lucas Stach  wrote:
>
> Am Montag, den 22.07.2019, 15:48 +0300 schrieb Daniel Baluta:
> > SAI supports up to 8 Rx/Tx data lines which can be enabled
> > using TCE/RCE bits of TCR3/RCR3 registers.
> >
> > Data lines to be enabled are read from DT fsl,dl_mask property.
> > By default (if no DT entry is provided) only data line 0 is enabled.
> >
> > Note:
> > We can only enable consecutive data lines starting with data line #0.
>
> Why is the property a bitmask then? To me this sounds like we want to
> have the number of lanes in the DT and convert to the bitmask inside
> the driver.

Actually my comment might be wrong. I have read the documentation again
and it seems that: We can only enable consecutive data lines
*ONLY* if combine mode is enabled.

Thus, if combine mode is disabled we can independently enable any data
line. I will clarify this with IP owner and correct the patch accordingly.

>
> > > Signed-off-by: Daniel Baluta 
> > ---
> >  sound/soc/fsl/fsl_sai.c | 10 +-
> >  sound/soc/fsl/fsl_sai.h |  6 --
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index 768341608695..d0fa02188b7c 100644
> > --- a/sound/soc/fsl/fsl_sai.c
> > +++ b/sound/soc/fsl/fsl_sai.c
> > @@ -601,7 +601,7 @@ static int fsl_sai_startup(struct snd_pcm_substream 
> > *substream,
> >
> > > regmap_update_bits(sai->regmap, FSL_SAI_xCR3(tx),
> > >FSL_SAI_CR3_TRCE_MASK,
> > > -  FSL_SAI_CR3_TRCE);
> > > +  FSL_SAI_CR3_TRCE(sai->soc_data->dl_mask[tx]);
> >
> > > ret = snd_pcm_hw_constraint_list(substream->runtime, 0,
> > > SNDRV_PCM_HW_PARAM_RATE, &fsl_sai_rate_constraints);
> > @@ -887,6 +887,14 @@ static int fsl_sai_probe(struct platform_device *pdev)
> > > }
> > > }
> >
> > > +   /* active data lines mask for TX/RX, defaults to 1 (only the first
> > > +* data line is enabled
> > +  */
>
> Comment style not in line with Linux coding style.

Will fix. Thanks Lucas for review.
Should be like this, right?
/*
 * comment
 */

checkpatch.pl warned me only about the end of the comment :).


Re: [DOC][PATCH v5 1/4] powerpc: Document some HCalls for Storage Class Memory

2019-07-24 Thread Laurent Dufour

Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :

This doc patch provides an initial description of the HCall op-codes
that are used by Linux kernel running as a guest operating
system (LPAR) on top of PowerVM or any other sPAPR compliant
hyper-visor (e.g qemu).

Apart from documenting the HCalls the doc-patch also provides a
rudimentary overview of how Hcalls are implemented inside the Linux
kernel and how information flows between kernel and PowerVM/KVM.


Hi Vaibhav,

That's a good idea to introduce such a documentation.


Signed-off-by: Vaibhav Jain 
---
Change-log:

v5
* First patch in this patchset.
---
  Documentation/powerpc/hcalls.txt | 140 +++
  1 file changed, 140 insertions(+)
  create mode 100644 Documentation/powerpc/hcalls.txt

diff --git a/Documentation/powerpc/hcalls.txt b/Documentation/powerpc/hcalls.txt
new file mode 100644
index ..cc9dd872cecd
--- /dev/null
+++ b/Documentation/powerpc/hcalls.txt
@@ -0,0 +1,140 @@
+Hyper-visor Call Op-codes (HCALLS)
+
+
+Overview
+=
+
+Virtualization on PPC64 arch is based on the PAPR specification[1] which
+describes run-time environment for a guest operating system and how it should
+interact with the hyper-visor for privileged operations. Currently there are 
two
+PAPR compliant hypervisors (PHYP):
+
+IBM PowerVM: IBM's proprietary hyper-visor that supports AIX, IBM-i and Linux 
as
+supported guests (termed as Logical Partitions or LPARS).
+
+Qemu/KVM:Supports PPC64 linux guests running on a PPC64 linux host.
+
+On PPC64 arch a virtualized guest kernel runs in a non-privileged mode (HV=0).
+Hence to perform a privileged operations the guest issues a Hyper-visor
+Call (HCALL) with necessary input operands. PHYP after performing the privilege
+operation returns a status code and output operands back to the guest.
+
+HCALL ABI
+=
+The ABI specification for a HCall between guest os kernel and PHYP is
+described in [1]. The Opcode for Hcall is set in R3 and subsequent in-arguments
+for the Hcall are provided in registers R4-R12. On return from 'HVCS'
+instruction the status code of HCall is available in R3 an the output 
parameters
+are returned in registers R4-R12.


Would it be good to mention that values passed through the memory must be 
stored in Big Endian format ?



+Powerpc arch code provides convenient wrappers named plpar_hcall_xxx defined in
+header 'hvcall.h' to issue HCalls from the linux kernel running as guest.
+
+
+DRC & DRC Indexes
+=
+
+PAPRGuest
+  DR1  Hypervisor OS
+  +--++--+ +-+
+  |  |<-->|  | |  User   |
+  +--+  DRC1  |  |   DRC   |  Space  |
+ |  |  Index  +-+
+  DR2 |  | | |
+  +--+|  |<--->|  Kernel |
+  |  |<- >|  |  HCall  | |
+  +--+  DRC2  +--+ +-+
+
+PHYP terms shared hardware resources like PCI devices, NVDimms etc available 
for
+use by LPARs as Dynamic Resource (DR). When a DR is allocated to an LPAR, PHYP
+creates a data-structure called Dynamic Resource Connector (DRC) to manage LPAR
+access. An LPAR refers to a DRC via an opaque 32-bit number called DRC-Index.
+The DRC-index value is provided to the LPAR via device-tree where its present
+as an attribute in the device tree node associated with the DR.


Should you use the term 'Hypervisor' instead of 'PHYP' which is not usually 
designing only the proprietary one ?


Thanks,
Laurent.


+
+HCALL Op-codes
+==
+
+Below is a partial of of HCALLs that are supported by PHYP. For the
+corresponding opcode values please look into the header
+'arch/powerpc/include/asm/hvcall.h' :
+
+* H_SCM_READ_METADATA:
+  Input: drcIndex, offset, buffer-address, numBytesToRead
+  Out: None
+  Description:
+  Given a DRC Index of an NVDimm, read N-bytes from the the meta data area
+  associated with it, at a specified offset and copy it to provided buffer.
+  The metadata area stores configuration information such as label information,
+  bad-blocks etc. The metadata area is located out-of-band of NVDimm storage
+  area hence a separate access semantics is provided.
+
+* H_SCM_WRITE_METADATA:
+  Input: drcIndex, offset, data, numBytesToWrite
+  Out: None
+  Description:
+  Given a DRC Index of an NVDimm, write N-bytes from provided buffer at the
+  given offset to the the meta data area associated with the NVDimm.
+
+
+* H_SCM_BIND_MEM:
+  Input: drcIndex, startingScmBlockIndex, numScmBlocksToBind, targetAddress
+  Out: guestMappedAddress, numScmBlockBound
+  Description:
+  Given a DRC-Index of an NVDimm, maps the SCM (Storage Class Memory) blocks to
+  continuous logical addresses in guest physical address space. The HCALL
+  arguments can be used to map partial range of SCM blocks instead of entire
+  NVDimm range to the LP

Re: [PATCH v5 4/4] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails

2019-07-24 Thread Laurent Dufour

Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :

In some cases initial bind of scm memory for an lpar can fail if
previously it wasn't released using a scm-unbind hcall. This situation
can arise due to panic of the previous kernel or forced lpar
fadump. In such cases the H_SCM_BIND_MEM return a H_OVERLAP error.

To mitigate such cases the patch updates papr_scm_probe() to force a
call to drc_pmem_unbind() in case the initial bind of scm memory fails
with EBUSY error. In case scm-bind operation again fails after the
forced scm-unbind then we follow the existing error path. We also
update drc_pmem_bind() to handle the H_OVERLAP error returned by phyp
and indicate it as a EBUSY error back to the caller.

Suggested-by: "Oliver O'Halloran" 
Signed-off-by: Vaibhav Jain 
Reviewed-by: Oliver O'Halloran 
---
Change-log:

v5:
* None. Re-spinning the patchset.

v4:
* None. Re-spinning the patchset.

v3:
* Minor update to a code comment. [Oliver]

v2:
* Moved the retry code from drc_pmem_bind() to papr_scm_probe()
   [Oliver]
* Changed the type of variable 'rc' in drc_pmem_bind() to
   int64_t. [Oliver]
---
  arch/powerpc/platforms/pseries/papr_scm.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
b/arch/powerpc/platforms/pseries/papr_scm.c
index 82568a7e0a7c..2c07908359b2 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -44,8 +44,9 @@ struct papr_scm_priv {
  static int drc_pmem_bind(struct papr_scm_priv *p)
  {
unsigned long ret[PLPAR_HCALL_BUFSIZE];
-   uint64_t rc, token;
uint64_t saved = 0;
+   uint64_t token;
+   int64_t rc;

/*
 * When the hypervisor cannot map all the requested memory in a single
@@ -65,6 +66,10 @@ static int drc_pmem_bind(struct papr_scm_priv *p)
} while (rc == H_BUSY);

if (rc) {
+   /* H_OVERLAP needs a separate error path */
+   if (rc == H_OVERLAP)
+   return -EBUSY;
+
dev_err(&p->pdev->dev, "bind err: %lld\n", rc);
return -ENXIO;
}
@@ -404,6 +409,14 @@ static int papr_scm_probe(struct platform_device *pdev)

/* request the hypervisor to bind this region to somewhere in memory */
rc = drc_pmem_bind(p);
+
+   /* If phyp says drc memory still bound then force unbound and retry */
+   if (rc == -EBUSY) {
+   dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
+   drc_pmem_unbind(p);
+   rc = drc_pmem_bind(p);


In the unlikely case where H_SCM_BIND_MEM is returning H_OVERLAP once the 
unbinding has been done, the error would be silently processed. That sounds 
really unlikely, but should an error message be displayed in this 
particular case ?



+   }
+
if (rc)
goto err;





Re: [PATCH v5 4/4] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails

2019-07-24 Thread Oliver O'Halloran
On Wed, Jul 24, 2019 at 7:17 PM Laurent Dufour
 wrote:
>
> Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :
> > *snip*
> > @@ -404,6 +409,14 @@ static int papr_scm_probe(struct platform_device *pdev)
> >
> >   /* request the hypervisor to bind this region to somewhere in memory 
> > */
> >   rc = drc_pmem_bind(p);
> > +
> > + /* If phyp says drc memory still bound then force unbound and retry */
> > + if (rc == -EBUSY) {
> > + dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
> > + drc_pmem_unbind(p);
> > + rc = drc_pmem_bind(p);
>
> In the unlikely case where H_SCM_BIND_MEM is returning H_OVERLAP once the
> unbinding has been done, the error would be silently processed. That sounds
> really unlikely, but should an error message be displayed in this
> particular case ?

drc_pmem_bind() prints the h-call error code if we get one, so it's not silent


Re: [PATCH v3 9/9] powerpc/eeh: Convert log messages to eeh_edev_* macros

2019-07-24 Thread kbuild test robot
Hi Sam,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.3-rc1 next-20190724]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sam-Bobroff/powerpc-64-Adjust-order-in-pcibios_init/20190724-134001
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   arch/powerpc/kernel/eeh_driver.c: In function 'eeh_add_virt_device':
>> arch/powerpc/kernel/eeh_driver.c:459:17: error: unused variable 'pdn' 
>> [-Werror=unused-variable]
 struct pci_dn *pdn = eeh_dev_to_pdn(edev);
^~~
   cc1: all warnings being treated as errors

vim +/pdn +459 arch/powerpc/kernel/eeh_driver.c

77bd7415 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03  
454  
bf773df9 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-09-12  
455  static void *eeh_add_virt_device(struct eeh_dev *edev)
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
456  {
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
457  struct pci_driver *driver;
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
458  struct pci_dev *dev = eeh_dev_to_pci_dev(edev);
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
@459  struct pci_dn *pdn = eeh_dev_to_pdn(edev);
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
460  
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
461  if (!(edev->physfn)) {
6dad7bbd arch/powerpc/kernel/eeh_driver.cSam Bobroff   2019-07-23  
462  eeh_edev_warn(edev, "Not for VF\n");
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
463  return NULL;
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
464  }
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
465  
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
466  driver = eeh_pcid_get(dev);
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
467  if (driver) {
46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-05-25  
468  if (driver->err_handler) {
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
469  eeh_pcid_put(dev);
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
470  return NULL;
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
471  }
46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-05-25  
472  eeh_pcid_put(dev);
46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-05-25  
473  }
67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04  
474  

:: The code at line 459 was first introduced by commit
:: 67086e32b56481531ab1292b284e074b1a8d764c powerpc/eeh: powerpc/eeh: 
Support error recovery for VF PE

:: TO: Wei Yang 
:: CC: Michael Ellerman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH v5 4/4] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails

2019-07-24 Thread Laurent Dufour

Le 24/07/2019 à 11:24, Oliver O'Halloran a écrit :

On Wed, Jul 24, 2019 at 7:17 PM Laurent Dufour
 wrote:


Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :

*snip*
@@ -404,6 +409,14 @@ static int papr_scm_probe(struct platform_device *pdev)

   /* request the hypervisor to bind this region to somewhere in memory */
   rc = drc_pmem_bind(p);
+
+ /* If phyp says drc memory still bound then force unbound and retry */
+ if (rc == -EBUSY) {
+ dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
+ drc_pmem_unbind(p);
+ rc = drc_pmem_bind(p);


In the unlikely case where H_SCM_BIND_MEM is returning H_OVERLAP once the
unbinding has been done, the error would be silently processed. That sounds
really unlikely, but should an error message be displayed in this
particular case ?


drc_pmem_bind() prints the h-call error code if we get one, so it's not silent


That's no more the case whith this patch, H_OVERLAP is handled before 
writing the error message, which would make sense for the first try.


For the record, the patch introduces:

@@ -65,6 +66,10 @@ static int drc_pmem_bind(struct papr_scm_priv *p)
} while (rc == H_BUSY);

if (rc) {
+   /* H_OVERLAP needs a separate error path */
+   if (rc == H_OVERLAP)
+   return -EBUSY;
+
dev_err(&p->pdev->dev, "bind err: %lld\n", rc);
return -ENXIO;
}



Re: [PATCH] powerpc: Wire up clone3 syscall

2019-07-24 Thread Christian Brauner
On Wed, Jul 24, 2019 at 12:25:14PM +0700, Arseny Solokha wrote:
> Hi,
> 
> may I also ask to provide ppc_clone3 symbol also for 32-bit powerpc? Otherwise
> Michael's patch breaks build for me:

Makes sense. Michael, are you planning on picking this up? :)

Christian

> 
>   powerpc-e500v2-linux-gnuspe-ld: arch/powerpc/kernel/systbl.o: in function 
> `sys_call_table':
>   (.rodata+0x6cc): undefined reference to `ppc_clone3'
>   make: *** [Makefile:1060: vmlinux] Error 1
> 
> The patch was tested using Christian's program on a real e500 machine.
> 
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -597,6 +597,14 @@ ppc_clone:
>   stw r0,_TRAP(r1)/* register set saved */
>   b   sys_clone
> 
> + .globl  ppc_clone3
> +ppc_clone3:
> + SAVE_NVGPRS(r1)
> + lwz r0,_TRAP(r1)
> + rlwinm  r0,r0,0,0,30/* clear LSB to indicate full */
> + stw r0,_TRAP(r1)/* register set saved */
> + b   sys_clone3
> +
>   .globl  ppc_swapcontext
>  ppc_swapcontext:
>   SAVE_NVGPRS(r1)
> 
> I don't think this trivial hunk deserves a separate patch submission.
> 
> Thanks,
> Arseny


Re: [PATCH v5 4/4] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails

2019-07-24 Thread Oliver O'Halloran
On Wed, Jul 24, 2019 at 7:27 PM Laurent Dufour
 wrote:
>
> Le 24/07/2019 à 11:24, Oliver O'Halloran a écrit :
> > On Wed, Jul 24, 2019 at 7:17 PM Laurent Dufour
> >  wrote:
> >>
> >> Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :
> >>> *snip*
> >>> @@ -404,6 +409,14 @@ static int papr_scm_probe(struct platform_device 
> >>> *pdev)
> >>>
> >>>/* request the hypervisor to bind this region to somewhere in 
> >>> memory */
> >>>rc = drc_pmem_bind(p);
> >>> +
> >>> + /* If phyp says drc memory still bound then force unbound and retry 
> >>> */
> >>> + if (rc == -EBUSY) {
> >>> + dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
> >>> + drc_pmem_unbind(p);
> >>> + rc = drc_pmem_bind(p);
> >>
> >> In the unlikely case where H_SCM_BIND_MEM is returning H_OVERLAP once the
> >> unbinding has been done, the error would be silently processed. That sounds
> >> really unlikely, but should an error message be displayed in this
> >> particular case ?
> >
> > drc_pmem_bind() prints the h-call error code if we get one, so it's not 
> > silent
>
> That's no more the case whith this patch, H_OVERLAP is handled before
> writing the error message, which would make sense for the first try.
>
> For the record, the patch introduces:
>
> @@ -65,6 +66,10 @@ static int drc_pmem_bind(struct papr_scm_priv *p)
> } while (rc == H_BUSY);
>
> if (rc) {
> +   /* H_OVERLAP needs a separate error path */
> +   if (rc == H_OVERLAP)
> +   return -EBUSY;
> +
> dev_err(&p->pdev->dev, "bind err: %lld\n", rc);
> return -ENXIO;
> }

Ah, good point. Getting H_OVERLAP is still an error case so I think
it's reasonable to still print the message in that case.


Re: [PATCH v3 9/9] powerpc/eeh: Convert log messages to eeh_edev_* macros

2019-07-24 Thread Oliver O'Halloran
On Wed, Jul 24, 2019 at 7:24 PM kbuild test robot  wrote:
>
> Hi Sam,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.3-rc1 next-20190724]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Sam-Bobroff/powerpc-64-Adjust-order-in-pcibios_init/20190724-134001
> config: powerpc-defconfig (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
>
> All errors (new ones prefixed by >>):
>
>arch/powerpc/kernel/eeh_driver.c: In function 'eeh_add_virt_device':
> >> arch/powerpc/kernel/eeh_driver.c:459:17: error: unused variable 'pdn' 
> >> [-Werror=unused-variable]
>  struct pci_dn *pdn = eeh_dev_to_pdn(edev);

FYI this happens when CONFIG_IOV isn't set. Adding a __maybe_unused
annotation fixes it.

> ^~~
>cc1: all warnings being treated as errors
>
> vim +/pdn +459 arch/powerpc/kernel/eeh_driver.c
>
> 77bd7415 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 2005-11-03 
>  454
> bf773df9 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-09-12 
>  455  static void *eeh_add_virt_device(struct eeh_dev *edev)
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  456  {
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  457  struct pci_driver *driver;
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  458  struct pci_dev *dev = eeh_dev_to_pci_dev(edev);
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
> @459  struct pci_dn *pdn = eeh_dev_to_pdn(edev);
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  460
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  461  if (!(edev->physfn)) {
> 6dad7bbd arch/powerpc/kernel/eeh_driver.cSam Bobroff   2019-07-23 
>  462  eeh_edev_warn(edev, "Not for VF\n");
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  463  return NULL;
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  464  }
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  465
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  466  driver = eeh_pcid_get(dev);
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  467  if (driver) {
> 46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-05-25 
>  468  if (driver->err_handler) {
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  469  eeh_pcid_put(dev);
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  470  return NULL;
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  471  }
> 46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-05-25 
>  472  eeh_pcid_put(dev);
> 46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   2018-05-25 
>  473  }
> 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  2016-03-04 
>  474
>
> :: The code at line 459 was first introduced by commit
> :: 67086e32b56481531ab1292b284e074b1a8d764c powerpc/eeh: powerpc/eeh: 
> Support error recovery for VF PE
>
> :: TO: Wei Yang 
> :: CC: Michael Ellerman 
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Re: [PATCH 2/2] powerpc: expose secure variables via sysfs

2019-07-24 Thread Oliver O'Halloran
On Wed, Jul 24, 2019 at 12:35 AM Nayna  wrote:
>
> On 07/05/2019 02:05 AM, Michael Ellerman wrote:
> > Hi Nayna,
>
> Hi Michael, Oliver,
>
> > Nayna Jain  writes:
> >> As part of PowerNV secure boot support, OS verification keys are stored
> >> and controlled by OPAL as secure variables. These need to be exposed to
> >> the userspace so that sysadmins can perform key management tasks.
> >>
> >> This patch adds the support to expose secure variables via a sysfs
> >> interface It reuses the the existing efi defined hooks and backend in
> >> order to maintain the compatibility with the userspace tools.
> > Which tools? Can you include a log demonstrating how they're used, ie.
> > so that I can test the sequence of commands.
> >
> >> Though it reuses a great deal of efi, POWER platforms do not use EFI.
> >> A new config, POWER_SECVAR_SYSFS, is defined to enable this new sysfs
> >> interface.
> > Sorry I haven't been able to keep up with all the discussions, but I
> > thought the consensus was that pretending to be EFI-like was a bad idea,
> > because we don't have actual EFI and we're not implementing an entirely
> > compatible scheme to EFI anyway.

My read is the consensus was that pretending to be EFI is a bad idea
unless we're going to behave like EFI.

> > Greg suggested just putting the variables in sysfs, why does that not
> > work? Matthew mentioned "complex semantics around variable deletion and
> > immutability" but do we have to emulate those semantics on powerpc?
>
> Sorry for the delay in the response.
>
> Yes, I agree. The purpose of the v2 version of the patchset was to try
> and quickly address Matthew's concerns. This version of the patchset:

> * is based on Greg's suggestion to use sysfs

As far as I can tell Greg made that suggestion here:

https://lwn.net/ml/linux-fsdevel/20190603072916.ga7...@kroah.com/

Then walked back on that suggestion after Matthew pointed out that
efivars is separate because of the immutability requirement and the
odd update semantics:

https://lwn.net/ml/linux-fsdevel/20190605081301.ga23...@kroah.com/

Considering the whole point of this is to present the same user-facing
interface so shouldn't you be dealing with all the problems that
interface creates?

> * is not using any EFI configs
That's true, but...

> * is not exposing secure variables via efivarfs
> * is STILL using some of the existing EFI code, that is used by EFI to
> expose its variables via sysfs, to avoid code duplication.

We avoid some of the potential problems of selecting CONFIG_EFI and we
gain a bunch of other potential problems since you've hacked the
makefiles to build code that's normally CONFIG_EFI only.

> * is using efivar hooks to expose secure variables for tool compatibility

Here's the real problem. For compatibility with the existing userspace
tooling, which expects UEFI,  you need to present the same interface
with the same semantics. Trying to not use efivarfs means you've
already lost since you no longer have the same interface. So how is
this an improvement? I think the options here are to either:

1) Come up with a new interface, implement it, and adapt the user
tooling to deal with the new API.

*or*

2) Use efivarsfs and fix the based i-cant-believe-its-not-efi variable
backend so it behaves *exactly* like the UEFI get/setVariable APIs.
This means that you need to validate the update certificates at
runtime. I don't think this is a huge strech since you're already
implementing the validator.

1) gives you the flexibility to change the key hierarchy and whatnot,
while 2) means we've got less weird powerpc crap for users to deal
with. I have no strong opinions about which you choose to do, but
don't do this.

Oliver


Re: [PATCH 1/5] powerpc/64s/radix: Fix memory hotplug section page table creation

2019-07-24 Thread Aneesh Kumar K.V
Nicholas Piggin  writes:

> create_physical_mapping expects physical addresses, but creating and
> splitting these mappings after boot is supplying virtual (effective)
> addresses. This can be irritated by booting with mem= to limit memory
> then probing an unused physical memory range:
>
>   echo  > /sys/devices/system/memory/probe
>
> This mostly works by accident, firstly because __va(__va(x)) == __va(x)
> so the virtual address does not get corrupted. Secondly because pfn_pte
> masks out the upper bits of the pfn beyond the physical address limit,
> so a pfn constructed with a 0xc000 virtual linear address
> will be masked back to the correct physical address in the pte.
>

Good catch. Did this result in any error?

Reviewed-by: Aneesh Kumar K.V 

> Cc: Reza Arbab 
> Fixes: 6cc27341b21a8 ("powerpc/mm: add radix__create_section_mapping()")
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c 
> b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index b4ca9e95e678..c5cc16ab1954 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -902,7 +902,7 @@ int __meminit radix__create_section_mapping(unsigned long 
> start, unsigned long e
>   return -1;
>   }
>  
> - return create_physical_mapping(start, end, nid);
> + return create_physical_mapping(__pa(start), __pa(end), nid);


While we are here, should we change the prototype to take phys_addr_t ?

>  }
>  
>  int __meminit radix__remove_section_mapping(unsigned long start, unsigned 
> long end)
> -- 
> 2.22.0



Re: [PATCH 2/5] powerpc/64s/radix: Fix memory hot-unplug page table split

2019-07-24 Thread Aneesh Kumar K.V
Nicholas Piggin  writes:

> create_physical_mapping expects physical addresses, but splitting
> these mapping on hot unplug is supplying virtual (effective)
> addresses.
>
> [I'm not sure how to test this one]
>

Memory hot unplug with kvm?


Reviewed-by: Aneesh Kumar K.V 

> Cc: Balbir Singh 
> Fixes: 4dd5f8a99e791 ("powerpc/mm/radix: Split linear mapping on hot-unplug")
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c 
> b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index c5cc16ab1954..2204d8eeb784 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -737,8 +737,8 @@ static int __meminit stop_machine_change_mapping(void 
> *data)
>  
>   spin_unlock(&init_mm.page_table_lock);
>   pte_clear(&init_mm, params->aligned_start, params->pte);
> - create_physical_mapping(params->aligned_start, params->start, -1);
> - create_physical_mapping(params->end, params->aligned_end, -1);
> + create_physical_mapping(__pa(params->aligned_start), 
> __pa(params->start), -1);
> + create_physical_mapping(__pa(params->end), __pa(params->aligned_end), 
> -1);
>   spin_lock(&init_mm.page_table_lock);
>   return 0;
>  }
> -- 
> 2.22.0



Re: [PATCH 3/5] powerpc/perf: fix imc allocation failure handling

2019-07-24 Thread Aneesh Kumar K.V
Nicholas Piggin  writes:

> The alloc_pages_node return value should be tested for failure
> before being passed to page_address.
>


Reviewed-by: Aneesh Kumar K.V 

This need Fixes: tag? It fix a real crash unlike the other patch in this
series? 

> Cc: Madhavan Srinivasan 
> Tested-by: Anju T Sudhakar 
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/perf/imc-pmu.c | 29 ++---
>  1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index dea243185ea4..cb50a9e1fd2d 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -577,6 +577,7 @@ static int core_imc_mem_init(int cpu, int size)
>  {
>   int nid, rc = 0, core_id = (cpu / threads_per_core);
>   struct imc_mem_info *mem_info;
> + struct page *page;
>  
>   /*
>* alloc_pages_node() will allocate memory for core in the
> @@ -587,11 +588,12 @@ static int core_imc_mem_init(int cpu, int size)
>   mem_info->id = core_id;
>  
>   /* We need only vbase for core counters */
> - mem_info->vbase = page_address(alloc_pages_node(nid,
> -   GFP_KERNEL | __GFP_ZERO | 
> __GFP_THISNODE |
> -   __GFP_NOWARN, get_order(size)));
> - if (!mem_info->vbase)
> + page = alloc_pages_node(nid,
> + GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE |
> + __GFP_NOWARN, get_order(size));
> + if (!page)
>   return -ENOMEM;
> + mem_info->vbase = page_address(page);
>  
>   /* Init the mutex */
>   core_imc_refc[core_id].id = core_id;
> @@ -849,15 +851,17 @@ static int thread_imc_mem_alloc(int cpu_id, int size)
>   int nid = cpu_to_node(cpu_id);
>  
>   if (!local_mem) {
> + struct page *page;
>   /*
>* This case could happen only once at start, since we dont
>* free the memory in cpu offline path.
>*/
> - local_mem = page_address(alloc_pages_node(nid,
> + page = alloc_pages_node(nid,
> GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE |
> -   __GFP_NOWARN, get_order(size)));
> - if (!local_mem)
> +   __GFP_NOWARN, get_order(size));
> + if (!page)
>   return -ENOMEM;
> + local_mem = page_address(page);
>  
>   per_cpu(thread_imc_mem, cpu_id) = local_mem;
>   }
> @@ -1095,11 +1099,14 @@ static int trace_imc_mem_alloc(int cpu_id, int size)
>   int core_id = (cpu_id / threads_per_core);
>  
>   if (!local_mem) {
> - local_mem = page_address(alloc_pages_node(phys_id,
> - GFP_KERNEL | __GFP_ZERO | 
> __GFP_THISNODE |
> - __GFP_NOWARN, get_order(size)));
> - if (!local_mem)
> + struct page *page;
> +
> + page = alloc_pages_node(phys_id,
> + GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE |
> + __GFP_NOWARN, get_order(size));
> + if (!page)
>   return -ENOMEM;
> + local_mem = page_address(page);
>   per_cpu(trace_imc_mem, cpu_id) = local_mem;
>  
>   /* Initialise the counters for trace mode */
> -- 
> 2.22.0



Re: [PATCH 4/5] powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses

2019-07-24 Thread Aneesh Kumar K.V
Nicholas Piggin  writes:

> Ensure __va is given a physical address below PAGE_OFFSET, and __pa is
> given a virtual address above PAGE_OFFSET.
>

Reviewed-by: Aneesh Kumar K.V 

> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/include/asm/page.h | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 0d52f57fca04..c8bb14ff4713 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -215,9 +215,19 @@ static inline bool pfn_valid(unsigned long pfn)
>  /*
>   * gcc miscompiles (unsigned long)(&static_var) - PAGE_OFFSET
>   * with -mcmodel=medium, so we use & and | instead of - and + on 64-bit.
> + * This also results in better code generation.
>   */
> -#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET))
> -#define __pa(x) ((unsigned long)(x) & 0x0fffUL)
> +#define __va(x)  
> \
> +({   \
> + VIRTUAL_BUG_ON((unsigned long)(x) >= PAGE_OFFSET);  \
> + (void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET);\
> +})

Can we make that static inline? Is there a need for __pa and __va to be
#define like we do #ifndef anywhere?

> +
> +#define __pa(x)  
> \
> +({   \
> + VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);   \
> + (unsigned long)(x) & 0x0fffUL;  \
> +})
>  
>  #else /* 32-bit, non book E */
>  #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + PAGE_OFFSET - 
> MEMORY_START))
> -- 
> 2.22.0



Re: [PATCH 5/5] powerpc/64s/radix: Remove redundant pfn_pte bitop, add VM_BUG_ON

2019-07-24 Thread Aneesh Kumar K.V
Nicholas Piggin  writes:

> pfn_pte is never given a pte above the addressable physical memory
> limit, so the masking is redundant. In case of a software bug, it
> is not obviously better to silently truncate the pfn than to corrupt
> the pte (either one will result in memory corruption or crashes),
> so there is no reason to add this to the fast path.
>
> Add VM_BUG_ON to catch cases where the pfn is invalid. These would
> catch the create_section_mapping bug fixed by a previous commit.
>
>   [16885.256466] [ cut here ]
>   [16885.256492] kernel BUG at 
> arch/powerpc/include/asm/book3s/64/pgtable.h:612!
>   cpu 0x0: Vector: 700 (Program Check) at [c000ee0a36d0]
>   pc: c0080738: __map_kernel_page+0x248/0x6f0
>   lr: c0080ac0: __map_kernel_page+0x5d0/0x6f0
>   sp: c000ee0a3960
>  msr: 90029033
> current = 0xc000ec63b400
> paca= 0xc17f   irqmask: 0x03   irq_happened: 0x01
>   pid   = 85, comm = sh
>   kernel BUG at arch/powerpc/include/asm/book3s/64/pgtable.h:612!
>   Linux version 5.3.0-rc1-1-g0fe93e5f3394
>   enter ? for help
>   [c000ee0a3a00] c0d37378 create_physical_mapping+0x260/0x360
>   [c000ee0a3b10] c0d370bc create_section_mapping+0x1c/0x3c
>   [c000ee0a3b30] c0071f54 arch_add_memory+0x74/0x130
>

Reviewed-by: Aneesh Kumar K.V 

> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 8308f32e9782..8e47fb85dfa6 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -608,8 +608,10 @@ static inline bool pte_access_permitted(pte_t pte, bool 
> write)
>   */
>  static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot)
>  {
> - return __ptepte_basic_t)(pfn) << PAGE_SHIFT) & PTE_RPN_MASK) |
> -  pgprot_val(pgprot));
> + VM_BUG_ON(pfn >> (64 - PAGE_SHIFT));
> + VM_BUG_ON((pfn << PAGE_SHIFT) & ~PTE_RPN_MASK);
> +
> + return __pte(((pte_basic_t)pfn << PAGE_SHIFT) | pgprot_val(pgprot));
>  }
>  
>  static inline unsigned long pte_pfn(pte_t pte)
> -- 
> 2.22.0



Re: [PATCH v5 0/4] powerpc/papr_scm: Workaround for failure of drc bind after kexec

2019-07-24 Thread Aneesh Kumar K.V
Vaibhav Jain  writes:

> Presently an error is returned in response to hcall H_SCM_BIND_MEM when a
> new kernel boots on lpar via kexec. This prevents papr_scm from registering
> drc memory regions with nvdimm. The error reported is of the form below:
>
> "papr_scm ibm,persistent-memory:ibm,pmemory@4412: bind err: -68"
>
> On investigation it was revealed that phyp returns this error as previous
> kernel did not completely release bindings for drc scm-memory blocks and
> hence phyp rejected request for re-binding these block to lpar with error
> H_OVERLAP. Also support for a new H_SCM_UNBIND_ALL is recently added which
> is better suited for releasing all the bound scm-memory block from an lpar.
>
> So leveraging new hcall H_SCM_UNBIND_ALL, we can workaround H_OVERLAP issue
> during kexec by forcing an unbind of all drm scm-memory blocks and issuing
> H_SCM_BIND_MEM to re-bind the drc scm-memory blocks to lpar. This sequence
> will also be needed when a new kernel boot on lpar after previous kernel
> panicked and it never got an opportunity to call H_SCM_UNBIND_MEM/ALL.
>
> Hence this patch-set implements following changes to papr_scm module:
>
> * Update hvcall.h to include opcodes for new hcall H_SCM_UNBIND_ALL.
>
> * Update it to use H_SCM_UNBIND_ALL instead of H_SCM_UNBIND_MEM
>
> * In case hcall H_SCM_BIND_MEM fails with error H_OVERLAP, force
>   H_SCM_UNBIND_ALL and retry the bind operation again.
>

You can add for the series.

Reviewed-by: Aneesh Kumar K.V 



Re: [DOC][PATCH v5 1/4] powerpc: Document some HCalls for Storage Class Memory

2019-07-24 Thread Michal Suchánek
On Wed, 24 Jul 2019 11:08:58 +0200
Laurent Dufour  wrote:

> Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :
> > This doc patch provides an initial description of the HCall op-codes
> > that are used by Linux kernel running as a guest operating
> > system (LPAR) on top of PowerVM or any other sPAPR compliant
> > hyper-visor (e.g qemu).
> > 
> > Apart from documenting the HCalls the doc-patch also provides a
> > rudimentary overview of how Hcalls are implemented inside the Linux
> > kernel and how information flows between kernel and PowerVM/KVM.  
> 
> Hi Vaibhav,
> 
> That's a good idea to introduce such a documentation.
> 
> > Signed-off-by: Vaibhav Jain 
> > ---
> > Change-log:
> > 
> > v5
> > * First patch in this patchset.
> > ---
> >   Documentation/powerpc/hcalls.txt | 140 +++
> >   1 file changed, 140 insertions(+)
> >   create mode 100644 Documentation/powerpc/hcalls.txt
> > 
> > diff --git a/Documentation/powerpc/hcalls.txt 
> > b/Documentation/powerpc/hcalls.txt
> > new file mode 100644
> > index ..cc9dd872cecd
> > --- /dev/null
> > +++ b/Documentation/powerpc/hcalls.txt
> > @@ -0,0 +1,140 @@
> > +Hyper-visor Call Op-codes (HCALLS)
> > +
> > +
> > +Overview
> > +=
> > +
> > +Virtualization on PPC64 arch is based on the PAPR specification[1] which
> > +describes run-time environment for a guest operating system and how it 
> > should
> > +interact with the hyper-visor for privileged operations. Currently there 
> > are two
> > +PAPR compliant hypervisors (PHYP):
> > +
> > +IBM PowerVM: IBM's proprietary hyper-visor that supports AIX, IBM-i and 
> > Linux as
> > +supported guests (termed as Logical Partitions or LPARS).
> > +
> > +Qemu/KVM:Supports PPC64 linux guests running on a PPC64 linux host.
> > +
> > +On PPC64 arch a virtualized guest kernel runs in a non-privileged mode 
> > (HV=0).
> > +Hence to perform a privileged operations the guest issues a Hyper-visor
> > +Call (HCALL) with necessary input operands. PHYP after performing the 
> > privilege
> > +operation returns a status code and output operands back to the guest.
> > +
> > +HCALL ABI
> > +=
> > +The ABI specification for a HCall between guest os kernel and PHYP is
> > +described in [1]. The Opcode for Hcall is set in R3 and subsequent 
> > in-arguments
> > +for the Hcall are provided in registers R4-R12. On return from 'HVCS'
> > +instruction the status code of HCall is available in R3 an the output 
> > parameters
> > +are returned in registers R4-R12.  
> 
> Would it be good to mention that values passed through the memory must be 
> stored in Big Endian format ?
> 
> > +Powerpc arch code provides convenient wrappers named plpar_hcall_xxx 
> > defined in
> > +header 'hvcall.h' to issue HCalls from the linux kernel running as guest.
> > +
> > +
> > +DRC & DRC Indexes
> > +=
> > +
> > +PAPRGuest
> > +  DR1  Hypervisor OS
> > +  +--++--+ +-+
> > +  |  |<-->|  | |  User   |
> > +  +--+  DRC1  |  |   DRC   |  Space  |
> > + |  |  Index  +-+
> > +  DR2 |  | | |
> > +  +--+|  |<--->|  Kernel |
> > +  |  |<- >|  |  HCall  | |
> > +  +--+  DRC2  +--+ +-+
> > +
> > +PHYP terms shared hardware resources like PCI devices, NVDimms etc 
> > available for
> > +use by LPARs as Dynamic Resource (DR). When a DR is allocated to an LPAR, 
> > PHYP
> > +creates a data-structure called Dynamic Resource Connector (DRC) to manage 
> > LPAR
> > +access. An LPAR refers to a DRC via an opaque 32-bit number called 
> > DRC-Index.
> > +The DRC-index value is provided to the LPAR via device-tree where its 
> > present
> > +as an attribute in the device tree node associated with the DR.  
> 
> Should you use the term 'Hypervisor' instead of 'PHYP' which is not usually 
> designing only the proprietary one ?
> 
> Thanks,
> Laurent.
> 
> > +
> > +HCALL Op-codes
> > +==
> > +
> > +Below is a partial of of HCALLs that are supported by PHYP. For the
^^ list?

Thanks

Michal
> > +corresponding opcode values please look into the header
> > +'arch/powerpc/include/asm/hvcall.h' :
> > +
> > +* H_SCM_READ_METADATA:
> > +  Input: drcIndex, offset, buffer-address, numBytesToRead
> > +  Out: None
> > +  Description:
> > +  Given a DRC Index of an NVDimm, read N-bytes from the the meta data area
> > +  associated with it, at a specified offset and copy it to provided buffer.
> > +  The metadata area stores configuration information such as label 
> > information,
> > +  bad-blocks etc. The metadata area is located out-of-band of NVDimm 
> > storage
> > +  area hence a separate access semantics is provided.
> > +
> > +* H_SCM_WRITE_METADATA:
> > +  Input: drcIndex, offset, data, numBytesToWrite
> > + 

Re: [PATCH v4 1/3] powerpc/pseries: Update SCM hcall op-codes in hvcall.h

2019-07-24 Thread Michael Ellerman
On Sat, 2019-06-29 at 16:06:08 UTC, Vaibhav Jain wrote:
> Update the hvcalls.h to include op-codes for new hcalls introduce to
> manage SCM memory. Also update existing hcall definitions to reflect
> current papr specification for SCM.
> 
> The removed hcall op-codes H_SCM_MEM_QUERY, H_SCM_BLOCK_CLEAR were
> transient proposals and there support was never implemented by
> Power-VM nor they were used anywhere in Linux kernel. Hence we don't
> expect anyone to be impacted by this change.
> 
> Signed-off-by: Vaibhav Jain 

Series applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/6d140e7569db89a1b596c1c2d1c2293d5c594432

cheers


[GIT PULL] Please pull powerpc/linux.git powerpc-5.3-2 tag

2019-07-24 Thread Michael Ellerman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Linus,

Please pull some powerpc fixes for 5.3:

The following changes since commit 192f0f8e9db7efe4ac98d47f5fa4334e43c1204d:

  Merge tag 'powerpc-5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2019-07-13 
16:08:36 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.3-2

for you to fetch changes up to 3a855b7ac7d5021674aa3e1cc9d3bfd6b604e9c0:

  powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails (2019-07-22 
23:31:00 +1000)

- --
powerpc fixes for 5.3 #2

An assortment of non-regression fixes that have accumulated since the start of
the merge window.

A fix for a user triggerable oops on machines where transactional memory is
disabled, eg. Power9 bare metal, Power8 with TM disabled on the command line, or
all Power7 or earlier machines.

Three fixes for handling of PMU and power saving registers when running nested
KVM on Power9.

Two fixes for bugs found while stress testing the XIVE interrupt controller
code, also on Power9.

A fix to allow guests to boot under Qemu/KVM on Power9 using the the Hash MMU
with >= 1TB of memory.

Two fixes for bugs in the recent DMA cleanup, one of which could lead to
checkstops.

And finally three fixes for the PAPR SCM nvdimm driver.

Thanks to:
  Alexey Kardashevskiy, Andrea Arcangeli, Cédric Le Goater, Christoph Hellwig,
  David Gibson, Gautham R. Shenoy, Michael Neuling, Oliver O'Halloran,, Satheesh
  Rajendran, Shawn Anastasio, Suraj Jitindar Singh, Vaibhav Jain.

- --
Andrea Arcangeli (1):
  powerpc: fix off by one in max_zone_pfn initialization for ZONE_DMA

Cédric Le Goater (1):
  KVM: PPC: Book3S HV: XIVE: fix rollback when kvmppc_xive_create fails

Gautham R. Shenoy (1):
  powerpc/xive: Fix loop exit-condition in xive_find_target_in_mask()

Michael Neuling (1):
  powerpc/tm: Fix oops on sigreturn on systems without TM

Shawn Anastasio (1):
  powerpc/dma: Fix invalid DMA mmap behavior

Suraj Jitindar Singh (4):
  powerpc/mm: Limit rma_size to 1TB when running without HV mode
  KVM: PPC: Book3S HV: Always save guest pmu for guest capable of nesting
  powerpc/pmu: Set pmcregs_in_use in paca when running as LPAR
  KVM: PPC: Book3S HV: Save and restore guest visible PSSCR bits on pseries

Vaibhav Jain (3):
  powerpc/pseries: Update SCM hcall op-codes in hvcall.h
  powerpc/papr_scm: Update drc_pmem_unbind() to use H_SCM_UNBIND_ALL
  powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails


 arch/powerpc/Kconfig  |  1 +
 arch/powerpc/include/asm/hvcall.h | 11 +---
 arch/powerpc/include/asm/pmc.h|  5 ++--
 arch/powerpc/kernel/Makefile  |  3 ++-
 arch/powerpc/kernel/dma-common.c  | 17 
 arch/powerpc/kernel/signal_32.c   |  3 +++
 arch/powerpc/kernel/signal_64.c   |  5 
 arch/powerpc/kvm/book3s_hv.c  | 13 +
 arch/powerpc/kvm/book3s_xive.c|  4 +--
 arch/powerpc/kvm/book3s_xive_native.c |  4 +--
 arch/powerpc/mm/book3s64/hash_utils.c |  9 +++
 arch/powerpc/mm/mem.c |  2 +-
 arch/powerpc/platforms/pseries/papr_scm.c | 44 +--
 arch/powerpc/sysdev/xive/common.c |  7 +++--
 14 files changed, 103 insertions(+), 25 deletions(-)
 create mode 100644 arch/powerpc/kernel/dma-common.c
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJdOF+PAAoJEFHr6jzI4aWAEQ4P/iw1q7wyO11sSAc+oNsdCFDh
tT7fPzQruFlulyDr67BqXrUPJ5OoDN7k2eiwa5/Gbte9YgyYQkgw8UspoRTPUNTt
1tjoeEC7KtdWByYdZ9yrhqhzN0OVhc8FSwFvqdprzdfsCyWx0Fuh9uhXShteqpiV
nU8qG7WmS4KmY/+FWuOzH3s75w80UscezZ5WU3SGNoTrZYItlmNrtwFcyU3k5KcE
XWwktFBQP1dQQ81gZTX6L6E2rKHPQ0jphbmLrNhk2qTwv7Z7uq7BDT6b83nS7/sK
DtUTNVD7Cp1HUtRUlla3GhFIW3WP4t8OtZaDLMYL2v1a/B04kSb0iMYQIeLv6Ti0
UvACpGss2s6JLMyGrJrxnzjQcHIk4jYeM/sa+viJ+XYu3rC8Li533MOkNzpyaZ4d
ueAiORVlH02yz6fezhJhXCCN2L7cS7ifufpPpnBWX+hkp7zthxG+1wVhuHnZ53MD
Muz8avaNBF0K3/1/dGDeX3WBKpQoEQP96yyfP+MtmRJsEfIEr/cJdOixetBhwZkU
9DvBGFibUFF4l2aAbv1fGkKak54iOrXzJiBbjvOXmErwYaHnBIKARLHvlgOlykrg
789enXFL3wH2wRtrLwQGC8jh6RyQio6vzbOxlJ011SmtueD/lbnMD67C+TdoYjGc
08eecoUyDMeoW62I9yhH
=tkyv
-END PGP SIGNATURE-


Re: [PATCH] powerpc: Wire up clone3 syscall

2019-07-24 Thread Michael Ellerman
Christian Brauner  writes:
> On Wed, Jul 24, 2019 at 12:25:14PM +0700, Arseny Solokha wrote:
>> Hi,
>> 
>> may I also ask to provide ppc_clone3 symbol also for 32-bit powerpc? 
>> Otherwise
>> Michael's patch breaks build for me:
>
> Makes sense. Michael, are you planning on picking this up? :)

Yes I obviously (I hope) am not going to merge a patch that breaks the
32-bit build :)

I'll send a v2.

cheers


[PATCH v2] powerpc: Wire up clone3 syscall

2019-07-24 Thread Michael Ellerman
Wire up the new clone3 syscall added in commit 7f192e3cd316 ("fork:
add clone3").

This requires a ppc_clone3 wrapper, in order to save the non-volatile
GPRs before calling into the generic syscall code. Otherwise we hit
the BUG_ON in CHECK_FULL_REGS in copy_thread().

Lightly tested using Christian's test code on a Power8 LE VM.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/unistd.h| 1 +
 arch/powerpc/kernel/entry_32.S   | 8 
 arch/powerpc/kernel/entry_64.S   | 5 +
 arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
 4 files changed, 15 insertions(+)

v2: Add the wrapper for 32-bit as well, don't allow SPU programs to call
clone3 (switch ABI to nospu).

v1: https://lore.kernel.org/r/20190722132231.10169-1-...@ellerman.id.au

diff --git a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
index 68473c3c471c..b0720c7c3fcf 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -49,6 +49,7 @@
 #define __ARCH_WANT_SYS_FORK
 #define __ARCH_WANT_SYS_VFORK
 #define __ARCH_WANT_SYS_CLONE
+#define __ARCH_WANT_SYS_CLONE3
 
 #endif /* __ASSEMBLY__ */
 #endif /* _ASM_POWERPC_UNISTD_H_ */
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 85fdb6d879f1..54fab22c9a43 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -597,6 +597,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stw r0,_TRAP(r1)/* register set saved */
b   sys_clone
 
+   .globl  ppc_clone3
+ppc_clone3:
+   SAVE_NVGPRS(r1)
+   lwz r0,_TRAP(r1)
+   rlwinm  r0,r0,0,0,30/* clear LSB to indicate full */
+   stw r0,_TRAP(r1)/* register set saved */
+   b   sys_clone3
+
.globl  ppc_swapcontext
 ppc_swapcontext:
SAVE_NVGPRS(r1)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index d9105fcf4021..0a0b5310f54a 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -487,6 +487,11 @@ _GLOBAL(ppc_clone)
bl  sys_clone
b   .Lsyscall_exit
 
+_GLOBAL(ppc_clone3)
+   bl  save_nvgprs
+   bl  sys_clone3
+   b   .Lsyscall_exit
+
 _GLOBAL(ppc32_swapcontext)
bl  save_nvgprs
bl  compat_sys_swapcontext
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl 
b/arch/powerpc/kernel/syscalls/syscall.tbl
index f2c3bda2d39f..43f736ed47f2 100644
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@ -516,3 +516,4 @@
 432common  fsmount sys_fsmount
 433common  fspick  sys_fspick
 434common  pidfd_open  sys_pidfd_open
+435nospu   clone3  ppc_clone3
-- 
2.20.1



Re: [PATCH] powerpc: Wire up clone3 syscall

2019-07-24 Thread Michael Ellerman
Christian Brauner  writes:
> On Mon, Jul 22, 2019 at 11:22:31PM +1000, Michael Ellerman wrote:
>> Wire up the new clone3 syscall added in commit 7f192e3cd316 ("fork:
>> add clone3").
>> 
>> This requires a ppc_clone3 wrapper, in order to save the non-volatile
>> GPRs before calling into the generic syscall code. Otherwise we hit
>> the BUG_ON in CHECK_FULL_REGS in copy_thread().
>> 
>> Lightly tested using Christian's test code on a Power8 LE VM.
>> 
>> Signed-off-by: Michael Ellerman 
>
> Thank you, Michael!
>
> One comment below, otherwise:
>
> Acked-by: Christian Brauner 

Thanks.

...
>> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl 
>> b/arch/powerpc/kernel/syscalls/syscall.tbl
>> index f2c3bda2d39f..6886ecb590d5 100644
>> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
>> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
>> @@ -516,3 +516,4 @@
>>  432 common  fsmount sys_fsmount
>>  433 common  fspick  sys_fspick
>>  434 common  pidfd_open  sys_pidfd_open
>> +435 common  clone3  ppc_clone3
>
> Note that in v5.3-rc1 there's now a comment that 435 is reserved in
> there. So this will likely cause a merge conflict. You might want to
> base your change off of v5.3-rc1 instead to avoid that. :)

Thanks for the heads-up.

My fixes branch is already based off pre-rc1, and in general Linus can
handle a trivial merge conflict like that.

But given I had to send a v2 to fix the 32-bit build (doh!), I'll move
my fixes up past rc1 once Linus has merged what's in there now, and then
do this patch based on top of rc1, so there'll be no conflict.

cheers


Re: [PATCH v2] powerpc: Wire up clone3 syscall

2019-07-24 Thread Christian Brauner
On Thu, Jul 25, 2019 at 12:02:59AM +1000, Michael Ellerman wrote:
> Wire up the new clone3 syscall added in commit 7f192e3cd316 ("fork:
> add clone3").
> 
> This requires a ppc_clone3 wrapper, in order to save the non-volatile
> GPRs before calling into the generic syscall code. Otherwise we hit
> the BUG_ON in CHECK_FULL_REGS in copy_thread().
> 
> Lightly tested using Christian's test code on a Power8 LE VM.
> 
> Signed-off-by: Michael Ellerman 

Acked-by: Christian Brauner 

> ---
>  arch/powerpc/include/asm/unistd.h| 1 +
>  arch/powerpc/kernel/entry_32.S   | 8 
>  arch/powerpc/kernel/entry_64.S   | 5 +
>  arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
>  4 files changed, 15 insertions(+)
> 
> v2: Add the wrapper for 32-bit as well, don't allow SPU programs to call
> clone3 (switch ABI to nospu).
> 
> v1: https://lore.kernel.org/r/20190722132231.10169-1-...@ellerman.id.au
> 
> diff --git a/arch/powerpc/include/asm/unistd.h 
> b/arch/powerpc/include/asm/unistd.h
> index 68473c3c471c..b0720c7c3fcf 100644
> --- a/arch/powerpc/include/asm/unistd.h
> +++ b/arch/powerpc/include/asm/unistd.h
> @@ -49,6 +49,7 @@
>  #define __ARCH_WANT_SYS_FORK
>  #define __ARCH_WANT_SYS_VFORK
>  #define __ARCH_WANT_SYS_CLONE
> +#define __ARCH_WANT_SYS_CLONE3
>  
>  #endif   /* __ASSEMBLY__ */
>  #endif /* _ASM_POWERPC_UNISTD_H_ */
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 85fdb6d879f1..54fab22c9a43 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -597,6 +597,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
>   stw r0,_TRAP(r1)/* register set saved */
>   b   sys_clone
>  
> + .globl  ppc_clone3
> +ppc_clone3:
> + SAVE_NVGPRS(r1)
> + lwz r0,_TRAP(r1)
> + rlwinm  r0,r0,0,0,30/* clear LSB to indicate full */
> + stw r0,_TRAP(r1)/* register set saved */
> + b   sys_clone3
> +
>   .globl  ppc_swapcontext
>  ppc_swapcontext:
>   SAVE_NVGPRS(r1)
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index d9105fcf4021..0a0b5310f54a 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -487,6 +487,11 @@ _GLOBAL(ppc_clone)
>   bl  sys_clone
>   b   .Lsyscall_exit
>  
> +_GLOBAL(ppc_clone3)
> +   bl  save_nvgprs
> +   bl  sys_clone3
> +   b   .Lsyscall_exit
> +
>  _GLOBAL(ppc32_swapcontext)
>   bl  save_nvgprs
>   bl  compat_sys_swapcontext
> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl 
> b/arch/powerpc/kernel/syscalls/syscall.tbl
> index f2c3bda2d39f..43f736ed47f2 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -516,3 +516,4 @@
>  432  common  fsmount sys_fsmount
>  433  common  fspick  sys_fspick
>  434  common  pidfd_open  sys_pidfd_open
> +435  nospu   clone3  ppc_clone3
> -- 
> 2.20.1
> 


[PATCH 3/5] arch: wire-up pidfd_wait()

2019-07-24 Thread Christian Brauner
This wires up the pidfd_wait() syscall into all arches at once.

Signed-off-by: Christian Brauner 
Cc: Arnd Bergmann 
Cc: "Eric W. Biederman" 
Cc: Kees Cook 
Cc: Joel Fernandes (Google) 
Cc: Thomas Gleixner 
Cc: Jann Horn 
Cc: David Howells 
Cc: Andy Lutomirsky 
Cc: Andrew Morton 
Cc: Oleg Nesterov 
Cc: Aleksa Sarai 
Cc: Linus Torvalds 
Cc: Al Viro 
Cc: linux-...@vger.kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
Cc: linux-a...@vger.kernel.org
Cc: x...@kernel.org
---
 arch/alpha/kernel/syscalls/syscall.tbl  | 1 +
 arch/arm/tools/syscall.tbl  | 1 +
 arch/arm64/include/asm/unistd.h | 2 +-
 arch/arm64/include/asm/unistd32.h   | 4 +++-
 arch/ia64/kernel/syscalls/syscall.tbl   | 1 +
 arch/m68k/kernel/syscalls/syscall.tbl   | 1 +
 arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
 arch/mips/kernel/syscalls/syscall_n32.tbl   | 1 +
 arch/mips/kernel/syscalls/syscall_n64.tbl   | 1 +
 arch/mips/kernel/syscalls/syscall_o32.tbl   | 1 +
 arch/parisc/kernel/syscalls/syscall.tbl | 1 +
 arch/powerpc/kernel/syscalls/syscall.tbl| 1 +
 arch/s390/kernel/syscalls/syscall.tbl   | 1 +
 arch/sh/kernel/syscalls/syscall.tbl | 1 +
 arch/sparc/kernel/syscalls/syscall.tbl  | 1 +
 arch/x86/entry/syscalls/syscall_32.tbl  | 1 +
 arch/x86/entry/syscalls/syscall_64.tbl  | 1 +
 arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
 include/linux/syscalls.h| 4 
 include/uapi/asm-generic/unistd.h   | 4 +++-
 20 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/arch/alpha/kernel/syscalls/syscall.tbl 
b/arch/alpha/kernel/syscalls/syscall.tbl
index 728fe028c02c..ca3e593f0c7a 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -475,3 +475,4 @@
 543common  fspick  sys_fspick
 544common  pidfd_open  sys_pidfd_open
 # 545 reserved for clone3
+548common  pidfd_wait  sys_pidfd_wait
diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
index 6da7dc4d79cc..5e448d915b2f 100644
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@ -449,3 +449,4 @@
 433common  fspick  sys_fspick
 434common  pidfd_open  sys_pidfd_open
 435common  clone3  sys_clone3
+438common  pidfd_wait  sys_pidfd_wait
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 2629a68b8724..b722e47377a5 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -38,7 +38,7 @@
 #define __ARM_NR_compat_set_tls(__ARM_NR_COMPAT_BASE + 5)
 #define __ARM_NR_COMPAT_END(__ARM_NR_COMPAT_BASE + 0x800)
 
-#define __NR_compat_syscalls   436
+#define __NR_compat_syscalls   439
 #endif
 
 #define __ARCH_WANT_SYS_CLONE
diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index 94ab29cf4f00..ca77c9d4f7a1 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -877,7 +877,9 @@ __SYSCALL(__NR_fsmount, sys_fsmount)
 __SYSCALL(__NR_fspick, sys_fspick)
 #define __NR_pidfd_open 434
 __SYSCALL(__NR_pidfd_open, sys_pidfd_open)
-#define __NR_clone3 435
+#define __NR_pidfd_wait 438
+__SYSCALL(__NR_pidfd_wait, sys_pidfd_wait)
+#define __NR_clone3 439
 __SYSCALL(__NR_clone3, sys_clone3)
 
 /*
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl 
b/arch/ia64/kernel/syscalls/syscall.tbl
index 36d5faf4c86c..f038afaced9b 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -356,3 +356,4 @@
 433common  fspick  sys_fspick
 434common  pidfd_open  sys_pidfd_open
 # 435 reserved for clone3
+438common  pidfd_wait  sys_pidfd_wait
diff --git a/arch/m68k/kernel/syscalls/syscall.tbl 
b/arch/m68k/kernel/syscalls/syscall.tbl
index a88a285a0e5f..51f86f7b4cec 100644
--- a/arch/m68k/kernel/syscalls/syscall.tbl
+++ b/arch/m68k/kernel/syscalls/syscall.tbl
@@ -435,3 +435,4 @@
 433common  fspick  sys_fspick
 434common  pidfd_open  sys_pidfd_open
 # 435 reserved for clone3
+438common  pidfd_wait  sys_pidfd_wait
diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl 
b/arch/microblaze/kernel/syscalls/syscall.tbl
index 09b0cd7dab0a..24f912ac5dfa 100644
--- a/arch/microblaze/kernel/syscalls/syscall.tbl
+++ b/arch/microblaze/kernel/syscalls/syscall.tbl
@@ -441,3 +441,4 @@
 433common  fspick  

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-2 tag

2019-07-24 Thread pr-tracker-bot
The pull request you sent on Wed, 24 Jul 2019 23:42:31 +1000:

> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
> tags/powerpc-5.3-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bed38c3e2dca01b358a62b5e73b46e875742fd75

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH 01/10] ASoC: fsl_sai: add of_match data

2019-07-24 Thread Nicolin Chen
On Mon, Jul 22, 2019 at 03:48:24PM +0300, Daniel Baluta wrote:
> From: Lucas Stach 
> 
> New revisions of the SAI IP block have even more differences that need
> be taken into account by the driver. To avoid sprinking compatible
> checks all over the driver move the current differences into of_match_data.
> 
> Signed-off-by: Lucas Stach 

Looks like Mark has applied this already? If so, should probably
drop applied ones and rebase the remaining patches for a resend.


Re: [PATCH 06/10] ASoC: dt-bindings: Document dl_mask property

2019-07-24 Thread Nicolin Chen
On Mon, Jul 22, 2019 at 03:48:29PM +0300, Daniel Baluta wrote:
> SAI supports up to 8 data lines. This property let the user
> configure how many data lines should be used per transfer
> direction (Tx/Rx).
> 
> Signed-off-by: Daniel Baluta 
> ---
>  Documentation/devicetree/bindings/sound/fsl-sai.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt 
> b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> index 2e726b983845..59f4d965a5fb 100644
> --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> @@ -49,6 +49,11 @@ Optional properties:

> +  - fsl,dl_mask  : list of two integers (bitmask, first for RX, 
> second

Not quite in favor of the naming here; And this patch should
be sent to the devicetree maillist and add DT maintainers --
they would give some good naming advice.

>From my point of view, I feel, since data lines are enabled
consecutively, probably it'd be clear just to have something
like "fsl,num-datalines = <2 2>", corresponding to "dl_mask
= <0x3 0x3>". I believe there're examples in the existing DT
bindings, so let's see how others suggest.

> +   for TX) representing enabled datalines. Bit 0
> +   represents first data line, bit 1 represents second
> +   data line and so on. Data line is enabled if
> +   corresponding bit is set to 1.

Would be better to mention: "as a default use case, if this
property is absent, only the first data line will be enabled
for both TX and RX", since it's an optional property.

And one more extension(?) of it could be what if there's no
data line being physically connected for one direction, for
example "dl_mask = <0x0 0x1>", indicating that SAI enables
one single TX line only, so driver would disable RX feature.
What do you think?


Re: [PATCH 08/10] ASoC: dt-bindings: Document fcomb_mode property

2019-07-24 Thread Nicolin Chen
On Mon, Jul 22, 2019 at 03:48:31PM +0300, Daniel Baluta wrote:
> This allows combining multiple-data-line FIFOs into a
> single-data-line FIFO.
> 
> Signed-off-by: Daniel Baluta 
> ---
>  Documentation/devicetree/bindings/sound/fsl-sai.txt | 4 

This should be sent to devicetree mail-list also.

>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt 
> b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> index 59f4d965a5fb..ca27afd840ba 100644
> --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> @@ -54,6 +54,10 @@ Optional properties:
> represents first data line, bit 1 represents second
> data line and so on. Data line is enabled if
> corresponding bit is set to 1.
> +  - fsl,fcomb_mode   : list of two integers (first for RX, second for TX)
> +   representing FIFO combine mode. Possible values for
> +   combined mode are: 0 - disabled, 1 - Rx/Tx from shift
> +   registers, 2 - Rx/Tx by software, 3 - both.

Looks like a software configuration to me, instead of a device
property. Is this configurable by user case, or hard-coded by
SoC/hardware design?


Re: [PATCH 09/10] ASoC: fsl_sai: Add support for SAI new version

2019-07-24 Thread Nicolin Chen
On Mon, Jul 22, 2019 at 03:48:32PM +0300, Daniel Baluta wrote:
> New IP version introduces Version ID and Parameter registers
> and optionally added Timestamp feature.
> 
> VERID and PARAM registers are placed at the top of registers
> address space and some registers are shifted according to
> the following table:
> 
> Tx/Rx data registers and Tx/Rx FIFO registers keep their
> addresses, all other registers are shifted by 8.

Feels like Lucas's approach is neater. I saw that Register TMR
at 0x60 is exceptional during your previous discussion. So can
we apply an offset-cancellation for it exceptionally? I haven't
checked all the registers so this would look okay to me as well
if there are more than just Register TMR.

Thanks
Nicolin

> SAI Memory map is described in chapter 13.10.4.1.1 I2S Memory map
> of the Reference Manual [1].
> 
> In order to make as less changes as possible we attach an offset
> to each register offset to each changed register definition. The
> offset is read from each board private data.
> 
> [1]https://cache.nxp.com/secured/assets/documents/en/reference-manual/IMX8MDQLQRM.pdf?__gda__=1563728701_38bea7f0f726472cc675cb141b91bec7&fileExt=.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
>  sound/soc/fsl/fsl_sai.c | 240 +++-
>  sound/soc/fsl/fsl_sai.h |  41 +++
>  2 files changed, 162 insertions(+), 119 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 140014901fce..f2441b84877e 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -40,6 +40,7 @@ static const struct snd_pcm_hw_constraint_list 
> fsl_sai_rate_constraints = {
>  static irqreturn_t fsl_sai_isr(int irq, void *devid)
>  {
>   struct fsl_sai *sai = (struct fsl_sai *)devid;
> + unsigned int ofs = sai->soc_data->reg_offset;
>   struct device *dev = &sai->pdev->dev;
>   u32 flags, xcsr, mask;
>   bool irq_none = true;
> @@ -52,7 +53,7 @@ static irqreturn_t fsl_sai_isr(int irq, void *devid)
>   mask = (FSL_SAI_FLAGS >> FSL_SAI_CSR_xIE_SHIFT) << FSL_SAI_CSR_xF_SHIFT;
>  
>   /* Tx IRQ */
> - regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> + regmap_read(sai->regmap, FSL_SAI_TCSR(ofs), &xcsr);
>   flags = xcsr & mask;
>  
>   if (flags)
> @@ -82,11 +83,11 @@ static irqreturn_t fsl_sai_isr(int irq, void *devid)
>   xcsr &= ~FSL_SAI_CSR_xF_MASK;
>  
>   if (flags)
> - regmap_write(sai->regmap, FSL_SAI_TCSR, flags | xcsr);
> + regmap_write(sai->regmap, FSL_SAI_TCSR(ofs), flags | xcsr);
>  
>  irq_rx:
>   /* Rx IRQ */
> - regmap_read(sai->regmap, FSL_SAI_RCSR, &xcsr);
> + regmap_read(sai->regmap, FSL_SAI_RCSR(ofs), &xcsr);
>   flags = xcsr & mask;
>  
>   if (flags)
> @@ -116,7 +117,7 @@ static irqreturn_t fsl_sai_isr(int irq, void *devid)
>   xcsr &= ~FSL_SAI_CSR_xF_MASK;
>  
>   if (flags)
> - regmap_write(sai->regmap, FSL_SAI_RCSR, flags | xcsr);
> + regmap_write(sai->regmap, FSL_SAI_RCSR(ofs), flags | xcsr);
>  
>  out:
>   if (irq_none)
> @@ -140,6 +141,7 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai 
> *cpu_dai,
>   int clk_id, unsigned int freq, int fsl_dir)
>  {
>   struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
> + unsigned int ofs = sai->soc_data->reg_offset;
>   bool tx = fsl_dir == FSL_FMT_TRANSMITTER;
>   u32 val_cr2 = 0;
>  
> @@ -160,7 +162,7 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai 
> *cpu_dai,
>   return -EINVAL;
>   }
>  
> - regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx),
> + regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx, ofs),
>  FSL_SAI_CR2_MSEL_MASK, val_cr2);
>  
>   return 0;
> @@ -193,6 +195,7 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai 
> *cpu_dai,
>   unsigned int fmt, int fsl_dir)
>  {
>   struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
> + unsigned int ofs = sai->soc_data->reg_offset;
>   bool tx = fsl_dir == FSL_FMT_TRANSMITTER;
>   u32 val_cr2 = 0, val_cr4 = 0;
>  
> @@ -287,9 +290,9 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai 
> *cpu_dai,
>   return -EINVAL;
>   }
>  
> - regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx),
> + regmap_update_bits(sai->regmap, FSL_SAI_xCR2(tx, ofs),
>  FSL_SAI_CR2_BCP | FSL_SAI_CR2_BCD_MSTR, val_cr2);
> - regmap_update_bits(sai->regmap, FSL_SAI_xCR4(tx),
> + regmap_update_bits(sai->regmap, FSL_SAI_xCR4(tx, ofs),
>  FSL_SAI_CR4_MF | FSL_SAI_CR4_FSE |
>  FSL_SAI_CR4_FSP | FSL_SAI_CR4_FSD_MSTR, val_cr4);
>  
> @@ -316,6 +319,7 @@ static int fsl_sai_set_dai_fmt(struct snd_soc_dai 
> *cpu_dai, unsigned int fmt)
>  static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)
>  {
>   struct fsl_sai *sai = snd_soc_dai_get_drvdata(dai);
> +

Re: [PATCH v3 9/9] powerpc/eeh: Convert log messages to eeh_edev_* macros

2019-07-24 Thread Sam Bobroff
On Wed, Jul 24, 2019 at 07:47:55PM +1000, Oliver O'Halloran wrote:
> On Wed, Jul 24, 2019 at 7:24 PM kbuild test robot  wrote:
> >
> > Hi Sam,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on linus/master]
> > [also build test ERROR on v5.3-rc1 next-20190724]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Sam-Bobroff/powerpc-64-Adjust-order-in-pcibios_init/20190724-134001
> > config: powerpc-defconfig (attached as .config)
> > compiler: powerpc64-linux-gcc (GCC) 7.4.0
> > reproduce:
> > wget 
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > GCC_VERSION=7.4.0 make.cross ARCH=powerpc
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot 
> >
> > All errors (new ones prefixed by >>):
> >
> >arch/powerpc/kernel/eeh_driver.c: In function 'eeh_add_virt_device':
> > >> arch/powerpc/kernel/eeh_driver.c:459:17: error: unused variable 'pdn' 
> > >> [-Werror=unused-variable]
> >  struct pci_dn *pdn = eeh_dev_to_pdn(edev);
> 
> FYI this happens when CONFIG_IOV isn't set. Adding a __maybe_unused
> annotation fixes it.

Ah, thanks. This must be in eeh_add_virt_device().

Since there's now only a single use of pdn in that function, maybe we
can remove the variable, and the IOV case can do this:
pci_iov_add_virtfn(edev->physfn, eeh_dev_to_pdn(edev)->vf_index);

> > ^~~
> >cc1: all warnings being treated as errors
> >
> > vim +/pdn +459 arch/powerpc/kernel/eeh_driver.c
> >
> > 77bd7415 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
> > 2005-11-03  454
> > bf773df9 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
> > 2018-09-12  455  static void *eeh_add_virt_device(struct eeh_dev *edev)
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  456  {
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  457  struct pci_driver *driver;
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  458  struct pci_dev *dev = eeh_dev_to_pci_dev(edev);
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04 @459  struct pci_dn *pdn = eeh_dev_to_pdn(edev);
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  460
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  461  if (!(edev->physfn)) {
> > 6dad7bbd arch/powerpc/kernel/eeh_driver.cSam Bobroff   
> > 2019-07-23  462  eeh_edev_warn(edev, "Not for VF\n");
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  463  return NULL;
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  464  }
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  465
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  466  driver = eeh_pcid_get(dev);
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  467  if (driver) {
> > 46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
> > 2018-05-25  468  if (driver->err_handler) {
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  469  eeh_pcid_put(dev);
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  470  return NULL;
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  471  }
> > 46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
> > 2018-05-25  472  eeh_pcid_put(dev);
> > 46d4be41 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
> > 2018-05-25  473  }
> > 67086e32 arch/powerpc/kernel/eeh_driver.cWei Yang  
> > 2016-03-04  474
> >
> > :: The code at line 459 was first introduced by commit
> > :: 67086e32b56481531ab1292b284e074b1a8d764c powerpc/eeh: powerpc/eeh: 
> > Support error recovery for VF PE
> >
> > :: TO: Wei Yang 
> > :: CC: Michael Ellerman 
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> 


signature.asc
Description: PGP signature


Re: [alsa-devel] [PATCH 01/10] ASoC: fsl_sai: add of_match data

2019-07-24 Thread Daniel Baluta
On Thu, Jul 25, 2019 at 1:34 AM Nicolin Chen  wrote:
>
> On Mon, Jul 22, 2019 at 03:48:24PM +0300, Daniel Baluta wrote:
> > From: Lucas Stach 
> >
> > New revisions of the SAI IP block have even more differences that need
> > be taken into account by the driver. To avoid sprinking compatible
> > checks all over the driver move the current differences into of_match_data.
> >
> > Signed-off-by: Lucas Stach 
>
> Looks like Mark has applied this already? If so, should probably
> drop applied ones and rebase the remaining patches for a resend.

Yes 1/10 and 2/10 were already applied. Will drop them from next version.


Re: [alsa-devel] [PATCH 08/10] ASoC: dt-bindings: Document fcomb_mode property

2019-07-24 Thread Daniel Baluta
On Thu, Jul 25, 2019 at 2:22 AM Nicolin Chen  wrote:
>
> On Mon, Jul 22, 2019 at 03:48:31PM +0300, Daniel Baluta wrote:
> > This allows combining multiple-data-line FIFOs into a
> > single-data-line FIFO.
> >
> > Signed-off-by: Daniel Baluta 
> > ---
> >  Documentation/devicetree/bindings/sound/fsl-sai.txt | 4 
>
> This should be sent to devicetree mail-list also.
>
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt 
> > b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> > index 59f4d965a5fb..ca27afd840ba 100644
> > --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> > +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> > @@ -54,6 +54,10 @@ Optional properties:
> > represents first data line, bit 1 represents second
> > data line and so on. Data line is enabled if
> > corresponding bit is set to 1.
> > +  - fsl,fcomb_mode   : list of two integers (first for RX, second for TX)
> > +   representing FIFO combine mode. Possible values for
> > +   combined mode are: 0 - disabled, 1 - Rx/Tx from 
> > shift
> > +   registers, 2 - Rx/Tx by software, 3 - both.
>
> Looks like a software configuration to me, instead of a device
> property. Is this configurable by user case, or hard-coded by
> SoC/hardware design?

Indeed this is a software configuration and configurable by user case.
Will think of a another way to specify it.


Re: [alsa-devel] [PATCH 09/10] ASoC: fsl_sai: Add support for SAI new version

2019-07-24 Thread Daniel Baluta
On Thu, Jul 25, 2019 at 2:32 AM Nicolin Chen  wrote:
>
> On Mon, Jul 22, 2019 at 03:48:32PM +0300, Daniel Baluta wrote:
> > New IP version introduces Version ID and Parameter registers
> > and optionally added Timestamp feature.
> >
> > VERID and PARAM registers are placed at the top of registers
> > address space and some registers are shifted according to
> > the following table:
> >
> > Tx/Rx data registers and Tx/Rx FIFO registers keep their
> > addresses, all other registers are shifted by 8.
>
> Feels like Lucas's approach is neater. I saw that Register TMR
> at 0x60 is exceptional during your previous discussion. So can
> we apply an offset-cancellation for it exceptionally? I haven't
> checked all the registers so this would look okay to me as well
> if there are more than just Register TMR.

It is not just TMR exceptional. There are like half of the registers.
Thus: half of the registers need to be shifted and half of them
need to stay the same as in previous version of SAI.

I'm not seeing yet a neater approach. Lucas idea would somehow
work if regmap will allow some sort of translation function applied
over registers before being accessed.

Maybe Mark has some clues here?

thanks,
daniel.


Re: [alsa-devel] [PATCH 06/10] ASoC: dt-bindings: Document dl_mask property

2019-07-24 Thread Daniel Baluta
On Thu, Jul 25, 2019 at 2:14 AM Nicolin Chen  wrote:
>
> On Mon, Jul 22, 2019 at 03:48:29PM +0300, Daniel Baluta wrote:
> > SAI supports up to 8 data lines. This property let the user
> > configure how many data lines should be used per transfer
> > direction (Tx/Rx).
> >
> > Signed-off-by: Daniel Baluta 
> > ---
> >  Documentation/devicetree/bindings/sound/fsl-sai.txt | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt 
> > b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> > index 2e726b983845..59f4d965a5fb 100644
> > --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
> > +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
> > @@ -49,6 +49,11 @@ Optional properties:
>
> > +  - fsl,dl_mask  : list of two integers (bitmask, first for 
> > RX, second
>
> Not quite in favor of the naming here; And this patch should
> be sent to the devicetree maillist and add DT maintainers --
> they would give some good naming advice.
>
> From my point of view, I feel, since data lines are enabled
> consecutively, probably it'd be clear just to have something
> like "fsl,num-datalines = <2 2>", corresponding to "dl_mask
> = <0x3 0x3>". I believe there're examples in the existing DT
> bindings, so let's see how others suggest.
>

Your suggestion looks good to me. Anyhow, after reading again the
documentation it seems that datalines are not always required to
be consecutive.

The need to be consecutive only when FIFO combine mode is enabled.
Will fix the documentation in the next version.


remove default fallbacks in dma_map_ops

2019-07-24 Thread Christoph Hellwig
Hi all,

we have a few places where the DMA mapping layer has non-trivial default
actions that are questionable and/or dangerous.

This series instead wires up the mmap, get_sgtable and get_required_mask
methods explicitly and cleans up some surrounding areas.  This also means
we could get rid of the ARCH_NO_COHERENT_DMA_MMAP kconfig option, as we
now require a mmap method wired up, or in case of non-coherent dma-direct
the presence of the arch_dma_coherent_to_pfn hook.  The only interesting
case is that the sound code also checked the ARCH_NO_COHERENT_DMA_MMAP
symbol in somewhat odd ways, so I'd like to see a review of the sound
situation before going forward with that patch.


[PATCH 1/5] m68knommu: add a pgprot_noncached stub

2019-07-24 Thread Christoph Hellwig
Provide a pgprot_noncached like all the other nommu ports so that
common code can rely on it being able to be present.  Note that this is
generally code that is not actually run on nommu, but at least we can
avoid nasty ifdefs by having a stub.

Signed-off-by: Christoph Hellwig 
---
 arch/m68k/include/asm/pgtable_no.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/m68k/include/asm/pgtable_no.h 
b/arch/m68k/include/asm/pgtable_no.h
index fc3a96c77bd8..06194c7ba151 100644
--- a/arch/m68k/include/asm/pgtable_no.h
+++ b/arch/m68k/include/asm/pgtable_no.h
@@ -29,6 +29,8 @@
 #define PAGE_READONLY  __pgprot(0)
 #define PAGE_KERNEL__pgprot(0)
 
+#define pgprot_noncached(prot)   (prot)
+
 extern void paging_init(void);
 #define swapper_pg_dir ((pgd_t *) 0)
 
-- 
2.20.1



[PATCH 2/5] dma-mapping: move the dma_get_sgtable API comments from arm to common code

2019-07-24 Thread Christoph Hellwig
The comments are spot on and should be near the central API, not just
near a single implementation.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/mm/dma-mapping.c | 11 ---
 kernel/dma/mapping.c  | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6774b03aa405..4410af33c5c4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -877,17 +877,6 @@ static void arm_coherent_dma_free(struct device *dev, 
size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
 }
 
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable.  This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- *a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- *as we will try to flush the memory through a different alias to that
- *actually being used (and the flushes are redundant.)
- */
 int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
 void *cpu_addr, dma_addr_t handle, size_t size,
 unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b945239621d8..4ceb5b9016d8 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct 
sg_table *sgt,
return ret;
 }
 
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable.  This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ *a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ *as we will try to flush the memory through a different alias to that
+ *actually being used (and the flushes are redundant.)
+ */
 int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
-- 
2.20.1



[PATCH 4/5] dma-mapping: provide a better default ->get_required_mask

2019-07-24 Thread Christoph Hellwig
Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
of IOVA space, and the generic direct mapping code already provides its
own routines that is intelligent based on the amount of memory actually
present.  Wire up the dma-direct routine for the ARM direct mapping code
as well, and otherwise default to the constant 32-bit mask.  This way
we only need to override it for the occasional odd IOMMU that requires
64-bit IOVA support, or IOMMU drivers that are more efficient if they
can fall back to the direct mapping.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/mm/dma-mapping.c   |  3 +++
 arch/powerpc/platforms/ps3/system-bus.c |  7 --
 arch/x86/kernel/amd_gart_64.c   |  1 +
 kernel/dma/mapping.c| 30 +
 4 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4410af33c5c4..9c9a23e5600d 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -192,6 +193,7 @@ const struct dma_map_ops arm_dma_ops = {
.sync_sg_for_cpu= arm_dma_sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_sync_sg_for_device,
.dma_supported  = arm_dma_supported,
+   .get_required_mask  = dma_direct_get_required_mask,
 };
 EXPORT_SYMBOL(arm_dma_ops);
 
@@ -212,6 +214,7 @@ const struct dma_map_ops arm_coherent_dma_ops = {
.map_sg = arm_dma_map_sg,
.map_resource   = dma_direct_map_resource,
.dma_supported  = arm_dma_supported,
+   .get_required_mask  = dma_direct_get_required_mask,
 };
 EXPORT_SYMBOL(arm_coherent_dma_ops);
 
diff --git a/arch/powerpc/platforms/ps3/system-bus.c 
b/arch/powerpc/platforms/ps3/system-bus.c
index 70fcc9736a8c..3542b7bd6a46 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -686,18 +686,12 @@ static int ps3_dma_supported(struct device *_dev, u64 
mask)
return mask >= DMA_BIT_MASK(32);
 }
 
-static u64 ps3_dma_get_required_mask(struct device *_dev)
-{
-   return DMA_BIT_MASK(32);
-}
-
 static const struct dma_map_ops ps3_sb_dma_ops = {
.alloc = ps3_alloc_coherent,
.free = ps3_free_coherent,
.map_sg = ps3_sb_map_sg,
.unmap_sg = ps3_sb_unmap_sg,
.dma_supported = ps3_dma_supported,
-   .get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_sb_map_page,
.unmap_page = ps3_unmap_page,
.mmap = dma_common_mmap,
@@ -710,7 +704,6 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
.map_sg = ps3_ioc0_map_sg,
.unmap_sg = ps3_ioc0_unmap_sg,
.dma_supported = ps3_dma_supported,
-   .get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_ioc0_map_page,
.unmap_page = ps3_unmap_page,
.mmap = dma_common_mmap,
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index a65b4a9c7f87..d02662238b57 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -680,6 +680,7 @@ static const struct dma_map_ops gart_dma_ops = {
.dma_supported  = dma_direct_supported,
.mmap   = dma_common_mmap,
.get_sgtable= dma_common_get_sgtable,
+   .get_required_mask  = dma_direct_get_required_mask,
 };
 
 static void gart_iommu_shutdown(void)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index cdb157cd70e7..7dff1829c8c5 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -231,25 +231,6 @@ int dma_mmap_attrs(struct device *dev, struct 
vm_area_struct *vma,
 }
 EXPORT_SYMBOL(dma_mmap_attrs);
 
-static u64 dma_default_get_required_mask(struct device *dev)
-{
-   u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-   u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-   u64 mask;
-
-   if (!high_totalram) {
-   /* convert to mask just covering totalram */
-   low_totalram = (1 << (fls(low_totalram) - 1));
-   low_totalram += low_totalram - 1;
-   mask = low_totalram;
-   } else {
-   high_totalram = (1 << (fls(high_totalram) - 1));
-   high_totalram += high_totalram - 1;
-   mask = (((u64)high_totalram) << 32) + 0x;
-   }
-   return mask;
-}
-
 u64 dma_get_required_mask(struct device *dev)
 {
const struct dma_map_ops *ops = get_dma_ops(dev);
@@ -258,7 +239,16 @@ u64 dma_get_required_mask(struct device *dev)
return dma_direct_get_required_mask(dev);
if (ops->get_required_mask)
return ops->get_required_mask(dev);
-   return dma_default_get_required_mask(dev);
+
+   /*
+* We require every DMA ops implementation to at least support a 32-bit

[PATCH 3/5] dma-mapping: explicitly wire up ->mmap and ->get_sgtable

2019-07-24 Thread Christoph Hellwig
While the default ->mmap and ->get_sgtable implementations work for the
majority of our dma_map_ops impementations they are inherently safe
for others that don't use the page allocator or CMA and/or use their
own way of remapping not covered by the common code.  So remove the
defaults if these methods are not wired up, but instead wire up the
default implementations for all safe instances.

Fixes: e1c7e324539a ("dma-mapping: always provide the dma_map_ops based 
implementation")
Signed-off-by: Christoph Hellwig 
---
 arch/alpha/kernel/pci_iommu.c   |  2 ++
 arch/ia64/hp/common/sba_iommu.c |  2 ++
 arch/ia64/sn/pci/pci_dma.c  |  2 ++
 arch/mips/jazz/jazzdma.c|  2 ++
 arch/powerpc/kernel/dma-iommu.c |  2 ++
 arch/powerpc/platforms/ps3/system-bus.c |  4 
 arch/powerpc/platforms/pseries/vio.c|  2 ++
 arch/s390/pci/pci_dma.c |  2 ++
 arch/sparc/kernel/iommu.c   |  2 ++
 arch/sparc/kernel/pci_sun4v.c   |  2 ++
 arch/x86/kernel/amd_gart_64.c   |  2 ++
 arch/x86/kernel/pci-calgary_64.c|  2 ++
 drivers/iommu/amd_iommu.c   |  2 ++
 drivers/iommu/intel-iommu.c |  2 ++
 kernel/dma/mapping.c| 20 
 15 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 242108439f42..7f1925a32c99 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -955,5 +955,7 @@ const struct dma_map_ops alpha_pci_ops = {
.map_sg = alpha_pci_map_sg,
.unmap_sg   = alpha_pci_unmap_sg,
.dma_supported  = alpha_pci_supported,
+   .mmap   = dma_common_mmap,
+   .get_sgtable= dma_common_get_sgtable,
 };
 EXPORT_SYMBOL(alpha_pci_ops);
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 3d24cc43385b..4c0ea6c2833d 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -2183,6 +2183,8 @@ const struct dma_map_ops sba_dma_ops = {
.map_sg = sba_map_sg_attrs,
.unmap_sg   = sba_unmap_sg_attrs,
.dma_supported  = sba_dma_supported,
+   .mmap   = dma_common_mmap,
+   .get_sgtable= dma_common_get_sgtable,
 };
 
 void sba_dma_init(void)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/pci/pci_dma.c
index b7d42e4edc1f..12ffb9c0d738 100644
--- a/arch/ia64/sn/pci/pci_dma.c
+++ b/arch/ia64/sn/pci/pci_dma.c
@@ -438,6 +438,8 @@ static struct dma_map_ops sn_dma_ops = {
.unmap_sg   = sn_dma_unmap_sg,
.dma_supported  = sn_dma_supported,
.get_required_mask  = sn_dma_get_required_mask,
+   .mmap   = dma_common_mmap,
+   .get_sgtable= dma_common_get_sgtable,
 };
 
 void sn_dma_init(void)
diff --git a/arch/mips/jazz/jazzdma.c b/arch/mips/jazz/jazzdma.c
index 1804dc9d8136..a01e14955187 100644
--- a/arch/mips/jazz/jazzdma.c
+++ b/arch/mips/jazz/jazzdma.c
@@ -682,5 +682,7 @@ const struct dma_map_ops jazz_dma_ops = {
.sync_sg_for_device = jazz_dma_sync_sg_for_device,
.dma_supported  = dma_direct_supported,
.cache_sync = arch_dma_cache_sync,
+   .mmap   = dma_common_mmap,
+   .get_sgtable= dma_common_get_sgtable,
 };
 EXPORT_SYMBOL(jazz_dma_ops);
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index a0879674a9c8..2f5a53874f6d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -208,4 +208,6 @@ const struct dma_map_ops dma_iommu_ops = {
.sync_single_for_device = dma_iommu_sync_for_device,
.sync_sg_for_cpu= dma_iommu_sync_sg_for_cpu,
.sync_sg_for_device = dma_iommu_sync_sg_for_device,
+   .mmap   = dma_common_mmap,
+   .get_sgtable= dma_common_get_sgtable,
 };
diff --git a/arch/powerpc/platforms/ps3/system-bus.c 
b/arch/powerpc/platforms/ps3/system-bus.c
index 98410119c47b..70fcc9736a8c 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -700,6 +700,8 @@ static const struct dma_map_ops ps3_sb_dma_ops = {
.get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_sb_map_page,
.unmap_page = ps3_unmap_page,
+   .mmap = dma_common_mmap,
+   .get_sgtable = dma_common_get_sgtable,
 };
 
 static const struct dma_map_ops ps3_ioc0_dma_ops = {
@@ -711,6 +713,8 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
.get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_ioc0_map_page,
.unmap_page = ps3_unmap_page,
+   .mmap = dma_common_mmap,
+   .get_sgtable = dma_common_get_sgtable,
 };
 
 /**
diff --git a/arch/powerpc/platforms/pseries/vio.c

[PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP

2019-07-24 Thread Christoph Hellwig
Now that we never use a default ->mmap implementation, and non-coherent
architectures can control the presence of ->mmap support by enabling
ARCH_HAS_DMA_COHERENT_TO_PFN for the dma direct implementation there
is no need for a global config option to control the availability
of dma_common_mmap.

Signed-off-by: Christoph Hellwig 
---
 arch/Kconfig|  3 ---
 arch/c6x/Kconfig|  1 -
 arch/m68k/Kconfig   |  1 -
 arch/microblaze/Kconfig |  1 -
 arch/parisc/Kconfig |  1 -
 arch/sh/Kconfig |  1 -
 arch/xtensa/Kconfig |  1 -
 kernel/dma/mapping.c|  4 
 sound/core/pcm_native.c | 10 +-
 9 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..ec2834206d08 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -790,9 +790,6 @@ config COMPAT_32BIT_TIME
  This is relevant on all 32-bit architectures, and 64-bit architectures
  as part of compat syscall handling.
 
-config ARCH_NO_COHERENT_DMA_MMAP
-   bool
-
 config ARCH_NO_PREEMPT
bool
 
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index b4fb61c83494..e65e8d82442a 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -20,7 +20,6 @@ config C6X
select OF_EARLY_FLATTREE
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
-   select ARCH_NO_COHERENT_DMA_MMAP
select MMU_GATHER_NO_RANGE if MMU
 
 config MMU
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index c518d695c376..614b355ae338 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -8,7 +8,6 @@ config M68K
select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
-   select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_NO_PREEMPT if !COLDFIRE
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index d411de05b628..632c9477a0f6 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -9,7 +9,6 @@ config MICROBLAZE
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_MIGHT_HAVE_PC_PARPORT
-   select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select TIMER_OF
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6d732e451071..e9dd88b7f81e 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -52,7 +52,6 @@ config PARISC
select GENERIC_SCHED_CLOCK
select HAVE_UNSTABLE_SCHED_CLOCK if SMP
select GENERIC_CLOCKEVENTS
-   select ARCH_NO_COHERENT_DMA_MMAP
select CPU_NO_EFFICIENT_FFS
select NEED_DMA_MAP_STATE
select NEED_SG_DMA_LENGTH
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 6b1b5941b618..f356ee674d89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -5,7 +5,6 @@ config SUPERH
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_MIGHT_HAVE_PC_PARPORT
-   select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select HAVE_PATA_PLATFORM
select CLKDEV_LOOKUP
select DMA_DECLARE_COHERENT
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index ebc135bda921..70653aed3005 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -5,7 +5,6 @@ config XTENSA
select ARCH_HAS_BINFMT_FLAT if !MMU
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
-   select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_FRAME_POINTERS
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 7dff1829c8c5..815446f76995 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -169,7 +169,6 @@ int dma_common_mmap(struct device *dev, struct 
vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
 {
-#ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long off = vma->vm_pgoff;
@@ -198,9 +197,6 @@ int dma_common_mmap(struct device *dev, struct 
vm_area_struct *vma,
 
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
user_count << PAGE_SHIFT, vma->vm_page_prot);
-#else
-   return -ENXIO;
-#endif /* !CONFIG_ARCH_NO_COHERENT_DMA_MMAP */
 }
 
 /**
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 860543a4c840..2dadc708343a 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -218,15 +218,7 @@ int snd_pcm_info_user(struct snd_pcm_substream *substream,
 
 static bool hw_support_mmap(struct snd_pcm_substream