* [RFC PATCH 09/10] arm64/sve: Enable default vector length control via procfs
From: Dave Martin @ 2017-01-12 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com>
This patch makes the default SVE vector length at exec() for user tasks
controllable via procfs, in /proc/cpu/sve_default_vector_length.
Limited effort is made to return sensible errors when writing the
procfs file, and anyway the value gets silently clamped to the
maximum VL supported by the platform: users should close and reopen
the file and read back to see the result.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
Caveats:
* /proc may not be the correct place for this (but it's not clear
where in sysfs it should go either, and it's a global control with
no corresponding kobject)
* There seems to be no suitable framework for writable controls of
this sort in /proc (unlike debugfs or sysfs). So, I had to write a
suspiciously large amount of code -- I may have missed an obvious
trick :P
arch/arm64/kernel/fpsimd.c | 160 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 158 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index f010a1c..3c0e08c 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -22,8 +22,12 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/prctl.h>
+#include <linux/proc_fs.h>
#include <linux/sched.h>
+#include <linux/seq_file.h>
#include <linux/signal.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
#include <linux/hardirq.h>
#include <asm/fpsimd.h>
@@ -102,9 +106,132 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
/* Maximum supported vector length across all CPUs (initially poisoned) */
int sve_max_vl = -1;
+/* Default VL for tasks that don't set it explicitly: */
+int sve_default_vl = -1;
#ifdef CONFIG_ARM64_SVE
+#ifdef CONFIG_PROC_FS
+
+struct default_vl_write_state {
+ bool invalid;
+ size_t len;
+ char buf[40]; /* enough for "0x" + 64-bit hex integer + NUL */
+};
+
+static int sve_default_vl_show(struct seq_file *s, void *data)
+{
+ seq_printf(s, "%d\n", sve_default_vl);
+ return 0;
+}
+
+static ssize_t sve_default_vl_write(struct file *f, const char __user *buf,
+ size_t size, loff_t *pos)
+{
+ struct default_vl_write_state *state =
+ ((struct seq_file *)f->private_data)->private;
+ long ret;
+
+ if (!size)
+ return 0;
+
+ if (*pos > sizeof(state->buf) ||
+ size >= sizeof(state->buf) - *pos) {
+ ret = -ENOSPC;
+ goto error;
+ }
+
+ ret = copy_from_user(state->buf + *pos, buf, size);
+ if (ret > 0)
+ ret = -EINVAL;
+ if (ret)
+ goto error;
+
+ *pos += size;
+ if (*pos > state->len)
+ state->len = *pos;
+
+ return size;
+
+error:
+ state->invalid = true;
+ return ret;
+}
+
+static int sve_default_vl_release(struct inode *i, struct file *f)
+{
+ int ret = 0;
+ int t;
+ unsigned long value;
+ struct default_vl_write_state *state =
+ ((struct seq_file *)f->private_data)->private;
+
+ if (!(f->f_mode & FMODE_WRITE))
+ goto out;
+
+ if (state->invalid)
+ goto out;
+
+ if (state->len >= sizeof(state->buf)) {
+ WARN_ON(1);
+ state->len = sizeof(state->buf) - 1;
+ }
+
+ state->buf[state->len] = '\0';
+ t = kstrtoul(state->buf, 0, &value);
+ if (t)
+ ret = t;
+
+ if (!sve_vl_valid(value))
+ ret = -EINVAL;
+
+ if (!sve_vl_valid(sve_max_vl)) {
+ WARN_ON(1);
+ ret = -EINVAL;
+ }
+
+ if (value > sve_max_vl)
+ value = sve_max_vl;
+
+ if (!ret)
+ sve_default_vl = value;
+
+out:
+ t = seq_release_private(i, f);
+ return ret ? ret : t;
+}
+
+static int sve_default_vl_open(struct inode *i, struct file *f)
+{
+ struct default_vl_write_state *data = NULL;
+ int ret;
+
+ if (f->f_mode & FMODE_WRITE) {
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->invalid = false;
+ data->len = 0;
+ }
+
+ ret = single_open(f, sve_default_vl_show, data);
+ if (ret)
+ kfree(data);
+
+ return ret;
+}
+
+static const struct file_operations sve_default_vl_fops = {
+ .open = sve_default_vl_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = sve_default_vl_release,
+ .write = sve_default_vl_write,
+};
+
+#endif /* !CONFIG_PROC_FS */
+
static void task_fpsimd_to_sve(struct task_struct *task);
static void task_fpsimd_load(struct task_struct *task);
static void task_fpsimd_save(struct task_struct *task);
@@ -299,7 +426,7 @@ void fpsimd_flush_thread(void)
!(current->thread.sve_flags & THREAD_VL_INHERIT)) {
BUG_ON(!sve_vl_valid(sve_max_vl));
- current->thread.sve_vl = sve_max_vl;
+ current->thread.sve_vl = sve_default_vl;
current->thread.sve_flags = 0;
}
}
@@ -723,6 +850,14 @@ void __init fpsimd_init_task_struct_size(void)
& 0xf) == 1) {
/* FIXME: This should be the minimum across all CPUs */
sve_max_vl = sve_get_vl();
+ sve_default_vl = sve_max_vl;
+
+ /*
+ * To avoid enlarging the signal frame by default, clamp to
+ * 512 bits until/unless overridden by userspace:
+ */
+ if (sve_default_vl > 512 / 8)
+ sve_default_vl = 512 / 8;
arch_task_struct_size = sizeof(struct task_struct) +
35 * sve_max_vl;
@@ -734,6 +869,27 @@ void __init fpsimd_init_task_struct_size(void)
/*
* FP/SIMD support code initialisation.
*/
+static int __init sve_procfs_init(void)
+{
+#if defined(CONFIG_ARM64_SVE) && defined(CONFIG_PROC_FS)
+ struct proc_dir_entry *dir;
+
+ if (!(elf_hwcap & HWCAP_SVE))
+ return 0;
+
+ /* This should be moved elsewhere is anything else ever uses it: */
+ dir = proc_mkdir("cpu", NULL);
+ if (!dir)
+ return -ENOMEM;
+
+ if (!proc_create("sve_default_vector_length",
+ S_IRUGO | S_IWUSR, dir, &sve_default_vl_fops))
+ return -ENOMEM;
+#endif
+
+ return 0;
+}
+
static int __init fpsimd_init(void)
{
if (elf_hwcap & HWCAP_FP) {
@@ -749,6 +905,6 @@ static int __init fpsimd_init(void)
if (!(elf_hwcap & HWCAP_SVE))
pr_info("Scalable Vector Extension available\n");
- return 0;
+ return sve_procfs_init();
}
late_initcall(fpsimd_init);
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 10/10] Revert "arm64/sve: Limit vector length to 512 bits by default"
From: Dave Martin @ 2017-01-12 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com>
This reverts commit cdedb254ccddd9c6a8db91b3737690327e48dfe7.
Vector length limiting via Kconfig is no longer required now that
the default vector length can be manipulated at runtime via procfs.
---
arch/arm64/Kconfig | 35 -----------------------------------
arch/arm64/mm/proc.S | 5 -----
2 files changed, 40 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 98c0934..bced568 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -900,41 +900,6 @@ config ARM64_SVE
To enable use of this extension on CPUs that implement it, say Y.
-if ARM64_SVE
-
-config ARM64_SVE_FULL_VECTOR_LENGTH
- bool "Enable full hardware vector length for userspace"
- default n
- help
- SVE vector lengths greater than 512 bits impact the size of signal
- frames and therefore the size requirements for any userspace stack
- onto which a signal may be delivered. Using larger vector lengths
- may therefore cause problems for some software. For this reason, the
- kernel currently limits the maximum vector length for userspace
- software to 512 bits by default.
-
- Enabling this option removes the limit, so that the full vector
- length implemented by the hardware is made available to userspace.
-
- Be aware: in general, software that (a) does not use SVE (including
- via libraries), or (b) does not handle signals, or (c) uses default
- process/thread stack sizes and does not use sigaltstack(2) should be
- unaffected by enabling larger vectors. Software that does not meet
- these criteria or that relies on certain legacy uses of the ucontext
- API may be affected however.
-
- This is a transitional compatibility option only and will be replaced
- by a userspace ABI extension in the future. Do not assume that this
- option will be available with compatible effect in future Linux
- releases.
-
- If you are developing software that uses SVE and understand the
- implications, you can consider saying Y here.
-
- If unsure, say N.
-
-endif
-
config ARM64_MODULE_CMODEL_LARGE
bool
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index da2d602..aa96b4c 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -200,11 +200,6 @@ ENTRY(__cpu_setup)
mrs_s x5, ZIDR_EL1 // SVE: Enable full vector len
and x5, x5, #ZCR_EL1_LEN_MASK // initially
-#ifndef CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH
- mov x6, #(512 / 128 - 1) // Clamp VL to 512 bits
- cmp x5, x6
- csel x5, x5, x6, lo
-#endif
msr_s ZCR_EL1, x5
b 2f
--
2.1.4
^ permalink raw reply related
* [PATCH] rtc: armada38x: hide maybe-uninitialized warning
From: Alexandre Belloni @ 2017-01-12 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111145112.722743-1-arnd@arndb.de>
Hi Arnd,
On 11/01/2017 at 15:50:31 +0100, Arnd Bergmann wrote :
> The function is too complicated for gcc to realize that this variable
> does eventually get initialized, causing a harmless warning:
>
> drivers/rtc/rtc-armada38x.c: In function 'read_rtc_register_wa':
> drivers/rtc/rtc-armada38x.c:131:25: warning: 'index_max' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> This adds an explicit initializion at the start of the function.
> I generally try to avoid that, but it seems appropriate here,
> as we start out with max=0 as well.
>
> Fixes: 61cffa2438e3 ("rtc: armada38x: Follow the new recommendation for errata implementation")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Actually, I fixed that one directly in the commit yesterday as it has
been reported to me multiple times already.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Marc Zyngier @ 2017-01-12 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110160419.4cc3d61c9d652e5d5da13f15@arm.com>
On 10/01/17 22:04, Kim Phillips wrote:
> On Tue, 3 Jan 2017 18:10:26 +0000
> Will Deacon <will.deacon@arm.com> wrote:
>
>> +#define DRVNAME "arm_spe_pmu"
>
> Based on Intel naming "intel_pt" and "intel_bts', I had expected
> "arm-spe" as the universal basename for SPE. I don't really care about
> whether '_pmu' is included, but it's yet another naming inconsistency we
> have with coresight's "cs_etm" (the other being prefixed with "arm_").
>
> Also, nit, since I don't know why perf userspace tools can't handle
> dashes in PMU names (commit 3d1ff755e367 "arm: perf: clean up PMU
> names" doesn't say), can we at least start to use dashes in our
> filenames? arm-spe-pmu.c is easier to type than arm_spe_pmu.c.
Fortunately, not everyone is using a UK/US keyboard... ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] rtc: armada38x: avoid unused-function warning
From: Alexandre Belloni @ 2017-01-12 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112111321.3219446-1-arnd@arndb.de>
Hi,
On 12/01/2017 at 12:13:08 +0100, Arnd Bergmann wrote :
> When CONFIG_PM_SLEEP is not set, rtc_update_mbus_timing_params becomes
> unused, now that armada38x_rtc_probe() no longer calls
> rtc_update_mbus_timing_params on startup:
>
> drivers/rtc/rtc-armada38x.c:79:13: error: 'rtc_update_mbus_timing_params' defined but not used [-Werror=unused-function]
>
> This addresses the warning by marking the PM functions as __maybe_unused,
> so the unused functions get silently dropped. I could not tell from
> the changelog if dropping the call to armada38x_rtc_probe() was
> intended here, and if that is the correct thing to do without
> CONFIG_PM_SLEEP, so we might need a different fix that brings it back.
>
Thanks for the report, Russell's patch didn't apply cleanly and it seems
I messed up when applying. I've just restored the
rtc_update_mbus_timing_params() call in probe as this should be.
Thanks again and sorry about this.
> Fixes: 4c492eb022c2 ("rtc: armada38x: make struct rtc_class_ops const")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/rtc/rtc-armada38x.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
> index 4f75c619bbba..2e451acccd9c 100644
> --- a/drivers/rtc/rtc-armada38x.c
> +++ b/drivers/rtc/rtc-armada38x.c
> @@ -338,8 +338,7 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int armada38x_rtc_suspend(struct device *dev)
> +static int __maybe_unused armada38x_rtc_suspend(struct device *dev)
> {
> if (device_may_wakeup(dev)) {
> struct armada38x_rtc *rtc = dev_get_drvdata(dev);
> @@ -350,7 +349,7 @@ static int armada38x_rtc_suspend(struct device *dev)
> return 0;
> }
>
> -static int armada38x_rtc_resume(struct device *dev)
> +static int __maybe_unused armada38x_rtc_resume(struct device *dev)
> {
> if (device_may_wakeup(dev)) {
> struct armada38x_rtc *rtc = dev_get_drvdata(dev);
> @@ -363,7 +362,6 @@ static int armada38x_rtc_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static SIMPLE_DEV_PM_OPS(armada38x_rtc_pm_ops,
> armada38x_rtc_suspend, armada38x_rtc_resume);
> --
> 2.9.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 16/62] watchdog: digicolor_wdt: Convert to use device managed functions and other improvements
From: Baruch Siach @ 2017-01-12 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484091325-9199-17-git-send-email-linux@roeck-us.net>
Hi Guenter,
On Tue, Jan 10, 2017 at 03:34:33PM -0800, Guenter Roeck wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Replace 'goto l; ... l: return e;' with 'return e;'
> - Replace 'val = e; return val;' with 'return e;'
> - Drop assignments to otherwise unused variables
> - Replace 'if (e) { return expr; }' with 'if (e) return expr;'
> - Drop remove function
> - Replace of_iomap() with platform_get_resource() followed by
> devm_ioremap_resource()
> - Drop platform_set_drvdata()
> - Replace &pdev->dev with dev if 'struct device *dev' is a declared
> variable
> - Use devm_watchdog_register_driver() to register watchdog device
> - Replace shutdown function with call to watchdog_stop_on_reboot()
>
> Cc: Baruch Siach <baruch@tkos.co.il>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Arnd Bergmann @ 2017-01-12 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <80676b35-121b-0462-23fc-ed5608e1e671@grimberg.me>
On Thursday, January 12, 2017 12:09:11 PM CET Sagi Grimberg wrote:
> >> Another workaround me might need is to limit amount of concurrent DMA
> >> in the NVMe driver based on some platform quirk. The way that NVMe works,
> >> it can have very large amounts of data that is concurrently mapped into
> >> the device.
> >
> > That's not really just NVMe - other storage and network controllers also
> > can DMA map giant amounts of memory. There are a couple aspects to it:
> >
> > - dma coherent memoery - right now NVMe doesn't use too much of it,
> > but upcoming low-end NVMe controllers will soon start to require
> > fairl large amounts of it for the host memory buffer feature that
> > allows for DRAM-less controller designs. As an interesting quirk
> > that is memory only used by the PCIe devices, and never accessed
> > by the Linux host at all.
>
> Would it make sense to convert the nvme driver to use normal allocations
> and use the DMA streaming APIs (dma_sync_single_for_[cpu|device]) for
> both queues and future HMB?
That is an interesting question: We actually have the
"DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements
it in the coherent interface, so that might be a good fit.
Implementing it in the streaming API makes no sense since we
already have a kernel mapping here, but using a normal allocation
(possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC,
need to check) might help on other architectures that have
limited amounts of coherent memory and no CMA.
Another benefit of the coherent API for this kind of buffer is
that we can use CMA where available to get a large consecutive
chunk of RAM on architectures without an IOMMU when normal
memory is no longer available because of fragmentation.
Arnd
^ permalink raw reply
* [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()
From: Will Deacon @ 2017-01-12 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112042143.GF20972@linaro.org>
On Thu, Jan 12, 2017 at 01:21:44PM +0900, AKASHI Takahiro wrote:
> On Wed, Jan 11, 2017 at 10:54:05AM +0000, Will Deacon wrote:
> > On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote:
> > > On Tue, Jan 10, 2017 at 11:32:48AM +0000, Will Deacon wrote:
> > > > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote:
> > > > > @@ -22,6 +25,7 @@
> > > > > extern const unsigned char arm64_relocate_new_kernel[];
> > > > > extern const unsigned long arm64_relocate_new_kernel_size;
> > > > >
> > > > > +static bool in_crash_kexec;
> > > >
> > > > Do you actually need this bool? Why not call kexec_crash_loaded() instead?
> > >
> > > The two have different meanings:
> > > "in_crash_kexec" indicates that kdump is taking place, while
> > > kexec_crash_loaded() tells us only whether crash dump kernel has been
> > > loaded or not.
> > >
> > > It is crucial to distinguish them especially for machine_kexec()
> > > which can be called on normal kexec even if kdump has been set up.
> >
> > Ah, I see. So how about just doing:
> >
> > if (kimage == kexec_crash_image)
> >
> > in machine_kexec?
>
> Yeah, it should work.
> Do you want to merge the following hunk,
> or expect that I will re-send the whole patch series
> (with other changes if any)?
Thanks, I'll fold it in and shout if I run into any problems. My plan is
to queue this for 4.11.
Will
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-12 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2pW20VPP_yGtvJ_ufvj6Xj1poBiiA2WqkALiaLyyONug@mail.gmail.com>
Hello Cedric,
On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> >> > This is surprising. I didn't recheck the manual, but that looks very
> >> > uncomfortable.
> >>
> >> I agree but this exactly the hardware way of working described in the
> >> reference manual.
> >
> > IMHO that's a hw bug. This makes it for example impossible to implement
> > SMBus block transfers (I think).
>
> This is not correct.
> Setting STOP/START bit does not mean the the pulse will be sent right now.
> Here we have just to prepare the hardware for the 2 next pulse but the
> STOP/START/ACK pulse will be generated at the right time as required
> by I2C specification.
> So SMBus block transfer will be possible.
A block transfer consists of a byte that specifies the count of bytes
yet to come. So the device sends for example:
0x01 0xab
So when you read the 1 in the first byte it's already too late to set
STOP to get it after the 2nd byte.
Not sure I got all the required details right, though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: juno: Adds missing CoreSight STM component.
From: Sudeep Holla @ 2017-01-12 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0802MB2198449A31AD8624B48045428C790@DB6PR0802MB2198.eurprd08.prod.outlook.com>
On 12/01/17 11:24, Mike Leach wrote:
> Hi Sudeep,
>
> I'm fine with that - less duplication the better.
>
> I've not played with .dts files much to I hadn't realised that type
> of construction was possible.
>
OK I spent some time and I think we can do the same for other coresight
components too. I will modify post the series but I need your help to
validate the change running core-sight tests.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Marc Gonzalez @ 2017-01-12 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xlgugldws.fsf@unicorn.mansr.com>
On 12/01/2017 12:24, M?ns Rullg?rd wrote:
> Marc Gonzalez writes:
>
>>> So far we have a claim that a cast to a void * may somehow be different
>>> to a cast to a different pointer, if used as function argument, and that
>>> the behavior with such a cast may be undefined. In other words, you claim
>>> that a function implemented as, say,
>>>
>>> void func(int *var) {}
>>>
>>> might result in undefined behavior if some header file declares it as
>>>
>>> void func(void *);
>>>
>>> and it is called as
>>>
>>> int var;
>>>
>>> func(&var);
>>>
>>> That seems really far fetched to me.
>>
>> Thanks for giving me an opportunity to play the language lawyer :-)
>>
>> C99 6.3.2.3 sub-clause 8 states:
>>
>> "A pointer to a function of one type may be converted to a pointer to
>> a function of another type and back again; the result shall compare
>> equal to the original pointer. If a converted pointer is used to call
>> a function whose type is not compatible with the pointed-to type, the
>> behavior is undefined."
>>
>> So, the behavior is undefined, not when you cast clk_disable_unprepare,
>> but when clk_disable_unprepare is later called through the devres->action
>> function pointer.
>
> Only if the function types are incompatible. C99 6.7.5.3 subclause 15:
>
> For two function types to be compatible, both shall specify compatible
> return types. Moreover, the parameter type lists, if both are
> present, shall agree in the number of parameters and in use of the
> ellipsis terminator; corresponding parameters shall have compatible
> types.
>
> The question then is whether pointer to void and pointer to struct clk
> are compatible types.
6.2.7 Compatible type and composite type
sub-clause 1
"Two types have compatible type if their types are the same. Additional rules for
determining whether two types are compatible are described in 6.7.2 for type specifiers,
in 6.7.3 for type qualifiers, and in 6.7.5 for declarators."
6.7.5.1 Pointer declarators
sub-clause 2
"For two pointer types to be compatible, both shall be identically qualified and both shall
be pointers to compatible types."
I don't think void and struct clk are compatible types.
AFAIU, conversion and compatibility are two separate subjects.
Regards.
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Will Deacon @ 2017-01-12 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com>
On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> index 5ac373c..480b644 100644
> >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
> >>
> >> /* Objects are coherent, unless 'no shareability' flag set. */
> >> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
> >>
> >> /*
> >> * The device-specific probe callback will get invoked by device_add()
> >
> > Why are these actually calling arch_setup_dma_ops() here in the first
> > place? Are these all devices that are DMA masters without an OF node?
>
> I don't know, but that's a different topic. This patch just adds
> argument and sets it to false everywhere but in the location when range
> should be definitely enforced.
I also wouldn't lose any sleep over a staging driver.
Will
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Paolo Bonzini @ 2017-01-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-2-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> So we can have portable formatting of uint32_t types. However there is
> a catch. Different compilers can use legally subtly different types
> though so we need to probe the compiler defined intdef.h first.
Interesting, what platform has long uint32_t? I thought the issue was
whether 64-bit is long or "long long".
Paolo
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> Makefile | 1 +
> configure | 13 +++++++++++++
> lib/libcflat.h | 9 +++++++++
> 3 files changed, 23 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index a32333b..9822d9a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
> CFLAGS += $(fno_stack_protector)
> CFLAGS += $(fno_stack_protector_all)
> CFLAGS += $(wno_frame_address)
> +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>
> CXXFLAGS += $(CFLAGS)
>
> diff --git a/configure b/configure
> index 995c8fa..127868c 100755
> --- a/configure
> +++ b/configure
> @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
> ln -fs $testdir/run $testdir-run
> fi
>
> +# check if uint32_t needs a long format modifier
> +cat << EOF > lib_test.c
> +#include <inttypes.h>
> +EOF
> +
> +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
> +exit=$?
> +if [ $exit -eq 0 ]; then
> + u32_long=true
> +fi
> +rm -f lib_test.c
> +
> # check for dependent 32 bit libraries
> if [ "$arch" != "arm" ]; then
> cat << EOF > lib_test.c
> @@ -155,4 +167,5 @@ TEST_DIR=$testdir
> FIRMWARE=$firmware
> ENDIAN=$endian
> PRETTY_PRINT_STACKS=$pretty_print_stacks
> +U32_LONG_FMT=$u32_long
> EOF
> diff --git a/lib/libcflat.h b/lib/libcflat.h
> index 380395f..e80fc50 100644
> --- a/lib/libcflat.h
> +++ b/lib/libcflat.h
> @@ -58,12 +58,21 @@ typedef _Bool bool;
> #define true 1
>
> #if __SIZEOF_LONG__ == 8
> +# define __PRI32_PREFIX
> # define __PRI64_PREFIX "l"
> # define __PRIPTR_PREFIX "l"
> #else
> +#if defined(__U32_LONG_FMT__)
> +# define __PRI32_PREFIX "l"
> +#else
> +# define __PRI32_PREFIX
> +#endif
> # define __PRI64_PREFIX "ll"
> # define __PRIPTR_PREFIX
> #endif
> +#define PRId32 __PRI32_PREFIX "d"
> +#define PRIu32 __PRI32_PREFIX "u"
> +#define PRIx32 __PRI32_PREFIX "x"
> #define PRId64 __PRI64_PREFIX "d"
> #define PRIu64 __PRI64_PREFIX "u"
> #define PRIx64 __PRI64_PREFIX "x"
>
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Paolo Bonzini @ 2017-01-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-5-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> README.md | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/README.md b/README.md
> index 5027b62..9462824 100644
> --- a/README.md
> +++ b/README.md
> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
> [format]
> subjectprefix = kvm-unit-tests PATCH
>
> +Please run the kernel's ./scripts/checkpatch.pl on new patches
Does it really work well on kvm-unit-tests?
Paolo
^ permalink raw reply
* [kvm-unit-tests PATCH 6/6] run_tests: allow passing of options to QEMU
From: Paolo Bonzini @ 2017-01-12 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-7-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> This allows additional options to be passed to QEMU. It follows the
> convention of passing parameters after a -- to the child process. In
> my case I'm using it to toggle MTTCG on an off:
>
> ./run_tests.sh -- --accel tcg,thread=multi
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>
> ---
> v1
> - changes from -o to --
> - fixed whitespace damage
> ---
> README.md | 6 ++++++
> run_tests.sh | 13 +++++++++++--
> scripts/functions.bash | 7 ++++---
> 3 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/README.md b/README.md
> index fa3a445..1bd6dcb 100644
> --- a/README.md
> +++ b/README.md
> @@ -55,6 +55,12 @@ To extend or disable the timeouts:
>
> TIMEOUT=0 ./run_tests.sh
>
> +Any arguments past the end-of-arguments marker (--) is passed on down
> +to the QEMU invocation. This can of course be combined with the other
> +modifiers:
> +
> + ACCEL=tcg ./run_tests.sh -v -- --accel tcg,thread=multi
> +
> # Contributing
>
> ## Directory structure
> diff --git a/run_tests.sh b/run_tests.sh
> index 254129d..3270fba 100755
> --- a/run_tests.sh
> +++ b/run_tests.sh
> @@ -13,7 +13,7 @@ function usage()
> {
> cat <<EOF
>
> -Usage: $0 [-g group] [-h] [-v]
> +Usage: $0 [-g group] [-h] [-v] [-- QEMU options]
>
> -g: Only execute tests in the given group
> -h: Output this help text
> @@ -22,6 +22,8 @@ Usage: $0 [-g group] [-h] [-v]
> Set the environment variable QEMU=/path/to/qemu-system-ARCH to
> specify the appropriate qemu binary for ARCH-run.
>
> +All options specified after -- are passed on to QEMU.
> +
> EOF
> }
>
> @@ -29,6 +31,7 @@ RUNTIME_arch_run="./$TEST_DIR/run"
> source scripts/runtime.bash
>
> while getopts "g:hv" opt; do
> +
> case $opt in
> g)
> only_group=$OPTARG
> @@ -46,6 +49,12 @@ while getopts "g:hv" opt; do
> esac
> done
>
> +# Any options left for QEMU?
> +shift $((OPTIND-1))
> +if [ "$#" -gt 0 ]; then
> + extra_opts="$@"
> +fi
> +
> RUNTIME_log_stderr () { cat >> test.log; }
> RUNTIME_log_stdout () {
> if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
> @@ -59,4 +68,4 @@ RUNTIME_log_stdout () {
> config=$TEST_DIR/unittests.cfg
> rm -f test.log
> printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
> -for_each_unittest $config run
> +for_each_unittest $config run "$extra_opts"
> diff --git a/scripts/functions.bash b/scripts/functions.bash
> index ee9143c..60fbc6a 100644
> --- a/scripts/functions.bash
> +++ b/scripts/functions.bash
> @@ -3,10 +3,11 @@ function for_each_unittest()
> {
> local unittests="$1"
> local cmd="$2"
> + local extra_opts=$3
> local testname
> local smp
> local kernel
> - local opts
> + local opts=$extra_opts
> local groups
> local arch
> local check
> @@ -21,7 +22,7 @@ function for_each_unittest()
> testname=${BASH_REMATCH[1]}
> smp=1
> kernel=""
> - opts=""
> + opts=$extra_opts
> groups=""
> arch=""
> check=""
> @@ -32,7 +33,7 @@ function for_each_unittest()
> elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
> smp=${BASH_REMATCH[1]}
> elif [[ $line =~ ^extra_params\ *=\ *(.*)$ ]]; then
> - opts=${BASH_REMATCH[1]}
> + opts="$opts ${BASH_REMATCH[1]}"
> elif [[ $line =~ ^groups\ *=\ *(.*)$ ]]; then
> groups=${BASH_REMATCH[1]}
> elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then
>
Great idea!
Paolo
^ permalink raw reply
* [kvm-unit-tests PATCH 4/6] docs: mention checkpatch in the README
From: Alex Bennée @ 2017-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <322298cd-aefa-e945-d3f4-1237767a06ef@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 11/01/2017 17:28, Alex Benn?e wrote:
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> README.md | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/README.md b/README.md
>> index 5027b62..9462824 100644
>> --- a/README.md
>> +++ b/README.md
>> @@ -79,3 +79,4 @@ You can add the following to .git/config to do this automatically for you:
>> [format]
>> subjectprefix = kvm-unit-tests PATCH
>>
>> +Please run the kernel's ./scripts/checkpatch.pl on new patches
>
> Does it really work well on kvm-unit-tests?
Well I keep getting pulled up on kernel coding style on my reviews so if
we mean it we should enforce it.
--
Alex Benn?e
^ permalink raw reply
* [kvm-unit-tests PATCH 2/6] lib/pci: fix BAR format strings
From: Paolo Bonzini @ 2017-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162841.15569-3-alex.bennee@linaro.org>
On 11/01/2017 17:28, Alex Benn?e wrote:
> Using %x as a format string is not portable across 32/64 bit builds.
> Use explicit PRIx32 format strings like the 64 bit version above.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> lib/pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/pci.c b/lib/pci.c
> index 6416191..597d8f2 100644
> --- a/lib/pci.c
> +++ b/lib/pci.c
> @@ -67,7 +67,7 @@ bool pci_setup_msi(struct pci_dev *dev, uint64_t msi_addr, uint32_t msi_data)
> pci_config_writel(addr, offset + PCI_MSI_DATA_32, msi_data);
> printf("MSI: dev 0x%x init 32bit address: ", addr);
> }
> - printf("addr=0x%lx, data=0x%x\n", msi_addr, msi_data);
> + printf("addr=0x%" PRIx64 ", data=0x%" PRIx32 "\n", msi_addr, msi_data);
Applying only the %lx -> %"PRIx64" change for now (though it's also in
Andrew's 32-bit compilation fixes patch).
Paolo
>
> msi_control |= PCI_MSI_FLAGS_ENABLE;
> pci_config_writew(addr, offset + PCI_MSI_FLAGS, msi_control);
> @@ -237,7 +237,7 @@ void pci_bar_print(struct pci_dev *dev, int bar_num)
> printf("BAR#%d,%d [%" PRIx64 "-%" PRIx64 " ",
> bar_num, bar_num + 1, start, end);
> } else {
> - printf("BAR#%d [%02x-%02x ",
> + printf("BAR#%d [%" PRIx32 "-%" PRIx32 " ",
> bar_num, (uint32_t)start, (uint32_t)end);
> }
>
>
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-12 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4286b719-ff75-d2cd-68b5-cb9d9bb89553@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 11/01/2017 17:28, Alex Benn?e wrote:
>> So we can have portable formatting of uint32_t types. However there is
>> a catch. Different compilers can use legally subtly different types
>> though so we need to probe the compiler defined intdef.h first.
>
> Interesting, what platform has long uint32_t? I thought the issue was
> whether 64-bit is long or "long long".
I haven't run into that one. This came up with the arm-none-eabi-gcc on
my overdrive01 box. According to the toolchain guys there is no particular
reason a 32bit compiler can't use long for its natural word length.
The native compiler on Debian armhf doesn't do this but the
arm-none-eabi-gcc compilers on both 64bit and 32bit Debian need this.
>
> Paolo
>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> Makefile | 1 +
>> configure | 13 +++++++++++++
>> lib/libcflat.h | 9 +++++++++
>> 3 files changed, 23 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index a32333b..9822d9a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
>> CFLAGS += $(fno_stack_protector)
>> CFLAGS += $(fno_stack_protector_all)
>> CFLAGS += $(wno_frame_address)
>> +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
>>
>> CXXFLAGS += $(CFLAGS)
>>
>> diff --git a/configure b/configure
>> index 995c8fa..127868c 100755
>> --- a/configure
>> +++ b/configure
>> @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
>> ln -fs $testdir/run $testdir-run
>> fi
>>
>> +# check if uint32_t needs a long format modifier
>> +cat << EOF > lib_test.c
>> +#include <inttypes.h>
>> +EOF
>> +
>> +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
>> +exit=$?
>> +if [ $exit -eq 0 ]; then
>> + u32_long=true
>> +fi
>> +rm -f lib_test.c
>> +
>> # check for dependent 32 bit libraries
>> if [ "$arch" != "arm" ]; then
>> cat << EOF > lib_test.c
>> @@ -155,4 +167,5 @@ TEST_DIR=$testdir
>> FIRMWARE=$firmware
>> ENDIAN=$endian
>> PRETTY_PRINT_STACKS=$pretty_print_stacks
>> +U32_LONG_FMT=$u32_long
>> EOF
>> diff --git a/lib/libcflat.h b/lib/libcflat.h
>> index 380395f..e80fc50 100644
>> --- a/lib/libcflat.h
>> +++ b/lib/libcflat.h
>> @@ -58,12 +58,21 @@ typedef _Bool bool;
>> #define true 1
>>
>> #if __SIZEOF_LONG__ == 8
>> +# define __PRI32_PREFIX
>> # define __PRI64_PREFIX "l"
>> # define __PRIPTR_PREFIX "l"
>> #else
>> +#if defined(__U32_LONG_FMT__)
>> +# define __PRI32_PREFIX "l"
>> +#else
>> +# define __PRI32_PREFIX
>> +#endif
>> # define __PRI64_PREFIX "ll"
>> # define __PRIPTR_PREFIX
>> #endif
>> +#define PRId32 __PRI32_PREFIX "d"
>> +#define PRIu32 __PRI32_PREFIX "u"
>> +#define PRIx32 __PRI32_PREFIX "x"
>> #define PRId64 __PRI64_PREFIX "d"
>> #define PRIu64 __PRI64_PREFIX "u"
>> #define PRIx64 __PRI64_PREFIX "x"
>>
--
Alex Benn?e
^ permalink raw reply
* [GIT PULL] Ux500 PM fix from Arnd
From: Linus Walleij @ 2017-01-12 13:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
this was forgotten on my fixes branch, sorry. Please pull it
in for fixes in the ARM SoC tree.
Yours,
Linus Walleij
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-fix-for-armsoc
for you to fetch changes up to f0e8faa7a5e894b0fc99d24be1b18685a92ea466:
ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation (2017-01-12 13:25:39 +0100)
----------------------------------------------------------------
A single PM fix from Arnd
----------------------------------------------------------------
Arnd Bergmann (1):
ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
arch/arm/mach-ux500/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL] Ux500 development for v4.11
From: Linus Walleij @ 2017-01-12 13:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
here is a set of two patches ready to be queued for v4.11 already.
Please pull them to a suitable branch on the ARM SoC tree.
Yours,
Linus Walleij
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-dev-for-armsoc
for you to fetch changes up to f3c05596344fa09074220513583bc5d6ff2d5c43:
ARM: ux500: remove duplicated include from cpu-db8500.c (2017-01-12
14:02:34 +0100)
----------------------------------------------------------------
Some two collected patches simplifying some Ux500
stuff.
----------------------------------------------------------------
Linus Walleij (1):
ARM: ux500: simplify secondary boot
Wei Yongjun (1):
ARM: ux500: remove duplicated include from cpu-db8500.c
arch/arm/mach-ux500/cpu-db8500.c | 1 -
arch/arm/mach-ux500/platsmp.c | 45 +++++++++++++++++-----------------------
2 files changed, 19 insertions(+), 27 deletions(-)
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Christoph Hellwig @ 2017-01-12 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3306663.hKmLLq1hhl@wuerfel>
On Thu, Jan 12, 2017 at 12:56:07PM +0100, Arnd Bergmann wrote:
> That is an interesting question: We actually have the
> "DMA_ATTR_NO_KERNEL_MAPPING" for this case, and ARM implements
> it in the coherent interface, so that might be a good fit.
Yes. my WIP HMB patch uses DMA_ATTR_NO_KERNEL_MAPPING, although I'm
workin on x86 at the moment where it's a no-op.
> Implementing it in the streaming API makes no sense since we
> already have a kernel mapping here, but using a normal allocation
> (possibly with DMA_ATTR_NON_CONSISTENT or DMA_ATTR_SKIP_CPU_SYNC,
> need to check) might help on other architectures that have
> limited amounts of coherent memory and no CMA.
Though about that - but in the end DMA_ATTR_NO_KERNEL_MAPPING implies
those, so instead of using lots of flags in driver I'd rather fix
up more dma_ops implementations to take advantage of
DMA_ATTR_NO_KERNEL_MAPPING.
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Uwe Kleine-König @ 2017-01-12 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111220235.GP14532@bhelgaas-glaptop.roam.corp.google.com>
On 01/11/2017 11:02 PM, Bjorn Helgaas wrote:
> Hi Uwe,
>
> On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
>> Hello,
>>
>> on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
>> ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
>> is enabled:
>>
>> [...]
> We have several open issues related to ASPM:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=102311 ASPM: ASMEDA asm1062 not working
> https://bugzilla.kernel.org/show_bug.cgi?id=187731 Null pointer dereference in ASPM
> https://bugzilla.kernel.org/show_bug.cgi?id=189951 Enabling ASPM causes NIC performance issue
> https://bugzilla.kernel.org/show_bug.cgi?id=60111 NULL pointer deref in ASPM alloc_pcie_link_state()
>
> I don't recognize yours as being one of these. Can you open a new
> issue and attach the complete dmesg log and "lspci -vv" output?
Done: https://bugzilla.kernel.org/show_bug.cgi?id=192441
> Is this a regression?
As written in the bug report this also happens on 4.7.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/d9f681f1/attachment.sig>
^ permalink raw reply
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-12 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff9c81c2-90ef-a5c2-6f0b-c6cf5d0d11a9@arm.com>
On 2017/1/12 17:11, Marc Zyngier wrote:
> On 12/01/17 04:23, Ding Tianhong wrote:
>> Hi Marc:
>>
>> How about this v7, if any suggestions very grateful.
>
> It's been less than 5 days since you posted this. I'll get to it once I
> finish reviewing all the other patches that are sitting in the queue
> right before yours.
>
Ok and sorry for the noisy.
Thanks
Ding
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH 1/2][UPDATE] of: base: add support to get the number of cache levels
From: Rob Herring @ 2017-01-12 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049616-22388-1-git-send-email-sudeep.holla@arm.com>
On Tue, Jan 10, 2017 at 6:00 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. This patch adds the support for the
> same.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/of/base.c | 23 +++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..80e557eca858 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -25,6 +25,7 @@
> #include <linux/cpu.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/spinlock.h>
> #include <linux/slab.h>
> @@ -2268,6 +2269,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
> }
>
> /**
> + * of_count_cache_levels - Find the total number of cache levels for the
> + * given logical cpu
> + *
> + * @cpu: cpu number(logical index) for which cache levels is being counted
> + *
> + * Returns the total number of cache levels for the given logical cpu
> + */
> +int of_count_cache_levels(unsigned int cpu)
> +{
> + int level = 0;
> + struct device_node *np = of_cpu_device_node_get(cpu);
> +
> + while (np) {
> + level++;
This will return 1 if you have a cpu node and no cache nodes. Are you
assuming the cpu has a cache?
Perhaps you should just find the last level cache node and then just
read "cache-level".
Rob
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-12 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112121623.GH1771@arm.com>
On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote:
> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote:
> > >> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> index 5ac373c..480b644 100644
> > >> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> > >> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
> > >>
> > >> /* Objects are coherent, unless 'no shareability' flag set. */
> > >> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> > >> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> > >> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
> > >>
> > >> /*
> > >> * The device-specific probe callback will get invoked by device_add()
> > >
> > > Why are these actually calling arch_setup_dma_ops() here in the first
> > > place? Are these all devices that are DMA masters without an OF node?
> >
> > I don't know, but that's a different topic. This patch just adds
> > argument and sets it to false everywhere but in the location when range
> > should be definitely enforced.
>
> I also wouldn't lose any sleep over a staging driver.
I think this is in the process of being moved out of staging, and
my question was about the other two as well:
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/iommu/rockchip-iommu.c
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox