* [PATCH 21/23] coresight: etm4x: Fix use-after-free of per-cpu etm drvdata
From: Mathieu Poirier @ 2020-05-18 18:02 UTC (permalink / raw)
To: gregkh; +Cc: linux-arm-kernel
In-Reply-To: <20200518180242.7916-1-mathieu.poirier@linaro.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
etm probe could be deferred due to the dependency in the trace
path chain and may be retried. We need to clear the per-cpu
etmdrvdata entry for the etm in case of a failure to avoid
use-after-free cases as reported below:
KASAN use-after-free bug in etm4_cpu_pm_notify():
[ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized
[ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024
[ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0
[ 8.581927]
[ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314
[ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized
[ 8.594195] Call trace:
[ 8.594205] dump_backtrace+0x0/0x188
[ 8.594209] show_stack+0x20/0x2c
[ 8.594216] dump_stack+0xdc/0x144
[ 8.594227] print_address_description+0x3c/0x494
[ 8.594232] __kasan_report+0x144/0x168
[ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized
[ 8.602563] kasan_report+0x10/0x18
[ 8.602568] check_memory_region+0x1a4/0x1b4
[ 8.602572] __kasan_check_read+0x18/0x24
[ 8.602577] etm4_cpu_pm_notify+0x580/0x2024
[ 8.665945] notifier_call_chain+0x5c/0x90
[ 8.670166] __atomic_notifier_call_chain+0x90/0xf8
[ 8.675182] cpu_pm_notify+0x40/0x6c
[ 8.678858] cpu_pm_enter+0x38/0x80
[ 8.682451] psci_enter_idle_state+0x34/0x70
[ 8.686844] cpuidle_enter_state+0xb8/0x20c
[ 8.691143] cpuidle_enter+0x38/0x4c
[ 8.694820] call_cpuidle+0x3c/0x68
[ 8.698408] do_idle+0x1a0/0x280
[ 8.701729] cpu_startup_entry+0x24/0x28
[ 8.705768] secondary_start_kernel+0x15c/0x170
[ 8.710423]
[ 8.711972] Allocated by task 242:
[ 8.715473] __kasan_kmalloc+0xf0/0x1ac
[ 8.719426] kasan_slab_alloc+0x14/0x1c
[ 8.723375] __kmalloc_track_caller+0x23c/0x388
[ 8.728040] devm_kmalloc+0x38/0x94
[ 8.731632] etm4_probe+0x48/0x3c8
[ 8.735140] amba_probe+0xbc/0x158
[ 8.738645] really_probe+0x144/0x408
[ 8.742412] driver_probe_device+0x70/0x140
[ 8.746716] __device_attach_driver+0x9c/0x110
[ 8.751287] bus_for_each_drv+0x90/0xd8
[ 8.755236] __device_attach+0xb4/0x164
[ 8.759188] device_initial_probe+0x20/0x2c
[ 8.763490] bus_probe_device+0x34/0x94
[ 8.767436] device_add+0x34c/0x3e0
[ 8.771029] amba_device_try_add+0x68/0x440
[ 8.775332] amba_deferred_retry_func+0x48/0xc8
[ 8.779997] process_one_work+0x344/0x648
[ 8.784127] worker_thread+0x2ac/0x47c
[ 8.787987] kthread+0x128/0x138
[ 8.791313] ret_from_fork+0x10/0x18
[ 8.794993]
[ 8.796532] Freed by task 242:
[ 8.799684] __kasan_slab_free+0x15c/0x22c
[ 8.803897] kasan_slab_free+0x10/0x1c
[ 8.807761] kfree+0x25c/0x4bc
[ 8.810913] release_nodes+0x240/0x2b0
[ 8.814767] devres_release_all+0x3c/0x54
[ 8.818887] really_probe+0x178/0x408
[ 8.822661] driver_probe_device+0x70/0x140
[ 8.826963] __device_attach_driver+0x9c/0x110
[ 8.831539] bus_for_each_drv+0x90/0xd8
[ 8.835487] __device_attach+0xb4/0x164
[ 8.839431] device_initial_probe+0x20/0x2c
[ 8.843732] bus_probe_device+0x34/0x94
[ 8.847678] device_add+0x34c/0x3e0
[ 8.851274] amba_device_try_add+0x68/0x440
[ 8.855576] amba_deferred_retry_func+0x48/0xc8
[ 8.860240] process_one_work+0x344/0x648
[ 8.864366] worker_thread+0x2ac/0x47c
[ 8.868228] kthread+0x128/0x138
[ 8.871557] ret_from_fork+0x10/0x18
[ 8.875231]
[ 8.876782] The buggy address belongs to the object at ffffff813304f800
[ 8.876782] which belongs to the cache kmalloc-1k of size 1024
[ 8.889632] The buggy address is located 200 bytes inside of
[ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00)
[ 8.901761] The buggy address belongs to the page:
[ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0
[ 8.917047] flags: 0x4000000000010200(slab|head)
[ 8.921799] raw: 4000000000010200 dead000000000100 dead000000000122 ffffff8146c03800
[ 8.929753] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[ 8.937703] page dumped because: kasan: bad access detected
[ 8.943433]
[ 8.944974] Memory state around the buggy address:
[ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.972157] ^
[ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 8.992713] ==================================================================
Fixes: f188b5e76aae9 ( "coresight: etm4x: Save/restore state across CPU low power states ")
Reported-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index fb0f5f4f3a91..747afc875f91 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -1516,6 +1516,7 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
return 0;
err_arch_supported:
+ etmdrvdata[drvdata->cpu] = NULL;
if (--etm4_count == 0) {
etm4_cpu_pm_unregister();
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 22/23] coresight: cti: Add CPU Hotplug handling to CTI driver
From: Mathieu Poirier @ 2020-05-18 18:02 UTC (permalink / raw)
To: gregkh; +Cc: linux-arm-kernel
In-Reply-To: <20200518180242.7916-1-mathieu.poirier@linaro.org>
From: Mike Leach <mike.leach@linaro.org>
Adds registration of CPU start and stop functions to CPU hotplug
mechanisms - for any CPU bound CTI.
Sets CTI powered flag according to state.
Will enable CTI on CPU start if there are existing enable requests.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/hwtracing/coresight/coresight-cti.c | 92 +++++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
2 files changed, 93 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-cti.c b/drivers/hwtracing/coresight/coresight-cti.c
index be61c1705916..7e7ec6dd93c0 100644
--- a/drivers/hwtracing/coresight/coresight-cti.c
+++ b/drivers/hwtracing/coresight/coresight-cti.c
@@ -8,6 +8,7 @@
#include <linux/atomic.h>
#include <linux/bits.h>
#include <linux/coresight.h>
+#include <linux/cpuhotplug.h>
#include <linux/device.h>
#include <linux/io.h>
#include <linux/kernel.h>
@@ -40,6 +41,12 @@ static DEFINE_MUTEX(ect_mutex);
#define csdev_to_cti_drvdata(csdev) \
dev_get_drvdata(csdev->dev.parent)
+/* power management handling */
+static int nr_cti_cpu;
+
+/* quick lookup list for CPU bound CTIs when power handling */
+static struct cti_drvdata *cti_cpu_drvdata[NR_CPUS];
+
/*
* CTI naming. CTI bound to cores will have the name cti_cpu<N> where
* N is the CPU ID. System CTIs will have the name cti_sys<I> where I
@@ -129,6 +136,35 @@ static int cti_enable_hw(struct cti_drvdata *drvdata)
return rc;
}
+/* re-enable CTI on CPU when using CPU hotplug */
+static void cti_cpuhp_enable_hw(struct cti_drvdata *drvdata)
+{
+ struct cti_config *config = &drvdata->config;
+ struct device *dev = &drvdata->csdev->dev;
+
+ pm_runtime_get_sync(dev->parent);
+ spin_lock(&drvdata->spinlock);
+ config->hw_powered = true;
+
+ /* no need to do anything if no enable request */
+ if (!atomic_read(&drvdata->config.enable_req_count))
+ goto cti_hp_not_enabled;
+
+ /* try to claim the device */
+ if (coresight_claim_device(drvdata->base))
+ goto cti_hp_not_enabled;
+
+ cti_write_all_hw_regs(drvdata);
+ config->hw_enabled = true;
+ spin_unlock(&drvdata->spinlock);
+ return;
+
+ /* did not re-enable due to no claim / no request */
+cti_hp_not_enabled:
+ spin_unlock(&drvdata->spinlock);
+ pm_runtime_put(dev->parent);
+}
+
/* disable hardware */
static int cti_disable_hw(struct cti_drvdata *drvdata)
{
@@ -620,6 +656,44 @@ static void cti_remove_conn_xrefs(struct cti_drvdata *drvdata)
}
}
+/* CPU HP handlers */
+static int cti_starting_cpu(unsigned int cpu)
+{
+ struct cti_drvdata *drvdata = cti_cpu_drvdata[cpu];
+
+ if (!drvdata)
+ return 0;
+
+ cti_cpuhp_enable_hw(drvdata);
+ return 0;
+}
+
+static int cti_dying_cpu(unsigned int cpu)
+{
+ struct cti_drvdata *drvdata = cti_cpu_drvdata[cpu];
+
+ if (!drvdata)
+ return 0;
+
+ spin_lock(&drvdata->spinlock);
+ drvdata->config.hw_powered = false;
+ coresight_disclaim_device(drvdata->base);
+ spin_unlock(&drvdata->spinlock);
+ return 0;
+}
+
+/* release PM registrations */
+static void cti_pm_release(struct cti_drvdata *drvdata)
+{
+ if (drvdata->ctidev.cpu >= 0) {
+ if (--nr_cti_cpu == 0) {
+ cpuhp_remove_state_nocalls(
+ CPUHP_AP_ARM_CORESIGHT_CTI_STARTING);
+ }
+ cti_cpu_drvdata[drvdata->ctidev.cpu] = NULL;
+ }
+}
+
/** cti ect operations **/
int cti_enable(struct coresight_device *csdev)
{
@@ -655,6 +729,7 @@ static void cti_device_release(struct device *dev)
mutex_lock(&ect_mutex);
cti_remove_conn_xrefs(drvdata);
+ cti_pm_release(drvdata);
/* remove from the list */
list_for_each_entry_safe(ect_item, ect_tmp, &ect_net, node) {
@@ -730,6 +805,22 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
goto err_out;
}
+ /* setup CPU power management handling for CPU bound CTI devices. */
+ if (drvdata->ctidev.cpu >= 0) {
+ cti_cpu_drvdata[drvdata->ctidev.cpu] = drvdata;
+ if (!nr_cti_cpu++) {
+ cpus_read_lock();
+ ret = cpuhp_setup_state_nocalls_cpuslocked(
+ CPUHP_AP_ARM_CORESIGHT_CTI_STARTING,
+ "arm/coresight_cti:starting",
+ cti_starting_cpu, cti_dying_cpu);
+
+ cpus_read_unlock();
+ if (ret)
+ goto err_out;
+ }
+ }
+
/* create dynamic attributes for connections */
ret = cti_create_cons_sysfs(dev, drvdata);
if (ret) {
@@ -768,6 +859,7 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
return 0;
err_out:
+ cti_pm_release(drvdata);
return ret;
}
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 77d70b633531..6dc7332307ca 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -142,6 +142,7 @@ enum cpuhp_state {
CPUHP_AP_ARM_XEN_STARTING,
CPUHP_AP_ARM_KVMPV_STARTING,
CPUHP_AP_ARM_CORESIGHT_STARTING,
+ CPUHP_AP_ARM_CORESIGHT_CTI_STARTING,
CPUHP_AP_ARM64_ISNDEP_STARTING,
CPUHP_AP_SMPCFD_DYING,
CPUHP_AP_X86_TBOOT_DYING,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 23/23] coresight: cti: Add CPU idle pm notifer to CTI devices
From: Mathieu Poirier @ 2020-05-18 18:02 UTC (permalink / raw)
To: gregkh; +Cc: linux-arm-kernel
In-Reply-To: <20200518180242.7916-1-mathieu.poirier@linaro.org>
From: Mike Leach <mike.leach@linaro.org>
Adds a notify callback for CPU PM events to the CTI driver - for
CPU bound CTI devices.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/hwtracing/coresight/coresight-cti.c | 69 +++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-cti.c b/drivers/hwtracing/coresight/coresight-cti.c
index 7e7ec6dd93c0..40387d58c8e7 100644
--- a/drivers/hwtracing/coresight/coresight-cti.c
+++ b/drivers/hwtracing/coresight/coresight-cti.c
@@ -8,6 +8,7 @@
#include <linux/atomic.h>
#include <linux/bits.h>
#include <linux/coresight.h>
+#include <linux/cpu_pm.h>
#include <linux/cpuhotplug.h>
#include <linux/device.h>
#include <linux/io.h>
@@ -656,6 +657,70 @@ static void cti_remove_conn_xrefs(struct cti_drvdata *drvdata)
}
}
+/** cti PM callbacks **/
+static int cti_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
+ void *v)
+{
+ struct cti_drvdata *drvdata;
+ unsigned int cpu = smp_processor_id();
+ int notify_res = NOTIFY_OK;
+
+ if (!cti_cpu_drvdata[cpu])
+ return NOTIFY_OK;
+
+ drvdata = cti_cpu_drvdata[cpu];
+
+ if (WARN_ON_ONCE(drvdata->ctidev.cpu != cpu))
+ return NOTIFY_BAD;
+
+ spin_lock(&drvdata->spinlock);
+
+ switch (cmd) {
+ case CPU_PM_ENTER:
+ /* CTI regs all static - we have a copy & nothing to save */
+ drvdata->config.hw_powered = false;
+ if (drvdata->config.hw_enabled)
+ coresight_disclaim_device(drvdata->base);
+ break;
+
+ case CPU_PM_ENTER_FAILED:
+ drvdata->config.hw_powered = true;
+ if (drvdata->config.hw_enabled) {
+ if (coresight_claim_device(drvdata->base))
+ drvdata->config.hw_enabled = false;
+ }
+ break;
+
+ case CPU_PM_EXIT:
+ /* write hardware registers to re-enable. */
+ drvdata->config.hw_powered = true;
+ drvdata->config.hw_enabled = false;
+
+ /* check enable reference count to enable HW */
+ if (atomic_read(&drvdata->config.enable_req_count)) {
+ /* check we can claim the device as we re-power */
+ if (coresight_claim_device(drvdata->base))
+ goto cti_notify_exit;
+
+ drvdata->config.hw_enabled = true;
+ cti_write_all_hw_regs(drvdata);
+ }
+ break;
+
+ default:
+ notify_res = NOTIFY_DONE;
+ break;
+ }
+
+cti_notify_exit:
+ spin_unlock(&drvdata->spinlock);
+ return notify_res;
+}
+
+static struct notifier_block cti_cpu_pm_nb = {
+ .notifier_call = cti_cpu_pm_notify,
+};
+
/* CPU HP handlers */
static int cti_starting_cpu(unsigned int cpu)
{
@@ -687,6 +752,8 @@ static void cti_pm_release(struct cti_drvdata *drvdata)
{
if (drvdata->ctidev.cpu >= 0) {
if (--nr_cti_cpu == 0) {
+ cpu_pm_unregister_notifier(&cti_cpu_pm_nb);
+
cpuhp_remove_state_nocalls(
CPUHP_AP_ARM_CORESIGHT_CTI_STARTING);
}
@@ -815,6 +882,8 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
"arm/coresight_cti:starting",
cti_starting_cpu, cti_dying_cpu);
+ if (!ret)
+ ret = cpu_pm_register_notifier(&cti_cpu_pm_nb);
cpus_read_unlock();
if (ret)
goto err_out;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] drm/exynos: Remove dev_err() on platform_get_irq() failure
From: Joe Perches @ 2020-05-18 18:03 UTC (permalink / raw)
To: Tamseel Shams, inki.dae, jy0922.shim, sw0312.kim, kyungmin.park,
airlied, daniel
Cc: linux-samsung-soc, shaik.ameer, linux-kernel, krzk, dri-devel,
alim.akhtar, linux-arm-kernel
In-Reply-To: <20200518172708.48600-1-m.shams@samsung.com>
On Mon, 2020-05-18 at 22:57 +0530, Tamseel Shams wrote:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.
trivia:
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
[]
> @@ -1810,7 +1810,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
>
> dsi->irq = platform_get_irq(pdev, 0);
> if (dsi->irq < 0) {
> - dev_err(dev, "failed to request dsi irq resource\n");
> return dsi->irq;
> }
You could also remove the now atypical braces
if (dsi->irq < 0)
return dsi->irq;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
[]
> @@ -294,7 +294,6 @@ static int rotator_probe(struct platform_device *pdev)
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> return irq;
> }
etc...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Ira Weiny @ 2020-05-18 18:11 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200518042932.GA59205@roeck-us.net>
On Sun, May 17, 2020 at 09:29:32PM -0700, Guenter Roeck wrote:
> On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> > On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.weiny@intel.com wrote:
> > > > From: Ira Weiny <ira.weiny@intel.com>
> > > >
> > > > Every single architecture (including !CONFIG_HIGHMEM) calls...
> > > >
> > > > pagefault_enable();
> > > > preempt_enable();
> > > >
> > > > ... before returning from __kunmap_atomic(). Lift this code into the
> > > > kunmap_atomic() macro.
> > > >
> > > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> > > > be consistent.
> > > >
> > > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > >
> > > This patch results in:
> > >
> > > Starting init: /bin/sh exists but couldn't execute it (error -14)
> > >
> > > when trying to boot microblazeel:petalogix-ml605 in qemu.
> >
> > Thanks for the report. I'm not readily seeing the issue.
> >
> > Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
> >
> See below. Yes, CONFIG_HIGHMEM is set.
>
> The scripts used to build and boot the image are at:
>
> https://github.com/groeck/linux-build-test/tree/master/rootfs/microblazeel
>
> Hope this helps,
Thank you ...
Could you try the following patch?
commit 82c284b2bb74ca195dfcd35b70a175f010b9fd46 (HEAD -> lm-kmap17)
Author: Ira Weiny <ira.weiny@intel.com>
Date: Mon May 18 11:01:10 2020 -0700
microblaze/kmap: Don't enable pagefault/preempt twice
The kunmap_atomic clean up failed to remove the pagefault/preempt
enables on this path.
Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
diff --git a/arch/microblaze/mm/highmem.c b/arch/microblaze/mm/highmem.c
index ee8a422b2b76..92e0890416c9 100644
--- a/arch/microblaze/mm/highmem.c
+++ b/arch/microblaze/mm/highmem.c
@@ -57,11 +57,8 @@ void kunmap_atomic_high(void *kvaddr)
int type;
unsigned int idx;
- if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- preempt_enable();
+ if (vaddr < __fix_to_virt(FIX_KMAP_END))
return;
- }
type = kmap_atomic_idx();
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V3 10/15] arch/kmap: Define kmap_atomic_prot() for all arch's
From: Ira Weiny @ 2020-05-18 18:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200517173722.GA33341@roeck-us.net>
On Sun, May 17, 2020 at 10:37:22AM -0700, Guenter Roeck wrote:
> Hi,
>
> On Thu, May 07, 2020 at 07:59:58AM -0700, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > To support kmap_atomic_prot(), all architectures need to support
> > protections passed to their kmap_atomic_high() function. Pass
> > protections into kmap_atomic_high() and change the name to
> > kmap_atomic_high_prot() to match.
> >
> > Then define kmap_atomic_prot() as a core function which calls
> > kmap_atomic_high_prot() when needed.
> >
> > Finally, redefine kmap_atomic() as a wrapper of kmap_atomic_prot() with
> > the default kmap_prot exported by the architectures.
> >
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> This patch causes a variety of crashes whem booting powerpc images in qemu.
PowerPC has the same issue as microblaze and sparc.
I'm preping a patch with all three fixed which fixes the kunmap_atomic clean up
patch...
Sorry for not seeing this last night...
Hopefully this can explain all the problems. It is clearly a bug.
Ira
>
> There are lots of warnings such as:
>
> WARNING: CPU: 0 PID: 0 at lib/locking-selftest.c:743 irqsafe1_hard_spin_12+0x50/0xb0
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Tainted: G W 5.7.0-rc5-next-20200515 #1
> NIP: c0660c7c LR: c0660c44 CTR: c0660c2c
> REGS: c1223e68 TRAP: 0700 Tainted: G W (5.7.0-rc5-next-20200515)
> MSR: 00021000 <CE,ME> CR: 28000224 XER: 20000000
>
> GPR00: c0669c78 c1223f20 c113d560 c0660c44 00000000 00000001 c1223ea8 00000001
> GPR08: 00000000 00000001 0000fffc ffffffff 88000222 00000000 00000000 00000000
> GPR16: 00000000 00000000 00000000 00000000 c0000000 00000000 00000000 c1125084
> GPR24: c1125084 c1230000 c1879538 fffffffc 00000001 00000000 c1011afc c1230000
> NIP [c0660c7c] irqsafe1_hard_spin_12+0x50/0xb0
> LR [c0660c44] irqsafe1_hard_spin_12+0x18/0xb0
> Call Trace:
> [c1223f20] [c1880000] megasas_mgmt_info+0xee4/0x1008 (unreliable)
> [c1223f40] [c0669c78] dotest+0x38/0x550
> [c1223f70] [c066aa4c] locking_selftest+0x8bc/0x1d54
> [c1223fa0] [c10e0bc8] start_kernel+0x3ec/0x510
> [c1223ff0] [c00003a0] set_ivor+0x118/0x154
> Instruction dump:
> 81420000 38e80001 3d4a0001 2c080000 91420000 90e20488 40820008 91020470
> 81290000 5529031e 7d290034 5529d97e <0f090000> 3fe0c11c 3bff3964 3bff00ac
> irq event stamp: 588
> hardirqs last enabled at (587): [<c00b9fe4>] vprintk_emit+0x1b4/0x33c
> hardirqs last disabled at (588): [<c0660c44>] irqsafe1_hard_spin_12+0x18/0xb0
> softirqs last enabled at (0): [<00000000>] 0x0
> softirqs last disabled at (0): [<00000000>] 0x0
> ---[ end trace b18fe9e172f99d03 ]---
>
> This is followed by:
>
> BUG: sleeping function called from invalid context at lib/mpi/mpi-pow.c:245
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: cryptomgr_test
> INFO: lockdep is turned off.
> CPU: 0 PID: 14 Comm: cryptomgr_test Tainted: G W 5.7.0-rc5-next-20200515 #1
> Call Trace:
> [ce221b58] [c008755c] ___might_sleep+0x280/0x2a8 (unreliable)
> [ce221b78] [c06bc524] mpi_powm+0x634/0xc50
> [ce221c38] [c05eafdc] rsa_dec+0x88/0x134
> [ce221c78] [c05f3b40] test_akcipher_one+0x678/0x804
> [ce221dc8] [c05f3d7c] alg_test_akcipher+0xb0/0x130
> [ce221df8] [c05ee674] alg_test.part.0+0xb4/0x458
> [ce221ed8] [c05ed2b0] cryptomgr_test+0x30/0x50
> [ce221ef8] [c007cd74] kthread+0x134/0x170
> [ce221f38] [c001433c] ret_from_kernel_thread+0x14/0x1c
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> CPU: 0 PID: 14 Comm: cryptomgr_test Tainted: G W 5.7.0-rc5-next-20200515 #1
> Call Trace:
> [ce221e08] [c00530fc] panic+0x148/0x34c (unreliable)
> [ce221e68] [c0056460] do_exit+0xac0/0xb40
> [ce221eb8] [c00f5be8] find_kallsyms_symbol_value+0x0/0x128
> [ce221ed8] [c05ed2d0] crypto_alg_put+0x0/0x70
> [ce221ef8] [c007cd74] kthread+0x134/0x170
> [ce221f38] [c001433c] ret_from_kernel_thread+0x14/0x1c
>
> Bisect log is attached. The patch can not easily be reverted since
> it results in compile errors.
>
> Note that similar failures are seen with sparc32 images. Those bisect
> to a different patch, but reverting that patch doesn't fix the problem.
> The failure pattern (warnings followed by a crash in cryptomgr_test)
> is the same.
>
> Guenter
>
> ---
> # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific files for 20200515
> # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> git bisect start 'HEAD' 'v5.7-rc5'
> # good: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking branch 'crypto/master'
> git bisect good 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
> # good: [87f6f21783522e6d62127cf33ae5e95f50874beb] Merge remote-tracking branch 'spi/for-next'
> git bisect good 87f6f21783522e6d62127cf33ae5e95f50874beb
> # good: [5c428e8277d5d97c85126387d4e00aa5adde4400] Merge remote-tracking branch 'staging/staging-next'
> git bisect good 5c428e8277d5d97c85126387d4e00aa5adde4400
> # good: [f68de67ed934e7bdef4799fd7777c86f33f14982] Merge remote-tracking branch 'hyperv/hyperv-next'
> git bisect good f68de67ed934e7bdef4799fd7777c86f33f14982
> # bad: [54acd2dc52b069da59639eea0d0c92726f32fb01] mm/memblock: fix a typo in comment "implict"->"implicit"
> git bisect bad 54acd2dc52b069da59639eea0d0c92726f32fb01
> # good: [784a17aa58a529b84f7cc50f351ed4acf3bd11f3] mm: remove the pgprot argument to __vmalloc
> git bisect good 784a17aa58a529b84f7cc50f351ed4acf3bd11f3
> # good: [6cd8137ff37e9a37aee2d2a8889c8beb8eab192f] khugepaged: replace the usage of system(3) in the test
> git bisect good 6cd8137ff37e9a37aee2d2a8889c8beb8eab192f
> # bad: [6987da379826ed01b8a1cf046b67cc8cc10117cc] sparc: remove unnecessary includes
> git bisect bad 6987da379826ed01b8a1cf046b67cc8cc10117cc
> # good: [bc17b545388f64c09e83e367898e28f60277c584] mm/hugetlb: define a generic fallback for is_hugepage_only_range()
> git bisect good bc17b545388f64c09e83e367898e28f60277c584
> # good: [9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011] arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes
> git bisect good 9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011
> # bad: [89194ba5ee31567eeee9c81101b334c8e3248198] arch/kmap: define kmap_atomic_prot() for all arch's
> git bisect bad 89194ba5ee31567eeee9c81101b334c8e3248198
> # good: [022785d2bea99f8bc2a37b7b6c525eea26f6ac59] arch-kunmap_atomic-consolidate-duplicate-code-checkpatch-fixes
> git bisect good 022785d2bea99f8bc2a37b7b6c525eea26f6ac59
> # good: [a13c2f39e3f0519ddee57d26cc66ec70e3546106] arch/kmap: don't hard code kmap_prot values
> git bisect good a13c2f39e3f0519ddee57d26cc66ec70e3546106
> # first bad commit: [89194ba5ee31567eeee9c81101b334c8e3248198] arch/kmap: define kmap_atomic_prot() for all arch's
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 10/29] c6x: use asm-generic/cacheflush.h
From: Mark Salter @ 2020-05-18 18:20 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, linux-alpha, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
Jessica Yu, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-11-hch@lst.de>
On Fri, 2020-05-15 at 16:36 +0200, Christoph Hellwig wrote:
> C6x needs almost no cache flushing routines of its own. Rely on
> asm-generic/cacheflush.h for the defaults.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/c6x/include/asm/cacheflush.h | 19 +------------------
> 1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/arch/c6x/include/asm/cacheflush.h b/arch/c6x/include/asm/cacheflush.h
> index 4540b40475e6c..10922d528de6d 100644
> --- a/arch/c6x/include/asm/cacheflush.h
> +++ b/arch/c6x/include/asm/cacheflush.h
> @@ -16,21 +16,6 @@
> #include <asm/page.h>
> #include <asm/string.h>
>
> -/*
> - * virtually-indexed cache management (our cache is physically indexed)
> - */
> -#define flush_cache_all() do {} while (0)
> -#define flush_cache_mm(mm) do {} while (0)
> -#define flush_cache_dup_mm(mm) do {} while (0)
> -#define flush_cache_range(mm, start, end) do {} while (0)
> -#define flush_cache_page(vma, vmaddr, pfn) do {} while (0)
> -#define flush_cache_vmap(start, end) do {} while (0)
> -#define flush_cache_vunmap(start, end) do {} while (0)
> -#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
> -#define flush_dcache_page(page) do {} while (0)
> -#define flush_dcache_mmap_lock(mapping) do {} while (0)
> -#define flush_dcache_mmap_unlock(mapping) do {} while (0)
> -
> /*
> * physically-indexed cache management
> */
> @@ -49,14 +34,12 @@ do { \
> (unsigned long) page_address(page) + PAGE_SIZE)); \
> } while (0)
>
> -
> #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> do { \
> memcpy(dst, src, len); \
> flush_icache_range((unsigned) (dst), (unsigned) (dst) + (len)); \
> } while (0)
>
> -#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
> - memcpy(dst, src, len)
> +#include <asm-generic/cacheflush.h>
>
> #endif /* _ASM_C6X_CACHEFLUSH_H */
Acked-by: Mark Salter <msalter@redhat.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] arm64/cpufeature: Drop open encodings while extracting parange
From: Marc Zyngier @ 2020-05-18 18:46 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, Anshuman Khandual, Catalin Marinas, linux-kernel,
James Morse, kvmarm, linux-arm-kernel
In-Reply-To: <20200518170934.GT32394@willie-the-truck>
On Mon, 18 May 2020 18:09:34 +0100,
Will Deacon <will@kernel.org> wrote:
>
> On Mon, May 18, 2020 at 05:59:59PM +0100, Will Deacon wrote:
> > On Wed, May 13, 2020 at 02:33:34PM +0530, Anshuman Khandual wrote:
> > > Currently there are multiple instances of parange feature width mask open
> > > encodings while fetching it's value. Even the width mask value (0x7) itself
> > > is not accurate. It should be (0xf) per ID_AA64MMFR0_EL1.PARange[3:0] as in
> > > ARM ARM (0487F.a). Replace them with cpuid_feature_extract_unsigned_field()
> > > which can extract given standard feature (4 bits width i.e 0xf mask) field.
> > >
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Marc Zyngier <maz@kernel.org>
> > > Cc: James Morse <james.morse@arm.com>
> > > Cc: kvmarm@lists.cs.columbia.edu
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Cc: linux-kernel@vger.kernel.org
> > >
> > > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > > ---
> > > Changes in V2:
> > >
> > > - Used cpuid_feature_extract_unsigned_field() per Mark
> > >
> > > Changes in V1: (https://patchwork.kernel.org/patch/11541913/)
> > >
> > > arch/arm64/kernel/cpufeature.c | 3 ++-
> > > arch/arm64/kvm/reset.c | 11 ++++++++---
> > > 2 files changed, 10 insertions(+), 4 deletions(-)
> >
> > Acked-by: Will Deacon <will@kernel.org>
> >
> > I'm assuming Marc will take this, but let me know if it should go via arm64
> > instead (where we have a bunch of other cpufeature stuff queued).
>
> Hmm, but having just spotted [1], it looks like we might need a bit of
> co-ordination here. Marc?
Yeah, there is a clear dependency between the two. I'm happy to take
both patches via the KVM tree, or to have a shared branch with the
arm64 tree (we already have one for Andrew's generic AT patch).
Just let me know,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arch/{mips, sparc, microblaze, powerpc}: Don't enable pagefault/preempt twice
From: ira.weiny @ 2020-05-18 18:48 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Ira Weiny, Thomas Gleixner,
Helge Deller, x86, linux-csky, Christoph Hellwig, Ingo Molnar,
linux-snps-arc, linux-xtensa, Borislav Petkov, Al Viro,
Andy Lutomirski, Dan Williams, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-mips, Christian Koenig,
linuxppc-dev, David S. Miller
In-Reply-To: <20200507150004.1423069-8-ira.weiny@intel.com>
From: Ira Weiny <ira.weiny@intel.com>
The kunmap_atomic clean up failed to remove one set of pagefault/preempt
enables when vaddr is not in the fixmap.
Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
arch/microblaze/mm/highmem.c | 5 +----
arch/mips/mm/highmem.c | 5 +----
arch/powerpc/mm/highmem.c | 5 +----
arch/sparc/mm/highmem.c | 5 +----
4 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/microblaze/mm/highmem.c b/arch/microblaze/mm/highmem.c
index ee8a422b2b76..92e0890416c9 100644
--- a/arch/microblaze/mm/highmem.c
+++ b/arch/microblaze/mm/highmem.c
@@ -57,11 +57,8 @@ void kunmap_atomic_high(void *kvaddr)
int type;
unsigned int idx;
- if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- preempt_enable();
+ if (vaddr < __fix_to_virt(FIX_KMAP_END))
return;
- }
type = kmap_atomic_idx();
diff --git a/arch/mips/mm/highmem.c b/arch/mips/mm/highmem.c
index 37e244cdb14e..8e8726992720 100644
--- a/arch/mips/mm/highmem.c
+++ b/arch/mips/mm/highmem.c
@@ -41,11 +41,8 @@ void kunmap_atomic_high(void *kvaddr)
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
int type __maybe_unused;
- if (vaddr < FIXADDR_START) { // FIXME
- pagefault_enable();
- preempt_enable();
+ if (vaddr < FIXADDR_START)
return;
- }
type = kmap_atomic_idx();
#ifdef CONFIG_DEBUG_HIGHMEM
diff --git a/arch/powerpc/mm/highmem.c b/arch/powerpc/mm/highmem.c
index 35071c2913f1..624b4438aff9 100644
--- a/arch/powerpc/mm/highmem.c
+++ b/arch/powerpc/mm/highmem.c
@@ -44,11 +44,8 @@ void kunmap_atomic_high(void *kvaddr)
{
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
- if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- preempt_enable();
+ if (vaddr < __fix_to_virt(FIX_KMAP_END))
return;
- }
if (IS_ENABLED(CONFIG_DEBUG_HIGHMEM)) {
int type = kmap_atomic_idx();
diff --git a/arch/sparc/mm/highmem.c b/arch/sparc/mm/highmem.c
index d237d902f9c3..6ff6e2a9f9b3 100644
--- a/arch/sparc/mm/highmem.c
+++ b/arch/sparc/mm/highmem.c
@@ -86,11 +86,8 @@ void kunmap_atomic_high(void *kvaddr)
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
int type;
- if (vaddr < FIXADDR_START) { // FIXME
- pagefault_enable();
- preempt_enable();
+ if (vaddr < FIXADDR_START)
return;
- }
type = kmap_atomic_idx();
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Support ETMv4 power management
From: Bjorn Andersson @ 2020-05-18 18:51 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: devicetree, Mathieu Poirier, Suzuki K Poulose, linux-arm-msm,
coresight, linux-kernel, Rob Herring, Stephen Boyd, Andy Gross,
linux-arm-kernel, Mike Leach
In-Reply-To: <56a5563205da61c47eb4f8bbf6120e28@codeaurora.org>
On Fri 15 May 03:55 PDT 2020, Sai Prakash Ranjan wrote:
> Hi Bjorn,
>
Hi Sai,
> On 2020-05-15 16:21, Sai Prakash Ranjan wrote:
> > Now that deep idle states are properly supported on SC7180,
> > we need to add "coresight-loses-context-with-cpu" property
> > to avoid failure of trace session because of losing context
> > on entering deep idle states.
> >
> > Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> > ---
> >
> > Resending this because the last patch sent here -
> > https://lore.kernel.org/patchwork/patch/1230367/
> > seems to have added "coresight-loses-context-with-cpu" to
> > replicator node instead of etm7 node.
> >
> > ---
> > arch/arm64/boot/dts/qcom/sc7180.dtsi | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > index 4069bb1c93af..8b3707347547 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > @@ -1656,6 +1656,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1674,6 +1675,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1692,6 +1694,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1710,6 +1713,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1728,6 +1732,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1746,6 +1751,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1764,6 +1770,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
> > @@ -1782,6 +1789,7 @@
> >
> > clocks = <&aoss_qmp>;
> > clock-names = "apb_pclk";
> > + arm,coresight-loses-context-with-cpu;
> >
> > out-ports {
> > port {
>
>
> The previous version of this patch in QCOM tree seems to have added the
> property to replicator node instead of etm7 node, can you please drop
> that from the tree and apply this one?
>
I'm not able to replace the old commit without rewriting the history of
the branch. So I've applied a patch ontop of the branch to fix this up
instead.
Please review the branch and let me know if there's any issues.
Regards,
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_sdei: Put the SDEI table after using it
From: James Morse @ 2020-05-18 18:59 UTC (permalink / raw)
To: Hanjun Guo; +Cc: linux-arm-kernel
In-Reply-To: <1589021566-46373-1-git-send-email-guohanjun@huawei.com>
Hi Hanjun,
On 09/05/2020 11:52, Hanjun Guo wrote:
> The acpi_get_table() should be coupled with acpi_put_table() if
> the mapped table is not used for runtime after the initialization
> to release the table mapping, put the SDEI table after using it.
I thought this didn't really matter once ACPI had switched to its global mapping of the
tables...
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index 334c8be..5c42757 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -1113,6 +1113,7 @@ static bool __init sdei_present_acpi(void)
> if (ACPI_FAILURE(status))
> return false;
>
> + acpi_put_table(sdei_table_header);
> pdev = platform_device_register_simple(sdei_driver.driver.name, 0, NULL,
> 0);
> if (IS_ERR(pdev))
>
This conflicts with Sudeep's patch that moved all this code. I'll rebase and repost it.
Thanks!
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Support ETMv4 power management
From: Sai Prakash Ranjan @ 2020-05-18 19:08 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree, Mathieu Poirier, Suzuki K Poulose, linux-arm-msm,
coresight, linux-kernel, Rob Herring, Stephen Boyd, Andy Gross,
linux-arm-kernel, Mike Leach
In-Reply-To: <20200518185124.GG2165@builder.lan>
Hi Bjorn,
On 2020-05-19 00:21, Bjorn Andersson wrote:
> On Fri 15 May 03:55 PDT 2020, Sai Prakash Ranjan wrote:
[...]
>>
>>
>> The previous version of this patch in QCOM tree seems to have added
>> the
>> property to replicator node instead of etm7 node, can you please drop
>> that from the tree and apply this one?
>>
>
> I'm not able to replace the old commit without rewriting the history of
> the branch. So I've applied a patch ontop of the branch to fix this up
> instead.
>
> Please review the branch and let me know if there's any issues.
>
Thanks for the patch, I checked the branch and its good.
Sorry, I should have sent a patch on top of the old one
instead of repost.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: mchp-sgpio: Add pinctrl driver for Microsemi Serial GPIO
From: Lars Povlsen @ 2020-05-18 19:44 UTC (permalink / raw)
To: Randy Dunlap
Cc: devicetree, Alexandre Belloni, Linus Walleij, linux-kernel,
Microchip Linux Driver Support, linux-gpio, SoC Team,
linux-arm-kernel, Lars Povlsen
In-Reply-To: <fb104436-69c1-3f5a-85d9-af0aee35547f@infradead.org>
Randy Dunlap writes:
> On 5/13/20 7:11 AM, Lars Povlsen wrote:
>> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>> index 834c59950d1cf..2b0e9021fd7e0 100644
>> --- a/drivers/pinctrl/Kconfig
>> +++ b/drivers/pinctrl/Kconfig
>> @@ -396,6 +396,23 @@ config PINCTRL_OCELOT
>> select OF_GPIO
>> select REGMAP_MMIO
>>
>> +config PINCTRL_MSCC_SGPIO
>> + bool "Pinctrl driver for Microsemi Serial GPIO"
>> + depends on OF
>> + depends on HAS_IOMEM
>> + select GPIOLIB
>> + select GENERIC_PINCONF
>> + select GENERIC_PINCTRL_GROUPS
>> + select GENERIC_PINMUX_FUNCTIONS
>> + select OF_GPIO
>> + help
>> + Support for the VCoreIII SoC serial GPIO device. By using a
>
> Line above should be indented with one tab + 2 spaces...
> like the lines below.
>
Well spotted...
>> + serial interface, the SIO controller significantly extends
>> + the number of available GPIOs with a minimum number of
>> + additional pins on the device. The primary purpose of the
>> + SIO controller is to connect control signals from SFP
>> + modules and to act as an LED controller.
>> +
>
> thanks.
Thank you for your comments.
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Mike Rapoport @ 2020-05-18 19:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Doug Berger, Arnd Bergmann, sboyd, Kevin Cernekee, rmk+kernel,
Gregory Fong, linux-arm-kernel
In-Reply-To: <a7c86780-d65c-ab7b-ec3c-4029257cee7a@gmail.com>
On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
>
>
> On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> >
> >
> > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> >>>
> >>> ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of
> >>> system memory can be located deep in the 36-bit address space. Allow
> >>> FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains
> >>> the default.
> >>>
> >>> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
> >>> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
> >>> commit message text above. As Arnd pointed out at [2] there doesn't
> >>> seem to be any reason to tie this specifically to ARMv7, so this has
> >>> been changed to apply to all multiplatform kernels.
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
> >>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
> >>>
> >>> Cc: Kevin Cernekee <cernekee@gmail.com>
> >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >>> ---
> >>> arch/arm/Kconfig | 5 +++++
> >>> 1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>> index 5986277296c3..7bb5264a9c3a 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -312,6 +312,8 @@ choice
> >>> config ARCH_MULTIPLATFORM
> >>> bool "Allow multiple platforms to be selected"
> >>> depends on MMU
> >>> + select ARCH_FLATMEM_ENABLE
> >>> + select ARCH_SPARSEMEM_ENABLE
> >>
> >> The logic in mm/Kconfig is quite convoluted, so selecting
> >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> >>
> >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> >> something like:
> >
> > Yes indeed, thanks that does allow me to select between flatmem and
> > sparsemem from menuconfig correctly now.
>
> Mike, do you want to make a formal submission to Russell's patch
> tracker? If so, feel free to add:
I actually hoped to hear from people what do they think about switching
over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
it would make sense.
Russel, Arnd, can you comment please?
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Thanks!
> --
> Florian
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] mm/memory-failure: Add memory_failure_queue_kick()
From: Andrew Morton @ 2020-05-18 19:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mark Rutland, Tony Luck, linux-acpi, Catalin Marinas, Xie XiuQi,
linux-mm, Tyler Baicar, James Morse, Borislav Petkov,
Naoya Horiguchi, Will Deacon, linux-arm-kernel, Len Brown
In-Reply-To: <49686237.p6yG9EJavU@kreacher>
On Mon, 18 May 2020 14:45:05 +0200 "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> On Friday, May 1, 2020 6:45:41 PM CEST James Morse wrote:
> > The GHES code calls memory_failure_queue() from IRQ context to schedule
> > work on the current CPU so that memory_failure() can sleep.
> >
> > For synchronous memory errors the arch code needs to know any signals
> > that memory_failure() will trigger are pending before it returns to
> > user-space, possibly when exiting from the IRQ.
> >
> > Add a helper to kick the memory failure queue, to ensure the scheduled
> > work has happened. This has to be called from process context, so may
> > have been migrated from the original cpu. Pass the cpu the work was
> > queued on.
> >
> > Change memory_failure_work_func() to permit being called on the 'wrong'
> > cpu.
> >
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -3012,6 +3012,7 @@ enum mf_flags {
> > };
> > extern int memory_failure(unsigned long pfn, int flags);
> > extern void memory_failure_queue(unsigned long pfn, int flags);
> > +extern void memory_failure_queue_kick(int cpu);
> > extern int unpoison_memory(unsigned long pfn);
> > extern int get_hwpoison_page(struct page *page);
> > #define put_hwpoison_page(page) put_page(page)
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index a96364be8ab4..c4afb407bf0f 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1493,7 +1493,7 @@ static void memory_failure_work_func(struct work_struct *work)
> > unsigned long proc_flags;
> > int gotten;
> >
> > - mf_cpu = this_cpu_ptr(&memory_failure_cpu);
> > + mf_cpu = container_of(work, struct memory_failure_cpu, work);
> > for (;;) {
> > spin_lock_irqsave(&mf_cpu->lock, proc_flags);
> > gotten = kfifo_get(&mf_cpu->fifo, &entry);
> > @@ -1507,6 +1507,19 @@ static void memory_failure_work_func(struct work_struct *work)
> > }
> > }
> >
> > +/*
> > + * Process memory_failure work queued on the specified CPU.
> > + * Used to avoid return-to-userspace racing with the memory_failure workqueue.
> > + */
> > +void memory_failure_queue_kick(int cpu)
> > +{
> > + struct memory_failure_cpu *mf_cpu;
> > +
> > + mf_cpu = &per_cpu(memory_failure_cpu, cpu);
> > + cancel_work_sync(&mf_cpu->work);
> > + memory_failure_work_func(&mf_cpu->work);
> > +}
> > +
> > static int __init memory_failure_init(void)
> > {
> > struct memory_failure_cpu *mf_cpu;
> >
>
> I could apply this provided an ACK from the mm people.
>
Naoya Horiguchi is the memory-failure.c person. A review would be
appreciated please?
I'm struggling with it a bit. memory_failure_queue_kick() should be
called on the cpu which is identified by arg `cpu', yes?
memory_failure_work_func() appears to assume this.
If that's right then a) why bother passing in the `cpu' arg? and b)
what keeps this thread pinned to that CPU? cancel_work_sync() can
schedule.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
From: Prakhar Srivastava @ 2020-05-18 20:16 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, kstewart, gregkh, benh, bhsharma, tao.li, zohar,
paulus, vincenzo.frascino, will, nramas, frowand.list, masahiroy,
jmorris, takahiro.akashi, linux-arm-kernel, catalin.marinas,
serge, devicetree, pasha.tatashin, hsinyi, tusharsu, tglx,
allison, christophe.leroy, mbrugger, balajib, dmitry.kasatkin,
linux-kernel, linux-security-module, james.morse, mpe,
linux-integrity, linuxppc-dev
In-Reply-To: <20200512230509.GA2654@bogus>
On 5/12/20 4:05 PM, Rob Herring wrote:
> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:
>> Hi Mark,
>
> Please don't top post.
>
>> This patch set currently only address the Pure DT implementation.
>> EFI and ACPI implementations will be posted in subsequent patchsets.
>>
>> The logs are intended to be carried over the kexec and once read the
>> logs are no longer needed and in prior conversation with James(
>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/)
>> the apporach of using a chosen node doesn't
>> support the case.
>>
>> The DT entries make the reservation permanent and thus doesnt need kernel
>> segments to be used for this, however using a chosen-node with
>> reserved memory only changes the node information but memory still is
>> reserved via reserved-memory section.
>
> I think Mark's point was whether it needs to be permanent. We don't
> hardcode the initrd address for example.
>
Thankyou for clarifying my misunderstanding, i am modelling this keeping
to the TPM log implementation that uses a reserved memory. I will rev up
the version with chosen-node support.
That will make the memory reservation free after use.
>> On 5/5/20 2:59 AM, Mark Rutland wrote:
>>> Hi Prakhar,
>>>
>>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote:
>>>> IMA during kexec(kexec file load) verifies the kernel signature and measures
>
> What's IMAIMA is a LSM attempting to detect if files have been accidentally or
maliciously altered, both remotely and locally, it can also be used
to appraise a file's measurement against a "good" value stored as an
extended attribute, and enforce local file integrity.
IMA also validates and measures the signers of the kernel and initrd
during kexec. The measurements are extended to PCR 10(configurable) and
the logs stored in memory, however once kexec'd the logs are lost. Kexec
is used as secondary boot loader in may use cases and loosing the signer
creates a security hole.
This patch is an implementation to carry over the logs and making it
possible to remotely validate the signers of the kernel and initrd. Such
a support exits only in powerpc.
This patch makes the carry over of logs architecture independent and
puts the complexity in a driver.
Thanks,
Prakhar
>
>>>> the signature of the kernel. The signature in the logs can be used to verfiy the
>>>> authenticity of the kernel. The logs don not get carried over kexec and thus
>>>> remote attesation cannot verify the signature of the running kernel.
>>>>
>>>> Introduce an ABI to carry forward the ima logs over kexec.
>>>> Memory reserved via device tree reservation can be used to store and read
>>>> via the of_* functions.
>>>
>>> This flow needs to work for:
>>>
>>> 1) Pure DT
>>> 2) DT + EFI memory map
>>> 3) ACPI + EFI memory map
>>>
>>> ... and if this is just for transiently passing the log, I don't think
>>> that a reserved memory region is the right thing to use, since they're
>>> supposed to be more permanent.
>>>
>>> This sounds analogous to passing the initrd, and should probably use
>>> properties under the chosen node (which can be used for all three boot
>>> flows above).
>>>
>>> For reference, how big is the IMA log likely to be? Does it need
>>> physically contiguous space?
>>
>> It purely depends on the policy used and the modules/files that are accessed
>> for my local testing over a kexec session the log in
>> about 30KB.
>>
>> Current implementation expects enough contiguous memory to allocated to
>> carry forward the logs. If the log size exceeds the reserved memory the
>> call will fail.
>>
>> Thanks,
>> Prakhar Srivastava
>>>
>>> Thanks,
>>> Mark.
>>>
>>>>
>>>> Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting
>>>> address, followed by the IMA log contents.
>>>>
>>>> Tested on:
>>>> arm64 with Uboot
>>>>
>>>> Prakhar Srivastava (2):
>>>> Add a layer of abstraction to use the memory reserved by device tree
>>>> for ima buffer pass.
>>>> Add support for ima buffer pass using reserved memory for arm64 kexec.
>>>> Update the arch sepcific code path in kexec file load to store the
>>>> ima buffer in the reserved memory. The same reserved memory is read
>>>> on kexec or cold boot.
>>>>
>>>> arch/arm64/Kconfig | 1 +
>>>> arch/arm64/include/asm/ima.h | 22 ++++
>>>> arch/arm64/include/asm/kexec.h | 5 +
>>>> arch/arm64/kernel/Makefile | 1 +
>>>> arch/arm64/kernel/ima_kexec.c | 64 ++++++++++
>>>> arch/arm64/kernel/machine_kexec_file.c | 1 +
>>>> arch/powerpc/include/asm/ima.h | 3 +-
>>>> arch/powerpc/kexec/ima.c | 14 ++-
>>>> drivers/of/Kconfig | 6 +
>>>> drivers/of/Makefile | 1 +
>>>> drivers/of/of_ima.c | 165 +++++++++++++++++++++++++
>>>> include/linux/of.h | 34 +++++
>>>> security/integrity/ima/ima_kexec.c | 15 ++-
>>>> 13 files changed, 325 insertions(+), 7 deletions(-)
>>>> create mode 100644 arch/arm64/include/asm/ima.h
>>>> create mode 100644 arch/arm64/kernel/ima_kexec.c
>>>> create mode 100644 drivers/of/of_ima.c
>>>>
>>>> --
>>>> 2.25.1
>>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 5/6] clocksource: Add Low Power STM32 timers driver
From: Daniel Lezcano @ 2020-05-18 20:18 UTC (permalink / raw)
To: Benjamin Gaignard, fabrice.gasnier, lee.jones, robh+dt,
mark.rutland, mcoquelin.stm32, alexandre.torgue, tglx
Cc: devicetree, linux-kernel, Pascal Paillet, Benjamin Gaignard,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200420121620.2099-6-benjamin.gaignard@st.com>
On 20/04/2020 14:16, Benjamin Gaignard wrote:
> From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>
> Implement clock event driver using low power STM32 timers.
> Low power timer counters running even when CPUs are stopped.
> It could be used as clock event broadcaster to wake up CPUs but not like
> a clocksource because each it rise an interrupt the counter restart from 0.
>
> Low power timers have a 16 bits counter and a prescaler which allow to
> divide the clock per power of 2 to up 128 to target a 32KHz rate.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Signed-off-by: Pascal Paillet <p.paillet@st.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC][PATCH 1/2] Add a layer of abstraction to use the memory reserved by device tree for ima buffer pass.
From: Prakhar Srivastava @ 2020-05-18 20:34 UTC (permalink / raw)
To: Rob Herring
Cc: kstewart, mark.rutland, gregkh, benh, bhsharma, tao.li, zohar,
paulus, vincenzo.frascino, will, nramas, frowand.list, masahiroy,
jmorris, takahiro.akashi, linux-arm-kernel, catalin.marinas,
serge, devicetree, pasha.tatashin, hsinyi, tusharsu, tglx,
allison, christophe.leroy, mbrugger, balajib, dmitry.kasatkin,
linux-kernel, linux-security-module, james.morse, mpe,
linux-integrity, linuxppc-dev
In-Reply-To: <20200512230954.GB2654@bogus>
On 5/12/20 4:09 PM, Rob Herring wrote:
> On Mon, May 04, 2020 at 01:38:28PM -0700, Prakhar Srivastava wrote:
>> Introduce a device tree layer for to read and store ima buffer
>> from the reserved memory section of a device tree.
>
> But why do I need 'a layer of abstraction'? I don't like them.
>
This is a common path for the all architectures to carry over the
IMA measurement logs. A single layer will avoid any code duplication.
>> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>> ---
>> drivers/of/Kconfig | 6 ++
>> drivers/of/Makefile | 1 +
>> drivers/of/of_ima.c | 165 ++++++++++++++++++++++++++++++++++++++++++++
>
> Who are the users of this code and why does it need to be here? Most
> code for specific bindings are not in drivers/of/ but with the user. It
> doesn't sound like there's more than 1 user.
>
Currently the path is exercised by arm64 kexec_file_load path. A slight
restructuring is needed on the powerpc side to use the same code path
and other architectures can follow to add carrying over IMA logs over
kexec with just a few function calls.
I have attempted to bring the code path down to the highest common
layer, however please do suggest if i can move this some where else.
Thanks,
Prakhar
>> include/linux/of.h | 34 +++++++++
>> 4 files changed, 206 insertions(+)
>> create mode 100644 drivers/of/of_ima.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] docs/devicetree/i2c: brcm, bcm2835: fix node id in example
From: Rob Herring @ 2020-05-18 20:43 UTC (permalink / raw)
To: l4stpr0gr4m
Cc: linux-arm-kernel, devicetree, trivial, linux-kernel, linux-i2c,
nsaenzjulienne, linux-rpi-kernel
In-Reply-To: <1589140701-7516-1-git-send-email-l4stpr0gr4m@gmail.com>
On Mon, 11 May 2020 04:58:21 +0900, wrote:
> From: Kangmin Park <l4stpr0gr4m@gmail.com>
>
> This is a trivial patch to fix node id to match the reg in example.
>
> Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com>
> ---
> Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc, ocelot-sgpio
From: Lars Povlsen @ 2020-05-18 20:49 UTC (permalink / raw)
To: Linus Walleij
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Rob Herring, Linux ARM, Lars Povlsen
In-Reply-To: <CACRpkdZa7OM3bqB+zRprEQ3M4m9hG3uPCoYxrdH_O=oxD8zi8Q@mail.gmail.com>
Linus Walleij writes:
> On Wed, May 13, 2020 at 4:11 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
>> This adds DT bindings for the Microsemi SGPIO controller, bindings
>> mscc,ocelot-sgpio and mscc,luton-sgpio.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>
>> + microchip,sgpio-ports:
>> + description: This is a 32-bit bitmask, configuring whether a
>> + particular port in the controller is enabled or not. This allows
>> + unused ports to be removed from the bitstream and reduce latency.
>> + $ref: "/schemas/types.yaml#/definitions/uint32"
>
> I don't know about this.
>
> You are saying this pin controller can have up to 32 GPIO "ports"
> (also known as banks).
>
> Why can't you just represent each such port as a separate GPIO
> node:
>
> pinctrl@nnn {
> gpio@0 {
> ....
> };
> gpio@1 {
> ....
> };
> ....
> gpio@31 {
> ....
> };
> };
>
> Then if some of them are unused just set it to status = "disabled";
>
> This also makes your Linux driver simpler because each GPIO port
> just becomes a set of 32bit registers and you can use
> select GPIO_GENERIC and bgpio_init() and save a whole
> slew of standard stock code.
>
Linus, thank you for your input.
The controller handles an array of 32*n signals, where n >= 1 && n <=
4.
The problem with the above approach is that the ports are disabled
*port*-wise - so they remove all (upto) 4 bits. That would be across the
banks.
You could of course have the "implied" semantics that a disabled port at
any bit position disabled all (bit positions for the same port).
But I don't know if this would be easier to understand, DT-wise.
What do you think...?
> Yours,
> Linus Walleij
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Rob Herring @ 2020-05-18 21:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, geert+renesas, xuwei5, kernel, Ricardo Cañuelo,
linux-arm-kernel
In-Reply-To: <20200514152239.GG5955@pendragon.ideasonboard.com>
On Thu, May 14, 2020 at 06:22:39PM +0300, Laurent Pinchart wrote:
> Hi Ricardo,
>
> On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> > Hi Laurent, thanks for the thorough review. Some comments below:
> >
> > On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > > +description: |
> > > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > > + interface.
> > >
> > > I would write the last sentence as "The transmitter input is parallel
> > > RGB or YUV data." as YUV is also supported.
> >
> > Ok.
> >
> > > > + adi,input-colorspace:
> > > > + description: Input color space.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/string
> > > > + - enum: [ rgb, yuv422, yuv444 ]
> > >
> > > Isn't string implied ? Can't you write
> > >
> > > adi,input-colorspace:
> > > description: Input color space.
> > > enum: [ rgb, yuv422, yuv444 ]
> >
> > example-schema.yaml says that
> >
> > Vendor specific properties have slightly different schema
> > requirements than common properties. They must have at least a type
> > definition and 'description'.
> >
> > However, dt_binding_check doesn't seem to enforce this rule for string
> > properties, and I saw a couple of vendor-specific string properties in
> > other bindings that don't define the type either, so I'm going to follow
> > your suggestion but only for string properties, the rest need a type
> > definition.
>
> I'll defer to Rob to tell the law here :-)
Yes, if you have a string with defined values, then a type isn't needed.
That only applies to strings as numeric values need a size.
>
> > I noticed I can remove the "allOf" keywords from these too.
Yes, that's a recent change. Both forms still work.
> > > > + adi,embedded-sync:
> > > > + description:
> > > > + The input uses synchronization signals embedded in the data
> > > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > > + synchronization signals).
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [ 0, 1 ]
> > > > + - default: 0
> > >
> > > This be a boolean property (it is read as a bool by the driver, the
> > > property being absent means false, the property being present means
> > > true).
> >
> > You're completely right.
> >
> > > > + ports:
> > > > + description:
> > > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > > + models their connections as documented in
> > > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > > + Documentation/devicetree/bindings/graph.txt
> > > > + type: object
> > > > + properties:
> > > > + port@0:
> > > > + description: Video port for the RGB, YUV or DSI input.
> > >
> > > s/RGB, YUV or DSI/RGB or YUV/
> >
> > Ok.
> >
> > > > +if:
> > > > + not:
> > > > + properties:
> > > > + adi,input-colorspace:
> > > > + contains:
> > > > + enum: [ rgb, yuv444 ]
> > > > + adi,input-clock:
> > > > + contains:
> > > > + const: 1x
> > >
> > > As both properties take a single value, I think you can omit
> > > "contains:".
> >
> > I think it's required here, removing it makes the test fail.
>
> I thought the following could work:
>
> if:
> not:
> properties:
> adi,input-colorspace:
> enum: [ rgb, yuv444 ]
> adi,input-clock:
> items:
> - const: 1x
>
> But no big deal, contains: is ok too.
In theory the above should work. However, this is probably a case where
we don't fix-up the properties. If you look at the DT yaml encoding,
everything is an array (as dtc doesn't know). For schemas, the tooling
expands scalars to arrays.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: at91: DT for 5.8
From: Alexandre Belloni @ 2020-05-18 21:28 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm, soc
Cc: Ludovic Desroches, linux-arm-kernel, linux-kernel
Arnd, Olof,
Despite a new evaluation board being added this cycle, the move of the
flexcom nodes to the sama5d2 dtsi and the switch to the new PMC bindings
result in the deletion of about 100 lines.
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-5.8-dt
for you to fetch changes up to 88d801aec6e971c15a0bfb4d46d02476dde9e8aa:
ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPs (2020-05-18 16:51:58 +0200)
----------------------------------------------------------------
AT91 DT for 5.8
- New board: Microchip SAMA5D2 Industrial Connectivity Platform
- All SoCs are now converted to the new PMC device tree binding
- sama5d2 flexcom nodes are now fully described in sama5d2.dtsi
----------------------------------------------------------------
Alexandre Belloni (4):
ARM: dts: at91: sama5d3: switch to new clock bindings
ARM: dts: at91: at91sam9n12: switch to new clock bindings
ARM: dts: at91: at91sam9g45: switch to new clock bindings
ARM: dts: at91: rm9200: switch to new clock bindings
Claudiu Beznea (1):
ARM: dts: at91: sama5d27_som1: Add SPI NOR flash mapping
Codrin Ciubotariu (2):
dt-bindings: ARM: Document SAMA5D2-ICP
ARM: dts: at91: Configure I2C SCL gpio as open drain
Cristian Birsan (1):
ARM: dts: at91: sama5d2-icp: add SAMA5D2-ICP
Cyrille Pitchen (1):
ARM: dts: at91: sama5d2_xplained: Add QSPI0 + SPI NOR memory nodes
Ludovic Desroches (6):
ARM: dts: at91: sama5d2_ptc_ek: fix sdmmc0 node description
ARM: dts: at91: sama5d2_ptc_ek: fix vbus pin
ARM: dts: at91: sama5d2_ptc_ek: add PB_USER as wakeup source
ARM: dts: at91: sama5d27_som1_ek: enable i2c0
ARM: dts: at91: sama5d27_som1_ek: add an alias for i2c0
ARM: dts: at91: at91-sama5d27_som1: Enable eeprom device
Tudor Ambarus (20):
ARM: dts: at91: sam9x60ek: Use quad mode in the spi-nor flash
ARM: dts: at91: sam9x60ek: Add sdmmc1 node
ARM: dts: at91: sama5d27_wlsom1: Add alias for i2c0
ARM: dts: at91: sama5d2: Fix the label numbering for flexcom functions
ARM: dts: at91: sama5d2: Move flx4 definitions in the SoC dtsi
ARM: dts: at91: sama5d2: Move flx3 definitions in the SoC dtsi
ARM: dts: at91: sama5d2: Move flx2 definitions in the SoC dtsi
ARM: dts: at91: sama5d2: Move flx1 definitions in the SoC dtsi
ARM: dts: at91: sama5d2: Move flx0 definitions in the SoC dtsi
ARM: dts: at91: sama5d2: Specify the FIFO size for the Flexcom UART
ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and UART flx4 functions
ARM: dts: at91: sama5d2: Add DMA bindings for the flx3 SPI function
ARM: dts: at91: sama5d2: Add DMA bindings for the flx1 I2C function
ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and I2C flx0 functions
ARM: dts: at91: sama5d2: Remove i2s and tcb aliases from SoC dtsi
ARM: dts: at91: sama5d2: Add missing flexcom definitions
ARM: dts: at91: sama5d2_xplained: Add alias for DBGU
ARM: dts: at91: sama5d2_ptc_ek: Add comments to describe the aliases
ARM: dts: at91: sama5d2_xplained: Describe the flx0 I2C function
ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPs
.../devicetree/bindings/arm/atmel-at91.yaml | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-dvk_su60_somc.dtsi | 2 +-
arch/arm/boot/dts/at91-kizbox3-hs.dts | 4 +-
arch/arm/boot/dts/at91-kizbox3_common.dtsi | 48 +-
arch/arm/boot/dts/at91-sam9x60ek.dts | 23 +
arch/arm/boot/dts/at91-sama5d27_som1.dtsi | 54 ++
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 64 +-
arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi | 16 +-
arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts | 12 -
arch/arm/boot/dts/at91-sama5d2_icp.dts | 767 +++++++++++++++++++++
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 25 +-
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 118 +++-
arch/arm/boot/dts/at91-wb50n.dtsi | 4 -
arch/arm/boot/dts/at91rm9200.dtsi | 296 +-------
arch/arm/boot/dts/at91sam9g45.dtsi | 338 +--------
arch/arm/boot/dts/at91sam9m10g45ek.dts | 4 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 324 +--------
arch/arm/boot/dts/at91sam9n12ek.dts | 2 +-
arch/arm/boot/dts/sama5d2.dtsi | 295 +++++++-
arch/arm/boot/dts/sama5d3.dtsi | 430 ++----------
arch/arm/boot/dts/sama5d3_can.dtsi | 20 +-
arch/arm/boot/dts/sama5d3_emac.dtsi | 8 +-
arch/arm/boot/dts/sama5d3_gmac.dtsi | 11 +-
arch/arm/boot/dts/sama5d3_lcd.dtsi | 19 +-
arch/arm/boot/dts/sama5d3_mci2.dtsi | 11 +-
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 12 +-
arch/arm/boot/dts/sama5d3_uart.dtsi | 20 +-
arch/arm/boot/dts/sama5d3xmb.dtsi | 6 +-
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 6 +-
arch/arm/boot/dts/sama5d4.dtsi | 6 +-
31 files changed, 1429 insertions(+), 1524 deletions(-)
create mode 100644 arch/arm/boot/dts/at91-sama5d2_icp.dts
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: at91: defconfig for 5.8
From: Alexandre Belloni @ 2020-05-18 21:32 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm, soc
Cc: Ludovic Desroches, linux-arm-kernel, linux-kernel
Arnd, Olof,
Very little is added to the sama5_defconfig: support for the gpios from
the security module and a pmic for the SAMA5D27 WLSOM1.
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-5.8-defconfig
for you to fetch changes up to 6a2ab88ca789804cad89d558625147edd26a1d37:
ARM: configs: at91: sama5: enable MCP16502 regulator (2020-04-13 13:00:16 +0200)
----------------------------------------------------------------
AT91 defconfig for 5.8
- Add PIOBU and MCP16502 regulator to sama5 defconfig
----------------------------------------------------------------
Razvan Stefanescu (2):
ARM: configs: at91: sama5: enable SAMA5D2_PIOBU
ARM: configs: at91: sama5: enable MCP16502 regulator
arch/arm/configs/sama5_defconfig | 2 ++
1 file changed, 2 insertions(+)
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: defconfig: enable Qualcomm IPA and RMNet modules
From: Alex Elder @ 2020-05-18 21:54 UTC (permalink / raw)
To: bjorn.andersson, agross
Cc: catalin.marinas, linux-kernel, evgreen, cpratapa, subashab, will,
linux-arm-kernel
Enable building the Qualcomm IPA driver as a kernel module. To be
useful, the IPA driver also requires RMNet, so enable building that
as a module as well.
Signed-off-by: Alex Elder <elder@linaro.org>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 9c6500b71bc6..56261fd7ea8d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -306,6 +306,7 @@ CONFIG_MLX4_EN=m
CONFIG_MLX5_CORE=m
CONFIG_MLX5_CORE_EN=y
CONFIG_QCOM_EMAC=m
+CONFIG_RMNET=m
CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
@@ -313,6 +314,7 @@ CONFIG_SNI_AVE=y
CONFIG_SNI_NETSEC=y
CONFIG_STMMAC_ETH=m
CONFIG_TI_K3_AM65_CPSW_NUSS=y
+CONFIG_QCOM_IPA=m
CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MDIO_BUS_MUX_MULTIPLEXER=y
CONFIG_AQUANTIA_PHY=y
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper
From: Gustavo A. R. Silva @ 2020-05-18 22:19 UTC (permalink / raw)
To: Qiang Zhao, Li Yang
Cc: Kees Cook, linuxppc-dev, linux-kernel, linux-arm-kernel,
Gustavo A. R. Silva
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.
Also, make use of the new struct_size() helper to properly calculate the
size of struct qe_firmware.
This issue was found with the help of Coccinelle and, audited and fixed
_manually_.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/soc/fsl/qe/qe.c | 4 ++--
include/soc/fsl/qe/qe.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 447146861c2c1..2df20d6f85fa4 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -448,7 +448,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
unsigned int i;
unsigned int j;
u32 crc;
- size_t calc_size = sizeof(struct qe_firmware);
+ size_t calc_size;
size_t length;
const struct qe_header *hdr;
@@ -480,7 +480,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
}
/* Validate the length and check if there's a CRC */
- calc_size += (firmware->count - 1) * sizeof(struct qe_microcode);
+ calc_size = struct_size(firmware, microcode, firmware->count);
for (i = 0; i < firmware->count; i++)
/*
diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
index e282ac01ec081..3feddfec9f87d 100644
--- a/include/soc/fsl/qe/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -307,7 +307,7 @@ struct qe_firmware {
u8 revision; /* The microcode version revision */
u8 padding; /* Reserved, for alignment */
u8 reserved[4]; /* Reserved, for future expansion */
- } __attribute__ ((packed)) microcode[1];
+ } __packed microcode[];
/* All microcode binaries should be located here */
/* CRC32 should be located here, after the microcode binaries */
} __attribute__ ((packed));
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox