* [PATCH v2 0/3] ARM: dts: sun7i: BPI-M1+ USB support
From: Chen-Yu Tsai @ 2016-11-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Maxime,
These are the remaining patches of my BPI-M1+ fixes series from July.
Changes since v1:
- Split out USB PHY enable patch.
- Dropped custom OPP table. Tested the A20 default one with
cpufreq-ljt-stress-test and it seemed stable.
- Dropped voltage range for cpu supply regulator to normal 1.0V ~ 1.4V.
- Dropped pinmux setting for OTG ID pin.
Please have a look.
Regards
ChenYu
Chen-Yu Tsai (3):
ARM: dts: sun7i: bananapi-m1-plus: Enable USB PHY for USB host support
ARM: dts: sun7i: bananapi-m1-plus: Add PMIC regulators
ARM: dts: sun7i: bananapi-m1-plus: Enable USB OTG
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 60 ++++++++++++++++++++++--
1 file changed, 56 insertions(+), 4 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: sun7i: bananapi-m1-plus: Enable USB PHY for USB host support
From: Chen-Yu Tsai @ 2016-11-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115135106.438-1-wens@csie.org>
The 2 USB host ports are directly tied to the 2 USB hosts in the SoC.
The 2 host pairs were already enabled, but the USB PHY wasn't.
VBUS on the 2 ports are always on.
Enable the USB PHY.
Fixes: 04c85ecad32a ("ARM: dts: sun7i: Add dts file for Bananapi M1 Plus
board")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index ba5bca0fe997..44377a98cc89 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -227,3 +227,8 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+
+&usbphy {
+ /* VBUS on usb host ports are tied to DC5V and therefore always on */
+ status = "okay";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: sun7i: bananapi-m1-plus: Add PMIC regulators
From: Chen-Yu Tsai @ 2016-11-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115135106.438-1-wens@csie.org>
The Bananapi M1+, like other Allwinner A20 based boards, uses the
AXP209 PMIC to supply its power.
Add the AXP209 regulators.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 35 +++++++++++++++++++++---
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index 44377a98cc89..ac19630c1c23 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -105,6 +105,10 @@
status = "okay";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci0 {
status = "okay";
};
@@ -132,16 +136,14 @@
status = "okay";
axp209: pmic at 34 {
- compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
};
};
+#include "axp209.dtsi"
+
&ir0 {
pinctrl-names = "default";
pinctrl-0 = <&ir0_rx_pins_a>;
@@ -222,6 +224,31 @@
};
};
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: sun7i: bananapi-m1-plus: Enable USB OTG
From: Chen-Yu Tsai @ 2016-11-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115135106.438-1-wens@csie.org>
The Bananapi M1+ supports USB OTG, with the PMIC doing VBUS sensing.
Enable the USB OTG related functions.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index ac19630c1c23..5f7114e13850 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -194,6 +194,10 @@
status = "okay";
};
+&otg_sram {
+ status = "okay";
+};
+
&pio {
gmac_power_pin_bpi_m1p: gmac_power_pin at 0 {
allwinner,pins = "PH23";
@@ -249,13 +253,29 @@
regulator-name = "avcc";
};
+®_usb0_vbus {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usb_power_supply {
+ status = "okay";
+};
+
&usbphy {
+ usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_power-supply = <&usb_power_supply>;
+ usb0_vbus-supply = <®_usb0_vbus>;
/* VBUS on usb host ports are tied to DC5V and therefore always on */
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-15 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d42546d-5917-891c-2b18-ccf7f7328624@redhat.com>
On 11/15/2016 02:48 PM, Hans de Goede wrote:
> Hi,
>
> On 15-11-16 14:28, Jacek Anaszewski wrote:
>> On 11/15/2016 01:06 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 15-11-16 12:48, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>>>> The LED you are talking about _has_ a trigger, implemented in
>>>>>>>> hardware. That trigger can change LED brightness behind kernel's
>>>>>>>> (and
>>>>>>>> userspace's) back. Don't pretend the trigger does not exist, it
>>>>>>>> does.
>>>>>>>>
>>>>>>>> And when you do that, you'll have nice place to report changes to
>>>>>>>> userspace -- trigger can now export that information, and offer
>>>>>>>> poll()
>>>>>>>> interface.
>>>>>>>
>>>>>>> Well, that sounds interesting. It is logically justifiable.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>> I initially proposed exactly this solution, with recently
>>>>>>> added userspace LED being a trigger listener. It seems a bit
>>>>>>> awkward though. How would you listen to the trigger events?
>>>>>>
>>>>>> Trigger exposes a file in sysfs, with poll() working on that file
>>>>>
>>>>> Hmm, a new file would give the advantage of making it easy for
>>>>> userspace to see if the trigger is poll-able, this is likely
>>>>> better then my own proposal I just send.
>>>>
>>>> Good.
>>>>
>>>>>> (and
>>>>>> probably read exposing the current brightness).
>>>>>
>>>>> If we do this, can we please make it mirror brightness, iow
>>>>> also make it writable, that will make it easier for userspace
>>>>> to deal with it. We can simply re-use the existing show / store
>>>>> methods for brightness for this.
>>>>
>>>> Actually, echo 0 > brightness disables the trigger, IIRC. I'd avoid
>>>> that here, you want to be able to turn off the backlight but still
>>>> keep the trigger (and be notified of future changes).
>>>
>>> True, that is easy to do the store method will just need to call
>>> led_set_brightness_nosleep instead of led_set_brightness, this
>>> will skip the checks to stop blinking in led_set_brightness and
>>> otherwise is equivalent.
>>>
>>>>> I suggest we call it:
>>>>>
>>>>> trigger_brightness
>>>>>
>>>>> And only register it when a poll-able trigger is present.
>>>>
>>>> I'd call it 'current_brightness', but that's no big deal. Yes, only
>>>> registering it for poll-able triggers makes sense.
>>>
>>> current_brightness works for me. I will take a shot a patch-set
>>> implementing this.
>>
>> Word "current" is not precise here.
>>
>> It can be thought of as either last brightness set by the
>> user or the brightness currently written to the device
>> (returned by brightness file).
>>
>> There is a semantic discrepancy in our requirements -
>> we want the file representing both permanent brightness
>> set by the user and brightness set by the hardware.
>>
>> The two stand in contradiction to each other since
>> brightness set by the user can be adjusted by the hardware.
>>
>> Reading the file shouldn't update brightness property of
>> struct led_classdev, so it shouldn't call led_update_brightness()
>> but it still should allow reading brightness set by the
>> hardware, as a result of each POLLPRI event. So in fact in
>> the same time it should report both according to our requirements
>> which is impossible. Do we need three brightness files ?
>
> I don't think so, current_brightness actually is an accurate
> name, if the brightness was last changed by writing from
> sysfs, the keyboard backlight will honor that and the current_brightness
> attribute will show the brightness last set through writing it,
> which matches the actual current brightness of the keyboard backlight.
>
> Likewise if it was changed with the hotkey last then the keyboard
> backlight brightness will be changed and reading from current_brightness
> will return the new actual brightness. Basically reading from this
> file will be no different then reading from the normal "brightness"
> file the difference will be in that it is poll-able and that
> writing 0 turns off the LED without stopping blinking.
If so then when software blinking enabled, it will return 0 on low
blink cycle no matter what current brightness level is.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] ARM64: zynqmp: Fix W=1 dtc 1.4 warnings
From: Michal Simek @ 2016-11-15 14:04 UTC (permalink / raw)
To: linux-arm-kernel
The patch removes these warnings reported by dtc 1.4:
Warning (unit_address_vs_reg): Node /amba_apu has a reg or ranges
property, but no unit name
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 2 +-
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index 358089687a69..ef1b9e573af0 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -27,7 +27,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x40000000>;
};
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 68a908334c7b..83791eadff41 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -72,7 +72,7 @@
<1 10 0xf08>;
};
- amba_apu {
+ amba_apu: amba_apu at 0 {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: zynq: Remove skeleton.dtsi
From: Michal Simek @ 2016-11-15 14:07 UTC (permalink / raw)
To: linux-arm-kernel
Based on
"ARM: dts: explicitly mark skeleton.dtsi as deprecated"
(sha1: 9c0da3cc61f1233c2782e2d3d91e3d0707dd4ba5)
skeleton.dtsi is deprecated.
Move address and size-cells directly to zynq-7000.dtsi.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/boot/dts/zynq-7000.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index f283ff08381c..f47a6c1cc752 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -10,9 +10,10 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
-/include/ "skeleton.dtsi"
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "xlnx,zynq-7000";
cpus {
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: zynq: Fix W=1 dtc 1.4 warnings
From: Michal Simek @ 2016-11-15 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d42e25d7dd03e562e12e71fd037837737115940.1479218844.git.michal.simek@xilinx.com>
The patch removes these warnings reported by dtc 1.4:
Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property,
but no unit name
Warning (unit_address_vs_reg): Node /fixedregulator at 0 has a unit name,
but no reg property
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
arch/arm/boot/dts/zynq-parallella.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
arch/arm/boot/dts/zynq-zybo.dts | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index f47a6c1cc752..402b5bbe3b5b 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -42,14 +42,14 @@
};
};
- pmu {
+ pmu at f8891000 {
compatible = "arm,cortex-a9-pmu";
interrupts = <0 5 4>, <0 6 4>;
interrupt-parent = <&intc>;
reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
};
- regulator_vccpint: fixedregulator at 0 {
+ regulator_vccpint: fixedregulator {
compatible = "regulator-fixed";
regulator-name = "VCCPINT";
regulator-min-microvolt = <1000000>;
diff --git a/arch/arm/boot/dts/zynq-parallella.dts b/arch/arm/boot/dts/zynq-parallella.dts
index 307ed201d658..64a6390fc501 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -28,7 +28,7 @@
serial0 = &uart1;
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x0 0x40000000>;
};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index e96959b2e67a..0cdad2cc8b78 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -24,7 +24,7 @@
serial0 = &uart1;
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x0 0x40000000>;
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index be6a986bbbd8..ad4bb06dba25 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -24,7 +24,7 @@
serial0 = &uart1;
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x0 0x40000000>;
};
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 7250c1eac7f9..325379f7983c 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -23,7 +23,7 @@
serial0 = &uart1;
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x0 0x20000000>;
};
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
index d9e0f3e70671..590ec24b8749 100644
--- a/arch/arm/boot/dts/zynq-zybo.dts
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -23,7 +23,7 @@
serial0 = &uart1;
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x0 0x20000000>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-15 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gh9qB41zcnvnETDA-5ho577uhxE4rehZqEXorFViY__w@mail.gmail.com>
On Tue, Nov 15, 2016 at 02:04:09PM +0100, Rafael J. Wysocki wrote:
> On Tue, Nov 15, 2016 at 11:12 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Hi Rafael,
> >
> > On Thu, Nov 10, 2016 at 12:36:12AM +0100, Rafael J. Wysocki wrote:
> >> Hi Lorenzo,
> >>
> >> On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
> >> <lorenzo.pieralisi@arm.com> wrote:
> >> > This patch series is v7 of a previous posting:
> >> >
> >> > https://lkml.org/lkml/2016/10/18/506
> >>
> >> I don't see anything objectionable in this series.
> >>
> >> Please let me know which patches in particular to look at in detail.
> >
> > Are patches 7 and consequently 16 (that builds on top of 7) ok with
> > you ? They should be equivalent to nop on anything other than ARM64
> > but they touch ACPI core so they require an ACK if they are ok please.
>
> Yes, they are. Please feel free to add my ACKs to those or I will
> send them separately later today.
Thank you very much, I will add them to v8 that should be final,
I will send it when the dust has settled on patch 4, which looks
like the last bit to sort out (we may not even need a v8 at all).
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Ard Biesheuvel @ 2016-11-15 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018234200.5804-1-sboyd@codeaurora.org>
On 19 October 2016 at 00:42, Stephen Boyd <sboyd@codeaurora.org> wrote:
> In similar spirit to x86 and arm64 support, add a make_nop_arm()
> to replace calls to mcount with a nop in sections that aren't
> traced.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Acked-by: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> scripts/recordmcount.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
> index 5423a58d1b06..aeb34223167c 100644
> --- a/scripts/recordmcount.c
> +++ b/scripts/recordmcount.c
> @@ -213,6 +213,59 @@ static int make_nop_x86(void *map, size_t const offset)
> return 0;
> }
>
> +static unsigned char ideal_nop4_arm_le[4] = { 0x00, 0x00, 0xa0, 0xe1 }; /* mov r0, r0 */
> +static unsigned char ideal_nop4_arm_be[4] = { 0xe1, 0xa0, 0x00, 0x00 }; /* mov r0, r0 */
Shouldn't you be taking the difference between BE8 and BE32 into
account here? IIRC, BE8 uses little endian encoding for instructions.
> +static unsigned char *ideal_nop4_arm;
> +
> +static unsigned char bl_mcount_arm_le[4] = { 0xfe, 0xff, 0xff, 0xeb }; /* bl */
> +static unsigned char bl_mcount_arm_be[4] = { 0xeb, 0xff, 0xff, 0xfe }; /* bl */
> +static unsigned char *bl_mcount_arm;
> +
> +static unsigned char push_arm_le[4] = { 0x04, 0xe0, 0x2d, 0xe5 }; /* push {lr} */
> +static unsigned char push_arm_be[4] = { 0xe5, 0x2d, 0xe0, 0x04 }; /* push {lr} */
> +static unsigned char *push_arm;
> +
> +static unsigned char ideal_nop2_thumb_le[2] = { 0x00, 0xbf }; /* nop */
> +static unsigned char ideal_nop2_thumb_be[2] = { 0xbf, 0x00 }; /* nop */
> +static unsigned char *ideal_nop2_thumb;
> +
> +static unsigned char push_bl_mcount_thumb_le[6] = { 0x00, 0xb5, 0xff, 0xf7, 0xfe, 0xff }; /* push {lr}, bl */
> +static unsigned char push_bl_mcount_thumb_be[6] = { 0xb5, 0x00, 0xf7, 0xff, 0xff, 0xfe }; /* push {lr}, bl */
> +static unsigned char *push_bl_mcount_thumb;
> +
> +static int make_nop_arm(void *map, size_t const offset)
> +{
> + char *ptr;
> + int cnt = 1;
> + int nop_size;
> + size_t off = offset;
> +
> + ptr = map + offset;
> + if (memcmp(ptr, bl_mcount_arm, 4) == 0) {
> + if (memcmp(ptr - 4, push_arm, 4) == 0) {
> + off -= 4;
> + cnt = 2;
> + }
> + ideal_nop = ideal_nop4_arm;
> + nop_size = 4;
> + } else if (memcmp(ptr - 2, push_bl_mcount_thumb, 6) == 0) {
> + cnt = 3;
> + nop_size = 2;
> + off -= 2;
> + ideal_nop = ideal_nop2_thumb;
> + } else
> + return -1;
> +
> + /* Convert to nop */
> + ulseek(fd_map, off, SEEK_SET);
> +
> + do {
> + uwrite(fd_map, ideal_nop, nop_size);
> + } while (--cnt > 0);
> +
> + return 0;
> +}
> +
> static unsigned char ideal_nop4_arm64[4] = {0x1f, 0x20, 0x03, 0xd5};
> static int make_nop_arm64(void *map, size_t const offset)
> {
> @@ -430,6 +483,11 @@ do_file(char const *const fname)
> w2 = w2rev;
> w8 = w8rev;
> }
> + ideal_nop4_arm = ideal_nop4_arm_le;
> + bl_mcount_arm = bl_mcount_arm_le;
> + push_arm = push_arm_le;
> + ideal_nop2_thumb = ideal_nop2_thumb_le;
> + push_bl_mcount_thumb = push_bl_mcount_thumb_le;
> break;
> case ELFDATA2MSB:
> if (*(unsigned char const *)&endian != 0) {
> @@ -438,6 +496,11 @@ do_file(char const *const fname)
> w2 = w2rev;
> w8 = w8rev;
> }
> + ideal_nop4_arm = ideal_nop4_arm_be;
> + bl_mcount_arm = bl_mcount_arm_be;
> + push_arm = push_arm_be;
> + ideal_nop2_thumb = ideal_nop2_thumb_be;
> + push_bl_mcount_thumb = push_bl_mcount_thumb_be;
> break;
> } /* end switch */
> if (memcmp(ELFMAG, ehdr->e_ident, SELFMAG) != 0
> @@ -463,6 +526,8 @@ do_file(char const *const fname)
> break;
> case EM_ARM: reltype = R_ARM_ABS32;
> altmcount = "__gnu_mcount_nc";
> + make_nop = make_nop_arm;
> + rel_type_nop = R_ARM_NONE;
> break;
> case EM_AARCH64:
> reltype = R_AARCH64_ABS64;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] STM32 SOC changes for v4.10 #1
From: Alexandre Torgue @ 2016-11-15 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider this first round of STM32 SOC updates for v4.10:
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
tags/soc-for-4.10-1
for you to fetch changes up to 6bc18b83c0c3b5d56137a31ce98ca2802036e7a9:
ARM: Kconfig: Introduce MACH_STM32F746 flag (2016-11-15 12:02:59 +0100)
----------------------------------------------------------------
STM32 SOC updates for v4.10, round 1.
Highlights:
----------
- Add new MCU SOC STM32F746
----------------------------------------------------------------
Alexandre TORGUE (2):
ARM: mach-stm32: Add a new SOC - STM32F746
ARM: Kconfig: Introduce MACH_STM32F746 flag
Documentation/arm/stm32/overview.txt | 3 ++-
Documentation/arm/stm32/stm32f746-overview.txt | 34
++++++++++++++++++++++++++
arch/arm/Kconfig | 5 ++++
arch/arm/mach-stm32/board-dt.c | 1 +
4 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 Documentation/arm/stm32/stm32f746-overview.txt
^ permalink raw reply
* [PATCH] arm/arm64: KVM: VGIC: limit ITARGETSR bits to number of VCPUs
From: Andre Przywara @ 2016-11-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
The GICv2 spec says in section 4.3.12 that a "CPU targets field bit that
corresponds to an unimplemented CPU interface is RAZ/WI."
Currently we allow the guest to write any value in there and it can
read that back.
Mask the written value with the proper CPU mask to be spec compliant.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
virt/kvm/arm/vgic/vgic-mmio-v2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
index b44b359..e59d4c7 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
@@ -129,6 +129,7 @@ static void vgic_mmio_write_target(struct kvm_vcpu *vcpu,
unsigned long val)
{
u32 intid = VGIC_ADDR_TO_INTID(addr, 8);
+ u8 cpu_mask = (1 << atomic_read(&vcpu->kvm->online_vcpus)) - 1;
int i;
/* GICD_ITARGETSR[0-7] are read-only */
@@ -141,7 +142,7 @@ static void vgic_mmio_write_target(struct kvm_vcpu *vcpu,
spin_lock(&irq->irq_lock);
- irq->targets = (val >> (i * 8)) & 0xff;
+ irq->targets = ((val >> (i * 8)) & 0xff) & cpu_mask;
target = irq->targets ? __ffs(irq->targets) : 0;
irq->target_vcpu = kvm_get_vcpu(vcpu->kvm, target);
--
2.9.0
^ permalink raw reply related
* [PATCH net 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Jerome Brunet @ 2016-11-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
Initially reported as a low Tx throughput issue at gigabit speed, the
platform enters LPI too often. This eventually break the link (both Tx
and Rx), and require to bring the interface down and up again to get the
Rx path working again.
The root cause of this issue is not fully understood yet but disabling EEE
advertisement on the PHY prevent this feature to be negotiated.
With this change, the link is stable and reliable, with the expected
throughput performance.
The patchset adds options in the realtek phy driver to disable EEE
advertisement, through device tree, for the phy version supporting EEE.
Then EEE is disabled in the OdroidC2 device tree for Gigabit speed.
100M is not affected by this issue.
Jerome Brunet (3):
net: phy: realtek: add eee advertisement disable options
dt-bindings: net: add DT bindings for realtek phys
ARM64: dts: meson: odroidc2: disable 1000t-eee advertisement
.../devicetree/bindings/net/realtek-phy.txt | 20 +++++++
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++++
drivers/net/phy/realtek.c | 65 +++++++++++++++++++++-
3 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/realtek-phy.txt
--
2.7.4
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-1-git-send-email-jbrunet@baylibre.com>
On some platforms, energy efficient ethernet with rtl8211 devices is
causing issue, like throughput drop or broken link.
This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
cause is not fully understood yet, disabling EEE advertisement prevent auto
negotiation from enabling EEE.
This patch provides options to disable 1000T and 100TX EEE advertisement
individually for the realtek phys supporting this feature.
Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Andre Roth <neolynx@gmail.com>
---
drivers/net/phy/realtek.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index aadd6e9f54ad..77235fd5faaf 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -15,6 +15,12 @@
*/
#include <linux/phy.h>
#include <linux/module.h>
+#include <linux/of.h>
+
+struct rtl8211x_phy_priv {
+ bool eee_1000t_disable;
+ bool eee_100tx_disable;
+};
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX 0x2000
@@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct phy_device *phydev)
return err;
}
+static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
+{
+ struct rtl8211x_phy_priv *priv = phydev->priv;
+ u16 val;
+
+ if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
+ val = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
+ MDIO_MMD_AN);
+
+ if (priv->eee_1000t_disable)
+ val &= ~MDIO_AN_EEE_ADV_1000T;
+ if (priv->eee_100tx_disable)
+ val &= ~MDIO_AN_EEE_ADV_100TX;
+
+ phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
+ MDIO_MMD_AN, val);
+ }
+}
+
+static int rtl8211x_config_init(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = genphy_config_init(phydev);
+ if (ret < 0)
+ return ret;
+
+ rtl8211x_clear_eee_adv(phydev);
+
+ return 0;
+}
+
static int rtl8211f_config_init(struct phy_device *phydev)
{
int ret;
u16 reg;
- ret = genphy_config_init(phydev);
+ ret = rtl8211x_config_init(phydev);
if (ret < 0)
return ret;
@@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return 0;
}
+static int rtl8211x_phy_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct device_node *of_node = dev->of_node;
+ struct rtl8211x_phy_priv *priv;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->eee_1000t_disable =
+ of_property_read_bool(of_node, "realtek,disable-eee-1000t");
+ priv->eee_100tx_disable =
+ of_property_read_bool(of_node, "realtek,disable-eee-100tx");
+
+ phydev->priv = priv;
+
+ return 0;
+}
+
static struct phy_driver realtek_drvs[] = {
{
.phy_id = 0x00008201,
@@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
.phy_id_mask = 0x001fffff,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+ .probe = &rtl8211x_phy_probe,
.config_aneg = genphy_config_aneg,
+ .config_init = &rtl8211x_config_init,
.read_status = genphy_read_status,
.ack_interrupt = rtl821x_ack_interrupt,
.config_intr = rtl8211e_config_intr,
@@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
.phy_id_mask = 0x001fffff,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+ .probe = &rtl8211x_phy_probe,
.config_aneg = &genphy_config_aneg,
+ .config_init = &rtl8211x_config_init,
.read_status = &genphy_read_status,
.ack_interrupt = &rtl821x_ack_interrupt,
.config_intr = &rtl8211e_config_intr,
@@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
.phy_id_mask = 0x001fffff,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+ .probe = &rtl8211x_phy_probe,
.config_aneg = &genphy_config_aneg,
.config_init = &rtl8211f_config_init,
.read_status = &genphy_read_status,
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Jerome Brunet @ 2016-11-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/realtek-phy.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/realtek-phy.txt
diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt b/Documentation/devicetree/bindings/net/realtek-phy.txt
new file mode 100644
index 000000000000..dc2845a6b387
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
@@ -0,0 +1,20 @@
+Realtek Ethernet PHY
+
+Some boards require special tuning values of the phy.
+
+Optional properties:
+
+realtek,disable-eee-1000t:
+realtek,disable-eee-100tx:
+ If set, respectively disable 1000-BaseT and 100-BaseTx energy efficient
+ ethernet capabilty advertisement
+ default: Leave the phy default settings unchanged (capabilities advertised)
+
+Example:
+
+&mdio0 {
+ ethernetphy0: ethernet-phy at 0 {
+ reg = <0>;
+ realtek,disable-eee-1000t;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH net 3/3] ARM64: dts: meson: odroidc2: disable 1000t-eee advertisement
From: Jerome Brunet @ 2016-11-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-1-git-send-email-jbrunet@baylibre.com>
Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Andre Roth <neolynx@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491d48a5..1f4416ecb183 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -98,3 +98,18 @@
pinctrl-0 = <&i2c_a_pins>;
pinctrl-names = "default";
};
+
+ðmac {
+ phy-handle = <ð_phy0>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy at 0 {
+ reg = <0>;
+ realtek,disable-eee-1000t;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-15 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3bb538bb-3c80-70c7-2c44-46b174c90503@samsung.com>
Hi,
On 15-11-16 15:04, Jacek Anaszewski wrote:
> On 11/15/2016 02:48 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 15-11-16 14:28, Jacek Anaszewski wrote:
>>> On 11/15/2016 01:06 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 15-11-16 12:48, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>>>>> The LED you are talking about _has_ a trigger, implemented in
>>>>>>>>> hardware. That trigger can change LED brightness behind kernel's
>>>>>>>>> (and
>>>>>>>>> userspace's) back. Don't pretend the trigger does not exist, it
>>>>>>>>> does.
>>>>>>>>>
>>>>>>>>> And when you do that, you'll have nice place to report changes to
>>>>>>>>> userspace -- trigger can now export that information, and offer
>>>>>>>>> poll()
>>>>>>>>> interface.
>>>>>>>>
>>>>>>>> Well, that sounds interesting. It is logically justifiable.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>> I initially proposed exactly this solution, with recently
>>>>>>>> added userspace LED being a trigger listener. It seems a bit
>>>>>>>> awkward though. How would you listen to the trigger events?
>>>>>>>
>>>>>>> Trigger exposes a file in sysfs, with poll() working on that file
>>>>>>
>>>>>> Hmm, a new file would give the advantage of making it easy for
>>>>>> userspace to see if the trigger is poll-able, this is likely
>>>>>> better then my own proposal I just send.
>>>>>
>>>>> Good.
>>>>>
>>>>>>> (and
>>>>>>> probably read exposing the current brightness).
>>>>>>
>>>>>> If we do this, can we please make it mirror brightness, iow
>>>>>> also make it writable, that will make it easier for userspace
>>>>>> to deal with it. We can simply re-use the existing show / store
>>>>>> methods for brightness for this.
>>>>>
>>>>> Actually, echo 0 > brightness disables the trigger, IIRC. I'd avoid
>>>>> that here, you want to be able to turn off the backlight but still
>>>>> keep the trigger (and be notified of future changes).
>>>>
>>>> True, that is easy to do the store method will just need to call
>>>> led_set_brightness_nosleep instead of led_set_brightness, this
>>>> will skip the checks to stop blinking in led_set_brightness and
>>>> otherwise is equivalent.
>>>>
>>>>>> I suggest we call it:
>>>>>>
>>>>>> trigger_brightness
>>>>>>
>>>>>> And only register it when a poll-able trigger is present.
>>>>>
>>>>> I'd call it 'current_brightness', but that's no big deal. Yes, only
>>>>> registering it for poll-able triggers makes sense.
>>>>
>>>> current_brightness works for me. I will take a shot a patch-set
>>>> implementing this.
>>>
>>> Word "current" is not precise here.
>>>
>>> It can be thought of as either last brightness set by the
>>> user or the brightness currently written to the device
>>> (returned by brightness file).
>>>
>>> There is a semantic discrepancy in our requirements -
>>> we want the file representing both permanent brightness
>>> set by the user and brightness set by the hardware.
>>>
>>> The two stand in contradiction to each other since
>>> brightness set by the user can be adjusted by the hardware.
>>>
>>> Reading the file shouldn't update brightness property of
>>> struct led_classdev, so it shouldn't call led_update_brightness()
>>> but it still should allow reading brightness set by the
>>> hardware, as a result of each POLLPRI event. So in fact in
>>> the same time it should report both according to our requirements
>>> which is impossible. Do we need three brightness files ?
>>
>> I don't think so, current_brightness actually is an accurate
>> name, if the brightness was last changed by writing from
>> sysfs, the keyboard backlight will honor that and the current_brightness
>> attribute will show the brightness last set through writing it,
>> which matches the actual current brightness of the keyboard backlight.
>>
>> Likewise if it was changed with the hotkey last then the keyboard
>> backlight brightness will be changed and reading from current_brightness
>> will return the new actual brightness. Basically reading from this
>> file will be no different then reading from the normal "brightness"
>> file the difference will be in that it is poll-able and that
>> writing 0 turns off the LED without stopping blinking.
>
> If so then when software blinking enabled, it will return 0 on low
> blink cycle no matter what current brightness level is.
For software blinking there will not be a current_brightness atrribute,
as we will only add that for LEDs with poll-able triggers.
Also during the low cycle the LED is off, so its brightness at the
moment of reading (iow currently) is 0.
Regards,
Hans
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v4.10 #2
From: Alexandre Torgue @ 2016-11-15 14:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider this second round of STM32 DT updates for v4.10:
The following changes since commit f6dbbff4f0af1a5c0d6eaf414572b5eff7a73a8b:
ARM: dts: stm32f429: add LSI and LSE clocks (2016-11-04 15:08:08 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
tags/stm32-dt-for-v4.10-2
for you to fetch changes up to 2ecaa477b404d707bac93c56f09a0a6162e04ed7:
ARM: dts: stm32f429: Add QSPI clock (2016-11-15 13:59:11 +0100)
----------------------------------------------------------------
STM32 DT updates for v4.10, round 2.
Highlights:
----------
- Add support of STM32F746 MCU and STM32746G-Eval board
- Add QSPI support for STM32F469-Disco board
----------------------------------------------------------------
Alexandre TORGUE (1):
ARM: dts: Add STM32F746 MCU and STM32746g-EVAL board
Gabriel Fernandez (1):
ARM: dts: stm32f429: Add QSPI clock
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/stm32746g-eval.dts | 96 +++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 4 +
arch/arm/boot/dts/stm32f746.dtsi | 304
++++++++++++++++++++++++++++++++++
4 files changed, 406 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/stm32746g-eval.dts
create mode 100644 arch/arm/boot/dts/stm32f746.dtsi
^ permalink raw reply
* LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-15 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e1c1db1e-2a78-bbe0-e3bc-84be449dbcb6@redhat.com>
On 11/15/2016 03:30 PM, Hans de Goede wrote:
> Hi,
>
> On 15-11-16 15:04, Jacek Anaszewski wrote:
>> On 11/15/2016 02:48 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 15-11-16 14:28, Jacek Anaszewski wrote:
>>>> On 11/15/2016 01:06 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 15-11-16 12:48, Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>>>>>> The LED you are talking about _has_ a trigger, implemented in
>>>>>>>>>> hardware. That trigger can change LED brightness behind kernel's
>>>>>>>>>> (and
>>>>>>>>>> userspace's) back. Don't pretend the trigger does not exist, it
>>>>>>>>>> does.
>>>>>>>>>>
>>>>>>>>>> And when you do that, you'll have nice place to report changes to
>>>>>>>>>> userspace -- trigger can now export that information, and offer
>>>>>>>>>> poll()
>>>>>>>>>> interface.
>>>>>>>>>
>>>>>>>>> Well, that sounds interesting. It is logically justifiable.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>> I initially proposed exactly this solution, with recently
>>>>>>>>> added userspace LED being a trigger listener. It seems a bit
>>>>>>>>> awkward though. How would you listen to the trigger events?
>>>>>>>>
>>>>>>>> Trigger exposes a file in sysfs, with poll() working on that file
>>>>>>>
>>>>>>> Hmm, a new file would give the advantage of making it easy for
>>>>>>> userspace to see if the trigger is poll-able, this is likely
>>>>>>> better then my own proposal I just send.
>>>>>>
>>>>>> Good.
>>>>>>
>>>>>>>> (and
>>>>>>>> probably read exposing the current brightness).
>>>>>>>
>>>>>>> If we do this, can we please make it mirror brightness, iow
>>>>>>> also make it writable, that will make it easier for userspace
>>>>>>> to deal with it. We can simply re-use the existing show / store
>>>>>>> methods for brightness for this.
>>>>>>
>>>>>> Actually, echo 0 > brightness disables the trigger, IIRC. I'd avoid
>>>>>> that here, you want to be able to turn off the backlight but still
>>>>>> keep the trigger (and be notified of future changes).
>>>>>
>>>>> True, that is easy to do the store method will just need to call
>>>>> led_set_brightness_nosleep instead of led_set_brightness, this
>>>>> will skip the checks to stop blinking in led_set_brightness and
>>>>> otherwise is equivalent.
>>>>>
>>>>>>> I suggest we call it:
>>>>>>>
>>>>>>> trigger_brightness
>>>>>>>
>>>>>>> And only register it when a poll-able trigger is present.
>>>>>>
>>>>>> I'd call it 'current_brightness', but that's no big deal. Yes, only
>>>>>> registering it for poll-able triggers makes sense.
>>>>>
>>>>> current_brightness works for me. I will take a shot a patch-set
>>>>> implementing this.
>>>>
>>>> Word "current" is not precise here.
>>>>
>>>> It can be thought of as either last brightness set by the
>>>> user or the brightness currently written to the device
>>>> (returned by brightness file).
>>>>
>>>> There is a semantic discrepancy in our requirements -
>>>> we want the file representing both permanent brightness
>>>> set by the user and brightness set by the hardware.
>>>>
>>>> The two stand in contradiction to each other since
>>>> brightness set by the user can be adjusted by the hardware.
>>>>
>>>> Reading the file shouldn't update brightness property of
>>>> struct led_classdev, so it shouldn't call led_update_brightness()
>>>> but it still should allow reading brightness set by the
>>>> hardware, as a result of each POLLPRI event. So in fact in
>>>> the same time it should report both according to our requirements
>>>> which is impossible. Do we need three brightness files ?
>>>
>>> I don't think so, current_brightness actually is an accurate
>>> name, if the brightness was last changed by writing from
>>> sysfs, the keyboard backlight will honor that and the current_brightness
>>> attribute will show the brightness last set through writing it,
>>> which matches the actual current brightness of the keyboard backlight.
>>>
>>> Likewise if it was changed with the hotkey last then the keyboard
>>> backlight brightness will be changed and reading from current_brightness
>>> will return the new actual brightness. Basically reading from this
>>> file will be no different then reading from the normal "brightness"
>>> file the difference will be in that it is poll-able and that
>>> writing 0 turns off the LED without stopping blinking.
>>
>> If so then when software blinking enabled, it will return 0 on low
>> blink cycle no matter what current brightness level is.
>
> For software blinking there will not be a current_brightness atrribute,
> as we will only add that for LEDs with poll-able triggers.
>
> Also during the low cycle the LED is off, so its brightness at the
> moment of reading (iow currently) is 0.
OK, I wanted to make sure that we know what we've agreed on.
Earlier there were doubts raised about brightness during
software blinking being periodically reported 0, but actually
your reasoning seems to be the best answer to that.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] arm/arm64: KVM: VGIC: limit ITARGETSR bits to number of VCPUs
From: Marc Zyngier @ 2016-11-15 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115142749.19955-1-andre.przywara@arm.com>
Hi Andre,
On 15/11/16 14:27, Andre Przywara wrote:
> The GICv2 spec says in section 4.3.12 that a "CPU targets field bit that
> corresponds to an unimplemented CPU interface is RAZ/WI."
> Currently we allow the guest to write any value in there and it can
> read that back.
> Mask the written value with the proper CPU mask to be spec compliant.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-mmio-v2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> index b44b359..e59d4c7 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> @@ -129,6 +129,7 @@ static void vgic_mmio_write_target(struct kvm_vcpu *vcpu,
> unsigned long val)
> {
> u32 intid = VGIC_ADDR_TO_INTID(addr, 8);
> + u8 cpu_mask = (1 << atomic_read(&vcpu->kvm->online_vcpus)) - 1;
For the sake of avoiding open-coding things, how about using GENMASK?
> int i;
>
> /* GICD_ITARGETSR[0-7] are read-only */
> @@ -141,7 +142,7 @@ static void vgic_mmio_write_target(struct kvm_vcpu *vcpu,
>
> spin_lock(&irq->irq_lock);
>
> - irq->targets = (val >> (i * 8)) & 0xff;
> + irq->targets = ((val >> (i * 8)) & 0xff) & cpu_mask;
Can't you just drop the '& 0xff' part, since cpu_mask is guaranteed to
be more restrictive?
> target = irq->targets ? __ffs(irq->targets) : 0;
> irq->target_vcpu = kvm_get_vcpu(vcpu->kvm, target);
>
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-11-15 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0af2373f-db86-e93f-b3e1-01c3076ce6fc@redhat.com>
On 14/11/16 23:23, Auger Eric wrote:
> Hi Robin,
>
> On 14/11/2016 13:36, Robin Murphy wrote:
>> On 04/11/16 11:24, Eric Auger wrote:
>>> From: Robin Murphy <robin.murphy@arm.com>
>>>
>>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>>> with regard to mapping MSI messages in systems where the MSI write is
>>> subject to IOMMU translation. With the relevant infrastructure now in
>>> place for managed DMA domains, it's actually really simple for other
>>> users to piggyback off that and reap the benefits without giving up
>>> their own IOVA management, and without having to reinvent their own
>>> wheel in the MSI layer.
>>>
>>> Allow such users to opt into automatic MSI remapping by dedicating a
>>> region of their IOVA space to a managed cookie.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> OK, following the discussion elsewhere I've had a go at the less stupid,
>> but more involved, version. Thoughts?
>
> Conceptually I don't have any major objection with the minimalist
> allocation scheme all the more so it follows Joerg's guidance. Maybe the
> only thing is we do not check we don't overshoot the reserved msi-region.
Yes, I thought about that and came to the conclusion that it was hard to
justify the extra complexity. Since the caller has to calculate an
appropriate region size to reserve anyway, we might as well just trust
it to be correct. And if the caller did get things wrong, then one or
other iommu_map() is going to fail on the overlapping IOVAs anyway.
>
> Besides there are 2 issues reported below.
>
>>
>> Robin.
>>
>> ----->8-----
>> From: Robin Murphy <robin.murphy@arm.com>
>> Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie, and extend the mapping
>> routine to implement a trivial linear allocator in such cases, to avoid
>> the needless overhead of a full-blown IOVA domain.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
>> include/linux/dma-iommu.h | 6 +++
>> 2 files changed, 100 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab8667e6f2..33d66a8273c6 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
>> phys_addr_t phys;
>> };
>>
>> +enum iommu_dma_cookie_type {
>> + IOMMU_DMA_IOVA_COOKIE,
>> + IOMMU_DMA_MSI_COOKIE,
>> +};
>> +
>> struct iommu_dma_cookie {
>> - struct iova_domain iovad;
>> - struct list_head msi_page_list;
>> - spinlock_t msi_lock;
>> + union {
>> + struct iova_domain iovad;
>> + dma_addr_t msi_iova;
>> + };
>> + struct list_head msi_page_list;
>> + spinlock_t msi_lock;
>> + enum iommu_dma_cookie_type type;
>> };
>>
>> static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
>> @@ -53,6 +62,19 @@ int iommu_dma_init(void)
>> return iova_cache_get();
>> }
>>
>> +static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
>> +{
>> + struct iommu_dma_cookie *cookie;
>> +
>> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
>> + if (cookie) {
>> + spin_lock_init(&cookie->msi_lock);
>> + INIT_LIST_HEAD(&cookie->msi_page_list);
>> + cookie->type = type;
>> + }
>> + return cookie;
>> +}
>> +
>> /**
>> * iommu_get_dma_cookie - Acquire DMA-API resources for a domain
>> * @domain: IOMMU domain to prepare for DMA-API usage
>> @@ -62,25 +84,53 @@ int iommu_dma_init(void)
>> */
>> int iommu_get_dma_cookie(struct iommu_domain *domain)
>> {
>> - struct iommu_dma_cookie *cookie;
>> -
>> if (domain->iova_cookie)
>> return -EEXIST;
>>
>> - cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
>> - if (!cookie)
>> + domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
>> + if (!domain->iova_cookie)
>> return -ENOMEM;
>>
>> - spin_lock_init(&cookie->msi_lock);
>> - INIT_LIST_HEAD(&cookie->msi_page_list);
>> - domain->iova_cookie = cookie;
>> return 0;
>> }
>> EXPORT_SYMBOL(iommu_get_dma_cookie);
>>
>> /**
>> + * iommu_get_msi_cookie - Acquire just MSI remapping resources
>> + * @domain: IOMMU domain to prepare
>> + * @base: Start address of IOVA region for MSI mappings
>> + *
>> + * Users who manage their own IOVA allocation and do not want DMA API support,
>> + * but would still like to take advantage of automatic MSI remapping, can use
>> + * this to initialise their own domain appropriately. Users should reserve a
>> + * contiguous IOVA region, starting at @base, large enough to accommodate the
>> + * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
>> + * used by the devices attached to @domain.
>> + */
>> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
>> +{
>> + struct iommu_dma_cookie *cookie;
>> +
>> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
>> + return -EINVAL;
>> +
>> + if (domain->iova_cookie)
>> + return -EEXIST;
>> +
>> + cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
> must be IOMMU_DMA_MSI_COOKIE else it has bad consequences.
Oops, quite right!
>> + if (!cookie)
>> + return -ENOMEM;
>> +
>> + cookie->msi_iova = base;
>> + domain->iova_cookie = cookie;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(iommu_get_msi_cookie);
>> +
>> +/**
>> * iommu_put_dma_cookie - Release a domain's DMA mapping resources
>> - * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
>> + * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
>> + * iommu_get_msi_cookie()
>> *
>> * IOMMU drivers should normally call this from their domain_free callback.
>> */
>> @@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
>> if (!cookie)
>> return;
>>
>> - if (cookie->iovad.granule)
>> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
>> put_iova_domain(&cookie->iovad);
>>
>> list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
>> @@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
>> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> u64 size, struct device *dev)
>> {
>> - struct iova_domain *iovad = cookie_iovad(domain);
>> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
>> + struct iova_domain *iovad = &cookie->iovad;
>> unsigned long order, base_pfn, end_pfn;
>>
>> - if (!iovad)
>> - return -ENODEV;
>> + if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
>> + return -EINVAL;
>>
>> /* Use the smallest supported page size for IOVA granularity */
>> order = __ffs(domain->pgsize_bitmap);
>> @@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
>> {
>> struct iommu_dma_cookie *cookie = domain->iova_cookie;
>> struct iommu_dma_msi_page *msi_page;
>> - struct iova_domain *iovad = &cookie->iovad;
>> + struct iova_domain *iovad;
>> struct iova *iova;
>> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>> + size_t size;
>> +
>> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
>> + iovad = &cookie->iovad;
>> + size = iovad->granule;
>> + } else {
>> + iovad = NULL;
>> + size = PAGE_SIZE;
>> + }
>> +
>> + msi_addr &= ~(phys_addr_t)(size - 1);
>>
>> - msi_addr &= ~(phys_addr_t)iova_mask(iovad);
>> list_for_each_entry(msi_page, &cookie->msi_page_list, list)
>> if (msi_page->phys == msi_addr)
>> return msi_page;
>> @@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
>> if (!msi_page)
>> return NULL;
>>
>> - iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
>> - if (!iova)
>> - goto out_free_page;
>> -
>> msi_page->phys = msi_addr;
>> - msi_page->iova = iova_dma_addr(iovad, iova);
>> - if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
>> + if (iovad) {
>> + iova = __alloc_iova(domain, size, dma_get_mask(dev));
>> + if (!iova)
>> + goto out_free_page;
>> + msi_page->iova = iova_dma_addr(iovad, iova);
>> + } else {
>> + msi_page->iova = cookie->msi_iova;
>> + cookie->msi_iova += size;
>> + }
>> +
>> + if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
>> goto out_free_iova;
>>
>> INIT_LIST_HEAD(&msi_page->list);
>> @@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
>> return msi_page;
>>
>> out_free_iova:
>> - __free_iova(iovad, iova);
>> + if (iovad)
>> + __free_iova(iovad, iova);
>> + else
>> + cookie->msi_iova -= size;
>> out_free_page:
>> kfree(msi_page);
>> return NULL;
>> @@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>> msg->address_lo += lower_32_bits(msi_page->iova);
>> }
>> }
>
> in iommu_dma_map_msi_msg there is another issue at:
> msg->address_lo &= iova_mask(&cookie->iovad);
> iovad might not exist
Ah yes, I'd overlooked that one, thanks - seems compile-testing isn't
that magic bullet...
Completely factoring out the alloc/free seemed like overkill when all
the IOVA stuff seemed to be in the one function, but in light of this
I'll have another go and see if I can get it any tidier - the RFC was
primarily for the simplified interface and allocator. In the meantime I
think your fixed-up version looks correct.
> Thanks
>
> Eric
>
>> +
(now, this line I had at least already taken care of. Oh well)
Thanks,
Robin.
>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>> index 32c589062bd9..d69932474576 100644
>> --- a/include/linux/dma-iommu.h
>> +++ b/include/linux/dma-iommu.h
>> @@ -27,6 +27,7 @@ int iommu_dma_init(void);
>>
>> /* Domain management interface for IOMMU drivers */
>> int iommu_get_dma_cookie(struct iommu_domain *domain);
>> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
>> void iommu_put_dma_cookie(struct iommu_domain *domain);
>>
>> /* Setup call for arch DMA mapping code */
>> @@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
>> return -ENODEV;
>> }
>>
>> +static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
>> +{
>> + return -ENODEV;
>> +}
>> +
>> static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
>> {
>> }
>>
^ permalink raw reply
* [PATCH] ARM: fix backtrace
From: Russell King @ 2016-11-15 15:01 UTC (permalink / raw)
To: linux-arm-kernel
Recent kernels have changed their behaviour to be more inconsistent
when handling printk continuations. With todays kernels, the output
looks sane on the console, but dmesg splits individual printk()s which
do not have the KERN_CONT prefix into separate lines.
Since the assembly code is not trivial to add the KERN_CONT, and we
ideally want to avoid using KERN_CONT (as multiple printk()s can race
between different threads), convert the assembly dumping the register
values to C code, and have the C code build the output a line at a
time before dumping to the console.
This avoids the KERN_CONT issue, and also avoids situations where the
output is intermixed with other console activity.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
Noticed due to a NFS bug in 4.9-rc.
arch/arm/kernel/traps.c | 20 ++++++++++++++++++++
arch/arm/lib/backtrace.S | 37 +++----------------------------------
2 files changed, 23 insertions(+), 34 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 2771ba243f36..ff2ae872d555 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -75,6 +75,26 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long
dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
}
+void dump_backtrace_stm(u32 *stack, u32 instruction)
+{
+ char str[80], *p;
+ unsigned int x;
+ int reg;
+
+ for (reg = 10, x = 0, p = str; reg >= 0; reg--) {
+ if (instruction & BIT(reg)) {
+ p += sprintf(p, " r%d:%08x", reg, *stack--);
+ if (++x == 6) {
+ x = 0;
+ p = str;
+ printk("%s\n", str);
+ }
+ }
+ }
+ if (p != str)
+ printk("%s\n", str);
+}
+
#ifndef CONFIG_ARM_UNWIND
/*
* Stack pointers should always be within the kernels view of
diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
index fab5a50503ae..7d7952e5a3b1 100644
--- a/arch/arm/lib/backtrace.S
+++ b/arch/arm/lib/backtrace.S
@@ -10,6 +10,7 @@
* 27/03/03 Ian Molton Clean up CONFIG_CPU
*
*/
+#include <linux/kern_levels.h>
#include <linux/linkage.h>
#include <asm/assembler.h>
.text
@@ -83,13 +84,13 @@ for_each_frame: tst frame, mask @ Check for address exceptions
teq r3, r1, lsr #11
ldreq r0, [frame, #-8] @ get sp
subeq r0, r0, #4 @ point at the last arg
- bleq .Ldumpstm @ dump saved registers
+ bleq dump_backtrace_stm @ dump saved registers
1004: ldr r1, [sv_pc, #0] @ if stmfd sp!, {..., fp, ip, lr, pc}
ldr r3, .Ldsi @ instruction exists,
teq r3, r1, lsr #11
subeq r0, frame, #16
- bleq .Ldumpstm @ dump saved registers
+ bleq dump_backtrace_stm @ dump saved registers
teq sv_fp, #0 @ zero saved fp means
beq no_frame @ no further frames
@@ -112,38 +113,6 @@ ENDPROC(c_backtrace)
.long 1004b, 1006b
.popsection
-#define instr r4
-#define reg r5
-#define stack r6
-
-.Ldumpstm: stmfd sp!, {instr, reg, stack, r7, lr}
- mov stack, r0
- mov instr, r1
- mov reg, #10
- mov r7, #0
-1: mov r3, #1
- ARM( tst instr, r3, lsl reg )
- THUMB( lsl r3, reg )
- THUMB( tst instr, r3 )
- beq 2f
- add r7, r7, #1
- teq r7, #6
- moveq r7, #0
- adr r3, .Lcr
- addne r3, r3, #1 @ skip newline
- ldr r2, [stack], #-4
- mov r1, reg
- adr r0, .Lfp
- bl printk
-2: subs reg, reg, #1
- bpl 1b
- teq r7, #0
- adrne r0, .Lcr
- blne printk
- ldmfd sp!, {instr, reg, stack, r7, pc}
-
-.Lfp: .asciz " r%d:%08x%s"
-.Lcr: .asciz "\n"
.Lbad: .asciz "Backtrace aborted due to bad frame pointer <%p>\n"
.align
.Ldsi: .word 0xe92dd800 >> 11 @ stmfd sp!, {... fp, ip, lr, pc}
--
2.7.4
^ permalink raw reply related
* [BUG] Suspicious RCU usage: NFS client - 4.9-rc4
From: Russell King - ARM Linux @ 2016-11-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
While booting two of my machines, I noticed this splat on the console.
Not sure if this is due to a RCU change or NFS change, so adding folk
on both sides.
===============================
[ INFO: suspicious RCU usage. ]
4.9.0-rc4+ #2050 Not tainted
-------------------------------
net/sunrpc/clnt.c:2773 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by mount.nfs/1499:
#0:
(
&(&nn->nfs_client_lock)->rlock
){+.+...}
, at:
[<c026c6d4>] nfs_get_client+0xe8/0x580
stack backtrace:
CPU: 1 PID: 1499 Comm: mount.nfs Not tainted 4.9.0-rc4+ #2050
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c0013b84>] (dump_backtrace) from [<c0013dc4>] (show_stack+0x18/0x1c)
r6:60010013 r5:ffffffff r4:00000000 r3:00000000
[<c0013dac>] (show_stack) from [<c035d300>] (dump_stack+0xa4/0xdc)
[<c035d25c>] (dump_stack) from [<c008093c>] (lockdep_rcu_suspicious+0xbc/0x11c)
r6:00000ad5 r5:c08f4078 r4:ee58a4c0 r3:ee58a4c0
[<c0080880>] (lockdep_rcu_suspicious) from [<c0721ba4>] (rpc_clnt_xprt_switch_has_addr+0x134/0x15c)
r7:ef27dd80 r6:c0ae3972 r5:eeb5a110 r4:ee930400
[<c0721a70>] (rpc_clnt_xprt_switch_has_addr) from [<c026c814>] (nfs_get_client+0x228/0x580)
r6:ef27ddd0 r5:eeb5a110 r4:00000000
[<c026c5ec>] (nfs_get_client) from [<c026cc20>] (nfs_create_server+0xb4/0x3d4)
r10:edaebe6c r9:c0a84d54 r8:edaebd30 r7:edf7b480 r6:00000000 r5:ed50a000
r4:eeb5a000
[<c026cb6c>] (nfs_create_server) from [<c028a2f8>] (nfs3_create_server+0x10/0x28)
r10:00000000 r9:edbea200 r8:c0a84d54 r7:edaebe6c r6:00000000 r5:00000001
r4:eeb5a000
[<c028a2e8>] (nfs3_create_server) from [<c02792a0>] (nfs_try_mount+0x188/0x280)
r4:eeb5a000 r3:c028a2e8
[<c0279118>] (nfs_try_mount) from [<c027b28c>] (nfs_fs_mount+0x420/0x8c0)
r10:00000000 r9:00000400 r8:edbea200 r7:edbea200 r6:c0a84d54 r5:edbea206
r4:eeb5a000
[<c027ae6c>] (nfs_fs_mount) from [<c016eaf4>] (mount_fs+0x1c/0xa8)
r10:ed4f5000 r9:edbea340 r8:c0a82204 r7:c019091c r6:c0a82204 r5:edbea200
r4:ed8a3700
[<c016ead8>] (mount_fs) from [<c018d6d0>] (vfs_kern_mount+0x5c/0x138)
r6:00000000 r5:edbea200 r4:ed8a3700
[<c018d674>] (vfs_kern_mount) from [<c019091c>] (do_mount+0x164/0xc58)
r10:c0191774 r8:edbea200 r7:00000020 r6:ed4f5000 r5:c0a82204 r4:00000000
[<c01907b8>] (do_mount) from [<c0191774>] (SyS_mount+0x7c/0xa4)
r10:00000000 r9:edaea000 r8:0078c0f8 r7:00000000 r6:ed4f5000 r5:edbea200
r4:edbea340
[<c01916f8>] (SyS_mount) from [<c000fd60>] (ret_fast_syscall+0x0/0x1c)
r8:c000ff04 r7:00000015 r6:0078dd50 r5:bed2bad0 r4:007968a8
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [BUG] Suspicious RCU usage: NFS client - 4.9-rc4
From: Anna Schumaker @ 2016-11-15 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115150706.GW1041@n2100.armlinux.org.uk>
Hi Russel,
On 11/15/2016 10:07 AM, Russell King - ARM Linux wrote:
> While booting two of my machines, I noticed this splat on the console.
> Not sure if this is due to a RCU change or NFS change, so adding folk
> on both sides.
The patch to fix this went into rc5 :)
Thanks for reporting!
Anna
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.9.0-rc4+ #2050 Not tainted
> -------------------------------
> net/sunrpc/clnt.c:2773 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 1 lock held by mount.nfs/1499:
> #0:
> (
> &(&nn->nfs_client_lock)->rlock
> ){+.+...}
> , at:
> [<c026c6d4>] nfs_get_client+0xe8/0x580
>
> stack backtrace:
> CPU: 1 PID: 1499 Comm: mount.nfs Not tainted 4.9.0-rc4+ #2050
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> Backtrace:
> [<c0013b84>] (dump_backtrace) from [<c0013dc4>] (show_stack+0x18/0x1c)
> r6:60010013 r5:ffffffff r4:00000000 r3:00000000
> [<c0013dac>] (show_stack) from [<c035d300>] (dump_stack+0xa4/0xdc)
> [<c035d25c>] (dump_stack) from [<c008093c>] (lockdep_rcu_suspicious+0xbc/0x11c)
> r6:00000ad5 r5:c08f4078 r4:ee58a4c0 r3:ee58a4c0
> [<c0080880>] (lockdep_rcu_suspicious) from [<c0721ba4>] (rpc_clnt_xprt_switch_has_addr+0x134/0x15c)
> r7:ef27dd80 r6:c0ae3972 r5:eeb5a110 r4:ee930400
> [<c0721a70>] (rpc_clnt_xprt_switch_has_addr) from [<c026c814>] (nfs_get_client+0x228/0x580)
> r6:ef27ddd0 r5:eeb5a110 r4:00000000
> [<c026c5ec>] (nfs_get_client) from [<c026cc20>] (nfs_create_server+0xb4/0x3d4)
> r10:edaebe6c r9:c0a84d54 r8:edaebd30 r7:edf7b480 r6:00000000 r5:ed50a000
> r4:eeb5a000
> [<c026cb6c>] (nfs_create_server) from [<c028a2f8>] (nfs3_create_server+0x10/0x28)
> r10:00000000 r9:edbea200 r8:c0a84d54 r7:edaebe6c r6:00000000 r5:00000001
> r4:eeb5a000
> [<c028a2e8>] (nfs3_create_server) from [<c02792a0>] (nfs_try_mount+0x188/0x280)
> r4:eeb5a000 r3:c028a2e8
> [<c0279118>] (nfs_try_mount) from [<c027b28c>] (nfs_fs_mount+0x420/0x8c0)
> r10:00000000 r9:00000400 r8:edbea200 r7:edbea200 r6:c0a84d54 r5:edbea206
> r4:eeb5a000
> [<c027ae6c>] (nfs_fs_mount) from [<c016eaf4>] (mount_fs+0x1c/0xa8)
> r10:ed4f5000 r9:edbea340 r8:c0a82204 r7:c019091c r6:c0a82204 r5:edbea200
> r4:ed8a3700
> [<c016ead8>] (mount_fs) from [<c018d6d0>] (vfs_kern_mount+0x5c/0x138)
> r6:00000000 r5:edbea200 r4:ed8a3700
> [<c018d674>] (vfs_kern_mount) from [<c019091c>] (do_mount+0x164/0xc58)
> r10:c0191774 r8:edbea200 r7:00000020 r6:ed4f5000 r5:c0a82204 r4:00000000
> [<c01907b8>] (do_mount) from [<c0191774>] (SyS_mount+0x7c/0xa4)
> r10:00000000 r9:edaea000 r8:0078c0f8 r7:00000000 r6:ed4f5000 r5:edbea200
> r4:edbea340
> [<c01916f8>] (SyS_mount) from [<c000fd60>] (ret_fast_syscall+0x0/0x1c)
> r8:c000ff04 r7:00000015 r6:0078dd50 r5:bed2bad0 r4:007968a8
>
>
^ permalink raw reply
* [PATCH v2 2/3] efi/libstub: add random.c to ARM build
From: Arnd Bergmann @ 2016-11-15 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_=et=2zHBTYOr9thz2kS0cXHHYg96oWGRdD3D10fqXtw@mail.gmail.com>
On Wednesday, November 2, 2016 9:37:13 AM CET Ard Biesheuvel wrote:
> @@ -98,7 +100,7 @@
> efi_memory_desc_t *md = (void *)memory_map + map_offset;
> unsigned long slots;
>
> - slots = get_entry_num_slots(md, size, align);
> + slots = get_entry_num_slots(md, size, ilog2(align));
> MD_NUM_SLOTS(md) = slots;
> total_slots += slots;
> }
> """
>
> This is because ARM does not have a division routine in the
> decompressor, and the fact that the division by 'align' should always
> involve a power of 2 is not visible to the compiler.
>
> If nobody objects, I will fold this in when applying
>
>
I'm getting a link error here when building with -Os:
drivers/firmware/efi/libstub/random.stub.o: In function `efi_random_alloc':
random.c:(.text.efi_random_alloc+0x264): undefined reference to `__aeabi_llsr'
If I compile this with -O2, the ilog2 gets inlined and everything
works.
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox