* [PATCH v3 03/21] ARM: dts: omap: Add generic compatible string for I2C EEPROM
From: Rob Herring @ 2017-04-19 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414010445.21727-4-javier@osg.samsung.com>
On Thu, Apr 13, 2017 at 10:04:27PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/am335x-baltos.dtsi | 2 +-
> arch/arm/boot/dts/am335x-base0033.dts | 2 +-
> arch/arm/boot/dts/am335x-bone-common.dtsi | 10 +++++-----
> arch/arm/boot/dts/am335x-nano.dts | 2 +-
> arch/arm/boot/dts/am335x-pepper.dts | 2 +-
> arch/arm/boot/dts/am335x-shc.dts | 2 +-
> arch/arm/boot/dts/am335x-sl50.dts | 2 +-
> arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
> arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
> arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
> arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 2 +-
> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> arch/arm/boot/dts/omap3-sb-t35.dtsi | 2 +-
> arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 +-
> arch/arm/boot/dts/omap5-cm-t54.dts | 2 +-
> arch/arm/boot/dts/omap5-sbc-t54.dts | 2 +-
> 17 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
> index d42b98f15e8b..6ca780d0623f 100644
> --- a/arch/arm/boot/dts/am335x-baltos.dtsi
> +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
> @@ -255,7 +255,7 @@
> };
>
> at24 at 50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02", "atmel,24c02";
I think you can just drop the at24 compatibles. A new kernel doesn't
need it. An old kernel ignores the manufacturer. I checked that u-boot
only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
couldn't find anything.
Minimally, the deprecated compatible should come last.
Rob
^ permalink raw reply
* [PATCH v3 00/21] eeprom: at24: Add OF device ID table
From: Rob Herring @ 2017-04-20 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
On Thu, Apr 13, 2017 at 10:04:24PM -0300, Javier Martinez Canillas wrote:
> Hello Wolfram,
>
> This series is a follow-up to patch [0] that added an OF device ID table
> to the at24 EEPROM driver. As you suggested [1], this version instead of
> adding entries for every used <vendor,device> tuple, only adds a single
> entry for each chip type using the "atmel" vendor as a generic fallback.
>
> The first patch adds the OF device ID table for the at24 driver and the
> next patches adds a generic fallback compatible string to each DTS that
> defines a compatible I2C EEPROM device node.
>
> Patches can be applied independently since the DTS change without the
> driver change is a no-op and the OF device table won't be used without
> the DTS changes.
>
> [0]: https://lkml.org/lkml/2017/3/14/589
I don't have this patch in my inbox, but the i2c core will still match
on compatibles with no vendor prefix? If not, those need to be added to
the match table too.
Rob
^ permalink raw reply
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jon Masters @ 2017-04-20 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <baed1ecf-7a57-0229-42b0-d87599a225b5@redhat.com>
One additional footnote. I spent a bunch of time recently on my personal
Xeon systems walking through the PCIe topology and aligning on how to
advise the ARM server community proceed going forward. If you look at
how Intel vs AMD handle their host bridges for example, you'll see two
very different approaches to the case of cross-socket PCIe. But my
operating assumption is that anything longer term which looks boring and
x86 enough is probably fine from an ARM server point of view.
On 04/19/2017 07:38 PM, Jon Masters wrote:
> Hi Bjorn, JC,
>
> On 04/13/2017 08:19 PM, Bjorn Helgaas wrote:
>
>> I tentatively applied both patches to pci/host-thunder for v4.12.
>
> Thanks for that :)
>
>> However, I am concerned about the topology here:
>
> Various feedback has been provided on this one over the past $time. In
> addition, I have requested that this serve as an example of why we need
> a more complete PCIe integration guide for ARMv8. It's on the list of
> things for my intended opus magnum on the topic ;)
>
>> On Thu, Apr 13, 2017 at 08:30:45PM +0000, Jayachandran C wrote:
>>> On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the
>>> PCI topology is slightly unusual. For a multi-node system, it looks
>>> like:
>>>
>>> 00:00.0 [PCI] bridge to [bus 01-1e]
>>> 01:0a.0 [PCI-PCIe bridge, type 8] bridge to [bus 02-04]
>>> 02:00.0 [PCIe root port, type 4] bridge to [bus 03-04] (XLATE_ROOT)
>>> 03:00.0 PCIe Endpoint
>>
>> A root port normally has a single PCIe link leading downstream.
>
> In integration terms, there's always a bus on the other side of the RC.
> It's just usually a processor local bus of some kind on a proprietary
> interconnect, but there's always something there. The issue is when you
> can see it as PCIe and it's not through a transparent glue bridge.
>
> I had originally hoped that the ECAM could be hacked up so that we would
> first walk the topology at the 02:00.0 as a root and not see what's
> above it BUT there are other device attachments up there for the on-SoC
> devices and I think we really intend to use those.
>
> Bottom line in my opinion is document this case, use it as a learning
> example, and move forward. This has been useful in justifying why we
> need better integration documentation from the server community. And in
> particular from the OS vendors, of which I guess we can allude to their
> being more than Linux interested in ARM server these days ;)
>
> Jon.
>
--
Computer Architect | Sent from my Fedora powered Ryzen
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-20 0:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in:
arch/arm/boot/dts/sun8i-a33.dtsi
between commits:
66c373228dc4 ("ARM: sun8i: a33: Add the Mali OPPs")
e6bd37627e92 ("ARM: sun8i: a33: add all operating points")
from the arm-soc tree and commit:
d87bd1942058 ("PM / OPP: Use - instead of @ for DT entries")
from the pm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
I suspect that arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts may need
some fixups as well.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/sun8i-a33.dtsi
index 013978259372,a2c555d6475c..000000000000
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@@ -50,73 -49,19 +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 */
@@@ -156,27 -100,6 +156,27 @@@
status = "disabled";
};
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&ths>;
+ };
+
+ 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>;
+ };
+ };
+
memory {
reg = <0x40000000 0x80000000>;
};
^ permalink raw reply
* [v4.9-rt PATCH v2] ARM: mm: remove tasklist locking from update_sections_early()
From: Laura Abbott @ 2017-04-20 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419201047.31578-1-grygorii.strashko@ti.com>
On 04/19/2017 01:10 PM, Grygorii Strashko wrote:
> The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA
> option enabled:
>
> BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:993
> in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
> 1 lock held by migration/0/14:
> #0: (tasklist_lock){+.+...}, at: [<c01183e8>] update_sections_early+0x24/0xdc
> irq event stamp: 38
> hardirqs last enabled at (37): [<c08f6f7c>] _raw_spin_unlock_irq+0x24/0x68
> hardirqs last disabled at (38): [<c01fdfe8>] multi_cpu_stop+0xd8/0x138
> softirqs last enabled at (0): [<c01303ec>] copy_process.part.5+0x238/0x1b64
> softirqs last disabled at (0): [< (null)>] (null)
> Preemption disabled at: [<c01fe244>] cpu_stopper_thread+0x80/0x10c
> CPU: 0 PID: 14 Comm: migration/0 Not tainted 4.9.21-rt16-02220-g49e319c #15
> Hardware name: Generic DRA74X (Flattened Device Tree)
> [<c0112014>] (unwind_backtrace) from [<c010d370>] (show_stack+0x10/0x14)
> [<c010d370>] (show_stack) from [<c049beb8>] (dump_stack+0xa8/0xd4)
> [<c049beb8>] (dump_stack) from [<c01631a0>] (___might_sleep+0x1bc/0x2ac)
> [<c01631a0>] (___might_sleep) from [<c08f7244>] (__rt_spin_lock+0x1c/0x30)
> [<c08f7244>] (__rt_spin_lock) from [<c08f77a4>] (rt_read_lock+0x54/0x68)
> [<c08f77a4>] (rt_read_lock) from [<c01183e8>] (update_sections_early+0x24/0xdc)
> [<c01183e8>] (update_sections_early) from [<c01184b0>] (__fix_kernmem_perms+0x10/0x1c)
> [<c01184b0>] (__fix_kernmem_perms) from [<c01fe010>] (multi_cpu_stop+0x100/0x138)
> [<c01fe010>] (multi_cpu_stop) from [<c01fe24c>] (cpu_stopper_thread+0x88/0x10c)
> [<c01fe24c>] (cpu_stopper_thread) from [<c015edc4>] (smpboot_thread_fn+0x174/0x31c)
> [<c015edc4>] (smpboot_thread_fn) from [<c015a988>] (kthread+0xf0/0x108)
> [<c015a988>] (kthread) from [<c0108818>] (ret_from_fork+0x14/0x3c)
> Freeing unused kernel memory: 1024K (c0d00000 - c0e00000)
>
> The stop_machine() is called with cpus = NULL from fix_kernmem_perms() and
> mark_rodata_ro() which means only one CPU will execute
> update_sections_early() while all other CPUs will spin and wait. Hence,
> it's safe to remove tasklist locking from update_sections_early(). As part
> of this change also mark functions which are local to this module as
> static
Acked-by: Laura Abbott <labbott@redhat.com>
>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Laura Abbott <labbott@redhat.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> As I've checked it also can be applied to LKML as is.
>
> Changes in v2:
> - added comment to update_sections_early()
>
> v1: https://patchwork.kernel.org/patch/9686289/
>
> arch/arm/mm/init.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 370581a..838f6b35 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -689,34 +689,37 @@ void set_section_perms(struct section_perm *perms, int n, bool set,
>
> }
>
> +/**
> + * update_sections_early intended to be called only through stop_machine
> + * framework and executed by only one CPU while all other CPUs will spin and
> + * wait, so no locking is required in this function.
> + */
> static void update_sections_early(struct section_perm perms[], int n)
> {
> struct task_struct *t, *s;
>
> - read_lock(&tasklist_lock);
> for_each_process(t) {
> if (t->flags & PF_KTHREAD)
> continue;
> for_each_thread(t, s)
> set_section_perms(perms, n, true, s->mm);
> }
> - read_unlock(&tasklist_lock);
> set_section_perms(perms, n, true, current->active_mm);
> set_section_perms(perms, n, true, &init_mm);
> }
>
> -int __fix_kernmem_perms(void *unused)
> +static int __fix_kernmem_perms(void *unused)
> {
> update_sections_early(nx_perms, ARRAY_SIZE(nx_perms));
> return 0;
> }
>
> -void fix_kernmem_perms(void)
> +static void fix_kernmem_perms(void)
> {
> stop_machine(__fix_kernmem_perms, NULL, NULL);
> }
>
> -int __mark_rodata_ro(void *unused)
> +static int __mark_rodata_ro(void *unused)
> {
> update_sections_early(ro_perms, ARRAY_SIZE(ro_perms));
> return 0;
>
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Rafael J. Wysocki @ 2017-04-20 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420103427.62fbf195@canb.auug.org.au>
On Thursday, April 20, 2017 10:34:27 AM Stephen Rothwell wrote:
> Hi Rafael,
>
> Today's linux-next merge of the pm tree got a conflict in:
>
> arch/arm/boot/dts/sun8i-a33.dtsi
>
> between commits:
>
> 66c373228dc4 ("ARM: sun8i: a33: Add the Mali OPPs")
> e6bd37627e92 ("ARM: sun8i: a33: add all operating points")
>
> from the arm-soc tree and commit:
>
> d87bd1942058 ("PM / OPP: Use - instead of @ for DT entries")
>
> from the pm tree.
Thanks for the report!
I'm going to drop the conflicting commit tomorrow.
Thanks,
Rafael
^ permalink raw reply
* linux-next: manual merge of the crypto tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-20 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the crypto tree got a conflict in:
arch/arm/boot/dts/stm32746g-eval.dts
between commit:
4cc627472cd6 ("ARM: dts: stm32: enable RTC on stm32746g-eval")
from the arm-soc tree and commit:
2e3db2931875 ("ARM: dts: stm32: enable CRC on stm32746g-eval board")
from the crypto tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/stm32746g-eval.dts
index b5207588bdcb,0dc18a0f0940..000000000000
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@@ -89,10 -89,10 +89,14 @@@
clock-frequency = <25000000>;
};
+ &crc {
+ status = "okay";
+ };
+
+&rtc {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
^ permalink raw reply
* [arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top"
From: Tan Xiaojun @ 2017-04-20 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419114935.GE27829@leverpostej>
On 2017/4/19 19:49, Mark Rutland wrote:
> Hi,
>
> Ard, this sseems to be a nomap issue. Please see below.
>
> Xiaojun, for some reason, the first message in this thread didn't seem
> to make it to LAKML (or to me). In future could you please Cc me for
> emails regarding perf on arm/arm64?
>
Sorry, this is my negligence.
> On Wed, Apr 19, 2017 at 09:44:56AM +0530, Pratyush Anand wrote:
>> On Saturday 15 April 2017 02:18 PM, Tan Xiaojun wrote:
>>> My test server is Hisilicon D03/D05 (arm64).
>>> Kernel source code is 4.11-rc6 (up to date) and config (as an attachment in the end) is generated by defconfig.
>>> (Old version does not seem to have this problem. Linux-4.1 is fine and other versions I have not tested yet.)
>>
>> I tested with mustang(ARM64) and 4.11-rc6 and could not reproduce it.
>>
>>> When I do "perf top" and annotate a random kernel symbol (like vsnprintf or others), the system report an OOPS below:
>>> (The probability of occurrence is very high, almost every time.)
>>>
>>> $ perf top
>>>
>>> Annotate vsnprintf ---- choose it
>>> Zoom into perf(7066) thread
>>> Zoom into the Kernel DSO
>>> Browse map details
>>> Run scripts for samples of thread [perf]
>>> Run scripts for samples of symbol [vsnprintf]
>>> Run scripts for all samples
>>> Exit
>
> Was perf built from the same v4.11-rc6 source tree, or was this an older
> perf binary?
>
No, I had used 4.10-rc7 or some other older perf binary.
At first, I found this problem in kernel-4.10-rc7 + perf-4.10-rc7, and then I tested the other kernel versions.
For now, I use "git bisect" and find the problem maybe between v4.5 and v4.6-rc1.
I will try more and tell you the result.
> With a perf tool built from v4.11-rc6, even with CAP_SYS_RAWIO, I see perf top
> complaining that it it cannot annotate the symbol due to a lack of a vmlinux
> file. I can't seem to convince it to use /proc/kcore.
>
> However, I can reproduce the issue by other means:
>
> # cat /proc/kcore > /dev/null
> [ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
> [ 4544.991995] pgd = ffff80096745f000
> [ 4544.995369] [ffff804392800000] *pgd=0000000000000000
> [ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
> [ 4545.005815] Modules linked in:
> [ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
> [ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
> [ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
> [ 4545.026520] PC is at __memcpy+0x100/0x180
> [ 4545.030491] LR is at vread+0x144/0x280
> [ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
> [ 4545.041530] sp : ffff80097533fcb0
> [ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
> [ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
> [ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
> [ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
> [ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
> [ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
> [ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
> [ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
> [ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
> [ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
> [ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
> [ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
> [ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
> [ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
> [ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
> [ 4545.123745]
> [ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
> [ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
> [ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
> [ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
> [ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
> [ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
> [ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
> [ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
> [ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
> [ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
> [ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
> [ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
> [ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
> [ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
> [ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
> [ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
> [ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
> [ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
> [ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
> [ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
> [ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
> [ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
> [ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
> [ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
> [ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
> [ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
> [ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
> [ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
> [ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 4545.346786] Call trace:
> [ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
> [ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
> [ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
> [ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
> [ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
> [ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
> [ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
> [ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
> [ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
> [ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
> [ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
> [ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
> [ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
> [ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
> [ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
> [ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
> [ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
> [ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
> [ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
> [ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
> [ 4545.476435] note: cat[8976] exited with preempt_count 2
>
> So the call flow is:
>
> read_core() // finds the address is vmalloc or module
> -> vread()
> --> aligned_vread()
>
> In aligned_vread(), we vmalloc_to_page() the address, and find a page.
> We then try to kmap_atomic() that. The generic kmap_atomic() returns the
> linear map alias of the address.
>
> However, it appears that the page is nomap'd memory, and the linear
> alias doesn't exist. Thus memcpy explodes when trying to access that
> address.
>
> I've verified that with:
>
> ----
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 0b05762..d7f48e0 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -9,6 +9,7 @@
> */
>
> #include <linux/vmalloc.h>
> +#include <linux/memblock.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/highmem.h>
> @@ -1978,6 +1979,8 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
> {
> struct page *p;
> int copied = 0;
> + phys_addr_t phys;
> + bool nomap;
>
> while (count) {
> unsigned long offset, length;
> @@ -2000,6 +2003,14 @@ static int aligned_vread(char *buf, char *addr, unsigned long count)
> * function description)
> */
> void *map = kmap_atomic(p);
> +
> + phys = page_to_phys(p);
> + nomap = !memblock_is_map_memory(phys);
> +
> + pr_info("HARK: %s kmap'd %pa (%s memory) @ %p\n",
> + __func__, &phys, (nomap ? "nomap" : "map"),
> + map);
> +
> memcpy(buf, map + offset, length);
> kunmap_atomic(map);
> } else
> ----
>
> # cat /proc/kcore > /dev/null
>
> ... which eventually results in:
>
> [ 47.360980] HARK: aligned_vread kmap'd 0x000003e290005000 (nomap memory) @ ffff83e210005000
> [ 47.369297] Unable to handle kernel paging request at virtual address ffff83e210005000
>
> I'm not sure what we should do here.
>
> I'm not immediately sure what the nomap region is. I'm using UEFI && DT,
> so I guess it's not ACPI tables.
>
> I can try to dump more info later.
>
> Thanks,
> Mark.
Thanks a lot.
Xiaojun.
>
> .
>
^ permalink raw reply
* [GIT PULL] ARM: SOC PM domain for 4.12
From: Dave Gerlach @ 2017-04-20 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0358ac18-8d7a-84a6-356f-8c9e8840bc4d@oracle.com>
Arnd,
On 04/19/2017 05:54 PM, santosh.shilimkar at oracle.com wrote:
> +Dave,
>
> On 4/19/17 12:56 PM, Arnd Bergmann wrote:
>> On Thu, Apr 6, 2017 at 7:42 PM, Santosh Shilimkar <ssantosh@kernel.org> wrote:
>>> Hi Arnd, Olof,
>>>
>>> As inidcated on the list, because of various dependencies, am senidng
>>> Dave Gerlach's full patchset in single pull request.
>>>
>>> The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
>>>
>>> Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
>>> tags/arm-soc-pmdomain
>>>
>>> for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:
>>>
>>> ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)
>>>
>>> ----------------------------------------------------------------
>>> ARM SOC PM domain support for 4.12
>>>
>>> Dave Gerlach (5):
>>> PM / Domains: Add generic data pointer to genpd data struct
>>> PM / Domains: Do not check if simple providers have phandle cells
>>> dt-bindings: Add TI SCI PM Domains
>>> soc: ti: Add ti_sci_pm_domains driver
>>> ARM: keystone: Drop PM domain support for k2g
>>
>> I went through the list of arm at kernel.org emails that had not seen a reply after
>> Olof's pull marathon today. I did not get a reply for this one, but I
>> see that Olof
>> has merged it into next/drivers.
>>
> Thanks.
>
>> Since I was looking at it, I also took a closer look at the contents of the
>> patch series. The driver itself looks fine, but for the record, I'm not that
>> happy about seeing a header file duplicating the information from the
>> data sheet: We only use dt-binding headers to establish an interface between
>> the driver and the sources when there is well-defined fixed way to enumerate
>> resources, but in this case there clearly is...
>>
I apologize but I'm not clear on exactly what your concern is? Currently we
define a device ID which is associated to a "device" in the firmware's view of
the world, however the firmware has no knowledge of what goes on in the kernel
and vice-versa. The device ID is associated to that device only on that
hardware, it could be a different ID on a different SoC making use of SCI. The
only way a device is identified to the firmware is through this number, it will
also be used by the ti-sci-clock [1] and ti-sci-reset [2] drivers to identify
the device.
I'm not sure what you mean by "We only use dt-binding headers to establish an
interface between the driver and the sources when there is well-defined fixed
way to enumerate resources."
Regards,
Dave
[1] https://www.spinics.net/lists/arm-kernel/msg537665.html
[2] https://www.spinics.net/lists/devicetree/msg151643.html
> Dave, please care to follow up Arnd's concerns on those defines.
>
> Regards,
> Santosh
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] scsi: mpt3sas: remove redundant wmb
From: Martin K. Petersen @ 2017-04-20 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491591978-17880-1-git-send-email-okaya@codeaurora.org>
Sinan Kaya <okaya@codeaurora.org> writes:
> Due to relaxed ordering requirements on multiple architectures,
> drivers are required to use wmb/rmb/mb combinations when they need to
> guarantee observability between the memory and the HW.
>
> The mpt3sas driver is already using wmb() for this purpose. However,
> it issues a writel following wmb(). writel() function on arm/arm64
> arhictectures have an embedded wmb() call inside.
>
> This results in unnecessary performance loss and code duplication.
>
> writel already guarantees ordering for both cpu and bus. we don't need
> additional wmb()
Broadcom folks, please review!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI
From: Sergey Senozhatsky @ 2017-04-20 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419131341.76bc7634@gandalf.local.home>
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.
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
-- if we are in printk_safe
-- well... bad luck... have a bigger buffer.
.... or there are some other options here, but I'd prefer
not to list them, because people will hate me :)
so this shifts the purpose of `nmi_print_seq' buffer: use it only when
you can't use logbuf. otherwise, do printk_deferred().
need to think more.
-ss
^ permalink raw reply
* [PATCH] lib/mpi: fix build with clang
From: Stefan Agner @ 2017-04-20 3:40 UTC (permalink / raw)
To: linux-arm-kernel
Use just @ to denote comments which works with gcc and clang.
Otherwise clang reports an escape sequence error:
error: invalid % escape in inline assembly string
Use %0-%3 as operand references, this avoids:
error: invalid operand in inline asm: 'umull ${1:r}, ${0:r}, ${2:r}, ${3:r}'
Also remove superfluous casts on output operands to avoid warnings
such as:
warning: invalid use of a cast in an inline asm context requiring an l-value
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
I checked the output of gcc with -S switch before and after this change,
gcc generated the same assembly.
--
Stefan
lib/mpi/longlong.h | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
index 93336502af08..57fd45ab7af1 100644
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -176,8 +176,8 @@ extern UDItype __udiv_qrnnd(UDItype *, UDItype, UDItype, UDItype);
#define add_ssaaaa(sh, sl, ah, al, bh, bl) \
__asm__ ("adds %1, %4, %5\n" \
"adc %0, %2, %3" \
- : "=r" ((USItype)(sh)), \
- "=&r" ((USItype)(sl)) \
+ : "=r" (sh), \
+ "=&r" (sl) \
: "%r" ((USItype)(ah)), \
"rI" ((USItype)(bh)), \
"%r" ((USItype)(al)), \
@@ -185,15 +185,15 @@ extern UDItype __udiv_qrnnd(UDItype *, UDItype, UDItype, UDItype);
#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
__asm__ ("subs %1, %4, %5\n" \
"sbc %0, %2, %3" \
- : "=r" ((USItype)(sh)), \
- "=&r" ((USItype)(sl)) \
+ : "=r" (sh), \
+ "=&r" (sl) \
: "r" ((USItype)(ah)), \
"rI" ((USItype)(bh)), \
"r" ((USItype)(al)), \
"rI" ((USItype)(bl)))
#if defined __ARM_ARCH_2__ || defined __ARM_ARCH_3__
#define umul_ppmm(xh, xl, a, b) \
- __asm__ ("%@ Inlined umul_ppmm\n" \
+ __asm__ ("@ Inlined umul_ppmm\n" \
"mov %|r0, %2, lsr #16 @ AAAA\n" \
"mov %|r2, %3, lsr #16 @ BBBB\n" \
"bic %|r1, %2, %|r0, lsl #16 @ aaaa\n" \
@@ -206,19 +206,19 @@ extern UDItype __udiv_qrnnd(UDItype *, UDItype, UDItype, UDItype);
"addcs %|r2, %|r2, #65536\n" \
"adds %1, %|r1, %|r0, lsl #16\n" \
"adc %0, %|r2, %|r0, lsr #16" \
- : "=&r" ((USItype)(xh)), \
- "=r" ((USItype)(xl)) \
+ : "=&r" (xh), \
+ "=r" (xl) \
: "r" ((USItype)(a)), \
"r" ((USItype)(b)) \
: "r0", "r1", "r2")
#else
#define umul_ppmm(xh, xl, a, b) \
- __asm__ ("%@ Inlined umul_ppmm\n" \
- "umull %r1, %r0, %r2, %r3" \
- : "=&r" ((USItype)(xh)), \
- "=&r" ((USItype)(xl)) \
+ __asm__ ("@ Inlined umul_ppmm\n" \
+ "umull %1, %0, %2, %3" \
+ : "=&r" (xh), \
+ "=&r" (xl) \
: "r" ((USItype)(a)), \
- "r" ((USItype)(b)) \
+ "r" ((USItype)(b)) \
: "r0", "r1")
#endif
#define UMUL_TIME 20
--
2.12.2
^ permalink raw reply related
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: dongbo (E) @ 2017-04-20 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419103313.GA3238@e104818-lin.cambridge.arm.com>
On 2017/4/19 18:33, Catalin Marinas wrote:
> On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
>> On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
>>> On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
>>>> From: Dong Bo <dongbo4@huawei.com>
>>>>
>>>> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
>>>> the flag is propagated to its child processes, even the elf
>>>> files are marked as not requiring executable stack. It may
>>>> cause superfluous operations on some arch, e.g.
>>>> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
>>>> also marked as PROT_EXEC.
>>>>
>>>> Signed-off-by: Dong Bo <dongbo4@huawei.com>
>>>> ---
>>>> fs/binfmt_elf.c | 2 ++
>>>> fs/binfmt_elf_fdpic.c | 2 ++
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
>>>> index 5075fd5..c52e670 100644
>>>> --- a/fs/binfmt_elf.c
>>>> +++ b/fs/binfmt_elf.c
>>>> @@ -863,6 +863,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
>>>> SET_PERSONALITY2(loc->elf_ex, &arch_state);
>>>> if (elf_read_implies_exec(loc->elf_ex, executable_stack))
>>>> current->personality |= READ_IMPLIES_EXEC;
>>>> + else
>>>> + current->personality &= ~READ_IMPLIES_EXEC;
>>>> if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
>>>> current->flags |= PF_RANDOMIZE;
>>>> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
>>>> index cf93a4f..c4bc4d0 100644
>>>> --- a/fs/binfmt_elf_fdpic.c
>>>> +++ b/fs/binfmt_elf_fdpic.c
>>>> @@ -354,6 +354,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm)
>>>> set_personality(PER_LINUX);
>>>> if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
>>>> current->personality |= READ_IMPLIES_EXEC;
>>>> + else
>>>> + current->personality &= ~READ_IMPLIES_EXEC;
>>>> setup_new_exec(bprm);
>>
>>> That's affecting most architectures with a risk of ABI breakage. We
>>> could do it on arm64 only, though I'm not yet clear on the ABI
>>> implications (at a first look, there shouldn't be any).
>>
>> Is there a reason why it isn't just straightforwardly a bug
>> (which we could fix) to make READ_IMPLIES_EXEC propagate to
>> child processes?
>
> While I agree that it looks like a bug, if there are user programs
> relying on such bug we call it "ABI". On arm64, I don't think there is
> anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
> the compat task handling without the corresponding change in arch/arm.
>
With READ_IMPLIES_EXEC propagation, several hundreds times of
__sync_icache_dcache operations shows up than not READ_IMPLIES_EXEC
propagation, which degenerating the system performance. Changing arm64
only would settle our problem down, thanks for figuring out previously.
Seems that arch/arm had discussed the propagation of READ_IMPLIES_EXEC:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086490.html
But the READ_IMPLIES_EXEC is still not cleared in elf_set_personality().
>> AFAICT this should be per-process: just because
>> init happens not to have been (re)compiled to permit non-executable
>> stacks doesn't mean every process on the system needs to have
>> an executable stack.
>
> I think this also affects the heap if brk(2) is used (via
> VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
> days).
>
>> Behaviour shouldn't be variable across architectures either, I would
>> hope.
>
> The behaviour has already been variable for a long time. Even on x86,
> AFAICT x86_32 differs from x86_64 in this respect.
>
> Anyway, the patch should be posted to linux-arch for a cross-arch
> discussion.
>
OK, this mail Cc to linux-arch. Thanks.
^ permalink raw reply
* [PATCH v2] soc: brcmstb: enable drivers for ARM64 and BMIPS
From: Baruch Siach @ 2017-04-20 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419225040.71650-1-code@mmayer.net>
Hi Markus,
On Wed, Apr 19, 2017 at 03:50:40PM -0700, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and
> BMIPS.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
>
> I used (COMPILE_TEST & OF) as condition like Raspberry Pi, since we
> have of_* calls in our code, too.
All of_* calls under drivers/soc/bcm/ either have empty implementations for
the !CONFIG_OF case, or call only such routines. The RPi OF condition is most
likely not needed as well.
baruch
> Changes since v1:
> - Add BMIPS
> - Add COMPILE_TEST
>
> drivers/soc/bcm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
> index a39b0d58ddd0..9463d6709909 100644
> --- a/drivers/soc/bcm/Kconfig
> +++ b/drivers/soc/bcm/Kconfig
> @@ -11,7 +11,7 @@ config RASPBERRYPI_POWER
>
> config SOC_BRCMSTB
> bool "Broadcom STB SoC drivers"
> - depends on ARM
> + depends on ARM || ARM64 || BMIPS_GENERIC || (COMPILE_TEST && OF)
> select SOC_BUS
> help
> Enables drivers for the Broadcom Set-Top Box (STB) series of chips.
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Sunil Kovvuri @ 2017-04-20 4:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492430246-17267-1-git-send-email-sunil.kovvuri@gmail.com>
On Mon, Apr 17, 2017 at 5:27 PM, <sunil.kovvuri@gmail.com> wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> For software initiated address translation, when domain type is
> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
> i.e return the same IOVA as translated address.
>
> This patch is an extension to Will Deacon's patchset
> "Implement SMMU passthrough using the default domain".
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> ---
> drivers/iommu/arm-smmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 41afb07..2f4a130 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
>
> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
> + return iova;
> +
> if (!ops)
> return 0;
>
> --
> 2.7.4
>
Any comments or is this patch accepted ?
Thanks,
Sunil.
^ permalink raw reply
* [PATCH] arm64: dts: freescale: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Priyanka Jain @ 2017-04-20 4:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch add support for NXP LS2081ARDB board which has
LS2081A SoC.
LS2081A SoC is 40-pin derivative of LS2088A SoC
So, from functional perspective both are same.
Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts | 139 +++++++++++++++++++++
2 files changed, 140 insertions(+), 0 deletions(-)
create mode 100755 arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 72c4b52..58b80de 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
new file mode 100444
index 0000000..7ae408e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
@@ -0,0 +1,139 @@
+/*
+ * Device Tree file for NXP LS2081A RDB Board.
+ *
+ * Copyright (C) 2017, NXP Semiconductors
+ *
+ * Priyanka Jain <priyanka.jain@nxp.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "fsl-ls2088a.dtsi"
+
+/ {
+ model = "NXP Layerscape 2081A RDB Board";
+ compatible = "fsl,ls2081a-rdb", "fsl,ls2081a";
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ };
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+};
+
+&esdhc {
+ status = "okay";
+};
+
+&ifc {
+ status = "disabled";
+};
+
+&i2c0 {
+ status = "okay";
+ pca9547 at 75 {
+ compatible = "nxp,pca9547";
+ reg = <0x75>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x01>;
+ rtc at 51 {
+ compatible = "nxp,pcf2129";
+ reg = <0x51>;
+ };
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ adt7481 at 4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
+ };
+};
+
+&dspi {
+ status = "okay";
+ dflash0: n25q512a {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <3000000>;
+ reg = <0>;
+ };
+};
+
+
+&qspi {
+ status = "okay";
+ flash0: n25q512a at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+ flash1: n25q512a at 1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
--
1.7.4.1
^ permalink raw reply related
* [PATCH] arm: alignment: update comments on /proc/cpu/alignment
From: Perr Zhang @ 2017-04-20 4:55 UTC (permalink / raw)
To: linux-arm-kernel
The path name in the comment is out of date, update it.
Signed-off-by: Perr Zhang <strongbox8@zoho.com>
---
arch/arm/mm/alignment.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 2c96190..db9c2cf 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -33,8 +33,12 @@
/*
* 32-bit misaligned trap handler (c) 1998 San Mehat (CCC) -July 1998
- * /proc/sys/debug/alignment, modified and integrated into
- * Linux 2.1 by Russell King
+ * /proc/cpu/alignment, modified and integrated into Linux 2.1 by Russell King
+ * Note:
+ * The path name may be different for very old versions of Linux,
+ * i.e, /proc/sys/debug/alignment for Linux 2.1.
+ * This was relocated because it was in conflict with sysctl(/proc/sys/)
+ * and it doesn't contain sysctl information.
*
* Speed optimisations and better fault handling by Russell King.
*
@@ -985,10 +989,8 @@ static int __init noalign_setup(char *__unused)
__setup("noalign", noalign_setup);
/*
- * This needs to be done after sysctl_init, otherwise sys/ will be
- * overwritten. Actually, this shouldn't be in sys/ at all since
- * it isn't a sysctl, and it doesn't contain sysctl information.
- * We now locate it in /proc/cpu/alignment instead.
+ * Refer to Documentation/arm/mem_alignment for
+ * usage of /proc/cpu/alignment.
*/
static int __init alignment_init(void)
{
--
1.9.3
^ permalink raw reply related
* [PATCH V4 0/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 5:44 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 has been sent separately as a single patch earlier, and Olof
suggested to split it per-platform and get it merged via platform
specific trees. Please get these applied to your trees guys and the rest
can go via arm-soc.
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/am4372.dtsi | 10 ++--
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.dtsi | 6 +-
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 ++--
20 files changed, 294 insertions(+), 294 deletions(-)
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply
* [PATCH V4 1/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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 V4 2/7] ARM: TI: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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/am4372.dtsi | 10 +++++-----
2 files changed, 15 insertions(+), 15 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/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 97fcaf415de1..1532ffe1de63 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -60,32 +60,32 @@
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
- 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>;
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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 f9408188f97f..3678d5b44d80 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -335,15 +335,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>;
};
@@ -353,13 +353,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>;
};
};
@@ -368,10 +368,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>;
};
};
@@ -380,10 +380,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>;
};
};
@@ -392,13 +392,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>;
};
};
@@ -407,13 +407,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 235bbb69ad7c..ce240d0198b3 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>;
@@ -433,23 +433,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>;
};
@@ -459,16 +459,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>;
};
};
@@ -525,19 +525,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>;
};
@@ -547,10 +547,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>;
};
};
@@ -559,10 +559,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>;
};
};
@@ -571,10 +571,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 7dc9dc82afd8..5cd6c7389d51 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 V4 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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 V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 306af6cadf26..a2c555d6475c 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -49,19 +49,19 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
opp-microvolt = <1040000>;
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 1008000000 {
+ opp-1008000000 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1200000>;
clock-latency-ns = <244144>; /* 8 32k periods */
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
* [PATCH V4 6/7] ARM: uniphier: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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 dbc5e5333163..22ef2842be3a 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 e9e031d63c1a..acaaa2187843 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 da881f5b6ed4..0f2bee028ab0 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 a6b3a70dae83..19f782408d54 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 V4 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.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 b850b2cd0adc..2c7dc69987df 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
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