* [stable:PATCH 1/3] arm64: cpufeature: Schedule enable() calls instead of calling them via IPI [v4.4]
From: James Morse @ 2016-12-02 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202164247.19496-1-james.morse@arm.com>
commit 2a6dcb2b5f3e21592ca8dfa198dcce7bec09b020 upstream.
The enable() call for a cpufeature/errata is called using on_each_cpu().
This issues a cross-call IPI to get the work done. Implicitly, this
stashes the running PSTATE in SPSR when the CPU receives the IPI, and
restores it when we return. This means an enable() call can never modify
PSTATE.
To allow PAN to do this, change the on_each_cpu() call to use
stop_machine(). This schedules the work on each CPU which allows
us to modify PSTATE.
This involves changing the protype of all the enable() functions.
enable_cpu_capabilities() is called during boot and enables the feature
on all online CPUs. This path now uses stop_machine(). CPU features for
hotplug'd CPUs are enabled by verify_local_cpu_features() which only
acts on the local CPU, and can already modify the running PSTATE as it
is called from secondary_start_kernel().
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[Removed enable() hunks for features/errata v4.4. doesn't have. Changed
caps->enable arg in enable_cpu_capabilities()]
Signed-off-by: James Morse <james.morse@arm.com>
Cc: <stable@vger.kernel.org> # 4.4.35
---
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/mm/fault.c | 3 ++-
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8136afc9df0d..8884b5d5f48c 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -77,7 +77,7 @@ struct arm64_cpu_capabilities {
const char *desc;
u16 capability;
bool (*matches)(const struct arm64_cpu_capabilities *);
- void (*enable)(void *); /* Called on all active CPUs */
+ int (*enable)(void *); /* Called on all active CPUs */
union {
struct { /* To be used for erratum handling only */
u32 midr_model;
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 4acb7ca94fcd..d08559528927 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -186,6 +186,6 @@ static inline void spin_lock_prefetch(const void *x)
#endif
-void cpu_enable_pan(void *__unused);
+int cpu_enable_pan(void *__unused);
#endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 0669c63281ea..2735bf814592 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -19,7 +19,9 @@
#define pr_fmt(fmt) "CPU features: " fmt
#include <linux/bsearch.h>
+#include <linux/cpumask.h>
#include <linux/sort.h>
+#include <linux/stop_machine.h>
#include <linux/types.h>
#include <asm/cpu.h>
#include <asm/cpufeature.h>
@@ -764,7 +766,13 @@ static void enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
for (i = 0; caps[i].desc; i++)
if (caps[i].enable && cpus_have_cap(caps[i].capability))
- on_each_cpu(caps[i].enable, NULL, true);
+ /*
+ * Use stop_machine() as it schedules the work allowing
+ * us to modify PSTATE, instead of on_each_cpu() which
+ * uses an IPI, giving us a PSTATE that disappears when
+ * we return.
+ */
+ stop_machine(caps[i].enable, NULL, cpu_online_mask);
}
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 4c1a118c1d09..d4634e6942ca 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -606,8 +606,9 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
}
#ifdef CONFIG_ARM64_PAN
-void cpu_enable_pan(void *__unused)
+int cpu_enable_pan(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ return 0;
}
#endif /* CONFIG_ARM64_PAN */
--
2.10.1
^ permalink raw reply related
* [stable:PATCH 0/3] PAN fixes backport for v4.4.35
From: James Morse @ 2016-12-02 16:42 UTC (permalink / raw)
To: linux-arm-kernel
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,
James Morse (3):
arm64: cpufeature: Schedule enable() calls instead of calling them via
IPI [v4.4]
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call [v4.4]
arm64: suspend: Reconfigure PSTATE after resume from idle [v4.4]
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/suspend.c | 9 +++++++++
arch/arm64/mm/fault.c | 12 +++++++++++-
5 files changed, 31 insertions(+), 4 deletions(-)
--
2.10.1
^ permalink raw reply
* [linux-sunxi] [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Chen-Yu Tsai @ 2016-12-02 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202150513.34691-2-icenowy@aosc.xyz>
Hi,
On Fri, Dec 2, 2016 at 11:05 PM, Icenowy Zheng <icenowy@aosc.xyz> 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 */
> + 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;
This is already set in h3.dtsi
> +};
> +
> +&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 */
I think this comment could use a little work.
AFAIK this board doesn't have an actual USB port.
It's just the D+/D- pins on the pin header, along
with the board-wide 5V, also on the pin header.
ChenYu
> + status = "okay";
> +};
> --
> 2.10.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-12-02 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b6c6e9c3-6534-9f20-73bb-84c4e31de5e5@oracle.com>
On 11/30/2016 9:14 AM, Santosh Shilimkar wrote:
> On 11/30/2016 9:10 AM, Grygorii Strashko wrote:
>>
[...]
>>
>> For some reason you e-email is not working - delivery failure
>> ssantosh at kernel.org
>>
> Weird. I was getting all the emails. Thanks for bouncing the thread.
> I will check.
>
Seems like there was issue with kernel.org mail host which I have
been told fixed now. You shouldn't see those bouncing anymore.
Regards,
Santosh
^ permalink raw reply
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Javier Martinez Canillas @ 2016-12-02 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202161359.y3mzvdxsfb2dyok7@t450s.lan>
Hello Gary,
On Fri, Dec 2, 2016 at 1:13 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> Hi Javier,
>
> Thanks for the quick feedback on the matter.
>
You are welcome.
> On Fri, Dec 02, 2016 at 12:44:42PM -0300, Javier Martinez Canillas wrote:
>> Hello Gary,
>>
>> On Fri, Dec 2, 2016 at 12:27 PM, Gary Bisson
>> <gary.bisson@boundarydevices.com> wrote:
>> > Hi Fabio,
>> >
>> > On Fri, Dec 02, 2016 at 01:18:42PM -0200, Fabio Estevam wrote:
>> >> Hi Gary,
>> >>
>> >> On Fri, Dec 2, 2016 at 12:56 PM, Gary Bisson
>> >> <gary.bisson@boundarydevices.com> wrote:
>> >> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
>> >> > ---
>> >> > Hi,
>> >> >
>> >> > Seems that this configuration is missing, especially since many
>> >> > device trees are already using "spidev" nodes.
>> >>
>>
>> This seems to have been added just because people weren't looking that
>> closer to DT patches at the beginning, but now is forbidden. That's
>> why the kernel now warns about it.
>>
>> >> Then they will trigger the following warning below (from the spidev
>> >> probe function):
>> >>
>> >> /*
>> >> * spidev should never be referenced in DT without a specific
>> >> * compatible string, it is a Linux implementation thing
>> >> * rather than a description of the hardware.
>> >> */
>> >> if (spi->dev.of_node && !of_match_device(spidev_dt_ids, &spi->dev)) {
>> >> dev_err(&spi->dev, "buggy DT: spidev listed directly in DT\n");
>> >> WARN_ON(spi->dev.of_node &&
>> >> !of_match_device(spidev_dt_ids, &spi->dev));
>> >> }
>> >
>> > Yes I've seen this WARN_ON when doing the dt-overlay testing. But is
>> > disabling the SPIDEV configuration a solution?
>> >
>> > To be honest I disagree with that WARN_ON. Ok it means that the hardware
>> > isn't fully described in the device tree but for development platforms
>> > (such as ours or any rpi-like boards) the user can design his own
>> > daugher board with whatever SPI device on it. Then using the spidev
>> > interface is very convenient, so I don't understand what we are trying
>> > to forbid here.
>> >
>>
>> AFAICT, what we are trying to forbid is to have a Linux implementation
>> detail to creep into a Device Tree.
>>
>> It's OK to use the spidev interface but that's orthogonal on how the
>> device is instantiated from the DT. If you want to do that, the
>> correct approach is AFAIU to add a OF device ID entry in
>> drivers/spi/spidev.c and use that compatible string in your DT.
>
> I understand that the device tree isn't supposed to describe such
> generic "spidev" concept.
>
> And that argument to me is ok for final products where the hardware is
> fully defined. However I still believe that for development platforms
> this cannot be applied. My customers want to use the SPI bus to connect
> any device they want, and most of those customers don't want to mess
> with the kernel. For them, having a spidev node, just like it exists for
> i2cdev nodes, is ideal.
>
Yes, they are free to do it in their vendor tree DTBs. They just
shouldn't try to post their DTS for mainline inclusion :)
>> That way, the DT will describe the hardware instead of just a "spidev"
>> but you could use the spidev interface to access your SPI device.
>
> But then aren't you afraid that the person will use the first compatible
> that shows up (let's say "rohm,dh2228fv") and use it for all his spidev?
> In that case the driver is happy although the fact remains that any hw
> will be plugged behind. Or at the opposite, if everybody that uses
> spidev adds its own compatible I'm not sure it will benefit the drive
> code.
>
I agree with you that people adding random compatible strings to the
spidev OF device ID table will not scale either. I don't really have
an answer to that, I just mentioned what the SPI maintainers told me
last time I tried to do something similar for a different platform a
couple of years ago:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/303348.html
> Anyway, I appreciate your feedback.
>
> Regards,
> Gary
Best regards,
Javier
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Arnd Bergmann @ 2016-12-02 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAQ0ZWQkU6T=Fm4oZ1R5-zJEzErjroYAAJqU2TeNHfz=3UhYrg@mail.gmail.com>
On Monday, November 28, 2016 10:08:18 PM CET Shawn Guo wrote:
> On Sat, Nov 26, 2016 at 6:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> >> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> >> > GICR for multiple CPU can be described with start address and stride,
> >> > or with multiple address. Current multiple address and stride are
> >> > both used. Fix it.
> >> >
> >> > vmalloc patch 727a7f5a9 triggered this bug:
> >> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> >> > [ 0.097150] pgd = ffff000008602000
> >> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> >> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> >> > [ 0.097170] Modules linked in:
> >> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> >> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> >> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> >> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c
> >> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20
> >> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> >> >
> >> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> >>
> >> A Fixes: tag would be useful on a patch like this, to tell what patch
> >> introduced the problem. Please consider using them in the future.
> >>
> >> I've applied this one to fixes now.
> >
> > Hi Olof,
> >
> > I happened to still have this one in my todo folder as I must have
> > missed your reply, and I stumbled over it while looking for things
> > that may have gone missing.
> >
> > I don't see it in v4.9-rc6, did it get dropped accidentally?
>
> Please help get this into v4.9 if possible, as it is required to get
> v4.9 kernel boot up on ZTE ZX296718 SoC. Thanks.
>
> Shawn
>
Ok, applied both. Thanks,
Arnd
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Chen-Yu Tsai @ 2016-12-02 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <324c8820-aeea-3fad-0e02-1bdb8f675677@arm.com>
On Sat, Dec 3, 2016 at 12:10 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 02/12/16 14:32, Icenowy Zheng wrote:
>>
>>
>> 02.12.2016, 22:30, "Hans de Goede" <hdegoede@redhat.com>:
>>> Hi,
>>>
>>> On 02-12-16 15:22, Icenowy Zheng wrote:
>>>> 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>>>>> On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
>>>>>> > Something more interesting happened.
>>>>>> >
>>>>>> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>>>> > two USB Controllers exported at expansion bus as USB Type-A
>>>>>> > connectors.
>>>>>> >
>>>>>> > Also it exposes a analog A/V jack and a microphone.
>>>>>> >
>>>>>> > Should I enable {e,o}hci{2.3} in the device tree?
>>>>>>
>>>>>> Actually we should do this regardless of this extension board. The USB
>>>>>> pins are not multiplexed and are exposed on user accessible pins (just
>>>>>> not soldered, but that's a detail), so I think they qualify for DT
>>>>>> enablement. And even if a user can't use them, it doesn't hurt to have
>>>>>> them (since they are not multiplexed).
>>>>>
>>>>> My main concern about this is that we'll leave regulators enabled by
>>>>> default, for a minority of users. And that minority will prevent to do
>>>>> a proper power management when the times come since we'll have to keep
>>>>> that behaviour forever.
>>>>
>>>> I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>>>
>>> I don't think that will be necessary I'm pretty sure these extra usb
>>> ports do not have a regulator for the Vbus, they just hook directly
>>> to the 5V rail, can someone with a schematic check ?
>>
>> We seems to have still no schematics for the add-on board.
>
> From looking at the picture of that expansion board on the Aliexpress
> page and chasing the tracks, there is clearly no voltage regulator on
> there, it's just passive components. The 5V pin from the headers is
> routed forth and back between the two layers via some vias directly to
> the 5V pins of the USB sockets.
>
>> But something is sure is that there's no any regulator-related pins
>> on the add-on pinout. There's only USB DM and DP pins.
>>
>> So the Vbus must be directly connected to +5V.
>
> So yes, it is.
>
> But I think the question is moot anyways, since we don't provide DT
> support for that add-on board at that point anyways.
> One could imagine another board, though, which has regulators switched
> by GPIOs, but that would be their problem and they would have regulators
> specified in their specific DT snippet, then.
>
> So to summarize:
> - For that specific Orange Pi Zero board which we discuss the DT for
> there is no regulator support for the additional USB ports. Thus nothing
> we could turn off to save power.
> - A user could just take these USB brackets with pin headers that are so
> common in PCs to connect additional USB ports to the back of the box.
> One just needs to re-sort the pins, which is a matter of a minute.
> - As long as we don't provide any easy way of handling DT changes, we
> should enable the USB ports for the sake of the users of either those
> brackets or the expansion board. Any more sophisticated USB expansion
> board with regulators would need to amend the DT anyway.
>
> Does that make sense?
Sounds good to me.
ChenYu
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Florian Weimer @ 2016-12-02 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202114850.GQ1574@e103592.cambridge.arm.com>
On 12/02/2016 12:48 PM, Dave Martin wrote:
> On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote:
>
> [...]
>
>> We could add a system call to get the right stack size. But as it depends
>> on VL, I'm not sure what it looks like. Particularly if you need determine
>> the stack size before creating a thread that uses a specific VL setting.
>
> I missed this point previously -- apologies for that.
>
> What would you think of:
>
> set_vl(vl_for_new_thread);
> minsigstksz = get_minsigstksz();
> set_vl(my_vl);
>
> This avoids get_minsigstksz() requiring parameters -- which is mainly a
> concern because the parameters tomorrow might be different from the
> parameters today.
>
> If it is possible to create the new thread without any SVE-dependent code,
> then we could
>
> set_vl(vl_for_new_thread);
> new_thread_stack = malloc(get_minsigstksz());
> new_thread = create_thread(..., new_thread_stack);
> set_vl(my_vl);
>
> which has the nice property that the new thread directly inherits the
> configuration that was used for get_minsigstksz().
Because all SVE registers are caller-saved, it's acceptable to
temporarily reduce the VL value, I think. So this should work.
One complication is that both the kernel and the libc need to reserve
stack space, so the kernel-returned value and the one which has to be
used in reality will be different.
> However, it would be necessary to prevent GCC from moving any code
> across these statements -- in particular, SVE code that access VL-
> dependent data spilled on the stack is liable to go wrong if reordered
> with the above. So the sequence would need to go in an external
> function (or a single asm...)
I would talk to GCC folks?we have similar issues with changing the FPU
rounding mode, I assume.
Thanks,
Florian
^ permalink raw reply
* [PATCH 2/2] arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
From: Arnd Bergmann @ 2016-12-02 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ed75f674-feaf-9c4b-a995-3e815054918d@arm.com>
On Thursday, December 1, 2016 10:11:24 AM CET Sudeep Holla wrote:
> On 16/11/16 17:31, Sudeep Holla wrote:
> > The core and the cluster sleep state entry latencies can't be same as
> > cluster sleep involves more work compared to core level e.g. shared
> > cache maintenance.
> >
> > Experiments have shown on an average about 100us more latency for the
> > cluster sleep state compared to the core level sleep. This patch fixes
> > the entry latency for the cluster sleep state.
> >
> > Fixes: 28e10a8f3a03 ("arm64: dts: juno: Add idle-states to device tree")
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>
> > Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
> You missed to pick up this, I posted this along with vexpress config bus
> fix. Sorry for the confusion, I feel pull request are better/easier to
> track than single patches. I will send PR from next time if also prefer
> that. Let me know.
Ok, I've applied that to the 4.9-fixes branch. Thanks for double-checking.
Arnd
^ permalink raw reply
* [Linaro-acpi] [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Bjorn Helgaas @ 2016-12-02 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202104500.GE10776@rric.localdomain>
On Fri, Dec 02, 2016 at 11:45:00AM +0100, Robert Richter wrote:
> On 02.12.16 11:06:24, Tomasz Nowicki wrote:
> > On 02.12.2016 07:42, Duc Dang wrote:
>
> > >@@ -98,16 +98,16 @@ struct mcfg_fixup {
> > > { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
> > > &pci_thunder_ecam_ops }
> > > /* SoC pass1.x */
> > >- THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
> > >- THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
> > >- THUNDER_ECAM_QUIRK(2, 0),
> > >- THUNDER_ECAM_QUIRK(2, 1),
> > >- THUNDER_ECAM_QUIRK(2, 2),
> > >- THUNDER_ECAM_QUIRK(2, 3),
> > >- THUNDER_ECAM_QUIRK(2, 10),
> > >- THUNDER_ECAM_QUIRK(2, 11),
> > >- THUNDER_ECAM_QUIRK(2, 12),
> > >- THUNDER_ECAM_QUIRK(2, 13),
> > >+ THUNDER_PEM_QUIRK(2, 0UL), /* off-chip devices */
> > >+ THUNDER_PEM_QUIRK(2, 1UL), /* off-chip devices */
> > >+ THUNDER_ECAM_QUIRK(2, 0UL),
> > >+ THUNDER_ECAM_QUIRK(2, 1UL),
> > >+ THUNDER_ECAM_QUIRK(2, 2UL),
> > >+ THUNDER_ECAM_QUIRK(2, 3UL),
> > >+ THUNDER_ECAM_QUIRK(2, 10UL),
> > >+ THUNDER_ECAM_QUIRK(2, 11UL),
> > >+ THUNDER_ECAM_QUIRK(2, 12UL),
> > >+ THUNDER_ECAM_QUIRK(2, 13UL),
> > >
> >
> > The UL suffix is needed for *THUNDER_PEM_QUIRK* only. THUNDER_ECAM_QUIRK is
> > fine.
>
> We should better make the type cast part of the macro.
>
> + this:
>
> ---
> #define THUNDER_MCFG_RES(addr, node) \
> DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M)
> ---
>
> The args in the macro need parentheses.
Would you mind sending me a little incremental patch doing what you
want? I could try myself, but since I don't have an arm64 cross-build
setup, I'm working in the dark.
^ permalink raw reply
* ACPI namespace details for ARM64
From: Bjorn Helgaas @ 2016-12-02 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1d7424da-f9f8-68e3-5571-b9fc46f13a7f@redhat.com>
On Thu, Dec 01, 2016 at 11:52:00PM -0500, Jon Masters wrote:
> On 11/09/2016 05:05 PM, Bjorn Helgaas wrote:
> > The basic requirement is that the ACPI namespace should describe
> > *everything* that consumes address space unless there's another
> > standard way for the OS to find it [1, 2].
>
> ...and by the way, this was a key lesson for me, too. I had not
> fully internalized before that you don't just want to describe the
> ECAM region in the MCFG but you also need to ensure it's properly
> described in the ACPI namespace. Lots of good things learned.
I wish the ACPI spec contained explicit language to this effect, but
if it does, I haven't found it. There might be firmware people who
would disagree with it.
My rationale is that the OS may receive a device with no address
space assigned, and for the OS to safely assign space, it has to know
everything to avoid. The devil's advocate might argue that the OS
doesn't need full knowledge as long as firmware constrains every
device's _PRS to avoid the possibility of conflict. But that seems
like it would be impractical for non-trivial systems.
Bjorn
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: Alexandre Belloni @ 2016-12-02 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0232C0D@AcuExch.aculab.com>
On 02/12/2016 at 15:59:57 +0000, David Laight wrote :
> From: Alexandre Belloni
> > Sent: 01 December 2016 10:27
> > Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> > when needed.
>
> s/when needed/when the device is freed/
>
> > Suggested-by: Peter Rosin <peda@axentia.se>
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
> > drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > index 45bc997d0711..aec72fe8273c 100644
> > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
> > dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
> > goto err;
> > }
> > - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
> > + ep->ep.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ep%d",
> > + ep->index);
>
> Acually why bother mallocing such a small string at all.
> The maximum length is 12 bytes even if 'index' are unrestricted.
>
IIRC, using statically allocated string is failing somewhere is the USB
core but I don't remember all the details.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND PATCH V6 0/6] Add support for privileged mappings
From: Robin Murphy @ 2016-12-02 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480690509-13490-1-git-send-email-sricharan@codeaurora.org>
Hi Sricharan,
On 02/12/16 14:55, Sricharan R wrote:
> This series is a resend of the V5 that Mitch sent sometime back [2]
> All the patches are the same and i have just rebased. Not sure why this
> finally did not make it last time. The last patch in the previous
> series does not apply now [3], so just redid that. Also Copied the tags
> that he had from last time as well.
Heh, I was assuming this would be down to me to pick up. Vinod did have
some complaints last time about the commit message on the PL330 patch -
I did get as far as rewriting that and reworking onto my SMMU
changes[1], I just hadn't got round to sending it, so it fell onto the
"after the next merge window" pile.
I'd give some review comments, but they'd essentially be a diff against
that branch :)
Robin.
[1]:http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/mh/dma-priv
> The following patch to the ARM SMMU driver:
>
> commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
> Author: Robin Murphy <robin.murphy@arm.com>
> Date: Tue Jan 26 18:06:34 2016 +0000
>
> iommu/arm-smmu: Treat all device transactions as unprivileged
>
> started forcing all SMMU transactions to come through as "unprivileged".
> The rationale given was that:
>
> (1) There is no way in the IOMMU API to even request privileged
> mappings.
>
> (2) It's difficult to implement a DMA mapper that correctly models the
> ARM VMSAv8 behavior of unprivileged-writeable =>
> privileged-execute-never.
>
> This series rectifies (1) by introducing an IOMMU API for privileged
> mappings and implements it in io-pgtable-arm.
>
> This series rectifies (2) by introducing a new dma attribute
> (DMA_ATTR_PRIVILEGED) for users of the DMA API that need privileged
> mappings which are inaccessible to lesser-privileged execution levels, and
> implements it in the arm64 IOMMU DMA mapper. The one known user (pl330.c)
> is converted over to the new attribute.
>
> Jordan and Jeremy can provide more info on the use case if needed, but the
> high level is that it's a security feature to prevent attacks such as [1].
>
> [1] https://github.com/robclark/kilroy
> [2] https://lkml.org/lkml/2016/7/27/590
> [3] https://patchwork.kernel.org/patch/9250493/
>
> Changelog:
>
> v5..v6
> - Rebased all the patches and redid 6/6 as it does not apply in
> this code base.
>
> v4..v5
>
> - Simplified patch 4/6 (suggested by Robin Murphy).
>
> v3..v4
>
> - Rebased and reworked on linux next due to the dma attrs rework going
> on over there. Patches changed: 3/6, 4/6, and 5/6.
>
> v2..v3
>
> - Incorporated feedback from Robin:
> * Various comments and re-wordings.
> * Use existing bit definitions for IOMMU_PRIV implementation
> in io-pgtable-arm.
> * Renamed and redocumented dma_direction_to_prot.
> * Don't worry about executability in new DMA attr.
>
> v1..v2
>
> - Added a new DMA attribute to make executable privileged mappings
> work, and use that in the pl330 driver (suggested by Will).
>
> Jeremy Gebben (1):
> iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag
>
> Mitchel Humpherys (4):
> iommu: add IOMMU_PRIV attribute
> common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
> arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
> dmaengine: pl330: Make sure microcode is privileged
>
> Sricharan R (1):
> iommu/arm-smmu: Set privileged attribute to 'default' instead of
> 'unprivileged'
>
> Documentation/DMA-attributes.txt | 10 ++++++++++
> arch/arm64/mm/dma-mapping.c | 6 +++---
> drivers/dma/pl330.c | 6 ++++--
> drivers/iommu/arm-smmu.c | 2 +-
> drivers/iommu/dma-iommu.c | 10 ++++++++--
> drivers/iommu/io-pgtable-arm.c | 5 ++++-
> include/linux/dma-iommu.h | 3 ++-
> include/linux/dma-mapping.h | 7 +++++++
> include/linux/iommu.h | 1 +
> 9 files changed, 40 insertions(+), 10 deletions(-)
>
^ permalink raw reply
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Gary Bisson @ 2016-12-02 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=nSUfDT-bqHBm2e0XY55Qp4nH+66PriMqnix2RTsN0BNQ@mail.gmail.com>
Hi Javier,
Thanks for the quick feedback on the matter.
On Fri, Dec 02, 2016 at 12:44:42PM -0300, Javier Martinez Canillas wrote:
> Hello Gary,
>
> On Fri, Dec 2, 2016 at 12:27 PM, Gary Bisson
> <gary.bisson@boundarydevices.com> wrote:
> > Hi Fabio,
> >
> > On Fri, Dec 02, 2016 at 01:18:42PM -0200, Fabio Estevam wrote:
> >> Hi Gary,
> >>
> >> On Fri, Dec 2, 2016 at 12:56 PM, Gary Bisson
> >> <gary.bisson@boundarydevices.com> wrote:
> >> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> >> > ---
> >> > Hi,
> >> >
> >> > Seems that this configuration is missing, especially since many
> >> > device trees are already using "spidev" nodes.
> >>
>
> This seems to have been added just because people weren't looking that
> closer to DT patches at the beginning, but now is forbidden. That's
> why the kernel now warns about it.
>
> >> Then they will trigger the following warning below (from the spidev
> >> probe function):
> >>
> >> /*
> >> * spidev should never be referenced in DT without a specific
> >> * compatible string, it is a Linux implementation thing
> >> * rather than a description of the hardware.
> >> */
> >> if (spi->dev.of_node && !of_match_device(spidev_dt_ids, &spi->dev)) {
> >> dev_err(&spi->dev, "buggy DT: spidev listed directly in DT\n");
> >> WARN_ON(spi->dev.of_node &&
> >> !of_match_device(spidev_dt_ids, &spi->dev));
> >> }
> >
> > Yes I've seen this WARN_ON when doing the dt-overlay testing. But is
> > disabling the SPIDEV configuration a solution?
> >
> > To be honest I disagree with that WARN_ON. Ok it means that the hardware
> > isn't fully described in the device tree but for development platforms
> > (such as ours or any rpi-like boards) the user can design his own
> > daugher board with whatever SPI device on it. Then using the spidev
> > interface is very convenient, so I don't understand what we are trying
> > to forbid here.
> >
>
> AFAICT, what we are trying to forbid is to have a Linux implementation
> detail to creep into a Device Tree.
>
> It's OK to use the spidev interface but that's orthogonal on how the
> device is instantiated from the DT. If you want to do that, the
> correct approach is AFAIU to add a OF device ID entry in
> drivers/spi/spidev.c and use that compatible string in your DT.
I understand that the device tree isn't supposed to describe such
generic "spidev" concept.
And that argument to me is ok for final products where the hardware is
fully defined. However I still believe that for development platforms
this cannot be applied. My customers want to use the SPI bus to connect
any device they want, and most of those customers don't want to mess
with the kernel. For them, having a spidev node, just like it exists for
i2cdev nodes, is ideal.
> That way, the DT will describe the hardware instead of just a "spidev"
> but you could use the spidev interface to access your SPI device.
But then aren't you afraid that the person will use the first compatible
that shows up (let's say "rohm,dh2228fv") and use it for all his spidev?
In that case the driver is happy although the fact remains that any hw
will be plugged behind. Or at the opposite, if everybody that uses
spidev adds its own compatible I'm not sure it will benefit the drive
code.
Anyway, I appreciate your feedback.
Regards,
Gary
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Andre Przywara @ 2016-12-02 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11535601480689127@web2g.yandex.ru>
Hi,
On 02/12/16 14:32, Icenowy Zheng wrote:
>
>
> 02.12.2016, 22:30, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 02-12-16 15:22, Icenowy Zheng wrote:
>>> 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>>>> On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
>>>>> > Something more interesting happened.
>>>>> >
>>>>> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>>>>> > two USB Controllers exported at expansion bus as USB Type-A
>>>>> > connectors.
>>>>> >
>>>>> > Also it exposes a analog A/V jack and a microphone.
>>>>> >
>>>>> > Should I enable {e,o}hci{2.3} in the device tree?
>>>>>
>>>>> Actually we should do this regardless of this extension board. The USB
>>>>> pins are not multiplexed and are exposed on user accessible pins (just
>>>>> not soldered, but that's a detail), so I think they qualify for DT
>>>>> enablement. And even if a user can't use them, it doesn't hurt to have
>>>>> them (since they are not multiplexed).
>>>>
>>>> My main concern about this is that we'll leave regulators enabled by
>>>> default, for a minority of users. And that minority will prevent to do
>>>> a proper power management when the times come since we'll have to keep
>>>> that behaviour forever.
>>>
>>> I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>>
>> I don't think that will be necessary I'm pretty sure these extra usb
>> ports do not have a regulator for the Vbus, they just hook directly
>> to the 5V rail, can someone with a schematic check ?
>
> We seems to have still no schematics for the add-on board.
>From looking at the picture of that expansion board on the Aliexpress
page and chasing the tracks, there is clearly no voltage regulator on
there, it's just passive components. The 5V pin from the headers is
routed forth and back between the two layers via some vias directly to
the 5V pins of the USB sockets.
> But something is sure is that there's no any regulator-related pins
> on the add-on pinout. There's only USB DM and DP pins.
>
> So the Vbus must be directly connected to +5V.
So yes, it is.
But I think the question is moot anyways, since we don't provide DT
support for that add-on board at that point anyways.
One could imagine another board, though, which has regulators switched
by GPIOs, but that would be their problem and they would have regulators
specified in their specific DT snippet, then.
So to summarize:
- For that specific Orange Pi Zero board which we discuss the DT for
there is no regulator support for the additional USB ports. Thus nothing
we could turn off to save power.
- A user could just take these USB brackets with pin headers that are so
common in PCs to connect additional USB ports to the back of the box.
One just needs to re-sort the pins, which is a matter of a minute.
- As long as we don't provide any easy way of handling DT changes, we
should enable the USB ports for the sake of the users of either those
brackets or the expansion board. Any more sophisticated USB expansion
board with regulators would need to amend the DT anyway.
Does that make sense?
Cheers,
Andre.
^ permalink raw reply
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Fabio Estevam @ 2016-12-02 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=myE8V2+=ZT6CJR_ZVVDy7aOLL6D10PADAqDz5XMjeoww@mail.gmail.com>
On Fri, Dec 2, 2016 at 1:50 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> I guess I didn't make clear on my previous email, but I'm not against
> $SUBJECT. I think that the platforms that currently have nodes using
> "spidev" as compatible need to be cleaned up, and so I find it
> valuable to have this option enabled so people are aware of the issue.
Yes, agreed.
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: David Laight @ 2016-12-02 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102656.29041-1-alexandre.belloni@free-electrons.com>
From: Alexandre Belloni
> Sent: 01 December 2016 10:27
> Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> when needed.
s/when needed/when the device is freed/
> Suggested-by: Peter Rosin <peda@axentia.se>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 45bc997d0711..aec72fe8273c 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
> dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
> goto err;
> }
> - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
> + ep->ep.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ep%d",
> + ep->index);
Acually why bother mallocing such a small string at all.
The maximum length is 12 bytes even if 'index' are unrestricted.
David
^ permalink raw reply
* [PATCH 2/2] arm64: PMU: Reset PMSELR_EL0 to a sane value at boot time
From: Marc Zyngier @ 2016-12-02 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693859-27249-1-git-send-email-marc.zyngier@arm.com>
In order to avoid any ugly surprise, let's reset PMSELR_EL0 to the
first valid value (avoiding the cycle counter which has been proven
to be troublesome) at CPU boot time. This ensures that no guest will
be faced with some odd value which it cannot modify (due to
MDCR_EL2.TPM being set).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/perf_event.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index a65b757..42d1840 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -910,6 +910,14 @@ static void armv8pmu_reset(void *info)
*/
armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C |
ARMV8_PMU_PMCR_LC);
+
+ /*
+ * If we have at least one available counter, reset to that
+ * one so that no illegal value is left in PMSELR_EL0, which
+ * could have an impact on a guest.
+ */
+ if (armv8pmu_counter_valid(cpu_pmu, ARMV8_IDX_COUNTER0))
+ armv8pmu_select_counter(ARMV8_IDX_COUNTER0);
}
static int armv8_pmuv3_map_event(struct perf_event *event)
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] arm64: PMU: Do not use PMSELR_EL0 to access PMCCFILTR_EL0
From: Marc Zyngier @ 2016-12-02 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693859-27249-1-git-send-email-marc.zyngier@arm.com>
The ARMv8 architecture allows the cycle counter to be configured
by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
hence accessing PMCCFILTR_EL0. But it disallows the use of
PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
PMXEVCNTR_EL0.
Linux itself doesn't violate this rule, but we may end up with
PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
despite the guest not having done anything wrong.
In order to avoid this unfortunate course of events (haha!), let's
apply the same method armv8pmu_write_counter and co are using,
explicitely checking for the cycle counter and writing to
PMCCFILTR_EL0 directly. This prevents writing 0x1f to PMSELR_EL0,
and saves a Linux guest an extra trap.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/perf_event.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 57ae9d9..a65b757 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -632,7 +632,10 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
static inline void armv8pmu_write_evtype(int idx, u32 val)
{
- if (armv8pmu_select_counter(idx) == idx) {
+ if (idx == ARMV8_IDX_CYCLE_COUNTER) {
+ val &= ARMV8_PMU_EVTYPE_MASK & ~ARMV8_PMU_EVTYPE_EVENT;
+ write_sysreg(val, pmccfiltr_el0);
+ } else if (armv8pmu_select_counter(idx) == idx) {
val &= ARMV8_PMU_EVTYPE_MASK;
write_sysreg(val, pmxevtyper_el0);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] arm64: PMU: Sanitize usage of PMSELR_EL0.SEL
From: Marc Zyngier @ 2016-12-02 15:50 UTC (permalink / raw)
To: linux-arm-kernel
An ugly interaction between the use of PMSELR_EL0 in a host kernel and
the use of PMXEVCNTR_EL0 in a guest has recently come to light [1],
leading to the guest taking an UNDEF exception in EL1 when using the
PMU.
The fix is pretty simple ("don't do that!"), making the PMU useable on
X-Gene, which seems to have a stricter (but nonetheless valid)
interpretation of the architecture.
Patches against 4.9-rc6.
[1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-November/022545.html
Marc Zyngier (2):
arm64: PMU: Do not use PMSELR_EL0 to access PMCCFILTR_EL0
arm64: PMU: Reset PMSELR_EL0 to a sane value at boot time
arch/arm64/kernel/perf_event.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--
2.1.4
^ permalink raw reply
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Javier Martinez Canillas @ 2016-12-02 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=nSUfDT-bqHBm2e0XY55Qp4nH+66PriMqnix2RTsN0BNQ@mail.gmail.com>
Hello Gary,
On Fri, Dec 2, 2016 at 12:44 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
[snip]
>
> This seems to have been added just because people weren't looking that
> closer to DT patches at the beginning, but now is forbidden. That's
> why the kernel now warns about it.
>
>>> Then they will trigger the following warning below (from the spidev
>>> probe function):
>>>
I guess I didn't make clear on my previous email, but I'm not against
$SUBJECT. I think that the platforms that currently have nodes using
"spidev" as compatible need to be cleaned up, and so I find it
valuable to have this option enabled so people are aware of the issue.
Best regards,
Javier
^ permalink raw reply
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Javier Martinez Canillas @ 2016-12-02 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202152718.o4xv2ru5r7xw7t5e@t450s.lan>
Hello Gary,
On Fri, Dec 2, 2016 at 12:27 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> Hi Fabio,
>
> On Fri, Dec 02, 2016 at 01:18:42PM -0200, Fabio Estevam wrote:
>> Hi Gary,
>>
>> On Fri, Dec 2, 2016 at 12:56 PM, Gary Bisson
>> <gary.bisson@boundarydevices.com> wrote:
>> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
>> > ---
>> > Hi,
>> >
>> > Seems that this configuration is missing, especially since many
>> > device trees are already using "spidev" nodes.
>>
This seems to have been added just because people weren't looking that
closer to DT patches at the beginning, but now is forbidden. That's
why the kernel now warns about it.
>> Then they will trigger the following warning below (from the spidev
>> probe function):
>>
>> /*
>> * spidev should never be referenced in DT without a specific
>> * compatible string, it is a Linux implementation thing
>> * rather than a description of the hardware.
>> */
>> if (spi->dev.of_node && !of_match_device(spidev_dt_ids, &spi->dev)) {
>> dev_err(&spi->dev, "buggy DT: spidev listed directly in DT\n");
>> WARN_ON(spi->dev.of_node &&
>> !of_match_device(spidev_dt_ids, &spi->dev));
>> }
>
> Yes I've seen this WARN_ON when doing the dt-overlay testing. But is
> disabling the SPIDEV configuration a solution?
>
> To be honest I disagree with that WARN_ON. Ok it means that the hardware
> isn't fully described in the device tree but for development platforms
> (such as ours or any rpi-like boards) the user can design his own
> daugher board with whatever SPI device on it. Then using the spidev
> interface is very convenient, so I don't understand what we are trying
> to forbid here.
>
AFAICT, what we are trying to forbid is to have a Linux implementation
detail to creep into a Device Tree.
It's OK to use the spidev interface but that's orthogonal on how the
device is instantiated from the DT. If you want to do that, the
correct approach is AFAIU to add a OF device ID entry in
drivers/spi/spidev.c and use that compatible string in your DT.
That way, the DT will describe the hardware instead of just a "spidev"
but you could use the spidev interface to access your SPI device.
> Regards,
> Gary
>
Best regards,
Javier
^ permalink raw reply
* [PATCH v2 3/3] ARM: da850: fix da850_set_pll0rate()
From: Bartosz Golaszewski @ 2016-12-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693134-31324-1-git-send-email-bgolaszewski@baylibre.com>
This function is broken - its second argument is an index to the freq
table, not the requested clock rate in Hz. It leads to an oops when
called from clk_set_rate() since this argument isn't bounds checked
either.
Fix it by iterating over the array of supported frequencies and
selecting a one that matches or returning -EINVAL for unsupported
rates.
Also: update the davinci cpufreq driver. It's the only user of this
clock and currently it passes the cpufreq table index to
clk_set_rate(), which is confusing. Make it pass the requested clock
rate in Hz.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 22 ++++++++++++++++++----
drivers/cpufreq/davinci-cpufreq.c | 2 +-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index a55101c..92e3303 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1179,14 +1179,28 @@ static int da850_set_armrate(struct clk *clk, unsigned long index)
return clk_set_rate(pllclk, index);
}
-static int da850_set_pll0rate(struct clk *clk, unsigned long index)
+static int da850_set_pll0rate(struct clk *clk, unsigned long rate)
{
- unsigned int prediv, mult, postdiv;
- struct da850_opp *opp;
struct pll_data *pll = clk->pll_data;
+ struct cpufreq_frequency_table *freq;
+ unsigned int prediv, mult, postdiv;
+ struct da850_opp *opp = NULL;
int ret;
- opp = (struct da850_opp *) cpufreq_info.freq_table[index].driver_data;
+ for (freq = da850_freq_table;
+ freq->frequency != CPUFREQ_TABLE_END; freq++) {
+ /* requested_rate is in Hz, freq->frequency is in KHz */
+ unsigned long freq_rate = freq->frequency * 1000;
+
+ if (freq_rate == rate) {
+ opp = (struct da850_opp *)freq->driver_data;
+ break;
+ }
+ }
+
+ if (opp == NULL)
+ return -EINVAL;
+
prediv = opp->prediv;
mult = opp->mult;
postdiv = opp->postdiv;
diff --git a/drivers/cpufreq/davinci-cpufreq.c b/drivers/cpufreq/davinci-cpufreq.c
index b95a872..d54a27c 100644
--- a/drivers/cpufreq/davinci-cpufreq.c
+++ b/drivers/cpufreq/davinci-cpufreq.c
@@ -55,7 +55,7 @@ static int davinci_target(struct cpufreq_policy *policy, unsigned int idx)
return ret;
}
- ret = clk_set_rate(armclk, idx);
+ ret = clk_set_rate(armclk, new_freq * 1000);
if (ret)
return ret;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] ARM: da850: coding style fix
From: Bartosz Golaszewski @ 2016-12-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693134-31324-1-git-send-email-bgolaszewski@baylibre.com>
Fix alignment of the clock lookup table entries.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 1fcc986..a55101c 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -548,7 +548,7 @@ static struct clk_lookup da850_clks[] = {
CLK("spi_davinci.0", NULL, &spi0_clk),
CLK("spi_davinci.1", NULL, &spi1_clk),
CLK("vpif", NULL, &vpif_clk),
- CLK("ahci_da850", NULL, &sata_clk),
+ CLK("ahci_da850", NULL, &sata_clk),
CLK("davinci-rproc.0", NULL, &dsp_clk),
CLK(NULL, NULL, &ehrpwm_clk),
CLK("ehrpwm.0", "fck", &ehrpwm0_clk),
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/3] ARM: da850: fix infinite loop in clk_set_rate()
From: Bartosz Golaszewski @ 2016-12-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693134-31324-1-git-send-email-bgolaszewski@baylibre.com>
The aemif clock is added twice to the lookup table in da850.c. This
breaks the children list of pll0_sysclk3 as we're using the same list
links in struct clk. When calling clk_set_rate(), we get stuck in
propagate_rate().
Create a separate clock for nand, inheriting the rate of the aemif
clock and retrieve it in the davinci_nand module.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 7 ++++++-
drivers/mtd/nand/davinci_nand.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index e770c97..1fcc986 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -367,6 +367,11 @@ static struct clk aemif_clk = {
.flags = ALWAYS_ENABLED,
};
+static struct clk nand_clk = {
+ .name = "nand",
+ .parent = &aemif_clk,
+};
+
static struct clk usb11_clk = {
.name = "usb11",
.parent = &pll0_sysclk4,
@@ -537,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
- CLK(NULL, "aemif", &aemif_clk),
+ CLK(NULL, "nand", &nand_clk),
CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 27fa8b8..5857d06 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -694,7 +694,7 @@ static int nand_davinci_probe(struct platform_device *pdev)
ret = -EINVAL;
- info->clk = devm_clk_get(&pdev->dev, "aemif");
+ info->clk = devm_clk_get(&pdev->dev, "nand");
if (IS_ERR(info->clk)) {
ret = PTR_ERR(info->clk);
dev_dbg(&pdev->dev, "unable to get AEMIF clock, err %d\n", ret);
--
2.9.3
^ 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