* wdt, gpio: move arch_initcall into subsys_initcall ?
From: Guenter Roeck @ 2016-11-15 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e4472c2d-effa-9583-aded-8dcdfdd57ee6@mentor.com>
On 11/15/2016 03:32 AM, Vladimir Zapolskiy wrote:
> On 11/15/2016 01:10 PM, Vladimir Zapolskiy wrote:
>> Hello Heiko,
>>
>> On 11/15/2016 12:20 PM, Heiko Schocher wrote:
>>> Hello,
>>>
>>> commit e188cbf7564f: "gpio: mxc: shift gpio_mxc_init() to subsys_initcall level"
>>> moves the gpio initialization of the mxc gpio driver
>>> from the arch_initcall level into subsys_initcall level.
>>>
>>> This leads now on mxc boards, which use a gpio wdt driver
>>> and the CONFIG_GPIO_WATCHDOG_ARCH_INITCALL option enabled,
>>> to unwanted driver probe deferrals during kernel boot.
>>>
>>> I see this currently on an imx6 based board (which has unfortunately
>>> 3 WDT: imx6 internal (disabled), gpio wdt and da9063 WDT ...).
>>>
>>> Also a side effect from above commit is, that the da9063 WDT driver
>>> is now probed before the gpio WDT driver ... so /dev/watchdog now
>>> does not point to the gpio_wdt, instead it points to the da9063 WDT.
>>>
>>> So there are 2 solutions possible:
>>>
>>> - add a CONFIG_GPIO_MCX_ARCH_INITCALL option
>>> in drivers/gpio/gpio-mxc.c like for the gpio_wdt.c driver?
>>
>> in my opinion this is overly heavy solution and it might be
>> better to avoid it if possible.
>>
>> I would rather prefer to reconsider GPIO_WATCHDOG_ARCH_INITCALL
>> usage in the watchdog driver.
>>
>> Moreover adding this proposed GPIO_MCX_ARCH_INITCALL to call
>> the driver on arch level will result in deferring the GPIO driver.
>>
>>> But how can we guarantee, that first the gpio driver and then
>>> the gpio_wdt driver gets probed?
>>>
>>> - move the arch_initcall in gpio_wdt.c into a subsys_initcall
>>> (Tested this, and the probe dereferral messages are gone ...)
>>>
>>> But this may results in problems on boards, which needs an early
>>> trigger on an gpio wdt ...
>>
>> The level of "earliness" can not be defined in absolute time value
>> in any case, why decreasing the init level of the watchdog driver
>> to subsys level can cause problems? For that there should exist
>> some kind of a dependency on IC or PCB hardware level, can you
>> name it please?
>>
>> Also please note that more than a half of all GPIO drivers settle
>> on subsys or later initcall level, this means that there is
>> an expected GPIO watchdog driver deferral for all of them.
>
> Please find two more late notes though.
>
>> I propose to send two patches for review:
>>
>> 1. remove GPIO_WATCHDOG_ARCH_INITCALL option completely and decouple
>> module_platform_driver() into arch_initcall() and module_exit()
>> unconditionally.
>>
>> 2. change arch_initcall() in the watchdog driver to subsys_initcall().
>> This change removes probe deferrals on boot, when the driver is
>> used with the most of the GPIO controllers.
>
> Alternatively commit 5e53c8ed813d ("watchdog: gpio_wdt: Add option for
> early registration") can be reverted and then module_platform_driver()
> is decoupled into subsys_initcall() and module_exit() as its replacement.
>
Sure, only the reason for that was that there are situations where
subsys_initcall() was too late. Also, when using arch_initcall() only,
we get deferrals again, which is apparently hated by many and a reason
for all those "avoid probe deferrals" patches.
> And also please note that since quite many GPIO controller drivers
> live on initcall levels after subsys_initcall(), the solution won't
> let to avoid watchdog driver deferrals totally, this should be accepted.
>
... except for others it isn't, and we are back to square one.
GPIO_WATCHDOG_ARCH_INITCALL was intended to be only used in situations
where needed. Why is it used here in the first place if that is not
the case ?
Guenter
^ permalink raw reply
* 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 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9e7d5e0f-c4ca-6930-63b9-83dc28517f33@samsung.com>
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.
Regards,
Hans
^ permalink raw reply
* [PATCH v3 1/3] phy_sun4i_usb: set_mode: Allow using set_mode to force end the current session
From: Kishon Vijay Abraham I @ 2016-11-15 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923134058.26828-1-hdegoede@redhat.com>
On Friday 23 September 2016 07:10 PM, Hans de Goede wrote:
> The sunxi musb has a bug where sometimes it will generate a babble
> error on device disconnect instead of a disconnect irq. When this
> happens the musb-controller switches from host mode to device mode
> (it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
> gets stuck in this state.
>
> Clearing this requires reporting Vbus low for 200 or more ms, but
> on some devices Vbus is simply always high (host-only mode, no Vbus
> control).
>
> This commit modifies sun4i_usb_phy_set_mode so that it will force
> end the current session when called with the current mode, before this
> commit calling set_mode with the current mode was a nop since id_det
> would stay the same resulting in the detect_work not doing anything.
>
> This allows the sunxi-musb glue to use sun4i_usb_phy_set_mode to force
> end the current session without changing the mode, to fixup the stuck
> state after a babble error.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
merged, thanks.
-Kishon
> ---
> Changes in v2:
> -New patch in v2 of this series replacing the
> "phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function"
> from v1
> Changes in v3:
> -Fix dev_info so that it prints the new-mode instead of the old one
> ---
> drivers/phy/phy-sun4i-usb.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 43c0d98..cbd338d 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -437,25 +437,31 @@ static int sun4i_usb_phy_set_mode(struct phy *_phy, enum phy_mode mode)
> {
> struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> + int new_mode;
>
> if (phy->index != 0)
> return -EINVAL;
>
> switch (mode) {
> case PHY_MODE_USB_HOST:
> - data->dr_mode = USB_DR_MODE_HOST;
> + new_mode = USB_DR_MODE_HOST;
> break;
> case PHY_MODE_USB_DEVICE:
> - data->dr_mode = USB_DR_MODE_PERIPHERAL;
> + new_mode = USB_DR_MODE_PERIPHERAL;
> break;
> case PHY_MODE_USB_OTG:
> - data->dr_mode = USB_DR_MODE_OTG;
> + new_mode = USB_DR_MODE_OTG;
> break;
> default:
> return -EINVAL;
> }
>
> - dev_info(&_phy->dev, "Changing dr_mode to %d\n", (int)data->dr_mode);
> + if (new_mode != data->dr_mode) {
> + dev_info(&_phy->dev, "Changing dr_mode to %d\n", new_mode);
> + data->dr_mode = new_mode;
> + }
> +
> + data->id_det = -1; /* Force reprocessing of id */
> data->force_session_end = true;
> queue_delayed_work(system_wq, &data->detect, 0);
>
>
^ permalink raw reply
* [PATCH] ASoC: mioa701_wm9713: add missing white space in dev_err message
From: Lothar Waßmann @ 2016-11-15 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112163025.4801-1-colin.king@canonical.com>
Hi,
On Sat, 12 Nov 2016 16:30:25 +0000 Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a missing whitespace in the dev_err message between
> "will" and "lead". Add the whitespace.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> sound/soc/pxa/mioa701_wm9713.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/pxa/mioa701_wm9713.c b/sound/soc/pxa/mioa701_wm9713.c
> index d1661fa..0fe0abe 100644
> --- a/sound/soc/pxa/mioa701_wm9713.c
> +++ b/sound/soc/pxa/mioa701_wm9713.c
> @@ -187,7 +187,7 @@ static int mioa701_wm9713_probe(struct platform_device *pdev)
> mioa701.dev = &pdev->dev;
> rc = devm_snd_soc_register_card(&pdev->dev, &mioa701);
> if (!rc)
> - dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will"
> + dev_warn(&pdev->dev, "Be warned that incorrect mixers/muxes setup will "
> "lead to overheating and possible destruction of your device."
> " Do not use without a good knowledge of mio's board design!\n");
>
There is already a continuation line that has a whitespace in front. It
would be nice to be consistent and also add the missing whitespace in
front of the succeeding line...
Lothar Wa?mann
^ permalink raw reply
* [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
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