* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-11-11 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a5c1318-de70-bcfc-648d-fd5a43c2fac5@wwwdotorg.org>
Stephen Warren <swarren@wwwdotorg.org> writes:
> On 10/27/2016 10:52 AM, Eric Anholt wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> The idea is to give useful names to GPIO lines that an implementer
>> will be using from userspace, e.g. for maker type projects. These are
>> user-visible using tools/gpio/lsgpio.c
>
>> arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-a.dts | 67 ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm2835-rpi-b.dts | 67 ++++++++++++++++++++++++++++++++
>
> Aren't the A and B rev 2 pinouts the same.
Looking at the contents of the patches and the schematics referenced
>From them: no, they aren't.
> If so, why duplicate the
> content between the files instead of creating an inclue file? Same for
> A+, B+, Pi 2, and Pi 3. Shouldn't this patch update the Pi 2 and Pi 3
> DTs too?
Pi2 and 3 would be lovely. If someone wants to write them, I'd
encourage them to.
> I think the whole point of naming GPIOs is to give users the same
> experience across the different boards where the same semantics exist in
> HW. Both the A+ and B+ use GPIO0/1 (a/k/a ID_SD/ID_SC a/k/a SDA0/SCL0)
> for the same semantic purpose and are exposed in the same externally
> visible way (same pins on the expansion header); the board ID EEPROM.
> Therefore I assert the names of these GPIOs should be identical on all
> boards that use them for that purpose, to allow SW (or human knowledge)
> portability between the boards.
I weakly agree with this, but find the idea of "consistent semantics"
attached to the names rather silly given the number of ways people
reconfigure the boards (particularly given that people can pinmux
things).
That said, I agree with you on renaming ID_SD to disagree with the
schematic in favor of consistency, and I've done so.
>> + "GPIO17",
>
> This pin is known as GPIO_GEN0 on the expansion header. Given the
> expansion header is all end-users likely care about, and other pins
> (e.g. SPI_CE1_N) are named after the expansion header, shouldn't this
> patch use the GPIO expansion header naming for all pins that are routed
> to that header?
We've already been through this. Users *don't* know the GENx names and
they were confusing and got eliminated in the later schematics. This
was done for consistency, like you asked for above!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/1ba7017a/attachment.sig>
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-11 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111120114.GA1076@amd>
On 11/11/2016 01:01 PM, Pavel Machek wrote:
> On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/10/2016 09:29 PM, Pavel Machek wrote:
>>> On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
>>>> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
>>>>> Hi!
>>>>>
>>>>>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>>>>>>>>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>>>>>>>>
>>>>>>>>> On my omap dm3730 based test system, idle power consumption is over 70
>>>>>>>>> times higher now with this patch! It goes from about 6mW for the core
>>>>>>>>> system to over 440mW during idle meaning there's some busy timer now
>>>>>>>>> active.
>>>>>>>>>
>>>>>>>>> Reverting this patch fixes the issue. Any ideas?
>>>>>
>>>>> Are you using any LED that toggles with high frequency? Like perhaps
>>>>> LED that is lit when CPU is active?
>>>>
>>>> Yeah one of them seems to have cpu0 as the default trigger.
>>>
>>> Aha. Its quite obvious we don't want to notify sysfs each time that
>>> one is toggled, right?
>>>
>>> IMO brightness should display max brightness for the trigger, as Hans
>>> suggested, anything else is madness for trigger such as cpu activity.
>>
>> Are you suggesting that we should revert changes introduced
>> by below patch?
>>
>> commit 29d76dfa29fe22583aefddccda0bc56aa81035dc
>> Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>> Date: Tue Mar 18 09:47:48 2008 +0000
>>
>> leds: Add support to leds with readable status
>>
>> Some led hardware allows drivers to query the led state, and this patch
>> adds a hook to let the led class take advantage of that information when
>> available.
>>
>> Without this functionality, when access to the led hardware is not
>> exclusive (i.e. firmware or hardware might change its state behind the
>> kernel's back), reality goes out of sync with the led class' idea of
>> what
>> the led is doing, which is annoying at best.
>
> Hmm. So userland can read the LED state, and it can get _some_ value
> back, but it can not know if it is current state or not.
>
> I don't think that's a good interface. I see it is from 2008... is
> someone using it? Maybe it is too late for revert.
I can imagine it being used in flash LED use case. E.g. one
could use oneshot trigger to trigger flash strobe, and then
he could periodically read brightness file to check, for whatever
reason, whether the flash is strobing.
> But I'd certainly not extend it with poll.
We could add a dedicated file e.g. hw_brightness_change for that
(maybe someone will have a better candidate for the file name).
This way it would be semantically consistent to report only
hardware originating brightness changes on it, which was the
initial reason for adding the brightness change notification
feature.
Moreover, LED class drivers could report on this file the
brightness level which was set by the firmware, which wouldn't
affect current LED class device brightness setting, unless
brightness file is read (and brightness_get op is supported).
> IMO reading/polling should only be available with some triggers. It
> does not make sense with "CPU load" trigger. It makes sense with
> "keyboard light changeable by hardware" trigger.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH V8 0/6] thermal: bcm2835: add thermal driver
From: Eric Anholt @ 2016-11-11 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478081906-12009-1-git-send-email-kernel@martin.sperl.org>
kernel at martin.sperl.org writes:
> From: Martin Sperl <kernel@martin.sperl.org>
Since Eduardo seems to be AFK, I've pulled this series to my -next
branches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/b4d84fe9/attachment.sig>
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-11 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111144539.GL10219@e106497-lin.cambridge.arm.com>
Hi, Liviu,
On 11/11/2016 10:45 PM, liviu.dudau at arm.com wrote:
> On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
>> Hi Arnd
>>
>>> -----Original Message-----
>>> From: Arnd Bergmann [mailto:arnd at arndb.de]
>>> Sent: 10 November 2016 16:07
>>> To: Gabriele Paoloni
>>> Cc: linux-arm-kernel at lists.infradead.org; Yuanzhichang;
>>> mark.rutland at arm.com; devicetree at vger.kernel.org;
>>> lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
>>> benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
>>> kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
>>> robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
>>> catalin.marinas at arm.com; olof at lixom.net; liviu.dudau at arm.com;
>>> bhelgaas at googl e.com; zhichang.yuan02 at gmail.com
>>> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
>>> Hip06
>>>
>>> On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
>>>>
>>>> Where should we get the range from? For LPC we know that it is going
>>>> Work on anything that is not used by PCI I/O space, and this is
>>>> why we use [0, PCIBIOS_MIN_IO]
>>>
>>> It should be allocated the same way we allocate PCI config space
>>> segments. This is currently done with the io_range list in
>>> drivers/pci/pci.c, which isn't perfect but could be extended
>>> if necessary. Based on what others commented here, I'd rather
>>> make the differences between ISA/LPC and PCI I/O ranges smaller
>>> than larger.
>
> Gabriele,
>
>>
>> I am not sure this would make sense...
>>
>> IMHO all the mechanism around io_range_list is needed to provide the
>> "mapping" between I/O tokens and physical CPU addresses.
>>
>> Currently the available tokens range from 0 to IO_SPACE_LIMIT.
>>
>> As you know the I/O memory accessors operate on whatever
>> __of_address_to_resource sets into the resource (start, end).
>>
>> With this special device in place we cannot know if a resource is
>> assigned with an I/O token or a physical address, unless we forbid
>> the I/O tokens to be in a specific range.
>>
>> So this is why we are changing the offsets of all the functions
>> handling io_range_list (to make sure that a range is forbidden to
>> the tokens and is available to the physical addresses).
>>
>> We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
>> because this is the maximum physical I/O range that a non PCI device
>> can operate on and because we believe this does not impose much
>> restriction on the available I/O token range; that now is
>> [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
>> So we believe that the chosen forbidden range can accommodate
>> any special ISA bus device with no much constraint on the rest
>> of I/O tokens...
>
> Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> actually need another variable for "reserving" an area in the I/O space
> that can be used for physical addresses rather than I/O tokens.
>
I think selecting PCIBIOS_MIN_IO as the separator of mapped and non-mapped I/O
range probably is not so reasonable.
PCIBIOS_MIN_IN is specific to PCI devices, it seems as the recommended minimal
start I/O address when assigning the pci device I/O region. It is probably not
defined in some platforms/architectures when no PCI is needed there. That is why
my patch caused some compile error on some archs;
But more important thing is that the PCIBIOS_MIN_IO has different value on
different platforms/architectures. On Arm64, it is 4K currently, but in other
archs, it is not true. And the maximum LPC I/O address should be 64K
theoretically, although for compatible ISA, 2K is enough.
So, It means using PCIBIOS_MIN_IO on arm64 can match our I/O reservation
require. But we can not make this indirectIO work well on other architectures.
I am thinking Arnd's suggestion. But I worry about I haven't completely
understood his idea. What about create a new bus host for LPC/ISA whose I/O
range can be 64KB? This LPC/ISA I/O range works similar to PCI host bridge's I/O
window, all the downstream devices under LPC/ISA should request I/O from that
root resource. But it seems Arnd want this root resource registered dynamically,
I am not sure how to do...
Anyway, if we have this root I/O resource, we don't need any new macro or
variable for the LPC/ISA I/O reservation.
Hope my thought is right.
Best,
Zhichang
> The one good example for using PCIBIOS_MIN_IO is when your platform/architecture
> does not support legacy ISA operations *at all*. In that case someone
> sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> so that it doesn't get used. With Zhichang's patch you now start forcing
> those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> For the general case you also have to bear in mind that PCIBIOS_MIN_IO could
> be zero. In that case, what is your "forbidden" range? [0, 0) ? So it makes
> sense to add a new #define that should only be defined by those architectures/
> platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> where I/O tokens can't be generated for.
>
> Best regards,
> Liviu
>
>>
>>>
>>>>> Your current version has
>>>>>
>>>>> if (arm64_extio_ops->pfout) \
>>>>> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>>>>> addr, value, sizeof(type)); \
>>>>>
>>>>> Instead, just subtract the start of the range from the logical
>>>>> port number to transform it back into a bus-local port number:
>>>>
>>>> These accessors do not operate on IO tokens:
>>>>
>>>> If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
>>>> addr is not going to be an I/O token; in fact patch 2/3 imposes that
>>>> the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
>>> PCIBIOS_MIN_IO
>>>> we have free physical addresses that the accessors can operate on.
>>>
>>> Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
>>> the logical I/O tokens, the purpose of that macro is really meant
>>> for allocating PCI I/O port numbers within the address space of
>>> one bus.
>>
>> As I mentioned above, special devices operate on CPU addresses directly,
>> not I/O tokens. For them there is no way to distinguish....
>>
>>>
>>> Note that it's equally likely that whichever next platform needs
>>> non-mapped I/O access like this actually needs them for PCI I/O space,
>>> and that will use it on addresses registered to a PCI host bridge.
>>
>> Ok so here you are talking about a platform that has got an I/O range
>> under the PCI host controller, right?
>> And this I/O range cannot be directly memory mapped but needs special
>> redirections for the I/O tokens, right?
>>
>> In this scenario registering the I/O ranges with the forbidden range
>> implemented by the current patch would still allow to redirect I/O
>> tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
>>
>> So effectively the special PCI host controller
>> 1) knows the physical range that needs special redirection
>> 2) register such range
>> 3) uses pci_pio_to_address() to retrieve the IO tokens for the
>> special accessors
>> 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
>>
>> So to be honest I think this patch can fit well both with
>> special PCI controllers that need I/O tokens redirection and with
>> special non-PCI controllers that need non-PCI I/O physical
>> address redirection...
>>
>> Thanks (and sorry for the long reply but I didn't know how
>> to make the explanation shorter :) )
>>
>> Gab
>>
>>>
>>> If we separate the two steps:
>>>
>>> a) assign a range of logical I/O port numbers to a bus
>>> b) register a set of helpers for redirecting logical I/O
>>> port to a helper function
>>>
>>> then I think the code will get cleaner and more flexible.
>>> It should actually then be able to replace the powerpc
>>> specific implementation.
>>>
>>> Arnd
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
Add a device tree file for it.
As there's still no mainline-compatible driver for the SDIO WLAN card on
board (a new card by Allwinner), the mmc1 controller is not enabled yet.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 148 +++++++++++++++++++++++
2 files changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9843fb0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -818,6 +818,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-h2plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
new file mode 100644
index 0000000..581f56e
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun8i-h3-orangepi-one.dts, which is:
+ * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h2plus.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi Zero";
+ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus",
+ "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ leds_opi0: led_pins at 0 {
+ allwinner,pins = "PA17";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&r_pio {
+ leds_r_opi0: led_pins at 0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "disabled";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+ status = "disabled";
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sunxi: add Allwinner H2+ dtsi
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111164654.15273-1-icenowy@aosc.xyz>
Allwinner H2+ is a SoC so similar with H3 that H3 drivers and memory map
is known to work well on H2+, with both BSP kernel/firmware or the
mainline ones.
So add a dtsi file which only include the H3 dtsi only, so we can add
H2+-specified nodes in the dtsi file when we find any software
difference between H2+ and H3.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-h2plus.dtsi | 43 +++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus.dtsi
diff --git a/arch/arm/boot/dts/sun8i-h2plus.dtsi b/arch/arm/boot/dts/sun8i-h2plus.dtsi
new file mode 100644
index 0000000..76fc3d0
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun8i-h3.dtsi"
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner H2+ is a quad-core Cortex-A7 SoC.
It is very like H3, that they share the same SoC ID (0x1680), and H3
memory maps as well as drivers works well on the SoC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/arm/sunxi/README | 4 ++++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index cd02433..1fe4d99c 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -63,6 +63,10 @@ SunXi family
+ User Manual
http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
+ - Allwinner H2+ (sun8i)
+ + No document available now, but is known to be working properly with
+ H3 drivers and memory map.
+
- Allwinner H3 (sun8i)
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 3975d0a..0c0f277 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -13,5 +13,6 @@ using one of the following compatible strings:
allwinner,sun8i-a33
allwinner,sun8i-a83t
allwinner,sun8i-h3
+ allwinner,sun8i-h2plus
allwinner,sun9i-a80
nextthing,gr8
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 2e2bde2..3647ad7 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
"allwinner,sun8i-a83t",
+ "allwinner,sun8i-h2plus",
"allwinner,sun8i-h3",
NULL,
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/2] regulator: Add coupled regulator
From: Mark Brown @ 2016-11-11 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107154738.ewliwzx5plams4ni@lukather>
On Mon, Nov 07, 2016 at 04:47:38PM +0100, Maxime Ripard wrote:
> Since regulator_get returns a struct regulator pointer, it felt
> logical to try to add the list of parent regulators to it, especially
> as this structure is per-consumer, and different consumers might have
> different combinations of regulators.
> However, this structure embeds a pointer to a struct regulator_dev,
> which seems to model the regulator itself, but will also contain
> pointer to the struct regulator, probably to model its parent? I guess
It'd be a lot easier to follow this if you named the fields... The rdev
in the struct regulator is indeed the physical device. The struct
regulator called supply in struct regulator_dev is indeed the parent
regulator.
> my first question would be do we care about nesting? or having a
> regulator with multiple parents?
Well, it seems that your use case here is multiple parents so I guess we
do care about it. :)
> It also contains the constraints on each regulator, which might or
> might not be different for each of the coupled regulators, but I'm
> guessing the couple might have contraints of its own too I guess. Is
> it something that might happen? Should we care about it?
I can't see how one could physically have constraints that didn't apply
to both parents.
> And finally, my real question is, do we want to aggregate them in
> struct regulator, at the consumer level, which might make the more
> sense, or do we want to create an intermediate regulator internally?
> What is your take on this?
My initial thought without having tried to implement this is that doing
things in an intermediate regulator might do a better job of
encapsulating things it if it works out but I've got a feeling that it's
not going to work out well and that therefore doing it in the consumer
with multiple rdevs will be better. But really either approach is fine
if it doesn't look horrible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/8ecde8e8/attachment.sig>
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-11 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111162211.GU2078@8bytes.org>
Hi Joerg,
On 11/11/2016 17:22, Joerg Roedel wrote:
> Hi Eric,
>
> On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote:
>> Effectively in passthrough use case, the userspace defines the address
>> space layout and maps guest RAM PA=IOVA to PAs (using
>> VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI
>> IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA
>> region must be allocated by either the VFIO driver or the IOMMU driver I
>> think. Who else could initialize the IOVA allocator domain?
>
> So I think we need a way to tell userspace about the reserved regions
> (per iommu-group) so that userspace knows where it can not map anything,
Current plan is to expose that info through an iommu-group sysfs
attribute, as you and Robin advised.
> and VFIO can enforce that. But the right struct here is not an
> iova-allocator rb-tree, a ordered linked list should be sufficient.
I plan a linked list to store the reserved regions (P2P regions, MSI
region, ...). get_dma_regions is called with a list local to a function
for that. Might be needed to move that list head in the iommu_group to
avoid calling the get_dm_regions again in the attribute show function?
But to allocate the IOVAs within the MSI reserved region, I understand
you don't want us to use the iova.c allocator, is that correct? We need
an allocator though, even a very basic one based on bitmap or whatever.
There potentially have several different physical MSI frame pages to map.
Best Regards
Eric
>
>
> Joerg
>
^ permalink raw reply
* [PATCH] ARM: davinci: enable PM for DT boot
From: Kevin Hilman @ 2016-11-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c73eab0-dadd-f8a0-f822-84296d319443@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Tuesday 08 November 2016 11:43 PM, Kevin Hilman wrote:
>> Hi Sekhar,
>>
>> Sekhar Nori <nsekhar@ti.com> writes:
>>
>>> On Wednesday 26 October 2016 03:17 AM, Kevin Hilman wrote:
>>>> Currently system PM is only enabled for legacy (non-DT) boot. Enable
>>>> for DT boot also.
>>>>
>>>> Tested on da850-lcdk using "rtcwake -m mem -s5 -d rtc0".
>>>>
>>>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>>>> ---
>>>> arch/arm/mach-davinci/da8xx-dt.c | 18 ++++++++++++++++++
>>>> 1 file changed, 18 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
>>>> index c9f7e9274aa8..a8089fa40d86 100644
>>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>>> @@ -43,8 +43,26 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>>>>
>>>> #ifdef CONFIG_ARCH_DAVINCI_DA850
>>>>
>>>> +static struct davinci_pm_config da850_pm_pdata = {
>>>> + .sleepcount = 128,
>>>> +};
>>>> +
>>>> +static struct platform_device da850_pm_device = {
>>>> + .name = "pm-davinci",
>>>> + .dev = {
>>>> + .platform_data = &da850_pm_pdata,
>>>> + },
>>>> + .id = -1,
>>>> +};
>>>> +
>>>> static void __init da850_init_machine(void)
>>>> {
>>>> + int ret;
>>>> +
>>>> + ret = da850_register_pm(&da850_pm_device);
>>>
>>> I am not sure if it makes sense to keep the "pm device" around anymore.
>>> I think for both DT and non-DT boot, we can get rid of the fake PM
>>> device and combine da850_register_pm() and davinci_pm_probe() into a
>>> single davinci_init_suspend() function which can then be called both for
>>> DT and non-DT boot.
>>
>> Looking closer at this, where do you propose the pdata comes from for
>> the non-DT boot?
>>
>> It seems to me that we can't currently remove the pdata dependency
>> without breaking the non-DT platforms, so the approach proposed here is
>> the least invasive.
>
> There is a single value of sleep count that is used today (128). So I
> was thinking we can hardcode that in pm.c. We are not going to add more
> board files anyway so there is no risk here.
>
> For future, if a different sleepcount value is needed, it will need to
> be a new DT property.
Right, but getting rid of the pdata is more than just hard-coding the
sleep count. There are a bunch of other fields in the pdata, which are
filled out to some standard defaults in da850.c. Are you proposing to
hard-code those in pm.c also?
An intermediate step might be to start by removing the
platform_device/pdata from the board files, but keep it in da850.c for
now. Then, a follow-up cleanup could be done to either move all of that
into pm.c, or use DT.
Kevin
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Joerg Roedel @ 2016-11-11 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <552e674a-f434-f08f-8e16-a94544ce8e6e@arm.com>
On Fri, Nov 11, 2016 at 04:17:37PM +0000, Robin Murphy wrote:
> In the original of_iommu_configure design, the thought was that an ops
> structure could be IOMMU-instance-specific (hence the later-removed
> "priv" member), so I suppose right now it is mostly a hangover from
> that. However, it's also what we initialise a device's fwspec with, so
> becomes important again if we're ever going to get past the limitations
> of buses-which-are-not-actually-buses[1].
Yeah, I discussed this with a few others at LPC. My current idea is to
tell the iommu-core which hardware-iommus exist in the system and a
seperate iommu_ops ptr for each of them. Then every struct device can
link to the iommu-instance it is translated by.
We are not there yet, but this will give you the same per-device
iommu-ops as implemented here.
Joerg
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-11 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111085056.4cf8989d@t450s.home>
On 11/11/2016 10:50 AM, Alex Williamson wrote:
> On Fri, 11 Nov 2016 12:19:44 +0100
> Joerg Roedel <joro@8bytes.org> wrote:
>
>> On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
>>> In the case of x86, we know that DMA mappings overlapping the MSI
>>> doorbells won't be translated correctly, it's not a valid mapping for
>>> that range, and therefore the iommu driver backing the IOMMU API
>>> should describe that reserved range and reject mappings to it.
>>
>> The drivers actually allow mappings to the MSI region via the IOMMU-API,
>> and I think it should stay this way also for other reserved ranges.
>> Address space management is done by the IOMMU-API user already (and has
>> to be done there nowadays), be it a DMA-API implementation which just
>> reserves these regions in its address space allocator or be it VFIO with
>> QEMU, which don't map RAM there anyway. So there is no point of checking
>> this again in the IOMMU drivers and we can keep that out of the
>> mapping/unmapping fast-path.
>
> It's really just a happenstance that we don't map RAM over the x86 MSI
> range though. That property really can't be guaranteed once we mix
> architectures, such as running an aarch64 VM on x86 host via TCG.
> AIUI, the MSI range is actually handled differently than other DMA
> ranges, so a iommu_map() overlapping a range that the iommu cannot map
> should fail just like an attempt to map beyond the address width of the
> iommu.
>
+1. As was stated at Plumbers, x86 MSI is in a fixed, hw location, so:
1) that memory space is never a valid page to the system to be used for IOVA,
therefore, nothing to micro-manage in the iommu mapping (fast) path.
2) migration btwn different systems isn't an issue b/c all x86 systems have this mapping.
3) ACS resolves DMA writes to mem going to a device(-mmio space).
For aarch64, without such a 'fixed' MSI location, whatever hole/used-space-struct
concept that is contrived for MSI (DMA) writes on aarch64 won't guarantee migration
failure across mixed aarch64 systems (migrate guest-G from sys-vendor-A to
sys-vendor-B; sys-vendor-A has MSI at addr-A; sys-vendor-B has MSI at addr-B).
Without agreement, migration only possilbe across the same systems (can even
be broken btwn two sytems from same vendor). ACS in the PCIe path handles
the iova->dev-mmio collision problem. q.e.d.
ergo, my proposal to put MSI space as the upper-most, space of any system....
FFFF.FFFF.FFFE0.0000 ... and hw drops the upper 1's/F's, and uses that for MSI.
Allows it to vary on each system based on max-memory. pseudo-fixed, but not
right smack in the middle of mem-space.
There is an inverse scenario for host phys addr's as well:
Wiring the upper-most bit of HPA to be 1==mmio, 0=mem simplifies a lot of
design issues in the cores & chipsets as well. Alpha-EV6, case in point
(18+ yr old design decision). another q.e.d.
I hate to admit it, but jcm has it right wrt 'fixed sys addr map', at least in this IO area.
>>> For PCI devices userspace can examine the topology of the iommu group
>>> and exclude MMIO ranges of peer devices based on the BARs, which are
>>> exposed in various places, pci-sysfs as well as /proc/iomem. For
>>> non-PCI or MSI controllers... ???
>>
>> Right, the hardware resources can be examined. But maybe this can be
>> extended to also cover RMRR ranges? Then we would be able to assign
>> devices with RMRR mappings to guests.
>
> RMRRs are special in a different way, the VT-d spec requires that the
> OS honor RMRRs, the user has no responsibility (and currently no
> visibility) to make that same arrangement. In order to potentially
> protect the physical host platform, the iommu drivers should prevent a
> user from remapping RMRRS. Maybe there needs to be a different
> interface used by untrusted users vs in-kernel drivers, but I think the
> kernel really needs to be defensive in the case of user mappings, which
> is where the IOMMU API is rooted. Thanks,
>
> Alex
>
^ permalink raw reply
* [PATCH RFC 00/12] tda998x updates
From: Jyri Sarha @ 2016-11-11 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111152700.GD1041@n2100.armlinux.org.uk>
On 11/11/16 17:27, Russell King - ARM Linux wrote:
> On Fri, Nov 11, 2016 at 05:10:09PM +0200, Jyri Sarha wrote:
>> On 11/08/16 14:24, Russell King - ARM Linux wrote:
>>> As no one responded to the previous round, I'm not spending soo much
>>> time writing up a description of these changes again. It's also been
>>> quite a long time, so I've forgotten all the details of the changes,
>>> so I'll do my best.
>>>
>>> Changes from the previous series include:
>>> - reorder the initial three patches
>>> - change the (now third patch)... I think to increase the size of the
>>> locked region.
>>> - fix edid parsing for infoframe generation - as was pointed out for
>>> dw-hdmi, parsing the EDID in get_modes() is incorrect, as that method
>>> will not be called when an override-edid is in effect. We need to
>>> parse the override-edid. Moreover, infoframe generation should not
>>> be keyed to whether the monitor is HDMI or not, CEA-861B allows non-
>>> HDMI to send infoframes.
>>> - only send audio if audio and infoframes are supported.
>>>
>>> Otherwise, these are very much like the previous posting of the series,
>>> except rebased upon the mali/hdlcd/tda998x change to remove the
>>> drm_connector_register() call.
>>>
>>> https://www.spinics.net/lists/dri-devel/msg121495.html
>>>
>>> It'd be nice to have other tda998x users ack and test these patches,
>>> I've tried to test on Juno, but the Juno situation seems to be a huge
>>> fail. (HBI0282B completely fails with latest firmware - (a) FPGA image
>>> incompatibilities io_b118 causes all FPGA AMBA devices to vanish, (b)
>>> seems no way to get SCPI support on it - adding the BL0 executable
>>> start address in the SCC registers seems to be incompatible with the
>>> devchip, causing the PLLs to fail. In discussion with Sudeep over
>>> these issues, but no idea where things are with it at the moment, other
>>> than Sudeep needs to investigate. All Linaro firmware releases are
>>> broken on HBI0282B.)
>>>
>>> drivers/gpu/drm/i2c/tda998x_drv.c | 826 ++++++++++++++++++++------------------
>>> 1 file changed, 429 insertions(+), 397 deletions(-)
>>>
>>
>> Reviewed-by: Jyri Sarha <jsarha@ti.com>
>>
>> For the whole series. I am also happy to test these patches if I can
>> fetch them from some git repo.
>
> git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
>
> The commit IDs are unstable, because I'll have to recommit them to add
> your r-by and any other tags you later give me. :)
>
I tested the branch with my Beaglebone-black and couple of TVs. I played
audio on different sample-rates while plugging and unplugging the cable
to the TVs and changing video modes. Everything worked as it should. I
let you decide whether or not this adhoc testing qualifies:
Tested-by: Jyri Sarha <jsarha@ti.com>
Best regards,
Jyri
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-11 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79da09b8-ac1e-cebf-5393-7d67f002b3e3@redhat.com>
Hi Eric,
On Fri, Nov 11, 2016 at 04:47:01PM +0100, Auger Eric wrote:
> Effectively in passthrough use case, the userspace defines the address
> space layout and maps guest RAM PA=IOVA to PAs (using
> VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI
> IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA
> region must be allocated by either the VFIO driver or the IOMMU driver I
> think. Who else could initialize the IOVA allocator domain?
So I think we need a way to tell userspace about the reserved regions
(per iommu-group) so that userspace knows where it can not map anything,
and VFIO can enforce that. But the right struct here is not an
iova-allocator rb-tree, a ordered linked list should be sufficient.
Joerg
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-11 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111152248.GS2078@8bytes.org>
On 11/11/16 15:22, Joerg Roedel wrote:
> On Wed, Nov 09, 2016 at 02:19:36PM +0000, Lorenzo Pieralisi wrote:
>> +struct iommu_fwentry {
>> + struct list_head list;
>> + struct fwnode_handle *fwnode;
>> + const struct iommu_ops *ops;
>> +};
>
> Is there a reason the iommu_ops need to be stored there? Currently it
> seems that the ops are only needed to get the of_xlate fn-ptr later. And
> the place where it is called the iommu-ops should also be available
> through pdev->dev->bus->iommu_ops.
In the original of_iommu_configure design, the thought was that an ops
structure could be IOMMU-instance-specific (hence the later-removed
"priv" member), so I suppose right now it is mostly a hangover from
that. However, it's also what we initialise a device's fwspec with, so
becomes important again if we're ever going to get past the limitations
of buses-which-are-not-actually-buses[1].
Robin.
[1]:http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Alex Williamson @ 2016-11-11 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111085056.4cf8989d@t450s.home>
On Fri, 11 Nov 2016 08:50:56 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Fri, 11 Nov 2016 12:19:44 +0100
> Joerg Roedel <joro@8bytes.org> wrote:
>
> > On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
> > > In the case of x86, we know that DMA mappings overlapping the MSI
> > > doorbells won't be translated correctly, it's not a valid mapping for
> > > that range, and therefore the iommu driver backing the IOMMU API
> > > should describe that reserved range and reject mappings to it.
> >
> > The drivers actually allow mappings to the MSI region via the IOMMU-API,
> > and I think it should stay this way also for other reserved ranges.
> > Address space management is done by the IOMMU-API user already (and has
> > to be done there nowadays), be it a DMA-API implementation which just
> > reserves these regions in its address space allocator or be it VFIO with
> > QEMU, which don't map RAM there anyway. So there is no point of checking
> > this again in the IOMMU drivers and we can keep that out of the
> > mapping/unmapping fast-path.
>
> It's really just a happenstance that we don't map RAM over the x86 MSI
> range though. That property really can't be guaranteed once we mix
> architectures, such as running an aarch64 VM on x86 host via TCG.
> AIUI, the MSI range is actually handled differently than other DMA
> ranges, so a iommu_map() overlapping a range that the iommu cannot map
> should fail just like an attempt to map beyond the address width of the
> iommu.
(clarification, this is x86 specific, the MSI controller - interrupt
remapper - is embedded in the iommu AIUI, so the iommu is actually not
able to provide DMA translation for this range. In architectures where
the MSI controller is separate from the iommu, I agree that the iommu
has no responsibility to fault mapping of iova ranges in the shadow of
an external MSI controller)
> > > For PCI devices userspace can examine the topology of the iommu group
> > > and exclude MMIO ranges of peer devices based on the BARs, which are
> > > exposed in various places, pci-sysfs as well as /proc/iomem. For
> > > non-PCI or MSI controllers... ???
> >
> > Right, the hardware resources can be examined. But maybe this can be
> > extended to also cover RMRR ranges? Then we would be able to assign
> > devices with RMRR mappings to guests.
>
> RMRRs are special in a different way, the VT-d spec requires that the
> OS honor RMRRs, the user has no responsibility (and currently no
> visibility) to make that same arrangement. In order to potentially
> protect the physical host platform, the iommu drivers should prevent a
> user from remapping RMRRS. Maybe there needs to be a different
> interface used by untrusted users vs in-kernel drivers, but I think the
> kernel really needs to be defensive in the case of user mappings, which
> is where the IOMMU API is rooted. Thanks,
>
> Alex
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* ??
From: Steven Rostedt @ 2016-11-11 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG2=9p_3nLD6MuLXPsbfC8LqK76LbwD3BDRUjX3uEUrijZnYCg@mail.gmail.com>
On Fri, 11 Nov 2016 11:38:45 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
What happened to the subject?
> >>> +static void
> >>> +trace_process_export(struct trace_export *export,
> >>> + struct ring_buffer_event *event)
> >>> +{
> >>> + struct trace_entry *entry;
> >>> + unsigned int size = 0;
> >>> +
> >>> + entry = ring_buffer_event_data(event);
> >>> +
> >>> + size = ring_buffer_event_length(event);
> >>> +
> >>> + if (export->write)
> >>> + export->write((char *)entry, size);
> >>
> >> Is there ever going to be a time where export->write wont be set?
> >
> > There hasn't been since only one trace_export (i.e. stm_ftrace) was
> > added in this patch-set , I just wanted to make sure the write() has
> > been set before registering trace_export like what I added in 2/3 of
> > this series.
> >
> >>
> >> And if there is, this can be racy. As in
> >>
> >>
> >> CPU 0: CPU 1:
> >> ------ ------
> >> if (export->write)
> >>
> >> export->write = NULL;
> >
> > Is there going to be this kind of use case? Why some one needs to
> > change export->write() rather than register a new trace_export?
> >
> > I probably haven't understood your point thoroughly, please correct me
> > if my guess was wrong.
> >
>
> Any further comments? :)
I don't remember which patch series this goes to, so right now, no.
-- Steve
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-11 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111111944.GO2078@8bytes.org>
On 11/11/2016 06:19 AM, Joerg Roedel wrote:
> On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
>> In the case of x86, we know that DMA mappings overlapping the MSI
>> doorbells won't be translated correctly, it's not a valid mapping for
>> that range, and therefore the iommu driver backing the IOMMU API
>> should describe that reserved range and reject mappings to it.
>
> The drivers actually allow mappings to the MSI region via the IOMMU-API,
> and I think it should stay this way also for other reserved ranges.
> Address space management is done by the IOMMU-API user already (and has
> to be done there nowadays), be it a DMA-API implementation which just
> reserves these regions in its address space allocator or be it VFIO with
> QEMU, which don't map RAM there anyway. So there is no point of checking
> this again in the IOMMU drivers and we can keep that out of the
> mapping/unmapping fast-path.
>
>> For PCI devices userspace can examine the topology of the iommu group
>> and exclude MMIO ranges of peer devices based on the BARs, which are
>> exposed in various places, pci-sysfs as well as /proc/iomem. For
>> non-PCI or MSI controllers... ???
>
> Right, the hardware resources can be examined. But maybe this can be
> extended to also cover RMRR ranges? Then we would be able to assign
> devices with RMRR mappings to guests.
>
eh gads no!
Assigning devices w/RMRR's is a security issue waiting to happen, if
it doesn't crash the system before the guest even gets the device --
reset the device before assignment; part of device is gathering system
environmental data; if BIOS/SMM support doesn't get env. data update,
it NMI's the system..... in fear that it may overheat ...
>
>
> Joerg
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6q-utilite-pro: i2c1 is muxed
From: christopher.spinrath at rwth-aachen.de @ 2016-11-11 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111155939.446-1-christopher.spinrath@rwth-aachen.de>
From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
It turns out that the i2c1 adapter is connected to a multiplexer
controlled by a gpio line. The first (default) mux option connects
i2c1 to a bus connected to the already known peripherals. The other
one connects the adapter to the ddc pins of the DVI port.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
---
arch/arm/boot/dts/imx6q-utilite-pro.dts | 51 ++++++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 6199063..246979a 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -71,6 +71,40 @@
gpio-key,wakeup;
};
};
+
+ i2cmux {
+ compatible = "i2c-mux-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1mux>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ i2c-parent = <&i2c1>;
+
+ i2c at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom at 50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+
+ em3027: rtc at 56 {
+ compatible = "emmicro,em3027";
+ reg = <0x56>;
+ };
+ };
+
+ i2c_dvi_ddc: i2c at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
};
&hdmi {
@@ -82,17 +116,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
-
- eeprom at 50 {
- compatible = "at24,24c02";
- reg = <0x50>;
- pagesize = <16>;
- };
-
- em3027: rtc at 56 {
- compatible = "emmicro,em3027";
- reg = <0x56>;
- };
};
&i2c2 {
@@ -115,6 +138,12 @@
>;
};
+ pinctrl_i2c1mux: i2c1muxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6q-cm-fx6: fix fec pinctrl
From: christopher.spinrath at rwth-aachen.de @ 2016-11-11 15:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
According to the schematics of CompuLab's sbc-fx6 baseboard and the
vendor devicetree GPIO_16 is *not* muxed to ENET_REF_CLK but to SPDIF_IN.
Remove the wrong pinctrl setting.
Fixes: 682d055e6ac5 ("ARM: dts: Add initial support for cm-fx6.")
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
---
arch/arm/boot/dts/imx6q-cm-fx6.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 59bc5a4..a150bca 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -183,7 +183,6 @@
MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
- MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
>;
};
--
2.10.2
^ permalink raw reply related
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-11 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111144539.GL10219@e106497-lin.cambridge.arm.com>
Hi Liviu
> -----Original Message-----
> From: liviu.dudau at arm.com [mailto:liviu.dudau at arm.com]
> Sent: 11 November 2016 14:46
> To: Gabriele Paoloni
> Cc: Arnd Bergmann; linux-arm-kernel at lists.infradead.org; Yuanzhichang;
> mark.rutland at arm.com; devicetree at vger.kernel.org;
> lorenzo.pieralisi at arm.com; minyard at acm.org; linux-pci at vger.kernel.org;
> benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> catalin.marinas at arm.com; olof at lixom.net; bhelgaas at googl e.com;
> zhichang.yuan02 at gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> > Hi Arnd
> >
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: 10 November 2016 16:07
> > > To: Gabriele Paoloni
> > > Cc: linux-arm-kernel at lists.infradead.org; Yuanzhichang;
> > > mark.rutland at arm.com; devicetree at vger.kernel.org;
> > > lorenzo.pieralisi at arm.com; minyard at acm.org; linux-
> pci at vger.kernel.org;
> > > benh at kernel.crashing.org; John Garry; will.deacon at arm.com; linux-
> > > kernel at vger.kernel.org; xuwei (O); Linuxarm; zourongrong at gmail.com;
> > > robh+dt at kernel.org; kantyzc at 163.com; linux-serial at vger.kernel.org;
> > > catalin.marinas at arm.com; olof at lixom.net; liviu.dudau at arm.com;
> > > bhelgaas at googl e.com; zhichang.yuan02 at gmail.com
> > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > > Hip06
> > >
> > > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni
> wrote:
> > > >
> > > > Where should we get the range from? For LPC we know that it is
> going
> > > > Work on anything that is not used by PCI I/O space, and this is
> > > > why we use [0, PCIBIOS_MIN_IO]
> > >
> > > It should be allocated the same way we allocate PCI config space
> > > segments. This is currently done with the io_range list in
> > > drivers/pci/pci.c, which isn't perfect but could be extended
> > > if necessary. Based on what others commented here, I'd rather
> > > make the differences between ISA/LPC and PCI I/O ranges smaller
> > > than larger.
>
> Gabriele,
>
> >
> > I am not sure this would make sense...
> >
> > IMHO all the mechanism around io_range_list is needed to provide the
> > "mapping" between I/O tokens and physical CPU addresses.
> >
> > Currently the available tokens range from 0 to IO_SPACE_LIMIT.
> >
> > As you know the I/O memory accessors operate on whatever
> > __of_address_to_resource sets into the resource (start, end).
> >
> > With this special device in place we cannot know if a resource is
> > assigned with an I/O token or a physical address, unless we forbid
> > the I/O tokens to be in a specific range.
> >
> > So this is why we are changing the offsets of all the functions
> > handling io_range_list (to make sure that a range is forbidden to
> > the tokens and is available to the physical addresses).
> >
> > We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> > because this is the maximum physical I/O range that a non PCI device
> > can operate on and because we believe this does not impose much
> > restriction on the available I/O token range; that now is
> > [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> > So we believe that the chosen forbidden range can accommodate
> > any special ISA bus device with no much constraint on the rest
> > of I/O tokens...
>
> Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> actually need another variable for "reserving" an area in the I/O space
> that can be used for physical addresses rather than I/O tokens.
>
> The one good example for using PCIBIOS_MIN_IO is when your
> platform/architecture
> does not support legacy ISA operations *at all*. In that case someone
> sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> so that it doesn't get used. With Zhichang's patch you now start
> forcing
> those platforms to have a valid address below PCIBIOS_MIN_IO.
But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be used
by PCI controllers only...so if you have a special bus device using
an I/O range in this case should be a PCI controller...i.e. I would
expect it to fall back into the case of I/O tokens redirection rather than
physical addresses redirection (as mentioned below from my previous reply).
What do you think?
Thanks
Gab
>
> For the general case you also have to bear in mind that PCIBIOS_MIN_IO
> could
> be zero. In that case, what is your "forbidden" range? [0, 0) ? So it
> makes
> sense to add a new #define that should only be defined by those
> architectures/
> platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> where I/O tokens can't be generated for.
>
> Best regards,
> Liviu
>
> >
> > >
> > > > > Your current version has
> > > > >
> > > > > if (arm64_extio_ops->pfout)
> \
> > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> >devpara,\
> > > > > addr, value, sizeof(type));
> \
> > > > >
> > > > > Instead, just subtract the start of the range from the logical
> > > > > port number to transform it back into a bus-local port number:
> > > >
> > > > These accessors do not operate on IO tokens:
> > > >
> > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> > > > addr is not going to be an I/O token; in fact patch 2/3 imposes
> that
> > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > PCIBIOS_MIN_IO
> > > > we have free physical addresses that the accessors can operate
> on.
> > >
> > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer
> to
> > > the logical I/O tokens, the purpose of that macro is really meant
> > > for allocating PCI I/O port numbers within the address space of
> > > one bus.
> >
> > As I mentioned above, special devices operate on CPU addresses
> directly,
> > not I/O tokens. For them there is no way to distinguish....
> >
> > >
> > > Note that it's equally likely that whichever next platform needs
> > > non-mapped I/O access like this actually needs them for PCI I/O
> space,
> > > and that will use it on addresses registered to a PCI host bridge.
> >
> > Ok so here you are talking about a platform that has got an I/O range
> > under the PCI host controller, right?
> > And this I/O range cannot be directly memory mapped but needs special
> > redirections for the I/O tokens, right?
> >
> > In this scenario registering the I/O ranges with the forbidden range
> > implemented by the current patch would still allow to redirect I/O
> > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> >
> > So effectively the special PCI host controller
> > 1) knows the physical range that needs special redirection
> > 2) register such range
> > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > special accessors
> > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
> >
> > So to be honest I think this patch can fit well both with
> > special PCI controllers that need I/O tokens redirection and with
> > special non-PCI controllers that need non-PCI I/O physical
> > address redirection...
> >
> > Thanks (and sorry for the long reply but I didn't know how
> > to make the explanation shorter :) )
> >
> > Gab
> >
> > >
> > > If we separate the two steps:
> > >
> > > a) assign a range of logical I/O port numbers to a bus
> > > b) register a set of helpers for redirecting logical I/O
> > > port to a helper function
> > >
> > > then I think the code will get cleaner and more flexible.
> > > It should actually then be able to replace the powerpc
> > > specific implementation.
> > >
> > > Arnd
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ?\_(?)_/?
^ permalink raw reply
* [RFC PATCH 6/6] [media] davinci: vpif_capture: get subdevs from DT
From: Javier Martinez Canillas @ 2016-11-11 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv==ZR0=4GhXECiKtFJZ3WEY_5h-Egvs3hjBK56FiQeF6Jg@mail.gmail.com>
On Fri, Nov 11, 2016 at 12:50 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
[snip]
> So if you can comment on this and see if the DT bindings fits your,
> would be very useful.
>
Sorry, I wanted to write "if the DT bindings fits your needs, it would
be very useful".
Best regards,
Javier
^ permalink raw reply
* Applied "regulator: axp20x: Fix axp809 ldo_io registration error on cold boot" to the regulator tree
From: Mark Brown @ 2016-11-11 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111031243.20236-1-wens@csie.org>
The patch
regulator: axp20x: Fix axp809 ldo_io registration error on cold boot
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 618c808968852609d2d9f0e5cfc351a4807ef8d0 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Fri, 11 Nov 2016 11:12:43 +0800
Subject: [PATCH] regulator: axp20x: Fix axp809 ldo_io registration error on
cold boot
The maximum supported voltage for ldo_io# is 3.3V, but on cold boot
the selector comes up at 0x1f, which maps to 3.8V. This was previously
corrected by Allwinner's U-boot, which set all regulators on the PMICs
to some pre-configured voltage. With recent progress in U-boot SPL
support, this is no longer the case. In any case we should handle
this quirk in the kernel driver as well.
This invalid setting causes _regulator_get_voltage() to fail with -EINVAL
which causes regulator registration to fail when constrains are used:
[ 1.054181] vcc-pg: failed to get the current voltage(-22)
[ 1.059670] axp20x-regulator axp20x-regulator.0: Failed to register ldo_io0
[ 1.069749] axp20x-regulator: probe of axp20x-regulator.0 failed with error -22
This commits makes the axp20x regulator driver accept the 0x1f register
value, fixing this.
The datasheet does not guarantee reliable operation above 3.3V, so on
boards where this regulator is used the regulator-max-microvolt setting
must be 3.3V or less.
This is essentially the same as the commit f40d4896bf32 ("regulator:
axp20x: Fix axp22x ldo_io registration error on cold boot") for AXP22x
PMICs.
Fixes: a51f9f4622a3 ("regulator: axp20x: support AXP809 variant")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/axp20x-regulator.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 54382ef902c6..e6a512ebeae2 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -337,10 +337,18 @@ static const struct regulator_desc axp809_regulators[] = {
AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
AXP_DESC(AXP809, ELDO3, "eldo3", "eldoin", 700, 3300, 100,
AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
- AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+ /*
+ * Note the datasheet only guarantees reliable operation up to
+ * 3.3V, this needs to be enforced via dts provided constraints
+ */
+ AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3800, 100,
AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
- AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+ /*
+ * Note the datasheet only guarantees reliable operation up to
+ * 3.3V, this needs to be enforced via dts provided constraints
+ */
+ AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3800, 100,
AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
AXP_DESC_FIXED(AXP809, RTC_LDO, "rtc_ldo", "ips", 1800),
--
2.10.2
^ permalink raw reply related
* Applied "regulator: gpio: properly check return value of of_get_named_gpio" to the regulator tree
From: Mark Brown @ 2016-11-11 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110092129.2203-1-jszhang@marvell.com>
The patch
regulator: gpio: properly check return value of of_get_named_gpio
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 09f2ba0b0b7c44ecea49cf69a708203b76ba5535 Mon Sep 17 00:00:00 2001
From: Jisheng Zhang <jszhang@marvell.com>
Date: Thu, 10 Nov 2016 17:21:29 +0800
Subject: [PATCH] regulator: gpio: properly check return value of
of_get_named_gpio
The function of_get_named_gpio() could return -ENOENT, -EPROBE_DEFER
-EINVAL and so on. Currently, for the optional property "enable-gpio",
we only check -EPROBE_DEFER, this is not enough since there may be
misconfigured "enable-gpio" in the DTB, of_get_named_gpio() will return
-EINVAL in this case, we should return immediately here. And for the
optional property "gpios", we didn't check the return value, the driver
will continue to the point where gpio_request_array() is called, it
doesn't make sense to continue if we got -EPROBE_DEFER or -EINVAL here.
This patch tries to address these two issues by properly checking the
return value of of_get_named_gpio.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/gpio-regulator.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c
index 83e89e5d4752..0fce06acfaec 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -162,8 +162,8 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
of_property_read_u32(np, "startup-delay-us", &config->startup_delay);
config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0);
- if (config->enable_gpio == -EPROBE_DEFER)
- return ERR_PTR(-EPROBE_DEFER);
+ if (config->enable_gpio < 0 && config->enable_gpio != -ENOENT)
+ return ERR_PTR(config->enable_gpio);
/* Fetch GPIOs. - optional property*/
ret = of_gpio_count(np);
@@ -190,8 +190,11 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
for (i = 0; i < config->nr_gpios; i++) {
gpio = of_get_named_gpio(np, "gpios", i);
- if (gpio < 0)
+ if (gpio < 0) {
+ if (gpio != -ENOENT)
+ return ERR_PTR(gpio);
break;
+ }
config->gpios[i].gpio = gpio;
if (proplen > 0) {
of_property_read_u32_index(np, "gpios-states",
--
2.10.2
^ permalink raw reply related
* Summary of LPC guest MSI discussion in Santa Fe
From: Alex Williamson @ 2016-11-11 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111111944.GO2078@8bytes.org>
On Fri, 11 Nov 2016 12:19:44 +0100
Joerg Roedel <joro@8bytes.org> wrote:
> On Thu, Nov 10, 2016 at 10:46:01AM -0700, Alex Williamson wrote:
> > In the case of x86, we know that DMA mappings overlapping the MSI
> > doorbells won't be translated correctly, it's not a valid mapping for
> > that range, and therefore the iommu driver backing the IOMMU API
> > should describe that reserved range and reject mappings to it.
>
> The drivers actually allow mappings to the MSI region via the IOMMU-API,
> and I think it should stay this way also for other reserved ranges.
> Address space management is done by the IOMMU-API user already (and has
> to be done there nowadays), be it a DMA-API implementation which just
> reserves these regions in its address space allocator or be it VFIO with
> QEMU, which don't map RAM there anyway. So there is no point of checking
> this again in the IOMMU drivers and we can keep that out of the
> mapping/unmapping fast-path.
It's really just a happenstance that we don't map RAM over the x86 MSI
range though. That property really can't be guaranteed once we mix
architectures, such as running an aarch64 VM on x86 host via TCG.
AIUI, the MSI range is actually handled differently than other DMA
ranges, so a iommu_map() overlapping a range that the iommu cannot map
should fail just like an attempt to map beyond the address width of the
iommu.
> > For PCI devices userspace can examine the topology of the iommu group
> > and exclude MMIO ranges of peer devices based on the BARs, which are
> > exposed in various places, pci-sysfs as well as /proc/iomem. For
> > non-PCI or MSI controllers... ???
>
> Right, the hardware resources can be examined. But maybe this can be
> extended to also cover RMRR ranges? Then we would be able to assign
> devices with RMRR mappings to guests.
RMRRs are special in a different way, the VT-d spec requires that the
OS honor RMRRs, the user has no responsibility (and currently no
visibility) to make that same arrangement. In order to potentially
protect the physical host platform, the iommu drivers should prevent a
user from remapping RMRRS. Maybe there needs to be a different
interface used by untrusted users vs in-kernel drivers, but I think the
kernel really needs to be defensive in the case of user mappings, which
is where the IOMMU API is rooted. Thanks,
Alex
^ 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