* [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END
From: Chris Brandt @ 2016-12-06 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-2-f.fainelli@gmail.com>
On 12/6/2016, Florian Fainelli wrote:
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 4001dd15818d..18ef688a796e 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1437,12 +1437,8 @@ static void __init kmap_init(void)
> static void __init map_lowmem(void)
> {
> struct memblock_region *reg;
> -#ifdef CONFIG_XIP_KERNEL
> - phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
> -#else
> - phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
> -#endif
> - phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
> + phys_addr_t kernel_x_start = round_down(__pa(KERNEL_START),
> SECTION_SIZE);
> + phys_addr_t kernel_x_end = round_down(__pa(_end), SECTION_SIZE);
Why are you changing the end of executable kernel (hence the 'x' in
kernel_x_end) from __init_end to _end which basically maps the entire
kernel image including text and data?
Doing so would then change data from MT_MEMORY_RW into MT_MEMORY_RWX.
I would think it would create some type of security risk to allow
data to be executable.
^ permalink raw reply
* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Jon Mason @ 2016-12-06 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rwdKHtgp+g58B3HrDnkYZoGGZUdSqVFAGXZbf8tNTBZPg@mail.gmail.com>
On Tue, Dec 06, 2016 at 09:57:31PM +0100, Rafa? Mi?ecki wrote:
> On 6 December 2016 at 21:06, Jon Mason <jon.mason@broadcom.com> wrote:
> > On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafa? Mi?ecki wrote:
> >> From: Rafa? Mi?ecki <rafal@milecki.pl>
> >>
> >> So far we were specifying only the first block which is always limited
> >> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
> >
> > Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
> > ways to access the first 128M of RAM, a proxy starting at address 0
> > and the real address. I think you are splitting RAM by accessing it
> > both ways, when you really should just be accessing it at the real
> > address.
>
> I need some more help, please.
>
> This patch (quite well tested) confirms that 0x88000000 can be used to
> access RAM at offset 128 MiB. If this is a real address and whole
> space is contiguous, it means the base real address should be
> 0x80000000. So using 0x0 and 0x80000000 should allow accessing
> beginning of the RAM. I took a device that was working just fine with:
> reg = <0x00000000 0x08000000>;
> and I replaced it with:
> reg = <0x80000000 0x08000000>;
> but it broke things, kernel didn't boot with the last message being:
> [ 0.000000] Memory policy: Data cache writealloc
>
> I can see that bcm958525er.dts, bcm958525xmc.dts, bcm958623hr.dts,
> bcm958625k.dts bcm988312hr.dts are using 0x60000000 as base address.
> It seems to be different from Northstar but I tried following entry
> anyway:
> reg = <0x60000000 0x08000000>;
> and I got kernel hang just like in the previous try.
>
> Did I miss something? Or does Northstar seem to be actually different than NSP?
Per the BCM5301X Preliminary Programmer's Register Reference guide
(page 394), under the second titled "System Address Mapping".
There is a table listing the System Address Mapping. The parts that
are of interest in this converstation are (and forgive my
approxmiation, but I cannot cut'n'paste from it):
Address Range Size Description
---------------------------------------------------
0x0000_0000-0x07FF_FFFF 128 MB DDR2/3 SDRAM Memory Region*
0x8000_0000-0xBFFF_FFFF 1 G DDR2/3 SDRAM Large Region
* The DDR2/3 SDRAM Memory Region (128MB) is a subset of the DDR2/3
SDRAM Large Region (1GB). Additionally, 0x0000_0000-0x07FF_FFFF is
aliased to 0x8000_0000-0x87FF_FFFF
However, since you say it isn't working for you, then there must be
some other missing peice. I'll retract my comment for now, and
hopefully we can double back and get it working in the future.
Thanks,
Jon
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: Fix check in usba_ep_enable()
From: Boris Brezillon @ 2016-12-06 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481061583-4727-1-git-send-email-boris.brezillon@free-electrons.com>
Hi Felipe,
I realize I sent this patch to your old @ti.com email address. Do you
want me to resend it?
Regards,
Boris
On Tue, 6 Dec 2016 22:59:43 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK is not necessarily
> equal to ep->index and that's perfectly fine. The usba endpoint index is
> just an internal identifier used by the driver to know which registers
> to use for a USB endpoint.
>
> Enforcing this constraint is not only useless, but can also lead to
> errors since nothing guarantees that the endpoint number and index are
> matching when an endpoint is selected for a specific descriptor, thus
> leading to errors at ->enable() time when it's already too late to choose
> another endpoint.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Hi,
>
> I intentionally didn't add the Cc stable and Fixes tags because this
> bug dates back to the drivers creation, and I fear the index <->
> epnum constraint was actually required at that time.
>
> Note that I discovered this bug thanks to the WARN_ON_ONCE() in
> usb_ep_queue() [1] which was introduced in 4.5.
> It might appear that this problem was silently ignored before that
> (with part of the usba_ep_enable() code being skipped without any
> notice).
>
> Regards,
>
> Boris
>
> [1]http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/core.c#L264
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index bb1f6c8f0f01..981d2639d413 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -531,11 +531,8 @@ usba_ep_enable(struct usb_ep *_ep, const struct usb_endpoint_descriptor *desc)
>
> maxpacket = usb_endpoint_maxp(desc) & 0x7ff;
>
> - if (((desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) != ep->index)
> - || ep->index == 0
> - || desc->bDescriptorType != USB_DT_ENDPOINT
> - || maxpacket == 0
> - || maxpacket > ep->fifo_size) {
> + if (ep->index == 0 || desc->bDescriptorType != USB_DT_ENDPOINT ||
> + maxpacket == 0 || maxpacket > ep->fifo_size) {
> DBG(DBG_ERR, "ep_enable: Invalid argument");
> return -EINVAL;
> }
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: Fix check in usba_ep_enable()
From: Boris Brezillon @ 2016-12-06 21:59 UTC (permalink / raw)
To: linux-arm-kernel
desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK is not necessarily
equal to ep->index and that's perfectly fine. The usba endpoint index is
just an internal identifier used by the driver to know which registers
to use for a USB endpoint.
Enforcing this constraint is not only useless, but can also lead to
errors since nothing guarantees that the endpoint number and index are
matching when an endpoint is selected for a specific descriptor, thus
leading to errors at ->enable() time when it's already too late to choose
another endpoint.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Hi,
I intentionally didn't add the Cc stable and Fixes tags because this
bug dates back to the drivers creation, and I fear the index <->
epnum constraint was actually required at that time.
Note that I discovered this bug thanks to the WARN_ON_ONCE() in
usb_ep_queue() [1] which was introduced in 4.5.
It might appear that this problem was silently ignored before that
(with part of the usba_ep_enable() code being skipped without any
notice).
Regards,
Boris
[1]http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/core.c#L264
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index bb1f6c8f0f01..981d2639d413 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -531,11 +531,8 @@ usba_ep_enable(struct usb_ep *_ep, const struct usb_endpoint_descriptor *desc)
maxpacket = usb_endpoint_maxp(desc) & 0x7ff;
- if (((desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) != ep->index)
- || ep->index == 0
- || desc->bDescriptorType != USB_DT_ENDPOINT
- || maxpacket == 0
- || maxpacket > ep->fifo_size) {
+ if (ep->index == 0 || desc->bDescriptorType != USB_DT_ENDPOINT ||
+ maxpacket == 0 || maxpacket > ep->fifo_size) {
DBG(DBG_ERR, "ep_enable: Invalid argument");
return -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Alexey Kardashevskiy @ 2016-12-06 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206104343.hb8GsYcB@smtp2j.mail.yandex.net>
On 06/12/16 18:43, Icenowy Zheng wrote:
>
> 2016?12?6? 09:51? Alexey Kardashevskiy <aik@ozlabs.ru>???
>>
>> On 03/12/16 02:05, Icenowy Zheng wrote:
>>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
>>> SDIO Wi-Fi chip by Allwinner (XR819).
>>>
>>> Add a device tree file for it.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>> ---
>>> Changes since v2:
>>> - Merged SDIO Wi-Fi patch into it.
>>> - SDIO Wi-Fi: add a ethernet1 alias to it, as it has no internal NVRAM.
>>> - SDIO Wi-Fi: changed pinctrl binding to generic pinconf
>>> - removed all gpio pinctrl nodes
>>> - changed h2plus to h2-plus
>>> Changes since v1:
>>> - Convert to generic pinconf bindings.
>>> - SDIO Wi-Fi: add patch.
>>>
>>> Some notes:
>>> - The uart1 and uart2 is available on the unsoldered gpio header.
>>> - The onboard USB connector has its Vbus directly connected to DCIN-5V (the
>>> power jack)
>>>
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 159 ++++++++++++++++++++++
>>> 2 files changed, 160 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 6447abc..59f6e86 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -844,6 +844,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>> sun8i-a33-sinlinx-sina33.dtb \
>>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>> sun8i-a83t-cubietruck-plus.dtb \
>>> + sun8i-h2-plus-orangepi-zero.dtb \
>>> sun8i-h3-bananapi-m2-plus.dtb \
>>> sun8i-h3-nanopi-neo.dtb \
>>> sun8i-h3-orangepi-2.dtb \
>>> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>> new file mode 100644
>>> index 0000000..d18807f
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>> @@ -0,0 +1,159 @@
>>> +/*
>>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>>> + *
>>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>>> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL 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 file 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 file 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 "sun8i-h3.dtsi"
>>> +#include "sunxi-common-regulators.dtsi"
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/input/input.h>
>>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>>> +
>>> +/ {
>>> + model = "Xunlong Orange Pi Zero";
>>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus";
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
>>
>>
>> It is not defined there as for:
>>
>> cef87e9 (tag: next-20161205) 20 hours ago Stephen Rothwell Add linux-next
>> specific files for 20161205
>
> The driver of H3's obfuscated DesignWare MAC is not yet mainlined, so there won't be one ethernet0 now.
>
> But it's reserved for the onboard Ethernet.
Could you please elaborate how you tested this patch (ideally some tree
somewhere on github)? This patch added RX819, it assumes EMAC support is
there, neither is there nor there is a way to test this... Thanks.
>
>>
>>
>>
>>
>>
>>> + ethernet1 = &xr819;
>>> + };
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + leds {
>>> + compatible = "gpio-leds";
>>> +
>>> + pwr_led {
>>> + label = "orangepi:green:pwr";
>>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>>> + default-state = "on";
>>> + };
>>> +
>>> + status_led {
>>> + label = "orangepi:red:status";
>>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>>> + };
>>> + };
>>> +
>>> + reg_vcc_wifi: reg_vcc_wifi {
>>> + compatible = "regulator-fixed";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + regulator-name = "vcc-wifi";
>>> + enable-active-high;
>>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-simple";
>>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>>> + };
>>> +};
>>> +
>>> +&ehci1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc0 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc0_pins_a>;
>>> + vmmc-supply = <®_vcc3v3>;
>>> + bus-width = <4>;
>>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>>> + cd-inverted;
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc1_pins_a>;
>>> + vmmc-supply = <®_vcc_wifi>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> + bus-width = <4>;
>>> + non-removable;
>>> + status = "okay";
>>> +
>>> + /*
>>> + * Explicitly define the sdio device, so that we can add an ethernet
>>> + * alias for it (which e.g. makes u-boot set a mac-address).
>>> + */
>>> + xr819: sdio_wifi at 1 {
>>> + reg = <1>;
>>> + };
>>> +};
>>> +
>>> +&mmc1_pins_a {
>>> + bias-pull-up;
>>> +};
>>> +
>>> +&ohci1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&uart0 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart0_pins_a>;
>>> + status = "okay";
>>> +};
>>> +
>>> +&uart1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart1_pins>;
>>> + status = "disabled";
>>> +};
>>> +
>>> +&uart2 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart2_pins>;
>>> + status = "disabled";
>>> +};
>>> +
>>> +&usbphy {
>>> + /* USB VBUS is always on */
>>> + status = "okay";
>>> +};
>>>
>>
>>
>> --
>> Alexey
--
Alexey
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Arnd Bergmann @ 2016-12-06 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206185440.GA4654@yury-N73SV>
On Wednesday, December 7, 2016 12:24:40 AM CET Yury Norov wrote:
> I see 3 solutions for my problem:
> 1. Reuse aarch64/lp64 mmap code for ilp32 in glibc, but wrap offset with
> SYSCALL_LL64() macro - which converts offset to the pair for 32-bit
> ports. This is simple but local solution. And most probably it's enough.
I wouldn't want arm64 to be different from all other architectures
here for the 32-bit API. The mmap() API used to be done entirely
in architecture specific code, while nowadays at least new architectures
use something resembling sys_mmap_pgoff(). I think that was originally
introduced to be the default API for 32-bit architectures, but it
failed to address architectures with variable page sizes.
> 2. Add new flag to mmap, like MAP_OFFSET_IN_PAIR. This will also work.
> The problem here is that there are too much arches that implement
> their custom sys_mmap2(). And, of course, this type of flags is
> looking ugly.
Right, better not touch make complicate it further. The other problem
is that mmap2() already has six argument and on most architectures
that is the limit for the number of syscall arguments, so you
cannot add another argument for the upper half.
> 3. Introduce new mmap64() syscall like this:
> sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off);
> (The pointer here because otherwise we have 7 args, if simply pass off_hi and
> off_lo in registers.)
This wouldn't have to be a pair, just a pointer to a 64-bit number.
> With new 64-bit interface we can deprecate mmap2(), and generalize all
> implementations in kernel.
>
> I think we can discuss it because 64-bit is the default size for off_t
> in all new 32-bit architectures. So generic solution may take place.
>
> The last question here is how important to support offsets bigger than
> 2^44 on 32-bit machines in practice? It may be a case for ARM64 servers,
> which are looking like main aarch64/ilp32 users. If no, we can leave
> things as is, and just do nothing.
If there is a use case for larger than 16TB offsets, we should add
the call on all architectures, probably using your approach 3. I don't
think that we should treat it as anything special for arm64 though.
Arnd
^ permalink raw reply
* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Rafał Miłecki @ 2016-12-06 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206200621.GB2768@broadcom.com>
On 6 December 2016 at 21:06, Jon Mason <jon.mason@broadcom.com> wrote:
> On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> So far we were specifying only the first block which is always limited
>> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
>
> Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
> ways to access the first 128M of RAM, a proxy starting at address 0
> and the real address. I think you are splitting RAM by accessing it
> both ways, when you really should just be accessing it at the real
> address.
I need some more help, please.
This patch (quite well tested) confirms that 0x88000000 can be used to
access RAM at offset 128 MiB. If this is a real address and whole
space is contiguous, it means the base real address should be
0x80000000. So using 0x0 and 0x80000000 should allow accessing
beginning of the RAM. I took a device that was working just fine with:
reg = <0x00000000 0x08000000>;
and I replaced it with:
reg = <0x80000000 0x08000000>;
but it broke things, kernel didn't boot with the last message being:
[ 0.000000] Memory policy: Data cache writealloc
I can see that bcm958525er.dts, bcm958525xmc.dts, bcm958623hr.dts,
bcm958625k.dts bcm988312hr.dts are using 0x60000000 as base address.
It seems to be different from Northstar but I tried following entry
anyway:
reg = <0x60000000 0x08000000>;
and I got kernel hang just like in the previous try.
Did I miss something? Or does Northstar seem to be actually different than NSP?
^ permalink raw reply
* [PATCH 3/3] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-06 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-4-f.fainelli@gmail.com>
On 12/06/2016 11:53 AM, Florian Fainelli wrote:
> x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
> virt_to_phys calls. The goal is to catch users who are calling
> virt_to_phys on non-linear addresses immediately. This includes caller
> using __virt_to_phys() on image addresses instead of __pa_symbol(). This
> is a generally useful debug feature to spot bad code (particulary in
> drivers).
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> @@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
> ((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
> PHYS_PFN_OFFSET)
>
> +#define __pa_symbol_nodebug(x) ((x) - (unsigned long)KERNEL_START)
I don't think I got this one quite right, but I also assume that won't
be the only problem with this patch series.
--
Florian
^ permalink raw reply
* [stable:PATCH 0/3] PAN fixes backport for v4.4.35
From: Greg KH @ 2016-12-06 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202164247.19496-1-james.morse@arm.com>
On Fri, Dec 02, 2016 at 04:42:44PM +0000, James Morse wrote:
> Hi linux-stable,
>
> This is the backport of the recent PAN fixes series for v4.4.35.
> Original series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
>
> Patch 1 changes the prototype of all the feature/errata enable calls, so
> is fiddly to backport, hence doing it later as a separate series.
>
> Patch 3 has had the UAO desription removed from its commit message as
> v4.4 doesn't support this feature.
Thanks, now all queued up.
greg k-h
^ permalink raw reply
* [stable:PATCH 0/3] PAN fixes backport for v4.8.12
From: Greg KH @ 2016-12-06 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206190454.19083-1-james.morse@arm.com>
On Tue, Dec 06, 2016 at 07:04:51PM +0000, James Morse wrote:
> Hi Greg, linux-stable,
>
> This is the backport of the recent PAN fixes series for v4.8.
> Original series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
>
> Next time I will remember to work backwards through stable versions.
> Sorry for the confusion!
Not a problem, many thanks for these, all now queued up.
greg k-h
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-06 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206201835.GA19700@bhelgaas-glaptop.roam.corp.google.com>
On 12/06/2016 03:18 PM, Bjorn Helgaas wrote:
> On Tue, Dec 06, 2016 at 02:46:00PM -0500, Jon Masters wrote:
>> On 12/05/2016 04:21 PM, Bjorn Helgaas wrote:
>>> On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote:
>>
>>>>> Even without this patch, I don't think it's a show-stopper to have
>>>>> Linux mistakenly thinking this region is routed to PCI, because the
>>>>> driver does reserve it and the PCI core will never try to use it.
>>>>
>>>> Ok. So are you happy with pulling in Duc's v4 patch and retaining
>>>> status quo on the bridge resources for 4.10?
>>>
>>> Yes, I think it looks good. I'll finish packaging things up and
>>> repost the current series.
>>
>> Ok, great. So you're still pretty confident we'll have "out of the box"
>> booting on these machines for 4.10? :)
>
> I just merged pci/ecam into my "next" branch, so as long as tomorrow's
> linux-next boots out of the box, we should be set. I made the following
> changes compared to v11:
>
> - dropped the x86 change to use acpi_resource_consumer()
> - added parens around macro args used in arithmetic expressions
> - renamed "seg" to "node" in THUNDER_PEM_RES and THUNDER_PEM_QUIRK
> - incorporated (u64) cast and dropped "UL" postfix for THUNDER_PEM_QUIRK
>
> Let me know if you see any issues.
Thanks - I'll test linux-next tomorrow.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-06 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aac9391d-8803-f5e8-f4e4-d7e56d54c05c@redhat.com>
On Tue, Dec 06, 2016 at 02:46:00PM -0500, Jon Masters wrote:
> On 12/05/2016 04:21 PM, Bjorn Helgaas wrote:
> > On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote:
>
> >>> Even without this patch, I don't think it's a show-stopper to have
> >>> Linux mistakenly thinking this region is routed to PCI, because the
> >>> driver does reserve it and the PCI core will never try to use it.
> >>
> >> Ok. So are you happy with pulling in Duc's v4 patch and retaining
> >> status quo on the bridge resources for 4.10?
> >
> > Yes, I think it looks good. I'll finish packaging things up and
> > repost the current series.
>
> Ok, great. So you're still pretty confident we'll have "out of the box"
> booting on these machines for 4.10? :)
I just merged pci/ecam into my "next" branch, so as long as tomorrow's
linux-next boots out of the box, we should be set. I made the following
changes compared to v11:
- dropped the x86 change to use acpi_resource_consumer()
- added parens around macro args used in arithmetic expressions
- renamed "seg" to "node" in THUNDER_PEM_RES and THUNDER_PEM_QUIRK
- incorporated (u64) cast and dropped "UL" postfix for THUNDER_PEM_QUIRK
Let me know if you see any issues.
Bjorn
^ permalink raw reply
* [PATCHv4 09/10] mm/usercopy: Switch to using lm_alias
From: Kees Cook @ 2016-12-06 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206181859.GH24177@leverpostej>
On Tue, Dec 6, 2016 at 10:18 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Nov 29, 2016 at 11:39:44AM -0800, Kees Cook wrote:
>> On Tue, Nov 29, 2016 at 10:55 AM, Laura Abbott <labbott@redhat.com> wrote:
>> >
>> > The usercopy checking code currently calls __va(__pa(...)) to check for
>> > aliases on symbols. Switch to using lm_alias instead.
>> >
>> > Signed-off-by: Laura Abbott <labbott@redhat.com>
>>
>> Acked-by: Kees Cook <keescook@chromium.org>
>>
>> I should probably add a corresponding alias test to lkdtm...
>>
>> -Kees
>
> Something like the below?
>
> It uses lm_alias(), so it depends on Laura's patches. We seem to do the
> right thing, anyhow:
Cool, this looks good. What happens on systems without an alias?
Laura, feel free to add this to your series:
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
>
> root at ribbensteg:/home/nanook# echo USERCOPY_KERNEL_ALIAS > /sys/kernel/debug/provoke-crash/DIRECT
> [ 44.493400] usercopy: kernel memory exposure attempt detected from ffff80000031a730 (<linear kernel text>) (4096 bytes)
> [ 44.504263] kernel BUG at mm/usercopy.c:75!
>
> Thanks,
> Mark.
>
> ---->8----
> diff --git a/drivers/misc/lkdtm.h b/drivers/misc/lkdtm.h
> index fdf954c..96d8d76 100644
> --- a/drivers/misc/lkdtm.h
> +++ b/drivers/misc/lkdtm.h
> @@ -56,5 +56,6 @@
> void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
> void lkdtm_USERCOPY_STACK_BEYOND(void);
> void lkdtm_USERCOPY_KERNEL(void);
> +void lkdtm_USERCOPY_KERNEL_ALIAS(void);
>
> #endif
> diff --git a/drivers/misc/lkdtm_core.c b/drivers/misc/lkdtm_core.c
> index f9154b8..f6bc6d6 100644
> --- a/drivers/misc/lkdtm_core.c
> +++ b/drivers/misc/lkdtm_core.c
> @@ -228,6 +228,7 @@ struct crashtype crashtypes[] = {
> CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
> CRASHTYPE(USERCOPY_STACK_BEYOND),
> CRASHTYPE(USERCOPY_KERNEL),
> + CRASHTYPE(USERCOPY_KERNEL_ALIAS),
> };
>
>
> diff --git a/drivers/misc/lkdtm_usercopy.c b/drivers/misc/lkdtm_usercopy.c
> index 1dd6114..955f2dc 100644
> --- a/drivers/misc/lkdtm_usercopy.c
> +++ b/drivers/misc/lkdtm_usercopy.c
> @@ -279,9 +279,16 @@ void lkdtm_USERCOPY_STACK_BEYOND(void)
> do_usercopy_stack(true, false);
> }
>
> -void lkdtm_USERCOPY_KERNEL(void)
> +static void do_usercopy_kernel(bool use_alias)
> {
> unsigned long user_addr;
> + const void *rodata = test_text;
> + void *text = vm_mmap;
> +
> + if (use_alias) {
> + rodata = lm_alias(rodata);
> + text = lm_alias(text);
> + }
>
> user_addr = vm_mmap(NULL, 0, PAGE_SIZE,
> PROT_READ | PROT_WRITE | PROT_EXEC,
> @@ -292,14 +299,14 @@ void lkdtm_USERCOPY_KERNEL(void)
> }
>
> pr_info("attempting good copy_to_user from kernel rodata\n");
> - if (copy_to_user((void __user *)user_addr, test_text,
> + if (copy_to_user((void __user *)user_addr, rodata,
> unconst + sizeof(test_text))) {
> pr_warn("copy_to_user failed unexpectedly?!\n");
> goto free_user;
> }
>
> pr_info("attempting bad copy_to_user from kernel text\n");
> - if (copy_to_user((void __user *)user_addr, vm_mmap,
> + if (copy_to_user((void __user *)user_addr, text,
> unconst + PAGE_SIZE)) {
> pr_warn("copy_to_user failed, but lacked Oops\n");
> goto free_user;
> @@ -309,6 +316,16 @@ void lkdtm_USERCOPY_KERNEL(void)
> vm_munmap(user_addr, PAGE_SIZE);
> }
>
> +void lkdtm_USERCOPY_KERNEL(void)
> +{
> + do_usercopy_kernel(false);
> +}
> +
> +void lkdtm_USERCOPY_KERNEL_ALIAS(void)
> +{
> + do_usercopy_kernel(true);
> +}
> +
> void __init lkdtm_usercopy_init(void)
> {
> /* Prepare cache that lacks SLAB_USERCOPY flag. */
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Jon Mason @ 2016-12-06 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-4-zajec5@gmail.com>
On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> So far we were specifying only the first block which is always limited
> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
ways to access the first 128M of RAM, a proxy starting at address 0
and the real address. I think you are splitting RAM by accessing it
both ways, when you really should just be accessing it at the real
address.
Thanks,
Jon
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
> arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
> 15 files changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 112a5a8..d241cee 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 3600f56..b0e6204 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index d49afec0..c9ba6b9 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8519548..b9f66c0 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> index 6229ef2..ae0199f 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 74cfcd3..36b628b1 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> index 71b98cf..db8608b 100644
> --- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> +++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index 2922536..d51586d 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> index 184fd92..de041b8 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> gpio-keys {
> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> index eac0f52..eaca687 100644
> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> index aab39c9..b32957c 100644
> --- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> +++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 7ab1176..f459a98 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 56d38a3..cd13534 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 7fb9270..64ded76 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> nand: nand at 18028000 {
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 7ecd57c..600795e 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -18,7 +18,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Jon Mason @ 2016-12-06 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-3-zajec5@gmail.com>
On Tue, Dec 06, 2016 at 06:17:12PM +0100, Rafa? Mi?ecki wrote:
> There is one GPIO controlling power for both USB ports.
>
> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
Was the double Signed-off-by intentional?
> ---
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 0225d82..7ab1176 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -100,3 +100,11 @@
> };
> };
> };
> +
> +&usb2 {
> + vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb3 {
> + vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> +};
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Check for properly initialized timer on init
From: Christoffer Dall @ 2016-12-06 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1ed187ba-965b-6087-f74f-68627f0d0504@arm.com>
On Tue, Dec 06, 2016 at 11:25:42AM +0000, Marc Zyngier wrote:
> On 05/12/16 09:32, Christoffer Dall wrote:
> > When the arch timer code fails to initialize (for example because the
> > memory mapped timer doesn't work, which is currently seen with the AEM
> > model), then KVM just continues happily with a final result that KVM
> > eventually does a NULL pointer dereference of the uninitialized cycle
> > counter.
> >
> > Check directly for this in the init path and give the user a reasonable
> > error in this case.
> >
> > Cc: Shih-Wei Li <shihwei@cs.columbia.edu>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > virt/kvm/arm/arch_timer.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 27a1f63..5c12f53 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -425,6 +425,11 @@ int kvm_timer_hyp_init(void)
> > info = arch_timer_get_kvm_info();
> > timecounter = &info->timecounter;
> >
> > + if (!timecounter->cc) {
> > + kvm_err("arch_timer: uninitialized timecounter\n");
>
> For consistency, I'll change the error message to say "kvm_arch_timer",
> just like the below case.
>
No objections, only problem is that the patch you queued uses
kcm_arch_timer ;)
> > + return -ENODEV;
> > + }
> > +
> > if (info->virtual_irq <= 0) {
> > kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
> > info->virtual_irq);
> >
>
> Otherwise looks good to me. I'll queue it now.
>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 3/3] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-06 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-1-f.fainelli@gmail.com>
x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
virt_to_phys calls. The goal is to catch users who are calling
virt_to_phys on non-linear addresses immediately. This includes caller
using __virt_to_phys() on image addresses instead of __pa_symbol(). This
is a generally useful debug feature to spot bad code (particulary in
drivers).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/memory.h | 16 ++++++++++++--
arch/arm/mm/Makefile | 1 +
arch/arm/mm/physaddr.c | 51 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mm/physaddr.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..5e66173c5787 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2,6 +2,7 @@ config ARM
bool
default y
select ARCH_CLOCKSOURCE_DATA
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index bee7511c5098..46f192218be7 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -213,7 +213,7 @@ extern const void *__pv_table_begin, *__pv_table_end;
: "r" (x), "I" (__PV_BITS_31_24) \
: "cc")
-static inline phys_addr_t __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
{
phys_addr_t t;
@@ -245,7 +245,7 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
#define PHYS_OFFSET PLAT_PHYS_OFFSET
#define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
-static inline phys_addr_t __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
{
return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
}
@@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
PHYS_PFN_OFFSET)
+#define __pa_symbol_nodebug(x) ((x) - (unsigned long)KERNEL_START)
+
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __virt_to_phys(unsigned long x);
+extern phys_addr_t __phys_addr_symbol(unsigned long x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
+#endif
+
/*
* These are *only* valid on the kernel direct mapped RAM memory.
* Note: Drivers should NOT use these. They are the wrong
@@ -283,9 +293,11 @@ static inline void *phys_to_virt(phys_addr_t x)
* Drivers should NOT use these either.
*/
#define __pa(x) __virt_to_phys((unsigned long)(x))
+#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
#define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((phys_addr_t)(pfn) << PAGE_SHIFT)
+
extern long long arch_phys_to_idmap_offset;
/*
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index e8698241ece9..b3dea80715b4 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -14,6 +14,7 @@ endif
obj-$(CONFIG_ARM_PTDUMP) += dump.o
obj-$(CONFIG_MODULES) += proc-syms.o
+obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
obj-$(CONFIG_HIGHMEM) += highmem.o
diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c
new file mode 100644
index 000000000000..00f6dcffab8b
--- /dev/null
+++ b/arch/arm/mm/physaddr.c
@@ -0,0 +1,51 @@
+#include <linux/bug.h>
+#include <linux/export.h>
+#include <linux/types.h>
+#include <linux/mmdebug.h>
+#include <linux/mm.h>
+
+#include <asm/sections.h>
+#include <asm/memory.h>
+#include <asm/fixmap.h>
+
+#include "mm.h"
+
+static inline bool __virt_addr_valid(unsigned long x)
+{
+ if (x < PAGE_OFFSET)
+ return false;
+ if (arm_lowmem_limit && is_vmalloc_or_module_addr((void *)x))
+ return false;
+ if (x >= FIXADDR_START && x < FIXADDR_END)
+ return false;
+ return true;
+}
+
+phys_addr_t __virt_to_phys(unsigned long x)
+{
+ WARN(!__virt_addr_valid(x),
+ "virt_to_phys used for non-linear address :%pK\n", (void *)x);
+
+ return __virt_to_phys_nodebug(x);
+}
+EXPORT_SYMBOL(__virt_to_phys);
+
+static inline bool __phys_addr_valid(unsigned long x)
+{
+ /* This is bounds checking against the kernel image only.
+ * __pa_symbol should only be used on kernel symbol addresses.
+ */
+ if (x < (unsigned long)KERNEL_START ||
+ x > (unsigned long)KERNEL_END)
+ return false;
+
+ return true;
+}
+
+phys_addr_t __phys_addr_symbol(unsigned long x)
+{
+ VIRTUAL_BUG_ON(!__phys_addr_valid(x));
+
+ return __pa_symbol_nodebug(x);
+}
+EXPORT_SYMBOL(__phys_addr_symbol);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: Utilize __pa_symbol in lieu of __pa
From: Florian Fainelli @ 2016-12-06 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-1-f.fainelli@gmail.com>
Unfold pmd_populate_kernel() to make us use __pa_symbol() instead of
__pa(), pre-requisite to turning on CONFIG_DEBUG_VIRTUAL.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 18ef688a796e..ab7e82085df9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -394,7 +394,7 @@ void __init early_fixmap_init(void)
!= FIXADDR_TOP >> PMD_SHIFT);
pmd = fixmap_pmd(FIXADDR_TOP);
- pmd_populate_kernel(&init_mm, pmd, bm_pte);
+ __pmd_populate(pmd, __pa_symbol(bm_pte), _PAGE_KERNEL_TABLE);
pte_offset_fixmap = pte_offset_early_fixmap;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END
From: Florian Fainelli @ 2016-12-06 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-1-f.fainelli@gmail.com>
In preparation for adding CONFIG_DEBUG_VIRTUAL support, define a set of
common constants: KERNEL_START and KERNEL_END which abstract
CONFIG_XIP_KERNEL vs. !CONFIG_XIP_KERNEL. Update the code where
relevant.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/include/asm/memory.h | 7 +++++++
arch/arm/mm/init.c | 7 ++-----
arch/arm/mm/mmu.c | 8 ++------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..bee7511c5098 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -111,6 +111,13 @@
#endif /* !CONFIG_MMU */
+#ifdef CONFIG_XIP_KERNEL
+#define KERNEL_START _sdata
+#else
+#define KERNEL_START _stext
+#endif
+#define KERNEL_END _end
+
/*
* We fix the TCM memories max 32 KiB ITCM resp DTCM at these
* locations
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..c87d0d5b65f2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -230,11 +230,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
void __init arm_memblock_init(const struct machine_desc *mdesc)
{
/* Register the kernel text, kernel data and initrd with memblock. */
-#ifdef CONFIG_XIP_KERNEL
- memblock_reserve(__pa(_sdata), _end - _sdata);
-#else
- memblock_reserve(__pa(_stext), _end - _stext);
-#endif
+ memblock_reserve(__pa(KERNEL_START), _end - KERNEL_START);
+
#ifdef CONFIG_BLK_DEV_INITRD
/* FDT scan will populate initrd_start */
if (initrd_start && !phys_initrd_size) {
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd15818d..18ef688a796e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1437,12 +1437,8 @@ static void __init kmap_init(void)
static void __init map_lowmem(void)
{
struct memblock_region *reg;
-#ifdef CONFIG_XIP_KERNEL
- phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
-#else
- phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
-#endif
- phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
+ phys_addr_t kernel_x_start = round_down(__pa(KERNEL_START), SECTION_SIZE);
+ phys_addr_t kernel_x_end = round_down(__pa(_end), SECTION_SIZE);
/* Map all the lowmem memory banks. */
for_each_memblock(memory, reg) {
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-06 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-1-git-send-email-labbott@redhat.com>
Hi all,
This patch series builds on top of Laura's [PATCHv4 00/10] CONFIG_DEBUG_VIRTUAL for arm64
to add support for CONFIG_DEBUG_VIRTUAL for ARM.
This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE).
There are a number of possible follow up/cleanup patches:
- all SMP implements that pass down the address of secondary_startup to the SMP bringup
operations should use __pa_symbol() instead since they reference in-kernel symbols
Flames, critiques, rotten tomatoes welcome!
Florian Fainelli (3):
ARM: Define KERNEL_START and KERNEL_END
ARM: Utilize __pa_symbol in lieu of __pa
ARM: Add support for CONFIG_DEBUG_VIRTUAL
arch/arm/Kconfig | 1 +
arch/arm/include/asm/memory.h | 23 +++++++++++++++++--
arch/arm/mm/Makefile | 1 +
arch/arm/mm/init.c | 7 ++----
arch/arm/mm/mmu.c | 10 +++------
arch/arm/mm/physaddr.c | 51 +++++++++++++++++++++++++++++++++++++++++++
6 files changed, 79 insertions(+), 14 deletions(-)
create mode 100644 arch/arm/mm/physaddr.c
--
2.9.3
^ permalink raw reply
* [RFC PATCH 23/23] arm: use kconfig fragments for tegra_defconfig/multi_v7_defconfig
From: Olof Johansson @ 2016-12-06 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481027938-31831-24-git-send-email-b.zolnierkie@samsung.com>
On Tue, Dec 6, 2016 at 4:38 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Replace [tegra,multi_v7]_defconfig-s with
> a Makefile target using merge_config.
>
> The patch was verified with doing:
>
> $ make [tegra,multi_v7]_defconfig
> $ make savedefconfig
>
> and comparing resulting defconfig files (before/after the patch).
>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-tegra at vger.kernel.org
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
I'll just reply to this one patch in addition to the cover letter (you
sent the patches to more people than the cover letter, which means
that most people who see these patches don't have full context).
NACK. See cover letter reply for motivation thereof.
-Olof
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-06 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205212140.GA18259@bhelgaas-glaptop.roam.corp.google.com>
On 12/05/2016 04:21 PM, Bjorn Helgaas wrote:
> On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote:
>>> Even without this patch, I don't think it's a show-stopper to have
>>> Linux mistakenly thinking this region is routed to PCI, because the
>>> driver does reserve it and the PCI core will never try to use it.
>>
>> Ok. So are you happy with pulling in Duc's v4 patch and retaining
>> status quo on the bridge resources for 4.10?
>
> Yes, I think it looks good. I'll finish packaging things up and
> repost the current series.
Ok, great. So you're still pretty confident we'll have "out of the box"
booting on these machines for 4.10? :)
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCH 2/2] arm64: dts: NS2: add support for XMC form factor
From: Jon Mason @ 2016-12-06 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612061647.t3qcDWHR%fengguang.wu@intel.com>
On Tue, Dec 06, 2016 at 04:37:48PM +0800, kbuild test robot wrote:
> Hi Jon,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.9-rc8]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Jon-Mason/arm64-dts-NS2-reserve-memory-for-Nitro-firmware/20161206-125631
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
> >> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:56.1-6 Label or path enet not found
> >> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:132.1-7 Label or path pcie8 not found
> >> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:148.1-6 Label or path qspi not found
> >> FATAL ERROR: Syntax error parsing input tree
This patch series is based on top of others queued in Florian's tree.
The errors referenced above are not present when based on this tree,
as those labels are already in the NS2 DT files there.
Thanks,
Jon
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] exynos-gsc: Clean up file handle in open() error path.
From: Krzysztof Kozlowski @ 2016-12-06 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480653927-6850-1-git-send-email-shailendra.v@samsung.com>
On Fri, Dec 02, 2016 at 10:15:27AM +0530, Shailendra Verma wrote:
> The File handle is not yet added in the vfd list.So no need to call
> v4l2_fh_del(&ctx->fh) if it fails to create control.
>
> Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
> ---
> drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I think I see this and exynos4-is patch for the third time...
1. sent in a very short time-frame (usually resending is after 2 weeks),
2. without any change log (should be after --- separator),
3. with different subjects (really...),
4. without versioning (use git format-patch -v2 etc).
Please, keep it a little bit more organized... Look at examples on
mailing lists how (and when) people are sending patches.
Best regards,
Krzysztof
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> index 9f03b79..5ea97c1 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> @@ -664,8 +664,8 @@ static int gsc_m2m_open(struct file *file)
>
> error_ctrls:
> gsc_ctrls_delete(ctx);
> -error_fh:
> v4l2_fh_del(&ctx->fh);
> +error_fh:
> v4l2_fh_exit(&ctx->fh);
> kfree(ctx);
> unlock:
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2
From: Krzysztof Kozlowski @ 2016-12-06 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480663087-4590-6-git-send-email-cw00.choi@samsung.com>
On Fri, Dec 02, 2016 at 04:18:07PM +0900, Chanwoo Choi wrote:
> This patch adds the bus Device-tree nodes for INT (Internal) block
> to enable the bus frequency scaling.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 72 +++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index c08589970134..7b37aae336b1 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -170,6 +170,58 @@
> };
> };
>
> +&bus_g2d_400 {
> + devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
> + vdd-supply = <&buck4_reg>;
> + exynos,saturation-ratio = <10>;
> + status = "okay";
> +};
> +
> +&bus_mscl {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_jpeg {
Except the first entry (which is a parent), are there any objections to
order these nodes alphabetically? This also applies to the previously
patch.
Beside that nit, looks good. I will have to wait anyway to next merge
window, so for the reference:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_g2d_266 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_gscl {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_hevc {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus0 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus1 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus2 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> &cmu_aud {
> assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
> assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
> @@ -794,6 +846,26 @@
> bus-width = <4>;
> };
>
> +&ppmu_d0_general {
> + status = "okay";
> +
> + events {
> + ppmu_event0_d0_general: ppmu-event0-d0-general {
> + event-name = "ppmu-event0-d0-general";
> + };
> + };
> +};
> +
> +&ppmu_d1_general {
> + status = "okay";
> +
> + events {
> + ppmu_event0_d1_general: ppmu-event0-d1-general {
> + event-name = "ppmu-event0-d1-general";
> + };
> + };
> +};
> +
> &pinctrl_alive {
> pinctrl-names = "default";
> pinctrl-0 = <&initial_alive>;
> --
> 1.9.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox