* [PATCH v4 02/21] linux/io.h: add PCI config space remap interface
From: Bjorn Helgaas @ 2017-04-20 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420105153.GA9741@red-moon>
On Thu, Apr 20, 2017 at 5:51 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> [+ Michael]
>
> On Wed, Apr 19, 2017 at 05:48:51PM +0100, Lorenzo Pieralisi wrote:
>> The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
>> Posting") mandate non-posted configuration transactions. As further
>> highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering
>> Considerations for the Enhanced Configuration Access Mechanism"),
>> through ECAM and ECAM-derivative configuration mechanism, the memory
>> mapped transactions from the host CPU into Configuration Requests on the
>> PCI express fabric may create ordering problems for software because
>> writes to memory address are typically posted transactions (unless the
>> architecture can enforce through virtual address mapping non-posted
>> write transactions behaviour) but writes to Configuration Space are not
>> posted on the PCI express fabric.
>>
>> Current DT and ACPI host bridge controllers map PCI configuration space
>> (ECAM and ECAM-derivative) into the virtual address space through
>> ioremap() calls, that are non-cacheable device accesses on most
>> architectures, but may provide "bufferable" or "posted" write semantics
>> in architecture like eg ARM/ARM64 that allow ioremap'ed regions writes
>> to be buffered in the bus connecting the host CPU to the PCI fabric;
>> this behaviour, as underlined in the PCIe specifications, may trigger
>> transactions ordering rules and must be prevented.
>>
>> Introduce a new generic and explicit API to create a memory
>> mapping for ECAM and ECAM-derivative config space area that
>> defaults to ioremap_nocache() (which should provide a sane default
>> behaviour) but still allowing architectures on which ioremap_nocache()
>> results in posted write transactions to override the function
>> call with an arch specific implementation that complies with
>> the PCI specifications for configuration transactions.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> include/linux/io.h | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/include/linux/io.h b/include/linux/io.h
>> index 82ef36e..3934aba 100644
>> --- a/include/linux/io.h
>> +++ b/include/linux/io.h
>> @@ -91,6 +91,25 @@ void devm_memunmap(struct device *dev, void *addr);
>> void *__devm_memremap_pages(struct device *dev, struct resource *res);
>>
>> /*
>> + * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
>> + * Posting") mandate non-posted configuration transactions. There is
>> + * no ioremap API in the kernel that can guarantee non-posted write
>> + * semantics across arches so provide a default implementation for
>> + * mapping PCI config space that defaults to ioremap_nocache(); arches
>> + * should override it if they have memory mapping implementations that
>> + * guarantee non-posted writes semantics to make the memory mapping
>> + * compliant with the PCI specification.
>> + */
>> +#ifndef pci_remap_cfgspace
>> +#define pci_remap_cfgspace pci_remap_cfgspace
>> +static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
>> + size_t size)
>> +{
>> + return ioremap_nocache(offset, size);
>> +}
>> +#endif
>> +
>> +/*
>
> As an heads-up, this patch strictly depends on:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/include/asm/io.h?id=590c369e7ecc00be736be39ae0c62d1b5d563a51
>
> to go upstream first, otherwise we would break powerpc compilation
> (owing to powerpc including linux/io.h before ioremap_nocache() is
> defined in arch/powerpc/include/asm/io.h).
>
> If we want to decouple them I must drop the static inline and make
> it a #define, it is not ideal but we must be aware of this, I really
> want to prevent breakage if we go ahead with this set (and -next can
> hide the issue).
It looks like Stephen merges powerpc/next into linux-next before
pci/next, so this will probably be OK there. I'll try to remember to
wait for the powerpc stuff to make it to Linus' tree during the merge
window before I send my pull request.
Bjorn
^ permalink raw reply
* [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI
From: Petr Mladek @ 2017-04-20 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420033112.GB542@jagdpanzerIV.localdomain>
On Thu 2017-04-20 12:31:12, Sergey Senozhatsky wrote:
> Hello Steven,
>
> On (04/19/17 13:13), Steven Rostedt wrote:
> > > printk() takes some locks and could not be used a safe way in NMI context.
> >
> > I just found a problem with this solution. It kills ftrace dumps from
> > NMI context :-(
> >
> > [ 1295.168495] <...>-67423 10dNh1 382171111us : do_raw_spin_lock <-_raw_spin_lock
> > [ 1295.168495] <...>-67423 10dNh1 382171111us : sched_stat_runtime: comm=cc1 pid=67423 runtime=96858 [ns] vruntime=11924198270 [ns]
> > [ 1295.168496] <...>-67423 10dNh1 382171111us : lock_acquire: ffffffff81c5c940 read rcu_read_lock
> > [ 1295.168497]
> > [ 1295.168498] Lost 4890096 message(s)!
> > [ 1296.805063] ---[ end Kernel panic - not syncing: Hard LOCKUP
> > [ 1296.811553] unchecked MSR access error: WRMSR to 0x83f (tried to write 0x00000000000000f6) at rIP: 0xffffffff81046fc7 (native_apic_msr_write+0x27/0x40)
> > [ 1296.811553] Call Trace:
> > [ 1296.811553] <NMI>
> >
> > I was hoping to see a cause of a hard lockup by enabling
> > ftrace_dump_on_oops. But as NMIs now have a very small buffer that
> > gets flushed, we need to find a new way to print out the full ftrace
> > buffer over serial.
> >
> > Thoughts?
>
> hmmm... a really tough one.
>
> well, someone has to say this:
> the simplest thing is to have a bigger PRINTK_SAFE_LOG_BUF_SHIFT value :)
>
>
> just thinking (well, sort of) out loud. the problem is that we can't tell if
> we already hold any printk related locks ("printk related locks" is not even
> well defined term). so printk from NMI can deadlock or it can be OK, we
> never know. but looking and vprintk_emit() and console_unlock() it seems that
> we have some sort of a hint now, which is this_cpu_read(printk_context) - if
> we are not in printk_safe context then we can say that _probably_ (and that's
> a Russian roulette) doing "normal" printk() will work. that is a *very-very*
> risky (and admittedly dumb) thing to assume, so we will move in a slightly
> different direction. checking this_cpu_read(printk_context) only assures us
> that we don't hold `logbuf_lock' on this CPU. and that is sort of something,
> at least we can be sure that doing printk_deferred() from this CPU is safe.
> printk_deferred() means that your NMI messages will end up in the logbuf,
> which is a) bigger in size than per-CPU buffer and b) some other CPU can
> immediately print those messages (hopefully).
>
> we also switch to printk_safe mode for call_console_drivers() in
> console_unlock(). but we can't make any solid assumptions there - serial
> console lock can already be acquired, we don't have any markers for that.
> it may be reasonable to assume that if we are not in printk_safe mode on
> this CPU then serial console is not locked from this CPU, but there is
> nothing that can assure us.
Good analyze. I would summarize it that we need to be careful of:
+ logbug_lock
+ PRINTK_SAFE_CONTEXT
+ locks used by console drivers
The first two things are easy to check. Except that a check for logbuf_lock
might produce false negatives. The last check is very hard.
> so at the moment what I can think of is something like
>
> -- check this_cpu_read(printk_context) in NMI prink
>
> -- if we are NOT in printk_safe on this CPU, then do printk_deferred()
> and bypass `nmi_print_seq' buffer
I would add also a check for logbuf_lock.
> -- if we are in printk_safe
> -- well... bad luck... have a bigger buffer.
Yup, we do the best effort while still trying to stay on the safe
side.
I have cooked up a patch based on this. It uses printk_deferred()
in NMI when it is safe. Note that console_flush_on_panic() will
try to get them on the console when a kdump is not generated.
I believe that it will help Steven.
>From c530d9dee91c74db5e6a198479e2e63b24cb84a2 Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.com>
Date: Thu, 20 Apr 2017 10:52:31 +0200
Subject: [PATCH] printk: Use the main logbuf in NMI when logbuf_lock is
available
The commit 42a0bb3f71383b457a7d ("printk/nmi: generic solution for safe
printk in NMI") caused that printk stores messages into a temporary
buffer in NMI context.
The buffer is per-CPU and therefore the size is rather limited.
It works quite well for NMI backtraces. But there are longer logs
that might get printed in NMI context, for example, lockdep
warnings, ftrace_dump_on_oops.
The temporary buffer is used to avoid deadlocks caused by
logbuf_lock. Also it is needed to avoid races with the other
temporary buffer that is used when PRINTK_SAFE_CONTEXT is entered.
But the main buffer can be used in NMI if the lock is available
and we did not interrupt PRINTK_SAFE_CONTEXT.
The lock is checked using raw_spin_is_locked(). It might cause
false negatives when the lock is taken on another CPU outside NMI.
For this reason, we do the check in printk_nmi_enter(). It makes
the handling consistent for the entire NMI handler and avoids
reshuffling of the messages.
The patch also defines special printk context that allows
to use printk_deferred() in NMI. Note that we could not flush
the messages to the consoles because console drivers might use
many other internal locks.
The newly created vprintk_deferred() disables the preemption
only around the irq work handling. It is needed there to keep
the consistency between the two per-CPU variables. But there
is no reason to disable preemption around vprintk_emit().
Finally, the patch patch puts back explicit serialization
of the NMI backtraces from different CPUs. It was removed
by the commit a9edc88093287183ac934b ("x86/nmi: Perform
a safe NMI stack trace on all CPUs"). It was not needed
because the flushing of the temporary per-CPU buffers
was serialized.
Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/printk/internal.h | 6 ++++--
kernel/printk/printk.c | 19 ++++++++++++++-----
kernel/printk/printk_safe.c | 25 +++++++++++++++++++++++--
lib/nmi_backtrace.c | 3 +++
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h
index 1db044f808b7..2a7d04049af4 100644
--- a/kernel/printk/internal.h
+++ b/kernel/printk/internal.h
@@ -18,12 +18,14 @@
#ifdef CONFIG_PRINTK
-#define PRINTK_SAFE_CONTEXT_MASK 0x7fffffff
-#define PRINTK_NMI_CONTEXT_MASK 0x80000000
+#define PRINTK_SAFE_CONTEXT_MASK 0x3fffffff
+#define PRINTK_NMI_DEFERRED_CONTEXT_MASK 0x40000000
+#define PRINTK_NMI_CONTEXT_MASK 0x80000000
extern raw_spinlock_t logbuf_lock;
__printf(1, 0) int vprintk_default(const char *fmt, va_list args);
+__printf(1, 0) int vprintk_deferred(const char *fmt, va_list args);
__printf(1, 0) int vprintk_func(const char *fmt, va_list args);
void __printk_safe_enter(void);
void __printk_safe_exit(void);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2984fb0f0257..16b519927d35 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2691,16 +2691,13 @@ void wake_up_klogd(void)
preempt_enable();
}
-int printk_deferred(const char *fmt, ...)
+int vprintk_deferred(const char *fmt, va_list args)
{
- va_list args;
int r;
- preempt_disable();
- va_start(args, fmt);
r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
- va_end(args);
+ preempt_disable();
__this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
preempt_enable();
@@ -2708,6 +2705,18 @@ int printk_deferred(const char *fmt, ...)
return r;
}
+int printk_deferred(const char *fmt, ...)
+{
+ va_list args;
+ int r;
+
+ va_start(args, fmt);
+ r = vprintk_deferred(fmt, args);
+ va_end(args);
+
+ return r;
+}
+
/*
* printk rate limiting, lifted from the networking subsystem.
*
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 033e50a7d706..c3d165bcde42 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -308,12 +308,23 @@ static int vprintk_nmi(const char *fmt, va_list args)
void printk_nmi_enter(void)
{
- this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK);
+ /*
+ * The size of the extra per-CPU buffer is limited. Use it
+ * only when really needed.
+ */
+ if (this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK ||
+ raw_spin_is_locked(&logbuf_lock)) {
+ this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK);
+ } else {
+ this_cpu_or(printk_context, PRINTK_NMI_DEFERRED_CONTEXT_MASK);
+ }
}
void printk_nmi_exit(void)
{
- this_cpu_and(printk_context, ~PRINTK_NMI_CONTEXT_MASK);
+ this_cpu_and(printk_context,
+ ~(PRINTK_NMI_CONTEXT_MASK ||
+ PRINTK_NMI_DEFERRED_CONTEXT_MASK));
}
#else
@@ -351,12 +362,22 @@ void __printk_safe_exit(void)
__printf(1, 0) int vprintk_func(const char *fmt, va_list args)
{
+ /* Use extra buffer in NMI when logbuf_lock is taken or in safe mode. */
if (this_cpu_read(printk_context) & PRINTK_NMI_CONTEXT_MASK)
return vprintk_nmi(fmt, args);
+ /* Use extra buffer to prevent a recursion deadlock in safe mode. */
if (this_cpu_read(printk_context) & PRINTK_SAFE_CONTEXT_MASK)
return vprintk_safe(fmt, args);
+ /*
+ * Use the main logbuf when logbuf_lock is available in NMI.
+ * But avoid calling console drivers that might have their own locks.
+ */
+ if (this_cpu_read(printk_context) & PRINTK_NMI_DEFERRED_CONTEXT_MASK)
+ return vprintk_deferred(fmt, args);
+
+ /* No obstacles. */
return vprintk_default(fmt, args);
}
diff --git a/lib/nmi_backtrace.c b/lib/nmi_backtrace.c
index 4e8a30d1c22f..0bc0a3535a8a 100644
--- a/lib/nmi_backtrace.c
+++ b/lib/nmi_backtrace.c
@@ -86,9 +86,11 @@ void nmi_trigger_cpumask_backtrace(const cpumask_t *mask,
bool nmi_cpu_backtrace(struct pt_regs *regs)
{
+ static arch_spinlock_t lock = __ARCH_SPIN_LOCK_UNLOCKED;
int cpu = smp_processor_id();
if (cpumask_test_cpu(cpu, to_cpumask(backtrace_mask))) {
+ arch_spin_lock(&lock);
if (regs && cpu_in_idle(instruction_pointer(regs))) {
pr_warn("NMI backtrace for cpu %d skipped: idling at pc %#lx\n",
cpu, instruction_pointer(regs));
@@ -99,6 +101,7 @@ bool nmi_cpu_backtrace(struct pt_regs *regs)
else
dump_stack();
}
+ arch_spin_unlock(&lock);
cpumask_clear_cpu(cpu, to_cpumask(backtrace_mask));
return true;
}
--
1.8.5.6
^ permalink raw reply related
* [arm:for-next 9/10] include/linux/bitops.h:56:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type
From: kbuild test robot @ 2017-04-20 13:08 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
head: b353b2cf63d7b9d5031ca7fd259ab58e492e7dc1
commit: c4f8ff16b46b3857a1e0a3b06b2b5c74c8556eda [9/10] ARM: 8669/1: bitops: Align prototypes to generic API
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c4f8ff16b46b3857a1e0a3b06b2b5c74c8556eda
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from include/linux/bitops.h:36:0,
from include/linux/bitmap.h:7,
from drivers/dma/sun4i-dma.c:11:
drivers/dma/sun4i-dma.c: In function 'find_and_use_pchan':
>> include/linux/bitops.h:56:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
^
>> drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
for_each_clear_bit_from(i, &priv->pchans_used, max) {
^~~~~~~~~~~~~~~~~~~~~~~
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/bitops.h:58:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
^
>> drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
for_each_clear_bit_from(i, &priv->pchans_used, max) {
^~~~~~~~~~~~~~~~~~~~~~~
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
^~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from include/linux/bitops.h:36:0,
from include/linux/bitmap.h:7,
from drivers//dma/sun4i-dma.c:11:
drivers//dma/sun4i-dma.c: In function 'find_and_use_pchan':
>> include/linux/bitops.h:56:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
^
drivers//dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
for_each_clear_bit_from(i, &priv->pchans_used, max) {
^~~~~~~~~~~~~~~~~~~~~~~
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/bitops.h:58:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
^
drivers//dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
for_each_clear_bit_from(i, &priv->pchans_used, max) {
^~~~~~~~~~~~~~~~~~~~~~~
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
^~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/_find_next_zero_bit_le +56 include/linux/bitops.h
4677d4a5 Borislav Petkov 2010-05-03 30 extern unsigned long __sw_hweight64(__u64 w);
4677d4a5 Borislav Petkov 2010-05-03 31
^1da177e Linus Torvalds 2005-04-16 32 /*
^1da177e Linus Torvalds 2005-04-16 33 * Include this here because some architectures need generic_ffs/fls in
^1da177e Linus Torvalds 2005-04-16 34 * scope
^1da177e Linus Torvalds 2005-04-16 35 */
^1da177e Linus Torvalds 2005-04-16 @36 #include <asm/bitops.h>
^1da177e Linus Torvalds 2005-04-16 37
984b3f57 Akinobu Mita 2010-03-05 38 #define for_each_set_bit(bit, addr, size) \
3e037454 Shannon Nelson 2007-10-16 39 for ((bit) = find_first_bit((addr), (size)); \
3e037454 Shannon Nelson 2007-10-16 40 (bit) < (size); \
3e037454 Shannon Nelson 2007-10-16 41 (bit) = find_next_bit((addr), (size), (bit) + 1))
3e037454 Shannon Nelson 2007-10-16 42
1e2ad28f Robert Richter 2011-11-18 43 /* same as for_each_set_bit() but use bit as value to start with */
307b1cd7 Akinobu Mita 2012-03-23 44 #define for_each_set_bit_from(bit, addr, size) \
1e2ad28f Robert Richter 2011-11-18 45 for ((bit) = find_next_bit((addr), (size), (bit)); \
1e2ad28f Robert Richter 2011-11-18 46 (bit) < (size); \
1e2ad28f Robert Richter 2011-11-18 47 (bit) = find_next_bit((addr), (size), (bit) + 1))
1e2ad28f Robert Richter 2011-11-18 48
03f4a822 Akinobu Mita 2012-03-23 49 #define for_each_clear_bit(bit, addr, size) \
03f4a822 Akinobu Mita 2012-03-23 50 for ((bit) = find_first_zero_bit((addr), (size)); \
03f4a822 Akinobu Mita 2012-03-23 51 (bit) < (size); \
03f4a822 Akinobu Mita 2012-03-23 52 (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
03f4a822 Akinobu Mita 2012-03-23 53
03f4a822 Akinobu Mita 2012-03-23 54 /* same as for_each_clear_bit() but use bit as value to start with */
03f4a822 Akinobu Mita 2012-03-23 55 #define for_each_clear_bit_from(bit, addr, size) \
03f4a822 Akinobu Mita 2012-03-23 @56 for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
03f4a822 Akinobu Mita 2012-03-23 57 (bit) < (size); \
03f4a822 Akinobu Mita 2012-03-23 58 (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
03f4a822 Akinobu Mita 2012-03-23 59
:::::: The code at line 56 was first introduced by commit
:::::: 03f4a8226c2f9c14361f75848d1e93139bab90c4 bitops: introduce for_each_clear_bit()
:::::: TO: Akinobu Mita <akinobu.mita@gmail.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 20782 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170420/4a18f434/attachment-0001.gz>
^ permalink raw reply
* [RFC PATCH v2 0/6] Signal frame expansion support
From: Dave Martin @ 2017-04-20 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760hz47u7.fsf@concordia.ellerman.id.au>
On Thu, Apr 20, 2017 at 09:49:36PM +1000, Michael Ellerman wrote:
> Dave Martin <Dave.Martin@arm.com> writes:
>
> > (Note: This is an arm64-specific series, but the concepts introduced may
> > be of interest to other arches -- see in particular patch 6.)
>
> Hi Dave,
>
> I think we (powerpc) will probably want to use this too.
>
> I haven't dug into the details yet, I'll try and do that after the 4.12
> merge window.
That would be great, thanks.
Since I've been focusing on arm64 and SVE, there may be generalities
or design issues that I've missed.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/3] ARM: dts: r8a7743: add PFC support
From: Sergei Shtylyov @ 2017-04-20 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420085112.GF3760@verge.net.au>
Hello.
On 04/20/2017 11:51 AM, Simon Horman wrote:
>> Define the generic R8A7743 part of the PFC device node.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> arch/arm/boot/dts/r8a7743.dtsi | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
>> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
>> @@ -1,7 +1,7 @@
>> /*
>> * Device Tree Source for the r8a7743 SoC
>> *
>> - * Copyright (C) 2016 Cogent Embedded Inc.
>> + * Copyright (C) 2016-2017 Cogent Embedded Inc.
>> *
>> * This file is licensed under the terms of the GNU General Public License
>> * version 2. This program is licensed "as is" without any warranty of any
>> @@ -123,6 +123,11 @@
>> #power-domain-cells = <1>;
>> };
>>
>> + pfc: pin-controller at e6060000 {
>> + compatible = "renesas,pfc-r8a7743";
>> + reg = <0 0xe6060000 0 0x250>;
>> + };
>> +
>
> I am curious to know why pin-controller was chosen rather than pfc which
> is dominant in the DT for Renesas SoCs.
The reason is simple: I was trying to follow the DT specs which require
generic node names. The "pin-controller" looked more generic than "pfc".
> And as a follow-up question, do
> you think it would be worth creating patches to make this uniform
> across the DT for Renesas SoCs.
Yes, probably.
[...]
MBR, Sergei
^ permalink raw reply
* [RFC PATCH v2 0/6] Signal frame expansion support
From: Michael Ellerman @ 2017-04-20 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492016239-19511-1-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> (Note: This is an arm64-specific series, but the concepts introduced may
> be of interest to other arches -- see in particular patch 6.)
Hi Dave,
I think we (powerpc) will probably want to use this too.
I haven't dug into the details yet, I'll try and do that after the 4.12
merge window.
cheers
^ permalink raw reply
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-04-20 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3119026.3cPho1BBNv@avalon>
Hi Laurent,
On Thu, Apr 20, 2017 at 1:24 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote:
>> On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote:
>> > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
>> >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
>> >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> >>>> - The following devices no longer exist on ES2.0, and are thus
>> >>>> removed:
>> >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> >>>>
>> >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> >>>> "vsps" property from the DU node until the driver can handle this.
>> >>>
>> >>> I think I'll need a different compatible string between ES1.x and ES2
>> >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi.
>> >>> We can decide about that later when I'll have a DU driver prototype
>> >>> ready.
>> >>
>> >> Why would you need a different compatible string?
>> >> Can't you use soc_device_match() to handle ES1.x SoCs?
>> >>
>> >> The different DU <-> VSPD topology is handled through the vsps property
>> >> in
>> >> DTS. Are the ports different, too? That can be handled in DTS.
>> >
>> > My point (not expressed clearly) was that, as I'll need a different vsps
>> > property, I can as well go for a different compatible string.
>>
>> Do you need a different vsps property?
>> AFAIK, the current array links each DU channel to a VSPD.
>> When a VSPD is shared between multiple channels, you can still link these
>> channels to the same VSPD.
>>
>> Or is my understanding incorrect?
>
> Do you mean listing the same VSP multiple times in the vsps array ? Yes, from
Yes, that's what I mean.
> a bindings point of view I think that would work too. That is, until we get a
OK.
> ES2.1 that will have a completely different hardware topology :-)
We'll fix that after we have received ES2.1 documentation...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Laurent Pinchart @ 2017-04-20 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWmvhZjxKfEdGJ3d_w0d2s2kK+8iW1tsEM584qZc+dVEQ@mail.gmail.com>
Hi Geert,
On Thursday 20 Apr 2017 12:55:28 Geert Uytterhoeven wrote:
> On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart wrote:
> > On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
> >> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
> >>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> >>>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> >>>> - The following devices no longer exist on ES2.0, and are thus
> >>>> removed:
> >>>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> >>>>
> >>>> - The DU <-> VSPD topology is different on ES2.0, hence remove the
> >>>> "vsps" property from the DU node until the driver can handle this.
> >>>
> >>> I think I'll need a different compatible string between ES1.x and ES2
> >>> for the DU. It could make sense to move the whole DU node to *-es1.dtsi.
> >>> We can decide about that later when I'll have a DU driver prototype
> >>> ready.
> >>
> >> Why would you need a different compatible string?
> >> Can't you use soc_device_match() to handle ES1.x SoCs?
> >>
> >> The different DU <-> VSPD topology is handled through the vsps property
> >> in
> >> DTS. Are the ports different, too? That can be handled in DTS.
> >
> > My point (not expressed clearly) was that, as I'll need a different vsps
> > property, I can as well go for a different compatible string.
>
> Do you need a different vsps property?
> AFAIK, the current array links each DU channel to a VSPD.
> When a VSPD is shared between multiple channels, you can still link these
> channels to the same VSPD.
>
> Or is my understanding incorrect?
Do you mean listing the same VSP multiple times in the vsps array ? Yes, from
a bindings point of view I think that would work too. That is, until we get a
ES2.1 that will have a completely different hardware topology :-)
> >> The main reason why I kept the DU node in r8a7795.dtsi is that the board
> >> DTS refers to it. Sharing board DTS means there needs to be at least a
> >> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
> >> shuffling board overrides around.
> >
> > As the ports are identical it makes sense to share the same board DTS, I
> > agree with you. We could override the compatible string in
> > r8a7795-es1.dtsi and leave it blank in r8a7795.dtsi for now, as there's
> > no driver support for ES2.0. That's a bit of a workaround as it shouldn't
> > matter to DT whether driver support is available or not. On the other
> > hand, leaving the vsps property out is a workaround too.
> >
> > The current driver will fail probing if the number of VSPs is different
> > than the number of CRTCs, so I believe you can keep the vsps property in
> > r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no
> > DT bindings for the H3 ES2.0 DU yet, so we would end up merging DT
> > without bindings, which is not good. I think that regardless of how we
> > proceed, keeping the DU node in the ES2.0 .dtsi will be a violation of
> > that policy.
>
> What does the current driver do if the number of VSPs is the same as the
> number of CRTCs, but some VSPs are listed more than once?
> I guess it will break in a subtle way, instead of refusing to probe?
Correct, it will be messy.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM: hyp-stub: Fix Thumb-2 compilation
From: Christoffer Dall @ 2017-04-20 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420101620.1368-1-marc.zyngier@arm.com>
On Thu, Apr 20, 2017 at 11:16:20AM +0100, Marc Zyngier wrote:
> The assembler defaults to emiting the short form of ADR, leading
> to an out-of-range immediate. Using the wide version solves this
> issue.
>
> Fixes: bc845e4fbbbb ("ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code")
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/kernel/hyp-stub.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> index d8523cc47a54..ec7e7377d423 100644
> --- a/arch/arm/kernel/hyp-stub.S
> +++ b/arch/arm/kernel/hyp-stub.S
> @@ -125,7 +125,7 @@ ENTRY(__hyp_stub_install_secondary)
> * (see safe_svcmode_maskall).
> */
> @ Now install the hypervisor stub:
> - adr r7, __hyp_stub_vectors
> + W(adr) r7, __hyp_stub_vectors
> mcr p15, 4, r7, c12, c0, 0 @ set hypervisor vector base (HVBAR)
>
> @ Disable all traps, so we don't get any nasty surprise
> --
> 2.11.0
>
This fixes the compile, but I get this when booting it on TC2:
kvm [1]: 8-bit VMID
kvm [1]: IDMAP page: 80201000
kvm [1]: HYP VA range: 80000000:ffffffff
kvm [1]: Hyp mode initialized successfully
kvm [1]: vgic-v2 at 2c004000
kvm [1]: vgic interrupt IRQ16
kvm [1]: virtual timer IRQ19
Kernel panic - not syncing:
HYP panic: UNDEF PC:802010ac CPSR:800001da
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc3+ #140
Hardware name: ARM-Versatile Express
[<8021c5f1>] (unwind_backtrace) from [<802199eb>] (show_stack+0xb/0xc)
[<802199eb>] (show_stack) from [<803ccc15>] (dump_stack+0x71/0x80)
[<803ccc15>] (dump_stack) from [<80289467>] (panic+0xbb/0x1d4)
[<80289467>] (panic) from [<8020b1f5>]
(_kvm_arch_hardware_disable+0x11/0x20)
[<8020b1f5>] (_kvm_arch_hardware_disable) from [<8026c497>]
(flush_smp_call_function_queue+0x77/0x134)
[<8026c497>] (flush_smp_call_function_queue) from [<8021b8f9>]
(handle_IPI+0xd9/0x150)
[<8021b8f9>] (handle_IPI) from [<80201425>] (gic_handle_irq+0x65/0x6c)
[<80201425>] (gic_handle_irq) from [<8021a213>] (__irq_svc+0x53/0x7c)
Exception stack(0x80a01f18 to 0x80a01f60)
1f00: 00000001
00000000
1f20: 80a01f70 802231c1 00000000 80a00000 00000000 80a03c80 80a03c34
808445d8
1f40: 80a01f70 80a03c88 805b31d1 80a01f68 80217ce1 80217ce2 40000033
ffffffff
[<8021a213>] (__irq_svc) from [<80217ce2>] (arch_cpu_idle+0x22/0x24)
[<80217ce2>] (arch_cpu_idle) from [<8024ca89>] (do_idle+0xf9/0x158)
[<8024ca89>] (do_idle) from [<8024ccaf>] (cpu_startup_entry+0x13/0x14)
[<8024ccaf>] (cpu_startup_entry) from [<80800a4d>]
(start_kernel+0x309/0x314)
[<80800a4d>] (start_kernel) from [<80008095>] (0x80008095)
CPU1: stopping
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3+ #140
Hardware name: ARM-Versatile Express
[<8021c5f1>] (unwind_backtrace) from [<802199eb>] (show_stack+0xb/0xc)
[<802199eb>] (show_stack) from [<803ccc15>] (dump_stack+0x71/0x80)
[<803ccc15>] (dump_stack) from [<8021b95d>] (handle_IPI+0x13d/0x150)
[<8021b95d>] (handle_IPI) from [<80201425>] (gic_handle_irq+0x65/0x6c)
[<80201425>] (gic_handle_irq) from [<8021a213>] (__irq_svc+0x53/0x7c)
Exception stack(0xeec47e20 to 0xeec47e68)
7e20: 00000000 ef1a96dc 80000000 80000000 80a03de4 80a03cf8 ef1b5a84
ef1b5a80
7e40: 00000001 00000008 80a03de4 80845a00 00000000 eec47e70 8026c9ed
8026ca02
7e60: a0000033 ffffffff
[<8021a213>] (__irq_svc) from [<8026ca02>]
(smp_call_function_many+0x1aa/0x1f0)
[<8026ca02>] (smp_call_function_many) from [<8026ca89>]
(on_each_cpu+0x1d/0x30)
[<8026ca89>] (on_each_cpu) from [<8020c369>] (kvm_arch_init+0x339/0x3fc)
[<8020c369>] (kvm_arch_init) from [<80207149>] (kvm_init+0x11/0x214)
[<80207149>] (kvm_init) from [<8020177d>] (do_one_initcall+0x2d/0x104)
[<8020177d>] (do_one_initcall) from [<80800bed>]
(kernel_init_freeable+0x195/0x208)
[<80800bed>] (kernel_init_freeable) from [<805b2383>]
(kernel_init+0x7/0xd4)
[<805b2383>] (kernel_init) from [<80217361>] (ret_from_fork+0x11/0x30)
SMP: failed to stop secondary CPUs
---[ end Kernel panic - not syncing:
HYP panic: UNDEF PC:802010ac CPSR:800001da
Thanks,
-Christoffer
^ permalink raw reply
* LDM/STM alignment fixups on arm64
From: Srinivas Ramana @ 2017-04-20 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419155801.GC3238@e104818-lin.cambridge.arm.com>
On 04/19/2017 09:28 PM, Catalin Marinas wrote:
> On Wed, Apr 19, 2017 at 06:20:10PM +0530, Srinivas Ramana wrote:
>> On 04/19/2017 03:28 PM, Russell King - ARM Linux wrote:
>>> On Wed, Apr 19, 2017 at 12:03:58PM +0530, Srinivas Ramana wrote:
>>>> While understanding how the alignment are handled on arm and arm64, we came
>>>> across the fixups for LDM/LDRD/STM on arm where as these fixups are not
>>>> present on arm64.
>>>>
>>>> There may be some specific reason why these fixups are not ported to arm64.
>>>> Can you please help us understand this?
>>>>
>>>> With this difference in how kernel handles 32-bit apps on arm and arm64,
>>>> there can be apps which are working without abort on arm, but fail on arm64
>>>> (SIGBUS). We have tried to get some history on web, but not successful.
>>>>
>>>> If this is indeed missing on arm64, do you see any issue if its ported (does
>>>> it fail any guidance)?
>>>
>>> Do you have an application that fails because of this? Your email makes
>>> it sound very theoretical.
>>
>> I don't have any application with me right now. But i just tried passing an
>> intentional misaligned address in a test program. When i say intentional,
>> please note this code is buggy and should be fixed.
>>
>> So, my question is when arm has such fixups to handle such cases and do
>> gracefully, is there any reason why those fixups are not ported to arm64?
>
> As Russell said, until we find some application in the wild I wouldn't
> rush to provide such emulation. Such code is either broken or relying on
> undefined C behaviour so they should rather be fixed. As with the
> deprecated/obsolete ARMv7 instructions (SWP, CP15 barriers), we
> initially decided not to implement the emulation in the arm64 kernel,
> though we eventually accepted it. But in those cases the instructions
> were once real and used correctly. The unaligned LDM/STM or LDRD/STRD
> have never been supported by the ARM architecture. They were added to
> cope with some unaligned accesses in the Linux kernel network stack (in
> hindsight, they should have not been provided to user but maybe there
> were good reasons, I don't know the full history here).
>
Sure. Thanks. I think i got some context and guidance now.
>> Again, I do agree that apps has to fix these instances, but we do have
>> fixups in arch/arm.
>
> I also think the default on arch/arm should be SIGBUS for these
> instructions on ARMv7 but this was discussed before on the list.
>
>> I do see that the compiler can detect (if its not intentionally induced)
>> such cases and avoiding to generate LDM/STM and generates multiple LDR/STR.
>> So, I just want to know if it is safe to assume that the compiler would take
>> care of all such misaligned addresses passed to LDM/STM?
>
> The compiler won't detect if you break its alignment assumptions (i.e.
> in your example pointers to struct locat are 64-bit aligned as per the
> EABI/PCS). If you want the compiler to assume unaligned struct pointers,
> you'd have to mark the structure with the packed attribute (with the
> additional padding if necessary, not in your example though).
>
You are right. with __packed__ attribute compiler detects the
unalignment (added a char to the test structure in my program), I could
see that compiler generates multiple LDRs instead of LDM.
Thanks for the details.
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V15 02/11] ras: acpi/apei: cper: add support for generic data v3 structure
From: Borislav Petkov @ 2017-04-20 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492556723-9189-3-git-send-email-tbaicar@codeaurora.org>
On Tue, Apr 18, 2017 at 05:05:14PM -0600, Tyler Baicar wrote:
> The ACPI 6.1 spec adds a new version of the generic data structure.
which data structure? HEST?
> Add support to handle the new structure as well as properly verify
> and iterate through the generic data entries.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Reviewed-by: James Morse <james.morse@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This is clearly a new version of the patch so Reviewed-by tags don't
apply anymore. Ditto for the next one. Remember to remove such tags in
the future when the patches are changed non-trivially in a following
iteration.
> ---
> drivers/acpi/apei/ghes.c | 6 +++---
> drivers/firmware/efi/cper.c | 37 ++++++++++++++++++++++---------------
> include/acpi/ghes.h | 22 ++++++++++++++++++++++
> 3 files changed, 47 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 6d87ab7..dfb7dd2 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -429,7 +429,7 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
> int flags = -1;
> int sec_sev = ghes_severity(gdata->error_severity);
> struct cper_sec_mem_err *mem_err;
> - mem_err = (struct cper_sec_mem_err *)(gdata + 1);
> + mem_err = acpi_hest_get_payload(gdata);
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
while you're at it.
> if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
> return;
> @@ -466,7 +466,7 @@ static void ghes_do_proc(struct ghes *ghes,
> if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> CPER_SEC_PLATFORM_MEM)) {
> struct cper_sec_mem_err *mem_err;
> - mem_err = (struct cper_sec_mem_err *)(gdata+1);
> + mem_err = acpi_hest_get_payload(gdata);
Ditto
+ add a \n here.
> ghes_edac_report_mem_error(ghes, sev, mem_err);
>
> arch_apei_report_mem_error(sev, mem_err);
> @@ -476,7 +476,7 @@ static void ghes_do_proc(struct ghes *ghes,
> else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> CPER_SEC_PCIE)) {
> struct cper_sec_pcie *pcie_err;
> - pcie_err = (struct cper_sec_pcie *)(gdata+1);
> + pcie_err = acpi_hest_get_payload(gdata);
Ditto.
> if (sev == GHES_SEV_RECOVERABLE &&
> sec_sev == GHES_SEV_RECOVERABLE &&
> pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index d425374..8328a6f 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -32,6 +32,7 @@
> #include <linux/acpi.h>
> #include <linux/pci.h>
> #include <linux/aer.h>
> +#include <acpi/ghes.h>
>
> #define INDENT_SP " "
>
> @@ -386,8 +387,9 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> }
>
> -static void cper_estatus_print_section(
> - const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
> +static void
> +cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata,
> + int sec_no)
> {
> uuid_le *sec_type = (uuid_le *)gdata->section_type;
> __u16 severity;
> @@ -403,14 +405,18 @@ static void cper_estatus_print_section(
>
> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
> - struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
> + struct cper_sec_proc_generic *proc_err;
> +
> + proc_err = acpi_hest_get_payload(gdata);
Ditto.
> printk("%s""section_type: general processor error\n", newpfx);
> if (gdata->error_data_length >= sizeof(*proc_err))
> cper_print_proc_generic(newpfx, proc_err);
> else
> goto err_section_too_small;
> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
> - struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
> + struct cper_sec_mem_err *mem_err;
> +
> + mem_err = acpi_hest_get_payload(gdata);
Ditto.
> printk("%s""section_type: memory error\n", newpfx);
> if (gdata->error_data_length >=
> sizeof(struct cper_sec_mem_err_old))
> @@ -419,7 +425,9 @@ static void cper_estatus_print_section(
> else
> goto err_section_too_small;
> } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
> - struct cper_sec_pcie *pcie = (void *)(gdata + 1);
> + struct cper_sec_pcie *pcie;
> +
> + pcie = acpi_hest_get_payload(gdata);
Ditto.
> printk("%s""section_type: PCIe error\n", newpfx);
> if (gdata->error_data_length >= sizeof(*pcie))
> cper_print_pcie(newpfx, pcie, gdata);
> @@ -438,7 +446,7 @@ void cper_estatus_print(const char *pfx,
> const struct acpi_hest_generic_status *estatus)
> {
> struct acpi_hest_generic_data *gdata;
> - unsigned int data_len, gedata_len;
> + unsigned int data_len;
> int sec_no = 0;
> char newpfx[64];
> __u16 severity;
> @@ -452,11 +460,10 @@ void cper_estatus_print(const char *pfx,
> data_len = estatus->data_length;
> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> - while (data_len >= sizeof(*gdata)) {
> - gedata_len = gdata->error_data_length;
<-- \n here while you're@it.
We have to start making this code more readable. It looks write-only
right now.
> + while (data_len >= acpi_hest_get_size(gdata)) {
> cper_estatus_print_section(newpfx, gdata, sec_no);
> - data_len -= gedata_len + sizeof(*gdata);
> - gdata = (void *)(gdata + 1) + gedata_len;
> + data_len -= acpi_hest_get_record_size(gdata);
> + gdata = acpi_hest_get_next(gdata);
> sec_no++;
> }
> }
> @@ -486,12 +493,12 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
> return rc;
> data_len = estatus->data_length;
> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> - while (data_len >= sizeof(*gdata)) {
> - gedata_len = gdata->error_data_length;
> - if (gedata_len > data_len - sizeof(*gdata))
Ditto.
> + while (data_len >= acpi_hest_get_size(gdata)) {
> + gedata_len = acpi_hest_get_error_length(gdata);
> + if (gedata_len > data_len - acpi_hest_get_size(gdata))
> return -EINVAL;
<-- \n here too
> - data_len -= gedata_len + sizeof(*gdata);
> - gdata = (void *)(gdata + 1) + gedata_len;
> + data_len -= acpi_hest_get_record_size(gdata);
> + gdata = acpi_hest_get_next(gdata);
> }
> if (data_len)
> return -EINVAL;
> diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
> index 68f088a..b89361a 100644
> --- a/include/acpi/ghes.h
> +++ b/include/acpi/ghes.h
> @@ -12,6 +12,20 @@
> #define GHES_TO_CLEAR 0x0001
> #define GHES_EXITING 0x0002
>
> +#define acpi_hest_get_error_length(gdata) \
> + (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
> +#define acpi_hest_get_size(gdata) \
> + ((acpi_hest_get_version(gdata) >= 3) ? \
> + sizeof(struct acpi_hest_generic_data_v300) : \
> + sizeof(struct acpi_hest_generic_data))
> +#define acpi_hest_get_record_size(gdata) \
> + (acpi_hest_get_size(gdata) + \
> + acpi_hest_get_error_length(gdata))
> +#define acpi_hest_get_next(gdata) \
> + ((void *)(gdata) + acpi_hest_get_record_size(gdata))
> +#define acpi_hest_get_version(gdata) \
> + (gdata->revision >> 8)
Make all those inline functions.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1714563.qChlbIjNcO@avalon>
Hi Laurent,
On Thu, Apr 20, 2017 at 12:42 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
>> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
>> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> >> - The following devices no longer exist on ES2.0, and are thus removed:
>> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> >>
>> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> >> "vsps" property from the DU node until the driver can handle this.
>> >
>> > I think I'll need a different compatible string between ES1.x and ES2 for
>> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We
>> > can decide about that later when I'll have a DU driver prototype ready.
>>
>> Why would you need a different compatible string?
>> Can't you use soc_device_match() to handle ES1.x SoCs?
>>
>> The different DU <-> VSPD topology is handled through the vsps property in
>> DTS. Are the ports different, too? That can be handled in DTS.
>
> My point (not expressed clearly) was that, as I'll need a different vsps
> property, I can as well go for a different compatible string.
Do you need a different vsps property?
AFAIK, the current array links each DU channel to a VSPD.
When a VSPD is shared between multiple channels, you can still link these
channels to the same VSPD.
Or is my understanding incorrect?
>> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS
>> refers to it. Sharing board DTS means there needs to be at least a
>> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
>> shuffling board overrides around.
>
> As the ports are identical it makes sense to share the same board DTS, I agree
> with you. We could override the compatible string in r8a7795-es1.dtsi and
> leave it blank in r8a7795.dtsi for now, as there's no driver support for
> ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether
> driver support is available or not. On the other hand, leaving the vsps
> property out is a workaround too.
>
> The current driver will fail probing if the number of VSPs is different than
> the number of CRTCs, so I believe you can keep the vsps property in
> r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT
> bindings for the H3 ES2.0 DU yet, so we would end up merging DT without
> bindings, which is not good. I think that regardless of how we proceed,
> keeping the DU node in the ES2.0 .dtsi will be a violation of that policy.
What does the current driver do if the number of VSPs is the same as the
number of CRTCs, but some VSPs are listed more than once?
I guess it will break in a subtle way, instead of refusing to probe?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V5 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 316dc713268c..d83bf789c864 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -118,27 +118,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <500000>;
};
- opp at 648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
clock-latency-ns = <500000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <500000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <500000>;
};
- opp at 1188000000 {
+ opp-1188000000 {
opp-hz = /bits/ 64 <1188000000>;
clock-latency-ns = <500000>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 6/7] ARM: uniphier: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/uniphier-pro5.dtsi | 32 ++++++++++++------------
arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 ++++++------
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 +++++------
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 ++++++++++++------------
4 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi
index df07b555cbed..81605e3a5e0a 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -77,67 +77,67 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
clock-latency-ns = <300>;
};
- opp at 116667000 {
+ opp-116667000 {
opp-hz = /bits/ 64 <116667000>;
clock-latency-ns = <300>;
};
- opp at 150000000 {
+ opp-150000000 {
opp-hz = /bits/ 64 <150000000>;
clock-latency-ns = <300>;
};
- opp at 175000000 {
+ opp-175000000 {
opp-hz = /bits/ 64 <175000000>;
clock-latency-ns = <300>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
clock-latency-ns = <300>;
};
- opp at 233334000 {
+ opp-233334000 {
opp-hz = /bits/ 64 <233334000>;
clock-latency-ns = <300>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
clock-latency-ns = <300>;
};
- opp at 350000000 {
+ opp-350000000 {
opp-hz = /bits/ 64 <350000000>;
clock-latency-ns = <300>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
clock-latency-ns = <300>;
};
- opp at 466667000 {
+ opp-466667000 {
opp-hz = /bits/ 64 <466667000>;
clock-latency-ns = <300>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
clock-latency-ns = <300>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
clock-latency-ns = <300>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <300>;
};
- opp at 933334000 {
+ opp-933334000 {
opp-hz = /bits/ 64 <933334000>;
clock-latency-ns = <300>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <300>;
};
- opp at 1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 58c3e2f35706..bc5a1afedee8 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -97,35 +97,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
clock-latency-ns = <300>;
};
- opp at 150000000 {
+ opp-150000000 {
opp-hz = /bits/ 64 <150000000>;
clock-latency-ns = <300>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
clock-latency-ns = <300>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
clock-latency-ns = <300>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
clock-latency-ns = <300>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
clock-latency-ns = <300>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <300>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 151c043b4835..4beb67b4535c 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -89,31 +89,31 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 245000000 {
+ opp-245000000 {
opp-hz = /bits/ 64 <245000000>;
clock-latency-ns = <300>;
};
- opp at 250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp at 490000000 {
+ opp-490000000 {
opp-hz = /bits/ 64 <490000000>;
clock-latency-ns = <300>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp at 653334000 {
+ opp-653334000 {
opp-hz = /bits/ 64 <653334000>;
clock-latency-ns = <300>;
};
- opp at 666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp at 980000000 {
+ opp-980000000 {
opp-hz = /bits/ 64 <980000000>;
clock-latency-ns = <300>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 6193f11acb78..adde6a10de20 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -116,35 +116,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp at 275000000 {
+ opp-275000000 {
opp-hz = /bits/ 64 <275000000>;
clock-latency-ns = <300>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp at 550000000 {
+ opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
clock-latency-ns = <300>;
};
- opp at 666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp at 733334000 {
+ opp-733334000 {
opp-hz = /bits/ 64 <733334000>;
clock-latency-ns = <300>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <300>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
clock-latency-ns = <300>;
};
@@ -154,35 +154,35 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 250000000 {
+ opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
clock-latency-ns = <300>;
};
- opp at 275000000 {
+ opp-275000000 {
opp-hz = /bits/ 64 <275000000>;
clock-latency-ns = <300>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <300>;
};
- opp at 550000000 {
+ opp-550000000 {
opp-hz = /bits/ 64 <550000000>;
clock-latency-ns = <300>;
};
- opp at 666667000 {
+ opp-666667000 {
opp-hz = /bits/ 64 <666667000>;
clock-latency-ns = <300>;
};
- opp at 733334000 {
+ opp-733334000 {
opp-hz = /bits/ 64 <733334000>;
clock-latency-ns = <300>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <300>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
clock-latency-ns = <300>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 ++--
arch/arm/boot/dts/sun8i-a33.dtsi | 30 +++++++++++++-------------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 9b620cc1d5f1..8a0b42a2c2da 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -88,13 +88,13 @@
};
&cpu0_opp_table {
- opp at 1104000000 {
+ opp-1104000000 {
opp-hz = /bits/ 64 <1104000000>;
opp-microvolt = <1320000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1320000>;
clock-latency-ns = <244144>; /* 8 32k periods */
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 61de52b9940d..6a33f840d981 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -50,73 +50,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 120000000 {
+ opp-120000000 {
opp-hz = /bits/ 64 <120000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 240000000 {
+ opp-240000000 {
opp-hz = /bits/ 64 <240000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 312000000 {
+ opp-312000000 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 408000000 {
+ opp-408000000 {
opp-hz = /bits/ 64 <408000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 480000000 {
+ opp-480000000 {
opp-hz = /bits/ 64 <480000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 504000000 {
+ opp-504000000 {
opp-hz = /bits/ 64 <504000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
opp-microvolt = <1040000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 720000000 {
+ opp-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1100000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 816000000 {
+ opp-816000000 {
opp-hz = /bits/ 64 <816000000>;
opp-microvolt = <1100000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 912000000 {
+ opp-912000000 {
opp-hz = /bits/ 64 <912000000>;
opp-microvolt = <1200000>;
clock-latency-ns = <244144>; /* 8 32k periods */
};
- opp at 1008000000 {
+ opp-1008000000 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1200000>;
clock-latency-ns = <244144>; /* 8 32k periods */
@@ -164,15 +164,15 @@
mali_opp_table: gpu-opp-table {
compatible = "operating-points-v2";
- opp at 144000000 {
+ opp-144000000 {
opp-hz = /bits/ 64 <144000000>;
};
- opp at 240000000 {
+ opp-240000000 {
opp-hz = /bits/ 64 <240000000>;
};
- opp at 384000000 {
+ opp-384000000 {
opp-hz = /bits/ 64 <384000000>;
};
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm/boot/dts/pxa25x.dtsi | 8 ++++----
arch/arm/boot/dts/pxa27x.dtsi | 14 +++++++-------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
index f9f4726396a0..95d59be97213 100644
--- a/arch/arm/boot/dts/pxa25x.dtsi
+++ b/arch/arm/boot/dts/pxa25x.dtsi
@@ -93,22 +93,22 @@
pxa250_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp at 99532800 {
+ opp-99532800 {
opp-hz = /bits/ 64 <99532800>;
opp-microvolt = <1000000 950000 1650000>;
clock-latency-ns = <20>;
};
- opp at 199065600 {
+ opp-199065600 {
opp-hz = /bits/ 64 <199065600>;
opp-microvolt = <1000000 950000 1650000>;
clock-latency-ns = <20>;
};
- opp at 298598400 {
+ opp-298598400 {
opp-hz = /bits/ 64 <298598400>;
opp-microvolt = <1100000 1045000 1650000>;
clock-latency-ns = <20>;
};
- opp at 398131200 {
+ opp-398131200 {
opp-hz = /bits/ 64 <398131200>;
opp-microvolt = <1300000 1235000 1650000>;
clock-latency-ns = <20>;
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index e0fab48ba6fa..5f1d6da02a4c 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -141,37 +141,37 @@
pxa270_opp_table: opp_table0 {
compatible = "operating-points-v2";
- opp at 104000000 {
+ opp-104000000 {
opp-hz = /bits/ 64 <104000000>;
opp-microvolt = <900000 900000 1705000>;
clock-latency-ns = <20>;
};
- opp at 156000000 {
+ opp-156000000 {
opp-hz = /bits/ 64 <156000000>;
opp-microvolt = <1000000 1000000 1705000>;
clock-latency-ns = <20>;
};
- opp at 208000000 {
+ opp-208000000 {
opp-hz = /bits/ 64 <208000000>;
opp-microvolt = <1180000 1180000 1705000>;
clock-latency-ns = <20>;
};
- opp at 312000000 {
+ opp-312000000 {
opp-hz = /bits/ 64 <312000000>;
opp-microvolt = <1250000 1250000 1705000>;
clock-latency-ns = <20>;
};
- opp at 416000000 {
+ opp-416000000 {
opp-hz = /bits/ 64 <416000000>;
opp-microvolt = <1350000 1350000 1705000>;
clock-latency-ns = <20>;
};
- opp at 520000000 {
+ opp-520000000 {
opp-hz = /bits/ 64 <520000000>;
opp-microvolt = <1450000 1450000 1705000>;
clock-latency-ns = <20>;
};
- opp at 624000000 {
+ opp-624000000 {
opp-hz = /bits/ 64 <624000000>;
opp-microvolt = <1550000 1550000 1705000>;
clock-latency-ns = <20>;
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
9 files changed, 194 insertions(+), 194 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d085ef90d27c..f8e946471a58 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -202,23 +202,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
@@ -292,23 +292,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -318,19 +318,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
@@ -339,19 +339,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
@@ -360,13 +360,13 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 9c28ef4508e0..590ee442d0ae 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -745,23 +745,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
@@ -835,23 +835,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -861,19 +861,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
@@ -882,19 +882,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
@@ -903,13 +903,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 80000000 {
+ opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index e6e62103a71f..768fb075b1fd 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -343,15 +343,15 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1025000>;
};
- opp at 267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1050000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1150000>;
};
@@ -361,13 +361,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
@@ -376,10 +376,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 5000000 {
+ opp-5000000 {
opp-hz = /bits/ 64 <5000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -388,10 +388,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 10000000 {
+ opp-10000000 {
opp-hz = /bits/ 64 <10000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
};
@@ -400,13 +400,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
};
@@ -415,13 +415,13 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-prime.dtsi b/arch/arm/boot/dts/exynos4412-prime.dtsi
index e75bc170c89c..a67bd953d754 100644
--- a/arch/arm/boot/dts/exynos4412-prime.dtsi
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -20,12 +20,12 @@
};
&cpu0_opp_table {
- opp at 1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
};
- opp at 1704000000 {
+ opp-1704000000 {
opp-hz = /bits/ 64 <1704000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index cc69466f17c0..7ff03a7e8fb9 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -76,73 +76,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <200000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <925000>;
clock-latency-ns = <200000>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <950000>;
clock-latency-ns = <200000>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <975000>;
clock-latency-ns = <200000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <987500>;
clock-latency-ns = <200000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <200000>;
opp-suspend;
};
- opp at 900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <200000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1087500>;
clock-latency-ns = <200000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <200000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1187500>;
clock-latency-ns = <200000>;
};
- opp at 1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <200000>;
};
- opp at 1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- cpu0_opp_1500: opp at 1500000000 {
+ cpu0_opp_1500: opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
@@ -442,23 +442,23 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <900000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <900000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <900000>;
};
- opp at 267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <950000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1050000>;
};
@@ -468,16 +468,16 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp at 267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
};
@@ -534,19 +534,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <900000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <925000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <950000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
@@ -556,10 +556,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
};
@@ -568,10 +568,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
};
@@ -580,10 +580,10 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 50000000 {
+ opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 83b3899d228d..0db0bcf8da36 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -49,62 +49,62 @@
cluster_a15_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
- opp at 1800000000 {
+ opp-1800000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <1250000>;
clock-latency-ns = <140000>;
};
- opp at 1700000000 {
+ opp-1700000000 {
opp-hz = /bits/ 64 <1700000000>;
opp-microvolt = <1212500>;
clock-latency-ns = <140000>;
};
- opp at 1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1175000>;
clock-latency-ns = <140000>;
};
- opp at 1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1137500>;
clock-latency-ns = <140000>;
};
- opp at 1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1112500>;
clock-latency-ns = <140000>;
};
- opp at 1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1062500>;
clock-latency-ns = <140000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1037500>;
clock-latency-ns = <140000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1012500>;
clock-latency-ns = <140000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = < 987500>;
clock-latency-ns = <140000>;
};
- opp at 900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = < 962500>;
clock-latency-ns = <140000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = < 937500>;
clock-latency-ns = <140000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = < 912500>;
clock-latency-ns = <140000>;
@@ -114,42 +114,42 @@
cluster_a7_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
- opp at 1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1275000>;
clock-latency-ns = <140000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1212500>;
clock-latency-ns = <140000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1162500>;
clock-latency-ns = <140000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1112500>;
clock-latency-ns = <140000>;
};
- opp at 900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1062500>;
clock-latency-ns = <140000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <140000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <975000>;
clock-latency-ns = <140000>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <937500>;
clock-latency-ns = <140000>;
diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi
index 8213016803e5..9ddb6bacac5a 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -24,60 +24,60 @@
};
&cluster_a15_opp_table {
- opp at 1700000000 {
+ opp-1700000000 {
opp-microvolt = <1250000>;
};
- opp at 1600000000 {
+ opp-1600000000 {
opp-microvolt = <1250000>;
};
- opp at 1500000000 {
+ opp-1500000000 {
opp-microvolt = <1100000>;
};
- opp at 1400000000 {
+ opp-1400000000 {
opp-microvolt = <1100000>;
};
- opp at 1300000000 {
+ opp-1300000000 {
opp-microvolt = <1100000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-microvolt = <1000000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-microvolt = <1000000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-microvolt = <1000000>;
};
- opp at 900000000 {
+ opp-900000000 {
opp-microvolt = <1000000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-microvolt = <900000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-microvolt = <900000>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
@@ -85,46 +85,46 @@
};
&cluster_a7_opp_table {
- opp at 1300000000 {
+ opp-1300000000 {
opp-microvolt = <1250000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-microvolt = <1250000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-microvolt = <1250000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-microvolt = <1100000>;
};
- opp at 900000000 {
+ opp-900000000 {
opp-microvolt = <1100000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-microvolt = <1100000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-microvolt = <1000000>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-microvolt = <1000000>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <140000>;
};
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <140000>;
};
- opp at 300000000 {
+ opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <900000>;
clock-latency-ns = <140000>;
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
index c42dc39c3223..ec11343dc528 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
@@ -94,27 +94,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1075000>;
};
- opp at 267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-microvolt = <1000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <975000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <962500>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <950000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <937500>;
};
@@ -123,19 +123,19 @@
bus_g2d_266_opp_table: opp_table3 {
compatible = "operating-points-v2";
- opp at 267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -143,13 +143,13 @@
bus_gscl_opp_table: opp_table4 {
compatible = "operating-points-v2";
- opp at 333000000 {
+ opp-333000000 {
opp-hz = /bits/ 64 <333000000>;
};
- opp at 222000000 {
+ opp-222000000 {
opp-hz = /bits/ 64 <222000000>;
};
- opp at 166500000 {
+ opp-166500000 {
opp-hz = /bits/ 64 <166500000>;
};
};
@@ -158,22 +158,22 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp at 267000000 {
+ opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 160000000 {
+ opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
@@ -181,16 +181,16 @@
bus_noc2_opp_table: opp_table6 {
compatible = "operating-points-v2";
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
- opp at 200000000 {
+ opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
- opp at 134000000 {
+ opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
};
- opp at 100000000 {
+ opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 16072c1c3ed3..727f36abf3d4 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -119,43 +119,43 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 400000000 {
+ opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <900000>;
};
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <925000>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <950000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <975000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1000000>;
};
- opp at 900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <1050000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1075000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1112500>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1112500>;
};
- opp at 1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1150000>;
};
@@ -165,63 +165,63 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <900000>;
};
- opp at 600000000 {
+ opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <900000>;
};
- opp at 700000000 {
+ opp-700000000 {
opp-hz = /bits/ 64 <700000000>;
opp-microvolt = <912500>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <912500>;
};
- opp at 900000000 {
+ opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <937500>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000>;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1012500>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1037500>;
};
- opp at 1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1062500>;
};
- opp at 1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1087500>;
};
- opp at 1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1125000>;
};
- opp at 1600000000 {
+ opp-1600000000 {
opp-hz = /bits/ 64 <1600000000>;
opp-microvolt = <1137500>;
};
- opp at 1700000000 {
+ opp-1700000000 {
opp-hz = /bits/ 64 <1700000000>;
opp-microvolt = <1175000>;
};
- opp at 1800000000 {
+ opp-1800000000 {
opp-hz = /bits/ 64 <1800000000>;
opp-microvolt = <1212500>;
};
- opp at 1900000000 {
+ opp-1900000000 {
opp-hz = /bits/ 64 <1900000000>;
opp-microvolt = <1262500>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 2/7] ARM: TI: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Tony Lindgren <tony@atomide.com>
---
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 ++++++++++----------
arch/arm/boot/dts/am335x-boneblack.dts | 2 +-
arch/arm/boot/dts/am33xx.dtsi | 20 ++++++++++----------
arch/arm/boot/dts/am4372.dtsi | 10 +++++-----
arch/arm/boot/dts/dra7.dtsi | 4 ++--
5 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
index ba0e15ad5bd9..0c38e4b8fc51 100644
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -63,64 +63,64 @@ cpu0_opp_table: opp-table {
* because they can not be enabled simultaneously on a
* single SoC.
*/
- opp50 at 300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
- opp100 at 275000000 {
+ opp100-275000000 {
opp-hz = /bits/ 64 <275000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
- opp100 at 300000000 {
+ opp100-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
- opp100 at 500000000 {
+ opp100-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp100 at 600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
- opp120 at 600000000 {
+ opp120-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp120 at 720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
- oppturbo at 720000000 {
+ oppturbo-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x01 0xFFFF>;
};
- oppturbo at 800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
- oppnitro at 1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 935ed17d22e4..d154d3133c16 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -22,7 +22,7 @@
* BeagleBone Blacks have PG 2.0 silicon which is guaranteed
* to support 1GHz OPP so enable it for PG 2.0 on this board.
*/
- oppnitro at 1000000000 {
+ oppnitro-1000000000 {
opp-supported-hw = <0x06 0x0100>;
};
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9e242943dcec..bdacb3dd689c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -64,64 +64,64 @@
* because the can not be enabled simultaneously on a
* single SoC.
*/
- opp50 at 300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
- opp100 at 275000000 {
+ opp100-275000000 {
opp-hz = /bits/ 64 <275000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
- opp100 at 300000000 {
+ opp100-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
- opp100 at 500000000 {
+ opp100-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp100 at 600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
- opp120 at 600000000 {
+ opp120-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x01 0xFFFF>;
};
- opp120 at 720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
- oppturbo at 720000000 {
+ oppturbo-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x01 0xFFFF>;
};
- oppturbo at 800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
- oppnitro at 1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 176e09e9a45e..e5b061469bf8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -59,32 +59,32 @@
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
- opp50 at 300000000 {
+ opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0xFF 0x01>;
opp-suspend;
};
- opp100 at 600000000 {
+ opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0xFF 0x04>;
};
- opp120 at 720000000 {
+ opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0xFF 0x08>;
};
- oppturbo at 800000000 {
+ oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0xFF 0x10>;
};
- oppnitro at 1000000000 {
+ oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0xFF 0x20>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 57892f264cea..25908dd338ee 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -99,14 +99,14 @@
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_wkup>;
- opp_nom at 1000000000 {
+ opp_nom-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1060000 850000 1150000>;
opp-supported-hw = <0xFF 0x01>;
opp-suspend;
};
- opp_od at 1176000000 {
+ opp_od-1176000000 {
opp-hz = /bits/ 64 <1176000000>;
opp-microvolt = <1160000 885000 1160000>;
opp-supported-hw = <0xFF 0x02>;
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 1/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492685450.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++++++--------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 63725498bd20..e36d261b9ba6 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -186,20 +186,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
compatible = "operating-points-v2";
opp-shared;
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
@@ -265,20 +265,20 @@ independently.
* independently.
*/
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000;
@@ -341,20 +341,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp@1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
- opp at 1100000000 {
+ opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
@@ -367,20 +367,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp at 1300000000 {
+ opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1050000 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
- opp at 1400000000 {
+ opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
- opp at 1500000000 {
+ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1100000 1010000 1110000>;
opp-microamp = <95000>;
@@ -409,7 +409,7 @@ Example 4: Handling multiple regulators
compatible = "operating-points-v2";
opp-shared;
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
@@ -422,7 +422,7 @@ Example 4: Handling multiple regulators
/* OR */
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
@@ -435,7 +435,7 @@ Example 4: Handling multiple regulators
/* OR */
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
@@ -467,7 +467,7 @@ Example 5: opp-supported-hw
status = "okay";
opp-shared;
- opp at 600000000 {
+ opp-600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
@@ -478,7 +478,7 @@ Example 5: opp-supported-hw
...
};
- opp at 800000000 {
+ opp-800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
@@ -510,7 +510,7 @@ Example 5: opp-supported-hw
compatible = "operating-points-v2";
opp-shared;
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt-slow = <915000 900000 925000>;
opp-microvolt-fast = <975000 970000 985000>;
@@ -518,7 +518,7 @@ Example 5: opp-supported-hw
opp-microamp-fast = <71000>;
};
- opp at 1200000000 {
+ opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
<925000 910000 935000>; /* Supply vcc1 */
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V5 0/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
This is rebased over arm-soc/for-next:
commit 6f714927c553 ("ARM: SoC: Document merges")
Platform maintainers shall apply patches touching their code.
V4->V5:
- Rebased on arm-soc/for-next. Couldn't do that on linux-next/master as
it still had the V3 patch via the PM tree (which will be dropped
today).
- Some more OPP entries got the update as they were present only in
next.
V3->V4:
- split it per platform
V2->V3:
- Rebased over 4.11-rc7 and fixed a merge conflict for sun8i.
--
Viresh
Viresh Kumar (7):
PM / OPP: Use - instead of @ for DT entries
ARM: TI: Use - instead of @ for DT OPP entries
ARM: exynos: Use - instead of @ for DT OPP entries
ARM: pxa: Use - instead of @ for DT OPP entries
ARM: sun8i: Use - instead of @ for DT OPP entries
ARM: uniphier: Use - instead of @ for DT OPP entries
ARM: ZTE: Use - instead of @ for DT OPP entries
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 20 +++----
.../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
Documentation/devicetree/bindings/opp/opp.txt | 38 ++++++-------
arch/arm/boot/dts/am335x-boneblack.dts | 2 +-
arch/arm/boot/dts/am33xx.dtsi | 20 +++----
arch/arm/boot/dts/am4372.dtsi | 10 ++--
arch/arm/boot/dts/dra7.dtsi | 4 +-
arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
arch/arm/boot/dts/pxa25x.dtsi | 8 +--
arch/arm/boot/dts/pxa27x.dtsi | 14 ++---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 +-
arch/arm/boot/dts/sun8i-a33.dtsi | 30 +++++-----
arch/arm/boot/dts/uniphier-pro5.dtsi | 32 +++++------
arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 +++---
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++---
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 +++++------
arch/arm64/boot/dts/zte/zx296718.dtsi | 10 ++--
24 files changed, 321 insertions(+), 321 deletions(-)
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply
* [PATCH v4 02/21] linux/io.h: add PCI config space remap interface
From: Lorenzo Pieralisi @ 2017-04-20 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419164913.19674-3-lorenzo.pieralisi@arm.com>
[+ Michael]
On Wed, Apr 19, 2017 at 05:48:51PM +0100, Lorenzo Pieralisi wrote:
> The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> Posting") mandate non-posted configuration transactions. As further
> highlighted in the PCIe specifications (4.0 - Rev0.3, "Ordering
> Considerations for the Enhanced Configuration Access Mechanism"),
> through ECAM and ECAM-derivative configuration mechanism, the memory
> mapped transactions from the host CPU into Configuration Requests on the
> PCI express fabric may create ordering problems for software because
> writes to memory address are typically posted transactions (unless the
> architecture can enforce through virtual address mapping non-posted
> write transactions behaviour) but writes to Configuration Space are not
> posted on the PCI express fabric.
>
> Current DT and ACPI host bridge controllers map PCI configuration space
> (ECAM and ECAM-derivative) into the virtual address space through
> ioremap() calls, that are non-cacheable device accesses on most
> architectures, but may provide "bufferable" or "posted" write semantics
> in architecture like eg ARM/ARM64 that allow ioremap'ed regions writes
> to be buffered in the bus connecting the host CPU to the PCI fabric;
> this behaviour, as underlined in the PCIe specifications, may trigger
> transactions ordering rules and must be prevented.
>
> Introduce a new generic and explicit API to create a memory
> mapping for ECAM and ECAM-derivative config space area that
> defaults to ioremap_nocache() (which should provide a sane default
> behaviour) but still allowing architectures on which ioremap_nocache()
> results in posted write transactions to override the function
> call with an arch specific implementation that complies with
> the PCI specifications for configuration transactions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> include/linux/io.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/io.h b/include/linux/io.h
> index 82ef36e..3934aba 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -91,6 +91,25 @@ void devm_memunmap(struct device *dev, void *addr);
> void *__devm_memremap_pages(struct device *dev, struct resource *res);
>
> /*
> + * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> + * Posting") mandate non-posted configuration transactions. There is
> + * no ioremap API in the kernel that can guarantee non-posted write
> + * semantics across arches so provide a default implementation for
> + * mapping PCI config space that defaults to ioremap_nocache(); arches
> + * should override it if they have memory mapping implementations that
> + * guarantee non-posted writes semantics to make the memory mapping
> + * compliant with the PCI specification.
> + */
> +#ifndef pci_remap_cfgspace
> +#define pci_remap_cfgspace pci_remap_cfgspace
> +static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
> + size_t size)
> +{
> + return ioremap_nocache(offset, size);
> +}
> +#endif
> +
> +/*
As an heads-up, this patch strictly depends on:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/include/asm/io.h?id=590c369e7ecc00be736be39ae0c62d1b5d563a51
to go upstream first, otherwise we would break powerpc compilation
(owing to powerpc including linux/io.h before ioremap_nocache() is
defined in arch/powerpc/include/asm/io.h).
If we want to decouple them I must drop the static inline and make
it a #define, it is not ideal but we must be aware of this, I really
want to prevent breakage if we go ahead with this set (and -next can
hide the issue).
Thanks,
Lorenzo
> * Some systems do not have legacy ISA devices.
> * /dev/port is not a valid interface on these systems.
> * So for those archs, <asm/io.h> should define the following symbol.
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Laurent Pinchart @ 2017-04-20 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXOzyo+kzaGAXp+jZTtUejYyXCQzezo+SmvNVQuEC9=_Q@mail.gmail.com>
Hi Geert,
On Thursday 20 Apr 2017 11:36:59 Geert Uytterhoeven wrote:
> On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart wrote:
> > On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> >> - The following devices no longer exist on ES2.0, and are thus removed:
> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> >>
> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the
> >> "vsps" property from the DU node until the driver can handle this.
> >
> > I think I'll need a different compatible string between ES1.x and ES2 for
> > the DU. It could make sense to move the whole DU node to *-es1.dtsi. We
> > can decide about that later when I'll have a DU driver prototype ready.
>
> Why would you need a different compatible string?
> Can't you use soc_device_match() to handle ES1.x SoCs?
>
> The different DU <-> VSPD topology is handled through the vsps property in
> DTS. Are the ports different, too? That can be handled in DTS.
My point (not expressed clearly) was that, as I'll need a different vsps
property, I can as well go for a different compatible string.
> The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS
> refers to it. Sharing board DTS means there needs to be at least a
> placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
> shuffling board overrides around.
As the ports are identical it makes sense to share the same board DTS, I agree
with you. We could override the compatible string in r8a7795-es1.dtsi and
leave it blank in r8a7795.dtsi for now, as there's no driver support for
ES2.0. That's a bit of a workaround as it shouldn't matter to DT whether
driver support is available or not. On the other hand, leaving the vsps
property out is a workaround too.
The current driver will fail probing if the number of VSPs is different than
the number of CRTCs, so I believe you can keep the vsps property in
r8a7795.dtsi with 3 VSPS without causing any problem. However, there's no DT
bindings for the H3 ES2.0 DU yet, so we would end up merging DT without
bindings, which is not good. I think that regardless of how we proceed,
keeping the DU node in the ES2.0 .dtsi will be a violation of that policy.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 03/21] ARM64: implement pci_remap_cfgspace() interface
From: Catalin Marinas @ 2017-04-20 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419164913.19674-4-lorenzo.pieralisi@arm.com>
On Wed, Apr 19, 2017 at 05:48:52PM +0100, Lorenzo Pieralisi wrote:
> The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering
> and Posting") defines rules for PCI configuration space transactions
> ordering and posting, that state that configuration writes
> are non-posted transactions.
>
> This rule is reinforced by the ARM v8 architecture reference manual
> (issue A.k, Early Write Acknowledgment) that explicitly recommends
> that No Early Write Acknowledgment attribute should be used to map
> PCI configuration (write) transactions.
>
> Current ioremap interface on ARM64 implements mapping functions
> where the Early Write Acknowledgment hint is enabled, so they
> cannot be used to map PCI configuration space in a PCI specs
> compliant way.
>
> Implement an ARM64 specific pci_remap_cfgspace() interface
> that allows to map PCI config region with nGnRnE attributes, providing
> a remap function that complies with PCI specifications and the ARMv8
> architecture reference manual recommendations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] ARM: hyp-stub: Fix Thumb-2 compilation
From: Marc Zyngier @ 2017-04-20 10:16 UTC (permalink / raw)
To: linux-arm-kernel
The assembler defaults to emiting the short form of ADR, leading
to an out-of-range immediate. Using the wide version solves this
issue.
Fixes: bc845e4fbbbb ("ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/kernel/hyp-stub.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index d8523cc47a54..ec7e7377d423 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -125,7 +125,7 @@ ENTRY(__hyp_stub_install_secondary)
* (see safe_svcmode_maskall).
*/
@ Now install the hypervisor stub:
- adr r7, __hyp_stub_vectors
+ W(adr) r7, __hyp_stub_vectors
mcr p15, 4, r7, c12, c0, 0 @ set hypervisor vector base (HVBAR)
@ Disable all traps, so we don't get any nasty surprise
--
2.11.0
^ permalink raw reply related
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Arnd Bergmann @ 2017-04-20 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jLPRYi+HK=07Zndc8szEKD4mZCqaHJFnHmmoYr7tA1xPw@mail.gmail.com>
On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keescook@chromium.org> wrote:
> Was there a conclusion to this discussion? I didn't see anything
> definitive in the thread...
No definite answer, no. My personal view now is that we should probably
merge the patches I sent, to help those that for one reason or another
use one of those ancient toolchains, but we should not go actively looking
for more problems with those compilers.
> On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> [Fixed linux-arm-kernel mailing list address, sorry for the duplicate,
>> I'm not reposting all the ugly patches though, unless someone really
>> wants them, https://lkml.org/lkml/2016/12/16/174 has a copy]
>>
>> On Friday, December 16, 2016 11:56:21 AM CET Arnd Bergmann wrote:
>>> I had some fun doing build testing with older gcc versions, building
>>> every release from 4.0 through 7.0 and running that on my randconfig
>>> setup to see what comes out.
>>>
>>> First of all, gcc-4.9 and higher is basically warning-free everywhere,
>>> although gcc-7 introduces some interesting new warnings (I have started
>>> doing patches for those as well). gcc-4.8 is probably good, too, and
>>> gcc-4.6 and 4.7 at least don't produce build failures in general, though
>>> the level of false-positive warnings increases (we could decide to turn
>>> those off for older compilers for build test purposes).
>>>
>>> In gcc-4.5 and below, dead code elimination is not as good as later,
>>> causing a couple of link errors, and some of them have no good workaround
>>> (see patch 1). It would be nice to declare that version too old, but
>>> several older distros that are still in wide use ship with compilers
>>> earlier than 4.6:
>>>
>>> RHEL6: gcc-4.4
>
> This appears to have support until July 31, 2018. (Though it's using a
> 2.6 kernel.)
>
>>> Debian 6: gcc-4.4
>
> This went fully unsupported on Feb 29, 2016.
>
>>> Ubuntu 10.04: gcc-4.4
>
> This went fully unsupported on Apr 30, 2015.
>
>>> SLES11: gcc-4.3
>
> General support ends Mar 31 2019, fully unsupported 31 Mar 2022. (And
> like RHEL6 is using a 2.6 kernel.)
Thanks for looking these up. This means we need to consider how important
build testing on SLES11 is to us in the long run. The most important scenario
I can think of for anyone would be someone that maintains an embedded
system with an x86 CPU and uses a SLES11 setup to maintain their
own distro.
In this case you typically don't want to modify your environment, but
one might want to upgrade the target kernel, and would suffer if
we break that.
>>>
>>> I have not checked in detail which version is required for
>>> each of the above.
>>>
>>> Specifically on ARM, going further makes things rather useless especially
>>> for build testing: with gcc-4.2, we lose support for ARMv7, EABI, and
>>> effectively ARMv6 (as it relies on EABI for building reliably). Also,
>>> the number of false-positive build warnings is so high that it is useless
>>> for finding actual bugs from the warnings.
>>>
>>> See the replies to this mail for 13 patches I needed to work around
>>> issues for each of the releases before 4.6. I have also submitted
>>> some separate patches for issues that I considered actual bugs
>>> uncovered by the older compilers and that should be applied regardless.
>>>
>>> The original gcc-4.3 release was in early 2008. If we decide to still
>>> support that, we probably want the first 10 quirks in this series,
>>> while gcc-4.6 (released in 2011) requires none of them.
>
> I'd be in support of raising the minimum to gcc 4.6. (I'd actually
> prefer 4.7, just to avoid some 4.6 packaging issues, and for better
> gcc plugin support.)
>
> I'm curious what gcc 4.6 binaries are common in the wild besides
> old-stable Debian (unsupported in maybe a year from now?) and 12.04
> Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was
> used only in Fedora 15 and 16 (both EOL).
I think we are better off defining two versions: One that we know
a lot of people care about, and we actively try to make that work
well in all configurations (e.g. 4.6, 4.7 or 4.8), fixing all warnings
we run into, and an older version that we try not to break
intentionally (e.g. 3.4, 4.1 or 4.3) but that we only fix when
someone actually runs into a problem they can't work around
by upgrading to a more modern compiler.
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